Re: [FFmpeg-devel] [PATCH 2/6] h264_ps: move and export aspect_ratio
On Sun, Nov 30, 2014 at 12:45:52AM +, Christophe Gisquet wrote: > Needed for filters that may need it, like an SPS bsf. > --- > libavcodec/h264_ps.c | 26 +++--- > libavcodec/h264data.h | 19 +++ > 2 files changed, 22 insertions(+), 23 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] bitstream_filter: add an init function
On Sun, Nov 30, 2014 at 12:45:51AM +, Christophe Gisquet wrote:
> From: Zongyi Zhou
>
> Original patch was adding an arg field in the context structure. As it
> is most often only useful once, allow passing the arguments on init.
>
> The proper solution would be using AVOption, but this is overkill for now.
>
> Signed-off-by: Christophe Gisquet
> ---
> ffmpeg_opt.c | 5 -
> libavcodec/avcodec.h | 5 -
> libavcodec/bitstream_filter.c | 8 +++-
> libavformat/concatdec.c | 2 +-
> libavformat/tee.c | 7 ++-
> 5 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 03e049b..b8cd35d 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -1138,9 +1138,12 @@ static OutputStream *new_output_stream(OptionsContext
> *o, AVFormatContext *oc, e
>
> MATCH_PER_STREAM_OPT(bitstream_filters, str, bsf, oc, st);
> while (bsf) {
> +char *arg = NULL;
> if (next = strchr(bsf, ','))
> *next++ = 0;
> -if (!(bsfc = av_bitstream_filter_init(bsf))) {
> +if (arg = strchr(bsf, '='))
> +*arg++ = 0;
> +if (!(bsfc = av_bitstream_filter_init(bsf, arg))) {
> av_log(NULL, AV_LOG_FATAL, "Unknown bitstream filter %s\n", bsf);
> exit_program(1);
> }
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3323284..03ce21f 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -5013,6 +5013,7 @@ typedef struct AVBitStreamFilter {
>const uint8_t *buf, int buf_size, int keyframe);
> void (*close)(AVBitStreamFilterContext *bsfc);
> struct AVBitStreamFilter *next;
> +int (*init)(AVBitStreamFilterContext *bsfc, const char *args);
> } AVBitStreamFilter;
>
> /**
> @@ -5033,10 +5034,12 @@ void av_register_bitstream_filter(AVBitStreamFilter
> *bsf);
> * The returned context must be freed with av_bitstream_filter_close().
> *
> * @param namethe name of the bitstream filter
> + * @param argsinitialization arguments for the bitstream filter
> * @return a bitstream filter context if a matching filter was found
> * and successfully initialized, NULL otherwise
> */
> -AVBitStreamFilterContext *av_bitstream_filter_init(const char *name);
> +AVBitStreamFilterContext *av_bitstream_filter_init(const char *name,
> + const char *args);
>
this breaks ABI/API
why is what is done in init not just done in the first packet when
the args are already available ?
This seems simpler and would avoid introducing a API that is possibly
going to be deprecated once a AVOption or AVDictionary based one is
introduced
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mxfdec.c: initial support for EssenceGroups
On Fri, Nov 28, 2014 at 9:26 AM, Tomas Härdin
wrote:
> On Tue, 2014-11-25 at 15:14 -0800, Mark Reid wrote:
> > ---
> > libavformat/mxf.c | 1 +
> > libavformat/mxf.h | 1 +
> > libavformat/mxfdec.c | 148
> -
> > tests/ref/lavf/mxf | 6 +-
> > tests/ref/lavf/mxf_d10 | 2 +-
> > 5 files changed, 127 insertions(+), 31 deletions(-)
> >
> > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> > index 4dc54d7..14d143e 100644
> > --- a/libavformat/mxf.c
> > +++ b/libavformat/mxf.c
> > @@ -94,6 +94,7 @@ static const struct {
> > {AV_PIX_FMT_RGB565BE,{'R', 5, 'G', 6, 'B', 5
>}},
> > {AV_PIX_FMT_RGBA,{'R', 8, 'G', 8, 'B', 8, 'A', 8
>}},
> > {AV_PIX_FMT_PAL8,{'P', 8
>}},
> > +{AV_PIX_FMT_GRAY8, {'A', 8
>}},
>
> There's no pixel format for pure alpha?
>
I was looking for a AV_PIX_FMT_A8 or something like that but could find
one.
http://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#a9a8e335cf3be472042bc9f0cf80cd4c5
AV_PIX_FMT_GRAY8 has the right buffer size, 1 channel 8bpp.
AV_PIX_FMT_YA8 or AV_PIX_FMT_GRAY8A are 4 channels.
> > };
> >
> > static const int num_pixel_layouts =
> FF_ARRAY_ELEMS(ff_mxf_pixel_layouts);
> > diff --git a/libavformat/mxf.h b/libavformat/mxf.h
> > index 5b95efa..63b497a 100644
> > --- a/libavformat/mxf.h
> > +++ b/libavformat/mxf.h
> > @@ -35,6 +35,7 @@ enum MXFMetadataSetType {
> > TimecodeComponent,
> > PulldownComponent,
> > Sequence,
> > +EssenceGroup,
>
> Add this to the end of the enum? That way mxfenc output doesn't change.
>
Okay I'll do that, I just didn't because of the scary comment at the bottom
of the enum
TypeBottom,// add metadata type before this
> > MultipleDescriptor,
> > Descriptor,
> > Track,
> > [...]
> >
> > +static int mxf_read_essence_group(void *arg, AVIOContext *pb, int tag,
> int size, UID uid, int64_t klv_offset)
> > +{
> > +MXFEssenceGroup *essence_group = arg;
> > +switch (tag) {
> > +case 0x0202:
> > +essence_group->duration = avio_rb64(pb);
> > +break;
> > +case 0x0501:
> > +essence_group->structural_components_count = avio_rb32(pb);
> > +essence_group->structural_components_refs =
> av_calloc(essence_group->structural_components_count, sizeof(UID));
> > +if (!essence_group->structural_components_refs)
> > +return AVERROR(ENOMEM);
> > +avio_skip(pb, 4); /* useless size of objects, always 16
> according to specs */
> > +avio_read(pb, (uint8_t
> *)essence_group->structural_components_refs,
> essence_group->structural_components_count * sizeof(UID));
>
> Is there any risk of this multiplication overflowing? I suspect
> av_calloc() will fail if it does, just making sure. Also not critical if
> it actually does since avio_read() just ends up reading less.
>
I copied the same code from the mxf_read_sequence func, so I assumed it was
okay.
http://ffmpeg.org/doxygen/trunk/mem_8c_source.html#l00251
av_calloc does check for a overflow and will return NULL if nmemb >=
INT_MAX / size. So it should fail before even getting to the avio_read.
> > +static MXFStructuralComponent*
> mxf_resolve_essence_group_choice(MXFContext *mxf, MXFEssenceGroup
> *essence_group)
> > +{
> > +MXFStructuralComponent *component = NULL;
> > +MXFPackage *package = NULL;
> > +MXFDescriptor *descriptor = NULL;
> > +int i;
> > +
> > +if (!essence_group || !essence_group->structural_components_count)
> > +return NULL;
> > +
> > +/* essence groups contains multiple representations of the same
> media,
> > + this return the first components with a valid Descriptor
> typically index 0 */
> > +for (i =0; i < essence_group->structural_components_count; i++){
> > +component = mxf_resolve_strong_ref(mxf,
> &essence_group->structural_components_refs[i], SourceClip);
> > +if (!component)
> > +continue;
> > +
> > +if (!(package = mxf_resolve_source_package(mxf,
> component->source_package_uid)))
> > +continue;
> > +
> > +descriptor = mxf_resolve_strong_ref(mxf,
> &package->descriptor_ref, Descriptor);
> > +if (descriptor){
> > +/* HACK: force the duration of the component to match the
> duration of the descriptor */
> > +if (descriptor->duration != AV_NOPTS_VALUE)
> > +component->duration = descriptor->duration;
>
> Not a huge fan of this, but probably doesn't hurt since it's checking
> for AV_NOPTS_VALUE.
>
>
I was planing of removing this in a future patch. I was going to move the
logic into mxf_parse_structural_metadata, but need to refactor and shuffle
somethings around in there to get it to work.
> > +static int mxf_metadataset_init(MXFMetadataSet *ctx, enum
> MXFMetadataSetType type)
> > +{
> > +switch (type){
> > +case MultipleDescriptor:
> > +case Descriptor:
> > +((MXFDescriptor*
Re: [FFmpeg-devel] [PATCH 4/6] h264_changesps_bsf: fix compilation
Christophe Gisquet gmail.com> writes: > libavcodec/h264_changesps_bsf.c | 24 +++- > 1 file changed, 3 insertions(+), 21 deletions(-) Please merge this into the earlier patch, as-is regression tests are unnecessarily hard. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On Sat, 29 Nov 2014 15:52:00 -0800 Philip Langdale wrote: > On Sun, 30 Nov 2014 00:04:37 +0100 > Timo Rothenpieler wrote: > > > Did some refactoring, now using a dynamic ring-buffer for both the > > surface lists as well as the timestamp list. > > > > There should be no thread safety problem anymore, as there are no > > non-constant static global variables anymore. > > > > I think i addressed most of the issues now, new patch is attached. > > I agree with Nicholas that the dynamically allocated buffer list is > overkill. You can just allocate a fixed length 20 entry array and use > circular indexing (16 bframes + 4 extra as claimed by API docs). > > Speaking of bframes, you're not allowing them to be selected as > flexibly as the hardware allows. According to docs, and reading the > nvidia patch, you should read the number of bframes requested by the > user (-bf) and set frameIntervalP equal to that number + 1 (so 17 in > the pathological case). From my limited testing, you really can > request an arbitrary number of bframes up to 16 and it will encode > them. But you're not respecting that config option. Oh, and did you check your non-square pixel aspect ratio handling? You're setting the dar Width/Height to the same as the pixel width/height. The nvidia patch is the same and it produces wrong results for non-square content (like DVDs). You need to scale by the sample aspect ratio, which makes sense, but I also needed to apply a 1.02 scale factor to the height. That's insane but it definitely produces slightly incorrect results without it, and correct results with it. Test for yourself. darWidth = 1024 * avctx->width * avctx->sample_aspect_ratio.num / avctx->sample_aspect_ratio.den; darHeight = 1024 * avctx->height * 1.02; --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/6] h264_changesps_bsf: fix compilation
---
libavcodec/h264_changesps_bsf.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/libavcodec/h264_changesps_bsf.c b/libavcodec/h264_changesps_bsf.c
index 5daea89..a166748 100644
--- a/libavcodec/h264_changesps_bsf.c
+++ b/libavcodec/h264_changesps_bsf.c
@@ -21,26 +21,8 @@
#include "avcodec.h"
#include "golomb.h"
-
-extern AVRational pixel_aspect[];
-
-// NAL unit types, copied from h264.h
-enum {
-NAL_SLICE=1,
-NAL_DPA,
-NAL_DPB,
-NAL_DPC,
-NAL_IDR_SLICE,
-NAL_SEI,
-NAL_SPS,
-NAL_PPS,
-NAL_AUD,
-NAL_END_SEQUENCE,
-NAL_END_STREAM,
-NAL_FILLER_DATA,
-NAL_SPS_EXT,
-NAL_AUXILIARY_SLICE=19
-};
+#include "h264.h"
+#include "h264data.h"
typedef struct H264SPSContext {
uint8_t state;
@@ -114,7 +96,7 @@ static int parse_args(struct H264SPSContext *c, const char
*args)
int i;
c->predefined_sar = 255;
for (i = 1; i < 17; i++)
-if (pixel_aspect[i].den * sarx == pixel_aspect[i].num * sary) {
+if (ff_h264_pixel_aspect[i].den * sarx ==
ff_h264_pixel_aspect[i].num * sary) {
c->predefined_sar = i;
break;
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] h264_changesps_bsf: allow specifying full cropping
The decoder support is unfortunately dismal.
---
libavcodec/h264_changesps_bsf.c | 103 +---
1 file changed, 64 insertions(+), 39 deletions(-)
diff --git a/libavcodec/h264_changesps_bsf.c b/libavcodec/h264_changesps_bsf.c
index 43e0d62..39896fa 100644
--- a/libavcodec/h264_changesps_bsf.c
+++ b/libavcodec/h264_changesps_bsf.c
@@ -1,6 +1,7 @@
/*
* H.264 change sps filter
* Copyright (c) 2010 Zongyi Zhou
+ * Copyright (c) 2014 Christophe Gisquet
*
* This file is part of FFmpeg.
*
@@ -35,15 +36,16 @@ typedef struct H264SPSContext {
int32_t refs;
uint32_t remove_nal_flags, delay_remove_flags;
int16_t sar_x, sar_y;
-int16_t crop_x, crop_y;
+int16_t crop[4];
int8_t fullrange, colorprim, transfer, colmatrix;
} H264SPSContext;
static int parse_args(struct H264SPSContext *c, const char *args)
{
int r = 0;
-int32_t sarx = -1, sary = -1, cropx = -1, cropy = -1, level = -1,
+int32_t sarx = -1, sary = -1, level = -1,
refs = -1, colorprim = -1, transfer = -1, colmatrix = -1;
+int32_t cropl = -1, cropt = -1, cropr = -1, cropb = -1;
if (!args) return 0;
c->fps_den = c->fps_num = c->fps_mode = -1;
c->fullrange = -1;
@@ -51,13 +53,15 @@ static int parse_args(struct H264SPSContext *c, const char
*args)
while (*args) {
if (sscanf(args, "fps=%u:%u", &c->fps_num, &c->fps_den) == 2 ||
sscanf(args, "sar=%u:%u", &sarx, &sary) == 2 ||
-sscanf(args, "crop=%u:%u", &cropx, &cropy) == 2 ||
sscanf(args, "level=%u", &level) == 1 ||
sscanf(args, "ref=%u", &refs) == 1 ||
sscanf(args, "colorprim=%u", &colorprim) == 1 ||
sscanf(args, "transfer=%u", &transfer) == 1 ||
sscanf(args, "colormatrix=%u", &colmatrix) == 1)
r++;
+else if (sscanf(args, "crop=%u:%u:%u:%u",
+&cropl, &cropt, &cropr, &cropb) == 4)
+r++;
else if (!strncmp(args, "vfr", 3)) {
r++;
c->fps_mode = 0;
@@ -84,9 +88,11 @@ static int parse_args(struct H264SPSContext *c, const char
*args)
args++;
}
if (sary == -1) sarx = -1;
-if (cropy == -1) cropx = -1;
+if (cropt == -1) cropl = -1;
+if (cropb == -1) cropr = -1;
c->sar_x = sarx; c->sar_y = sary;
-c->crop_x = cropx; c->crop_y = cropy;
+c->crop[0] = cropl; c->crop[1] = cropr;
+c->crop[2] = cropt; c->crop[3] = cropb;
c->level = level;
c->refs = refs;
c->colorprim = colorprim;
@@ -172,7 +178,9 @@ static int h264_modify(uint8_t *outbuf, const uint8_t
*inbuf, H264SPSContext *ct
#define COPYUE31 set_ue_golomb(&pb, get_ue_golomb_31(&gb))
#define COPYSE set_se_golomb(&pb, get_se_golomb(&gb))
#define COPYBITS1 put_bits(&pb, 1, get_bits1(&gb))
-int p, t, i;
+int p, t, i, frame_mbs_only, mb_width, mb_height;
+int chroma_format_idc = 1; // default value for non-High profile
+int csub[2];
init_get_bits(&gb, inbuf, insize * 8);
init_put_bits(&pb, outbuf, (insize + 10) * 8);
p = get_bits(&gb, 8); //profile_idc
@@ -184,9 +192,9 @@ static int h264_modify(uint8_t *outbuf, const uint8_t
*inbuf, H264SPSContext *ct
put_bits(&pb, 8, t);
COPYUE31;
if (p >= 100) {
-t = get_ue_golomb(&gb); //chroma_format_idc
-set_ue_golomb(&pb, t);
-if (t == 3)
+chroma_format_idc = get_ue_golomb(&gb);
+set_ue_golomb(&pb, chroma_format_idc);
+if (chroma_format_idc == 3)
COPYBITS1; //residue_transform_flag
COPYUE; //bit_depth_luma_minus8
COPYUE; //bit_depth_chroma_minus8
@@ -221,38 +229,49 @@ static int h264_modify(uint8_t *outbuf, const uint8_t
*inbuf, H264SPSContext *ct
t = ctx->refs;
set_ue_golomb(&pb,t);
COPYBITS1;
-COPYUE;
-COPYUE;
-i = get_bits1(&gb); //frame_mbs_only
-put_bits(&pb, 1, i);
-if (!i) COPYBITS1;
+mb_width = get_ue_golomb(&gb);
+mb_height = get_ue_golomb(&gb);
+set_ue_golomb(&pb,mb_width);
+set_ue_golomb(&pb,mb_height);
+frame_mbs_only = get_bits1(&gb);
+put_bits(&pb, 1, frame_mbs_only);
+if (!frame_mbs_only) COPYBITS1;
COPYBITS1;
+csub[0] = (chroma_format_idc == 1 || chroma_format_idc == 2) ? 1 : 0;
+csub[1] = (chroma_format_idc == 1) ? 1 : 0;
+csub[1] += 1-frame_mbs_only;
t = get_bits1(&gb);
-if (ctx->crop_x == -1)
-put_bits(&pb, 1, t);
if (t) {
-int t1, t2, t3, t4;
-t1 = get_ue_golomb(&gb),
-t2 = get_ue_golomb(&gb),
-t3 = get_ue_golomb(&gb),
-t4 = get_ue_golomb(&gb);
-if (ctx->crop_x == -1) {
-set_ue_golomb(&pb, t1);
-set_ue_golomb(&pb, t2);
-set_ue_golomb(&pb, t3);
-set_ue_golomb(&pb, t4);
+for (i=0; i<4; i++) {
+int val = get_ue_golomb(&gb);
+if (ctx->crop[i] < 0)
+ctx->crop[i] = val <<
[FFmpeg-devel] [PATCH 5/6] h264_changesps_bsf: add and use init
---
libavcodec/h264_changesps_bsf.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/h264_changesps_bsf.c b/libavcodec/h264_changesps_bsf.c
index a166748..43e0d62 100644
--- a/libavcodec/h264_changesps_bsf.c
+++ b/libavcodec/h264_changesps_bsf.c
@@ -398,6 +398,17 @@ static int find_next_nal_annexb(const uint8_t *src, int
*p, int size)
return 0;
}
+static int h264_changesps_init(AVBitStreamFilterContext *bsfc, const char
*args)
+{
+H264SPSContext *ctx = bsfc->priv_data;
+if (parse_args(ctx, args)) {
+ctx->state = 1;
+return 1;
+}
+ctx->state = 16;
+return 0;
+}
+
static int h264_changesps_filter(AVBitStreamFilterContext *bsfc,
AVCodecContext *avctx, const char *args,
uint8_t **poutbuf, int *poutbuf_size,
@@ -601,4 +612,5 @@ AVBitStreamFilter ff_h264_changesps_bsf = {
"h264_changesps",
sizeof(H264SPSContext),
h264_changesps_filter,
+.init = h264_changesps_init,
};
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] h264_changesps_bsf: import code
From: Zongyi Zhou
Mostly unverified, but seems to have been extensively tested here:
http://forum.doom9.org/showthread.php?t=152419
Signed-off-by: Christophe Gisquet
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/h264_changesps_bsf.c | 622
3 files changed, 624 insertions(+)
create mode 100644 libavcodec/h264_changesps_bsf.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fa0f53d..8eecf51 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -820,6 +820,7 @@ OBJS-$(CONFIG_AAC_ADTSTOASC_BSF) +=
aac_adtstoasc_bsf.o aacadtsdec.o \
mpeg4audio.o
OBJS-$(CONFIG_CHOMP_BSF) += chomp_bsf.o
OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
+OBJS-$(CONFIG_H264_CHANGESPS_BSF) += h264_changesps_bsf.o
OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF) += h264_mp4toannexb_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= imx_dump_header_bsf.o
OBJS-$(CONFIG_MJPEG2JPEG_BSF) += mjpeg2jpeg_bsf.o mjpeg.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0d39d33..0380824 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -581,6 +581,7 @@ void avcodec_register_all(void)
REGISTER_BSF(AAC_ADTSTOASC, aac_adtstoasc);
REGISTER_BSF(CHOMP, chomp);
REGISTER_BSF(DUMP_EXTRADATA,dump_extradata);
+REGISTER_BSF(H264_CHANGESPS,h264_changesps);
REGISTER_BSF(H264_MP4TOANNEXB, h264_mp4toannexb);
REGISTER_BSF(IMX_DUMP_HEADER, imx_dump_header);
REGISTER_BSF(MJPEG2JPEG,mjpeg2jpeg);
diff --git a/libavcodec/h264_changesps_bsf.c b/libavcodec/h264_changesps_bsf.c
new file mode 100644
index 000..5daea89
--- /dev/null
+++ b/libavcodec/h264_changesps_bsf.c
@@ -0,0 +1,622 @@
+/*
+ * H.264 change sps filter
+ * Copyright (c) 2010 Zongyi Zhou
+ *
+ * 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 "avcodec.h"
+#include "golomb.h"
+
+extern AVRational pixel_aspect[];
+
+// NAL unit types, copied from h264.h
+enum {
+NAL_SLICE=1,
+NAL_DPA,
+NAL_DPB,
+NAL_DPC,
+NAL_IDR_SLICE,
+NAL_SEI,
+NAL_SPS,
+NAL_PPS,
+NAL_AUD,
+NAL_END_SEQUENCE,
+NAL_END_STREAM,
+NAL_FILLER_DATA,
+NAL_SPS_EXT,
+NAL_AUXILIARY_SLICE=19
+};
+
+typedef struct H264SPSContext {
+uint8_t state;
+uint8_t bs_type; // 1=annexb 2=mp4
+int8_t fps_mode;
+int8_t remove_hrd;
+int32_t fps_den, fps_num;
+int32_t predefined_sar;
+int32_t level;
+int32_t refs;
+uint32_t remove_nal_flags, delay_remove_flags;
+int16_t sar_x, sar_y;
+int16_t crop_x, crop_y;
+int8_t fullrange, colorprim, transfer, colmatrix;
+} H264SPSContext;
+
+static int parse_args(struct H264SPSContext *c, const char *args)
+{
+int r = 0;
+int32_t sarx = -1, sary = -1, cropx = -1, cropy = -1, level = -1,
+refs = -1, colorprim = -1, transfer = -1, colmatrix = -1;
+if (!args) return 0;
+c->fps_den = c->fps_num = c->fps_mode = -1;
+c->fullrange = -1;
+c->remove_nal_flags = c->delay_remove_flags = 0;
+while (*args) {
+if (sscanf(args, "fps=%u:%u", &c->fps_num, &c->fps_den) == 2 ||
+sscanf(args, "sar=%u:%u", &sarx, &sary) == 2 ||
+sscanf(args, "crop=%u:%u", &cropx, &cropy) == 2 ||
+sscanf(args, "level=%u", &level) == 1 ||
+sscanf(args, "ref=%u", &refs) == 1 ||
+sscanf(args, "colorprim=%u", &colorprim) == 1 ||
+sscanf(args, "transfer=%u", &transfer) == 1 ||
+sscanf(args, "colormatrix=%u", &colmatrix) == 1)
+r++;
+else if (!strncmp(args, "vfr", 3)) {
+r++;
+c->fps_mode = 0;
+} else if (!strncmp(args, "cfr", 3)) {
+r++;
+c->fps_mode = 1;
+} else if (!strncmp(args, "fullrange", 9)) {
+r++;
+c->fullrange = 1;
+} else if (!strncmp(args, "removesei", 9)) {
+r++;
+c->remove_nal_flags |= 1 << NAL_SEI;
+} else if (!strncmp(args, "removeaud", 9)) {
+r++;
+c->remove_nal_flags |=
[FFmpeg-devel] [PATCH 2/6] h264_ps: move and export aspect_ratio
Needed for filters that may need it, like an SPS bsf.
---
libavcodec/h264_ps.c | 26 +++---
libavcodec/h264data.h | 19 +++
2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 2013670..4070490 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -31,32 +31,12 @@
#include "internal.h"
#include "avcodec.h"
#include "h264.h"
-#include "h264data.h" //FIXME FIXME FIXME (just for zigzag_scan)
+#include "h264data.h"
#include "golomb.h"
#define MAX_LOG2_MAX_FRAME_NUM(12 + 4)
#define MIN_LOG2_MAX_FRAME_NUM4
-static const AVRational pixel_aspect[17] = {
-{ 0, 1 },
-{ 1, 1 },
-{ 12, 11 },
-{ 10, 11 },
-{ 16, 11 },
-{ 40, 33 },
-{ 24, 11 },
-{ 20, 11 },
-{ 32, 11 },
-{ 80, 33 },
-{ 18, 11 },
-{ 15, 11 },
-{ 64, 33 },
-{ 160, 99 },
-{ 4, 3 },
-{ 3, 2 },
-{ 2, 1 },
-};
-
#define QP(qP, depth) ((qP) + 6 * ((depth) - 8))
#define CHROMA_QP_TABLE_END(d) \
@@ -164,8 +144,8 @@ static inline int decode_vui_parameters(H264Context *h, SPS
*sps)
if (aspect_ratio_idc == EXTENDED_SAR) {
sps->sar.num = get_bits(&h->gb, 16);
sps->sar.den = get_bits(&h->gb, 16);
-} else if (aspect_ratio_idc < FF_ARRAY_ELEMS(pixel_aspect)) {
-sps->sar = pixel_aspect[aspect_ratio_idc];
+} else if (aspect_ratio_idc < FF_ARRAY_ELEMS(ff_h264_pixel_aspect)) {
+sps->sar = ff_h264_pixel_aspect[aspect_ratio_idc];
} else {
av_log(h->avctx, AV_LOG_ERROR, "illegal aspect ratio\n");
return AVERROR_INVALIDDATA;
diff --git a/libavcodec/h264data.h b/libavcodec/h264data.h
index 38f3258..95ea385 100644
--- a/libavcodec/h264data.h
+++ b/libavcodec/h264data.h
@@ -167,4 +167,23 @@ static const PMbInfo b_sub_mb_type_info[13] = {
{ MB_TYPE_8x8 | MB_TYPE_P0L0 | MB_TYPE_P0L1 | MB_TYPE_P1L0 |
MB_TYPE_P1L1, 4, },
};
+static const AVRational ff_h264_pixel_aspect[17] = {
+{ 0, 1 },
+{ 1, 1 },
+{ 12, 11 },
+{ 10, 11 },
+{ 16, 11 },
+{ 40, 33 },
+{ 24, 11 },
+{ 20, 11 },
+{ 32, 11 },
+{ 80, 33 },
+{ 18, 11 },
+{ 15, 11 },
+{ 64, 33 },
+{ 160, 99 },
+{ 4, 3 },
+{ 3, 2 },
+{ 2, 1 },
+};
#endif /* AVCODEC_H264DATA_H */
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] bitstream_filter: add an init function
From: Zongyi Zhou
Original patch was adding an arg field in the context structure. As it
is most often only useful once, allow passing the arguments on init.
The proper solution would be using AVOption, but this is overkill for now.
Signed-off-by: Christophe Gisquet
---
ffmpeg_opt.c | 5 -
libavcodec/avcodec.h | 5 -
libavcodec/bitstream_filter.c | 8 +++-
libavformat/concatdec.c | 2 +-
libavformat/tee.c | 7 ++-
5 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 03e049b..b8cd35d 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1138,9 +1138,12 @@ static OutputStream *new_output_stream(OptionsContext
*o, AVFormatContext *oc, e
MATCH_PER_STREAM_OPT(bitstream_filters, str, bsf, oc, st);
while (bsf) {
+char *arg = NULL;
if (next = strchr(bsf, ','))
*next++ = 0;
-if (!(bsfc = av_bitstream_filter_init(bsf))) {
+if (arg = strchr(bsf, '='))
+*arg++ = 0;
+if (!(bsfc = av_bitstream_filter_init(bsf, arg))) {
av_log(NULL, AV_LOG_FATAL, "Unknown bitstream filter %s\n", bsf);
exit_program(1);
}
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3323284..03ce21f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5013,6 +5013,7 @@ typedef struct AVBitStreamFilter {
const uint8_t *buf, int buf_size, int keyframe);
void (*close)(AVBitStreamFilterContext *bsfc);
struct AVBitStreamFilter *next;
+int (*init)(AVBitStreamFilterContext *bsfc, const char *args);
} AVBitStreamFilter;
/**
@@ -5033,10 +5034,12 @@ void av_register_bitstream_filter(AVBitStreamFilter
*bsf);
* The returned context must be freed with av_bitstream_filter_close().
*
* @param namethe name of the bitstream filter
+ * @param argsinitialization arguments for the bitstream filter
* @return a bitstream filter context if a matching filter was found
* and successfully initialized, NULL otherwise
*/
-AVBitStreamFilterContext *av_bitstream_filter_init(const char *name);
+AVBitStreamFilterContext *av_bitstream_filter_init(const char *name,
+ const char *args);
/**
* Filter bitstream.
diff --git a/libavcodec/bitstream_filter.c b/libavcodec/bitstream_filter.c
index 3275326..53ec379 100644
--- a/libavcodec/bitstream_filter.c
+++ b/libavcodec/bitstream_filter.c
@@ -41,7 +41,8 @@ void av_register_bitstream_filter(AVBitStreamFilter *bsf)
} while(bsf->next != avpriv_atomic_ptr_cas((void * volatile
*)&first_bitstream_filter, bsf->next, bsf));
}
-AVBitStreamFilterContext *av_bitstream_filter_init(const char *name)
+AVBitStreamFilterContext *av_bitstream_filter_init(const char *name,
+ const char *args)
{
AVBitStreamFilter *bsf = NULL;
@@ -52,6 +53,11 @@ AVBitStreamFilterContext *av_bitstream_filter_init(const
char *name)
bsfc->filter= bsf;
bsfc->priv_data =
bsf->priv_data_size ? av_mallocz(bsf->priv_data_size) : NULL;
+if (bsfc->filter->init &&
+!bsfc->filter->init(bsfc, args)) {
+av_bitstream_filter_close(bsfc);
+return NULL;
+}
return bsfc;
}
}
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index a2584d7..9d46ffe 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -186,7 +186,7 @@ static int detect_stream_specific(AVFormatContext *avf, int
idx)
(st->codec->extradata_size < 4 || AV_RB32(st->codec->extradata) != 1))
{
av_log(cat->avf, AV_LOG_INFO,
"Auto-inserting h264_mp4toannexb bitstream filter\n");
-if (!(bsf = av_bitstream_filter_init("h264_mp4toannexb"))) {
+if (!(bsf = av_bitstream_filter_init("h264_mp4toannexb", NULL))) {
av_log(avf, AV_LOG_ERROR, "h264_mp4toannexb bitstream filter "
"required for H.264 streams\n");
return AVERROR_BSF_NOT_FOUND;
diff --git a/libavformat/tee.c b/libavformat/tee.c
index 681f943..88615ed 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -109,7 +109,12 @@ static int parse_bsfs(void *log_ctx, const char *bsfs_spec,
return AVERROR(ENOMEM);
while (bsf_name = av_strtok(buf, ",", &saveptr)) {
-AVBitStreamFilterContext *bsf = av_bitstream_filter_init(bsf_name);
+char *arg = strchr(buf, '=');
+AVBitStreamFilterContext *bsf;
+
+if (arg)
+*arg++ = 0;
+bsf = av_bitstream_filter_init(bsf_name, arg);
if (!bsf) {
av_log(log_ctx, AV_LOG_ERROR,
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/6] Toward a SPS filter for H.264
Most of the code is actually not mine but originated from "Direct264": http://forum.doom9.org/showthread.php?t=152419 https://svn.code.sf.net/p/direct264/code/Patches/ Therefore I've tried to split as best as possible the code I have added. There are 3 controversial parts in this patch set: - the BSF API change (fixing it is out of my league/time budget) - the filter doing in-place filtering (?) - the level of validation for this new filter I've only tested the cropping feature, and validating that the rest works tenuous. Anyway, cropping is unfortunately not at all well supported: - VLC 2.1.5 (Windows) either crashes or outputs garbage - DXVA on some Intel core gets top/left cropping completely wrong (0,0 but something valid for bottom/right seems to be OK) - ffmpeg-based decoders (e.g. mplayer) are OK It is possible the implementation is incorrect but it was written following the specs. Christophe Gisquet (4): h264_ps: move and export aspect_ratio h264_changesps_bsf: fix compilation h264_changesps_bsf: add and use init h264_changesps_bsf: allow specifying full cropping Zongyi Zhou (2): bitstream_filter: add an init function h264_changesps_bsf: import code ffmpeg_opt.c| 5 +- libavcodec/Makefile | 1 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h| 5 +- libavcodec/bitstream_filter.c | 8 +- libavcodec/h264_changesps_bsf.c | 641 libavcodec/h264_ps.c| 26 +- libavcodec/h264data.h | 19 ++ libavformat/concatdec.c | 2 +- libavformat/tee.c | 7 +- 10 files changed, 687 insertions(+), 28 deletions(-) create mode 100644 libavcodec/h264_changesps_bsf.c -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On Sun, 30 Nov 2014 00:04:37 +0100 Timo Rothenpieler wrote: > Did some refactoring, now using a dynamic ring-buffer for both the > surface lists as well as the timestamp list. > > There should be no thread safety problem anymore, as there are no > non-constant static global variables anymore. > > I think i addressed most of the issues now, new patch is attached. I agree with Nicholas that the dynamically allocated buffer list is overkill. You can just allocate a fixed length 20 entry array and use circular indexing (16 bframes + 4 extra as claimed by API docs). Speaking of bframes, you're not allowing them to be selected as flexibly as the hardware allows. According to docs, and reading the nvidia patch, you should read the number of bframes requested by the user (-bf) and set frameIntervalP equal to that number + 1 (so 17 in the pathological case). From my limited testing, you really can request an arbitrary number of bframes up to 16 and it will encode them. But you're not respecting that config option. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
Did some refactoring, now using a dynamic ring-buffer for both the
surface lists as well as the timestamp list.
There should be no thread safety problem anymore, as there are no
non-constant static global variables anymore.
I think i addressed most of the issues now, new patch is attached.
commit f7840ac3e9ae279e6665986a122e95b8bf9a7f6a
Author: Timo Rothenpieler
Date: Wed Nov 26 11:08:11 2014 +0100
Add NVENC encoder
diff --git a/Changelog b/Changelog
index 7172d0c..d26b7fa 100644
--- a/Changelog
+++ b/Changelog
@@ -17,6 +17,7 @@ version :
- WebP muxer with animated WebP support
- zygoaudio decoding support
- APNG demuxer
+- nvenc encoder
version 2.4:
diff --git a/MAINTAINERS b/MAINTAINERS
index 15b976f..f2ff47d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -226,6 +226,7 @@ Codecs:
msvideo1.cMike Melanson
nellymoserdec.c Benjamin Larsson
nuv.c Reimar Doeffinger
+ nvenc.c Timo Rothenpieler
paf.* Paul B Mahol
pcx.c Ivo van Poorten
pgssubdec.c Reimar Doeffinger
diff --git a/configure b/configure
index d4a86c0..1cafe4b 100755
--- a/configure
+++ b/configure
@@ -261,6 +261,7 @@ External library support:
--enable-libzvbi enable teletext support via libzvbi [no]
--disable-lzma disable lzma [autodetect]
--enable-decklinkenable Blackmagick DeckLink I/O support [no]
+ --enable-nvenc enable NVIDIA NVENC support [no]
--enable-openal enable OpenAL 1.1 capture support [no]
--enable-opencl enable OpenCL code
--enable-opengl enable OpenGL rendering [no]
@@ -1393,6 +1394,7 @@ EXTERNAL_LIBRARY_LIST="
libzmq
libzvbi
lzma
+nvenc
openal
opencl
opengl
@@ -2390,6 +2392,7 @@ libxvid_encoder_deps="libxvid"
libutvideo_decoder_deps="libutvideo"
libutvideo_encoder_deps="libutvideo"
libzvbi_teletext_decoder_deps="libzvbi"
+nvenc_encoder_deps="nvenc"
# demuxers / muxers
ac3_demuxer_select="ac3_parser"
@@ -4342,6 +4345,7 @@ die_license_disabled gpl x11grab
die_license_disabled nonfree libaacplus
die_license_disabled nonfree libfaac
+die_license_disabled nonfree nvenc
enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
enabled gpl && die_license_disabled_gpl nonfree openssl
@@ -4651,6 +4655,7 @@ fi
frei0r_filter_extralibs='$ldl'
frei0r_src_filter_extralibs='$ldl'
ladspa_filter_extralibs='$ldl'
+nvenc_encoder_extralibs='$ldl'
if ! disabled network; then
check_func getaddrinfo $network_extralibs
@@ -4916,6 +4921,7 @@ enabled libxavs && require libxavs xavs.h
xavs_encoder_encode -lxavs
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzmq&& require_pkg_config libzmq zmq.h zmq_ctx_new
enabled libzvbi && require libzvbi libzvbi.h vbi_decoder_new -lzvbi
+enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR:
nvEncodeAPI.h not found."; }
enabled openal&& { { for al_libs in "${OPENAL_LIBS}" "-lopenal"
"-lOpenAL32"; do
check_lib 'AL/al.h' alGetError "${al_libs}" &&
break; done } ||
die "ERROR: openal not found"; } &&
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fa0f53d..cc393f9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -347,6 +347,7 @@ OBJS-$(CONFIG_MXPEG_DECODER) += mxpegdec.o
OBJS-$(CONFIG_NELLYMOSER_DECODER) += nellymoserdec.o nellymoser.o
OBJS-$(CONFIG_NELLYMOSER_ENCODER) += nellymoserenc.o nellymoser.o
OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
+OBJS-$(CONFIG_NVENC_ENCODER) += nvenc.o
OBJS-$(CONFIG_ON2AVC_DECODER) += on2avc.o on2avcdata.o
OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o \
opus_imdct.o opus_silk.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 0d39d33..8ceee2f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -223,6 +223,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(MVC2, mvc2);
REGISTER_DECODER(MXPEG, mxpeg);
REGISTER_DECODER(NUV, nuv);
+REGISTER_ENCODER(NVENC, nvenc);
REGISTER_DECODER(PAF_VIDEO, paf_video);
REGISTER_ENCDEC (PAM, pam);
REGISTER_ENCDEC (PBM, pbm);
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
new file mode 100644
index 000..dc14594
--- /dev/null
+++ b/libavcodec/nvenc.c
@@ -0,0 +1,1189 @@
+/*
+ * H.264 hardware encoding using nvidia nvenc
+ * Copyright (c) 2014 Timo Rothenpieler
+ *
+ * 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
Re: [FFmpeg-devel] [PATCH] avfilter/vf_yadif: fix extra leading dup frame when deint=1
On Sat, Nov 29, 2014 at 12:23:58PM -0800, Neil Birkbeck wrote: > Logic for handling single frame in yadif (0f9f24c9), caused deint=1 (e.g., > yadif=0:-1:1) to output extra duplicate leading frame: > > ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf > yadif=0:-1:1,showinfo -f null -y /dev/null > [Parsed_showinfo_1 @ 0x1d967d0] n:0 pts:0 pts_time:0 pos:-1 fmt:gray sar:0/1 > s:352x432 i:P iskey:1 type:I checksum:E457EEA0 plane_checksum:[E457EEA0] > mean:[126] stdev:[46.6] > [Parsed_showinfo_1 @ 0x1d967d0] n:1 pts:0 pts_time:0 pos:-1 fmt:gray sar:0/1 > s:352x432 i:P iskey:1 type:I checksum:E457EEA0 plane_checksum:[E457EEA0] > mean:[126] stdev:[46.6] > (Outputs 51 frames) > > After patch, vf "yadif=0:-1:1" behaves correctly (like "yadif=0:-1:0") and > outputs 50 frames, first two: > > [Parsed_showinfo_1 @ 0x1e307d0] n:0 pts:0 pts_time:0 pos:-1 fmt:gray sar:0/1 > s:352x432 i:P iskey:1 type:I checksum:68E8D1EB plane_checksum:[68E8D1EB] > mean:[126] stdev:[46.0] > [Parsed_showinfo_1 @ 0x1e307d0] n:1 pts:2 pts_time:0.04 pos:-1 fmt:gray > sar:0/1 s:352x432 i:P iskey:1 type:I checksum:4E674BC7 > plane_checksum:[4E674BC7] mean:[125] stdev:[46.0] > (Outputs 50 frames) > > Signed-off-by: Neil Birkbeck > --- > libavfilter/vf_yadif.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2][RFC] xbr, hqx: minor simplification
On Sat, Nov 29, 2014 at 03:26:08AM +0100, Alexander Strasser wrote: > Hi, > > while reading the recent evolution of xbr I came up with the > idea for below 2 patches. > > Maybe I am missing something, but AFAICT both filters use > a single shared filter function for n in [2, 4] using n as a param > but n is stored in the filter context too. The corresponding fate > tests and visual inspection show no differences. > > It sure is a matter of taste, so I guess it is your call Clément. > > Alexander Strasser (2): > lavfi/vf_xbr: Remove function generator macro and function pointer > indirection > lavfi/vf_hqx: Remove function generator macro and function pointer > indirection > > libavfilter/vf_hqx.c | 35 +++ > libavfilter/vf_xbr.c | 33 ++--- NACK This probably kills the performances badly. The purpose of this indirection is to create N functions optimized for a specific size. Best regards, -- Clément B. pgpbIRSAiC63l.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_yadif: fix extra leading dup frame when deint=1
Logic for handling single frame in yadif (0f9f24c9), caused deint=1 (e.g.,
yadif=0:-1:1) to output extra duplicate leading frame:
ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf
yadif=0:-1:1,showinfo -f null -y /dev/null
[Parsed_showinfo_1 @ 0x1d967d0] n:0 pts:0 pts_time:0 pos:-1 fmt:gray sar:0/1
s:352x432 i:P iskey:1 type:I checksum:E457EEA0 plane_checksum:[E457EEA0]
mean:[126] stdev:[46.6]
[Parsed_showinfo_1 @ 0x1d967d0] n:1 pts:0 pts_time:0 pos:-1 fmt:gray sar:0/1
s:352x432 i:P iskey:1 type:I checksum:E457EEA0 plane_checksum:[E457EEA0]
mean:[126] stdev:[46.6]
(Outputs 51 frames)
After patch, vf "yadif=0:-1:1" behaves correctly (like "yadif=0:-1:0") and
outputs 50 frames, first two:
[Parsed_showinfo_1 @ 0x1e307d0] n:0 pts:0 pts_time:0 pos:-1 fmt:gray sar:0/1
s:352x432 i:P iskey:1 type:I checksum:68E8D1EB plane_checksum:[68E8D1EB]
mean:[126] stdev:[46.0]
[Parsed_showinfo_1 @ 0x1e307d0] n:1 pts:2 pts_time:0.04 pos:-1 fmt:gray sar:0/1
s:352x432 i:P iskey:1 type:I checksum:4E674BC7 plane_checksum:[4E674BC7]
mean:[125] stdev:[46.0]
(Outputs 50 frames)
Signed-off-by: Neil Birkbeck
---
libavfilter/vf_yadif.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index 70670c3..da6ee70 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -342,6 +342,9 @@ static int filter_frame(AVFilterLink *link, AVFrame *frame)
return -1;
}
+if (!yadif->prev)
+return 0;
+
if ((yadif->deint && !yadif->cur->interlaced_frame) || ctx->is_disabled) {
yadif->out = av_frame_clone(yadif->cur);
if (!yadif->out)
@@ -353,9 +356,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *frame)
return ff_filter_frame(ctx->outputs[0], yadif->out);
}
-if (!yadif->prev)
-return 0;
-
yadif->out = ff_get_video_buffer(ctx->outputs[0], link->w, link->h);
if (!yadif->out)
return AVERROR(ENOMEM);
--
2.2.0.rc0.207.ga3a616c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On Sat, 29 Nov 2014 19:00:02 +0100 Timo Rothenpieler wrote: > > does supporting these additional features need the extra complexity > > that the nvidia version has ? > > or could these features be added into your version while keeping its > > simplicity ? (note do not copy any code from the nvidia one as its > > not redistriutable nor *GPL compatible with the current license > > headers) > > I haven't even looked at their code for quite exactly that reason. > The primary problem with NVENC is, that there is only very poor > documentation available, so I can only implement stuff based on > reading the header and experimenting with the API and the available > examples. NVIDIA employees clearly are in a better position for this, > as they most likely have a much larger insight into how NVENC works > internaly. I'm quite sure all of their features could be added to my > version. I'm already 'polluted' until they correct their licensing, but I can at least describe what they have. The main piece of complexity in their implementation is they have an additional abstraction layer between the ffmpeg encoder implementation and the nvenc API. So this layer 'insulates' the two APIs. From a licensing point of view it's meaningless, but I think that's the reason why it exists, based on a brief email exchange with them. If that was squashed, it would make theirs more straight forward. There's also a bunch of utility code that handles argument mapping between x264 args and nvenc args. As I've written elsewhere - I think this is a very useful thing to do, as people are, broadly, familiar with how to tell x264 to do stuff. And as I mentioned before, they have a directx linked initialisation path as an alternative to the cuda one. I'm not sure what conditions that would be more useful under, but it's documented in the SDK. Hopefully, they will respond positively on Monday and will get engaged here, and sort out their licensing so that we can all work on a single implementation. Thanks! --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
> does supporting these additional features need the extra complexity > that the nvidia version has ? > or could these features be added into your version while keeping its > simplicity ? (note do not copy any code from the nvidia one as its > not redistriutable nor *GPL compatible with the current license > headers) I haven't even looked at their code for quite exactly that reason. The primary problem with NVENC is, that there is only very poor documentation available, so I can only implement stuff based on reading the header and experimenting with the API and the available examples. NVIDIA employees clearly are in a better position for this, as they most likely have a much larger insight into how NVENC works internaly. I'm quite sure all of their features could be added to my version. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
> BTW, can you verify that interlaced encoding works for > you? I get initialization errors back from the hardware. > Doesn't work for me either. It looks like it's not (yet?) supported and just available in the API. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On 29 Nov 2014 03:13, Timo Rothenpieler wrote: > > > I've spent a lot more time looking at the nvidia patch, but from a > > quick look through Timo's version, I'd say the following: > > > > * Timo's is more concise but not as feature complete. > > * nvidia one has windows support > > * The nvidia patch doesn't handle b-frames correctly, but I wrote a > > fix patch for them. I'm not sure whether Timo's works correctly > > * Timo's looks like it will handle interlaced input correctly. Nvidia > > definitely does not. > > * nvidia one implements argument compatibility with x264 - so it uses > > the same args as much as possible - it even does preset/tune mapping. > > I think this is pretty nice. > > > > The main issue with the nvidia patch, as it exists today, is that they > > have not put any licence header on the files at all - but I've told > > them they need to do that, and asked Stephen Warren if he can help them > > out. The other slight complexity is that it requires cuda.h (Timo seems > > to have avoided that by independently defining the necessary constants > > but you need even more of cuda.h for the windows support). But > > nvEncoderAPI.h is already so awkward (restrictive license, not properly > > distributed) that an extra header isn't any more inconvenient. > > My implementation also works fine on Windows. (Tested is with MSVC, > MinGW and Cygwin) > The required functions from CUDA are minimal, and i just dynamicaly load > them, avoiding any (linked) external dependencies except the nvEncodeAPI.h > > The main difference is that they support way more features, but they > seem to need an intermediate library, while mine is now just a single > new C file, which needs one header from the nvenc SDK. Fair enough. They have a set of nvenc aware files that expose an api to the ffmpeg aware encoder. I think they did this for licensing reasons but it's pointless and I'd recommend they drop the split. It's pointless because all those files are inside the ffmpeg patch anyway. Once they get back to work, hopefully they can get involved here and you can all work together. BTW, can you verify that interlaced encoding works for you? I get initialization errors back from the hardware. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On 29 Nov 2014 03:45, Nicolas George wrote:
>
> Le septidi 7 frimaire, an CCXXIII, Timo Rothenpieler a écrit :
> > Done that primarily to keep things cleaned up and easier to read.
> > Can as well put it all in one huge file.
>
> IMHO, your choice in the end.
>
> > Propably, will split that out when i get to it.
>
> Thanks.
>
> > Most of this code is ported from a C++ Project where everything had
> > to be camel case, so those and the C++ malloc casts are some of the
> > leftovers.
>
> Idem, IMHO your choice.
>
> > The maximum is the number of adjacent B Frames plus one. So 3 in the
> > case of NVENC, unless they change the supported gop patterns.
>
> In that case, I suspect to take some margin and use a hardcoded size for the
> queue: with 8 or 16, there is plenty of time to update the size if nvidia
> releases new GOP patterns.
>
> > I basically need a fifo like structure, where i can queue output
> > surfaces until NVENC is done filling them.
> > An array doesn't realy reflect that usage, as new elements are added
> > to the front, and taken from the back.
>
> An array used as a circular buffer is perfect for that.
For what it's worth, the implementation I did against the
nvidia patch was a circular buffer and it works fine. The
docs I read say 4 + num b frames and max b frames can
go up to 16 - not 2.
> > Is a simple assert on the return value enough? Can't continue in a
> > sane way anyway if it ever fails.
>
> No: an assert can only be used when the error is not possible except for a
> bug in the code. A malloc failure is always possible, so a proper error
> handling, eventually returning ENOMEM, is necessary. That is annoying but
> mostly unavoidable.
>
> > I renamed it to enqueue/dequeue.
>
> Thanks.
>
> > This definitely can't be replaced, its purpose isn't just a plain
> > list, but sorting of the input timestamps, so the dts is still
> > monotonic after re-ordering for B frames.
>
> As far as I can see, you do not need the sorting random access to the sorted
> timestamps but only to be able to extract the lowest one. This is precisely
> what a heap is very good at. I assure you, in this case a heap will be
> almost as simple to implement (certainly simpler if you make it fixed-size)
> and way more efficient.
Yeah, you don't need to sort. Circular fifo works fine.
> > Only adding the CUDA error code, which then has to be looked up manualy.
>
> Too bad ;(
>
> > What do you mean by that? Printing which presets are available in
> > the error message?
>
> Yes. Something like that is always nice:
>
> # x264 [error]: invalid preset 'list'
> # [libx264 @ 0x172a560] Error setting preset/tune list/(null).
> # [libx264 @ 0x172a560] Possible presets: ultrafast superfast veryfast faster
> # fast medium slow slower veryslow placebo
> # [libx264 @ 0x172a560] Possible tunes: film animation grain stillimage psnr
> # ssim fastdecode zerolatency
>
> > Not entirely sure why i did that this way. Copied it straight from
> > the libx264 encoder, without thinking too much about it. I can just
> > set the profileGUID straight from that switch and can remove the
> > second profile variable(which the libx264 encoder has in exactly the
> > same conflicting way) entirely.
>
> It is entirely possible that libx264 has reasons that I do not know to do
> things that way. It is also possible that the options are there just for
> historic reasons.
>
> > >>+ default:
> > >>+ avctx->coded_frame->pict_type = AV_PICTURE_TYPE_NONE;
> > Not that I'm aware of. But i don't know what else to assume in this case.
>
> Then I believe some kind of feedback would be needed. If it is really never
> supposed to happen, an assert is acceptable; otherwise, an error requesting
> a sample may be better.
>
> > The maximum supported number of surfaces is allocated, if it'd ever
> > run out, there'd be a bug in the code managing the surfaces.
>
> Then an assert is exactly what is needed.
>
> > ff_cuCtxCreate is a library function loaded from the CUDA dll/so.
> > Same for all the other ff_cu* functions, there is no way to change
> > what it returns, as it's not my function.
>
> I missed that, sorry.
>
> > >>+#define ifav_log(...) if (avctx) { av_log(__VA_ARGS__); }
> > >Looks strange: why no error message when there is no context?
> > Is it possible to call av_log without a context?
>
> Yes, it just prints the message without the [libfoo @ 0x42] prefix.
>
> > No, does it need to be? Can multiple threads create the coded at the
> > same time?
>
> It looks like it is called from encode_init, which can definitely be called
> by multiple threads.
>
> Thanks for your efforts. Hope this helps.
>
> Regards,
>
> --
> Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On Sat, Nov 29, 2014 at 12:13:18PM +0100, Timo Rothenpieler wrote: > > I've spent a lot more time looking at the nvidia patch, but from a > > quick look through Timo's version, I'd say the following: > > > > * Timo's is more concise but not as feature complete. > > * nvidia one has windows support > > * The nvidia patch doesn't handle b-frames correctly, but I wrote a > > fix patch for them. I'm not sure whether Timo's works correctly > > * Timo's looks like it will handle interlaced input correctly. Nvidia > > definitely does not. > > * nvidia one implements argument compatibility with x264 - so it uses > > the same args as much as possible - it even does preset/tune mapping. > > I think this is pretty nice. > > > > The main issue with the nvidia patch, as it exists today, is that they > > have not put any licence header on the files at all - but I've told > > them they need to do that, and asked Stephen Warren if he can help them > > out. The other slight complexity is that it requires cuda.h (Timo seems > > to have avoided that by independently defining the necessary constants > > but you need even more of cuda.h for the windows support). But > > nvEncoderAPI.h is already so awkward (restrictive license, not properly > > distributed) that an extra header isn't any more inconvenient. > > My implementation also works fine on Windows. (Tested is with MSVC, > MinGW and Cygwin) > The required functions from CUDA are minimal, and i just dynamicaly load > them, avoiding any (linked) external dependencies except the nvEncodeAPI.h > > The main difference is that they support way more features, but they > seem to need an intermediate library, while mine is now just a single > new C file, which needs one header from the nvenc SDK. does supporting these additional features need the extra complexity that the nvidia version has ? or could these features be added into your version while keeping its simplicity ? (note do not copy any code from the nvidia one as its not redistriutable nor *GPL compatible with the current license headers) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
On Thu, Nov 27, 2014 at 05:00:22PM +0100, Timo Rothenpieler wrote: > Refactored the code even more now, new, tested, patch is attached > and on github. > > The patch is ontop of my other patch that fixes the order in configure. > Changelog |1 > configure |6 > libavcodec/Makefile|1 > libavcodec/allcodecs.c |1 > libavcodec/nvenc.c | 1173 > + > 5 files changed, 1182 insertions(+) you may want to add yourself to MAINTAINERs for nvenc.c [...] -- 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] Add NVENC encoder
Le septidi 7 frimaire, an CCXXIII, Timo Rothenpieler a écrit :
> Done that primarily to keep things cleaned up and easier to read.
> Can as well put it all in one huge file.
IMHO, your choice in the end.
> Propably, will split that out when i get to it.
Thanks.
> Most of this code is ported from a C++ Project where everything had
> to be camel case, so those and the C++ malloc casts are some of the
> leftovers.
Idem, IMHO your choice.
> The maximum is the number of adjacent B Frames plus one. So 3 in the
> case of NVENC, unless they change the supported gop patterns.
In that case, I suspect to take some margin and use a hardcoded size for the
queue: with 8 or 16, there is plenty of time to update the size if nvidia
releases new GOP patterns.
> I basically need a fifo like structure, where i can queue output
> surfaces until NVENC is done filling them.
> An array doesn't realy reflect that usage, as new elements are added
> to the front, and taken from the back.
An array used as a circular buffer is perfect for that.
> Is a simple assert on the return value enough? Can't continue in a
> sane way anyway if it ever fails.
No: an assert can only be used when the error is not possible except for a
bug in the code. A malloc failure is always possible, so a proper error
handling, eventually returning ENOMEM, is necessary. That is annoying but
mostly unavoidable.
> I renamed it to enqueue/dequeue.
Thanks.
> This definitely can't be replaced, its purpose isn't just a plain
> list, but sorting of the input timestamps, so the dts is still
> monotonic after re-ordering for B frames.
As far as I can see, you do not need the sorting random access to the sorted
timestamps but only to be able to extract the lowest one. This is precisely
what a heap is very good at. I assure you, in this case a heap will be
almost as simple to implement (certainly simpler if you make it fixed-size)
and way more efficient.
> Only adding the CUDA error code, which then has to be looked up manualy.
Too bad ;(
> What do you mean by that? Printing which presets are available in
> the error message?
Yes. Something like that is always nice:
# x264 [error]: invalid preset 'list'
# [libx264 @ 0x172a560] Error setting preset/tune list/(null).
# [libx264 @ 0x172a560] Possible presets: ultrafast superfast veryfast faster
# fast medium slow slower veryslow placebo
# [libx264 @ 0x172a560] Possible tunes: film animation grain stillimage psnr
# ssim fastdecode zerolatency
> Not entirely sure why i did that this way. Copied it straight from
> the libx264 encoder, without thinking too much about it. I can just
> set the profileGUID straight from that switch and can remove the
> second profile variable(which the libx264 encoder has in exactly the
> same conflicting way) entirely.
It is entirely possible that libx264 has reasons that I do not know to do
things that way. It is also possible that the options are there just for
historic reasons.
> >>+default:
> >>+avctx->coded_frame->pict_type = AV_PICTURE_TYPE_NONE;
> Not that I'm aware of. But i don't know what else to assume in this case.
Then I believe some kind of feedback would be needed. If it is really never
supposed to happen, an assert is acceptable; otherwise, an error requesting
a sample may be better.
> The maximum supported number of surfaces is allocated, if it'd ever
> run out, there'd be a bug in the code managing the surfaces.
Then an assert is exactly what is needed.
> ff_cuCtxCreate is a library function loaded from the CUDA dll/so.
> Same for all the other ff_cu* functions, there is no way to change
> what it returns, as it's not my function.
I missed that, sorry.
> >>+#define ifav_log(...) if (avctx) { av_log(__VA_ARGS__); }
> >Looks strange: why no error message when there is no context?
> Is it possible to call av_log without a context?
Yes, it just prints the message without the [libfoo @ 0x42] prefix.
> No, does it need to be? Can multiple threads create the coded at the
> same time?
It looks like it is called from encode_init, which can definitely be called
by multiple threads.
Thanks for your efforts. Hope this helps.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add NVENC encoder
> I've spent a lot more time looking at the nvidia patch, but from a > quick look through Timo's version, I'd say the following: > > * Timo's is more concise but not as feature complete. > * nvidia one has windows support > * The nvidia patch doesn't handle b-frames correctly, but I wrote a > fix patch for them. I'm not sure whether Timo's works correctly > * Timo's looks like it will handle interlaced input correctly. Nvidia > definitely does not. > * nvidia one implements argument compatibility with x264 - so it uses > the same args as much as possible - it even does preset/tune mapping. > I think this is pretty nice. > > The main issue with the nvidia patch, as it exists today, is that they > have not put any licence header on the files at all - but I've told > them they need to do that, and asked Stephen Warren if he can help them > out. The other slight complexity is that it requires cuda.h (Timo seems > to have avoided that by independently defining the necessary constants > but you need even more of cuda.h for the windows support). But > nvEncoderAPI.h is already so awkward (restrictive license, not properly > distributed) that an extra header isn't any more inconvenient. My implementation also works fine on Windows. (Tested is with MSVC, MinGW and Cygwin) The required functions from CUDA are minimal, and i just dynamicaly load them, avoiding any (linked) external dependencies except the nvEncodeAPI.h The main difference is that they support way more features, but they seem to need an intermediate library, while mine is now just a single new C file, which needs one header from the nvenc SDK. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavutil/thread.h: Support OS/2 threads
On Fri, Nov 28, 2014 at 11:48:01PM -0800, Dave Yeo wrote: > Support OS/2 threading and correct an include that shouldn't be system. > Dave > both patches applied thanks [...] -- 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
