[Ffmpeg-devel] Interleaving audio and video
Roman Shaposhnik
rvs
Sun Feb 4 07:12:17 CET 2007
Hi
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 ?
Thanks,
Roman.
More information about the ffmpeg-devel
mailing list