Playback only covers cached video at time of start; needs reset to play full video

[GoogleCodeExporter]

What steps will reproduce the problem?
--------------------------------------
1. Set a reasonably large cache (32M on my machine) to be able to see the 
effects.
2. Play a video (in my case, http://www.youtube.com/watch?v=5rDZc1ZYRCA in 
Chromium with ViewTube greasemonkey script, Full HD MP4 mode).
3. Watch the video.

What is the expected output? What do you see instead?
-----------------------------------------------------
Video should play until end (since the video finishes loading long before the 
playback gets decently far into the video; fast university internet is fast :)

Instead, the playback ceases at the point where the caching had reached when 
playback began.  Playback seems to hang up at that point, potentially reset to 
the beginning given enough time.  Seeking beyond that point in the stream sends 
the position back to the start, and in top, seems to terminate/crash mplayer.  
Initiating playback again seems to start a new mplayer process, which can play 
the entire video with free seeking.

What version of the product are you using? On what operating system?
--------------------------------------------------------------------
Problem noticed with version 1.0.5 (gecko-mp + gnome-mp, mplayer-vaapi 34578 on 
Arch 64).  Detailed testing above with SVN versions (gecko-mp SVN 502, gnome-mp 
SVN 2242, mplayer-vaapi 34578).

Please provide any additional information below.
------------------------------------------------
Mount option noatime is active on my system, along with a bind mount for my 
home directory; assuming that these are not relevant, but am willing to run 
tests if that seems to be relevant.

Attached stdout log from chromium with debug logging in gnome-mplayer enabled 
for such a sequence (playing the video with fresh cache up to stopping point, 
waiting some time, seeking past stop-point to trigger crash&restart, and 
playing video again, successfully this time).

Vaapi:gl output mode does not seem to be relevant; same behavior observed with 
gl output.

Mplayer cache is disabled for the tests above, and both audio+video plugin 
caches set to 32768KB.

Original issue reported on code.google.com by henrypt...@gmail.com on 10 Apr 2012 at 1:18

Attachments:

• chromium.log

[GoogleCodeExporter]

One more additional note: Behavior does not occur when running gnome-mplayer 
from commandline with url from log.

Original comment by henrypt...@gmail.com on 10 Apr 2012 at 1:25

[GoogleCodeExporter]

Ok, you are running into an mplayer issue that is seen with some media types. 
mplayer for some media types (typically AVI) will look at the length of the 
file when mplayer is started and only play to that point in the file. It does 
this because gecko-mediaplayer is copying the file to your local hard drive and 
then telling mplayer to start playing the file from the cached file. There are 
some patches on the mplayer mailing list that corrects this or you can use 
gecko-mediaplayer with caching disabled. This disables some of the features 
including saving the stream seeking.

playing the url directly from gnome-mplayer is like playing the file from 
gecko-mediaplayer with caching disabled.

Original comment by kdeko...@gmail.com on 10 Apr 2012 at 5:42

[GoogleCodeExporter]

Thanks, tried applying http://patches.libav.org/patch/18621/ (with a few typo 
fixes) to the recent mplayer-vaapi into a custom package, seems to work great 
even with the old 1.0.5's.  Thanks!

On a side note, it seems possible that issue 132 is related to this (at least 
on that issue, the sample video is far too short for the caching effect to be 
significant); makes sense that the issue appears primarily on Youtube and its 
giant videos.

Original comment by henrypt...@gmail.com on 11 Apr 2012 at 6:23

[GoogleCodeExporter]

Great and Issue 132 could definitely be related to this.  

Original comment by kdeko...@gmail.com on 11 Apr 2012 at 12:38

• Changed state: Done