[vlc-devel] RE : RE : [PATCH] -- still image demux

[brezhoneg1]

> -----Message d'origine-----
> De : vlc-devel-bounces at videolan.org [mailto:vlc-devel-
> bounces at videolan.org] De la part de Antoine Cellerier
> Envoyé : dimanche 4 janvier 2009 19:44
> À : Mailing list for VLC media player developers
> Objet : Re: [vlc-devel] RE : [PATCH] -- still image demux
> 
> On Sun, Jan 04, 2009, brezhoneg1 wrote:
> > TODO: maybe remove support of bmp and gif by avcodec or change
> > priorities which decoder is chosen?
> 
> Removing bmp and gif support from avcodec sounds fine to me if we're
> sure that it indeed can't decode them properly. (is it possible to use
> ./ffmpeg to decode images and test that way?)

Actually, after some more testing, avcodec seems to only support a
subset of bmp files whereas sdl_image seems less demanding.

For bmp files not supported by avcodec, the error is (only warnings but
no display is created) :
[0x838bbe0] avcodec decoder warning: cannot decode one frame (3145782
bytes)
[0x838bbe0] avcodec decoder warning: not enough data (54 < 54)

This same error is also issued by ffmpeg/ffplay for those bmp files.

For jpeg files, both sdl_image and avcodec have problems displaying very
large files ( a 2048x1536 jpeg file failed with both of them, and was
checked successfully against gimp)

Some gif files lead to a black screen with avcodec and are displayed
successfully with sdl_image.

Yet, those tests were limited to about 30 different images. They cannot
be used to make it a general rule. More comprehensive tests should
certainly be needed before making any change.


> 
> > The only difference I see is that the image is decoded only once in
the
> > latter case, whereas it is decoded again and again with the new
demuxer.
> > I didn't quite figure out all the implications regarding the pts
> > computation. Maybe somebody who masters the pcr issues could be of
great
> > help to solve these warnings.
> 
> Can't we cache the decoded image?

Well, a simple way to remove this problem is to send a block only the
first time Demux is called.
 - es_out_control (... , SET_PCR, ...) is incremented to enable finite
duration.
 - es_out_send is only called once.

This actually works fine for basic needs and no warnings are issued. For
more complex use (sout for example), this most probably won't work, but
fake:// can still be used for those cases.

A more complex thing could be to cache the decoded image. Actually, that
is the current implementation of fake divided into a fake access_demux
and a fake decoder. This was certainly done on purpose for better
performance, but with the drawback of more complexity for end-users.


Last thing, is there a reason why only 2 out of 4 patches were applied
from the previous mail I sent?

Erwan10