[MPlayer-users] Problem with -ao pcm:file option

[Matthew Kwan]

Thanks for the advice Reimar.

>A large -autosync value should make the video smooth.

It didn't seem to make any difference. I cranked it up to 10000, but no
luck.

>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.

>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?

>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.

>Lastly, you could provide a sample so the FFmpeg bug can be fixed and
>you can use that.

I'll probably do that. But it won't get the problem fixed by Monday's
deadline. And the fix won't appear in an FC7 RPM ...

Regards,


mkwan