Cinevision with avisynth

[ericp]

Hello guys,

not sure if this was already covered elsewhere - research didn't point anything relevant.

I'm new to AviSynth - I started using it last week because of a really particular problem.

I received a mov file (HD 1080p24) captured with Blackmagic board on a MAC - Uncompressed 8bit 422.

I need to encode this file using Cinevision for Blu-ray authoring.
This is all okay but there is a color difference between the Quicktime played on the Mac and on the PC.
Once the file is on the PC, it looks like the color range is constrained to 16-235 colors (TV ?), so I loose contrast, the blacks look grey - it's like a thin grey filter is over the video.

So since version 3.0 it seems like Cinevision accepts asv scripts - someone convinced me that it would be easy to get the right colors back directly using the script in Cinevision, no need to render the file.

This is the script I used :

QTInput("H:\Movie directory\Movie file.mov") # Quicktime Import
Levels(16, 1, 235, 0, 255, coring=false)

This shows the correct color (at least, it seems so !)
BUT once it is rendered, the playback looks jittered as if the file was not playing realtime.
I tested on PowerDVD on my PC, I burnt a BD-r and tried on PS3 and BDP-S350 and all players showed the same effect.

So I guess something was wrong with my script because not using Avisynth shows a perfect playback.
I tried ConvertFPS(24), AssumeFrameBased, AssumeTFF and AssumeBFF with various settings but the results were all the same !

Any idea ?
Maybe something basic I missed or are avs script broken with Cinevision ?

Thanks for your help.

Eric

[ericp]

It looks like this only affect 24fps material.
Both AVI and MOV files are rendered with this jerkyness if I use AviSynth.

25 and 23.976 material are correctly encoded.

Now, is there anything specific when working on 24p material ?

[poisondeathray]

What does avisynth report the fps as? You could use info() for example

If you open the .avs script in vdub, or avsp, and step through frames, does anything look out of the ordinary?

[ericp]

Thanks for the advice.
Here is what info() gives :
Frame: 0 of 224257
Time: 00:00:00:000 of 02:35:44:041
Colorspace: YUY2
Width:1920 pixeles, Height:1080 pixels.
Frames per second: 24.0000 (2400/100)
FieldBased (Separated) Video: NO
Parity: Bottom Field First
Video Pitch: 3840 bytes.
Has Audio: NO

In VirtualDub nothing strange between frames... it looks normal to me - but I can't play it realtime due to disk speed.
It's on an external USB2 drive.

[ericp]

When I output a segment using VirtualDub, the result seems ok.

So this must be related in a way to CineVision.
As I have a Sonic Support account, I'll ask them but I'm pretty sure that since I'm using Avs and they are not supporting it they'll reply that it's not of their concern...

If anyone else as an idea of what I could try next, you're welcome !

Eric

[mp3dom]

Yes, it's a problem of CineVision. I've the same here, but works with 50i/60i. It's strange anyway that with the original QT you have a colorshift. Have you correctly selected the right colorspace?

[ericp]

By selecting the right colorspace, do you mean the pixel aspect in CineVision input ?
I tried different ones, but with same results.

Also the original mov file played in Quicktime player on PC shows the color shift.
This is not the case when played on MAC.

It seems it is a known problem when working on PC on a MAC-captured quicktime.

But maybe there is another workaround than avisynth ?

Here I'm rendering a new file through VirtualDub with AviSynth filter.
It takes time (4h40 for my 2h35 long feature) and HDD storage (over 900Gb) but it seems the only viable solution now.
I tried on a short segment with YUY2 export AVI - importing it and rendering in Cinevision and it looks fine.

Sonic Support didn't reply for now...

[mp3dom]

Which codec have you used for capturing? Considering the filesize seems that you're capturing in uncompressed 4:2:2 10bit. In that case try to choose v210 as source colorspace in CineVision. Another workaround (but require space) is to export your AVS file to a lossless codec (like Canopus Lossless, which is very well supported in CineVision, and it's a native YUY2 4:2:2 codec). The filesize could be reduced to about 200Gb.

The colorshift could be introduced by the container (QuickTime) so this could explain why in Windows you've a colorshift and not on Mac. In that case, and if you've captured in an uncompressed format, you can get the raw data ignoring QT (with AviSynth and the QTInput plugin). Set the parameter 'mode=1' and 'raw=xxxx' (look at the readme for all the colorspaces supported). If you've captured in 4:2:2 10b uncompressed the colorspace probably is v210. If you've captured in uncompressed 8bit 4:2:2 you can try uyvy

[ericp]

My file is uncompressed 8bit 422 - I tried every possible combination and uyvy was greyed so not possible to try it. It is possible with the avi file I tried but doesn't change the color display.

What you say about ignoring QT data is interesting but still requires AviSynth - which won't work in CineVision - so the result would be sensibly the same as I have now.
But I'll try it once I have an available workstation.

I will also try the Canopus Lossless codec which sounds great, thanks !

[ericp]

I also had many - memory allocation error - in CineVision just at the end of encodes when using avs scripts. Which is really annoying when you just spent 18h to 24h encode...
Never happened before.
Sonic didn't tell me how to avoid it. I guess it is also related to AviSynth.

[mp3dom]

If you can spend the extra space required I would do this:
AviSynth+QTInput -> Get raw data from your QT (QTInput("source.mov",mode=1,raw="uyvy")), VDub->Fast Recompress with Canopus Lossless AVI). In VDub you can already see if you have the colorshift.
Feed the AVI to CineVision choosing YUY2 colorspace as input.
Let me know.

[ericp]

I already started rendering the file in Uncompressed AVI in VirtualDub - I have some space left.
Another 2hours to get the results, I'll wait it to finish and then try your method.

[ericp]

I tried QTInput("source.mov",mode=1,raw="uyvy") also changing the raw= values and it didn't change anything from the original file...

Concerning the 16-235 -> 0-255 conversion I done, it's seems not the correct values; now the video looks more saturated - but better than original file, more close to original tape.
I'll need more testings I guess.

I also tried this method :
http://www.videocopilot.net/blog/2008/06/fix-quicktime-gamma-shift/

The colors and contrast change a bit, but not enough to get the original film look.

[mp3dom]

With the raw method, you get exactly what's captured by the card, so it's kinda strange. Are you sure that it's not the mac version that add a colorshift? Also, can you compare side-by-side the original tape (deck via external monitor) with the captured file to see if both have same colors?
It could be also a problem of color coefficients (rec601/rec709) that something is misunderstanding...

[ericp]

I really appreciate your help and ideas mp3dom, thanks !

I compared both the captured file (output from FCP through Blackmagic Multibridge) and the HD SR tape and there is indeed a very slight difference - but not the difference I see once I go to PC.
So I guess something isn't quiet right with either Blackmagic codec or board or ?...

I also tried the color coefficient change with AviSynth very early in my researchs and it didn't solve the problem.
Right now I'm trying to find the correct Levels settings to get the same aspect as the SR (or the closest possible).
What I last tried was :
Levels(8, 0.96, 245, 0, 255, coring=false)

Just before I tried
Levels(16, 1, 235, 0, 255, coring=false)
But the colors were too vivid and blacks were too deep (lost of details on dark grey areas)
So I try half the settings with a little gamma correction (0.96) because the general light of the image looked too bright.

Probably not the best solution and the more reliable I confess !
But since I don't have a real *1 click solve it all* algorithm, I'm trying my best.

[ericp]

I made a new battery of testings and finally it came to me that I was wrong in one of my statement :
This method works to get the right colors back :
http://www.videocopilot.net/blog/2008/06/fix-quicktime-gamma-shift/

BUT there is a very annoying downright on this : CineVision crashes when I try to import the QT file after I save the new visual settings in QT PRO.

This method basicaly is to set the Transparency setting to Straight Alpha (with the High Quality box checked).
So is this modifying the file and making it unreadable or unusable in CineVision...
I asked Sonic Support.

[ericp]

Thanks to Sonic Support, I could import avs script without the jitter effect in Cinevision encode file by a workaround : mounting the avs script into a new folder with the file.

http://www.turtlewar.org/avfs/

Good to know !

[mp3dom]

Very good link regarding the QT gamma shift.
About the Sonic workaround... good to know that you can resolve this, however I think the answer from Sonic support is really useless. Rather than fix their bugs, they suggests other way to workaround the bug. This is not an answer for a software that could cost 35.000$.

[CruNcher]

Very good link regarding the QT gamma shift.
About the Sonic workaround... good to know that you can resolve this, however I think the answer from Sonic support is really useless. Rather than fix their bugs, they suggests other way to workaround the bug. This is not an answer for a software that could cost 35.000$.

Yeah a major flaw but they have the Mainconcept team on their Side now it can only get better in the Future ;)

[shon3i]

however I think the answer from Sonic support is really useless. Rather than fix their bugs, they suggests other way to workaround the bug. This is not an answer for a software that could cost 35.000$.
Good post. however this is not only problem with avs, sometimes jitter is present for avi

[ericp]

jitter occur (at least for me) on 24 fps material both avi or mov when using avs script.

AVS script is only accepted in CineVision since version 3 (released a few months ago) and they use to release updates every 2-3 months or so.
I know version 3 has other flaws concerning AVC encoding, I think they changed too much things at the same time and we'll probably see a new version correcting these issues pretty soon.

But I agree, this could have been tested and fixed earlier...

[mp3dom]

AVS was available also on version 2.6 simply filtering the file as *.* to show all the files, and then selecting the avs. In version 3 they simply add the filter *.avs to the open dialog. Also in version 2.6 the avs script with 24p framerate produce same jerky encoding but at that time I thought it was a not fully supported feature. Anyway, since actually all the 3 major pro encoders are all in the same pricetag (or near), I think someone need to be really crazy to choose now CineVision

[ericp]

Anyway, since actually all the 3 major pro encoders are all in the same pricetag (or near), I think someone need to be really crazy to choose now CineVision
Except if it is part of a package with Scenarist and other softwares with a strong discount maybe...

What is the pro software you would choose if you had to pick one now ?

[mp3dom]

Well if you've got a good discount then it's OK (have you bought the full version of CineVision (with also the DVO filters) or only some options?). Without any trouble you can buy Scenarist BD without CineVision (they always ask anyway if you want the encoder :)).

[ericp]

Cinevision AVC with DVO.
See my pm for details

[speedyrazor]

Hi ericp, so, I know it's been a while since this thread, but I have the same issue with an Apple Pro Res 422 HQ file, and was wondering on your conclusion.
Currently I have found just using the straight mov file in Cinevision 3.6.1 and useing RGB 24 as the pixel format gives me the same result as using:
QTInput("H:\Movie directory\Movie file.mov")
Levels(16, 1, 235, 0, 255, coring=false)

So is there a 'standard' format for correcting this issue and what are you currently using?

Kind regards.