James Almer (12019-01-04):
> We already did size_t for AVSphericalMapping and had to change them to
> uint32_t.
> size_t is not the correct type at all, as video dimensions are not
> system dependent,
I fully agree with that.
> and it will generate the same issues we already
>
On 1/4/2019 11:45 PM, Rostislav Pehlivanov wrote:
> On Fri, 4 Jan 2019 at 23:19, Mohammad Izadi wrote:
>
>> Thanks James.
>> --
>> Best,
>> Mohammad
>>
>>
>> On Fri, Jan 4, 2019 at 3:03 PM James Almer wrote:
>>
>>> On 1/4/2019 7:51 PM, Rostislav Pehlivanov wrote:
On Fri, 4 Jan 2019 at
On Fri, 4 Jan 2019 at 23:19, Mohammad Izadi wrote:
> Thanks James.
> --
> Best,
> Mohammad
>
>
> On Fri, Jan 4, 2019 at 3:03 PM James Almer wrote:
>
> > On 1/4/2019 7:51 PM, Rostislav Pehlivanov wrote:
> > > On Fri, 4 Jan 2019 at 21:08, James Almer wrote:
> > >
> > >> On 1/4/2019 3:53 PM,
On 1/4/2019 10:08 AM, Vittorio Giovara wrote:
> On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
>
>> Rostislav Pehlivanov (12019-01-04):
+typedef struct AVRegionOfInterest {
+size_t self_size;
+size_t top;
+size_t bottom;
+size_t left;
+
Thanks James.
--
Best,
Mohammad
On Fri, Jan 4, 2019 at 3:03 PM James Almer wrote:
> On 1/4/2019 7:51 PM, Rostislav Pehlivanov wrote:
> > On Fri, 4 Jan 2019 at 21:08, James Almer wrote:
> >
> >> On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
> >>> On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi
On Fri, 4 Jan 2019 at 20:44, Vittorio Giovara
wrote:
> On Fri, Jan 4, 2019 at 7:57 PM Rostislav Pehlivanov
> wrote:
>
> > On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara <
> vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
> > >
> > > >
Hi Rostislav,
It seems there is a bit miscommunication here. I dont want to create a full
struct. However, as James mentioned too, Content Light and Dynamic HDR10+
are two different SEI types. There's no
reason to merge them into a single struct within the HEVC decoder. I mean
to create the
On 1/4/2019 7:51 PM, Rostislav Pehlivanov wrote:
> On Fri, 4 Jan 2019 at 21:08, James Almer wrote:
>
>> On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
>>> On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi wrote:
>>>
You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
On 1/4/2019 7:07 PM, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136
>
> Before change: Executed
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136
> in 28285 ms
> After
On Fri, 4 Jan 2019 at 21:08, James Almer wrote:
> On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
> > On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi wrote:
> >
> >> You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
> >> --
> >> Best,
> >> Mohammad
> >>
> >>
> >> On Thu, Jan
Fixes: Timeout
Fixes:
10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136
Before change: Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136
in 28285 ms
After change: Executed
On Fri, 4 Jan 2019, Nicolas George wrote:
Marton Balint (12018-12-30):
This allows the underlying files to change their duration on subsequent
avformat context opens.
An example use case where this matters:
ffconcat version 1.0
file dummy.mxf
file dummy.mxf
ffmpeg -re -stream_loop -1 -i
On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
> On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi wrote:
>
>> You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
>> --
>> Best,
>> Mohammad
>>
>>
>> On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov
>> wrote:
>>
>>> On Thu, 3
On 1/4/2019 2:51 PM, Mohammad Izadi wrote:
> I did that before and James ask me to copy. So now, James are you OK with
> that?
Your first patch allocated a second AVDynamicHDRPlus and memcpy'd
everything to the new one every frame. Rostislav suggestion is to
allocate a single AVDynamicHDRPlus,
On Fri, Jan 4, 2019 at 7:57 PM Rostislav Pehlivanov
wrote:
> On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara
> wrote:
>
> > On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
> >
> > > Vittorio Giovara (12019-01-04):
> > > > I personally disagree, what are coordinates within an AVFrame if not
I like your idea of using AVBufferRef. Thanks for that. However, I prefer
both HEVCSEIContentLight and HEVCSEIDynamicHDRPlus exist, because
ContentLight and Dynamic HDR10+ are two different things. For a frame, we
can have both or none of them or only one of them. It would be more complex
to set
./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
yuv420p16be \
-s 1920x1728 -f null -vframes 100 -v error -nostats -
9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
Fate passes, each format tested with an image to video conversion.
Only POWER8 includes 32-bit
Thanks a lot :-)
On Thu, Jan 3, 2019 at 1:53 PM Michael Niedermayer
wrote:
>
> On Wed, Jan 02, 2019 at 06:29:22PM -0800, Manoj Gupta wrote:
> > On Wed, Jan 2, 2019 at 2:33 PM Michael Niedermayer
> > wrote:
> > >
> > > On Wed, Jan 02, 2019 at 10:12:33AM -0800, Manoj Gupta wrote:
> > > > On Mon,
On 1/4/19, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/gdv.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
OK
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sat, Dec 29, 2018 at 02:35:19AM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tools/target_dec_fate.list | 61 ++
> 1 file changed, 61 insertions(+)
will apply
[...]
--
Michael GnuPG fingerprint:
On Sat, Dec 29, 2018 at 10:47:16AM +0100, Moritz Barsnick wrote:
> On Sat, Dec 29, 2018 at 02:35:18 +0100, Michael Niedermayer wrote:
> > +CACHED=$((CACHED+1))
>
> I believe this is the sort of math that won't work on old, non-POSIX
> Bourne shells. (I'm thinking Solaris /bin/sh here.) In
Signed-off-by: Michael Niedermayer
---
libavcodec/gdv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 538bc38e3e..132ec7288a 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -470,12 +470,10 @@ static int
Fixes: signed integer overflow: 2 * 2132811760 cannot be represented in type
'int'
Fixes:
11156/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6237685933408256
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: Timeout
Fixes:
11067/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5686623711264768
Before change: Executed
clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5686623711264768
in 34386 ms
After change: Executed
On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara
wrote:
> On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
>
> > Vittorio Giovara (12019-01-04):
> > > I personally disagree, what are coordinates within an AVFrame if not
> the
> > > length/size of an object in memory?
> >
> > That would be an
On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi wrote:
> You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
> --
> Best,
> Mohammad
>
>
> On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov
> wrote:
>
> > On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi wrote:
> >
> > >
> > > /**
You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
--
Best,
Mohammad
On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov
wrote:
> On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi wrote:
>
> >
> > /**
> > @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
> >
I did that before and James ask me to copy. So now, James are you OK with
that?
--
Best,
Mohammad
On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov
wrote:
> On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi wrote:
>
> >
> > /**
> > @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
> >
On Fri, Jan 04, 2019 at 04:26:51PM +, Derek Buitenhuis wrote:
> On 04/01/2019 14:15, Nicolas George wrote:
> > Rostislav Pehlivanov (12019-01-04):
> >> Hence an AVRational is appropriate as you can have fractions between 0 and
> >> 1, the encoder can adjust it and it'll be agnostic.
> >
> >
Steinar H. Gunderson (12019-01-04):
> Out of curiosity; if it's important to support as large resolutions
> as you can address in memory, what would you do with a 1bpp format
> on a 32-bit system, where one could easily store more than size_t pixels in
> memory?
It is not that important, and
On Fri, Jan 04, 2019 at 05:28:03PM +0100, Vittorio Giovara wrote:
> size_t really seems the right choice here
Out of curiosity; if it's important to support as large resolutions
as you can address in memory, what would you do with a 1bpp format
on a 32-bit system, where one could easily store
On Fri, Jan 4, 2019 at 2:37 PM Nicolas George wrote:
> Vittorio Giovara (12019-01-04):
> > I personally disagree, what are coordinates within an AVFrame if not the
> > length/size of an object in memory?
>
> That would be an argument for making AVFrame.width and AVFrame.height
> size_t. But they
On 04/01/2019 14:15, Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
>> Hence an AVRational is appropriate as you can have fractions between 0 and
>> 1, the encoder can adjust it and it'll be agnostic.
>
> Yes, AVRational is fine. Producing warnings for an unexpected
> denominator
On Fri, Jan 04, 2019 at 02:17:02AM +0900, nu774 wrote:
> The variable "err" is not initialized, and set only when something went wrong.
> When everything is OK, nobody sets it, so using it result in UB.
> ---
> libavformat/vapoursynth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, Jan 04, 2019 at 05:19:21PM +0800, Steven Liu wrote:
> Michael Niedermayer 于2019年1月4日周五 上午9:48写道：
> >
> > Found-by: jamrial
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/tests/rangecoder.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
Rostislav Pehlivanov (12019-01-04):
> Hence an AVRational is appropriate as you can have fractions between 0 and
> 1, the encoder can adjust it and it'll be agnostic.
Yes, AVRational is fine. Producing warnings for an unexpected
denominator would be a bad idea.
Regards,
--
Nicolas George
On Fri, 4 Jan 2019 at 14:02, Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
> > Which are in pixels, not bytes.
>
> And plain int, not uint32_t.
>
> > This is an encoder-only interface for now. For vp9 the denum would be 255
> > for example. They would warn on out of range qdelta.
>
Rostislav Pehlivanov (12019-01-04):
> Which are in pixels, not bytes.
And plain int, not uint32_t.
> This is an encoder-only interface for now. For vp9 the denum would be 255
> for example. They would warn on out of range qdelta.
> I still don't get why this can't be an int.
"For now" is the
Marton Balint (12018-12-30):
> This allows the underlying files to change their duration on subsequent
> avformat context opens.
>
> An example use case where this matters:
>
> ffconcat version 1.0
> file dummy.mxf
> file dummy.mxf
>
> ffmpeg -re -stream_loop -1 -i dummy.ffconcat -f sdl2 none
>
Vittorio Giovara (12019-01-04):
> I personally disagree, what are coordinates within an AVFrame if not the
> length/size of an object in memory?
That would be an argument for making AVFrame.width and AVFrame.height
size_t. But they are not, and therefore these ROI values have no reason
to be
On Fri, Jan 4, 2019 at 12:22 PM Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
> > > +typedef struct AVRegionOfInterest {
> > > +size_t self_size;
> > > +size_t top;
> > > +size_t bottom;
> > > +size_t left;
> > > +size_t right;
> > I'd still much rather have
On Fri, 4 Jan 2019 at 11:22, Nicolas George wrote:
> Rostislav Pehlivanov (12019-01-04):
> > > +typedef struct AVRegionOfInterest {
> > > +size_t self_size;
> > > +size_t top;
> > > +size_t bottom;
> > > +size_t left;
> > > +size_t right;
> > I'd still much rather have uints
On Fri, Jan 04, 2019 at 00:35:43 +0800, Guo, Yejun wrote:
> @@ -345,6 +350,50 @@ static int X264_frame(AVCodecContext *ctx, AVPacket
> *pkt, const AVFrame *frame,
[...]
> +if (sd) {
> +if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
> +av_log(ctx,
Rostislav Pehlivanov (12019-01-04):
> > +typedef struct AVRegionOfInterest {
> > +size_t self_size;
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
> I'd still much rather have uints with fixed sizes than these platform
> dependent types.
Guo, Yejun
On Thu, 3 Jan 2019 at 08:41, Guo, Yejun wrote:
> The encoders such as libx264 support different QPs offset for different
> MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
>
> Typical usage: After
ping
On Mon, Dec 31, 2018 at 11:02 PM Alex Mogurenko wrote:
> thanks,
> just sent new patch
>
> On Mon, Dec 31, 2018 at 5:56 PM Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
>> On 31/12/2018 09:12, Alex Mogurenko wrote:
>> > I seems to be lame as failed to find how to run fate to
Michael Niedermayer 于2019年1月4日周五 上午9:48写道：
>
> Found-by: jamrial
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/tests/rangecoder.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/tests/rangecoder.c b/libavcodec/tests/rangecoder.c
> index
47 matches
Mail list logo
