Re: [FFmpeg-user] How to preserve file time
Am 20.08.24 um 21:59 schrieb Rob Hallam: It is unlikely at this point you will receive an argument you deem applicable. A call to an OS function is not the same as managing filesystem-level metadata. If you really want it, it is possible for you to write and maintain your own small patch that provides this option and compile your own ffmpeg. Thanks for your arguments, which are worth to think about. As you see from the arguments of James Ralston, the funcionality around the '-y' option is not that simple, as one – especially Harald – might think. Well, in the end, "managing filesystem-level metadata", is also just an "OS call". Since James' arguments, I now have the impression that the implementation of my suggestion might even be easier than the correct handling of the “don't overwrite silently” functionality, at least from the OS call side. But it is like it is, there is no vote for my proposal. ___ 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] How to preserve file time
Am 20.08.24 um 21:33 schrieb Ulf Zibis: Am 14.08.24 um 17:20 schrieb Ulf Zibis: Am 12.08.24 um 19:04 schrieb Mark Filipak: That's a question for your operating system. I can change file times to whatever I want via the TotalCommander file browser. There are probably others. Isn't removing existing output files samely a question for the OS ? But for convenience FFmpeg CLI provides option `-y` for this task, so why not thinking about conveniently preserving file times by FFmpeg CLI? There seems some need to outline and precise my original message. 1. For the security of existing data and in some way for convenience (avoid the need to create the potentially overwritten data again) FFmpeg CLI does not silently overwrite existing files. This requires an additional OS filsystem operation (test for existing files with same name) irrelevant 2. For additional convenience FFmpeg provides option '-y' to prevent the user from manually deal with existing files. This requires 2 additional OS filsystem operations (write a message to system output stream + read and parse from system input stream). this is not true because "-y" the default from filesystem / OS view of point and needs no action 5. I'm sure, that anyone with a minimum of smartness was able to understand my original message. anyobdy with smartness considers jumping out of the window by all your nonsense ___ 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] How to preserve file time
Am 21.08.24 um 10:40 schrieb Ulf Zibis: Am 20.08.24 um 21:59 schrieb Rob Hallam: It is unlikely at this point you will receive an argument you deem applicable. A call to an OS function is not the same as managing filesystem-level metadata. If you really want it, it is possible for you to write and maintain your own small patch that provides this option and compile your own ffmpeg. Thanks for your arguments, which are worth to think about. As you see from the arguments of James Ralston, the funcionality around the '-y' option is not that simple, as one – especially Harald – might think. IT IS AS SIMPLE [harry@srv-rhsoft:/downloads]$ echo "X" > test.txt [harry@srv-rhsoft:/downloads]$ cat test.txt X [harry@srv-rhsoft:/downloads]$ echo "Y" > test.txt [harry@srv-rhsoft:/downloads]$ cat test.txt Y ___ 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] How to preserve file time
I'm sorry this mail is going to be rather long. However, I would
like to explain my opinion on this matter in detail.
I would also like to kindly ask everybody to calm down and refrain
from further ad-hominem attacks, because these are not going to make
things better for anybody.
Ulf Zibis wrote:
> As you see from the arguments of James Ralston, the funcionality around the
> '-y' option is not that simple, as one – especially Harald – might think.
I agree. In fact I think that the logic around the -y option (and its
absence) is not very well implemented in FFmpeg currently. But that's
a different topic; we're certainly not going to fix that here and now.
> Well, in the end, "managing filesystem-level metadata", is also just an "OS
> call".
> Since James' arguments, I now have the impression that the implementation of
> my suggestion might even be easier than the correct handling of the “don't
> overwrite silently” functionality, at least from the OS call side.
Well, I'm not sure who brought up the "OS call" argument -- and why.
I think that point is rather irrelevant, or at least very weak.
FFmpeg already does *lots* of OS calls, either directly or indirectly
(via 3rd-party libraries). Just run a truss(1), ktrace(1), strace(1)
(or whatever your operating system provides to trace system calls)
on the FFmpeg binary to get an impression. So it really doesn't
matter if there are two OS calls more or less.
So, then what are the pros and cons of the proposed wish?
On the pro side, one user (Ulf) obviously has a use case for this
kind of feature. However, so far, nobody else has stepped forward,
explaining that he would need that feature, too.
So, to be fair, this proposal is about a convenience option that
appears to benefit very few people (maybe just one).
And what are the cons?
Keep in mind that the meaning of the "mtime" time stamp (in POSIX
terms) is the last modification time of the file contents. When a
new file (with new contents) is created, it is obvious that the mtime
should be set to the creation time of the file. This is what the
operating system does by default, and it is what users expect, and
I'm not aware of any program that overrides it -- except for cp(1)
when the -p option is used, but it makes sense that cp(1) provides
such a convenience option because it does not create new content,
and there are often use cases where you need an identical copy of
a file including metadata (note that "cp -p" does not only copy the
mtime, but also other metadata).
On the other hand, FFmpeg *always* creates new content (*).
Therefore, the default behaviour of the OS to assign an updated mtime
to the output files is almost always what is desired. An option to
override that behaviour would only very rarely be useful.
Note that the OS also does other things by default. For example, it
assigns a group to newly created files. The details depend on the
operating system and on the mode bits of the directory: It may be the
group of the directory, or it may be the primary group of the user.
There might be cases where the user wants to override the default
group selection of the operating system -- do you think that FFmpeg
should have an option for this? I don't think so. You can easily
use an OS command to change the group if desired. Exactly the same
holds true for the mtime.
In fact, I can rather imagine use cases to preserve the *atime*
(access time) of the input files, rather than overriding the mtime
of output files. So, in my opinion, an option to reset the atime
when FFmpeg is finished would be more useful (and it would be much
easier to implement). But I wouldn't propose it either, because it
can be trivially done with an OS command, too.
There are two further cons that are important.
First, note that every single write access to output files refreshes
their mtime. That means that the setting of the mtime would be the
very last thing that FFmpeg had to do before it exits, after closing
the output files. But what if FFmpeg terminates unexpectedly, e.g.
because of a critical error or because of an OS signal? In that case,
the mtime would not be set as desired. Therefore it is better to
do that with a separate OS command afterwards ("touch", as has been
mentioned several times).
Second, implementing the proposed option correctly is actually very
non-trivial, especially considering that there can be multiple input
files and multiple output files, and there needs to be some syntax
and built-in logic for mapping mtime from input files to output files
(not to mention that all of that needs to be documented, too).
(My personal opinion: FFmpeg's existing -map* options are already
complicated enough; we don't really need more of that.)
In other words, it requires a certain amount of time and effort from
developers. All of that for a very rare use case that can trivially
be solved by running an OS command afterwards? It is very unlikely
that this is going to happen.
By
Re: [FFmpeg-user] How to preserve file time
Am 21.08.24 um 10:56 schrieb Reindl Harald: Am 20.08.24 um 21:33 schrieb Ulf Zibis: There seems some need to outline and precise my original message. 1. For the security of existing data and in some way for convenience (avoid the need to create the potentially overwritten data again) FFmpeg CLI does not silently overwrite existing files. This requires an additional OS filsystem operation (test for existing files with same name) irrelevant Yes – according your definition of NOTHING. 2. For additional convenience FFmpeg provides option '-y' to prevent the user from manually deal with existing files. This requires 2 additional OS filsystem operations (write a message to system output stream + read and parse from system input stream). this is not true because "-y" the default from filesystem / OS view of point and needs no action In this case I agree with you. I mixed up things. So for 1. it must be additionally: In case of output file existence 2 additional OS operations are needed and executed: Write a message to system output stream + read and parse users answer from system input stream. As discovered by James Ralston, the current implementation seems not really secure. And for 2. it must be: For additional convenience FFmpeg provides option '-y' to prevent the user from manually deal with existing files. This option dependently allows to skip the 2 additional OS operations above. anyobdy with smartness considers jumping out of the window by all your nonsense To finish this discussion: Just show your IQ-test certificate. ;-) ___ 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] How to preserve file time
Oliver Fromme (12024-08-21): > I'm sorry this mail is going to be rather long. However, I would > like to explain my opinion on this matter in detail. You are more patient than this issue deserves. > In fact, I can rather imagine use cases to preserve the *atime* > (access time) of the input files, rather than overriding the mtime > of output files. So, in my opinion, an option to reset the atime > when FFmpeg is finished would be more useful (and it would be much > easier to implement). But I wouldn't propose it either, because it > can be trivially done with an OS command, too. That is not entirely true. *Restoring* the atime can easily be done with an OS command, but it is an aberration that will trigger an update to the ctime. Do not do that. *Preserving* the atime cannot be done with a simple OS command, it requires a flag on the open() system call (and corresponding permission). rsync has the option: --open-noatime This tells rsync to open files with the O_NOATIME flag (on sys‐ tems that support it) to avoid changing the access time of the files that are being transferred. If your OS does not support the O_NOATIME flag then rsync will silently ignore this option. Note also that some filesystems are mounted to avoid updating the atime on read access even without the O_NOATIME flag being set. But rsync is a synchronization tool, and synchronizing without altering is a very important feature. > (*) Well, in theory you can use FFmpeg to make a 1:1 copy (-map 0, > same container), but even then details will usually be different Add -f data and you will have an exact binary copy. 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] How to preserve file time
Am 21.08.24 um 12:48 schrieb Ulf Zibis: So for 1. it must be additionally: In case of output file existence 2 additional OS operations are needed and executed: Write a message to system output stream + read and parse users answer from system input stream. As discovered by James Ralston, the current implementation seems not really secure. And for 2. it must be: For additional convenience FFmpeg provides option '-y' to prevent the user from manually deal with existing files. This option dependently allows to skip the 2 additional OS operations above. for the sake of god no - it's the exactly opposite For convenience ffmpeg saves you from accidently overwrite existing files - in your world the tail wags the dog [harry@srv-rhsoft:/downloads]$ echo "X" > test.txt [harry@srv-rhsoft:/downloads]$ cat test.txt X [harry@srv-rhsoft:/downloads]$ echo "Y" > test.txt [harry@srv-rhsoft:/downloads]$ cat test.txt Y ___ 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] How to preserve file time
On Wed, 21 Aug 2024 at 12:15, Nicolas George wrote: > > Oliver Fromme (12024-08-21): > > I'm sorry this mail is going to be rather long. However, I would > > like to explain my opinion on this matter in detail. > > You are more patient than this issue deserves. I enjoyed reading Oliver's explanation so I appreciate the time it must have taken to write it. In my mind the case against implementing boils down to: "this is a feature which has limited desire; it seems trivial but it actually isn't to do properly*; and it lies outside ffmpeg's area of responsibility so other tools can be used to handle it". Hopefully the detailed explanation is acceptable to Ulf. * It might seem easy since the `touch' invocation is simple, but would have to handle not only different platforms but also filesystems, the combinatorial complexity introduced by multiple inputs and outputs that Oliver and others have mentioned, parsing of user input, a suite of tests to cover all that, and ongoing maintenance if there are any bugs. Cheers, Rob ___ 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] How to preserve file time
Am 21.08.24 um 12:45 schrieb Oliver Fromme: I'm sorry this mail is going to be rather long. However, I would like to explain my opinion on this matter in detail. Hollala, thanks for your effort. German accuracy? ;-) Well, I'm not sure who brought up the "OS call" argument -- and why. I think that point is rather irrelevant, or at least very weak. Much thanks for that understanding !!! And what are the cons? Keep in mind that the meaning of the "mtime" time stamp (in POSIX terms) is the last modification time of the file contents. When a new file (with new contents) is created, it is obvious that the mtime should be set to the creation time of the file. This is what the operating system does by default, and it is what users expect, Agreed, so it should never be the default behaviour. In case of mtime is "manipulated", one can substitutionally refer the "creation time" (on Linux a kind of hidden and not available on very old kernels). * On the other hand, Linux NTFS, FAT and exFAT drivers mostly associate Windows "creation time" with Linux ctime. and I'm not aware of any program that overrides it I've seen this plenty of times. The one, which instantly comes in memory is IrfanView. There it's my standard setting. From there I was inspired for my proposal. I also remember some MP3-tag editors, which provide that. An option to override that behaviour would only very rarely be useful. To me it's very useful. Imagine you have huge collection of pictures and videos. If I do some compression later, preserving the mtime allows me to simply use the file manager for listing the files in their right order. Also e.g. image viewers normally refer the mtime for the order in a "slide show". For image compression I can conveniently use IrfanView for that requirement. But for videos I have to use FFMPEG, where I painfully miss that option. ... do you think that FFmpeg should have an option for this? Not really. (It could be named '--preserve-file-metadata' ;-) ) So I change my proposal to name the option '--preserve-mtime', it's anyway shorter. First, note that every single write access to output files refreshes their mtime. That means that the setting of the mtime would be the very last thing that FFmpeg had to do before it exits, after closing the output files. But what if FFmpeg terminates unexpectedly, e.g. because of a critical error or because of an OS signal? In that case, the mtime would not be set as desired. The same problem occurs with other options, e.g. '-movflags +faststart'. I think that culprit is acceptable. Second, implementing the proposed option correctly is actually very non-trivial, especially considering that there can be multiple input files and multiple output files, and there needs to be some syntax and built-in logic for mapping mtime from input files to output files (not to mention that all of that needs to be documented, too). Agreed, that this is the only non-trivial part. But the logic behind already exists, see my comment: https://trac.ffmpeg.org/ticket/11139#comment:3 (My personal opinion: FFmpeg's existing -map* options are already complicated enough; we don't really need more of that.) Right. But one can reuse them, and I believe, that most of the complicated side paths with '-map*' are not needed here. By the way, there are a lot more complications. For example, there are input streams that consist of multiple files. Think about the concat demuxer. How to handle that? Another typical case are VOBSUB subtitles that consist of two files (*.sub and *.idx). What if they have different mtimes -- which one should be taken? What if an input is a network stream -- should FFmpeg try to parse the "Last- Modified" header? What if there is no such header? What if an input file is a pipe, a FIFO or standard input? Even if you can answer these questions for yourself, others might think differently about such cases. And these are just some cases from the top of my head; you'll probably find many more when you read through the manual page. if the user idiotically maps the '--preserve-mtime' option to such streams, just ignore the option or throw an error message. Regards, -Ulf ___ 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] How to preserve file time
Am 21.08.24 um 14:39 schrieb Ulf Zibis: Second, implementing the proposed option correctly is actually very non-trivial, especially considering that there can be multiple input files and multiple output files, and there needs to be some syntax and built-in logic for mapping mtime from input files to output files (not to mention that all of that needs to be documented, too). Agreed, that this is the only non-trivial part. But the logic behind already exists, see my comment: https://trac.ffmpeg.org/ticket/11139#comment:3 Or just define the option to refer to the first appropriate input (e.g. not subtitles, not network streams ...). -Ulf ___ 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] How to preserve file time
Am 21.08.24 um 14:39 schrieb Ulf Zibis: and I'm not aware of any program that overrides it I've seen this plenty of times. The one, which instantly comes in memory is IrfanView. There it's my standard setting. From there I was inspired for my proposal. I also remember some MP3-tag editors, which provide that. Or jpeg / exif manipulation tools. ___ 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] How to preserve file time
Am 21.08.24 um 14:39 schrieb Ulf Zibis: To me it's very useful. Imagine you have huge collection of pictures and videos. If I do some compression later, preserving the mtime allows me to simply use the file manager for listing the files in their right order when you have a huge collection you do the convesion with a script anyways - so it's one line in that same script - case closed anyways: the problem with your whole argumentation is that you still think ffmpeg has anything to do actively for overwrite file which isn't the 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] Linux AMD 64 Static Build Question
I am having an issue with drawtext not being found as a valid filter with the amd64 builds (7.0.1 release and git) on John VanSickle’s builds. It does work for version 6.1. (https://johnvansickle.com/ffmpeg/). I have sent emails to him but I have not received a response. I looked at the build information on his site and I see libharfbuzz listed but when I run ffmpeg -version it does not show libharfbuzz as enabled. Is there another static build site for the amd64 builds? Anybody have any advice? Thank you! ___ 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] Failed setup for format vulkan: hwaccel initialisation returned error for Arc A750
Den 15.08.2024 20:29, skrev Terje J. Hanssen: tor. 15. aug. 2024, 13:27 skrev Wang, Fei W : On Wed, 2024-08-14 at 22:43 +0300, Dennis Mungai wrote: > On Wed, 14 Aug 2024 at 15:27, Terje J. Hanssen > wrote: > > > > > > Den 14.08.2024 14:22, skrev Dennis Mungai: > > > > > On Wed, Aug 14, 2024, 15:15 Terje J. Hanssen > > > wrote: > > > > > > > > > > > > > > > Den 14.08.2024 02:05, skrev Dennis Mungai: > > > > > > > > > On Wed, 14 Aug 2024, 02:59 Dennis Mungai, > > > > > wrote: > > > > > > > > > > > On Wed, 14 Aug 2024, 02:45 Terje J. Hanssen, > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Den 13.08.2024 19:40, skrev Dennis Mungai: > > > > > > > > > > > > > > > On Tue, 13 Aug 2024 at 19:49, Andrew Randrianasulu > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > вт, 13 авг. 2024 г., 19:46 Terje J. Hanssen > > > > > > > > > : > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I try to test Vulkan h264 or h265 decoding > > > > > > > > > > according to test command at > > > > > > > > > > https://trac.ffmpeg.org/wiki/HWAccelIntro#Vulkan > > > > > > > > > > ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel > > > > > > > > > > vulkan > > > > > > > > > > -hwaccel_output_format vulkan -i INPUT -f null - - > > > > > > > > > > benchmark > > > > > > > > > > > > > > > > > > > > but get the following output error: > > > > > > > > > > [h264 @ 0x55952760cf40] Failed setup for format > > > > > > > > > > vulkan: hwaccel > > > > > > > > > > initialisation returned error. > > > > > > > > > > or > > > > > > > > > > [hevc @ 0x5580e96e8c80] Failed setup for format > > > > > > > > > > vulkan: hwaccel > > > > > > > > > > initialisation returned error. > > > > > > > > > > > > > > > > > > > > Any suggestion how to solve it? > > > > > > > > > > > > > > > > > > > Honestly, no idea .. try ffmpeg matrix/irc channel or > > > > > > > > > ffmpeg-user? > > > > > > > > > > > > > > > > > This has to do with your input file. Your log indicates > > > > > > > > that you're > > > > > > > > attempting to decode 10-bit H.264, and from my > > > > > > > > suspicion, almost zero GPUs > > > > > > > > implement 10-bit H.264 decode. > > > > > > > > You can verify via vainfo's output to see the decoder > > > > > > > > limitation(s) for > > > > > > > > H.264 levels, etc. > > > > > > > > Try decoding any of the sample file from Kodi's H.264 > > > > > > > > sample collection: > > > > > > > > https://kodi.wiki/view/Samples#Codecs,_Framerates,_Blac > > > > > > > > k-levels_and_Subtitles > > > > > > > > And report back. > > > > > > > > ___ > > > > > > > > > > > > > > > > > > > > > > 1) Thank you for your suspicion regarding almost zero > > > > > > > GPUs implement 10-bit H.264 decode. > > > > > > > This is obviously true in my case, because when I tested > > > > > > > a h264 8-bit yuv420p file, the hwaccel > > > > > > > initialisation error was away. Full ffmpeg output report > > > > > > > below using my own encoded input file. > > > > > > > (Even with a h264 8-bit yuv422p input file ffmpeg did > > > > > > > output the hwaccel initialisation error) > > > > > > > > > > > > > > 2) However Intel Arc A-series should support HEVC > > > > > > > (H.265) 10-bit 4:2:0 and 10-bit 4:2:2 decode and encode > > > > > > > formats according to this page: > > > > > > > https://www.intel.com/content/www/us/en/support/articles > > > > > > > /98345/graphics.html > > > > > > > Also testing the corresponding input file in this format > > > > > > > get the hwaccel initialisation error, see the full ffmpeg > > > > > > > output below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ...snip > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > .snip > > > > > > > -- > > > > > > > > > > > > > > 2) 23M h265_yuv422p10le_SR.mp4 > > > > > > > > > > > > > > ffmpeg -hide_banner -init_hw_device "vulkan=vk:0" - > > > > > > > hwaccel vulkan -hwaccel_output_format vulkan -i > > > > > > > h265_yuv422p10le_SR.mp4 -f null - -benchmark > > > > > > > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > > > > > > > 'h265_yuv422p10le_SR.mp4': > > > > > > > Metadata: > > > > > > > major_brand : isom > > > > > > > minor_version : 512 > > > > > > > compatible_brands: isomiso2mp41 > > > > > > > encoder : Lavf61.1.100 > > > > > > > Duration: 00:01:11.16, sta
Re: [FFmpeg-user] Failed setup for format vulkan: hwaccel initialisation returned error for Arc A750
On Wed, Aug 21, 2024 at 2:41 PM Terje J. Hanssen wrote: > > > > Den 15.08.2024 20:29, skrev Terje J. Hanssen: > > > > > > tor. 15. aug. 2024, 13:27 skrev Wang, Fei W : > > > > On Wed, 2024-08-14 at 22:43 +0300, Dennis Mungai wrote: > > > On Wed, 14 Aug 2024 at 15:27, Terje J. Hanssen > > > wrote: > > > > > > > > > > > > Den 14.08.2024 14:22, skrev Dennis Mungai: > > > > > > > > > On Wed, Aug 14, 2024, 15:15 Terje J. Hanssen > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Den 14.08.2024 02:05, skrev Dennis Mungai: > > > > > > > > > > > > > On Wed, 14 Aug 2024, 02:59 Dennis Mungai, > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Wed, 14 Aug 2024, 02:45 Terje J. Hanssen, > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Den 13.08.2024 19:40, skrev Dennis Mungai: > > > > > > > > > > > > > > > > > > > On Tue, 13 Aug 2024 at 19:49, Andrew Randrianasulu > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 13 авг. 2024 г., 19:46 Terje J. Hanssen > > > > > > > > > > > : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > I try to test Vulkan h264 or h265 decoding > > > > > > > > > > > > according to test command at > > > > > > > > > > > > https://trac.ffmpeg.org/wiki/HWAccelIntro#Vulkan > > > > > > > > > > > > ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel > > > > > > > > > > > > vulkan > > > > > > > > > > > > -hwaccel_output_format vulkan -i INPUT -f null - - > > > > > > > > > > > > benchmark > > > > > > > > > > > > > > > > > > > > > > > > but get the following output error: > > > > > > > > > > > > [h264 @ 0x55952760cf40] Failed setup for format > > > > > > > > > > > > vulkan: hwaccel > > > > > > > > > > > > initialisation returned error. > > > > > > > > > > > > or > > > > > > > > > > > > [hevc @ 0x5580e96e8c80] Failed setup for format > > > > > > > > > > > > vulkan: hwaccel > > > > > > > > > > > > initialisation returned error. > > > > > > > > > > > > > > > > > > > > > > > > Any suggestion how to solve it? > > > > > > > > > > > > > > > > > > > > > > > Honestly, no idea .. try ffmpeg matrix/irc > > channel or > > > > > > > > > > > ffmpeg-user? > > > > > > > > > > > > > > > > > > > > > This has to do with your input file. Your log > > indicates > > > > > > > > > > that you're > > > > > > > > > > attempting to decode 10-bit H.264, and from my > > > > > > > > > > suspicion, almost zero GPUs > > > > > > > > > > implement 10-bit H.264 decode. > > > > > > > > > > You can verify via vainfo's output to see the decoder > > > > > > > > > > limitation(s) for > > > > > > > > > > H.264 levels, etc. > > > > > > > > > > Try decoding any of the sample file from Kodi's H.264 > > > > > > > > > > sample collection: > > > > > > > > > > > > https://kodi.wiki/view/Samples#Codecs,_Framerates,_Blac > > > > > > > > > > k-levels_and_Subtitles > > > > > > > > > > And report back. > > > > > > > > > > ___ > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) Thank you for your suspicion regarding almost zero > > > > > > > > > GPUs implement 10-bit H.264 decode. > > > > > > > > > This is obviously true in my case, because when I > > tested > > > > > > > > > a h264 8-bit yuv420p file, the hwaccel > > > > > > > > > initialisation error was away. Full ffmpeg output > > report > > > > > > > > > below using my own encoded input file. > > > > > > > > > (Even with a h264 8-bit yuv422p input file ffmpeg did > > > > > > > > > output the hwaccel initialisation error) > > > > > > > > > > > > > > > > > > 2) However Intel Arc A-series should support HEVC > > > > > > > > > (H.265) 10-bit 4:2:0 and 10-bit 4:2:2 decode and encode > > > > > > > > > formats according to this page: > > > > > > > > > https://www.intel.com/content/www/us/en/support/articles > > > > > > > > > /98345/graphics.html > > > > > > > > > Also testing the corresponding input file in this > > format > > > > > > > > > get the hwaccel initialisation error, see the full > > ffmpeg > > > > > > > > > output below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ...snip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > .snip > > > > > > > > > -- > > > > > > > > > > > > > > > > > > 2) 23M h265_yuv422p10le_SR.mp4 > > > > > > > > > > > > > > > > > > ffmpeg -hide_banner -init_hw_
Re: [FFmpeg-user] Failed setup for format vulkan: hwaccel initialisation returned error for Arc A750
Den 21.08.2024 22:31, skrev Greg Oliver: On Wed, Aug 21, 2024 at 2:41 PM Terje J. Hanssen wrote: Den 15.08.2024 20:29, skrev Terje J. Hanssen: tor. 15. aug. 2024, 13:27 skrev Wang, Fei W: On Wed, 2024-08-14 at 22:43 +0300, Dennis Mungai wrote: > On Wed, 14 Aug 2024 at 15:27, Terje J. Hanssen > wrote: > > > > > > Den 14.08.2024 14:22, skrev Dennis Mungai: > > > > > On Wed, Aug 14, 2024, 15:15 Terje J. Hanssen > > > wrote: > > > > > > > > > > > > > > > Den 14.08.2024 02:05, skrev Dennis Mungai: > > > > > > > > > On Wed, 14 Aug 2024, 02:59 Dennis Mungai, > > > > > wrote: > > > > > > > > > > > On Wed, 14 Aug 2024, 02:45 Terje J. Hanssen, > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Den 13.08.2024 19:40, skrev Dennis Mungai: > > > > > > > > > > > > > > > On Tue, 13 Aug 2024 at 19:49, Andrew Randrianasulu > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > вт, 13 авг. 2024 г., 19:46 Terje J. Hanssen > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I try to test Vulkan h264 or h265 decoding > > > > > > > > > > according to test command at > > > > > > > > > >https://trac.ffmpeg.org/wiki/HWAccelIntro#Vulkan > > > > > > > > > > ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel > > > > > > > > > > vulkan > > > > > > > > > > -hwaccel_output_format vulkan -i INPUT -f null - - > > > > > > > > > > benchmark > > > > > > > > > > > > > > > > > > > > but get the following output error: > > > > > > > > > > [h264 @ 0x55952760cf40] Failed setup for format > > > > > > > > > > vulkan: hwaccel > > > > > > > > > > initialisation returned error. > > > > > > > > > > or > > > > > > > > > > [hevc @ 0x5580e96e8c80] Failed setup for format > > > > > > > > > > vulkan: hwaccel > > > > > > > > > > initialisation returned error. > > > > > > > > > > > > > > > > > > > > Any suggestion how to solve it? > > > > > > > > > > > > > > > > > > > Honestly, no idea .. try ffmpeg matrix/irc channel or > > > > > > > > > ffmpeg-user? > > > > > > > > > > > > > > > > > This has to do with your input file. Your log indicates > > > > > > > > that you're > > > > > > > > attempting to decode 10-bit H.264, and from my > > > > > > > > suspicion, almost zero GPUs > > > > > > > > implement 10-bit H.264 decode. > > > > > > > > You can verify via vainfo's output to see the decoder > > > > > > > > limitation(s) for > > > > > > > > H.264 levels, etc. > > > > > > > > Try decoding any of the sample file from Kodi's H.264 > > > > > > > > sample collection: > > > > > > > > https://kodi.wiki/view/Samples#Codecs,_Framerates,_Blac > > > > > > > > k-levels_and_Subtitles > > > > > > > > And report back. > > > > > > > > ___ > > > > > > > > > > > > > > > > > > > > > > 1) Thank you for your suspicion regarding almost zero > > > > > > > GPUs implement 10-bit H.264 decode. > > > > > > > This is obviously true in my case, because when I tested > > > > > > > a h264 8-bit yuv420p file, the hwaccel > > > > > > > initialisation error was away. Full ffmpeg output report > > > > > > > below using my own encoded input file. > > > > > > > (Even with a h264 8-bit yuv422p input file ffmpeg did > > > > > > > output the hwaccel initialisation error) > > > > > > > > > > > > > > 2) However Intel Arc A-series should support HEVC > > > > > > > (H.265) 10-bit 4:2:0 and 10-bit 4:2:2 decode and encode > > > > > > > formats according to this page: > > > > > > >https://www.intel.com/content/www/us/en/support/articles > > > > > > > /98345/graphics.html > > > > > > > Also testing the corresponding input file in this format > > > > > > > get the hwaccel initialisation error, see the full ffmpeg > > > > > > > output below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ...snip > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > .snip > > > > > > > -- > > > > > > > > > > > > > > 2) 23M h265_yuv422p10le_SR.mp4 > > > > > > > > > > > > > > ffmpeg -hide_banner -init_hw_device "vulkan=vk:0" - > > > > > > > hwaccel vulkan -hwaccel_output_format vulkan -i > > > > > > > h265_yuv422p10le_SR.mp4 -f null - -benchmark > > > > > > > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from > > > > > > > 'h265_yuv422p10le_SR.mp4': > > > > > > >Metadata: > > > > > > > major_
