ons 2022-12-21 klockan 15:17 +0800 skrev zhilizhao(赵志立): > > > > On Dec 21, 2022, at 02:24, Tomas Härdin <g...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
