Running out of Buffer requires streams to be played from the beginning

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a divx stream
2. Play the stream
3. Provocate buffer underrun (cut internet connection or the like)

What is the expected output? What do you see instead?
When running out of buffer gecko-mediaplayer should "pause" the stream on
that position and wait until the buffer fills again. Instead the stream
"stops" and i have to watch from the beginning. Thats especially bad when
its not possible to seek within the stream.

What version of the product are you using? On what operating system?
0.9.8 debian squeeze/sid

Original issue reported on code.google.com by schn...@gmail.com on 7 Jan 2010 at 2:03

[GoogleCodeExporter]

No, if the stream goes offline, canceling the download is correct thing to do.
Firefox, ftp, wget all of these tools end the download when the internet 
connection
breaks and you must re-request the data to get it again.

Original comment by kdeko...@gmail.com on 7 Jan 2010 at 1:49

• Changed state: WontFix

[GoogleCodeExporter]

I have choosen the wrong words for what i actually want to say. I think its 
correct
to stop the stream when there is absolutely no internet connection any more. The
problem is that it´s up to me to estimate when to start a stream already or 
not. For
example: Average stream has 90 min. runtime at 700 mb what means that it would 
be
132.74 kb/s bandwidth. It´s not uncommon to download a stream just at 100kb/s 
or even
less. In that case i let the stream buffer quite some time to the point where i
estimate its enough to start watching. I sometimes run out of buffer at 70%. At 
this
point i have to restart the stream again or wait until the last part finishes 
to be
able to seek to the last position.

Here is my suggestion:
If the stream runs out of buffer while playing AND there is no more incoming 
Data for
$TIMEOUT time, the stream should stop.

If the stream runs out of buffer while playing BUT there is incomming Data, the
stream should just pause.

I think this is quite reasonable.

Original comment by schn...@gmail.com on 7 Jan 2010 at 3:24

[GoogleCodeExporter]

I don't know what size you have your buffer set to, but the caching mechanism is
designed so that the media playback should pause when the playback position is
approaching the cache buffer. The stream normally starts when 20% of the media 
size
is reached or when 2* the cache size is buffered. 

Original comment by kdeko...@gmail.com on 7 Jan 2010 at 3:52

[GoogleCodeExporter]

gnome-mplayer -> Preferences -> MPlayer "Enable mplayer cache" is set to 2000.

gnome-mplayer -> Plugin -> Cache Size is set to 2000

With the avg. 700mb 90 min media 2000kb would be ~14 seconds playback. It would 
be
completely fine if mplayer would pause when the buffer gets too low.

Original comment by schn...@gmail.com on 7 Jan 2010 at 4:48

[GoogleCodeExporter]

What I am saying is that is should pause while the buffer is being filled. What
version of gecko-mediaplayer/gnome-mplayer are you using?

Original comment by kdeko...@gmail.com on 7 Jan 2010 at 4:53

[GoogleCodeExporter]

Yes, it does so on the beginning of the stream. It fills the buffer and then 
fire up
play. But this is only working on the beginning. If the buffer gets empty while
playback the stream stops, no matter what. Instead the stream should go into 
"pause"
mode and wait to refill the buffer in case there is data to be processed.

Im using the latest version available on debian squeeze/sid which is 0.9.8-1 and
mplayer 1.0.rc2svn20091220-0.0

Original comment by schn...@gmail.com on 7 Jan 2010 at 5:15

[GoogleCodeExporter]

Set your cache to a higher value, if the media plays longer then mplayer is not
re-reading the EOF marker (I've seen it have problems with this in the past). 
If that
is the case then a bug will need to be opened with the mplayer team. 

Original comment by kdeko...@gmail.com on 7 Jan 2010 at 5:56

[GoogleCodeExporter]

To be concrete. I will increase the buffer size to 16 Mb. After that i start a 
stream
and let the buffer fill to 32 Mb. When the bitrate of the stream is twice as 
much as
the download rate i will soon trap into a buffer underrun.

So which behavoir is expected:

1. Mplayer plays as long as the buffer size is > 16 Mb and pausse if buffer 
size is <
16Mb.

2. Mplayer plays as long as there is _any_ buffer left. If buffer = 0 stop 
stream.

I can tell for sure that the second case is the current situation on my 
computer. If
you tell me the first behavoir is expected i will file a bugreport for mplayer.

Original comment by schn...@gmail.com on 7 Jan 2010 at 10:02

[GoogleCodeExporter]

mplayer does not do any pausing, the pausing is controlled by
gecko-mediaplayer/gnome-mplayer. The problem is that mplayer when launched sees 
the
file size as the file size when mplayer is launched. The file keeps growing but
mplayer does not detect this, so when it reads the byte at the end of the 
original
size, mplayer quits. That is the problem and it does happen with divx media, 
but not
all media types. gnome-mplayer never decides to pause the playback, because it 
has
enough cache of the file since it knows where mplayer is in the file and how 
much has
been downloaded.

Original comment by kdeko...@gmail.com on 7 Jan 2010 at 11:54

[GoogleCodeExporter]

"The problem is that mplayer when launched sees the
file size as the file size when mplayer is launched. The file keeps growing but
mplayer does not detect this, so when it reads the byte at the end of the 
original
size, mplayer quits."

The problem is non existant here. When i start watching a stream which first 32 
Mb
are buffered, i can watch beyond the 32 Mb without issues.

Please tell me if this is possible

gecko-mediaplayer plays as long as the buffer size is > 16 Mb and pausse if 
buffer
size is <
16Mb.

Thats it. Just "pause" when the stream runs out of buffer. And not just in the
beginning to fill the buffer. 

Original comment by schn...@gmail.com on 8 Jan 2010 at 5:22

[GoogleCodeExporter]

Do you have a site that I can test? 

the way the cache works is that when the media position is within 5% of the 
cache
size unless the cache is 100%, the media playback will pause until the cache 
size is
20% greater than then media position.

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 2:13

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Could it be that gecko-mediaplayer ignores cache? The first stream in Post #12 
has
350 Mb. The cache is set to 16336 which would be 4.4 % of the stream. But
gecko-mediaplayer starts playing the stream at >1% which means that the buffer 
is not
filled.

Original comment by schn...@gmail.com on 8 Jan 2010 at 5:09

[GoogleCodeExporter]

I tried both of those sites and they tell me I don't have the DiVX player 
installed.
Do you have any patches applied to make that site work?

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 5:13

[GoogleCodeExporter]

Ok, I did some tests with the duckload site and while it does start right away 
and
then stop, you can click the pause button and it will start playing again. Then 
when
the cache gets low, it will cache until there is a 20% buffer from the current 
point
and start playing again. So other than the startup issue, it seems to be 
working as
designed. 

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 5:26

[GoogleCodeExporter]

No, just Firefox 3.5.6 ( resp. Iceweasel). epiphany-webkit refuses to play the 
stream
with the same message of yours.

Original comment by schn...@gmail.com on 8 Jan 2010 at 5:27

[GoogleCodeExporter]

Webkit has problems with the firefox plugins, so we need to only test with 
firefox.

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 5:29

[GoogleCodeExporter]

The stream starts right away but dont stop like you describe. When 1% buffer is
filled the stream starts playing to the point where it runs out of buffer and 
then
just stops. So you dont experience such behavoir?

Original comment by schn...@gmail.com on 8 Jan 2010 at 5:31

[GoogleCodeExporter]

I have to correct myself. It does indeed "Pause" after 1% but that depends on 
the
cache size. But there is still the problem with the stopping streams.

Please follow this steps:

1. Open a stream on duckload
2. Wait until 1% is buffered.
3. Press Play ( no matter what the cache size is, if you press play after 1% the
stream will start playback)
4. Watch until the buffer gets empty

What happens now?
On my box the stream just stops and i have to rewatch. The stream wont resume 
from
the last position viewed when hitting play again.

Original comment by schn...@gmail.com on 8 Jan 2010 at 5:48

[GoogleCodeExporter]

1. open stream on duckload
2. wait until background turns from "gtk background color, grey on my machine" 
to black
On my machine this even is caused by the amount downloaded being double the 
cache size. 

3. gnome-mplayer is in paused state
4. click on pause icon, media starts to play, it will play for a couple of mins 
and
then go into paused state, it will fill a 20% buffer and then continue playing 
from
then on playback is fine.
5. Try to seek, does not work because mplayer emits this

ERROR: Cannot seek in raw AVI streams. (Index required, try with the -idx 
switch.)

This is due to mplayer not having the index because it is at the end of the 
media. If
I add the -idx to the mplayer command line, then media stops early due to badly
formed index due to partially downloaded file when mplayer starts to play.

Please try SVN of both gecko-mediaplayer and gnome-mplayer to see if you can
duplicate this scenario. And then post the logs that are generated from the 
terminal
where you run firefox. You may need to enable verbose debugging in 
gnome-mplayer as well.

Still not sure why it pauses right away as it does not do that with other media.

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 6:13

[GoogleCodeExporter]

I have found out, that my sample stream on duckload never plays until i manually
press "pause". But the stream from mystream.to will start automatically. So it
depends somehow on the hoster of the stream.

Anyway i will try to follow your steps with the svn versions.

Original comment by schn...@gmail.com on 8 Jan 2010 at 6:49

[GoogleCodeExporter]

Here is the firefox log.

Original comment by schn...@gmail.com on 8 Jan 2010 at 7:17

Attachments:

• firefox.log

[GoogleCodeExporter]

Looks like you have a 2K cache in use

Setting to play because 4260960 > 4259840 (double cache)
Entering list_parse_qt localsize = 4260960

You can adjust this cache in the Edit->Preferences->Plugin in gnome-mplayer. 
This is
the same thing I am getting. If a larger cache fixes it, it is probably due to 
the
way the media was encoded.

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 7:25

[GoogleCodeExporter]

I´ve changed the cache quite often with version 0.9.8 but not with the svn 
version.
You are right! Setting the cache to 4560 solved the EOF problem. Now its like 
you
describe it in post #20. So this issue will be fixed in the next final version i
guess. When can i expect a new release from both gnome-mplayer and 
gecko-mediaplayer?

The last question i have is what you guess how the official divx player handle 
to
seek within streams when the index is at the end.

Thank you very much for the time you spent on resolving this issue. Keep up the 
good
work!

Original comment by schn...@gmail.com on 8 Jan 2010 at 8:21

[GoogleCodeExporter]

I have found the real issue. In gnome-mplayer -> preferences -> MPlayer cache 
must
not be enabled. Only on the "Plugin" section. If i enable MPlayer cache i have 
the
"stop" stream situation i described here. If i disable MPlayer cache it works 
like
you post in #20.

Original comment by schn...@gmail.com on 8 Jan 2010 at 8:39

[GoogleCodeExporter]

Ah you didn't mention that, normally the plugin makes the right decision as to 
when
to using the mplayer cache. I think it has been discussed several times that if 
you
enabled that you are taking a risk that things may not work.

Original comment by kdeko...@gmail.com on 8 Jan 2010 at 8:58

[GoogleCodeExporter]

thanks for the post schnolt. Actions you've described resolved my issue. 

Original comment by shime.fe...@gmail.com on 22 Sep 2010 at 10:56