Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-10-20 Thread Reto Kromer
Martin Vignali wrote: >if avtc->profile < 0 or > 4, return an error. Should 5 not become ProRes XQ (ap4x) as in prores_ks? Best regards, Reto ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg.c: allow forcing input framerate on streamcopy

2018-10-20 Thread Leo Izen
On 10/20/18 6:47 PM, Michael Niedermayer wrote: On Fri, Oct 19, 2018 at 07:29:28PM -0400, Leo Izen wrote: On 10/19/18 3:02 PM, Carl Eugen Hoyos wrote: 2018-10-19 20:39 GMT+02:00, Leo Izen : On 10/19/18 2:26 PM, Carl Eugen Hoyos wrote: 2018-10-19 4:58 GMT+02:00, Leo Izen : ---

[FFmpeg-devel] [PATCH] avformat/dashenc: Support HTTP persistent for init segments as well

2018-10-20 Thread Karthick J
--- libavformat/dashenc.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c index b0a59af3ee..4e2ea2ebf2 100644 --- a/libavformat/dashenc.c +++ b/libavformat/dashenc.c @@ -355,8 +355,11 @@ static int

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg.c: allow forcing input framerate on streamcopy

2018-10-20 Thread Michael Niedermayer
On Fri, Oct 19, 2018 at 07:29:28PM -0400, Leo Izen wrote: > > On 10/19/18 3:02 PM, Carl Eugen Hoyos wrote: > >2018-10-19 20:39 GMT+02:00, Leo Izen : > >>On 10/19/18 2:26 PM, Carl Eugen Hoyos wrote: > >>>2018-10-19 4:58 GMT+02:00, Leo Izen : > --- > fftools/ffmpeg.c | 8 +--- >

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg4videodec: Fix typo in sprite delta check

2018-10-20 Thread Michael Niedermayer
On Thu, Oct 18, 2018 at 01:54:02AM +0200, Michael Niedermayer wrote: > Fixes: Integer overflow > Fixes: > 10890/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5636062181851136 > > Found-by: continuous fuzzing process >

[FFmpeg-devel] [PATCH 1/2] avcodec/jpeg2000dec: Fix off by 1 error in JPEG2000_PGOD_CPRL handling

2018-10-20 Thread Michael Niedermayer
Fixes: assertion failure Fixes: 10785/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5672160496975872 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/jpeg2000dec.c | 2 +-

[FFmpeg-devel] [PATCH 2/2] avcodec/ilbcdec: Check startindex

2018-10-20 Thread Michael Niedermayer
Fixes: Out of array read Fixes: 10789/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5153255445757952 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/ilbcdec.c | 2 +- 1 file

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Carl Eugen Hoyos
2018-10-20 23:43 GMT+02:00, Timo Rothenpieler : > On 20.10.2018 23:31, Carl Eugen Hoyos wrote: >> 2018-10-20 23:16 GMT+02:00, Timo Rothenpieler : >>> On 20.10.2018 23:00, Carl Eugen Hoyos wrote: 2018-10-20 22:46 GMT+02:00, Philip Langdale : > The big discussion was about the new

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 23:52, Philip Langdale wrote: On Sat, 20 Oct 2018 22:58:34 +0200 Timo Rothenpieler wrote: +// It it semantically incorrect to use AX_PIX_FMT_YUV444P16 for either the 10 +// or 12 bit case, but ffmpeg and nvidia disagree on which end the padding +// bits go at.

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
On Sat, 20 Oct 2018 23:10:57 +0200 Timo Rothenpieler wrote: > > > > -for (i = 0; i < 2; i++) { > > +pixdesc = av_pix_fmt_desc_get(avctx->sw_pix_fmt); > > + > > +for (i = 0; i < pixdesc->nb_components; i++) { > > +size_t height =

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
On Sat, 20 Oct 2018 22:58:34 +0200 Timo Rothenpieler wrote: > > > > +// It it semantically incorrect to use AX_PIX_FMT_YUV444P16 > > for either the 10 > > +// or 12 bit case, but ffmpeg and nvidia disagree on which end > > the padding > > +// bits go at. P16 is unambiguous and

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 23:31, Carl Eugen Hoyos wrote: 2018-10-20 23:16 GMT+02:00, Timo Rothenpieler : On 20.10.2018 23:00, Carl Eugen Hoyos wrote: 2018-10-20 22:46 GMT+02:00, Philip Langdale : The big discussion was about the new pixel formats. I would like to get to a clear conclusion on this

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 23:34, Marton Balint wrote: On Sat, 20 Oct 2018, Timo Rothenpieler wrote: On 20.10.2018 22:47, Philip Langdale wrote: 12bit is implicitly truncated to 10bit as part of doing this, but we already do that for P016 and YUV444P16. Huh? I thought one of the reasons of adding a

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

2018-10-20 Thread Marton Balint
On Sat, 20 Oct 2018, Timo Rothenpieler wrote: On 20.10.2018 22:47, Philip Langdale wrote: 12bit is implicitly truncated to 10bit as part of doing this, but we already do that for P016 and YUV444P16. Huh? I thought one of the reasons of adding a separate pixel format is to be able to

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Carl Eugen Hoyos
2018-10-20 23:16 GMT+02:00, Timo Rothenpieler : > On 20.10.2018 23:00, Carl Eugen Hoyos wrote: >> 2018-10-20 22:46 GMT+02:00, Philip Langdale : >> >>> The big discussion was about the new pixel formats. I would >>> like to get to a clear conclusion on this otherwise, this patch >>> series goes

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 23:00, Carl Eugen Hoyos wrote: 2018-10-20 22:46 GMT+02:00, Philip Langdale : The big discussion was about the new pixel formats. I would like to get to a clear conclusion on this otherwise, this patch series goes nowhere forever Wouldn't it be an alternative to first commit the

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 22:47, Philip Langdale wrote: 12bit is implicitly truncated to 10bit as part of doing this, but we already do that for P016 and YUV444P16. I've bundled a single version bump and changelog entry in this change to reflect the updates to all three of nvdec/nvenc/cuviddec.

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 22:47, Philip Langdale wrote: This is the equivalent change for cuviddec after the previous change for nvdec. I made similar changes to the copying routines to handle pixel formats in a more generic way. Note that unlike with nvdec, there is no confusion about the ability of a

Re: [FFmpeg-devel] [PATCH 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 22:46, Philip Langdale wrote: With the introduction of HEVC 444 support, we technically have two codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG, it can decode, but can only output one of the semi-planar formats. That means we need additional logic to decide

Re: [FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Carl Eugen Hoyos
2018-10-20 22:46 GMT+02:00, Philip Langdale : > The big discussion was about the new pixel formats. I would > like to get to a clear conclusion on this otherwise, this patch > series goes nowhere forever Wouldn't it be an alternative to first commit the patch with P16 and then discuss what the

Re: [FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Timo Rothenpieler
On 20.10.2018 22:46, Philip Langdale wrote: The latest generation video decoder on the Turing chips supports decoding HEVC 4:4:4. Supporting this is relatively straight-forward; we need to account for the different chroma format and pick the right output and sw formats at the right times. There

[FFmpeg-devel] [PATCH 1/5] avutil: Add YUV444P10_MSB and YUV444P12_MSB pixel formats

2018-10-20 Thread Philip Langdale
Currently, ffmpeg defines a set of YUV444P formats for use where the bits-per-pixel are between 8 and 16 bits. In these formats, the bits are packed in the LSBs of the 16 bits of available storage. On the other hand, all the hardware vendors have defined their equivalent formats with the bits

[FFmpeg-devel] [PATCH 0/5] Add nvidia hw decode support for HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
The new video decoder hardware on Turing GPUs supports HEVC 4:4:4 content. This patch series adds the necessary new pixel formats and implements support in nvdec/nvenc/cuviddec. (Since the previous post of this series, I fixed the reversed terminology on the pixel formats) The big discussion was

[FFmpeg-devel] [PATCH 3/5] avcodec/nvdec: Explicitly mark codecs that support 444 output formats

2018-10-20 Thread Philip Langdale
With the introduction of HEVC 444 support, we technically have two codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG, it can decode, but can only output one of the semi-planar formats. That means we need additional logic to decide whether to use a 444 output format or not.

[FFmpeg-devel] [PATCH 4/5] avcodec/cuviddec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
This is the equivalent change for cuviddec after the previous change for nvdec. I made similar changes to the copying routines to handle pixel formats in a more generic way. Note that unlike with nvdec, there is no confusion about the ability of a codec to output 444 formats. This is because the

[FFmpeg-devel] [PATCH 5/5] avcodec/nvenc: Accept YUV444P10_MSB and YUV444P12_MSB content

2018-10-20 Thread Philip Langdale
12bit is implicitly truncated to 10bit as part of doing this, but we already do that for P016 and YUV444P16. I've bundled a single version bump and changelog entry in this change to reflect the updates to all three of nvdec/nvenc/cuviddec. Signed-off-by: Philip Langdale --- Changelog

[FFmpeg-devel] [PATCH 2/5] avcodec/nvdec: Add support for decoding HEVC 4:4:4 content

2018-10-20 Thread Philip Langdale
The latest generation video decoder on the Turing chips supports decoding HEVC 4:4:4. Supporting this is relatively straight-forward; we need to account for the different chroma format and pick the right output and sw formats at the right times. There was one bug which was the hard-coded

[FFmpeg-devel] swscale/unscaled : add grayf32 bswap and rename packed_16bpc_bswap

2018-10-20 Thread Martin Vignali
Hello, 001 : add unscaled grayf32 bswap func similar to packed_16bpc_bswap processing 002 : rename packed_16bpc_bswap func to bswap_16bpc this func is used for planar and packed bswap16 Martin 0002-swscale-swscale_unscaled-rename-packed_16bpc_bswap.patch Description: Binary data

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

2018-10-20 Thread Martin Vignali
Le sam. 20 oct. 2018 à 18:18, Paul B Mahol a écrit : > On 10/20/18, Martin Vignali wrote: > > Hello, > > > >> > >> > Blocking this patch, no code should remove old filters. > >> > > >> > > I suppose you talk about the proposal of removing setfield, setrange > later ? > > It was not clear from

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Hendrik Leppkes
On Sat, Oct 20, 2018 at 4:50 PM Vittorio Giovara wrote: > > On Sat, Oct 20, 2018 at 12:30 PM Marton Balint wrote: > > > > > > > On Sat, 20 Oct 2018, Hendrik Leppkes wrote: > > > > > On Sat, Oct 20, 2018 at 12:35 PM Marton Balint wrote: > > >> > > >> Libx264 uses strtok which is not thread safe.

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Marton Balint
On Sat, 20 Oct 2018, Vittorio Giovara wrote: On Sat, Oct 20, 2018 at 12:30 PM Marton Balint wrote: On Sat, 20 Oct 2018, Hendrik Leppkes wrote: > On Sat, Oct 20, 2018 at 12:35 PM Marton Balint wrote: >> >> Libx264 uses strtok which is not thread safe. Strtok is used in >>

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

2018-10-20 Thread Paul B Mahol
On 10/20/18, Martin Vignali wrote: > Hello, > >> >> > Blocking this patch, no code should remove old filters. >> > >> > I suppose you talk about the proposal of removing setfield, setrange later ? It was not clear from commit log. So patches are fine for merge. Just missing documentation for new

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

2018-10-20 Thread Thomas Volkert
On 20.10.2018 17:15, Thilo Borgmann wrote: > Hi again, > >> FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech >> Republic during October 6th to 7th! >> >> [...] Find detailed information here: >> >> https://www.linuxdays.cz/2018/en/ > [..] > > Being the only booth staff

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

2018-10-20 Thread Martin Vignali
Hello, > > > Blocking this patch, no code should remove old filters. > > > I suppose you talk about the proposal of removing setfield, setrange later ? > > If you want more parameters to be changed write new filters instead. > > > This is what the current patch do. > > Feel free to merge

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

2018-10-20 Thread Paul B Mahol
On 10/20/18, Martin Vignali wrote: > Hello, > > Missing doc update, and changelog entry. > > 001 : Merge setfield and setrange to a new setparams filter > like both filter have near identical code, and merging it, can let a user > to set all property at the same time. > > in setparams, the field

Re: [FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

2018-10-20 Thread Paul B Mahol
On 10/20/18, Paul B Mahol wrote: > On 10/20/18, Martin Vignali wrote: >> Hello, >> >> Missing doc update, and changelog entry. >> >> 001 : Merge setfield and setrange to a new setparams filter >> like both filter have near identical code, and merging it, can let a user >> to set all property at

[FFmpeg-devel] GSoC 2018 mentor summit review

2018-10-20 Thread Thilo Borgmann
Hi folks, last weekend we attended the annual GSoC mentor summit. This time, it was Pedro Arthur and myself going there. As usual, there have been a huge amount of interesting fellow open-source projects around and we've met a lot of interesting people. There have been a lot of interesting

Re: [FFmpeg-devel] [LDP] FFmpeg at LinuxDays 2018 in Prague

2018-10-20 Thread Thilo Borgmann
Hi again, > FFmpeg been accepted for a booth at the LinuxDays 2018 in Prague, Czech > Republic during October 6th to 7th! > > [...] Find detailed information here: > > https://www.linuxdays.cz/2018/en/ about two weeks ago the Linux Days Prague took place. For limited space and luggage, I

[FFmpeg-devel] avfilter : merge setfield and setrange and add set color property option

2018-10-20 Thread Martin Vignali
Hello, Missing doc update, and changelog entry. 001 : Merge setfield and setrange to a new setparams filter like both filter have near identical code, and merging it, can let a user to set all property at the same time. in setparams, the field mode option have been rename to field_mode Current

Re: [FFmpeg-devel] [PATCH] avfilter: add chromahold filter

2018-10-20 Thread Paul B Mahol
On 10/18/18, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > doc/filters.texi | 20 > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_chromakey.c | 96 +- > 4 files changed, 116

[FFmpeg-devel] [PATCH] avfilter: add vibrance filter

2018-10-20 Thread Paul B Mahol
Signed-off-by: Paul B Mahol --- doc/filters.texi | 29 + libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_vibrance.c | 240 ++ 4 files changed, 271 insertions(+) create mode 100644 libavfilter/vf_vibrance.c

[FFmpeg-devel] avfilter/show_info : print color information

2018-10-20 Thread Martin Vignali
Hello, Patch in attach add to show_info filter print of the color property (range, primaries, trc, space) Martin 0003-avfilter-show_info-add-print-of-color-information.patch Description: Binary data ___ ffmpeg-devel mailing list

[FFmpeg-devel] avcodec : add prores_metadata bsf and fate test

2018-10-20 Thread Martin Vignali
Hello, Patch in attach add a bsf filter to set color property of a prores frame Can be used, to set all frames of prores file to the same value (avoid color shift on some frame depending of the software used to decode the file) or fix the value, for file created with incorrect metadata. Martin

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Marton Balint
On Sat, 20 Oct 2018, Hendrik Leppkes wrote: On Sat, Oct 20, 2018 at 12:35 PM Marton Balint wrote: Libx264 uses strtok which is not thread safe. Strtok is used in x264_param_default_preset in param_apply_tune in x264/common/base.c. Therefore the flag must be removed. Fixes ticket #7446.

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Hendrik Leppkes
On Sat, Oct 20, 2018 at 12:35 PM Marton Balint wrote: > > Libx264 uses strtok which is not thread safe. Strtok is used in > x264_param_default_preset in param_apply_tune in x264/common/base.c. > Therefore the flag must be removed. > > Fixes ticket #7446. > > Signed-off-by: Marton Balint > --- >

Re: [FFmpeg-devel] avcodec/proresenc_aw improvements

2018-10-20 Thread Martin Vignali
> > See coverity bug report, avctx->profile is not checked for valid values i > think. > > Hello, Doesn't find where avctx->profile can have an invalid value seems to be checked in prores_encode_init if FF_PROFILE_UNKNOWN use pix fmt YUV422P10 or YUV444P10 to select the profile (can pix_fmt be

[FFmpeg-devel] [PATCH] 2 alternative ways to check in vp9 decode_tiles() if there is data remaining

2018-10-20 Thread Michael Niedermayer
Hi 2 alternative patchsets are attached to fix $SUBJ The 2 alternatives should behave similar. The first adds a function to check if the next range coder symbol read would trigger the end of input case. We then error out before reading in case the read would trigger this case The second sets a

[FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

2018-10-20 Thread Marton Balint
Libx264 uses strtok which is not thread safe. Strtok is used in x264_param_default_preset in param_apply_tune in x264/common/base.c. Therefore the flag must be removed. Fixes ticket #7446. Signed-off-by: Marton Balint --- libavcodec/libx264.c | 6 ++ 1 file changed, 2 insertions(+), 4