GNOME Bugzilla – Bug 587426
non fast-start mov files fail to play from http locations
Last modified: 2009-07-08 09:34:15 UTC
Please describe the problem: i wanted to play a stream of german public law tv station with playbin2 but it fails. when wget'ing the whole file and playing it locally, it works. bilboed said the problem is a missing fast-start header. Steps to reproduce: 1. gst-launch playbin2 uri=http://tagesschau.vo.llnwd.net/d3/video/2009/0624/TV-20090624-1330-3201.h264.mp4 Actual results: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... WARNING: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0: No volume control found Additional debug info: gstplaysink.c(1491): gen_audio_chain (): /GstPlayBin2:playbin20/GstPlaySink:playsink0: Volume/mute is not available New clock: GstDVBAudioSinkClock Got EOS from element "playbin20". Execution ended after 357822000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... 0:00:01.536403000 1286 0x100b6118 INFO typefind gsttypefindelement.c:165:gst_type_find_element_have_type:<typefind> (null) 0:00:01.540674000 1286 0x100b6118 WARN qtdemux qtdemux.c:2569:gst_qtdemux_chain:<qtdemux0> Unknown fourcc while parsing header : ftyp 0:00:14.695901000 1286 0x100b6118 WARN qtdemux qtdemux.c:2569:gst_qtdemux_chain:<qtdemux0> Unknown fourcc while parsing header : free Expected results: automatically queue up the entire file, if that's necessary and then play. Does this happen every time? yes Other information:
What I meant is that if the main header was at the beginning (aka fast-start files), it could start playing straight away. *REGARDLESS* of that... once the file is stored and we hit the headers... we should be able to playback the file.
it actually does download all of the input file... 0:00:13.058877000 948 0x10047188 DEBUG qtdemux qtdemux.c:2499:gst_qtdemux_chain:<qtdemux0> pushing in inbuf 0x2d04e2d0, neededbytes:3638959, available:3641320 ... 0:00:15.708794000 948 0x10047188 DEBUG qtdemux qtdemux.c:2499:gst_qtdemux_chain:<qtdemux0> pushing in inbuf 0x2cfb84b8, neededbytes:1153133, available:1153337 ... qtdemux qtdemux.c:2499:gst_qtdemux_chain:<qtdemux0> pushing in inbuf 0x2cfa5b88, neededbytes:55141, available:57540 ... 0:00:15.864869000 948 0x10047188 DEBUG qtdemux qtdemux.c:2499:gst_qtdemux_chain:<qtdemux0> pushing in inbuf 0x2cfa5678, neededbytes:55891, available:55891 this sums up to 4903124 bytes and the downloaded file size is 4903156 i think the problem might be this: 0:01:23.522813000 948 0x10047188 LOG qtdemux qtdemux.c:2456:next_entry_size:<qtdemux0> stream 0 offset 32 demux->offset :4792116 0:01:23.524226000 948 0x10047188 DEBUG qtdemux qtdemux.c:2469:next_entry_size:<qtdemux0> There wasn't any entry at offset 4792116 0:01:23.526322000 948 0x10047188 LOG qtdemux qtdemux.c:1193:gst_qtdemux_handle_sink_event:<qtdemux0> handling eos event
But the problem is that the source is not seekable and when it is done with downloading and found the headers, it does not have the data anymore. As Edward said, it would be nice to just start to decode when we hit the data parts. But I don't know right now, if there is something that we need to know in order to play which is in the moov atom (gogle is useless when wanting to know about this damn fileformat).
The problem here is that the file contains 3 mdat atoms, one of which seems to contain all audio data, the other all video and the other just empty (which would not play very efficiently even in pull mode, and confuses current push mode). Anyway, following fixes push mode to handle more complicated atom layouts. commit a4d586daac5e454d008fd33086abf775fdc39e19 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Jul 7 15:57:55 2009 +0200 qtdemux: perform some more (careful) data buffering Once buffering has started (with an mdat atom), continue buffering until moov atom is reached, which handles cases with multiple mdat atoms. Also keep adapter/offset better in sync with upstream and fix some debug statements. Fixes #587426.