Hi there,
I just reported an issue I was running into with a DV file in the QuickTime
container last week.
Short recap:
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.
Thanks,
best,
Flo
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
