Re: [FFmpeg-devel] OSX AudioToolbox codec support

[Robert Krüger]

On Tue, Mar 1, 2016 at 11:06 AM, Carl Eugen Hoyos  wrote:

> Rodger Combs  gmail.com> writes:
>
> > This series adds decoders and encoders based on OSX's AudioToolbox
> framework.  They may be faster than the native ones (particularly in
> > cases where they can be hardware-accelerated), the encoders are
> > competitive on quality, and some
>
> I think this is a great addition to FFmpeg!
>
> > users may find them convenient from a licensing perspective.
>
> I believe it makes no difference.
>

It does IMHO. IIRC shipping a product with ffmpeg's aac requires you to pay
patent fees to the patent holder. Using the aac encoder from the platform
is different because the aac encoder is delivered by the platform and Apple
has already payed patent fees.


>
> > ADPCM_IMA_QT can also be encoded by AudioToolbox, but I couldn't
> > figure out how to get it working properly, so it's left with
> > just the decoders.
>
> > I'm not sure if the alaw/ulaw and IMA codecs are worth having
> > at all since they're so simple; I just threw them in since
> > they were easy.
>
> Please keep them.
>
> > The ALAC encoder and decoder have been tested as bitexact.
>
> Also with our implementation?
>
> Please mention ticket #4828 in the commit message and please
> bump minor, not micro.
>
> Thank you, 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

Re: [FFmpeg-devel] [PATCH] aacenc: avoid double in quantize_bands.

[Reimar Döffinger]

On 02.03.2016, at 04:48, Ganesh Ajjanagadde  wrote:

> On Tue, Mar 1, 2016 at 4:55 PM, Reimar Döffinger
>  wrote:
>> I cannot see any point whatsoever to use
>> double here instead of float.
> 
> There can be some negligible accuracy differences, but I do not see
> any harm myself; aac anyway sticks to floats in most places.

floating-point is difficult, but I really can't see any.
The only thing it changes at all is the addition of the rounding value.
However given that we convert to int after the range of relevant bits is very 
limited, and the rounding value is a fixed value != 0.5.
Thus I suspect that the two are actually exactly equivalent.

>> Using float allows for use of SIMD.
> 
> Not an accurate statement, there is SIMD for doubles as well. More
> precise variant is "allows for more effective/efficient use of SIMD".

Well... I don't know if I'll improve the statement, but the problem is that 
there are conditions in that code, and most SIMD does not have an cmov 
instruction equivalent.
Since SIMD registers generally fit only 2 doubles that basically does mean that 
with doubles using SIMD is in fact not possible (in a way that makes sense/does 
not make it slower).
At the very least the compiler won't do it on its own.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacenc: optimize cost cache.

[Reimar Döffinger]

On 02.03.2016, at 04:34, Ganesh Ajjanagadde  wrote:

> On Tue, Mar 1, 2016 at 6:34 PM, Reimar Döffinger
>  wrote:
>> Avoids trashing the CPU cache each time the
>> cost cache is cleared.
> 
> Just curious as to roughly the magnitude of perf improvement? No
> comments on the patch itself.

Didn't measure properly, approx. 6% with the one test file.
However I think now it might be better to just use a generational cache instead 
(i.e. store and compare a generation counter in the cache instead of clearing, 
only clear when that counter wraps around).
That would keep unused elements completely out of the cache.
Changing the cache layout so that a higher ratio of elements are in the CPU 
cache and close together (e.g. by using some kind of "hash") might be worth a 
try, too.
Because the current structure is unfortunately larger than even common L2 cache 
sizes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 5/5 v2] lavf/internal.h: Add declaration for ff_get_packet_palette()

[Mats Peterson]

Edited the doxy documentation.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From b5b8af39030ea01759567fdcd17d0420fb788c78 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 2 Mar 2016 07:50:32 +0100
Subject: [PATCH v4 5/5 v2] lavf/internal.h: Add declaration for ff_get_packet_palette()

---
 libavformat/internal.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index bc6a6c2..8e06655 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -573,4 +573,16 @@ int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp, int
  */
 int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *enc, int expected_stride);
 
+/**
+ * Retrieves the palette from a packet, either from side data, or
+ * appended to the video data in the packet itself (raw video only).
+ * It is commonly used after a call to ff_reshuffle_raw_rgb().
+ *
+ * Use 0 for the ret parameter to check for side data only.
+ *
+ * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
+ * @param ret return value from ff_reshuffle_raw_rgb(), or 0
+ */
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette);
+
 #endif /* AVFORMAT_INTERNAL_H */
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FLIC in AVI

[Mats Peterson]

I noticed that you, Paul, added a patch somewhere in 2012 with the 
purpose of making it possible to use FLI(C) in AVI. It doesn't work very 
well in my book. Try the following command with the file below:


ffmpeg -i 3DMORPH.FLI -vcodec copy 3dmorph.avi

File:
https://drive.google.com/open?id=0B3_pEBoLs0faNWRLc2tYLVAzWG8

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value

[Ganesh Ajjanagadde]

On Tue, Mar 1, 2016 at 9:14 AM, Rostislav Pehlivanov
 wrote:
> On 1 March 2016 at 03:21, Ganesh Ajjanagadde  wrote:
>>
>> It makes no sense whatsoever to do this at each function call; we
>> already have a table for this.
>>
>> Yields a 2x improvement in find_min_book (x86-64, Haswell+GCC):
>> ffmpeg -i sin.flac -acodec aac -y sin.aac
>> find_min_book
>> old
>> 605 decicycles in find_min_book, 8388453 runs,155 skips.9x
>> 606 decicycles in find_min_book,16776912 runs,304 skips.9x
>> 607 decicycles in find_min_book,33553819 runs,613 skips.2x
>> 607 decicycles in find_min_book,67107668 runs,   1196 skips.3x
>> 607 decicycles in find_min_book,134215360 runs,   2368 skips3x
>>
>> new
>> 359 decicycles in find_min_book, 8388552 runs, 56 skips.3x
>> 360 decicycles in find_min_book,16777112 runs,104 skips.1x
>> 361 decicycles in find_min_book,33554218 runs,214 skips.4x
>> 361 decicycles in find_min_book,67108381 runs,483 skips.5x
>> 361 decicycles in find_min_book,134216725 runs,   1003 skips5x
>>
>> and more importantly a non-negligible speedup (~ 8%) to overall AAC
>> encoding:
>> old:
>> ffmpeg -i sin.flac -acodec aac -strict -2 -y sin_new.aac  6.82s user 0.03s
>> system 104% cpu 6.565 total
>> new:
>> ffmpeg -i sin.flac -acodec aac -strict -2 -y sin_old.aac  6.24s user 0.03s
>> system 104% cpu 5.993 total
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>
>
> Nicely spotted, thanks.
>
> LGTM, feel free to apply whenever you can.
>

pushed, thanks both
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value

[Ganesh Ajjanagadde]

On Tue, Mar 1, 2016 at 7:52 AM, Derek Buitenhuis
 wrote:
> On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote:
>
> [...]
>
>> ---
>>  libavcodec/aacenc_utils.h | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> Cool. Looks like an obvious/easy win, assuming it's identical.

They are not precisely identical, and in fact the change results in
slightly better accuracy wrt the mathematical expression, simply
because sqrtf(q * sqrtf(q)) is not always a correctly rounded float. I
vaguely recall negligible ~ 2/3 ulp differences. The table is
correctly rounded; I tested that while speeding up the tablegen.

Added a small line to this effect in the notes.

>
> - Derek
> ___
> 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] aacenc: avoid double in quantize_bands.

[Ganesh Ajjanagadde]

On Tue, Mar 1, 2016 at 4:55 PM, Reimar Döffinger
 wrote:
> I cannot see any point whatsoever to use
> double here instead of float.

There can be some negligible accuracy differences, but I do not see
any harm myself; aac anyway sticks to floats in most places.

> Using float allows for use of SIMD.

Not an accurate statement, there is SIMD for doubles as well. More
precise variant is "allows for more effective/efficient use of SIMD".

Patch itself LGTM, but I am not an aac maintainer.

> ---
>  libavcodec/aacenc_utils.h | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
> index cb5bc8d..571b1e6 100644
> --- a/libavcodec/aacenc_utils.h
> +++ b/libavcodec/aacenc_utils.h
> @@ -66,10 +66,9 @@ static inline void quantize_bands(int *out, const float 
> *in, const float *scaled
>const float rounding)
>  {
>  int i;
> -double qc;
>  for (i = 0; i < size; i++) {
> -qc = scaled[i] * Q34;
> -out[i] = (int)FFMIN(qc + rounding, (double)maxval);
> +float qc = scaled[i] * Q34;
> +out[i] = (int)FFMIN(qc + rounding, (float)maxval);
>  if (is_signed && in[i] < 0.0f) {
>  out[i] = -out[i];
>  }
> --
> 2.7.0
>
> ___
> 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]lavf/img2enc: Allow to reverse frame order

[Ganesh Ajjanagadde]

On Tue, Mar 1, 2016 at 9:17 AM, Paul B Mahol  wrote:
> On 3/1/16, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos  wrote:
>>
>>> Ronald S. Bultje  gmail.com> writes:
>>>
>>> > > So how does this mechanism look like for the requested
>>> > > use case?
>>> >
>>> > man ln.
>>>
>>> As said, this is a completely ridiculous argument:
>>> FFmpeg has always tried to provide new features, no
>>> matter if other solutions existed or not.
>>
>>
>> When you don't get your way, just shout "ridiculous!" and all will be okay.
>
> Its just few loc. I see nothing wrong with it, lets vote!

+1 to voting - why don't we actually put the developer committee to
use instead of arguing about it?

> ___
> 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] aacenc: optimize cost cache.

[Ganesh Ajjanagadde]

On Tue, Mar 1, 2016 at 6:34 PM, Reimar Döffinger
 wrote:
> Avoids trashing the CPU cache each time the
> cost cache is cleared.

Just curious as to roughly the magnitude of perf improvement? No
comments on the patch itself.

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Patch: Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

Hi all,
This is my first patch. git send-mail did not work for me. Sending the
patch via gmail gui. Please review my patch.

Thank you,
NagaChaitanya Vellanki


0001-Add-test-for-avpriv_get_trc_function_from_trc-functi.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 5/5] lavf/internals.h: Add declaration for ff_get_packet_palette()

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 0fab64e2c08519302c3b44ae53ab01cfb3322812 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 2 Mar 2016 03:14:34 +0100
Subject: [PATCH v4 5/5] lavf/internals.h: Add declaration for ff_get_packet_palette()

---
 libavformat/internal.h |   13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index bc6a6c2..d838cfe 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -573,4 +573,17 @@ int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp, int
  */
 int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *enc, int expected_stride);
 
+/**
+ * Retrieves the palette from a packet, either from a side data packet,
+ * or appended to the video data in the packet itself (raw video only).
+ * It is commonly used after a call to ff_reshuffle_raw_rgb().
+ *
+ * Use 0 for the ret parameter to force checking for a palette side data
+ * packet only.
+ *
+ * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
+ * @param ret return value from ff_reshuffle_raw_rgb(), or 0
+ */
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette);
+
 #endif /* AVFORMAT_INTERNAL_H */
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 4/5] lavf/utils: New function ff_get_packet_palette()

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 403d4db37d2690a8263db53b28225409eeb9bb8c Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 2 Mar 2016 03:14:05 +0100
Subject: [PATCH v4 4/5] lavf/utils: New function ff_get_packet_palette()

---
 libavformat/utils.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index fe2916f..771e878 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4759,3 +4759,19 @@ int ff_parse_creation_time_metadata(AVFormatContext *s, int64_t *timestamp, int
 }
 return 0;
 }
+
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette)
+{
+int size;
+
+*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, );
+if (*palette && size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
+return AVERROR_INVALIDDATA;
+}
+
+if (!*palette && ret == CONTAINS_PAL)
+*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+
+return 0;
+}
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 3/5] lavf/riffenc: Handle palette for non-raw codecs

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From bb8b4c33f782d8c121a0575c5175739036906d27 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 2 Mar 2016 03:13:14 +0100
Subject: [PATCH v4 3/5] lavf/riffenc: Handle palette for non-raw codecs

---
 libavformat/riffenc.c |   20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 1dd7971..195a58e 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -209,12 +209,17 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 int keep_height = enc->extradata_size >= 9 &&
   !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
 int extradata_size = enc->extradata_size - 9*keep_height;
-int raw_pal_avi;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
+int pal_avi;
 
-raw_pal_avi = !for_asf && enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
-  !enc->codec_tag &&
-enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8;
-if (!enc->extradata_size && raw_pal_avi)
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+pal_avi = !for_asf &&
+  (pix_fmt == AV_PIX_FMT_PAL8 ||
+   pix_fmt == AV_PIX_FMT_MONOWHITE ||
+   pix_fmt == AV_PIX_FMT_MONOBLACK);
+
+if (!enc->extradata_size && pal_avi)
 extradata_size = 4 * (1 << enc->bits_per_coded_sample);
 
 /* size */
@@ -239,11 +244,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_write(pb, enc->extradata, extradata_size);
 if (!for_asf && extradata_size & 1)
 avio_w8(pb, 0);
-} else if (raw_pal_avi) {
+} else if (pal_avi) {
 int i;
-enum AVPixelFormat pix_fmt = enc->pix_fmt;
-if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
-pix_fmt = AV_PIX_FMT_MONOWHITE;
 for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
 /* Initialize 1 bpp palette to black & white */
 if (i == 0 && pix_fmt == AV_PIX_FMT_MONOWHITE)
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 2/5] lavf/movenc: Add support for palette side data packets

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From e4246cb978aa165cf2c1b51e62a97733398f5149 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 2 Mar 2016 03:12:17 +0100
Subject: [PATCH v4 2/5] lavf/movenc: Add support for palette side data packets

---
 libavformat/movenc.c |   45 +++--
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 3295266..d468e05 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1716,13 +1716,14 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr
 else
 avio_wb16(pb, 0x18); /* Reserved */
 
-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+int pal_size = 1 << track->enc->bits_per_coded_sample;
 int i;
 avio_wb16(pb, 0); /* Color table ID */
 avio_wb32(pb, 0); /* Color table seed */
 avio_wb16(pb, 0x8000);/* Color table flags */
-avio_wb16(pb, 255);   /* Color table size (zero-relative) */
-for (i = 0; i < 256; i++) {
+avio_wb16(pb, pal_size - 1);  /* Color table size (zero-relative) */
+for (i = 0; i < pal_size; i++) {
 uint32_t rgb = AV_RL32(>palette[i]);
 uint16_t r = (rgb >> 16) & 0xff;
 uint16_t g = (rgb >> 8)  & 0xff;
@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-if (trk->is_unaligned_qt_rgb) {
-const uint8_t *data = pkt->data;
-int size = pkt->size;
-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
-int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
-int ret = ff_reshuffle_raw_rgb(s, , trk->enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret == CONTAINS_PAL && !trk->pal_done) {
-int pal_size = 1 << trk->enc->bits_per_coded_sample;
-memset(trk->palette, 0, AVPALETTE_SIZE);
-memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
-trk->pal_done++;
-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
-   trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (trk->mode == MODE_MOV) {
+AVPacket *opkt = pkt;
+int ret;
+if (trk->is_unaligned_qt_rgb) {
+int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
+int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
+ret = ff_reshuffle_raw_rgb(s, , trk->enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, );
+if (ret2 < 0)
+return ret2;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
+trk->pal_done++;
+}
+} else if (trk->enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
+   (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
+   trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK)) {
 for (i = 0; i < pkt->size; i++)
 pkt->data[i] = ~pkt->data[i];
 }
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 1/5] lavf/avienc: Add support for palette side data packets

[Mats Peterson]

Hopefully the last version of the patch set.

Try to do stream copy to and from avi/mov with the files below:

QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0

QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc

Microsoft Video 1 (CRAM)
https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d573d32de5e8fe93b8212aedb44bafd444dd616c Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 2 Mar 2016 03:12:03 +0100
Subject: [PATCH v4 1/5] lavf/avienc: Add support for palette side data packets

---
 libavformat/avienc.c |   74 ++
 1 file changed, 44 insertions(+), 30 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..30a89cd 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -362,7 +362,8 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->pal_offset = avio_tell(pb) + 40;
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -652,11 +653,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,44 +669,57 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
 if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
 int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
 int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
 ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
 if (ret < 0)
 return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
-int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
-for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
-avio_wl32(pb, v & 0xff);
-}
-avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}
-avi_stream2fourcc(tag, stream_index, enc->codec_type);
-tag[2] = 'p'; tag[3] = 'c';
-pc_tag = ff_start_tag(pb, tag);
-avio_w8(pb, 0);
-avio_w8(pb, pal_size & 0xFF);
-avio_wl16(pb, 0); // reserved
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+const uint8_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, );
+if (ret2 < 0)
+return ret2;
+if (pal) {
+int pal_size = 1 << enc->bits_per_coded_sample;
+int pc_tag, i;
+if (pb->seekable && !avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->pal_offset, SEEK_SET);
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
-avio_wb32(pb, v<<8);
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wl32(pb, v & 0xff);
 }
-ff_end_tag(pb, pc_tag);
+avio_seek(pb, cur_offset, SEEK_SET);
+avist->hdr_pal_done++;
 }
-ret = avi_write_packet_internal(s, pkt);
-av_packet_free();
-return ret;
+avi_stream2fourcc(tag, stream_index, 

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> and ffmpeg supports alot more than files, one could want to do
> 
> -reverse 1 -i http://foobar.com/image%d.jpeg

This patch is unrelated to demuxing, it is meant 
to implement:
$ ffmpeg -i input -reverse 1 -start_number xyz out%3d.jpg

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add pipe and cache test

[Michael Niedermayer]

On Mon, Feb 29, 2016 at 09:36:55PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/seek.mak   |2 ++
>  tests/ref/seek/cache-pipe |   49 
> +
>  2 files changed, 51 insertions(+)
>  create mode 100644 tests/ref/seek/cache-pipe

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/seek-test: Support passing options to demuxers and protocols

[Michael Niedermayer]

On Mon, Feb 29, 2016 at 09:37:51PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/seek-test.c |2 ++
>  1 file changed, 2 insertions(+)

applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mov: Set display aspect ratio for avid dv

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> > New patch attached.
> > 
> > Please comment, Carl Eugen
> 
> probably ok

Patch applied.

Thank you, Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix a bug in ff_thread_report_progress in updating progress[field].

[Wan-Teh Chang]

On Tue, Mar 1, 2016 at 7:44 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang 
> wrote:
>
>> By the way, I'm also wondering why ff_thread_report_progress is
>> sometimes called with progress[field] >= n? I saw it happen when I ran
>> make fate-h264, but did not investigate it.
>
> I don't know, which sample (test name) specifically?

The attached ff_thread_report_progress.txt file is a patch for ffmpeg
that counts the fast and slow code paths in ff_thread_report_progress
and ff_thread_await_progress, and prints the counters at the end.

I ran "make fate-h264 THREADS=4". Here are the results, which show
that the fast code path (progress[field] >= n) was taken in
ff_thread_report_progress.

wtc@hostname:~/ffmpeg-dev/fast-slow-paths-instrumentation/ffmpeg/tests/data/fate$
grep slow *.err
h264-conformance-aud_mw_e.err:report_progress: fast=100, slow=1000 |
await_progress: fast=10999, slow=198
h264-conformance-ba1_ft_c.err:report_progress: fast=299, slow=5382 |
await_progress: fast=112159, slow=1254
h264-conformance-ba1_sony_d.err:report_progress: fast=17, slow=153 |
await_progress: fast=0, slow=0
h264-conformance-ba2_sony_f.err:report_progress: fast=300, slow=2700 |
await_progress: fast=36259, slow=688
h264-conformance-ba3_sva_c.err:report_progress: fast=17, slow=153 |
await_progress: fast=6054, slow=48
h264-conformance-bamq1_jvc_c.err:report_progress: fast=30, slow=270 |
await_progress: fast=0, slow=0
h264-conformance-bamq2_jvc_c.err:report_progress: fast=30, slow=270 |
await_progress: fast=4235, slow=87
h264-conformance-ba_mw_d.err:report_progress: fast=100, slow=900 |
await_progress: fast=10969, slow=223
h264-conformance-banm_mw_d.err:report_progress: fast=100, slow=900 |
await_progress: fast=9003, slow=243
h264-conformance-basqp1_sony_c.err:report_progress: fast=4, slow=36 |
await_progress: fast=0, slow=0
h264-conformance-caba1_sony_d.err:report_progress: fast=50, slow=450 |
await_progress: fast=0, slow=0
h264-conformance-caba1_sva_b.err:report_progress: fast=17, slow=153 |
await_progress: fast=0, slow=0
h264-conformance-caba2_sony_e.err:report_progress: fast=300, slow=2700
| await_progress: fast=34215, slow=920
h264-conformance-caba2_sva_b.err:report_progress: fast=17, slow=153 |
await_progress: fast=1610, slow=24
h264-conformance-caba3_sony_c.err:report_progress: fast=101, slow=909
| await_progress: fast=60774, slow=264
h264-conformance-caba3_sva_b.err:report_progress: fast=17, slow=153 |
await_progress: fast=6637, slow=91
h264-conformance-caba3_toshiba_e.err:report_progress: fast=300,
slow=2700 | await_progress: fast=28113, slow=716
h264-conformance-cabaci3_sony_b.err:report_progress: fast=101,
slow=909 | await_progress: fast=60989, slow=302
h264-conformance-cabac_mot_fld0_full.err:report_progress: fast=24,
slow=360 | await_progress: fast=72775, slow=83
h264-conformance-cabac_mot_frm0_full.err:report_progress: fast=12,
slow=360 | await_progress: fast=79299, slow=225
h264-conformance-cabac_mot_mbaff0_full.err:report_progress: fast=12,
slow=180 | await_progress: fast=77371, slow=119
h264-conformance-cabac_mot_picaff0_full.err:report_progress: fast=18,
slow=346 | await_progress: fast=88910, slow=169
h264-conformance-cabast3_sony_e.err:report_progress: fast=9, slow=162
| await_progress: fast=7851, slow=54
h264-conformance-cabastbr3_sony_b.err:report_progress: fast=25,
slow=450 | await_progress: fast=7967, slow=119
h264-conformance-cabref3_sand_d.err:report_progress: fast=36, slow=324
| await_progress: fast=38201, slow=43
h264-conformance-cacqp3_sony_d.err:report_progress: fast=26, slow=234
| await_progress: fast=9512, slow=126
h264-conformance-cafi1_sva_c.err:report_progress: fast=34, slow=510 |
await_progress: fast=78904, slow=2
h264-conformance-cama1_sony_c.err:report_progress: fast=5, slow=75 |
await_progress: fast=0, slow=0
h264-conformance-cama1_toshiba_b.err:report_progress: fast=30,
slow=270 | await_progress: fast=72871, slow=191
h264-conformance-cama1_vtc_c.err:report_progress: fast=3, slow=45 |
await_progress: fast=9041, slow=14
h264-conformance-cama2_vtc_b.err:report_progress: fast=3, slow=57 |
await_progress: fast=13790, slow=14
h264-conformance-cama3_sand_e.err:report_progress: fast=18, slow=162 |
await_progress: fast=34497, slow=77
h264-conformance-cama3_vtc_b.err:report_progress: fast=3, slow=54 |
await_progress: fast=13784, slow=13
h264-conformance-camaci3_sony_c.err:report_progress: fast=7, slow=28 |
await_progress: fast=1327, slow=22
h264-conformance-camanl1_toshiba_b.err:report_progress: fast=30,
slow=300 | await_progress: fast=71845, slow=200
h264-conformance-camanl2_toshiba_b.err:report_progress: fast=30,
slow=300 | await_progress: fast=65382, slow=187
h264-conformance-camanl3_sand_e.err:report_progress: fast=18, slow=180
| await_progress: fast=34512, slow=61
h264-conformance-camasl3_sony_b.err:report_progress: fast=7, slow=28 |
await_progress: fast=3142, slow=23

[FFmpeg-devel] [PATCH] aacenc: optimize cost cache.

[Reimar Döffinger]

Avoids trashing the CPU cache each time the
cost cache is cleared.
---
 libavcodec/aaccoder_twoloop.h | 20 
 libavcodec/aacenc.c   |  7 +--
 libavcodec/aacenc.h   |  4 +---
 libavcodec/aacenc_quantization_misc.h | 17 +++--
 4 files changed, 13 insertions(+), 35 deletions(-)

diff --git a/libavcodec/aaccoder_twoloop.h b/libavcodec/aaccoder_twoloop.h
index 397a4db..73bd082 100644
--- a/libavcodec/aaccoder_twoloop.h
+++ b/libavcodec/aaccoder_twoloop.h
@@ -391,10 +391,7 @@ static void search_for_quantizers_twoloop(AVCodecContext 
*avctx,
sce->ics.swb_sizes[g],
sce->sf_idx[w*16+g],
cb,
-   1.0f,
-   INFINITY,
-   , ,
-   0);
+   , );
 bits += b;
 qenergy += sqenergy;
 }
@@ -472,10 +469,7 @@ static void search_for_quantizers_twoloop(AVCodecContext 
*avctx,
 sce->ics.swb_sizes[g],
 sce->sf_idx[w*16+g],
 cb,
-1.0f,
-INFINITY,
-, ,
-0);
+, );
 bits += b;
 qenergy += sqenergy;
 }
@@ -628,10 +622,7 @@ static void search_for_quantizers_twoloop(AVCodecContext 
*avctx,
 sce->ics.swb_sizes[g],
 sce->sf_idx[w*16+g]-1,
 cb,
-1.0f,
-INFINITY,
-, ,
-0);
+, );
 bits += b;
 qenergy += sqenergy;
 }
@@ -665,10 +656,7 @@ static void search_for_quantizers_twoloop(AVCodecContext 
*avctx,
 
sce->ics.swb_sizes[g],
 
sce->sf_idx[w*16+g]+1,
 cb,
-1.0f,
-INFINITY,
-, ,
-0);
+, );
 bits += b;
 qenergy += sqenergy;
 }
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 5a70da1..e60bbfe 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -78,12 +78,7 @@ static void put_audio_specific_config(AVCodecContext *avctx)
 
 void ff_quantize_band_cost_cache_init(struct AACEncContext *s)
 {
-int sf, g;
-for (sf = 0; sf < 256; sf++) {
-for (g = 0; g < 128; g++) {
-s->quantize_band_cost_cache[sf][g].bits = -1;
-}
-}
+memset(s->quantize_band_cost_cache_state, 0xff, 
sizeof(s->quantize_band_cost_cache_state));
 }
 
 #define WINDOW_FUNC(type) \
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 2252e29..d937d17 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -85,9 +85,6 @@ typedef struct AACQuantizeBandCostCacheEntry {
 float rd;
 float energy;
 int bits; ///< -1 means uninitialized entry
-char cb;
-char rtz;
-char padding[2]; ///< Keeps the entry size a multiple of 32 bits
 } AACQuantizeBandCostCacheEntry;
 
 /**
@@ -126,6 +123,7 @@ typedef struct AACEncContext {
 DECLARE_ALIGNED(16, int,   qcoefs)[96];  ///< quantized coefficients
 DECLARE_ALIGNED(32, float, scoefs)[1024];///< scaled coefficients
 
+uint8_t quantize_band_cost_cache_state[256][128];
 AACQuantizeBandCostCacheEntry quantize_band_cost_cache[256][128]; ///< 
memoization area for quantize_band_cost
 
 struct {
diff --git a/libavcodec/aacenc_quantization_misc.h 
b/libavcodec/aacenc_quantization_misc.h
index eaa71c9..29bb986 100644
--- 

Re: [FFmpeg-devel] [PATCH 2/2] configure: build fix for mips cpu p5600

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 06:41:18PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> For P5600 mips cpu, cpuflags="-march=p5600" sets mips32r5 by default.
> Current configuration sets mips32r2 for p5600 cpu, hence ldflag check results 
> in,
> error: '-mips32r2' conflicts with the other architecture options, which 
> specify a mips32r5 processor
> 
> Due to above error, mips32r2 gets disabled avoiding necessary msa flag 
> settings, which breaks the build.
> To fix this issue, introduced mips32r5 in mips arch list which is more 
> appropriate.
> 
> Signed-off-by: Shivraj Patil 
> ---
>  configure |   23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 3f4a0c7..df9bb74 100755
> --- a/configure
> +++ b/configure
> @@ -1661,6 +1661,7 @@ ARCH_EXT_LIST_ARM="
>  ARCH_EXT_LIST_MIPS="
>  mipsfpu
>  mips32r2
> +mips32r5
>  mips64r2
>  mips32r6
>  mips64r6
> @@ -4174,6 +4175,7 @@ elif enabled mips; then
>  
>  case $cpu in
>  24kc)
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4186,6 +4188,7 @@ elif enabled mips; then
>  disable mmi
>  ;;
>  24kf*)
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4197,6 +4200,7 @@ elif enabled mips; then
>  disable mmi
>  ;;
>  24kec|34kc|1004kc)
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4208,6 +4212,7 @@ elif enabled mips; then
>  disable mmi
>  ;;
>  24kef*|34kf*|1004kf*)
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4218,6 +4223,7 @@ elif enabled mips; then
>  disable mmi
>  ;;
>  74kc)
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4237,6 +4243,7 @@ elif enabled mips; then
>  disable mmi
>  ;;
>  p5600)
> +disable mips32r2
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4251,6 +4258,7 @@ elif enabled mips; then
>  ;;
>  i6400)
>  disable mips32r2
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mipsdsp
> @@ -4265,6 +4273,7 @@ elif enabled mips; then
>  ;;
>  loongson*)
>  disable mips32r2
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6
> @@ -4300,6 +4309,7 @@ elif enabled mips; then
>  warn "unknown CPU. Disabling all MIPS optimizations."
>  disable mipsfpu
>  disable mips32r2
> +disable mips32r5
>  disable mips32r6
>  disable mips64r2
>  disable mips64r6

some working autodetection or factorizing this code or using
dependancies like
mips32r6_dep = "mips32r5"
mips32r5_dep = "mips32r2"
mips32r2_dep = "mips32"
(the deps will maybe not work depending on where the code using
 the stuff is)

would be cleaner i think  than repeating the list of disables

[...]
-- 
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 1/2] disabled loongson2, loongson3 and mmi for non-loongson cpu

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 06:41:17PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> For mips P5600/I6400 configure, assembler throws errors at check_inline_asm 
> for loongson2, loongson3 and mmi as the instructions opcode not supported on 
> this processor. Hence disabled loongson2, loongson3 and mmi in non loogson 
> mips cpus.

the point of check_inline_asm is to find out if something is
supported.

a 1 line automatic detection is much better than to manually list
all the cases


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc: add h264 mediacodec decoder

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 08:01:45PM +0100, Matthieu Bouron wrote:
> On Sat, Feb 27, 2016 at 04:28:43PM +0100, Michael Niedermayer wrote:
> > On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> > > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > > > On Tue, 23 Feb 2016 09:53:43 +0100
> > > > Matthieu Bouron  wrote:
> > > > 
> > > > > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer wrote:
> > > > > > On Mon, Feb 22, 2016 at 12:20:36PM +0100, Matthieu Bouron wrote:  
> > > > > > > From: Matthieu Bouron   
> > > > > > [...]  
> > > > > > > +codec = (*env)->NewObject(env, 
> > > > > > > jfields.mediacodec_list_class, jfields.init_id, 0);
> > > > > > > +if (!codec) {
> > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not create media 
> > > > > > > codec list\n");
> > > > > > > +goto done;
> > > > > > > +}
> > > > > > > +
> > > > > > > +tmp = (*env)->CallObjectMethod(env, codec, 
> > > > > > > jfields.find_decoder_for_format_id, format);
> > > > > > > +if (!tmp) {
> > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not find decoder 
> > > > > > > in media codec list\n");
> > > > > > > +goto done;
> > > > > > > +}
> > > > > > > +
> > > > > > > +name = ff_jni_jstring_to_utf_chars(env, tmp, NULL);
> > > > > > > +if (!name) {  
> > > > > >   
> > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not convert 
> > > > > > > jstring to utf chars\n");  
> > > > > > 
> > > > > > some non NULL context would be better, if possible, so the user 
> > > > > > knows
> > > > > > where an error came from  
> > > > > 
> > > > > It would require to pass the log_ctx (avctx) as an argument of
> > > > > ff_AMediaCodecList_getCodecByName.
> > > > > 
> > > > > All the functions of this wrapper does not take a log_ctx as argument
> > > > > to be as close as possible to the original NDK MediaCodec API. The
> > > > > NDK MediaCodec API does not provide any wrapper around MediaCodecList.
> > > > > 
> > > > > I would like the whole wrapper API to be consistent but also as close 
> > > > > as
> > > > > possible to original one.
> > > > > If you think it's mandatory I can add a log_ctx argument to every
> > > > > functions of the wrapper API (so it will be used directly by av_log 
> > > > > and
> > > > > ff_jni_exception_check).
> > > > > 
> > > > > On another note, I fixed locally this part of the code by adding 
> > > > > missing calls
> > > > > to ff_jni_exception_check.
> > > > > 
> > > > > [...]
> > > > 
> > > > Is it possible to store the log_ctx somewhere in the JNI?
> > > > 
> > > > We might at some point in the future forbid av_log(NULL, ...) calls, and
> > > > then it'd get complicated.
> > > 
> > > Patch updated with the following differences:
> > >   * All logging arguments in mediacodec_wrapper functions are now non
> > >   NULL
> > >   * The mediacodec buffer copy functions has been moved to a separate file
> > >   * The Mediacodec enum codec flags are properly retrieved from JNI
> > > 
> > > The codec extradata conversion to annex b simplification has not been
> > > addressed in this update. The bitstream filter api does not seem to
> > > provide a way to do the extradata conversion without feeding an actual
> > > packet to the api (av_bitstream_filter_filter) and i would like to keep
> > > the codec initialization in the init function.
> > > 
> > > The patchset has been pushed to a new branch:
> > > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support-v3
> > > 
> > > Matthieu
> > 
> > >  configure |5 
> > >  libavcodec/Makefile   |3 
> > >  libavcodec/allcodecs.c|1 
> > >  libavcodec/mediacodec_sw_buffer.c |  339 +++
> > >  libavcodec/mediacodec_sw_buffer.h |   62 +
> > >  libavcodec/mediacodec_wrapper.c   | 1674 
> > > ++
> > >  libavcodec/mediacodec_wrapper.h   |  122 ++
> > >  libavcodec/mediacodecdec.c|  563 
> > >  libavcodec/mediacodecdec.h|   82 +
> > >  libavcodec/mediacodecdec_h264.c   |  356 
> > >  10 files changed, 3207 insertions(+)
> > > f545068afece74d27cc04a365d9de7dcf5586a7d  
> > > 0002-lavc-add-h264-mediacodec-decoder.patch
> > > From 805c7b95433f1bfbbc5d47fd59a1bbb755edb112 Mon Sep 17 00:00:00 2001
> > > From: Matthieu Bouron 
> > > Date: Thu, 21 Jan 2016 09:29:39 +0100
> > > Subject: [PATCH 2/2] lavc: add h264 mediacodec decoder
> > 
> > breaks fate
> > swr-resample_lin-fltp-48000-44100
> > TESTswr-resample_lin-dblp-8000-44100
> > TESTswr-resample_lin-dblp-8000-48000
> > --- ./tests/ref/fate/source 2016-02-24 22:42:26.379879152 +0100
> > +++ tests/data/fate/source  2016-02-27 14:44:09.176735216 +0100
> > @@ -27,3 +27,4 @@
> >  compat/avisynth/windowsPorts/windows2linux.h
> >  compat/float/float.h
> >  

[FFmpeg-devel] [PATCH] aacenc: avoid double in quantize_bands.

[Reimar Döffinger]

I cannot see any point whatsoever to use
double here instead of float.
Using float allows for use of SIMD.
---
 libavcodec/aacenc_utils.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aacenc_utils.h b/libavcodec/aacenc_utils.h
index cb5bc8d..571b1e6 100644
--- a/libavcodec/aacenc_utils.h
+++ b/libavcodec/aacenc_utils.h
@@ -66,10 +66,9 @@ static inline void quantize_bands(int *out, const float *in, 
const float *scaled
   const float rounding)
 {
 int i;
-double qc;
 for (i = 0; i < size; i++) {
-qc = scaled[i] * Q34;
-out[i] = (int)FFMIN(qc + rounding, (double)maxval);
+float qc = scaled[i] * Q34;
+out[i] = (int)FFMIN(qc + rounding, (float)maxval);
 if (is_signed && in[i] < 0.0f) {
 out[i] = -out[i];
 }
-- 
2.7.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/6] lavc: factor apply_param_change() AV_EF_EXPLODE handling

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 07:21:37PM +0100, wm4 wrote:
> Remove the duplicated code for handling failure of apply_param_change().
> ---
>  libavcodec/utils.c | 34 +++---
>  1 file changed, 19 insertions(+), 15 deletions(-)

LGTM

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add the relaxed and acquire/releae flavors of avpriv_atomic_int_get and avpriv_atomic_int_set.

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 10:26 AM, Wan-Teh Chang  wrote:

> I'd like to reiterate that this is difficult for many good
> programmers.


I think you just hit the nail right on the head :). I think my personal
problem is that I don't quite understand what the actual problem is (your
wiki page on memory ordering was quite helpful here, thank you!), and how
the various release/acquire/memorybarrier/atomic functions help in solving
it (I still find this mind-bogglingly complex, I'll slowly read through the
documents you sent, but may take me a bit).

The fundamental problem being that it's difficult to understand, combined
with that we can't really grasp the severity of the issue (will files fail
to decode? will ffmpeg hang/crash? or is tsan just complaining for no
reason?), means that it's usually incredibly hard to do a good technical
review of these patches, so review may be slow'ish, sadly... I'm trying my
best but I'll make mistakes along the way.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 09:11:21PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 11:37:37AM -0800, NagaChaitanya Vellanki wrote:
> > ---
> >  libavutil/Makefile  |  1 +
> >  libavutil/color_utils.c | 53 
> > +
> >  2 files changed, 54 insertions(+)
> 
> to test avpriv_get_trc_function_from_trc(), one could
> for each index test the returned function at a few values, print the
> values and have "make fate" compare that output against a reference
> file

also see how other fate tests are done which compare some
output to a reference file
for example: 28a2107a8d61af7c7a26f9d4af0716ba12c112a7

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[wm4]

On Tue, 1 Mar 2016 20:57:12 +0100
Matthieu Bouron  wrote:

> On Tue, Mar 01, 2016 at 08:55:23PM +0100, Matthieu Bouron wrote:
> > On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:  
> > > On Tue, 1 Mar 2016 20:33:14 +0100
> > > Matthieu Bouron  wrote:
> > >   
> > > > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:  
> > > > > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> > > > > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > > > > Matthieu Bouron  wrote:
> > > > > > 
> > > > > > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > > > > > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > > > > > > Matthieu Bouron  wrote:
> > > > > > > >   
> > > > > > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron 
> > > > > > > > > wrote:  
> > > > > > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > From: Matthieu Bouron 
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > 
> > > > > > > > > > [...]
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > > Patch updated with the following differences:
> > > > > > > > > > >   * fix of switch/case code style
> > > > > > > > > > >   * removal of a miss declaration of FFJNIField enum as a 
> > > > > > > > > > > global variable
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > Patch updated with the following differences:
> > > > > > > > > >   * fixes a few typo in comments
> > > > > > > > > >   * fixes a if statement in ff_jni_init_jfields
> > > > > > > > > 
> > > > > > > > > Patch updated with the following differences:
> > > > > > > > >   * fixes a few typo in comments and message logs
> > > > > > > > >   * add missing .so at end of library names when trying to 
> > > > > > > > > find
> > > > > > > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > > > > > > >   * reintroduce public functions that allow the user to set 
> > > > > > > > > the Java
> > > > > > > > >   virtual machine (av_jni_(set,get)_java_vm) as the private 
> > > > > > > > > C++
> > > > > > > > >   JniInvocation wrapper is not available on all devices 
> > > > > > > > > (android >= 4.4)  
> > > > > > > > 
> > > > > > > > I'm wondering if the VM should be stored per AVCodecContext. 
> > > > > > > > (Since it
> > > > > > > > has to be set explicitly again by the user.)  
> > > > > > > 
> > > > > > > I think it is fine to store one VM for all the AVCodecContext as 
> > > > > > > it will
> > > > > > > be the same during all the lifetime of the application. I should 
> > > > > > > also
> > > > > > > enforce that the VM cannot be changed afterwards.
> > > > > > > 
> > > > > > > av_jni_set_java_vm stores the Java VM pointer locally in jni.c 
> > > > > > > and not in
> > > > > > > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. 
> > > > > > > I've done
> > > > > > > it that way because if at some point we are to include ffjni.c 
> > > > > > > from
> > > > > > > libavformat it won't work (it will only set the java vm in the 
> > > > > > > libavcodec
> > > > > > > memory space).
> > > > > > 
> > > > > > The problem is that this is not library-safe. What if two libs 
> > > > > > within
> > > > > > the process (which both are using libavcodec) are setting a 
> > > > > > different
> > > > > > VM?
> > > > > 
> > > > > In the Android application context, you only have, AFAIK, one VM 
> > > > > running
> > > > > during the lifetime of the application. The code does handle the 
> > > > > general
> > > > 
> > > > does *not* (sorry)
> > > >   
> > > > > JNI case (even outside Android) but do we really want to do that 
> > > > > anyway ?
> > > 
> > > If there's guaranteed to be exactly one, I don't get why we can't get
> > > it into existence ourselves?
> > >
> > > Where exactly would an application get the VM handle from?  
> > 
> > You get the Java VM pointer when JNI_onLoad(JavaVM *vm, void *reserved) is
> > executed at library load. This is where you can pass the pointer to lavc.
> > 
> > IMHO, av_jni_set_java_vm should set the VM once and then warn (or return an 
> > error)
> > if the user is providing a different Java VM pointer.
> > 
> > In theory, on some version of Android, you can spawn your own VM using their
> > private C++ JniInvocation wrapper.
> > On a regular desktop, you can create Java VMs (using JNI_createJavaVM).  
> 
> Also note that the JniInvocation wrapper is still used if the user hasn't
> provided a JavaVM using av_jni_set_java_vm but that will only work on
> android >= 4.4.2

I still don't quite understand the 

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 11:37:37AM -0800, NagaChaitanya Vellanki wrote:
> ---
>  libavutil/Makefile  |  1 +
>  libavutil/color_utils.c | 53 
> +
>  2 files changed, 54 insertions(+)

to test avpriv_get_trc_function_from_trc(), one could
for each index test the returned function at a few values, print the
values and have "make fate" compare that output against a reference
file

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Tue, Mar 01, 2016 at 08:55:23PM +0100, Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 20:33:14 +0100
> > Matthieu Bouron  wrote:
> > 
> > > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> > > > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:  
> > > > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > > > Matthieu Bouron  wrote:
> > > > >   
> > > > > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:  
> > > > > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > > > > > Matthieu Bouron  wrote:
> > > > > > > 
> > > > > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron 
> > > > > > > > wrote:
> > > > > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > >   
> > > > > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron 
> > > > > > > > > > wrote:  
> > > > > > > > > > > From: Matthieu Bouron 
> > > > > > > > > > >  
> > > > > > > > > >  
> > > > > > > > > 
> > > > > > > > > [...]
> > > > > > > > > 
> > > > > > > > >   
> > > > > > > > > >
> > > > > > > > > > Patch updated with the following differences:
> > > > > > > > > >   * fix of switch/case code style
> > > > > > > > > >   * removal of a miss declaration of FFJNIField enum as a 
> > > > > > > > > > global variable
> > > > > > > > > >
> > > > > > > > > >  
> > > > > > > > > Patch updated with the following differences:
> > > > > > > > >   * fixes a few typo in comments
> > > > > > > > >   * fixes a if statement in ff_jni_init_jfields  
> > > > > > > > 
> > > > > > > > Patch updated with the following differences:
> > > > > > > >   * fixes a few typo in comments and message logs
> > > > > > > >   * add missing .so at end of library names when trying to find
> > > > > > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > > > > > >   * reintroduce public functions that allow the user to set the 
> > > > > > > > Java
> > > > > > > >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> > > > > > > >   JniInvocation wrapper is not available on all devices 
> > > > > > > > (android >= 4.4)
> > > > > > > 
> > > > > > > I'm wondering if the VM should be stored per AVCodecContext. 
> > > > > > > (Since it
> > > > > > > has to be set explicitly again by the user.)
> > > > > > 
> > > > > > I think it is fine to store one VM for all the AVCodecContext as it 
> > > > > > will
> > > > > > be the same during all the lifetime of the application. I should 
> > > > > > also
> > > > > > enforce that the VM cannot be changed afterwards.
> > > > > > 
> > > > > > av_jni_set_java_vm stores the Java VM pointer locally in jni.c and 
> > > > > > not in
> > > > > > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've 
> > > > > > done
> > > > > > it that way because if at some point we are to include ffjni.c from
> > > > > > libavformat it won't work (it will only set the java vm in the 
> > > > > > libavcodec
> > > > > > memory space).  
> > > > > 
> > > > > The problem is that this is not library-safe. What if two libs within
> > > > > the process (which both are using libavcodec) are setting a different
> > > > > VM?  
> > > > 
> > > > In the Android application context, you only have, AFAIK, one VM running
> > > > during the lifetime of the application. The code does handle the 
> > > > general  
> > > 
> > > does *not* (sorry)
> > > 
> > > > JNI case (even outside Android) but do we really want to do that anyway 
> > > > ?  
> > 
> > If there's guaranteed to be exactly one, I don't get why we can't get
> > it into existence ourselves?
> >
> > Where exactly would an application get the VM handle from?
> 
> You get the Java VM pointer when JNI_onLoad(JavaVM *vm, void *reserved) is
> executed at library load. This is where you can pass the pointer to lavc.
> 
> IMHO, av_jni_set_java_vm should set the VM once and then warn (or return an 
> error)
> if the user is providing a different Java VM pointer.
> 
> In theory, on some version of Android, you can spawn your own VM using their
> private C++ JniInvocation wrapper.
> On a regular desktop, you can create Java VMs (using JNI_createJavaVM).

Also note that the JniInvocation wrapper is still used if the user hasn't
provided a JavaVM using av_jni_set_java_vm but that will only work on
android >= 4.4.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mov: Set display aspect ratio for avid dv

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 10:46:17AM +0100, Carl Eugen Hoyos wrote:
> On Monday 29 February 2016 01:44:13 pm Michael Niedermayer wrote:
> > On Mon, Feb 29, 2016 at 11:52:24AM +0100, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch fixes ticket #5271 for me.
> > >
> > > Please comment, Carl Eugen
> > >
> > >  mov.c |5 +
> > >  1 file changed, 5 insertions(+)
> > > ef08b944e3cb77bd7311187ecbfbdae719147d92  patchaviddv.diff
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index 043f4a9..888b2ad 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -1461,6 +1461,11 @@ static int mov_read_ares(MOVContext *c,
> > > AVIOContext *pb, MOVAtom atom) if (avio_rb16(pb) == 0xd4d)
> > >  codec->width = 1440;
> > >  return 0;
> > > +} else if (codec->codec_tag == MKTAG('A', 'V', 'd', '1') &&
> > > +   atom.size >= 24) {
> > > +avio_skip(pb, 12);
> > > +   
> > > c->fc->streams[c->fc->nb_streams-1]->display_aspect_ratio.num =
> > > avio_rb32(pb);
> > >
> > > +   
> > > c->fc->streams[c->fc->nb_streams-1]->display_aspect_ratio.den =
> > > avio_rb32(pb) * avio_rb32(pb);
> >
> > probably not wrong but i would use a temporary variable here
> > one also could check for integer overflow then
> 
> New patch attached.
> 
> Please comment, Carl Eugen

probably ok

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:
> On Tue, 1 Mar 2016 20:33:14 +0100
> Matthieu Bouron  wrote:
> 
> > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> > > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:  
> > > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > > Matthieu Bouron  wrote:
> > > >   
> > > > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:  
> > > > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > > > > Matthieu Bouron  wrote:
> > > > > > 
> > > > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:  
> > > > > > >   
> > > > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > >   
> > > > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron 
> > > > > > > > > wrote:  
> > > > > > > > > > From: Matthieu Bouron 
> > > > > > > > > >  
> > > > > > > > >  
> > > > > > > > 
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > >   
> > > > > > > > >
> > > > > > > > > Patch updated with the following differences:
> > > > > > > > >   * fix of switch/case code style
> > > > > > > > >   * removal of a miss declaration of FFJNIField enum as a 
> > > > > > > > > global variable
> > > > > > > > >
> > > > > > > > >  
> > > > > > > > Patch updated with the following differences:
> > > > > > > >   * fixes a few typo in comments
> > > > > > > >   * fixes a if statement in ff_jni_init_jfields  
> > > > > > > 
> > > > > > > Patch updated with the following differences:
> > > > > > >   * fixes a few typo in comments and message logs
> > > > > > >   * add missing .so at end of library names when trying to find
> > > > > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > > > > >   * reintroduce public functions that allow the user to set the 
> > > > > > > Java
> > > > > > >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> > > > > > >   JniInvocation wrapper is not available on all devices (android 
> > > > > > > >= 4.4)
> > > > > > 
> > > > > > I'm wondering if the VM should be stored per AVCodecContext. (Since 
> > > > > > it
> > > > > > has to be set explicitly again by the user.)
> > > > > 
> > > > > I think it is fine to store one VM for all the AVCodecContext as it 
> > > > > will
> > > > > be the same during all the lifetime of the application. I should also
> > > > > enforce that the VM cannot be changed afterwards.
> > > > > 
> > > > > av_jni_set_java_vm stores the Java VM pointer locally in jni.c and 
> > > > > not in
> > > > > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've 
> > > > > done
> > > > > it that way because if at some point we are to include ffjni.c from
> > > > > libavformat it won't work (it will only set the java vm in the 
> > > > > libavcodec
> > > > > memory space).  
> > > > 
> > > > The problem is that this is not library-safe. What if two libs within
> > > > the process (which both are using libavcodec) are setting a different
> > > > VM?  
> > > 
> > > In the Android application context, you only have, AFAIK, one VM running
> > > during the lifetime of the application. The code does handle the general  
> > 
> > does *not* (sorry)
> > 
> > > JNI case (even outside Android) but do we really want to do that anyway ? 
> > >  
> 
> If there's guaranteed to be exactly one, I don't get why we can't get
> it into existence ourselves?
>
> Where exactly would an application get the VM handle from?

You get the Java VM pointer when JNI_onLoad(JavaVM *vm, void *reserved) is
executed at library load. This is where you can pass the pointer to lavc.

IMHO, av_jni_set_java_vm should set the VM once and then warn (or return an 
error)
if the user is providing a different Java VM pointer.

In theory, on some version of Android, you can spawn your own VM using their
private C++ JniInvocation wrapper.
On a regular desktop, you can create Java VMs (using JNI_createJavaVM).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: avoid unneeded allocation if the frame is to be skipped

[Paul B Mahol]

On 3/1/16, Matthieu Bouron  wrote:
> From: Matthieu Bouron 
>
> ---
>  libavcodec/mjpegdec.c | 7 +++
>  1 file changed, 7 insertions(+)
>

probbably ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

---
 libavutil/Makefile  |  1 +
 libavutil/color_utils.c | 53 +
 2 files changed, 54 insertions(+)

diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32 
\
 bprint  \
 cast5   \
 camellia\
+color_utils \
 cpu \
 crc \
 des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..0881da8 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "common.h"
 #include "libavutil/color_utils.h"
 #include "libavutil/pixfmt.h"
 
@@ -216,3 +217,55 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharact
 }
 return func;
 }
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+static int test_avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharacteristic trc, avpriv_trc_function func)
+{
+
+if(avpriv_get_trc_function_from_trc(trc) != func) {
+printf("Failed: invalid function returned for %d\n", trc);
+return 1;
+}
+
+printf("Passed!\n");
+return 0;
+}
+
+int main(int argc, char ** argv)
+{
+int i, error_count = 0;
+struct test {
+enum AVColorTransferCharacteristic trc;
+avpriv_trc_function func;
+} tests[] = {
+{ AVCOL_TRC_BT709, avpriv_trc_bt709 },
+{ AVCOL_TRC_SMPTE170M, avpriv_trc_bt709 },
+{ AVCOL_TRC_BT2020_10, avpriv_trc_bt709 },
+{ AVCOL_TRC_BT2020_12, avpriv_trc_bt709 },
+{ AVCOL_TRC_GAMMA22, avpriv_trc_gamma22 },
+{ AVCOL_TRC_GAMMA28, avpriv_trc_gamma28 },
+{ AVCOL_TRC_SMPTE240M, avpriv_trc_smpte240M },
+{ AVCOL_TRC_LINEAR, avpriv_trc_linear },
+{ AVCOL_TRC_LOG, avpriv_trc_log },
+{ AVCOL_TRC_LOG_SQRT, avpriv_trc_log_sqrt },
+{ AVCOL_TRC_IEC61966_2_4, avpriv_trc_iec61966_2_4 },
+{ AVCOL_TRC_BT1361_ECG, avpriv_trc_bt1361 },
+{ AVCOL_TRC_IEC61966_2_1, avpriv_trc_iec61966_2_1 },
+{ AVCOL_TRC_SMPTEST2084, avpriv_trc_smpte_st2084 },
+{ AVCOL_TRC_SMPTEST428_1, avpriv_trc_smpte_st428_1 },
+{ AVCOL_TRC_RESERVED0, NULL },
+{ AVCOL_TRC_UNSPECIFIED, NULL },
+{ AVCOL_TRC_RESERVED, NULL }
+};
+
+for(i = 0; i < FF_ARRAY_ELEMS(tests); i++) {
+if(test_avpriv_get_trc_function_from_trc(tests[i].trc, tests[i].func)) 
{
+error_count++;
+}
+}
+return !!error_count;
+}
+// LCOV_EXCL_STOP
+#endif
-- 
2.7.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[wm4]

On Tue, 1 Mar 2016 20:33:14 +0100
Matthieu Bouron  wrote:

> On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:  
> > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > Matthieu Bouron  wrote:
> > >   
> > > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:  
> > > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > > > Matthieu Bouron  wrote:
> > > > > 
> > > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> > > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > > > 
> > > > > > > wrote:
> > > > > > >   
> > > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron 
> > > > > > > > wrote:  
> > > > > > > > > From: Matthieu Bouron 
> > > > > > > > >  
> > > > > > > >  
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > >   
> > > > > > > >
> > > > > > > > Patch updated with the following differences:
> > > > > > > >   * fix of switch/case code style
> > > > > > > >   * removal of a miss declaration of FFJNIField enum as a 
> > > > > > > > global variable
> > > > > > > >
> > > > > > > >  
> > > > > > > Patch updated with the following differences:
> > > > > > >   * fixes a few typo in comments
> > > > > > >   * fixes a if statement in ff_jni_init_jfields  
> > > > > > 
> > > > > > Patch updated with the following differences:
> > > > > >   * fixes a few typo in comments and message logs
> > > > > >   * add missing .so at end of library names when trying to find
> > > > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > > > >   * reintroduce public functions that allow the user to set the Java
> > > > > >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> > > > > >   JniInvocation wrapper is not available on all devices (android >= 
> > > > > > 4.4)
> > > > > 
> > > > > I'm wondering if the VM should be stored per AVCodecContext. (Since it
> > > > > has to be set explicitly again by the user.)
> > > > 
> > > > I think it is fine to store one VM for all the AVCodecContext as it will
> > > > be the same during all the lifetime of the application. I should also
> > > > enforce that the VM cannot be changed afterwards.
> > > > 
> > > > av_jni_set_java_vm stores the Java VM pointer locally in jni.c and not 
> > > > in
> > > > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've done
> > > > it that way because if at some point we are to include ffjni.c from
> > > > libavformat it won't work (it will only set the java vm in the 
> > > > libavcodec
> > > > memory space).  
> > > 
> > > The problem is that this is not library-safe. What if two libs within
> > > the process (which both are using libavcodec) are setting a different
> > > VM?  
> > 
> > In the Android application context, you only have, AFAIK, one VM running
> > during the lifetime of the application. The code does handle the general  
> 
> does *not* (sorry)
> 
> > JNI case (even outside Android) but do we really want to do that anyway ?  

If there's guaranteed to be exactly one, I don't get why we can't get
it into existence ourselves?

Where exactly would an application get the VM handle from?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 20:10:50 +0100
> > Matthieu Bouron  wrote:
> > 
> > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > > Matthieu Bouron  wrote:
> > > >   
> > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:  
> > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > > 
> > > > > > wrote:
> > > > > > 
> > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:  
> > > > > > >   
> > > > > > > > From: Matthieu Bouron 
> > > > > > > >
> > > > > > >
> > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > 
> > > > > > >
> > > > > > > Patch updated with the following differences:
> > > > > > >   * fix of switch/case code style
> > > > > > >   * removal of a miss declaration of FFJNIField enum as a global 
> > > > > > > variable
> > > > > > >
> > > > > > >
> > > > > > Patch updated with the following differences:
> > > > > >   * fixes a few typo in comments
> > > > > >   * fixes a if statement in ff_jni_init_jfields
> > > > > 
> > > > > Patch updated with the following differences:
> > > > >   * fixes a few typo in comments and message logs
> > > > >   * add missing .so at end of library names when trying to find
> > > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > > >   * reintroduce public functions that allow the user to set the Java
> > > > >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> > > > >   JniInvocation wrapper is not available on all devices (android >= 
> > > > > 4.4)  
> > > > 
> > > > I'm wondering if the VM should be stored per AVCodecContext. (Since it
> > > > has to be set explicitly again by the user.)  
> > > 
> > > I think it is fine to store one VM for all the AVCodecContext as it will
> > > be the same during all the lifetime of the application. I should also
> > > enforce that the VM cannot be changed afterwards.
> > > 
> > > av_jni_set_java_vm stores the Java VM pointer locally in jni.c and not in
> > > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've done
> > > it that way because if at some point we are to include ffjni.c from
> > > libavformat it won't work (it will only set the java vm in the libavcodec
> > > memory space).
> > 
> > The problem is that this is not library-safe. What if two libs within
> > the process (which both are using libavcodec) are setting a different
> > VM?
> 
> In the Android application context, you only have, AFAIK, one VM running
> during the lifetime of the application. The code does handle the general

does *not* (sorry)

> JNI case (even outside Android) but do we really want to do that anyway ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[Clément Bœsch]

On Tue, Mar 01, 2016 at 10:41:32AM -0800, NagaChaitanya Vellanki wrote:
> ---
>  libavutil/Makefile  |  1 +
>  libavutil/color_utils.c | 52 
> +
>  2 files changed, 53 insertions(+)
> 

I'm afraid testing the result of a switch with an array has absolutely no
value whatsoever.

Regards,

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> On Tue, 1 Mar 2016 20:10:50 +0100
> Matthieu Bouron  wrote:
> 
> > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > Matthieu Bouron  wrote:
> > >   
> > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:  
> > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> > > > > > > From: Matthieu Bouron 
> > > > > > >
> > > > > >
> > > > > 
> > > > > [...]
> > > > > 
> > > > > 
> > > > > >
> > > > > > Patch updated with the following differences:
> > > > > >   * fix of switch/case code style
> > > > > >   * removal of a miss declaration of FFJNIField enum as a global 
> > > > > > variable
> > > > > >
> > > > > >
> > > > > Patch updated with the following differences:
> > > > >   * fixes a few typo in comments
> > > > >   * fixes a if statement in ff_jni_init_jfields
> > > > 
> > > > Patch updated with the following differences:
> > > >   * fixes a few typo in comments and message logs
> > > >   * add missing .so at end of library names when trying to find
> > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > >   * reintroduce public functions that allow the user to set the Java
> > > >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> > > >   JniInvocation wrapper is not available on all devices (android >= 
> > > > 4.4)  
> > > 
> > > I'm wondering if the VM should be stored per AVCodecContext. (Since it
> > > has to be set explicitly again by the user.)  
> > 
> > I think it is fine to store one VM for all the AVCodecContext as it will
> > be the same during all the lifetime of the application. I should also
> > enforce that the VM cannot be changed afterwards.
> > 
> > av_jni_set_java_vm stores the Java VM pointer locally in jni.c and not in
> > ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've done
> > it that way because if at some point we are to include ffjni.c from
> > libavformat it won't work (it will only set the java vm in the libavcodec
> > memory space).
> 
> The problem is that this is not library-safe. What if two libs within
> the process (which both are using libavcodec) are setting a different
> VM?

In the Android application context, you only have, AFAIK, one VM running
during the lifetime of the application. The code does handle the general
JNI case (even outside Android) but do we really want to do that anyway ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Read |state| under the protection of |mutex| or |progress_mutex|.

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 1:47 PM, Wan-Teh Chang 
wrote:

> Hi Ronald,
>
> On Fri, Feb 26, 2016 at 12:16 PM, Ronald S. Bultje 
> wrote:
> >
> > This will be slower, right? Is this an actual issue? Like, can you point
> to
> > cases like [1] (i.e. a real-world race condition with real-world
> > consequences) that were fixed with your patch?
> >
> > Ronald
> >
> > https://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/
>
> With the new relaxed and acquire/release atomic int get and set
> functions I proposed in
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190516.html, we
> have the means to make the current code portable while preserving the
> exact performance for x86/x86_64. But unlike the progress[field]
> values, I am strongly against using this approach for |state| for two
> reasons.
>
> 1) |state| is guarded by one of two mutexes: |mutex| and
> |progress_mutex|. Which mutex should guard |state| when is not
> documented, and I haven't reverse-engineered that policy.


I can help there.

state is an enum with the following values:

STATE_INPUT_READY
STATE_SETTING_UP
STATE_GET_BUFFER
STATE_GET_FORMAT
STATE_SETUP_FINISHED

Transitions are like this:

- INPUT_READY to SETTING_UP in submit_packet() (main thread), guarded by
mutex. frame_worker_thread() (frame decoder thread[s]) awaits this state
change holding mutex. The accompanying cond is input_cond.

- any transition between SETTING_UP, GET_BUFFER and GET_FORMAT in
submit_packet (main thread) and
thread_get_buffer_internal/ff_thread_get_format (decoder thread[s]),
guarded by progress_mutex. The accompanying cond is progress_cond.

- SETTING_UP/GET_BUFFER/GET_FORMAT to SETUP_FINISHED in
ff_thread_finish_setup() (decoder thread[s]), guarded by progress_mutex.
The accompanying cond is progress_cond. This condition is awaited before
submit_packet() (main thread) returns to ensure that get_formats and
get_buffer was called in the context of the call to submit_packet(),
assuming the application did not explicitly say that calls to these
callbacks are threadsafe. I agree that the code at the bottom of
submit_packet() is ... Strange :) But I'm not convinced it's buggy. I'm
sure tsan hates it. I wouldn't mind patches that clean it up assuming they
don't make the code harder to read or slower.

- SETUP_FINISHED to INPUT_READY is in frame_worker_thread() (decoder
thread[s]) and is guarded by both mutex as well as progress_mutex. This
signals output_cond and progress_cond (both under control of
progress_mutex).  ff_thread_decode_frame() (main thread) uses this
transition controlled by output_cond to return decoded frames to the
application after calling submit_packet().

Hope this helps,
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] sdp: fix opus sprop-stereo fmtp syntax

[Michael Niedermayer]

On Mon, Feb 29, 2016 at 08:08:14PM -0800, Mark Harris wrote:
> ---
>  libavformat/sdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

https://tools.ietf.org/html/draft-ietf-payload-rtp-opus-11 uses "="
in the example
so ok and applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[wm4]

On Tue, 1 Mar 2016 20:10:50 +0100
Matthieu Bouron  wrote:

> On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 19:52:08 +0100
> > Matthieu Bouron  wrote:
> >   
> > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:  
> > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > 
> > > > wrote:
> > > > 
> > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> > > > > > From: Matthieu Bouron 
> > > > > >
> > > > >
> > > > 
> > > > [...]
> > > > 
> > > > 
> > > > >
> > > > > Patch updated with the following differences:
> > > > >   * fix of switch/case code style
> > > > >   * removal of a miss declaration of FFJNIField enum as a global 
> > > > > variable
> > > > >
> > > > >
> > > > Patch updated with the following differences:
> > > >   * fixes a few typo in comments
> > > >   * fixes a if statement in ff_jni_init_jfields
> > > 
> > > Patch updated with the following differences:
> > >   * fixes a few typo in comments and message logs
> > >   * add missing .so at end of library names when trying to find
> > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > >   * reintroduce public functions that allow the user to set the Java
> > >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> > >   JniInvocation wrapper is not available on all devices (android >= 4.4)  
> > 
> > I'm wondering if the VM should be stored per AVCodecContext. (Since it
> > has to be set explicitly again by the user.)  
> 
> I think it is fine to store one VM for all the AVCodecContext as it will
> be the same during all the lifetime of the application. I should also
> enforce that the VM cannot be changed afterwards.
> 
> av_jni_set_java_vm stores the Java VM pointer locally in jni.c and not in
> ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've done
> it that way because if at some point we are to include ffjni.c from
> libavformat it won't work (it will only set the java vm in the libavcodec
> memory space).

The problem is that this is not library-safe. What if two libs within
the process (which both are using libavcodec) are setting a different
VM?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> On Tue, 1 Mar 2016 19:52:08 +0100
> Matthieu Bouron  wrote:
> 
> > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > 
> > > wrote:
> > >   
> > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:  
> > > > > From: Matthieu Bouron 
> > > > >  
> > > >  
> > > 
> > > [...]
> > > 
> > >   
> > > >
> > > > Patch updated with the following differences:
> > > >   * fix of switch/case code style
> > > >   * removal of a miss declaration of FFJNIField enum as a global 
> > > > variable
> > > >
> > > >  
> > > Patch updated with the following differences:
> > >   * fixes a few typo in comments
> > >   * fixes a if statement in ff_jni_init_jfields  
> > 
> > Patch updated with the following differences:
> >   * fixes a few typo in comments and message logs
> >   * add missing .so at end of library names when trying to find
> >   JNI_GetCreatedVMs symbol (also add libart.so)
> >   * reintroduce public functions that allow the user to set the Java
> >   virtual machine (av_jni_(set,get)_java_vm) as the private C++
> >   JniInvocation wrapper is not available on all devices (android >= 4.4)
> 
> I'm wondering if the VM should be stored per AVCodecContext. (Since it
> has to be set explicitly again by the user.)

I think it is fine to store one VM for all the AVCodecContext as it will
be the same during all the lifetime of the application. I should also
enforce that the VM cannot be changed afterwards.

av_jni_set_java_vm stores the Java VM pointer locally in jni.c and not in
ffjni.c and it is retrieved in jni.c using av_jni_get_java_vm. I've done
it that way because if at some point we are to include ffjni.c from
libavformat it won't work (it will only set the java vm in the libavcodec
memory space).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc: add h264 mediacodec decoder

[Matthieu Bouron]

On Sat, Feb 27, 2016 at 04:28:43PM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > > On Tue, 23 Feb 2016 09:53:43 +0100
> > > Matthieu Bouron  wrote:
> > > 
> > > > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer wrote:
> > > > > On Mon, Feb 22, 2016 at 12:20:36PM +0100, Matthieu Bouron wrote:  
> > > > > > From: Matthieu Bouron   
> > > > > [...]  
> > > > > > +codec = (*env)->NewObject(env, 
> > > > > > jfields.mediacodec_list_class, jfields.init_id, 0);
> > > > > > +if (!codec) {
> > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not create media 
> > > > > > codec list\n");
> > > > > > +goto done;
> > > > > > +}
> > > > > > +
> > > > > > +tmp = (*env)->CallObjectMethod(env, codec, 
> > > > > > jfields.find_decoder_for_format_id, format);
> > > > > > +if (!tmp) {
> > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not find decoder in 
> > > > > > media codec list\n");
> > > > > > +goto done;
> > > > > > +}
> > > > > > +
> > > > > > +name = ff_jni_jstring_to_utf_chars(env, tmp, NULL);
> > > > > > +if (!name) {  
> > > > >   
> > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not convert jstring 
> > > > > > to utf chars\n");  
> > > > > 
> > > > > some non NULL context would be better, if possible, so the user knows
> > > > > where an error came from  
> > > > 
> > > > It would require to pass the log_ctx (avctx) as an argument of
> > > > ff_AMediaCodecList_getCodecByName.
> > > > 
> > > > All the functions of this wrapper does not take a log_ctx as argument
> > > > to be as close as possible to the original NDK MediaCodec API. The
> > > > NDK MediaCodec API does not provide any wrapper around MediaCodecList.
> > > > 
> > > > I would like the whole wrapper API to be consistent but also as close as
> > > > possible to original one.
> > > > If you think it's mandatory I can add a log_ctx argument to every
> > > > functions of the wrapper API (so it will be used directly by av_log and
> > > > ff_jni_exception_check).
> > > > 
> > > > On another note, I fixed locally this part of the code by adding 
> > > > missing calls
> > > > to ff_jni_exception_check.
> > > > 
> > > > [...]
> > > 
> > > Is it possible to store the log_ctx somewhere in the JNI?
> > > 
> > > We might at some point in the future forbid av_log(NULL, ...) calls, and
> > > then it'd get complicated.
> > 
> > Patch updated with the following differences:
> >   * All logging arguments in mediacodec_wrapper functions are now non
> >   NULL
> >   * The mediacodec buffer copy functions has been moved to a separate file
> >   * The Mediacodec enum codec flags are properly retrieved from JNI
> > 
> > The codec extradata conversion to annex b simplification has not been
> > addressed in this update. The bitstream filter api does not seem to
> > provide a way to do the extradata conversion without feeding an actual
> > packet to the api (av_bitstream_filter_filter) and i would like to keep
> > the codec initialization in the init function.
> > 
> > The patchset has been pushed to a new branch:
> > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support-v3
> > 
> > Matthieu
> 
> >  configure |5 
> >  libavcodec/Makefile   |3 
> >  libavcodec/allcodecs.c|1 
> >  libavcodec/mediacodec_sw_buffer.c |  339 +++
> >  libavcodec/mediacodec_sw_buffer.h |   62 +
> >  libavcodec/mediacodec_wrapper.c   | 1674 
> > ++
> >  libavcodec/mediacodec_wrapper.h   |  122 ++
> >  libavcodec/mediacodecdec.c|  563 
> >  libavcodec/mediacodecdec.h|   82 +
> >  libavcodec/mediacodecdec_h264.c   |  356 
> >  10 files changed, 3207 insertions(+)
> > f545068afece74d27cc04a365d9de7dcf5586a7d  
> > 0002-lavc-add-h264-mediacodec-decoder.patch
> > From 805c7b95433f1bfbbc5d47fd59a1bbb755edb112 Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron 
> > Date: Thu, 21 Jan 2016 09:29:39 +0100
> > Subject: [PATCH 2/2] lavc: add h264 mediacodec decoder
> 
> breaks fate
> swr-resample_lin-fltp-48000-44100
> TESTswr-resample_lin-dblp-8000-44100
> TESTswr-resample_lin-dblp-8000-48000
> --- ./tests/ref/fate/source 2016-02-24 22:42:26.379879152 +0100
> +++ tests/data/fate/source  2016-02-27 14:44:09.176735216 +0100
> @@ -27,3 +27,4 @@
>  compat/avisynth/windowsPorts/windows2linux.h
>  compat/float/float.h
>  compat/float/limits.h
> +libavcodec/mediacodec_sw_buffer.h
> Test source failed. Look at tests/data/fate/source.err for details.
> make: *** [fate-source] Error 1
> make: *** Waiting for unfinished jobs

New patch attached fixing the issue. It also fixes an issue while the
binding was trying to access the field 

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[wm4]

On Tue, 1 Mar 2016 19:52:08 +0100
Matthieu Bouron  wrote:

> On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > wrote:
> >   
> > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:  
> > > > From: Matthieu Bouron 
> > > >  
> > >  
> > 
> > [...]
> > 
> >   
> > >
> > > Patch updated with the following differences:
> > >   * fix of switch/case code style
> > >   * removal of a miss declaration of FFJNIField enum as a global variable
> > >
> > >  
> > Patch updated with the following differences:
> >   * fixes a few typo in comments
> >   * fixes a if statement in ff_jni_init_jfields  
> 
> Patch updated with the following differences:
>   * fixes a few typo in comments and message logs
>   * add missing .so at end of library names when trying to find
>   JNI_GetCreatedVMs symbol (also add libart.so)
>   * reintroduce public functions that allow the user to set the Java
>   virtual machine (av_jni_(set,get)_java_vm) as the private C++
>   JniInvocation wrapper is not available on all devices (android >= 4.4)

I'm wondering if the VM should be stored per AVCodecContext. (Since it
has to be set explicitly again by the user.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Move the |die| member of FrameThreadContext to PerThreadContext.

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 1:15 PM, Wan-Teh Chang 
wrote:

> On Fri, Feb 26, 2016 at 12:14 PM, Ronald S. Bultje 
> wrote:
> >
> > Is probably OK since it doesn't introduce new lock/unlock pairs, yes. We
> > typically don't care about a few bytes of memory.
>
> Hi Ronald,
>
> I just signed off this patch and submitted it in
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190520.html.
>
> Does the patch need additional review? Could you approve and commit
> the patch for me?


Okiedokie, pushed.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron wrote:
> On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> wrote:
> 
> > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > >
> >
> 
> [...]
> 
> 
> >
> > Patch updated with the following differences:
> >   * fix of switch/case code style
> >   * removal of a miss declaration of FFJNIField enum as a global variable
> >
> >
> Patch updated with the following differences:
>   * fixes a few typo in comments
>   * fixes a if statement in ff_jni_init_jfields

Patch updated with the following differences:
  * fixes a few typo in comments and message logs
  * add missing .so at end of library names when trying to find
  JNI_GetCreatedVMs symbol (also add libart.so)
  * reintroduce public functions that allow the user to set the Java
  virtual machine (av_jni_(set,get)_java_vm) as the private C++
  JniInvocation wrapper is not available on all devices (android >= 4.4)
>From 653f6f02efad5dd3bf3aeb328fd5ee2af1c7e5c6 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Mon, 28 Sep 2015 15:18:56 +0200
Subject: [PATCH 1/2] lavc: add JNI support

---
 configure   |   5 +
 libavcodec/Makefile |   4 +
 libavcodec/ffjni.c  | 483 
 libavcodec/ffjni.h  | 148 
 libavcodec/jni.c|  65 +++
 libavcodec/jni.h|  42 +
 6 files changed, 747 insertions(+)
 create mode 100644 libavcodec/ffjni.c
 create mode 100644 libavcodec/ffjni.h
 create mode 100644 libavcodec/jni.c
 create mode 100644 libavcodec/jni.h

diff --git a/configure b/configure
index 8491fa1..fe94f84 100755
--- a/configure
+++ b/configure
@@ -208,6 +208,7 @@ External library support:
   --enable-gnutls  enable gnutls, needed for https support
if openssl is not used [no]
   --disable-iconv  disable iconv [autodetect]
+  --enable-jni enable JNI support [no]
   --enable-ladspa  enable LADSPA audio filtering [no]
   --enable-libass  enable libass subtitles rendering,
needed for subtitles and ass filter [no]
@@ -1436,6 +1437,7 @@ EXTERNAL_LIBRARY_LIST="
 gmp
 gnutls
 iconv
+jni
 ladspa
 libass
 libbluray
@@ -5544,6 +5546,8 @@ enabled decklink  && { check_header DeckLinkAPI.h || die "ERROR: DeckLin
 enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h header not found"; }
 enabled gmp   && require2 gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls/gnutls.h gnutls_global_init
+enabled jni   && { [ $target_os = "android" ] && check_header jni.h && enabled pthreads &&
+   check_lib2 "dlfcn.h" dlopen -ldl; }
 enabled ladspa&& { check_header ladspa.h || die "ERROR: ladspa.h header not found"; }
 enabled libiec61883   && require libiec61883 libiec61883/iec61883.h iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
 enabled libass&& require_pkg_config libass ass/ass.h ass_library_init
@@ -6312,6 +6316,7 @@ echo "threading support ${thread_type-no}"
 echo "safe bitstream reader ${safe_bitstream_reader-no}"
 echo "SDL support   ${sdl-no}"
 echo "opencl enabled${opencl-no}"
+echo "JNI support   ${jni-no}"
 echo "texi2html enabled ${texi2html-no}"
 echo "perl enabled  ${perl-no}"
 echo "pod2man enabled   ${pod2man-no}"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 667e257..c7a0ede 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -9,6 +9,7 @@ HEADERS = avcodec.h \
   d3d11va.h \
   dirac.h   \
   dxva2.h   \
+  jni.h \
   qsv.h \
   vaapi.h   \
   vda.h \
@@ -30,6 +31,7 @@ OBJS = allcodecs.o  \
dirac.o  \
dv_profile.o \
imgconvert.o \
+   jni.o\
mathtables.o \
options.o\
parser.o

Re: [FFmpeg-devel] [PATCH] Read |state| under the protection of |mutex| or |progress_mutex|.

[Wan-Teh Chang]

Hi Ronald,

On Fri, Feb 26, 2016 at 12:16 PM, Ronald S. Bultje  wrote:
>
> This will be slower, right? Is this an actual issue? Like, can you point to
> cases like [1] (i.e. a real-world race condition with real-world
> consequences) that were fixed with your patch?
>
> Ronald
>
> https://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/

With the new relaxed and acquire/release atomic int get and set
functions I proposed in
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190516.html, we
have the means to make the current code portable while preserving the
exact performance for x86/x86_64. But unlike the progress[field]
values, I am strongly against using this approach for |state| for two
reasons.

1) |state| is guarded by one of two mutexes: |mutex| and
|progress_mutex|. Which mutex should guard |state| when is not
documented, and I haven't reverse-engineered that policy.

2) progress[field] is only accessed in a pair of short functions
(ff_thread_report_progress and ff_thread_await_progress). For such a
simple problem, my first attempt at using atomics still needed to be
corrected by an expert (Dmitry Vyukov, who works on ThreadSanitizer).
In contrast, |state| is accessed in many places in
libavcodec/pthread_frame.c. Using atomics on |state| will be more
difficult, and the resulting code will be difficult to maintain.

So, to fix the |state| data races I propose using the approach of this patch.

Note: this proposal is my personal judgement and may not reflect
Dmitry's opinion. Dmitry and I seem to disagree on how to best fix the
|state| data races. To my surprise, he is fine with using atomics to
make the double-checked locking style access to |state| correct and
portable.

Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

---
 libavutil/Makefile  |  1 +
 libavutil/color_utils.c | 52 +
 2 files changed, 53 insertions(+)

diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32 
\
 bprint  \
 cast5   \
 camellia\
+color_utils \
 cpu \
 crc \
 des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..419de31 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "common.h"
 #include "libavutil/color_utils.h"
 #include "libavutil/pixfmt.h"
 
@@ -216,3 +217,54 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharact
 }
 return func;
 }
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+static int test_avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharacteristic trc, avpriv_trc_function func) {
+
+if(avpriv_get_trc_function_from_trc(trc) != func) {
+printf("Failed: invalid function returned for %d\n", trc);
+return 1;
+}
+
+printf("Passed!\n");
+return 0;
+}
+
+int main(int argc, char ** argv)
+{
+int i, error_count = 0;
+struct test {
+enum AVColorTransferCharacteristic trc;
+avpriv_trc_function func;
+} tests[] = {
+{ AVCOL_TRC_BT709, avpriv_trc_bt709 },
+{ AVCOL_TRC_SMPTE170M, avpriv_trc_bt709 },
+{ AVCOL_TRC_BT2020_10, avpriv_trc_bt709 },
+{ AVCOL_TRC_BT2020_12, avpriv_trc_bt709 },
+{ AVCOL_TRC_GAMMA22, avpriv_trc_gamma22 },
+{ AVCOL_TRC_GAMMA28, avpriv_trc_gamma28 },
+{ AVCOL_TRC_SMPTE240M, avpriv_trc_smpte240M },
+{ AVCOL_TRC_LINEAR, avpriv_trc_linear },
+{ AVCOL_TRC_LOG, avpriv_trc_log },
+{ AVCOL_TRC_LOG_SQRT, avpriv_trc_log_sqrt },
+{ AVCOL_TRC_IEC61966_2_4, avpriv_trc_iec61966_2_4 },
+{ AVCOL_TRC_BT1361_ECG, avpriv_trc_bt1361 },
+{ AVCOL_TRC_IEC61966_2_1, avpriv_trc_iec61966_2_1 },
+{ AVCOL_TRC_SMPTEST2084, avpriv_trc_smpte_st2084 },
+{ AVCOL_TRC_SMPTEST428_1, avpriv_trc_smpte_st428_1 },
+{ AVCOL_TRC_RESERVED0, NULL },
+{ AVCOL_TRC_UNSPECIFIED, NULL },
+{ AVCOL_TRC_RESERVED, NULL }
+};
+
+for(i = 0; i < FF_ARRAY_ELEMS(tests); i++) {
+if(test_avpriv_get_trc_function_from_trc(tests[i].trc, tests[i].func)) 
{
+error_count++;
+}
+}
+return !!error_count;
+}
+// LCOV_EXCL_STOP
+#endif
-- 
2.7.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

Improve coverage by adding test.

NagaChaitanya Vellanki (1):
  Add test for avpriv_get_trc_function_from_trc function

 libavutil/Makefile  |  1 +
 libavutil/color_utils.c | 52 +
 2 files changed, 53 insertions(+)

-- 
2.7.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 6/6] ffmpeg: use new encode API

[wm4]

---
I'm wondering if the ost->sync_opts++; and ost->frame_number++; lines
in do_video_out() should be moved into the loop.
---
 ffmpeg.c | 71 +---
 1 file changed, 46 insertions(+), 25 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index 54eb14e..66847fd 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -785,7 +785,7 @@ static void do_audio_out(AVFormatContext *s, OutputStream 
*ost,
 {
 AVCodecContext *enc = ost->enc_ctx;
 AVPacket pkt;
-int got_packet = 0;
+int ret;
 
 av_init_packet();
 pkt.data = NULL;
@@ -809,13 +809,19 @@ static void do_audio_out(AVFormatContext *s, OutputStream 
*ost,
enc->time_base.num, enc->time_base.den);
 }
 
-if (avcodec_encode_audio2(enc, , frame, _packet) < 0) {
-av_log(NULL, AV_LOG_FATAL, "Audio encoding failed 
(avcodec_encode_audio2)\n");
-exit_program(1);
-}
-update_benchmark("encode_audio %d.%d", ost->file_index, ost->index);
+ret = avcodec_send_frame(enc, frame);
+if (ret < 0)
+goto error;
+
+while (1) {
+ret = avcodec_receive_packet(enc, );
+if (ret == AVERROR(EAGAIN))
+break;
+if (ret < 0)
+goto error;
+
+update_benchmark("encode_audio %d.%d", ost->file_index, ost->index);
 
-if (got_packet) {
 av_packet_rescale_ts(, enc->time_base, ost->st->time_base);
 
 if (debug_ts) {
@@ -827,6 +833,11 @@ static void do_audio_out(AVFormatContext *s, OutputStream 
*ost,
 
 write_frame(s, , ost);
 }
+
+return;
+error:
+av_log(NULL, AV_LOG_FATAL, "Audio encoding failed\n");
+exit_program(1);
 }
 
 static void do_subtitle_out(AVFormatContext *s,
@@ -1094,7 +1105,7 @@ static void do_video_out(AVFormatContext *s,
 } else
 #endif
 {
-int got_packet, forced_keyframe = 0;
+int forced_keyframe = 0;
 double pts_time;
 
 if (enc->flags & (AV_CODEC_FLAG_INTERLACED_DCT | 
AV_CODEC_FLAG_INTERLACED_ME) &&
@@ -1161,14 +1172,18 @@ static void do_video_out(AVFormatContext *s,
 
 ost->frames_encoded++;
 
-ret = avcodec_encode_video2(enc, , in_picture, _packet);
-update_benchmark("encode_video %d.%d", ost->file_index, ost->index);
-if (ret < 0) {
-av_log(NULL, AV_LOG_FATAL, "Video encoding failed\n");
-exit_program(1);
-}
+ret = avcodec_send_frame(enc, in_picture);
+if (ret < 0)
+goto error;
+
+while (1) {
+ret = avcodec_receive_packet(enc, );
+update_benchmark("encode_video %d.%d", ost->file_index, 
ost->index);
+if (ret == AVERROR(EAGAIN))
+break;
+if (ret < 0)
+goto error;
 
-if (got_packet) {
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "encoder -> type:video "
"pkt_pts:%s pkt_pts_time:%s pkt_dts:%s 
pkt_dts_time:%s\n",
@@ -1216,6 +1231,11 @@ static void do_video_out(AVFormatContext *s,
 av_frame_ref(ost->last_frame, next_picture);
 else
 av_frame_free(>last_frame);
+
+return;
+error:
+av_log(NULL, AV_LOG_FATAL, "Video encoding failed\n");
+exit_program(1);
 }
 
 static double psnr(double d)
@@ -1704,35 +1724,36 @@ static void flush_encoders(void)
 continue;
 #endif
 
+if (enc->codec_type != AVMEDIA_TYPE_VIDEO && enc->codec_type != 
AVMEDIA_TYPE_AUDIO)
+continue;
+
+avcodec_send_frame(enc, NULL);
+
 for (;;) {
-int (*encode)(AVCodecContext*, AVPacket*, const AVFrame*, int*) = 
NULL;
-const char *desc;
+const char *desc = NULL;
 
 switch (enc->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
-encode = avcodec_encode_audio2;
 desc   = "audio";
 break;
 case AVMEDIA_TYPE_VIDEO:
-encode = avcodec_encode_video2;
 desc   = "video";
 break;
 default:
-stop_encoding = 1;
+av_assert0(0);
 }
 
-if (encode) {
+if (1) {
 AVPacket pkt;
 int pkt_size;
-int got_packet;
 av_init_packet();
 pkt.data = NULL;
 pkt.size = 0;
 
 update_benchmark(NULL);
-ret = encode(enc, , NULL, _packet);
+ret = avcodec_receive_packet(enc, );
 update_benchmark("flush_%s %d.%d", desc, ost->file_index, 
ost->index);
-if (ret < 0) {
+if (ret < 0 && ret != AVERROR_EOF) {
 av_log(NULL, AV_LOG_FATAL, "%s encoding failed: %s\n",
desc,
av_err2str(ret));
@@ -1741,7 +1762,7 @@ static void flush_encoders(void)
 if (ost->logfile && 

[FFmpeg-devel] [PATCH 5/6] ffmpeg: use new decode API

[wm4]

---
Unfortunately requires a hack to make FATE pass: ffmpeg.c will pass
a flush AVPacket (data/size are null) with the dts field set, and will
expect to get the dts back with the flushed frame. Should probably be
fixed somehow. I'm not even sure if this is valid API usage (with the
old API).
---
 ffmpeg.c   | 44 +---
 libavcodec/utils.c |  4 +++-
 2 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index f24ee41..54eb14e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1916,6 +1916,31 @@ int guess_input_channel_layout(InputStream *ist)
 return 1;
 }
 
+static int decode(AVCodecContext *avctx, AVFrame *frame, int *got_frame, 
AVPacket *pkt)
+{
+int ret;
+int consumed = 0;
+
+*got_frame = 0;
+
+// This relies on the fact that the decoder will not buffer additional
+// packets internally, but returns AVERROR(EAGAIN) if there are still
+// decoded frames to be returned.
+ret = avcodec_send_packet(avctx, pkt);
+if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
+return ret;
+if (ret >= 0)
+consumed = pkt->size;
+
+ret = avcodec_receive_frame(avctx, frame);
+if (ret < 0 && ret != AVERROR(EAGAIN) && ret != AVERROR_EOF)
+return ret;
+if (ret >= 0)
+*got_frame = 1;
+
+return consumed;
+}
+
 static void check_decode_result(InputStream *ist, int *got_output, int ret)
 {
 if (*got_output || ret<0)
@@ -1946,7 +1971,7 @@ static int decode_audio(InputStream *ist, AVPacket *pkt, 
int *got_output)
 decoded_frame = ist->decoded_frame;
 
 update_benchmark(NULL);
-ret = avcodec_decode_audio4(avctx, decoded_frame, got_output, pkt);
+ret = decode(avctx, decoded_frame, got_output, pkt);
 update_benchmark("decode_audio %d.%d", ist->file_index, ist->st->index);
 
 if (ret >= 0 && avctx->sample_rate <= 0) {
@@ -2072,8 +2097,7 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output)
 pkt->dts  = av_rescale_q(ist->dts, AV_TIME_BASE_Q, ist->st->time_base);
 
 update_benchmark(NULL);
-ret = avcodec_decode_video2(ist->dec_ctx,
-decoded_frame, got_output, pkt);
+ret = decode(ist->dec_ctx, decoded_frame, got_output, pkt);
 update_benchmark("decode_video %d.%d", ist->file_index, ist->st->index);
 
 // The following line may be required in some cases where there is no 
parser
@@ -2141,8 +2165,6 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output)
ist->st->time_base.num, ist->st->time_base.den);
 }
 
-pkt->size = 0;
-
 if (ist->st->sample_aspect_ratio.num)
 decoded_frame->sample_aspect_ratio = ist->st->sample_aspect_ratio;
 
@@ -2181,12 +2203,12 @@ static int decode_video(InputStream *ist, AVPacket 
*pkt, int *got_output)
 break;
 } else
 f = decoded_frame;
-ret = av_buffersrc_add_frame_flags(ist->filters[i]->filter, f, 
AV_BUFFERSRC_FLAG_PUSH);
-if (ret == AVERROR_EOF) {
-ret = 0; /* ignore */
-} else if (ret < 0) {
+err = av_buffersrc_add_frame_flags(ist->filters[i]->filter, f, 
AV_BUFFERSRC_FLAG_PUSH);
+if (err == AVERROR_EOF) {
+err = 0; /* ignore */
+} else if (err < 0) {
 av_log(NULL, AV_LOG_FATAL,
-   "Failed to inject frame into filter network: %s\n", 
av_err2str(ret));
+   "Failed to inject frame into filter network: %s\n", 
av_err2str(err));
 exit_program(1);
 }
 }
@@ -2357,7 +2379,7 @@ static int process_input_packet(InputStream *ist, const 
AVPacket *pkt, int no_eo
 
 // touch data and size only if not EOF
 if (pkt) {
-if(ist->dec_ctx->codec_type != AVMEDIA_TYPE_AUDIO)
+if(ist->dec_ctx->codec_type == AVMEDIA_TYPE_SUBTITLE)
 ret = avpkt.size;
 avpkt.data += ret;
 avpkt.size -= ret;
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index a0ec269..0667754 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2747,7 +2747,9 @@ int attribute_align_arg 
avcodec_send_packet(AVCodecContext *avctx, const AVPacke
 
 if (!avpkt || !avpkt->size) {
 avctx->internal->draining = 1;
-avpkt = NULL;
+// Crazy things ffmpeg.c requires: it sets a dts on a flush packet, and
+// wants this dts back in the flushed AVFrame.
+//avpkt = NULL;
 
 if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
 return 0;
-- 
2.7.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/6] ffmpeg: remove sub-frame warning

[wm4]

It's not practical to keep this with the new decode API.
---
 ffmpeg.c | 7 ---
 ffmpeg.h | 1 -
 2 files changed, 8 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index d148588..f24ee41 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2313,13 +2313,6 @@ static int process_input_packet(InputStream *ist, const 
AVPacket *pkt, int no_eo
 ist->pts = ist->next_pts;
 ist->dts = ist->next_dts;
 
-if (avpkt.size && avpkt.size != pkt->size &&
-!(ist->dec->capabilities & AV_CODEC_CAP_SUBFRAMES)) {
-av_log(NULL, ist->showed_multi_packet_warning ? AV_LOG_VERBOSE : 
AV_LOG_WARNING,
-   "Multiple frames in a packet from stream %d\n", 
pkt->stream_index);
-ist->showed_multi_packet_warning = 1;
-}
-
 switch (ist->dec_ctx->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
 ret = decode_audio(ist, , _output);
diff --git a/ffmpeg.h b/ffmpeg.h
index 403b098..377822c 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -283,7 +283,6 @@ typedef struct InputStream {
 
 double ts_scale;
 int saw_first_ts;
-int showed_multi_packet_warning;
 AVDictionary *decoder_opts;
 AVRational framerate;   /* framerate forced with -r */
 int top_field_first;
-- 
2.7.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/6] lavc: introduce a new decoding/encoding API with decoupled input/output

[wm4]

Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.

This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.

For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here it to make them
interopate. The reverse is not possible, although for audio it might.
---
The ff_alloc_packet2() cleverness actually forces the new encode API
to always copy the packet in order to return something refcounted.
This should probably be improved. Doesn't seem to have an effect on
FATE speed (with the later ffmpeg.c patch applied to use the new API).
---
 libavcodec/avcodec.h  | 223 ++
 libavcodec/internal.h |  12 +++
 libavcodec/utils.c| 261 +-
 3 files changed, 494 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5dc4b73..c3bfeb9 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2463,6 +2463,8 @@ typedef struct AVCodecContext {
  * Otherwise, the decoded frames must not be freed by the caller and are
  * only valid until the next decode call.
  *
+ * This is always automatically enabled if avcodec_receive_frame() is used.
+ *
  * - encoding: unused
  * - decoding: set by the caller before avcodec_open2().
  */
@@ -3507,6 +3509,21 @@ typedef struct AVCodec {
 int (*decode)(AVCodecContext *, void *outdata, int *outdata_size, AVPacket 
*avpkt);
 int (*close)(AVCodecContext *);
 /**
+ * Decode/encode API with decoupled packet/frame dataflow. The API is the
+ * same as the avcodec_ prefixed APIs (avcodec_send_frame() etc.), except
+ * that:
+ * - never called if the codec is closed or the wrong type
+ * - AVPacket parameter change side data is applied right before calling
+ *   AVCodec->send_packet
+ * - if AV_CODEC_CAP_DELAY is not set, drain packets or frames are never 
sent
+ * - only one drain packet is ever passed down (until the next flush())
+ * [- a drain AVPacket is always NULL (no need to check for avpkt->size).]
+ */
+int (*send_frame)(AVCodecContext *avctx, const AVFrame *frame);
+int (*send_packet)(AVCodecContext *avctx, const AVPacket *avpkt);
+int (*receive_frame)(AVCodecContext *avctx, AVFrame *frame);
+int (*receive_packet)(AVCodecContext *avctx, AVPacket *avpkt);
+/**
  * Flush buffers.
  * Will be called when seeking
  */
@@ -4438,6 +4455,212 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, 
AVSubtitle *sub,
 AVPacket *avpkt);
 
 /**
+ * send/receive API overview (xxx: where does this go?)
+ *
+ * The avcodec_send_packet()/avcodec_receive_frame()/avcodec_send_frame()/
+ * avcodec_receive_packet() provide a encode/decode API, which decouples input
+ * and output.
+ *
+ * The API is very similar for encoding/decoding and audio/video, and works as
+ * follows:
+ * - Setup and open the AVCodecContext as usual.
+ * - Send valid input:
+ *   - For decoding, call avcodec_send_packet() to give the decoder raw
+ * compressed data in an AVPacket.
+ *   - For encoding, call avcodec_send_frame() to give the decoder an AVFrame
+ * containing uncompressed audio or video.
+ *   In both cases, it's recommended that AVPackets and AVFrames are 
refcounted,
+ *   or libavcodec might have to copy the input data. (libavformat always
+ *   returns refcounted AVPackets, and av_frame_get_buffer() allocates
+ *   refcounted AVFrames.)
+ * - Receive output in a loop. Periodically call one of the avcodec_receive_*()
+ *   functions and process their output:
+ *   - For decoding, call avcodec_receive_frame(). On success, it will return
+ * a AVFrame containing uncompressed audio or video data.
+ *   - For encoding, call avcodec_receive_packet(). On success, it will return
+ * an AVPacket with a compressed frame.
+ *   Repeat this call until it returns AVERROR(EAGAIN) or an error. The
+ *   AVERROR(EAGAIN) return value means that new input data is required to
+ *   return new output. In this case, continue with sending input. For each
+ *   input frame/packet, the codec will typically return 1 output frame/packet,
+ *   but it can also be 0 or more than 1.
+ *
+ * At the beginning of decoding or encoding, the codec might accept multiple
+ * input frames/packets without returning a frame, until its internal buffers
+ * are filled. This situation is handled transparently if you follow the steps
+ * outlined above.
+ *
+ * End of stream situations. These require "flushing" (aka draining) the codec,
+ * as the codec might buffer multiple frames or packets internally for
+ * 

[FFmpeg-devel] [PATCH 1/6] lavu: improve documentation of some AVFrame functions

[wm4]

---
 libavutil/frame.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 76a8123..2d6299b 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -591,6 +591,10 @@ void av_frame_free(AVFrame **frame);
  * If src is not reference counted, new buffers are allocated and the data is
  * copied.
  *
+ * @warning: dst MUST have been either unreferenced with av_frame_unref(dst),
+ *   or newly allocated with av_frame_alloc() before calling this
+ *   function, or undefined behavior will occur.
+ *
  * @return 0 on success, a negative AVERROR on error
  */
 int av_frame_ref(AVFrame *dst, const AVFrame *src);
@@ -611,6 +615,10 @@ void av_frame_unref(AVFrame *frame);
 
 /**
  * Move everything contained in src to dst and reset src.
+ *
+ * @warning: dst is not unreferenced, but directly overwritten without reading
+ *   or deallocating its contents. Call av_frame_unref(dst) manually
+ *   before calling this function to ensure that no memory is leaked.
  */
 void av_frame_move_ref(AVFrame *dst, AVFrame *src);
 
@@ -626,6 +634,10 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
  * necessary, allocate and fill AVFrame.extended_data and AVFrame.extended_buf.
  * For planar formats, one buffer will be allocated for each plane.
  *
+ * @warning: if frame already has been allocated, calling this function will
+ *   leak memory. In addition, undefined behavior can occur in certain
+ *   cases.
+ *
  * @param frame frame in which to store the new buffers.
  * @param align required buffer size alignment
  *
-- 
2.7.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/6] lavc: factor apply_param_change() AV_EF_EXPLODE handling

[wm4]

Remove the duplicated code for handling failure of apply_param_change().
---
 libavcodec/utils.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f435588..86236f8 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2032,7 +2032,8 @@ static int apply_param_change(AVCodecContext *avctx, 
AVPacket *avpkt)
 if (!(avctx->codec->capabilities & AV_CODEC_CAP_PARAM_CHANGE)) {
 av_log(avctx, AV_LOG_ERROR, "This decoder does not support parameter "
"changes, but PARAM_CHANGE side data was sent to it.\n");
-return AVERROR(EINVAL);
+ret = AVERROR(EINVAL);
+goto fail2;
 }
 
 if (size < 4)
@@ -2047,7 +2048,8 @@ static int apply_param_change(AVCodecContext *avctx, 
AVPacket *avpkt)
 val = bytestream_get_le32();
 if (val <= 0 || val > INT_MAX) {
 av_log(avctx, AV_LOG_ERROR, "Invalid channel count");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto fail2;
 }
 avctx->channels = val;
 size -= 4;
@@ -2064,7 +2066,8 @@ static int apply_param_change(AVCodecContext *avctx, 
AVPacket *avpkt)
 val = bytestream_get_le32();
 if (val <= 0 || val > INT_MAX) {
 av_log(avctx, AV_LOG_ERROR, "Invalid sample rate");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto fail2;
 }
 avctx->sample_rate = val;
 size -= 4;
@@ -2077,13 +2080,20 @@ static int apply_param_change(AVCodecContext *avctx, 
AVPacket *avpkt)
 size -= 8;
 ret = ff_set_dimensions(avctx, avctx->width, avctx->height);
 if (ret < 0)
-return ret;
+goto fail2;
 }
 
 return 0;
 fail:
 av_log(avctx, AV_LOG_ERROR, "PARAM_CHANGE side data too small.\n");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+fail2:
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Error applying parameter changes.\n");
+if (avctx->err_recognition & AV_EF_EXPLODE)
+return ret;
+}
+return 0;
 }
 
 static int unrefcount_frame(AVCodecInternal *avci, AVFrame *frame)
@@ -2158,11 +2168,8 @@ int attribute_align_arg 
avcodec_decode_video2(AVCodecContext *avctx, AVFrame *pi
 (avctx->active_thread_type & FF_THREAD_FRAME)) {
 int did_split = av_packet_split_side_data();
 ret = apply_param_change(avctx, );
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error applying parameter changes.\n");
-if (avctx->err_recognition & AV_EF_EXPLODE)
-goto fail;
-}
+if (ret < 0)
+goto fail;
 
 avctx->internal->pkt = 
 if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
@@ -2259,11 +2266,8 @@ int attribute_align_arg 
avcodec_decode_audio4(AVCodecContext *avctx,
 AVPacket tmp = *avpkt;
 int did_split = av_packet_split_side_data();
 ret = apply_param_change(avctx, );
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR, "Error applying parameter changes.\n");
-if (avctx->err_recognition & AV_EF_EXPLODE)
-goto fail;
-}
+if (ret < 0)
+goto fail;
 
 avctx->internal->pkt = 
 if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME)
-- 
2.7.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/6] Add decoding/encoding API with decoupled input/output

[wm4]

This has been often discussed, and everyone agreed it was a good idea.
Here are patches which add such an API, but without making proper use
of it yet.

wm4 (6):
  lavu: improve documentation of some AVFrame functions
  lavc: factor apply_param_change() AV_EF_EXPLODE handling
  lavc: introduce a new decoding/encoding API with decoupled
input/output
  ffmpeg: remove sub-frame warning
  ffmpeg: use new decode API
  ffmpeg: use new encode API

 ffmpeg.c  | 122 +
 ffmpeg.h  |   1 -
 libavcodec/avcodec.h  | 223 +
 libavcodec/internal.h |  12 ++
 libavcodec/utils.c| 297 +++---
 libavutil/frame.h |  12 ++
 6 files changed, 606 insertions(+), 61 deletions(-)

-- 
2.7.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Move the |die| member of FrameThreadContext to PerThreadContext.

[Wan-Teh Chang]

On Fri, Feb 26, 2016 at 12:14 PM, Ronald S. Bultje  wrote:
>
> Is probably OK since it doesn't introduce new lock/unlock pairs, yes. We
> typically don't care about a few bytes of memory.

Hi Ronald,

I just signed off this patch and submitted it in
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190520.html.

Does the patch need additional review? Could you approve and commit
the patch for me?

Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Move the |die| member of FrameThreadContext to PerThreadContext.

[Wan-Teh Chang]

This fixes a data race warning by ThreadSanitizer.
FrameThreadContext.die is read by all the worker threads but is not
protected by any mutex. Move it to PerThreadContext so that each worker
thread reads its own copy of |die|, which can then be protected with
PerThreadContext.mutex.

Signed-off-by: Wan-Teh Chang 
---
 libavcodec/pthread_frame.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index b77dd1e..c5ac44f 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -93,6 +93,8 @@ typedef struct PerThreadContext {
 
 const enum AVPixelFormat *available_formats; ///< Format array for 
get_format()
 enum AVPixelFormat result_format;///< get_format() result
+
+int die;///< Set when the thread should exit.
 } PerThreadContext;
 
 /**
@@ -111,8 +113,6 @@ typedef struct FrameThreadContext {
 * Set for the first N packets, where N is 
the number of threads.
 * While it is set, 
ff_thread_en/decode_frame won't return any results.
 */
-
-int die;   ///< Set when threads should exit.
 } FrameThreadContext;
 
 #define THREAD_SAFE_CALLBACKS(avctx) \
@@ -134,10 +134,10 @@ static attribute_align_arg void *frame_worker_thread(void 
*arg)
 
 pthread_mutex_lock(>mutex);
 while (1) {
-while (p->state == STATE_INPUT_READY && !fctx->die)
+while (p->state == STATE_INPUT_READY && !p->die)
 pthread_cond_wait(>input_cond, >mutex);
 
-if (fctx->die) break;
+if (p->die) break;
 
 if (!codec->update_thread_context && THREAD_SAFE_CALLBACKS(avctx))
 ff_thread_finish_setup(avctx);
@@ -553,12 +553,11 @@ void ff_frame_thread_free(AVCodecContext *avctx, int 
thread_count)
 fctx->threads->avctx->internal->is_copy = 1;
 }
 
-fctx->die = 1;
-
 for (i = 0; i < thread_count; i++) {
 PerThreadContext *p = >threads[i];
 
 pthread_mutex_lock(>mutex);
+p->die = 1;
 pthread_cond_signal(>input_cond);
 pthread_mutex_unlock(>mutex);
 
-- 
2.7.0.rc3.207.g0ac5344

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add the relaxed and acquire/releae flavors of avpriv_atomic_int_get and avpriv_atomic_int_set.

[Wan-Teh Chang]

Hi,

I removed the ff_thread_report_progress and ff_thread_await_progress
changes from this patch. This patch now only changes
libavutil/atomic*. I also added some comments to libavutil/atomic.h to
describe how the acquire and release operations are intended to be
used.

While working on the comments in libavutil/atomic.h, I noticed that
the comment for avpriv_atomic_int_add_and_fetch contradicts the code.
The comment says:

 * @note This does NOT act as a memory barrier. This is primarily
 *   intended for reference counting.

But the primary implementation in libavutil/atomic_gcc.h uses the
sequentially consistent ordering rather than the relaxed ordering:

#define avpriv_atomic_int_add_and_fetch atomic_int_add_and_fetch_gcc
static inline int atomic_int_add_and_fetch_gcc(volatile int *ptr, int inc)
{
#if HAVE_ATOMIC_COMPARE_EXCHANGE
return __atomic_add_fetch(ptr, inc, __ATOMIC_SEQ_CST);
#else
return __sync_add_and_fetch(ptr, inc);
#endif
}

How should we make the comment match the code? I suggest that the
default memory order of avpriv_atomic_int_add_and_fetch be the
sequentially consistent ordering, and add a
avpriv_atomic_int_add_and_fetch_relaxed function that does not issue a
memory barrier.

If you agree with my proposal, I can write a separate patch to do that.

Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Patch: Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

Hi all,
This is my first patch. git send-mail did not work for me. Sending the
patch via gmail gui. Please review my patch.

Thank you,
NagaChaitanya Vellanki


0001-Add-test-for-avpriv_get_trc_function_from_trc-functi.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/udp: Add a delay between packets for streaming to clients with short buffer

[Michael Niedermayer]

On Mon, Feb 29, 2016 at 10:40:02PM +0300, Pavel Nikiforov wrote:
> Hello !
> 
> This patch enables background sending of UDP packets with specified delay.
> When sending packets without a delay some devices with small RX buffer
> ( MAG200 STB, for example) will drop tail packets in burst causing
> decoding errors.
> 
> It needs to specify "fifo_size" with "packet_gap" .
> 
> The output url will looks like udp://xxx:yyy?fifo_size= size>_gap=
> 
> Patch attached.

>  udp.c |  133 
> --
>  1 file changed, 129 insertions(+), 4 deletions(-)
> 80b57f176b5492070b2ed4853472de61b7d9ab7f  udp.patch
>  libavformat/udp.c | 133 
> --
>  1 file changed, 129 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index ea80e52..ff676f4 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -92,6 +92,7 @@ typedef struct UDPContext {
>  int circular_buffer_size;
>  AVFifoBuffer *fifo;
>  int circular_buffer_error;
> +int packet_gap; /* delay between transmitted packets */
>  #if HAVE_PTHREAD_CANCEL
>  pthread_t circular_buffer_thread;
>  pthread_mutex_t mutex;
> @@ -112,6 +113,7 @@ typedef struct UDPContext {
>  #define E AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
>  { "buffer_size","System data size (in bytes)", 
> OFFSET(buffer_size),AV_OPT_TYPE_INT,{ .i64 = -1 },-1, INT_MAX, 
> .flags = D|E },
> +{ "packet_gap", "Delay between packets, in usec",  
> OFFSET(packet_gap), AV_OPT_TYPE_INT,{ .i64 = 0  }, 0, INT_MAX, 
> .flags = E },

units should be seconds so that SI suffixes like for usecs work

also independant of this patch but supporting to transmit packets
at at their PCR/SCR/transmit time should be interresting


>  { "localport",  "Local port",  
> OFFSET(local_port), AV_OPT_TYPE_INT,{ .i64 = -1 },-1, INT_MAX, 
> D|E },
>  { "local_port", "Local port",  
> OFFSET(local_port), AV_OPT_TYPE_INT,{ .i64 = -1 },-1, INT_MAX, 
> .flags = D|E },
>  { "localaddr",  "Local address",   
> OFFSET(localaddr),  AV_OPT_TYPE_STRING, { .str = NULL },   
> .flags = D|E },
> @@ -486,7 +488,7 @@ static int udp_get_file_handle(URLContext *h)
>  }
>  
>  #if HAVE_PTHREAD_CANCEL
> -static void *circular_buffer_task( void *_URLContext)
> +static void *circular_buffer_task_rx( void *_URLContext)
>  {
>  URLContext *h = _URLContext;
>  UDPContext *s = h->priv_data;

renaming things should be in a seperate patch

anyway, real review left to someone who knows th network stuff better
like nicolas

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add the relaxed and acquire/releae flavors of avpriv_atomic_int_get and avpriv_atomic_int_set.

[Wan-Teh Chang]

Correct the order of the load/store operation and the memory barrier in
avpriv_atomic_int_get and avpriv_atomic_int_set.

Signed-off-by: Wan-Teh Chang 
---
 libavutil/atomic.c   | 48 
 libavutil/atomic.h   | 45 +++--
 libavutil/atomic_gcc.h   | 44 
 libavutil/atomic_suncc.h | 30 +-
 libavutil/atomic_win32.h | 28 
 5 files changed, 192 insertions(+), 3 deletions(-)

diff --git a/libavutil/atomic.c b/libavutil/atomic.c
index b13725d..3dc9062 100644
--- a/libavutil/atomic.c
+++ b/libavutil/atomic.c
@@ -40,6 +40,16 @@ int avpriv_atomic_int_get(volatile int *ptr)
 return res;
 }
 
+int avpriv_atomic_int_get_relaxed(volatile int *ptr)
+{
+return avpriv_atomic_int_get(ptr);
+}
+
+int avpriv_atomic_int_get_acquire(volatile int *ptr)
+{
+return avpriv_atomic_int_get(ptr);
+}
+
 void avpriv_atomic_int_set(volatile int *ptr, int val)
 {
 pthread_mutex_lock(_lock);
@@ -47,6 +57,16 @@ void avpriv_atomic_int_set(volatile int *ptr, int val)
 pthread_mutex_unlock(_lock);
 }
 
+void avpriv_atomic_int_set_relaxed(volatile int *ptr, int val)
+{
+avpriv_atomic_int_set(ptr, val);
+}
+
+void avpriv_atomic_int_set_release(volatile int *ptr, int val)
+{
+avpriv_atomic_int_set(ptr, val);
+}
+
 int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int inc)
 {
 int res;
@@ -77,11 +97,31 @@ int avpriv_atomic_int_get(volatile int *ptr)
 return *ptr;
 }
 
+int avpriv_atomic_int_get_relaxed(volatile int *ptr)
+{
+return avpriv_atomic_int_get(ptr);
+}
+
+int avpriv_atomic_int_get_acquire(volatile int *ptr)
+{
+return avpriv_atomic_int_get(ptr);
+}
+
 void avpriv_atomic_int_set(volatile int *ptr, int val)
 {
 *ptr = val;
 }
 
+void avpriv_atomic_int_set_relaxed(volatile int *ptr, int val)
+{
+avpriv_atomic_int_set(ptr, val);
+}
+
+void avpriv_atomic_int_set_release(volatile int *ptr, int val)
+{
+avpriv_atomic_int_set(ptr, val);
+}
+
 int avpriv_atomic_int_add_and_fetch(volatile int *ptr, int inc)
 {
 *ptr += inc;
@@ -121,6 +161,14 @@ int main(void)
 avpriv_atomic_int_set(, 3);
 res = avpriv_atomic_int_get();
 av_assert0(res == 3);
+avpriv_atomic_int_set_relaxed(, 5);
+res = avpriv_atomic_int_get_relaxed();
+av_assert0(res == 5);
+res = avpriv_atomic_int_add_and_fetch(, -1);
+av_assert0(res == 4);
+avpriv_atomic_int_set_release(, 3);
+res = avpriv_atomic_int_get_acquire();
+av_assert0(res == 3);
 
 return 0;
 }
diff --git a/libavutil/atomic.h b/libavutil/atomic.h
index 15906d2..e0e67d2 100644
--- a/libavutil/atomic.h
+++ b/libavutil/atomic.h
@@ -40,20 +40,61 @@
  *
  * @param ptr atomic integer
  * @return the current value of the atomic integer
- * @note This acts as a memory barrier.
+ * @note This acts as a full memory barrier.
  */
 int avpriv_atomic_int_get(volatile int *ptr);
 
 /**
+ * Load the current value stored in an atomic integer, with no memory barrier.
+ *
+ * @param ptr atomic integer
+ * @return the current value of the atomic integer
+ * @note This does NOT act as a memory barrier.
+ */
+int avpriv_atomic_int_get_relaxed(volatile int *ptr);
+
+/**
+ * Load the current value stored in an atomic integer, with an acquire memory
+ * barrier.
+ *
+ * @param ptr atomic integer
+ * @return the current value of the atomic integer
+ * @note This acts as an acquire memory barrier. When used with a release
+ *   operation on the same value, this establishes a happens-before
+ *   relationship between threads.
+ */
+int avpriv_atomic_int_get_acquire(volatile int *ptr);
+
+/**
  * Store a new value in an atomic integer.
  *
  * @param ptr atomic integer
  * @param val the value to store in the atomic integer
- * @note This acts as a memory barrier.
+ * @note This acts as a full memory barrier.
  */
 void avpriv_atomic_int_set(volatile int *ptr, int val);
 
 /**
+ * Store a new value in an atomic integer, with no memory barrier.
+ *
+ * @param ptr atomic integer
+ * @param val the value to store in the atomic integer
+ * @note This does NOT act as a memory barrier.
+ */
+void avpriv_atomic_int_set_relaxed(volatile int *ptr, int val);
+
+/**
+ * Store a new value in an atomic integer, with a release memory barrier.
+ *
+ * @param ptr atomic integer
+ * @param val the value to store in the atomic integer
+ * @note This acts as a release memory barrier. When used with an acquire
+ *   operation on the same value, this establishes a happens-before
+ *   relationship between threads.
+ */
+void avpriv_atomic_int_set_release(volatile int *ptr, int val);
+
+/**
  * Add a value to an atomic integer.
  *
  * @param ptr atomic integer
diff --git a/libavutil/atomic_gcc.h b/libavutil/atomic_gcc.h
index 5f9fc49..34a6a8e 100644
--- a/libavutil/atomic_gcc.h
+++ b/libavutil/atomic_gcc.h
@@ -31,19 +31,63 @@ static 

[FFmpeg-devel] [PATCH] lavc/mjpegdec: avoid unneeded allocation if the frame is to be skipped

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libavcodec/mjpegdec.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index f41f3a5..1e83e88 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -614,6 +614,13 @@ unk_pixfmt:
 return AVERROR_BUG;
 }
 
+if (s->avctx->skip_frame == AVDISCARD_ALL) {
+s->picture_ptr->pict_type = AV_PICTURE_TYPE_I;
+s->picture_ptr->key_frame = 1;
+s->got_picture= 1;
+return 0;
+}
+
 av_frame_unref(s->picture_ptr);
 if (ff_get_buffer(s->avctx, s->picture_ptr, AV_GET_BUFFER_FLAG_REF) < 0)
 return -1;
-- 
2.7.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon

[Clément Bœsch]

On Tue, Mar 01, 2016 at 05:18:36PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 01, 2016 at 11:11:36AM +0100, Clément Bœsch wrote:
> > On Mon, Feb 29, 2016 at 10:55:49AM +0100, Clément Bœsch wrote:
> > > From: Clément Bœsch 
> > > 
> > > ---
> > > Changes since latest version:
> > > - remove unused 32-bit path
> > > - make 16-bit path more accurate by mirroring the MMX code (still not 
> > > bitexact)
> > > - the code as originally trying to process 2 lines at a time to save 
> > > chroma pre
> > >   mult computations and avoid re-reading the whole line; for some reason, 
> > > this
> > >   actually made the code around twice slower, for twice the complexity.
> > >   dropping that complexity was a win-win.
> > > ---
> > >  libswscale/aarch64/Makefile   |   3 +
> > >  libswscale/aarch64/swscale_unscaled.c | 132 ++
> > >  libswscale/aarch64/yuv2rgb_neon.S | 207 
> > > ++
> > >  libswscale/swscale_internal.h |   1 +
> > >  libswscale/swscale_unscaled.c |   2 +
> > >  5 files changed, 345 insertions(+)
> > >  create mode 100644 libswscale/aarch64/Makefile
> > >  create mode 100644 libswscale/aarch64/swscale_unscaled.c
> > >  create mode 100644 libswscale/aarch64/yuv2rgb_neon.S
> > > 
> > 
> > Random benchmark on Hikey (Cortex-A53):
> > 
> > ./ffmpeg -nostats -f lavfi -i testsrc2=s=uhd2160:d=1 -vf 
> > format=yuv420p,bench=start,format=rgba,bench=stop -f null -
> > 
> > (yuv420p to rgba in 3840x2160)
> > 
> > before:
> > [bench @ 0x2edfe1e0] t:0.181514 avg:0.181514 max:0.181514 min:0.181514
> > [bench @ 0x2edfe1e0] t:0.178870 avg:0.180192 max:0.181514 min:0.178870
> > [bench @ 0x2edfe1e0] t:0.164448 avg:0.174944 max:0.181514 min:0.164448
> > [bench @ 0x2edfe1e0] t:0.164801 avg:0.172408 max:0.181514 min:0.164448
> > [bench @ 0x2edfe1e0] t:0.164635 avg:0.170853 max:0.181514 min:0.164448
> > [bench @ 0x2edfe1e0] t:0.164756 avg:0.169837 max:0.181514 min:0.164448
> > [bench @ 0x2edfe1e0] t:0.164784 avg:0.169115 max:0.181514 min:0.164448
> > [bench @ 0x2edfe1e0] t:0.164413 avg:0.168527 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164760 avg:0.168109 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164647 avg:0.167762 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164698 avg:0.167484 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164600 avg:0.167243 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164498 avg:0.167032 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164765 avg:0.166870 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164613 avg:0.166720 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164781 avg:0.166598 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164489 avg:0.166474 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164432 avg:0.166361 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164540 avg:0.166265 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.164524 avg:0.166178 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.165147 avg:0.166129 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.165484 avg:0.166099 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.165703 avg:0.166082 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.165643 avg:0.166064 max:0.181514 min:0.164413
> > [bench @ 0x2edfe1e0] t:0.165294 avg:0.166033 max:0.181514 min:0.164413
> > 
> > after:
> > [bench @ 0x16d871e0] t:0.042296 avg:0.042296 max:0.042296 min:0.042296
> > [bench @ 0x16d871e0] t:0.041986 avg:0.042141 max:0.042296 min:0.041986
> > [bench @ 0x16d871e0] t:0.027298 avg:0.037193 max:0.042296 min:0.027298
> > [bench @ 0x16d871e0] t:0.027388 avg:0.034742 max:0.042296 min:0.027298
> > [bench @ 0x16d871e0] t:0.027383 avg:0.033270 max:0.042296 min:0.027298
> > [bench @ 0x16d871e0] t:0.027366 avg:0.032286 max:0.042296 min:0.027298
> > [bench @ 0x16d871e0] t:0.027225 avg:0.031563 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027685 avg:0.031078 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027246 avg:0.030652 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027363 avg:0.030323 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027449 avg:0.030062 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027582 avg:0.029855 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027374 avg:0.029664 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027429 avg:0.029505 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027275 avg:0.029356 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027573 avg:0.029244 max:0.042296 min:0.027225
> > [bench @ 0x16d871e0] t:0.027219 avg:0.029125 max:0.042296 min:0.027219
> > [bench @ 0x16d871e0] t:0.027392 avg:0.029029 max:0.042296 min:0.027219
> > [bench @ 0x16d871e0] t:0.027720 avg:0.028960 max:0.042296 min:0.027219
> > [bench @ 0x16d871e0] t:0.027449 avg:0.028884 max:0.042296 min:0.027219
> > [bench @ 0x16d871e0] t:0.027473 avg:0.028817 max:0.042296 

Re: [FFmpeg-devel] [PATCH v2] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 11:11:36AM +0100, Clément Bœsch wrote:
> On Mon, Feb 29, 2016 at 10:55:49AM +0100, Clément Bœsch wrote:
> > From: Clément Bœsch 
> > 
> > ---
> > Changes since latest version:
> > - remove unused 32-bit path
> > - make 16-bit path more accurate by mirroring the MMX code (still not 
> > bitexact)
> > - the code as originally trying to process 2 lines at a time to save chroma 
> > pre
> >   mult computations and avoid re-reading the whole line; for some reason, 
> > this
> >   actually made the code around twice slower, for twice the complexity.
> >   dropping that complexity was a win-win.
> > ---
> >  libswscale/aarch64/Makefile   |   3 +
> >  libswscale/aarch64/swscale_unscaled.c | 132 ++
> >  libswscale/aarch64/yuv2rgb_neon.S | 207 
> > ++
> >  libswscale/swscale_internal.h |   1 +
> >  libswscale/swscale_unscaled.c |   2 +
> >  5 files changed, 345 insertions(+)
> >  create mode 100644 libswscale/aarch64/Makefile
> >  create mode 100644 libswscale/aarch64/swscale_unscaled.c
> >  create mode 100644 libswscale/aarch64/yuv2rgb_neon.S
> > 
> 
> Random benchmark on Hikey (Cortex-A53):
> 
> ./ffmpeg -nostats -f lavfi -i testsrc2=s=uhd2160:d=1 -vf 
> format=yuv420p,bench=start,format=rgba,bench=stop -f null -
> 
> (yuv420p to rgba in 3840x2160)
> 
> before:
> [bench @ 0x2edfe1e0] t:0.181514 avg:0.181514 max:0.181514 min:0.181514
> [bench @ 0x2edfe1e0] t:0.178870 avg:0.180192 max:0.181514 min:0.178870
> [bench @ 0x2edfe1e0] t:0.164448 avg:0.174944 max:0.181514 min:0.164448
> [bench @ 0x2edfe1e0] t:0.164801 avg:0.172408 max:0.181514 min:0.164448
> [bench @ 0x2edfe1e0] t:0.164635 avg:0.170853 max:0.181514 min:0.164448
> [bench @ 0x2edfe1e0] t:0.164756 avg:0.169837 max:0.181514 min:0.164448
> [bench @ 0x2edfe1e0] t:0.164784 avg:0.169115 max:0.181514 min:0.164448
> [bench @ 0x2edfe1e0] t:0.164413 avg:0.168527 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164760 avg:0.168109 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164647 avg:0.167762 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164698 avg:0.167484 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164600 avg:0.167243 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164498 avg:0.167032 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164765 avg:0.166870 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164613 avg:0.166720 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164781 avg:0.166598 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164489 avg:0.166474 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164432 avg:0.166361 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164540 avg:0.166265 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.164524 avg:0.166178 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.165147 avg:0.166129 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.165484 avg:0.166099 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.165703 avg:0.166082 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.165643 avg:0.166064 max:0.181514 min:0.164413
> [bench @ 0x2edfe1e0] t:0.165294 avg:0.166033 max:0.181514 min:0.164413
> 
> after:
> [bench @ 0x16d871e0] t:0.042296 avg:0.042296 max:0.042296 min:0.042296
> [bench @ 0x16d871e0] t:0.041986 avg:0.042141 max:0.042296 min:0.041986
> [bench @ 0x16d871e0] t:0.027298 avg:0.037193 max:0.042296 min:0.027298
> [bench @ 0x16d871e0] t:0.027388 avg:0.034742 max:0.042296 min:0.027298
> [bench @ 0x16d871e0] t:0.027383 avg:0.033270 max:0.042296 min:0.027298
> [bench @ 0x16d871e0] t:0.027366 avg:0.032286 max:0.042296 min:0.027298
> [bench @ 0x16d871e0] t:0.027225 avg:0.031563 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027685 avg:0.031078 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027246 avg:0.030652 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027363 avg:0.030323 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027449 avg:0.030062 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027582 avg:0.029855 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027374 avg:0.029664 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027429 avg:0.029505 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027275 avg:0.029356 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027573 avg:0.029244 max:0.042296 min:0.027225
> [bench @ 0x16d871e0] t:0.027219 avg:0.029125 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027392 avg:0.029029 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027720 avg:0.028960 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027449 avg:0.028884 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027473 avg:0.028817 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027444 avg:0.028755 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027535 avg:0.028702 max:0.042296 min:0.027219
> [bench @ 0x16d871e0] t:0.027607 avg:0.028656 max:0.042296 min:0.027219
> [bench 

[FFmpeg-devel] [WIP] vc2 encoder simd assembly

[James Darnley]

Hello

I've been working on assembly for the vc2 encoder and have reached an
impasse.  My code results in very visible errors, very obvious vertical
streaks in the bottom-right half of the image and some low-frequency
effect (I think).

I cannot see the problem in my code so I need some fresh eyes to look at it.

You can test the code with these two commands:
> ./ffmpeg -f lavfi -i testsrc=s=1024x576,format=yuv420p -vcodec vc2 -strict -1 
> -vframes 1 -cpuflags 0 -y temp.vc2
> ./ffmpeg -f lavfi -i testsrc=s=1024x576,format=yuv420p -vcodec vc2 -strict -1 
> -vframes 1 -y temp.vc2

Decode each to a png image to see the problem.

Attached is a diff from master (my branch is a two dozen small commits).

Thanks.

diff --git a/libavcodec/vc2enc_dwt.c b/libavcodec/vc2enc_dwt.c
index c60b003..bac262d 100644
--- a/libavcodec/vc2enc_dwt.c
+++ b/libavcodec/vc2enc_dwt.c
@@ -23,6 +23,7 @@
 #include "libavutil/attributes.h"
 #include "libavutil/mem.h"
 #include "vc2enc_dwt.h"
+#include "libavcodec/x86/vc2dsp.h"
 
 /* Since the transforms spit out interleaved coefficients, this function
  * rearranges the coefficients into the more traditional subdivision,
@@ -76,16 +77,21 @@ static void vc2_subband_dwt_97(VC2TransformContext *t, 
dwtcoef *data,
 for (y = 0; y < synth_height; y++) {
 /* Lifting stage 2. */
 synthl[1] -= (8*synthl[0] + 9*synthl[2] - synthl[4] + 8) >> 4;
+
 for (x = 1; x < width - 2; x++)
-synthl[2*x + 1] -= (9*synthl[2*x] + 9*synthl[2*x + 2] - synthl[2*x 
+ 4] -
-synthl[2 * x - 2] + 8) >> 4;
+synthl[2*x + 1] -= (9*synthl[2*x] +
+9*synthl[2*x + 2] -
+  synthl[2*x + 4] -
+  synthl[2*x - 2] + 8) >> 4;
+
 synthl[synth_width - 1] -= (17*synthl[synth_width - 2] -
-synthl[synth_width - 4] + 8) >> 4;
+   synthl[synth_width - 4] + 8) >> 4;
 synthl[synth_width - 3] -= (8*synthl[synth_width - 2] +
 9*synthl[synth_width - 4] -
-synthl[synth_width - 6] + 8) >> 4;
+  synthl[synth_width - 6] + 8) >> 4;
 /* Lifting stage 1. */
 synthl[0] += (synthl[1] + synthl[1] + 2) >> 2;
+
 for (x = 1; x < width - 1; x++)
 synthl[2*x] += (synthl[2*x - 1] + synthl[2*x + 1] + 2) >> 2;
 
@@ -97,25 +103,28 @@ static void vc2_subband_dwt_97(VC2TransformContext *t, 
dwtcoef *data,
 /* Vertical synthesis: Lifting stage 2. */
 synthl = synth + synth_width;
 for (x = 0; x < synth_width; x++)
-synthl[x] -= (8*synthl[x - synth_width] + 9*synthl[x + synth_width] -
-  synthl[x + 3 * synth_width] + 8) >> 4;
+synthl[x] -= (8*synthl[x - synth_width] +
+  9*synthl[x + synth_width] -
+synthl[x + 3*synth_width] + 8) >> 4;
 
 synthl = synth + (synth_width << 1);
 for (y = 1; y < height - 2; y++) {
 for (x = 0; x < synth_width; x++)
 synthl[x + synth_width] -= (9*synthl[x] +
-9*synthl[x + 2 * synth_width] -
-synthl[x - 2 * synth_width] -
-synthl[x + 4 * synth_width] + 8) >> 4;
+9*synthl[x + 2*synth_width] -
+  synthl[x - 2*synth_width] -
+  synthl[x + 4*synth_width] + 8) >> 4;
 synthl += synth_width << 1;
 }
 
 synthl = synth + (synth_height - 1) * synth_width;
 for (x = 0; x < synth_width; x++) {
 synthl[x] -= (17*synthl[x - synth_width] -
-  synthl[x - 3*synth_width] + 8) >> 4;
-  synthl[x - 2*synth_width] -= (9*synthl[x - 
3*synth_width] +
-  8*synthl[x - 1*synth_width] - synthl[x - 5*synth_width] 
+ 8) >> 4;
+ synthl[x - 3*synth_width] + 8) >> 4;
+
+synthl[x - 2*synth_width] -= (9*synthl[x - 3*synth_width] +
+  8*synthl[x - 1*synth_width] -
+synthl[x - 5*synth_width] + 8) >> 4;
 }
 
 /* Vertical synthesis: Lifting stage 1. */
@@ -262,6 +271,10 @@ av_cold int ff_vc2enc_init_transforms(VC2TransformContext 
*s, int p_width, int p
 s->vc2_subband_dwt[VC2_TRANSFORM_HAAR]   = vc2_subband_dwt_haar;
 s->vc2_subband_dwt[VC2_TRANSFORM_HAAR_S] = vc2_subband_dwt_haar_shift;
 
+#if ARCH_X86
+ff_vc2enc_init_x86(s, p_width, p_height);
+#endif
+
 s->buffer = av_malloc(2*p_width*p_height*sizeof(dwtcoef));
 if (!s->buffer)
 return 1;
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 839b5bc..24aedda 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile

Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder

[wm4]

On Tue, 01 Mar 2016 14:57:29 +
Timothy Gu  wrote:

> Hi,
> 
> On Mon, Feb 29, 2016 at 9:42 PM Rick Kern  wrote:
> 
> > Autodetected by default. Encode using -codec:v vtenc.
> >
> > Signed-off-by: Rick Kern 
> > ---
> >  MAINTAINERS|1 +
> >  configure  |   19 +
> >  libavcodec/Makefile|1 +
> >  libavcodec/allcodecs.c |1 +
> >  libavcodec/vtenc.c | 1339
> > 
> >  5 files changed, 1361 insertions(+)
> >  create mode 100644 libavcodec/vtenc.c
> >  
> 
> We already have videotoolbox AVHWAccel. Maybe it would be better to change
> the name of the file to videotoolboxenc.c so that it's easier to associate
> these two files?

I don't mind. They're pretty different after all.

> 
> > +AVCodec ff_vtenc_encoder = {  
> 
> > +.name = "vtenc",
> > +.long_name= NULL_IF_CONFIG_SMALL("VideoToolbox H.264
> > Encoder"),
> >  
> 
> The norm seems to be using "h264_videotoolbox" (like "h264_qsv") so that
> potential future extensions to VideoToolbox can be supported without
> changing the name of the codec.
> 

Good point.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 08:01:26AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Mar 1, 2016 at 7:00 AM, Carl Eugen Hoyos  wrote:
> 
> > wm4  googlemail.com> writes:
> >
> > > Adding dozens of small very specialized features leads to
> > > unmaintainable and unusable software, even if the change
> > > itself is inoffensive.
> >
> > I don't think this is a "small" feature, I consider it a
> > very useful request.
> > I also wonder why it is "very specialized": I can see a
> > few uses for the new option.
> 
> 
> Nonetheless, it does not belong in ffmpeg or libav*.
> 
> > Powerful, orthogonal mechanisms will always be superior.
> >
> > So how does this mechanism look like for the requested
> > use case?
> 
> 
> man ln.

iam not sure this is such a great alternative

it seems rather inconvenient. why i think so ?
well if it was convenient you would likely have written the working
command and not pointed to the manual

also does this work on all platforms? (windows?)

and ffmpeg supports alot more than files, one could want to do

-reverse 1 -i http://foobar.com/image%d.jpeg

to do that with ln one either needs some remote mounting http thing
(i dont even know how to do that) or download all the images first
which may or may not be practical depending on their number and size

that said, i too prefer if there was a generic+portable+simple
solution using something that works with all comand line tools and
isnt ffmpeg specific

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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 a bug in ff_thread_report_progress in updating progress[field].

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 9:34 AM, Wan-Teh Chang 
wrote:

> By the way, I'm also wondering why ff_thread_report_progress is
> sometimes called with progress[field] >= n? I saw it happen when I ran
> make fate-h264, but did not investigate it.


I don't know, which sample (test name) specifically?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add the relaxed and acquire/releae flavors of avpriv_atomic_int_get and avpriv_atomic_int_set.

[Wan-Teh Chang]

Hi,

I have some remarks on this patch.

1. This patch is an alternative fix for the data races in the access
to frame progress values in ff_thread_report_progress and
ff_thread_await_progress. Between the two patches I submitted, I
prefer the first patch
(http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/190100.html).

Although C11/C++ made significant progress in standardizing the C/C++
memory model, many good programmers still have trouble understanding
it. Code that always accesses progress[field] under the protection of
progress_mutex is very easy to understand. Given how expensive it is
to decode video frame, I cannot help but suspect the double-checked
locking style code in ff_thread_report_progress and
ff_thread_await_progress is premature optimization. If we want to
preserve it, this patch makes it correct.

2. While working on this patch, I found the order of the load/store
operation and the memory barrier in some avpriv_atomic_int_get and
avpriv_atomic_int_set implementations seems wrong. For example,
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html has examples of
how atomic load and store operations are mapped to assembly code. Some
examples for Load Seq Cst and Store Seq Cst use no memory barrier or
two memory barriers. But in the examples that use one memory barrier,
the order of the load/store operation and the memory barrier is
opposite to the order in avpriv_atomic_int_get and
avpriv_atomic_int_set.

Should I split this change into a separate patch?

3. The Solaris Studio compiler intrinsics for memory barriers (which
are used in atomic_suncc.h) are documented at:

https://docs.oracle.com/cd/E24457_01/html/E21991/gjzmf.html

On Mon, Feb 29, 2016 at 7:05 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Mon, Feb 29, 2016 at 9:35 PM, Wan-Teh Chang > wrote:
>
>> Correct the order of the load/store operation and the memory barrier in
>> avpriv_atomic_int_get and avpriv_atomic_int_set.
>
> This sounds useful. Is there some documentation on which one should be used
> under what conditions? I.e. when do I need full, release or acquire?

http://en.cppreference.com/w/c/atomic/memory_order is pretty good. I
am surprised that I can't find a good Wikipedia article on this
subject. The best I can find is
https://en.wikipedia.org/wiki/Memory_ordering.

I'd like to reiterate that this is difficult for many good
programmers. I need the relaxed and acquire/release flavors of
avpriv_atomic_int_get and avpriv_atomic_int_set to make the
ff_thread_report_progress and ff_thread_await_progress code portable
and to ensure that the new code is identical to the original code for
x86/x86_64, according to the mappings in
https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html.

Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder

[Timothy Gu]

Hi,

On Mon, Feb 29, 2016 at 9:42 PM Rick Kern  wrote:

> Autodetected by default. Encode using -codec:v vtenc.
>
> Signed-off-by: Rick Kern 
> ---
>  MAINTAINERS|1 +
>  configure  |   19 +
>  libavcodec/Makefile|1 +
>  libavcodec/allcodecs.c |1 +
>  libavcodec/vtenc.c | 1339
> 
>  5 files changed, 1361 insertions(+)
>  create mode 100644 libavcodec/vtenc.c
>

We already have videotoolbox AVHWAccel. Maybe it would be better to change
the name of the file to videotoolboxenc.c so that it's easier to associate
these two files?

> +AVCodec ff_vtenc_encoder = {

> +.name = "vtenc",
> +.long_name= NULL_IF_CONFIG_SMALL("VideoToolbox H.264
> Encoder"),
>

The norm seems to be using "h264_videotoolbox" (like "h264_qsv") so that
potential future extensions to VideoToolbox can be supported without
changing the name of the codec.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix a bug in ff_thread_report_progress in updating progress[field].

[Wan-Teh Chang]

On Mon, Feb 29, 2016 at 7:00 PM, Ronald S. Bultje  wrote:
>
> Do you have a sample+commandline to reproduce? The thing is, in all cases
> where we use this, only one thread writes to a specific progress[n]. Two
> threads may write to progress[], one per field, but one will write to
> progress[0] and the other to progress[1]. If this happens, I don't mind the
> patch, but I'd like to know how exactly this happens (also for posterity
> documentation purposes).

Dmitry Vyukov found this issue by code inspection. We understand this
is a bug only if two threads may call ff_thread_report_progress, on
the same progress[field] value (which I didn't state in my original
report), at the same time. I thought we should report the issue here
to get your opinion.

You can reject this patch, or accept the patch to make it easier to
reason about the correctness of the code.

By the way, I'm also wondering why ff_thread_report_progress is
sometimes called with progress[field] >= n? I saw it happen when I ran
make fate-h264, but did not investigate it.

Thanks,
Wan-Teh Chang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Paul B Mahol]

On 3/1/16, Ronald S. Bultje  wrote:
> Hi,
>
> On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos  wrote:
>
>> Ronald S. Bultje  gmail.com> writes:
>>
>> > > So how does this mechanism look like for the requested
>> > > use case?
>> >
>> > man ln.
>>
>> As said, this is a completely ridiculous argument:
>> FFmpeg has always tried to provide new features, no
>> matter if other solutions existed or not.
>
>
> When you don't get your way, just shout "ridiculous!" and all will be okay.

Its just few loc. I see nothing wrong with it, lets vote!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value

[Rostislav Pehlivanov]

On 1 March 2016 at 03:21, Ganesh Ajjanagadde  wrote:

> It makes no sense whatsoever to do this at each function call; we
> already have a table for this.
>
> Yields a 2x improvement in find_min_book (x86-64, Haswell+GCC):
> ffmpeg -i sin.flac -acodec aac -y sin.aac
> find_min_book
> old
> 605 decicycles in find_min_book, 8388453 runs,155 skips.9x
> 606 decicycles in find_min_book,16776912 runs,304 skips.9x
> 607 decicycles in find_min_book,33553819 runs,613 skips.2x
> 607 decicycles in find_min_book,67107668 runs,   1196 skips.3x
> 607 decicycles in find_min_book,134215360 runs,   2368 skips3x
>
> new
> 359 decicycles in find_min_book, 8388552 runs, 56 skips.3x
> 360 decicycles in find_min_book,16777112 runs,104 skips.1x
> 361 decicycles in find_min_book,33554218 runs,214 skips.4x
> 361 decicycles in find_min_book,67108381 runs,483 skips.5x
> 361 decicycles in find_min_book,134216725 runs,   1003 skips5x
>
> and more importantly a non-negligible speedup (~ 8%) to overall AAC
> encoding:
> old:
> ffmpeg -i sin.flac -acodec aac -strict -2 -y sin_new.aac  6.82s user 0.03s
> system 104% cpu 6.565 total
> new:
> ffmpeg -i sin.flac -acodec aac -strict -2 -y sin_old.aac  6.24s user 0.03s
> system 104% cpu 5.993 total
>
> Signed-off-by: Ganesh Ajjanagadde 
>

Nicely spotted, thanks.

LGTM, feel free to apply whenever you can.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder

[wm4]

On Tue, 1 Mar 2016 11:31:18 +0100
Michael Niedermayer  wrote:

> On Tue, Mar 01, 2016 at 01:40:53PM +0800, Rick Kern wrote:
> > Autodetected by default. Encode using -codec:v vtenc.  
> [...]
> > +static void set_async_error(VTEncContext *vtctx, int err)
> > +{
> > +BufNode *info;
> > +
> > +pthread_mutex_lock(>lock);
> > +
> > +vtctx->async_error = err;
> > +
> > +info = vtctx->q_head;
> > +vtctx->q_head = vtctx->q_tail = NULL;
> > +
> > +while (info) {
> > +BufNode *next = info->next;
> > +CFRelease(info->cm_buffer);
> > +free(info);  
> 
> should probably av_free()
> 
> > +info = next;
> > +}
> > +
> > +pthread_mutex_unlock(>lock);
> > +}
> > +
> > +static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
> > *buf)
> > +{
> > +BufNode *info;
> > +
> > +pthread_mutex_lock(>lock);
> > +
> > +if (vtctx->async_error) {
> > +pthread_mutex_unlock(>lock);
> > +return vtctx->async_error;
> > +}
> > +
> > +if (vtctx->flushing && vtctx->frame_ct_in == vtctx->frame_ct_out) {
> > +*buf = NULL;
> > +
> > +pthread_mutex_unlock(>lock);
> > +return 0;
> > +}
> > +
> > +while (!vtctx->q_head && !vtctx->async_error && wait) {
> > +pthread_cond_wait(>cv_sample_sent, >lock);
> > +}
> > +
> > +if (!vtctx->q_head) {
> > +pthread_mutex_unlock(>lock);
> > +*buf = NULL;
> > +return 0;
> > +}
> > +
> > +info = vtctx->q_head;
> > +vtctx->q_head = vtctx->q_head->next;
> > +if (!vtctx->q_head) {
> > +vtctx->q_tail = NULL;
> > +}
> > +
> > +pthread_mutex_unlock(>lock);
> > +
> > +*buf = info->cm_buffer;  
> 
> > +free(info);  
> 
> same
> 
> [...]

PS: I'll change them locally to av_free() and then push in some time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 8:04 AM, Carl Eugen Hoyos  wrote:

> Ronald S. Bultje  gmail.com> writes:
>
> > > So how does this mechanism look like for the requested
> > > use case?
> >
> > man ln.
>
> As said, this is a completely ridiculous argument:
> FFmpeg has always tried to provide new features, no
> matter if other solutions existed or not.


When you don't get your way, just shout "ridiculous!" and all will be okay.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Check for msghdr struct

[Moritz Barsnick]

On Tue, Mar 01, 2016 at 14:00:14 +0100, Moritz Barsnick wrote:
> Possibly only the first one. I assumed that CMSG_SPACE was related, but
> that was my mind running amok.

Actually, other sources hint that they are all related, defined as
X/Open Unix Extensions. And these need to be enabled under Solaris (or
at least under this very old one). The first mentioned link quotes from
Solaris's sources:

> application writers wishing to use any functions specified as X/Open
> UNIX Extension must define _XOPEN_SOURCE and
> _XOPEN_SOURCE_EXTENDED=1. The Sun internal macro _XPG4_2 should not
> be used in its place as unexpected results may occur.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] configure: build fix for mips cpu p5600

[shivraj.patil]

From: Shivraj Patil 

For P5600 mips cpu, cpuflags="-march=p5600" sets mips32r5 by default.
Current configuration sets mips32r2 for p5600 cpu, hence ldflag check results 
in,
error: '-mips32r2' conflicts with the other architecture options, which specify 
a mips32r5 processor

Due to above error, mips32r2 gets disabled avoiding necessary msa flag 
settings, which breaks the build.
To fix this issue, introduced mips32r5 in mips arch list which is more 
appropriate.

Signed-off-by: Shivraj Patil 
---
 configure |   23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 3f4a0c7..df9bb74 100755
--- a/configure
+++ b/configure
@@ -1661,6 +1661,7 @@ ARCH_EXT_LIST_ARM="
 ARCH_EXT_LIST_MIPS="
 mipsfpu
 mips32r2
+mips32r5
 mips64r2
 mips32r6
 mips64r6
@@ -4174,6 +4175,7 @@ elif enabled mips; then
 
 case $cpu in
 24kc)
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4186,6 +4188,7 @@ elif enabled mips; then
 disable mmi
 ;;
 24kf*)
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4197,6 +4200,7 @@ elif enabled mips; then
 disable mmi
 ;;
 24kec|34kc|1004kc)
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4208,6 +4212,7 @@ elif enabled mips; then
 disable mmi
 ;;
 24kef*|34kf*|1004kf*)
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4218,6 +4223,7 @@ elif enabled mips; then
 disable mmi
 ;;
 74kc)
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4237,6 +4243,7 @@ elif enabled mips; then
 disable mmi
 ;;
 p5600)
+disable mips32r2
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4251,6 +4258,7 @@ elif enabled mips; then
 ;;
 i6400)
 disable mips32r2
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mipsdsp
@@ -4265,6 +4273,7 @@ elif enabled mips; then
 ;;
 loongson*)
 disable mips32r2
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -4300,6 +4309,7 @@ elif enabled mips; then
 warn "unknown CPU. Disabling all MIPS optimizations."
 disable mipsfpu
 disable mips32r2
+disable mips32r5
 disable mips32r6
 disable mips64r2
 disable mips64r6
@@ -5152,14 +5162,21 @@ elif enabled mips; then
 check_inline_asm mips32r6 '"aui $0, $0, 0"' ||
 disable mips32r6
 fi
-if disabled mips32r6 && enabled mips32r2; then
+if disabled mips32r6 && enabled mips32r5; then
+check_ldflags "-mips32r5" &&
+add_cflags "-mips32r5" &&
+add_asflags "-mips32r5" &&
+check_inline_asm mips32r5 '"eretnc"' ||
+disable mips32r5
+fi
+if disabled mips32r6 && disabled mips32r5 && enabled mips32r2; then
 check_ldflags "-mips32r2" &&
 add_cflags "-mips32r2" &&
 add_asflags "-mips32r2" &&
 check_inline_asm mips32r2 '"ext $0, $0, 0, 1"' ||
 disable mips32r2
 fi
-if disabled mips32r6 && disabled mips32r2; then
+if disabled mips32r6 && disabled mips32r5 && disabled mips32r2; then
 check_ldflags "-mips32" &&
 add_cflags "-mips32" &&
 add_asflags "-mips32" &&
@@ -5178,7 +5195,7 @@ elif enabled mips; then
 fi
 
 # MSA and DSP support require ISA revision level 2 or greater
-if enabled mips32r2 || enabled mips64r2 || enabled mips32r6 || enabled 
mips64r6; then
+if enabled mips32r2 || enabled mips64r2 || enabled mips32r5 || enabled 
mips32r6 || enabled mips64r6; then
 # MSA must be used with -mfp64 and -mhard-float
 if enabled mipsfpu; then
 if enabled msa; then
-- 
1.7.9.5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] disabled loongson2, loongson3 and mmi for non-loongson cpu

[shivraj.patil]

From: Shivraj Patil 

For mips P5600/I6400 configure, assembler throws errors at check_inline_asm for 
loongson2, loongson3 and mmi as the instructions opcode not supported on this 
processor. Hence disabled loongson2, loongson3 and mmi in non loogson mips cpus.

Signed-off-by: Shivraj Patil 
---
 configure |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/configure b/configure
index 8491fa1..3f4a0c7 100755
--- a/configure
+++ b/configure
@@ -4181,6 +4181,9 @@ elif enabled mips; then
 disable mipsdsp
 disable mipsdspr2
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 24kf*)
 disable mips32r6
@@ -4189,6 +4192,9 @@ elif enabled mips; then
 disable mipsdsp
 disable mipsdspr2
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 24kec|34kc|1004kc)
 disable mips32r6
@@ -4197,6 +4203,9 @@ elif enabled mips; then
 disable mipsfpu
 disable mipsdspr2
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 24kef*|34kf*|1004kf*)
 disable mips32r6
@@ -4204,6 +4213,9 @@ elif enabled mips; then
 disable mips64r6
 disable mipsdspr2
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 74kc)
 disable mips32r6
@@ -4211,12 +4223,18 @@ elif enabled mips; then
 disable mips64r6
 disable mipsfpu
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 74kf)
 disable mips32r6
 disable mips64r2
 disable mips64r6
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 p5600)
 disable mips32r6
@@ -4224,6 +4242,9 @@ elif enabled mips; then
 disable mips64r6
 disable mipsdsp
 disable mipsdspr2
+disable loongson2
+disable loongson3
+disable mmi
 check_cflags "-mtune=p5600" &&
 check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
 add_asflags "-mfp64"
@@ -4234,6 +4255,9 @@ elif enabled mips; then
 disable mips64r2
 disable mipsdsp
 disable mipsdspr2
+disable loongson2
+disable loongson3
+disable mmi
 check_cflags "-mtune=i6400 -mabi=64" &&
 check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
 check_ldflags "-mabi=64" &&
@@ -4282,6 +4306,9 @@ elif enabled mips; then
 disable mipsdsp
 disable mipsdspr2
 disable msa
+disable loongson2
+disable loongson3
+disable mmi
 ;;
 esac
 
-- 
1.7.9.5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

> > So how does this mechanism look like for the requested
> > use case?
> 
> man ln.

As said, this is a completely ridiculous argument:
FFmpeg has always tried to provide new features, no 
matter if other solutions existed or not.

Apart from the fact that ln does not exist on all 
OSes we support.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Ronald S. Bultje]

Hi,

On Tue, Mar 1, 2016 at 7:00 AM, Carl Eugen Hoyos  wrote:

> wm4  googlemail.com> writes:
>
> > Adding dozens of small very specialized features leads to
> > unmaintainable and unusable software, even if the change
> > itself is inoffensive.
>
> I don't think this is a "small" feature, I consider it a
> very useful request.
> I also wonder why it is "very specialized": I can see a
> few uses for the new option.


Nonetheless, it does not belong in ffmpeg or libav*.

> Powerful, orthogonal mechanisms will always be superior.
>
> So how does this mechanism look like for the requested
> use case?


man ln.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value

[Derek Buitenhuis]

On 3/1/2016 3:21 AM, Ganesh Ajjanagadde wrote:

[...]

> ---
>  libavcodec/aacenc_utils.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Cool. Looks like an obvious/easy win, assuming it's identical.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Check for msghdr struct

[Moritz Barsnick]

On Tue, Mar 01, 2016 at 12:01:10 +, Carl Eugen Hoyos wrote:
> Which of the links you provided is related to msghdr?

Possibly only the first one. I assumed that CMSG_SPACE was related, but
that was my mind running amok.

It would be easier to see if we had the Solaris headers or a Solaris
install available. (I do know *OpenSolaris* can be downloaded. I don't
want to right now. ;-))

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder

[wm4]

On Tue, 1 Mar 2016 11:31:18 +0100
Michael Niedermayer  wrote:

> On Tue, Mar 01, 2016 at 01:40:53PM +0800, Rick Kern wrote:
> > Autodetected by default. Encode using -codec:v vtenc.  
> [...]
> > +static void set_async_error(VTEncContext *vtctx, int err)
> > +{
> > +BufNode *info;
> > +
> > +pthread_mutex_lock(>lock);
> > +
> > +vtctx->async_error = err;
> > +
> > +info = vtctx->q_head;
> > +vtctx->q_head = vtctx->q_tail = NULL;
> > +
> > +while (info) {
> > +BufNode *next = info->next;
> > +CFRelease(info->cm_buffer);
> > +free(info);  
> 
> should probably av_free()
> 
> > +info = next;
> > +}
> > +
> > +pthread_mutex_unlock(>lock);
> > +}
> > +
> > +static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
> > *buf)
> > +{
> > +BufNode *info;
> > +
> > +pthread_mutex_lock(>lock);
> > +
> > +if (vtctx->async_error) {
> > +pthread_mutex_unlock(>lock);
> > +return vtctx->async_error;
> > +}
> > +
> > +if (vtctx->flushing && vtctx->frame_ct_in == vtctx->frame_ct_out) {
> > +*buf = NULL;
> > +
> > +pthread_mutex_unlock(>lock);
> > +return 0;
> > +}
> > +
> > +while (!vtctx->q_head && !vtctx->async_error && wait) {
> > +pthread_cond_wait(>cv_sample_sent, >lock);
> > +}
> > +
> > +if (!vtctx->q_head) {
> > +pthread_mutex_unlock(>lock);
> > +*buf = NULL;
> > +return 0;
> > +}
> > +
> > +info = vtctx->q_head;
> > +vtctx->q_head = vtctx->q_head->next;
> > +if (!vtctx->q_head) {
> > +vtctx->q_tail = NULL;
> > +}
> > +
> > +pthread_mutex_unlock(>lock);
> > +
> > +*buf = info->cm_buffer;  
> 
> > +free(info);  
> 
> same

Indeed, it should be.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]configure: Check for msghdr struct

[Carl Eugen Hoyos]

Moritz Barsnick  gmx.net> writes:

> On Tue, Mar 01, 2016 at 10:32:55 +0100, Carl Eugen Hoyos wrote:
> > A user claims that not all (Solaris) systems have a sufficiently 
> > new msghdr struct. Attached patch adds an additional check.
> 
> This disables the sctp protocol on those systems then? Probably 
> fine, but *searchengine* tells me that some parts of the 
> implementation are hidden behind defines

Which of the links you provided is related to msghdr?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> Adding dozens of small very specialized features leads to
> unmaintainable and unusable software, even if the change 
> itself is inoffensive. 

I don't think this is a "small" feature, I consider it a 
very useful request.
I also wonder why it is "very specialized": I can see a 
few uses for the new option.

> Powerful, orthogonal mechanisms will always be superior.

So how does this mechanism look like for the requested 
use case?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v9] VideoToolbox H.264 Encoder

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 01:40:53PM +0800, Rick Kern wrote:
> Autodetected by default. Encode using -codec:v vtenc.
[...]
> +static void set_async_error(VTEncContext *vtctx, int err)
> +{
> +BufNode *info;
> +
> +pthread_mutex_lock(>lock);
> +
> +vtctx->async_error = err;
> +
> +info = vtctx->q_head;
> +vtctx->q_head = vtctx->q_tail = NULL;
> +
> +while (info) {
> +BufNode *next = info->next;
> +CFRelease(info->cm_buffer);
> +free(info);

should probably av_free()

> +info = next;
> +}
> +
> +pthread_mutex_unlock(>lock);
> +}
> +
> +static int vtenc_q_pop(VTEncContext *vtctx, bool wait, CMSampleBufferRef 
> *buf)
> +{
> +BufNode *info;
> +
> +pthread_mutex_lock(>lock);
> +
> +if (vtctx->async_error) {
> +pthread_mutex_unlock(>lock);
> +return vtctx->async_error;
> +}
> +
> +if (vtctx->flushing && vtctx->frame_ct_in == vtctx->frame_ct_out) {
> +*buf = NULL;
> +
> +pthread_mutex_unlock(>lock);
> +return 0;
> +}
> +
> +while (!vtctx->q_head && !vtctx->async_error && wait) {
> +pthread_cond_wait(>cv_sample_sent, >lock);
> +}
> +
> +if (!vtctx->q_head) {
> +pthread_mutex_unlock(>lock);
> +*buf = NULL;
> +return 0;
> +}
> +
> +info = vtctx->q_head;
> +vtctx->q_head = vtctx->q_head->next;
> +if (!vtctx->q_head) {
> +vtctx->q_tail = NULL;
> +}
> +
> +pthread_mutex_unlock(>lock);
> +
> +*buf = info->cm_buffer;

> +free(info);

same

[...]
-- 
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]configure: Check for msghdr struct

[Moritz Barsnick]

On Tue, Mar 01, 2016 at 10:32:55 +0100, Carl Eugen Hoyos wrote:
> A user claims that not all (Solaris) systems have a sufficiently new msghdr 
> struct. Attached patch adds an additional check.

This disables the sctp protocol on those systems then? Probably fine,
but *searchengine* tells me that some parts of the implementation are
hidden behind defines (which ffmpeg may or may not want to use):
http://stackoverflow.com/q/1034587
https://groups.google.com/forum/#!topic/comp.unix.solaris/xSGPgkzndIc
https://bugs.freedesktop.org/show_bug.cgi?id=40235

But then, without understanding the impact of these defines (at least
globally), and especially without the possibility of trying to build on
Solaris, this may indeed be the easiest fix.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available

[Michael Niedermayer]

On Tue, Mar 01, 2016 at 10:57:57AM +0100, Nicolas George wrote:
> Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit :
> > I have checked the code where and when duration filled and made some
> > reasoning about it.
> > Duration value for input files has been populated some time after opening.
> > (estimate_timings function in utils.c) And never again corrected or called
> > this function..
> > So, if early in processing there is no duration info, it remains empty.
> > When input is not a seekable file but a not-seekable stream, the only chance
> > to get a duration info  when the stream itself contains info about this
> > value. (eg. flv metadata, mp4-moov)
> > But mpegts format does not contain this info. So the only moment when
> > duration calculatable is when we finish the reading. I think contoniously
> > updating the duration value after each packet would not be a good idea.
> > (cur_dts is updated is AVStream->info struct)
> > 
> > So reading a file via pipe or reading hls stream via http it is normal that
> > duration value remains empty.
> > 
> > thus, I think to handle the cases when duration value is not populated, this
> > is not a bug fix but a reasonable solution for these cases.
> > 
> > I agree with you that we should not "measure" our-own the pts values but I
> > could not find any existing/available data member to have this info.
> 
> Sorry for the late reply, I was distracted.
> 
> If I summarize correctly your findings:
> 
> For formats without a reliable duration header with seekable backing, the
> duration is evaluated at the opening by peeking at the last timestamps.
> 
> With unseekable backing, the duration is not evaluated at all.
> 
> In particular, the duration is not updated once the end of the file is
> reached.
> 
> Well, I thought it was and wrote the code in consequence, thanks for
> correcting me.
> 
> Still, the logic for tracking the duration can be a bit tricky, possibly
> trickier than your original patch if there are B-frames and timestamps
> resets. I would rather have it in a common part of the code than in the
> concat demuxer.
> 
> I suspect we could consider adding AVStream.current_duration that tracks the
> maximum recently seen PTS for each stream.
> 
> (We could also have a function that peeks in AVStream.pts_buffer, but that
> looks tricky; and the corresponding duration is not available.)
> 

> I hope other can give advice about this issue.

somewhat independant of this, but i thik some kind of "indexer"
input would be usefull
i mean a input format that opens another input and sequentially reads
the whole at open and creates an index
with that exact seeking, exact bitrate, exact duration would become
available.
the index could also be stored in a on disk cache if the user wants
making repeated opening of the same file not require sequentially
scaning the whole

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] sws/aarch64: add {nv12, nv21, yuv420p, yuv422p}_to_{argb, rgba, abgr, rgba}_neon

[Clément Bœsch]

On Mon, Feb 29, 2016 at 10:55:49AM +0100, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> ---
> Changes since latest version:
> - remove unused 32-bit path
> - make 16-bit path more accurate by mirroring the MMX code (still not 
> bitexact)
> - the code as originally trying to process 2 lines at a time to save chroma 
> pre
>   mult computations and avoid re-reading the whole line; for some reason, this
>   actually made the code around twice slower, for twice the complexity.
>   dropping that complexity was a win-win.
> ---
>  libswscale/aarch64/Makefile   |   3 +
>  libswscale/aarch64/swscale_unscaled.c | 132 ++
>  libswscale/aarch64/yuv2rgb_neon.S | 207 
> ++
>  libswscale/swscale_internal.h |   1 +
>  libswscale/swscale_unscaled.c |   2 +
>  5 files changed, 345 insertions(+)
>  create mode 100644 libswscale/aarch64/Makefile
>  create mode 100644 libswscale/aarch64/swscale_unscaled.c
>  create mode 100644 libswscale/aarch64/yuv2rgb_neon.S
> 

Random benchmark on Hikey (Cortex-A53):

./ffmpeg -nostats -f lavfi -i testsrc2=s=uhd2160:d=1 -vf 
format=yuv420p,bench=start,format=rgba,bench=stop -f null -

(yuv420p to rgba in 3840x2160)

before:
[bench @ 0x2edfe1e0] t:0.181514 avg:0.181514 max:0.181514 min:0.181514
[bench @ 0x2edfe1e0] t:0.178870 avg:0.180192 max:0.181514 min:0.178870
[bench @ 0x2edfe1e0] t:0.164448 avg:0.174944 max:0.181514 min:0.164448
[bench @ 0x2edfe1e0] t:0.164801 avg:0.172408 max:0.181514 min:0.164448
[bench @ 0x2edfe1e0] t:0.164635 avg:0.170853 max:0.181514 min:0.164448
[bench @ 0x2edfe1e0] t:0.164756 avg:0.169837 max:0.181514 min:0.164448
[bench @ 0x2edfe1e0] t:0.164784 avg:0.169115 max:0.181514 min:0.164448
[bench @ 0x2edfe1e0] t:0.164413 avg:0.168527 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164760 avg:0.168109 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164647 avg:0.167762 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164698 avg:0.167484 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164600 avg:0.167243 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164498 avg:0.167032 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164765 avg:0.166870 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164613 avg:0.166720 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164781 avg:0.166598 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164489 avg:0.166474 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164432 avg:0.166361 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164540 avg:0.166265 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.164524 avg:0.166178 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.165147 avg:0.166129 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.165484 avg:0.166099 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.165703 avg:0.166082 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.165643 avg:0.166064 max:0.181514 min:0.164413
[bench @ 0x2edfe1e0] t:0.165294 avg:0.166033 max:0.181514 min:0.164413

after:
[bench @ 0x16d871e0] t:0.042296 avg:0.042296 max:0.042296 min:0.042296
[bench @ 0x16d871e0] t:0.041986 avg:0.042141 max:0.042296 min:0.041986
[bench @ 0x16d871e0] t:0.027298 avg:0.037193 max:0.042296 min:0.027298
[bench @ 0x16d871e0] t:0.027388 avg:0.034742 max:0.042296 min:0.027298
[bench @ 0x16d871e0] t:0.027383 avg:0.033270 max:0.042296 min:0.027298
[bench @ 0x16d871e0] t:0.027366 avg:0.032286 max:0.042296 min:0.027298
[bench @ 0x16d871e0] t:0.027225 avg:0.031563 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027685 avg:0.031078 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027246 avg:0.030652 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027363 avg:0.030323 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027449 avg:0.030062 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027582 avg:0.029855 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027374 avg:0.029664 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027429 avg:0.029505 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027275 avg:0.029356 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027573 avg:0.029244 max:0.042296 min:0.027225
[bench @ 0x16d871e0] t:0.027219 avg:0.029125 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027392 avg:0.029029 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027720 avg:0.028960 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027449 avg:0.028884 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027473 avg:0.028817 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027444 avg:0.028755 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027535 avg:0.028702 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027607 avg:0.028656 max:0.042296 min:0.027219
[bench @ 0x16d871e0] t:0.027476 avg:0.028609 max:0.042296 min:0.027219

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] OSX AudioToolbox codec support

[Carl Eugen Hoyos]

Rodger Combs  gmail.com> writes:

> This series adds decoders and encoders based on OSX's AudioToolbox
framework.  They may be faster than the native ones (particularly in 
> cases where they can be hardware-accelerated), the encoders are 
> competitive on quality, and some

I think this is a great addition to FFmpeg!

> users may find them convenient from a licensing perspective.

I believe it makes no difference.

> ADPCM_IMA_QT can also be encoded by AudioToolbox, but I couldn't 
> figure out how to get it working properly, so it's left with 
> just the decoders.

> I'm not sure if the alaw/ulaw and IMA codecs are worth having 
> at all since they're so simple; I just threw them in since 
> they were easy.

Please keep them.

> The ALAC encoder and decoder have been tested as bitexact.

Also with our implementation?

Please mention ticket #4828 in the commit message and please 
bump minor, not micro.

Thank you, Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available

[Nicolas George]

Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit :
> I have checked the code where and when duration filled and made some
> reasoning about it.
> Duration value for input files has been populated some time after opening.
> (estimate_timings function in utils.c) And never again corrected or called
> this function..
> So, if early in processing there is no duration info, it remains empty.
> When input is not a seekable file but a not-seekable stream, the only chance
> to get a duration info  when the stream itself contains info about this
> value. (eg. flv metadata, mp4-moov)
> But mpegts format does not contain this info. So the only moment when
> duration calculatable is when we finish the reading. I think contoniously
> updating the duration value after each packet would not be a good idea.
> (cur_dts is updated is AVStream->info struct)
> 
> So reading a file via pipe or reading hls stream via http it is normal that
> duration value remains empty.
> 
> thus, I think to handle the cases when duration value is not populated, this
> is not a bug fix but a reasonable solution for these cases.
> 
> I agree with you that we should not "measure" our-own the pts values but I
> could not find any existing/available data member to have this info.

Sorry for the late reply, I was distracted.

If I summarize correctly your findings:

For formats without a reliable duration header with seekable backing, the
duration is evaluated at the opening by peeking at the last timestamps.

With unseekable backing, the duration is not evaluated at all.

In particular, the duration is not updated once the end of the file is
reached.

Well, I thought it was and wrote the code in consequence, thanks for
correcting me.

Still, the logic for tracking the duration can be a bit tricky, possibly
trickier than your original patch if there are B-frames and timestamps
resets. I would rather have it in a common part of the code than in the
concat demuxer.

I suspect we could consider adding AVStream.current_duration that tracks the
maximum recently seen PTS for each stream.

(We could also have a function that peeks in AVStream.pts_buffer, but that
looks tricky; and the corresponding duration is not available.)

I hope other can give advice about this issue.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Accepted for GSoC 2016

[Carl Eugen Hoyos]

Hi!

https://summerofcode.withgoogle.com/organizations/6504812191416320/

FFmpeg was accepted for GSoC 2016, thank you to everybody who 
helped with the wiki page and / or added himself as a mentor!

If you have an idea for a doable, strictly defined project 
that a student has a chance to finish, please add it to the 
wiki page, if you want to mentor an existing project, please 
add yourself!

Thank you, Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavc: add AudioToolbox decoders

[Rodger Combs]

---
 Changelog|   1 +
 configure|  24 
 libavcodec/Makefile  |  14 ++
 libavcodec/allcodecs.c   |  14 ++
 libavcodec/audiotoolboxdec.c | 334 +++
 libavcodec/version.h |   2 +-
 6 files changed, 388 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/audiotoolboxdec.c

diff --git a/Changelog b/Changelog
index c683cda..7bf9de3 100644
--- a/Changelog
+++ b/Changelog
@@ -8,6 +8,7 @@ version :
 - Bob Weaver deinterlacing filter
 - firequalizer filter
 - datascope filter
+- AudioToolbox audio decoders
 
 
 version 3.0:
diff --git a/configure b/configure
index 8491fa1..5a9725b 100755
--- a/configure
+++ b/configure
@@ -195,6 +195,7 @@ Individual component options:
   --disable-filtersdisable all filters
 
 External library support:
+  --disable-audiotoolbox   enable AudioToolbox decoders and encoders 
[autodetect]
   --enable-avisynthenable reading of AviSynth script files [no]
   --disable-bzlib  disable bzlib [autodetect]
   --enable-cudaenable dynamically linked CUDA [no]
@@ -1425,6 +1426,7 @@ EXAMPLE_LIST="
 "
 
 EXTERNAL_LIBRARY_LIST="
+audiotoolbox
 avisynth
 bzlib
 chromaprint
@@ -2479,6 +2481,10 @@ zlib_encoder_select="zlib"
 zmbv_decoder_select="zlib"
 zmbv_encoder_select="zlib"
 
+# platform codecs
+audiotoolbox_deps="AudioToolbox_AudioToolbox_h"
+audiotoolbox_extralibs="-framework CoreFoundation -framework AudioToolbox 
-framework CoreMedia"
+
 # hardware accelerators
 crystalhd_deps="libcrystalhd_libcrystalhd_if_h"
 d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
@@ -2610,6 +2616,20 @@ vc1_parser_select="vc1dsp"
 mjpeg2jpeg_bsf_select="jpegtables"
 
 # external libraries
+aac_at_decoder_deps="audiotoolbox"
+ac3_at_decoder_deps="audiotoolbox"
+adpcm_ima_qt_at_decoder_deps="audiotoolbox"
+alac_at_decoder_deps="audiotoolbox"
+amr_nb_at_decoder_deps="audiotoolbox"
+gsm_ms_at_decoder_deps="audiotoolbox"
+ilbc_at_decoder_deps="audiotoolbox"
+mp1_at_decoder_deps="audiotoolbox"
+mp2_at_decoder_deps="audiotoolbox"
+mp3_at_decoder_deps="audiotoolbox"
+pcm_alaw_at_decoder_deps="audiotoolbox"
+pcm_mulaw_at_decoder_deps="audiotoolbox"
+qdmc_at_decoder_deps="audiotoolbox"
+qdm2_at_decoder_deps="audiotoolbox"
 chromaprint_muxer_deps="chromaprint"
 libcelt_decoder_deps="libcelt"
 libdcadec_decoder_deps="libdcadec"
@@ -3051,6 +3071,9 @@ enable valgrind_backtrace
 sws_max_filter_size_default=256
 set_default sws_max_filter_size
 
+# Enable platform codecs by default.
+enable audiotoolbox
+
 # Enable hwaccels by default.
 enable d3d11va dxva2 vaapi vda vdpau videotoolbox xvmc
 enable xlib
@@ -5424,6 +5447,7 @@ check_func_headers glob.h glob
 enabled xlib &&
 check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute 
-lXv -lX11 -lXext
 
+check_header AudioToolbox/AudioToolbox.h
 check_header direct.h
 check_header dirent.h
 check_header dlfcn.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 667e257..aec2fda 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -795,6 +795,20 @@ OBJS-$(CONFIG_WEBM_MUXER)  += mpeg4audio.o 
mpegaudiodata.o  \
 OBJS-$(CONFIG_ELBG_FILTER) += elbg.o
 
 # external codec libraries
+OBJS-$(CONFIG_AAC_AT_DECODER) += audiotoolboxdec.o
+OBJS-$(CONFIG_AC3_AT_DECODER) += audiotoolboxdec.o
+OBJS-$(CONFIG_ADPCM_IMA_QT_AT_DECODER)+= audiotoolboxdec.o
+OBJS-$(CONFIG_ALAC_AT_DECODER)+= audiotoolboxdec.o
+OBJS-$(CONFIG_AMR_NB_AT_DECODER)  += audiotoolboxdec.o
+OBJS-$(CONFIG_GSM_MS_AT_DECODER)  += audiotoolboxdec.o
+OBJS-$(CONFIG_ILBC_AT_DECODER)+= audiotoolboxdec.o
+OBJS-$(CONFIG_MP1_AT_DECODER) += audiotoolboxdec.o
+OBJS-$(CONFIG_MP2_AT_DECODER) += audiotoolboxdec.o
+OBJS-$(CONFIG_MP3_AT_DECODER) += audiotoolboxdec.o
+OBJS-$(CONFIG_PCM_MULAW_AT_DECODER)   += audiotoolboxdec.o
+OBJS-$(CONFIG_PCM_ALAW_AT_DECODER)+= audiotoolboxdec.o
+OBJS-$(CONFIG_QDMC_AT_DECODER)+= audiotoolboxdec.o
+OBJS-$(CONFIG_QDM2_AT_DECODER)+= audiotoolboxdec.o
 OBJS-$(CONFIG_LIBCELT_DECODER)+= libcelt_dec.o
 OBJS-$(CONFIG_LIBDCADEC_DECODER)  += libdcadec.o dca.o
 OBJS-$(CONFIG_LIBFAAC_ENCODER)+= libfaac.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2097db0..5cba33c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -562,6 +562,20 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (XSUB,  xsub);
 
 /* external libraries */
+REGISTER_DECODER(AAC_AT,aac_at);
+REGISTER_DECODER(AC3_AT,ac3_at);
+REGISTER_DECODER(ADPCM_IMA_QT_AT,   adpcm_ima_qt_at);
+REGISTER_DECODER(ALAC_AT,   alac_at);
+REGISTER_DECODER(AMR_NB_AT, amr_nb_at);
+REGISTER_DECODER(GSM_MS_AT, gsm_ms_at);
+

[FFmpeg-devel] [PATCH 2/2] lavc: add AudioToolbox encoders

[Rodger Combs]

---
 Changelog|   1 +
 configure|  10 +
 libavcodec/Makefile  |   5 +
 libavcodec/allcodecs.c   |  10 +-
 libavcodec/audiotoolboxenc.c | 471 +++
 libavcodec/version.h |   2 +-
 6 files changed, 493 insertions(+), 6 deletions(-)
 create mode 100644 libavcodec/audiotoolboxenc.c

diff --git a/Changelog b/Changelog
index 7bf9de3..9f38d46 100644
--- a/Changelog
+++ b/Changelog
@@ -9,6 +9,7 @@ version :
 - firequalizer filter
 - datascope filter
 - AudioToolbox audio decoders
+- AudioToolbox audio encoders
 
 
 version 3.0:
diff --git a/configure b/configure
index 5a9725b..22ae1ba 100755
--- a/configure
+++ b/configure
@@ -2630,6 +2630,16 @@ pcm_alaw_at_decoder_deps="audiotoolbox"
 pcm_mulaw_at_decoder_deps="audiotoolbox"
 qdmc_at_decoder_deps="audiotoolbox"
 qdm2_at_decoder_deps="audiotoolbox"
+aac_at_encoder_deps="audiotoolbox"
+aac_at_encoder_select="audio_frame_queue"
+alac_at_encoder_deps="audiotoolbox"
+alac_at_encoder_select="audio_frame_queue"
+ilbc_at_encoder_deps="audiotoolbox"
+ilbc_at_encoder_select="audio_frame_queue"
+pcm_alaw_at_encoder_deps="audiotoolbox"
+pcm_alaw_at_encoder_select="audio_frame_queue"
+pcm_mulaw_at_encoder_deps="audiotoolbox"
+pcm_mulaw_at_encoder_select="audio_frame_queue"
 chromaprint_muxer_deps="chromaprint"
 libcelt_decoder_deps="libcelt"
 libdcadec_decoder_deps="libdcadec"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index aec2fda..cef2260 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -809,6 +809,11 @@ OBJS-$(CONFIG_PCM_MULAW_AT_DECODER)   += 
audiotoolboxdec.o
 OBJS-$(CONFIG_PCM_ALAW_AT_DECODER)+= audiotoolboxdec.o
 OBJS-$(CONFIG_QDMC_AT_DECODER)+= audiotoolboxdec.o
 OBJS-$(CONFIG_QDM2_AT_DECODER)+= audiotoolboxdec.o
+OBJS-$(CONFIG_AAC_AT_ENCODER) += audiotoolboxenc.o
+OBJS-$(CONFIG_ALAC_AT_ENCODER)+= audiotoolboxenc.o
+OBJS-$(CONFIG_ILBC_AT_ENCODER)+= audiotoolboxenc.o
+OBJS-$(CONFIG_PCM_ALAW_AT_ENCODER)+= audiotoolboxenc.o
+OBJS-$(CONFIG_PCM_MULAW_AT_ENCODER)   += audiotoolboxenc.o
 OBJS-$(CONFIG_LIBCELT_DECODER)+= libcelt_dec.o
 OBJS-$(CONFIG_LIBDCADEC_DECODER)  += libdcadec.o dca.o
 OBJS-$(CONFIG_LIBFAAC_ENCODER)+= libfaac.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 5cba33c..0c69e69 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -562,18 +562,18 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (XSUB,  xsub);
 
 /* external libraries */
-REGISTER_DECODER(AAC_AT,aac_at);
+REGISTER_ENCDEC (AAC_AT,aac_at);
 REGISTER_DECODER(AC3_AT,ac3_at);
 REGISTER_DECODER(ADPCM_IMA_QT_AT,   adpcm_ima_qt_at);
-REGISTER_DECODER(ALAC_AT,   alac_at);
+REGISTER_ENCDEC (ALAC_AT,   alac_at);
 REGISTER_DECODER(AMR_NB_AT, amr_nb_at);
 REGISTER_DECODER(GSM_MS_AT, gsm_ms_at);
-REGISTER_DECODER(ILBC_AT,   ilbc_at);
+REGISTER_ENCDEC (ILBC_AT,   ilbc_at);
 REGISTER_DECODER(MP1_AT,mp1_at);
 REGISTER_DECODER(MP2_AT,mp2_at);
 REGISTER_DECODER(MP3_AT,mp3_at);
-REGISTER_DECODER(PCM_ALAW_AT,   pcm_alaw_at);
-REGISTER_DECODER(PCM_MULAW_AT,  pcm_mulaw_at);
+REGISTER_ENCDEC (PCM_ALAW_AT,   pcm_alaw_at);
+REGISTER_ENCDEC (PCM_MULAW_AT,  pcm_mulaw_at);
 REGISTER_DECODER(QDMC_AT,   qdmc_at);
 REGISTER_DECODER(QDM2_AT,   qdm2_at);
 REGISTER_DECODER(LIBCELT,   libcelt);
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
new file mode 100644
index 000..cb53f2a
--- /dev/null
+++ b/libavcodec/audiotoolboxenc.c
@@ -0,0 +1,471 @@
+/*
+ * Audio Toolbox system codecs
+ *
+ * copyright (c) 2016 Rodger Combs
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "config.h"
+#include "audio_frame_queue.h"
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+#include "libavformat/isom.h"
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "libavutil/log.h"
+
+typedef struct ATDecodeContext 

[FFmpeg-devel] OSX AudioToolbox codec support

[Rodger Combs]

This series adds decoders and encoders based on OSX's AudioToolbox framework.
They may be faster than the native ones (particularly in cases where they can
be hardware-accelerated), the encoders are competitive on quality, and some
users may find them convenient from a licensing perspective.

ADPCM_IMA_QT can also be encoded by AudioToolbox, but I couldn't figure out how
to get it working properly, so it's left with just the decoders.

I'm not sure if the alaw/ulaw and IMA codecs are worth having at all since
they're so simple; I just threw them in since they were easy.

The ALAC encoder and decoder have been tested as bitexact.

The decoder delay handling is pretty awkward and potentially wrong; I wish we
had a version of audio_frame_queue for decoders.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add bench and abench filters

[Clément Bœsch]

On Mon, Feb 29, 2016 at 07:37:35PM +0100, Paul B Mahol wrote:
> On 2/29/16, Clement Boesch  wrote:
> > From: Clement Boesch 
> >
> > ---
> > TODO: doc, bump, Changelog
> >
> > example: -vf bench=start,gradfun,format=rgba,hqx,bench=stop
> 
> Nice, LGTM with documentation changes.

Added average/min/max info, documented, lavfi bumped, Changelog updated,
and pushed.

Thanks.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]configure: Check for msghdr struct

[Carl Eugen Hoyos]

Hi!

A user claims that not all (Solaris) systems have a sufficiently new msghdr 
struct. Attached patch adds an additional check.

Please comment, Carl Eugen
diff --git a/configure b/configure
index 8491fa1..2831ce4 100755
--- a/configure
+++ b/configure
@@ -1929,6 +1929,7 @@ TYPES_LIST="
 struct_group_source_req
 struct_ip_mreq_source
 struct_ipv6_mreq
+struct_msghdr_msg_flags
 struct_pollfd
 struct_rusage_ru_maxrss
 struct_sctp_event_subscribe
@@ -2829,7 +2830,7 @@ rtmpt_protocol_select="ffrtmphttp_protocol"
 rtmpte_protocol_select="ffrtmpcrypt_protocol ffrtmphttp_protocol"
 rtmpts_protocol_select="ffrtmphttp_protocol https_protocol"
 rtp_protocol_select="udp_protocol"
-sctp_protocol_deps="struct_sctp_event_subscribe"
+sctp_protocol_deps="struct_sctp_event_subscribe struct_msghdr_msg_flags"
 sctp_protocol_select="network"
 srtp_protocol_select="rtp_protocol"
 tcp_protocol_select="network"
@@ -5325,6 +5326,7 @@ if ! disabled network; then
 check_type netinet/in.h "struct ipv6_mreq" -D_DARWIN_C_SOURCE
 check_type poll.h "struct pollfd"
 check_type netinet/sctp.h "struct sctp_event_subscribe"
+check_struct "sys/socket.h" "struct msghdr" msg_flags
 check_struct "sys/types.h sys/socket.h" "struct sockaddr" sa_len
 check_type netinet/in.h "struct sockaddr_in6"
 check_type "sys/types.h sys/socket.h" "struct sockaddr_storage"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel