Consistent Playback Delay for HTTPS Network Streams

I couldn't attach the logs because they are about 3MiB and this above the maximum size limit.

How do you use YouTube without TLS? MissingSample, unreproducible and no logs.

closed

I couldn't attach the logs because they are above the size limit. And you can produce them using vlc -vvv https://www.youtube.com/watch?v=UiXaa3ZorWs 2>&1 | tee consistent-playback-delay-for-https-network-streams.log.

I don't really understand your note about TLS (does VLC need to be linked against TLS, for example?). Please elaborate more and if you need me to reproduce it by compiling the latest revision from the repo.

And please do tell me whatever you need to resolve this because my brother is using VLC for realtime purposes and a one minute delay in playback for him is huge. I suggested to him to use SMPlayer for playback but he wants to use a single player.

Replying to [ticket:21614 Abdullah Alansari]:

Whenever I play an HTTPS network stream the playback is consistently delayed by about 1 minute. We can easily see delay of 84s on Win nightly version and web player. That is, of course, when VLC is not using Win10 built-in certificates...(another ticket)

I just tried playback that seems to be using HTTP rather than HTTPS and there's, indeed, no delay.

I searched HTTPS on https://trac.videolan.org to find the other tickets to no avail. Can you point me to it?

That is only in rare cases when it will not even open the video by default without disabling system certs. \ In this case it is important to note that web player is offering option to seek 4h back. In VLC that is not possible at any time(only live-1m)

This is happening consistently on both my Ubuntu machine and my brother's Windows 10 machine for YouTube live videos (as in the sample provided above) using the native VLC player directly (not a browser extension/plugin, etc...) and without any system modification (disabling certs, for example).

I believe this can be produced in any stock system by just opening a YouTube live URL in the native VLC player (see the reproducability above), as opposed to what I understood from your last comment (system certs disabled -> VLC uses built-in/fallback ones).

I just tried a couple of YouTube live channels and I think there may be a positive correlation between the quality of the stream and the delay (not sure if this can be different depending on network speed). This is, of course, a couple of steps ahead and I think we should focus on confirming the bug in the first place.

And I'm curious how the delay could be 60+ seconds which is a lot if VLC is just doing some computation to catch up.

And as a side, I think disabling system certs (which is not the case here) may be for self-issued certs or something similar and YouTube explains this away.

Replying to [comment:7 Abdullah Alansari]:

And I'm curious how the delay could be 60+ seconds which is a lot if VLC is just doing some computation to catch up. That proves seek is possible for live streams. When we attempt to seek back 4h(beginning of seek bar):

main error: INPUT_CONTROL_SET_POSITION @0.0% failed

On start seek bar should be full(blue) indicating live

main error: INPUT_CONTROL_SET_POSITION @100% failed

And as a side, I think disabling system certs (which is not the case here) may be for self-issued certs or something similar and YouTube explains this away. I will again see what is with that ticket affecting only certain combinations of Win10 and older CPUs...

I didn't get your point about seeking the live-stream and can't see how it's relevant especially since I didn't do anything in the start/end time options and the seeking doesn't seem to work with the sample I provided.

I just uploaded a video of this bug (yet to be confirmed) so you can see it in action https://youtu.be/Ip7S8mPhIRE.

You can see the minutes in my top bar and the minutes in the video and that they don't match unlike the actual stream when played from youtube.com or using SMPlayer.

Please take my word (and video) for it and just play the sample I provided so we can confirm this and start to work on a fix as soon as possible and we can be more elaborate and have more discussions if it wasn't reproduced.

Sometimes assuming a bug has a rare scenario/state can waste time looking for the rare scenario/state when the it just happens in the initial state. It's true that this may only happen with certain hardware (me and my brother both have high-end machines with external GPUs) and network connections (in Saudi Arabia) but starting with the assumption that it happens all the time is much faster and more productive than the opposite.

Long story short, just try the provided sample using any recent VLC version (not necessarily the latest commit) and if you can reproduce the bug then you just confirmed it in less than 5 minutes otherwise you just lost 5 minutes.

Replying to [comment:9 Abdullah Alansari]:

I didn't get your point about seeking the live-stream and can't see how it's relevant especially since I didn't do anything in the start/end time options and the seeking doesn't seem to work with the sample I provided. Because it looks like VLC will unintentionally rewind any such live video by one minute. For example, we can see there is no DVR on F24.

Broadcast Delay in Advanced Settings of Events.

I observe a delay of about one-minute when playing F24 using VLC. This is just like the sample video I provided which doesn't have the delay on SMPlayer.

If the delay have something to do with the YouTube live-stream settings or anything else, then the same delay should be present in SMPlayer (which it is not). Unless, for example, YouTube live uses a black-list (that includes VLC) of agents for the delay settings but this is too far ahead right now and we need to just confirm this as a bug in the first place.

I need VLC for this use-case and I have no idea what to do right now because the ticket is closed, the bug is not confirmed, and I don't know of any workaround.

even if reopened

There can be no warranties regarding the timeframe or the propriety* of the resolution of any particular bug reported or feature requested here.

priority?

Sorry, I may have spoken out of line. I understand this is a community support and you already have too many other tickets as it is. It just would be nice to confirm this as a bug or not for now.

I think of working on the fix myself too and confirming the bug would justify the investment of time and the initial setup to look into it.

removed Status::needs more info label

reopened

0001-demux-hls-fix-consistent-live-delay-21614-WIP.patch

Added attachment:

0001-demux-hls-fix-consistent-live-delay-21614-WIP.patch

I just submitted a patch/fix and the name of the file and the commit message should be self-explanatory. I know everyone who writes the most cryptic descriptions says this but I hope to be the first to be right:sweat_smile:.

I will just paste the whole commit message here for convenience so here goes:sweat_smile::

demux: hls: fix consistent live delay (#21614)

The bug was first observed on https://www.youtube.com/watch?v=WI86J46VRUc

This YouTube live-stream contains a wall-clock in the bottom-right corner which makes it very convenient for testing.

Before this patch/fix, playback with VLC is 1minute+ behind the YouTube website:sweat_smile: and after the patch, YouTube is the one behind:smiley:.

This bug should manifest in all platforms in any YouTube live video.

The initial analysis of this bug showed that the reason for this delay is that VLC plays the first video in the M38U file which can be 1minute+ before the current wall-clock time:sweat_smile:.

This was observed on http://www.tv.wataan.com/?video=show&show=104 where the delay was non-existent on Firefox and existent on VLC .

On Firefox, the second-to-last video in the M3U8 was played while on VLC the first video was played. And upon downloading both videos, Firefox's downloaded has the correct wall-clock time while VLC's one was 1minute+ behind:sweat_smile:.

And thus this patch does something similar to the Firefox observed behavior above (which may just be from the website's own code).

I have almost the whole related RFC and the 6.3.3 sections is probably the single most relevent: https://tools.ietf.org/html/rfc8216#section-6.3.3 Specifically "the client SHOULD NOT choose a segment that starts less than three target durations from the end of the Playlist file."

This patch may possibly break non-live HLS and not fix other adaptive-live stuff (e.g: DASH) if they are already affected:sweat_smile:.

A list of tested samples that had the delay before this patch and don't anymore:

Related to https://trac.videolan.org/vlc/ticket/21614#attachments

Fixes an issue where the previous patch would break with non-live HLS streams.

Added attachment:

0001-demux-hls-fix-consistent-live-delay-21614-WIP2.patch

Sooo what can I do to help move things forward:sweat_smile:?

	373	        if (isFirstPlaylist) {
 	374	            segmentList->pruneBySegmentNumber(sequenceNumber - 1);
 	375	        }
 	376

We have fixed live timeshift seeking, it's not to truncate playlist as soon as you load it.

I have almost the whole related RFC and the 6.3.3 sections is probably
the single most relevent:
https://tools.ietf.org/html/rfc8216#section-6.3.3
Specifically "the client SHOULD NOT choose a segment that
starts less than three target durations from the end of the
Playlist file."

Then your understanding is different from mine. The last sentence of this paragraph being:

Doing so can trigger
   playback stalls.

Which means don't try to download the most 3 recent segments, or buffering will stall.

If you always start within the 3 last ones, you'll likely have to wait for total buffering / target length - 3.

Computed delay is:

Max of

Min buffering (6s)
Max buffering (60s)
Suggested presentation delay (manifest defined)
3 last segments + 1 sec

Only the max buffering can be shrunk, but its default value is for stability.

See

vlc_tick_t AbstractPlaylist::getMaxBuffering() const
{
    const vlc_tick_t minbuf = getMinBuffering();
    return std::max(minbuf, VLC_TICK_FROM_SEC(60));
}

First and foremost, sorry for the late reply:sweat_smile: and thanks for looking more into this:smile:.

We have fixed live timeshift seeking, it's not to truncate playlist as soon as you load it. I've looked closely and found the existing implementation tracing it from AbstractPlaylist::getMaxBuffering().

Which means don't try to download the most 3 recent segments, or buffering will stall. You're absolutely right. I've understood the wording to be what I wanted even though it's unambiguous:sweat_smile:.

Only the max buffering can be shrunk, but its default value is for stability. Looking into the existing timeshift implementation, I found that the value of the max buffering is the main contributing factor to the HLS live playback delay:sweat_smile:.

Now I will blab on but hope this will get the message across, save your time, and show how I see this as accurately as humanly possible:smiley:. And as a bonus you can sleep any time you want in the future by just trying to read the rest:sweat_smile:.

I didn't intend for my initial patch to be a fix. I first analyzed the issue from a user-perspective (comparing VLC to YouTube, websites, other players, etc...) without even looking into the devs corner or downloading the source code. Only after reproducing the bug consistently on VLC and confirming its absence as a user, did I look into the devs corner and start looking into the code. Then I worked on the code and did the minimum fix merely to confirm my hypotheses. I then submitted my minimum fix as a patch just to get my foot in the door and at least get an acknowledgement of the issue.

The issue only appears for real-time use-cases where a 1minute delay is too long. My brother has some of these use-cases for his job and this is how I came across this:sweat_smile:. This is very obvious because when using VLC the delay is always 1minute+.

The possible reasons of how this is not widely reported are many and I will explain some of them.

Only users where 1minute+ delay is too long are affected and these are mostly specialists and would just use another player even if just for the sake of this issue.
Like any software project (open source or not), even if a user reported this it may not be confirmed as a bug.
From experience, I personally find that most people overestimate how complex the majority of bugs are. Sure there are bugs where the correct behavior of multiple components leads to incorrect behavior in a particular environment but assuming this as the default can make many simple bugs non-fixable for all intents and purposes:sweat_smile:. In this instance, you can simply open a live YouTube stream with wall-clock time and compare YouTube to VLC and you have just reproduced the bug. Even the logs and environment which are necessary in many cases are probably irrelevant in this case.

The current time-shift implementation uses 60seconds for stability but this is too large a value for real-time use-cases where a total 1minute delay is too large. Although, the defined VLC delay is 60seconds the perceived user delay is much larger because other factors increase the delay (e.g: multiple RTTs). For example, the actual live stream has a delay and even the latest segment is at least several seconds late:sweat_smile:.

When working on this and before knowing that there's already a time-shift implementation, I was planning to have a user-input/preference to choose between stability and low-delay. For example, in the preferences there would be a volume-like slider where in one end the first segment would be played first and on the other end the 3rd to last segment would be played first.

Because IMHO my patch and even the more advance cool VLC existing time-shift implementation are too small for a (preference/user-input)-free implementation that can work for both stable and low-delay use-cases and just don't fit the problem.

Sometimes I think of problems and solutions as 3D objects. For example, a solution where a fixed video quality (e.g: 720p) is used without user-input/preference is too small and doesn't fit the problem of choosing the most appropriate quality for the user. In this case, a solution where a user-input/preference exists is too small but does fit because the user-input can compensate for the missing solution volume. And a solution where the most appropriate quality can be automatically chosen for the user has the same size of the problem and does fit.

IMHO, The most important thing is for the solution to fit. The current VLC time-shift implementation is too small and doesn't fit the solution space. I think it boils down to two main choices/fixes:

Add user-input/preference where a user can choose whether they want low-delay or stability.
Make the time-shift implementation work for both low-delay and stability.

The first fix is logically straight forward and most of effort would probably go into the UI/UX. However, the second fix is logically hard and probably has no direct easy solution without drawbacks:sweat_smile:.

It's fine to go with the easiest fix and I'd even recommend it:smiley:. On the other hand, I'd strongly recommend against the second harder fix in most cases because I think it would take longer than expected and the contributor would run out of time and then implement the easiest solution in a hurry:sweat_smile:.

TLDR;

I can think of 3 ways to handle this:

Use a smaller value for the max buffering (AbstractPlaylist::getMaxBuffering()). For example, 20seconds.
Add user-input/preference where a user can choose whether they want low-delay or stability.
Make the time-shift implementation work for both low-delay and stability.

I don't think you would be very fond of approach no. 1 and approach no. 3 is probably too far in the future for VLC.

So I'd suggest approach no. 2 which would involve some UI/UX work along with adding some configuration and finally integrating with the current time-shift implementation.

I just want this mitigated/fixed and would be happy to start working on it upon your approval (whether using my suggested approach or otherwise). Any help would be immensely appreciated though.

Loooooking forward to hearing from you:smiley:.

Sooo what can I do to help move things forward:sweat_smile:?

added Component::Input: network streams Platform::GNU/Linux labels

Consistent Playback Delay for HTTPS Network Streams

Child items 0

Activity