[FFmpeg-devel] [PATCH] avcodec/libdavs2: unbreak compilation failure

[Gyan Doshi]

FF_CODEC_CAP_AUTO_THREADS added in 8a129077cc requires internal.h
---
 libavcodec/libdavs2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 383b54039a..0f18353c93 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -23,6 +23,7 @@
  */
 
 #include "avcodec.h"
+#include "internal.h"
 #include "davs2.h"
 
 typedef struct DAVS2Context {
-- 
2.30.1

___
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".

Re: [FFmpeg-devel] [PATCH] libsvtav1: Add crf and enable_tpl_la options

[Christopher Degawa]

ping on this patch
___
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".

Re: [FFmpeg-devel] [PATCH] avformat/aviobuf: don't reduce short seek threshold

[Andriy Gelman]

On Mon, 15. Mar 11:52, Martin Storsjö wrote:
> On Sat, 13 Mar 2021, Andriy Gelman wrote:
> 
> > From: Andriy Gelman 
> > 
> > Commit 8c8e5d5286bf598a89ef9993a2cf6ea409d03a32 added a way to reduce
> > seek time by waiting for the windowed tcp packets instead of creating a
> > new socket connection. It implemented this by overwriting
> > s->short_seek_threshold in the avio_seek(). However,
> > s->short_seek_threshold could already be set and be higher than the
> > threshold set by the protocol (i.e. s->short_seek_threshold is set in
> > ff_configure_buffers_for_index()).
> > 
> > This new feature was only enabled for tls connections in
> > 70d8077b795766e2486e6ec8110f22a97362d6d7. As in Ticket #9148 it reduced
> 
> This commit reference is typoed, the last char should be a 6, not a 7.
> 
> > performance because instead of waiting to refill the AVIOContext buffers
> > with an existing connections, a new HTTP request was often made instead.
> > 
> > Fixes Ticket #9148.
> > 
> > Signed-off-by: Andriy Gelman 
> > ---
> > libavformat/aviobuf.c | 10 +++---
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> > index 78cc60b2ae..518cb11129 100644
> > --- a/libavformat/aviobuf.c
> > +++ b/libavformat/aviobuf.c
> > @@ -283,13 +283,9 @@ int64_t avio_seek(AVIOContext *s, int64_t offset, int 
> > whence)
> > if (offset < 0)
> > return AVERROR(EINVAL);
> > 
> > -if (s->short_seek_get) {
> > -short_seek = s->short_seek_get(s->opaque);
> > -/* fallback to default short seek */
> > -if (short_seek <= 0)
> > -short_seek = s->short_seek_threshold;
> > -} else
> > -short_seek = s->short_seek_threshold;
> > +short_seek = s->short_seek_threshold;
> > +if (s->short_seek_get)
> > +short_seek = FFMAX(s->short_seek_get(s->opaque), short_seek);
> > 
> > offset1 = offset - pos; // "offset1" is the relative offset from the 
> > beginning of s->buffer
> > s->buf_ptr_max = FFMAX(s->buf_ptr_max, s->buf_ptr);
> > -- 
> > 2.30.2

> 
> LGTM, thanks!

Thanks, will apply with the typo fix.

-- 
Andriy
___
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".

Re: [FFmpeg-devel] [PATCH 0/5] Initial usage of AVCodecContext.get_encode_buffer()

[James Almer]

On 3/12/2021 9:15 PM, James Almer wrote:

For ffmpeg 4.4, as the last version featuring avcodec_encode_video2/audio2 and
since marking an encoder as AV_CODEC_CAP_DR1 capable will make it unusable with
that API, we should only port encoders using the AVCodec.receive_packet() API.

The rest can be ported after either ffmpeg 4.4 is branched out from master, or
the major version bumped and the old encode API removed.

James Almer (5):
   avcodec/amfenc: use AVCodecContext.get_encode_buffer()
   avcodec/librav1e: use AVCodecContext.get_encode_buffer()
   avcodec/mfenc: use AVCodecContext.get_encode_buffer()
   avcodec/nvenc: use AVCodecContext.get_encode_buffer()
   avcodec/vaapi_encode: use AVCodecContext.get_encode_buffer()

  libavcodec/amfenc.c | 2 +-
  libavcodec/amfenc_h264.c| 3 ++-
  libavcodec/amfenc_hevc.c| 3 ++-
  libavcodec/librav1e.c   | 5 +++--
  libavcodec/mfenc.c  | 5 +++--
  libavcodec/nvenc.c  | 2 +-
  libavcodec/nvenc_h264.c | 2 +-
  libavcodec/nvenc_hevc.c | 2 +-
  libavcodec/vaapi_encode.c   | 2 +-
  libavcodec/vaapi_encode_h264.c  | 3 ++-
  libavcodec/vaapi_encode_h265.c  | 3 ++-
  libavcodec/vaapi_encode_mjpeg.c | 2 +-
  libavcodec/vaapi_encode_mpeg2.c | 3 ++-
  libavcodec/vaapi_encode_vp8.c   | 3 ++-
  libavcodec/vaapi_encode_vp9.c   | 3 ++-
  15 files changed, 26 insertions(+), 17 deletions(-)


Will apply.
___
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".

Re: [FFmpeg-devel] [PATCH] lavu: add VKAPI hwcontext implementation

[Suji Velupillai]

Thank you Mark for your feedback. Please see inline

On Fri, Mar 12, 2021 at 1:14 PM Mark Thompson  wrote:

> On 11/03/2021 22:09, suji.velupil...@broadcom.com wrote:
> > From: Suji Velupillai 
> >
> > Initial commit to add VKAPI hardware accelerator implementation.
> > The depedency component vkil source code can be obtained from github
> > https://github.com/Broadcom/vkil
> >
> > Signed-off-by: Suji Velupillai 
> > ---
> >   configure  |   8 +-
> >   doc/APIchanges |   4 +
> >   libavutil/Makefile |   2 +
> >   libavutil/hwcontext.c  |   4 +
> >   libavutil/hwcontext.h  |   1 +
> >   libavutil/hwcontext_internal.h |   1 +
> >   libavutil/hwcontext_vkapi.c| 522 +
> >   libavutil/hwcontext_vkapi.h| 104 +++
> >   libavutil/pixdesc.c|   4 +
> >   libavutil/pixfmt.h |   6 +
> >   10 files changed, 655 insertions(+), 1 deletion(-)
> >   create mode 100644 libavutil/hwcontext_vkapi.c
> >   create mode 100644 libavutil/hwcontext_vkapi.h
>
> Where has the "vkapi" name come from?  It seems to be consistently called
> "vkil" in that repository.

valkyrie is the hardware name. vkil refers to VK Interface Layer. vkapi is
the name given to all ffmpeg API's.


>
If you are making up the name for this, please consider making it less
> confusing:
> * The standard Vulkan API already effectively owns the "vk" namespace
> prefix, and colliding with that in a related project is unhelpful.
>* Indeed, Vulkan already uses the "VKAPI" name in its headers when
> marking ABIs (see <
> https://github.com/ARM-software/vulkan-sdk/blob/master/include/vulkan/vk_platform.h#L35
> >).
> * Current search results for "vkapi" show it is also used by APIs for the
> VK social network.
>

Okay I will rename all with VKAPI and VK_* reference to avoid
conflicts/confusion.
Kernel driver code consistently used "bcm_vk", also Google search points
correctly to the kernel driver for this card.
Would it be okay to switch to bcm_vk instead of vkapi and vk?


>
> > ... > diff --git a/libavutil/hwcontext_vkapi.h
> b/libavutil/hwcontext_vkapi.h
> > new file mode 100644
> > index 00..096602b42e
> > --- /dev/null
> > +++ b/libavutil/hwcontext_vkapi.h
> > @@ -0,0 +1,104 @@
> > +/*
> > + * Copyright (c) 2018 Broadcom
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> > + */
> > +
> > +#ifndef AVUTIL_HWCONTEXT_VKAPI_H
> > +#define AVUTIL_HWCONTEXT_VKAPI_H
> > +
> > +#include 
> > +
> > +#define VKAPI_METADATA_PLANE 4
> > +
> > +/**
> > + * @file
> > + * API-specific header for AV_HWDEVICE_TYPE_VKAPI.
> > + */
> > +
> > +/**
> > + * Allocated as AVHWDeviceContext.hwctx
> > + */
> > +typedef struct VKAPIDeviceContext {
> > +/**
> > + * Holds pointers to hardware specific functions
> > + */
> > +vkil_api *ilapi;
> > +/**
> > + * Internal functions definitions
> > + */
> > +/**
> > + * Get the hwprops reference from the AVFrame:data[3]
> > + */
> > +int (*frame_ref_hwprops)(const AVFrame *frame, void
> *phw_surface_desc);
> > +/**
> > + * Set the hwprops into AVFrame:data[3]
> > + */
> > +int (*frame_set_hwprops)(AVFrame *frame, const vkil_buffer_surface
> *hw_surface_desc);
> > +/**
> > + * Get the hwprops from AVFrame:data[3]
> > + */
> > +int (*frame_get_hwprops)(const AVFrame *frame, vkil_buffer_surface
> *hw_surface_desc);
> > +/**
> > + * Check if format is in an array
> > + */
> > +int (*fmt_is_in)(int fmt, const int *fmts);
> > +/**
> > + * Convert AVPixelFormat to VKAPI equivalent pixel format
> > + */
> > +int (*av2vk_fmt)(enum AVPixelFormat pixel_format);
> > +/**
> > + * Get no of buffer count reference in the hardware pool
> > + */
> > +int (*get_pool_occupancy)(AVHWFramesContext *ctx);
> > +} VKAPIDeviceContext;
>
> This structure has two uses:
>
> * To be filled by the user when they already have an instance of the
> device and want to use it with libav*.
> * To provide information to the user about an instance of the device
> created inside libav*.
>
> To that end, the "ilapi" field makes sense to me (the 

Re: [FFmpeg-devel] [PATCH 5/5] lavfi/dnn_backend_openvino.c: fix mem leak for TaskItem upon error

[Guo, Yejun]

> -Original Message-
> From: Guo, Yejun 
> Sent: 2021年3月13日 14:29
> To: ffmpeg-devel@ffmpeg.org
> Cc: Guo, Yejun 
> Subject: [PATCH 5/5] lavfi/dnn_backend_openvino.c: fix mem leak for TaskItem
> upon error
> 
> ---
>  libavfilter/dnn/dnn_backend_openvino.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> b/libavfilter/dnn/dnn_backend_openvino.c
> index 55cb0c757e..9a47d74c15 100644
> --- a/libavfilter/dnn/dnn_backend_openvino.c
> +++ b/libavfilter/dnn/dnn_backend_openvino.c
> @@ -678,12 +678,6 @@ DNNReturnType
> ff_dnn_execute_model_async_ov(const DNNModel *model, const char *i
>  return DNN_ERROR;
>  }
> 
> -task = av_malloc(sizeof(*task));
> -if (!task) {
> -av_log(ctx, AV_LOG_ERROR, "unable to alloc memory for task
> item.\n");
> -return DNN_ERROR;
> -}
> -
>  if (!ov_model->exe_network) {
>  if (init_model_ov(ov_model, input_name, output_names[0]) !=
> DNN_SUCCESS) {
>  av_log(ctx, AV_LOG_ERROR, "Failed init OpenVINO exectuable
> network or inference request\n"); @@ -691,6 +685,12 @@ DNNReturnType
> ff_dnn_execute_model_async_ov(const DNNModel *model, const char *i
>  }
>  }
> 
> +task = av_malloc(sizeof(*task));
> +if (!task) {
> +av_log(ctx, AV_LOG_ERROR, "unable to alloc memory for task
> item.\n");
> +return DNN_ERROR;
> +}
> +
>  task->done = 0;
>  task->do_ioproc = 1;
>  task->async = 1;
> --
> 2.17.1

will push tomorrow if there's no objection, thanks.

___
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".

Re: [FFmpeg-devel] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions

[Zane van Iperen]

On 16/3/21 11:31 pm, Thilo Borgmann wrote:

Am 10.03.21 um 18:19 schrieb Thilo Borgmann:

Am 10.03.21 um 09:25 schrieb Zane van Iperen:

Before you do, just give it a crack locally.

I couldn't get the cloned version of the site to look identical to what's 
already published (something to do with incorrect CSS symlinks iirc). It's 
probably fine, but for something like this I'd rather err on the side of 
caution.


I know this problem and I'm happily ignoring it - because the style thingys are 
living happily on the server and look like intended.

So I don't expect any problems. If so, its the website being a bit more ugly 
for maybe some short time...
Not doing it today anyway, so you can still test on if you feel the desire to 
get a 1:1 website locally.


Pushed. I don't see any bad thing on ffmpeg.org, please check.


Look all good to me.
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size

[Marton Balint]

On Tue, 16 Mar 2021, Marton Balint wrote:




On Tue, 16 Mar 2021, Mark Plomer wrote:

Unfortunately it is not possible to move the hack to the bottom, because 
the "normal processing" (dv_profiles lookup loop) will catch it 
otherwise (with a wrong profile), because it does not check the frame_size:


Then at least check the 50/60 flag as well in the VAUX source pack, e.g.:

pal   = !!(frame[80 * 5 + 48 + 3] & 0x20);


And as far as I see, the more specific hack checking for codec_tag and 
similar can be removed then, because your check covers that case as well.


Regards,
Marton



Regards,
Marton




    for (i = 0; i < FF_ARRAY_ELEMS(dv_profiles); i++)
    if (dsf == dv_profiles[i].dsf && stype == 
dv_profiles[i].video_stype)

    return _profiles[i];

But as the new "if" is very specific and catches an "invalid" 
combination only (with the frame_size check), it should not break 
anything, I think:


    if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size == 
dv_profiles[1].frame_size)


At least, I put the new hack after all other "pre-normal-processing" 
hacks ;-)


Regards
Mark

Am 13.03.21 um 17:48 schrieb Marton Balint:



On Sat, 16 Jan 2021, Mark Plomer wrote:


Trying to fix https://trac.ffmpeg.org/ticket/8333

Some of my old DV AVI files have the DSF-Flag of frames set to 0, 
although it is PAL (I think they were rendered with Ulead Media 
Studio Pro) ... this causes ffmpeg/VLC-player to produce/play 
corrupted video.


In other players/editors it works fine including:

- VirtualDub
- Windows Media Player
- AVCutty
- Ulead Media Studio Pro (very old)

I had a look at VirtualDub ... there the PAL/NTSC detection is based 
on the frame rate from AVISTREAMINFO header (dwRate/dwScale) - see 




https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211


As I don't know, how to access the AVI header info inside 
dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another 
workaround by checking the buf_size against the dv_profile.


It works fine now, but I don't know, if this is really the best 
solution ...


--- a/libavcodec/dv_profile.c
+++ b/libavcodec/dv_profile.c
@@ -281,6 +281,10 @@ const AVDVProfile* 
ff_dv_frame_profile(AVCodecContext* codec, const AVDVProfile

    && codec->coded_height==576)
 return _profiles[1];

+    /* hack for trac issue #8333, dv files with wrong dsf flag - 
detect via buf_size */
+    if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size 
== dv_profiles[1].frame_size)

+    return _profiles[1];
+

If possible, then it is probably better to move this fallback to later 
in the code, right after the hack for trac issue #217, so previous 
hacks won't get broken...


Regards,
Marton
___
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".

___
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".

___
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".

___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size

[Marton Balint]

On Tue, 16 Mar 2021, Mark Plomer wrote:

Unfortunately it is not possible to move the hack to the bottom, because 
the "normal processing" (dv_profiles lookup loop) will catch it 
otherwise (with a wrong profile), because it does not check the frame_size:


Then at least check the 50/60 flag as well in the VAUX source pack, e.g.:

pal   = !!(frame[80 * 5 + 48 + 3] & 0x20);

Regards,
Marton




    for (i = 0; i < FF_ARRAY_ELEMS(dv_profiles); i++)
    if (dsf == dv_profiles[i].dsf && stype == 
dv_profiles[i].video_stype)

    return _profiles[i];

But as the new "if" is very specific and catches an "invalid" 
combination only (with the frame_size check), it should not break 
anything, I think:


    if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size == 
dv_profiles[1].frame_size)


At least, I put the new hack after all other "pre-normal-processing" 
hacks ;-)


Regards
Mark

Am 13.03.21 um 17:48 schrieb Marton Balint:



On Sat, 16 Jan 2021, Mark Plomer wrote:


Trying to fix https://trac.ffmpeg.org/ticket/8333

Some of my old DV AVI files have the DSF-Flag of frames set to 0, 
although it is PAL (I think they were rendered with Ulead Media 
Studio Pro) ... this causes ffmpeg/VLC-player to produce/play 
corrupted video.


In other players/editors it works fine including:

- VirtualDub
- Windows Media Player
- AVCutty
- Ulead Media Studio Pro (very old)

I had a look at VirtualDub ... there the PAL/NTSC detection is based 
on the frame rate from AVISTREAMINFO header (dwRate/dwScale) - see 


https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211


As I don't know, how to access the AVI header info inside 
dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another 
workaround by checking the buf_size against the dv_profile.


It works fine now, but I don't know, if this is really the best 
solution ...


--- a/libavcodec/dv_profile.c
+++ b/libavcodec/dv_profile.c
@@ -281,6 +281,10 @@ const AVDVProfile* 
ff_dv_frame_profile(AVCodecContext* codec, const AVDVProfile

    && codec->coded_height==576)
 return _profiles[1];

+    /* hack for trac issue #8333, dv files with wrong dsf flag - 
detect via buf_size */
+    if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size 
== dv_profiles[1].frame_size)

+    return _profiles[1];
+

If possible, then it is probably better to move this fallback to later 
in the code, right after the hack for trac issue #217, so previous 
hacks won't get broken...


Regards,
Marton
___
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".

___
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".

___
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/webvttdec, enc: correctly process files containing STYLE, REGION blocks

[Dave Evans]

Would it be possible for someone to take a look at this please? Would be
lovely to get it merged at some point. Please let me know if further
changes are needed.

Cheers,
Dave

On Tue, Oct 13, 2020 at 10:25 AM Dave Evans  wrote:

> This patch fixes the total failure to parse cues when style and region
> definition blocks are contained in the input file, and ensures those
> blocks are written to the output when copying.
>
> The sample attached needs to be added to samples at the path shown in
> the patch in order to validate that the original issue is fixed.
>
> Same as v1 except the test has been changed as requested in the original
> review.
>
> Cheers,
> Dave
>
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size

[Mark Plomer]

Oh yes, of course. I updated the commit-message in the attached new patch.

Am 13.03.21 um 11:41 schrieb Michael Niedermayer:


The commit message should mention "Fixes Ticket8333" if that is a bugfix
for that ticket

also maybe some of the other details you write in your mail could be moved
into the commit message

Thanks

[...]

>From 8bcbd3ff98c63a96c5191244de25fc83f1c2fd5b Mon Sep 17 00:00:00 2001
From: Mark Plomer 
Date: Sat, 16 Jan 2021 14:04:44 +0100
Subject: [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via
 buf_size

Some old DV AVI files have the DSF-Flag of frames set to 0, although it
is PAL (maybe rendered with an old Ulead Media Studio Pro) ... this causes
ffmpeg/VLC-player to produce/play corrupted video (other players/editors
like VirtualDub work fine).

Fixes ticket #8333
---
 libavcodec/dv_profile.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/dv_profile.c b/libavcodec/dv_profile.c
index 66505c886b..8f9a358032 100644
--- a/libavcodec/dv_profile.c
+++ b/libavcodec/dv_profile.c
@@ -281,6 +281,10 @@ const AVDVProfile* ff_dv_frame_profile(AVCodecContext* codec, const AVDVProfile
&& codec->coded_height==576)
 return _profiles[1];
 
+/* hack for trac issue #8333, dv files with wrong dsf flag - detect via buf_size */
+if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size == dv_profiles[1].frame_size)
+return _profiles[1];
+
 for (i = 0; i < FF_ARRAY_ELEMS(dv_profiles); i++)
 if (dsf == dv_profiles[i].dsf && stype == dv_profiles[i].video_stype)
 return _profiles[i];
-- 
2.25.1

___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/dv_profile: dv files with wrong dsf flag - detect via buf_size

[Mark Plomer]

Unfortunately it is not possible to move the hack to the bottom, because 
the "normal processing" (dv_profiles lookup loop) will catch it 
otherwise (with a wrong profile), because it does not check the frame_size:


    for (i = 0; i < FF_ARRAY_ELEMS(dv_profiles); i++)
    if (dsf == dv_profiles[i].dsf && stype == 
dv_profiles[i].video_stype)

    return _profiles[i];

But as the new "if" is very specific and catches an "invalid" 
combination only (with the frame_size check), it should not break 
anything, I think:


    if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size == 
dv_profiles[1].frame_size)


At least, I put the new hack after all other "pre-normal-processing" 
hacks ;-)


Regards
Mark

Am 13.03.21 um 17:48 schrieb Marton Balint:



On Sat, 16 Jan 2021, Mark Plomer wrote:


Trying to fix https://trac.ffmpeg.org/ticket/8333

Some of my old DV AVI files have the DSF-Flag of frames set to 0, 
although it is PAL (I think they were rendered with Ulead Media 
Studio Pro) ... this causes ffmpeg/VLC-player to produce/play 
corrupted video.


In other players/editors it works fine including:

- VirtualDub
- Windows Media Player
- AVCutty
- Ulead Media Studio Pro (very old)

I had a look at VirtualDub ... there the PAL/NTSC detection is based 
on the frame rate from AVISTREAMINFO header (dwRate/dwScale) - see 
https://github.com/Pavuucek/VirtualDub/blob/f47ebd2536f0034b048180d0b9cb9bde0ab10c73/src/VirtualDub/source/VideoSource.cpp#L1211


As I don't know, how to access the AVI header info inside 
dvvideo_decode_frame()/ff_dv_frame_profile(), I tried another 
workaround by checking the buf_size against the dv_profile.


It works fine now, but I don't know, if this is really the best 
solution ...


--- a/libavcodec/dv_profile.c
+++ b/libavcodec/dv_profile.c
@@ -281,6 +281,10 @@ const AVDVProfile* 
ff_dv_frame_profile(AVCodecContext* codec, const AVDVProfile

    && codec->coded_height==576)
 return _profiles[1];

+    /* hack for trac issue #8333, dv files with wrong dsf flag - 
detect via buf_size */
+    if (dsf == 0 && stype == dv_profiles[1].video_stype && buf_size 
== dv_profiles[1].frame_size)

+    return _profiles[1];
+

If possible, then it is probably better to move this fallback to later 
in the code, right after the hack for trac issue #217, so previous 
hacks won't get broken...


Regards,
Marton
___
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".

___
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".

[FFmpeg-devel] [PATCH 6/6] avcodec/options: Reindent after previous commit

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/options.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavcodec/options.c b/libavcodec/options.c
index 53f13dab37..58c7ce8d62 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -140,10 +140,9 @@ static int init_context_defaults(AVCodecContext *s, const 
AVCodec *codec)
 
 s->reordered_opaque= AV_NOPTS_VALUE;
 if(codec && codec->priv_data_size){
-s->priv_data= av_mallocz(codec->priv_data_size);
-if (!s->priv_data) {
-return AVERROR(ENOMEM);
-}
+s->priv_data = av_mallocz(codec->priv_data_size);
+if (!s->priv_data)
+return AVERROR(ENOMEM);
 if(codec->priv_class){
 *(const AVClass**)s->priv_data = codec->priv_class;
 av_opt_set_defaults(s->priv_data);
-- 
2.27.0

___
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".

[FFmpeg-devel] [PATCH 5/6] avcodec/options: Remove always-true check

[Andreas Rheinhardt]

Added in dc51a72ba45fbefb9f1c6c3ca5a5b2388d69b2da, yet even back then
the check was always true as the AVCodecContext has already been memset
to zero before that.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/options.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/options.c b/libavcodec/options.c
index 61689b48d9..53f13dab37 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -140,12 +140,10 @@ static int init_context_defaults(AVCodecContext *s, const 
AVCodec *codec)
 
 s->reordered_opaque= AV_NOPTS_VALUE;
 if(codec && codec->priv_data_size){
-if(!s->priv_data){
 s->priv_data= av_mallocz(codec->priv_data_size);
 if (!s->priv_data) {
 return AVERROR(ENOMEM);
 }
-}
 if(codec->priv_class){
 *(const AVClass**)s->priv_data = codec->priv_class;
 av_opt_set_defaults(s->priv_data);
-- 
2.27.0

___
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".

[FFmpeg-devel] [PATCH 4/6] avcodec/utils: Move decoder channel count check to ff_decode_preinit

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
I actually wonder why this flag is not used for encoders. Several of
them explicitly check for invalid channel values.

 libavcodec/decode.c | 5 +
 libavcodec/utils.c  | 8 
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index cbd41c8cc8..390147908d 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -2026,6 +2026,11 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
+if (avctx->codec_type == AVMEDIA_TYPE_AUDIO && avctx->channels == 0 &&
+!(avctx->codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF)) {
+av_log(avctx, AV_LOG_ERROR, "Decoder requires channel count but 
channels not set\n");
+return AVERROR(EINVAL);
+}
 if (avctx->codec->max_lowres < avctx->lowres || avctx->lowres < 0) {
 av_log(avctx, AV_LOG_WARNING, "The maximum value for lowres supported 
by the decoder is %d\n",
avctx->codec->max_lowres);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 7d4ad113df..77f98c951b 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -671,14 +671,6 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 ret = AVERROR(EINVAL);
 goto free_and_end;
 }
-if (av_codec_is_decoder(codec) &&
-codec->type == AVMEDIA_TYPE_AUDIO &&
-!(codec->capabilities & AV_CODEC_CAP_CHANNEL_CONF) &&
-avctx->channels == 0) {
-av_log(avctx, AV_LOG_ERROR, "Decoder requires channel count but 
channels not set\n");
-ret = AVERROR(EINVAL);
-goto free_and_end;
-}
 
 if (avctx->sample_rate < 0) {
 av_log(avctx, AV_LOG_ERROR, "Invalid sample rate: %d\n", 
avctx->sample_rate);
-- 
2.27.0

___
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".

[FFmpeg-devel] [PATCH 3/6] avcodec/utils: Sanitize options before using them

[Andreas Rheinhardt]

This is how it is supposed to happen, yet when using frame threading,
the codec's init function has been called before preinit. This can lead
to crashes when e.g. using unsupported lowres values for decoders
together with frame threading.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/utils.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 3629813387..7d4ad113df 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -716,6 +716,13 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 avctx->time_base.den = avctx->sample_rate;
 }
 
+if (av_codec_is_encoder(avctx->codec))
+ret = ff_encode_preinit(avctx);
+else
+ret = ff_decode_preinit(avctx);
+if (ret < 0)
+goto free_and_end;
+
 if (!HAVE_THREADS)
 av_log(avctx, AV_LOG_WARNING, "Warning: not compiled with thread 
support, using thread emulation\n");
 
@@ -737,13 +744,6 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 if (!HAVE_THREADS && !(codec->caps_internal & FF_CODEC_CAP_AUTO_THREADS))
 avctx->thread_count = 1;
 
-if (av_codec_is_encoder(avctx->codec))
-ret = ff_encode_preinit(avctx);
-else
-ret = ff_decode_preinit(avctx);
-if (ret < 0)
-goto free_and_end;
-
 if (   avctx->codec->init && (!(avctx->active_thread_type_THREAD_FRAME)
 || avci->frame_thread_encoder)) {
 ret = avctx->codec->init(avctx);
-- 
2.27.0

___
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".

[FFmpeg-devel] [PATCH 2/6] avcodec/utils: Perform sub_charenc/iconv checks before AVCodec.init()

[Andreas Rheinhardt]

Also move them to ff_decode_preinit().

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/decode.c | 35 +++
 libavcodec/utils.c  | 40 
 2 files changed, 35 insertions(+), 40 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 5a00aeedae..cbd41c8cc8 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -2031,6 +2031,41 @@ FF_ENABLE_DEPRECATION_WARNINGS
avctx->codec->max_lowres);
 avctx->lowres = avctx->codec->max_lowres;
 }
+if (avctx->sub_charenc) {
+if (avctx->codec_type != AVMEDIA_TYPE_SUBTITLE) {
+av_log(avctx, AV_LOG_ERROR, "Character encoding is only "
+   "supported with subtitles codecs\n");
+return AVERROR(EINVAL);
+} else if (avctx->codec_descriptor->props & AV_CODEC_PROP_BITMAP_SUB) {
+av_log(avctx, AV_LOG_WARNING, "Codec '%s' is bitmap-based, "
+   "subtitles character encoding will be ignored\n",
+   avctx->codec_descriptor->name);
+avctx->sub_charenc_mode = FF_SUB_CHARENC_MODE_DO_NOTHING;
+} else {
+/* input character encoding is set for a text based subtitle
+ * codec at this point */
+if (avctx->sub_charenc_mode == FF_SUB_CHARENC_MODE_AUTOMATIC)
+avctx->sub_charenc_mode = FF_SUB_CHARENC_MODE_PRE_DECODER;
+
+if (avctx->sub_charenc_mode == FF_SUB_CHARENC_MODE_PRE_DECODER) {
+#if CONFIG_ICONV
+iconv_t cd = iconv_open("UTF-8", avctx->sub_charenc);
+if (cd == (iconv_t)-1) {
+ret = AVERROR(errno);
+av_log(avctx, AV_LOG_ERROR, "Unable to open iconv context "
+   "with input character encoding \"%s\"\n", 
avctx->sub_charenc);
+return ret;
+}
+iconv_close(cd);
+#else
+av_log(avctx, AV_LOG_ERROR, "Character encoding subtitles "
+   "conversion needs a libavcodec built with iconv support 
"
+   "for this codec\n");
+return AVERROR(ENOSYS);
+#endif
+}
+}
+}
 
 avctx->pts_correction_num_faulty_pts =
 avctx->pts_correction_num_faulty_dts = 0;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2bc556c1d9..3629813387 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -60,9 +60,6 @@
 #include 
 #include 
 #include 
-#if CONFIG_ICONV
-# include 
-#endif
 
 #include "libavutil/ffversion.h"
 const char av_codec_ffversion[] = "FFmpeg version " FFMPEG_VERSION;
@@ -786,43 +783,6 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 ret = AVERROR(EINVAL);
 goto free_and_end;
 }
-if (avctx->sub_charenc) {
-if (avctx->codec_type != AVMEDIA_TYPE_SUBTITLE) {
-av_log(avctx, AV_LOG_ERROR, "Character encoding is only "
-   "supported with subtitles codecs\n");
-ret = AVERROR(EINVAL);
-goto free_and_end;
-} else if (avctx->codec_descriptor->props & 
AV_CODEC_PROP_BITMAP_SUB) {
-av_log(avctx, AV_LOG_WARNING, "Codec '%s' is bitmap-based, "
-   "subtitles character encoding will be ignored\n",
-   avctx->codec_descriptor->name);
-avctx->sub_charenc_mode = FF_SUB_CHARENC_MODE_DO_NOTHING;
-} else {
-/* input character encoding is set for a text based subtitle
- * codec at this point */
-if (avctx->sub_charenc_mode == FF_SUB_CHARENC_MODE_AUTOMATIC)
-avctx->sub_charenc_mode = FF_SUB_CHARENC_MODE_PRE_DECODER;
-
-if (avctx->sub_charenc_mode == 
FF_SUB_CHARENC_MODE_PRE_DECODER) {
-#if CONFIG_ICONV
-iconv_t cd = iconv_open("UTF-8", avctx->sub_charenc);
-if (cd == (iconv_t)-1) {
-ret = AVERROR(errno);
-av_log(avctx, AV_LOG_ERROR, "Unable to open iconv 
context "
-   "with input character encoding \"%s\"\n", 
avctx->sub_charenc);
-goto free_and_end;
-}
-iconv_close(cd);
-#else
-av_log(avctx, AV_LOG_ERROR, "Character encoding subtitles "
-   "conversion needs a libavcodec built with iconv 
support "
-   "for this codec\n");
-ret = AVERROR(ENOSYS);
-goto free_and_end;
-#endif
-}
-}
-}
 
 #if FF_API_AVCTX_TIMEBASE
 if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
-- 
2.27.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH 1/6] avcodec/utils: Check earlier for codec id/type mismatch

[Andreas Rheinhardt]

These fields can't be set via AVOptions, ergo one can check them before
having allocated anything.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/utils.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 71dbcb19d8..2bc556c1d9 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -564,6 +564,18 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 if (!codec)
 codec = avctx->codec;
 
+if ((avctx->codec_type == AVMEDIA_TYPE_UNKNOWN || avctx->codec_type == 
codec->type) &&
+avctx->codec_id == AV_CODEC_ID_NONE) {
+avctx->codec_type = codec->type;
+avctx->codec_id   = codec->id;
+}
+if (avctx->codec_id != codec->id || (avctx->codec_type != codec->type &&
+ avctx->codec_type != 
AVMEDIA_TYPE_ATTACHMENT)) {
+av_log(avctx, AV_LOG_ERROR, "Codec type or id mismatches\n");
+return AVERROR(EINVAL);
+}
+avctx->codec = codec;
+
 if (avctx->extradata_size < 0 || avctx->extradata_size >= 
FF_MAX_EXTRADATA_SIZE)
 return AVERROR(EINVAL);
 
@@ -682,18 +694,6 @@ int attribute_align_arg avcodec_open2(AVCodecContext 
*avctx, const AVCodec *code
 goto free_and_end;
 }
 
-avctx->codec = codec;
-if ((avctx->codec_type == AVMEDIA_TYPE_UNKNOWN || avctx->codec_type == 
codec->type) &&
-avctx->codec_id == AV_CODEC_ID_NONE) {
-avctx->codec_type = codec->type;
-avctx->codec_id   = codec->id;
-}
-if (avctx->codec_id != codec->id || (avctx->codec_type != codec->type
- && avctx->codec_type != 
AVMEDIA_TYPE_ATTACHMENT)) {
-av_log(avctx, AV_LOG_ERROR, "Codec type or id mismatches\n");
-ret = AVERROR(EINVAL);
-goto free_and_end;
-}
 avctx->frame_number = 0;
 avctx->codec_descriptor = avcodec_descriptor_get(avctx->codec_id);
 
-- 
2.27.0

___
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".

[FFmpeg-devel] [PATCH]lavf/swfdec: Allow decoding Nellymoser in swf

[Carl Eugen Hoyos]

Hi,

apart from the existing code and the sample files in ticket #9153,
Nellymoser in swf is apparently supported by Flash binaries if I read
the existing exploit correctly.

Please comment, Carl Eugen
From 3d1a744ce548fab6f3ae1b8f7f867a80452637b7 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 16 Mar 2021 21:11:45 +0100
Subject: [PATCH] lavf/swfdec: Allow decoding Nellymoser in swf.

Such files exist in the wild, see ticket #9153.
---
 libavformat/swfdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
index 9416187803..60c02cca12 100644
--- a/libavformat/swfdec.c
+++ b/libavformat/swfdec.c
@@ -52,7 +52,7 @@ static const AVCodecTag swf_audio_codec_tags[] = {
 { AV_CODEC_ID_ADPCM_SWF,  0x01 },
 { AV_CODEC_ID_MP3,0x02 },
 { AV_CODEC_ID_PCM_S16LE,  0x03 },
-//  { AV_CODEC_ID_NELLYMOSER, 0x06 },
+{ AV_CODEC_ID_NELLYMOSER, 0x06 },
 { AV_CODEC_ID_NONE,  0 },
 };
 
-- 
2.30.1

___
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".

Re: [FFmpeg-devel] [PATCH] lavu: add VKAPI hwcontext implementation

[Suji Velupillai]

On Fri, Mar 12, 2021 at 2:06 PM Mark Thompson  wrote:

> On 12/03/2021 18:29, Suji Velupillai wrote:
> > On Fri, Mar 12, 2021 at 1:12 AM Jean-Baptiste Kempf 
> wrote:
> >
> >> On Thu, 11 Mar 2021, at 23:09, suji.velupil...@broadcom.com wrote:
> >>> Initial commit to add VKAPI hardware accelerator implementation.
> >>> The depedency component vkil source code can be obtained from github
> >>> https://github.com/Broadcom/vkil
> >>
> >> This has no license, no readme, no description.
> >>
> > I'll have this addressed in the github.
> >
> >
> >>
> >> What is the hardware supported?
> >>
> > It's an M.2 module connected via PCIe that supports video transcoding.
> Some
> > high level info can be found here
> >
> https://engineering.fb.com/2019/03/14/data-center-engineering/accelerating-infrastructure/
> >
> > Does it work for rPI?
> >>
> > No
>
> So it's some sort of custom hardware for Facebook servers, and presumably
> therefore of no use to anyone outside Facebook?  Why is this being
> submitted to FFmpeg?
>
> The servers are from Facebook's contribution to the Open Compute Project.
 See  Facebook Contributions to Open Compute Project (OCP)

 .
The Video Transcoding PCIe cards are standard M.2 form factor and can be
used in standard Servers or Desktops that accept M.2 cards.
Kernel driver for the hardware is already in kernel 5.11.

> - Mark
> ___
> 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".


smime.p7s
Description: S/MIME Cryptographic Signature
___
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".

[FFmpeg-devel] [PATCH] libavformat: IEC61937_EAC3 decoding support

[Denis Shulyaka]

This patch adds support to decode IEC61937_EAC3 (aka dolby digital plus).

Signed-off-by: Denis Shulyaka 
---
 libavformat/spdifdec.c | 47 ++
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/libavformat/spdifdec.c b/libavformat/spdifdec.c
index 1808fa9d65..58841e7775 100644
--- a/libavformat/spdifdec.c
+++ b/libavformat/spdifdec.c
@@ -93,6 +93,10 @@ static int spdif_get_offset_and_codec(AVFormatContext *s,
 *offset = 8192;
 *codec = AV_CODEC_ID_DTS;
 break;
+case IEC61937_EAC3:
+*offset = AC3_FRAME_SIZE << 4;
+*codec = AV_CODEC_ID_EAC3;
+break;
 default:
 if (s) { /* be silent during a probe */
 avpriv_request_sample(s, "Data type 0x%04x in IEC 61937",
@@ -103,9 +107,34 @@ static int spdif_get_offset_and_codec(AVFormatContext
*s,
 return 0;
 }

-/* Largest offset between bursts we currently handle, i.e. AAC with
-   samples = 4096 */
-#define SPDIF_MAX_OFFSET 16384
+static int spdif_read_burst_payload_length(AVFormatContext *s,
+   enum IEC61937DataType data_type)
+{
+AVIOContext *pb = s->pb;
+int pkt_size_bits, pkt_size_bytes;
+
+switch (data_type & 0xff) {
+case IEC61937_EAC3:
+pkt_size_bytes = avio_rl16(pb);
+
+if (pkt_size_bytes % 2)
+avpriv_request_sample(s, "Packet not ending at a 16-bit
boundary");
+
+return FFALIGN(pkt_size_bytes, 2);
+break;
+default:
+pkt_size_bits = avio_rl16(pb);
+
+if (pkt_size_bits % 16)
+avpriv_request_sample(s, "Packet not ending at a 16-bit
boundary");
+
+return FFALIGN(pkt_size_bits, 16) >> 3;
+}
+return 0;
+}
+
+/* Largest offset between bursts we currently handle, i.e. E-AC-3 */
+#define SPDIF_MAX_OFFSET 24576

 static int spdif_probe(const AVProbeData *p)
 {
@@ -140,7 +169,7 @@ int ff_spdif_probe(const uint8_t *p_buf, int buf_size,
enum AVCodecID *codec)
 break;

 /* continue probing to find more sync codes */
-probe_end = FFMIN(buf + SPDIF_MAX_OFFSET, p_buf + buf_size -
1);
+probe_end = FFMIN(buf + SPDIF_MAX_OFFSET + 1, p_buf + buf_size
- 1);

 /* skip directly to the next sync code */
 if (!spdif_get_offset_and_codec(NULL, (buf[2] << 8) | buf[1],
@@ -176,7 +205,7 @@ int ff_spdif_read_packet(AVFormatContext *s, AVPacket
*pkt)
 enum IEC61937DataType data_type;
 enum AVCodecID codec_id;
 uint32_t state = 0;
-int pkt_size_bits, offset, ret;
+int pkt_size, offset, ret;

 while (state != (AV_BSWAP16C(SYNCWORD1) << 16 |
AV_BSWAP16C(SYNCWORD2))) {
 state = (state << 8) | avio_r8(pb);
@@ -185,12 +214,12 @@ int ff_spdif_read_packet(AVFormatContext *s, AVPacket
*pkt)
 }

 data_type = avio_rl16(pb);
-pkt_size_bits = avio_rl16(pb);
+pkt_size = spdif_read_burst_payload_length(s, data_type);

-if (pkt_size_bits % 16)
-avpriv_request_sample(s, "Packet not ending at a 16-bit boundary");
+if (!pkt_size)
+return AVERROR_BUG;

-ret = av_new_packet(pkt, FFALIGN(pkt_size_bits, 16) >> 3);
+ret = av_new_packet(pkt, pkt_size);
 if (ret)
 return ret;

-- 
2.30.2
___
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".

Re: [FFmpeg-devel] [PATCH] set ulMaxDisplayDelay cuviddec parser option to zero if low_delay flag is on

[clime]

Some measurements:

cpu:  Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
gpu: Quadro RTX 4000

GPU H264 DECODING
=

NOTE:
- first column is max floating average over past 10s
- second column is overall maximum during measurement (at least 1 min)
- measure for custom app using new ffmpeg api, a very few ms could maybe
be trimmed off by more efficient implementation
- 1x LOW DELAY OFF is there for comparison

1x LOW DELAY ON
---
h264_1920_1080_420_8b_120p_bcount:0_crf:14.ts 14ms 26ms
h264_1920_1080_420_8b_120p_bcount:2_crf:14.ts 28ms 69ms
h264_1920_1080_420_8b_120p_bcount:4_crf:14.ts 28ms 78ms

h264_1920_1080_420_8b_30p_bcount:0_crf:14.ts 41ms  53ms
h264_1920_1080_420_8b_30p_bcount:2_crf:14.ts 105ms 244ms
h264_1920_1080_420_8b_30p_bcount:4_crf:14.ts 105ms 280ms

h264_1920_1080_420_8b_60p_bcount:0_crf:14.ts 23ms 36ms
h264_1920_1080_420_8b_60p_bcount:2_crf:14.ts 53ms 108ms
h264_1920_1080_420_8b_60p_bcount:4_crf:14.ts 54ms 129ms

h264_2880_1620_420_8b_60p_bcount:0_crf:14.ts 27ms 41ms
h264_2880_1620_420_8b_60p_bcount:2_crf:14.ts 55ms 111ms
h264_2880_1620_420_8b_60p_bcount:4_crf:14.ts 55ms 131ms

h264_2880_1620_420_8b_120p_bcount:0_crf:14.ts 20ms 46ms
h264_2880_1620_420_8b_120p_bcount:2_crf:14.ts 30ms 70ms
h264_2880_1620_420_8b_120p_bcount:4_crf:14.ts 31ms 79ms

1x LOW DELAY OFF

h264_1920_1080_420_8b_120p_bcount:0_crf:14.ts 36ms 48ms
h264_1920_1080_420_8b_120p_bcount:2_crf:14.ts 44ms 85ms
h264_1920_1080_420_8b_120p_bcount:4_crf:14.ts 53ms 103ms

h264_1920_1080_420_8b_30p_bcount:0_crf:14.ts 137ms 151ms
h264_1920_1080_420_8b_30p_bcount:2_crf:14.ts 172ms 309ms
h264_1920_1080_420_8b_30p_bcount:4_crf:14.ts 206ms 380ms

h264_1920_1080_420_8b_60p_bcount:0_crf:14.ts 69ms  82ms
h264_1920_1080_420_8b_60p_bcount:2_crf:14.ts 86ms  162ms
h264_1920_1080_420_8b_60p_bcount:4_crf:14.ts 104ms 210ms

h264_2880_1620_420_8b_60p_bcount:0_crf:14.ts 71ms  86ms
h264_2880_1620_420_8b_60p_bcount:2_crf:14.ts 88ms  161ms
h264_2880_1620_420_8b_60p_bcount:4_crf:14.ts 105ms 212ms

h264_2880_1620_420_8b_120p_bcount:0_crf:14.ts 38ms 52ms
h264_2880_1620_420_8b_120p_bcount:2_crf:14.ts 46ms 85ms
h264_2880_1620_420_8b_120p_bcount:4_crf:14.ts 54ms 106ms

3x LOW DELAY ON
---
(nvdec: 40% load)
h264_1920_1080_420_8b_120p_bcount:0_crf:14.ts 14ms 31ms
h264_1920_1080_420_8b_120p_bcount:2_crf:14.ts 27ms 67ms
h264_1920_1080_420_8b_120p_bcount:4_crf:14.ts 28ms 77ms

(nvdec: 24% load)
h264_1920_1080_420_8b_30p_bcount:0_crf:14.ts 41ms  58ms
h264_1920_1080_420_8b_30p_bcount:2_crf:14.ts 105ms 246ms
h264_1920_1080_420_8b_30p_bcount:4_crf:14.ts 105ms 277ms

(nvdec: 35% load)
h264_1920_1080_420_8b_60p_bcount:0_crf:14.ts 23ms 35ms
h264_1920_1080_420_8b_60p_bcount:2_crf:14.ts 53ms 109ms
h264_1920_1080_420_8b_60p_bcount:4_crf:14.ts 53ms 130ms

(nvdec: 36% load)
h264_2880_1620_420_8b_60p_bcount:0_crf:14.ts 26ms 44ms
h264_2880_1620_420_8b_60p_bcount:2_crf:14.ts 54ms 112ms
h264_2880_1620_420_8b_60p_bcount:4_crf:14.ts 55ms 133ms

(nvdec: 62% load)
h264_2880_1620_420_8b_120p_bcount:0_crf:14.ts 18ms 43ms
h264_2880_1620_420_8b_120p_bcount:2_crf:14.ts 30ms 71ms
h264_2880_1620_420_8b_120p_bcount:4_crf:14.ts 31ms 80ms

7x LOW DELAY ON
---
(nvdec: 70% load)
h264_1920_1080_420_8b_120p_bcount:0_crf:14.ts 15ms 40ms
h264_1920_1080_420_8b_120p_bcount:2_crf:14.ts 28ms 69ms
h264_1920_1080_420_8b_120p_bcount:4_crf:14.ts 29ms 78ms

11x LOW DELAY ON

(nvdec: 65% load)
h264_1920_1080_420_8b_60p_bcount:0_crf:14.ts 23ms 45ms
h264_1920_1080_420_8b_60p_bcount:2_crf:14.ts 53ms 108ms
h264_1920_1080_420_8b_60p_bcount:4_crf:14.ts 54ms 131ms

6x LOW DELAY ON
---
(nvdec: 70% load)
h264_2880_1620_420_8b_60p_bcount:0_crf:14.ts 28ms 53ms
h264_2880_1620_420_8b_60p_bcount:2_crf:14.ts 55ms 112ms
h264_2880_1620_420_8b_60p_bcount:4_crf:14.ts 55ms 134ms

4x LOW DELAY ON
---
(nvdec: 78% load)
h264_2880_1620_420_8b_120p_bcount:0_crf:14.ts 24ms 58ms
h264_2880_1620_420_8b_120p_bcount:2_crf:14.ts 31ms 70ms
h264_2880_1620_420_8b_120p_bcount:4_crf:14.ts 33ms 79ms


Sample bitrates for bcount:0 inputs:
h264_1920_1080_420_8b_120p_bcount:0_crf:14.ts: 89890 kb/s
h264_1920_1080_420_8b_30p_bcount:0_crf:14.ts: 66513 kb/s
h264_1920_1080_420_8b_60p_bcount:0_crf:14.ts: 85399 kb/s
h264_2880_1620_420_8b_60p_bcount:0_crf:14.ts: 138562 kb/s
h264_2880_1620_420_8b_120p_bcount:0_crf:14.ts: 149715 kb/s

Best regards
Michal Novotny

On Mon, 22 Feb 2021 at 18:06, clime  wrote:
>
> From: Michal Novotny 
>
> * zero is recommended value in Nvidia coding samples for low latency use-cases
>
> Signed-off-by: Michal Novotny 
> ---
>  libavcodec/cuviddec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 49775b5a09..ec57afdefe 100644
> --- a/libavcodec/cuviddec.c
> +++ b/libavcodec/cuviddec.c
> @@ -999,7 +999,7 @@ static av_cold int cuvid_decode_init(AVCodecContext 
> *avctx)
>  }
>
>  ctx->cuparseinfo.ulMaxNumDecodeSurfaces = ctx->nb_surfaces;
> -

Re: [FFmpeg-devel] [PATCH 45/48] doc/examples/vaapi_encode: use av_packet_alloc() to allocate packets

[James Almer]

On 3/11/2021 10:34 AM, Michael Niedermayer wrote:

On Wed, Mar 10, 2021 at 06:25:58PM -0300, James Almer wrote:

On 3/10/2021 5:22 PM, Michael Niedermayer wrote:

On Sat, Mar 06, 2021 at 06:45:57PM -0300, James Almer wrote:

On 3/6/2021 6:35 PM, Michael Niedermayer wrote:

On Fri, Mar 05, 2021 at 01:33:36PM -0300, James Almer wrote:

Signed-off-by: James Almer 
---
doc/examples/vaapi_encode.c | 16 
1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/examples/vaapi_encode.c b/doc/examples/vaapi_encode.c
index 707939db37..66cb949cdc 100644
--- a/doc/examples/vaapi_encode.c
+++ b/doc/examples/vaapi_encode.c
@@ -74,27 +74,27 @@ static int set_hwframe_ctx(AVCodecContext *ctx, AVBufferRef 
*hw_device_ctx)
static int encode_write(AVCodecContext *avctx, AVFrame *frame, FILE *fout)
{
int ret = 0;
-AVPacket enc_pkt;
+AVPacket *enc_pkt;
-av_init_packet(_pkt);
-enc_pkt.data = NULL;
-enc_pkt.size = 0;
+if (!(enc_pkt = av_packet_alloc()))
+return AVERROR(ENOMEM);
if ((ret = avcodec_send_frame(avctx, frame)) < 0) {
fprintf(stderr, "Error code: %s\n", av_err2str(ret));
goto end;
}
while (1) {
-ret = avcodec_receive_packet(avctx, _pkt);
+ret = avcodec_receive_packet(avctx, enc_pkt);
if (ret)
break;
-enc_pkt.stream_index = 0;
-ret = fwrite(enc_pkt.data, enc_pkt.size, 1, fout);
-av_packet_unref(_pkt);
+enc_pkt->stream_index = 0;
+ret = fwrite(enc_pkt.data, enc_pkt->size, 1, fout);
+av_packet_unref(enc_pkt);
}
end:
+av_packet_free(_pkt);
ret = ((ret == AVERROR(EAGAIN)) ? 0 : -1);
return ret;
}


breaks:
doc/examples/vaapi_encode.c: In function ‘encode_write’:
doc/examples/vaapi_encode.c:92:29: error: ‘enc_pkt’ is a pointer; did you mean to 
use ‘->’?
ret = fwrite(enc_pkt.data, enc_pkt->size, 1, fout);
^
->
ffbuild/common.mak:67: recipe for target 'doc/examples/vaapi_encode.o' failed
make: *** [doc/examples/vaapi_encode.o] Error 1
make: *** Waiting for unfinished jobs


Fixed locally. Thanks.


do you have a public git tree for testing such minor changes ?
so i can retest the update set easily

thanks


Yes, pushed it to

https://github.com/jamrial/FFmpeg/commits/avpacket


seems to work now, thanks


Will rebase and apply the patchset soon, then, so we can release 4.4 
after it.

___
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".

Re: [FFmpeg-devel] [FFmpeg-web][PATCH] web/download: add signing key and verification instructions

[Thilo Borgmann]

Am 10.03.21 um 18:19 schrieb Thilo Borgmann:
> Am 10.03.21 um 09:25 schrieb Zane van Iperen:
>> Before you do, just give it a crack locally.
>>
>> I couldn't get the cloned version of the site to look identical to what's 
>> already published (something to do with incorrect CSS symlinks iirc). It's 
>> probably fine, but for something like this I'd rather err on the side of 
>> caution.
> 
> I know this problem and I'm happily ignoring it - because the style thingys 
> are living happily on the server and look like intended.
> 
> So I don't expect any problems. If so, its the website being a bit more ugly 
> for maybe some short time...
> Not doing it today anyway, so you can still test on if you feel the desire to 
> get a 1:1 website locally.

Pushed. I don't see any bad thing on ffmpeg.org, please check.

-Thilo
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] avformat/libsrt: fix setsockopt() typo

[myp...@gmail.com]

On Mon, Mar 15, 2021 at 5:06 PM Zhao Zhili  wrote:
>
> ---
>  libavformat/libsrt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index 233e9096fa..ac865c5658 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @@ -334,7 +334,7 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
>  (s->latency >= 0 && libsrt_setsockopt(h, fd, SRTO_LATENCY, 
> "SRTO_LATENCY", , sizeof(latency)) < 0) ||
>  (s->rcvlatency >= 0 && libsrt_setsockopt(h, fd, SRTO_RCVLATENCY, 
> "SRTO_RCVLATENCY", , sizeof(rcvlatency)) < 0) ||
>  (s->peerlatency >= 0 && libsrt_setsockopt(h, fd, SRTO_PEERLATENCY, 
> "SRTO_PEERLATENCY", , sizeof(peerlatency)) < 0) ||
> -(s->tlpktdrop >= 0 && libsrt_setsockopt(h, fd, SRTO_TLPKTDROP, 
> "SRTO_TLPKDROP", >tlpktdrop, sizeof(s->tlpktdrop)) < 0) ||
> +(s->tlpktdrop >= 0 && libsrt_setsockopt(h, fd, SRTO_TLPKTDROP, 
> "SRTO_TLPKTDROP", >tlpktdrop, sizeof(s->tlpktdrop)) < 0) ||

>  (s->nakreport >= 0 && libsrt_setsockopt(h, fd, SRTO_NAKREPORT, 
> "SRTO_NAKREPORT", >nakreport, sizeof(s->nakreport)) < 0) ||
>  (connect_timeout >= 0 && libsrt_setsockopt(h, fd, SRTO_CONNTIMEO, 
> "SRTO_CONNTIMEO", _timeout, sizeof(connect_timeout)) <0 ) ||
>  (s->sndbuf >= 0 && libsrt_setsockopt(h, fd, SRTO_SNDBUF, 
> "SRTO_SNDBUF", >sndbuf, sizeof(s->sndbuf)) < 0) ||
> --
Both of two patches LGTM
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avformat: Make AVChapter.id an int64_t on next major bump

[Anton Khirnov]

Quoting Andreas Rheinhardt (2021-03-16 10:34:22)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2021-03-16 09:29:53)
> >> 64 bits are needed in order to retain the uid values of Matroska
> >> chapters; the type is kept signed because the semantics of NUT chapters
> >> depend upon whether the id is > 0 or < 0.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >> Apologies for being so late.
> >>
> >>  doc/APIchanges| 4 
> >>  libavformat/aadec.c   | 2 +-
> >>  libavformat/avformat.h| 4 
> >>  libavformat/internal.h| 4 
> >>  libavformat/matroskaenc.c | 4 
> >>  libavformat/nutdec.c  | 4 ++--
> >>  libavformat/utils.c   | 4 
> >>  libavformat/version.h | 5 -
> >>  8 files changed, 27 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> index c0d955b1fa..8b93adebe1 100644
> >> --- a/doc/APIchanges
> >> +++ b/doc/APIchanges
> >> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
> >>  
> >>  API changes, most recent first:
> >>  
> >> +2021-03-16 - xx - lavf 58.75.100  - avformat.h
> >> +  AVChapter.id will be changed from int to int64_t
> >> +  on the next major version bump.
> >> +
> >>  2021-03-12 - xx - lavc 58.131.100 - avcodec.h codec.h
> >>Add a get_encode_buffer callback to AVCodecContext, similar to
> >>get_buffer2 but for encoders.
> >> diff --git a/libavformat/aadec.c b/libavformat/aadec.c
> >> index e88cdb89df..80ca2c12d7 100644
> >> --- a/libavformat/aadec.c
> >> +++ b/libavformat/aadec.c
> >> @@ -222,7 +222,7 @@ static int aa_read_header(AVFormatContext *s)
> >>  c->content_end = start + largest_size;
> >>  
> >>  while ((chapter_pos = avio_tell(pb)) >= 0 && chapter_pos < 
> >> c->content_end) {
> >> -int chapter_idx = s->nb_chapters;
> >> +unsigned chapter_idx = s->nb_chapters;
> > 
> > unrelated?
> > 
> The chapter ids created by aadec are just 0,1,... And in the
> hypothetical scenario that there are more than INT_MAX of them the
> INT_MAX+1U chapter would have a negative id if I didn't change it to
> unsigned above. (I don't think it can happen, but nb_chapters is an
> unsigned, so it is better anyway.)

Right, ok then.

-- 
Anton Khirnov
___
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".

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Add support for HEVC with Alpha.

[bouno]

Greetings,

Thank you for your help in advance.
Unfortunately, my patch, which add support the "HEVC with alpha" profile to the 
videotoolbox encoder, has not been reviewed for nearly three weeks. Would it be 
possible to give me why nobody has reviewed my patch?

Regards,

Hironori Bono
E-mail: bo...@rouge.plala.or.jp

-Original Message-
From: ffmpeg-devel  On Behalf Of 
bo...@rouge.plala.or.jp
Sent: Tuesday, February 23, 2021 2:02 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Hironori Bono 
Subject: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Add support for HEVC with 
Alpha.

From: Hironori Bono 

This change supports the "HEVC Video with Alpha" profile introduced in WWDC 
2019 . (This change is a 
partial fix for Ticket #7965.)

For example, the following command converts an animation PNG file to an HEVC 
with Alpha video:
./ffmpeg -i fate-suite/apng/clock.png -c:v hevc_videotoolbox -allow_sw 1 
-alpha_quality 0.75 -vtag hvc1 clock.mov

(This change uses the "HEVC Video with Alpha" profile only when the 
'-alpha_quality' value is not 0 for backward compatibility.)

Signed-off-by: Hironori Bono 
---
 configure|  2 ++
 libavcodec/videotoolboxenc.c | 47 +---
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 336301cb40..63adf131b9 100755
--- a/configure
+++ b/configure
@@ -2288,6 +2288,7 @@ TOOLCHAIN_FEATURES="
 
 TYPES_LIST="
 kCMVideoCodecType_HEVC
+kCMVideoCodecType_HEVCWithAlpha
 kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
 kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ
 kCVImageBufferTransferFunction_ITU_R_2100_HLG
@@ -6211,6 +6212,7 @@ enabled avfoundation && {  enabled videotoolbox && {
 check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
"-framework CoreServices"
 check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC 
"-framework CoreMedia"
+check_func_headers CoreMedia/CMFormatDescription.h 
kCMVideoCodecType_HEVCWithAlpha "-framework CoreMedia"
 check_func_headers CoreVideo/CVPixelBuffer.h 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
 check_func_headers CoreVideo/CVImageBuffer.h 
kCVImageBufferTransferFunction_SMPTE_ST_2084_PQ "-framework CoreVideo"
 check_func_headers CoreVideo/CVImageBuffer.h 
kCVImageBufferTransferFunction_ITU_R_2100_HLG "-framework CoreVideo"
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index 
c487d2dc60..9d3c7e29dc 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -40,6 +40,10 @@
 enum { kCMVideoCodecType_HEVC = 'hvc1' };  #endif
 
+#if !HAVE_KCMVIDEOCODECTYPE_HEVCWITHALPHA
+enum { kCMVideoCodecType_HEVCWithAlpha = 'muxa' }; #endif
+
 #if !HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
 enum { kCVPixelFormatType_420YpCbCr10BiPlanarFullRange = 'xf20' };  enum { 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange = 'x420' }; @@ -88,6 +92,7 @@ 
static struct{
 CFStringRef kVTProfileLevel_HEVC_Main10_AutoLevel;
 
 CFStringRef kVTCompressionPropertyKey_RealTime;
+CFStringRef kVTCompressionPropertyKey_TargetQualityForAlpha;
 
 CFStringRef 
kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder;
 CFStringRef 
kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder;
@@ -147,6 +152,8 @@ static void loadVTEncSymbols(){
 GET_SYM(kVTProfileLevel_HEVC_Main10_AutoLevel,   "HEVC_Main10_AutoLevel");
 
 GET_SYM(kVTCompressionPropertyKey_RealTime, "RealTime");
+GET_SYM(kVTCompressionPropertyKey_TargetQualityForAlpha,
+"TargetQualityForAlpha");
 
 GET_SYM(kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder,
 "EnableHardwareAcceleratedVideoEncoder");
@@ -222,6 +229,7 @@ typedef struct VTEncContext {
 
 int64_t allow_sw;
 int64_t require_sw;
+double alpha_quality;
 
 bool flushing;
 bool has_b_frames;
@@ -392,11 +400,17 @@ static int count_nalus(size_t length_code_size,
 return 0;
 }
 
-static CMVideoCodecType get_cm_codec_type(enum AVCodecID id)
+static CMVideoCodecType get_cm_codec_type(enum AVCodecID id,
+  enum AVPixelFormat fmt,
+  double alpha_quality)
 {
 switch (id) {
 case AV_CODEC_ID_H264: return kCMVideoCodecType_H264;
-case AV_CODEC_ID_HEVC: return kCMVideoCodecType_HEVC;
+case AV_CODEC_ID_HEVC:
+if (fmt == AV_PIX_FMT_BGRA && alpha_quality > 0.0) {
+return kCMVideoCodecType_HEVCWithAlpha;
+}
+return kCMVideoCodecType_HEVC;
 default:   return 0;
 }
 }
@@ -786,6 +800,8 @@ static int get_cv_pixel_format(AVCodecContext* avctx,
 *av_pixel_format = range == AVCOL_RANGE_JPEG ?
 
kCVPixelFormatType_420YpCbCr8PlanarFullRange :

Re: [FFmpeg-devel] [PATCH 1/7] lavc: factor out encoder init/validation from avcodec_open2()

[Anton Khirnov]

Quoting James Almer (2021-03-10 16:17:35)
> On 3/10/2021 9:03 AM, Anton Khirnov wrote:
> > avcodec_open2() is massive, splitting it makes it more readable.
> > 
> > Also, add a missing error code to ticks_per_frame sanity check.
> > ---
> >   libavcodec/encode.c | 157 +
> >   libavcodec/encode.h |   6 ++
> >   libavcodec/utils.c  | 166 +---
> >   3 files changed, 166 insertions(+), 163 deletions(-)
> > 
> > diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> > index 282337e453..bbf03d62fc 100644
> > --- a/libavcodec/encode.c
> > +++ b/libavcodec/encode.c
> > @@ -462,3 +462,160 @@ int attribute_align_arg 
> > avcodec_encode_video2(AVCodecContext *avctx,
> >   return ret;
> >   }
> >   #endif
> > +
> > +int ff_encode_preinit(AVCodecContext *avctx)
> 
> nit: Would prefer if this and ff_decode_preinit() could stay in the same 
> file as avcodec_open2() as static functions. This includes moving 
> decode_bsfs_init() there, too.
> decode.c and encode.c seem to me that they should contain functions used 
> during decoding and encoding, and not initialization.

For the record: discussed this on IRC and James dropped his objection to
the move

> 
> That being said, not related to this set and not really a priority, but 
> avcodec_open2() is not a "utility" function as much as a core lavc 
> function. av_get_bits_per_sample() for example is a util, as are 
> av_get_audio_frame_duration() and avcodec_align_dimensions2(). So 
> perhaps it, avcodec_alloc_context3() and avcodec_free_context() should 
> be together (options.c is also not exactly the best name for the file 
> currently hosting the latter two, so maybe it could be renamed to 
> avcodec.c while at it).

I would certainly be in favor of that. utils.c is way too huge.

-- 
Anton Khirnov
___
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".

[FFmpeg-devel] Re: [PATCH] cmdutils: replace strncpy() with direct assignment

[Anton Khirnov]

No further comments, so set pushed.

-- 
Anton Khirnov
___
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".

Re: [FFmpeg-devel] [PATCH] lavc: replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap

[Anton Khirnov]

No further comments, so set pushed.

-- 
Anton Khirnov
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avformat: Make AVChapter.id an int64_t on next major bump

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-03-16 09:29:53)
>> 64 bits are needed in order to retain the uid values of Matroska
>> chapters; the type is kept signed because the semantics of NUT chapters
>> depend upon whether the id is > 0 or < 0.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> Apologies for being so late.
>>
>>  doc/APIchanges| 4 
>>  libavformat/aadec.c   | 2 +-
>>  libavformat/avformat.h| 4 
>>  libavformat/internal.h| 4 
>>  libavformat/matroskaenc.c | 4 
>>  libavformat/nutdec.c  | 4 ++--
>>  libavformat/utils.c   | 4 
>>  libavformat/version.h | 5 -
>>  8 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index c0d955b1fa..8b93adebe1 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
>>  
>>  API changes, most recent first:
>>  
>> +2021-03-16 - xx - lavf 58.75.100  - avformat.h
>> +  AVChapter.id will be changed from int to int64_t
>> +  on the next major version bump.
>> +
>>  2021-03-12 - xx - lavc 58.131.100 - avcodec.h codec.h
>>Add a get_encode_buffer callback to AVCodecContext, similar to
>>get_buffer2 but for encoders.
>> diff --git a/libavformat/aadec.c b/libavformat/aadec.c
>> index e88cdb89df..80ca2c12d7 100644
>> --- a/libavformat/aadec.c
>> +++ b/libavformat/aadec.c
>> @@ -222,7 +222,7 @@ static int aa_read_header(AVFormatContext *s)
>>  c->content_end = start + largest_size;
>>  
>>  while ((chapter_pos = avio_tell(pb)) >= 0 && chapter_pos < 
>> c->content_end) {
>> -int chapter_idx = s->nb_chapters;
>> +unsigned chapter_idx = s->nb_chapters;
> 
> unrelated?
> 
The chapter ids created by aadec are just 0,1,... And in the
hypothetical scenario that there are more than INT_MAX of them the
INT_MAX+1U chapter would have a negative id if I didn't change it to
unsigned above. (I don't think it can happen, but nb_chapters is an
unsigned, so it is better anyway.)

- Andreas
___
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".

Re: [FFmpeg-devel] [PATCH] doc/encoders: remove text about single bit-depth libx264 support

[Tobias Rapp]

On 15.03.2021 17:19, Gyan Doshi wrote:



On 2021-03-15 18:54, Tobias Rapp wrote:
In the meanwhile libx264 allows to be configured for including both 
8/10 bit

support within a single library. The new libx264 interface was enabled in
2f96190732d15510ba29471fa45d66841c0c3df1.

Signed-off-by: Tobias Rapp 
---
  doc/encoders.texi | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index c9c8785a..a92eb0e 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2305,9 +2305,7 @@ pixel formats as input instead of YUV.
  @subsection Supported Pixel Formats
  x264 supports 8- to 10-bit color spaces. The exact bit depth is 
controlled at
-x264's configure time. FFmpeg only supports one bit depth in one 
particular
-build. In other words, it is not possible to build one FFmpeg with 
multiple

-versions of x264 with different bit depths.
+x264's configure time.
  @subsection Options


LGTM.



Pushed, thanks for review.

Tobias

___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avformat: Make AVChapter.id an int64_t on next major bump

[Anton Khirnov]

Quoting Andreas Rheinhardt (2021-03-16 09:29:53)
> 64 bits are needed in order to retain the uid values of Matroska
> chapters; the type is kept signed because the semantics of NUT chapters
> depend upon whether the id is > 0 or < 0.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Apologies for being so late.
> 
>  doc/APIchanges| 4 
>  libavformat/aadec.c   | 2 +-
>  libavformat/avformat.h| 4 
>  libavformat/internal.h| 4 
>  libavformat/matroskaenc.c | 4 
>  libavformat/nutdec.c  | 4 ++--
>  libavformat/utils.c   | 4 
>  libavformat/version.h | 5 -
>  8 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index c0d955b1fa..8b93adebe1 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2021-03-16 - xx - lavf 58.75.100  - avformat.h
> +  AVChapter.id will be changed from int to int64_t
> +  on the next major version bump.
> +
>  2021-03-12 - xx - lavc 58.131.100 - avcodec.h codec.h
>Add a get_encode_buffer callback to AVCodecContext, similar to
>get_buffer2 but for encoders.
> diff --git a/libavformat/aadec.c b/libavformat/aadec.c
> index e88cdb89df..80ca2c12d7 100644
> --- a/libavformat/aadec.c
> +++ b/libavformat/aadec.c
> @@ -222,7 +222,7 @@ static int aa_read_header(AVFormatContext *s)
>  c->content_end = start + largest_size;
>  
>  while ((chapter_pos = avio_tell(pb)) >= 0 && chapter_pos < 
> c->content_end) {
> -int chapter_idx = s->nb_chapters;
> +unsigned chapter_idx = s->nb_chapters;

unrelated?

-- 
Anton Khirnov
___
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".

[FFmpeg-devel] [PATCH v3] avformat/pp_bnk: treat music files as stereo

[Zane van Iperen]

These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:

  [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]

Signed-off-by: Zane van Iperen 
---
 libavformat/pp_bnk.c | 52 ++--
 1 file changed, 45 insertions(+), 7 deletions(-)

diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
index 8364de1fd9..4aa77c1c9d 100644
--- a/libavformat/pp_bnk.c
+++ b/libavformat/pp_bnk.c
@@ -55,6 +55,7 @@ typedef struct PPBnkCtx {
 int track_count;
 PPBnkCtxTrack   *tracks;
 uint32_tcurrent_track;
+int is_music;
 } PPBnkCtx;
 
 enum {
@@ -194,8 +195,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
 goto fail;
 }
 
+ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
+(ctx->track_count == 2) &&
+(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
+
 /* Build the streams. */
-for (int i = 0; i < ctx->track_count; i++) {
+for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
 if (!(st = avformat_new_stream(s, NULL))) {
 ret = AVERROR(ENOMEM);
 goto fail;
@@ -204,14 +209,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
 par = st->codecpar;
 par->codec_type = AVMEDIA_TYPE_AUDIO;
 par->codec_id   = AV_CODEC_ID_ADPCM_IMA_CUNNING;
-par->format = AV_SAMPLE_FMT_S16;
-par->channel_layout = AV_CH_LAYOUT_MONO;
-par->channels   = 1;
+par->format = AV_SAMPLE_FMT_S16P;
+
+if (ctx->is_music) {
+par->channel_layout = AV_CH_LAYOUT_STEREO;
+par->channels   = 2;
+} else {
+par->channel_layout = AV_CH_LAYOUT_MONO;
+par->channels   = 1;
+}
+
 par->sample_rate= hdr.sample_rate;
 par->bits_per_coded_sample  = 4;
 par->bits_per_raw_sample= 16;
 par->block_align= 1;
-par->bit_rate   = par->sample_rate * 
par->bits_per_coded_sample;
+par->bit_rate   = par->sample_rate * 
par->bits_per_coded_sample * par->channels;
 
 avpriv_set_pts_info(st, 64, 1, par->sample_rate);
 st->start_time  = 0;
@@ -253,7 +265,22 @@ static int pp_bnk_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
 
-if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
+if (!ctx->is_music)
+ret = av_new_packet(pkt, size);
+else if (ctx->current_track == 0)
+ret = av_new_packet(pkt, size * 2);
+else
+ret = 0;
+
+if (ret < 0)
+return ret;
+
+if (ctx->is_music)
+ret = avio_read(s->pb, pkt->data + size * ctx->current_track, 
size);
+else
+ret = avio_read(s->pb, pkt->data, size);
+
+if (ret == AVERROR_EOF) {
 /* If we've hit EOF, don't attempt this track again. */
 trk->data_size = trk->bytes_read;
 continue;
@@ -263,8 +290,19 @@ static int pp_bnk_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 trk->bytes_read+= ret;
 pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
-pkt->stream_index   = ctx->current_track++;
+pkt->stream_index   = ctx->current_track;
 pkt->duration   = ret * 2;
+
+if (ctx->is_music) {
+if (pkt->stream_index == 0)
+continue;
+
+pkt->stream_index = 0;
+} else {
+pkt->size = ret;
+}
+
+ctx->current_track++;
 return 0;
 }
 
-- 
2.29.3

___
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/pp_bnk: treat music files are stereo

[Moritz Barsnick]

On Tue, Mar 16, 2021 at 18:30:19 +1000, Zane van Iperen wrote:

Nit:

> Subject: avformat/pp_bnk: treat music files are stereo
  ^ as

Moritz
___
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/pp_bnk: treat music files are stereo

[Andreas Rheinhardt]

Zane van Iperen:
> 
> 
> On 16/3/21 6:40 pm, Andreas Rheinhardt wrote:
> 
>>> +
>>> +    if (ctx->is_music) {
>>> +    if (pkt->stream_index == 0) {
>>> +    ctx->current_track--;
>>
>> I have to admit to be confused by this. Won't this imply that
>> ctx->current_track will always be zero for music files until you hit the
>> bytes_read == data_size check and that you just overwrite and therefore
>> leak the already allocated packets?
>>
> 
> No, because it's a continue instead of a return, I need to counteract the
> "ctx->current_track++" in the above for(;;).

I didn't think about that; I only saw pkt->stream_index   =
ctx->current_track++;.

- Andreas
___
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/pp_bnk: treat music files are stereo

[Zane van Iperen]

On 16/3/21 6:47 pm, Zane van Iperen wrote:



On 16/3/21 6:40 pm, Andreas Rheinhardt wrote:


+
+    if (ctx->is_music) {
+    if (pkt->stream_index == 0) {
+    ctx->current_track--;


I have to admit to be confused by this. Won't this imply that
ctx->current_track will always be zero for music files until you hit the
bytes_read == data_size check and that you just overwrite and therefore
leak the already allocated packets?



No, because it's a continue instead of a return, I need to counteract the
"ctx->current_track++" in the above for(;;).


Forgot to mention, it's also incremented immediately above:

  pkt->stream_index   = ctx->current_track++;

...Yeah, I might clean this up a bit.
___
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/pp_bnk: treat music files are stereo

[Zane van Iperen]

On 16/3/21 6:40 pm, Andreas Rheinhardt wrote:


+
+if (ctx->is_music) {
+if (pkt->stream_index == 0) {
+ctx->current_track--;


I have to admit to be confused by this. Won't this imply that
ctx->current_track will always be zero for music files until you hit the
bytes_read == data_size check and that you just overwrite and therefore
leak the already allocated packets?



No, because it's a continue instead of a return, I need to counteract the
"ctx->current_track++" in the above for(;;).
___
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/pp_bnk: treat music files are stereo

[Andreas Rheinhardt]

Zane van Iperen:
> These files are technically a series of planar mono tracks.
> If the "music" flag is set, merge the packets from the two
> mono tracks, essentially replicating:
> 
>   [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
> 
> Signed-off-by: Zane van Iperen 
> ---
>  libavformat/pp_bnk.c | 51 ++--
>  1 file changed, 45 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
> index 8364de1fd9..eba53a01a3 100644
> --- a/libavformat/pp_bnk.c
> +++ b/libavformat/pp_bnk.c
> @@ -55,6 +55,7 @@ typedef struct PPBnkCtx {
>  int track_count;
>  PPBnkCtxTrack   *tracks;
>  uint32_tcurrent_track;
> +int is_music;
>  } PPBnkCtx;
>  
>  enum {
> @@ -194,8 +195,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
>  goto fail;
>  }
>  
> +ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
> +(ctx->track_count == 2) &&
> +(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
> +
>  /* Build the streams. */
> -for (int i = 0; i < ctx->track_count; i++) {
> +for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
>  if (!(st = avformat_new_stream(s, NULL))) {
>  ret = AVERROR(ENOMEM);
>  goto fail;
> @@ -204,14 +209,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
>  par = st->codecpar;
>  par->codec_type = AVMEDIA_TYPE_AUDIO;
>  par->codec_id   = AV_CODEC_ID_ADPCM_IMA_CUNNING;
> -par->format = AV_SAMPLE_FMT_S16;
> -par->channel_layout = AV_CH_LAYOUT_MONO;
> -par->channels   = 1;
> +par->format = AV_SAMPLE_FMT_S16P;
> +
> +if (ctx->is_music) {
> +par->channel_layout = AV_CH_LAYOUT_STEREO;
> +par->channels   = 2;
> +} else {
> +par->channel_layout = AV_CH_LAYOUT_MONO;
> +par->channels   = 1;
> +}
> +
>  par->sample_rate= hdr.sample_rate;
>  par->bits_per_coded_sample  = 4;
>  par->bits_per_raw_sample= 16;
>  par->block_align= 1;
> -par->bit_rate   = par->sample_rate * 
> par->bits_per_coded_sample;
> +par->bit_rate   = par->sample_rate * 
> par->bits_per_coded_sample * par->channels;
>  
>  avpriv_set_pts_info(st, 64, 1, par->sample_rate);
>  st->start_time  = 0;
> @@ -253,7 +265,22 @@ static int pp_bnk_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
>  
> -if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
> +if (!ctx->is_music)
> +ret = av_new_packet(pkt, size);
> +else if (ctx->current_track == 0)
> +ret = av_new_packet(pkt, size * 2);
> +else
> +ret = 0;
> +
> +if (ret < 0)
> +return ret;
> +
> +if (ctx->is_music)
> +ret = avio_read(s->pb, pkt->data + size * ctx->current_track, 
> size);
> +else
> +ret = avio_read(s->pb, pkt->data, size);
> +
> +if (ret == AVERROR_EOF) {
>  /* If we've hit EOF, don't attempt this track again. */
>  trk->data_size = trk->bytes_read;
>  continue;
> @@ -265,6 +292,18 @@ static int pp_bnk_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
>  pkt->stream_index   = ctx->current_track++;
>  pkt->duration   = ret * 2;
> +
> +if (ctx->is_music) {
> +if (pkt->stream_index == 0) {
> +ctx->current_track--;

I have to admit to be confused by this. Won't this imply that
ctx->current_track will always be zero for music files until you hit the
bytes_read == data_size check and that you just overwrite and therefore
leak the already allocated packets?

> +continue;
> +}
> +
> +pkt->stream_index = 0;
> +} else {
> +pkt->size = ret;
> +}
> +
>  return 0;
>  }
>  
> 

___
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".

[FFmpeg-devel] [PATCH 2/2] avformat: Make AVChapter.id an int64_t on next major bump

[Andreas Rheinhardt]

64 bits are needed in order to retain the uid values of Matroska
chapters; the type is kept signed because the semantics of NUT chapters
depend upon whether the id is > 0 or < 0.

Signed-off-by: Andreas Rheinhardt 
---
Apologies for being so late.

 doc/APIchanges| 4 
 libavformat/aadec.c   | 2 +-
 libavformat/avformat.h| 4 
 libavformat/internal.h| 4 
 libavformat/matroskaenc.c | 4 
 libavformat/nutdec.c  | 4 ++--
 libavformat/utils.c   | 4 
 libavformat/version.h | 5 -
 8 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index c0d955b1fa..8b93adebe1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2021-03-16 - xx - lavf 58.75.100  - avformat.h
+  AVChapter.id will be changed from int to int64_t
+  on the next major version bump.
+
 2021-03-12 - xx - lavc 58.131.100 - avcodec.h codec.h
   Add a get_encode_buffer callback to AVCodecContext, similar to
   get_buffer2 but for encoders.
diff --git a/libavformat/aadec.c b/libavformat/aadec.c
index e88cdb89df..80ca2c12d7 100644
--- a/libavformat/aadec.c
+++ b/libavformat/aadec.c
@@ -222,7 +222,7 @@ static int aa_read_header(AVFormatContext *s)
 c->content_end = start + largest_size;
 
 while ((chapter_pos = avio_tell(pb)) >= 0 && chapter_pos < c->content_end) 
{
-int chapter_idx = s->nb_chapters;
+unsigned chapter_idx = s->nb_chapters;
 uint32_t chapter_size = avio_rb32(pb);
 if (chapter_size == 0 || avio_feof(pb))
 break;
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index e3bd01ec7f..765bc3b6f5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1184,7 +1184,11 @@ typedef struct AVProgram {
  change dynamically at runtime. */
 
 typedef struct AVChapter {
+#if FF_API_CHAPTER_ID_INT
 int id; ///< unique ID to identify the chapter
+#else
+int64_t id; ///< unique ID to identify the chapter
+#endif
 AVRational time_base;   ///< time base in which the start/end timestamps 
are specified
 int64_t start, end; ///< chapter start/end time in time_base units
 AVDictionary *metadata;
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 0ffdc87b6a..df4918e318 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -554,7 +554,11 @@ void ff_configure_buffers_for_index(AVFormatContext *s, 
int64_t time_tolerance);
  *
  * @return AVChapter or NULL on error
  */
+#if FF_API_CHAPTER_ID_INT
 AVChapter *avpriv_new_chapter(AVFormatContext *s, int id, AVRational time_base,
+#else
+AVChapter *avpriv_new_chapter(AVFormatContext *s, int64_t id, AVRational 
time_base,
+#endif
   int64_t start, int64_t end, const char *title);
 
 /**
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 8f29d64e72..02e171593e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1669,7 +1669,11 @@ static int mkv_write_chapters(AVFormatContext *s)
 int64_t chapterstart = av_rescale_q(c->start, c->time_base, scale);
 int64_t chapterend   = av_rescale_q(c->end,   c->time_base, scale);
 const AVDictionaryEntry *t;
+#if FF_API_CHAPTER_ID_INT
 uint64_t uid = create_new_ids ? i + 1ULL : (uint32_t)c->id;
+#else
+uint64_t uid = create_new_ids ? i + 1ULL : c->id;
+#endif
 if (chapterstart < 0 || chapterstart > chapterend || chapterend < 0) {
 av_log(s, AV_LOG_ERROR,
"Invalid chapter start (%"PRId64") or end (%"PRId64").\n",
diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index ebb062377d..d1f3496990 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -489,8 +489,8 @@ static int decode_info_header(NUTContext *nut)
 AVIOContext *bc= s->pb;
 uint64_t tmp, chapter_start, chapter_len;
 unsigned int stream_id_plus1, count;
-int chapter_id, i, ret = 0;
-int64_t value, end;
+int i, ret = 0;
+int64_t chapter_id, value, end;
 char name[256], str_value[1024], type_str[256];
 const char *type;
 int *event_flags= NULL;
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8573117694..8fb5dbbf9d 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4611,7 +4611,11 @@ AVProgram *av_new_program(AVFormatContext *ac, int id)
 return program;
 }
 
+#if FF_API_CHAPTER_ID_INT
 AVChapter *avpriv_new_chapter(AVFormatContext *s, int id, AVRational time_base,
+#else
+AVChapter *avpriv_new_chapter(AVFormatContext *s, int64_t id, AVRational 
time_base,
+#endif
   int64_t start, int64_t end, const char *title)
 {
 AVChapter *chapter = NULL;
diff --git a/libavformat/version.h b/libavformat/version.h
index e43754b069..ca1cd1a920 100644
--- a/libavformat/version.h
+++ 

[FFmpeg-devel] [PATCH v2] avformat/pp_bnk: treat music files are stereo

[Zane van Iperen]

These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:

  [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]

Signed-off-by: Zane van Iperen 
---
 libavformat/pp_bnk.c | 51 ++--
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
index 8364de1fd9..eba53a01a3 100644
--- a/libavformat/pp_bnk.c
+++ b/libavformat/pp_bnk.c
@@ -55,6 +55,7 @@ typedef struct PPBnkCtx {
 int track_count;
 PPBnkCtxTrack   *tracks;
 uint32_tcurrent_track;
+int is_music;
 } PPBnkCtx;
 
 enum {
@@ -194,8 +195,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
 goto fail;
 }
 
+ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
+(ctx->track_count == 2) &&
+(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
+
 /* Build the streams. */
-for (int i = 0; i < ctx->track_count; i++) {
+for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
 if (!(st = avformat_new_stream(s, NULL))) {
 ret = AVERROR(ENOMEM);
 goto fail;
@@ -204,14 +209,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
 par = st->codecpar;
 par->codec_type = AVMEDIA_TYPE_AUDIO;
 par->codec_id   = AV_CODEC_ID_ADPCM_IMA_CUNNING;
-par->format = AV_SAMPLE_FMT_S16;
-par->channel_layout = AV_CH_LAYOUT_MONO;
-par->channels   = 1;
+par->format = AV_SAMPLE_FMT_S16P;
+
+if (ctx->is_music) {
+par->channel_layout = AV_CH_LAYOUT_STEREO;
+par->channels   = 2;
+} else {
+par->channel_layout = AV_CH_LAYOUT_MONO;
+par->channels   = 1;
+}
+
 par->sample_rate= hdr.sample_rate;
 par->bits_per_coded_sample  = 4;
 par->bits_per_raw_sample= 16;
 par->block_align= 1;
-par->bit_rate   = par->sample_rate * 
par->bits_per_coded_sample;
+par->bit_rate   = par->sample_rate * 
par->bits_per_coded_sample * par->channels;
 
 avpriv_set_pts_info(st, 64, 1, par->sample_rate);
 st->start_time  = 0;
@@ -253,7 +265,22 @@ static int pp_bnk_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
 
-if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
+if (!ctx->is_music)
+ret = av_new_packet(pkt, size);
+else if (ctx->current_track == 0)
+ret = av_new_packet(pkt, size * 2);
+else
+ret = 0;
+
+if (ret < 0)
+return ret;
+
+if (ctx->is_music)
+ret = avio_read(s->pb, pkt->data + size * ctx->current_track, 
size);
+else
+ret = avio_read(s->pb, pkt->data, size);
+
+if (ret == AVERROR_EOF) {
 /* If we've hit EOF, don't attempt this track again. */
 trk->data_size = trk->bytes_read;
 continue;
@@ -265,6 +292,18 @@ static int pp_bnk_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
 pkt->stream_index   = ctx->current_track++;
 pkt->duration   = ret * 2;
+
+if (ctx->is_music) {
+if (pkt->stream_index == 0) {
+ctx->current_track--;
+continue;
+}
+
+pkt->stream_index = 0;
+} else {
+pkt->size = ret;
+}
+
 return 0;
 }
 
-- 
2.29.3

___
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".

[FFmpeg-devel] [PATCH 1/2] avformat/matroskaenc: Check chapter ids for duplicates

[Andreas Rheinhardt]

Up until now, there has been no check that each chapter has a unique id;
there was only a check for whether a chapter id is zero (this happens
often when the chapters originated from a format that lacks the concept
of chapter id and simply counts from zero) which is invalid in Matroska.
In this case the chapter ids are offset by 1 to make them nonnegative.
Yet offsetting won't fix duplicate ids, therefore this is changed to
simply create new chapter uids when the input chapter uids don't conform
to the requirements of Matroska (in which case it can be presumed that
they did not originate from Matroska, so that we don't need to bother
to preserve them).

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/matroskaenc.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 1749b7fd37..8f29d64e72 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1625,24 +1625,29 @@ static int mkv_write_tags(AVFormatContext *s)
 return 0;
 }
 
+static int mkv_new_chapter_ids_needed(const AVFormatContext *s)
+{
+for (unsigned i = 0; i < s->nb_chapters; i++) {
+if (!s->chapters[i]->id)
+return 1;
+for (unsigned j = 0; j < i; j++)
+if (s->chapters[j]->id == s->chapters[i]->id)
+return 1;
+}
+return 0;
+}
+
 static int mkv_write_chapters(AVFormatContext *s)
 {
 MatroskaMuxContext *mkv = s->priv_data;
 AVIOContext *dyn_cp = NULL, *dyn_tags = NULL, **tags, *pb = s->pb;
 ebml_master editionentry;
-uint64_t chapter_id_offset = 0;
 AVRational scale = {1, 1E9};
-int i, ret;
+int ret, create_new_ids;
 
 if (!s->nb_chapters || mkv->wrote_chapters)
 return 0;
 
-for (i = 0; i < s->nb_chapters; i++)
-if (!s->chapters[i]->id) {
-chapter_id_offset = 1;
-break;
-}
-
 ret = start_ebml_master_crc32(_cp, mkv);
 if (ret < 0)
 return ret;
@@ -1656,12 +1661,15 @@ static int mkv_write_chapters(AVFormatContext *s)
 } else
 tags = NULL;
 
-for (i = 0; i < s->nb_chapters; i++) {
+create_new_ids = mkv_new_chapter_ids_needed(s);
+
+for (unsigned i = 0; i < s->nb_chapters; i++) {
 ebml_master chapteratom, chapterdisplay;
 const AVChapter *c   = s->chapters[i];
 int64_t chapterstart = av_rescale_q(c->start, c->time_base, scale);
 int64_t chapterend   = av_rescale_q(c->end,   c->time_base, scale);
 const AVDictionaryEntry *t;
+uint64_t uid = create_new_ids ? i + 1ULL : (uint32_t)c->id;
 if (chapterstart < 0 || chapterstart > chapterend || chapterend < 0) {
 av_log(s, AV_LOG_ERROR,
"Invalid chapter start (%"PRId64") or end (%"PRId64").\n",
@@ -1671,8 +1679,7 @@ static int mkv_write_chapters(AVFormatContext *s)
 }
 
 chapteratom = start_ebml_master(dyn_cp, MATROSKA_ID_CHAPTERATOM, 0);
-put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERUID,
-  (uint32_t)c->id + chapter_id_offset);
+put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERUID, uid);
 put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERTIMESTART, chapterstart);
 put_ebml_uint(dyn_cp, MATROSKA_ID_CHAPTERTIMEEND, chapterend);
 if ((t = av_dict_get(c->metadata, "title", NULL, 0))) {
@@ -1685,8 +1692,7 @@ static int mkv_write_chapters(AVFormatContext *s)
 
 if (tags && mkv_check_tag(c->metadata, 
MATROSKA_ID_TAGTARGETS_CHAPTERUID)) {
 ret = mkv_write_tag(mkv, c->metadata, tags, NULL,
-MATROSKA_ID_TAGTARGETS_CHAPTERUID,
-(uint32_t)c->id + chapter_id_offset);
+MATROSKA_ID_TAGTARGETS_CHAPTERUID, uid);
 if (ret < 0)
 goto fail;
 }
-- 
2.27.0

___
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".

Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder

[Florian Nouwt]

Why would those equations not make sense?? I literally looked the top two
up on wikipedia. And the bottom one was reverse engineered from the ds
decoder and I verified it to be accurate for this codec.
I too think that converting to rgb is not the most elegant solution, but it
would be better than just wrong colors I think.

Op di 16 mrt. 2021 08:55 schreef Paul B Mahol :

> On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt  wrote:
>
> > It's actually closer to normal yuv than ycocg. If you look at the
> > coefficients of normal yuv
> > r = y + 1.14v
> > g = y - 0.39u - 0.58v
> > b = y + 2.03u
> >
> > ycocg
> > r = y + co - cg
> > g = y + cg
> > b = y - co - cg
> >
> > the format used in actimagine
> > r = y + 2v
> > g = y - 0.5u - v
> > b = y + 2u
> >
>
>
> Something is very wrong with those equations.
> They do not have sense.
>
> Next time make sure to use real player like mpv, and set frame color_space
> to ycgco or ycocg.
>
>
> > You can see it's more like yuv than ycocg. That's also why currently the
> > decoded colors still look "alright". I think it wouldn't be a good idea
> to
> > use converted ref frames and then convert back as it would likely
> introduce
> > errors. But like you are saying, this coded is as far as I know, never
> used
> > for large frame sizes, so it shouldn't really be an issue to have an
> extra
> > frame and it prevents other problems.
> >
> > Op ma 15 mrt. 2021 21:42 schreef Lynne :
> >
> > > Mar 15, 2021, 21:20 by fnou...@gmail.com:
> > >
> > > > Good to know the order doesn't matter. In that case I should be able
> to
> > > use
> > > > it!
> > > >
> > > > I don't have any docs about the format because it's all proprietary,
> > but
> > > I
> > > > did some testing with the official codec for windows and the color
> > > > conversion I reverse engineered from the decoder used in ds games
> > > > r = y + (v << 1)
> > > > g = y - (u >> 1) - v
> > > > b = y + (u << 1)
> > > > results in colors that are equal to whatever I throw into the codec
> and
> > > > frames that are 1:1 equal to the output of the decoder included in
> the
> > > > windows codec.
> > > >
> > >
> > > That's looking really close to YCoCg. In fact it probably is just a
> > > variant of
> > > YCoCg. You should be able to convert between both with no loss of
> quality
> > > or rounding errors and just mark the output frame as being YUV with a
> > > YCoCg colorspace. The wikipedia page on YCoCg has RGB<->YCoCg
> > > conversions you can follow.
> > >
> > >
> > > > I suppose that I would just have to allocate an extra frame if I
> wanted
> > > to
> > > > do conversion to normal yuv colors. That frame would then be returned
> > and
> > > > the original frame would be put in the ref queue.
> > > >
> > >
> > > You could implement an inverse step when you use the reference frames,
> > > but for such a codec, where the frame size is going to be comparitively
> > > tiny, I think you can just get away quicker with copying and the
> > converting
> > > the copied frame, while keeping your ref frames as-is.
> > > ___
> > > 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".
> > ___
> > 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".
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder

[Paul B Mahol]

On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt  wrote:

> It's actually closer to normal yuv than ycocg. If you look at the
> coefficients of normal yuv
> r = y + 1.14v
> g = y - 0.39u - 0.58v
> b = y + 2.03u
>
> ycocg
> r = y + co - cg
> g = y + cg
> b = y - co - cg
>
> the format used in actimagine
> r = y + 2v
> g = y - 0.5u - v
> b = y + 2u
>


Something is very wrong with those equations.
They do not have sense.

Next time make sure to use real player like mpv, and set frame color_space
to ycgco or ycocg.


> You can see it's more like yuv than ycocg. That's also why currently the
> decoded colors still look "alright". I think it wouldn't be a good idea to
> use converted ref frames and then convert back as it would likely introduce
> errors. But like you are saying, this coded is as far as I know, never used
> for large frame sizes, so it shouldn't really be an issue to have an extra
> frame and it prevents other problems.
>
> Op ma 15 mrt. 2021 21:42 schreef Lynne :
>
> > Mar 15, 2021, 21:20 by fnou...@gmail.com:
> >
> > > Good to know the order doesn't matter. In that case I should be able to
> > use
> > > it!
> > >
> > > I don't have any docs about the format because it's all proprietary,
> but
> > I
> > > did some testing with the official codec for windows and the color
> > > conversion I reverse engineered from the decoder used in ds games
> > > r = y + (v << 1)
> > > g = y - (u >> 1) - v
> > > b = y + (u << 1)
> > > results in colors that are equal to whatever I throw into the codec and
> > > frames that are 1:1 equal to the output of the decoder included in the
> > > windows codec.
> > >
> >
> > That's looking really close to YCoCg. In fact it probably is just a
> > variant of
> > YCoCg. You should be able to convert between both with no loss of quality
> > or rounding errors and just mark the output frame as being YUV with a
> > YCoCg colorspace. The wikipedia page on YCoCg has RGB<->YCoCg
> > conversions you can follow.
> >
> >
> > > I suppose that I would just have to allocate an extra frame if I wanted
> > to
> > > do conversion to normal yuv colors. That frame would then be returned
> and
> > > the original frame would be put in the ref queue.
> > >
> >
> > You could implement an inverse step when you use the reference frames,
> > but for such a codec, where the frame size is going to be comparitively
> > tiny, I think you can just get away quicker with copying and the
> converting
> > the copied frame, while keeping your ref frames as-is.
> > ___
> > 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".
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder

[Paul B Mahol]

On Tue, Mar 16, 2021 at 8:22 AM Florian Nouwt  wrote:

> Alright, I'll just convert to rgb then. Both the windows codec and the ds
> decoder decode the subsampling by simply duplicating the u/v samples within
> a 2x2 block (no interpolation). Should I do that too? Or would
> interpolation be preferred? As far as I was able to see the windows codec
> takes the average of 2x2 blocks to create the subsampled data.
>

That is unacceptable non-solution.


>
> Op ma 15 mrt. 2021 23:35 schreef Hendrik Leppkes :
>
> > On Mon, Mar 15, 2021 at 10:55 PM Florian Nouwt 
> wrote:
> > >
> > > Now that I think about it, it might not be possible to an accurate
> > > straightforward conversion to regular yuv because of the subsampling.
> > The u
> > > and v cannot just linearly be scaled to line up with the required
> values
> > > for regular yuv. That would mean the output would have to be in rgb
> > format.
> > > It wouldn't really be an issue, but not the most elegant solution.
> > Wouldn't
> > > it be possible to support these alternative coefficients in libswscale
> or
> > > so? I suppose that would still give issues with applications that have
> > > their own conversion algorithms.
> > >
> >
> > I don't think a single game codec warrants creating an entirely new
> > pixel format for, unless it has a concrete independent definition and
> > is used outside of this codec as well.
> > Otherwise, the conversion logic looks rather straight forward and
> > relatively cheap, and should probably just output RGB (either packed
> > or planar, whichever is easier). It does remind me a bit of YCgCo, but
> > with different  formulas unfortunately.
> >
> > - Hendrik
> > ___
> > 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".
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: Fix leak on error

[Tomas Härdin]

fre 2021-03-12 klockan 14:07 +0100 skrev Andreas Rheinhardt:
> It was introduced in d3d9b1fc8e2dfc8b4d66c9916ab7221062ff4660;
> Fixes Coverity issue #733800.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> I have no testcase for this; but hopefully Michael can test it with the
> testcase that led to d3d9b1fc8e2dfc8b4d66c9916ab7221062ff4660 in the
> first place?
> (And I always thought fuzzing samples were small. How does it come that
> it is close to INT64_MAX?)
> 
>  libavformat/mxfdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index d7213bda30..2e9d7d713a 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2909,8 +2909,11 @@ static int mxf_read_local_tags(MXFContext *mxf, 
> KLVPacket *klv, MXFMetadataReadF
>  int size = avio_rb16(pb); /* KLV specified by 0x53 */
>  int64_t next = avio_tell(pb);
>  UID uid = {0};
> -if (next < 0 || next > INT64_MAX - size)
> +if (next < 0 || next > INT64_MAX - size) {
> +if (meta)
> +mxf_free_metadataset(, 1);

{} here too of course. Looks good otherwise

/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".

Re: [FFmpeg-devel] [PATCH] avcodec: add Actimagine VX video decoder

[Florian Nouwt]

Alright, I'll just convert to rgb then. Both the windows codec and the ds
decoder decode the subsampling by simply duplicating the u/v samples within
a 2x2 block (no interpolation). Should I do that too? Or would
interpolation be preferred? As far as I was able to see the windows codec
takes the average of 2x2 blocks to create the subsampled data.

Op ma 15 mrt. 2021 23:35 schreef Hendrik Leppkes :

> On Mon, Mar 15, 2021 at 10:55 PM Florian Nouwt  wrote:
> >
> > Now that I think about it, it might not be possible to an accurate
> > straightforward conversion to regular yuv because of the subsampling.
> The u
> > and v cannot just linearly be scaled to line up with the required values
> > for regular yuv. That would mean the output would have to be in rgb
> format.
> > It wouldn't really be an issue, but not the most elegant solution.
> Wouldn't
> > it be possible to support these alternative coefficients in libswscale or
> > so? I suppose that would still give issues with applications that have
> > their own conversion algorithms.
> >
>
> I don't think a single game codec warrants creating an entirely new
> pixel format for, unless it has a concrete independent definition and
> is used outside of this codec as well.
> Otherwise, the conversion logic looks rather straight forward and
> relatively cheap, and should probably just output RGB (either packed
> or planar, whichever is easier). It does remind me a bit of YCgCo, but
> with different  formulas unfortunately.
>
> - Hendrik
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH 3/4] avformat/pp_bnk: treat music files are stereo

[Andreas Rheinhardt]

Zane van Iperen:
> These files are technically a series of planar mono tracks.
> If the "music" flag is set, merge the packets from the two
> mono tracks, essentially replicating:
> 
>   [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]
> 
> Signed-off-by: Zane van Iperen 
> ---
>  libavformat/pp_bnk.c | 60 
>  1 file changed, 50 insertions(+), 10 deletions(-)
> 
> diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
> index 8364de1fd9..970ef09923 100644
> --- a/libavformat/pp_bnk.c
> +++ b/libavformat/pp_bnk.c
> @@ -55,6 +55,8 @@ typedef struct PPBnkCtx {
>  int track_count;
>  PPBnkCtxTrack   *tracks;
>  uint32_tcurrent_track;
> +int is_music;
> +AVPacketpkt;
>  } PPBnkCtx;
>  
>  enum {
> @@ -194,8 +196,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
>  goto fail;
>  }
>  
> +ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
> +(ctx->track_count == 2) &&
> +(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
> +
>  /* Build the streams. */
> -for (int i = 0; i < ctx->track_count; i++) {
> +for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
>  if (!(st = avformat_new_stream(s, NULL))) {
>  ret = AVERROR(ENOMEM);
>  goto fail;
> @@ -204,14 +210,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
>  par = st->codecpar;
>  par->codec_type = AVMEDIA_TYPE_AUDIO;
>  par->codec_id   = AV_CODEC_ID_ADPCM_IMA_CUNNING;
> -par->format = AV_SAMPLE_FMT_S16;
> -par->channel_layout = AV_CH_LAYOUT_MONO;
> -par->channels   = 1;
> +par->format = AV_SAMPLE_FMT_S16P;
> +
> +if (ctx->is_music) {
> +par->channel_layout = AV_CH_LAYOUT_STEREO;
> +par->channels   = 2;
> +} else {
> +par->channel_layout = AV_CH_LAYOUT_MONO;
> +par->channels   = 1;
> +}
> +
>  par->sample_rate= hdr.sample_rate;
>  par->bits_per_coded_sample  = 4;
>  par->bits_per_raw_sample= 16;
>  par->block_align= 1;
> -par->bit_rate   = par->sample_rate * 
> par->bits_per_coded_sample;
> +par->bit_rate   = par->sample_rate * 
> par->bits_per_coded_sample * par->channels;
>  
>  avpriv_set_pts_info(st, 64, 1, par->sample_rate);
>  st->start_time  = 0;
> @@ -253,7 +266,22 @@ static int pp_bnk_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
>  
> -if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
> +if (!ctx->is_music)
> +ret = av_new_packet(>pkt, size);
> +else if (ctx->current_track == 0)
> +ret = av_new_packet(>pkt, size * 2);
> +else
> +ret = 0;
> +
> +if (ret < 0)
> +return ret;
> +
> +if (ctx->is_music)
> +ret = avio_read(s->pb, ctx->pkt.data + size * 
> ctx->current_track, size);
> +else
> +ret = avio_read(s->pb, ctx->pkt.data, size);
> +
> +if (ret == AVERROR_EOF) {
>  /* If we've hit EOF, don't attempt this track again. */
>  trk->data_size = trk->bytes_read;
>  continue;
> @@ -261,10 +289,21 @@ static int pp_bnk_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  return ret;
>  }
>  
> -trk->bytes_read+= ret;
> -pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
> -pkt->stream_index   = ctx->current_track++;
> -pkt->duration   = ret * 2;
> +trk->bytes_read+= ret;
> +ctx->pkt.flags &= ~AV_PKT_FLAG_CORRUPT;
> +ctx->pkt.stream_index   = ctx->current_track++;
> +ctx->pkt.duration   = ret * 2;
> +
> +if (ctx->is_music) {
> +if (ctx->pkt.stream_index == 0)
> +return FFERROR_REDO;

Wouldn't a simple continue have the same effect? This would allow to
avoid the temporary packet.

> +
> +ctx->pkt.stream_index = 0;
> +} else {
> +ctx->pkt.size = ret;
> +}
> +
> +av_packet_move_ref(pkt, >pkt);
>  return 0;
>  }
>  
> @@ -277,6 +316,7 @@ static int pp_bnk_read_close(AVFormatContext *s)
>  PPBnkCtx *ctx = s->priv_data;
>  
>  av_freep(>tracks);
> +av_packet_unref(>pkt);
>  
>  return 0;
>  }
> 

___
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".

[FFmpeg-devel] [PATCH 4/4] fate: add adpcm_ima_cunning stereo test case

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 tests/fate/adpcm.mak| 3 +++
 tests/ref/fate/adpcm-ima-cunning-stereo | 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 tests/ref/fate/adpcm-ima-cunning-stereo

diff --git a/tests/fate/adpcm.mak b/tests/fate/adpcm.mak
index 84c6996bd4..f858a808c5 100644
--- a/tests/fate/adpcm.mak
+++ b/tests/fate/adpcm.mak
@@ -139,5 +139,8 @@ fate-adpcm-ima-cunning-trunc-t2a-track1: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bn
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-trunc-h2
 fate-adpcm-ima-cunning-trunc-h2: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-h2.11c -map 0:a:0 -f s16le -af aresample
 
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-stereo
+fate-adpcm-ima-cunning-stereo: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/MOGODON2-cut.44c -f s16le -af aresample
+
 FATE_SAMPLES_AVCONV += $(FATE_ADPCM-yes)
 fate-adpcm: $(FATE_ADPCM-yes)
diff --git a/tests/ref/fate/adpcm-ima-cunning-stereo 
b/tests/ref/fate/adpcm-ima-cunning-stereo
new file mode 100644
index 00..7e11c8529d
--- /dev/null
+++ b/tests/ref/fate/adpcm-ima-cunning-stereo
@@ -0,0 +1 @@
+c508235656525c97429153c639dbe8eb
-- 
2.29.3

___
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".

[FFmpeg-devel] [PATCH 3/4] avformat/pp_bnk: treat music files are stereo

[Zane van Iperen]

These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:

  [0:a:0][0:a:1]join=inputs=2:channel_layout=stereo[a]

Signed-off-by: Zane van Iperen 
---
 libavformat/pp_bnk.c | 60 
 1 file changed, 50 insertions(+), 10 deletions(-)

diff --git a/libavformat/pp_bnk.c b/libavformat/pp_bnk.c
index 8364de1fd9..970ef09923 100644
--- a/libavformat/pp_bnk.c
+++ b/libavformat/pp_bnk.c
@@ -55,6 +55,8 @@ typedef struct PPBnkCtx {
 int track_count;
 PPBnkCtxTrack   *tracks;
 uint32_tcurrent_track;
+int is_music;
+AVPacketpkt;
 } PPBnkCtx;
 
 enum {
@@ -194,8 +196,12 @@ static int pp_bnk_read_header(AVFormatContext *s)
 goto fail;
 }
 
+ctx->is_music = (hdr.flags & PP_BNK_FLAG_MUSIC) &&
+(ctx->track_count == 2) &&
+(ctx->tracks[0].data_size == ctx->tracks[1].data_size);
+
 /* Build the streams. */
-for (int i = 0; i < ctx->track_count; i++) {
+for (int i = 0; i < (ctx->is_music ? 1 : ctx->track_count); i++) {
 if (!(st = avformat_new_stream(s, NULL))) {
 ret = AVERROR(ENOMEM);
 goto fail;
@@ -204,14 +210,21 @@ static int pp_bnk_read_header(AVFormatContext *s)
 par = st->codecpar;
 par->codec_type = AVMEDIA_TYPE_AUDIO;
 par->codec_id   = AV_CODEC_ID_ADPCM_IMA_CUNNING;
-par->format = AV_SAMPLE_FMT_S16;
-par->channel_layout = AV_CH_LAYOUT_MONO;
-par->channels   = 1;
+par->format = AV_SAMPLE_FMT_S16P;
+
+if (ctx->is_music) {
+par->channel_layout = AV_CH_LAYOUT_STEREO;
+par->channels   = 2;
+} else {
+par->channel_layout = AV_CH_LAYOUT_MONO;
+par->channels   = 1;
+}
+
 par->sample_rate= hdr.sample_rate;
 par->bits_per_coded_sample  = 4;
 par->bits_per_raw_sample= 16;
 par->block_align= 1;
-par->bit_rate   = par->sample_rate * 
par->bits_per_coded_sample;
+par->bit_rate   = par->sample_rate * 
par->bits_per_coded_sample * par->channels;
 
 avpriv_set_pts_info(st, 64, 1, par->sample_rate);
 st->start_time  = 0;
@@ -253,7 +266,22 @@ static int pp_bnk_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 size = FFMIN(trk->data_size - trk->bytes_read, PP_BNK_MAX_READ_SIZE);
 
-if ((ret = av_get_packet(s->pb, pkt, size)) == AVERROR_EOF) {
+if (!ctx->is_music)
+ret = av_new_packet(>pkt, size);
+else if (ctx->current_track == 0)
+ret = av_new_packet(>pkt, size * 2);
+else
+ret = 0;
+
+if (ret < 0)
+return ret;
+
+if (ctx->is_music)
+ret = avio_read(s->pb, ctx->pkt.data + size * ctx->current_track, 
size);
+else
+ret = avio_read(s->pb, ctx->pkt.data, size);
+
+if (ret == AVERROR_EOF) {
 /* If we've hit EOF, don't attempt this track again. */
 trk->data_size = trk->bytes_read;
 continue;
@@ -261,10 +289,21 @@ static int pp_bnk_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 return ret;
 }
 
-trk->bytes_read+= ret;
-pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
-pkt->stream_index   = ctx->current_track++;
-pkt->duration   = ret * 2;
+trk->bytes_read+= ret;
+ctx->pkt.flags &= ~AV_PKT_FLAG_CORRUPT;
+ctx->pkt.stream_index   = ctx->current_track++;
+ctx->pkt.duration   = ret * 2;
+
+if (ctx->is_music) {
+if (ctx->pkt.stream_index == 0)
+return FFERROR_REDO;
+
+ctx->pkt.stream_index = 0;
+} else {
+ctx->pkt.size = ret;
+}
+
+av_packet_move_ref(pkt, >pkt);
 return 0;
 }
 
@@ -277,6 +316,7 @@ static int pp_bnk_read_close(AVFormatContext *s)
 PPBnkCtx *ctx = s->priv_data;
 
 av_freep(>tracks);
+av_packet_unref(>pkt);
 
 return 0;
 }
-- 
2.29.3

___
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".

[FFmpeg-devel] [PATCH 2/4] avcodec/adpcm_ima_cunning: reindent

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 libavcodec/adpcm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 44f14763fb..5b6d1040af 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -1379,11 +1379,11 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 case AV_CODEC_ID_ADPCM_IMA_CUNNING:
 for (channel = 0; channel < avctx->channels; channel++) {
 int16_t *smp = samples_p[channel];
-for (n = 0; n < nb_samples / 2; n++) {
-int v = bytestream2_get_byteu();
-*smp++ = adpcm_ima_cunning_expand_nibble(>status[channel], v & 
0x0F);
-*smp++ = adpcm_ima_cunning_expand_nibble(>status[channel], v >> 
4);
-}
+for (n = 0; n < nb_samples / 2; n++) {
+int v = bytestream2_get_byteu();
+*smp++ = adpcm_ima_cunning_expand_nibble(>status[channel], 
v & 0x0F);
+*smp++ = adpcm_ima_cunning_expand_nibble(>status[channel], 
v >> 4);
+}
 }
 break;
 case AV_CODEC_ID_ADPCM_IMA_OKI:
-- 
2.29.3

___
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".

[FFmpeg-devel] [PATCH 1/4] avcodec/adpcm_ima_cunning: support stereo

[Zane van Iperen]

Changes the sample format to S16P, but was only ever mono so it
affects nothing.

Signed-off-by: Zane van Iperen 
---
 libavcodec/adpcm.c   | 11 +++
 tests/fate/adpcm.mak | 18 +-
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index eb228cc47a..44f14763fb 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -111,7 +111,6 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
 
 switch(avctx->codec->id) {
 case AV_CODEC_ID_ADPCM_IMA_AMV:
-case AV_CODEC_ID_ADPCM_IMA_CUNNING:
 max_channels = 1;
 break;
 case AV_CODEC_ID_ADPCM_DTK:
@@ -197,6 +196,7 @@ static av_cold int adpcm_decode_init(AVCodecContext * avctx)
 
 switch (avctx->codec->id) {
 case AV_CODEC_ID_ADPCM_AICA:
+case AV_CODEC_ID_ADPCM_IMA_CUNNING:
 case AV_CODEC_ID_ADPCM_IMA_DAT4:
 case AV_CODEC_ID_ADPCM_IMA_QT:
 case AV_CODEC_ID_ADPCM_IMA_WAV:
@@ -1377,10 +1377,13 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 }
 break;
 case AV_CODEC_ID_ADPCM_IMA_CUNNING:
+for (channel = 0; channel < avctx->channels; channel++) {
+int16_t *smp = samples_p[channel];
 for (n = 0; n < nb_samples / 2; n++) {
 int v = bytestream2_get_byteu();
-*samples++ = adpcm_ima_cunning_expand_nibble(>status[0], v & 
0x0F);
-*samples++ = adpcm_ima_cunning_expand_nibble(>status[0], v >> 
4);
+*smp++ = adpcm_ima_cunning_expand_nibble(>status[channel], v & 
0x0F);
+*smp++ = adpcm_ima_cunning_expand_nibble(>status[channel], v >> 
4);
+}
 }
 break;
 case AV_CODEC_ID_ADPCM_IMA_OKI:
@@ -2162,7 +2165,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_EA_XAS,  
sample_fmts_s16p, adpcm_ea_xas,
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_AMV, sample_fmts_s16,  adpcm_ima_amv,  
   "ADPCM IMA AMV");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APC, sample_fmts_s16,  adpcm_ima_apc,  
   "ADPCM IMA CRYO APC");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_APM, sample_fmts_s16,  adpcm_ima_apm,  
   "ADPCM IMA Ubisoft APM");
-ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_CUNNING, sample_fmts_s16,  
adpcm_ima_cunning, "ADPCM IMA Cunning Developments");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_CUNNING, sample_fmts_s16p, 
adpcm_ima_cunning, "ADPCM IMA Cunning Developments");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DAT4,sample_fmts_s16,  adpcm_ima_dat4, 
   "ADPCM IMA Eurocom DAT4");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK3, sample_fmts_s16,  adpcm_ima_dk3,  
   "ADPCM IMA Duck DK3");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_DK4, sample_fmts_s16,  adpcm_ima_dk4,  
   "ADPCM IMA Duck DK4");
diff --git a/tests/fate/adpcm.mak b/tests/fate/adpcm.mak
index c75a756bc3..84c6996bd4 100644
--- a/tests/fate/adpcm.mak
+++ b/tests/fate/adpcm.mak
@@ -113,31 +113,31 @@ FATE_ADPCM-$(call DEMDEC, ALP, ADPCM_IMA_ALP) += 
fate-adpcm-ima-alp-stereo
 fate-adpcm-ima-alp-stereo: CMD = md5 -i $(TARGET_SAMPLES)/alp/theme-cut.tun -f 
s16le
 
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-single
-fate-adpcm-ima-cunning-single: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/GD-cut.5c -f s16le
+fate-adpcm-ima-cunning-single: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/GD-cut.5c -f s16le -af aresample
 
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-track0
-fate-adpcm-ima-cunning-track0: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:0 -f s16le
+fate-adpcm-ima-cunning-track0: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:0 -f s16le -af aresample
 
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-track1
-fate-adpcm-ima-cunning-track1: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:1 -f s16le
+fate-adpcm-ima-cunning-track1: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:1 -f s16le -af aresample
 
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-trunc-t1
-fate-adpcm-ima-cunning-trunc-t1: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t1.11c -map 0:a:0 -f s16le
+fate-adpcm-ima-cunning-trunc-t1: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t1.11c -map 0:a:0 -f s16le -af aresample
 
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-trunc-t2-track0
-fate-adpcm-ima-cunning-trunc-t2-track0: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:0 -f s16le
+fate-adpcm-ima-cunning-trunc-t2-track0: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:0 -f s16le -af aresample
 
 FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) += 
fate-adpcm-ima-cunning-trunc-t2-track1
-fate-adpcm-ima-cunning-trunc-t2-track1: CMD = md5 -y -i 
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:1 -f s16le
+fate-adpcm-ima-cunning-trunc-t2-track1: CMD = md5 -y -i