[FFmpeg-devel] [PATCHv3 3/6] dvbsubdec: always return the whole buffer as consumed bytes

[Reimar Döffinger]

On Wed, Oct 16, 2013 at 07:54:23AM +0100, JULIAN GARDNER wrote:
> >>>  Unfortunately I don't have a sample transport stream. The only 
> > reference I could find why leftover junk bytes are even possible is here:
> >>> 
> >>>  http://ffmpeg.org/pipermail/ffmpeg-devel/2011-February/103659.html
> >>>  (mplayer ts demuxer outputs an extra byte)
> >>> 
> >>>  The patch is needed to ensure that leftover bytes still do not cause 
> > any frame decode errors after extending avcodec_decode_subtitle2 to support 
> > multiple frames in a single packet. So it's for compatibility and keeping 
> > existing behaviour.
> >>> 
> >>>  Regards,
> >>>  Marton
> >>>  _______________________________________________
> >>>  ffmpeg-devel mailing list
> >>>  ffmpeg-devel at ffmpeg.org
> >>>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>> 
> >> 
> >> 
> >>  Well I would say "get mplayers demuxer fixed 1st"
> >> 
> > 
> > Yes, sure, but are you saying that we should change the behaviour of the 
> > decoder to return AVERROR_INVALIDDATA in case of leftover bytes?
> > 
> 
> but you are changing it, instead of returning the correct number of bytes your returning the number of bytes passed to it, which is the wrong number hence the warning message. Who is to say that these bytes do not have some meaning? I know your trying to fix a bug in mplayer, but why not push them for a fix first.

I don't think he tries to fix a MPlayer bug but just tries to not change
behaviour more than necessary.
If for no other reason that it might affect more cases.
We definitely should not return AVERROR_INVALIDDATA (except with high
values of strict or similar), we generally should try to accept any
input we can make sense of.
If we are confident that leftover bytes are due to a bug somewhere, I
think printing a warning message (instead of just debug) each time is
quite ok for example.
Either way I have a bit of a problem with saying "the correct number of
bytes", because I think we have quite different behaviours in codecs,
so "correct" is unfortunately not that well defined IMHO.