Re: [FFmpeg-devel] [PATCH] lavd/v4l2: do not fail when VIDIOC_ENUMSTD returns ENODATA
On Mon, Aug 18, 2014 at 10:44:03AM +0800, Andre Wolokita wrote: > Fixed parentheses mismatch. > > Signed-off-by: Andre Wolokita --- > libavdevice/v4l2.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied with the previous patches "commit message", as that was more verbose Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] gifdec: use truncated width for image manipulation
Hi,
2014-08-17 23:53 GMT+02:00 Michael Niedermayer :
>> > i think these need a check for top >= s->screen_height and
>> > left >= s->screen_width
[...]
> 0x007319ea in gif_fill_rect (picture=0x1a96a60, color=16777215, l=0,
> t=65535, w=192, h=-65367) at libavcodec/gifdec.c:108
Sorry for missing the obvious, indeed in those cases pw/height would
end negative...
So I have added the checks you propose and decided to shuffle them
with the others.
Updated patch attached.
--
Christophe
From a8a329b19d72405b6cc7de173e3f160be02e212d Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Sun, 17 Aug 2014 09:47:46 +0200
Subject: [PATCH] gifdec: use truncated width for image manipulation
Some files seem to have an off-by-one error. In most cases, it appears to
be on the image width. Therefore, if the decoded image doesn't fit in the
screen:
- If it is wider than the screen (and the lzw decoding buffer), reject it;
- Otherwise, decode the indicated amount, but only write a truncated amount
to the screen.
Fixes ticket #3538.
---
libavcodec/gifdec.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
index 78c8900..dee48f5 100644
--- a/libavcodec/gifdec.c
+++ b/libavcodec/gifdec.c
@@ -129,7 +129,7 @@ static void gif_copy_img_rect(const uint32_t *src, uint32_t *dst,
static int gif_read_image(GifState *s, AVFrame *frame)
{
-int left, top, width, height, bits_per_pixel, code_size, flags;
+int left, top, width, height, bits_per_pixel, code_size, flags, pw;
int is_interleaved, has_local_palette, y, pass, y1, linesize, pal_size;
uint32_t *ptr, *pal, *px, *pr, *ptr1;
int ret;
@@ -179,15 +179,28 @@ static int gif_read_image(GifState *s, AVFrame *frame)
}
/* verify that all the image is inside the screen dimensions */
-if (left + width > s->screen_width ||
-top + height > s->screen_height) {
-av_log(s->avctx, AV_LOG_ERROR, "image is outside the screen dimensions.\n");
+if (!width || width > s->screen_width || left >= s->screen_width) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid image width.\n");
return AVERROR_INVALIDDATA;
}
-if (width <= 0 || height <= 0) {
-av_log(s->avctx, AV_LOG_ERROR, "Invalid image dimensions.\n");
+if (!height || height > s->screen_height || top >= s->screen_height) {
+av_log(s->avctx, AV_LOG_ERROR, "Invalid image height.\n");
return AVERROR_INVALIDDATA;
}
+if (left + width > s->screen_width) {
+/* width must be kept around to avoid lzw vs line desync */
+pw = s->screen_width - left;
+av_log(s->avctx, AV_LOG_WARNING, "Image too wide by %d, truncating.\n",
+ left + width - s->screen_width);
+} else {
+pw = width;
+}
+if (top + height > s->screen_height) {
+/* we don't care about the extra invisible lines */
+av_log(s->avctx, AV_LOG_WARNING, "Image too high by %d, truncating.\n",
+ top + height - s->screen_height);
+height = s->screen_height - top;
+}
/* process disposal method */
if (s->gce_prev_disposal == GCE_DISPOSAL_BACKGROUND) {
@@ -201,7 +214,7 @@ static int gif_read_image(GifState *s, AVFrame *frame)
if (s->gce_disposal != GCE_DISPOSAL_NONE) {
s->gce_l = left; s->gce_t = top;
-s->gce_w = width; s->gce_h = height;
+s->gce_w = pw;s->gce_h = height;
if (s->gce_disposal == GCE_DISPOSAL_BACKGROUND) {
if (s->transparent_color_index >= 0)
@@ -214,7 +227,7 @@ static int gif_read_image(GifState *s, AVFrame *frame)
return AVERROR(ENOMEM);
gif_copy_img_rect((uint32_t *)frame->data[0], s->stored_img,
-frame->linesize[0] / sizeof(uint32_t), left, top, width, height);
+frame->linesize[0] / sizeof(uint32_t), left, top, pw, height);
}
}
@@ -244,7 +257,7 @@ static int gif_read_image(GifState *s, AVFrame *frame)
goto decode_tail;
}
-pr = ptr + width;
+pr = ptr + pw;
for (px = ptr, idx = s->idx_line; px < pr; px++, idx++) {
if (*idx != s->transparent_color_index)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/wavdec: add sanity check for AVCodecContext.channels
On Mon, Aug 18, 2014 at 03:14:01AM -0300, James Almer wrote: > Fixes ticket #3862. > As a side effect, this also fixes aac_latm in wav. > > Signed-off-by: James Almer applied > --- > Maybe a check for channels <= 0 should be also added to ff_get_wav_header() > right after the sample_rate one? sounds reasonable, would need to be tested though 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] x86: hevc: adding transform_add
Hi, here's the new version of the patch. Sorry for the delay. James, I have not done 8-bit AVX versions because it requires unpacks that are done differently in AVX. Thanks for the feedback ! -Pierre-Edouard Leperecommit 414ebcfeb47ea99ac7e8281d2794996d8a2a09fc Author: plepere Date: Wed Jul 30 10:31:49 2014 +0200 adding ASM transform_add functions for HEVC diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile index 7ceb7e2..fbb9abf 100644 --- a/libavcodec/x86/Makefile +++ b/libavcodec/x86/Makefile @@ -131,7 +131,8 @@ YASM-OBJS-$(CONFIG_AAC_DECODER)+= x86/sbrdsp.o YASM-OBJS-$(CONFIG_DCA_DECODER)+= x86/dcadsp.o YASM-OBJS-$(CONFIG_HEVC_DECODER) += x86/hevc_mc.o \ x86/hevc_deblock.o\ - x86/hevc_idct.o + x86/hevc_idct.o \ + x86/hevc_res_add.o YASM-OBJS-$(CONFIG_PNG_DECODER)+= x86/pngdsp.o YASM-OBJS-$(CONFIG_PRORES_DECODER) += x86/proresdsp.o YASM-OBJS-$(CONFIG_PRORES_LGPL_DECODER) += x86/proresdsp.o diff --git a/libavcodec/x86/hevc_res_add.asm b/libavcodec/x86/hevc_res_add.asm new file mode 100644 index 000..e020e1f --- /dev/null +++ b/libavcodec/x86/hevc_res_add.asm @@ -0,0 +1,385 @@ +; /* +; * Provide SIMD optimizations for transform_add functions for HEVC decoding +; * Copyright (c) 2014 Pierre-Edouard LEPERE +; * +; * This file is part of FFmpeg. +; * +; * FFmpeg is free software; you can redistribute it and/or +; * modify it under the terms of the GNU Lesser General Public +; * License as published by the Free Software Foundation; either +; * version 2.1 of the License, or (at your option) any later version. +; * +; * FFmpeg is distributed in the hope that it will be useful, +; * but WITHOUT ANY WARRANTY; without even the implied warranty of +; * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +; * Lesser General Public License for more details. +; * +; * You should have received a copy of the GNU Lesser General Public +; * License along with FFmpeg; if not, write to the Free Software +; * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA +; */ +%include "libavutil/x86/x86util.asm" + +SECTION_RODATA 32 +max_pixels_10: times 16 dw ((1 << 10)-1) + + +SECTION .text + +;the tr_add macros and functions were largely inspired by x264 project's code in the h264_idct.asm file +%macro TR_ADD_MMX_4_8 0 +mova m2, [r1] +mova m4, [r1+8] +pxor m3, m3 +psubw m3, m2 +packuswb m2, m2 +packuswb m3, m3 +pxor m5, m5 +psubw m5, m4 +packuswb m4, m4 +packuswb m5, m5 + +movh m0, [r0 ] +movh m1, [r0+r2 ] +paddusb m0, m2 +paddusb m1, m4 +psubusb m0, m3 +psubusb m1, m5 +movh [r0 ], m0 +movh [r0+r2 ], m1 +%endmacro + + +INIT_MMX mmxext +; void ff_hevc_tranform_add_8_mmxext(uint8_t *dst, int16_t *coeffs, ptrdiff_t stride) +cglobal hevc_transform_add4_8, 3, 4, 6 +TR_ADD_MMX_4_8 +add r1, 16 +lea r0, [r0+r2*2] +TR_ADD_MMX_4_8 +RET + +%macro TR_ADD_SSE_8_8 0 +pxor m3, m3 +mova m4, [r1] +mova m6, [r1+16] +mova m0, [r1+32] +mova m2, [r1+48] +psubw m5, m3, m4 +psubw m7, m3, m6 +psubw m1, m3, m0 +packuswb m4, m0 +packuswb m5, m1 +psubw m3, m2 +packuswb m6, m2 +packuswb m7, m3 + +movqm0, [r0 ] +movqm1, [r0+r2 ] +movhps m0, [r0+r2*2] +movhps m1, [r0+r3 ] +paddusb m0, m4 +paddusb m1, m6 +psubusb m0, m5 +psubusb m1, m7 +movq [r0 ], m0 +movq [r0+r2 ], m1 +movhps [r0+2*r2], m0 +movhps [r0+r3 ], m1 +%endmacro + +%macro TR_ADD_INIT_SSE_8 0 +pxor m0, m0 + +mova m4, [r1] +mova m1, [r1+16] +psubw m2, m0, m1 +psubw m5, m0, m4 +packuswb m4, m1 +packuswb m5, m2 + +mova m6, [r1+32] +mova m1, [r1+48] +psubw m2, m0, m1 +psubw m7, m0, m6 +packuswb m6, m1 +packuswb m7, m2 + +mova m8, [r1+64] +mova m1, [r1+80] +psubw m2, m0, m1 +psubw m9, m0, m8 +packuswb m8, m1 +packuswb m9, m2 + +mova m10, [r1+96] +mova m1, [r1+112] +
Re: [FFmpeg-devel] [PATCH 0/2] Fix ALAC encoder for 24bps
Hi, 2014-08-17 19:09 GMT+02:00 Christophe Gisquet : > It would possible to detect bitstreams before this change and achieve > correct decoding if need be. So after further exploration, you can't really detect this: - there's no metadata for the alac bitstream - the container one may be stripped or added while importing a valid alac bitstream - it may be possible to detect this when an overflow occurs (ie samples have a larger magnitude than expected) but I bet this doesn't always occur - I don't see a crc or whatever allowing to identify if the stream was incorrectly decoded Anyway, it was suggested to add a command-line option to be able to force this. Please confirm the steps needed: - Add a new flag in workaround_bugs (eg FF_BUG_ALAC_MATRIXING valued at 32768) - Add an option for this (in options_table.h) - Bump micro? We're at 56.0.101. Should that become 56.0.102 or 56.1.xx (100? 0?) -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] gifdec: use truncated width for image manipulation
On Mon, Aug 18, 2014 at 09:42:08AM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-17 23:53 GMT+02:00 Michael Niedermayer : > >> > i think these need a check for top >= s->screen_height and > >> > left >= s->screen_width > [...] > > 0x007319ea in gif_fill_rect (picture=0x1a96a60, color=16777215, > > l=0, t=65535, w=192, h=-65367) at libavcodec/gifdec.c:108 > > Sorry for missing the obvious, indeed in those cases pw/height would > end negative... > > So I have added the checks you propose and decided to shuffle them > with the others. > > Updated patch attached. > > -- > Christophe > gifdec.c | 31 ++- > 1 file changed, 22 insertions(+), 9 deletions(-) > 76cade6cedda47f5f98817afa6892a2f64a2692a > 0001-gifdec-use-truncated-width-for-image-manipulation.patch > From a8a329b19d72405b6cc7de173e3f160be02e212d Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Sun, 17 Aug 2014 09:47:46 +0200 > Subject: [PATCH] gifdec: use truncated width for image manipulation > > Some files seem to have an off-by-one error. In most cases, it appears to > be on the image width. Therefore, if the decoded image doesn't fit in the > screen: > - If it is wider than the screen (and the lzw decoding buffer), reject it; > - Otherwise, decode the indicated amount, but only write a truncated amount > to the screen. > > Fixes ticket #3538. patch applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile
Hi,
Ticket #3846 is about an incorrect profile being used:
- The user wants alpha but the profile indicates to software there's no alpha
- Also, the encoder still encodes the alpha channel in spite of the profile
The attached patch is not the most user-friendly, but is preferred by
the encoder author, and has the merit to leave the final decision to
the user.
An alternative would be to select the profile based on the pixel
format. If a user wants to encode without alpha, he would then need to
change the pixel format as well as specify the proper profile, which
may not be obvious to him.
--
Christophe
From d9679c80df991e98b1f00fd15f9c1c3c689ec426 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc_kostya: warn/reject on incorrect profile
This fixes the following situations:
- Reject encoding when profile selected encodes alpha, but the pixel format
does not have an alpha channel;
- Warn if the pixel format has an alpha channel but the profile does not
encode it;
- Do not encode alpha if the profile does not specify it.
---
libavcodec/proresenc_kostya.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 46f81db..d2419e9c 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1145,11 +1145,22 @@ static av_cold int encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
if (av_pix_fmt_desc_get(avctx->pix_fmt)->flags & AV_PIX_FMT_FLAG_ALPHA) {
-if (ctx->alpha_bits & 7) {
+if (ctx->profile != PRORES_PROFILE_) {
+// ignore alpha but warn
+av_log(avctx, AV_LOG_WARNING, "If you want alpha to be encoded,"
+ "please specify -profile \n");
+ctx->alpha_bits = 0;
+}
+else if (ctx->alpha_bits & 7) {
av_log(avctx, AV_LOG_ERROR, "alpha bits should be 0, 8 or 16\n");
return AVERROR(EINVAL);
}
} else {
+if (ctx->profile == PRORES_PROFILE_) {
+av_log(avctx, AV_LOG_ERROR, "attempt to encode alpha while "
+ "content has no alpha\n");
+return AVERROR(EINVAL);
+}
ctx->alpha_bits = 0;
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Replace old cookies with new cookies of the same name
On Sun, Aug 17, 2014 at 9:29 PM, Nicolas George wrote: > Le decadi 30 thermidor, an CCXXII, Micah Galizia a écrit : >> When new cookie values (with the same name as an existing cookie) are >> returned in an HLS stream, the current implementation will append the >> new cookie to the list of cookies. This causes FFMPEG to send multiple >> cookie values for the same cookie and in some cases exceed the http >> header size in some cases. >> >> The patch attached resolves the issue. > > Thanks for the patch. Below are a few technical remarks. But before that, a > general remark: > > char *cookies; ///< holds newline (\n) delimited Set-Cookie header field > values (without the "Set-Cookie: " field name) > > Well, this is just awful. This is obviously not your fault, this is existing > code, but it is no way of building anything: it can do for a quick-and-dirty > first implementation to get things working, but it makes a very bad ground > to build upon. > > It seems to me that most of your patch is there to deal with that awful data > structure. A large part of the existing code too, for that matter. > > IMHO, it would be much better to rework the current code to use a proper > data structure. A dynarray of structures with name, value, path and domain > already split seems like the best option. > > I suspect it would even be simpler to do that than making sure your patch is > correct in its current form. > > Are you interested in that? Yes & no. I agree its not an ideal implementation (it actually was mine to begin with) to just use a string full of cookies. But we can't pass around complex structures through avopts, which is where we would really see the benefit. As you & Mark pointed out, we need to maintain compatibility with the current format, so why why go through parsing the cookie list each time if 1 in 100 requests actually sends back an updated cookie, and even then you'd have to dump it back out to a string and parse it again to pass it between http requests all this considered, I'd say I'm definitely leaning to "no" unless there is something I've overlooked. I'll follow up separately on the issues in the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Replace old cookies with new cookies of the same name
On Mon, Aug 18, 2014 at 07:59:11PM +1000, Micah Galizia wrote: > On Sun, Aug 17, 2014 at 9:29 PM, Nicolas George wrote: > > Le decadi 30 thermidor, an CCXXII, Micah Galizia a écrit : > >> When new cookie values (with the same name as an existing cookie) are > >> returned in an HLS stream, the current implementation will append the > >> new cookie to the list of cookies. This causes FFMPEG to send multiple > >> cookie values for the same cookie and in some cases exceed the http > >> header size in some cases. > >> > >> The patch attached resolves the issue. > > > > Thanks for the patch. Below are a few technical remarks. But before that, a > > general remark: > > > > char *cookies; ///< holds newline (\n) delimited Set-Cookie header field > > values (without the "Set-Cookie: " field name) > > > > Well, this is just awful. This is obviously not your fault, this is existing > > code, but it is no way of building anything: it can do for a quick-and-dirty > > first implementation to get things working, but it makes a very bad ground > > to build upon. > > > > It seems to me that most of your patch is there to deal with that awful data > > structure. A large part of the existing code too, for that matter. > > > > IMHO, it would be much better to rework the current code to use a proper > > data structure. A dynarray of structures with name, value, path and domain > > already split seems like the best option. > > > > I suspect it would even be simpler to do that than making sure your patch is > > correct in its current form. > > > > Are you interested in that? > > Yes & no. I agree its not an ideal implementation (it actually was > mine to begin with) to just use a string full of cookies. But we can't > pass around complex structures through avopts, which is where we would note, avopt now has AV_OPT_TYPE_DICT, dunno if that could help somewhere [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: export motion vectors in frame side data on demand
On date Sunday 2014-08-17 20:08:35 +0200, Clément Bœsch encoded: [...] > From 76f24f87bdfe1ca8778a6d39751fd70246c3b093 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= > Date: Wed, 16 Jul 2014 16:42:42 +0200 > Subject: [PATCH] avcodec: export motion vectors in frame side data on demand > > The reasoning behind this addition is that various third party > applications are interested in getting some motion information out of a > video "for free" when it is available. > > It was considered to export other information as well (such as the intra > information about the block, or the quantization) but the structure > might have ended up into a half full-generic, half full of codec > specific cruft. If more information is necessary, it should either be > added in the "flags" field of the AVMotionVector structure, or in > another side-data. > > This commit also includes an example exporting them in a CSV stream. > --- > .gitignore | 1 + > configure | 2 + > doc/APIchanges | 3 + > doc/Makefile | 1 + > doc/codecs.texi| 3 + > doc/examples/Makefile | 1 + > doc/examples/extract_mvs.c | 185 > + > libavcodec/avcodec.h | 1 + > libavcodec/mpegvideo.c | 103 - > libavcodec/options_table.h | 1 + > libavutil/Makefile | 1 + > libavutil/frame.c | 1 + > libavutil/frame.h | 7 ++ > libavutil/motion_vector.h | 50 > libavutil/version.h| 2 +- > 15 files changed, 360 insertions(+), 2 deletions(-) > create mode 100644 doc/examples/extract_mvs.c > create mode 100644 libavutil/motion_vector.h LGTM (but I'm no lavc maintainer), thanks. -- FFmpeg = Freak & Frightening Muttering Pitiless Explosive Gorilla ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On date Sunday 2014-08-17 19:04:35 -0400, compn encoded: > libav brought up the point again that it doesnt like libmpcodecs. That is, they will reunite if we drop mp? Or is that one of the conditional requirements? > is there anyone using the remaining libmpcodecs filters ? > most of the filters have been ported to libavfilter already. > > comments? Of the remaining filters, at least eq and eq2 are useful, and they are actually used by real users. -- FFmpeg = Faithful Frightening Minimal Practical Ecumenical Guru ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, 16 Aug 2014, Thomas Goirand wrote: > Yes, the Linux kernel is a successful project. Does this mean using a > list for reviewing patches is a good thing? No! The workflow with a list > is simply horrible. Using git-review and gerrit is so much better. Strong NAK here. First: it breaks the medium used (eMail vs. web). Second: Gerrit is an accessibility nightmare, not just for people using Lynx, but also for those who do have the required webbloatser at hand… and it recently got even worse. Having less points where information is exchanged is Good™. bye, //mirabilos, speaking from contributor experience in many projects -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Replace old cookies with new cookies of the same name
Le primidi 1er fructidor, an CCXXII, Micah Galizia a écrit :
> Yes & no. I agree its not an ideal implementation (it actually was
> mine to begin with) to just use a string full of cookies. But we can't
> pass around complex structures through avopts, which is where we would
> really see the benefit. As you & Mark pointed out, we need to maintain
> compatibility with the current format, so why why go through parsing
> the cookie list each time if 1 in 100 requests actually sends back an
> updated cookie, and even then you'd have to dump it back out to a
> string and parse it again to pass it between http requests all
> this considered, I'd say I'm definitely leaning to "no" unless there
> is something I've overlooked.
First, a small nitpick: if you read the option to get the updated values of
the cookies after the request, then you are abusing the API, as the option
does not have AV_OPT_FLAG_EXPORT. But for the sake of discussion we can
assume it should be there and always was.
But that does not mean that the string must be the authoritative value used
internally. A lot of your code is spent updating the middle of the string
while keeping the prefix and suffix constant. That makes a lot of tricky
code, with reallocations and possible integer overflows everywhere.
I am convinced that parsing the string as a whole, manipulating an internal
data structure and rebuilding the string as a whole would give much simpler
code. The parsing is needed for the actual Set-Cookie header; line-splitting
is relatively easy. As for the rebuilding of the string, we have utilities
that can take care of the reallocations and integer overflow for you; I
think especially of AVBPrint. Here is a snippet of code:
av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
for (i = 0; i < http->nb_cookies; i++) {
Cookie *c = &http->cookie[i];
if (i)
av_bprintf(&bp, "\n");
av_bprintf(&bp, "%s=%s", c->name, c->value);
if (c->domain)
av_bprintf(&bp, "; domain=%s", c->domain);
if (c->path)
av_bprintf(&bp, "; path=%s", c->path);
if (c->extra)
av_bprintf(&bp, "; %s", c->extra);
}
if (!av_bprint_is_complete(&bp))
return AVERROR(ENOMEM);
return av_bprint_finalize(&bp, &http->cookies);
Another point: I believe that having a callback on some options values may
also be quite useful. That could be done as AV_OPT_FLAG_CALLBACK with a
function pointer in AVClass. In this particular case, the callback could
parse the string on the fly and re-generate it only when necessary.
What do people think about that?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
Le primidi 1er fructidor, an CCXXII, Stefano Sabatini a écrit : > That is, they will reunite if we drop mp? And accept the features in FFmpeg that they have disparagingly called hacks? I would not bet on that. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Thomas, On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with potentially the same security issues that we'd have to fix twice rather than once. Why is it a security problem to have FFmpeg and Libav, but apparently no problem to have MySQL, MariaDB and PerconaDB? This seems quite arbitrary to me, especially since there have been already 36 CVEs in 2014 for MySQL [1], of which 26 apparently are also relevant for MariaDB [2] and PerconaDB [3], but only 7 for FFmpeg [4] and 8 for Libav [5] in the same time. Best regards, Andreas 1: https://security-tracker.debian.org/tracker/source-package/mysql-5.5 2: https://security-tracker.debian.org/tracker/source-package/mariadb-5.5 3: https://security-tracker.debian.org/tracker/source-package/percona-xtradb-cluster-5.5 4: https://security-tracker.debian.org/tracker/source-package/ffmpeg 5: https://security-tracker.debian.org/tracker/source-package/libav ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile
Christophe Gisquet gmail.com> writes: > An alternative would be to select the profile based on > the pixel format. What would be the disadvantage in this case? > If a user wants to encode without alpha, he would then > need to change the pixel format as well as specify the > proper profile, which may not be obvious to him. If a profile was set, the automatic setting should probably not overwrite it. (If this is possible.) But I consider the usecase where a user wants to encode alpha but at the same time using a profile that indicates no alpha of very limited usefulness. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le primidi 1er fructidor, an CCXXII, Thomas Goirand a écrit : > The problem was enforcing patch review policies. No, it never was. > There's been a very well commented technical reason stated here: the > release team don't want to deal with 2 of the same library that are > doing (nearly) the same things That the reason for keeping only one; other have discussed the validity of the reason. The reason for switching from FFmpeg to libav in the first place just after the fork is much simpler than that. > Yeah. If both were fully compatible, there would be no issue using one > or the other. Are there known current cases where FFmpeg can not emulate libav? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: do not fail when VIDIOC_ENUMSTD returns ENODATA
Andre Wolokita analog.com> writes:
> -if (ret == AVERROR(EINVAL)) {
> +if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
If I read fate correctly this broke compilation
on OpenBSD where ENODATA isn't defined.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
Ivan Kalvachev gmail.com> writes: > softpulldown - turns soft into hard telecine. Do you remember how this filter was used with MEncoder? I have a suspicion that it cannot work with FFmpeg. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: do not fail when VIDIOC_ENUMSTD returns ENODATA
On Mon, Aug 18, 2014 at 11:42:15AM +, Carl Eugen Hoyos wrote:
> Andre Wolokita analog.com> writes:
>
> > -if (ret == AVERROR(EINVAL)) {
> > +if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
>
> If I read fate correctly this broke compilation
> on OpenBSD where ENODATA isn't defined.
pushed a fix, hope it works
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/v4l2: do not fail when VIDIOC_ENUMSTD returns ENODATA
On Mon, Aug 18, 2014 at 02:04:48PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 18, 2014 at 11:42:15AM +, Carl Eugen Hoyos wrote:
> > Andre Wolokita analog.com> writes:
> >
> > > -if (ret == AVERROR(EINVAL)) {
> > > +if (ret == AVERROR(EINVAL) || ret == AVERROR(ENODATA)) {
> >
> > If I read fate correctly this broke compilation
> > on OpenBSD where ENODATA isn't defined.
>
> pushed a fix, hope it works
>
v4l2 + openbsd? What magic is this?
[...]
--
Clément B.
pgpE7SjMoRXgM.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavd/pulse_audio_dec: use default source when no input provided
On 07.08.2014 15:36, Michael Niedermayer wrote: On Thu, Aug 07, 2014 at 01:58:55AM +0200, Lukasz Marek wrote: PulseAudio expilitly requires name of the source. This patch makes it use default source when not provided. It simplifies programistic use. Signed-off-by: Lukasz Marek --- libavdevice/pulse_audio_dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) LGTM You can merge this one. Second one is up to you. I will resend third one from patch set later. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: export motion vectors in frame side data on demand
On Mon, Aug 18, 2014 at 01:27:05PM +0200, Stefano Sabatini wrote: > On date Sunday 2014-08-17 20:08:35 +0200, Clément Bœsch encoded: > [...] > > From 76f24f87bdfe1ca8778a6d39751fd70246c3b093 Mon Sep 17 00:00:00 2001 > > From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= > > Date: Wed, 16 Jul 2014 16:42:42 +0200 > > Subject: [PATCH] avcodec: export motion vectors in frame side data on demand > > > > The reasoning behind this addition is that various third party > > applications are interested in getting some motion information out of a > > video "for free" when it is available. > > > > It was considered to export other information as well (such as the intra > > information about the block, or the quantization) but the structure > > might have ended up into a half full-generic, half full of codec > > specific cruft. If more information is necessary, it should either be > > added in the "flags" field of the AVMotionVector structure, or in > > another side-data. > > > > This commit also includes an example exporting them in a CSV stream. > > --- > > .gitignore | 1 + > > configure | 2 + > > doc/APIchanges | 3 + > > doc/Makefile | 1 + > > doc/codecs.texi| 3 + > > doc/examples/Makefile | 1 + > > doc/examples/extract_mvs.c | 185 > > + > > libavcodec/avcodec.h | 1 + > > libavcodec/mpegvideo.c | 103 - > > libavcodec/options_table.h | 1 + > > libavutil/Makefile | 1 + > > libavutil/frame.c | 1 + > > libavutil/frame.h | 7 ++ > > libavutil/motion_vector.h | 50 > > libavutil/version.h| 2 +- > > 15 files changed, 360 insertions(+), 2 deletions(-) > > create mode 100644 doc/examples/extract_mvs.c > > create mode 100644 libavutil/motion_vector.h > > LGTM (but I'm no lavc maintainer), thanks. Thanks, applied. -- Clément B. pgpe50AY6HRQF.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun schrieb: > Hi Thomas, > > On 18.08.2014 08:36, Thomas Goirand wrote: >> There's been a very well commented technical reason stated here: the >> release team don't want to deal with 2 of the same library that are >> doing (nearly) the same things, with potentially the same security >> issues that we'd have to fix twice rather than once. > > Why is it a security problem to have FFmpeg and Libav, but apparently no > problem to have MySQL, MariaDB and PerconaDB? Raphael Geissert already wrote that mysql/mariadb/percona will be addressed as well; we haven't come around to since since we need to deal with a lot of stuf and being dragged into endless discussions on -devel is certainly not helpful. Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On 8/18/14, Carl Eugen Hoyos wrote: > Ivan Kalvachev gmail.com> writes: > >> softpulldown - turns soft into hard telecine. > > Do you remember how this filter was used with MEncoder? > I have a suspicion that it cannot work with FFmpeg. I have written about it before: On 5/4/13, Ivan Kalvachev wrote: > On 4/29/13, Paul B Mahol wrote: >> The filter funcionality is same as interlace/tinterlace. >> Required flag: MP_IMGFIELD_REPEAT_FIRST is never set, >> and can not be set as its not exported from lavf/lavc. > > That flag is derivided from AVFrame->repeat_pict . ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/apad: fix logic when whole_len or pad_len options are specified
---
libavfilter/af_apad.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/libavfilter/af_apad.c b/libavfilter/af_apad.c
index 15ba8c4..c58cacf 100644
--- a/libavfilter/af_apad.c
+++ b/libavfilter/af_apad.c
@@ -39,8 +39,8 @@ typedef struct {
int64_t next_pts;
int packet_size;
-int64_t pad_len;
-int64_t whole_len;
+int64_t pad_len, pad_len_left;
+int64_t whole_len, whole_len_left;
} APadContext;
#define OFFSET(x) offsetof(APadContext, x)
@@ -48,8 +48,8 @@ typedef struct {
static const AVOption apad_options[] = {
{ "packet_size", "set silence packet size", OFFSET(packet_size),
AV_OPT_TYPE_INT, { .i64 = 4096 }, 0, INT_MAX, A },
-{ "pad_len", "number of samples of silence to add",
OFFSET(pad_len), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, A },
-{ "whole_len", "target number of samples in the audio stream",
OFFSET(whole_len), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, A },
+{ "pad_len", "set number of samples of silence to add",
OFFSET(pad_len), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, A },
+{ "whole_len", "set target number of samples in the audio stream",
OFFSET(whole_len), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, A },
{ NULL }
};
@@ -64,6 +64,8 @@ static av_cold int init(AVFilterContext *ctx)
av_log(ctx, AV_LOG_ERROR, "Both whole and pad length are set, this is
not possible\n");
return AVERROR(EINVAL);
}
+apad->pad_len_left = apad->pad_len;
+apad->whole_len_left = apad->whole_len;
return 0;
}
@@ -73,8 +75,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
AVFilterContext *ctx = inlink->dst;
APadContext *apad = ctx->priv;
-if (apad->whole_len)
-apad->whole_len -= frame->nb_samples;
+if (apad->whole_len) {
+apad->whole_len_left = FFMAX(apad->whole_len_left - frame->nb_samples,
0);
+av_log(ctx, AV_LOG_DEBUG, "whole_len_left:%"PRId64"\n",
apad->whole_len_left);
+}
apad->next_pts = frame->pts + av_rescale_q(frame->nb_samples,
(AVRational){1, inlink->sample_rate}, inlink->time_base);
return ff_filter_frame(ctx->outputs[0], frame);
@@ -92,13 +96,14 @@ static int request_frame(AVFilterLink *outlink)
int n_out = apad->packet_size;
AVFrame *outsamplesref;
-if (apad->whole_len > 0) {
-apad->pad_len = apad->whole_len;
-apad->whole_len = 0;
+if (apad->whole_len > 0 && !apad->pad_len) {
+apad->pad_len = apad->pad_len_left = apad->whole_len_left;
}
-if (apad->pad_len > 0) {
-n_out = FFMIN(n_out, apad->pad_len);
-apad->pad_len -= n_out;
+if (apad->pad_len > 0 || apad->whole_len > 0) {
+n_out = FFMIN(n_out, apad->pad_len_left);
+apad->pad_len_left -= n_out;
+av_log(ctx, AV_LOG_DEBUG,
+ "n_out:%d pad_len_left:%"PRId64"\n", n_out,
apad->pad_len_left);
}
if(!n_out)
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/filters/apad: extend documentation
---
doc/filters.texi | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ca1d6f..44eecca 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -742,8 +742,51 @@ Pass the audio source unchanged to the output.
@section apad
-Pad the end of a audio stream with silence, this can be used together with
--shortest to extend audio streams to the same length as the video stream.
+Pad the end of an audio stream with silence.
+
+This can be used together with @command{ffmpeg} @option{-shortest} to
+extend audio streams to the same length as the video stream.
+
+A description of the accepted parameters follows.
+
+@table @option
+@item packet_size
+Set silence packet size. Default value is 4096.
+
+@item pad_len
+Set the number of samples of silence to add to the end. After the
+value is reached, the stream is terminated. This option is mutually
+exclusive with @option{whole_len}.
+
+@item whole_len
+Set the target number of sample in the audio stream. After the value
+is reached, the stream is terminated. This option is mutually
+exclusive with @option{pad_len}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Add 1024 samples of silence to the end of the input:
+@example
+apad=pad_len=1024
+@end example
+
+@item
+Make sure the audio output will contain at least 1 samples, pad
+the input with silence if required:
+@example
+apad=whole_len=1
+@end example
+
+@item
+Use @command{ffmpeg} to pad the audio input with silence, so that the
+video stream will be converted in the output until the end:
+@example
+ffmpeg -i VIDEO -i AUDIO -filter_complex "[1:0]apad" -shortest OUTPUT
+@end example
+@end itemize
@section aphaser
Add a phasing effect to the input audio.
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] huffyuvenc, multithread and context=1
Hi, 2014-06-19 6:23 GMT+02:00 Michael Niedermayer : > patch applied Am I missing something or was it not applied? -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On 18 August 2014 02:26, Ivan Kalvachev wrote: > ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to > do that too. Scale doesn't have much (any?) knowledge of interlaced chroma. That said I could probably port this filter to lavfi because it would be quite useful to me. I wasn't actually aware it existed. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Moritz, On 18.08.2014 14:05, Moritz Mühlenhoff wrote: Andreas Cadhalpun schrieb: On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with potentially the same security issues that we'd have to fix twice rather than once. Why is it a security problem to have FFmpeg and Libav, but apparently no problem to have MySQL, MariaDB and PerconaDB? Raphael Geissert already wrote that mysql/mariadb/percona will be addressed as well; we haven't come around to since since we need to deal with a lot of stuf and being dragged into endless discussions on -devel is certainly not helpful. I don't remember Raphael Geissert writing anything about security concerns with having MySQL, MariaDB and PerconaDB, only that you wrote half a year ago, that the security team will "be working with the release team to sort this out for jessie" [1]. As I haven't seen any further discussion about this and the recent mail about MySQL, MariaDB and PerconaDB on debian-devel [2] indicated that the plan was to have all of them as alternatives, I assumed this was resolved. There wouldn't be any discussion about the security of FFmpeg and Libav as well, if you hadn't started it [3]. Why is FFmpeg treated differently than MariaDB/PerconaDB? Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435 2: https://lists.debian.org/debian-devel/2014/08/msg00016.html 3: https://lists.debian.org/debian-devel/2014/02/msg00668.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On 8/18/14, Kieran Kunhya wrote: > On 18 August 2014 02:26, Ivan Kalvachev wrote: > >> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to >> do that too. > > Scale doesn't have much (any?) knowledge of interlaced chroma. > That said I could probably port this filter to lavfi because it would > be quite useful to me. I wasn't actually aware it existed. Hum? " ‘interl’ Set the interlacing mode. It accepts the following values: ‘1’Force interlaced aware scaling. ‘0’Do not apply interlaced scaling. ‘-1’Select interlaced aware scaling depending on whether the source frames are flagged as interlaced or not. Default value is ‘0’. " Maybe the default value should be -1. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On 18 August 2014 14:37, Ivan Kalvachev wrote: > On 8/18/14, Kieran Kunhya wrote: >> On 18 August 2014 02:26, Ivan Kalvachev wrote: >> >>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to >>> do that too. >> >> Scale doesn't have much (any?) knowledge of interlaced chroma. >> That said I could probably port this filter to lavfi because it would >> be quite useful to me. I wasn't actually aware it existed. > > Hum? > " > ‘interl’ > Set the interlacing mode. It accepts the following values: > ‘1’Force interlaced aware scaling. > ‘0’Do not apply interlaced scaling. > ‘-1’Select interlaced aware scaling depending on whether > the source frames are flagged as interlaced or not. > Default value is ‘0’. That is totally different to what the ilpack filter does. The ilpack filter converts from yuv420 to yuyv (422). vf_scale doesn't have any knowledge of interlaced chroma at all (and I sincerely hope nobody tries adding it to swscale). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
Hi, On Mon, Aug 18, 2014 at 9:48 AM, Kieran Kunhya wrote: > On 18 August 2014 14:37, Ivan Kalvachev wrote: > > On 8/18/14, Kieran Kunhya wrote: > >> On 18 August 2014 02:26, Ivan Kalvachev wrote: > >> > >>> ilpack - interlaced yuv420-> yuv422 converter. Scale should be able to > >>> do that too. > >> > >> Scale doesn't have much (any?) knowledge of interlaced chroma. > >> That said I could probably port this filter to lavfi because it would > >> be quite useful to me. I wasn't actually aware it existed. > > > > Hum? > > " > > ‘interl’ > > Set the interlacing mode. It accepts the following values: > > ‘1’Force interlaced aware scaling. > > ‘0’Do not apply interlaced scaling. > > ‘-1’Select interlaced aware scaling depending on whether > > the source frames are flagged as interlaced or not. > > Default value is ‘0’. > > That is totally different to what the ilpack filter does. The ilpack > filter converts from yuv420 to yuyv (422). vf_scale doesn't have any > knowledge of interlaced chroma at all (and I sincerely hope nobody > tries adding it to swscale). How is it different? If you're interlacing-aware and call swscale_convert() twice (once for each field, double stride each, alternate offset for second call), isn't that the same? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
> How is it different? If you're interlacing-aware and call swscale_convert() > twice (once for each field, double stride each, alternate offset for second > call), isn't that the same? That would be true in the 422 domain, yes. In 420, the chroma planes are offset and this has to be taken into account with weighted averages as ilpack does. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] alac: add option to decoded incorrect ALAC
Hi,
this is a proposal to allow decoding incorrect files. There is no
obvious and systematic way to detect them however.
--
Christophe
From feaacb09d8660b7e8784ad4a550dda455f172e24 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 09:53:20 +0200
Subject: [PATCH] alac: add option to decoded incorrect ALAC
Prior to 56.1.100, incorrect ALAC files for 24bps content were produced, in
particular not decoding losslessly.
Add an option to allow correctly decoding those streams.
---
libavcodec/alac.c| 24 +++-
libavcodec/version.h | 4 ++--
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 103d14e..849d623 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -48,6 +48,7 @@
#include
#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
#include "avcodec.h"
#include "get_bits.h"
#include "bytestream.h"
@@ -78,6 +79,7 @@ typedef struct {
int nb_samples; /**< number of samples in the current frame */
int direct_output;
+int extra_bit_bug;
} ALACContext;
static inline unsigned int decode_scalar(GetBitContext *gb, int k, int bps)
@@ -380,12 +382,17 @@ static int decode_element(AVCodecContext *avctx, AVFrame *frame, int ch_index,
decorr_left_weight = 0;
}
+if (alac->extra_bits && alac->extra_bit_bug) {
+append_extra_bits(alac->output_samples_buffer, alac->extra_bits_buffer,
+ alac->extra_bits, channels, alac->nb_samples);
+}
+
if (channels == 2 && decorr_left_weight) {
decorrelate_stereo(alac->output_samples_buffer, alac->nb_samples,
decorr_shift, decorr_left_weight);
}
-if (alac->extra_bits) {
+if (alac->extra_bits && !alac->extra_bit_bug) {
append_extra_bits(alac->output_samples_buffer, alac->extra_bits_buffer,
alac->extra_bits, channels, alac->nb_samples);
}
@@ -630,6 +637,20 @@ static int init_thread_copy(AVCodecContext *avctx)
return allocate_buffers(alac);
}
+static const AVOption options[] = {
+{ "extra_bits_bug", "Force non-standard decoding process",
+ offsetof(ALACContext, extra_bit_bug), AV_OPT_TYPE_INT, { .i64 = 0 },
+ 0, 1, AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_DECODING_PARAM },
+{ NULL },
+};
+
+static const AVClass alac_class = {
+.class_name = "alac",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
AVCodec ff_alac_decoder = {
.name = "alac",
.long_name = NULL_IF_CONFIG_SMALL("ALAC (Apple Lossless Audio Codec)"),
@@ -641,4 +662,5 @@ AVCodec ff_alac_decoder = {
.decode = alac_decode_frame,
.init_thread_copy = ONLY_IF_THREADS_ENABLED(init_thread_copy),
.capabilities = CODEC_CAP_DR1 | CODEC_CAP_FRAME_THREADS,
+.priv_class = &alac_class
};
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 2c871ba..19e2e45 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,8 +29,8 @@
#include "libavutil/version.h"
#define LIBAVCODEC_VERSION_MAJOR 56
-#define LIBAVCODEC_VERSION_MINOR 0
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MINOR 1
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: add option to decoded incorrect ALAC
2014-08-18 15:59 GMT+02:00 Christophe Gisquet : > this is a proposal to allow decoding incorrect files. There is no > obvious and systematic way to detect them however. Ignore the version.h stray change in your review, I thought I had removed it. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: add option to decoded incorrect ALAC
On 8/18/14, Christophe Gisquet wrote: > Hi, > > this is a proposal to allow decoding incorrect files. There is no > obvious and systematic way to detect them however. > > -- > Christophe > AFAIK it is missing AVClass *class in codec context. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters/apad: extend documentation
On 2014-08-18 14:53, Stefano Sabatini wrote: > +@item whole_len > +Set the target number of sample in the audio stream. After the value ^^ samples, plural signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add codecview filter
From: Clément Bœsch
---
Note: I didn't use FF_API_DEBUG_MV because it seems to overlap with all
kind of other things and I couldn't test properly the conditional
compilation.
BTW, I could add a FATE test easily, but I didn't find any relevant
samples available.
TODO: minor bump avfilter, micro bump avcodec
---
Changelog | 1 +
RELEASE_NOTES | 2 +
doc/filters.texi | 36 +++
libavcodec/mpegvideo.c | 13 ++-
libavcodec/options_table.h | 4 +-
libavcodec/utils.c | 6 ++
libavcodec/version.h | 4 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_codecview.c | 241 +
10 files changed, 305 insertions(+), 4 deletions(-)
create mode 100644 libavfilter/vf_codecview.c
diff --git a/Changelog b/Changelog
index 6260d0c..b2e3896 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
- large optimizations in dctdnoiz to make it usable
- request icecast metadata by default
- support for using metadata in stream specifiers in fftools
+- added codecview filter to visualize information exported by some codecs
version 2.3:
diff --git a/RELEASE_NOTES b/RELEASE_NOTES
index eb73e88..3fbf556 100644
--- a/RELEASE_NOTES
+++ b/RELEASE_NOTES
@@ -37,6 +37,7 @@
• ported lenscorrection filter from frei0r filter
• large optimizations in dctdnoiz to make it usable
+• added codecview filter to visualize information exported by some codecs
┌┐
│ libavutil │
@@ -49,3 +50,4 @@
└┘
• dctdnoiz filter now uses a block size of 8x8 instead of 16x16 by default
+ • -vismv option is deprecated in favor of the codecview filter
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ca1d6f..de4cb19 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2755,6 +2755,42 @@
boxblur=luma_radius=min(h\,w)/10:luma_power=1:chroma_radius=min(cw\,ch)/10:chrom
@end example
@end itemize
+@section codecview
+
+Visualize information exported by some codecs.
+
+Some codecs can export information through frames using side-data or other
+means. For example, some MPEG based codecs export motion vectors through the
+@var{export_mvs} flag in the codec @option{flags2} option.
+
+The filter accepts the following option:
+
+@table @option
+@item mv
+Set motion vectors to visualize.
+
+Available flags for @var{mv} are:
+
+@table @samp
+@item pf
+forward predicted MVs of P-frames
+@item bf
+forward predicted MVs of B-frames
+@item bb
+backward predicted MVs of B-frames
+@end table
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Visualizes multi-directionals MVs from P and B-Frames using @command{ffplay}:
+@example
+ffplay -flags2 +export_mvs input.mpg -vf codecview=mv=pf+bf+bb
+@end example
+@end itemize
+
@section colorbalance
Modify intensity of primary colors (red, green and blue) of input frames.
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 6a0b822..4e63edb 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -1982,7 +1982,7 @@ void ff_mpv_frame_end(MpegEncContext *s)
ff_thread_report_progress(&s->current_picture_ptr->tf, INT_MAX, 0);
}
-
+#if FF_API_VISMV
static int clip_line(int *sx, int *sy, int *ex, int *ey, int maxx)
{
if(*sx > *ex)
@@ -2107,6 +2107,7 @@ static void draw_arrow(uint8_t *buf, int sx, int sy, int
ex,
}
draw_line(buf, sx, sy, ex, ey, w, h, stride, color);
}
+#endif
static int add_mb(AVMotionVector *mb, uint32_t mb_type,
int dst_x, int dst_y,
@@ -2292,13 +2293,15 @@ void ff_print_debug_info2(AVCodecContext *avctx,
AVFrame *pict, uint8_t *mbskip_
if ((avctx->debug & (FF_DEBUG_VIS_QP | FF_DEBUG_VIS_MB_TYPE)) ||
(avctx->debug_mv)) {
-const int shift = 1 + quarter_sample;
int mb_y;
-uint8_t *ptr;
int i;
int h_chroma_shift, v_chroma_shift, block_height;
+#if FF_API_VISMV
+const int shift = 1 + quarter_sample;
+uint8_t *ptr;
const int width = avctx->width;
const int height = avctx->height;
+#endif
const int mv_sample_log2 = avctx->codec_id == AV_CODEC_ID_H264 ||
avctx->codec_id == AV_CODEC_ID_SVQ3 ? 2 : 1;
const int mv_stride = (mb_width << mv_sample_log2) +
(avctx->codec->id == AV_CODEC_ID_H264 ? 0 :
1);
@@ -2310,13 +2313,16 @@ void ff_print_debug_info2(AVCodecContext *avctx,
AVFrame *pict, uint8_t *mbskip_
av_frame_make_writable(pict);
pict->opaque = NULL;
+#if FF_API_VISMV
ptr = pict->data[0];
+#endif
block_height = 16 >> v_chroma_shift;
for (mb_y = 0; mb_y < mb_height; mb_y++) {
int mb_x;
for (mb_x = 0; mb_x < mb_width; mb_x++) {
const int mb_index = mb_x + mb_y * mb_stride;
+#if FF_API_VISMV
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On Mon, 18 Aug 2014 13:31:26 +0200 Stefano Sabatini wrote: > On date Sunday 2014-08-17 19:04:35 -0400, compn encoded: > > is there anyone using the remaining libmpcodecs filters ? > > Of the remaining filters, at least eq and eq2 are useful, and they are > actually used by real users. ok, then i am fine to keep libmpcodecs. thanks everyone for your opinions and info! -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters/apad: extend documentation
On Mon, Aug 18, 2014 at 5:53 AM, Stefano Sabatini wrote:
> ---
> doc/filters.texi | 47 +--
> 1 file changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 0ca1d6f..44eecca 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -742,8 +742,51 @@ Pass the audio source unchanged to the output.
>
> @section apad
>
> -Pad the end of a audio stream with silence, this can be used together with
> --shortest to extend audio streams to the same length as the video stream.
> +Pad the end of an audio stream with silence.
> +
> +This can be used together with @command{ffmpeg} @option{-shortest} to
> +extend audio streams to the same length as the video stream.
> +
> +A description of the accepted parameters follows.
@subsection Options
I would also change "parameters" to "options", as it is more common in the doc.
> +
> +@table @option
> +@item packet_size
> +Set silence packet size. Default value is 4096.
> +
> +@item pad_len
> +Set the number of samples of silence to add to the end. After the
> +value is reached, the stream is terminated. This option is mutually
> +exclusive with @option{whole_len}.
> +
> +@item whole_len
> +Set the target number of sample in the audio stream. After the value
> +is reached, the stream is terminated. This option is mutually
> +exclusive with @option{pad_len}.
How about:
Set total number of samples in the audio stream. If the value is
longer than input audio length, silence is added to the end, until the
value is reached. If it is shorter, the stream is terminated after the
value is reached. This option is mutually exclusive with
@option{pad_len}.
What happens when neither of these are specified (like in your third example)?
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Add 1024 samples of silence to the end of the input:
> +@example
> +apad=pad_len=1024
> +@end example
> +
> +@item
> +Make sure the audio output will contain at least 1 samples, pad
> +the input with silence if required:
> +@example
> +apad=whole_len=1
> +@end example
> +
> +@item
> +Use @command{ffmpeg} to pad the audio input with silence, so that the
> +video stream will be converted in the output until the end:
> +@example
> +ffmpeg -i VIDEO -i AUDIO -filter_complex "[1:0]apad" -shortest OUTPUT
> +@end example
> +@end itemize
>
> @section aphaser
> Add a phasing effect to the input audio.
> --
> 1.8.3.2
>
> ___
> 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] 0001-Avoid-segfault-in-a64_write_header-when-stream-codec.patch
Hello,
Attached patch fixes segmentation fault in libavformat/a64.c
a64_write_header() when output stream's codec is not open, so
avctx->codec is NULL (in "stream_copy" use case for example). Correct
access to codec id is use of "avctx->codec_id" instead of
"avctx->codec->id".
Additionally, in 'default' section of switch() statement here, I propose
to return AVERROR(ENOTSUP) instead of AVERROR_INVALIDDATA, because it is
more clear to get someting like
"avformat_write_header() fails: Operation not supported"
instread of
"avformat_write_header() fails: Invalid data found when processing
input"
when we do output, but do not input.
Reards,
Andrey Myznikov
>From b7d1fab99ac24b0a7a81244e24b65abb4b9059cc Mon Sep 17 00:00:00 2001
From: Andrey Myznikov
Date: Mon, 18 Aug 2014 19:18:04 +0300
Subject: [PATCH] Avoid segfault in a64_write_header() when stream codec is not
open
---
libavformat/a64.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/a64.c b/libavformat/a64.c
index 03679b2..ed27b14 100644
--- a/libavformat/a64.c
+++ b/libavformat/a64.c
@@ -40,7 +40,8 @@ static int a64_write_header(AVFormatContext *s)
return AVERROR_INVALIDDATA;
}
-switch (avctx->codec->id) {
+
+switch (avctx->codec_id) {
case AV_CODEC_ID_A64_MULTI:
header[2] = 0x00;
header[3] = AV_RB32(avctx->extradata+0);
@@ -52,7 +53,7 @@ static int a64_write_header(AVFormatContext *s)
header[4] = 3;
break;
default:
-return AVERROR_INVALIDDATA;
+return AVERROR(ENOTSUP);
}
avio_write(s->pb, header, 2);
return 0;
--
2.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fix CBR output for IP multicasting video
> So could you help me fix this problem and make the measurment result is > better. It is quite a bit of work to make ffmpeg do this properly. Also those encoder settings are quite interesting. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] 0001-Avoid-segfault-in-a64_write_header-when-stream-codec.patch
Le primidi 1er fructidor, an CCXXII, Andrey Myznikov a écrit : > Additionally, in 'default' section of switch() statement here, I > propose to return AVERROR(ENOTSUP) instead of AVERROR_INVALIDDATA, > because it is more clear to get someting like > "avformat_write_header() fails: Operation not supported" > > instread of > "avformat_write_header() fails: Invalid data found when > processing input" > > when we do output, but do not input. Unfortunately: ENOTSUP POSIX +++... Operation not supported The three dots show that ENOTSUP does not exist on windows and BeOS, so it can not be used in generic code. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] 0001-Avoid-segfault-in-a64_write_header-when-stream-codec.patch
Hello,
Attached patch fixes segmentation fault in libavformat/a64.c
a64_write_header() when output stream's codec is not open, so
avctx->codec is NULL (in "stream_copy" use case for example). Correct
access to codec id is use of "avctx->codec_id" instead of
"avctx->codec->id".
Regards,
Andrey Myznikov
>From e792c3db82b35f7f6d4cd9000e3be297b02df88d Mon Sep 17 00:00:00 2001
From: Andrey Myznikov
Date: Mon, 18 Aug 2014 20:03:31 +0300
Subject: [PATCH] Avoid segfault in a64_write_header() when stream codec is not
open
---
libavformat/a64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/a64.c b/libavformat/a64.c
index 03679b2..a7f93a2 100644
--- a/libavformat/a64.c
+++ b/libavformat/a64.c
@@ -40,7 +40,7 @@ static int a64_write_header(AVFormatContext *s)
return AVERROR_INVALIDDATA;
}
-switch (avctx->codec->id) {
+switch (avctx->codec_id) {
case AV_CODEC_ID_A64_MULTI:
header[2] = 0x00;
header[3] = AV_RB32(avctx->extradata+0);
--
2.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
Signed-off-by: Deti fliegl
---
libavdevice/decklink_common.cpp | 227 ++
libavdevice/decklink_common.h | 98
libavdevice/decklink_common_c.h | 32 +++
libavdevice/decklink_dec.cpp| 520
libavdevice/decklink_dec.h | 32 +++
libavdevice/decklink_dec_c.c| 54 +
6 files changed, 963 insertions(+)
create mode 100644 libavdevice/decklink_common.cpp
create mode 100644 libavdevice/decklink_common.h
create mode 100644 libavdevice/decklink_common_c.h
create mode 100644 libavdevice/decklink_dec.cpp
create mode 100644 libavdevice/decklink_dec.h
create mode 100644 libavdevice/decklink_dec_c.c
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
new file mode 100644
index 000..7a9fed5
--- /dev/null
+++ b/libavdevice/decklink_common.cpp
@@ -0,0 +1,227 @@
+/*
+ * Blackmagic DeckLink output
+ * Copyright (c) 2013-2014 Ramiro Polla, Luca Barbato, Deti Fliegl
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#ifdef _WIN32
+#include
+#else
+#include
+#endif
+
+#include
+#include
+
+extern "C" {
+#include "libavformat/avformat.h"
+#include "libavformat/internal.h"
+#include "libavutil/imgutils.h"
+}
+
+#include "decklink_common.h"
+
+#ifdef _WIN32
+IDeckLinkIterator *CreateDeckLinkIteratorInstance(void)
+{
+IDeckLinkIterator *iter;
+
+if (CoInitialize(NULL) != S_OK) {
+av_log(NULL, AV_LOG_ERROR, "COM initialization failed.\n");
+return NULL;
+}
+
+if (CoCreateInstance(CLSID_CDeckLinkIterator, NULL, CLSCTX_ALL,
+ IID_IDeckLinkIterator, (void**) &iter) != S_OK) {
+av_log(NULL, AV_LOG_ERROR, "DeckLink drivers not installed.\n");
+return NULL;
+}
+
+return iter;
+}
+#endif
+
+/* free() is needed for a string returned by the DeckLink SDL. */
+#undef free
+
+#ifdef _WIN32
+char *dup_wchar_to_utf8(wchar_t *w)
+{
+char *s = NULL;
+int l = WideCharToMultiByte(CP_UTF8, 0, w, -1, 0, 0, 0, 0);
+s = (char *) av_malloc(l);
+if (s)
+WideCharToMultiByte(CP_UTF8, 0, w, -1, s, l, 0, 0);
+return s;
+}
+#define DECKLINK_STROLECHAR *
+#define DECKLINK_STRDUP dup_wchar_to_utf8
+#else
+#define DECKLINK_STRconst char *
+#define DECKLINK_STRDUP av_strdup
+#endif
+
+HRESULT IDeckLink_GetDisplayName(IDeckLink *This, const char **displayName)
+{
+DECKLINK_STR tmpDisplayName;
+HRESULT hr = This->GetDisplayName(&tmpDisplayName);
+if (hr != S_OK)
+return hr;
+*displayName = DECKLINK_STRDUP(tmpDisplayName);
+free((void *) tmpDisplayName);
+return hr;
+}
+
+int decklink_set_format(struct decklink_ctx *ctx,
+ int width, int height,
+ int tb_num, int tb_den,
+ decklink_direction_t direction, int num)
+{
+BMDDisplayModeSupport support;
+IDeckLinkDisplayModeIterator *itermode;
+IDeckLinkDisplayMode *mode;
+int i = 1;
+HRESULT res;
+
+if (direction == DIRECTION_IN) {
+res = ctx->dli->GetDisplayModeIterator (&itermode);
+} else {
+res = ctx->dlo->GetDisplayModeIterator (&itermode);
+}
+
+if (res!= S_OK) {
+av_log(NULL, AV_LOG_ERROR, "Could not get Display Mode
Iterator\n");
+return AVERROR(EIO);
+}
+
+
+if (tb_num == 1) {
+tb_num *= 1000;
+tb_den *= 1000;
+}
+ctx->bmd_mode = bmdModeUnknown;
+while ((ctx->bmd_mode == bmdModeUnknown) && itermode->Next(&mode) == S_OK)
{
+BMDTimeValue bmd_tb_num, bmd_tb_den;
+int bmd_width = mode->GetWidth();
+int bmd_height = mode->GetHeight();
+
+mode->GetFrameRate(&bmd_tb_num, &bmd_tb_den);
+
+if ((bmd_width == width && bmd_height == height &&
+bmd_tb_num == tb_num && bmd_tb_den == tb_den) || i == num) {
+ctx->bmd_mode = mode->GetDisplayMode();
+ctx->bmd_width = bmd_width;
+ctx->bmd_height = bmd_height;
+ctx->bmd_tb_den = bmd_tb_den;
+ctx->bmd_tb_num = bmd_tb_num;
+ctx->bmd_field_dominance = mode->GetFieldDominance();
+av_log(NULL, AV_LOG_INFO, "Found Decklink mode %d x %d wit
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
Hi, On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya wrote: > > How is it different? If you're interlacing-aware and call > swscale_convert() > > twice (once for each field, double stride each, alternate offset for > second > > call), isn't that the same? > > That would be true in the 422 domain, yes. In 420, the chroma planes > are offset and this has to be taken into account with weighted > averages as ilpack does. You mean the centerpoint chroma location (top-left, top-middle, middle-middle, etc.) respective to the set of luma pixels? If that's all, that's a mere few seconds to implement in swscale, correctly for all cases (you just offset the start of the filter). You don't need special filters just for that. I bet Michael or me could do this in 15 minutes. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
Deti Fliegl fliegl.de> writes: > +/* free() is needed for a string returned by the DeckLink SDL. */ > +#undef free I believe this is not needed anymore but ... > +free((void *) tmpDisplayName); ... please move the comment here. Is the cast necessary? > +av_log(NULL, AV_LOG_ERROR, Context should not be NULL. > +av_log(NULL, AV_LOG_INFO, "Found Decklink mode %d x > %d with rate %.2f%s\n", bmd_width, bmd_height, > (float)bmd_tb_den/(float)bmd_tb_num, > (ctx->bmd_field_dominance==bmdLowerFieldFirst || > ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":""); Please split this line. Isn't your patch missing a configure check and a change to Makefile? (What is the license of the decklink libraries?) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile
2014-08-18 19:26 GMT+02:00 Christophe Gisquet :
> Hi,
And with all patches.
--
Christophe
From 89b54fbd698eb9c68f0bf30105bcaf72c5575d27 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc: force correct profile for alpha
Irrespective of the strictness level, if the pixel format contains alpha,
the profile is forced to be 4:4:4:4. Otherwise, the file may contain
alpha, but software like Final Cut Pro or After Effects will consider
this file to not contain alpha data.
---
libavcodec/proresenc_kostya.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 46f81db..08ea906 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1145,6 +1145,13 @@ static av_cold int encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
if (av_pix_fmt_desc_get(avctx->pix_fmt)->flags & AV_PIX_FMT_FLAG_ALPHA) {
+if (ctx->profile != PRORES_PROFILE_) {
+// force alpha and warn
+av_log(avctx, AV_LOG_WARNING, "Profile 4:4:4:4 forced to "
+ "allow encoding of alpha channel. Change pixel format"
+ " if you actually want this.\n");
+ctx->profile = PRORES_PROFILE_;
+}
if (ctx->alpha_bits & 7) {
av_log(avctx, AV_LOG_ERROR, "alpha bits should be 0, 8 or 16\n");
return AVERROR(EINVAL);
--
1.9.2.msysgit.0
From f24ec2b80392918e436fd5b5564b0641e37131f9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc: skip/warn on incorrect profile
This does, if strictness level is high enough:
- Skip encoding of alpha when profile does not allow it;
- Warn about profile allowing alpha when content does not have alpha.
Some software such as After Effects and Final Cut Pro entirely skip
alpha channel decoding if the profile is not .
---
libavcodec/proresenc_kostya.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 46f81db..90e9d74 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1145,11 +1145,22 @@ static av_cold int encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
if (av_pix_fmt_desc_get(avctx->pix_fmt)->flags & AV_PIX_FMT_FLAG_ALPHA) {
-if (ctx->alpha_bits & 7) {
+if (ctx->profile != PRORES_PROFILE_ &&
+avctx->strict_std_compliance > FF_COMPLIANCE_NORMAL) {
+// ignore alpha but warn
+av_log(avctx, AV_LOG_WARNING, "If you want alpha to be "
+ "encoded, please specify -profile \n");
+ctx->alpha_bits = 0;
+} else if (ctx->alpha_bits & 7) {
av_log(avctx, AV_LOG_ERROR, "alpha bits should be 0, 8 or 16\n");
return AVERROR(EINVAL);
}
} else {
+if (ctx->profile == PRORES_PROFILE_ &&
+avctx->strict_std_compliance > FF_COMPLIANCE_NORMAL)
+av_log(avctx, AV_LOG_WARNING, "profile with alpha but "
+ "content has no alpha\n");
+
ctx->alpha_bits = 0;
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On Mon, Aug 18, 2014 at 01:22:37PM -0400, Ronald S. Bultje wrote:
> Hi,
>
>
> On Mon, Aug 18, 2014 at 9:58 AM, Kieran Kunhya wrote:
>
> > > How is it different? If you're interlacing-aware and call
> > swscale_convert()
> > > twice (once for each field, double stride each, alternate offset for
> > second
> > > call), isn't that the same?
> >
> > That would be true in the 422 domain, yes. In 420, the chroma planes
> > are offset and this has to be taken into account with weighted
> > averages as ilpack does.
>
>
> You mean the centerpoint chroma location (top-left, top-middle,
> middle-middle, etc.) respective to the set of luma pixels? If that's all,
> that's a mere few seconds to implement in swscale, correctly for all cases
> (you just offset the start of the filter). You don't need special filters
> just for that.
>
> I bet Michael or me could do this in 15 minutes.
i had almost forgotten it but there is:
{ "src_v_chr_pos", "source vertical chroma position in luma grid/256" ,
OFFSET(src_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1}, -1, 512,
VE },
{ "src_h_chr_pos", "source horizontal chroma position in luma grid/256",
OFFSET(src_h_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1}, -1, 512,
VE },
{ "dst_v_chr_pos", "destination vertical chroma position in luma
grid/256" , OFFSET(dst_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1},
-1, 512, VE },
{ "dst_h_chr_pos", "destination horizontal chroma position in luma
grid/256", OFFSET(dst_h_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1},
-1, 512, VE },
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
On Mon, Aug 18, 2014 at 01:31:26PM +0200, Stefano Sabatini wrote: > On date Sunday 2014-08-17 19:04:35 -0400, compn encoded: > > libav brought up the point again that it doesnt like libmpcodecs. > > That is, they will reunite if we drop mp? Or is that one of the > conditional requirements? > > > is there anyone using the remaining libmpcodecs filters ? > > most of the filters have been ported to libavfilter already. > > > > comments? > > Of the remaining filters, at least eq and eq2 are useful, and they are > actually used by real users. yes, i use them as well for debuging stuff occasionally, either to remove luma or chroma or to boost contrast to better see some faint artifacts [...] -- 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] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile
Hi,
2014-08-18 13:40 GMT+02:00 Carl Eugen Hoyos :
> Christophe Gisquet gmail.com> writes:
> If a profile was set, the automatic setting should
> probably not overwrite it.
> (If this is possible.)
>
> But I consider the usecase where a user wants to encode
> alpha but at the same time using a profile that
> indicates no alpha of very limited usefulness.
0001-proresenc-skip-warn-on-incorrect-profile.patch is the
continuation of the first patch: we still encode the alpha with the
incorrect profile (ie no change in behaviour) thereby not overriding
the user decision. If he selected strict conformance and a profile
without alpha, alpha channel coding is skipped.
Second patch 0001-proresenc-force-correct-profile-for-alpha.patch
overrides the profile information. The default profile is
PRORES_PROFILE_STANDARD, maye a PRORES_PROFILE_AUTO could be
introduced to control the behavior of this patch.
--
Christophe
From f24ec2b80392918e436fd5b5564b0641e37131f9 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc: skip/warn on incorrect profile
This does, if strictness level is high enough:
- Skip encoding of alpha when profile does not allow it;
- Warn about profile allowing alpha when content does not have alpha.
Some software such as After Effects and Final Cut Pro entirely skip
alpha channel decoding if the profile is not .
---
libavcodec/proresenc_kostya.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 46f81db..90e9d74 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1145,11 +1145,22 @@ static av_cold int encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
if (av_pix_fmt_desc_get(avctx->pix_fmt)->flags & AV_PIX_FMT_FLAG_ALPHA) {
-if (ctx->alpha_bits & 7) {
+if (ctx->profile != PRORES_PROFILE_ &&
+avctx->strict_std_compliance > FF_COMPLIANCE_NORMAL) {
+// ignore alpha but warn
+av_log(avctx, AV_LOG_WARNING, "If you want alpha to be "
+ "encoded, please specify -profile \n");
+ctx->alpha_bits = 0;
+} else if (ctx->alpha_bits & 7) {
av_log(avctx, AV_LOG_ERROR, "alpha bits should be 0, 8 or 16\n");
return AVERROR(EINVAL);
}
} else {
+if (ctx->profile == PRORES_PROFILE_ &&
+avctx->strict_std_compliance > FF_COMPLIANCE_NORMAL)
+av_log(avctx, AV_LOG_WARNING, "profile with alpha but "
+ "content has no alpha\n");
+
ctx->alpha_bits = 0;
}
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
Hi, 2014-08-18 19:22 GMT+02:00 Ronald S. Bultje : > You mean the centerpoint chroma location (top-left, top-middle, > middle-middle, etc.) respective to the set of luma pixels? I don't think it's only that, but it's probably only slightly longer to implement. For interlaced 4:2:0, each chroma field has a phase shift, respectively 3/4 and 1/4. If I'm not mistaken, you can probably run each filter on each field, and that's it. Though it's probably better to unroll it for the 2 fields. Or I could read the fine code. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] 0001-Avoid-segfault-in-a64_write_header-when-stream-codec.patch
On Mon, Aug 18, 2014 at 08:05:41PM +0300, Andrey Myznikov wrote: > Hello, > > Attached patch fixes segmentation fault in libavformat/a64.c > a64_write_header() when output stream's codec is not open, so > avctx->codec is NULL (in "stream_copy" use case for example). > Correct access to codec id is use of "avctx->codec_id" instead of > "avctx->codec->id". > > Regards, > Andrey Myznikov > > a64.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 96351557a0db44309720871519238be5aba7a890 > 0001-Avoid-segfault-in-a64_write_header-when-stream-codec.patch > From e792c3db82b35f7f6d4cd9000e3be297b02df88d Mon Sep 17 00:00:00 2001 > From: Andrey Myznikov > Date: Mon, 18 Aug 2014 20:03:31 +0300 > Subject: [PATCH] Avoid segfault in a64_write_header() when stream codec is not > open applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On 18.08.14 19:23, Carl Eugen Hoyos wrote:
> Deti Fliegl fliegl.de> writes:
>
>> +/* free() is needed for a string returned by the DeckLink SDL. */
>> +#undef free
>
> I believe this is not needed anymore but ...
removed it - but this has been part of the existing code which I simply
moved to a new file.
>
>> +free((void *) tmpDisplayName);
>
> ... please move the comment here.
Done.
> Is the cast necessary?
Yes.
>
>> +av_log(NULL, AV_LOG_ERROR,
>
> Context should not be NULL.
Can hardly be done in this file unless you supply avctx as argument in
every function only for av_log purposes.
>
>> +av_log(NULL, AV_LOG_INFO, "Found Decklink mode %d x
>> %d with rate %.2f%s\n", bmd_width, bmd_height,
>> (float)bmd_tb_den/(float)bmd_tb_num,
>> (ctx->bmd_field_dominance==bmdLowerFieldFirst ||
>> ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":"");
>
> Please split this line.
done.
> Isn't your patch missing a configure check and
> a change to Makefile?
Must have missed some files to commit. Fixing patch attached to this mail.
> (What is the license of the decklink libraries?)
There is no DeckLink library code in my patch. The already existing
decklink encoder support covers how to build ffmpeg with the DeckLink SDK.
Deti
Signed-off-by: Deti fliegl
---
configure | 4 +-
doc/indevs.texi | 54 +++
libavdevice/Makefile| 5 +-
libavdevice/alldevices.c| 2 +-
libavdevice/decklink_common.cpp | 30 +++
libavdevice/decklink_dec.cpp| 14 +--
libavdevice/decklink_enc.cpp| 194
libavdevice/decklink_enc.h | 11 ---
libavdevice/decklink_enc_c.c| 1 +
9 files changed, 100 insertions(+), 215 deletions(-)
diff --git a/configure b/configure
index f355dad..189542f 100755
--- a/configure
+++ b/configure
@@ -253,7 +253,7 @@ External library support:
native MPEG-4/Xvid encoder exists [no]
--enable-libzmq enable message passing via libzmq [no]
--enable-libzvbi enable teletext support via libzvbi [no]
- --enable-decklinkenable Blackmagick DeckLink output [no]
+ --enable-decklinkenable Blackmagick DeckLink I/O support [no]
--enable-openal enable OpenAL 1.1 capture support [no]
--enable-opencl enable OpenCL code
--enable-opengl enable OpenGL rendering [no]
@@ -2441,6 +2441,8 @@ bktr_indev_deps_any="dev_bktr_ioctl_bt848_h
machine_ioctl_bt848_h dev_video_bktr
caca_outdev_deps="libcaca"
decklink_outdev_deps="decklink pthreads"
decklink_outdev_extralibs="-lstdc++"
+decklink_indev_deps="decklink pthreads"
+decklink_indev_extralibs="-lstdc++"
dshow_indev_deps="IBaseFilter"
dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid"
dv1394_indev_deps="dv1394"
diff --git a/doc/indevs.texi b/doc/indevs.texi
index ce409b9..ddf4c44 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -922,4 +922,58 @@ Use the MIT-SHM extension for shared memory. Default value
is @code{1}.
It may be necessary to disable it for remote displays.
@end table
+@section decklink
+
+The decklink input device provides capture capabilities for Blackmagic
+DeckLink devices.
+
+To enable this input device, you need the Blackmagic DeckLink SDK and you
+need to configure with the appropriate @code{--extra-cflags}
+and @code{--extra-ldflags}.
+On Windows, you need to run the IDL files through @command{widl}.
+
+DeckLink is very picky about the formats it supports. Pixel format is always
+uyvy422, framerate and video size must be determined for your device with
+@command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
+of channels currently is limited to 2 (stereo).
+
+@subsection Options
+
+@table @option
+
+@item list_devices
+If set to @option{true}, print a list of devices and exit.
+Defaults to @option{false}.
+
+@item list_formats
+If set to @option{true}, print a list of supported formats and exit.
+Defaults to @option{false}.
+
+@end table
+
+@subsection Examples
+
+@itemize
+
+@item
+List input devices:
+@example
+ffmpeg -f decklink -list_devices 1 -i dummy
+@end example
+
+@item
+List supported formats:
+@example
+ffmpeg -f decklink -list_formats 1 -i 'Intensity Pro'
+@end example
+
+@item
+Capture video clip at 1080i50 (format 11):
+@example
+ffmpeg -f decklink -r 25 -i 'Intensity Pro@@11' -acodec copy -vcodec copy
output.avi
+@end example
+
+@end itemize
+
+
@c man end INPUT DEVICES
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index db301e7..8cf98f0 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -16,7 +16,8 @@ OBJS-$(CONFIG_ALSA_OUTDEV) +=
alsa-audio-common.o \
OBJS-$(CONFIG_AVFOUNDATION_INDEV)+= avfoundation.o
OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
OBJS-$(CONFIG_CACA_OUTDEV) += caca.o
-OBJS-$(CONFIG_DECKLINK_OUTDEV) += decklink_enc.o decklink_enc_c.o
+OBJ
Re: [FFmpeg-devel] Filters
> > From: Clément Bœsch >To: FFmpeg development discussions and patches >Sent: Sunday, 20 July 2014, 10:40 >Subject: Re: [FFmpeg-devel] Filters > > >On Fri, Jul 18, 2014 at 10:33:40PM +0100, JULIAN GARDNER wrote: >[...] >> fmpeg -i .ts -vcodec libx264 -b:v 1000k -acodec libfaac -async 1 -vf >> 'split [mark], drawbox=10:10:100:100:color=green [dontneed];[mark] >> drawbox=100:100:100;100:color=red [vid];[dontneed][vid] overlay' -y -f >> mpegts processed.ts >> > >try -filter_complex instead of -vf and >-map [vid] -y -f mpegts processed.ts -map '[dontneed]' -f null - > >[...] > >-- >Clément B. > Thanks for this, its 99% what i need apart from I lose the audio on the [vid] output. I want the small picture [160x100] output without audio and the 640x360 output with audio Commandlineffmpeg -threads 0 -i "udp://231.231.11.3:1234?localaddr=192.168.2.123" -filter_complex 'scale=iw/2:ih/2,split [mark], scale=160:90,drawbox=10:10:5:5:color=red [detect];[mark] drawbox=10:10:10:5:5:color=blue [vid]' -map [detect] -vcodec libx264 -preset faster -x264opts keyint=75 -x264opts bitrate=512 -bufsize 1M -r 25 -an -f mpegts "udp://238.170.112.96:1234?pkt_size=1316&buffer_size=1048576" -map [vid][0:a] -vcodec libx264 -preset faster -x264opts keyint=75 -x264opts bitrate=1150 -bufsize 1M -r 25 -acodec libfaac -ab 128k -ar 32k -ac 2 -f mpegts "udp://225.170.112.96:1234?pkt_size=1316&buffer_size=1048576" Output (as I know you love this)ffmpeg version N-63057-g63504d8 Copyright (c) 2000-2014 the FFmpeg developers built on Aug 14 2014 10:36:36 with gcc 4.6 (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04) configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libmp3lame --enable-libx264 --enable-libzvbi --cc='ccache cc' libavutil 52. 82.100 / 52. 82.100 libavcodec 55. 60.103 / 55. 60.103 libavformat 55. 37.102 / 55. 37.102 libavdevice 55. 13.101 / 55. 13.101 libavfilter 4. 5.100 / 4. 5.100 libswscale 2. 6.100 / 2. 6.100 libswresample 0. 18.100 / 0. 18.100 libpostproc 52. 3.100 / 52. 3.100 Input #0, mpegts, from 'udp://231.231.11.3:1234?localaddr=192.168.2.123': Duration: N/A, start: 12191.492622, bitrate: 128 kb/s Program 48 Stream #0:0[0x41]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc Stream #0:1[0x42]: Audio: mp2 ([4][0][0][0] / 0x0004), 48000 Hz, stereo, s16p, 128 kb/s Codec AVOption ab (set bitrate (in bits/s)) specified for output file #1 (udp://225.170.112.96:1234?pkt_size=1316&buffer_size=1048576) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream. [libx264 @ 0x2d72560] VBV maxrate unspecified, assuming CBR [libx264 @ 0x2d72560] using SAR=1/1 [libx264 @ 0x2d72560] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 [libx264 @ 0x2d72560] profile High, level 1.3 [libx264 @ 0x2d74d60] VBV maxrate unspecified, assuming CBR [libx264 @ 0x2d74d60] using SAR=1/1 [libx264 @ 0x2d74d60] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 [libx264 @ 0x2d74d60] profile High, level 3.0 Output #0, mpegts, to 'udp://238.170.112.96:1234?pkt_size=1316&buffer_size=1048576': Metadata: encoder : Lavf55.37.102 Stream #0:0: Video: h264 (libx264), yuv420p, 160x90 [SAR 1:1 DAR 16:9], q=-1--1, 512 kb/s, 90k tbn, 25 tbc Output #1, mpegts, to 'udp://225.170.112.96:1234?pkt_size=1316&buffer_size=1048576': Metadata: encoder : Lavf55.37.102 Stream #1:0: Video: h264 (libx264), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=-1--1, 1150 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 (h264) -> scale drawbox -> Stream #0:0 (libx264) drawbox -> Stream #1:0 (libx264) Press [q] to stop, [?] for help [mpegts @ 0x2d40fc0] New 0011 Table, version 255 to 0 frame= 130 fps= 26 q=-1.0 Lq=-1.0 size= 245kB time=00:00:05.12 bitrate= 392.2kbits/s dup=24 drop=224 any idea on how i can get the audio back joolz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] removing libmpcodecs for reuniting purposes.
>> I bet Michael or me could do this in 15 minutes.
>
> i had almost forgotten it but there is:
> { "src_v_chr_pos", "source vertical chroma position in luma grid/256"
> , OFFSET(src_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1}, -1,
> 512, VE },
> { "src_h_chr_pos", "source horizontal chroma position in luma
> grid/256", OFFSET(src_h_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1},
> -1, 512, VE },
> { "dst_v_chr_pos", "destination vertical chroma position in luma
> grid/256" , OFFSET(dst_v_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1
> }, -1, 512, VE },
> { "dst_h_chr_pos", "destination horizontal chroma position in luma
> grid/256", OFFSET(dst_h_chr_pos), AV_OPT_TYPE_INT, { .i64 = -1},
> -1, 512, VE },
Then i think it would work if you supplied each field with the correct
chroma position data.
I'll need to compare to the interlaced resizer in dirac I guess and
find a suitable sequence.
Kieran.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
Deti Fliegl fliegl.de> writes: > >> +av_log(NULL, AV_LOG_ERROR, > > > > Context should not be NULL. > Can hardly be done in this file unless you supply avctx as > argument in every function only for av_log purposes. Please do this. The patch you sent in your second mail is completely broken (a diff to your first patch?) and it made me remember that you should consider using tools/patcheck to check for things like tabs and trailing whitespace that our repository would refuse. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86: hevc: adding transform_add
On 18/08/14 5:01 AM, Pierre Edouard Lepere wrote: > Hi, > here's the new version of the patch. Sorry for the delay. > James, I have not done 8-bit AVX versions because it requires unpacks that > are done differently in AVX. Aren't you thinking of AVX2 with 256bits wide registers? With AVX i mean an xmm version of the function that takes advantage of the three-operand instruction format, which should be essentially the same as the SSE2 version except for the many saved movdqa between registers. Anyway, LGTM and this can be committed as is. There's some of room for improvements (AVX version, or making all the functions use 8 or less xmm registers) but that can be done later instead of sending the same patch a fourth time. Not sure if someone else wants to comment (Ronald?). > > Thanks for the feedback ! > > -Pierre-Edouard Lepere > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
Rebased commits to have all changes in one patch. Hopefully it's
complete now.
Deti
On 18.08.14 19:48, Deti Fliegl wrote:
> On 18.08.14 19:23, Carl Eugen Hoyos wrote:
>> Deti Fliegl fliegl.de> writes:
>>
>>> +/* free() is needed for a string returned by the DeckLink SDL. */
>>> +#undef free
>>
>> I believe this is not needed anymore but ...
> removed it - but this has been part of the existing code which I simply
> moved to a new file.
>
>>
>>> +free((void *) tmpDisplayName);
>>
>> ... please move the comment here.
> Done.
>
>> Is the cast necessary?
> Yes.
>
>>
>>> +av_log(NULL, AV_LOG_ERROR,
>>
>> Context should not be NULL.
> Can hardly be done in this file unless you supply avctx as argument in
> every function only for av_log purposes.
>
>>
>>> +av_log(NULL, AV_LOG_INFO, "Found Decklink mode %d x
>>> %d with rate %.2f%s\n", bmd_width, bmd_height,
>>> (float)bmd_tb_den/(float)bmd_tb_num,
>>> (ctx->bmd_field_dominance==bmdLowerFieldFirst ||
>>> ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":"");
>>
>> Please split this line.
> done.
>
>> Isn't your patch missing a configure check and
>> a change to Makefile?
> Must have missed some files to commit. Fixing patch attached to this mail.
>
>> (What is the license of the decklink libraries?)
> There is no DeckLink library code in my patch. The already existing
> decklink encoder support covers how to build ffmpeg with the DeckLink SDK.
>
> Deti
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
commit missing files
use avctx as context as often as possible
Signed-off-by: Deti fliegl
---
configure | 4 +-
doc/indevs.texi | 54 +
libavdevice/Makefile| 5 +-
libavdevice/alldevices.c| 2 +-
libavdevice/decklink_common.cpp | 229 ++
libavdevice/decklink_common.h | 98
libavdevice/decklink_common_c.h | 32 +++
libavdevice/decklink_dec.cpp| 520
libavdevice/decklink_dec.h | 32 +++
libavdevice/decklink_dec_c.c| 54 +
libavdevice/decklink_enc.cpp| 196 ++-
libavdevice/decklink_enc.h | 11 -
libavdevice/decklink_enc_c.c| 1 +
13 files changed, 1044 insertions(+), 194 deletions(-)
create mode 100644 libavdevice/decklink_common.cpp
create mode 100644 libavdevice/decklink_common.h
create mode 100644 libavdevice/decklink_common_c.h
create mode 100644 libavdevice/decklink_dec.cpp
create mode 100644 libavdevice/decklink_dec.h
create mode 100644 libavdevice/decklink_dec_c.c
diff --git a/configure b/configure
index f355dad..189542f 100755
--- a/configure
+++ b/configure
@@ -253,7 +253,7 @@ External library support:
native MPEG-4/Xvid encoder exists [no]
--enable-libzmq enable message passing via libzmq [no]
--enable-libzvbi enable teletext support via libzvbi [no]
- --enable-decklinkenable Blackmagick DeckLink output [no]
+ --enable-decklinkenable Blackmagick DeckLink I/O support [no]
--enable-openal enable OpenAL 1.1 capture support [no]
--enable-opencl enable OpenCL code
--enable-opengl enable OpenGL rendering [no]
@@ -2441,6 +2441,8 @@ bktr_indev_deps_any="dev_bktr_ioctl_bt848_h
machine_ioctl_bt848_h dev_video_bktr
caca_outdev_deps="libcaca"
decklink_outdev_deps="decklink pthreads"
decklink_outdev_extralibs="-lstdc++"
+decklink_indev_deps="decklink pthreads"
+decklink_indev_extralibs="-lstdc++"
dshow_indev_deps="IBaseFilter"
dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid"
dv1394_indev_deps="dv1394"
diff --git a/doc/indevs.texi b/doc/indevs.texi
index ce409b9..ddf4c44 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -922,4 +922,58 @@ Use the MIT-SHM extension for shared memory. Default value
is @code{1}.
It may be necessary to disable it for remote displays.
@end table
+@section decklink
+
+The decklink input device provides capture capabilities for Blackmagic
+DeckLink devices.
+
+To enable this input device, you need the Blackmagic DeckLink SDK and you
+need to configure with the appropriate @code{--extra-cflags}
+and @code{--extra-ldflags}.
+On Windows, you need to run the IDL files through @command{widl}.
+
+DeckLink is very picky about the formats it supports. Pixel format is always
+uyvy422, framerate and video size must be determined for your device with
+@command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
+of channels currently is limited to 2 (stereo).
+
+@subsection Options
+
+@table @option
+
+@item list_devices
+If set to @option{true}, print a list of devices and exit.
+Defaults to @option{false}.
+
+@item list_formats
+If set to @option{true}, print a list of supported formats and exit.
+Defaults to @option{false}.
+
+@end table
+
+@subsection Example
Re: [FFmpeg-devel] [PATCH] Add input support for DeckLink devices.
On 18.08.14 20:05, Carl Eugen Hoyos wrote: > Deti Fliegl fliegl.de> writes: > +av_log(NULL, AV_LOG_ERROR, >>> >>> Context should not be NULL. >> Can hardly be done in this file unless you supply avctx as >> argument in every function only for av_log purposes. > > Please do this. Done with my last commit. > The patch you sent in your second mail is completely broken > (a diff to your first patch?) and it made me remember that > you should consider using tools/patcheck to check for things > like tabs and trailing whitespace that our repository would > refuse. I am sorry. This should be fixed by now. See my last mail. Deti ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/proresenc_kostya: allocate 1 slice more to avoid triggering the reallocation warning when the used space is actually less than the allocated
Signed-off-by: Michael Niedermayer
---
libavcodec/proresenc_kostya.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 1e40dcf..2c09e03 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -939,7 +939,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
int slice_hdr_size = 2 + 2 * (ctx->num_planes - 1);
int frame_size, picture_size, slice_size;
int pkt_size, ret;
-int max_slice_size = (ctx->frame_size_upper_bound - 200) /
ctx->pictures_per_frame / ctx->slices_per_picture;
+int max_slice_size = (ctx->frame_size_upper_bound - 200) /
(ctx->pictures_per_frame * ctx->slices_per_picture + 1);
uint8_t frame_flags;
*avctx->coded_frame = *pic;
@@ -1247,16 +1247,16 @@ static av_cold int encode_init(AVCodecContext *avctx)
ctx->bits_per_mb += ls * 4;
}
-ctx->frame_size_upper_bound = ctx->pictures_per_frame *
- ctx->slices_per_picture *
+ctx->frame_size_upper_bound = (ctx->pictures_per_frame *
+ ctx->slices_per_picture + 1) *
(2 + 2 * ctx->num_planes +
(mps * ctx->bits_per_mb) / 8)
+ 200;
if (ctx->alpha_bits) {
// The alpha plane is run-coded and might exceed the bit budget.
- ctx->frame_size_upper_bound += ctx->pictures_per_frame *
-ctx->slices_per_picture *
+ ctx->frame_size_upper_bound += (ctx->pictures_per_frame *
+ ctx->slices_per_picture + 1) *
/* num pixels per slice */ (ctx->mbs_per_slice * 256 *
/* bits per pixel */(1 + ctx->alpha_bits + 1) + 7 >> 3);
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/proresenc_kostya: set initial max_slice_size based on frame_size_upper_bound
Signed-off-by: Michael Niedermayer
---
libavcodec/proresenc_kostya.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 0f69767..1e40dcf 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -938,7 +938,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
int sizes[4] = { 0 };
int slice_hdr_size = 2 + 2 * (ctx->num_planes - 1);
int frame_size, picture_size, slice_size;
-int pkt_size, ret, max_slice_size = 0;
+int pkt_size, ret;
+int max_slice_size = (ctx->frame_size_upper_bound - 200) /
ctx->pictures_per_frame / ctx->slices_per_picture;
uint8_t frame_flags;
*avctx->coded_frame = *pic;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] alac: add option to decoded incorrect ALAC
On Mon, Aug 18, 2014 at 04:06:30PM +0200, Paul B Mahol wrote: > On 8/18/14, Christophe Gisquet wrote: > > Hi, > > > > this is a proposal to allow decoding incorrect files. There is no > > obvious and systematic way to detect them however. > > > > -- > > Christophe > > > > AFAIK it is missing AVClass *class in codec context. added removed version.h change applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] huffyuvenc, multithread and context=1
On Mon, Aug 18, 2014 at 03:02:14PM +0200, Christophe Gisquet wrote: > Hi, > > 2014-06-19 6:23 GMT+02:00 Michael Niedermayer : > > patch applied > > Am I missing something or was it not applied? the "[PATCH 1/2] huffyuv: change statistics initialization" patch has has been applied git says: git am -3 Applying: huffyuv: change statistics initialization Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... No changes -- Patch already applied. is there some other patch ive missed ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] isom: add ni24 to pcm_s24le
patch requested by ubitux.
found in code dump from kierank:
+{ CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC
typo fix for using ni24 instead of in24 (#3051) */ //GARYH added
(sorry for inline)
-compn
diff --git a/libavformat/isom.c b/libavformat/isom.c
index d768c32..613d5ec 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -292,6 +292,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
+{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
{ AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
{ AV_CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },
{ AV_CODEC_ID_PCM_S8, MKTAG('s', 'o', 'w', 't') },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] isom: add ni24 to pcm_s24le
On Mon, Aug 18, 2014 at 04:42:15PM -0400, compn wrote:
> patch requested by ubitux.
>
> found in code dump from kierank:
>
> +{ CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC
> typo fix for using ni24 instead of in24 (#3051) */ //GARYH added
>
> (sorry for inline)
>
Why do you remove the comment? Please mention more exactly where this
comes from ("dump from kierank" gives no clue about authorship).
I'd suggest you mention all of this in the commit message (that is why I
wanted you to send a proper patch here; it's not about the diff itself).
> -compn
>
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index d768c32..613d5ec 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -292,6 +292,7 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
> { AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
> { AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
> { AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
> +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
> { AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
> { AV_CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },
> { AV_CODEC_ID_PCM_S8, MKTAG('s', 'o', 'w', 't') },
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Clément B.
pgpsgg5Ud_UdY.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/isom: add ni24 typo/alias for in24
This is adapted from Elemental/libavformat.isom.c.patch by a certain
GARYH. The original patch only includes the LE version.
See also
http://lists.apple.com/archives/quicktime-users/2009/Oct/msg00048.html
---
libavformat/isom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/isom.c b/libavformat/isom.c
index d768c32..8daff62 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -292,6 +292,8 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
{ AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
{ AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
{ AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
+{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') }, /* BBC typo */
+{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC typo */
{ AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
{ AV_CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },
{ AV_CODEC_ID_PCM_S8, MKTAG('s', 'o', 'w', 't') },
--
2.0.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavd/pulse_audio_dec: use default source when no input provided
On Mon, Aug 18, 2014 at 02:14:23PM +0200, Lukasz Marek wrote: > On 07.08.2014 15:36, Michael Niedermayer wrote: > >On Thu, Aug 07, 2014 at 01:58:55AM +0200, Lukasz Marek wrote: > >>PulseAudio expilitly requires name of the source. > >>This patch makes it use default source when not provided. > >>It simplifies programistic use. > >> > >>Signed-off-by: Lukasz Marek > >>--- > >> libavdevice/pulse_audio_dec.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > >LGTM > > You can merge this one. > > Second one is up to you. patches 1+2 applied btw, if you want a git write account send me your public SSH key thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/isom: add ni24 typo/alias for in24
On Mon, Aug 18, 2014 at 11:01:39PM +0200, Clément Bœsch wrote:
> This is adapted from Elemental/libavformat.isom.c.patch by a certain
> GARYH. The original patch only includes the LE version.
>
> See also
> http://lists.apple.com/archives/quicktime-users/2009/Oct/msg00048.html
> ---
> libavformat/isom.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index d768c32..8daff62 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -292,6 +292,8 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
> { AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
> { AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
> { AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
> +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') }, /* BBC typo
> */
> +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC typo
> */
> { AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
> { AV_CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },
> { AV_CODEC_ID_PCM_S8, MKTAG('s', 'o', 'w', 't') },
Note: no sample, and can't confirm if the BE one makes sense.
--
Clément B.
pgpp_anpjYvX1.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Fwd: [PATCH] libavformat: Add poster_time and time_scale to quicktime metadata output
I'm wondering if this patch request got missed? ... or if I neglected something
when submitting? ... Any feedback appreciated.
Cheers
GT
Graham Torn
graham.t...@gmail.com
Begin forwarded message:
> From: Graham Torn
> Subject: [PATCH] libavformat: Add poster_time and time_scale to quicktime
> metadata output
> Date: August 14, 2014 at 13:24:37 MDT
> To: ffmpeg-devel@ffmpeg.org
> Cc: gt-sdi
>
> From: gt-sdi
>
> Extract poster_time and time_scale from quicktime mdhd atom
> and add to metadata for output by ffprobe.
>
> Signed-off-by: gt-sdi
> ---
> libavformat/mov.c | 27 +--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 767833e..b49592b 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -850,9 +850,28 @@ static int mov_read_mdhd(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
> return 0;
> }
>
> +static void mov_metadata_time_scale(AVDictionary **metadata, int time)
> +{
> +char buffer[32];
> +if (time) {
> +snprintf(buffer, sizeof(buffer), "%i", time);
> +av_dict_set(metadata, "time_scale", buffer, 0);
> +}
> +}
> +
> +static void mov_metadata_poster_time(AVDictionary **metadata, int64_t time)
> +{
> +char buffer[32];
> +if (time) {
> +snprintf(buffer, sizeof(buffer), "%" PRId64, time);
> +av_dict_set(metadata, "poster_time", buffer, 0);
> +}
> +}
> +
> static int mov_read_mvhd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> int64_t creation_time;
> +int64_t poster_time;
> int version = avio_r8(pb); /* version */
> avio_rb24(pb); /* flags */
>
> @@ -864,8 +883,9 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
> avio_rb32(pb); /* modification time */
> }
> mov_metadata_creation_time(&c->fc->metadata, creation_time);
> -c->time_scale = avio_rb32(pb); /* time scale */
>
> +c->time_scale = avio_rb32(pb); /* time scale */
> +mov_metadata_time_scale(&c->fc->metadata, c->time_scale);
> av_dlog(c->fc, "time scale = %i\n", c->time_scale);
>
> c->duration = (version == 1) ? avio_rb64(pb) : avio_rb32(pb); /* duration
> */
> @@ -883,7 +903,10 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
>
> avio_rb32(pb); /* preview time */
> avio_rb32(pb); /* preview duration */
> -avio_rb32(pb); /* poster time */
> +
> +poster_time = avio_rb32(pb); /* poster time */
> +mov_metadata_poster_time(&c->fc->metadata, poster_time);
> +
> avio_rb32(pb); /* selection time */
> avio_rb32(pb); /* selection duration */
> avio_rb32(pb); /* current time */
> --
> 2.0.4
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/isom: add ni24 typo/alias for in24
On Mon, Aug 18, 2014 at 11:01:39PM +0200, Clément Bœsch wrote:
> This is adapted from Elemental/libavformat.isom.c.patch by a certain
> GARYH. The original patch only includes the LE version.
>
> See also
> http://lists.apple.com/archives/quicktime-users/2009/Oct/msg00048.html
> ---
> libavformat/isom.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index d768c32..8daff62 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -292,6 +292,8 @@ const AVCodecTag ff_codec_movaudio_tags[] = {
> { AV_CODEC_ID_PCM_S16LE, MKTAG('l', 'p', 'c', 'm') },
> { AV_CODEC_ID_PCM_S24BE, MKTAG('i', 'n', '2', '4') },
> { AV_CODEC_ID_PCM_S24LE, MKTAG('i', 'n', '2', '4') },
> +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') }, /* BBC typo
> */
> +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC typo
> */
> { AV_CODEC_ID_PCM_S32BE, MKTAG('i', 'n', '3', '2') },
> { AV_CODEC_ID_PCM_S32LE, MKTAG('i', 'n', '3', '2') },
> { AV_CODEC_ID_PCM_S8, MKTAG('s', 'o', 'w', 't') },
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add poster_time and time_scale to quicktime metadata output
Hi
On Thu, Aug 14, 2014 at 01:24:37PM -0600, Graham Torn wrote:
> From: gt-sdi
>
> Extract poster_time and time_scale from quicktime mdhd atom
> and add to metadata for output by ffprobe.
>
> Signed-off-by: gt-sdi
> ---
> libavformat/mov.c | 27 +--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 767833e..b49592b 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -850,9 +850,28 @@ static int mov_read_mdhd(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
> return 0;
> }
>
> +static void mov_metadata_time_scale(AVDictionary **metadata, int time)
> +{
> +char buffer[32];
> +if (time) {
> +snprintf(buffer, sizeof(buffer), "%i", time);
> +av_dict_set(metadata, "time_scale", buffer, 0);
> +}
> +}
> +
> +static void mov_metadata_poster_time(AVDictionary **metadata, int64_t time)
> +{
> +char buffer[32];
> +if (time) {
> +snprintf(buffer, sizeof(buffer), "%" PRId64, time);
> +av_dict_set(metadata, "poster_time", buffer, 0);
> +}
> +}
see av_dict_set_int()
> +
> static int mov_read_mvhd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> {
> int64_t creation_time;
> +int64_t poster_time;
> int version = avio_r8(pb); /* version */
> avio_rb24(pb); /* flags */
>
> @@ -864,8 +883,9 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext *pb,
> MOVAtom atom)
> avio_rb32(pb); /* modification time */
> }
> mov_metadata_creation_time(&c->fc->metadata, creation_time);
> -c->time_scale = avio_rb32(pb); /* time scale */
>
> +c->time_scale = avio_rb32(pb); /* time scale */
> +mov_metadata_time_scale(&c->fc->metadata, c->time_scale);
> av_dlog(c->fc, "time scale = %i\n", c->time_scale);
>
> c->duration = (version == 1) ? avio_rb64(pb) : avio_rb32(pb); /*
> duration */
when transcoding this can end up being stored in the destination
file. considering that could even be a mov file, this seems
sub optimal
note see, "duration" and "encoder" on other similar metadata that is
not just unconditionally copied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: add fontcolor option
On Mon, Aug 18, 2014 at 7:03 AM, Timothy Gu wrote: > On Sun, Aug 17, 2014 at 4:54 PM, Muhammad Faiz wrote: > > This fontcolor option uses arithmetic expression, not color value, > > so color names aren't available. > > Thank's > > You should use AV_OPT_TYPE_COLOR instead of AV_OPT_TYPE_STRING to make > the color names usable. Look at how vf_drawtext is doing it. > The main goal is to compute color from frequency where it is evaluated. I think AV_OPT_TYPE_COLOR doesn't have this capability. Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
On Thu, Aug 14, 2014 at 12:03:25PM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-12 12:44 GMT+02:00 Christophe Gisquet : > > Forgot a parameter to the call to avpriv_request_sample, will be added > > later. > > If there's no further comment on this option for the reallocation, > here's an updated patch. > > -- > Christophe > proresenc_kostya.c | 37 - > 1 file changed, 36 insertions(+), 1 deletion(-) > 403c44b2dadd7bc81072bea4252519daed260dc3 > 0001-proresenc_kostya-realloc-if-buffer-too-small.patch > From 4ea51dc2cec915ce4c84db92febd8960bb44b650 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Mon, 11 Aug 2014 19:37:39 +0200 > Subject: [PATCH 1/2] proresenc_kostya: realloc if buffer too small > > The buffer allocation may be incorrect (e.g. with an alpha plane), > and currently causes the buffer to be set to NULL by init_put_bits, > later on causing crashing. > > So, detect that situation, and if detected, reallocate the buffer > and ask a sample if it happens. > > Fixes ticket #2760 > --- > libavcodec/proresenc_kostya.c | 37 - > 1 file changed, 36 insertions(+), 1 deletion(-) a variant of this was merged [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/wavdec: add sanity check for AVCodecContext.channels
On 18/08/14 4:42 AM, Michael Niedermayer wrote: > On Mon, Aug 18, 2014 at 03:14:01AM -0300, James Almer wrote: >> Fixes ticket #3862. >> As a side effect, this also fixes aac_latm in wav. >> >> Signed-off-by: James Almer > > applied > > >> --- >> Maybe a check for channels <= 0 should be also added to ff_get_wav_header() >> right after the sample_rate one? > > sounds reasonable, would need to be tested though It seems that according to the wav spec, "channels" can only have values from 1 to UINT16_MAX, so a wav header where it's 0 means it's most assuredly broken. Fate passes after adding a check to ff_get_wav_header(). Is there some other kind of test that could be done? > > 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
Re: [FFmpeg-devel] [PATCH] lavfi/apad: fix logic when whole_len or pad_len options are specified
On Mon, Aug 18, 2014 at 02:53:45PM +0200, Stefano Sabatini wrote: > --- > libavfilter/af_apad.c | 29 + > 1 file changed, 17 insertions(+), 12 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Do not ask for mxf samples with unknown field dominance
Hi! Attached patch removes a request for samples of which we already have several that all work fine. Please comment, Carl Eugendiff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c index 7a4633f..aabae69 100644 --- a/libavformat/mxfdec.c +++ b/libavformat/mxfdec.c @@ -1603,9 +1603,6 @@ static int mxf_parse_structural_metadata(MXFContext *mxf) st->codec->field_order = AV_FIELD_BB; break; default: -avpriv_request_sample(mxf->fc, - "Field dominance %d support", - descriptor->field_dominance); break; } /* Turn field height into frame height. */ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/wavdec: add sanity check for AVCodecContext.channels
On Mon, Aug 18, 2014 at 07:44:39PM -0300, James Almer wrote: > On 18/08/14 4:42 AM, Michael Niedermayer wrote: > > On Mon, Aug 18, 2014 at 03:14:01AM -0300, James Almer wrote: > >> Fixes ticket #3862. > >> As a side effect, this also fixes aac_latm in wav. > >> > >> Signed-off-by: James Almer > > > > applied > > > > > >> --- > >> Maybe a check for channels <= 0 should be also added to ff_get_wav_header() > >> right after the sample_rate one? > > > > sounds reasonable, would need to be tested though > > It seems that according to the wav spec, "channels" can only have values from > 1 to > UINT16_MAX, so a wav header where it's 0 means it's most assuredly broken. > > Fate passes after adding a check to ff_get_wav_header(). Is there some other > kind > of test that could be done? probably not, one could test *.wav that one has locally to see if any change [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Set H264 bitrate
Hi!
Attached patch from MIKEH / Elemental is apparently meant to implement
setting h264 bitrate. It makes no difference for the sample from ticket
#3392.
I have no idea how to attribute the patch.
Please comment, Carl Eugendiff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 2013670..2f48f72 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -130,6 +130,7 @@ static const uint8_t default_scaling8[2][64] = {
static inline int decode_hrd_parameters(H264Context *h, SPS *sps)
{
int cpb_count, i;
+int bit_rate_scale, bit_rate_value = 0;
cpb_count = get_ue_golomb_31(&h->gb) + 1;
if (cpb_count > 32U) {
@@ -137,13 +138,15 @@ static inline int decode_hrd_parameters(H264Context *h, SPS *sps)
return AVERROR_INVALIDDATA;
}
-get_bits(&h->gb, 4); /* bit_rate_scale */
+bit_rate_scale = get_bits(&h->gb, 4); /* bit_rate_scale */
get_bits(&h->gb, 4); /* cpb_size_scale */
for (i = 0; i < cpb_count; i++) {
-get_ue_golomb_long(&h->gb); /* bit_rate_value_minus1 */
+bit_rate_value = get_ue_golomb_long(&h->gb); /* bit_rate_value_minus1 */
get_ue_golomb_long(&h->gb); /* cpb_size_value_minus1 */
get_bits1(&h->gb); /* cbr_flag */
}
+if (bit_rate_value)
+h->avctx->bit_rate = bit_rate_value + 1 << bit_rate_scale + 6;
sps->initial_cpb_removal_delay_length = get_bits(&h->gb, 5) + 1;
sps->cpb_removal_delay_length = get_bits(&h->gb, 5) + 1;
sps->dpb_output_delay_length = get_bits(&h->gb, 5) + 1;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Fix maximum wma superframe size
Hi! Attached patch from Elemental increases the maximum superframe size, I don't know if this fixes any samples. The original patchfile contains no further attribution. Please comment, Carl Eugendiff --git a/libavcodec/wma.h b/libavcodec/wma.h index c4056ec..37be627 100644 --- a/libavcodec/wma.h +++ b/libavcodec/wma.h @@ -40,8 +40,7 @@ #define NB_LSP_COEFS 10 -/* XXX: is it a suitable value ? */ -#define MAX_CODED_SUPERFRAME_SIZE 16384 +#define MAX_CODED_SUPERFRAME_SIZE (1 << 16) #define MAX_CHANNELS 2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] isom: add ni24 to pcm_s24le
On Mon, 18 Aug 2014 22:49:13 +0200
Clément Bœsch wrote:
> On Mon, Aug 18, 2014 at 04:42:15PM -0400, compn wrote:
> > +{ CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') }, /* BBC
> > typo fix for using ni24 instead of in24 (#3051) */ //GARYH added
> Why do you remove the comment?
because the #3051 is not an ffmpeg bug, i'm guessing its a bug with
wherever this came from.
also "bbc typo fix" tells us nothing useful.
likewise "GARYH". who is gary h? on irc? ml? no contact info?
i didnt investigate further into where this came from. nor did i find
it relevant to tag the commit with a bunch of random companies
(bbc/elemental).
to each his own.
-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/isom: add ni24 typo/alias for in24
Clément Bœsch pkh.me> writes:
> +{ AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
> BBC typo */
> +{ AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
> /* BBC typo */
Doesn't this patch make absolutely sure that the same
files that didn't work before this patch (and that
were fixed by the Elemental patch) don't work with
the patch applied?
Or do I miss something?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Set H264 bitrate
On 19 August 2014 00:32, Carl Eugen Hoyos wrote: > Hi! > > Attached patch from MIKEH / Elemental is apparently meant to implement > setting h264 bitrate. It makes no difference for the sample from ticket > #3392. This patch is nonsensical unfortunately. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 18 August 2014 23:15, Andreas Cadhalpun wrote: > Why is FFmpeg treated differently than MariaDB/PerconaDB? > That's a very good question really. But reading some of the comments in regards to having a nay for including project that duplicate code, my guess is that it's a totally irrational decision ; and one that has very little technical basis at that. Also gotta love when the security breach are actually unique to Debian because some package maintainer has decided he knew better and happily broke things. SSL anyone? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/tiff: add support for YUV deflate
Signed-off-by: James Almer
---
Seems to work great with yuv deflate tiff images created with our tiff encoder
libavcodec/tiff.c | 71 +++
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 73bf828..7acfe7b 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -283,6 +283,34 @@ static int deinvert_buffer(TiffContext *s, const uint8_t
*src, int size)
return 0;
}
+static void unpack_yuv(TiffContext *s, AVFrame *p,
+ const uint8_t *src, int lnum)
+{
+int i, j, k;
+int w = (s->width - 1) / s->subsampling[0] + 1;
+uint8_t *pu = &p->data[1][lnum / s->subsampling[1] * p->linesize[1]];
+uint8_t *pv = &p->data[2][lnum / s->subsampling[1] * p->linesize[2]];
+if (s->width % s->subsampling[0] || s->height % s->subsampling[1]) {
+for (i = 0; i < w; i++) {
+for (j = 0; j < s->subsampling[1]; j++)
+for (k = 0; k < s->subsampling[0]; k++)
+p->data[0][FFMIN(lnum + j, s->height-1) * p->linesize[0] +
+ FFMIN(i * s->subsampling[0] + k, s->width-1)] =
*src++;
+*pu++ = *src++;
+*pv++ = *src++;
+}
+}else{
+for (i = 0; i < w; i++) {
+for (j = 0; j < s->subsampling[1]; j++)
+for (k = 0; k < s->subsampling[0]; k++)
+p->data[0][(lnum + j) * p->linesize[0] +
+ i * s->subsampling[0] + k] = *src++;
+*pu++ = *src++;
+*pv++ = *src++;
+}
+}
+}
+
#if CONFIG_ZLIB
static int tiff_uncompress(uint8_t *dst, unsigned long *len, const uint8_t
*src,
int size)
@@ -305,9 +333,9 @@ static int tiff_uncompress(uint8_t *dst, unsigned long
*len, const uint8_t *src,
return zret == Z_STREAM_END ? Z_OK : zret;
}
-static int tiff_unpack_zlib(TiffContext *s, uint8_t *dst, int stride,
+static int tiff_unpack_zlib(TiffContext *s, AVFrame *p, uint8_t *dst, int
stride,
const uint8_t *src, int size,
-int width, int lines)
+int width, int lines, int strip_start)
{
uint8_t *zbuf;
unsigned long outlen;
@@ -338,6 +366,10 @@ static int tiff_unpack_zlib(TiffContext *s, uint8_t *dst,
int stride,
} else {
memcpy(dst, src, width);
}
+if (s->photometric == TIFF_PHOTOMETRIC_YCBCR) {
+unpack_yuv(s, p, dst, strip_start + line);
+line += s->subsampling[1] - 1;
+}
dst += stride;
src += width;
}
@@ -383,35 +415,6 @@ static int tiff_unpack_fax(TiffContext *s, uint8_t *dst,
int stride,
return ret;
}
-static void unpack_yuv(TiffContext *s, AVFrame *p,
- const uint8_t *src, int lnum)
-{
-int i, j, k;
-int w = (s->width - 1) / s->subsampling[0] + 1;
-uint8_t *pu = &p->data[1][lnum / s->subsampling[1] * p->linesize[1]];
-uint8_t *pv = &p->data[2][lnum / s->subsampling[1] * p->linesize[2]];
-if (s->width % s->subsampling[0] || s->height % s->subsampling[1]) {
-for (i = 0; i < w; i++) {
-for (j = 0; j < s->subsampling[1]; j++)
-for (k = 0; k < s->subsampling[0]; k++)
-p->data[0][FFMIN(lnum + j, s->height-1) * p->linesize[0] +
- FFMIN(i * s->subsampling[0] + k, s->width-1)] =
*src++;
-*pu++ = *src++;
-*pv++ = *src++;
-}
-}else{
-for (i = 0; i < w; i++) {
-for (j = 0; j < s->subsampling[1]; j++)
-for (k = 0; k < s->subsampling[0]; k++)
-p->data[0][(lnum + j) * p->linesize[0] +
- i * s->subsampling[0] + k] = *src++;
-*pu++ = *src++;
-*pv++ = *src++;
-}
-}
-}
-
-
static int tiff_unpack_strip(TiffContext *s, AVFrame *p, uint8_t *dst, int
stride,
const uint8_t *src, int size, int strip_start,
int lines)
{
@@ -443,12 +446,8 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
}
if (s->compr == TIFF_DEFLATE || s->compr == TIFF_ADOBE_DEFLATE) {
-if (is_yuv) {
-av_log(s->avctx, AV_LOG_ERROR, "YUV deflate is unsupported");
-return AVERROR_PATCHWELCOME;
-}
#if CONFIG_ZLIB
-return tiff_unpack_zlib(s, dst, stride, src, size, width, lines);
+return tiff_unpack_zlib(s, p, dst, stride, src, size, width, lines,
strip_start);
#else
av_log(s->avctx, AV_LOG_ERROR,
"zlib support not enabled, "
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Fix maximum wma superframe size
Am 19.08.2014 01:34 schrieb "Carl Eugen Hoyos" : > > Hi! > > Attached patch from Elemental increases the maximum superframe size, I don't know if this fixes any samples. > The original patchfile contains no further attribution. > > Please comment, Carl Eugen It makes no sense to send random patches without either understanding the code in question or at least having a sample that it fixes. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: add fontcolor option
On Mon, Aug 18, 2014 at 06:54:55AM +0700, Muhammad Faiz wrote:
> This fontcolor option uses arithmetic expression, not color value,
> so color names aren't available.
> Thank's
>
> ---
> doc/filters.texi | 20 +++
> libavfilter/avf_showcqt.c | 84
> ++-
> 2 files changed, 81 insertions(+), 23 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 0ca1d6f..958b48e 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10610,6 +10610,26 @@ Default value is @code{3.0}.
> @item fontfile
> Specify font file for use with freetype. If not specified, use embedded font.
>
> +@item fontcolor
> +Specify font color expression. This is arithmetic expression that should
> return
> +integer value 0xRRGGBB. The expression can contain variables:
> +@table @option
> +@item frequency, freq, f
> +the frequency where transform is evaluated
> +@item timeclamp, tc
> +value of timeclamp option
> +@end table
> +and functions:
> +@table @option
> +@item midi(f)
> +midi number of frequency f
> +@item r(x), g(x), b(x)
> +red, green, and blue value of intensity x
> +@end table
> +Default value is @code{st(0, (midi(f)-59.5)/12);
> +st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));
> +r(1-ld(1)) + b(ld(1)}
> +
Can you suggest an alternative in the examples? (maybe with some green?)
> @item fullhd
> If set to 1 (the default), the video size is 1920x1080 (full HD),
> if set to 0, the video size is 960x540. Use this option to make CPU usage
> lower.
> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
> index 012362b..d349c3d 100644
> --- a/libavfilter/avf_showcqt.c
> +++ b/libavfilter/avf_showcqt.c
> @@ -54,6 +54,9 @@
> #define TLENGTH_DEFAULT "384/f*tc/(384/f+tc)"
> #define VOLUME_MIN 1e-10
> #define VOLUME_MAX 100.0
> +#define FONTCOLOR_DEFAULT "st(0, (midi(f)-59.5)/12);" \
> +"st(1, if(between(ld(0),0,1), 0.5-0.5*cos(2*PI*ld(0)), 0));" \
> +"r(1-ld(1)) + b(ld(1))"
>
> typedef struct {
> FFTSample value;
> @@ -73,7 +76,7 @@ typedef struct {
> uint8_t *font_alpha;
> char *fontfile; /* using freetype */
> int coeffs_len[VIDEO_WIDTH];
> -uint8_t font_color[VIDEO_WIDTH];
> +uint8_t fontcolor_value[VIDEO_WIDTH*3]; /* result of fontcolor option */
> int64_t frame_count;
> int spectogram_count;
> int spectogram_index;
> @@ -82,6 +85,7 @@ typedef struct {
> int remaining_fill;
> char *tlength;
> char *volume;
> +char *fontcolor;
> double timeclamp; /* lower timeclamp, time-accurate, higher timeclamp,
> freq-accurate (at low freq)*/
> float coeffclamp; /* lower coeffclamp, more precise, higher
> coeffclamp, faster */
> int fullhd; /* if true, output video is at full HD resolution,
> otherwise it will be halved */
> @@ -103,6 +107,7 @@ static const AVOption showcqt_options[] = {
> { "fps", "set video fps", OFFSET(fps), AV_OPT_TYPE_INT, { .i64 = 25 },
> 10, 100, FLAGS },
> { "count", "set number of transform per frame", OFFSET(count),
> AV_OPT_TYPE_INT, { .i64 = 6 }, 1, 30, FLAGS },
> { "fontfile", "set font file", OFFSET(fontfile), AV_OPT_TYPE_STRING, {
> .str = NULL }, CHAR_MIN, CHAR_MAX, FLAGS },
> +{ "fontcolor", "set font color", OFFSET(fontcolor), AV_OPT_TYPE_STRING,
> { .str = FONTCOLOR_DEFAULT }, CHAR_MIN, CHAR_MAX, FLAGS },
> { NULL }
> };
>
> @@ -275,6 +280,29 @@ static double c_weighting(void *p, double f)
> return ret;
> }
>
> +static double midi(void *p, double f)
> +{
> +return log2(f/440.0) * 12.0 + 69.0;
> +}
> +
> +static double r_func(void *p, double x)
> +{
> +x = FFMAX(0.0, FFMIN(1.0, x));
av_clipd()?
> +return (int)(x*255.0+0.5) << 16;
> +}
> +
> +static double g_func(void *p, double x)
> +{
> +x = FFMAX(0.0, FFMIN(1.0, x));
> +return (int)(x*255.0+0.5) << 8;
> +}
> +
> +static double b_func(void *p, double x)
> +{
> +x = FFMAX(0.0, FFMIN(1.0, x));
> +return (int)(x*255.0+0.5);
> +}
> +
> static inline int qsort_sparsecoeff(const SparseCoeff *a, const SparseCoeff
> *b)
> {
> if (fabsf(a->value) >= fabsf(b->value))
> @@ -288,10 +316,13 @@ static int config_output(AVFilterLink *outlink)
> AVFilterContext *ctx = outlink->src;
> AVFilterLink *inlink = ctx->inputs[0];
> ShowCQTContext *s = ctx->priv;
> -AVExpr *tlength_expr, *volume_expr;
> +AVExpr *tlength_expr, *volume_expr, *fontcolor_expr;
> +uint8_t *fontcolor_value = s->fontcolor_value;
> static const char * const expr_vars[] = { "timeclamp", "tc",
> "frequency", "freq", "f", NULL };
> static const char * const expr_func_names[] = { "a_weighting",
> "b_weighting", "c_weighting", NULL };
> +static const char * const expr_fontcolor_func_names[] = { "midi", "r",
> "g", "b", NULL };
> static double (* const expr_funcs[])(void *, double) = { a_weighting,
> b_weighting, c_weighting, NULL };
> +static double (* const e
[FFmpeg-devel] [PATCH] avfilter/atempo: Flush all buffered input samples
Fixes ticket #3829
---
libavfilter/af_atempo.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 6a3fd61..fcd0cb0 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -949,7 +949,13 @@ static int yae_flush(ATempoContext *atempo,
}
}
-// flush the remaininder of the current fragment:
+// check whether all of the input samples have been consumed:
+if (frag->position[0] + frag->nsamples < atempo->position[0]) {
+yae_advance_to_next_frag(atempo);
+return AVERROR(EAGAIN);
+}
+
+// flush the remainder of the current fragment:
start_here = FFMAX(atempo->position[1], overlap_end);
stop_here = frag->position[1] + frag->nsamples;
offset = start_here - frag->position[1];
--
1.8.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Set H264 bitrate
On 19.08.2014, at 02:24, Kieran Kunhya wrote: > On 19 August 2014 00:32, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch from MIKEH / Elemental is apparently meant to implement >> setting h264 bitrate. It makes no difference for the sample from ticket >> #3392. > > This patch is nonsensical unfortunately. Could you expand on that? The only obvious issue I see is that bit_rate_value should be summed up instead of using only the last value. I suspect that is just a typo though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
