[FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Improve spec compliance

[Michael Niedermayer]

On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote:
> Mats Peterson <matsp888-at-yahoo.com at ffmpeg.org> skrev: (11 mars 2016 14:06:19 CET)
> >Mats Peterson <matsp888-at-yahoo.com at ffmpeg.org> skrev: (11 mars 2016
> >13:55:20 CET)
> >>Michael Niedermayer <michael at niedermayer.cc> skrev: (11 mars 2016
> >>13:49:32 CET)
> >>>On Fri, Mar 11, 2016 at 01:28:47PM +0100, Mats Peterson wrote:
> >>>> On 03/11/2016 01:25 PM, Mats Peterson wrote:
> >>>> >On 03/11/2016 01:14 PM, Michael Niedermayer wrote:
> >>>> >>On Fri, Mar 11, 2016 at 05:17:18AM +0100, Mats Peterson wrote:
> >>>> >>>On 03/11/2016 05:10 AM, Mats Peterson wrote:
> >>>> >>>>Forget patch 2/3 and 3/3 from the old patch set.
> >>>> >>>>
> >>>> >>>> From the Microsoft documentation for BITMAPINFOHEADER at
> >>>>
> >>>>>>>https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>"biSize: Specifies the number of bytes required by the
> >>structure.
> >>>This
> >>>> >>>>value does not include the size of the color table or the size
> >>of
> >>>the
> >>>> >>>>color masks, if they are appended to the end of structure."
> >>>> >>>>
> >>>> >>>>So, biSize is always 40. Also, Windows Media Player won't
> >detect
> >>>video
> >>>> >>>>encoded with Microsoft Video 1 in 8 bpp mode if this value is
> >>>anything
> >>>> >>>>else than 40. I don't know about other codecs, they probably
> >>>work.
> >>>> >>>>Anyway, we should stick with the specs, and not include the
> >>>palette
> >>>> >>>>size
> >>>> >>>>in that field.
> >>>> >>>>
> >>>> >>>>Regarding the biClrUsed field, I'm setting it to 1 <<
> >>>> >>>>bits_per_coded_sample if palettized video, since setting it to
> >0
> >>>is
> >>>> >>>>another case where it won't work with Windows Media Player and
> >>>> >>>>Microsoft
> >>>> >>>>Video 1 in 8 bpp mode.
> >>>> >>>>
> >>>> >>>>Mats
> >>>> >>>>
> >>>> >>>>
> >>>> >>>>
> >>>> >>>
> >>>> >>>Once, again, HuffYUV has its own variant of BITMAPINFOHEADER
> >that
> >>>> >>>*does* include the size of the Huffman tables in biSize. That's
> >>>the
> >>>> >>>only exception as far as I know.
> >>>> >>
> >>>> >>is huffyuv really the exception ? and not raw rgb or palettes ?
> >>>> >>
> >>>> >>asv1 and asv2 do not have 40 there
> >>>
> >>>> >>which codec with a non-palette global header puts 40 there ?
> >>>
> >>>[...]
> >>>
> >>>> As I said before, Microsoft Video 1 in 8-bit mode and RLE4/RLE8
> >>>> won't even display in Windows Media Player if this value is
> >anything
> >>>> else than 40.
> >>>
> >>>msv1 / RLE4/8 doesnt have a "Non palette global header"
> >>>
> >>>
> >>>[...]
> >>
> >>That's correct. Sorry. Anyway, the only case I know of is HuffYUV with
> >>its special variant of BITMAPINFOHEADER that includes the Huffman
> >>tables. Is there stated anywhere in the ASUS specs that the size of
> >the
> >>extra data following the BITMAPINFOHEADER should be included in
> >biSize?
> >>If not, it should be 40.
> >>
> >>Mats
> >>-- 
> >>Mats Peterson
> >>http://matsp888.no-ip.org/~mats/
> >>_______________________________________________
> >>ffmpeg-devel mailing list
> >>ffmpeg-devel at ffmpeg.org
> >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >Those asv1/asv2 files play just fine with a biSize of 40, at that.
> >
> >Mats
> >-- 
> >Mats Peterson
> >http://matsp888.no-ip.org/~mats/
> >_______________________________________________
> >ffmpeg-devel mailing list
> >ffmpeg-devel at ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Should we perhaps "tighten" the "specs" (I saw that you have written some documentation on asv1/asv2 in FFmpeg), and include those extra bytes in biSize? I suppose this is somewhat of a proprietary FFmpeg invention.

we didnt invent ASUS video 1 and 2 nor huffyuv

which codec with a non-palette global header puts 40 there ?

the ms specs just says the color table & mask isnt part of biSize
it doesnt say the global header isnt, or iam looking at the wrong text
or location in the text/spec

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160311/b735b51c/attachment.sig>