Arch Linux

accidently hit enter...

Description:

current extra/ffmpeg 2:4.4.1-1 and extra/svt-av1 0.9.0-1 seem not to fit anymore

with svt-av1 0.8.7-1 following commandline still worked

/usr/bin/ffmpeg -i <input> -c:v libsvtav1 -qp 28 -b:v 0 -c:a libopus -b:a 128k -map 0:0 -map 0:1 -vf "fps=25,format=yuv420p"
<output>

now it ends with error. Will add error detail later as I am currently transcoding with the old svt-av1 version
(do not want to upgrade version with active program running).

Steps to reproduce:
execute the above with e.g. mpeg ts as input.

Hello,

so the error is as follows:

Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v0.9.0-dirty
Svt[info]: SVT [build] : GCC 11.1.0 64 bit
Svt[info]: LIB Build date: Jan 22 2022 06:46:34
Svt[info]: -------------------------------------------
Svt[error]: Instance 1: Encoder Bit Depth shall be only 8 or 10
Svt[error]: Instance 1: The encoder bit depth shall be equal to 8 or 10 for Main/High Profile
Svt[error]: Instance 1: Invalid Compressed Ten Bit Format flag [0 - 1]
[libsvtav1 @ 0x5587e2232840] Error setting encoder parameters: bad parameter (0x80001005)
SvtMalloc[info]: you have no memory leak
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

As a workaround for the time being, you can pipe ffmpeg output to SvtAv1EncApp. For example, as shown here: http://trac.ffmpeg.org/ticket/9610

When using ffmpeg libraries for libsvtav1 encoding, the same error occurs when calling avcodec_open2(). I could not find a workaround for this, as there is no bit depth field neither at AVCodecContext and at libsvtav1 options. Probably it will require an upstream fix.

This issue is solved for me in ffmpeg package, now at version 5.0. Probably it may require a fix for ffmpeg4.4 package, or maybe disable svt-av1 support on it.

I think this issue can now be closed.

@stkain Can you confirm that it's fixed for you too with ffmpeg 5.0?

Hello Daniel,

thank you for your help!

I can confirm that the original issue does not occur with the current packages in a sense.
the original incantation works now. But with the new release the resulting quality
is basically unusable. ("ghost"-effects in moving parts of a scene)
So I will continue with your proposed solution of piping ffmpeg
output into the svt-executable which yields good results.
I guess we have to wait for upstream ffmpeg to become able to forward detailed options to the svt encoder
or send more sensible options to the encoder.

Bye,
Stefan

ffmpeg git master added proper support for svt-av1 0.9.0.

Applying these two patches on top of ffmpeg 5.0 makes it to work fine for me with acceptable quality, both at the command line and with the C library API:

https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/c33b4048859a191acf9b6aa22acaea248a4eb18f
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/1dddb930aaf0cadaa19f86e81225c9c352745262

There are also other patches upstream, but I think that only these are needed, since the others mostly change/deprecate options.

It can be also tested by using ffmpeg-git from the AUR.

Replacing the ffmpeg package with the AUR ffmpeg package is complicated.
If I try, the package manager tells me that it breaks the dependencies required by chromaprint, freedp and mpv.
For the time being, I do the conversions with the following two commands:
ffmpeg -i Infile.mp4 -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 6 --keyint 240 --input-depth 10 --crf 30 --rc 0 --passes 1 --film-grain 0 -b Outfile.ivf
and then :
ffmpeg -i Outfile.ivf -i Infile.mp4 -map 0:v -map 1:a:0 -c:v copy -c:a copy FinalProduct.mp4
It would be so much more convenient to pass all the options to FFmpeg directly than to go through SvtAv1EncApp as it is currently the case.

Can you give v5.1 a try? Just pushed it in [extra].

Hi Maxime, sorry for the late reply.
can you reopen. I can report on my experiences with the new version.

Bye,
Stefan

Hi Stefan, no problem. It's been reopened for 2 weeks now though, will close again if I don't hear anything from you by the end of the week.

Hi,

I tested the latest version. It works now and has quite good performance compared to the "piping" solution. (factor 2-3 faster)
Yet the resulting files are 25% larger for the same quality setting.

Bye,
Stefan