Re: [FFmpeg-devel] [PATCH v2] Fix undefined reference to xcb_shape_rectangles in xcbgrab.c
Sorry, here's an update of my patch that works with
(--enable-libxcb-shape) and without (--disable-libxcb-shape) now.
Attached is v2 of the patch.
On 11/23/2014 5:13 PM, Michael Niedermayer wrote:
Hi
On Sun, Nov 23, 2014 at 02:48:54PM -0600, Boris Reisig wrote:
It seems when using the latest ffmpeg from master git, there's an
incompatible change in the last few weeks that prevents libxcb-shape
from being detected properly in ffmpeg so it wouldn't compile
properly. I have written a patch to fix the detection to make
ffmpeg compile properly.
Example if if failing to compile.
INSTALL doc/libavcodec.3
INSTALL doc/libavformat.3
INSTALL doc/libavdevice.3
INSTALL doc/libavfilter.3
LD ffmpeg_g
libavdevice/libavdevice.a(xcbgrab.o): In function `xcbgrab_read_header':
xcbgrab.c:(.text.unlikely+0x52c): undefined reference to
`xcb_shape_rectangles'
collect2: error: ld returned 1 exit status
Makefile:122: recipe for target 'ffmpeg_g' failed
make: *** [ffmpeg_g] Error 1
a quite similar patch was already posted, and i have the same question
as with that one, does this work with --disable-libxcb-shape ?
Please someone confirm that it does work with --disable-libxcb-shape
or if not please adjust the patch so it does something appropriate
also carl has posted a untested alternative patch in the previous
thread "[FFmpeg-devel] [PATCH] libxcb-xhsape in configure"
i really would like to apply a fix for this but i need a bit feedback
on which is best and what works
Thanks
[...]
# This fixes the latest ffmpeg not compiling the latest libxcb with shape
support. Boris Reisig
diff -uNr ffmpeg-2.4.3-original/configure ffmpeg-2.4.3/configure
--- ffmpeg-2.4.3-original/configure 2014-11-24 01:46:13.961047773 -0600
+++ ffmpeg-2.4.3/configure 2014-11-24 01:46:43.840464702 -0600
@@ -254,6 +254,7 @@
--enable-libxcb enable X11 grabbing using XCB [auto]
--enable-libxcb-shm enable X11 grabbing shm communication [auto]
--enable-libxcb-xfixes enable X11 grabbing mouse rendering [auto]
+ --enable-libxcb-shapeenable X11 grabbing shape rendering [auto]
--enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
--enable-libzmq enable message passing via libzmq [no]
@@ -1386,6 +1387,7 @@
libxavs
libxcb
libxcb_shm
+libxcb_shape
libxcb_xfixes
libxvid
libzmq
@@ -5047,8 +5049,13 @@
enabled libxcb_xfixes && die "ERROR: libxcb_xfixes not found";
} && enable libxcb_xfixes; }
-add_cflags $xcb_cflags $xcb_shm_cflags $xcb_xfixes_cflags
-add_extralibs $xcb_libs $xcb_shm_libs $xcb_xfixes_libs
+disabled libxcb_shape || {
+check_pkg_config xcb-shape xcb/shape.h xcb_shape_get_rectangles || {
+enabled libxcb_shape && die "ERROR: libxcb_shape not found";
+} && enable libxcb_shape; }
+
+add_cflags $xcb_cflags $xcb_shm_cflags $xcb_xfixes_cflags $xcb_shape_cflags
+add_extralibs $xcb_libs $xcb_shm_libs $xcb_xfixes_libs $xcb_shape_libs
fi
fi
diff -uNr ffmpeg-2.4.3-original/libavdevice/xcbgrab.c
ffmpeg-2.4.3/libavdevice/xcbgrab.c
--- ffmpeg-2.4.3-original/libavdevice/xcbgrab.c 2014-11-24 01:46:14.091045233
-0600
+++ ffmpeg-2.4.3/libavdevice/xcbgrab.c 2014-11-24 01:47:42.529319460 -0600
@@ -33,6 +33,10 @@
#include
#endif
+#if CONFIG_LIBXCB_SHAPE
+#include
+#endif
+
#include "libavformat/avformat.h"
#include "libavformat/internal.h"
@@ -576,7 +580,7 @@
XCB_COPY_FROM_PARENT,
mask, values);
-#if XCB_SHAPE_RECTANGLES
+#if CONFIG_LIBXCB_SHAPE
xcb_shape_rectangles(c->conn, XCB_SHAPE_SO_SUBTRACT,
XCB_SHAPE_SK_BOUNDING, XCB_CLIP_ORDERING_UNSORTED,
c->window,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] pipeline multithreading
Hi, >From what I gather the filter graph is utilizing modern multicores by >“striping” where filters support it, i.e. an image is divided in stripes and >the filter gets called in separate threads for separate stripes. I was >wondering if there is or will be pipeline multuthreading, i.e. with a setup >such as inout -> filter1 -> filter2 -> output some threads processing frame n in the output (i.e. encoding), other threads procesing frame n+1 in filter2, others processing frame n+2 in filter1, and yet others processing frame n+3 decoding. This way non-parallel filters can be sped up, and diminishing returns for too much striping can be avoided. With modern cpus scaling easily up to 24 hardware threads I see this as neccessary to fully utilize the hardware. Is this already done? Or are there plans? If it is not done, how much more work is it? Could I help (not promising much, but I may find time, especially as this limits us…). Best Daniel P.S: please CC answers back to me, as I pipe ffmpeg mails into a folder I only check occasionally.. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] libavcodec: new API for frame threading by step
Hi, 2014-07-23 21:13 GMT+02:00 Christophe Gisquet : > The new _progress3 functions allow reporting the x,y position in > decoding. > > ff_thread_report_progress3_raster_end allows signaling the end of > a raster line and updates unconditionally the position to the > start of next raster line. > > ff_thread_report_progress3_increment tries to increment position > if it lies on the same raster line as current position. I think participants to the openhevc project have taken some potential interest in this. My suggestion some time ago to them was to make the staircase more generic because of WPP, ie have more than 1 stair. Hopefully it will not finish in just an article, and they will resubmit improvement to this patchset. So, dropped for that reason. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] bprint.h can't be included in C++ code
Le tridi 3 frimaire, an CCXXIII, Vadim Kalinsky a écrit :
> Yep, my bad.
Thanks for the updated patch.
> Maybe I'm little contaminated with modern PLs, but I don't see huge
> difference in readability between the old and the new versions. Both are
> terrible :-)
At least, this one, I can actually read what is being changed directly in
the patch.
> From 6e97656e9765b734ca66d1665eba190e37be3312 Mon Sep 17 00:00:00 2001
> From: Vadim Kalinsky
> Date: Sun, 23 Nov 2014 21:29:25 -0500
> Subject: [PATCH] Squashed
>
> ---
> libavutil/bprint.h | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/bprint.h b/libavutil/bprint.h
> index d1682fc..4df57ce 100644
> --- a/libavutil/bprint.h
> +++ b/libavutil/bprint.h
> @@ -30,9 +30,12 @@
> * Define a structure with extra padding to a fixed size
> * This helps ensuring binary compatibility with future versions.
> */
> -#define FF_PAD_STRUCTURE(size, ...) \
> +#define FF_PAD_STRUCTURE(name,size, ...) \
^
Nit: space after commas.
> +typedef struct pad_structure_helper_##name { __VA_ARGS__ }
> pad_structure_helper_##name; \
Is it necessary to typedef the structure on top of declaring it? In C, this:
struct foo { ... };
... sizeof(struct foo); ...
is legal, no need to typedef it.
Apart from that, I think the helper structure should be scoped in the ff_
namespace: ff_pad_structure_helper_##name (but in that case, it may not need
to be that long; not a problem though).
> +typedef struct name { \
> __VA_ARGS__ \
> -char reserved_padding[size - sizeof(struct { __VA_ARGS__ })];
> +char reserved_padding[size - sizeof(pad_structure_helper_##name)]; \
> +} name;
>
> /**
> * Buffer to print data progressively
> @@ -74,15 +77,14 @@
> * internal buffer is large enough to hold a reasonable paragraph of text,
> * such as the current paragraph.
> */
> -typedef struct AVBPrint {
> -FF_PAD_STRUCTURE(1024,
> +
Nit: no empty line between doxy and declaration.
And I wonder: does Doxygen understand the resulting construct? With the
current code, the fields are not shown, but at least the documentation for
the structure is produced:
http://ffmpeg.org/doxygen/trunk/bprint_8h.html
> +FF_PAD_STRUCTURE(AVBPrint, 1024,
> char *str; /**< string so far */
> unsigned len; /**< length so far */
> unsigned size; /**< allocated memory */
> unsigned size_max; /**< maximum allocated memory */
> char reserved_internal_buffer[1];
> -)
> -} AVBPrint;
> +)
>
> /**
> * Convenience macros for special values for av_bprint_init() size_max
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/rawdec: raw formats have no timestamps
Some raw demuxers already had AVFMT_NOTIMESTAMPS set. Add it for all the
others.
---
Not sure if this is correct. But I noticed that libavformat does not
return any timestamps for .shn (Shorten) files, and I'd like to use
the AVFMT_NOTIMESTAMPS flag to make up my own timestamps (or at least
let such files start at pts=0).
---
libavformat/rawdec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavformat/rawdec.c b/libavformat/rawdec.c
index 69b95bc..bbb76b6 100644
--- a/libavformat/rawdec.c
+++ b/libavformat/rawdec.c
@@ -119,6 +119,7 @@ AVInputFormat ff_data_demuxer = {
.read_header= ff_raw_data_read_header,
.read_packet= ff_raw_read_partial_packet,
.raw_codec_id = AV_CODEC_ID_NONE,
+.flags = AVFMT_NOTIMESTAMPS,
};
#endif
@@ -129,7 +130,7 @@ AVInputFormat ff_latm_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("raw LOAS/LATM"),
.read_header= ff_raw_audio_read_header,
.read_packet= ff_raw_read_partial_packet,
-.flags = AVFMT_GENERIC_INDEX,
+.flags = AVFMT_GENERIC_INDEX | AVFMT_NOTIMESTAMPS,
.extensions = "latm",
.raw_codec_id = AV_CODEC_ID_AAC_LATM,
};
@@ -211,7 +212,7 @@ AVInputFormat ff_mlp_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("raw MLP"),
.read_header= ff_raw_audio_read_header,
.read_packet= ff_raw_read_partial_packet,
-.flags = AVFMT_GENERIC_INDEX,
+.flags = AVFMT_GENERIC_INDEX | AVFMT_NOTIMESTAMPS,
.extensions = "mlp",
.raw_codec_id = AV_CODEC_ID_MLP,
};
@@ -223,7 +224,7 @@ AVInputFormat ff_truehd_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("raw TrueHD"),
.read_header= ff_raw_audio_read_header,
.read_packet= ff_raw_read_partial_packet,
-.flags = AVFMT_GENERIC_INDEX,
+.flags = AVFMT_GENERIC_INDEX | AVFMT_NOTIMESTAMPS,
.extensions = "thd",
.raw_codec_id = AV_CODEC_ID_TRUEHD,
};
@@ -235,7 +236,7 @@ AVInputFormat ff_shorten_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("raw Shorten"),
.read_header= ff_raw_audio_read_header,
.read_packet= ff_raw_read_partial_packet,
-.flags = AVFMT_NOBINSEARCH | AVFMT_NOGENSEARCH |
AVFMT_NO_BYTE_SEEK,
+.flags = AVFMT_NOBINSEARCH | AVFMT_NOGENSEARCH |
AVFMT_NO_BYTE_SEEK|AVFMT_NOTIMESTAMPS,
.extensions = "shn",
.raw_codec_id = AV_CODEC_ID_SHORTEN,
};
--
2.1.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/bprint: make header work with C++, simplify
This change should be ABI-compatible. Since the size of the useable
internal buffer was actually different on 32 bit and 64 bit, so the code
contains a somewhat ugly kludge to maintain ABI-compatibility. It can be
removed on the next ABI-bump.
---
Note that there are the following (and IMO sufficient) methods left
to add fields without breaking ABI:
- allocate extra fields in reserved_internal_buffer
- add the fields freely, and mess with the reserved_internal_buffer size
- add unused dummy fields
---
libavutil/bprint.c | 3 +--
libavutil/bprint.h | 12 +---
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/libavutil/bprint.c b/libavutil/bprint.c
index 0a0d078..d340c1f 100644
--- a/libavutil/bprint.c
+++ b/libavutil/bprint.c
@@ -68,8 +68,7 @@ static void av_bprint_grow(AVBPrint *buf, unsigned extra_len)
void av_bprint_init(AVBPrint *buf, unsigned size_init, unsigned size_max)
{
-unsigned size_auto = (char *)buf + sizeof(*buf) -
- buf->reserved_internal_buffer;
+unsigned size_auto = sizeof(buf->reserved_internal_buffer);
if (size_max == 1)
size_max = size_auto;
diff --git a/libavutil/bprint.h b/libavutil/bprint.h
index d1682fc..781d711 100644
--- a/libavutil/bprint.h
+++ b/libavutil/bprint.h
@@ -27,14 +27,6 @@
#include "avstring.h"
/**
- * Define a structure with extra padding to a fixed size
- * This helps ensuring binary compatibility with future versions.
- */
-#define FF_PAD_STRUCTURE(size, ...) \
-__VA_ARGS__ \
-char reserved_padding[size - sizeof(struct { __VA_ARGS__ })];
-
-/**
* Buffer to print data progressively
*
* The string buffer grows as necessary and is always 0-terminated.
@@ -75,13 +67,11 @@
* such as the current paragraph.
*/
typedef struct AVBPrint {
-FF_PAD_STRUCTURE(1024,
char *str; /**< string so far */
unsigned len; /**< length so far */
unsigned size; /**< allocated memory */
unsigned size_max; /**< maximum allocated memory */
-char reserved_internal_buffer[1];
-)
+char reserved_internal_buffer[1000 + (sizeof(void*) == 4 ? 8 : 0)];
} AVBPrint;
/**
--
2.1.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] bprint.h can't be included in C++ code
On Fri, 21 Nov 2014 13:43:20 -0500 Vadim Kalinsky wrote: > C++ does not support anonymous struct. > Proposed an alternative patch ([PATCH] avutil/bprint: make header work with C++, simplify). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/bprint: make header work with C++, simplify
Le quartidi 4 frimaire, an CCXXIII, wm4 a écrit : > This change should be ABI-compatible. Since the size of the useable > internal buffer was actually different on 32 bit and 64 bit, so the code > contains a somewhat ugly kludge to maintain ABI-compatibility. It can be > removed on the next ABI-bump. No. Please read the discussion that lead to the current implementation for the explanations. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
In order to support multiple IDAT of fdAT chunks following an fcTL one,
transmit all the chunks between two fcTL ones (or between fcTL and IEND
one).
---
libavformat/apngdec.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 1e0f1c7..756cdd1 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec.c
@@ -325,8 +325,6 @@ static int apng_read_packet(AVFormatContext *s, AVPacket
*pkt)
* and needed next:
* 4 (length)
* 4 (tag (must be fdAT or IDAT))
- *
- * TODO: support multiple fdAT following an fcTL
*/
/* if num_play is not 1, then the seekback is already guaranteed */
if (ctx->num_play == 1 && (ret = ffio_ensure_seekback(pb, 46)) < 0)
@@ -350,15 +348,35 @@ static int apng_read_packet(AVFormatContext *s, AVPacket
*pkt)
tag != MKTAG('I', 'D', 'A', 'T'))
return AVERROR_INVALIDDATA;
-if ((ret = avio_seek(pb, -46, SEEK_CUR)) < 0)
-return ret;
-
size = 38 /* fcTL */ + 8 /* len, tag */ + len + 4 /* crc */;
if (size > INT_MAX)
return AVERROR(EINVAL);
-if ((ret = av_get_packet(pb, pkt, size)) < 0)
+if ((ret = avio_seek(pb, -46, SEEK_CUR)) < 0 ||
+(ret = av_append_packet(pb, pkt, size)) < 0)
+return ret;
+
+if (ctx->num_play == 1 && (ret = ffio_ensure_seekback(pb, 8)) < 0)
return ret;
+
+len = avio_rb32(pb);
+tag = avio_rl32(pb);
+while (tag &&
+ tag != MKTAG('f', 'c', 'T', 'L') &&
+ tag != MKTAG('I', 'E', 'N', 'D')) {
+if (len > 0x7fff)
+return AVERROR_INVALIDDATA;
+if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0 ||
+(ret = av_append_packet(pb, pkt, len + 12)) < 0)
+return ret;
+if (ctx->num_play == 1 && (ret = ffio_ensure_seekback(pb, 8)) < 0)
+return ret;
+len = avio_rb32(pb);
+tag = avio_rl32(pb);
+}
+if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0)
+return ret;
+
if (ctx->is_key_frame)
pkt->flags |= AV_PKT_FLAG_KEY;
return ret;
--
2.2.0.rc2.23.gca0107e
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
In order to support multiple IDAT of fdAT chunks following an fcTL one,
transmit all the chunks between two fcTL ones (or between fcTL and IEND
one).
---
libavformat/apngdec.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 1e0f1c7..d766a87 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec.c
@@ -24,10 +24,6 @@
* APNG demuxer.
* @see https://wiki.mozilla.org/APNG_Specification
* @see http://www.w3.org/TR/PNG
- *
- * Not supported (yet):
- * - streams with chunks other than fcTL / fdAT / IEND after the first fcTL
- * - streams with multiple fdAT chunks after an fcTL one
*/
#include "avformat.h"
@@ -325,8 +321,6 @@ static int apng_read_packet(AVFormatContext *s, AVPacket
*pkt)
* and needed next:
* 4 (length)
* 4 (tag (must be fdAT or IDAT))
- *
- * TODO: support multiple fdAT following an fcTL
*/
/* if num_play is not 1, then the seekback is already guaranteed */
if (ctx->num_play == 1 && (ret = ffio_ensure_seekback(pb, 46)) < 0)
@@ -350,15 +344,35 @@ static int apng_read_packet(AVFormatContext *s, AVPacket
*pkt)
tag != MKTAG('I', 'D', 'A', 'T'))
return AVERROR_INVALIDDATA;
-if ((ret = avio_seek(pb, -46, SEEK_CUR)) < 0)
-return ret;
-
size = 38 /* fcTL */ + 8 /* len, tag */ + len + 4 /* crc */;
if (size > INT_MAX)
return AVERROR(EINVAL);
-if ((ret = av_get_packet(pb, pkt, size)) < 0)
+if ((ret = avio_seek(pb, -46, SEEK_CUR)) < 0 ||
+(ret = av_append_packet(pb, pkt, size)) < 0)
+return ret;
+
+if (ctx->num_play == 1 && (ret = ffio_ensure_seekback(pb, 8)) < 0)
+return ret;
+
+len = avio_rb32(pb);
+tag = avio_rl32(pb);
+while (tag &&
+ tag != MKTAG('f', 'c', 'T', 'L') &&
+ tag != MKTAG('I', 'E', 'N', 'D')) {
+if (len > 0x7fff)
+return AVERROR_INVALIDDATA;
+if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0 ||
+(ret = av_append_packet(pb, pkt, len + 12)) < 0)
+return ret;
+if (ctx->num_play == 1 && (ret = ffio_ensure_seekback(pb, 8)) < 0)
+return ret;
+len = avio_rb32(pb);
+tag = avio_rl32(pb);
+}
+if ((ret = avio_seek(pb, -8, SEEK_CUR)) < 0)
return ret;
+
if (ctx->is_key_frame)
pkt->flags |= AV_PKT_FLAG_KEY;
return ret;
--
2.2.0.rc2.23.gca0107e
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: add APNG support.
Hi, - Mail original - > On Fri, Nov 21, 2014 at 08:09:50AM -0500, compn wrote: > > On Fri, 21 Nov 2014 12:05:47 +0100 > > Benoit Fouet wrote: > > > > > configure | 1 + > > > libavcodec/Makefile | 1 + > > > libavcodec/allcodecs.c | 1 + > > > libavcodec/avcodec.h| 1 + > > > libavcodec/codec_desc.c | 8 +++ > > > libavcodec/pngdec.c | 139 > > > > missing addition of apng to docs. > > maybe this should be done when apng support is more complete > ATM from > https://people.mozilla.org/~dolske/apng/demo.html > not all files play yet and not all play correctly > > Either way this is very nice work, ill apply it in a moment > should be easier to improve and review on top of this > I'll take some time tomorrow for the docs and changelog entries for the demuxer, as my last patch makes it feature complete (to my knowledge at least). Then I'll work on what I called "non key-frames" on the decoder side, trying to dig a bit more how the dispose and blend operations could be handled. Thanks, -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/bprint: make header work with C++, simplify
On 24.11.2014, at 15:27, Nicolas George wrote: > Le quartidi 4 frimaire, an CCXXIII, wm4 a écrit : >> This change should be ABI-compatible. Since the size of the useable >> internal buffer was actually different on 32 bit and 64 bit, so the code >> contains a somewhat ugly kludge to maintain ABI-compatibility. It can be >> removed on the next ABI-bump. > > No. Please read the discussion that lead to the current implementation for > the explanations. Hm, I'd say that discussion should probably be captured in comments next to the code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] pipeline multithreading
On Mon, Nov 24, 2014 at 3:35 AM, Daniel Oberhoff wrote: > Hi, > > From what I gather the filter graph is utilizing modern multicores by > “striping” where filters support it, i.e. an image is divided in stripes > and the filter gets called in separate threads for separate stripes. In FFmpeg we call it slice threading. > I was wondering if there is or will be pipeline multuthreading, i.e. > with a setup such as > > inout -> filter1 -> filter2 -> output > > some threads processing frame n in the output (i.e. encoding), > other threads procesing frame n+1 in filter2, others processing frame > n+2 in filter1, and yet others processing frame n+3 decoding. This > way non-parallel filters can be sped up, and diminishing returns for > too much striping can be avoided. With modern cpus scaling easily > up to 24 hardware threads I see this as neccessary to fully utilize the > hardware. We call it "frame threading." There are some decoders that already support it. > > Is this already done? Or are there plans? If it is not done, how much > more work is it? Could I help (not promising much, but I may find time, > especially as this limits us…). If the filter is independent of past and future frames then it is pretty easy (just like the "intra-only" decoders). For other ones I am not so sure. Clément knows more about it. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] pipeline multithreading
On Mon, Nov 24, 2014 at 12:35:58PM +0100, Daniel Oberhoff wrote: > inout -> filter1 -> filter2 -> output > > some threads processing frame n in the output (i.e. encoding), other threads > procesing frame n+1 in filter2, others processing frame n+2 in filter1, and > yet others processing frame n+3 decoding. This way non-parallel filters can > be sped up, and diminishing returns for too much striping can be avoided. > With modern cpus scaling easily up to 24 hardware threads I see this as > neccessary to fully utilize the hardware. Keep in mind the two things: 1) It only works for cases where many filters are used, which is not necessarily a common case 2) While it would possibly be simpler to implement, you do not want each filter to use its own thread. This leads to massive bouncing of data between caches and especially for filters that use in-place processing a large amount of cache coherency traffic. Ideally, when used with frame multithreading you would even re-use the thread that did the decoding. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] bprint.h can't be included in C++ code
> Nit: space after commas.
> Is it necessary to typedef the structure on top of declaring it? In C, this:
> {...} is legal, no need to typedef it.
> Apart from that, I think the helper structure should be scoped in the
> ff_namespace
> Nit: no empty line between doxy and declaration.
Patch attached.
0001-Squashed-commits.patch
Description: Binary data
> And I wonder: does Doxygen understand the resulting construct?
I guess that (not good) behaviour is not changed.
BTW, isn't the whole stuff slightly over-engineered? Why is "binary
compatibility" needed (and with what?).
Wouldn't it be easier in terms of compatibility, readability and doxygenability
to define simple C structure?
struct AVBPrint {
char *str; /**< string so far */
unsigned len; /**< length so far */
unsigned size; /**< allocated memory */
unsigned size_max; /**< maximum allocated memory */
char reserved_internal_buffer[1024];
};
Vadim Kalinsky
kalinsky.ru
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] Fix undefined reference to xcb_shape_rectangles in xcbgrab.c
On Mon, Nov 24, 2014 at 02:00:05AM -0600, Boris Reisig wrote: > Sorry, here's an update of my patch that works with > (--enable-libxcb-shape) and without (--disable-libxcb-shape) now. > Attached is v2 of the patch. > > On 11/23/2014 5:13 PM, Michael Niedermayer wrote: > >Hi > > > >On Sun, Nov 23, 2014 at 02:48:54PM -0600, Boris Reisig wrote: > >>It seems when using the latest ffmpeg from master git, there's an > >>incompatible change in the last few weeks that prevents libxcb-shape > >>from being detected properly in ffmpeg so it wouldn't compile > >>properly. I have written a patch to fix the detection to make > >>ffmpeg compile properly. > >> > >> > >>Example if if failing to compile. > >> > >>INSTALL doc/libavcodec.3 > >>INSTALL doc/libavformat.3 > >>INSTALL doc/libavdevice.3 > >>INSTALL doc/libavfilter.3 > >>LD ffmpeg_g > >>libavdevice/libavdevice.a(xcbgrab.o): In function `xcbgrab_read_header': > >>xcbgrab.c:(.text.unlikely+0x52c): undefined reference to > >>`xcb_shape_rectangles' > >>collect2: error: ld returned 1 exit status > >>Makefile:122: recipe for target 'ffmpeg_g' failed > >>make: *** [ffmpeg_g] Error 1 > >a quite similar patch was already posted, and i have the same question > >as with that one, does this work with --disable-libxcb-shape ? > > > >Please someone confirm that it does work with --disable-libxcb-shape > >or if not please adjust the patch so it does something appropriate > >also carl has posted a untested alternative patch in the previous > >thread "[FFmpeg-devel] [PATCH] libxcb-xhsape in configure" > >i really would like to apply a fix for this but i need a bit feedback > >on which is best and what works > > > >Thanks > > > >[...] > > > > # This fixes the latest ffmpeg not compiling the latest libxcb with shape > support. Boris Reisig > diff -uNr ffmpeg-2.4.3-original/configure ffmpeg-2.4.3/configure applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
On 24/11/14 12:12 PM, Benoit Fouet wrote: > In order to support multiple IDAT of fdAT chunks following an fcTL one, > transmit all the chunks between two fcTL ones (or between fcTL and IEND > one). Using one of the samples from https://people.mozilla.org/~dolske/apng/demo.html $ ./ffmpeg -i chompy2.png chompy2.mp4 -loglevel debug [...] Input #0, apng, from 'chompy2.png': Duration: N/A, bitrate: N/A Stream #0:0: Video: apng, rgba, 166x120, 14.58 fps, 10 tbr, 90k tbn, 90k tbc Output #0, mp4, to 'chompy2.mp4': Metadata: encoder : Lavf56.15.100 Stream #0:0, 0, 1/10240: Video: mpeg4 ( [0][0][0] / 0x0020), yuv420p, 166x120, 1/10, q=2-31, 200 kb/s, 10 fps, 10240 tbn, 10 tbc Metadata: encoder : Lavc56.13.100 mpeg4 Stream mapping: Stream #0:0 -> #0:0 (apng (native) -> mpeg4 (native)) Press [q] to stop, [?] for help *** dropping frame 8 from stream 0 at ts 5 *** dropping frame 10 from stream 0 at ts 7 *** dropping frame 12 from stream 0 at ts 9 *** dropping frame 14 from stream 0 at ts 11 [output stream 0:0 @ 00317a20] EOF on sink link output stream 0:0:default. No more output streams to write to, finishing. frame= 16 fps=0.0 q=2.3 Lsize= 64kB time=00:00:01.60 bitrate= 328.6kbits/s dup=0 drop=5 video:63kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.433775% Input file #0 (chompy2.png): Input stream #0:0 (video): 21 packets read (288248 bytes); 21 frames decoded; Total: 21 packets (288248 bytes) demuxed Output file #0 (chompy2.mp4): Output stream #0:0 (video): 16 frames encoded; 16 packets muxed (64794 bytes); Total: 16 packets (64794 bytes) muxed 23 frames successfully decoded, 0 decoding errors I fixed this by using time_base instead of r_frame_rate in decode_fctl_chunk, but i'm not sure if that's correct either because it's changed after reading every frame, and in this one apng file the last frame has a different delay_den and delay_num values than in every previous frame. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: fix accurate seeking with -copyts
On Sun, Nov 23, 2014 at 11:31:20PM -0600, Rodger Combs wrote: > --- > ffmpeg.h| 1 + > ffmpeg_filter.c | 18 -- > 2 files changed, 17 insertions(+), 2 deletions(-) applied btw, a fate test (especially one which shows the timestamps like with framecrc) for this could be quite usefull to reduce the chance of it breaking at some future point thx [...] -- 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] avformat/rawdec: raw formats have no timestamps
On Mon, Nov 24, 2014 at 03:20:53PM +0100, wm4 wrote: > Some raw demuxers already had AVFMT_NOTIMESTAMPS set. Add it for all the > others. > --- > Not sure if this is correct. But I noticed that libavformat does not > return any timestamps for .shn (Shorten) files, and I'd like to use > the AVFMT_NOTIMESTAMPS flag to make up my own timestamps (or at least > let such files start at pts=0). > --- > libavformat/rawdec.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/avuienc: fix mem leak in case of init failure
On Mon, Nov 24, 2014 at 04:52:01AM +0100, Lukasz Marek wrote: > Signed-off-by: Lukasz Marek > --- > libavcodec/avuienc.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) LGTM [...] -- 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
Re: [FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
Hi, Le 24/11/2014 17:54, James Almer a écrit : On 24/11/14 12:12 PM, Benoit Fouet wrote: In order to support multiple IDAT of fdAT chunks following an fcTL one, transmit all the chunks between two fcTL ones (or between fcTL and IEND one). Using one of the samples from https://people.mozilla.org/~dolske/apng/demo.html $ ./ffmpeg -i chompy2.png chompy2.mp4 -loglevel debug Just to be sure: the problem you have is present whther or not this patch is, right? [...] Input #0, apng, from 'chompy2.png': Duration: N/A, bitrate: N/A Stream #0:0: Video: apng, rgba, 166x120, 14.58 fps, 10 tbr, 90k tbn, 90k tbc Output #0, mp4, to 'chompy2.mp4': Metadata: encoder : Lavf56.15.100 Stream #0:0, 0, 1/10240: Video: mpeg4 ( [0][0][0] / 0x0020), yuv420p, 166x120, 1/10, q=2-31, 200 kb/s, 10 fps, 10240 tbn, 10 tbc Metadata: encoder : Lavc56.13.100 mpeg4 Stream mapping: Stream #0:0 -> #0:0 (apng (native) -> mpeg4 (native)) Press [q] to stop, [?] for help *** dropping frame 8 from stream 0 at ts 5 *** dropping frame 10 from stream 0 at ts 7 *** dropping frame 12 from stream 0 at ts 9 *** dropping frame 14 from stream 0 at ts 11 [output stream 0:0 @ 00317a20] EOF on sink link output stream 0:0:default. No more output streams to write to, finishing. frame= 16 fps=0.0 q=2.3 Lsize= 64kB time=00:00:01.60 bitrate= 328.6kbits/s dup=0 drop=5 video:63kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.433775% Input file #0 (chompy2.png): Input stream #0:0 (video): 21 packets read (288248 bytes); 21 frames decoded; Total: 21 packets (288248 bytes) demuxed Output file #0 (chompy2.mp4): Output stream #0:0 (video): 16 frames encoded; 16 packets muxed (64794 bytes); Total: 16 packets (64794 bytes) muxed 23 frames successfully decoded, 0 decoding errors I fixed this by using time_base instead of r_frame_rate in decode_fctl_chunk, but i'm not sure if that's correct either because it's changed after reading every frame, and in this one apng file the last frame has a different delay_den and delay_num values than in every previous frame. That was the part I'd have loved to get some feedback on. I have no preference whatsoever on which solution we use for frame duration, but it seems rather clear with the issue you get that the one I've put in place is not the right one :-) -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
On 24/11/14 4:52 PM, Benoit Fouet wrote: > Hi, > > Le 24/11/2014 17:54, James Almer a écrit : >> On 24/11/14 12:12 PM, Benoit Fouet wrote: >>> In order to support multiple IDAT of fdAT chunks following an fcTL one, >>> transmit all the chunks between two fcTL ones (or between fcTL and IEND >>> one). >> Using one of the samples from >> https://people.mozilla.org/~dolske/apng/demo.html >> >> $ ./ffmpeg -i chompy2.png chompy2.mp4 -loglevel debug > > Just to be sure: the problem you have is present whther or not this patch is, > right? Yes, but i was only able to notice it now that this file can be decoded. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
On Mon, Nov 24, 2014 at 04:12:26PM +0100, Benoit Fouet wrote: > In order to support multiple IDAT of fdAT chunks following an fcTL one, > transmit all the chunks between two fcTL ones (or between fcTL and IEND > one). > --- > libavformat/apngdec.c | 34 -- > 1 file changed, 24 insertions(+), 10 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.
On Mon, Nov 24, 2014 at 09:15:27PM +0100, Michael Niedermayer wrote: > On Mon, Nov 24, 2014 at 04:12:26PM +0100, Benoit Fouet wrote: > > In order to support multiple IDAT of fdAT chunks following an fcTL one, > > transmit all the chunks between two fcTL ones (or between fcTL and IEND > > one). > > --- > > libavformat/apngdec.c | 34 -- > > 1 file changed, 24 insertions(+), 10 deletions(-) > > applied > > thanks btw, forgot to mention, you maybe want to add yourself to the MAINTAINERs file for apng [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavc/options: fix leaks in avcodec_free_context
On Mon, Nov 24, 2014 at 05:16:49AM +0100, Lukasz Marek wrote: > Signed-off-by: Lukasz Marek > --- > libavcodec/options.c | 3 +++ > 1 file changed, 3 insertions(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/utils: free private options on avcodec_open2 fail
On Sun, Nov 23, 2014 at 12:58:07AM +0100, Lukasz Marek wrote: > It protects leaking string/binary/dict options from priv context. > > Signed-off-by: Lukasz Marek > --- > libavcodec/utils.c | 2 ++ > 1 file changed, 2 insertions(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/opt: handle NULL obj in av_opt_next
On Sun, Nov 23, 2014 at 01:10:21AM +0100, Lukasz Marek wrote:
> On 23.11.2014 00:59, Clément Bœsch wrote:
> >On Sun, Nov 23, 2014 at 12:58:06AM +0100, Lukasz Marek wrote:
> >>It indirectly also fixes av_opt_free for NULL objs.
> >>
> >>Signed-off-by: Lukasz Marek
> >>---
> >> libavutil/opt.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >>diff --git a/libavutil/opt.c b/libavutil/opt.c
> >>index 47b1f0c..85330c9 100644
> >>--- a/libavutil/opt.c
> >>+++ b/libavutil/opt.c
> >>@@ -50,6 +50,8 @@ const AVOption *av_next_option(void *obj, const AVOption
> >>*last)
> >>
> >> const AVOption *av_opt_next(void *obj, const AVOption *last)
> >> {
> >>+if (!obj)
> >>+return NULL;
> >> AVClass *class = *(AVClass**)obj;
> >
> >AVClass *class must be declared above
>
> Thx for notice, updated patch is attached.
>
> opt.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 39406482021ccfc2ee83515a3cf9ea809583f711
> 0001-lavu-opt-handle-NULL-obj-in-av_opt_next.patch
> From 01f6964251ae9805c62794f3dca17be0cd2255c1 Mon Sep 17 00:00:00 2001
> From: Lukasz Marek
> Date: Sun, 23 Nov 2014 00:48:17 +0100
> Subject: [PATCH] lavu/opt: handle NULL obj in av_opt_next
>
> It indirectly also fixes av_opt_free for NULL objs.
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/examples/decoding_encoding: fix storing all channels
On Fri, Nov 21, 2014 at 02:38:20AM +0100, Michael Niedermayer wrote: > Fixes Ticket3355 > > Signed-off-by: Michael Niedermayer > --- > doc/examples/decoding_encoding.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] web/style: Only add bottom border when requested to 's in
On Saturday, November 22, 2014, Timothy Gu wrote: > When the is a row heading, the border looks as ugly as heck. > > Add a special case for in as a long heading. > > Signed-off-by: Timothy Gu > > --- > > This does not have any difference in the website right now, but there will > be > in the new fateserver. > > --- > src/download| 2 +- > src/less/style.less | 17 + > 2 files changed, 18 insertions(+), 1 deletion(-) Ping patch set. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] web/style: Only add bottom border when requested to 's in
On Sat, Nov 22, 2014 at 10:36:18PM -0800, Timothy Gu wrote: > When the is a row heading, the border looks as ugly as heck. > > Add a special case for in as a long heading. > > Signed-off-by: Timothy Gu > --- > > This does not have any difference in the website right now, but there will be > in the new fateserver. > > --- > src/download| 2 +- > src/less/style.less | 17 + > 2 files changed, 18 insertions(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] web/style: Remove ugly white border around tables on mobile devices
On Sat, Nov 22, 2014 at 10:36:19PM -0800, Timothy Gu wrote: > Signed-off-by: Timothy Gu > --- > > See http://imgur.com/qsnnjAi > > --- > src/less/style.less | 4 > 1 file changed, 4 insertions(+) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] web/download: Fix indentation
On Sat, Nov 22, 2014 at 10:36:21PM -0800, Timothy Gu wrote: > Signed-off-by: Timothy Gu > --- > src/download | 86 > ++-- > 1 file changed, 43 insertions(+), 43 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] web/download: Make "snapshot" and "browse" buttons
On Sat, Nov 22, 2014 at 10:36:20PM -0800, Timothy Gu wrote: > Signed-off-by: Timothy Gu > --- > > See end results at http://imgur.com/GtLoaFe,PF2DeNy (both desktop and mobile) > > --- > src/download | 57 ++--- > 1 file changed, 38 insertions(+), 19 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
