On Fri, Mar 11, 2016 at 02:12:56PM +0100, Mats Peterson wrote: > Mats Peterson <matsp888-at-yahoo....@ffmpeg.org> skrev: (11 mars 2016 > 14:06:19 CET) > >Mats Peterson <matsp888-at-yahoo....@ffmpeg.org> skrev: (11 mars 2016 > >13:55:20 CET) > >>Michael Niedermayer <mich...@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@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@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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
