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

[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.