Colorimetry undefined in mpv files

[charleski]

I'm using the latest DGIndex (1.4.6b2)

Source input is an mpeg2 transport stream that my capture card (a Hauppage Nova-T) saves as a simple .mpg which I cut and demux in ProjectX. Now, when loading the resulting .mpv into DGIndex, it recognises the colorimetry and shows ITU-R BT.709 in the Colorimetry field of the Information pane. But the d2v file reports the colorimetry as Unspecified Video (2).

If I run DGIndexer over the original .mpg the resulting d2v reports the colorimetry correctly.

Am I doing something wrong, or is this a bug?

[Guest]

But the d2v file reports the colorimetry as Unspecified Video (2). There's no string for Colorimetry in the D2V file. Where exactly are you seeing this string?

[charleski]

The 'Unspecified Video (2)' is what's reported from dgdecode using the info=1 option.
The matrix is specified as the 2nd number in each line in the d2v, if I'm reading the manual correctly.
I.e. 900 1 0 670058496 0 0 32 32 92 b2 b2 a2means the input has BT.709 colorimetry.
here's a sample line from the d2v made from my demuxed .mpv:900 2 0 20751626 0 0 32 32 92 b2 b2 a2 b2 b2 a2

[tritical]

The differing reports between dgindex/dgdecode are because dgindex's info dialog displays what is actually being used for the conversion to rgb and not the actual value in the stream. However, dgdecode's info=1 option (and what is stored in the d2v file) correspond to the actual value in the stream. The current mapping between possible values that could be in the stream (of which there are 256) and what set of coefficients will actually be used for the conversion to rgb (of which there are 4) is as follows:

8-255 (reserved) -> ITU-R BT.709
7 (SMPTE 240M) -> SMPTE 240M
6 (SMPTE 170M) -> SMPTE 170M
5 (ITU-R BT.470-2) -> ITU-R BT.470-2
4 (FCC) -> FCC
3 (reserved) -> ITU-R BT.709
2 (Unspecified Video) -> ITU-R BT.709
1 (ITU-R BT.709) -> ITU-R BT.709
0 (forbidden) -> ITU-R BT.709

The following are actually the same: SMPTE 170M = ITU-R BT.470-2 = BT.601. Maybe changing dgindex to report the actual decimal value from the stream along side what is currently displayed would be useful.

[charleski]

I've taken the liberty of uploading a very short sample to your ftp site (directory: ColorimetryInDemuxedFiles) to illustrate the problem. It includes the d2v files derived from the original and demuxed streams, these report different values. The whole lot is just over 14M, hope that's alright.

It's not a vital issue, I only stumbled over it as I began using ColorMatrix in the past couple of days and thought I would be clever by using the info from the d2v as Wilbert specifies. But I suppose it's safe just to use ColorMatrix without any parameters.

[tritical]

As far as the difference between original and demuxed streams I don't know off hand, probably have to wait for neuron2, but for colormatrix its d2v option currently only works if all matrix_coefficients values throughout the stream (in the d2v) are 1, 4, 5, 6, or 7 (i.e. defined values), and if all values in the d2v are the same or are compatible (i.e. mixing of 5 and 6 would be ok, but not 1 and 5). I have been meaning for a long time to update colormatrix so that it's d2v option can handle changes in the stream and to have fully correct conversions for S240M and FCC, but I've never gotten around to it.

[Guest]

Apparently, ProjectX has changed the colorimetry. If you just use the original MPG all the way, you see everything agreeing: DGIndex, D2V value, and DGDecode. If you demux the M2V with DGIndex, it still all agrees. As soon as you process it with ProjectX, it changes to value 2. DGIndex reports any value less than 4 as ITU-R BT.709.

[charleski]

Thanks for looking at this. So it was something I was doing (indirectly:) ). I'll let the ProjectX people know. ProjX seems to manage sync issues across cuts better than the other solutions I've tried, so it would be nice if it preserved all the parameters, but I'll live.

[Guest]

It would be interesting to know why they do that, or even if it is intentional or not. Please post if you find out the answer.

[charleski]

Here's the reply I got after posting this in the bugs section of ProjectX's sourceforge board: (no name given)
some encoders of dvb broadcasters also use that flag resp.
its informations, but some zoran chipsets of some dvd
players cannot parse/process these data correctly from the
original stream, and then you'll get ugly green blocked
pictures.
that's why pjx optional remove the infos in 'composite
display flag', so you have to untick this option..
I assume he's talking about the 'patch c.d flagged infos of pictures' checkbox in the Video tab of the PreSettings box. Unfortunately, this has no effect on the colorimetry removal.