Re: [FFmpeg-devel] [PATCH] avcodec/v410enc: Use ff_alloc_packet() instead of ff_alloc_packet2()
On Sun, 5 Jul 2015 23:03:24 +0200 Michael Niedermayer wrote: > the later is not optimal when the buffer size is well known at allocation time > > This avoids a memcpy() > > about 1% faster > > Signed-off-by: Michael Niedermayer > --- > libavcodec/v410enc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/v410enc.c b/libavcodec/v410enc.c > index f2f7d73..5537a12 100644 > --- a/libavcodec/v410enc.c > +++ b/libavcodec/v410enc.c > @@ -50,7 +50,7 @@ static int v410_encode_frame(AVCodecContext *avctx, > AVPacket *pkt, > uint32_t val; > int i, j, ret; > > -if ((ret = ff_alloc_packet2(avctx, pkt, avctx->width * avctx->height * > 4)) < 0) > +if ((ret = ff_alloc_packet(pkt, avctx->width * avctx->height * 4)) < 0) > return ret; > dst = pkt->data; > This seems unintuitive. Shouldn't the "2" version be better and a full replacement of the original function, with the original deprecated? If not, then the naming of the function is utter misleading crap. What's the deal with this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.
Hello Michael, For any case there is need a way to encode h.264 with or without active frame_mbs_only_flag into SPS. If I understanding correct, the purpose of CODEC_FLAG_INTERLACED_DCT is exactly for this. Monday, July 6, 2015, 3:26:16 AM, you wrote: MN> the CODEC_FLAG_INTERLACED_DCT flag is intended for the user to be MN> able to choose the CODING mode, that is it allows (not forced) MN> interlaced DCT CODING MN> the flag says nothing about the content being interlaced. MN> allowing interlaced coding just by common sense implies that the MN> material is probably interlaced MN> [...] -- Best regards, Ivanmailto:ivan.us...@nablet.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] configure: loongson enabled local aligned 32
From 7cef687fac2f056a0f1a6e7cf65df5358b16a642 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong Date: Mon, 6 Jul 2015 09:42:17 +0800 Subject: [PATCH 1/2] configure: loongson enabled local aligned 32 Signed-off-by: ZhouXiaoyong --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index bb3041b..bf6ca37 100755 --- a/configure +++ b/configure @@ -3974,7 +3974,7 @@ elif enabled mips; then disable mipsdspr1 disable mipsdspr2 disable msa -enable local_aligned_8 local_aligned_16 +enable local_aligned_8 local_aligned_16 local_aligned_32 enable simd_align_16 enable fast_64bit enable fast_clz -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec: loongson optimized mpegvideo dct unquantize with
From cc51287aa33d095595f1373de2b0191a2180428c Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Mon, 6 Jul 2015 16:45:56 +0800
Subject: [PATCH 2/2] avcodec: loongson optimized mpegvideo dct unquantize with
mmi
Signed-off-by: ZhouXiaoyong
---
libavcodec/mips/Makefile | 1 +
libavcodec/mips/mpegvideo_init_mips.c | 14 ++
libavcodec/mips/mpegvideo_mips.h | 35
libavcodec/mips/mpegvideo_mmi.c | 303 ++
4 files changed, 353 insertions(+)
diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 894ca28..03a1990 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -52,3 +52,4 @@ MSA-OBJS-$(CONFIG_MPEGVIDEO) +=
mips/mpegvideo_msa.o
MMI-OBJS-$(CONFIG_H264DSP)+= mips/h264dsp_mmi.o
MMI-OBJS-$(CONFIG_H264CHROMA) += mips/h264chroma_mmi.o
MMI-OBJS-$(CONFIG_H264PRED) += mips/h264pred_mmi.o
+MMI-OBJS-$(CONFIG_MPEGVIDEO) += mips/mpegvideo_mmi.o
diff --git a/libavcodec/mips/mpegvideo_init_mips.c
b/libavcodec/mips/mpegvideo_init_mips.c
index ee14b31..85a833c 100644
--- a/libavcodec/mips/mpegvideo_init_mips.c
+++ b/libavcodec/mips/mpegvideo_init_mips.c
@@ -19,6 +19,7 @@
*/
#include "h263dsp_mips.h"
+#include "mpegvideo_mips.h"
#if HAVE_MSA
static av_cold void dct_unquantize_init_msa(MpegEncContext *s)
@@ -29,9 +30,22 @@ static av_cold void dct_unquantize_init_msa(MpegEncContext
*s)
}
#endif // #if HAVE_MSA
+#if HAVE_MMI
+static av_cold void dct_unquantize_init_mmi(MpegEncContext *s)
+{
+s->dct_unquantize_h263_intra = ff_dct_unquantize_h263_intra_mmi;
+s->dct_unquantize_h263_inter = ff_dct_unquantize_h263_inter_mmi;
+s->dct_unquantize_mpeg1_intra = ff_dct_unquantize_mpeg1_intra_mmi;
+s->dct_unquantize_mpeg1_inter = ff_dct_unquantize_mpeg1_inter_mmi;
+}
+#endif /* HAVE_MMI */
+
av_cold void ff_mpv_common_init_mips(MpegEncContext *s)
{
#if HAVE_MSA
dct_unquantize_init_msa(s);
#endif // #if HAVE_MSA
+#if HAVE_MMI
+dct_unquantize_init_mmi(s);
+#endif /* HAVE_MMI */
}
diff --git a/libavcodec/mips/mpegvideo_mips.h b/libavcodec/mips/mpegvideo_mips.h
new file mode 100644
index 000..dbcea6a
--- /dev/null
+++ b/libavcodec/mips/mpegvideo_mips.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2015 Zhou Xiaoyong
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef MPEGVIDEO_MIPS_H
+#define MPEGVIDEO_MIPS_H
+
+#include "libavcodec/mpegvideo.h"
+
+void ff_dct_unquantize_h263_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_h263_inter_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_mpeg1_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+void ff_dct_unquantize_mpeg1_inter_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale);
+
+#endif /* MPEGVIDEO_MIPS_H */
diff --git a/libavcodec/mips/mpegvideo_mmi.c b/libavcodec/mips/mpegvideo_mmi.c
new file mode 100644
index 000..b3d58bd
--- /dev/null
+++ b/libavcodec/mips/mpegvideo_mmi.c
@@ -0,0 +1,303 @@
+/*
+ * Loongson SIMD optimized mpegvideo
+ *
+ * Copyright (c) 2015 Loongson Technology Corporation Limited
+ * Copyright (c) 2015 Zhou Xiaoyong
+ *Zhang Shuangshuang
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "mpegvideo_mips.h"
+
+void ff_dct_unquantize_h263_intra_mmi(MpegEncContext *s, int16_t *block,
+int n, int qscale)
+{
+int64_t level, qmul, qadd, nCoeffs;
Re: [FFmpeg-devel] implement process_command for vf_scale and vf_crop
On 6/25/15, Bernd Blessmann wrote: > Hi all, > > I want to implement process_command for vf_scale.c and vf_crop.c in order to > use zmq to change > scaling and cropping dynamically. > > I have implemented it using av_opt_set() and calling config_props() for > scale and config_input() and > config_output() for crop. I am using the config_-functions because they > handle variable parsing and > checking of the values. But I do not know if this is the right way to do it > and if it is safe to > call these functions from process_command. > > Maybe someone can comment on these implementation or outline a way to > implement process_command for > these filters. > > I attach patches including my implementation so far. > > Thank you very much in advance >Bernd > If it works I guess it should be ok. But newly added stuff should be somewhere documented... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/v410enc: Use ff_alloc_packet() instead of ff_alloc_packet2()
On Mon, Jul 06, 2015 at 09:37:34AM +0200, wm4 wrote: > On Sun, 5 Jul 2015 23:03:24 +0200 > Michael Niedermayer wrote: > > > the later is not optimal when the buffer size is well known at allocation > > time > > > > This avoids a memcpy() > > > > about 1% faster > > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/v410enc.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/v410enc.c b/libavcodec/v410enc.c > > index f2f7d73..5537a12 100644 > > --- a/libavcodec/v410enc.c > > +++ b/libavcodec/v410enc.c > > @@ -50,7 +50,7 @@ static int v410_encode_frame(AVCodecContext *avctx, > > AVPacket *pkt, > > uint32_t val; > > int i, j, ret; > > > > -if ((ret = ff_alloc_packet2(avctx, pkt, avctx->width * avctx->height * > > 4)) < 0) > > +if ((ret = ff_alloc_packet(pkt, avctx->width * avctx->height * 4)) < 0) > > return ret; > > dst = pkt->data; > > > > This seems unintuitive. Shouldn't the "2" version be better and a full > replacement of the original function, with the original deprecated? If > not, then the naming of the function is utter misleading crap. What's > the deal with this? ill post a patch that deprecates it and solves this differently [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/v410enc: do not use internal->byte_buffer
it is not optimal when the buffer size is well known at allocation time This avoids a memcpy() about 1% faster Signed-off-by: Michael Niedermayer --- libavcodec/v410enc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/v410enc.c b/libavcodec/v410enc.c index f2f7d73..b256a31 100644 --- a/libavcodec/v410enc.c +++ b/libavcodec/v410enc.c @@ -50,7 +50,7 @@ static int v410_encode_frame(AVCodecContext *avctx, AVPacket *pkt, uint32_t val; int i, j, ret; -if ((ret = ff_alloc_packet2(avctx, pkt, avctx->width * avctx->height * 4)) < 0) +if ((ret = ff_alloc_packet2(NULL, pkt, avctx->width * avctx->height * 4)) < 0) return ret; dst = pkt->data; -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/internal: Deprecate ff_alloc_packet() in favor of ff_alloc_packet2()
Signed-off-by: Michael Niedermayer --- libavcodec/internal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/internal.h b/libavcodec/internal.h index cea5355..2feb68b 100644 --- a/libavcodec/internal.h +++ b/libavcodec/internal.h @@ -221,7 +221,7 @@ int avpriv_unlock_avformat(void); */ int ff_alloc_packet2(AVCodecContext *avctx, AVPacket *avpkt, int64_t size); -int ff_alloc_packet(AVPacket *avpkt, int size); +attribute_deprecated int ff_alloc_packet(AVPacket *avpkt, int size); /** * Rescale from sample rate to AVCodecContext.time_base. -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/internal: Document how to avoid the internal->byte_buffer with ff_alloc_packet2()
Signed-off-by: Michael Niedermayer --- libavcodec/internal.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/internal.h b/libavcodec/internal.h index 2feb68b..c410f8b 100644 --- a/libavcodec/internal.h +++ b/libavcodec/internal.h @@ -210,6 +210,9 @@ int avpriv_unlock_avformat(void); * or allocated in this function. * * @param avctx the AVCodecContext of the encoder + *this can be set to NULL to avoid the use of internal->byte_buffer + *in the allocation algorithm. When the final used size is well + *known it is more efficient to not use internal->byte_buffer. * @param avpkt the AVPacket *If avpkt->data is already set, avpkt->size is checked *to ensure it is large enough. -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/internal: Document how to avoid the internal->byte_buffer with ff_alloc_packet2()
On Mon, Jul 6, 2015 at 12:07 PM, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/internal.h |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/internal.h b/libavcodec/internal.h > index 2feb68b..c410f8b 100644 > --- a/libavcodec/internal.h > +++ b/libavcodec/internal.h > @@ -210,6 +210,9 @@ int avpriv_unlock_avformat(void); > * or allocated in this function. > * > * @param avctx the AVCodecContext of the encoder > + *this can be set to NULL to avoid the use of > internal->byte_buffer > + *in the allocation algorithm. When the final used size is > well > + *known it is more efficient to not use > internal->byte_buffer. > * @param avpkt the AVPacket > *If avpkt->data is already set, avpkt->size is checked > *to ensure it is large enough. This seems terrible. Can't it somehow be made smarter? Passing a NULL context is hardly intuitive or obvious. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/internal: Document how to avoid the internal->byte_buffer with ff_alloc_packet2()
On 7/6/15, Hendrik Leppkes wrote: > On Mon, Jul 6, 2015 at 12:07 PM, Michael Niedermayer > wrote: >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/internal.h |3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/libavcodec/internal.h b/libavcodec/internal.h >> index 2feb68b..c410f8b 100644 >> --- a/libavcodec/internal.h >> +++ b/libavcodec/internal.h >> @@ -210,6 +210,9 @@ int avpriv_unlock_avformat(void); >> * or allocated in this function. >> * >> * @param avctx the AVCodecContext of the encoder >> + *this can be set to NULL to avoid the use of >> internal->byte_buffer >> + *in the allocation algorithm. When the final used size >> is well >> + *known it is more efficient to not use >> internal->byte_buffer. >> * @param avpkt the AVPacket >> *If avpkt->data is already set, avpkt->size is checked >> *to ensure it is large enough. > > This seems terrible. Can't it somehow be made smarter? > Passing a NULL context is hardly intuitive or obvious. > ff_alloc_packet3 ? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] swscale: ayuv16le output support
Signed-off-by: Paul B Mahol
---
libswscale/output.c | 48
libswscale/utils.c | 2 +-
tests/ref/fate/filter-pixfmts-copy | 1 +
tests/ref/fate/filter-pixfmts-crop | 1 +
tests/ref/fate/filter-pixfmts-field | 1 +
tests/ref/fate/filter-pixfmts-fieldorder | 1 +
tests/ref/fate/filter-pixfmts-hflip | 1 +
tests/ref/fate/filter-pixfmts-il | 1 +
tests/ref/fate/filter-pixfmts-null | 1 +
tests/ref/fate/filter-pixfmts-scale | 1 +
tests/ref/fate/filter-pixfmts-vflip | 1 +
11 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index 1db0a51..d7f0553 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -2008,6 +2008,51 @@ yuv2ya8_X_c(SwsContext *c, const int16_t *lumFilter,
}
}
+static void
+yuv2ayuv16le_X_c(SwsContext *c, const int16_t *lumFilter,
+ const int32_t **lumSrc, int lumFilterSize,
+ const int16_t *chrFilter, const int32_t **chrUSrc,
+ const int32_t **chrVSrc, int chrFilterSize,
+ const int32_t **alpSrc, uint8_t *dest, int dstW, int y)
+{
+int hasAlpha = !!alpSrc;
+int i;
+
+for (i = 0; i < dstW; i++) {
+int Y = 1 << 14, U = 1 << 14;
+int V = 1 << 14, A = 1 << 14;
+int j;
+
+Y -= 0x4000;
+U -= 0x4000;
+V -= 0x4000;
+A -= 0x4000;
+
+for (j = 0; j < lumFilterSize; j++)
+Y += lumSrc[j][i] * (unsigned)lumFilter[j];
+
+for (j = 0; j < chrFilterSize; j++)
+U += chrUSrc[j][i] * (unsigned)chrFilter[j];
+
+for (j = 0; j < chrFilterSize; j++)
+V += chrVSrc[j][i] * (unsigned)chrFilter[j];
+
+if (hasAlpha)
+for (j = 0; j < lumFilterSize; j++)
+A += alpSrc[j][i] * (unsigned)lumFilter[j];
+
+Y = 0x8000 + av_clip_int16(Y >> 15);
+U = 0x8000 + av_clip_int16(U >> 15);
+V = 0x8000 + av_clip_int16(V >> 15);
+A = 0x8000 + av_clip_int16(A >> 15);
+
+AV_WL16(dest + 8 * i, hasAlpha ? A : 65535);
+AV_WL16(dest + 8 * i + 2, Y);
+AV_WL16(dest + 8 * i + 4, U);
+AV_WL16(dest + 8 * i + 6, V);
+}
+}
+
av_cold void ff_sws_init_output_funcs(SwsContext *c,
yuv2planar1_fn *yuv2plane1,
yuv2planarX_fn *yuv2planeX,
@@ -2457,5 +2502,8 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed2 = yuv2ya8_2_c;
*yuv2packedX = yuv2ya8_X_c;
break;
+case AV_PIX_FMT_AYUV16LE:
+*yuv2packedX = yuv2ayuv16le_X_c;
+break;
}
}
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 1ec3eff..856f7fe 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -225,7 +225,7 @@ static const FormatEntry format_entries[AV_PIX_FMT_NB] = {
[AV_PIX_FMT_BAYER_GRBG16BE] = { 1, 0 },
[AV_PIX_FMT_XYZ12BE] = { 1, 1, 1 },
[AV_PIX_FMT_XYZ12LE] = { 1, 1, 1 },
-[AV_PIX_FMT_AYUV16LE]= { 1, 0},
+[AV_PIX_FMT_AYUV16LE]= { 1, 1},
};
int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
diff --git a/tests/ref/fate/filter-pixfmts-copy
b/tests/ref/fate/filter-pixfmts-copy
index defdb19..4c179b3 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -2,6 +2,7 @@
0rgb527ef3d164c8fd0700493733959689c2
abgr023ecf6396d324edb113e4a483b79ba2
argbf003b555ef429222005d33844cca9325
+ayuv16le07b9c969dfbe4add4c0626773b151d4f
bgr06fcd67c8e6cec723dab21c70cf53dc16
bgr24 4cff3814819f02ecf5824edfd768d2b1
bgr444be1cd47c1555f947dfcba99192e3429d20
diff --git a/tests/ref/fate/filter-pixfmts-crop
b/tests/ref/fate/filter-pixfmts-crop
index b9e117b..3f2bb8f 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -2,6 +2,7 @@
0rgb974833c777e6abe6d84dc59af2ca5625
abgr1d21f5b8a20186ac9dd54459c986a2a7
argb8b822972049a1e207000763f2564d6e0
+ayuv16leab2f7bc8f150af47c42c778e3ea28bce
bgr038a84849a9198667c348c686802e3b52
bgr24 1dacd8e04bf0eff163e82250d01a9cc7
bgr444bee2d2b864dfa528e77684ddc117f2d974
diff --git a/tests/ref/fate/filter-pixfmts-field
b/tests/ref/fate/filter-pixfmts-field
index 5bec7f8..da3cc40 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -2,6 +2,7 @@
0rgbe2c35753a2271d1f9455b1809bc0e907
abgrc0eb95959edf5d40ff8af315e62d0f8a
argb6dca4f2987b49b7d63f702d17bace630
+ayuv16led9836decca6323ba88b3b3d02257c0b6
bgr01da3fdbac616b3b410d081e39ed7a1f6
bgr24 573c76d77b1cbe6534ea7c0267dc1b13
bgr444be
Re: [FFmpeg-devel] [PATCH] fate/api: simplify
This has a couple of implications for the running of these tests in certain circumstances. Whether these circumstances are important or realistic, I do not know. In particular, I tested by configuring with "--disable-avformat" and in that case, "make fate" works fine, but necessarily excludes all API tests, and the "fate-api" target will fail if SAMPLES isn't set. > -FATE_API_SAMPLES_LIBAVFORMAT-$(call DEMDEC, H264, H264) += fate-api-h264 > +FATE_API_SAMPLES-$(call DEMDEC, H264, H264) += fate-api-h264 > fate-api-h264: $(APITESTSDIR)/api-h264-test$(EXESUF) > fate-api-h264: CMD = run $(APITESTSDIR)/api-h264-test > $(TARGET_SAMPLES)/h264-conformance/SVA_NL2_E.264 > > -FATE_API_SAMPLES-$(CONFIG_AVFORMAT) += $(FATE_API_SAMPLES_LIBAVFORMAT-yes) As far as I can tell, $(call DEMDEC, X, Y) does not necessarily imply $(CONFIG_AVFORMAT), so "--disable-avformat" led to a condition where this failed. > +FATE_FFMPEG += $(FATE_API-yes) > +FATE_SAMPLES_FFMPEG += $(FATE_API_SAMPLES-yes) This causes all the API tests to depend on the ffmpeg program. Strictly speaking they shouldn't need to, at least for the tests that are currently there. And this also explains why "--disable-avformat" will exclude the API tests from "make fate". > > -ifdef SAMPLES > -FATE_API_SAMPLES += $(FATE_API_SAMPLES-yes) > -endif > - > -FATE_API-$(CONFIG_AVCODEC) += $(FATE_API_LIBAVCODEC-yes) > -FATE_API-$(CONFIG_AVFORMAT) += $(FATE_API_LIBAVFORMAT-yes) > -FATE_API = $(FATE_API-yes) > - > -FATE-yes += $(FATE_API) $(FATE_API_SAMPLES) > - > -fate-api: $(FATE_API) $(FATE_API_SAMPLES) > +fate-api: $(FATE_API-yes) $(FATE_API_SAMPLES-yes) > This will add the sample-dependent tests to the "fate-api" target, whether or not SAMPLES is set. I guess the question is whether there are a limited number of desired use cases to support like "configure && make fate", or the tests should be robust to more particular circumstances/configurations (by the way, I'm not claiming the existing state covers all bases in that respect). If it's the former, then this patch makes things much neater. If it's the latter, then the old state seems to cover more cases. Which is better is not for me to decide. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] swscale: ayuv16 input support
Paul B Mahol gmail.com> writes: > +static void read_ayuv16le_Y_c Wasn't the original request for output-only? Is the input useful? Imo, AYUV64 is more consistent. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] api-seek-test: first version
On Sun, Jul 05, 2015 at 02:29:49AM +0300, Ludmila Glinskih wrote:
> Works only with video stream.
> ---
> tests/api/Makefile| 1 +
> tests/api/api-seek-test.c | 194
> ++
> tests/fate/api.mak| 4 +
> tests/ref/fate/api-seek | 147 +++
> 4 files changed, 346 insertions(+)
> create mode 100644 tests/api/api-seek-test.c
> create mode 100644 tests/ref/fate/api-seek
>
> diff --git a/tests/api/Makefile b/tests/api/Makefile
> index 704987e..59cbc7c 100644
> --- a/tests/api/Makefile
> +++ b/tests/api/Makefile
> @@ -1,5 +1,6 @@
> APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
> APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
> +APITESTPROGS-yes += api-seek
> APITESTPROGS += $(APITESTPROGS-yes)
>
> APITESTOBJS := $(APITESTOBJS:%=$(APITESTSDIR)%)
> $(APITESTPROGS:%=$(APITESTSDIR)/%-test.o)
> diff --git a/tests/api/api-seek-test.c b/tests/api/api-seek-test.c
> new file mode 100644
> index 000..85430a3
> --- /dev/null
> +++ b/tests/api/api-seek-test.c
> @@ -0,0 +1,194 @@
> +/*
> + * Copyright (c) 2015 Ludmila Glinskih
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +/**
> + * Seek test.
> + */
> +
> +#include "libavutil/adler32.h"
> +#include "libavcodec/avcodec.h"
> +#include "libavformat/avformat.h"
> +#include "libavutil/imgutils.h"
> +
> +static int compute_crc_of_packets(AVFormatContext *fmt_ctx, int video_stream,
> +AVCodecContext *ctx, AVFrame *fr, uint64_t
> ts_start, uint64_t ts_end)
> +{
> +int number_of_written_bytes;
> +int got_frame = 0;
> +int result;
> +int end_of_stream = 0;
> +int byte_buffer_size;
> +uint8_t *byte_buffer;
> +AVPacket pkt;
> +
> +byte_buffer_size = av_image_get_buffer_size(ctx->pix_fmt, ctx->width,
> ctx->height, 16);
> +byte_buffer = av_malloc(byte_buffer_size);
> +if (!byte_buffer) {
> +av_log(NULL, AV_LOG_ERROR, "Can't allocate buffer\n");
> +return AVERROR(ENOMEM);
> +}
> +
> +result = av_seek_frame(fmt_ctx, video_stream, ts_start, AVSEEK_FLAG_ANY);
> +printf("Seeking to %"PRId64", computing crc for frames with pts <
> %"PRId64"\n", ts_start, ts_end);
> +if (result < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Error in seeking\n");
> +return result;
> +}
> +avcodec_flush_buffers(ctx);
> +
> +av_init_packet(&pkt);
> +do {
> +if (!end_of_stream)
> +if (av_read_frame(fmt_ctx, &pkt) < 0)
> +end_of_stream = 1;
> +if (end_of_stream) {
> +pkt.data = NULL;
> +pkt.size = 0;
> +}
> +if (pkt.stream_index == video_stream || end_of_stream) {
> +got_frame = 0;
> +if (pkt.pts == AV_NOPTS_VALUE) {
> +av_log(NULL, AV_LOG_ERROR, "Error: frames doesn't have pts
> values\n");
> +return -1;
> +}
> +result = avcodec_decode_video2(ctx, fr, &got_frame, &pkt);
> +if (result < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Error decoding frame\n");
> +return result;
> +}
> +if (got_frame) {
> +number_of_written_bytes =
> av_image_copy_to_buffer(byte_buffer, byte_buffer_size,
> +(const uint8_t* const *)fr->data,
> (const int*) fr->linesize,
> +ctx->pix_fmt, ctx->width,
> ctx->height, 1);
> +if (number_of_written_bytes < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Can't copy image to
> buffer\n");
> +return number_of_written_bytes;
> +}
> +if (fr->pkt_pts > ts_end)
> +break;
> +printf("%10"PRId64", 0x%08lx\n", fr->pkt_pts,
> av_adler32_update(0
Re: [FFmpeg-devel] [PATCH 2/3] swscale: ayuv16 input support
Carl Eugen Hoyos ag.or.at> writes: > Imo, AYUV64 is more consistent. Or YUVA64? Please mention the ticket in the commit message for the swscaler output. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] swscale: ayuv16le output support
Paul B Mahol gmail.com> writes: > +static void > +yuv2ayuv16le_X_c Where you able to test this with the Apple encoder? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred with mmi
On Fri, Jul 03, 2015 at 06:13:25PM +0800, 周晓勇 wrote: > From dc50d05ba8a4d40e17f15a52237f33cff0205fea Mon Sep 17 00:00:00 2001 > From: ZhouXiaoyong > Date: Fri, 3 Jul 2015 16:56:01 +0800 > Subject: [PATCH 4/4] avcodec: loongson optimized h264pred with mmi > > > Signed-off-by: ZhouXiaoyong > --- > libavcodec/mips/Makefile | 1 + > libavcodec/mips/h264pred_init_mips.c | 53 +++ > libavcodec/mips/h264pred_mips.h | 53 +++ > libavcodec/mips/h264pred_mmi.c | 799 > +++ > 4 files changed, 906 insertions(+) this fails with: /tmp/ccbnexwo.s: Assembler messages: /tmp/ccbnexwo.s:44: Error: Number (0xfffbfffafff9fff8) larger than 32 bits /tmp/ccbnexwo.s:46: Error: Number (0xfffefffdfffc) larger than 32 bits /tmp/ccbnexwo.s:48: Error: Number (0x0004000300020001) larger than 32 bits /tmp/ccbnexwo.s:50: Error: Number (0x0008000700060005) larger than 32 bits /tmp/ccbnexwo.s:195: Error: Number (0x000300020001) larger than 32 bits /tmp/ccbnexwo.s:198: Error: Number (0x0007000600050004) larger than 32 bits /tmp/ccbnexwo.s:201: Error: Number (0x000b000a00090008) larger than 32 bits /tmp/ccbnexwo.s:204: Error: Number (0x000f000e000d000c) larger than 32 bits /tmp/ccbnexwo.s:302: Error: Number (0x0101010101010101) larger than 32 bits /tmp/ccbnexwo.s:360: Error: Number (0x0101010101010101) larger than 32 bits /tmp/ccbnexwo.s:1451: Error: Number (0x0001010101010101) larger than 32 bits /tmp/ccbnexwo.s:1531: Error: Number (0x0101010101010101) larger than 32 bits /tmp/ccbnexwo.s:1870: Error: Number (0x0101010101010101) larger than 32 bits make: *** No rule to make target `libavcodec/mips/h264pred_mmi.o', needed by `libavcodec/libavcodec.a'. Stop. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] swscale: ayuv16le output support
On Mon, Jul 6, 2015 at 2:27 PM, Carl Eugen Hoyos wrote: > Paul B Mahol gmail.com> writes: > > > +static void > > +yuv2ayuv16le_X_c > > Where you able to test this with the Apple > encoder? > > I will try to get a test setup running and post the results here, probably tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] swscale: ayuv16 input support
On 7/6/15, Carl Eugen Hoyos wrote: > Paul B Mahol gmail.com> writes: > >> +static void read_ayuv16le_Y_c > > Wasn't the original request for output-only? > Is the input useful? Mostly for testing purposes. > > Imo, AYUV64 is more consistent. Yes, I think about that too. > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] swscale: ayuv16 input support
On 7/6/15, Carl Eugen Hoyos wrote: > Carl Eugen Hoyos ag.or.at> writes: > >> Imo, AYUV64 is more consistent. > > Or YUVA64? YUVA is different from AYUV like RGBA is different from ARGB. > > Please mention the ticket in the commit message > for the swscaler output. Will, do. Although y416 have nothing to do with 16 bit ayuv. > > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] swscale: ayuv16 input support
Paul B Mahol gmail.com> writes: > > Please mention the ticket in the commit message > > for the swscaler output. > > Will, do. Although y416 have nothing to do with 16 bit ayuv. I completely agree but I think it turned out the the OP wasn't really interested in y416 but in your patch;-) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] swscale: ayuv16le output support
On Mon, Jul 06, 2015 at 11:56:21AM +, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libswscale/output.c | 48 > > libswscale/utils.c | 2 +- > tests/ref/fate/filter-pixfmts-copy | 1 + > tests/ref/fate/filter-pixfmts-crop | 1 + > tests/ref/fate/filter-pixfmts-field | 1 + > tests/ref/fate/filter-pixfmts-fieldorder | 1 + > tests/ref/fate/filter-pixfmts-hflip | 1 + > tests/ref/fate/filter-pixfmts-il | 1 + > tests/ref/fate/filter-pixfmts-null | 1 + > tests/ref/fate/filter-pixfmts-scale | 1 + > tests/ref/fate/filter-pixfmts-vflip | 1 + > 11 files changed, 58 insertions(+), 1 deletion(-) filter-pixfmts-fieldorder TESTfilter-pixfmts-hflip reference file './tests/ref/fate/filter-pixdesc-ayuv16le' not found ./tests/fate-run.sh: 282: ./tests/fate-run.sh: cannot open tests/data/fate/filter-pixdesc-ayuv16le.diff: No such file Test filter-pixdesc-ayuv16le failed. Look at tests/data/fate/filter-pixdesc-ayuv16le.err for details. make: *** [fate-filter-pixdesc-ayuv16le] Error 1 patch should be ok otherwise [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] swscale: ayuv16le output support
On Mon, Jul 06, 2015 at 03:10:41PM +0200, Michael Niedermayer wrote: > On Mon, Jul 06, 2015 at 11:56:21AM +, Paul B Mahol wrote: > > Signed-off-by: Paul B Mahol > > --- > > libswscale/output.c | 48 > > > > libswscale/utils.c | 2 +- > > tests/ref/fate/filter-pixfmts-copy | 1 + > > tests/ref/fate/filter-pixfmts-crop | 1 + > > tests/ref/fate/filter-pixfmts-field | 1 + > > tests/ref/fate/filter-pixfmts-fieldorder | 1 + > > tests/ref/fate/filter-pixfmts-hflip | 1 + > > tests/ref/fate/filter-pixfmts-il | 1 + > > tests/ref/fate/filter-pixfmts-null | 1 + > > tests/ref/fate/filter-pixfmts-scale | 1 + > > tests/ref/fate/filter-pixfmts-vflip | 1 + > > 11 files changed, 58 insertions(+), 1 deletion(-) > > filter-pixfmts-fieldorder > TESTfilter-pixfmts-hflip > reference file './tests/ref/fate/filter-pixdesc-ayuv16le' not found > ./tests/fate-run.sh: 282: ./tests/fate-run.sh: cannot open > tests/data/fate/filter-pixdesc-ayuv16le.diff: No such file > Test filter-pixdesc-ayuv16le failed. Look at > tests/data/fate/filter-pixdesc-ayuv16le.err for details. > make: *** [fate-filter-pixdesc-ayuv16le] Error 1 > > patch should be ok otherwise (assuming roberts tests find no issues of course) [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] swscale: ayuv16 input support
On Mon, Jul 6, 2015 at 3:08 PM, Carl Eugen Hoyos wrote: > Paul B Mahol gmail.com> writes: > > > > Please mention the ticket in the commit message > > > for the swscaler output. > > > > Will, do. Although y416 have nothing to do with 16 bit ayuv. > > I completely agree but I think it turned out the the OP > wasn't really interested in y416 but in your patch;-) > > yes, it turned out that apparently incorrectly Apple documented that format as Y416 in their api docs and that definition seems to contradict documentation that I found on Y416. So I should update the ticket accordingly. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] implement process_command for vf_scale and vf_crop
Am 06.07.2015 um 11:17 schrieb Paul B Mahol: On 6/25/15, Bernd Blessmann wrote: Hi all, I want to implement process_command for vf_scale.c and vf_crop.c in order to use zmq to change scaling and cropping dynamically. I have implemented it using av_opt_set() and calling config_props() for scale and config_input() and config_output() for crop. I am using the config_-functions because they handle variable parsing and checking of the values. But I do not know if this is the right way to do it and if it is safe to call these functions from process_command. Maybe someone can comment on these implementation or outline a way to implement process_command for these filters. I attach patches including my implementation so far. Thank you very much in advance Bernd If it works I guess it should be ok. But newly added stuff should be somewhere documented... Yes. Thank you. I will have a look a the developer documentation again and add a commands entry to the filter documentation. Bernd ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: More correct selection of alignment of a frame height depending whether an encoded sequence progressive or not.
On Mon, Jul 06, 2015 at 11:52:21AM +0300, Ivan Uskov wrote: > Hello Michael, > > For any case there is need a way to encode h.264 with or without > active frame_mbs_only_flag into SPS. > If I understanding correct, the purpose of CODEC_FLAG_INTERLACED_DCT > is exactly for this. yes applied thanks [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] avcodec: Add support for Closed Caption export in h264
On Mon, Jul 06, 2015 at 01:05:01AM +0100, Kieran Kunhya wrote: > --- > libavcodec/h264.c | 9 + > libavcodec/h264.h | 2 ++ > libavcodec/h264_sei.c | 39 +-- > 3 files changed, 48 insertions(+), 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred with mmi
the new FC21 download address: http://loongnix.org/ftp/os/Fedora21/ the fault caused by ARCH_MIPS64 in configure doesn't match with O32 API in old FC19. it's different on loongson arch(or other mips arch) and x86 arch that 32bit system can only use mips32 instruction set. to achieve high performance, loongson use mips64r2 instruction set, and to use mmi SIMD loongson use -march=loongson3a in compiling. after running configure file, on old O32 FC19 you get ARCH_MIPS only, but on new FC21 you could specify API as O32, N32 or N64, because the new FC21 supported multi-libs. as most of the rpms were build with N64 and OS mainly aiming at 64bit application, ffmpeg should be configured and compiled into N64. with the new mips64el FC21 OS, you could compile correctly. the new FC21 you will download was a test release with gst-libav inside, which could decode 1080p mainline now. the ccache, dash and screen have been installed. the yum repo should be work abroad. if it doesn't, send your requirement to me. ^ ^ > -原始邮件- > 发件人: "Michael Niedermayer" > 发送时间: 2015年7月6日 星期一 > 收件人: "FFmpeg development discussions and patches" > 抄送: > 主题: Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred with > mmi > > On Fri, Jul 03, 2015 at 06:13:25PM +0800, 周晓勇 wrote: > > From dc50d05ba8a4d40e17f15a52237f33cff0205fea Mon Sep 17 00:00:00 2001 > > From: ZhouXiaoyong > > Date: Fri, 3 Jul 2015 16:56:01 +0800 > > Subject: [PATCH 4/4] avcodec: loongson optimized h264pred with mmi > > > > > > Signed-off-by: ZhouXiaoyong > > --- > > libavcodec/mips/Makefile | 1 + > > libavcodec/mips/h264pred_init_mips.c | 53 +++ > > libavcodec/mips/h264pred_mips.h | 53 +++ > > libavcodec/mips/h264pred_mmi.c | 799 > > +++ > > 4 files changed, 906 insertions(+) > > this fails with: > > /tmp/ccbnexwo.s: Assembler messages: > /tmp/ccbnexwo.s:44: Error: Number (0xfffbfffafff9fff8) larger than 32 bits > /tmp/ccbnexwo.s:46: Error: Number (0xfffefffdfffc) larger than 32 bits > /tmp/ccbnexwo.s:48: Error: Number (0x0004000300020001) larger than 32 bits > /tmp/ccbnexwo.s:50: Error: Number (0x0008000700060005) larger than 32 bits > /tmp/ccbnexwo.s:195: Error: Number (0x000300020001) larger than 32 bits > /tmp/ccbnexwo.s:198: Error: Number (0x0007000600050004) larger than 32 bits > /tmp/ccbnexwo.s:201: Error: Number (0x000b000a00090008) larger than 32 bits > /tmp/ccbnexwo.s:204: Error: Number (0x000f000e000d000c) larger than 32 bits > /tmp/ccbnexwo.s:302: Error: Number (0x0101010101010101) larger than 32 bits > /tmp/ccbnexwo.s:360: Error: Number (0x0101010101010101) larger than 32 bits > /tmp/ccbnexwo.s:1451: Error: Number (0x0001010101010101) larger than 32 bits > /tmp/ccbnexwo.s:1531: Error: Number (0x0101010101010101) larger than 32 bits > /tmp/ccbnexwo.s:1870: Error: Number (0x0101010101010101) larger than 32 bits > make: *** No rule to make target `libavcodec/mips/h264pred_mmi.o', needed by > `libavcodec/libavcodec.a'. Stop. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I do not agree with what you have to say, but I'll defend to the death your > right to say it. -- Voltaire ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: allow the user to ignore unused stream maps
On Wed, Jul 01, 2015 at 02:14:26PM -0500, Rodger Combs wrote: > --- > ffmpeg_opt.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) applied please post a patch to update docs thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred with mmi
upgrade the new FC21 with these steps: 1.mount Fedora21-xfce-Loongson-20150706.iso to /mnt 2.mkfs.ext3(ext4 may not supported by loongson pmon) the usb disk 3.copy all two folders in /mnt to usb 4.reboot and plug in usb disk 5.press key "u" until select menu 6.enter in usb disk(first menu) 7.enter in install system(please do not enter int other entries, because others not correctly work) 8.choose on partition to install 9.after install completed, reboot into any other os to enable first line in FC21 /etc/fstab: #/dev/sda8 / ext4 ... --> /dev/sda8 / ext4 ... (sdax is the partition which you installed yet) 10.copy /boot folder of FC21 partition into the first BOOT partition(sda1) to use the new kernel 3.18.xxx 11.modify the boot.cfg file in BOOT partision(sda1) > -原始邮件- > 发件人: "周晓勇" > 发送时间: 2015年7月6日 星期一 > 收件人: "FFmpeg development discussions and patches" > 抄送: > 主题: Re: Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred > with mmi > > the new FC21 download address: > http://loongnix.org/ftp/os/Fedora21/ > > the fault caused by ARCH_MIPS64 in configure doesn't match with O32 API in > old FC19. > it's different on loongson arch(or other mips arch) and x86 arch that 32bit > system can only use mips32 instruction set. > to achieve high performance, loongson use mips64r2 instruction set, and to > use mmi SIMD loongson use -march=loongson3a in compiling. > after running configure file, on old O32 FC19 you get ARCH_MIPS only, but on > new FC21 you could specify API as O32, N32 or N64, > because the new FC21 supported multi-libs. as most of the rpms were build > with N64 and OS mainly aiming at 64bit application, ffmpeg should be > configured and compiled into N64. > with the new mips64el FC21 OS, you could compile correctly. > > the new FC21 you will download was a test release with gst-libav inside, > which could decode 1080p mainline now. > the ccache, dash and screen have been installed. > the yum repo should be work abroad. if it doesn't, send your requirement to > me. ^ ^ > > > > > -原始邮件- > > 发件人: "Michael Niedermayer" > > 发送时间: 2015年7月6日 星期一 > > 收件人: "FFmpeg development discussions and patches" > > 抄送: > > 主题: Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred > > with mmi > > > > On Fri, Jul 03, 2015 at 06:13:25PM +0800, 周晓勇 wrote: > > > From dc50d05ba8a4d40e17f15a52237f33cff0205fea Mon Sep 17 00:00:00 2001 > > > From: ZhouXiaoyong > > > Date: Fri, 3 Jul 2015 16:56:01 +0800 > > > Subject: [PATCH 4/4] avcodec: loongson optimized h264pred with mmi > > > > > > > > > Signed-off-by: ZhouXiaoyong > > > --- > > > libavcodec/mips/Makefile | 1 + > > > libavcodec/mips/h264pred_init_mips.c | 53 +++ > > > libavcodec/mips/h264pred_mips.h | 53 +++ > > > libavcodec/mips/h264pred_mmi.c | 799 > > > +++ > > > 4 files changed, 906 insertions(+) > > > > this fails with: > > > > /tmp/ccbnexwo.s: Assembler messages: > > /tmp/ccbnexwo.s:44: Error: Number (0xfffbfffafff9fff8) larger than 32 bits > > /tmp/ccbnexwo.s:46: Error: Number (0xfffefffdfffc) larger than 32 bits > > /tmp/ccbnexwo.s:48: Error: Number (0x0004000300020001) larger than 32 bits > > /tmp/ccbnexwo.s:50: Error: Number (0x0008000700060005) larger than 32 bits > > /tmp/ccbnexwo.s:195: Error: Number (0x000300020001) larger than 32 bits > > /tmp/ccbnexwo.s:198: Error: Number (0x0007000600050004) larger than 32 bits > > /tmp/ccbnexwo.s:201: Error: Number (0x000b000a00090008) larger than 32 bits > > /tmp/ccbnexwo.s:204: Error: Number (0x000f000e000d000c) larger than 32 bits > > /tmp/ccbnexwo.s:302: Error: Number (0x0101010101010101) larger than 32 bits > > /tmp/ccbnexwo.s:360: Error: Number (0x0101010101010101) larger than 32 bits > > /tmp/ccbnexwo.s:1451: Error: Number (0x0001010101010101) larger than 32 bits > > /tmp/ccbnexwo.s:1531: Error: Number (0x0101010101010101) larger than 32 bits > > /tmp/ccbnexwo.s:1870: Error: Number (0x0101010101010101) larger than 32 bits > > make: *** No rule to make target `libavcodec/mips/h264pred_mmi.o', needed > > by `libavcodec/libavcodec.a'. Stop. > > > > [...] > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > I do not agree with what you have to say, but I'll defend to the death your > > right to say it. -- Voltaire > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_colormatrix: add yuv444p support
Signed-off-by: Paul B Mahol
---
libavfilter/vf_colormatrix.c | 53 +++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c
index 4971cac..c0ca9ee 100644
--- a/libavfilter/vf_colormatrix.c
+++ b/libavfilter/vf_colormatrix.c
@@ -230,6 +230,53 @@ static int process_slice_uyvy422(AVFilterContext *ctx,
void *arg, int jobnr, int
return 0;
}
+static int process_slice_yuv444p(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
+{
+const ThreadData *td = arg;
+const AVFrame *src = td->src;
+AVFrame *dst = td->dst;
+const int height = src->height;
+const int width = src->width;
+const int slice_start = (height * jobnr ) / nb_jobs;
+const int slice_end = (height * (jobnr+1)) / nb_jobs;
+const int src_pitchY = src->linesize[0];
+const int src_pitchUV = src->linesize[1];
+const unsigned char *srcpU = src->data[1] + slice_start * src_pitchUV;
+const unsigned char *srcpV = src->data[2] + slice_start * src_pitchUV;
+const unsigned char *srcpY = src->data[0] + slice_start * src_pitchY;
+const int dst_pitchY = dst->linesize[0];
+const int dst_pitchUV = dst->linesize[1];
+unsigned char *dstpU = dst->data[1] + slice_start * dst_pitchUV;
+unsigned char *dstpV = dst->data[2] + slice_start * dst_pitchUV;
+unsigned char *dstpY = dst->data[0] + slice_start * dst_pitchY;
+const int c2 = td->c2;
+const int c3 = td->c3;
+const int c4 = td->c4;
+const int c5 = td->c5;
+const int c6 = td->c6;
+const int c7 = td->c7;
+int x, y;
+
+for (y = slice_start; y < slice_end; y++) {
+for (x = 0; x < width; x++) {
+const int u = srcpU[x] - 128;
+const int v = srcpV[x] - 128;
+const int uvval = c2 * u + c3 * v + 1081344;
+dstpY[x] = CB((65536 * (srcpY[x] - 16) + uvval) >> 16);
+dstpU[x] = CB((c4 * u + c5 * v + 8421376) >> 16);
+dstpV[x] = CB((c6 * u + c7 * v + 8421376) >> 16);
+}
+srcpY += src_pitchY;
+dstpY += dst_pitchY;
+srcpU += src_pitchUV;
+srcpV += src_pitchUV;
+dstpU += dst_pitchUV;
+dstpV += dst_pitchUV;
+}
+
+return 0;
+}
+
static int process_slice_yuv422p(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
const ThreadData *td = arg;
@@ -350,6 +397,7 @@ static int config_input(AVFilterLink *inlink)
static int query_formats(AVFilterContext *ctx)
{
static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUV444P,
AV_PIX_FMT_YUV422P,
AV_PIX_FMT_YUV420P,
AV_PIX_FMT_UYVY422,
@@ -411,7 +459,10 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
td.c6 = color->yuv_convert[color->mode][2][1];
td.c7 = color->yuv_convert[color->mode][2][2];
-if (in->format == AV_PIX_FMT_YUV422P)
+if (in->format == AV_PIX_FMT_YUV444P)
+ctx->internal->execute(ctx, process_slice_yuv444p, &td, NULL,
+ FFMIN(in->height, ctx->graph->nb_threads));
+else if (in->format == AV_PIX_FMT_YUV422P)
ctx->internal->execute(ctx, process_slice_yuv422p, &td, NULL,
FFMIN(in->height, ctx->graph->nb_threads));
else if (in->format == AV_PIX_FMT_YUV420P)
--
1.7.11.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: A warning message when library will work at partial hardware acceleration
Hello All, There is the patch attached which add warning message for case when QSV/MFX encoder has been initialized to work with partial hardware acceleration. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-qsvenc.c-A-warning-message-when-library-w.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc.c: A warning message when library will work at partial hardware acceleration
On Mon, Jul 06, 2015 at 05:15:24PM +0300, Ivan Uskov wrote: > Hello All, > > There is the patch attached which add warning message for case when > QSV/MFX encoder has been initialized to work with partial hardware > acceleration. > > -- > Best regards, > Ivan mailto:ivan.us...@nablet.com > qsvenc.c |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > 960ad0846100b695e4d45ed31cbb109680f1b7cc > 0001-libavcodec-qsvenc.c-A-warning-message-when-library-w.patch > From 94a18d7f18d6897333480c5095f881b4c60ec3a7 Mon Sep 17 00:00:00 2001 > From: Ivan Uskov > Date: Mon, 6 Jul 2015 16:58:33 +0300 > Subject: [PATCH] libavcodec/qsvenc.c: A warning message when library will work > at partial hardware acceleration. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
Hi!
Attached patch adds "Closed Captions" to the codec dump if
the video stream contains them.
Please comment, Carl Eugen
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e367399..c39a241 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3171,6 +3171,14 @@ typedef struct AVCodecContext {
* - decoding: set by user through AVOPtions (NO direct access)
*/
char *codec_whitelist;
+
+/**
+ * Set if the (video) stream contains internal Closed Captions
+ * Not to be accessed outside of libavcodec
+ * - encoding: unused
+ * - decoding: set by libavcodec
+ */
+int closed_captions;
} AVCodecContext;
AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index f62ad6a..824abd6 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -886,6 +886,7 @@ static void decode_postinit(H264Context *h, int
setup_finished)
memcpy(sd->data, h->a53_caption, h->a53_caption_size);
av_freep(&h->a53_caption);
h->a53_caption_size = 0;
+h->avctx->closed_captions = 1;
}
cur->mmco_reset = h->mmco_reset;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index b0e5ae9..c250d55 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1685,6 +1685,7 @@ static int mpeg_field_start(MpegEncContext *s, const
uint8_t *buf, int buf_size)
if (sd)
memcpy(sd->data, s1->a53_caption, s1->a53_caption_size);
av_freep(&s1->a53_caption);
+avctx->closed_captions = 1;
}
if (s1->has_stereo3d) {
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index b80b4e7..26b1662 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3136,6 +3136,10 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *enc, int encode)
if (encode) {
snprintf(buf + strlen(buf), buf_size - strlen(buf),
", q=%d-%d", enc->qmin, enc->qmax);
+} else {
+if (enc->closed_captions)
+snprintf(buf + strlen(buf), buf_size - strlen(buf),
+ ", Closed Captions");
}
break;
case AVMEDIA_TYPE_AUDIO:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
On Mon, Jul 6, 2015 at 5:53 PM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch adds "Closed Captions" to the codec dump if > the video stream contains them. > Adding fields to a public context which should never be accessed by the public is a big no-no. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow native jpeg 2000 encoding yuv42x and yuv41x
On Fri, Jul 03, 2015 at 05:18:03PM +, Paul B Mahol wrote: > On 7/3/15, Michael Niedermayer wrote: > > On Fri, Jul 03, 2015 at 12:34:21PM +0200, Carl Eugen Hoyos wrote: > >> Hi! > >> > >> Attached patch allows lossless encoding of lena.pnm > >> in yuv420p, yuv422p, yuv410p and yuv411p with the > >> native jpeg 2000 encoder, fixes tickets #535 and > >> #4524. > >> Tested only with FFmpeg, all other decoders also > >> fail for file3.jp2, the relevant sample from the > >> reference file suite. > >> > >> Please comment, Carl Eugen > > > > if it works now after the decder fix the this should be ok > > It kinda works, decoder dumps bunch of yellow warnings but final > output looks ok. > Encoder on other hand for yuv420p use bunch of memory ~330MB. is it worse than with other parameters ? jpeg2000 is a rather overcomplicated format > > ImageMagick does not like ffmpeg output. does ImageMagick support this type of jpeg2000 ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
Hendrik Leppkes gmail.com> writes: > > Attached patch adds "Closed Captions" to the codec > > dump if the video stream contains them. > > Adding fields to a public context which should never > be accessed by the public is a big no-no. What is the alternative? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Allow native jpeg 2000 encoding yuv42x and yuv41x
Carl Eugen Hoyos ag.or.at> writes: > AV_PIX_FMT_RGB24, AV_PIX_FMT_YUV444P, AV_PIX_FMT_GRAY8, > -/* AV_PIX_FMT_YUV420P, > -AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P, > -AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,*/ > +AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, > +AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P, The patch was merged after Michael fixed the decoding issue for resolutions > 256x256. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
On Monday 06 July 2015 06:18:14 pm Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
> > > Attached patch adds "Closed Captions" to the codec
> > > dump if the video stream contains them.
> >
> > Adding fields to a public context which should never
> > be accessed by the public is a big no-no.
>
> What is the alternative?
As in attached?
Carl Eugen
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e367399..cc71f10 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3171,6 +3171,14 @@ typedef struct AVCodecContext {
* - decoding: set by user through AVOPtions (NO direct access)
*/
char *codec_whitelist;
+
+/**
+ * Set if the (video) stream contains internal Closed Captions
+ * To be accessed through av_codec_get_closed_captions() (NO direct access)
+ * - encoding: unused
+ * - decoding: set by libavcodec
+ */
+int closed_captions;
} AVCodecContext;
AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
@@ -3185,6 +3193,12 @@ void av_codec_set_lowres(AVCodecContext *avctx, int val);
int av_codec_get_seek_preroll(const AVCodecContext *avctx);
void av_codec_set_seek_preroll(AVCodecContext *avctx, int val);
+/**
+ * Returns >0 if Closed Captions were found in the (video) stream
+ * Returns 0 if no Closed Captions were found in the (video) stream
+ */
+int av_codec_get_closed_captions(const AVCodecContext *avctx);
+
uint16_t *av_codec_get_chroma_intra_matrix(const AVCodecContext *avctx);
void av_codec_set_chroma_intra_matrix(AVCodecContext *avctx, uint16_t *val);
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index f62ad6a..824abd6 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -886,6 +886,7 @@ static void decode_postinit(H264Context *h, int
setup_finished)
memcpy(sd->data, h->a53_caption, h->a53_caption_size);
av_freep(&h->a53_caption);
h->a53_caption_size = 0;
+h->avctx->closed_captions = 1;
}
cur->mmco_reset = h->mmco_reset;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index b0e5ae9..c250d55 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1685,6 +1685,7 @@ static int mpeg_field_start(MpegEncContext *s, const
uint8_t *buf, int buf_size)
if (sd)
memcpy(sd->data, s1->a53_caption, s1->a53_caption_size);
av_freep(&s1->a53_caption);
+avctx->closed_captions = 1;
}
if (s1->has_stereo3d) {
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index b80b4e7..a875f7c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1299,6 +1299,11 @@ MAKE_ACCESSORS(AVCodecContext, codec, int, lowres)
MAKE_ACCESSORS(AVCodecContext, codec, int, seek_preroll)
MAKE_ACCESSORS(AVCodecContext, codec, uint16_t*, chroma_intra_matrix)
+int av_codec_get_closed_captions(const AVCodecContext *codec)
+{
+return codec->closed_captions;
+}
+
int av_codec_get_max_lowres(const AVCodec *codec)
{
return codec->max_lowres;
@@ -3136,6 +3141,10 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *enc, int encode)
if (encode) {
snprintf(buf + strlen(buf), buf_size - strlen(buf),
", q=%d-%d", enc->qmin, enc->qmax);
+} else {
+if (enc->closed_captions)
+snprintf(buf + strlen(buf), buf_size - strlen(buf),
+ ", Closed Captions");
}
break;
case AVMEDIA_TYPE_AUDIO:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for mpegvideoencdsp functions
On Mon, Jun 29, 2015 at 08:57:13PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > This patch adds MSA (MIPS-SIMD-Arch) optimizations for mpegvideoencdsp > functions in new file mpegvideoencdsp_msa.c > > Signed-off-by: Shivraj Patil > --- > libavcodec/mips/Makefile| 2 + > libavcodec/mips/mpegvideoencdsp_init_mips.c | 40 +++ > libavcodec/mips/mpegvideoencdsp_msa.c | 62 > + > libavcodec/mpegvideoencdsp.c| 2 + > libavcodec/mpegvideoencdsp.h| 2 + > libavutil/mips/generic_macros_msa.h | 34 > 6 files changed, 142 insertions(+) > create mode 100644 libavcodec/mips/mpegvideoencdsp_init_mips.c > create mode 100644 libavcodec/mips/mpegvideoencdsp_msa.c applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for me_cmp functions
On Mon, Jun 29, 2015 at 08:57:14PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > This patch adds MSA (MIPS-SIMD-Arch) optimizations for me_cmp functions in > new file me_cmp_msa.c > > Signed-off-by: Shivraj Patil > --- > libavcodec/me_cmp.c | 2 + > libavcodec/me_cmp.h | 1 + > libavcodec/mips/Makefile| 2 + > libavcodec/mips/me_cmp_init_mips.c | 56 +++ > libavcodec/mips/me_cmp_mips.h | 60 > libavcodec/mips/me_cmp_msa.c| 686 > > libavutil/mips/generic_macros_msa.h | 59 > 7 files changed, 866 insertions(+) > create mode 100644 libavcodec/mips/me_cmp_init_mips.c > create mode 100644 libavcodec/mips/me_cmp_mips.h > create mode 100644 libavcodec/mips/me_cmp_msa.c applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] movtextdec.c: Add support for highlight and hilightcolor box
From: Niklesh
Signed-off-by: Niklesh
---
libavcodec/movtextdec.c | 254 +---
1 file changed, 173 insertions(+), 81 deletions(-)
diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index a3afd91..7e9e4f5 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -31,37 +31,166 @@
#define STYLE_FLAG_ITALIC (1<<1)
#define STYLE_FLAG_UNDERLINE(1<<2)
+#define STYL_BOX (1<<0)
+#define HLIT_BOX (1<<1)
+#define HCLR_BOX (1<<2)
+
typedef struct {
uint16_t style_start;
uint16_t style_end;
uint8_t style_flag;
} StyleBox;
+typedef struct {
+uint16_t hlit_start;
+uint16_t hlit_end;
+} HighlightBox;
+
+typedef struct {
+ uint8_t hlit_color[4];
+} HilightcolorBox;
+
+typedef struct {
+StyleBox **s;
+StyleBox *s_temp;
+HighlightBox h;
+HilightcolorBox c;
+uint8_t box_flags;
+uint16_t style_entries;
+uint64_t tracksize;
+int size_var;
+int count_s;
+} MovTextContext;
+
+struct Box
+{
+uint32_t type;
+size_t base_size;
+int (*decode)(const uint8_t *tsmb, MovTextContext *m, AVPacket *avpkt);
+};
+
+static void mov_text_cleanup(MovTextContext *m)
+{
+int i;
+if (m->box_flags & STYL_BOX) {
+for(i = 0; i < m->count_s; i++) {
+av_freep(&m->s[i]);
+}
+av_freep(&m->s);
+}
+}
+
+static int decode_hlit(const uint8_t *tsmb, MovTextContext *m, AVPacket *avpkt)
+{
+m->box_flags |= HLIT_BOX;
+m->h.hlit_start = AV_RB16(tsmb);
+tsmb += 2;
+m->h.hlit_end = AV_RB16(tsmb);
+tsmb += 2;
+return 0;
+}
+
+static int decode_hclr(const uint8_t *tsmb, MovTextContext *m, AVPacket *avpkt)
+{
+m->box_flags |= HCLR_BOX;
+m->c.hlit_color[0] = *tsmb++;
+m->c.hlit_color[1] = *tsmb++;
+m->c.hlit_color[2] = *tsmb++;
+m->c.hlit_color[3] = *tsmb++;
+return 0;
+}
+
+static int decode_styl(const uint8_t *tsmb, MovTextContext *m, AVPacket *avpkt)
+{
+int i;
+m->style_entries = AV_RB16(tsmb);
+tsmb += 2;
+// A single style record is of length 12 bytes.
+if (m->tracksize + m->size_var + 2 + m->style_entries * 12 > avpkt->size)
+return -1;
+
+m->box_flags |= STYL_BOX;
+for(i = 0; i < m->style_entries; i++) {
+m->s_temp = av_malloc(sizeof(StyleBox));
+if (!m->s_temp) {
+mov_text_cleanup(m);
+return AVERROR(ENOMEM);
+}
+m->s_temp->style_start = AV_RB16(tsmb);
+tsmb += 2;
+m->s_temp->style_end = AV_RB16(tsmb);
+tsmb += 2;
+// fontID = AV_RB16(tsmb);
+tsmb += 2;
+m->s_temp->style_flag = AV_RB8(tsmb);
+av_dynarray_add(&m->s, &m->count_s, m->s_temp);
+if(!m->s) {
+mov_text_cleanup(m);
+return AVERROR(ENOMEM);
+}
+// fontsize = AV_RB8(tsmb);
+tsmb += 2;
+// text-color-rgba
+tsmb += 4;
+}
+return 0;
+}
+
+struct Box box_types[] = {
+{ MKBETAG('s','t','y','l'), 2, decode_styl },
+{ MKBETAG('h','l','i','t'), 4, decode_hlit },
+{ MKBETAG('h','c','l','r'), 4, decode_hclr }
+};
+
+const static size_t box_count = sizeof(box_types) / sizeof(struct Box);
+
static int text_to_ass(AVBPrint *buf, const char *text, const char *text_end,
-StyleBox **s, int style_entries)
+MovTextContext *m)
{
int i = 0;
int text_pos = 0;
while (text < text_end) {
-for (i = 0; i < style_entries; i++) {
-if (s[i]->style_flag && text_pos == s[i]->style_end) {
-if (s[i]->style_flag & STYLE_FLAG_BOLD)
-av_bprintf(buf, "{\\b0}");
-if (s[i]->style_flag & STYLE_FLAG_ITALIC)
-av_bprintf(buf, "{\\i0}");
-if (s[i]->style_flag & STYLE_FLAG_UNDERLINE)
-av_bprintf(buf, "{\\u0}");
+if (m->box_flags & STYL_BOX) {
+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag && text_pos == m->s[i]->style_end) {
+if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
+av_bprintf(buf, "{\\b0}");
+if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
+av_bprintf(buf, "{\\i0}");
+if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
+av_bprintf(buf, "{\\u0}");
+}
+}
+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag && text_pos == m->s[i]->style_start) {
+if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
+av_bprintf(buf, "{\\b1}");
+if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
+av_bprintf(buf, "{\\i1}");
+if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
+av_bprintf(buf, "{\\u1}");
+}
Re: [FFmpeg-devel] [PATCH 1/4] concatdec: add support for specifying inpoint of files
L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit : > Signed-off-by: Marton Balint > --- > doc/demuxers.texi | 17 + > libavformat/concatdec.c | 48 +++- > 2 files changed, 52 insertions(+), 13 deletions(-) I like the feature, but I find the name of the directive, "in", too generic. Maybe "seek" is the best choice? Also, the timestamp computation code is starting to be a bit complex. Maybe now is a good time to move file_start_time to the per-file structure. But I will not consider this blocking. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] concatdec: store eof condition in context
L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit : > This is needed later for outpoint support which may leave the last file in a > not-eof state. > > Signed-off-by: Marton Balint > --- > libavformat/concatdec.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Ok. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] concatdec: add support for specifying outpoint of files
L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit :
> Signed-off-by: Marton Balint
> ---
> doc/demuxers.texi | 13 +
> libavformat/concatdec.c | 22 --
> 2 files changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 4bad1c8..4ba797e 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -129,6 +129,19 @@ directive) will be reduced based on their specified In
> point.
> Because of potential packets before the specified In point, packet timestamps
> may overlap between two concatenated files.
>
> +@item @code{out @var{timestamp}}
> +Out point of the file. When the demuxer reaches the specified timestamp in
> any
> +of the streams, it handles it as an end of file condition. Out point is
> +exclusive, which means that the demuxer will not output packets which has a
> +timestamp greater or equal to Out point.
> +
> +This directive works best with intra frame codecs, because for non-intra
> frame
> +ones you will usually not get enough packets to decode the last few frames
> +before the specified Out point.
> +
> +The duration of the files (if not specified by the @code{duration}
> +directive) will be reduced based on their specified Out point.
> +
> @item @code{stream}
> Introduce a stream in the virtual file.
> All subsequent stream-related directives apply to the last introduced
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index 11e6759..eaf34b0 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -44,6 +44,7 @@ typedef struct {
> int64_t duration;
> ConcatStream *streams;
> int64_t inpoint;
> +int64_t outpoint;
> int nb_streams;
> } ConcatFile;
>
> @@ -145,6 +146,7 @@ static int add_file(AVFormatContext *avf, char *filename,
> ConcatFile **rfile,
> file->start_time = AV_NOPTS_VALUE;
> file->duration = AV_NOPTS_VALUE;
> file->inpoint= AV_NOPTS_VALUE;
> +file->outpoint = AV_NOPTS_VALUE;
>
> return 0;
>
> @@ -360,7 +362,7 @@ static int concat_read_header(AVFormatContext *avf)
> }
> if ((ret = add_file(avf, filename, &file, &nb_files_alloc)) < 0)
> goto fail;
> -} else if (!strcmp(keyword, "duration") || !strcmp(keyword, "in")) {
> +} else if (!strcmp(keyword, "duration") || !strcmp(keyword, "in") ||
> !strcmp(keyword, "out")) {
> char *dur_str = get_keyword(&cursor);
> int64_t dur;
> if (!file) {
> @@ -377,6 +379,8 @@ static int concat_read_header(AVFormatContext *avf)
> file->duration = dur;
> else if (!strcmp(keyword, "in"))
> file->inpoint = dur;
> +else if (!strcmp(keyword, "out"))
> +file->outpoint = dur;
> } else if (!strcmp(keyword, "stream")) {
> if (!avformat_new_stream(avf, NULL))
> FAIL(AVERROR(ENOMEM));
> @@ -443,6 +447,8 @@ static int open_next_file(AVFormatContext *avf)
> cat->cur_file->duration = cat->avf->duration;
> if (cat->cur_file->inpoint != AV_NOPTS_VALUE)
> cat->cur_file->duration -= (cat->cur_file->inpoint -
> file_start_time);
> +if (cat->cur_file->outpoint != AV_NOPTS_VALUE)
> +cat->cur_file->duration -= cat->avf->duration -
> (cat->cur_file->outpoint - file_start_time);
> }
>
> if (++fileno >= cat->nb_files) {
> @@ -504,6 +510,16 @@ static int64_t get_cur_file_inpoint(ConcatContext *cat)
> return file_inpoint;
> }
>
> +/* Returns true if the packet pts is greater or equal to the specified
> outpoint. */
> +static int packet_after_outpoint(ConcatContext *cat, AVPacket *pkt)
> +{
> +if (cat->cur_file->outpoint != AV_NOPTS_VALUE && pkt->pts !=
> AV_NOPTS_VALUE) {
> +return av_compare_ts(pkt->pts,
> cat->avf->streams[pkt->stream_index]->time_base,
> + cat->cur_file->outpoint, AV_TIME_BASE_Q) >= 0;
> +}
> +return 0;
> +}
> +
> static int concat_read_packet(AVFormatContext *avf, AVPacket *pkt)
> {
> ConcatContext *cat = avf->priv_data;
> @@ -520,7 +536,9 @@ static int concat_read_packet(AVFormatContext *avf,
> AVPacket *pkt)
>
> while (1) {
> ret = av_read_frame(cat->avf, pkt);
> -if (ret == AVERROR_EOF) {
> +if (ret == AVERROR_EOF || packet_after_outpoint(cat, pkt)) {
> +if (ret == 0)
> +av_packet_unref(pkt);
This will not work if the streams in the file are not exactly interleaved.
Some formats store subtitles, and even audio, a few frames early, that will
trigger EOF even though there may be frames below the outpoint still coming.
At least, the documentation should have a warning about it.
> if ((ret = open_next_file(avf)) < 0)
> return ret;
> continue;
No other objection, but if you change the name of the inpoint option,
Re: [FFmpeg-devel] [PATCH] fate/api: simplify
On 06/07/15 9:10 AM, George Boyle wrote: > This has a couple of implications for the running of these tests in > certain circumstances. Whether these circumstances are important or > realistic, I do not know. In particular, I tested by configuring with > "--disable-avformat" and in that case, "make fate" works fine, but > necessarily excludes all API tests, and the "fate-api" target will fail > if SAMPLES isn't set. This happens with most targets requiring samples. They are skipped if you simply run "make fate" but will try to run and fail if you call them explicitly. fate-api-flac will still run before it fails with the h264 test if you call make fate-api. Now, i'm not sure if there are other similar cases. After a quick glance every explicit target seems to require samples for all tests or none. This would be the first with mixed tests. > > >> -FATE_API_SAMPLES_LIBAVFORMAT-$(call DEMDEC, H264, H264) += fate-api-h264 >> +FATE_API_SAMPLES-$(call DEMDEC, H264, H264) += fate-api-h264 >> fate-api-h264: $(APITESTSDIR)/api-h264-test$(EXESUF) >> fate-api-h264: CMD = run $(APITESTSDIR)/api-h264-test >> $(TARGET_SAMPLES)/h264-conformance/SVA_NL2_E.264 >> >> -FATE_API_SAMPLES-$(CONFIG_AVFORMAT) += $(FATE_API_SAMPLES_LIBAVFORMAT-yes) > > As far as I can tell, $(call DEMDEC, X, Y) does not necessarily imply > $(CONFIG_AVFORMAT), so "--disable-avformat" led to a condition where > this failed. $(call DEMDEC, X, Y) implies the availability of the requested decoder and demuxer. If said demuxer is still enabled in config.mak after configuring with "--disable-avformat" then that's probably a build system bug. > > >> +FATE_FFMPEG += $(FATE_API-yes) >> +FATE_SAMPLES_FFMPEG += $(FATE_API_SAMPLES-yes) > > This causes all the API tests to depend on the ffmpeg program. Strictly > speaking they shouldn't need to, at least for the tests that are > currently there. And this also explains why "--disable-avformat" will > exclude the API tests from "make fate". > Right, didn't realize this makes it dependent of ffmpeg. I'll see if i can get around this later. Patch dropped until then. > >> >> -ifdef SAMPLES >> -FATE_API_SAMPLES += $(FATE_API_SAMPLES-yes) >> -endif >> - >> -FATE_API-$(CONFIG_AVCODEC) += $(FATE_API_LIBAVCODEC-yes) >> -FATE_API-$(CONFIG_AVFORMAT) += $(FATE_API_LIBAVFORMAT-yes) >> -FATE_API = $(FATE_API-yes) >> - >> -FATE-yes += $(FATE_API) $(FATE_API_SAMPLES) >> - >> -fate-api: $(FATE_API) $(FATE_API_SAMPLES) >> +fate-api: $(FATE_API-yes) $(FATE_API_SAMPLES-yes) >> > > This will add the sample-dependent tests to the "fate-api" target, > whether or not SAMPLES is set. > > > I guess the question is whether there are a limited number of desired > use cases to support like "configure && make fate", or the tests should > be robust to more particular circumstances/configurations (by the way, > I'm not claiming the existing state covers all bases in that respect). > If it's the former, then this patch makes things much neater. If it's > the latter, then the old state seems to cover more cases. Which is > better is not for me to decide. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] concatdec: add support for injecting packet metadata
L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit :
> Signed-off-by: Marton Balint
> ---
> doc/demuxers.texi | 4
> libavformat/concatdec.c | 30 ++
> 2 files changed, 34 insertions(+)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 4ba797e..28244f3 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -142,6 +142,10 @@ before the specified Out point.
> The duration of the files (if not specified by the @code{duration}
> directive) will be reduced based on their specified Out point.
>
> +@item @code{metadata @var{string}}
> +Metadata of the file. The specified metadata (which consists of
> +@code{key=value} pairs seperated by commas) will be set for each file packet.
This looks like a step into escaping hell.
metadata foo=bar,baz=qux
metadata foo=bar
metadata baz=qux
Would the second form be ok for you?
> +
> @item @code{stream}
> Introduce a stream in the virtual file.
> All subsequent stream-related directives apply to the last introduced
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index eaf34b0..66e81c8 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -45,6 +45,8 @@ typedef struct {
> ConcatStream *streams;
> int64_t inpoint;
> int64_t outpoint;
> +char *metadata;
> +int metadata_len;
> int nb_streams;
> } ConcatFile;
>
> @@ -329,6 +331,7 @@ static int concat_read_close(AVFormatContext *avf)
> avformat_close_input(&cat->avf);
> for (i = 0; i < cat->nb_files; i++) {
> av_freep(&cat->files[i].url);
> +av_freep(&cat->files[i].metadata);
> av_freep(&cat->files[i].streams);
> }
> av_freep(&cat->files);
> @@ -381,6 +384,27 @@ static int concat_read_header(AVFormatContext *avf)
> file->inpoint = dur;
> else if (!strcmp(keyword, "out"))
> file->outpoint = dur;
> +} else if (!strcmp(keyword, "metadata")) {
> +AVDictionary *opts = NULL;
> +char *metadata;
> +if (file->metadata) {
> +av_log(avf, AV_LOG_ERROR, "Line %d: metadata is already
> provided\n", line);
> +FAIL(AVERROR_INVALIDDATA);
> +}
> +metadata = av_get_token((const char **)&cursor, SPACE_CHARS);
> +if (!metadata) {
> +av_log(avf, AV_LOG_ERROR, "Line %d: metadata required\n",
> line);
> +FAIL(AVERROR_INVALIDDATA);
> +}
> +if ((ret = av_dict_parse_string(&opts, metadata, "=", ",", 0)) <
> 0) {
> +av_log(avf, AV_LOG_ERROR, "Line %d: failed to parse metadata
> string\n", line);
> +av_freep(&metadata);
> +av_dict_free(&opts);
> +FAIL(AVERROR_INVALIDDATA);
> +}
> +file->metadata = av_packet_pack_dictionary(opts,
> &file->metadata_len);
> +av_freep(&metadata);
> +av_dict_free(&opts);
> } else if (!strcmp(keyword, "stream")) {
> if (!avformat_new_stream(avf, NULL))
> FAIL(AVERROR(ENOMEM));
> @@ -576,6 +600,12 @@ static int concat_read_packet(AVFormatContext *avf,
> AVPacket *pkt)
> av_log(avf, AV_LOG_DEBUG, " -> pts:%s pts_time:%s dts:%s dts_time:%s\n",
> av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base),
> av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base));
> +if (cat->cur_file->metadata) {
> +uint8_t* metadata;
> +if (!(metadata = av_packet_new_side_data(pkt,
> AV_PKT_DATA_STRINGS_METADATA, cat->cur_file->metadata_len)))
> +return AVERROR(ENOMEM);
> +memcpy(metadata, cat->cur_file->metadata,
> cat->cur_file->metadata_len);
> +}
> return ret;
> }
>
No other objection, but can you explain the use case? Packet metadata is not
very common.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] lavf/tcp: add tcp_accept
Le sextidi 16 messidor, an CCXXIII, Stephan Holljes a écrit :
> Signed-off-by: Stephan Holljes
> ---
> libavformat/tcp.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index f24cad2..71dff7a 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -19,6 +19,7 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
> #include "avformat.h"
> +#include "libavutil/avassert.h"
> #include "libavutil/parseutils.h"
> #include "libavutil/opt.h"
> #include "libavutil/time.h"
> @@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int
> flags)
> return ret;
> }
>
> +static int tcp_accept(URLContext *s, URLContext **c)
> +{
> +TCPContext *sc = s->priv_data;
> +TCPContext *cc;
> +int ret;
> +av_assert0(sc->listen);
> +if ((ret = ffurl_alloc(c, s->filename, AVIO_FLAG_READ_WRITE,
> &s->interrupt_callback)) < 0)
> +return ret;
My previous comment said: "Maybe c->flags instead of hardcoding
AVIO_FLAG_READ_WRITE?", what happened to it? It is ok to not agree with it,
but not to ignore it entirely.
> +cc = (*c)->priv_data;
> +ret = ff_accept(sc->fd, sc->listen_timeout, s);
> +if (ret < 0)
> +return ff_neterrno();
> +cc->fd = ret;
> +return 0;
> +}
> +
> static int tcp_read(URLContext *h, uint8_t *buf, int size)
> {
> TCPContext *s = h->priv_data;
> @@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
> URLProtocol ff_tcp_protocol = {
> .name= "tcp",
> .url_open= tcp_open,
> +.url_accept = tcp_accept,
> .url_read= tcp_read,
> .url_write = tcp_write,
> .url_close = tcp_close,
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] lavf/tcp: add tcp_accept
On Mon, Jul 6, 2015 at 7:58 PM, Nicolas George wrote:
> Le sextidi 16 messidor, an CCXXIII, Stephan Holljes a écrit :
>> Signed-off-by: Stephan Holljes
>> ---
>> libavformat/tcp.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
>> index f24cad2..71dff7a 100644
>> --- a/libavformat/tcp.c
>> +++ b/libavformat/tcp.c
>> @@ -19,6 +19,7 @@
>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
>> USA
>> */
>> #include "avformat.h"
>> +#include "libavutil/avassert.h"
>> #include "libavutil/parseutils.h"
>> #include "libavutil/opt.h"
>> #include "libavutil/time.h"
>> @@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int
>> flags)
>> return ret;
>> }
>>
>> +static int tcp_accept(URLContext *s, URLContext **c)
>> +{
>> +TCPContext *sc = s->priv_data;
>> +TCPContext *cc;
>> +int ret;
>> +av_assert0(sc->listen);
>
>> +if ((ret = ffurl_alloc(c, s->filename, AVIO_FLAG_READ_WRITE,
>> &s->interrupt_callback)) < 0)
>> +return ret;
>
> My previous comment said: "Maybe c->flags instead of hardcoding
> AVIO_FLAG_READ_WRITE?", what happened to it? It is ok to not agree with it,
> but not to ignore it entirely.
Sorry, I must have missed that remark. Fixed in attached patch.
>
>> +cc = (*c)->priv_data;
>> +ret = ff_accept(sc->fd, sc->listen_timeout, s);
>> +if (ret < 0)
>> +return ff_neterrno();
>> +cc->fd = ret;
>> +return 0;
>> +}
>> +
>> static int tcp_read(URLContext *h, uint8_t *buf, int size)
>> {
>> TCPContext *s = h->priv_data;
>> @@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
>> URLProtocol ff_tcp_protocol = {
>> .name= "tcp",
>> .url_open= tcp_open,
>> +.url_accept = tcp_accept,
>> .url_read= tcp_read,
>> .url_write = tcp_write,
>> .url_close = tcp_close,
>
> Regards,
>
> --
> Nicolas George
Regards,
Stephan
From d796bbc8160af59995d10d17779f3909a7ee62e5 Mon Sep 17 00:00:00 2001
From: Stephan Holljes
Date: Fri, 3 Jul 2015 02:27:09 +0200
Subject: [PATCH] lavf/tcp: add tcp_accept
Signed-off-by: Stephan Holljes
---
libavformat/tcp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index f24cad2..6f5e175 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -19,6 +19,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include "avformat.h"
+#include "libavutil/avassert.h"
#include "libavutil/parseutils.h"
#include "libavutil/opt.h"
#include "libavutil/time.h"
@@ -163,6 +164,22 @@ static int tcp_open(URLContext *h, const char *uri, int flags)
return ret;
}
+static int tcp_accept(URLContext *s, URLContext **c)
+{
+TCPContext *sc = s->priv_data;
+TCPContext *cc;
+int ret;
+av_assert0(sc->listen);
+if ((ret = ffurl_alloc(c, s->filename, s->flags & AVIO_FLAG_READ_WRITE, &s->interrupt_callback)) < 0)
+return ret;
+cc = (*c)->priv_data;
+ret = ff_accept(sc->fd, sc->listen_timeout, s);
+if (ret < 0)
+return ff_neterrno();
+cc->fd = ret;
+return 0;
+}
+
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h->priv_data;
@@ -223,6 +240,7 @@ static int tcp_get_file_handle(URLContext *h)
URLProtocol ff_tcp_protocol = {
.name= "tcp",
.url_open= tcp_open,
+.url_accept = tcp_accept,
.url_read= tcp_read,
.url_write = tcp_write,
.url_close = tcp_close,
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 9/9] Add http multi-client example code
Le sextidi 16 messidor, an CCXXIII, Stephan Holljes a écrit :
> Yes, I tested it with multiple simultaneous wget instances and with
> siege (a benchmark tool for webservers).
Good. Although you should also test manually, with socat / nc / telnet.
> I see that I missed closing the client context in the server process,
> but I think the server context is being closed when the client process
> reaches the end label.
Yes, but that is too late: imagine you want to restart the server while some
clients are still alive. It is good practice to close file descriptors as
soon as possible, and with forking servers it is especially important to
follow that practice.
Of course, with example code, following good practices can be dispensed
with, but if it does not make the code more complex there is no reason to.
In fact, I believe you should move all client-related code in a separate
function:
void client(AVIOContext *client)
{
avio_handshake(client);
...
}
if (pid == 0) {
avio_closep(&server);
exit(0);
}
That way, changing it into a thread (less isolation) or a separate program
(fork+exec, more isolation) becomes trivial.
This makes sharing the error reporting code less straightforward, but
sharing the error reporting is always awkward: sometimes you need context,
sometime you do not, some you need more than context, etc. IMHO, with the
simplistic error system in FFmpeg, it is best to put the error message at
the place of the error, even if that means more av_log() and more braces.
Unrelated: when you resend a full patch series, try to remember to annotate
the patches with a few words to say what changed since last version. The
lines between the first "---" and the first "diff --git" where Git puts
ASCII-art histograms are purely informational and can be used for that. You
can use "git send-email --annotate" to get an editor to edit them.
Personally, I always use --annotate because it gives me an extra chance to
re-read the patch series.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Subject: [PATCH] libavcodec/qsv.c: Linux-only code part has been moved to separate function in order to avoid the "ISO C90 forbids mixed declarations and code" compiler warning.
Hello All, Unfortunately, previous patch for libavcodec/qsv.c at the commit db89f45535aa3e99bceb5f6bf957c90e7ca39841 does initiate the compiler warning "ISO C90 forbids mixed declarations and code" under linux platform, because there is declaration block under preprocessor condition. Looks like it can not be re-arranged by graceful way into one function. I believe the best way to fix it is moving linux-related code into own separate function. Suggested patch does this. Please review. Thank. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-qsv.c-Linux-only-code-part-has-been-moved.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avcodec: loongson remove useless macros in mipsfpu optimization
On Fri, Jul 03, 2015 at 06:10:41PM +0800, 周晓勇 wrote: > From be9c7fd9b3ddcba9c122c933717f54437d2e1c8a Mon Sep 17 00:00:00 2001 > From: ZhouXiaoyong > Date: Fri, 3 Jul 2015 15:59:00 +0800 > Subject: [PATCH 1/4] avcodec: loongson remove useless macros in mipsfpu > optimization > > > Loongson has disabled all mipsfpu optimization as fate-test faild. > > > Signed-off-by: ZhouXiaoyong > --- > libavcodec/mips/aacsbr_mips.h | 4 ++-- > libavcodec/mips/iirfilter_mips.c | 4 > libavcodec/mips/mpegaudiodsp_mips_float.c | 6 -- > libavcodec/mips/sbrdsp_mips.c | 4 > 4 files changed, 2 insertions(+), 16 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
We had long disscussion last year for same thing, and i ended up in libavfilter movie, though i dont have any problem with this patch. We also used side data for same thing if u want u can look in that directions. my opinion would be to treat h264 caption in same way as it is treated in mpeg, mpeg and h264 cc need different processing, but can be kept in similar context. Sorry if this mails end up top posted, i am unable to confirm setting of this tool now. -Anshul -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/libdcadec: export matrix encoding side data
Signed-off-by: James Almer
---
libavcodec/libdcadec.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 890d270..9d4b9e8 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -41,6 +41,7 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
*data,
{
DCADecContext *s = avctx->priv_data;
AVFrame *frame = data;
+struct dcadec_exss_info *exss;
int ret, i, k;
int **samples, nsamples, channel_mask, sample_rate, bits_per_sample,
profile;
uint32_t mrk;
@@ -127,6 +128,26 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
*data,
} else
avctx->bit_rate = 0;
+if (exss = dcadec_context_get_exss_info(s->ctx)) {
+enum AVMatrixEncoding matrix_encoding;
+
+switch(exss->matrix_encoding) {
+case DCADEC_MATRIX_ENCODING_SURROUND:
+matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
+break;
+case DCADEC_MATRIX_ENCODING_HEADPHONE:
+matrix_encoding = AV_MATRIX_ENCODING_DOLBYHEADPHONE;
+break;
+default:
+matrix_encoding = AV_MATRIX_ENCODING_NONE;
+break;
+}
+dcadec_context_free_exss_info(exss);
+
+if ((ret = ff_side_data_update_matrix_encoding(frame,
matrix_encoding)) < 0)
+return ret;
+}
+
frame->nb_samples = nsamples;
if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
return ret;
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
Anshul gmail.com> writes: > We had long disscussion last year for same thing, > and i ended up in libavfilter movie, Do you mean a discussion about telling users about Closed Captions in video streams or a discussion about patches to implement decoding of Closed Captions? I am (currently) only interested in telling users about Closed Captions. > though i dont have any problem with this patch. Thank you! > my opinion would be to treat h264 caption in > same way as it is treated in mpeg, I believe it is treated identically. Did you have time to look at ticket #1482? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] concatdec: add support for specifying inpoint of files
On Mon, 6 Jul 2015, Nicolas George wrote: L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit : Signed-off-by: Marton Balint --- doc/demuxers.texi | 17 + libavformat/concatdec.c | 48 +++- 2 files changed, 52 insertions(+), 13 deletions(-) I like the feature, but I find the name of the directive, "in", too generic. Maybe "seek" is the best choice? I chose the "in" and "out" keywords because for intra frame (and exactly interleaved) content (where packet based cutting actually works without additional magic) it matches the semantics of inpoint and outpoint in an EDL list. I can change it if you still prefer seek. Also, the timestamp computation code is starting to be a bit complex. Maybe now is a good time to move file_start_time to the per-file structure. But I will not consider this blocking. Are you referring to file_start_time or file_inpoint? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add removegrain
On 2015-07-05 20:14, Paul B Mahol wrote: > + * TODO: add SIMD If you and nobody else is working assembly then I am volunteering (and have literally just started). signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] concatdec: add support for specifying outpoint of files
On Mon, 6 Jul 2015, Nicolas George wrote:
L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
doc/demuxers.texi | 13 +
libavformat/concatdec.c | 22 --
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 4bad1c8..4ba797e 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -129,6 +129,19 @@ directive) will be reduced based on their specified In
point.
Because of potential packets before the specified In point, packet timestamps
may overlap between two concatenated files.
+@item @code{out @var{timestamp}}
+Out point of the file. When the demuxer reaches the specified timestamp in any
+of the streams, it handles it as an end of file condition. Out point is
+exclusive, which means that the demuxer will not output packets which has a
+timestamp greater or equal to Out point.
+
+This directive works best with intra frame codecs, because for non-intra frame
+ones you will usually not get enough packets to decode the last few frames
+before the specified Out point.
+
+The duration of the files (if not specified by the @code{duration}
+directive) will be reduced based on their specified Out point.
+
@item @code{stream}
Introduce a stream in the virtual file.
All subsequent stream-related directives apply to the last introduced
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 11e6759..eaf34b0 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -44,6 +44,7 @@ typedef struct {
int64_t duration;
ConcatStream *streams;
int64_t inpoint;
+int64_t outpoint;
int nb_streams;
} ConcatFile;
@@ -145,6 +146,7 @@ static int add_file(AVFormatContext *avf, char *filename,
ConcatFile **rfile,
file->start_time = AV_NOPTS_VALUE;
file->duration = AV_NOPTS_VALUE;
file->inpoint= AV_NOPTS_VALUE;
+file->outpoint = AV_NOPTS_VALUE;
return 0;
@@ -360,7 +362,7 @@ static int concat_read_header(AVFormatContext *avf)
}
if ((ret = add_file(avf, filename, &file, &nb_files_alloc)) < 0)
goto fail;
-} else if (!strcmp(keyword, "duration") || !strcmp(keyword, "in")) {
+} else if (!strcmp(keyword, "duration") || !strcmp(keyword, "in") ||
!strcmp(keyword, "out")) {
char *dur_str = get_keyword(&cursor);
int64_t dur;
if (!file) {
@@ -377,6 +379,8 @@ static int concat_read_header(AVFormatContext *avf)
file->duration = dur;
else if (!strcmp(keyword, "in"))
file->inpoint = dur;
+else if (!strcmp(keyword, "out"))
+file->outpoint = dur;
} else if (!strcmp(keyword, "stream")) {
if (!avformat_new_stream(avf, NULL))
FAIL(AVERROR(ENOMEM));
@@ -443,6 +447,8 @@ static int open_next_file(AVFormatContext *avf)
cat->cur_file->duration = cat->avf->duration;
if (cat->cur_file->inpoint != AV_NOPTS_VALUE)
cat->cur_file->duration -= (cat->cur_file->inpoint -
file_start_time);
+if (cat->cur_file->outpoint != AV_NOPTS_VALUE)
+cat->cur_file->duration -= cat->avf->duration -
(cat->cur_file->outpoint - file_start_time);
}
if (++fileno >= cat->nb_files) {
@@ -504,6 +510,16 @@ static int64_t get_cur_file_inpoint(ConcatContext *cat)
return file_inpoint;
}
+/* Returns true if the packet pts is greater or equal to the specified
outpoint. */
+static int packet_after_outpoint(ConcatContext *cat, AVPacket *pkt)
+{
+if (cat->cur_file->outpoint != AV_NOPTS_VALUE && pkt->pts !=
AV_NOPTS_VALUE) {
+return av_compare_ts(pkt->pts,
cat->avf->streams[pkt->stream_index]->time_base,
+ cat->cur_file->outpoint, AV_TIME_BASE_Q) >= 0;
+}
+return 0;
+}
+
static int concat_read_packet(AVFormatContext *avf, AVPacket *pkt)
{
ConcatContext *cat = avf->priv_data;
@@ -520,7 +536,9 @@ static int concat_read_packet(AVFormatContext *avf,
AVPacket *pkt)
while (1) {
ret = av_read_frame(cat->avf, pkt);
-if (ret == AVERROR_EOF) {
+if (ret == AVERROR_EOF || packet_after_outpoint(cat, pkt)) {
+if (ret == 0)
+av_packet_unref(pkt);
This will not work if the streams in the file are not exactly interleaved.
Some formats store subtitles, and even audio, a few frames early, that will
trigger EOF even though there may be frames below the outpoint still coming.
Yeah, i know. Actually I don't see how would it be possible to give a
stronger kind of guarantee efficiently and reliably to the user. That is
why I sticked to the simplest-to-implement method. For the moment - if the
user will use this directive to cut parts in an interleaved video, he
should know his interleaving delays (and his GOP sizes :))
At least, the documentation should have a warning about it.
Okay, I
Re: [FFmpeg-devel] [PATCH] movtextdec.c: Add support for highlight and hilightcolor box
On Mon, Jul 06, 2015 at 10:27:47PM +0530, Niklesh Lalwani wrote:
> From: Niklesh
>
> Signed-off-by: Niklesh
> ---
> libavcodec/movtextdec.c | 254
> +---
> 1 file changed, 173 insertions(+), 81 deletions(-)
>
> diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
> index a3afd91..7e9e4f5 100644
> --- a/libavcodec/movtextdec.c
> +++ b/libavcodec/movtextdec.c
> @@ -31,37 +31,166 @@
> #define STYLE_FLAG_ITALIC (1<<1)
> #define STYLE_FLAG_UNDERLINE(1<<2)
>
> +#define STYL_BOX (1<<0)
> +#define HLIT_BOX (1<<1)
> +#define HCLR_BOX (1<<2)
> +
> typedef struct {
> uint16_t style_start;
> uint16_t style_end;
> uint8_t style_flag;
> } StyleBox;
>
> +typedef struct {
> +uint16_t hlit_start;
> +uint16_t hlit_end;
> +} HighlightBox;
> +
> +typedef struct {
> + uint8_t hlit_color[4];
> +} HilightcolorBox;
> +
> +typedef struct {
> +StyleBox **s;
> +StyleBox *s_temp;
> +HighlightBox h;
> +HilightcolorBox c;
> +uint8_t box_flags;
> +uint16_t style_entries;
> +uint64_t tracksize;
> +int size_var;
> +int count_s;
> +} MovTextContext;
> +
> +struct Box
> +{
style
> +uint32_t type;
> +size_t base_size;
> +int (*decode)(const uint8_t *tsmb, MovTextContext *m, AVPacket *avpkt);
> +};
> +
> +static void mov_text_cleanup(MovTextContext *m)
> +{
> +int i;
> +if (m->box_flags & STYL_BOX) {
> +for(i = 0; i < m->count_s; i++) {
> +av_freep(&m->s[i]);
> +}
> +av_freep(&m->s);
> +}
> +}
> +
> +static int decode_hlit(const uint8_t *tsmb, MovTextContext *m, AVPacket
> *avpkt)
> +{
> +m->box_flags |= HLIT_BOX;
> +m->h.hlit_start = AV_RB16(tsmb);
> +tsmb += 2;
> +m->h.hlit_end = AV_RB16(tsmb);
> +tsmb += 2;
> +return 0;
> +}
> +
> +static int decode_hclr(const uint8_t *tsmb, MovTextContext *m, AVPacket
> *avpkt)
> +{
> +m->box_flags |= HCLR_BOX;
> +m->c.hlit_color[0] = *tsmb++;
> +m->c.hlit_color[1] = *tsmb++;
> +m->c.hlit_color[2] = *tsmb++;
> +m->c.hlit_color[3] = *tsmb++;
you can use memcpy here it seems
> +return 0;
> +}
> +
> +static int decode_styl(const uint8_t *tsmb, MovTextContext *m, AVPacket
> *avpkt)
> +{
> +int i;
> +m->style_entries = AV_RB16(tsmb);
> +tsmb += 2;
> +// A single style record is of length 12 bytes.
> +if (m->tracksize + m->size_var + 2 + m->style_entries * 12 > avpkt->size)
> +return -1;
> +
> +m->box_flags |= STYL_BOX;
> +for(i = 0; i < m->style_entries; i++) {
> +m->s_temp = av_malloc(sizeof(StyleBox));
sizeof(*m->s_temp)
> +if (!m->s_temp) {
> +mov_text_cleanup(m);
> +return AVERROR(ENOMEM);
> +}
> +m->s_temp->style_start = AV_RB16(tsmb);
> +tsmb += 2;
> +m->s_temp->style_end = AV_RB16(tsmb);
> +tsmb += 2;
> +// fontID = AV_RB16(tsmb);
> +tsmb += 2;
> +m->s_temp->style_flag = AV_RB8(tsmb);
> +av_dynarray_add(&m->s, &m->count_s, m->s_temp);
> +if(!m->s) {
> +mov_text_cleanup(m);
> +return AVERROR(ENOMEM);
> +}
> +// fontsize = AV_RB8(tsmb);
> +tsmb += 2;
> +// text-color-rgba
> +tsmb += 4;
> +}
> +return 0;
> +}
> +
> +struct Box box_types[] = {
static const
> +{ MKBETAG('s','t','y','l'), 2, decode_styl },
> +{ MKBETAG('h','l','i','t'), 4, decode_hlit },
> +{ MKBETAG('h','c','l','r'), 4, decode_hclr }
> +};
> +
> +const static size_t box_count = sizeof(box_types) / sizeof(struct Box);
use FF_ARRAY_ELEMS() in the only place it's used instead
> +
> static int text_to_ass(AVBPrint *buf, const char *text, const char *text_end,
> -StyleBox **s, int style_entries)
> +MovTextContext *m)
nit: vertical align
> {
> int i = 0;
> int text_pos = 0;
> while (text < text_end) {
> -for (i = 0; i < style_entries; i++) {
> -if (s[i]->style_flag && text_pos == s[i]->style_end) {
> -if (s[i]->style_flag & STYLE_FLAG_BOLD)
> -av_bprintf(buf, "{\\b0}");
> -if (s[i]->style_flag & STYLE_FLAG_ITALIC)
> -av_bprintf(buf, "{\\i0}");
> -if (s[i]->style_flag & STYLE_FLAG_UNDERLINE)
> -av_bprintf(buf, "{\\u0}");
> +if (m->box_flags & STYL_BOX) {
> +for (i = 0; i < m->style_entries; i++) {
> +if (m->s[i]->style_flag && text_pos == m->s[i]->style_end) {
> +if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
> +av_bprintf(buf, "{\\b0}");
> +if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
> +av_bprintf(buf, "{\\i0}");
> +if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
> +av_bprintf(buf, "{\\u0}");
Re: [FFmpeg-devel] [PATCH] avcodec/libdcadec: export matrix encoding side data
On Mon, Jul 6, 2015 at 10:25 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/libdcadec.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
> index 890d270..9d4b9e8 100644
> --- a/libavcodec/libdcadec.c
> +++ b/libavcodec/libdcadec.c
> @@ -41,6 +41,7 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
> *data,
> {
> DCADecContext *s = avctx->priv_data;
> AVFrame *frame = data;
> +struct dcadec_exss_info *exss;
> int ret, i, k;
> int **samples, nsamples, channel_mask, sample_rate, bits_per_sample,
> profile;
> uint32_t mrk;
> @@ -127,6 +128,26 @@ static int dcadec_decode_frame(AVCodecContext *avctx,
> void *data,
> } else
> avctx->bit_rate = 0;
>
> +if (exss = dcadec_context_get_exss_info(s->ctx)) {
> +enum AVMatrixEncoding matrix_encoding;
> +
> +switch(exss->matrix_encoding) {
> +case DCADEC_MATRIX_ENCODING_SURROUND:
> +matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
> +break;
> +case DCADEC_MATRIX_ENCODING_HEADPHONE:
> +matrix_encoding = AV_MATRIX_ENCODING_DOLBYHEADPHONE;
> +break;
> +default:
> +matrix_encoding = AV_MATRIX_ENCODING_NONE;
> +break;
> +}
I think Dolby would disagree. ;)
Maybe we should just not set anything when the expected value is NONE?
Not that it really matters. but sending an "empty" value all the time
may not be required?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
On Mon, Jul 6, 2015 at 6:32 PM, Carl Eugen Hoyos wrote: > On Monday 06 July 2015 06:18:14 pm Carl Eugen Hoyos wrote: >> Hendrik Leppkes gmail.com> writes: >> > > Attached patch adds "Closed Captions" to the codec >> > > dump if the video stream contains them. >> > >> > Adding fields to a public context which should never >> > be accessed by the public is a big no-no. >> >> What is the alternative? > > As in attached? > If anything it should use the automatic accessor macros, but I still find it a silly solution. Any API user could just check the side data of the frames to know if CCs are available, AVCodecContext doesn't need to track that. Its an old problem, you're trying to solve a ffmpeg.c problem by hacking around in avcodec, which is IMHO not a good idea. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add removegrain
Dana 6. 7. 2015. 23:29 osoba "James Darnley" napisala je: > > On 2015-07-05 20:14, Paul B Mahol wrote: > > + * TODO: add SIMD > > If you and nobody else is working assembly then I am volunteering (and > have literally just started). The original, from VapourSynth. src/filters/removegrain have afaik intrinsic assembly. Thanks for working on this. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Tell users about Closed Captions in video streams
Hendrik Leppkes gmail.com> writes: > On Mon, Jul 6, 2015 at 6:32 PM, Carl Eugen Hoyos wrote: > > On Monday 06 July 2015 06:18:14 pm Carl Eugen Hoyos wrote: > >> Hendrik Leppkes gmail.com> writes: > >> > > Attached patch adds "Closed Captions" to the codec > >> > > dump if the video stream contains them. > >> > > >> > Adding fields to a public context which should never > >> > be accessed by the public is a big no-no. > >> > >> What is the alternative? > > > > As in attached? > > If anything it should use the automatic accessor macros, I don't think that works, no setter is needed. > but I still find it a silly solution. Then please suggest another solution. > Any API user could just check the side data of > the frames to know if CCs are available, > AVCodecContext doesn't need to track that. This sounds as if it would be a significantly higher amount of work than to check the getter function. > Its an old problem, you're trying to solve a > ffmpeg.c problem by hacking around in avcodec, > which is IMHO not a good idea. I am trying to help users. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Make jp2 output Kakadu-compatible
Michael Niedermayer gmx.at> writes: > > Attached patch makes the output of > > ffmpeg -i lena.pnm -strict -2 out.jp2 > > compatible with Kakadu, fixes ticket #4689. > > > > Please comment, Carl Eugen > > > j2kenc.c |1 + > > 1 file changed, 1 insertion(+) > > 7fe04b2a6ae6fc046144cc6d4879b1f249e0ef7d patchftyp.diff > > needs fate update > LGTM The patch was merged with a fate update. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] concatdec: add support for injecting packet metadata
On Mon, 6 Jul 2015, Nicolas George wrote:
L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit :
Signed-off-by: Marton Balint
---
doc/demuxers.texi | 4
libavformat/concatdec.c | 30 ++
2 files changed, 34 insertions(+)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 4ba797e..28244f3 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -142,6 +142,10 @@ before the specified Out point.
The duration of the files (if not specified by the @code{duration}
directive) will be reduced based on their specified Out point.
+@item @code{metadata @var{string}}
+Metadata of the file. The specified metadata (which consists of
+@code{key=value} pairs seperated by commas) will be set for each file packet.
This looks like a step into escaping hell.
metadata foo=bar,baz=qux
metadata foo=bar
metadata baz=qux
Would the second form be ok for you?
Ok.
+
@item @code{stream}
Introduce a stream in the virtual file.
All subsequent stream-related directives apply to the last introduced
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index eaf34b0..66e81c8 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -45,6 +45,8 @@ typedef struct {
ConcatStream *streams;
int64_t inpoint;
int64_t outpoint;
+char *metadata;
+int metadata_len;
int nb_streams;
} ConcatFile;
@@ -329,6 +331,7 @@ static int concat_read_close(AVFormatContext *avf)
avformat_close_input(&cat->avf);
for (i = 0; i < cat->nb_files; i++) {
av_freep(&cat->files[i].url);
+av_freep(&cat->files[i].metadata);
av_freep(&cat->files[i].streams);
}
av_freep(&cat->files);
@@ -381,6 +384,27 @@ static int concat_read_header(AVFormatContext *avf)
file->inpoint = dur;
else if (!strcmp(keyword, "out"))
file->outpoint = dur;
+} else if (!strcmp(keyword, "metadata")) {
+AVDictionary *opts = NULL;
+char *metadata;
+if (file->metadata) {
+av_log(avf, AV_LOG_ERROR, "Line %d: metadata is already
provided\n", line);
+FAIL(AVERROR_INVALIDDATA);
+}
+metadata = av_get_token((const char **)&cursor, SPACE_CHARS);
+if (!metadata) {
+av_log(avf, AV_LOG_ERROR, "Line %d: metadata required\n",
line);
+FAIL(AVERROR_INVALIDDATA);
+}
+if ((ret = av_dict_parse_string(&opts, metadata, "=", ",", 0)) <
0) {
+av_log(avf, AV_LOG_ERROR, "Line %d: failed to parse metadata
string\n", line);
+av_freep(&metadata);
+av_dict_free(&opts);
+FAIL(AVERROR_INVALIDDATA);
+}
+file->metadata = av_packet_pack_dictionary(opts,
&file->metadata_len);
+av_freep(&metadata);
+av_dict_free(&opts);
} else if (!strcmp(keyword, "stream")) {
if (!avformat_new_stream(avf, NULL))
FAIL(AVERROR(ENOMEM));
@@ -576,6 +600,12 @@ static int concat_read_packet(AVFormatContext *avf,
AVPacket *pkt)
av_log(avf, AV_LOG_DEBUG, " -> pts:%s pts_time:%s dts:%s dts_time:%s\n",
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base));
+if (cat->cur_file->metadata) {
+uint8_t* metadata;
+if (!(metadata = av_packet_new_side_data(pkt, AV_PKT_DATA_STRINGS_METADATA,
cat->cur_file->metadata_len)))
+return AVERROR(ENOMEM);
+memcpy(metadata, cat->cur_file->metadata, cat->cur_file->metadata_len);
+}
return ret;
}
No other objection, but can you explain the use case? Packet metadata is not
very common.
Actually I have one more patch I have not yet sent to the list, which adds
support to select frames by metadata to the select filters.
With that, you can cut frame accurately from XDCAM HD files if you
overshoot outpoint a bit and store the useful timecodes in the packet
metadata:
ffconcat version 1.0
file 'XDCAMHD.mxf'
in 01:04.00
out 01:05.12
metadata select.from=0
metadata select.until=0.96
duration 1
file 'XDCAMHD.mxf'
in 01:06.00
out 01:07.12
duration 1
metadata select.from=1
metadata select.until=1.96
./ffmpeg -copyts -vsync 0 -i test.concat
-vf "select='between(t,meta(0),meta(1)):meta_keys=select.from|select.until'"
-af "aselect='between(t,meta(0),meta(1)):meta_keys=select.from|select.until'"
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Add some docs for j2k encoding and remove experimental (instead of: Change the default j2k prediction to 5/3)
Michael Niedermayer gmx.at> writes: > > So instead I suggest the attached documentation > > update and the removal of the experimental flag. > > the docs change LGTM The documentation update was merged. I will probably send a patch for removal of strict soon. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Silence a warning when decoding hap
Michael Niedermayer gmx.at> writes: > > hapdec.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > 126826ea8c86d05606122d00f4f8d633829f94f9 patchhap.diff > > probably the call can be removed entirely but this > is strictly taken safer > LGTM The patch was merged. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libdcadec: export matrix encoding side data
On 06/07/15 7:02 PM, Hendrik Leppkes wrote:
> On Mon, Jul 6, 2015 at 10:25 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libdcadec.c | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
>> index 890d270..9d4b9e8 100644
>> --- a/libavcodec/libdcadec.c
>> +++ b/libavcodec/libdcadec.c
>> @@ -41,6 +41,7 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
>> *data,
>> {
>> DCADecContext *s = avctx->priv_data;
>> AVFrame *frame = data;
>> +struct dcadec_exss_info *exss;
>> int ret, i, k;
>> int **samples, nsamples, channel_mask, sample_rate, bits_per_sample,
>> profile;
>> uint32_t mrk;
>> @@ -127,6 +128,26 @@ static int dcadec_decode_frame(AVCodecContext *avctx,
>> void *data,
>> } else
>> avctx->bit_rate = 0;
>>
>> +if (exss = dcadec_context_get_exss_info(s->ctx)) {
>> +enum AVMatrixEncoding matrix_encoding;
>> +
>> +switch(exss->matrix_encoding) {
>> +case DCADEC_MATRIX_ENCODING_SURROUND:
>> +matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
>> +break;
>> +case DCADEC_MATRIX_ENCODING_HEADPHONE:
>> +matrix_encoding = AV_MATRIX_ENCODING_DOLBYHEADPHONE;
>> +break;
>> +default:
>> +matrix_encoding = AV_MATRIX_ENCODING_NONE;
>> +break;
>> +}
>
> I think Dolby would disagree. ;)
The native dca decoder sets AV_MATRIX_ENCODING_DOLBY for the same type of
frames this
would, stating they are the equivalent. So does mlpdec.
>
> Maybe we should just not set anything when the expected value is NONE?
> Not that it really matters. but sending an "empty" value all the time
> may not be required?
I'm replicating the native dca decoder behavior with this. If you for example
use the
ashowinfo filter, it will output "side data - matrix encoding: none".
Not setting anything in that case would save us a
ff_side_data_update_matrix_encoding
call per frame, though, so i guess I'll do just that.
Both encodings are apparently guaranteed to be set only with stereo streams, so
maybe
i should also check for channel amount and skip the entire branch? 99% of
streams out
there are multichannel after all.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add removegrain
On 2015-07-05 20:14, Paul B Mahol wrote:
> +static int mode01(int c, int a1, int a2, int a3, int a4, int a5, int a6, int
> a7, int a8)
> +{
> +const int mi = FFMIN(FFMIN(FFMIN(a1, a2), FFMIN(a3, a4)),
> FFMIN(FFMIN(a5, a6), FFMIN(a7, a8)));
> +const int ma = FFMAX(FFMAX(FFMAX(a1, a2), FFMAX(a3, a4)),
> FFMAX(FFMIN(a5, a6), FFMAX(a7, a8)));
> ^
Is this a typo here? I would have expected all that second line to be
FFMAXes but this is an FFMIN.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add removegrain
On 05/07/15 3:14 PM, Paul B Mahol wrote:
> +static int mode06(int c, int a1, int a2, int a3, int a4, int a5, int a6, int
> a7, int a8)
> +{
> +REMOVE_GRAIN_SORT_AXIS
> +
> +const int d1 = ma1 - mi1;
> +const int d2 = ma2 - mi2;
> +const int d3 = ma3 - mi3;
> +const int d4 = ma4 - mi4;
> +
> +const int cli1 = av_clip(c, mi1, ma1);
> +const int cli2 = av_clip(c, mi2, ma2);
> +const int cli3 = av_clip(c, mi3, ma3);
> +const int cli4 = av_clip(c, mi4, ma4);
> +
> +const int c1 = av_clip((FFABS(c - cli1) << 1) + d1, 0, 0xFF);
> +const int c2 = av_clip((FFABS(c - cli2) << 1) + d2, 0, 0xFF);
> +const int c3 = av_clip((FFABS(c - cli3) << 1) + d3, 0, 0xFF);
> +const int c4 = av_clip((FFABS(c - cli4) << 1) + d4, 0, 0xFF);
av_clip_uint8
[...]
> +static int mode08(int c, int a1, int a2, int a3, int a4, int a5, int a6, int
> a7, int a8)
> +{
> +REMOVE_GRAIN_SORT_AXIS
> +
> +const int d1 = ma1 - mi1;
> +const int d2 = ma2 - mi2;
> +const int d3 = ma3 - mi3;
> +const int d4 = ma4 - mi4;
> +
> +const int cli1 = av_clip(c, mi1, ma1);
> +const int cli2 = av_clip(c, mi2, ma2);
> +const int cli3 = av_clip(c, mi3, ma3);
> +const int cli4 = av_clip(c, mi4, ma4);
> +
> +const int c1 = av_clip(FFABS(c - cli1) + (d1 << 1), 0, 0x);
> +const int c2 = av_clip(FFABS(c - cli2) + (d2 << 1), 0, 0x);
> +const int c3 = av_clip(FFABS(c - cli3) + (d3 << 1), 0, 0x);
> +const int c4 = av_clip(FFABS(c - cli4) + (d4 << 1), 0, 0x);
av_clip_uint16
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] concatdec: store eof condition in context
On Mon, Jul 06, 2015 at 07:26:11PM +0200, Nicolas George wrote: > L'octidi 18 messidor, an CCXXIII, Marton Balint a écrit : > > This is needed later for outpoint support which may leave the last file in a > > not-eof state. > > > > Signed-off-by: Marton Balint > > --- > > libavformat/concatdec.c | 9 - > > 1 file changed, 8 insertions(+), 1 deletion(-) > > Ok. i cant apply without the previous patch Marton, nicolas please make sure once you both are happy with the code it also gets applied, aka send pull req or ping or push or whatever, dont just assume i wont forget ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] use mmi instead of loongson3 as simd-optimization flag
On Fri, Jul 03, 2015 at 06:11:27PM +0800, 周晓勇 wrote: > From 0b953ff84cce87c2b988852aa59c899e2fa23309 Mon Sep 17 00:00:00 2001 > From: ZhouXiaoyong > Date: Fri, 3 Jul 2015 16:27:48 +0800 > Subject: [PATCH 2/4] use mmi instead of loongson3 as simd-optimization flag applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] configure: add loongson2 cpu support
On Fri, Jul 03, 2015 at 06:12:07PM +0800, 周晓勇 wrote: > From c6c4faaab7c598ce0fb6f7a4afab825f7a86 Mon Sep 17 00:00:00 2001 > From: ZhouXiaoyong > Date: Fri, 3 Jul 2015 16:44:12 +0800 > Subject: [PATCH 3/4] configure: add loongson2 cpu support applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add removegrain
Dana 7. 7. 2015. 01:36 osoba "James Darnley"
napisala je:
>
> On 2015-07-05 20:14, Paul B Mahol wrote:
> > +static int mode01(int c, int a1, int a2, int a3, int a4, int a5, int
a6, int a7, int a8)
> > +{
> > +const int mi = FFMIN(FFMIN(FFMIN(a1, a2), FFMIN(a3, a4)),
FFMIN(FFMIN(a5, a6), FFMIN(a7, a8)));
> > +const int ma = FFMAX(FFMAX(FFMAX(a1, a2), FFMAX(a3, a4)),
FFMAX(FFMIN(a5, a6), FFMAX(a7, a8)));
> >
^
>
> Is this a typo here? I would have expected all that second line to be
> FFMAXes but this is an FFMIN.
>
>
Yes, you are right. Thanks for spotting it.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Add some docs for j2k encoding and remove experimental (instead of: Change the default j2k prediction to 5/3)
Dana 7. 7. 2015. 00:25 osoba "Carl Eugen Hoyos" napisala je: > > Michael Niedermayer gmx.at> writes: > > > > So instead I suggest the attached documentation > > > update and the removal of the experimental flag. > > > > the docs change LGTM > > The documentation update was merged. > > I will probably send a patch for removal > of strict soon. > Why? It uses big memory for first real word sample. > Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/libdcadec: export matrix encoding side data
Signed-off-by: James Almer
---
libavcodec/libdcadec.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 890d270..4bc3765 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -41,6 +41,7 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
*data,
{
DCADecContext *s = avctx->priv_data;
AVFrame *frame = data;
+struct dcadec_exss_info *exss;
int ret, i, k;
int **samples, nsamples, channel_mask, sample_rate, bits_per_sample,
profile;
uint32_t mrk;
@@ -127,6 +128,24 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
*data,
} else
avctx->bit_rate = 0;
+if (exss = dcadec_context_get_exss_info(s->ctx)) {
+enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
+
+switch(exss->matrix_encoding) {
+case DCADEC_MATRIX_ENCODING_SURROUND:
+matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
+break;
+case DCADEC_MATRIX_ENCODING_HEADPHONE:
+matrix_encoding = AV_MATRIX_ENCODING_DOLBYHEADPHONE;
+break;
+}
+dcadec_context_free_exss_info(exss);
+
+if (matrix_encoding != AV_MATRIX_ENCODING_NONE &&
+(ret = ff_side_data_update_matrix_encoding(frame,
matrix_encoding)) < 0)
+return ret;
+}
+
frame->nb_samples = nsamples;
if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
return ret;
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodev/libdcadec: implement request_channel_layout
Signed-off-by: James Almer
---
libavcodec/libdcadec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 4bc3765..796826e 100644
--- a/libavcodec/libdcadec.c
+++ b/libavcodec/libdcadec.c
@@ -36,6 +36,8 @@ typedef struct DCADecContext {
int buffer_size;
} DCADecContext;
+static int downmix_warned = 0;
+
static int dcadec_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame_ptr, AVPacket *avpkt)
{
@@ -131,6 +133,17 @@ static int dcadec_decode_frame(AVCodecContext *avctx, void
*data,
if (exss = dcadec_context_get_exss_info(s->ctx)) {
enum AVMatrixEncoding matrix_encoding = AV_MATRIX_ENCODING_NONE;
+if (!downmix_warned) {
+uint64_t layout = avctx->request_channel_layout;
+
+if (((layout == AV_CH_LAYOUT_STEREO_DOWNMIX || layout ==
AV_CH_LAYOUT_STEREO) && !exss->embedded_stereo) ||
+( layout == AV_CH_LAYOUT_5POINT1 && !exss->embedded_6ch))
+av_log(avctx, AV_LOG_WARNING, "%s downmix was requested but no
custom coefficients are available, "
+ "this may result in clipping\n",
+ layout == AV_CH_LAYOUT_5POINT1 ?
"5.1" : "stereo");
+downmix_warned = 1;
+}
+
switch(exss->matrix_encoding) {
case DCADEC_MATRIX_ENCODING_SURROUND:
matrix_encoding = AV_MATRIX_ENCODING_DOLBY;
@@ -195,6 +208,27 @@ static av_cold int dcadec_init(AVCodecContext *avctx)
if (avctx->flags & CODEC_FLAG_BITEXACT)
flags |= DCADEC_FLAG_CORE_BIT_EXACT;
+if (avctx->request_channel_layout > 0 && avctx->request_channel_layout !=
AV_CH_LAYOUT_NATIVE) {
+switch (avctx->request_channel_layout) {
+case AV_CH_LAYOUT_STEREO:
+case AV_CH_LAYOUT_STEREO_DOWNMIX:
+/* libdcadec ignores the 2ch flag if used alone when no custom
downmix coefficients
+ are available, silently outputting a 5.1 downmix if possible
instead.
+ Using both the 2ch and 6ch flags together forces a 2ch downmix
using default
+ coefficients in such cases. This matches the behavior of the
6ch flag when used
+ alone, where a 5.1 downmix is generated if possible, regardless
of custom
+ coefficients being available or not. */
+flags |= DCADEC_FLAG_KEEP_DMIX_2CH | DCADEC_FLAG_KEEP_DMIX_6CH;
+break;
+case AV_CH_LAYOUT_5POINT1:
+flags |= DCADEC_FLAG_KEEP_DMIX_6CH;
+break;
+default:
+av_log(avctx, AV_LOG_WARNING, "Invalid request_channel_layout\n");
+break;
+}
+}
+
s->ctx = dcadec_context_create(flags);
if (!s->ctx)
return AVERROR(ENOMEM);
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
