[MPlayer-dev-eng] more pts

[Arpi]

Hi,

> For the audio, we have a_pts set to whatever the demuxer gives up, but then
> its adjusted by 
> 
>       a_pts+=(ds_tell_pts(d_audio)-sh_audio->a_in_buffer_len)/(float)sh_audi
> o->i_bps;
> 
> Why?  If you have the timestamp of the original audio packet, and the
> timestamp of the original video packet, why do you need this adjustment to p
> ut

as there are several buffering in the queue, and we should compensate PTS
with buffer's delay. this one compensates delay from demuxer buffer (bytes
readed after last PTS timestamp: ds_tell_pts(d_audio)) and decoder buffer
(sh_audio->a_in_buffer_len), divided by input bitrate.
i think it won't do anything with uncompressed data, it's for weird buffered
stuff used by win32 decoders like voxware or wma.

> them back together again for a skip or dup?  Also further down the code a bi
> t,
> AV_delay is computed via 
> 
>     AV_delay=(a_pts-v_pts); 
> 
> which makes sense, but then you go on to adjust it via 
> 
>     AV_delay-=mux_a->timer-(mux_v->timer-(v_timer_corr+v_pts_corr));
> 
> What are you subtracting out here?

i calculate the difference of incoming and outgoing a-v differences,
and also add known a-v delay correction (v_timer_corr+v_pts_corr)

v_timer_corr comes from FPS difference at input and output side,
v_pts_corr comes from PTS difference (same as ct: in mplayer)

> And finally, why do you multiply the whole thing by .1?
> 
>         x=AV_delay*0.1f;  

to reduce strength of a-v pts correction.
if i apply a-v desync immediatelly, then a single broken PTS could kill the
whole stuff and drop lots of frames...
this one and the next lines limits PTS correction code depending on value of
-mc option. -mc 0 disables this stuff, and keep v_pts_corr==0.0

for mpeg or asf files, but for some avi files too, PTS is not accurate
value, it should eb just a reference and should be integrated/averaged to
get any use of it.

i see your problem, you have very accurate PTS values from TV demuxer,
calculated from FPS (anyway you should get PTS from gettimeofday() imho)
and you expect my code to handle it without any magic.
but my code (based on mplayer's a-v sync correction) was developed for
inaccurate PTS values and variable input FPS.

> I just dont understand what yor trying to do with this code.  
i see.

> Wouldnt you only ever skip an video frame if the audio has missed a frame?
> Why skip a video frame if there is a corresponding audio frame?
as there are no 'audio frames'.
maybe there are in your demuxer... but it's not usual.
audio is a continous stream (you can fragment it, and usually do it, but it
still doesn't mean that there are a single audio fragment for each video
frame) , video is queue of frames.
the code reads audio, and calculates time position. then it's compared to
video pts and frame is skipped/dupped if the difference is too big.

> Wouldnt you want something like
> 
>     if(v_pts > a_pts) get_audio_frame()
>     if(a_pts > v_pts) get_video_frame() 

> and do the duplication as earlier in the code which is essentially:
> 
>     for(corr=current_framepts - lastframe_pts; corr > 0; corr -=frametime)
>         {
>         write duplicate frame;
>         }
> 
> ??

this is too simple and won't handle many cases what my current code does.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu