[FFmpeg-devel] Support MXF separate fields layout with interlaced j2k

[Matthieu Bouron]

On Thu, Mar 21, 2013 at 1:03 PM, Matthieu Bouron
<matthieu.bouron at gmail.com> wrote:
> 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.
>>
>> Correct.
>>
>> > > > - 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
>> correctly).
>>
>
> What do you mean by "lump both packets together" ?
> Here is the branch i'm working on:
> https://github.com/mbouron/FFmpeg/tree/mxfdec_j2ki
>
> First, the decoder has been patched to output a entire frame every two video
> packets.
>
> 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
>     following result:
>
> 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
> correct.
>
> Last patch add an option (-use_field_rate 0|1), to interpret the edit rate
> as field rate.
>
> Reviews and better ideas welcomed :)

Hello,

New patchset send to ml:
libopenjpegdec now uses avctx->extradata instead of avctx->field_order.
avctx->extradata[0] enables interlaced layout,
avctx->extradata[1] stores which field is coded first.
the decoder can't depend on avctx->field_order because of the mxf
segmented layout case (progressive).
libopenjpegdec does not set picture->interlaced_frame and
picture->top_field_first flags anymore.

On the mxf part, the option -use_field_rate (0|1) is renamed to
-field_rate (0|1).
This option is necessary since the SMPTE 422M is unclear about how the
sample rate should be interpreted.
The problem is well described here (page 5):
http://www.digitizationguidelines.gov/guidelines/FADGI_MXF_ASAP_Issues_20110815.pdf

Please comment :)

Best regards,
Matthieu