[Ffmpeg-devel] [RFC] Real demuxer and audio reordering
Tue Nov 22 00:49:59 CET 2005
On Sun, 20 Nov 2005 23:14:27 -0500
Rich Felker <dalias at aerifal.cx> wrote:
> On Sun, Nov 20, 2005 at 06:00:29PM +0100, Roberto Togni wrote:
> WTF? The extradata is raw binary data IDENTICAL TO HOWEVER IT'S STORED
> IN THE FILE!! There is no endianness to it because it is not a
> ready-to-read data structure but a serialized platform-independent
This is data stored in the container that needs to be passed to the
binary codec during initialization. The format is the same as in
MPlayer and all other players that support binary real codecs. At least
sub_packet_h and coded_framesize are needed for raInitDecoder(); flavor
is passed to different functions like raSetFlavor() and
raGetFlavorProperty() (MPlayer uses it to get the bitrate).
We can question it all this is really needed, or if we can trick the
binary codec to work even when inited with fake data; but current
implementation of binary codec interface needs this data.
You also need this information if you want to remux the audio in rm
container (streamcopy, since we don't support encoding to cook or 28_8).
> > *** Extradata
> This is all broken. You should only pass the actual real extradata,
> not additional crap you add on. If the demuxer works in the natural
> correct way this problem goes away entirely.
See above about binary codecs init.
> > *** Timestamps
> > In all samples i tested, all packets in a block have the same
> > timestamp. In the patch i store them anyway and put them on the
> > reordered packets, but this is probably not needed.
> > Is it ok to have many packets with the same timestamp? I don't see any
> > problem in my test, and the current behaviour (without my patch) is the
> > same.
> No, it's not correct. The timestamp only applies to one of the packets
> (the first? the last?) and should only be attached to that one. If the
> calling program needs more timestamps it will have to use a framer to
> build correct timestamps for all the missing ones, but the demuxer
> should NEVER output incorrect timestamps!
Ok. btw the patch was broken and was already outputting timestamp only
for the first packet in a block.
I have no idea about the timestamp position, i can only guess that it
refers to the beginning of the complete block; if someone have more
info on this please let me know.
> > - Do we care about being able to use binary codecs with lavf demuxer?
> Yes and no. Yes, we should be able to use them, but it's up to the
> wrapper code for the binary codec/loader to adapt the data back into
> whatever broken/container-incest format the binary codec needs.
That's true as long as the loader have all the information required to
perform the task, I'll try to play with the binary init code to check if
some info can be omitted at init stage.
I like the "packet size = minimum decodeable unit" concept (that's why
i proposed the 3rd solution), i just want to be sure that it can work
also with binary codecs; if it doesn't i prefer to use the secont
solution even if it's not perfect.
Anybody knows how matroska stores real audio? I know that
they "defragment" video frames, but i have no idea about audio.
More information about the ffmpeg-devel