[MPlayer-dev-eng] [PATCH] Radio support for MPlayer
Vladimir Voroshilov
voroshil at univer.omsk.su
Fri Jul 14 08:48:35 CEST 2006
Reimar Döffinger пишет:
>Well, there are the MP_CMD_SET_PROPERTY and MP_CMD_GET_PROPERTY which
>are special commands to modify all kinds of "properties". I don't know
>this stuff well, so maybe it isn't suitable, but you might want to have
>a look at it anyway.
>
>
>
I is not suitable here, but can be used to set "rawaudio rate=" property
automatically.
>Actually... No, just return whatever data you have (maybe sleeping a bit
>if it's really very little data, just test that it never uses and insane
>amount). Well, actually you should also make sure it is aligned at a
>sample boundary (i.e. len is divisible by number of channels multiplied
>by number of bytes per sample), otherwise MPlayer might break thinks when e.g.
>resampling.
>I was mostly saying this because I think (and a closer look at
>demux_rawaudio seems to confirm) that this is where your problem lies.
>If you return data for less than one second of audio demux_rawaudio will
>accept that happily and return for more much earlier.
>
>
Please, can you point me on a peace of code where demux_rawaudio decides
to stop filling it's one second buffer even it not full?
I have tryed to find something like this in demux_rawaudio.c, stream.c,
stream.h,cache2.c but could find nothing.
>I guess the people doing binary build would be happy if they could build
>in support for both. But that really is just a very minor
>"nice-to-have".
>
>
>
I'll try to do it after solving fill buffer problem.
>Sure. I guess I've said it often enough, but when reviewing I don't try
>to full understand everything, so if something I say doesn't make sense
>to you that could be because it really doesn't make sense :-)
>It just looked to me like you were implementing some kind of cache
>(probably to avoid initial stuttering or so?), and in that case the -cache
>option could probably provide the same functionality while being more
>flexible. Disadvanteg is of course that the user has to know about it and
>use it.
>
>
preload parameter will be removed.
>Greetings,
>Reimar Döffinger
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>
>
>!DSPAM:44b69335221233718222520!
>
>
>
--
Regards,
Vladimir Voroshilov mailto:voroshil at univer.omsk.su
Omsk State University
JID: voroshil at jabber.ru
ICQ: 95587719
More information about the MPlayer-dev-eng
mailing list