VirtualDub2

[rgr]

Originally Posted by v0lt

I tested the increase in frame size.
GDI - Point
DirectDraw - Bilinear
Direct3D 9 - Point/Bilinear/Bicubic
Direct3D 11 - Point/Bilinear/Bad Bicubic
OpenGL - Point/Bilinear/Bad Bicubic

Frame reduction works visually the same for different APIs.

Direct3D 9 supports transparency.

Thanks. So it's best to stick with DirectX9.

[nji]

When restoring movies I sometimes have to use lossless format as intermediate step.

Most (if not all) lossless formats use YUV as pixel format.
Now I realized that default subsampling is 422, if not 420.
This worries me.

Doesn't mean anything but 444 mean information loss?
(I hope this question isn't too... well...

[LigH]

The most common consumer video formats with an efficient compression use YUV 4:2:0 chroma subsampling anyway. Subsampling 4:2:2 may be used in more or less professional encoder profiles which are hardly used in digital broadcast or disc media standards.

The Ut Codec package offers a variety of specialized lossless codecs with separate FourCC identifiers per subsampling and bitdepth.

[nji]

So... if I choose one of VD2's lossless codecs (x265 lossless, FFV1 lossless, HUFYUV lossless)
with default subsampling settings I won't get lossless?
I explicitely have to change subsampling to YUV 4:4:4 to get true lossless?

(I wonder why the combination of codecs called "lossless" with anything but YUV4:4:4 or RGB
is called lossless at all. Isn't it misleading?).

Only uncompressed and lagarith do real lossless?

(If that's the case it's probably not only me to be shocked... for all the data lost)

[LigH]

Rather the opposite. I would always recommend to use a codec for intermediate files which matches the same chroma subsampling as the output of your workflow up to that point. If you did not change the pixel format during a previous edit, then it shall be the same as the input video's.

If you force a higher chroma resolution than your original workflow's, then the codec may have to upscale the chrominance planes which may not be a lossless operation. And it is also a waste of space.

[nji]

Sorry, but no, you must be wrong.

Take an example of RGB input format;
then do some filter (say blur just of an example. format stays RGB(A)).

Now I want to save it lossless (to do some external manipulation or whatever).

If I use one of the mentioned lossless codecs above:

FFMPEG / x265 lossless takes YUV 4:2:0: (larger data loss).
FFMPEG Huffyuv lossless takes YUV4:2:2 P16 : data loss.
FFMPEG Huffyuv lossless takes RGB24: OK.

I'm puzzled (that's why I'm asking)...
Or does x265 lossless do some trick so that 4:2:0 acutally is without data loss?

[LigH]

Of course, if your original footage is RGB (e.g. the output of a 3D animation system or a screen recording), and you don't convert it during your filtering, then use a lossless RGB codec.

But no DVB / DVD / Blu-ray is encoded in RGB. Consumer formats use an efficiently compressed video format (e.g. H.264 or VC-1) in YUV, almost certainly with 4:2:0 chroma subsampling.

If you convert your video to YUV 4:4:4 during your filtering, then use a YUV 4:4:4 codec.

[nji]

So you got me wrong all the time.

I never adressed the task of simple format conversion of movies (Source in, destination out).

As I explained in my first post I'm about to lossless save a movie within my workflow.

Usually it's not me to explicitely perform pixel format conversion,
but many filters in VD2 do (e.g. output RGBA),
and obviously most of the explicitely stated lossless codecs do data loss
due to their default subsampling.
(Actually I don't understand what "lossless" means at all in these cases?)

[LigH]

OK, once again for dummies...

If your filtering workflow returns RGB, then using a lossless RGB codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.
If your filtering workflow returns YUV 4:4:4, then using a lossless YUV 4:4:4 codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.
If your filtering workflow returns YUV 4:2:2, then using a lossless YUV 4:2:2 codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.
If your filtering workflow returns YUV 4:2:0, then using a lossless YUV 4:2:0 codec will store this output losslessly. Using a codec which enforces any other color space will add some conversion loss.

If any of your filters convert between two color spaces, there will be a loss between the video input and the filtering output in addition to the filter effect.
Using AviSynth filtering may avoid this because most AviSynth filters support many color spaces without a required color space/subsampling conversion.

[nji]

Originally Posted by LigH

OK, once again for dummies...

Pardon, I don't see why it was you pointing the possibility of having to change the default subsampling (even when lossless codec chosen), but me.

Moreover I don't think "dummies" is appropriate in the forum.

[LigH]

Sorry for that, today I have several sources of stress in parallel...

[rgr]

Originally Posted by nji

So... if I choose one of VD2's lossless codecs (x265 lossless, FFV1 lossless, HUFYUV lossless)
with default subsampling settings I won't get lossless?

If your source is YUV420, then lossless YUV420 will be lossless. If your source is YUV422, then lossless YUV422 will be lossless (but lossless YUV420 will not be lossless). If your source is YUV444, then lossless YUV444 will be lossless (but lossless YUV420 and YUV422 will not).

[rgr]

Originally Posted by nji

Take an example of RGB input format;
then do some filter (say blur just of an example. format stays RGB(A)).

Now I want to save it lossless (to do some external manipulation or whatever).

If I use one of the mentioned lossless codecs above:

FFMPEG / x265 lossless takes YUV 4:2:0: (larger data loss).
FFMPEG Huffyuv lossless takes YUV4:2:2 P16 : data loss.
FFMPEG Huffyuv lossless takes RGB24: OK.

I'm puzzled (that's why I'm asking)...
Or does x265 lossless do some trick so that 4:2:0 acutally is without data loss?

No RGB->YUV conversion is completely lossless, although RGB->YUV444 can be considered as such.

[LigH]

And if you have a YUV420 source, but you filter the video before saving and the filter converts to RGB, then use an RGB lossless codec.

[nji]

Thankyou for all your kind help.

So the situation in general seems quite easy I might think.

BUT the point is:
I would never have expected that when choosing a lossless codec
(without further regard to pixel format) it would be lossless only
when there's a pixel formats' matching for filter graph output and encoder.

"Lossless means lossless" that's what I always thought.
(And I suspect I'm not the only "simple" user thinking so).
Now I'm aware that I produced lot of quality loss due to that presumption.

My proposal would be to have matching pixel formats as default
for lossless formats.

However I found out that some lossless formats do well only for
appropriate pixel values (lagarith-rgb, avc-yuv,...).

Moreover I made the observation that if I choose matching pixel formats
then the various lossless codecs don't seem to have much difference in
file size (bits/pixel is always about bitdepth) ???

The way it is now one seems have to take utmost care no to have
quality drop.

[LigH]

Lossless codecs have a limit of compressibility. Claude Shannon, father of the modern Theory of Information, called it the entropy.

[poisondeathray]

Originally Posted by rgr

No RGB->YUV conversion is completely lossless, although RGB->YUV444 can be considered as such.

8bit RGB <=> YUV444P10 can be lossless and reversible if done properly. This was proven for all 16777216 8bit RGB colors in other threads

Originally Posted by nji

My proposal would be to have matching pixel formats as default
for lossless formats.

It would be difficult to implement properly, because of the myriad of pixel formats, and many codecs only support a tiny subset of formats. e.g. YUV420P10 is getting quite common, but lagarith, huffyuv do not support it

Actually official lagarith (not vdub lagarith) RGB default setting will use whatever pixel type is sent and reproduce it, if supported. e.g. If you send RGB24, it will use RGB24, if you send YUY2, it will use YUY2, if you send YV12, it will use YV12

However I found out that some lossless formats do well only for
appropriate pixel values (lagarith-rgb, avc-yuv,...).

Not sure what "do well" means...? Does that mean user error ? Does it mean unsupported pixel type and some inserted auto-conversion ? Does that mean compression ratio ?

lagarith supports YV12, YUY2, RGB . Lossless AVC supports 8 and 10bit YUV, all common subsampled formats 420,422,444, and RGB

Moreover I made the observation that if I choose matching pixel formats
then the various lossless codecs don't seem to have much difference in
file size (bits/pixel is always about bitdepth) ???

How much is "much difference" for you ?

lagarith should generally be a few% smaller than huffyuv in the same pixel format. The trade off is it's slower for encode/decode speed

The most significant factor in most situations for lossless compression ratio will be the use of I-frame only vs. long GOP (temporal compression) lossless compression . On average you might expect between 10-35% smaller, it's content dependent . Lagarith /huffyuv/ut video are i-frame only. x264/x265/ffv1 have long GOP options

The way it is now one seems have to take utmost care no to have
quality drop.

It always has been that way. Not just for video and audio. If you're sloppy with anything in life, you run a higher risk of quality problems (e.g if you're painting a fence, if you're fixing a car, fixing plumbing ....)

[LigH]

YUV can be several different color spaces, depending on the angles towards the RGB color cube. There is a special color space YCgCo or YCoCg which uses a symmetric orientation, this conversion from and to RGB is indeed lossless and reversible even in 8 bit precision only.

[Leo 69]

Thanks to v0lt for continuous updates for this crucial application.

[v0lt]

Test build VirtualDub2 v2.4.0.917
Fixed crash of 64-bit version when using highpass, lowpass audio filters.
avlib_vdplugin 1.0.0.377.