[linux-dvb] av-sync: mplayer, dvb-mplex

[Tomi Ollila <Tomi.Ollila@iki.fi>]

Hi

All you who use dvbstream to capture video and mplayer to play it, 
do you have problems with AV sync?

For me, If I `dvbstream -f <freq> <vpid> <apid> -ps -o | mplayer ... _',
or first save the dvbstream output to file and then play it with
mplayer -- both (all) cases the audio/video synchronization is
200 milliseconds off. If I play captured video with Xine, the
av sync is OK.

(as a side node, I just tested a six month old vdr recording --
 and with mplayer, the 200 ms av-sync issue is there too).

I'd like to ask which one gives you better av-sync:
mplayer with or without `-delay -0.2' -option.

The strange thing is that If the video is processed
with mencoder, the encoded video has correct av-sync.


This mplayer synchronization issue is not bad problem, the 200 ms
sync issue is there for each and every capture I've tested so far.
But If I want to some editing for the captured material, then new
problem arises.

*** Now, I came back here after spending some time writing this
*** email, with strange problem that seemed to set a/v out of
*** sync by random amount. I'll leave the text at the end of
*** this mail just to show how sometimes one simple thing can
*** get it all confused...

I have used dvb-mplex (from Metzelbros site, URL and reason why at the end)
to remultiplex my dvb captures so that the material can be edited further.
I now assume everything with it goes OK if the first audio and video
packets have time difference of small enough amount; I just tested
about 9 files, and when working, the maximum difference was 1035 ms.
But with 5 of these dvb-mplex reported time difference of:

VPTS - APTS = 3717456ms
VPTS - APTS = 76142179ms
VPTS - APTS = 44374750ms
VPTS - APTS = 26624986ms
VPTS - APTS = 23742183ms

I checked from code, and if the time difference is more than 500 seconds,
it will be changed to 300ms. (btw: previous versions just reported error
and exited -- as a suggestion that could be default, with more detailed
message of how user can do the mplex using -a and/or -v options...)

Anyway. When the time difference is this big, and it still continues
to do remultiplexing, the message of this "error" disappeares, and user
ends up with remultiplexed media file which seems to have out of sync
problem with random amount.

OK. previous sentence was just a reasoning why that old behaviour should
be reintroduced...

... But my real question here is, why does dvb-mplex notice such time
difference. Is there problem with the dvbstream generated pes -file 
(I just tested my 6 month old vdr recording that generated 2 output
files. First one had VPTS - APTS = 1020, but second 67 million),
or is there problem how dvb-mplex demuxes the file before remuxing.

In the next few hours I try to investigate the demux code in
dvb-mplex a bit whether I can find some solution here...


Tomi.

Now, the rest of this e-mail contains mostly inaccurate information,
but there might be (between lines) something that may interest you.

----


Before such programs as transcode, GOPchop, LVE, mpgtx, etc. Can
be used for the DVB-video, the file must be remultiblexed. The
tool that is suggested to do this is [dvb-]mplex currently available
at DVB CVS and in Mezlerbros www site. I am currently using the
one in http://www.metzlerbros.org/dvb/dvb-mpegtools-0.2.3.tar.gz
for 2 reasons.

1) It is probably more maintained as the linuxtv CVS.
2) the target binary name dvb-mplex does not pollute shell command
   namespace as plain `mplex' did (and, especially as the mjpegtools
   mplex still does).

So far, I have remultiplexed my video captures with these 4 different
command line options:

$ dvb-mplex -t MPEG2 -o output.mpg input.ps
$ dvb-mplex -t MPEG2 -a 1 -v 1 -o output.mpg input.ps
$ dvb-mplex -t DVD -o output.mpg input.ps
$ dvb-mplex -t DVD -a 1 -v 1 -o output.mpg input.ps

Choice between MPEG2 and DVD was just to test whether there is any
difference in output (and I hoped that changing that would magically
fix my problem).

The -a 1 -v 1 was given to set av delay to 0 by hand -- if only -a 0
or -v 0 (or -a 0 -v 0) is given, the change is ignored since the
code checks this argument is given if either of the variables
`adelay' and/or `vdelay' is != 0 in mplex.cpp line 398.


Each of the above 4 command line choices usually breaks the "lip-sync"
that was there in the .ps -version. The resulting audio/video out of
sync has been so far been in range of -200 -- 800 (i.e. got those
in sync with `mplayer -delay 0.6 ...' - `mplayer -delay -0.4 ...').


When I run the first (or 3rd) line, The usual range of VPTS - APTS
is in 200 - 800ms. Some of the resulting videos has even been in
sync with this. But a few times dvb-mplex has reported VPTS - APTS
like 76 million -- in this case dvb-mplex resets the sync
value as user would have given `-a 300'. When this happens, I've
never got output file where audio and video are in sync.

Hmm, what if...


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.