On Sat, 10 Dec 2016 22:36:50 +0100
Michael Niedermayer wrote:
> Personally if i would be doing this i would use avoptions as
> that means less code to backport that is less work
Less changes doesn't make it right. Anyway, you don't need to listen to
me. I'm just arguing
On Fri, Dec 09, 2016 at 08:47:00PM +0100, Paul B Mahol wrote:
> On 12/9/16, Michael Niedermayer wrote:
> > Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> > pix_fmt is unused and is added to avoid a 2nd API change later
> >
> > The old function uses
On Sat, Dec 10, 2016 at 01:33:59PM +0100, Andreas Cadhalpun wrote:
> On 09.12.2016 20:31, Michael Niedermayer wrote:
> > Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> > pix_fmt is unused and is added to avoid a 2nd API change later
> >
> > The old function uses AVOptions
On Sat, Dec 10, 2016 at 12:20:01PM +0100, wm4 wrote:
> On Fri, 9 Dec 2016 20:31:40 +0100
> Michael Niedermayer wrote:
>
> > Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> > pix_fmt is unused and is added to avoid a 2nd API change later
> >
> > The
On 09.12.2016 20:31, Michael Niedermayer wrote:
> Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> pix_fmt is unused and is added to avoid a 2nd API change later
>
> The old function uses AVOptions to obtain the max_pixels value to simplify
> the transition.
>
> TODO: split
2016-12-10 12:13 GMT+01:00 wm4 :
> On Sat, 10 Dec 2016 11:51:04 +0100
> Carl Eugen Hoyos wrote:
>
>> 2016-12-09 19:45 GMT+01:00 wm4 :
>>
>> > But users switching from FFmpeg to other software because
>> > it fails at the limit does
wm4 wrote:
>Surely not really a worry for ffmpeg, since it's concerned
>about video, and 16K video is still "a bit" in the future.
If by "video" you mean "YUV", then may I disagree with you?
We use daily FFmpeg, and mainly in a "film" ("RGB") context
and often with a 5K or 6.6K horizontal
On Fri, 9 Dec 2016 20:31:40 +0100
Michael Niedermayer wrote:
> Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> pix_fmt is unused and is added to avoid a 2nd API change later
>
> The old function uses AVOptions to obtain the max_pixels value to
On Sat, 10 Dec 2016 11:51:04 +0100
Carl Eugen Hoyos wrote:
> 2016-12-09 19:45 GMT+01:00 wm4 :
>
> > But users switching from FFmpeg to other software because
> > it fails at the limit does happen.
>
> Could you elaborate?
> Was there a bug report
2016-12-09 19:45 GMT+01:00 wm4 :
> But users switching from FFmpeg to other software because
> it fails at the limit does happen.
Could you elaborate?
Was there a bug report that we ignored?
Carl Eugen
___
ffmpeg-devel mailing
On Fri, Dec 09, 2016 at 12:45:22AM +0100, Andreas Cadhalpun wrote:
> On 08.12.2016 19:30, Michael Niedermayer wrote:
> > TODO: split into 2 patches (one per lib), docs & bump
> >
> > This allows preventing some OOM and "slow decoding" cases by limiting the
> > maximum resolution
> > this may be
On 12/9/16, Michael Niedermayer wrote:
> Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
> pix_fmt is unused and is added to avoid a 2nd API change later
>
> The old function uses AVOptions to obtain the max_pixels value to simplify
> the transition.
>
On Fri, 9 Dec 2016, Michael Niedermayer wrote:
Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
pix_fmt is unused and is added to avoid a 2nd API change later
The old function uses AVOptions to obtain the max_pixels value to simplify
the transition.
TODO: split into 2
Adds av_image_check_size2() with max_pixels and pix_fmt parameters.
pix_fmt is unused and is added to avoid a 2nd API change later
The old function uses AVOptions to obtain the max_pixels value to simplify
the transition.
TODO: split into 2 patches (one per lib), docs & bump
This allows
On Fri, 9 Dec 2016 14:11:30 +0100
Michael Niedermayer wrote:
> On Fri, Dec 09, 2016 at 10:14:14AM +0100, wm4 wrote:
> > On Thu, 8 Dec 2016 19:30:25 +0100
> > Michael Niedermayer wrote:
> >
> > > TODO: split into 2 patches (one per lib), docs &
On Fri, Dec 09, 2016 at 10:14:14AM +0100, wm4 wrote:
> On Thu, 8 Dec 2016 19:30:25 +0100
> Michael Niedermayer wrote:
>
> > TODO: split into 2 patches (one per lib), docs & bump
> >
> > This allows preventing some OOM and "slow decoding" cases by limiting the
> >
On Thu, 8 Dec 2016 19:30:25 +0100
Michael Niedermayer wrote:
> TODO: split into 2 patches (one per lib), docs & bump
>
> This allows preventing some OOM and "slow decoding" cases by limiting the
> maximum resolution
> this may be useful to avoid fuzzers getting stuck
On Fri, Dec 9, 2016 at 12:45 AM, Andreas Cadhalpun
wrote:
> On 08.12.2016 19:30, Michael Niedermayer wrote:
>> TODO: split into 2 patches (one per lib), docs & bump
>>
>> This allows preventing some OOM and "slow decoding" cases by limiting the
>> maximum
On 08.12.2016 19:30, Michael Niedermayer wrote:
> TODO: split into 2 patches (one per lib), docs & bump
>
> This allows preventing some OOM and "slow decoding" cases by limiting the
> maximum resolution
> this may be useful to avoid fuzzers getting stuck in boring cases
>
> Signed-off-by:
TODO: split into 2 patches (one per lib), docs & bump
This allows preventing some OOM and "slow decoding" cases by limiting the
maximum resolution
this may be useful to avoid fuzzers getting stuck in boring cases
Signed-off-by: Michael Niedermayer
---
20 matches
Mail list logo