Alliance for Open Media codecs [Archive] - Page 30

IgorC

11th February 2019, 13:32

Igor, you're arguing with 2 technical professionals who are key members of their respective Tier 1 companies... Amazon and Disney. .
That's really good. Then they should know that 200-300 kbps is a far from reality.
I have provided a study with real numbers of world bandwidth and I'm myself network specialist who has an information what's going on with ISPs and how xHE-AAC (ultra low bitrate audio format) will change very little if anything as it has already happened with MPEG Surround (standard since 2007). All those professionals were very positive how this MPEG Surround will save bandwidth to million people. Has it?

Phanton_13

11th February 2019, 16:01

I don't think that 200-300 kbps is that far from reality, specially in a mobile phone as even through my phone speed is typilally +30mbps is not thar rare the occasion when it drops down to 1000-500 kbps, basicallly drops in signal quality or being in a overpopulate cell. On the other part more than bandwidth what it save is data usage and as most mobile connections are billed by data usage not by bandwidth this has economical advantage for the user.

I also admit that xhe-aac is mainly a letdown that have seen no real adoption beyond DRM and is understandable for more than one reason.

TomV

11th February 2019, 19:23

Again, the people who run worldwide video streaming services know exactly how many customers are bandwidth limited, and they know which of the many Adaptive Bit Rate renditions (tiers) their customers are streaming. When customers can't sustain higher bit rates, the client player application requests the lowest bit rate rendition from the server. The video service provider has logs of all of this activity, so they know what % of streams are at the lowest bit rate tier, and where/when this happens. Some have tiers as low as 100 kbps (including about 10 kbps for mono audio). With HEVC, this tier is watchable, even if the picture size is reduced to 320x240. It's not possible at all with AVC. For those in rural parts of the world where the best they can get is a 2G mobile connection, they're thrilled to get super-low bit rate video, as long as they can tell what's happening, and they don't have to wait for buffering too often. It sure beats what they used to have, which was no video, or extremely long buffering times.

IgorC

11th February 2019, 19:53

Again, the people who run worldwide video streaming services know exactly how many customers are bandwidth limited,
So do network engineers know (in fact even better)

Again, where is xHE-AAC adoption? It's as old as HEVC. HEVC was adopted, xHE-AAC wasn't.
If ultra low bitrates are so important why nobody hurries to adopt this codec?

Name me just one relatively large broadcasting company who has adopted it.
Name me just one developer team (not Fraunhofer themselves) who actually developing xHE-AAC encoder in this moment.

Can You do it?
Because if You can't I don't see a reason to keep this dicussion.

The video service provider has logs of all of this activity, so they know what % of streams are at the lowest bit rate tier, and where/when this happens. Some have tiers as low as 100 kbps... (including about 10 kbps for mono audio).
Are You sure this number isn't very small? 0.1%, 1-2% ?
Can You present any statistics?

Nintendo Maniac 64

11th February 2019, 20:43

So um, as someone on the outside, I've got to ask - outside of DRM and satisfying "not invented here" syndrome, what benefit does xHE-AAC provide over something like Opus?

benwaggoner

11th February 2019, 21:25

So um, as someone on the outside, I've got to ask - outside of DRM and satisfying "not invented here" syndrome, what benefit does xHE-AAC provide over something like Opus?
It supposedly offers somewhat better quality at very low bitrates. I've not seen a detailed double-blind listening test to validate that, though.

I think xHE-AAC is going to become more broadly supported on platforms, out of momentum. AAC licensees now get access to xHE-AAC for free so it's a trivial effort to roll in xHE-AAC support with platforms updates. And use of AAC in MPEG-4 streams is broadly understood and implemented. Opus does have a mapping, but I've not seem much use of it. MPEG-4 as a file format is more dominant than H.264 was; the Matroska based container formats aren't a significant player for commercially distributed content.

The biggest recent news is that Android Pie has xHE-AAC built in.

xHE-AAC also offers gapless switching between bitrates without having to do overlap decoding. Does Opus support that. I consider this a significant advantage of xHE-AAC over HE v1/v2 and LC, which can only do gapless switching within v1 or v2, but not between. xHE-AAC can switch from very low bitrates to very high quality, which wasn't feasible before.

And don't knock how critical DRM is for premium content. It's a Very Big Deal. And there are SoC reasons why mixing encrypted video and unencrypted audio can be problematic.

Blue_MiSfit

11th February 2019, 21:48

^ DRM is absolutely positively mandatory - no two ways about it. You simply will not get the rights to distribute content if you don't have approved DRM implementations, and this is extremely specific e.g hardware implementations of PlayReady, Widevine with progressive restrictions to unlock HD or UHD content.

I don't love DRM, but it's just table stakes when you're delivering premium content. There's no way around it, so the best we can do is make it as unobtrusive as possible!

Regarding the 200 - 300 Kbps scenario - another use case would be rural customers with satellite or very poor cell service. I grew up in a very small town and many of my friends live outside the city limits where there simply is no broadband. Not even DSL, though you could maybe get an ISDN or T1 line if you're a masochist :D

You might get one bar of LTE (or two if you stand in exactly the right place), and you're sharing this one solitary tower with your neighbors, so during peak times you're lucky to get 1 Mbps, assuming you're not over your data cap, at which point you drop down to under 500 Kbps. Satellite can be fast, but generally is very over-sold in these areas, and cannot keep up with demand during peak times. It also has extreme data caps, and the throttled speed is extremely slow.

Anyway - hoping we can get back on topic - AOM codec discussion :)

Maybe viewing through the ultra low bitrate lens, has anyone done very low bitrate 2 pass VBR tests with AV1? I'd be interested to see how that might fit into the above scenario regarding downloading content for offline playback. This is a neat scenario because you get the bonus of being able to skip all the compromises one must make when encoding for adaptive bitrate delivery and can use very large buffers (vbv-maxrate + vbv-bufsize) and longer adaptive keyframe intervals.

benwaggoner

11th February 2019, 22:29

^ DRM is absolutely positively mandatory - no two ways about it. You simply will not get the rights to distribute content if you don't have approved DRM implementations, and this is extremely specific e.g hardware implementations of PlayReady, Widevine with progressive restrictions to unlock HD or UHD content.Yeah. It is table stakes for anything that isn't piracy or user-generated content. If AV1 matters outside of social networks, it'll be because it gets 1st class DRM support, which requires HW decoders and other deep SoC integration. Weird little SoC DRM design decisions have kept a lot of amazing things from happening.

Maybe viewing through the ultra low bitrate lens, has anyone done very low bitrate 2 pass VBR tests with AV1? I'd be interested to see how that might fit into the above scenario regarding downloading content for offline playback. This is a neat scenario because you get the bonus of being able to skip all the compromises one must make when encoding for adaptive bitrate delivery and can use very large buffers (vbv-maxrate + vbv-bufsize) and longer adaptive keyframe intervals.
It's not so much a long buffer window, but having a maxrate>>bitrate. Maxrate and bufsize can be kept at the profile @ level maximums while ABR can be way way lower. Doing maximum 10 sec Open GOP is pretty reasonable.

I worry that AV1's interframe CABAC dependencies will impair random access enough to make the practical maximum GOP duration a lot smaller. Some of that could probably be addressed via encoder tweaks, at the loss of a little efficiency.

Phanton_13

11th February 2019, 22:37

I think that I misled wen I reference DRM, I was referencing to Digital Radio Mondiale where xhe-aac is one of the codecs used.

The lowest that I went with AV1 is q50 for sd anime and is surprisingly watchable (resulting in about 100 to 200 kbps of video bitrate, the audio was opus at 32kbps). Definitely CDEF is a great tool. Around 30MB per episode... I wish that this quality-bitrate ratio was available 20 years ago.

IgorC

12th February 2019, 00:24

So um, as someone on the outside, I've got to ask - outside of DRM and satisfying "not invented here" syndrome, what benefit does xHE-AAC provide over something like Opus?
Both Opus and xHE-AAC are hybrid music/speech formats and have essentially same quality. xHE-AAC is slightly better than Opus at 16-32 kbps, quality at 48-64 kbps is the same for both and Opus is slightly better than all family LC-AAC/HE-AAC/xHE-AAC at higher bitrates.

Many people try to market a feature of xHE-AAC as switching between bitrates as something outstanding and so on. But in reality it's not a premium feature and Opus supports it from the very beginning. More here https://wiki.hydrogenaud.io/index.php?title=Opus

Also xHE-AAC is a high delay codec and it's not suitable for real time communications like VOIP calls etc. Company who wants real time communication should also adopt low-delay xHE-AAC fork (EVS). And if You want stereo EVS then this is just another extension. So we got mutltiple codecs and/or extensions:
1.xHE-AAC
2.low delay EVS
3.EVS stereo extension (aka IVAS)
...
It's sort of LC-AAC, HE-AAC, HE-AACv2, Low delay AAC (LD-AAC), Enhanced LD-AAC ( low delay HE-AAC) aka ELD-AAC, ELD-AAC v2 (HE-AACv2 low delay), xHE-AAC, EVS ( low delay xHE-AAC), IVAS (low delay stereo xHE-AAC)...

While Opus is just one single format for everything: high-,low-delay, stereo and multichannel codec.
So I'm not surprised that Opus is popular in internet community while xHE-AAC support is non-existent. Android 9 will get an xHE-AAC decoder but there is still no any encoder

Tommy Carrot

12th February 2019, 00:58

Maybe viewing through the ultra low bitrate lens, has anyone done very low bitrate 2 pass VBR tests with AV1? I'd be interested to see how that might fit into the above scenario regarding downloading content for offline playback.

Very low bitrate is definitely the strong point of AV1 (more precisely aomenc). At around crf 28-30 compression rates, it's starting to get better than x265, and the lower the bitrate, the bigger the advantage. XVC, and especially VVC are still better though, the VVC reference encoder is seriously amazing at ultra low bitrate scenarios.

benwaggoner

12th February 2019, 01:21

Very low bitrate is definitely the strong point of AV1 (more precisely aomenc). At around crf 28-30 compression rates, it's starting to get better than x265, and the lower the bitrate, the bigger the advantage. XVC, and especially VVC are still better though, the VVC reference encoder is seriously amazing at ultra low bitrate scenarios.
Ooh, do you have any examples or command lines for the >x265 for very low bitrates? Low bitrate, low resolution video enables MUCH faster encode/evaluate/reencode cycles and would be a great place to evaluate AV1's potential strengths.

Tommy Carrot

12th February 2019, 01:41

Ooh, do you have any examples or command lines for the >x265 for very low bitrates? Low bitrate, low resolution video enables MUCH faster encode/evaluate/reencode cycles and would be a great place to evaluate AV1's potential strengths.
Nothing special, i pretty much use the default settings.
aomenc --end-usage=q --cq-level=xx --cpu-used=1 --kf-max-dist=250 -v -o av1.webm test.y4m
I haven't tried 2-pass bitrate mode though, only CQ mode with using the quantizer with the closest bitrate.

Mr.Radar

14th February 2019, 21:17

I think that I misled wen I reference DRM, I was referencing to Digital Radio Mondiale where xhe-aac is one of the codecs used.

For those who are unaware, Digital Radio Mondiale is the digital broadcasting standard used on the shortware radio bands. Due to the narrow bandwidth of shortwave broadcast channels and the high amount of error correction required to avoid dropouts the usable bitrates are very low. Here is a 2017 comparison between xHE-AAC and Opus at those bitrates (https://www.youtube.com/watch?v=sEUwScTX-R4). More recent versions of libopus should produce significantly more competitive results in the speech-focused samples (libopus 1.3 enabled wideband audio down to 9 kbps) but on music samples xHE-AAC would probably retain the edge since Opus at very low bitrates is effectively operating mostly as a speech codec in its SILK mode.

Mr_Khyron

15th February 2019, 00:28

https://github.com/OpenVisualCloud/SVT-AV1/pull/55

Over 50% reduction in memory requirements

:)

soresu

15th February 2019, 08:45

It says "low core count (e.g. 4-core machines)" though, does that mean it doesnt apply at all to higher core counts, or that they alreeady have a similar optimisation implemented or in the pipe?

nevcairiel

15th February 2019, 09:23

It probably means that memory usage didn't scale properly to different core counts. The more cores you run, the more memory its going to need, that is not unexpected from any encoder. :)

Mr_Khyron

16th February 2019, 01:42

https://phoronix.com/scan.php?page=news_item&px=SVT-AV1-Speed-Progress

It was just a few weeks ago that Intel open-sourced the SVT-AV1 project as a CPU-based AV1 video encoder. In the short time since publishing it, there's already been some significant performance improvements.

Since the start of the month, SVT-AV1 has added multi-threaded CDEF search, more AVX optimizations, and other improvements to this fast evolving AV1 encoder. With having updated the test profile against the latest state as of today, here's a quick look at the performance of this Intel open-source AV1 video encoder.

Nintendo Maniac 64

16th February 2019, 03:14

"low core count (e.g. 4-core machines)"

That's certainly amusing considering that Intel seemed to love branding quad cores as i7 up until recently. :p

Speaking of quad core i7 CPUs...

https://phoronix.com/scan.php?page=news_item&px=SVT-AV1-Speed-Progress

I'm going to go out on a limb and guess that, on the SVT-AV1 v2019-02-15 results, the lack of performance delta seen between the i7-7740X and Ryzen 2700X is due to the former's considerably faster AVX2 implementation even though the Ryzen has twice as many cores and threads as the i7?

Selur

16th February 2019, 07:38

btw. https://ci.appveyor.com/project/OpenVisualCloud/SVT-AV1/build/artifacts offers Windows binaries of the stv-av1 encoder (SvtAv1EncApp.exe and SvtAv1EncApp.dll are needed)

Blue_MiSfit

16th February 2019, 21:33

Very cool. I'm playing with this now.

Default settings are quite fast - it did 12 fps for 480p on my i7 7700k with 50% CPU usage and 1.2 GB RAM usage.

Here's the basic usage guide:
https://github.com/OpenVisualCloud/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md

A sample command:
.\SvtAv1EncApp.exe -i .\beauty_480p.yuv -b out.ivf -w 848 -h 480 -fps 24

Yes, I had to encode at 848x480 and not 854 - comically this encoder requires mod 8 input :)

Results aren't too bad - the default CQ 50 setting produced a 623 Kbps file that looks marginally okay, and CQ 40 produced a 1.2 Mbps file that looks a lot better. There are some odd artifacts, almost like the edges of objects wiggle a bit every other frame.

However, I'm getting very jerky playback for some reason. I've tried a LAV nightly build in MPC-HC, latest VLC, and ffplay, and they all show the issue. I confirmed my input YUV is 24 fps and the output webm is 24 fps. When I step through it frame by frame it's all there, but for some reason it's jerky on playback. I don't recall seeing this with aomenc encodes, and the decoder isn't close to maxing out one core, so I'm not sure what's up with that...

tnti

18th February 2019, 02:20

TD-Linux

21st February 2019, 23:16

I worry that AV1's interframe CABAC dependencies will impair random access enough to make the practical maximum GOP duration a lot smaller. Some of that could probably be addressed via encoder tweaks, at the loss of a little efficiency.

You don't need to worry - AV1 probability dependencies can only come from one of the reference frames, so it doesn't place any additional impairment on seekability.

(also note that CABAC is a misnomer, as it's not binary. The spec doesn't give it an acronym, but dav1d uses MSAC).

Beelzebubu

22nd February 2019, 03:01

You don't need to worry - AV1 probability dependencies can only come from one of the reference frames, so it doesn't place any additional impairment on seekability.

I think his concern that a decoder (or a stupid player, which is 99.9% of them) don't know this. A good container format (like mp4) can represent the reference structure in its atoms, and then a good decoder + good container + good encoder can do the right thing. But if any one of them fails, you'll have a worse seeking experience if you want to do frame-exact user experience. It's up to all devs to make sure that doesn't happen, and like I said, this is multi-factorial so it's easy to forget and screw up.

benwaggoner

22nd February 2019, 21:41

I think his concern that a decoder (or a stupid player, which is 99.9% of them) don't know this. A good container format (like mp4) can represent the reference structure in its atoms, and then a good decoder + good container + good encoder can do the right thing. But if any one of them fails, you'll have a worse seeking experience if you want to do frame-exact user experience. It's up to all devs to make sure that doesn't happen, and like I said, this is multi-factorial so it's easy to forget and screw up.
Yeah, the goal is for the decoder to determine the minimum sequence of frames required to decode a particular frame. With a IbbbBbbbPbbbBbbbPbbbbBbbbI kind of structure, decoding the last "b" frame in an Open GOP should require just six frames (IPPBIb) in decode order typically. But that requires the reference list because sometimes a b could reference two B frames back and things like that. With multiple reference frames it's impossible to reliably know the hierarchy without knowing what each frame references.

And there are patterns that can be spec-legal but that existing encoders might not do. And then better encoders add those to improve quality.

TD-Linux

22nd February 2019, 22:37

Yeah, the goal is for the decoder to determine the minimum sequence of frames required to decode a particular frame. With a IbbbBbbbPbbbBbbbPbbbbBbbbI kind of structure, decoding the last "b" frame in an Open GOP should require just six frames (IPPBIb) in decode order typically. But that requires the reference list because sometimes a b could reference two B frames back and things like that. With multiple reference frames it's impossible to reliably know the hierarchy without knowing what each frame references.

Yeah, if you want to do that you'll need a reference list parser. But that's been true for a very long time - even x264 produces streams that require you to do this.

But regardless, whatever structure you pick, the CDFs always follow that same structure, so they are "free" from a seekability point of view.

benwaggoner

23rd February 2019, 00:31

Yeah, if you want to do that you'll need a reference list parser. But that's been true for a very long time - even x264 produces streams that require you to do this.

But regardless, whatever structure you pick, the CDFs always follow that same structure, so they are "free" from a seekability point of view.
That's good news. I had heard suggestions otherwise.

sneaker_ger

24th February 2019, 23:29

Seems like dav1d is now like 40% faster than libaom on my i5-2500K (no AVX2). And there's a pull request for additional SSSE3 optimizations with like another 50% speedup.

https://code.videolan.org/videolan/dav1d/merge_requests/599#note_29705

nevcairiel

25th February 2019, 00:06

Once the CDEF patch is merged, it should definitely beat AOM in nearly all situations, in 8-bit decoding anyway. 10-bit/12-bit hasn't been worked on much yet, performance wise.

sneaker_ger

26th February 2019, 15:32

CDEF patch is merged now.

nevcairiel

26th February 2019, 15:53

Here is an up-to-date performance comparison of aomdec vs dav1d (I believe some of the tests are still running as I write this)
https://docs.google.com/spreadsheets/d/1rkPMHgy7cXEsT9KeYF-NVZQNiEGEkvrLnLo2FaLWiwA/edit#gid=1835354908

Single-Threading, it still loses in some cases on SSE 4.1 CPUs (aom implements mostly SSE4.1 for pre-AVX), but Multi-Threading it makes up for that.
One missing part is prep_8tap (https://code.videolan.org/videolan/dav1d/merge_requests/604), which can have a decent impact.

Their goal for releasing dav1d 0.2.0 is to be faster then aomdec in 8-bit in all targeted scenarios.

sneaker_ger

26th February 2019, 17:03

nevcairiel

26th February 2019, 17:27

Years ago we told people they would never be able to watch new codecs on a phone if it didn't have ASIC for the codec ...

They really still shouldn't want to/have to, since it'll make the phone hot and the battery empty. :)

benwaggoner

26th February 2019, 18:00

There are some user benchmarks on an iPhone (https://code.videolan.org/videolan/dav1d/issues/15#note_29792) with crazy results.

https://i.imgur.com/tqR6ttB.png

1080p with 46 to 74 fps. Years ago we told people they would never be able to watch new codecs on a phone if it didn't have ASIC for the codec ...

Fun way to amaze yourself - figure out how long ago you first got a computer that was more powerful than your current phone (benchmark/metric of your choice). A modern iPhone has lots of fast cores with SIMD instructions and a pretty darn powerful GPU. It would smoke any hot gaming rig of 10 years ago, and a typical laptop of 5 years ago.

Generally each new codec generation aims to be more than twice as complex to decode as the prior generation. With Moore’s Law gains, computing devices get a LOT more than 2x faster in that time.

The bigger challenge with software codecs is getting them integrated into hardware DRM required to play premium content above 480p.

It’s exciting to see these perf gains with AV1. Hopefully we’ll get to a reasonably “done” version of dav1d later this year so we can ballpark decoder requirements for AV1 versus other codecs. I’m particularly interested in how much parallelism is possible. VP9 was nearly single-threaded, which was problematic

A big question for AV1’s viability is how many extra transistors (and thus how much extra die size and SoC cost) full HW decode will take. I’ve not heard any details from anyone who has taped out an implementation yet. Anyone else?

NikosD

26th February 2019, 18:16

Single-Threading, it still loses in some cases on SSE 4.1 CPUs (aom implements mostly SSE4.1 for pre-AVX), but Multi-Threading it makes up for that. Unfortunately, in single-threading mode, dav1d looses even using SSSE3 in Dua Lipa clip.

It needs further optimization for pre-AVX2 SIMD, but the multi-threading performance especially for AVX2 is impressive.

EwoutH

26th February 2019, 20:10

@nevcairiel You're fast :)

That bench included !604 (prep_8tap), so this is most likely the performance as it's going to look like at 0.2.0 release. Not all prep_8tap functions are converted to ssse3 yet, so there is potentially another 5-12% speedup possible for ssse3, highly depending on content.

iwod

28th February 2019, 08:34

https://aomediacodec.github.io/av1-avif/

v1.0.0, 19 February 2019 but page still says it is a draft.

That is the Image format AVIF you are looking at. Not sure if that is what you want.

Q3CPMA

28th February 2019, 10:45

Personally, I find AVIF a lot more interesting than AV1 seeing as JPEG is technologically much more obsolete than AVC (if you don't consider 4K, of course). I just hope they don't force chroma subsampling like on webp.

hajj_3

28th February 2019, 13:01

Rumbah

28th February 2019, 22:05

Jpeg XL will be ratified later this year, that should be much nicer than AVIF.
Will it be royalty free?

Zebulon84

1st March 2019, 05:40

In this document (Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)) (https://jpeg.org/downloads/jpegxl/jpegxl-cfp.pdf) issued in last April, it is stated page 3: This new JPEG activity aims to develop a new image coding standard that provides state-of-the-art image compression performance, and that addresses shortcomings in current standards. To encourage widespread adoption, an important goal for this standard is to support a royalty-free baseline
So probably partially. But will il be enough to have wider adoption than previous standards (JPEG 2000, JPEG XR...) ?

mzso

1st March 2019, 23:27

They really still shouldn't want to/have to, since it'll make the phone hot and the battery empty. :)

There's a solution. :)
https://cdn.vox-cdn.com/thumbor/1HzHTQhjVUrhVDHQC8k1hdM9HPg=/0x0:2040x1360/1200x800/filters:focal(913x433:1239x759)/cdn.vox-cdn.com/uploads/chorus_image/image/63124099/energizer_unit_vsavov7.0.jpg

Jpeg XL will be ratified later this year, that should be much nicer than AVIF.
Yay! Two more formats to sink into obscurity...

hajj_3

2nd March 2019, 02:08

It looks like the dav1d decoder v0.2.0 has been released: https://code.videolan.org/videolan/dav1d/commit/0e55d462957323119b9e90b203f534b9fe6f169a

marcomsousa

2nd March 2019, 07:31

It looks like the dav1d decoder v0.2.0 has been released: https://code.videolan.org/videolan/dav1d/commit/0e55d462957323119b9e90b203f534b9fe6f169a

Isn't release yet, just a change for the next release.
Wait until there is a 0.2.0 tag and/or release.
https://code.videolan.org/videolan/dav1d/tags

marcomsousa

2nd March 2019, 08:07

The version has already bumped to 0.2.0 (https://code.videolan.org/videolan/dav1d/commit/e811c4767d0c698fc674e9603e1e63d15acff16e)

Are you sure that 0.2.0 is finished?
There isn't a tag neither a release version.

https://code.videolan.org/videolan/dav1d/tags
https://code.videolan.org/videolan/dav1d/releases

That change was in 25/02 (https://code.videolan.org/videolan/dav1d/commit/e811c4767d0c698fc674e9603e1e63d15acff16e) and the other was 13 hours ago (https://code.videolan.org/videolan/dav1d/commit/0e55d462957323119b9e90b203f534b9fe6f169a).

I think that the final version of 0.2.0 isn't release yet, but it's seems that will be release in the follow hours/days.

But I confirm that this is a litle strange. They have a version without being finished. That it seems that is the way before, they don't use -dev neither -snapshot.

nevcairiel

2nd March 2019, 09:14

The release is scheduled for Monday currently. The version bump means nothing, its only in preparation for the release, only tags really matter. You would typically do that a few days earlier to ensure everything comes out as expected.
Its not really that strange either, you guys are just overthinking it.

Wolfberry

2nd March 2019, 09:46

The version bump means nothing.

Just like this commit (https://code.videolan.org/videolan/dav1d/commit/0c173fd19326435e575d884b6f40ca135aed1885)

It seems like 0.1.1 is just a transition from 0.1.0 to 0.2.0 and will never get released. But I can be wrong, anyway.

nevcairiel

2nd March 2019, 10:35

0.1.1 was never released indeed, the changelog entries being created for it have been recycled into the 0.2.0 changelog.

sneaker_ger

2nd March 2019, 12:03

The version has already bumped to 0.2.0 (https://code.videolan.org/videolan/dav1d/commit/e811c4767d0c698fc674e9603e1e63d15acff16e)

libaom 1.0.0-1402-g442f429de
libdav1d 0.2.0-493155af
(https://drive.google.com/open?id=1TrR10EL8nDD4WO2nHhHvaSKVhNaWTmcC)
Now dav1d is like 55% faster on i5-2500K (AVX, no AVX2) than libaom on Blackmagic Pocket Cinema "Nature" sample 1080p24. :cool: