Question: How does DGIndex handle the timecode stored in video files ?

[Darksoul71]

Hi neuron,

I have two questions in regard to DGIndex. May be you are aware off my two tools QuEnc^n and HCEnc^n which do segmented parallel encoding and use DGIndex to merge M2V segments.

My two questions:
1) Lets say I load two separately encoded M2V segments into DGIndex and then select "Save project and demux video". What will happen to the time code in the final M2V "demuxed" video ?
If each segment has a timecode from 0 Minutes to 45 Minutes, will the concatenated movie have a corrected time stamp from 0 to 90 minutes ?

I hope you get what I ask

2) Has the approach how DGIndex handles the demuxing video tracks changed over the last version, e.g. from 1.4.6 to 1.4.9 in a big way ?

TIA....:thanks:

Best regards,
D$

[Guest]

Demuxing passes the MPEG data through transparently, so no changes are made to timecodes.

There were no big changes to demuxing between the versions you mentioned.

[Darksoul71]

OK, thanks for the quick answer...

I´m simply trying to figure out a strange behaviour the final file causes in some tools (e.g. TMPEG DVD Author or MPLEX) which worked flawlessly and I have no clue what beside DGIndex could have influence.

Thanks for the cool tool and the contiuous updates....

Best regards,
D$

[Guest]

Well, what is the strange behavior? Are you saying that it appeared between 1.4.6 and 1.4.9?

[Darksoul71]

Hm, I have to check and to do more testing

I´ll try to outline what has happened:
QuEnc^n used DGIndex 1.4.6 in earlier implementation. MPLEX was perfectly able to mux the resulting M2V file without any hickup.
TMPEGEnc DVD Author was able to detect the playtime correctly for the resulting M2V (encoded via QuEnc and merged via DGIndex 1.4.6).

A while ago when I started working on HCEnc^n I changed QuEnc^n also a bit and DGIndex was not part of the QuEnc^n package anymore. I did so in favor for DIKO since HCEnc^n and QuEnc^n will be included in one of the next packages.

I grabbed a newer version of DGIndex (1.4.9) and used it for my latest encodings with HCEnc^n. Currently I´m facing two strange "problems":
1) TMPEGEnc DVD Author is not able to detect the movie generated by HCEnc^n anymore. Since I have a dual core CPU my M2V file is merged from two separately encoded M2V segments. In such cases DVD Author only detects half the playtime (e.g. 45 Minutes for a 90 min movie). I can "solve" this issue when I mux audio and video prior mastering them. TMPEGEnc (which I used for muxing) seems to fix whatever the problem is...

2) MPLEX fails muxing the file correctly. It stops. The resulting file (surprise) is exactly as big as one segment plus audio.

Since HCEnc^n and QuEnc^n are really dumb middleware scripts translating some CLI parameters and calling external applications this limits the possible sources for any problems, doesn´t it ?

Hm..I´ll report back tomorrow what my test showed. I just wanted to assure in first place you didn´t change something dramatic in the demuxing code.

Don´t want to waste your time, though.

Thanks,
D$

[Guest]

Check to see if you have a sequence end code at the joint where things stop in MPLEX. DGIndex doesn't remove them. That is, check whether the M2Vs that are joined in DGIndex have sequence end codes at the end. If so, they should be removed before joining, or the encoder should be told not to add them.

EDIT: Sequence end code is 00 00 01 B7

[Darksoul71]

Hi neuron,

sorry for not getting back earlier to you and thanks for you reply.
Centurione pointed out correctly that HCEnc adds a end sequence code to each generated M2V.

http://forum.doom9.org/showthread.php?p=1057743#post1057743

This caused the problem with MPLEX. QuEnc on the other hand seems not to add any end segment code.

So my initial assumption that DGIndex behaves differently between two versions was completely wrong.

One thing that is still left:
The resulting merged M2V has incorrect timecode. Are you aware of a freeware tool (ProjectX ? ) which I could use to correct the timecode of the resulting M2V ?

I fully understand now that main intended use of the M2V "merging option" of DGIndex is solely to demux a M2V from VOB-files where the timecode is / should be perfectly right.

So my usage is "mis-usage" so to say.

Thanks for your support and DGIndex :)

Best regards,
D$

[Guest]

One thing that is still left:
The resulting merged M2V has incorrect timecode. Are you aware of a freeware tool (ProjectX ? ) which I could use to correct the timecode of the resulting M2V ? Sure. There's an obscure little tool called DGPulldown. :) If you run it with custom rates and put the existing rate in the before and after boxes, and set timecodes, you won't get any pulldown, but you will get the timecodes rewritten.

[Darksoul71]

Hi neuron,

thanks for the quick reply. DGPulldown sounds also worth a try.
A quick googling revealed a tool called restream by ssh. It´s out of CLI unfortunately but I hacked together a quick&dirty autoit interface. I´m currently doing some testing. If Restream doesn´t look like doing the work I´ll focus on DGPulldown. This would mean that I have to detect the FPS of the source video though (which I currently do not do).

Thanks again,
D$

[Guest]

Actually, you don't need to know the FPS, because DGPulldown has the "No change" option, which I forgot about in my post above.