Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-21 Thread Michael Niedermayer
On Mon, Nov 20, 2017 at 08:10:36PM -0800, Philip Langdale wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 20 Nov 2017 22:53:00 +0100
> Michael Niedermayer  wrote:
> 
> > On Sun, Nov 19, 2017 at 11:52:28AM -0800, Philip Langdale wrote:
> > > This was predictably nightmarish, given how ridiculous mpeg4 is.
> > > I had to stare at the cuvid parser output for a long time to work
> > > out what each field was supposed to be, and even then, I still don't
> > > fully understand some of them, particularly:
> > > 
> > > vop_coded: I think this means whether the vop has a picture shape,
> > >and therefore a picture type. I have no samples where
> > >this is not the case.
> > > divx_flags: There's obviously no documentation on what the possible
> > > flags are. I simply observed that this is '0' for a
> > > normal bitstream and '5' for packed b-frames.  
> > 
> > > gmc_enabled: This seems to map to mc_sel being non-zero, but I also
> > >  have no samples where that is true.  
> > 
> > issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
> > seems to use gmc, didnt check how compex or trivial its use is
> > 
> > [...]
> 
> I think it's as complex as you can get, and the nvidia decoder cannot
> handle it properly. With vdpau, cuvid and now nvdec, there are a lot of
> visual glitches. Interestingly, the resutls with nvdec are better than
> cuvid, so not using the nvidia parser somehow makes things less worse.
> 
> I'd love to try a single warp point sample but can't find or generate
> one.

Heres one with 2 wrap points:
~/tickets/1180/GoneNutty.avi

you can find a 1 point gmc with, iam sure we had such samples but it
seems i couldnt quickly find one

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 69f455e226..e0c904707e 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -1883,6 +1883,10 @@ static int decode_vol_header(Mpeg4DecContext *ctx, 
GetBitContext *gb)
 check_marker(s->avctx, gb, "after sprite_top");
 }
 ctx->num_sprite_warping_points = get_bits(gb, 6);
+if (ctx->num_sprite_warping_points!=3 && 
ctx->num_sprite_warping_points!=2 && ctx->num_sprite_warping_points){
+av_log(0,0, "XXX %d\n", ctx->num_sprite_warping_points);
+abort();
+}
 if (ctx->num_sprite_warping_points > 3) {
 av_log(s->avctx, AV_LOG_ERROR,
"%d sprite_warping_points\n",

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-20 Thread Philip Langdale
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 20 Nov 2017 22:53:00 +0100
Michael Niedermayer  wrote:

> On Sun, Nov 19, 2017 at 11:52:28AM -0800, Philip Langdale wrote:
> > This was predictably nightmarish, given how ridiculous mpeg4 is.
> > I had to stare at the cuvid parser output for a long time to work
> > out what each field was supposed to be, and even then, I still don't
> > fully understand some of them, particularly:
> > 
> > vop_coded: I think this means whether the vop has a picture shape,
> >and therefore a picture type. I have no samples where
> >this is not the case.
> > divx_flags: There's obviously no documentation on what the possible
> > flags are. I simply observed that this is '0' for a
> > normal bitstream and '5' for packed b-frames.  
> 
> > gmc_enabled: This seems to map to mc_sel being non-zero, but I also
> >  have no samples where that is true.  
> 
> issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
> seems to use gmc, didnt check how compex or trivial its use is
> 
> [...]

I think it's as complex as you can get, and the nvidia decoder cannot
handle it properly. With vdpau, cuvid and now nvdec, there are a lot of
visual glitches. Interestingly, the resutls with nvdec are better than
cuvid, so not using the nvidia parser somehow makes things less worse.

I'd love to try a single warp point sample but can't find or generate
one.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAloTpz0ACgkQ+NaxlGp1aC5ZgQCaA4FpVgJq6YKS6TkbHxiLque7
6pIAn1kL80I16yvLVZAFSw27Opcw0/tn
=UqY9
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-20 Thread Michael Niedermayer
On Sun, Nov 19, 2017 at 11:52:28AM -0800, Philip Langdale wrote:
> This was predictably nightmarish, given how ridiculous mpeg4 is.
> I had to stare at the cuvid parser output for a long time to work
> out what each field was supposed to be, and even then, I still don't
> fully understand some of them, particularly:
> 
> vop_coded: I think this means whether the vop has a picture shape,
>and therefore a picture type. I have no samples where
>this is not the case.
> divx_flags: There's obviously no documentation on what the possible
> flags are. I simply observed that this is '0' for a
> normal bitstream and '5' for packed b-frames.

> gmc_enabled: This seems to map to mc_sel being non-zero, but I also
>  have no samples where that is true.

issues/388/Matrix.Reloaded.Trailer-640x346-XviD-1.0beta2-HE_AAC_subtitled.mkv
seems to use gmc, didnt check how compex or trivial its use is

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-20 Thread Philip Langdale
On Mon, 20 Nov 2017 10:59:52 +0100
Timo Rothenpieler  wrote:

> > Duplicate. Will remove.  
> 
> Can't really tell if the parameters are in any way correct, but I
> guess time will tell if some sample comes up that breaks it.
> 
> lgtm with that duplicate removed
> 

Thanks. I've pushed all three. I learned a bit more about a couple of
the mpeg4 flags and made small updates in the pushed version.

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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-20 Thread Timo Rothenpieler

Duplicate. Will remove.


Can't really tell if the parameters are in any way correct, but I guess 
time will tell if some sample comes up that breaks it.


lgtm with that duplicate removed



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-19 Thread Carl Eugen Hoyos
2017-11-19 23:35 GMT+01:00 Carl Eugen Hoyos :
> 2017-11-19 20:52 GMT+01:00 Philip Langdale :
>
>> gmc_enabled: This seems to map to mc_sel being non-zero, but I also
>>  have no samples where that is true.
>
> Iirc, global motion compensation is not supported by hardware decoders.

Or maybe it only works if there is no more than one warppoint.

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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-19 Thread Philip Langdale
On Sun, 19 Nov 2017 11:52:28 -0800
Philip Langdale  wrote:

> This was predictably nightmarish, given how ridiculous mpeg4 is.
> I had to stare at the cuvid parser output for a long time to work
> out what each field was supposed to be, and even then, I still don't
> fully understand some of them, particularly:
> 
> vop_coded: I think this means whether the vop has a picture shape,
>and therefore a picture type. I have no samples where
>this is not the case.
> divx_flags: There's obviously no documentation on what the possible
> flags are. I simply observed that this is '0' for a
> normal bitstream and '5' for packed b-frames.
> gmc_enabled: This seems to map to mc_sel being non-zero, but I also
>  have no samples where that is true.
> 
> Also note that as with the vdpau hwaccel, the decoder needs to
> consume the entire frame and not the slice.
> 
> Signed-off-by: Philip Langdale 
> ---
>  Changelog|   2 +-
>  configure|   2 +
>  libavcodec/Makefile  |   1 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/h263dec.c |   3 ++
>  libavcodec/nvdec.c   |   1 +
>  libavcodec/nvdec_mpeg4.c | 121
> +++
> libavcodec/version.h |   2 +- 8 files changed, 131 insertions(+),
> 2 deletions(-) create mode 100644 libavcodec/nvdec_mpeg4.c
> 
> diff --git a/Changelog b/Changelog
> index 5a9d183aed..74ed35cfe6 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -13,7 +13,7 @@ version :
>  - PCE support for extended channel layouts in the AAC encoder
>  - native aptX encoder and decoder
>  - Raw aptX muxer and demuxer
> -- NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2, VC1 and VP9
> hwaccel decoding +- NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2/4,
> VC1 and VP9 hwaccel decoding
>  - Intel QSV-accelerated overlay filter
>  - mcompand audio filter
>  - acontrast audio filter
> diff --git a/configure b/configure
> index 35713805fa..36ccf767dd 100755
> --- a/configure
> +++ b/configure
> @@ -2731,6 +2731,8 @@ mpeg2_xvmc_hwaccel_select="mpeg2video_decoder"
>  mpeg4_cuvid_hwaccel_select="mpeg4_cuvid_decoder"
>  mpeg4_mediacodec_hwaccel_deps="mediacodec"
>  mpeg4_mmal_hwaccel_deps="mmal"
> +mpeg4_nvdec_hwaccel_deps="nvdec"
> +mpeg4_nvdec_hwaccel_select="mpeg4_decoder"
>  mpeg4_vaapi_hwaccel_deps="vaapi"
>  mpeg4_vaapi_hwaccel_select="mpeg4_decoder"
>  mpeg4_vdpau_hwaccel_deps="vdpau"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 0573454c7b..2af957ab72 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -861,6 +861,7 @@ OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+=
> vaapi_mpeg2.o OBJS-$(CONFIG_MPEG2_VDPAU_HWACCEL)+=
> vdpau_mpeg12.o OBJS-$(CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL) +=
> videotoolbox.o OBJS-$(CONFIG_MPEG2_XVMC_HWACCEL) +=
> mpegvideo_xvmc.o +OBJS-$(CONFIG_MPEG4_NVDEC_HWACCEL)+=
> nvdec_mpeg4.o OBJS-$(CONFIG_MPEG4_VAAPI_HWACCEL)+=
> vaapi_mpeg4.o OBJS-$(CONFIG_MPEG4_VDPAU_HWACCEL)+=
> vdpau_mpeg4.o OBJS-$(CONFIG_MPEG4_VIDEOTOOLBOX_HWACCEL) +=
> videotoolbox.o diff --git a/libavcodec/allcodecs.c
> b/libavcodec/allcodecs.c index e9df7049de..85c38c83aa 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -106,6 +106,7 @@ static void register_all(void)
>  REGISTER_HWACCEL(MPEG4_CUVID,   mpeg4_cuvid);
>  REGISTER_HWACCEL(MPEG4_MEDIACODEC,  mpeg4_mediacodec);
>  REGISTER_HWACCEL(MPEG4_MMAL,mpeg4_mmal);
> +REGISTER_HWACCEL(MPEG4_NVDEC,   mpeg4_nvdec);
>  REGISTER_HWACCEL(MPEG4_VAAPI,   mpeg4_vaapi);
>  REGISTER_HWACCEL(MPEG4_VDPAU,   mpeg4_vdpau);
>  REGISTER_HWACCEL(MPEG4_VIDEOTOOLBOX, mpeg4_videotoolbox);
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index c7cf4bc0c2..b222de793b 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -714,6 +714,9 @@ const enum AVPixelFormat
> ff_h263_hwaccel_pixfmt_list_420[] = { #if CONFIG_H263_VAAPI_HWACCEL
> || CONFIG_MPEG4_VAAPI_HWACCEL AV_PIX_FMT_VAAPI,
>  #endif
> +#if CONFIG_MPEG4_NVDEC_HWACCEL
> +AV_PIX_FMT_CUDA,
> +#endif
>  #if CONFIG_MPEG4_VDPAU_HWACCEL
>  AV_PIX_FMT_VDPAU,
>  #endif
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index d5cf1058cb..efcd47a7f7 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -56,6 +56,7 @@ static int map_avcodec_id(enum AVCodecID id)
>  case AV_CODEC_ID_HEVC:   return cudaVideoCodec_HEVC;
>  case AV_CODEC_ID_MPEG1VIDEO: return cudaVideoCodec_MPEG1;
>  case AV_CODEC_ID_MPEG2VIDEO: return cudaVideoCodec_MPEG2;
> +case AV_CODEC_ID_MPEG4:  return cudaVideoCodec_MPEG4;
>  case AV_CODEC_ID_VC1:return cudaVideoCodec_VC1;
>  case AV_CODEC_ID_VP9:return cudaVideoCodec_VP9;
>  case AV_CODEC_ID_WMV3:   return cudaVideoCodec_VC1;
> diff --git a/libavcodec/nvdec_mpeg4.c b/libavcodec/nvdec_mpeg4.c
> new file mode 100644
> index 00..be81bd958b
> -

Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-19 Thread Philip Langdale
On Sun, 19 Nov 2017 23:35:24 +0100
Carl Eugen Hoyos  wrote:

> 2017-11-19 20:52 GMT+01:00 Philip Langdale :
> 
> > gmc_enabled: This seems to map to mc_sel being non-zero, but I also
> >  have no samples where that is true.  
> 
> Iirc, global motion compensation is not supported by hardware
> decoders.
> 

It's obviously hard to tell when you have no samples and no
documentation, but it would be weird if this flag existed only for the
hardware to give up if gmc was used. Still, it's all academic given the
complete lack of real world usage of gmc.

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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Implement mpeg4 nvdec hwaccel

2017-11-19 Thread Carl Eugen Hoyos
2017-11-19 20:52 GMT+01:00 Philip Langdale :

> gmc_enabled: This seems to map to mc_sel being non-zero, but I also
>  have no samples where that is true.

Iirc, global motion compensation is not supported by hardware decoders.

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