On 22.11.2016 01:35, Carl Eugen Hoyos wrote:
> 2016-11-22 0:06 GMT+01:00 Andreas Cadhalpun
> :
>> I tend to silently accept zero, because I'd like a
>> consistent solution and in some cases rejecting zero
>> causes FATE failures.
>
> If there were a bug, you should of course fix fate, fate
> alon
On 22.11.2016 01:27, Carl Eugen Hoyos wrote:
> 2016-11-22 0:40 GMT+01:00 Andreas Cadhalpun
> :
>
>> For example what should be done about overflows, e.g. when
>> calculating the bit rate? Does this count as demuxer failing?
>
> I don't understand this question:
> There are formats for which we d
2016-11-22 0:06 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 21:02, Carl Eugen Hoyos wrote:
>> 2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun
>> :
>>> Currently many demuxers silently accept wrong (i.e. negative) values
>>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>>> so
2016-11-22 0:40 GMT+01:00 Andreas Cadhalpun :
> For example what should be done about overflows, e.g. when
> calculating the bit rate? Does this count as demuxer failing?
I don't understand this question:
There are formats for which we don't know the specification (or
it may not exist): Of course
On 21.11.2016 03:13, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>>
>>
On 20.11.2016 21:02, Carl Eugen Hoyos wrote:
> 2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun
> :
>> Currently many demuxers silently accept wrong (i.e. negative) values
>> for channels, bit_rate, block_align and so on. I'd like to fix that,
>> so the question is now, how?
>>
>> There are a few poss
On 11/21/2016 4:21 AM, Rostislav Pehlivanov wrote:
> On 17 November 2016 at 00:08, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
>> All the fields can be set via options read from the ffm file and thus
>> have to be sanitized.
>>
>> A negative extradata size for example gets pas
On 17 November 2016 at 00:08, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> All the fields can be set via options read from the ffm file and thus
> have to be sanitized.
>
> A negative extradata size for example gets passed to memcpy in
> avcodec_parameters_from_context causing a
On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
> On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
> > 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun
> > :
> >
> >> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
> >> convinced me that it should be avoided.
> >
> >
2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
>> 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun
>> :
>>
>>> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
>>> convinced me that it should be avoided.
>>
>> I believe that ffm should (or
On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
> 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun
> :
>
>> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
>> convinced me that it should be avoided.
>
> I believe that ffm should (or at least can) indeed be treated differently
> from al
On 20.11.2016 03:41, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 12:37:05AM +0100, Andreas Cadhalpun wrote:
>
>> ffmdec.c | 52 ++--
>> 1 file changed, 42 insertions(+), 10 deletions(-)
>> a565a670592ad6455e9f26e95edf9886b426dfb3
>> 000
2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun :
> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
> convinced me that it should be avoided.
I believe that ffm should (or at least can) indeed be treated differently
from all other containers.
> 1: https://ffmpeg.org/pipermail/ffmpe
On Sun, Nov 20, 2016 at 12:37:05AM +0100, Andreas Cadhalpun wrote:
> On 19.11.2016 22:36, Michael Niedermayer wrote:
> > On Sat, Nov 19, 2016 at 05:30:59PM +0100, Andreas Cadhalpun wrote:
> >> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
> >> convinced me that it should be avoid
On 19.11.2016 22:36, Michael Niedermayer wrote:
> On Sat, Nov 19, 2016 at 05:30:59PM +0100, Andreas Cadhalpun wrote:
>> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
>> convinced me that it should be avoided.
>
> I think there are 2 different things here
> unavailable data, like
On Sat, Nov 19, 2016 at 05:30:59PM +0100, Andreas Cadhalpun wrote:
> On 19.11.2016 16:28, Michael Niedermayer wrote:
> > On Sat, Nov 19, 2016 at 02:04:44PM +0100, Andreas Cadhalpun wrote:
> >> On 19.11.2016 02:14, Michael Niedermayer wrote:
> >>> On Fri, Nov 18, 2016 at 10:35:29PM +0100, Andreas Ca
On 19.11.2016 16:28, Michael Niedermayer wrote:
> On Sat, Nov 19, 2016 at 02:04:44PM +0100, Andreas Cadhalpun wrote:
>> On 19.11.2016 02:14, Michael Niedermayer wrote:
>>> On Fri, Nov 18, 2016 at 10:35:29PM +0100, Andreas Cadhalpun wrote:
On 18.11.2016 02:40, Michael Niedermayer wrote:
> O
On Sat, Nov 19, 2016 at 02:04:44PM +0100, Andreas Cadhalpun wrote:
> On 19.11.2016 02:14, Michael Niedermayer wrote:
> > On Fri, Nov 18, 2016 at 10:35:29PM +0100, Andreas Cadhalpun wrote:
> >> On 18.11.2016 02:40, Michael Niedermayer wrote:
> >>> On Thu, Nov 17, 2016 at 07:35:01PM +0100, Andreas Ca
On 19.11.2016 02:14, Michael Niedermayer wrote:
> On Fri, Nov 18, 2016 at 10:35:29PM +0100, Andreas Cadhalpun wrote:
>> On 18.11.2016 02:40, Michael Niedermayer wrote:
>>> On Thu, Nov 17, 2016 at 07:35:01PM +0100, Andreas Cadhalpun wrote:
+if (size < 0 || size >= FF_MAX_EXTRADA
On Fri, Nov 18, 2016 at 10:35:29PM +0100, Andreas Cadhalpun wrote:
> On 18.11.2016 02:40, Michael Niedermayer wrote:
> > On Thu, Nov 17, 2016 at 07:35:01PM +0100, Andreas Cadhalpun wrote:
> >> +if (size < 0 || size >= FF_MAX_EXTRADATA_SIZE) {
> >> +av_log(s, AV_L
On 18.11.2016 02:40, Michael Niedermayer wrote:
> On Thu, Nov 17, 2016 at 07:35:01PM +0100, Andreas Cadhalpun wrote:
>> +if (size < 0 || size >= FF_MAX_EXTRADATA_SIZE) {
>> +av_log(s, AV_LOG_WARNING, "Invalid extradata size
>> %d\n", size);
>
> i think this and
On Thu, Nov 17, 2016 at 07:35:01PM +0100, Andreas Cadhalpun wrote:
> On 17.11.2016 02:26, Michael Niedermayer wrote:
> > On Thu, Nov 17, 2016 at 01:08:31AM +0100, Andreas Cadhalpun wrote:
> >> +SANITIZE_PARAMETER(pix_fmt,"pixel format",
> >> codec->pix_fmt <
On 17.11.2016 02:26, Michael Niedermayer wrote:
> On Thu, Nov 17, 2016 at 01:08:31AM +0100, Andreas Cadhalpun wrote:
>> +SANITIZE_PARAMETER(pix_fmt,"pixel format",
>> codec->pix_fmt < AV_PIX_FMT_NONE || codec->pix_fmt > AV_PIX_FMT_NB,
>> AV_PIX_F
On Thu, Nov 17, 2016 at 01:08:31AM +0100, Andreas Cadhalpun wrote:
> All the fields can be set via options read from the ffm file and thus
> have to be sanitized.
>
> A negative extradata size for example gets passed to memcpy in
> avcodec_parameters_from_context causing a segmentation fault.
>
>
All the fields can be set via options read from the ffm file and thus
have to be sanitized.
A negative extradata size for example gets passed to memcpy in
avcodec_parameters_from_context causing a segmentation fault.
Signed-off-by: Andreas Cadhalpun
---
The other fields like qmin etc. seem to b
25 matches
Mail list logo
