[MPlayer-dev-eng] (libmad) decode_audio block decoding [ARM]

[Gaetan SEMET]

Joey Parrish wrote:

>On Wed, Jun 29, 2005 at 12:16:21PM +0200, Gaetan SEMET wrote:
>  
>
>>I'm trying to have mplayer working on a ARM9 board, and have a
>>problem with libmad to decode MP3 stream coming from network
>>(RTP multicast, using livemedia).
>>
>>Audio (mp3 using libmad) only works fine, Video only as well,
>>but as soon as they are played together, audio is played correctly,
>>but video is played far too slowly.
>>I've checked the source, and the problem comes from the call of
>>decode_audio in mplayer.c. It spends 0,6s decoding audio (and
>>most of the time it actually *waits" for all this data to come from
>>the network (so it's not a CPU overhead).). So, during these 0,6s,
>>it doesn't decode any video frame, and when it comes to decode
>>a frame, it finds it's in late so drop the frame and want to fill
>>the audio buffer again... and wait again 0,6s.
>>So I have audio that is played very fine, but the video is played...
>>1 frame per 0,6s.
>>    
>>
>
>Try -cache.  If you have slow media (network, for example) then you
>should be using it anyway.
>
>--Joey
>
>  
>
Hello.
I tred with -cache, even with -cache-min or -cache-prefill, it doesn't 
change anything.
Do you think it's a cache problem?
Does *this* cache is enabled for network streaming (I mean a file which 
network URL
is extracted from a SDP file)?
I've checked the liveMedia source, it seems to have an acceptable audio 
cache.
The thing is i don't have a slow media, I stream the video over a 
100Mbps ethernet
and there is no problem at all for video only (which requiere much much 
much larger
bandwidth). I've dropped to 15fps I've still this bug.
I think it's a "timing" problem, but i don't understand why sometimes 
the player
waits. I've reached deep into the code, and it seeam it hang around the 
call of
ds_fill_buffer(). This is called lot of time, most of the time it takes 
almost nothing
(40-80 µs using GetTimer()), but sometime it take 9000 (9ms).
I'm almost sure this comes from
getBuffer(demuxer, ds, False, ptsBehind);
in demux_rtp_fill_buffer() that is block when there is no RTP packet 
available, but
I don't understand why this strange behaviour?
Ok sound packet arrives regularly, but it's the role of the buffer to 
handle that.
Is it possible to increase the minimum level of data the buffer should have
before being able to start (-cache-min doesn't seem to change anything).

Thanks for all help

Gaetan