[MPlayer-dev-eng] Re: [PATCH] TV & DXR3: mencoder works but mplayer does not

Jaroslav Tulach jtulach at netbeans.org
Sat Jan 4 20:32:35 CET 2003


> Jaroslav Tulach wrote:
 >
> Unfortunately, it doesn't work well with anything else than ao_SDL.
> 

I am sorry, I do not know what ao_SDL is (maybe 
http://www.mplayerhq.hu/DOCS/video.html#sdl ?). Btw. "sdl" is one of my 
disabled audio outputs, still I have found the patch useful.

> 
>> Problem description:
>>
>> mencoder -tv
>> on:driver=v4l:device=/dev/video0:width=384:height=288:forceaudio:forcechan=2:adevice=/dev/dsp
>> -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=900 -oac mp3lame -lameopts
>> cbr:br=32 -o Y.avi
>>
>> works fine, but
>>
>> mplayer -vo dxr3:noprebuf -ao oss:/dev/em8300_ma -tv
>> on:driver=v4l:device=/dev/video0:width=384:height=288:forceaudio:forcechan=2:adevice=/dev/dsp
>>
>> does not. The reason for this is that mplayer.c sets tv_param_immediate
>> = 1 and then the tv_v4l.c driver disables the sound completely.
> 
> 
> Yes I know that. I disabled it completely because i didn't know how to 
> solve the sync problems. 

Surprisingly synchronization is not big problem for me. Sound and audio 
seem to keep in sych relatively well.

> (and it wasn't necessary for me as I use an 
> external loopback => no motivation for spending time).

I have some motivation. What problem you are exactly facing? Audio 
buffer getting ahead of video one? Might deterministic switching of 
video and Audio grab solve the problem? Btw. does not this problem 
influence mencoder? It needs to encode audio+video at once, so it should 
suffer from the same problem!?

>> Solution:
> 
>> I am looking forward to see conflict during cvs upd indicating that my
>> patch was integrated ;-)
>> -jst 
> 
> 
> No, I won't commit this in the current form.

That is expected. Otherwise there would be no conflicts in CVS!

But I would approciate if you could be a bit more concrete and describe 
what is the problem with the patch. As far as I can see, the part that 
adds ensure_video_grabber_thread_is_running check into grab_audio_frame 
does not make the code worse. It just makes the code more robust. 
mencoder will run as before, mplayer might run better if audio is 
enabled. So what exactly your are objecting to?


I understand that the part enabling the audio might not be the nicest. 
If that is true, please suggest another way. As I really seem to have 
some motivation for implementing this, I am ready code implement it 
differently.

-jst



More information about the MPlayer-dev-eng mailing list