[gstreamer-bugs] [Bug 613003] New: [flvmux] EOS after supposedly reaching FLV timestamp limit, but real limit is lower

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=613003
  GStreamer | gst-plugins-good | git

           Summary: [flvmux] EOS after supposedly reaching FLV timestamp
                    limit, but real limit is lower
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: wulczer at wulczer.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


The timestamp field of a FLV tag is actually a signed 32bit integer (see
http://www.adobe.com/devnet/flv/pdf/video_file_format_spec_v10.pdf page 5).

The FLV muxer emits an EOS if the timestamp reaches G_MAXUINT32, when in
reality it should be G_MAXINT32.

For example, a file created with this pipeline:

gst-launch videotestsrc timestamp-offset=428996729500 num-buffers=1000 !
x264enc ! flvmux name=mux audiotestsrc timestamp-offset=428996729500
num-buffers=1000 ! lame ! mux. mux. ! filesink location=out.flv

freezes in Addobe Flash player after the timestamp reaches MAXINT32.

An even better solution that just emitting EOS would be wrapping the timestamp
back to 0 (in the FLV tag, not the GStreamer buffer timestamp). The player will
freeze anyway, but if the muxer is streaming live data the client will just
need to reconnect (read: refresh the web page) and will resume playback.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.