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

[Jaroslav Tulach]

Jindra wrote:
> 
> 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.

I see.

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

First solution that comes to my mind is to double the data deliver rate 
n-times by duplicating each video frame n-times. I can imagine this 
could work for video, but I expect that it would not for audio at all.

> Maybe it could be solved using the streaming code but I don't 
> know it much. 

I do not even know where to find it.

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

I am using:

mplayer -vo dxr3:prebuf:sync -ao oos:/dev/em8300_ma -tv on:.....

and everything seems to work find for few minutes. But I can confirm 
that after 3-7min work the video starts to be very slow. I thought that 
this is a problem of DXR3 (because DXR3 becames corrupted then). But 
maybe you are seeing the same problem. What are your arguments? Just

mplayer -tv on:...

Is your video slow since the begining or you have to wait few minutes?

-jst

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

The patch just exhibits problem that was already there, but you are 
right better to make it work correctly.