[Bug 683142] h264parse: should proxy demuxer width+height (incorrectly reports Canon MOV resolution as 1920x1088 instead of 1920x1080)

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #7 from Sebastian Dröge <slomo at circular-chaos.org> 2012-12-17 09:11:18 UTC ---
(In reply to comment #6)
> IMHO,
> 
>  - sanity checking upstream width/height is "nice", but not really
> super-important

I wouldn't be surprised if we can produce crashes downstream if a larger
width/height than actually present is given in the caps

>  - decoders *should* take the provided upstream size and crop (there's a bug
> about that I think)

Yes, where I gave the same argument ;)

>  - the commit is needed either way, even if we add crop metadata as well,
> because:
> 
>  - the width/height in the caps should always reflect the effective
> width/height after cropping. This is the case with videocrop even when using
> crop meta (hopefully!), and should be the case here as well.

Correct, but the reason why I don't think that just changing the width/height
is a good idea is that it's ambigious. With the crop metadata you know which
x/y offset and which width/height should be used, with only a different
width/height in the caps you don't know anything about that.


I guess something similar to the libav change could be allowed though. Just
allowing a width/height that is smaller and that would result in the same
number of macro blocks.

-- 
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.