GNOME Bugzilla – Bug 613003
[flvmux] EOS after supposedly reaching FLV timestamp limit, but real limit is lower
Last modified: 2010-03-17 08:25:14 UTC
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.
What would you suggest to do with the duration and the index? Limit the duration to MAXINT32 and don't put all tags after MAXINT32 into the index? Maybe we should only allow this in case is-live==TRUE? Are you planning to work on this?
Yeah, I'm planning to work on this. Maybe it should only happen for is-live, rolling over timestamps is really a hack to allow the muxer to do streaming, a file that lasts that long can arguably be considered not suitable for FLV and that's it. OTOH the times in the index are in doubles, so you could fit values > MAXUINT32 there, and the same goes for duration, so you could put correct data there. I guess just doing timestamp &= 0x7fffffff before writing it to the FLV tag would be the best solution.
Putting values > MAXINT32 into the index is confusing though because the tags won't have these timestamps
Created attachment 156317 [details] [review] don't use timestamps larger that G_MAXINT32, wrap them for live
(In reply to comment #3) > Putting values > MAXINT32 into the index is confusing though because the tags > won't have these timestamps You're right, there's not point in trying to support that. I made the timestamps wrap for live and EOS after G_MAXINT32 for non-live.
commit 96de71d74b3f4d2fc3c6a675dab86ac00a0c151a Author: Jan Urbański <wulczer@wulczer.org> Date: Tue Mar 16 23:32:45 2010 +0100 flvmux: don't put timestamps larger than G_MAXINT32 in the FLV tags For non-live input respond by pushing EOS, for live wrap the timestamps every G_MAXINT32 miliseconds. Fixes #613003.