[Libav-user] QuickTime file reading explanation
Info || Non-Lethal Applications
info at non-lethal-applications.com
Tue Jul 1 12:00:39 CEST 2014
I just reported an issue I was running into with a DV file in the QuickTime container last week.
I was reading a DV file and I received 25 frames of video before the first packet of audio. This means that I’d need to buffer a lot of video to read audio that I need for synchronous AV playback.
I was trying to investigate the issue a bit further and I ended up having a look at the file in question with Apple’s Atom Inspector.
I realized that every single data chunk is properly written into the Chunk Offset Sample Table (‘stco’ atom).
The video track data comes first and the audio track data is stored after it.
As all the information is there separately and not in an interleaved order that would explain my issue, I’m wondering if there’s anything I could do to get rid of the video frame buffering?
Is there any decoder/demuxer setting I could influence from the outside to get the packets in a different order?
Which part decides in which order the A/V packets are being processed?
I already had a look at the source files (esp. mov.c) but I couldn’t find any of the functions inside mov.c being called from the outside (not very experienced programmer here, sorry for that).
Would be cool if someone could give me a short explanation on how this MOV demuxer is placed in the decoding pipeline.
More information about the Libav-user