[FFmpeg-devel] [PATCH V3] [RFC] GSoC: FLIF16 Image format parser

[Anamitra Ghorui]

Hello,

March 15, 2020 2:15 AM, "Jai Luthra" <me at jailuthra.in> wrote:
>On Fri, Mar 06, 2020 at 06:10:04PM +0000, Anamitra Ghorui wrote:
>>The parser has been tested and is able to correctly identify the start
>>of the compressed bitstream. The patch has a set of printf statements
>>which print a "tracing table" of the behaviour. Upon Nicolas George's
>>suggestion I have made it so that the varints are read into a uint64_t.
>>Hence the varints are limited in the range 0 to 2^64 - 1.

>Yes afaics parser does not generally return errors. Usually the parser splits 
>the frames out if it is able to, and the decoder verifies if something is 
>wrong within the packet bitstream.
>
>I am not certain how this should be handled here as you plan to do entropy 
>decoding within the parser.
>
>Parser's ret value being < 0 usually implies that frame start was in previous 
>packet, but look around other parsers and ask in #ffmpeg-devel if your 
>approach is feasible.

The main reason I was trying to decode the bitstream in the parser itself was
that the specification doesn't mention anything about the size of the compressed
bitstream from what I can see. We however can read through the second/image 
description header and the uncompressed length of the pixel data is already 
known. 

Another approach I would suggest is simply to send the bytes over to the output 
buffer unaltered without doing anything, but then there is no need
to even really have the parser aside from just being congruent to the standard 
decoding procedure given in the example code (decode_video.c), and finding 
the start of the bitstream.

The decoder will then throw a series of AVERROR(EAGAIN)s while the bitstream is
being read.

I will ask around.

>>Now comes the part of decompressing the bitstream and finding the bounds
>>of the data. I haven't yet properly gone through the reference
>>implementation due to a lack of time (I will have now), but I'm thinking
>>of defining a few functions:
>>
>>int ff_flif16_read_rac(uint8_t *buf, unsigned int buf_size,
>>					unsinged int offset,
>>					FLIF16ChanceTable chance);
>>int ff_flif16_read_uni_int(int min, int max);
>>int ff_flif16_read_nz_int(int min, int max,  FLIF16ChanceTable context);
>>int ff_flif16_read_gnz_int(int min, int max, FLIF16ChanceTable context);
>>(...)
>
>I haven't heard from the other applicant who was working on the entropy 
>decoding task, so I would suggest you can go ahead with implementing this. I 
>think you may be able to use/modify the existing range coder ffmpeg module.

I see, but I am a bit confused about the tasks that we are to complete during 
the official work period and now. Where should I stop?

>>
>>The decoder itself will not handle decompressing or decoding the
>>bitstream, rather we will alter the buffer to add in the decompressed
>>bitstream, then run it through the parser and add it to the AVPacket,
>>and finally pass it to the decoder. The decoder will then decode all
>>the frames from that single packet.
>>
>
>
>>+typedef struct FLIF16ParseContext {
>>+    ParseContext pc;
>>+    int state;              ///< The section of the file the parser is in currently.
>>+    unsigned int index;     ///< An index based on the current state.
>>+    uint8_t iac;            ///< Interlaced, animated, color palette info
>
>For testing this is good enough, but I think it would be a better idea to have 
>separate fields in the context for interlaced/animated/color pallete etc. so 
>that you don't need to do bitshifts everywhere you need to use them as done 
>below.

Okay

Regards,
Anamitra