Restamping audio PTS/DTS inside a VOB/MPEG-2?

[Ghitulescu]

Like the title said, is there something that could change the delay between audio and video without remuxing/demuxing them? I know it cannot perform magics, but I'm expecting results up to eg 100-200 ms .....

It's more or less what DVDsubedit does with the subtitles.

[Sir Didymus]

I am not aware about the existance of such tools...

Even in case the changes of these time stamps are of limited size, the implications in terms of authoring may become relevant (think about audio packets close to the cell boundaries: what to do if the audio "shift" would lead to move packets from one cell to another?). Furthermore the consistance of the video buffer verifier may become infringed, I think...

I know it's obvious to say, but I would recommend to carry out always demux/reauthoring in the situations like the ones you have reported...

Cheers,
SD

[Ghitulescu]

I know this, this is why I said short delays, yes, maybe 300 ms is too much ...
I was just curious if there's such a tool out there ...
Because it could have been of a great help to people like me that do some processing in HW and thus slight delays between the audio and video may appear. Muxing and remuxing 4GB several times to find the exact lipsynch is not really that funny. :)

[r0lZ]

Muxing and remuxing 4GB several times to find the exact lipsynch is not really that funny. :)Maybe you can use Aegisub. It's an excellent tool to build and synchronize subtitles, but it has powerful functions to examine (visually) the audio waveform, and it can show the video image as well. It should be easy to find the exact offset to sync them.

[jeanl]

It's an interesting question. You can do a little by modifying the PTS of the audio packs, but you can only do a little (and I don't know exactly how much). If you do too much you get into a muxing problem: the dvd player does not get the audio pack in time to play it, and runs out of audio, or vice versa, it gets it too early and runs out of place to store the audio. The same is true of subtitles, you can change their timing a little bit with the PTS, but it's not recommended, because it can make the final mux out of spec (i.e., unplayable on some players). The only reliable way is by demuxing and remuxing (with a tool that guarantees a playable mux, i.e., a good muxing program).
Jeanl

[Ghitulescu]

I was talking about a few frames, so up to 100-200ms.
There is a reason for this question - I work on external HDDs and they are quite slow, my captures are HW, and the amount of delay is dictated by the number of processors in between, up to 2-3 frames. Remuxing the elementary streams several times in a row is extremely time consuming with file sizes in the DVD range ... Guesstimating is ok, but I still need 2-3 runs, which I prefer to skip and focus on more important things ....

Once the delay known, I can remux them the orthodox way :)

I found no program that could take a DVD structure and to edit the delay, for this purpose

[jeanl]

I was talking about a few frames, so up to 100-200ms.
There is a reason for this question - I work on external HDDs and they are quite slow, my captures are HW, and the amount of delay is dictated by the number of processors in between, up to 2-3 frames. Remuxing the elementary streams several times in a row is extremely time consuming with file sizes in the DVD range ... Guesstimating is ok, but I still need 2-3 runs, which I prefer to skip and focus on more important things ....

Once the delay known, I can remux them the orthodox way :)

I found no program that could take a DVD structure and to edit the delay, for this purpose
I"m not quite understanding the context: how can the capture put the wrong time stamps? :( and I don't quite understand (the number of processors in between).
Do you know the exact time in ms you need to delay the audio (or the video)? There are players that allow you to adjust that on the fly (I think mediaplayerclassic can, if I'm not mistaken). So if you can estimate this delay in advance, by playing the video a few times, then you only have to remux once.

Otherwise, if you're a programmer, you can use python to do what you want. It's in fact quite simple if you're not remuxing: you just read the PTS from the audio packs, add/subtract a small value from it, and write it back....
Jeanl

[Sir Didymus]

...There are players that allow you to adjust that on the fly...

Wow... That's a very good hint... Apparently, after few simple attempts, with MPC. For delays up to around one second it seems the playback is perfect. However, video becomes unwatchable (frequent pauses and restarts) for huge delays - around 5 seconds...


Otherwise, if you're a programmer, ...

Naaa... It is in any case time and space consuming, it creates (most probably) oddities and infringements of various types in the regenerates streams... Me voting for your smart suggestion above, clean, easy, practical... :-) ...

[Ghitulescu]

I"m not quite understanding the context: how can the capture put the wrong time stamps? :( and I don't quite understand (the number of processors in between).
No, the time stamps are correctly put, ie at the time of capturing.
While I can safely assume that my TBC delays the signal with 20ms (PAL), I can only guestimate the delay introduced by the colour correction, which may amount to one frame.
Do you know the exact time in ms you need to delay the audio (or the video)?
No, exactly this was MY question. I don't know. Should I knew it beforehand, wasn't it easier to adjust this KNOWN delay prior to ONE SINGLE muxing :)?

[Sir Didymus]

If the assets are not already muxed, the usage of the timeline alignment tools of the authoring suite (or the proper usage of the NLE environment that you use for the DVD production) should be sufficient - or better, necessary - to put audio and video in synch; if the assets have been already muxed and the synch is not satisfying, then the "smart player" solution suggested by jeanl should help to find precisely the amount of the millisec correction.

In both situation a new authoring session seems needed... Right?
:-)

Cheers,
SD