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
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
automatically queue up the entire file, if that's necessary and then play.
Does this happen every time?
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.
Author: Mark Nauwelaerts <email@example.com>
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.