Re: [libav-devel] [PATCH] utils: Do not expand a macro with 'defined' in it
On 8/24/2017 9:04 PM, Derek Buitenhuis wrote: > From: Derek Buitenhuis > > Fixes: > > libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' > has undefined behavior [-Wexpansion-to-defined] > #if USE_MMAP > ^ > libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP' > #define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS) > ^ > Signed-off-by: Derek Buitenhuis > --- > libswscale/utils.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) s#utils#swscale/utils# - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] utils: Do not expand a macro with 'defined' in it
From: Derek Buitenhuis
Fixes:
libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' has
undefined behavior [-Wexpansion-to-defined]
#if USE_MMAP
^
libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP'
#define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS)
^
Signed-off-by: Derek Buitenhuis
---
libswscale/utils.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 6b17955..786774f 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1098,7 +1098,11 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
}
}
-#define USE_MMAP (HAVE_MMAP && HAVE_MPROTECT && defined MAP_ANONYMOUS)
+#if HAVE_MMAP && HAVE_MPROTECT && defined(MAP_ANONYMOUS)
+#define USE_MMAP 1
+#else
+#define USE_MMAP 0
+#endif
/* precalculate horizontal scaler filter coefficients */
{
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avcodec: Mark some codecs with threadsafe init as such
Signed-off-by: Derek Buitenhuis
---
Circa November 2015.
---
libavcodec/aasc.c | 1 +
libavcodec/aic.c | 1 +
libavcodec/anm.c | 1 +
libavcodec/ansi.c | 1 +
libavcodec/aura.c | 1 +
libavcodec/avs.c | 1 +
libavcodec/bethsoftvideo.c | 1 +
libavcodec/bfi.c | 1 +
libavcodec/bmvvideo.c | 1 +
libavcodec/c93.c | 1 +
libavcodec/cllc.c | 1 +
libavcodec/cyuv.c | 2 ++
libavcodec/fraps.c | 1 +
libavcodec/lcldec.c| 2 ++
libavcodec/pngdec.c| 1 +
libavcodec/r210dec.c | 2 ++
libavcodec/utvideodec.c| 1 +
libavcodec/vble.c | 1 +
libavcodec/zerocodec.c | 1 +
19 files changed, 22 insertions(+)
diff --git a/libavcodec/aasc.c b/libavcodec/aasc.c
index e65ea39..c4800f0 100644
--- a/libavcodec/aasc.c
+++ b/libavcodec/aasc.c
@@ -119,4 +119,5 @@ AVCodec ff_aasc_decoder = {
.close = aasc_decode_end,
.decode = aasc_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index ed0be44..de9d7de 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -488,4 +488,5 @@ AVCodec ff_aic_decoder = {
.decode = aic_decode_frame,
.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
.init_thread_copy = ONLY_IF_THREADS_ENABLED(aic_decode_init),
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/anm.c b/libavcodec/anm.c
index b70d220..af8d843 100644
--- a/libavcodec/anm.c
+++ b/libavcodec/anm.c
@@ -199,4 +199,5 @@ AVCodec ff_anm_decoder = {
.close = decode_end,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/ansi.c b/libavcodec/ansi.c
index 65e2e16..0bdbdbe 100644
--- a/libavcodec/ansi.c
+++ b/libavcodec/ansi.c
@@ -451,4 +451,5 @@ AVCodec ff_ansi_decoder = {
.close = decode_close,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/aura.c b/libavcodec/aura.c
index a1ef6f8..6a03f8f 100644
--- a/libavcodec/aura.c
+++ b/libavcodec/aura.c
@@ -107,4 +107,5 @@ AVCodec ff_aura2_decoder = {
.init = aura_decode_init,
.decode = aura_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/avs.c b/libavcodec/avs.c
index 959f570..edd91ef 100644
--- a/libavcodec/avs.c
+++ b/libavcodec/avs.c
@@ -186,4 +186,5 @@ AVCodec ff_avs_decoder = {
.decode = avs_decode_frame,
.close = avs_decode_end,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/bethsoftvideo.c b/libavcodec/bethsoftvideo.c
index 11e2cfa..61f098b 100644
--- a/libavcodec/bethsoftvideo.c
+++ b/libavcodec/bethsoftvideo.c
@@ -164,4 +164,5 @@ AVCodec ff_bethsoftvid_decoder = {
.close = bethsoftvid_decode_end,
.decode = bethsoftvid_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/bfi.c b/libavcodec/bfi.c
index 8335e9d..0ce73b1 100644
--- a/libavcodec/bfi.c
+++ b/libavcodec/bfi.c
@@ -181,4 +181,5 @@ AVCodec ff_bfi_decoder = {
.close = bfi_decode_close,
.decode = bfi_decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/bmvvideo.c b/libavcodec/bmvvideo.c
index 4fb42f0..698bc56 100644
--- a/libavcodec/bmvvideo.c
+++ b/libavcodec/bmvvideo.c
@@ -289,4 +289,5 @@ AVCodec ff_bmv_video_decoder = {
.init = decode_init,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/c93.c b/libavcodec/c93.c
index 18df958..e751483 100644
--- a/libavcodec/c93.c
+++ b/libavcodec/c93.c
@@ -261,4 +261,5 @@ AVCodec ff_c93_decoder = {
.close = decode_end,
.decode = decode_frame,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/cllc.c b/libavcodec/cllc.c
index bac2b73..3c476f7 100644
--- a/libavcodec/cllc.c
+++ b/libavcodec/cllc.c
@@ -488,4 +488,5 @@ AVCodec ff_cllc_decoder = {
.decode = cllc_decode_frame,
.close = cllc_decode_close,
.capabilities = AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
};
diff --git a/libavcodec/cyuv.c b/libavcodec/cyuv.c
index 86f7aac..2c4f98d 100644
--- a/libavcodec/cyuv.c
+++ b/libavcodec/cyuv.c
@@ -173,6 +173,7 @@ AVCodec ff_aura_decoder = {
.init = cyuv_decode_init,
.decode
[libav-devel] [PATCH] hevc: Mark as having threadsafe init
Signed-off-by: Derek Buitenhuis
---
libavcodec/hevcdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 700b5f09a0..48045fb11b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3091,5 +3091,6 @@ AVCodec ff_hevc_decoder = {
.init_thread_copy = hevc_init_thread_copy,
.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
AV_CODEC_CAP_FRAME_THREADS,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
.profiles = NULL_IF_CONFIG_SMALL(ff_hevc_profiles),
};
--
2.11.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 0/2] H.264 threading stuffix + test
Sample is here: https://trac.ffmpeg.org/attachment/ticket/5458/nondeterministic_cut.h264 Can be reproduced using 13 or more frame threads to decode. This email is a professional courtesy. Derek Buitenhuis (2): h264_slice: Wait for refs to be available before we use them in error concealment fate: Add h264 test for frame num gaps libavcodec/h264_slice.c | 3 +++ tests/fate/h264.mak | 2 ++ tests/ref/fate/h264-missing-frame | 31 +++ 3 files changed, 36 insertions(+) create mode 100644 tests/ref/fate/h264-missing-frame -- 2.11.0 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] fate: Add h264 test for frame num gaps
Signed-off-by: Derek Buitenhuis --- tests/fate/h264.mak | 2 ++ tests/ref/fate/h264-missing-frame | 31 +++ 2 files changed, 33 insertions(+) create mode 100644 tests/ref/fate/h264-missing-frame diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak index 635abcd7b9..3d6fde7bdb 100644 --- a/tests/fate/h264.mak +++ b/tests/fate/h264.mak @@ -182,6 +182,7 @@ FATE_H264 := $(FATE_H264:%=fate-h264-conformance-%) \ fate-h264-extreme-plane-pred \ fate-h264-intra-refresh-recovery \ fate-h264-lossless\ + fate-h264-missing-frame \ FATE_H264-$(call DEMDEC, H264, H264) += $(FATE_H264) FATE_H264-$(call DEMDEC, MOV, H264) += fate-h264-crop-to-container @@ -397,5 +398,6 @@ fate-h264-lossless: CMD = framecrc -i $(TARGET_SAM fate-h264-mixed-nal-coding: CMD = framecrc -i $(TARGET_SAMPLES)/h264/mixed-nal-coding.mp4 fate-h264-twofields-packet: CMD = framecrc -i $(TARGET_SAMPLES)/h264/twofields_packet.mp4 -an -frames 30 fate-h264-unescaped-extradata:CMD = framecrc -i $(TARGET_SAMPLES)/h264/unescaped_extradata.mp4 -an -frames 10 +fate-h264-missing-frame: CMD = framecrc -i $(TARGET_SAMPLES)/h264/nondeterministic_cut.h264 fate-h264-reinit-%: CMD = framecrc -i $(TARGET_SAMPLES)/h264/$(@:fate-h264-%=%).h264 -vf format=yuv444p10le,scale=w=352:h=288 diff --git a/tests/ref/fate/h264-missing-frame b/tests/ref/fate/h264-missing-frame new file mode 100644 index 00..61c5f2fab5 --- /dev/null +++ b/tests/ref/fate/h264-missing-frame @@ -0,0 +1,31 @@ +#tb 0: 1/25 +0, 0, 0,1, 2332800, 0x009dacb8 +0, 1, 1,1, 2332800, 0xb1e50764 +0, 2, 2,1, 2332800, 0xe29481e0 +0, 3, 3,1, 2332800, 0x0b1b4de4 +0, 4, 4,1, 2332800, 0x726a644c +0, 5, 5,1, 2332800, 0x7a09c4a5 +0, 6, 6,1, 2332800, 0x2e9059ea +0, 7, 7,1, 2332800, 0x52071fdc +0, 8, 8,1, 2332800, 0x4fa00417 +0, 9, 9,1, 2332800, 0x6037fb4d +0, 10, 10,1, 2332800, 0x887ffae2 +0, 11, 11,1, 2332800, 0x887ffae2 +0, 12, 12,1, 2332800, 0x887ffae2 +0, 13, 13,1, 2332800, 0x887ffae2 +0, 14, 14,1, 2332800, 0x887ffae2 +0, 15, 15,1, 2332800, 0x887ffae2 +0, 16, 16,1, 2332800, 0x887ffae2 +0, 17, 17,1, 2332800, 0x887ffae2 +0, 18, 18,1, 2332800, 0x887ffae2 +0, 19, 19,1, 2332800, 0x887ffae2 +0, 20, 20,1, 2332800, 0x887ffae2 +0, 21, 21,1, 2332800, 0x887ffae2 +0, 22, 22,1, 2332800, 0x887ffae2 +0, 23, 23,1, 2332800, 0x887ffae2 +0, 24, 24,1, 2332800, 0x887ffae2 +0, 25, 25,1, 2332800, 0x887ffae2 +0, 26, 26,1, 2332800, 0x887ffae2 +0, 27, 27,1, 2332800, 0x887ffae2 +0, 28, 28,1, 2332800, 0x887ffae2 +0, 29, 29,1, 2332800, 0x824bb91b -- 2.11.0 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] h264_slice: Wait for refs to be available before we use them in error concealment
This could happen when there was a frame number gap and frame threading was
used.
Debugging-by: Ronald S. Bultje
Debugging-by: Justin Ruggles
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264_slice.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 8d79740a7f..1b91088f52 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1404,6 +1404,9 @@ static int h264_field_start(H264Context *h, const
H264SliceContext *sl,
h->short_ref[0]->f->width == prev->f->width &&
h->short_ref[0]->f->height == prev->f->height &&
h->short_ref[0]->f->format == prev->f->format) {
+ff_thread_await_progress(&prev->tf, INT_MAX, 0);
+if (prev->field_picture)
+ff_thread_await_progress(&prev->tf, INT_MAX, 1);
av_image_copy(h->short_ref[0]->f->data,
h->short_ref[0]->f->linesize,
(const uint8_t **)prev->f->data,
--
2.11.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] libx265: Add option to force IDR frames
From: Derek Buitenhuis
This is in the same the same vein as 380146924ecad2e05e9dcc5c3c2e1b5ba47c51e8.
Signed-off-by: Derek Buitenhuis
---
A professional courtesy.
---
libavcodec/libx265.c | 5 -
libavcodec/version.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index f5d3d0f..add0569 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -42,6 +42,7 @@ typedef struct libx265Context {
const x265_api *api;
float crf;
+int forced_idr;
char *preset;
char *tune;
char *x265_opts;
@@ -263,7 +264,8 @@ static int libx265_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
x265pic.pts = pic->pts;
x265pic.bitDepth = av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth;
-x265pic.sliceType = pic->pict_type == AV_PICTURE_TYPE_I ? X265_TYPE_I :
+x265pic.sliceType = pic->pict_type == AV_PICTURE_TYPE_I ?
+ (ctx->forced_idr ? X265_TYPE_IDR
: X265_TYPE_I) :
pic->pict_type == AV_PICTURE_TYPE_P ? X265_TYPE_P :
pic->pict_type == AV_PICTURE_TYPE_B ? X265_TYPE_B :
X265_TYPE_AUTO;
@@ -348,6 +350,7 @@ static av_cold void libx265_encode_init_csp(AVCodec *codec)
#define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{ "crf", "set the x265 crf",
OFFSET(crf), AV_OPT_TYPE_FLOAT, { .dbl = -1 }, -1,
FLT_MAX, VE },
+{ "forced-idr", "if forcing keyframes, force them as IDR frames",
OFFSET(forced_idr),AV_OPT_TYPE_INT,{ .i64 = 0 }, 0,
1, VE },
{ "preset", "set the x265 preset",
OFFSET(preset),AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "tune","set the x265 tune parameter",
OFFSET(tune), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
{ "x265-params", "set the x265 configuration using a :-separated list of
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_STRING, { 0 }, 0, 0, VE },
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 6f439c0..a4856bf 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 57
#define LIBAVCODEC_VERSION_MINOR 28
-#define LIBAVCODEC_VERSION_MICRO 1
+#define LIBAVCODEC_VERSION_MICRO 2
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] mov: Remove ancient heuristic hack
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis
---
libavformat/isom.h | 1 -
libavformat/mov.c | 8 +---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 75aa70b..58f0a20 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -128,7 +128,6 @@ typedef struct MOVStreamContext {
unsigned drefs_count;
MOVDref *drefs;
int dref_id;
-int wrong_dts;///< dts are wrong due to huge ctts offset (iMovie
files)
int width;///< tkhd width
int height; ///< tkhd height
int dts_shift;///< dts shift when ctts is negative
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 03427d7..89c2c23 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2307,12 +2307,8 @@ static void mov_build_index(MOVContext *mov, AVStream
*st)
sc->time_offset = av_rescale(sc->time_offset, sc->time_scale,
mov->time_scale);
current_dts = -sc->time_offset;
if (sc->ctts_data && sc->stts_data && sc->stts_data[0].duration &&
-sc->ctts_data[0].duration / sc->stts_data[0].duration > 16) {
-/* more than 16 frames delay, dts are likely wrong
- this happens with files created by iMovie */
-sc->wrong_dts = 1;
+sc->ctts_data[0].duration / sc->stts_data[0].duration > 16)
st->internal->avctx->has_b_frames = 1;
-}
}
/* only use old uncompressed audio chunk demuxing when stts specifies it */
@@ -3670,8 +3666,6 @@ static int mov_read_packet(AVFormatContext *s, AVPacket
*pkt)
sc->ctts_index++;
sc->ctts_sample = 0;
}
-if (sc->wrong_dts)
-pkt->dts = AV_NOPTS_VALUE;
} else {
int64_t next_dts = (sc->current_sample < st->nb_index_entries) ?
st->index_entries[sc->current_sample].timestamp : st->duration;
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 0/2] mov: Remove some old hacks that break legitimate files
I ran into issues with these at work, and fixed them in FFmpeg. I've rebased them on Libav and am sending them as a professional courtesy. Keep in mind I'm still unscubscribed from both lists, so relevant comments may need to be CC'd to me if you feel something needs changing. Cheers. Derek Buitenhuis (2): mov: Remove ancient heuristic hack mov: Remove old b-frame/video delay heuristic libavformat/isom.h | 1 - libavformat/mov.c | 9 - 2 files changed, 10 deletions(-) -- 1.8.3.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] mov: Remove old b-frame/video delay heuristic
This was added before edts support existed, and is no longer valid. Signed-off-by: Derek Buitenhuis --- libavformat/mov.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 89c2c23..ca49716 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2306,9 +2306,6 @@ static void mov_build_index(MOVContext *mov, AVStream *st) if (sc->time_offset < 0) sc->time_offset = av_rescale(sc->time_offset, sc->time_scale, mov->time_scale); current_dts = -sc->time_offset; -if (sc->ctts_data && sc->stts_data && sc->stts_data[0].duration && -sc->ctts_data[0].duration / sc->stts_data[0].duration > 16) -st->internal->avctx->has_b_frames = 1; } /* only use old uncompressed audio chunk demuxing when stts specifies it */ -- 1.8.3.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] simple_idct_template: Fix strict aliasing violation
On 5/9/2016 5:13 PM, Vittorio Giovara wrote: > *on gcc 4.4. On all compilers. 4.4 just happened to hit it. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/5] mpeg4audio: Convert to the new bitstream reader.
On 5/9/2016 2:21 PM, Luca Barbato wrote: > compared to > > bitstream_read(bc, 32); > > and > > bitstream_read_32(bc, 32); > > Only the latter helps you a little more. > > At least bitstream.h is fully documented so it does not require you to > use the preprocessor to see what is going on =) It really is a shame more compilers don't have __builtin_constant_p type things... It would solve this whole issue. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/7] Add the new bitstream reader.
On 5/9/2016 2:16 PM, Luca Barbato wrote: > Let me sum up the evolution: > > - The functions had their max range embedded > - people used to have the exact range complained > > - Considering their complaint valid, Alexandra accepted to use another > set of names. > > - Then somebody suggested to make the 0-63 version the bitstream_read > and have the other with a different name. > - The suggested name had been _narrow. > > The people complaining the old names being confusing and irrational (me, > Alexandra, Kostya, Anton) maybe still like to have _32 and _63. I never weighed in one way or another until now, actually, because _narrow is even worse than the old names IMO. I have no opinion on _32 or _64. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] mjpegdec: Properly fail on malloc failure
Signed-off-by: Derek Buitenhuis
---
libavcodec/mjpegdec.c | 52 +++
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5625929..1f36b39 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1327,30 +1327,31 @@ static int mjpeg_decode_com(MJpegDecodeContext *s)
{
int len = get_bits(&s->gb, 16);
if (len >= 2 && 8 * len - 16 <= get_bits_left(&s->gb)) {
+int i;
char *cbuf = av_malloc(len - 1);
-if (cbuf) {
-int i;
-for (i = 0; i < len - 2; i++)
-cbuf[i] = get_bits(&s->gb, 8);
-if (i > 0 && cbuf[i - 1] == '\n')
-cbuf[i - 1] = 0;
-else
-cbuf[i] = 0;
+if (!cbuf)
+return AVERROR(ENOMEM);
-if (s->avctx->debug & FF_DEBUG_PICT_INFO)
-av_log(s->avctx, AV_LOG_INFO, "mjpeg comment: '%s'\n", cbuf);
-
-/* buggy avid, it puts EOI only at every 10th frame */
-if (!strcmp(cbuf, "AVID")) {
-s->buggy_avid = 1;
-} else if (!strcmp(cbuf, "CS=ITU601"))
-s->cs_itu601 = 1;
-else if ((len > 20 && !strncmp(cbuf, "Intel(R) JPEG Library", 21))
||
- (len > 19 && !strncmp(cbuf, "Metasoft MJPEG Codec", 20)))
-s->flipped = 1;
-
-av_free(cbuf);
-}
+for (i = 0; i < len - 2; i++)
+cbuf[i] = get_bits(&s->gb, 8);
+if (i > 0 && cbuf[i - 1] == '\n')
+cbuf[i - 1] = 0;
+else
+cbuf[i] = 0;
+
+if (s->avctx->debug & FF_DEBUG_PICT_INFO)
+av_log(s->avctx, AV_LOG_INFO, "mjpeg comment: '%s'\n", cbuf);
+
+/* buggy avid, it puts EOI only at every 10th frame */
+if (!strcmp(cbuf, "AVID")) {
+s->buggy_avid = 1;
+} else if (!strcmp(cbuf, "CS=ITU601"))
+s->cs_itu601 = 1;
+else if ((len > 20 && !strncmp(cbuf, "Intel(R) JPEG Library", 21)) ||
+ (len > 19 && !strncmp(cbuf, "Metasoft MJPEG Codec", 20)))
+s->flipped = 1;
+
+av_free(cbuf);
}
return 0;
@@ -1525,8 +1526,11 @@ int ff_mjpeg_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
else if (start_code >= APP0 && start_code <= APP15)
mjpeg_decode_app(s);
/* Comment */
-else if (start_code == COM)
-mjpeg_decode_com(s);
+else if (start_code == COM) {
+ret = mjpeg_decode_com(s);
+if (ret < 0)
+return ret;
+}
if (!CONFIG_JPEGLS_DECODER &&
(start_code == SOF48 || start_code == LSE)) {
--
2.8.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/5] mpeg4audio: Convert to the new bitstream reader.
On 5/7/2016 11:35 AM, Alexandra Hájková wrote:
> -if (get_bits_long(gb, 32) != MKBETAG('A','L','S','\0'))
> +if (bitstream_read_narrow(bc, 32) != MKBETAG('A','L','S','\0'))
To me, this change pretty much highlights how confusing the new vague
names are. I can't even tell if this change is correct without reading
the source for "bitstream_read_narrow".
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/7] Add the new bitstream reader.
On 5/9/2016 11:41 AM, Alexandra Hájková wrote: > I was foolowing the ML discussion and used the names the majority agreed on, > however I can never satisfy everyone. I'd suggest to consider naming > bikesheding to be over. I must admit though, for people who complain the old names are too confusing, to call a function "_narrow", which as about as vague as it gets, is pretty ... well... confusing. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH] lavc: change semantics of avcodec_send_packet() with 0-sized packets
On 5/5/2016 1:58 PM, wm4 wrote: > But I don't understand why my sample file has this 0-sized packet. If it's an MP4, then it's the index that has them coded like that. You can look at them with boxdumper. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH] lavc: change semantics of avcodec_send_packet() with 0-sized packets
On 5/4/2016 8:40 PM, wm4 wrote: > This fixes behavior with "legitimate" 0-sized packets that appear mid- > stream, and which are _not_ flush packets. I still do not think these packets are "legitimate". The correct fix is to make sure lavf doesn't return 0-sized packets, no? Can anyone inform me the reasoning for returning these at all in the first place? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: Do not enable GPL by default
On 5/4/2016 11:01 PM, Diego Biurrun wrote: > This default was chosen when there was still some amount of > general-purpose code under GPL. Now only special modules are covered by > GPL. When enabling those modules, one can turn on GPL along with them. > --- > tests/fate.sh | 1 - > 1 file changed, 1 deletion(-) What is the gain from this? All this really accomplishes is making sure that if any GPL code is added in the future (e.g. filters), that this needs to be re-added if a test is written. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader
On 5/3/2016 5:19 PM, Vittorio Giovara wrote: > You know, the best way to make a dev care about some code is making > sure that that code is present in that dev's project. > I'm sure Alexandra will happily update her patchset when that poc is > present in Libav. IIRC someone is already working on porting. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Fwd: [RFC PATCH 00/12] Replace the bitstream reader
On 4/29/2016 9:13 AM, Christophe Gisquet wrote: > The results are interesting: > time / size / decode_gray_bitstream _TIMER > 4.16 / 34236 / 190887 UNITS in gray, 262143 runs, 1 skips > 6.41 / 16080 / 283210 UNITS in gray, 262144 runs, 0 skips I'm not entirely sure how to interpret these... which is which? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 00/12] Replace the bitstream reader
On 4/27/2016 1:56 PM, Alexandra Hájková wrote: > I sent this small RFC patchset to be discussed and I'm waiting for > all the opinions You can surely reply to the opinions/questions in the current mails though. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCHv3.1 4/4] mov: Parse uuid box and detect spherical videos
On 4/21/2016 10:24 PM, Vittorio Giovara wrote: > +size_t len = atom.size - sizeof(uuid); > +uint8_t *buffer = av_malloc(len + 1); > +if (!buffer) > +return AVERROR(ENOMEM); > +buffer[len] = '\0'; > + > +ret = ffio_read_size(pb, buffer, len); What happens if atom.size == sizeof(uuid) here? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 6/6] movenc-test: Test signaling of the next fragment start time together with manual flushing
On 4/25/2016 1:25 PM, Martin Storsjö wrote: > --- > libavformat/movenc-test.c | 40 > tests/ref/fate/movenc | 2 ++ > 2 files changed, 42 insertions(+) Unrelated to the patch, but at this point, it may be worth pointing to this file as an example of movenc, or APIs in general, in the docs. It shows a lot of concepts that are not easy to grasp from text alone, IMO. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/6] movenc: Interpret zero sized packets as a hint for the next pts/dts
On 4/25/2016 1:25 PM, Martin Storsjö wrote: > Previously, zero sized packets can be used to signal the nominal > start time for a track, when muxing discontinuously. (That is, > to indicate that the track starts at dts=-1, pts=0, while starting > to mux from dts=99,pts=100, for muxing individual fragments.) > > After this patch, such zero sized packets can also be used to > indicate the next timestamp in a stream. > > For the last packet in a fragment, the muxer uses either pkt->duration > or a heuristic guess based on older packet intervals, to guess what > the start timestamp of the next fragment will be. Once that fragment > has been written, the next fragment must start at that time, and thus > the timestamp of the next packet will be readjusted accordingly. > > If the muxer can cut fragments automatically, it will already know > the next packet and can write the proper packet duration at the end > of the fragment (for the one stream that caused the fragment to be cut). > > If the caller wants to manually flush fragments by calling > av_write_frame(ctx, NULL), the muxer doesn't know the timestamps of > the next packet, and must resort to guessing. > > Such timestamp guessing and readjusting doesn't work perfectly for VFR > streams, even less so for VFR streams with b-frames. > > Therefore, allow a caller that uses manual fragment flushing to > signal the duration of the last packet of a fragment (for any streams > where this info is available), by muxing a zero sized packet with the > same timestamp before flushing. Insert my reply from 2/6 here. > TODO: Should we do this automatically based on packets queued in > the interleaving queues? How ugly would this be compared to its benefit? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/6] libavformat: Don't update cur_dts for empty packets used for signaling
On 4/25/2016 1:25 PM, Martin Storsjö wrote: > If a packet is empty, and the muxer is flagged to treat such packets > specially, don't update cur_dts, to allow a packet with the same > timestamp to be written again later. > --- > libavformat/mux.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Perhaps I'm not entirely reading the intent correctly, but should this not be squashed into 2/6, and 3/6 put before it? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/6] movenc: Use packets in interleaving queues for the duration at the end of fragments
On 4/25/2016 1:25 PM, Martin Storsjö wrote: > As long as caller only writes packets using av_interleaved_write_frame > with no manual flushing, this should allow us to always have accurate > durations at the end of fragments, since there should be at least > one queued packet in each stream (except for the stream where the > current packet is being written, but if the muxer itself does the > cutting of fragments, it also has info about the next packet for that > stream). I think the problem it solves is important, and the implementation is consistent with no the fragmented muxer already works, so OK by me. I'm sure Kieran will be happy he can set the duration of the last frame ;). - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/6] libavformat: Add new public API for interacting with the interleaving queue
On 4/25/2016 1:25 PM, Martin Storsjö wrote: > This doesn't work for the few muxers that implement custom > interleave_packet functions (gxfenc, mxfenc). It seems to me that > they also could be covered, but that would require changing the > signature of the interleave_packet function to split adding packets > and polling/getting packets, which probably would require a major bump. > --- > doc/APIchanges | 4 +++ > libavformat/avformat.h | 33 + > libavformat/mux.c | 79 > +++--- > libavformat/version.h | 4 +-- > 4 files changed, 108 insertions(+), 12 deletions(-) Can these muxers be documented somewhere? e.g. mxfenc is unfortunately rather... used a lot. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 00/12] Replace the bitstream reader
On 4/27/2016 2:40 PM, Hendrik Leppkes wrote: > Testing a high-bitrate video codec that does actually use it may be > beneficial - prores, dnxhd, or any other codec with really high > bitrates. Does CAVLC use it? IIRC 100 mbit h264-intra uses CAVLC. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/6] libavformat: Add new public API for interacting with the interleaving queue
On 4/25/2016 2:56 PM, Luca Barbato wrote: > avformat_mux_queue_pull() <- remove from the queue Would 'pop' not be more descriptive, since it is removed and ownership is transfered? Regardless, I have no strong feelings one way or another. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 02/12] attributes: add av_unlikely macro
On 4/27/2016 12:37 PM, Alexandra Hájková wrote: > --- > libavutil/attributes.h | 6 ++ > 1 file changed, 6 insertions(+) Just for documentation reasons for people not on IRC: [13:58] <@Daemon404> if it can be *proven* to speed up very core bits like bitreading, i am not adverse to using it very sparingly [13:58] <@Daemon404> key word is proven - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader
On 4/27/2016 1:54 PM, Hendrik Leppkes wrote: > That is all internal, and any external code calls get_bits(context, > count), the new one has a different name, but otherwise identical > signature. Some stuff calls the macros directly, for speed reasons. I'm not adverse to having to update those. I'd certainly like to keep get_bits() and stuff the same if possible, though. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 02/12] attributes: add av_unlikely macro
On 4/27/2016 1:41 PM, Christophe Gisquet wrote: > I guess this should be used sparingly, and with benchmark reports to > back the few cases. The problem with measuring perf for likely/unlikely is that half the time it's either negligible or impossible to measure consistently. That's part of what I dislike it (besides being scarred for like from reading GNU source code). - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC PATCH 00/12] Replace the bitstream reader
On 4/27/2016 12:35 PM, Alexandra Hájková wrote: > Greetings, > I'd like to introduce a new bitstream reader I wrote. The advantages of the > new bitreader are: > * it is easier to use: > for example there is just one function to read 0-32 bits instead of > 3 of them in the get_bits.h > * it is more consistent and easier to follow (macros are not needed anymore) > * it is better documented > * it is faster for some decoders (no speed loss when not faster) > * it could be made a public header. > > This work has been sponsored by Luminem.it and it follows the ideas suggested > by Niels Möller in his email from > the time when he was working on DCA XLL extention > (https://www.mail-archive.com/libav-devel%40libav.org/msg57746.html). > > This patchset does some preparation, adds the new bitreader and converts a > few decoders to use it. The following patchets > will subsequently convert all remaning decoders and demuxers that uses > get_bits.h to the new bitreader and original get_bits.h > will be removed in the end of the last patchset. I have several points: 1. Why was was this new impl not adapted to the current get_bits API? Why do we need a giant invasive change to all of avcodec? 2. Why was this (paid!) large patch not really discussed before just... showing up? I really dislike the "well it's already paid for and implemented" mentality this creates when considering whether or not its even a good idea hasn't even been discussed. 3. Some of the points aren't really good arguments for a new API, such as "it is better documented". 4. "it could be made a public header" -> Hell no. Don't bit a bitreader in public API. 5. Not sure I buy "easier to use". 6. Where are the speed test results? You're not going to sell an invasive patch set like this to anyone without very good benefits provided... Just my initial stream of thoughts. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] pgssub: Support BT709 subtitles
On 4/25/2016 5:19 PM, Vittorio Giovara wrote: > I'm ok with lowering the limit of some percentage to accommodate > random resolutions, but you can't really call HD what is not. Semantics vs practicality. - Frtrk ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Update a comment to reflect reality
On 4/19/2016 12:08 PM, Martin Storsjö wrote: > This codepath isn't quite as bad as it used to sound, if fragments > are cut automatically at video packets. > --- > This is mostly a note to future self. > --- > libavformat/movenc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) LGTM. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libxvid: Create extradata in init using a dummy frame
On 4/6/2016 4:12 AM, Tim W. wrote: > It is ugly, but AFAICT that's libxvid's fault; other solution I can imagine > would be to create fake extradata like Anton did for QSV/HEVC/VPS, which is > a lot more work for little benefit. Definitely not worth it for this. Because SO many people encode xvid to not-AVI. -Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libxvid: Create extradata in init using a dummy frame
On 4/5/2016 5:18 PM, Luca Barbato wrote:
>> +xerr = xvid_encore(NULL, XVID_ENC_CREATE, &xvid_enc_create, NULL);
>> +if( xerr ) {
>
> Meh, I'll fix it for you if nothing else crops up.
You should really explain *what* you'll fix, otherwise the review
is useless and I learn nothing new.
>
>> +av_frame_free(&picture);
>> +av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder
>> reference\n");
>> +return AVERROR_UNKNOWN;
>> +}
>> +x->encoder_handle = xvid_enc_create.handle;
>> +size = ((avctx->width + 1) & ~1) * ((avctx->height + 1) & ~1);
>
> Same
Same.
> I guess, as ugly as it could be, it is a solution. I wonder if it
> shouldn't be called always though.
It's not needed unless there is a global header. Same as x264 and x265.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] libxvid: Create extradata in init using a dummy frame
Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.
Heavily based off of a patch from 2012 by Nicolas George.
Signed-off-by: Derek Buitenhuis
---
Fixes encoding xvid to mov.
---
libavcodec/libxvid.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index b352849..8ae18ae 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -85,6 +85,10 @@ struct xvid_ff_pass1 {
struct xvid_context *context; /**< Pointer to private context */
};
+static int xvid_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
+ const AVFrame *picture, int *got_packet);
+
+
/*
* Xvid 2-Pass Kludge Section
*
@@ -677,6 +681,43 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (avctx->max_b_frames > 0 && !x->quicktime_format)
xvid_enc_create.global |= XVID_GLOBAL_PACKED;
+/* Encode a dummy frame to get the extradata immediately */
+if (x->quicktime_format) {
+AVFrame *picture;
+AVPacket packet;
+int size, got_packet, ret;
+
+av_init_packet(&packet);
+
+picture = av_frame_alloc();
+if (!picture)
+return AVERROR(ENOMEM);
+
+xerr = xvid_encore(NULL, XVID_ENC_CREATE, &xvid_enc_create, NULL);
+if( xerr ) {
+av_frame_free(&picture);
+av_log(avctx, AV_LOG_ERROR, "Xvid: Could not create encoder
reference\n");
+return AVERROR_UNKNOWN;
+}
+x->encoder_handle = xvid_enc_create.handle;
+size = ((avctx->width + 1) & ~1) * ((avctx->height + 1) & ~1);
+picture->data[0] = av_malloc(size + size / 2);
+if (!picture->data[0]) {
+av_frame_free(&picture);
+return AVERROR(ENOMEM);
+}
+picture->data[1] = picture->data[0] + size;
+picture->data[2] = picture->data[1] + size / 4;
+memset(picture->data[0], 0, size);
+memset(picture->data[1], 128, size / 2);
+ret = xvid_encode_frame(avctx, &packet, picture, &got_packet);
+if (!ret && got_packet)
+av_packet_unref(&packet);
+av_free(picture->data[0]);
+av_frame_free(&picture);
+xvid_encore(x->encoder_handle, XVID_ENC_DESTROY, NULL, NULL);
+}
+
/* Create encoder context */
xerr = xvid_encore(NULL, XVID_ENC_CREATE, &xvid_enc_create, NULL);
if (xerr) {
--
2.8.0.rc3
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RFC] Handling of major version bumps
Some context: https://mailman.videolan.org/pipermail/vlc-devel/2016-February/106310.html Basically, I would like to propose the following: In the future, for major version bumps, we should push the commit which bumps the version before the big list of commits that remove all the deprecated code, rather than after. The reasons are as follows: 1. All the deprecated code is already hidden under deprecation guards which check the version. This would properly be disabled with a version bump, ensuring that at no point in the git history, does this new major version contain usable versions of the deprecated to-be-remove APIs. 2. It ensures that at no point in the git history has a feature removed without a way check for it via version, as has occurred previously, if you were to pull or checkout a commit in between code removal and version bump. Comments and arguments/reasoning for the current procedure are welcome. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 01/25] fate: Add test for WMV2 with jframes
On 2/23/2016 1:17 AM, Vittorio Giovara wrote: > --- > The test sample is already on FATE strangely enough. > Vittorio > > tests/fate/microsoft.mak| 3 + > tests/ref/fate/wmv8-intrax8 | 475 > > 2 files changed, 478 insertions(+) > create mode 100644 tests/ref/fate/wmv8-intrax8 I'm pretty sure it was removed at some point because it was not a portable test for some reason or another. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] build: Add idct dependency to dct test
On 2/20/2016 7:36 PM, Vittorio Giovara wrote: > I am able to reproduce with that exact same line, on OSX, with clang and gcc A real (ports) GCC or the llvm-gcc that apple ships? Could be the same DCE bug if so? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] flacenc: Restore defaults and range for {min, max}_prediction_order
This was broken in 243df1351d2d928caa084a5704ed783f0b83f072.
Signed-off-by: Derek Buitenhuis
---
The default was changed to be out of range and caused warnings to be
printed for default values.
---
libavcodec/flacenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index e25e867..81c3bb6 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -1350,8 +1350,8 @@ static const AVOption options[] = {
{ "left_side", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FLAC_CHMODE_LEFT_SIDE
}, INT_MIN, INT_MAX, FLAGS, "ch_mode" },
{ "right_side", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FLAC_CHMODE_RIGHT_SIDE
}, INT_MIN, INT_MAX, FLAGS, "ch_mode" },
{ "mid_side", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = FLAC_CHMODE_MID_SIDE
}, INT_MIN, INT_MAX, FLAGS, "ch_mode" },
-{ "min_prediction_order", NULL, offsetof(FlacEncodeContext,
options.min_prediction_order), AV_OPT_TYPE_INT, { .i64 = 0 }, MIN_LPC_ORDER,
MAX_LPC_ORDER, FLAGS },
-{ "max_prediction_order", NULL, offsetof(FlacEncodeContext,
options.max_prediction_order), AV_OPT_TYPE_INT, { .i64 = 0 }, MIN_LPC_ORDER,
MAX_LPC_ORDER, FLAGS },
+{ "min_prediction_order", NULL, offsetof(FlacEncodeContext,
options.min_prediction_order), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
MAX_LPC_ORDER, FLAGS },
+{ "max_prediction_order", NULL, offsetof(FlacEncodeContext,
options.max_prediction_order), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
MAX_LPC_ORDER, FLAGS },
{ NULL },
};
--
2.7.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] msvc: Fix libx264 linking
On 1/28/2016 4:11 PM, Henrik Gramner wrote: > --- > configure | 1 + > 1 file changed, 1 insertion(+) OK. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libavcodec/util: Fix timebase overflow check
On 1/27/2016 10:16 PM, Luca Barbato wrote: > When it is zero? (isn't there a check before to sanitize the time_base ?) I only see a check for audio. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] libavcodec/util: Fix timebase overflow check
It could accidentally divide by zero if num was zero.
Signed-off-by: Derek Buitenhuis
---
libavcodec/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e06ee66..a3cb341 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1050,7 +1050,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!avctx->rc_initial_buffer_occupancy)
avctx->rc_initial_buffer_occupancy = avctx->rc_buffer_size * 3 / 4;
-if (avctx->ticks_per_frame &&
+if (avctx->ticks_per_frame && avctx->time_base.num &&
avctx->ticks_per_frame > INT_MAX / avctx->time_base.num) {
av_log(avctx, AV_LOG_ERROR,
"ticks_per_frame %d too large for the timebase %d/%d.",
--
2.7.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] h264: Print the complete user message
On 10/22/2015 1:13 PM, Vittorio Giovara wrote: > This will allow dumping the complete x264 encode info when needed. strings(1) - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] mov: Add an option to toggle dref opening
This feature is mostly only used by NLE software, and is
both of dubious value being enabled by default, and a
possible security risk.
Signed-off-by: Derek Buitenhuis
---
libavformat/isom.h| 1 +
libavformat/mov.c | 20
libavformat/version.h | 2 +-
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index d81d435..aec623b 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -159,6 +159,7 @@ typedef struct MOVContext {
int64_t next_root_atom; ///< offset of the next root atom
int export_all;
int export_xmp;
+int enable_drefs;
} MOVContext;
int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index aaf1c2d..0a1eefc 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2484,12 +2484,22 @@ static int mov_read_trak(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
if (sc->dref_id-1 < sc->drefs_count && sc->drefs[sc->dref_id-1].path) {
MOVDref *dref = &sc->drefs[sc->dref_id - 1];
-if (mov_open_dref(&sc->pb, c->fc->filename, dref,
&c->fc->interrupt_callback) < 0)
-av_log(c->fc, AV_LOG_ERROR,
- "stream %d, error opening alias: path='%s', dir='%s', "
- "filename='%s', volume='%s', nlvl_from=%d, nlvl_to=%d\n",
+if (c->enable_drefs) {
+if (mov_open_dref(&sc->pb, c->fc->filename, dref,
&c->fc->interrupt_callback) < 0)
+av_log(c->fc, AV_LOG_ERROR,
+ "stream %d, error opening alias: path='%s', dir='%s', "
+ "filename='%s', volume='%s', nlvl_from=%d,
nlvl_to=%d\n",
+ st->index, dref->path, dref->dir, dref->filename,
+ dref->volume, dref->nlvl_from, dref->nlvl_to);
+} else {
+av_log(c->fc, AV_LOG_WARNING,
+ "Skipped opening external track: "
+ "stream %d, alias: path='%s', dir='%s', "
+ "filename='%s', volume='%s', nlvl_from=%d, nlvl_to=%d."
+ "Set enable_drefs to allow this.\n",
st->index, dref->path, dref->dir, dref->filename,
dref->volume, dref->nlvl_from, dref->nlvl_to);
+}
} else
sc->pb = c->fc->pb;
@@ -3643,6 +3653,8 @@ static const AVOption mov_options[] = {
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = FLAGS },
{ "export_xmp", "Export full XMP metadata", OFFSET(export_xmp),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = FLAGS },
+{ "enable_drefs", "Enable external track support.", OFFSET(enable_drefs),
+AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
{ NULL },
};
diff --git a/libavformat/version.h b/libavformat/version.h
index e29e4eb..a003a8b 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,7 +30,7 @@
#include "libavutil/version.h"
#define LIBAVFORMAT_VERSION_MAJOR 57
-#define LIBAVFORMAT_VERSION_MINOR 2
+#define LIBAVFORMAT_VERSION_MINOR 3
#define LIBAVFORMAT_VERSION_MICRO 0
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Use pkg-config to check for openssl
On 1/15/2016 5:10 PM, Luca Barbato wrote: > --- > > Possibly we could drop the 3 lines above. > > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Normally I'm all for pkg-config. However for OpenSSL, it is a system library on some platforms and does not have a .pc file, AFAIK. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Cineform HD Decoder:
On 1/4/2016 8:32 AM, Anton Khirnov wrote: > missing the props, probably lossy+intraonly Some CFHD files seem to have skip frames, so perhaps not the latter? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [libav-commits] lavc: Deprecate coder_type and its symbols
On 1/3/2016 8:09 PM, Diego Biurrun wrote: > This is wrong, not just in name. Perhaps you should actually say how. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH v3 0/3] OSX video support
On 11/27/2015 2:15 PM, Derek Buitenhuis wrote: > I'm going to be devil's advocate here, and ask: > > Why was this written from scratch, rather than backporting > from FFmpeg, which already has a fully working implementation? > What technical advantages does it bring? > > P.S. Preemptively: Do not bring politics into this please, I am > asking a purely technical question, only. Eh, some emails seem to have been put in my spam folder, and this has already been discussed. Woops. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH v3 0/3] OSX video support
Hi, On 11/23/2015 10:08 PM, Alexandre Lision wrote: > Changes since v2: > - commits restructuration > > Alexandre Lision (2): > avfoundation: basic working implementation > avfoundation: add optionnal AVOptions > > Luca Barbato (1): > configure: ObjC support I'm going to be devil's advocate here, and ask: Why was this written from scratch, rather than backporting from FFmpeg, which already has a fully working implementation? What technical advantages does it bring? P.S. Preemptively: Do not bring politics into this please, I am asking a purely technical question, only. Cheers, - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] doc: Document better how to use MSYS2
On 11/23/2015 12:05 PM, Luca Barbato wrote:
> -@item Building natively using MSYS2 can be sped up by disabling implicit
> rules
> -in the Makefile by calling @code{make -r} instead of plain @code{make}. This
> +@item Native MSYS building is discouraged, MSYS2 provides a full mingw-w64
> +environment through @file{mingw64_shell.bat} or @file{mingw32_shell.bat}
> +that should be used instead of the environment provides by
> +@file{msys2_shell.bat}.
I think it should be clarified what "Native MSYS" means. It sounds a bit
ambiguous,
kind of like it refers to native Windows, which is the opposite of what the MSYS
compiler will do. I don't mind an extra few sentences here.
> +@subsection Native Windows compilation using MSYS2
> +
> +The MSYS2 MinGW-w64 environment provides ready to use toolchains and
> dependencies
> +through @command{pacman}.
> +
> +Make sure to use @file{mingw64_shell.bat} or @file{mingw32_shell.bat} to have
> +the correct MinGW-w64 environment.
Maybe list the start menu shortcut names?
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] oggparsespeex: Fix unchecked malloc
Signed-off-by: Derek Buitenhuis
---
libavformat/oggparsespeex.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/oggparsespeex.c b/libavformat/oggparsespeex.c
index f7af794..3cc9012 100644
--- a/libavformat/oggparsespeex.c
+++ b/libavformat/oggparsespeex.c
@@ -47,6 +47,8 @@ static int speex_header(AVFormatContext *s, int idx) {
if (!spxp) {
spxp = av_mallocz(sizeof(*spxp));
+if (!spxp)
+return AVERROR(ENOMEM);
os->private = spxp;
}
--
2.6.2
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] configure: Support msys2 out of box
On 11/21/2015 10:51 AM, Henrik Gramner wrote: > Is there any downside of making stuff "just work" (tm) with the > default msys shell? Yes. The default msys2 shell may have 'gcc' as the msys compiler. That is, not mingw, but a special compiler that compiles the system binaries for msys, like bash.exe. I think it would only lead to more confusion. The proper 'fix' is to have msys2 better documented. In the meantime, we could update platforms.texi with the relevant info. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] dca: Integer core decoder.
Random lazy questions incoming. On 11/13/2015 5:11 PM, Alexandra Hájková wrote: > Provide a bit-exact reconstruction. > > The dca core decoder converts integer coefficients read from the > bitstream to floats just after reading them (along with dequantization). > All the other steps of the audio reconstruction are done with floats > which makes the output for the DTS lossless extension (XLL) > actually lossy. > This patch trasforms the dca core to work with integer coefficients > till the point QMF filters are called. The integer coefficients are > transformed to floats at this point if needed, the new bitexact QMF > filters are used for the XLL streams or for the case the new > -force_fixed option is set. This option forces fixed-point > reconstruction for any kind of input. > --- > doc/decoders.texi | 9 + > libavcodec/dca.h | 13 +- > libavcodec/dca_exss.c | 7 + > libavcodec/dcadec.c | 253 + > libavcodec/dcadsp.c | 500 > +- > libavcodec/dcadsp.h | 15 +- > 6 files changed, 711 insertions(+), 86 deletions(-) Was this tested against any known sample input/output? > + * The functions idct_perform32_fixed, qmf_32_subbands_fixed, > idct_perform64_fixed, > + * qmf_64_subbands_fixed and the auxiliary functions they are using are > adapted > + * from libdcadec, https://github.com/foo86/dcadec/tree/master/libdcadec. You need to fix up these functions so they do not use for loops with variable declarations in them, and also add him to the copyright. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 016/264] mxfenc: always assume long gop
On 11/9/2015 6:35 AM, Anton Khirnov wrote: > This is just for mpeg2 video. I have no idea what it does for othe > codecs. Intra-only mpeg-2 in mxf is pretty common... - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 007/264] libx264: export CPB props side data
On 11/8/2015 7:57 PM, Anton Khirnov wrote: > --- > libavcodec/libx264.c | 8 > 1 file changed, 8 insertions(+) Missing libx265.c? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 016/264] mxfenc: always assume long gop
On 11/8/2015 7:57 PM, Anton Khirnov wrote: > Checking the codec context parameters to find out this information is > far too unreliable to be useful, so it is safer to assume B-frames are > always present. > --- > libavformat/mxfenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Isn't this kind of suboptimal for intra-only stuff like DCP or one of the many mezzanine formats that use mxf? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] aac: Make codec init run under ff_thread_once
This makes AAC init threadsafe.
Signed-off-by: Derek Buitenhuis
---
libavcodec/aacdec.c | 84 +++--
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index f0c7960..e2e02b4 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -110,6 +110,8 @@
# include "arm/aac.h"
#endif
+#include "libavutil/thread.h"
+
static VLC vlc_scalefactors;
static VLC vlc_spectral[11];
@@ -1003,11 +1005,56 @@ static void reset_predictor_group(PredictorState *ps,
int group_num)
sizeof(ff_aac_spectral_codes[num][0]), \
size);
+static av_cold void aac_static_table_init()
+{
+AAC_INIT_VLC_STATIC( 0, 304);
+AAC_INIT_VLC_STATIC( 1, 270);
+AAC_INIT_VLC_STATIC( 2, 550);
+AAC_INIT_VLC_STATIC( 3, 300);
+AAC_INIT_VLC_STATIC( 4, 328);
+AAC_INIT_VLC_STATIC( 5, 294);
+AAC_INIT_VLC_STATIC( 6, 306);
+AAC_INIT_VLC_STATIC( 7, 268);
+AAC_INIT_VLC_STATIC( 8, 510);
+AAC_INIT_VLC_STATIC( 9, 366);
+AAC_INIT_VLC_STATIC(10, 462);
+
+ff_aac_sbr_init();
+
+ff_aac_tableinit();
+
+INIT_VLC_STATIC(&vlc_scalefactors, 7,
+FF_ARRAY_ELEMS(ff_aac_scalefactor_code),
+ff_aac_scalefactor_bits,
+sizeof(ff_aac_scalefactor_bits[0]),
+sizeof(ff_aac_scalefactor_bits[0]),
+ff_aac_scalefactor_code,
+sizeof(ff_aac_scalefactor_code[0]),
+sizeof(ff_aac_scalefactor_code[0]),
+352);
+
+
+// window initialization
+ff_kbd_window_init(ff_aac_kbd_long_1024, 4.0, 1024);
+ff_kbd_window_init(ff_aac_kbd_short_128, 6.0, 128);
+ff_init_ff_sine_windows(10);
+ff_init_ff_sine_windows( 9);
+ff_init_ff_sine_windows( 7);
+
+cbrt_tableinit();
+}
+
+static AVOnce aac_init = AV_ONCE_INIT;
+
static av_cold int aac_decode_init(AVCodecContext *avctx)
{
AACContext *ac = avctx->priv_data;
int ret;
+ret = ff_thread_once(&aac_init, &aac_static_table_init);
+if (ret != 0)
+return AVERROR_UNKNOWN;
+
ac->avctx = avctx;
ac->oc[1].m4ac.sample_rate = avctx->sample_rate;
@@ -1049,36 +1096,10 @@ static av_cold int aac_decode_init(AVCodecContext
*avctx)
}
}
-AAC_INIT_VLC_STATIC( 0, 304);
-AAC_INIT_VLC_STATIC( 1, 270);
-AAC_INIT_VLC_STATIC( 2, 550);
-AAC_INIT_VLC_STATIC( 3, 300);
-AAC_INIT_VLC_STATIC( 4, 328);
-AAC_INIT_VLC_STATIC( 5, 294);
-AAC_INIT_VLC_STATIC( 6, 306);
-AAC_INIT_VLC_STATIC( 7, 268);
-AAC_INIT_VLC_STATIC( 8, 510);
-AAC_INIT_VLC_STATIC( 9, 366);
-AAC_INIT_VLC_STATIC(10, 462);
-
-ff_aac_sbr_init();
-
avpriv_float_dsp_init(&ac->fdsp, avctx->flags & AV_CODEC_FLAG_BITEXACT);
ac->random_state = 0x1f2e3d4c;
-ff_aac_tableinit();
-
-INIT_VLC_STATIC(&vlc_scalefactors, 7,
-FF_ARRAY_ELEMS(ff_aac_scalefactor_code),
-ff_aac_scalefactor_bits,
-sizeof(ff_aac_scalefactor_bits[0]),
-sizeof(ff_aac_scalefactor_bits[0]),
-ff_aac_scalefactor_code,
-sizeof(ff_aac_scalefactor_code[0]),
-sizeof(ff_aac_scalefactor_code[0]),
-352);
-
ff_mdct_init(&ac->mdct, 11, 1, 1.0 / (32768.0 * 1024.0));
ff_mdct_init(&ac->mdct_ld,10, 1, 1.0 / (32768.0 * 512.0));
ff_mdct_init(&ac->mdct_small, 8, 1, 1.0 / (32768.0 * 128.0));
@@ -1087,15 +1108,6 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
if (ret < 0)
return ret;
-// window initialization
-ff_kbd_window_init(ff_aac_kbd_long_1024, 4.0, 1024);
-ff_kbd_window_init(ff_aac_kbd_short_128, 6.0, 128);
-ff_init_ff_sine_windows(10);
-ff_init_ff_sine_windows( 9);
-ff_init_ff_sine_windows( 7);
-
-cbrt_tableinit();
-
return 0;
}
@@ -3321,6 +,7 @@ AVCodec ff_aac_decoder = {
AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
},
.capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
.channel_layouts = aac_channel_layout,
};
@@ -3342,5 +3355,6 @@ AVCodec ff_aac_latm_decoder = {
AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
},
.capabilities= AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
.channel_layouts = aac_channel_layout,
};
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avcodec: Don't lock during init if there is no init function
Signed-off-by: Derek Buitenhuis
---
libavcodec/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index a1aece7..430926d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -845,7 +845,7 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
av_dict_copy(&tmp, *options, 0);
/* If there is a user-supplied mutex locking routine, call it. */
-if (!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE)) {
+if (!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE) && codec->init)
{
if (lockmgr_cb) {
if ((*lockmgr_cb)(&codec_mutex, AV_LOCK_OBTAIN))
return -1;
@@ -1086,7 +1086,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
#endif
}
end:
-if (!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE)) {
+if (!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE) && codec->init)
{
entangled_thread_counter--;
/* Release any user-supplied mutex. */
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] h264: Run VLC init under pthread_once
On 10/8/2015 9:08 AM, Rémi Denis-Courmont wrote: > I would assert and abort here. The most likely problems here are > deadlocks (i.e. recursive initialization) and memory corruption (once > ff_h264_vlc_init is garbage)... I initially had this since Hendrik's patch could fail, but that is no longer the case. I have no strong opinion on what to do in the error case - you're screwed regardless. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] h264: Run VLC init under pthread_once
On 10/7/2015 5:44 PM, Luca Barbato wrote: > Do you plan to use it outside somehow? The rest seems fine. No. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 0/2] h264: Threadsafe Initialization
Towards a glorious non-locking future. Anton Khirnov (1): cabac: Make CABAC states hardcoded. Derek Buitenhuis (1): h264: Run VLC init under pthread_once libavcodec/cabac.c | 225 --- libavcodec/cabac.h | 3 +- libavcodec/cabac_functions.h | 8 +- libavcodec/h264.c| 11 ++- libavcodec/h264.h| 1 + libavcodec/hevc.c| 2 - 6 files changed, 138 insertions(+), 112 deletions(-) -- 1.8.3.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] h264: Run VLC init under pthread_once
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264.c | 9 -
libavcodec/h264.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 4c1e135..0a0db9a 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -606,6 +606,8 @@ static int h264_init_context(AVCodecContext *avctx,
H264Context *h)
return 0;
}
+static pthread_once_t ff_h264_vlc_init = PTHREAD_ONCE_INIT;
+
av_cold int ff_h264_decode_init(AVCodecContext *avctx)
{
H264Context *h = avctx->priv_data;
@@ -619,7 +621,11 @@ av_cold int ff_h264_decode_init(AVCodecContext *avctx)
if (!avctx->has_b_frames)
h->low_delay = 1;
-ff_h264_decode_init_vlc();
+ret = pthread_once(&ff_h264_vlc_init, &ff_h264_decode_init_vlc);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "pthread_once has failed.");
+return AVERROR_UNKNOWN;
+}
if (avctx->codec_id == AV_CODEC_ID_H264) {
if (avctx->ticks_per_frame == 1)
@@ -1801,6 +1807,7 @@ AVCodec ff_h264_decoder = {
.capabilities = /*AV_CODEC_CAP_DRAW_HORIZ_BAND |*/
AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_DELAY | AV_CODEC_CAP_SLICE_THREADS |
AV_CODEC_CAP_FRAME_THREADS,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
.flush = flush_dpb,
.init_thread_copy = ONLY_IF_THREADS_ENABLED(decode_init_thread_copy),
.update_thread_context =
ONLY_IF_THREADS_ENABLED(ff_h264_update_thread_context),
diff --git a/libavcodec/h264.h b/libavcodec/h264.h
index bf8b07e..e9fd9cc 100644
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -29,6 +29,7 @@
#define AVCODEC_H264_H
#include "libavutil/intreadwrite.h"
+#include "libavutil/thread.h"
#include "cabac.h"
#include "error_resilience.h"
#include "get_bits.h"
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] cabac: Make CABAC states hardcoded.
From: Anton Khirnov
There's not much reason to generate such a small table at runtime.
Signed-off-by: Derek Buitenhuis
---
libavcodec/cabac.c | 225 ---
libavcodec/cabac.h | 3 +-
libavcodec/cabac_functions.h | 8 +-
libavcodec/h264.c| 2 -
libavcodec/hevc.c| 2 -
5 files changed, 129 insertions(+), 111 deletions(-)
diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
index b6f56f0..7df0648 100644
--- a/libavcodec/cabac.c
+++ b/libavcodec/cabac.c
@@ -31,75 +31,130 @@
#include "cabac.h"
#include "cabac_functions.h"
-uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
- 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
- 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
- 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
- 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
-};
-
-static const uint8_t lps_range[64][4]= {
-{128,176,208,240}, {128,167,197,227}, {128,158,187,216}, {123,150,178,205},
-{116,142,169,195}, {111,135,160,185}, {105,128,152,175}, {100,122,144,166},
-{ 95,116,137,158}, { 90,110,130,150}, { 85,104,123,142}, { 81, 99,117,135},
-{ 77, 94,111,128}, { 73, 89,105,122}, { 69, 85,100,116}, { 66, 80, 95,110},
-{ 62, 76, 90,104}, { 59, 72, 86, 99}, { 56, 69, 81, 94}, { 53, 65, 77, 89},
-{ 51, 62, 73, 85}, { 48, 59, 69, 80}, { 46, 56, 66, 76}, { 43, 53, 63, 72},
-{ 41, 50, 59, 69}, { 39, 48, 56, 65}, { 37, 45, 54, 62}, { 35, 43, 51, 59},
-{ 33, 41, 48, 56}, { 32, 39, 46, 53}, { 30, 37, 43, 50}, { 29, 35, 41, 48},
-{ 27, 33, 39, 45}, { 26, 31, 37, 43}, { 24, 30, 35, 41}, { 23, 28, 33, 39},
-{ 22, 27, 32, 37}, { 21, 26, 30, 35}, { 20, 24, 29, 33}, { 19, 23, 27, 31},
-{ 18, 22, 26, 30}, { 17, 21, 25, 28}, { 16, 20, 23, 27}, { 15, 19, 22, 25},
-{ 14, 18, 21, 24}, { 14, 17, 20, 23}, { 13, 16, 19, 22}, { 12, 15, 18, 21},
-{ 12, 14, 17, 20}, { 11, 14, 16, 19}, { 11, 13, 15, 18}, { 10, 12, 15, 17},
-{ 10, 12, 14, 16}, { 9, 11, 13, 15}, { 9, 11, 12, 14}, { 8, 10, 12, 14},
-{ 8, 9, 11, 13}, { 7, 9, 11, 12}, { 7, 9, 10, 12}, { 7, 8, 10, 11},
-{ 6, 8, 9, 11}, { 6, 7, 9, 10}, { 6, 7, 8, 9}, { 2, 2, 2, 2},
-};
-
-static const uint8_t mps_state[64]= {
- 1, 2, 3, 4, 5, 6, 7, 8,
- 9,10,11,12,13,14,15,16,
- 17,18,19,20,21,22,23,24,
- 25,26,27,28,29,30,31,32,
- 33,34,35,36,37,38,39,40,
- 41,42,43,44,45,46,47,48,
- 49,50,51,52,53,54,55,56,
- 57,58,59,60,61,62,62,63,
-};
-
-static const uint8_t lps_state[64]= {
- 0, 0, 1, 2, 2, 4, 4, 5,
- 6, 7, 8, 9, 9,11,11,12,
- 13,13,15,15,16,16,18,18,
- 19,19,21,21,22,22,23,24,
- 24,25,26,26,27,27,28,29,
- 29,30,30,30,31,32,32,33,
- 33,33,34,34,35,35,35,36,
- 36,36,37,37,37,38,38,63,
-};
-
-static const uint8_t last_coeff_flag_offset_8x8[63] = {
- 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
- 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
- 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4,
- 5, 5, 5, 5, 6, 6, 6, 6, 7, 7, 7, 7, 8, 8, 8
+const uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
+9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
+4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
+3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
+3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
+2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
+2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
+2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
+2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
Re: [libav-devel] [PATCH][RFC] avcodec: Don't lock during open for codecs marked as having threadsafe init
On 10/1/2015 4:16 PM, Hendrik Leppkes wrote: > Isn't this and the condition above backwards? Oh, yep! I got confused when backporting from my FFmpeg version, since it needs the opposite... - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH][RFC] avcodec: Don't lock during open for codecs marked as having threadsafe init
On 10/1/2015 4:00 PM, wm4 wrote: > Is this a preparation for a long, painful transition, or just a way to > workaround your particular failure case? Depends what you mean transitioning to. Currently, I'm just making the existing flag actually *do* something useful. (I will be converting codecs to all have threadsafe init, and this flag slowly as well, but this lets stuff work in the intermin.) - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH][RFC] avcodec: Don't lock during open for codecs marked as having threadsafe init
Signed-off-by: Derek Buitenhuis
---
libavcodec/utils.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 1721c09..586e7be 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -845,20 +845,21 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
av_dict_copy(&tmp, *options, 0);
/* If there is a user-supplied mutex locking routine, call it. */
-if (lockmgr_cb) {
-if ((*lockmgr_cb)(&codec_mutex, AV_LOCK_OBTAIN))
-return -1;
-}
+if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE) {
+if (lockmgr_cb) {
+if ((*lockmgr_cb)(&codec_mutex, AV_LOCK_OBTAIN))
+return -1;
+}
-entangled_thread_counter++;
-if (entangled_thread_counter != 1 &&
-!(codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE)) {
-av_log(avctx, AV_LOG_ERROR,
- "Insufficient thread locking. At least %d threads are "
- "calling avcodec_open2() at the same time right now.\n",
- entangled_thread_counter);
-ret = -1;
-goto end;
+entangled_thread_counter++;
+if (entangled_thread_counter != 1) {
+av_log(avctx, AV_LOG_ERROR,
+ "Insufficient thread locking. At least %d threads are "
+ "calling avcodec_open2() at the same time right now.\n",
+ entangled_thread_counter);
+ret = -1;
+goto end;
+}
}
avctx->internal = av_mallocz(sizeof(AVCodecInternal));
@@ -1085,12 +1086,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
#endif
}
end:
-entangled_thread_counter--;
+if (codec->caps_internal & FF_CODEC_CAP_INIT_THREADSAFE) {
+entangled_thread_counter--;
-/* Release any user-supplied mutex. */
-if (lockmgr_cb) {
-(*lockmgr_cb)(&codec_mutex, AV_LOCK_RELEASE);
+/* Release any user-supplied mutex. */
+if (lockmgr_cb) {
+(*lockmgr_cb)(&codec_mutex, AV_LOCK_RELEASE);
+}
}
+
if (options) {
av_dict_free(options);
*options = tmp;
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Don't require a global sidx box to write the dash brand
On 9/23/2015 2:11 PM, Martin Storsjö wrote: > On Wed, 23 Sep 2015, Derek Buitenhuis wrote: > >> There's no reason this should be required. >> >> Signed-off-by: Derek Buitenhuis >> --- >> As far as I know, anyway. >> --- >> libavformat/movenc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavformat/movenc.c b/libavformat/movenc.c >> index ee2f089..90857e3 100644 >> --- a/libavformat/movenc.c >> +++ b/libavformat/movenc.c >> @@ -2977,7 +2977,7 @@ static int mov_write_ftyp_tag(AVIOContext *pb, >> AVFormatContext *s) >> else if (mov->mode == MODE_MP4) >> ffio_wfourcc(pb, "mp41"); >> >> -if (mov->flags & FF_MOV_FLAG_DASH && mov->flags & >> FF_MOV_FLAG_GLOBAL_SIDX) >> +if (mov->flags & FF_MOV_FLAG_DASH) >> ffio_wfourcc(pb, "dash"); >> >> return update_size(pb, pos); >> -- >> 1.8.3.1 > > Ok with me. (The original cause of this code is that I originally tried to > mimic different files for different usecases produced by other software, > and the m4s init segments I looked at lacked this brand. But I do agree > that it probably should be added.) > Seems I was wrong: [14:13] < Daemon404> muken, ping [14:13] < Daemon404> any comment ? [14:36] < muken> Daemon404: you're wrong since dash brand means Indexed self-initialized media segment [14:36] < Daemon404> this is why i asked you [14:36] < Daemon404> i am often wrong. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] movenc: Don't require a global sidx box to write the dash brand
There's no reason this should be required. Signed-off-by: Derek Buitenhuis --- As far as I know, anyway. --- libavformat/movenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index ee2f089..90857e3 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -2977,7 +2977,7 @@ static int mov_write_ftyp_tag(AVIOContext *pb, AVFormatContext *s) else if (mov->mode == MODE_MP4) ffio_wfourcc(pb, "mp41"); -if (mov->flags & FF_MOV_FLAG_DASH && mov->flags & FF_MOV_FLAG_GLOBAL_SIDX) +if (mov->flags & FF_MOV_FLAG_DASH) ffio_wfourcc(pb, "dash"); return update_size(pb, pos); -- 1.8.3.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] tiny_psnr: Use the correct abs() version
On 9/22/2015 4:20 PM, Luca Barbato wrote: > Uhm we have some already. MSDN must be lying to me... - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] tiny_psnr: Use the correct abs() version
On 9/22/2015 12:56 PM, Vittorio Giovara wrote: > -dist = abs(a - b); > +dist = llabs(a - b); I don't think llabs is supported everywhere. e.g. MSVC, I think, has has only had it since MSVS 2013. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] [RFC] use a wrapper script to call MS link.exe to avoid mixing with /usr/bin/link.exe
On 7/23/2015 6:23 PM, Steve Lhomme wrote: > What's the other alternative ? dirname is always used as $(dirname > $xyz) in configure. Is $(dirname "`command -v cl`") not equivalent to $(dirname "$(command -v cl)") ? Maybe I am lacking in my shell-fu. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] [RFC] use a wrapper script to call MS link.exe to avoid mixing with /usr/bin/link.exe
On 7/23/2015 6:02 PM, Derek Buitenhuis wrote: > On 7/23/2015 5:41 PM, Steve Lhomme wrote: Looping in the other list, cause I forgot. >> -- >> favor link over link.exe in case some wrapper script already exists >> fallback to "link" in the path if the one next to cl is not found >> --- >> configure | 2 +- >> tools/mslink.sh | 9 + > > Should be under compat. > >> diff --git a/tools/mslink.sh b/tools/mslink.sh >> new file mode 100644 > > Broken permissions. > > Can do without the .sh extension (see for example, makedef). > >> index 000..6f0d98f >> --- /dev/null >> +++ b/tools/mslink.sh >> @@ -0,0 +1,9 @@ >> +#!/bin/sh >> + >> +LINK_EXE_PATH=$(dirname "`command -v cl`")/link > > Be consistent with the usage of $(). > > The idea itself seems reasonable. > > - Derek > ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] [RFC] use a wrapper script to call MS link.exe to avoid mixing with /usr/bin/link.exe
On 7/23/2015 5:41 PM, Steve Lhomme wrote: > -- > favor link over link.exe in case some wrapper script already exists > fallback to "link" in the path if the one next to cl is not found > --- > configure | 2 +- > tools/mslink.sh | 9 + Should be under compat. > diff --git a/tools/mslink.sh b/tools/mslink.sh > new file mode 100644 Broken permissions. Can do without the .sh extension (see for example, makedef). > index 000..6f0d98f > --- /dev/null > +++ b/tools/mslink.sh > @@ -0,0 +1,9 @@ > +#!/bin/sh > + > +LINK_EXE_PATH=$(dirname "`command -v cl`")/link Be consistent with the usage of $(). The idea itself seems reasonable. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: force WINAPI_FAMILY to WINAPI_FAMILY_DESKTOP_APP to detect DVXA
On 7/23/2015 5:35 PM, Martin Storsjö wrote: > With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC? This will never be a supported set up. Ever. It's a hack. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Dropping Windows XP and Windows 2003 support
On 7/2/2015 12:42 PM, Steve Lhomme wrote: > What version of Windows is Wine equivalent to these days ? One that doesn't exist. It implements APIs as they are needed, so it's a mishmash. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] configure: Check for x265_api_get
Any other x265 symbol may not exported, e.g. if the build is a
multilib (10-bit and 8-bit in one) build.
This is the only symbol we directly call, and is available in the
build number we check for.
Fixes the configure check on multilib x265 builds.
Signed-off-by: Derek Buitenhuis
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 6466ed3..078cd33 100755
--- a/configure
+++ b/configure
@@ -4347,7 +4347,7 @@ enabled libwebp && require_pkg_config libwebp
webp/encode.h WebPGetEnc
enabled libx264 && require_pkg_config x264 "stdint.h x264.h"
x264_encoder_encode &&
{ check_cpp_condition x264.h "X264_BUILD >= 118"
||
die "ERROR: libx264 version must be >= 0.118.";
}
-enabled libx265 && require_pkg_config x265 x265.h
x265_encoder_encode &&
+enabled libx265 && require_pkg_config x265 x265.h x265_api_get &&
{ check_cpp_condition x265.h "X265_BUILD >= 57" ||
die "ERROR: libx265 version must be >= 57."; }
enabled libxavs && require libxavs xavs.h xavs_encoder_encode -lxavs
--
1.8.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mem: support jemalloc
On 5/31/2015 4:02 PM, Vittorio Giovara wrote: > Although might not be immediately useful, there could be occurrences where it > is. -- MiNi ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [FFmpeg-devel] Exact screen size not working: Re: [PATCH] Fix segfault with x11grab when switching windows. (fwd)
On 5/13/2015 10:37 AM, Diego Biurrun wrote: > Forbidding them to contribute to libav is OK in your opinion? I haven't seen such a thing. Regardless of that, this is entirely unrelated to the thread at hand and nothing but trolling. Be less butthurt, it's been years. Thank you Nicholas for your time. Ignore the troll under the bridge, please. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avcodec/libx265: use x265 Multi-library Interface to query the API
On 5/13/2015 9:59 AM, Luca Barbato wrote:
> +#if (X265_BUILD >= 57)
> +#define init_libx265(B) \
> +do { \
> +ctx->api = x265_api_get((B)); \
> +if (!ctx->api) \
> +ctx->api = x265_api_get(0); \
> +} while (0)
> +
> +#undef x265_encoder_open
> +
> +#define x265_param_free(PA) \
> +ctx->api->param_free((PA))
> +#define x265_encoder_close(C) \
> +ctx->api->encoder_close((C))
> +#define x265_param_alloc() \
> +ctx->api->param_alloc()
> +#define x265_param_default_preset(PA, PR, TU) \
> +ctx->api->param_default_preset((PA), (PR), (TU))
> +#define x265_param_parse(PA, K, V) \
> +ctx->api->param_parse((PA), (K), (V))
> +#define x265_encoder_open(PA) \
> +ctx->api->encoder_open((PA))
> +#define x265_encoder_headers(EN, NAL, NNAL) \
> +ctx->api->encoder_headers((EN), (NAL), (NNAL))
> +#define x265_picture_init(PA, PIC) \
> +ctx->api->picture_init((PA), (PIC))
> +#define x265_encoder_encode(EN, NAL, NNAL, PIC, POUT) \
> +ctx->api->encoder_encode((EN), (NAL), (NNAL), (PIC), (POUT))
> +#else
> +#define init_libx265(B) \
> +do {} while (0)
> +
> +#endif /* X265_BUILD */
>
> +#if (X265_BUILD >= 57)
> +const x265_api *api;
> +#endif
>
> and init_libx265 at init.
Useful to some maybe, but I don't think it belongs in the codebase (e.g. we
never did
such things for libx264).
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [FFmpeg-devel] Exact screen size not working: Re: [PATCH] Fix segfault with x11grab when switching windows. (fwd)
On 5/12/2015 6:55 PM, Diego Biurrun wrote: > It would be nice if more people from your team worked in that spirit of > cooperation instead of requiring that ffmpeg gsoc students not contribute > to libav. Requiring that students that air paid to work on ffmpeg, work on ffmpeg, isn't exactly insane... - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCHv6] lavc: check memory allocations
On 5/12/2015 3:56 PM, Diego Biurrun wrote: > I have no idea what you are trying to tell me. The reviewer should > fix what the patch submitter failed to fix for n rounds of review? I'll break it down. Please: 1) Be less condescending. 2) Be consistent between reviews in what you request. 3) Less of a stickler. You don't to absolutely demand someone sends Yet Another Revision of a patch set if only minor fixes are needed. It's a waste of everybody's time, and only annoys the author. 4) Consider what's better to actually go into the tree, not what's easier to review. 5) Do not insist authors do stuff like splitting patches or fixing some nits, if in reality, it makes no difference, and is only your preference. Do it yourself if it bothers you that much. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCHv6] lavc: check memory allocations
On 5/12/2015 3:45 PM, Diego Biurrun wrote: > Reviewer time is precious, so the onus is on the > patch submitter to ease the reviewer's burden. Everyone's time is precious, and doing N rounds of review and e.g. finding things the Nth time, that have been present since the first revision, should not be the author's burden. There's a line between what's reasonable for a reviewer to ask for, and what's just obnoxious. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mkv: Print unsupported mov tag when found
On 5/12/2015 2:48 PM, Vittorio Giovara wrote: > buf is initialized with av_get_codec_tag_string which converts hex to > readable tags buf should be of size 21 then, no? e.g.: a tag of 0x -> [255][255][255][255] with null terminator. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mkv: Print unsupported mov tag when found
On 5/11/2015 5:23 PM, Vittorio Giovara wrote: > +av_log(matroska->ctx, AV_LOG_ERROR, > + "mov FourCC not found %s.\n", buf); Is this guaranteed to be printable? Should it not be hex? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avcodec/libx265: use x265 Multi-library Interface to query the API
From: Gopu Govindaswamy
ffmpeg can now use the x265 multi-library interface to make a runtime
selection between a number of libx265 libraries (perhaps 8bpp and 16bpp).
ffmpeg will link to one build of libx265 (statically or
dynamically) and this linked version of libx265 will support one
bit-depth (8 or 10 bits). At runtime, ffmpeg now has the option to request the
encoder to use a different bit depth(8 or 10). If the requested bitdepth
is zero, or if it matches the bitdepth of the system default libx265 (the
currently linked library), then this library will be used for encode.
If ffmpeg requests a different bit-depth, the linked libx265 will attempt
to dynamically bind a shared library with the requested bit-depth from the
install
location (default or user-specified).
new x265 API:
const x265_api* api = x265_api_get(int bitDepth);
x265_api - holds the libx265 public API functions
bitDepth - requested API for 8bpp or 16bpp
note: Use 0 to indicate native bit depth of the linked libx265 and
x265_api_get(0) is guaranteed to return a non-null pointer
Signed-off-by: Gopu Govindaswamy
Signed-off-by: Derek Buitenhuis
---
configure| 4 ++--
libavcodec/libx265.c | 29 +
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/configure b/configure
index f3e5154..5bcc2df 100755
--- a/configure
+++ b/configure
@@ -4268,8 +4268,8 @@ enabled libx264 && require_pkg_config x264
"stdint.h x264.h" x264_enco
{ check_cpp_condition x264.h "X264_BUILD >= 118"
||
die "ERROR: libx264 version must be >= 0.118.";
}
enabled libx265 && require_pkg_config x265 x265.h
x265_encoder_encode &&
- { check_cpp_condition x265.h "X265_BUILD >= 17" ||
- die "ERROR: libx265 version must be >= 17."; }
+ { check_cpp_condition x265.h "X265_BUILD >= 57" ||
+ die "ERROR: libx265 version must be >= 57."; }
enabled libxavs && require libxavs xavs.h xavs_encoder_encode -lxavs
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled mmal && { check_lib interface/mmal/mmal.h
mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host ||
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 36cd0a8..f5687f6 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -39,6 +39,7 @@ typedef struct libx265Context {
x265_encoder *encoder;
x265_param *params;
+const x265_api *api;
float crf;
char *preset;
@@ -67,10 +68,10 @@ static av_cold int libx265_encode_close(AVCodecContext
*avctx)
av_frame_free(&avctx->coded_frame);
-x265_param_free(ctx->params);
+ctx->api->param_free(ctx->params);
if (ctx->encoder)
-x265_encoder_close(ctx->encoder);
+ctx->api->encoder_close(ctx->encoder);
return 0;
}
@@ -79,6 +80,10 @@ static av_cold int libx265_encode_init(AVCodecContext *avctx)
{
libx265Context *ctx = avctx->priv_data;
+ctx->api =
x265_api_get(av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 + 1);
+if (!ctx->api)
+ctx->api = x265_api_get(0);
+
if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL &&
!av_pix_fmt_desc_get(avctx->pix_fmt)->log2_chroma_w) {
av_log(avctx, AV_LOG_ERROR,
@@ -93,13 +98,13 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
return AVERROR(ENOMEM);
}
-ctx->params = x265_param_alloc();
+ctx->params = ctx->api->param_alloc();
if (!ctx->params) {
av_log(avctx, AV_LOG_ERROR, "Could not allocate x265 param
structure.\n");
return AVERROR(ENOMEM);
}
-if (x265_param_default_preset(ctx->params, ctx->preset, ctx->tune) < 0) {
+if (ctx->api->param_default_preset(ctx->params, ctx->preset, ctx->tune) <
0) {
int i;
av_log(avctx, AV_LOG_ERROR, "Error setting preset/tune %s/%s.\n",
ctx->preset, ctx->tune);
@@ -148,7 +153,7 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
avctx->sample_aspect_ratio.num,
avctx->sample_aspect_ratio.den, 65535);
snprintf(sar, sizeof(sar), "%d:%d", sar_num, sar_den);
-if (x265_param_parse(ctx->params, "sar", sar) == X265_PARAM_BAD_VALUE)
{
+if (ctx->api->param_parse(ctx->params, "sar", sar) ==
X265_PARAM_BAD_VALUE) {
av_log(avctx, AV_LOG_ERROR, "Invalid SAR: %d:%d.\n", sar_num,
sar_den);
Re: [libav-devel] [PATCH] libx265: Fix 'braces around scalar initializer' warning
On 5/2/2015 9:34 PM, Martin Storsjö wrote: > It's not irrelevant at all. Previously, the first member of x265_picture > used to be a struct (which would be why the extra braces were added), now > it isn't a struct any longer, causing warnings due to the extra braces. Or > at least this is a potential explanation - does this match the actual > evolution of the x265_picture struct? Interesting... I admit I thought it was a rehash of the original warning due to compiler versions. This is pretty lulz though... - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libx265: Fix 'braces around scalar initializer' warning
On 5/1/2015 6:28 PM, Luca Barbato wrote: > Which version of x265 ? Irrelevant. This is in our code. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] libx265: Fix 'braces around scalar initializer' warning
On 5/1/2015 3:39 PM, Vittorio Giovara wrote: > --- > libavcodec/libx265.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) http://permalink.gmane.org/gmane.comp.video.libav.devel/50988 - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: Replace the ASF demuxer
On 4/29/2015 6:01 AM, Anton Khirnov wrote: > I already asked in the last review -- any reason for this to be signed? This would go infinitely smoother if there were actual responses to reviews, and not just a giant new patch with no notes on what changed. My 2 cents. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avformat: fix compiler warning integer conversion resulted in a change of sign
On 4/11/2015 2:04 PM, Diego Biurrun wrote: > Rude is your continued trolling on this mailing list. Please take it back > to your FFmpeg home turf where such behavior is apparently tolerated. It > is not tolerated here. You are the one who is trolling here Diego. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vfwcap: Unbreak building after c201069fa
On 4/10/2015 11:26 AM, Martin Storsjö wrote: > These headers can't be included in any arbitrary order. > --- > Updated the comment about winsock2.h vs windows.h; on MSVC it is an error > to include them in the wrong order, while mingw only warns about it. > --- > libavdevice/vfwcap.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) OK. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avcodec/libx265: print supported presets and tunes on error
From: James Almer
Based on code from libavcodec/libx264.c
Signed-off-by: James Almer
Signed-off-by: Derek Buitenhuis
---
libavcodec/libx265.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index a7089b1..c04299a 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -100,7 +100,20 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
}
if (x265_param_default_preset(ctx->params, ctx->preset, ctx->tune) < 0) {
-av_log(avctx, AV_LOG_ERROR, "Invalid preset or tune.\n");
+int i;
+
+av_log(avctx, AV_LOG_ERROR, "Error setting preset/tune %s/%s.\n",
ctx->preset, ctx->tune);
+av_log(avctx, AV_LOG_INFO, "Possible presets:");
+for (i = 0; x265_preset_names[i]; i++)
+av_log(avctx, AV_LOG_INFO, " %s", x265_preset_names[i]);
+
+av_log(avctx, AV_LOG_INFO, "\n");
+av_log(avctx, AV_LOG_INFO, "Possible tunes:");
+for (i = 0; x265_tune_names[i]; i++)
+av_log(avctx, AV_LOG_INFO, " %s", x265_tune_names[i]);
+
+av_log(avctx, AV_LOG_INFO, "\n");
+
return AVERROR(EINVAL);
}
--
2.1.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/3] mpegtsenc: Allow user to set SDT retransmission period
On 4/5/2015 8:41 PM, Martin Storsjö wrote: > This changes the default value for the CBR case I know. There was no explanation why it differed. (I also tend to think separate defaults are just insane.) We should keep one or the other, but not both. > This is a bit problematic, when one single option is interpreted in two > different units depending on the case. For the CBR case, SDT_RETRANS_TIME > previously (and ts->sdt_period after this patch) is interpreted as a value > in milliseconds, while for the VBR case below it is interpreted as a > number of packets. Someone ought to go back in time and ask Fabrice why. (Before someone chimes in with a "while you're at it": No, I will not refactor mpegtsenc.c to be consistent, just for this patch set to be accepted > I'm a bit unsure how to expose this in the best way via an avoption > actually - two different avoptions for the two cases is ugly, while one > single option interpreted in two different ways also is problematic. Also, > if changing the default value for any case, I'd rather change the value > for the VBR case (the CBR case default value makes more sense I think). Well, being able to set these values for the CBR case is arguably even more important (broadcast standards, etc.) I am fine with changing the VBR case defaults. As for how to best expose it, one solution is simply to to document it properly. This would be my preference, rather than adding a total of four new avoptions. Any other preferences? - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/3] hlsenc: Only write PAT/PMT once per segment
On 4/5/2015 7:48 PM, Martin Storsjö wrote: > For things like this, you could use av_opt_set_int. But in this case, > these don't need to be reset for each segment at all, but could be set > just once at startup, via an AVDictionary to avformat_write_header. All right. Will send a new patch in a while. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 0/3] Lower HLS Overhead
Derek Buitenhuis (3): mpegtsenc: Allow user to set SDT retransmission period mpegtsenc: Allow user to set PAT/PMT retransmission period hlsenc: Only write PAT/PMT once per segment libavformat/hlsenc.c| 10 +- libavformat/mpegtsenc.c | 20 ++-- libavformat/version.h | 2 +- 3 files changed, 24 insertions(+), 8 deletions(-) -- 2.1.4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
