Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-12-02 Thread wm4 
On Fri, 2 Dec 2016 16:15:10 +0800
Jun Zhao  wrote:

> On 2016/12/1 19:03, wm4 wrote:
> > On Wed, 30 Nov 2016 18:25:59 +0100
> > Michael Niedermayer  wrote:
> >   
>  AVFrame had a pan_scan parameter to store one or more croping
>  rectangles.
>  That is now available as side data
> 
>  I remember the intend that this could be used for multiple rectangles
>  of different sizes for example for storing recommanded display
>  rectangles for a 4:3 and a 16:9 display device, but it seems only a
>  single size per frame is supported in the API
> 
>  [...]
> >>>
> >>> This one is very "special" - I don't know if I'd want to further its
> >>> existence. What's it used for at all?
> >>
> >> I only know whats written in the specs, i dont remember having
> >> investigated what real world files do with it, and my knowledge of the
> >> specs is many years old so the spec would be a better place than my
> >> memory of it for further research ...  
> > 
> > If we're going to have a crop rectangle, lots of code (including many
> > video filters) will need to be able to interpret them. Considering
> > this, the pan scan side data is prohibitively complex. Maybe it
> > accurately reflects some standard (mpeg1/2 apparently?), but I'd say
> > it's not simple enough for general use.
> > _  
> 
> I don't think software dec/enc/filter have the crop issue, so I guess
> we just need a general solution for HWAccel dec/enc/hwcontext_xxx_filter.

For software filters, there is the issue that cropping left/right can
make the plane pointers unaligned (e.g. crop 1 pixel -> the pointer is
not aligned to 16 bytes anymore). Which can cause performance issues.
Also, cropping subsampled yuv by non-mod-2 width/height (as jpg
decoding requires it) is really messy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-12-02 Thread Jun Zhao 


On 2016/12/1 19:03, wm4 wrote:
> On Wed, 30 Nov 2016 18:25:59 +0100
> Michael Niedermayer  wrote:
> 
 AVFrame had a pan_scan parameter to store one or more croping
 rectangles.
 That is now available as side data

 I remember the intend that this could be used for multiple rectangles
 of different sizes for example for storing recommanded display
 rectangles for a 4:3 and a 16:9 display device, but it seems only a
 single size per frame is supported in the API

 [...]  
>>>
>>> This one is very "special" - I don't know if I'd want to further its
>>> existence. What's it used for at all?  
>>
>> I only know whats written in the specs, i dont remember having
>> investigated what real world files do with it, and my knowledge of the
>> specs is many years old so the spec would be a better place than my
>> memory of it for further research ...
> 
> If we're going to have a crop rectangle, lots of code (including many
> video filters) will need to be able to interpret them. Considering
> this, the pan scan side data is prohibitively complex. Maybe it
> accurately reflects some standard (mpeg1/2 apparently?), but I'd say
> it's not simple enough for general use.
> _

I don't think software dec/enc/filter have the crop issue, so I guess
we just need a general solution for HWAccel dec/enc/hwcontext_xxx_filter.
 
__
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-12-01 Thread wm4 
On Wed, 30 Nov 2016 18:25:59 +0100
Michael Niedermayer  wrote:

> > > AVFrame had a pan_scan parameter to store one or more croping
> > > rectangles.
> > > That is now available as side data
> > > 
> > > I remember the intend that this could be used for multiple rectangles
> > > of different sizes for example for storing recommanded display
> > > rectangles for a 4:3 and a 16:9 display device, but it seems only a
> > > single size per frame is supported in the API
> > > 
> > > [...]  
> > 
> > This one is very "special" - I don't know if I'd want to further its
> > existence. What's it used for at all?  
> 
> I only know whats written in the specs, i dont remember having
> investigated what real world files do with it, and my knowledge of the
> specs is many years old so the spec would be a better place than my
> memory of it for further research ...

If we're going to have a crop rectangle, lots of code (including many
video filters) will need to be able to interpret them. Considering
this, the pan scan side data is prohibitively complex. Maybe it
accurately reflects some standard (mpeg1/2 apparently?), but I'd say
it's not simple enough for general use.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-30 Thread Michael Niedermayer 
On Wed, Nov 30, 2016 at 04:56:01PM +0100, wm4 wrote:
> On Wed, 30 Nov 2016 16:40:53 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Nov 30, 2016 at 02:18:36PM +0100, wm4 wrote:
> > > On Wed, 30 Nov 2016 11:08:10 +
> > > Mark Thompson  wrote:
> > >   
> > > > On 30/11/16 02:20, Jun Zhao wrote:  
> > > > > From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
> > > > > From: Jun Zhao 
> > > > > Date: Tue, 29 Nov 2016 14:14:25 +0800
> > > > > Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in 
> > > > > vaapi_h26[4,5]
> > > > >
> > > > > add crop information support in vaapi_h26[4,5] hwaccel decode,
> > > > > and align h264/hevc software decoder. After this fix, FATE test
> > > > > h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
> > > > > will pass in i965/SKL.
> > > > >
> > > > > Signed-off-by: Wang, Yi A 
> > > > > Signed-off-by: Jun Zhao 
> > > > > ---
> > > > >  libavcodec/h264dec.c| 13 +
> > > > >  libavcodec/hevc_refs.c  |  7 +++
> > > > >  libavutil/hwcontext.h   |  6 ++
> > > > >  libavutil/hwcontext_vaapi.c |  1 +
> > > > >  4 files changed, 27 insertions(+)
> > > > 
> > > > No.  Top/left cropping needs a more general approach, not hacks in 
> > > > specific decoders/hwcontexts.
> > > > 
> > > > Among other things:
> > > > - The hardware frame context is owned by the user, you can't edit it 
> > > > like this from inside the decoder.
> > > > - It can't be per-frame-context anyway, because multiple streams can be 
> > > > decoded into the same frame context.
> > > > - More components need to be aware of it: the scale filters definitely 
> > > > should be (at 
> > > > ,
> > > >  in VAAPI, similarly for the other hardware APIs).  Other components 
> > > > can probably ignore it (with docs saying you should put it through the 
> > > > relevant scale filter if you want correctly-cropped images), but we 
> > > > should make that decision explicitly.
> > > > - Messing with pointers/sizes on frame upload/download has issues with 
> > > > APIs which can only transfer whole frames - see the comment at 
> > > > .
> > > >   (That was written with VDPAU in mind, there are likely others.)
> > > > 
> > > > As wm4 notes in another reply, this ends up pointing to some sort of 
> > > > cropping information associated with the AVFrame which all interested 
> > > > components can then read.
> > > > 
> > > > I know several people have expressed interest in this problem: given 
> > > > that, it's probably a good idea to have some discussion first and 
> > > > decide roughly what the result should look like before writing a lot of 
> > > > code for it.  
> > > 
> > > I've always argued for having a cropping rectangle directly in AVFrame,
> > > but the idea was never popular.  
> > 
> > AVFrame had a pan_scan parameter to store one or more croping
> > rectangles.
> > That is now available as side data
> > 
> > I remember the intend that this could be used for multiple rectangles
> > of different sizes for example for storing recommanded display
> > rectangles for a 4:3 and a 16:9 display device, but it seems only a
> > single size per frame is supported in the API
> > 
> > [...]
> 
> This one is very "special" - I don't know if I'd want to further its
> existence. What's it used for at all?

I only know whats written in the specs, i dont remember having
investigated what real world files do with it, and my knowledge of the
specs is many years old so the spec would be a better place than my
memory of it for further research ...

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-30 Thread Michael Niedermayer 
On Wed, Nov 30, 2016 at 02:18:36PM +0100, wm4 wrote:
> On Wed, 30 Nov 2016 11:08:10 +
> Mark Thompson  wrote:
> 
> > On 30/11/16 02:20, Jun Zhao wrote:
> > > From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
> > > From: Jun Zhao 
> > > Date: Tue, 29 Nov 2016 14:14:25 +0800
> > > Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in 
> > > vaapi_h26[4,5]
> > >
> > > add crop information support in vaapi_h26[4,5] hwaccel decode,
> > > and align h264/hevc software decoder. After this fix, FATE test
> > > h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
> > > will pass in i965/SKL.
> > >
> > > Signed-off-by: Wang, Yi A 
> > > Signed-off-by: Jun Zhao 
> > > ---
> > >  libavcodec/h264dec.c| 13 +
> > >  libavcodec/hevc_refs.c  |  7 +++
> > >  libavutil/hwcontext.h   |  6 ++
> > >  libavutil/hwcontext_vaapi.c |  1 +
> > >  4 files changed, 27 insertions(+)  
> > 
> > No.  Top/left cropping needs a more general approach, not hacks in specific 
> > decoders/hwcontexts.
> > 
> > Among other things:
> > - The hardware frame context is owned by the user, you can't edit it like 
> > this from inside the decoder.
> > - It can't be per-frame-context anyway, because multiple streams can be 
> > decoded into the same frame context.
> > - More components need to be aware of it: the scale filters definitely 
> > should be (at 
> > ,
> >  in VAAPI, similarly for the other hardware APIs).  Other components can 
> > probably ignore it (with docs saying you should put it through the relevant 
> > scale filter if you want correctly-cropped images), but we should make that 
> > decision explicitly.
> > - Messing with pointers/sizes on frame upload/download has issues with APIs 
> > which can only transfer whole frames - see the comment at 
> > .
> >   (That was written with VDPAU in mind, there are likely others.)
> > 
> > As wm4 notes in another reply, this ends up pointing to some sort of 
> > cropping information associated with the AVFrame which all interested 
> > components can then read.
> > 
> > I know several people have expressed interest in this problem: given that, 
> > it's probably a good idea to have some discussion first and decide roughly 
> > what the result should look like before writing a lot of code for it.
> 
> I've always argued for having a cropping rectangle directly in AVFrame,
> but the idea was never popular.

AVFrame had a pan_scan parameter to store one or more croping
rectangles.
That is now available as side data

I remember the intend that this could be used for multiple rectangles
of different sizes for example for storing recommanded display
rectangles for a 4:3 and a 16:9 display device, but it seems only a
single size per frame is supported in the API

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-30 Thread wm4 
On Wed, 30 Nov 2016 11:08:10 +
Mark Thompson  wrote:

> On 30/11/16 02:20, Jun Zhao wrote:
> > From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
> > From: Jun Zhao 
> > Date: Tue, 29 Nov 2016 14:14:25 +0800
> > Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4,5]
> >
> > add crop information support in vaapi_h26[4,5] hwaccel decode,
> > and align h264/hevc software decoder. After this fix, FATE test
> > h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
> > will pass in i965/SKL.
> >
> > Signed-off-by: Wang, Yi A 
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavcodec/h264dec.c| 13 +
> >  libavcodec/hevc_refs.c  |  7 +++
> >  libavutil/hwcontext.h   |  6 ++
> >  libavutil/hwcontext_vaapi.c |  1 +
> >  4 files changed, 27 insertions(+)  
> 
> No.  Top/left cropping needs a more general approach, not hacks in specific 
> decoders/hwcontexts.
> 
> Among other things:
> - The hardware frame context is owned by the user, you can't edit it like 
> this from inside the decoder.
> - It can't be per-frame-context anyway, because multiple streams can be 
> decoded into the same frame context.
> - More components need to be aware of it: the scale filters definitely should 
> be (at 
> ,
>  in VAAPI, similarly for the other hardware APIs).  Other components can 
> probably ignore it (with docs saying you should put it through the relevant 
> scale filter if you want correctly-cropped images), but we should make that 
> decision explicitly.
> - Messing with pointers/sizes on frame upload/download has issues with APIs 
> which can only transfer whole frames - see the comment at 
> .
>   (That was written with VDPAU in mind, there are likely others.)
> 
> As wm4 notes in another reply, this ends up pointing to some sort of cropping 
> information associated with the AVFrame which all interested components can 
> then read.
> 
> I know several people have expressed interest in this problem: given that, 
> it's probably a good idea to have some discussion first and decide roughly 
> what the result should look like before writing a lot of code for it.

I've always argued for having a cropping rectangle directly in AVFrame,
but the idea was never popular.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-30 Thread Mark Thompson 
On 30/11/16 02:20, Jun Zhao wrote:
> From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 29 Nov 2016 14:14:25 +0800
> Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4,5]
>
> add crop information support in vaapi_h26[4,5] hwaccel decode,
> and align h264/hevc software decoder. After this fix, FATE test
> h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
> will pass in i965/SKL.
>
> Signed-off-by: Wang, Yi A 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/h264dec.c| 13 +
>  libavcodec/hevc_refs.c  |  7 +++
>  libavutil/hwcontext.h   |  6 ++
>  libavutil/hwcontext_vaapi.c |  1 +
>  4 files changed, 27 insertions(+)

No.  Top/left cropping needs a more general approach, not hacks in specific 
decoders/hwcontexts.

Among other things:
- The hardware frame context is owned by the user, you can't edit it like this 
from inside the decoder.
- It can't be per-frame-context anyway, because multiple streams can be decoded 
into the same frame context.
- More components need to be aware of it: the scale filters definitely should 
be (at 
,
 in VAAPI, similarly for the other hardware APIs).  Other components can 
probably ignore it (with docs saying you should put it through the relevant 
scale filter if you want correctly-cropped images), but we should make that 
decision explicitly.
- Messing with pointers/sizes on frame upload/download has issues with APIs 
which can only transfer whole frames - see the comment at 
.
  (That was written with VDPAU in mind, there are likely others.)

As wm4 notes in another reply, this ends up pointing to some sort of cropping 
information associated with the AVFrame which all interested components can 
then read.

I know several people have expressed interest in this problem: given that, it's 
probably a good idea to have some discussion first and decide roughly what the 
result should look like before writing a lot of code for it.

Thanks,

- Mark

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-30 Thread wm4 
On Wed, 30 Nov 2016 10:20:54 +0800
Jun Zhao  wrote:

> From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 29 Nov 2016 14:14:25 +0800
> Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4,5]
> 
> add crop information support in vaapi_h26[4,5] hwaccel decode,
> and align h264/hevc software decoder. After this fix, FATE test
> h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
> will pass in i965/SKL.
> 
> Signed-off-by: Wang, Yi A 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/h264dec.c| 13 +
>  libavcodec/hevc_refs.c  |  7 +++
>  libavutil/hwcontext.h   |  6 ++
>  libavutil/hwcontext_vaapi.c |  1 +
>  4 files changed, 27 insertions(+)
> 
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ed0b724..2e7692c 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -54,6 +54,7 @@
>  #include "rectangle.h"
>  #include "thread.h"
>  #include "vdpau_compat.h"
> +#include "libavutil/hwcontext.h"
>  
>  static int h264_decode_end(AVCodecContext *avctx);
>  
> @@ -1012,6 +1013,18 @@ static int output_frame(H264Context *h, AVFrame *dst, 
> H264Picture *srcp)
>(srcp->crop_top  >> vshift) * dst->linesize[i];
>  dst->data[i] += off;
>  }
> +
> +/* HWAccel always used data[0-3] in avframe */
> +for (i = 0; i < 3; i++) {
> +if (dst->hw_frames_ctx) {
> +int hshift = (i > 0) ? desc->log2_chroma_w : 0;
> +int vshift = (i > 0) ? desc->log2_chroma_h : 0;
> +AVHWFramesContext *ctx = 
> (AVHWFramesContext*)dst->hw_frames_ctx->data;
> +ctx->top_offset[i] = srcp->crop_top  >> vshift;
> +ctx->left_offset[i] = (srcp->crop_left >> hshift) << 
> h->pixel_shift;
> +}
> +}
> +
>  return 0;
>  }
>  
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index 611ad45..a184de2 100644
> --- a/libavcodec/hevc_refs.c
> +++ b/libavcodec/hevc_refs.c
> @@ -28,6 +28,7 @@
>  #include "thread.h"
>  #include "hevc.h"
>  
> +#include "libavutil/hwcontext.h"
>  void ff_hevc_unref_frame(HEVCContext *s, HEVCFrame *frame, int flags)
>  {
>  /* frame->frame can be NULL if context init failed */
> @@ -222,7 +223,13 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, 
> int flush)
>  int off = ((frame->window.left_offset >> hshift) << 
> pixel_shift) +
>(frame->window.top_offset   >> vshift) * 
> dst->linesize[i];
>  dst->data[i] += off;
> +if (out->hw_frames_ctx) {
> +AVHWFramesContext *ctx = 
> (AVHWFramesContext*)out->hw_frames_ctx->data;
> +ctx->top_offset[i] = frame->window.top_offset >> vshift;
> +ctx->left_offset[i] = (frame->window.left_offset >> 
> hshift) << pixel_shift;
> +}
>  }
> +
>  av_log(s->avctx, AV_LOG_DEBUG,
> "Output frame with POC %d.\n", frame->poc);
>  return 1;
> diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
> index 785da09..0d666c3 100644
> --- a/libavutil/hwcontext.h
> +++ b/libavutil/hwcontext.h
> @@ -220,6 +220,12 @@ typedef struct AVHWFramesContext {
>   * Must be set by the user before calling av_hwframe_ctx_init().
>   */
>  int width, height;
> +
> +/**
> + * The top and left offset of the frames
> + */
> +int top_offset[AV_NUM_DATA_POINTERS];
> +int left_offset[AV_NUM_DATA_POINTERS];
>  } AVHWFramesContext;
>  
>  /**
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 6176bdc..fa026cc 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -781,6 +781,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
>  for (i = 0; i < map->image.num_planes; i++) {
>  dst->data[i] = (uint8_t*)address + map->image.offsets[i];
>  dst->linesize[i] = map->image.pitches[i];
> +dst->data[i] += hwfc->top_offset[i] * dst->linesize[i] + 
> hwfc->left_offset[i];
>  }
>  if (
>  #ifdef VA_FOURCC_YV16

That's an interesting approach. I don't mind this being pushed, but in
the end I think it would be better to have proper crop info in AVFrame
(this would also get rid of annoyances like unaligned data pointers
with software decoded frames).

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4, 5]

2016-11-29 Thread Jun Zhao 
From 20bedd18213420c77d5e8a26fbe741d8d204ac10 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 29 Nov 2016 14:14:25 +0800
Subject: [PATCH] lavc/vaapi_h26[45]: add crop info support in vaapi_h26[4,5]

add crop information support in vaapi_h26[4,5] hwaccel decode,
and align h264/hevc software decoder. After this fix, FATE test
h264-conformance-cvfc1_sony_c/hevc-conformance-CONFWIN_A_Sony_1
will pass in i965/SKL.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/h264dec.c| 13 +
 libavcodec/hevc_refs.c  |  7 +++
 libavutil/hwcontext.h   |  6 ++
 libavutil/hwcontext_vaapi.c |  1 +
 4 files changed, 27 insertions(+)

diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index ed0b724..2e7692c 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -54,6 +54,7 @@
 #include "rectangle.h"
 #include "thread.h"
 #include "vdpau_compat.h"
+#include "libavutil/hwcontext.h"
 
 static int h264_decode_end(AVCodecContext *avctx);
 
@@ -1012,6 +1013,18 @@ static int output_frame(H264Context *h, AVFrame *dst, 
H264Picture *srcp)
   (srcp->crop_top  >> vshift) * dst->linesize[i];
 dst->data[i] += off;
 }
+
+/* HWAccel always used data[0-3] in avframe */
+for (i = 0; i < 3; i++) {
+if (dst->hw_frames_ctx) {
+int hshift = (i > 0) ? desc->log2_chroma_w : 0;
+int vshift = (i > 0) ? desc->log2_chroma_h : 0;
+AVHWFramesContext *ctx = 
(AVHWFramesContext*)dst->hw_frames_ctx->data;
+ctx->top_offset[i] = srcp->crop_top  >> vshift;
+ctx->left_offset[i] = (srcp->crop_left >> hshift) << 
h->pixel_shift;
+}
+}
+
 return 0;
 }
 
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 611ad45..a184de2 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -28,6 +28,7 @@
 #include "thread.h"
 #include "hevc.h"
 
+#include "libavutil/hwcontext.h"
 void ff_hevc_unref_frame(HEVCContext *s, HEVCFrame *frame, int flags)
 {
 /* frame->frame can be NULL if context init failed */
@@ -222,7 +223,13 @@ int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int 
flush)
 int off = ((frame->window.left_offset >> hshift) << 
pixel_shift) +
   (frame->window.top_offset   >> vshift) * 
dst->linesize[i];
 dst->data[i] += off;
+if (out->hw_frames_ctx) {
+AVHWFramesContext *ctx = 
(AVHWFramesContext*)out->hw_frames_ctx->data;
+ctx->top_offset[i] = frame->window.top_offset >> vshift;
+ctx->left_offset[i] = (frame->window.left_offset >> 
hshift) << pixel_shift;
+}
 }
+
 av_log(s->avctx, AV_LOG_DEBUG,
"Output frame with POC %d.\n", frame->poc);
 return 1;
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index 785da09..0d666c3 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -220,6 +220,12 @@ typedef struct AVHWFramesContext {
  * Must be set by the user before calling av_hwframe_ctx_init().
  */
 int width, height;
+
+/**
+ * The top and left offset of the frames
+ */
+int top_offset[AV_NUM_DATA_POINTERS];
+int left_offset[AV_NUM_DATA_POINTERS];
 } AVHWFramesContext;
 
 /**
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6176bdc..fa026cc 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -781,6 +781,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
 for (i = 0; i < map->image.num_planes; i++) {
 dst->data[i] = (uint8_t*)address + map->image.offsets[i];
 dst->linesize[i] = map->image.pitches[i];
+dst->data[i] += hwfc->top_offset[i] * dst->linesize[i] + 
hwfc->left_offset[i];
 }
 if (
 #ifdef VA_FOURCC_YV16
-- 
2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel