ср, 11 мар. 2026 г., 18:32 Andrew Randrianasulu <randrianasulu@gmail.com>:

ср, 11 мар. 2026 г., 18:19 Terje J. Hanssen <terjejhanssen@gmail.com>:

On 11/03/2026 15:07, Andrew Randrianasulu wrote:

ср, 11 мар. 2026 г., 16:17 Terje J. Hanssen <terjejhanssen@gmail.com>:

On 11/03/2026 13:17, Andrew Randrianasulu wrote:
> On Wed, Mar 11, 2026 at 2:14 PM Terje J. Hanssen via Cin
> <cin@lists.cinelerra-gg.org> wrote:
>>
>>
>> On 10/03/2026 01:34, Andrew Randrianasulu wrote:
>>
>> On Mon, Mar 9, 2026 at 7:22 PM Terje J. Hanssen <terjejhanssen@gmail.com> 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
>> <cin@lists.cinelerra-gg.org> 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 -- cin@lists.cinelerra-gg.org
>> To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
>>
>>
>>
>> _______________________________________________
>> Cin mailing list -- cin@lists.cinelerra-gg.org
>> To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org