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. |
12th July 2019, 23:11 | #1781 | Link | |
Registered User
Join Date: Jan 2007
Posts: 729
|
Quote:
Recently somebody asked on AOM IRC whether it would be possible for the Parkjoy encode that Two Orioles showed on the recent conference presentation to be shared/uploaded. They were rejected - by their words the encodes are not actually"classified", but it is "too much work". Take it as you will but it AFAIK there is not a signle public stream or file encoded by their software, out in the open (or am I missing something?), so it might not be a coincidence or something that is gonna change. I don't want this to sound like bashing, but perhaps NDAing all that is the business policy that they want/need/are forced to use by the nature of the field. Few years have passed and I can't see how there was no way some more transparent comparison test couldn't have been arranged one way or another, so I assume they just don't wish to do that. Sharing samples like what Beamr guys did is one way they could brag about their quality without the encoder leaving their hands... You would probably have to get such sample from streaming/video services who are using the software, when content encoded with Eve appears via them. Last edited by mandarinka; 12th July 2019 at 23:16. |
|
15th July 2019, 23:37 | #1782 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Yeah what the heck, guys! Why can't they release some sample bitstreams of open source content? The pros among us are totally interested in commercial encoders, but only if they can compete honestly.
|
17th July 2019, 02:31 | #1783 | Link | |||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
Quote:
Quote:
|
|||
18th July 2019, 09:25 | #1784 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
New uploads: (MSYS2; MinGW32 / MinGW64: GCC 9.1.0)
AOM v1.0.0-2084-g42451f74e rav1e 0.1.0 (20190430-207-g6ac87d8) built 2019-07-17; new verbose version numbering dav1d 0.3.1 (2019-07-17, g15a9386) |
24th July 2019, 15:20 | #1785 | Link |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
AV1 Ecosystem Update: June 2019
https://www.singhkays.com/blog/av1-e...ate-june-2019/ |
6th August 2019, 23:13 | #1786 | Link | |
Registered User
Join Date: Jun 2019
Posts: 16
|
dav1d 0.4.0 + FFmpeg 4.2
|
|
8th August 2019, 08:06 | #1787 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
Instead, MABS disabled ffmpeg support for librav1e because the previously working patch doesn't work anymore. I guess the two projects have to find a common and more stable API again.
|
8th August 2019, 19:10 | #1788 | Link |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Phononix has a new review including more SVT-AV1 v0.5 encoding performance metrics (located ~1/3 the way down the page) as well as dav1d v0.3 decoding performance metrics (located ~2/3 the way down the page); do note that all this testing was conducted on Ubuntu Linux:
https://www.phoronix.com/scan.php?pa...502-7742&num=4 This time they were testing the new Zen2-based AMD Epyc 32core (Epyc 7502) and 64core (Epyc 7742) chips against existing top-end Intel Xeon and AMD Epyc CPUs in both single-socket and dual-socket configurations. dav1d v0.3 decoding was also included on the performance-per-dollar page, though oddly enough SVT-AV1 was not (scroll down to around half way down the page): https://www.phoronix.com/scan.php?pa...502-7742&num=9 And in the according forum thread for that review, there's a post containing information for dav1d's decoding performance in fps at both 1080p and 4k as well as frames-per-dollar at 4k: https://www.phoronix.com/forums/foru...ks#post1118526
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
26th August 2019, 14:11 | #1790 | Link |
Registered User
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 196
|
I found a gitlab repo for the dav1d GPU acceleration GSoC, seems like SGR and CDEF have been implemented in Vulkan, and the same repo even has a GLES branch.
Link here. It will be interesting to see if they can get weaker non ASIC SoC's running well by taking advantage of the previously untapped GPU. |
27th August 2019, 20:56 | #1791 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
|
|
27th August 2019, 21:31 | #1792 | Link | |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Quote:
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
|
1st September 2019, 08:43 | #1795 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
@benwaggoner
There is no such thing as "GPU encoding" nowadays. It's an old term referring to the old days where GPGPU processing used for video encoding. Nowadays all GPUs from the three major vendors (Intel, nVidia, AMD) contain a fixed-function hardware unit, an ASIC, just for the purpose of video decoding/encoding/pre-post processing. The quality of H.265 hardware encoding of Turing cards aka Turing specific ASIC for video encoding is more than good enough and its speed is out of this world compared to software encoders.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
2nd September 2019, 05:56 | #1796 | Link | |
Registered User
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 447
|
Quote:
(Navi's AVC encoder is still no better than previous AMD GPUs however, meaning you really shouldn't use it)
__________________
____HTPC____ | __Desktop PC__
2.93GHz Xeon x3470 (4c/8t Nehalem) | 4.5GHz 1.24v dual-core Haswell G3258 Radeon HD5870 | Intel iGPU 2x2GB+2x1GB DDR3-1333 | 4x4GB DDR3-1600 |
|
3rd September 2019, 19:30 | #1797 | Link | |||
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
This could be of particular interest for new codecs like AV1, EVC, and VVC where mature fixed-function implementations aren't yet available. The rapid iteration possible with software is a huge benefit in early-stage codec development and deployment. Quote:
Quote:
Although we don't have any GPUs with AV1 fixed function units yet, do we? |
|||
3rd September 2019, 19:39 | #1798 | Link | |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
Quote:
And I'm starting to believe that due to the complexity of the codec, it could be the first time that we will not see hybrid (GPU+CPU) decoders/ encoders and we will go straight to fixed-function decoders/encoders of AV1. Agreed with your post above.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
|
3rd September 2019, 20:37 | #1799 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
I think it's already posted, but just as a reminder we could also wait for Vulkan/OpenGL GPU assisted hybrid decoding of dAV1d.
I have my doubts, but OK: https://www.phoronix.com/scan.php?pa...LES-Experiment
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
|
|