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 > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th November 2011, 19:48   #1  |  Link
tiffytaffy
tiffytaffy
 
Join Date: Oct 2011
Location: Germany
Posts: 9
YUV PC/TV question

I know there are a lot of discussion about this topic and I read many of them. Can someone explain why I get a luma Y minimum of 7 instead of 16 with following scrip:

ColorBars(pixel_type="YV12")
ColorYUV(analyze =true)

Thanks
tiffytaffy is offline   Reply With Quote
Old 17th November 2011, 20:35   #2  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,431
The lower part of the color bars (the 'pluge') contains a section (-4 IRE) that is 'blacker than black', with Y=7, used in adjusting for correct brightness of your monitor/TV.

See http://avisynth.org/mediawiki/ColorBars.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 20th November 2011, 17:25   #3  |  Link
tiffytaffy
tiffytaffy
 
Join Date: Oct 2011
Location: Germany
Posts: 9
@Gavino
Ok, thank you.

Here my next problem that belongs to this topic. I have an AVI source file with full range in RGB24
(sorry but I can't upload any image. Get an error: not valid)
I used following script to convert it to YV12 16-235

AviSource("test.avi",audio=false,pixel_type="RGB24").AssumeTFF()
ConvertToYV12(matrix="PC.709",interlaced=false)
SmoothLevels(preset="pc2tv",gamma=0.90, Lmode=2,darkSTR=100, smooth=100,dither=50)
ColorYUV(analyze =true)

This works fine for me. ColorYUV reports a range between 16 and 235. I used the same script(without ColorYUV(analyze =true)) to encode wit MeGui :

program --crf 20 --colormatrix bt709 --output

After that I double checked the target file(using DGAVC Index)

AVCSource("test.dga")
ColorYUV(analyze =true)

Now ColorYUV reported a range between 0 and 255. Why not 16 and 235?
What's happened?
tiffytaffy is offline   Reply With Quote
Old 20th November 2011, 20:21   #4  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
why you went through such a weird way to convert your source from PC to TV scale is beyond me, but what you sse after encoding... If picture looks right and ColorYUV reports out of range pixels - these may be just artifacts added during encoding.
Keiyakusha is offline   Reply With Quote
Old 23rd November 2011, 18:44   #5  |  Link
tiffytaffy
tiffytaffy
 
Join Date: Oct 2011
Location: Germany
Posts: 9
Is there a way to encode without out of color range artifacts? I looked at a commercial blue-ray and noticed that the video is completely in range(16-235). How do they do this?
I use a little Sony Cyber-shot for my videos and ColorYUV(analyze=true) reports me a range from 16 to 255. Maybe it should be 16-235 and the internal h264 encoder add artifacts too. Is it true that consumer camcorder normally use TV-Range? I can't find any information about this for my product.

When I watch a clip on my TV I would assume that 16 is black and 235 is white. So write this script and create a blue-ray disc:

left = BlankClip(length=30000, width=960, height=480, fps=24, color=$FFFFFF,pixel_type="YV12",audio_rate=48000)
left = AddBorders(left, 0, 300, 0, 0, $000000)
left = AddBorders(left, 0, 0, 0, 300, $191970 )
left=ColorYUV(left,analyze =true)

right = BlankClip(length=30000, width=960, height=480, fps=24, color=$FFFFFF,pixel_type="RGB32",audio_rate=48000).killaudio()
right = AddBorders(right, 0, 300, 0, 0, $000000)
right = AddBorders(right, 0, 0, 0, 300, $191970 )

right=ConvertToYV12(right,matrix="PC.709",interlaced=false)
right=ColorYUV(right,analyze =true)
comb = StackHorizontal(left, right)

return comb

But on my TV the left part has no black and white. It looks washed out. I guess I misunderstand something, but what?
tiffytaffy is offline   Reply With Quote
Old 23rd November 2011, 19:00   #6  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
I believe there is someone who have better ideas of what is going on with your workflow but since noone is answering, maybe they don't really understand where is the problem?
Personally I don't understand what your goals is.
You have RGB source. I assume this source has PC range levels as normal RGB usually would be, you using Converttoyv12() (with the right matrix= depending on resolution) before encoding and that's all you need to do. If there will be some out of range pixels after encoding - this is not something you should worry about. Its how encoder works, it doesn't means your blacks is no longer black or something like that.
converttoyv12(matrix="Rec601") is for SD resolution, converttoyv12(matrix="Rec709") is for HD. You shouldn't use PC.709.

If resulting file looks wrong after that then you have playback problems which are pretty common.

Last edited by Keiyakusha; 23rd November 2011 at 19:16.
Keiyakusha is offline   Reply With Quote
Old 23rd November 2011, 19:22   #7  |  Link
Ghitulescu
Registered User
 
Ghitulescu's Avatar
 
Join Date: Mar 2009
Location: Germany
Posts: 5,769
Quote:
Originally Posted by tiffytaffy View Post
Is it true that consumer camcorder normally use TV-Range? I can't find any information about this for my product.
It depends on the camcorder, some do clip at 235, while others do record whiter-than-white signals (so up to 255) to avoid the clipping. This is generally not noticed since there's no white limitation on TVs (there is however a PAL/NTSC limitation in terms of signals).
__________________
Born in the USB (not USA)
Ghitulescu is offline   Reply With Quote
Old 26th November 2011, 23:53   #8  |  Link
tiffytaffy
tiffytaffy
 
Join Date: Oct 2011
Location: Germany
Posts: 9
Thank you for answering.
My RGB-AVI source was only a test case. My workflow is:

Source:
Camcorder source: MTS container with h264 stream, 50fps progressive 1920x1080, YV12, color range=unknown. Now I assume it is 16-255 or the internal camcorder encoder creates artifacts and it is 16-235.

Target:
Samsung LCD TV. The TV has the color options AUTO and NATIVE. After reading in some forums, I think native means 0-255. AUTO is not clear. It could be 16-235 or the TV try to analyze and detect the color range. That is why I wrote the test script above(with blank clip and borders). With this script AUTO and NATIVE shows no difference on TV. Left side looks gray and right side looks black and white. This let me assume that the AUTO modus analyze the video. and detect the correct range from 0 to 255. In this case my problem is following: When encoding with x264 creates out of range artifacts, then the TV have to detect a wrong color range.
However, your answers were helpfully for me. I guess you are right and it is not a real problem. I only try to understand the correlations. I think in my case it is a good solution, when I don't convert the color range and let the thing as they are.
tiffytaffy is offline   Reply With Quote
Old 27th November 2011, 00:01   #9  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,389
When checking the difference between "Auto" and "Native" on a Samsung LCD TV, don't use greyscale clips. Instead, use something with strong red colored objects. Then you'll see a difference. It seems to me this setting is rather related to BT.601 / BT.709 color schemes.

However you are correct - there are several things "not quite clear" about what-does-this-setting-do in Samsung TVs.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Reply

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 09:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.