DGMPGDec audio/video sync discussion

[Guest]

I broke this out into its own thread.

I've now figured out why there is the large discrepancy with the stream that Zep provided. The transport stream is cut at the beginning just before an early B frame of a long GOP. DGIndex compares that B frame's PTS to the PTS of the next audio frame to calculate the offset. But later when the video is decoded, the frames prior to the first I frame of the first (following) good GOP are discarded. There is about 700ms of video discarded for this reason.

Normally with VOBs, you can trust that the first video will be a good I frame at the start of a GOP, but with these capped transport streams, all bets are off. Apparently, I am told, async can also occur later in the file due to video drops, etc.

Therefore, our plan should be as follows. First, modify the code to not output any audio or video prior to the first good video GOP. Second, dynamically insert/delete audio frames to maintain exact sync throughout. Then the demuxed streams will just be synced properly and you won't have to set offsets in VDub, TMPGe, etc. That is how ProjectX works and there is no reason why DGMPGDec should not work that way too.

Comments?

[dtv_user]

@neutron2

Donald I was thinking about possibly a 2 pass process.

First pass would generate D2v file and note time stamp of beginning of file.

Second pass would grab audio and write audio file using time stamp from video first pass.

My understanding is that some ATSC streams can have their audio packets in different location in stream without affecting time code.
Balazar on AVSForum has posted some information about this and has a program ATSC3 (source code available) to relocate audio packets.

dtv_user

[Guest]

I searched on AVSForum for user Balazar and for keyword ATSC3. No matches for either. Can you be more specific please?

[Cyberia]

Would this method be employed for all file types, or just transport streams?

[dtv_user]

@neutron2

Here's the link to his homepage Donald.

http://www-personal.engin.umich.edu/~balazer/atsc/

Link to thread talking about audio.

http://www.avsforum.com/avs-vb/showthread.php?threadid=402883&perpage=20&pagenumber=1
He has 3 programs ATSC3 moves audio packets.


Also when using projectx I seem to be off 2 audio frames, I think this is because projectx throws out the first 2 B frames like DVD2avi.

dtv_user

[Guest]

Originally posted by Cyberia
Would this method be employed for all file types, or just transport streams? I don't see any reason to limit it to transport streams, do you?

[eb]

My prompt from the practice, sorry that I am not ably to describe details.
When I have a record that ProjectX or PVAStrumento (with settings to correct errors) are not able to deal with this record, then I am processing that record by PVAStrumento but having all corrections for audio and for video switched off.
Probably,PVAS in this case is working like neuron2 described above( looking for first valid/full/ GOP then rewriting audio and video time stamps changing them as begining from the zero value, keeping latter natural oder of the packets.

Processing raw strems of mpg records in DVD2AVIT3 we can see in many cases that audio time stamps are starting from value let say 2:00:00:000 and then changing to 00:20:00:000.
It happens mainly on the borders between comercials and proper programs.

eb

[Guest]

@eb

Good point. We need to allow for discontinuities in the PCR. That shouldn't be a problem as long as we ignore it (!) and just align the audio and video PTS's.

[eb]

@neuron2

exactly, and this is the MAIN difference between DVD and DVB processing programs.
so neuron2 please level this.

eb

[NeOff]

I havent tested this recently, but I do know I used to have a problem with the HDTV streams when they switched between 2.0 and 5.1, each switch seemed to cause a new offset of around 300ms. Currently I have no samples of this, I will see if I can catch something tonight or tommarow where this happens, or possibly someone else knows what Im talking about and could provide a sample sooner.

[Zep]

Originally posted by neuron2
I broke this out into its own thread.


Normally with VOBs, you can trust that the first video will be a good I frame at the start of a GOP, but with these capped transport streams, all bets are off. Apparently, I am told, async can also occur later in the file due to video drops, etc.



yup and it appears that basically after a drop
it is like the start GOP problem and a GOP(s) is/are
hosed and you would need to do the same thing and start
re sync at the next full GOP. Still show the frames
in the bad GOP if possible but re sync from scratch
on the next full good GOP.


Originally posted by neuron2
Therefore, our plan should be as follows. First, modify the code to not output any audio or video prior to the first good video GOP. Second, dynamically insert/delete audio frames to maintain exact sync throughout. Then the demuxed streams will just be synced properly and you won't have to set offsets in VDub, TMPGe, etc. That is how ProjectX works and there is no reason why DGMPGDec should not work that way too.

Comments? [/B]



With drops each section of audio will be off a different amount
so you can't just slide the whole audio track. You have to break
it up in chunks and slide each chunk around. That is why it
is such a HUGE problem.

First thing i do is use offset in VDUB to get the start
to the first drop in sync then open the audio in cooledit and
add/delete audio frames at the first drop point. Which slides
the audio after that point. Then moved to the next drop
if there is one and do it again. worst of all it means you have
to WATCH the whole .ts and FIND these drops. some drops are so
small you have to go frame by frame to catch them all.

arrrgghhhhh very time comsumming! and a huge pain in the neck!


Anyway


AWESOME!!! :D

[eb]

@ Zep,

In this way as you described is working PVAStrumento and ProjectX.
When in records there are many discontinuities then you can finish with 200MB file resulted from 2GB record file.
But when playing back this 2GB file everything seems ok.
That is the reason why I used only rewriting time stamps in PVAStrumento , at same time demuxing all video and audio streams to seperated files.

eb

PS
Then in VirtualDubMod i was checking length of video and audio files having starting point already set as 0 by PVAStrumento.
In folder Video of VDM under Frame rate I was looking for the prompt what value of frame rate to be used to align length of video and audio. / example new value 24.992/
At the same time at the same place but another window /a little below I put value 25.000 in order to get final product as 25 frames/s to be able latter to join/append resulted files.

[Zep]

Originally posted by eb
[B]@ Zep,

In this way as you described is working PVAStrumento and ProjectX.
When in records there are many discontinuities then you can finish with 200MB file resulted from 2GB record file.
But when playing back this 2GB file everything seems ok.
That is the reason why I used only rewriting time stamps in PVAStrumento , at same time demuxing all video and audio streams to seperated files.

eb


right. i use projectX. It was me that sent DG my projectX
logs so he could see what it was doing that DGindex was not
with that whole +700 problem.

projectX is not perfect but it is better than doing what i
described in my last post that I used to do before projectX.

I never tried PVAStrument. which is better?

and do you have a link?


thx

[eb]

Zep,

link to PVAStrumento:
http://www.offeryn.de/dv.htm
eb

[dtv_user]

@neuron2

Don first a disclaimer - I am not a programmer.

What I have done with version 1_3 was to put a video_PTS display in the Info dialog display and have made the ShowInfo to default to on all the time.

Now when I move the slider to advance the clips I can see the video and audio time codes display and change from frame to frame.

My question is why do I still get a DELAY value if I have both time codes reading the same value?

Maybe it has to be down to the frame level instead of second value.
Could you could shed some light on this issue?

Thanks
dtv_user

[dtv_user]

@neuron2

Don interesting link I found concerning audio sync.

http://www.broadcastpapers.com/sigdis/TektronixMPEGGuide%20-%20streams02.htm

One interesting thing stated was about not having time stamps in every presention unit - but can be interpolated by decoder as long as the weren't farther than 700ms apart.


from the article:
A time stamp is a 33-bit number that is a sample of a counter driven by a 90-kHz clock. This clock is obtained by dividing the 27-MHz program clock by 300. Since presentation times are evenly spaced, it is not essential to include a time stamp in every presentation unit. Instead, time stamps can be interpolated by the decoder, but they must not be more than 700 ms apart in either program streams or transport streams.


Later
dtv_user