Premiere Frameserves SD in Rec 709?

[koberulz]

Okay, burned Blu-Rays again. This time, set up my video camera on a stable surface, pulled up one of the internal white-balance patterns on my TV, white-balanced the camera, and took photos from each input.

005 is the cable box. This is the target.
006 is the first matrix conversion, from 601 to 709.
007 is the second matrix conversion, 709 to 601.

The latter two are very clearly a horrid shade of orange.

[poisondeathray]

Yeah...

I think everything is off, even your "target". I realize that it was taken from a camera, but much of the black detail is obscured

But in terms of red/orange, the "alcohol think again" logo on the ground beneath the basket , I think the "again" supposed to be more orange, not red. A quick search on google shows some variation, but mostly more "orange" than red. Also go to another frame, with the gatorade jug. Usually that is orange, not red.



So everything is off IMO, even your "goal" . I would use reference images of known colors and objects / logos as your guide. But it's up to you

[koberulz]

The lack of black detail is entirely to do with the exposure of the camera. I was erring on the side of not washing anything out. It seems to have tipped everything a bit towards red, too; the ATA logo is correct from the cable box on my TV screen.

The exact colors aren't critical, it's more about the comparison between the cable version and the versions I can come up with.

[koberulz]

Took another shot from the cable box.

[poisondeathray]

Difficult to judge those photos because of the exposure differences

I think what you might want is 2 colormatrix shifts, one to "undo" the frameserver , and other to "undo" the 709 import.

Can you upload 1 frame of the frameserver output as lagarith or ut ?

[koberulz]

I've got an mp4 file that hasn't been through television, or my crappy home capture methods. Only a couple of minutes of it though. Frame grabs from Premiere. So the MJPEG is coming in wrong, and the ffmpeg MP4 is coming in pretty much the same, except with more contrast for some reason. I tried setting fullrange to on in ffmpeg to see if that would help, and it didn't.

Also attached a sample from the frameserver. Opened the frameserved AVI in Vdub, cut it down, fast recompress to Lagarith YUY2.

[koberulz]

Ugh, more fun.

HD MP4 -> uncompressed UYVY AVI -> HD2SD -> 601 422 Ut -> Premiere...shifts red the other way, towards purple. Remains true if I output as uncompressed UYVY AVI from the HD2SD script.

[poisondeathray]

The screenshot taken from the source mp4 looks more correct, at least to me. The "think" is more yellow, the "again" is more orange both matching the known logo. The "red" jerseys don't look oversaturated, and definitely not orange

So basically you do the double shift mentioned earlier to "reverse" the problem incurred because of the frameserver and again from wrong import matrix. There is a slight yellow/green residual shift with that alone, perhaps from rounding, but it's easy to fix with something like coloryuv

e.g

AVISource("Frameserve.avi",audio=false)
colormatrix(mode="rec.601->rec.709",clamp=0, interlaced=true)
colormatrix(mode="rec.601->rec.709",clamp=0, interlaced=true)
coloryuv(off_u=0.5, off_v=0.5)

And the screenshot was taken by converting to RGB with 709


How did I know what values to use off the u , v offsets ? Well you can do it by "eyeballing", but you can use histogram("levels") or any number of various monitoring/scopes in avisynth too




I don't know what your ffmpeg mp4 is supposed to indicate. The ffmpeg -vf filter is because mjpeg decodes as full range yuvj422p (the "j" ) . In case you didn't notice, there were 2 versions of mp4's , one with the -vf filter, one without. The one with the filter should be full range data (same output from mjpeg decoder), but unflagged as full range. Thus it will look "illegal" on scopes, and over saturated. The point of doing it that way is so you have all the data so you can adjust it, instead of clipping or clamping. If you use the same command with MP4 input it won't work, unless it has been flagged full range. AVC will decode as standard range in ffmpeg unless it has a full range flag

[poisondeathray]

Ugh, more fun.

HD MP4 -> uncompressed UYVY AVI -> HD2SD -> 601 422 Ut -> Premiere...shifts red the other way, towards purple. Remains true if I output as uncompressed UYVY AVI from the HD2SD script.

You have to be careful with this ;

Is the UYVY a direct physical export (from AME) , ie. not afs set to "UYVY" ?

And how are you "loading" the UYVY ? (what source filter?) because there might be another filter inbetween that you don't know about

Assuming it was loaded correctly , HD2SD should be using colormatrix to convert 709 to 601 in YUV .

Premiere treats 601 YUV422 utvideo as RGB, and uses 601, at least in CC. Not so sure about CS6 so you should verify it's handling first before using UT

Can you upload 1 frame of the UYVY export ?

[koberulz]

Is there a way to fix it before it comes into Premiere/AE? I had a signal dropout at one point, and the idea is to use the source MP4 to cover the gap. So I need them to match...could I load the MJPEG in AviSynth and do the double color matrix that way?

I don't know what your ffmpeg mp4 is supposed to indicate.

Excess contrast.

The ffmpeg -vf filter is because mjpeg decodes as full range yuvj422p (the "j" )

...what? I actually meant to ask about the p in "422p" earlier but forgot, as I have no idea what that means. Nor do I know what the alternative to a j is...

In case you didn't notice, there were 2 versions of mp4's

...no, no I did not. This is news to me. In my defense, with timezones and me trying to cram as much of this in as I can around the rest of my schedule, I'm often on here at 5am. So I just remove the "-vf" and it fixes the excess contrast? Or do I have to remove the bit after that as well?

Is the UYVY a direct physical export (from AME) , ie. not afs set to "UYVY" ?

I selected "AVI (Uncompressed)" in the PP export dialog, then UYVY.

And how are you "loading" the UYVY ? (what source filter?)

AVISource("BSB_HD.avi")
hd2sd(interlaced=false, OutputColorSpace="YUY2", Widescreentype=1, VerticalBlur=0.25)

I don't think UT is the issue, given that an uncompressed UYVY output from the HD2SD script looks identical, color-wise. Unless I generated that wrong? Fast recompress, Compression->Uncompressed, Color Depth->UYVY for both in and out. Changed OutputColorspace to "UYVY" in HD2SD as well.

I tried pulling the uncompressed UYVY HD file into Premiere and it looks identical to the original, so the issue is somewhere along the HD2SD path.

I've attached the uncompressed UYVY that went into HD2SD, and the YUY2 UT that came out the first time.

[poisondeathray]

Is there a way to fix it before it comes into Premiere/AE? I had a signal dropout at one point, and the idea is to use the source MP4 to cover the gap. So I need them to match...could I load the MJPEG in AviSynth and do the double color matrix that way?

There should be, you just have to figure out what is going on. And there will be a fudge factor (it's not perfect - for whatever reason coloryuv was required to make it "closer" for the mjpeg import + frameserver). If it was only import and frameserver issue, purely 601/709 issues, you shouldn't need coloryuv - so something else is going on too, the residual shift seems more than just 8bit rounding errors.

If your other source MP4 looks correct, PP imports correctly as 709 - then that section should only require 709->601 for import format - again theoretically . You can try it out. But because of the fudging required for the mjpeg section I suspect it's probably not that simple. Probably some other mjpeg inconsistencies in the mix.

Also the choice of import makes a difference. You are seeing that in this thread how different formats give different interpretation results.

If you use PP filters and match it within PP, that should work too.

So IMO , if it's a continuous section (you're not editing/mixing bits and pieces) it's probably better to "fix" it afterwards, you want to minimize to as few operations as possible. It doesn't make sense to alter/filter it beforehand, only to filter it a few more times later to "reverse" what you filtered earlier. Those operations are not lossless - you lose quality and accuracy each time, and it's slower.

So you can apply different filters to different sections. You're going to be using avisynth to "fix" the mjpeg derived section anyways. Just apply a different "fix" to the MP4 derived section(s)

The ffmpeg -vf filter is because mjpeg decodes as full range yuvj422p (the "j" )

...what? I actually meant to ask about the p in "422p" earlier but forgot, as I have no idea what that means. Nor do I know what the alternative to a j is...

yuv422p means YUV, 4:2:2 chroma subsampling, planar.

The "j" is upon when decoding ; mjpeg is decoded as full range. The -vf filter stuff was to adjust the levels. Recall I said you can adjust it to however you want.

In case you didn't notice, there were 2 versions of mp4's

...no, no I did not. This is news to me. In my defense, with timezones and me trying to cram as much of this in as I can around the rest of my schedule, I'm often on here at 5am. So I just remove the "-vf" and it fixes the excess contrast? Or do I have to remove the bit after that as well?

I already explained this, and uploaded 2 samples. Just try it out .

When you have the -vf scale forcing in/out range to TV . The YUV data is full range, because that is how libavcodec decodes mjpeg data 0-255. But you didn't encode it full range. But the data is full range. Thus when you import into PP, it only "looks" to 16-235, so it looks "contrasty". Recall there was a lot of data outside of 0-100 IRE (or below 16, above 235) if you imported a format treated as YUV. If you imported a format treated as RGB, those data would be clipped

If you don't force ffmpeg handling (erase the filter) , it decodes mjpeg as full range (yuvj422p, the "j") , but auto clamps the data to 16-235, but in a "dumb" fashion. Thus less contrasty, but some sections will not be ideal (elevated black) . Just try it out.

Is the UYVY a direct physical export (from AME) , ie. not afs set to "UYVY" ?

I selected "AVI (Uncompressed)" in the PP export dialog, then UYVY.

And how are you "loading" the UYVY ? (what source filter?)

AVISource("BSB_HD.avi")
hd2sd(interlaced=false, OutputColorSpace="YUY2", Widescreentype=1, VerticalBlur=0.25)

I don't think UT is the issue, given that an uncompressed UYVY output from the HD2SD script looks identical, color-wise. Unless I generated that wrong? Fast recompress, Compression->Uncompressed, Color Depth->UYVY for both in and out. Changed OutputColorspace to "UYVY" in HD2SD as well.

I tried pulling the uncompressed UYVY HD file into Premiere and it looks identical to the original, so the issue is somewhere along the HD2SD path.

I've attached the uncompressed UYVY that went into HD2SD, and the YUY2 UT that came out the first time.

The SD version is shifted the wrong way when decoded and viewed correctly. (HD using 709, SD using 601 for viewing in RGB) . It's purely 601/709 issue.

But your UYVY was directly from the PP timeline, derived from mjpeg , correct ? So no frameserver ? Thus you should need 1 shift for the HD (to reverse the import, recall it was already incorrect upon import from the mjpeg decoding), and no shift for the SD, at least theoretically

Or sorry, was this the MP4 as source, UYVY direct export ? There is a discrepancy with the SD version. I have to ask why use the HD2SD script at all ? You'll get better results just resizing it and using colormatrix . This is a progressive resize, nothing tricky. But I get different (the expected) results with your same script. So it's probably some user error with vdub, or you have some other indavertent filters or rgb conversions going on) . 2 most common errors are not using video=>fast recompress (color space conversion) , and using ffmpeg input driver instead of AVI driver (if you have ffmpeg input driver for vdub, sometimes it gets selected and can mess up avs scripts)

It would have been nicer if you included the same or similar frame from before to compare instead of a "blob"




1) Open the avs script as you normally would in 32bit vdub, and check file=>file information in vdub, what does it say ?

2) In 32bit vdub, file=>open , select the UYVY directly (not through avs), and in the open video file dialog box, under files of type dropdown, select "AVIFile input driver" . Now go file=>file information , what does it say ?

3) In avisynth, what does this say?

AVISource("BSB_sample.avi")
info()

(Also, you're using ITU rules for AR interpretation. Notice in the "SD" version has the top and bottom pixels missing and vertically stretched. There are ways to "fix" that in the HD2SD script with the outputPAR parameter IIRC . Or maybe you want that AR interpretation ? ) . If you wanted full frame, no missing pixels, to override the ITU AR for PAL 16:9 , use outputPAR=1.4222 . Or just avoid HD2SD and do the simpler resize + colormatrix

[koberulz]

If your other source MP4 looks correct, PP imports correctly as 709 - then that section should only require 709->601 for import format

If it's currently correct, why would it need anything?

So IMO , if it's a continuous section (you're not editing/mixing bits and pieces) it's probably better to "fix" it afterwards, you want to minimize to as few operations as possible. It doesn't make sense to alter/filter it beforehand, only to filter it a few more times later to "reverse" what you filtered earlier.

Would I not simply fix the MJPEG first, and then it matches the MP4 and nothing further needs doing?

I have to ask why use the HD2SD script at all ? You'll get better results just resizing it and using colormatrix .

I was warned away from resizing in PP some years ago, and HD2SD was recommended. Although that was interlaced footage.

It would have been nicer if you included the same or similar frame from before to compare instead of a "blob"

It's different footage.

File information...what areas am I looking at? They're both using the Internal DIB decoder. One is YUY2, the other is UYVY, obviously.

The AVS script you posted...is RGB32. Could that be the problem?

Notice in the "SD" version has the top and bottom pixels missing and vertically stretched.

I don't see stretching, just cropping (small letterboxes if I drop the SD onto the HD sequence and scale to frame size), and I was under the impression that was how it was supposed to work?

Remember that EPS that was shifting towards green from yellow? Replaced it with the AI and it all looks fine in AE. Exported as a PNG sequence, brought it into Premiere and IT'S SHIFTED TOWARDS GREEN AGAIN. The same file in a different project shifted significantly less and in a different direction (it looks more saturated, not sure what the actual movement is) when its PNG sequence was imported into Premiere. This one probably is color management, seeing as the green-shifted comp was in an HD project and the other was in an SD project and I can't think of any other differences. AE is rendering right now though so I can't dig too much.

[poisondeathray]

If your other source MP4 looks correct, PP imports correctly as 709 - then that section should only require 709->601 for import format

If it's currently correct, why would it need anything?

Exactly! But you said you wanted to adjust the import to match. So it doesn't make sense to adjust the mp4 to match the mjpeg, only to undo it twice later + coloryuv . That was my point. But now it's clear that you were referring to the mjpeg, not the source mp4 . But if the "coverage" mp4 is just a small section, it might be ok to treat it that way, especially if you're having difficulting getting the mjpeg to match

So IMO , if it's a continuous section (you're not editing/mixing bits and pieces) it's probably better to "fix" it afterwards, you want to minimize to as few operations as possible. It doesn't make sense to alter/filter it beforehand, only to filter it a few more times later to "reverse" what you filtered earlier.

Would I not simply fix the MJPEG first, and then it matches the MP4 and nothing further needs doing?

You can try that too. The other ffmpeg without -vf filter version. But I bet the black level is different because it's a "dumb" clamp as explained earlier

But you'd still have to fix the frameserver step if using that

I have to ask why use the HD2SD script at all ? You'll get better results just resizing it and using colormatrix .

I was warned away from resizing in PP some years ago, and HD2SD was recommended. Although that was interlaced footage.

yes, definitely avoid interlaced resizing in NLE's . But that "source" MP4 was progressive

It would have been nicer if you included the same or similar frame from before to compare instead of a "blob"

It's different footage.

It is , but you should have some sections that are remotely similar shouldn't you ?

File information...what areas am I looking at? They're both using the Internal DIB decoder. One is YUY2, the other is UYVY, obviously.

I'm looking for 3rd party decoders for your AVI 32bit VFW pathway - they should be identified if you had them

The AVS script you posted...is RGB32. Could that be the problem?

The AVISource and Info() ?

Yes, that is likely the problem . You're not decoding it correctly (or rather you inadvertently converted to RGB , as I guessed earlier). Your AVISource VFW decoder for UYVY is probably auto inserting a RGB filter in between . To avoid all that inconsistency an alternative is to use ffms2 or lsmash (uh-oh here we go again... ) . Another free alternative for VFW is "DT Codecs" , but it can be a hassle finding the right version - but that would make AVISource work for you (check with info() of course)

Notice in the "SD" version has the top and bottom pixels missing and vertically stretched.

I don't see stretching, just cropping (small letterboxes if I drop the SD onto the HD sequence and scale to frame size), and I was under the impression that was how it was supposed to work?

It's a different AR interpretation, that's all. PP uses ITU AR interpretation , most NLE's do . But some people don't like losing pixels or active image area. Just be aware of what's happening.

Remember that EPS that was shifting towards green from yellow? Replaced it with the AI and it all looks fine in AE. Exported as a PNG sequence, brought it into Premiere and IT'S SHIFTED TOWARDS GREEN AGAIN. The same file in a different project shifted significantly less and in a different direction (it looks more saturated, not sure what the actual movement is) when its PNG sequence was imported into Premiere. This one probably is color management, seeing as the green-shifted comp was in an HD project and the other was in an SD project and I can't think of any other differences. AE is rendering right now though so I can't dig too much.

lots of fun

[koberulz]

You can try that too. The other ffmpeg without -vf filter version. But I bet the black level is different because it's a "dumb" clamp as explained earlier

The ffmpeg I was using doesn't color shift at all, it only expands the range. Would the other ffmpeg help with the colors at all?

It is , but you should have some sections that are remotely similar shouldn't you ?

Not even slightly.

The AVISource and Info() ?

Yes, that is likely the problem . You're not decoding it correctly (or rather you inadvertently converted to RGB , as I guessed earlier). Your AVISource VFW decoder for UYVY is probably auto inserting a RGB filter in between .

*bangs head on desk*

WHY DO YOU HATE ME, INFERNAL MACHINE!

Not that I know what much of that actually means...is there a way to locate this encoder and change what it's doing or something?

To avoid all that inconsistency an alternative is to use ffms2 or lsmash (uh-oh here we go again... )

So just never use AVISource() for anything? I managed to find both ffms2 and lsmash on the AviSynth wiki, finally! Is there any reason to use one or the other?

It's a different AR interpretation, that's all. PP uses ITU AR interpretation , most NLE's do . But some people don't like losing pixels or active image area. Just be aware of what's happening.

I'm aware it's cropping, yes. I was led to believe that was proper (and it's HD2SD's default behaviour, although it is alterable).

lots of fun

😒

[poisondeathray]

You can try that too. The other ffmpeg without -vf filter version. But I bet the black level is different because it's a "dumb" clamp as explained earlier

The ffmpeg I was using doesn't color shift at all, it only expands the range. Would the other ffmpeg help with the colors at all?

That example commandline only used in and out range . But there are in_color_matrix, out_color_matrix arguments too with -vf scale. ffmpeg has many other filters as well, including a separate color matrix. There is even a filter for custom LUTs . So it's entirely possible you could get it working . But when you fed it through the frameserver, there were 2 shifts + coloryuv required to "fix" it, so I'll hazard to guess it's not going to be super simple, you're going to have to try a few things out

https://ffmpeg.org/ffmpeg-filters.html#scale-1
https://ffmpeg.org/ffmpeg-filters.html

The AVISource and Info() ?

Yes, that is likely the problem . You're not decoding it correctly (or rather you inadvertently converted to RGB , as I guessed earlier). Your AVISource VFW decoder for UYVY is probably auto inserting a RGB filter in between .

*bangs head on desk*

WHY DO YOU HATE ME, INFERNAL MACHINE!

Not that I know what much of that actually means...is there a way to locate this encoder and change what it's doing or something?

When you load an AVI directly in vdub (with the AVI driver) , file=>file information will list the VFW decoder used. AVISource() in 32bit avisynth will usually use that same 32bit VFW decoder indicated by vdub . For example if DT codecs or some other 3rd party codec was being used, that would likely be listed in file=>file information. Same with 64bit vdub, for x64. So I know some types of AVI imported in to AE and PP use the system x64 VFW decoder. That's at least one of the reasons why we were getting different results for the mjpeg AVI for example. There are utilities to manage codecs such as vcswap for VFW, graphstudio for directshow, a few others . It's simpler/easier for most people to use ffms2 or lsmash. Less room for error or inconsistency.

To avoid all that inconsistency an alternative is to use ffms2 or lsmash (uh-oh here we go again... )

So just never use AVISource() for anything? I managed to find both ffms2 and lsmash on the AviSynth wiki, finally! Is there any reason to use one or the other?

If you have your VFW system sorted out, I still prefer AVISource() for AVI formats. No indexing is a big reason (indexing takes time , adds index clutter)

They are both good. But in general, lsmash is preferred for MP4/MOV because it doesn't need to index with LSMASHVideoSource() . LWLibavVideoSource() is used for other non MP4, non MOV formats . There will be times when sometimes ffms2 works better, or maybe you need to make use of some auxiliary functions that one has but other doesn't. Sometimes a specific build version wasn't compiled with support for a specific format (e.g. some might not support HEVC) . So it's nice to have plan B, plan C, and so forth in case you need to.

[koberulz]

But when you fed it through the frameserver, there were 2 shifts + coloryuv required to "fix" it

Is it coming out of the frameserver any worse than it's going in, though?

Okay, so after playing around with the sample clip...scaling from 601 to 709 and full to TV seems to be pretty damn good. Will have to grab a clip that matches the source MP4 and check, but the contrast is visually exact, with minute scope changes, and the reds are red. Would also be nice if I could fix the environment variable thing; I've just got my sample stuck in the bin folder at the moment. It's a refreshing metaphor for this experience, but it also adds difficulty.

When you load an AVI directly in vdub (with the AVI driver) , file=>file information will list the VFW decoder used.

As previously mentioned, it says 'internal DIB decoder' for the UYVY. It uses Ut for the Ut file.

[koberulz]

Well...it's bloody close, but it's still slightly off.

[poisondeathray]

Is it coming out of the frameserver any worse than it's going in, though?

Yes, and any time you use filters like, especially in 8bit, you lose accuracy . The more manipulations, the worse it gets. Had frameserver not caused a shift, that would be 2 fewer quality hits. The loss might be negligible , but it's still avoidable quality loss

Okay, so after playing around with the sample clip...scaling from 601 to 709 and full to TV seems to be pretty damn good.

So was that the mjpeg sample AVI ? And what is the screenshot, in PP, or frameserver, or how was the RGB conversion done ?

If you're just trying to match within PP, you should be able to get it closer with PP filters

Would also be nice if I could fix the environment variable thing; I've just got my sample stuck in the bin folder at the moment. It's a refreshing metaphor for this experience, but it also adds difficulty.

I can't offer more suggestions without seeing the console log and what it says exactly. It should tell you what is wrong.

There are many guides on ffmpeg and setting up environment variables, try resetting the path

When you load an AVI directly in vdub (with the AVI driver) , file=>file information will list the VFW decoder used.

As previously mentioned, it says 'internal DIB decoder' for the UYVY. It uses Ut for the Ut file.

Yes, that means vdub's internal DIB decoder. Avisynth doesn't use vdub's internal decoder. It means you have no VFW decoder for that, so it probably inserted some colorspace filter hence your problems

[poisondeathray]

So that's the same yellow green shift I mentioned earlier that coloryuv addressed; another way is smoothtweak(hue1=1, hue2=1) . Both give same results, both shift U,V to the right towards blue/red

To do that in ffmpeg, one way is to apply a lut to u,v planes

-vf lutyuv="u=val+1:v=val+1"

If you had a linear chain of filters in ffmpeg, just separate them by comma



Illustration (these are in jpg, to save bandwitdh), you can flip back and forth and notice the U,V shift

src


ffmpeg


ffmpeg + avs (either coloryuv or smoothtweak as described above)


ffmpeg + lut

[jagabo]

When you load an AVI directly in vdub (with the AVI driver) , file=>file information will list the VFW decoder used.

As previously mentioned, it says 'internal DIB decoder' for the UYVY. It uses Ut for the Ut file.

AviSynth doesn't support UYVY. So it has to find a filter that converts UYVY into something it does support. On my system it's one of UtVideo's filters * -- which converts to RGB32. Probably the same on yours. If you have ffdshow installed, you can use its "raw video" codec to convert UYVY to YUY2.


* By the way, I determined this with GraphStudio.

[koberulz]

If you had a linear chain of filters in ffmpeg, just separate them by comma

I don't know what a 'linear chain of filters' is.

ffmpeg + lut

That appears to just be the AviSynth version again.

If you have ffdshow installed, you can use its "raw video" codec to convert UYVY to YUY2.

How do I do that? I tried going to the video decoder options and setting the Raw Video to "UYVY", but that still resulted in an RGB32 AVS file.

I tried installing LSMASH, but there's already an LSMASHSource.dll in my plugins folder. Yet when I try to use LSMASH, I get a 'no such function' error.

With ffmpeg, I can open a command prompt anywhere and 'ffmpeg -version' works. But the batch command only works if it's in the bin folder, whether I run the batch or type the same ffmpeg command in manually.

[koberulz]

ffms2...at least opens, I guess. Output source frame to clipboard in Vdub using FFVideoSource(). If I use FFmpegSource2(), I get an error saying ffvideosource does not have an argument "pp" in FFMS2.avsi.

[poisondeathray]

If you had a linear chain of filters in ffmpeg, just separate them by comma

I don't know what a 'linear chain of filters' is.

ffmpeg + lut

That appears to just be the AviSynth version again.

That's the idea wasn't it ? Instead of using avisynth you batch ffmpeg to convert your files upon import ? I'm not saying you have to use those values, adjust them to however you like . Or, you can just "fix" everything with avisynth after near the end as shown earlier, whatever you feel like

A linear filter chain is like filter A, filter B, filter C .... in sequential order. So if you used -vf filter with in/out color matrix to get the results of "ffmpeg" screenshot in PP, you could use -vf lut to shift the colors similar to coloryuv or smoothtweak without having to go to avisynth . A simple filter chain doesn't require -filter_complex graph in ffmpeg, they are just applied one after the other in sequential order when separated by a comma. Colons separate arguments within a filter, commas separate separate filters

-vf filterA,filterB,filterC

ffms2...at least opens, I guess.

hmm ffms2 opens the UYVY "BSB_sample.avi" for me as YV16, which is planar 4:2:2 - Which is correct in avisynth . YV16, YUY2, UYVY , 2vuy, etc... are all YUV422 . They are just stored slightly differently.

which avisynth version are you using?
What ffms2 version are you using ?

[koberulz]

That's the idea wasn't it ?

I meant that your screenshot appears to be the same file.

AviSynth 2.60, ffms2 2.23.1. I had an old ffms2 already installed, and copied the dlls but not the avsi. Copied that over and now FFmpegSource2() results in the same half-correct, half-green result I got with FFVideoSource().

I tried the simple script with only FFMpegSource2() and info() and it shows as YV16 and looks fine. But if I add the HD2SD line, I get the half-green output.

Any idea why LSMASH won't open?

[poisondeathray]

hd2sd probably doesn't support planar 422 or additional avisynth 2.6 colorspaces - it's an ancient script. Convert to YUY2 ( don't forget interlaced true/false) , or don't even bother with hd2sd

for lsmash , use the msvc version , 32bit if you're using 32bit avisynth

[koberulz]

The first frame is still green when I load it in VDub, but if I scrub past it and scrub back it's normal. Is that worth worrying about?

Grabbed the msvc version, and there's no error anymore but Vdub completely locks up when I try to open the AVS using LwLibavVideoSource(), and I get a fatal error about being unable to read the source file if I use LSMASHVideoSource().

The color shift in the EPS file appears isolated to PP, the PNGs in the sequence are fine in PS or Photo Viewer. The HD2SD avi file matches Premiere but the DVD-compliant m2v seems to match AE.

[poisondeathray]

Yes green frame is a problem . Do you get it without hd2sd ?

Might be threading issue. Try threads=1 .

FFVideoSource("video.avi", threads=1)

for lsmash error, you sometimes get something like that when you have incompatible plugins autoloading in the avisynth plugins folder . Might be some of the ancient ones that hd2sd relies on. Some people manually load plugins in their scripts (plugins in subfolders, LoadPlugin(....) ) so you don't get those sorts of issues with old plugins

But LWLibavVideoSource("BSB_sample.avi") works for me . I think I'm using an older version of the dll r901

[koberulz]

Yes, the green frame occurs without HD2SD. threads=1 changed nothing.

[poisondeathray]

With the script loaded in vdub, what does file=>file information say?

"green frame" issues shouldn't occur at all with I-frame formats, even if it resolves when you scrub back/forth

[koberulz]

720x576 25fps, 1644 frames (1:05.76), Internal DIB decoder (YUY2), 1644 key frames, all key frame sizes are 829440 (1331640K), no delta frames, data rate 165888 kbps, 0% overhead.