ColorMatrix v2.3

[Wilbert]

TMPGEnc converts it to RGB24 for you. Thus TMPSource also delivers RGB24. TMPGEnc uses fcc coefficients (=Rec.601) for the YV12->RGB24 (and vice versa) conversion.


TMPsource("yourtprfile")
converttoyv12()


converts it back to YV12 using the same (ie Rec.601) coefficients. Ok, that's good and we don't have to worry about this conversion to RGB in between.

So the script:

TMPsource("yourtprfile")
converttoyv12()
ColorMatrix(d2v="xxx.d2v")

should be correct when encoding to XviD/DivX.

[jackiehcs]

I see, thanks.

[Ginsonic]

I'd meant to send it to Wilbert to take a look, but I've been busy the last month or so and haven't had the time to finish it. I did finally sit down today and finished the asm routines and made the d2v option able to work with sources that have multiple colorimetry types... so maybe in the next couple days.

Knock, knock ;) Is there any news ?

[jmac698]

I did some research, and bbmpeg can set the coefficients in advanced settings. Now you just set it the same as your source. If you have dvb/s or hdtv, set rec709, for cap set rec601, and for properly made xvid set rec601.

Only one problem, bbmpg is an older program and we need to increase the motion vector length, and apply some good matrices.

I found that freeenc (based on libavcodec) has no option for color coefficients.

Ideally we need the option in restream, to set the whole stream to a coefficient.

There is one more problem of different coefficients in one stream, and the only solution so far is colormatrix. Use the coeff. of the main movie in the bbmpg settings, and use colormatrix with hints to convert 601->709 when 601 appears.

[Inc]

I found that freeenc (based on libavcodec) has no option for color coefficients.
IF theres an option in the Libavcodec XXXcontext settings to set the coefficients for the encode then this could be integrated in FreeEnc or Qenc as both are open source.

[jmac698]

I see nothing in
http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC9
relating to color coefficients. Any other ideas?
Also
http://mplayerhq.hu/~michael/ffmpeg-doxy/structMpegEncContext.html
Has a lot of info, I don't think it's there but I'm not sure.

[Hans Ohlo]

i read trough most parts of the thread. since a hdtv transport stream i recorded showed nothing in gspot i had to determine which coefficents were used. so i loaded the avs script into virtualdub took a screenshot and did the same with the mpeg in mpc. then i compared. i found that when i used colormatrix the result was more a match. now after encoding with x264 and nero digital avc the colors were to bright and i have to do the encode all over again. isnt there a way to determine for shure if to use colormatrix or not?

[Wilbert]

i found that when i used colormatrix the result was more a match. now after encoding with x264 and nero digital avc the colors were to bright
This might be a playback issue. What are you using to play it?

[Hans Ohlo]

This might be a playback issue. What are you using to play it?
CoreAVC (0.0.0.4 alpha)

[Wilbert]

i read trough most parts of the thread. since a hdtv transport stream i recorded showed nothing in gspot i had to determine which coefficents were used. so i loaded the avs script into virtualdub took a screenshot and did the same with the mpeg in mpc. then i compared. i found that when i used colormatrix the result was more a match. now after encoding with x264 and nero digital avc the colors were to bright

I guess the same happens when you don't use ColorMatrix?

[Hans Ohlo]

I guess the same happens when you don't use ColorMatrix?
no, i did a reencode without colormatrix and the colors are ok. strange is what i described before...

[jellysandwich]

1) 1) I709 (= Rec.709 coefficients)
2) FCC (almost the same as Rec.601)
3) I470 (= Rec.601 coefficients [an updated version of Rec.470-6, but coefficients are exactly the same])
4) S170 (= SMPTE 170M; exactly the same as Rec.601)
5) S240 (= SMPTE 240M; almost the same as Rec.709)

If the boxes remain "black" then the used coefficients are not present in the header, and the default (which is Rec.709) should be assumed.


I'm confused about this whole ColorMatrix thing. If the boxes are black, then I should assume Rec.709 was used, and I should use ColorMatrix (Megui x264)?

js

[Wilbert]

I'm confused about this whole ColorMatrix thing. If the boxes are black, then I should assume Rec.709 was used
Yes, indeed.

and I should use ColorMatrix (Megui x264)?
Yes again.

[Hans Ohlo]

Yes, indeed.


Yes again.
yep but in my experience in 90% of the time this is wrong and the colors (especially red) are to bright...

[Wilbert]

yep but in my experience in 90% of the time this is wrong and the colors (especially red) are to bright...
Could you upload a 10 frames vob somewhere showing this problem?

[Hans Ohlo]

it is no vob it is from mpeg2 high def ts streams.

[Wilbert]

Ok, could you cut it with some tool and upload 5-10 frames from that?

[HOLiC]

Hi, I have a quick question!
Is it necessary to use colormatrix right after source, before ivtc?
(I just remebemer someone saying that filter won't do anything if it didn't come right after the source..)

I'm trying to encode something using "tivtc mkv-vfr" method and I can't use colormatrix, since I keep getting an error about clip being not matched, or something like this:


Avisynth Open failure:
TFM: crc32 in input files does not match that of current clip...


So, I placed colormatrix after ivtc, and it seems to work fine:


mpeg2source()

TFM(mode=1,input="tfm.txt")
oldcount=framecount
tdecimate(mode=5,hybrid=2,input="tdec.txt",tfmIn="tfm.txt",mkvOut="timecodes.txt")

colormatrix(mode="Rec.709->Rec.601")

oldfps=framerate
averagefps=(float(framecount)/float(oldcount))*oldfps
assumefps(averagefps).Nicefps()


I'm just worried that if I do it like this, the filter won't do anything...
I would appreciated it if someone would confirm this.
Thanks in advance!!

[Wilbert]

Is it necessary to use colormatrix right after source, before ivtc?
(I just remebemer someone saying that filter won't do anything if it didn't come right after the source..)
Only if you use hints.

I'm trying to encode something using "tivtc mkv-vfr" method and I can't use colormatrix, since I keep getting an error about clip being not matched, or something like this:
I'm not sure. Perhaps tritical can comment?

[foxyshadis]

It's a special function of the tfm 2-pass file, it errors out if you don't use exactly the same filters before tfm as you did on the first pass. tdec has the same check. Colormatrix should have no effect, but tfm's trying to protect against random changes that render the stats useless.

To disable the check, all you have to do is remove the "crc=" section from the beginning of the stats files. (Leave the other info though!)

Colormatrix will still have an effect where it is now, though. It just won't be able to use hints to decide when it actually needs to be used, it'll just affect every frame (which is usually correct).

[jellysandwich]

Is it necessary to use colormatrix right after source, before ivtc?
(I just remebemer someone saying that filter won't do anything if it didn't come right after the source..)

When I was working on FLCL, I actually got small horizontal line artifacts in a few frames using Colormatrix before IVTC. Calling Colormatrix after IVTC fixed it.


js

[Wilbert]

Also, I just got a copy of Ferris Bueller. As it turns out, it's one of those rare DVDs that has changing colorimetry info. What's the recommended action for these types of DVDs? Leave it alone? Use colormatrix anyway?
A small request :) Could you upload a small vob (say 20 frames), where this changing occurs?

Does the change happen at the end or in the middle of the clip?

[rig_veda]

If an avisynth script outputs YV12 and I open it in VirtualDub, Vdub needs to make a YV12->RGB conversion for it's preview image. For this conversion, does it assume that the YV12 material is Rec.601?
In this case, if I process Rec.709 material in my AviSynth script, make a ColorMatrix() call along the line and feed it into Vdub, it would display correctly, right?

If I process Rec.709 material, make a ColorMatrix() call that converts it to Rec.601 and a ConvertToRGB() at the end and open this in Vdub, it would give the same result, right?

And if I process Rec.709 material and just do ConvertToRGB(Rec709) before handing it to Vdub, it would also be the same, yes?

The maximum differences i got from screenshots of vdub's display of these three cases was 3 (for RGB values in the 20-30 area), so i was wondering whether these are still due to rounding errors or whether my assumptions above are just wrong.. :D And, yes, which of the three method's display to trust most for proof viewing the output of a filter chain..?


Edit: I was using VirtualDubMod, not VirtualDub.

[Wilbert]

If an avisynth script outputs YV12 and I open it in VirtualDub, Vdub needs to make a YV12->RGB conversion for it's preview image. For this conversion, does it assume that the YV12 material is Rec.601?
Yes.

In this case, if I process Rec.709 material in my AviSynth script, make a ColorMatrix() call along the line and feed it into Vdub, it would display correctly, right?
Yes.

And if I process Rec.709 material and just do ConvertToRGB(Rec709) before handing it to Vdub, it would also be the same, yes?
Yes.

The maximum differences i got from screenshots of vdub's display of these three cases was 3 (for RGB values in the 20-30 area), so i was wondering whether these are still due to rounding errors or whether my assumptions above are just wrong..
For the last two cases, they are just rounding errors. The first one is wrong.

And, yes, which of the three method's display to trust most for proof viewing the output of a filter chain..?
It seems to me that ConvertToRGB(Rec709) would be the most accurate.
When using ColorMatrix and ConvertToRGB (VDub routines), you will make two rounding erros.

[unplugged]

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders, with the result that DivX/XviD clips or mpeg2 clips encoded by TMPGEnc/CCE using AviSynth or VirtualDub are displayed with slighty off colors (which looks like a small difference in brightness ). This can be checked by opening the mpeg2 stream directly in VDubMod. More info can be found in the readme.

This filter recalculates the yuv values assuming the coefficients which are used by AviSynth/VDub/DivX/XviD, with the consequence that your final encoding (mpeg2 or mpeg4) is displayed correctly.
I appreciate your effort, but isn't better to implement an option to ffdshow or XviD decoder to pass YUV data through hardware overlay using the same ITU-R BT standard used in the DVD Player software?

If PC DVD Players show movies with the "right" brighteness and they almost always use overlay card function as well why MPEG4 DirectShow decoders can't simply dial with the overlay subsystem by simply imparting the same YUV->RGB color conversion scheme?

When we see a movie in our PC, most of times we see it through overlay output method. AFAIK "overlay" involves direct video card conversion of YUY2 / YV12 data *directly* into analog RGB signals.
(that's the reason because overlay mode exists, this makes a lot of difference on (analog) CRT displays)

IMHO this is better than manipulate YV12 data and than involve some erratic pixel requantization. (16-235 --> 0-255)

[foxyshadis]

Because the pc-playback streams suck and don't include any form of flagging for this. Same problem, but much worse, with tv/pc yuv translation. A simple bitflag for tv/pc would give decoders & renderers a way to correctly decode everything, instead of essentially randomly picking one method and destroying video that doesn't fit its mold. In this case, adding the colorometry flag of mpeg2 to mp4/mkv, or mpeg4 asp/avc raw streams would be a better way, but afaik it isn't there at all, and good luck calling up ISO and asking them to throw it in.

[Heini011]

hi,

many thanks for your work on colormatrix! but i have 2 questions. regarding to this line from manual:

This filter will clamp (= round) your input video to CCIR-601 compliant values (these ranges are 16-235 for the luma component and 16-240 for the chroma component).

first: i don't understand why luma and chroma limitting is performed and why it is not possible to disable. if i encode for playback on a pc via xvid, i would like to keep the full pc-scale [0..255] of luma and chroma.

second: if i process an avs script within avisynth and save a frame as rgb-bitmap, i got the full pc-scale on luma and corrected color. uhm.. ?

greetings.

[Heini011]

Hi,

many thanks for the working on colormatrix. i have 2 questions regarding to the following line in the docu:

This filter will clamp (= round) your input video to CCIR-601 compliant values (these ranges are 16-235 for the luma component and 16-240 for the chroma component).

1. is that mean tv-scale luma/chroma clipping? i don't want such clipping if i encode material for pc playback!

2. if i open an avs script with colormatrix within virtualdub and save a frame as rgb bitmap, i got the full luma range [0,255] - exactly what i want to have, but in opposite to the docu ?

btw: HCEnc is using ITU-R BT.709 colormetry already.
so i have (not) to use it for hcenc in the opposite way than xvid, right ?

greetings.

[Wilbert]

1. is that mean tv-scale luma/chroma clipping?
Yes.

i don't want such clipping if i encode material for pc playback!
tv/pc-scale has not much to do with pc playback. I know some people claim otherwise, but that's a bit misleading. The point is that the footage is clipped in YUV-space (and when the clip is played back, and thus converted to RGB, the luma/chroma range is expanded again by most players), so it is only a problem if the range of your YUV clip is [0,255].

2. if i open an avs script with colormatrix within virtualdub and save a frame as rgb bitmap, i got the full luma range [0,255] - exactly what i want to have, but in opposite to the docu ?
See above.

btw: HCEnc is using ITU-R BT.709 colormetry already.
so i have (not) to use it for hcenc in the opposite way than xvid, right ?
Yes.

[Ginsonic]

Sorry, that I ask again, but is there any chance to get a special version, which does not clamp to 16-235 ?

Thanks !

[Didée]

Can't decide if that makes sense at all ... but if you desperately must have it, you can do like

a = last
b = a.ColorMatrix()
c = mt_lutxy(a,b, yexpr="x 16 < x 235 > | x y ?",
\ uexpr="x 16 < x 240 > | x y ?",
\ vexpr="x 16 < x 240 > | x y ?", U=3,V=3)

and have the wished result in the "c" clip.

[Ginsonic]

Many thanks Didée, I will try !

[canuckerfan]

Would ColorMatrix be necessary for a DVD9 to DVD5 conversion using CCE SP2?

[unskinnyboy]

Would ColorMatrix be necessary for a DVD9 to DVD5 conversion using CCE SP2?
Only if the MPEG-2 coefficients are different, which is rare. Use it with hints=true so that it is applied only if needed. Also, make sure you call ColorMatrix first before any other filter for the hints to work.

[Wilbert]

Only if the MPEG-2 coefficients are different, which is rare. Use it with hints=true so that it is applied only if needed. Also, make sure you call ColorMatrix first before any other filter for the hints to work.
Don't forget to add mode="Rec.601->Rec.709" in that case. CCE assumes Rec.709 coefficients.

[G_M_C]

Would ColorMatrix be necessary for a DVD9 to DVD5 conversion using CCE SP2?

Only if the MPEG-2 coefficients are different, which is rare. Use it with hints=true so that it is applied only if needed. Also, make sure you call ColorMatrix first before any other filter for the hints to work.

Don't forget to add mode="Rec.601->Rec.709" in that case. CCE assumes Rec.709 coefficients.


These three posts got me to thinking about the way DVD-RB opens its DVD files. This because DVD-RB uses all kinds of encoders, inclusing CCE and Procoder. To stream files to the encoders it generates an AviSynth script that ends with “ConvertToYUY2()”. At the moment it works like this:

Mpeg2Source (“<file>”, div.options)

<some further script options (resizing of instance)>

ConvertToYUY2()

Reading the above posts got me to thinking that something might go wrong there, because AviSynth assumes Rec.601 data when the “ConvertToYUY2()” is invoked (or another conversion), and most DVD’s i’ve checked use rec.709.

Wouldn’t it be wise to use colormatrix in DVD-RB, when opening files ? Like this:

Mpeg2Source (“<file>”, div.options, info=3)
Colormatrix (hints=true)

<from here script as usual>

ConvertToYUY2()

I’ve made a posting in the DVD-Rebuilder part of this forum with this idea. But I am no expert (to say the least), maybe you can shed some light on it ?

Posting is @ : http://forum.doom9.org/showthread.php?p=879894#post879894

[unskinnyboy]

Wouldn’t it be wise to use colormatrix in DVD-RB, when opening files ? Like this:

Mpeg2Source (“<file>”, div.options, info=3)
Colormatrix (hints=true)

<from here script as usual>

ConvertToYUY2()
It's better that you don't cross-post, because the answers can get scattered and discontinuous, but anyway..

Right way is :

Mpeg2Source (“<file>”, div.options, info=3)
Colormatrix (mode="Rec.601->Rec.709", hints=true)

It would be wise to do this by default for the most part, yes. But not all DVDs are Rec.709 and also there is an overhead in checking for hints every time. I think it should remain optional.

[Wilbert]

@G_M_C,

These coefficients are only used in a RGB<->YUV conversion, thus not in a YV12<->YUY2 conversion (which you are dealing with when using DVD-RB).

ConvertToYUY2(matrix="rec709") might be needed when requesting RGB (by using upConv=2) from MPEG2Source. I say "might" because i'm not sure what coefficients are used by MPEG2Source to convert to RGB24.

@Neuron2,

Are the coefficients autodetected and used when requesting RGB24 from MPEG2Source?

[primusmp]

Ok I finished reading the whole post (It`s quite large..) didn´t find answer to my problem... So I`ll be testing tomorrow...

I have PAL DV edited at premiere exported to huffyuv PAL AVI then loaded in avisyth and converted to NTSC ...

Script is being modified now but it used to start with ConverttoYU2() before smoothdeinterlace was applied....

In the end it was fed to CCE... watching tha0 .avs in video player (BS player media playe.. winap.. all teh same.) played the correct levels... The CCE Mpeg 2 file produced VERY distorted levels (No noticeable change using 0-255 or 16-235) Changed CCe to "Try to use RGB" and I get the correct levels (now 0-255 and 16-235 are different also) but Encoding is slower. Tried using ColorMatrix() with several different options... (i.e 6to7 and 7to6) and it doesn´t seem to affect the cce encoding. Colormatrix() line is placed rigth after the resize...

NOTES: when I say "No noticealbe change" it actually means "It`s 2 in the morning and I do not have time to actually pay attention to minor changes" and when it says "VERY distorted" I really mean VERY distorted like oversaturated and really darker...

I`ll send some pics tomorrow and if I find out what the f**k`s going on I`ll let you know.

Please apologize my english It`s not the best it can get but hey... Ive been working for the last 48 ours straight and Im really tired.

[tritical]

@Wilbert
With upConv=2, dgdecode does detect and use the coefficients indicated by the matrix_coefficients value to perform the conversion to rgb. (This is not the case for previous mpeg2decx.dlls that could deliver rgb).

[tritical]

[link removed, read down for a newer version], finally finshed the new version I mentioned back in January. Changes from v1.10:
+ Rewrote a large portion of the code
+ Added ability to convert between any of: Rec.709, FCC, Rec.601, and SMPTE 240M
+ Added source and dest parameters
+ Added scaling parameter (optional clipping and unscaled coefficients)
+ d2v option supports changing colorimetry info (with trim() and frame rearrangement restriction)
- fixed a problem with calculated luma values that were < 0 being set to 255 instead of 0

Main items are ColorMatrix can now convert between any of: Rec.709, FCC, Rec.601, and SMPTE 240M... everything in the mpeg2 specs. The pre/post clipping with limiter is optional, and there is also the option to use non-scaled coefficients if desired. The d2v option supports changing colorimetry (though there are still a few restrictions with using trim() and the like beforehand -- see the read me). The new syntax is:

ColorMatrix(clip, string "mode", int "source", int "dest", int "scaling", bool "interlaced", bool "hints", string "d2v", bool "debug", int "opt")

[G_M_C]

The downloadlink times-out for me, guess the whole world is getting an update :P

[Adub]

Shouldn't you update the title of the thread?
And maybe your website?

[tritical]

hm, I had updated my website but the university's servers had a little outage around then and I guess something screwy happened. Anyways, it's updated now. I can't edit the thread title since it isn't mine. I opted not to post this in a separate thread so that all the ColorMatrix related info would stay together.

[Alain2]

A few questions..
- When using colormatrix with the d2v parameter, do we still have to specify the interlace parameter ?

If so:
- If a PAL interlaced source, for a progressive one I suppose the interlace parameter should be set to false ?
But for a NTSC source, if the d2v was done with honor pulldown flags", should the interlaced parameter be true or false ? Same question for a d2v in forced film ?

I have these questions because the d2v analysed is showing fields, not frames I think, so I am not sure how the interlace parameter is used..

Thanks

[Wilbert]

A few questions..
- When using colormatrix with the d2v parameter, do we still have to specify the interlace parameter ?
Yes.

for a progressive one I suppose the interlace parameter should be set to false ?
Yes.

But for a NTSC source, if the d2v was done with honor pulldown flags", should the interlaced parameter be true or false ? Same question for a d2v in forced film ?
That's a good one. You need to make it progressive first by inverse telecining it. Note that the first frame is not altered by the ivtc process (the first few bytes are altered in the first frame when using hints in dgdecode), so you can use ColorMatrix directly after doing the inverse telecine.

[canuckerfan]

I tried the above suggestion, to use colormatrix after IVTC, but it says no hints detected in red text. It worked fine when I called it before IVTC. here's my script:

mpeg2source("E:\Video\Hindi Movies\Dil.Chahta.Hai.2001.DVD9-bj1988\temp\slow.d2v",idct=5,info=3)

Setmemorymax(512)

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

ColorMatrix(mode="Rec.601->Rec.709",hints=true)

DeSpot(pwidth=65,pheight=65,p1=35,p2=14,mthres=25)
RemoveDirt()

Tweak(sat=1.12,cont=1.12,bright=10.4)

FFT3DFilter(sigma=2.2,ow=48/2,oh=48/2)
Dehalo_alpha()
LimitedSharpenFaster(Smode=4,Lmode=2,overshoot=14,strength=200)

Crop(0,48,0,-48)
AddBorders(0,48,0,48)

ConvertToYUY2()

[Alain2]

Ok, so if I understand well:

- in case of a d2v in forced film, then I get a progressive clip out of mpeg2source, and thus set interlaced=false in colormatrix ?

- in case of a d2v in honor pulldown flags, then I have a telecined clip. You say it's better to ivtc first (with tfm+tdecimate for instance) before applying colormatrix, so in that case the d2v won't have the same number of frames than what is fed through colormatrix.
-- I can't use the d2v parameter then (so won't detect eventual changes of colorimetry within the clip) ?
-- If I don't ivtc first but place colormatrix with d2v=.. and interlaced=true immediately after mpeg2source, would that be a worse solution and why ?

[Wilbert]

- in case of a d2v in forced film, then I get a progressive clip out of mpeg2source, and thus set interlaced=false in colormatrix ?
Yes.

- in case of a d2v in honor pulldown flags, then I have a telecined clip. You say it's better to ivtc first (with tfm+tdecimate for instance) before applying colormatrix, so in that case the d2v won't have the same number of frames than what is fed through colormatrix.
Yes.

-- I can't use the d2v parameter then (so won't detect eventual changes of colorimetry within the clip) ?
I never thought about this, but i guess that means yes indeed.

-- If I don't ivtc first but place colormatrix with d2v=.. and interlaced=true immediately after mpeg2source, would that be a worse solution and why ?
Yes, a little bit worse. The chroma of the clip will be blurred more in that case (because it's being treated as interlaced).

@canuckerfan,

I tried the above suggestion, to use colormatrix after IVTC, but it says no hints detected in red text. It worked fine when I called it before IVTC. here's my script:
I'm not sure why, but perhaps tritical can explain. In any case, you can store the hints in a different clip:


Setmemorymax(512)

mpeg2source("E:\Video\Hindi Movies\Dil.Chahta.Hai.2001.DVD9-bj1988\temp\slow.d2v",idct=5,info=3)
savedHints = last
AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

MergeHints(hintClip=savedHints) # add hints back for use with ColorMatrix
ColorMatrix(mode="Rec.601->Rec.709",hints=true)

DeSpot(pwidth=65,pheight=65,p1=35,p2=14,mthres=25)
RemoveDirt()

Tweak(sat=1.12,cont=1.12,bright=10.4)

FFT3DFilter(sigma=2.2,ow=48/2,oh=48/2)
Dehalo_alpha()
LimitedSharpenFaster(Smode=4,Lmode=2,overshoot=14,strength=200)

Crop(0,48,0,-48)
AddBorders(0,48,0,48)

ConvertToYUY2()

[tritical]

-- I can't use the d2v parameter then (so won't detect eventual changes of colorimetry within the clip) ?
You can still use the d2v parameter as long as the colorimetry doesn't change at some point in the d2v. The same number of frames requirement is only enforced if colormatrix detects that the colorimetry does indeed change in the d2v file. That requirement is checked for during filter construction, so if you are able to load the script without an error then everything is fine. In the case that the colorimetry does change, colormatrix has to correctly match up input frames to frames in the d2v file to determine which frames need which conversion... thus the requirement that the number of frames be the same.

@canuckerfan
The hints wont survive tfm because by default it writes its own hints into the same bytes that dgdecode uses for hints. Unfortunately, the mergehints() workaround that Wilbert posted wont work correctly either since the frames in the saved clip wont match up with the frames after ivtc... which would be required to correctly handle changing colorimetry. If the colorimetry didn't change, then it would be fine, but in that case you could just use the d2v parameter.