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

[tateu]

This is very much a test version, there are still quite a few bugs, especially when dealing with audio. You must have Quicktime installed. Quicktime 6 is supported for video input and output, Quicktime 7 is supported for audio/video input and video output. Audio input for Quicktime appears to be working now. The filter should be able to read video from any file that Quicktime player can open (mov, mp4, raw dv, etc.). Quicktime mov creation supports video only and should be able to create a Quicktime file using any Quicktime codec that you have installed. Advanced codec parameters are partially supported.

[UPDATE 2006-01-09]
v0.0.5a
http://www.tateu.net/software/dl.php?f=QTSource
Source Code http://www.tateu.net/software/dl.php?f=QTSource_src

usage - Read:
QTInput("FileName.mov", color = 2, quality = 100, audio = false, mode = 0, raw = "yuyv", info = 0, dither = 0)
QTInput("FileName.mov")

file - input filename
color - output colorspace (default = 2)
0 = RGB24
1 = RGB32
2 = YUY2
quality - decompression quality (default = 100)
There are really only two values for this setting:
0 = normal
> 0 = High quality
This parameter does not have an effect on all codecs but there is a noticeable drop in quality for some of them (dvc) if it is set to 0. It is recommended that you leave this value at it's default value of > 0.
audio - audio input (default = false)
false = audio disabled
true = audio enabled
This is only valid if you have Quicktime 7. Audio is completely disabled for Quicktime 6.
mode - Decode mode (default = 0)
0 = Uses Quicktime SDK function MoviesTask to decode video
1 = If source file is one of several YUV formats (listed below), this mode returns raw data
2 = Uses Quicktime SDK function DecompressSequence to decode video
raw - raw input colorspace (default = "yuyv")
If mode = 1, this sets the input file colorspace method. Choices are:
uyvy (2vuy), yuyv (yuy2), yvyu, vyuy, yuv2, rgb, argb
info - Overlays codec info on the video (default = 0)
0 = info feature is turned off
1 = info feature is turned on
dither - raw 10bit to 8bit dither mode (default = 0)
0 = off
1 = Uses the 2 least significant bits as a fraction for rounding the 10bit value to the nearest 8bit value.
Currently this really isn't a dither mode, but is in place for a future dither mode option.
This only has an effect when mode=1, raw="v210."


usage - Write:
QTOutput("FileName.mov", format = "", quality = 80, datarate = 1000, keyframe = 1, raw = "")
QTOutput("FileName.mov")

file - output filename
format - quicktime FourCC codec (default = "")
If you leave this value blank, a dialog box will open allowing you to choose which codec to use.
h264 compression is a little buggy. It doesn't work if "keyframe every" is checked. This means you have to use the dialog box for h264 and uncheck it
Other options for this depend on what codecs you have installed, some examples:
"dvc" = DV25 NTSC
"dvcp" = DV25 PAL
"rle" = Animation
"SVQ3" = Sorenson Video 3
"cvid" = Cinepak
"IV41" = Intel Indeo¨ Video 4.4
"cvid" = Cinepak
quality - compression quality (default = 100)
This value is divided by 20 and truncated to an integer, so a value of 25 is identical to a value of 20.
0 = Least
20 = Low
40 = Medium
60 = High
80 = Best
100 = Lossless (this is listed as lossless in the SDK, but is probably not always lossless, but rather just the highest setting for a given codec
333 = This is a special mode that will create a file called "Quicktime_CodecList.txt" in the same directory as the avs script. This file will contain a list of the FourCC codes installed on your system.
datarate - datarate in KBytes/sec (default = 1000)
keyframe - keyframe every n frames (default = 1)
raw - raw output colorspace (default = "")
This is a raw output mode. Instead of using a quicktime codec to encode data, this mode copies the data directly from YUY2 to the requested output mode.
You must set format to a valid quicktime FourCC.
Currently only format="2Vuy", raw="uyvy" is supported.
And you must have a codec installed that handles 2Vuy, such as the Blackmagic codec.


Version 0.0.5a, 2006-01-09
Fixed raw YUV input that was broken in 0.0.5.

Version 0.0.5, 2006-01-09
Added raw input mode for RGB and ARGB data.
Fixed (hopefully) audio input for Quicktime 7.
Fixed several memory errors that caused QTInput to sometimes crash on opening or closing a file.

Version 0.0.4, 2006-01-07
Added a dither (rounding) mode to raw 10bit input (v210).
Added a raw output mode for 2Vuy (uyvy).
Added a frame count check to QTOutput. This keeps it from writing more frames than the input clip has.
Removed some unnecessary code.

Version 0.0.3, 2006-01-05
Added 10Bit raw decoding of v210 uyvy video.
Fixed a bug with the way fps info was calculated for some movies.
Fixed a bug with the way frame count was calculated for h264 mp4 files.
Fixed part of a bug with the decoding of h264 mp4 files in mode=0. Still not 100% working, first frame is not decoded and it sometimes skips over a frame.
Added the default compression dialog box and two new compression parameters, datarate and keyframe.
h264 compression is a little buggy. It doesn't work if "keyframe every" is checked. This means you have to use the dialog box for h264 and uncheck it .

Version 0.0.2, 2005-12-20
Added two new decode methods: Quicktime SDK DecompressSequence and a raw mode for some types of YUV data.
Added info parameter to overlay codec info on top of video.

[peter100m]

Very nice tateu!
Have tried QTInput with different sources and compressions (uncompressed, dv, animation) and everything seems good so far (except for audio of course)!

Now we can finally choose colorspace and get YUY2 data from Quicktime in an easy way!

For testing purposes, is there a way to see which decoder is being used? I have several decoders for uncompressed video and I want to know which one that actually does the decoding.

Many thanks for this!

[tateu]

Don't jump for joy just yet. Even though Quicktime is returning YUY2, I am not sure that it is returning an exact copy of the uncompressed data. I'll have to setup up some comparisons against one of the rawsource filters.

If it is altering the data, I can try a call to Quicktime's GetMediaSample and return the raw data to AviSynth. I might run into the same problems as rawsource with this method, though. I did a quick test this morning on an Avid Meridian 1:1 encoded mov and GetMediaSample returned 720896 bytes of data, which would suggest a YUY2 frame size of 720x500 with an 896 byte header. The actual frame size of the file was 720x486, so my test was unsuccessful because of a buffer overflow. I'm not sure if I will be able to figure out the header and extra frame size data for all of the different uncompressed codecs.

As for showing you which decoder is being used, I'll put in an option to use subtitle to overlay some file and decoder info. The codec is chosen based on the FourCC value of the file. If you open the file in Quicktime player and select "Show Movie Info," it will show you the codec being used. My filter uses the same codec.

[bond]

wow, this might be the first way to measure decoding speed of qt's decoders

but i have a few questions:
- why does QTInput() not support YV12 output colorspace? doesnt qt7 support it? what colorspace is outputted in qt7 itself by default?
- i dont understand what output decompression quality should be? shouldnt every decoder output the same quality? does this affect the h.264 decoder?
- how fast/slow is QTInput()?

[peter100m]

I'll have to setup up some comparisons against one of the rawsource filters.
I actually did this prior to posting before. I took an uncompressed YUV-file of some colorbars and compared QTInput(color=2) with Rawsource. The colors were the same (checked with the Color Picker filter in Virtualdub, and color picker in Photoshop).

I was asking for decoder info because QT reports the Blackmagic codec as decoder for the file and I heard somewhere that the Blackmagic codec only did RGB output. I guess it at least can output YUY2 as well...
The option to overlay some info could be useful! Thanks again!

@bond:
regarding decompression quality, if you play a DV file in the Quicktime Player you will see a visually degraded picture because the player appearantly doesn't use "decompression quality=100"..if you use QTInput() with decompression quality=100 the picture is not degraded. Maybe this exists to reduce CPU load but is sure is annoying, not knowing what your file actually looks like.

[tateu]

Bond,
I can't seem to get it to output YV12 but I'm still trying. The Quicktime developer site has sample code to use for determining if a given codec can output to the desired format (it uses a codec's cpix resource). The code doesn't seem to work with 3rd party codecs but for the one's I've gotten it work on, kYUV420PixelFormat always returns false. kYUVSPixelFormat, k24BGRPixelFormat and k32BGRAPixelFormat return true.

For QTInput, there are really only two quality options: equal to 0 and greater than 0. Quality = 0 sets the decoder in a normal (lower quality) decoding mode, probably meant for a preview mode so you get a faster decode. It does not have an affect for all codecs but for some of them, DV25 for example, there is a large drop in quality when set to 0 (very blurry output). I have not tried it on an x264 file yet but if you leave it set at the default value of 100 you should get the best possible quality.

For QTOutput, quality sets the basic encoder compression parameters. If you open any program that can export to Quicktime you get a dialog box where you choose the codec, fps, depth and quality (least, low, medium, high, best). This quality setting is what gets set by the QTOutput quality param. This does not affect all codecs, but for mjpa this adjusts the amount of jpeg compression per frame. For an mjpa test encode I tried:
quality = 0, resulted in a data rate of 11.55 mbit/s
quality = 20, resulted in a data rate of 15.00 mbit/s
quality = 40, resulted in a data rate of 29.14 mbit/s
quality = 60, resulted in a data rate of 46.48 mbit/s
quality = 80, resulted in a data rate of 63.45 mbit/s
quality = 100, resulted in a data rate of 105.11 mbit/s

There are also sometimes more advanced compression options (data rate, interlaced, etc.). These are not yet available with my filter.

I haven't done any speed tests. Are you looking for speed compared to mencoder/ffmpeg quicktime decoding or to compared to avi vfw decoding?


peter100m,
That's good news. I'm still going to try and have an option to return raw data. This will also facilitate a planned direct stream copy mode from quicktime to avi.

[bond]

thx :)

what colorspace is outputted in qt7 itself by default?
eg mpeg-4 and h.264 streams are always YV12, so it would be interesting to know if qt7 does a colorspace conversion during playback and if thats avoidable with your plugin

i made a quick test on a h.264 sample with quality = 0 and 100 and it seems to output exactly the same picture

I haven't done any speed tests. Are you looking for speed compared to mencoder/ffmpeg quicktime decoding or to compared to avi vfw decoding?yes, till now there exists no way to test the max decoding speed a decoder in qt can achieve afaik

for getting an idea on how fast/slow your plugin is i now did the following:
i played an .avi with uncompressed YUY2 video (~3gb) via .avs and your qtinput() in directshow (so its decoded in qt7) and measured the decoding speed
than i played the same .avi directly in directshow without avs and your plugin

the result was:
qtinput: 22.63fps
normal: 39.94fps

so when going via your plugin it was played slower than realtime (the file has 25fps)
i noticed that at the beginning it played at normal speed, after seeking eg to the middle of the file i saw that things were slower (this is not the same in qt7)

i dunno if thats a bug in your plugin or maybe caused somehow by the big filesize or if your plugin is simply slower?

[IanB]

Source code?

[Mug Funky]

excellent.

one thing - i've got a couple of 2vuy clips hanging around (i can do a bit comparison of output if you like, because i have the exact same clips in uyvy avi files)

they don't load.. virtualdub gives me a clip of correct length (you can see the little ticks on the timeline), but before the image shows up it disappears.

[Leak]

Source code?
Ummm...

I'll try and get the source packaged sometime in the next few days.

[tateu]

A new version and the source code will be available later tonight, probably 8-10 hours from now. The new version doesn't fix any of the bugs, it just adds two new decoding modes and an info option which shows you the codec used by the decoder. Mode=0 decodes the video the same way that the current version does. Mode=1 (not 100% perfect yet, sometimes has trouble with the extra frame header data and interlaced separate field codecs) will copy the raw 8bit YUV (uyvy, yuyv, yvyu or vyuy) data directly from the file without decompression. Mode=2 will give you the exact same output as Mode=0 but it uses a different decompression method, which seems to be a little faster.


Mug Funky,
Hmm...do you feel like sending me one of the files that crashes? If you don't have a site to upload to, I can get an ftp link for you.


bond,
I'm not sure what the default colorspace for qt7 is. The way I understand quicktime: You build a GWorld, which is some magic quicktime construct that I don't fully understand, which is used for compressing and decompressing graphics. In the constructor for a GWorld, you tell it what pixel format you want (YUY2, 24BGR, etc.) and this determines the output colorspace when decompressing an image. When the decompresser does not support the desired colorspace the function fails. This is what happens when I try YV12.

I've done some tests using color bars as the source. I used Avisynth's ColorBars(720,486) to create a YUY2 avi with a luminance range of 16-235. I then converted that avi with Adobe After FX into several different types of quicktime movies and fed them all back into QTInput. For most codecs, it seems that QTinput returns a closer match to the original avi colors and luminance range when using RGB output. When using QTInput YUY2, most codecs converted the grey bar rgb(180,180,180) to rgb(170,170,170) and the white bar rgb(235,235,235) to rgb(232,232,232). When using QTInput RGB24, there was a much less noticeable change. I also opened the file in quicktime player and saved a still frame as a bmp. The bmp was a very close match to QTinput in RGB mode. The one exception I have found so far, is the Black Magic 2Yuv codec. It's output was a closer match when QTInput was set to YUY2. I have not run these tests on actual video material yet.

I have sometimes noticed inconsistent frame rates when playing my scripts in Media Player but haven't done a whole lot of testing with it. Nor have I tried anything larger than a 1GB mov. The 1GB DV25 file I just tried, seems to play at about 30fps the whole way through no matter how much I jump around. Maybe it's related to a specific codec?

I also did some speed tests of my own earlier today, with a different method, on DV25 and 2vuy material. I used ffmpeg's raw stream copy method as my speed test. I fed several different scripts and the mov file into ffmpeg with the command line "ffmpeg -an -i file.mov -vcodec copy -r 29.97 -f avi file.avi" and timed how long it took to complete. In this mode, ffmpeg read the raw data from the mov file and created a dv25 avi and a 2yuv avi. It read the raw data from the Avisynth scripts and created i420 avi files.

Results for a 30 second 2yuv mov:
QTInput Mode 0 = QTinput("2yuv.mov", color=2, mode=0)
QTInput Mode 1 = QTinput("2yuv.mov", color=2, mode=1, raw="uyvy")
QTInput Mode 2 = QTinput("2yuv.mov", color=2, mode=2)
AviSource("2yuv.avi") - via ffdshow

Mov DirectStream Copy = 15.7s
QTInput Mode 0 = 42.4s
QTInput Mode 1 = 15.5s
QTInput Mode 2 = 38.9s
AviSource = 39.4s

Results for a 8799 frame DV25 mov:
QTInput Mode 0 = QTinput("DV25.mov", color=2, mode=0)
QTInput Mode 2 = QTinput("DV25.mov", color=2, mode=2)
AviSource("DV25.avi")

Mov DirectStream Copy = 107s
QTInput Mode 0 = 252s
QTInput Mode 2 = 228s
AviSource (CedocidaDV) = 204s
AviSource (ffdshow DV) = 240s

[tateu]

New version:
http://www.tateu.net/software/dl.php?f=QTSource

Source is a mess, has lots of incomplete and unused code but here it is anyway:
http://www.tateu.net/software/dl.php?f=QTSource_src

Added two new decode methods: Quicktime SDK DecompressSequence and a raw mode for some types of YUV data.
Added info parameter to overlay codec info on top of video.

[Mug Funky]

haha! i accidentally made it open an avi file, and it worked perfectly...?

it was an uncompressed uyvy avi though, and qt7 has no trouble opening these (which is quite useful)

[edit]

with the latest version you posted i have no trouble loading 2vuy files. in raw mode it gives identical results to loading the avi (not a pixel changed... very good). however, using blackmagic's codec with color set to 2 (default), there's quite a difference - about quarter/half a pixel shift for some reason and chroma is tinted. i was using subtract(qt, avi).coloryuv(autogain=true) to compare, so i couldn't say which direction the image shifted.

looks like i'll be using raw mode anyway, as it's hella fast. thankyou very much - i've been wanting to import 2vuy quicktimes _losslessly_ for a long time, and now i can :)

sure beats having to rip the decklink card out of the mac and shove it in a PC for capturing...

[tateu]

Looks like maybe it is quicktimes fault? I started with a Blackmagic quicktime file of NTSC color bars (15-234, for some reason). I opened the file in After Effects...rgb(179,179,179) was changed to rgb(187,187,187). rgb(234,234,234) was changed to rgb(236,236,236). rgb(16,15,179) was changed to rgb(23,21,189).

I then opened the same file in quicktime player, chose export and selected the Blackmagic codec. This should theoretically give me an identical file? It did not. After 9 generations of exports, the file was nowhere near its original state. I also tried the same export test using one of Avid's (supposedly) lossless yuv codecs (AV1x). It performed better than the Blackmagic codec, but still did not return an identical file.

Still Frame Source: http://www.tateu.net/software/Bars_Source.png
Still Frame Blackmagic Generation 9: http://www.tateu.net/software/Bars_BlackMagic_Gen9.png
Still Frame Avid AV1x Generation 9: http://www.tateu.net/software/Bars_Avid1.1x_Gen9.png

[Pookie]

tateu - Awesome. Thanks so much for working on this.

[bond]

tateu, so yv12 output doesnt work even on yv12 files (eg h.264 ones)?

[hanfrunz]

I then opened the same file in quicktime player, chose export and selected the Blackmagic codec. This should theoretically give me an identical file? It did not. After 9 generations of exports, the file was nowhere near its original state. I also tried the same export test using one of Avid's (supposedly) lossless yuv codecs (AV1x). It performed better than the Blackmagic codec, but still did not return an identical file.


i had similar problems the other day. I imported a .yuv file with a avid mediacomposer. It had some areas of "super black" (y=13). I thought avid would import raw yuy2 data, but it looks like that the .yuv-import filter makes a conversion to RGB first. Because these areas were always clipped (i checked all import setings). maybe it is also a quicktime related problem. Who knows....

regards and thanks again for this cool filter,
hanfrunz

[tateu]

bond,
It doesn't work with the code I have written but I looked through the mplayer source code today and it looks like maybe they have been successful setting it to YV12. Hopefully I can make sense of their method and adapt it to work with my filter.


hanfrunz,
After seeing the results with quicktime, I was also curious about what happens when importing into an Avid system. When I get some free time, I plan to try it out on our Adrenaline.

[bond]

bond,
It doesn't work with the code I have written but I looked through the mplayer source code today and it looks like maybe they have been successful setting it to YV12. Hopefully I can make sense of their method and adapt it to work with my filter.mplayer can also wrap quicktimes decoders? if yes, how? :)

[morsa]

well there is the Quicktime Alternative project also.
I guess it is a directshow filter for quicktime.I use it with Avisynth and it works.It has some problems though, like getting a quarter resolution clip when its color space is YV12 or 4:1:1/4:2:0

[Mug Funky]

@ tateu:

fascinating. looks like QT/blackmagic has a dirty little secret? :) that chroma drift looks to have been created by multiple yuy2-rgb conversions (and it drifts to the side! that means even with 1 generation there's going to be a chroma offset... i mean come on, is it that hard to convert colourspaces without moving stuff around?)

that's good though - that means us avisynthers can make as many generations as we like without loss. though i fear for 10-bit files the same losses will occur (it'd be cool to dither 10-bit to 8-bit on import, but that's for another time. and when avs 3.0 comes along it'd be much nicer to just use it's 15 bit colourspace on 10 bit files).

looks like i'll be doing all my capping in 8 bit for now then :)

thanks heaps for your import plugin - it's nice to know there's more quality to be had from quicktime than what quicktime itself actually provides.

[tateu]

Yes, it seems strange that there would be that much of a shift. I expected lossless in, lossless out (I'm still hoping that someone proves me wrong and shows me some checkbox I forgot to select). As I delve deeper and deeper into quicktime and omf, I'm finding that I mostly prefer plain old AVIs, I seem to have fewer problems.

10bit...yes, I was looking for a way to do a raw import, but I don't know enough to write my own 10bit to 8bit function from scratch. If I can find an open source one I'll add it in.

The raw import still needs some work. I need to figure out how to accurately determine the frame header size so I can skip over it. Right now it's just a guess. A call to GetMediaSample returns the raw data and the size of the data in bytes. I know the height and width of the file which allows me to determine the actual size in bytes of 1 frame. I then assume the header size is equal to (Raw data size) - (actual frame size) and skip over that amount.

As an Example using 720x486, progressive, Avid AV1x codec:
GetMediaSampleSize = 720,896
YUY2 FrameSize = 699,840 = 720 * 486 * 2
Assumed Header Size = 21056 = 720,896 - 699,840

This method does not work on every file I have tried and it definitely does not work for separate field interlaced files because each field has it's own header data and GetMediaSample returns the entire frame, not each field. I'm still looking for a foolproof solution.

And I found a bug that shows up occasionally which sets the incorrect fps. I used the wrong values in my calculation. I used MovieTimeScale / GetMovieNextInterestingTimeDuration when it looks like it might be better to use MediaTimeScale / MediaSampleDuration. Quicktime doesn't have an fps parameter, it has timescale and sampleduration which seem to act kind of like fps.numerator and fps.denominator. The movie as a whole has a timescale and each piece of media (video track, audio track, etc.) has it's own timescale. I was calling GetMovieNextInterestingTime and using it's duration as my fps denominator but this failed on one file I tested. MovieTimeScale was 2997 and the first call to GetMovieNextInterestingTime was 64 resulting in 46.83fps. If I had used MediaTimeScale / MediaSampleDuration it would have been 600 / 20 = 30fps. I don't fully understand the concept of sampleduration, though, so even this method may not be 100% correct. One 30fps file that I have, has a MediaTimeScale of 600 so it seems that each frame should have a sample duration of 20, but the frames actually ranged in duration from 19-22. It wasn't meant to be a variable frame rate file, it was just a DV25 file rendered out of Final Cut Pro on a Mac.

December is always my busiest time of year so I won't have time to work on any of these issues until the beginning of next Jan.

[Mug Funky]

i wonder if it'd be possible to reverse-engineer output of some uncompressed formats?

because even though we can decode "lossless" (i'm growing more and more wary of this term when dealing with quicktime), we can't export back to it without loss.

with the example of blackmagic 2Vuy, my preferred method is to export via ffdshow a uyvy avi file. the quicktime blackmagic codecs can load this without fuss, so i save it out from there. in theory there's no yuy2 to rgb conversion happening, at least in theory.

now with the QTsource plugins, we can also export straight out of our scripts by just playing through. now this would seem an even safer way to preserve the colourspace throughout the chain.

however, i did a little test where i made a mov with both these techniques. they both loaded fine in QT and avs, but when subtracted from the source, it was clear there were differences.

the avs -> ffdshow uyvy -> mov file showed evidence of colourspace conversion (it was blurred and slightly shifted).

the avs -> QToutput -> mov file showed no blurring that i could tell, but a luma change of some kind (i haven't tracked down the numbers yet). it doesn't seem to be the standard 8-235 clamping.

i think if this is sorted, we might finally have a way of working with quicktime that's truly lossless.

[edit]

i think it's using different colour coefficients... the reds are sort of orange when i view it in QT player. that means it's almost certainly converting colourspace. bugger it.

[morsa]

one more of the hundred reasons why I insist on not using quicktime despite what Mac fans tell about about its "superior image quality" :confused:

Anyway I respect it as a container, problem is it is so closed that you can't never really tell what is going on inside it......

[hanfrunz]

10bit...yes, I was looking for a way to do a raw import, but I don't know enough to write my own 10bit to 8bit function from scratch. If I can find an open source one I'll add it in.


ITU-601 says:
To avoid confusion between 8-bit and 10-bit representations, the eight most-significant bits are considered to be an integer part while the two additional bits, if present, are considered to be fractional parts.

So just take the eight most-significant bits and you got your 8->10 bit conversion.

hanfrunz

[Mug Funky]

Anyway I respect it as a container, problem is it is so closed that you can't never really tell what is going on inside it......

hit the nail right on the head there. just another bit of ammunition for me to use on the mac fanboys at work :sly:

@ hanfrunz:
true, true. i'd like to see dither added too - it might help repress blocking when encoding to mpeg-2 (or anything else for that matter). certainly a nicer kind of noise than blockbuster gives.

[bond]

tateu: i have upload a .mp4 file with h.264 video here (http://home.pages.at/bond_/quicktime.mp4). it has been created with x264
it plays in quicktime (jerkily) but when i try to open it via your plugin it only shows me a green picture. the funny thing is i also cant open it via the cyberlink dshow qt source filter (coming with qt alternative)

any idea why it doesnt work?

[tateu]

Mug Funky,
This document, http://developer.apple.com/quicktime/icefloe/dispatch019.html has a lot of info on quicktime and yuv. There are a few ImageDescription Extensions (colr & nclc) which describe color matrixes and transfer functions. I'm muddling my way through and hoping to find something useful. I've also found that mencoder using quicktime codecs in YUY2 mode does a much better job than my filter of decoding to YUY2 with the correct color output (still not perfect and some filters seem to only work in RGB). Mencoder/mplayer uses yet another quicktime function for decoding frames (ImageCodecBandDecompress) that I have not tried yet. I'll have to look into it some more. I'm definately in agreement with morsa...Quicktime is really starting to get annoying...there are way too many functions available to decompress a frame of video (ImageCodecBandDecompress, DecompressSequenceFrameWhen, MoviesTask, DecompressImage, ICMDecompressionSessionDecodeFrame, DataCodecDecompress, FDecompressImage and probably others that I haven't found yet).


Bond,
Sorry, I remember typing (in notepad) a reply to your question about mplayer and quicktime but I guess I never actually logged on and posted it. Mplayer has a quicktime demuxer which reads the properties of the quicktime file (FourCC, height, etc.). It then has a set of codecs that it can use to decode the video. "Codecs.conf" is used to determine which codec to use for each FourCC. If you play a Sorenson Video 3 quicktime with mplayer, the demuxer will determine that the FourCC is SVQ3 and will search through "codecs.conf" for a compatible decoder. The first one listed is ffmpeg, so mplayer will grab compressed media samples from the quicktime file and feed them to the ffmpeg SVQ3 decoder. If you remove or comment out the ffmpeg decoder entry, it will try to use the next one in the list, "Win32/QuickTime SVQ3 decoder." I have not been successful using the quicktime decoders with mplayer but they seem to work with mencoder. I added an entry for Blackmagic's 10Bit codec (v210) and mencoder successfully re-encoded the file to mpeg4.

I tried "mplayer -vo directx SVQ3.mov" which crashes
and "mencoder SVQ3.mov -ovc lavc -lavcopts vcodec=mpeg4 -ffourcc XVID -o SVQ3.avi" which successfully encodes an mpeg4 avi.

As an example of a new mplayer/mencoder codec, here's the entry I added for the Blackmagic's 10Bit codec:
videocodec qtv210
info "Win32/QuickTime Blackmagic 10Bit"
status untested
fourcc v210
driver qtvideo
dll "BlackmagicCodec.qtx"
out BGR32

About h264...There are two problems there: 1) My method of returning the frame count doesn't seem to work with your sample file and always returns a value of 1. 2) It looks like I am using older APIs that cannot handle B-Frames, the error message that quicktime gives me is "kQTMediaHasDisplayOffsetsErr = -9461, /* Returned by old (non-B-frame-aware) media APIs that cannot cope with nonzero decode to display deltas on media that contain them. */." My guess is that the cyberlink filter has a similar problem.

I'll have to revert back to my first method of returning the framecount (GetMediaSampleCount) and figure out the newer quicktime 7 video APIs (ICMDecompressionSession).


hanfrunz,
Thanks for that info. I now have Blackmagic 10Bit (v210) raw decoding added in, using the 8 most significant bits.


I should hopefully have a new version available sometime in the next few days. It will add 10Bit decoding and fix the fps error. I think I may end up needing to start a new filter from scratch to clean everything up and try to get the colorspace and h264 issues resolved correctly. Right now, I just keep dumping code into the middle of an already messy project and I'm starting to get lost in it.

[bond]

Sorry, I remember typing (in notepad) a reply to your question about mplayer and quicktime but I guess I never actually logged on and posted it. Mplayer has a quicktime demuxer which reads the properties of the quicktime file (FourCC, height, etc.). It then has a set of codecs that it can use to decode the video. "Codecs.conf" is used to determine which codec to use for each FourCC. If you play a Sorenson Video 3 quicktime with mplayer, the demuxer will determine that the FourCC is SVQ3 and will search through "codecs.conf" for a compatible decoder. The first one listed is ffmpeg, so mplayer will grab compressed media samples from the quicktime file and feed them to the ffmpeg SVQ3 decoder. If you remove or comment out the ffmpeg decoder entry, it will try to use the next one in the list, "Win32/QuickTime SVQ3 decoder." I have not been successful using the quicktime decoders with mplayer but they seem to work with mencoder. I added an entry for Blackmagic's 10Bit codec (v210) and mencoder successfully re-encoded the file to mpeg4.hm, i have been able playing a sorenson3 mov file via mplayer after placing all the qtsystem files into the codecs folder of mplayer, but i dont seem to be able to get it to decode h.264 via qt's decoder. all i get is a black picture...

[tateu]

Pretty much the same here, mplayer crashes and I get nothing but black output from mencoder. I've tried the MPlayer-mingw32-dev-CVS-050928 build from mplayerhq.hu and CelticDruid builds from Aug, Nov and Jan 06. It could be the same problem as my filter: the quicktime function mplayer uses (ImageCodecBandDecompress) may not be able to handle B-Frames.

I'm using this as my config:

videocodec qth264
info "Win32/QuickTime h264"
status untested
fourcc H264,h264
fourcc avc1
driver qtvideo
dll "QuickTimeH264.qtx"
out YV12,I420,IYUV

[bond]

i tried this too an a mp4 without b-frames and it didnt work either :(

[tateu]

Ok, hopefully I didn't break anything with these changes...
http://www.tateu.net/software/dl.php?f=QTSource
http://www.tateu.net/software/dl.php?f=QTSource_src

A few bugs with fps and framecount were fixed. h264 mp4 files can now be partially decoded in mode=0 but it is still not 100% working. It returns a green frame for frame 0 and sometimes skips the decoding of a few frames. And it's really slow. Raw decoding of 10bit v210 files has been added. This is the format for the Blackmagic 10Bit codec. The last 2 bits of each component are dropped to convert to 8Bit YUY2.

For QTOutput, the standard compression dialog box has been added. This allows you to set a datarate for certain codecs. If you want to use the dialog box, leave format equal to "". If you do not want to use the dialog box, set format equal to a valid FourCC. Along with the dialog box, two new parameters have been added: datarate and keyframe. h264 compression is a little buggy. It doesn't work if "keyframe every" is checked. This means you have to use the dialog box for h264 and uncheck it.

[bond]

h264 mp4 files can now be partially decoded in mode=0 but it is still not 100% working. It returns a green frame for frame 0this might be caused by the delay introduced by b-frames?

and sometimes skips the decoding of a few frames.i noticed that too when playing avc in qt. i think thats caused if you use more than 1 b-frame

[tateu]

bond,
It's definately something with the b-frames. I took your sample mp4 file, converted it to YUY2 avi with mencoder and then encoded it to h264 mp4 using MeGui (mencoder, mp4box, CE-Quicktime profile) with 0, 1 and 2 b-frames.

The 0 b-frame version plays back with my filter at normal 25fps speed. The 1 and 2 b-frame versions behave exactly like your sample...stuttering around 2-6fps playback speed. They all play back relatively smoothly and at a decent speed in quicktime player, though.

To get h264 mp4 decoding working in this latest version, I didn't actually use the new quicktime 7 API's, I just fixed an error in my old decoding method. My best guess is that my method causes quicktime to always start the decode process from the nearest ref frame, even when stepping sequentially through the file. I don't think there is a frame buffer for anything but the current frame. This means that it is decoding way more frames than it actually needs to.

[anton_foy]

...WOW...I just need to say it...WOW!
Never thought this filter would ever come and now it is here, great work Tateu!

Is it possible to import mpeg-2 material with this filter and output to QT?

This would be a much faster and easier way than my present way:
importing my HDV material (mpg) in VDub, add a lot of avisynth filters, output in raw .avi then import the raw avi in AfterFX to put some more filters on and finally output it in Avid's DNxHD format (1080-25P 185 10-bit).

[tateu]

That's what it's supposed to do. No audio output, though....yet. And Avid's DNxHD codec seems to work in a test I just tried.

[Mug Funky]

Raw decoding of 10bit v210 files has been added. This is the format for the Blackmagic 10Bit codec. The last 2 bits of each component are dropped to convert to 8Bit YUY2.

weee! thanks for that. this will speed things up considerably with 10-bit sources (and increase the quality too).

one thing... would dithering be a possibility, or is there no point? i guess it would be too slow and would give a very small quality increase (if any).

[edit]

it just occured to me... would it be difficult to allow raw output as well? i'd like to avoid using QT's own stuff wherever possible :) something like the input filter where a fourcc (2Vuy for example) and pixel type (like uyvy) could be specified.

[tateu]

Raw output into a quicktime container? I don't think that will be overly difficult. I'll look into it this weekend.

It doesn't hurt to try dithering. If there's no quality increase or it's too slow then you don't have to use it. I don't know how to do it, though. I did a quick search this morning for a formula and didn't find anything that I understood. If I figure something out, I'll add it in.

One thing I did try (though I'm not sure how correct it is)...The current version completely ignores the 2 least-significant bits. I added an option which uses these bits for fractional rounding. Here's a version if you want to try it out...http://www.tateu.net/software/QTSource_10Bit_Round.zip. Add dither=1 to turn on rounding (only has an effect when using mode=1, raw="v210").

y10b = 1110 1010 10
y8b = 1110 1010 = 234
y_frac = 10 = 2

y8b_rounded = y8b + (y_frac > 1) = 235

[Mug Funky]

hehe... thanks for that :)

i don't have any 10-bit stuff on my machine right now (i'm at home for the weekend thankfully), but i'll try it out when i get to work.

i highly doubt there'd be a perceptible difference, but it could help to have a little bit of dither noise in there for the sake of the encoder - perfectly clean video will go blocky even at very low quants, but a little bit of noise (bonus if it's related to the signal like dither noise is) can help prevent blocking without hurting bitrate performance.

and if you get raw export working, even for 2Vuy, i would kiss you. i've got a really awesome looking "my neighbor totoro" in huffy that i want to export back to didge, and it'd suck if i had to bugger up the sharpness and colours by saving it with quicktime's routines. (seriously, anyone who gets the R4 totoro in march will have the best looking release in the world :). i'm real happy with how it turned out).

doing a simple subtraction between a resaved QT and the original is a real eye opener...

[edit]

i'm just reading up on dither for both audio and video. it looks like 1/2 the LSB of noise added before rounding will be fine. only thing is you might want to use the same seed each time, otherwise we will never get the same encode twice :)

there's also floyd-steinberg dither... i'm just looking for appropriate links

[edit 2]

here's a page with source for a floy-steinberg dither. i'm not sure if interlace needs to be taken into account for it though (probably) as it propagates error from 1 line onto pixels from the next (possibly unrelated) line.

http://www.home.unix-ag.org/simon/gimp/fsdither.html

[tateu]

I haven't looked at the dithering info yet, but here's a version with raw out to try...http://www.tateu.net/software/QTSource_RawOut.zip.

Avisynth must, of course, be outputing YUY2 and 2Vuy is the only setting currently supported (others, yuv2, etc., may be added later). You must have a codec installed that supports 2Vuy (Blackmagic) otherwise it will fail.

QTOutput("file.mov", format="2Vuy", raw="uyvy")

Raw out is running about 1.5 times as fast in my tests.

[Mug Funky]

with QT7 (the latest? i dl'd it a second ago) i'm getting "error -2048 - not a movie file" :(

but it's nice and fast :)

[edit]

the made file does load in QTinput without any problem.

btw, thanks heaps for this! it's a real nice new year's present, i tell you :)

[edit 2]

scratch that, the created file doesn't load with QTinput. i was accidentally loading the old one...

[edit 3]

scratch even that... what was happening was the input plugin was crashing on my sample at around frame 205, and that meant the movie was never finished writing... changing the input made QToutput make a usable file.

which is good news! :):):):):):):) this makes me so happy :) i'll crack a beer open for you.

[edit 4]

output is bit identical to input! party time!

[mode editing, omg]

writing the files seems to be tricky - i figured the safest way to make a file would be to load it in virtualdub and go "preview VBR" so it played the clip beginning to end. but when it finished, virtualdub went back to the first frame, which was then written to the end of my file... perhaps space needs to be allocated first and frames written to specific byte offsets in the output file as they're accessed? that could be tricky for large files (like an 80 minute movie...), but a simpler measure that would work for the "preview VBR" method is to not allow it to write more frames than in the source clip. it would just mean random access isn't possible (which i can live with of course).

[tateu]

writing the files seems to be tricky
Yeah, I know. I've been using it with VirtualDub pretty much the same way...My first version, several months ago, had all of the quicktime SDK functions called directly from within the avisynth methods. I quickly got rid of that code and created separate quicktime movie classes (CQTMovieDec and CQTMovieEnc) so that I could hopefully (and easily?) create a standalone quicktime program. The plan has always been to create a cli program that reads quicktime, avi, avs and can output to quicktime, avi, raw. I haven't started working on it yet, though.

As a quick fix, I like your idea of not allowing it to output more frames than the input clip has. I'll add that in and get it out sometime tomorrow.

The problem with your other method of preallocating space is that I am using quicktime functions to handle everything except encoding the data. Instead of encoded data, I feed the raw frames to AddMediaSample and I don't see a way of specifying offset locations with this method. The reason I do it this way is so that I don't have to figure out how to write the correct header and footer data.

[Mug Funky]

ah. that makes sense.

i really appreciate this by the way :) without the means to write my own plugins (or the time to learn a language), i have to harrass good people like you to make stuff :) it's really amazing how a free tool like avisynth can do stuff to such a high quality and speed that only the most expensive of pro equipment can rival it. in fact, your plugin is unique in that it's the only way of re-saving an uncompressed mov without any loss.

perhaps you could hook up with Avery Lee and maybe QT output could be hacked into Virtualdub? that would solve the frame access problem pretty definitively, and give people a much nicer alternative to QT pro. of course, if you're making your own program for similar things, then i'll let you do that too ;)

[Revgen]

perhaps you could hook up with Avery Lee and maybe QT output could be hacked into Virtualdub? that would solve the frame access problem pretty definitively, and give people a much nicer alternative to QT pro. of course, if you're making your own program for similar things, then i'll let you do that too ;)

Remember when Microsoft went after Avery because VirtualDub had support for .asf files?

I doubt he wants to repeat that experience with Apple.

It's still a good idea though.

[tateu]

Sure, no problem. I've been around here for years, never really talked all that much, but I've learned a great deal and found a lot of useful info and programs just by reading through the forums. Programming is just a hobby and I've always been grateful to all the people that work on programs like avisynth and release the source code for people like me to study and learn from. I'm glad that I can finally offer something useful back.

I've used Avisynth in our production workflow for years. I've always been impressed with how well and how much it can do.

Integrating directly into VirtualDub was another option I had thought of and I think it's better than a standalone cli version. I'm just not sure I am capable of doing it. I use fccHandler's modified VirtualDub-MPEG2 and I've glanced at the code he wrote for directly importing Mpeg-2 in the hopes that I could alter it to use my quicktime and omf code. I haven't done much with it so far but I do have my own custom version that checks the file extension of the file you are trying to open and if it is mov, mp4, dv or omf it writes an avisynth script in the VirtualDub-Mpeg2 home directory and opens that file instead. I also think I really need to get quicktime audio import and export working before fully integrating it with VirtualDub.

I don't think Apple would have much to say about quicktime integrated into VirtualDub. Wasn't the asf code reverse engineered? Apple releases an official quicktime SDK so that support can be added to any program. I am not a lawyer (and license agreements seem to cause a large thumping like pain just over my right eye) but everything I have read of the license agreements deals with distributing the quicktime installer and/or logos with an application.

New version...
http://www.tateu.net/software/dl.php?f=QTSource
http://www.tateu.net/software/dl.php?f=QTSource_src

This update contains the dither=1 (rounding mode), raw 2Vuy output, removes some unnecessary code and contains a frame count check for QTOutput to keep it from writing more frames than the input clip has.

[Mug Funky]

just tried export out in FCP with a decklink card and it accepted it without asking to re-render. that's very good news :)

note i've only tried PAL with this... it's possible that NTSC is another story - to be honest i've yet to successfully make a 2Vuy NTSC file that would actually play out to the NTSC deck here. that's certainly not a priority though - i only ever needed to do it once, and the file was small enough to burn to disc, so that wasn't a problem. i'm pretty sure it's user error, too - nobody here has actually needed to output NTSC through SDI, so no-one's got any experience doing it.

another thing i noticed is this plugin has exposed some alignment oddities in ffdshow - it was returning yuy2, and avisynth was reading it fine, but on QT export the picture was skewed majorly. i'm guessing it's a pitch oddity, but i fixed it by telling ffdshow to output the closest matching colourspace (even though in both cases it appeared to be returning yuy2).

[tateu]

Are you talking about something like this: http://www.tateu.net/software/skew.jpg? That's what I get when I use QTInput outputting YUY2 on a 420x240 quicktime. I tried several different codecs (uncompressed, Sorenson, mjpa) all with the same result. If I change QTInput to output RGB32, it works correctly. RGB24 is also skewed, but not as much and it's in greyscale.

I then tried a 418x240 quicktime which is skewed in all three colorspaces. I'm not sure what's going on, but it must be somewhere in my code.

[Mug Funky]

well, interestingly enough, the clip i was using also failed with HC (it just spat out a 0 kb file and said it was finished), even though i'd converted it to yv12 beforehand.

i have a sneaking suspicion it's a pitch or alignment issue that doesn't get corrected in avisynth (which is fine because it saves a little time i guess). but the old crop(align=true) chestnut didn't seem to work for it, while changing ffdshow's decoding options fixed it.

perhaps you could work around it by only giving quicktime pixels that you know are in the frame. as i understand it avisynth can store pixels outside the frame in order to either save time with simple operations like cropping, or to align data to 32 bit chunks. having not looked at the source, i don't really know what is going one here, rather i've just read a few discussions about pitch and alignment and possible problems with both in filter design.

i've also noticed some plugins don't work with other plugins as far as the skewing thing goes (for example, interleaving motion-compensated frames via mvtools and then using tsp's medianblurt on them results in a skewed mess).

[tateu]

Audio input for Quicktime 7 now seems to be working. Tests were run on several different formats: 48KHz Stereo (uncompressed, Mace6:1, ALaw, ULaw, QDesgin2 and AAC), 32KHz, 11KHz, mono, etc. I do not have any sample files with 5.1 surround sound to test. The movies were opened in Quicktime Pro and with QTInput (VirtualDub) and exported to 32bit wav files. The wavs were then invert mixed together to check for differences. The difference files never rose above -78db.

It always returns 32bit float. The sample rate and number of channels returned are the same as the source movie.

Audio is still disabled by default. You must set audio=true to use it.

http://www.tateu.net/software/dl.php?f=QTSource
http://www.tateu.net/software/dl.php?f=QTSource_src

[Mug Funky]

awesome!

do you think the differences are due to random dither for 16-bit stuff? i had wondered why when i exported audio from an SDI capture that audition reported true 32-bit. dither would explain this (if it was lossless from tape to mov to wav, audition should have reported 20 bits deep, even in a 32-bit file. digibeta carries 4 discrete 20 bit channels at 48k). i can live with dither though :)

i'll try this build out when i'm done exporting this movie to tape (thanks to your plugin :)). oyu might be interested to know that it worked flawlessly even when exporting an 83 minute feature. no crashes or memory problems i know about (at least not enough to crash a machine with 1 gig real and 2 gigs swapfile... i let it go overnight so i don't know how it performed).

[tateu]

If you grabbed v0.0.5, please download again to get v0.0.5a.
http://www.tateu.net/software/dl.php?f=QTSource
http://www.tateu.net/software/dl.php?f=QTSource_src
I broke raw YUV input in v0.0.5 when I added raw RGB input.

It's probably the dither. One of the main things I did to get audio working in this version is switch over to 32bit float from 16bit signed int. I'd prefer to return whatever format the source is in, but 32bit is the only mode I can get working correctly. All of my test files were 16bit. And I guess now I'll have to add a raw audio mode for uncompressed sources so that it doesn't pass through quicktimes decoders.

The memory errors didn't seem to cause a whole lot of problems, but they always crashed VirtualDub if I used F2 to reload the avs script multiple times. 83 minutes...that's good to know. The longest I have tried is only about 10 minutes.

[Mug Funky]

thanks for the update :)

btw, i tried some 10-bit stuff on it. it looked nice (not that i can see any differences... suffice to say it worked, looked good and was fast).

one thing though - a couple of short clips i have tend to crash before the end somehow. tried it on a short chunk out of Pom Poko (2Vuy), and a short clip from GITS SAC (v210). they are both around 250 frames long, and both disappear virtualdub at around frame 205. they were captured on a mac with FCP 4.5 (we have FCP 5 now, which in case anyone is interested makes it possible to capture onto a networked NTFS drive where before it would hang for 3 hours and bugger up after 2 mins of capture).

if i can find a nice big place to host these, i'll give it a shot. they're around 150 megs each.

[tateu]

I found a bug when opening files with more than 2 channels of audio (5.1, etc. such as an h264/aac trailer downloaded from apple.com)...it crashes :). I'm currently testing a fixed version that mixes it down to stereo and will hopefully have it available in a day or two. I've modified the new version so that all audio is output as 16bit Signed Int. I'd like to be able to return the data in the same format as the source file (8bit, all 6 channels, etc.) but that is not yet working. The new version will also feature much faster h264 decoding (about 15x the current version). For h264, though, ffdshow via DirectShowSource is still a better option. In my tests, it's atleast 1.5x as fast. And I'm still trying to get QTInput to return YV12 data.

I finally got a few raw clips encoded with QTOutput to the Avid Meridien Uncompressed Codec(AVUI), imported into Avid Adrenaline (it converts to omf) and printed to DigiBeta. I had to modify the raw output settings when using AVUI. Adrenaline didn't like the 2Vuy (uyvy) encoded files because it uses AVUI (also uyvy) but it stores each frame of 720x486 data as 720x496 (10 lines of black at the top) and has a four byte footer. It uses something similar for PAL and I need to add that correction in as well.

[Mug Funky]

hmm strange about the extra 10 lines. maybe it's for CC, macrovision or teletext?

i eaagerly await the next release. btw, avisynth can handle multichannel audio, so you may be able to return the correct number of channels without a downmix. this'd be cool for anime :) tapes come with ch 1+2 = english, 3+4 = japanese, and capping all 4 at once would be cooool (just do getchannel(1,2) etc). not sure if quicktime allows that kind of thing though.

[hanfrunz]

@tateu:
the extra lines in the avid file are just the "nonactive" lines, i found that avid also grabs them. You can switch this off somewhere in the settings, but then the lines are just blanked. You can use this for getting vitc and keycode-data into the avid system.

hanfrunz

[bond]

The new version will also feature much faster h264 decoding (about 15x the current version). For h264, though, ffdshow via DirectShowSource is still a better option. In my tests, it's atleast 1.5x as fast.great stuff, how did you get 15x to work? i recently measured the speed of various qt wrappers with h.264 mp4 with the following results:
- intervideo dshow: 19.93 fps (yuy2)
- qtinput 0.0.1: 19.60 fps (yuy2)
- qtinput 0.0.5: 18.74 fps (yuy2)
- cyberlink dshow: 18.60 fps (rgb24)
- qtreader: 15.72 fps (rgb24)

so you can see that qtinput seems to be pretty much in a range of the other wrappers

i noticed that qtinput 0.0.1 was faster than 0.0.5, any idea what caused the slowdown?

btw i couldnt get mode 1 and 2 to work with h.264 mp4 files!?
whats the difference, advantage/disadvantage of those? which one does qt itself use during playback?

And I'm still trying to get QTInput to return YV12 data.would be great. cant be that a yv12 h.264 stream cant be decoded to raw yv12 via qt :(
what colorspace does qt itself output during playback?

edit:
To get h264 mp4 decoding working in this latest version, I didn't actually use the new quicktime 7 API's, I just fixed an error in my old decoding method. My best guess is that my method causes quicktime to always start the decode process from the nearest ref frame, even when stepping sequentially through the file. I don't think there is a frame buffer for anything but the current frame. This means that it is decoding way more frames than it actually needs to.hm this sounds not good :(
is this still the case in 0.0.5?

[tateu]

I still haven't fully tested the new decoding routines so I haven't put together a release of a new version yet but if you want to give them a try (quicktime 6 will not work with this version)...http://www.tateu.net/software/QTSource_test_h264.7z. 6 channel audio should also now be correctly decoded to 6 channel 16bit pcm. Just be aware that this version may (and probably does) have even more bugs than my normal release versions and may have broken some previously working functions.

To test the new h264 speeds, use mode=2.
QTInput("file.mp4", color=2, mode=2)


As far as I can tell, the quicktime player seems to only operate in RGB. Using QTInput in RGB mode produces colors that are a much closer match to what quicktime player puts out. I do not know what decoding method it uses, though.

The new speed increase is using mode=2. Mode=0 speeds are still just as slow in the new version. Mode=0 uses a generic quicktime API function called MoviesTask which does all of the decoding work behind the scenes. You jump to a specific frame number, then call MoviesTask and it returns the decoded frame. From what I can tell, this method redecodes frames several times, almost as if it has to start the decode process from the nearest I-Frame, for every single frame, even when stepping sequentially. To decode frame 1, it redecodes frame 0. To decode frame 2, it redecodes 0 and 1. To decode frame 3, it redecodes 0, 1 and 2. Watch the frame rate as the file plays back, it starts out fast then slows down more and more, then instantly speeds up (when it reaches an I-frame, I think) then gradually slows down again. This means that it is possibly decoding 10-20 times the amount of frames actually contained in the file and why it can give you decent results on a 0 b-frame file but terrible results on a 2 b-frame file.

For the new method in mode=2, when a movie is first loaded, QTInput uses a QTSampleTableRef from CopyMediaMutableSampleTable to grab a list of all video frames with their respective decode and playback times. The list is copied into two vector structs and one is sorted by playback order and the other is sorted by decode order. It also keeps track of the last frame number decoded, the nearest I-Frame and a small buffer of 6 or 7 recently decoded frames. When avisynth requests a specific frame, QTInput uses the vector structs to determine which frames to decode and which frame to return for playback or. If you step sequentially forward by 1 frame at a time, this new method only decodes each frame once, so you get a huge increase in speed over the old method. If you skip ahead by several frames, it starts the decoding either from the last decoded frame or the nearest I-Frame, whichever is closer.

Mode=1 only works for uncompressed sources. It is a raw copy method that bypasses all quicktime codecs and returns raw YUV or RGB data.

I'm not sure why v0.0.1 would be faster than v0.0.5. The 0.86 fps your results show is such a small amount and I've made a ton of changes since v0.0.1. What test method are you using to get your results? Do your sample files have b-frames? The only way I can get speeds with QTInput mode=0 that are even in the same neighborhood as other decoders is on files that don't have b-frames.

I reran some mplayer benchmark tests today using the sample file you posted on page 2 of this thread (quicktime.mp4) and also a trailer from apple's site (King Kong 480p (http://movies.apple.com/movies/universal/king_kong/king_kong-tlr_h480p.mov))converted to mp4 using mp4box (mp4box.exe -add king_kong-tlr_h480p.mov#1 -add king_kong-tlr_h480p.mov#2 king_kong-tlr_h480p.mp4). Both of them contain b-frames. These tests show the new mode=2 to be about 10x as fast as mode=0 and DirectShowSource with various decoders to be as much as 2.25x as fast as mode=2. And DirectshowSource used about 1/4 the amount of memory used by QTInput. To play the King Kong trailer, CoreAvc through DirectShowSource never went above 100MB, whereas QTInput used almost 400MB. I'm sure atleast some of this memory increase in QTInput is due to bad programming on my part but I don't know if any of it is actually due to quicktime itself.

The tests were run on a Dual 3GHz Xeon with 2GBs of ram using Celtic Druid's mplayer2006.01.01.P4.7z, Celtic Druid's ffdshow-20051103.exe and avisynth v2.5.7.0 built on 2005-12-15.

quicktime.mp4 - 300 frames
- QTInput Mode 0: 19.921s = 15.06 fps
- QTInput Mode 2: 1.932s = 155.28 fps
- AviSynth DShow ffmpeg: 0.983s = 305.19 fps
- AviSynth DShow CoreAVC 0.0.4: 0.907s = 330.76 fps
- AviSynth DShow Moonlight: 0.858s = 349.65 fps
- AviSynth DShow Nero6: 1.150s = 260.86 fps
- QTInput v0.0.1: Failed to decode

MPlayer dev-CVS-060101-18:59-4.0.2 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium 4/Celeron 4 Northwood; Pentium 4 EE/Xeon Prestonia, Galla Family: 15, Stepping: 9)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

86 audio & 201 video codecs
Playing quicktime_Mode2.avs.
AVS file format detected.
VIDEO: [YV12] 640x256 12bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
=====================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 640 x 256 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 640x256 => 640x256 Planar YV12
Selected video codec: [rawyv12] vfm: raw (RAW YV12)
=====================================================

mplayer -vo null -benchmark quicktime_Mode0.avs
QTInput("quicktime.mp4", color=2, mode=0)
mplayer -vo null -benchmark quicktime_Mode2.avs
QTInput("quicktime.mp4", color=2, mode=2)
mplayer -vo null -benchmark quicktime_Dshow.avs
DirectShowSource("quicktime.mp4", 25)
mplayer -vo null -benchmark quicktime_v0.0.1.avs
QTInput("quicktime.mp4", color=2)

king_kong-tlr_h480p.mp4 - 4201 frames
- QTInput Mode 0: 271.514s = 15.47 fps
- QTInput Mode 2: 39.101s = 107.44 fps
- AviSynth DShow ffdshow: 29.684s = 141.52 fps
- AviSynth DShow CoreAVC 0.0.4: 23.679s = 177.41 fps
- AviSynth DShow Moonlight: 34.910s = 120.34 fps
- AviSynth DShow Nero6: 30.584s = 137.36 fps
- QTInput v0.0.1: 272.396s = 15.42 fps

VIDEO: [YV12] 848x352 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
=====================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 848 x 352 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 848x352 => 848x352 Planar YV12
Selected video codec: [rawyv12] vfm: raw (RAW YV12)
=====================================================

mplayer -vo null -benchmark king_kong-tlr_h480p.mp4_Mode0.avs
QTInput("king_kong-tlr_h480p.mp4", color=2, mode=0)
mplayer -vo null -benchmark king_kong-tlr_h480p.mp4_Mode2.avs
QTInput("king_kong-tlr_h480p.mp4", color=2, mode=2)
mplayer -vo null -benchmark king_kong-tlr_h480p.mp4_Dshow.avs
DirectShowSource("king_kong-tlr_h480p.mp4", 23.976)
mplayer -vo null -benchmark king_kong-tlr_h480p.mp4_v0.0.1.avs
QTInput("king_kong-tlr_h480p.mp4", color=2)

[foxyshadis]

Curious, but do you throw away decoded b-frames? If you have knowledge of the decode order you can throw away frames as soon as they are no longer referenced (or never referenced at all), and that might keep mem usage down. If quicktime lets you know the references, that is...

[bond]

I still haven't fully tested the new decoding routines so I haven't put together a release of a new version yet but if you want to give them a try (quicktime 6 will not work with this version)...http://www.tateu.net/software/QTSource_test_h264.7z. 6 channel audio should also now be correctly decoded to 6 channel 16bit pcm. Just be aware that this version may (and probably does) have even more bugs than my normal release versions and may have broken some previously working functions.

To test the new h264 speeds, use mode=2.
QTInput("file.mp4", color=2, mode=2)i tried it on a .mp4 file encoded with qt7 itself (1 b-frame) and i dont get a speedup at all :(
in fact it gets slower:
mode2: 17.74 fps
mode0: 18.91 fps

I'm not sure why v0.0.1 would be faster than v0.0.5. The 0.86 fps your results show is such a small amount and I've made a ton of changes since v0.0.1. What test method are you using to get your results? Do your sample files have b-frames? The only way I can get speeds with QTInput mode=0 that are even in the same neighborhood as other decoders is on files that don't have b-frames.my sample file uses 1 b-frame (has been encoded with qt)
my speed measurement method is loading the avs via directshow into graphedit and than using the elecard chegepua (http://forum.doom9.org/showthread.php?p=703999#post703999) renderer

I reran some mplayer benchmark tests today using the sample file you posted on page 2 of this thread (quicktime.mp4)i tried this sample too with both modes and on this sample there is indeed a big difference
with mode0 i get like 1.5 fps, with mode2 i get like 25 fps

quicktime.mp4 has been encoded with x264 and aimed at only using settings the qt7 encoder also uses. it wasnt perfect tough (used adaptive b-frames and only 1 slice) so i made a new one with the following settings being equivalent to the settings the qt7 encoder uses:
x264 --bitrate 770 --threads 5 --bframe 1 --no-b-adapt --ref 1 --filter 0:0 --no-cabac --subme 5 --analyse p8x8,b8x8,i4x4 --progress --no-psnr -o quicktime_x264.mp4 input.avsi also encoded with the same settings to raw .264 and muxed the stream into .mp4 with both mp4box and mp4creator to see if this makes a difference
you can get all these samples here (http://home.pages.at/bond_/quicktime_x264.7z)

as you will see yourself, all those samples also play very slow with mode 0, but ok with mode 2

i think there are now two possibilities:
1) mode 0 takes care about buffering_period SEI the qt7 encoder writes into the h.264 bitstream, but x264 doesnt
2) the qt7 mp4 muxer does something different than the others which make mode 0 be able to play the file faster

ad 1) this is not the case, because when i remux an qt7 encoded h.264 stream with mp4box to .mp4, the resulting file also plays slow with mode 0

ad 2) i guess thats the reason for the speed difference between decoding qt7 produced mp4 files and others with mode 0

x264 uses the gpac lib for mp4 creation (as mp4box does too). mp4creator uses its own lib. i have to say i tested the libgpacs and mp4creators mp4 files extensively and i dont know any open issues. so, as both also show the same slow speed, i dont think they do anything incompliant
i also tried remuxing all the files via qt7 passthrough, which didnt work as qt crashed reporting an "unknown error"

comparing the same stream once created with qt7 and once remuxed with mp4box and mp4creator i see the following differences in the files:
- slightly different durations in the mvhd and tkhd atom (mp4box and mp4creator have the same)
- qt7 has an elst atom (under edts)
- qt7 has a sdtp atom with lots of 00 and 08 (under stbl atom)
- qt7 has far more entries in the stsc and stco atoms (under stbl)
- qt7 has two free atoms before the mdat (mp4box doesnt, mp4creator has the mdat at the beginning)


btw i also noticed that the mp4creator created mp4 doesnt work with mode 2 (it works with mode 0). i only get a green picture (maybe because the mdat is at the beginning, headers at the end?)
qt7 handles it, so i think qt7 itself doesnt use your mode 2 during playback


The new speed increase is using mode=2. Mode=0 speeds are still just as slow in the new version. Mode=0 uses a generic quicktime API function called MoviesTask which does all of the decoding work behind the scenes. You jump to a specific frame number, then call MoviesTask and it returns the decoded frame. From what I can tell, this method redecodes frames several times, almost as if it has to start the decode process from the nearest I-Frame, for every single frame, even when stepping sequentially. To decode frame 1, it redecodes frame 0. To decode frame 2, it redecodes 0 and 1. To decode frame 3, it redecodes 0, 1 and 2. Watch the frame rate as the file plays back, it starts out fast then slows down more and more, then instantly speeds up (when it reaches an I-frame, I think) then gradually slows down again. This means that it is possibly decoding 10-20 times the amount of frames actually contained in the file and why it can give you decent results on a 0 b-frame file but terrible results on a 2 b-frame file.

For the new method in mode=2, when a movie is first loaded, QTInput uses a QTSampleTableRef from CopyMediaMutableSampleTable to grab a list of all video frames with their respective decode and playback times. The list is copied into two vector structs and one is sorted by playback order and the other is sorted by decode order. It also keeps track of the last frame number decoded, the nearest I-Frame and a small buffer of 6 or 7 recently decoded frames. When avisynth requests a specific frame, QTInput uses the vector structs to determine which frames to decode and which frame to return for playback or. If you step sequentially forward by 1 frame at a time, this new method only decodes each frame once, so you get a huge increase in speed over the old method. If you skip ahead by several frames, it starts the decoding either from the last decoded frame or the nearest I-Frame, whichever is closer.i noticed that the first time you decode some frames its slow. when you stop and restart playing the frames the already decoded ones are shown very fast and once you come to frames that havent been decoded yet it slows down a lot
this is with both mode 0 and 2, i assume this means qt somewhere buffers the already decoded frames with both modes?

edit: changed a lot with new findings

[bond]

actually i think the reason for the performance difference between qt7 created files and others is the sdtp atom

the specs say:
Independent and Disposable Samples Box

This optional table answers three questions about sample dependency:
1) does this sample depend on others (is it an I-picture)?
2) do no other samples depend on this one?
3) does this sample contain multiple (redundant) encodings of the data at this time-instant (possibly with
different dependencies)?propably quicktime relies on this info during playback?

either way sdtp is not mandatory, so a player shouldnt need it for playback

[Longinus]

Hello!
First, thanks a lot for this plug-in Tateu. Its really useful for me (especially the output part)..

I'm writing to let you know that I created some very big mov files out of it (120gb, the biggest) and it worked great. The input too, is very nice.. A big step from using the vfapi reader (that had to be tweaked for fps, flipped, etc).

I have only one question... how hard is to make a plug-in to let Quicktime open AVS files? The biggest problem with QTOutput is having to use Virtualdub to play it... I don't even know why the windows Quicktime can't open AVI with directshow, supporting all the AVI codecs you have. So I think if quicktime supported avisynth, it would be really useful for a lot of people. Do you think something like this is possible? Or perhaps to you intend to make a CLI like you said in an earlier post?

Again, thanks for this great addition to avisynth.

[makoto916]

Sorry to reopen a dormant threat. I'm curious if there have been any advancements of this input filter, namly in the implementation of a CLI or VirtualDub filter?

I'm always writing automation scripts (mostly in Perl and Windows Script) that convert from one thing to another as I also use AVISynth in a production environment. Until now, there has never been a reliable and consistent way to decode QuickTime through AVISynth (especially if it is Avid OMF). So this filter is extremely exciting as it eliminates the need for DirectShowSource and the quirks that come along with it. The addition of a CLI app to handle the output side would be the proverbial icing on this very tasty cake.

[Longinus]

Yep, I second that!

I can even take any alpha version you might have made. =D

[Mug Funky]

if you're doing batches and stuff, try mplayer to play it and avs2wav to get the audio out, then pass the results onto whatever's next in your chain. it works pretty well that way (as well as using virtualdub i'd imagine).

i even use avisynth + mplayer to resize DVD flats from PAL to NTSC and vice-versa (lanczos + subpel accurate cropping for the win! does it far better than photoshop, and a lot quicker). with enough fannying about you can use a combination of avsi functions, ECHO commands to avs files, and CLI programs like mplayer and avs2wav to go from anything to anything else. it's hacky, but works pretty well.

the only kink in the chain is soft encode which has laughably bad CLI support - took a while to get that working.

[rollow]

Tateu,

First of all a big thanks for the QT import filter. I have a question about working with QT movies with multiple videotracks, as far as I can tell only the first vid track is processed, and the duration of the movie is based on that vid tracks' duration. Would it be feasible to 'keep looking' and also process the other tracks in the QT container?

TIA for your answer

Tim

[Chainmax]

I am trying to make a DVD version out of the "Ginga" series of videos available for download at NikeSoccer's site. QTSource loads them perfectly, but a few scattered frames appear blocky (like artifact-blocky, not low-bitrate-blocky). What could it be due to?

[hanfrunz]

does your quicktime player play it correctly? Can you give a link to the file? And which Quicktime version are you using?

[Mug Funky]

what format are the videos? mp4 i suppose?

from what i've seen mp4 is a bit of a tricky case. disabling audio helps though, but you probably already did that.

btw, you can get Ginga on DVD in r4 through a certain independent distributor...

[Chainmax]

hansfrunz: I don't know, I didn't watch them, but I assume those blocks would appear on playback as well. I don' think a direct link can be obtained for the files, as the Ginga subsite is entirely made in flash (or something like that), but go to http://www.nike.com/nikesoccer/, once it loads, go to the "Archive" section, select "Ginga, the soul of Brazilian soccer" and download one of the chapters.
[edit]They seem to have either moved it somewhere else or eliminated it.


Mug Funky: I think it was .MOV. I deleted it anyway since the DVD I'm making is about Eric Cantona and I found more on-topic things to put in it. In any case, why would I pay for a DVD when the official site was offering the episodes for free (albeit on a crappy quality)?

[binba]

One of the raw modes (and an important one) is "yuv2" - correct me if I'm wrong, it's just a mistake (http://forum.doom9.org/archive/index.php/t-73305.html)and is supposed to be "yuy2".

p.s. This filter is great! Why oh why didn't I find out about it earlier, and saved a year's worth of messing with QTReader.

[tateu]

According to Quicktime docs, YUV2 does exist and is slightly different than YUY2.

http://developer.apple.com/quicktime/icefloe/dispatch020.html
YUV2 - kYUVUPixelFormat - 'yuvu'
Y0, Cb, Y1, Cr
16 bit pixel, unsigned eight bit luminance component and two two’s complement signed eight bit chroma components. Luminance components have a range of [0, 255], the chroma values have a range of [-127, +127].

YUY2 - kYUVSPixelFormat - 'yuvu'
Y0, Cb, Y1, Cr
16 bit pixel, unsigned eight bit luminance component and two unsigned eight bit chroma components. Luminance components have a range of [16, 235], the chroma values have a range of [16, 240].


http://developer.apple.com/quicktime/icefloe/dispatch019.html#yuv2

http://developer.apple.com/quicktime/icefloe/dispatch019.html#schemeA
Scheme A: "Wide-Range" Mapping with Unsigned Y´, Two's Complement Cb, Cr
for 8-bit
Y´=floor(0.5 + 255 * EY´) Y´=[0,255] as EY´=[0,1]
Cb=floor(0.5 + 254 * ECb) Cb=[-127,+127] as ECb=[-0.5,+0.5]
Cr=floor(0.5 + 254 * ECr) Cr=[-127,+127] as ECr=[-0.5,+0.5]

http://developer.apple.com/quicktime/icefloe/dispatch019.html#schemeB
Scheme B: "Video-Range" Mapping with Unsigned Y´, Offset Binary Cb, Cr
for 8-bit
Y´=floor(0.5 + 219 * EY´ + 16) Y´=[16,235] as EY´=[0,1]
Cb=floor(0.5 + 224 * ECb + 128) Cb=[16,240] as ECb=[-0.5,+0.5]
Cr=floor(0.5 + 224 * ECr + 128) Cb=[16,240] as ECr=[-0.5,+0.5]

And the same info
YUV2 http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#yuvu
YUY2 http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#yuvs

http://developer.apple.com/documentation/QuickTime/QTFF/QTFFChap3/chapter_4_section_2.html
yuv2 conversion to rgb. The r, g, and b values range from 0 to 255.
r = 1.402 * v + y + .5
g = y - .7143 * v - .3437 * u + .5
b = 1.77 * u + y + .5




And I seem to have missed several questions posted over 6 months ago...As long as I am here I might as well answer them...

@makoto916 and Longinus,
I had the framework for a cli version done long, long ago but I never went anywhere with it because I didn't feel like writing the vfw/Directshow code to read data from an input source (avi, mpeg, whatever). AViSynth already handles all that and converts it into raw video for me to work with.

@rollow,
It should be possible to allow selection of something other than the first video or audio track. I had planned to work on this, I figured there would be two new QTInput parameters (vtrack and atrack), I just never got around to it. I got just about everything I needed working at a satisfactory level to handle a new workflow implemented at my office back in 2005 and, to be honest, for the most part I just sort of stopped working on it when it reached that stage.

It turns out that I wrote some incorrect code (gee, what a surprise!) in my OMF import plugin that is now broken with the release of AviSynth v2.57 so it looks like I will atleast have to spend some time fixing that. Maybe, if I feel adventurous enough, I will attempt to dive back into the quicktime code and see what I can do.

[dvdan23]

This had been useful to me despite whatever limitations it had. The newest quicktime kills it so it bombs out when accessing a quicktime video. As it has not been developed in some time, is anyone able to pick this up and try to fix it?

[rollow]

That's bad news indeed. Glad I didn't update yet. As it is part of my daily workflow, I'm even willing to _pay_ someone to pick this up. Tateu are you still reading this thread? Would you mind if someone took over development?

[tateu]

The latest version available from apple is v7.16 (http://www.apple.com/quicktime/download/). I have been using Quicktime v7.15 with QTSource and AviSynth v2.5.7 for months without problems and I just upgraded to v7.16 yesterday, when I first heard mention of a problem. It runs just fine on my systems.

What happens if you write a simple avs script:

QTInput("yourmovie.mov")

and open it in VirtualDub?

Can you tell me more about the problem? Avisynth version, qtsource version, quicktime codec specs, with/without audio, etc?

And the source code is out there so anyone wishing to modify it is more than welcome to.

[Razorholt]

Hello,

I have a bunch of DV files (DV/DVCPRO) that I would like to convert. I used QTinput at first but I'm not quite happy with the result. The picture is very blurry.

I used the following line:
QTinput("F:\MyDVfile.dv",quality=100,mode=2)

Thanks a lot

[tateu]

And if you open it up in Quicktime player it should be blurry also. It's the quicktime DV codec. It should not be blurry with QTInput, quality=100, though. I am testing it right now with PAL and NTSC dv. They are blurry in quicktime player, they are blurry with QTInput if quality=0, but they are fine with QTInput if quality=100.

What version of QTInput, Quicktime, Avisynth? PAL or NTSC? DV or DVCPro? Change your QTInput script to
QTinput("F:\MyDVfile.dv",quality=100,mode=2,info=1)
What codec does it say is being used?

If you want to upload a sample movie somewhere, I will take a look. You could also try FFMpegSource (search the forum for it). It will most likely be faster (though I haven't actually tested it, but I know quicktime is always slow). If I actually had a choice I would never use quicktime for anything.

[Razorholt]

I'm using the latest version of your script with AVISynth 2.5.7 and QT 7.2.

The file's format is DV/DVCPRO - NTSC (640x480)

I did changed the script to info=1 but nothing happened, no info.

How can I get a sample of a DV file without re-encoding?


Thanks Tateu for for help.

- Dan

[tateu]

Either of these will cut 1/2 second of raw video into a new file, starting at 10 seconds:
ffmpeg.exe -ss 00:00:10.000 -t 00:00:00.500 -i "MyDVfile.dv" -an -vcodec copy -f rawvideo "MyDVfile_cut.dv"
or
mencoder.exe -ss 00:00:10.000 -endpos 00:00:00.500 "MyDVfile.dv" -nosound -ovc copy -of rawvideo -o "MyDVfile_cut.dv"
or, if it is raw dv (as your file extension suggests), you could even use a hex editor and save the first 2 or 3 MB to a new file.

Are you sure it's 640x480? I believe that 720x480 is the only legal resolution for NTSC DV. And if info=1 does nothing, there is something definitely wrong. That setting should add text at the top of the video with codec and decompression info, like this (http://www.tateu.net/QTInput.png).

And what happens if you open the file in Quicktime player? Is it blurry?

[IanB]

640x480This smells like a still camera MJPEG video. Kodak, etc, wrap these in .MOV just to be difficult, ffmpeg'ing them into an .AVI container works very well.

[Razorholt]

From Quicktime it says 640x480... weird. But I think it is 720. Here is the file: http://70.86.69.186/~matrix/sample_cut.zip

Thanks,
- Dan

[tateu]

Oops, I guess I should have given you the start time parameter for ffmpeg and mencoder since the 15 frames you uploaded are from a fade in. Don't bother sending another file, though, the sample you already posted is good enough for our purposes...Here are the modified commands anyway:

Either of these will cut 1/2 second of raw video into a new file, starting at 10 seconds:
ffmpeg.exe -ss 00:00:10.000 -t 00:00:00.500 -i "MyDVfile.dv" -an -vcodec copy -f rawvideo "MyDVfile_cut.dv"
or
mencoder.exe -ss 00:00:10.000 -endpos 00:00:00.500 "MyDVfile.dv" -nosound -ovc copy -of rawvideo -o "MyDVfile_cut.dv"

And here is frame 14 of your video opened with: (http://www.tateu.net/QTInput_q000.jpg)
QTInput("sample_cut.dv", mode=2, quality=0, info=1)

And here is frame 14 of your video opened with: (http://www.tateu.net/QTInput_q100.jpg)
QTInput("sample_cut.dv", mode=2, quality=100, info=1)

You can see that the codec info is printed on the top of both and you can also see that the airplane is blurry in the frame with quality=0 but not with quality=100. There is nothing wrong with your video and there is nothing wrong with QTInput over here...quality=100 is as sharp as it should be. Can you post your entire avs script? Maybe there is something else going on there. And then can you try a script with nothing but:
QTInput("sample_cut.dv", mode=2, quality=100, info=1)

[Razorholt]

here is the code
QTinput("F:\file.dv",quality=100,mode=2)
LanczosResize(592,336)
Crop(0,24,0,-24)

New sample: http://70.86.69.186/~matrix/sample_cut2.rar

[tateu]

This is what I get with your sample file and your script. Compare one of them to the avs output on your computer. Is it the same or different? (All three of the following links are identical video, they are just encoded with different codecs. You only need to download one.)

If you have the Lagarith codec installed, file size = 7.54MB
...link removed...

If you have the HuffYUV codec installed, file size = 9.57MB
...link removed...

If you don't have the above codecs, file size = 12.1MB
This is uncompressed video, but you need something that can decompress 7z archive files (7zip, winrar. etc.)
...link removed...

[Razorholt]

I got the same results - So I guess this is the file...

My guess is that they have encoded the source to DV but they've done a terrible job. It's so noisy and the frames are even messed up.

Anyway, I thank you Tateu for your precious help :)

[LigH]

No issues found in the latest H.264/AAC trailer, released today (if I am not wrong):

DNF_Teaser_720p_HD.mov = "Duke Nukem Forever" teaser (75.7 MB, 720p, 8.8 Mbps AVC/160 kbps AAC). Downloads at http://www.3drealms.com

I just had to include "ConvertAudioto16bit()" when using ACM codecs in VirtualDubMod, because QuickTime decodes AAC to 32bit, and VirtualDubMod seems not to pass through the MS PCM Converter (VirtualDub 1.7.6 does), and LAME ACM only expects 16 bit samples.

LoadPlugin("QTSource.dll")
QTInput("DNF_Teaser_720p_HD.mov", color=2, quality=100, audio=true)
ConvertToYV12(interlaced=false)
ConvertAudioTo16bit()

[jollye]

Hi,

Where can I find QTSource source code? The link in the help page doesn't work.

Thanks for your help.

[tateu]

My web host has been having some issues lately...the link does work but my site has been up and down for the past few days. If, for some reason you have a help file with an incorrect link, the link in the first post of this thread is the correct one.

[jollye]

Hi,

Thanks for your answer.
What happens is that when I use the source code download link, I get the following message box popping:

http://img165.imageshack.us/img165/3496/bugcc5.th.png (http://img165.imageshack.us/my.php?image=bugcc5.png)

Thanks for your help

[IanB]

Just click Save and then give the file a good name.

[tateu]

Yes, it's php not javascript and there's a reason I use it instead of a straight link...

It mainly has to do with handling a small pet peeve of mine: I hate clicking on a direct download link and not knowing what version it is that I have downloaded.

With a direct download link, the only way I know of to solve that, is to create a separate link every time a new version comes out (link_to/version01.zip, link_to/version02.zip, etc.). But then it's very easy for people to mistakenly download old, outdated versions.

If I create just one generic direct download link (link_to/generic.zip) and replace the underlying file every time a new version comes out...this would keep people from accidently downloading an old version, but they would have to unzip it/install it to find out what version it is.

Using the php script, I can give a generic download link and, when someone clicks on it, the correct file to send is read from a text file/database and the user gets the latest version with version info embedded in the file name.

That's the plan anyway. It seems it doesn't always work as evidenced by jollye (not sure why, though).

[Leak]

Using the php script, I can give a generic download link and, when someone clicks on it, the correct file to send is read from a text file/database and the user gets the latest version with version info embedded in the file name.
Since your content isn't actually generated on-the-fly - how about putting archives for all versions (with the version number in their name) into a directory, then making your PHP script actually send a redirect to the real file based upon the parameter passed to it?

That way a browser has no choice but to save the file under the correct name... :)

(And if the file is generated on the fly - it's possible set up your server to send all requests under a certain location to a handler script so that you can put the real file name into the URL anyway and create the content based on the parameters, or by analyzing the requested file name, or something similar...)

Just my 0.02€...

np: Duo505 - Choral (Another Illusion)

[jollye]

Thanks. Now it's working.
I tried to recompile the sources because I want to make some "small" modifications but I couldn't. I installed the latest QuickTime SDK. I am using Visual .NET 2005.

The first error I get is the following:

1>C:\...\qtsource\QTMovie.h(88) : error C2146: syntax error : missing ';' before identifier 'strStatus'

Any idea?
Thanks for your help.

[tateu]

It looks tchar.h is not getting included. On my system, it is included somewhere, by default (maybe?)...not really sure where since I didn't explicitly include it in one of my files...in fact, it is included, but commented out in QTMovie.h line 12. Try uncommenting that line.

And if you don't mind me asking: what changes are you trying to make? I haven't done any work on this in a long while (though I have newer versions that I never released because they just had to many small issues that I never solved) and, if you make some worthwhile changes and/or fix some of the many bugs, I wouldn't mind making them official.

[jollye]

Hi,

I also had to uncomment the following line in QTMovie.h:
#include <wtypes.h>

what changes are you trying to make?

I have written some custom .avs scripts that are supposed to open any type of video. Their principle is that they use different plugins. They try a plugin and catch an exception that should occur when the input format is not supported by the plugin. My problem is that it seems QTSource accepts some formats that I don't want it to accept like *.AVI. So I want to modify the code so that when it tries to open an *.AVI it generates an exception instead of (badly) trying to open it.

[dr.schanker]

First let me thank You for this nice plugin. I used version 0.0.5a for some time now and it worked quite nicely.
The only downside was an exception if i tried to open my .avs with Windows Media Encoder (WMCmd.vbs) or e.g. VirtualDub (open the same .avs twice in a row).

Your new alpha-version 0.0.8 (from this thread: http://forum.doom9.org/showthread.php?t=143308) fixed that problem but added sadly another.
For some .mov i get really strange results for framerate & framecount.

Here is an example (1 second snippet because of filesize):
http://www.mediafire.com/?4tzmym0yzdz
(10MB, 1920x1080@25fps, codec=mjpb)

This .mov is reported by QTPlayer, ffmpeg, MediaInfo as 25 fps.
Using QTSource.dll v0.0.8, Avisynth's Info() reports:
Frame: 0 of 608
Time: 00:00:00:000 of 00:00:00:999
Fps: 608.2725 (250000/411)

This simple script shows the problem:

qtinput("sample_short_25fps.mov",color=0,quality=100,audio=false)
info()


I tried to change some parameters of qtinput(), "color" or "mode" didn't fix it.
Forcing "vfrFPS" to 25 seemed to work, but it would be nice if the default (vfrFPS=0) would give correct results too.

The problem occurs with Quicktime 7.1.6 and 7.5.5, i am running Windows XP SP2 and Avisynth 2.58 RC4.

[tateu]

I hate quicktime...I really hate quicktime...with it's stupid movie timescale and different video timescale and it's stupid individual frame durations and it's stupid variable frame rate, even when the video is not variable frame rate...


dr.schanker,

I see a couple of ways to fix it: one is just to go back to the old way and another tries to incorporate some of my attempts at making variable frame rates work. When I find some free time I will attempt to get it fixed...

[dr.schanker]

tateu,

thank you for the quick reply. please take your time, it's not worth getting upset about. ;)
in the meantime i'm downgrading to v0.0.5 + intermediate huffyuv.

best regards and have a nice christmas time.

[Mug Funky]

here's a question...

say you're exporting a quicktime like we all love to do, then there's an interruption (crash, somebody resets the net switch, whatever). the file hasn't had it's header written and so can't be loaded. but there may be several hours rendering in that file...

is it possible to add this header to a busted file after the fact? no programs i've found can save a bung quicktime (error -2048), but there's similar utilities for fixing busted avi files.

this would help not only in use of this plugin, but quicktimes output by macs as well. anywhere something unforseen stops the entire file being written.

[stoffal]

Hi ! This plugin really helps me getting my quicktimes into avisynth. I wonder how the export works. Unfortunatly, I can not reference an input video. Something like this does not work:

loadplugin("c:\QTsource.dll")
myfilm = QTInput("mymovie.mov")
myfilm.info()
qtoutput("output.mov")

When I work with a reference (myfilm) , then the QToutput does not work any more.
I HAVE to work with references for my scripts. Any idea how to solve this?

[tateu]

It works just fine for me using reference files and the latest QTSource (20110219). I successfully outputed MOV files using the Animation, Avid Meridien and Mpeg4 codecs with the AVS opened in VirtualDub in Windows 7 Ultimate x64 and AviSynth 2.58 tsp MT version 5.

I need more info: AviSynth version, QTSource version, MOV codec, etc. and possibly an MOV file to test.

[neuron2]

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.