On Wed, May 22, 2019 at 12:14 PM Gyan <ffm...@gyani.pro> wrote: > > > > On 22-05-2019 03:29 PM, Hendrik Leppkes wrote: > > On Wed, May 22, 2019 at 11:51 AM Gyan <ffm...@gyani.pro> wrote: > >> > >> > >> On 22-05-2019 02:29 PM, Hendrik Leppkes wrote: > >>> On Wed, May 22, 2019 at 10:53 AM Gyan <ffm...@gyani.pro> wrote: > >>>> > >>>> On 22-05-2019 01:41 PM, Liu Steven wrote: > >>>>>> 在 2019年5月22日，下午3:10，Gyan <ffm...@gyani.pro> 写道： > >>>>>> > >>>>>> > >>>>>> Helps users to identify temp files for a given instance. > >>>>>> > >>>>>> In the longer term, we should aim to clean up all temp files. > >>>>>> > >>>>>> Gyan > >>>>>> <0001-avutil-file_open-log-temp-filename.patch>_______________________________________________ > >>>>> Why don’t use AV_LOG_DEBUG or AV_LOG_TRACE? > >>>>> > >>>> DEBUG and TRACE are meant to record micro-ops for debugging purposes. > >>>> This message will be present a handful of times in the log and is > >>>> essential for end-users so they can delete these files, which ffmpeg > >>>> won't do, but should since these are meant to be temporary files. > >>>> > >>> Why don't we work on fixing this instead, as users will not know what > >>> implications this message has in any case and just consider it spam. > >> 1) A grep of the tree shows only two components make use of this > >> function. The cache protocol, which needs to be expressly invoked by the > >> user, and the xvid encoder in 2-pass mode, which also has to be > >> expressly invoked. No unsuspecting user will be presented with this > >> message. > >> > >> 2) Fixing this is the ideal solution. The above two components already > >> unlink the file after use, but with cache:, the file remains available > >> after ffmpeg has exited. So this has to be looked at by someone > >> acquainted and able to test with all the environments that ffmpeg can be > >> run on. I don't have that knowledge or access. Till then, let's not the > >> perfect be the enemy of the good. > >> > > This message has absolutely zero indication that the user might need > > to act on it, nevermind that API users might never see it in the first > > place, as such I don't see how this is even "good". > > > > Why don't you start with collecting information which systems are even > > affected by this? You must have some systems where you saw this. > This patch was prompted by a Windows user who wanted this info. As > mentioned above, I can reproduce it with cache protocol on Windows. > Don't have access to other systems, except one linux box. > > I just saw that we do have a file delete function. Will first see if > that works. >
I know that it doesn't work on Windows, because you have to specifically request that a file can be marked for deletion while its still open, which we do not do. I'm working on a patch to see if we can fix this. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
