On 2013-03-22 09:04:36 +0100, Vittorio Giovara wrote:
> 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".
which application? That is decoder private data structure
> How about adding two H264Context private real_width and real_height were
> the right size is specified in luma samples?
I'm missing how that's gonna help
> > > - 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?
The container cropping takes preference if the sps crops to macro block
border and the container cropping is less than one macro block to that
dimensions, i.e. impossible to hit on sane samples. I wouldn't mind
cropping to pre set avctx width/height only if frame_cropping_flag == 0
in the sps.
> Is this specified anywhere?
No, just a workaround for samples from a well known and unfortunately
well spread source (1080 video recordings from canon dslr cameras)
Janne
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
