Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On Mon, Aug 11, 2014 at 01:49:19AM +0200, Michael Niedermayer wrote: > From: Luca Barbato > > TODO:bump > > Signed-off-by: Michael Niedermayer > --- > libswresample/Makefile |1 + > libswresample/swresample.h | 61 +++ > libswresample/swresample_frame.c | 158 > ++ > 3 files changed, 220 insertions(+) > create mode 100644 libswresample/swresample_frame.c > [...] > +/** > + * Convert the samples in the input AVFrame and write them to the output > AVFrame. > + * > + * Input and output AVFrames must have channel_layout, sample_rate and > format set. > + * > + * If the output AVFrame does not have the data pointers allocated the > nb_samples > + * field will be set using av_frame_get_buffer() > + * is called to allocate the frame. > + * > + * The output AVFrame can be NULL or have fewer allocated samples than > required. > + * In this case, any remaining samples not written to the output will be > added > + * to an internal FIFO buffer, to be returned at the next call to this > function > + * or to swr_convert() or to swr_convert_frame(). > + * > + * If converting sample rate, there may be data remaining in the internal > + * resampling delay buffer. swr_get_delay() tells the number of > + * remaining samples. To get this data as output, call this function or > + * swr_convert() with NULL input. > + * > + * If the SwrContext configuration does not match the output and > + * input AVFrame settings the conversion does not take place and depending on > + * which AVFrame is not matching AVERROR_OUTPUT_CHANGED, > AVERROR_INPUT_CHANGED > + * or AVERROR_OUTPUT_CHANGED|AVERROR_INPUT_CHANGED is returned. > + * > + * @see swr_delay() > + * @see swr_convert() > + * @see swr_get_delay() > + * > + * @param swr audio resample context > + * @param output output AVFrame > + * @param input input AVFrame > + * @return0 on success, AVERROR on failure or nonmatching > + *configuration. > + */ > +int swr_convert_frame(SwrContext *swr, > + AVFrame *output, AVFrame *input); > + Is it possible to have input AVFrame const or it needs to increment references or something? [...] -- Clément B. pgpT8PPO4SRcl.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On 11 August 2014 00:49, Michael Niedermayer wrote: > From: Luca Barbato Clearly this is Luca's patch but rewritten by you for swr so you should say "Based on patch from Luca for avresample" or similar. IANAL but this is quite dubious from a copyright perspective. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add C xvid IDCT support
On 2014-08-11 07:44, Clément Bœsch wrote: > /** > * @file > * Walken IDCT > * Alternative idct implementations for decoding compatibility > * > * @author Skal > * @note this "C" version is not the original one, but is modified to > * yield the same error profile than the MMX version. A minor grammar nit: yield the same error profile *as* the MMX version. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] delete the old segment file from hls list
Hi Guys,
The FFmpeg hls module can make m3u8 and ts, but it dosen't delete the
old ts segment file.
If always run this module, the disk will full, so this patch can fix
the problem.
When update the segment list m3u8 file, it will delete the ts segment
out range from the list file.
before use this patch:
[root@localhost ffmpeg]# ls *.ts *.m3u8
a0.ts a10.ts a11.ts a12.ts a13.ts a14.ts a15.ts a16.ts a17.ts
a18.ts a19.ts a1.ts a20.ts a2.ts a3.ts a4.ts a5.ts a6.ts a7.ts
a8.ts a9.ts a.m3u8
[root@localhost ffmpeg]# cat a.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:11
#EXT-X-MEDIA-SEQUENCE:16
#EXTINF:10.427075,
a16.ts
#EXTINF:10.427075,
a17.ts
#EXTINF:10.427075,
a18.ts
#EXTINF:10.427075,
a19.ts
#EXTINF:3.670330,
a20.ts
#EXT-X-ENDLIST
[root@localhost ffmpeg]#
after use this patch:
[root@localhost ffmpeg]# ls *.ts *.m3u8
a10.ts a11.ts a12.ts a13.ts a9.ts a.m3u8
[root@localhost ffmpeg]# cat a.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:11
#EXT-X-MEDIA-SEQUENCE:9
#EXTINF:10.427075,
a9.ts
#EXTINF:10.427075,
a10.ts
#EXTINF:10.427075,
a11.ts
#EXTINF:10.427075,
a12.ts
#EXTINF:2.335665,
a13.ts
#EXT-X-ENDLIST
[root@localhost ffmpeg]#
---
The patch context:
when update the hls m3u8 list, the old file is not unlinked
this patch can do this operation
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 11f1e5b..2ee0970 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -30,6 +30,10 @@
#include "avformat.h"
#include "internal.h"
+#if HAVE_UNISTD_H
+#include
+#endif
+
typedef struct HLSSegment {
char filename[1024];
@@ -115,6 +119,7 @@ static int hls_append_segment(HLSContext *hls, double
duration)
if (hls->max_nb_segments && hls->nb_entries >= hls->max_nb_segments) {
en = hls->segments;
hls->segments = en->next;
+unlink(en->filename);
av_free(en);
} else
hls->nb_entries++;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add C xvid IDCT support
On Mon, Aug 11, 2014 at 07:44:25AM +0200, Clément Bœsch wrote:
> On Mon, Aug 11, 2014 at 05:18:32AM +0200, Michael Niedermayer wrote:
> > From: Pascal Massimino
> >
> > Thanks to Pascal Massimino and Michael Militzer for permission to use under
> > LGPL
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/Makefile |2 +-
> > libavcodec/xvid_c_idct.c | 335
> > ++
> > libavcodec/xvididct.c| 60 +
> > libavcodec/xvididct.h|2 +
> > 4 files changed, 398 insertions(+), 1 deletion(-)
> > create mode 100644 libavcodec/xvid_c_idct.c
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 6873439..55b7b02 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -325,7 +325,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER) += mpeg12dec.o
> > mpeg12.o mpeg12data.o
> > OBJS-$(CONFIG_MPEG1VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
> > OBJS-$(CONFIG_MPEG2VIDEO_DECODER) += mpeg12dec.o mpeg12.o mpeg12data.o
> > OBJS-$(CONFIG_MPEG2VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
> > -OBJS-$(CONFIG_MPEG4_DECODER) += xvididct.o
> > +OBJS-$(CONFIG_MPEG4_DECODER) += xvididct.o xvid_c_idct.o
> > OBJS-$(CONFIG_MPL2_DECODER)+= mpl2dec.o ass.o
> > OBJS-$(CONFIG_MSMPEG4V1_DECODER) += msmpeg4dec.o msmpeg4.o
> > msmpeg4data.o
> > OBJS-$(CONFIG_MSMPEG4V2_DECODER) += msmpeg4dec.o msmpeg4.o
> > msmpeg4data.o
> > diff --git a/libavcodec/xvid_c_idct.c b/libavcodec/xvid_c_idct.c
> > new file mode 100644
> > index 000..b15fb8e
> > --- /dev/null
> > +++ b/libavcodec/xvid_c_idct.c
> > @@ -0,0 +1,335 @@
> > +/*
> > + *
> > + * XVID MPEG-4 VIDEO CODEC
> > + * - Inverse DCT -
> > + *
> > + * Copyright (C) 2006-2011 Xvid Solutions GmbH
> > + *
> > + * 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
> > + *
>
> > + * $Id$
> > + *
>
> No meaning in FFmpeg/git
removed
>
> > +
> > /
> > +
> > +/*
> > + * Authors: Skal
> > + *
> > + * Walken IDCT
> > + * Alternative idct implementations for decoding compatibility
> > + *
> > + * NOTE: this "C" version is not the original one,
> > + * but is modified to yield the same error profile
> > + * than the MMX version.
> > + *
> > + /
> > +
>
> /**
> * @file
> * Walken IDCT
> * Alternative idct implementations for decoding compatibility
> *
> * @author Skal
> * @note this "C" version is not the original one, but is modified to
> * yield the same error profile than the MMX version.
> */
ok copy and pasted that in
>
> > +#include "xvididct.h"
> > +
>
> > +
> > +#define XVID_DSP_CLIP_255(x) ( ((x)&~255) ? ((-(x)) >>
> > (8*sizeof((x))-1))&0xff : (x) )
>
> Looks unused
>
> > +
> > +#define ROW_SHIFT 11
> > +#define COL_SHIFT 6
> > +
> > +// #define FIX(x) (int)((x) * (1< > +#define Rnd0 65536 // 1<<(COL_SHIFT+ROW_SHIFT-1);
> > +#define Rnd1 3597 // FIX (1.75683487303);
> > +#define Rnd2 2260 // FIX (1.10355339059);
> > +#define Rnd3 1203 // FIX (0.587788325588);
> > +#define Rnd4 0
> > +#define Rnd5 120 // FIX (0.058658283817);
> > +#define Rnd6 512 // FIX (0.25);
> > +#define Rnd7 512 // FIX (0.25);
>
> > +#undef FIX
>
> Mot defined
Ill submit a patch to xvid about these, if they are accepted ill
merge them in our version
>
> > +
> > +static const int Tab04[] = { 22725, 21407, 19266, 16384, 12873, 8867,
> > 4520 };
> > +static const int Tab17[] = { 31521, 29692, 26722, 22725, 17855, 12299,
> > 6270 };
> > +static const int Tab26[] = { 29692, 27969, 25172, 21407, 16819, 11585,
> > 5906 };
> > +static const int Tab35[] = { 26722, 25172, 22654, 19266, 15137, 10426,
> > 5315 };
> > +
> > +static int Idct_Row(short * In, const int * const Tab, int Rnd)
> > +{
> > + const int C1 = Tab[0];
> > + const int C2 = Tab[1];
> > + const int C3 = Tab[2];
> > + const int C4 = Tab[3];
> > + const int C5 = Tab[4];
> > + const int C6 = Tab[5];
> > + const int C7 = Tab[6];
> > +
> > + const int Right
Re: [FFmpeg-devel] [PATCH] avcodec: add C xvid IDCT support
On Mon, Aug 11, 2014 at 10:56:11AM +0200, James Darnley wrote: > On 2014-08-11 07:44, Clément Bœsch wrote: > > /** > > * @file > > * Walken IDCT > > * Alternative idct implementations for decoding compatibility > > * > > * @author Skal > > * @note this "C" version is not the original one, but is modified to > > * yield the same error profile than the MMX version. > > A minor grammar nit: > > yield the same error profile *as* the MMX version. ill submit a patch for that as well [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." 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: add C xvid IDCT support
On 2014-08-11 12:39, Michael Niedermayer wrote: > On Mon, Aug 11, 2014 at 10:56:11AM +0200, James Darnley wrote: >> On 2014-08-11 07:44, Clément Bœsch wrote: >>> /** >>> * @file >>> * Walken IDCT >>> * Alternative idct implementations for decoding compatibility >>> * >>> * @author Skal >>> * @note this "C" version is not the original one, but is modified to >>> * yield the same error profile than the MMX version. >> >> A minor grammar nit: >> >> yield the same error profile *as* the MMX version. > > ill submit a patch for that as well Sorry, I didn't realize that this was just copied from the xvid original. 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] avcodec: add C xvid IDCT support
On Mon, Aug 11, 2014 at 12:36:56AM -0300, James Almer wrote:
> On 11/08/14 12:18 AM, Michael Niedermayer wrote:
> > From: Pascal Massimino
> >
> > Thanks to Pascal Massimino and Michael Militzer for permission to use under
> > LGPL
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/Makefile |2 +-
> > libavcodec/xvid_c_idct.c | 335
> > ++
> > libavcodec/xvididct.c| 60 +
> > libavcodec/xvididct.h|2 +
> > 4 files changed, 398 insertions(+), 1 deletion(-)
> > create mode 100644 libavcodec/xvid_c_idct.c
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 6873439..55b7b02 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -325,7 +325,7 @@ OBJS-$(CONFIG_MPEG1VIDEO_DECODER) += mpeg12dec.o
> > mpeg12.o mpeg12data.o
> > OBJS-$(CONFIG_MPEG1VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
> > OBJS-$(CONFIG_MPEG2VIDEO_DECODER) += mpeg12dec.o mpeg12.o mpeg12data.o
> > OBJS-$(CONFIG_MPEG2VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
> > -OBJS-$(CONFIG_MPEG4_DECODER) += xvididct.o
> > +OBJS-$(CONFIG_MPEG4_DECODER) += xvididct.o xvid_c_idct.o
> > OBJS-$(CONFIG_MPL2_DECODER)+= mpl2dec.o ass.o
> > OBJS-$(CONFIG_MSMPEG4V1_DECODER) += msmpeg4dec.o msmpeg4.o
> > msmpeg4data.o
> > OBJS-$(CONFIG_MSMPEG4V2_DECODER) += msmpeg4dec.o msmpeg4.o
> > msmpeg4data.o
> > diff --git a/libavcodec/xvid_c_idct.c b/libavcodec/xvid_c_idct.c
> > new file mode 100644
> > index 000..b15fb8e
> > --- /dev/null
> > +++ b/libavcodec/xvid_c_idct.c
> > @@ -0,0 +1,335 @@
> > +/*
> > + *
> > + * XVID MPEG-4 VIDEO CODEC
> > + * - Inverse DCT -
> > + *
> > + * Copyright (C) 2006-2011 Xvid Solutions GmbH
> > + *
> > + * 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
> > + *
> > + * $Id$
> > + *
> > +
> > /
> > +
> > +/*
> > + * Authors: Skal
> > + *
> > + * Walken IDCT
> > + * Alternative idct implementations for decoding compatibility
> > + *
> > + * NOTE: this "C" version is not the original one,
> > + * but is modified to yield the same error profile
> > + * than the MMX version.
> > + *
> > + /
>
> Is a separate file really necessary? The above copyright could be copied to
> xvididct.c just fine.
> It's all lgpl code.
a seperate file is not neccessary but may make future syncing with
xvid easier
>
> [...]
>
> > diff --git a/libavcodec/xvididct.c b/libavcodec/xvididct.c
> > index 8645af4..9b07518 100644
> > --- a/libavcodec/xvididct.c
> > +++ b/libavcodec/xvididct.c
> > @@ -22,6 +22,59 @@
> > #include "idctdsp.h"
> > #include "xvididct.h"
> >
> > +static void put_pixels_clamped_c(const int16_t *block, uint8_t
> > *av_restrict pixels,
> > + int line_size)
> > +{
> > +int i;
> > +
> > +/* read the pixels */
> > +for (i = 0; i < 8; i++) {
> > +pixels[0] = av_clip_uint8(block[0]);
> > +pixels[1] = av_clip_uint8(block[1]);
> > +pixels[2] = av_clip_uint8(block[2]);
> > +pixels[3] = av_clip_uint8(block[3]);
> > +pixels[4] = av_clip_uint8(block[4]);
> > +pixels[5] = av_clip_uint8(block[5]);
> > +pixels[6] = av_clip_uint8(block[6]);
> > +pixels[7] = av_clip_uint8(block[7]);
> > +
> > +pixels += line_size;
> > +block += 8;
> > +}
> > +}
> > +
> > +static void add_pixels_clamped_c(const int16_t *block, uint8_t
> > *av_restrict pixels,
> > + int line_size)
> > +{
> > +int i;
> > +
> > +/* read the pixels */
> > +for (i = 0; i < 8; i++) {
> > +pixels[0] = av_clip_uint8(pixels[0] + block[0]);
> > +pixels[1] = av_clip_uint8(pixels[1] + block[1]);
> > +pixels[2] = av_clip_uint8(pixels[2] + block[2]);
> > +pixels[3] = av_clip_uint8(pixels[3] + block[3]);
> > +pixels[4] = av_clip_uint8(pixels[4] + block[4]);
> > +pixels[5] = av_clip_uint8(pixels[5]
Re: [FFmpeg-devel] [PATCH 1/4] lavc: stop exporting internal functions and tables
On Sat, Aug 09, 2014 at 09:04:32PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/libavcodec.v | 18 -- > 1 file changed, 18 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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/2] lavc/raw: remove obsolete ff_raw_pix_fmt_tags cruft
On Sat, Aug 09, 2014 at 10:01:46PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/raw.h | 4 > 1 file changed, 4 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/mpegts: remove obsolete ff_mpegts_parse_* cruft
On Sat, Aug 09, 2014 at 10:01:47PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/mpegts.c | 18 -- > libavformat/mpegts.h | 7 --- > 2 files changed, 25 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/metadata: Implement AVFMT_FLAG_NO_META_CONV
Decoders/parsers run ff_metadata_conv() unconditionally. This makes
it impossible to retrieve or keep original metadata field names.
If one wishes to skip ff_metadata_conv() calls at the decoding/parsing
stage. This patch implements AVFMT_FLAG_NO_META_CONV which is set by
the decoding fflag opt parameter 'nometaconv'.
Signed-off-by: Mohammad Alsaleh
---
doc/APIchanges | 3 +++
doc/formats.texi | 2 ++
libavformat/asfdec.c | 3 ++-
libavformat/avformat.h | 1 +
libavformat/id3v2.c | 17 -
libavformat/matroskadec.c| 4 +++-
libavformat/metadata.c | 4
libavformat/oggparsevorbis.c | 3 ++-
libavformat/options_table.h | 1 +
libavformat/version.h| 2 +-
libavformat/wtvdec.c | 3 ++-
11 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index b7961ae..854563a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+2014-08-xx - xxx - lavf 56.1.100 - avformat.h
+ Add AVFMT_FLAG_NO_META_CONV.
+
2014-04-xx - xxx - lavr 2.1.0 - avresample.h
Add avresample_convert_frame() and avresample_config().
diff --git a/doc/formats.texi b/doc/formats.texi
index 027510e..92c079d 100644
--- a/doc/formats.texi
+++ b/doc/formats.texi
@@ -51,6 +51,8 @@ Discard corrupted frames.
Try to interleave output packets by DTS.
@item keepside
Do not merge side data.
+@item nometaconv
+Skip conversion of metadata field names.
@item latm
Enable RTP MP4A-LATM payload.
@item nobuffer
diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c
index 5fc293e..13c7806 100644
--- a/libavformat/asfdec.c
+++ b/libavformat/asfdec.c
@@ -862,7 +862,8 @@ static int asf_read_header(AVFormatContext *s)
}
}
-ff_metadata_conv(&s->metadata, NULL, ff_asf_metadata_conv);
+if (!(s->flags & AVFMT_FLAG_NO_META_CONV))
+ff_metadata_conv(&s->metadata, NULL, ff_asf_metadata_conv);
return 0;
}
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index a4f7ed7..12fba94 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1287,6 +1287,7 @@ typedef struct AVFormatContext {
#define AVFMT_FLAG_SORT_DTS0x1 ///< try to interleave outputted
packets by dts (using this flag can slow demuxing down)
#define AVFMT_FLAG_PRIV_OPT0x2 ///< Enable use of private options by
delaying codec open (this could be made default once all code is converted)
#define AVFMT_FLAG_KEEP_SIDE_DATA 0x4 ///< Don't merge side data but keep
it separate.
+#define AVFMT_FLAG_NO_META_CONV 0x8 ///< Skip conversion of metadata field
names.
/**
* @deprecated deprecated in favor of probesize2
diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index fb89e83..c2bcbe0 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -574,8 +574,11 @@ static void read_chapter(AVFormatContext *s, AVIOContext
*pb, int len, char *tta
len -= taglen;
}
-ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_34_metadata_conv);
-ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_4_metadata_conv);
+if (!(s->flags & AVFMT_FLAG_NO_META_CONV)) {
+ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_34_metadata_conv);
+ff_metadata_conv(&chapter->metadata, NULL, ff_id3v2_4_metadata_conv);
+}
+
end:
av_free(dst);
}
@@ -916,9 +919,13 @@ static void id3v2_read_internal(AVIOContext *pb,
AVDictionary **metadata,
avio_seek(pb, off, SEEK_SET);
}
} while (found_header);
-ff_metadata_conv(metadata, NULL, ff_id3v2_34_metadata_conv);
-ff_metadata_conv(metadata, NULL, id3v2_2_metadata_conv);
-ff_metadata_conv(metadata, NULL, ff_id3v2_4_metadata_conv);
+
+if (!(s->flags & AVFMT_FLAG_NO_META_CONV)) {
+ff_metadata_conv(metadata, NULL, ff_id3v2_34_metadata_conv);
+ff_metadata_conv(metadata, NULL, id3v2_2_metadata_conv);
+ff_metadata_conv(metadata, NULL, ff_id3v2_4_metadata_conv);
+}
+
merge_date(metadata);
}
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 31ee456..347dbcd 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1377,7 +1377,9 @@ static void matroska_convert_tag(AVFormatContext *s,
EbmlList *list,
matroska_convert_tag(s, &tags[i].sub, metadata, key);
}
}
-ff_metadata_conv(metadata, NULL, ff_mkv_metadata_conv);
+
+if (!(s->flags & AVFMT_FLAG_NO_META_CONV))
+ff_metadata_conv(metadata, NULL, ff_mkv_metadata_conv);
}
static void matroska_convert_tags(AVFormatContext *s)
diff --git a/libavformat/metadata.c b/libavformat/metadata.c
index b9b6de7..bba7af7 100644
--- a/libavformat/metadata.c
+++ b/libavformat/metadata.c
@@ -60,6 +60,10 @@ void ff_metadata_conv_ctx(AVFormatContext *ctx, const
AVMetadataConv *d_conv,
Re: [FFmpeg-devel] [PATCH 2/4] lavf: stop exporting internal functions
On Sat, Aug 09, 2014 at 09:04:33PM -0300, James Almer wrote: > Except for those currently used by ffserver. > > Signed-off-by: James Almer > --- > libavformat/libavformat.v | 9 - > 1 file changed, 9 deletions(-) mostly applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: export motion vectors in frame side data on demand
From: Clément Bœsch
The reasoning behind this addition is that various third party
applications are interested in getting some motion information out of a
video "for free" when it is available.
It was considered to export other information as well (such as the intra
information about the block, or the quantization) but the structure
might have ended up into a half full-generic, half full of codec
specific cruft. If more information is necessary, it should either be
added in the "flags" field of the AVExportedMV structure, or in another
side-data.
This commit also includes an example exporting them in a CSV stream.
---
TODO: avcodec version bump & APIChanges entry
---
.gitignore | 1 +
configure | 2 +
doc/Makefile | 1 +
doc/codecs.texi| 3 +
doc/examples/Makefile | 1 +
doc/examples/extract_mvs.c | 185 +
libavcodec/avcodec.h | 1 +
libavcodec/mpegvideo.c | 102 -
libavcodec/options_table.h | 1 +
libavutil/frame.h | 6 ++
libavutil/mvinfo.h | 49
11 files changed, 351 insertions(+), 1 deletion(-)
create mode 100644 doc/examples/extract_mvs.c
create mode 100644 libavutil/mvinfo.h
diff --git a/.gitignore b/.gitignore
index cb370bb..480fbe0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,7 @@
/doc/examples/avio_reading
/doc/examples/decoding_encoding
/doc/examples/demuxing_decoding
+/doc/examples/extract_mvs
/doc/examples/filter_audio
/doc/examples/filtering_audio
/doc/examples/filtering_video
diff --git a/configure b/configure
index 0ac6132..a93fc06 100755
--- a/configure
+++ b/configure
@@ -1306,6 +1306,7 @@ EXAMPLE_LIST="
avio_reading_example
decoding_encoding_example
demuxing_decoding_example
+extract_mvs_example
filter_audio_example
filtering_audio_example
filtering_video_example
@@ -2586,6 +2587,7 @@ zoompan_filter_deps="swscale"
avio_reading="avformat avcodec avutil"
avcodec_example_deps="avcodec avutil"
demuxing_decoding_example_deps="avcodec avformat avutil"
+extract_mvs_example_deps="avcodec avformat avutil"
filter_audio_example_deps="avfilter avutil"
filtering_audio_example_deps="avfilter avcodec avformat avutil"
filtering_video_example_deps="avfilter avcodec avformat avutil"
diff --git a/doc/Makefile b/doc/Makefile
index 99f588a..2fb9058 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -39,6 +39,7 @@ DOCS = $(DOCS-yes)
DOC_EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE) += avio_reading
DOC_EXAMPLES-$(CONFIG_AVCODEC_EXAMPLE) += avcodec
DOC_EXAMPLES-$(CONFIG_DEMUXING_DECODING_EXAMPLE) += demuxing_decoding
+DOC_EXAMPLES-$(CONFIG_EXTRACT_MVS_EXAMPLE) += extract_mvs
DOC_EXAMPLES-$(CONFIG_FILTER_AUDIO_EXAMPLE) += filter_audio
DOC_EXAMPLES-$(CONFIG_FILTERING_AUDIO_EXAMPLE) += filtering_audio
DOC_EXAMPLES-$(CONFIG_FILTERING_VIDEO_EXAMPLE) += filtering_video
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 1160e5d..7aaa229 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -797,6 +797,9 @@ Frame data might be split into multiple chunks.
Show all frames before the first keyframe.
@item skiprd
Deprecated, use mpegvideo private options instead.
+@item export_mvs
+Export motion vectors into frame side-data (see @code{AV_FRAME_DATA_MV_INFO})
+for codecs that support it. See also @file{doc/examples/export_mvs.c}.
@end table
@item error @var{integer} (@emph{encoding,video})
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 03c7021..07251fe 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -14,6 +14,7 @@ LDLIBS := $(shell pkg-config --libs $(FFMPEG_LIBS)) $(LDLIBS)
EXAMPLES= avio_reading \
decoding_encoding \
demuxing_decoding \
+extract_mvs\
filtering_video\
filtering_audio\
metadata \
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
new file mode 100644
index 000..69f76cd
--- /dev/null
+++ b/doc/examples/extract_mvs.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright (c) 2012 Stefano Sabatini
+ * Copyright (c) 2014 Clément Bœsch
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWA
Re: [FFmpeg-devel] rectification filter
Am 11.08.2014 um 00:20 schrieb Michael Niedermayer : > On Sun, Aug 10, 2014 at 08:36:37PM +0200, Daniel Oberhoff wrote: >> >> >> Von meinem iPhone gesendet >> >>> Am 10.08.2014 um 17:50 schrieb Michael Niedermayer : >>> On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote: Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit : > It is not mandatory(but it would be nice) to add other methods to have > this filter included into libavfilter. Is it really a good idea? We would end up with various interpolation / anti-aliasing algorithms implemented in each filter that needs it, none of them with the same set of architecture optimizations and each with its own set of bugs and misfeatures. >>> Until someone comes up with a really satisfactory solution, I believe the simple solution of suggesting users to upscale before the filter and downscale after, using the optimized lswr scalers, is better. >>> >>> thats not practical >>> a 1024x768 image would need to be upscaled to 262144x196608 to get >>> 8bit precission from a nearest neighbor resampler as basis >>> >>> also see vf_perspective.c which supports bilinear and bicubic >>> interpolation, these surely could be shared and exist already. >>> >>> of course we could push it with just nearest neighbor and work on that >>> later, but i dont think only nearest neighbor and leaving it at that >>> is a reasonable choice, its too poor quality wise >> >> I would like to push now, and try to generate a refactoring patch possibly >> within the week. > > sure, feel free to push and send a pull request, or if you prefer > i can allso apply the patch if you post the latest verision I am not sure about pull requests (would have to read up on how to do that properly) so rigjht now I would prefer it by patch: Is that ok? Best and thanks! Daniel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] rectification filter
On Mon, Aug 11, 2014 at 05:33:10PM +0200, Daniel Oberhoff wrote: > > Am 11.08.2014 um 00:20 schrieb Michael Niedermayer : > > > On Sun, Aug 10, 2014 at 08:36:37PM +0200, Daniel Oberhoff wrote: > >> > >> > >> Von meinem iPhone gesendet > >> > >>> Am 10.08.2014 um 17:50 schrieb Michael Niedermayer : > >>> > On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote: > Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit : > > It is not mandatory(but it would be nice) to add other methods to have > > this filter included into libavfilter. > > Is it really a good idea? We would end up with various interpolation / > anti-aliasing algorithms implemented in each filter that needs it, none > of > them with the same set of architecture optimizations and each with its > own > set of bugs and misfeatures. > >>> > Until someone comes up with a really satisfactory solution, I believe the > simple solution of suggesting users to upscale before the filter and > downscale after, using the optimized lswr scalers, is better. > >>> > >>> thats not practical > >>> a 1024x768 image would need to be upscaled to 262144x196608 to get > >>> 8bit precission from a nearest neighbor resampler as basis > >>> > >>> also see vf_perspective.c which supports bilinear and bicubic > >>> interpolation, these surely could be shared and exist already. > >>> > >>> of course we could push it with just nearest neighbor and work on that > >>> later, but i dont think only nearest neighbor and leaving it at that > >>> is a reasonable choice, its too poor quality wise > >> > >> I would like to push now, and try to generate a refactoring patch possibly > >> within the week. > > > > sure, feel free to push and send a pull request, or if you prefer > > i can allso apply the patch if you post the latest verision > > I am not sure about pull requests (would have to read up on how to do that > properly) so rigjht now I would prefer it by patch: > > > > Is that ok? > Yes, please just re-submit the patch here. Sorry about the suggestion of adding FATE tests, I forgot the fact that the filter was actually using floats. > Best and thanks! > > Daniel -- Clément B. pgpGPOVdeEpWh.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote: > > High quality libraries must iterate on their API. Especially for a library > trying to solve such a complex problem as audio and video encoding and > decoding for every codec and format. It is unreasonable to expect no > incompatible changes. Also both ffmpeg and libav codebases have a lot of > legacy cruft. Libav is making a more concentrated effort at improving this, > and the evolving API is a side-effect of that. I beg to differ. My definition of a "high quality library" is one where careful design is taken into account when designing the ABI/API's in the first place, and which if absolutely necessary, uses ELF symbol versioning to maintain ABI compatibility. There are plenty of "high quality libraries" (glibc, libext2fs, etc.) where we've been able to maintain full ABI compatibility even while adding new features --- including in the case of libext2fs, migrating from 32-bit to 64-bit block numbers. And if you're careful in your design and implementation, the amount of cruft required can be kept to a very low minimum. - Ted ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, 2014-08-10 at 23:02 +0200, Andreas Cadhalpun wrote: [...] > * dvswitch: Still uses CodecID (and also avcodec_encode_video, but > that is still present in FFmpeg.) [3] [...] dvswitch was also broken by the removal of support for downscaled decoding of DV video. I don't know whether that change is specific to libav or was also made in FFmpeg. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Montag, 11. August 2014, Ben Hutchings wrote: > dvswitch was also broken by the removal of support for downscaled > decoding of DV video. I don't know whether that change is specific to > libav or was also made in FFmpeg. dvswitch is still broken and there is no dvswitch in jessie... We have a daily job testing against libav from git, but that was alwayys broken everyday in the last half year or so. Maybe it would be useful to setup building against ffmpeg. cheers, Holger signature.asc Description: This is a digitally signed message part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add missing initialization for AVProbeData.
This has become necessary since the new mime field was added.
Signed-off-by: Reimar Döffinger
---
libavformat/img2dec.c | 2 +-
tools/probetest.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index d70fc75..a82f50f 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -308,7 +308,7 @@ int ff_img_read_header(AVFormatContext *s1)
int probe_buffer_size = 2048;
uint8_t *probe_buffer = av_realloc(NULL, probe_buffer_size +
AVPROBE_PADDING_SIZE);
AVInputFormat *fmt = NULL;
-AVProbeData pd;
+AVProbeData pd = { 0 };
if (!probe_buffer)
return AVERROR(ENOMEM);
diff --git a/tools/probetest.c b/tools/probetest.c
index b685e3d..78327de 100644
--- a/tools/probetest.c
+++ b/tools/probetest.c
@@ -78,7 +78,7 @@ static void print_times(void)
int main(int argc, char **argv)
{
unsigned int p, i, type, size, retry;
-AVProbeData pd;
+AVProbeData pd = { 0 };
AVLFG state;
PutBitContext pb;
int retry_count= 4097;
--
2.1.0.rc1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Should add AVProbeData change to API changes + release notes
Hello, (sorry for being too lazy to send a patch) With the major version bump AVProbeData was extended by a new field. This so far has broken 3 places within FFmpeg and one within MPlayer, where AVProbeData was only initialized field-by-field. This will cause "random" crashes. I'm at this point fairly certain a lot of other software will have the same issue. I suggest we make add a big note with the release that everyone should check their software for uses of AVProbeData that might result in parts of that struct not being initialized. Reimar ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add missing initialization for AVProbeData.
Reimar Döffinger gmx.de> writes: > This has become necessary since the new mime field was added. The patch is definitely ok, sorry for missing this when I fixed one occurrence. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
Hi Ivan, On 11.08.2014 01:23, Ivan Kalvachev wrote: The patch is inspired by something I read in the Debian discussion. Libav and FFmpeg could be installed side by side without conflicts in the libraries, thanks to using additional suffixes. Thanks for your interest in the matter. However development/include files are still conflicting, so I thought of a simple configure hack to give more control to FFmpeg. With this patch you can do `./configure --extra-incdir="/ffmpeg" ` , as result the header files would be installed in "/usr/local/include/ffmpeg" e.g. "/usr/local/include/ffmpeg/libavcodec/avcodec.h" ... Assuming it would be possible to install development packages for both at the same time, which one should be used, when building a program? The change is reflected in the pkgconfig files too. Since applications that link to libraries with addition suffixes should be using pkgconfig, they would be using the correct header includes automatically. If that's to be determined via pkg-config files, then the obvious problem is that both install these files in the same location, and if one doesn't, programs can't find the library. I did just a rudimentary test and I couldn't spot anything wrong. Please test it before inclusion. The patch seems to be alright, but it doesn't make it possible to make the development packages of FFmpeg and Libav co-installable. As for the future, it might be good idea next major release (e.g. 3.0) to have the $prefix/include/ffmpeg as default include path (for non-comapt build). So this would also not help. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavu: stop exporting internal functions
On 10.08.2014 02:04, James Almer wrote:
Signed-off-by: James Almer
---
libavutil/libavutil.v | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/libavutil.v b/libavutil/libavutil.v
index eb16ae1..e9f04cb 100644
--- a/libavutil/libavutil.v
+++ b/libavutil/libavutil.v
@@ -1,4 +1,4 @@
LIBAVUTIL_$MAJOR {
-global: av*; ff_*;
+global: av*;
local: *;
};
I'd also like to see this happen, but this change requires to first
convert ff_opencl_set_parameter into avpriv*, because it is used by
libavfilter.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hello,
Apologies for not being able to resist answering even if it is getting
off-topic.
On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote:
> On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote:
> >
> > High quality libraries must iterate on their API. Especially for a library
> > trying to solve such a complex problem as audio and video encoding and
> > decoding for every codec and format. It is unreasonable to expect no
> > incompatible changes. Also both ffmpeg and libav codebases have a lot of
> > legacy cruft. Libav is making a more concentrated effort at improving this,
> > and the evolving API is a side-effect of that.
>
> I beg to differ. My definition of a "high quality library" is one
> where careful design is taken into account when designing the
> ABI/API's in the first place, and which if absolutely necessary, uses
> ELF symbol versioning to maintain ABI compatibility.
>
> There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
> where we've been able to maintain full ABI compatibility even while
> adding new features --- including in the case of libext2fs, migrating
> from 32-bit to 64-bit block numbers. And if you're careful in your
> design and implementation, the amount of cruft required can be kept to
> a very low minimum.
While you certainly have a point that we have a lot to learn and improve,
your comparison is not entirely fair, for reasons like
a) glibc, libext2fs are much older projects, we still have to
pay for old sins, from times where everyone was happy when
their video played at all on Linux and nobody complained about
ABI compatibility. Not to mention few of us having much experience
in software development.
b) A good number of our users are on Windows, which makes symbol
versioning a very undesirable solution. Sometimes that means alternative
solutions which are messier or more likely to break compatibility by
accident
c) For libext2fs your users won't claim a file system is ext2, when it
is actually btrfs and still expect your ext2 library to work with it!
That is very much the standard in multimedia ("everything is .avi",
"I don't care what format it is, I just want it to play", ...).
Nor do you have competing ext2 implementations adding completely
mis-designed extensions to it, with everyone expecting you to support it, that
definitely makes API design a _lot_ more challenging.
d) At least in the case of glibc that backwards-compatibility is not at
all free to its current users. _IO_stdin_used is a prime example of that,
anyone playing with methods to reduce binary size/strip symbols will stumble
over that and curse very loudly at some point.
I certainly would have preferred it to not be ABI compatible in that
case!
Regards,
Reimar
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add missing initialization for AVProbeData.
On Mon, Aug 11, 2014 at 06:09:54PM +, Carl Eugen Hoyos wrote: > Reimar Döffinger gmx.de> writes: > > > This has become necessary since the new mime field was added. > > The patch is definitely ok, sorry for missing this > when I fixed one occurrence. I'm glad you fixed the other one first, it made it much easier for me to realize the issue (in MPlayer, this patch is just a result of me deciding to double-check in FFmpeg as well while at it. And I still might have missed some)! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf: stop exporting internal functions
> ffmpeg | branch: master | James Almer | Sat Aug 9 > 21:04:33 2014 -0300| [7b3de03c8fa7c7a49522b45dc90f9970417554b4] | committer: > Michael Niedermayer > > lavf: stop exporting internal functions > > Except for those currently used by ffserver. > > Signed-off-by: James Almer > > Also left some others that seemed used by applications other than ffserver We shouldn't leave these hacks just so another project can abuse the API. It's not our responsibility. If these functions are used by other projects and they can't fix their stuff with the available public API, then we should see how feasible making them public is and considering doing that. And ideally, we should also take the opportunity to fix ffserver and get rid of every ff* export. But whatever we do it should be done asap since we just bumped and no release was made just yet. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavu: stop exporting internal functions
On 11/08/14 3:39 PM, Andreas Cadhalpun wrote:
> On 10.08.2014 02:04, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavutil/libavutil.v | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/libavutil.v b/libavutil/libavutil.v
>> index eb16ae1..e9f04cb 100644
>> --- a/libavutil/libavutil.v
>> +++ b/libavutil/libavutil.v
>> @@ -1,4 +1,4 @@
>> LIBAVUTIL_$MAJOR {
>> -global: av*; ff_*;
>> +global: av*;
>> local: *;
>> };
>>
>
> I'd also like to see this happen, but this change requires to first convert
> ff_opencl_set_parameter into avpriv*, because it is used by libavfilter.
>
> Best regards,
> Andreas
Right, i didn't enable opencl when i tested this.
Will send a patch later, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] dict.c: Add av_dict_set_int helper function.
This allows getting rid of the many, slightly differing, implementations
of basically the same thing.
Signed-off-by: Reimar Döffinger
---
doc/APIchanges | 3 +++
libavutil/dict.c| 8
libavutil/dict.h| 8
libavutil/version.h | 2 +-
4 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index b7961ae..5613452 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2014-08-09
API changes, most recent first:
+2014-xx-xx - xxx - lavu 52.95.100 - dict.h
+ Add av_dict_set_int helper function.
+
2014-04-xx - xxx - lavr 2.1.0 - avresample.h
Add avresample_convert_frame() and avresample_config().
diff --git a/libavutil/dict.c b/libavutil/dict.c
index aea8910..9fdc6d6 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -122,6 +122,14 @@ int av_dict_set(AVDictionary **pm, const char *key, const
char *value,
return 0;
}
+int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value,
+int flags)
+{
+char valuestr[22];
+snprintf(valuestr, sizeof(valuestr), "%"PRId64, value);
+return av_dict_set(pm, key, valuestr, flags);
+}
+
static int parse_key_value_pair(AVDictionary **pm, const char **buf,
const char *key_val_sep, const char *pairs_sep,
int flags)
diff --git a/libavutil/dict.h b/libavutil/dict.h
index 025d867..06f1621 100644
--- a/libavutil/dict.h
+++ b/libavutil/dict.h
@@ -31,6 +31,8 @@
#ifndef AVUTIL_DICT_H
#define AVUTIL_DICT_H
+#include
+
#include "version.h"
/**
@@ -123,6 +125,12 @@ int av_dict_count(const AVDictionary *m);
int av_dict_set(AVDictionary **pm, const char *key, const char *value, int
flags);
/**
+ * Convenience wrapper for av_dict_set that converts the value to a string
+ * and stores it.
+ */
+int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, int
flags);
+
+/**
* Parse the key/value pairs list and add the parsed entries to a dictionary.
*
* In case of failure, all the successfully set entries are stored in
diff --git a/libavutil/version.h b/libavutil/version.h
index 23b331d..43114c7 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -56,7 +56,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 54
-#define LIBAVUTIL_VERSION_MINOR 1
+#define LIBAVUTIL_VERSION_MINOR 2
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.1.0.rc1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] Use new av_dict_set_int helper function.
Get rid of the many, slightly differing, implementations
of basically the same thing.
Signed-off-by: Reimar Döffinger
---
ffmpeg_opt.c | 12 +++-
ffplay.c | 2 +-
libavfilter/vf_bbox.c| 4 +---
libavfilter/vf_cropdetect.c | 4 +---
libavformat/cinedec.c| 4 +---
libavformat/ftp.c| 10 --
libavformat/hls.c| 17 -
libavformat/id3v1.c | 4 +---
libavformat/matroskadec.c| 31 +++
libavformat/mlvdec.c | 16
libavformat/mov.c| 14 +++---
libavformat/mxfdec.c | 8 ++--
libavformat/smoothstreamingenc.c | 4 +---
libavformat/vqf.c| 6 +-
14 files changed, 34 insertions(+), 102 deletions(-)
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 1962cf4..f738e27 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -785,7 +785,6 @@ static int open_input_file(OptionsContext *o, const char
*filename)
AVInputFormat *file_iformat = NULL;
int err, i, ret;
int64_t timestamp;
-uint8_t buf[128];
AVDictionary **opts;
AVDictionary *unused_opts = NULL;
AVDictionaryEntry *e = NULL;
@@ -814,8 +813,7 @@ static int open_input_file(OptionsContext *o, const char
*filename)
exit_program(1);
}
if (o->nb_audio_sample_rate) {
-snprintf(buf, sizeof(buf), "%d",
o->audio_sample_rate[o->nb_audio_sample_rate - 1].u.i);
-av_dict_set(&o->g->format_opts, "sample_rate", buf, 0);
+av_dict_set_int(&o->g->format_opts, "sample_rate",
o->audio_sample_rate[o->nb_audio_sample_rate - 1].u.i, 0);
}
if (o->nb_audio_channels) {
/* because we set audio_channels based on both the "ac" and
@@ -824,9 +822,7 @@ static int open_input_file(OptionsContext *o, const char
*filename)
if (file_iformat && file_iformat->priv_class &&
av_opt_find(&file_iformat->priv_class, "channels", NULL, 0,
AV_OPT_SEARCH_FAKE_OBJ)) {
-snprintf(buf, sizeof(buf), "%d",
- o->audio_channels[o->nb_audio_channels - 1].u.i);
-av_dict_set(&o->g->format_opts, "channels", buf, 0);
+av_dict_set_int(&o->g->format_opts, "channels",
o->audio_channels[o->nb_audio_channels - 1].u.i, 0);
}
}
if (o->nb_frame_rates) {
@@ -2058,9 +2054,7 @@ loop_end:
assert_file_overwrite(filename);
if (o->mux_preload) {
-uint8_t buf[64];
-snprintf(buf, sizeof(buf), "%d", (int)(o->mux_preload*AV_TIME_BASE));
-av_dict_set(&of->opts, "preload", buf, 0);
+av_dict_set_int(&of->opts, "preload", o->mux_preload*AV_TIME_BASE, 0);
}
oc->max_delay = (int)(o->mux_max_delay * AV_TIME_BASE);
diff --git a/ffplay.c b/ffplay.c
index e1e4ccc..662b7f9 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2582,7 +2582,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
if (!av_dict_get(opts, "threads", NULL, 0))
av_dict_set(&opts, "threads", "auto", 0);
if (stream_lowres)
-av_dict_set(&opts, "lowres", av_asprintf("%d", stream_lowres),
AV_DICT_DONT_STRDUP_VAL);
+av_dict_set_int(&opts, "lowres", stream_lowres, 0);
if (avctx->codec_type == AVMEDIA_TYPE_VIDEO || avctx->codec_type ==
AVMEDIA_TYPE_AUDIO)
av_dict_set(&opts, "refcounted_frames", "1", 0);
if (avcodec_open2(avctx, codec, &opts) < 0)
diff --git a/libavfilter/vf_bbox.c b/libavfilter/vf_bbox.c
index 6c6aab1..1e6feff 100644
--- a/libavfilter/vf_bbox.c
+++ b/libavfilter/vf_bbox.c
@@ -61,8 +61,7 @@ static int query_formats(AVFilterContext *ctx)
}
#define SET_META(key, value) \
-snprintf(buf, sizeof(buf), "%d", value); \
-av_dict_set(metadata, key, buf, 0);
+av_dict_set_int(metadata, key, value, 0);
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
@@ -70,7 +69,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
BBoxContext *bbox = ctx->priv;
FFBoundingBox box;
int has_bbox, w, h;
-char buf[32];
has_bbox =
ff_calculate_bounding_box(&box,
diff --git a/libavfilter/vf_cropdetect.c b/libavfilter/vf_cropdetect.c
index ed8e7a8..f85a0bb 100644
--- a/libavfilter/vf_cropdetect.c
+++ b/libavfilter/vf_cropdetect.c
@@ -113,8 +113,7 @@ static int config_input(AVFilterLink *inlink)
}
#define SET_META(key, value) \
-snprintf(buf, sizeof(buf), "%d", value); \
-av_dict_set(metadata, key, buf, 0)
+av_dict_set_int(metadata, key, value, 0)
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
@@ -123,7 +122,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
int bpp = s->max_pixsteps[0];
int w, h, x, y, shrink_by;
AVDictionary **metadata;
-char buf[32];
// ignore first 2 frames - they may be empty
if (++s->frame_nb > 0) {
diff --git a/libavf
[FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.
Unfortunately this was not explicitly documented and thus
might be very risky.
But basically all uses I saw in FFmpeg had a memleak in these
cases.
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 9 +++--
libavutil/dict.h | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index 9fdc6d6..f23b768 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -91,7 +91,7 @@ int av_dict_set(AVDictionary **pm, const char *key, const
char *value,
AVDictionaryEntry *tmp = av_realloc(m->elems,
(m->count + 1) *
sizeof(*m->elems));
if (!tmp)
-return AVERROR(ENOMEM);
+goto err_out;
m->elems = tmp;
}
if (value) {
@@ -105,7 +105,7 @@ int av_dict_set(AVDictionary **pm, const char *key, const
char *value,
int len = strlen(oldval) + strlen(value) + 1;
char *newval = av_mallocz(len);
if (!newval)
-return AVERROR(ENOMEM);
+goto err_out;
av_strlcat(newval, oldval, len);
av_freep(&oldval);
av_strlcat(newval, value, len);
@@ -120,6 +120,11 @@ int av_dict_set(AVDictionary **pm, const char *key, const
char *value,
}
return 0;
+
+err_out:
+if (flags & AV_DICT_DONT_STRDUP_KEY) av_free(key);
+if (flags & AV_DICT_DONT_STRDUP_VAL) av_free(value);
+return AVERROR(ENOMEM);
}
int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value,
diff --git a/libavutil/dict.h b/libavutil/dict.h
index 06f1621..5e319fe 100644
--- a/libavutil/dict.h
+++ b/libavutil/dict.h
@@ -115,6 +115,8 @@ int av_dict_count(const AVDictionary *m);
/**
* Set the given entry in *pm, overwriting an existing entry.
*
+ * Note: On error non-av_strduped arguments will be freed.
+ *
* @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
* a dictionary struct is allocated and put in *pm.
* @param key entry key to add to *pm (will be av_strduped depending on flags)
--
2.1.0.rc1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] dict.c: empty dictionaries should be a NULL pointer.
Ensure this is even the case if they are empty because
we failed adding the first entry.
Signed-off-by: Reimar Döffinger
---
libavutil/dict.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/dict.c b/libavutil/dict.c
index f23b768..bdb5690 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -122,6 +122,10 @@ int av_dict_set(AVDictionary **pm, const char *key, const
char *value,
return 0;
err_out:
+if (!m->count) {
+av_free(m->elems);
+av_freep(pm);
+}
if (flags & AV_DICT_DONT_STRDUP_KEY) av_free(key);
if (flags & AV_DICT_DONT_STRDUP_VAL) av_free(value);
return AVERROR(ENOMEM);
--
2.1.0.rc1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On Sun, Aug 10, 2014 at 11:05:13PM -0300, James Almer wrote: > On 10/08/14 8:49 PM, Michael Niedermayer wrote: > > From: Luca Barbato > > > > TODO:bump > > APIChanges entry as well added TODO [...] > > +int swr_config_by_frames(SwrContext *swr, AVFrame *out, AVFrame *in); > > Maybe swr_config_frame()? changed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavu: rename ff_opencl_set_parameter() to avpriv_opencl_set_parameter()
It was wrongly being exported and used by libavfilter.
Signed-off-by: James Almer
---
libavfilter/deshake_opencl.c | 4 ++--
libavfilter/unsharp_opencl.c | 6 +++---
libavutil/opencl_internal.c | 2 +-
libavutil/opencl_internal.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/deshake_opencl.c b/libavfilter/deshake_opencl.c
index c66103c..2821248 100644
--- a/libavfilter/deshake_opencl.c
+++ b/libavfilter/deshake_opencl.c
@@ -57,7 +57,7 @@ int ff_opencl_transform(AVFilterContext *ctx,
av_log(ctx, AV_LOG_ERROR, "Selected interpolate method is invalid\n");
return AVERROR(EINVAL);
}
-ret = ff_opencl_set_parameter(¶m_lu,
+ret = avpriv_opencl_set_parameter(¶m_lu,
FF_OPENCL_PARAM_INFO(deshake->opencl_ctx.cl_inbuf),
FF_OPENCL_PARAM_INFO(deshake->opencl_ctx.cl_outbuf),
FF_OPENCL_PARAM_INFO(packed_matrix_lu),
@@ -70,7 +70,7 @@ int ff_opencl_transform(AVFilterContext *ctx,
NULL);
if (ret < 0)
return ret;
-ret = ff_opencl_set_parameter(¶m_ch,
+ret = avpriv_opencl_set_parameter(¶m_ch,
FF_OPENCL_PARAM_INFO(deshake->opencl_ctx.cl_inbuf),
FF_OPENCL_PARAM_INFO(deshake->opencl_ctx.cl_outbuf),
FF_OPENCL_PARAM_INFO(packed_matrix_ch),
diff --git a/libavfilter/unsharp_opencl.c b/libavfilter/unsharp_opencl.c
index e619cef..5c6b5ef 100644
--- a/libavfilter/unsharp_opencl.c
+++ b/libavfilter/unsharp_opencl.c
@@ -181,7 +181,7 @@ int ff_opencl_apply_unsharp(AVFilterContext *ctx, AVFrame
*in, AVFrame *out)
kernel1.ctx = ctx;
kernel1.kernel = unsharp->opencl_ctx.kernel_luma;
-ret = ff_opencl_set_parameter(&kernel1,
+ret = avpriv_opencl_set_parameter(&kernel1,
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_inbuf),
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_outbuf),
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_luma_mask),
@@ -198,7 +198,7 @@ int ff_opencl_apply_unsharp(AVFilterContext *ctx, AVFrame
*in, AVFrame *out)
kernel2.ctx = ctx;
kernel2.kernel = unsharp->opencl_ctx.kernel_chroma;
-ret = ff_opencl_set_parameter(&kernel2,
+ret = avpriv_opencl_set_parameter(&kernel2,
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_inbuf),
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_outbuf),
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_chroma_mask),
@@ -230,7 +230,7 @@ int ff_opencl_apply_unsharp(AVFilterContext *ctx, AVFrame
*in, AVFrame *out)
kernel1.ctx = ctx;
kernel1.kernel = unsharp->opencl_ctx.kernel_default;
-ret = ff_opencl_set_parameter(&kernel1,
+ret = avpriv_opencl_set_parameter(&kernel1,
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_inbuf),
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_outbuf),
FF_OPENCL_PARAM_INFO(unsharp->opencl_ctx.cl_luma_mask),
diff --git a/libavutil/opencl_internal.c b/libavutil/opencl_internal.c
index 3d996ab..bdb4193 100644
--- a/libavutil/opencl_internal.c
+++ b/libavutil/opencl_internal.c
@@ -23,7 +23,7 @@
#include "opencl_internal.h"
#include "libavutil/log.h"
-int ff_opencl_set_parameter(FFOpenclParam *opencl_param, ...)
+int avpriv_opencl_set_parameter(FFOpenclParam *opencl_param, ...)
{
int ret = 0;
va_list arg_ptr;
diff --git a/libavutil/opencl_internal.h b/libavutil/opencl_internal.h
index 34b39a0..dacd930 100644
--- a/libavutil/opencl_internal.h
+++ b/libavutil/opencl_internal.h
@@ -30,4 +30,4 @@ typedef struct {
void *ctx;
} FFOpenclParam;
-int ff_opencl_set_parameter(FFOpenclParam *opencl_param, ...);
+int avpriv_opencl_set_parameter(FFOpenclParam *opencl_param, ...);
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On Mon, Aug 11, 2014 at 09:25:20AM +0100, Kieran Kunhya wrote: > On 11 August 2014 00:49, Michael Niedermayer wrote: > > From: Luca Barbato > > Clearly this is Luca's patch but rewritten by you for swr so you > should say "Based on patch from Luca for avresample" or similar. its copy and pasted from lucas work and adapted where needed. I would not call that rewritten. rewritten is if you start with an empty file. luca has certainly done the main work on this and i thus would like to give him the majority of the credit for the work but if he preferrs i certainly can also put my name in the author field and add a "Based on commit ... by Luca ..." CCing luca In absence of a reply i will follow kierans suggestion > IANAL but this is quite dubious from a copyright perspective. [...] -- 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] swresample: Add AVFrame based API
On Aug 10, 2014 4:49 PM, "Michael Niedermayer" wrote:
>
> From: Luca Barbato
>
> TODO:bump
>
> Signed-off-by: Michael Niedermayer
> ---
> libswresample/Makefile |1 +
> libswresample/swresample.h | 61 +++
> libswresample/swresample_frame.c | 158
++
> 3 files changed, 220 insertions(+)
> create mode 100644 libswresample/swresample_frame.c
>
> diff --git a/libswresample/Makefile b/libswresample/Makefile
> index 75c6535..120ee33 100644
> --- a/libswresample/Makefile
> +++ b/libswresample/Makefile
> @@ -13,6 +13,7 @@ OBJS = audioconvert.o\
> resample.o\
> resample_dsp.o\
> swresample.o \
> + swresample_frame.o\
>
> OBJS-$(CONFIG_LIBSOXR) += soxr_resample.o
> OBJS-$(CONFIG_SHARED) += log2_tab.o
> diff --git a/libswresample/swresample.h b/libswresample/swresample.h
> index 4b8b045..687891b 100644
> --- a/libswresample/swresample.h
> +++ b/libswresample/swresample.h
> @@ -121,6 +121,7 @@
> */
>
> #include
> +#include "libavutil/frame.h"
> #include "libavutil/samplefmt.h"
>
> #include "libswresample/version.h"
> @@ -467,6 +468,66 @@ const char *swresample_license(void);
>
> /**
> * @}
> + *
> + * @name AVFrame based API
> + * @{
> + */
> +
> +/**
> + * Convert the samples in the input AVFrame and write them to the output
AVFrame.
> + *
> + * Input and output AVFrames must have channel_layout, sample_rate and
format set.
> + *
> + * If the output AVFrame does not have the data pointers allocated the
nb_samples
> + * field will be set using av_frame_get_buffer()
> + * is called to allocate the frame.
> + *
> + * The output AVFrame can be NULL or have fewer allocated samples than
required.
> + * In this case, any remaining samples not written to the output will be
added
> + * to an internal FIFO buffer, to be returned at the next call to this
function
> + * or to swr_convert() or to swr_convert_frame().
at the next call to this function or to swr_convert().
> + *
> + * If converting sample rate, there may be data remaining in the internal
> + * resampling delay buffer. swr_get_delay() tells the number of
> + * remaining samples. To get this data as output, call this function or
> + * swr_convert() with NULL input.
> + *
> + * If the SwrContext configuration does not match the output and
> + * input AVFrame settings the conversion does not take place and
depending on
> + * which AVFrame is not matching AVERROR_OUTPUT_CHANGED,
AVERROR_INPUT_CHANGED
> + * or AVERROR_OUTPUT_CHANGED|AVERROR_INPUT_CHANGED is returned.
or the result of a bitwise-OR of them is returned.
> + *
> + * @see swr_delay()
> + * @see swr_convert()
> + * @see swr_get_delay()
> + *
> + * @param swr audio resample context
> + * @param output output AVFrame
> + * @param input input AVFrame
> + * @return0 on success, AVERROR on failure or nonmatching
> + *configuration.
> + */
> +int swr_convert_frame(SwrContext *swr,
> + AVFrame *output, AVFrame *input);
> +
> +/**
> + * Configure or reconfigure the SwrContext using the information
> + * provided by the AVFrames.
> + *
> + * The original resampling context is reset even on failure.
> + * The function calls swr_close() internally if the context is open.
swr_close does nothing. Is it appropriate to list it here? Also, I don't
think SwrContext has a concept of open or close.
> + *
> + * @see swr_close();
> + *
> + * @param swr audio resample context
> + * @param output output AVFrame
> + * @param input input AVFrame
> + * @return0 on success, AVERROR on failure.
> + */
> +int swr_config_by_frames(SwrContext *swr, AVFrame *out, AVFrame *in);
> +
> +/**
> + * @}
> * @}
> */
[...]
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On Mon, Aug 11, 2014 at 10:02:54AM +0200, Clément Bœsch wrote: > On Mon, Aug 11, 2014 at 01:49:19AM +0200, Michael Niedermayer wrote: > > From: Luca Barbato > > > > TODO:bump > > > > Signed-off-by: Michael Niedermayer > > --- > > libswresample/Makefile |1 + > > libswresample/swresample.h | 61 +++ > > libswresample/swresample_frame.c | 158 > > ++ > > 3 files changed, 220 insertions(+) > > create mode 100644 libswresample/swresample_frame.c > > > [...] > > +/** > > + * Convert the samples in the input AVFrame and write them to the output > > AVFrame. > > + * > > + * Input and output AVFrames must have channel_layout, sample_rate and > > format set. > > + * > > + * If the output AVFrame does not have the data pointers allocated the > > nb_samples > > + * field will be set using av_frame_get_buffer() > > + * is called to allocate the frame. > > + * > > + * The output AVFrame can be NULL or have fewer allocated samples than > > required. > > + * In this case, any remaining samples not written to the output will be > > added > > + * to an internal FIFO buffer, to be returned at the next call to this > > function > > + * or to swr_convert() or to swr_convert_frame(). > > + * > > + * If converting sample rate, there may be data remaining in the internal > > + * resampling delay buffer. swr_get_delay() tells the number of > > + * remaining samples. To get this data as output, call this function or > > + * swr_convert() with NULL input. > > + * > > + * If the SwrContext configuration does not match the output and > > + * input AVFrame settings the conversion does not take place and depending > > on > > + * which AVFrame is not matching AVERROR_OUTPUT_CHANGED, > > AVERROR_INPUT_CHANGED > > + * or AVERROR_OUTPUT_CHANGED|AVERROR_INPUT_CHANGED is returned. > > + * > > + * @see swr_delay() > > + * @see swr_convert() > > + * @see swr_get_delay() > > + * > > + * @param swr audio resample context > > + * @param output output AVFrame > > + * @param input input AVFrame > > + * @return0 on success, AVERROR on failure or nonmatching > > + *configuration. > > + */ > > +int swr_convert_frame(SwrContext *swr, > > + AVFrame *output, AVFrame *input); > > + > > Is it possible to have input AVFrame const or it needs to increment > references or something? yes works, changed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] dict.c: Free non-strduped av_dict_set arguments on error.
On Mon, 11 Aug 2014 21:17:18 +0200
Reimar Döffinger wrote:
> Unfortunately this was not explicitly documented and thus
> might be very risky.
> But basically all uses I saw in FFmpeg had a memleak in these
> cases.
It's the more convenient behavior, although on the other hand it feels
wrong to change the input data on error.
This makes me wonder, isn't AV_DICT_DONT_STRDUP_* too obscure and too
much of a microoptimization, that we have to risk retro-guessing these
subtle semantics?
(But the patch is probably OK, IMHO.)
>
> Signed-off-by: Reimar Döffinger
> ---
> libavutil/dict.c | 9 +++--
> libavutil/dict.h | 2 ++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 9fdc6d6..f23b768 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -91,7 +91,7 @@ int av_dict_set(AVDictionary **pm, const char *key, const
> char *value,
> AVDictionaryEntry *tmp = av_realloc(m->elems,
> (m->count + 1) *
> sizeof(*m->elems));
> if (!tmp)
> -return AVERROR(ENOMEM);
> +goto err_out;
> m->elems = tmp;
> }
> if (value) {
> @@ -105,7 +105,7 @@ int av_dict_set(AVDictionary **pm, const char *key, const
> char *value,
> int len = strlen(oldval) + strlen(value) + 1;
> char *newval = av_mallocz(len);
> if (!newval)
> -return AVERROR(ENOMEM);
> +goto err_out;
> av_strlcat(newval, oldval, len);
> av_freep(&oldval);
> av_strlcat(newval, value, len);
> @@ -120,6 +120,11 @@ int av_dict_set(AVDictionary **pm, const char *key,
> const char *value,
> }
>
> return 0;
> +
> +err_out:
> +if (flags & AV_DICT_DONT_STRDUP_KEY) av_free(key);
> +if (flags & AV_DICT_DONT_STRDUP_VAL) av_free(value);
> +return AVERROR(ENOMEM);
> }
>
> int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value,
> diff --git a/libavutil/dict.h b/libavutil/dict.h
> index 06f1621..5e319fe 100644
> --- a/libavutil/dict.h
> +++ b/libavutil/dict.h
> @@ -115,6 +115,8 @@ int av_dict_count(const AVDictionary *m);
> /**
> * Set the given entry in *pm, overwriting an existing entry.
> *
> + * Note: On error non-av_strduped arguments will be freed.
> + *
That doesn't really explain anything. Suggestion: mention
AV_DICT_DONT_STRDUP_* explicitly, and mention that the corresponding
argument will always be freed, even on error.
> * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
> * a dictionary struct is allocated and put in *pm.
> * @param key entry key to add to *pm (will be av_strduped depending on
> flags)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On Mon, Aug 11, 2014 at 12:53:30PM -0700, Timothy Gu wrote: > On Aug 10, 2014 4:49 PM, "Michael Niedermayer" wrote: [...] > > + * to an internal FIFO buffer, to be returned at the next call to this > function > > + * or to swr_convert() or to swr_convert_frame(). > > at the next call to this function or to swr_convert(). > > > + * > > + * If converting sample rate, there may be data remaining in the internal > > + * resampling delay buffer. swr_get_delay() tells the number of > > + * remaining samples. To get this data as output, call this function or > > + * swr_convert() with NULL input. > > + * > > + * If the SwrContext configuration does not match the output and > > + * input AVFrame settings the conversion does not take place and > depending on > > + * which AVFrame is not matching AVERROR_OUTPUT_CHANGED, > AVERROR_INPUT_CHANGED > > > + * or AVERROR_OUTPUT_CHANGED|AVERROR_INPUT_CHANGED is returned. > > or the result of a bitwise-OR of them is returned. both changed > > > + * > > + * @see swr_delay() > > + * @see swr_convert() > > + * @see swr_get_delay() > > + * > > + * @param swr audio resample context > > + * @param output output AVFrame > > + * @param input input AVFrame > > + * @return0 on success, AVERROR on failure or nonmatching > > + *configuration. > > + */ > > +int swr_convert_frame(SwrContext *swr, > > + AVFrame *output, AVFrame *input); > > + > > +/** > > + * Configure or reconfigure the SwrContext using the information > > + * provided by the AVFrames. > > + * > > > + * The original resampling context is reset even on failure. > > + * The function calls swr_close() internally if the context is open. > > swr_close does nothing. Is it appropriate to list it here? Also, I don't > think SwrContext has a concept of open or close. it has a concept of initialized vs not initialized and close returns it to the non initilaized state [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Should add AVProbeData change to API changes + release notes
On Mon, Aug 11, 2014 at 08:05:38PM +0200, Reimar Döffinger wrote: > Hello, > (sorry for being too lazy to send a patch) > With the major version bump AVProbeData was extended by a new field. > This so far has broken 3 places within FFmpeg and one within MPlayer, > where AVProbeData was only initialized field-by-field. > This will cause "random" crashes. > I'm at this point fairly certain a lot of other software will have the > same issue. > I suggest we make add a big note with the release that everyone should > check their software for uses of AVProbeData that might result in parts > of that struct not being initialized. agree [...] -- 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] lavu: rename ff_opencl_set_parameter() to avpriv_opencl_set_parameter()
On Mon, Aug 11, 2014 at 04:35:39PM -0300, James Almer wrote: > It was wrongly being exported and used by libavfilter. > > Signed-off-by: James Almer > --- > libavfilter/deshake_opencl.c | 4 ++-- > libavfilter/unsharp_opencl.c | 6 +++--- > libavutil/opencl_internal.c | 2 +- > libavutil/opencl_internal.h | 2 +- > 4 files changed, 7 insertions(+), 7 deletions(-) note, the header says: * This interface is considered still experimental and its API and ABI may * change without prior notice. not sure changing it to avpriv before its stable API/ABI is a good idea also its in opencl_internal.h maybe we should just disallow this with --enable-shared [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 11 Aug 2014 20:40:28 +0200
Reimar Döffinger wrote:
> Hello,
>
> Apologies for not being able to resist answering even if it is getting
> off-topic.
>
> On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote:
> > On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote:
> > >
> > > High quality libraries must iterate on their API. Especially for a library
> > > trying to solve such a complex problem as audio and video encoding and
> > > decoding for every codec and format. It is unreasonable to expect no
> > > incompatible changes. Also both ffmpeg and libav codebases have a lot of
> > > legacy cruft. Libav is making a more concentrated effort at improving
> > > this,
> > > and the evolving API is a side-effect of that.
> >
> > I beg to differ. My definition of a "high quality library" is one
> > where careful design is taken into account when designing the
> > ABI/API's in the first place, and which if absolutely necessary, uses
> > ELF symbol versioning to maintain ABI compatibility.
> >
> > There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
> > where we've been able to maintain full ABI compatibility even while
> > adding new features --- including in the case of libext2fs, migrating
> > from 32-bit to 64-bit block numbers. And if you're careful in your
> > design and implementation, the amount of cruft required can be kept to
> > a very low minimum.
>
> While you certainly have a point that we have a lot to learn and improve,
> your comparison is not entirely fair, for reasons like
>
> a) glibc, libext2fs are much older projects, we still have to
> pay for old sins, from times where everyone was happy when
> their video played at all on Linux and nobody complained about
> ABI compatibility. Not to mention few of us having much experience
> in software development.
Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still is.)
So glibc might achieve some ABI backwards-compatibility, but the truth
is that they have many many issues, and the symbol versioning merely
paints them over. They can only dream of ABI compatibility as solid
as kernel32.dll's.
> b) A good number of our users are on Windows, which makes symbol
> versioning a very undesirable solution. Sometimes that means alternative
> solutions which are messier or more likely to break compatibility by
> accident
To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.
> c) For libext2fs your users won't claim a file system is ext2, when it
> is actually btrfs and still expect your ext2 library to work with it!
> That is very much the standard in multimedia ("everything is .avi",
> "I don't care what format it is, I just want it to play", ...).
> Nor do you have competing ext2 implementations adding completely
> mis-designed extensions to it, with everyone expecting you to support it, that
> definitely makes API design a _lot_ more challenging.
Even more importantly, libext2fs has a very specific use case. Not only
is there only ext2fs "vendor", it's also a pretty simple problem. IF
you really want to make a fair comparison, you'd have to compare FFmpeg
with a filesystem abstraction library that allows low-level accesses.
I think the largest issue with FFmpeg is actually that it's so
low-level. Users usually have to connect the individual libraries
themselves, and that is very error prone. Hell, even the official
FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem
to be broken to hell.
I think there should be a higher-level FFmpeg library that takes care
of these things.
> d) At least in the case of glibc that backwards-compatibility is not at
> all free to its current users. _IO_stdin_used is a prime example of that,
> anyone playing with methods to reduce binary size/strip symbols will stumble
> over that and curse very loudly at some point.
> I certainly would have preferred it to not be ABI compatible in that
> case!
I have the feeling glibc would have it easier if they wouldn't expose so
many internals. If you compile a program written against standard C and
POSIX, it will reference the strangest glibc symbols.
> Regards,
> Reimar
> ___
> 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] lavu: rename ff_opencl_set_parameter() to avpriv_opencl_set_parameter()
On 11/08/14 5:31 PM, Michael Niedermayer wrote: > On Mon, Aug 11, 2014 at 04:35:39PM -0300, James Almer wrote: >> It was wrongly being exported and used by libavfilter. >> >> Signed-off-by: James Almer >> --- >> libavfilter/deshake_opencl.c | 4 ++-- >> libavfilter/unsharp_opencl.c | 6 +++--- >> libavutil/opencl_internal.c | 2 +- >> libavutil/opencl_internal.h | 2 +- >> 4 files changed, 7 insertions(+), 7 deletions(-) > > note, the header says: > * This interface is considered still experimental and its API and ABI may > * change without prior notice. > > not sure changing it to avpriv before its stable API/ABI is a good > idea > > also its in opencl_internal.h > > maybe we should just disallow this with --enable-shared The public header says that, not the internal one. This function should have never been called ff_ if it was meant to be used by libavfilter since its inception. And at this point, any changes to it in the future would mean an ABI break regardless of name anyway. But we can change its name to a proper one right now without breaking ABI since we just bumped major. And as far as linux distros go, disabling OpenCL with shared builds would be the same as not offering OpenCL at all. Probably for the best since it's supposedly experimental anyway. In any case, removing the ff_* part from libavutil.v is the entire point behind this. Worst case we can make it only export this one function instead of the entire namespace. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/4] prores: fix various issues
There are mostly issues (in order), potentially causing crashes: - no check on the buffer left - no reallocation when the buffer will overflow - incorrect buffer size when encoding alpha Christophe Gisquet (4): proresenc_kostya: remove unneeded parameters proresenc_kostya: report buffer overflow proresenc_kostya: realloc if buffer too small proresenc_kostya: properly account for alpha libavcodec/proresenc_kostya.c | 53 --- 1 file changed, 45 insertions(+), 8 deletions(-) -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] proresenc_kostya: report buffer overflow
If the allocated size, despite best efforts, is too small, exit
with the appropriate error.
---
libavcodec/proresenc_kostya.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 24cb333..a70ae3c 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -570,6 +570,11 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
quant);
}
total_size += sizes[i];
+if (put_bits_left(pb) < 0) {
+av_log(avctx, AV_LOG_ERROR, "Serious underevaluation of"
+ "required buffer size");
+return AVERROR_BUFFER_TOO_SMALL;
+}
}
return total_size;
}
@@ -940,9 +945,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
avctx->coded_frame->pict_type = AV_PICTURE_TYPE_I;
avctx->coded_frame->key_frame = 1;
-pkt_size = ctx->frame_size_upper_bound + FF_MIN_BUFFER_SIZE;
+pkt_size = ctx->frame_size_upper_bound;
-if ((ret = ff_alloc_packet2(avctx, pkt, pkt_size)) < 0)
+if ((ret = ff_alloc_packet2(avctx, pkt, pkt_size + FF_MIN_BUFFER_SIZE)) <
0)
return ret;
orig_buf = pkt->data;
@@ -1019,7 +1024,9 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
slice_hdr = buf;
buf += slice_hdr_size - 1;
init_put_bits(&pb, buf, (pkt_size - (buf - orig_buf)) * 8);
-encode_slice(avctx, pic, &pb, sizes, x, y, q, mbs_per_slice);
+ret = encode_slice(avctx, pic, &pb, sizes, x, y, q,
mbs_per_slice);
+if (ret < 0)
+return ret;
bytestream_put_byte(&slice_hdr, q);
slice_size = slice_hdr_size + sizes[ctx->num_planes - 1];
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
The buffer allocation may be incorrect (e.g. with an alpha plane),
and currently causes the buffer to be set to NULL by init_put_bits,
later on causing crashing.
So, detect that situation, and if detected, reallocate the buffer
and ask a sample if it happens.
Fixes ticket #2760
---
libavcodec/proresenc_kostya.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index a70ae3c..2cd33ce 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1023,6 +1023,30 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
bytestream_put_byte(&buf, slice_hdr_size << 3);
slice_hdr = buf;
buf += slice_hdr_size - 1;
+if (pkt_size <= buf - orig_buf) {
+static int warn = 0;
+uint8_t *start = pkt->data;
+int ret, delta = buf - orig_buf; // double the size
+
+if (!warn) {
+avpriv_request_sample(avctx,
+ "Packet too small (%i/%i)",
+ pkt_size, delta);
+}
+ctx->frame_size_upper_bound += delta;
+ret = av_grow_packet(pkt, delta);
+if (ret < 0)
+return AVERROR(ENOMEM);
+
+pkt_size += delta;
+// restore pointers
+orig_buf = pkt->data + (orig_buf - start);
+buf = pkt->data + (buf - start);
+picture_size_pos = pkt->data + (picture_size_pos - start);
+slice_sizes = pkt->data + (slice_sizes - start);
+slice_hdr = pkt->data + (slice_hdr - start);
+tmp = pkt->data + (tmp - start);
+}
init_put_bits(&pb, buf, (pkt_size - (buf - orig_buf)) * 8);
ret = encode_slice(avctx, pic, &pb, sizes, x, y, q,
mbs_per_slice);
if (ret < 0)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha
The packet buffer allocation considered as dct-coded, while it is
actually run-coded and thus requires a larger buffer.
---
libavcodec/proresenc_kostya.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 2cd33ce..443ea76 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1232,16 +1232,23 @@ static av_cold int encode_init(AVCodecContext *avctx)
ctx->bits_per_mb = ls * 8;
if (ctx->chroma_factor == CFACTOR_Y444)
ctx->bits_per_mb += ls * 4;
-if (ctx->num_planes == 4)
-ctx->bits_per_mb += ls * 4;
}
ctx->frame_size_upper_bound = ctx->pictures_per_frame *
ctx->slices_per_picture *
- (2 + 2 * ctx->num_planes +
+ (2 + 2 * FFMIN(3, ctx->num_planes) +
(mps * ctx->bits_per_mb) / 8)
+ 200;
+if (ctx->alpha_bits) {
+ // alpha plane is run-coded and might run over bit budget
+ ctx->frame_size_upper_bound += (ctx->pictures_per_frame *
+ ctx->slices_per_picture *
+ ctx->mbs_per_slice *
+ 256 * (1 + ctx->alpha_bits+1)
+ + 7) >> 3;
+}
+
avctx->codec_tag = ctx->profile_info->tag;
av_log(avctx, AV_LOG_DEBUG,
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] proresenc_kostya: remove unneeded parameters
---
libavcodec/proresenc_kostya.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 93bcde7..24cb333 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -471,7 +471,6 @@ static void put_alpha_run(PutBitContext *pb, int run)
// todo alpha quantisation for high quants
static int encode_alpha_plane(ProresContext *ctx, PutBitContext *pb,
- const uint16_t *src, int linesize,
int mbs_per_slice, uint16_t *blocks,
int quant)
{
@@ -566,7 +565,7 @@ static int encode_slice(AVCodecContext *avctx, const
AVFrame *pic,
get_alpha_data(ctx, src, linesize, xp, yp,
pwidth, avctx->height / ctx->pictures_per_frame,
ctx->blocks[0], mbs_per_slice, ctx->alpha_bits);
-sizes[i] = encode_alpha_plane(ctx, pb, src, linesize,
+sizes[i] = encode_alpha_plane(ctx, pb,
mbs_per_slice, ctx->blocks[0],
quant);
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] dict.c: Add av_dict_set_int helper function.
On Mon, Aug 11, 2014 at 09:17:16PM +0200, Reimar Döffinger wrote: > This allows getting rid of the many, slightly differing, implementations > of basically the same thing. > > Signed-off-by: Reimar Döffinger > --- > doc/APIchanges | 3 +++ > libavutil/dict.c| 8 > libavutil/dict.h| 8 > libavutil/version.h | 2 +- > 4 files changed, 20 insertions(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample: Add AVFrame based API
On 2014-08-11 21:42 +0200, Michael Niedermayer wrote: > On Mon, Aug 11, 2014 at 09:25:20AM +0100, Kieran Kunhya wrote: > > On 11 August 2014 00:49, Michael Niedermayer wrote: > > > From: Luca Barbato > > > > Clearly this is Luca's patch but rewritten by you for swr so you > > should say "Based on patch from Luca for avresample" or similar. > > its copy and pasted from lucas work and adapted where needed. > I would not call that rewritten. rewritten is if you start with an > empty file. > luca has certainly done the main work on this and i thus would like > to give him the majority of the credit for the work > but if he preferrs i certainly can also put my name in the author > field and add a "Based on commit ... by Luca ..." > > CCing luca > In absence of a reply i will follow kierans suggestion > > > > IANAL but this is quite dubious from a copyright perspective. Whoever ends up in the author field the commit message body should mention that you adapted Luca's work for libswresample. Just for clarity. Alexander pgpHnTg39aTqf.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote: > > To be fair, FFmpeg does its own "manual" symbol versioning by appending > increasing numbers to function names. But the real problem are not > these functions, but public structs. Imagine a new API user fighting to > guess which fields in AVCodecContext must be set, or which must not be > set. Seasoned FFmpeg developers probably don't know the horror. There are some best practices in API design; one of them is to minimize public structs as much as possible. Instead, have blind pointers which are handed back by an "initialize object" function, and then have setter/getter functions that allow you to fetch various parameters or flags which modify how the object behaves. This allows you to add or deprecate new flags, configuration parameters, in a relatively sane way. I have this dream/fantasy where all of the energy over developing and maintaining two forks was replaced by a spirit of cooperations and the developers working together to design a new API from scratch that could be guaranteed to be stable, and then applications migrated over to use this stable, well-designed, future-proofed API. Call me a naive, over-optimistic dreamer, but :-) (And, the yes, the new API probably should be a bit higher level.) "Can we all just get along?" -- https://www.youtube.com/watch?v=1sONfxPCTU0 - Ted ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] proresenc_kostya: remove unneeded parameters
On Mon, Aug 11, 2014 at 10:06:07PM +, Christophe Gisquet wrote: > --- > libavcodec/proresenc_kostya.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) applied thanks [...] -- 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] rectification filter
Am 11.08.2014 um 17:39 schrieb Clément Bœsch :
> On Mon, Aug 11, 2014 at 05:33:10PM +0200, Daniel Oberhoff wrote:
>>
>> Am 11.08.2014 um 00:20 schrieb Michael Niedermayer :
>>
>>> On Sun, Aug 10, 2014 at 08:36:37PM +0200, Daniel Oberhoff wrote:
Von meinem iPhone gesendet
> Am 10.08.2014 um 17:50 schrieb Michael Niedermayer :
>
>> On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote:
>> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit :
>>> It is not mandatory(but it would be nice) to add other methods to have
>>> this filter included into libavfilter.
>>
>> Is it really a good idea? We would end up with various interpolation /
>> anti-aliasing algorithms implemented in each filter that needs it, none
>> of
>> them with the same set of architecture optimizations and each with its
>> own
>> set of bugs and misfeatures.
>
>> Until someone comes up with a really satisfactory solution, I believe the
>> simple solution of suggesting users to upscale before the filter and
>> downscale after, using the optimized lswr scalers, is better.
>
> thats not practical
> a 1024x768 image would need to be upscaled to 262144x196608 to get
> 8bit precission from a nearest neighbor resampler as basis
>
> also see vf_perspective.c which supports bilinear and bicubic
> interpolation, these surely could be shared and exist already.
>
> of course we could push it with just nearest neighbor and work on that
> later, but i dont think only nearest neighbor and leaving it at that
> is a reasonable choice, its too poor quality wise
I would like to push now, and try to generate a refactoring patch possibly
within the week.
>>>
>>> sure, feel free to push and send a pull request, or if you prefer
>>> i can allso apply the patch if you post the latest verision
>>
>> I am not sure about pull requests (would have to read up on how to do that
>> properly) so rigjht now I would prefer it by patch:
>>
>>
>>
>> Is that ok?
>>
>
> Yes, please just re-submit the patch here.
Darn, forgot that attachements are scrubbed from the list (I had the patch
attached). Will paste at the end.
>
> Sorry about the suggestion of adding FATE tests, I forgot the fact that
> the filter was actually using floats.
No probs :)
>From aa27195163da74c6e8f6a3b258f971f589d19aca Mon Sep 17 00:00:00 2001
From: Daniel Oberhoff
Date: Mon, 28 Jul 2014 23:58:12 +0200
Subject: [PATCH] avfilter: ported lenscorrection filter from frei0r
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/filters.texi| 46 ++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_lenscorrection.c | 199
6 files changed, 249 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_lenscorrection.c
diff --git a/Changelog b/Changelog
index 25dd210..79393ce 100644
--- a/Changelog
+++ b/Changelog
@@ -3,7 +3,7 @@ releases are sorted from youngest to oldest.
version :
- Icecast protocol
-
+- ported lenscorrection filter from frei0r filter
version 2.3:
- AC3 fixed-point decoding
diff --git a/MAINTAINERS b/MAINTAINERS
index c383d3f..6948e22 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -354,6 +354,7 @@ Filters:
vf_histogram.cPaul B Mahol
vf_hqx.c Clément Bœsch
vf_il.c Paul B Mahol
+ vf_lenscorrection.c Daniel Oberhoff
vf_mergeplanes.c Paul B Mahol
vf_psnr.c Paul B Mahol
vf_scale.cMichael Niedermayer
diff --git a/doc/filters.texi b/doc/filters.texi
index e0759fc..54b4451 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5546,6 +5546,51 @@ kerndeint=map=1
@end example
@end itemize
+@section lenscorrection
+
+Correct radial lens distortion
+
+This filter can be used to correct for radial distortion as can result from
the use
+of wide angle lenses, and thereby re-rectify the image. To find the right
parameters
+one can use tools available for example as part of opencv or simply
trial-and-error.
+To use opencv use the calibration sample (under samples/cpp) from the opencv
sources
+and extract the k1 and k2 coefficients from the resulting matrix.
+
+Note that effectively the same filter is available in the open-source tools
Krita and
+Digikam from the KDE project.
+
+In contrast to the @ref{vignette} filter, which can also be used to compensate
lens errors,
+this filter corrects the distortion of the image, whereas @ref{vignette}
corrects the
+brightness distribution, so you may want to use both filters together in
certain
+cases, though you will have to take care of ordering, i.e. whether vignetting
should
+be applied before or after lens correc
Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list
On 11/08/14 at 17:39, Steven Liu wrote: > Hi Guys, Hello, > > The FFmpeg hls module can make m3u8 and ts, but it dosen't delete the > old ts segment file. > If always run this module, the disk will full, so this patch can fix > the problem. > When update the segment list m3u8 file, it will delete the ts segment > out range from the list file. [..] I'm pretty sure this is why the hls muxer has the `-hls_wrap wrap' option. -- Simon Thelen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha
On Mon, Aug 11, 2014 at 10:06:10PM +, Christophe Gisquet wrote: > The packet buffer allocation considered as dct-coded, while it is > actually run-coded and thus requires a larger buffer. > --- > libavcodec/proresenc_kostya.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c > index 2cd33ce..443ea76 100644 > --- a/libavcodec/proresenc_kostya.c > +++ b/libavcodec/proresenc_kostya.c > @@ -1232,16 +1232,23 @@ static av_cold int encode_init(AVCodecContext *avctx) > ctx->bits_per_mb = ls * 8; > if (ctx->chroma_factor == CFACTOR_Y444) > ctx->bits_per_mb += ls * 4; > -if (ctx->num_planes == 4) > -ctx->bits_per_mb += ls * 4; > } > > ctx->frame_size_upper_bound = ctx->pictures_per_frame * >ctx->slices_per_picture * > - (2 + 2 * ctx->num_planes + > + (2 + 2 * FFMIN(3, ctx->num_planes) + slice_hdr_size is 2 + 2 * (ctx->num_planes - 1); is this difference intended ? also ctx->num_planes is currently either 3 or 4 which would make the FFMIN a constant [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] proresenc_kostya: report buffer overflow
On Mon, Aug 11, 2014 at 10:06:08PM +, Christophe Gisquet wrote: > If the allocated size, despite best efforts, is too small, exit > with the appropriate error. > --- > libavcodec/proresenc_kostya.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) This is kind of an internal error, we should ideally allocate the buffer large enough, or reallocate as needed, but the case tested for here should never happen if everything else works correctly but its alot safer to do this check than to not do it so applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
On 8/11/14, Andreas Cadhalpun wrote: > Hi Ivan, > > On 11.08.2014 01:23, Ivan Kalvachev wrote: >> The patch is inspired by something I read in the Debian discussion. >> Libav and FFmpeg could be installed side by side without conflicts in >> the libraries, thanks to using additional suffixes. > > Thanks for your interest in the matter. > >> However development/include files are still conflicting, so I thought >> of a simple configure hack to give more control to FFmpeg. >> >> With this patch you can do `./configure --extra-incdir="/ffmpeg" >> --prefix="/usr"` , >> as result the header files would be installed in >> "/usr/include/ffmpeg" >> e.g. >> "/usr/include/ffmpeg/libavcodec/avcodec.h" >> ... > > Assuming it would be possible to install development packages for both > at the same time, which one should be used, when building a program? It would be decided by the gcc -I inclusion option. It modifies the search paths for header files, so that it checks these paths before the system/default ones (When using `#include "libavcodec/avcodec.h" `) Libav headers are probably going to remain in the default /usr/include/ . Usually this should not be a problem, unless a program uses `#include ` that should be used for system headers (aka checks the system/default paths first). There might still be problems if there are explicit -I/usr/include inserted by other libraries that mix the inclusion order. To avoid hard to debug compiling problems, that the -dev packages may still be marked as conflicting, even though no files are overwritten. This final conflict however cannot be resolved on FFmpeg side. >> The change is reflected in the pkgconfig files too. Since applications >> that link to libraries with addition suffixes should be using >> pkgconfig, they would be using the correct header includes >> automatically. > > If that's to be determined via pkg-config files, then the obvious > problem is that both install these files in the same location, and if > one doesn't, programs can't find the library. The problem is not that they are installed in the same location, but that they have same names. However I just checked and when you define library suffix (e.g. --build-suffix="_ffmpeg"), it also adds the same suffix to the .pc files. So you have /usr/lib/share/pkgconfig/libavcodec_ffmpeg.pc /usr/lib/libavcodec_ffmpeg.so In short, assuming if Libav doesn't change their library names and pkgconfig files, the programs that are looking for 'libavcodec.pc' would get the Libav one, the programs that are looking for 'libavcodec_ffmpeg.pc' would get FFmpeg. I believe that you should already be using --build-suffix, so that should already be in the package. Is there something else I'm missing? >> I did just a rudimentary test and I couldn't spot anything wrong. >> Please test it before inclusion. > > The patch seems to be alright, but it doesn't make it possible to make > the development packages of FFmpeg and Libav co-installable. Unfortunately not. But without the patch the problem is entirely in how FFmpeg installs its header. With it, it is entirely Libav problem for using system/common directory. Then, if Debian wants to resolve the conflict, Libav header files could be moved in their own directory. The patch should be trivial to port. >> As for the future, it might be good idea next major release (e.g. 3.0) >> to have the $prefix/include/ffmpeg as default include path (for >> non-comapt build). > > So this would also not help. At the moment FFmpeg is trying to mimic 100% Libav API/ABI, and to be perfect drop-in replacement. This means using the same library names, locations and header files. This is what I call compat build. It is 100% compatible with Libav from application/program point of view. When using --build-suffix, you obviously want to differentiate from Libav, so I call that non-compat build. Sorry if this is caused confusion. I hope that the way Debian packages FFmpeg would actually turn out to be the new default. Best Regards Ivan Kalvachev iive ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
On Mon, Aug 11, 2014 at 10:06:09PM +, Christophe Gisquet wrote:
> The buffer allocation may be incorrect (e.g. with an alpha plane),
> and currently causes the buffer to be set to NULL by init_put_bits,
> later on causing crashing.
>
> So, detect that situation, and if detected, reallocate the buffer
> and ask a sample if it happens.
>
> Fixes ticket #2760
> ---
> libavcodec/proresenc_kostya.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
> index a70ae3c..2cd33ce 100644
> --- a/libavcodec/proresenc_kostya.c
> +++ b/libavcodec/proresenc_kostya.c
> @@ -1023,6 +1023,30 @@ static int encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> bytestream_put_byte(&buf, slice_hdr_size << 3);
> slice_hdr = buf;
> buf += slice_hdr_size - 1;
> +if (pkt_size <= buf - orig_buf) {
this isnt sufficient, there could be 1 byte space left, then the
reallocate wouldnt run and encode_slice() would run into the extra
padding and fail
I think either enough space should be allocated to begin with (like
your patch 4) then the reallocation shouldnt be needed
or the buffer could be allocated to an average size and reallocated
when the encoder gets close to its end
in which case reallocation also would not need a warning
as it would be a normal operation
that is unless iam missing something
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, wm4: > Build something on a newer glibc system, and try to run the binary on > an older system. It most likely won't work - even if it could in > theory. (At least it was this way some years ago. Probably still is.) What would be the point of introducing new or updated interfaces if you then couldn't use them? ABI backwards compatibility is not a goal I would want to spend any time on. Forward compatibility, on the other hand … > To be fair, FFmpeg does its own "manual" symbol versioning by appending > increasing numbers to function names. But the real problem are not > these functions, but public structs. Imagine a new API user fighting to > guess which fields in AVCodecContext must be set, or which must not be > set. Seasoned FFmpeg developers probably don't know the horror. > That's reasonably easy – you add a function to allocate the structure for you. That function sets a version field and/or initializes everything to a sane default. Also, you never shrink the structure, or move fields. Obviously, you also tell people to never ever embed the thing directly in something else, assuming that you can't keep it opaque entirely. Of course, it's only easy if you design your API that way from the beginning … > I think the largest issue with FFmpeg is actually that it's so > low-level. Users usually have to connect the individual libraries > themselves, and that is very error prone. Hell, even the official > FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem > to be broken to hell. > > I think there should be a higher-level FFmpeg library that takes care > of these things. > gstreamer-ffmpeg? -- -- Matthias Urlichs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] rectification filter
On Tue, Aug 12, 2014 at 12:52:45AM +0200, Daniel Oberhoff wrote: > > Am 11.08.2014 um 17:39 schrieb Clément Bœsch : > > > On Mon, Aug 11, 2014 at 05:33:10PM +0200, Daniel Oberhoff wrote: > >> > >> Am 11.08.2014 um 00:20 schrieb Michael Niedermayer : > >> > >>> On Sun, Aug 10, 2014 at 08:36:37PM +0200, Daniel Oberhoff wrote: > > > Von meinem iPhone gesendet > > > Am 10.08.2014 um 17:50 schrieb Michael Niedermayer : > > > >> On Sun, Aug 10, 2014 at 03:36:04PM +0200, Nicolas George wrote: > >> Le tridi 23 thermidor, an CCXXII, Paul B Mahol a écrit : > >>> It is not mandatory(but it would be nice) to add other methods to have > >>> this filter included into libavfilter. > >> > >> Is it really a good idea? We would end up with various interpolation / > >> anti-aliasing algorithms implemented in each filter that needs it, > >> none of > >> them with the same set of architecture optimizations and each with its > >> own > >> set of bugs and misfeatures. > > > >> Until someone comes up with a really satisfactory solution, I believe > >> the > >> simple solution of suggesting users to upscale before the filter and > >> downscale after, using the optimized lswr scalers, is better. > > > > thats not practical > > a 1024x768 image would need to be upscaled to 262144x196608 to get > > 8bit precission from a nearest neighbor resampler as basis > > > > also see vf_perspective.c which supports bilinear and bicubic > > interpolation, these surely could be shared and exist already. > > > > of course we could push it with just nearest neighbor and work on that > > later, but i dont think only nearest neighbor and leaving it at that > > is a reasonable choice, its too poor quality wise > > I would like to push now, and try to generate a refactoring patch > possibly within the week. > >>> > >>> sure, feel free to push and send a pull request, or if you prefer > >>> i can allso apply the patch if you post the latest verision > >> > >> I am not sure about pull requests (would have to read up on how to do that > >> properly) so rigjht now I would prefer it by patch: > >> > >> > >> > >> Is that ok? > >> > > > > Yes, please just re-submit the patch here. > > Darn, forgot that attachements are scrubbed from the list (I had the patch > attached). Will paste at the end. > > > > > Sorry about the suggestion of adding FATE tests, I forgot the fact that > > the filter was actually using floats. > > No probs :) > > From aa27195163da74c6e8f6a3b258f971f589d19aca Mon Sep 17 00:00:00 2001 > From: Daniel Oberhoff > Date: Mon, 28 Jul 2014 23:58:12 +0200 > Subject: [PATCH] avfilter: ported lenscorrection filter from frei0r patch applied if you would change it to use fixed point instead of floating point calculatios then a regression test would be possible Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu: rename ff_opencl_set_parameter() to avpriv_opencl_set_parameter()
On Mon, Aug 11, 2014 at 05:56:50PM -0300, James Almer wrote: > On 11/08/14 5:31 PM, Michael Niedermayer wrote: > > On Mon, Aug 11, 2014 at 04:35:39PM -0300, James Almer wrote: > >> It was wrongly being exported and used by libavfilter. > >> > >> Signed-off-by: James Almer > >> --- > >> libavfilter/deshake_opencl.c | 4 ++-- > >> libavfilter/unsharp_opencl.c | 6 +++--- > >> libavutil/opencl_internal.c | 2 +- > >> libavutil/opencl_internal.h | 2 +- > >> 4 files changed, 7 insertions(+), 7 deletions(-) > > > > note, the header says: > > * This interface is considered still experimental and its API and ABI may > > * change without prior notice. > > > > not sure changing it to avpriv before its stable API/ABI is a good > > idea > > > > also its in opencl_internal.h > > > > maybe we should just disallow this with --enable-shared > > The public header says that, not the internal one. This function should have > never > been called ff_ if it was meant to be used by libavfilter since its inception. > And at this point, any changes to it in the future would mean an ABI break > regardless > of name anyway. But we can change its name to a proper one right now without > breaking > ABI since we just bumped major. > And as far as linux distros go, disabling OpenCL with shared builds would be > the same > as not offering OpenCL at all. Probably for the best since it's supposedly > experimental > anyway. > > In any case, removing the ff_* part from libavutil.v is the entire point > behind this. > Worst case we can make it only export this one function instead of the entire > namespace. applied thanks [...] -- 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] delete the old segment file from hls list
2014-08-12 7:26 GMT+08:00 Simon Thelen : > On 11/08/14 at 17:39, Steven Liu wrote: > > Hi Guys, > Hello, > > > > The FFmpeg hls module can make m3u8 and ts, but it dosen't delete the > > old ts segment file. > > If always run this module, the disk will full, so this patch can fix > > the problem. > > When update the segment list m3u8 file, it will delete the ts segment > > out range from the list file. > [..] > I'm pretty sure this is why the hls muxer has the `-hls_wrap wrap' option. > Hello, > > When use the option -hls_wrap 7 > ./ffmpeg -i shaolinzuqiu.rm -vcodec libx264 -preset ultrafast -an -f hls > -hls_wrap 7 a.m3u8 > it dose not remove the nouse file: > [root@localhost ffmpeg]# ls *.ts;cat a.m3u8 > a0.ts a1.ts a2.ts a3.ts a4.ts a5.ts a6.ts > #EXTM3U > #EXT-X-VERSION:3 > #EXT-X-TARGETDURATION:11 > #EXT-X-MEDIA-SEQUENCE:20 > #EXTINF:10.427075, > a6.ts > #EXTINF:10.427075, > a0.ts > #EXTINF:10.427075, > a1.ts > #EXTINF:10.427075, > a2.ts > #EXTINF:10.427075, > a3.ts > > the list file just have a0.ts,a1.ts,a2.ts,a3.ts,a6.ts but no a4.ts,a5.ts, > and there have a4.ts,a5.ts on the disk. > perhaps this patch can fix this problem. > > Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs
Its API is marked as experimental, we should not export experimental API
from shared libs
Signed-off-by: Michael Niedermayer
---
configure |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 0ac6132..84d308e 100755
--- a/configure
+++ b/configure
@@ -4861,7 +4861,9 @@ enabled opencl&& { check_lib2 OpenCL/cl.h
clEnqueueNDRangeKernel -Wl
die "ERROR: opencl not found"; } &&
{ check_cpp_condition "OpenCL/cl.h"
"defined(CL_VERSION_1_2)" ||
check_cpp_condition "CL/cl.h"
"defined(CL_VERSION_1_2)" ||
- die "ERROR: opencl must be installed and
version must be 1.2 or compatible"; }
+ die "ERROR: opencl must be installed and
version must be 1.2 or compatible"; } &&
+ { enabled shared &&
+ die "ERROR OpenCL API is experimental and not
safe to be used with shared libs"; }
enabled opengl&& { check_lib GL/glx.h glXGetProcAddress "-lGL" ||
check_lib2 windows.h wglGetProcAddress
"-lopengl32 -lgdi32" ||
check_lib2 OpenGL/gl3.h glGetError
"-Wl,-framework,OpenGL" ||
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list
2014-08-12 7:26 GMT+08:00 Simon Thelen : > On 11/08/14 at 17:39, Steven Liu wrote: > > Hi Guys, > Hello, > > > > The FFmpeg hls module can make m3u8 and ts, but it dosen't delete the > > old ts segment file. > > If always run this module, the disk will full, so this patch can fix > > the problem. > > When update the segment list m3u8 file, it will delete the ts segment > > out range from the list file. > [..] > I'm pretty sure this is why the hls muxer has the `-hls_wrap wrap' option. > Hi Simon, hls_list_size and hls_wrap option two can fix the problem, but this patch can fix the problem of the default parameter, because the ts file on disk , one to one correspondence with the m3u8 file will better, isn't it? Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavu: stop exporting internal functions
On Mon, Aug 11, 2014 at 08:39:24PM +0200, Andreas Cadhalpun wrote:
> On 10.08.2014 02:04, James Almer wrote:
> >Signed-off-by: James Almer
> >---
> > libavutil/libavutil.v | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libavutil/libavutil.v b/libavutil/libavutil.v
> >index eb16ae1..e9f04cb 100644
> >--- a/libavutil/libavutil.v
> >+++ b/libavutil/libavutil.v
> >@@ -1,4 +1,4 @@
> > LIBAVUTIL_$MAJOR {
> >-global: av*; ff_*;
> >+global: av*;
> > local: *;
> > };
> >
>
> I'd also like to see this happen, but this change requires to first
> convert ff_opencl_set_parameter into avpriv*, because it is used by
> libavfilter.
ok, applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fix: 'make' with mingw32
>From 48e4da7d6476ac2a62cc462478b8ccf4d0c45361 Mon Sep 17 00:00:00 2001 From: Youka Date: Tue, 12 Aug 2014 04:32:02 +0200 Subject: [PATCH] fix: 'make' with mingw32 Older mingw32 compilers (not mingw-64, but tdm [default by IDE C::B]) don't auto-include pthread headers, so struct timespec & nanosleep are missing for compilation of libavutil/time.c. --- libavutil/time.c | 4 1 file changed, 4 insertions(+) diff --git a/libavutil/time.c b/libavutil/time.c index ce4552e..a286fca 100644 --- a/libavutil/time.c +++ b/libavutil/time.c @@ -31,6 +31,10 @@ #endif #if HAVE_WINDOWS_H #include +#if HAVE_NANOSLEEP +#include +#include +#endif #endif #include "time.h" -- 1.8.4.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
Hi,
2014-08-12 2:34 GMT+02:00 Michael Niedermayer :
>> +if (pkt_size <= buf - orig_buf) {
>
> this isnt sufficient, there could be 1 byte space left, then the
> reallocate wouldnt run and encode_slice() would run into the extra
> padding and fail
Yeah, you're right. I have no idea how big a slice can be, as that
seems the extra size check here. How about FF_MIN_BUFFER_SIZE ?
Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ?
> I think either enough space should be allocated to begin with (like
> your patch 4) then the reallocation shouldnt be needed
Yes, the intent of that code is to try and catch bugs like the one
fixed by patch 4. Even if it catches it, we want to fix the original
bug.
> or the buffer could be allocated to an average size and reallocated
> when the encoder gets close to its end
> in which case reallocation also would not need a warning
> as it would be a normal operation
I have mixed feeling over not warning (and asking a sample). Sure we
may catch most issues with reallocating, but we can't get a guarantee
that the encode can complete (hence patch 1) in case of a serious
undersizing. Case in point: I had used a growth that was the maximum
between the quarter of the allocated size and twice the needed size,
and it crashed without patch 2.
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha
Hi, 2014-08-12 1:56 GMT+02:00 Michael Niedermayer : >> - (2 + 2 * ctx->num_planes + >> + (2 + 2 * FFMIN(3, ctx->num_planes) + > > slice_hdr_size is 2 + 2 * (ctx->num_planes - 1); > > is this difference intended ? I don't know why there was a difference between the original code and slice_hdr_size. I don't know either why the +200 too (I expect it to be an upper bound of the other stuff, like quant matrix and other header info). In any case, we may err on the safer side and use that. Anyway, the hunk indeed is wrong as I misinterpreted the code. > also ctx->num_planes is currently either 3 or 4 which would make the > FFMIN a constant Yeah, I'll drop it. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
