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

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 796382
           Summary: flvmux: (too) easily produces backwards flv-timestamps
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: havard.graff at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: gstreamer at pexip.com
     GNOME version: ---

Created attachment 372380
  --> https://bugzilla.gnome.org/attachment.cgi?id=372380&action=edit
test

Running the new GstAggregator-based flvmuxer in our system gave some weird
failures.

Turns out it was caused by the flv-timestamps going backwards, and with RTMP
generating delta timestamps, these would go negative and cause the timestamps
to overflow, producing timestamps thousands of hours into the future!

With a bit of hassle I was able to produce a test that can be run both with the
old and new flvmuxer, and that will produce a "correct" sequence with the old
implmentation, and a "backwards-timestamp" sequence with the new, basing it on
the real data I saw in our tests.

As for possible fixes I think first it would be a good idea to determine if
producing backwards timestamps in the flv-stream is something we want to avoid
at all costs, or if this can be expected to happen.

Anyway, some sort of sanity internally in the flvmuxer to at least notify the
user of backwards timestamps (or perhaps a property to not allow it), would
probably be a good idea, as I expect many people upgrading the muxer would
experience similar things to what we did.

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