[FFmpeg-devel] theora depayloader

[Josh Allmann]

Awesome, almost there...

On 22 March 2010 04:17, Martin Storsj? <martin at martin.st> wrote:
>> > So a wild guess on the exact amount of bytes written would be 1 +
>> > length1/255 + 1 + length2/255 + 1 + length - is this correct?
>>
>> Sounds about right, I kept the original length/255 rather than divide
>> by 255 twice to get an exact amount. We may over-allocate a little,
>> but shouldn't be by much. (length <= length1+length2)
>
>> Erm, I meant length >= length1+length2
>
>>
>> + ? ?/* allocate extra space:
>> + ? ? * --length/255 +1 for xiphlacing
>> + ? ? * -- one for the '2' marker
>> + ? ? * -- FF_INPUT_BUFFER_PADDING_SIZE required */
>> + ? ?extradata_alloc = length + length/255 + 2 + FF_INPUT_BUFFER_PADDING_SIZE;
>
> I'm ok with this.
>
> Although, if I'd be pedantic, I'd point out that even if length >=
> length1+length2, you should count length/255 + 2 for the xiphlacing, since
> each invocation gives you +1. :-)

It is now:
+ ? ?extradata_alloc = length + length/255 + 3 + FF_INPUT_BUFFER_PADDING_SIZE;

>
> What's left (in my opinion) is mostly a few cosmetic issues:

Got the rest of them, hopefully.

>
>> + ? ?} else if (fragmented == 1) {
>> + ? ? ? ?// start of theora data fragment
>> + ? ? ? ?int res;
>> + ? ? ? ?assert(!num_pkts);
>
> Hmm, doesn't this depend on the actual data of the packet? That is, this
> assert could be triggered by a bad packet, and therefore should be a
> warning/error with a suitable return, instead of an assert.

I just removed the assert.
The spec says num_pkts should be 0 for fragments, but num_pkts isn't
used in that block anyway.

>
>
> Except for these details, this looks good. :-)
>
> // Martin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: theora_depayloader.diff
Type: text/x-patch
Size: 16076 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100322/cc3cb7f1/attachment.bin>