[MPlayer-users] Peer Test: Apple.com Tailer video. Problem of initi second replay in loop?

[RainerStroebel at t-online.de]

Hello Kevin,

-----Original Message-----
> Date: Tue, 17 Jul 2007 19:52:21 +0200
> Subject: Re: [MPlayer-users] Peer Test: Apple.com Tailer video.
> Problem of initi second replay in loop?
> From: Kevin DeKorte 
> To: "MPlayer usage questions, feature requests, bug reports"
> 

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> RainerStroebel at t-online.de wrote:
> > 
> > MPlayer and the cache usage
> > ======================
> > 
> > 
> > By the usage of MPalyer I have notice:
> > 
> > 1.  The  execution  of the program result in usage of  cache with
> > different sizes and  cache-min setting by program logic.
> > 
> > 2. In the testcase above the program logic does not assign an amount
> > of cache buffer and an cach-min value  > 0 setting.
> > 
> > 3. The default setting of values for cache size and cache-min can /
> > could  depending of the task, the CPU type and the bandwidth by 
> > program logic  does make sense to me.
> > 
> 
> That is 100% correct. It is up to you, as a user, to be able to figure
> out your proper cache setting when using mplayer directly. Usually if
> you have problems, set the value higher.
> 

For different tasks  MPlayer program logic assigns diffenrent values for
cache:

e.g execute MPlayer without any cache option setting by the user

1. Example

mplayer "rtsp://video.rootvision.net/1.rm?start=53:80"
  
--> snip 

Playing rtsp://video.rootvision.net/1.rm?start=53:80.
Resolving video.rootvision.net for AF_INET...
Connecting to server video.rootvision.net[212.111.95.96]: 554...
Cache size set to 640 KBytes
Cache fill: 18.75% (122880 bytes)
REAL file format detected.

---> snip

2. example

mplayer.exe http://208.53.131.29:8080 
MPlayer dev-SVN-r23698-OS2-3.3.5 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) III Mobile CPU      1133MHz (Family: 6, Model:
11, Stepping: 1)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled with runtime CPU detection.

Playing http://208.53.131.29:8080.
Connecting to server 208.53.131.29[208.53.131.29]: 8080...
Name   : liveIreland, Independent Irish and Celtic Music  From Dublin,
Ireland.
Genre  : Folk Celtic Irish
Website: http://www.liveireland.com
Public : yes
Bitrate: 56kbit/s
Cache size set to 320 KBytes

Cache fill:  0.00% (0 bytes)   
Cache fill:  0.00% (0 bytes)   
Cache fill:  0.00% (0 bytes)   
Cache fill:  0.00% (0 bytes)   
Cache fill:  0.00% (0 bytes)   
Cache fill:  0.00% (0 bytes)   
Cache fill:  2.50% (8192 bytes)   
Cache fill:  2.50% (8192 bytes)   
Cache fill:  2.50% (8192 bytes)   
Cache fill:  7.50% (24576 bytes)   
Cache fill:  7.50% (24576 bytes)   
Cache fill:  7.50% (24576 bytes)   
ICY Info: StreamTitle='The Bridies - Fanny
Power';StreamUrl='http://www.liveireland.com';

Cache fill: 15.00% (49152 bytes)   
Cache fill: 15.00% (49152 bytes)   
Cache fill: 15.00% (49152 bytes)   
Audio file file format detected.


> 
> > 
> > This especially is  required, if  MPlayer is used in an Online
> > environment -
> > called form an Browser Plugin odr and Browser Extension.
> > 
> 
> Right now in mplayerplug-in and gecko-mediaplayer I set the cache to a
> 'default' value and then give the user the option to alter that
> setting.

Setting the cache to an default value  work  against this
 program logic.

Target:

1 .Gives MPplayer sufficient data  in cache work properly 

2. Do not  let the user wait  for the "Starting playback..."  longer
than absolutely nessary 


> Having better logic such as knowing when mplayer is about to run out
> of cache and then pausing playback until the cache reaches an
> acceptable level has always something I have thought about doing, but
> doing it right is a much harder issue, especially with all the
> different media types out there. Feedback from mplayer is better on
> some media types than others.
> 
> 
> > In this case an user action is not desired for special Mplayer
> > option setting .
> > 
> 
> mplayer cannot always make this decision due to websites not providing
> enough data or other factors.
>
Can the current implemented program logic improved to minimized user 
decisions / actions about cache size ?


>  Kevin

--> snip

kind  regards

Rainer