On Mon, Jun 8, 2020 at 7:19 AM Tobias Rapp <t.r...@noa-archive.com> wrote:
> On 30.05.2020 12:41, Kieran O Leary wrote:
> > Hi,
> >
> > On Fri 29 May 2020, 22:47 Neil Birkbeck, <neil.birkb...@gmail.com>
> wrote:
> >
> >> [...]
> >> I've changed the side data to be PixelCrop (instead of CleanAperture)
> given
> >> the intent to reuse as cropping elsewhere.
> >> -For now, I've kept the rational representation--although CLAP seems to
> be
> >> the only required case of it. Maybe Kieran could comment on the
> requirement
> >> of having maintaining the rationals for CLAP (only works on mov to mov
> >> transmuxing).
> >>
> > I'm no expert, but I think a lot of this just comes from video standards
> > that stipulate those rational numbers? I've cc'd tobias Rapp and
> Christoph
> > Gerstbauer of NOA just to bring this to their attention, as I'm pretty
> sure
> > that they use cropping values in AVI, so perhaps all of this could be
> > useful to them in some way.
> >
>
> Hi Kieran,
>
> when digitizing SD video carriers we indeed store some offset
> information in case VBI is preverved (i.e. PAL 720x608). But these
> offset values are currently not stored in the AVI container itself. The
> OpenDML "vprp" chunk defines some offset values but for the purpose of
> compressed image data where the codec implies some multiple-of-N
> height/width dimension on the data. So it did not seem to match our
> use-case.
>
> Besides AVI and the mentioned MKV and MOV formats I remember some
> display offset/cropping information being stored in MXF with the Display
> X/Y-Offset values.
>
> Regardless whether the frame crop/offset values are stored as frame
> fields or side data: how would this information be affected by filters
> like "crop" or "scale"?
>
Thanks for the additional info, Kieran and Tobias.
AVFrame already has cropping fields (AVFrame::crop_{top, bottom, left,
right}), and James Almer's suggestion was that this representation could
replace those. At the moment, when AVCodecContext::apply_cropping is true,
these offsets get applied (and zerod) in libavcodec/decode.c. Currently,
vf_crop adjusts these offsets for HWACCEL pix fmts, and vf_scale_vulkan
also respects (vf_scale doesn't).
Any additional reviewer thoughts on the SideData representation (e.g., crop
fields, currently rational to fully support the mov mux case)?
_______________________________________________
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".
