Re: [codec] requirements #8 (new): Sample rates?

["Pascal Pochol" <[e-mail]>]

Brutus,

> Well, but you probably need at least one bit to signal header/data
> packets, no?

for what we do, no. We open a stream we can easily assume the header is at
the beginning and everything after that is data packets. We don't have
anything that can join in midstream or change the format midstream or
anything like that. Again this is very specific to what we do it might not
fit others needs. I wouldn't even have a problem if we simply had to call a
few api functions before encoding to set everything up and call a few api
functions before decoding with the same type of parameters to let the
decoder know what it's about to receive and not even use a header. Since we
write both encoder and decoder programs to fit our needs and nobody else
reads our encoded data.

when we used speex we started with the standard speexenc/speexdec format
encapsulated into an ogg. But that was too complex so we dropped the ogg
container and used samplexenc.c and sampledec.c instead. We made our
version of sampleenc.c spit out a tiny header at the beginning that would
give us some basic information that we needed in order to decode
everything. I don't remember off hand what it contained one was the
original number of samples I think. And we loaded that in our decoder and
that was it. the rest of the files were all the smallest speex packets we
could make. We noticed that the first byte was a constant size of the frame
so we dropped that out as well and moved it into the header. That saved a
few hundreds to a few thousands bytes for each file (a few thousands of
files total) for a huge saving. For us a byte is still a full 8 bits which
can be used to store a lot of information, so I perfectly understand and
appreciate this group's concern about adding a few bits to each packets. My
personal vote for opus-custom would be to use api calls and not store any
more data than absolutely necessary in the stream. Since using the custom
mode mean using custom code on both ends it's not a problem for us.

-Pascal