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.
Do you mean buggy?
