TheDiveO wrote:

Inapickle wrote: I for one would like to get more information from different sources to maybe get a better understanding in the long run.

Well yes, I agree, that was the idea behind starting this thread as I saw it, so that people could weigh in with their experiences with different video sources and maybe reach consensus about how and when the "Full Luma Range" applies and the implications of using it.

That's why I'd been trying to find a way to generate that AVISynth YUV Histogram in Linux, to provide some common point of reference when comparing luma ranges. But so far, without success. Like I said, trying to run AVISynth and VirtualDub in Wine I can load the script and pull-up the first frame, but I just can't get it to seek to a particular frame without freezing or corrupting. Tried converting the KDenLive renders to raw YV12 or YUV avi files, but no joy there either. Same thing if I load the avi files directly into VirtualDub, so the issue must be with VDub itself. I'd like to get that working as I'd have other uses for it also. I guess I could have a look at VapourSynth, but that's another coding language to get my head around and I ain't no programmer. So, I'm wondering if there is any other tool in Linux that can produce equivalent raw YUV levels information?

I've still some tests to run with the AW120 clips to reach firm conclusions. I'm a bit strapped for time over the next few days, but will try before the end of the week.

Cheers.

TheDiveO wrote:The Wayback Machine will help: http://web.archive.org/web/201404021316 ... ange-flag/

Oh brilliant ! Thanks a lot for that.

Edit: Note, in that article he's using the 'Classic' waveform (YUV luma) mode of the AVISynth Histogram filter:

http://avisynth.nl/index.php/Histogram

Very useful tool, if I could only get it working.

agree with TheDiveO,

please dont let people discourage you, this is for me the the most interesting threads around here..

and thank you so much for your offer to check with sony a7s files. I ll check if i have some snippets that are shot with no picture profile, if not i ll just shoot a test tomorrow and will send it over, I m very curious, like there s no real information anywhere to find.

@kalimerox,

I got your PM with the clip, and replied, but it looks like my replies (two of them) are still sitting in the OutBox, not in Sent Messages. Not sure why? Did you receive them?

Edit: Ah OK - found "You'll see it in Outbox until the receiver has read the PM"

@TheDiveO,

I am getting around to finishing the tests with the AW120 0-255 luma range clips. Thought I was about done but that article about "Full Luma Range" you gave a link for brought to light (pardon the pun) some things that warranted further testing.

Thinking about a comment I made earlier:

Inapickle wrote:

TheDiveO wrote:

Inapickle wrote:http://everything.explained.today/Rec._709/

Thank you for the reference, an interesting read. Still unsure whether the developers at the various cam manufacturers really got everything correctly implemented...

Just to answer that point. A popular opinion is that camcorder engineers, from all of the major companies, exploited allowances in the Rec.601 and then Rec.709 standards for 8-bit encoding in the 236-254 range to accommodate filter overshoot, transient signals and specular highlights, and used this as a way of gaining a little extra dynamic range and headroom for grading i.e. bent the rules, so to speak. To what extent that's true or simply that full scale YV12 decoding co-incidentally reveals these "super-white" excursions, I'm not sure.

Whilst I'm not generally in favor of "compressing" luma ranges, as a rule, there are some special situations where I might consider it - namely if it reveals/brings down highlight detail that may be lurking in the "super-white" range in a way that 'saves' or significantly improves a particular shot/scene. Was just going through some footage - here's an example where I might:

Original 16-255 range:

http://i.imgur.com/EJIx7xy.jpg

Clipped/Clamped to 16-235:

http://i.imgur.com/BttsUUq.jpg

Down-scaled/Compressed to 16-235:

http://i.imgur.com/t3zVVDk.jpg

Notice, whether "clamped" or "compressed" there's usually a little over-shoot at the limits - "soft roll-off"

OK, after much a to-do, here is a summary of my findings testing a 1080/30p.mov clip from NikonAW120 “all weather camera”. The quality of video is not that great, but it records in full scale 0-255 YV12 h264 (15.4 Mbps, AVC Baseline@ L4.1) and so suffices for these tests.

Again, this is quite a read.

The test set-up was basically the same as that described in the first post. I’ll cover the findings in three parts:

Part 1.Tests with native 1080/30p.mov clip

Here is the YUV Histogram of the original clip:

Frameshot: http://i.imgur.com/t10JqUY.jpg

Arguably, the luma range doesn't quite extend down to 0; I don't know if it is the same with other cameras that record "Full range" video.

As in the earlier tests, the clip was loaded on the KDenLive timeline and processed in three different ways - no effect applied (pass-through), Distortion (Mirror) effect applied and a light Luma Curve effect applied. Separate projects for each. All rendered out to Matroska Lossless.mkv and (Intra) h264.mp4

All of the renders had the same YUV Histogram profile. The luma had been compressed (down-scaled) to 16-235:

Frameshot: http://i.imgur.com/dgei2fb.jpg

The tests were then repeated this time applying the “Full Luma Range” option in the clip properties. Again, all of the renders showed a compressed 16-235 luma range.

Frameshot: http://i.imgur.com/nPS9BRt.jpg

Part 2. Tests with transcodes

As in the earlier tests, the native clip was encoded to Matroska.mkv and DNxHD.mov (220Mbps) using the respective transcode presets. Here's what the YUV Histogram of the transcodes looks like - compressed to 16-235, just like the renders from the native clip tests:

Frameshot: http://i.imgur.com/ciGskAr.jpg

The transcodes were then processed on the timeline in the same manner as the native clip. All of the renders from the tests performed with the “Full Luma Range” set to OFF, showed the same compression to 16-235. In other words the already compressed 16-235 luma range of the transcodes was maintained, irrespective of whether an effect was applied or not.

Frameshot: http://i.imgur.com/G4wc5ry.jpg

Applying the “Full Luma Range” flag to the transcodes however had the effect of further compressing the luma range to around 32-220. Which was perhaps not surprising, given that the flag was being applied to a source that was no longer full scale 0-255.

Frameshot: http://i.imgur.com/lnh9KNZ.jpg

Maybe a good point to pause there and reflect (and/or make a cup of coffee)

So, using the native source clip, all of the renders were compressed to 16-235, but inspecting the luma profiles more closely reveals some differences. All of the luma profiles of the renders from the native clip and transcode tests performed with the “Full Luma Range” flag OFF exhibit “spiking”. Those spikes look to me like the by-products of spline down-scaling and had this been a greyscale gradient instead of an actual clip they would likely be seen as “banding”. Might go on to demonstrate that further.

And this is one of the reasons why I try to avoid re-scaling of YUV sources whenever possible. When I do re-scale I prefer to use an AVISynth filter (SmoothLevels from Smooth Adjust plugin pack) which utilizes a smoothing and dithering algorithm precisely to avoid banding:

http://forum.doom9.org/archive/index.php/t-154971.html

I know, Windows again but AVISynth is where I “cut my teeth” and I can’t deny my roots. Plus, this can be done in linux via Wine...when it works. Compare the YUV histogram produced when used to down scale the clip luma to 16-235.

Frameshot: http://i.imgur.com/nhKs5cf.jpg

A lot smoother, no? But I digress.

OK, now look again at the histogram of the render from the native clip tests performed with the “Full Luma Range” flag applied. Similar profile overall, but noticeably less “spiking” Why?

Well again, here’s my best stab at it, right or wrong. As I speculated in the first HF-G10 tests, what we might be seeing here is the net result of initial conversion of full scale 0-255 luma YV12 to RGB using modified “PC.709” coefficients and then conversion back to YUV with normal Rec709 co-efficients to produce the 16-235 luma range. In effect, “round-about compression” rather than direct re-scaling. This would explain why applying an effect, like RGB curves, doesn’t change that. Seems reasonable? And indeed I can replicate it by doing just that in AVISynth:

Frameshot: http://i.imgur.com/bMrp8Qg.jpg

But still, why is there more “spiking” when the “Full Luma Range” flag is not applied ? Well, the first thing to note is that this native AW120 clip is clearly handled in a different way to the raw 16-255 AVCHD.mts clip from my Canon HF-G10. In that case, with the “Full Range Flag” OFF, there was “pass-through” of the 16-255 luma , except where an effect that called for RGB (like RGB curves) was applied, in which case the luma was clamped (not compressed) to 16-235. In these tests with the native AW120 clip, there was no pass-through, all of the renders were compressed to 16-235 irrespective of whether an effect was applied. So what’s going on? If there was uniform conversion to RGB and back to YUV using standard Rec709 coefficients that definitely would result in “clamping” with “crushed” values at both 16 and 235 boundaries, like this (using AVISynth):

Frameshot: http://i.imgur.com/cYryPLl.jpg

Well yes, there were “crushed” whites at the 235 boundary, as there were at 255 in the original clip histogram as a result of the blown out super-whites shining through the window - so compression just shifts those down. But no clamping at the 16 boundary. So what then? Only other possibility I can think of is that the luma is first being scaled down to 16-235 before the rec709 conversion is applied, which in turn would require that the full scale luma of the native clip is somehow discerned. That’s literally a stab in the dark; and if someone with insight can explain what is really going on there, I would more than happy to be put right.

Regardless of the explanation, these tests left me wondering if there was any prospect for processing of full range luma sources other than by compression to 16-235? Well there is, but it appears to be at a price.

Part 3. Tests with transcodes that preserve Full Scale flagging Edited for readability after further testing

The article that TheDiveO kindly provided a fresh link to prompted me to try something else:

http://web.archive.org/web/201404021316 ... ange-flag/

As stated in the article, whilst FFMPEG makes provision for flagging "full scale" YUV by virtue of the pixel_format designations yuvj422p and yuvj420p, some formats including DNxHD and HuffYuv do not support these designations and auto-revert to pix_format yuv422p during encoding resulting in compressed 16-235 YUV. In my tests I found this still to be the case, and also with UTVideo encoded with the yuvj422p and yuvj420p pixel formats.

However, on further inquiry I discovered that when the native AW120 1080/30p.mov clips were transcoded to (uncompressed) RawYV12 and RawYUY2 with the yuvj420p and yuvj422p designations, the 0-255 YUV scaling is preserved, as confirmed by the respective YUV Histograms. As also were lossless YUY2 and YV12 transcodes made with the vfw version of the UTVideo codec.

Accordingly I went on process these transcodes in KDenLive in the same manner as above. Examining the YUV Histograms of the renders, all preserved the full 0-255 luma range when no effect had been applied (pass-through), or when the Distort: Mirror effect was applied:

Frameshot: http://i.imgur.com/TVvA0ws.jpg

....but all were “clamped” (not compressed) to 16-235 when the (RGB) Luma Curve effect was applied.

Frameshot: http://i.imgur.com/Dr4r8bl.jpg

and this ONLY happened with KDenLive “Full Luma Range” flag set to OFF. When set to ON, the resulting renders returned to the compressed 16-235 luma pattern.

So, in effect, these transcodes behaved in a similar manner to the native HF-G10.mts (16-235) clips in the first series of tests, where the original luma scale was preserved, except where an “RGB effect” was applied, in which case the luma was clamped to 16-235.

So is that desirable? Well yes, if the intent is merely to pass-thru or apply basic trimming/cut editing. And yes if the intent is to apply “RGB” effects to the entire clip or series of clips on the timeline and preserve the original gradient, at the expense of clamping to 16-235. The "price" (I referred to above) however is having to work with very large uncompressed YUV files or else encoding compressed, lossless files with the vfw UTVideo codec (via AVISynth/VirtualDub) in Windows or feasibly (but untested) in Wine. For me UTVideo is the better option at this time.

On further testing I found that FFMPEG encoded x264 (libx264) does also now support the pix_format yuvj420p flag. That said, x264 wouldn't be my choice for an intermediate format, so I'll probably just stick with vfw UTVideo as and when the needs require.

As for the "Full Range Luma" option in KDenLive. I can find no case for applying it in the processing of video recordings from my Canon HF-G10 and Nikon AW120. Sometimes it may be desirable to process full-scale YUV compressed to 16-235 scale (preservation of detail in the 'super-white' range, for example), but I would want to be able to scale back to full range YUV. And since it is not clear (to me) exactly how the compression is carried out (although I have a pretty good idea) I would prefer to do that outside of KDenLive using techniques that I have greater understanding of and know how they behave. Sometimes also pre-conversion to RGB may be a desirable option, especially in situations where I might want use KDenLive as a "stage" in a grading workflow; which in turn brings further consideration of the options for rendering out to RGB. As far as I can see the only available pre-set there would be PNG as an Image Sequence. Do-able I guess but would mean a further round of frame-serving to reconstruct the video stream. I'll maybe post a separate inquiry about that.

OK, that's me done. Hope this information, although rather long winded, is in some way useful.

P.S. - As for the methodology I used for generating the YUV Histograms. I'm afraid I still can't get AVISynth/VirtualDub to work properly in Wine. If anyone has, the AVISynth script is pretty straightforward. Best all round plugin for loading the different KDenLive render formats is probably L-Smash Source:
http://avisynth.nl/index.php/LSMASHSource

And then after loading the source:

Code: Select all

ConverttoYV12(interlaced=false) # for non-planar sources; the Histogram "levels" and "classic" modes require planar input.  Interlaced = true, for interlaced sources.
Spline36Resize(1280,720) # purely to accommodate the Histogram alongside the video preview in VirtualDub.
Histogram(mode="levels") # for the YUV Histogram, or mode="classic" for the luma WFM if preferred. 

I've also gone on to test the "full scale" AW120 clip transcoded to HuffYuv (YV12 and YUY2) and FFV1 (YV12 and YUY2) with the vfw FFDshow encoder. The transcodes behaved in KDenLive exactly the same as the vfw UTVideo transcodes and the FFMPEG-encoded RawYU2 and RawYV12 transcodes to which the yuvj422p and yuvj420p pixel format flags had been successfully applied. That is, the 0-255 YUV profile is preserved on pass-through but clamped to 16-235 when an "RGB effect" like Luma Curve is applied. What I don't understand is why a vfw encoder like vfw-FFDShow, which uses ffmpeg (libavcodec), has no problem encoding these compressed formats with full scale YUV, but there is still this incompatibility issue when the yuvj420p and yuvj422p pix_format flags are applied in CLI ffmpeg ?

As regards my initial interpretation of why processing of the native AW120 clip in KDenLive results in uniform compression to 16-235, irrespective of whether an effect is applied or not, and irrespective of whether the "Full Luma Range" flag is selected or not:

Inapickle wrote:...Well again, here’s my best stab at it, right or wrong. As I speculated in the first HF-G10 tests, what we might be seeing here is the net result of initial conversion of full scale 0-255 luma YV12 to RGB using modified “PC.709” coefficients and then conversion back to YUV with normal Rec709 co-efficients to produce the 16-235 luma range. In effect, “round-about compression” rather than direct re-scaling. This would explain why applying an effect, like RGB curves, doesn’t change that. Seems reasonable? And indeed I can replicate it by doing just that in AVISynth:
Frameshot: http://i.imgur.com/bMrp8Qg.jpg

To try and gain further insight into what happens I've done some more tests comparing the render profiles with (AVISynth) simulations of all the possible permutations. Tools were applied to detect subtle differences in the luma and chroma profiles and also map "out of gamut" (invalid RGB) values when Rec709 or pc.709 coefficients are applied. Based on the results, I'm thinking now that the 0-255 luma is first scaled (compressed) to 16-235, and that Rec709 conversion to RGB and then back to 16-235 YUV only occurs when an effect "calls" for RGB. If that is the case it would imply that the KDenLive MLT 'engine' is itself operating in YUV color space, logically YUV 4:4:4, which I suspect, as this readily explains the "pass through" phenomena; except that in this case it is "pass-through" of down-scaled 16-235 YUV. Purely conjecture again, but it's the only way I can reconcile the behavior.

Again, I would find it helpful if someone with greater insight into the workings of MLT could confirm or refute these pontifications, or point to documentation that clearly explains it, or at least provides more clues.

Crikey I've written a lot haven't I. Do I get points for longest posts ever ?

As far as my very limited understanding of the MLT engine (framework) goes, it is format agnostic without preference for YUVA or RGBA. Each frames wandering through MLT has its format attached. Now, effects and transitions each have their requirement of format. MLT then converts frames as required by the particular effects and transitions.

If your source is YUV, its frames will be YUVA. If your souce is RGB then its frames should be RGBA. If your sink is RGB it will happily take RGBA. If you feed your sink YUVA, then a final conversation applies.

To my limited understanding that's the reason why MLT can pass through either YUV or RGB untouched, depending on what effects and transitions are present. Most transitions are RGB, but it might be a wild guess.

Thanks for that insight TheDiveO, which of course makes sense, and it would make no sense for an "RGB frame" to be needlessly converted to YUV only to be converted back to RGB to apply a particular effect.

Just thinking this through - taking the case of the processed native AW120 clip then, where all frames in the YUV renders were compressed to 16-235 irrespective of whether an effect was applied or not, it would still make sense that that down scale of the luma to 16-235 is applied to all frames, as a precedent, otherwise it's back to my first notion that modified (pc.709) matrix coefficients are applied when the effect calls for RGB, which I think now is not the case. And if Rec709 coefficients were applied to the full-scale YUV, that would surely result in "clamping" to 16-235, not compression. I guess it's also possible that the luma compression is applied at final rendering, but if that were the case, it would again require that modified "pc.709" are applied to those frames to which an "RGB requiring effect" is applied, as Rec709 coefficients would result in clamping, not compression. Furthermore, taking an effect like (RGB) Curves or Bezier Curves, where there is provision for selecting the Color Matrix, there is no "pc.709" option there, only Rec709. So, my feeling is that the luma compression, when it occurs, is taking place before any conversion to RGB.

And applying that interpretation to the last set of tests - using transcodes that preserved the full scale YUV luma (RawYV12/YUY2, and the vfw-encoded UTVideo, FFV1, HuffYUV) - the evidence there would suggest that the luma down-scaling is mitigated. As a result, those frames that are "passed through" retain the full scale luma, whereas those to which an "RGB requiring effect" is applied are merely clamped to 16-235 as a result of the Rec709 conversion to RGB and back. And the same, as it appears, would apply to the tests with the native AVCHD.mts clips off my HF-G10, where the original 16-255 range luma is preserved in the "pass through" frames but clamped to 16-235 when an "RGB effect" is applied.

Just what flag, or lack of, in the native AW120 clip caused it to be treated differently, I'm not sure, but applying the KDenLive "Full Luma Range" option didn't have a significant influence on the outcome, except to note that there was rather less "luma spiking" when examining the YUV histograms of the compressed render frames. And that's something that remains a mystery to me. The degree of "luma spiking" seen in the tests where the "Full Luma Range" flag was not applied bothers me a bit.

http://i.imgur.com/nGfrklt.jpg

I'll maybe look at that again with other clips and greyscale gradients, but it's one reason why I'd prefer to down scale separately for now.

As for the Effects and Transitions themselves. As I commented in the first post, it would be useful to distinguish those which call for RGB and any that don't. And I'm in the process of working my way through the list just now, based on the premise that if an effect operates in RGB it will appear as "clamping" in the YUV Histogram; this is using the native HF-G10 clip as source. I've already covered Color Correction (a main area of interest for me) and yes, as you'd expect all "call for RGB", with one exception - Gamma. And then the various 'Distort' effects; having already seen that the Mirror effect didn't cause clamping, it was interesting to find that the Wave effect doesn't either, whereas the others (Pixelize, Lens Correct, Distort, Defish, Corners) do. I'm just getting on to Transitions now. First one tested at random (Softlight), as expected, requires RGB. I'll maybe post the results when I'm finished.

Anyhow, if this thread is to be of any continuing value, it would be interesting to hear from other members what their experiences are with different video sources. In particular I'd find it helpful to know whether the results I obtained with the full AW120 clip are peculiar to the recording format on this camera, or represent the common experience with cameras recording full scale video. And then, which of the two behaviors in KDenLive - "compression" or "clamping" is the "expected" one? Both have their uses, as long as one appreciates the impact each has on luminance levels and possibly color rendition.

I have a small collection of raw clips (mostly AVCHD) from various camcorders that I compiled when trying to decide on which camcorder to buy. But, the Nikon AW120 aside, I have nothing from contemporary DSLR's and camcorders capable of recording full scale video. Sometimes there are videos on Vimeo and the like that purport to be raw footage straight from the camera, only to find after downloading that they have been processed in some way.

Video platforms always reencode due to license costs involved with broadcasting in certain audio/video codec combinations. A raw image or footage on any such video platform currently is an oxymoron.

TheDiveO wrote:.. oxymoron.

I had to look that up, after a search for images/videos of "bullocks with unusually low intelligence" turned up nothing

But seriously, what I meant was that occasionally on sites like Vimeo someone will upload, and make available for download, an actual raw clip (mts or whatever) from the camcorder/camera in question, or else provide a link to another site where the original clip can be downloaded. But they are few and far between.

Regarding:

Inapickle wrote:.....Just what flag, or lack of, in the native AW120 clip caused it to be treated differently (i.e. compressed), I'm not sure, but applying the KDenLive "Full Luma Range" option didn't have a significant influence on the outcome, except to note that there was rather less "luma spiking" when examining the YUV histograms of the compressed render frames. And that's something that remains a mystery to me. The degree of "luma spiking" seen in the tests where the "Full Luma Range" flag was not applied bothers me a bit.

http://i.imgur.com/nGfrklt.jpg

I'll maybe look at that again with other clips and greyscale gradients, but it's one reason why I'd prefer to down scale separately for now.

I've done just that. First I created a full scale (0-255) greyscale YV12 gradient clip in the same format as the Nikon AW120 clip. To do that I used a program called Pegasys (TMPGenc) Smart Renderer4. With this program it is possible to transcode a video clip (or Image) to match the format of a Master clip. So I took a full scale 8-bit ramp image that I had to hand and converted it to the same format as the "Master" AW120 clip. The program gives the option to output as separated clips or joined together. I chose the latter - so the output was the AW120 clip with the gradient segment (5 sec) tacked on, and as an .mp4 file; unfortunately the program doesn't give .mov as an output container option, so I also made a copy of the AW120 clip in mp4.

Here's what the YUV Histogram and Luma WFM (rotated to create line curve) of the gradient looks like:

http://i.imgur.com/bvNy74K.png
http://i.imgur.com/eP58d1f.png

The gradient is not completely smooth as the source image was 1280x720 PNG and so got scaled-up to 1920x1080 YV12 in the format conversion - so there's some very feint banding already there, but it's adequate for these tests and actually serves to demonstrate the different effects more clearly.

Testing both the "AW120+Gradient".mp4 and AW120.mp4 clip in KDenLive I found that they behaved in exactly the same way as the native AW120.mov clip, the gradient included i.e. on "pass through", the luma was compressed to 16-235. Rendering out to Lossless Matroska.mkv and Intra h264.mp4, here's what the YUV Histogram and Luma WFM of the gradient portion looks like (same with both render formats) - this was processing with the "Full Luma Range" setting OFF:

http://i.imgur.com/aF9tjkQ.png
http://i.imgur.com/WRedezh.png

The "luma spiking" in the Histogram is obvious. Hopefully in the upload image one can also make out the stronger 'banding' on the gradient itself and the more jagged WFM line curve. It's a lot clearer original PNG frame shot. Transcodes of the "AW120+Gradient".mp4 clip to DNxHD and Matroska.mkv, using the KDenLive presets, gave exactly exactly the same result, by the way.

Now, here's the same when the AW120+Gradient clip was processed with the "Full Luma Range" ON. Stronger banding there in my opinion. Again, more striking in the original image though:

http://i.imgur.com/MoD2I08.png
http://i.imgur.com/G8j4ZFh.png

And, for comparison, here are the gradient Histograms when compression (down-scaling) to 16-255 was performed using two different AVISynth Levels filters.
The first, using SmoothLevels (SmoothAdjust pack) which uses a dithered alogorithm precisely to avoid such artifacts:

http://i.imgur.com/Xq6dRkT.png
http://i.imgur.com/b1zSSgZ.png

Dramatically less spiking and banding.

And the second, using a filter (scripted function) YLevels, which predated SmoothLevels.

http://i.imgur.com/ZIbvTBT.png
http://i.imgur.com/VwsjpGJ.png

Similar results there to what was seen with the Compressed renders in KDenlive. Pronounced spiking and banding again.

And that's just one side of the coin. Up-scaling (expanding) the compressed output back to 0-255 (as one might wish to do to recover the original gradient/dynamic range) doesn't make things any better. Once the 'banding' is set, it's going to be preserved in the up-scale:

Worst case:
http://i.imgur.com/3QDkDZC.png
http://i.imgur.com/UO7JNwP.png

Best case: Pre-compressing and post-upscaling with SmoothLevels:
http://i.imgur.com/GjWivad.png
http://i.imgur.com/pGi5b8v.png

So this illustrates why I try to avoid compression whenever possible, and when I do find need for it, prefer to pre-compress and post-expand using a levels filter like SmoothLevels to reduce the chance of banding and posterization artifacts.

Having little more than basic knowledge of FFMPEG myself, is there anything equivalent in FFMPEG (dithered scaling filter etc) that could be brought to bear. I'd like, if at possible, to move on from this half-Windows/half-Linux way of working, if it could all be done in Linux.

Ffmpeg surely is a beast of software. I would suggest asking in a ffmpeg forum as I would hope that's where the ffmpeg experts hang out.

Thanks. I'll maybe try Doom9's forum first. There are "gear heads" there with cross-platform experience who might be able help, especially when it comes to AVISynth/FFMPEG equivalencies and workarounds.

I would be interested to hear back in case you get suitable responses from those other forums.