[FFmpeg-devel] [PATCH] h264: expose stereo_mode from h264 frame?packing info

Michael Niedermayer michaelni at gmx.at
Thu Jun 27 13:31:49 CEST 2013


On Thu, Jun 27, 2013 at 10:50:25AM +0000, Joakim Plate wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> 
> > 
> > >  <at>  <at>  -5033,6 +5036,9  <at>  <at>  static const AVProfile 
> profiles[] = {
> > >  static const AVOption h264_options[] = {
> > >      {"is_avc", "is avc", offsetof(H264Context, is_avc), 
> FF_OPT_TYPE_INT, {.i64 = 0}, 0, 1, 0},
> > >      {"nal_length_size", "nal_length_size", offsetof(H264Context, 
> nal_length_size),
> > FF_OPT_TYPE_INT, {.i64 = 0}, 0, 4, 0},
> > > +    {"frame_packing_arrangement_cancel_flag", 
> "frame_packing_arrangement_cancel_flag",
> > offsetof(H264Context, sei_fpa.frame_packing_arrangement_cancel_flag), 
> FF_OPT_TYPE_INT, {.i64
> > = -1}, -1, 1, 0},
> > > +    {"frame_packing_arrangement_type", 
> "frame_packing_arrangement_type", offsetof(H264Context,
> > sei_fpa.frame_packing_arrangement_type), FF_OPT_TYPE_INT, {.i64 = 0}, 0, 
> 6, 0},
> > > +    {"content_interpretation_type", "content_interpretation_type", 
> offsetof(H264Context,
> > sei_fpa.content_interpretation_type), FF_OPT_TYPE_INT, {.i64 = 0}, 0, 2, 
> 0},
> > >      {NULL}
> > >  };
> > 
> > how do these interact with frame threads ?
> > (as they are not strictly global options and could change per frame)
> 
> I'm not fully sure. To be honest. I couldn't really follow the thread logic 
> when it came to the H264Context, it seem to be duplicated and copied around. 
> Maybe the sei_fpa struct need to be copied around too.
> 
> > also exporting the cancel flag seems quite low level, isnt exporting
> > the current state enough ?
> 
> To be honest, I wasn't really sure if there was a point in exporting these 
> options externally at all. The cancel flag is needed however, since 3d mode 
> can end at any point in the stream and start again. 
> 
> The frame_packing_arrangement_type in the spec does include a 2D mode, but 
> that explicitly states it's only valid to use under certain situations. Thus
> it felt wrong to force this value to the 2d mode if we detect a 
> cancellation.

> 
> If the export of this data in matroska string format in metadata is okey, I 
> would say we should just drop these internal flags.

its fine with me but iam not a user of this stuff


> 
> > 
> > > +    skip_bits(&h->gb, 8*size - (bits - get_bits_left(&h->gb)));
> > 
> > skip_bits_long()
> > 
> 
> Ok.
> 
> Regarding that. To me it sort of feels that logic should be outside this 
> function to benefit all the sei parsers. Now if one of the sei parsers fail, 
> we fail the whole sei parsing completely.

agree, this should be improved

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130627/29f64040/attachment.asc>


More information about the ffmpeg-devel mailing list