[Ffmpeg-devel] Interleaving audio and video

Roman Shaposhnik rvs
Sun Feb 4 07:12:17 CET 2007


On Fri, 2007-02-02 at 13:34 +0100, Michael Niedermayer wrote:
> hmm, that must have been a missunderstanding, sorry, anyway i see no
> serious problem with using interleave_packet() to chopup and merge PCM
> packets its just not designed for that

  I think there's a problem if the right kind of chopping makes a
difference as far as standard compliance of the generated stream
is concerned. Wouldn't you agree ? 

> > That should be also perfect for other formats, there is no framer for
> > pcm atm, what do you suggests ?
> > 
> > Add option to ffmpeg.c ? Set enc->frame_size to 1920 or so, though that
> > will perturb mov muxer for example which expect frame_size to 1 for pcm.
> if mxf/gxf are the only containers havig such odd limitations then the code
> to deal with it should be in them (its already there i assume and so its
> the least work and seems simplest)

  DV is even worse. Its actually funny that these muxers seem to be the
only serious  users of Fifos because they have to keep [re]packetizing
at muxer level which leads to code duplication.

> also keep in mind that in reality audio and video come from different
> hardware and their sampling intervals are not synchronized so the idea
> of X audio samples per video sample is broken by design, its not a
> problem in reality as audio can be resampled video frames can be droped
> or duplicated but if your goal is good quality then such a limitation is
> unaccpetable, iam really curious why formats like that are being designed
> while much simpler, more advanced and less retarded formats already 
> exist

  DV is more flexible in that regard. In non-locked mode the clocks are
allowed to drift a bit. But I'm not surprised that GXF/MXF have the
same kind of requirements as far as audio goes as DV does. After all
the 3 of them are supposed to be easy for heavy editing. And once
you start edit and splice -- I think locked audio with a fixed # of
audio frames per fixed # of video frames actually makes sense.
Wouldn't you agree ?


More information about the ffmpeg-devel mailing list