GNOME Bugzilla – Bug 707242
qtmux: streamable and faststart property have no effect
Last modified: 2013-09-20 08:04:19 UTC
please try this pipeline: gst-launch-1.0 -e videotestsrc num-buffers=1000 ! jpegenc ! qtmux streamable=1 ! filesink location=/tmp/test.mov the file test.mov is not playable until I stop the pipeline, if I change qtmux with matroskamux, the file is playable without waiting for the pipeline to finish (CTRL+C). Additionally the following pipeline produce two identical files: gst-launch-1.0 videotestsrc ! jpegenc ! qtmux streamable=true ! filesink location=/tmp/test1.mov gst-launch-1.0 videotestsrc ! jpegenc ! qtmux streamable=false ! filesink location=/tmp/test.mov so streamable property make no difference, using matroskamux instead of qtmux produce, as expected, file with different sizes, setting streamable=true produce a smaller file (no index) and the file is playable while the pipeline is still writing to the file. I don't know if this is a isomp4 limitation, if so streamable property should be removed from qtmux
Confirmed with git master, it seems like streamable does not cause the correct headers to be generated anymore.
What are you trying to achieve with qtmux? The streamable property seems to only make sense to be used when fragmented output is enabled.
for example use qtmux to write to a socket (that is not seekable), matroskamux support this use case properly
Are you streaming it 'live'? isomedia (qt / mp4 / ...) aren't suitable for live streaming unless you are using the fragmented version. It can be streamable, but not live, if you enable the fast-start mode. In this mode it will write the headers first (at the cost of writing data to a temp file and pushing it all at the end) and the resulting file can be played as it is downloaded. Without fast-start, the file has the headers in the end, making players only able to start playback when they reach the end of the file.
yes I'm streaming live, I'll stay with mkv, however streamable property seems useless for qtmux, maybe could be removed, Nicola
Does it work for you if you use faststart=true?
no: gst-launch-1.0 -e videotestsrc ! jpegenc ! qtmux streamable=true faststart=true ! filesink location=/tmp/test.mov test.mov is not playable until I hit CTRL+C
Without streamable, ignore that. gst-launch-1.0 -e videotestsrc ! jpegenc ! qtmux faststart=true ! decodebin ! xvimagesink works fine here.
this does't work for me: gst-launch-1.0 -e videotestsrc ! jpegenc ! qtmux faststart=true ! filesink location=/tmp/test.mov gst-launch-1.0 playbin uri=file:///tmp/test.mov Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Stream contains no data. Additional debug info: gsttypefindelement.c(1038): gst_type_find_element_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: Can't typefind empty stream ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... if you try the same with matroskamux streamable=true it will work fine and you'll be able to write a streamable mkv file over a network socket
Confirmed, it only worked for me because at EOS (num-buffers=1000 above) the complete file is pushed downstream. Apparently the faststart=true property on qtmux still lets it write to a temporary file and only on EOS push everything downstream. No data is pushed out of qtmux before EOS. This is a regression from 0.10 at least.
The mp4 spec doesn't not support streaming at all, it's only supported for fragmented mp4 and using a protocol like DASH or Smooth Streaming, therefore it should only be available for mp4dashmux and ismlmux. I propose deprecate the streamable property and make it only available for mp4dashmux and ismlmux. The muxer also queries if downstream is seekable, setting streamable=FALSE, which is not correct either. If it's regular mp4 and downstream is not seekable, the only option is to use faststart=TRUE becuase we can't rewrite the headers. For ffmp4, if dowsntream is not seekable and faststart=FALSE than the only option is to use streamable=TRUE. For ffmp4 I would set by default streamable=TRUE, because it's the regular scenario for DASH and Smooth Streaming. streamable=FALSe is only used to create ffmp4 files that can be used with manifest/playlist, including the moof's index box.
(In reply to comment #11) > ffmp4 files that can be used with manifest/playlist, including the moof's index > box. That can be used *without* manifest/playlist
(In reply to comment #11) > The muxer also queries if downstream is seekable, setting streamable=FALSE, setting streamable=TRUE
I was mid writing, but Andoni was faster and I agree with his suggestions. Just for clarification: fast-start makes qtmux create a 'fast start' file, making it put the headers at the beginning instead of putting them at the end. To be able to do this it saves all media data to a temporary file and only pushes everything downstream on EOS. That's when qtmux is able to generate headers with the full information about the samples. The only option to stream isomedia live is to use fragmented versions, as Andoni pointed out.
Created attachment 255084 [details] [review] qtmux: deprecate the streamable property for non-fragmented MP4 The streamable property only makes sense for fragmented MP4.
Created attachment 255085 [details] [review] qtmux: make "streamable" TRUE as default The most common use case for fragmented MP4 (Dash and Smooth Streaming) is producing streamable content (even for VOD). streamable=FALSE would only be used to generate fragmented MP4 with and index of MOOF's that could be reproduced without a playlist/manifest
Created attachment 255086 [details] [review] qtmux: handle issues correctly when downstream is not seekable The streamable property only make sense for fragmented formats. For regular MP4, when downstream is not seekable we can't rewrite the headers, so qtmux can only work with fast-start=TRUE, where the headers are written finishing the file. For fragmented MP4, when streamable is not seekable and the streamable property is FALSE, we must enforce streamable=TRUE warning the user about this change
Comment on attachment 255084 [details] [review] qtmux: deprecate the streamable property for non-fragmented MP4 Additionally set_property should probably not do anything for the deprecated case. Can you add that?
Comment on attachment 255085 [details] [review] qtmux: make "streamable" TRUE as default Should only be TRUE for the fragmented formats by default, right?
Created attachment 255314 [details] [review] qtmux: make "streamable" TRUE as default The most common use case for fragmented MP4 (Dash and Smooth Streaming) is producing streamable content (even for VOD). streamable=FALSE would only be used to generate fragmented MP4 with and index of MOOF's that could be reproduced without a playlist/manifest
Created attachment 255316 [details] [review] qtmux: make "streamable" TRUE as default The most common use case for fragmented MP4 (Dash and Smooth Streaming) is producing streamable content (even for VOD). streamable=FALSE would only be used to generate fragmented MP4 with and index of MOOF's that could be reproduced without a playlist/manifest
That won't apply in current master, let me rebase them first
Created attachment 255324 [details] [review] qtmux: deprecate the streamable property for non-fragmented MP4 The streamable property only makes sense for fragmented MP4.
Created attachment 255325 [details] [review] qtmux: make "streamable" TRUE as default The most common use case for fragmented MP4 (Dash and Smooth Streaming) is producing streamable content (even for VOD). streamable=FALSE would only be used to generate fragmented MP4 with and index of MOOF's that could be reproduced without a playlist/manifest
Created attachment 255326 [details] [review] qtmux: handle issues correctly when downstream is not seekable The streamable property only make sense for fragmented formats. For regular MP4, when downstream is not seekable we can't rewrite the headers, so qtmux can only work with fast-start=TRUE, where the headers are written finishing the file. For fragmented MP4, when streamable is not seekable and the streamable property is FALSE, we must enforce streamable=TRUE warning the user about this change
Created attachment 255327 [details] [review] qtmux: handle issues correctly when downstream is not seekable The streamable property only make sense for fragmented formats. For regular MP4, when downstream is not seekable we can't rewrite the headers, so qtmux can only work with fast-start=TRUE, where the headers are written finishing the file. For fragmented MP4, when streamable is not seekable and the streamable property is FALSE, we must enforce streamable=TRUE warning the user about this change
Still doesn't fix the original bug though, there's something wrong with the fast-start handling. This never prerolls: gst-launch-1.0 -e videotestsrc ! jpegenc ! qtmux faststart=true ! decodebin ! xvimagesink with num-buffers=100 it prerolls after the 100 buffers are encoded. Thiago?
Nevermind, missed Thiago's explanations. It's all good now :)