Re: [FFmpeg-devel] [PATCH 1/2] lavc/mediacodecdec_h264: switch to new BSF API
On Fri, May 27, 2016 at 10:13:20AM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libavcodec/mediacodecdec_h264.c | 61
> +
> 1 file changed, 37 insertions(+), 24 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
> index 2d1d525..7f764e9 100644
> --- a/libavcodec/mediacodecdec_h264.c
> +++ b/libavcodec/mediacodecdec_h264.c
> @@ -23,6 +23,7 @@
> #include
> #include
>
> +#include "libavutil/avassert.h"
> #include "libavutil/common.h"
> #include "libavutil/fifo.h"
> #include "libavutil/opt.h"
> @@ -41,13 +42,11 @@ typedef struct MediaCodecH264DecContext {
>
> MediaCodecDecContext ctx;
>
> -AVBitStreamFilterContext *bsf;
> +AVBSFContext *bsf;
>
> AVFifoBuffer *fifo;
>
> -AVPacket input_ref;
> AVPacket filtered_pkt;
> -uint8_t *filtered_data;
>
> } MediaCodecH264DecContext;
>
> @@ -156,8 +155,9 @@ static av_cold int mediacodec_decode_close(AVCodecContext
> *avctx)
> ff_mediacodec_dec_close(avctx, &s->ctx);
>
> av_fifo_free(s->fifo);
> +av_bsf_free(&s->bsf);
>
> -av_bitstream_filter_close(s->bsf);
> +av_packet_unref(&s->filtered_pkt);
>
> return 0;
> }
> @@ -211,12 +211,23 @@ static av_cold int
> mediacodec_decode_init(AVCodecContext *avctx)
> goto done;
> }
>
> -s->bsf = av_bitstream_filter_init("h264_mp4toannexb");
> -if (!s->bsf) {
> -ret = AVERROR(ENOMEM);
> +const AVBitStreamFilter *bsf = av_bsf_get_by_name("h264_mp4toannexb");
> +if(!bsf) {
> +ret = AVERROR_BSF_NOT_FOUND;
> goto done;
> }
>
> +if ((ret = av_bsf_alloc(bsf, &s->bsf))) {
> +goto done;
> +}
> +
> +if (((ret = avcodec_parameters_from_context(s->bsf->par_in, avctx)) < 0)
> ||
> +((ret = av_bsf_init(s->bsf)) < 0)) {
> + goto done;
> +}
> +
> +av_init_packet(&s->filtered_pkt);
> +
> done:
> if (format) {
> ff_AMediaFormat_delete(format);
> @@ -265,7 +276,9 @@ static int mediacodec_decode_frame(AVCodecContext *avctx,
> void *data,
> while (!*got_frame) {
> /* prepare the input data -- convert to Annex B if needed */
> if (s->filtered_pkt.size <= 0) {
> -int size;
> +AVPacket input_pkt = { 0 };
> +
> +av_packet_unref(&s->filtered_pkt);
>
> /* no more data */
> if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
> @@ -273,22 +286,24 @@ static int mediacodec_decode_frame(AVCodecContext
> *avctx, void *data,
> ff_mediacodec_dec_decode(avctx, &s->ctx, frame,
> got_frame, avpkt);
> }
>
> -if (s->filtered_data != s->input_ref.data)
> -av_freep(&s->filtered_data);
> -s->filtered_data = NULL;
> -av_packet_unref(&s->input_ref);
> +av_fifo_generic_read(s->fifo, &input_pkt, sizeof(input_pkt),
> NULL);
> +
> +ret = av_bsf_send_packet(s->bsf, &input_pkt);
> +if (ret < 0) {
> +return ret;
> +}
> +
> +ret = av_bsf_receive_packet(s->bsf, &s->filtered_pkt);
> +if (ret == AVERROR(EAGAIN)) {
> +goto done;
> +}
> +
> +/* h264_mp4toannexb is used here and does not require flushing */
> +av_assert0(ret != AVERROR_EOF);
>
> -av_fifo_generic_read(s->fifo, &s->input_ref,
> sizeof(s->input_ref), NULL);
> -ret = av_bitstream_filter_filter(s->bsf, avctx, NULL,
> - &s->filtered_data, &size,
> - s->input_ref.data,
> s->input_ref.size, 0);
> if (ret < 0) {
> -s->filtered_data = s->input_ref.data;
> -size = s->input_ref.size;
> +return ret;
> }
> -s->filtered_pkt = s->input_ref;
> -s->filtered_pkt.data = s->filtered_data;
> -s->filtered_pkt.size = size;
> }
>
> ret = mediacodec_process_data(avctx, frame, got_frame,
> &s->filtered_pkt);
> @@ -298,7 +313,7 @@ static int mediacodec_decode_frame(AVCodecContext *avctx,
> void *data,
> s->filtered_pkt.size -= ret;
> s->filtered_pkt.data += ret;
> }
> -
> +done:
> return avpkt->size;
> }
>
> @@ -313,8 +328,6 @@ static void mediacodec_decode_flush(AVCodecContext *avctx)
> }
> av_fifo_reset(s->fifo);
>
> -av_packet_unref(&s->input_ref);
> -
> av_init_packet(&s->filtered_pkt);
> s->filtered_pkt.data = NULL;
> s->filtered_pkt.size = 0;
The above chunk has been updated locally with:
-av_init_packet(&s->filtered_pkt);
-s->filtered_pkt.data = NULL;
-s->filtered_pkt.size = 0;
+av_packet_unref(&s->filtered_pkt);
Matthieu
___
ffmpeg-devel ma
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On Sun, May 29, 2016 at 01:32:54AM +0200, Michael Niedermayer wrote: [...] > 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 I'm OK with adding an AVClass* on top of AVCodecParameters. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Clément Bœsch pkh.me> writes: > I'm OK with adding an AVClass* on top of AVCodecParameters. +1 Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On 29 May 2016 at 00:32, 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 ... > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If a bugfix only changes things apparently unrelated to the bug with no > further explanation, that is a good sign that the bugfix is wrong. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > I am NOT okay with adding AVClass or AVOption to AVCodecParameters. Keeping things modular and simple is better in this case rather than providing 2 ways to access struct fields. Applications should use the normal way to access fields in the struct rather than go through AVOption, so the argument about a mysterious crash is void. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/movenc: remove useless if and reindent
Signed-off-by: Marton Balint
---
libavformat/movenc.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index fbb659d..f9dffc2 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5734,11 +5734,9 @@ static int mov_write_trailer(AVFormatContext *s)
av_log(s, AV_LOG_INFO, "Starting second pass: moving the moov atom
to the beginning of the file\n");
if ((res = shift_data(s)) < 0)
goto error;
-if (res == 0) {
-avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
-if ((res = mov_write_moov_tag(pb, mov, s)) < 0)
-goto error;
-}
+avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
+if ((res = mov_write_moov_tag(pb, mov, s)) < 0)
+goto error;
} else if (mov->reserved_moov_size > 0) {
int64_t size;
if ((res = mov_write_moov_tag(pb, mov, s)) < 0)
@@ -5763,16 +5761,15 @@ static int mov_write_trailer(AVFormatContext *s)
for (i = 0; i < mov->nb_streams; i++)
mov->tracks[i].data_offset = 0;
if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX) {
+int64_t end;
av_log(s, AV_LOG_INFO, "Starting second pass: inserting sidx
atoms\n");
if ((res = shift_data(s)) < 0)
goto error;
-if (res == 0) {
-int64_t end = avio_tell(pb);
-avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
-mov_write_sidx_tags(pb, mov, -1, 0);
-avio_seek(pb, end, SEEK_SET);
-mov_write_mfra_tag(pb, mov);
-}
+end = avio_tell(pb);
+avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
+mov_write_sidx_tags(pb, mov, -1, 0);
+avio_seek(pb, end, SEEK_SET);
+mov_write_mfra_tag(pb, mov);
} else {
mov_write_mfra_tag(pb, mov);
}
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/movenc: propagate shift_data errors properly
The second one is not explicitly needed, as res is not reset, but it is there
for consistency.
Signed-off-by: Marton Balint
---
libavformat/movenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 49cd1bd..fbb659d 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5732,7 +5732,8 @@ static int mov_write_trailer(AVFormatContext *s)
if (mov->flags & FF_MOV_FLAG_FASTSTART) {
av_log(s, AV_LOG_INFO, "Starting second pass: moving the moov atom
to the beginning of the file\n");
-res = shift_data(s);
+if ((res = shift_data(s)) < 0)
+goto error;
if (res == 0) {
avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
if ((res = mov_write_moov_tag(pb, mov, s)) < 0)
@@ -5763,7 +5764,8 @@ static int mov_write_trailer(AVFormatContext *s)
mov->tracks[i].data_offset = 0;
if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX) {
av_log(s, AV_LOG_INFO, "Starting second pass: inserting sidx
atoms\n");
-res = shift_data(s);
+if ((res = shift_data(s)) < 0)
+goto error;
if (res == 0) {
int64_t end = avio_tell(pb);
avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On Sun, May 29, 2016 at 1:32 AM, 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 do not think they are useful or needed, so a "no" from me. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi, On Sat, May 28, 2016 at 7:32 PM, Michael Niedermayer wrote: > 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 *decision :) I would prefer if we don't add AVClass to AVCodecParameters. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: propagate shift_data errors properly
Marton Balint passwd.hu> writes: > -res = shift_data(s); > +if ((res = shift_data(s)) < 0) It's not my code but "if (res < 0)" is imo easier to read, less error-prone and makes the patch smaller... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On Sat, 28 May 2016, Stefano Sabatini wrote: On date Saturday 2016-05-28 18:57:00 +0200, Paul B Mahol encoded: On 5/28/16, Clement Boesch wrote: > On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote: >> Hi, >> >> I want to propose to have an FFmpeg IRC meeting on >> the Saturday of the next week, Saturday May 28, >> UTC 17. >> > > So I suppose this happens in about half an hour. Can you remind us the > IRC channel? It could be #ffmpeg-devel or any other channel. The FFmpeg IRC meeting will start soon (17:15 UTC) on the #ffmpeg-meeting2016 channel. Will somebody submit the log to the trac wiki? Thanks, Marton ___ 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, 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 am in favor of adding AVClass. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Am 29.05.16 um 01:32 schrieb Michael Niedermayer: > 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 I'm in favor of adding them. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder
Hi,
patch attached.
From f9f538cc6253f892bb04b7c9e46189194b6f9be4 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 22 May 2016 15:18:30 +0200
Subject: [PATCH] avocdec: add MagicYUV decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/magicyuv.c | 437
libavformat/riff.c | 1 +
6 files changed, 448 insertions(+)
create mode 100644 libavcodec/magicyuv.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 224ccf7..733a82d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -348,6 +348,7 @@ OBJS-$(CONFIG_LOCO_DECODER)+= loco.o
OBJS-$(CONFIG_M101_DECODER)+= m101.o
OBJS-$(CONFIG_MACE3_DECODER) += mace.o
OBJS-$(CONFIG_MACE6_DECODER) += mace.o
+OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
OBJS-$(CONFIG_METASOUND_DECODER) += metasound.o metasound_data.o \
twinvq.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6d0a7e7..7aa54ee 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -219,6 +219,7 @@ void avcodec_register_all(void)
REGISTER_ENCODER(LJPEG, ljpeg);
REGISTER_DECODER(LOCO, loco);
REGISTER_DECODER(M101, m101);
+REGISTER_DECODER(MAGICYUV, magicyuv);
REGISTER_DECODER(MDEC, mdec);
REGISTER_DECODER(MIMIC, mimic);
REGISTER_ENCDEC (MJPEG, mjpeg);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 00d0ef8..339a1b2 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -406,6 +406,7 @@ enum AVCodecID {
AV_CODEC_ID_CFHD,
AV_CODEC_ID_TRUEMOTION2RT,
AV_CODEC_ID_M101,
+AV_CODEC_ID_MAGICYUV,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 077b2d4..5fd946e 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1542,6 +1542,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("Duck TrueMotion 2.0 Real Time"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_MAGICYUV,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "magicyuv",
+.long_name = NULL_IF_CONFIG_SMALL("MagicYUV Lossless Video"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
new file mode 100644
index 000..2a161d9
--- /dev/null
+++ b/libavcodec/magicyuv.c
@@ -0,0 +1,437 @@
+/*
+ * MagicYUV decoder
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+#include
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "get_bits.h"
+#include "huffyuvdsp.h"
+#include "internal.h"
+#include "thread.h"
+
+typedef struct Slice {
+uint32_t start;
+uint32_t size;
+} Slice;
+
+typedef enum Prediction {
+LEFT = 1,
+GRADIENT,
+MEDIAN,
+} Prediction;
+
+typedef struct MagicYUVContext {
+AVFrame*p;
+int slice_height;
+int nb_slices;
+int planes;
+uint8_t *buf;
+int hshift[4];
+int vshift[4];
+Slice *slices[4];
+int slices_size[4];
+uint8_t freq[4][256];
+VLC vlc[4];
+HuffYUVDSPContext hdsp;
+} MagicYUVContext;
+
+static av_cold int decode_init(AVCodecContext *avctx)
+{
+MagicYUVContext *s = avctx->priv_data;
+ff_huffyuvdsp_init(&s->hdsp);
+return 0;
+}
+
+typedef struct HuffEntry {
+uint8_t sym;
+uint8_t len;
+uint32_t code;
+} HuffEntry;
+
+static int ff_magy_huff_cmp_len(const void *a, const void *b)
+{
+const HuffEntry *aa = a, *bb = b;
+return
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi, On Sun, May 29, 2016 at 3:25 PM, Thilo Borgmann wrote: > Am 29.05.16 um 01:32 schrieb Michael Niedermayer: > > 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 > > I'm in favor of adding them. And you are not in the list either [1]... Ronald [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi, On Sun, May 29, 2016 at 3:13 PM, Marton Balint wrote: > > > On Sun, 29 May 2016, 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 am in favor of adding AVClass. You're not in the list [1]? Ronald [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On 5/29/2016 5:45 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, May 29, 2016 at 3:13 PM, Marton Balint wrote: > >> >> >> On Sun, 29 May 2016, 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 am in favor of adding AVClass. > > > You're not in the list [1]? > > Ronald > > [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html At least one the person in the list has apparently left the project, so maybe we could suggest adding recurrent contributors like Marton and Thilo. ___ 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, James Almer wrote: On 5/29/2016 5:45 PM, Ronald S. Bultje wrote: Hi, On Sun, May 29, 2016 at 3:13 PM, Marton Balint wrote: On Sun, 29 May 2016, 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 am in favor of adding AVClass. You're not in the list [1]? Ronald [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html At least one the person in the list has apparently left the project, so maybe we could suggest adding recurrent contributors like Marton and Thilo. I beieve there was an expansion when I got already included: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi, On May 29, 2016 5:01 PM, "Marton Balint" wrote: > > > > On Sun, 29 May 2016, James Almer wrote: > >> On 5/29/2016 5:45 PM, Ronald S. Bultje wrote: >>> >>> Hi, >>> >>> On Sun, May 29, 2016 at 3:13 PM, Marton Balint wrote: >>> On Sun, 29 May 2016, 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 am in favor of adding AVClass. >>> >>> >>> >>> You're not in the list [1]? >>> >>> Ronald >>> >>> [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html >> >> >> At least one the person in the list has apparently left the project, so maybe >> we could suggest adding recurrent contributors like Marton and Thilo. > > > I beieve there was an expansion when I got already included: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183803.html You're right, I was looking at an older email, sorry about that. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi, On May 29, 2016 4:59 PM, "James Almer" wrote: > > On 5/29/2016 5:45 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Sun, May 29, 2016 at 3:13 PM, Marton Balint wrote: > > > >> > >> > >> On Sun, 29 May 2016, 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 am in favor of adding AVClass. > > > > > > You're not in the list [1]? > > > > Ronald > > > > [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html > > At least one the person in the list has apparently left the project, so maybe > we could suggest adding recurrent contributors like Marton and Thilo. Probably, yes. Is it just Thilo or are others missing also? What were the criteria again? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
On 5/29/2016 6:30 PM, Ronald S. Bultje wrote: > Hi, > > On May 29, 2016 4:59 PM, "James Almer" wrote: >> >> On 5/29/2016 5:45 PM, Ronald S. Bultje wrote: >>> Hi, >>> >>> On Sun, May 29, 2016 at 3:13 PM, Marton Balint wrote: >>> On Sun, 29 May 2016, 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 am in favor of adding AVClass. >>> >>> >>> You're not in the list [1]? >>> >>> Ronald >>> >>> [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html >> >> At least one the person in the list has apparently left the project, so > maybe >> we could suggest adding recurrent contributors like Marton and Thilo. > > Probably, yes. Is it just Thilo or are others missing also? What were the > criteria again? > > Ronald The original criteria was i think 50 commits in the past year or so. This was back in mid 2015. After that a couple people were added based on suggestions since many long time contributors and maintainers didn't meet that criteria. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] IRC meeting
On Sun, May 29, 2016 at 09:11:38PM +0200, Marton Balint wrote: > > > On Sat, 28 May 2016, Stefano Sabatini wrote: > > >On date Saturday 2016-05-28 18:57:00 +0200, Paul B Mahol encoded: > >>On 5/28/16, Clement Boesch wrote: > >>> On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote: > Hi, > > I want to propose to have an FFmpeg IRC meeting on > the Saturday of the next week, Saturday May 28, > UTC 17. > > >>> > >>> So I suppose this happens in about half an hour. Can you remind us the > >>> IRC channel? > >> > > > >>It could be #ffmpeg-devel or any other channel. > > > >The FFmpeg IRC meeting will start soon (17:15 UTC) on the > >#ffmpeg-meeting2016 channel. > > Will somebody submit the log to the trac wiki? https://trac.ffmpeg.org/wiki/FFmeeting/2016-05 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/movenc: remove unnecessary null check
Fixes CID1361955 --- libavformat/movenc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 49cd1bd..3a633a6 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -1894,9 +1894,7 @@ static int mov_write_tmcd_tag(AVIOContext *pb, MOVTrack *track) avio_w8(pb, nb_frames); /* Number of frames */ avio_w8(pb, 0); /* Reserved */ -if (track->st) -t = av_dict_get(track->st->metadata, "reel_name", NULL, 0); - +t = av_dict_get(track->st->metadata, "reel_name", NULL, 0); if (t && utf8len(t->value) && track->mode != MODE_MP4) mov_write_source_reference_tag(pb, track, t->value); else -- 2.7.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/movenc: remove unnecessary null check
On Sun, May 29, 2016 at 05:17:32PM -0700, Mark Reid wrote: > Fixes CID1361955 > --- > libavformat/movenc.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi, > [...] >> >> 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 am in favor of adding AVClass. You're not in the list [1]? Ronald [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html >>> >>> At least one the person in the list has apparently left the project, so >> maybe >>> we could suggest adding recurrent contributors like Marton and Thilo. >> >> Probably, yes. Is it just Thilo or are others missing also? What were the >> criteria again? >> >> Ronald > > The original criteria was i think 50 commits in the past year or so. This > was back in mid 2015. After that a couple people were added based on > suggestions since many long time contributors and maintainers didn't meet > that criteria. Thanks for pointing out, Ronald. Sorry, I've just missed the committee part... I'd like not to be added to the committee while a vote is ongoing. Please consider my vote to be void. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AVClass & AVOption [VOTE]
Hi Thilo, On Sun, May 29, 2016 at 8:59 PM, Thilo Borgmann wrote: > Hi, > > > [...] > >> > >> 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 am in favor of adding AVClass. > > > You're not in the list [1]? > > Ronald > > [1] > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html > >>> > >>> At least one the person in the list has apparently left the project, so > >> maybe > >>> we could suggest adding recurrent contributors like Marton and Thilo. > >> > >> Probably, yes. Is it just Thilo or are others missing also? What were > the > >> criteria again? > >> > >> Ronald > > > > The original criteria was i think 50 commits in the past year or so. This > > was back in mid 2015. After that a couple people were added based on > > suggestions since many long time contributors and maintainers didn't meet > > that criteria. > > Thanks for pointing out, Ronald. Sorry, I've just missed the committee > part... > > I'd like not to be added to the committee while a vote is ongoing. > Please consider my vote to be void. (If you want,) I still think you could be added for e.g. future votes? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Add a G.729 muxer
On Wed, May 18, 2016 at 07:55:59PM +0200, Michael Niedermayer wrote: > On Wed, May 18, 2016 at 01:32:13PM +, Carl Eugen Hoyos wrote: > > Derek Buitenhuis gmail.com> writes: > > > > > I would agree, but for some reason Carl feels he is exempt > > > from the FFmpeg developer rules. > > > > I should probably add that this is an interesting comment > > coming from somebody who breaks FFmpeg with nearly every > > commit and not only absolutely refuses to work on fixes but > > even blocks fixes if others want to help him. > > if you wish to call peoples attention to a regression bug so > more people and the author and commiter are aware of it. I think > its best to reply to the commit on ffmpeg-cvslog with a CC to > ffmpeg-devel and a link to the bugreport which contains instructions > how to reproduce. > That way anyone who has time sees it and can help fixing it ping can you list which regressions you spoke about i like to fix them before the release if thats possible [...] -- 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
