Adding CIN_HW_DEV=qsv for GPU HW decoding?
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
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) 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]
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?
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 [email protected]
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.
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]
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 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?
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 [email protected]
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 ?
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]
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 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]
ср, 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]
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41 A bit slower fps and lower video% with remap hevc-> av1_qsv ============== # remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none intel_gpu_top Video: up to 25% ** rendered 5972 frames in 22.474 secs, 265.729 fps audio0 pad 64 0 (64) ---------------- remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none intel_gpu_top Video: up to 23% ** rendered 5972 frames in 26.549 secs, 224.943 fps audio0 pad 64 0 (64)
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]
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ... there is also way to set uniprocessor mode in preferences, and compare again using version with patch. And there was another command I forgot, set program to execute on specific cpus..
A bit slower fps and lower video% with remap
hevc-> av1_qsv ============== # remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 25%
** rendered 5972 frames in 22.474 secs, 265.729 fps audio0 pad 64 0 (64)
----------------
remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 23%
** rendered 5972 frames in 26.549 secs, 224.943 fps audio0 pad 64 0 (64)
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]
ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <[email protected]>:
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ...
there is also way to set uniprocessor mode in preferences, and compare again using version with patch.
And there was another command I forgot, set program to execute on specific cpus..
taskset -c 0 program
A bit slower fps and lower video% with remap
hevc-> av1_qsv ============== # remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 25%
** rendered 5972 frames in 22.474 secs, 265.729 fps audio0 pad 64 0 (64)
----------------
remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 23%
** rendered 5972 frames in 26.549 secs, 224.943 fps audio0 pad 64 0 (64)
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]
On 11/03/2026 16:34, Andrew Randrianasulu wrote:
ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <[email protected]>:
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ...
What about my own last build, does it have the patch? Cinelerra Infinity - built: Mar 2 2026 22:23:36
there is also way to set uniprocessor mode in preferences, and compare again using version with patch.
And there was another command I forgot, set program to execute on specific cpus..
taskset -c 0 program
A bit slower fps and lower video% with remap
hevc-> av1_qsv ============== # remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 25%
** rendered 5972 frames in 22.474 secs, 265.729 fps audio0 pad 64 0 (64)
----------------
remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 23%
** rendered 5972 frames in 26.549 secs, 224.943 fps audio0 pad 64 0 (64)
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]
On Wed, Mar 11, 2026 at 6:54 PM Terje J. Hanssen <[email protected]> wrote:
On 11/03/2026 16:34, Andrew Randrianasulu wrote:
ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <[email protected]>:
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ...
What about my own last build, does it have the patch? Cinelerra Infinity - built: Mar 2 2026 22:23:36
Unless you partially rebuilt it with patch - no. I thought you patched/rebuild it already ....
there is also way to set uniprocessor mode in preferences, and compare again using version with patch.
And there was another command I forgot, set program to execute on specific cpus..
taskset -c 0 program
A bit slower fps and lower video% with remap
hevc-> av1_qsv ============== # remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 25%
** rendered 5972 frames in 22.474 secs, 265.729 fps audio0 pad 64 0 (64)
----------------
remap_video_decoder mpeg2video=mpeg2_qsv Settings|Preferences|Performance|Use HW Device: none
intel_gpu_top Video: up to 23%
** rendered 5972 frames in 26.549 secs, 224.943 fps audio0 pad 64 0 (64)
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]
On 11/03/2026 17:28, Andrew Randrianasulu wrote:
On Wed, Mar 11, 2026 at 6:54 PM Terje J. Hanssen <[email protected]> wrote:
On 11/03/2026 16:34, Andrew Randrianasulu wrote:
ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <[email protected]>:
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ...
What about my own last build, does it have the patch? Cinelerra Infinity - built: Mar 2 2026 22:23:36
Unless you partially rebuilt it with patch - no.
I thought you patched/rebuild it already ....
I'll do a rebuild from git now, then it should be ok with the patch? (I thought remap was a standard function because there already was a remap line in decode.opts)
On 11/03/2026 17:36, Terje J. Hanssen wrote:
On 11/03/2026 17:28, Andrew Randrianasulu wrote:
On Wed, Mar 11, 2026 at 6:54 PM Terje J. Hanssen <[email protected]> wrote:
On 11/03/2026 16:34, Andrew Randrianasulu wrote:
ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <[email protected]>:
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ...
What about my own last build, does it have the patch? Cinelerra Infinity - built: Mar 2 2026 22:23:36
Unless you partially rebuilt it with patch - no.
I thought you patched/rebuild it already ....
I'll do a rebuild from git now, then it should be ok with the patch? (I thought remap was a standard function because there already was a remap line in decode.opts)
Seeminly not yet: git clone https://git.cinelerra-gg.org/goodguy/cinelerra.git Cloning into 'cinelerra'... fatal: unable to access 'https://git.cinelerra-gg.org/goodguy/cinelerra.git/': The requested URL returned error: 502
On Wed, Mar 11, 2026 at 7:36 PM Terje J. Hanssen <[email protected]> wrote:
On 11/03/2026 17:28, Andrew Randrianasulu wrote:
On Wed, Mar 11, 2026 at 6:54 PM Terje J. Hanssen <[email protected]> wrote:
On 11/03/2026 16:34, Andrew Randrianasulu wrote:
ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <[email protected]>:
ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <[email protected]>:
On 11/03/2026 15:07, Andrew Randrianasulu wrote:
ср, 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?
RPM Cinelerra Infinity - built: Mar 1 2026 06:30:41
khm, rpm does not have this patch .... so with or without remap it should be nearly the same? Strange it is not ...
What about my own last build, does it have the patch? Cinelerra Infinity - built: Mar 2 2026 22:23:36
Unless you partially rebuilt it with patch - no.
I thought you patched/rebuild it already ....
I'll do a rebuild from git now, then it should be ok with the patch?
sorry no I attached patch to earlier email, so you need to save it and apply and rebuild Just attaching both patches again
(I thought remap was a standard function because there already was a remap line in decode.opts)
participants (2)
-
Andrew Randrianasulu -
Terje J. Hanssen