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 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 possibly others should be a hard failure
> >>> or why would a invalid extradata_size be ok ?
> >>
> >> The decoder might still be able to work.
> >> What would be the advantage of a hard failure?
> >
> > the advantage of stoping clearly invalid data early
> > The decoder runs on a seperate machine with ffm possibly. The file
> > just gets demuxed and sent over the network. The warning hinting to
> > the issue is on the sending side. The decoder failure at the receiver
> > i didnt try but if iam not mixing things up that would be confusing
> > neither side would fully understand whats going on without the other
>
> OK, I changed the extradata_size case to an error.
> Which others do you think should be changed, too?why do you want to accept any invalid values ? ffm files should only be generated by FFmpeg, why should FFmpeg generate invalid files or what is the use case where this occurs ? It feels like iam missing something here ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
