Quicktime Import Filter - Test Version, Still Buggy - 2006-01-09

[Guest]

myfilm.qtoutput("output.mov")

[stoffal]

Perfect, thank you both very much!
This plugin saved my day!

[7ekno]

latest QTSource (20110219).

Any chance of a link to this one?!?

For some reason I can't find it mentioned anywhere else!

7ek

[LigH]

Indeed, and please tell warpenterprises about the updates.

[poisondeathray]

You can download 20110219 from his website
http://www.tateu.net/

[Yellow_]

I really don't want to bring this up in yet another thread but just to clarify, it seems impossible to get a full range luma decoded through qtinput whatever mode, it appears to upsample from yv12 ro YUY2 and do the usual 16-235 in the process. That's what the classic histogram waveform shows at least.

If that's the case going to RGB if the original luma is captured full range and qtinput does infact squeeze it, should a PC or rec matrix be used bearing in mind original video was captured with full range luma?

I hate going back over old ground and probably just been a dumb a--. :-)

[tateu]

Edit: Ignore this whole post...After reading the post by Yellow_ below this one, I realized that my YUY2 test files were, in fact, not full range. I was (stupidly) visually comparing them in VirtualDub which converted and expanded them from [16-235] to [0-255]...


it seems impossible to get a full range luma decoded through qtinput whatever mode
Can I get an example, source mov/mp4 and the AVS Script?


I used an AviSynth script that created a greyscale 640x480 YUY2 or RGB24 video composed of 256 squares that step from 0-255. I then used x264 to encode the YUY2 version to an mp4 file and QTOutput to encode the RGB24 version to an Animation Codec mov file.

I then loaded the mp4 file using AviSynth:
FFmpegSource2("FullRange_by_Steps_YUY2.mp4", cache=false, vtrack=-1, atrack=-2, colorspace="yuy2")
and
QTInput("FullRange_by_Steps_YUY2.mp4", color=2, quality=100, audio=1, mode=0, raw="", info=0, dither=0, vfw="")

Both FFmpegSource2 and QTInput returned YUY2 0-255 almost exactly identical to the original AVS Script.


I then loaded the mov file using AviSynth:
FFmpegSource2("FullRange_by_Steps_RGB24.mov", cache=false, vtrack=-1, atrack=-2, colorspace="rgb24")
and
QTInput("FullRange_by_Steps_RGB24.mov", color=0, quality=100, audio=1, mode=0, raw="", info=0, dither=0, vfw="")

Both FFmpegSource2 and QTInput returned RGB24 0-255 identical to the original AVS Script.

[Yellow_]

Can I get an example, source mov/mp4 and the AVS Script?

This file illustrates differences between ffmpeg2source and qtinput. It's a Canon DSLR h264AVC mov file, which includes the full range flag in the header of the file. ffmpeg honours flag qt ignores it.

Simple 3 line script, loadplugin("path"), qtsource ("whatever") and histogram("classic")

http://www.yellowspace.webspace.virginmedia.com/boat.zip

Link to a different (much smaller file size) sample mov from same camera, with full range luma:

http://www.yellowspace.webspace.virginmedia.com/Gold.aMOV

I ran a simple test using the following test files:
http://www.tateu.net/software/FullRange_QTInput_Test.zip


I used an AviSynth script that created a greyscale 640x480 YUY2 or RGB24 video composed of 256 squares that step from 0-255. I then used x264 to encode the YUY2 version to an mp4 file and QTOutput to encode the RGB24 version to an Animation Codec mov file.

I then loaded the mp4 file using AviSynth:
FFmpegSource2("FullRange_by_Steps_YUY2.mp4", cache=false, vtrack=-1, atrack=-2, colorspace="yuy2")
and
QTInput("FullRange_by_Steps_YUY2.mp4", color=2, quality=100, audio=1, mode=0, raw="", info=0, dither=0, vfw="")

Both FFmpegSource2 and QTInput returned YUY2 0-255 almost exactly identical to the original AVS Script.


I then loaded the mov file using AviSynth:
FFmpegSource2("FullRange_by_Steps_RGB24.mov", cache=false, vtrack=-1, atrack=-2, colorspace="rgb24")
and
QTInput("FullRange_by_Steps_RGB24.mov", color=0, quality=100, audio=1, mode=0, raw="", info=0, dither=0, vfw="")

Both FFmpegSource2 and QTInput returned RGB24 0-255 identical to the original AVS Script.

Hazard a guess that as the '--full range on' flag was not set in your encodes that both ffmpeg and qt read it as non full range and therefore results the same.

If added --full range on to x264 encode parameters, ffmpeg would use it, qt ignores it whatever and discrepancies would be seen along with cropping 8 off the bottom and upsample to yuy2, neither of which ffmpeg does. But that's nit picking. :-)

My apologies if this is not the case and that I'm using your plugin incorrectly.

[tateu]

So, it turns out that the test file I was using in my post above this one actually only had data in the range of [16-235] so you can disregard anything in that post...

I have since encoded new test files that actually have full range data [0-255] with and without the x264 --fullrange flag on.

With --fullrange on:
FFmpegSource2("file1.mp4") - Full output of [0-255]
FFmpegSource2("file1.mp4", colorspace="yv12") - Scales output to [16-235]
FFmpegSource2("file1.mp4", colorspace="yuy2") - Scales output to [16-235]
QTInput("file1.mp4", color=2, mode=3) - Scales output to [16-235]

With --fullrange off:
FFmpegSource2("file2.mp4") - Full output of [0-255]
FFmpegSource2("file2.mp4", colorspace="yv12") - Full output of [0-255]
FFmpegSource2("file2.mp4", colorspace="yuy2") - Full output of [0-255]
QTInput("file2.mp4", color=2, mode=3) - Clamps output to [16-235]


With --fullrange on, QTInput acts the same as FFmpegSource2 with an internal color space conversion. FFmpegSource2 only outputs [0-255] when yv12 is returned with no conversion. QTInput has an option for YV12 output but I have never been able to get it to work.

With --fullrange off, FFmpegSource2 always returns [0-255] but QTInput clamps YUY2 values.

For YUY2, the current version of QTInput uses kYUVSPixelFormat internally, which is identical to AviSynth's YUY2 format (YUYV). It seems that kYUVSPixelFormat can only return data in the range of [16-235]. The Quicktime SDK has a few other YUY2 type formats. I just tried using k2vuyPixelFormat, which is UYVY, and it returns data in the range of [0-255] when fullrange is off.


You can switch to k2vuyPixelFormat format with color=4 but, in a future version, I think it might be best if I changed k2vuyPixelFormat to color=2 and either remove kYUVSPixelFormat completely or change it to color=4.

With --fullrange on (same as previous version):
QTInput("file1.mp4", color=4, mode=3) - Scales output to [16-235]

With --fullrange off (different):
QTInput("file2.mp4", color=4, mode=3) - Full output of [0-255]


Now, I just need to figure out how to get QTInput to decode directly to YV12 without an internal color space conversion and it should decode more like FFmpegSource2 when fullrange is on.

[Wilbert]

Just curious. What's the difference between

FFmpegSource2("file1.mp4")

and

FFmpegSource2("file1.mp4", colorspace="yv12")

Does the first one output a different colorspace?

[tateu]

I expected there to be no difference between them and they both output YV12.

With x264 fullrange flag off (http://www.tateu.net/software/x264_fullrange_off.mp4), there appears to be very little to no visual difference
x264_x86.exe --fullrange off --preset medium --force-cfr --fps 29.97 --min-keyint 30 --keyint 300 --crf 21 --tune film --profile baseline --level 3 -o "x264_fullrange_off.mp4" "fullrange_YV12.avs"
FFmpegSource2("x264_fullrange_off.mp4") (http://www.tateu.net/software/x264_fullrange_off_FFmpegSource2.jpg)
and
FFmpegSource2("x264_fullrange_off.mp4", colorspace="yv12") (http://www.tateu.net/software/x264_fullrange_off_FFmpegSource2_colorspace=yv12.jpg)

With x264 fullrange flag on (http://www.tateu.net/software/x264_fullrange_on.mp4), the output with colorspace=yv12 is clearly scaled to [16,235]
x264_x86.exe --fullrange on --preset medium --force-cfr --fps 29.97 --min-keyint 30 --keyint 300 --crf 21 --tune film --profile baseline --level 3 -o "x264_fullrange_on.mp4" "fullrange_YV12.avs"
FFmpegSource2("x264_fullrange_on.mp4") (http://www.tateu.net/software/x264_fullrange_on_FFmpegSource2.jpg)
and
FFmpegSource2("x264_fullrange_on.mp4", colorspace="yv12") (http://www.tateu.net/software/x264_fullrange_on_FFmpegSource2_colorspace=yv12.jpg)

[TheFluff]

I expected there to be no difference between them and they both output YV12.

With x264 fullrange flag off (http://www.tateu.net/software/x264_fullrange_off.mp4), there appears to be very little to no visual difference
x264_x86.exe --fullrange off --preset medium --force-cfr --fps 29.97 --min-keyint 30 --keyint 300 --crf 21 --tune film --profile baseline --level 3 -o "x264_fullrange_off.mp4" "fullrange_YV12.avs"
FFmpegSource2("x264_fullrange_off.mp4") (http://www.tateu.net/software/x264_fullrange_off_FFmpegSource2.jpg)
and
FFmpegSource2("x264_fullrange_off.mp4", colorspace="yv12") (http://www.tateu.net/software/x264_fullrange_off_FFmpegSource2_colorspace=yv12.jpg)

With x264 fullrange flag on (http://www.tateu.net/software/x264_fullrange_on.mp4), the output with colorspace=yv12 is clearly scaled to [16,235]
x264_x86.exe --fullrange on --preset medium --force-cfr --fps 29.97 --min-keyint 30 --keyint 300 --crf 21 --tune film --profile baseline --level 3 -o "x264_fullrange_on.mp4" "fullrange_YV12.avs"
FFmpegSource2("x264_fullrange_on.mp4") (http://www.tateu.net/software/x264_fullrange_on_FFmpegSource2.jpg)
and
FFmpegSource2("x264_fullrange_on.mp4", colorspace="yv12") (http://www.tateu.net/software/x264_fullrange_on_FFmpegSource2_colorspace=yv12.jpg)

Interesting behavior. Probably related to SWScale being dumb. I'll look into fixing it.

[Yellow_]

Now, I just need to figure out how to get QTInput to decode directly to YV12 without an internal color space conversion and it should decode more like FFmpegSource2 when fullrange is on.

Ok, so bottom line for h264 with full range flag on, which is 100% of the source I use, qtinput can't decompress 0 - 255, that explains my confusion. :-)

Don't know how common the use of that flag is, but there are other scripts/ functions using qtinput, like jmac's deep color tools for 10bit I think.

As an aside, it's quite common to see NLE waveforms and scopes showing squeezed levels to 100IRE when decoding h264 from video cameras and wonder whether getting full range YV12 or YUY2 out of quicktime is possible at all, when the flag is set on that is.

[tateu]

$#@!

Wow, Quicktime sure seems stupid...or maybe I am.

A 640x480 x264 encode with --fullrange off:
QTInput with mode=0, color=4 decodes to full output of [0-255], the same as FFMpegSource2.
QTInput with mode=3, color=4 decodes to full output of [0-255].

Now take almost the exact same file but 16x9...

A 640x360 x264 encode with --fullrange off:
QTInput with mode=0, color=4, clamps to [16-235], but FFMpegSource2 still decodes to full output of [0-255].
QTInput with mode=3, color=4 still decodes to full output of [0-255].

I am never going to fully solve this.

I did some more digging into YV12 decoding. I found a few posts around the internet and on the Quicktime API mailing list of people claiming to have h264 to YV12 decoding working but every test I try gives an error message during the decode phase.

I did manage to get your sample movie, Gold.MOV, to decode to YUY2 (mode=3, color=4) with full output [0-255] and very close to what FFMpegSource2 outputs, but I had to mod the file with a hex editor and remove the fullrange flag.

[poisondeathray]

I did manage to get your sample movie, Gold.MOV, to decode to YUY2 (mode=3, color=4) with full output [0-255] and very close to what FFMpegSource2 outputs, but I had to mod the file with a hex editor and remove the fullrange flag.


maybe another option to hex editor:

roozhou has a patched ffmpeg build that can modify sps in h264 bitstream

http://forum.doom9.org/showthread.php?t=152419

[tateu]

I tried that already. It works on some files and breaks others (they won't play). It doesn't work on the above mentioned Gold.MOV or on Gold.MOV remuxed to mp4 with mp4box (mp4box -add "Gold.MOV" "Gold.mp4") or remuxed with mp4creator.

ffmpeg -i "Gold.mp4" -vcodec copy -acodec copy -vbsf h264_changesps=limitedrange "Gold_mod.mp4"

[Chikuzen]

I tried that already. It works on some files and breaks others (they won't play). It doesn't work on the above mentioned Gold.MOV or on Gold.MOV remuxed to mp4 with mp4box (mp4box -add "Gold.MOV" "Gold.mp4") or remuxed with mp4creator.

Which mp4box are you using ?
Try following if you are using Kurtnoise's or komisar's build.
mp4box -add Gold.MOV:fullrange=off -new Gold.mp4

AFAIK, most of mp4box binaries redistributed for Windows contains this patch (https://github.com/golgol7777/gpac/commit/f0a3c4bbc7904c870ae2952d6b1a1c218c07c6e8).

[tateu]

Chikuzen,

Nice...I am using my own modified version but I never knew about that patch. I just applied it and recompiled...it's working very well, thanks.

[speedyrazor]

Hi tateu,
I am having a problem that when trying to use your plugin on a 90 minute 1920x1080 Prores HQ quicktime 23.98, it successfully opens and reads the file but whatever I open the file up in it says it's 12 mins long (not 90 mins long), but everything seems to be there. I am using the latest quicktime version and the latest plugin version on avisynth 2.5. Any suggestions please?

Kind regards.

[speedyrazor]

OK, I got it working using an old version 0.0.5, and it now reads the correct 90 min time.

The issue I am now having is I am trying to encode a 90 minute 1920x1080 Prores HQ quicktime 23.98 using Cinevision Bluray encoder on a PC so am trying to correct the gamma shift. I am using the below script:

QTInput("movie.mov")
Levels(0,1.0,255,0,255)

Should this work for me?

Kind regards.

[tateu]

Is it importing at the correct frame rate? Also, try mode=3, that works better for some types of videos.

I'm afraid I don't have any 90 minute HD ProRes files lying around to test.

Quicktime gamma is a magic thing that very rarely works correctly. I have never figured out what it does to video levels. Are you using YUY2 or RGB? Try whichever one you are not using now.

Also, your levels adjustment does nothing. Those values are the default and do not make any changes.

[Yellow_]

As this threads popped up again, tateu did the full range flag 'on' issue resolve or still impossible to get unaltered levels using QTInput with full range h264 with flag set 'on'?

[speedyrazor]

Hi tateu, many thanks for your reply. yes, it is importing at the correct frame rate of 23.98 with the latest version, and I have just tried mode=3 but it still only reports to be 12 mins long, so using version 0.0.5 opens with the correct length.
I was going from an official Sonic pdf document which says this is the way to correct the gamma levels in quicktime created on Macs which are to be encoded on PC, I didn't think it was doing anything.
If I compare an encode to the original quicktime there is a visible difference between the two, the encoded file looks lighter than the original quicktime.
Is there a way that you could suggest to correct this please tateu?

[speedyrazor]

I have found that if I don't use avisynth and directly use the quicktime file then select RGB 32 as the pixel format in Cinevision encoder then I am not getting a gamma shift. Is this a bad workflow or setting to use?

Cheers.

[LigH]

Levels(0,1.0,255,0,255)
keeps the video as it is, doesn't change it. If it was wrong before the Levels() line, it will be just as wrong after the Levels() line.

[tateu]

I have found that if I don't use avisynth and directly use the quicktime file then select RGB 32 as the pixel format in Cinevision encoder then I am not getting a gamma shift. Is this a bad workflow or setting to use?
You should use whatever method produces the results you are looking for.

As this threads popped up again, tateu did the full range flag 'on' issue resolve or still impossible to get unaltered levels using QTInput with full range h264 with flag set 'on'?
No, but remuxing with mp4box :fullrange=off and then using QTInput works. If your mov is h264, I recommend using ffmpegsource instead of QTInput.

[IanB]

@LigH,

For YUV input Levels(0,1.0,255,0,255) is equivalent to Levels(16,1.0,235,16,235,coring=false), so although it does not change the active video levels it crushes the super-black to 16 and the super-white to 235.

And yes QT's (mis)handling of video levels is abysmal and confusing.

[Yellow_]

You should use whatever method produces the results you are looking for.


No, but remuxing with mp4box :fullrange=off and then using QTInput works. If your mov is h264, I recommend using ffmpegsource instead of QTInput.

I'm struggling to find how to add a fullrange=on or off flag to an existing h264 .mp4 with MP4Box.

[tateu]

You add the fullrange flag with ':fullrange=on' or ':fullrange=off' right after your video input file (no spaces).

mp4box -fps 30 -add "video.h264":fullrange=off "output.mp4"

Several other flags can also be added this way: colorprim, colmatrix, etc.

[kolak]

Qtsource works very well for ProRes and most QT formats- no color/gamma shifts- one of the most reliable way to read ProRes.

[Yellow_]

Except something like DSLR video, re fullrange flag wierdness.

I've not been able to test a Prores file converted from a Canon DSLR as I'm not on Mac and have no Prores encoder.

Would it be too much to ask, if you could transcode this short clip to Prores maintaining full range and make it available for download?

http://forum.doom9.org/showthread.php?p=1508996#post1508996

The 'GOLD.MOV' file.

[kolak]

What if you use qtsource with color=0? Also try this with mode=0 and 2.
QT seams to decode everything to RGB, so it's strange that you have problems.

[Yellow_]

kolak, it's not me who has problems with DSLR h264 video I use ffmpegsource2 always, (apart from 2.16 which was dodgy), tateu the qtinput author himself has made it clear qtinput can't decode full range h264 if the full range flag is set on, but does if it's switched off. :-) #126 above.

[kolak]

Yes- I tried it and every method I used produced different results :) I have no idea which one was correct.
I think loading it to Edius software was correct, but I'm not sure.

[vampiredom]

You can try my method of dealing with DSLR h264 .mov files. I created a routine called MpegAutoIndexSource(). It employs a command-line demuxer that then allows neuron2's DGAVCIndex (or DGNVIndex, if you have a license) to decode the file.

Note that this only works with h264 .mov files and NOT other types of Quicktime movies.

Go here and follow the download and installation instructions:
http://forum.doom9.org/showthread.php?t=162930

So long as it is progressive h264 (which is usually is from DSLRs) you likely won't need a license for neuron2's NV or DiAVC enabled tools. MpegAutoIndex will call the old DGAVCIndex, which seems to work quite well on these kinds of files.

Then, create an .avs script:
MpegAutoIndexSource("h264.mov")

It will perform the indexing automatically and get you really nice quality. Certain cameras (the Canon 5D, for example) uses raw PCM audio that does not get demuxed, unfortunately. However, MpegAutoIndexSource() will attempt to dub the audio via DirectShowSource() as a last resort, which should work fine so long as you have Haali's Media Splitter installed or something like it.

[stoffal]

I found a problem/bug and would like to discuss with you if you know any workaround. I assume that the QTSOURCE package is not updated anymore, right? So perhaps you know any workaround...

I need to load a Quicktime MOV with avisynth. I am using qtsource to read the file. This works fine. But i realized that it has a small bug.

You can scale the Quicktime player and see two infos about the video size: the ACTUAL size and the CURRENt size. Actual is the size of the video frame, and current is the display size (scaled down/up on the player). If you save a video file and have the player scaled then it remembers this.

QTSOURCE reads in the video but uses the CURRENT size instead of the actual video size. This means that a video will be loaded into the system which is smaller or bigger than the real video data.

This happens only in the (very unlikely) case if you save the video being displayed with a scale value! But I have exacly this poroblem: I have received MOV data from a client that have this setup. Now QTSOURCE will only import them scaled down (current size) instead of the real (actual) size.

TEST FILE:
It is a 768x576 PAL resolution, scaled down and saved. The actual video data are there in PAL quality just the display size is scaled down (and quicktime remembers this!).
http://www.crocko.com/0B7C4A3C55AE46EEA939B39A91D10D2D/768x576_scaleddown.mov

Any ideas how to load this kind of MOV correctly ?

[LigH]

Immediate guess, untested:

Does FFVideoSource decode without scaling?

[hanfrunz]

If you have quicktime pro you can do this:
1. press CTRL+1 to resize to 100%
2. press CTRL+J to enter the properties window
3. click on the videotrack
4. go to visual settings
5. check if the display size is correct
6. activate high quality (this is just for changing something, so qt saves the new settings to file)
7. quit qt-player. It will save the changes.
8. Open the file again to see the right size.

[stoffal]

Unfortunatly, the issue cannot be solved with ffmepgsource (does not eat Photo-JPEG MOVs). It seems you really have to make sure the Quicktime file is stored with 100% scale factor (ctrl + 1, as mentioned by hanfrunz).

As I have about 700 Quicktime clips I like to find a way around that...

I also realized the website of the developer is down now - www.tateu.net is offline. =(

It would have been so great if you could read in Quicktimes and it would use the actual pixel dimension and not the scaled dimensions!!!

[kolak]

All what you need is QT Pro. Go to Properties click first tab (not video one), than Presentation and change Conform aperture to: Encoded Pixel, than View: Normal save and done. It should open properly in every software now (as already posted).

You can do it also with HexEditor (eg in VirtulDub)- in your sample go to (Ctr-G) address 55 and type 0100, than go to address 65 and type 0100 and Save.
I don't think that these addresses are constant, but they work for your sample.

[dr.schanker]

FFVideoSource should work, i just tested a Photo-JPEG .mov with a somewhat recent version of ffms2.dll (May 2012) under WinXP.

Alternatively you could remux your Photo-JPEG .mov's to another container (e.g. .avi) with ffmpeg, use the switches '-vcodec copy' and '-acodec copy' to keep the original streams (no reencoding). This will give you an .avi which can easily be decoded by a MJPEG VfW decoder, e.g. 'ffdshow VfW'.

[stoffal]

Thank you kolak and dr.schanker !
I will play around with a script to edit the 700 Quicktime files as mentioned by kolak. If this does not work, I will try out vvvideosource again. Good workarounds, thank you.

[tateu]

Use mode=2 or mode=3. And if it is avc/h264, definitely use FFMpegSource instead.

[stoffal]

Thank you , Tateu. "mode=2" helped and opens the video in its real size. Great help !

[buck-tick]

Hi tateu!

I noticed the QT plugin for VDub doesn't load multi track audio like the Plugin for AviSynth does. I have a 8 channel ProRes I use to test with and it loads as mono in VDub with latest QT plugin from your site.

<3 your AviSynth plugin :)

Man this would make my life easier in trying to see waveform at a glance without having to open up a heavy program like FCP or Premiere

[tateu]

Yeah, the Quicktime version has never really been updated like the AviSynth version.

I know there are probably lots of people who use VirtualDub but do not use AviSynth...I am not one of them. I also use a custom VirtualDub which automatically writes a temp AviSynth script when I open a Quicktime movie and I also use ASynther through the SendTo menu to quickly get my AviSynth scripts started...I just don't have a personal reason to keep the VirtualDub plugin updated since I don't ever use it so it's hard to get motivated to work on it.

And to be honest, they both need a complete rewrite to clean up the supreme mess they have become...Again, it's hard to get motivated to do it.

[buck-tick]

Yeah, the Quicktime version has never really been updated like the AviSynth version.

I know there are probably lots of people who use VirtualDub but do not use AviSynth...I am not one of them. I also use a custom VirtualDub which automatically writes a temp AviSynth script when I open a Quicktime movie and I also use ASynther through the SendTo menu to quickly get my AviSynth scripts started...I just don't have a personal reason to keep the VirtualDub plugin updated since I don't ever use it so it's hard to get motivated to work on it.

And to be honest, they both need a complete rewrite to clean up the supreme mess they have become...Again, it's hard to get motivated to do it.

Np. :)

Thanks for the plugins as they are. :D

[hanfrunz]

And to be honest, they both need a complete rewrite to clean up the supreme mess they have become...Again, it's hard to get motivated to do it.


Set up some kind of a donation or flattr button, maybe we can get you motivated :D
If you visit IBC in Amsterdam this year i'll get you some beers, too.

regards,
hanf "using qtinput everyday" runz

[kolak]

tateu can you port QTinput to vapoursynth and add 10bit+ color spaces (v210, b64a, v216 etc)?

[colinhunt]

tateu, what would it take to get you motivated about developing qtinput further? Perhaps a sizable donation?