[MPlayer-users] Re: Free audio codec for .AVI files ?

[D Richard Felker III]

On Tue, Jan 27, 2004 at 08:52:33PM +0100, Alexander Noé wrote:
> D Richard Felker III wrote:
> 
> >>When lacing 2 frames into one block for a CFR file, it would be the 
> >>same, and should be less
> >>for larger laces.
> >>   
> >>
> >
> >I don't even want to know about this "lacing" nonsense. It's huge
> >added complexity 
> >
> You make a fool of yourself within one sentence. You say that you 
> neither know what it is,

I know it's a way of packing together data from different frames. The
name suggests that the packing is done out-of-order to spread out
damage and minimize its impact, which would be useful but also would
require large buffers in the player. Maybe this isn't the case, but
then the name "lacing" is stupid, since laces (in the ordinary sense)
criss-cross. In any case, I know enough to talk about it.

> nor do you want to know, but you really dare to judge the complexity (or 
> lack thereof) which
> it adds.......if you had looked at my audio reading classes, you would 
> have noticed that

Sorry, I have better things to do than read nasty C++. Perhaps if you
would write proper documentation IN THE SPECS then I could read it. I
know you have specs, but they remind me of RFC 1459: lots of info, but
no explanation of how it all fits together, and not sufficient to use
as the basis for an implementation. (If one writes an irc client or
server solely based on RFC 1459, it won't work with any existing
clients or servers. Thus it serves as a good example of bad "specs".)

> resolving the laces (= hide their existence for something using that 
> class) causes a neglectible
> amount of extra code, compared to the size of the AVI or matroska 
> parsers, or even writers.

AVI parsing is totally trivial without seeking. And seeking is easy
too in proper VBR files. AVI demuxing only gets complicated when you
want to support files written by horribly broken programs that don't
even interleave audio, or interleave it incorrectly.

> >that a hardware device without excessively large
> >buffers would never be able to handle. And only "CFR"? Why do you
> >distinguish "CFR/VFR" anyway in the file format? They're just
> >different time base units...
> > 
> >
> For CFR, you can leave out some time stamps and then accurately guess 
> them back. For
> VFR, you can't.

This isn't very helpful, since timestamps only take 1 byte if done
correctly. Of course you use stupid 1/10**n based timestamps rather
than a real time base, so your timestamps are very big.

> So you can only seek on Block accuracy for VFR, but 
> frame accuracy
> for CFR. Thus, if you want to maintain frame accuracy for seeking in 
> VFR, you need one
> block = one frame = no lacing. If you don't need frame accuracy on 
> seeking, you can
> surely lace VFR.

Wait, how can you even play the file if there are no timestamps on the
individual frames and the file is VFR? This makes no sense. There must
be some way to get the timestamps... For audio you get durations in
samples by decoding, so that works, but with video, the codec normally
cannot tell you the correct frame duration.

> That's why avi-mux gui does not lace vorbis audio by default...ups, 
> again this bad word
> you don't want to know nothing about :p

By the way, why does Matroska invent its own silly names for things
which already have nice established names? Just to confuse critics so
you can insult them when they try to explain how bad Matroska is?

> >Now you're being completely stupid. Obviously you don't shrink down
> >identifiers to make it smaller.
> >
> I want to be able to read my own code.

Right, that's why I said don't do it.

> >If you want, compare the binary sizes
> >instead.
> >
> ...if made by the same compiler...

Look, stop being a fucking idiot. The bloat of the matroska demuxer is
not caused by your symbol names, or your compiler, or any such
nonsense. It's caused either by matroska being overcomplicated, or you
being a bad coder, or possibly both.

> >BTW your mailer seems to have a problem with adding lots of extra
> >lines when quoting...
> > 
> >
> Everything shows up nicely here. I don't even use UTF-8 for those who 
> still use
> primitive OSes.

This is extracted from your previous mail:

----------------------------------------------------------------------
>On Tue, Jan 27, 2004 at 06:58:57PM +0100, Alexander Noé wrote:
>
>
>>OK, I'll only comment on statements which are obviously nonsense:
>>
>>
>>
>>>3. OGM reportedly lacks support for variable-fps video, but I'm not
>>>sure this is true.
>>>
>>>
>>It could be done using one page per frame, but the overhead would be
>>hilarious (about 30 bytes per frame = twice as much as AVI)
>>
>>
>
>Eh? One page per frame should decrease overhead, since all the
>overhead comes from the page headers... I guess I don't follow what
>you're saying.
>
>
----------------------------------------------------------------------

As you can see, lots of extra lines that came out of nowhere...

BTW notice that your "non-primitive" mailer doesn't even know how to
wrap lines properly:

----------------------------------------------------------------------
> Everything shows up nicely here. I don't even use UTF-8 for those who 
> still use
> primitive OSes.
----------------------------------------------------------------------

Looks like it wrapped once when you were writing then again when
sending.....

Rich