Faster Audio Decoding/Encoding Coming To Ogg & FLAC

[ssokolow]

This could be a great companion to youtube-dl. Do you have a git repo with it?

Not yet. I'm still gearing up to do it. (Though using it with youtube-dl is actually my intention.)

The old Python-OpenCV script I hacked together is available at https://gist.github.com/ssokolow/ac3...7f37e66f3c9a40 if you want to poke at it, but it was my first OpenCV code and written in a rush, so it's not ideal.

I can make a note to let you know once I have something if you'd like.

[caligula]

Some of us are programmers who want to do things like batch-fingerprinting audio as part of custom cataloguing or ad-skipping solutions. (The latter is one I'm actually gearing up for, because one of the YouTube channels I follow no longer puts an OpenCV-matchable title card before the grating, carnival barker-y "Hey, subscribe!" stock clip they duplicate onto the end of every single video.)

...and I'm still on a dual-core Athlon II X2 270 because I only upgrade my CPU when the CPU, mobo, or RAM die. This change is certainly very welcome.

So how much would it work faster in terms of wall clock time, if the optimization improved decoding by 5 to 10%?

[adila01]

Patch author here. Feel free to ask questions.


Yes, the patches are architecture independent. However, I did not measure the speedup on ARM yet.


It's open source, but under a proprietary, not OSI approved license.

Thank you for this amazing enhancement!

[andreano]

You linked a 90 minute video

Sorry, it's at 28:45.

We started out at 20 frames per minute, and now we are at … well, very slow.

[ssokolow]

So how much would it work faster in terms of wall clock time, if the optimization improved decoding by 5 to 10%?

I won't be able to give you a good answer until I've finished researching the most efficient options available to me for audio fingerprinting and which tricks for pre-filtering what gets fingerprinted and compared are applicable to my use case.

I just know from past experience that decoding/decompressing is worth optimizing when doing bulk fingerprinting of images, audio, or video.

[timofonic]

Not yet. I'm still gearing up to do it. (Though using it with youtube-dl is actually my intention.)

The old Python-OpenCV script I hacked together is available at https://gist.github.com/ssokolow/ac3...7f37e66f3c9a40 if you want to poke at it, but it was my first OpenCV code and written in a rush, so it's not ideal.

I can make a note to let you know once I have something if you'd like.

Yes, of course!

PS: You can contact mpv community if you wish too, I'm just a mere user of the software but I love it (the sucessor of all mplayer forks, modernized). There are great people there and many like get innovative, libmpv intention is to be used with any other project too. They are at IRC too #mpv at irc.freenode.net

[ssokolow]

Yes, of course!

PS: You can contact mpv community if you wish too, I'm just a mere user of the software but I love it (the sucessor of all mplayer forks, modernized). There are great people there and many like get innovative, libmpv intention is to be used with any other project too. They are at IRC too #mpv at irc.freenode.net

I'm actually already using Python bindings for libmpv in one of my other scripts as a means to get some custom behaviour out of my preferred video player setup.

(And sorry for the delayed reply. Messy few days.)

[coder]

Good to be able to save some cycles on the audio part when the we get a new video standard for webRTC that encodes at 0.25 - 0.5 frames per minute.

...because all programmers should work on your highest priority.

But I think you have a point: audio (de-)compression does not impose significant stress on contemporary CPUs. Work is much better invested in optimizing the latest and greatest video codecs.

...because yours is the only use case that matters.

As ssokolow pointed out, there are reasons to want faster-than-realtime audio compression & decompression. For instance, an online audio repository that's stored in a lossless format and supports realtime streaming via different compression formats & bitrates will have to transcode on-the-fly. In such cases, faster decoding means lower server requirements, better energy efficiency, and cost-savings.

More importantly is probably non-realtime audio analysis by deep learning and other means. In this case, FLAC is useful not only as a way to compress audio data, but other types of uniformly-sampled, high-precision time series data.

[dwagner]

For instance, an online audio repository that's stored in a lossless format and supports realtime streaming via different compression formats & bitrates will have to transcode on-the-fly.

Once per song and format. Caching and storing derived formats as they are used is the much more obvious approach, given today's cheap storage, and won't cause significant CPU load in the long run.

[coder]

Once per song and format. Caching and storing derived formats as they are used is the much more obvious approach, given today's cheap storage, and won't cause significant CPU load in the long run.

You ignore that connection speed could dictate dynamic bitrate adjustment. But that was a hypothetical example.

A more relevant example is probably for training deep learning networks, which must be done repeatedly. With the use of accelerators, the cost of merely feeding in the data suddenly becomes relevant. To optimize storage bandwidth, compression is probably desirable.