[vlc-devel] [PATCH] Implemented libjpeg decoder module

[Maxim Bublis]

>
> But that means that if any MJPEG stream has those FOURCC, it won't get
> decoded anymore, no?


I've looked closer at the code recently. I'll give my explanation in
context of src/misc/fourcc.c.

There is only one function, which operates on p_list_video - Find.
Find is called by vlc_fourcc_GetCodec and vlc_fourcc_GetDescription.
First function returns FOURCC created from entry.p_class, and the second
one just returns entry.psz_description.

Find function invokes Lookup function passing p_list_video as first
argument to it and desired fourcc as second one.
Lookup function is an O(n) algorithm, which is really a simple 'for` loop
iterating over p_list_video.
For each entry in p_list_video it compares its fourcc with passed argument
and in case they equal, returns entry constructed from last seen not null
p_class and psz_description.

Currently, image demuxer (modules/demux/image.c) uses
vlc_fourcc_GetDescription for debug purposes only and doesn't use
vlc_fourcc_GetCodec, so my changes in src/misc/fourcc.c only fix debug
message.

But some demuxers (avi for example) uses vlc_fourcc_GetCodec, and if you
call it like vlc_fourcc_GetCodec(VIDEO_ES, VLC_CODEC_JPEG) it will return
VLC_CODEC_MJPEG instead and it is the reason why it currently works for AVI
streams with incorrectly defined (buggy) Motion JPEG videos as simple JPEG
images. My changes in src/misc/fourcc.c surely will break this behavior,
and it is the reason I'll resubmit patch in a few minutes, but you should
know, that current code could possibly lead to undesired behaviour, when
you are expecting to get libjpeg codec, but instead of it you'll get
something like avcodec which could possibly be slower.


-- 
Maxim Bublis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20131219/9ff538f9/attachment.html>