> What do you think about using awk instead of shell?
No objection here, especially if it's more robust in some ways than this
or other shell code (though personally I'm not fluent in awk).
My only concern was preventing a considerable performance impact which could
otherwise be avoided
On Tue, Apr 16, 2019 at 2:04 PM Jun Zhao wrote:
>
> From: Jun Zhao
>
> After the commit 9f61abc8111, we can use AVFormatContext.strict_std_compliance
> instead of HLSContext.strict_std_compliance to avoid the code redundancy.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/hls.c |4 +---
>
On Sat, Apr 27, 2019 at 8:22 PM Gyan wrote:
>
>
>
> On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote:
> > 2019-04-27 13:17 GMT+02:00, Jun Zhao :
> >> perfer avctx->framerate first than use avctx->time_base when
> >> setting the frame rate to encoder. 1/time_base is not the
> >> average frame rate
Hi both of you,
nice work iterating on this patch set!
I want to discuss a little more, please don't take my comments
the wrong way, I just couldn't get back to this discussion earlier.
On 2019-04-24 13:36 +, Guo, Yejun wrote:
> >
> > From: avih [mailto:avih...@yahoo.com]
> > Sent:
> From: avih [mailto:avih...@yahoo.com]
> Sent: Wednesday, April 24, 2019 9:23 PM
> To: FFmpeg development discussions and patches
> Cc: Guo, Yejun
> Subject: Re: [FFmpeg-devel] [PATCH V5 2/2] configure: replace 'pr' with printf
> since busybox does not support pr
>
> > log_file(){
> > -
On 2019-04-25 18:49 +0200, Paul B Mahol wrote:
> On 4/23/19, Alexander Strasser wrote:
[...]
> >
> > On 2019-04-22 11:51 +0200, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> doc/filters.texi| 6 +++
> >> libavfilter/af_astats.c | 86
On Sat, Apr 27, 2019 at 03:25:42PM +0200, Paul B Mahol wrote:
> On 4/24/19, Michael Niedermayer wrote:
> > Fixes: Timeout (11sec -> 60ms)
> > Fixes:
> > 14270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAM_fuzzer-5734809634078720
> >
> > Found-by: continuous fuzzing process
> >
On Sat, Apr 27, 2019 at 03:26:35PM +0200, Paul B Mahol wrote:
> On 4/27/19, Michael Niedermayer wrote:
> > On Sat, Apr 27, 2019 at 02:58:38PM +0200, Michael Niedermayer wrote:
> >> Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm
> >> Found-by: Michael Koch
> >> Signed-off-by: Michael
On 4/26/2019 12:31 PM, James Almer wrote:
> Fixes ticket #7866.
>
> Signed-off-by: James Almer
> ---
> libavcodec/scpr3.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/scpr3.c b/libavcodec/scpr3.c
> index f92ccfa902..5cfad9f4d2 100644
> --- a/libavcodec/scpr3.c
> +++
On 4/27/19, Michael Niedermayer wrote:
> On Sat, Apr 27, 2019 at 02:58:38PM +0200, Michael Niedermayer wrote:
>> Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm
>> Found-by: Michael Koch
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavcodec/pnm_parser.c | 15 ++-
>>
On 4/24/19, Michael Niedermayer wrote:
> Fixes: Timeout (11sec -> 60ms)
> Fixes:
> 14270/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PAM_fuzzer-5734809634078720
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael
On Sat, Apr 27, 2019 at 02:58:38PM +0200, Michael Niedermayer wrote:
> Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm
> Found-by: Michael Koch
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pnm_parser.c | 15 ++-
> 1 file changed, 14 insertions(+), 1
On 4/27/19, Michael Niedermayer wrote:
> Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm
> Found-by: Michael Koch
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pnm_parser.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
This code does not apply
Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm
Found-by: Michael Koch
Signed-off-by: Michael Niedermayer
---
libavcodec/pnm_parser.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
index
On Fri, Apr 26, 2019 at 11:58:21PM +0200, Paul B Mahol wrote:
> Improves decoding of: https://jmvalin.ca/misc_stuff/chain_works.opus
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/oggdec.c | 10 +-
> libavformat/oggdec.h | 1 +
> libavformat/oggparseopus.c | 1 +
> 3
On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote:
2019-04-27 13:17 GMT+02:00, Jun Zhao :
perfer avctx->framerate first than use avctx->time_base when
setting the frame rate to encoder. 1/time_base is not the
average frame rate if the frame rate is not constant.
But why would the average
2019-04-27 13:17 GMT+02:00, Jun Zhao :
> perfer avctx->framerate first than use avctx->time_base when
> setting the frame rate to encoder. 1/time_base is not the
> average frame rate if the frame rate is not constant.
But why would the average framerate be a good choice to set
the encoder
On 4/27/19, Clément Bœsch wrote:
> On Sat, Apr 27, 2019 at 12:29:44PM +0200, Paul B Mahol wrote:
>> On 4/27/19, Clément Bœsch wrote:
>> > On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
>> >> On 4/25/19, Reto Kromer wrote:
>> >> > Paul B Mahol wrote:
>> >> >
>> >> >>Found 65x65x65
On Sat, Apr 27, 2019 at 12:29:44PM +0200, Paul B Mahol wrote:
> On 4/27/19, Clément Bœsch wrote:
> > On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
> >> On 4/25/19, Reto Kromer wrote:
> >> > Paul B Mahol wrote:
> >> >
> >> >>Found 65x65x65 3D LUT in wild
> >> >
> >> > FYI:
perfer avctx->framerate first than use avctx->time_base when setting
the frame rate to encoder. 1/time_base is not the average frame rate
if the frame rate is not constant. So perfer avctx->framerate than
1/avctx->time_base if the avctx->framerate is not zero.
Jun Zhao (2):
lavc/libx264: Use
From: Jun Zhao
perfer avctx->framerate first than use avctx->time_base when setting
the frame rate to encoder. 1/time_base is not the average frame rate
if the frame rate is not constant. In this case, we need to setting
avctx->framerate and avctx->time_base both, but avctx->framerate not
equal
From: Jun Zhao
perfer avctx->framerate first than use avctx->time_base when setting
the frame rate to encoder. 1/time_base is not the average frame rate
if the frame rate is not constant, so use avctx->framerate if the
value is not zero.
Signed-off-by: Jun Zhao
---
libavcodec/libx265.c |9
2019-04-25 0:45 GMT+02:00, Carl Eugen Hoyos :
> Attached patch allows to run fate from wsl for out-of-tree builds.
I will push this patch if there are no objections.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
2019-04-06 14:39 GMT+02:00, Michael Niedermayer :
> Fixes: Timeout (8sec -> 0.1sec)
As reported by Michael Koch, this caused a slowdown (~400x) for
the "Samsung" sample in https://trac.ffmpeg.org/wiki/RemapFilter
Carl Eugen
___
ffmpeg-devel mailing
On 4/27/19, Clément Bœsch wrote:
> On Thu, Apr 25, 2019 at 11:22:47PM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/microdvddec.c | 2 ++
>> libavformat/subtitles.c | 2 +-
>> libavformat/subtitles.h | 2 +-
>> 3 files changed, 4 insertions(+), 2
On 4/27/19, Clément Bœsch wrote:
> On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
>> On 4/25/19, Reto Kromer wrote:
>> > Paul B Mahol wrote:
>> >
>> >>Found 65x65x65 3D LUT in wild
>> >
>> > FYI: 128x128x128 3D LUTs do also exist in film production.
>> >
>>
>> Thank you, changed
On 4/20/19, Swaraj Hota wrote:
> Fixes ticket #2956.
>
> Signed-off-by: Swaraj Hota
> ---
> I have tested it on all the samples provided in the ticket and
> it works for all of them.
>
> Please comment.
> ---
> Changelog| 1 +
> libavformat/Makefile | 1 +
>
On Thu, Apr 25, 2019 at 11:22:47PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/microdvddec.c | 2 ++
> libavformat/subtitles.c | 2 +-
> libavformat/subtitles.h | 2 +-
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git
On Thu, Apr 25, 2019 at 02:57:26PM +0200, Paul B Mahol wrote:
> The ranges are for input, not for output.
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_lut3d.c | 73 +-
> 1 file changed, 51 insertions(+), 22 deletions(-)
>
LGTM, thanks
--
On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
> On 4/25/19, Reto Kromer wrote:
> > Paul B Mahol wrote:
> >
> >>Found 65x65x65 3D LUT in wild
> >
> > FYI: 128x128x128 3D LUTs do also exist in film production.
> >
>
> Thank you, changed locally.
This means one single malloc of 24M
30 matches
Mail list logo
