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 19th February 2018, 18:30   #441  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Like the error message said: Some formats require you to set -strict -1 for y4m output. (But of course aomenc still needs to support the format you choose.)
ffmpeg -i "input" -strict -1 -f yuv4mpegpipe - | aomenc --passes=1 -o "output.webm" -
sneaker_ger is offline   Reply With Quote
Old 19th February 2018, 18:36   #442  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by sneaker_ger View Post
Like the error message said: Some formats require you to set -strict -1 for y4m output. (But of course aomenc still needs to support the format you choose.)
ffmpeg -i "input" -strict -1 -f yuv4mpegpipe - | aomenc --passes=1 -o "output.webm" -
It doesn't help with the file I'm trying. I'm actually trying with an RGB stream. (screencast)
So RGB can't be piped?
mzso is offline   Reply With Quote
Old 19th February 2018, 18:38   #443  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
I don't see any rgb input option in aomenc (maybe it can be passed as i444?). Use -pix_fmt to convert to a compatible format in ffmpeg.
sneaker_ger is offline   Reply With Quote
Old 19th February 2018, 18:56   #444  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by sneaker_ger View Post
I don't see any rgb input option in aomenc (maybe it can be passed as i444?). Use -pix_fmt to convert to a compatible format in ffmpeg.
Okay. Thanks.

(Out of curiosity, what would I need to pass RGB if the encoder supported it? The original command line failed on ffmpeg's side. PS: there's a yuvj pixel format, what does that mean? I know I need to use this when encoding with libx264 to keep it full range.)

Last edited by mzso; 19th February 2018 at 19:02.
mzso is offline   Reply With Quote
Old 19th February 2018, 19:01   #445  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
The formats with j mark full range content. RGB cannot be passed as y4m. You would have to pass as raw video (headerless) and specificy resolution, fps, colorspace, bitdepth manually if aomenc would support it (x264 does).
sneaker_ger is offline   Reply With Quote
Old 19th February 2018, 19:05   #446  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
As the name (YUV for MPEG) already suggests, it was designed for YUV color space (luminance Y + chrominance differences U/V) with different chroma subsampling configurations, additionally also luminance-only (greyscale) formats. Most efficiently compressing modern video formats rely on this color space because it resembles the preference for luminance in the retina of the human eyes (a magnitude more brightness-sensitive rods than color-sensitive cones), a pre-requisite for making use of chroma subsampling to reduce data rate with hardly obvious loss of resolution.

Basic command-line encoders in test and development generation, like aomenc, may not even contain code to convert generally unsupported RGB color space into supported YUV color space on their own, they rely on the video source serving a supported format.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 19th February 2018, 19:35   #447  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by sneaker_ger View Post
The formats with j mark full range content. RGB cannot be passed as y4m. You would have to pass as raw video (headerless) and specificy resolution, fps, colorspace, bitdepth manually if aomenc would support it (x264 does).
I see. So since yuvj isn't supported I guess I need to use "-scale=out_color_matrix=bt709ut_range=pc", right?
mzso is offline   Reply With Quote
Old 19th February 2018, 19:49   #448  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by LigH View Post
As the name (YUV for MPEG) already suggests, it was designed for YUV color space (luminance Y + chrominance differences U/V) with different chroma subsampling configurations, additionally also luminance-only (greyscale) formats. Most efficiently compressing modern video formats rely on this color space because it resembles the preference for luminance in the retina of the human eyes (a magnitude more brightness-sensitive rods than color-sensitive cones), a pre-requisite for making use of chroma subsampling to reduce data rate with hardly obvious loss of resolution.

Basic command-line encoders in test and development generation, like aomenc, may not even contain code to convert generally unsupported RGB color space into supported YUV color space on their own, they rely on the video source serving a supported format.
It might have converted to yuv automatically for all I knew.

I'm aware of what YUV is, but it's not your assesment of the retina is wrong, YUV doesn't resemble how the retina works. The retina has RGB cones which ar sensitive to their respective colors (sort of, they have an overlapping sensitivity curve) . And there's no suck thing as separation for brightness sensation, which is nonsensical. The rods are alternative sensors for low light circumstances, which (since there's only one kind) are monochromatic.

However human preception is more sensitive towards luminance that's why having it separate is advantageous. (The UV part has no relevance to human perception, it's just an artificial way to store color)
mzso is offline   Reply With Quote
Old 19th February 2018, 20:04   #449  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by mzso View Post
I see. So since yuvj isn't supported I guess I need to use "-scale=out_color_matrix=bt709:out_range=pc", right?
Yes. (If you want BT709 PC range output. Most people would use TV range.)
sneaker_ger is offline   Reply With Quote
Old 19th February 2018, 22:50   #450  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by Tommy Carrot View Post
Thanks for the new build. I thought after so many SIMD optimization, the encoding speed would've got a bit more tolerable, but on the default settings it's still slow as hell. With cpu-used=2 i could at least test it on some very short videos. The quality is decent, but i don't think it has improved much in the last few months.
Encoder optimization is a HUGE project, especially with the current generation of complex codecs. It's not just SIMD, but early exits, heuristics, frame-level parallelism. And there are SO MANY functions requiring assembly optimization. Just take a look at the x265 source code for a roughly equivalent example.

The VPx series has always had speed issues, particularly in multicore environments; most VPx encoding was done with split-and-stitch across multiple hosts, which isn't typical for premium content at feature length. A true production-efficient encoder might require a different basic architecture than what the reference encoder uses. Which is why we have bitstream specs, so people can build their own interoperable encoders and decoders.

But I'd expect it'd take a couple of years before we have AV1 encoders that would match performance @ quality of today's best HEVC encoders.

And that's not even getting into rate control and psychovisual optimization, which can also take several years to get to a reasonable baseline, and keep on getting refined for the usage life of the codec. We are still seeing significant improvements in MPEG-2 encoders 20+ years in.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book

Last edited by benwaggoner; 19th February 2018 at 22:51. Reason: typo fixed
benwaggoner is offline   Reply With Quote
Old 20th February 2018, 00:10   #451  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by benwaggoner View Post
But I'd expect it'd take a couple of years before we have AV1 encoders that would match performance @ quality of today's best HEVC encoders.

And that's not even getting into rate control and psychovisual optimization, which can also take several years to get to a reasonable baseline, and keep on getting refined for the usage life of the codec. We are still seeing significant improvements in MPEG-2 encoders 20+ years in.
I hope not. These many large corporations should have lots of bodies to throw at optimizing, improving the encoder.
mzso is offline   Reply With Quote
Old 20th February 2018, 00:21   #452  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by mzso View Post
I hope not. These many large corporations should have lots of bodies to throw at optimizing, improving the encoder.


That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.


Sent from my iPhone using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th February 2018, 19:26   #453  |  Link
bstrobl
Registered User
 
Join Date: Jun 2016
Posts: 55
Quote:
Originally Posted by benwaggoner View Post
That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.


Sent from my iPhone using Tapatalk
It gets worse once you factor the insane amount of coding tools that can be used in a myriad of combinations. Simply getting all of the heuristics to figure that out is insane work.

I do expect the default encoder and decoder to be pretty decent with good support however. OPUS is doing a decent job with its default tools.
bstrobl is offline   Reply With Quote
Old 20th February 2018, 19:58   #454  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by bstrobl View Post
It gets worse once you factor the insane amount of coding tools that can be used in a myriad of combinations. Simply getting all of the heuristics to figure that out is insane work.
Yeah, exactly my point. The efficiency gains of new codecs largely comes from the variety of new tools available, so getting the quality gains requires

Quote:
I do expect the default encoder and decoder to be pretty decent with good support however. OPUS is doing a decent job with its default tools.
Decoders are way easier than encoders, thankfully. They work, or they don’t. And unlike VP9, we actually have some Profile/Level specs so we know what a particular decoder is required to do and thus what our encoders can be allowed to do.

I’m not sure how you’d define “pretty decent” - I would think it wouldn’t before end of year that AV1 has solutions that clearly outperform even x264 for high-volume scenarios. But yeah, desktop file-to-file conversion will work, and will produce good looking video. Speed is far from practical yet, but getting it to the ballpark of x265 speed at x264 quality is a reasonable 2018 goal.

Also, Opus is an audio codec: only one dimension! Audio codec optimization is important, but we’re talking 1-2 orders of magnitude less effort to get to a production-grade encoder than with a video codec. And we actually have good audio quality perceptually correlated metrics, which makes automated tuning and testing much more feasible and useful.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th February 2018, 20:19   #455  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 930
Quote:
Originally Posted by benwaggoner View Post
That was true of HEVC, H.264, and MPEG-2. It always takes a couple of years from an essentially complete bitstream design to commercial grade encoders.


Sent from my iPhone using Tapatalk
It seems like to me that HEVC and AVC mostly had patent trolls. Who were only interested in filling their pockets.
mzso is offline   Reply With Quote
Old 20th February 2018, 20:21   #456  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by mzso View Post
It seems like to me that HEVC and AVC mostly had patent trolls. Who were only interested in filling their pockets.

DEFINITELY not mostly. Companies that really wanted to contribute to it so they could use the technology most joined the reasonable MPEG-LA pool.



Sent from my iPhone using Tapatalk
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th February 2018, 23:30   #457  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Quote:
Originally Posted by benwaggoner View Post
And we actually have good audio quality perceptually correlated metrics, which makes automated tuning and testing much more feasible and useful.
Audio metrics are no better than any video metrics.
Both have flaws.

Final quality verification tests of absolutely every meaningful audio standard were made by testing ... on humans.

Last edited by IgorC; 20th February 2018 at 23:34.
IgorC is offline   Reply With Quote
Old 23rd February 2018, 23:43   #458  |  Link
Clare
Registered User
 
Join Date: Apr 2016
Posts: 61
Experimental AV1 encoder in Rust: https://github.com/xiph/rav1e

I'll be adding new data to my comparator with a AV1 snapshot from 20180222, next week or so. I've changed the encoder parameters for more speed so I need to recalculate the old snapshots to have comparable data.

Also I added the PIK image format.

I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9. Gonna take a long while as I haven't written a single line of code yet and the encoding itself will be long.

Maybe AV1 will be bitstream freezed then. Latest estimate are: "AOM: Bitstream maybe March, maybe announce at NAB (early April)"
(https://www.nabshow.com/ from April 7th to April 12th)

Last edited by Clare; 23rd February 2018 at 23:47.
Clare is offline   Reply With Quote
Old 24th February 2018, 00:33   #459  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Quote:
Originally Posted by Clare View Post
I also plan to do an actual video comparaison based on 30 short clips, VMAF metrics, AV1, X264, X265, and VP9.
I hope you do comparisons at many resolutions e.g: 360p, 480p, 576p, 720p, 1080p, 1440p, uhd. A lot of the benchmarks shown so far comparing av1 to x264, x265 and vp9 either just show the overall difference or they show 360p, 720p and 1080p. I am more interested in the improvement of 360p-720p as x265 doesn't have that much improvement over x264 at those resolutions.
hajj_3 is offline   Reply With Quote
Old 24th February 2018, 01:36   #460  |  Link
Clare
Registered User
 
Join Date: Apr 2016
Posts: 61
Quote:
Originally Posted by hajj_3 View Post
I hope you do comparisons at many resolutions e.g: 360p, 480p, 576p, 720p, 1080p, 1440p, uhd. A lot of the benchmarks shown so far comparing av1 to x264, x265 and vp9 either just show the overall difference or they show 360p, 720p and 1080p. I am more interested in the improvement of 360p-720p as x265 doesn't have that much improvement over x264 at those resolutions.
I plan to use objective1-fast https://people.xiph.org/~tdaede/sets/objective-1-fast/
It's a mix of 360p, 720p and 1080p. I don't have any 1440p or UHD content and I doubt my computer would be able to process it in a reasonable time. But I plan to release the Python scripts I use on Github so it will be usable on any dataset, like I did for images (https://github.com/WyohKnott/image-comparison-sources).

Or I need to buy a Threadripper… when I have lots of money and no taxes to pay.
Clare 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 02:15.


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