Den 09.11.2024 17:16, skrev Andrew Randrianasulu:
Den 09.11.2024 10:48, skrev Terje J.
Hanssen:
Den 09.11.2024 00:10, skrev Andrew
Randrianasulu:
Den 07.11.2024 22:53, skrev
Terje J. Hanssen:
Den 07.11.2024 20:41,
skrev Andrew Randrianasulu:
sorry
I mean set
like this
export
CIN_10BIT_ENC=1
Now hevc_vaapi was
able to render to
yuv420p10le, that
is 10-bit 420p, by
selecting pixels
p010le.
Also rendering
with pixels y210
resulted in
yuv420p10le, that
is not 10-bit 422p
as for hevc_qsv
below.
I would assume
this is caused due
to the incomplete
hevc_vapi.mp4
preset as shown
below?
More like
incomplete code that
does not yet know how to
get custom format ... so
far as name says it only
adds 10bit 4:2:0
encoding, not 4:2:2
subsampling.
can you
test other vaapi/qsv
profiles too?
also with
test picture actually
containing more than
8bit values? ;)
To the latter; the input file
cfhd01.mkv was 10bit 422:
yuv422p10le
Maybe have a look at and
compare with the hevc_qsv code
that managed 10bit 422:
yuv422p10le?
Summary
----------------
hevc_vaapi.mp4 and av1_vaapi.mp4
Pixels: vaapi (default and
only option) works and results
in yuv420p
p010 or p010le
written works and result in
yuv420p10le
y210 or all
variants y210le/Y210/le render
(with fallback) to yuv420p10le
h264_vaapi.mp4 didn't render
(error message)
yeah, no 10bit h264 here
(while possible by spec)
av1_qsv.mp4 is for external
ffmpeg
if you still have my
onevpl patch applied (and enabled it
earlier with configure switch) too -
qsv should work ...
try it too just in case?
av1_qsv.mp4
Would not render at all
[av1_qsv
@ 0x7fe19826f240] Current picture
structure is unsupported
[av1_qsv
@ 0x7fe19826f240] some encoding
parameters are not supported by the QSV
runtime. Please double check the input
parameters.
FFMPEG::open_encoder
err: Function not implemented
int
FFMPEG::open_encoder(const char*, const
char*):
open
failed
av1_qsv:/Videoklipp/Cineform/cfhd01_av1_qsv_pix_nv12.mp4
Render::render_single:
Session finished.
hevc_qsv.mp4
Does render, but only to yuv420p now.
For one or another reason pixel formats
p010le and y210le results in yuv420p.
That is I am not able to reconstruct the
previous 10bit results below.
I do another attempt next day.
hevc_qsv.mp4 revised:
pixel formats p010le and y210le render again
to yuv420p10le and .yuv422p10le respectively
Woops; only when these window lines are
commented out as written in my previous post !
#
profile=main
# cin_pix_fmt=nv12
Works both with and without
export CIN_10BIT_ENC=1
before cin/bin
we most likely will need new profiles
for 10bit everything anyway ...
thanks for continued (and very
exhaustive!) testing
Also the preset's combination of pixel formats and the
right (ffmpeg) codec profiles would need an overhaul.
As mentioned already above:
hevc_qsv.mp4 revised:
pixel formats p010le and y210le render again to
yuv420p10le and .yuv422p10le respectively
Woops; only when these window lines are commented out as
written in my previous post !
#
profile=main
#
cin_pix_fmt=nv12
I experimented additional and got
y210/profile=1 ==> yuv422p10le
y210/ profile=main10/ profile=2/ profile=3 ==>
yuv420p10le
I got similar results with my own dynamic Cingg built with
ffmpeg 7.1.
--------------------------
So a question beside:
Yesterday I did a new (monthly) upgrade of
Tumbleweed-Slowroll, which replaced Packman package libs
and ffmpeg 7.1
After that, the static Cingg with onevpl and 10bit patch
would not render hevc_qsv.
Today's upgrade with new Packman packages up-to-date with
the new Slowroll version, and now Cingg worked as before:
ffmpeg-7 ffmpeg-7-libavcodec-devel
ffmpeg-7-libavdevice-devel ffmpeg-7-libavfilter-devel
ffmpeg-7-libavformat-devel ffmpeg-7-libavutil-devel
ffmpeg-7-libpostproc-devel ffmpeg-7-libswresample-devel
ffmpeg-7-libswscale-devel libavcodec61 libavdevice61
libavfilter10 libavformat61 libavutil59 libpostproc58
libswresample5 libswscale8
So even Cingg with onevpl is static built, it looks like
it is dependent of one or more system packages/libs
beside?
Any idea what packages it can be ?