On Fri, 2011-09-30 at 01:15 -0700, Alex Converse wrote:
> On Fri, Sep 30, 2011 at 12:19 AM, Tomas Härdin <tomas.har...@codemill.se> 
> wrote:
> > On Thu, 2011-09-29 at 13:44 -0700, Alex Converse wrote:
> >> This should result in more idiomatic output that is less confusing to
> >> marginal implementations.
> >> ---
> >>  libavformat/movenc.c |   16 ++++++++++++++--
> >>  1 files changed, 14 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> >> index b79bbe8..066dae0 100644
> >> --- a/libavformat/movenc.c
> >> +++ b/libavformat/movenc.c
> >> @@ -381,6 +381,18 @@ static int mov_write_glbl_tag(AVIOContext *pb, 
> >> MOVTrack *track)
> >>      return 8+track->vosLen;
> >>  }
> >>
> >> +static int mov_write_extradata(AVIOContext *pb, MOVTrack *track)
> >> +{
> >> +    if (track->vosLen >= 8 &&
> >> +        AV_RB32(track->vosData+4) == MKBETAG('f','i','e','l')) {
> >
> > Check codec_id == CODEC_ID_MJPEG instead? See commit e571305 to mov.c in
> > FFmpeg ("mov: Only touch extradata in mov_read_extradata() if codec_id
> > is what we expect").
> > I haven't gotten around to rebasing and posting that here yet since I'm
> > still bouncing ideas for mov/mxfdec off Baptiste.
> >
> 
> The more I think about the more the logical conclusion seems to be
> that 'fiel' data shouldn't be treated as extradata at all but instead
> should be decoded into the avcodec context.

At work we added an "int interlacing;" field to AVCodecContext. It's
only set by a few decoders though (no demuxer sets it), and doesn't
provide field order information.
To support field order, "interlacing" could have the value of 0/1/2
(progressive, TFF, BFF) or a separate field could be used (like AVFrame
does). Do those sound like decent ideas?

> It really doesn't make
> sense to dump a raw fiel atom into another container when remuxing
> mjpeg (or prores), not to mention it conflicts with AVC Intra and
> other interlaced formats that also have extradata.

There's also the fact that FCP requires the fiel atom in a variety of
cases, including AVC-Intra and XDCAM.

/Tomas

_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to