Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th February 2020, 16:21   #2101  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 136
Quote:
Originally Posted by dapperdan View Post
I think Instagram were already shipping a VP9 software decoder on Android I don't think they were even using the fast ffmpeg decoder, just libaom.
Ouch, that's just being bloody minded to user battery life that is.

Here's the gitlab issue link for dav1d NEON, 4 opts for 16bpc already merged, 2 more lined up it seems.

Last edited by soresu; 7th February 2020 at 16:29.
soresu is offline   Reply With Quote
Old 7th February 2020, 18:20   #2102  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,102
Quote:
Originally Posted by Blue_MiSfit View Post
Probably wider support for fMP4 on various platforms. What benefits does WebM offer over fMP4 for ABR streaming via DASH?
Exactly. There's SO much stuff for MP4 as a container format, and such a huge infrastructure around it. WebM just doesn't have the same ecosystem or any particular standout features.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 7th February 2020, 18:25   #2103  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,102
Quote:
Originally Posted by birdie View Post
This announcement makes no sense: I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.
Has anyone looked at what the power draw of AV1 decode looks like on different devices/platforms. Like using a Kill-a-watt on a charged laptop or a desktop and comparing AV1 playback versus a HW decoded bitstream?

Obviously there is a lot of other power draw happening for the screen, UX, system. But getting a delta would be helpful.

Back in the day with Silverlight, I remember finding the HW decoder could save 20 watts over the SW decoder on a laptop of the era. Obviously with much less powerful CPUs than we have now, but also with a much less complex decoder (H.264 in this case).

"How many hours of playback" is an important metric for premium video content players.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 7th February 2020, 20:55   #2104  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 443
Quote:
Originally Posted by benwaggoner View Post
Exactly. There's SO much stuff for MP4 as a container format, and such a huge infrastructure around it. WebM just doesn't have the same ecosystem or any particular standout features.
Opus does not use the MP4 container on YouTube though and does in fact use WebM.


Nevertheless, follow-up question.

As someone that has no concept of what goes into the software back-end required for delivering video, does it in fact still improve the ease of implementation to use a container that is already widely used if it's a completely new codec anyway?
__________________
____HTPC____  | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.6GHz Pentium G3258 (2c/2t Haswell)
Radeon HD5870  | Intel iGPU      
2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600       

Win7 x64
Nintendo Maniac 64 is offline   Reply With Quote
Old 7th February 2020, 22:20   #2105  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,628
Yes, it does, because you still have to package it (and encrypt it, often). There's often an established ecosystem to do this in a way that meets business requirements. Sometimes it's even done dynamically. Adding support for a new codec in that tooling is likely easier than having to implement support for a whole new container format as well.

Same thing on the clients, honestly. I don't see anything about WebM that adds value to the adaptive streaming use case, but I may be missing something.
Blue_MiSfit is offline   Reply With Quote
Old 8th February 2020, 01:19   #2106  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,102
Quote:
Originally Posted by Blue_MiSfit View Post
Same thing on the clients, honestly. I don't see anything about WebM that adds value to the adaptive streaming use case, but I may be missing something.
And media format code is pretty low level, so needs to get lots of fuzz testing and security checks. People remember how often big security bugs (Stagefright for example) come from media playback stacks.

So there's little desire to take on new code for such mission critical task.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th February 2020, 08:35   #2107  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 443
So yeah uh...then why the heck are they using WebM for Opus? I mean, isn't splitting the video and audio between separate MP4 and WebM containers even worse than just having both in a WebM container let alone both in an MP4 container?
__________________
____HTPC____  | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.6GHz Pentium G3258 (2c/2t Haswell)
Radeon HD5870  | Intel iGPU      
2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600       

Win7 x64
Nintendo Maniac 64 is offline   Reply With Quote
Old 8th February 2020, 10:01   #2108  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,465
Quote:
Originally Posted by Nintendo Maniac 64 View Post
So yeah uh...then why the heck are they using WebM for Opus? I mean, isn't splitting the video and audio between separate MP4 and WebM containers even worse than just having both in a WebM container let alone both in an MP4 container?
The whole point of DASH is that you can cherrypick your favorite video and audio, and swap in alternates at any time depending on bandwidth. You can swap languages without having to download all languages. The container they're delivered in doesn't matter, but they still need something. That necessitates that every stream is packaged separately, but fortunately, WebM/MKV and MP4 are very low-overhead containers. The penalty is well under 1% for most videos.

I think there's a combination of institutional inertia in keeping Opus on WebM instead of tearing down the whole stack, and that no one wants to be the guy who accidentally broke YouTube while changing it over.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.

Last edited by foxyshadis; 8th February 2020 at 10:04.
foxyshadis is offline   Reply With Quote
Old 8th February 2020, 12:47   #2109  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 86
Quote:
Originally Posted by Nintendo Maniac 64 View Post
It is worth noting however that sometimes I notice that a rare DASH WebM video will instead be downloaded into individual chunks via youtube-dl which are then reassembled into a single file as it downloads. These are notable in that trying to watch the reassembled albeit still downloading video gives you the exact same behavior as the DASH MP4 videos.

Try passing --youtube-skip-dash-manifest to youtube-dl.
__________________
saldl: a command-line downloader optimized for speed and early preview.
MoSal is offline   Reply With Quote
Old 8th February 2020, 12:54   #2110  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 86
Quote:
Quote:
I think Instagram were already shipping a VP9 software decoder on Android I don't think they were even using the fast ffmpeg decoder, just libaom.
Ouch, that's just being bloody minded to user battery life that is.
Not really. libvpx (not libaom) has good NEON optimizations and performs much better than ffvp9 on ARM.
__________________
saldl: a command-line downloader optimized for speed and early preview.
MoSal is offline   Reply With Quote
Old 8th February 2020, 16:58   #2111  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 927
rav1e 0.3.0 has been released: https://github.com/xiph/rav1e/releases/tag/v0.3.0
hajj_3 is offline   Reply With Quote
Old 8th February 2020, 19:33   #2112  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 136
Quote:
Originally Posted by MoSal View Post
Not really. libvpx (not libaom) has good NEON optimizations and performs much better than ffvp9 on ARM.
Ah my mistake, I took it as a given the ff**** decoders were usually better optimised.

Also didn't realise that libvpx had another incremental version in december - v1.8.2 "Pekin Duck".

Does libaom have official version names/numbers yet?
soresu is offline   Reply With Quote
Old 8th February 2020, 22:39   #2113  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 443
dav1d v0.5.0 performance on Ubuntu Linux 20.04 LTS snapshot with the new 64core/128thread Threadripper 3990X: https://www.phoronix.com/scan.php?pa...er-linux&num=2
__________________
____HTPC____  | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.6GHz Pentium G3258 (2c/2t Haswell)
Radeon HD5870  | Intel iGPU      
2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600       

Win7 x64
Nintendo Maniac 64 is offline   Reply With Quote
Old 9th February 2020, 18:23   #2114  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 50
Does anyone know why libaom and vmaf are not compatible on an arch linux system?

Quote:
cmake ../aom -DCONFIG_TUNE_VMAF=1

Quote:
make
home/jakob/Downloads/aom/aom_dsp/vmaf.c:13:10: fatal error: libvmaf/libvmaf.h: No such file or directory
13 | #include <libvmaf/libvmaf.h>
Quote:
pacman -Ql vmaf | grep libvmaf
vmaf /usr/include/libvmaf.h
so if I edit it to #include <libvmaf.h> it builds, but why is the path different than what libaom asks for?
utack is offline   Reply With Quote
Old 10th February 2020, 16:42   #2115  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
Quote:
Originally Posted by utack View Post
Does anyone know why libaom and vmaf are not compatible on an arch linux system?
Packaging differences. Compiling from sources and using "ninja -vC release install" puts the header(s) under <somewhere>/include/libvmaf/<headers>.h
Arch's package maintainer probably follows in the footsteps of the Debian package, that leaves the header under /usr/include/libvmaf.h
SmilingWolf is offline   Reply With Quote
Old 10th February 2020, 18:32   #2116  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 86
Quote:
Originally Posted by soresu View Post
Ouch, that's just being bloody minded to user battery life that is.

Here's the gitlab issue link for dav1d NEON, 4 opts for 16bpc already merged, 2 more lined up it seems.
Quote:
Originally Posted by SmilingWolf View Post
Packaging differences. Compiling from sources and using "ninja -vC release install" puts the header(s) under <somewhere>/include/libvmaf/<headers>.h
Arch's package maintainer probably follows in the footsteps of the Debian package, that leaves the header under /usr/include/libvmaf.h

Arch's package maintainer is not following anyone's footsteps other than upstream. It''s just the Makefile from v1.3.15 predates the changes that made the new Makefile just a wrapper around meson/ninja.

Anyway, the last time (~18 months ago) I tried linking libvmaf to ffmpeg, I got runtime crashes after I managed to find a version that compiles. So I figured the library is not really reliable API/ABI wise for external linkage use-cases. So I opted to just script around the provided executable vmafossexec.
__________________
saldl: a command-line downloader optimized for speed and early preview.
MoSal is offline   Reply With Quote
Old 11th February 2020, 17:30   #2117  |  Link
SmilingWolf
I am maddo saientisto!
 
SmilingWolf's Avatar
 
Join Date: Aug 2018
Posts: 103
Quote:
Originally Posted by MoSal View Post
Anyway, the last time (~18 months ago) I tried linking libvmaf to ffmpeg, I got runtime crashes after I managed to find a version that compiles. So I figured the library is not really reliable API/ABI wise for external linkage use-cases. So I opted to just script around the provided executable vmafossexec.
The timeframe look just about right to be about https://github.com/Netflix/vmaf/issues/177, which has since been fixed by http://ffmpeg.org/pipermail/ffmpeg-d...st/233012.html
SmilingWolf is offline   Reply With Quote
Old 11th February 2020, 23:43   #2118  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 927
Samsung galaxy s20 has been announced, no mention of AV1 support which i'm a little surprised at.
hajj_3 is offline   Reply With Quote
Old 11th February 2020, 23:48   #2119  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,900
Quote:
Originally Posted by hajj_3 View Post
Samsung galaxy s20 has been announced, no mention of AV1 support which i'm a little surprised at.
Its Android 10, at the very least it has a built-in software decoder.

Otherwise, its just Snapdragon 865, we already knew its media support - which does not include AV1. It won't be in the mainstream until the end of the year, if not 2021.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 12th February 2020, 00:44   #2120  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,628
Yeah, ooof. At least yet another cycle in front of us before we see a premium mobile phone with hardware AV1 decoding.
Blue_MiSfit is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.