[MPlayer-dev-eng] Cleaning your nuts

[Michael Niedermayer]

Hi

On Thursday 22 April 2004 18:22, D Richard Felker III wrote:
> On Thu, Apr 22, 2004 at 05:32:06PM +0200, Michael Niedermayer wrote:
[...]
> > lsb timestamps should be enough for these packets too, so i guess the
> > type 1 headers would be 50-70% smaller then type 2
>
> BTW we should address the msb/lsb/relative timestamp issue. My
> proposal has been to get rid of msb/lsb thing and just use relative
> timestamps for type0 (and type1?) frames if possible. But maybe the
> lsb thing is more robust in the presence of errors. IMO relative is
> much more compact, especially with the 3 delta predictors.
yes, its also unfortunate that fulltimestamp, lsb + 3delta = 5 which doesnt 
fit in 2 bit, maybe be could use AC coding for the header, no iam not joking
for example 3 cases of size_lsb (size= 3*size_msb + size_lsb) with 5 timestamp 
cases would fit in 4bit
encoding: timestamp + 5*size_lsb
decoding: with %5 and /5

[...]
> > 2. possibility: use 2byte startcodes, and escape all occurances of this
> > 2byte code in the stream, we wouldnt even need to store the packet size
> > in this case, but theres the (un)escaping which needs to be done which
> > wastes cpu time, we could also use a few bits (~4) of these 2 bytes as
> > flags
>
> IMO this is totally unacceptable. The cpu overhead for high bitrate
> mpeg2/4 would be insane.
u wont like h264 ...

>
> > > Caveats: Before writing any packet, the muxer must know that no other
> > > stream will want to write a packet before it. Either the muxer can
> > > buffer one packet in each stream, or the calling app can just call the
> > > muxer in the proper order.
> >
> > further caveat, do we use the timestamp of the first, last or middle
> > sample of an audio frame?
>
> I was just thinking about it this morning. IMO all timestamps must be
> for the very beginning of the frame. (This applies to video too since
> sometimes a video frame is 2 fields.) Beginning is the only useful
> piece of information to know for the player. If the timestamp is the
> middle or end, you have to know the decoded length of the frame in
> order to get the beginning timestamp, which is the important piece of
> information. Also, anything but beginning timestamp would be
> disastrous for proper interleaving, especially with subtitle packets!
yes fully agree

>
> > > 2. Get rid of framecode and replace it with something non-obfuscated.
> > > [...]
> > > Rationale: Meets the simplicity goal and perhaps improves error
> > > recovery.
> >
> > simlicity, yes,
> > error recovery IMHO no, its easily possible to require 50% of the
> > framecodes to be invalid to detect errors
>
> Then you only have a 50% chance of catching an error, and you added
> lots of overhead. Bad tradeoff.
its a fundamental problem, length >= log(legal_count + illegal_count)
overhead= 1bit here btw

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en