video goes out of sync after Muxman

[Kitt0s]

hey all,

after i demux a movie with PGCDemux and Mux it again with MuxMan (without changing anything) the audio and the subtitles are correct, but they don't match the video..

at first it was after i added a new .sup, but then i tested it without doing anything but still the same..

what could be the problem?

[Zeul]

Is there a progressive increase in the desynch or is it constant?

[Sir Didymus]

Also, when you demux through PgcDemux, what is the "audio delay" reported by pushing the "Check A/V delay" button ?

A couple of times noticed that if you blank (pre-process) some initial cells of a title, these results having video (a black I frame) but no audio. Into this condition the demuxer sometimes reports "none" for the delays all of the audio streams and the reauthoring of the title becomes badly out of synch (by a constant offset).

The trick have been to blank the unwanted cells by physically remove them... not just blanking...

My feeling is that the indicator of a good demux throug PgcDemux is a meaningful value reported by pushing the "Check A/V delay" button...

Cheers,
SD

[Kitt0s]

the Check A/V Delay reports none at all streams...

[Sir Didymus]

This is most probably due to the presence of cells, without audio, having different VID respect to the movie cells, BEFORE demuxing.

In this case the fault is not on MuxMan, but in the process you adopted for blanking some intro.

If you used VobBlanker in the process, please redo the blanking of the cells, unticking the option "Use Blank Cells in unref middle ones". This should hopefully completely delete the unref cells.

Found also very useful the usage of VidChanger [another great application from Jsoto], before reauthoring, in order to rearrange the VID/CID sequence.

[Kitt0s]

look what i did:
demux the movie with PGCDemux
made a .sup file
muxed with Muxman

thats it! no blanking no nothing!
it works ok in the original movie..
and even if i don't include the new .sup in the mux process i still get the same result.

[Sir Didymus]

Mhhh. Undestood.

I'll try to involve the kind attention of the writer of PgcDemux (Jsoto).
This seems it's not really a demuxer fault... It seems a specific, very particular scenario not completely covered...

On my understanding, even though you didn't perform any pre-processing, you got into something similar:

- the program chain you demuxed is composed by cells with different VID;
- the initial (or some of the initial) cells have no audio;
- a SCR discontinuity happened (SCR reset to 0 ?) between the initial cells and and the cells of the PGC containing audio;

Into these conditions the PTS of the audio packets is related to the time when the SCR reset happened, while the demuxed video may include a lot of video - the initial cell(s); if you try to perform a plain remux of the title, no information is available about the A/V delay and the audio may become heavily out of synch...

Not sure if this hypothesis may explain what happened to you... And not sure what you can do to solve the trouble...

I have for the moment no suggestion (apart doing some manual analysing to the program stream before demuxing, in order to understand precisely if the described situation is the one you actually face with...); maybe you may get a look, using DgIndex and VobEdit, to "see" inside the VOBs, and check PTS and SCR timings of the initial audio and video packets in your VOBS:

- check if the initial cells have Vob ID which is changing;
- check for the presence of SCR discontinuity among the cell(s) at the beginning of the title;
- check if there is audio or not in the first cell(s);
- analyse the SCR and PTS of the first audio and video packets...

All the best
SD

[jsoto]

May be the PGC has some blank cells at the beginning?

I'm pretty sure the A/V delay calculator will not work there, and the demuxer will not work fine....
The easiest solution is to remove the first cells with pgcEdit (only IFOs are modified) and, after that, demux the PGC with pgcDemux.

Seems I have to put some code inside pgcDemux to skip null or blank cells...

jsoto

[Fiticek]

Any progress here?
I exprerienced same problem..
I demuxed (tried with different tools) and muxed (also more tools) and video and audio is out of sync... (original dvd plays alright of course)
here are some details:
Movie pgc is divided into 2 vids.
I found that movie is going out of sync after vid change.
After inserting in dvd-lab, it says whole demuxed m2v has length of only second vid.
If i demux 2 vids separately(with PGCdemux), both parts shows right length and can be muxed and played in sync separately without any problem...
I tried to join both parts when muxing in Muxman, but no luck, same sync problem...
Any other idea, what could i try?

[mpucoder]

Create the two parts as seperate segments, which results in 2 VobIDs and allows for resyncing. The desync occurs because the audio and video of the first part are not equal in duration. By making seperate vobs, as in the original, the sync starts over with each vob.

[Zeul]

@mpucoder
This raises a question :D

If two vobids are created and we wanted them to be seamless - how can this be achieved if the audio is too short in the first vobid? Or is this factor unimportant.

[Fiticek]

thanks mpucoder
It could be the reason for desync.
I thought this already before, because there are few small reused cells in the beginning of pgc, which could, in this case, contain only video and no audio.
I tried to remove them (with pgcedit) and demux only movie cells, but with no luck. Is it possible yet that audio is different in duration even in those movie cells?

I will try to make it two separate vobidd, is it sufficient to change voids with vidchanger or how to? :-)

btw, how to make new pgc from two separated ifos (first and second vids i muxed separately)?

[Fiticek]

and.. as i demuxed firts vobid, i see video is one second shorter than audio..

and.. difference looks like to be in last cell of first movie vobid...