Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
31st May 2008, 19:07 | #482 | Link |
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. |
31st May 2008, 19:23 | #483 | Link |
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, 21:20 | #485 | Link |
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, 14:15 | #486 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
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 |
|
1st June 2008, 16:44 | #487 | Link |
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. |
1st June 2008, 18:12 | #488 | Link | |||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Quote:
Quote:
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. Last edited by Wilbert; 1st June 2008 at 18:17. |
|||
1st June 2008, 22:31 | #489 | Link |
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 |
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. |
2nd June 2008, 18:40 | #491 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
I'm suspecting that dfttest() is responsible. Are you able to cause this problem without it? |
|
2nd June 2008, 19:15 | #492 | Link | ||
Registered User
Join Date: Sep 2006
Location: There! Not there! There!
Posts: 21
|
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:
Quote:
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() Last edited by Harukalover; 2nd June 2008 at 19:23. Reason: Missed a question... |
||
2nd June 2008, 20:21 | #493 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
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. |
|
3rd June 2008, 02:09 | #494 | Link |
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, 10:04 | #495 | Link |
Junglist
Join Date: May 2003
Location: Belarus, Minsk
Posts: 298
|
me is using it from time to time with no purpose ... just fo fun
__________________
Rule Number 6: Concentrate!!! (c)Hercules, Disney "I like to build planes.... in the air" (c) some ADV. tutorials How to Setup agent-based encoding with x264farm (the easy way) |
8th June 2008, 11:12 | #498 | Link |
Registered User
Join Date: Aug 2004
Location: Russia, Novosibirsk
Posts: 176
|
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! |
|
|