Re: [FFmpeg-user] amd hwaccel encoding + overlay filter is not working together
> I tried your way. Unfortunately it's not working. > time ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 > -hwaccel_output_format vaapi -i ../WK.0217/2024_0217_S0n000.mp4 -r 1 -i > 2024_0217_S0n000-f%04d.tiff -filter_complex > '[1:v]hwupload,format=vaapi[1v];[0:v][1v]overlay_vaapi' -r 7.5 -an -c:v > hevc_vaapi -crf 22 2024_0217_S0n000f-hwa2.mp4 > ... > [out#0/mp4 @ 0xe43b0cf1f80] Codec AVOption crf (Select the quality for > constant quality mode) has not been used for any stream. The most likely > reason is either wrong type (e.g. a video option with no video streams) or > that it is a private option of some encoder which was not actually used for > any stream. > Stream mapping: > Stream #0:0 (hevc) -> overlay_vaapi > Stream #1:0 (tiff) -> hwupload:default > overlay_vaapi:default -> Stream #0:0 (hevc_vaapi) > Press [q] to stop, [?] for help > [in#1/image2 @ 0xe43aee2ca00] Thread message queue blocking; consider > raising the thread_queue_size option (current value: 8) > [Parsed_overlay_vaapi_2 @ 0xe43b0cf2340] VAAPI driver doesn't support > [Parsed_overlay_vaapi_2 @ 0xe43b0cf2340] Failed to configure output pad > on > Parsed_overlay_vaapi_2 > [fc#0 @ 0xe43aee6a080] Error reinitializing filters! > Failed to inject frame into filter network: Invalid argument > Error while filtering: Invalid argument > [Parsed_overlay_vaapi_2 @ 0xe43b0cf2400] VAAPI driver doesn't support > overlay > [Parsed_overlay_vaapi_2 @ 0xe43b0cf2400] Failed to configure output pad > on > Parsed_overlay_vaapi_2 > [fc#0 @ 0xe43aee6a080] Error reinitializing filters! > Failed to inject frame into filter network: Invalid argument > [out#0/mp4 @ 0xe43b0cf1f80] Nothing was written into output file, because > at least one of its streams received no packets. > frame=0 fps=0.0 q=0.0 Lsize= 0kB time=N/A bitrate=N/A speed=N/A > > Conversion failed! > > real 3m57.578s > user 0m2.788s > sys 3m57.688s > > And an empty output. Is it possible that overlay_vaapi is not supported on > my cpu afterall? > It's a Ryzen 5800U. > > In the meantime, I came up with a different approach: do the decode and > overlay by the cpu, and use the gpu to encode the stream: > time ffmpeg -vaapi_device /dev/dri/renderD128 -i > ../WK.0217/2024_0217_S0n000.mp4 -r 1 -i 2024_0217_S0n000-f%04d.tiff > -filter_complex 'overlay,format=yuv420p,hwupload,scale_vaapi=format=nv12' > -r 7.5 -an -c:v hevc_vaapi -qp 22 2024_0217_S0n000f-hwa1.mp4 > [fc#0 @ 0x3a0550953a80] Error while filtering: Cannot allocate > memory3311.3kbits/s dup=0 drop=2922 speed=1.18x > Failed to inject frame into filter network: Cannot allocate memory > Error while filtering: Cannot allocate memory > [out#0/mp4 @ 0x3a0550986f80] video:212882kB audio:0kB subtitle:0kB > other > streams:0kB global headers:0kB muxing overhead: 0.003005% > frame= 981 fps=8.8 q=-0.0 Lsize= 212888kB time=00:02:10.66 > bitrate=13346.8kbits/s dup=0 drop=2933 speed=1.17x > Conversion failed! > > real 1m51.626s > user 20m40.850s > sys 0m14.040s > Though, it says, the conversion failed. But it encodes 981 frames. 2 frames > less compared to the case, when there's no acceleration et al. > If the only consequence is that the result will be 2 frame shorter than I > planned, I can solve that: I just need to add some bogus ending to the > videos, or cut longer the original slices. (Or just don't care about > missing 2 frames. Afterall, in a later phase, I add the audio back, concat > a lot of slice like this, than speed up to 30 fps, by dumping the video > stream, than generating PTS + atempo*4 -> At that speed, 2 missing frames > here and there doesn't really hurt.) > > I tried to fine tune your solution further: > Let the hwaccel do the decode, and hwdownload the video frame, then use > the > cpu for the overlay, then hwupload again... > But no luck again: > time ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 > -hwaccel_output_format vaapi -vaapi_device /dev/dri/renderD128 -i > ../WK.0217/2024_0217_S0n000.mp4 -r 1 -i 2024_0217_S0n000-f%04d.tiff > -filter_complex > '[0:v]hwdownload,format=yuv420p[0v];[0v][1:v]overlay,hwupload,format=vaa > pi' > -r 7.5 -an -c:v hevc_vaapi -crf 22 2024_0217_S0n000f-hwa3.mp4 > > [out#0/mp4 @ 0x2f69bfa76a40] Codec AVOption crf (Select the quality for > constant quality mode) has not been used for any stream. The most likely > reason is either wrong type (e.g. a video option with no video streams) or > that it is a private option of some encoder which was not actually used for > any stream. > File '2024_0217_S0n000f-hwa3.mp4' already exists. Overwrite? [y/N] y > Stream mapping: > Stream #0:0 (hevc) -> hwdownload:default > Stream #1:0 (tiff) -> overlay > format:default -> Stream #0:0 (hevc_vaapi) > Press [q] to stop, [?] for help > [in#1/image2 @ 0x2f69b8a7d400] Thread message queue blocking; consider > raising the thread_queue_size option (current value: 8) > There are 2 hardware devices. device vaapi1 of type vaapi is picked for > filters by default. Set
Re: [FFmpeg-user] QUESTION ABOUT VIDEO CODECS : LIBX264 vs LIBX265
Am 31.03.24 um 18:15 schrieb Hervé ANSELME: In other words, re-encoding with the x265 codec for the final video : can it improve the final video quality, compared to the source video, when the source video is encoded with x264? how should a lossy codec restore information dropped by the lossy codec in the past - after it's gone it will be gone forever ___ 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".
Re: [FFmpeg-user] Question about video codecs : libx264 vs libx265
Hervé ANSELME (12024-03-31): > I have a question about re-encoding a source video having libx264 video codec. > > Is there any advantage(s) to re-encode with the libx265, which is supposed to > give better result than libx264 ? > > In other words, re-encoding with the x265 codec for the final video : > can it improve the final video quality, compared to the source video, > when the source video is encoded with x264 ? You will never have a better quality than the original, of course.¹ Transcoding with a different codec that makes different compression decisions will not even let you get exactly the quality of the original content, but if you throw enough computing power you can get almost it with a smaller size. What you can get, and where it makes sense to transcode, is a smaller file with lower quality where the lost of quality is much smaller than the gain in size. 1: You might think you can get it with AI, but it only seems better quality. If you do it too much, like if you are trying to catch the face of a replicant reflected on a whisky glass, what you will get is bits of series from Amazon Studios in your videos. Regards, -- Nicolas George ___ 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".
Re: [FFmpeg-user] QUESTION ABOUT VIDEO CODECS : LIBX264 vs LIBX265
On Sun, 31 Mar 2024 at 19:15, Hervé ANSELME < hervea95-at-hotmail@ffmpeg.org> wrote: > Hi all, > > I have a question about re-encoding a source video having libx264 video > codec. > > Is there any advantage(s) to re-encode with the libx265, which is supposed > to give better result than libx264 ? > > In other words, re-encoding with the x265 codec for the final video : can > it improve the final video quality, compared to the source video, when the > source video is encoded with x264 ? > > Thanks for your answers. > > Regards, > HA > Quick answers: Is there any advantage(s) to re-encode with libx265, which is supposed to give better results than libx264 ? Yes, *if* the target bitrate(s) are expected to be lower to fit within specific constraints, such as live streaming and archival, and with an acceptable trade off in quality for saved bandwidth & storage. Even then, the target encoder(s) must be tuned specifically for the workload(s) in question. In other words, re-encoding with the x265 codec for the final video : can it improve the final video quality, compared to the source video, when the source video is encoded with x264 ? No, video quality will actually degrade. Both are lossy codecs by design. ___ 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".
Re: [FFmpeg-user] QUESTION ABOUT VIDEO CODECS : LIBX264 vs LIBX265
Hi all, I have a question about re-encoding a source video having libx264 video codec. Is there any advantage(s) to re-encode with the libx265, which is supposed to give better result than libx264 ? In other words, re-encoding with the x265 codec for the final video : can it improve the final video quality, compared to the source video, when the source video is encoded with x264 ? Thanks for your answers. Regards, HA There is absolutely no advantage other than probably getting a smaller filesize, but quality will degrade per definition as both H264 and H265 are lossy codecs. ___ 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] QUESTION ABOUT VIDEO CODECS : LIBX264 vs LIBX265
Hi all, I have a question about re-encoding a source video having libx264 video codec. Is there any advantage(s) to re-encode with the libx265, which is supposed to give better result than libx264 ? In other words, re-encoding with the x265 codec for the final video : can it improve the final video quality, compared to the source video, when the source video is encoded with x264 ? Thanks for your answers. Regards, HA ___ 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".
