Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
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
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
"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
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
[deleted comment]
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
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
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
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
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
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
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
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
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
Here is the firefox log.
Original comment by schn...@gmail.com
on 8 Jan 2010 at 7:17
Attachments:
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
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
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
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
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
Original issue reported on code.google.com by
schn...@gmail.com
on 7 Jan 2010 at 2:03