[Bug 694068] h264parser: Parse the cropping-rectangle separately.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=694068
  GStreamer | gst-plugins-bad | git

--- Comment #6 from Gwenole Beauchesne <gb.devel at gmail.com> 2013-07-08 14:21:42 UTC ---
Hi sree,

(In reply to comment #4)
> (In reply to comment #3)
> > Review of attachment 236561 [details] [details]:
> > 
> > This will need a change in h264parse if I understand correctly, as h264parse
> > currently uses sps->width/height for the caps. Instead it should now use the
> > cropped width/height.
> > 
> > Otherwise looks good to me, will push after the corresponding h264parse change.
> 
> The patch is setting the un_cropped values to sps->width/sps->height. We are
> supposed to set the cropping values as videometa (instead of setting the
> cropped values to caps) since it is the duty of renderer to deal with cropping.
> right?

Do you have the patch for slomo's request? I think we should at least maintain
the current semantics to get this patch committed and continue discussions for
what h264parse should use. :)

At least, we should get the video parsers behave consistently. e.g. if
mpegvideoparse is using sequence_display_extension to arrange the caps, if this
is smaller than the size reported in sequence header, then for h264parse we
probably should adjust the caps based on the frame cropping info.

In any case, your current patch already addresses two issues:
- this really fills in sps->frame_cropping_flag as we ought to ;
- we can determine the cropping rectangle that was parsed.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.