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

[Jindrich Makovicka]

Jaroslav Tulach wrote:

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

It is not exactly bad sync but on my machine I get the video about two 
times slower with alsa, and about one frame per second with oss audio 
output. With SDL it was usable but I haven't seen more than a few seconds.

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

The sync algorithms in mplayer expect that the media data delivery rate 
is faster than the playback rate but TV watching is more close to 
streaming. Maybe it could be solved using the streaming code but I don't 
know it much. MEncoder doesn't suffer from this as it can wait for the 
next frame as long as necessary. What I experience with your patch is 
that MPlayer somehow accumulates the delay, the video is _very_ slow and 
the video capture buffer grows fast.

> 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 am objecting to the current unusability of the patch.

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

This is the least problem.

-- 
Jindrich Makovicka