[FFmpeg-devel] [PATCH] add av_shrink_packet

Baptiste Coudurier baptiste.coudurier
Wed Apr 8 03:02:39 CEST 2009


On 4/7/2009 5:49 PM, Michael Niedermayer wrote:
> On Tue, Apr 07, 2009 at 05:20:01PM -0700, Baptiste Coudurier wrote:
>> On 4/7/2009 4:38 PM, Michael Niedermayer wrote:
>>> On Wed, Apr 08, 2009 at 12:17:32AM +0200, Reimar D?ffinger wrote:
>>>> Hello,
>>>> currently av_get_packet upon a partial read simply resizes the packet
>>>> by setting pkt->size. Unfortunately like that the padding will not be
>>>> set to 0 as required, it can actually be uninitialized.
>>>> Attached is a possible solution to this.
>>> not pretty but ok as i ve no better idea either
>>>
>> Print and return error in this case ?
>>
>> Feeding partial packets might be a good way to test decoder resistance,
>> but overall it only produces bug reports and bugs in my experience.
> 
> for the raw case the last frame that is partial for the demuxer is not
> partial for the decoder, as the demuxer doesnt know the frame sizes
> only after the parser are they known ...

Well, yes and no, that's because the way "raw" demuxers are implemented.
If parsers were reading data directly, this would not be the case I believe.

> also if just 1 byte is missing it would be annoying if the frame would
> be thrown away for non raw demuxers

Not false.

> and decoders have to deal with nonsense input anyway, throwing such
> away at demuxer level doesnt feel correct to me

Well, I tend to agree but this is only good if someone actually fixes
crashes in decoder...

Discarding know to be incomplete packets, mainly because of EOF, in
demuxers knowing it, is not necessarly a bad idea, in my experience,
like I said.

> maybe we could set some flag in AVPacket to indicate that a packet is
> possibly damaged, iam not sure if this would be of any use, but a user
> application could at least drop such packets if its author thinks its
> better though i dont really think it is ...

Well when you know that decoder is not error proof regarding partial
packets, it certainly is IMHO.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list