DGMPGDec 1.5.3 Final - Page 25

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.ph...ht=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, from the reference file posted above and from this ITU601 reference (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

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

Quote:

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

Quote:

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

Quote:

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

Quote:

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 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

Quote:

Originally Posted by Harukalover

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

Quote:

Originally Posted by neuron2

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.

Quote:

Originally Posted by neuron2

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.

Quote:

Originally Posted by neuron2

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

Quote:

Originally Posted by Harukalover

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

Quote:

Originally Posted by squid_80

(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

Quote:

Originally Posted by squid_80

(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!

Guest · 8th June 2008, 13:48

@Tima

I need the corresponding VOB fragments to do anything with this.

This doesn't affect the decoding, right?

Tima · 8th June 2008, 17:10

The bug with wrong cell ids -- doesnt affect decoding.

An issue with different timestamps -- don't know.

Working on delivering vob parts to you..

31st May 2008, 19:07	#482 \| Link
3ngel Registered User Join Date: Mar 2005 Posts: 457	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... Last edited by 3ngel; 31st May 2008 at 19:15.

1st June 2008, 16:44	#487 \| Link
3ngel Registered User Join Date: Mar 2005 Posts: 457	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. Last edited by 3ngel; 1st June 2008 at 16:54.

31st May 2008, 19:04	#481 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	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.

31st May 2008, 19:23	#483 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	You may find this thread enlightening, if you have not already seen it. http://forum.doom9.org/showthread.ph...ht=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.

31st May 2008, 19:34	#484 \| Link
3ngel Registered User Join Date: Mar 2005 Posts: 457	I'll read it. (Thanks again for having posted the reference, having an official reference as discussion basis is good)

31st May 2008, 21:20	#485 \| Link
3ngel Registered User Join Date: Mar 2005 Posts: 457	Now, i'm trying to shred some light again (i go till the end eheh). So from here, from the reference file posted above and from this ITU601 reference (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 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.

1st June 2008, 22:31	#489 \| Link
3ngel Registered User Join Date: Mar 2005 Posts: 457	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 confirm what we have read on many places "BT601 for SD".

2nd June 2008, 06:30	#490 \| Link
Harukalover Registered User Join Date: Sep 2006 Location: There! Not there! There! Posts: 21	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.

3rd June 2008, 02:09	#494 \| Link
squid_80 Registered User Join Date: Dec 2004 Location: Melbourne, AU Posts: 1,963	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?)

6th June 2008, 17:07	#497 \| Link
jpsdr Registered User Join Date: Oct 2002 Location: France Posts: 2,316	Same for me.

8th June 2008, 13:48	#499 \| Link
Guest Guest Join Date: Jan 2002 Posts: 21,901	@Tima I need the corresponding VOB fragments to do anything with this. This doesn't affect the decoding, right?

8th June 2008, 17:10	#500 \| Link
Tima Registered User Join Date: Aug 2004 Location: Russia, Novosibirsk Posts: 176	The bug with wrong cell ids -- doesnt affect decoding. An issue with different timestamps -- don't know. Working on delivering vob parts to you..