Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
2014-08-12 7:56 GMT+02:00 Christophe Gisquet :
> Yeah, you're right. I have no idea how big a slice can be, as that
> seems the extra size check here. How about FF_MIN_BUFFER_SIZE ?
> Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ?
Here's a patch for that, and moving the warn variable to the context.
From b3543b1a9c535299b445cb0e4f86f86cc1b0419f Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 11 Aug 2014 19:37:39 +0200
Subject: [PATCH 1/2] proresenc_kostya: realloc if buffer too small
The buffer allocation may be incorrect (e.g. with an alpha plane),
and currently causes the buffer to be set to NULL by init_put_bits,
later on causing crashing.
So, detect that situation, and if detected, reallocate the buffer
and ask a sample if it happens.
Fixes ticket #2760
---
libavcodec/proresenc_kostya.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index a70ae3c..19eb13d 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -209,6 +209,7 @@ typedef struct ProresContext {
int bits_per_mb;
int force_quant;
int alpha_bits;
+int warn;
char *vendor;
int quant_sel;
@@ -1023,6 +1024,31 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
bytestream_put_byte(&buf, slice_hdr_size << 3);
slice_hdr = buf;
buf += slice_hdr_size - 1;
+if (pkt_size <= buf - orig_buf + FF_MIN_BUFFER_SIZE) {
+uint8_t *start = pkt->data;
+// double the size
+int delta = FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf);
+
+if (!ctx->warn) {
+avpriv_request_sample(avctx,
+ "Packet too small (%i/%i)",
+ pkt_size, delta);
+ctx->warn = 1;
+}
+ctx->frame_size_upper_bound += delta;
+ret = av_grow_packet(pkt, delta);
+if (ret < 0)
+return AVERROR(ENOMEM);
+
+pkt_size += delta;
+// restore pointers
+orig_buf = pkt->data + (orig_buf - start);
+buf = pkt->data + (buf - start);
+picture_size_pos = pkt->data + (picture_size_pos - start);
+slice_sizes = pkt->data + (slice_sizes - start);
+slice_hdr = pkt->data + (slice_hdr - start);
+tmp = pkt->data + (tmp - start);
+}
init_put_bits(&pb, buf, (pkt_size - (buf - orig_buf)) * 8);
ret = encode_slice(avctx, pic, &pb, sizes, x, y, q, mbs_per_slice);
if (ret < 0)
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] proresenc_kostya: properly account for alpha
Hi,
2014-08-12 8:10 GMT+02:00 Christophe Gisquet :
> Yeah, I'll drop it.
Done. Kostya suggested another rounding (the slice bitstreams are
byte-aligned), integrated in this patch.
--
Christophe
From 4e72ed146848b1d7b1804080f43b5d45484e3d94 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 11 Aug 2014 19:43:27 +0200
Subject: [PATCH 2/2] proresenc_kostya: properly account for alpha
The packet buffer allocation considered as dct-coded, while it is
actually run-coded and thus requires a larger buffer.
---
libavcodec/proresenc_kostya.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index 19eb13d..052352a 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -1234,8 +1234,6 @@ static av_cold int encode_init(AVCodecContext *avctx)
ctx->bits_per_mb = ls * 8;
if (ctx->chroma_factor == CFACTOR_Y444)
ctx->bits_per_mb += ls * 4;
-if (ctx->num_planes == 4)
-ctx->bits_per_mb += ls * 4;
}
ctx->frame_size_upper_bound = ctx->pictures_per_frame *
@@ -1244,6 +1242,14 @@ static av_cold int encode_init(AVCodecContext *avctx)
(mps * ctx->bits_per_mb) / 8)
+ 200;
+if (ctx->alpha_bits) {
+ // alpha plane is run-coded and might run over bit budget
+ ctx->frame_size_upper_bound += ctx->pictures_per_frame *
+ctx->slices_per_picture *
+ /* num pixels per slice */ (ctx->mbs_per_slice * 256 *
+ /* bits per pixel */(1 + ctx->alpha_bits + 1) + 7 >> 3);
+}
+
avctx->codec_tag = ctx->profile_info->tag;
av_log(avctx, AV_LOG_DEBUG,
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix: 'make' with mingw32
On Tue, Aug 12, 2014 at 5:48 AM, spanknebel.bor...@t-online.de wrote: > From 48e4da7d6476ac2a62cc462478b8ccf4d0c45361 Mon Sep 17 00:00:00 2001 > From: Youka > Date: Tue, 12 Aug 2014 04:32:02 +0200 > Subject: [PATCH] fix: 'make' with mingw32 > > Older mingw32 compilers (not mingw-64, but tdm [default by IDE C::B]) don't > auto-include pthread headers, so struct timespec & nanosleep are missing for > compilation of libavutil/time.c. > --- > libavutil/time.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavutil/time.c b/libavutil/time.c > index ce4552e..a286fca 100644 > --- a/libavutil/time.c > +++ b/libavutil/time.c > @@ -31,6 +31,10 @@ > #endif > #if HAVE_WINDOWS_H > #include > +#if HAVE_NANOSLEEP > +#include > +#include > +#endif > #endif > > #include "time.h" > -- > 1.8.4.msysgit.0 Since when is nanosleep a pthread function? If its not the usual posix nanosleep, maybe configure should just be fixed to disable it instead? I saw a patch on the libav side that did just that, seems like a better solution to me, since Windows has other sleep functions which get used instead then. This is the patch: https://lists.libav.org/pipermail/libav-devel/2014-August/062211.html - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
On Tue, Aug 12, 2014 at 07:56:36AM +0200, Christophe Gisquet wrote:
> Hi,
>
> 2014-08-12 2:34 GMT+02:00 Michael Niedermayer :
> >> +if (pkt_size <= buf - orig_buf) {
> >
> > this isnt sufficient, there could be 1 byte space left, then the
> > reallocate wouldnt run and encode_slice() would run into the extra
> > padding and fail
>
> Yeah, you're right. I have no idea how big a slice can be, as that
> seems the extra size check here. How about FF_MIN_BUFFER_SIZE ?
> Then the growth would be FFMAX(FF_MIN_BUFFER_SIZE, buf - orig_buf) ?
the "serious undersizing" check already depends on the assumtation
that FF_MIN_BUFFER_SIZE is larger than a slice,
>
> > I think either enough space should be allocated to begin with (like
> > your patch 4) then the reallocation shouldnt be needed
>
> Yes, the intent of that code is to try and catch bugs like the one
> fixed by patch 4. Even if it catches it, we want to fix the original
> bug.
>
> > or the buffer could be allocated to an average size and reallocated
> > when the encoder gets close to its end
> > in which case reallocation also would not need a warning
> > as it would be a normal operation
>
> I have mixed feeling over not warning (and asking a sample). Sure we
> may catch most issues with reallocating, but we can't get a guarantee
what i meant was that in case we knowingly allocate a smaller buffer
than the max then reallocation would not be a "abnormal" condition
and thus would not need a warning.
smaller mallocs might be faster, so if for example a 50% sized
buffer is enough for 99.9% of cases needing realloc only in 0.1%
it might be faster to allocate less than the maximum
but i made no benchmarks so it might be negligible ...
> that the encode can complete (hence patch 1) in case of a serious
> undersizing. Case in point: I had used a growth that was the maximum
> between the quarter of the allocated size and twice the needed size,
> and it crashed without patch 2.
>
> --
> Christophe
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]Slightly extend the -r input option documentation
Timothy Gu gmail.com> writes: > > +This is not the same as the framerate option used > > +for some input formats > > Aside from Lou's comment, you can list some examples > for the "input formats" that have the option. I am slightly against listing examples because that would only add to the confusion imo. Car Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix: 'make' with mingw32
On Tue, Aug 12, 2014 at 10:11:08AM +0200, Hendrik Leppkes wrote: > On Tue, Aug 12, 2014 at 5:48 AM, spanknebel.bor...@t-online.de > wrote: > > From 48e4da7d6476ac2a62cc462478b8ccf4d0c45361 Mon Sep 17 00:00:00 2001 > > From: Youka > > Date: Tue, 12 Aug 2014 04:32:02 +0200 > > Subject: [PATCH] fix: 'make' with mingw32 > > > > Older mingw32 compilers (not mingw-64, but tdm [default by IDE C::B]) don't > > auto-include pthread headers, so struct timespec & nanosleep are missing > > for compilation of libavutil/time.c. > > --- > > libavutil/time.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/libavutil/time.c b/libavutil/time.c > > index ce4552e..a286fca 100644 > > --- a/libavutil/time.c > > +++ b/libavutil/time.c > > @@ -31,6 +31,10 @@ > > #endif > > #if HAVE_WINDOWS_H > > #include > > +#if HAVE_NANOSLEEP > > +#include > > +#include > > +#endif > > #endif > > > > #include "time.h" > > -- > > 1.8.4.msysgit.0 > > Since when is nanosleep a pthread function? > > If its not the usual posix nanosleep, maybe configure should just be > fixed to disable it instead? > I saw a patch on the libav side that did just that, seems like a > better solution to me, since Windows has other sleep functions which > get used instead then. do these other functions provide the same performance on windows ? googling a bit doesnt lead to a conclusive awnser to that but at least one page claimed usleep() to be only millisecond precission and one that its "obsolete" (on windows) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix: 'make' with mingw32
On Tue, Aug 12, 2014 at 10:42 AM, Michael Niedermayer wrote: > On Tue, Aug 12, 2014 at 10:11:08AM +0200, Hendrik Leppkes wrote: >> On Tue, Aug 12, 2014 at 5:48 AM, spanknebel.bor...@t-online.de >> wrote: >> > From 48e4da7d6476ac2a62cc462478b8ccf4d0c45361 Mon Sep 17 00:00:00 2001 >> > From: Youka >> > Date: Tue, 12 Aug 2014 04:32:02 +0200 >> > Subject: [PATCH] fix: 'make' with mingw32 >> > >> > Older mingw32 compilers (not mingw-64, but tdm [default by IDE C::B]) >> > don't auto-include pthread headers, so struct timespec & nanosleep are >> > missing for compilation of libavutil/time.c. >> > --- >> > libavutil/time.c | 4 >> > 1 file changed, 4 insertions(+) >> > >> > diff --git a/libavutil/time.c b/libavutil/time.c >> > index ce4552e..a286fca 100644 >> > --- a/libavutil/time.c >> > +++ b/libavutil/time.c >> > @@ -31,6 +31,10 @@ >> > #endif >> > #if HAVE_WINDOWS_H >> > #include >> > +#if HAVE_NANOSLEEP >> > +#include >> > +#include >> > +#endif >> > #endif >> > >> > #include "time.h" >> > -- >> > 1.8.4.msysgit.0 >> >> Since when is nanosleep a pthread function? >> >> If its not the usual posix nanosleep, maybe configure should just be >> fixed to disable it instead? >> I saw a patch on the libav side that did just that, seems like a > >> better solution to me, since Windows has other sleep functions which >> get used instead then. > > do these other functions provide the same performance on windows ? > googling a bit doesnt lead to a conclusive awnser to that but > at least one page claimed usleep() to be only millisecond precission > and one that its "obsolete" > (on windows) > > This specific nanosleep implementation doesn't have any higher granularity (I checked its code), it falls back to sleeping by milliseconds as well (using Sleep), since Windows just doesn't have any higher timer granularity you can use to sleep properly, unless you spin. Seems to me it makes more sense to just use Sleep directly instead of some weird nanosleep hidden in some mingw pthread header. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fix: 'make' with mingw32
On Tue, Aug 12, 2014 at 11:07:11AM +0200, Hendrik Leppkes wrote: > On Tue, Aug 12, 2014 at 10:42 AM, Michael Niedermayer > wrote: > > On Tue, Aug 12, 2014 at 10:11:08AM +0200, Hendrik Leppkes wrote: > >> On Tue, Aug 12, 2014 at 5:48 AM, spanknebel.bor...@t-online.de > >> wrote: > >> > From 48e4da7d6476ac2a62cc462478b8ccf4d0c45361 Mon Sep 17 00:00:00 2001 > >> > From: Youka > >> > Date: Tue, 12 Aug 2014 04:32:02 +0200 > >> > Subject: [PATCH] fix: 'make' with mingw32 > >> > > >> > Older mingw32 compilers (not mingw-64, but tdm [default by IDE C::B]) > >> > don't auto-include pthread headers, so struct timespec & nanosleep are > >> > missing for compilation of libavutil/time.c. > >> > --- > >> > libavutil/time.c | 4 > >> > 1 file changed, 4 insertions(+) > >> > > >> > diff --git a/libavutil/time.c b/libavutil/time.c > >> > index ce4552e..a286fca 100644 > >> > --- a/libavutil/time.c > >> > +++ b/libavutil/time.c > >> > @@ -31,6 +31,10 @@ > >> > #endif > >> > #if HAVE_WINDOWS_H > >> > #include > >> > +#if HAVE_NANOSLEEP > >> > +#include > >> > +#include > >> > +#endif > >> > #endif > >> > > >> > #include "time.h" > >> > -- > >> > 1.8.4.msysgit.0 > >> > >> Since when is nanosleep a pthread function? > >> > >> If its not the usual posix nanosleep, maybe configure should just be > >> fixed to disable it instead? > >> I saw a patch on the libav side that did just that, seems like a > > > >> better solution to me, since Windows has other sleep functions which > >> get used instead then. > > > > do these other functions provide the same performance on windows ? > > googling a bit doesnt lead to a conclusive awnser to that but > > at least one page claimed usleep() to be only millisecond precission > > and one that its "obsolete" > > (on windows) > > > > > > This specific nanosleep implementation doesn't have any higher > granularity (I checked its code), it falls back to sleeping by > milliseconds as well (using Sleep), since Windows just doesn't have > any higher timer granularity you can use to sleep properly, unless you > spin. > > Seems to me it makes more sense to just use Sleep directly instead of > some weird nanosleep hidden in some mingw pthread header. hmm, ok, applied martins patch in that case, for now Youka, please tell me in case that doesnt fix your issue or you see some disadvantage in that solution Thanks to all [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
Hi, 2014-08-12 10:19 GMT+02:00 Michael Niedermayer : > the "serious undersizing" check already depends on the assumtation > that FF_MIN_BUFFER_SIZE is larger than a slice, Yes, and here lies the issue: if we haven't been able to guess it correctly previously, how likely are we to guess it correctly here? Take 2*max(previous_slice_size) ? > what i meant was that in case we knowingly allocate a smaller buffer > than the max then reallocation would not be a "abnormal" condition > and thus would not need a warning. > smaller mallocs might be faster, so if for example a 50% sized > buffer is enough for 99.9% of cases needing realloc only in 0.1% > it might be faster to allocate less than the maximum > but i made no benchmarks so it might be negligible ... I see your point. But this is prores, an intermediate codec where people don't mind having tens of MB/s and use workstations. I don't think they really mind the extra allocation. Plus the codec already is lenient: ctx->frame_size_upper_bound is usually a rather high bound (except of course when it's buggy like here). -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] Use new av_dict_set_int helper function.
On Mon, Aug 11, 2014 at 09:17:17PM +0200, Reimar Döffinger wrote: > Get rid of the many, slightly differing, implementations > of basically the same thing. > > Signed-off-by: Reimar Döffinger > --- > ffmpeg_opt.c | 12 +++- > ffplay.c | 2 +- > libavfilter/vf_bbox.c| 4 +--- > libavfilter/vf_cropdetect.c | 4 +--- > libavformat/cinedec.c| 4 +--- > libavformat/ftp.c| 10 -- > libavformat/hls.c| 17 - > libavformat/id3v1.c | 4 +--- > libavformat/matroskadec.c| 31 +++ > libavformat/mlvdec.c | 16 > libavformat/mov.c| 14 +++--- > libavformat/mxfdec.c | 8 ++-- > libavformat/smoothstreamingenc.c | 4 +--- > libavformat/vqf.c| 6 +- > 14 files changed, 34 insertions(+), 102 deletions(-) nice simplification LGTM from a quick look [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. 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] proresenc_kostya: realloc if buffer too small
On Tue, Aug 12, 2014 at 11:56:21AM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-12 10:19 GMT+02:00 Michael Niedermayer : > > the "serious undersizing" check already depends on the assumtation > > that FF_MIN_BUFFER_SIZE is larger than a slice, > > Yes, and here lies the issue: if we haven't been able to guess it > correctly previously, how likely are we to guess it correctly here? > Take 2*max(previous_slice_size) ? I think if we allocate based on a upper bound and that turns out not enough, its better to fail and tell the user to report a bug than to try to reallocate. The condition that we run out of space when we intended to allocate enough is not supposed to happen, if it does happen theres something wrong and that should be fixed. This assumes we intend to allocate a amount that is always large enough of course. for the per slice check we could take 2 or 3 times the upper bound of a slice and allocate more by that. And then check that we still have that amount before we start each slice. This should give us a 2-3 times saftey factor for underestimating slice sizes. While only slightly increasing the overall buffer size [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9/x86: fix bug in intra_pred_hd_32x32.
Fixes mismatch in first keyframe in sample ffvp9_fails_where_libvpx.succeeds.webm from ticket 3849. There's still a second mismatch a few frames into the sample. --- libavcodec/x86/vp9intrapred.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/vp9intrapred.asm b/libavcodec/x86/vp9intrapred.asm index 1d8d219..8c0f44e 100644 --- a/libavcodec/x86/vp9intrapred.asm +++ b/libavcodec/x86/vp9intrapred.asm @@ -1374,7 +1374,7 @@ cglobal vp9_ipred_hd_32x32, 4, 6, 8, dst, stride, l, a palignr m6, m1, m0, 1 palignr m1, m0, 2 LOWPASS 1, 6, 0, 7 -pavgb m0, m1 +pavgb m0, m6 SBUTTERFLY bw, 2, 3, 6 SBUTTERFLY bw, 0, 1, 6 -- 1.8.5.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] x86/ttadsp: remove an unnecessary mova
On Sun, Aug 03, 2014 at 11:53:39PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/x86/ttadsp.asm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- 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 3/4] proresenc_kostya: realloc if buffer too small
Hi,
2014-08-12 12:26 GMT+02:00 Michael Niedermayer :
> On Tue, Aug 12, 2014 at 11:56:21AM +0200, Christophe Gisquet wrote:
>> Hi,
>>
>> 2014-08-12 10:19 GMT+02:00 Michael Niedermayer :
>> > the "serious undersizing" check already depends on the assumtation
>> > that FF_MIN_BUFFER_SIZE is larger than a slice,
>>
>> Yes, and here lies the issue: if we haven't been able to guess it
>> correctly previously, how likely are we to guess it correctly here?
>> Take 2*max(previous_slice_size) ?
>
> I think if we allocate based on a upper bound and that turns out
> not enough, its better to fail and tell the user to report a bug
> than to try to reallocate.
Hopefully, the warning should incite the user to report it, but I
agree that trying to handle it may cut us for those reports. As you
like, but if you prefer failing, then maybe something like:
if (pkt_size <= buf - orig_buf + 2*max_slice_size)
return AVERROR_BUFFER_TOO_SMALL;
is enough?
> for the per slice check we could take 2 or 3 times the upper bound
> of a slice and allocate more by that. And then check that we still
> have that amount before we start each slice. This should give us
> a 2-3 times saftey factor for underestimating slice sizes. While only
> slightly increasing the overall buffer size
I chose 2 times in the attached patch. I have no strong opinion on
which solution is best, though reallocating was a specific request I
got.
--
Christophe
From 4934f42ce3b96e269786240f990da47bef2c Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 11 Aug 2014 19:37:39 +0200
Subject: [PATCH 1/2] proresenc_kostya: realloc if buffer too small
The buffer allocation may be incorrect (e.g. with an alpha plane),
and currently causes the buffer to be set to NULL by init_put_bits,
later on causing crashing.
So, detect that situation, and if detected, reallocate the buffer
and ask a sample if it happens.
Fixes ticket #2760
---
libavcodec/proresenc_kostya.c | 37 -
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index a70ae3c..46acbf3 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -209,6 +209,7 @@ typedef struct ProresContext {
int bits_per_mb;
int force_quant;
int alpha_bits;
+int warn;
char *vendor;
int quant_sel;
@@ -938,7 +939,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
int sizes[4] = { 0 };
int slice_hdr_size = 2 + 2 * (ctx->num_planes - 1);
int frame_size, picture_size, slice_size;
-int pkt_size, ret;
+int pkt_size, ret, max_slice_size = 0;
uint8_t frame_flags;
*avctx->coded_frame = *pic;
@@ -1023,6 +1024,38 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
bytestream_put_byte(&buf, slice_hdr_size << 3);
slice_hdr = buf;
buf += slice_hdr_size - 1;
+if (pkt_size <= buf - orig_buf + 2*max_slice_size) {
+uint8_t *start = pkt->data;
+// Recompute new size according to max_slice_size
+// and deduce delta
+int delta = 200 + ctx->pictures_per_frame *
+ctx->slices_per_picture * max_slice_size
+- pkt_size;
+
+delta = FFMAX(delta, 2*max_slice_size);
+ctx->frame_size_upper_bound += delta;
+
+if (!ctx->warn) {
+avpriv_request_sample(avctx,
+ "Packet too small: is %i,"
+ " needs %i (slice: %i). "
+ "Correct allocation",
+ pkt_size, delta);
+ctx->warn = 1;
+}
+ret = av_grow_packet(pkt, delta);
+if (ret < 0)
+return AVERROR(ENOMEM);
+
+pkt_size += delta;
+// restore pointers
+orig_buf = pkt->data + (orig_buf - start);
+buf = pkt->data + (buf - start);
+picture_size_pos = pkt->data + (picture_size_pos - start);
+slice_sizes = pkt->data + (slice_sizes - start);
+slice_hdr = pkt->data + (slice_hdr - start);
+tmp = pkt->data + (tmp - start);
+}
init_put_bits(&pb, buf, (pkt_size - (buf - orig_buf)) * 8);
ret = encode_slice(avctx, pic, &pb, sizes, x, y, q, mbs_per_slice);
if (ret < 0)
@@ -1036,6 +1069,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
}
bytestream_put_be16(&slice_sizes, slice_size);
buf += slice_size - slice_hdr_size;
+
Re: [FFmpeg-devel] [PATCH 3/4] proresenc_kostya: realloc if buffer too small
Hi, 2014-08-12 12:38 GMT+02:00 Christophe Gisquet : > I chose 2 times in the attached patch. I have no strong opinion on > which solution is best, though reallocating was a specific request I > got. Forgot a parameter to the call to avpriv_request_sample, will be added later. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/dca: remove unused header
On Sun, Aug 10, 2014 at 02:24:01AM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/x86/dca.h | 60 > > 1 file changed, 60 deletions(-) > delete mode 100644 libavcodec/x86/dca.h applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfitler/vf_perspective: support slice threading
Signed-off-by: Paul B Mahol
---
libavfilter/vf_perspective.c | 69 +---
1 file changed, 52 insertions(+), 17 deletions(-)
diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
index f433226..c5471b0 100644
--- a/libavfilter/vf_perspective.c
+++ b/libavfilter/vf_perspective.c
@@ -47,10 +47,8 @@ typedef struct PerspectiveContext {
int hsub, vsub;
int nb_planes;
-void (*perspective)(struct PerspectiveContext *s,
-uint8_t *dst, int dst_linesize,
-uint8_t *src, int src_linesize,
-int w, int h, int hsub, int vsub);
+int (*perspective)(AVFilterContext *ctx,
+ void *arg, int job, int nb_jobs);
} PerspectiveContext;
#define OFFSET(x) offsetof(PerspectiveContext, x)
@@ -193,15 +191,34 @@ static int config_input(AVFilterLink *inlink)
return 0;
}
-static void resample_cubic(PerspectiveContext *s,
- uint8_t *dst, int dst_linesize,
- uint8_t *src, int src_linesize,
- int w, int h, int hsub, int vsub)
+typedef struct ThreadData {
+uint8_t *dst;
+int dst_linesize;
+uint8_t *src;
+int src_linesize;
+int w, h;
+int hsub, vsub;
+} ThreadData;
+
+static int resample_cubic(AVFilterContext *ctx, void *arg,
+ int job, int nb_jobs)
{
+PerspectiveContext *s = ctx->priv;
+ThreadData *td = arg;
+uint8_t *dst = td->dst;
+int dst_linesize = td->dst_linesize;
+uint8_t *src = td->src;
+int src_linesize = td->src_linesize;
+int w = td->w;
+int h = td->h;
+int hsub = td->hsub;
+int vsub = td->vsub;
+int start = (h * job) / nb_jobs;
+int end = (h * (job+1)) / nb_jobs;
const int linesize = s->linesize[0];
int x, y;
-for (y = 0; y < h; y++) {
+for (y = start; y < end; y++) {
int sy = y << vsub;
for (x = 0; x < w; x++) {
int u, v, subU, subV, sum, sx;
@@ -259,17 +276,28 @@ static void resample_cubic(PerspectiveContext *s,
dst[x + y * dst_linesize] = sum;
}
}
+return 0;
}
-static void resample_linear(PerspectiveContext *s,
-uint8_t *dst, int dst_linesize,
-uint8_t *src, int src_linesize,
-int w, int h, int hsub, int vsub)
+static int resample_linear(AVFilterContext *ctx, void *arg,
+ int job, int nb_jobs)
{
+PerspectiveContext *s = ctx->priv;
+ThreadData *td = arg;
+uint8_t *dst = td->dst;
+int dst_linesize = td->dst_linesize;
+uint8_t *src = td->src;
+int src_linesize = td->src_linesize;
+int w = td->w;
+int h = td->h;
+int hsub = td->hsub;
+int vsub = td->vsub;
+int start = (h * job) / nb_jobs;
+int end = (h * (job+1)) / nb_jobs;
const int linesize = s->linesize[0];
int x, y;
-for (y = 0; y < h; y++){
+for (y = start; y < end; y++){
int sy = y << vsub;
for (x = 0; x < w; x++){
int u, v, subU, subV, sum, sx, index, subUI, subVI;
@@ -323,6 +351,7 @@ static void resample_linear(PerspectiveContext *s,
dst[x + y * dst_linesize] = sum;
}
}
+return 0;
}
static av_cold int init(AVFilterContext *ctx)
@@ -355,9 +384,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
for (plane = 0; plane < s->nb_planes; plane++) {
int hsub = plane == 1 || plane == 2 ? s->hsub : 0;
int vsub = plane == 1 || plane == 2 ? s->vsub : 0;
-s->perspective(s, out->data[plane], out->linesize[plane],
- frame->data[plane], frame->linesize[plane],
- s->linesize[plane], s->height[plane], hsub, vsub);
+ThreadData td = {.dst = out->data[plane],
+ .dst_linesize = out->linesize[plane],
+ .src = frame->data[plane],
+ .src_linesize = frame->linesize[plane],
+ .w = s->linesize[plane],
+ .h = s->height[plane],
+ .hsub = hsub,
+ .vsub = vsub };
+ctx->internal->execute(ctx, s->perspective, &td, NULL, FFMIN(td.h,
ctx->graph->nb_threads));
}
av_frame_free(&frame);
--
1.7.11.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfitler/vf_perspective: support slice threading
On Tue, Aug 12, 2014 at 11:32:20AM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_perspective.c | 69
> +---
> 1 file changed, 52 insertions(+), 17 deletions(-)
>
> diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
> index f433226..c5471b0 100644
> --- a/libavfilter/vf_perspective.c
> +++ b/libavfilter/vf_perspective.c
> @@ -47,10 +47,8 @@ typedef struct PerspectiveContext {
> int hsub, vsub;
> int nb_planes;
>
> -void (*perspective)(struct PerspectiveContext *s,
> -uint8_t *dst, int dst_linesize,
> -uint8_t *src, int src_linesize,
> -int w, int h, int hsub, int vsub);
> +int (*perspective)(AVFilterContext *ctx,
> + void *arg, int job, int nb_jobs);
> } PerspectiveContext;
>
> #define OFFSET(x) offsetof(PerspectiveContext, x)
> @@ -193,15 +191,34 @@ static int config_input(AVFilterLink *inlink)
> return 0;
> }
>
> -static void resample_cubic(PerspectiveContext *s,
> - uint8_t *dst, int dst_linesize,
> - uint8_t *src, int src_linesize,
> - int w, int h, int hsub, int vsub)
> +typedef struct ThreadData {
> +uint8_t *dst;
> +int dst_linesize;
> +uint8_t *src;
> +int src_linesize;
> +int w, h;
> +int hsub, vsub;
> +} ThreadData;
> +
> +static int resample_cubic(AVFilterContext *ctx, void *arg,
> + int job, int nb_jobs)
> {
> +PerspectiveContext *s = ctx->priv;
> +ThreadData *td = arg;
> +uint8_t *dst = td->dst;
> +int dst_linesize = td->dst_linesize;
> +uint8_t *src = td->src;
> +int src_linesize = td->src_linesize;
> +int w = td->w;
> +int h = td->h;
> +int hsub = td->hsub;
> +int vsub = td->vsub;
> +int start = (h * job) / nb_jobs;
> +int end = (h * (job+1)) / nb_jobs;
> const int linesize = s->linesize[0];
> int x, y;
>
> -for (y = 0; y < h; y++) {
> +for (y = start; y < end; y++) {
> int sy = y << vsub;
> for (x = 0; x < w; x++) {
> int u, v, subU, subV, sum, sx;
> @@ -259,17 +276,28 @@ static void resample_cubic(PerspectiveContext *s,
> dst[x + y * dst_linesize] = sum;
> }
> }
> +return 0;
> }
>
> -static void resample_linear(PerspectiveContext *s,
> -uint8_t *dst, int dst_linesize,
> -uint8_t *src, int src_linesize,
> -int w, int h, int hsub, int vsub)
> +static int resample_linear(AVFilterContext *ctx, void *arg,
> + int job, int nb_jobs)
> {
> +PerspectiveContext *s = ctx->priv;
> +ThreadData *td = arg;
> +uint8_t *dst = td->dst;
> +int dst_linesize = td->dst_linesize;
> +uint8_t *src = td->src;
> +int src_linesize = td->src_linesize;
> +int w = td->w;
> +int h = td->h;
> +int hsub = td->hsub;
> +int vsub = td->vsub;
> +int start = (h * job) / nb_jobs;
> +int end = (h * (job+1)) / nb_jobs;
> const int linesize = s->linesize[0];
> int x, y;
>
> -for (y = 0; y < h; y++){
> +for (y = start; y < end; y++){
> int sy = y << vsub;
> for (x = 0; x < w; x++){
> int u, v, subU, subV, sum, sx, index, subUI, subVI;
> @@ -323,6 +351,7 @@ static void resample_linear(PerspectiveContext *s,
> dst[x + y * dst_linesize] = sum;
> }
> }
> +return 0;
> }
>
> static av_cold int init(AVFilterContext *ctx)
> @@ -355,9 +384,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *frame)
> for (plane = 0; plane < s->nb_planes; plane++) {
> int hsub = plane == 1 || plane == 2 ? s->hsub : 0;
> int vsub = plane == 1 || plane == 2 ? s->vsub : 0;
> -s->perspective(s, out->data[plane], out->linesize[plane],
> - frame->data[plane], frame->linesize[plane],
> - s->linesize[plane], s->height[plane], hsub, vsub);
> +ThreadData td = {.dst = out->data[plane],
> + .dst_linesize = out->linesize[plane],
> + .src = frame->data[plane],
> + .src_linesize = frame->linesize[plane],
> + .w = s->linesize[plane],
> + .h = s->height[plane],
> + .hsub = hsub,
> + .vsub = vsub };
> +ctx->internal->execute(ctx, s->perspective, &td, NULL, FFMIN(td.h,
> ctx->graph->nb_threads));
> }
>
> av_frame_free(&frame);
Missing the entry .flags, the threading probably has no effect.
[...]
--
Clément B.
pgpJG2ABKmwUC.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
Re: [FFmpeg-devel] [PATCH] avfitler/vf_perspective: support slice threading
On 8/12/14, Clement Boesch wrote:
> On Tue, Aug 12, 2014 at 11:32:20AM +, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavfilter/vf_perspective.c | 69
>> +---
>> 1 file changed, 52 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
>> index f433226..c5471b0 100644
>> --- a/libavfilter/vf_perspective.c
>> +++ b/libavfilter/vf_perspective.c
>> @@ -47,10 +47,8 @@ typedef struct PerspectiveContext {
>> int hsub, vsub;
>> int nb_planes;
>>
>> -void (*perspective)(struct PerspectiveContext *s,
>> -uint8_t *dst, int dst_linesize,
>> -uint8_t *src, int src_linesize,
>> -int w, int h, int hsub, int vsub);
>> +int (*perspective)(AVFilterContext *ctx,
>> + void *arg, int job, int nb_jobs);
>> } PerspectiveContext;
>>
>> #define OFFSET(x) offsetof(PerspectiveContext, x)
>> @@ -193,15 +191,34 @@ static int config_input(AVFilterLink *inlink)
>> return 0;
>> }
>>
>> -static void resample_cubic(PerspectiveContext *s,
>> - uint8_t *dst, int dst_linesize,
>> - uint8_t *src, int src_linesize,
>> - int w, int h, int hsub, int vsub)
>> +typedef struct ThreadData {
>> +uint8_t *dst;
>> +int dst_linesize;
>> +uint8_t *src;
>> +int src_linesize;
>> +int w, h;
>> +int hsub, vsub;
>> +} ThreadData;
>> +
>> +static int resample_cubic(AVFilterContext *ctx, void *arg,
>> + int job, int nb_jobs)
>> {
>> +PerspectiveContext *s = ctx->priv;
>> +ThreadData *td = arg;
>> +uint8_t *dst = td->dst;
>> +int dst_linesize = td->dst_linesize;
>> +uint8_t *src = td->src;
>> +int src_linesize = td->src_linesize;
>> +int w = td->w;
>> +int h = td->h;
>> +int hsub = td->hsub;
>> +int vsub = td->vsub;
>> +int start = (h * job) / nb_jobs;
>> +int end = (h * (job+1)) / nb_jobs;
>> const int linesize = s->linesize[0];
>> int x, y;
>>
>> -for (y = 0; y < h; y++) {
>> +for (y = start; y < end; y++) {
>> int sy = y << vsub;
>> for (x = 0; x < w; x++) {
>> int u, v, subU, subV, sum, sx;
>> @@ -259,17 +276,28 @@ static void resample_cubic(PerspectiveContext *s,
>> dst[x + y * dst_linesize] = sum;
>> }
>> }
>> +return 0;
>> }
>>
>> -static void resample_linear(PerspectiveContext *s,
>> -uint8_t *dst, int dst_linesize,
>> -uint8_t *src, int src_linesize,
>> -int w, int h, int hsub, int vsub)
>> +static int resample_linear(AVFilterContext *ctx, void *arg,
>> + int job, int nb_jobs)
>> {
>> +PerspectiveContext *s = ctx->priv;
>> +ThreadData *td = arg;
>> +uint8_t *dst = td->dst;
>> +int dst_linesize = td->dst_linesize;
>> +uint8_t *src = td->src;
>> +int src_linesize = td->src_linesize;
>> +int w = td->w;
>> +int h = td->h;
>> +int hsub = td->hsub;
>> +int vsub = td->vsub;
>> +int start = (h * job) / nb_jobs;
>> +int end = (h * (job+1)) / nb_jobs;
>> const int linesize = s->linesize[0];
>> int x, y;
>>
>> -for (y = 0; y < h; y++){
>> +for (y = start; y < end; y++){
>> int sy = y << vsub;
>> for (x = 0; x < w; x++){
>> int u, v, subU, subV, sum, sx, index, subUI, subVI;
>> @@ -323,6 +351,7 @@ static void resample_linear(PerspectiveContext *s,
>> dst[x + y * dst_linesize] = sum;
>> }
>> }
>> +return 0;
>> }
>>
>> static av_cold int init(AVFilterContext *ctx)
>> @@ -355,9 +384,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>> *frame)
>> for (plane = 0; plane < s->nb_planes; plane++) {
>> int hsub = plane == 1 || plane == 2 ? s->hsub : 0;
>> int vsub = plane == 1 || plane == 2 ? s->vsub : 0;
>> -s->perspective(s, out->data[plane], out->linesize[plane],
>> - frame->data[plane], frame->linesize[plane],
>> - s->linesize[plane], s->height[plane], hsub,
>> vsub);
>> +ThreadData td = {.dst = out->data[plane],
>> + .dst_linesize = out->linesize[plane],
>> + .src = frame->data[plane],
>> + .src_linesize = frame->linesize[plane],
>> + .w = s->linesize[plane],
>> + .h = s->height[plane],
>> + .hsub = hsub,
>> + .vsub = vsub };
>> +ctx->internal->execute(ctx, s->perspective, &td, NULL,
>> FFMIN(td.h, ctx->graph->nb_threads));
>> }
>>
>> av_frame_free(&frame);
>
> Missing the entry .flags, the threading probably has no effect.
>
> [...]
>
> --
> Clement B.
>
locally ad
[FFmpeg-devel] [PATCH] ffmpeg 0.10.x set correct bit rate in riff wav headers
Hi, The attached patch fixes incorrect bit rate values in riff headers when a conversion is done from 16 bit samples to alaw. [user@test ffmpeg-new]$ ./ffprobe ../sample.wav 2>&1 | tail -4 Input #0, wav, from '../sample.wav': Duration: 00:00:10.00, bitrate: 256 kb/s Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, 1 channels,s16, 256 kb/s [user@test ffmpeg-new]$ ./ffmpeg -i ../sample.wav -f wav -acodec pcm_alaw -ac 1 -ar 8000 ../sample.alaw.wav ffmpeg version 0.10.14 Copyright (c) 2000-2014 the FFmpeg developers built on Aug 12 2014 12:30:33 with gcc 4.1.2 20080704 (Red Hat 4.1.2-51) configuration: --disable-yasm libavutil 51. 35.100 / 51. 35.100 libavcodec 53. 61.100 / 53. 61.100 libavformat53. 32.100 / 53. 32.100 libavdevice53. 4.100 / 53. 4.100 libavfilter 2. 61.100 / 2. 61.100 libswscale 2. 1.100 / 2. 1.100 libswresample 0. 6.100 / 0. 6.100 [wav @ 0x158813a0] max_analyze_duration 500 reached at 512 Input #0, wav, from '../sample.wav': Duration: 00:00:10.00, bitrate: 256 kb/s Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, 1 channels,s16, 256 kb/s File '../sample.alaw.wav' already exists. Overwrite ? [y/N] y Output #0, wav, to '../sample.alaw.wav': Metadata: encoder : Lavf53.32.100 Stream #0:0: Audio: pcm_alaw ([6][0][0][0] / 0x0006), 8000 Hz, 1 channels, s 16, 64 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s16le -> pcm_alaw) Press [q] to stop, [?] for help size= 78kB time=00:00:09.99 bitrate= 64.0kbits/s video:0kB audio:78kB global headers:0kB muxing overhead 0.072509% [user@test ffmpeg-new]$ ./ffprobe ../sample.alaw.wav 2>&1 | tail -4 Input #0, wav, from '../sample.alaw.wav': Duration: 00:00:09.99, bitrate: 64 kb/s Stream #0:0: Audio: pcm_alaw ([6][0][0][0] / 0x0006), 8000 Hz, 1 channels, s 16, 64 kb/s Without the patch ffprobe would report a bit rate of 128kb/s. Greetings, Wilfried 0001-merge-pcmenc-set-correct-bitrate-value.patch Description: 0001-merge-pcmenc-set-correct-bitrate-value.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9/x86: fix bug in intra_pred_hd_32x32.
On Tue, Aug 12, 2014 at 06:37:00AM -0400, Ronald S. Bultje wrote: > Fixes mismatch in first keyframe in sample > ffvp9_fails_where_libvpx.succeeds.webm from ticket 3849. There's still > a second mismatch a few frames into the sample. > --- > libavcodec/x86/vp9intrapred.asm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg 0.10.x set correct bit rate in riff wav headers
Wilfried Weissmann realnetworks.com> writes: > The attached patch fixes incorrect bit rate values in riff > headers when a conversion is done from 16 bit samples to alaw. > From: user This doesn't look correct, did you use "git cherry-pick -x"? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg 0.10.x set correct bit rate in riff wav headers
On Tue, Aug 12, 2014 at 11:45:11AM +, Wilfried Weissmann wrote: > Hi, > > The attached patch fixes incorrect bit rate values in riff headers when a > conversion is done from 16 bit samples to alaw. > > [user@test ffmpeg-new]$ ./ffprobe ../sample.wav 2>&1 | tail -4 > Input #0, wav, from '../sample.wav': > Duration: 00:00:10.00, bitrate: 256 kb/s > Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, 1 > channels,s16, 256 kb/s > > [user@test ffmpeg-new]$ ./ffmpeg -i ../sample.wav -f wav -acodec pcm_alaw -ac > 1-ar 8000 ../sample.alaw.wav > ffmpeg version 0.10.14 Copyright (c) 2000-2014 the FFmpeg developers > built on Aug 12 2014 12:30:33 with gcc 4.1.2 20080704 (Red Hat 4.1.2-51) > configuration: --disable-yasm > libavutil 51. 35.100 / 51. 35.100 > libavcodec 53. 61.100 / 53. 61.100 > libavformat53. 32.100 / 53. 32.100 > libavdevice53. 4.100 / 53. 4.100 > libavfilter 2. 61.100 / 2. 61.100 > libswscale 2. 1.100 / 2. 1.100 > libswresample 0. 6.100 / 0. 6.100 > [wav @ 0x158813a0] max_analyze_duration 500 reached at 512 > Input #0, wav, from '../sample.wav': > Duration: 00:00:10.00, bitrate: 256 kb/s > Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, 1 > channels,s16, 256 kb/s > File '../sample.alaw.wav' already exists. Overwrite ? [y/N] y > Output #0, wav, to '../sample.alaw.wav': > Metadata: > encoder : Lavf53.32.100 > Stream #0:0: Audio: pcm_alaw ([6][0][0][0] / 0x0006), 8000 Hz, 1 > channels, s 16, 64 kb/s > Stream mapping: > Stream #0:0 -> #0:0 (pcm_s16le -> pcm_alaw) > Press [q] to stop, [?] for help > size= 78kB time=00:00:09.99 bitrate= 64.0kbits/s > video:0kB audio:78kB global headers:0kB muxing overhead 0.072509% > [user@test ffmpeg-new]$ ./ffprobe ../sample.alaw.wav 2>&1 | tail -4 > Input #0, wav, from '../sample.alaw.wav': > Duration: 00:00:09.99, bitrate: 64 kb/s > Stream #0:0: Audio: pcm_alaw ([6][0][0][0] / 0x0006), 8000 Hz, 1 > channels, s 16, 64 kb/s > > Without the patch ffprobe would report a bit rate of 128kb/s. > > Greetings, > Wilfried > > libavcodec/pcm.c |1 + > tests/ref/acodec/pcm_alaw|2 +- > tests/ref/acodec/pcm_mulaw |2 +- > tests/ref/seek/pcm_alaw_wav | 36 ++-- > tests/ref/seek/pcm_mulaw_wav | 36 ++-- > 5 files changed, 39 insertions(+), 38 deletions(-) > b49e6729732102f81842fdc6f17c9bb690aea642 > 0001-merge-pcmenc-set-correct-bitrate-value.patch > From 4cf471903c9285f3e7dd035f0ef9cf153ad28535 Mon Sep 17 00:00:00 2001 > From: user like carl said, this looks wrong, but ive found the correct commit from where this came already, ill backport it to release/0.10 so it will be in the next release from that branch thanks PS: i suggest you use a modern FFmpeg like from the latest release which is 2.3.2 ATM, 0.10 is a bit old already ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list
On 12/08/14 at 10:36, Steven Liu wrote: > 2014-08-12 7:26 GMT+08:00 Simon Thelen : > > On 11/08/14 at 17:39, Steven Liu wrote: [..] > > > The FFmpeg hls module can make m3u8 and ts, but it dosen't delete the > > > old ts segment file. > > > If always run this module, the disk will full, so this patch can fix > > > the problem. > > > When update the segment list m3u8 file, it will delete the ts segment > > > out range from the list file. > > [..] > > I'm pretty sure this is why the hls muxer has the `-hls_wrap wrap' option. [..] > hls_list_size and hls_wrap option two can fix the problem, but this > patch can fix the problem of the default parameter, because the ts file on > disk , one to one correspondence with the m3u8 file will better, isn't it? IMO, the problem is that you're modifying the default behavior even though an option already exists to let you specify the amount of segment files to keep around. This might be suitable in your use-case, but what if I (or someone else) wanted to keep all the segment files for archival purposes, but not list them in the m3u8; with your patch this no longer becomes possible. If you were to write a new patch that made hls_wrap default to hls_list_size instead of the default 0, it would no longer impose artificial limits on users. At that point, the inclusion of the patch would depend on the opinion of the hls maintainer and the other FFmpeg maintainers with opinions on the matter. -- Simon Thelen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 11 Aug 2014 18:34:23 -0400 Theodore Ts'o wrote: > On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote: > > > > To be fair, FFmpeg does its own "manual" symbol versioning by appending > > increasing numbers to function names. But the real problem are not > > these functions, but public structs. Imagine a new API user fighting to > > guess which fields in AVCodecContext must be set, or which must not be > > set. Seasoned FFmpeg developers probably don't know the horror. > > There are some best practices in API design; one of them is to > minimize public structs as much as possible. Instead, have blind > pointers which are handed back by an "initialize object" function, and > then have setter/getter functions that allow you to fetch various > parameters or flags which modify how the object behaves. This allows > you to add or deprecate new flags, configuration parameters, in a > relatively sane way. Yes. Unfortunately, central data structures are still public, and just making them opaque and adding accessors on top of them would lead to a major compatibility issue, and all developers using ffmpeg would complain big time. In fact, the API cleanup is an ongoing process, and is what causes the incompatibilities with each release. For example, a C library should have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ as prefixes for all symbols in the public header files. This required fixing some symbols, which of course broke some applications. > I have this dream/fantasy where all of the energy over developing and > maintaining two forks was replaced by a spirit of cooperations and the > developers working together to design a new API from scratch that > could be guaranteed to be stable, and then applications migrated over > to use this stable, well-designed, future-proofed API. > > Call me a naive, over-optimistic dreamer, but :-) > > (And, the yes, the new API probably should be a bit higher level.) > > "Can we all just get along?" -- https://www.youtube.com/watch?v=1sONfxPCTU0 > > - Ted Yes, that would be nice. The FFmpeg/Libav split is mostly a political/social issue though: it seems some (not all) members from each side just can't deal with some (not all) members from the other side. How do you fix this? It seems impossible. (Also, btw.: sometimes the low level aspect of the libraries is simply needed. It's just that most applications would be better off with a more high level API.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 02:54:39 +0200 Matthias Urlichs wrote: > Hi, > > wm4: > > Build something on a newer glibc system, and try to run the binary on > > an older system. It most likely won't work - even if it could in > > theory. (At least it was this way some years ago. Probably still is.) > > What would be the point of introducing new or updated interfaces > if you then couldn't use them? Apparently this happens even if an application only uses C99 and POSIX standard symbols. > ABI backwards compatibility is not a goal I would want to spend any time > on. Forward compatibility, on the other hand … Well, I think it's a pretty common complaint from commercial software vendors. That you can't distribute precompiled binaries reasonably. > > To be fair, FFmpeg does its own "manual" symbol versioning by appending > > increasing numbers to function names. But the real problem are not > > these functions, but public structs. Imagine a new API user fighting to > > guess which fields in AVCodecContext must be set, or which must not be > > set. Seasoned FFmpeg developers probably don't know the horror. > > > That's reasonably easy – you add a function to allocate the structure for > you. That function sets a version field and/or initializes everything to > a sane default. Also, you never shrink the structure, or move fields. > > Obviously, you also tell people to never ever embed the thing directly in > something else, assuming that you can't keep it opaque entirely. That's already the case with most libav* data structures. > Of course, it's only easy if you design your API that way from the > beginning … > > > I think the largest issue with FFmpeg is actually that it's so > > low-level. Users usually have to connect the individual libraries > > themselves, and that is very error prone. Hell, even the official > > FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem > > to be broken to hell. > > > > I think there should be a higher-level FFmpeg library that takes care > > of these things. > > > gstreamer-ffmpeg? gstreamer has more problems than it solves. (Forces glib/gobject on you, GTK-style OOP, pretty crashy, tons of low-quality plugins, complicated API and design, ...) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg 0.10.x set correct bit rate in riff wav headers
I did cherry-pick from http://git.videolan.org/?p=ffmpeg.git;a=commit;h=7d7b40f48a05af4483b31cdb8b4f1808b97b1f2f to my local repo and applied it to the 0.10 branch. I assumed the test/ref/... are for unit tests and included these changes too. Is that what you are referring to when you say the patch does not look correct? After fixing some compile issues of the test suite (because of disabled features?) a "make check" completed without errors. That is why I tought the changes to those files are valid. Greetings, Wilfried > -Ursprüngliche Nachricht- > Von: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] Im Auftrag von Michael Niedermayer > Gesendet: Dienstag, 12. August 2014 14:23 > An: FFmpeg development discussions and patches > Betreff: Re: [FFmpeg-devel] [PATCH] ffmpeg 0.10.x set correct bit rate > in riff wav headers > > On Tue, Aug 12, 2014 at 11:45:11AM +, Wilfried Weissmann wrote: > > Hi, > > > > The attached patch fixes incorrect bit rate values in riff headers > when a conversion is done from 16 bit samples to alaw. > > > > [user@test ffmpeg-new]$ ./ffprobe ../sample.wav 2>&1 | tail -4 Input > > #0, wav, from '../sample.wav': > > Duration: 00:00:10.00, bitrate: 256 kb/s > > Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, > 1 channels,s16, 256 kb/s > > > > [user@test ffmpeg-new]$ ./ffmpeg -i ../sample.wav -f wav -acodec > pcm_alaw -ac 1-ar 8000 ../sample.alaw.wav > > ffmpeg version 0.10.14 Copyright (c) 2000-2014 the FFmpeg developers > > built on Aug 12 2014 12:30:33 with gcc 4.1.2 20080704 (Red Hat > 4.1.2-51) > > configuration: --disable-yasm > > libavutil 51. 35.100 / 51. 35.100 > > libavcodec 53. 61.100 / 53. 61.100 > > libavformat53. 32.100 / 53. 32.100 > > libavdevice53. 4.100 / 53. 4.100 > > libavfilter 2. 61.100 / 2. 61.100 > > libswscale 2. 1.100 / 2. 1.100 > > libswresample 0. 6.100 / 0. 6.100 > > [wav @ 0x158813a0] max_analyze_duration 500 reached at 512 > > Input #0, wav, from '../sample.wav': > > Duration: 00:00:10.00, bitrate: 256 kb/s > > Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, > 1 channels,s16, 256 kb/s > > File '../sample.alaw.wav' already exists. Overwrite ? [y/N] y Output > > #0, wav, to '../sample.alaw.wav': > > Metadata: > > encoder : Lavf53.32.100 > > Stream #0:0: Audio: pcm_alaw ([6][0][0][0] / 0x0006), 8000 Hz, 1 > channels, s 16, 64 kb/s > > Stream mapping: > > Stream #0:0 -> #0:0 (pcm_s16le -> pcm_alaw) Press [q] to stop, [?] > > for help > > size= 78kB time=00:00:09.99 bitrate= 64.0kbits/s > > video:0kB audio:78kB global headers:0kB muxing overhead 0.072509% > > [user@test ffmpeg-new]$ ./ffprobe ../sample.alaw.wav 2>&1 | tail -4 > Input #0, wav, from '../sample.alaw.wav': > > Duration: 00:00:09.99, bitrate: 64 kb/s > > Stream #0:0: Audio: pcm_alaw ([6][0][0][0] / 0x0006), 8000 Hz, 1 > channels, s 16, 64 kb/s > > > > Without the patch ffprobe would report a bit rate of 128kb/s. > > > > Greetings, > > Wilfried > > > > > libavcodec/pcm.c |1 + > > tests/ref/acodec/pcm_alaw|2 +- > > tests/ref/acodec/pcm_mulaw |2 +- > > tests/ref/seek/pcm_alaw_wav | 36 ++-- > > > tests/ref/seek/pcm_mulaw_wav | 36 ++-- > > > 5 files changed, 39 insertions(+), 38 deletions(-) > > b49e6729732102f81842fdc6f17c9bb690aea642 > > 0001-merge-pcmenc-set-correct-bitrate-value.patch > > From 4cf471903c9285f3e7dd035f0ef9cf153ad28535 Mon Sep 17 00:00:00 > 2001 > > > From: user > > like carl said, this looks wrong, but ive found the correct commit from > where this came already, ill backport it to release/0.10 so it will be > in the next release from that branch > > thanks > > PS: i suggest you use a modern FFmpeg like from the latest release > which is 2.3.2 ATM, 0.10 is a bit old already ... > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Old school: Use the lowest level language in which you can solve the > problem > conveniently. > New school: Use the highest level language in which the latest > supercomputer > can solve the problem without the user falling asleep > waiting. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfitler/vf_perspective: support slice threading
On Tue, Aug 12, 2014 at 11:32:20AM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_perspective.c | 69
> +---
> 1 file changed, 52 insertions(+), 17 deletions(-)
>
> diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
> index f433226..c5471b0 100644
> --- a/libavfilter/vf_perspective.c
> +++ b/libavfilter/vf_perspective.c
> @@ -47,10 +47,8 @@ typedef struct PerspectiveContext {
> int hsub, vsub;
> int nb_planes;
>
> -void (*perspective)(struct PerspectiveContext *s,
> -uint8_t *dst, int dst_linesize,
> -uint8_t *src, int src_linesize,
> -int w, int h, int hsub, int vsub);
> +int (*perspective)(AVFilterContext *ctx,
> + void *arg, int job, int nb_jobs);
> } PerspectiveContext;
>
> #define OFFSET(x) offsetof(PerspectiveContext, x)
> @@ -193,15 +191,34 @@ static int config_input(AVFilterLink *inlink)
> return 0;
> }
>
> -static void resample_cubic(PerspectiveContext *s,
> - uint8_t *dst, int dst_linesize,
> - uint8_t *src, int src_linesize,
> - int w, int h, int hsub, int vsub)
> +typedef struct ThreadData {
> +uint8_t *dst;
> +int dst_linesize;
> +uint8_t *src;
> +int src_linesize;
> +int w, h;
> +int hsub, vsub;
> +} ThreadData;
> +
> +static int resample_cubic(AVFilterContext *ctx, void *arg,
> + int job, int nb_jobs)
> {
> +PerspectiveContext *s = ctx->priv;
> +ThreadData *td = arg;
> +uint8_t *dst = td->dst;
> +int dst_linesize = td->dst_linesize;
> +uint8_t *src = td->src;
> +int src_linesize = td->src_linesize;
> +int w = td->w;
> +int h = td->h;
> +int hsub = td->hsub;
> +int vsub = td->vsub;
> +int start = (h * job) / nb_jobs;
> +int end = (h * (job+1)) / nb_jobs;
I would guess this doesn't work unless you src += start * src_linesize
(same for dst)
[...]
--
Clément B.
pgpxEzPIzAGuL.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg 0.10.x set correct bit rate in riff wav headers
Wilfried Weissmann realnetworks.com> writes: > I did cherry-pick from > http://git.videolan.org/?p=ffmpeg.git;a=commit;h=7d7b40f4 > to my local repo and applied it to the 0.10 branch. > > I assumed the test/ref/... are for unit tests and > included these changes too. Is that what you are > referring to when you say the patch does not look correct? No, the author was not set correctly. I still believe that using "git cherry-pick -x 7d7b40f4" should keep the author information, or to say it differently, if it disappears, this should be reported to the git developers. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list
On Aug 12, 2014, at 8:37 PM, Simon Thelen wrote: > On 12/08/14 at 10:36, Steven Liu wrote: >> 2014-08-12 7:26 GMT+08:00 Simon Thelen : >>> On 11/08/14 at 17:39, Steven Liu wrote: > [..] The FFmpeg hls module can make m3u8 and ts, but it dosen't delete the old ts segment file. If always run this module, the disk will full, so this patch can fix the problem. When update the segment list m3u8 file, it will delete the ts segment out range from the list file. >>> [..] >>> I'm pretty sure this is why the hls muxer has the `-hls_wrap wrap' option. > [..] >> hls_list_size and hls_wrap option two can fix the problem, but this >> patch can fix the problem of the default parameter, because the ts file on >> disk , one to one correspondence with the m3u8 file will better, isn't it? > IMO, the problem is that you're modifying the default behavior even > though an option already exists to let you specify the amount of segment > files to keep around. This might be suitable in your use-case, but what > if I (or someone else) wanted to keep all the segment files for archival > purposes, but not list them in the m3u8; with your patch this no longer > becomes possible. > > If you were to write a new patch that made hls_wrap default to > hls_list_size instead of the default 0, it would no longer impose > artificial limits on users. At that point, the inclusion of the patch > would depend on the opinion of the hls maintainer and the other FFmpeg > maintainers with opinions on the matter. Hi Simon Thelen, Maybe you’re right. I think the '-f segment' can save all of the segment ts file, so hls is used for living stream, so it not save segment ts be better; Maybe i’m wrong. but this patch just used for remove the segment ts not list in m3u8. :D > > -- > Simon Thelen > ___ > 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] Reintroducing FFmpeg to Debian
Hi, wm4: > > ABI backwards compatibility is not a goal I would want to spend any time > > on. Forward compatibility, on the other hand … > > Well, I think it's a pretty common complaint from commercial software > vendors. That you can't distribute precompiled binaries reasonably. > They need to compile the software with the lowest-possible version of the library which they can reasonably use (and which is still API compatible with the hightest that's in general use). This is hardly rocket science, but requires care from all participants. > > gstreamer-ffmpeg? > > gstreamer has more problems than it solves. (Forces glib/gobject on > you, GTK-style OOP, pretty crashy, tons of low-quality plugins, > complicated API and design, ...) > Yeah, I know. Missing Snarky Smiley Syndrome on my part. -- -- Matthias Urlichs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, wm4: > In fact, the API cleanup is an ongoing process, and is what causes the > incompatibilities with each release. For example, a C library should > have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ > as prefixes for all symbols in the public header files. This required > fixing some symbols, which of course broke some applications. > One could add weak aliases and/or marked-as-deprecated C macros instead of doing a "hard" renaming. To be fair, the GCC change which even allowed emitting a warning upon use of a macro isn't _that_ old … > Yes, that would be nice. The FFmpeg/Libav split is mostly a > political/social issue though: it seems some (not all) members from > each side just can't deal with some (not all) members from the other > side. > > How do you fix this? It seems impossible. > Kick the non-cooperating people off both projects. :-P (One slight problem with this solution is that the net effect is likely to be three forks instead of two, not one …) > (Also, btw.: sometimes the low level aspect of the libraries is simply > needed. It's just that most applications would be better off with a > more high level API.) Most CS problems can be solved by adding yet another level of indirection – except for the problem of having too many levels of indirection and – relevant here – the associated decrease in speed. -- -- Matthias Urlichs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 16:51:40 +0200 Matthias Urlichs wrote: > Hi, > > wm4: > > In fact, the API cleanup is an ongoing process, and is what causes the > > incompatibilities with each release. For example, a C library should > > have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ > > as prefixes for all symbols in the public header files. This required > > fixing some symbols, which of course broke some applications. > > > One could add weak aliases and/or marked-as-deprecated C macros > instead of doing a "hard" renaming. But this was done: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=104e10fb426f903ba9157fdbfe30292d0e4c3d72 FFmpeg still has them, Libav removed them about half a year after adding them. > To be fair, the GCC change which even allowed emitting a warning upon use > of a macro isn't _that_ old … > > > Yes, that would be nice. The FFmpeg/Libav split is mostly a > > political/social issue though: it seems some (not all) members from > > each side just can't deal with some (not all) members from the other > > side. > > > > How do you fix this? It seems impossible. > > > Kick the non-cooperating people off both projects. :-P > > (One slight problem with this solution is that the net effect is likely to > be three forks instead of two, not one …) Yes, or kill the project entirely, since key people would have to be kicked off. A bit of a problem, as you see. > > (Also, btw.: sometimes the low level aspect of the libraries is simply > > needed. It's just that most applications would be better off with a > > more high level API.) > > Most CS problems can be solved by adding yet another level of indirection – > except for the problem of having too many levels of indirection and – > relevant here – the associated decrease in speed. Speed wouldn't be affected here, since the "hard work" is done in libavcodec anyway. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfitler/vf_perspective: support slice threading
On 8/12/14, Clement Boesch wrote:
> On Tue, Aug 12, 2014 at 11:32:20AM +, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavfilter/vf_perspective.c | 69
>> +---
>> 1 file changed, 52 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
>> index f433226..c5471b0 100644
>> --- a/libavfilter/vf_perspective.c
>> +++ b/libavfilter/vf_perspective.c
>> @@ -47,10 +47,8 @@ typedef struct PerspectiveContext {
>> int hsub, vsub;
>> int nb_planes;
>>
>> -void (*perspective)(struct PerspectiveContext *s,
>> -uint8_t *dst, int dst_linesize,
>> -uint8_t *src, int src_linesize,
>> -int w, int h, int hsub, int vsub);
>> +int (*perspective)(AVFilterContext *ctx,
>> + void *arg, int job, int nb_jobs);
>> } PerspectiveContext;
>>
>> #define OFFSET(x) offsetof(PerspectiveContext, x)
>> @@ -193,15 +191,34 @@ static int config_input(AVFilterLink *inlink)
>> return 0;
>> }
>>
>> -static void resample_cubic(PerspectiveContext *s,
>> - uint8_t *dst, int dst_linesize,
>> - uint8_t *src, int src_linesize,
>> - int w, int h, int hsub, int vsub)
>> +typedef struct ThreadData {
>> +uint8_t *dst;
>> +int dst_linesize;
>> +uint8_t *src;
>> +int src_linesize;
>> +int w, h;
>> +int hsub, vsub;
>> +} ThreadData;
>> +
>> +static int resample_cubic(AVFilterContext *ctx, void *arg,
>> + int job, int nb_jobs)
>> {
>> +PerspectiveContext *s = ctx->priv;
>> +ThreadData *td = arg;
>> +uint8_t *dst = td->dst;
>> +int dst_linesize = td->dst_linesize;
>> +uint8_t *src = td->src;
>> +int src_linesize = td->src_linesize;
>> +int w = td->w;
>> +int h = td->h;
>> +int hsub = td->hsub;
>> +int vsub = td->vsub;
>> +int start = (h * job) / nb_jobs;
>> +int end = (h * (job+1)) / nb_jobs;
>
> I would guess this doesn't work unless you src += start * src_linesize
> (same for dst)
I do not think so. You can try it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
hi, This patch enables demuxing fo MXF files generated for or by Avid Media Composer. Avid seems to use different SMPTE universal labels for its video and audio data definitions then ones currently in mxf.c. Also they seem to use a differnt UL for DNxHD Codec ID. I got the ULs from FMbc version of mxf.c I tested it out on the follow media submitted by users reporting this problem ticket #1554 http://samples.ffmpeg.org/MXF/issue2160/PW0805A0V01.4C5B5636.EFA330.mxf ticket #3100 http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3100/1sec_mxf_test_A5270C779.1.mxf http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3100/1sec_mxf_test_Video5270C795.mxf ticket #3450 http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3450/WriteAvidMXFgenerated/5502_0010_v1.mxf I can also supply more sample material if needed. Mark Reid (1): added ULs for demuxing avid media composer mxf files libavformat/mxf.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
---
libavformat/mxf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index d20ed94..8ebfdf2 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -28,6 +28,8 @@
const MXFCodecUL ff_mxf_data_definition_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x01,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_VIDEO },
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x02,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_AUDIO },
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x6F,0x3C,0x8C,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_VIDEO }, /* Avid Media Composer MXF */
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x78,0xE1,0xEB,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_AUDIO }, /* Avid Media Composer MXF */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVMEDIA_TYPE_DATA },
};
@@ -44,6 +46,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x01,0x00
}, 15, AV_CODEC_ID_RAWVIDEO }, /* Uncompressed 422 8-bit */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00
}, 13, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x03,0x02,0x00,0x00
}, 14, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x04,0x01,0x00
}, 16, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD Avid Media Composer MXF */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x00,0x00
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC Intra */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
}, 16, AV_CODEC_ID_V210 }, /* V210 */
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 16:51:40 +0200 Matthias Urlichs wrote: > Hi, > > Yes, that would be nice. The FFmpeg/Libav split is mostly a > > political/social issue though: it seems some (not all) members from > > each side just can't deal with some (not all) members from the other > > side. > > > > How do you fix this? It seems impossible. > > > Kick the non-cooperating people off both projects. :-P > at least 6+ devels refuse to work with each other , thats only a quick estimation, i havent polled everyone lately. ffmpeg and libav devs dont even TALK to each other. theres a couple devs who frequent both irc/lists, most do not. > (One slight problem with this solution is that the net effect is > likely to be three forks instead of two, not one …) i wrote up a current status of the projects, http://wiki.multimedia.cx/index.php?title=User_talk:Compn yes, you are correct, baptiste left and created ffmbc. ffmbc is nice, if we play our cards correctly we can get it merged into ffmpeg. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lsws: duplicate ff_log2_tab
libswscale uses the table but wasn't duplicating it like the rest of the libs. This should fix compilation failures on msvc/icl after lavu stopped exporting internal functions and tables. Signed-off-by: James Almer --- libswscale/Makefile | 2 ++ libswscale/log2_tab.c | 1 + 2 files changed, 3 insertions(+) create mode 100644 libswscale/log2_tab.c diff --git a/libswscale/Makefile b/libswscale/Makefile index 067e2b9..a60b057 100644 --- a/libswscale/Makefile +++ b/libswscale/Makefile @@ -15,6 +15,8 @@ OBJS = hscale_fast_bilinear.o \ utils.o \ yuv2rgb.o\ +OBJS-$(CONFIG_SHARED)+= log2_tab.o + # Windows resource file SLIBOBJS-$(HAVE_GNU_WINDRES) += swscaleres.o diff --git a/libswscale/log2_tab.c b/libswscale/log2_tab.c new file mode 100644 index 000..47a1df0 --- /dev/null +++ b/libswscale/log2_tab.c @@ -0,0 +1 @@ +#include "libavutil/log2_tab.c" -- 1.8.5.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC][PATCH] Allow include files to be installed into subdirectory
Hi, On 12.08.2014 02:21, Ivan Kalvachev wrote: On 8/11/14, Andreas Cadhalpun wrote: Assuming it would be possible to install development packages for both at the same time, which one should be used, when building a program? It would be decided by the gcc -I inclusion option. But this path has to come from the pkg-config files. It modifies the search paths for header files, so that it checks these paths before the system/default ones (When using `#include "libavcodec/avcodec.h" `) Libav headers are probably going to remain in the default /usr/include/ . Usually this should not be a problem, unless a program uses `#include ` that should be used for system headers (aka checks the system/default paths first). But a lot of programs use '#include '. There might still be problems if there are explicit -I/usr/include inserted by other libraries that mix the inclusion order. To avoid hard to debug compiling problems, that the -dev packages may still be marked as conflicting, even though no files are overwritten. This final conflict however cannot be resolved on FFmpeg side. Yes, they still have to conflict. The change is reflected in the pkgconfig files too. Since applications that link to libraries with addition suffixes should be using pkgconfig, they would be using the correct header includes automatically. If that's to be determined via pkg-config files, then the obvious problem is that both install these files in the same location, and if one doesn't, programs can't find the library. The problem is not that they are installed in the same location, but that they have same names. However I just checked and when you define library suffix (e.g. --build-suffix="_ffmpeg"), it also adds the same suffix to the .pc files. So you have /usr/lib/share/pkgconfig/libavcodec_ffmpeg.pc /usr/lib/libavcodec_ffmpeg.so Yes, but I patched that out in the Debian package [1], because otherwise the programs wouldn't find the pkg-config files. In short, assuming if Libav doesn't change their library names and pkgconfig files, the programs that are looking for 'libavcodec.pc' would get the Libav one, the programs that are looking for 'libavcodec_ffmpeg.pc' would get FFmpeg. The problem is that programs only look for libavcodec.pc. I believe that you should already be using --build-suffix, so that should already be in the package. Is there something else I'm missing? Probably, that the pkg-config files in the FFmpeg package for Debian are still libavcodec.pc etc.. I did just a rudimentary test and I couldn't spot anything wrong. Please test it before inclusion. The patch seems to be alright, but it doesn't make it possible to make the development packages of FFmpeg and Libav co-installable. Unfortunately not. But without the patch the problem is entirely in how FFmpeg installs its header. With it, it is entirely Libav problem for using system/common directory. Then, if Debian wants to resolve the conflict, Libav header files could be moved in their own directory. The patch should be trivial to port. I still don't see what the benefit would be, as the *-dev packages still have to conflict. As for the future, it might be good idea next major release (e.g. 3.0) to have the $prefix/include/ffmpeg as default include path (for non-comapt build). So this would also not help. At the moment FFmpeg is trying to mimic 100% Libav API/ABI, and to be perfect drop-in replacement. This means using the same library names, locations and header files. This is what I call compat build. It is 100% compatible with Libav from application/program point of view. When using --build-suffix, you obviously want to differentiate from Libav, so I call that non-compat build. Except that the programs still should be able to build, ideally with both, and which one is used during build is defined by which *-dev packages are installed. This is the reason, why the pkg-config file names have to be the same. Sorry if this is caused confusion. I hope that the way Debian packages FFmpeg would actually turn out to be the new default. Best regards, Andreas 1: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/tree/debian/patches/pkg-config_file_without_build_suffix.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lsws: duplicate ff_log2_tab
On Tue, Aug 12, 2014 at 03:21:24PM -0300, James Almer wrote: > libswscale uses the table but wasn't duplicating it like the rest of the libs. > This should fix compilation failures on msvc/icl after lavu stopped exporting > internal functions and tables. > > Signed-off-by: James Almer > --- > libswscale/Makefile | 2 ++ > libswscale/log2_tab.c | 1 + > 2 files changed, 3 insertions(+) > create mode 100644 libswscale/log2_tab.c applied thanks [...] -- 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. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
Mark Reid gmail.com> writes: > I got the ULs from FMbc version of mxf.c Sounds like this could be added to the commit message. > I tested it out on the follow media submitted > by users reporting this problem > > ticket #1554 > ticket #3100 > ticket #3450 Mentioning these tickets in the commit message would also be a good idea. Thank you for the patch, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
On Tue, Aug 12, 2014 at 12:06 PM, Carl Eugen Hoyos wrote: > Mark Reid gmail.com> writes: > > > I got the ULs from FMbc version of mxf.c > > Sounds like this could be added to the commit message. > > > I tested it out on the follow media submitted > > by users reporting this problem > > > > ticket #1554 > > ticket #3100 > > ticket #3450 > > Mentioning these tickets in the commit message would > also be a good idea. > Sure thing, I'll send a new patch with these details in the commit message. > > Thank you for the patch, Carl Eugen > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/idctdsp: make add/put_pixels_clamped_c internal functions
This reduces code duplication and differences with the fork.
Signed-off-by: James Almer
---
libavcodec/idctdsp.c | 49 +
libavcodec/idctdsp.h | 46 +-
libavcodec/xvididct.c | 4 ++--
3 files changed, 52 insertions(+), 47 deletions(-)
diff --git a/libavcodec/idctdsp.c b/libavcodec/idctdsp.c
index 4ca0734..f139bac 100644
--- a/libavcodec/idctdsp.c
+++ b/libavcodec/idctdsp.c
@@ -80,6 +80,27 @@ av_cold void ff_init_scantable_permutation(uint8_t
*idct_permutation,
}
}
+void ff_put_pixels_clamped(const int16_t *block, uint8_t *av_restrict pixels,
+ int line_size)
+{
+int i;
+
+/* read the pixels */
+for (i = 0; i < 8; i++) {
+pixels[0] = av_clip_uint8(block[0]);
+pixels[1] = av_clip_uint8(block[1]);
+pixels[2] = av_clip_uint8(block[2]);
+pixels[3] = av_clip_uint8(block[3]);
+pixels[4] = av_clip_uint8(block[4]);
+pixels[5] = av_clip_uint8(block[5]);
+pixels[6] = av_clip_uint8(block[6]);
+pixels[7] = av_clip_uint8(block[7]);
+
+pixels += line_size;
+block += 8;
+}
+}
+
static void put_pixels_clamped4_c(const int16_t *block, uint8_t *av_restrict
pixels,
int line_size)
{
@@ -133,6 +154,26 @@ static void put_signed_pixels_clamped_c(const int16_t
*block,
}
}
+void ff_add_pixels_clamped(const int16_t *block, uint8_t *av_restrict pixels,
+ int line_size)
+{
+int i;
+
+/* read the pixels */
+for (i = 0; i < 8; i++) {
+pixels[0] = av_clip_uint8(pixels[0] + block[0]);
+pixels[1] = av_clip_uint8(pixels[1] + block[1]);
+pixels[2] = av_clip_uint8(pixels[2] + block[2]);
+pixels[3] = av_clip_uint8(pixels[3] + block[3]);
+pixels[4] = av_clip_uint8(pixels[4] + block[4]);
+pixels[5] = av_clip_uint8(pixels[5] + block[5]);
+pixels[6] = av_clip_uint8(pixels[6] + block[6]);
+pixels[7] = av_clip_uint8(pixels[7] + block[7]);
+pixels += line_size;
+block+= 8;
+}
+}
+
static void add_pixels_clamped4_c(const int16_t *block, uint8_t *av_restrict
pixels,
int line_size)
{
@@ -166,13 +207,13 @@ static void add_pixels_clamped2_c(const int16_t *block,
uint8_t *av_restrict pix
static void jref_idct_put(uint8_t *dest, int line_size, int16_t *block)
{
ff_j_rev_dct(block);
-put_pixels_clamped_c(block, dest, line_size);
+ff_put_pixels_clamped(block, dest, line_size);
}
static void jref_idct_add(uint8_t *dest, int line_size, int16_t *block)
{
ff_j_rev_dct(block);
-add_pixels_clamped_c(block, dest, line_size);
+ff_add_pixels_clamped(block, dest, line_size);
}
static void ff_jref_idct4_put(uint8_t *dest, int line_size, int16_t *block)
{
@@ -255,9 +296,9 @@ av_cold void ff_idctdsp_init(IDCTDSPContext *c,
AVCodecContext *avctx)
}
}
-c->put_pixels_clamped= put_pixels_clamped_c;
+c->put_pixels_clamped= ff_put_pixels_clamped;
c->put_signed_pixels_clamped = put_signed_pixels_clamped_c;
-c->add_pixels_clamped= add_pixels_clamped_c;
+c->add_pixels_clamped= ff_add_pixels_clamped;
if (CONFIG_MPEG4_DECODER && avctx->idct_algo == FF_IDCT_XVID)
ff_xvididct_init(c, avctx);
diff --git a/libavcodec/idctdsp.h b/libavcodec/idctdsp.h
index bd5e875..9df13c5 100644
--- a/libavcodec/idctdsp.h
+++ b/libavcodec/idctdsp.h
@@ -48,6 +48,11 @@ void ff_init_scantable_permutation(uint8_t *idct_permutation,
int ff_init_scantable_permutation_x86(uint8_t *idct_permutation,
enum idct_permutation_type perm_type);
+void ff_put_pixels_clamped(const int16_t *block, uint8_t *av_restrict pixels,
+ int line_size);
+void ff_add_pixels_clamped(const int16_t *block, uint8_t *av_restrict pixels,
+ int line_size);
+
typedef struct IDCTDSPContext {
/* pixel ops : interface with DCT */
void (*put_pixels_clamped)(const int16_t *block /* align 16 */,
@@ -106,45 +111,4 @@ void ff_idctdsp_init_ppc(IDCTDSPContext *c, AVCodecContext
*avctx,
void ff_idctdsp_init_x86(IDCTDSPContext *c, AVCodecContext *avctx,
unsigned high_bit_depth);
-static inline void put_pixels_clamped_c(const int16_t *block, uint8_t
*av_restrict pixels,
-int line_size)
-{
-int i;
-
-/* read the pixels */
-for (i = 0; i < 8; i++) {
-pixels[0] = av_clip_uint8(block[0]);
-pixels[1] = av_clip_uint8(block[1]);
-pixels[2] = av_clip_uint8(block[2]);
-pixels[3] = av_clip_uint8(block[3]);
-pixels[4] = av_clip_uint8(block[4]);
-pixels[5] = av_clip_uint8(block[5]);
-pixels[6] = av_clip_uint8(block[6]);
-pixels[7] = av_clip_uint8(block[7]);
-
-pix
[FFmpeg-devel] [PATCH 4/6] lavc/flacenc: partially unroll loop in flac_enc_lpc_32
Now does 6 samples per iteration, up from 2. >From 1.6 to 2.1 times faster again. 2.5 to 3.9 times faster overall. Runtime is reduced by a further 4 to 17%. Reduced by 9 to 65% overall. Same conditions as previously. --- libavcodec/x86/flac_dsp_gpl.asm | 32 +++- 1 files changed, 27 insertions(+), 5 deletions(-) diff --git a/libavcodec/x86/flac_dsp_gpl.asm b/libavcodec/x86/flac_dsp_gpl.asm index 7a49fae..f0674d9 100644 --- a/libavcodec/x86/flac_dsp_gpl.asm +++ b/libavcodec/x86/flac_dsp_gpl.asm @@ -135,13 +135,13 @@ RET INIT_XMM sse42 %if ARCH_X86_64 -cglobal flac_enc_lpc_32, 5, 7, 4, mmsize, res, smp, len, order, coefs +cglobal flac_enc_lpc_32, 5, 7, 8, mmsize, res, smp, len, order, coefs DECLARE_REG_TMP 5, 6 %define length r2d movsxd orderq, orderd %else -cglobal flac_enc_lpc_32, 5, 6, 4, mmsize, res, smp, len, order, coefs +cglobal flac_enc_lpc_32, 5, 6, 8, mmsize, res, smp, len, order, coefs DECLARE_REG_TMP 2, 5 %define length r2mp %endif @@ -173,6 +173,8 @@ mova [rsp],m4; save sign extend mask .looplen: pxor m0, m0 +pxor m4, m4 +pxor m6, m6 mov posj, orderq xor negj, negj @@ -180,23 +182,43 @@ mova [rsp],m4; save sign extend mask movd m2, [coefsq+posj*4] ; c = coefs[j] SPLATD m2 movh m1, [smpq+negj*4-4] ; s = smp[i-j-1] +movh m5, [smpq+negj*4-4+mmsize/2] +movh m7, [smpq+negj*4-4+mmsize] pshufd m1, m1, q3130 +pshufd m5, m5, q3130 +pshufd m7, m7, q3130 pmuldq m1, m2 +pmuldq m5, m2 +pmuldq m7, m2 paddq m0, m1 ; p += c * s +paddq m4, m5 +paddq m6, m7 decnegj incposj jnz .looporder HACK_PSRAQ m0, m3, [rsp], m2; p >>= shift +HACK_PSRAQ m4, m3, [rsp], m2 +HACK_PSRAQ m6, m3, [rsp], m2 CLIPQ m0, [pq_int_min], [pq_int_max], m2 ; clip(p >> shift) +CLIPQ m4, [pq_int_min], [pq_int_max], m2 +CLIPQ m6, [pq_int_min], [pq_int_max], m2 pshufd m0,m0, q0020 ; pack into first 2 dwords +pshufd m4,m4, q0020 +pshufd m6,m6, q0020 movhm1, [smpq] +movhm5, [smpq+mmsize/2] +movhm7, [smpq+mmsize] psubd m1,m0 ; smp[i] - p +psubd m5,m4 +psubd m7,m6 movh [resq], m1 ; res[i] = smp[i] - (p >> shift) +movh [resq+mmsize/2], m5 +movh [resq+mmsize], m7 -add resq, mmsize/2 -add smpq, mmsize/2 -sub length, mmsize/8 +add resq, (3*mmsize)/2 +add smpq, (3*mmsize)/2 +sub length, (3*mmsize)/8 jg .looplen RET -- 1.7.9 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] lavc/flacdsp: document limitations of the LPC encoder
---
libavcodec/flacdsp.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
index 272cf2a..36cd904 100644
--- a/libavcodec/flacdsp.h
+++ b/libavcodec/flacdsp.h
@@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
int len, int shift);
void (*lpc)(int32_t *samples, const int coeffs[32], int order,
int qlevel, int len);
+/**
+ * This function has some limitations with various configurations:
+ * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes the
+ * maximum value of order is 32.
+ * - when SSE4 (or newer) is available on x86 there is an unrolled copy
+ * which also assumes the maximum value of order is 0.
+ */
void (*lpc_encode)(int32_t *res, const int32_t *smp, int len, int order,
const int32_t *coefs, int shift);
} FLACDSPContext;
--
1.7.9
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] lavc/flacenc: add sse4 version of the 16-bit lpc encoder
>From 1.8 to 2.4 times faster. Runtime is reduced by 2 to 39%. The
speed-up generally increases with compression_level.
This lpc encoder is not used with levels < 3 so it provides no speed-up
in these cases.
---
LICENSE.md |1 +
libavcodec/flacenc.c|2 +-
libavcodec/x86/Makefile |3 +
libavcodec/x86/flac_dsp_gpl.asm | 85 +++
libavcodec/x86/flacdsp_init.c |4 ++
5 files changed, 94 insertions(+), 1 deletions(-)
create mode 100644 libavcodec/x86/flac_dsp_gpl.asm
diff --git a/LICENSE.md b/LICENSE.md
index 04decbf..e78d932 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -15,6 +15,7 @@ Specifically, the GPL parts of FFmpeg are:
- libpostproc
- libmpcodecs
- optional x86 optimizations in the files
+ libavcodec/x86/flac_dsp_gpl.asm
libavcodec/x86/idct_mmx.c
- libutvideo encoding/decoding wrappers in
libavcodec/libutvideo*.cpp
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 3a3b2ae..f37bab8 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -80,7 +80,7 @@ typedef struct FlacSubframe {
int shift;
RiceContext rc;
int32_t samples[FLAC_MAX_BLOCKSIZE];
-int32_t residual[FLAC_MAX_BLOCKSIZE+1];
+int32_t residual[FLAC_MAX_BLOCKSIZE+3];
} FlacSubframe;
typedef struct FlacFrame {
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 53e643b..4298262 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -83,6 +83,9 @@ YASM-OBJS-$(CONFIG_DIRAC_DECODER) += x86/diracdsp_mmx.o
x86/diracdsp_yasm.o
YASM-OBJS-$(CONFIG_DNXHD_ENCODER) += x86/dnxhdenc.o
YASM-OBJS-$(CONFIG_FFT)+= x86/fft.o
YASM-OBJS-$(CONFIG_FLAC_DECODER) += x86/flacdsp.o
+ifdef CONFIG_GPL
+YASM-OBJS-$(CONFIG_FLAC_ENCODER) += x86/flac_dsp_gpl.o
+endif
YASM-OBJS-$(CONFIG_H263DSP)+= x86/h263_loopfilter.o
YASM-OBJS-$(CONFIG_H264CHROMA) += x86/h264_chromamc.o \
x86/h264_chromamc_10bit.o
diff --git a/libavcodec/x86/flac_dsp_gpl.asm b/libavcodec/x86/flac_dsp_gpl.asm
new file mode 100644
index 000..1f28be1
--- /dev/null
+++ b/libavcodec/x86/flac_dsp_gpl.asm
@@ -0,0 +1,85 @@
+;**
+;* FLAC DSP functions
+;*
+;* Copyright (c) 2014 James Darnley
+;*
+;* This file is part of FFmpeg.
+;*
+;* FFmpeg is free software; you can redistribute it and/or modify
+;* it under the terms of the GNU General Public License as published by
+;* the Free Software Foundation; either version 2 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 General Public License for more details.
+;*
+;* You should have received a copy of the GNU General Public License along
+;* with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+;* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+;**
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION_TEXT
+
+INIT_XMM sse4
+%if ARCH_X86_64
+cglobal flac_enc_lpc_16, 5, 7, 4, 0, res, smp, len, order, coefs
+DECLARE_REG_TMP 5, 6
+%define length r2d
+
+movsxd orderq, orderd
+%else
+cglobal flac_enc_lpc_16, 5, 6, 4, 0, res, smp, len, order, coefs
+DECLARE_REG_TMP 2, 5
+%define length r2mp
+%endif
+
+; Here we assume that the maximum order value is 32. This means that we only
+; need to copy a maximum of 32 samples. Therefore we let the preprocessor
+; unroll this loop and copy all 32.
+%assign iter 0
+%rep 32/(mmsize/4)
+movu m0, [smpq+iter]
+movu [resq+iter], m0
+%assign iter iter+mmsize
+%endrep
+
+lea resq, [resq+orderq*4]
+lea smpq, [smpq+orderq*4]
+lea coefsq, [coefsq+orderq*4]
+sub length, orderd
+movd m3, r5m
+neg orderq
+
+%define posj t0q
+%define negj t1q
+
+.looplen:
+pxor m0, m0
+mov posj, orderq
+xor negj, negj
+
+.looporder:
+movd m2, [coefsq+posj*4] ; c = coefs[j]
+SPLATD m2
+movu m1, [smpq+negj*4-4] ; s = smp[i-j-1]
+pmulld m1, m2
+paddd m0, m1 ; p += c * s
+
+decnegj
+incposj
+jnz .looporder
+
+psrad m0, m3 ; p >>= shift
+movu m1,[smpq]
+psubd m1, m0 ; smp[i] - p
+movu [resq], m1 ; res[i] = smp[i] - (p >> shift)
+
+add resq, mmsize
+add smpq, mmsize
+sub length, mmsize/4
+jg .looplen
+RET
diff --git a/libavcodec/x86/flacdsp_init.c b/libavcodec/x86/flacdsp_init.c
index a071b3d..ad88e5b 100644
--- a/libavcodec/x86/flacdsp_init.c
+++ b/libavcodec/x86/flacdsp_init.c
@@ -27,6 +27,8 @@ void ff_flac_lpc_32_sse4(int32_
[FFmpeg-devel] [PATCH 3/6] lavc/flacenc: add sse42 version of the 32-bit lpc encoder
>From 1.3 to 2.5 times faster. Runtime reduced by 4 to 58%. As with the
16-bit version the speed-up generally increases with compression_level.
Also like the 16-bit version, it is not used with levels less than 3.
---
libavcodec/x86/flac_dsp_gpl.asm | 101 +++
libavcodec/x86/flacdsp_init.c |5 ++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/libavcodec/x86/flac_dsp_gpl.asm b/libavcodec/x86/flac_dsp_gpl.asm
index cedf083..7a49fae 100644
--- a/libavcodec/x86/flac_dsp_gpl.asm
+++ b/libavcodec/x86/flac_dsp_gpl.asm
@@ -22,6 +22,12 @@
%include "libavutil/x86/x86util.asm"
+SECTION_RODATA
+
+pd_0_int_min: times 2 dd 0, -2147483648
+pq_int_min: times 2 dq -2147483648
+pq_int_max: times 2 dq 2147483647
+
SECTION_TEXT
INIT_XMM sse4
@@ -99,3 +105,98 @@ neg orderq
sub length, (3*mmsize)/4
jg .looplen
RET
+
+%macro PMINSQ 3
+pcmpgtq %3, %2, %1
+pand%1, %3
+pandn %3, %2
+por %1, %3
+%endmacro
+
+%macro PMAXSQ 3
+pcmpgtq %3, %1, %2
+pand%1, %3
+pandn %3, %2
+por %1, %3
+%endmacro
+
+%macro CLIPQ 4 ; reg, min, max, tmp
+PMAXSQ %1, %2, %4
+PMINSQ %1, %3, %4
+%endmacro
+
+%macro HACK_PSRAQ 4 ; dst, src (shift), sign extend mask, tmp
+pxor%4, %4 ; zero
+pcmpgtq %4, %1 ; mask where 0 > dst
+pand%4, %3 ; mask & sign extend mask
+psrlq %1, %2 ; dst >>= shift
+por %1, %4 ; dst | mask
+%endmacro
+
+INIT_XMM sse42
+%if ARCH_X86_64
+cglobal flac_enc_lpc_32, 5, 7, 4, mmsize, res, smp, len, order, coefs
+DECLARE_REG_TMP 5, 6
+%define length r2d
+
+movsxd orderq, orderd
+%else
+cglobal flac_enc_lpc_32, 5, 6, 4, mmsize, res, smp, len, order, coefs
+DECLARE_REG_TMP 2, 5
+%define length r2mp
+%endif
+
+; Here we assume that the maximum order value is 32. This means that we only
+; need to copy a maximum of 32 samples. Therefore we let the preprocessor
+; unroll this loop and copy all 32.
+%assign iter 0
+%rep 32/(mmsize/4)
+movu m0, [smpq+iter]
+movu [resq+iter], m0
+%assign iter iter+mmsize
+%endrep
+
+learesq, [resq+orderq*4]
+leasmpq, [smpq+orderq*4]
+leacoefsq, [coefsq+orderq*4]
+sublength, orderd
+movd m3, r5m
+negorderq
+
+movu m4, [pd_0_int_min] ; load 1 bit
+psrad m4, m3; turn that into shift+1 bits
+pslld m4, 1 ; reduce that
+mova [rsp],m4; save sign extend mask
+
+%define posj t0q
+%define negj t1q
+
+.looplen:
+pxor m0, m0
+mov posj, orderq
+xor negj, negj
+
+.looporder:
+movd m2, [coefsq+posj*4] ; c = coefs[j]
+SPLATD m2
+movh m1, [smpq+negj*4-4] ; s = smp[i-j-1]
+pshufd m1, m1, q3130
+pmuldq m1, m2
+paddq m0, m1 ; p += c * s
+
+decnegj
+incposj
+jnz .looporder
+
+HACK_PSRAQ m0, m3, [rsp], m2; p >>= shift
+CLIPQ m0, [pq_int_min], [pq_int_max], m2 ; clip(p >> shift)
+pshufd m0,m0, q0020 ; pack into first 2 dwords
+movhm1, [smpq]
+psubd m1,m0 ; smp[i] - p
+movh [resq], m1 ; res[i] = smp[i] - (p >> shift)
+
+add resq, mmsize/2
+add smpq, mmsize/2
+sub length, mmsize/8
+jg .looplen
+RET
diff --git a/libavcodec/x86/flacdsp_init.c b/libavcodec/x86/flacdsp_init.c
index ad88e5b..976ea2c 100644
--- a/libavcodec/x86/flacdsp_init.c
+++ b/libavcodec/x86/flacdsp_init.c
@@ -28,6 +28,7 @@ void ff_flac_lpc_32_xop(int32_t *samples, const int
coeffs[32], int order,
int qlevel, int len);
void ff_flac_enc_lpc_16_sse4(int32_t *, const int32_t *, int, int, const
int32_t *,int);
+void ff_flac_enc_lpc_32_sse42(int32_t *, const int32_t *, int, int, const
int32_t *,int);
av_cold void ff_flacdsp_init_x86(FLACDSPContext *c, enum AVSampleFormat fmt,
int bps)
@@ -45,5 +46,9 @@ av_cold void ff_flacdsp_init_x86(FLACDSPContext *c, enum
AVSampleFormat fmt,
if (bps > 16 && CONFIG_FLAC_DECODER)
c->lpc = ff_flac_lpc_32_xop;
}
+if (EXTERNAL_SSE42(cpu_flags)) {
+if (bps > 16 && CONFIG_FLAC_ENCODER && CONFIG_GPL)
+c->lpc_encode = ff_flac_enc_lpc_32_sse42;
+}
#endif
}
--
1.7.9
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] lavc/flacenc: partially unroll loop in flac_enc_lpc_16
It now does 12 samples per iteration, up from 4.
>From 1.8 to 3.2 times faster again. 3.6 to 5.7 times faster overall.
Runtime is reduced by a further 2 to 18%. Overall runtime reduced by
4 to 50%.
Same conditions as before apply.
---
libavcodec/flacenc.c|2 +-
libavcodec/x86/flac_dsp_gpl.asm | 26 +-
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index f37bab8..3b72888 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -80,7 +80,7 @@ typedef struct FlacSubframe {
int shift;
RiceContext rc;
int32_t samples[FLAC_MAX_BLOCKSIZE];
-int32_t residual[FLAC_MAX_BLOCKSIZE+3];
+int32_t residual[FLAC_MAX_BLOCKSIZE+11];
} FlacSubframe;
typedef struct FlacFrame {
diff --git a/libavcodec/x86/flac_dsp_gpl.asm b/libavcodec/x86/flac_dsp_gpl.asm
index 1f28be1..cedf083 100644
--- a/libavcodec/x86/flac_dsp_gpl.asm
+++ b/libavcodec/x86/flac_dsp_gpl.asm
@@ -26,13 +26,13 @@ SECTION_TEXT
INIT_XMM sse4
%if ARCH_X86_64
-cglobal flac_enc_lpc_16, 5, 7, 4, 0, res, smp, len, order, coefs
+cglobal flac_enc_lpc_16, 5, 7, 8, 0, res, smp, len, order, coefs
DECLARE_REG_TMP 5, 6
%define length r2d
movsxd orderq, orderd
%else
-cglobal flac_enc_lpc_16, 5, 6, 4, 0, res, smp, len, order, coefs
+cglobal flac_enc_lpc_16, 5, 6, 8, 0, res, smp, len, order, coefs
DECLARE_REG_TMP 2, 5
%define length r2mp
%endif
@@ -59,6 +59,8 @@ neg orderq
.looplen:
pxor m0, m0
+pxor m4, m4
+pxor m6, m6
mov posj, orderq
xor negj, negj
@@ -66,20 +68,34 @@ neg orderq
movd m2, [coefsq+posj*4] ; c = coefs[j]
SPLATD m2
movu m1, [smpq+negj*4-4] ; s = smp[i-j-1]
+movu m5, [smpq+negj*4-4+mmsize]
+movu m7, [smpq+negj*4-4+mmsize*2]
pmulld m1, m2
+pmulld m5, m2
+pmulld m7, m2
paddd m0, m1 ; p += c * s
+paddd m4, m5
+paddd m6, m7
decnegj
incposj
jnz .looporder
psrad m0, m3 ; p >>= shift
+psrad m4, m3
+psrad m6, m3
movu m1,[smpq]
+movu m5,[smpq+mmsize]
+movu m7,[smpq+mmsize*2]
psubd m1, m0 ; smp[i] - p
+psubd m5, m4
+psubd m7, m6
movu [resq], m1 ; res[i] = smp[i] - (p >> shift)
+movu [resq+mmsize], m5
+movu [resq+mmsize*2], m7
-add resq, mmsize
-add smpq, mmsize
-sub length, mmsize/4
+add resq,3*mmsize
+add smpq,3*mmsize
+sub length, (3*mmsize)/4
jg .looplen
RET
--
1.7.9
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] cosmetic fix
--- libavcodec/flacdsp_lpc_template.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libavcodec/flacdsp_lpc_template.c b/libavcodec/flacdsp_lpc_template.c index acdac04..5d532e0 100644 --- a/libavcodec/flacdsp_lpc_template.c +++ b/libavcodec/flacdsp_lpc_template.c @@ -154,6 +154,6 @@ static void FUNC(flac_lpc_encode_c)(int32_t *res, const int32_t *smp, int len, * * The CONFIG_SMALL code above simplifies to this, in the case of SAMPLE_SIZE * not being equal to 32 (at the present time that means for 16-bit audio). The - * code above does 2 samples per iteration. Commit bfdd5bc ( made all the way + * code above does 2 samples per iteration. Commit bfdd5bc (made all the way * back in 2007) says that way is faster. */ -- 1.7.9 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi: duplicate ff_log2_tab
Fixes compilation failures on msvc/icl shared builds Signed-off-by: James Almer --- libavfilter/Makefile | 1 + libavfilter/log2_tab.c | 1 + 2 files changed, 2 insertions(+) create mode 100644 libavfilter/log2_tab.c diff --git a/libavfilter/Makefile b/libavfilter/Makefile index e9c8456..7486f96 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -244,6 +244,7 @@ SKIPHEADERS-$(CONFIG_LIBVIDSTAB) += vidstabutils.h SKIPHEADERS-$(CONFIG_OPENCL) += opencl_internal.h deshake_opencl_kernel.h unsharp_opencl_kernel.h OBJS-$(HAVE_THREADS) += pthread.o +OBJS-$(CONFIG_SHARED)+= log2_tab.o TOOLS = graph2dot TESTPROGS = drawutils filtfmts formats diff --git a/libavfilter/log2_tab.c b/libavfilter/log2_tab.c new file mode 100644 index 000..47a1df0 --- /dev/null +++ b/libavfilter/log2_tab.c @@ -0,0 +1 @@ +#include "libavutil/log2_tab.c" -- 1.8.5.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] added ULs for demuxing avid media composer mxf files
UL values copied from FMbc version of mxf.c
Fixes Ticket#1554, Ticket#3100 and Ticket#3450
---
libavformat/mxf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index d20ed94..8ebfdf2 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -28,6 +28,8 @@
const MXFCodecUL ff_mxf_data_definition_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x01,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_VIDEO },
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x02,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_AUDIO },
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x6F,0x3C,0x8C,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_VIDEO }, /* Avid Media Composer MXF */
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x78,0xE1,0xEB,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_AUDIO }, /* Avid Media Composer MXF */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVMEDIA_TYPE_DATA },
};
@@ -44,6 +46,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x01,0x00
}, 15, AV_CODEC_ID_RAWVIDEO }, /* Uncompressed 422 8-bit */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00
}, 13, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x03,0x02,0x00,0x00
}, 14, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x04,0x01,0x00
}, 16, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD Avid Media Composer MXF */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x00,0x00
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC Intra */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
}, 16, AV_CODEC_ID_V210 }, /* V210 */
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] added ULs for demuxing avid media composer mxf files
Changes since v1: * add more descriptive commit message Mark Reid (1): added ULs for demuxing avid media composer mxf files libavformat/mxf.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: ignore reference segmentation map if error_resilience flag is set.
Fixes ffvp9_fails_where_libvpx.succeeds.webm from ticket 3849.
---
libavcodec/vp9.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 56975bd..186aec1 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -278,7 +278,7 @@ static int vp9_alloc_frame(AVCodecContext *ctx, VP9Frame *f)
// retain segmentation map if it doesn't update
if (s->segmentation.enabled && !s->segmentation.update_map &&
-!s->intraonly && !s->keyframe) {
+!s->intraonly && !s->keyframe && !s->errorres) {
memcpy(f->segmentation_map, s->frames[LAST_FRAME].segmentation_map,
sz);
}
@@ -1344,16 +1344,20 @@ static void decode_mode(AVCodecContext *ctx)
vp56_rac_get_prob_branchy(&s->c,
s->prob.segpred[s->above_segpred_ctx[col] +
s->left_segpred_ctx[row7]]))) {
-int pred = 8, x;
-uint8_t *refsegmap = s->frames[LAST_FRAME].segmentation_map;
-
-if (!s->last_uses_2pass)
-ff_thread_await_progress(&s->frames[LAST_FRAME].tf, row >> 3, 0);
-for (y = 0; y < h4; y++)
-for (x = 0; x < w4; x++)
-pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols + x +
col]);
-av_assert1(pred < 8);
-b->seg_id = pred;
+if (!s->errorres) {
+int pred = 8, x;
+uint8_t *refsegmap = s->frames[LAST_FRAME].segmentation_map;
+
+if (!s->last_uses_2pass)
+ff_thread_await_progress(&s->frames[LAST_FRAME].tf, row >> 3,
0);
+for (y = 0; y < h4; y++)
+for (x = 0; x < w4; x++)
+pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols +
x + col]);
+av_assert1(pred < 8);
+b->seg_id = pred;
+} else {
+b->seg_id = 0;
+}
memset(&s->above_segpred_ctx[col], 1, w4);
memset(&s->left_segpred_ctx[row7], 1, h4);
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, Aug 12, 2014 at 09:45:37PM +0200, Attila Kinali wrote: > On Tue, 12 Aug 2014 10:44:35 -0500 > Joe Neal wrote: > > > > When this happened I scoured the net, including mailing lists from both > > projects to try and figure out what had happened. The overwhelming > > evidence based on mailing list posts, blog posts, forum discussions and > > pretty much everywhere else I could look all led me to the overwhelming > > conclusion of what I stated before. This is the only time I've ever > > seen anything to the contrary stated and I looked good and hard for > > another side of the story, as have many other people. > > Part of the reason for this is that the people around libav decided > that they didn't want to participate in the mudslinging. Only the most > blatant lies were refuted and all the name calling was mostly ignored. > In hindsight that was a mistake. > > > I still don't know who is in the right, but at least you've put an end > > to the weirdness where only one side of the story existed on the net > > and there was just conspicuous silence on the other. > > I'd like to give here a short account on what happend before the split, > even though this not the right place. I think i should write up something > longer after my vacations and put it somewhere online. > > Before 2011 there were quite a few issues within FFmpeg. Most of those > revolved around Michael Niedermayer playing by his own set of rules > and ignoring the advise of everyone else. His behaviour has resulted > in quite a bit of ... anger.. to put it mildly. A few people left because > of him. Heck, even i wanted to leave everything that was related to > FFmpeg in any way, even though all i did was keeping the server running > and was not involved in the development or anything else at all. Its a long time ago, but IIRC when i asked about what rules it was that where broken back then it was a mix of silence and someone who admited he mixed the rules of FFmpeg up with another project. Also ive offered my resignation in the past. I do still offer to resign from the FFmpeg leader position, if it resolves this split between FFmpeg and Libav and make everyone work together again. I never understood why people who once where friends became mutually so hostile The part i insist on though is that everyone must be able to work on their code without people uninvolved in that specific parts maintaince or authorship being able to block their work. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs
On 11/08/14 11:33 PM, Michael Niedermayer wrote:
> Its API is marked as experimental, we should not export experimental API
> from shared libs
>
> Signed-off-by: Michael Niedermayer
> ---
> configure |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 0ac6132..84d308e 100755
> --- a/configure
> +++ b/configure
> @@ -4861,7 +4861,9 @@ enabled opencl&& { check_lib2 OpenCL/cl.h
> clEnqueueNDRangeKernel -Wl
> die "ERROR: opencl not found"; } &&
> { check_cpp_condition "OpenCL/cl.h"
> "defined(CL_VERSION_1_2)" ||
> check_cpp_condition "CL/cl.h"
> "defined(CL_VERSION_1_2)" ||
> - die "ERROR: opencl must be installed and
> version must be 1.2 or compatible"; }
> + die "ERROR: opencl must be installed and
> version must be 1.2 or compatible"; } &&
> + { enabled shared &&
> + die "ERROR OpenCL API is experimental and not
> safe to be used with shared libs"; }
> enabled opengl&& { check_lib GL/glx.h glXGetProcAddress "-lGL" ||
> check_lib2 windows.h wglGetProcAddress
> "-lopengl32 -lgdi32" ||
> check_lib2 OpenGL/gl3.h glGetError
> "-Wl,-framework,OpenGL" ||
>
The API hasn't been touched in several months and is functional, and
considering
distros already link to opencl if available in previous ffmpeg releases, i
don't
know if removing the feature like this is a good idea.
Of course they can just remove this check and keep using opencl if they want
to,
but that's besides the point.
Maybe a warning instead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 14:04:32 -0400 compn wrote: > at least 6+ devels refuse to work with each other , thats only a > quick estimation, i havent polled everyone lately. ffmpeg and libav devs > dont even TALK to each other. theres a couple devs who frequent both > irc/lists, most do not. This is not entirely true. There are people who talk to eachother. But it is mostly kept under wraps as some zealots think that talking to "the others" is a mortal sin and anyone who does it needs to be punished. Heck, i remember how i was sitting with some FFmpeg guys during lunch at the Videolan Developers Days last year. We had some discussion going on, nothing serious, mostly smalltalk, but still a discussion. When Diego Biurrun joined our table everyone suddenly fell silent. It felt like being in some second rate sitcom... But that's personal issues between the developers and does not belong to debian-devel. > i wrote up a current status of the projects, > http://wiki.multimedia.cx/index.php?title=User_talk:Compn Thanks for writing that up. There are certain things i would like to add there or write diffently, but i will contact you off list for that. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/idctdsp: make add/put_pixels_clamped_c internal functions
On Tue, Aug 12, 2014 at 06:22:24PM -0300, James Almer wrote: > This reduces code duplication and differences with the fork. > > Signed-off-by: James Almer > --- > libavcodec/idctdsp.c | 49 + > libavcodec/idctdsp.h | 46 +- > libavcodec/xvididct.c | 4 ++-- > 3 files changed, 52 insertions(+), 47 deletions(-) breaks arm libavcodec/arm/idctdsp_init_arm.c:33:15: error: ‘ff_put_pixels_clamped’ redeclared as different kind of symbol libavcodec/idctdsp.h:51:6: note: previous declaration of ‘ff_put_pixels_clamped’ was here libavcodec/arm/idctdsp_init_arm.c:34:15: error: ‘ff_add_pixels_clamped’ redeclared as different kind of symbol libavcodec/idctdsp.h:53:6: note: previous declaration of ‘ff_add_pixels_clamped’ was here [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: duplicate ff_log2_tab
On Tue, Aug 12, 2014 at 06:38:32PM -0300, James Almer wrote: > Fixes compilation failures on msvc/icl shared builds > > Signed-off-by: James Almer > --- > libavfilter/Makefile | 1 + > libavfilter/log2_tab.c | 1 + > 2 files changed, 2 insertions(+) > create mode 100644 libavfilter/log2_tab.c 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] configure: disallow OpenCL with shared libs
On Tue, Aug 12, 2014 at 07:31:58PM -0300, James Almer wrote:
> On 11/08/14 11:33 PM, Michael Niedermayer wrote:
> > Its API is marked as experimental, we should not export experimental API
> > from shared libs
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > configure |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index 0ac6132..84d308e 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4861,7 +4861,9 @@ enabled opencl&& { check_lib2 OpenCL/cl.h
> > clEnqueueNDRangeKernel -Wl
> > die "ERROR: opencl not found"; } &&
> > { check_cpp_condition "OpenCL/cl.h"
> > "defined(CL_VERSION_1_2)" ||
> > check_cpp_condition "CL/cl.h"
> > "defined(CL_VERSION_1_2)" ||
> > - die "ERROR: opencl must be installed and
> > version must be 1.2 or compatible"; }
> > + die "ERROR: opencl must be installed and
> > version must be 1.2 or compatible"; } &&
> > + { enabled shared &&
> > + die "ERROR OpenCL API is experimental and
> > not safe to be used with shared libs"; }
> > enabled opengl&& { check_lib GL/glx.h glXGetProcAddress "-lGL"
> > ||
> > check_lib2 windows.h wglGetProcAddress
> > "-lopengl32 -lgdi32" ||
> > check_lib2 OpenGL/gl3.h glGetError
> > "-Wl,-framework,OpenGL" ||
> >
>
> The API hasn't been touched in several months and is functional, and
> considering
> distros already link to opencl if available in previous ffmpeg releases, i
> don't
> know if removing the feature like this is a good idea.
> Of course they can just remove this check and keep using opencl if they want
> to,
> but that's besides the point.
>
> Maybe a warning instead?
The question is if people intend to change the API and IIRC its
design makes it hard to make changes without breaking ABI
i can add a warning if preferred but i think we either should
choose to support the ABI/API until the next bump which wouldnt
need a warning or not support it in which case we probably should
disable it hard for shared libs or put a warning in the release notes
where its hard to miss
[...]
--
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] avcodec/idctdsp: make add/put_pixels_clamped_c internal functions
This reduces code duplication and differences with the fork.
Signed-off-by: James Almer
---
Fix for the ARM hack untested.
libavcodec/arm/idctdsp_init_arm.c | 16 ++---
libavcodec/idctdsp.c | 49 +++
libavcodec/idctdsp.h | 46
libavcodec/xvididct.c | 4 ++--
4 files changed, 60 insertions(+), 55 deletions(-)
diff --git a/libavcodec/arm/idctdsp_init_arm.c
b/libavcodec/arm/idctdsp_init_arm.c
index 578697e..0a983bf 100644
--- a/libavcodec/arm/idctdsp_init_arm.c
+++ b/libavcodec/arm/idctdsp_init_arm.c
@@ -30,8 +30,8 @@
#include "idctdsp_arm.h"
/* XXX: local hack */
-static void (*ff_put_pixels_clamped)(const int16_t *block, uint8_t *pixels,
int line_size);
-static void (*ff_add_pixels_clamped)(const int16_t *block, uint8_t *pixels,
int line_size);
+static void (*put_pixels_clamped)(const int16_t *block, uint8_t *pixels, int
line_size);
+static void (*add_pixels_clamped)(const int16_t *block, uint8_t *pixels, int
line_size);
void ff_add_pixels_clamped_arm(const int16_t *block, uint8_t *dest,
int line_size);
@@ -41,25 +41,25 @@ void ff_add_pixels_clamped_arm(const int16_t *block,
uint8_t *dest,
static void j_rev_dct_arm_put(uint8_t *dest, int line_size, int16_t *block)
{
ff_j_rev_dct_arm(block);
-ff_put_pixels_clamped(block, dest, line_size);
+put_pixels_clamped(block, dest, line_size);
}
static void j_rev_dct_arm_add(uint8_t *dest, int line_size, int16_t *block)
{
ff_j_rev_dct_arm(block);
-ff_add_pixels_clamped(block, dest, line_size);
+add_pixels_clamped(block, dest, line_size);
}
static void simple_idct_arm_put(uint8_t *dest, int line_size, int16_t *block)
{
ff_simple_idct_arm(block);
-ff_put_pixels_clamped(block, dest, line_size);
+put_pixels_clamped(block, dest, line_size);
}
static void simple_idct_arm_add(uint8_t *dest, int line_size, int16_t *block)
{
ff_simple_idct_arm(block);
-ff_add_pixels_clamped(block, dest, line_size);
+add_pixels_clamped(block, dest, line_size);
}
av_cold void ff_idctdsp_init_arm(IDCTDSPContext *c, AVCodecContext *avctx,
@@ -67,8 +67,8 @@ av_cold void ff_idctdsp_init_arm(IDCTDSPContext *c,
AVCodecContext *avctx,
{
int cpu_flags = av_get_cpu_flags();
-ff_put_pixels_clamped = c->put_pixels_clamped;
-ff_add_pixels_clamped = c->add_pixels_clamped;
+put_pixels_clamped = c->put_pixels_clamped;
+add_pixels_clamped = c->add_pixels_clamped;
if (!avctx->lowres && !high_bit_depth) {
if ((avctx->idct_algo == FF_IDCT_AUTO && !(avctx->flags &
CODEC_FLAG_BITEXACT)) ||
diff --git a/libavcodec/idctdsp.c b/libavcodec/idctdsp.c
index 4ca0734..f139bac 100644
--- a/libavcodec/idctdsp.c
+++ b/libavcodec/idctdsp.c
@@ -80,6 +80,27 @@ av_cold void ff_init_scantable_permutation(uint8_t
*idct_permutation,
}
}
+void ff_put_pixels_clamped(const int16_t *block, uint8_t *av_restrict pixels,
+ int line_size)
+{
+int i;
+
+/* read the pixels */
+for (i = 0; i < 8; i++) {
+pixels[0] = av_clip_uint8(block[0]);
+pixels[1] = av_clip_uint8(block[1]);
+pixels[2] = av_clip_uint8(block[2]);
+pixels[3] = av_clip_uint8(block[3]);
+pixels[4] = av_clip_uint8(block[4]);
+pixels[5] = av_clip_uint8(block[5]);
+pixels[6] = av_clip_uint8(block[6]);
+pixels[7] = av_clip_uint8(block[7]);
+
+pixels += line_size;
+block += 8;
+}
+}
+
static void put_pixels_clamped4_c(const int16_t *block, uint8_t *av_restrict
pixels,
int line_size)
{
@@ -133,6 +154,26 @@ static void put_signed_pixels_clamped_c(const int16_t
*block,
}
}
+void ff_add_pixels_clamped(const int16_t *block, uint8_t *av_restrict pixels,
+ int line_size)
+{
+int i;
+
+/* read the pixels */
+for (i = 0; i < 8; i++) {
+pixels[0] = av_clip_uint8(pixels[0] + block[0]);
+pixels[1] = av_clip_uint8(pixels[1] + block[1]);
+pixels[2] = av_clip_uint8(pixels[2] + block[2]);
+pixels[3] = av_clip_uint8(pixels[3] + block[3]);
+pixels[4] = av_clip_uint8(pixels[4] + block[4]);
+pixels[5] = av_clip_uint8(pixels[5] + block[5]);
+pixels[6] = av_clip_uint8(pixels[6] + block[6]);
+pixels[7] = av_clip_uint8(pixels[7] + block[7]);
+pixels += line_size;
+block+= 8;
+}
+}
+
static void add_pixels_clamped4_c(const int16_t *block, uint8_t *av_restrict
pixels,
int line_size)
{
@@ -166,13 +207,13 @@ static void add_pixels_clamped2_c(const int16_t *block,
uint8_t *av_restrict pix
static void jref_idct_put(uint8_t *dest, int line_size, int16_t *block)
{
ff_j_rev_dct(block);
-put_pixels_clamped_c(block, dest, line_size);
+ff_put_pixels_clamped(block, dest, line_size);
}
static
Re: [FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs
On 12/08/14 8:13 PM, Michael Niedermayer wrote:
> On Tue, Aug 12, 2014 at 07:31:58PM -0300, James Almer wrote:
>> On 11/08/14 11:33 PM, Michael Niedermayer wrote:
>>> Its API is marked as experimental, we should not export experimental API
>>> from shared libs
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> configure |4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 0ac6132..84d308e 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -4861,7 +4861,9 @@ enabled opencl&& { check_lib2 OpenCL/cl.h
>>> clEnqueueNDRangeKernel -Wl
>>> die "ERROR: opencl not found"; } &&
>>> { check_cpp_condition "OpenCL/cl.h"
>>> "defined(CL_VERSION_1_2)" ||
>>> check_cpp_condition "CL/cl.h"
>>> "defined(CL_VERSION_1_2)" ||
>>> - die "ERROR: opencl must be installed and
>>> version must be 1.2 or compatible"; }
>>> + die "ERROR: opencl must be installed and
>>> version must be 1.2 or compatible"; } &&
>>> + { enabled shared &&
>>> + die "ERROR OpenCL API is experimental and
>>> not safe to be used with shared libs"; }
>>> enabled opengl&& { check_lib GL/glx.h glXGetProcAddress "-lGL"
>>> ||
>>> check_lib2 windows.h wglGetProcAddress
>>> "-lopengl32 -lgdi32" ||
>>> check_lib2 OpenGL/gl3.h glGetError
>>> "-Wl,-framework,OpenGL" ||
>>>
>>
>> The API hasn't been touched in several months and is functional, and
>> considering
>> distros already link to opencl if available in previous ffmpeg releases, i
>> don't
>> know if removing the feature like this is a good idea.
>> Of course they can just remove this check and keep using opencl if they want
>> to,
>> but that's besides the point.
>>
>> Maybe a warning instead?
>
> The question is if people intend to change the API and IIRC its
> design makes it hard to make changes without breaking ABI
OpenCL maintainers should probably chime in at this point. CCing Wei Gao then.
>
> i can add a warning if preferred but i think we either should
> choose to support the ABI/API until the next bump which wouldnt
> need a warning or not support it in which case we probably should
> disable it hard for shared libs or put a warning in the release notes
> where its hard to miss
A warning in release notes and in the configure script is IMO preferable than
disabling existing functionality, but i'm fine doing whatever causes the less
headaches for everyone.
>
> [...]
>
>
>
> ___
> 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] added ULs for demuxing avid media composer mxf files
On Aug 12, 2014 10:41 AM, "Mark Reid" wrote: > I got the ULs from FMbc version of mxf.c Isn't FFmbc GPL? You can't use GPL code in LGPL code unless it is not copyrightable (which ULs probably are, IANAL) or you have author consent. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] lavc/flacenc: add sse4 version of the 16-bit lpc encoder
On Tue, Aug 12, 2014 at 11:22:02PM +0200, James Darnley wrote: > From 1.8 to 2.4 times faster. Runtime is reduced by 2 to 39%. The > speed-up generally increases with compression_level. > > This lpc encoder is not used with levels < 3 so it provides no speed-up > in these cases. > --- > LICENSE.md |1 + > libavcodec/flacenc.c|2 +- > libavcodec/x86/Makefile |3 + > libavcodec/x86/flac_dsp_gpl.asm | 85 > +++ > libavcodec/x86/flacdsp_init.c |4 ++ > 5 files changed, 94 insertions(+), 1 deletions(-) > create mode 100644 libavcodec/x86/flac_dsp_gpl.asm applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
> Also ive offered my resignation in the past. > I do still offer to resign from the FFmpeg leader position, if it > resolves this split between FFmpeg and Libav and make everyone work > together again. I never understood why people who once where friends > became mutually so hostile The big elephant in the room in any discussion about even moving an iota in the direction of something resembling a resolution is that you as FFmpeg leader are a hidden leader. Every year at VDD when there is any informal discussion of any reconciliation as Attila alludes to the line "we can't get anywhere since Michael isn't here" is uttered and then everyone moves on. Things have changed a lot in the 3.5 years since the split but since you never show your face and because many libav people don't follow FFmpeg they just imagine conditions to be the same and remember the same anger that caused all this. Yes there is a lot of anger around still but meeting in person dampens things. Lets be honest, Google is definitely FFmpeg home turf, at previous VDDs there were plenty of FFmpeg people and J-b has offered to pay your travel/accommodation etc for many years - there is literally nothing more that they could do beyond hosting a conference at your home. Every year however, it's always silence when talking about this to you. I appreciate you may not want to meet people face to face but if you are seriously interested in moving in the right direction this is the *ONLY* way forward and I cannot stress this more. I suspect you won't hear it publicly but it's fair to say that this view is unanimous on both sides of the fence - if you're physically not there nothing will change and we'll all have to waste stupid amounts of time dealing with the current state. Whatever, people can work on their own code happily but the rest of the world (cf this thread) has to deal with this annoying FFmpeg/libav madness. Getting it into Debian isn't going to change much (I get the feeling some FFmpeg people expect it to be a massive game-changer of some sort). (of course this is going to get me lots of angry private messages and emails like the last set of emails) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/idctdsp: make add/put_pixels_clamped_c internal functions
On Tue, Aug 12, 2014 at 08:19:24PM -0300, James Almer wrote: > This reduces code duplication and differences with the fork. > > Signed-off-by: James Almer > --- > Fix for the ARM hack untested. > > libavcodec/arm/idctdsp_init_arm.c | 16 ++--- > libavcodec/idctdsp.c | 49 > +++ > libavcodec/idctdsp.h | 46 > libavcodec/xvididct.c | 4 ++-- > 4 files changed, 60 insertions(+), 55 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- 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] added ULs for demuxing avid media composer mxf files
On Tue, Aug 12, 2014 at 4:36 PM, Timothy Gu wrote: > On Aug 12, 2014 10:41 AM, "Mark Reid" wrote: > > > I got the ULs from FMbc version of mxf.c > > Isn't FFmbc GPL? You can't use GPL code in LGPL code unless it is not > copyrightable (which ULs probably are, IANAL) or you have author consent. I didn't realize FFmbc was licensed differently :s. I don't know if it helps, (IANAL either) but the same ULs can be found in libMXF project, as well as the AAF SDK. I'm not sure how to proceed, should I just drop the patch? > [...] > > Timothy > ___ > 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] configure: disallow OpenCL with shared libs
highgod0401
From: James Almer
Date: 2014-08-13 07:28
To: FFmpeg development discussions and patches
CC: highgod0401; weigao
Subject: Re: [FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs
On 12/08/14 8:13 PM, Michael Niedermayer wrote:
> On Tue, Aug 12, 2014 at 07:31:58PM -0300, James Almer wrote:
>> On 11/08/14 11:33 PM, Michael Niedermayer wrote:
>>> Its API is marked as experimental, we should not export experimental API
>>> from shared libs
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> configure |4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 0ac6132..84d308e 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -4861,7 +4861,9 @@ enabled opencl&& { check_lib2 OpenCL/cl.h
>>> clEnqueueNDRangeKernel -Wl
>>> die "ERROR: opencl not found"; } &&
>>> { check_cpp_condition "OpenCL/cl.h"
>>> "defined(CL_VERSION_1_2)" ||
>>> check_cpp_condition "CL/cl.h"
>>> "defined(CL_VERSION_1_2)" ||
>>> - die "ERROR: opencl must be installed and
>>> version must be 1.2 or compatible"; }
>>> + die "ERROR: opencl must be installed and
>>> version must be 1.2 or compatible"; } &&
>>> + { enabled shared &&
>>> + die "ERROR OpenCL API is experimental and
>>> not safe to be used with shared libs"; }
>>> enabled opengl&& { check_lib GL/glx.h glXGetProcAddress "-lGL"
>>> ||
>>> check_lib2 windows.h wglGetProcAddress
>>> "-lopengl32 -lgdi32" ||
>>> check_lib2 OpenGL/gl3.h glGetError
>>> "-Wl,-framework,OpenGL" ||
>>>
>>
>> The API hasn't been touched in several months and is functional, and
>> considering
>> distros already link to opencl if available in previous ffmpeg releases, i
>> don't
>> know if removing the feature like this is a good idea.
>> Of course they can just remove this check and keep using opencl if they want
>> to,
>> but that's besides the point.
>>
>> Maybe a warning instead?
>
> The question is if people intend to change the API and IIRC its
> design makes it hard to make changes without breaking ABI
OpenCL maintainers should probably chime in at this point. CCing Wei Gao then.
>
> i can add a warning if preferred but i think we either should
> choose to support the ABI/API until the next bump which wouldnt
> need a warning or not support it in which case we probably should
> disable it hard for shared libs or put a warning in the release notes
> where its hard to miss
A warning in release notes and in the configure script is IMO preferable than
disabling existing functionality, but i'm fine doing whatever causes the less
headaches for everyone.
Hi
Warning is OK for me.
Thanks
Best regards
>
> [...]
>
>
>
> ___
> 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] added ULs for demuxing avid media composer mxf files
On Aug 12, 2014 6:29 PM, "Mark Reid" wrote: > I didn't realize FFmbc was licensed differently :s. I don't know if it > helps, (IANAL either) > but the same ULs can be found in libMXF project, as well as the AAF SDK. > I'm not sure how to proceed, should I just drop the patch? Just mention libMXF then, as the values are the same and libMXF is under LGPL or BSD depending on the version. [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs
On Aug 12, 2014 6:43 PM, "highgod0401" wrote: > Hi > > Warning is OK for me. Do you plan to change the API? [...] Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/6] lavc/flacenc: partially unroll loop in flac_enc_lpc_16
On Tue, Aug 12, 2014 at 11:22:03PM +0200, James Darnley wrote: > It now does 12 samples per iteration, up from 4. > > From 1.8 to 3.2 times faster again. 3.6 to 5.7 times faster overall. > Runtime is reduced by a further 2 to 18%. Overall runtime reduced by > 4 to 50%. > > Same conditions as before apply. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
On Tue, Aug 12, 2014 at 6:44 PM, Timothy Gu wrote: > On Aug 12, 2014 6:29 PM, "Mark Reid" wrote: > > > I didn't realize FFmbc was licensed differently :s. I don't know if it > > helps, (IANAL either) > > but the same ULs can be found in libMXF project, as well as the AAF SDK. > > I'm not sure how to proceed, should I just drop the patch? > > Just mention libMXF then, as the values are the same and libMXF is under > LGPL or BSD depending on the version. Okay, I'll submit a new patch and do that then, thanks! > [...] > > Timothy > ___ > 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 6/6] lavc/flacdsp: document limitations of the LPC encoder
On Tue, Aug 12, 2014 at 11:22:07PM +0200, James Darnley wrote:
> ---
> libavcodec/flacdsp.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
> index 272cf2a..36cd904 100644
> --- a/libavcodec/flacdsp.h
> +++ b/libavcodec/flacdsp.h
> @@ -27,6 +27,13 @@ typedef struct FLACDSPContext {
> int len, int shift);
> void (*lpc)(int32_t *samples, const int coeffs[32], int order,
> int qlevel, int len);
> +/**
> + * This function has some limitations with various configurations:
> + * - when CONFIG_SMALL is 0 there is an unrolled loop which assumes the
> + * maximum value of order is 32.
> + * - when SSE4 (or newer) is available on x86 there is an unrolled copy
> + * which also assumes the maximum value of order is 0.
> + */
sounds like
printf()
on fridays with SSE4 this is limited to 27 characters
a function either should have a limit or not have one, it should
not depend on other factors
People using this function must be able to tell in what cases they
can use it
and People optimizing the function need to know which cases their
optimized code must support
the API defines both
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] cosmetic fix
On Tue, Aug 12, 2014 at 11:22:06PM +0200, James Darnley wrote: > --- > libavcodec/flacdsp_lpc_template.c |2 +- > 1 files changed, 1 insertions(+), 1 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
[FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
Changes since v2: *cleaned up commit message *identified keys as legacy ULs Mark Reid (1): added ULs for demuxing avid media composer mxf files libavformat/mxf.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
UL values from libMXF
Fixes Ticket#1554, Ticket#3100 and Ticket#3450
---
libavformat/mxf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index d20ed94..7d30d65 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -28,6 +28,8 @@
const MXFCodecUL ff_mxf_data_definition_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x01,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_VIDEO },
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x02,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_AUDIO },
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x6F,0x3C,0x8C,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_VIDEO }, /* LegacyPicture Avid Media Composer MXF */
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x78,0xE1,0xEB,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_AUDIO }, /* LegacySound Avid Media Composer MXF */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVMEDIA_TYPE_DATA },
};
@@ -44,6 +46,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x01,0x00
}, 15, AV_CODEC_ID_RAWVIDEO }, /* Uncompressed 422 8-bit */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00
}, 13, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x03,0x02,0x00,0x00
}, 14, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x04,0x01,0x00
}, 16, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD Legacy Avid Media Composer
MXF */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x00,0x00
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC Intra */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
}, 16, AV_CODEC_ID_V210 }, /* V210 */
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added ULs for demuxing avid media composer mxf files
sorry I didn't label this patch as version 3 I'll resend this correctly
On Tue, Aug 12, 2014 at 8:02 PM, Mark Reid wrote:
> UL values from libMXF
> Fixes Ticket#1554, Ticket#3100 and Ticket#3450
> ---
> libavformat/mxf.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index d20ed94..7d30d65 100644
> --- a/libavformat/mxf.c
> +++ b/libavformat/mxf.c
> @@ -28,6 +28,8 @@
> const MXFCodecUL ff_mxf_data_definition_uls[] = {
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x01,0x00,0x00,0x00
> }, 13, AVMEDIA_TYPE_VIDEO },
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x02,0x00,0x00,0x00
> }, 13, AVMEDIA_TYPE_AUDIO },
> +{ {
> 0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x6F,0x3C,0x8C,0xE1,0x6C,0xEF,0x11,0xD2
> }, 16, AVMEDIA_TYPE_VIDEO }, /* LegacyPicture Avid Media Composer MXF */
> +{ {
> 0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x78,0xE1,0xEB,0xE1,0x6C,0xEF,0x11,0xD2
> }, 16, AVMEDIA_TYPE_AUDIO }, /* LegacySound Avid Media Composer MXF */
> { {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> }, 0, AVMEDIA_TYPE_DATA },
> };
>
> @@ -44,6 +46,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x01,0x00
> }, 15, AV_CODEC_ID_RAWVIDEO }, /* Uncompressed 422 8-bit */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00
> }, 13, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x03,0x02,0x00,0x00
> }, 14, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x04,0x01,0x00
> }, 16, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD Legacy Avid Media
> Composer MXF */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x00,0x00
> }, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC Intra */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
> }, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
> }, 16, AV_CODEC_ID_V210 }, /* V210 */
> --
> 2.0.0
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] added ULs for demuxing avid media composer mxf files
Changes since v2: *cleaned up commit message *identified keys as legacy ULs Mark Reid (1): added ULs for demuxing avid media composer mxf files libavformat/mxf.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3] added ULs for demuxing avid media composer mxf files
UL values from libMXF
Fixes Ticket#1554, Ticket#3100 and Ticket#3450
---
libavformat/mxf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index d20ed94..7d30d65 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -28,6 +28,8 @@
const MXFCodecUL ff_mxf_data_definition_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x01,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_VIDEO },
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x02,0x02,0x00,0x00,0x00
}, 13, AVMEDIA_TYPE_AUDIO },
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x6F,0x3C,0x8C,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_VIDEO }, /* LegacyPicture Avid Media Composer MXF */
+{ {
0x80,0x7D,0x00,0x60,0x08,0x14,0x3E,0x6F,0x78,0xE1,0xEB,0xE1,0x6C,0xEF,0x11,0xD2
}, 16, AVMEDIA_TYPE_AUDIO }, /* LegacySound Avid Media Composer MXF */
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVMEDIA_TYPE_DATA },
};
@@ -44,6 +46,7 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x01,0x00
}, 15, AV_CODEC_ID_RAWVIDEO }, /* Uncompressed 422 8-bit */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x71,0x00,0x00,0x00
}, 13, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x03,0x02,0x00,0x00
}, 14, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x04,0x01,0x00
}, 16, AV_CODEC_ID_DNXHD }, /* SMPTE VC-3/DNxHD Legacy Avid Media Composer
MXF */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x32,0x00,0x00
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC Intra */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
}, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
}, 16, AV_CODEC_ID_V210 }, /* V210 */
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/dnxhd: ff_dnxhd_cid_table is not exported
Signed-off-by: James Almer
---
libavcodec/dnxhddata.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddata.h b/libavcodec/dnxhddata.h
index 8166ee8..d5629e2 100644
--- a/libavcodec/dnxhddata.h
+++ b/libavcodec/dnxhddata.h
@@ -46,7 +46,7 @@ typedef struct CIDEntry {
AVRational frame_rates[5];
} CIDEntry;
-extern av_export const CIDEntry ff_dnxhd_cid_table[];
+extern const CIDEntry ff_dnxhd_cid_table[];
int ff_dnxhd_get_cid_table(int cid);
int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth);
--
1.8.5.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/dnxhd: ff_dnxhd_cid_table is not exported
On Wed, Aug 13, 2014 at 5:34 AM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/dnxhddata.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dnxhddata.h b/libavcodec/dnxhddata.h
> index 8166ee8..d5629e2 100644
> --- a/libavcodec/dnxhddata.h
> +++ b/libavcodec/dnxhddata.h
> @@ -46,7 +46,7 @@ typedef struct CIDEntry {
> AVRational frame_rates[5];
> } CIDEntry;
>
> -extern av_export const CIDEntry ff_dnxhd_cid_table[];
> +extern const CIDEntry ff_dnxhd_cid_table[];
>
> int ff_dnxhd_get_cid_table(int cid);
> int ff_dnxhd_find_cid(AVCodecContext *avctx, int bit_depth);
> --
> 1.8.5.5
>
LGTM, its not used anywhere outside of avcodec.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: ignore reference segmentation map if error_resilience flag is set.
On Wed, Aug 13, 2014 at 12:11 AM, Ronald S. Bultje wrote:
> Fixes ffvp9_fails_where_libvpx.succeeds.webm from ticket 3849.
> ---
> libavcodec/vp9.c | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 56975bd..186aec1 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -278,7 +278,7 @@ static int vp9_alloc_frame(AVCodecContext *ctx, VP9Frame
> *f)
>
> // retain segmentation map if it doesn't update
> if (s->segmentation.enabled && !s->segmentation.update_map &&
> -!s->intraonly && !s->keyframe) {
> +!s->intraonly && !s->keyframe && !s->errorres) {
> memcpy(f->segmentation_map, s->frames[LAST_FRAME].segmentation_map,
> sz);
> }
>
> @@ -1344,16 +1344,20 @@ static void decode_mode(AVCodecContext *ctx)
> vp56_rac_get_prob_branchy(&s->c,
> s->prob.segpred[s->above_segpred_ctx[col] +
> s->left_segpred_ctx[row7]]))) {
> -int pred = 8, x;
> -uint8_t *refsegmap = s->frames[LAST_FRAME].segmentation_map;
> -
> -if (!s->last_uses_2pass)
> -ff_thread_await_progress(&s->frames[LAST_FRAME].tf, row >> 3, 0);
> -for (y = 0; y < h4; y++)
> -for (x = 0; x < w4; x++)
> -pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols + x
> + col]);
> -av_assert1(pred < 8);
> -b->seg_id = pred;
> +if (!s->errorres) {
> +int pred = 8, x;
> +uint8_t *refsegmap = s->frames[LAST_FRAME].segmentation_map;
> +
> +if (!s->last_uses_2pass)
> +ff_thread_await_progress(&s->frames[LAST_FRAME].tf, row >>
> 3, 0);
> +for (y = 0; y < h4; y++)
> +for (x = 0; x < w4; x++)
> +pred = FFMIN(pred, refsegmap[(y + row) * 8 * s->sb_cols
> + x + col]);
> +av_assert1(pred < 8);
> +b->seg_id = pred;
> +} else {
> +b->seg_id = 0;
> +}
>
> memset(&s->above_segpred_ctx[col], 1, w4);
> memset(&s->left_segpred_ctx[row7], 1, h4);
> --
> 1.8.5.5
>
Might it be useful to add some of those special samples to fate?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
