same mp4 opened in VD and avisynth is different

[marcorocchini]

HI, PLEASE FOR **** ONLY, THANKS

the same mp4 have different image (contrast? luma? gamma?) when opened, alwais in virtualdub, but one is input avisynth with the ffms2 and one the ffmpeg plugin for virtualdub

Please ***, can you tell me why? many thanks

what is the "right" image?

p.s: if I open the same .mxf (from xdcam camera) both virtualdub and avisynth have identical image



General
Complete name : C:\gopro\GOPR1248.MP4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1
File size : 37.5 MiB
Duration : 15s 240ms
Overall bit rate mode : Variable
Overall bit rate : 20.6 Mbps
Encoded date : UTC 2013-01-01 20:24:22
Tagged date : UTC 2013-01-01 20:24:22
AMBA :

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 1 frame
Format settings, GOP : M=1, N=15
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 15s 240ms
Bit rate mode : Variable
Bit rate : 20.2 Mbps
Maximum bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.390
Stream size : 36.7 MiB (98%)
Title : GoPro AVC
Language : English
Encoded date : UTC 2013-01-01 20:24:22
Tagged date : UTC 2013-01-01 20:24:22
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 15s 232ms
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 238 KiB (1%)
Title : GoPro AAC
Language : English
Encoded date : UTC 2013-01-01 20:24:22
Tagged date : UTC 2013-01-01 20:24:22

Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 15s 240ms
Time code of first frame : 20:24:21:00
Time code settings : Striped
Language : English
Encoded date : UTC 2013-01-01 20:24:22
Tagged date : UTC 2013-01-01 20:24:22

[poisondeathray]

They are the same in your screenshot. Maybe you posted wrong screenshot ?

[marcorocchini]

this is avisynth

an this virtualdub

[poisondeathray]

I suspect your gopro videos probably have a full range flag in the bitstream. Your screenshot taking in vdub is incorrect with avisynth (rec matrix) , probably wrong colors as well (rec601)

If YUV data is decoded at full range, you need to take screenshots (convert to RGB) at full range

So probably neither are "correct" in terms of RGB representation

[marcorocchini]

it's the first frame of exported YUY2 uncompressed from the same source GOPR1262.MP4



Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.2
Format settings, CABAC : Si
Format settings, ReFrames : 1 frame
Format settings, GOP : M=1, N=15
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 3s 680ms
Bit rate mode : Variabile
Bit rate : 31,6 Mbps
Maximum bit rate : 30,0 Mbps
Width : 1.920 pixel
Height : 1.080 pixel
Display aspect ratio : 16:9
Frame rate mode : Costante
Frame rate : 50,000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bit
Scan type : Progressivo
Bits/(Pixel*Frame) : 0.305
Stream size : 13,9MiB (93%)
Title : GoPro AVC
Language : Inglese
Encoded date : UTC 2013-02-03 18:45:34
Tagged date : UTC 2013-02-03 18:45:34
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

the same attached .mp4 open with:

1) totalcode 3.1.0 build 16757
2) avisynth 2.5.8.6 ffms2 (v?) 21.05.2013

FFVideoSource("C:\gopro\GOPR1262.MP4")
ConvertToYUY2(interlaced=false)
AssumeFPS(50)

3) Edius 6.01
4) virtualdub for cats (modify by a cat for timecode insertion speedrazor) 1.10.4 FFMpeg plugin 0.8.1.4configured as


but seems to me that nothing change also even I try to check the "Autodetect601/709,Full/Limited" checkbox I try to check the "If undetected and H>720 or W>1280" checkbox

Because gopro cannot (or not?) generate bars, any evaluation is to be done by eye?
Seems to me that I have cat'eye the "best" is the edius levels-decompressing

Seems to me: levels of totalcode and avisynth are the same, identical. It's levels are slightly different (in gamma?) from levels of edius, that are also different from levels of virtualdub that are shure wrong

If I load the same .mxf in totalcode/avisynth/edius/virtualdub: levels are exactly the same.
So is is more than probable that the matter is as you said, but how can I resolve in virtualdub? ^^

[poisondeathray]

It's as I said above - there is a full range flag

Decoders and software are inconsistent when handling this, as you can see

There is no "absolutely correct" way to do it; it depends on your workflow, whether you're working in RGB or YUV - But for broadcast submission, you need legal levels. That is absolute

So you either need to clamp levels to legal range, or use a decoder that outputs legal range in YUV. If working in RGB (maybe you use vdub RGB filter?), you also need to take that into consideration, otherwise you might clip data, lose data

For example, ffms2 in avisynth will output full range 0-255 Y' levels. So in order to take proper screenshot or see proper preview in RGB, you must either clamp levels, or use PC Matrix to convert to RGB

Same with the matrix coefficients, 709 should be used



1st one is incorrect (look at the waveform, there are "illegal" levels , < Y=16), look at the loss in shadow details in the dolls' chest. It's full range YUV, by standard Rec709 matrix is used to take screenshot





2nd one is "legalized" (look at shadow details are now visible), but in a "dumb" way . It's clamped, but notice full legal 16-235 dynamic range isn't used (the highlights are brought down compared to the other) . But this is what is normally used, because it's "easy" to do





But the "optimal" way would be to manually adjust levels per scene

[marcorocchini]

For example:
no rgb, simply I open that in virtualdub and save-avi
My workflow is YUV (or I think) no RGB
Please poison I opened it in virtualdub, with the ffmpeg plugin decoder the GOPR1262.MP4 with the plugin V0.8.1.4 configured as mentioned above

For now I consider the case I have to resize it into 720x576 so I try this set of filter in virtualdub:



Thr AutoYUY2 is this as virtuladub plugin:
https://www.dropbox.com/s/0afcikgz857nn5x/Filtres_JPSDR.vdf?dl=0

The result seems to me as the edius'one, but think you that procedure is correc?

[poisondeathray]

Check the output file, if levels are legal and shadows weren't clipped, then workflow is probably correct , at least in terms of levels.

(But there might be other issues)

For example, if file is progressive (you're resizing before interlacing), then vdub's resize filter probably shouldn't be set to interlaced resizing

[marcorocchini]

I attach 2 .avi uncompressed: one removing the resize filter, so image is 1920x1080. And a second with resize filter

(But there might be other issues) = also chroma ghost? hoewver seems don't do chroma ghost using other files

yes is progressive 50fps but if I uncheck the interlace box, I see a lot of aliasing in image details... I know you tell me the low pass filter, but my target (in this proof) is 50i SD: in alternative what is the correct procedure to resizing in virtualdub?

[poisondeathray]

I don't know what the correct procedure is in vdub. It just doesn't make sense to me to checkmark "interlaced", when it's progressive . But use whatever works

The levels in 720x576 output file are fine.

But you cannot test effectiveness of lowpass or motion problems, unless you have motion You need to check a scene with more motion. Pan across a picket fence or roof tiles (anything with man made lines). If you see buzzing lines, aliasing, you probably need to low pass more

(Blindly lowpassing everything isn't always the best method either - In static scenes, quality is deteriorated. (It's done anyways, because it's "easy") )

You also need to change the colors of the SD file (601) e.g using colormatrix or something equivalent

[marcorocchini]

I have check in fast motion and seems to me it don't do chroma ghost or other problems, seems identical at the output of edius also as "definition"

[poisondeathray]

Ok.. if you say so...

BTW Color is wrong for SD (you kept it same as HD)

[marcorocchini]

I says: seems identical... not are identical


now I do some proof, however shure there be something wrong

[marcorocchini]

errata corrige: edius produce a YUY2 SD output that in my monitor result aliasing, more "defined" but with aliasing (not too aliasing) but it's aliasing

I try to uncheck the interlace flag to see if result is identical to the one of edius

[poisondeathray]

[Attachment 27882 - Click to enlarge]

I says: seems identical... not are identical


now I do some proof, however shure there be something wrong

You can prove it to yourself

A) Convert HD image to RGB using 709 (after legalizing levels , if they need to be fixed). Scale it down in RGB to SD dimensions

B) Take your SD image and convert to RGB using 601

(A) should look identical to (B) in terms of colors. But it doesn't. That's is proof that it's done incorrectly



More proof- If you add colormatrix(mode="rec.709->rec.601", clamp=0) to the SD file, it now looks correct. This means you didn't convert the colors in the SD file to 601

errata corrige: edius produce a YUY2 SD output that in my monitor result aliasing, more "defined" but with aliasing (not too aliasing) but it's aliasing

I try to uncheck the interlace flag to see if result is identical to the one of edius

I don't use edius, but most NLE' s have a "reduce interlace flicker" or similar function

[marcorocchini]

mm a little complicated for a cat but I try

[marcorocchini]

because you think the gopro write mp4 with a flag that tell to the decompressor to use RGB instead of YUV?

[poisondeathray]

because you think the gopro write mp4 with a flag that tell to the decompressor to use RGB instead of YUV?

No, it's a full range flag. Some decoders obey the flag others ignore it. Eitherway, decoder itself should output YUV, not RGB

It's also flagged BT.709. Again, some decoders obey the flag, others ignore it.

If you open mediainfo it will say BT.709.

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

If you use ffmpeg -i input.mp4, it will say yuvj420p (pc, bt709) . So it has both 709 flags, and Full range flags

After the decoder, it's up to other software chain for conversion to RGB in terms of levels (PC vs. Rec), and matrix coefficients (709 vs. 601). Some obey flags, some ignore.

[poisondeathray]

mm a little complicated for a cat but I try

Ok you should know this by now:

(I ignore interlace, this is just to check if colors are correct)

A)

FFVideoSource("GOPR1262.MP4")
SmoothLevels(0,1,255,16,235) # "dumb" clamp of levels to legal range
ConvertToRGB24(matrix="rec709")
Spline36Resize(720,576)

B)

AVISource("GOPR1262withresize720_576.avi")
ConvertToRGB24(matrix="rec601")

You tell me if A and B look the same in terms of colors


Now

C)

AVISource("GOPR1262withresize720_576.avi")

ColorMatrix(mode="rec.709->rec.601",clamp=0)

ConvertToRGB24(matrix="rec601")

[marcorocchini]

where I can download smoothlevels?

[poisondeathray]

where I can download smoothlevels?

It's part of smoothadjust.dll.

Or instead you can use Levels() the internal filter

Levels(0,1,255,16,235, coring=false, dither=true) if you have avisynth 2.6

or even
Levels(0,1,255,16,235 , coring=false) , since we are just checking colors quickly

It's just legalizing the full range output of ffms2 by clamping the output to 16-235


If you wanted to be more precise, then the interlaced switch should be true for RGB conversion and colormatrix for the SD file, but we dont' really care because it's just a quick check to see if colors are correct

[marcorocchini]

install now AviSynth_130918.exe that should be avisynth 2.6.0

using scriptA.avs this:

FFVideoSource("c:\gopro\GOPR1262.MP4")
Levels(0,1,255,16,235, coring=false, dither=true)
ConvertToRGB24(matrix="rec709")
Spline36Resize(720,576)

color from scriptA and scriptB are different

From scriptC I get this

[poisondeathray]

color from scriptA and scriptB are different

That's all that matters. That's your proof

If your SD file was correct , they should look the same in terms of colors

From scriptC I get this

[Attachment 27883 - Click to enlarge]

different versions of colormatrix. Some are clamp=0, some are clamp=false

It doesn't matter, just take out the clamp argument. This is just a quick check anyway and levels have already been "fixed"

[marcorocchini]

here the color differences seems low but in the broadcast monitor seems that scriptB does not have the rec.709-->rec.601 colormatrix conversion

[marcorocchini]

different versions of colormatrix. Some are clamp=0, some are clamp=false

It doesn't matter, just take out the clamp argument. This is just a quick check anyway and levels have already been "fixed"

however if I see weell image output from my script seems that mine have a litlle lower quality of the edius'one

[poisondeathray]

here the color differences seems low but in the broadcast monitor seems that scriptB does not have the rec.709-->rec.601 colormatrix conversion

Script B is directly viewing the RGB conversion with 601 matrix. Since it's different than "A" (which is HD file viewed with 709 matrix), that is proof that your SD file is incorrect

Since script C looks like A (or very similar), that again is more proof, because the colormatrix is 709->601 (as if it had used 601 in the first place)

Does explanation make sense ?

however if I see weell image output from my script seems that mine have a litlle lower quality of the edius'one

We are not looking at quality with these scripts, just quick test comparing if colors are correct (otherwise more care would be taken with the interlaced switches for the colormatrix, rgb conversion)

[marcorocchini]

poison I wonder, in general, in an avisynt script

the "converttoyuy2()" are to be place top or bottom the colormatrix? top or bottom the resize

supposing I have to resize and rec.709-->rec.601

what the correct sequence?

ffvideosource(input)
converttoyuy2
resize
colormatrix

?
or ffvideosource
colormatrix
resize
converttoyuy2

or others?

[poisondeathray]

Since source has full range flag and you use ffvideosource, you need to legalize levels first

Order of Converting to YUY2 doesn't matter, but it will be very slightly faster at the bottom. (It's still progressive at this point, so interlaced=false, for colormatrix as well)

[marcorocchini]

or, better, please poison considering this gopro file, please can you tell to the cat what is the correct way to do a script that convert to sd?

considering that source is 50fps progressive and target is 50i, I hipotyze

ffvideosource(gopro)
converttoYUY2(interlace=false)
colormatrix 709->601
Iresize(720,576)

but is this the correct sequence for this case?

[poisondeathray]

or, better, please poison considering this gopro file, please can you tell to the cat what is the correct way to do a script that convert to sd?

considering that source is 50fps progressive and target is 50i, I hipotyze

ffvideosource(gopro)
converttoYUY2(interlace=false)
colormatrix 709->601
Iresize(720,576)

but is this the correct sequence for this case?

No, because IResize() is filter for interlaced resizing (where source is interlaced). GoPro video is progressive

Come on , you already know how to re-interlace from 50p . IT was discussed about a dozen times in your threads

The only difference here, is if you use FFMS2, you need to legalize levels because these GoPro videos have full range flag