ср, 11 мар. 2026 г., 16:17 Terje J. Hanssen <[email protected]>:
On 11/03/2026 13:17, Andrew Randrianasulu wrote:
On Wed, Mar 11, 2026 at 2:14 PM Terje J. Hanssen via Cin <[email protected]> wrote:
On 10/03/2026 01:34, Andrew Randrianasulu wrote:
On Mon, Mar 9, 2026 at 7:22 PM Terje J. Hanssen <
[email protected]> wrote:
On 09/03/2026 11:28, Andrew Randrianasulu wrote:
You need to set remappig manually in (for single-user buld)
bin/ffmpeg/decode.opts
like
remap_video_decoder mpeg2video=mpeg2_qsv
and other similar lines if you want to test other formats (hevc, h264)
Thank you for quick response. After editing:
~/Applications/squashfs-root/usr/bin/ffmpeg # cat decode.opts # apply at init decode loglevel=fatal formatprobesize=5000000 scan_all_pmts=1 remap_video_decoder libaom-av1=libdav1d remap_video_decoder mpeg2video=mpeg2_qsv
Compilation of my test results as follows:
mpeg2 transcoded to h264_qsv.mp4
decoding in cpu/gpu Cingg: 265/300 fps ffmpeg: 548/562 fps
mpeg2 transcoded to hevc_qsv.mp4
decoding in cpu/gpu Cingg: 290/294 fps ffmpeg: - /688 fps
mpeg2 transcoded to av1_qsv.mp4
decoding in cpu/gpu Cingg: 251/325 fps ffmpeg: 631/698 fps
As seen the Cingg fps results are much slower than my system ffmpeg
results.
Is there any way to verify that decoding is done in the gpu like with ffmpeg?
Comment out remap line and retest? Watch nvtop or "intel gpu top" not sure if they discriminate between enc and decoding on Intel (it works on amd polaris12)?
As I said earlier we are not even supposed to be as fast as ffmpeg in ideal case because we roundtrip uncompressed video via system memory/bus.
I tried intel_gpu_top which has a video line (for total gpu use in % I think).
At least Cingg HW use device seemingly will output in the terminal if it is not supported as for:
Settings|Preferences|Performance|Use HW Device: vaapi Does it work better if you set Use hw device to none ?
Yes, as the previous results above, decoding cpu/gpu (before remap/after remap) But no speed benefit to set remap, results just within variations from time to time
You also can probably watch with top/conky/gkrellm if cpu usage goes down with qsv decoding case? Does decoding heavier (hevc?) examples change the picture?
A renewed test example:
av1_qsv ========
Settings|Preferences|Performance|Use HW Device: none
Decoding in GPU after remap remap_video_decoder mpeg2video=mpeg2_qsv
239-291 fps
-----------
Settings|Preferences|Performance|Use HW Device: vaapi
Decoder mpeg2_qsv does not support device type vaapi. HW device init failed, using SW decode. file:/Videoklipp/AV1/hdv09_04.m2t err: Operation not permitted ......
Render::render_single: Session finished.
** rendered 5972 frames in 20.875 secs, 286.084 fps audio0 pad 64 0 (64) malloc_consolidate(): unaligned fastbin chunk detected Aborted (core dumped) cin
===============
av1_qsv ========
Settings|Preferences|Performance|Use HW Device: none
Decoding in CPU before remap # remap_video_decoder mpeg2video=mpeg2_qsv
Render::render_single: Session finished.
** rendered 5972 frames in 20.001 secs, 298.585 fps audio0 pad 64 0 (64)
----------
Settings|Preferences|Performance|Use HW Device: vaapi
Decoding in cpu before remap # remap_video_decoder mpeg2video=mpeg2_qsv
int FFVideoConvert::convert_picture_vframe(VFrame*, AVFrame*, AVFrame*): Error retrieving data from GPU to CPU file: /Videoklipp/AV1/hdv09_04.m2t
Render::render_single: Session finished.
** rendered 5972 frames in 30.432 secs, 196.241 fps audio0 pad 64 0 (64)
Decoder libdav1d does not support device type vaapi. HW device init failed, using SW decode. file:/Videoklipp/QSV/hdv09-04_cin_av1_qsv_8b420.mp4 err: Operation not permitted Decoder libdav1d does not support device type vaapi. HW device init failed, using SW decode. file:/Videoklipp/QSV/hdv09-04_cin_av1_qsv_8b420.mp4 err: Operation not permitted
Decoder mpeg2_qsv does not support device type vaapi. HW device init failed, using SW decode. file:/Videoklipp/AV1/hdv09_04.m2t err: Operation not permitted ...... Render::render_single: Session finished. ** rendered 5972 frames in 20.875 secs, 286.084 fps audio0 pad 64 0 (64) malloc_consolidate(): unaligned fastbin chunk detected Aborted (core dumped) cin
-------
Yeah, of course Cingg and ffmpeg are not comparable with regards to
video format transcoding speed..
I guess their working principles, surely oversimplified, may be
something like this example:
Cingg: mpeg2 input --> decoding -->internal/raw format -->
decoding?--> encoding output
FFmpeg: mpeg2 input --> decoding --> encoding output
Therefore it's confusing where "remap_video_decoder
mpeg2video=mpeg2_qsv" decoding really should take place, from mpeg2 input --> internal/raw format rather than decoding before encoding output? somewhere inside libavcodec ...
On Sun, Mar 8, 2026 at 11:46 PM Terje J. Hanssen via Cin <[email protected]> wrote:
I have tested transcoding mpeg2video to h264_qsv, hevc_qsv, vp9_qsv and av1_qsv HW GPU accelerated decoding+encoding with ffmpeg. Just by adding "-hwaccel qsv" before the input file, the correct qsv codec for decoding in GPU apparently is auto-detected.
ffmpeg -hide_banner -hwaccel qsv -i hdv09_04.m2t -c:v hevc_qsv -y hdv09_04_ffmpeg_hevc_qsv.mp4
With a medium powerful (balanced) Intel Alder Lake (i7-12700KF) /DG2 (A750) the qsv.mp4 video output and playback are clean and faster with GPU decoding. For the legacy, limited SkyLake (h264_qsv) and Coffee Lake (hevc_qsv) igpu's, it is best to keep decoding in CPU, due to igpu buffer errors and some distortions on the playback.
So I wonder if it manageable to test-implement an additional environment variable "CIN_HW_DEV=qsv" for GPU HW decoding that adds "-hwaccel qsv" on the input side? If it works, it may be added as a "Use HW Device: qsv" next.
Terje J. H
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]