APV, visually lossless pro codec from Samsung

[birdie]

https://www.ietf.org/archive/id/draft-lim-apv-00.html

https://developer.samsung.com/conference/sdc23/tech-square/advanced-professional-video-codec

The APV codec supports the following features:


Perceptually lossless video quality that is close to raw video quality

Low complexity and high throughput intra frame only coding without pixel domain prediction

Support for high bit-rates up to a few Gbps for 2K, 4K and 8K resolution content, enabled by a lightweight entropy coding scheme

Frame tiling for immersive content and for enabling parallel encoding and decoding

Support for various chroma sampling formats from 4:2:2 to 4:4:4, and bit-depths from 10 to 16

Support for multiple decoding and re-encoding without severe visual quality degradation

[Sagittaire]

https://www.ietf.org/archive/id/draft-lim-apv-00.html

https://developer.samsung.com/conference/sdc23/tech-square/advanced-professional-video-codec

The APV codec supports the following features:


Perceptually lossless video quality that is close to raw video quality

Low complexity and high throughput intra frame only coding without pixel domain prediction

Support for high bit-rates up to a few Gbps for 2K, 4K and 8K resolution content, enabled by a lightweight entropy coding scheme

Frame tiling for immersive content and for enabling parallel encoding and decoding

Support for various chroma sampling formats from 4:2:2 to 4:4:4, and bit-depths from 10 to 16

Support for multiple decoding and re-encoding without severe visual quality degradation


Strange codec because not strictly lossless ...

And all codec will be visualy lossless if you use only Iframe at really low quantizer. You can make that easely with H264 or H265.

[GeoffreyA]

Strange codec because not strictly lossless ...

And all codec will be visualy lossless if you use only Iframe at really low quantizer. You can make that easely with H264 or H265.

A challenger to ProRes and DNxHD, I suppose.

[kolak]

More like Daniel2.

[Blue_MiSfit]

Hm... Interesting. What problem does this solve that's not solved already by

- JPEG XS / TICO
- High throughput JPEG2000
- ProRes
- DNxHD / DNxHR
- Intra-only AVC / HEVC / AV1

?

[kolak]

None?
Maybe it's faster.

[Zebulon84]

Next FFmpeg release should be able to decode, mux and demux this codec :

https://www.phoronix.com/news/FFmpeg-Merges-APV-Decoder

[birdie]

Next FFmpeg release should be able to decode, mux and demux this codec :

https://www.phoronix.com/news/FFmpeg-Merges-APV-Decoder

Yeah, Samsung contributed. Some companies are actually sane.

[excellentswordfight]

Hm... Interesting. What problem does this solve that's not solved already by

- JPEG XS / TICO
- High throughput JPEG2000
- ProRes
- DNxHD / DNxHR
- Intra-only AVC / HEVC / AV1

?
If its open and license free maybe (which it looks like it is)? In the camera and file based DI-sphere all common formats are all propitiatory (XAVC (AVC & HEVC flavors), DNxHD and ProRes), + that each camera manufacturer has their own RAW-format. This space has always been very divided, like it took years and years before we got an "free" prores-encoder.

IF its an improvement on ProRes in most regards, while being completely open, that sounds pretty great.

But...

https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fimgs.xkcd.com%2Fcomics%2Fstandards.png&f=1&nofb=1&ipt=bd18e964773cfe41b8f086214b0e1b69fab2a2ee5c651804d3c8213894805483

[benwaggoner]

If its open and license free maybe (which it looks like it is)? In the camera and file based DI-sphere all common formats are all propitiatory (XAVC (AVC & HEVC flavors), DNxHD and ProRes), + that each camera manufacturer has their own RAW-format. This space has always been very divided, like it took years and years before we got an "free" prores-encoder.

IF its an improvement on ProRes in most regards, while being completely open, that sounds pretty great.

Open and royalty free is my understanding. Samsung has been doing good work around royalty free encoding stuff in recent years, including AV1&2, the IAMF audio codec, and EVC.

[FranceBB]

it took years and years before we got an "free" prores-encoder.

and even then we have to spoof the writing library as "Apple" (luckily it's supported directly within FFMpeg with -vendor apl0) because if the official software decoders see "Lavc" they artificially block decoding even if the bitstream is actually perfectly compliant.

Apple at its best... -.-

Anyway, the current open source prores_ks encoder is actually pretty good and I've been using it regularly. I even sent out those files to plenty of other companies (the most famous one being ITV when I sent them all the Hell's Kitchen episodes re-encoded in ProRes from our masterfiles) and they happily accepted them.

[Z2697]

and even then we have to spoof the writing library as "Apple" (luckily it's supported directly within FFMpeg with -vendor apl0) because if the official software decoders see "Lavc" they artificially block decoding even if the bitstream is actually perfectly compliant.

Apple at its best... -.-

Anyway, the current open source prores_ks encoder is actually pretty good and I've been using it regularly. I even sent out those files to plenty of other companies (the most famous one being ITV when I sent them all the Hell's Kitchen episodes re-encoded in ProRes from our masterfiles) and they happily accepted them.

What format are the masterfiles?

[Jamaika]

- Perceptually lossless video quality that is close to raw video quality.
For low bitrate too? Where is the lossless function?

- Support for various chroma sampling formats from 4:2:2 to 4:4:4, and bit-depths from 10 to 16
And what do we have in the case of codec in the case of 4:2:0 in 8bit?

- Next FFmpeg release should be able to decode, mux and demux this codec :
It should, but it doesn't decode. It isn't compatible with the available samsung encoder

Samsung codec compatibility with ffmpeg decoder:
https://github.com/FFmpeg/FFmpeg/commit/7faa560f1a36cebb58bf8e5a2da9e1d4d02497fc

oapv_app_enc.exe -v 3 -i "avp_yuv420p.yuv" --width 1920 --height 1080 --input-depth 8 --input-csp 1 --fps 30000/1001 --threads 20 --preset medium --bitrate 6000K -o "avp_yuv420p.avp"
[apv @ 000002f78458ee80] chroma_format_idc 1 for 4:2:0 is not allowed in APV.
[apv @ 000002f78458ee80] Failed to read unit 0 (type 1).
[apv @ 000002f78458ee80] Failed to parse access unit.

oapv_app_enc.exe -v 3 -i "avp_yuv422p10le.yuv" --width 1920 --height 1080 --input-depth 10 --input-csp 2 --fps 30000/1001 --threads 20 --preset medium --bitrate 6000K -o "avp_yuv422p10le.avp"
The image quality is disaster.
https://www.sendspace.com/file/5kq1sy

Other notes: There is a huge difference in image quality for FullHD yuv420p10le between 30000K and 40000K bitrate.
Edit: Added openapv to ffmpeg. Unfortunately it fails to compile. There are common functions.
https://github.com/AcademySoftwareFoundation/openapv/commit/938691ccd2994de29ead7fd13d77ea2fff242aee
https://github.com/FFmpeg/FFmpeg/commit/fab691edaf53bbf10429ef3448f1f274e5078395
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../lib\libxeve_x64.a(xeve_thread_pool.o):xeve_thread_po:(.text+0x4a0): multiple definition of `threadsafe_assign'; ../lib\libopenapv_x64.a(oapv_tpool.o):oapv_tpool.c:(.text+0x490): first defined here

Disadvantages: apv container doesn't have a lossless compressor.
apv files can't be converted to mov,mkv,avi. Besides it is unjustified due to the large file sizes.

"payload %zu but expecting %zu\n",
fixed:
"payload %"SIZE_SPECIFIER" but expecting %"SIZE_SPECIFIER"\n",

[FranceBB]

What format are the masterfiles?

The Italian version is edited entirely in AVID Media Composer, so it's DNX but I don't remember which flavor (and I'm not gonna restore a file just to find out) muxed in an mxf container, while the American version is edited in Davinci Resolve (not by us) and it's indeed ProRes, in particular Apple ProRes HQ 1920x1080 203 Mbit/s 29.970i TFF 4:2:2 BT709 SDR with PCM 24bit 48000Hz audio muxed in a mov container.

[hajj_3]

encode support for APV is coming in ffmpeg: https://www.phoronix.com/news/FFmpeg-Adds-APV-Encoder

[FranceBB]

Nice, so we have everything then: encoding support with an open source encoder directly from within FFMpeg and decoding support in libav which means that we also have indexers in Avisynth and VapourSynth ( i.e LWLibavVideoSource() and FFVideoSource() ) and playback support in MPV and VLC.

It would be nice to see support coming up in Android for this codec alongside the ability to shoot log so that we can squeeze as much as we can out of those tiny sensors if we need to. Not that I would probably ever do that, but if I'm in a particular situation in which I don't have my camera with me I might as well just try to use that one instead.

As far as the industry goes, however, it's gonna be hard for it to gain some traction as it's gonna need camera manufacturers to play along (Canon, Sony, Red, Arri, Fuji etc) and I don't really see that happening, but who knows, I guess time will tell.

[excellentswordfight]

Nice, so we have everything then: encoding support with an open source encoder directly from within FFMpeg and decoding support in libav which means that we also have indexers in Avisynth and VapourSynth ( i.e LWLibavVideoSource() and FFVideoSource() ) and playback support in MPV and VLC.

It would be nice to see support coming up in Android for this codec alongside the ability to shoot log so that we can squeeze as much as we can out of those tiny sensors if we need to. Not that I would probably ever do that, but if I'm in a particular situation in which I don't have my camera with me I might as well just try to use that one instead.

As far as the industry goes, however, it's gonna be hard for it to gain some traction as it's gonna need camera manufacturers to play along (Canon, Sony, Red, Arri, Fuji etc) and I don't really see that happening, but who knows, I guess time will tell.
Does anyone see if there any different compression options? Most DI have different compression ratios (ls, hx for prores, class100/300 for XAVC etc), is there anything like this here, or is it always the same compression level? And has anyone seen typical bitrate levels for common formats?

[FranceBB]

Does anyone see if there any different compression options?

Judging from the commits here https://github.com/FFmpeg/FFmpeg/blob/f4e72eb5a3dbd25ed3ab6c9f89c42adcfc0b5e3d/libavcodec/liboapvenc.c#L52 there seems to be different compression levels as we can specify different presets

-prest fastest, fast, medium, slow, placebo

but I haven't tried it yet.

[Zebulon84]

It would be nice to see support coming up in Android for this codec alongside the ability to shoot log so that we can squeeze as much as we can out of those tiny sensors if we need to.
It should come with Android 16 : https://www.androidauthority.com/android-16-beta-1-3518608/
"Android 16 will support the APV 422-10 Profile, which provides YUV422 color sampling, 10-bit encoding, and target bitrates of up to 2Gbps."

[FranceBB]

Interesting. I'm currently on Android 16 Beta with my Pixel 6 Pro but I can only see H.264 and H.265. I'll let you know if something comes up in the future updates.

[foxyshadis]

I don't think it will ever be an option in the Camera app, which is very restricted in options, but it should be one of the built-in system codecs now, so other apps can use it. And it should decode if you open a video with it in, say, Photos. https://developer.android.com/reference/android/media/MediaFormat#MIMETYPE_VIDEO_APV

[benwaggoner]

I don't think it will ever be an option in the Camera app, which is very restricted in options, but it should be one of the built-in system codecs now, so other apps can use it.
Perhaps not in the Android Camera app, but it would make a lot of sense for Samsung to release some kind of Pro camera app that could support the codec for high fidelity recording. An equivalent to ProRes on iPhone Pros.

[LigH]

The media-autobuild suite now supports compiling it. Used repository:

https://github.com/AcademySoftwareFoundation/openapv

[excellentswordfight]

Has anyone tried it? Still interested to know what typical datarate range we are talking about, only thing I can find is that it supports up to a "few Gbps", I would like to know if we are talking about a codec that offer low, about the same, or higher datarates than prores (biggest codec in this segment) at a similar quality level.

[GeoffreyA]

Has anyone tried it? Still interested to know what typical datarate range we are talking about, only thing I can find is that it supports up to a "few Gbps", I would like to know if we are talking about a codec that offer low, about the same, or higher datarates than prores (biggest codec in this segment) at a similar quality level.

On a short, grainy sample, APV has a lower bitrate than ProRes; I can't tell the difference but ProRes might have the edge. There is a range for CQP, though, as well as presets. Everything is default: CQP 32, and preset medium. An FFV1 encode of the APV file was made for playback, but the frame rate has changed: coming from the APV bitstream, perhaps there's not much information.

APV: 168 MB
ProRes: 292 MB

Link: https://we.tl/t-rw0w0Zcy1k

ffmpeg -i REF.mp4 -c:v prores ProRes.mkv
ffmpeg -i REF.mp4 -c:v liboapv APV.apv
ffmpeg -i APV.apv -c:v ffv1 APV_encoded_as_FFV1.mkv

[Z2697]

On a short, grainy sample, APV has a lower bitrate than ProRes; I can't tell the difference but ProRes might have the edge. There is a range for CQP, though, as well as presets. Everything is default: CQP 32, and preset medium. An FFV1 encode of the APV file was made for playback, but the frame rate has changed: coming from the APV bitstream, perhaps there's not much information.

APV: 168 MB
ProRes: 292 MB

Link: https://we.tl/t-rw0w0Zcy1k

ffmpeg -i REF.mp4 -c:v prores ProRes.mkv
ffmpeg -i REF.mp4 -c:v liboapv APV.apv
ffmpeg -i APV.apv -c:v ffv1 APV_encoded_as_FFV1.mkv


Probably gonna need a higher quality source for proper testing

[GeoffreyA]

Probably gonna need a higher quality source for proper testing

Sol Levante might be a good one but no grain. I've only got a 1080p 4:2:0 lossless copy on my computer, though. I don't think I've got any high-end mezzanine files of anything.

[benwaggoner]

Sol Levante might be a good one but no grain. I've only got a 1080p 4:2:0 lossless copy on my computer, though. I don't think I've got any high-end mezzanine files of anything.
Sol Levante is my current go-to non-grain stress test clip. Pretty much every encoder I've tried gets huge ugly QP spikes during those spinning overlapping Mandala shots, even at higher than normal bitrates.

It's a great test clip to see how things break, but it's not a representative example of anything. Tears of Steel is my recommended standard test clip for normal content.

STeM2 is also really good for clean natural image stuff and available in UHD HDR.
https://dpel.aswf.io/asc-stem2/

It's got all sorts of embedded stress test bits, including the corners of Rec. 2020.

[GeoffreyA]

Oh, yes, those overlapping blue shots are a killer!

I always found that Tears of Steel compresses too easily. Would you say it's representative in that it's similar to most streaming content today?

Thanks for the recommendation of STeM2. Actually, for testing tone mapping, I was using Fellowship of the Ring and Samsung's Travel with My Pet.

[excellentswordfight]

Oh, yes, those overlapping blue shots are a killer!

I always found that Tears of Steel compresses too easily. Would you say it's representative in that it's similar to most streaming content today?

Thanks for the recommendation of STeM2. Actually, for testing tone mapping, I was using Fellowship of the Ring and Samsung's Travel with My Pet.
I would say that STeM2 is more representative, its a very clean modern digital image, typical for at least a lot of original netflix content. It looks very good, but its very easy to compress. Especially for good modern encoders that excels with clean sources. With x265 you can do 5Mbps at UHD without any major issues.

Tears of Steel is by no means a "stress test", but I think its very much representative of a typical live action movie with about below average compressibility (at least compared to a lot of modern titles).

To my knowledge, the only common UHD open source content available as lossless sourced from film is SVT:s classic test sequences. But it it just a few shots in 50 fps so its not a great substitute. But could be good to test a DI codec I guess.

I would very much like there to be something like STeM2, so a proper "title" in UHD HDR, but shot on film, doesnt need to be a grain feast, but but at least a decent amount, that would struggle in the 20-25Mbps bitrate range that is commonly used in streaming today.

[Z2697]

Let's shoot our own test clip!

[GeoffreyA]

I would say that STeM2 is more representative, its a very clean modern digital image, typical for at least a lot of original netflix content. It looks very good, but its very easy to compress. Especially for good modern encoders that excels with clean sources. With x265 you can do 5Mbps at UHD without any major issues.

Tears of Steel is by no means a "stress test", but I think its very much representative of a typical live action movie with about below average compressibility (at least compared to a lot of modern titles).

To my knowledge, the only common UHD open source content available as lossless sourced from film is SVT:s classic test sequences. But it it just a few shots in 50 fps so its not a great substitute. But could be good to test a DI codec I guess.

I would very much like there to be something like STeM2, so a proper "title" in UHD HDR, but shot on film, doesnt need to be a grain feast, but but at least a decent amount, that would struggle in the 20-25Mbps bitrate range that is commonly used in streaming today.

I half-heartedly tried a low-end copy of STeM2 a while back but, because it compressed easily, didn't care much. I suppose I should consider it seriously with a proper source, since it is representative of today's material.

I agree it would be helpful if we had an open-source equivalent of, say, Interstellar or Last Night in Soho, both of which have a gentle quantity of grain. Interestingly, Tenet, Oppenheimer, and Nope look strangely clean: they've clearly degrained the picture.

Let's shoot our own test clip!

Hear! Hear! Let's do it :)

[Z2697]

Interestingly, Tenet, Oppenheimer, and Nope look strangely clean: they've clearly degrained the picture.

I think they are just finer, probably different film was used. (yeah, googled it, Interstellar and Last Night in Soho is 35mm + IMAX/digital, the others are 65mm + IMAX)
If you compare the IMAX shots that have similar light level, the grain is roughly the same strength.

[GeoffreyA]

As always, good point. The 65mm is finer, explaining why the other two have a relatively coarser appearance. Still, I reckon Van Hoytema is applying processing to tone down the grain further.

[FranceBB]

Let's shoot our own test clip!

Problem is most cameras don't support recording losslessly, they would do things like Sony RAW, Blackmagic RAW, Arri RAW, XAVC, ProRes etc, all of which are very high quality, can be set to be all intra and can get to very high bitrates, but are nonetheless lossy. It's very hard to find cameras that can shoot .dng lossless or .tiff lossless in which every frame is a picture, the audio is a sidecar PCM muxed in a .wav container and you have an XML linking the two and specifying the timecode, framerate etc.

I guess the closest thing would be connecting a bunch of cameras via SDI to a video mixer / router and then connect the output of that to a Blackmagic Decklink card connected via PCI Express to save the incoming lossless stream in v210 lossless. Once again, relatively easily doable, but it will be limited to what you're gonna shoot in a studio which is generally news, perhaps some cooking programs etc.

[excellentswordfight]

Problem is most cameras don't support recording losslessly, they would do things like Sony RAW, Blackmagic RAW, Arri RAW, XAVC, ProRes etc, all of which are very high quality, can be set to be all intra and can get to very high bitrates, but are nonetheless lossy. It's very hard to find cameras that can shoot .dng lossless or .tiff lossless in which every frame is a picture, the audio is a sidecar PCM muxed in a .wav container and you have an XML linking the two and specifying the timecode, framerate etc.

I guess the closest thing would be connecting a bunch of cameras via SDI to a video mixer / router and then connect the output of that to a Blackmagic Decklink card connected via PCI Express to save the incoming lossless stream in v210 lossless. Once again, relatively easily doable, but it will be limited to what you're gonna shoot in a studio which is generally news, perhaps some cooking programs etc.
This is getting off topic, put I dont really see that as an big issue. Does it really matter if its "truly lossless" or not? Im more a fan of having samples that are good representative of the content that Im actually encoding, on the hard/complex side ofc, but still representative of what im actually going to use the encoder for. So if for example if REDCODE RAW or X-OCN XT (visually lossless compression) is used as capture format, thats not a big issue imo, its high quality and used in high end productions all the time so it can still be a representative source.

With that said, ARRIRAW is used all the time in high end productions, and that is a lossless format. And also, the issue is not availability of high end digital samples, the issue is open sourced titles shot on film. Cause its not the digital titles in general that is the struggle of codecs and what most type of distribution is struggling with today, its titles with grain (and yes, titles shot on digital can have that as well).

And is that SDI-solution really an option? They do 12/16bit 6-8K capture nowdays, is there really SDI products that would allow for external lossless capture?

I agree it would be helpful if we had an open-source equivalent of, say, Interstellar or Last Night in Soho, both of which have a gentle quantity of grain. Interestingly, Tenet, Oppenheimer, and Nope look strangely clean: they've clearly degrained the picture.

Again, this is spiraling out of topic i guess, but I enjoy the subject :)

It seems like exterior shots on 65mm in general produce very little grain, the are plenty av examples of that (like those you mention), and TBH after seeing some large-format/imax stuff shot digitally I dont actually see the reason of being that obsessed of shooting this on film when its that clean. And this comes from someone who is a fan film. And if they shot it digutally, they could do alot more of it, maybe even the whole movie like the Joker (I saw Joker on an 70mm projection, absolutely fantastic).

Also, when it comes to 65/70mm/imax in general, at this point I think its marketing more than anything, cause in most cases its just not visually great when jumping between formats and filmstock/looks, it is more distracting than immersive. Saw Sinners recently, and that jumps between 1.78:1 and 2.76:1, absolutely jarring. Its fine when used for creative/story telling reason (e.g. when it goes 4:3 when showing an old vhs or whatever), but I actually think its an horrible trend.

[GeoffreyA]

Again, this is spiraling out of topic i guess, but I enjoy the subject :)

It seems like exterior shots on 65mm in general produce very little grain, the are plenty av examples of that (like those you mention), and TBH after seeing some large-format/imax stuff shot digitally I dont actually see the reason of being that obsessed of shooting this on film when its that clean. And this comes from someone who is a fan film. And if they shot it digutally, they could do alot more of it, maybe even the whole movie like the Joker (I saw Joker on an 70mm projection, absolutely fantastic).

Also, when it comes to 65/70mm/imax in general, at this point I think its marketing more than anything, cause in most cases its just not visually great when jumping between formats and filmstock/looks, it is more distracting than immersive. Saw Sinners recently, and that jumps between 1.78:1 and 2.76:1, absolutely jarring. Its fine when used for creative reason (e.g. when it goes 4:3 when showing an old vhs or whatever), but I actually think its an horrible trend.

True! To bring this thread back on topic, I'll post the results of an encoding of Sol Levante when at the computer: APV knocked ProRes over the head in terms of file size. I haven't compared picture quality, and it's a mere 1080p 4:2:0 copy.

65mm today certainly leads to less grain. Perhaps older 65mm stock was different? Lawrence of Arabia had a pronounced grain. At any rate, I'm not averse to movies being shot digitally; Blade Runner 2049 shows what can be done in the right hands.

I agree that the switching of aspect ratio with mixed IMAX material can be distracting. I am not a Nolan devotee and find many issues with his films, but generally, he tends to get the rhythm right when switching to the IMAX footage, though credit is also due to Van Hoytema.

[Z2697]

APV knocked ProRes over the head in terms of file size.

QP in both codec is adjustable though.

[GeoffreyA]

QP in both codec is adjustable though.

FFmpeg's ProRes wrapper doesn't seem to expose any settings.

Using default settings:

APV: 1.94 GB
ProRes: 3.7 GB

[Z2697]

FFmpeg has two prores encoder for some reason.
The non-default one "prores_ks" has an undocumented(?) option, "-q".
(Is it undocumented, or is it just ommited because it's "standard" option for a lot of encoders?)

(And is this QP or not QP? IDK.
I think QP is used to derive a quantizing matrix? This value here is setting the quantizing matrix directly?)

[GeoffreyA]

I think they are different implementations, and prores_ks is thought to be the better one.

https://trac.ffmpeg.org/wiki/Encode/VFX

Might that q setting not be an on-off switch for the different ProRes modes, standard and high quality?

EDIT: Oh, well, it does seem to be a quality setting after all. So it must be controlling a quantisation matrix.

[Z2697]

prores_ks by default is slower because it's trying to adapt the quantizer to the "prores profile specification bitrate" or something, and setting the "-q" parameter tells it to just ignore it and use constant quantizer, that's what I heard.

I guess no one really cares about the profile bitrate anymore, and should just use constant quantizer.

[Z2697]

openapv has higher quality than prores_ks until the bitrate lowers below a certain point and it's like demolished... but who cares low bitrate quality for "mezzanine codecs"? We are here for visually lossless bruh!

[GeoffreyA]

It makes me sigh when I think of having to adjust these codecs. A speed-compression preset, all right, but visually lossless should be visually lossless.

I wouldn't mind using, for example, APV in place of FFV1 if the differential were substantial. But I doubt whether it's going to make a dent in ProRes's and DNxHD's popularity.

[benwaggoner]

prores_ks by default is slower because it's trying to adapt the quantizer to the "prores profile specification bitrate" or something, and setting the "-q" parameter tells it to just ignore it and use constant quantizer, that's what I heard.

I guess no one really cares about the profile bitrate anymore, and should just use constant quantizer.
Profile bitrate would mainly matter to make file size more predictable at to cap worst case encode/decode or read/write speeds. Stuff that SSD storage and Moore's Law have made much less relevant for traditional ProRes use cases.

[benwaggoner]

It makes me sigh when I think of having to adjust these codecs. A speed-compression preset, all right, but visually lossless should be visually lossless.
Visually lossless is harder to define than you might think. How much pause and zoom-in is allowed? Are artifacts that aren't psychovisually detectable but could cause issues with multiple generations of additional processing acceptable?

A postproduction codec needs to be visually lossless through X generations of decode-modify-reencode with a huge variety of content. A mezzanine codec doesn't need to be as precise, but it still shouldn't have anything that would cause any changes after being scaled down and encoded in another codec, for example.

[GeoffreyA]

Visually lossless is harder to define than you might think. How much pause and zoom-in is allowed? Are artifacts that aren't psychovisually detectable but could cause issues with multiple generations of additional processing acceptable?

A postproduction codec needs to be visually lossless through X generations of decode-modify-reencode with a huge variety of content. A mezzanine codec doesn't need to be as precise, but it still shouldn't have anything that would cause any changes after being scaled down and encoded in another codec, for example.

Good points, Ben, and food for thought as always. I like the metric of how many generations a codec can sustain before degradation is detected. It would be a fun test to try with APV and ProRes, and indeed, our popular lossy codecs.

I remember an analogous discussion with audio codecs from Hydrogenaudio, and I tested it myself. Opus degraded significantly compared to AAC over 100 encode cycles or so. Those lossy codecs aren't meant to be used that way, but interesting nonetheless.

[birdie]

https://github.com/AcademySoftwareFoundation/openapv/releases/tag/v0.2.0.0

v0.2.0.0


Adds 'APV family' (typical target bitrate) definition
Introduces new API to get APV family's bitrates
Updates 'level' table according to APV spec changes
Improves coding gain according to preset values through enhanced RDOQ and RDO
Supports various profiles;
422-12, 444-10, 444-12, 4444-10, 4444-12, and 400-10
Speed-up encoding and decoding time
Optimizes VLC encoding and decoding code
Safe bitstreasm buffer access by one byte-level addressing
Safe management of metadata by instance copy
Introduces a method to disable the 'Raw bitstream format' in encoding and decoding API
new API for getting version number
new logo of OpenAPV project provided by ASWF

[benwaggoner]

Good points, Ben, and food for thought as always. I like the metric of how many generations a codec can sustain before degradation is detected. It would be a fun test to try with APV and ProRes, and indeed, our popular lossy codecs.

I remember an analogous discussion with audio codecs from Hydrogenaudio, and I tested it myself. Opus degraded significantly compared to AAC over 100 encode cycles or so. Those lossy codecs aren't meant to be used that way, but interesting nonetheless.
Apple did a detailed report about ProRes multigenerational quality, and it has been done for other codecs as well.

And yeah, mezzanine and intermediate codecs are quite different use cases than distribution codecs. Among other things, they're generally intra-only. The job is about delivering the high quality bar at the lowest bitrate and complexity, not about making a low bitrate look good.

[Z2697]

Good points, Ben, and food for thought as always. I like the metric of how many generations a codec can sustain before degradation is detected. It would be a fun test to try with APV and ProRes, and indeed, our popular lossy codecs.

I remember an analogous discussion with audio codecs from Hydrogenaudio, and I tested it myself. Opus degraded significantly compared to AAC over 100 encode cycles or so. Those lossy codecs aren't meant to be used that way, but interesting nonetheless.

Opus' preproecssing hitting hard. :p

Yes, 20 KHz cutoff shouldn't make noticable difference, but when I compared the spectrogram (1st encode), I noticed that there seem to be some kind of processing on the low frequency side as well, maybe it's the < 20 Hz hearing limit, similar to the 20 KHz cutoff, or a design flaw / limitation.

It's doesn't matter for probably a few cycles, but when the cycle progress, it gets progressively weirder, making the low-frequency instruments sound like, idk, wind, somehow? Even at maximum bitrate.
This terrible generational loss is "gone" if I delete the < 100 Hz frequency.

If we ignore that, which is impossible in real world, but just imagine... the generational loss isn't terrible actually, to me at least.
Still not as good as QAAC.
But as we all know, AAC encoders have a vast quality range. And good AAC encoders ain't free and open source.
I tested QAAC, ffmpeg aac_at (by audiotoolbox wrapper, and is using same DLLs as QAAC), ffmpeg libfdk_aac and ffmpeg aac, QAAC is the only one that's better than "Opus minus low freq".
(The QAAC test is using QAAC for both decode and encode)
EDIT: turns out I screwed the aac_at test, the pre-skip ruined it very bad.

Oh there's an experimental ffmpeg native Opus encoder, I tested it and... somehow it has low generational loss comparable to QAAC (still worse).
But the problem is, it's experimental, who knows what else can happen.