On 2025-02-28 22:00, Dragan Randjelovic wrote:
Hi Vladimir,
I have noticed that you were strugling, try using the following:
scale_vaapi=w=-1:h=-1 ensures hardware scaling before overlay (source
resolution is kept with -1)
Thank you for your reply. I'm verry sorry to say, however, that it
doesn't help me much, if at all:
ffmpeg -init_hw_device vaapi=hw -filter_hw_device hw \
-i rtmp://localhost/stream1 \
-i rtmp://localhost/stream2 \
-filter_complex "
[0:v]format=nv12,hwupload=extra_hw_frames=20,scale_vaapi=w=-1:h=-1[i0];
[1:v]format=nv12,hwupload=extra_hw_frames=20,scale_vaapi=w=-1:h=-1[i1];
[i0][i1]overlay_vaapi"
-c:v h264_vaapi -global_quality 25 -g 50 -r 25 -an -f null -
This command works perfectly already without any "scale_vaapi" filter
regardless of the input streams' resolutions. However, it uses software
decoding, which is evident by the lack of "-hwaccel vaapi
-hwaccel_output_format vaapi" arguments for inputs, and also by the use
of the hwupload filters.
Setting extra_hw_frames=20 does reduce memory usage indeed. I've seen
the recommendation to keep it relatively high (around 100) to reduce the
risk of issues during encoding. But I don't much care about memory usage
anyway since I have a lot of memory to spare.
Just in case there's been a misunderstanding, let me repeat the command
that uses a purely hardware transcoding pipeline, and which works only
when input streams have the same resolution:
ffmpeg \
-hwaccel vaapi -hwaccel_output_format vaapi -i rtmp://localhost/stream1
\
-hwaccel vaapi -hwaccel_output_format vaapi -i rtmp://localhost/stream2
\
-filter_complex "[0:v][1:v]overlay_vaapi=w=500" \
-c:v h264_vaapi -global_quality 25 -g 50 -r 25 -an -f null -
And no, putting "scale_vaapi" before overlay here does not help.
P.S. I'm wondering if this recommendation was written by AI, by the way.
Regards
Dragan Randelovic
On Fri, Feb 28, 2025 at 6:37 PM Vladimir Mishonov via ffmpeg-user
<ffmpeg-user@ffmpeg.org> wrote:
On 2025-02-28 19:53, Greg Oliver wrote:
On Thu, Feb 27, 2025 at 11:49 PM Vladimir Mishonov via ffmpeg-user <
ffmpeg-user@ffmpeg.org> wrote:
Sorry - that link I referenced actually did not have the whole
thread.
The
piece I intended to be included was:
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2024-September/058652.html
Unfortunately, the -noautoscale option does not work either, I've
already tried that before.
It is, however, not surprising that it has no effect because
-noautoscale is an output option. And in my scenario, the output
resolution does not change over time.
As for the patch linked in that thread, I have yet to try it. Not sure
if it's already been merged into master; if not, it means I have to
compile a build myself, and setting everything up for that is likely
going to take a while...
If that does not solve it - sorry - I do not use QSV (except in Plex)
for
anything - I just remembered seeing that email thread a while back,
so
looked it up. This one has a resolution, but I am unsure if it is
software
or hardware.
No problem. What I still cannot understand is whether this is some
kind
of fundamental limitation or an outright bug. For some reason, I could
find very little information about this particular scenario. Whenever
I
search for that error message ("impossible to convert between..."), it
always seems to concern a completely different use case.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
