[MPlayer-users] Problem with -ao pcm:file option
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Thu May 14 15:57:35 CEST 2009
On Thu, May 14, 2009 at 11:26:26PM +1000, Matthew Kwan wrote:
> >audio will always be written in chunks of 64 kB. While it's silly you
> >could change the audio to 2 channels / 48kHz and you'd get a piece of
> >audio about every 0.6 seconds.
>
> Nice in theory, but our server is under enough load already, so I'd
> rather not be encoding and passing around extra megabytes of audio.
> And for smooth video we'd really like updates every 0.1 seconds.
We're talking about resampling and processing 100 kB/s (certainly not
encoding) or if you want 0.1 seconds that 600 kB/s. Also it is a simple
way to test which of the possible solutions might work out for you.
> >Change ao_pcm to calculate get_delay correctly would make the video
> >smooth (but as said, -autosync should do that already).
>
> I think this will be the option we go with. Much as I dislike having
> to maintain a custom binary, at least it gives us the opportunity to
> unconfigure all the video and audio output libraries that really
> shouldn't be installed on our rack-mounted machine.
>
> What do you think would be the best option -
> 1) simulate a continually draining output buffer with a call to
> gettimeofday in the get_space() function?
> 2) use select calls to check if the fifo would block in the get_space()
> function, and use the process on the other end to control the rate?
As I said, this only makes the video smooth, it doesn't solve any of the
other issues.
Changing ao_data.outburst = 65536; to ao_data.outburst = ao_data.bps / 16
(and of course moving it below where ao_data.bps is calculated) might work
better.
> >Or you could probably use e.g. ao_jack and grab the audio via that
> >framework.
>
> It might work, but it sounds a bit too convoluted to be maintainable.
Strange thing to say considering that the overall solution you consider
basically will depend on MPlayer internals (e.g. it will write the data
to the FIFO with the right timing) while jack was essentially created
for that kind of thing (passing audio between applications with proper
timing).
More information about the MPlayer-users
mailing list