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.

 

Go Back   Doom9's Forum > General > DVD2AVI / DGIndex

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 31st May 2008, 19:04   #481  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,924
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.
Guest is offline  
Old 31st May 2008, 19:07   #482  |  Link
3ngel
Registered User
 
Join Date: Mar 2005
Posts: 455
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.
3ngel is offline  
Old 31st May 2008, 19:23   #483  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,924
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.
Guest is offline  
Old 31st May 2008, 19:34   #484  |  Link
3ngel
Registered User
 
Join Date: Mar 2005
Posts: 455
I'll read it.
(Thanks again for having posted the reference, having an official reference as discussion basis is good)
3ngel is offline  
Old 31st May 2008, 21:20   #485  |  Link
3ngel
Registered User
 
Join Date: Mar 2005
Posts: 455
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.
3ngel is offline  
Old 1st June 2008, 14:15   #486  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,293
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
Wilbert is offline  
Old 1st June 2008, 16:44   #487  |  Link
3ngel
Registered User
 
Join Date: Mar 2005
Posts: 455
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.
3ngel is offline  
Old 1st June 2008, 18:12   #488  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,293
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.

Last edited by Wilbert; 1st June 2008 at 18:17.
Wilbert is offline  
Old 1st June 2008, 22:31   #489  |  Link
3ngel
Registered User
 
Join Date: Mar 2005
Posts: 455
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".
3ngel is offline  
Old 2nd June 2008, 06:30   #490  |  Link
Harukalover
Registered User
 
Harukalover's Avatar
 
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.
Harukalover is offline  
Old 2nd June 2008, 18:40   #491  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,924
Quote:
Originally Posted by Harukalover View Post
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?
Guest is offline  
Old 2nd June 2008, 19:15   #492  |  Link
Harukalover
Registered User
 
Harukalover's Avatar
 
Join Date: Sep 2006
Location: There! Not there! There!
Posts: 21
Quote:
Originally Posted by neuron2 View Post
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 View Post
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 View Post
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()

Last edited by Harukalover; 2nd June 2008 at 19:23. Reason: Missed a question...
Harukalover is offline  
Old 2nd June 2008, 20:21   #493  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,924
Quote:
Originally Posted by Harukalover View Post
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.
Guest is offline  
Old 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?)
squid_80 is offline  
Old 6th June 2008, 10:04   #495  |  Link
SpAwN_gUy
Junglist
 
SpAwN_gUy's Avatar
 
Join Date: May 2003
Location: Belarus, Minsk
Posts: 298
Quote:
Originally Posted by squid_80 View Post
(Who uses the extremely slow reference IDCT anyway?)
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)
SpAwN_gUy is offline  
Old 6th June 2008, 13:02   #496  |  Link
GrofLuigi
Member of a Library
 
Join Date: Oct 2002
Posts: 463
Quote:
Originally Posted by squid_80 View Post
(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
GrofLuigi is offline  
Old 6th June 2008, 17:07   #497  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,312
Same for me.
jpsdr is offline  
Old 8th June 2008, 11:12   #498  |  Link
Tima
Registered User
 
Join Date: Aug 2004
Location: Russia, Novosibirsk
Posts: 157
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!
Attached Files
File Type: rar RV10.d2v.problem.sample.rar (99.3 KB, 24 views)
Tima is offline  
Old 8th June 2008, 13:48   #499  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,924
@Tima

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

This doesn't affect the decoding, right?
Guest is offline  
Old 8th June 2008, 17:10   #500  |  Link
Tima
Registered User
 
Join Date: Aug 2004
Location: Russia, Novosibirsk
Posts: 157
The bug with wrong cell ids -- doesnt affect decoding.

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

Working on delivering vob parts to you..
Tima is offline  
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:01.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.