[FFmpeg-devel] [PATCH 1/2] mxfenc: factorize samples per frame code

Tomas Härdin tomas.hardin at codemill.se
Mon Sep 17 11:14:49 CEST 2012


On Thu, 2012-09-13 at 11:09 +0100, Kieran Kunhya wrote:
> On Thu, Sep 13, 2012 at 12:52 AM, Ben Jackson <ben at ben.com> wrote:
> > On Thu, Sep 13, 2012 at 01:22:02AM +0200, Matthieu Bouron wrote:
> >> On Thu, Sep 13, 2012 at 1:09 AM, Kieran Kunhya <kierank at ob-encoder.com>wrote:
> >>
> >> > > +    { { 1001, 60000 }, { 801,  801,  801,  801,  800,  0 } }, // NTSC
> >> > 59.94
> >> >
> >> > I thought the pattern was:
> >> > {  801,  800,  801,  801,  801 }
> >> >
> >> > I've never found a spec for this though - found it in a document
> >> > somewhere so you might be right.
> >
> > The particular cadence doesn't matter.  It just needs to average 800.8
> > over 10 fields.  At a frame level it typically does not diverge beyond
> > 1600 to 1602 (although obviously 1601 and 1602 are all that are strictly
> > necessary).
> >
> > I might be able to dig up the relevant SMPTE spec but it's not so specific
> > as to give a pattern.
> 
> It's more of a question as to whether tools on the market will
> complain/crash/cause the apocalypse unless you use a pattern that it
> likes.

The pattern is important for sample accurate seeking - see "[PATCH]
mxfdec: set audio packet pts". This reminds me: this table needs to be
shared between muxer and demuxer so lavf works with itself. That can be
done in a later patch though.

> +typedef struct {
> +    struct AVRational time_base;
> +    int samples_per_frame[6];
> +} MXFSamplesPerFrame;
> +
> +static const MXFSamplesPerFrame mxf_samples_per_frames[] = {
> 
Not very important, but you could save a few lines by not naming the
struct:

> +static const struct {
> +    struct AVRational time_base;
> +    int samples_per_frame[6];
> +} mxf_samples_per_frames[] = {

The patch looks OK though.

/Tomas



More information about the ffmpeg-devel mailing list