[Bug 796382] flvmux: (too) easily produces backwards flv-timestamps

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796382

Håvard Graff (hgr) <havard.graff at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #372380|0                           |1
        is obsolete|                            |
 Attachment #372387|rejected                    |none
             status|                            |
 Attachment #372387|0                           |1
        is obsolete|                            |

--- Comment #13 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
Created attachment 372461
  --> https://bugzilla.gnome.org/attachment.cgi?id=372461&action=edit
flvmux: always wait for both an audio and a video buffer  before processing

his makes the behavior almost identical to the old flvmuxer, and removes
quite a few racy behaviors that exists today.

The most interesting one we have been seeing has been when audio
comes first into the muxer (say 2 seconds worth), and then video
starts flowing after that.

The audio *should* then always be processed first (since it has lower
timestamps), but due to the wait the waiting for buffers is working,
sometimes a video-buffer would sneak in (because the audio-buffer did
not reached the flvmuxpad in time from the queue it was residing in,
and then only a video-buffer was available when finding the best pad) and
then you get havoc with backwards timestamps etc etc.

Effectively this means the flvmuxer will now never wait on the clock
at all, but rather wait for at least one buffer on each pad.

Whether we would like a "live-mode" that would wait on the clock at some
point could probably be discussed, but then more care need to be given
about what to do with late buffer etc (probably dropping?).

AFAICT this patch makes the "new" flvmuxer act almost identical with the
"old" one, and that is probably a good thing for now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.