VLC2 updated libavcodec?

[aitte]

Hello,

Did VLC2 get a new version of libavcodec or what?

All I know is that VLC 1.x plays files that 2.x will stutter or freeze on.

I cannot provide any sample files, which is why I am simply asking if libavcodec was updated, or if something else is to blame?

[Jean-Baptiste Kempf]

It was updated.

[aitte]

Thanks for the info. It seems then that libavcodec updates have caused certain formats to freeze now, meaning either errors decoding portions of a file, or outright freezing beyond just showing the first frame. Perhaps it's a change to libavcodec's API that VLC hasn't been updated for, or perhaps libavcodec has genuinely got worse decoding than before.

Examples of container/codec combos I've come across as freezing in VLC 2 but not in 1.1.9:
On2's VP6.2 (VP6F) in FLV container
XVID in AVI container

If anyone else comes across any files that freeze in VLC 2, try playing in VLC 1.1.9 (http://download.videolan.org/pub/videol ... .9/macosx/) and it will work.

For now I'll keep both 1.1.9 and 2.0 on the system.

[Jean-Baptiste Kempf]

1.1.9 is insecure.

[aitte]

1.1.9 is insecure.

Hmm, that is unfortunate, but it's unavoidable since 2.0 has these issues.

This is possibly related: http://trac.videolan.org/vlc/ticket/6180 (libavcodec bug related to multithreaded decoding, but seems to only be for h264).

Either way, looking at the commit history for libavcodec and bug tracker gives me hope that some of the recent changes might fix things. It looks like everything is caused by libavcodec, and not by VLC 2 itself.

[BlueBluBuru]

1.1.9 is insecure.

What do you mean by "insecure" Do you mean buggy?

[aitte]

1.1.9 is insecure.

What do you mean by "insecure" Do you mean buggy?

He means that it's from April 2011, meaning it's nearly a year old. Since then, they've spent countless hours re-factoring the code, fixing bugs, fixing theoretical and real exploits, and so on, to create v2.0. So in other words, 1.1.9 is outdated from a security standpoint, although I am unaware of any actual exploits for it.

However, VLC 2 has trouble with so many video formats freezing that keeping both is required. :-/

As for why VLC 2 is so troubled, well, it could be a bug in libavcodec (the open source video and audio decoder/encoder component used by VLC and most other open-source media players), or it could be a bug in VLC 2's handling of the updated libavcodec.

[BlueBluBuru]

1.1.9 is insecure.

What do you mean by "insecure" Do you mean buggy?

He means that it's from April 2011, meaning it's nearly a year old. Since then, they've spent countless hours re-factoring the code, fixing bugs, fixing theoretical and real exploits, and so on, to create v2.0. So in other words, 1.1.9 is outdated from a security standpoint, although I am unaware of any actual exploits for it.

However, VLC 2 has trouble with so many video formats freezing that keeping both is required. :-/

As for why VLC 2 is so troubled, well, it could be a bug in libavcodec (the open source video and audio decoder/encoder component used by VLC and most other open-source media players), or it could be a bug in VLC 2's handling of the updated libavcodec.

Yeah, I'm just a little perplexed as to how something used to playback video files can be seriously exploited from a security standpoint. At this point, anyway, I really only use VLC to playback MKV video files that I've ripped myself so I really don't see how, for my purposes at least, security could be any sort of an issue. Maybe if you're streaming or downloading a lot stuff, then, yeah.

[aitte]

Yeah, I'm just a little perplexed as to how something used to playback video files can be seriously exploited from a security standpoint. At this point, anyway, I really only use VLC to playback MKV video files that I've ripped myself so I really don't see how, for my purposes at least, security could be any sort of an issue. Maybe if you're streaming or downloading a lot stuff, then, yeah.

That's why it is so insidious; people don't suspect media files. However, it is fully possible to execute evil code with the combination of media player vulnerabilities and a carefully crafted media file to exploit it. Google "vlc exploit".

Finding these exploits isn't as common these days as it used to be, and it's also extremely rare that they're actually abused in the wild, so for those reasons I am not worried about keeping 1.1.9 for now.

And you're also right - the risk comes from downloaded files; particularly from untrustworthy sources. A file has to be manually crafted to take advantage of an exploit, and it won't just randomly happen with something you've encoded yourself, or even with the vast majority of the media files out there. It requires an author with evil intent.

[Jean-Baptiste Kempf]

No I mean insecure, as in exploitable.

[aitte]

Will 2.0.1 update libavcodec again? Perhaps that will fix things. They recently solved some multicore decoding bugs upstream and that may be the entire cause of this, if we're lucky.

Update: I have 2.0.1 now but files still play badly... VLC 2.x is still not ready for primetime, and I think we can blame libavcodec for it. Files that used to play perfectly can now skip frames as if they were corrupt and so on. Slower seeking etc too. (Some affected formats are listed in a previous post in this thread)... And now I see that serious exploits have been discovered for earlier versions, at http://www.videolan.org/security/sa1201.html and http://www.videolan.org/security/sa1202.html... Fun... VLC 2 is just not good right now. I can only hope a newer libavcodec will fix this someday... For now, I guess I'll re-encode offending files to make them playable in VLC 2 and stop using VLC 1...

[Jean-Baptiste Kempf]

Just share the files that are broken!

[aitte]

Just share the files that are broken!

Sorry, I didn't check back and see this reply until now.

I have figured out what the common thing in all of this is. Every file VLC has a problem with was something recorded/ripped from live streams, in other words files with lots of missing frames!

Live streams will extremely often drop loads and loads of frames. These dropped frames cause pauses in the video, which VLC might either stall on or completely hang on. Probably the fault of libavcodec, not VLC.

VLC/libavcodec can also cause the stream to be played in a weird way, where it is sped up, rather than waiting the proper amount of time between frames.

VLC/libavcodec also doesn't handle streamed audio well, having a choppy effect.

Here's an example that shows both stalling, speeding up and choppy audio:
http://www.mirrorcreator.com/files/1SSZ ... .flv_links

If played in something like a flash player, the video above will play properly with proper audio, proper pauses between frames etc, whereas VLC plays it sped up with choppy audio, and stalls at several points. I tried the same exact file in something called Applian FLV player and it plays perfectly (as perfect as can be for this very choppy stream; I intentionally chose this stream because of its low bandwidth).

The correct result would be if VLC was able to play the above file as nicely as Flash Player/Applian FLV player does.

[Jean-Baptiste Kempf]

So, it seems it is a flv issue, and therefore libavformat, not libavcodec.
This is probably linked to the rtmpdump pipe...

[aitte]

So, it seems it is a flv issue, and therefore libavformat, not libavcodec.
This is probably linked to the rtmpdump pipe...

Great to hear back from you, and that's an interesting theory, although it also happens if the stream is moved as-is to another container format like AVI (without re-encode).

Basically, if you go into the VLC log, you'll see that it's struggling with the "unexpected" gaps in the video and audio streams, giving constant warnings about buffer underruns. I'll post a copy of the errors here for reference purposes for anyone else reading the thread later down the line.

I have a theory of why it's happening. Imagine this is the live stream coming down from a website:
[a/v data][gap in stream][a/v data][a/v data][a/v data][gap in stream][a/v data][a/v data]
(this is simplified; live streaming allows audio data to come in asynchronous from video data, and streaming servers always put a focus on delivering audio data at all times even if the video stream stalls due to bandwidth issues, so that you will at least hear what is going on while bandwidth issues are going on)

VLC seems to play through the video and audio buffers as fast as it can, ignoring the intended wait time between frames, leading to this:
[video decoded][video decoded][video decoded][video decoded][video decoded][buffer underrun since there is no more data, sometimes even giving up video decoding completely and leading to a frozen frame or crashed player]
[audio decoded][audio decoded][audio decoded][audio decoded][audio decoded][buffer underrun since there is no more data]

That would explain the very sped-up, choppy movement as it blazes through everything.

Proper playback of such live-streams would be:
[video decode][gap in stream][video decode][video decode][gap in stream][gap in stream][gap in stream][video decode]
[audio decode][audio decode][gap in stream][audio decode][audio decode][audio decode][gap in stream][audio decode]
(proper playback would require both the video decode and audio decode to be asynchronous from each other and for each to independently wait the proper time for the next audio/video data to become available)

This is just a theory, of course, based on seeing the rapid video playback and audio buffer underruns in VLC, but it seems to be the culprit.

Code: Select all

main debug: Decoder buffering done in 223 ms main warning: PTS is out of range (-9986), dropping buffer main warning: buffer too late (60222), up-sampling main warning: timing screwed, stopping resampling main warning: buffer too late (91541), up-sampling main debug: VoutDisplayEvent 'mouse button' 0 t=8 main debug: VoutDisplayEvent 'mouse button' 0 t=9 main debug: picture might be displayed late (missing 0 ms) main debug: auto hiding mouse cursor main warning: resampling stopped after 1887358 usec (drift: -130376) main debug: picture might be displayed late (missing 10 ms) main warning: buffer too late (130816), up-sampling main warning: picture is too late to be displayed (missing 20 ms) main warning: buffer way too late (197063), dropping buffer main debug: picture might be displayed late (missing 3 ms) main debug: picture might be displayed late (missing 9 ms) main warning: buffer way too late (202519), dropping buffer main warning: buffer way too late (223777), dropping buffer main warning: buffer way too late (216777), dropping buffer main debug: picture might be displayed late (missing 13 ms) main debug: picture might be displayed late (missing 0 ms) main warning: buffer way too early (-196055), clearing queue main warning: timing screwed, stopping resampling main warning: buffer too late (117199), up-sampling main warning: timing screwed, stopping resampling main debug: audio output is starving (-1835840), playing silence main warning: buffer too late (175519), up-sampling main debug: picture might be displayed late (missing 0 ms) main warning: buffer way too late (180399), dropping buffer main warning: buffer way too late (186399), dropping buffer main warning: resampling stopped after 645682 usec (drift: 52703) main warning: buffer too early (-52264), down-sampling main warning: audio output out of sync, adjusting dates (-175602 us) main warning: not synchronized (-175602 us), resampling main warning: buffer way too early (-266101), clearing queue main warning: timing screwed, stopping resampling main debug: audio output is starving (-1812132), playing silence main warning: buffer too late (68639), up-sampling main warning: resampling stopped after 487568 usec (drift: 583) main warning: buffer too late (64775), up-sampling main warning: resampling stopped after 205699 usec (drift: -91884) main warning: buffer too late (110324), up-sampling main warning: timing screwed, stopping resampling main warning: buffer way too late (186643), dropping buffer main warning: audio output out of sync, adjusting dates (-175131 us) main warning: buffer too early (-46357), down-sampling main warning: not synchronized (-175131 us), resampling main warning: buffer way too early (-222048), clearing queue main warning: timing screwed, stopping resampling main debug: audio output is starving (-1823949), playing silence main warning: buffer too late (79639), up-sampling main warning: resampling stopped after 158617 usec (drift: -59868) main warning: buffer too late (60308), up-sampling main warning: resampling stopped after 199921 usec (drift: 372) main warning: buffer too late (80106), up-sampling main warning: audio output out of sync, adjusting dates (-175337 us) main warning: not synchronized (-175337 us), resampling main warning: buffer way too early (-182360), clearing queue main warning: timing screwed, stopping resampling main warning: buffer too late (61759), up-sampling main debug: audio output is starving (-1858507), playing silence main warning: timing screwed, stopping resampling main warning: buffer too late (126079), up-sampling main warning: buffer way too late (194868), dropping buffer main warning: resampling stopped after 526167 usec (drift: -17766) main warning: buffer too early (-46794), down-sampling

I think a fix would require independent, asynchronous a/v decoding with proper waiting between data frames in each. If I remember correctly (and I may not), there's actually a frame index at the start of all audio/video frames in live-streams, which tell you what frame the audio or video data is for; that's what allows a player to keep repeating the last-seen frame + silent audio (during low bandwidth/stalling) until it reaches the frame index that allows it to decode and show the new data. Basically:
[1000,video data][1100,video data]
[1500,audio data][1550,audio data]
That means a player has to use this info to wait before playing the audio/video until the right time has come, and to repeat the last-seen video frame/silent audio while waiting.

Now, the thing is, playback of such streams was more stable under the VLC 1.x line; nowadays with VLC 2.x it's much more common to see complete freezing of VLC or freezing of the video on a single frame, despite more data becoming available. This might be because of VLC2 giving up more quickly when it encounters gaps in the video sequence?

Either way, this is probably a job for the codec layer, to either pass along timing information for the decoded audio and video data, or to insert the necessary frame repeats/audio silence where needed.

[bentleykf]

VLC 1.x plays files that 2.x will stutter or freeze on.

I've noticed problems specifically with XviD in an AVI container.

I can replicate the files using BSR Screen Recorder 5 with the Xvid codec installed and selected with all default values. The Xvid codec is from http://www.xvid.org/ not from any other source (1.3.2 x64). I'm using Windows 7 build 7601. I've reproduced two simple examples that should show a cursor moving about the screen.

http://www.mirrorcreator.com/files/0ZLY ... .rar_links

These files only load the first frame and fail to play any other frames under VLC 2.0.1 x86 (the VLC slider still progresses). I haven't been able to test sound so i'm not sure if there's a problem with sound and the xvid codec in vlc.

If you require any further info please let me know

[Jean-Baptiste Kempf]

Did they play before?

[bentleykf]

Did they play before?

They play fine after i uninstall version 2.0.1 and install 1.1.9

[Jean-Baptiste Kempf]

Both work fine on VLC 2.0.2 on linux. Will update libavcodec for VLC 2.0.2 on windows too then.

[aitte]

Hello Jean-Baptiste Kempf! I've been gone for a while.

Well, you know my long post above about FLV frame indexes? I finally found your answer for how it works:

FLV - and particularly ones recorded from streaming sources - contains *timestamps* and those timestamps indicate when Audio or Video frames are supposed to be presented. This MUST be followed, NEVER displaying data before its timestamp occurs. If there's no more data ready to display for the moment, then a player must repeat silence (audio)/last frame (video) until it is time to show the frames/play the audio.

The problem is that VLC just speeds through files, seemingly ignoring timestamps (see the test recording I posted way above), therefore playing video and audio too fast and flooding its own message log with buffer underrun errors, etc, instead of gracefully waiting for the right time to display video/audio based on the actual timestamps... The question is if it's VLC's fault or Libavcodec's...

Basically, the timestamp indicates when the video/audio/metadata is to be presented to the viewer. The value is in milliseconds relative to the start of the
file.

If you have an FLV file, a hex editor and a copy of http://download.macromedia.com/f4v/vide ... _v10_1.pdf you can try it out and see how altering the timestamp values affect the playback when using a fully compliant player such as Flash.

They are very similar to MPEG PTS (Presentation time stamps).

So, any idea if this is a decoder issue or VLC issue?

[aitte]

Does anyone know what might be the cause of the issues? libavcodec or VLC's interpretation of the data returned from libavcodec? (See previous message; last one on page 1)

[Jean-Baptiste Kempf]

libavcodec regression.

[evasive]

any timeline on a solution, whatever the outcome?

How about backrevving libavcodec?

Right now I am faced with no usable player since VLC 2.x is broken and VLC 1.x is insecure?

[fkuehne]

Please try again with the latest version. That includes an updated libavcodec. Regrettably, we cannot revert to a previous version because of security issues.

[evasive]

2.0.3/2.0.4 do not solve the issue. Playing around with power management settings in bios and windows did. The problem is, after restoring the settings to their original values, I cannot reproduce the problem. I am beginning to think this is something similar like the cpufreq issue in linux with Core2 Duo and newer CPUs. Either there's a fault in the documentation of those or there's a flaw that Intel not yet is admitting. But something is wrong outside of VLC.

System:
HP 6000 SFF, E8400, 4GB, XP SP3 32bit