DGMPGDec 1.5.3 Final [Archive] - Page 10

ChiDragon

9th May 2008, 20:41

I've got a 1-frame "still pic" MPEG-2 from a Blu-ray that I can't get to play in any software except when PowerDVD plays the disc itself. It's actually Sony's "wrong region code" video, but I'm curious...

In DGIndex, I just get a wrong-sized black frame window, although it is able to deduce that the file is 1920x1080. In DGDecode, I get a garbled frame with proper picture at the top and green in the rest.

Now the weirdest part is that I managed to decode it by opening it along with another 1920x1080 MPEG-2 TS in DGIndex's File List. Any old file with the right res seems to work, but I've uploaded the one I used as a relatively small example. Opening the single frame vid before the additional clip works nicely, opening it after has issues if you don't seek normally.

00082.m2ts (474KB) (http://chidragon.thedessie.com/00082.m2ts)
00000.m2ts (24MB) (http://chidragon.thedessie.com/00000.m2ts)

Would it maybe be possible to get it to decode without the workaround, or could you explain what the issue might be?

Edit: In fact, adding 00082.m2ts alone to the list TWICE also decodes perfectly, but DGIndex's arrow controls don't like it.

Guest

12th May 2008, 14:23

Would it maybe be possible to get it to decode without the workaround, or could you explain what the issue might be? It's interesting, because if I demux the video with XMuxer Pro and then open the M2V, everything works normally. So it's some quirk with single frames in transport. I'll investigate.

dbzman1995

13th May 2008, 11:44

How about: -

http://i27.tinypic.com/zwzy1u.png

Cheers

thanks!!

Guest

25th May 2008, 15:21

* Fixed detection of field order for field structure streams.

* Fixed bug: Open file, Save Project, then File -> Open -> OK gives an error messge.

* Fixed bug: Save project with decode AC3 to WAV. Repeat that. Each time the WAV file becomes longer. The size was not reset to zero.

http://neuron2.net/dgmpgdec/dgmpgdec.html

Taurus

25th May 2008, 15:44

It's getting better all the time!
Thanks a lot,
and looking at the change log, I can see how much work you've got.
Really appreciated:thanks:

SeeMoreDigital

25th May 2008, 16:11

Hi Donald,

AAC audio (with MPEG-2) streams placed within .TS container are recognised in the "Information" bar as containing "MPA L2 2ch 44.1 free" audio.

Cheers

Guest

25th May 2008, 17:05

AAC audio (with MPEG-2) streams placed within .TS container are recognised in the "Information" bar as containing "MPA L2 2ch 44.1 free" audio.
Thanks for waiting for the release to tell me.

Do you have a stream I can use to duplicate it?

SeeMoreDigital

25th May 2008, 17:23

Thanks for waiting for the release to tell me.

Do you have a stream I can use to duplicate it?
I know, I know.... I'm useless :eek:

Here's a link to a sample: -

http://rapidshare.de/files/39518752/MPEG-2_with_6Ch_AAC.zip.html

ChunkyNorwich

30th May 2008, 00:22

Hi neuron2,

I think I found a bug in DGIndex 1.5.0. I'm trying to use the "Analyze Sync" feature but my audio ID contains three hex digits. The output file is called "trim.timestamps.delayTb1.txt" (only two hex digits) even though the audio track is 0x4b1. The output file is virtually empty:

<file>
Delay Analysis Output (Audio ID b1)

Decode picture: temporal reference 2[I]
</file>

Here's a clip:
http://rapidshare.de/files/39561574/SpamClip.ts.html

Thanks

Guest

30th May 2008, 01:15

The audio ID is not the same as the audio PID. The audio ID is the one shown in the audio box of the info dialog. For transport streams, it is always 0. If you specify 0 as the audio ID everything will work as expected.

The users manual does state in the "Select Tracks" section that the audio ID is always 0 for transport streams, but I'll add that to the Analyze Sync section as well.

ChunkyNorwich

30th May 2008, 11:53

Ah, my bad. It's working now, thanks.

alfixdvd

30th May 2008, 19:47

Wit the same group of VOB's

Version 1.49 indicates colorimetry is BT.709
Version 1.50b10 indicates colorimetry is BT.709
Version 1.50 Final indicates colorimetry is BT.470

I pay attention to the final version or to the previous ones ?

Guest

30th May 2008, 20:01

Colorimetry reporting changed. Please see the release notes.

Post a link to your stream if you want me to look at it and tell you why DGIndex reports what it does.

alfixdvd

31st May 2008, 07:58

21. When a stream does not declare the colorimetry, matrix_coefficients=1 is assumed for
HD video and matrix_coefficients=5 is assumed for SD video.

DGMPGDec/DGINDEX versions starting with 1.5.0 beta 12 (released Nov 9, 2007)(including the current 1.5.0 RC2), report BT.709* for HD video and BT.470-2* [aka BT.601] for SD video when colorimetry information is not specified by 'sequence_display_extension'. The asterisk (*) means the stream did not declare the colorimetry. from http://forum.doom9.org/showpost.php?p=1090272&postcount=93

Thanks, neuron2

3ngel

31st May 2008, 08:53

@neuron2

I was reading the DgDecode manual and and i have some doubts. It says

upConv: 0 to 2 (default: 0)

Upsample from 4:2:0 to YUY2 (4:2:2) or RGB24.
- 0: Do not upsample
- 1: Upsample to YUY2 (ignored if input is already 4:2:2)
- 2: Upsample to RGB24

The points 0 and 1 are clear, but point 2 doesn't say what matrix uses in order to do YUV->RGB conversion.

Does it uses an arbitrary fixed matrix (Bt.601,Bt.709,SMPTe etc) possibly mismatching, or it does use the "declared in the stream" matrix (always correct result)?
Moreover after the conversion i get a 16-235 or 0-255 range?

Thanks

Guest

31st May 2008, 13:55

The matrix is read from the GOP lines of the D2V file. The range is read from the YUVRGB_Scale line of the D2V header section. Refer to the DGIndex users manual for documentation of the D2V file format.

3ngel

31st May 2008, 15:09

Thanks. So i see PC/TV levels refers to luma range, while the calorimetry is taken from the information provided by DgIndex.

But, at this point, looking at the information given by DgIndex when the calorimetry is not declared

Note that if the stream does not declare the colorimetry, then ITU-R BT.709* is reported for HD video,
and ITU-R BT.470-2* is reported for SD video.
The * character indicates that the stream did not declare the colorimetry.

I see from an NTSC dvd it goes on BT.470 B,G* wich means it did not declare.

But reading around many place (and i was wondering from some time about this) i read that BT.470 is used as a reference for "Analog" devices, while the BT.601 is the "Digital Counterpart". So i think this is the first "ingruence" we can say. The label would to be 601 instead of 470.
Moreover from this site (http://www.scanline.ca/ycbcr/) wich gives a good calorimetry explanation, the ITU-R BT.470-2 System M would to be used on NTSC source while the ITU-R BT.470-2 System B, G would to be used on PAL sources.

So on my example, on NTSC dvd (altough from what i've read the 470 definition is not exactly correct) it would to use the M scale instead of the BG scale. But in the most correct way from what i've understood the BT.601 scale (or it is only a label strictly correspondy to the BG or M counterpart?) would to be used.

Moreover from this site (http://www.kolumbus.fi/pami1/video/pal_ntsc.html) when there are excerpt from the original "ITU Reference" wich unfortunately isn't publicy available, we have that the BG PAL assume a gamma of 2.8 while the M NTSC a gamma of 2.2.

Now because all the monitors sRGB have a gamma of 2.2 i think that it would be an even more reason to use the M matrix colorimetry instead of the BG colorimetry actually used by DGIndex on SD video.

What do you think?

Guest

31st May 2008, 15:57

I think that if you don't like the choice that DGIndex makes, then you can upsample outside of DGDecode.

This has been discussed a lot and there is a lot of conflicting information. The choice I made is based on feedback from users.

The MPEG2 specification allows for 470-2 System B,G matrix coefficients. There is no way to specify System M for matrix coefficients. It does allow for System M for color primaries and transfer characteristics, but DGMPGDec doesn't use those in any way.

For our purposes BT.601 is synonymous with 470-2 System B,G.

3ngel

31st May 2008, 16:20

Mine was not a critic. 'Cause i was going a more deep in the colorimetry i reported some observations of mine.

In this sense i don't know how the YUV->RGB conversion is done by DGindex but i saw in the sites above

ITU-R BT.470-2 System M (NTSC/USA) (0.67, 0.33) (0.21, 0.71) (0.14, 0.08)
ITU-R BT.470-2 System B, G (PAL) (0.64, 0.33) (0.29, 0.60) (0.15, 0.06)

So i assumed that in the YUV->RGB formula those different value for the RGB cromacity could make a difference in the final result.

I obviously can choose a different colorimetry (with a conversion) if i don't like, but that was not the point :)

Hope you didn't misundestand me, mine was just "for the sake of the knowledge" :)

Guest

31st May 2008, 16:43

I still don't understand your point. What is it? What are you asking me to do to DGMPGDec? This is the DGMPGDec thread, you know.

Just because you saw something in a site somewhere, it is not necessarily reliable. The only fully reliable sources are the specifications themselves.

So i assumed that in the YUV->RGB formula those different value for the RGB cromacity could make a difference in the final result. Did you miss the part where I told you that it is not possible to specify System M for matrix coefficients, and that it is only the matrix coefficients that are used for upsampling?

3ngel

31st May 2008, 17:47

My point is that in the references the two BT.470-2 (M and G,B) are different and were made for two different television systems, PAL and NTSC that used two different phospores system in the consumer television, so the trasmission had 2 different color palettes.
Because you in DGIndex explicity say "System B", i made you note the fact that SystemB with a gamma of 2.3 could not be indicated on our monitors with a gamma of 2.2, while System M uses the same gamma, so using the System M pheraps would yeld more precise results.

But you say that there is no way you can use SystemM matrix (wich differentiate from the System B for the cromacity values i posted before). But at this point if you can't differentiate M from B, on wich basis you say you're using system B?
In other words if you can't differentiate from the two system, because from what you've said you don't use the cromacity values which are the difference between the twos, how can you say you use SystemB? Pheraps, you're using BT-470, but inside this there are other 2 color subsystem palettes. And if you can't differentiate between the two, pheraps saying only BT-470-2* would be more correct.

Moreover i can't find anywhere that BT.470-2 = BT.601.

So pheraps you're using BT.601 wich doesnt have the M,B differentiation being done for a digital environment.

In the end i was misleaded by the fact that you say using BT.470-2, System B when you say you are not able to distinguish from System M (part of 470-2 too), and the assertion you say BT.470-2 = BT.601 wich in my opinion (and from what i've read everyware) is not.

And because you say cromacity values dont' fit in your YUV formula i can suggest (in the end of all this) you change the label from BT.470-2 PAL G (wich refer to a color subsytem of an analogue system), to BT.601 wich doesn't have cromacity value differentiation (not referring to a analogue phosphor system) and is the right digital counterpart to BT-709.

BT.470-2 everyware i read is used in relation to analogue/signal/TV phospors systems.

BTW sorry for this long OT in the thread, if you want i'll delete all these posts.

Obviously good work and thanks.

PS: The whole point of all my dissertion was to add reproduction and formal preciseness to DGDecode.

Guest

31st May 2008, 18:23

Why do I say System B,G?

See here:

http://neuron2.net/library/mpeg2/iso13818-2.pdf

Table 6-9 specifies B,G for value 5. So that is what I report.

Perhaps you could profit from doing a little homework on the relevance of color primaries, transfer characteristics, and matrix coefficients in the analog and digital domains. Recall that it is only the matrix coefficients that influence upsampling by DGMPGDec.

My point is that in the references the two BT.470-2 (M and G,B) are different and were made for two different television systems

Analog television systems. DGMPGDec remains wholly in the digital domain.

3ngel

31st May 2008, 19:01

I'm very glad you post the table because at page 68 just after table 6-9 it states:

In the case that sequence_display_extension() is not present in the bitstream or colour_description is zero
the matrix coefficients are assumed to be those corresponding to matrix_coefficients having the value 1.

That is:
if the portion of the stream containing the colorimetry is not present in the stream then switch to value 1 that is

1 Recommendation ITU-R BT.709
E¢Y = 0,7154 E¢G + 0,0721 E¢B + 0,2125 E¢R
E¢PB = -0,386 E¢G + 0,500 E¢B -0,115 E¢R
E¢PR = -0,454 E¢G - 0,046 E¢B + 0,500 E¢R

This clausole of "default switching" is present in every section above the 6-9 table.

So in our case, because we were talking about "not present colorimetry" (that is no information pesent in the stream) the right setting according to the Reference would be BT.709

Guest

31st May 2008, 19:04

That's what I used to do, but user feedback led me to the new approach. As I said, if you are not happy with it, just upsample with Avisynth's ConvertToRGB(), and specify the matrix that you prefer.

3ngel

31st May 2008, 19:07

Oh i finally understand your point.
Thanks, but i could not imagine you had gone different from reference 'cause of user feedback.

Now it's all clear :)
Now i know it, i'll try to do some conversion when i have occasion and if you like i'll post the screenshots (in contrary case, no problem, important thing it's knowing what's going on).

PS:
Strange enough the SystemM doesn't appear in table nor even BT601...

Guest

31st May 2008, 19:23

You may find this thread enlightening, if you have not already seen it.

http://forum.doom9.org/showthread.php?t=82217&highlight=ColorMatrix

Please don't get the wrong idea: I am always receptive to suggestions for improvement. One should try to be careful to review previous developments, if possible. Thank you for your information.

3ngel

31st May 2008, 19:34

I'll read it.
(Thanks again for having posted the reference, having an official reference as discussion basis is good)

3ngel

31st May 2008, 21:20

Now, i'm trying to shred some light again (i go till the end eheh).
So from here (http://www.scanline.ca/ycbcr/), from the reference file posted above and from this ITU601 reference (http://inst.eecs.berkeley.edu/~cs150/Documents/ITU601.PDF) (page 6) that is BT.601

ITU-R BT.470-2 System B, G
E'Y = 0,587 E'G + 0,114 E'B + 0,299 E'R
E'PB = -0,331 E'G + 0,500 E'B -0,169 E'R
E'PR = -0,419 E'G - 0,081 E'B + 0,500 E'R

ITU-R BT.601
E'y = 0.299R' + 0.587G' + 0114B'
E'CR = 0.500 E'R – 0.419 E'G – 0.081 E'B
E'CB = – 0.169 E'R – 0.331 E'G + 0.500 E'B

ITU-R BT.470-2 System B, G = ITU-R BT.601

I had to be matematically sure :D

You can write if you want (in order to avoid confusion) in DGIndex (the more known) BT.601 instead of BT.470-2 System B, G

PS:
I've read all the thread that pushed you to differ from the reference suggestion BT709, and it seems strange to me that software/hardware houses would so massively default to BT601 when the reference says different. I'll do test if i have time.

Wilbert

1st June 2008, 14:15

PS:
I've read all the thread that pushed you to differ from the reference suggestion BT709, and it seems strange to me that software/hardware houses would so massively default to BT601 when the reference says different. I'll do test if i have time.
Your reference iso13818-2.pdf is outdated. In "ITU-T Rec.H262 (2000 E)" they state:

In the case that sequence_display_extension() is not present in the bitstream or colour_description is zero the matrix
coefficients are assumed to be implicitly defined by the application.

We had this discussion a while ago: http://forum.doom9.org/showthread.php?t=131169 . Some more info about his subject: http://forum.doom9.org/showthread.php?t=133982

3ngel

1st June 2008, 16:44

In thruth it seems really strange to me that a reference would say "if you don't know, do as you please".
From what i've read from the References pieces we can find around, they are very precise on everything.

BTW you can access the official references? They are not public and require a login. In this case you sure have the latest version?

As a side note, after doing some tests i can say that from a visual taste BT601 seems give to me a balanced tone while BT709 colors seem little overexposed assuming a kind of little "exasperated" tint (speaking about DVDs).

Much interesting is your second links, in wich at a glance it appears that "BT601 for SD and 709 for HD"
And this statement i've personally read in clear or between the lines on many places.

Wilbert

1st June 2008, 18:12

In thruth it seems really strange to me that a reference would say "if you don't know, do as you please".
:)

BTW you can access the official references? They are not public and require a login. In this case you sure have the latest version?
They are freely accessible since a while: http://www.itu.int/rec/T-REC-H.262/en

Much interesting is your second links, in wich at a glance it appears that "BT601 for SD and 709 for HD"
And this statement i've personally read in clear or between the lines on many places.
Yes, many people say so. But at the end, only the dvd specs can give a definite answer. Unfortunately i don't know anyone who has them.

A separate issue is what the players and renderers do when playing video. Many of them are ignoring that setting in the mpeg-2 header. There is a lot of discussion about that too in those threads.

3ngel

1st June 2008, 22:31

I've just read the ITU601.PDF posted by me.
When i post it i read only the part regarding the colorspace matrix, but now i've read it entirely so i think it can be considered the angle stone of our dissertion. This because

1) It's called
ENCODING PARAMETERS OF DIGITAL TELEVISION FOR STUDIOS
So it refers exclusively to Digital Domain, and is dedicated to "Studios" that is the "source" of all productions, both TV, and DVD regarless the format. So we could have a 4:4:4 Lossless YUV at the studio wich is then converted to 4:2:0 YUV DVD maintaining the colorimetry of the 4:4:4 that is what this reference suggest.

2) This reference is dedicated exclusively to 565/625 lines (PAL/NTSC) and moreover it explains "officially" the right method to convert from "analogue lines" to "digital lines", so it can be considered the real bridges between the two world. In other words it's dedicated to all "digital 576/480 vertical size" both DVD or DVB.

So in my opionion this reference (http://inst.eecs.berkeley.edu/~cs150/Documents/ITU601.PDF) confirm what we have read on many places "BT601 for SD".

Harukalover

2nd June 2008, 06:30

Sorry in advance for reporting an issue after the final release but I couldn't find a reliable way to reproduce the following problem till now.

When using IEEE-1180 Reference iDCT algorithm for creation of a d2v, the resulting stream will sometimes output corruption in the form of random blocks appearing.

http://www.mediafire.com/?dymxfez1qoj

In the Test.7z uploaded I have included two pictures of frame 72. The one with the suffix of _okay was saved from the Fine.avs script, that used the d2v generated by Skal SSE MMX. The other pic is saved from the output of the Broken.avs script using the opposite IEEE-1180 Reference d2v.

I have commented lines in the Broken.avs script to explain how to reproduce the issue. dfttest() seems to just act as a trigger for it to appear. If you remove dfttest() after triggering it the blocks will not disappear from the output.

Thanks in advance.

Guest

2nd June 2008, 18:40

I have commented lines in the Broken.avs script to explain how to reproduce the issue. dfttest() seems to just act as a trigger for it to appear. If you remove dfttest() after triggering it the blocks will not disappear from the output. What are you using to view the AVS scipt when this is seen? When you say you comment out the dfttest() and it still stays broken, what do you mean exactly? Do you exit the application and restart it?

I'm suspecting that dfttest() is responsible. Are you able to cause this problem without it?

Harukalover

2nd June 2008, 19:15

What are you using to view the AVS scipt when this is seen?
Have seen it in AvsP and yatta. Another person who reported the same issue to me has seen it in yatta and Virtualdubmod and also had it encode into his resulting encodes. For me the blocks never encoded into another video.

When you say you comment out the dfttest() and it still stays broken, what do you mean exactly? Do you exit the application and restart it?
After I add dfttest() the blocks will appear in the frame as shown in frame_72_bork.png. If I remove dfttest() the blurring from the filter disappears but the blocks do not. If I exit and reopen the application the blocks will disappear until I seek about with dfttest() on again.

I'm suspecting that dfttest() is responsible. Are you able to cause this problem without it?
I'm not really sure anymore... >_> (I first found this issue a while ago and don't really remember what was used then to trigger it)

But could it actually be dfttest() causing it even though dfttest() will not cause the same issue with the d2v that didn't use IEEE-1180 Reference iDCT?

Either way I'll try asking the other person who experienced this same problem if their avs script used dfttest()

Guest

2nd June 2008, 20:21

But could it actually be dfttest() causing it even though dfttest() will not cause the same issue with the d2v that didn't use IEEE-1180 Reference iDCT? Yes, because memory and stack layouts are different in the two cases.

So I have to install dfttest() and Avsp to duplicate this and you've never seen it without them?! Sorry, but I'm not going to spend any time on that. If you can demonstrate an issue with DGMPGDec, then I'll look at it.

squid_80

3rd June 2008, 02:09

Maybe the compiler is using floating point instructions for the reference IDCT and dfttest is missing an emms instruction... Virtualdub's normally pretty good at catching those though.

(Who uses the extremely slow reference IDCT anyway?)

SpAwN_gUy

6th June 2008, 10:04

(Who uses the extremely slow reference IDCT anyway?)
me is using it from time to time with no purpose :) ... just fo fun :)

GrofLuigi

6th June 2008, 13:02

(Who uses the extremely slow reference IDCT anyway?)

Me too. When I'm faced with choice of speed over (supposed) quality, I chose the latter.

I don't understand what's the fuss about DGIndex's speed anyway. It's not slow, even on my aging Barton...

GL

jpsdr

6th June 2008, 17:07

Same for me.

Tima

8th June 2008, 11:12

Donald, hi!

I noticed a strange behaviour of DGIndex 1.5.0. I have a DVD with 4 episodes of a show: first ep is in vob 1 cell 1-2, second is in vob 1 cell 3-4 and so on. I saved 4 projects -- one for each episode. When looking into d2v, in last 3 files there are improper (I think) cell id's for first two GOPs. Also (when comparing each episode's d2v to d2v for the whole timeline) there's one GOP with different 'position' value.

I attached 5 d2v-s -- please have a look at them. Problem with first two lines of GOPs exists with eps 02-04; problem with different position for one GOP is in ep 02.

Thanks!