[MPlayer-dev-eng] force lavf demuxer for rtmp?

[Howard Chu]

Reimar Döffinger wrote:
> On Sun, Mar 21, 2010 at 09:13:47PM -0400, compn wrote:
>> it seems rtmp always uses flv (afaict?), it speeds things up to add
>> mplayer -lavfdopts format=flv -demuxer lavf in front of any rtmp stream.
>>
>> i guess a large enough -cache would also help the probe find things quicker.
>> just seems like it freezes for a while instead of playing if too small a cache is utilized.
>>
>> example stream:
>> mplayer -lavfdopts format=flv -demuxer lavf ffmpeg://rtmp://cp82346.live.edgefcs.net:1935/live?ovpfv=1.1/CSPAN1@14845
>
> Huh? The flv probe function only needs the first 10 bytes and the returns the
> maximum score, any cache size should be good enough, and actually the stream buffer
> should be enough as well - it just may be it is not used fully currently.
> I won't accept any hacks for this until it is understood why they are needed, they
> definitely should not be.

It definitely starts up more slowly without that hack. The probe may only need 
10 bytes, but it always reads 32KB to get started, and then somewhere down the 
line the demux seeks back to zero to actually do real work. One key problem 
with all this, which I've been trying to get attention on, is that everything 
in mplayer/ffmpeg operates on byte offsets, but RTMP only operates on 
timestamps. I hacked around this particular issue in one version of my patch 
by accepting seek(0), since we can also seek to timestamp 0 in that case.

But yes these are just ugly hacks, and proper support for time-based seeks 
doesn't seem to really exist yet.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/