[FFmpeg-devel] [PATCH v3 3/7] avcodec/mediacodecenc: use bsf to handle crop

[Tomas Härdin]

ons 2022-12-21 klockan 15:17 +0800 skrev zhilizhao(赵志立):
> 
> 
> > On Dec 21, 2022, at 02:24, Tomas Härdin <git at haerdin.se> wrote:
> > 
> > tor 2022-12-15 klockan 01:37 +0800 skrev Zhao Zhili:
> > > On Wed, 2022-12-14 at 18:08 +0100, Tomas Härdin wrote:
> > > 
> > > > 
> > > > I think we might want something for this inside lavf somewhere,
> > > > so
> > > > that
> > > > encoders can signal dimension alignment requirements. Some
> > > > containers
> > > > (MXF, MOV) support such cropping in a codec-agnostic manner.
> > > 
> > > From my own experience, dimension mismatch between codec and
> > > container
> > > makes a lot of trouble. ISO base format specification specified
> > > how
> > > to
> > > crop/scale after decoding clear, however, I don't think it has
> > > been
> > > widely supported, including FFmpeg. We can fix that inside of
> > > FFmpeg,
> > > but we should avoid such cases as much as we can.
> > 
> > This is the difference between stored, sampled and display
> > dimensions
> > in MXF. For example 1080i video has StoredHeight = 544,
> > SampledHeight =
> > 540 and DisplayHeight = 540 (see AS-10). When you add VBLANK and
> > HBLANK
> > to the mix then all three dimensions are typically different.
> > 
> > Anyway specifying at the NAL level whenever the essence isn't a
> > multiple of 16x16 is obviously normal. The only complication I can
> > think of is 4:2:2 and 4:4:4. Does MC require 16x16 also in those
> > cases?
> > I'd expect 16x8 and 8x8 respectively.
> 
> It’s still 16x16. From H.264 specification:

I stand corrected. I did give the spec a once-over a while back, but
not everything sticks.

/Tomas