On Sun, 18 Dec 2016 22:02:08 +0100
Hendrik Leppkes <[email protected]> wrote:

> On Sun, Dec 18, 2016 at 9:52 PM, wm4 <[email protected]> wrote:
> > On Sun, 18 Dec 2016 21:37:44 +0100
> > Hendrik Leppkes <[email protected]> wrote:
> >  
> >> On Sun, Dec 18, 2016 at 9:27 PM, Anton Khirnov <[email protected]> wrote:  
> >> > ---
> >> >  doc/APIchanges      |  4 ++++
> >> >  libavutil/frame.c   |  2 ++
> >> >  libavutil/frame.h   | 14 ++++++++++++++
> >> >  libavutil/version.h |  2 +-
> >> >  4 files changed, 21 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/doc/APIchanges b/doc/APIchanges
> >> > index 7633c99..ca95308 100644
> >> > --- a/doc/APIchanges
> >> > +++ b/doc/APIchanges
> >> > @@ -13,6 +13,10 @@ libavutil:     2015-08-28
> >> >
> >> >  API changes, most recent first:
> >> >
> >> > +2016-xx-xx - xxxxxxx - lavu 55.30.0 - frame.h
> >> > +  Add AVFrame.crop_left/crop_top fields for attaching cropping 
> >> > information to
> >> > +  video frames.
> >> > +
> >> >  2016-xx-xx - xxxxxxx - lavc 57.29.0 - avcodec.h
> >> >    Add AV_PKT_DATA_SPHERICAL packet side data to export 
> >> > AVSphericalMapping
> >> >    information from containers.
> >> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> >> > index 1c14f5f..935c281 100644
> >> > --- a/libavutil/frame.c
> >> > +++ b/libavutil/frame.c
> >> > @@ -390,6 +390,8 @@ int av_frame_copy_props(AVFrame *dst, const AVFrame 
> >> > *src)
> >> >      dst->key_frame              = src->key_frame;
> >> >      dst->pict_type              = src->pict_type;
> >> >      dst->sample_aspect_ratio    = src->sample_aspect_ratio;
> >> > +    dst->crop_left              = src->crop_left;
> >> > +    dst->crop_top               = src->crop_top;
> >> >      dst->pts                    = src->pts;
> >> >      dst->repeat_pict            = src->repeat_pict;
> >> >      dst->interlaced_frame       = src->interlaced_frame;
> >> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> >> > index 4052199..744d8d2 100644
> >> > --- a/libavutil/frame.h
> >> > +++ b/libavutil/frame.h
> >> > @@ -25,6 +25,7 @@
> >> >  #ifndef AVUTIL_FRAME_H
> >> >  #define AVUTIL_FRAME_H
> >> >
> >> > +#include <stddef.h>
> >> >  #include <stdint.h>
> >> >
> >> >  #include "avutil.h"
> >> > @@ -369,6 +370,19 @@ typedef struct AVFrame {
> >> >       * AVHWFramesContext describing the frame.
> >> >       */
> >> >      AVBufferRef *hw_frames_ctx;
> >> > +
> >> > +    /**
> >> > +     * Video frames only.
> >> > +     * The number of pixels to discard from the left border of the 
> >> > frame to
> >> > +     * obtain the part of the frame intended for presentation.
> >> > +     */
> >> > +    size_t crop_left;
> >> > +    /**
> >> > +     * Video frames only.
> >> > +     * The number of pixels to discard from the top border of the frame 
> >> > to
> >> > +     * obtain the part of the frame intended for presentation.
> >> > +     */
> >> > +    size_t crop_top;  
> >>
> >> If you start exporting cropping info, it should imho be a full rect,
> >> so you can eg. export 1px crop for 4:2:0 formats and whatnot, and not
> >> be limited to one  specific use-case.
> >> Also, then it should be put into a struct and not 4 individual values.  
> >
> > We already support odd cropping of 4:2:0 frames. Try decoding a jpg
> > with odd dimensions.  
> 
> By using technically invalid dimensions and hoping chroma dimensions
> are rounded up - its anything but clean.

Well, it's sort of well-defined: allocation is always done in a way
that you can assume there's an extra luma line/column if the dimensions
are odd.

But yeah, it's not exactly clean. Putting the uncropped dimensions into
the width/height field, and doing bottom/right cropping with separate
fields would be cleaner.

> I would rather have a full cropping rect and have a clean way to
> communicate this, with w/h (optionally) unmolested.

I agree.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to