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. |
4th August 2018, 20:34 | #821 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
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...
|
5th August 2018, 07:55 | #822 | Link | |
Registered User
Join Date: Aug 2009
Posts: 201
|
Quote:
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. |
|
7th August 2018, 02:04 | #823 | Link |
Registered User
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. |
7th August 2018, 07:44 | #824 | Link | |
Registered User
Join Date: Oct 2009
Posts: 930
|
Quote:
|
|
8th August 2018, 23:34 | #826 | Link |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
I apologize for an offtopic.
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. |
9th August 2018, 16:56 | #828 | Link |
Registered User
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. |
10th August 2018, 07:36 | #829 | Link |
German doom9/Gleitz SuMo
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... Last edited by LigH; 12th August 2018 at 19:36. |
12th August 2018, 19:35 | #830 | Link |
German doom9/Gleitz SuMo
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. |
17th August 2018, 14:46 | #831 | Link |
German doom9/Gleitz SuMo
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) Last edited by LigH; 17th August 2018 at 15:21. |
17th August 2018, 18:23 | #832 | Link |
Registered User
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. |
18th August 2018, 04:01 | #833 | Link |
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. |
21st August 2018, 13:17 | #836 | Link |
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? |
21st August 2018, 16:50 | #837 | Link |
Registered User
Join Date: Dec 2008
Posts: 1,959
|
Where did you get this very questionable information?
__________________
MPC-BE 1.6.11 and Nightly builds | VideoRenderer | ImageSource | ScriptSource | BassAudioSource |
22nd August 2018, 01:28 | #838 | Link | |
Registered User
Join Date: Aug 2015
Posts: 34
|
Quote:
|
|
22nd August 2018, 01:32 | #839 | Link |
Registered User
Join Date: Jun 2015
Posts: 21
|
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. |
22nd August 2018, 01:46 | #840 | Link | |
Registered User
Join Date: Jun 2015
Posts: 21
|
Quote:
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. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|