Re: [FFmpeg-devel] [PATCH 03/20] lavc: Add coded bitstream read/write API
On 14/09/17 01:42, Michael Niedermayer wrote:
> On Wed, Sep 13, 2017 at 12:43:53AM +0100, Mark Thompson wrote:
>> (cherry picked from commit 18f1706f331bf5dd565774eae680508c8d3a97ad)
>> (cherry picked from commit 44cde38c8acbef7d5250e6d1b52b1020871e093b)
>> ---
>> configure | 1 +
>> libavcodec/Makefile | 1 +
>> libavcodec/cbs.c | 466
>> ++
>> libavcodec/cbs.h | 274 +++
>> libavcodec/cbs_internal.h | 83 +
>> 5 files changed, 825 insertions(+)
>> create mode 100644 libavcodec/cbs.c
>> create mode 100644 libavcodec/cbs.h
>> create mode 100644 libavcodec/cbs_internal.h
>>
>> diff --git a/configure b/configure
>> index 4dd11efe5e..2e84b1f892 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2112,6 +2112,7 @@ CONFIG_EXTRA="
>> blockdsp
>> bswapdsp
>> cabac
>> +cbs
>> dirac_parse
>> dvprofile
>> exif
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index 999632cf9e..d9612d68d0 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -59,6 +59,7 @@ OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
>> OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
>> OBJS-$(CONFIG_BSWAPDSP)+= bswapdsp.o
>> OBJS-$(CONFIG_CABAC) += cabac.o
>> +OBJS-$(CONFIG_CBS) += cbs.o
>> OBJS-$(CONFIG_CRYSTALHD) += crystalhd.o
>> OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o dct32_float.o
>> OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
>> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
>> new file mode 100644
>> index 00..13bc25728f
>> --- /dev/null
>> +++ b/libavcodec/cbs.c
>> @@ -0,0 +1,466 @@
>> +/*
>> + * 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
>> + */
>> +
>> +#include
>> +
>> +#include "config.h"
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/common.h"
>> +
>> +#include "cbs.h"
>> +#include "cbs_internal.h"
>> +
>> +
>> +static const CodedBitstreamType *cbs_type_table[] = {
>> +};
>> +
>> +int ff_cbs_init(CodedBitstreamContext *ctx,
>> +enum AVCodecID codec_id, void *log_ctx)
>> +{
>> +const CodedBitstreamType *type;
>> +int i;
>> +
>> +type = NULL;
>> +for (i = 0; i < FF_ARRAY_ELEMS(cbs_type_table); i++) {
>> +if (cbs_type_table[i]->codec_id == codec_id) {
>> +type = cbs_type_table[i];
>> +break;
>> +}
>> +}
>> +if (!type)
>> +return AVERROR(EINVAL);
>> +
>> +ctx->log_ctx = log_ctx;
>> +ctx->codec = type;
>> +
>> +ctx->priv_data = av_mallocz(ctx->codec->priv_data_size);
>> +if (!ctx->priv_data)
>> +return AVERROR(ENOMEM);
>> +
>> +ctx->decompose_unit_types = NULL;
>> +
>> +ctx->trace_enable = 0;
>> +ctx->trace_level = AV_LOG_TRACE;
>> +
>> +return 0;
>> +}
>> +
>> +void ff_cbs_close(CodedBitstreamContext *ctx)
>> +{
>> +if (ctx->codec && ctx->codec->close)
>> +ctx->codec->close(ctx);
>> +
>> +av_freep(&ctx->priv_data);
>> +}
>> +
>> +static void cbs_unit_uninit(CodedBitstreamContext *ctx,
>> +CodedBitstreamUnit *unit)
>> +{
>> +if (ctx->codec->free_unit && unit->content && !unit->content_external)
>> +ctx->codec->free_unit(unit);
>> +
>> +av_freep(&unit->data);
>> +unit->data_size = 0;
>> +unit->data_bit_padding = 0;
>> +}
>> +
>> +void ff_cbs_fragment_uninit(CodedBitstreamContext *ctx,
>> +CodedBitstreamFragment *frag)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < frag->nb_units; i++)
>> +cbs_unit_uninit(ctx, &frag->units[i]);
>> +av_freep(&frag->units);
>> +frag->nb_units = 0;
>> +
>> +av_freep(&frag->data);
>> +frag->data_size= 0;
>> +frag->data_bit_padding = 0;
>> +}
>> +
>> +static int cbs_read_fragment_content(CodedBitstreamContext *ctx,
>> + CodedBitstreamFragment *frag)
>> +{
>> +int err, i, j;
>> +
>> +for (i = 0; i < frag->nb_units; i++) {
>> +if (ctx->decompose_unit_types) {
>> +for (j = 0; j < ctx->nb_decompose_unit_
Re: [FFmpeg-devel] [PATCH 18/20] mpeg12: Move finding the best frame rate to common code
On 14/09/17 01:48, Michael Niedermayer wrote:
> On Wed, Sep 13, 2017 at 12:44:08AM +0100, Mark Thompson wrote:
>> Previously in the mpeg2_metadata filter. Also adds a test.
> [...]
>> +for (c = 1; c <= max_code; c++) {
>> +for (n = 1; n <= (mpeg2 ? 4 : 1); n++) {
>> +for (d = 1; d <= (mpeg2 ? 32 : 1); d++) {
>> +AVRational test, error;
>> +int cmp;
>> +
>> +test = av_mul_q(ff_mpeg12_frame_rate_tab[c],
>> +(AVRational) { n, d });
>> +
>> +cmp = av_cmp_q(test, frame_rate);
>> +if (cmp == 0) {
>> +best_c = c;
>> +best_n = n;
>> +best_d = d;
>> +goto found;
>> +}
>> +
>> +if (cmp < 0)
>> +error = av_div_q(frame_rate, test);
>> +else
>> +error = av_div_q(test, frame_rate);
>> +
>> +cmp = av_cmp_q(error, best_error);
>> +if (cmp < 0 || (cmp == 0 && n == 1 && d == 1)) {
>> +best_c = c;
>> +best_n = n;
>> +best_d = d;
>> +best_error = error;
>> +}
>> +}
>> +}
>> +}
> [...]
>> -for (i = 1; i < FF_ARRAY_ELEMS(frame_rate_table); i++) {
>> -AVRational fr, error;
>> -int n, d, cmp;
>> -for (n = 1; n <= 4; n++) {
>> -for (d = 1; d <= 32; d++) {
>> -fr = av_mul_q(frame_rate_table[i],
>> - (AVRational) { n, d });
>> -cmp = av_cmp_q(fr, ctx->frame_rate);
>> -if (cmp == 0) {
>> -code = i;
>> -ext_n = n;
>> -ext_d = d;
>> -goto found_frame_rate;
>> -}
>> -if (cmp < 0)
>> -error = av_div_q(ctx->frame_rate, fr);
>> -else
>> -error = av_div_q(fr, ctx->frame_rate);
>> -cmp = av_cmp_q(error, best_error);
>> -if (cmp < 0 || (cmp == 0 && n == 1 && d == 1)) {
>> -code = i;
>> -ext_n = n;
>> -ext_d = d;
>> -best_error = error;
>> -}
>> -}
>> -}
>> -}
>
> This doesnt just move the code, it also changes it
> (this makes it harder to determine if the chnages are just cosmetic or
> not)
I'll rearrange the patches so that the common part gets applied first and never
changed.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] kmsgrab: fix build error when use old libdrm
On 14/09/17 01:34, Jun Zhao wrote:
> From 8c7ddfcabf686f213aa59544d90055d20bdac0f7 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Wed, 13 Sep 2017 20:21:38 -0400
> Subject: [PATCH] kmsgrab: fix build error when use old libdrm
>
> DRM_FORMAT_R16 adding from libdrm 2.4.82, fix the build error
> when libdrm < 2.4.82.
>
> Signed-off-by: Jun Zhao
> ---
> libavdevice/kmsgrab.c | 2 ++
> libavutil/hwcontext_vaapi.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
> index d0b9cf5001..49eb44f6f2 100644
> --- a/libavdevice/kmsgrab.c
> +++ b/libavdevice/kmsgrab.c
> @@ -203,7 +203,9 @@ static const struct {
> uint32_t drm_format;
> } kmsgrab_formats[] = {
> { AV_PIX_FMT_GRAY8,DRM_FORMAT_R8 },
> +#ifdef DRM_FORMAT_R16
> { AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16 },
> +#endif
> { AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888 },
> { AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888 },
> { AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 2cc6f26715..837b79da11 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -920,7 +920,7 @@ static const struct {
> } vaapi_drm_format_map[] = {
> DRM_MAP(NV12, 2, DRM_FORMAT_R8, DRM_FORMAT_RG88),
> DRM_MAP(NV12, 1, DRM_FORMAT_NV12),
> -#ifdef VA_FOURCC_P010
> +#if defined(VA_FOURCC_P010) && defined(DRM_FORMAT_R16)
> DRM_MAP(P010, 2, DRM_FORMAT_R16, DRM_FORMAT_RG1616),
> #endif
> DRM_MAP(BGRA, 1, DRM_FORMAT_BGRA),
> --
> 2.11.0
>
Hmm, yeah. Thanks for noticing this - let me think about it a bit further, I
imagine there are more cases than just this one. (It isn't autodetected so
nothing is directly broken.)
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber
On 14/09/17 05:35, James Almer wrote: > On 9/7/2017 6:56 PM, Mark Thompson wrote: >> +pkt->data = (uint8_t*)frame; >> +pkt->size = sizeof(*frame); >> +pkt->pts = now; >> +pkt->flags = AV_PKT_FLAG_TRUSTED; > > pkt->flags |= AV_PKT_FLAG_TRUSTED; > > I know pkt->flags is zeroed by default, but that may change in the > future. And ORing/XORing is the proper way to set flags anyway. Fixed. Thanks! - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter
L'octidi 28 fructidor, an CCXXV, Richard Ling a écrit :
> This patch adds a filter to normalize (contrast stretch) RGB video.
> Comments welcome.
Thanks for the patch. Unfortunately, your mail software mangled it with
line breaks, it cannot be applied as is. Still, see a few comments
below.
>
> R.
>
> From f08f132ecd79718d0ce6fb07f99c84ab5dd52ee4 Mon Sep 17 00:00:00 2001
> From: Richard Ling
> Date: Thu, 14 Sep 2017 13:18:50 +1000
> Subject: [PATCH] avfilter: add normalize filter
>
> ---
> doc/filters.texi | 79 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_normalize.c | 415
> +
> 4 files changed, 496 insertions(+)
> create mode 100644 libavfilter/vf_normalize.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 830de54..1e7712a 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10808,6 +10808,85 @@ Add temporal and uniform noise to input video:
> noise=alls=20:allf=t+u
> @end example
>
> +@section normalize
> +
> +Normalize RGB video (aka histogram stretching, contrast stretching).
> +See: https://en.wikipedia.org/wiki/Normalization_(image_processing)
> +
> +For each channel of each frame, the filter computes the input range and
> maps
> +it linearly to the user-specified output range. The output range defaults
> +to the full dynamic range from pure black to pure white.
> +
> +Temporal smoothing can be used on the input range to reduce flickering
> (rapid
> +changes in brightness) caused when small dark or bright objects enter or
> leave
> +the scene. This is similar to the auto-exposure (automatic gain control)
> on a
> +video camera, and, like a video camera, it may cause a period of over- or
> +under-exposure of the video.
> +
> +The R,G,B channels can be normalized independently, which may cause some
> +color shifting, or linked together as a single channel, which prevents
> +color shifting. Linked normalization preserves hue. Independent
> normalization
> +does not, so it can be used to remove some color casts. Independent and
> linked
> +normalization can be combined in any ratio.
> +
> +The normalize filter accepts the following options:
> +
> +@table @option
> +@item blackpt
> +@item whitept
> +Colors which define the output range. The minimum input value is mapped to
> +the @var{blackpt}. The maximum input value is mapped to the @var{whitept}.
> +The defaults are black and white respectively. Specifying white for
> +@var{blackpt} and black for @var{whitept} will give color-inverted,
> +normalized video. Shades of grey can be used to reduce the dynamic range
> +(contrast). Specifying saturated colors here can create some interesting
> +effects.
> +
> +@item smoothing
> +The amount of temporal smoothing, expressed in seconds. the input range of
> +each channel is smoothed using a rolling average over that many seconds of
> +video. Defaults to 0.0 (no temporal smoothing). The maximum is 60 seconds.
If I read the code correctly, the rolling average is asymmetrical:
the current frame is computed using the n previous frames rather than
the n/2 previous and n/2 next. Which, of course, is the best that can be
done without buffering that many frames.
But the documentation should probably specify it.
> +
> +@item independence
> +Controls the ratio of independent (color shifting) channel normalization to
> +linked (color preserving) normalization. 0.0 is fully linked, 1.0 is fully
> +independent. Defaults to fully independent.
> +
> +@item strength
> +Overall strength of the filter. 1.0 is full strength. 0.0 is a rather
> +expensive no-op.
> +
> +@end table
> +
> +@subsection Examples
> +
> +Stretch video contrast to use the full dynamic range, with no temporal
> +smoothing; may flicker depending on the source content:
> +@example
> +normalize=black:white:0
Better use named options in example. See the drama about that last
summer.
> +@end example
> +
> +As above, but with 2 seconds of temporal smoothing; flicker should be
> +reduced, depending on the source content:
> +@example
> +normalize=black:white:2
> +@end example
> +
> +As above, but with hue-preserving linked channel normalization:
> +@example
> +normalize=black:white:2:1
> +@end example
> +
> +As above, but with half strength:
> +@example
> +normalize=black:white:2:1:0.5
> +@end example
> +
> +Map the darkest input color to red, the brightest input color to cyan:
> +@example
> +normalize=red:cyan
> +@end example
> +
> @section null
>
> Pass the video source unchanged to the output.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 8aa974e..31f8170 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -243,6 +243,7 @@ OBJS-$(CONFIG_NLMEANS_FILTER)+=
> vf_nlmeans.o
> OBJS-$(CONFIG_NNEDI_FILTER) += vf_nnedi.o
> OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
> OBJS-$(CONFIG_NOISE_FILTER) += vf_noise.
Re: [FFmpeg-devel] [PATCH] kmsgrab: fix build error when use old libdrm
On 14/09/17 01:34, Jun Zhao wrote:
> From 8c7ddfcabf686f213aa59544d90055d20bdac0f7 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Wed, 13 Sep 2017 20:21:38 -0400
> Subject: [PATCH] kmsgrab: fix build error when use old libdrm
>
> DRM_FORMAT_R16 adding from libdrm 2.4.82, fix the build error
> when libdrm < 2.4.82.
>
> Signed-off-by: Jun Zhao
> ---
> libavdevice/kmsgrab.c | 2 ++
> libavutil/hwcontext_vaapi.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
> index d0b9cf5001..49eb44f6f2 100644
> --- a/libavdevice/kmsgrab.c
> +++ b/libavdevice/kmsgrab.c
> @@ -203,7 +203,9 @@ static const struct {
> uint32_t drm_format;
> } kmsgrab_formats[] = {
> { AV_PIX_FMT_GRAY8,DRM_FORMAT_R8 },
> +#ifdef DRM_FORMAT_R16
> { AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16 },
> +#endif
> { AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888 },
> { AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888 },
> { AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 2cc6f26715..837b79da11 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -920,7 +920,7 @@ static const struct {
> } vaapi_drm_format_map[] = {
> DRM_MAP(NV12, 2, DRM_FORMAT_R8, DRM_FORMAT_RG88),
> DRM_MAP(NV12, 1, DRM_FORMAT_NV12),
> -#ifdef VA_FOURCC_P010
> +#if defined(VA_FOURCC_P010) && defined(DRM_FORMAT_R16)
> DRM_MAP(P010, 2, DRM_FORMAT_R16, DRM_FORMAT_RG1616),
> #endif
> DRM_MAP(BGRA, 1, DRM_FORMAT_BGRA),
> --
> 2.11.0
>
R8/RG88 can be a problem as well (2.4.68). Also, this should be two patches
(one for each of the two components).
I can split and add that later myself, or you can send a new version if you
prefer?
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: use the common packet pts setter function for opatom files
On 2017-09-13 21:31, Marton Balint wrote: On Fri, 8 Sep 2017, Michael Niedermayer wrote: On Thu, Sep 07, 2017 at 05:11:40PM +0200, Marton Balint wrote: Fixes ticket #6631. Signed-off-by: Marton Balint --- libavformat/mxfdec.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) please add a fate this if you push this Unfortunately we only have a sample which is around 16 MB but it seems like an overkill to add such a big sample to the fate suite for such a minor feature. And I am also not very fond of truncating the file and adding truncated files to the fate suite... So unless somebody can provide an opAtom AVC intra file which is only a few frames long, I see no good way to fate test this. Do you have an idea how to proceed? Try having the user that reported the bug generate a smaller + lower res sample? /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames
Signed-off-by: Tobias Rapp
---
libavformat/mxfenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7289e0b..da4d7b4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1810,7 +1810,7 @@ static int mxf_parse_dv_frame(AVFormatContext *s,
AVStream *st, AVPacket *pkt)
stype= vs_pack[3] & 0x1f;
pal = (vs_pack[3] >> 5) & 0x1;
-if ((vs_pack[2] & 0x07) == 0x02)
+if ((vsc_pack[2] & 0x07) == 0x02)
sc->aspect_ratio = (AVRational){ 16, 9 };
else
sc->aspect_ratio = (AVRational){ 4, 3 };
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] fate: add mxf_dv25/dvcpro50 regression tests
Signed-off-by: Tobias Rapp --- tests/fate/avformat.mak | 2 ++ tests/fate/seek.mak | 4 +++ tests/lavf-regression.sh | 8 ++ tests/ref/lavf/mxf_dv25 | 3 +++ tests/ref/lavf/mxf_dvcpro50 | 3 +++ tests/ref/seek/lavf-mxf_dv25 | 53 tests/ref/seek/lavf-mxf_dvcpro50 | 53 7 files changed, 126 insertions(+) create mode 100644 tests/ref/lavf/mxf_dv25 create mode 100644 tests/ref/lavf/mxf_dvcpro50 create mode 100644 tests/ref/seek/lavf-mxf_dv25 create mode 100644 tests/ref/seek/lavf-mxf_dvcpro50 diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak index f65ef76..c9ea99a 100644 --- a/tests/fate/avformat.mak +++ b/tests/fate/avformat.mak @@ -25,6 +25,8 @@ FATE_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2, MPEG1SYSTEM MPEGPS) += mpg FATE_LAVF-$(call ENCDEC, PCM_MULAW, PCM_MULAW) += mulaw FATE_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF)+= mxf FATE_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF_D10 MXF)+= mxf_d10 +FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF)+= mxf_dv25 +FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF)+= mxf_dvcpro50 FATE_LAVF-$(call ENCDEC2, DNXHD, PCM_S16LE, MXF_OPATOM MXF) += mxf_opatom FATE_LAVF-$(call ENCDEC2, DNXHD, PCM_S16LE, MXF_OPATOM MXF) += mxf_opatom_audio FATE_LAVF-$(call ENCDEC2, MPEG4, MP2, NUT)+= nut diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak index 1a6e584..c863b2a 100644 --- a/tests/fate/seek.mak +++ b/tests/fate/seek.mak @@ -180,6 +180,8 @@ FATE_SEEK_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2, MPEG1SYSTEM MPEGPS) += mpg FATE_SEEK_LAVF-$(call ENCDEC, PCM_MULAW, PCM_MULAW) += mulaw FATE_SEEK_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf FATE_SEEK_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF_D10 MXF) += mxf_d10 +FATE_SEEK_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF) += mxf_dv25 +FATE_SEEK_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF) += mxf_dvcpro50 FATE_SEEK_LAVF-$(call ENCDEC2, DNXHD, PCM_S16LE, MXF_OPATOM MXF) += mxf_opatom FATE_SEEK_LAVF-$(call ENCDEC2, DNXHD, PCM_S16LE, MXF_OPATOM MXF) += mxf_opatom_audio FATE_SEEK_LAVF-$(call ENCDEC2, MPEG4, MP2, NUT) += nut @@ -220,6 +222,8 @@ fate-seek-lavf-mpg: SRC = lavf/lavf.mpg fate-seek-lavf-mulaw:SRC = lavf/lavf.ul fate-seek-lavf-mxf: SRC = lavf/lavf.mxf fate-seek-lavf-mxf_d10: SRC = lavf/lavf.mxf_d10 +fate-seek-lavf-mxf_dv25: SRC = lavf/lavf.mxf_dv25 +fate-seek-lavf-mxf_dvcpro50: SRC = lavf/lavf.mxf_dvcpro50 fate-seek-lavf-mxf_opatom: SRC = lavf/lavf.mxf_opatom fate-seek-lavf-mxf_opatom_audio: SRC = lavf/lavf.mxf_opatom_audio fate-seek-lavf-nut: SRC = lavf/lavf.nut diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh index d9026de..45c877e 100755 --- a/tests/lavf-regression.sh +++ b/tests/lavf-regression.sh @@ -90,6 +90,14 @@ if [ -n "$do_mxf_d10" ]; then do_lavf mxf_d10 "-ar 48000 -ac 2" "-r 25 -vf scale=720:576,pad=720:608:0:32 -vcodec mpeg2video -g 0 -flags +ildct+low_delay -dc 10 -non_linear_quant 1 -intra_vlc 1 -qscale 1 -ps 1 -qmin 1 -rc_max_vbv_use 1 -rc_min_vbv_use 1 -pix_fmt yuv422p -minrate 3k -maxrate 3k -b 3k -bufsize 120 -top 1 -rc_init_occupancy 120 -qmax 12 -f mxf_d10" fi +if [ -n "$do_mxf_dv25" ]; then +do_lavf mxf_dv25 "-ar 48000 -ac 2" "-r 25 -vf scale=720:576,setdar=4/3 -vcodec dvvideo -pix_fmt yuv420p -b 25000k -top 0 -f mxf" +fi + +if [ -n "$do_mxf_dvcpro50" ]; then +do_lavf mxf_dvcpro50 "-ar 48000 -ac 2" "-r 25 -vf scale=720:576,setdar=16/9 -vcodec dvvideo -pix_fmt yuv422p -b 5k -top 0 -f mxf" +fi + if [ -n "$do_mxf_opatom" ]; then do_lavf mxf_opatom "" "-s 1920x1080 -vcodec dnxhd -pix_fmt yuv422p -vb 36M -f mxf_opatom -map 0" fi diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25 new file mode 100644 index 000..adecc07 --- /dev/null +++ b/tests/ref/lavf/mxf_dv25 @@ -0,0 +1,3 @@ +de98603ecc27c2f3cefd192d4820d3f4 *./tests/data/lavf/lavf.mxf_dv25 +3833389 ./tests/data/lavf/lavf.mxf_dv25 +./tests/data/lavf/lavf.mxf_dv25 CRC=0xbdaf7f52 diff --git a/tests/ref/lavf/mxf_dvcpro50 b/tests/ref/lavf/mxf_dvcpro50 new file mode 100644 index 000..1d0cf79 --- /dev/null +++ b/tests/ref/lavf/mxf_dvcpro50 @@ -0,0 +1,3 @@ +6c9cb62911ac16c3b55f0ad0b052c05b *./tests/data/lavf/lavf.mxf_dvcpro50 +7430189 ./tests/data/lavf/lavf.mxf_dvcpro50 +./tests/data/lavf/lavf.mxf_dvcpro50 CRC=0xe3bbe4b4 diff --git a/tests/ref/seek/lavf-mxf_dv25 b/tests/ref/seek/lavf-mxf_dv25 new file mode 100644 index 000..42b3bbd --- /dev/null +++ b/tests/ref/seek/lavf-mxf_dv25 @@ -0,0 +1,53 @@ +ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos: 6144 size:144000 +ret: 0 st:-1 flags:0 ts:-1.00 +ret: 0 st: 0 flags:1 dts: 0.00
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames
On 2017-09-14 15:44, Tobias Rapp wrote:
Signed-off-by: Tobias Rapp
---
libavformat/mxfenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7289e0b..da4d7b4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1810,7 +1810,7 @@ static int mxf_parse_dv_frame(AVFormatContext *s,
AVStream *st, AVPacket *pkt)
stype= vs_pack[3] & 0x1f;
pal = (vs_pack[3] >> 5) & 0x1;
-if ((vs_pack[2] & 0x07) == 0x02)
+if ((vsc_pack[2] & 0x07) == 0x02)
sc->aspect_ratio = (AVRational){ 16, 9 };
else
sc->aspect_ratio = (AVRational){ 4, 3 };
Might want to add some { } around those two cases while you're at it
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames
On 14.09.2017 15:55, Tomas Härdin wrote:
On 2017-09-14 15:44, Tobias Rapp wrote:
Signed-off-by: Tobias Rapp
---
libavformat/mxfenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7289e0b..da4d7b4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1810,7 +1810,7 @@ static int mxf_parse_dv_frame(AVFormatContext
*s, AVStream *st, AVPacket *pkt)
stype = vs_pack[3] & 0x1f;
pal = (vs_pack[3] >> 5) & 0x1;
- if ((vs_pack[2] & 0x07) == 0x02)
+ if ((vsc_pack[2] & 0x07) == 0x02)
sc->aspect_ratio = (AVRational){ 16, 9 };
else
sc->aspect_ratio = (AVRational){ 4, 3 };
Might want to add some { } around those two cases while you're at it
Added to the list of cosmetic changes that I'll apply after this patch
is accepted. See attached file for reference.
Regards,
Tobias
From 2a4a95b4d930bb5b511576ab2932969a37766adf Mon Sep 17 00:00:00 2001
From: Tobias Rapp
Date: Thu, 14 Sep 2017 16:05:31 +0200
Subject: [PATCH] avformat/mxfenc: cosmetic changes
Signed-off-by: Tobias Rapp
---
libavformat/mxfenc.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index da4d7b4..b8d3030 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -846,7 +846,7 @@ static void mxf_write_track(AVFormatContext *s, AVStream
*st, enum MXFMetadataSe
// write edit rate
mxf_write_local_tag(pb, 8, 0x4B01);
-if (st == mxf->timecode_track && s->oformat == &ff_mxf_opatom_muxer){
+if (st == mxf->timecode_track && s->oformat == &ff_mxf_opatom_muxer) {
avio_wb32(pb, mxf->tc.rate.num);
avio_wb32(pb, mxf->tc.rate.den);
} else {
@@ -882,7 +882,7 @@ static void mxf_write_common_fields(AVFormatContext *s,
AVStream *st)
// write duration
mxf_write_local_tag(pb, 8, 0x0202);
-if (st != mxf->timecode_track && s->oformat == &ff_mxf_opatom_muxer &&
st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO){
+if (st != mxf->timecode_track && s->oformat == &ff_mxf_opatom_muxer &&
st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
avio_wb64(pb, mxf->body_offset / mxf->edit_unit_byte_count);
} else {
avio_wb64(pb, mxf->duration);
@@ -1194,7 +1194,7 @@ static void
mxf_write_generic_sound_common(AVFormatContext *s, AVStream *st, con
mxf_write_generic_desc(s, st, key, size+duration_size+5+12+8+8);
-if (duration_size > 0){
+if (duration_size > 0) {
mxf_write_local_tag(pb, 8, 0x3002);
avio_wb64(pb, mxf->body_offset / mxf->edit_unit_byte_count);
}
@@ -1328,7 +1328,7 @@ static void mxf_write_package(AVFormatContext *s, enum
MXFMetadataSetType type,
// write uid
mxf_write_local_tag(pb, 16, 0x3C0A);
mxf_write_uuid(pb, type, 0);
-av_log(s,AV_LOG_DEBUG, "package type:%d\n", type);
+av_log(s, AV_LOG_DEBUG, "package type:%d\n", type);
PRINT_KEY(s, "package uid", pb->buf_ptr - 16);
// write package umid
@@ -1770,7 +1770,7 @@ AVPacket *pkt)
sc->codec_ul = &mxf_essence_container_uls[sc->index].codec_ul;
sc->aspect_ratio = (AVRational){ 16, 9 };
-if(s->oformat == &ff_mxf_opatom_muxer){
+if (s->oformat == &ff_mxf_opatom_muxer) {
mxf->edit_unit_byte_count = frame_size;
return 1;
}
@@ -1810,10 +1810,11 @@ static int mxf_parse_dv_frame(AVFormatContext *s,
AVStream *st, AVPacket *pkt)
stype= vs_pack[3] & 0x1f;
pal = (vs_pack[3] >> 5) & 0x1;
-if ((vsc_pack[2] & 0x07) == 0x02)
+if ((vsc_pack[2] & 0x07) == 0x02) {
sc->aspect_ratio = (AVRational){ 16, 9 };
-else
+} else {
sc->aspect_ratio = (AVRational){ 4, 3 };
+}
sc->interlaced = (vsc_pack[3] >> 4) & 0x01;
// TODO: fix dv encoder to set proper FF/FS value in VSC pack
@@ -2097,7 +2098,7 @@ static int mxf_write_header(AVFormatContext *s)
if (!s->nb_streams)
return -1;
-if (s->oformat == &ff_mxf_opatom_muxer && s->nb_streams !=1){
+if (s->oformat == &ff_mxf_opatom_muxer && s->nb_streams !=1) {
av_log(s, AV_LOG_ERROR, "there must be exactly one stream for mxf
opatom\n");
return -1;
}
@@ -2212,7 +2213,7 @@ static int mxf_write_header(AVFormatContext *s)
}
spf = ff_mxf_get_samples_per_frame(s, tbc);
-if (!spf){
+if (!spf) {
av_log(s, AV_LOG_ERROR, "Unsupported timecode frame rate
%d/%d\n", tbc.den, tbc.num);
return AVERROR(EINVAL);
}
@@ -2605,7 +2606,7 @@ static int mxf_write_footer(AVFormatContext *s)
mxf_write_random_index_pack(s);
if (s->pb->seekable & AVIO_SEEKABLE_NORMAL) {
-if (s->oformat == &ff_mxf_opatom_muxer){
+if (s->oformat == &ff_mxf_opatom_muxer) {
/* rewrite body partition to update lengths */
avio_seek(pb
Re: [FFmpeg-devel] [PATCH] avfilter: add despill filter
On Mon, Aug 28, 2017 at 15:25:54 +0200, Paul B Mahol wrote:
> +@table @option
> +@item type
> +Set what type of despill to use.
Please add:
Accepted values are @code{green} and @code{blue} for greenscreen and
bluescreen spills.
(Or make this a list.)
> +@item mix
> +Set how spillmap will be generated.
This doesn't make it clear that it's a value (and defaults to 0.5).
> +@item red
> +Controls ammount of red in spill area.
^ amount
(Same remark for two further cases.)
> +@item green
> +Controls ammount of green in spill area.
> +Should be -1 for greenscreen.
Perhaps @code{-1}. Remark also valid for "blue".
> +{ "red","set red scale", OFFSET(bluescale),
> AV_OPT_TYPE_FLOAT, {.dbl=0}, -100, 100, FLAGS },
Assigned to the wrong variable.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avformat/mpegts: opus muxing & demuxing for mapping family 255
On Fri, Sep 08, 2017 at 01:46:38 +0200, pkv.stream wrote:
> -avpriv_request_sample(fc, "Opus in MPEG-TS -
> channel_config_code > 0x8");
[...]
> +avpriv_request_sample(fc, "Opus in MPEG-TS -
> channel_config_code");
You probably need to mention the channel_config_code in the new
message.
> +for (j = 0; j < channels; j++) {
> +opus_channel_map255[j] = j;
> +}
Misplaced closing bracket.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avformat/mpegts: opus muxing & demuxing for mapping family 255
Thanks for your comments Moritz.
Corrected patch in attachment.
Regards
Le 14/09/2017 à 5:46 PM, Moritz Barsnick a écrit :
On Fri, Sep 08, 2017 at 01:46:38 +0200, pkv.stream wrote:
-avpriv_request_sample(fc, "Opus in MPEG-TS - channel_config_code
> 0x8");
[...]
+avpriv_request_sample(fc, "Opus in MPEG-TS -
channel_config_code");
You probably need to mention the channel_config_code in the new
message.
+for (j = 0; j < channels; j++) {
+opus_channel_map255[j] = j;
+}
Misplaced closing bracket.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
From 9175cb61dabce42417199cc6d6272d8290c39a5c Mon Sep 17 00:00:00 2001
From: pkviet
Date: Fri, 8 Sep 2017 01:34:22 +0200
Subject: [PATCH] avformat/mpegts: opus muxing & demuxing expanded
Support for opus in mpegts demuxer was brought by commit
9cfa68c560bdec82d2d5ec079f9c5b0f9ca37af0 (Kieran Kunhya).
Support for opus in mpegts muxer was then added by commit
01509cdf9287b975eced1fd609a8201fbd1438e3 (S. Droge).
Later commit 37941878f193a2316c514bd5ba55bfe9d2dfdfcf by Michael Graczyk
added support of mapping_family encoder parameter which allows for up to
255 audio channels (for family 255).
While matroska muxer & demuxer readily accepts mapping_family, it is not
the case for mpegts muxer & demuxer for all the range of the parameter
(family 255 and also part of family 1 with channel_config_code > 0x81
unsupported).
This commit brings such a support.
---
libavformat/mpegts.c| 64 ++---
libavformat/mpegtsenc.c | 19 ++-
2 files changed, 74 insertions(+), 9 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 4d2f5c6..8d8977b 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1633,7 +1633,7 @@ static const uint8_t opus_stream_cnt[9] = {
1, 1, 1, 2, 2, 3, 4, 4, 5,
};
-static const uint8_t opus_channel_map[8][8] = {
+static const uint8_t opus_channel_map_a[8][8] = {
{ 0 },
{ 0,1 },
{ 0,2,1 },
@@ -1644,6 +1644,17 @@ static const uint8_t opus_channel_map[8][8] = {
{ 0,6,1,2,3,4,5,7 },
};
+static const uint8_t opus_channel_map_b[8][8] = {
+{ 0 },
+{ 0,1 },
+{ 0,1,2 },
+{ 0,1,2,3 },
+{ 0,1,2,3,4 },
+{ 0,1,2,3,4,5 },
+{ 0,1,2,3,4,5,6 },
+{ 0,1,2,3,4,5,6,7 },
+};
+
int ff_parse_mpeg2_descriptor(AVFormatContext *fc, AVStream *st, int
stream_type,
const uint8_t **pp, const uint8_t *desc_list_end,
Mp4Descr *mp4_descr, int mp4_descr_count, int
pid,
@@ -1887,9 +1898,56 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
AVStream *st, int stream_type
st->codecpar->extradata[18] = channel_config_code ?
(channels > 2) : /* Dual Mono */ 255;
st->codecpar->extradata[19] =
opus_stream_cnt[channel_config_code];
st->codecpar->extradata[20] =
opus_coupled_stream_cnt[channel_config_code];
-memcpy(&st->codecpar->extradata[21],
opus_channel_map[channels - 1], channels);
+memcpy(&st->codecpar->extradata[21],
opus_channel_map_a[channels - 1], channels);
} else {
-avpriv_request_sample(fc, "Opus in MPEG-TS -
channel_config_code > 0x8");
+if (channel_config_code == 0x81) {
+channels = get8(pp, desc_end);
+st->codecpar->extradata_size = 22 + channels;
+size_t extradata_size;
+extradata_size = (22 + channels) * sizeof(uint8_t);
+uint8_t *extradata;
+extradata = av_malloc(extradata_size);
+if (!extradata)
+return AVERROR(ENOMEM);
+for (i = 0; i <= (22+channels); i++) {
+if (i < 9) {
+extradata[i] = opus_default_extradata[i];
+}
+else {
+extradata[i] = 0;
+}
+}
+memcpy(st->codecpar->extradata, extradata,
sizeof(extradata));
+av_free(extradata);
+st->codecpar->extradata[9] = channels;
+st->codecpar->extradata[18] = 255;
+st->codecpar->extradata[19] = channels;
+st->codecpar->extradata[20] = 0;
+size_t channel_map_size = channels * sizeof(uint8_t);
+uint8_t *opus_channel_map255;
+opus_channel_map255 = av_malloc(channel_map_size);
+
Re: [FFmpeg-devel] [PATCH] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.
On Tue, Sep 12, 2017 at 6:45 PM, Thierry Foucu wrote:
> Fix ticket #2674
> Tested with examples from ticket 2674.
> ---
> Sorry Michael, I forgot to configure using --enable-gpl.
> Please find new patch.
>
>
>
ping?
> libavfilter/vf_fps.c | 44 ++
> +-
> tests/ref/fate/filter-fps| 6 ++
> tests/ref/fate/filter-fps-r | 4
> tests/ref/fate/filter-mpdecimate | 1 -
> tests/ref/fate/m4v-cfr | 1 -
> 5 files changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
> index 20ccd797d1..09fc66a73c 100644
> --- a/libavfilter/vf_fps.c
> +++ b/libavfilter/vf_fps.c
> @@ -34,6 +34,8 @@
> #include "libavutil/opt.h"
> #include "libavutil/parseutils.h"
>
> +#define FF_INTERNAL_FIELDS 1
> +#include "framequeue.h"
> #include "avfilter.h"
> #include "internal.h"
> #include "video.h"
> @@ -137,13 +139,45 @@ static int request_frame(AVFilterLink *outlink)
> AVFrame *buf;
>
> av_fifo_generic_read(s->fifo, &buf, sizeof(buf), NULL);
> -buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> -outlink->time_base) + s->frames_out;
> +if (av_fifo_size(s->fifo)) {
> +buf->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
>
> -if ((ret = ff_filter_frame(outlink, buf)) < 0)
> -return ret;
> +if ((ret = ff_filter_frame(outlink, buf)) < 0)
> +return ret;
>
> -s->frames_out++;
> +s->frames_out++;
> +} else {
> +/* This is the last frame, we may have to duplicate it to
> match
> + * the last frame duration */
> +int j;
> +int delta = av_rescale_q_rnd(ctx->inputs[0]->current_pts
> - s->first_pts,
> + ctx->inputs[0]->time_base,
> + outlink->time_base,
> s->rounding) - s->frames_out ;
> +/* if the delta is equal to 1, it means we just need to
> output
> + * the last frame. Greater than 1 means we will need
> duplicate
> + * delta-1 frames */
> +if (delta > 0 ) {
> +for (j = 0; j < delta; j++) {
> +AVFrame *dup = av_frame_clone(buf);
> +
> +av_log(ctx, AV_LOG_DEBUG, "Duplicating frame.\n");
> +dup->pts = av_rescale_q(s->first_pts,
> ctx->inputs[0]->time_base,
> +outlink->time_base) +
> s->frames_out;
> +
> +if ((ret = ff_filter_frame(outlink, dup)) < 0)
> +return ret;
> +
> +s->frames_out++;
> +if (j > 0) s->dup++;
> +}
> +} else {
> +/* for delta less or equal to 0, we should drop the
> frame,
> + * otherwise, we will have one or more extra frames */
> +av_frame_free(&buf);
> +s->drop++;
> +}
> +}
> }
> return 0;
> }
> diff --git a/tests/ref/fate/filter-fps b/tests/ref/fate/filter-fps
> index 55712cfb1c..242fb04e85 100644
> --- a/tests/ref/fate/filter-fps
> +++ b/tests/ref/fate/filter-fps
> @@ -85,3 +85,9 @@
> 0, 79, 79,1,30576, 0xa2fcd06f
> 0, 80, 80,1,30576, 0xa2fcd06f
> 0, 81, 81,1,30576, 0xd4150aad
> +0, 82, 82,1,30576, 0xd4150aad
> +0, 83, 83,1,30576, 0xd4150aad
> +0, 84, 84,1,30576, 0xd4150aad
> +0, 85, 85,1,30576, 0xd4150aad
> +0, 86, 86,1,30576, 0xd4150aad
> +0, 87, 87,1,30576, 0xd4150aad
> diff --git a/tests/ref/fate/filter-fps-r b/tests/ref/fate/filter-fps-r
> index 826b1ed6c6..c1bc7d1547 100644
> --- a/tests/ref/fate/filter-fps-r
> +++ b/tests/ref/fate/filter-fps-r
> @@ -72,3 +72,7 @@
> 0, 79, 79,1,30576, 0xa2fcd06f
> 0, 80, 80,1,30576, 0xa2fcd06f
> 0, 82, 82,1,30576, 0xd4150aad
> +0, 83, 83,1,30576, 0xd4150aad
> +0, 84, 84,1,30576, 0xd4150aad
> +0, 85, 85,1,30576, 0xd4150aad
> +0, 86, 86,1,30576, 0xd4150aad
> diff --git a/tests/ref/fate/filter-mpdecimate b/tests/ref/fate/filter-
> mpdecimate
> index d438dacc2e..9c1dc36562 100644
> --- a/tests/ref/fate/filter-mpdecimate
> +++ b/tests/ref/fate/filter-mpdecimate
> @@ -22,4 +22,3 @@
>
Re: [FFmpeg-devel] img2dec: jpeg_probe logic
Can we change mjpeg_probe() then? It has the same problem. "Everything was valid, and there's more than two frames, but it still has lower score than extension-based guess" libavformat/rawdec.c:184 if (nb_invalid == 0 && nb_frames > 2) return AVPROBE_SCORE_EXTENSION / 2; Vadim ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/20] lavc: Add coded bitstream read/write API
On Thu, Sep 14, 2017 at 08:31:28AM +0100, Mark Thompson wrote:
> On 14/09/17 01:42, Michael Niedermayer wrote:
> > On Wed, Sep 13, 2017 at 12:43:53AM +0100, Mark Thompson wrote:
[...]
> >> +int ff_cbs_write_packet(CodedBitstreamContext *ctx,
> >> +AVPacket *pkt,
> >> +CodedBitstreamFragment *frag)
> >> +{
> >> +int err;
> >> +
> >> +err = ff_cbs_write_fragment_data(ctx, frag);
> >> +if (err < 0)
> >> +return err;
> >> +
> >
> >> +av_new_packet(pkt, frag->data_size);
> >> +if (err < 0)
> >> +return err;
> >
> > that does not work
>
> I think I'm missing something. Can you be more precise about what doesn't
> work?
you ignore the return code of av_new_packet()
the check does nothing
[...]
> >> + */
> >> +int nb_units;
> >> +/**
> >> + * Pointer to an array of units of length nb_units.
> >> + *
> >> + * Must be NULL if nb_units is zero.
> >> + */
> >> +CodedBitstreamUnit *units;
> >> +} CodedBitstreamFragment;
> >> +
> >> +/**
> >> + * Context structure for coded bitstream operations.
> >> + */
> >> +typedef struct CodedBitstreamContext {
> >> +/**
> >> + * Logging context to be passed to all av_log() calls associated
> >> + * with this context.
> >> + */
> >> +void *log_ctx;
> >> +
> >> +/**
> >> + * Internal codec-specific hooks.
> >> + */
> >> +const struct CodedBitstreamType *codec;
> >> +
> >> +/**
> >> + * Internal codec-specific data.
> >> + *
> >> + * This contains any information needed when reading/writing
> >> + * bitsteams which will not necessarily be present in a fragment.
> >> + * For example, for H.264 it contains all currently visible
> >> + * parameter sets - they are required to determine the bitstream
> >> + * syntax but need not be present in every access unit.
> >> + */
> >> +void *priv_data;
> >> +
> >
> >> +/**
> >> + * Array of unit types which should be decomposed when reading.
> >> + *
> >> + * Types not in this list will be available in bitstream form only.
> >> + * If NULL, all supported types will be decomposed.
> >> + */
> >> +uint32_t *decompose_unit_types;
> >
> > this should not be a generic integer.
> > a typedef or enum would be better
>
> It's H.264 nal unit types union H.265 nal unit types union MPEG-2 start codes
> (union any other codec that gets added).
>
> What type should that be? I chose uint32_t to make it fixed-size and
> hopefully large enough to be able to make sense for any future codec.
a typedef based type would be better than a litterally hardcoded
one. A hardcoded type would be duplicatedly hardcoded in many
places ...
Also please document that the type is codec specific (it is IIUC)
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3] avfilter/interlace: add support for 10 and 12 bit
Hi, this patch set adds support for 10 and 12 bit to the interlace filters. This is useful for broadcasters transcoding high bit depth sources to AVC Intra or similar 10 bit video codecs. These patches need to be applied on top of the following patch, which is not pushed yet: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215621.html Please comment. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/20] lavc: Add coded bitstream read/write API
On 14/09/17 21:28, Michael Niedermayer wrote:
> On Thu, Sep 14, 2017 at 08:31:28AM +0100, Mark Thompson wrote:
>> On 14/09/17 01:42, Michael Niedermayer wrote:
>>> On Wed, Sep 13, 2017 at 12:43:53AM +0100, Mark Thompson wrote:
> [...]
>
+int ff_cbs_write_packet(CodedBitstreamContext *ctx,
+AVPacket *pkt,
+CodedBitstreamFragment *frag)
+{
+int err;
+
+err = ff_cbs_write_fragment_data(ctx, frag);
+if (err < 0)
+return err;
+
>>>
+av_new_packet(pkt, frag->data_size);
+if (err < 0)
+return err;
>>>
>>> that does not work
>>
>> I think I'm missing something. Can you be more precise about what doesn't
>> work?
>
> you ignore the return code of av_new_packet()
> the check does nothing
Duh, oops. I spent a while looking for some subtlety in av_new_packet() and
missed the obvious. Sorry!
+ */
+int nb_units;
+/**
+ * Pointer to an array of units of length nb_units.
+ *
+ * Must be NULL if nb_units is zero.
+ */
+CodedBitstreamUnit *units;
+} CodedBitstreamFragment;
+
+/**
+ * Context structure for coded bitstream operations.
+ */
+typedef struct CodedBitstreamContext {
+/**
+ * Logging context to be passed to all av_log() calls associated
+ * with this context.
+ */
+void *log_ctx;
+
+/**
+ * Internal codec-specific hooks.
+ */
+const struct CodedBitstreamType *codec;
+
+/**
+ * Internal codec-specific data.
+ *
+ * This contains any information needed when reading/writing
+ * bitsteams which will not necessarily be present in a fragment.
+ * For example, for H.264 it contains all currently visible
+ * parameter sets - they are required to determine the bitstream
+ * syntax but need not be present in every access unit.
+ */
+void *priv_data;
+
>>>
+/**
+ * Array of unit types which should be decomposed when reading.
+ *
+ * Types not in this list will be available in bitstream form only.
+ * If NULL, all supported types will be decomposed.
+ */
+uint32_t *decompose_unit_types;
>>>
>>> this should not be a generic integer.
>>> a typedef or enum would be better
>>
>> It's H.264 nal unit types union H.265 nal unit types union MPEG-2 start
>> codes (union any other codec that gets added).
>>
>> What type should that be? I chose uint32_t to make it fixed-size and
>> hopefully large enough to be able to make sense for any future codec.
>
> a typedef based type would be better than a litterally hardcoded
> one. A hardcoded type would be duplicatedly hardcoded in many
> places ...
So have "typedef uint32_t CBSUnitType;"? I'm not really sure this adds
anything since every implementation is using its own enum anyway, but ok.
> Also please document that the type is codec specific (it is IIUC)
Yes; above there is:
"""
typedef struct CodedBitstreamUnit {
/**
* Codec-specific type of this unit.
*/
uint32_t type;
"""
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avfilter/tinterlace: use drawutils for pad mode
Patch attached 0002-avfilter-tinterlace-use-drawutils-for-pad-mode.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avfilter/interlace: add support for 10 and 12 bit
Patch attached 0003-avfilter-interlace-add-support-for-10-and-12-bit.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avfilter/interlace: simplify code
Patch attached 0001-avfilter-interlace-simplify-code.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc: Mark functions where ignoring returned error code is always wrong
--- There are more around, but this marks all of the obvious ones in avcodec.h. (Prompted by my own stupid error in <01ec4b44-1857-fdf4-ba1d-84fcac474...@jkqxz.net>.) libavcodec/avcodec.h | 13 + 1 file changed, 13 insertions(+) diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index 5c84974e03..758686af23 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -4483,6 +4483,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec, * @see avcodec_alloc_context3(), avcodec_find_decoder(), avcodec_find_encoder(), * av_dict_set(), av_opt_find(). */ +av_warn_unused_result int avcodec_open2(AVCodecContext *avctx, const AVCodec *codec, AVDictionary **options); /** @@ -4568,6 +4569,7 @@ void av_init_packet(AVPacket *pkt); * @param size wanted payload size * @return 0 if OK, AVERROR_xxx otherwise */ +av_warn_unused_result int av_new_packet(AVPacket *pkt, int size); /** @@ -4584,6 +4586,7 @@ void av_shrink_packet(AVPacket *pkt, int size); * @param pkt packet * @param grow_by number of bytes by which to increase the size of the packet */ +av_warn_unused_result int av_grow_packet(AVPacket *pkt, int grow_by); /** @@ -4736,6 +4739,7 @@ void av_packet_free_side_data(AVPacket *pkt); * * @return 0 on success, a negative AVERROR on error. */ +av_warn_unused_result int av_packet_ref(AVPacket *dst, const AVPacket *src); /** @@ -4814,6 +4818,7 @@ AVCodec *avcodec_find_decoder_by_name(const char *name); * it can be called by custom get_buffer2() implementations for decoders without * AV_CODEC_CAP_DR1 set. */ +av_warn_unused_result int avcodec_default_get_buffer2(AVCodecContext *s, AVFrame *frame, int flags); #if FF_API_EMU_EDGE @@ -5060,6 +5065,7 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub, * AVERROR(ENOMEM): failed to add packet to internal queue, or similar * other errors: legitimate decoding errors */ +av_warn_unused_result int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt); /** @@ -5080,6 +5086,7 @@ int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt); * AVERROR(EINVAL): codec not opened, or it is an encoder * other negative values: legitimate decoding errors */ +av_warn_unused_result int avcodec_receive_frame(AVCodecContext *avctx, AVFrame *frame); /** @@ -5117,6 +5124,7 @@ int avcodec_receive_frame(AVCodecContext *avctx, AVFrame *frame); * AVERROR(ENOMEM): failed to add packet to internal queue, or similar * other errors: legitimate decoding errors */ +av_warn_unused_result int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); /** @@ -5134,6 +5142,7 @@ int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); * AVERROR(EINVAL): codec not opened, or it is an encoder * other errors: legitimate decoding errors */ +av_warn_unused_result int avcodec_receive_packet(AVCodecContext *avctx, AVPacket *avpkt); @@ -6091,12 +6100,14 @@ const AVBitStreamFilter *av_bsf_next(void **opaque); * * @return 0 on success, a negative AVERROR code on failure */ +av_warn_unused_result int av_bsf_alloc(const AVBitStreamFilter *filter, AVBSFContext **ctx); /** * Prepare the filter for use, after all the parameters and options have been * set. */ +av_warn_unused_result int av_bsf_init(AVBSFContext *ctx); /** @@ -6114,6 +6125,7 @@ int av_bsf_init(AVBSFContext *ctx); * * @return 0 on success, a negative AVERROR on error. */ +av_warn_unused_result int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt); /** @@ -6140,6 +6152,7 @@ int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt); * output fewer packets than were sent to it, so this function may return * AVERROR(EAGAIN) immediately after a successful av_bsf_send_packet() call. */ +av_warn_unused_result int av_bsf_receive_packet(AVBSFContext *ctx, AVPacket *pkt); /** -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vaapi: Disable deprecation warnings around use of old struct vaapi_context
---
libavcodec/vaapi_decode.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 4fe414c504..550ee05432 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -59,9 +59,11 @@ typedef struct VAAPIDecodeContext {
VAContextID va_context;
#if FF_API_STRUCT_VAAPI_CONTEXT
+FF_DISABLE_DEPRECATION_WARNINGS
int have_old_context;
struct vaapi_context *old_context;
AVBufferRef *device_ref;
+FF_ENABLE_DEPRECATION_WARNINGS
#endif
AVHWDeviceContext*device;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/http: Reset encoding on redirect
Hi! Attached patch fixes ticket #. Please comment, Carl Eugen From 479e3b2097a73a918f0c62cb6e3d661f9e71c5d0 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 14 Sep 2017 23:21:53 +0200 Subject: [PATCH] lavf/http: Reset encoding on redirect. Fixes ticket #. --- libavformat/http.c |1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/http.c b/libavformat/http.c index 30890bb..d835f22 100644 --- a/libavformat/http.c +++ b/libavformat/http.c @@ -287,6 +287,7 @@ redo: memset(&s->auth_state, 0, sizeof(s->auth_state)); attempts = 0; location_changed = 0; +s->compressed= 0; goto redo; } return 0; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber
2017-09-07 23:56 GMT+02:00 Mark Thompson :
> +static const struct {
> +enum AVPixelFormat pixfmt;
> +uint32_t drm_format;
> +} kmsgrab_formats[] = {
> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8 },
> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16 },
> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888 },
> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888 },
> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
> +{ AV_PIX_FMT_YUYV422, DRM_FORMAT_YUYV },
> +{ AV_PIX_FMT_YVYU422, DRM_FORMAT_YVYU },
> +{ AV_PIX_FMT_UYVY422, DRM_FORMAT_UYVY },
> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
> +{ AV_PIX_FMT_YUV420P, DRM_FORMAT_YUV420 },
> +{ AV_PIX_FMT_YUV422P, DRM_FORMAT_YUV422 },
> +{ AV_PIX_FMT_YUV444P, DRM_FORMAT_YUV444 },
Which of those were you able to test?
I find the comments in the header file very misleading:
What is "little-endian 8:8:8:8 ARGB"?
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Consider 0x0f just a hint towards aac
On Wed, Sep 13, 2017 at 07:12:17PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #6657. > > Please comment, Carl Eugen > mpegts.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 370a433251f563e16b654eeca8bb3463e787fd61 > 0001-lavf-mpegts-Consider-stream_type-0x0f-just-a-hint-to.patch > From d806a243e97de8c245958dc6f8d2646217cc5105 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Wed, 13 Sep 2017 19:05:10 +0200 > Subject: [PATCH] lavf/mpegts: Consider stream_type 0x0f just a hint toward > AAC. > > It is also used in the wild to signal latm. > > Fixes ticket #6657. > --- > libavformat/mpegts.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) should be ok unless this causes common streams to be slowed down in a non trivial way in terms of data/time needed for detection also please add a fate test, if the file is not too large [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 03/20] lavc: Add coded bitstream read/write API
On Thu, Sep 14, 2017 at 09:51:31PM +0100, Mark Thompson wrote:
> On 14/09/17 21:28, Michael Niedermayer wrote:
> > On Thu, Sep 14, 2017 at 08:31:28AM +0100, Mark Thompson wrote:
> >> On 14/09/17 01:42, Michael Niedermayer wrote:
> >>> On Wed, Sep 13, 2017 at 12:43:53AM +0100, Mark Thompson wrote:
> > [...]
> >
> +int ff_cbs_write_packet(CodedBitstreamContext *ctx,
> +AVPacket *pkt,
> +CodedBitstreamFragment *frag)
> +{
> +int err;
> +
> +err = ff_cbs_write_fragment_data(ctx, frag);
> +if (err < 0)
> +return err;
> +
> >>>
> +av_new_packet(pkt, frag->data_size);
> +if (err < 0)
> +return err;
> >>>
> >>> that does not work
> >>
> >> I think I'm missing something. Can you be more precise about what doesn't
> >> work?
> >
> > you ignore the return code of av_new_packet()
> > the check does nothing
>
> Duh, oops. I spent a while looking for some subtlety in av_new_packet() and
> missed the obvious. Sorry!
>
> + */
> +int nb_units;
> +/**
> + * Pointer to an array of units of length nb_units.
> + *
> + * Must be NULL if nb_units is zero.
> + */
> +CodedBitstreamUnit *units;
> +} CodedBitstreamFragment;
> +
> +/**
> + * Context structure for coded bitstream operations.
> + */
> +typedef struct CodedBitstreamContext {
> +/**
> + * Logging context to be passed to all av_log() calls associated
> + * with this context.
> + */
> +void *log_ctx;
> +
> +/**
> + * Internal codec-specific hooks.
> + */
> +const struct CodedBitstreamType *codec;
> +
> +/**
> + * Internal codec-specific data.
> + *
> + * This contains any information needed when reading/writing
> + * bitsteams which will not necessarily be present in a fragment.
> + * For example, for H.264 it contains all currently visible
> + * parameter sets - they are required to determine the bitstream
> + * syntax but need not be present in every access unit.
> + */
> +void *priv_data;
> +
> >>>
> +/**
> + * Array of unit types which should be decomposed when reading.
> + *
> + * Types not in this list will be available in bitstream form only.
> + * If NULL, all supported types will be decomposed.
> + */
> +uint32_t *decompose_unit_types;
> >>>
> >>> this should not be a generic integer.
> >>> a typedef or enum would be better
> >>
> >> It's H.264 nal unit types union H.265 nal unit types union MPEG-2 start
> >> codes (union any other codec that gets added).
> >>
> >> What type should that be? I chose uint32_t to make it fixed-size and
> >> hopefully large enough to be able to make sense for any future codec.
> >
> > a typedef based type would be better than a litterally hardcoded
> > one. A hardcoded type would be duplicatedly hardcoded in many
> > places ...
>
> So have "typedef uint32_t CBSUnitType;"? I'm not really sure this adds
> anything since every implementation is using its own enum anyway, but ok.
duplication is bad
consider you ever want to change the underlaying type ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: Mark functions where ignoring returned error code is always wrong
On Thu, 14 Sep 2017, Mark Thompson wrote: --- There are more around, but this marks all of the obvious ones in avcodec.h. [...] +av_warn_unused_result int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt); */ +av_warn_unused_result int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); I am not sure about these, these can only fail with ENOMEM if the user always gets all available frames/packets, but even if there is no memory, no state will be changed, the ownership of the packet/frame will remain with the caller, no null pointer will be returned, so if ignoring these is what the user wants, then so be it, no "undefined" behaviour will occur and we are not breaking the API contract by continuing like nothing happened. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] kmsgrab: fix build error when use old libdrm
On 14/09/17 11:02, Mark Thompson wrote:
> On 14/09/17 01:34, Jun Zhao wrote:
>> From 8c7ddfcabf686f213aa59544d90055d20bdac0f7 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Wed, 13 Sep 2017 20:21:38 -0400
>> Subject: [PATCH] kmsgrab: fix build error when use old libdrm
>>
>> DRM_FORMAT_R16 adding from libdrm 2.4.82, fix the build error
>> when libdrm < 2.4.82.
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavdevice/kmsgrab.c | 2 ++
>> libavutil/hwcontext_vaapi.c | 2 +-
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
>> index d0b9cf5001..49eb44f6f2 100644
>> --- a/libavdevice/kmsgrab.c
>> +++ b/libavdevice/kmsgrab.c
>> @@ -203,7 +203,9 @@ static const struct {
>> uint32_t drm_format;
>> } kmsgrab_formats[] = {
>> { AV_PIX_FMT_GRAY8,DRM_FORMAT_R8 },
>> +#ifdef DRM_FORMAT_R16
>> { AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16 },
>> +#endif
>> { AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888 },
>> { AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888 },
>> { AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>> index 2cc6f26715..837b79da11 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -920,7 +920,7 @@ static const struct {
>> } vaapi_drm_format_map[] = {
>> DRM_MAP(NV12, 2, DRM_FORMAT_R8, DRM_FORMAT_RG88),
>> DRM_MAP(NV12, 1, DRM_FORMAT_NV12),
>> -#ifdef VA_FOURCC_P010
>> +#if defined(VA_FOURCC_P010) && defined(DRM_FORMAT_R16)
>> DRM_MAP(P010, 2, DRM_FORMAT_R16, DRM_FORMAT_RG1616),
>> #endif
>> DRM_MAP(BGRA, 1, DRM_FORMAT_BGRA),
>> --
>> 2.11.0
>>
>
> R8/RG88 can be a problem as well (2.4.68). Also, this should be two patches
> (one for each of the two components).
>
> I can split and add that later myself, or you can send a new version if you
> prefer?
Split, added the other case, applied.
Thanks!
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Consider 0x0f just a hint towards aac
2017-09-14 23:48 GMT+02:00 Michael Niedermayer : > also please add a fate test, if the file is not too large Are 10 bytes ok? The alternative is to simply mux any latm sample into mpegts with patched FFmpeg to force id 0x0f. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: Mark functions where ignoring returned error code is always wrong
On 14/09/17 22:54, Marton Balint wrote: > > On Thu, 14 Sep 2017, Mark Thompson wrote: > >> --- >> There are more around, but this marks all of the obvious ones in avcodec.h. >> > > [...] > >> +av_warn_unused_result >> int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt); > >> */ >> +av_warn_unused_result >> int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); > > I am not sure about these, these can only fail with ENOMEM if the user always > gets all available frames/packets, but even if there is no memory, no state > will be changed, the ownership of the packet/frame will remain with the > caller, no null pointer will be returned, so if ignoring these is what the > user wants, then so be it, no "undefined" behaviour will occur and we are not > breaking the API contract by continuing like nothing happened. I was primarily thinking of the EAGAIN case, where the input data will just have been silently discarded if the user ignores the return value. I admit that isn't quite the same as the failed-allocation ones which result in undefined behaviour, but I don't think ignoring the return value of any of the send/receive functions is sane on the part of the user. What do you think? (I could also split the patch into ENOMEM and other cases if that helps.) - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC
On Thu, 14 Sep 2017, Jeyapal, Karthick wrote: Hi Marton, Thanks a lot for your comments. I have modified the patch as per all your comments, except the below one. +tgt = teletext_data_unit_from_ancillary_packet(buf, buf + 1920, tgt, cctx->teletext_lines, 0); this should be tgt = teletext_data_unit_from_ancillary_packet(buf, buf + len, tgt, cctx->teletext_lines, 1); I have modified it as tgt = teletext_data_unit_from_ancillary_packet(buf, buf + len, tgt, cctx->teletext_lines, 0); That was just to be in consistency with the existing code. Because current code passes allow_multipacket as 0. Let me know if my understanding here is correct. Shoot, then the original code was incorrect :). I will take a final look at your patches next week. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: Mark functions where ignoring returned error code is always wrong
On Thu, 14 Sep 2017, Mark Thompson wrote: On 14/09/17 22:54, Marton Balint wrote: On Thu, 14 Sep 2017, Mark Thompson wrote: --- There are more around, but this marks all of the obvious ones in avcodec.h. [...] +av_warn_unused_result int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt); */ +av_warn_unused_result int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); I am not sure about these, these can only fail with ENOMEM if the user always gets all available frames/packets, but even if there is no memory, no state will be changed, the ownership of the packet/frame will remain with the caller, no null pointer will be returned, so if ignoring these is what the user wants, then so be it, no "undefined" behaviour will occur and we are not breaking the API contract by continuing like nothing happened. I was primarily thinking of the EAGAIN case, where the input data will just have been silently discarded if the user ignores the return value. I admit that isn't quite the same as the failed-allocation ones which result in undefined behaviour, but I don't think ignoring the return value of any of the send/receive functions is sane on the part of the user. What do you think? (I could also split the patch into ENOMEM and other cases if that helps.) If the send/receive API is used in a way that receive is called in a loop until EAGAIN is returned after each send, that ensures that no EAGAIN can occur in send. ffplay does exactly that and the only reason it does not ignore the return value of send_packet is to be able to warn the user about API violations, which - in theory - should not happen. So I'd rather not tag these functions as warn_unused_result, but if others disagree, I don't mind too much if the patch goes in as is. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber
On 14/09/17 22:30, Carl Eugen Hoyos wrote:
> 2017-09-07 23:56 GMT+02:00 Mark Thompson :
>
>> +static const struct {
>> +enum AVPixelFormat pixfmt;
>> +uint32_t drm_format;
>> +} kmsgrab_formats[] = {
>> +{ AV_PIX_FMT_GRAY8,DRM_FORMAT_R8 },
>> +{ AV_PIX_FMT_GRAY16LE, DRM_FORMAT_R16 },
>> +{ AV_PIX_FMT_RGB24,DRM_FORMAT_RGB888 },
>> +{ AV_PIX_FMT_BGR24,DRM_FORMAT_BGR888 },
>> +{ AV_PIX_FMT_0RGB, DRM_FORMAT_XRGB },
>> +{ AV_PIX_FMT_0BGR, DRM_FORMAT_XBGR },
>> +{ AV_PIX_FMT_RGB0, DRM_FORMAT_RGBX },
>> +{ AV_PIX_FMT_BGR0, DRM_FORMAT_BGRX },
>> +{ AV_PIX_FMT_ARGB, DRM_FORMAT_ARGB },
>> +{ AV_PIX_FMT_ABGR, DRM_FORMAT_ABGR },
>> +{ AV_PIX_FMT_RGBA, DRM_FORMAT_RGBA },
>> +{ AV_PIX_FMT_BGRA, DRM_FORMAT_BGRA },
>> +{ AV_PIX_FMT_YUYV422, DRM_FORMAT_YUYV },
>> +{ AV_PIX_FMT_YVYU422, DRM_FORMAT_YVYU },
>> +{ AV_PIX_FMT_UYVY422, DRM_FORMAT_UYVY },
>> +{ AV_PIX_FMT_NV12, DRM_FORMAT_NV12 },
>> +{ AV_PIX_FMT_YUV420P, DRM_FORMAT_YUV420 },
>> +{ AV_PIX_FMT_YUV422P, DRM_FORMAT_YUV422 },
>> +{ AV_PIX_FMT_YUV444P, DRM_FORMAT_YUV444 },
>
> Which of those were you able to test?
Only the 32-bit RGB0-type ones (all of them are testable because you just get
the colours in a different order). Intel at least should work with others in
near-future versions (e.g.
),
though I haven't actually tested this. It seemed sensible to include all core
DRM formats which map to ffmpeg pixfmts to account for other drivers (possibly
future) which I can't test now.
I've tested on amdgpu, exynos, i915 and rockchip. It should work on other KMS
drivers, though if the output is tiled or not-CPU-mappable it can be hard to
get the output somewhere where it can actually be used. (The ARM ones are fine
and allow hwdownload directly. Intels I've tried are mappable but tiled so
hwdownload is messed up, but they interoperate cleanly with VAAPI. The AMD I
have makes the objects completely unmappable from the CPU, but they can be
imported to other GPU things with Mesa.)
> I find the comments in the header file very misleading:
> What is "little-endian 8:8:8:8 ARGB"?
It is just A-R-G-B in memory in that order as you might expect without the
comment. Not sure why it says little-endian - maybe to emphasise that it
doesn't change based on the host architecture?
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc: Mark functions where ignoring returned error code is always wrong
On 14/09/17 23:35, Marton Balint wrote: > > On Thu, 14 Sep 2017, Mark Thompson wrote: > >> On 14/09/17 22:54, Marton Balint wrote: >>> >>> On Thu, 14 Sep 2017, Mark Thompson wrote: >>> --- There are more around, but this marks all of the obvious ones in avcodec.h. >>> >>> [...] >>> +av_warn_unused_result int avcodec_send_packet(AVCodecContext *avctx, const AVPacket *avpkt); >>> */ +av_warn_unused_result int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame); >>> >>> I am not sure about these, these can only fail with ENOMEM if the user >>> always gets all available frames/packets, but even if there is no memory, >>> no state will be changed, the ownership of the packet/frame will remain >>> with the caller, no null pointer will be returned, so if ignoring these is >>> what the user wants, then so be it, no "undefined" behaviour will occur and >>> we are not breaking the API contract by continuing like nothing happened. >> >> I was primarily thinking of the EAGAIN case, where the input data will just >> have been silently discarded if the user ignores the return value. I admit >> that isn't quite the same as the failed-allocation ones which result in >> undefined behaviour, but I don't think ignoring the return value of any of >> the send/receive functions is sane on the part of the user. >> >> What do you think? (I could also split the patch into ENOMEM and other >> cases if that helps.) > > If the send/receive API is used in a way that receive is called in a loop > until EAGAIN is returned after each send, that ensures that no EAGAIN can > occur in send. > > ffplay does exactly that and the only reason it does not ignore the return > value of send_packet is to be able to warn the user about API violations, > which - in theory - should not happen. > > So I'd rather not tag these functions as warn_unused_result, but if others > disagree, I don't mind too much if the patch goes in as is. Ok, that's fair. I've removed the annotation from the the send functions - these two and also av_bsf_send_packet(). Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber
Mark Thompson wrote: --- Now sets the trusted packet flag; otherwise unchanged. configure| 1 + libavdevice/Makefile | 1 + libavdevice/alldevices.c | 1 + libavdevice/kmsgrab.c| 455 +++ 4 files changed, 458 insertions(+) create mode 100644 libavdevice/kmsgrab.c diff --git a/configure b/configure index 6581c53c1a..76a7591ceb 100755 --- a/configure +++ b/configure @@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder" iec61883_indev_deps="libiec61883" jack_indev_deps="jack" jack_indev_deps_any="sem_timedwait dispatch_dispatch_h" +kmsgrab_indev_deps="libdrm" Doesn't get built for me = doesn't show up as indev after configure anything special needed? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber
Andy Furniss wrote: Mark Thompson wrote: --- Now sets the trusted packet flag; otherwise unchanged. configure| 1 + libavdevice/Makefile | 1 + libavdevice/alldevices.c | 1 + libavdevice/kmsgrab.c| 455 +++ 4 files changed, 458 insertions(+) create mode 100644 libavdevice/kmsgrab.c diff --git a/configure b/configure index 6581c53c1a..76a7591ceb 100755 --- a/configure +++ b/configure @@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder" iec61883_indev_deps="libiec61883" jack_indev_deps="jack" jack_indev_deps_any="sem_timedwait dispatch_dispatch_h" +kmsgrab_indev_deps="libdrm" Doesn't get built for me = doesn't show up as indev after configure anything special needed? Never mind I found --enable-libdrm (had tried --enable-kmsgrab) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc lpf msa functions
On Wed, Sep 13, 2017 at 09:30:45AM +, Manojkumar Bhosale wrote: > LGTM applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve hevc idct msa functions
On Wed, Sep 13, 2017 at 09:31:00AM +, Manojkumar Bhosale wrote: > LGTM applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavd: Add KMS frame grabber
On 15/09/17 00:15, Andy Furniss wrote: > Andy Furniss wrote: >> Mark Thompson wrote: >>> --- >>> Now sets the trusted packet flag; otherwise unchanged. >>> >>> >>> configure | 1 + >>> libavdevice/Makefile | 1 + >>> libavdevice/alldevices.c | 1 + >>> libavdevice/kmsgrab.c | 455 >>> +++ >>> 4 files changed, 458 insertions(+) >>> create mode 100644 libavdevice/kmsgrab.c >>> >>> diff --git a/configure b/configure >>> index 6581c53c1a..76a7591ceb 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -3040,6 +3040,7 @@ gdigrab_indev_select="bmp_decoder" >>> iec61883_indev_deps="libiec61883" >>> jack_indev_deps="jack" >>> jack_indev_deps_any="sem_timedwait dispatch_dispatch_h" >>> +kmsgrab_indev_deps="libdrm" >> >> Doesn't get built for me = doesn't show up as indev after configure anything >> special needed? > > Never mind I found --enable-libdrm (had tried --enable-kmsgrab) I assume you're going to try AMD + Mesa + VAAPI. VAAPI_DISABLE_INTERLACE=1 ./ffmpeg_g -y -format bgr0 -device /dev/dri/card1 -f kmsgrab -i - -vsync 0 -init_hw_device vaapi=v:/dev/dri/renderD129 -filter_hw_device v -vf 'hwmap,scale_vaapi=w=1920:h=1080:format=nv12' -c:v h264_vaapi -profile 578 -bf 0 out.mp4 Three Mesa issues I had to get around: * Device derivation doesn't work because the Mesa driver doesn't want to initialise on the DRM master device for some reason; making the matching device separately does work. * Against current git, you need to reapply the VAAPI_DISABLE_INTERLACE patch and use it - if not, the colour conversion just barfs because it wants interlaced surfaces. * The postproc scaler seems to only write the luma plane when converting from RGB - this is also visible when uploading normal RGB images, so just a bug somewhere. With that, it works to record the screen in greyscale... I have some other Mesa stuff to do queued up (libva2 with VAAPI export for EGL import on AMD), so I'll pursue these further soonish. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in avctx
On Wed, Sep 13, 2017 at 08:11:38PM +0200, Reimar Döffinger wrote: > On Wed, Sep 13, 2017 at 07:12:48PM +0200, Reimar Döffinger wrote: > > This is the equivalent to what 7d317d4706b49d572a1eb5269438753be18362c7 > > did for the codec-specific options. > > av_opt_copy has specific handling so it's fine that we already copied > > the whole context before. the change looks reasonable > > Btw, if someone can make time for reviewing it that would likely > be time well spent. you mean reviewing the whole frame_thread_encoder code searching for issues unrelated to tickets or patches ? ATM i think i have too much i should have done "yesterday" to add that > For example it seems the code also leaks the memory for the AVPacket > it mallocs sometimes. is there some way by which this can be reproduced or is it completely random ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Consider 0x0f just a hint towards aac
On Fri, Sep 15, 2017 at 12:13:56AM +0200, Carl Eugen Hoyos wrote: > 2017-09-14 23:48 GMT+02:00 Michael Niedermayer : > > > also please add a fate test, if the file is not too large > > Are 10 bytes ok? with mpeg-ts, i think its ok > The alternative is to simply mux any latm sample into mpegts > with patched FFmpeg to force id 0x0f. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.
On Tue, Sep 12, 2017 at 06:45:57PM -0700, Thierry Foucu wrote: > Fix ticket #2674 > Tested with examples from ticket 2674. > --- > Sorry Michael, I forgot to configure using --enable-gpl. > Please find new patch. > > > libavfilter/vf_fps.c | 44 > +++- > tests/ref/fate/filter-fps| 6 ++ > tests/ref/fate/filter-fps-r | 4 > tests/ref/fate/filter-mpdecimate | 1 - > tests/ref/fate/m4v-cfr | 1 - > 5 files changed, 49 insertions(+), 7 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/hevc_sei: Support HEVC paired fields.
Correctly set frame.interlaced and frame.top_field_first when pic_struct
indicates paired fields.
---
libavcodec/hevc_sei.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index cd55d50..d0f9966 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -137,10 +137,10 @@ static int decode_nal_sei_pic_timing(HEVCSEIContext *s,
GetBitContext *gb, const
if (sps->vui.frame_field_info_present_flag) {
int pic_struct = get_bits(gb, 4);
h->picture_struct = AV_PICTURE_STRUCTURE_UNKNOWN;
-if (pic_struct == 2) {
+if (pic_struct == 2 || pic_struct == 10 || pic_struct == 12) {
av_log(logctx, AV_LOG_DEBUG, "BOTTOM Field\n");
h->picture_struct = AV_PICTURE_STRUCTURE_BOTTOM_FIELD;
-} else if (pic_struct == 1) {
+} else if (pic_struct == 1 || pic_struct == 9 || pic_struct == 11) {
av_log(logctx, AV_LOG_DEBUG, "TOP Field\n");
h->picture_struct = AV_PICTURE_STRUCTURE_TOP_FIELD;
}
--
2.7.4
.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mips: Improve avc lpf msa functions
From: Kaustubh Raste
Optimize luma intra case by reducing conditional cases.
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/h264dsp_msa.c | 428 +
1 file changed, 138 insertions(+), 290 deletions(-)
diff --git a/libavcodec/mips/h264dsp_msa.c b/libavcodec/mips/h264dsp_msa.c
index 16e4858..a17eacb 100644
--- a/libavcodec/mips/h264dsp_msa.c
+++ b/libavcodec/mips/h264dsp_msa.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015 Parag Salasakar (parag.salasa...@imgtec.com)
+ * Copyright (c) 2015 - 2017 Parag Salasakar (parag.salasa...@imgtec.com)
*
* This file is part of FFmpeg.
*
@@ -644,96 +644,69 @@ static void
avc_loopfilter_luma_intra_edge_hor_msa(uint8_t *data,
uint8_t beta_in,
uint32_t img_width)
{
-v16u8 p2_asub_p0, q2_asub_q0, p0_asub_q0;
-v16u8 alpha, beta;
-v16u8 is_less_than, is_less_than_beta, negate_is_less_than_beta;
-v16u8 p2, p1, p0, q0, q1, q2;
-v16u8 p3_org, p2_org, p1_org, p0_org, q0_org, q1_org, q2_org, q3_org;
-v8i16 p1_org_r, p0_org_r, q0_org_r, q1_org_r;
-v8i16 p1_org_l, p0_org_l, q0_org_l, q1_org_l;
-v8i16 p2_r = { 0 };
-v8i16 p1_r = { 0 };
-v8i16 p0_r = { 0 };
-v8i16 q0_r = { 0 };
-v8i16 q1_r = { 0 };
-v8i16 q2_r = { 0 };
-v8i16 p2_l = { 0 };
-v8i16 p1_l = { 0 };
-v8i16 p0_l = { 0 };
-v8i16 q0_l = { 0 };
-v8i16 q1_l = { 0 };
-v8i16 q2_l = { 0 };
-v16u8 tmp_flag;
-v16i8 zero = { 0 };
-
-alpha = (v16u8) __msa_fill_b(alpha_in);
-beta = (v16u8) __msa_fill_b(beta_in);
+v16u8 p0_asub_q0, p1_asub_p0, q1_asub_q0;
+v16u8 is_less_than, is_less_than_beta, is_less_than_alpha;
+v16u8 p1_org, p0_org, q0_org, q1_org;
LD_UB4(data - (img_width << 1), img_width, p1_org, p0_org, q0_org, q1_org);
-{
-v16u8 p1_asub_p0, q1_asub_q0, is_less_than_alpha;
-
-p0_asub_q0 = __msa_asub_u_b(p0_org, q0_org);
-p1_asub_p0 = __msa_asub_u_b(p1_org, p0_org);
-q1_asub_q0 = __msa_asub_u_b(q1_org, q0_org);
+p0_asub_q0 = __msa_asub_u_b(p0_org, q0_org);
+p1_asub_p0 = __msa_asub_u_b(p1_org, p0_org);
+q1_asub_q0 = __msa_asub_u_b(q1_org, q0_org);
-is_less_than_alpha = (p0_asub_q0 < alpha);
-is_less_than_beta = (p1_asub_p0 < beta);
-is_less_than = is_less_than_beta & is_less_than_alpha;
-is_less_than_beta = (q1_asub_q0 < beta);
-is_less_than = is_less_than_beta & is_less_than;
-}
+is_less_than_alpha = (p0_asub_q0 < alpha_in);
+is_less_than_beta = (p1_asub_p0 < beta_in);
+is_less_than = is_less_than_beta & is_less_than_alpha;
+is_less_than_beta = (q1_asub_q0 < beta_in);
+is_less_than = is_less_than_beta & is_less_than;
if (!__msa_test_bz_v(is_less_than)) {
-q2_org = LD_UB(data + (2 * img_width));
-p3_org = LD_UB(data - (img_width << 2));
-p2_org = LD_UB(data - (3 * img_width));
+v16u8 p2_asub_p0, q2_asub_q0, p0, q0, negate_is_less_than_beta;
+v8i16 p0_r = { 0 };
+v8i16 q0_r = { 0 };
+v8i16 p0_l = { 0 };
+v8i16 q0_l = { 0 };
+v16i8 zero = { 0 };
+v8i16 p1_org_r, p0_org_r, q0_org_r, q1_org_r;
+v8i16 p1_org_l, p0_org_l, q0_org_l, q1_org_l;
+v16u8 q2_org = LD_UB(data + (2 * img_width));
+v16u8 p2_org = LD_UB(data - (3 * img_width));
+v16u8 tmp_flag = (v16u8)__msa_fill_b((alpha_in >> 2) + 2);
UNPCK_UB_SH(p1_org, p1_org_r, p1_org_l);
UNPCK_UB_SH(p0_org, p0_org_r, p0_org_l);
UNPCK_UB_SH(q0_org, q0_org_r, q0_org_l);
-tmp_flag = alpha >> 2;
-tmp_flag = tmp_flag + 2;
tmp_flag = (p0_asub_q0 < tmp_flag);
p2_asub_p0 = __msa_asub_u_b(p2_org, p0_org);
-is_less_than_beta = (p2_asub_p0 < beta);
+is_less_than_beta = (p2_asub_p0 < beta_in);
is_less_than_beta = is_less_than_beta & tmp_flag;
negate_is_less_than_beta = __msa_xori_b(is_less_than_beta, 0xff);
is_less_than_beta = is_less_than_beta & is_less_than;
negate_is_less_than_beta = negate_is_less_than_beta & is_less_than;
-{
-v8u16 is_less_than_beta_l, is_less_than_beta_r;
-
-q1_org_r = (v8i16) __msa_ilvr_b(zero, (v16i8) q1_org);
-
-is_less_than_beta_r =
-(v8u16) __msa_sldi_b((v16i8) is_less_than_beta, zero, 8);
-if (!__msa_test_bz_v((v16u8) is_less_than_beta_r)) {
-v8i16 p3_org_r;
-
-ILVR_B2_SH(zero, p3_org, zero, p2_org, p3_org_r, p2_r);
-AVC_LPF_P0P1P2_OR_Q0Q1Q2(p3_org_r, p0_org_r, q0_org_r,
p1_org_r,
- p2_r, q1_org_r, p0_r, p1_r, p2_r);
-}
-
-q1_org_l = (v8i16) __msa_ilvl_b(zero, (v16i8) q1_org);
-is_less_than_beta_l =
-(v8u16) __msa_sldi_b(zero, (v16i8) is_less_than_beta, 8);
[FFmpeg-devel] [PATCH] avcodec/mips: Improve avc mc copy msa functions
From: Kaustubh Raste
Remove loops and unroll as block sizes are known.
Signed-off-by: Kaustubh Raste
---
libavcodec/mips/h264qpel_msa.c | 81 +---
1 file changed, 75 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mips/h264qpel_msa.c b/libavcodec/mips/h264qpel_msa.c
index 43d21f7..05dffea 100644
--- a/libavcodec/mips/h264qpel_msa.c
+++ b/libavcodec/mips/h264qpel_msa.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015 Parag Salasakar (parag.salasa...@imgtec.com)
+ * Copyright (c) 2015 -2017 Parag Salasakar (parag.salasa...@imgtec.com)
*
* This file is part of FFmpeg.
*
@@ -2966,31 +2966,100 @@ static void avg_width16_msa(const uint8_t *src,
int32_t src_stride,
void ff_put_h264_qpel16_mc00_msa(uint8_t *dst, const uint8_t *src,
ptrdiff_t stride)
{
-copy_width16_msa(src, stride, dst, stride, 16);
+v16u8 src0, src1, src2, src3, src4, src5, src6, src7;
+v16u8 src8, src9, src10, src11, src12, src13, src14, src15;
+
+LD_UB8(src, stride, src0, src1, src2, src3, src4, src5, src6, src7);
+src += (8 * stride);
+LD_UB8(src, stride, src8, src9, src10, src11, src12, src13, src14, src15);
+
+ST_UB8(src0, src1, src2, src3, src4, src5, src6, src7, dst, stride);
+dst += (8 * stride);
+ST_UB8(src8, src9, src10, src11, src12, src13, src14, src15, dst, stride);
}
void ff_put_h264_qpel8_mc00_msa(uint8_t *dst, const uint8_t *src,
ptrdiff_t stride)
{
-copy_width8_msa(src, stride, dst, stride, 8);
+uint64_t src0, src1, src2, src3, src4, src5, src6, src7;
+
+LD4(src, stride, src0, src1, src2, src3);
+src += 4 * stride;
+LD4(src, stride, src4, src5, src6, src7);
+SD4(src0, src1, src2, src3, dst, stride);
+dst += 4 * stride;
+SD4(src4, src5, src6, src7, dst, stride);
}
void ff_avg_h264_qpel16_mc00_msa(uint8_t *dst, const uint8_t *src,
ptrdiff_t stride)
{
-avg_width16_msa(src, stride, dst, stride, 16);
+v16u8 src0, src1, src2, src3, src4, src5, src6, src7;
+v16u8 dst0, dst1, dst2, dst3, dst4, dst5, dst6, dst7;
+
+LD_UB8(src, stride, src0, src1, src2, src3, src4, src5, src6, src7);
+src += (8 * stride);
+LD_UB8(dst, stride, dst0, dst1, dst2, dst3, dst4, dst5, dst6, dst7);
+
+AVER_UB4_UB(src0, dst0, src1, dst1, src2, dst2, src3, dst3, dst0, dst1,
+dst2, dst3);
+AVER_UB4_UB(src4, dst4, src5, dst5, src6, dst6, src7, dst7, dst4, dst5,
+dst6, dst7);
+ST_UB8(dst0, dst1, dst2, dst3, dst4, dst5, dst6, dst7, dst, stride);
+dst += (8 * stride);
+
+LD_UB8(src, stride, src0, src1, src2, src3, src4, src5, src6, src7);
+LD_UB8(dst, stride, dst0, dst1, dst2, dst3, dst4, dst5, dst6, dst7);
+
+AVER_UB4_UB(src0, dst0, src1, dst1, src2, dst2, src3, dst3, dst0, dst1,
+dst2, dst3);
+AVER_UB4_UB(src4, dst4, src5, dst5, src6, dst6, src7, dst7, dst4, dst5,
+dst6, dst7);
+ST_UB8(dst0, dst1, dst2, dst3, dst4, dst5, dst6, dst7, dst, stride);
}
void ff_avg_h264_qpel8_mc00_msa(uint8_t *dst, const uint8_t *src,
ptrdiff_t stride)
{
-avg_width8_msa(src, stride, dst, stride, 8);
+uint64_t tp0, tp1, tp2, tp3, tp4, tp5, tp6, tp7;
+v16u8 src0 = { 0 }, src1 = { 0 }, src2 = { 0 }, src3 = { 0 };
+v16u8 dst0 = { 0 }, dst1 = { 0 }, dst2 = { 0 }, dst3 = { 0 };
+
+LD4(src, stride, tp0, tp1, tp2, tp3);
+src += 4 * stride;
+LD4(src, stride, tp4, tp5, tp6, tp7);
+INSERT_D2_UB(tp0, tp1, src0);
+INSERT_D2_UB(tp2, tp3, src1);
+INSERT_D2_UB(tp4, tp5, src2);
+INSERT_D2_UB(tp6, tp7, src3);
+
+LD4(dst, stride, tp0, tp1, tp2, tp3);
+LD4(dst + 4 * stride, stride, tp4, tp5, tp6, tp7);
+INSERT_D2_UB(tp0, tp1, dst0);
+INSERT_D2_UB(tp2, tp3, dst1);
+INSERT_D2_UB(tp4, tp5, dst2);
+INSERT_D2_UB(tp6, tp7, dst3);
+
+AVER_UB4_UB(src0, dst0, src1, dst1, src2, dst2, src3, dst3, dst0, dst1,
+dst2, dst3);
+
+ST8x8_UB(dst0, dst1, dst2, dst3, dst, stride);
}
void ff_avg_h264_qpel4_mc00_msa(uint8_t *dst, const uint8_t *src,
ptrdiff_t stride)
{
-avg_width4_msa(src, stride, dst, stride, 4);
+uint32_t tp0, tp1, tp2, tp3;
+v16u8 src0 = { 0 }, dst0 = { 0 };
+
+LW4(src, stride, tp0, tp1, tp2, tp3);
+INSERT_W4_UB(tp0, tp1, tp2, tp3, src0);
+LW4(dst, stride, tp0, tp1, tp2, tp3);
+INSERT_W4_UB(tp0, tp1, tp2, tp3, dst0);
+
+dst0 = __msa_aver_u_b(src0, dst0);
+
+ST4x4_UB(dst0, dst0, 0, 1, 2, 3, dst, stride);
}
void ff_put_h264_qpel16_mc10_msa(uint8_t *dst, const uint8_t *src,
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
