[FFmpeg-devel] [PATCH 1/2] avformat/icodec: ico probe with unknown data

[Michael Niedermayer]

On Tue, Feb 16, 2016 at 01:42:50AM -0800, Mark Harris wrote:
> >>     Header:  OK, 2 frames
> >>     Frame 0: Unknown (offset points beyond end of probe buffer)
> >>     Frame 1: Invalid
> >> Previously this example had a score of 25, even though the score would
> >> be 1 if the unknown frame was known to be valid or 0 if it was known
> >> to be invalid.  For this example the score is now 1.
> >
> > If the header is ok and the offset points beyond the end
> > of the probe buffer, the score was always 25 (before I
> > extended the check). Why should this be changed?
> > 25 is not very high after checking ~40 bit.
> 
> If you think that 25 is better when there is 1 unknown frame and 1
> invalid frame, I don't see an issue with that.  However in that case,
> when the unknown frame is known to be valid it should have a score
> that is at least the same value.  It doesn't make sense for the score
> with an unknown value to be higher than the highest score that could
> possibly be produced if the unknown value was known.
> 
> For this patch I just wanted to keep the behavior exactly the same in
> the common case where all of the data is in the buffer.
> 
> For the case of unknown data, the existing code can do strange things.
> For example if the probe buffer ends in the middle of a size or offset
> field then it can end up reading a partial value, which can cause it
> to check bytes at the wrong offset or produce false positives or false
> negatives.  There were also inconsistencies if there was a mixture of
> unknown and invalid data.  It seemed only logical that with unknown
> data the score should never be higher than what it would be if the
> data was known to be valid, and never be lower than what it would be
> if the data was known to be invalid.  So I preserved the existing
> behavior for the cases of known data, and adjusted the behavior for
> unknown data so that the scores would be within these constraints and
> so that there was no reliance on the zero padding.

patch applied

the hardcoded litteral offsets could be replaced by named constants
or comments be added

also the score should possibly be higher for truncated files,
it would be better if a decissive recognization could be done before
the whole file needs to be read

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160220/dd5fa833/attachment.sig>