On 28-08-2018 01:29 AM, Michael Niedermayer wrote:
LGTM
thanks
PS: these fields seem not documented anywhere, neither the new nor the old or
iam looking at the wrong places
Will add documentation.
This patch pushed as 26dc76324564fc572689509c2efb7f1cb8f41a45
Thanks,
Gyan
_
On Sun, Aug 26, 2018 at 11:53:16AM +0530, Gyan Doshi wrote:
> On 09-08-2018 10:09 AM, Gyan Doshi wrote:
> >
> >
> >On 08-08-2018 12:47 AM, Nicolas George wrote:
> >>Gyan Doshi (2018-08-08):
> >>>That will just defer the breaking change.
> >>
> >>That will leave people time to notice the change and
On 26-08-2018 11:53 AM, Gyan Doshi wrote:
On 09-08-2018 10:09 AM, Gyan Doshi wrote:
On 08-08-2018 12:47 AM, Nicolas George wrote:
Gyan Doshi (2018-08-08):
That will just defer the breaking change.
That will leave people time to notice the change and allow old and new
scripts to work during
On 09-08-2018 10:09 AM, Gyan Doshi wrote:
On 08-08-2018 12:47 AM, Nicolas George wrote:
Gyan Doshi (2018-08-08):
That will just defer the breaking change.
That will leave people time to notice the change and allow old and new
scripts to work during the transition.
Will do it this way.
R
On 08-08-2018 12:47 AM, Nicolas George wrote:
Gyan Doshi (2018-08-08):
That will just defer the breaking change.
That will leave people time to notice the change and allow old and new
scripts to work during the transition.
Will do it this way.
Gyan
Gyan Doshi (2018-08-08):
> That will just defer the breaking change.
That will leave people time to notice the change and allow old and new
scripts to work during the transition.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
On 06-08-2018 08:00 PM, Nicolas George wrote:
Not really. I suppose you could add the field with the correct name and
remove the bogus one later. But your thoughts on this are probably
better than mine.
That will just defer the breaking change. The options, as I see it, are
wontfix, or
pus
Gyan Doshi (2018-08-06):
> >Ah yes, Sorry, this is used for parsing. What protocol do you suggest for
> >correcting this?
>
> Any thoughts on this?
Not really. I suppose you could add the field with the correct name and
remove the bogus one later. But your thoughts on this are probably
better tha
On 05-08-2018 02:28 PM, Gyan Doshi wrote:
Ah yes, Sorry, this is used for parsing. What protocol do you suggest
for correcting this?
Any thoughts on this?
I see that there were two changes made to value fields of the progress
report earlier this year - a194e9c4159 and 1322b00060
Regards,
On 05-08-2018 02:17 PM, Nicolas George wrote:
Gyan Doshi (2018-08-05):
Will push soon, if nothing else.
Have you considered you may be breaking some user's scripts?
Ah yes, Sorry, this is used for parsing. What protocol do you suggest
for correcting this?
Regards,
Gyan
_
Gyan Doshi (2018-08-05):
> Will push soon, if nothing else.
Have you considered you may be breaking some user's scripts?
Carl Eugen's comment was in no way an approval of your patch. Pushing a
patch without a second positive opinion in less than half a day...
Regards,
--
Nicolas George
sig
On 05-08-2018 01:46 PM, Carl Eugen Hoyos wrote:
av_bprintf(&buf_script, "out_time_ms=N/A\n");
If the patch is a good idea you should also change this line.
Fixed locally.
Will push soon, if nothing else.
Thanks,
Gyan
___
ffmpeg-devel mailing
> Am 05.08.2018 um 09:10 schrieb Gyan Doshi :
>
> <0001-ffmpeg-correct-units-for-raw-pts-in-progress-report.patch>
> av_bprintf(&buf_script, "out_time_ms=N/A\n");
If the patch is a good idea you should also change this line.
Thank you, Carl Eugen
_
From a45b0ade691816d8037c846f2b773d0ddab74cbe Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Sun, 5 Aug 2018 12:34:21 +0530
Subject: [PATCH] ffmpeg: correct units for raw pts in -progress report
PTS is in microseconds.
Fixes #7345
---
fftools/ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1
14 matches
Mail list logo