[FFmpeg-devel] [RFC]Fix flac with high lpc precision
Hi!
Attached is my attempt to fix ticket #4421 based on the
analysis by trac user lvqcl. If the patch is ok, I will
add the encoder check to the decoder and the version
bump.
Please review, Carl Eugen
TODO: Fix indentation in libavcodec/x86/flacdsp_init.c()
diff --git a/libavcodec/arm/flacdsp_init_arm.c
b/libavcodec/arm/flacdsp_init_arm.c
index 82a807f..564e3dc 100644
--- a/libavcodec/arm/flacdsp_init_arm.c
+++ b/libavcodec/arm/flacdsp_init_arm.c
@@ -27,6 +27,6 @@ void ff_flac_lpc_16_arm(int32_t *samples, const int
coeffs[32], int order,
av_cold void ff_flacdsp_init_arm(FLACDSPContext *c, enum AVSampleFormat fmt,
int channels,
int bps)
{
-if (CONFIG_FLAC_DECODER && bps <= 16)
-c->lpc = ff_flac_lpc_16_arm;
+if (CONFIG_FLAC_DECODER)
+c->lpc16 = ff_flac_lpc_16_arm;
}
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 34a0a70..bfedb6d 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -338,7 +338,11 @@ static int decode_subframe_lpc(FLACContext *s, int32_t
*decoded, int pred_order,
if ((ret = decode_residuals(s, decoded, pred_order)) < 0)
return ret;
-s->dsp.lpc(decoded, coeffs, pred_order, qlevel, s->blocksize);
+if (bps <= 16 && bps + coeff_prec + av_log2(pred_order) <= 32) {
+s->dsp.lpc16(decoded, coeffs, pred_order, qlevel, s->blocksize);
+} else {
+s->dsp.lpc32(decoded, coeffs, pred_order, qlevel, s->blocksize);
+}
return 0;
}
diff --git a/libavcodec/flacdsp.c b/libavcodec/flacdsp.c
index a83eb83..30b6648 100644
--- a/libavcodec/flacdsp.c
+++ b/libavcodec/flacdsp.c
@@ -88,13 +88,10 @@ static void flac_lpc_32_c(int32_t *decoded, const int
coeffs[32],
av_cold void ff_flacdsp_init(FLACDSPContext *c, enum AVSampleFormat fmt, int
channels,
int bps)
{
-if (bps > 16) {
-c->lpc= flac_lpc_32_c;
-c->lpc_encode = flac_lpc_encode_c_32;
-} else {
-c->lpc= flac_lpc_16_c;
-c->lpc_encode = flac_lpc_encode_c_16;
-}
+c->lpc16= flac_lpc_16_c;
+c->lpc32= flac_lpc_32_c;
+c->lpc16_encode = flac_lpc_encode_c_16;
+c->lpc32_encode = flac_lpc_encode_c_32;
switch (fmt) {
case AV_SAMPLE_FMT_S32:
diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
index 417381c..f5cbd94 100644
--- a/libavcodec/flacdsp.h
+++ b/libavcodec/flacdsp.h
@@ -25,10 +25,14 @@
typedef struct FLACDSPContext {
void (*decorrelate[4])(uint8_t **out, int32_t **in, int channels,
int len, int shift);
-void (*lpc)(int32_t *samples, const int coeffs[32], int order,
-int qlevel, int len);
-void (*lpc_encode)(int32_t *res, const int32_t *smp, int len, int order,
- const int32_t coefs[32], int shift);
+void (*lpc16)(int32_t *samples, const int coeffs[32], int order,
+ int qlevel, int len);
+void (*lpc32)(int32_t *samples, const int coeffs[32], int order,
+ int qlevel, int len);
+void (*lpc16_encode)(int32_t *res, const int32_t *smp, int len, int order,
+ const int32_t coefs[32], int shift);
+void (*lpc32_encode)(int32_t *res, const int32_t *smp, int len, int order,
+ const int32_t coefs[32], int shift);
} FLACDSPContext;
void ff_flacdsp_init(FLACDSPContext *c, enum AVSampleFormat fmt, int channels,
int bps);
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index bc6d00a..b6dc4d5 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -838,8 +838,13 @@ static int encode_residual_ch(FlacEncodeContext *s, int ch)
order = av_clip(order, min_order - 1, max_order - 1);
if (order == last_order)
continue;
-s->flac_dsp.lpc_encode(res, smp, n, order+1, coefs[order],
- shift[order]);
+if (s->bps_code * 4 + s->options.lpc_coeff_precision +
av_log2(order) <= 32) {
+s->flac_dsp.lpc16_encode(res, smp, n, order+1, coefs[order],
+ shift[order]);
+} else {
+s->flac_dsp.lpc32_encode(res, smp, n, order+1, coefs[order],
+ shift[order]);
+}
bits[i] = find_subframe_rice_params(s, sub, order+1);
if (bits[i] < bits[opt_index]) {
opt_index = i;
@@ -853,7 +858,11 @@ static int encode_residual_ch(FlacEncodeContext *s, int ch)
opt_order = 0;
bits[0] = UINT32_MAX;
for (i = min_order-1; i < max_order; i++) {
-s->flac_dsp.lpc_encode(res, smp, n, i+1, coefs[i], shift[i]);
+if (s->bps_code * 4 + s->options.lpc_coeff_precision + av_log2(i)
<= 32) {
+s->flac_dsp.lpc16_encode(res, smp, n, i+1, coefs[i], shift[i]);
+} else {
+s->flac_dsp.
[FFmpeg-devel] [PATCH] avcodec/libx265: use x265 Multi-library Interface to query the API
>From 24fc78ebee006693f235ea2fd07994f7829b367e Mon Sep 17 00:00:00 2001
From: Gopu Govindaswamy
Date: Wed, 6 May 2015 12:47:21 +0530
Subject: [PATCH] avcodec/libx265: use x265 Multi-library Interface to query
the API
ffmpeg can now use the x265 multi-library interface to make a runtime
selection between a number of libx265 libraries (perhaps 8bpp and 16bpp).
ffmpeg will link to one build of libx265 (statically or
dynamically) and this linked version of libx265 will support one
bit-depth (8 or 10 bits). At runtime, ffmpeg now has the option to request
the
encoder to use a different bit depth(8 or 10). If the requested bitdepth
is zero, or if it matches the bitdepth of the system default libx265 (the
currently linked library), then this library will be used for encode.
If ffmpeg requests a different bit-depth, the linked libx265 will attempt
to dynamically bind a shared library with the requested bit-depth from the
install
location (default or user-specified).
new x265 API:
const x265_api* api = x265_api_get(int bitDepth);
x265_api - holds the libx265 public API functions
bitDepth - requested API for 8bpp or 16bpp
note: Use 0 to indicate native bit depth of the linked libx265 and
x265_api_get(0) is guaranteed to return a non-null pointer
---
configure| 4 ++--
libavcodec/libx265.c | 32 +---
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/configure b/configure
index d3f23c8..7c5d13a 100755
--- a/configure
+++ b/configure
@@ -5111,8 +5111,8 @@ enabled libx264 && { use_pkg_config x264
"stdint.h x264.h" x264_encode
{ check_cpp_condition x264.h "X264_BUILD >=
118" ||
die "ERROR: libx264 must be installed and
version must be >= 0.118."; }
enabled libx265 && require_pkg_config x265 x265.h
x265_encoder_encode &&
- { check_cpp_condition x265.h "X265_BUILD >=
17" ||
- die "ERROR: libx265 version must be >=
17."; }
+ { check_cpp_condition x265.h "X265_BUILD >=
56" ||
+ die "ERROR: libx265 version must be >=
56."; }
enabled libxavs && require libxavs xavs.h xavs_encoder_encode
-lxavs
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzmq&& require_pkg_config libzmq zmq.h zmq_ctx_new
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 8924657..c055c76 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -39,6 +39,7 @@ typedef struct libx265Context {
x265_encoder *encoder;
x265_param *params;
+const x265_api *api;
float crf;
char *preset;
@@ -67,10 +68,10 @@ static av_cold int libx265_encode_close(AVCodecContext
*avctx)
av_frame_free(&avctx->coded_frame);
-x265_param_free(ctx->params);
+ctx->api->param_free(ctx->params);
if (ctx->encoder)
-x265_encoder_close(ctx->encoder);
+ctx->api->encoder_close(ctx->encoder);
return 0;
}
@@ -79,6 +80,15 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
{
libx265Context *ctx = avctx->priv_data;
+ctx->api =
x265_api_get(av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth_minus1 + 1);
+if (!ctx->api)
+ctx->api = x265_api_get(0);
+
+if (!ctx->api) {
+av_log(avctx, AV_LOG_ERROR, "Could not get x265 API.\n");
+return AVERROR_EXTERNAL;
+}
+
if (avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL &&
!av_pix_fmt_desc_get(avctx->pix_fmt)->log2_chroma_w) {
av_log(avctx, AV_LOG_ERROR,
@@ -93,13 +103,13 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
return AVERROR(ENOMEM);
}
-ctx->params = x265_param_alloc();
+ctx->params = ctx->api->param_alloc();
if (!ctx->params) {
av_log(avctx, AV_LOG_ERROR, "Could not allocate x265 param
structure.\n");
return AVERROR(ENOMEM);
}
-if (x265_param_default_preset(ctx->params, ctx->preset, ctx->tune) <
0) {
+if (ctx->api->param_default_preset(ctx->params, ctx->preset,
ctx->tune) < 0) {
int i;
av_log(avctx, AV_LOG_ERROR, "Error setting preset/tune %s/%s.\n",
ctx->preset, ctx->tune);
@@ -148,7 +158,7 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
avctx->sample_aspect_ratio.num,
avctx->sample_aspect_ratio.den, 65535);
snprintf(sar, sizeof(sar), "%d:%d", sar_num, sar_den);
-if (x265_param_parse(ctx->params, "sar", sar) ==
X265_PARAM_BAD_VALUE) {
+if (ctx->api->param_parse(ctx->params, "sar", sar) ==
X265_PARAM_BAD_VALUE) {
av_log(avctx, AV_LOG_ERROR, "Invalid SAR: %d:%d.\n", sar_num,
sar_den);
return AVERROR_INVALIDDATA;
}
@@ -173,7 +183,7 @@ static av_cold int libx265_encode_init(AVCodecContext
*avctx)
char crf[6];
[FFmpeg-devel] Exact screen size not working: Re: [PATCH] Fix segfault with x11grab when switching windows.
@ffmpeg-devel@ffmpeg.org tldr; Using exact screen size doesn't work but less one pixel does. I'm new to ffmpeg but I see a recent message below and wonder there is an error now. The ffmpeg I built from source only yesterday. On a 1366x768 screen this below, sees the error suggested: ffmpeg -f x11grab -r 30 -s 1366x768 -i :0.0 -vcodec libx264 -preset ultrafast -crf 0 -y output.mkv [x11grab @ 0xa578ae0] Capture area 1366x768 at position 0.0 outside the screen size 1366x768 :0.0: Invalid argument This with one pixel size down, works fine: ffmpeg -f x11grab -r 30 -s 1365x767 -i :0.0 -vcodec libx264 -preset ultrafast -crf 0 -y output.mkv Regards davidpbrown == Re: [FFmpeg-devel] [PATCH] Fix segfault with x11grab when switching windows. Matthew Smiglarski Fri, 01 May 2015 00:55:15 -0700 On Fri, May 1, 2015 at 12:29 AM, Michael Niedermayer wrote: > On Thu, Apr 30, 2015 at 09:27:25PM +0100, Matthew Smiglarski wrote: >> The segfault occurred when running ffmpeg with x11grab and specifying a >> resolution size greater than the screen, alongside an offset: >> >> ./ffmpeg -f x11grab -r 30 -s 1920x1147 -i :0.0+0,53 output.mkv > is this still needed after dc83733f2bf2f26433bbf23d42fe92a2c7691df1 and > f5c5aa968c3c96ff3968bd5b060e5a0f2f278732 No, no longer needed. Good fix. The segfault is now avoided and the following message is seen: [x11grab @ 0x28c7200] Capture area 1920x1147 at position 0.53 outside the screen size 1366x768 :0.0+0,53: Invalid argument (return code 1) Thanks, Matt ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] OS/2:Makedef.cmd cleanup
On Tue, May 05, 2015 at 09:07:59PM -0700, Dave Yeo wrote: > From 448cf672d7793e0d5166d66c7daffacdc8a3af72 Mon Sep 17 00:00:00 2001 > From: Dave Yeo > Date: Tue, 5 May 2015 20:22:51 -0700 > Subject: [PATCH] OS/2:Makedef.cmd cleanup > > Remove PROTMODE as it doesn't make sense for DLLs. Also fixes a warning with > the OpenWatcom linker > Export symbols as names rather then ordinals for better compatibility for > minor releases. > > --- > configure | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Exact screen size not working: Re: [PATCH] Fix segfault with x11grab when switching windows.
Le septidi 17 floréal, an CCXXIII, davidpbrown a écrit :
> tldr; Using exact screen size doesn't work but less one pixel does.
The attached patch should fix this.
Please feel anyone free to apply without waiting on me.
davidpbrown: in the future, remember that bug reports should go to the users
mailing list or the issue tracker, unless they are accompanied by a patch.
Regards,
--
Nicolas George
From 9a26eec2aea97aac3c78a943c76d5bc2334cd8bf Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Wed, 6 May 2015 11:53:19 +0200
Subject: [PATCH] lavd/xcbgrab: fix comparison with screen size.
Signed-off-by: Nicolas George
---
libavdevice/xcbgrab.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index 15512cd..166575c 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -533,8 +533,8 @@ static int create_stream(AVFormatContext *s)
gc = xcb_get_geometry(c->conn, c->screen->root);
geo = xcb_get_geometry_reply(c->conn, gc, NULL);
-if (c->x + c->width >= geo->width ||
-c->y + c->height >= geo->height) {
+if (c->x + c->width > geo->width ||
+c->y + c->height > geo->height) {
av_log(s, AV_LOG_ERROR,
"Capture area %dx%d at position %d.%d "
"outside the screen size %dx%d\n",
--
2.1.4
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Loongson Optimization Patchs and Machine Express Issuse
On Wed, May 06, 2015 at 05:18:15PM +0800, 周晓勇 wrote: > > > > > -原始邮件- > > 发件人: "Michael Niedermayer" > > 发送时间: 2015年5月6日 星期三 > > 收件人: "FFmpeg development discussions and patches" > > 抄送: gaoxiang , "孟小甫" > > 主题: Re: [FFmpeg-devel] Loongson Optimization Patchs and Machine Express > > Issuse > > > > On Tue, May 05, 2015 at 08:06:57PM +0200, Michael Niedermayer wrote: > > > On Wed, Apr 22, 2015 at 02:27:11PM +0800, 周晓勇 wrote: > > > > Hi Michael, > > > > We have prepared the patchs and Loongson-3A machine for you, but > > > > DHL needs consignee's phone number in case they could not contact u. > > > > Could you send me your phone number right now? I have make an > > > > appointment with courier tomorrow morning. > > > > The enclosures are our Loongson-3 patchs for ffmpeg-master based on > > > > fbdaebb29861d32acc93fa55fd13554a2ae32eb4. > > > > Cause the machine belong to the company, our boss need one > > > > Electronic Receipt to confirm that i do not keep the machine privately. > > > > Could you email me one receipt with your sign after you receive it? > > > > > > For the record, i confirm to have recived one loongson computer: > > > > > > according to /proc/cpuinfo, 4 core > > > system type : lst-loongson3-eva > > > machine : Unknown > > > processor : 0 > > > cpu model : ICT Loongson-3A V0.5 FPU V0.1 > > > BogoMIPS: 717.28 > > > ... > > > with 500gb 7200rpm WD Caviar Blue HDD > > > 4gb memory > > > > it seems fate does not pass > > ./configure --enable-gpl --cc='ccache gcc' --enable-pthreads > > --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 > > --assert-level=2 --cpu=loongson3a > > gcc (GCC) 4.8.3 20140624 (Red Hat 4.8.3-1) > > > > Checkout the enclosure, you may need ccache rpms installed before do the > configure. i installed it with "yum install ccache" is there a problem with the ccache installed this way ? also, is it possible to upgrade the distro on this box ? fedora 19 has reached "end of life" in 2015-01-06 Thanks [...] -- 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] Exact screen size not working: Re: [PATCH] Fix segfault with x11grab when switching windows.
On Wed, May 06, 2015 at 11:55:25AM +0200, Nicolas George wrote: > Le septidi 17 floréal, an CCXXIII, davidpbrown a écrit : > > tldr; Using exact screen size doesn't work but less one pixel does. > > The attached patch should fix this. > > Please feel anyone free to apply without waiting on me. applied thanks [...] -- 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] configure: replace arch loongson with arch extra list loongson
On Wed, May 06, 2015 at 02:38:21PM +0800, 周晓勇 wrote: > From a5031b4c4b97f790a40603cff9a1f45cbb043005 Mon Sep 17 00:00:00 2001 > From: ZhouXiaoyong > Date: Wed, 6 May 2015 14:05:21 +0800 > Subject: [PATCH] configure: replace arch loongson with arch extra list > loongson > > fate pass when do configure without --cc='ccache gcc' option: > ./configure --enable-gpl --enable-pthreads --samples=/home/loongson/fate/ > --enable-nonfree --enable-version3 --assert-level=2 --cpu=loongson3a > --enable-loongson3 with this ARCH_MIPS64 is disabled, is this intended ? why is "--enable-loongson3" needed when "--cpu=loongson3a" is already specified ? and fate still fails time ./configure --enable-gpl --enable-pthreads --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 --assert-level=2 --cpu=loongson3a --enable-loongson3 real4m48.779s user4m13.918s sys 0m40.020s time make -j4 real19m31.114s user57m52.785s sys 2m52.359s make -j5 fate-vsynth1-rv10 fate-vsynth1-svq1 fate-amrwb-23k85 fate-dss-lp fate-lavf-avi --- ./tests/ref/fate/dss-lp 2015-05-06 01:16:58.238387245 +0800 +++ tests/data/fate/dss-lp 2015-05-06 20:15:23.060689405 +0800 @@ -1,31 +1,31 @@ #tb 0: 1/8000 -0, 0, 0, 240, 480, 0xf1107658 -0,240,240, 240, 480, 0x50dee179 -0,480,480, 240, 480, 0x40090802 -0,720,720, 240, 480, 0x3ef9f6ff -0,960,960, 240, 480, 0x5b7df231 -0, 1200, 1200, 240, 480, 0xe266efd1 -0, 1440, 1440, 240, 480, 0xfbe6e658 -0, 1680, 1680, 240, 480, 0xde84f311 -0, 1920, 1920, 240, 480, 0x5854ec2f -0, 2160, 2160, 240, 480, 0x4901cdea -0, 2400, 2400, 240, 480, 0x03f3e619 -0, 2640, 2640, 240, 480, 0x47abfe87 -0, 2880, 2880, 240, 480, 0x69dddf34 -0, 3120, 3120, 240, 480, 0x1cfeee2c -0, 3360, 3360, 240, 480, 0x1860ef1c -0, 3600, 3600, 240, 480, 0x8f86e8ed -0, 3840, 3840, 240, 480, 0x307deaf8 -0, 4080, 4080, 240, 480, 0xeca7eca0 -0, 4320, 4320, 240, 480, 0x1835ee1c -0, 4560, 4560, 240, 480, 0x6676ed66 -0, 4800, 4800, 240, 480, 0x49c2fd04 -0, 5040, 5040, 240, 480, 0xc463db75 -0, 5280, 5280, 240, 480, 0x1931ed7d -0, 5520, 5520, 240, 480, 0xc99ff886 -0, 5760, 5760, 240, 480, 0xcd3ae8de -0, 6000, 6000, 240, 480, 0x2294ecfa -0, 6240, 6240, 240, 480, 0xcf5ef14b -0, 6480, 6480, 240, 480, 0x6325d4fe -0, 6720, 6720, 240, 480, 0x3790dcf2 -0, 6960, 6960, 240, 480, 0x0fbee6c0 +0, 0, 0, 240, 480, 0x4f3de452 +0,240,240, 240, 480, 0x55d1f9da +0,480,480, 240, 480, 0xe887e1f6 +0,720,720, 240, 480, 0xc353f768 +0,960,960, 240, 480, 0x34adebcc +0, 1200, 1200, 240, 480, 0x7d67dfa2 +0, 1440, 1440, 240, 480, 0xc7a4f1f4 +0, 1680, 1680, 240, 480, 0x549cf083 +0, 1920, 1920, 240, 480, 0x468dead7 +0, 2160, 2160, 240, 480, 0x7e6af748 +0, 2400, 2400, 240, 480, 0x02f20456 +0, 2640, 2640, 240, 480, 0xb9d5eb37 +0, 2880, 2880, 240, 480, 0x008cee35 +0, 3120, 3120, 240, 480, 0xdd13f6c0 +0, 3360, 3360, 240, 480, 0xaa0df718 +0, 3600, 3600, 240, 480, 0x0a84ee9c +0, 3840, 3840, 240, 480, 0xaccfed94 +0, 4080, 4080, 240, 480, 0x65c7f1bf +0, 4320, 4320, 240, 480, 0xda8cebed +0, 4560, 4560, 240, 480, 0x0ea4f747 +0, 4800, 4800, 240, 480, 0x0feee8a6 +0, 5040, 5040, 240, 480, 0x65d0de7d +0, 5280, 5280, 240, 480, 0xc986f146 +0, 5520, 5520, 240, 480, 0x7886f3f5 +0, 5760, 5760, 240, 480, 0x39a6eda8 +0, 6000, 6000, 240, 480, 0x636af0b0 +0, 6240, 6240, 240, 480, 0xdd2bfec3 +0, 6480, 6480, 240, 480, 0x1baddcc4 +0, 6720, 6720, 240, 480, 0x12cbef82 +0, 6960, 6960, 240, 480, 0xbd11ee44 Test dss-lp failed. Look at tests/data/fate/dss-lp.err for details. make: *** [fate-dss-lp] Error 1 make: *** Waiting for unfinished jobs stddev:32798.91 PSNR: 6.01 MAXDIFF:46621 bytes: 327680/ 327680 stddev: |32798.91 - 0| >=
Re: [FFmpeg-devel] [RFC]Fix flac with high lpc precision
On Wed, May 06, 2015 at 09:27:22AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached is my attempt to fix ticket #4421 based on the > analysis by trac user lvqcl. If the patch is ok, I will > add the encoder check to the decoder and the version > bump. > > Please review, Carl Eugen > > TODO: Fix indentation in libavcodec/x86/flacdsp_init.c() > arm/flacdsp_init_arm.c |4 ++-- > flacdec.c |6 +- > flacdsp.c | 11 --- > flacdsp.h | 12 > flacenc.c | 27 ++- > x86/flacdsp_init.c | 10 -- > 6 files changed, 45 insertions(+), 25 deletions(-) > fc060d52aeff3b151eabadf58b4be4b8880bf0f0 patchflaclpc1.diff > diff --git a/libavcodec/arm/flacdsp_init_arm.c > b/libavcodec/arm/flacdsp_init_arm.c probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] diracdec: check if reference could not be allocated
On 06.05.2015 02:26, Michael Niedermayer wrote: > On Tue, May 05, 2015 at 11:51:48PM +0200, Andreas Cadhalpun wrote: >> s->ref_pics[i] is later used as ref argument of interpolate_refplane, >> where it is dereferenced. >> >> If it is NULL, it causes a segmentation fault. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> libavcodec/diracdec.c | 6 ++ >> 1 file changed, 6 insertions(+) > > applied > > though i would also prefer more expressive error codes I agree, but most of that file lacks proper error codes/forwarding. I'll see if I can fix this properly. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Re: [PATCH] diracdec: check that block length is large enough
On 06.05.2015 01:49, Michael Niedermayer wrote:
> On Tue, May 05, 2015 at 10:39:50PM +0200, Andreas Cadhalpun wrote:
>> +if (s->plane[0].xblen >> s->chroma_x_shift <= 0 || s->plane[0].yblen >>
>> s->chroma_y_shift <= 0) {
>> +av_log(s->avctx, AV_LOG_ERROR, "Block length too small\n");
>> +return -1;
>> +}
>
> a broader check is possible
> the spec says "Frame height shall be an integer multiple of picture chroma
> height."
> in 10.5.1
> ive not found an equivalent for width but from rounding the chroma
> width down i doubt that the spec intends to allow non multiplies for
> the width
OK, new patch attached.
Best regards,
Andreas
>From 2269fc041c160a7e5acff6984186240f05d90bf0 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Wed, 6 May 2015 15:34:53 +0200
Subject: [PATCH] diracdec: check that block length is valid
In init_planes p->xblen and p->yblen are set to:
p->xblen = s->plane[0].xblen >> s->chroma_x_shift;
p->yblen = s->plane[0].yblen >> s->chroma_y_shift;
These are later used as block_w and block_h arguments of
s->vdsp.emulated_edge_mc. If one of them is 0 it triggers an av_assert2
in emulated_edge_mc:
av_assert2(start_x < end_x && block_w > 0);
av_assert2(start_y < end_y && block_h > 0);
Signed-off-by: Andreas Cadhalpun
---
libavcodec/diracdec.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index d452982..deb4b26 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -902,6 +902,14 @@ static int dirac_unpack_prediction_parameters(DiracContext *s)
/*[DIRAC_STD] 11.2.4 motion_data_dimensions()
Calculated in function dirac_unpack_block_motion_data */
+if (s->plane[0].xblen % (1 << s->chroma_x_shift) != 0 ||
+s->plane[0].yblen % (1 << s->chroma_y_shift) != 0 ||
+!s->plane[0].xblen || !s->plane[0].yblen) {
+av_log(s->avctx, AV_LOG_ERROR,
+ "invalid x/y block length (%d/%d) for x/y chroma shift (%d/%d)\n",
+ s->plane[0].xblen, s->plane[0].yblen, s->chroma_x_shift, s->chroma_y_shift);
+return AVERROR_INVALIDDATA;
+}
if (!s->plane[0].xbsep || !s->plane[0].ybsep || s->plane[0].xbsep < s->plane[0].xblen/2 || s->plane[0].ybsep < s->plane[0].yblen/2) {
av_log(s->avctx, AV_LOG_ERROR, "Block separation too small\n");
return -1;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] dirac: use and forward error codes
Signed-off-by: Andreas Cadhalpun
---
libavcodec/dirac_dwt.c | 2 +-
libavcodec/diracdec.c | 75 --
2 files changed, 43 insertions(+), 34 deletions(-)
diff --git a/libavcodec/dirac_dwt.c b/libavcodec/dirac_dwt.c
index da2da75..ee3665e 100644
--- a/libavcodec/dirac_dwt.c
+++ b/libavcodec/dirac_dwt.c
@@ -537,7 +537,7 @@ int ff_spatial_idwt_init2(DWTContext *d, IDWTELEM *buffer,
int width, int height
break;
default:
av_log(NULL, AV_LOG_ERROR, "Unknown wavelet type %d\n", type);
-return -1;
+return AVERROR_INVALIDDATA;
}
if (HAVE_MMX) ff_spatial_idwt_init_mmx(d, type);
diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index deb4b26..dbf2fd1 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -884,7 +884,7 @@ static int dirac_unpack_prediction_parameters(DiracContext
*s)
if (idx > 4) {
av_log(s->avctx, AV_LOG_ERROR, "Block prediction index too high\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
if (idx == 0) {
@@ -912,15 +912,15 @@ static int
dirac_unpack_prediction_parameters(DiracContext *s)
}
if (!s->plane[0].xbsep || !s->plane[0].ybsep || s->plane[0].xbsep <
s->plane[0].xblen/2 || s->plane[0].ybsep < s->plane[0].yblen/2) {
av_log(s->avctx, AV_LOG_ERROR, "Block separation too small\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
if (s->plane[0].xbsep > s->plane[0].xblen || s->plane[0].ybsep >
s->plane[0].yblen) {
av_log(s->avctx, AV_LOG_ERROR, "Block separation greater than size\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
if (FFMAX(s->plane[0].xblen, s->plane[0].yblen) > MAX_BLOCKSIZE) {
av_log(s->avctx, AV_LOG_ERROR, "Unsupported large block size\n");
-return -1;
+return AVERROR_PATCHWELCOME;
}
/*[DIRAC_STD] 11.2.5 Motion vector precision. motion_vector_precision()
@@ -928,7 +928,7 @@ static int dirac_unpack_prediction_parameters(DiracContext
*s)
s->mv_precision = svq3_get_ue_golomb(gb);
if (s->mv_precision > 3) {
av_log(s->avctx, AV_LOG_ERROR, "MV precision finer than eighth-pel\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
/*[DIRAC_STD] 11.2.6 Global motion. global_motion()
@@ -967,7 +967,7 @@ static int dirac_unpack_prediction_parameters(DiracContext
*s)
Picture prediction mode, not currently used. */
if (svq3_get_ue_golomb(gb)) {
av_log(s->avctx, AV_LOG_ERROR, "Unknown picture prediction mode\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
/* [DIRAC_STD] 11.2.8 Reference picture weight. reference_picture_weights()
@@ -999,7 +999,7 @@ static int dirac_unpack_idwt_params(DiracContext *s)
tmp = svq3_get_ue_golomb(gb); \
if (cond) { \
av_log(s->avctx, AV_LOG_ERROR, errmsg); \
-return -1; \
+return AVERROR_INVALIDDATA; \
}\
dst = tmp;
@@ -1263,7 +1263,7 @@ static int dirac_unpack_block_motion_data(DiracContext *s)
for (x = 0; x < s->sbwidth; x++) {
unsigned int split = dirac_get_arith_uint(arith, CTX_SB_F1,
CTX_SB_DATA);
if (split > 2)
-return -1;
+return AVERROR_INVALIDDATA;
sbsplit[x] = (split + pred_sbsplit(sbsplit+x, s->sbwidth, x, y)) %
3;
}
sbsplit += s->sbwidth;
@@ -1631,9 +1631,10 @@ static int dirac_decode_frame_internal(DiracContext *s)
memset(p->idwt_buf, 0, p->idwt_stride * p->idwt_height *
sizeof(IDWTELEM));
decode_component(s, comp); /* [DIRAC_STD] 13.4.1
core_transform_data() */
}
-if (ff_spatial_idwt_init2(&d, p->idwt_buf, p->idwt_width,
p->idwt_height, p->idwt_stride,
- s->wavelet_idx+2, s->wavelet_depth,
p->idwt_tmp))
-return -1;
+ret = ff_spatial_idwt_init2(&d, p->idwt_buf, p->idwt_width,
p->idwt_height, p->idwt_stride,
+s->wavelet_idx+2, s->wavelet_depth,
p->idwt_tmp);
+if (ret < 0)
+return ret;
if (!s->num_refs) { /* intra */
for (y = 0; y < p->height; y += 16) {
@@ -1714,7 +1715,7 @@ static int get_buffer_with_edge(AVCodecContext *avctx,
AVFrame *f, int flags)
static int dirac_decode_picture_header(DiracContext *s)
{
unsigned retire, picnum;
-int i, j;
+int i, j, ret;
int64_t refdist, refnum;
GetBitContext *gb = &s->gb;
@@ -1757,7 +1758,7 @@ static int dirac_decode_picture_header(DiracContext *s)
if (!s->ref_pics[i]) {
av_log(s->avctx, AV_LOG_ERROR, "Reference could not be
allocated\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
}
@@ -1782,13 +1783,16 @@ static int dirac_decode_picture_header(DiracContext *s)
}
if (s->num_refs) {
-if (dirac_unpack_prediction_par
Re: [FFmpeg-devel] [PATCH] dirac: use and forward error codes
On Wed, May 06, 2015 at 04:54:40PM +0200, Andreas Cadhalpun wrote: > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/dirac_dwt.c | 2 +- > libavcodec/diracdec.c | 75 > -- > 2 files changed, 43 insertions(+), 34 deletions(-) applied 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
[FFmpeg-devel] [PATCH 1/9] lavu: add yuv440p10/12 pixfmts.
---
libavutil/pixdesc.c | 48
libavutil/pixfmt.h | 6 ++
2 files changed, 54 insertions(+)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index de1ea7fb..5086edc 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -605,6 +605,54 @@ const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = AV_PIX_FMT_FLAG_PLANAR,
},
+[AV_PIX_FMT_YUV440P10LE] = {
+.name = "yuv440p10le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 9 },/* Y */
+{ 1, 1, 1, 0, 9 },/* U */
+{ 2, 1, 1, 0, 9 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV440P10BE] = {
+.name = "yuv440p10be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 9 },/* Y */
+{ 1, 1, 1, 0, 9 },/* U */
+{ 2, 1, 1, 0, 9 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV440P12LE] = {
+.name = "yuv440p12le",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 11 },/* Y */
+{ 1, 1, 1, 0, 11 },/* U */
+{ 2, 1, 1, 0, 11 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_YUV440P12BE] = {
+.name = "yuv440p12be",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 11 },/* Y */
+{ 1, 1, 1, 0, 11 },/* U */
+{ 2, 1, 1, 0, 11 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
+},
[AV_PIX_FMT_YUVA420P] = {
.name = "yuva420p",
.nb_components = 4,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 534747b..ba22eed 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -307,6 +307,10 @@ enum AVPixelFormat {
#if !FF_API_XVMC
AV_PIX_FMT_XVMC,///< XVideo Motion Acceleration via common packet passing
#endif /* !FF_API_XVMC */
+AV_PIX_FMT_YUV440P10LE, ///< planar YUV 4:4:0,20bpp, (1 Cr & Cb sample per
1x2 Y samples), little-endian
+AV_PIX_FMT_YUV440P10BE, ///< planar YUV 4:4:0,20bpp, (1 Cr & Cb sample per
1x2 Y samples), big-endian
+AV_PIX_FMT_YUV440P12LE, ///< planar YUV 4:4:0,24bpp, (1 Cr & Cb sample per
1x2 Y samples), little-endian
+AV_PIX_FMT_YUV440P12BE, ///< planar YUV 4:4:0,24bpp, (1 Cr & Cb sample per
1x2 Y samples), big-endian
AV_PIX_FMT_NB,///< number of pixel formats, DO NOT USE THIS if you
want to link with shared libav* because the number of formats might differ
between versions
@@ -362,9 +366,11 @@ enum AVPixelFormat {
#define AV_PIX_FMT_YUV444P9 AV_PIX_FMT_NE(YUV444P9BE , YUV444P9LE)
#define AV_PIX_FMT_YUV420P10 AV_PIX_FMT_NE(YUV420P10BE, YUV420P10LE)
#define AV_PIX_FMT_YUV422P10 AV_PIX_FMT_NE(YUV422P10BE, YUV422P10LE)
+#define AV_PIX_FMT_YUV440P10 AV_PIX_FMT_NE(YUV440P10BE, YUV440P10LE)
#define AV_PIX_FMT_YUV444P10 AV_PIX_FMT_NE(YUV444P10BE, YUV444P10LE)
#define AV_PIX_FMT_YUV420P12 AV_PIX_FMT_NE(YUV420P12BE, YUV420P12LE)
#define AV_PIX_FMT_YUV422P12 AV_PIX_FMT_NE(YUV422P12BE, YUV422P12LE)
+#define AV_PIX_FMT_YUV440P12 AV_PIX_FMT_NE(YUV440P12BE, YUV440P12LE)
#define AV_PIX_FMT_YUV444P12 AV_PIX_FMT_NE(YUV444P12BE, YUV444P12LE)
#define AV_PIX_FMT_YUV420P14 AV_PIX_FMT_NE(YUV420P14BE, YUV420P14LE)
#define AV_PIX_FMT_YUV422P14 AV_PIX_FMT_NE(YUV422P14BE, YUV422P14LE)
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/9] swscale: add yuv440p10/12 pixfmts.
---
libswscale/input.c| 8
libswscale/swscale_unscaled.c | 2 ++
libswscale/utils.c| 4
3 files changed, 14 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index 7b3b706..1f04fc2 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -931,9 +931,11 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_YUV422P9LE:
case AV_PIX_FMT_YUV420P9LE:
case AV_PIX_FMT_YUV422P10LE:
+case AV_PIX_FMT_YUV440P10LE:
case AV_PIX_FMT_YUV444P10LE:
case AV_PIX_FMT_YUV420P10LE:
case AV_PIX_FMT_YUV422P12LE:
+case AV_PIX_FMT_YUV440P12LE:
case AV_PIX_FMT_YUV444P12LE:
case AV_PIX_FMT_YUV420P12LE:
case AV_PIX_FMT_YUV422P14LE:
@@ -958,9 +960,11 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_YUV444P9BE:
case AV_PIX_FMT_YUV422P9BE:
case AV_PIX_FMT_YUV420P9BE:
+case AV_PIX_FMT_YUV440P10BE:
case AV_PIX_FMT_YUV444P10BE:
case AV_PIX_FMT_YUV422P10BE:
case AV_PIX_FMT_YUV420P10BE:
+case AV_PIX_FMT_YUV440P12BE:
case AV_PIX_FMT_YUV444P12BE:
case AV_PIX_FMT_YUV422P12BE:
case AV_PIX_FMT_YUV420P12BE:
@@ -1197,9 +1201,11 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_YUV422P9LE:
case AV_PIX_FMT_YUV420P9LE:
case AV_PIX_FMT_YUV444P10LE:
+case AV_PIX_FMT_YUV440P10LE:
case AV_PIX_FMT_YUV422P10LE:
case AV_PIX_FMT_YUV420P10LE:
case AV_PIX_FMT_YUV444P12LE:
+case AV_PIX_FMT_YUV440P12LE:
case AV_PIX_FMT_YUV422P12LE:
case AV_PIX_FMT_YUV420P12LE:
case AV_PIX_FMT_YUV444P14LE:
@@ -1229,9 +1235,11 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_YUV422P9BE:
case AV_PIX_FMT_YUV420P9BE:
case AV_PIX_FMT_YUV444P10BE:
+case AV_PIX_FMT_YUV440P10BE:
case AV_PIX_FMT_YUV422P10BE:
case AV_PIX_FMT_YUV420P10BE:
case AV_PIX_FMT_YUV444P12BE:
+case AV_PIX_FMT_YUV440P12BE:
case AV_PIX_FMT_YUV422P12BE:
case AV_PIX_FMT_YUV420P12BE:
case AV_PIX_FMT_YUV444P14BE:
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 490290f..b426fa1 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1694,6 +1694,8 @@ void ff_get_unscaled_swscale(SwsContext *c)
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV422P12) ||
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV422P14) ||
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV422P16) ||
+IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV440P10) ||
+IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV440P12) ||
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV444P9) ||
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV444P10) ||
IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_YUV444P12) ||
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 45e4b7c..f9f4ec6 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -119,6 +119,10 @@ static const FormatEntry format_entries[AV_PIX_FMT_NB] = {
[AV_PIX_FMT_GRAY16LE]= { 1, 1 },
[AV_PIX_FMT_YUV440P] = { 1, 1 },
[AV_PIX_FMT_YUVJ440P]= { 1, 1 },
+[AV_PIX_FMT_YUV440P10LE] = { 1, 1 },
+[AV_PIX_FMT_YUV440P10BE] = { 1, 1 },
+[AV_PIX_FMT_YUV440P12LE] = { 1, 1 },
+[AV_PIX_FMT_YUV440P12BE] = { 1, 1 },
[AV_PIX_FMT_YUVA420P]= { 1, 1 },
[AV_PIX_FMT_YUVA422P]= { 1, 1 },
[AV_PIX_FMT_YUVA444P]= { 1, 1 },
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/9] vp9: add profile 2/3 to exported profiles.
---
libavcodec/avcodec.h | 2 ++
libavcodec/vp9.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3d5e82d..f1a330e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2914,6 +2914,8 @@ typedef struct AVCodecContext {
#define FF_PROFILE_VP9_00
#define FF_PROFILE_VP9_11
+#define FF_PROFILE_VP9_22
+#define FF_PROFILE_VP9_33
/**
* level
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 71057f3..4ba46f3 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -4089,6 +4089,8 @@ static int
vp9_decode_update_thread_context(AVCodecContext *dst, const AVCodecCo
static const AVProfile profiles[] = {
{ FF_PROFILE_VP9_0, "Profile 0" },
{ FF_PROFILE_VP9_1, "Profile 1" },
+{ FF_PROFILE_VP9_2, "Profile 2" },
+{ FF_PROFILE_VP9_3, "Profile 3" },
{ FF_PROFILE_UNKNOWN },
};
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/9] lavc: add yuv440p10/12 formats to aligned pixfmt list.
--- libavcodec/utils.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index 40dde88..48286cf 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -341,6 +341,10 @@ void avcodec_align_dimensions2(AVCodecContext *s, int *width, int *height, case AV_PIX_FMT_YUVA422P10BE: case AV_PIX_FMT_YUVA422P16LE: case AV_PIX_FMT_YUVA422P16BE: +case AV_PIX_FMT_YUV440P10LE: +case AV_PIX_FMT_YUV440P10BE: +case AV_PIX_FMT_YUV440P12LE: +case AV_PIX_FMT_YUV440P12BE: case AV_PIX_FMT_YUV444P9LE: case AV_PIX_FMT_YUV444P9BE: case AV_PIX_FMT_YUV444P10LE: -- 2.1.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/9] vp9: parse profile 2/3 bitdepth in frame header.
---
libavcodec/vp9.c | 36
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 4ba46f3..298470a 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -478,36 +478,47 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
};
VP9Context *s = ctx->priv_data;
enum AVPixelFormat res;
+int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8, 1:10,
2:12
ctx->colorspace = colorspaces[get_bits(&s->gb, 3)];
if (ctx->colorspace == AVCOL_SPC_RGB) { // RGB = profile 1
-if (ctx->profile == 1) {
+static const enum AVPixelFormat pix_fmt_rgb[3] = {
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
+};
+if (ctx->profile & 1) {
s->ss_h = s->ss_v = 1;
-res = AV_PIX_FMT_GBRP;
+res = pix_fmt_rgb[bits];
ctx->color_range = AVCOL_RANGE_JPEG;
} else {
-av_log(ctx, AV_LOG_ERROR, "RGB not supported in profile 0\n");
+av_log(ctx, AV_LOG_ERROR, "RGB not supported in profile %d\n",
+ ctx->profile);
return AVERROR_INVALIDDATA;
}
} else {
-static const enum AVPixelFormat pix_fmt_for_ss[2 /* v */][2 /* h */] =
{
-{ AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P },
-{ AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV420P },
+static const enum AVPixelFormat pix_fmt_for_ss[3][2 /* v */][2 /* h
*/] = {
+{ { AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P },
+ { AV_PIX_FMT_YUV440P, AV_PIX_FMT_YUV420P } },
+{ { AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV422P10 },
+ { AV_PIX_FMT_YUV440P10, AV_PIX_FMT_YUV420P10 } },
+{ { AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV422P12 },
+ { AV_PIX_FMT_YUV440P12, AV_PIX_FMT_YUV420P12 } }
};
ctx->color_range = get_bits1(&s->gb) ? AVCOL_RANGE_JPEG :
AVCOL_RANGE_MPEG;
-if (ctx->profile == 1) {
+if (ctx->profile & 1) {
s->ss_h = get_bits1(&s->gb);
s->ss_v = get_bits1(&s->gb);
-if ((res = pix_fmt_for_ss[s->ss_v][s->ss_h]) ==
AV_PIX_FMT_YUV420P) {
-av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in profile
1\n");
+if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
AV_PIX_FMT_YUV420P) {
+av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in profile
%d\n",
+ ctx->profile);
return AVERROR_INVALIDDATA;
} else if (get_bits1(&s->gb)) {
-av_log(ctx, AV_LOG_ERROR, "Profile 1 color details reserved
bit set\n");
+av_log(ctx, AV_LOG_ERROR, "Profile %d color details reserved
bit set\n",
+ ctx->profile);
return AVERROR_INVALIDDATA;
}
} else {
s->ss_h = s->ss_v = 1;
-res = AV_PIX_FMT_YUV420P;
+res = pix_fmt_for_ss[bits][1][1];
}
}
@@ -534,7 +545,8 @@ static int decode_frame_header(AVCodecContext *ctx,
}
ctx->profile = get_bits1(&s->gb);
ctx->profile |= get_bits1(&s->gb) << 1;
-if (ctx->profile > 1) {
+if (ctx->profile == 3) ctx->profile += get_bits1(&s->gb);
+if (ctx->profile > 3) {
av_log(ctx, AV_LOG_ERROR, "Profile %d is not yet supported\n",
ctx->profile);
return AVERROR_INVALIDDATA;
}
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/9] vp9: add inter-frame profile 2/3 suport.
---
libavcodec/vp9.c | 136 ---
libavcodec/vp9_mc_template.c | 37 +++-
libavcodec/vp9dsp_template.c | 81 ++
3 files changed, 167 insertions(+), 87 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 8957e40..15951f2 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -2733,7 +2733,7 @@ static av_always_inline void mc_luma_scaled(VP9Context
*s, vp9_scaled_mc_func sm
const uint8_t *ref, ptrdiff_t
ref_stride,
ThreadFrame *ref_frame,
ptrdiff_t y, ptrdiff_t x, const
VP56mv *mv,
-int bw, int bh, int w, int h,
+int bw, int bh, int w, int h, int
bytesperpixel,
const uint16_t *scale, const
uint8_t *step)
{
#define scale_mv(n, dim) (((int64_t)(n) * scale[dim]) >> 14)
@@ -2747,7 +2747,7 @@ static av_always_inline void mc_luma_scaled(VP9Context
*s, vp9_scaled_mc_func sm
y = my >> 4;
x = mx >> 4;
-ref += y * ref_stride + x;
+ref += y * ref_stride + x * bytesperpixel;
mx &= 15;
my &= 15;
refbw_m1 = ((bw - 1) * step[0] + mx) >> 4;
@@ -2759,12 +2759,12 @@ static av_always_inline void mc_luma_scaled(VP9Context
*s, vp9_scaled_mc_func sm
ff_thread_await_progress(ref_frame, FFMAX(th, 0), 0);
if (x < 3 || y < 3 || x + 4 >= w - refbw_m1 || y + 4 >= h - refbh_m1) {
s->vdsp.emulated_edge_mc(s->edge_emu_buffer,
- ref - 3 * ref_stride - 3,
- 144, ref_stride,
+ ref - 3 * ref_stride - 3 * bytesperpixel,
+ 288, ref_stride,
refbw_m1 + 8, refbh_m1 + 8,
x - 3, y - 3, w, h);
-ref = s->edge_emu_buffer + 3 * 144 + 3;
-ref_stride = 144;
+ref = s->edge_emu_buffer + 3 * 288 + 3 * bytesperpixel;
+ref_stride = 288;
}
smc(dst, dst_stride, ref, ref_stride, bh, mx, my, step[0], step[1]);
}
@@ -2776,7 +2776,7 @@ static av_always_inline void mc_chroma_scaled(VP9Context
*s, vp9_scaled_mc_func
const uint8_t *ref_v, ptrdiff_t
src_stride_v,
ThreadFrame *ref_frame,
ptrdiff_t y, ptrdiff_t x, const
VP56mv *mv,
- int bw, int bh, int w, int h,
+ int bw, int bh, int w, int h,
int bytesperpixel,
const uint16_t *scale, const
uint8_t *step)
{
// BUG https://code.google.com/p/webm/issues/detail?id=820
@@ -2788,8 +2788,8 @@ static av_always_inline void mc_chroma_scaled(VP9Context
*s, vp9_scaled_mc_func
y = my >> 4;
x = mx >> 4;
-ref_u += y * src_stride_u + x;
-ref_v += y * src_stride_v + x;
+ref_u += y * src_stride_u + x * bytesperpixel;
+ref_v += y * src_stride_v + x * bytesperpixel;
mx &= 15;
my &= 15;
refbw_m1 = ((bw - 1) * step[0] + mx) >> 4;
@@ -2801,51 +2801,60 @@ static av_always_inline void
mc_chroma_scaled(VP9Context *s, vp9_scaled_mc_func
ff_thread_await_progress(ref_frame, FFMAX(th, 0), 0);
if (x < 3 || y < 3 || x + 4 >= w - refbw_m1 || y + 4 >= h - refbh_m1) {
s->vdsp.emulated_edge_mc(s->edge_emu_buffer,
- ref_u - 3 * src_stride_u - 3,
- 144, src_stride_u,
+ ref_u - 3 * src_stride_u - 3 * bytesperpixel,
+ 288, src_stride_u,
refbw_m1 + 8, refbh_m1 + 8,
x - 3, y - 3, w, h);
-ref_u = s->edge_emu_buffer + 3 * 144 + 3;
-smc(dst_u, dst_stride, ref_u, 144, bh, mx, my, step[0], step[1]);
+ref_u = s->edge_emu_buffer + 3 * 288 + 3 * bytesperpixel;
+smc(dst_u, dst_stride, ref_u, 288, bh, mx, my, step[0], step[1]);
s->vdsp.emulated_edge_mc(s->edge_emu_buffer,
- ref_v - 3 * src_stride_v - 3,
- 144, src_stride_v,
+ ref_v - 3 * src_stride_v - 3 * bytesperpixel,
+ 288, src_stride_v,
refbw_m1 + 8, refbh_m1 + 8,
x - 3, y - 3, w, h);
-ref_v = s->edge_emu_buffer + 3 * 144 + 3;
-smc(dst_v, dst_stride, ref_v, 144, bh, mx, my, step[0], step[1]);
+ref_v = s->edge_emu_buffer + 3 * 288 + 3 * bytesperpixel;
+smc(dst_v, dst_stride, ref_v, 288, bh, mx, my, step[0], step[1]);
} else {
smc(dst_u, ds
[FFmpeg-devel] [PATCH 8/9] vp9: add profile 2/3 fate tests.
--- tests/fate/vpx.mak | 8 +--- tests/ref/fate/vp9p2-20-10bit-yuv420 | 15 +++ tests/ref/fate/vp9p2-20-12bit-yuv420 | 15 +++ tests/ref/fate/vp9p3-20-10bit-yuv422 | 15 +++ tests/ref/fate/vp9p3-20-10bit-yuv440 | 25 + tests/ref/fate/vp9p3-20-10bit-yuv444 | 15 +++ tests/ref/fate/vp9p3-20-12bit-yuv422 | 15 +++ tests/ref/fate/vp9p3-20-12bit-yuv440 | 25 + tests/ref/fate/vp9p3-20-12bit-yuv444 | 15 +++ 9 files changed, 145 insertions(+), 3 deletions(-) create mode 100644 tests/ref/fate/vp9p2-20-10bit-yuv420 create mode 100644 tests/ref/fate/vp9p2-20-12bit-yuv420 create mode 100644 tests/ref/fate/vp9p3-20-10bit-yuv422 create mode 100644 tests/ref/fate/vp9p3-20-10bit-yuv440 create mode 100644 tests/ref/fate/vp9p3-20-10bit-yuv444 create mode 100644 tests/ref/fate/vp9p3-20-12bit-yuv422 create mode 100644 tests/ref/fate/vp9p3-20-12bit-yuv440 create mode 100644 tests/ref/fate/vp9p3-20-12bit-yuv444 diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak index 3bc8e9a..94dfc5f 100644 --- a/tests/fate/vpx.mak +++ b/tests/fate/vpx.mak @@ -98,6 +98,8 @@ VP9_Q = 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 \ VP9_SHARP = 1 2 3 4 5 6 7 VP9_SIZE_A = 08 10 16 18 32 34 64 66 VP9_SIZE_B = 196 198 200 202 208 210 224 226 +VP9_CHROMA_SUBSAMPLE = 422 440 444 +VP9_HIGH_BITDEPTH = 10 12 define FATE_VP9_FULL $(foreach Q,$(VP9_Q),$(eval $(call FATE_VP9_SUITE,00-quantizer-$(Q @@ -105,9 +107,9 @@ $(foreach SHARP,$(VP9_SHARP),$(eval $(call FATE_VP9_SUITE,01-sharpness-$(SHARP)) $(foreach W,$(VP9_SIZE_A),$(eval $(foreach H,$(VP9_SIZE_A),$(eval $(call FATE_VP9_SUITE,02-size-$(W)x$(H)) $(foreach W,$(VP9_SIZE_B),$(eval $(foreach H,$(VP9_SIZE_B),$(eval $(call FATE_VP9_SUITE,03-size-$(W)x$(H)) $(eval $(call FATE_VP9_SUITE,03-deltaq)) -$(eval $(call FATE_VP9_PROFILE_SUITE,04-yuv444,1)) -$(eval $(call FATE_VP9_PROFILE_SUITE,04-yuv440,1)) -$(eval $(call FATE_VP9_PROFILE_SUITE,04-yuv422,1)) +$(foreach SS,$(VP9_CHROMA_SUBSAMPLE),$(eval $(call FATE_VP9_PROFILE_SUITE,04-yuv$(SS),1))) +$(foreach BD,$(VP9_HIGH_BITDEPTH),$(eval $(call FATE_VP9_PROFILE_SUITE,20-$(BD)bit-yuv420,2))) +$(foreach BD,$(VP9_HIGH_BITDEPTH),$(eval $(foreach SS,$(VP9_CHROMA_SUBSAMPLE),$(eval $(call FATE_VP9_PROFILE_SUITE,20-$(BD)bit-yuv$(SS),3) $(eval $(call FATE_VP9_SUITE,06-bilinear)) $(eval $(call FATE_VP9_SUITE,09-lf_deltas)) $(eval $(call FATE_VP9_SUITE,10-show-existing-frame)) diff --git a/tests/ref/fate/vp9p2-20-10bit-yuv420 b/tests/ref/fate/vp9p2-20-10bit-yuv420 new file mode 100644 index 000..297a178 --- /dev/null +++ b/tests/ref/fate/vp9p2-20-10bit-yuv420 @@ -0,0 +1,15 @@ +#format: frame checksums +#version: 1 +#hash: MD5 +#tb 0: 1/50 +#stream#, dts,pts, duration, size, hash +0, 0, 0,1,43200, c3964ed9065de7f839b8d878444c6140 +0, 1, 1,1,43200, 87595f7f53d6e84af9708dba72422cc4 +0, 2, 2,1,43200, 5cadbce099363a71040919e6f1cec496 +0, 3, 3,1,43200, 0e3cab2b26b936de245a94b4128a368f +0, 4, 4,1,43200, 07bde452ca50655717a85cd9fdb3f7ce +0, 5, 5,1,43200, 00bee090fe849fee5fd4eb169c62c897 +0, 6, 6,1,43200, 4564a423df89d7e9dea1226873ce9a51 +0, 7, 7,1,43200, 7580af6956360112191380a677f5e625 +0, 8, 8,1,43200, c9d05c5aadf8a372acfc2c93094d003e +0, 9, 9,1,43200, 6c08ea732cda06cf9a12f2e1a089d401 diff --git a/tests/ref/fate/vp9p2-20-12bit-yuv420 b/tests/ref/fate/vp9p2-20-12bit-yuv420 new file mode 100644 index 000..1ba0094 --- /dev/null +++ b/tests/ref/fate/vp9p2-20-12bit-yuv420 @@ -0,0 +1,15 @@ +#format: frame checksums +#version: 1 +#hash: MD5 +#tb 0: 1/50 +#stream#, dts,pts, duration, size, hash +0, 0, 0,1,43200, 8403bd5a381737e1c2d737047f6a5a0b +0, 1, 1,1,43200, 3c0bf7eecc3131e3598f6810d6b70539 +0, 2, 2,1,43200, ff020bf894bb88d74426f02a75081695 +0, 3, 3,1,43200, 097d81cb29f1caaf4446f3a3de4842d9 +0, 4, 4,1,43200, e923a7e7e0349846ba27bd2e6ebdf4df +0, 5, 5,1,43200, 28c6016e6687c7eecbe4057a4dbfe372 +0, 6, 6,1,43200, 15ae05537ea7152b535d112871b5ef84 +0, 7, 7,1,43200, cb50d043a10a0e9b52eed0e8b3aabc7b +0, 8, 8,1,43200, f97dfbce56e36a42538ef000ce0e937e +0, 9, 9,1,43200, aae42063df910ed31c09eba5f73a195c diff --git a/tests/ref/fate/vp9p3-20-10bit-yuv422 b/tests/ref/fate/vp9p3-20-10bit-yuv422 new file mode 100644 index 000..5aaf056 --- /dev/null +++ b/tests/ref/fate/vp9p3-20-10bit-yuv
[FFmpeg-devel] [PATCH 9/9] libvpxdec: add 440 pixfmts.
---
libavcodec/libvpxdec.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavcodec/libvpxdec.c b/libavcodec/libvpxdec.c
index 75231f8..11f7be1 100644
--- a/libavcodec/libvpxdec.c
+++ b/libavcodec/libvpxdec.c
@@ -72,6 +72,9 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
case VPX_IMG_FMT_I422:
avctx->pix_fmt = AV_PIX_FMT_YUV422P;
return 0;
+case VPX_IMG_FMT_I440:
+avctx->pix_fmt = AV_PIX_FMT_YUV440P;
+return 0;
case VPX_IMG_FMT_I444:
avctx->pix_fmt = AV_PIX_FMT_YUV444P;
return 0;
@@ -96,6 +99,16 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
vpx_image *img)
} else {
return AVERROR_INVALIDDATA;
}
+case VPX_IMG_FMT_I44016:
+if (img->bit_depth == 10) {
+avctx->pix_fmt = AV_PIX_FMT_YUV440P10LE;
+return 0;
+} else if (img->bit_depth == 12) {
+avctx->pix_fmt = AV_PIX_FMT_YUV440P12LE;
+return 0;
+} else {
+return AVERROR_INVALIDDATA;
+}
case VPX_IMG_FMT_I44416:
if (img->bit_depth == 10) {
avctx->pix_fmt = AV_PIX_FMT_YUV444P10LE;
--
2.1.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] diracdec: check that block length is large enough
On Wed, May 06, 2015 at 03:39:02PM +0200, Andreas Cadhalpun wrote:
> On 06.05.2015 01:49, Michael Niedermayer wrote:
> > On Tue, May 05, 2015 at 10:39:50PM +0200, Andreas Cadhalpun wrote:
> >> +if (s->plane[0].xblen >> s->chroma_x_shift <= 0 || s->plane[0].yblen
> >> >> s->chroma_y_shift <= 0) {
> >> +av_log(s->avctx, AV_LOG_ERROR, "Block length too small\n");
> >> +return -1;
> >> +}
> >
> > a broader check is possible
> > the spec says "Frame height shall be an integer multiple of picture chroma
> > height."
> > in 10.5.1
> > ive not found an equivalent for width but from rounding the chroma
> > width down i doubt that the spec intends to allow non multiplies for
> > the width
>
> OK, new patch attached.
>
> Best regards,
> Andreas
>
> diracdec.c |8
> 1 file changed, 8 insertions(+)
> 23dcbeeaf39dd41ec6b4343395f4d9e00274f7df
> 0001-diracdec-check-that-block-length-is-valid.patch
> From 2269fc041c160a7e5acff6984186240f05d90bf0 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Wed, 6 May 2015 15:34:53 +0200
> Subject: [PATCH] diracdec: check that block length is valid
>
> In init_planes p->xblen and p->yblen are set to:
> p->xblen = s->plane[0].xblen >> s->chroma_x_shift;
> p->yblen = s->plane[0].yblen >> s->chroma_y_shift;
>
> These are later used as block_w and block_h arguments of
> s->vdsp.emulated_edge_mc. If one of them is 0 it triggers an av_assert2
> in emulated_edge_mc:
> av_assert2(start_x < end_x && block_w > 0);
> av_assert2(start_y < end_y && block_h > 0);
>
> Signed-off-by: Andreas Cadhalpun
applied
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
[FFmpeg-devel] ffserver jpg patch
Can this patch be applied now? It doesn't have any line breaks anymore.
On Mon, May 04, 2015 at 06:35:36PM -0600, ill wrote:
I changed it to git and add the .write header to the last part. The first part
compiled after I changed ffserver.c, so it is no longer corrupted. Muxer
detection seems to work when I tried it for the middle part. It should be good
to fix ffserver now?
patch is still corrupted by linebreaks
probably your MUA is breaking long lines, try to attach the patch or
use git send-email
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
diff -Nrup ffmpeg-git--orig/ffserver.c ffmpeg-git/ffserver.c
--- ffmpeg-git--orig/ffserver.c2015-03-16 20:25:48.0 +0100
+++ ffmpeg-git/ffserver.c2015-04-05 02:33:53.0 +0200
@@ -967,6 +967,10 @@ static int handle_connection(HTTPContext
/* close connection if trailer sent */
if (c->state == HTTPSTATE_SEND_DATA_TRAILER)
return -1;
+/* Check if it is a single jpeg frame 123 */
+if (c->stream->single_frame && c->data_count > c->cur_frame_bytes && c->cur_frame_bytes > 0) {
+close_connection(c);
+}
break;
case HTTPSTATE_RECEIVE_DATA:
/* no need to read if no events */
diff -Nrup ffmpeg-git--orig/ffserver_config.c
ffmpeg-git/ffserver_config.c
--- ffmpeg-git--orig/ffserver_config.c2015-03-16
20:25:48.0 +0100
+++ ffmpeg-git/ffserver_config.c2015-04-05 02:33:53.0 +0200
@@ -862,8 +862,10 @@ static int ffserver_parse_config_stream(
} else {
stream->stream_type = STREAM_TYPE_LIVE;
/* JPEG cannot be used here, so use single frame MJPEG */
-if (!strcmp(arg, "jpeg"))
-strcpy(arg, "mjpeg");
+if (!strcmp(arg, "jpeg")) {
+strcpy(arg, "singlejpeg");
+stream->single_frame=1;
+}
stream->fmt = ffserver_guess_format(arg, NULL, NULL);
if (!stream->fmt)
ERROR("Unknown Format: '%s'\n", arg);
diff -Nrup ffmpeg-git--orig/ffserver_config.h
ffmpeg-git/ffserver_config.h
--- ffmpeg-git--orig/ffserver_config.h2015-03-16
20:25:48.0 +0100
+++ ffmpeg-git/ffserver_config.h2015-04-05 02:33:53.0 +0200
@@ -79,6 +79,7 @@ typedef struct FFServerStream {
int multicast_port; /* first port used for multicast */
int multicast_ttl;
int loop; /* if true, send the stream in loops (only meaningful if file) */
+char single_frame;/* only single frame */
/* feed specific */
int feed_opened; /* true if someone is writing to the
feed */
diff -Nrup ffmpeg-git--orig/libavformat/allformats.c
ffmpeg-git/libavformat/allformats.c
--- ffmpeg-git--orig/libavformat/allformats.c2015-03-16
20:25:52.0 +0100
+++ ffmpeg-git/libavformat/allformats.c2015-04-05
02:33:53.0 +0200
@@ -273,6 +273,7 @@ void av_register_all(void)
REGISTER_MUXER (SEGMENT, stream_segment);
REGISTER_DEMUXER (SHORTEN, shorten);
REGISTER_DEMUXER (SIFF, siff);
+REGISTER_MUXER (SINGLEJPEG, singlejpeg);
REGISTER_DEMUXER (SLN, sln);
REGISTER_DEMUXER (SMACKER, smacker);
REGISTER_MUXDEMUX(SMJPEG, smjpeg);
diff -Nrup ffmpeg-git--orig/libavformat/rawenc.c
ffmpeg-git/libavformat/rawenc.c
--- ffmpeg-git--orig/libavformat/rawenc.c2015-03-16
20:25:54.0 +0100
+++ ffmpeg-git/libavformat/rawenc.c2015-04-05$
02:33:53.0 +0200
@@ -250,6 +250,18 @@ AVOutputFormat ff_mjpeg_muxer = {
.write_packet = ff_raw_write_packet,
.flags = AVFMT_NOTIMESTAMPS,
};
+
+AVOutputFormat ff_singlejpeg_muxer = {
+.name = "singlejpeg",
+.long_name = NULL_IF_CONFIG_SMALL("JPEG single image"),
+.mime_type = "image/jpeg",
+.extensions= "jpg,jpeg",
+.audio_codec = AV_CODEC_ID_NONE,
+.video_codec = AV_CODEC_ID_MJPEG,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+.write_header = force_one_stream,
+};
#endif
#if CONFIG_MLP_MUXER
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Ronald S. Bultje gmail.com> writes: > +static void vert_4x4_c(uint8_t *_dst, ptrdiff_t stride, > + const uint8_t *left, const uint8_t *_top) Once upon a time, it was claimed that we must not use identifiers starting with "_". Would it be slower to decode to YUV420P16 and set bits_per_coded_sample? (Just being curious.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Hi,
On Wed, May 6, 2015 at 1:40 PM, Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
> > +static void vert_4x4_c(uint8_t *_dst, ptrdiff_t stride,
> > + const uint8_t *left, const uint8_t *_top)
>
> Once upon a time, it was claimed that we must not
> use identifiers starting with "_".
Well, they're not really variable names, just pre-cast placeholders. I'm
basically just copying the approach that hevc/h264 templating uses. For
example:
static void FUNC(put_hevc_pel_pixels)(int16_t *dst,
uint8_t *_src, ptrdiff_t _srcstride,
int height, intptr_t mx, intptr_t my,
int width)
{
int x, y;
pixel *src = (pixel *)_src;
ptrdiff_t srcstride = _srcstride / sizeof(pixel);
Note that all pre-cast placeholders start with a _ to prevent name-clashes
with the post-cast variables of interest.
> Would it be slower to decode to YUV420P16 and set
> bits_per_coded_sample? (Just being curious.)
Someone capable and interested would need to test this. I simply copied the
hevc/h264 approach.
Theoretically, I think certain parts would be faster if we kept p10/p12,
e.g. that flat loop filter (since it can be done in 16bits, and would need
to be done in 32bits if we used p16). I also think the directional
predictors (3-tap, specifically) would be slightly more complex in p16 than
in p10/p12 (see also how we do it for 8bit to keep it 8bits instead of
going to 16bits). This is admittedly minor, but it's still a factor.
Overall, the effect would be minor, like in the lower single-digit percents
or perhaps even fractional percent, but I would absolutely expect a small
performance gain from using p10/p12 over p16 w/ bits_per_coded_sample. Also
note most of this would only be noticeable after simd optimizations; in C
there would be no difference.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Ronald S. Bultje gmail.com> writes: > Overall, the effect would be minor, like in the lower > single-digit percents or perhaps even fractional percent, > but I would absolutely expect a small performance gain > from using p10/p12 over p16 w/ bits_per_coded_sample. > Also note most of this would only be noticeable after > simd optimizations; in C there would be no difference. Thank you for the explanation! I still wonder if it was a good idea to add the formats >8 and <16... (I of course do not care about the underscore.) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
Newer versions of clang will allocate %rbx as one of the inline asm inputs,
even in PIC. This occurs when building ffmpeg with clang -fsanitize=address
-O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just
include %bx in the clobber list regardless of whether PIC is on or off.
Patch attached, please review and apply on my behalf.
Nick
PS. While looking at this code, I have a couple more comments:
a) What is supposed to be at -8(%rsp) that the asm saves and restores?
Doesn't this depend on whether the compiler is using %sp or %bp? A few of
us compiler engineers couldn't figure out what this is trying to do (save a
return value to %rax? but it returns void? or to save the return address of
the function? but it's never clobbered?)
b) There's an inline comment suggesting that one variable in the inline
asm is "buf2". There is no "buf2" (did you mean "dst2" or "src2"?)
diff --git a/libswscale/x86/hscale_fast_bilinear_simd.c b/libswscale/x86/hscale_fast_bilinear_simd.c
index 103793d..bfb23e2 100644
--- a/libswscale/x86/hscale_fast_bilinear_simd.c
+++ b/libswscale/x86/hscale_fast_bilinear_simd.c
@@ -198,26 +198,15 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
int16_t *filter= c->hLumFilter;
void*mmxextFilterCode = c->lumMmxextFilterCode;
int i;
-#if defined(PIC)
-uint64_t ebxsave;
-#endif
#if ARCH_X86_64
uint64_t retsave;
#endif
__asm__ volatile(
-#if defined(PIC)
-"mov %%"REG_b", %5\n\t"
-#if ARCH_X86_64
-"mov -8(%%rsp), %%"REG_a" \n\t"
-"mov %%"REG_a", %6\n\t"
-#endif
-#else
#if ARCH_X86_64
"mov -8(%%rsp), %%"REG_a" \n\t"
"mov %%"REG_a", %5\n\t"
#endif
-#endif
"pxor %%mm7, %%mm7 \n\t"
"mov %0, %%"REG_c" \n\t"
"mov %1, %%"REG_D" \n\t"
@@ -256,30 +245,16 @@ void ff_hyscale_fast_mmxext(SwsContext *c, int16_t *dst,
CALL_MMXEXT_FILTER_CODE
CALL_MMXEXT_FILTER_CODE
-#if defined(PIC)
-"mov %5, %%"REG_b" \n\t"
-#if ARCH_X86_64
-"mov %6, %%"REG_a" \n\t"
-"mov %%"REG_a", -8(%%rsp) \n\t"
-#endif
-#else
#if ARCH_X86_64
"mov %5, %%"REG_a" \n\t"
"mov %%"REG_a", -8(%%rsp) \n\t"
#endif
-#endif
:: "m" (src), "m" (dst), "m" (filter), "m" (filterPos),
"m" (mmxextFilterCode)
-#if defined(PIC)
- ,"m" (ebxsave)
-#endif
#if ARCH_X86_64
,"m"(retsave)
#endif
-: "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D
-#if !defined(PIC)
- ,"%"REG_b
-#endif
+: "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D ,"%"REG_b
);
for (i=dstWidth-1; (i*xInc)>>16 >=srcW-1; i--)
@@ -294,26 +269,15 @@ void ff_hcscale_fast_mmxext(SwsContext *c, int16_t *dst1, int16_t *dst2,
int16_t *filter= c->hChrFilter;
void*mmxextFilterCode = c->chrMmxextFilterCode;
int i;
-#if defined(PIC)
-DECLARE_ALIGNED(8, uint64_t, ebxsave);
-#endif
#if ARCH_X86_64
DECLARE_ALIGNED(8, uint64_t, retsave);
#endif
__asm__ volatile(
-#if defined(PIC)
-"mov %%"REG_b", %7 \n\t"
-#if ARCH_X86_64
-"mov -8(%%rsp), %%"REG_a" \n\t"
-"mov %%"REG_a", %8 \n\t"
-#endif
-#else
#if ARCH_X86_64
"mov -8(%%rsp), %%"REG_a" \n\t"
"mov %%"REG_a", %7 \n\t"
#endif
-#endif
"pxor %%mm7, %%mm7 \n\t"
"mov %0, %%"REG_c" \n\t"
"mov %1, %%"REG_D" \n\t"
@@ -340,30 +304,16 @@ void ff_hcscale_fast_mmxext(SwsContext *c, int16_t *dst1, int16_t *dst2,
CALL_MMXEXT_FILTER_CODE
CALL_MMXEXT_FILTER_CODE
-#if defined(PIC)
-"mov %7, %%"REG_b"\n\t"
-#if ARCH_X86_64
-"mov %8, %%"REG_a" \n\t"
-"mov %%"REG_a", -8(%%rsp) \n\t"
-#endif
-#else
#if ARCH_X86_64
"mov %7, %%"REG_a" \n\t"
"mov %%"REG_a", -8(%%rsp) \n\t"
#endif
-#endif
:: "m" (src1), "m" (dst1), "m" (filter), "m" (filterPos),
"m" (mmxextFilterCode), "m" (src2), "m"(dst2)
-#if defined(PIC)
- ,"m" (ebxsave)
-#endif
#if ARCH_X86_64
,"m"(retsave)
#endif
-: "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D
-#if !defined(PIC)
- ,"%"REG_b
-#endif
+: "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D ,"%"REG_b
);
for (i=dstWidth-1; (i*xInc)>>16 >=srcW-1; i--) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
Nick Lewycky google.com> writes: > This occurs when building ffmpeg with clang > -fsanitize=address -O1 -fPIE. What is the usecase for -O1? Did you check performance with and without your patch? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 6 May 2015 at 11:58, Carl Eugen Hoyos wrote: > Nick Lewycky google.com> writes: > > > This occurs when building ffmpeg with clang > > -fsanitize=address -O1 -fPIE. > > What is the usecase for -O1? > It's very important for asan. ASan instruments every memory access (outside inline asm, for now) and if we don't run the optimizer then every local variable is a stack allocation with loads and stores, and all those loads and stores get instrumented leading to both crazy slowdown and binary size increase. Did you check performance with and without your patch? > No. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Hi, On Wed, May 6, 2015 at 2:00 PM, Carl Eugen Hoyos wrote: > Ronald S. Bultje gmail.com> writes: > > > Overall, the effect would be minor, like in the lower > > single-digit percents or perhaps even fractional percent, > > but I would absolutely expect a small performance gain > > from using p10/p12 over p16 w/ bits_per_coded_sample. > > Also note most of this would only be noticeable after > > simd optimizations; in C there would be no difference. > > Thank you for the explanation! > > I still wonder if it was a good idea to add the > formats >8 and <16... I think the biggest issue with going with 16 and using bits_per_coded_sample, is to enforce that the lowest bits are actually zero. In practice, what I foresee is that every DSP operation would spend a two cycles per set of pixels to downshift and upshift, or a few (I don't know exactly how many) cycles to mask the lowest bits to zero (like val &= 0xffc0 for 10 bpp) every time the codec ABI requires it. For older codecs where exact reconstruction isn't defined (like MPEG-1/2), this wouldn't matter, but for h264, hevc, vp9 and alike codecs, this would be a headache, not so much just in terms of performance, but in terms of actually getting the decoder to work (or the encoder to produce optimal results, which might be even harder). Having said that, I agree having 100s of AV_PIX_FMT_ defines isn't ideal either. I wish there was a different way, but I can't really think of from the top of my head. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Test case for Closed caption decoder.
On 05/06/2015 01:21 AM, Michael Niedermayer wrote: On Tue, May 05, 2015 at 08:33:42PM +0530, Anshul wrote: [...] and here is shorter file then previous one. http://gsocdev.ccextractor.org/~anshul/test_video/Closedcaption_atsc_rollup.ts considering that this is created by FFmpeg Metadata: service_name: Service01 service_provider: FFmpeg please make a smaller file I cant encode any video with subtitle, I used ffmpeg to cut the previous video in smaller video. if I transcode the video then cc will be lost. this is still 16 times larger than the next largest file in fate/sub the video streams bitrate should play no role in testing the subtites I searched for other opensource encoder that could embed cc in videos. but I was unable to find out. if you know about any openSource cc encoder. then please share. thanks [...] ___ 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]qdraw autodetection
Hi!
Attached patch allows the autodetection of qdraw images
as decoded by libavcodec.
Please comment, Carl Eugen
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8d9a770..bca9d5b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -206,6 +206,7 @@ OBJS-$(CONFIG_IMAGE_JPEG_PIPE_DEMUXER)+= img2dec.o
img2.o
OBJS-$(CONFIG_IMAGE_JPEGLS_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PICTOR_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_PNG_PIPE_DEMUXER) += img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_QDRAW_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e6a9d01..0f53d4c 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -339,6 +339,7 @@ void av_register_all(void)
REGISTER_DEMUXER (IMAGE_JPEGLS_PIPE, image_jpegls_pipe);
REGISTER_DEMUXER (IMAGE_PICTOR_PIPE, image_pictor_pipe);
REGISTER_DEMUXER (IMAGE_PNG_PIPE,image_png_pipe);
+REGISTER_DEMUXER (IMAGE_QDRAW_PIPE, image_qdraw_pipe);
REGISTER_DEMUXER (IMAGE_SGI_PIPE,image_sgi_pipe);
REGISTER_DEMUXER (IMAGE_SUNRAST_PIPE,image_sunrast_pipe);
REGISTER_DEMUXER (IMAGE_TIFF_PIPE, image_tiff_pipe);
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 5fc5b83..c744094 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -707,6 +707,15 @@ static int jpegls_probe(AVProbeData *p)
return 0;
}
+static int qdraw_probe(AVProbeData *p)
+{
+const uint8_t *b = p->buf;
+
+if (b[10] || AV_RB32(b+11) != 0x1102ff0c || b[15])
+return 0;
+return AVPROBE_SCORE_EXTENSION + 1;
+}
+
static int pictor_probe(AVProbeData *p)
{
const uint8_t *b = p->buf;
@@ -793,6 +802,7 @@ IMAGEAUTO_DEMUXER(jpeg,AV_CODEC_ID_MJPEG)
IMAGEAUTO_DEMUXER(jpegls, AV_CODEC_ID_JPEGLS)
IMAGEAUTO_DEMUXER(pictor, AV_CODEC_ID_PICTOR)
IMAGEAUTO_DEMUXER(png, AV_CODEC_ID_PNG)
+IMAGEAUTO_DEMUXER(qdraw, AV_CODEC_ID_QDRAW)
IMAGEAUTO_DEMUXER(sgi, AV_CODEC_ID_SGI)
IMAGEAUTO_DEMUXER(sunrast, AV_CODEC_ID_SUNRAST)
IMAGEAUTO_DEMUXER(tiff,AV_CODEC_ID_TIFF)
diff --git a/libavformat/version.h b/libavformat/version.h
index 976fa60..6373017 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,8 +30,8 @@
#include "libavutil/version.h"
#define LIBAVFORMAT_VERSION_MAJOR 56
-#define LIBAVFORMAT_VERSION_MINOR 31
-#define LIBAVFORMAT_VERSION_MICRO 102
+#define LIBAVFORMAT_VERSION_MINOR 32
+#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
Nick Lewycky google.com> writes: > On 6 May 2015 at 11:58, Carl Eugen Hoyos: > > > Nick Lewycky google.com> writes: > > > > > This occurs when building ffmpeg with clang > > > -fsanitize=address -O1 -fPIE. > > > > What is the usecase for -O1? > > It's very important for asan. ASan instruments > every memory access (outside inline asm, for now) > and if we don't run the optimizer then every local > variable is a stack allocation with loads and > stores, and all those loads and stores get > instrumented leading to both crazy slowdown and > binary size increase. What I meant was (and I believe I wasn't clear): What is the usecase for -O1 as opposed to default optimization? Or in other words: Is the issue with clang also reproducible with -O2 and -O3? > > Did you check performance with and without > > your patch? > > No. I believe such a performance test is a precondition for an asm patch (but I am not the maintainer). Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Ronald S. Bultje gmail.com> writes: > > I still wonder if it was a good idea to add the > > formats >8 and <16... > > I think the biggest issue with going with 16 and > using bits_per_coded_sample, is to enforce that > the lowest bits are actually zero. I think this shouldn't be enforced. Iirc, one issue is that libx264 expects these pix_fmts and would have to transform the input if FFmpeg would not support them. >From a (very) quick look, this seems to be different with libvpx or did I misread your patch? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Hi, On Wed, May 6, 2015 at 4:28 PM, Carl Eugen Hoyos wrote: > Ronald S. Bultje gmail.com> writes: > > > > I still wonder if it was a good idea to add the > > > formats >8 and <16... > > > > I think the biggest issue with going with 16 and > > using bits_per_coded_sample, is to enforce that > > the lowest bits are actually zero. > > I think this shouldn't be enforced. > > Iirc, one issue is that libx264 expects these > pix_fmts and would have to transform the input > if FFmpeg would not support them. > From a (very) quick look, this seems to be > different with libvpx or did I misread your > patch? upper bits are zero in libvpx, so it uses formats that are analogous to our p10/p12 pixfmts. It (confusingly) calls the formats p16 in its internal API, and sets bits_per_sample, but this has the exact opposite meaning of what it means in ffmpeg... Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Test case for Closed caption decoder.
Michael Niedermayer niedermayer.cc> writes: > please make a smaller file > this is still 16 times larger than the next > largest file in fate/sub I uploaded a 1.5M file: http://www.datafilehost.com/d/02ce0ef8 $ ffmpeg -i Closedcaption_rollup.ts -vcodec copy -ss 37 -t 5 out.m2v If newline testing is not necessary, it can be made smaller. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/9] vp9: add keyframe profile 2/3 support.
Ronald S. Bultje gmail.com> writes: > upper bits are zero in libvpx, so it uses formats > that are analogous to our p10/p12 pixfmts. It > (confusingly) calls the formats p16 in its internal > API, and sets bits_per_sample, but this has the exact > opposite meaning of what it means in ffmpeg... Cool! Thank you for the explanation, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]qdraw autodetection
On Wed, May 06, 2015 at 10:05:29PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch allows the autodetection of qdraw images > as decoded by libavcodec. > > Please comment, Carl Eugen > Makefile |1 + > allformats.c |1 + > img2dec.c| 10 ++ > version.h|4 ++-- > 4 files changed, 14 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffserver jpg patch
Patch looks OK at a first glance. Any chance you can attach the relevant feed and stream sections of the ffserver.conf file you used in your tests? Also, it would be great if you can use git format-patch with your email/name so we can preserve autorship information on the commit. Bests, -- Reynaldo H. Verdejo Pinochet Open Source Group Samsung Research America / Silicon Valley ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Also support real-world qdraw samples
Hi!
Attached patch allows decoding of the qdraw files I found.
Please comment, Carl Eugen
diff --git a/libavcodec/qdrw.c b/libavcodec/qdrw.c
index b650ade..b7a7cf5 100644
--- a/libavcodec/qdrw.c
+++ b/libavcodec/qdrw.c
@@ -124,6 +124,10 @@ static int decode_frame(AVCodecContext *avctx,
int w, h, ret;
bytestream2_init(&gbc, avpkt->data, avpkt->size);
+if ( avpkt->size >= 552
+&& AV_RB32(&avpkt->data[ 10]) != 0x001102FF
+&& AV_RB32(&avpkt->data[522]) == 0x001102FF)
+bytestream2_skip(&gbc, 512);
/* smallest PICT header */
if (bytestream2_get_bytes_left(&gbc) < 40) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 6 May 2015 at 13:08, Carl Eugen Hoyos wrote: > Nick Lewycky google.com> writes: > > > On 6 May 2015 at 11:58, Carl Eugen Hoyos: > > > > > Nick Lewycky google.com> writes: > > > > > > > This occurs when building ffmpeg with clang > > > > -fsanitize=address -O1 -fPIE. > > > > > > What is the usecase for -O1? > > > > It's very important for asan. ASan instruments > > every memory access (outside inline asm, for now) > > and if we don't run the optimizer then every local > > variable is a stack allocation with loads and > > stores, and all those loads and stores get > > instrumented leading to both crazy slowdown and > > binary size increase. > > What I meant was (and I believe I wasn't clear): > What is the usecase for -O1 as opposed to default > optimization? > Or in other words: Is the issue with clang also > reproducible with -O2 and -O3? > Oh I see. Yes, it does. I happened to use clang -O1 because that's our normal "unoptimized" ASan configuration where I first found the bug. I assume it doesn't happen at -O0 but I haven't checked, it does happen at higher optimization levels too. > > Did you check performance with and without > > > your patch? > > > > No. > > I believe such a performance test is a precondition > for an asm patch (but I am not the maintainer). > I'm new here, I don't even know to test ffmpeg performance. I'm happy to run something if you have a suggestion? My two arguments are that correctness trumps performance (otherwise ffmpeg could be "return 0" -- don't tempt me, I'm already a compiler optimization engineer ;-) ), and that this is exactly what ffmpeg already did with PIC disabled. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
Hi On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: > Newer versions of clang will allocate %rbx as one of the inline asm inputs, Thats great > even in PIC. This occurs when building ffmpeg with clang -fsanitize=address > -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, just > include %bx in the clobber list regardless of whether PIC is on or off. you cant include *bx in the clobber list with PIC it breaks compilers that are less great, like gcc gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hyscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ ../libswscale/x86/hscale_fast_bilinear_simd.c: In function ‘ff_hcscale_fast_mmxext’: ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register clobbered by ‘%ebx’ in ‘asm’ also what exactly are you trying to fix ? or rather what exactly goes how exactly wrong with the code as it is if rbx is used ? also ideally changes to this code should be tested against gcc/clang/icc of various versions with and without PIC, 32 and 64 bit this code is more tricky than than the average so theres a good change changes to it will break some compiler [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Test case for Closed caption decoder.
On Thu, May 07, 2015 at 01:29:11AM +0530, Anshul wrote: > > > On 05/06/2015 01:21 AM, Michael Niedermayer wrote: > >On Tue, May 05, 2015 at 08:33:42PM +0530, Anshul wrote: > >[...] > >>and here is shorter file then previous one. > >>http://gsocdev.ccextractor.org/~anshul/test_video/Closedcaption_atsc_rollup.ts > >considering that this is created by FFmpeg > > Metadata: > > service_name: Service01 > > service_provider: FFmpeg > > > >please make a smaller file > I cant encode any video with subtitle, I used ffmpeg to cut the > previous video in smaller video. > if I transcode the video then cc will be lost. > >this is still 16 times larger than the next largest file in > >fate/sub > > > >the video streams bitrate should play no role in testing the subtites > I searched for other opensource encoder that could embed cc in videos. > but I was unable to find out. if you know about any openSource cc encoder. > then please share. i thought it was easy if not then lets upload carls file, its the smallest so far, if that file works for your test ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Also support real-world qdraw samples
On Wed, May 06, 2015 at 11:11:53PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch allows decoding of the qdraw files I found. > > Please comment, Carl Eugen if that works, i guess its an improvment and should be ok [...] -- 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] ffserver jpg patch
File /tmp/cam.ffm #when remarked, no file is beeing created and the stream keeps working!! FileMaxSize 400K # Only allow connections from localhost to the feed. ACL allow 127.0.0.1 ACL allow 192.168.1.2 192.168.1.49 Feed cam.ffm Format jpeg VideoFrameRate 2 VideoIntraOnly VideoQmin 1 VideoQMax 5 VideoSize 960x720 NoAudio Strict -1 For the authorship, I didn't make the patch, so I don't think I can be author. Can you edit in the guy who originally submitted the patch from http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2006-June/013107.html ? Patch looks OK at a first glance. Any chance you can attach the relevant feed and stream sections of the ffserver.conf file you used in your tests? Also, it would be great if you can use git format-patch with your email/name so we can preserve autorship information on the commit. Bests, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On 6 May 2015 at 15:06, Michael Niedermayer wrote: > Hi > > On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: > > Newer versions of clang will allocate %rbx as one of the inline asm > inputs, > > Thats great > > > > even in PIC. This occurs when building ffmpeg with clang > -fsanitize=address > > -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, > just > > include %bx in the clobber list regardless of whether PIC is on or off. > > you cant include *bx in the clobber list with PIC > it breaks compilers that are less great, like gcc > Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 > ../libswscale/x86/hscale_fast_bilinear_simd.c: In function > ‘ff_hyscale_fast_mmxext’: > ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register > clobbered by ‘%ebx’ in ‘asm’ > ../libswscale/x86/hscale_fast_bilinear_simd.c: In function > ‘ff_hcscale_fast_mmxext’: > ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register > clobbered by ‘%ebx’ in ‘asm’ > > > also what exactly are you trying to fix ? > or rather what exactly goes how exactly wrong with the code as it is > if rbx is used ? > Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated in PIC x86-64, the inline constraints work out to: :: "m" (src1), "m" (dst1), "m" (filter), "m" (filterPos), "m" (mmxextFilterCode), "m" (src2), "m"(dst2) ,"m" (ebxsave) ,"m"(retsave) : "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D so clang looks at that and decides that it can pick src1 = (%r10), dst1 = (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem there is src2 being (%rbx). Now let's look at how we use them: "mov %0, %%"REG_c" \n\t" "mov %1, %%"REG_D" \n\t" "mov %2, %%"REG_d" \n\t" "mov %3, %%"REG_b" \n\t" // Clobbers %rbx / src2 / %5 here "xor %%"REG_a", %%"REG_a" \n\t" PREFETCH" (%%"REG_c") \n\t" PREFETCH" 32(%%"REG_c") \n\t" PREFETCH" 64(%%"REG_c") \n\t" CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE CALL_MMXEXT_FILTER_CODE "xor %%"REG_a", %%"REG_a" \n\t" "mov %5, %%"REG_c" \n\t" // %5 is read too late, we get %3 / filterPos instead "mov %6, %%"REG_D" \n\t" PREFETCH" (%%"REG_c") \n\t" PREFETCH" 32(%%"REG_c") \n\t" PREFETCH" 64(%%"REG_c") \n\t" CALL_MMXEXT_FILTER_CODE // Crash... The two marked instructions are intended to refer to different contents. CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: "movl(%%"REG_b"), %%esi \n\t"\ "call*%4\n\t"\ // Crash... That callee ultimately segfaults: => 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 => 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 Program received signal SIGSEGV, Segmentation fault. 0x7fffefa45004 in ?? () => 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 I'm trying to fix this segfault. also ideally changes to this code should be tested against gcc/clang/icc > of various versions with and without PIC, 32 and 64 bit > this code is more tricky than than the average so theres a good > change changes to it will break some compiler > I understand that, but I may not be able to test as many environments as you like. I'm going to give testing it my best effort, but I can tell you up front that I'm only going to test gcc and clang, on an x86 Ubuntu machine. I don't have ICC, so I can't test that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ff_h[yc]scale_fast_mmext always clobbers %rbx
On Wed, May 06, 2015 at 04:08:09PM -0700, Nick Lewycky wrote: > On 6 May 2015 at 15:06, Michael Niedermayer wrote: > > > Hi > > > > On Wed, May 06, 2015 at 11:52:59AM -0700, Nick Lewycky wrote: > > > Newer versions of clang will allocate %rbx as one of the inline asm > > inputs, > > > > Thats great > > > > > > > even in PIC. This occurs when building ffmpeg with clang > > -fsanitize=address > > > -O1 -fPIE. Because the asm does clobber %bx whether PIC is on or off, > > just > > > include %bx in the clobber list regardless of whether PIC is on or off. > > > > you cant include *bx in the clobber list with PIC > > it breaks compilers that are less great, like gcc > > > > Doh!! I did check for this, but only tried x86-64, not x86-32. Sorry! > > gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 > > ../libswscale/x86/hscale_fast_bilinear_simd.c: In function > > ‘ff_hyscale_fast_mmxext’: > > ../libswscale/x86/hscale_fast_bilinear_simd.c:205:5: error: PIC register > > clobbered by ‘%ebx’ in ‘asm’ > > ../libswscale/x86/hscale_fast_bilinear_simd.c: In function > > ‘ff_hcscale_fast_mmxext’: > > ../libswscale/x86/hscale_fast_bilinear_simd.c:276:5: error: PIC register > > clobbered by ‘%ebx’ in ‘asm’ > > > > > > also what exactly are you trying to fix ? > > or rather what exactly goes how exactly wrong with the code as it is > > if rbx is used ? > > > > Ok, let's look at ff_hcscale_fast_mmext. Preprocessor directives evaluated > in PIC x86-64, the inline constraints work out to: > > :: "m" (src1), "m" (dst1), "m" (filter), "m" (filterPos), >"m" (mmxextFilterCode), "m" (src2), "m"(dst2) > ,"m" (ebxsave) > ,"m"(retsave) > : "%"REG_a, "%"REG_c, "%"REG_d, "%"REG_S, "%"REG_D > > so clang looks at that and decides that it can pick src1 = (%r10), dst1 = > (%r8), filter = (%r11), filterPos = (%r12), mmxextFilterCode = (%r15), src2 > = (%rbx), dst2 = (%r14), ebxsave = (%r13), retsave = (%r9). The problem > there is src2 being (%rbx). > > Now let's look at how we use them: > > "mov %0, %%"REG_c" \n\t" > "mov %1, %%"REG_D" \n\t" > "mov %2, %%"REG_d" \n\t" > "mov %3, %%"REG_b" \n\t" // Clobbers %rbx / src2 > / %5 here > "xor %%"REG_a", %%"REG_a" \n\t" > PREFETCH" (%%"REG_c") \n\t" > PREFETCH" 32(%%"REG_c") \n\t" > PREFETCH" 64(%%"REG_c") \n\t" > > CALL_MMXEXT_FILTER_CODE > CALL_MMXEXT_FILTER_CODE > CALL_MMXEXT_FILTER_CODE > CALL_MMXEXT_FILTER_CODE > "xor %%"REG_a", %%"REG_a" \n\t" > "mov %5, %%"REG_c" \n\t" // %5 is read too late, > we get %3 / filterPos instead > "mov %6, %%"REG_D" \n\t" > PREFETCH" (%%"REG_c") \n\t" > PREFETCH" 32(%%"REG_c") \n\t" > PREFETCH" 64(%%"REG_c") \n\t" > > CALL_MMXEXT_FILTER_CODE // Crash... > > The two marked instructions are intended to refer to different contents. > CALL_MMXEXT_FILTER_CODE moves RBX to ESI and calls mmxextFilterCode: > > "movl(%%"REG_b"), %%esi \n\t"\ > "call*%4\n\t"\ // Crash... > > That callee ultimately segfaults: > > => 0x7fffefa45000: movq (%rdx,%rax,1),%mm3 > => 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 > Program received signal SIGSEGV, Segmentation fault. > 0x7fffefa45004 in ?? () > => 0x7fffefa45004: movd (%rcx,%rsi,1),%mm0 > > I'm trying to fix this segfault. > > also ideally changes to this code should be tested against gcc/clang/icc > > of various versions with and without PIC, 32 and 64 bit > > this code is more tricky than than the average so theres a good > > change changes to it will break some compiler > > > > I understand that, but I may not be able to test as many environments as > you like. I'm going to give testing it my best effort, but I can tell you > up front that I'm only going to test gcc and clang, on an x86 Ubuntu > machine. I don't have ICC, so I can't test that. iam not sure it would work but, configure could easily test if ebx can be put on the clobber list and that then could be used in place of PIC in the checks and thanks for the detailed informaion [...] -- 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
[FFmpeg-devel] [PATCH 1/2] avformat/mxf: Simplify PRINT_KEY()
Signed-off-by: Michael Niedermayer --- libavformat/mxf.h | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/libavformat/mxf.h b/libavformat/mxf.h index 71a4084..dd08bdc 100644 --- a/libavformat/mxf.h +++ b/libavformat/mxf.h @@ -102,22 +102,14 @@ const MXFSamplesPerFrame *ff_mxf_get_samples_per_frame(AVFormatContext *s, AVRat "0x%02x,0x%02x,0x%02x,0x%02x," \ "0x%02x,0x%02x,0x%02x,0x%02x," \ "0x%02x,0x%02x,0x%02x,0x%02x ", \ -s, \ -(x)[0], (x)[1], (x)[2], (x)[3], \ -(x)[4], (x)[5], (x)[6], (x)[7], \ -(x)[8], (x)[9], (x)[10], (x)[11], \ -(x)[12], (x)[13], (x)[14], (x)[15]);\ +s, UID_ARG(x)); \ av_log(pc, AV_LOG_INFO, \ "%s "\ "%02x.%02x.%02x.%02x." \ "%02x.%02x.%02x.%02x." \ "%02x.%02x.%02x.%02x." \ "%02x.%02x.%02x.%02x\n", \ -s, \ -(x)[0], (x)[1], (x)[2], (x)[3], \ -(x)[4], (x)[5], (x)[6], (x)[7], \ -(x)[8], (x)[9], (x)[10], (x)[11], \ -(x)[12], (x)[13], (x)[14], (x)[15]) +s, UID_ARG(x)) #else #define PRINT_KEY(pc, s, x) #endif -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/mxf: Always evaluate PRINT_KEY() arguments at compile time
Signed-off-by: Michael Niedermayer
---
libavformat/mxf.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index dd08bdc..1763063 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -111,7 +111,15 @@ const MXFSamplesPerFrame
*ff_mxf_get_samples_per_frame(AVFormatContext *s, AVRat
"%02x.%02x.%02x.%02x\n", \
s, UID_ARG(x))
#else
-#define PRINT_KEY(pc, s, x)
+#define PRINT_KEY(pc, s, x) do { if(0) \
+av_log(pc, AV_LOG_VERBOSE, \
+ "%s "\
+ "0x%02x,0x%02x,0x%02x,0x%02x," \
+ "0x%02x,0x%02x,0x%02x,0x%02x," \
+ "0x%02x,0x%02x,0x%02x,0x%02x," \
+ "0x%02x,0x%02x,0x%02x,0x%02x ", \
+s, UID_ARG(x)); \
+}while(0)
#endif
#endif /* AVFORMAT_MXF_H */
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: replace arch loongson with arch extra list loongson
> -原始邮件- > 发件人: "Michael Niedermayer" > 发送时间: 2015年5月6日 星期三 > 收件人: "FFmpeg development discussions and patches" > 抄送: gaoxiang , "孟小甫" > 主题: Re: [FFmpeg-devel] [PATCH] configure: replace arch loongson with arch > extra list loongson > > On Wed, May 06, 2015 at 02:38:21PM +0800, 周晓勇 wrote: > > From a5031b4c4b97f790a40603cff9a1f45cbb043005 Mon Sep 17 00:00:00 2001 > > From: ZhouXiaoyong > > Date: Wed, 6 May 2015 14:05:21 +0800 > > Subject: [PATCH] configure: replace arch loongson with arch extra list > > loongson > > > > fate pass when do configure without --cc='ccache gcc' option: > > ./configure --enable-gpl --enable-pthreads --samples=/home/loongson/fate/ > > --enable-nonfree --enable-version3 --assert-level=2 --cpu=loongson3a > > --enable-loongson3 > > with this ARCH_MIPS64 is disabled, is this intended ? > ARCH_MIPS64 only be used in libavutil/mips/intereadwrite.h for AV_RN32. i mean to not disturb other MIPS64 machines, and Loongson's optimization maybe not compatible for other MIPS64 before tested. as i have no MIPS64 machine expect Loongson3 for testing. In my personal git-devel branch, i have optimized the other funcs for Loongson-3, such as AV_WN32, AV_RN64, AV_WN64, AV_COPY32, AV_COPY64, AV_SWAP64, AV_ZERO32, AV_ZERO_64. But, its boost gain little than anticipant. i will do more test to make sure the optimized intreadwrite boost truely, then send u the patch. > why is "--enable-loongson3" needed when "--cpu=loongson3a" is already > specified ? > no need, i just add on to make sure the SIMD optimization enabled. > and fate still fails > time ./configure --enable-gpl --enable-pthreads > --samples=/home/loongson/fate/ --enable-nonfree --enable-version3 > --assert-level=2 --cpu=loongson3a --enable-loongson3 > real4m48.779s > user4m13.918s > sys 0m40.020s > > time make -j4 > real19m31.114s > user57m52.785s > sys 2m52.359s > > make -j5 fate-vsynth1-rv10 fate-vsynth1-svq1 fate-amrwb-23k85 fate-dss-lp > fate-lavf-avi > > --- ./tests/ref/fate/dss-lp 2015-05-06 01:16:58.238387245 +0800 > +++ tests/data/fate/dss-lp 2015-05-06 20:15:23.060689405 +0800 > @@ -1,31 +1,31 @@ > #tb 0: 1/8000 > -0, 0, 0, 240, 480, 0xf1107658 > -0,240,240, 240, 480, 0x50dee179 > -0,480,480, 240, 480, 0x40090802 > -0,720,720, 240, 480, 0x3ef9f6ff > -0,960,960, 240, 480, 0x5b7df231 > -0, 1200, 1200, 240, 480, 0xe266efd1 > -0, 1440, 1440, 240, 480, 0xfbe6e658 > -0, 1680, 1680, 240, 480, 0xde84f311 > -0, 1920, 1920, 240, 480, 0x5854ec2f > -0, 2160, 2160, 240, 480, 0x4901cdea > -0, 2400, 2400, 240, 480, 0x03f3e619 > -0, 2640, 2640, 240, 480, 0x47abfe87 > -0, 2880, 2880, 240, 480, 0x69dddf34 > -0, 3120, 3120, 240, 480, 0x1cfeee2c > -0, 3360, 3360, 240, 480, 0x1860ef1c > -0, 3600, 3600, 240, 480, 0x8f86e8ed > -0, 3840, 3840, 240, 480, 0x307deaf8 > -0, 4080, 4080, 240, 480, 0xeca7eca0 > -0, 4320, 4320, 240, 480, 0x1835ee1c > -0, 4560, 4560, 240, 480, 0x6676ed66 > -0, 4800, 4800, 240, 480, 0x49c2fd04 > -0, 5040, 5040, 240, 480, 0xc463db75 > -0, 5280, 5280, 240, 480, 0x1931ed7d > -0, 5520, 5520, 240, 480, 0xc99ff886 > -0, 5760, 5760, 240, 480, 0xcd3ae8de > -0, 6000, 6000, 240, 480, 0x2294ecfa > -0, 6240, 6240, 240, 480, 0xcf5ef14b > -0, 6480, 6480, 240, 480, 0x6325d4fe > -0, 6720, 6720, 240, 480, 0x3790dcf2 > -0, 6960, 6960, 240, 480, 0x0fbee6c0 > +0, 0, 0, 240, 480, 0x4f3de452 > +0,240,240, 240, 480, 0x55d1f9da > +0,480,480, 240, 480, 0xe887e1f6 > +0,720,720, 240, 480, 0xc353f768 > +0,960,960, 240, 480, 0x34adebcc > +0, 1200, 1200, 240, 480, 0x7d67dfa2 > +0, 1440, 1440, 240, 480, 0xc7a4f1f4 > +0, 1680, 1680, 240, 480, 0x549cf083 > +0, 1920, 1920, 240, 480, 0x468dead7 > +0, 2160, 2160, 240, 480, 0x7e6af748 > +0, 2400, 2400, 240, 480, 0x02f20456 > +0, 2640, 2640, 240, 480, 0xb9d5eb37 > +0, 2880, 2880, 240, 480, 0x008cee35 > +0, 3120, 3120, 240, 480, 0xdd13f6c0 > +0, 3360, 3360, 240, 480, 0xaa0df718 > +0, 3600, 3600, 240, 480, 0x0a84ee9c
Re: [FFmpeg-devel] [PATCH] configure: replace arch loongson with arch extra list loongson
On Wed, May 06, 2015 at 02:38:21PM +0800, 周晓勇 wrote:
> From a5031b4c4b97f790a40603cff9a1f45cbb043005 Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong
> Date: Wed, 6 May 2015 14:05:21 +0800
> Subject: [PATCH] configure: replace arch loongson with arch extra list
> loongson
>
> fate pass when do configure without --cc='ccache gcc' option:
> ./configure --enable-gpl --enable-pthreads --samples=/home/loongson/fate/
> --enable-nonfree --enable-version3 --assert-level=2 --cpu=loongson3a
> --enable-loongson3
>
> Signed-off-by: ZhouXiaoyong
> ---
> configure | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/configure b/configure
> index d3f23c8..0f79874 100755
> --- a/configure
> +++ b/configure
> @@ -1577,6 +1577,9 @@ ARCH_EXT_LIST_MIPS="
> mipsdspr1
> mipsdspr2
> msa
> +"
> +
> +ARCH_EXT_LIST_LOONGSON="
> loongson3
> "
>
> @@ -1617,7 +1620,7 @@ ARCH_EXT_LIST="
> $ARCH_EXT_LIST_PPC
> $ARCH_EXT_LIST_X86
> $ARCH_EXT_LIST_MIPS
> -loongson
> +$ARCH_EXT_LIST_LOONGSON
> "
>
> ARCH_FEATURES="
> @@ -2018,7 +2021,6 @@ setend_deps="arm"
>
> map 'eval ${v}_inline_deps=inline_asm' $ARCH_EXT_LIST_ARM
>
> -loongson_deps="mips"
> mipsfpu_deps="mips"
> mipsdspr1_deps="mips"
> mipsdspr2_deps="mips"
> @@ -4686,8 +4688,6 @@ EOF
>
> elif enabled mips; then
>
> -check_inline_asm loongson '"dmult.g $1, $2, $3"'
> -
these 2 hunks are unrelated to the first 2
they should be in a seperate patch
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ripemd: move ripemd{256, 320} into separate functions
This allows the removal of a few branches.
Before:
lavu RIPEMD-160 size: 1048576 runs: 1024 time:7.052 +- 0.010
After:
lavu RIPEMD-160 size: 1048576 runs: 1024 time:6.865 +- 0.015
Signed-off-by: James Almer
---
libavutil/ripemd.c | 354 +
1 file changed, 222 insertions(+), 132 deletions(-)
diff --git a/libavutil/ripemd.c b/libavutil/ripemd.c
index 1ceb24b..0084860 100644
--- a/libavutil/ripemd.c
+++ b/libavutil/ripemd.c
@@ -34,9 +34,8 @@ typedef struct AVRIPEMD {
uint64_t count; ///< number of bytes in buffer
uint8_t buffer[64]; ///< 512-bit buffer of input values used in hash
updating
uint32_t state[10]; ///< current hash value
-uint8_t ext; ///< extension (0 for 128 and 160, 1 for 256 and 320)
/** function used to update hash for 512-bit input block */
-void (*transform)(uint32_t *state, const uint8_t buffer[64], int ext);
+void (*transform)(uint32_t *state, const uint8_t buffer[64]);
} AVRIPEMD;
const int av_ripemd_size = sizeof(AVRIPEMD);
@@ -88,8 +87,6 @@ static const int WB[80] = {
#define rol(value, bits) ((value << bits) | (value >> (32 - bits)))
-#define SWAP(a,b) if (ext) { t = a; a = b; b = t; }
-
#define ROUND128_0_TO_15(a,b,c,d,e,f,g,h) \
a = rol(a + (( b ^ c ^ d) + block[WA[n]]), ROTA[n]); \
e = rol(e + f ^ g) & h) ^ g) + block[WB[n]] + KB[0]), ROTB[n]); \
@@ -110,21 +107,40 @@ static const int WB[80] = {
e = rol(e + (( f ^ g ^ h) + block[WB[n]]), ROTB[n]); \
n++
-static void ripemd128_transform(uint32_t *state, const uint8_t buffer[64], int
ext)
+#define R128_0 \
+ROUND128_0_TO_15(a,b,c,d,e,f,g,h); \
+ROUND128_0_TO_15(d,a,b,c,h,e,f,g); \
+ROUND128_0_TO_15(c,d,a,b,g,h,e,f); \
+ROUND128_0_TO_15(b,c,d,a,f,g,h,e)
+
+#define R128_16 \
+ROUND128_16_TO_31(a,b,c,d,e,f,g,h); \
+ROUND128_16_TO_31(d,a,b,c,h,e,f,g); \
+ROUND128_16_TO_31(c,d,a,b,g,h,e,f); \
+ROUND128_16_TO_31(b,c,d,a,f,g,h,e)
+
+#define R128_32 \
+ROUND128_32_TO_47(a,b,c,d,e,f,g,h); \
+ROUND128_32_TO_47(d,a,b,c,h,e,f,g); \
+ROUND128_32_TO_47(c,d,a,b,g,h,e,f); \
+ROUND128_32_TO_47(b,c,d,a,f,g,h,e)
+
+#define R128_48 \
+ROUND128_48_TO_63(a,b,c,d,e,f,g,h); \
+ROUND128_48_TO_63(d,a,b,c,h,e,f,g); \
+ROUND128_48_TO_63(c,d,a,b,g,h,e,f); \
+ROUND128_48_TO_63(b,c,d,a,f,g,h,e)
+
+static void ripemd128_transform(uint32_t *state, const uint8_t buffer[64])
{
-uint32_t a, b, c, d, e, f, g, h, t;
+uint32_t a, b, c, d, e, f, g, h, av_unused t;
uint32_t block[16];
int n;
-if (ext) {
-a = state[0]; b = state[1]; c = state[2]; d = state[3];
-e = state[4]; f = state[5]; g = state[6]; h = state[7];
-} else {
-a = e = state[0];
-b = f = state[1];
-c = g = state[2];
-d = h = state[3];
-}
+a = e = state[0];
+b = f = state[1];
+c = g = state[2];
+d = h = state[3];
for (n = 0; n < 16; n++)
block[n] = AV_RL32(buffer + 4 * n);
@@ -136,77 +152,100 @@ static void ripemd128_transform(uint32_t *state, const
uint8_t buffer[64], int e
t = d; d = c; c = b; b = a; a = t;
t = h; h = g; g = f; f = e; e = t;
}
-SWAP(a,e)
for (; n < 32;) {
ROUND128_16_TO_31(a,b,c,d,e,f,g,h);
t = d; d = c; c = b; b = a; a = t;
t = h; h = g; g = f; f = e; e = t;
}
-SWAP(b,f)
for (; n < 48;) {
ROUND128_32_TO_47(a,b,c,d,e,f,g,h);
t = d; d = c; c = b; b = a; a = t;
t = h; h = g; g = f; f = e; e = t;
}
-SWAP(c,g)
for (; n < 64;) {
ROUND128_48_TO_63(a,b,c,d,e,f,g,h);
t = d; d = c; c = b; b = a; a = t;
t = h; h = g; g = f; f = e; e = t;
}
-SWAP(d,h)
#else
-#define R128_0 \
-ROUND128_0_TO_15(a,b,c,d,e,f,g,h); \
-ROUND128_0_TO_15(d,a,b,c,h,e,f,g); \
-ROUND128_0_TO_15(c,d,a,b,g,h,e,f); \
-ROUND128_0_TO_15(b,c,d,a,f,g,h,e)
-
R128_0; R128_0; R128_0; R128_0;
-SWAP(a,e)
-
-#define R128_16 \
-ROUND128_16_TO_31(a,b,c,d,e,f,g,h); \
-ROUND128_16_TO_31(d,a,b,c,h,e,f,g); \
-ROUND128_16_TO_31(c,d,a,b,g,h,e,f); \
-ROUND128_16_TO_31(b,c,d,a,f,g,h,e)
R128_16; R128_16; R128_16; R128_16;
-SWAP(b,f)
-
-#define R128_32 \
-ROUND128_32_TO_47(a,b,c,d,e,f,g,h); \
-ROUND128_32_TO_47(d,a,b,c,h,e,f,g); \
-ROUND128_32_TO_47(c,d,a,b,g,h,e,f); \
-ROUND128_32_TO_47(b,c,d,a,f,g,h,e)
R128_32; R128_32; R128_32; R128_32;
-SWAP(c,g)
-
-#define R128_48 \
-ROUND128_48_TO_63(a,b,c,d,e,f,g,h); \
-ROUND128_48_TO_63(d,a,b,c,h,e,f,g); \
-ROUND128_48_TO_63(c,d,a,b,g,h,e,f); \
-ROUND128_4
Re: [FFmpeg-devel] Test case for Closed caption decoder.
On 05/07/2015 03:43 AM, Michael Niedermayer wrote: On Thu, May 07, 2015 at 01:29:11AM +0530, Anshul wrote: On 05/06/2015 01:21 AM, Michael Niedermayer wrote: On Tue, May 05, 2015 at 08:33:42PM +0530, Anshul wrote: [...] and here is shorter file then previous one. http://gsocdev.ccextractor.org/~anshul/test_video/Closedcaption_atsc_rollup.ts considering that this is created by FFmpeg Metadata: service_name: Service01 service_provider: FFmpeg please make a smaller file I cant encode any video with subtitle, I used ffmpeg to cut the previous video in smaller video. if I transcode the video then cc will be lost. this is still 16 times larger than the next largest file in fate/sub the video streams bitrate should play no role in testing the subtites I searched for other opensource encoder that could embed cc in videos. but I was unable to find out. if you know about any openSource cc encoder. then please share. i thought it was easy if not then lets upload carls file, its the smallest so far, if that file works for your test ? Carl, can you please give me link of the sample, I would make the test case patch again. -Anshul ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
