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 delet
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
>
> 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 a
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
> ---
>
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.
Si
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
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
> >> x264_param_default_preset in param_apply_tune in x264
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@ffmpeg.or
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
di
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 insertions(+
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 b
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 cou
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 ses
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 t
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 m
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 code
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 this
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
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
>> x264_param_defa
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.
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 co
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
0001-swscale
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 assumptio
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 c
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 |
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
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.
Signed-
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 pack
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
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 di
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 wheth
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 code
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.
Signed-off-
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
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 nowh
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 diffe
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 se
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 otherwi
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 matc
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 = avctx->height
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. P
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 pixel
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 ch
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 +-
1
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
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpe
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 +---
>
---
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 flush_init_segment(AVFormat
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 :
---
fftools/ffm
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
49 matches
Mail list logo
