PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/
As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.
H.264 is Magic (2016)
161–170 of 229 posts
Re: H.264 is Magic (2016)
#162Earlier quoted context omitted.
you can serve new devices with JPEG XL and convert it back to JPEG without loss on server for old devices
I think you might have that backwards. JPEG can be losslessly converted to JPEG XL with better compression (~20% smaller), but I haven't seen anything about going the other direction. I'm not sure how it would be possible with JPEG XL's different sized blocks and different available transforms. https://en.wikipedia.org/wiki/JPEG_XL
Either way, it's not that useful for anyone that's already deploying post-JPEG formats; even WebP should save more than 20%. Mostly it's useful for CDNs and SaaS companies like Cloudinary to transparently deploy JPEG-XL for JPEG-only customers.
Re: H.264 is Magic (2016)
#163See also H.265: * https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding And now even H.266: * https://en.wikipedia.org/wiki/Versatile_Video_Coding Also, at what point will AV1 become "mainstream"? How prevalent is it? Still seems that hardware decoding (never mind encoding) support is still only so-so.
What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread their respective codecs all over the internet through pirated content, which forced adoption. The fact that you can play .mkv files almost anywhere now is a testament to that.
libaom https://aomedia.googlesource.com/aom, the reference implementation.
https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising.
https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places where libaom is too slow.
Re: H.264 is Magic (2016)
#164With that said. Improvements of audio and video compression over the last 25 years are very impressive and have changed how the world works in several areas.
Re: H.264 is Magic (2016)
#165Earlier quoted context omitted.
I often wonder what we could do with a truly patent free codec once all the H.264 patent expired.
You don’t have to wonder: There have been many truly patent free codecs and the answer is mostly “Try to convince companies to adopt it even though they have a vested interest in using codecs they control” For example: FLAC
Re: H.264 is Magic (2016)
#166H.264 patents are not expiring yet, if anyone was wondering. 2027 seems to be when that happens. On the other hand, I believe H.263 patents already expired, and MPEG-4 ASP (DivX etc.) is expiring this year.
Interestingly enough, there's some non-standard-essential patents still floating around out there. For example, Mediatek patented converting Sorenson Spark bitstreams for decoding with standards-compliant H.263 hardware decoders[1], and that patent is still live until later in this decade.
[0] I wrote a Sorenson-flavored H.263 decoder in Rust for integration into Ruffle.
[1] The invention is literally just truncation-with-saturation wrapped in a bunch of patent language. If you have the money to front a legal fight against them, feel free to get the patent invalidated. But I don't think it matters.
Re: H.264 is Magic (2016)
#167Re: H.264 is Magic (2016)
#168Two questions for the compression gurus here. Suppose you have a bunch of raw video. You take extracts of it and put them together to make a movie, M1. You make an H.264 encoded copy of that. Let's call it C1. You then make a new cut of your movie, M2, which is mostly the same footage as M1 except that you've shortened a few scenes and lengthened others. You make an H.264 encoded copy of that. Call this C1. When maki…
> Question: are there any encoders that when encoding M2 to produce C2 can be given M1 and C1 as references using them to adjust I-frame spacing so as make as many C2 I-frames as possible match C1 I-frames?
I suspect if you were to encode both files with x264 with identical settings, in crf mode, with vbv disabled and keyint=0 (unlimited keyframe length), its scene detection should place I-frames in the same places (that is, on scene cuts, not on the timeline). Maybe some scenecut tuning would be necessary.
> That would allow C2 to be stored efficiently as a binary diff from C1. This could be handy if C1 and C2 needed to be checked into a version control system, or you needed to distribute C2 over a low bandwidth or expensive link to someone who already had C1.
I'm not aware of any automated way to do that, but you can do a similar thing manually using mkv's ordered chapters. You first compress the original cut, then you compress any additional scenes and insert them where you need. For example, you can make a mkv file for a theatrical cut of a movie, and then make a separate file for a director's cut that is only as big as the additional scenes are, since it uses the theatrical cut file for the common scenes.
Re: H.264 is Magic (2016)
#169I stopped reading when the author started to do comparisons with PNG. PNG or alternatives should only be used when the errors created by lossy compression is too visible. With that said. Improvements of audio and video compression over the last 25 years are very impressive and have changed how the world works in several areas.
Re: H.264 is Magic (2016)
#170Earlier quoted context omitted.
Yeah, in this era of mobile device dominance i think hardware decoding is key. Suspect Apple will add it then suddenly the Android SoC folks will suddenly consider it a priority and not before.
Apple won't add it; they traditionally ignore free codecs, and even if they implement them, it is so limited, so it is usable only in the narrow situation, where it is required (see Opus, for example). On the PC side, decoding is supported by Intel (since Tiger Lake), Nvidia (since 30x0) and AMD (since RDNA2). On the mobile side, it is supported by bunch of mobile chip vendors, like Mediatek or Samsung; so you can ha…