[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl

Baptiste Coudurier baptiste.coudurier
Thu Apr 16 19:57:02 CEST 2009


Hi Michael,

On 4/16/2009 6:48 AM, Michael Niedermayer wrote:
> On Wed, Apr 15, 2009 at 04:24:34PM -0700, Baptiste Coudurier wrote:
>> On Thu, Apr 16, 2009 at 12:53:53AM +0200, Michael Niedermayer wrote:
>>> On Wed, Apr 15, 2009 at 03:21:53PM -0700, Baptiste Coudurier wrote:
>>>> On Wed, Apr 15, 2009 at 11:43:12PM +0200, Michael Niedermayer wrote:
>>>>> On Wed, Apr 15, 2009 at 01:51:32PM -0700, Baptiste Coudurier wrote:
>>>>>> On Wed, Apr 15, 2009 at 10:32:29PM +0200, Michael Niedermayer wrote:
>>>>>>> On Wed, Apr 15, 2009 at 01:22:10PM -0700, Baptiste Coudurier wrote:
> 
> [...]
>>>>> the global context doesnt work as the palette isnt global, and
>>>>> using the context is what we do currently and that causes race conditions,
>>>>> which is why its currently not working ...
>>>> No, we do not use a separate context for format _and_ codec currently. That's
>>>> one other option.
>>> Its of no relevance at all if the context is seperate, an application could
>>> take the palette out of AVCodecContext as much as it could out of
>>> AVFormatContext, theres no difference at all both are available to an
>>> application. But applications do NOT do it because its a huge mess to
>>> implement this in a way that works, instead applications take the
>>> palette out of AVFrame.data which is not thread safe and does not work.
>> Well internalizing because it is a big mess to implement can IMHO be a
>> good think of course.
>>
>> Now if you buffer pkt you buffer pkt->palette_data and packet is
>> passed to the decoder using avcodec_decode_video2.
>>
>> What's the problem here ?
> 
> That user apps that are not based on libav* (mplayer, xine, vlc at least)
> dont use AVPacket internally, and i suspect many players will rather drop
> palette support or even libavformat support before redesigning their
> internal buffer and fifo handling to pass vectors of arrays between
> demuxers and decoders.

Indeed that's a good point.

Do you think they will craft special data needed by decoders like palette ?

For gif in .mov, if quicktime is used with perian, you will get in the
decoder what quicktime demux. This means palette will be in
extradata/stsd structure.

For palette in .avi and .wmv, if windows media player is used, you will
get what wmp give to the windows decoder api. This means palette will be
in bmp header.

Game formats case may be different since not many players support them.

Now when the palette is within the bitstream itself interleaved with
video packets, it makes sense to demux these packets "as is" to the
decoder. Do they need to be merged with the video packet ? Maybe, maybe
not, decode_video can return 0 but not set got_picture, decoders should
be already handling this.

When it's not interleaved but pointers to specific palettes in header
are in the bitstream (like WC3), it may be worth using extradata. This
may make seeking and streaming support easier, but there is still a need
to inform the decoder that palette has changed. AVCodecContext field
could be used in this case.

This is a quick picture, and of course is not exhaustive.

Any other information is welcome.

> Also there are systems (maybe dshow?) that are not going to be redesiged
> to allow passing of vectors of arrays between layers
> 
> we are not in power to choose any arbitrary interface between demuxer and
> decoder because players likely have their own interface and just use
> libavcodec and libavformat in addition to their own native system.
> Besides we should not change the interface without exceedingly good reason

This is probably true, see above.

>>>>> [...]
>>>>>
>>>>> I do NOT ignore suggestions that have advantages but I do ignore equivalent
>>>>> suggestions that have no advantages, i rather move forward if noone has a
>>>>> better suggestion.
>>>>>
>>>> Well, I think you are.
>>> You had trolled around like this in the past
>>> mjpeg, gif palette, ...
>> You call discussing, trolling. The discussion was justified IMHO.
>> Besides this was not about gif palette, it was how to implement
>> animated gif in the decoder.
> 
> there where multiple gif trollings i guess ;)
> one was about how the bugs in the gif decoder where twisted by you into
> bugs in swscale and effectively forced me to fix your code to proof you
> wrong.

Sorry for having been so dumb to fail to understand PIX_FMT_PAL8 usage.

>>> and in no case did the discussions lead to anything
>> Of course it did, mjpeg interlacing is somehow fixed, not correctly
>> since it forces a multiple of 2 height, but it somehow works.
> 
> its fixed because i fixed it

I know you are the best.

-- 
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