[Libav-user] MPEG1-2 CEA-608 CC (subtitle) decoding fails for interlaced content

Carl Eugen Hoyos ceffmpeg at gmail.com
Tue Dec 4 18:10:49 EET 2018


2018-12-04 16:58 GMT+01:00, Eric Jong <ericdejong_nospam10 at gmx.net>:
>> Did you test without the line?
>
> Yes, I did a test without the line for libav 4.0.3 and just now with the
> latest
> snapshot, with and without the line.
> I did not find a good explanation how interlaced content is encoded with
> mpeg-2,
> but from the source I can make the following observations:
>
> Interlaced content consist of an odd field and an even field and these are
> stored
> as seperate frames in the mpeg-stream. The decoder decodes both fields and
> merges
> them directly in the resulting frame. This saves us an extra image
> processing step
> if we would output this frame to an display immediatly. (beside the point,
> we don't,
> we would need to deinterlace these frames first or output it to an encoder
> card as
> interlaced content)
>
> As the original source contained captions, these were added to the fields in
> the
> mpeg stream. As these two fields are merged into a single AVFrame we also
> get two
> sidedata packets of AV_FRAME_DATA_A53_CC. And we need both!
>
> With the line av_frame_remove_side_data: sidedata AV_FRAME_DATA_A53_CC of
> first field
> is discarded.
> Without the line: Each AVFrame contains AV_FRAME_DATA_A53_CC twice.
>
> Please add the patch without av_frame_remove_side_data. And do not consider
> of merging
> the AV_FRAME_DATA_A53_CC sidedata, as this will make analysing these closed
> captions
> more difficult (then which data belonged to which frame)

Interesting, how did you test?
I ask because I don't get anything useful if I don't discard the first
field's data.

Carl Eugen


More information about the Libav-user mailing list