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 1st June 2017, 19:24   #221  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,852
Is there a place to get support from the developers?
stax76 is offline   Reply With Quote
Old 1st June 2017, 19:31   #222  |  Link
wiak
Registered User
 
Join Date: Jul 2003
Location: somewhere north
Posts: 260
Quote:
Originally Posted by stax76 View Post
Is there a place to get support from the developers?
#aomedia @ irc.freenode.net probobly your best bet, or there is http://aomedia.org/contact/

btw aoem isnt even done yet sooo
__________________
Woah! Ninja?! http://nwgat.ninja/ (AV1 Overview)
"Not available in your region" has now been redefined as "Go Pirate, you filthy scum" Nwgat
wiak is offline   Reply With Quote
Old 1st June 2017, 19:38   #223  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,495
Try with y4m input via pipe:
aomenc --pass=1 --passes=2 --fpf="statsfile.txt" -o "output" -
aomenc --pass=2 --passes=2 --fpf="statsfile.txt" -o "output" -
sneaker_ger is offline   Reply With Quote
Old 1st June 2017, 19:44   #224  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,852
Thanks, got it working now as it seems.

https://postimg.org/image/vbjihxjml/

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Encoding video using aomenc May 2017
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=1 --target-bitrate=1167 --fpf=D:\Temp\staxrip\Eli_temp\Eli.txt -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

cmd.exe /C call D:\Temp\staxrip\Eli_temp\Eli_encode.bat

ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)

Input #0, avisynth, from 'D:\Temp\staxrip\Eli_temp\Eli.avs':
Duration: 00:00:43.41, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 480x272, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: wrapped_avframe, yuv420p, 480x272, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc57.89.100 wrapped_avframe
Pass 1/2 frame 1/0 0B 0 us 0.00 fpm [ETA unknown] [K
Pass 1/2 frame 2/1 176B 2963 us 674.99 fps [ETA unknown] [K
Pass 1/2 frame 3/2 352B 5649 us 531.07 fps [ETA unknown] [K
Pass 1/2 frame 4/3 528B 8217 us 486.80 fps [ETA unknown] [K
Pass 1/2 frame 5/4 704B 10686 us 467.90 fps [ETA unknown] [K
Pass 1/2 frame 6/5 880B 12733 us 471.22 fps [ETA unknown] [K
Pass 1/2 frame 7/6 1056B 14736 us 475.03 fps [ETA unknown] [K
Pass 1/2 frame 8/7 1232B 16749 us 477.64 fps [ETA unknown] [K
Pass 1/2 frame 9/8 1408B 18797 us 478.80 fps [ETA unknown] [K

Start: 19:32:48
End: 19:32:53
Duration: 00:00:04

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Encoding video second pass using aomenc May 2017
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
D:\Projekte\VS\VB\StaxRip\bin\Apps\ffmpeg\ffmpeg.exe -i D:\Temp\staxrip\Eli_temp\Eli.avs -f yuv4mpegpipe - | D:\Projekte\VS\VB\StaxRip\bin\Apps\aomenc\aomenc.exe - --passes=2 --pass=2 --target-bitrate=1167 --fpf=D:\Temp\staxrip\Eli_temp\Eli.txt -o D:\Temp\staxrip\Eli_temp\Eli_out.webm

cmd.exe /C call D:\Temp\staxrip\Eli_temp\Eli_encode.bat

ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)

Input #0, avisynth, from 'D:\Temp\staxrip\Eli_temp\Eli.avs':
Duration: 00:00:43.41, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 480x272, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: wrapped_avframe, yuv420p, 480x272, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc
Metadata:
encoder : Lavc57.89.100 wrapped_avframe
frame= 27 fps=1.4 q=-0.0 size= 5164kB time=00:00:00.90 bitrate=46956.7kbits/s speed=0.0458x
frame= 28 fps=1.3 q=-0.0 size= 5355kB time=00:00:00.93 bitrate=46956.6kbits/s speed=0.0429x
frame= 30 fps=1.3 q=-0.0 size= 5738kB time=00:00:01.00 bitrate=46956.6kbits/s speed=0.0433x
frame= 31 fps=0.9 q=-0.0 size= 5929kB time=00:00:01.03 bitrate=46956.6kbits/s speed=0.029x
frame= 32 fps=0.8 q=-0.0 size= 6120kB time=00:00:01.06 bitrate=46956.6kbits/s speed=0.0281x
frame= 34 fps=0.8 q=-0.0 size= 6503kB time=00:00:01.13 bitrate=46956.5kbits/s speed=0.0274x
frame= 35 fps=0.8 q=-0.0 size= 6694kB time=00:00:01.16 bitrate=46956.5kbits/s speed=0.0257x
frame= 36 fps=0.7 q=-0.0 size= 6885kB time=00:00:01.20 bitrate=46956.5kbits/s speed=0.0246x
frame= 38 fps=0.7 q=-0.0 size= 7268kB time=00:00:01.26 bitrate=46956.5kbits/s speed=0.0241x
frame= 39 fps=0.4 q=-0.0 size= 7459kB time=00:00:01.30 bitrate=46956.5kbits/s speed=0.013x
frame= 40 fps=0.3 q=-0.0 size= 7650kB time=00:00:01.33 bitrate=46956.5kbits/s speed=0.0107x
frame= 42 fps=0.3 q=-0.0 size= 8033kB time=00:00:01.40 bitrate=46956.4kbits/s speed=0.0103x
stax76 is offline   Reply With Quote
Old 1st June 2017, 20:38   #225  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 841
Too bad Montgomery stopped with the Dalaa blogs. Now there's no info (that mere mortals can comprehend) about what stuff they're experimenting with.
mzso is offline   Reply With Quote
Old 2nd June 2017, 19:34   #226  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,852
There's a first staxrip test build with AV1 support, feedback for tab names and labels would be a really helpful.

https://postimg.org/image/hjhoy7qar

https://github.com/stax76/staxrip/bl...ncoder.vb#L144

https://forum.doom9.org/showthread.p...26#post1808526
stax76 is offline   Reply With Quote
Old 2nd June 2017, 19:36   #227  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
I hope you have a huge warning somewhere that people should really not encode videos in AV1 if they care to be playable in the future? AV1 is not done yet, and files encoded with a certain encoder version will not be compatible with future decoders.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 2nd June 2017, 20:21   #228  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,852
I guess you are right, I've changed the title bar to: Under construction, AV1 isn't finished yet
stax76 is offline   Reply With Quote
Old 15th June 2017, 23:48   #229  |  Link
TD-Linux
Registered User
 
Join Date: Aug 2015
Posts: 34
Quote:
Originally Posted by Phanton_13 View Post
I found this comparison betwen beta of AV1, HEVC and AVC by the Fraunhofer Heinrich Hertz Institute:

http://iphome.hhi.de/marpe/download/...VC-PCS2016.pdf

The result is somewat surprising but not much if we think who did it and the development status of AV1, after reading it I also find it of poor quality and with various possibilities for errors plus it's potentially in conflict with other studies.
This paper is old now, but I didn't see this documented anywhere else, so:

This paper made the same error as their previous VP9 comparison paper. They allow x265 to do fixed quantizer modulation, but lock AV1 to a single quantizer per frame. x265's --qp option still varies per-frame qp's via ipFactor and pbFactor.

Even if they had set both x265 factors to 1.0, there would still be the problem that H.265 itself maps the QP value to different "real" quantizers based on keyframe or not, as part of the bitstream. So you'd actually have to null that out with a "backwards" ipFactor, or adjust AV1 to have a similar boost.
TD-Linux is offline   Reply With Quote
Old 16th June 2017, 23:10   #230  |  Link
blurred
Registered User
 
Join Date: Jul 2016
Posts: 14
Hot thread about Google ANS patent for AV1:
https://www.reddit.com/r/programming...ort=confidence
blurred is offline   Reply With Quote
Old 24th June 2017, 20:39   #231  |  Link
ls1dreams
Registered User
 
Join Date: Aug 2016
Posts: 3
which intel chip?

Anyone have a prediction on which intel series chip/igpu this will make it into?

- coffee lake
- cannonlake
- later?

Coffee Lake seems unlikely since timing is about the same time as they plan to freeze the AV1 bitstream, unless the alliance has been working VERY closely with intel. Cannonlake even shortly after seems like it's rather tight.
ls1dreams is offline   Reply With Quote
Old 24th June 2017, 21:21   #232  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 115
Seems likeliest that the first accelerated implementations will be GPGPU or DSP based prior to ASIC for at least a year after bitstream is frozen later this year (assuming they manage to freeze at all this year).
soresu is offline   Reply With Quote
Old 24th June 2017, 21:25   #233  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 115
A more interesting question is whether AV1 will be more amenable to parallel implementations than VP9, or even HEVC - which was a key goal originally for Daala, given the slow progress in CPU single thread performance, GPGPU or some other massively parallel accelerator represents a far more efficient target, and OTOY's ORBX codec shows that it can be done, strange that they are completely absent from the Alliance to be honest.
soresu is offline   Reply With Quote
Old 25th June 2017, 03:24   #234  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 65
Quote:
Originally Posted by soresu View Post
A more interesting question is whether AV1 will be more amenable to parallel implementations than VP9, or even HEVC - which was a key goal originally for Daala, given the slow progress in CPU single thread performance, GPGPU or some other massively parallel accelerator represents a far more efficient target, and OTOY's ORBX codec shows that it can be done, strange that they are completely absent from the Alliance to be honest.
Why do you believe VP9 was not parallelizable? I think FFmpeg's decoder showed that parallelism is not an issue. The fact that Google's decoder didn't use parallelism has nothing to do with the format.
Beelzebubu is offline   Reply With Quote
Old 25th June 2017, 03:43   #235  |  Link
soresu
Registered User
 
Join Date: May 2005
Location: Swansea, Wales, UK
Posts: 115
Ah, when talking about parallelism, I meant the encoder rather than the decoder, which is usually more compute intensive and seems to increase in complexity sometimes an order of magnitude or more per generation, while the decoder seems to be only a modest increase albeit still enough to hurt in the current climate of slow single thread improvement.

It seems that the likes of Netflix and Google get around parallelisation limits (atleast limits that dont impact compression efficiency) of H264, HEVC and VP9 by employing chunked encoding over the gamut of a server farm/datacenter, but this is still limited to CPU compute.

It would be interesting to see if we could at least see GPGPU employed efficiently for chunked encoding, if not for full length videos.
soresu is offline   Reply With Quote
Old 25th June 2017, 03:50   #236  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 65
Without wanting to get too much into detail, I would claim that the issue here is in the implementation, not the format. There are alternative VP9 encoder implementations that are far less limited in their parallelism.
Beelzebubu is offline   Reply With Quote
Old 25th June 2017, 08:56   #237  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
Quote:
Originally Posted by soresu View Post
It would be interesting to see if we could at least see GPGPU employed efficiently for chunked encoding, if not for full length videos.
GPGPU for encoding has never really been any successfull. You would probably have to design a codec with that as a key basic design for it to work decently, and it would probably have drawbacks anywhere else - ie. not be very general purpose.
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot. Encoding thousands of chunks at the same time would not be very simple (in fact a single chunk would be rather complex), and likely not work very well.

I do think however that the codecs we currently have do scale well enough to keep multi-core CPUs busy just fine, encoder implementations not withstanding.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 25th June 2017 at 09:01.
nevcairiel is offline   Reply With Quote
Old 26th June 2017, 03:22   #238  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 424
I would imagine that the first GPUs implementing hardware AV1 decoding would be the middle of 2018 at the earliest.

CPU-wise, that would line up well with Zen2 APUs (H2 2018 - H1 2019) but if you insist on Intel you'd have to wait for Icelake in 2019.
Nintendo Maniac 64 is offline   Reply With Quote
Old 26th June 2017, 20:28   #239  |  Link
Przemek_Sperling
Registered User
 
Join Date: Jun 2009
Location: Poland
Posts: 125
Quote:
Originally Posted by nevcairiel View Post
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot.
I can't believe it

;-)
Przemek_Sperling is offline   Reply With Quote
Old 29th June 2017, 14:25   #240  |  Link
Phanton_13
Registered User
 
Join Date: May 2002
Posts: 94
Quote:
Originally Posted by nevcairiel View Post
GPGPU for encoding has never really been any successfull. You would probably have to design a codec with that as a key basic design for it to work decently, and it would probably have drawbacks anywhere else - ie. not be very general purpose.
The thing about GPGPU is that it only works well if a simple task can be parallized a whole lot. Encoding thousands of chunks at the same time would not be very simple (in fact a single chunk would be rather complex), and likely not work very well..
Actually the bigest problem is that you have to throw to the sink the knowledge and commom sense in algorithms that you learned doing commom programing. I learned this the hard way when I helped in the parallezitaion of a problem, we made it faster doing it slower... basically our solution was around ten times slower than the clasical one runing only one thread, but the clasical one was mostly limited to 12 threads and our was able to scale to more than 1000 threads and that resulted in it being around 80 times faster that the clasical solution in the machine where it was run.

Sorry for my english, I'n not a native speaker.

Last edited by Phanton_13; 29th June 2017 at 14:29.
Phanton_13 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 05:07.


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