Any objection to this patch? It makes it somewhat easier/nicer to move over the stream flags to API, and keep the nut flags in the demuxer... Also, 128 is low enough for the flags which have no use to be coded in frame header, because vlc's can only store up to 127 in a single byte. Also, the non-stream flags are pushed to top of first byte so they can expand towards down while stream flags expand toward up... (I know, this is all very silly, but I see no reason against any of this, the decision between this is almost arbitrary, so might as well go with the more convinient direction?) - ods15
Hi On Sat, Mar 11, 2006 at 02:59:44PM +0200, Oded Shimon wrote:
Any objection to this patch? It makes it somewhat easier/nicer to move over the stream flags to API, and keep the nut flags in the demuxer...
Also, 128 is low enough for the flags which have no use to be coded in frame header, because vlc's can only store up to 127 in a single byte.
yes, but that brings up another incredible minor improvement, i mean bits 0-6 go into the first byte bits 7-13 need a second byte so if we put the first group in 0..X, and the "we wont store in frame header" group in 7..Y then extending the first beyond 0..6 will be messy, why not put the second in Y..13 instead? and yes iam fine with your proposed change [...] -- Michael
participants (2)
-
Michael Niedermayer -
Oded Shimon