LAV Splitter does not write buClrImportant from AVI headers to the media type

[GoogleCodeExporter]

LAV Splitter deletes (or omits) information in BITMAPINFOHEADER of AMMEDIATYPE, 
in particular the field biClrImportant (and maybe others). I don't know about 
other container formats, but I am referring here to AVI containers.

This issue causes malfuntion of certain codecs which require the full header 
information for video decoding, e.g. the ones I developed some years ago for a 
commercial/industrial purpose (and which are quite widespread in their field of 
application).

It would be great if you would fix this and provide all information stored in 
the video file to the decoder filters.

Original issue reported on code.google.com by t...@inot.de on 21 May 2013 at 8:47

[GoogleCodeExporter]

Because LAV supports a very large variety of formats, such rather format 
specific values are not extracted from the file, because format-specific hacks 
are kept to a minimum, and i've never seen a format before where these values 
are actually required.

It may be possible to communicate this to the function which creates the final 
media types, but its not going to be soon.

Original comment by h.lepp...@gmail.com on 21 May 2013 at 9:04

• Changed title: LAV Splitter does not write buClrImportant from AVI headers to the media type
• Changed state: Accepted
• Added labels: Component-DirectShow, Component-ffmpeg, Filter-Splitter, Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I just checked the source of FFmpeg 1.2.1: It looks like FFmpeg just ignores 
all "advanced" fields such as biClrImportant or just sets them to 0. So if LAV 
entirely relies on FFmpeg, the chance to fix this might be very small - or it 
would have to be fixed in FFmpeg. It would just require another 
AV_SIDE_DATA_PARAM_*

On the other hand this means all software using FFmpeg (or libav) won't be able 
to decode these files...

Original comment by t...@inot.de on 21 May 2013 at 10:47