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 > VP9 and AV1

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th August 2018, 20:34   #821  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Quote:
Originally Posted by mzso View Post
I believe someone explained before that the golden frame was kept consciously, and that it's no is not only not a disadvantage, but on the contrary it allows to do some stuff that otherwise wouldn't be possible.
Golden frame was the goto thing they could point at when they wanted to pretend VP8/9/... is a result of an extensive independent research and novel ideas of On2's and not just a crippled H.264/HEVC copy with some arbitrary changes and mangling made so that it is harder to sue. When your competitor makes everything in the open and drafts are available years in advance...
mandarinka is offline   Reply With Quote
Old 5th August 2018, 07:55   #822  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 201
Quote:
Originally Posted by mandarinka View Post
Golden frame was the goto thing they could point at when they wanted to pretend VP8/9/... is a result of an extensive independent research and novel ideas of On2's and not just a crippled H.264/HEVC copy with some arbitrary changes and mangling made so that it is harder to sue. When your competitor makes everything in the open and drafts are available years in advance...
Live by the patent, die by the patent.

If your entire business model is based on the public granting you property rights over a specific bit of mathematics in return for publishing the exact limits of your property, it's a little bit churlish to complain that the public makes use of that information. If that deal didn't suit then they shouldn't have taken it.
dapperdan is offline   Reply With Quote
Old 7th August 2018, 02:04   #823  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
I don't buy the "it's only math" as an argument that video compression technology is simple and should not be patentable.

Everything is obvious in hindsight/to laymen, but to get to that hindsight situation is the hard part. MPEG/VCEG circles brought amazing video technology forward, if you recall how bad the codecs were say in 2004 (and those were already things brought forward by them and those were already great progress above truly stone age tech).

As in many fields and situations, people take all good things for granted, ignore their value and endlessly bitch about some trifling small details they find on them to complain about. (Yes, the neverending rants about licensing and royalty-free/encumberedness broken record, I consider that unimportant in the overall scope of video compression progress - to be clear.)

Last edited by mandarinka; 7th August 2018 at 02:10.
mandarinka is offline   Reply With Quote
Old 7th August 2018, 07:44   #824  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by mandarinka View Post
I don't buy the "it's only math" as an argument that video compression technology is simple and should not be patentable.

Everything is obvious in hindsight/to laymen, but to get to that hindsight situation is the hard part. MPEG/VCEG circles brought amazing video technology forward, if you recall how bad the codecs were say in 2004 (and those were already things brought forward by them and those were already great progress above truly stone age tech).

As in many fields and situations, people take all good things for granted, ignore their value and endlessly bitch about some trifling small details they find on them to complain about. (Yes, the neverending rants about licensing and royalty-free/encumberedness broken record, I consider that unimportant in the overall scope of video compression progress - to be clear.)
Nothing should be patentable. You can't own a mental concept, you can't be dispossessed from it either.
mzso is offline   Reply With Quote
Old 8th August 2018, 00:53   #825  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Let's not go down this rabbit hole, please Let's keep discussion on AV1.
Blue_MiSfit is offline   Reply With Quote
Old 8th August 2018, 23:34   #826  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
I apologize for an offtopic.
Quote:
Originally Posted by mandarinka View Post
if you recall how bad the codecs were say in 2004
Ateme H.264 encoder was already state of the art with an excelent physocvisual model in 2004. It took x264 some long time to reach that quality.

Last edited by IgorC; 8th August 2018 at 23:37.
IgorC is offline   Reply With Quote
Old 9th August 2018, 15:03   #827  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
New upload:

AOM v1.0.0-359-g1bc580401 (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th August 2018, 16:56   #828  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863


The latest build crashes at the third frame in each attempt, no matter what settings i try. Anyone else have this happening? The 32 bit version works fine, so i dont know if it's because some bug in the code, or because of the new GCC.
Tommy Carrot is offline   Reply With Quote
Old 10th August 2018, 07:36   #829  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Confirming on an AMD FX-6300. First pass passes; second pass gives an APPCRASH: Exception at 0x00000000004D3B68 in aomenc.exe: 0xC0000005: Access violation while reading at address 0x0000000000000000

A kind of "over-optimization" bug in GCC 8.2.0 is quite probable, IMHO. I wonder where to discuss it best. Will use the good old IRC for a while.
_

P.S.: There is a channel #aomedia on Freenode; I wonder why it is missing in the server's channel list, though... — Probably to avoid spam bots.
_

P.P.S.: It's probably an issue with the auto-vectorization. Let's see whether Alexpux can downgrade or upgrade GCC in MSYS2...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 12th August 2018 at 19:36.
LigH is offline   Reply With Quote
Old 12th August 2018, 19:35   #830  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
The issue has been analyzed down to a disassembly proving that Tree SLP Vectorization may produce undesired unaligned memory access, causing a segmentation fault.

There is a temporary patch proposed which rearranges some code to avoid this misalignment. Furthermore, I tried to notify the GCC developers of this issue. So until GCC 8 got fixed, aomedia may try to circumvent it sooner.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 17th August 2018, 14:46   #831  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
New upload:

AOM v1.0.0-399-g427b0382d (MSYS2; MinGW32: GCC 7.3.0 / MinGW64: GCC 8.2.0; -fno-tree-slp-vectorize)
_

I have no experience creating a real .diff file; but if you want to do the same in MABS, a snippet for build/media-suite_compile.sh would look like:

Code:
 if { [[ $aom = y ]] || { [[ $ffmpeg != "no" ]] && enabled libaom; }; } &&
     do_vcs https://aomedia.googlesource.com/aom; then
-    extracommands=()
+    extracommands=(-DAOM_EXTRA_C_FLAGS="-fno-tree-slp-vectorize" -DAOM_EXTRA_CXX_FLAGS="-fno-tree-slp-vectorize")
     [[ -n $_aom_bins ]] && _check+=(bin-video/aomdec.exe) ||
         extracommands+=(-DENABLE_EXAMPLES=off)
It could possibly be optimized to include these extra flags only in the 64 bit branch.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 17th August 2018 at 15:21.
LigH is offline   Reply With Quote
Old 17th August 2018, 18:23   #832  |  Link
Tommy Carrot
Registered User
 
Tommy Carrot's Avatar
 
Join Date: Mar 2002
Posts: 863
Thanks for the new build, and for finding out what went wrong with the previous. No crashes so far, and while it's still very slow, the encoding speed is getting a bit better (though the quality has regressed a bit in some cases compared to the earlier builds).

I tinkered around with rav1e (the other av1 encoder) a bit too. It's definitely in a much earlier stage of development, it's still missing way too many features to have acceptable quality. But at least it produces valid bitstream.
Tommy Carrot is offline   Reply With Quote
Old 18th August 2018, 04:01   #833  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
rav1e now has automatic Windows builds via Appveyor. To get the latest build, go to this page:

https://ci.appveyor.com/project/tdaede/rav1e/history

Click the latest build labeled with "master", then click Artifacts to download the executable. I'll wire up a better interface for some at this point.

Keep in mind that rav1e is still incomplete, lacking features such as motion compensation, so you should not expect good compression performance. However, it is much faster than libaom and is useful for generating long AV1 test sequences.
TD-Linux is offline   Reply With Quote
Old 18th August 2018, 15:20   #834  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
@TD-Linux: does rav1e support y4m input via pipe?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 18th August 2018, 20:40   #835  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
Yes it does - just use a "-" to indicate pipe. You can also output ivf via a pipe. For example:

ffmpeg -i file.webm -f yuv4mpegpipe - | rav1e - -o file.ivf
TD-Linux is offline   Reply With Quote
Old 21st August 2018, 13:17   #836  |  Link
olduser217
Registered User
 
Join Date: Jun 2015
Posts: 21
Hi guys, does the bit distribution of AV1 similar to VP9?

For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
These non-display frames are normally acting as ALTREF frame for the decoding of frames decoded after it, and they are normally being allocated with lot of bits compare to other inter frames (more than 10 times) which will be displayed.

Netflix VP9 bitstreams seem like having such bit distribution too.

Does the same happen to AV1?
olduser217 is offline   Reply With Quote
Old 21st August 2018, 16:50   #837  |  Link
v0lt
Registered User
 
Join Date: Dec 2008
Posts: 1,959
Quote:
Originally Posted by olduser217 View Post
For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
Where did you get this very questionable information?
v0lt is offline   Reply With Quote
Old 22nd August 2018, 01:28   #838  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
Quote:
Originally Posted by TD-Linux View Post
For VP9 4k bitstream in Youtube, according to requirement from Youtube, the decoder needs to support up to 65-frame decoding frame rate for 60-frame display frame rate, where there are up to 5-frame decoded without display.
These non-display frames are normally acting as ALTREF frame for the decoding of frames decoded after it, and they are normally being allocated with lot of bits compare to other inter frames (more than 10 times) which will be displayed.

Netflix VP9 bitstreams seem like having such bit distribution too.

Does the same happen to AV1?
Yes, see section A.3 of the spec. MaxDisplayRate and MaxDecodeRate are different, with MaxDecodeRate being higher. Note that this is more flexible than VP9 - if you are at a lower resolution or frame rate, you can use more non-shown frames. There is also a maximum header rate defined separately.
TD-Linux is offline   Reply With Quote
Old 22nd August 2018, 01:32   #839  |  Link
olduser217
Registered User
 
Join Date: Jun 2015
Posts: 21
Quote:
Originally Posted by v0lt View Post
Where did you get this very questionable information?
https://sites.google.com/a/google.co...irements?pli=1

You probably need to join the group to access it.

You can simply download a 4k 60fps VP9 bitstream from Youtube to check the existence of such non-display frames (show_frame == 0), which are added around or close to the frequency mentioned.

Last edited by olduser217; 22nd August 2018 at 01:35.
olduser217 is offline   Reply With Quote
Old 22nd August 2018, 01:46   #840  |  Link
olduser217
Registered User
 
Join Date: Jun 2015
Posts: 21
Quote:
Originally Posted by TD-Linux View Post
Yes, see section A.3 of the spec. MaxDisplayRate and MaxDecodeRate are different, with MaxDecodeRate being higher. Note that this is more flexible than VP9 - if you are at a lower resolution or frame rate, you can use more non-shown frames. There is also a maximum header rate defined separately.
Yes, noticed about this too.
So, for Level 5.1 of AV1 (seems like suitable for 4k60), the maximum decode frame rate for 3840x2160 equals to:
= MaxDecodeRate/3840x2160
= 547,430,400 / 3840x2160
= 66fps

So, the frame rate for decoding is quite similar to VP9 (at least for Youtube case).

Just curious whether the bit distribution of AV1 is similar as VP9 too, i.e. the non-display inter frames are being allocated with much higher bits (more than 10 times) compared to the displayed inter frames.
This seems like not mentioned in the AV1 specification.
olduser217 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 14:04.


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