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

[Ivan Kalvachev]

On 6/30/05, Gaetan SEMET <gsem01 at freescale.com> wrote:
> 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
> 

cache-min and cache-prefill are swapped in meaning, and one of them is
not used at all.

Anyway, it seems much more probable that you are not using cache at
all. It could be caused by troubles with fork (less likely, all unix
should have it) or with share memory (MPlayer support 3 styles of it,
last time I checked).

When MPlayer is started you must see how buffer is filled to 20%
before playback starts.

  Ivan Kalvachev
 iive