On Wed, Mar 20, 2013 at 5:26 PM, Janne Grunau <[email protected]>wrote:
> On 2013-03-12 12:48:36 +0100, Anton Khirnov wrote:
>
> > + (h->sps.crop_top +
> h->sps.crop_bottom);
>
> I guess it would make more sense to do the calculations during sps
> parsing and specify h->sps.crop_* in luma pixels.
>
I'm not sure about this, maybe the application needs to read this data
"raw".
How about adding two H264Context private real_width and real_height were
the right size is specified in luma samples?
> > - if (FFALIGN(h->avctx->width, 16) == h->width &&
> > - FFALIGN(h->avctx->height, 16) == h->height) {
> > - h->width = h->avctx->width;
> > - h->height = h->avctx->height;
> > - }
>
> removing this breaks the workaround added in
> 30f515091c323da59c0f1b533703dedca2f4b95d said canon samples have no
> cropping info in the sps
>
Slightly unrelated, but what happens if the sps cropping and the container
cropping do not match?
Is this specified anywhere?
Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
