On 24-05-2019 08:53 PM, Gyan wrote:
On 24-05-2019 11:24 AM, Gyan wrote:
Will push tonight.
Pushed as 50789e356d65270698d0d8495323ebe76a46091a
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpe
On 24-05-2019 11:24 AM, Gyan wrote:
On 24-05-2019 02:06 AM, Hendrik Leppkes wrote:
On Thu, May 23, 2019 at 9:55 PM Gyan wrote:
On 24-05-2019 12:58 AM, Nicolas George wrote:
Gyan (12019-05-24):
avpriv_io_delete will call the file protocol's delete which is
guarded
with a header check,
On 24-05-2019 02:06 AM, Hendrik Leppkes wrote:
On Thu, May 23, 2019 at 9:55 PM Gyan wrote:
On 24-05-2019 12:58 AM, Nicolas George wrote:
Gyan (12019-05-24):
avpriv_io_delete will call the file protocol's delete which is guarded
with a header check, not done here.
Do you have report of a
On Thu, May 23, 2019 at 9:55 PM Gyan wrote:
>
>
>
> On 24-05-2019 12:58 AM, Nicolas George wrote:
> > Gyan (12019-05-24):
> >> avpriv_io_delete will call the file protocol's delete which is guarded
> >> with a header check, not done here.
> > Do you have report of a build failure caused by unlink(
On 24-05-2019 12:58 AM, Nicolas George wrote:
Gyan (12019-05-24):
avpriv_io_delete will call the file protocol's delete which is guarded
with a header check, not done here.
Do you have report of a build failure caused by unlink()?
No. I assume that the guard in the file proto callback is g
Gyan (12019-05-24):
> avpriv_io_delete will call the file protocol's delete which is guarded
> with a header check, not done here.
Do you have report of a build failure caused by unlink()?
> Since we now have a generic wrapper function, isn't that better for
> future maintenance?
Not that I see.
On 23-05-2019 11:20 PM, Nicolas George wrote:
Gyan (12019-05-23):
-unlink(buffername);
-av_freep(&buffername);
+ret = avpriv_io_delete(buffername);
Is there a reason you replace unlink() with avpriv_io_delete()? unlink()
is more direct, and cache does not support non-file cache.
Gyan (12019-05-23):
> -unlink(buffername);
> -av_freep(&buffername);
> +ret = avpriv_io_delete(buffername);
Is there a reason you replace unlink() with avpriv_io_delete()? unlink()
is more direct, and cache does not support non-file cache.
Regards,
--
Nicolas George
signature.as
On 23-05-2019 09:13 PM, Michael Niedermayer wrote:
On Wed, May 22, 2019 at 09:06:11PM +0530, Gyan wrote:
On 22-05-2019 06:37 PM, Nicolas George wrote:
Gyan (12019-05-22):
The existing practice of unlinking path immediately after acquiring file
handle was returning (unchecked) EPERM error on
On Wed, May 22, 2019 at 09:06:11PM +0530, Gyan wrote:
>
>
> On 22-05-2019 06:37 PM, Nicolas George wrote:
> >Gyan (12019-05-22):
> >>The existing practice of unlinking path immediately after acquiring file
> >>handle was returning (unchecked) EPERM error on Windows. Switched to
> >>deletion after
On 22-05-2019 06:37 PM, Nicolas George wrote:
Gyan (12019-05-22):
The existing practice of unlinking path immediately after acquiring file
handle was returning (unchecked) EPERM error on Windows. Switched to
deletion after closing handle.
Confirmed that cache protocol temp files are deleted in
Gyan (12019-05-22):
>
> The existing practice of unlinking path immediately after acquiring file
> handle was returning (unchecked) EPERM error on Windows. Switched to
> deletion after closing handle.
> Confirmed that cache protocol temp files are deleted in Windows 7 when
> ffmpeg exits.
>
> The
The existing practice of unlinking path immediately after acquiring file
handle was returning (unchecked) EPERM error on Windows. Switched to
deletion after closing handle.
Confirmed that cache protocol temp files are deleted in Windows 7 when
ffmpeg exits.
The cache protocol calls avutil/av
13 matches
Mail list logo
