[PATCH][RFC] Xv: select between Rec.601 and Rec.709
Hi all, This is a follow-up on bug #22901 (http://bugs.freedesktop.org/show_bug.cgi?id=22901). The attached patch adds functionality to select between Rec.601 and Rec.709 constants using a Xv attribute. Additionally, an 'auto-detect' setting is provided, where video with width 1280px (720p) or higher uses Rec.709, and Rec.601 is used otherwise. Auto-detection is the default. At the moment, it is only effective on r6xx/r7xx. I have not yet tested for regressions on r5xx. Cheers, -- Yang Zhao http://yangman.ca
On Jul 27, 09 23:25:51 -0700, Yang Zhao wrote:
The attached patch adds functionality to select between Rec.601 and Rec.709 constants using a Xv attribute. Additionally, an 'auto-detect' setting is provided, where video with width 1280px (720p) or higher uses Rec.709, and Rec.601 is used otherwise. Auto-detection is the default.
The autodetect is problematic - at least you should check for both width
and height, as 4:3 images in 720p will be 960x720. Also note that 480p
is a regular HD standard as well.
Or, you check out my suggestion for autodetect:
- 640x480 gets Rec. 709 (this is HD 4:3)
- Anything wider than 800 gets Rec. 709 (this includes HD 480p 16:9)
- Everything else gets Rec. 601 (this includes 720/768x480/576)
The only problematic thing will be 640x480 XVids that had originated
from DVDs - too bad, you cannot detect those. On the other hand, we
could just ignore 480p as a HD standard, as it's only a semi-HD
standard.
Comments?
Matthias
--
Matthias Hopf
2009/7/28 Matthias Hopf
On Jul 27, 09 23:25:51 -0700, Yang Zhao wrote:
The attached patch adds functionality to select between Rec.601 and Rec.709 constants using a Xv attribute. Additionally, an 'auto-detect' setting is provided, where video with width 1280px (720p) or higher uses Rec.709, and Rec.601 is used otherwise. Auto-detection is the default.
The autodetect is problematic - at least you should check for both width and height, as 4:3 images in 720p will be 960x720. Also note that 480p is a regular HD standard as well.
Or, you check out my suggestion for autodetect: - 640x480 gets Rec. 709 (this is HD 4:3) - Anything wider than 800 gets Rec. 709 (this includes HD 480p 16:9) - Everything else gets Rec. 601 (this includes 720/768x480/576)
My understanding is that Rec.709 only applies to content that is equal to or larger than 720p. 480p falls under something called "EDTV" which isn't technically HD. The definition of what is considered "HD" varies from region to region, but, AFAICS, the cut-off is fairly well defined when it comes to the colour space change. Unfortunately, this is all second-hand sources. Can anyone cite anything more authoritative? -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jul 28, 09 09:44:02 -0700, Yang Zhao wrote:
The autodetect is problematic - at least you should check for both width and height, as 4:3 images in 720p will be 960x720. Also note that 480p is a regular HD standard as well.
Or, you check out my suggestion for autodetect: - 640x480 gets Rec. 709 (this is HD 4:3) - Anything wider than 800 gets Rec. 709 (this includes HD 480p 16:9) - Everything else gets Rec. 601 (this includes 720/768x480/576)
My understanding is that Rec.709 only applies to content that is equal to or larger than 720p. 480p falls under something called "EDTV" which isn't technically HD. The definition of what is considered "HD" varies
Ok, still the 4:3 720p is an argument. So probably something like width >= 1200 || height >= 700 would be reasonable (and account for some weird broken overscan possibilities). I also remember that there was a color space that used the full 0..255 range for Y, but I don't know its specification number.
Can anyone cite anything more authoritative?
Nope, sorry.
Matthias
--
Matthias Hopf
2009/7/28 Matthias Hopf
On Jul 28, 09 09:44:02 -0700, Yang Zhao wrote:
The autodetect is problematic - at least you should check for both width and height, as 4:3 images in 720p will be 960x720. Also note that 480p is a regular HD standard as well.
Or, you check out my suggestion for autodetect: - 640x480 gets Rec. 709 (this is HD 4:3) - Anything wider than 800 gets Rec. 709 (this includes HD 480p 16:9) - Everything else gets Rec. 601 (this includes 720/768x480/576)
My understanding is that Rec.709 only applies to content that is equal to or larger than 720p. 480p falls under something called "EDTV" which isn't technically HD. The definition of what is considered "HD" varies
Ok, still the 4:3 720p is an argument. So probably something like
width >= 1200 || height >= 700
would be reasonable (and account for some weird broken overscan possibilities).
I'm not sure 4:3 with 720 lines is an accepted common resolution. It's certainly not part of ATSC. My primary intention with checking only the width is to handle media that's been cropped from a 720p source to get rid of letter boxing. This is not uncommon for cinema in 1.85:1 and 2.39:1. To add to the confusion, I have media labelled as "HD" at 960x544 which is stretched to 1280x544 using Xv, which is then used as the effective resolution of the video. The sum of all this is that I implemented something which categorizes a video source as being encoded with Rec. 709 only when it is definitely fits the size requirement of being "HD", ignoring the grey area between HDTV and SDTV.
I also remember that there was a color space that used the full 0..255 range for Y, but I don't know its specification number.
xvYCC? http://en.wikipedia.org/wiki/XvYCC I'm not sure if it's actually in common use. Easy to add, if it has the same conversion constants as Rec.709. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jul 28, 09 11:28:07 -0700, Yang Zhao wrote:
Ok, still the 4:3 720p is an argument. So probably something like width >= 1200 || height >= 700 would be reasonable (and account for some weird broken overscan possibilities).
I'm not sure 4:3 with 720 lines is an accepted common resolution. It's certainly not part of ATSC.
Good question.
My primary intention with checking only the width is to handle media that's been cropped from a 720p source to get rid of letter boxing.
4:3 could result of cropped video from 720p source as well. IMHO something like my test above would deal with all known good resolutions, but...
This is not uncommon for cinema in 1.85:1 and 2.39:1. To add to the confusion, I have media labelled as "HD" at 960x544 which is stretched to 1280x544 using Xv, which is then used as the effective resolution of the video.
Eeck, yes. Similar to 1440x1080 streched to 1920x1080, I assume. I have *no* idea how to deal with that, and whether that's a reasonable medium to assume to be recorded with Rec. 709 in mind.
I also remember that there was a color space that used the full 0..255 range for Y, but I don't know its specification number. xvYCC? http://en.wikipedia.org/wiki/XvYCC
Could be.
I'm not sure if it's actually in common use. Easy to add, if it has
I had one file once, that's as much as I know.
the same conversion constants as Rec.709.
I'm not exactly sure - the range 0-15 must change the scaling factors.
Also, as long as we don't know the color range of the monitor, this
discussion is probably pretty moot.
CU
Matthias
--
Matthias Hopf
2009/7/29 Matthias Hopf
On Jul 28, 09 11:28:07 -0700, Yang Zhao wrote:
My primary intention with checking only the width is to handle media that's been cropped from a 720p source to get rid of letter boxing.
4:3 could result of cropped video from 720p source as well. IMHO something like my test above would deal with all known good resolutions, but...
4:3 cropped from 720p would be silly. That defeats the point of the original being in 720p to begin with. I've certainly not seen it done and it doesn't make any sense to me to do such a thing. (Other than for video composition, in which case the final work is re-encoded anyway)
This is not uncommon for cinema in 1.85:1 and 2.39:1. To add to the confusion, I have media labelled as "HD" at 960x544 which is stretched to 1280x544 using Xv, which is then used as the effective resolution of the video.
Eeck, yes. Similar to 1440x1080 streched to 1920x1080, I assume. I have *no* idea how to deal with that, and whether that's a reasonable medium to assume to be recorded with Rec. 709 in mind.
IMO, at this point, rips with weird dimensions are not worth worrying about. There are a few sources of 720p and higher video that we can be sure are meant to be Rec.709: HDTV broadcasts, HD-DVD/BluRay videos, and non-grey-area websites that provide media in HD (AppleTrailers, etc). HD videos from these sources will always have width of 1280 or 1920. Although, if we want to default media in the poorly-defined zone between EDTV and HD to Rec. 709 instead of Rec. 601, I propose that we use the heuristic: if (width >= 928) use_Rec709; This should exclude all DVD sources--including DVD content re-encoded at their intended resolution (720x480 presented in 852x480)--and STDV and EDTV for both NTSC and PAL. -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jul 29, 09 09:36:46 -0700, Yang Zhao wrote:
2009/7/29 Matthias Hopf
: 4:3 could result of cropped video from 720p source as well. IMHO something like my test above would deal with all known good resolutions, but...
4:3 cropped from 720p would be silly. That defeats the point of the original being in 720p to begin with. I've certainly not seen it done and it doesn't make any sense to me to do such a thing. (Other than for video composition, in which case the final work is re-encoded anyway)
If the source is 4:3 and had just been encoded in 720p or 1080p for transmission it makes a lot of sense, and I've already done this myself with HDTV transmissions of old movies (color, not b&w, where color space discussions are obviously moot). Not encoding black always makes sense as it saves bits.
Eeck, yes. Similar to 1440x1080 streched to 1920x1080, I assume. I have *no* idea how to deal with that, and whether that's a reasonable medium to assume to be recorded with Rec. 709 in mind.
IMO, at this point, rips with weird dimensions are not worth worrying about. There are a few sources of 720p and higher video that we can be
Agreed.
Although, if we want to default media in the poorly-defined zone between EDTV and HD to Rec. 709 instead of Rec. 601, I propose that we use the heuristic:
if (width >= 928) use_Rec709;
This should exclude all DVD sources--including DVD content re-encoded at their intended resolution (720x480 presented in 852x480)--and STDV and EDTV for both NTSC and PAL.
I like this much better.
The only source of confusion would IMHO be PAL DVD 16:9 content encoded
to 1:1 pixel aspect (which creates 1024x576) - but who on earth would
blow up 720x576 anamorph video like that? If somebody does he deserves
to get the wrong color space :-P
Can you update your patch? I'd love to include it then.
Thanks
Matthias
--
Matthias Hopf
2009/7/29 Matthias Hopf
Although, if we want to default media in the poorly-defined zone between EDTV and HD to Rec. 709 instead of Rec. 601, I propose that we use the heuristic:
if (width >= 928) use_Rec709;
This should exclude all DVD sources--including DVD content re-encoded at their intended resolution (720x480 presented in 852x480)--and STDV and EDTV for both NTSC and PAL.
I like this much better.
The only source of confusion would IMHO be PAL DVD 16:9 content encoded to 1:1 pixel aspect (which creates 1024x576) - but who on earth would blow up 720x576 anamorph video like that? If somebody does he deserves to get the wrong color space :-P
Can you update your patch? I'd love to include it then.
Will do. I'll update the patch and push it later today. Finally got my commit access. :) Cheers, -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jul 29, 09 09:52:29 -0700, Yang Zhao wrote:
Can you update your patch? I'd love to include it then. Will do. I'll update the patch and push it later today. Finally got my commit access. :)
Yoohay!!1
That was pretty fast, don't you think? ;-)
Matthias
--
Matthias Hopf
participants (2)
-
Matthias Hopf
-
Yang Zhao