[FFmpeg-devel] Support MXF separate fields layout with interlaced j2k
matthieu.bouron at gmail.com
Thu Mar 21 13:03:08 CET 2013
On Tue, Mar 19, 2013 at 11:55:40AM +0100, Tomas Härdin wrote:
> On Wed, 2013-02-20 at 17:19 +0100, Matthieu Bouron wrote:
> > On Sat, Feb 16, 2013 at 05:44:49PM +0100, Matthieu Bouron wrote:
> > > On Sat, Feb 16, 2013 at 09:23:05AM -0500, Dave Rice wrote:
> > > > On Feb 16, 2013, at 7:52 AM, Matthieu Bouron <matthieu.bouron at gmail.com> wrote:
> > > >
> > > > In "CDCI Essence Descriptor", if "Interlace or Progressive layout" (0x320C) is 1, then the encoding is field per field rather than frame per frame,
> Be careful here. lavc outputs frames in its MPEG video decoders.
> > so for a natural presentation you'd need to suppose both that:
> > > > - Height is the height of a field, not a frame
> > >
> > > I agree.
> > > > - Frame rate is field rate
> Probably not. It's probably the frame rate as you'd expect. But to be
> entirely sure you'd have to consult S377m and S422m.
The S422M is not clear about this and the two samples differ:
- for ntsc2.mxf -> edit rate = frame rate
- for test-jpeg2000-color-wsound1.mxf -> edit rate = field rate
> > > Is this behaviour described somewhere ?
> > > Following this logic, the file associated with ticket #1102 would play at
> > > 15000/1001 which do not feel natural to me.
> > >
> > > Wild guess: the frame duplication occurs because i did not correct the frame
> > > pts in the decoder.
> > The frame duplication occurs because the decoder outputs one frame every
> > two video packets. The outputed frame takes the pts from the second packet
> > causing ffmpeg to duplicate one frame. A temporary fix is to use -vsync 0.
> > The only ugly solution i see right now (and it seems to work), is to generate
> > the ptses for the interlaced + j2k case so that the pair of video packet
> > needed to reconstruct a given frame would have the same pts.
> > pkt0.pts = 0, pkt1.pts = 0 -> decoded_frame.pkt_pts = 0
> > pkt2.pts = 1, pkt3.pts = 1 -> decoded_frame.pkt_pts = 1
> > ...
> > Better ideas welcomed :)
> Lump both packets together, patch the decoder to output an entire frame?
> After all, this is what mpeg*.c do (if I'm interpreting the code
What do you mean by "lump both packets together" ?
Here is the branch i'm working on:
First, the decoder has been patched to output a entire frame every two video
At this point the remaining problem is to output correct ptses for
each frame. Since the ptses are generated by the demuxer, i needed to:
- divide the stream time base by a factor of 2 since,
- generate packet ptses and set it to field (mxf frame) number to achieve the
pkt0.pts = 0, pkt1.pts = 1 -> decode_frame.pkt_pts = 1
pkt2.pts = 2, pkt3.pts = 3 -> decode_frame.pkt_pts = 3
Since the time_base has been divided by a factor of 2, the ptses are
Last patch add an option (-use_field_rate 0|1), to interpret the edit rate
as field rate.
Reviews and better ideas welcomed :)
More information about the ffmpeg-devel