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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #17 from Håvard Graff (hgr) <havard.graff at gmail.com> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #16)
> Assuming the FLV spec forbids a certain delay debtween audio / video, which
> is what makes it looks like backward timestamp. This as been simply assumed
> based so far. It's also bad, since the idea behind using aggregator is now
> completely broken. I'd like Olivier's input, this patch seems backward, and
> a little too focus on one test case. More information need to be gathered.

No one is assuming anything. I am very familiar with the specs, and they *do*
allow backwards timestamps, because of seeking: ref:
http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

5.3.1.2.1. Type 0
 Type 0 chunk headers are 11 bytes long. This type MUST be used at
 the start of a chunk stream, and whenever the stream timestamp goes
 backward (e.g., because of a backward seek).

But what the specs says and what implementations out there are doing is of
course two very different things (as you would know).

What I am pointing out is a very large behavioral difference that will cause
chaos for many users. It certainly did for us, all our RTMP related tests went
blood red when upgrading to 1.18.

And it is *not* just the fact that timestamps will sometimes go backwards that
is the problem here (as you would have understood having read all my previous
comments). The fact that a video buffer "from the future" can sneak in to a
stream of audio-buffer being processed is very bad, and a side-effect of timing
out a wait for a time in the past.

Keep in mind this is not flvmux2, this is good old flvmux and hence I would
expect the behavior to stay the same. Moving to GstAggregator is great because
collectpads are very prone do deadlocking, and aggregator are much better in
that respect.

Now, if we were to add a new "live-feature" to the flvmux that would be great,
and the aggregator would be perfect for that, but that is *new* functionality,
and should be treated as such (ex. opt in/out with a property) which is
different from a change that on the surface should *not* be functionally
different.

Reverting to the old flvmux would of course be an option, but I think there are
good things in the future for a more live-based flvmux and would definitely
like to see this moving forwards, and also removing collectpads from the
equation is a very good thing. (they have been our single biggest source of
deadlocks)

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