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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
