[FFmpeg-devel] [PATCH] Indeo 5 decoder
Maxim
max_pole
Mon Feb 8 12:25:36 CET 2010
Kostya schrieb:
> On Sat, Feb 06, 2010 at 11:07:06AM +0100, Reimar D?ffinger wrote:
>
>> On Sat, Feb 06, 2010 at 11:39:24AM +0200, Kostya wrote:
>>
>>> On Sat, Feb 06, 2010 at 10:07:10AM +0100, Reimar D?ffinger wrote:
>>>
>>>> On Thu, Feb 04, 2010 at 09:44:13AM +0200, Kostya wrote:
>>>>
>>>>> On Wed, Feb 03, 2010 at 09:27:29PM +0100, Reimar D?ffinger wrote:
>>>>>
>>>>>> On Mon, Feb 01, 2010 at 07:49:55PM +0200, Kostya wrote:
>>>>>>
>>>>>>> + uint32_t frame_num;
>>>>>>>
>>>>>> Only a 8-bit value is stored in that, also it is unused...
>>>>>>
>>>>> still, it's in the bitstream. I'd like to keep it for debug purposes.
>>>>>
>>>> I wasn't objecting to reading it, I just don't like it much that
>>>> you're storing it in a context variable, that makes it rather hard
>>>> to find out it's not used.
>>>> Why do you think it is worse to do e.g.
>>>>
>>>>
>>>>> + ctx->frame_num = get_bits(&ctx->gb, 8);
>>>>>
>>>> skip_bits(&ctx->gb, 8); // frame_num
>>>> (or keep the get_bits, then it's even less change to re-add it).
>>>>
>>> Not that I have any strict preferences, decoder author used this and I'd
>>> like to keep it this way.
>>>
>> Then at least add a comment somewhere for the poor person trying to find out
>> what the purpose of that is.
>> Possibly sort all those unused variables at the end and put a "// these are currently
>> not used" above it or something.
>> Also the "decoder author used this" would be more convincing if I knew if this was
>> intentional or if it's just a left-over from the beginning when it was unclear
>> if it would be needed or not.
>>
>
> Should be obvious for frame_num, can't say anything for the other fields,
> but it looks to me that Maxim tried to follow original codec structure
> closely.
>
I'm online again (I was moved to another town last week...)
The variables "frame_num" and "gop_hdr_size" belong to some error
cancealment code I wrote but never included into the final patch...
- "frame_num" was used to detect if there was any frame drop in the
sequence. If yes, the decoder should wait for the next key frame...
"gop_num" was intended for debug purposes only...
Regards
Maxim
More information about the ffmpeg-devel
mailing list