Re: [FFmpeg-devel] Filter_mb_edge
I finally got it ... The explanation is in h264dsp_template.c (big bunch of macro, yummy !) De : ffmpeg-devel-boun...@ffmpeg.org ffmpeg-devel-boun...@ffmpeg.org de la part de Nicolas Derouineau nicolas.derouin...@vitec.com Envoyé : lundi 1 septembre 2014 17:22 À : ffmpeg-devel@ffmpeg.org Objet : [FFmpeg-devel] Filter_mb_edge Hello, I would like to understand the prototype of this function: filter_mb_edgeh(uint8_t *pix, int stride, const int16_t bS[4], unsigned int qp, int a, int b, H264Context *h, int intra) Let's say I want to check the filtering condition on p0,1,2 and q0,1,2 . How am I supposed to read the pix buffer to get them ? Correct me if I'm wrong: On a 16x16 macroblock, considering abcd are the vertical boundaries, and efgh are the horizontal one: /* Filtering a */ filter_mb_edgev( img_y[4*0pixel_shift], linesize, bS3, qp, a, b, h, 0); /* Filtering b */ filter_mb_edgev( img_y[4*1pixel_shift], linesize, bS3, qp, a, b, h, 0); /* Filtering c */ filter_mb_edgev( img_y[4*2pixel_shift], linesize, bS3, qp, a, b, h, 0); I guess img_y[0], img_y[stride] gives p0, p1, but how am I supposed to get q0 and q1 ? Regards, Nicolas DEROUINEAU ___ 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 1/2] avcodec/rawdec: Support CODEC_CAP_PARAM_CHANGE
On 9/2/14, Michael Niedermayer michae...@gmx.at wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/rawdec.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 305c13e..28792a1 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -98,19 +98,6 @@ static av_cold int raw_init_decoder(AVCodecContext
*avctx)
memset(context-palette-data, 0, AVPALETTE_SIZE);
}
-if ((avctx-bits_per_coded_sample == 4 || avctx-bits_per_coded_sample
== 2)
-avctx-pix_fmt == AV_PIX_FMT_PAL8
- (!avctx-codec_tag || avctx-codec_tag == MKTAG('r','a','w',' ')))
{
-context-is_2_4_bpp = 1;
-context-frame_size = avpicture_get_size(avctx-pix_fmt,
- FFALIGN(avctx-width,
16),
- avctx-height);
-} else {
-context-is_lt_16bpp = av_get_bits_per_pixel(desc) == 16
avctx-bits_per_coded_sample avctx-bits_per_coded_sample 16;
-context-frame_size = avpicture_get_size(avctx-pix_fmt,
avctx-width,
- avctx-height);
-}
-
if ((avctx-extradata_size = 9
!memcmp(avctx-extradata + avctx-extradata_size - 9, BottomUp,
9)) ||
avctx-codec_tag == MKTAG('c','y','u','v') ||
@@ -168,11 +155,25 @@ static int raw_decode(AVCodecContext *avctx, void
*data, int *got_frame,
int buf_size = avpkt-size;
int linesize_align = 4;
int res, len;
-int need_copy = !avpkt-buf || context-is_2_4_bpp ||
context-is_yuv2 || context-is_lt_16bpp;
+int need_copy;
AVFrame *frame = data;
AVPicture *picture = data;
+if ((avctx-bits_per_coded_sample == 4 || avctx-bits_per_coded_sample
== 2)
+avctx-pix_fmt == AV_PIX_FMT_PAL8
+ (!avctx-codec_tag || avctx-codec_tag == MKTAG('r','a','w',' ')))
{
+context-is_2_4_bpp = 1;
+context-frame_size = avpicture_get_size(avctx-pix_fmt,
+ FFALIGN(avctx-width,
16),
+ avctx-height);
+} else {
+context-is_lt_16bpp = av_get_bits_per_pixel(desc) == 16
avctx-bits_per_coded_sample avctx-bits_per_coded_sample 16;
+context-frame_size = avpicture_get_size(avctx-pix_fmt,
avctx-width,
+ avctx-height);
+}
+need_copy = !avpkt-buf || context-is_2_4_bpp || context-is_yuv2 ||
context-is_lt_16bpp;
+
frame-pict_type= AV_PICTURE_TYPE_I;
frame-key_frame= 1;
@@ -368,4 +369,5 @@ AVCodec ff_rawvideo_decoder = {
.close = raw_close_decoder,
.decode = raw_decode,
.priv_class = rawdec_class,
+.capabilities = CODEC_CAP_PARAM_CHANGE,
};
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 02/14] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/5]
+/* Rounding to zero used for simplicity */
+static av_always_inline aac_float_t float_add(aac_float_t a, aac_float_t b)
+{
+int diff;
+
+if (a.mant == 0)
+return b;
+
+if (b.mant == 0)
+return a;
+
+diff = a.expo - b.expo;
+
+if (diff 0) // a.expo b.expo
+{
+diff = -diff;
+if (diff = 31)
+a.mant = 0;
+else
+a.mant = diff;
+a.expo = b.expo;
+}
+else // a.expo = b.expo
+{
+if (diff = 31)
+b.mant = 0;
+else
+b.mant = diff;
+}
In addition to the comments I had before, if you care only
about (mostly) matching single-precision IEEE you can
save some cycles by changing to diff 24 instead
of = 31.
Obviously that means you need to change the
code to directly return e.g. a in the else
path instead of insisting on explicitly
adding 0 to a, otherwise it won't get any faster of course.
The idea for this entire emulation was not to make IEEE compliant emulation,
but
to create a tool that is used in aac fixed point decoder on places where
dynamical
range is to large for fixed point operations to be used.
Probably our mistake was in that we didn't put a comment regarding this in the
file,
but it was easily overlooked since this patch is part of the patch set that
implements
fixed point AAC decoder and not stand alone patch for implementing float
emulation.
Also name for this file should probably be changed back to aac_float_emu.h
instead
float_emu.h to emphasize this.
Having this in mind, changing diff = 31 with 24 here is not an option unless
entire
algorithm is changed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). Signed-off-by: Jörg Krause jkra...@posteo.de --- libavutil/error.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/error.c b/libavutil/error.c index bd66354..d326584 100644 --- a/libavutil/error.c +++ b/libavutil/error.c @@ -17,6 +17,7 @@ */ #undef _GNU_SOURCE +#define _XCODE_SOURCE 600 #include avutil.h #include avstring.h #include common.h -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] libavutil/time: fix build with musl toolchain
Add the feature test macro which is required for building with the musl toolchain. The required feature test macro is: nanosleep(): _POSIX_C_SOURCE = 199309L Signed-off-by: Jörg Krause jkra...@posteo.de --- libavutil/time.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/time.c b/libavutil/time.c index ce4552e..52eed4b 100644 --- a/libavutil/time.c +++ b/libavutil/time.c @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ +#define _POSIX_C_SOURCE 199309L + #include config.h #include stddef.h -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] how to merge fixed point wma decoder from rockbox to libav 0.7.6
On Tue, 2 Sep 2014 17:48:57 +0800 Diaz Soho soho123.2...@gmail.com wrote: Hi All, Is there anyone have idea about how to merge fixed point wma decoder to libav 0.7.6? because my cpu does not include fpu, when use the wma decoder in libav , it take a lot of cpu time. Or is anyone have merge fixed point wma decoder to libav? merging the fixed point decoders from rockbox has been on our todo list for a while. https://github.com/Rockbox/rockbox/tree/master/lib/rbcodec/codecs -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). is there a reason why you dont set it from configure ? similar to the existing -D_XOPEN_SOURCE=600 code in configure ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 3/4] libavutil/file: fix build with musl toolchain
Add the feature test macro which is required for building with the musl toolchain. The required feature test macro is: mkstemp(): _POSIX_C_SOURCE = 200112L Signed-off-by: Jörg Krause jkra...@posteo.de --- Changes v1 - v2: - Fixed commit message --- libavutil/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavutil/file.c b/libavutil/file.c index 359d290..cc80050 100644 --- a/libavutil/file.c +++ b/libavutil/file.c @@ -16,6 +16,8 @@ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ +#define _POSIX_C_SOURCE 200112L + #include config.h #include file.h #include internal.h -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFmpeg 2.4
Hi Its almost 2 Months since 2.3 and i assume people want a new release from around the same time of when libav 11 will get released so expect FFmpeg 2.4 to be released soon! if you want something in it, now is the time to push/post it if you want something fixed, now is the time to fix it Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 Rare item - Common item with rare defect or maybe just a lie Professional - 'Toy' made in china, not functional except as doorstop Experts will know - The seller hopes you are not an expert signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/rawdec: Support CODEC_CAP_PARAM_CHANGE
On Tue, Sep 02, 2014 at 08:44:47AM +, Paul B Mahol wrote:
On 9/2/14, Michael Niedermayer michae...@gmx.at wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/rawdec.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 305c13e..28792a1 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -98,19 +98,6 @@ static av_cold int raw_init_decoder(AVCodecContext
*avctx)
memset(context-palette-data, 0, AVPALETTE_SIZE);
}
-if ((avctx-bits_per_coded_sample == 4 || avctx-bits_per_coded_sample
== 2)
-avctx-pix_fmt == AV_PIX_FMT_PAL8
- (!avctx-codec_tag || avctx-codec_tag == MKTAG('r','a','w',' ')))
{
-context-is_2_4_bpp = 1;
-context-frame_size = avpicture_get_size(avctx-pix_fmt,
- FFALIGN(avctx-width,
16),
- avctx-height);
-} else {
-context-is_lt_16bpp = av_get_bits_per_pixel(desc) == 16
avctx-bits_per_coded_sample avctx-bits_per_coded_sample 16;
-context-frame_size = avpicture_get_size(avctx-pix_fmt,
avctx-width,
- avctx-height);
-}
-
if ((avctx-extradata_size = 9
!memcmp(avctx-extradata + avctx-extradata_size - 9, BottomUp,
9)) ||
avctx-codec_tag == MKTAG('c','y','u','v') ||
@@ -168,11 +155,25 @@ static int raw_decode(AVCodecContext *avctx, void
*data, int *got_frame,
int buf_size = avpkt-size;
int linesize_align = 4;
int res, len;
-int need_copy = !avpkt-buf || context-is_2_4_bpp ||
context-is_yuv2 || context-is_lt_16bpp;
+int need_copy;
AVFrame *frame = data;
AVPicture *picture = data;
+if ((avctx-bits_per_coded_sample == 4 || avctx-bits_per_coded_sample
== 2)
+avctx-pix_fmt == AV_PIX_FMT_PAL8
+ (!avctx-codec_tag || avctx-codec_tag == MKTAG('r','a','w',' ')))
{
+context-is_2_4_bpp = 1;
+context-frame_size = avpicture_get_size(avctx-pix_fmt,
+ FFALIGN(avctx-width,
16),
+ avctx-height);
+} else {
+context-is_lt_16bpp = av_get_bits_per_pixel(desc) == 16
avctx-bits_per_coded_sample avctx-bits_per_coded_sample 16;
+context-frame_size = avpicture_get_size(avctx-pix_fmt,
avctx-width,
+ avctx-height);
+}
+need_copy = !avpkt-buf || context-is_2_4_bpp || context-is_yuv2 ||
context-is_lt_16bpp;
+
frame-pict_type= AV_PICTURE_TYPE_I;
frame-key_frame= 1;
@@ -368,4 +369,5 @@ AVCodec ff_rawvideo_decoder = {
.close = raw_close_decoder,
.decode = raw_decode,
.priv_class = rawdec_class,
+.capabilities = CODEC_CAP_PARAM_CHANGE,
};
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
lgtm
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/swfdec: Do not change the pixel format
This is currently not supported
Fixes part of Ticket 3539
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/swfdec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
index ca2a1c4..528bc23 100644
--- a/libavformat/swfdec.c
+++ b/libavformat/swfdec.c
@@ -289,6 +289,7 @@ static int swf_read_packet(AVFormatContext *s, AVPacket
*pkt)
const int bmp_fmt = avio_r8(pb);
const int width = avio_rl16(pb);
const int height = avio_rl16(pb);
+int pix_fmt;
len -= 2+1+2+2;
@@ -367,7 +368,7 @@ static int swf_read_packet(AVFormatContext *s, AVPacket
*pkt)
switch (bmp_fmt) {
case 3:
-st-codec-pix_fmt = AV_PIX_FMT_PAL8;
+pix_fmt = AV_PIX_FMT_PAL8;
for (i = 0; i colormapsize; i++)
if (alpha_bmp) colormap[i] = buf[3]24 | AV_RB24(buf +
4*i);
elsecolormap[i] = 0xffU 24 | AV_RB24(buf +
3*i);
@@ -379,14 +380,20 @@ static int swf_read_packet(AVFormatContext *s, AVPacket
*pkt)
memcpy(pal, colormap, AVPALETTE_SIZE);
break;
case 4:
-st-codec-pix_fmt = AV_PIX_FMT_RGB555;
+pix_fmt = AV_PIX_FMT_RGB555;
break;
case 5:
-st-codec-pix_fmt = alpha_bmp ? AV_PIX_FMT_ARGB :
AV_PIX_FMT_0RGB;
+pix_fmt = alpha_bmp ? AV_PIX_FMT_ARGB : AV_PIX_FMT_0RGB;
break;
default:
av_assert0(0);
}
+if (st-codec-pix_fmt != AV_PIX_FMT_NONE st-codec-pix_fmt !=
pix_fmt) {
+av_log(s, AV_LOG_ERROR, pixel format change unsupported\n);
+res = AVERROR_PATCHWELCOME;
+goto bitmap_end;
+}
+st-codec-pix_fmt = pix_fmt;
if (linesize * height pkt-size) {
res = AVERROR_INVALIDDATA;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote: Am 02.09.2014 12:40 schrieb Michael Niedermayer: On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). is there a reason why you dont set it from configure ? similar to the existing -D_XOPEN_SOURCE=600 code in configure ? [...] I followed the recommendation from the GNU C Library Reference Manual, ch. 1.3.4 Feature Test Macro: You should define these macros by using ‘#define’ preprocessor directives at the top of your source code files. These directives must come before any #include of a system header file. It is best to make them the very first thing in the file, preceded only by comments. You could also use the ‘-D’ option to GCC, but it's better if you make the source files indicate their own meaning in a self-contained way. Do you prefer to define the macro in configure? i prefer that all libcs are handled the same way [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cmdutils: Add some whitespace when printing layouts
Attached patch adds some whitespace when listing channel layouts with
the -layouts option.
== Output before patch ==
Individual channels:
NAMEDESCRIPTION
FL front left
FR front right
FC front center
[...]
Standard channel layouts:
NAMEDECOMPOSITION
monoFC
stereo FL+FR
2.1 FL+FR+LFE
[...]
7.1(wide) FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side)FL+FR+FC+LFE+FLC+FRC+SL+SR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
downmix DL+DR
== Output after patch ==
Individual channels:
NAME DESCRIPTION
FL front left
FR front right
FC front center
[...]
Standard channel layouts:
NAME DECOMPOSITION
mono FC
stereo FL+FR
2.1FL+FR+LFE
[...]
7.1(wide) FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side) FL+FR+FC+LFE+FLC+FRC+SL+SR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
downmixDL+DR
From 4bb45eaf4f0b404348e9f72a1a0bbb30551322d8 Mon Sep 17 00:00:00 2001
From: Tobias Rapp t.r...@noa-audio.com
Date: Tue, 2 Sep 2014 16:20:45 +0200
Subject: [PATCH] cmdutils: Add some whitespace when printing layouts
Adds some more whitespace between channel layout name and decomposition.
---
cmdutils.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cmdutils.c b/cmdutils.c
index a71c7db..1143ea1 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -1639,19 +1639,19 @@ int show_layouts(void *optctx, const char *opt, const
char *arg)
const char *name, *descr;
printf(Individual channels:\n
- NAMEDESCRIPTION\n);
+ NAME DESCRIPTION\n);
for (i = 0; i 63; i++) {
name = av_get_channel_name((uint64_t)1 i);
if (!name)
continue;
descr = av_get_channel_description((uint64_t)1 i);
-printf(%-12s%s\n, name, descr);
+printf(%-14s %s\n, name, descr);
}
printf(\nStandard channel layouts:\n
- NAMEDECOMPOSITION\n);
+ NAME DECOMPOSITION\n);
for (i = 0; !av_get_standard_channel_layout(i, layout, name); i++) {
if (name) {
-printf(%-12s, name);
+printf(%-14s , name);
for (j = 1; j; j = 1)
if ((layout j))
printf(%s%s, (layout (j - 1)) ? + : ,
av_get_channel_name(j));
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, 2 Sep 2014 12:33:26 +0200 Jörg Krause jkra...@posteo.de wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). Signed-off-by: Jörg Krause jkra...@posteo.de --- libavutil/error.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/error.c b/libavutil/error.c index bd66354..d326584 100644 --- a/libavutil/error.c +++ b/libavutil/error.c @@ -17,6 +17,7 @@ */ #undef _GNU_SOURCE +#define _XCODE_SOURCE 600 #include avutil.h #include avstring.h #include common.h This looks good to me, though in the meantime I heard that others compile FFmpeg on musl without issues and without having to patch anything. I'm not sure why it's breaking in your case; maybe random CFLAGS were leaking from pkg-config or other configure checks, which makes this work for others. Also, you probably have to adjust the configure test for HAVE_STRERROR_R? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] how to merge fixed point wma decoder from rockbox to libav 0.7.6
Hi compn, how about : merging the fixed point decoders from rockbox has been on our todo list for a while. https://github.com/Rockbox/rockbox/tree/master/lib/rbcodec/codecs any idea ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 2.4
On Tue, Sep 02, 2014 at 08:05:56AM -0400, Marcus Johnson wrote: Alright, probably a bad place to post this, but I made a few cosmetic changes to the dts decoder, the first replaces the request_channels calls with the request_channel_layout function, and the second removes the code that disabled deprecation warnings around those calls. this breaks ffmpeg -request_channels 2 -i ... also they are structure fields and not function calls -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] SSE2 version of vf_idet's filter_line()
On Tue, Sep 02, 2014 at 05:13:08PM +0200, Pascal Massimino wrote: Hi, Much faster. An example (time ffmpeg -i ... -vf idet -f null /dev/null) Raw C: user 25.007s MMX:user 16.818s MMXEXT: user 16.191s SSE2: user 15.481s no idet filter: user 15.025s YMMV. skal vf_idet.c | 34 + vf_idet.h | 55 +++ x86/Makefile |2 x86/vf_idet.asm| 193 + x86/vf_idet_init.c | 53 ++ 5 files changed, 307 insertions(+), 30 deletions(-) 0caf7533d437c2f14cb0b42fd701f467a2cd idet_sse2.patch commit de5064a0126a0a5bed9d8f151fa79b07614729fe Author: skal pascal.massim...@gmail.com Date: Tue Sep 2 16:55:29 2014 +0200 git am didnt like this, it needs git format-patch or send-email output. also fails to build on x86-32 after applying it with patch -p1 libavfilter/x86/vf_idet.asm:123: error: undefined symbol `r7d' (first use) libavfilter/x86/vf_idet.asm:123: error: (Each undefined symbol is reported only once.) libavfilter/x86/vf_idet.asm:123: error: undefined symbol `ff_idet_filter_line_mmxext.end' (first use) libavfilter/x86/vf_idet.asm:123: error: undefined symbol `r7' (first use) libavfilter/x86/vf_idet.asm:123: warning: `movsxd' is an instruction in 64-bit mode libavfilter/x86/vf_idet.asm:123: error: instruction expected after label libavfilter/x86/vf_idet.asm:123: error: undefined symbol `movsxd.left_over_loop' (first use) libavfilter/x86/vf_idet.asm:127: error: undefined symbol `ff_idet_filter_line_mmx.end' (first use) libavfilter/x86/vf_idet.asm:127: warning: `movsxd' is an instruction in 64-bit mode libavfilter/x86/vf_idet.asm:127: error: instruction expected after label libavfilter/x86/vf_idet.asm:127: error: redefinition of `movsxd.end' libavfilter/x86/vf_idet.asm:123: error: `movsxd.end' previously defined here libavfilter/x86/vf_idet.asm:187: error: undefined symbol `ff_idet_filter_line_sse2.sse2_end' (first use) libavfilter/x86/vf_idet.asm:189: warning: `movsxd' is an instruction in 64-bit mode libavfilter/x86/vf_idet.asm:189: error: instruction expected after label and if you want to maintain this, dont hesitate to add yourself to the MAINTAINERs file thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: Add some whitespace when printing layouts
On Tue, Sep 02, 2014 at 05:04:31PM +0200, Tobias Rapp wrote: Attached patch adds some whitespace when listing channel layouts with the -layouts option. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rangecoder-test: Allow running with small stack size.
On Tue, Sep 02, 2014 at 01:48:09AM +0200, Michael Niedermayer wrote: On Mon, Sep 01, 2014 at 11:26:06PM +0200, Reimar Döffinger wrote: Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de --- libavcodec/rangecoder.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) LGTM Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_deshake: reduce stack usage.
On Tue, Sep 02, 2014 at 01:54:38AM +0200, Michael Niedermayer wrote: On Mon, Sep 01, 2014 at 11:36:52PM +0200, Reimar Döffinger wrote: Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de --- libavfilter/deshake.h| 3 +++ libavfilter/vf_deshake.c | 13 + 2 files changed, 8 insertions(+), 8 deletions(-) LGTM Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_deshake: Avoid doing a malloc+free for every single frame.
On Tue, Sep 02, 2014 at 01:55:20AM +0200, Michael Niedermayer wrote: On Mon, Sep 01, 2014 at 11:49:28PM +0200, Reimar Döffinger wrote: Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de --- libavfilter/deshake.h| 2 ++ libavfilter/vf_deshake.c | 10 ++ 2 files changed, 8 insertions(+), 4 deletions(-) LGTM Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Redirecting MP4 muxed data to socket using movflags resets timestamp
On Tue, Sep 02, 2014 at 04:42:09PM +0530, Parth Shah wrote: My question is why this timestamps gets changed? Is thereant method to send MP4 file over socket without changing its timestamp? Any help or advice? Thank you in advance. This belongs on ffmpeg-user. Plus, I'd suggest reconsidering trying to beat MP4 container format into doing something it wasn't designed for. Though you might be able to force the feature on using the use_editlist flag. But what you are doing is just asking for trouble. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avformat/assdec: UTF-16 support
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The FFTextReader wrapper now also takes care of skipping
the UTF-8 BOM.
---
libavformat/assdec.c| 19 +--
libavformat/subtitles.c | 63 +
libavformat/subtitles.h | 51 +++
3 files changed, 126 insertions(+), 7 deletions(-)
diff --git a/libavformat/assdec.c b/libavformat/assdec.c
index bb953c7..a5f792a 100644
--- a/libavformat/assdec.c
+++ b/libavformat/assdec.c
@@ -33,10 +33,13 @@ typedef struct ASSContext {
static int ass_probe(AVProbeData *p)
{
-const char *header = [Script Info];
+char buf[13];
+FFTextReader tr;
+ff_text_init_buf(tr, p-buf, p-buf_size);
-if (!memcmp(p-buf, header, strlen(header)) ||
-!memcmp(p-buf + 3, header, strlen(header)))
+ff_text_read(tr, buf, sizeof(buf));
+
+if (!memcmp(buf, [Script Info], 13))
return AVPROBE_SCORE_MAX;
return 0;
@@ -66,13 +69,13 @@ static int read_ts(const uint8_t *p, int64_t *start, int
*duration)
return -1;
}
-static int64_t get_line(AVBPrint *buf, AVIOContext *pb)
+static int64_t get_line(AVBPrint *buf, FFTextReader *tr)
{
-int64_t pos = avio_tell(pb);
+int64_t pos = ff_text_pos(tr);
av_bprint_clear(buf);
for (;;) {
-char c = avio_r8(pb);
+char c = ff_text_r8(tr);
if (!c)
break;
av_bprint_chars(buf, c, 1);
@@ -88,6 +91,8 @@ static int ass_read_header(AVFormatContext *s)
AVBPrint header, line;
int header_remaining, res = 0;
AVStream *st;
+FFTextReader tr;
+ff_text_init_avio(tr, s-pb);
st = avformat_new_stream(s, NULL);
if (!st)
@@ -102,7 +107,7 @@ static int ass_read_header(AVFormatContext *s)
av_bprint_init(line, 0, AV_BPRINT_SIZE_UNLIMITED);
for (;;) {
-int64_t pos = get_line(line, s-pb);
+int64_t pos = get_line(line, tr);
if (!line.str[0]) // EOF
break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index fce2bf1..47a52ec 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -20,9 +20,72 @@
#include avformat.h
#include subtitles.h
+#include avio_internal.h
#include libavutil/avassert.h
#include libavutil/avstring.h
+void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
+{
+int i;
+r-pb = pb;
+r-buf_pos = r-buf_len = 0;
+r-type = 0;
+for (i = 0; i 2; i++)
+r-buf[r-buf_len++] = avio_r8(r-pb);
+if (strncmp(\xFF\xFE, r-buf, 2) == 0) {
+r-type = 1; // UTF16LE
+r-buf_pos += 2;
+} else if (strncmp(\xFE\xFF, r-buf, 2) == 0) {
+r-type = 2; // UTF16BE
+r-buf_pos += 2;
+} else {
+r-buf[r-buf_len++] = avio_r8(r-pb);
+if (strncmp(\xEF\xBB\xBF, r-buf, 3) == 0) {
+// UTF8
+r-buf_pos += 3;
+}
+}
+}
+
+void ff_text_init_buf(FFTextReader *r, void *buf, size_t size)
+{
+memset(r-buf_pb, 0, sizeof(r-buf_pb));
+ffio_init_context(r-buf_pb, buf, size, 0, NULL, NULL, NULL, NULL);
+ff_text_init_avio(r, r-buf_pb);
+}
+
+int64_t ff_text_pos(FFTextReader *r)
+{
+return avio_tell(r-pb) - r-buf_len + r-buf_pos;
+}
+
+int ff_text_r8(FFTextReader *r)
+{
+uint32_t val;
+uint8_t tmp;
+if (r-buf_pos r-buf_len)
+return r-buf[r-buf_pos++];
+if (r-type == 1) {
+GET_UTF16(val, avio_rl16(r-pb), return 0;)
+} else if (r-type == 2) {
+GET_UTF16(val, avio_rb16(r-pb), return 0;)
+} else {
+return avio_r8(r-pb);
+}
+if (!val)
+return 0;
+r-buf_pos = 0;
+r-buf_len = 0;
+PUT_UTF8(val, tmp, r-buf[r-buf_len++] = tmp;)
+return r-buf[r-buf_pos++]; // buf_len is at least 1
+}
+
+void ff_text_read(FFTextReader *r, char *buf, size_t size)
+{
+for ( ; size 0; size--)
+*buf++ = ff_text_r8(r);
+}
+
AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
const uint8_t *event, int len, int merge)
{
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index b5a96ec..9549b32 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -31,6 +31,57 @@ enum sub_sort {
};
typedef struct {
+int type;
+AVIOContext *pb;
+unsigned char buf[8];
+int buf_pos, buf_len;
+AVIOContext buf_pb;
+} FFTextReader;
+
+/**
+ * Initialize the FFTextReader from the given AVIOContext. This function will
+ * read some bytes from pb, and test for UTF-8 or UTF-16 BOMs. Further accesses
+ * to FFTextReader will read more data from pb.
+ *
+ * The purpose of FFTextReader is to transparently convert read data to UTF-8
+ * if the stream had a UTF-16 BOM.
+ *
+ * @param r object which will be initialized
+ * @param pb stream to read
[FFmpeg-devel] [PATCH 3/4] avformat/samidec: UTF-16 support
ff_smil_extract_next_chunk() is still used by RealText.
---
libavformat/samidec.c | 17 ++---
libavformat/subtitles.c | 15 ---
libavformat/subtitles.h | 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 1a12eca..4dbf2cf 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -38,11 +38,12 @@ typedef struct {
static int sami_probe(AVProbeData *p)
{
-const unsigned char *ptr = p-buf;
+char buf[6];
+FFTextReader tr;
+ff_text_init_buf(tr, p-buf, p-buf_size);
+ff_text_read(tr, buf, sizeof(buf));
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3; /* skip UTF-8 BOM */
-return !strncmp(ptr, SAMI, 6) ? AVPROBE_SCORE_MAX : 0;
+return !strncmp(buf, SAMI, 6) ? AVPROBE_SCORE_MAX : 0;
}
static int sami_read_header(AVFormatContext *s)
@@ -52,6 +53,8 @@ static int sami_read_header(AVFormatContext *s)
AVBPrint buf, hdr_buf;
char c = 0;
int res = 0, got_first_sync_point = 0;
+FFTextReader tr;
+ff_text_init_avio(tr, s-pb);
if (!st)
return AVERROR(ENOMEM);
@@ -62,10 +65,10 @@ static int sami_read_header(AVFormatContext *s)
av_bprint_init(buf, 0, AV_BPRINT_SIZE_UNLIMITED);
av_bprint_init(hdr_buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-while (!avio_feof(s-pb)) {
+while (!ff_text_eof(tr)) {
AVPacket *sub;
-const int64_t pos = avio_tell(s-pb) - (c != 0);
-int is_sync, n = ff_smil_extract_next_chunk(s-pb, buf, c);
+const int64_t pos = ff_text_pos(tr) - (c != 0);
+int is_sync, n = ff_smil_extract_next_text_chunk(tr, buf, c);
if (n == 0)
break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 1641aae..b8b680e 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -272,20 +272,20 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue *q)
q-nb_subs = q-allocated_size = q-current_sub_idx = 0;
}
-int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char *c)
{
int i = 0;
char end_chr;
if (!*c) // cached char?
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
if (!*c)
return 0;
end_chr = *c == '' ? '' : '';
do {
av_bprint_chars(buf, *c, 1);
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
i++;
} while (*c != end_chr *c);
if (end_chr == '') {
@@ -295,6 +295,15 @@ int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint
*buf, char *c)
return i;
}
+int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+{
+FFTextReader tr;
+tr.buf_pos = tr.buf_len = 0;
+tr.type = 0;
+tr.pb = pb;
+return ff_smil_extract_next_text_chunk(tr, buf, c);
+}
+
const char *ff_smil_get_attr_ptr(const char *s, const char *attr)
{
int in_quotes = 0;
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index d5b4a82..33dd0d0 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -143,6 +143,11 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue *q);
int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c);
/**
+ * As ff_smil_extract_next_chunk(), but with FFTextReader.
+ */
+int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char *c);
+
+/**
* SMIL helper to point on the value of an attribute in the given tag.
*
* @param sSMIL tag (...)
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffv1dec: Avoid unnecessarily large stack usage and copies.
Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply be assigned.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/ffv1dec.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index c408f16..5fbe51c 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -1051,12 +1051,17 @@ static int update_thread_context(AVCodecContext *dst,
const AVCodecContext *src)
return 0;
{
-FFV1Context bak = *fdst;
+ThreadFrame picture = fdst-picture, last_picture = fdst-last_picture;
+uint8_t (*initial_states[MAX_QUANT_TABLES])[32];
+struct FFV1Context *slice_context[MAX_SLICES];
+memcpy(initial_states, fdst-initial_states,
sizeof(fdst-initial_states));
+memcpy(slice_context, fdst-slice_context ,
sizeof(fdst-slice_context));
+
memcpy(fdst, fsrc, sizeof(*fdst));
-memcpy(fdst-initial_states, bak.initial_states,
sizeof(fdst-initial_states));
-memcpy(fdst-slice_context, bak.slice_context ,
sizeof(fdst-slice_context));
-fdst-picture = bak.picture;
-fdst-last_picture = bak.last_picture;
+memcpy(fdst-initial_states, initial_states,
sizeof(fdst-initial_states));
+memcpy(fdst-slice_context, slice_context ,
sizeof(fdst-slice_context));
+fdst-picture = picture;
+fdst-last_picture = last_picture;
for (i = 0; ifdst-num_h_slices * fdst-num_v_slices; i++) {
FFV1Context *fssrc = fsrc-slice_context[i];
FFV1Context *fsdst = fdst-slice_context[i];
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, 2 Sep 2014 20:32:57 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
A bit more complex than e.g. adding it to the context, but
using the context for something that will be used only during
initialization seemed a bit wasteful.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/ffv1enc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index b63ed42..4611f94 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -862,9 +862,11 @@ static av_cold int encode_init(AVCodecContext *avctx)
}
if (avctx-stats_in) {
char *p = avctx-stats_in;
-uint8_t best_state[256][256];
+uint8_t (*best_state)[256] = av_malloc_array(256, 256);
int gob_count = 0;
char *next;
+ if (!best_state)
+return AVERROR(ENOMEM);
av_assert0(s-version = 2);
@@ -875,6 +877,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
if (next == p) {
av_log(avctx, AV_LOG_ERROR,
2Pass file invalid at %d %d [%s]\n, j, i,
p);
+av_freep(best_state);
return AVERROR_INVALIDDATA;
}
p = next;
@@ -888,6 +891,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
av_log(avctx, AV_LOG_ERROR,
2Pass file invalid at %d %d %d %d
[%s]\n,
i, j, k, m, p);
+av_freep(best_state);
return AVERROR_INVALIDDATA;
}
p = next;
@@ -896,6 +900,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
gob_count = strtol(p, next, 0);
if (next == p || gob_count = 0) {
av_log(avctx, AV_LOG_ERROR, 2Pass file invalid\n);
+av_freep(best_state);
return AVERROR_INVALIDDATA;
}
p = next;
@@ -933,6 +938,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
}
}
}
+av_freep(best_state);
}
if (s-version 1) {
Is there any specific purpose to these changes? Sure, 64KB stack is
pushing a bit, but it should be fine on all normal systems.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 07:41:40PM +0200, Reimar Döffinger wrote: On Tue, Sep 02, 2014 at 05:03:56PM +0200, Michael Niedermayer wrote: On Tue, Sep 02, 2014 at 01:52:24PM +0200, Jörg Krause wrote: Am 02.09.2014 12:40 schrieb Michael Niedermayer: On Tue, Sep 02, 2014 at 12:33:26PM +0200, Jörg Krause wrote: Add the feature test macro which is required for building with the musl toolchain. The feature test macro _XOPEN_SOURCE = 600 provides the XSI-compliant version of strerror_r(). is there a reason why you dont set it from configure ? similar to the existing -D_XOPEN_SOURCE=600 code in configure ? [...] I followed the recommendation from the GNU C Library Reference Manual, ch. 1.3.4 Feature Test Macro: You should define these macros by using ‘#define’ preprocessor directives at the top of your source code files. These directives must come before any #include of a system header file. It is best to make them the very first thing in the file, preceded only by comments. You could also use the ‘-D’ option to GCC, but it's better if you make the source files indicate their own meaning in a self-contained way. Do you prefer to define the macro in configure? i prefer that all libcs are handled the same way And to be honest the configure check seems backwards to me, why isn't -D_XOPEN_SOURCE=600 used by default? no idea Do all of klibc, bionic, mingw32, mingw64, cygwin/newlib, msvcrt break if you add it? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/assdec: UTF-16 support
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote: Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents to UTF-8 on the fly using FFTextReader, which acts as converting wrapper around AVIOContext. It also can work on a static buffer, needed for format probing. The FFTextReader wrapper now also takes care of skipping the UTF-8 BOM. Haven't reviewed it in detail, but shouldn't it also detect anything with a 0 byte in the first 2 characters as UTF-16? Interpreting it as any other text format is unlikely to work anyway, and I think most subtitle formats will start with an ASCII character, giving near 100% reliability without any BOM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Request for testing
On Tuesday, September 02, 2014 20:22:24 James Darnley wrote: I am looking for someone with an XOP capable CPU to compile and run two basic fate tests for me. All you have to do is: - get the ffmpeg source from my git repo (link below) - checkout the flac_enc_lpc branch: git checkout flac_enc_lpc - configure with --enable-gpl - build ffmpeg - run: make fate-acodec-flac-comp-5 fate-acodec-flac-24-comp-5 - tell me whether the tests complete without error https://gitorious.org/ffmpeg/jdarnley-ffmpeg/commits/e00f101380ee9c1c92755 c4ff9eda8bc3a01f71c CPUs with XOP instructions would be AMD CPUs from 2011 onwards, specifically the Bulldozer family TESTacodec-flac-comp-5 TESTacodec-flac-24-comp-5 --- ./tests/ref/acodec/flac-24-comp-5 2014-09-02 12:35:11.678786719 -0600 +++ tests/data/fate/acodec-flac-24-comp-5 2014-09-02 12:37:46.439300144 -0600 @@ -1,4 +1,4 @@ -fedf634bba4d07734d19426620f9c31e *tests/data/fate/acodec-flac-24-comp-5.flac -238199 tests/data/fate/acodec-flac-24-comp-5.flac -95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-flac-24- comp-5.out.wav -stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes: 1058400/ 1058400 +5845db245381243c9a0abcec03955f88 *tests/data/fate/acodec-flac-24-comp-5.flac +776441 tests/data/fate/acodec-flac-24-comp-5.flac +e6fcc8c3c1b6daf9bb7d5a29dd568a45 *tests/data/fate/acodec-flac-24- comp-5.out.wav +stddev:18098.97 PSNR: 11.18 MAXDIFF:65492 bytes: 1058400/ 1058400 Test acodec-flac-24-comp-5 failed. Look at tests/data/fate/acodec-flac-24- comp-5.err for details. tests/Makefile:192: recipe for target 'fate-acodec-flac-24-comp-5' failed make: *** [fate-acodec-flac-24-comp-5] Error 1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/assdec: UTF-16 support
On Tue, 2 Sep 2014 21:05:08 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote: Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents to UTF-8 on the fly using FFTextReader, which acts as converting wrapper around AVIOContext. It also can work on a static buffer, needed for format probing. The FFTextReader wrapper now also takes care of skipping the UTF-8 BOM. Haven't reviewed it in detail, but shouldn't it also detect anything with a 0 byte in the first 2 characters as UTF-16? Interpreting it as any other text format is unlikely to work anyway, and I think most subtitle formats will start with an ASCII character, giving near 100% reliability without any BOM. Interesting idea, but on the other hand I haven't seen any UTF-16 subtitles without BOM. (My guess is that they're all produced on Windows...) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, Sep 02, 2014 at 08:58:50PM +0200, wm4 wrote:
On Tue, 2 Sep 2014 20:32:57 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -933,6 +938,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
}
}
}
+av_freep(best_state);
}
if (s-version 1) {
Is there any specific purpose to these changes? Sure, 64KB stack is
pushing a bit, but it should be fine on all normal systems.
First, that is only true if you assume that the calling application
did not already use up all but 64 kB of stack.
As a library, every byte we use on stack is a byte the calling
application must ensure to leave free.
Plus, normal system depends a lot on your definition.
If you wanted to run 1000 threads on a 32 bit system, you certainly
can't use 8MB stacks like we might be used to on our systems.
Windows uses 1 MB stack by default.
Since we are a library, I think it is reasonable to say that we
definitely should not never grab more than 1/4th (and I find that rather
high personally).
That leaves us with 256kB. To keep a safety margin since we simply
don't test all paths, I would suggest testing at least for 128 kB max.
That does give us the freedom to allow 64 kB allocations if you should
find my patches too intrusive, it just feels cutting it a bit close
even on fairly common systems, not to mention that it might prevent
us from running at all on more obscure systems.
So I'd prefer to avoid it. However there is the question of which
code mess/benefit ratio we want to accept.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, 2 Sep 2014 21:18:24 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Tue, Sep 02, 2014 at 08:58:50PM +0200, wm4 wrote:
On Tue, 2 Sep 2014 20:32:57 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
@@ -933,6 +938,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
}
}
}
+av_freep(best_state);
}
if (s-version 1) {
Is there any specific purpose to these changes? Sure, 64KB stack is
pushing a bit, but it should be fine on all normal systems.
First, that is only true if you assume that the calling application
did not already use up all but 64 kB of stack.
As a library, every byte we use on stack is a byte the calling
application must ensure to leave free.
Plus, normal system depends a lot on your definition.
If you wanted to run 1000 threads on a 32 bit system, you certainly
can't use 8MB stacks like we might be used to on our systems.
Windows uses 1 MB stack by default.
Since we are a library, I think it is reasonable to say that we
definitely should not never grab more than 1/4th (and I find that rather
high personally).
That leaves us with 256kB. To keep a safety margin since we simply
don't test all paths, I would suggest testing at least for 128 kB max.
That does give us the freedom to allow 64 kB allocations if you should
find my patches too intrusive, it just feels cutting it a bit close
even on fairly common systems, not to mention that it might prevent
us from running at all on more obscure systems.
So I'd prefer to avoid it. However there is the question of which
code mess/benefit ratio we want to accept.
I don't see anything wrong in the patch (well, maybe you should switch
the code to the goto fail; idiom). I was just wondering whether there
was a specific reason for this. Did it fail on a certain system?
Anyway, I'm not opposed to these patches; just curious.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, Sep 02, 2014 at 09:28:27PM +0200, wm4 wrote: On Tue, 2 Sep 2014 21:18:24 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: So I'd prefer to avoid it. However there is the question of which code mess/benefit ratio we want to accept. I don't see anything wrong in the patch (well, maybe you should switch the code to the goto fail; idiom). I generally prefer that, however the only way I can see that does not result in a total mess is if I first extract this part into a separate function (of you can see a trivial way to use goto here, I'd like to hear it). Probably a good idea anyway, but I didn't feel like getting completely sidetracked with unrelated code clean-up again. I was just wondering whether there was a specific reason for this. Did it fail on a certain system? No, only trying to run make fate with ulimit -s 64. Anyway, I'm not opposed to these patches; just curious. Sorry, if I sound defensive or anything, that would be because I am myself not completely convinced if and how far we should take it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, Sep 02, 2014 at 08:32:57PM +0200, Reimar Döffinger wrote: A bit more complex than e.g. adding it to the context, but using the context for something that will be used only during initialization seemed a bit wasteful. Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, Sep 02, 2014 at 09:28:27PM +0200, wm4 wrote: I don't see anything wrong in the patch (well, maybe you should switch the code to the goto fail; idiom). I was just wondering whether there was a specific reason for this. Did it fail on a certain system? Btw. while I did not test it, and ignoring HP-UX and AIX (16k and 96k stack it seems), OpenBSD 4.6 release notes say: Increased the default thread stack size to 256k for 32-bit hosts and to 512k on 64-bit hosts. Before it was 64k, so it should fail on an OpenBSD system from 2009 :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffv1enc: reduce stack usage.
On Tue, 2 Sep 2014 21:54:36 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Tue, Sep 02, 2014 at 09:28:27PM +0200, wm4 wrote: I don't see anything wrong in the patch (well, maybe you should switch the code to the goto fail; idiom). I was just wondering whether there was a specific reason for this. Did it fail on a certain system? Btw. while I did not test it, and ignoring HP-UX and AIX (16k and 96k stack it seems), OpenBSD 4.6 release notes say: Increased the default thread stack size to 256k for 32-bit hosts and to 512k on 64-bit hosts. Before it was 64k, so it should fail on an OpenBSD system from 2009 :) Seems like a good enough reason. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] 8svx: Return proper error codes
On Tue, Sep 02, 2014 at 09:54:31PM +0200, Gabriel Dume wrote:
ffmpeg | branch: master | Gabriel Dume gabriel.dd...@gmail.com | Mon Sep 1
15:18:57 2014 -0400| [74512f7e369da40e1148c92b58cd8e59f7737b8f] | committer:
Diego Biurrun
8svx: Return proper error codes
Signed-off-by: Diego Biurrun di...@biurrun.de
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=74512f7e369da40e1148c92b58cd8e59f7737b8f
---
libavcodec/8svx.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/8svx.c b/libavcodec/8svx.c
index 11fbf19..b973771 100644
--- a/libavcodec/8svx.c
+++ b/libavcodec/8svx.c
@@ -96,11 +96,11 @@ static int eightsvx_decode_frame(AVCodecContext *avctx,
void *data,
if (avpkt-size hdr_size * avctx-channels) {
av_log(avctx, AV_LOG_ERROR, packet size is too small\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
}
if (esc-data[0]) {
av_log(avctx, AV_LOG_ERROR, unexpected data after first
packet\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
}
if (is_compr) {
@@ -125,7 +125,7 @@ static int eightsvx_decode_frame(AVCodecContext *avctx,
void *data,
}
if (!esc-data[0]) {
av_log(avctx, AV_LOG_ERROR, unexpected empty packet\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
}
/* decode next piece of data from the buffer */
@@ -166,7 +166,7 @@ static av_cold int eightsvx_decode_init(AVCodecContext
*avctx)
if (avctx-channels 1 || avctx-channels 2) {
av_log(avctx, AV_LOG_ERROR, 8SVX does not support more than 2
channels\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
Isn't this a user settable option? EINVAL was appropriate then.
}
switch(avctx-codec-id) {
@@ -179,7 +179,7 @@ static av_cold int eightsvx_decode_init(AVCodecContext
*avctx)
case AV_CODEC_ID_PCM_S8_PLANAR:
break;
default:
- return -1;
+ return AVERROR_INVALIDDATA;
AVERROR_BUG, or EINVAL maybe?
Unless I'm mistaken this is set depending on the selected decoder. It
looks unrelated to the stream data anyway.
[...]
--
Clément B.
pgpjQTmptg957.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/assdec: UTF-16 support
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote:
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The FFTextReader wrapper now also takes care of skipping
the UTF-8 BOM.
---
libavformat/assdec.c| 19 +--
libavformat/subtitles.c | 63
+
libavformat/subtitles.h | 51 +++
3 files changed, 126 insertions(+), 7 deletions(-)
[...]
+void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
+{
+int i;
+r-pb = pb;
+r-buf_pos = r-buf_len = 0;
+r-type = 0;
+for (i = 0; i 2; i++)
+r-buf[r-buf_len++] = avio_r8(r-pb);
+if (strncmp(\xFF\xFE, r-buf, 2) == 0) {
+r-type = 1; // UTF16LE
Would you mind using an enum for type? You won't need these comments
anymore, and the rest of the code will be easier to read.
[...]
Apart from that, patch looks really good to me. I'll review the rest of
the patchset in a moment.
--
Clément B.
pgpMsxPlCkd3f.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix vf_cropdetect returning negative rectangles
The cropdetect filter is prone to reporting negative-sized rectangles, particularly for dark images. This patch adjusts the limits of the filter loops, preventing the left/right and top/bottom offsets from crossing each other, so that such a zero-sized rectangle is reported instead of a negative one. This improves the reliability of using cropdetect to find a maximum bounding rectangle. 0001-Prevent-vf_cropdetect-from-returning-negative-rectan.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix MSVC warnings about possible value truncation.
On Tue, Sep 02, 2014 at 01:13:27PM -0700, Peter Kasting wrote:
On Sat, Aug 30, 2014 at 2:21 AM, wm4 nfx...@googlemail.com wrote:
I'd
expect it rather to hide bugs than to expose them. For example, it
could make a static analyzer with value range analysis stop working,
because the casts will basically throw a wrench into its algorithm.
I can't understand how the sorts of casts that would be introduced here.
I'm suggesting would harm static analysis. If we're assigning a value to a
variable of type T, then T var = x; and T var = (T)x; have the same
effect, and a static analyzer ought to treat them identically.
The problem is that we have nothing that ensures the form
T var = (T)x;
over
T2 var = (T)x;
(where T2 is a wider type than T for example).
Depending on the static analyzer you can make it ignore
T var = x;
but it will start warning again once the type of var or x changes.
+// !!! Is this cast safe?
+sub-end_display_time = (uint32_t)av_rescale_q(avpkt-duration,
+
avctx-pkt_timebase, ms);
Don't really see anything much better to do.
You could clamp it to e.g. INT_MAX, but not convinced it
would get any better by that.
+// !!! Are these casts safe?
+s-base_matrix[0][i]= (uint8_t)vp31_intra_y_dequant[i];
+s-base_matrix[1][i]= (uint8_t)vp31_intra_c_dequant[i];
+s-base_matrix[2][i]= (uint8_t)vp31_inter_dequant[i];
That one is answered by a simple look in the table: None are negative, so yes.
No idea if there is a specific reason they use signed types.
Considering this seems to be the only place they are used, it probably is
a bug in sofar as the declared types of the tables are stupid.
secs %= 86400;
-tm-tm_hour = secs / 3600;
+tm-tm_hour =(int)(secs / 3600);
tm-tm_min = (secs % 3600) / 60;
-tm-tm_sec = secs % 60;
+tm-tm_sec = secs % 60;
The second part breaks the alignment. And the first one the compiler in theory
could figure out on its own...
+// !!! Should |pts_num| and |pts_den| be uint64_t?
void avpriv_set_pts_info(AVStream *s, int pts_wrap_bits,
unsigned int pts_num, unsigned int pts_den);
I can only hope that nobody has/will come up with some insanity where
that would be useful.
+if (ffio_limit(pb, (int)length) != length)
This one actually looks kind of like a bug, the cast might invoke
undefined behaviour.
@@ -1500,7 +1500,7 @@ static void
matroska_add_index_entries(MatroskaDemuxContext *matroska)
{
EbmlList *index_list;
MatroskaIndex *index;
-int index_scale = 1;
+uint64_t index_scale = 1;
That looks like it will be a really expensive change,
division by a 64 bit value isn't fast.
In general, the nicer way to avoid the matroska issues and saving
a bit of memory would be to add a EBML_UINT32 (dummy) type.
-static int matroska_aac_sri(int samplerate)
+static int matroska_aac_sri(double samplerate)
I don't think this is equivalent at all.
Not sure if it is better or worse though, we seem to switch between doing
int and doing float comparisons.
-avpriv_set_pts_info(st, 64, matroska-time_scale * track-time_scale,
+avpriv_set_pts_info(st, 64, (unsigned int)(matroska-time_scale *
track-time_scale),
1000 * 1000 * 1000);/* 64 bit pts in ns */
I see where the other question came from.
That looks a bit annoying, won't work for time_scale values 4s??
Not that I think anyone cares.
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -185,7 +185,7 @@ int ff_read_riff_info(AVFormatContext *s, int64_t size)
while ((cur = avio_tell(pb)) = 0
cur = end - 8 /* = tag + size */) {
uint32_t chunk_code;
-int64_t chunk_size;
+unsigned int chunk_size;
That seems risky to me.
We seem to have the right checks right now, but just one mistake
and we have an integer overflow in a malloc argument and
a huge security hole if we using a 32 bit type here.
if (bitrate = 0 bitrate = INT_MAX)
-ic-bit_rate = bitrate;
+ic-bit_rate = (int)bitrate;
I'd kind of think the compilers should manage at least these trivial cases...
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -61,7 +61,7 @@ typedef struct WAVDemuxContext {
#if CONFIG_WAV_DEMUXER
-static int64_t next_tag(AVIOContext *pb, uint32_t *tag)
+static unsigned int next_tag(AVIOContext *pb, uint32_t *tag)
{
*tag = avio_rl32(pb);
return avio_rl32(pb);
@@ -76,10 +76,10 @@ static int64_t wav_seek_tag(WAVDemuxContext * wav,
AVIOContext *s, int64_t offse
}
/* return the size of the found tag */
-static int64_t find_tag(WAVDemuxContext * wav, AVIOContext *pb, uint32_t tag1)
+static unsigned int find_tag(WAVDemuxContext * wav, AVIOContext *pb, uint32_t
tag1)
{
unsigned int tag;
-int64_t size;
+unsigned int size;
for (;;)
Re: [FFmpeg-devel] [PATCH 1/4] libavutil/error: fix build with musl toolchain
On Tue, Sep 02, 2014 at 11:31:39PM +0200, Jörg Krause wrote: The maintainers of the musl C library states that looking for __GLIBC__ or __UCLIBC__ and making assumptions about the implemented feature set is not the best way. Instead features.h should be inspected for the specification of the feature test macros. Here are links to a discussion on the musl mailing list: I don't know for sure, but I suspect features.h won't help you one bit for the things that configure check was supposed to solve, like the fact that some specific POSIX compliance flag on some platforms will hide a specific feature with no way to get it back again, yet you need the POSIX features enabled by that flag. Unless you propose to test all 100s of combinations of flags until we find one that looks like it works, which I'd object to on the reason that configure is already too slow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Print bits_per_raw_sample for ffprobe -show_streams
Hi! Attached patch fixes ticket #3919 for me. Please comment, Carl Eugen diff --git a/ffprobe.c b/ffprobe.c index 2d48070..34c7f1e 100644 --- a/ffprobe.c +++ b/ffprobe.c @@ -2170,6 +2170,7 @@ static int show_stream(WriterContext *w, AVFormatContext *fmt_ctx, int stream_id else print_str_opt(bit_rate, N/A); if (dec_ctx-rc_max_rate 0) print_val (max_bit_rate, dec_ctx-rc_max_rate, unit_bit_per_second_str); else print_str_opt(max_bit_rate, N/A); +if (dec_ctx-bits_per_raw_sample 0) print_fmt(bits_per_raw_sample, %d, dec_ctx-bits_per_raw_sample); if (stream-nb_frames) print_fmt(nb_frames, %PRId64, stream-nb_frames); else print_str_opt(nb_frames, N/A); if (nb_streams_frames[stream_idx]) print_fmt(nb_read_frames, %PRIu64, nb_streams_frames[stream_idx]); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/srtdec: UTF-16 support
On Tue, Sep 02, 2014 at 08:56:10PM +0200, wm4 wrote:
---
libavformat/srtdec.c| 22 +++--
libavformat/subtitles.c | 51
+++--
libavformat/subtitles.h | 33 +---
3 files changed, 91 insertions(+), 15 deletions(-)
diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
index 53182cd..a258cfe 100644
--- a/libavformat/srtdec.c
+++ b/libavformat/srtdec.c
@@ -31,20 +31,20 @@ typedef struct {
static int srt_probe(AVProbeData *p)
{
-const unsigned char *ptr = p-buf;
int i, v, num = 0;
+FFTextReader tr;
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3; /* skip UTF-8 BOM */
+ff_text_init_buf(tr, p-buf, p-buf_size);
-while (*ptr == '\r' || *ptr == '\n')
-ptr++;
+while (ff_text_peek_r8(tr) == '\r' || ff_text_peek_r8(tr) == '\n')
+ff_text_r8(tr);
for (i=0; i2; i++) {
+char buf[128];
+ff_subtitles_read_line(tr, buf, sizeof(buf));
if ((num == i || num + 1 == i)
- sscanf(ptr, %*d:%*2d:%*2d%*1[,.]%*3d --
%*d:%*2d:%*2d%*1[,.]%3d, v) == 1)
+ sscanf(buf, %*d:%*2d:%*2d%*1[,.]%*3d --
%*d:%*2d:%*2d%*1[,.]%3d, v) == 1)
return AVPROBE_SCORE_MAX;
-num = atoi(ptr);
-ptr += ff_subtitles_next_line(ptr);
+num = atoi(buf);
So ff_subtitles_read_line() actually makes the probe too slow?
What if you try to:
buf[0] = '0' buf[1] = '9' strstr(buf, -- ) sscanf(...)
to gain some little time by sometimes avoiding the sscanf call?
}
return 0;
}
@@ -79,6 +79,8 @@ static int srt_read_header(AVFormatContext *s)
AVBPrint buf;
AVStream *st = avformat_new_stream(s, NULL);
int res = 0;
+FFTextReader tr;
+ff_text_init_avio(tr, s-pb);
if (!st)
return AVERROR(ENOMEM);
@@ -88,8 +90,8 @@ static int srt_read_header(AVFormatContext *s)
av_bprint_init(buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-while (!avio_feof(s-pb)) {
-ff_subtitles_read_chunk(s-pb, buf);
+while (!ff_text_eof(tr)) {
+ff_subtitles_read_text_chunk(tr, buf);
if (buf.len) {
int64_t pos = avio_tell(s-pb);
ff_text_pos()?
[...]
+size_t ff_subtitles_read_line(FFTextReader *tr, char *buf, size_t size)
+{
+size_t cur = 0;
+if (!size)
+return 0;
+while (cur + 1 size) {
+unsigned char c = ff_text_r8(tr);
+if (!c ff_text_eof(tr))
+return cur;
+if (c == '\r' || c == '\n')
+break;
+buf[cur++] = c;
+buf[cur] = '\0';
By reworking the logic, you might be able avoid double writing that end
character and gain some speed for the probing.
+}
+if (ff_text_peek_r8(tr) == '\r')
+ff_text_r8(tr);
+if (ff_text_peek_r8(tr) == '\n')
+ff_text_r8(tr);
+return cur;
+}
LGTM otherwise
--
Clément B.
pgpuWJPANDqd_.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] ffv1dec: Avoid unnecessarily large stack usage and copies.
Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply be assigned.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/ffv1dec.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index c408f16..5fbe51c 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -1051,12 +1051,17 @@ static int update_thread_context(AVCodecContext *dst,
const AVCodecContext *src)
return 0;
{
-FFV1Context bak = *fdst;
+ThreadFrame picture = fdst-picture, last_picture = fdst-last_picture;
+uint8_t (*initial_states[MAX_QUANT_TABLES])[32];
+struct FFV1Context *slice_context[MAX_SLICES];
+memcpy(initial_states, fdst-initial_states,
sizeof(fdst-initial_states));
+memcpy(slice_context, fdst-slice_context ,
sizeof(fdst-slice_context));
+
memcpy(fdst, fsrc, sizeof(*fdst));
-memcpy(fdst-initial_states, bak.initial_states,
sizeof(fdst-initial_states));
-memcpy(fdst-slice_context, bak.slice_context ,
sizeof(fdst-slice_context));
-fdst-picture = bak.picture;
-fdst-last_picture = bak.last_picture;
+memcpy(fdst-initial_states, initial_states,
sizeof(fdst-initial_states));
+memcpy(fdst-slice_context, slice_context ,
sizeof(fdst-slice_context));
+fdst-picture = picture;
+fdst-last_picture = last_picture;
for (i = 0; ifdst-num_h_slices * fdst-num_v_slices; i++) {
FFV1Context *fssrc = fsrc-slice_context[i];
FFV1Context *fsdst = fdst-slice_context[i];
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] huffyuvdec: avoid large stack use.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libavcodec/huffyuvdec.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 1df77e0..d661328 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -115,9 +115,9 @@ static int read_len_table(uint8_t *dst, GetBitContext *gb,
int n)
static int generate_joint_tables(HYuvContext *s)
{
-uint16_t symbols[1 VLC_BITS];
-uint16_t bits[1 VLC_BITS];
-uint8_t len[1 VLC_BITS];
+uint16_t *symbols = av_mallocz(5 VLC_BITS);
+uint16_t *bits = symbols + (1 VLC_BITS);
+uint8_t *len = (uint8_t *)(bits + (1 VLC_BITS));
int ret;
if (s-bitstream_bpp 24 || s-version 2) {
@@ -147,7 +147,7 @@ static int generate_joint_tables(HYuvContext *s)
ff_free_vlc(s-vlc[4 + p]);
if ((ret = ff_init_vlc_sparse(s-vlc[4 + p], VLC_BITS, i, len, 1,
1,
bits, 2, 2, symbols, 2, 2, 0)) 0)
-return ret;
+goto out;
}
} else {
uint8_t (*map)[4] = (uint8_t(*)[4]) s-pix_bgr_map;
@@ -191,9 +191,12 @@ static int generate_joint_tables(HYuvContext *s)
ff_free_vlc(s-vlc[4]);
if ((ret = init_vlc(s-vlc[4], VLC_BITS, i, len, 1, 1,
bits, 2, 2, 0)) 0)
-return ret;
+goto out;
}
-return 0;
+ret = 0;
+out:
+av_freep(symbols);
+return ret;
}
static int read_huffman_tables(HYuvContext *s, const uint8_t *src, int length)
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/samidec: UTF-16 support
On Tue, Sep 02, 2014 at 08:56:11PM +0200, wm4 wrote:
ff_smil_extract_next_chunk() is still used by RealText.
---
libavformat/samidec.c | 17 ++---
libavformat/subtitles.c | 15 ---
libavformat/subtitles.h | 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 1a12eca..4dbf2cf 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -38,11 +38,12 @@ typedef struct {
static int sami_probe(AVProbeData *p)
{
-const unsigned char *ptr = p-buf;
+char buf[6];
+FFTextReader tr;
+ff_text_init_buf(tr, p-buf, p-buf_size);
+ff_text_read(tr, buf, sizeof(buf));
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3; /* skip UTF-8 BOM */
-return !strncmp(ptr, SAMI, 6) ? AVPROBE_SCORE_MAX : 0;
+return !strncmp(buf, SAMI, 6) ? AVPROBE_SCORE_MAX : 0;
}
static int sami_read_header(AVFormatContext *s)
@@ -52,6 +53,8 @@ static int sami_read_header(AVFormatContext *s)
AVBPrint buf, hdr_buf;
char c = 0;
int res = 0, got_first_sync_point = 0;
+FFTextReader tr;
+ff_text_init_avio(tr, s-pb);
if (!st)
return AVERROR(ENOMEM);
@@ -62,10 +65,10 @@ static int sami_read_header(AVFormatContext *s)
av_bprint_init(buf, 0, AV_BPRINT_SIZE_UNLIMITED);
av_bprint_init(hdr_buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-while (!avio_feof(s-pb)) {
+while (!ff_text_eof(tr)) {
AVPacket *sub;
-const int64_t pos = avio_tell(s-pb) - (c != 0);
-int is_sync, n = ff_smil_extract_next_chunk(s-pb, buf, c);
+const int64_t pos = ff_text_pos(tr) - (c != 0);
+int is_sync, n = ff_smil_extract_next_text_chunk(tr, buf, c);
if (n == 0)
break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 1641aae..b8b680e 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -272,20 +272,20 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue *q)
q-nb_subs = q-allocated_size = q-current_sub_idx = 0;
}
-int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char *c)
{
int i = 0;
char end_chr;
if (!*c) // cached char?
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
if (!*c)
return 0;
end_chr = *c == '' ? '' : '';
do {
av_bprint_chars(buf, *c, 1);
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
i++;
} while (*c != end_chr *c);
if (end_chr == '') {
@@ -295,6 +295,15 @@ int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint
*buf, char *c)
return i;
}
+int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+{
+FFTextReader tr;
+tr.buf_pos = tr.buf_len = 0;
+tr.type = 0;
+tr.pb = pb;
+return ff_smil_extract_next_text_chunk(tr, buf, c);
How can this work with utf-16? Aren't you supposed to use the type
obtained after the ff_text_init_avio() in sami_read_header() or something
along those lines?
[...]
--
Clément B.
pgpdHhl2ZieWl.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix MSVC warnings about possible value truncation.
On Fri, 29 Aug 2014 15:44:34 -0700
Peter Kasting pkast...@google.com wrote:
From 1c94e78d2b2037d492ea5abb3edb7960c8e98a1d Mon Sep 17 00:00:00 2001
From: Peter Kasting pkast...@google.com
Date: Fri, 29 Aug 2014 15:31:41 -0700
Subject: [PATCH] Fix MSVC warnings about possible value truncation.
Tried to review it. Here's why patches like these are bad: they're
HUGE. Reviewing them takes a lot of time, and the result is
questionable. How are we going to do v2 of this patch? And v3 etc.?
Probably not at all. It's just too monolithic. It's like reviewing a
phone book.
Another problem: this mixes hiding compiler warnings and trying to fix
real problems. And in many cases, hiding real problems. Just plastering
everything with (type)expr won't help much, especially not if type
is signed, because it doesn't change anything about the legality of an
overflow.
For the next time, I'd suggest putting every real fix (or attempt of a
fix) into a separate patch - even if it results in dozens of patches.
At least this makes it easier to see what patch got rejected, what got
accepted, and what needs further work.
In general, this reinforces my belief that enabling compiler warnings
with large potential for false positives, and then hiding the warnings
by making the compiler happy (without really fixing the issue), is a
very bad idea.
---
compat/strtod.c| 2 +-
libavcodec/avpacket.c | 4 +-
libavcodec/bitstream.c | 14 +++
libavcodec/fft-internal.h | 6 +--
libavcodec/opus.c | 2 +-
libavcodec/rdft.c | 6 +--
libavcodec/utils.c | 21 +-
libavcodec/vorbisdec.c | 19 -
libavcodec/vp3.c | 7 ++--
libavformat/aviobuf.c | 4 +-
libavformat/cutils.c | 6 +--
libavformat/internal.h | 1 +
libavformat/isom.c | 2 +-
libavformat/matroskadec.c | 87
+-
libavformat/mux.c | 10 ++---
libavformat/oggparseogm.c | 6 +--
libavformat/oggparseopus.c | 8 ++--
libavformat/oggparsespeex.c| 4 +-
libavformat/oggparsevorbis.c | 6 ++-
libavformat/pcm.c | 2 +-
libavformat/riffdec.c | 2 +-
libavformat/utils.c| 28 +++---
libavformat/wavdec.c | 16
libavutil/avstring.c | 2 +-
libavutil/bswap.h | 2 +-
libavutil/eval.c | 16
libavutil/intfloat_readwrite.c | 13 ---
libavutil/opt.c| 38 +-
libavutil/parseutils.c | 6 +--
libavutil/rational.c | 10 ++---
libavutil/utils.c | 2 +-
31 files changed, 180 insertions(+), 172 deletions(-)
diff --git a/compat/strtod.c b/compat/strtod.c
index 3a9452e..51d30bf 100644
--- a/compat/strtod.c
+++ b/compat/strtod.c
@@ -81,7 +81,7 @@ double avpriv_strtod(const char *nptr, char **endptr)
!av_strncasecmp(nptr, +0x, 3)) {
/* FIXME this doesn't handle exponents, non-integers (float/double)
* and numbers too large for long long */
-res = strtoll(nptr, end, 16);
+res = (double)strtoll(nptr, end, 16);
Pointless cast.
} else {
res = strtod(nptr, end);
}
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index a87e8e3..739231c 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -351,7 +351,7 @@ int av_packet_merge_side_data(AVPacket *pkt){
}
if (size INT_MAX)
return AVERROR(EINVAL);
-buf = av_buffer_alloc(size);
+buf = av_buffer_alloc((int)size);
False positive; size is explicitly checked above.
if (!buf)
return AVERROR(ENOMEM);
pkt-buf = buf;
@@ -361,7 +361,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
pkt-destruct = dummy_destruct_packet;
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-pkt-size = size - FF_INPUT_BUFFER_PADDING_SIZE;
+pkt-size = (int)size - FF_INPUT_BUFFER_PADDING_SIZE;
Same as above.
bytestream_put_buffer(p, old.data, old.size);
for (i=old.side_data_elems-1; i=0; i--) {
bytestream_put_buffer(p, old.side_data[i].data,
old.side_data[i].size);
diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c
index d041643..1665c68 100644
--- a/libavcodec/bitstream.c
+++ b/libavcodec/bitstream.c
@@ -85,18 +85,18 @@ void avpriv_copy_bits(PutBitContext *pb, const uint8_t
*src, int length)
/* VLC decoding */
-#define GET_DATA(v, table, i, wrap, size) \
+#define GET_DATA(type, v, table, i, wrap, size) \
{ \
const uint8_t *ptr = (const uint8_t *)table + i * wrap; \
switch(size) { \
case 1: \
-
[FFmpeg-devel] [PATCH] web/download: Update Linux Static Build links
* Remove Burek's builds These have been halted since 16 July. Burek has been notified several times, but I have recieved no response. Link will be re-added if activity resumes. * Add reference to 32-bit builds to relaxed's link Thanks to relaxed for quickly volunteering to provide 32-bit builds, and thanks to Burek for all of his previous work. Signed-off-by: Lou Logan l...@lrcd.com --- src/download | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/download b/src/download index c0a2023..03fa183 100644 --- a/src/download +++ b/src/download @@ -70,10 +70,8 @@ h3Linux Static Builds/h3 div class=list-group - a class=list-group-item href=http://ffmpeg.gusari.org/static/;32-bit and -64-bit with kernel 3.2.x and above/a - a class=list-group-item href=http://johnvansickle.com/ffmpeg/;64-bit -with kernel 2.6.32 and above/a + a class=list-group-item href=http://johnvansickle.com/ffmpeg/;32-bit and +64-bit for kernel 2.6.32 and above/a /div !-- list-group -- /div !-- build -- -- 2.0.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/assdec: UTF-16 support
On Tue, 2 Sep 2014 23:18:02 +0200
Clément Bœsch u...@pkh.me wrote:
On Tue, Sep 02, 2014 at 08:56:09PM +0200, wm4 wrote:
Use the UTF-16 BOM to detect UTF-16 encoding. Convert the file contents
to UTF-8 on the fly using FFTextReader, which acts as converting wrapper
around AVIOContext. It also can work on a static buffer, needed for
format probing. The FFTextReader wrapper now also takes care of skipping
the UTF-8 BOM.
---
libavformat/assdec.c| 19 +--
libavformat/subtitles.c | 63
+
libavformat/subtitles.h | 51 +++
3 files changed, 126 insertions(+), 7 deletions(-)
[...]
+void ff_text_init_avio(FFTextReader *r, AVIOContext *pb)
+{
+int i;
+r-pb = pb;
+r-buf_pos = r-buf_len = 0;
+r-type = 0;
+for (i = 0; i 2; i++)
+r-buf[r-buf_len++] = avio_r8(r-pb);
+if (strncmp(\xFF\xFE, r-buf, 2) == 0) {
+r-type = 1; // UTF16LE
Would you mind using an enum for type? You won't need these comments
anymore, and the rest of the code will be easier to read.
Sure. I didn't do it because all magic numbers are used in one place,
but ok.
[...]
Apart from that, patch looks really good to me. I'll review the rest of
the patchset in a moment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] ffv1dec: Avoid unnecessarily large stack usage and copies.
On Wed, Sep 03, 2014 at 12:01:52AM +0200, Reimar Döffinger wrote: Ideally the compiler could figure this out on its own, but it seems it can't. An alternative that would avoid the messy explicit memcpy would be to use a sub-struct for the parts that should be preserved, which can then simply be assigned. Note this one is an exact duplicate of the one I sent earlier (following ones are new). Sorry, I didn't remember anymore what I had and hadn't sent.. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/srtdec: UTF-16 support
On Tue, 2 Sep 2014 23:54:51 +0200
Clément Bœsch u...@pkh.me wrote:
On Tue, Sep 02, 2014 at 08:56:10PM +0200, wm4 wrote:
---
libavformat/srtdec.c| 22 +++--
libavformat/subtitles.c | 51
+++--
libavformat/subtitles.h | 33 +---
3 files changed, 91 insertions(+), 15 deletions(-)
diff --git a/libavformat/srtdec.c b/libavformat/srtdec.c
index 53182cd..a258cfe 100644
--- a/libavformat/srtdec.c
+++ b/libavformat/srtdec.c
@@ -31,20 +31,20 @@ typedef struct {
static int srt_probe(AVProbeData *p)
{
-const unsigned char *ptr = p-buf;
int i, v, num = 0;
+FFTextReader tr;
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3; /* skip UTF-8 BOM */
+ff_text_init_buf(tr, p-buf, p-buf_size);
-while (*ptr == '\r' || *ptr == '\n')
-ptr++;
+while (ff_text_peek_r8(tr) == '\r' || ff_text_peek_r8(tr) == '\n')
+ff_text_r8(tr);
for (i=0; i2; i++) {
+char buf[128];
+ff_subtitles_read_line(tr, buf, sizeof(buf));
if ((num == i || num + 1 == i)
- sscanf(ptr, %*d:%*2d:%*2d%*1[,.]%*3d --
%*d:%*2d:%*2d%*1[,.]%3d, v) == 1)
+ sscanf(buf, %*d:%*2d:%*2d%*1[,.]%*3d --
%*d:%*2d:%*2d%*1[,.]%3d, v) == 1)
return AVPROBE_SCORE_MAX;
-num = atoi(ptr);
-ptr += ff_subtitles_next_line(ptr);
+num = atoi(buf);
So ff_subtitles_read_line() actually makes the probe too slow?
What if you try to:
buf[0] = '0' buf[1] = '9' strstr(buf, -- ) sscanf(...)
to gain some little time by sometimes avoiding the sscanf call?
Doesn't help.
The profiler actually shows ff_text_init_avio and avio_r8 on the top;
maybe removing them from probing will help... will try later.
}
return 0;
}
@@ -79,6 +79,8 @@ static int srt_read_header(AVFormatContext *s)
AVBPrint buf;
AVStream *st = avformat_new_stream(s, NULL);
int res = 0;
+FFTextReader tr;
+ff_text_init_avio(tr, s-pb);
if (!st)
return AVERROR(ENOMEM);
@@ -88,8 +90,8 @@ static int srt_read_header(AVFormatContext *s)
av_bprint_init(buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-while (!avio_feof(s-pb)) {
-ff_subtitles_read_chunk(s-pb, buf);
+while (!ff_text_eof(tr)) {
+ff_subtitles_read_text_chunk(tr, buf);
if (buf.len) {
int64_t pos = avio_tell(s-pb);
ff_text_pos()?
Oops, thanks.
[...]
+size_t ff_subtitles_read_line(FFTextReader *tr, char *buf, size_t size)
+{
+size_t cur = 0;
+if (!size)
+return 0;
+while (cur + 1 size) {
+unsigned char c = ff_text_r8(tr);
+if (!c ff_text_eof(tr))
+return cur;
+if (c == '\r' || c == '\n')
+break;
+buf[cur++] = c;
+buf[cur] = '\0';
By reworking the logic, you might be able avoid double writing that end
character and gain some speed for the probing.
Somehow I doubt the extra write is a hot-spot. The other things in this
function look much more costly to me. If I read the profiler output
right, the if (!c ff_text_eof(tr)) line seems to be a bad idea.
I really wish I wouldn't have to debug probe functions for performance,
though.
+}
+if (ff_text_peek_r8(tr) == '\r')
+ff_text_r8(tr);
+if (ff_text_peek_r8(tr) == '\n')
+ff_text_r8(tr);
+return cur;
+}
LGTM otherwise
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/samidec: UTF-16 support
On Wed, 3 Sep 2014 00:03:04 +0200
Clément Bœsch u...@pkh.me wrote:
On Tue, Sep 02, 2014 at 08:56:11PM +0200, wm4 wrote:
ff_smil_extract_next_chunk() is still used by RealText.
---
libavformat/samidec.c | 17 ++---
libavformat/subtitles.c | 15 ---
libavformat/subtitles.h | 5 +
3 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 1a12eca..4dbf2cf 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -38,11 +38,12 @@ typedef struct {
static int sami_probe(AVProbeData *p)
{
-const unsigned char *ptr = p-buf;
+char buf[6];
+FFTextReader tr;
+ff_text_init_buf(tr, p-buf, p-buf_size);
+ff_text_read(tr, buf, sizeof(buf));
-if (AV_RB24(ptr) == 0xEFBBBF)
-ptr += 3; /* skip UTF-8 BOM */
-return !strncmp(ptr, SAMI, 6) ? AVPROBE_SCORE_MAX : 0;
+return !strncmp(buf, SAMI, 6) ? AVPROBE_SCORE_MAX : 0;
}
static int sami_read_header(AVFormatContext *s)
@@ -52,6 +53,8 @@ static int sami_read_header(AVFormatContext *s)
AVBPrint buf, hdr_buf;
char c = 0;
int res = 0, got_first_sync_point = 0;
+FFTextReader tr;
+ff_text_init_avio(tr, s-pb);
if (!st)
return AVERROR(ENOMEM);
@@ -62,10 +65,10 @@ static int sami_read_header(AVFormatContext *s)
av_bprint_init(buf, 0, AV_BPRINT_SIZE_UNLIMITED);
av_bprint_init(hdr_buf, 0, AV_BPRINT_SIZE_UNLIMITED);
-while (!avio_feof(s-pb)) {
+while (!ff_text_eof(tr)) {
AVPacket *sub;
-const int64_t pos = avio_tell(s-pb) - (c != 0);
-int is_sync, n = ff_smil_extract_next_chunk(s-pb, buf, c);
+const int64_t pos = ff_text_pos(tr) - (c != 0);
+int is_sync, n = ff_smil_extract_next_text_chunk(tr, buf, c);
if (n == 0)
break;
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 1641aae..b8b680e 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -272,20 +272,20 @@ void ff_subtitles_queue_clean(FFDemuxSubtitlesQueue
*q)
q-nb_subs = q-allocated_size = q-current_sub_idx = 0;
}
-int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+int ff_smil_extract_next_text_chunk(FFTextReader *tr, AVBPrint *buf, char
*c)
{
int i = 0;
char end_chr;
if (!*c) // cached char?
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
if (!*c)
return 0;
end_chr = *c == '' ? '' : '';
do {
av_bprint_chars(buf, *c, 1);
-*c = avio_r8(pb);
+*c = ff_text_r8(tr);
i++;
} while (*c != end_chr *c);
if (end_chr == '') {
@@ -295,6 +295,15 @@ int ff_smil_extract_next_chunk(AVIOContext *pb,
AVBPrint *buf, char *c)
return i;
}
+int ff_smil_extract_next_chunk(AVIOContext *pb, AVBPrint *buf, char *c)
+{
+FFTextReader tr;
+tr.buf_pos = tr.buf_len = 0;
+tr.type = 0;
+tr.pb = pb;
+return ff_smil_extract_next_text_chunk(tr, buf, c);
How can this work with utf-16? Aren't you supposed to use the type
obtained after the ff_text_init_avio() in sami_read_header() or something
along those lines?
This is just for compatibility with RealText, and is actually removed
with the next patch (only reason why I did RealText). Sami in this
patch uses the new function.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix MSVC warnings about possible value truncation.
On Tue, 2 Sep 2014 23:43:33 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: On Tue, Sep 02, 2014 at 01:13:27PM -0700, Peter Kasting wrote: On Sat, Aug 30, 2014 at 2:21 AM, wm4 nfx...@googlemail.com wrote: I'd expect it rather to hide bugs than to expose them. For example, it could make a static analyzer with value range analysis stop working, because the casts will basically throw a wrench into its algorithm. I can't understand how the sorts of casts that would be introduced here. I'm suggesting would harm static analysis. If we're assigning a value to a variable of type T, then T var = x; and T var = (T)x; have the same effect, and a static analyzer ought to treat them identically. The problem is that we have nothing that ensures the form T var = (T)x; over T2 var = (T)x; (where T2 is a wider type than T for example). Depending on the static analyzer you can make it ignore T var = x; but it will start warning again once the type of var or x changes. +// !!! Is this cast safe? +sub-end_display_time = (uint32_t)av_rescale_q(avpkt-duration, + avctx-pkt_timebase, ms); Don't really see anything much better to do. You could clamp it to e.g. INT_MAX, but not convinced it would get any better by that. Well, if you have an excessive duration, that would help to get the correct behavior. It's really easy to write a very large timestamp into a subtitle file. +// !!! Are these casts safe? +s-base_matrix[0][i]= (uint8_t)vp31_intra_y_dequant[i]; +s-base_matrix[1][i]= (uint8_t)vp31_intra_c_dequant[i]; +s-base_matrix[2][i]= (uint8_t)vp31_inter_dequant[i]; That one is answered by a simple look in the table: None are negative, so yes. No idea if there is a specific reason they use signed types. Considering this seems to be the only place they are used, it probably is a bug in sofar as the declared types of the tables are stupid. secs %= 86400; -tm-tm_hour = secs / 3600; +tm-tm_hour =(int)(secs / 3600); tm-tm_min = (secs % 3600) / 60; -tm-tm_sec = secs % 60; +tm-tm_sec = secs % 60; The second part breaks the alignment. And the first one the compiler in theory could figure out on its own... +// !!! Should |pts_num| and |pts_den| be uint64_t? void avpriv_set_pts_info(AVStream *s, int pts_wrap_bits, unsigned int pts_num, unsigned int pts_den); I can only hope that nobody has/will come up with some insanity where that would be useful. Actually, going through the patch, it might help with some overflow checks in demuxers. We could just clamp the input to sane values (so invalid files don't break all applications, without needing too many checks and all that). [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] SSE2 version of vf_idet's filter_line()
Michael, On Tue, Sep 2, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 05:13:08PM +0200, Pascal Massimino wrote: Hi, Much faster. An example (time ffmpeg -i ... -vf idet -f null /dev/null) Raw C: user 25.007s MMX:user 16.818s MMXEXT: user 16.191s SSE2: user 15.481s no idet filter: user 15.025s YMMV. skal vf_idet.c | 34 + vf_idet.h | 55 +++ x86/Makefile |2 x86/vf_idet.asm| 193 + x86/vf_idet_init.c | 53 ++ 5 files changed, 307 insertions(+), 30 deletions(-) 0caf7533d437c2f14cb0b42fd701f467a2cd idet_sse2.patch commit de5064a0126a0a5bed9d8f151fa79b07614729fe Author: skal pascal.massim...@gmail.com Date: Tue Sep 2 16:55:29 2014 +0200 git am didnt like this, it needs git format-patch or send-email output. also fails to build on x86-32 after applying it with patch -p1 silly question: how do you compile for x86-32? I tried './configure --arch=x86_32' but it didn't trigger this compile error... thx! skal [ahem: ffmpeg doesn't feel like using intrinsics, by chance?] libavfilter/x86/vf_idet.asm:123: error: undefined symbol `r7d' (first use) libavfilter/x86/vf_idet.asm:123: error: (Each undefined symbol is reported only once.) libavfilter/x86/vf_idet.asm:123: error: undefined symbol `ff_idet_filter_line_mmxext.end' (first use) libavfilter/x86/vf_idet.asm:123: error: undefined symbol `r7' (first use) libavfilter/x86/vf_idet.asm:123: warning: `movsxd' is an instruction in 64-bit mode libavfilter/x86/vf_idet.asm:123: error: instruction expected after label libavfilter/x86/vf_idet.asm:123: error: undefined symbol `movsxd.left_over_loop' (first use) libavfilter/x86/vf_idet.asm:127: error: undefined symbol `ff_idet_filter_line_mmx.end' (first use) libavfilter/x86/vf_idet.asm:127: warning: `movsxd' is an instruction in 64-bit mode libavfilter/x86/vf_idet.asm:127: error: instruction expected after label libavfilter/x86/vf_idet.asm:127: error: redefinition of `movsxd.end' libavfilter/x86/vf_idet.asm:123: error: `movsxd.end' previously defined here libavfilter/x86/vf_idet.asm:187: error: undefined symbol `ff_idet_filter_line_sse2.sse2_end' (first use) libavfilter/x86/vf_idet.asm:189: warning: `movsxd' is an instruction in 64-bit mode libavfilter/x86/vf_idet.asm:189: error: instruction expected after label and if you want to maintain this, dont hesitate to add yourself to the MAINTAINERs file thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle ___ 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] Request for testing
On 2014-09-02 21:25, James Darnley wrote: On 2014-09-02 20:39, Kelly Anderson wrote: TESTacodec-flac-comp-5 TESTacodec-flac-24-comp-5 tests/Makefile:192: recipe for target 'fate-acodec-flac-24-comp-5' failed make: *** [fate-acodec-flac-24-comp-5] Error 1 Thanks. Good to know that the 16-bit version works. I am probably misusing one of the fancier instructions. I've pushed a commit which, I hope, will correct this. The hash is 390c0dc If someone could test (again) the newest code I would I appreciate it. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] doc/demuxers: document gif demuxer
On Aug 31, 2014 3:16 PM, Lou Logan l...@lrcd.com wrote:
+@item ignore_loop
+GIF files can be set to loop infinitely or up to a certain number of
+times.
can contain information to loop...
Can be set sounds like settable from a ffmpeg command.
+
+If @option{ignore_loop} is set to 1, then the loop setting from the
+input will be ignored and looping will not occur.
+
+If set to 0, then looping will occur and will cycle the number of times
+the GIF dictates.
Merge the above 3 paragraphs if you think it is appropriate.
+
+This option prevents a GIF stream from looping forever.
Not necessary. Covered in the second paragraph above.
+
+Default value is 1.
5 paragraphs for this trivial option? Ouch.
+@end table
+
+For example, with the overlay filter, place an infinitely looping GIF
+over another video:
+@example
+ffmpeg -i input.mp4 -ignore_loop 0 -i input.gif
-filter_complex overlay=shortest=1 out.mkv
What if input.gif contains information saying that it should only be looped
once? Doesn't this command break then?
Rest LGTM.
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch: 42507534977e2108e397a381357ee2db209475f6
Patch not sent to ML so couldn't review: Why have you only changed the code to favour DESC_types and not other types? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] patch for x32 for libpostproc
Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. As requested, the patch I used is attached. It’s not optimal as the arch could use the wider registers, but probably good enough, should it do what it’s supposed to ;-) bye, //mirabilos ① https://wiki.debian.org/X32Port -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”# DP: Port to x32 # DP: There is no GCC documentation about the asm præficēs except # DP: in http://stackoverflow.com/a/17825185/2171120 – go figure… --- a/configure +++ b/configure @@ -811,6 +811,7 @@ ARCH_LIST=' sparc sparc64 tomi +x32 x86 x86_32 x86_64 @@ -2190,7 +2191,9 @@ case $arch in check_cc EOF subarch=x86_64 int test[(int)sizeof(char*) - 7]; EOF -if test $subarch = x86_64; then +test $subarch = x86_32 check_cpp_condition sys/types.h \ +'defined(__x86_64__) defined(__ILP32__)' subarch=x32 +if test $subarch = x86_64 || test $subarch = x32; then spic=$shared fi ;; --- a/libpostproc/postprocess_template.c +++ b/libpostproc/postprocess_template.c @@ -29,7 +29,7 @@ #define MANGLE(a) EXTERN_PREFIX LOCAL_MANGLE(a) -#if ARCH_X86_64 defined(PIC) +#if (ARCH_X32 || ARCH_X86_64) defined(PIC) #define LOCAL_MANGLE(a) #a (%%rip) #else #define LOCAL_MANGLE(a) #a @@ -1142,10 +1142,10 @@ FIND_MIN_MAX((%0, %1, 8)) #endif movq %%mm6, %%mm0 \n\t // max psubb %%mm7, %%mm6 \n\t // max - min -push %4 \n\t +pushq %q4 \n\t movd %%mm6, %k4\n\t cmpb MANGLE(deringThreshold), %b4\n\t -pop %4 \n\t +popq %q4 \n\t jb 1f \n\t PAVGB(%%mm0, %%mm7) // a=(max + min)/2 punpcklbw %%mm7, %%mm7 \n\t --- a/libpostproc/x86/asm.h +++ b/libpostproc/x86/asm.h @@ -64,14 +64,34 @@ typedef int32_t x86_reg; #define REGcecx #define REGdedx #define REGSP esp +#elif ARCH_X32 + +#define OPSIZE l +#define REG_a eax +#define REG_b ebx +#define REG_c ecx +#define REG_d edx +#define REG_D edi +#define REG_S esi +#define PTR_SIZE 4 +typedef int32_t x86_reg; + +/* do not define REG_SP so code using it fails */ +#define REG_BP ebp +#define REGBP ebp +#define REGaeax +#define REGbebx +#define REGcecx +#define REGdedx +/* do not define REGSP so code using it fails */ #else typedef int x86_reg; #endif -#define HAVE_7REGS (ARCH_X86_64 || (HAVE_EBX_AVAILABLE HAVE_EBP_AVAILABLE)) -#define HAVE_6REGS (ARCH_X86_64 || (HAVE_EBX_AVAILABLE || HAVE_EBP_AVAILABLE)) +#define HAVE_7REGS (ARCH_X32 || ARCH_X86_64 || (HAVE_EBX_AVAILABLE HAVE_EBP_AVAILABLE)) +#define HAVE_6REGS (ARCH_X32 || ARCH_X86_64 || (HAVE_EBX_AVAILABLE || HAVE_EBP_AVAILABLE)) -#if ARCH_X86_64 defined(PIC) +#if (ARCH_X32 || ARCH_X86_64) defined(PIC) #define BROKEN_RELOCATIONS 1 #endif @@ -99,7 +119,7 @@ typedef int x86_reg; #define LABEL_MANGLE(a) EXTERN_PREFIX #a // Use rip-relative addressing if compiling PIC code on x86-64. -#if ARCH_X86_64 defined(PIC) +#if (ARCH_X32 || ARCH_X86_64) defined(PIC) #define LOCAL_MANGLE(a) #a (%%rip) #else #define LOCAL_MANGLE(a) #a ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] 8svx: Return proper error codes
On Tue, Sep 02, 2014 at 10:03:39PM +0200, Clément Bœsch wrote:
On Tue, Sep 02, 2014 at 09:54:31PM +0200, Gabriel Dume wrote:
ffmpeg | branch: master | Gabriel Dume gabriel.dd...@gmail.com | Mon Sep
1 15:18:57 2014 -0400| [74512f7e369da40e1148c92b58cd8e59f7737b8f] |
committer: Diego Biurrun
8svx: Return proper error codes
Signed-off-by: Diego Biurrun di...@biurrun.de
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=74512f7e369da40e1148c92b58cd8e59f7737b8f
---
libavcodec/8svx.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/8svx.c b/libavcodec/8svx.c
index 11fbf19..b973771 100644
--- a/libavcodec/8svx.c
+++ b/libavcodec/8svx.c
@@ -96,11 +96,11 @@ static int eightsvx_decode_frame(AVCodecContext *avctx,
void *data,
if (avpkt-size hdr_size * avctx-channels) {
av_log(avctx, AV_LOG_ERROR, packet size is too small\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
}
if (esc-data[0]) {
av_log(avctx, AV_LOG_ERROR, unexpected data after first
packet\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
}
if (is_compr) {
@@ -125,7 +125,7 @@ static int eightsvx_decode_frame(AVCodecContext *avctx,
void *data,
}
if (!esc-data[0]) {
av_log(avctx, AV_LOG_ERROR, unexpected empty packet\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
}
/* decode next piece of data from the buffer */
@@ -166,7 +166,7 @@ static av_cold int eightsvx_decode_init(AVCodecContext
*avctx)
if (avctx-channels 1 || avctx-channels 2) {
av_log(avctx, AV_LOG_ERROR, 8SVX does not support more than 2
channels\n);
-return AVERROR(EINVAL);
+return AVERROR_INVALIDDATA;
Isn't this a user settable option? EINVAL was appropriate then.
from an applications point of view yes
OTOH one could argue its invalid in the headers from the container
}
switch(avctx-codec-id) {
@@ -179,7 +179,7 @@ static av_cold int eightsvx_decode_init(AVCodecContext
*avctx)
case AV_CODEC_ID_PCM_S8_PLANAR:
break;
default:
- return -1;
+ return AVERROR_INVALIDDATA;
AVERROR_BUG, or EINVAL maybe?
Unless I'm mistaken this is set depending on the selected decoder. It
looks unrelated to the stream data anyway.
seems so, yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] doc/demuxers: document gif demuxer
On Sep 2, 2014 5:31 PM, Lou Logan l...@lrcd.com wrote: From d95991c4dd423cc4bc231510255f74dda600afbc Mon Sep 17 00:00:00 2001 From: Lou Logan l...@lrcd.com Date: Thu, 28 Aug 2014 16:26:11 -0800 Subject: [PATCH] doc/demuxers: document gif demuxer Signed-off-by: Lou Logan l...@lrcd.com --- doc/demuxers.texi | 34 ++ 1 file changed, 34 insertions(+) LGTM Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vorbisenc: avoid large stack allocation.
On Wed, Sep 03, 2014 at 12:25:17AM +0200, Reimar Döffinger wrote: Code is only used during initialization, so malloc/free should be fine to use. Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de --- libavcodec/vorbisenc.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) LGTM [...] -- 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: 42507534977e2108e397a381357ee2db209475f6
On 3 September 2014 01:40, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 12:59:53AM +0100, Kieran Kunhya wrote: Patch not sent to ML so couldn't review: Why have you only changed the code to favour DESC_types and not other types? because thats what was needed to fix Ticket3766, which was what the commit tried to do. We might want to change others too, ideally would be if we had actual testcases for them that need it. So the changes can be tested. Do you have some testcases ? In general you should not be probing if there are descriptors because the descriptors are designed to make the codec detection unambiguous. How do testcases for stream detection even work in FATE? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Request for testing
On Wednesday, September 03, 2014 00:51:18 James Darnley wrote: 390c0dc TESTacodec-flac-comp-5 TESTacodec-flac-24-comp-5 --- ./tests/ref/acodec/flac-24-comp-5 2014-09-02 12:35:11.678786719 -0600 +++ tests/data/fate/acodec-flac-24-comp-5 2014-09-02 19:25:14.73914 -0600 @@ -1,4 +1,4 @@ -fedf634bba4d07734d19426620f9c31e *tests/data/fate/acodec-flac-24-comp-5.flac -238199 tests/data/fate/acodec-flac-24-comp-5.flac -95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-flac-24- comp-5.out.wav -stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes: 1058400/ 1058400 +5845db245381243c9a0abcec03955f88 *tests/data/fate/acodec-flac-24-comp-5.flac +776441 tests/data/fate/acodec-flac-24-comp-5.flac +e6fcc8c3c1b6daf9bb7d5a29dd568a45 *tests/data/fate/acodec-flac-24- comp-5.out.wav +stddev:18098.97 PSNR: 11.18 MAXDIFF:65492 bytes: 1058400/ 1058400 Test acodec-flac-24-comp-5 failed. Look at tests/data/fate/acodec-flac-24- comp-5.err for details. tests/Makefile:192: recipe for target 'fate-acodec-flac-24-comp-5' failed make: *** [fate-acodec-flac-24-comp-5] Error 1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch: 42507534977e2108e397a381357ee2db209475f6
On Wed, Sep 03, 2014 at 04:24:29AM +0200, Michael Niedermayer wrote: On Wed, Sep 03, 2014 at 02:37:48AM +0100, Kieran Kunhya wrote: On 3 September 2014 01:40, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 12:59:53AM +0100, Kieran Kunhya wrote: Patch not sent to ML so couldn't review: Why have you only changed the code to favour DESC_types and not other types? because thats what was needed to fix Ticket3766, which was what the commit tried to do. We might want to change others too, ideally would be if we had actual testcases for them that need it. So the changes can be tested. Do you have some testcases ? In general you should not be probing if there are descriptors because the descriptors are designed to make the codec detection unambiguous. yes How do testcases for stream detection even work in FATE? see tests/fate/probe.mak oops, thats just container detection, i meant tests/fate/ffprobe.mak something similar i suspect could be used but i didnt try it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix MSVC warnings about possible value truncation.
On 03.09.2014, at 02:16, Peter Kasting pkast...@google.com wrote: On Tue, Sep 2, 2014 at 5:10 PM, wm4 nfx...@googlemail.com wrote: In the end, if we do decide to enable this warning, we will have to insert some casts that are clearly safe, e.g. if (x INT_MAX) return; int y = (int)x; Indeed, if all of the nontrivial issues are fixed, those sorts of casts are presumably the majority of the trivial changes we'd have to introduce. And here is exactly where we disagree. I'm not sure what you mean by disagree. I would assume you mean you don't think we should enable the warning if it would mean having to insert any casts like this, but that's not actually disagreeing with me, that's just a statement that the benefit isn't worth the costs. Or do you mean you actually disagree that deciding to enable the warning would require inserting casts? I'm confused. I suspect similar to me he means that maybe we shouldn't enable warnings the compiler doesn't support well enough to manage to avoid trivial and obvious false positives... In other words, there should maybe be some effort compiler-side first, or alternatively the check would better be provided by a more advanced tool. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] libswresample: Avoid needlessly large on-stack array.
On 03.09.2014, at 06:28, Michael Niedermayer michae...@gmx.at wrote:
On Wed, Sep 03, 2014 at 12:01:54AM +0200, Reimar Döffinger wrote:
We only actually use a tiny part of it.
Signed-off-by: Reimar Döffinger reimar.doeffin...@gmx.de
---
libswresample/rematrix.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
i think there a multiple loops left that can access more of the array
2 i spotted:
for(i=0; i64; i++){
if(in_ch_layout out_ch_layout (1ULLi))
matrix[i][i]= 1.0;
}
Seems I missed that somehow. That one might be a bit of a mess.
if(s-rematrix_volume 0){
for(i=0; iSWR_CH_MAX; i++)
for(j=0; jSWR_CH_MAX; j++){
s-matrix[i][j] *= s-rematrix_volume;
}
}
That is s-matrix?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
