DGMPGDec 1.4.4 Final!

[Xesdeeni]

Originally Posted by neuron2

That stream has private tables for PMT...Neither BBDMUX nor DGIndex can decode those private tables. Sorry.

Wouldn't that also be the case for TVs with QAM tuners? So does he have a non-Fusion backup for complaining to the cable operator?

Xesdeeni

[Stereodude]

I have a TV with a QAM tuner, and it can tune the channels just fine, as can the Fusion 5.

I'll have to record another sample since I've already deleted that one by accident, but it seemed like HDTVtoMPEG2 (1.11.0.51) was able to decode the PAT table, but wasn't set up to look for a few hundred PIDs.

[honai]

@neuron2

I have a problem with Appleseed, NTSC, RC1. (Persists since version DGMPGDec version 1.4.0, so probably no regression bug.)

I open VTS_03_1.VOB to VTS_03_7.VOB in DGIndex, hit "Preview", and the preview window shows a jumping back and forth between different sections of the opening credits. The information panel shows that preview source alternates between VOB Cell Id 1 1 and 2 1. I checked the generated project in Virtualdub (via Avisynth), and the rendered video shows the same behavior.

It seems that DGIndex gets confused by different branches (?) in the opening sequence.

However, Nero Recode behaves correctly, i.e. only one branch is shown and processed.

Any idea?

(Oh, and thanks for such a great tool!)

[Leak]

Originally Posted by honai

Any idea?

Rip the movie in File mode using DVD Decrypter, turn on Multiangle Processing and choose an angle (probably the first) you want to keep. Then let DGIndex loose on the newly ripped VOBs.

np: Galoppierende Zuversicht LIVE @ [KONTROL] San Francisco - 18.06. 2005

[honai]

That did the job, thanks!

[neuron2]

Version 1.4.4 beta 4:

* Fixed an indexing bug in DGIndex that caused incorrect random frame access in DGDecode in some rare cases.

* Fixed a problem that caused stepping backward by GOP in DGIndex to fail in some cases.

* Added "m1v" to the open dialog "Files of type" string.

* Increased from 100 to 500 the maximum number of PIDs that can be displayed when performing Detect PIDs: Raw.

http://neuron2.net/dgmpgdec/dgmpgdec144b4.zip

[len0x]

I have noticed that CLI doesn't seem to support loading of D2V projects. I think it would be very handy feature later on when cutting is supported (of even now for those who always cut credits for instance).

[neuron2]

Let's get this girl to the prom, because I want to start cutting.

Here is version 1.4.4 RC 1:

* "Decode AC3 to WAV" was totally broken for tracks 2-8 (1 was OK). This
has been repaired.

* Fix D2V is now run automatically and the D2V file is repaired (instead of saving the correct D2V file in *.d2v.fixed). The bad version is saved in *.d2v.bad. See the reference manual for details.

* The right arrow key can now be used to single step in play/preview mode if the playback speed is set to Single Step (previously just the right arrow button worked).

http://neuron2.net/dgmpgdec/dgmpgdec144rc1.zip

[len0x]

Is there a reason for change logs to be in a separate files like this: Changes_xxx.txt instead of just one? There are nine files already and the number keeps growing

[Marius-the-Mad]

Hello.

neuron2, I have a problem with colorimetry reports, but at this point, I don't know whether the problem lies in DGDecode or HC Encoder. Please bear with me if I'm knocking on the wrong door. I reported a problem to hank315, too, but AFAIK he's taking a few day break from programming after a weekend spent in front of the keyboard and hasn't answered yet.


The problem: DGIndex/DGDecode report I470 in my encodes, but converting the output to RGB with simple ConvertToRGB32() (rec601 is the default colour matrix) results in a bit different colours than in the source. ConvertToRGB32(matrix="rec709") results in colours matching the source perfectly.

As I don't know whether colour matrix is being stored in MPEG 2 stream just like quantisation matrix is, I don't know where the problem can and can not lie. I want to report it in case it were an issue with DGDecode.


Some screenshots illustrating the case:

- the source (I709): http://img291.imageshack.us/my.php?i...rcei7099iz.png

- DGDecode's report: http://img291.imageshack.us/my.php?image=m2vinfo8tn.png

- ConvertToRGB32(): http://img291.imageshack.us/my.php?image=m2vi4704bo.png

- ConvertToRGB32(matrix="rec709"): http://img387.imageshack.us/my.php?image=m2vi7093zv.png


Screenshot from the source needs a comment. DGDecode reported I470 on the DVD, so I used ColorMatrix(mode="rec.601->rec.709"). At this point, I'm a bit lost in the maze of these conversions and am not sure if my screenshots are helpful at all. But I can upload a short sample of the original VOB, if you want me to.



Also, I found an other, but small problem in DGIndex - the state of the option to log quantisation matrices is not being preserved between sessions. Is it intentional ?


Thank you for the new DGIndex, neuron2.

Regards
MTM

[neuron2]

@Marius-The-Mad

I'm afraid I don't have time to go trekking into the jungle of color space conversions, etc. DGMPGDec simply reports the value of the colorimetry field as contained in the MPEG stream. Unless you are suggesting that it is being reported wrongly, I simply do not have any time to get involved in that.

Perhaps HC is not recording the colorimetry info in the stream properly.

The log quants option is not stored in the INI file, as documented in the reference manual for DGIndex.

@len0x

I'll consolidate them. Thanks for the suggestion. It stems from having separate changes files for linking at my web site.

[Wilbert]

The problem: DGIndex/DGDecode report I470 in my encodes, but converting the output to RGB with simple ConvertToRGB32() (rec601 is the default colour matrix) results in a bit different colours than in the source.

That should indeed be the same since I470 = Rec.601.

The problem: DGIndex/DGDecode report I470 in my encodes, but converting the output to RGB with simple ConvertToRGB32() (rec601 is the default colour matrix) results in a bit different colours than in the source. ConvertToRGB32(matrix="rec709") results in colours matching the source perfectly.

How did you take a screenshot of the source?

[Marius-the-Mad]

Originally Posted by neuron2

Perhaps HC is not recording the colorimetry info in the stream properly.

Perhaps. I'm fully aware this may be the case now, I wasn't sure how this information was being retrieved. I will bug hank315 about, then.

Originally Posted by neuron2

The log quants option is not stored in the INI file, as documented in the reference manual for DGIndex.

Ooops... I'm sorry, it's definitely there, but I managed to overlook it somehow.

Originally Posted by Wilbert

How did you take a screenshot of the source?

The path:

DGDecode -> pc_to_tv -> ColorMatrix(mode="rec.601->rec.709") -> some_filters -> ConvertToRGB32(matrix="rec709")

I call it "source" because this is what I feed HC with (excluding YUV->RGB conversion, of course). Somewhere in the chain there is a problem with colours, it seems - I'll ask Hank about it again.


<edit> Specified ColorMatrix() parameters.

[Wilbert]

Please do the following test:

Mpeg2source(...) #I470
ColorMatrix(mode="rec.601->rec.709")
ConvertToRGB32(matrix="rec709")

Open this in VDub and take a screenshot. Next script:

Mpeg2source(...) #I470
ConvertToRGB32()

Open this in VDub and take a screenshot. Are both screenshots identical? If not upload a short vob somewhere.

[Marius-the-Mad]

They are identical. I guess this leaves us with wrong colour matrix written into MPEG 2 stream by HC.

Thank you, Wilbert. I couldn't put together a proper test. It seems so obvious I feel ashamed.


Unless I'm mistaken, but I think this time I'm not.

[Wilbert]

They are identical. I guess this leaves us with wrong colour matrix written into MPEG 2 stream by HC.

You have to ask hank315 about this, but i think the following happens:

1) The Rec.709 coefficients are written in the header of the MPEG-2 stream when feeding HC with RGB material.

2) The Rec.601 coefficients are used for the RGB->YUV conversion (remember MPEG-2 is stored as YUV) which is done in HC.

The coefficients in (1) and (2) should be the same. If this is not the problem some further testing is needed.

Btw, you can easily circumvent the problem by using ColorMatrix() and feeding hc with YUV material.

edit: clarification

[Marius-the-Mad]

I've been doing it from the start. There just seems to be a slight problem in HC, because if DGIndex reported a wrong colour matrix, the test you suggested would result with different looking screenshots, I think.

Thank you very much for all the replies.

[hank315]

DGMPGDec simply reports the value of the colorimetry field as contained in the MPEG stream.

Have a question about it, how do you detect the colorimetry?
Just did a run with DGIndex 1.4.3 on a HC encoded file and it reported ITU-R BT.470-2, seems strange because HC doesn't write the sequence display extension so I expected the default ITU-R BT.709.
The D2V does have the line "YUVRGB_Scale=1" in it.

[tritical]

Have a question about it, how do you detect the colorimetry?
Just did a run with DGIndex 1.4.3 on a HC encoded file and it reported ITU-R BT.470-2, seems strange because HC doesn't write the sequence display extension so I expected the default ITU-R BT.709.

Guessing here, but it is probably because when parsing the sequence header dgindex assumes mpeg1 defaults for a couple values: progressive_sequence, chroma_format, and matrix_coefficients thinking that they will be overridden later if the stream is actually mpeg2. However, if the sequence display extension isn't present then the matrix_coefficients value never gets overridden and it defaults to the mpeg1 default of ITU-R BT.470-2 instead of the mpeg2 default of ITU-R BT.709.

[neuron2]

If there is no SDE, it is designed to default to 470 for MPEG1 and 709 for MPEG2. Was your stream MPEG2?

I'll run an experiment with HC tonight.

EDIT: Just saw tritical's post. Yes, it's not getting set right for MPEG2 in absence of SDE. I know it's MPEG2, however, from initial_parse(), so I will fix that.