Re: [FFmpeg-devel] [PATCH 2/2] avformat/apng: set max_fps to no limit by default
Hi,
On 21/03/2017 14:03, James Almer wrote:
> On 3/21/2017 9:52 AM, Michael Niedermayer wrote:
>> On Mon, Mar 20, 2017 at 11:03:23PM -0300, James Almer wrote:
>>> Should fix ticket #6252
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavformat/apngdec.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
>>> index 7a284e32c2..75dcf74a0c 100644
>>> --- a/libavformat/apngdec.c
>>> +++ b/libavformat/apngdec.c
>>> @@ -421,7 +421,7 @@ static const AVOption options[] = {
>>> { "ignore_loop", "ignore loop setting" ,
>>> offsetof(APNGDemuxContext, ignore_loop),
>>>AV_OPT_TYPE_BOOL, { .i64 = 1 } , 0, 1 ,
>>> AV_OPT_FLAG_DECODING_PARAM },
>>> { "max_fps", "maximum framerate (0 is no limit)" ,
>>> offsetof(APNGDemuxContext, max_fps),
>>> - AV_OPT_TYPE_INT, { .i64 = DEFAULT_APNG_FPS }, 0, INT_MAX,
>>> AV_OPT_FLAG_DECODING_PARAM },
>>> + AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX,
>>> AV_OPT_FLAG_DECODING_PARAM },
>>> { "default_fps", "default framerate (0 is as fast as possible)",
>>> offsetof(APNGDemuxContext, default_fps),
>>>AV_OPT_TYPE_INT, { .i64 = DEFAULT_APNG_FPS }, 0, INT_MAX,
>>> AV_OPT_FLAG_DECODING_PARAM },
>>> { NULL },
>> why was there a max fps set ?
>> are there files which have huge and incorrect fps ?
> I have no idea. The author of the decoder may know.
>
A bit late, but honestly, I don't remember why I did it that way, though
both patches look fine as they are.
It's easy enough to come back to that code when/if needed.
Thanks,
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avutil/spherical: add av_spherical_projection_name()
Hi,
On 29/03/2017 04:55, James Almer wrote:
> Signed-off-by: James Almer
> ---
> doc/APIchanges| 3 +++
> libavutil/spherical.c | 15 +++
> libavutil/spherical.h | 9 +
> 3 files changed, 27 insertions(+)
>
[...]
> diff --git a/libavutil/spherical.c b/libavutil/spherical.c
> index f0b622128a..1d06e7c552 100644
> --- a/libavutil/spherical.c
> +++ b/libavutil/spherical.c
> @@ -50,3 +50,18 @@ void av_spherical_tile_bounds(const AVSphericalMapping
> *map,
> *right = orig_width - width - *left;
> *bottom = orig_height - height - *top;
> }
> +
> +static const char *spherical_projection_names[] = {
> +[AV_SPHERICAL_EQUIRECTANGULAR] = "equirectangular",
> +[AV_SPHERICAL_CUBEMAP] = "cubemap",
> +[AV_SPHERICAL_EQUIRECTANGULAR_TILE] = "tiled equirectangular",
> +
> +};
> +
> +const char *av_spherical_projection_name(enum AVSphericalProjection
> projection)
> +{
> +if (projection >= FF_ARRAY_ELEMS(spherical_projection_names))
> +return "unknown";
> +
You should also check for projection to be negative, or cast it to
unsigned when checking.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [UPDATE] HLS, add option to skip down streams,
Hi,
On 20/04/2017 18:18, Amine kabab wrote:
> From 5079f9b7114589626a4c9fff0fbb8f6e0d2f4fd9 Mon Sep 17 00:00:00 2001
> From: amine kabab
> Date: Thu, 20 Apr 2017 15:59:42 +
> Subject: [PATCH] HLS skip down streams
>
> ---
> libavformat/hls.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4..26d7679 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -194,6 +194,7 @@ typedef struct HLSContext {
>
> int cur_seq_no;
> int live_start_index;
> +int skip_down_streams;
> int first_packet;
> int64_t first_timestamp;
> int64_t cur_timestamp;
> @@ -1652,11 +1653,20 @@ static int hls_read_header(AVFormatContext *s)
> /* If the playlist only contained playlists (Master Playlist),
> * parse each individual playlist. */
> if (c->n_playlists > 1 || c->playlists[0]->n_segments == 0) {
> +int all_failed = 1;
> for (i = 0; i < c->n_playlists; i++) {
> struct playlist *pls = c->playlists[i];
> -if ((ret = parse_playlist(c, pls->url, pls, NULL)) < 0)
> +av_log(NULL, AV_LOG_WARNING, "Trying %s\n", pls->url);
Do you really want to keep this trace?
> +ret = parse_playlist(c, pls->url, pls, NULL);
> +if (c->skip_down_streams && ret >= 0) {
> +all_failed = 0;
> +} else if (!c->skip_down_streams && ret < 0){
> goto fail;
> +}
If I understand correctly, that means that if you do not set
skip_down_streams and the playlist parsing is OK, you will not unset
all_failed, and bail out below. Is this really what you want?
> }
> +
> +if (all_failed)
> +goto fail;
> }
>
> if (c->variants[0]->playlists[0]->n_segments == 0) {
> @@ -2126,6 +2136,8 @@ static int hls_probe(AVProbeData *p)
> static const AVOption hls_options[] = {
> {"live_start_index", "segment index to start live streams at (negative
> values are from the end)",
> OFFSET(live_start_index), AV_OPT_TYPE_INT, {.i64 = -3}, INT_MIN,
> INT_MAX, FLAGS},
> +{"skip_down_streams", "continue playback of HLS when one of the variant
> streams are down",
> +OFFSET(skip_down_streams), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
> FLAGS},
> {NULL}
> };
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/aarch64/simple_idct: separate macro arguments with commas
Hi,
On 28/04/2017 21:58, Matthieu Bouron wrote:
> Untested: fixes ticket #6324.
> ---
> libavcodec/aarch64/simple_idct_neon.S | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/aarch64/simple_idct_neon.S
> b/libavcodec/aarch64/simple_idct_neon.S
> index 52273420f9..d31f72a609 100644
> --- a/libavcodec/aarch64/simple_idct_neon.S
> +++ b/libavcodec/aarch64/simple_idct_neon.S
> @@ -61,19 +61,19 @@ endconst
> br x10
> .endm
>
> -.macro smull1 a b c
> +.macro smull1 a, b, c
> smull \a, \b, \c
> .endm
>
> -.macro smlal1 a b c
> +.macro smlal1 a, b, c
> smlal \a, \b, \c
> .endm
>
> -.macro smlsl1 a b c
> +.macro smlsl1 a, b, c
> smlsl \a, \b, \c
> .endm
>
> -.macro idct_col4_top y1 y2 y3 y4 i l
> +.macro idct_col4_top y1, y2, y3, y4, i, l
> smull\i v7.4S, \y3\().\l, z2
> smull\i v16.4S, \y3\().\l, z6
> smull\i v17.4S, \y2\().\l, z1
> @@ -91,7 +91,7 @@ endconst
> smlsl\i v6.4S, \y4\().\l, z5
> .endm
>
> -.macro idct_row4_neon y1 y2 y3 y4 pass
> +.macro idct_row4_neon y1, y2, y3, y4, pass
> ld1 {\y1\().2D-\y2\().2D}, [x2], #32
> moviv23.4S, #1<<2, lsl #8
> orr v5.16B, \y1\().16B, \y2\().16B
> @@ -153,7 +153,7 @@ endconst
> trn2\y4\().4S, v17.4S, v19.4S
> .endm
>
> -.macro declare_idct_col4_neon i l
> +.macro declare_idct_col4_neon i, l
> function idct_col4_neon\i
> dup v23.4H, z4c
> .if \i == 1
Sounds sane, but shouldn't we be doing this for all instances of
multiple arguments macros without commas?
Thanks
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Two patches from github
Hi, On 15/05/2017 12:40, Carl Eugen Hoyos wrote: > > 0002-avutil-Use-_SC_NPROCESSORS_CONF.patch > > > From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001 > From: Steve Kondik > Date: Tue, 16 Dec 2014 01:37:57 -0800 > Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF > > * On most Android devices, CPUs can appear and disappear due to hotplug >or CPU cluster management. Use the total number of CPUs instead so >that multithreaded decoding is properly optimized. I'm not convinced the patch below fixes the issue described above. The idea is to optimize the number of threads given the number of usable CPUs. If a user of libav* wants to make sure they use the right number, they should make sure that the CPUs are woken up prior to calling this. There are ways to force the system's power management to make sure that the number of online CPUs is maximized, and, IMHO, that should be used instead of returning the total number of CPUs on the platform. > Change-Id: I1cbf000a1bda7b3abf0a84e971e752f176857385 > --- > libavutil/cpu.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavutil/cpu.c b/libavutil/cpu.c > index 16e0c92..ab0965b 100644 > --- a/libavutil/cpu.c > +++ b/libavutil/cpu.c > @@ -282,6 +282,8 @@ int av_cpu_count(void) > > if (sysctl(mib, 2, &nb_cpus, &len, NULL, 0) == -1) > nb_cpus = 0; > +#elif defined(__ANDROID__) && HAVE_SYSCONF && defined(_SC_NPROCESSORS_CONF) > +nb_cpus = sysconf(_SC_NPROCESSORS_CONF); > #elif HAVE_SYSCONF && defined(_SC_NPROC_ONLN) > nb_cpus = sysconf(_SC_NPROC_ONLN); > #elif HAVE_SYSCONF && defined(_SC_NPROCESSORS_ONLN) > -- 1.7.10.4 -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] matroskadec: fix NULL pointer dereference
Hi,
On 17/10/2016 06:49, James Almer wrote:
On 10/16/2016 9:30 PM, James Almer wrote:
On 10/16/2016 5:11 PM, Andreas Cadhalpun wrote:
The problem was introduced in commit 1273bc6.
Signed-off-by: Andreas Cadhalpun
---
libavformat/matroskadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 8847c62..a5d3c0e 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1759,7 +1759,7 @@ static int mkv_field_order(MatroskaDemuxContext
*matroska, int64_t field_order)
/* workaround a bug in our Matroska muxer, introduced in version 57.36 alongside
* this function, and fixed in 57.52 */
-if (sscanf(matroska->muxingapp, "Lavf%d.%d.%d", &major, &minor, µ) ==
3)
+if (matroska->muxingapp && sscanf(matroska->muxingapp, "Lavf%d.%d.%d", &major,
&minor, µ) == 3)
LGTM.
Matroska files are supposed to always have that element, but even ffmpeg used
to mux files without it at some point when bitexact flag was enabled, so i
guess plenty of files out there are missing it.
bttb = (major == 57 && minor >= 36 && minor <= 51 && micro >= 100);
switch (field_order) {
Just tried a file missing the muxingapp element, meaning matroska->muxingapp
is NULL, and sscanf simply returns -1 and sets errno to EINVAL.
Where does it crash for you and using what file?
FWIW, I've just written a quick test on my machine, and an "sscanf(NULL,
"%d", &i)" segfaults.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mov: zero initialize codec_name in mov_parse_stsd_video()
Hi,
On 17/10/2016 02:34, James Almer wrote:
> Fixes valgrind warning about "Conditional jump or move depends on
> uninitialised value(s)"
>
> Signed-off-by: James Almer
> ---
> libavformat/mov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index add1812..7462ecf 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1802,7 +1802,7 @@ static int mov_codec_id(AVStream *st, uint32_t format)
> static void mov_parse_stsd_video(MOVContext *c, AVIOContext *pb,
> AVStream *st, MOVStreamContext *sc)
> {
> -uint8_t codec_name[32];
> +uint8_t codec_name[32] = { 0 };
> int64_t stsd_start;
> unsigned int len;
>
Do we really need to "fix" false positive from Valgrind?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] mov: Evaluate the movie display matrix
Hi, On 14/10/2016 00:50, Vittorio Giovara wrote: > diff --git a/libavformat/mov.c b/libavformat/mov.c > index a15c8d1..e8da77f 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c [...] > @@ -3798,16 +3804,33 @@ static int mov_read_meta(MOVContext *c, AVIOContext > *pb, MOVAtom atom) > return 0; > } > > +// return 0 when matrix is identity, 1 otherwise > +#define IS_MATRIX_FULL(matrix) \ > +(matrix[0][0] != (1 << 16) ||\ > + matrix[1][1] != (1 << 16) ||\ > + matrix[2][2] != (1 << 30) ||\ > + matrix[0][1] || matrix[0][2] || \ > + matrix[1][0] || matrix[1][2] || \ > + matrix[2][0] || matrix[2][1]) > + should be "(matrix)" everywhere Also, reversing the logic would allow preventing the evaluation of all conditions when the matrix is not identity (i.e. making it IS_MATRIX_IDENTITY) > +// fixed point to double > +#define CONV_FP(x, sh) ((double) (x)) / (1 << (sh)) > + ((double) (x) / (1 << (sh))) > +// double to fixed point > +#define CONV_DB(x, sh) ((int32_t) ((x) * (1 << (sh > + Cheers, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ffjni: replace ff_jni_{attach, detach} with ff_jni_get_env
Hi,
On 24/07/2016 23:05, Matthieu Bouron wrote:
From: Matthieu Bouron
If a JNI environment is not already attached to the thread where the
MediaCodec calls are made the current implementation will attach /
detach an environment for each MediaCodec call wasting some CPU time.
ff_jni_get_env replaces ff_jni_{attach,detach} by permanently attaching
an environment (if it is not already the case) to the current thread.
The environment will be automatically detached at the thread destruction
using a pthread_key callback.
Saves around 5% of CPU time (out of 20%) while decoding a stream with
MediaCodec.
---
libavcodec/ffjni.c | 43 +
libavcodec/ffjni.h | 15 +--
LGTM
libavcodec/mediacodec.c | 14 +--
libavcodec/mediacodec_surface.c | 14 +--
libavcodec/mediacodec_wrapper.c | 200
5 files changed, 74 insertions(+), 212 deletions(-)
Just had a quick look at those ones.
Cheers,
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: fix SODB escaping
Hi,
On 06/09/2016 16:53, Matthieu Bouron wrote:
From: Matthieu Bouron
Fixes escaping of consecutive 0x00, 0x00, 0x0{0-3} sequences.
---
libavcodec/mediacodecdec_h264.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index a141174..4f9d737 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -104,9 +104,9 @@ static int h264_ps_to_nalu(const uint8_t *src, int
src_size, uint8_t **out, int
}
*out = p = new;
-i = i + 3;
-memmove(p + i, p + i - 1, *out_size - i);
-p[i - 1] = 0x03;
+i = i + 2;
+memmove(p + i + 1, p + i, *out_size - (i + 1));
+p[i] = 0x03;
LGTM
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264: Use ptrdiff_t for (bi)width functions
Hi, On 21/09/2016 03:34, Michael Niedermayer wrote: Might fix some mysterious asm related issues like Ticket5579 Signed-off-by: Michael Niedermayer --- libavcodec/h264dsp.h | 5 +++-- libavcodec/h264dsp_template.c | 4 ++-- libavcodec/mips/h264dsp_mips.h | 26 +- libavcodec/mips/h264dsp_mmi.c | 12 ++-- libavcodec/x86/h264dsp_init.c | 8 5 files changed, 28 insertions(+), 27 deletions(-) Typo in the commit message: should be weight, not width. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add nlmeans filter
Hi,
On 20/09/2016 21:52, Clément Bœsch wrote:
Fixes Ticket #4910
---
I actually tried to implement the better defaults suggestion from ipol (see
@todo) but it wasn't convincing; probably because of different scales, so I
need to investigate.
Also, integral is still inplace in the filter for now as I didn't find a clean
way of testing it outside the filter without a long trip in dependency hell. I
think it can wait until the SIMD are implemented and the need to expose it
comes up.
I've made several changes from the initial WIP. The most important one is the
fix in the patch distance calculation, followed by the the addition of chroma
parameters.
I believe the filter is ready for integration as a first version.
Two interesting examples: http://imgur.com/a/XXhJP
---
Changelog| 1 +
doc/filters.texi | 35 +++
libavfilter/Makefile | 3 +-
libavfilter/allfilters.c | 1 +
libavfilter/tests/integral.c | 92
libavfilter/version.h| 2 +-
libavfilter/vf_nlmeans.c | 548 +++
7 files changed, 680 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/tests/integral.c
create mode 100644 libavfilter/vf_nlmeans.c
diff --git a/Changelog b/Changelog
index 2d0a449..a5282b4 100644
--- a/Changelog
+++ b/Changelog
@@ -31,6 +31,7 @@ version :
- MediaCodec HEVC decoding
- TrueHD encoder
- Meridian Lossless Packing (MLP) encoder
+- nlmeans filter (denoiser)
The full name could be used here: Non-Local Means (nlmeans) denoising filter
version 3.1:
diff --git a/doc/filters.texi b/doc/filters.texi
index 070e57d..7e9ab60 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9695,6 +9695,41 @@ Negate input video.
It accepts an integer in input; if non-zero it negates the
alpha component (if available). The default value in input is 0.
+@section nlmeans
+
+Denoise frames using Non-Local Means algorithm.
+
+Each pixel is adjusted by looking for other pixels with similar contexts. This
+context similarity is defined by their surrounding patch of size
"is defined by comparing their surrounding patches" ?
+@option{p}x@option{p}. Patches are researched in an area of
+@option{r}x@option{r} surrouding the pixel.
+
surrounding, or even simply "around"
Also "research" sounds weird (I'd use "search"), but maybe wait for
someone native to comment
[...]
diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
new file mode 100644
index 000..f923f80
--- /dev/null
+++ b/libavfilter/vf_nlmeans.c
@@ -0,0 +1,548 @@
+/*
+ * Copyright (c) 2016 Clément Bœsch
+ *
+ * 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
+ */
+
+/**
+ * @todo
+ * - SIMD for compute_safe_ssd_integral_image
+ * - SIMD for final weighted averaging
+ * - better automatic defaults? see "Parameters" @
http://www.ipol.im/pub/art/2011/bcm_nlm/
+ * - temporal support (probably doesn't need any displacement according to
+ * "Denoising image sequences does not require motion estimation")
+ * - bayer support?
+ * - FATE test (probably needs visual threshold test mechanism due to the use
of floats)
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+struct weighted_avg {
+double total_weight;
+double sum;
+};
+
+#define WEIGHT_LUT_NBITS 9
+#define WEIGHT_LUT_SIZE (1<
nit: could you use _uv instead of _c (the latter has a taste of C vs ASM)?
+int research_size, research_hsize;// research size and half size
+int research_size_c, research_hsize_c; // research size and half size for
chroma planes
+uint32_t *ii_orig; // integral image
+uint32_t *ii; // integral image starting after
the 0-line and 0-column
+int ii_w, ii_h; // width and height of the
integral image
+int ii_lz_32; // linesize in 32-bit units of the
integral image
+struct weighted_avg *wa;// weighted average of every pixel
+int wa_linesize;// linesize for wa in struct size
unit
+double weight_lut[WEIGHT_LU
Re: [FFmpeg-devel] [PATCH] avformat/matroskadec: retain error codes in matroska_resync() and matroska_read_packet()
Hi,
On 22/09/2016 23:03, Sophia Wang wrote:
Signed-off-by: Sophia Wang
---
libavformat/matroskadec.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 77b8a5d..936690d 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -738,13 +738,16 @@ static int matroska_read_close(AVFormatContext *s);
static int matroska_resync(MatroskaDemuxContext *matroska, int64_t last_pos)
{
AVIOContext *pb = matroska->ctx->pb;
+int64_t ret;
uint32_t id;
matroska->current_id = 0;
matroska->num_levels = 0;
/* seek to next position to resync from */
-if (avio_seek(pb, last_pos + 1, SEEK_SET) < 0)
-goto eof;
+if ((ret = avio_seek(pb, last_pos + 1, SEEK_SET)) < 0) {
+matroska->done = 1;
+return ret;
doesn't this generate a warning, returning an int64 from a function
supposed to return an int?
+}
id = avio_rb32(pb);
@@ -760,7 +763,6 @@ static int matroska_resync(MatroskaDemuxContext *matroska, int64_t last_pos)
id = (id << 8) | avio_r8(pb);
}
-eof:
matroska->done = 1;
return AVERROR_EOF;
}
@@ -3317,13 +3319,14 @@ static int matroska_parse_cluster(MatroskaDemuxContext
*matroska)
static int matroska_read_packet(AVFormatContext *s, AVPacket *pkt)
{
MatroskaDemuxContext *matroska = s->priv_data;
+int ret = 0;
while (matroska_deliver_packet(matroska, pkt)) {
int64_t pos = avio_tell(matroska->ctx->pb);
if (matroska->done)
-return AVERROR_EOF;
+return (ret < 0) ? ret : AVERROR_EOF;
if (matroska_parse_cluster(matroska) < 0)
-matroska_resync(matroska, pos);
+ret = matroska_resync(matroska, pos);
}
return 0;
You might want to return ret instead of 0 here.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/psymodel: check for av_malloc failure
Hi,
Le 04/03/2016 04:06, Ganesh Ajjanagadde a écrit :
No idea why in commit 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec the
checks were removed; this can lead to NULL pointer dereferences. This
effectively reverts that portion of the commit.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/psymodel.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/psymodel.c b/libavcodec/psymodel.c
index 6274a49..edc5ac8 100644
--- a/libavcodec/psymodel.c
+++ b/libavcodec/psymodel.c
@@ -120,7 +120,11 @@ av_cold struct FFPsyPreprocessContext*
ff_psy_preprocess_init(AVCodecContext *av
FF_FILTER_MODE_LOWPASS,
FILT_ORDER,
cutoff_coeff, 0.0, 0.0);
if (ctx->fcoeffs) {
-ctx->fstate = av_mallocz(sizeof(ctx->fstate[0]) * avctx->channels);
+ctx->fstate = av_mallocz_array(sizeof(ctx->fstate[0]),
avctx->channels);
+if (!ctx->fstate) {
+av_free(ctx);
+return NULL;
you're leaking ctx->fcoeffs
+}
for (i = 0; i < avctx->channels; i++)
ctx->fstate[i] = ff_iir_filter_init_state(FILT_ORDER);
}
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/10] swscale/arm/yuv2rgb: fix comments and factorize lsl in load_args_yuv422p
Hi,
Le 25/03/2016 23:45, Matthieu Bouron a écrit :
From: Matthieu Bouron
---
libswscale/arm/yuv2rgb_neon.S | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index f40327b..aac0773 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -172,11 +172,10 @@
vdup.16 d0, r10@ d0
= y_coeff
vld1.16 {d1}, [r8] @ d1
= *table
add r11, r2, r3@ r11
= dst + linesize (dst2)
-lsl r8, r0, #2
-sub r3, r3, r8 @ r3 =
linesize * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 =
linesizeY * 2 - width (paddingY)
-sub r7, r7, r0, lsr #1 @ r7 =
linesizeU - width / 2 (paddingU)
-sub r12,r12,r0, lsr #1 @ r12 =
linesizeV- width / 2 (paddingV)
+sub r3, r3, r0, lsl #2 @ r3 =
linesize - width * 4 (padding)
+sub r5, r5, r0 @ r5 =
linesizeY - width (paddingY)
+sub r7, r7, r0, lsr #1 @ r7 =
linesizeU - width / 2 (paddingU)
+sub r12,r12,r0, lsr #1 @ r12 =
linesizeV - width / 2 (paddingV)
ldr r10,[sp, #120] @ r10
= srcV
.endm
nit: it would be cool to split: one for the comments and the other one
for the lsl factorization.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time for the yuv420p and nv{12, 21} formats
Hi,
Le 26/03/2016 13:05, Matthieu Bouron a écrit :
On Sat, Mar 26, 2016 at 2:09 AM, Michael Niedermayer
>wrote:
>On Fri, Mar 25, 2016 at 11:46:01PM +0100, Matthieu Bouron wrote:
> >From: Matthieu Bouron
> >
> >---
> > libswscale/arm/yuv2rgb_neon.S | 89
>---
> > 1 file changed, 24 insertions(+), 65 deletions(-)
>
>breaks build
>
> make distclean ; ../configure --cross-prefix=/usr/arm-linux-gnueabi/bin/
>--cc='ccache arm-linux-gnueabi-gcc-4.5' --extra-cflags='-mfpu=neon
>-mfloat-abi=softfp' --cpu=cortex-a8 --arch=armv7 --target-os=linux
>--enable-cross-compile && make -j12
>
>CC libavutil/arm/float_dsp_init_arm.o
>src/libswscale/arm/yuv2rgb_neon.S: Assembler messages:
>src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional
>instruction should be in IT block -- `subeq r6,r6,r0'
>src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional
>instruction should be in IT block -- `addne r6,r7'
>
[...]
Patch updated with the relevant it instructions added. It still does build
on my rpi2 setup but is not tested on the same setup as yours.
Can you confirm it builds/works on your setup ?
If it works, i will send an updated version of the next patch (07/10) to
resolve the conflicts.
Matthieu
0006-swscale-arm-yuv2rgb-only-process-one-line-at-a-time-.patch
From 7b3a405b2b483fb16f549b69ce6f21d8a946 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron
Date: Wed, 23 Mar 2016 11:26:13 +
Subject: [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time
for the yuv420p and nv{12,21} formats
---
libswscale/arm/yuv2rgb_neon.S | 92 +--
1 file changed, 27 insertions(+), 65 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..6aeccae 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -105,16 +105,6 @@
compute_16pxr2, d14, d15, \ofmt
.endm
-.macro process_2l_16px ofmt
-compute_premult d28, d29, d30, d31
-
-vld1.8 {q7}, [r4]!@ first
line of luma
-compute_16pxr2, d14, d15, \ofmt
-
-vld1.8 {q7}, [r12]! @
second line of luma
-compute_16pxr11, d14, d15, \ofmt
-.endm
-
.macro load_args_nvx
push{r4-r12, lr}
vpush {q4-q7}
@@ -127,13 +117,9 @@
ldr r10,[sp, #128] @ r10
= y_coeff
vdup.16 d0, r10@ d0
= y_coeff
vld1.16 {d1}, [r8] @ d1
= *table
-add r11, r2, r3@ r11 =
dst + linesize (dst2)
-add r12, r4, r5@ r12 =
srcY + linesizeY (srcY2)
Nit: this lets r11 and r12 unused by the NV conversions. It should be
possible not to push/pop them
If not (which I would certainly understand), what would you think about
moving the registers save out of the 'load_args_*' macro?
It seems weird to have all the push/vpush that are not factored, and the
pop/vpop that is done in only one place, at the end of each function.
[snip]
Looks good to me anyway (as well as the remainder of the series).
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 6/9] swscale/arm/yuv2rgb: macro-ify
On 28/03/2016 21:19, Matthieu Bouron wrote:
---
libswscale/arm/yuv2rgb_neon.S | 137 ++
1 file changed, 60 insertions(+), 77 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..e1b68c1 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -64,7 +64,7 @@
vmov.u8 \a2, #255
.endm
-.macro compute_16px dst y0 y1 ofmt
+.macro compute dst y0 y1 ofmt
vmovl.u8q14, \y0 @ 8px
of y
vmovl.u8q15, \y1 @ 8px
of y
@@ -99,23 +99,23 @@
.endm
-.macro process_1l_16px ofmt
+.macro process_1l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
.endm
-.macro process_2l_16px ofmt
+.macro process_2l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!@ first line of luma
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
vld1.8 {q7}, [r12]! @ second line of luma
-compute_16pxr11, d14, d15, \ofmt
+compute r11, d14, d15, \ofmt
.endm
-.macro load_args_nvx
+.macro load_args_nv12
push{r4-r12, lr}
vpush {q4-q7}
ldr r4, [sp, #104] @ r4
= srcY
@@ -136,6 +136,10 @@
sub r7, r7, r0 @ r7 =
linesizeC - width (paddingC)
.endm
+.macro load_args_nv21
+load_args_nv12
+.endm
+
.macro load_args_yuv420p
push{r4-r12, lr}
vpush {q4-q7}
@@ -176,55 +180,23 @@
ldr r10,[sp, #120] @ r10
= srcV
.endm
-.macro declare_func ifmt ofmt
-function ff_\ifmt\()_to_\ofmt\()_neon, export=1
-
-.ifc \ifmt,nv12
-load_args_nvx
-.endif
-
-.ifc \ifmt,nv21
-load_args_nvx
-.endif
-
-.ifc \ifmt,yuv420p
-load_args_yuv420p
-.endif
-
-
-.ifc \ifmt,yuv422p
-load_args_yuv422p
-.endif
-
-1:
-mov r8, r0 @ r8 =
width
-2:
-pld [r6, #64*3]
-pld [r4, #64*3]
-
-vmov.i8 d10, #128
-
-.ifc \ifmt,nv12
+.macro load_chroma_nv12
pld [r12, #64*3]
vld2.8 {d2, d3}, [r6]!@ q1: interleaved chroma line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,nv21
+.macro load_chroma_nv21
pld [r12, #64*3]
vld2.8 {d2, d3}, [r6]!@ q1: interleaved chroma line
vsubl.u8q14, d3, d10 @ q14
= U - 128
vsubl.u8q15, d2, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv420p
+.macro load_chroma_yuv420p
pld [r10, #64*3]
pld [r12, #64*3]
@@ -232,68 +204,79 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv422p
+.macro load_chroma_yuv422p
pld [r10, #64*3]
vld1.8 d2, [r6]! @ d2: chroma red line
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_1l_16px \ofmt
-.endif
-
-subsr8, r8, #16@ width
-= 16
-bgt 2b
-
-add r2, r2, r3 @ dst
+= padding
-add r4, r4, r5 @ srcY
+= paddingY
-
-.ifc \ifmt,nv12
+.macro increment_nv12
add r11, r11, r3 @ dst2
+= padding
add r12, r12, r5 @
srcY2 += paddingY
-
add r6, r6, r7 @ srcC
+= paddingC
-
subsr1, r1, #2
Re: [FFmpeg-devel] [PATCH v2 6/9] swscale/arm/yuv2rgb: macro-ify
Hi,
(sorry for the first mail, fuzzy fingers...)
On 28/03/2016 21:19, Matthieu Bouron wrote:
---
libswscale/arm/yuv2rgb_neon.S | 137 ++
1 file changed, 60 insertions(+), 77 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..e1b68c1 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -64,7 +64,7 @@
vmov.u8 \a2, #255
.endm
-.macro compute_16px dst y0 y1 ofmt
+.macro compute dst y0 y1 ofmt
vmovl.u8q14, \y0 @ 8px
of y
vmovl.u8q15, \y1 @ 8px
of y
@@ -99,23 +99,23 @@
.endm
-.macro process_1l_16px ofmt
+.macro process_1l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
.endm
-.macro process_2l_16px ofmt
+.macro process_2l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!@ first line of luma
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
vld1.8 {q7}, [r12]! @ second line of luma
-compute_16pxr11, d14, d15, \ofmt
+compute r11, d14, d15, \ofmt
.endm
This renaming could be split
[...]
@@ -232,68 +204,79 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv422p
+.macro load_chroma_yuv422p
pld [r10, #64*3]
vld1.8 d2, [r6]! @ d2: chroma red line
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_1l_16px \ofmt
-.endif
-
-subsr8, r8, #16@ width
-= 16
-bgt 2b
-
-add r2, r2, r3 @ dst
+= padding
-add r4, r4, r5 @ srcY
+= paddingY
-
-.ifc \ifmt,nv12
+.macro increment_nv12
How about increment_and test_nv12? Same for the other ones.
(I'm not happy with the name I found, but am trying to come up with a
solution to have a more explicit naming)
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 8/9] swscale/arm/yuv2rgb: save a few instructions by processing the luma line interleaved
Hi,
On 28/03/2016 21:19, Matthieu Bouron wrote:
---
libswscale/arm/yuv2rgb_neon.S | 88 +--
1 file changed, 34 insertions(+), 54 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 124d7d3..6b911c8 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
[...]
@@ -94,25 +67,29 @@
.ifc \ofmt,bgra
compute_rgbad8, d7, d6, d9, d12, d11, d10, d13
.endif
+
+vzip.8 d6, d10
+vzip.8 d7, d11
+vzip.8 d8, d12
+vzip.8 d9, d13
Adding a comment to explain the resulting interleaving would be nice
vst4.8 {q3, q4}, [\dst,:128]!
vst4.8 {q5, q6}, [\dst,:128]!
-
.endm
.macro process_1l ofmt
-compute_premult d28, d29, d30, d31
-vld1.8 {q7}, [r4]!
-compute r2, d14, d15, \ofmt
+compute_premult
+vld2.8 {d14, d15}, [r4]!
+compute r2, \ofmt
.endm
.macro process_2l ofmt
-compute_premult d28, d29, d30, d31
+compute_premult
-vld1.8 {q7}, [r4]!@ first line of luma
-compute r2, d14, d15, \ofmt
+vld2.8 {d14, d15}, [r4]! @ q7 =
Y (interleaved)
+compute r2, \ofmt
-vld1.8 {q7}, [r12]! @ second line of luma
-compute r11, d14, d15, \ofmt
+vld2.8 {d14, d15}, [r12]! @ q7 =
Y (interleaved)
+compute r11, \ofmt
.endm
What about adding a level of macro here? Something like:
.macro process_1l_internal ofmt src_addr res
compute_premult
vld2.8{d14, d15}, [\src_addr]!
compute\res, \ofmt
.endm
(again, the naming could be changed, according to your own taste :-) )
This way, we would get:
.macro process_1l ofmt
process_1l_internal \ofmt, r4, r2
.endm
.macro process_2l ofmt
process_1l_internal \ofmt, r4, r2
process_1l_internal \ofmt, r12, r11
.endm
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 6/9] swscale/arm/yuv2rgb: macro-ify
On 28/03/2016 21:19, Matthieu Bouron wrote:
---
libswscale/arm/yuv2rgb_neon.S | 137 ++
1 file changed, 60 insertions(+), 77 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..e1b68c1 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -64,7 +64,7 @@
vmov.u8 \a2, #255
.endm
-.macro compute_16px dst y0 y1 ofmt
+.macro compute dst y0 y1 ofmt
vmovl.u8q14, \y0 @ 8px
of y
vmovl.u8q15, \y1 @ 8px
of y
@@ -99,23 +99,23 @@
.endm
-.macro process_1l_16px ofmt
+.macro process_1l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
.endm
-.macro process_2l_16px ofmt
+.macro process_2l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!@ first line of luma
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
vld1.8 {q7}, [r12]! @ second line of luma
-compute_16pxr11, d14, d15, \ofmt
+compute r11, d14, d15, \ofmt
.endm
-.macro load_args_nvx
+.macro load_args_nv12
push{r4-r12, lr}
vpush {q4-q7}
ldr r4, [sp, #104] @ r4
= srcY
@@ -136,6 +136,10 @@
sub r7, r7, r0 @ r7 =
linesizeC - width (paddingC)
.endm
+.macro load_args_nv21
+load_args_nv12
+.endm
+
.macro load_args_yuv420p
push{r4-r12, lr}
vpush {q4-q7}
@@ -176,55 +180,23 @@
ldr r10,[sp, #120] @ r10
= srcV
.endm
-.macro declare_func ifmt ofmt
-function ff_\ifmt\()_to_\ofmt\()_neon, export=1
-
-.ifc \ifmt,nv12
-load_args_nvx
-.endif
-
-.ifc \ifmt,nv21
-load_args_nvx
-.endif
-
-.ifc \ifmt,yuv420p
-load_args_yuv420p
-.endif
-
-
-.ifc \ifmt,yuv422p
-load_args_yuv422p
-.endif
-
-1:
-mov r8, r0 @ r8 =
width
-2:
-pld [r6, #64*3]
-pld [r4, #64*3]
-
-vmov.i8 d10, #128
-
-.ifc \ifmt,nv12
+.macro load_chroma_nv12
pld [r12, #64*3]
vld2.8 {d2, d3}, [r6]!@ q1: interleaved chroma line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,nv21
+.macro load_chroma_nv21
pld [r12, #64*3]
vld2.8 {d2, d3}, [r6]!@ q1: interleaved chroma line
vsubl.u8q14, d3, d10 @ q14
= U - 128
vsubl.u8q15, d2, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv420p
+.macro load_chroma_yuv420p
pld [r10, #64*3]
pld [r12, #64*3]
@@ -232,68 +204,79 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv422p
+.macro load_chroma_yuv422p
pld [r10, #64*3]
vld1.8 d2, [r6]! @ d2: chroma red line
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14
= U - 128
vsubl.u8q15, d3, d10 @ q15
= V - 128
+.endm
-process_1l_16px \ofmt
-.endif
-
-subsr8, r8, #16@ width
-= 16
-bgt 2b
-
-add r2, r2, r3 @ dst
+= padding
-add r4, r4, r5 @ srcY
+= paddingY
-
-.ifc \ifmt,nv12
+.macro increment_nv12
add r11, r11, r3 @ dst2
+= padding
add r12, r12, r5 @
srcY2 += paddingY
-
add r6, r6, r7 @ srcC
+= paddingC
-
subsr1, r1, #2
Re: [FFmpeg-devel] [PATCH] swscale/arm: add yuv2planeX_8_neon
Hi,
(again, thanks to both of you for documenting all this assembly /NEON code)
On 09/04/2016 10:22, Matthieu Bouron wrote:
From: Matthieu Bouron
---
Hello,
The following patch add yuv2planeX_8_neon function for the arm platform. It is
currently restricted to 8-bit per component sources until I fix fate issues
with 10-bit sources (the dnxhd-*-10bit tests fail but I haven't figured out yet
where it comes from).
Matthieu
---
libswscale/arm/Makefile | 1 +
libswscale/arm/output.S | 78
libswscale/arm/swscale.c | 7 +
libswscale/utils.c | 3 +-
4 files changed, 88 insertions(+), 1 deletion(-)
create mode 100644 libswscale/arm/output.S
[...]
diff --git a/libswscale/arm/output.S b/libswscale/arm/output.S
new file mode 100644
index 000..4437447
--- /dev/null
+++ b/libswscale/arm/output.S
@@ -0,0 +1,78 @@
[...]
+function ff_yuv2planeX_8_neon, export=1
+push {r4-r12, lr}
+vpush {q4-q7}
+ldr r4, [sp, #104] @ dstW
+ldr r5, [sp, #108] @ dither
+ldr r6, [sp, #112] @ offset
+vld1.8 {d0}, [r5] @ load
8x8-bit dither values
+tst r6, #0 @ check
offsetting which can be 0 or 3 only
+beq 1f
+vext.u8 d0, d0, d0, #3 @ honor
offseting which can be 3 only
+1: vmovl.u8q0, d0 @
extend dither to 16-bit
+vshll.u16 q1, d0, #12@
extend dither to 32-bit with left shift by 12 (part 1)
+vshll.u16 q2, d1, #12@
extend dither to 32-bit with left shift by 12 (part 2)
+mov r7, #0 @ i = 0
+2: vmov.u8 q3, q1 @
initialize accumulator with dithering values (part 1)
+vmov.u8 q4, q2 @
initialize accumulator with dithering values (part 2)
+mov r8, r1 @
tmpFilterSize = filterSize
+mov r9, r2 @ srcp
+mov r10, r0@
filterp
+3: ldr r11, [r9], #4 @ get
pointer @ src[j]
+ldr r12, [r9], #4 @ get
pointer @ src[j+1]
+add r11, r11, r7, lsl #1 @
&src[j][i]
+add r12, r12, r7, lsl #1 @
&src[j+1][i]
+vld1.16 {q5}, [r11]@ read
8x16-bit @ src[j ][i + {0..7}]: A,B,C,D,E,F,G,H
+vld1.16 {q6}, [r12]@ read
8x16-bit @ src[j+1][i + {0..7}]: I,J,K,L,M,N,O,P
+ldr r11, [r10], #4 @ read
2x16-bit coeffs (X, Y) at (filter[j], filter[j+1])
+vmov.16 q7, q5 @ copy
8x16-bit @ src[j ][i + {0..7}] for following inplace zip instruction
+vmov.16 q8, q6 @ copy
8x16-bit @ src[j+1][i + {0..7}] for following inplace zip instruction
+vzip.16 q7, q8 @
A,I,B,J,C,K,D,L,E,M,F,N,G,O,H,L
nit: O,H,P
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] swresample/arm: add ff_resample_common_apply_filter_{x4, x8}_{float, s16}_neon
Hi,
I mostly have nits remarks.
On 11/05/2016 18:39, Matthieu Bouron wrote:
From: Matthieu Bouron
[...]
diff --git a/libswresample/arm/resample.S b/libswresample/arm/resample.S
new file mode 100644
index 000..13462e3
--- /dev/null
+++ b/libswresample/arm/resample.S
@@ -0,0 +1,77 @@
[...]
+function ff_resample_common_apply_filter_x4_float_neon, export=1
+vmov.f32q0, #0.0 @
accumulator
+1: vld1.32 {q1}, [r1]!@ src
+vld1.32 {q2}, [r2]!@ filter
+vmla.f32q0, q1, q2 @ src +
{0..3} * filter + {0..3}
nit: the comment could be "accu += src[0..3] . filter[0..3]"
same for the other ones below
[...]
+subsr3, #4 @
filter_length -= 4
+bgt 1b @ loop
until filter_length
+vpadd.f32 d0, d0, d1 @ pair
adding of the 4x32-bit accumulated values
+vpadd.f32 d0, d0, d0 @ pair
adding of the 4x32-bit accumulator values
+vst1.32 {d0[0]}, [r0] @ write
accumulator
+mov pc, lr
+endfunc
+
+function ff_resample_common_apply_filter_x8_float_neon, export=1
+vmov.f32q0, #0.0 @
accumulator
+1: vld1.32 {q1}, [r1]!@ src1
+vld1.32 {q2}, [r2]!@
filter1
+vld1.32 {q8}, [r1]!@ src2
+vld1.32 {q9}, [r2]!@
filter2
+vmla.f32q0, q1, q2 @ src1
+ {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @ src2
+ {0..3} * filter2 + {0..3}
instead of using src1 and src2, you may want to use src[0..3] and src[4..7]
so, if I reuse the formulation I proposed above:
accu += src[0..3] . filter[0..3]
accu += src[4..7] . filter[4..7]
+subsr3, #8 @
filter_length -= 4
-= 8
[...]
diff --git a/libswresample/arm/resample_init.c
b/libswresample/arm/resample_init.c
new file mode 100644
index 000..c817d03
--- /dev/null
+++ b/libswresample/arm/resample_init.c
[...]
+static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void *dest,
const void *source, \
+int n, int update_ctx)
\
+{
\
+DELEM *dst = dest;
\
+const DELEM *src = source;
\
+int dst_index;
\
+int index= c->index;
\
+int frac= c->frac;
\
+int sample_index = index >> c->phase_shift;
\
+int x4_aligned_filter_length = c->filter_length & ~3;
\
+int x8_aligned_filter_length = c->filter_length & ~7;
\
+
\
+index &= c->phase_mask;
\
+for (dst_index = 0; dst_index < n; dst_index++) {
\
+FELEM *filter = ((FELEM *) c->filter_bank) + c->filter_alloc * index;
\
+
\
+FELEM2 val=0;
\
+int i = 0;
\
+if (x8_aligned_filter_length >= 8) {
\
+ff_resample_common_apply_filter_x8_##TYPE##_neon(&val,
&src[sample_index],\
+ filter,
x8_aligned_filter_length); \
+i += x8_aligned_filter_length;
\
+
\
+} else if (x4_aligned_filter_length >= 4) {
Re: [FFmpeg-devel] [PATCH] swresample/arm: add ff_resample_common_apply_filter_{x4, x8}_{float, s16}_neon
Hi,
On 12/05/2016 15:22, Matthieu Bouron wrote:
On Thu, May 12, 2016 at 10:01 AM, Benoit Fouet wrote:
Hi,
I mostly have nits remarks.
On 11/05/2016 18:39, Matthieu Bouron wrote:
From: Matthieu Bouron
[...]
diff --git a/libswresample/arm/resample.S b/libswresample/arm/resample.S
new file mode 100644
index 000..13462e3
--- /dev/null
+++ b/libswresample/arm/resample.S
@@ -0,0 +1,77 @@
[...]
+function ff_resample_common_apply_filter_x4_float_neon, export=1
+vmov.f32q0, #0.0 @
accumulator
+1: vld1.32 {q1}, [r1]!@
src
+vld1.32 {q2}, [r2]!@
filter
+vmla.f32q0, q1, q2 @
src + {0..3} * filter + {0..3}
nit: the comment could be "accu += src[0..3] . filter[0..3]"
same for the other ones below
[...]
+subsr3, #4 @
filter_length -= 4
+bgt 1b @
loop until filter_length
+vpadd.f32 d0, d0, d1 @
pair adding of the 4x32-bit accumulated values
+vpadd.f32 d0, d0, d0 @
pair adding of the 4x32-bit accumulator values
+vst1.32 {d0[0]}, [r0] @
write accumulator
+mov pc, lr
+endfunc
+
+function ff_resample_common_apply_filter_x8_float_neon, export=1
+vmov.f32q0, #0.0 @
accumulator
+1: vld1.32 {q1}, [r1]!@
src1
+vld1.32 {q2}, [r2]!@
filter1
+vld1.32 {q8}, [r1]!@
src2
+vld1.32 {q9}, [r2]!@
filter2
+vmla.f32q0, q1, q2 @
src1 + {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @
src2 + {0..3} * filter2 + {0..3}
instead of using src1 and src2, you may want to use src[0..3] and src[4..7]
so, if I reuse the formulation I proposed above:
accu += src[0..3] . filter[0..3]
accu += src[4..7] . filter[4..7]
Fixed locally (as well as the other case you mentionned) with:
-vmla.f32q0, q1, q2 @
src1 + {0..3} * filter1 + {0..3}
-vmla.f32q0, q8, q9 @
src2 + {0..3} * filter2 + {0..3}
+vmla.f32q0, q1, q2 @
accumulator += src1 + {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @
accumulator += src2 + {4..7} * filter2 + {4..7}
I prefer to use + {0..3} instead of [0..3] to make the comments consistent
with what has been done in swscale/arm.
Fine for me (I chose the "[]" notation to be consistent with the "."
notation also, in order to do as if it were a dot product between two
vectors).
+subsr3, #8 @
filter_length -= 4
-= 8
Fixed locally.
[...]
diff --git a/libswresample/arm/resample_init.c
b/libswresample/arm/resample_init.c
new file mode 100644
index 000..c817d03
--- /dev/null
+++ b/libswresample/arm/resample_init.c
[...]
+static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void
*dest, const void *source, \
+int n, int update_ctx)
\
+{
\
+DELEM *dst = dest;
\
+const DELEM *src = source;
\
+int dst_index;
\
+int index= c->index;
\
+int frac= c->frac;
\
+int sample_index = index >> c->phase_shift;
\
+int x4_aligned_filter_length = c->filter_length & ~3;
\
+int x8_aligned_filter_length = c->filter_length & ~7;
\
+
\
+index &= c->phase_mask;
\
+for (dst_index = 0; dst_index < n; dst_index++) {
\
+FELEM *filter = ((FELEM *) c->filter_bank) + c->filter_alloc *
index; \
+
\
+FELEM2 val=0;
\
+int i = 0;
\
+if (x8_aligned_filter_length >= 8) {
\
+ff_resample_common_apply_filter_x8_##TYPE##_neon(&val,
&src[sample_index],\
+
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
Hi,
Le 18 mai 2016 20:40:08 GMT+02:00, Michael Niedermayer
a écrit :
>Signed-off-by: Michael Niedermayer
>---
> doc/developer.texi | 29 +
> 1 file changed, 29 insertions(+)
>
>diff --git a/doc/developer.texi b/doc/developer.texi
>index 6db93ce..4d3a7ae 100644
>--- a/doc/developer.texi
>+++ b/doc/developer.texi
>@@ -403,6 +403,35 @@ finding a new maintainer and also don't forget to
>update the @file{MAINTAINERS}
>
> We think our rules are not too hard. If you have comments, contact us.
>
>+@section Code of conduct
>+
>+Be friendly and respectful towards others and third parties.
>+Treat others the way you yourself want to be treated.
>+
>+Be considerate. Not everyone shares the same viewpoint and priorities
>as you do.
>+Different opinions and interpretations help the project.
>+Looking at issues from a different perspective assists development.
>+
>+Do not assume malice for things that can be attributed to
>incompetence. Even if
>+it is malice, it's rarely good to start with that as initial
>assumption.
>+
>+Stay friendly even if someone acts contrarily. Everyone has a bad day
>+once in a while.
>+If you yourself have a bad day or are angry then try to take a break
>and reply
>+once you are calm and without anger if you have to.
>+
>+Try to help other team members and cooperate if you can.
>+
>+The goal of software development is to create technical excellence,
>not for any
>+individual to be better and "win" against the others. Large software
>projects
>+are only possible and successful through teamwork.
>+
>+If someone struggles do not put them down. Give them a helping hand
>+instead and point them in the right direction.
>+
>+Finally, keep in mind the immortal words of Bill and Ted,
>+"Be excellent to each other."
>+
> @anchor{Submitting patches}
> @section Submitting patches
>
FWIW, fine by me too.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mpegtsenc: move putstr8 definition up
Hi,
Le 19/05/2016 18:45, Stefano Sabatini a écrit :
This allows to use the function in a future commit.
---
libavformat/mpegtsenc.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 93cbac1..5f22032 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -253,6 +253,23 @@ static void mpegts_write_pat(AVFormatContext *s)
data, q - data);
}
+/* NOTE: !str is accepted for an empty string */
+static void putstr8(uint8_t **q_ptr, const char *str)
+{
+uint8_t *q;
+int len;
+
+q = *q_ptr;
+if (!str)
+len = 0;
+else
+len = strlen(str);
+*q++ = len;
+memcpy(q, str, len);
Side note on this one, unrelated to your change.
Isn't this undefined behavior to call memcpy with one of the pointers
being NULL?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hls muxer doc: clarify segment splitting option
Hi,
find attached a patch to $subj
This would have been useful at least to me :-)
--
Ben
From aac7f87102337b7b1a59f88fc69766a20dfa0790 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Wed, 8 Jun 2016 11:42:51 +0200
Subject: [PATCH] hls muxer doc: clarify segment splitting option
---
doc/muxers.texi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c62d4b5..8847a1c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -358,7 +358,8 @@ This muxer supports the following options:
@table @option
@item hls_time @var{seconds}
-Set the segment length in seconds. Default value is 2.
+Set the target segment length in seconds. Default value is 2.
+Segment will be cut on the next key frame after this time has passed.
@item hls_list_size @var{size}
Set the maximum number of playlist entries. If set to 0 the list file
--
2.9.0.rc0.38.gf3913c2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
Hi, On 12/06/2016 22:58, Paul B Mahol wrote: Hi, As requested in the IRC meeting I hereby request for the voting committee to begin voting on whatever to ban Carl Eugen Hoyos from mailing list, trac and IRC for 4 months, starting after the voting has finished. Voting will last 7 days from now. In order for the vote to pass, at least 50% of all votes from committee need to agree to do so. Disclaimer: I'm not part of this committee All developers and users are welcome to write about their experiences with Carl. My feeling here is that all the things that have been discussed about the CoC are a consequence of Carl's behaviour on the ML. I can understand (I think) your feelings, but this is still problematic to me as a rule of thumb. It does not seem fair to decide on a CoC because of certain facts and then rule on those very facts on the charge that they fail to follow the rules that they have led to create. In addition to this, I really feel that 4 months is way too long for a ban, as in "forever". In short, I feel that this is unfair and too long a period, though I can understand your feelings on this. Cheers, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/os_support.h: Fix for unicode filenames on windows.
Hi,
On 13/06/2016 10:21, Clément Bœsch wrote:
On Mon, Jun 13, 2016 at 05:50:18AM +0200, Matt Oliver wrote:
ffmpeg | branch: master | Matt Oliver | Mon Jun 6
17:04:39 2016 +1000| [37787f261639c53998487400e874741c17e85fc6] | committer: Matt
Oliver
lavf/os_support.h: Fix for unicode filenames on windows.
Fixes #819 #5256 #5281
Signed-off-by: Matt Oliver
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37787f261639c53998487400e874741c17e85fc6
---
libavformat/file.c |4
libavformat/os_support.h | 24
2 files changed, 28 insertions(+)
diff --git a/libavformat/file.c b/libavformat/file.c
index 5765ce7..264542a 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -148,7 +148,11 @@ static int file_check(URLContext *h, int mask)
ret |= AVIO_FLAG_WRITE;
#else
struct stat st;
+# ifndef _WIN32
ret = stat(filename, &st);
+# else
+ret = win32_stat(filename, &st);
+# endif
why this chunk?
if (ret < 0)
return AVERROR(errno);
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index a332911..9e312a5 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -182,6 +182,29 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
DEF_FS_FUNCTION(mkdir, _wmkdir, _mkdir)
DEF_FS_FUNCTION(rmdir, _wrmdir , _rmdir)
+#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
+static inline int win32_##name(const char *filename_utf8, partype par) \
+{ \
+wchar_t *filename_w; \
+int ret; \
+ \
+if (utf8towchar(filename_utf8, &filename_w)) \
+return -1;\
+if (!filename_w) \
+goto fallback;\
+ \
+ret = wfunc(filename_w, par); \
+av_free(filename_w); \
+return ret; \
+ \
+fallback: \
+/* filename may be be in CP_ACP */\
+return afunc(filename_utf8, par); \
+}
+
+DEF_FS_FUNCTION2(access, _waccess, _access, int)
+DEF_FS_FUNCTION2(stat, _wstat64, _stat64, struct stat*)
+
static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
{
wchar_t *src_w, *dest_w;
@@ -231,6 +254,7 @@ fallback:
#define rename win32_rename
#define rmdir win32_rmdir
#define unlink win32_unlink
+#define access win32_access
...instead of #define stat win32_stat here?
as already noted by someone else, this should be
#define stat(a, b) win32_stat((a), (b))
in order not to conflict with "struct stat" definition.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] hls muxer doc: clarify segment splitting option
Hi, Le 08/06/2016 11:46, Benoit Fouet a écrit : Hi, find attached a patch to $subj This would have been useful at least to me :-) Anyone against this patch? If not, can someone please apply it? Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: allow devices not implementing VIDIOC_G_PARM
Hi,
On 15/06/2016 17:21, Niklas Söderlund wrote:
Not all v4l2 devices implement the VIDIOC_G_PARM ioctl. This patch allow
ffmpeg to open such device and treat it the same as devices that do
implement the ioctl but returns that it do not implement the
V4L2_CAP_TIMEPERFRAME capability.
Signed-off-by: Niklas Söderlund
---
libavdevice/v4l2.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 103fb10..c8915e0 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -715,11 +715,8 @@ static int v4l2_set_parameters(AVFormatContext *ctx)
streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (v4l2_ioctl(s->fd, VIDIOC_G_PARM, &streamparm) < 0) {
ret = AVERROR(errno);
-av_log(ctx, AV_LOG_ERROR, "ioctl(VIDIOC_G_PARM): %s\n",
av_err2str(ret));
-return ret;
-}
-
-if (framerate_q.num && framerate_q.den) {
+av_log(ctx, AV_LOG_WARNING, "ioctl(VIDIOC_G_PARM): %s\n",
av_err2str(ret));
+} else if (framerate_q.num && framerate_q.den) {
if (streamparm.parm.capture.capability & V4L2_CAP_TIMEPERFRAME) {
tpf = &streamparm.parm.capture.timeperframe;
LGTM
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
Hi,
Unless I totally missed something, the FIXME in H264ParamSets structure
should be fixed by attached patch.
--
Ben
From 28ae10498f81070539bdb8f40236326743350101 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const
---
libavcodec/h264.h | 3 +--
libavcodec/h264_slice.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6e7b940..da7f9dd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -873,7 +873,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h,
int force_callback)
/* export coded and cropped frame dimensions to AVCodecContext */
static int init_dimensions(H264Context *h)
{
-SPS *sps = h->ps.sps;
+SPS *sps = (SPS*)h->ps.sps_ref->data;
int width = h->width - (sps->crop_right + sps->crop_left);
int height = h->height - (sps->crop_top + sps->crop_bottom);
av_assert0(sps->crop_right + sps->crop_left < (unsigned)h->width);
--
2.9.0.rc2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
Hi,
On 21/06/2016 14:52, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 2:40 PM, Clément Bœsch wrote:
On Tue, Jun 21, 2016 at 02:34:33PM +0200, Benoit Fouet wrote:
Hi,
Unless I totally missed something, the FIXME in H264ParamSets structure
should be fixed by attached patch.
--
Ben
From 28ae10498f81070539bdb8f40236326743350101 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const
---
libavcodec/h264.h | 3 +--
libavcodec/h264_slice.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6e7b940..da7f9dd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -873,7 +873,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h,
int force_callback)
/* export coded and cropped frame dimensions to AVCodecContext */
static int init_dimensions(H264Context *h)
{
-SPS *sps = h->ps.sps;
+SPS *sps = (SPS*)h->ps.sps_ref->data;
int width = h->width - (sps->crop_right + sps->crop_left);
int height = h->height - (sps->crop_top + sps->crop_bottom);
av_assert0(sps->crop_right + sps->crop_left < (unsigned)h->width);
So it's not actually const, right?
Indeed, the FIXME wasn't just there because someone forgot to write
"const" in front of it, but because it was used in some parts as
not-const.
OK, right... Thanks for reminding me of reading the code better before
sending a patch.
As far as I can see, the only place where this constness is not
preserved is in the init_dimensions function (in h264_slice), in a dead
part of the code, as crop is asserted at the beginning of the very same
function.
Please correct me if I've missed other places.
Updated patch attached (which I can very well split in two different
ones if it's (more) correct).
Thanks,
--
Ben
From cc56a2f787c64ca4051be9b53dd2e4e9b472339c Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const
Only init_dimension was abusing the data, in a case that is asserted can
never happen.
---
libavcodec/h264.h| 3 +--
libavcodec/h264_parser.c | 2 +-
libavcodec/h264_ps.c | 2 +-
libavcodec/h264_sei.c| 4 ++--
libavcodec/h264_slice.c | 21 ++---
5 files changed, 7 insertions(+), 25 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 42ad932..76ed2a3 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -373,7 +373,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
"non-existing SPS %u referenced\n", p->ps.pps->sps_id);
goto fail;
}
-p->ps.sps = (SPS*)p->ps.sps_list[p->ps.pps->sps_id]->data;
+p->ps.sps = (const SPS*)p->ps.sps_list[p->ps.pps->sps_id]->data;
sps = p->ps.sps;
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index fb05b05..3867918 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -738,7 +738,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb,
AVCodecContext *avct
ret = AVERROR_INVALIDDATA;
goto fail;
}
-sps = (SPS*)ps->sps_list[pps->sps_id]->data;
+sps = (const SPS*)ps->sps_list[pps->sps_id]->data;
if (sps->bit_depth_luma > 14) {
av_log(avctx, AV_LOG_ERROR,
"Invalid luma bit depth=%d\n",
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index d0596dc..fedb172 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -276,7 +276,7 @@ static int decode_buffering_period(H264SEIBufferingPeriod
*h, GetBitContext *gb,
{
unsigned int sps_id;
int sched_sel_idx;
-SPS *sps;
+const SPS *sps;
sps_id = get_ue_golomb_31(gb);
if (sps_id > 31 || !ps->sps_list[sps_id]) {
@@ -284,7 +284,7 @@ static int decode_buffering_period(H264SEIBufferingPeriod
*h, GetBitContext *gb,
"non-existing SPS %d referenced i
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
Hi,
On 21/06/2016 16:29, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 4:20 PM, Benoit Fouet wrote:
Hi,
On 21/06/2016 14:52, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 2:40 PM, Clément Bœsch wrote:
On Tue, Jun 21, 2016 at 02:34:33PM +0200, Benoit Fouet wrote:
Hi,
Unless I totally missed something, the FIXME in H264ParamSets structure
should be fixed by attached patch.
--
Ben
From 28ae10498f81070539bdb8f40236326743350101 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const
---
libavcodec/h264.h | 3 +--
libavcodec/h264_slice.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6e7b940..da7f9dd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -873,7 +873,7 @@ static enum AVPixelFormat
get_pixel_format(H264Context *h, int force_callback)
/* export coded and cropped frame dimensions to AVCodecContext */
static int init_dimensions(H264Context *h)
{
-SPS *sps = h->ps.sps;
+SPS *sps = (SPS*)h->ps.sps_ref->data;
int width = h->width - (sps->crop_right + sps->crop_left);
int height = h->height - (sps->crop_top + sps->crop_bottom);
av_assert0(sps->crop_right + sps->crop_left < (unsigned)h->width);
So it's not actually const, right?
Indeed, the FIXME wasn't just there because someone forgot to write
"const" in front of it, but because it was used in some parts as
not-const.
OK, right... Thanks for reminding me of reading the code better before
sending a patch.
As far as I can see, the only place where this constness is not preserved is
in the init_dimensions function (in h264_slice), in a dead part of the code,
as crop is asserted at the beginning of the very same function.
Please correct me if I've missed other places.
If anything the asserts should probably be removed, because bad files
should never be able to trigger assertions, and the existing check
remain.
Well, the SPS "decoder" already takes care of the check (see
ff_h264_decode_seq_parameter_set).
So I could remove the check, because it seems useless, instead of
removing it because "bad things happen", what do you think?
Thanks,
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
Hi,
On 21/06/2016 16:42, Benoit Fouet wrote:
Hi,
On 21/06/2016 16:29, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 4:20 PM, Benoit Fouet
wrote:
Hi,
On 21/06/2016 14:52, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 2:40 PM, Clément Bœsch wrote:
On Tue, Jun 21, 2016 at 02:34:33PM +0200, Benoit Fouet wrote:
Hi,
Unless I totally missed something, the FIXME in H264ParamSets
structure
should be fixed by attached patch.
--
Ben
From 28ae10498f81070539bdb8f40236326743350101 Mon Sep 17
00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const
---
libavcodec/h264.h | 3 +--
libavcodec/h264_slice.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6e7b940..da7f9dd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -873,7 +873,7 @@ static enum AVPixelFormat
get_pixel_format(H264Context *h, int force_callback)
/* export coded and cropped frame dimensions to AVCodecContext */
static int init_dimensions(H264Context *h)
{
-SPS *sps = h->ps.sps;
+SPS *sps = (SPS*)h->ps.sps_ref->data;
int width = h->width - (sps->crop_right + sps->crop_left);
int height = h->height - (sps->crop_top +
sps->crop_bottom);
av_assert0(sps->crop_right + sps->crop_left <
(unsigned)h->width);
So it's not actually const, right?
Indeed, the FIXME wasn't just there because someone forgot to write
"const" in front of it, but because it was used in some parts as
not-const.
OK, right... Thanks for reminding me of reading the code better before
sending a patch.
As far as I can see, the only place where this constness is not
preserved is
in the init_dimensions function (in h264_slice), in a dead part of
the code,
as crop is asserted at the beginning of the very same function.
Please correct me if I've missed other places.
If anything the asserts should probably be removed, because bad files
should never be able to trigger assertions, and the existing check
remain.
Well, the SPS "decoder" already takes care of the check (see
ff_h264_decode_seq_parameter_set).
So I could remove the check, because it seems useless, instead of
removing it because "bad things happen", what do you think?
Any objection to this patch now?
Thanks,
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
Hi,
On 23/06/2016 22:37, Michael Niedermayer wrote:
On Thu, Jun 23, 2016 at 03:28:10PM +0200, Benoit Fouet wrote:
Hi,
On 21/06/2016 16:42, Benoit Fouet wrote:
Hi,
On 21/06/2016 16:29, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 4:20 PM, Benoit Fouet
wrote:
Hi,
On 21/06/2016 14:52, Hendrik Leppkes wrote:
On Tue, Jun 21, 2016 at 2:40 PM, Clément Bœsch wrote:
On Tue, Jun 21, 2016 at 02:34:33PM +0200, Benoit Fouet wrote:
Hi,
Unless I totally missed something, the FIXME in
H264ParamSets structure
should be fixed by attached patch.
--
Ben
From 28ae10498f81070539bdb8f40236326743350101 Mon Sep
17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH] h264: make H264ParamSets sps const
---
libavcodec/h264.h | 3 +--
libavcodec/h264_slice.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index c4d2921..b809ee5 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 6e7b940..da7f9dd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -873,7 +873,7 @@ static enum AVPixelFormat
get_pixel_format(H264Context *h, int force_callback)
/* export coded and cropped frame dimensions to AVCodecContext */
static int init_dimensions(H264Context *h)
{
-SPS *sps = h->ps.sps;
+SPS *sps = (SPS*)h->ps.sps_ref->data;
int width = h->width - (sps->crop_right + sps->crop_left);
int height = h->height - (sps->crop_top +
sps->crop_bottom);
av_assert0(sps->crop_right + sps->crop_left <
(unsigned)h->width);
So it's not actually const, right?
Indeed, the FIXME wasn't just there because someone forgot to write
"const" in front of it, but because it was used in some parts as
not-const.
OK, right... Thanks for reminding me of reading the code better before
sending a patch.
As far as I can see, the only place where this constness is
not preserved is
in the init_dimensions function (in h264_slice), in a dead
part of the code,
as crop is asserted at the beginning of the very same function.
Please correct me if I've missed other places.
If anything the asserts should probably be removed, because bad files
should never be able to trigger assertions, and the existing check
remain.
Well, the SPS "decoder" already takes care of the check (see
ff_h264_decode_seq_parameter_set).
So I could remove the check, because it seems useless, instead of
removing it because "bad things happen", what do you think?
Any objection to this patch now?
iam ok with the patch, maybe give others a bit of time to reply
before applying though
Yeah, I'm in no hurry, I just saw this FIXME in the context of one of
Mateo's patches.
I was more waiting for some feedback from Hendrik or Clément, anyway, as
they were the ones raising the points.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: drop people who do not appear in git history > 2013
onrad - libvorbis.c David Conrad libvpx* James Zern - libxavs.c Stefan Gehrer libzvbi-teletextdec.c Marton Balint lzo.h, lzo.c Reimar Doeffinger mdec.cMichael Niedermayer @@ -201,56 +178,34 @@ Codecs: mpegvideo.c, mpegvideo.h Michael Niedermayer mqc* Nicolas Bertrand msmpeg4.c, msmpeg4data.h Michael Niedermayer - msrle.c Mike Melanson - msvideo1.cMike Melanson nuv.c Reimar Doeffinger nvenc*Timo Rothenpieler paf.* Paul B Mahol - pcx.c Ivo van Poorten pgssubdec.c Reimar Doeffinger - ptx.c Ivo van Poorten qcelp*Reynaldo H. Verdejo Pinochet qdm2.c, qdm2data.hRoberto Togni qsv* Ivan Uskov - qtrle.c Mike Melanson ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni resample2.c Michael Niedermayer - rl2.c Sascha Sommer rpza.cRoberto Togni rtjpeg.c, rtjpeg.hReimar Doeffinger rv10.cMichael Niedermayer rv4* Christophe Gisquet - s3tc* Ivo van Poorten - smc.c Mike Melanson smvjpegdec.c Ash Hughes snow* Michael Niedermayer, Loren Merritt - sonic.c Alex Beregszaszi - srt* Aurelien Jacobs - sunrast.c Ivo van Poorten svq3.cMichael Niedermayer tak* Paul B Mahol - truemotion1* Mike Melanson - tta.c Alex Beregszaszi, Jaikrishnan Menon ttaenc.c Paul B Mahol - txd.c Ivo van Poorten vc1* Christophe Gisquet vc2* Rostislav Pehlivanov vcr1.cMichael Niedermayer vda_h264_dec.cXidorn Quan videotoolboxenc.c Rick Kern vima.cPaul B Mahol - vorbisdec.c Denes Balatoni, David Conrad - vorbisenc.c Oded Shimon - vp3* Mike Melanson - vp5 Aurelien Jacobs - vp6 Aurelien Jacobs - vp8 David Conrad, Ronald Bultje + vp8 Ronald Bultje vp9 Ronald Bultje - vqavideo.cMike Melanson - wmaprodec.c Sascha Sommer wmavoice.cRonald S. Bultje wmv2.cMichael Niedermayer - xan.c Mike Melanson xbm* Paul B Mahol xface Stefano Sabatini xvmc.cIvan Kalvachev @@ -258,7 +213,7 @@ Codecs: Hardware acceleration: crystalhd.c Philip Langdale - dxva2*Hendrik Leppkes, Laurent Aimar + dxva2*Hendrik Leppkes mediacodec* Matthieu Bouron vaapi*Gwenole Beauchesne vaapi_encode* Mark Thompson @@ -361,14 +316,11 @@ Generic parts: Muxers/Demuxers: - 4xm.c Mike Melanson aadec.c Vesselin Bontchev (vesselin.bontchev at yandex dot com) - adtsenc.c Robert Swain afc.c Paul B Mahol - aiffdec.c Baptiste Coudurier, Matthieu Bouron - aiffenc.c Baptiste Coudurier, Matthieu Bouron + aiffdec.c Matthieu Bouron + aiffenc.c Matthieu Bouron apngdec.c Benoit Fouet - ass* Aurelien Jacobs astdec.c Paul B Mahol astenc.c James Almer avi* Mi
Re: [FFmpeg-devel] [PATCH] h264: make H264ParamSets sps const
Hi, On 25/06/2016 14:15, Clément Bœsch wrote: On Fri, Jun 24, 2016 at 09:20:35AM +0200, Benoit Fouet wrote: [...] Any objection to this patch now? iam ok with the patch, maybe give others a bit of time to reply before applying though Yeah, I'm in no hurry, I just saw this FIXME in the context of one of Mateo's patches. I was more waiting for some feedback from Hendrik or Clément, anyway, as they were the ones raising the points. Should be fine if indeed the following computation: int width = 16 * sps->mb_width; int height = 16 * sps->mb_height * (2 - sps->frame_mbs_only_flag); ...is always correct. Good one. It seems the check that is done today on the height part is not enough. I've also found another place which was writing to the SPS and shouldn't. I'm sending a new patchset for all this. Thanks for the review, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] H264ParamSets: make sps const
Hi, First patch change decode_scaling_matrices function, so that it does not affect the SPS structure it gets, and marks SPS and PPS const in its arguments. Second patch straightens the check for macroblock sizes in ff_h264_decode_seq_parameter_set and removes the unneeded check in H.264 slice init_dimensions. Last patch make SPS const in H264ParamSets and fixes its usages. Cheers, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
From c2606da98ecd04762305734f4f45ca8eaf266459 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 27 Jun 2016 12:00:39 +0200
Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
const {s,p}ps
In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
---
libavcodec/h264_ps.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 943d953..5d4ddea 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -265,8 +265,8 @@ static void decode_scaling_list(GetBitContext *gb, uint8_t
*factors, int size,
}
}
-static void decode_scaling_matrices(GetBitContext *gb, SPS *sps,
-PPS *pps, int is_sps,
+static int decode_scaling_matrices(GetBitContext *gb, const SPS *sps,
+const PPS *pps, int is_sps,
uint8_t(*scaling_matrix4)[16],
uint8_t(*scaling_matrix8)[64])
{
@@ -277,8 +277,9 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS
*sps,
fallback_sps ? sps->scaling_matrix8[0] : default_scaling8[0],
fallback_sps ? sps->scaling_matrix8[3] : default_scaling8[1]
};
+int ret = 0;
if (get_bits1(gb)) {
-sps->scaling_matrix_present |= is_sps;
+ret = is_sps;
decode_scaling_list(gb, scaling_matrix4[0], 16, default_scaling4[0],
fallback[0]);// Intra, Y
decode_scaling_list(gb, scaling_matrix4[1], 16, default_scaling4[0],
scaling_matrix4[0]); // Intra, Cr
decode_scaling_list(gb, scaling_matrix4[2], 16, default_scaling4[0],
scaling_matrix4[1]); // Intra, Cb
@@ -296,6 +297,8 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS
*sps,
}
}
}
+
+return ret;
}
void ff_h264_ps_uninit(H264ParamSets *ps)
@@ -401,7 +404,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb,
AVCodecContext *avctx,
goto fail;
}
sps->transform_bypass = get_bits1(gb);
-decode_scaling_matrices(gb, sps, NULL, 1,
+sps->scaling_matrix_present |= decode_scaling_matrices(gb, sps, NULL,
1,
sps->scaling_matrix4, sps->scaling_matrix8);
} else {
sps->chroma_format_idc = 1;
--
2.9.0.37.g6d523a3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] h264: make H264ParamSets sps const
From 735362df589eb5f8b05063c56862ff18589475ad Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 21 Jun 2016 14:17:13 +0200
Subject: [PATCH 3/3] h264: make H264ParamSets sps const
---
libavcodec/h264.h| 3 +--
libavcodec/h264_parser.c | 2 +-
libavcodec/h264_ps.c | 4 ++--
libavcodec/h264_sei.c| 4 ++--
libavcodec/h264_slice.c | 4 ++--
5 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index efe3555..ce4f8bf 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -234,8 +234,7 @@ typedef struct H264ParamSets {
AVBufferRef *sps_ref;
/* currently active parameters sets */
const PPS *pps;
-// FIXME this should properly be const
-SPS *sps;
+const SPS *sps;
} H264ParamSets;
/**
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index ce4bab2..7af2a8d 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -373,7 +373,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
"non-existing SPS %u referenced\n", p->ps.pps->sps_id);
goto fail;
}
-p->ps.sps = (SPS*)p->ps.sps_list[p->ps.pps->sps_id]->data;
+p->ps.sps = (const SPS*)p->ps.sps_list[p->ps.pps->sps_id]->data;
sps = p->ps.sps;
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 0a97649..fdbe548 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -711,7 +711,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb,
AVCodecContext *avct
H264ParamSets *ps, int bit_length)
{
AVBufferRef *pps_buf;
-SPS *sps;
+const SPS *sps;
unsigned int pps_id = get_ue_golomb(gb);
PPS *pps;
int qp_bd_offset;
@@ -742,7 +742,7 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb,
AVCodecContext *avct
ret = AVERROR_INVALIDDATA;
goto fail;
}
-sps = (SPS*)ps->sps_list[pps->sps_id]->data;
+sps = (const SPS*)ps->sps_list[pps->sps_id]->data;
if (sps->bit_depth_luma > 14) {
av_log(avctx, AV_LOG_ERROR,
"Invalid luma bit depth=%d\n",
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 0bbd7e5..3bdbaa0 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -278,7 +278,7 @@ static int decode_buffering_period(H264SEIBufferingPeriod
*h, GetBitContext *gb,
{
unsigned int sps_id;
int sched_sel_idx;
-SPS *sps;
+const SPS *sps;
sps_id = get_ue_golomb_31(gb);
if (sps_id > 31 || !ps->sps_list[sps_id]) {
@@ -286,7 +286,7 @@ static int decode_buffering_period(H264SEIBufferingPeriod
*h, GetBitContext *gb,
"non-existing SPS %d referenced in buffering period\n", sps_id);
return sps_id > 31 ? AVERROR_INVALIDDATA : AVERROR_PS_NOT_FOUND;
}
-sps = (SPS*)ps->sps_list[sps_id]->data;
+sps = (const SPS*)ps->sps_list[sps_id]->data;
// NOTE: This is really so duplicated in the standard... See H.264, D.1.1
if (sps->nal_hrd_parameters_present_flag) {
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index a470da6..afda9cd 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -356,7 +356,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
h->ps.sps_ref = av_buffer_ref(h1->ps.sps_ref);
if (!h->ps.sps_ref)
return AVERROR(ENOMEM);
-h->ps.sps = (SPS*)h->ps.sps_ref->data;
+h->ps.sps = (const SPS*)h->ps.sps_ref->data;
}
if (need_reinit || !inited) {
@@ -873,7 +873,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h,
int force_callback)
/* export coded and cropped frame dimensions to AVCodecContext */
static int init_dimensions(H264Context *h)
{
-SPS *sps = h->ps.sps;
+const SPS *sps = (const SPS*)h->ps.sps;
int width = h->width - (sps->crop_right + sps->crop_left);
int height = h->height - (sps->crop_top + sps->crop_bottom);
av_assert0(sps->crop_right + sps->crop_left < (unsigned)h->width);
--
2.9.0.37.g6d523a3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] h264: straighten dimensions check
From 91b000bf2e0b01695803c5ef98cfb06590f5f409 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 27 Jun 2016 13:31:21 +0200
Subject: [PATCH 2/3] h264: straighten dimensions check
ff_h264_decode_seq_parameter_set
The MBS only flag was not taken into account when checking macroblock
dimensions.
Also removes the unneeded check in init_dimensions for slices.
---
libavcodec/h264_ps.c| 15 ---
libavcodec/h264_slice.c | 17 -
2 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 5d4ddea..0a97649 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -463,13 +463,6 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb,
AVCodecContext *avctx,
sps->gaps_in_frame_num_allowed_flag = get_bits1(gb);
sps->mb_width = get_ue_golomb(gb) + 1;
sps->mb_height = get_ue_golomb(gb) + 1;
-if ((unsigned)sps->mb_width >= INT_MAX / 16 ||
-(unsigned)sps->mb_height >= INT_MAX / 16 ||
-av_image_check_size(16 * sps->mb_width,
-16 * sps->mb_height, 0, avctx)) {
-av_log(avctx, AV_LOG_ERROR, "mb_width/height overflow\n");
-goto fail;
-}
sps->frame_mbs_only_flag = get_bits1(gb);
if (!sps->frame_mbs_only_flag)
@@ -477,6 +470,14 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb,
AVCodecContext *avctx,
else
sps->mb_aff = 0;
+if ((unsigned)sps->mb_width >= INT_MAX / 16 ||
+(unsigned)sps->mb_height >= INT_MAX / (16 * (2 -
sps->frame_mbs_only_flag)) ||
+av_image_check_size(16 * sps->mb_width,
+16 * sps->mb_height * (2 -
sps->frame_mbs_only_flag), 0, avctx)) {
+av_log(avctx, AV_LOG_ERROR, "mb_width/height overflow\n");
+goto fail;
+}
+
sps->direct_8x8_inference_flag = get_bits1(gb);
#ifndef ALLOW_INTERLACE
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 474400b..a470da6 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -889,23 +889,6 @@ static int init_dimensions(H264Context *h)
height = h->avctx->height;
}
-if (width <= 0 || height <= 0) {
-av_log(h->avctx, AV_LOG_ERROR, "Invalid cropped dimensions: %dx%d.\n",
- width, height);
-if (h->avctx->err_recognition & AV_EF_EXPLODE)
-return AVERROR_INVALIDDATA;
-
-av_log(h->avctx, AV_LOG_WARNING, "Ignoring cropping information.\n");
-sps->crop_bottom =
-sps->crop_top=
-sps->crop_right =
-sps->crop_left =
-sps->crop= 0;
-
-width = h->width;
-height = h->height;
-}
-
h->avctx->coded_width = h->width;
h->avctx->coded_height = h->height;
h->avctx->width= width;
--
2.9.0.37.g6d523a3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
Hi,
On 27/06/2016 18:31, Michael Niedermayer wrote:
On Mon, Jun 27, 2016 at 02:38:50PM +0200, Benoit Fouet wrote:
h264_ps.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
ea8cc471972e1dbaa4f4f03cd7a5fe92a3b848e9
0001-h264_ps-change-decode_scaling_matrices-so-that-it-ta.patch
From c2606da98ecd04762305734f4f45ca8eaf266459 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 27 Jun 2016 12:00:39 +0200
Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
const {s,p}ps
In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
---
libavcodec/h264_ps.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
please document the return value
LGTM otherwise
See if attached patch is OK in that regard.
Thanks,
--
Ben
From 67e714cbdabcb9ed808e8b10c70bbdf670cf3c2d Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 27 Jun 2016 12:00:39 +0200
Subject: [PATCH 1/3] h264_ps: change decode_scaling_matrices so that it takes
const {s,p}ps
In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
---
libavcodec/h264_ps.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 943d953..2f166c5 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -265,8 +265,9 @@ static void decode_scaling_list(GetBitContext *gb, uint8_t
*factors, int size,
}
}
-static void decode_scaling_matrices(GetBitContext *gb, SPS *sps,
-PPS *pps, int is_sps,
+/* returns non zero if the provided SPS scaling matrix has been filled */
+static int decode_scaling_matrices(GetBitContext *gb, const SPS *sps,
+const PPS *pps, int is_sps,
uint8_t(*scaling_matrix4)[16],
uint8_t(*scaling_matrix8)[64])
{
@@ -277,8 +278,9 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS
*sps,
fallback_sps ? sps->scaling_matrix8[0] : default_scaling8[0],
fallback_sps ? sps->scaling_matrix8[3] : default_scaling8[1]
};
+int ret = 0;
if (get_bits1(gb)) {
-sps->scaling_matrix_present |= is_sps;
+ret = is_sps;
decode_scaling_list(gb, scaling_matrix4[0], 16, default_scaling4[0],
fallback[0]);// Intra, Y
decode_scaling_list(gb, scaling_matrix4[1], 16, default_scaling4[0],
scaling_matrix4[0]); // Intra, Cr
decode_scaling_list(gb, scaling_matrix4[2], 16, default_scaling4[0],
scaling_matrix4[1]); // Intra, Cb
@@ -296,6 +298,8 @@ static void decode_scaling_matrices(GetBitContext *gb, SPS
*sps,
}
}
}
+
+return ret;
}
void ff_h264_ps_uninit(H264ParamSets *ps)
@@ -401,7 +405,7 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb,
AVCodecContext *avctx,
goto fail;
}
sps->transform_bypass = get_bits1(gb);
-decode_scaling_matrices(gb, sps, NULL, 1,
+sps->scaling_matrix_present |= decode_scaling_matrices(gb, sps, NULL,
1,
sps->scaling_matrix4, sps->scaling_matrix8);
} else {
sps->chroma_format_idc = 1;
--
2.9.0.37.g6d523a3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] H264ParamSets: make sps const
Hi, On 27/06/2016 14:37, Benoit Fouet wrote: Hi, First patch change decode_scaling_matrices function, so that it does not affect the SPS structure it gets, and marks SPS and PPS const in its arguments. Second patch straightens the check for macroblock sizes in ff_h264_decode_seq_parameter_set and removes the unneeded check in H.264 slice init_dimensions. Last patch make SPS const in H264ParamSets and fixes its usages. I'll apply the patchset in a day or two, if there is no more feedback. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] git: ignore test binaries
From e514644033781cb431641ae088482f5a8aa2de42 Mon Sep 17 00:00:00 2001 From: Benoit Fouet Date: Wed, 29 Jun 2016 17:53:50 +0200 Subject: [PATCH] git: ignore test binaries --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 524fb73..670d1d2 100644 --- a/.gitignore +++ b/.gitignore @@ -19,6 +19,7 @@ *.swp *.ver *_g +*-test \#* .\#* /.config -- 2.9.0.37.g6d523a3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] git: ignore test binaries
Hi, On 29/06/2016 17:57, Clément Bœsch wrote: On Wed, Jun 29, 2016 at 05:54:37PM +0200, Benoit Fouet wrote: From e514644033781cb431641ae088482f5a8aa2de42 Mon Sep 17 00:00:00 2001 From: Benoit Fouet Date: Wed, 29 Jun 2016 17:53:50 +0200 Subject: [PATCH] git: ignore test binaries --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 524fb73..670d1d2 100644 --- a/.gitignore +++ b/.gitignore @@ -19,6 +19,7 @@ *.swp *.ver *_g +*-test \#* .\#* /.config You shouldn't have any, they moved somewhere else without the -test suffix (with the exception of fate api tests which have the proper entry in their own .gitignore) Maybe previously built programs? indeed, dropped. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] H264ParamSets: make sps const
Hi, On 27/06/2016 14:37, Benoit Fouet wrote: Hi, First patch change decode_scaling_matrices function, so that it does not affect the SPS structure it gets, and marks SPS and PPS const in its arguments. Second patch straightens the check for macroblock sizes in ff_h264_decode_seq_parameter_set and removes the unneeded check in H.264 slice init_dimensions. Last patch make SPS const in H264ParamSets and fixes its usages. Patchset pushed -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mediacodecdec_h264: properly convert extradata to annex-b
Hi,
On 04/07/2016 10:12, Matthieu Bouron wrote:
From: Matthieu Bouron
H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
converted to NAL units before sending them to MediaCodec.
This patch adds the missing convertion of the SPS/PPS from SOBP to RBSP
which makes the resulting NAL units correct.
Fixes codec initialization on Nexus 4 and Nexus 7.
---
libavcodec/mediacodecdec_h264.c | 69 +
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 0664e49..f07c7cc 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -65,6 +65,54 @@ static av_cold int mediacodec_decode_close(AVCodecContext
*avctx)
return 0;
}
+static int h264_ps_to_nalu(const uint8_t *src, int src_size, uint8_t **out, int *out_size)
+{
+int i;
+int ret = 0;
+uint8_t *p = NULL;
+static const uint8_t nalu_header[] = { 0x00, 0x00, 0x00, 0x01 };
+
+if (!out) {
+return AVERROR(EINVAL);
+}
+
out_size should also be checked
+*out_size = sizeof(nalu_header) + src_size;
+*out = p = av_malloc(*out_size);
+if (!*out) {
+return AVERROR(ENOMEM);
+}
+
nit: the size affectation could be done once the allocation is OK.
+memcpy(p, nalu_header, sizeof(nalu_header));
+memcpy(p + sizeof(nalu_header), src, src_size);
+
+/* Escape 0x00, 0x00, 0x0{0-3} pattern */
+for (i = 4; i < *out_size; i++) {
+if (i < *out_size - 3 &&
+p[i + 0] == 0 &&
+p[i + 1] == 0 &&
+p[i + 2] <= 3) {
+uint8_t *new;
+
+*out_size += 1;
+new = av_realloc(*out, *out_size);
+if (!new) {
+ret = AVERROR(ENOMEM);
+goto done;
+}
+*out = p = new;
+
+i = i + 3;
+memmove(p + i, p + i - 1, *out_size - i);
+p[i - 1] = 0x03;
+}
+}
+done:
+if (ret < 0)
+av_freep(out);
+
+return ret;
+}
+
static av_cold int mediacodec_decode_init(AVCodecContext *avctx)
{
int i;
@@ -112,24 +160,19 @@ static av_cold int mediacodec_decode_init(AVCodecContext
*avctx)
}
if (pps && sps) {
-static const uint8_t nal_headers[] = { 0x00, 0x00, 0x00, 0x01 };
-
uint8_t *data = NULL;
-size_t data_size = sizeof(nal_headers) + FFMAX(sps->data_size,
pps->data_size);
+size_t data_size = 0;
-data = av_mallocz(data_size);
-if (!data) {
-ret = AVERROR(ENOMEM);
+if ((ret = h264_ps_to_nalu(sps->data, sps->data_size, &data, &data_size))
< 0) {
goto done;
}
+ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data, data_size);
+av_freep(&data);
-memcpy(data, nal_headers, sizeof(nal_headers));
-memcpy(data + sizeof(nal_headers), sps->data, sps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-0", (void*)data,
sizeof(nal_headers) + sps->data_size);
-
-memcpy(data + sizeof(nal_headers), pps->data, pps->data_size);
-ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data,
sizeof(nal_headers) + pps->data_size);
-
+if ((ret = h264_ps_to_nalu(pps->data, pps->data_size, &data, &data_size))
< 0) {
+goto done;
+}
+ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, data_size);
av_freep(&data);
} else {
av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from
extradata");
LGTM otherwise
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add hwaccel support
Hi,
On 07/07/2016 17:43, Matthieu Bouron wrote:
[...]
0001-lavc-add-mediacodec-hwaccel-support.patch
From 9bb86990f0f7a26d25878a771f5977ae83d14769 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron
Date: Fri, 11 Mar 2016 17:21:04 +0100
Subject: [PATCH] lavc: add mediacodec hwaccel support
---
configure | 1 +
libavcodec/Makefile | 6 +-
libavcodec/allcodecs.c | 1 +
libavcodec/mediacodec.c | 133
libavcodec/mediacodec.h | 88 +
libavcodec/mediacodec_surface.c | 66 ++
libavcodec/mediacodec_surface.h | 31 +
libavcodec/mediacodec_wrapper.c | 5 +-
libavcodec/mediacodecdec.c | 270 +---
libavcodec/mediacodecdec.h | 17 +++
libavcodec/mediacodecdec_h264.c | 44 ++-
libavcodec/version.h| 2 +-
libavutil/pixdesc.c | 4 +
libavutil/pixfmt.h | 2 +
14 files changed, 611 insertions(+), 59 deletions(-)
create mode 100644 libavcodec/mediacodec.c
create mode 100644 libavcodec/mediacodec.h
create mode 100644 libavcodec/mediacodec_surface.c
create mode 100644 libavcodec/mediacodec_surface.h
[...]
diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
new file mode 100644
index 000..5b79798
--- /dev/null
+++ b/libavcodec/mediacodec.c
@@ -0,0 +1,133 @@
+/*
+ * Android MediaCodec public API functions
+ *
+ * Copyright (c) 2016 Matthieu Bouron
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#if CONFIG_H264_MEDIACODEC_HWACCEL
+
+#include
+
+#include "libavcodec/avcodec.h"
+#include "libavutil/atomic.h"
+#include "libavutil/mem.h"
+
+#include "ffjni.h"
+#include "mediacodec.h"
+#include "mediacodecdec.h"
+
+AVMediaCodecContext *av_mediacodec_alloc_context(void)
+{
+return av_mallocz(sizeof(AVMediaCodecContext));
+}
+
+int av_mediacodec_default_init(AVCodecContext *avctx, AVMediaCodecContext
*ctx, void *surface)
+{
+int ret = 0;
+JNIEnv *env = NULL;
+int attached = 0;
+
nit: env and attached don't need to be initialized
+env = ff_jni_attach_env(&attached, avctx);
+if (!env) {
+return AVERROR_EXTERNAL;
+}
+
+ctx->surface = (*env)->NewGlobalRef(env, surface);
+if (ctx->surface) {
+avctx->hwaccel_context = ctx;
+} else {
+av_log(avctx, AV_LOG_ERROR, "Could not create new global reference\n");
+ret = AVERROR_EXTERNAL;
+}
+
+if (attached) {
+ff_jni_detach_env(avctx);
+}
+
+return ret;
+}
+
+void av_mediacodec_default_free(AVCodecContext *avctx)
+{
+JNIEnv *env = NULL;
+int attached = 0;
+
ditto
[...]
diff --git a/libavcodec/mediacodec.h b/libavcodec/mediacodec.h
new file mode 100644
index 000..f755bd1
--- /dev/null
+++ b/libavcodec/mediacodec.h
@@ -0,0 +1,88 @@
+/*
+ * Android MediaCodec public API
+ *
+ * Copyright (c) 2016 Matthieu Bouron
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_MEDIACODEC_H
+#define AVCODEC_MEDIACODEC_H
+
+#include "libavcodec/avcodec.h"
+
+/**
+ * This structure holds a reference to a android/view/Surface object that will
+ * be used as output by the decoder.
+ *
+ */
+typedef struct AVMediaCodecContext {
+
+/**
+ * android/view/Surface object reference.
+ */
+void *surface;
+
+} AVMediaCodecContext;
+
+/**
+ * Allocate and initialize a MediaCodec context.
+ *
+ * When decoding with MediaCodec is finished, the caller must free the
+ * MediaC
Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: add hwaccel support
On 08/07/2016 15:40, Matthieu Bouron wrote:
On Fri, Jul 08, 2016 at 01:21:48PM +0200, Benoit Fouet wrote:
Hi,
On 07/07/2016 17:43, Matthieu Bouron wrote:
[...]
0001-lavc-add-mediacodec-hwaccel-support.patch
From 9bb86990f0f7a26d25878a771f5977ae83d14769 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron
Date: Fri, 11 Mar 2016 17:21:04 +0100
Subject: [PATCH] lavc: add mediacodec hwaccel support
---
configure | 1 +
libavcodec/Makefile | 6 +-
libavcodec/allcodecs.c | 1 +
libavcodec/mediacodec.c | 133
libavcodec/mediacodec.h | 88 +
libavcodec/mediacodec_surface.c | 66 ++
libavcodec/mediacodec_surface.h | 31 +
libavcodec/mediacodec_wrapper.c | 5 +-
libavcodec/mediacodecdec.c | 270
+---
libavcodec/mediacodecdec.h | 17 +++
libavcodec/mediacodecdec_h264.c | 44 ++-
libavcodec/version.h| 2 +-
libavutil/pixdesc.c | 4 +
libavutil/pixfmt.h | 2 +
14 files changed, 611 insertions(+), 59 deletions(-)
create mode 100644 libavcodec/mediacodec.c
create mode 100644 libavcodec/mediacodec.h
create mode 100644 libavcodec/mediacodec_surface.c
create mode 100644 libavcodec/mediacodec_surface.h
[...]
diff --git a/libavcodec/mediacodecdec.h b/libavcodec/mediacodecdec.h
index 646b628..8613352 100644
--- a/libavcodec/mediacodecdec.h
+++ b/libavcodec/mediacodecdec.h
@@ -34,12 +34,17 @@
typedef struct MediaCodecDecContext {
+volatile int refcount;
+
I don't think this needs to be marked volatile
The avpriv_atomic_[...] functions take a volatile int *ptr. Also there are
examples in our code base that declare the atomic as volatile int (see
libavutil/buffer_internal.h, libavcodec/mmaldec.c for example). I can
be missing something though.
as the atomic api is working on addresses, it should not make any
difference.
I don't really mind, though, keep it this way if you prefer
I'm not a volatile fan boy, so I try to refrain from using them when
it's not strictly needed :-)
[...]
If you are OK with my comments, I will push the patch.
Yes, sure.
Cheers,
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] SSE2 version of vf_idet's filter_line()
Hi, - Mail original - > Hi, > > > updated patch, sorry for the broken format in the previous one. Hope > it's > ok now. > This is just missing the new header file vf_idet.h -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] libavdevice/v4l2: fix descriptors leak on error paths
Hi, - Mail original - > From: Dmitry Volyntsev > > Signed-off-by: Dmitry Volytnsev > --- > libavdevice/v4l2.c | 37 - > 1 file changed, 20 insertions(+), 17 deletions(-) > > diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c > index 9f9f944..7b9e2f3 100644 > --- a/libavdevice/v4l2.c > +++ b/libavdevice/v4l2.c [...] > @@ -956,6 +955,10 @@ static int v4l2_read_header(AVFormatContext *s1) > st->codec->bit_rate = s->frame_size * > av_q2d(st->avg_frame_rate) * 8; > > return 0; > + > +fail: > +v4l2_close(s->fd); > +return res; > } > > static int v4l2_read_packet(AVFormatContext *s1, AVPacket *pkt) This is not really a 'fail' path when it is reached after listing the formats or the standards. LGTM anyway. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/x11grab: fix error handling in pixel formats
Hi,
- Mail original -
> Signed-off-by: Michael Niedermayer
> ---
> libavdevice/x11grab.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/x11grab.c b/libavdevice/x11grab.c
> index 120f754..e0d1dfa 100644
> --- a/libavdevice/x11grab.c
> +++ b/libavdevice/x11grab.c
> @@ -181,6 +181,8 @@ static int pixfmt_from_image(AVFormatContext *s,
> XImage *image, int *pix_fmt)
> image->blue_mask,
> image->bits_per_pixel);
>
> +*pix_fmt = AV_PIX_FMT_NONE;
> +
> switch (image->bits_per_pixel) {
> case 8:
> *pix_fmt = AV_PIX_FMT_PAL8;
> @@ -214,7 +216,8 @@ static int pixfmt_from_image(AVFormatContext *s,
> XImage *image, int *pix_fmt)
> *pix_fmt = AV_PIX_FMT_0RGB32;
> }
> break;
> -default:
> +}
> +if (*pix_fmt == AV_PIX_FMT_NONE) {
> av_log(s, AV_LOG_ERROR,
> "XImages with RGB mask 0x%.6lx 0x%.6lx 0x%.6lx and
> depth %i "
> "are currently not supported.\n",
LGTM
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tiff: fix {2,4}bpp grayscale palettes.
Create a default grayscale palette for 2 or 4 bpp grayscale tiff, if
there is no palette defined.
Fixes ticket #3915
---
libavcodec/tiff.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 1e2d235..0352639 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -653,6 +653,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
static int init_image(TiffContext *s, ThreadFrame *frame)
{
int ret;
+int create_gray_palette = 0;
switch (s->planar * 1000 + s->bpp * 10 + s->bppcount) {
case 11:
@@ -662,6 +663,11 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
}
case 21:
case 41:
+s->avctx->pix_fmt = AV_PIX_FMT_PAL8;
+if (!s->palette_is_set) {
+create_gray_palette = 1;
+}
+break;
case 81:
s->avctx->pix_fmt = s->palette_is_set ? AV_PIX_FMT_PAL8 :
AV_PIX_FMT_GRAY8;
break;
@@ -741,7 +747,15 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
if ((ret = ff_thread_get_buffer(s->avctx, frame, 0)) < 0)
return ret;
if (s->avctx->pix_fmt == AV_PIX_FMT_PAL8) {
-memcpy(frame->f->data[1], s->palette, sizeof(s->palette));
+if (!create_gray_palette)
+memcpy(frame->f->data[1], s->palette, sizeof(s->palette));
+else {
+/* make default grayscale pal */
+int i;
+uint32_t *pal = (uint32_t *)frame->f->data[1];
+for (i = 0; i < 1
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegvideo: Factor ff_mpv_decode_init() out
Hi, Le 05/09/2014 17:41, Michael Niedermayer a écrit : > Signed-off-by: Michael Niedermayer > --- > libavcodec/h261dec.c |7 ++- > libavcodec/h263dec.c |6 ++ > libavcodec/mpeg12dec.c |3 +-- > libavcodec/mpegvideo.c | 12 > libavcodec/mpegvideo.h |1 + > libavcodec/rv10.c |3 +-- > libavcodec/rv34.c |7 +-- > 7 files changed, 20 insertions(+), 19 deletions(-) LGTM -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpegvideo: set codec tags in ff_mpv_decode_init()
Hi, Le 05/09/2014 17:41, Michael Niedermayer a écrit : > Fixes Ticket3912 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpegvideo.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > LGTM as well -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: Dont autoexeit by default on single images
Hi, Le 07/09/2014 02:16, Michael Niedermayer a écrit : > Signed-off-by: Michael Niedermayer > --- > ffplay.c |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > I'm fine with it in principle (though the commit message should be fixed), but this -1 value should be somewhat documented. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] configure: fix check_cmd in check_host_cpp
Hi,
- Mail original -
> Use correct cpp and c flags variables for the host libc.
>
> Signed-off-by: Jörg Krause
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e66519d..7a711a2 100755
> --- a/configure
> +++ b/configure
> @@ -1244,7 +1244,7 @@ check_host_cpp(){
> log check_host_cpp "$@"
> cat > $TMPC
> log_file $TMPC
> -check_cmd $host_cc $HOSTCPPFLAGS $HOSTCFLAGS "$@" $(hostcc_e
> $TMPO) $TMPC
> +check_cmd $host_cc $host_cppflags $host_cflags "$@" $(hostcc_e
> $TMPO) $TMPC
> }
>
> check_host_cppflags(){
LGTM
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] img2dec: make probing score zero for known file extensions.
When a known extension has its own probing function, make img_read_probe
return 0, so that the probing functions are actually called instead of
relying only on the file extensions.
Fixes issue #3901
---
libavformat/img2dec.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 8bbcddc..0be31c8 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -155,6 +155,26 @@ fail:
return -1;
}
+/* Add entry here when/if a known extension has its own probing function */
+static int ext_has_probe(const char *filename)
+{
+const char extensions[] = "jpg,jpeg,jps,mpo" /*
AV_CODEC_ID_MJPEG */
+ ",jls" /*
AV_CODEC_ID_MJPEG */
+ ",png,pns,mng" /*
AV_CODEC_ID_PNG */
+ ",bmp" /*
AV_CODEC_ID_BMP */
+ ",tiff,tif"/*
AV_CODEC_ID_TIFF */
+ ",sgi" /*
AV_CODEC_ID_SGI */
+ ",sun,ras,rs,im1,im8,im24,im32,sunras" /*
AV_CODEC_ID_SUNRAST */
+ ",j2c,jp2,jpc,j2k" /*
AV_CODEC_ID_JPEG2000 */
+ ",dpx" /*
AV_CODEC_ID_DPX */
+ ",exr" /*
AV_CODEC_ID_EXR */
+ ",pic" /*
AV_CODEC_ID_PICTOR */
+ ",webp"/*
AV_CODEC_ID_WEBP */
+ ",gif" /*
AV_CODEC_ID_GIF */
+ ;
+return av_match_ext(filename, extensions);
+}
+
static int img_read_probe(AVProbeData *p)
{
if (p->filename && ff_guess_image2_codec(p->filename)) {
@@ -162,8 +182,10 @@ static int img_read_probe(AVProbeData *p)
return AVPROBE_SCORE_MAX;
else if (is_glob(p->filename))
return AVPROBE_SCORE_MAX;
-else if (av_match_ext(p->filename, "raw") || av_match_ext(p->filename,
"gif"))
+else if (av_match_ext(p->filename, "raw"))
return 5;
+else if (ext_has_probe(p->filename))
+return 0;
else
return AVPROBE_SCORE_EXTENSION;
}
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/format: Run image2 probe again when file content data is available
Hi,
- Mail original -
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/format.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/format.c b/libavformat/format.c
> index 828ab52..006cc87 100644
> --- a/libavformat/format.c
> +++ b/libavformat/format.c
> @@ -202,7 +202,7 @@ AVInputFormat *av_probe_input_format3(AVProbeData
> *pd, int is_opened,
>
> fmt = NULL;
> while ((fmt1 = av_iformat_next(fmt1))) {
> -if (!is_opened == !(fmt1->flags & AVFMT_NOFILE))
> +if (!is_opened == !(fmt1->flags & AVFMT_NOFILE) &&
> strcmp(fmt1->name, "image2"))
>
Wouldn't it be possible to add for instance another flag that tells this?
AVFMT_PREFER_FILE or something like that (I don't like the name, just proposing
so that what I say is clearer)?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/img2dec: reduce bmppipe probe score
Hi,
- Mail original -
> bmp pipe needs the bmp parser which is not bug free and should thus
> not be favored
> over the bmp image2 demuxer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/img2dec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 8bbcddc..9f48c5d 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -574,7 +574,7 @@ static int bmp_probe(AVProbeData *p)
> return 0;
>
> if (!AV_RN32(b + 6)) {
> -return AVPROBE_SCORE_EXTENSION + 1;
> +return AVPROBE_SCORE_EXTENSION - 1; // lower than extension
> as bmp pipe has bugs
>
No real opinion on this one, do as you prefer...
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] img2dec: make probing score zero for known file extensions.
Hi,
- Mail original -
> On Thu, Sep 11, 2014 at 03:48:21PM +0200, Benoit Fouet wrote:
> > When a known extension has its own probing function, make
> > img_read_probe
> > return 0, so that the probing functions are actually called instead
> > of
> > relying only on the file extensions.
> >
> > Fixes issue #3901
> > ---
> > libavformat/img2dec.c | 24 +++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > index 8bbcddc..0be31c8 100644
> > --- a/libavformat/img2dec.c
> > +++ b/libavformat/img2dec.c
> > @@ -155,6 +155,26 @@ fail:
> > return -1;
> > }
> >
> > +/* Add entry here when/if a known extension has its own probing
> > function */
> > +static int ext_has_probe(const char *filename)
> > +{
> > +const char extensions[] = "jpg,jpeg,jps,mpo"
> > /* AV_CODEC_ID_MJPEG */
> > + ",jls"
> > /* AV_CODEC_ID_MJPEG */
> > + ",png,pns,mng"
> > /* AV_CODEC_ID_PNG */
> > + ",bmp"
> > /* AV_CODEC_ID_BMP */
> > + ",tiff,tif"
> >/* AV_CODEC_ID_TIFF */
> > + ",sgi"
> > /* AV_CODEC_ID_SGI */
> > +
> > ",sun,ras,rs,im1,im8,im24,im32,sunras"
> > /* AV_CODEC_ID_SUNRAST */
> > + ",j2c,jp2,jpc,j2k"
> > /* AV_CODEC_ID_JPEG2000 */
> > + ",dpx"
> > /* AV_CODEC_ID_DPX */
> > + ",exr"
> > /* AV_CODEC_ID_EXR */
> > + ",pic"
> > /* AV_CODEC_ID_PICTOR */
> > + ",webp"
> >/* AV_CODEC_ID_WEBP */
> > + ",gif"
> > /* AV_CODEC_ID_GIF */
> > + ;
> > +return av_match_ext(filename, extensions);
> > +}
>
> keeping this in sync with the probe functions could be unreliable
>
True, though this was the simplest solution I could propose.
> also this fails 2 fate tests.
> one might be fixed by using
> "avformat/img2dec: reduce bmppipe probe score", which ive just posted
> dunno why the 2nd fails
>
If we choose this patch, I'll look into this.
[...]
>
> also see the patchset ive just posted, but iam not totally happy with
> mine either, espeially the special case for image2 kind of looks ugly
>
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avformat/img2dec: Fail probing when no data is yet available and the filename contains no number/glob patterns either.
Hi, - Mail original - > Fixes Ticket3901 > > Signed-off-by: Michael Niedermayer > --- > libavformat/img2dec.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c > index 9f48c5d..a21429f 100644 > --- a/libavformat/img2dec.c > +++ b/libavformat/img2dec.c > @@ -162,6 +162,8 @@ static int img_read_probe(AVProbeData *p) > return AVPROBE_SCORE_MAX; > else if (is_glob(p->filename)) > return AVPROBE_SCORE_MAX; > +else if (p->buf_size == 0) > +return 0; > else if (av_match_ext(p->filename, "raw") || > av_match_ext(p->filename, "gif")) > return 5; > else > LGTM -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat: add AVFMT_FILE to allow demuxers to be used with and without files
Hi,
- Mail original -
> On Fri, 12 Sep 2014 12:29:36 +0200
> Michael Niedermayer wrote:
>
> > Suggested-by: Benoit Fouet
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/APIchanges |3 +++
> > libavformat/avformat.h |8
> > libavformat/format.c |3 ++-
> > libavformat/version.h |4 ++--
> > 4 files changed, 15 insertions(+), 3 deletions(-)
> >
[...]
> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > index b915148..a95d702 100644
> > --- a/libavformat/avformat.h
> > +++ b/libavformat/avformat.h
> > @@ -446,6 +446,14 @@ typedef struct AVProbeData {
> >
> > #define AVFMT_SEEK_TO_PTS 0x400 /**< Seeking is based on PTS
> > */
> >
> > +#define AVFMT_FILE 0x800 /**< demuxer can be used
> > with a file, this
> > + is default if
> > AVFMT_NOFILE is not set.
>
> It's default, but it's not set? That's very strange.
>
> > + If AVFMT_NOFILE and
> > AVFMT_FILE is set
> > + then the demuxer can be
> > used with and
> > + without a file (so this
> > flag makes
> > + only sense together
> > with AVFMT_NOFILE)
>
> Very confusing. Without knowing the context (hack for img2 stuff) I
> wouldn't know what this means.
>
> I think I would prefer the previous patch, which just special-cases
> image2. image2 probing should be fixed eventually, and it'd be better
> not to add strange API artifacts just because we're not there yet.
>
Now that I see this patch, I agree. Let's just add a hack for image2 in the
probe function and be done with it...
You're right about the fact that only image2 probing is weird (as Michael
explained) and we shouldn't add such a thing just for that.
Sorry Michael for having you lose some time to put this in place.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/format: Run image2 probe again when file content data is available
Hi,
- Mail original -
> On Fri, Sep 12, 2014 at 10:13:20AM +0200, Benoit Fouet wrote:
> > Hi,
> >
> > - Mail original -
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/format.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/format.c b/libavformat/format.c
> > > index 828ab52..006cc87 100644
> > > --- a/libavformat/format.c
> > > +++ b/libavformat/format.c
> > > @@ -202,7 +202,7 @@ AVInputFormat
> > > *av_probe_input_format3(AVProbeData
> > > *pd, int is_opened,
> > >
> > > fmt = NULL;
> > > while ((fmt1 = av_iformat_next(fmt1))) {
> > > -if (!is_opened == !(fmt1->flags & AVFMT_NOFILE))
> > > +if (!is_opened == !(fmt1->flags & AVFMT_NOFILE) &&
> > > strcmp(fmt1->name, "image2"))
> > >
> >
> > Wouldn't it be possible to add for instance another flag that tells
> > this?
> > AVFMT_PREFER_FILE or something like that (I don't like the name,
> > just proposing so that what I say is clearer)?
>
> great idea, patch posted
>
OK, as stated in the other patch thread, I no more agree with myself :-)
So this one LGTM right now.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/img2: remove useless 'pix' duplicated entry.
The second entry will never be selected, so let's save some bytes in the
library.
---
libavformat/img2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/img2.c b/libavformat/img2.c
index 8002054..d6f1244 100644
--- a/libavformat/img2.c
+++ b/libavformat/img2.c
@@ -57,7 +57,6 @@ static const IdStrMap img_tags[] = {
{ AV_CODEC_ID_TIFF, "tif" },
{ AV_CODEC_ID_SGI,"sgi" },
{ AV_CODEC_ID_PTX,"ptx" },
-{ AV_CODEC_ID_BRENDER_PIX,"pix" },
{ AV_CODEC_ID_PCX,"pcx" },
{ AV_CODEC_ID_SUNRAST,"sun" },
{ AV_CODEC_ID_SUNRAST,"ras" },
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/avidec: assumes that extradata begins with palette when bpp <= 8.
Some other information is stored in extradata, such that the BottomUp field. But it seems that extradata always starts with the palette. Fixes ticket #1304 --- libavformat/avidec.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavformat/avidec.c b/libavformat/avidec.c index 5b260e2..6292952 100644 --- a/libavformat/avidec.c +++ b/libavformat/avidec.c @@ -745,7 +745,7 @@ static int avi_read_header(AVFormatContext *s) avio_r8(pb); /* Extract palette from extradata if bpp <= 8. - * This code assumes that extradata contains only palette. + * This code assumes that extradata begins with palette. * This is true for all paletted codecs implemented in * FFmpeg. */ if (st->codec->extradata_size && @@ -754,8 +754,7 @@ static int avi_read_header(AVFormatContext *s) const uint8_t *pal_src; pal_size = FFMIN(pal_size, st->codec->extradata_size); -pal_src = st->codec->extradata + - st->codec->extradata_size - pal_size; +pal_src = st->codec->extradata; for (i = 0; i < pal_size / 4; i++) ast->pal[i] = 0xFFU<<24 | AV_RL32(pal_src+4*i); ast->has_pal = 1; -- 2.1.0.127.g0c72b98 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Considering the palette is located at the end of extradata may be flawed when the extradata contains the palette followed by the BottomUp field. When the BottomUp field is present, exclude it from the palette. Fixes ticket #1304 --- libavformat/avidec.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/avidec.c b/libavformat/avidec.c index 5b260e2..f7b15b7 100644 --- a/libavformat/avidec.c +++ b/libavformat/avidec.c @@ -756,6 +756,10 @@ static int avi_read_header(AVFormatContext *s) pal_size = FFMIN(pal_size, st->codec->extradata_size); pal_src = st->codec->extradata + st->codec->extradata_size - pal_size; +/* Exclude the "BottomUp" field from the palette */ +if (pal_src - st->codec->extradata >= 9 && +!memcmp(st->codec->extradata + st->codec->extradata_size - 9, "BottomUp", 9)) +pal_src -= 9; for (i = 0; i < pal_size / 4; i++) ast->pal[i] = 0xFFU<<24 | AV_RL32(pal_src+4*i); ast->has_pal = 1; -- 2.1.0.127.g0c72b98 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/img2: remove useless 'pix' duplicated entry.
ping?
- Mail original -
> The second entry will never be selected, so let's save some bytes in
> the
> library.
> ---
> libavformat/img2.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/img2.c b/libavformat/img2.c
> index 8002054..d6f1244 100644
> --- a/libavformat/img2.c
> +++ b/libavformat/img2.c
> @@ -57,7 +57,6 @@ static const IdStrMap img_tags[] = {
> { AV_CODEC_ID_TIFF, "tif" },
> { AV_CODEC_ID_SGI,"sgi" },
> { AV_CODEC_ID_PTX,"ptx" },
> -{ AV_CODEC_ID_BRENDER_PIX,"pix" },
> { AV_CODEC_ID_PCX,"pcx" },
> { AV_CODEC_ID_SUNRAST,"sun" },
> { AV_CODEC_ID_SUNRAST,"ras" },
> --
> 2.1.0.127.g0c72b98
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
> On Mon, Sep 22, 2014 at 09:57:37AM +0200, Benoit Fouet wrote:
> > Considering the palette is located at the end of extradata may be
> > flawed
> > when the extradata contains the palette followed by the BottomUp
> > field.
> > When the BottomUp field is present, exclude it from the palette.
> > Fixes ticket #1304
> > ---
> > libavformat/avidec.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> > index 5b260e2..f7b15b7 100644
> > --- a/libavformat/avidec.c
> > +++ b/libavformat/avidec.c
> > @@ -756,6 +756,10 @@ static int avi_read_header(AVFormatContext *s)
> > pal_size = FFMIN(pal_size,
> > st->codec->extradata_size);
> > pal_src = st->codec->extradata +
> > st->codec->extradata_size -
> > pal_size;
> > +/* Exclude the "BottomUp" field from the
> > palette */
> > +if (pal_src - st->codec->extradata >= 9 &&
> > +!memcmp(st->codec->extradata +
> > st->codec->extradata_size - 9, "BottomUp", 9))
> > +pal_src -= 9;
> > for (i = 0; i < pal_size / 4; i++)
> > ast->pal[i] = 0xFFU<<24 |
> > AV_RL32(pal_src+4*i);
> > ast->has_pal = 1;
>
> applied
>
> though i suspect this only fixes demuxing/decoding of remuxed files
> with ffmpeg/ffplay.
> I suspect the remuxed files still wont play with the official
> avi/rawvideo code from MS or whatever the "reference" code would be
>
I also have a "fix" for the muxer, though I'm still trying to see what the
consequences of such a patch could be...
See attached.
--
Ben
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index c9d8b7f..2855293 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -299,6 +299,13 @@ static int avi_write_header(AVFormatContext *s)
avio_wl32(pb, au_ssize); /* sample size */
avio_wl32(pb, 0);
avio_wl16(pb, enc->width);
+if ( enc->extradata_size >= 9
+&& !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9)) {
+enc->height = -enc->height;
+enc->extradata_size -= 9;
+if (!enc->extradata_size)
+av_freep(&enc->extradata);
+}
avio_wl16(pb, enc->height);
ff_end_tag(pb, strh);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
> On Mon, Sep 22, 2014 at 11:28:31AM +0200, Benoit Fouet wrote:
> > Hi,
> >
> > - Mail original -
> > > On Mon, Sep 22, 2014 at 09:57:37AM +0200, Benoit Fouet wrote:
> > > > Considering the palette is located at the end of extradata may
> > > > be
> > > > flawed
> > > > when the extradata contains the palette followed by the
> > > > BottomUp
> > > > field.
> > > > When the BottomUp field is present, exclude it from the
> > > > palette.
> > > > Fixes ticket #1304
> > > > ---
> > > > libavformat/avidec.c | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/libavformat/avidec.c b/libavformat/avidec.c
> > > > index 5b260e2..f7b15b7 100644
> > > > --- a/libavformat/avidec.c
> > > > +++ b/libavformat/avidec.c
> > > > @@ -756,6 +756,10 @@ static int avi_read_header(AVFormatContext
> > > > *s)
> > > > pal_size = FFMIN(pal_size,
> > > > st->codec->extradata_size);
> > > > pal_src = st->codec->extradata +
> > > > st->codec->extradata_size -
> > > > pal_size;
> > > > +/* Exclude the "BottomUp" field from
> > > > the
> > > > palette */
> > > > +if (pal_src - st->codec->extradata >=
> > > > 9 &&
> > > > +!memcmp(st->codec->extradata +
> > > > st->codec->extradata_size - 9, "BottomUp", 9))
> > > > +pal_src -= 9;
> > > > for (i = 0; i < pal_size / 4; i++)
> > > > ast->pal[i] = 0xFFU<<24 |
> > > > AV_RL32(pal_src+4*i);
> > > > ast->has_pal = 1;
> > >
> > > applied
> > >
> > > though i suspect this only fixes demuxing/decoding of remuxed
> > > files
> > > with ffmpeg/ffplay.
> > > I suspect the remuxed files still wont play with the official
> > > avi/rawvideo code from MS or whatever the "reference" code would
> > > be
> > >
> >
> > I also have a "fix" for the muxer, though I'm still trying to see
> > what the consequences of such a patch could be...
> > See attached.
> >
> > --
> > Ben
> >
>
> > avienc.c |7 +++
> > 1 file changed, 7 insertions(+)
> > 8ae96276e07eb00474ab2115f9ff9c3d0f690723 avienc.diff
> > diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> > index c9d8b7f..2855293 100644
> > --- a/libavformat/avienc.c
> > +++ b/libavformat/avienc.c
> > @@ -299,6 +299,13 @@ static int avi_write_header(AVFormatContext
> > *s)
> > avio_wl32(pb, au_ssize); /* sample size */
> > avio_wl32(pb, 0);
> > avio_wl16(pb, enc->width);
> > +if ( enc->extradata_size >= 9
> > +&& !memcmp(enc->extradata + enc->extradata_size - 9,
> > "BottomUp", 9)) {
> > +enc->height = -enc->height;
>
> i think its safer not to change AVCodecContext.height and just change
> the in the bitstream stored value instead
>
The issue when doing this is that the BITMAPINFOHEADER is wrong. Sop the image
is still flipped.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/img2dec: fix glob pattern detection.
The is_glob() function was not working with unescaped glob patterns,
which is the way only glob_sequence (which is deprecated) works.
Fixes ticket #3948
---
libavformat/img2dec.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index a21429f..64ebc31 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -75,19 +75,7 @@ static int infer_size(int *width_ptr, int *height_ptr, int
size)
static int is_glob(const char *path)
{
#if HAVE_GLOB
-size_t span = 0;
-const char *p = path;
-
-while (p = strchr(p, '%')) {
-if (*(++p) == '%') {
-++p;
-continue;
-}
-if (span = strspn(p, "*?[]{}"))
-break;
-}
-/* Did we hit a glob char or get to the end? */
-return span != 0;
+return strspn(path, "%*?[]{}") != 0;
#else
return 0;
#endif
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
[...]
> > > > avienc.c |7 +++
> > > > 1 file changed, 7 insertions(+)
> > > > 8ae96276e07eb00474ab2115f9ff9c3d0f690723 avienc.diff
> > > > diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> > > > index c9d8b7f..2855293 100644
> > > > --- a/libavformat/avienc.c
> > > > +++ b/libavformat/avienc.c
> > > > @@ -299,6 +299,13 @@ static int
> > > > avi_write_header(AVFormatContext
> > > > *s)
> > > > avio_wl32(pb, au_ssize); /* sample size */
> > > > avio_wl32(pb, 0);
> > > > avio_wl16(pb, enc->width);
> > > > +if ( enc->extradata_size >= 9
> > > > +&& !memcmp(enc->extradata + enc->extradata_size -
> > > > 9,
> > > > "BottomUp", 9)) {
> > > > +enc->height = -enc->height;
> > >
> > > i think its safer not to change AVCodecContext.height and just
> > > change
> > > the in the bitstream stored value instead
> > >
> >
> > The issue when doing this is that the BITMAPINFOHEADER is wrong.
> > So the image is still flipped.
>
> Well then you need a local variable/array or value in the avi muxer
> context. values in AVCodecContext shouldnt really be randomly
> be overwritten by the muxer
>
The only thing that is needed is to extend ff_put_bmp_header, so that it can be
asked to negate height in the BITMAPINFOHEADER header.
Would that be OK?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
> Hi,
>
> - Mail original -
>
> [...]
>
> > > > > avienc.c |7 +++
> > > > > 1 file changed, 7 insertions(+)
> > > > > 8ae96276e07eb00474ab2115f9ff9c3d0f690723 avienc.diff
> > > > > diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> > > > > index c9d8b7f..2855293 100644
> > > > > --- a/libavformat/avienc.c
> > > > > +++ b/libavformat/avienc.c
> > > > > @@ -299,6 +299,13 @@ static int
> > > > > avi_write_header(AVFormatContext
> > > > > *s)
> > > > > avio_wl32(pb, au_ssize); /* sample size */
> > > > > avio_wl32(pb, 0);
> > > > > avio_wl16(pb, enc->width);
> > > > > +if ( enc->extradata_size >= 9
> > > > > +&& !memcmp(enc->extradata + enc->extradata_size
> > > > > -
> > > > > 9,
> > > > > "BottomUp", 9)) {
> > > > > +enc->height = -enc->height;
> > > >
> > > > i think its safer not to change AVCodecContext.height and just
> > > > change
> > > > the in the bitstream stored value instead
> > > >
> > >
> > > The issue when doing this is that the BITMAPINFOHEADER is wrong.
> > > So the image is still flipped.
> >
> > Well then you need a local variable/array or value in the avi muxer
> > context. values in AVCodecContext shouldnt really be randomly
> > be overwritten by the muxer
> >
>
> The only thing that is needed is to extend ff_put_bmp_header, so that
> it can be asked to negate height in the BITMAPINFOHEADER header.
> Would that be OK?
>
Here is a patch to illustrate this...
From 27491a189f2e9d0964b4a896fa515185f0e0ac36 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 23 Sep 2014 10:07:10 +0200
Subject: [PATCH] avformat/riffenc: extend ff_put_bmp_header to be able to
force height to not be changed.
When stream copying, height shouldn't be changed when writing the
BITMAPINFOHEADER header if the BottomUp information is present in the
extardata.
---
libavformat/asfenc.c | 2 +-
libavformat/avienc.c | 12 ++--
libavformat/matroskaenc.c | 2 +-
libavformat/riff.h| 2 +-
libavformat/riffenc.c | 4 ++--
libavformat/wtvenc.c | 2 +-
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/libavformat/asfenc.c b/libavformat/asfenc.c
index fbf6158..dd48e85 100644
--- a/libavformat/asfenc.c
+++ b/libavformat/asfenc.c
@@ -556,7 +556,7 @@ static int asf_write_header1(AVFormatContext *s, int64_t file_size,
avio_wl16(pb, 40 + enc->extradata_size); /* size */
/* BITMAPINFOHEADER header */
-ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 1, 0);
+ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 1, 0, 0);
}
end_header(pb, hpos);
}
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index c9d8b7f..e73b6b2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -313,14 +313,21 @@ static int avi_write_header(AVFormatContext *s)
* are not (yet) supported. */
if (enc->codec_id != AV_CODEC_ID_XSUB)
break;
-case AVMEDIA_TYPE_VIDEO:
+case AVMEDIA_TYPE_VIDEO: {
+int keep_height = enc->extradata_size >= 9
+ && !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
/* WMP expects RGB 5:5:5 rawvideo in avi to have bpp set to 16. */
if ( !enc->codec_tag
&& enc->codec_id == AV_CODEC_ID_RAWVIDEO
&& enc->pix_fmt == AV_PIX_FMT_RGB555LE
&& enc->bits_per_coded_sample == 15)
enc->bits_per_coded_sample = 16;
-ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
+if (keep_height) {
+enc->extradata_size -= 9;
+if (!enc->extradata_size)
+av_freep(&enc->extradata);
+}
+ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0, keep_height);
pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
enc->bits_per_coded_sample);
if ( !enc->codec_tag
@@ -330,6 +337,7 @@ static int avi_write_header(AVFormatContext *s)
av_log(s, AV_LOG_ERROR, "%s rawvideo cannot be written to avi, output file will be unreadable\n",
av_ge
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
> On Tue, Sep 23, 2014 at 10:19:17AM +0200, Benoit Fouet wrote:
> > Here is a patch to illustrate this...
>
> this looks better but:
>
>
> [...]
> > -ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0,
> > 0);
> > +if (keep_height) {
> > +enc->extradata_size -= 9;
> > +if (!enc->extradata_size)
> > +av_freep(&enc->extradata);
> > +}
>
> what if extradata is stored in 2 files, the 2nd muxer would no longer
> see it
> also the muxer shouldnt change the encoders/demuxer extradata
>
> and cant all this logic be put in ff_put_bmp_header() ?
> might even be simpler
>
Do you mean that ff_put_bmp_header() would check for the BottomUp presence and
not negate height in this case, and also only write the palette in the stream?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
> Hi,
>
> - Mail original -
> > On Tue, Sep 23, 2014 at 10:19:17AM +0200, Benoit Fouet wrote:
>
> > > Here is a patch to illustrate this...
> >
> > this looks better but:
> >
> >
> > [...]
> > > -ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0,
> > > 0);
> > > +if (keep_height) {
> > > +enc->extradata_size -= 9;
> > > +if (!enc->extradata_size)
> > > +av_freep(&enc->extradata);
> > > +}
> >
> > what if extradata is stored in 2 files, the 2nd muxer would no
> > longer
> > see it
> > also the muxer shouldnt change the encoders/demuxer extradata
> >
> > and cant all this logic be put in ff_put_bmp_header() ?
> > might even be simpler
> >
>
> Do you mean that ff_put_bmp_header() would check for the BottomUp
> presence and not negate height in this case, and also only write the
> palette in the stream?
>
Patch attached, just in case this is what you meant...
From b8c8f07555769215af7a10c48e7a479f783a7c49 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 23 Sep 2014 10:07:10 +0200
Subject: [PATCH] avformat/riffenc: extend ff_put_bmp_header to be able to
force height to not be changed.
When stream copying, height shouldn't be changed when writing the
BITMAPINFOHEADER header if the BottomUp information is present in the
extradata.
---
libavformat/riffenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index ef4d399..f1a2274 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -209,11 +209,13 @@ int ff_put_wav_header(AVIOContext *pb, AVCodecContext *enc, int flags)
void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
const AVCodecTag *tags, int for_asf, int ignore_extradata)
{
+int keep_height = enc->extradata_size >= 9 &&
+ !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
/* size */
avio_wl32(pb, 40 + (ignore_extradata ? 0 : enc->extradata_size));
avio_wl32(pb, enc->width);
//We always store RGB TopDown
-avio_wl32(pb, enc->codec_tag ? enc->height : -enc->height);
+avio_wl32(pb, enc->codec_tag || keep_height ? enc->height : -enc->height);
/* planes */
avio_wl16(pb, 1);
/* depth */
@@ -227,7 +229,7 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
avio_wl32(pb, 0);
if (!ignore_extradata) {
-avio_write(pb, enc->extradata, enc->extradata_size);
+avio_write(pb, enc->extradata, keep_height ? enc->extradata_size : enc->extradata_size - 9);
if (!for_asf && enc->extradata_size & 1)
avio_w8(pb, 0);
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/avidec: ensure that palette does not contain the BottomUp info.
Hi,
- Mail original -
> On Tue, Sep 23, 2014 at 03:11:58PM +0200, Michael Niedermayer wrote:
> > On Tue, Sep 23, 2014 at 01:33:30PM +0200, Benoit Fouet wrote:
> > > Hi,
> > >
> > > - Mail original -
> > > > Hi,
> > > >
> > > > - Mail original -
> > > > > On Tue, Sep 23, 2014 at 10:19:17AM +0200, Benoit Fouet wrote:
> > > >
> > > > > > Here is a patch to illustrate this...
> > > > >
> > > > > this looks better but:
> > > > >
> > > > >
> > > > > [...]
> > > > > > -ff_put_bmp_header(pb, enc,
> > > > > > ff_codec_bmp_tags, 0,
> > > > > > 0);
> > > > > > +if (keep_height) {
> > > > > > +enc->extradata_size -= 9;
> > > > > > +if (!enc->extradata_size)
> > > > > > +av_freep(&enc->extradata);
> > > > > > +}
> > > > >
> > > > > what if extradata is stored in 2 files, the 2nd muxer would
> > > > > no
> > > > > longer
> > > > > see it
> > > > > also the muxer shouldnt change the encoders/demuxer extradata
> > > > >
> > > > > and cant all this logic be put in ff_put_bmp_header() ?
> > > > > might even be simpler
> > > > >
> > > >
> > > > Do you mean that ff_put_bmp_header() would check for the
> > > > BottomUp
> > > > presence and not negate height in this case, and also only
> > > > write the
> > > > palette in the stream?
> > > >
> > >
> > > Patch attached, just in case this is what you meant...
> >
> > > riffenc.c |6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > d3a93efc5680ad2340086a61ba3d59749f67e770
> > > 0001-avformat-riffenc-extend-ff_put_bmp_header-to-be-able.patch
> > > From b8c8f07555769215af7a10c48e7a479f783a7c49 Mon Sep 17 00:00:00
> > > 2001
> > > From: Benoit Fouet
> > > Date: Tue, 23 Sep 2014 10:07:10 +0200
> > > Subject: [PATCH] avformat/riffenc: extend ff_put_bmp_header to be
> > > able to
> > > force height to not be changed.
> > >
> > > When stream copying, height shouldn't be changed when writing the
> > > BITMAPINFOHEADER header if the BottomUp information is present in
> > > the
> > > extradata.
> > > ---
> > > libavformat/riffenc.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
> > > index ef4d399..f1a2274 100644
> > > --- a/libavformat/riffenc.c
> > > +++ b/libavformat/riffenc.c
> > > @@ -209,11 +209,13 @@ int ff_put_wav_header(AVIOContext *pb,
> > > AVCodecContext *enc, int flags)
> > > void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
> > > const AVCodecTag *tags, int for_asf, int
> > > ignore_extradata)
> > > {
> > > +int keep_height = enc->extradata_size >= 9 &&
> > > + !memcmp(enc->extradata +
> > > enc->extradata_size - 9, "BottomUp", 9);
> > > /* size */
> > > avio_wl32(pb, 40 + (ignore_extradata ? 0 :
> > > enc->extradata_size));
> > > avio_wl32(pb, enc->width);
> > > //We always store RGB TopDown
> > > -avio_wl32(pb, enc->codec_tag ? enc->height : -enc->height);
> > > +avio_wl32(pb, enc->codec_tag || keep_height ? enc->height :
> > > -enc->height);
> > > /* planes */
> > > avio_wl16(pb, 1);
> > > /* depth */
> >
> > > @@ -227,7 +229,7 @@ void ff_put_bmp_header(AVIOContext *pb,
> > > AVCodecContext *enc,
> > > avio_wl32(pb, 0);
> > >
> > > if (!ignore_extradata) {
> > > -avio_write(pb, enc->extradata, enc->extradata_size);
> > > +avio_write(pb, enc->extradata, keep_height ?
> > > enc->extradata_size : enc->extradata_size - 9);
> >
> > this corrupts the stored extradata and breaks fate
>
> fixed and applied
>
> thanks
>
Yes, I swapped the ternary...
Also, do you think it makes sense to revert my previous patch?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: use av_codec_get_pkt_timebase()
Hi,
- Mail original -
> Signed-off-by: Michael Niedermayer
> ---
> ffplay.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ffplay.c b/ffplay.c
> index 6eb5aef..7728452 100644
> --- a/ffplay.c
> +++ b/ffplay.c
> @@ -598,7 +598,7 @@ static int decoder_decode_frame(Decoder *d, void
> *fframe) {
> if (frame->pts != AV_NOPTS_VALUE)
> frame->pts = av_rescale_q(frame->pts,
> d->avctx->time_base, tb);
> else if (frame->pkt_pts != AV_NOPTS_VALUE)
> -frame->pts = av_rescale_q(frame->pkt_pts,
> d->avctx->pkt_timebase, tb);
> +frame->pts = av_rescale_q(frame->pkt_pts,
> av_codec_get_pkt_timebase(d->avctx), tb);
> else if (d->next_pts != AV_NOPTS_VALUE)
> frame->pts = av_rescale_q(d->next_pts,
> d->next_pts_tb, tb);
> if (frame->pts != AV_NOPTS_VALUE) {
>
LGTM
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_mp4toannexb_bsf: always set idr_sps_pps_seen when SPS/PPS is seen.
Hi, - Mail original - > Michael Niedermayer gmx.at> writes: > > > > > On Fri, Aug 01, 2014 at 01:54:14AM +0200, Michael Niedermayer > > wrote: > > > On Thu, Jul 31, 2014 at 03:40:51PM +0200, Benoit Fouet wrote: > > > > In order not to break a sequence like "SPS IDR SPS IDR", the > boolean > > > > telling that the SPS/PPS has been seen should always be set. > > > > --- > > > > libavcodec/h264_mp4toannexb_bsf.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > LGTM > > > > applied > > > > thanks > > A GitHub user "@thomag" commented on this commit: > > > Consider an mp4 files with just pps in the h264 stream (no sps in > > the > > NAL units, but available from avcc). > > In this case 'ctx->idr_sps_pps_seen' prevents inserting sps in the > > extracted h264, which is then unusable. > > FYI. I cannot confirm if it is correct or not, and what the correct > solution would be. > I'm willing to try and fix this when/if we have a sample to test that. If there is also an example with just sps in the avcc and only pps in the stream, that'd be perfect... Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] xtory codec support
Hi, - Mail original - > On Wed, Sep 24, 2014 at 10:21:01AM +0400, I.C. Wiener wrote: > > > > Hello, i have just upload the sample of dxtory 2.0 output file with > > ffmpeg stder dump(in corresponding txt file) to > > ftp://upload.ffmpeg.org/incoming . Please, have a look. Recent > > version of avcodec can not decode it. > > fixed > ref_slice_height is now unused in dxtory_decode_v2_4[12]0 functions, and should be removed. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_mp4toannexb_bsf: always set idr_sps_pps_seen when SPS/PPS is seen.
Hi, Le 26/09/2014 18:38, Michael Niedermayer a écrit : > On Fri, Sep 26, 2014 at 09:27:01AM +0200, Benoit Fouet wrote: >> Hi, >> >> - Mail original - >>> Michael Niedermayer gmx.at> writes: >>> >>>> >>>> On Fri, Aug 01, 2014 at 01:54:14AM +0200, Michael Niedermayer >>>> wrote: >>>>> On Thu, Jul 31, 2014 at 03:40:51PM +0200, Benoit Fouet wrote: >>>>>> In order not to break a sequence like "SPS IDR SPS IDR", the >>> boolean >>>>>> telling that the SPS/PPS has been seen should always be set. >>>>>> --- >>>>>> libavcodec/h264_mp4toannexb_bsf.c | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> LGTM >>>> >>>> applied >>>> >>>> thanks >>> >>> A GitHub user "@thomag" commented on this commit: >>> >>>> Consider an mp4 files with just pps in the h264 stream (no sps in >>>> the >>>> NAL units, but available from avcc). >>>> In this case 'ctx->idr_sps_pps_seen' prevents inserting sps in the >>>> extracted h264, which is then unusable. >>> >>> FYI. I cannot confirm if it is correct or not, and what the correct >>> solution would be. >>> >> >> I'm willing to try and fix this when/if we have a sample to test that. >> If there is also an example with just sps in the avcc and only pps in the stream, that'd be perfect... > > forwarding from github > > Michael, > Here is a short clip @ https://s3.amazonaws.com/quickfire-public/dwclip2.mp4 > which has just PPS in the h264 stream. > Please let me know if you need anything else. > Regards, > Thomas. > OK, cool. I'll have a look at this after the weekend then. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Do not add palette size to the bitmapheader size
Hi, - Mail original - > On Monday 29 September 2014 01:22:38 am Carl Eugen Hoyos wrote: > > Attached patch is the first part of the fix for ticket #1304. > > New, tested patch attached. > > Please comment, Carl Eugen > LGTM, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Set the rawvideo image size to 0 in the bitmapinfoheader
Hi, - Mail original - > On Monday 29 September 2014 01:30:44 am Carl Eugen Hoyos wrote: > > Attached patch fixes ticket #1304: biSizeImage may be 0 for images > > with > > codec tag 0, if the size is set too small, WMP refuses to play the > > file. > > Patch with changes to fate attached. > LGTM too -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/utils: Fix off by 1 error causing unneeded allocation in ff_fast_malloc()
Hi,
- Mail original -
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/utils.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index b27f918..9eb2b5b 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -122,7 +122,7 @@ static void *avformat_mutex;
> static inline int ff_fast_malloc(void *ptr, unsigned int *size,
> size_t min_size, int zero_realloc)
> {
> void **p = ptr;
> -if (min_size < *size)
> +if (min_size <= *size && *p)
> return 0;
> min_size = FFMAX(17 * min_size / 16 + 32, min_size);
> av_free(*p);
>
LGTM
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/put_bits: Add rebase_put_bits()
Hi,
- Mail original -
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/put_bits.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
> index 8081fb9..f16d04a 100644
> --- a/libavcodec/put_bits.h
> +++ b/libavcodec/put_bits.h
> @@ -63,6 +63,23 @@ static inline void init_put_bits(PutBitContext *s,
> uint8_t *buffer,
> }
>
> /**
> + * Rebase the bit writer onto a reallocted buffer.
> + *
>
reallocated
Also, IMHO, it should be mentioned that the new buffer has to be larger than
the previous one.
> + * @param buffer the buffer where to put bits
> + * @param buffer_size the size in bytes of buffer
> + */
> +static inline void rebase_put_bits(PutBitContext *s, uint8_t
> *buffer,
> + int buffer_size)
> +{
> +av_assert0(8*buffer_size > s->size_in_bits);
> +
> +s->buf_end = buffer + buffer_size;
> +s->buf_ptr = buffer + (s->buf_ptr - s->buf);
> +s->buf = buffer;
> +s->size_in_bits = 8 * buffer_size;
> +}
> +
> +/**
> * @return the total number of bits written to the bitstream.
> */
> static inline int put_bits_count(PutBitContext *s)
>
LGTM otherwise.
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_mp4toannexb_bsf: always set idr_sps_pps_seen when SPS/PPS is seen.
Hi,
- Mail original -
> Hi,
>
> Le 26/09/2014 18:38, Michael Niedermayer a écrit :
> > On Fri, Sep 26, 2014 at 09:27:01AM +0200, Benoit Fouet wrote:
> >> Hi,
> >>
> >> - Mail original -
> >>> Michael Niedermayer gmx.at> writes:
> >>>
> >>>>
> >>>> On Fri, Aug 01, 2014 at 01:54:14AM +0200, Michael Niedermayer
> >>>> wrote:
> >>>>> On Thu, Jul 31, 2014 at 03:40:51PM +0200, Benoit Fouet wrote:
> >>>>>> In order not to break a sequence like "SPS IDR SPS IDR", the
> >>> boolean
> >>>>>> telling that the SPS/PPS has been seen should always be set.
> >>>>>> ---
> >>>>>> libavcodec/h264_mp4toannexb_bsf.c | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> LGTM
> >>>>
> >>>> applied
> >>>>
> >>>> thanks
> >>>
> >>> A GitHub user "@thomag" commented on this commit:
> >>>
> >>>> Consider an mp4 files with just pps in the h264 stream (no sps
> >>>> in
> >>>> the
> >>>> NAL units, but available from avcc).
> >>>> In this case 'ctx->idr_sps_pps_seen' prevents inserting sps in
> >>>> the
> >>>> extracted h264, which is then unusable.
> >>>
> >>> FYI. I cannot confirm if it is correct or not, and what the
> >>> correct
> >>> solution would be.
> >>>
> >>
> >> I'm willing to try and fix this when/if we have a sample to test
> >> that.
> >> If there is also an example with just sps in the avcc and only pps
> >> in
> the stream, that'd be perfect...
> >
> > forwarding from github
> >
> > Michael,
> > Here is a short clip @
> https://s3.amazonaws.com/quickfire-public/dwclip2.mp4
> > which has just PPS in the h264 stream.
> > Please let me know if you need anything else.
> > Regards,
> > Thomas.
> >
>
> OK, cool. I'll have a look at this after the weekend then.
>
I have a first version of the patch attached.
With this patch, the sample provided from the link above can be converted with
the h264_mp4toannexb_bsf, but produces warnings when played back.
What I've done here is to prepend only the missing parameter set to the
filtered stream.
I'll spend some more time on it, but I'd like to get another look than mine,
just in case I'm missing something obvious.
--
Ben
From 29536721f09901f0197c0ca4c14e8e19ff01489b Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 29 Sep 2014 15:18:50 +0200
Subject: [PATCH] avcodec/h264_mp4toannexb_bsf: add a case when only SPS/PPS is
in the stream.
When the AVCC contains SPS and PPS and the stream contains only one of
those, only the missing one should be prepended to the next key frame,
not both.
---
libavcodec/h264_mp4toannexb_bsf.c | 44 +++
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c b/libavcodec/h264_mp4toannexb_bsf.c
index 739ff95..6ab76ae 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -26,9 +26,12 @@
#include "avcodec.h"
typedef struct H264BSFContext {
+int32_t sps_offset;
+int32_t pps_offset;
uint8_t length_size;
uint8_t new_idr;
-uint8_t idr_sps_pps_seen;
+uint8_t idr_sps_seen;
+uint8_t idr_pps_seen;
int extradata_parsed;
} H264BSFContext;
@@ -60,7 +63,7 @@ static int alloc_and_copy(uint8_t **poutbuf, int *poutbuf_size,
return 0;
}
-static int h264_extradata_to_annexb(AVCodecContext *avctx, const int padding)
+static int h264_extradata_to_annexb(H264BSFContext *ctx, AVCodecContext *avctx, const int padding)
{
uint16_t unit_size;
uint64_t total_size = 0;
@@ -70,11 +73,14 @@ static int h264_extradata_to_annexb(AVCodecContext *avctx, const int padding)
static const uint8_t nalu_header[4] = { 0, 0, 0, 1 };
int length_size = (*extradata++ & 0x3) + 1; // retrieve length coded size
+ctx->sps_offset = ctx->pps_offset = -1;
+
/* retrieve sps and pps unit(s) */
unit_nb = *extradata++ & 0x1f; /* number of sps unit(s) */
if (!unit_nb) {
goto pps;
} else {
+ctx->sps_offset = 0;
sps_seen = 1;
}
@@ -103,8 +109,10 @@ static int h264_extradata_to_annexb(AVCodecContext *avctx, const int padding)
pps:
if (!unit_nb && !sps_done++) {
unit_nb = *extradata++; /* nu
Re: [FFmpeg-devel] [PATCH] h264_mp4toannexb_bsf: always set idr_sps_pps_seen when SPS/PPS is seen.
Hi, - Mail original - > On Mon, Sep 29, 2014 at 03:31:36PM +0200, Benoit Fouet wrote: > [...] > does this ensure that the sps is before the pps ? > if not that might be the reason for the warnings > It does not. I can update this so that when the pps is seen and not the sps, it prepends the sps to the pps. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_mp4toannexb_bsf: always set idr_sps_pps_seen when SPS/PPS is seen.
Hi,
- Mail original -
> On Tue, Sep 30, 2014 at 09:45:47AM +0200, Benoit Fouet wrote:
> > Hi,
> >
> > - Mail original -
> > > On Mon, Sep 29, 2014 at 03:31:36PM +0200, Benoit Fouet wrote:
> > >
> >
> > [...]
> >
> > > does this ensure that the sps is before the pps ?
> > > if not that might be the reason for the warnings
> > >
> >
> > It does not. I can update this so that when the pps is seen and not
> > the sps, it prepends the sps to the pps.
>
> please do, sps should be before the pps
>
Done, new patch attached.
Also, it would be cool if someone had a sample with only SPS in the stream, to
check that the copy of PPS from AVCC works fine too.
--
Ben
From d53efe2d0474a032813b71d5c6485f174d7659f6 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Mon, 29 Sep 2014 15:18:50 +0200
Subject: [PATCH] avcodec/h264_mp4toannexb_bsf: add a case when only SPS/PPS is
in the stream.
When only SPS or PPS is present in the stream, copy the missing one from
AVCC before insertion to the output stream.
---
libavcodec/h264_mp4toannexb_bsf.c | 57 ---
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c b/libavcodec/h264_mp4toannexb_bsf.c
index 739ff95..3ec4170 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -26,9 +26,12 @@
#include "avcodec.h"
typedef struct H264BSFContext {
+int32_t sps_offset;
+int32_t pps_offset;
uint8_t length_size;
uint8_t new_idr;
-uint8_t idr_sps_pps_seen;
+uint8_t idr_sps_seen;
+uint8_t idr_pps_seen;
int extradata_parsed;
} H264BSFContext;
@@ -60,7 +63,7 @@ static int alloc_and_copy(uint8_t **poutbuf, int *poutbuf_size,
return 0;
}
-static int h264_extradata_to_annexb(AVCodecContext *avctx, const int padding)
+static int h264_extradata_to_annexb(H264BSFContext *ctx, AVCodecContext *avctx, const int padding)
{
uint16_t unit_size;
uint64_t total_size = 0;
@@ -70,11 +73,14 @@ static int h264_extradata_to_annexb(AVCodecContext *avctx, const int padding)
static const uint8_t nalu_header[4] = { 0, 0, 0, 1 };
int length_size = (*extradata++ & 0x3) + 1; // retrieve length coded size
+ctx->sps_offset = ctx->pps_offset = -1;
+
/* retrieve sps and pps unit(s) */
unit_nb = *extradata++ & 0x1f; /* number of sps unit(s) */
if (!unit_nb) {
goto pps;
} else {
+ctx->sps_offset = 0;
sps_seen = 1;
}
@@ -103,8 +109,10 @@ static int h264_extradata_to_annexb(AVCodecContext *avctx, const int padding)
pps:
if (!unit_nb && !sps_done++) {
unit_nb = *extradata++; /* number of pps unit(s) */
-if (unit_nb)
+if (unit_nb) {
+ctx->pps_offset = (extradata - 1) - (avctx->extradata + 4);
pps_seen = 1;
+}
}
}
@@ -151,12 +159,13 @@ static int h264_mp4toannexb_filter(AVBitStreamFilterContext *bsfc,
/* retrieve sps and pps NAL units from extradata */
if (!ctx->extradata_parsed) {
-ret = h264_extradata_to_annexb(avctx, FF_INPUT_BUFFER_PADDING_SIZE);
+ret = h264_extradata_to_annexb(ctx, avctx, FF_INPUT_BUFFER_PADDING_SIZE);
if (ret < 0)
return ret;
ctx->length_size = ret;
ctx->new_idr = 1;
-ctx->idr_sps_pps_seen = 0;
+ctx->idr_sps_seen = 0;
+ctx->idr_pps_seen = 0;
ctx->extradata_parsed = 1;
}
@@ -176,8 +185,25 @@ static int h264_mp4toannexb_filter(AVBitStreamFilterContext *bsfc,
if (buf + nal_size > buf_end || nal_size < 0)
goto fail;
-if (unit_type == 7 || unit_type == 8)
-ctx->idr_sps_pps_seen = 1;
+if (unit_type == 7)
+ctx->idr_sps_seen = 1;
+else if (unit_type == 8) {
+ctx->idr_pps_seen = 1;
+/* if SPS has not been seen yet, prepend the AVCC one to PPS */
+if (!ctx->idr_sps_seen) {
+if (ctx->sps_offset == -1)
+av_log(avctx, AV_LOG_WARNING, "SPS not present in the stream, nor in AVCC, stream may be unreadable\n");
+else {
+if ((ret = alloc_and_copy(poutbuf, poutbuf_size,
+ avctx->extradata + ctx->sps_offset,
+ ctx->pps_offset != -1 ? ctx->pps_offset : avctx->extradata_size - ctx->sps_offset,
+ buf, nal_size)) < 0)
+goto fail;
+ctx->idr_sps_seen = 1;
+goto next_nal;
+}
+}
+
Re: [FFmpeg-devel] [PATCH] avformat/img2dec: fix glob pattern detection.
Hi,
- Mail original -
> The is_glob() function was not working with unescaped glob patterns,
> which is the way only glob_sequence (which is deprecated) works.
> Fixes ticket #3948
> ---
> libavformat/img2dec.c | 14 +-
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index a21429f..64ebc31 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -75,19 +75,7 @@ static int infer_size(int *width_ptr, int
> *height_ptr, int size)
> static int is_glob(const char *path)
> {
> #if HAVE_GLOB
> -size_t span = 0;
> -const char *p = path;
> -
> -while (p = strchr(p, '%')) {
> -if (*(++p) == '%') {
> -++p;
> -continue;
> -}
> -if (span = strspn(p, "*?[]{}"))
> -break;
> -}
> -/* Did we hit a glob char or get to the end? */
> -return span != 0;
> +return strspn(path, "%*?[]{}") != 0;
> #else
> return 0;
> #endif
>
Any opinion on this one?
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_mp4toannexb_bsf: always set idr_sps_pps_seen when SPS/PPS is seen.
Hi, - Mail original - > On Tue, Sep 30, 2014 at 11:15:06AM +0200, Benoit Fouet wrote: > > Hi, > > > > - Mail original - > > > On Tue, Sep 30, 2014 at 09:45:47AM +0200, Benoit Fouet wrote: > > > > Hi, > > > > > > > > - Mail original - > > > > > On Mon, Sep 29, 2014 at 03:31:36PM +0200, Benoit Fouet wrote: > > > > > > > > > > > > > [...] > > > > > > > > > does this ensure that the sps is before the pps ? > > > > > if not that might be the reason for the warnings > > > > > > > > > > > > > It does not. I can update this so that when the pps is seen and > > > > not > > > > the sps, it prepends the sps to the pps. > > > > > > please do, sps should be before the pps > > > > > > > Done, new patch attached. > > probably ok, should i apply it ? > I guess so. I have 2 more patches to this BSF, I'll send them shortly. > > > Also, it would be cool if someone had a sample with only SPS in the > > stream, to check that the copy of PPS from AVCC works fine too. > > yes, but i suspect this could be more rare > When/if we have one, we can test this anyway. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/h264_mp4toannexb_bsf: use the given padding in h264_extradata_to_annexb().
--- libavcodec/h264_mp4toannexb_bsf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/h264_mp4toannexb_bsf.c b/libavcodec/h264_mp4toannexb_bsf.c index 3ec4170..be42304 100644 --- a/libavcodec/h264_mp4toannexb_bsf.c +++ b/libavcodec/h264_mp4toannexb_bsf.c @@ -117,7 +117,7 @@ pps: } if (out) -memset(out + total_size, 0, FF_INPUT_BUFFER_PADDING_SIZE); +memset(out + total_size, 0, padding); if (!sps_seen) av_log(avctx, AV_LOG_WARNING, -- 2.1.0.127.g0c72b98 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/h264_mp4toannexb_bsf: reset the new IDR flag when SPS/PPS is seen.
---
libavcodec/h264_mp4toannexb_bsf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
index be42304..ae96ee9 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -186,9 +186,9 @@ static int h264_mp4toannexb_filter(AVBitStreamFilterContext
*bsfc,
goto fail;
if (unit_type == 7)
-ctx->idr_sps_seen = 1;
+ctx->idr_sps_seen = ctx->new_idr = 1;
else if (unit_type == 8) {
-ctx->idr_pps_seen = 1;
+ctx->idr_pps_seen = ctx->new_idr = 1;
/* if SPS has not been seen yet, prepend the AVCC one to PPS */
if (!ctx->idr_sps_seen) {
if (ctx->sps_offset == -1)
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mxfenc: add jpeg2000 support
Hi,
this patch adds support for j2k muxing in MXF.
tested with:
$ ffmpeg -t 5 -f lavfi -i testsrc -y -c:v libopenjpeg -y out.mxf
Played back in ffplay (linux), vlc (windows), Acrok MXF converter (windows).
I have no idea against what other players this should be tested.
--
Ben
From 448810ec5b39e7b95d7a43a76ed7994e7fca3b27 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Tue, 30 Sep 2014 14:16:52 +0200
Subject: [PATCH] avformat/mxfenc: add jpeg2000 support.
Fixes ticket #1542
---
libavformat/mxfenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 6a6b7c2..d808e4d 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -26,6 +26,7 @@
* SMPTE 377M MXF File Format Specifications
* SMPTE 379M MXF Generic Container
* SMPTE 381M Mapping MPEG Streams into the MXF Generic Container
+ * SMPTE 422M Mapping JPEG 2000 Codestreams into the MXF Generic Container
* SMPTE RP210: SMPTE Metadata Dictionary
* SMPTE RP224: Registry of SMPTE Universal Labels
*/
@@ -95,6 +96,7 @@ static const struct {
{ AV_CODEC_ID_PCM_S16LE, 1 },
{ AV_CODEC_ID_DVVIDEO, 15 },
{ AV_CODEC_ID_DNXHD, 24 },
+{ AV_CODEC_ID_JPEG2000, 34 },
{ AV_CODEC_ID_NONE }
};
@@ -266,6 +268,11 @@ static const MXFContainerEssenceEntry mxf_essence_container_uls[] = {
{ 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00 },
{ 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x13,0x00,0x00 },
mxf_write_cdci_desc },
+// JPEG2000
+{ { 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00 },
+ { 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x08,0x00 },
+ { 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00 },
+ mxf_write_cdci_desc },
{ { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 },
{ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 },
{ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 },
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/movenc: add EAC3 muxing support.
Fixes ticket #3074
---
libavformat/isom.c | 1 +
libavformat/movenc.c | 44 +++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index d768c32..1509021 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -57,6 +57,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
{ AV_CODEC_ID_VC1 , 0xA3 },
{ AV_CODEC_ID_DIRAC , 0xA4 },
{ AV_CODEC_ID_AC3 , 0xA5 },
+{ AV_CODEC_ID_EAC3, 0xA6 },
{ AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
{ AV_CODEC_ID_VORBIS , 0xDD }, /* non standard, gpac uses it */
{ AV_CODEC_ID_DVD_SUBTITLE, 0xE0 }, /* non standard, see
unsupported-embedded-subs-2.mp4 */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bfee866..62b2d4b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -31,6 +31,7 @@
#include "avio.h"
#include "isom.h"
#include "avc.h"
+#include "libavcodec/ac3_parser.h"
#include "libavcodec/get_bits.h"
#include "libavcodec/put_bits.h"
#include "libavcodec/vc1_common.h"
@@ -292,6 +293,40 @@ static int mov_write_ac3_tag(AVIOContext *pb, MOVTrack
*track)
return 11;
}
+static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack *track)
+{
+GetBitContext gbc;
+PutBitContext pbc;
+uint8_t buf[5];
+AC3HeaderInfo tmp, *hdr = &tmp;
+
+if (!track->vos_len)
+return -1;
+
+init_get_bits(&gbc, track->vos_data, track->vos_len * 8);
+if (avpriv_ac3_parse_header2(&gbc, &hdr) != 0)
+return -1;
+
+avio_wb32(pb, 13);
+ffio_wfourcc(pb, "dec3");
+
+init_put_bits(&pbc, buf, sizeof(buf));
+put_bits(&pbc, 13, hdr->bit_rate);
+put_bits(&pbc, 3, 0); /* consider there is only one independent substream
present */
+put_bits(&pbc, 2, hdr->sr_code);
+put_bits(&pbc, 5, hdr->bitstream_id);
+put_bits(&pbc, 5, hdr->bitstream_mode);
+put_bits(&pbc, 3, hdr->channel_mode);
+put_bits(&pbc, 1, hdr->lfe_on);
+put_bits(&pbc, 5, 0); /* reserved */
+put_bits(&pbc, 4, 0); /* no dependent substream */
+put_bits(&pbc, 1, 0); /* reserved */
+flush_put_bits(&pbc);
+avio_write(pb, buf, sizeof(buf));
+
+return 13;
+}
+
/**
* This function writes extradata "as is".
* Extradata must be formatted like a valid atom (with size and tag).
@@ -486,6 +521,8 @@ static int mov_write_wave_tag(AVIOContext *pb, MOVTrack
*track)
mov_write_amr_tag(pb, track);
} else if (track->enc->codec_id == AV_CODEC_ID_AC3) {
mov_write_ac3_tag(pb, track);
+} else if (track->enc->codec_id == AV_CODEC_ID_EAC3) {
+mov_write_eac3_tag(pb, track);
} else if (track->enc->codec_id == AV_CODEC_ID_ALAC ||
track->enc->codec_id == AV_CODEC_ID_QDM2) {
mov_write_extradata_tag(pb, track);
@@ -756,6 +793,7 @@ static int mov_write_audio_tag(AVIOContext *pb, MOVTrack
*track)
if (track->mode == MODE_MOV &&
(track->enc->codec_id == AV_CODEC_ID_AAC ||
track->enc->codec_id == AV_CODEC_ID_AC3 ||
+ track->enc->codec_id == AV_CODEC_ID_EAC3 ||
track->enc->codec_id == AV_CODEC_ID_AMR_NB||
track->enc->codec_id == AV_CODEC_ID_ALAC ||
track->enc->codec_id == AV_CODEC_ID_ADPCM_MS ||
@@ -770,6 +808,8 @@ static int mov_write_audio_tag(AVIOContext *pb, MOVTrack
*track)
mov_write_amr_tag(pb, track);
else if (track->enc->codec_id == AV_CODEC_ID_AC3)
mov_write_ac3_tag(pb, track);
+else if (track->enc->codec_id == AV_CODEC_ID_EAC3)
+mov_write_eac3_tag(pb, track);
else if (track->enc->codec_id == AV_CODEC_ID_ALAC)
mov_write_extradata_tag(pb, track);
else if (track->enc->codec_id == AV_CODEC_ID_WMAPRO)
@@ -877,6 +917,7 @@ static int mp4_get_codec_tag(AVFormatContext *s, MOVTrack
*track)
if (track->enc->codec_id == AV_CODEC_ID_H264) tag =
MKTAG('a','v','c','1');
else if (track->enc->codec_id == AV_CODEC_ID_HEVC) tag =
MKTAG('h','e','v','1');
else if (track->enc->codec_id == AV_CODEC_ID_AC3) tag =
MKTAG('a','c','-','3');
+else if (track->enc->codec_id == AV_CODEC_ID_EAC3) tag =
MKTAG('e','c','-','3');
else if (track->enc->codec_id == AV_CODEC_ID_DIRAC) tag =
MKTAG('d','r','a','c');
else if (track->enc->codec_id == AV_CODEC_ID_MOV_TEXT) tag =
MKTAG('t','x','3','g');
else if (track->enc->codec_id == AV_CODEC_ID_VC1) tag =
MKTAG('v','c','-','1');
@@ -3605,7 +3646,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
}
if ((enc->codec_id == AV_CODEC_ID_DNXHD ||
- enc->codec_id == AV_CODEC_ID_AC3) && !trk->vos_len) {
+ enc->codec_id == AV_CODEC_ID_AC3 ||
+ enc->codec_id == AV_CODEC_ID_EAC3) && !trk->vos_len) {
/* copy frame to create needed atoms */
trk->vos_len = size;
trk->vos_data = av_malloc(siz
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: add jpeg2000 support
Hi, - Mail original - > On Tue, 2014-09-30 at 15:37 +0200, Benoit Fouet wrote: > > Hi, > > > > this patch adds support for j2k muxing in MXF. > > tested with: > > $ ffmpeg -t 5 -f lavfi -i testsrc -y -c:v libopenjpeg -y out.mxf > > > > Played back in ffplay (linux), vlc (windows), Acrok MXF converter > > (windows). > > I have no idea against what other players this should be tested. > > Do we have a sample + FATE case for this? > Nope -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add EAC3 muxing support.
Hi,
- Mail original -
> 2014-10-02 19:39 GMT+09:00 Benoit Fouet :
>
[...]
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index bfee866..62b2d4b 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
> > @@ -31,6 +31,7 @@
> > #include "avio.h"
> > #include "isom.h"
> > #include "avc.h"
> > +#include "libavcodec/ac3_parser.h"
> > #include "libavcodec/get_bits.h"
> > #include "libavcodec/put_bits.h"
> > #include "libavcodec/vc1_common.h"
> > @@ -292,6 +293,40 @@ static int mov_write_ac3_tag(AVIOContext *pb,
> > MOVTrack *track)
> > return 11;
> > }
> >
> > +static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack *track)
> > +{
> > +GetBitContext gbc;
> > +PutBitContext pbc;
> > +uint8_t buf[5];
> > +AC3HeaderInfo tmp, *hdr = &tmp;
> > +
> > +if (!track->vos_len)
> > +return -1;
> > +
> > +init_get_bits(&gbc, track->vos_data, track->vos_len * 8);
> > +if (avpriv_ac3_parse_header2(&gbc, &hdr) != 0)
> > +return -1;
> > +
> > +avio_wb32(pb, 13);
> > +ffio_wfourcc(pb, "dec3");
> > +
> > +init_put_bits(&pbc, buf, sizeof(buf));
> > +put_bits(&pbc, 13, hdr->bit_rate);
> > +put_bits(&pbc, 3, 0); /* consider there is only one
> > independent
> > substream present */
> > +put_bits(&pbc, 2, hdr->sr_code);
> > +put_bits(&pbc, 5, hdr->bitstream_id);
> > +put_bits(&pbc, 5, hdr->bitstream_mode);
> > +put_bits(&pbc, 3, hdr->channel_mode);
> > +put_bits(&pbc, 1, hdr->lfe_on);
> > +put_bits(&pbc, 5, 0); /* reserved */
> > +put_bits(&pbc, 4, 0); /* no dependent substream */
> >
>
> I tested this patch for a 7.1ch source (requires dependent stream(s))
> and I
> get the result containing improper settings here.
> Please set properly here. Or reject streams requiring dependent
> streams.
>
Do you have a sample you can share?
I don't have any material to test this.
> Sorry, multiple and consecutive posts.
> But I found another issue in this patch.
> This patch does not pack syncframes into a sample in order to pack 6 blocks.
> The spec requires a sample consists of 6 blocks to make samle_delta in stts
> equal to 1536.
>
I'll have a look at that too.
Thanks
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add EAC3 muxing support.
Hi, - Mail original - > Benoit Fouet free.fr> writes: > > > Do you have a sample you can share? > > Please look at the 7.1 samples in > http://samples.ffmpeg.org//A-codecs/AC3/eac3/ > I was about to send an email stating I found those ones. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/movenc: add EAC3 muxing support.
Hi, - Mail original - > Benoit Fouet free.fr> writes: > > > > Please look at the 7.1 samples in > > > http://samples.ffmpeg.org//A-codecs/AC3/eac3/ > > > > I was about to send an email stating I found those ones. > > Since all samples we have are from demo discs, I strongly > suggest you simply fail for those samples (or write > invalid files). > Actually, there needs to be some more specific work done for EAC3 muxing, as stated by Yusuke Nakamura. I've some ideas to implement them, and this should fix all the issues that exists right now with the patch (possibly concatenating syncframes and taking care of all the different substreams, whatever their type is). I won't have time to do that today, but I'll get back to it on Monday. Though this patch, in its current state, can be considered as dropped. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/movenc: add EAC3 muxing support.
Support only one independent substream right now, and only syncframes
containing 6 blocks.
Fixes part of ticket #3074
---
Right now, this produces the same output as the previous patch for supported
streams, and rejects the unsupported ones.
Support for syncframes concatenation will come afterwards.
libavformat/isom.c | 1 +
libavformat/movenc.c | 184 +++
libavformat/movenc.h | 2 +
3 files changed, 187 insertions(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index d768c32..1509021 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -57,6 +57,7 @@ const AVCodecTag ff_mp4_obj_type[] = {
{ AV_CODEC_ID_VC1 , 0xA3 },
{ AV_CODEC_ID_DIRAC , 0xA4 },
{ AV_CODEC_ID_AC3 , 0xA5 },
+{ AV_CODEC_ID_EAC3, 0xA6 },
{ AV_CODEC_ID_DTS , 0xA9 }, /* mp4ra.org */
{ AV_CODEC_ID_VORBIS , 0xDD }, /* non standard, gpac uses it */
{ AV_CODEC_ID_DVD_SUBTITLE, 0xE0 }, /* non standard, see
unsupported-embedded-subs-2.mp4 */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bfee866..18c5955 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -31,6 +31,7 @@
#include "avio.h"
#include "isom.h"
#include "avc.h"
+#include "libavcodec/ac3_parser.h"
#include "libavcodec/get_bits.h"
#include "libavcodec/put_bits.h"
#include "libavcodec/vc1_common.h"
@@ -292,6 +293,178 @@ static int mov_write_ac3_tag(AVIOContext *pb, MOVTrack
*track)
return 11;
}
+struct eac3_info {
+uint8_t ec3_done;
+
+/* Layout of the EC3SpecificBox */
+/* maximum bitrate */
+uint16_t data_rate;
+/* number of independent substreams */
+uint8_t num_ind_sub;
+struct {
+/* sample rate code (see ff_ac3_sample_rate_tab) 2 bits */
+uint8_t fscod;
+/* bit stream identification 5 bits */
+uint8_t bsid;
+/* one bit reserved */
+/* audio service mixing (not supported yet) 1 bit */
+/* bit stream mode 3 bits */
+uint8_t bsmod;
+/* audio coding mode 3 bits */
+uint8_t acmod;
+/* sub woofer on 1 bit */
+uint8_t lfeon;
+/* 3 bits reserved */
+/* number of dependent substreams associated with this substream 4
bits */
+uint8_t num_dep_sub;
+/* channel locations of the dependent substream(s), if any, 9 bits */
+uint16_t chan_loc;
+/* if there is no dependent substream, then one bit reserved instead */
+} substream[1]; /* TODO: support 8 independent substreams */
+};
+
+static int handle_eac3(AVPacket *pkt, MOVTrack *track)
+{
+GetBitContext gbc;
+AC3HeaderInfo tmp, *hdr = &tmp;
+struct eac3_info *info;
+int ret, num_blocks;
+
+if (!track->eac3_priv && !(track->eac3_priv = av_mallocz(sizeof(*info
+return AVERROR(ENOMEM);
+info = track->eac3_priv;
+
+init_get_bits(&gbc, pkt->data, pkt->size * 8);
+if ((ret = avpriv_ac3_parse_header2(&gbc, &hdr)) < 0)
+return ret;
+
+info->data_rate = FFMAX(info->data_rate, hdr->bit_rate);
+num_blocks = hdr->num_blocks;
+
+if (!info->ec3_done) {
+/* AC-3 substream must be the first one */
+if (hdr->bitstream_id <= 10 && hdr->substreamid != 0)
+return AVERROR(EINVAL);
+
+/* this should always be the case, given that our AC-3 parser
+ * concatenates dependent frames to their independent parent */
+if (hdr->frame_type == EAC3_FRAME_TYPE_INDEPENDENT) {
+/* substream ids must be incremental */
+if (hdr->substreamid > info->num_ind_sub + 1)
+return AVERROR(EINVAL);
+
+if (hdr->substreamid == info->num_ind_sub + 1) {
+//info->num_ind_sub++;
+avpriv_request_sample(track->enc, "Multiple independent
substreams");
+return AVERROR_PATCHWELCOME;
+} else if (hdr->substreamid < info->num_ind_sub ||
+ hdr->substreamid == 0 && info->substream[0].bsid) {
+info->ec3_done = 1;
+goto concatenate;
+}
+}
+
+/* fill the info needed for the "dec3" atom */
+info->substream[hdr->substreamid].fscod = hdr->sr_code;
+info->substream[hdr->substreamid].bsid = hdr->bitstream_id;
+info->substream[hdr->substreamid].bsmod = hdr->bitstream_mode;
+info->substream[hdr->substreamid].acmod = hdr->channel_mode;
+info->substream[hdr->substreamid].lfeon = hdr->lfe_on;
+
+/* Parse dependent substream(s), if any */
+if (pkt->size != hdr->frame_size) {
+int cumul_size = hdr->frame_size;
+int parent = hdr->substreamid;
+
+while (cumul_size != pkt->size) {
+int i;
+init_get_bits(&gbc, pkt->data + cumul_size, (pkt->size -
cumul_size) * 8);
+if ((ret = avpriv_ac3_parse_header2(&gbc, &hdr)) < 0)
+
[FFmpeg-devel] [PATCH] avformat/mov: E-AC-3 streams need parsing too.
syncframes in E-AC-3 can be combined to provide 6 audio blocks per sample, thus requiring parsing for proper decoding. --- libavformat/mov.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index fdd0671..40c2fc4 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -1631,6 +1631,7 @@ static int mov_finalize_stsd_codec(MOVContext *c, AVIOContext *pb, } break; case AV_CODEC_ID_AC3: +case AV_CODEC_ID_EAC3: case AV_CODEC_ID_MPEG1VIDEO: case AV_CODEC_ID_VC1: st->need_parsing = AVSTREAM_PARSE_FULL; -- 2.1.0.127.g0c72b98 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/movenc: add support for syncframes concatenation for E-AC-3.
E-AC-3 samples should contain 6 audio blocks, so concatenate syncframes
in order to achieve this.
---
libavformat/movenc.c | 41 +++--
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 18c5955..4f4f1cb 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -294,7 +294,9 @@ static int mov_write_ac3_tag(AVIOContext *pb, MOVTrack
*track)
}
struct eac3_info {
+AVPacket pkt;
uint8_t ec3_done;
+uint8_t num_blocks;
/* Layout of the EC3SpecificBox */
/* maximum bitrate */
@@ -405,11 +407,32 @@ static int handle_eac3(AVPacket *pkt, MOVTrack *track)
}
}
-/* TODO: concatenate syncframes to have 6 blocks per entry */
concatenate:
-if (num_blocks != 6) {
-avpriv_request_sample(track->enc, "%d block(s) in syncframe",
num_blocks);
-return AVERROR_PATCHWELCOME;
+if (!info->num_blocks && num_blocks == 6)
+return pkt->size;
+else if (info->num_blocks + num_blocks > 6)
+return AVERROR_INVALIDDATA;
+
+if (!info->num_blocks) {
+if ((ret = av_copy_packet(&info->pkt, pkt)) < 0)
+return ret;
+info->num_blocks = num_blocks;
+return 0;
+} else {
+if ((ret = av_grow_packet(&info->pkt, pkt->size)) < 0)
+return ret;
+memcpy(info->pkt.data + info->pkt.size - pkt->size, pkt->data,
pkt->size);
+info->num_blocks += num_blocks;
+info->pkt.duration += pkt->duration;
+if ((ret = av_copy_packet_side_data(&info->pkt, pkt)) < 0)
+return ret;
+if (info->num_blocks != 6)
+return 0;
+av_free_packet(pkt);
+if ((ret = av_copy_packet(pkt, &info->pkt)) < 0)
+return ret;
+av_free_packet(&info->pkt);
+info->num_blocks = 0;
}
return pkt->size;
@@ -429,8 +452,8 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack
*track)
size = 2 + 4 * (info->num_ind_sub + 1);
buf = av_malloc(size);
if (!buf) {
-av_freep(&track->eac3_priv);
-return AVERROR(ENOMEM);
+size = AVERROR(ENOMEM);
+goto end;
}
init_put_bits(&pbc, buf, size);
@@ -460,6 +483,9 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack
*track)
avio_write(pb, buf, size);
av_free(buf);
+
+end:
+av_free_packet(&info->pkt);
av_freep(&track->eac3_priv);
return size;
@@ -3783,6 +3809,8 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
size = handle_eac3(pkt, trk);
if (size < 0)
return size;
+else if (!size)
+goto end;
avio_write(pb, pkt->data, size);
} else {
avio_write(pb, pkt->data, size);
@@ -3856,6 +3884,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
if (trk->hint_track >= 0 && trk->hint_track < mov->nb_streams)
ff_mov_add_hinted_packet(s, pkt, trk->hint_track, trk->entry,
reformatted_data, size);
+end:
av_free(reformatted_data);
return 0;
}
--
2.1.0.127.g0c72b98
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
