Some qustion about AV1,VP9,HEVC,AVC

[pandy]

I a newbie in video coding, so I have new questions?
I know that the quantization level or qp, when I chose the higher value you will get good compression but bad quality? I think its the same as Quantizer in PCM higher level means higher quality and less error?

PCM is uncompressed and there is no quantization (not in same sense as in lossy compressed video/audio) - for PCM and video instead quantizer another term can be used - bit depth - you must distinguish between raw audio/video samples and compressed audio/video signal - this is two different things - lossy codec samples are functions being produce after particular transformation (DCT, Hadamard etc). Don't confuse spatial domain with frequency domain.

I'm still don't know how to measure bitrate for bitstream, let us say I have .265 with size 100kB and duration 3sec and 30 ms, so I need to multiply 100 by 8 and divide it by duration which is 3.33 then I will get the average bitrate, right?

yes

I'm using x265, x264 when I want to output the bitstream I write -o example.265 but if I change the .265 to a container like .mp4 or .mkv I got the same file size? the -o example .265 work great if I open the file with hevc analyzer, they have the same size because I don't multiplexer the bitstream with the audio file ? is this thing made the file bigger?

Using x264 x265 against non optimized reference encoders is not fair... i see no relation with audio and container

which one of this two is good compression method, using fixed qp during the whole process with every codec and measure the bitrate with psnr,ssim... or using certain bitrate and compare the bitrate with psnr.ssim ?

Using crf and verifying quality objectively and subjectively also measuring bitrate. Fixed qp is unnatural video codec mode used usually only is some niche applications like Intra codecs dedicated for material editing (qp is then sufficiently low to introduce lowest possible quality losses).

btw I'm using x265.x264.libvpx-vp9,aomenc av1 without ffmpeg , i don't want to use ffmpeg

your choice but this comparison sounds quite weird too me...

what is the lag in the frame option?

I assume it is latency undesired with live applications like video chat - so it may imply that codec allow to reduce latency at a cost of something.

why does some encoder ask to enter the fps with a fraction like --fps=50000/1001 not 49 to 50 ?

Because to support correct NTSC framerates (NTSC as class of framerates not composite colour coding) they must be expressed as 30000/1001 or 60000/1001

whats the reason for JM and HW reference encoder?

They are like living proof for written standard i.e. codec specification - some video codecs (mostly those from google or regular developers without too much video experience) have no good specification and reference encoder code may act like documentation itself - you can take plain, quite well documented code and based on this code start creating own implementation - also they are used as reference i.e. your video codec implementation should be identical when decoded by reference decoder - using reference encoder is good starting point to decoder that deliver same result as reference decoder.

[rockerovo]

Thank you pandy

I'm using CBR mode now, let's say I want 3500 kbps, why the output bitrate for the file is not exactly 3500 sometimes it's 3550 or 3000, is this mode for to tell encoder, not exceeds given bitrate? I know when I choose 3500 this means the same bitrate in the whole video, and it's not good, but I'm trying to compare here.

whats you think about my settings :

for x264 :

x264 --profile main --preset medium --bitrate 3500 --input-csp i420  --output-csp i420  --input-depth 8  --output-depth 8 --input-res 1920x1080 --fps 50 --verbose ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv  --pass 1 -o NUL --stats 264.stats

x264 --profile main --preset medium --bitrate 3500 -o avc_3500.264 --input-csp i420  --output-csp i420  --input-depth 8  --output-depth 8 --input-res 1920x1080 --fps 50 --verbose ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv --dump-yuv 264.yuv --pass 2 --stats 264.stat

for x265 :

x265  --output-depth 8 --input ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv --fps 50 --input-res 1920x1080 --input-depth 8 --input-csp 1  -P main -p medium --bitrate 3500 --pass 1 --stats a.stats --output NUL

x265 -o hevc_3500.265 --output-depth 8 --input ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv --fps 50 --input-res 1920x1080 --input-depth 8 --input-csp 1  -P main -p medium --bitrate 3500 --pass 2 --stats a.stats

for VP9 :

./vpxenc --output=ReadySteadyGo_1920x1080_120fps_420_8bit_.webm --codec=vp9 --passes=2 --good --verbose --psnr --i420 --threads=8 --width=1920 --height=1080 --profile=0 --fps=50000/1001  --target-bitrate=3500  --cpu-used=1 --auto-alt-ref=1 --input-bit-depth=8 --tile-columns=2 ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv --bit-depth=8 --row-mt=1 --end-usage=cbr --webm

AV1 :

./aomenc ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv -v --threads=8 --width=1920 --height=1080 --i420 --profile=0 --fps=50000/1001 --codec=av1 --cpu-used=1 --passes=2 --pass=1 --fpf=aom.pass  --target-bitrate=3500 --end-usage=cbr  --aq-mode=1 --bit-depth=8 --input-bit-depth=8 


./aomenc ReadySteadyGo_1920x1080_120fps_420_8bit_YUV.yuv -v --threads=8 --width=1920 --height=1080 --i420 --profile=0 --fps=50000/1001 --codec=av1 --cpu-used=1 --passes=2 --pass=2 --fpf=aom.pass  --target-bitrate=3500 --end-usage=cbr  --aq-mode=1 --bit-depth=8 --input-bit-depth=8  -o ReadySteadyGo.webm

I know these commands are simple I still don't know what exactly other option can do, still learning
what I'm doing here, simply I encode with CBR mode with 3500 kbps, x264 and x264 the yuv output option enabled, and vp9 when I finish with encoder I pass the output webm to decoder to get yuv file same with av1, then I'm using VQMT tool to compare between yuv files with the original one to get PSNR, SSIM....etc
https://github.com/Rolinh/VQMT

Is what I'm doing right or wrong?

when using pass 2, with the first pass I should not use the output option -o right? only for the second pass command

I saw some article about compression they use some graph to show the difference, on the x-axis (bitrate CBR with multiple values 2000,3500,4000..) then the y-axis there is PSNR or another metric, my question the psnr they suing is it the average psnr for the whole video or they compare certain frame with each codec ?


what is the codec used in DTH Broadcast ? are they use AVC?

[pandy]

Newer codec should deliver same quality at a half of bitrate when compared to previous codec generation. Forcing CBR doesn't sound correctly - this is artificial and suboptimal situation - VBR seem to be most optimal approach - for situation where some bitrate limitations exist you can specify VBV requirements - IMHO you should focus on quality than on bitrate...
I assume by DTH you mean satellite (DVB-Sx) - generally for SD MPEG-2 is used, for HD H.264 and for UHD H.265.

[fornit]

In your start post you have written, that you are working on a project about "Performance comparison of AV1, VP9, HEVC, AVC".

My question: Have you already defined for yourself what you mean, when you say "performance"? Possible meanings from my point of view:

1. Ratio of quality to file size
2. Decoding performance
3. Encoding performance
4. Level of maturity: Does it usually work fine in most cases?

Or maybe a mixture of those points?

Look e.g. at AV1: It's the candidate for the best ratio of quality to file size. But decoding and encoding performance are in a range that it's still far away from use in practice.

Or have a look at VP9: With the setting "--cpu-used=1" you'll get nice results but encoding performance will become horrible, so that you won't have fun with it if you try to encode a movie or so.
In general encoding performance is the main problem of VP9 from my point of view. And I guess that's the reason why nearly nobody will encode his Blu Rays in webm format.

With respect to CBR pandy has written enough. Forget it.

Above gdx has posted an interesting url:
http://goughlui.com/2016/08/27/video-compression-testing-x264-vs-x265-crf-in-handbrake-0-10-5/

In that example the authors compare different quality levels (crf). And they try to identify the qualtity levels where x264 and x265 can be considered as "transparent". I.e.: You won't notice a difference between the encoding and the original.

That's how I could imagine it:

• Do some encodings for each codec and try to identify the crf where transparency starts. You can also use your quality metrics for that. Of course that can differ from video to video. But I assume that an average value should be identifyable for each codec.
• Before you do that: Decide whether to use practical values for parameters like "--preset" (e.g.: medium or fast) and "--cpu-used" (e.g.: 4 for the 1st pass and 3 or 2 for the 2nd pass). Or do you want to use best quality parameters only?
• After you have identified those crf values do some encodings with those and compare ratio of quality to file size, decoding performance, encoding performance and maturity.
• Do your encodings for different resolutions. With constant quality x264 shows a linear relationship with respect to file size when resolution is increased. In contrast to that VP9 behaves logarithmically.

I've looked through your last encoding suggestions. Sorry, but for me they seem to be a bit inconsistent (2 pass ABR for x264 and x265, CBR for VP9 and AV1). Why not use ffmpeg for all instead of 4 different tools?