[MPlayer-users] SBLive + AC3 Potential Solution

[Aubin Paul]

> no one of the developers have ac3 decoder hardware, so we cannot fix it.
> it's know that it doesn't work with sblive. it works wiht some other
> cards, so maybe the code is ok, maybe some sblive specific thing isn't 
> ok.
> i've applied few patches about a month ago, try cvs, may help.

I'm running the CVS versions (I have a script that rebuilds my Debian 
packages nightly ;) I fixed dec_audio.c to use the new ac3-iec958.* 
code, but that doesn't help either. It's definitely an A-V sync problem.

> but again: don't bugreport hwac3. send patches.
> we can't fix bugs as we never could test it. we can only accept patches.
> (and donations :)

Understood. Could I ask a couple of questions though?

Mainly, the only issue I'm seeing the super slow video. It's clearly the 
sync being thrown off, as it's not a lack of CPU power. This is probably 
a bigger question than I think, but how can I send sync ticks back to 
mplayer?

>> not easy, as mplayer have to know the exact a-v delay. with a pipe, 
>> it's not
> | possible, and you may have to manually adjust delay all time :(

The main reason I bring it up, is because using the -dumpaudio command 
gives a proper AC3 output file, and using -ao null seems to keep the 
audio in sync while the AC3 file is playing.

Something like this would work:

mplayer -vo mga -ao null -dumpaudio:"|play-ac3" mydivx_with_ac3.avi

If dumpaudio could redirect to a pipe in this manner, the video problem 
would be handled by the null audio driver, and the actual playing of the 
AC3 file could be handled via the play-ac3 program which is known to 
work. It's not the perfect solution, but it would make AC3 work on 
SBLive.

But before I try to get -dumpaudio to write to a pipe, would this 
solution even work?

Aubin