levels in video

[torwart]

hello.

the target is to convert video from yuy2(vhs capture) to rgb24. and to do it right. as i know ycbcr has 16-235 luma range and rgb 0-255. so how to convert it and not to loose in quality?
the only thing that worked is :

avisource("f:\1.avi")
ColorYUV(levels="TV->PC")
converttorgb24(matrix="pc.601",interlaced=true)

and i think that this works, because the color(brightness an so on...) is absolutly the same(on eye) as it
is in my capture file. file is uncompressed yuy2 720 x 480 ntsc. is it right script?

if it is possible also tell me why when i write ColorYUV(levels="TV->PC") i have one color gamma, but when i write converttorgb24(matrix="pc.601",interlaced=true) after that, the gamma changes. logically it has to be the same because quantity of levels is the same or it is mistake?

this convertion is needed for editing in premiere pro. i need best quality that could be.

:thanks:

[sneaker_ger]

if it is possible also tell me why when i write ColorYUV(levels="TV->PC") i have one color gamma, but when i write converttorgb24(matrix="pc.601",interlaced=true) after that, the gamma changes. logically it has to be the same because quantity of levels is the same or it is mistake?

For displaying your player has to convert to RGB first, and players usually assume TV levels. So basically when opening a script with only "ColorYUV(levels="TV->PC")" most players will still assume the source is TV, so another "TV->PC" conversion is done.

[Keiyakusha]

Why you want to convert it to RGB before loading into premiere? I believe premiere is able to handle this task by himself.
Anyway, for conversion YUV->RGB you should use converttorgb24() command only (with right matrix setting depending on your source).

[Yellow_]

hello.

the target is to convert video from yuy2(vhs capture) to rgb24. and to do it right. as i know ycbcr has 16-235 luma range and rgb 0-255. so how to convert it and not to loose in quality?
the only thing that worked is :

avisource("f:\1.avi")
ColorYUV(levels="TV->PC")
converttorgb24(matrix="pc.601",interlaced=true)

When you say you know YCC is 16-235 luma do you mean you've checked your source or that you assume all YCC is 16-235. It isn't necessarily the case.

if it is possible also tell me why when i write ColorYUV(levels="TV->PC") i have one color gamma, but when i write converttorgb24(matrix="pc.601",interlaced=true) after that, the gamma changes. logically it has to be the same because quantity of levels is the same or it is mistake?

That depends on what your player is doing with it's YCC to RGB conversion. After the TV->PC jaz it's still YCC and your player is handling the conversion to RGB.

If you do it for the player by adding the second line and it shifts levels then assume your player is not doing the right conversion of levels and or matrix to suit your source.

[torwart]

so all i need is converttorgb24(matrix="rec601",interlaced=true) and thats it? and it will be real rgb with levels from 0 to 255?
i cant beleive to players. they all show different gamma.

__________________________________________________________________________________________________________

now i understand. i have read avisynth documentation. :) when you want to convert from yuv to rgb you need rec601(if yor source is 16-235) and it will be automatically 0-255 in rgb. but when you need rgb to yuv you need the same rec601 and it will make 16-235 from 0-255.
correct?

[Yellow_]

If you are sure your YCC luma levels are 16-235 then rec601 if you are sure your levels are full range then PC.601.

If you are unsure exactly what your levels are then add histogram(mode="classic") and check the waveform.

[torwart]

everything is clear. thanks. now i have another question. about yv12. when i encode this 16 235 yuy2 uncompressed to xvid it becomes yv12 and levels become 0 255. it has to be like this or it is my mistake??????????? how to make them staying in 16 235???

[Yellow_]

Forgot to mention about decompressing codec previously, you need to make sure the decompressing codec you're using isn't scaling luma for you when decompressing, confusing you.

So suggest using only ffmpegsource2 & then version 2.15, not 2.16. And not DirectShowSource() if you happen to be using that.

Going from yv12 to yuy2 there's a chance levels are getting squeezed at encode or decompress without you knowing confusing you again.

[Wilbert]

about yv12. when i encode this 16 235 yuy2 uncompressed to xvid it becomes yv12 and levels become 0 255.
No it will stay [16,235]. When you play the footage it will be converted to RGB at some point and the levels are stretched to [0,255] (well in many cases): http://avisynth.org/mediawiki/Luminance_levels

[torwart]

i made an experiment. only lagarith lossless codec(yv12) stayed in this range(16-235). other codecs like divx, xvid, avc h264 changed this range. i know it from coloryuv(analyze=true) and histogram. i think you have the same problem.....

[Keiyakusha]

this probably means you have something horribly wrong with decoding chain setup... or maybe videocard drivers setup, or both. This is the most usual places where it goes wrong.
EDIT: take some RGB image (maybe black to green gradient so it will be super easy to see levels just by eye, or maybe vdub's color cube will do), make video out of it, convert it to YV12 [ converttoyv12() ] and encode as h264. Then check if everything is ok, it should be 16-235. If not - try to check decoders, drivers and stuff.

[torwart]

yes, but how can setup or videocard affect to avisynth script opened in virtual dub??? every video file except lagarith showed levels more than 16-235.
i just take my capture file(uncompressed yuy2) and convert it to xvid, divx and h264. after this i am writing script for every file separately. in script i have only avisource and after goes coloryuv(analyze=true) and it shows for luma more than max and min 16-235.......

[Yellow_]

If you're taking YCC through vdub ensure you are using Fast Recompress & not Full Processing. FP introduces RGB into the process.

[torwart]

here are screenshots


before. this is my yuy2
http://s60.radikal.ru/i167/1201/f7/8eff77ff95e2.jpg

after. this is xvid. convertion was made in fast recompress mode in virtual dub

http://s013.radikal.ru/i325/1201/95/7a00070dc5cd.jpg

[poisondeathray]

Something weird is going on with your uncompressed YUY2 decoding - look at the histogram, see the banding, and how it's not visible in the xvid version ? It's almost as if you have another filter causing a clamp to Y' 16-235

Post your full script. Is it only AVISource() ?


yes, but how can setup or videocard affect to avisynth script opened in virtual dub???


video card doesn't affect actual processing, unless you are using a filter that specifically relies on video card (e.g fftgpu, NLmeansCL)

Otherwise , only the appearance in the vdub pane is affected. Underlying video is unaffected. If you uncheckmark "use directx" in the display options then the video overlay isn't used for the output pane either

[torwart]

yes there is a banding. you are right. in script i have only avisource and after goes coloryuv(analyze=true) and histogram. this file is a capture from vhs. uncompressed yuy2.
that's all. something is happening........ :)

[poisondeathray]

Can you post a few second sample of the source to a free hosting site e.g. mediafire.com , sendspace.com

[torwart]

here it is


http://www.megaupload.com/?d=1WCB1YA6

[poisondeathray]

It doesn't have to be that big a sample :) just a second or two to check the levels

While you are waiting, check to see if FFVideoSource() does the same behaviour with the levels, instead of using AVISource() . AVISource will rely on VFW system installed codecs, but FFVideoSource will run independent of that

But that still doesn't explain the difference. Even if input levels are screwed up, the same screwed up input levels should be in the xvid export when you use fast recompress in vdub

[torwart]

ffvideosource shows me green screen :) it cant open it....

[poisondeathray]

hmmm not sure why it's happening, but I can confirm your observations

lossless codecs appear to be fine (ut video codec, huffyuv, lagarith)

not sure why there is a discrepancy

[IanB]

The Loose Minimum and Maximum values are very similar as is the Histogram distribution, so there does not appear to be any gross levels mismatch like [16-235] versus [0-255].

The extraneous values maybe bad edge condition handling. As a test crop off 16 edge pixels all round before the analyse and histogram. i.e. only analyse the centre of the image....source...

Crop(16, 16, -16, -16)
coloryuv(analyze=true)
Histogram()

[Keiyakusha]

I have no troubles encoding this file to any format without changing levels. As was said, if you using avisource or directshowsource something is broken for you. Yes levels in this file are not exact 16-235 to begin with. nothing to be surprised about here, this is common if not say normal.
FFMS2 can't open this file. Not sure why but I guess some (or all? too lazy to check) uncompressed formats are not supported.
I opened this file with the fillowing graph: Filesource (async) eee.avi -> LAV Splitter
Then encoded with not so recent x264. And checked result with FFMS2.
coloryuv(analyze=true) shows that levels do change just a bit here and there (+/- ~2 Loose Minimum and Maximum), but that's normal. This is how encoder works, these are various artifacts and stuff. The worse encoding quality, the higher will be difference. What matters is that actual brightness is the same. Of course with lossless encoding everything stays as it was.

[poisondeathray]

Yes, there aren't big changes, but a delta 5 or 6 on a 0-255 scale is 2.3%. I was expecting maybe a delta of 1 or 2. Even cineform (medium preset) ~22Mb/s shows this difference

It seems the lossy compression smooths out the banding in the histogram, even if you specify interlaced encoding for the various lossy encoders

[Keiyakusha]

So that's was the problem? You guys sure can find problem where it doesn't exist... I though when I'll encode this file I'll see how overal brightness will magically become 2 times higher, blacks and whites will be totally crushed and overall it will be unwatchable... ^__^

[poisondeathray]

I think that's what he was concerned about. I agree it's not a huge problem, and even if it was, just use a lossless format

(but how NLE's treat "lossless" formats is another story...) :)

[torwart]

thank you gyes for help!! ofcourse you are right this is not a big problem, but why is it happening??? :)) it is a mistery for me....