GNOME Bugzilla – Bug 631430
[flvdemux] Cannot play .flv to the end
Last modified: 2011-11-25 16:05:39 UTC
gst123 and Amarok using the gstreamer plugin cannot play the .flv of http://www.youtube.com/watch?v=8wxOVn99FTE (that can be downloaded using http://bitbucket.org/rg3/youtube-dl/wiki/Home ) to its end - they stop in the middle. xine and mplayer (and I believe VLC too) play it fine. I'm uploading the offending .flv file to my web-site and will give a URL. I'm on Mandriva Linux Cooker on a Pentium 4 2.4 GHz machine.
OK, now I tried it in VLC and it plays fine, and the offending .flv can be found here: http://www.shlomifish.org/Files/files/video/gst-bug-631430/ Regards, -- Shlomi Fish
Oh, and its sha256sum is: 45faa0eba89337df01f0961f9d7a3350735989cde4b02fe71c58d88e31b01399 8wxOVn99FTE.flv Regards, -- Shlomi Fish.
It's 4:10 minutes long and seems to play all the way to the end with git here. Tested with playbin2 and seek.c.
(In reply to comment #3) > It's 4:10 minutes long and seems to play all the way to the end with git here. > Tested with playbin2 and seek.c. I used youtube-dl to get the current one. The one at shlomifish.org has the right sha256sum and stops in the middle indeed.
The file has wrong timestamps, they reset back to 0 in the middle of the file.
(In reply to comment #4) > (In reply to comment #3) > > It's 4:10 minutes long and seems to play all the way to the end with git here. > > Tested with playbin2 and seek.c. > > I used youtube-dl to get the current one. The one at shlomifish.org has the > right sha256sum and stops in the middle indeed. Hi Wim, Some people on #gstreamer and I tried using youtube-dl on the URL and got at least 4 different sha256sums (one of them twice from the same client host). I don't see why youtube-dl and/or youtube would return different contents each time, but it seems to. Regards, -- Shlomi Fish
Can this still be reproduced with a fresh download of the file? it could be that there was a corrupt file for a moment.
@Wim : a fresh download from youtube.com using youtube-dl from a different host plays fine till the end. However, the file on http://www.shlomifish.org/Files/files/video/gst-bug-631430/ , does not play fine well with gstreamer, but plays fine on xine, mplayer or VLC.
Indeed: tpm@zingle:~/gst/git$ gst-launch-0.10 playbin2 uri=file:///home/tpm/samples/631430-8wxOVn99FTE.flv audio-sink=fakesink video-sink='progressreport ! fakesink' ... progressreport0 (00:00:05): 44 / 250 seconds (17.6 %) progressreport0 (00:00:10): 93 / 250 seconds (37.2 %) progressreport0 (00:00:15): 11 / 250 seconds ( 4.4 %) progressreport0 (00:00:20): 58 / 250 seconds (23.2 %) progressreport0 (00:00:25): 105 / 250 seconds (42.0 %) progressreport0 (00:00:26): 116 / 250 seconds (46.4 %) Got EOS from element "playbin20". Execution ended after 25201634763 ns. There must be a timestamp wraparound at ca. 2 mins 10 secs or so. VLC shows 4:10 as duration, but then around position 2m10s goes back to showing 0m00s as position and counting up from there to the end.
So is this a case of "broken file in, broken playback out" and we don't care, or should that be fixed by detecting backwards timestamps and sending a new segment or something along those lines ?
I think it depends a bit on how cracktastic it turns out to be on deeper investigation, and how hard to fix. We can probably just detect the wraparound and maintain a timestamp "offset/base" of some sort (assuming there's max. 1 wraparound for now). If the flash player plays it, we should try to play it as well IMHO.
Created attachment 198124 [details] [review] flvdemux: detect large pts gaps and resync Should work on multiple gaps, but tested on only one.
commit cf3f3f14da6561223bf9f5d6bf1ff230526d40eb Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Mon Oct 3 17:50:43 2011 +0100 flvdemux: detect large pts gaps and resync Should work on multiple gaps, but tested on only one. https://bugzilla.gnome.org/show_bug.cgi?id=631430
Thanks for fixing this bug.
This commit breaks seeking + duration stuff for me with most other flv files, re-opening.
IMHO 2 seconds are quite small, does work if you chose 10 seconds or something on other files?
Created attachment 202071 [details] [review] flvdemux: fix seeking Which I accidentally broke when fixing flv videos breaking on spurious timestamp discontinuities in broken files.
Oops. Fixed :) The seeking was triggering the discontinuity detector. It was still working fine when seeking via navseek. Seeking works fine for my test case, which was broken before the patch. If you confirm it fixes your test case also, I'll push.
Comment on attachment 202071 [details] [review] flvdemux: fix seeking Definitely makes sense, even if it doesn't fix the bug Tim mentioned ;) Please push
It fixes seeking for me too, thanks!
commit 21d3faa40070b2ddc10a1c572bd4d4a7dd28af39 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Nov 24 16:31:38 2011 +0000 flvdemux: fix seeking Which I accidentally broke when fixing flv videos breaking on spurious timestamp discontinuities in broken files. https://bugzilla.gnome.org/show_bug.cgi?id=631430