[FFmpeg-devel] [PATCH] avfilter/src_movie: call open_stream after guess_channel_layout
fix error 'Channel layout change is not supported' when
opening wav file
Signed-off-by: Muhammad Faiz
---
libavfilter/src_movie.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index 9ac115b..4714ca9 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -303,15 +303,15 @@ static av_cold int movie_common_init(AVFilterContext *ctx)
pad.config_props = movie_config_output_props;
pad.request_frame = movie_request_frame;
ff_insert_outpad(ctx, i, &pad);
-ret = open_stream(ctx, &movie->st[i]);
-if (ret < 0)
-return ret;
if ( movie->st[i].st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
!movie->st[i].st->codecpar->channel_layout) {
ret = guess_channel_layout(&movie->st[i], i, ctx);
if (ret < 0)
return ret;
}
+ret = open_stream(ctx, &movie->st[i]);
+if (ret < 0)
+return ret;
}
av_log(ctx, AV_LOG_VERBOSE, "seek_point:%"PRIi64" format_name:%s
file_name:%s stream_index:%d\n",
--
2.5.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder
Hi, > > 2016-05-30 17:50 GMT+02:00 Paul B Mahol : > > On 5/30/16, Piotr Bandurski wrote: > >> Hi, > >> > >>> patch attached. > >> > >> Is decoding of interlaced video supported? Because I get here invalid > >> output. > >> > >> Also crash happens with this fuzzed file: > >> > >> https://www.datafilehost.com/d/c64eb5b1 > >> > >> Regards > > > > Can you create YUVA video somehow? I can't with virtualdub. > > So a final iteration was pushed. > > Can any of you create fate tests, ideally for 3 cases, > "normal"/"interlaced"/"YUVA" (or whatever required introducing quirks > in the code) No idea how to create fate tests, but a few samples are here, so eventually someone can add them: https://www.datafilehost.com/d/1df27b13 Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/graphparser: remove '\n' from parse_filter
On Thu, May 5, 2016 at 2:21 PM, Muhammad Faiz wrote:
> this allow a filter to be written like this:
> aformat =
> sample_fmts = fltp|flt:
> sample_rates = 44100|44800
>
> Signed-off-by: Muhammad Faiz
> ---
> libavfilter/graphparser.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
> index 8d15b5d..03062af 100644
> --- a/libavfilter/graphparser.c
> +++ b/libavfilter/graphparser.c
> @@ -165,12 +165,12 @@ static int parse_filter(AVFilterContext **filt_ctx,
> const char **buf, AVFilterGr
> int index, void *log_ctx)
> {
> char *opts = NULL;
> -char *name = av_get_token(buf, "=,;[\n");
> +char *name = av_get_token(buf, "=,;[");
> int ret;
>
> if (**buf == '=') {
> (*buf)++;
> -opts = av_get_token(buf, "[],;\n");
> +opts = av_get_token(buf, "[],;");
> }
>
> ret = create_filter(filt_ctx, graph, index, name, opts, log_ctx);
> --
> 2.5.0
>
No response. So, I will try to explain this patch.
It allows filter definition to span across multiple lines.
This behaviour is useful to make filter graph more readable,
especially when stored on file.
For example, using lavfi
ffplay -graph_file filter.txt -f lavfi my_lavfi
filter.txt:
amovie=audio.mp3,
aformat=
channel_layouts = stereo:
sample_rates= 48000:
sample_fmts = flt|fltp,
asplit [out0],
showcqt =
tc = 0.33:
fps = 60
[out1]
Thank's
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/avf_showcqt: full chroma blending on draw_axis_yuv
On Tue, May 31, 2016 at 9:56 PM, Muhammad Faiz wrote: > improve quality on axis drawing with yuv422p and yuv420p format > > Signed-off-by: Muhammad Faiz > --- > libavfilter/avf_showcqt.c | 73 > ++- > 1 file changed, 60 insertions(+), 13 deletions(-) > applied thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use int32_t instead of int for gaintable in hdcd filter
On Wed, Jun 01, 2016 at 09:47:25PM -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Jun 1, 2016 at 7:47 PM, Michael Niedermayer > wrote: > > > On Thu, Jun 02, 2016 at 12:01:50AM +0200, Benjamin St wrote: > > > > > > > > af_hdcd.c |2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > b56f3e60dbd8c688ad37cc5dceb5378f68855622 > > 0001-Use-int32_t-instead-of-int-for-gaintable-in-hdcd-fil.patch > > > From 11bbac3343cb06ce0862ffbbf6365ba834b4284b Mon Sep 17 00:00:00 2001 > > > From: Benjamin Steffes > > > Date: Sun, 29 May 2016 17:45:33 +0200 > > > Subject: [PATCH] Use int32_t instead of int for gaintable in hdcd filter. > > > > the commit message is missing the "why" > > > > also note POSIX gurantees >=32bit int and we require POSIX > > > It may be to prevent the theoretical case where the container type (int) > would be 64 bit on some platforms, which would waste some space... indeed, that makes sense [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued 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 few compiler warnings
On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote: [...] > vf_hwdownload.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > 5eb7416fececde847414f37de9a78a4e1cd5e1af > 0004-libavfilter-vf_hwdownload-show-error-when-ff_formats.patch > From d1d00989a374facba3cdf777d95c61bf385f1332 Mon Sep 17 00:00:00 2001 > From: dsmudhar > Date: Sun, 22 May 2016 06:26:36 +0530 > Subject: [PATCH 4/7] libavfilter/vf_hwdownload: show error when ff_formats_ref > fails > > --- > libavfilter/vf_hwdownload.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c > index 2dcc9fa..79ea82d 100644 > --- a/libavfilter/vf_hwdownload.c > +++ b/libavfilter/vf_hwdownload.c > @@ -56,8 +56,10 @@ static int hwdownload_query_formats(AVFilterContext *avctx) > } > } > > -ff_formats_ref(infmts, &avctx->inputs[0]->out_formats); > -ff_formats_ref(outfmts, &avctx->outputs[0]->in_formats); > +if ((err = ff_formats_ref(infmts, &avctx->inputs[0]->out_formats)) < 0 > || > +(err = ff_formats_ref(outfmts, &avctx->outputs[0]->in_formats)) < 0) > +return err; according to coverity this introduces a memleak (1362184) ill send you an invite so you can take a look [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Add Pro-MPEG CoP #3-R2 FEC protocol
> also why are some called _size and some _len ?
I will use length_recovery as it's named exactly like that in the code of
practice and use better names for the rest.
The size check will also take into account UINT16_MAX and not INT_MAX since
the recovery field is only 16-bit.
> -ret = ffurl_write(hd, buf, size);
> +if ((ret = ffurl_write(hd, buf, size)) < 0) {
> +goto end;
> +}
> +
> +if (s->fec_hd && !RTP_PT_IS_RTCP(buf[1])) {
> +if ((ret_fec = ffurl_write(s->fec_hd, buf, size)) < 0) {
> +av_log(h, AV_LOG_ERROR, "Failed to send FEC\n");
> +ret = ret_fec;
> +}
> +}
> +
> +end:
> return ret;
> the goto isnt needed, a direct return can be used
> also is ret_fec needed and cant ret be used directly ?
The reasoning here was that rtp_write() should return the result of the RTP
write operation on success, and not that of the FEC write.
If there's a better way let me know and I will implement it.
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] FTP graceful close data connection to avoid server abort
When writing files to FTP, if the data connection is closed before the
control connection, the server may handle it as an aborted file transfer
and create and leave the file empty.
---
libavformat/ftp.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 0663b47..00747bb 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -220,15 +220,21 @@ static int ftp_send_command(FTPContext *s, const char
*command,
static void ftp_close_data_connection(FTPContext *s)
{
-ffurl_closep(&s->conn_data);
+static const int close_codes[] = {225, 226, 0};
+
+if (s->conn_data) {
+ffurl_closep(&s->conn_data);
+// Need to wait for status, or file transfer might be aborted on
server side
+ftp_status(s, NULL, close_codes);
+}
s->position = 0;
s->state = DISCONNECTED;
}
static void ftp_close_both_connections(FTPContext *s)
{
-ffurl_closep(&s->conn_control);
ftp_close_data_connection(s);
+ffurl_closep(&s->conn_control);
}
static int ftp_auth(FTPContext *s)
@@ -918,8 +924,8 @@ static int ftp_open_dir(URLContext *h)
if (s->conn_data && s->state == LISTING_DIR)
return 0;
fail:
+ftp_close_data_connection(s);
ffurl_closep(&s->conn_control);
-ffurl_closep(&s->conn_data);
return ret;
}
@@ -1039,8 +1045,8 @@ static int ftp_close_dir(URLContext *h)
{
FTPContext *s = h->priv_data;
av_freep(&s->dir_buffer);
+ftp_close_data_connection(s);
ffurl_closep(&s->conn_control);
-ffurl_closep(&s->conn_data);
return 0;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat: Add Pro-MPEG CoP #3-R2 FEC protocol
Pro-MPEG Code of Practice #3 release 2 forward error correction for rtp_mpegts
streams
Signed-off-by: Vlad Tarca
---
Changelog | 1 +
doc/general.texi| 1 +
doc/protocols.texi | 35
libavformat/Makefile| 1 +
libavformat/prompeg.c | 481
libavformat/protocols.c | 1 +
libavformat/rtpproto.c | 61 +-
7 files changed, 578 insertions(+), 3 deletions(-)
create mode 100644 libavformat/prompeg.c
diff --git a/Changelog b/Changelog
index 697b430..34bc23a 100644
--- a/Changelog
+++ b/Changelog
@@ -37,6 +37,7 @@ version :
- Direct Stream Transfer (DST) decoder
- loudnorm filter
- MTAF demuxer and decoder
+- Pro-MPEG CoP #3-R2 FEC protocol
version 3.0:
- Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/doc/general.texi b/doc/general.texi
index 2d3dd0b..80a434a 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1126,6 +1126,7 @@ performance on systems without hardware floating point
support).
@item MMSH @tab X
@item MMST @tab X
@item pipe @tab X
+@item Pro-MPEG FEC @tab X
@item RTMP @tab X
@item RTMPE@tab X
@item RTMPS@tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index a9c9d0c..875fdac 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -513,6 +513,41 @@ time, which is valuable if data transmission is slow.
Note that some formats (typically MOV), require the output protocol to
be seekable, so they will fail with the pipe output protocol.
+@section prompeg
+
+Pro-MPEG Code of Practice #3 Release 2 FEC protocol.
+
+The Pro-MPEG CoP#3 FEC is a 2D parity-check forward error correction mechanism
+for MPEG-2 Transport Streams sent over RTP.
+
+This protocol must be used in conjunction with the @code{rtp_mpegts} muxer and
+the @code{rtp} protocol.
+
+The required syntax is:
+@example
+-f rtp_mpegts -fec prompeg=@var{option}=@var{val}...
rtp://@var{hostname}:@var{port}
+@end example
+
+The destination UDP ports are @code{port + 2} for the column FEC stream
+and @code{port + 4} for the row FEC stream.
+
+This protocol accepts the following options:
+@table @option
+
+@item l=@var{n}
+The number of columns (4-20, LxD <= 100)
+
+@item d=@var{n}
+The number of rows (4-20, LxD <= 100)
+
+@end table
+
+Example usage:
+
+@example
+-f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
+@end example
+
@section rtmp
Real-Time Messaging Protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..90d7587 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ OBJS-$(CONFIG_MD5_PROTOCOL) += md5proto.o
OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
OBJS-$(CONFIG_PIPE_PROTOCOL) += file.o
+OBJS-$(CONFIG_PROMPEG_PROTOCOL) += prompeg.o
OBJS-$(CONFIG_RTMP_PROTOCOL) += rtmpproto.o rtmppkt.o
OBJS-$(CONFIG_RTMPE_PROTOCOL)+= rtmpproto.o rtmppkt.o
OBJS-$(CONFIG_RTMPS_PROTOCOL)+= rtmpproto.o rtmppkt.o
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
new file mode 100644
index 000..cc1baa4
--- /dev/null
+++ b/libavformat/prompeg.c
@@ -0,0 +1,481 @@
+/*
+ * Pro-MPEG Code of Practice #3 Release 2 FEC
+ * Copyright (c) 2016 Mobibase, France (http://www.mobibase.com)
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Pro-MPEG Code of Practice #3 Release 2 FEC protocol
+ * @author Vlad Tarca
+ */
+
+/*
+ * Reminder:
+
+ [RFC 2733] FEC Packet Structure
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RTP Header|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FEC Header|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FEC Payload |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ [RFC 3550] RTP header
+
+0 1
Re: [FFmpeg-devel] [PATCH] avformat: Copy properties from internal context
On Mon, May 30, 2016 at 02:42:25PM +0200, Hendrik Leppkes wrote: > On Mon, May 30, 2016 at 2:25 PM, Michael Niedermayer > wrote: > > Fixes Ticket5467 "Lossless j2k information no longer shown" > > > > Based on suggestion by Hendrik Leppkes > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/dump.c |3 +++ > > libavformat/utils.c |3 +++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/libavformat/dump.c b/libavformat/dump.c > > index 9eb6146..e016a37 100644 > > --- a/libavformat/dump.c > > +++ b/libavformat/dump.c > > @@ -453,6 +453,9 @@ static void dump_stream_format(AVFormatContext *ic, int > > i, > > return; > > } > > > > +// Fields which are missing from AVCodecParameters need to be taken > > from the AVCodecContext > > +avctx->properties = st->codec->properties; > > + > > if (separator) > > av_opt_set(avctx, "dump_separator", separator, 0); > > avcodec_string(buf, sizeof(buf), avctx, is_output); > > diff --git a/libavformat/utils.c b/libavformat/utils.c > > index 47f5ba0..8f0361a 100644 > > --- a/libavformat/utils.c > > +++ b/libavformat/utils.c > > @@ -3807,6 +3807,9 @@ FF_DISABLE_DEPRECATION_WARNINGS > > } > > FF_ENABLE_DEPRECATION_WARNINGS > > #endif > > +// Fields unavailable in AVCodecParameters > > +st->codec->properties = st->internal->avctx->properties; > > + > > st->codec is deprecated, so it should be in deprecation guards so the > code doesn't break when the version is bumped. changed, also added a comment so it doesnt break without people being aware of when bumping applied thx [...] -- 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] Remove Derek Buitenhuis from MAINTAINERS
On 5/19/2016 2:18 PM, Derek Buitenhuis wrote: > On 5/19/2016 2:12 PM, Michael Niedermayer wrote: >> if derek still wants to leave in 2 weeks then so be it, its his choice >> but i really hope things can be resolved in a way that everyone >> stays and works together and is happy > > I will wait 2 weeks. I've read the "CoC" and IRC meeting. My feelings have not changed. Please push. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On Sun, 29 May 2016 01:32:54 +0200 Michael Niedermayer wrote: > Hi > > It was suggested in the IRC meeting today that i start a vote to > resolve if AVClass & AVOption should be added to AVCodecParameters > This question needs to be awnsered before the next release because > the ABI would be broken if its added afterwards > the lack of any decission blocks the release which is worse than > either decission, otherwise a vote might be silly for such technical > question but eve a bad decission is better than no decission here > > > The disadvanatges are: > 1 more field in the struct > a high level API that some feel is unneeded for AVCodecParameters > it could be confusing to some that there are 2 different ways to > access the fields > people might use it as av_log() context when they intended to use a > different context for it > There are probably more please help fill the list if you know more > > The advanatges are: > More consistent availability of AVOptions and AVClass in public > structs > Makes supporting multiple FFmpeg versions and distros easier and > cleaner for applications. (reduces lists of #if version checks) > Provides default/min/max values, allows basic validity checking within > min/max > Avoids mysterious crashes if an application uses avoption functions > on AVCodecParameters > Introspection > Serialization support that may be usefull for ffserver or an application > replacing ffserver > > > An application that doesnt want to use AVOptions or AVClass can > completey ignore them. > > Please state clearly if you agree to add AVClass&AVOption to > AVCodecParameters or if you disagree about adding it or if you dont > care either way > > The vote will end 1 week from now, simple 50% majority (Yes vs no) > I dont really know who should be eligible for voting, so i suggest > everyone from the vote comittee but iam happy with anything, just > stating somethng ... > I disagree with adding AVClass to AVCodecParameters. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encoder_{h264, h265}: fix bad format warning
From: Matthieu Bouron --- libavcodec/vaapi_encode_h264.c | 2 +- libavcodec/vaapi_encode_h265.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c index 0a99bb1..dc7774b 100644 --- a/libavcodec/vaapi_encode_h264.c +++ b/libavcodec/vaapi_encode_h264.c @@ -769,7 +769,7 @@ static av_cold int vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx priv->fixed_qp_p = 26; priv->fixed_qp_b = 26; -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %d bps.\n", +av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" bps.\n", avctx->bit_rate); return 0; } diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c index 05d3aa4..17cd900 100644 --- a/libavcodec/vaapi_encode_h265.c +++ b/libavcodec/vaapi_encode_h265.c @@ -1196,7 +1196,7 @@ static av_cold int vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx priv->fixed_qp_p = 30; priv->fixed_qp_b = 30; -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %d bps.\n", +av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" bps.\n", avctx->bit_rate); return 0; } -- 2.8.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtpenc: packetizer for VP9 RTP payload format (draft v2)
Hi, On 30.05.2016 17:43, Ronald S. Bultje wrote: Hi, On Mon, May 30, 2016 at 10:41 AM, Thomas Volkert wrote: From: Thomas Volkert --- libavformat/Makefile | 1 + libavformat/rtpenc.c | 14 + libavformat/rtpenc.h | 1 + libavformat/rtpenc_vp9.c | 54 libavformat/sdp.c| 4 5 files changed, 74 insertions(+) create mode 100644 libavformat/rtpenc_vp9.c No opinion on the patch itself yet, but I'm wondering if you've tested this under real conditions with the built-in and libvpx-based decoders? I'm Yes. asking because IIRC the built-in ffvp9 decoder doesn't deal with missing references well at all (it just bails out), so it might be that under real My tests showed this behavior, too. Is it possible to improve the decoder with acceptable effort to overcome this limitation? network conditions, it doesn't work all that well... (That doesn't disqualify the patch in any way, but it would be good to document somewhere for people trying to use this.) I think the sender part is not the right position. Where should we place such a hint? Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtpenc: packetizer for VP9 RTP payload format (draft v2)
Hi, On Thu, Jun 2, 2016 at 12:33 PM, Thomas Volkert wrote: > Hi, > > On 30.05.2016 17:43, Ronald S. Bultje wrote: > >> Hi, >> >> On Mon, May 30, 2016 at 10:41 AM, Thomas Volkert wrote: >> >> From: Thomas Volkert >>> >>> --- >>> libavformat/Makefile | 1 + >>> libavformat/rtpenc.c | 14 + >>> libavformat/rtpenc.h | 1 + >>> libavformat/rtpenc_vp9.c | 54 >>> >>> libavformat/sdp.c| 4 >>> 5 files changed, 74 insertions(+) >>> create mode 100644 libavformat/rtpenc_vp9.c >>> >> No opinion on the patch itself yet, but I'm wondering if you've tested >> this >> under real conditions with the built-in and libvpx-based decoders? I'm >> > Yes. > > asking because IIRC the built-in ffvp9 decoder doesn't deal with missing >> references well at all (it just bails out), so it might be that under real >> > My tests showed this behavior, too. > Is it possible to improve the decoder with acceptable effort to overcome > this limitation? Yes, absolutely, just use a different reference should help about half of it, see h264/mpeg/hevc decoders for more general info on error resilience/recovery. network conditions, it doesn't work all that well... >> >> (That doesn't disqualify the patch in any way, but it would be good to >> document somewhere for people trying to use this.) >> > I think the sender part is not the right position. > Where should we place such a hint? That's a great question, I'm not entirely sure. The point is not so much to serve as a TODO list (in which case it should go into vp9.c), but to document a limitation and suggest a workaround (use libvpx-vp9), so I would suggest to put it in rtpenc_vp9.c anyway, but it does feel iffy. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS
On Thu, 2 Jun 2016 16:03:03 +0100, Derek Buitenhuis wrote: > I've read the "CoC" and IRC meeting. My feelings have not changed. > > Please push. > > - Derek Done. We can revert at any time if you like. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encoder_{h264, h265}: fix bad format warning
On 02/06/16 17:20, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > libavcodec/vaapi_encode_h264.c | 2 +- > libavcodec/vaapi_encode_h265.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c > index 0a99bb1..dc7774b 100644 > --- a/libavcodec/vaapi_encode_h264.c > +++ b/libavcodec/vaapi_encode_h264.c > @@ -769,7 +769,7 @@ static av_cold int > vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx > priv->fixed_qp_p = 26; > priv->fixed_qp_b = 26; > > -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %d bps.\n", > +av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" bps.\n", > avctx->bit_rate); > return 0; > } > diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c > index 05d3aa4..17cd900 100644 > --- a/libavcodec/vaapi_encode_h265.c > +++ b/libavcodec/vaapi_encode_h265.c > @@ -1196,7 +1196,7 @@ static av_cold int > vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx > priv->fixed_qp_p = 30; > priv->fixed_qp_b = 30; > > -av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %d bps.\n", > +av_log(avctx, AV_LOG_DEBUG, "Using constant-bitrate = %"PRId64" bps.\n", > avctx->bit_rate); > return 0; > } > LGTM to fix the warning. I didn't realise that bit_rate has a different type in the two tines - I think a bit more is needed here to just reject higher numbers because all of the relevant fields in va.h structures are 32-bit anyway... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31
---
... something like this.
libavcodec/vaapi_encode_h264.c | 6 ++
libavcodec/vaapi_encode_h265.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 0a99bb1..019ed1f 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -731,6 +731,12 @@ static av_cold int
vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
int hrd_buffer_size;
int hrd_initial_buffer_fullness;
+if (avctx->bit_rate >= 1u << 31) {
+av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
+ "higher is not supported.\n");
+return AVERROR(EINVAL);
+}
+
if (avctx->rc_buffer_size)
hrd_buffer_size = avctx->rc_buffer_size;
else
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 05d3aa4..060c7b7 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1158,6 +1158,12 @@ static av_cold int
vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx
int hrd_buffer_size;
int hrd_initial_buffer_fullness;
+if (avctx->bit_rate >= 1u << 31) {
+av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
+ "higher is not supported.\n");
+return AVERROR(EINVAL);
+}
+
if (avctx->rc_buffer_size)
hrd_buffer_size = avctx->rc_buffer_size;
else
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31
On Thu, Jun 02, 2016 at 07:13:39PM +0100, Mark Thompson wrote:
> ---
> ... something like this.
>
> libavcodec/vaapi_encode_h264.c | 6 ++
> libavcodec/vaapi_encode_h265.c | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 0a99bb1..019ed1f 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -731,6 +731,12 @@ static av_cold int
> vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
> int hrd_buffer_size;
> int hrd_initial_buffer_fullness;
>
> +if (avctx->bit_rate >= 1u << 31) {
Wouldn't INT32_MAX be more aproriate ?
> +av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
> + "higher is not supported.\n");
> +return AVERROR(EINVAL);
> +}
> +
> if (avctx->rc_buffer_size)
> hrd_buffer_size = avctx->rc_buffer_size;
> else
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 05d3aa4..060c7b7 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -1158,6 +1158,12 @@ static av_cold int
> vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx
> int hrd_buffer_size;
> int hrd_initial_buffer_fullness;
>
> +if (avctx->bit_rate >= 1u << 31) {a
Same comment as above.
> +av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
> + "higher is not supported.\n");
> +return AVERROR(EINVAL);
> +}
> +
> if (avctx->rc_buffer_size)
> hrd_buffer_size = avctx->rc_buffer_size;
> else
> --
> 2.8.1
>
> ___
> 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] vaapi_encode_h26[45]: Reject bitrate targets higher than 2^31
On 02/06/16 22:00, Matthieu Bouron wrote:
> On Thu, Jun 02, 2016 at 07:13:39PM +0100, Mark Thompson wrote:
>> ---
>> ... something like this.
>>
>> libavcodec/vaapi_encode_h264.c | 6 ++
>> libavcodec/vaapi_encode_h265.c | 6 ++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index 0a99bb1..019ed1f 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -731,6 +731,12 @@ static av_cold int
>> vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
>> int hrd_buffer_size;
>> int hrd_initial_buffer_fullness;
>>
>> +if (avctx->bit_rate >= 1u << 31) {
>
> Wouldn't INT32_MAX be more aproriate ?
Hmm. No preference - I went for 1u << 31 to match the 2^31 in the error
message, but maybe INT32_MAX makes the code constraint slightly clearer.
>> +av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
>> + "higher is not supported.\n");
>> +return AVERROR(EINVAL);
>> +}
>> +
>> if (avctx->rc_buffer_size)
>> hrd_buffer_size = avctx->rc_buffer_size;
>> else
>> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
>> index 05d3aa4..060c7b7 100644
>> --- a/libavcodec/vaapi_encode_h265.c
>> +++ b/libavcodec/vaapi_encode_h265.c
>> @@ -1158,6 +1158,12 @@ static av_cold int
>> vaapi_encode_h265_init_constant_bitrate(AVCodecContext *avctx
>> int hrd_buffer_size;
>> int hrd_initial_buffer_fullness;
>>
>> +if (avctx->bit_rate >= 1u << 31) {a
>
> Same comment as above.
Whichever answer you prefer, they should be the same.
>> +av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
>> + "higher is not supported.\n");
>> +return AVERROR(EINVAL);
>> +}
>> +
>> if (avctx->rc_buffer_size)
>> hrd_buffer_size = avctx->rc_buffer_size;
>> else
>> --
>> 2.8.1
>>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix few compiler warnings
On Thu, Jun 2, 2016 at 5:18 PM Michael Niedermayer wrote: > On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote: > [...] > > > vf_hwdownload.c |6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > 5eb7416fececde847414f37de9a78a4e1cd5e1af > 0004-libavfilter-vf_hwdownload-show-error-when-ff_formats.patch > > From d1d00989a374facba3cdf777d95c61bf385f1332 Mon Sep 17 00:00:00 2001 > > From: dsmudhar > > Date: Sun, 22 May 2016 06:26:36 +0530 > > Subject: [PATCH 4/7] libavfilter/vf_hwdownload: show error when > ff_formats_ref > > fails > > > > --- > > libavfilter/vf_hwdownload.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/libavfilter/vf_hwdownload.c b/libavfilter/vf_hwdownload.c > > index 2dcc9fa..79ea82d 100644 > > --- a/libavfilter/vf_hwdownload.c > > +++ b/libavfilter/vf_hwdownload.c > > @@ -56,8 +56,10 @@ static int hwdownload_query_formats(AVFilterContext > *avctx) > > } > > } > > > > -ff_formats_ref(infmts, &avctx->inputs[0]->out_formats); > > -ff_formats_ref(outfmts, &avctx->outputs[0]->in_formats); > > +if ((err = ff_formats_ref(infmts, &avctx->inputs[0]->out_formats)) > < 0 || > > +(err = ff_formats_ref(outfmts, &avctx->outputs[0]->in_formats)) > < 0) > > +return err; > > according to coverity this introduces a memleak > (1362184) > ill send you an invite so you can take a look > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Those who are too smart to engage in politics are punished by being > governed by those who are dumber. -- Plato > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel this patch should fix it Thanks, DSM_ 0001-vf_hwdownload-fix-memory-leak.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: fix H.264 hwaccel init issue
some problems of https://trac.ffmpeg.org/ticket/5595 are fixed.
can playback 480p.mp4, 720p.mp4, 1080p.mp4 with videotoolbox on osx1095.
test.mp4 may be supported by videdotoolbox hardware decoding because can
playback it with commands on #5272.
ponpon
2016-06-02 11:06 GMT+09:00 Rick Kern :
> Fixes VTDecompressionSessionCreate() error.
>
> Signed-off-by: Rick Kern
> ---
> libavcodec/videotoolbox.c | 59
> ---
> 1 file changed, 45 insertions(+), 14 deletions(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 2f4d531..cadfb23 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -487,23 +487,53 @@ static CFDictionaryRef
> videotoolbox_buffer_attributes_create(int width,
> return buffer_attributes;
> }
>
> -static CMVideoFormatDescriptionRef
> videotoolbox_format_desc_create(CMVideoCodecType codec_type,
> +static CMVideoFormatDescriptionRef
> videotoolbox_format_desc_create(AVCodecContext *avctx,
> +
> CMVideoCodecType codec_type,
>
> CFDictionaryRef decoder_spec,
> int
> width,
> int
> height)
> {
> -CMFormatDescriptionRef cm_fmt_desc;
> -OSStatus status;
> -
> -status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
> -codec_type,
> -width,
> -height,
> -decoder_spec, // Dictionary
> of extension
> -&cm_fmt_desc);
> -
> -if (status)
> -return NULL;
> +CMFormatDescriptionRef cm_fmt_desc = NULL;
> +int status;
> +H264Context *h = codec_type == kCMVideoCodecType_H264 ?
> avctx->priv_data : NULL;
> +
> +if (h && h->sps.data_size && h->pps.data_size) {
> +int ps_count = 2;
> +const uint8_t **ps_data = av_malloc(sizeof(uint8_t*) * ps_count);
> +size_t *ps_sizes = av_malloc(sizeof(size_t) * ps_count);
> +
> +ps_data[0] = h->sps.data;
> +ps_sizes[0] = h->sps.data_size;
> +
> +ps_data[1] = h->pps.data;
> +ps_sizes[1] = h->pps.data_size;
> +
> +status = CMVideoFormatDescriptionCreateFromH264ParameterSets(NULL,
> +
> ps_count,
> +
> ps_data,
> +
> ps_sizes,
> + 4,
> +
> &cm_fmt_desc);
> +av_freep(&ps_sizes);
> +av_freep(&ps_data);
> +
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error creating H.264 format
> description: %d\n", status);
> +return NULL;
> +}
> +} else {
> +status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
> +codec_type,
> +width,
> +height,
> +decoder_spec, //
> Dictionary of extension
> +&cm_fmt_desc);
> +
> +if (status) {
> +av_log(avctx, AV_LOG_ERROR, "Error creating format
> description: %d\n", status);
> +return NULL;
> +}
> +}
>
> return cm_fmt_desc;
> }
> @@ -543,7 +573,8 @@ static int videotoolbox_default_init(AVCodecContext
> *avctx)
>
> decoder_spec =
> videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
>
> -videotoolbox->cm_fmt_desc =
> videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
> +videotoolbox->cm_fmt_desc = videotoolbox_format_desc_create(avctx,
> +
> videotoolbox->cm_codec_type,
>
> decoder_spec,
>
> avctx->width,
>
> avctx->height);
> --
> 2.7.4
>
> ___
> 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] lavc/videotoolbox: fix H.264 hwaccel init issue
>may be
this is a miscue. by right, may not be
sorry
ponpon
2016-06-03 11:47 GMT+09:00 pon pon :
> some problems of https://trac.ffmpeg.org/ticket/5595 are fixed.
> can playback 480p.mp4, 720p.mp4, 1080p.mp4 with videotoolbox on osx1095.
> test.mp4 may be supported by videdotoolbox hardware decoding because can
> playback it with commands on #5272.
>
> ponpon
>
> 2016-06-02 11:06 GMT+09:00 Rick Kern :
>
>> Fixes VTDecompressionSessionCreate() error.
>>
>> Signed-off-by: Rick Kern
>> ---
>> libavcodec/videotoolbox.c | 59
>> ---
>> 1 file changed, 45 insertions(+), 14 deletions(-)
>>
>> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
>> index 2f4d531..cadfb23 100644
>> --- a/libavcodec/videotoolbox.c
>> +++ b/libavcodec/videotoolbox.c
>> @@ -487,23 +487,53 @@ static CFDictionaryRef
>> videotoolbox_buffer_attributes_create(int width,
>> return buffer_attributes;
>> }
>>
>> -static CMVideoFormatDescriptionRef
>> videotoolbox_format_desc_create(CMVideoCodecType codec_type,
>> +static CMVideoFormatDescriptionRef
>> videotoolbox_format_desc_create(AVCodecContext *avctx,
>> +
>> CMVideoCodecType codec_type,
>>
>> CFDictionaryRef decoder_spec,
>> int
>> width,
>> int
>> height)
>> {
>> -CMFormatDescriptionRef cm_fmt_desc;
>> -OSStatus status;
>> -
>> -status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
>> -codec_type,
>> -width,
>> -height,
>> -decoder_spec, // Dictionary
>> of extension
>> -&cm_fmt_desc);
>> -
>> -if (status)
>> -return NULL;
>> +CMFormatDescriptionRef cm_fmt_desc = NULL;
>> +int status;
>> +H264Context *h = codec_type == kCMVideoCodecType_H264 ?
>> avctx->priv_data : NULL;
>> +
>> +if (h && h->sps.data_size && h->pps.data_size) {
>> +int ps_count = 2;
>> +const uint8_t **ps_data = av_malloc(sizeof(uint8_t*) * ps_count);
>> +size_t *ps_sizes = av_malloc(sizeof(size_t) * ps_count);
>> +
>> +ps_data[0] = h->sps.data;
>> +ps_sizes[0] = h->sps.data_size;
>> +
>> +ps_data[1] = h->pps.data;
>> +ps_sizes[1] = h->pps.data_size;
>> +
>> +status =
>> CMVideoFormatDescriptionCreateFromH264ParameterSets(NULL,
>> +
>> ps_count,
>> +
>> ps_data,
>> +
>> ps_sizes,
>> + 4,
>> +
>> &cm_fmt_desc);
>> +av_freep(&ps_sizes);
>> +av_freep(&ps_data);
>> +
>> +if (status) {
>> +av_log(avctx, AV_LOG_ERROR, "Error creating H.264 format
>> description: %d\n", status);
>> +return NULL;
>> +}
>> +} else {
>> +status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
>> +codec_type,
>> +width,
>> +height,
>> +decoder_spec, //
>> Dictionary of extension
>> +&cm_fmt_desc);
>> +
>> +if (status) {
>> +av_log(avctx, AV_LOG_ERROR, "Error creating format
>> description: %d\n", status);
>> +return NULL;
>> +}
>> +}
>>
>> return cm_fmt_desc;
>> }
>> @@ -543,7 +573,8 @@ static int videotoolbox_default_init(AVCodecContext
>> *avctx)
>>
>> decoder_spec =
>> videotoolbox_decoder_config_create(videotoolbox->cm_codec_type, avctx);
>>
>> -videotoolbox->cm_fmt_desc =
>> videotoolbox_format_desc_create(videotoolbox->cm_codec_type,
>> +videotoolbox->cm_fmt_desc = videotoolbox_format_desc_create(avctx,
>> +
>> videotoolbox->cm_codec_type,
>>
>> decoder_spec,
>>
>> avctx->width,
>>
>> avctx->height);
>> --
>> 2.7.4
>>
>> ___
>> 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
