On 07-09-2018 12:21 AM, Gyan Doshi wrote:
On 05-09-2018 06:06 AM, Michael Niedermayer wrote:
On Mon, Sep 03, 2018 at 10:48:45AM +0530, Gyan Doshi wrote:
On 31-08-2018 10:26 AM, Gyan Doshi wrote:
On 31-08-2018 09:57 AM, Gyan Doshi wrote:
On 31-08-2018 04:28 AM, Marton Balint wrote:
Is there
On 05-09-2018 06:06 AM, Michael Niedermayer wrote:
On Mon, Sep 03, 2018 at 10:48:45AM +0530, Gyan Doshi wrote:
On 31-08-2018 10:26 AM, Gyan Doshi wrote:
On 31-08-2018 09:57 AM, Gyan Doshi wrote:
On 31-08-2018 04:28 AM, Marton Balint wrote:
Is there any real use case when same source and des
On Mon, Sep 03, 2018 at 10:48:45AM +0530, Gyan Doshi wrote:
> On 31-08-2018 10:26 AM, Gyan Doshi wrote:
> >On 31-08-2018 09:57 AM, Gyan Doshi wrote:
> >>On 31-08-2018 04:28 AM, Marton Balint wrote:
> >>
> >>>
> >>>Is there any real use case when same source and destination works, so
> >>>the option
On 31-08-2018 10:26 AM, Gyan Doshi wrote:
On 31-08-2018 09:57 AM, Gyan Doshi wrote:
On 31-08-2018 04:28 AM, Marton Balint wrote:
Is there any real use case when same source and destination works, so
the option can be used?
If not, then just make ffmpeg fail, like the cp command fails for
On 31-08-2018 09:57 AM, Gyan Doshi wrote:
On 31-08-2018 04:28 AM, Marton Balint wrote:
Is there any real use case when same source and destination works, so
the option can be used?
If not, then just make ffmpeg fail, like the cp command fails for same
source and destination. I am against a
On 31-08-2018 04:28 AM, Marton Balint wrote:
Is there any real use case when same source and destination works, so
the option can be used?
If not, then just make ffmpeg fail, like the cp command fails for same
source and destination. I am against adding an option if it has no known
use.
On Thu, 30 Aug 2018, Paul B Mahol wrote:
On 8/30/18, Gyan Doshi wrote:
On 29-08-2018 09:48 AM, Gyan Doshi wrote:
On 29-08-2018 02:43 AM, Michael Niedermayer wrote:
On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:
Instead of this, maybe we should add support to write lock
On 8/30/18, Gyan Doshi wrote:
> On 29-08-2018 09:48 AM, Gyan Doshi wrote:
>> On 29-08-2018 02:43 AM, Michael Niedermayer wrote:
>>> On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:
>>
Instead of this, maybe we should add support to write lock the files
when
openin
On 29-08-2018 09:48 AM, Gyan Doshi wrote:
On 29-08-2018 02:43 AM, Michael Niedermayer wrote:
On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:
Instead of this, maybe we should add support to write lock the files
when
opening them for reading. Then ffmpeg can request this. That
On 29-08-2018 02:43 AM, Michael Niedermayer wrote:
On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:
Instead of this, maybe we should add support to write lock the files when
opening them for reading. Then ffmpeg can request this. That would be an
useful option, and not just for
On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:
>
>
> On Tue, 28 Aug 2018, Gyan Doshi wrote:
>
> >
> >With some regularity, we have users trying to update input files using
> >ffmpeg, usually for the purposes of tagging, but occasionally for changing
> >the encoding or something e
On Tue, 28 Aug 2018, Gyan Doshi wrote:
With some regularity, we have users trying to update input files using
ffmpeg, usually for the purposes of tagging, but occasionally for changing
the encoding or something else. Other apps like mp4box or taggers edit the
files in-place i.e. destinatio
With some regularity, we have users trying to update input files using
ffmpeg, usually for the purposes of tagging, but occasionally for
changing the encoding or something else. Other apps like mp4box or
taggers edit the files in-place i.e. destination file is same as the
source. FFmpeg cann
13 matches
Mail list logo
