[FFmpeg-devel] [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

From: Clément Bœsch 

---
 libavutil/threadmessage.c | 37 ++---
 libavutil/threadmessage.h | 21 ++---
 2 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index b7fcbe2..87ce8dc 100644
--- a/libavutil/threadmessage.c
+++ b/libavutil/threadmessage.c
@@ -40,14 +40,16 @@ struct AVThreadMessageQueue {
 int err_send;
 int err_recv;
 unsigned elsize;
+void (*free_func)(void *msg);
 #else
 int dummy;
 #endif
 };
 
-int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
-  unsigned nelem,
-  unsigned elsize)
+int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
+   unsigned nelem,
+   unsigned elsize,
+   void (*free_func)(void *msg))
 {
 #if HAVE_THREADS
 AVThreadMessageQueue *rmq;
@@ -73,6 +75,7 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
 return AVERROR(ret);
 }
 rmq->elsize = elsize;
+rmq->free_func = free_func;
 *mq = rmq;
 return 0;
 #else
@@ -81,10 +84,18 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
 #endif /* HAVE_THREADS */
 }
 
+int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
+  unsigned nelem,
+  unsigned elsize)
+{
+return av_thread_message_queue_alloc2(mq, nelem, elsize, NULL);
+}
+
 void av_thread_message_queue_free(AVThreadMessageQueue **mq)
 {
 #if HAVE_THREADS
 if (*mq) {
+av_thread_message_flush(*mq);
 av_fifo_freep(&(*mq)->fifo);
 pthread_cond_destroy(&(*mq)->cond);
 pthread_mutex_destroy(&(*mq)->lock);
@@ -182,3 +193,23 @@ void 
av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
 pthread_mutex_unlock(>lock);
 #endif /* HAVE_THREADS */
 }
+
+void av_thread_message_flush(AVThreadMessageQueue *mq)
+{
+#if HAVE_THREADS
+int used, off;
+
+pthread_mutex_lock(>lock);
+used = av_fifo_size(mq->fifo);
+if (mq->free_func) {
+for (off = 0; off < used; off += mq->elsize) {
+void *msg;
+av_fifo_generic_peek_at(mq->fifo, , off, mq->elsize, NULL);
+mq->free_func(msg);
+}
+}
+av_fifo_drain(mq->fifo, used);
+pthread_cond_broadcast(>cond);
+pthread_mutex_unlock(>lock);
+#endif /* HAVE_THREADS */
+}
diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
index a8481d8..f9004a8 100644
--- a/libavutil/threadmessage.h
+++ b/libavutil/threadmessage.h
@@ -33,17 +33,27 @@ typedef enum AVThreadMessageFlags {
 } AVThreadMessageFlags;
 
 /**
+ * @deprecated use av_thread_message_queue_alloc2 instead
+ */
+attribute_deprecated
+int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
+  unsigned nelem,
+  unsigned elsize);
+
+/**
  * Allocate a new message queue.
  *
  * @param mq  pointer to the message queue
  * @param nelem   maximum number of elements in the queue
  * @param elsize  size of each element in the queue
+ * @param free_func free message callback function, can be NULL
  * @return  >=0 for success; <0 for error, in particular AVERROR(ENOSYS) if
  *  lavu was built without thread support
  */
-int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
-  unsigned nelem,
-  unsigned elsize);
+int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
+   unsigned nelem,
+   unsigned elsize,
+   void (*free_func)(void *msg));
 
 /**
  * Free a message queue.
@@ -88,4 +98,9 @@ void 
av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
 void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
   int err);
 
+/**
+ * Flush the message queue
+ */
+void av_thread_message_flush(AVThreadMessageQueue *mq);
+
 #endif /* AVUTIL_THREADMESSAGE_H */
-- 
2.6.2

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

Re: [FFmpeg-devel] AAC experimental flag: the sequel

[Ganesh Ajjanagadde]

On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire  wrote:
> So, here comes the discussion again.
>
> This time, the AAC encoder is in good shape. It's not perfect. I have
> a list of known bugs to address that still has some issues, but I'm
> not really certain whether they should block the flag's removal.
>
> The bugs will be addressed in time, but maybe the encoder is in good
> enough shape as it is?

IIUC, JBK responded at VDD 2015 to the question of for which types of
files they don't use avcodec. He mentioned AAC due to some user's
complaints about quality on certain files. This was likely referring
to the decoder and not encoder. Nevertheless, I suggest a conversation
with them (or other users) to obtain problematic files to test.

If it works fine wrt users (who really are the main people affected by
removal of such "strict" flags), and the more immediate possible
concerns of Clement are met, then I am ok with this change.

Or in other words, for me removal of the flag is "stable beyond
fuzzing/security, and stable for integration by important users".

If there are known crashes, it is an immediate nack from me.

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

[FFmpeg-devel] [PATCH 3/3] avutil/threadmessage: fix condition broadcasting

[Clément Bœsch]

From: Clément Bœsch 

Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.

Scenario (real record obtained with debug added):
[...]
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: acquired lock
SENDER #1: queue is full, wait
RECEIVER: acquired lock
RECEIVER: reading a msg from the queue
RECEIVER: signal the cond
RECEIVER: acquired lock
RECEIVER: queue is empty, wait
SENDER #0: writing a msg the queue
SENDER #0: signal the cond
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: queue is full, wait

Translated:
 - initially the queue contains 1/1 message with 2 senders blocking on
   it, waiting to push another message.
 - Meanwhile the receiver is obtaining the lock, read the message,
   signal & release the lock. For some reason it is able to acquire the
   lock again before the signal wakes up one of the sender. Since it
   just emptied the queue, the reader waits for the queue to fill up
   again.
 - The signal finally reaches one of the sender, which writes a message
   and then signal the condition. Unfortunately, instead of waking up
   the reader, it actually wakes up the other worker (signal = notify
   the condition just for 1 waiter), who can't push another message in
   the queue because it's full.
 - Meanwhile, the receiver is still waiting. Deadlock.

This scenario can be triggered with for example:
tests/api/api-threadmessage-test 2 1 100 100 999

The fix is simply to make sure to notify everyone when work is done (be
it reading or writing). Another solution would be to use 2 distincts
conditions.
---
 libavutil/threadmessage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index 87ce8dc..ec62c2d 100644
--- a/libavutil/threadmessage.c
+++ b/libavutil/threadmessage.c
@@ -118,7 +118,7 @@ static int 
av_thread_message_queue_send_locked(AVThreadMessageQueue *mq,
 if (mq->err_send)
 return mq->err_send;
 av_fifo_generic_write(mq->fifo, msg, mq->elsize, NULL);
-pthread_cond_signal(>cond);
+pthread_cond_broadcast(>cond);
 return 0;
 }
 
@@ -134,7 +134,7 @@ static int 
av_thread_message_queue_recv_locked(AVThreadMessageQueue *mq,
 if (av_fifo_size(mq->fifo) < mq->elsize)
 return mq->err_recv;
 av_fifo_generic_read(mq->fifo, msg, mq->elsize, NULL);
-pthread_cond_signal(>cond);
+pthread_cond_broadcast(>cond);
 return 0;
 }
 
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[Alexander Agranovsky]

On 11/30/15 10:35 AM, Alexander Agranovsky wrote:



On 11/30/15 10:24 AM, Nicolas George wrote:

Le decadi 10 frimaire, an CCXXIV, Alexander Agranovsky a écrit :

Without getting into a religious debate

This is the reason I gave practical argument.


As pointed later in the thread, lu is used elsewhere. And yes, MS makes it
interesting in this case.

wm4 explained that point. Really, long and short should only ever be used by
libc headers to implement intXX_t.


I've pondered the change, but with
if (!av_stristart(start, "boundary=")) {
  start += 9;
'9' seems a bit random, and with

This is the reason for the third argument of av_stristart():

if (av_stristart(start, "boundary=", )) {
// no need to add 9, av_stristart() does it
}

Ah, missed that. Thanks -- attaching new iteration with this change.


Regards,



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



Hi guys -- where do we stand with this? Are there any additional comments?

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

[FFmpeg-devel] threadmessage improvements v2

[Clément Bœsch]

Improvements & changes regarding last iteration:

[PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()

- the flushing function can be set through a dedicated function instead of a
  new constructor prototype
- the flush function is now fixed regarding messages larger than a pointer...

[PATCH 2/3] fate/api: test threadmessage

- the test program is greatly improved by allowing multiple readers in addition
  to multiple senders.
- the flush now occurs randomly in readers and senders
- the messages are now larger than a pointer (see bug fix in 1/3) with a magic
  check

[PATCH 3/3] avutil/threadmessage: fix condition broadcasting

- instead of an inefficient wide signal broadcasting, it's now using 2 distinct
  conditions for reading and sending
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] threadmessage improvements v2.1

[Clément Bœsch]

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

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Wed, Dec 02, 2015 at 03:13:33PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > because concurrent read/write accesses on the fifo needs to be locked?
> 
> No, of course not.

I was talking about the fifo itself, not the threadmessage API.

> 
> > I don't understand...
> 
> *I* do not understand what you need, what you want to do with this API. To
> discard all elements, just read them until there are no more, no need of
> locking (except internally to read them, of course), no need for anything
> else. So what am I missing?

I'd say it prevents the sender (application side) to become a reader in
order to read every message concurrently with the dedicated reader(s) in
the goal of discarding them so they can't read them.

In case I'm not clear, one simple scenario would be the following:

 - there is a large queue of packets, almost filled
 - there is one fast sender filling the queue (the demuxer)
 - there is a bunch of slow readers reading from the queue (the decoders)
 - the sender "receives" a seek event from the user
 - the sender now wants to stop as fast as possible readers (decoders)
   from reading all kind of packets

If that sender has to lock for every message it's going to read & drop,
while the decoders are still fighting to read them from the queue, it
looks very ineffective to me.

Hopefully this clarifies. I'm not sure what kind of similar information I
could write in the doxy. If you have any suggestion...

I will send a new patchset very soon (with important bug fixes and
improvements)

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] AAC experimental flag: the sequel

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>   He mentioned AAC due to some user's
> complaints about quality on certain files. This was likely referring
> to the decoder and not encoder.

I remember it about the MP3 decoder compared to libmp3, not AAC.

Regards,

-- 
  Nicolas George


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/3] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Wed, Dec 02, 2015 at 05:09:23PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > What would be the difference? both av_fifo_generic_peek and
> > av_fifo_generic_peek_at require a copy of the element in a destination
> > buffer, unless I'm missing something.
> 
> As I see it, av_fifo_generic_peek() does NOT require a copy if a callback is
> supplied.
> 

Ah, indeed. av_fifo_generic_peek_at seems to have the same, I didn't
realize. Code is much simpler that way, thanks.

-- 
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] AAC experimental flag: the sequel

[Hendrik Leppkes]

On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch  wrote:
> On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote:
>> So, here comes the discussion again.
>>
>> This time, the AAC encoder is in good shape. It's not perfect. I have
>> a list of known bugs to address that still has some issues, but I'm
>> not really certain whether they should block the flag's removal.
>>
>
> What kind of bugs? If it's crashes, I think they should be fixed before
> removing the flag (for security reasons).


Maybe the other coders could just be disabled unless the experimental
flag is set, and only allow twoloop otherwise.

>
> If it's about efficiency (regarding compression or speed), I don't think
> it should be blocking the drop of the flag.
>
> Note that dropping the flag means it will be a white flag for the
> beginning of extended tests & benchmarks
>
> Regards,
>
> [...]
>
> --
> Clément B.
>
> ___
> 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 1/3] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> From: Clément Bœsch 
> 
> ---
>  libavutil/threadmessage.c | 32 
>  libavutil/threadmessage.h | 12 
>  2 files changed, 44 insertions(+)
> 
> diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
> index b7fcbe2..66b5fc6 100644
> --- a/libavutil/threadmessage.c
> +++ b/libavutil/threadmessage.c
> @@ -40,6 +40,8 @@ struct AVThreadMessageQueue {
>  int err_send;
>  int err_recv;
>  unsigned elsize;
> +void (*free_func)(void *msg);
> +void *tmp_msg;
>  #else
>  int dummy;
>  #endif
> @@ -81,10 +83,21 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue 
> **mq,
>  #endif /* HAVE_THREADS */
>  }
>  
> +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq,
> +  void (*free_func)(void *msg))
> +{
> +mq->free_func = free_func;
> +av_freep(>tmp_msg);
> +mq->tmp_msg = av_mallocz(mq->elsize);
> +return mq->tmp_msg ? 0 : AVERROR(ENOMEM);
> +}
> +
>  void av_thread_message_queue_free(AVThreadMessageQueue **mq)
>  {
>  #if HAVE_THREADS
>  if (*mq) {
> +av_thread_message_flush(*mq);
> +av_freep(&(*mq)->tmp_msg);
>  av_fifo_freep(&(*mq)->fifo);
>  pthread_cond_destroy(&(*mq)->cond);
>  pthread_mutex_destroy(&(*mq)->lock);
> @@ -182,3 +195,22 @@ void 
> av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
>  pthread_mutex_unlock(>lock);
>  #endif /* HAVE_THREADS */
>  }
> +
> +void av_thread_message_flush(AVThreadMessageQueue *mq)
> +{
> +#if HAVE_THREADS
> +int used, off;
> +
> +pthread_mutex_lock(>lock);
> +used = av_fifo_size(mq->fifo);
> +if (mq->free_func) {
> +for (off = 0; off < used; off += mq->elsize) {

> +av_fifo_generic_peek_at(mq->fifo, mq->tmp_msg, off, mq->elsize, 
> NULL);
> +mq->free_func(mq->tmp_msg);

Could this use av_fifo_generic_peek() to avoid the ugly extra allocation?

> +}
> +}
> +av_fifo_drain(mq->fifo, used);
> +pthread_cond_broadcast(>cond);
> +pthread_mutex_unlock(>lock);
> +#endif /* HAVE_THREADS */
> +}
> diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
> index a8481d8..c59cb06 100644
> --- a/libavutil/threadmessage.h
> +++ b/libavutil/threadmessage.h
> @@ -88,4 +88,16 @@ void 
> av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
>  void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
>int err);
>  
> +/**
> + * Set the optional free message callback function which will be called if an
> + * operation is removing messages from the queue.
> + */
> +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq,
> +  void (*free_func)(void *msg));
> +
> +/**

> + * Flush the message queue

I will not block for that, but I am still not satisfied with the
explanations, and therefore I find this documentation insufficient. Maybe
wait for other advice?

> + */
> +void av_thread_message_flush(AVThreadMessageQueue *mq);
> +
>  #endif /* AVUTIL_THREADMESSAGE_H */

Regards,

-- 
  Nicolas George


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/3] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> What would be the difference? both av_fifo_generic_peek and
> av_fifo_generic_peek_at require a copy of the element in a destination
> buffer, unless I'm missing something.

As I see it, av_fifo_generic_peek() does NOT require a copy if a callback is
supplied.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 2/3] fate/api: test threadmessage

[Clément Bœsch]

From: Clément Bœsch 

---
 tests/api/Makefile |   1 +
 tests/api/api-threadmessage-test.c | 202 +
 tests/fate/api.mak |   6 ++
 3 files changed, 209 insertions(+)
 create mode 100644 tests/api/api-threadmessage-test.c

diff --git a/tests/api/Makefile b/tests/api/Makefile
index c48c34a..3556a9b 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -3,6 +3,7 @@ APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
 APITESTPROGS-yes += api-seek
 APITESTPROGS-yes += api-codec-param
 APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
+APITESTPROGS-yes += api-threadmessage
 APITESTPROGS += $(APITESTPROGS-yes)
 
 APITESTOBJS  := $(APITESTOBJS:%=$(APITESTSDIR)%) 
$(APITESTPROGS:%=$(APITESTSDIR)/%-test.o)
diff --git a/tests/api/api-threadmessage-test.c 
b/tests/api/api-threadmessage-test.c
new file mode 100644
index 000..abf0154
--- /dev/null
+++ b/tests/api/api-threadmessage-test.c
@@ -0,0 +1,202 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * Thread message API test
+ */
+
+#include 
+
+#include "libavutil/frame.h"
+#include "libavutil/avstring.h"
+#include "libavutil/threadmessage.h"
+
+struct tdata {
+int id;
+pthread_t tid;
+int workload;
+AVThreadMessageQueue *queue;
+};
+
+static void free_frame(void *arg)
+{
+AVFrame *frame = arg;
+av_frame_free();
+}
+
+/* Frame producing thread. Will flush the queue half way just to be a jerk */
+static void *worker_thread(void *arg)
+{
+int i, ret;
+struct tdata *td = arg;
+
+av_log(NULL, AV_LOG_INFO, "worker #%d: workload=%d\n", td->id, 
td->workload);
+for (i = 0; i < td->workload; i++) {
+if (i == td->workload/2) {
+av_log(NULL, AV_LOG_INFO, "worker #%d: flushing the queue\n", 
td->id);
+av_thread_message_flush(td->queue);
+} else {
+char *val;
+AVDictionary *meta = NULL;
+AVFrame *frame = av_frame_alloc();
+if (!frame) {
+ret = AVERROR(ENOMEM);
+break;
+}
+
+/* we add some metadata to identify the frames */
+val = av_asprintf("frame from worker %d", td->id);
+if (!val) {
+av_frame_free();
+ret = AVERROR(ENOMEM);
+break;
+}
+ret = av_dict_set(, "sig", val, AV_DICT_DONT_STRDUP_VAL);
+if (ret < 0) {
+av_frame_free();
+break;
+}
+av_frame_set_metadata(frame, meta);
+
+/* allocate a real frame in order to simulate "real" work */
+frame->format = AV_PIX_FMT_RGBA;
+frame->width  = 320;
+frame->height = 240;
+ret = av_frame_get_buffer(frame, 32);
+if (ret < 0) {
+av_frame_free();
+break;
+}
+
+/* push the frame in the common queue */
+av_log(NULL, AV_LOG_INFO, "worker #%d: sending my work (%p), %d 
left\n",
+   td->id, frame, td->workload - i - 1);
+ret = av_thread_message_queue_send(td->queue, , 0);
+if (ret < 0) {
+av_frame_free();
+break;
+}
+}
+}
+av_log(NULL, AV_LOG_INFO, "worker #%d: my work is done here (%s)\n",
+   td->id, av_err2str(ret));
+av_thread_message_queue_set_err_recv(td->queue, ret < 0 ? ret : 
AVERROR_EOF);
+return NULL;
+}
+
+static int consume_queue(AVThreadMessageQueue *q, int n)
+{
+int i, ret = 0;
+
+for (i = 0; i < n; i++) {
+AVFrame *frame;
+AVDictionary *meta;
+AVDictionaryEntry *e;
+
+ret = av_thread_message_queue_recv(q, , 0);
+if (ret < 0)
+break;
+meta = av_frame_get_metadata(frame);
+e = av_dict_get(meta, "sig", NULL, 0);
+

[FFmpeg-devel] (no subject)

[Clément Bœsch]

GIT: [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()
GIT: [PATCH 2/3] fate/api: test threadmessage
GIT: [PATCH 3/3] avutil/threadmessage: fix condition broadcasting
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] avutil/threadmessage: fix condition broadcasting

[Clément Bœsch]

From: Clément Bœsch 

Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.

Scenario (real record obtained with debug added):
[...]
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: acquired lock
SENDER #1: queue is full, wait
RECEIVER: acquired lock
RECEIVER: reading a msg from the queue
RECEIVER: signal the cond
RECEIVER: acquired lock
RECEIVER: queue is empty, wait
SENDER #0: writing a msg the queue
SENDER #0: signal the cond
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: queue is full, wait

Translated:
 - initially the queue contains 1/1 message with 2 senders blocking on
   it, waiting to push another message.
 - Meanwhile the receiver is obtaining the lock, read the message,
   signal & release the lock. For some reason it is able to acquire the
   lock again before the signal wakes up one of the sender. Since it
   just emptied the queue, the reader waits for the queue to fill up
   again.
 - The signal finally reaches one of the sender, which writes a message
   and then signal the condition. Unfortunately, instead of waking up
   the reader, it actually wakes up the other worker (signal = notify
   the condition just for 1 waiter), who can't push another message in
   the queue because it's full.
 - Meanwhile, the receiver is still waiting. Deadlock.

This scenario can be triggered with for example:
tests/api/api-threadmessage-test 1 2 100 100 1 1000 1000

One working solution is to make av_thread_message_queue_{send,recv}()
call pthread_cond_broadcast() instead of pthread_cond_signal() so both
senders and receivers are unlocked when work is done (be it reading or
writing).

This second solution replaces the condition with two: one to notify the
senders, and one to notify the receivers. This prevents senders from
notifying other senders instead of a reader, and the other way around.
It also avoid broadcasting to everyone like the first solution, and is,
as a result in theory more optimized.
---
 libavutil/threadmessage.c | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
index 66b5fc6..783855f 100644
--- a/libavutil/threadmessage.c
+++ b/libavutil/threadmessage.c
@@ -36,7 +36,8 @@ struct AVThreadMessageQueue {
 #if HAVE_THREADS
 AVFifoBuffer *fifo;
 pthread_mutex_t lock;
-pthread_cond_t cond;
+pthread_cond_t cond_recv;
+pthread_cond_t cond_send;
 int err_send;
 int err_recv;
 unsigned elsize;
@@ -63,13 +64,20 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
 av_free(rmq);
 return AVERROR(ret);
 }
-if ((ret = pthread_cond_init(>cond, NULL))) {
+if ((ret = pthread_cond_init(>cond_recv, NULL))) {
+pthread_mutex_destroy(>lock);
+av_free(rmq);
+return AVERROR(ret);
+}
+if ((ret = pthread_cond_init(>cond_send, NULL))) {
+pthread_cond_destroy(>cond_recv);
 pthread_mutex_destroy(>lock);
 av_free(rmq);
 return AVERROR(ret);
 }
 if (!(rmq->fifo = av_fifo_alloc(elsize * nelem))) {
-pthread_cond_destroy(>cond);
+pthread_cond_destroy(>cond_send);
+pthread_cond_destroy(>cond_recv);
 pthread_mutex_destroy(>lock);
 av_free(rmq);
 return AVERROR(ret);
@@ -99,7 +107,8 @@ void av_thread_message_queue_free(AVThreadMessageQueue **mq)
 av_thread_message_flush(*mq);
 av_freep(&(*mq)->tmp_msg);
 av_fifo_freep(&(*mq)->fifo);
-pthread_cond_destroy(&(*mq)->cond);
+pthread_cond_destroy(&(*mq)->cond_send);
+pthread_cond_destroy(&(*mq)->cond_recv);
 pthread_mutex_destroy(&(*mq)->lock);
 av_freep(mq);
 }
@@ -115,12 +124,13 @@ static int 
av_thread_message_queue_send_locked(AVThreadMessageQueue *mq,
 while (!mq->err_send && av_fifo_space(mq->fifo) < mq->elsize) {
 if ((flags & AV_THREAD_MESSAGE_NONBLOCK))
 return AVERROR(EAGAIN);
-pthread_cond_wait(>cond, >lock);
+pthread_cond_wait(>cond_send, >lock);
 }
 if (mq->err_send)
 return mq->err_send;
 av_fifo_generic_write(mq->fifo, msg, mq->elsize, NULL);
-pthread_cond_signal(>cond);
+/* one message is sent, signal one receiver */
+pthread_cond_signal(>cond_recv);
 return 0;
 }
 
@@ -131,12 +141,13 @@ static int 
av_thread_message_queue_recv_locked(AVThreadMessageQueue *mq,
 while (!mq->err_recv && av_fifo_size(mq->fifo) < mq->elsize) {
 if ((flags & AV_THREAD_MESSAGE_NONBLOCK))
 return AVERROR(EAGAIN);
-pthread_cond_wait(>cond, >lock);
+pthread_cond_wait(>cond_recv, >lock);
 }
 if (av_fifo_size(mq->fifo) < mq->elsize)
 return mq->err_recv;
 av_fifo_generic_read(mq->fifo, msg, mq->elsize, NULL);
-

Re: [FFmpeg-devel] threadmessage improvements v2

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> - the flushing function can be set through a dedicated function instead of a
>   new constructor prototype

If I read the patch correctly, you seem to have fumbled your rebasing. The
deprecation is still there and the setter function is not.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] AAC experimental flag: the sequel

[Clément Bœsch]

On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote:
> So, here comes the discussion again.
> 
> This time, the AAC encoder is in good shape. It's not perfect. I have
> a list of known bugs to address that still has some issues, but I'm
> not really certain whether they should block the flag's removal.
> 

What kind of bugs? If it's crashes, I think they should be fixed before
removing the flag (for security reasons).

If it's about efficiency (regarding compression or speed), I don't think
it should be blocking the drop of the flag.

Note that dropping the flag means it will be a white flag for the
beginning of extended tests & benchmarks

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] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
>  - there is a large queue of packets, almost filled
>  - there is one fast sender filling the queue (the demuxer)
>  - there is a bunch of slow readers reading from the queue (the decoders)
>  - the sender "receives" a seek event from the user
>  - the sender now wants to stop as fast as possible readers (decoders)
>from reading all kind of packets

Ok.

> If that sender has to lock for every message it's going to read & drop,
> while the decoders are still fighting to read them from the queue, it
> looks very ineffective to me.

This, especially "looks very ineffective", sounds like premature
optimization. I am not against it, but then the documentation should tell it
is an optimization. And conversely, if it is not only a matter of efficiency
but also of correctness, the documentation must explain what the risk is.

Regards,

-- 
  Nicolas George


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 11/13] Remove the MIPS "generic" core in favor of "*"

[Vicente Olivert Riera]

Dear Andreas Cadhalpun,

On 20/11/15 20:10, Andreas Cadhalpun wrote:
> On 18.11.2015 12:13, Vicente Olivert Riera wrote:
>> There is no point to have a "generic" core when we can catch all
>> unsupported cores with the "*" option, so remove it.
>>
>> Signed-off-by: Vicente Olivert Riera 
>> ---
>> Changes v1 -> v2:
>>  - Nothing.
>>
>>  configure |4 
>>  1 files changed, 0 insertions(+), 4 deletions(-)
>>
>> diff --git a/configure b/configure
>> index fc3d559..7d87e5c 100755
>> --- a/configure
>> +++ b/configure
>> @@ -4154,10 +4154,6 @@ elif enabled mips; then
>>  ;;
>>  esac
>>  ;;
>> -generic)
>> -disable mips64r6
>> -disable msa
>> -;;
>>  *)
>>  disable mipsfpu
>>  disable mips32r2
>>
> 
> This is a bad idea.
> If the cpu is not explicitly set via configure options, it is set to generic.
> Removing this generic case here, will force-disable all mips optimizations,
> even if they were explicitly enabled with configure options.
> That would e.g. break how the Debian ffmpeg package is built for mips64el.

Aha, I see.

But I don't understand why msa is disabled for a generic cpu and not the
dsp or dspr2. Either we disable everything, or nothing. But just
disabling features randomly doesn't make any sense, at least for me.

What about this?

generic)
# We don't disable anything. Is up to the user to
# disable the unwanted features.
;;
*)
# Unknown CPU. Disable everything.
disable mipsfpu
disable mips32r2
...
;;

Regards,

Vincent.

> Best regards,
> Andreas
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[wm4]

On Wed, 2 Dec 2015 09:28:40 -0500
Alexander Agranovsky  wrote:

> Hi guys -- where do we stand with this? Are there any additional comments?
> 
> - A.

Looks fine now. The trim_right() still looks a bit awkward IMHO, but it
should be correct (whoever really cares can send a follow-up patch to
change it). I'll apply this tonight, I guess.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avcodec: include tablegen compat header before the tablegen functionality

[Michael Niedermayer]

On Wed, Dec 02, 2015 at 09:52:02AM +0100, Hendrik Leppkes wrote:
> ---
>  libavcodec/cbrt_tablegen_template.c | 2 +-
>  libavcodec/mpegaudio_tablegen.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

should be ok (ugly though that the order matters)

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] threadmessage improvements v2

[Clément Bœsch]

On Wed, Dec 02, 2015 at 04:01:40PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> > - the flushing function can be set through a dedicated function instead of a
> >   new constructor prototype
> 
> If I read the patch correctly, you seem to have fumbled your rebasing. The
> deprecation is still there and the setter function is not.

Yeah I sent the wrong patchset, see v2.1. Sorry about that. It seems git
also sent 2 empty compose message for whatever reason.

Sorry about the noise.

-- 
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] AAC experimental flag: the sequel

[Claudio Freire]

So, here comes the discussion again.

This time, the AAC encoder is in good shape. It's not perfect. I have
a list of known bugs to address that still has some issues, but I'm
not really certain whether they should block the flag's removal.

The bugs will be addressed in time, but maybe the encoder is in good
enough shape as it is?

It needs more testing. My tests have all been centered on one
configuration: AAC-LC + PNS + M/S + I/S, ABR, twoloop coder. I haven't
yet thoroughly tested any other configuration, or any other coder, and
it's possible the other coders are kaputt.

I have plans for the other coders but they haven't been fleshed out yet.

There are two possibilities here:

1. Wait until the other coders at least don't crash before removing the flag

2. Remove the flag now, and document the other coders' instability

Which one to go for depends a lot on what removing the flag means to
other people.

Does it mean "it is stable" or does it mean "it's stable for most
uses"? (a subtle but important distinction). IE: what's the contract
between us developers and users when we remove the flag? I'm rather
new at this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Wed, Dec 02, 2015 at 04:59:15PM +0100, Nicolas George wrote:
[...]
> > +av_fifo_generic_peek_at(mq->fifo, mq->tmp_msg, off, 
> > mq->elsize, NULL);
> > +mq->free_func(mq->tmp_msg);
> 
> Could this use av_fifo_generic_peek() to avoid the ugly extra allocation?
> 

What would be the difference? both av_fifo_generic_peek and
av_fifo_generic_peek_at require a copy of the element in a destination
buffer, unless I'm missing something.

> > +}
> > +}
> > +av_fifo_drain(mq->fifo, used);
> > +pthread_cond_broadcast(>cond);
> > +pthread_mutex_unlock(>lock);
> > +#endif /* HAVE_THREADS */
> > +}
> > diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
> > index a8481d8..c59cb06 100644
> > --- a/libavutil/threadmessage.h
> > +++ b/libavutil/threadmessage.h
> > @@ -88,4 +88,16 @@ void 
> > av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
> >  void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
> >int err);
> >  
> > +/**
> > + * Set the optional free message callback function which will be called if 
> > an
> > + * operation is removing messages from the queue.
> > + */
> > +int av_thread_message_queue_set_free_func(AVThreadMessageQueue *mq,
> > +  void (*free_func)(void *msg));
> > +
> > +/**
> 
> > + * Flush the message queue
> 
> I will not block for that, but I am still not satisfied with the
> explanations, and therefore I find this documentation insufficient. Maybe
> wait for other advice?
> 

Sure, no problem.

-- 
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 v2 11/13] Remove the MIPS "generic" core in favor of "*"

[Andreas Cadhalpun]

On 02.12.2015 15:54, Vicente Olivert Riera wrote:
> On 20/11/15 20:10, Andreas Cadhalpun wrote:
>> If the cpu is not explicitly set via configure options, it is set to generic.
>> Removing this generic case here, will force-disable all mips optimizations,
>> even if they were explicitly enabled with configure options.
>> That would e.g. break how the Debian ffmpeg package is built for mips64el.
> 
> Aha, I see.
> 
> But I don't understand why msa is disabled for a generic cpu and not the
> dsp or dspr2.

That was added in commit 8af3ce5, with the following comment:
"MIPS 'generic' case is added, with mips32r2 arch as default (fpu and dsp opt 
enabled)."

I'm not sure why this combination was chosen for the generic case.

> Either we disable everything, or nothing. But just
> disabling features randomly doesn't make any sense, at least for me.
> 
> What about this?
> 
> generic)
>   # We don't disable anything. Is up to the user to
>   # disable the unwanted features.
> ;;

That would be fine with me.

> *)
>   # Unknown CPU. Disable everything.

I think it would be good if configure printed a warning in this case.

>   disable mipsfpu
>   disable mips32r2
>   ...
> ;;

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] Makefile: add cleanup of pkg-config files created by configure to distclean

[Andreas Cadhalpun]

On 25.11.2015 11:56, Tobias Rapp wrote:
> Subject: [PATCH] Makefile: add cleanup of pkg-config files created by
>  configure to distclean
> 
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Makefile b/Makefile
> index 306f060..58f1a3a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -181,6 +181,7 @@ clean::
>  distclean::
>   $(RM) $(DISTCLEANSUFFIXES)
>   $(RM) config.* .config libavutil/avconfig.h .version avversion.h 
> version.h libavutil/ffversion.h libavcodec/codec_names.h
> + $(RM) -rf doc/examples/pc-uninstalled
>  
>  config:
>   $(SRC_PATH)/configure $(value FFMPEG_CONFIGURATION)
> -- 1.9.1

This looks good to me, so applied and pushed.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] lavfi: deprecate avfilter_link_set_closed().

[Andreas Cadhalpun]

On 29.11.2015 17:21, Nicolas George wrote:
> Applications are not supposed to mess with links,
> they should close the sinks.
> Furthermore, this function does not distinguish what end
> of the link caused the close and does not have a timestamp.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/avfilter.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index a6aa919..58a0cbd 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -541,7 +541,10 @@ int avfilter_link_get_channels(AVFilterLink *link);
>  
>  /**
>   * Set the closed field of a link.
> + * @deprecated applications are not supposed to mess with links, they should
> + * close the sinks.
>   */
> +attribute_deprecated
>  void avfilter_link_set_closed(AVFilterLink *link, int closed);
>  
>  /**
> 

It would be nice to mention this deprecation in APIchanges.
Other than that, this deprecation should be fine, as there seem to be no users
of this function.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.

[Aaron Colwell]

On Wed, Dec 2, 2015 at 2:16 AM wm4  wrote:

> On Wed, 02 Dec 2015 00:32:46 +
> Aaron Colwell  wrote:
>
> > On Mon, Nov 30, 2015 at 4:35 PM wm4  wrote:
> >
> > >
> > > I tried your patch, and it actually makes it work better (looks correct
> > > with the patch). The patch itself also LGTM.
> > >
> > >
> > Ok. Great. Thanks for the review. What do I need to do next to get this
> > checked in. I don't have commit access.
>
> Well, first it has to be determined whether the patch is accepted, and
> then someone has to push it. I just did the latter.
>
> Before pushing, I slightly modified the subject line to add a prefix
> and to make it somewhat shorter (as the prefix made it too long). I
> hope this is ok.
>

Yes. That is fine. Thank you again for your help. I appreciate it.

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

Re: [FFmpeg-devel] [PATCH] web/download: remove architecture lists

[Andreas Cadhalpun]

On 25.11.2015 02:30, Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 12:35:03AM +0100, Andreas Cadhalpun wrote:
>> They are not very helpful and feel out-of-place.
>>
>> Suggested-by: Timothy Gu 
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  src/download | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> LGTM.

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] AAC experimental flag: the sequel

[Claudio Freire]

On Wed, Dec 2, 2015 at 12:50 PM, Hendrik Leppkes  wrote:
> On Wed, Dec 2, 2015 at 4:42 PM, Clément Bœsch  wrote:
>> On Wed, Dec 02, 2015 at 12:37:00PM -0300, Claudio Freire wrote:
>>> So, here comes the discussion again.
>>>
>>> This time, the AAC encoder is in good shape. It's not perfect. I have
>>> a list of known bugs to address that still has some issues, but I'm
>>> not really certain whether they should block the flag's removal.
>>>
>>
>> What kind of bugs? If it's crashes, I think they should be fixed before
>> removing the flag (for security reasons).
>
>
> Maybe the other coders could just be disabled unless the experimental
> flag is set, and only allow twoloop otherwise.

That's not a bad idea in fact.

But yeah, the issue is that they might crash. I don't know, because
they haven't been tested enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Incorrect FourCC for HE-AAC in ISMV manifest

[Yann Coupin]

Hi,

According to Microsoft's specs [1] (and after experiencing issues with the
Unified Streaming Platform [2] server), content encoded with HE-AAC audio
should use the AACH FourCC, but the value AACL is hardcoded in the manifest
generation code. So I created the attached patch to fix this. It passes
"test fate" and its effects can be seen using the commands bellow and
compatible server.

Although I tried to follow the patch submission checklist don't hesitate to
point errors or mistakes.

Yann


Sample command lines:

ffmpeg -i video.mp4 -vn -acodec libfdk_aac -profile:a aac_low -ab 128k -ar
44.1k -movflags isml -f ismv http://example.com/

FourCC of audio track in manifest is AACL as before

ffmpeg -i video.mp4 -vn -acodec libfdk_aac -profile:a aac_he -ab 64k -ar
44.1k -movflags isml -f ismv http://example.com/

FourCC is AACH

ffmpeg -i video.mp4 -vn -acodec libfdk_aac -profile:a aac_he_v2 -ab 64k -ar
44.1k -movflags isml -f ismv http://example.com/

FourCC is AACP

[1] https://msdn.microsoft.com/en-us/library/ff728116%28v=vs.95%29.aspx
[2] http://www.unified-streaming.com/


0001-HE-AAC-correct-FourCC-in-ISML.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AAC experimental flag: the sequel

[Paul B Mahol]

Dana 2. 12. 2015. 16:54 osoba "Nicolas George"  napisala
je:
>
> Le duodi 12 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> >   He mentioned AAC due to some user's
> > complaints about quality on certain files. This was likely referring
> > to the decoder and not encoder.
>
> I remember it about the MP3 decoder compared to libmp3, not AAC.
>

It it on range of golden cables.

> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] mjpegdec: consider chroma subsampling in size check

[Andreas Cadhalpun]

If the chroma components are subsampled, smaller buffers are allocated
for them. In that case the maximal block_offset for the chroma
components is not as large as for the luma component.

This fixes out of bounds writes causing segmentation faults or memory
corruption.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/mjpegdec.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index cfc59ac..303b990 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1246,7 +1246,7 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int 
nb_components, int Ah,
  int mb_bitmask_size,
  const AVFrame *reference)
 {
-int i, mb_x, mb_y;
+int i, mb_x, mb_y, chroma_h_shift, chroma_v_shift;
 uint8_t *data[MAX_COMPONENTS];
 const uint8_t *reference_data[MAX_COMPONENTS];
 int linesize[MAX_COMPONENTS];
@@ -1271,6 +1271,9 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int 
nb_components, int Ah,
 s->coefs_finished[c] |= 1;
 }
 
+av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt, _h_shift,
+ _v_shift);
+
 for (mb_y = 0; mb_y < s->mb_height; mb_y++) {
 for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
 const int copy_mb = mb_bitmask && !get_bits1(_bitmask_gb);
@@ -1285,7 +1288,7 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int 
nb_components, int Ah,
 }
 for (i = 0; i < nb_components; i++) {
 uint8_t *ptr;
-int n, h, v, x, y, c, j;
+int n, h, v, x, y, c, j, h_shift, v_shift;
 int block_offset;
 n = s->nb_blocks[i];
 c = s->comp_index[i];
@@ -1293,14 +1296,16 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int 
nb_components, int Ah,
 v = s->v_scount[i];
 x = 0;
 y = 0;
+h_shift = c ? chroma_h_shift: 0;
+v_shift = c ? chroma_v_shift: 0;
 for (j = 0; j < n; j++) {
 block_offset = (((linesize[c] * (v * mb_y + y) * 8) +
  (h * mb_x + x) * 8 * bytes_per_pixel) >> 
s->avctx->lowres);
 
 if (s->interlaced && s->bottom_field)
 block_offset += linesize[c] >> 1;
-if (   8*(h * mb_x + x) < s->width
-&& 8*(v * mb_y + y) < s->height) {
+if (   8*(h * mb_x + x) < (s->width  + (1 << h_shift) - 1) 
>> h_shift
+&& 8*(v * mb_y + y) < (s->height + (1 << v_shift) - 1) 
>> v_shift) {
 ptr = data[c] + block_offset;
 } else
 ptr = NULL;
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] git-howto: mention how to clone ffmpeg-web

[Andreas Cadhalpun]

On 25.11.2015 01:26, Andreas Cadhalpun wrote:
> Subject: [PATCH] git-howto: mention how to clone ffmpeg-web
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  doc/git-howto.texi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/doc/git-howto.texi b/doc/git-howto.texi
> index bf37bcc..e5e3c81 100644
> --- a/doc/git-howto.texi
> +++ b/doc/git-howto.texi
> @@ -65,6 +65,21 @@ git clone git@@source.ffmpeg.org:ffmpeg 
>  This will put the FFmpeg sources into the directory @var{} and let
>  you push back your changes to the remote repository.
>  
> +@example
> +git clone gil@@ffmpeg.org:ffmpeg-web 
> +@end example
> +
> +This will put the source of the FFmpeg website into the directory
> +@var{} and let you push back your changes to the remote repository.
> +(Note that @var{gil} stands for GItoLite and is not a typo of @var{git}.)
> +
> +If you don't have write-access to the ffmpeg-web repository, you can
> +create patches after making a read-only ffmpeg-web clone:
> +
> +@example
> +git clone git://ffmpeg.org/ffmpeg-web 
> +@end example
> +
>  Make sure that you do not have Windows line endings in your checkouts,
>  otherwise you may experience spurious compilation failures. One way to
>  achieve this is to run

I pushed this version now.
Feel free to improve it further.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/3] common.mak: Use CCFLAGS for assembly generation as well

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 09:46:04PM -0800, Timothy Gu wrote:
> CCFLAGS is equivalent to CPPFLAGS + CFLAGS.
> ---
>  common.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

does this fix any case or just simplifies common.mak ?

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- 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] aacenc: remove experimental flag

[Claudio Freire]

On Wed, Dec 2, 2015 at 4:14 PM, Rostislav Pehlivanov
 wrote:
> This commit removes the experimental flag from the native AAC Encoder
> and thus makes it the default.
>
> After a lot of work, done by myself and Claudio Freire, the quality of
> this encoder rivals and surpasses libfdk_aac in some situations. The
> encoder had instability issues earlier which prevented it from having
> its experimental flag removed, however the last commit done by Claudio
> removed the last known source of instability and solved a lot of
> problems which were previously observed. The issues were caused by the
> various coding tools interfering with the scalefactor indices. Thus,
> with these problems solved, it should now be possible to declare this
> encoder as the default and recommend that the users should use it
> instead of others provided by external libraries, as it is both faster
> and has a subjectively higher quality with selected tracks.
> The encoder has still yet to be fine tuned for every possible audio file
> type like music or voice, so it is hoped that with the experimental flag
> removed the users should be able to provide feedback and make the
> encoder better than the alternatives for every type of audio.
>
> The documentation will be edited and commited with a later commit.


Did you check the discussion about this?

http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184393.html

There Hendrik Leppkes had a good idea to shield us from possible
instability in the nondefault coders (anmr, fast, etc).

It would be desirable to implement it with this commit (unless you did
the testing/fuzzing of those coders of course).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] sbr_qmf_analysis: sanitize input for 32-bit imdct

[Andreas Cadhalpun]

On 19.11.2015 01:02, Andreas Cadhalpun wrote:
> If the input contains too many too large values, the imdct can overflow.
> Even if it didn't, the output would be larger than the valid range of 29
> bits.
> 
> Note that this is a very delicate limit: Allowing values up to 1<<25
> does not prevent input larger than 1<<29 from arriving at
> sbr_sum_square, while limiting values to 1<<23 breaks the
> fate-aac-fixed-al_sbr_hq_cm_48_5.1 test.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
> 
> Nedeljko, do you have an explanation why larger input values here
> are invalid?
> 
> By the way, the imdct calculations in imdct_and_windowing and
> sbr_qmf_synthesis can also overflow, so maybe need a similar check.
> 
> ---
>  libavcodec/aacsbr_template.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
> index 66f4159..f48ddd0 100644
> --- a/libavcodec/aacsbr_template.c
> +++ b/libavcodec/aacsbr_template.c
> @@ -1153,6 +1153,9 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, 
> FFTContext *mdct,
>   INTFLOAT z[320], INTFLOAT W[2][32][32][2], int 
> buf_idx)
>  {
>  int i;
> +#if USE_FIXED
> +int j;
> +#endif
>  memcpy(x, x+1024, (320-32)*sizeof(x[0]));
>  memcpy(x+288, in, 1024*sizeof(x[0]));
>  for (i = 0; i < 32; i++) { // numTimeSlots*RATE = 16*2 as 960 sample 
> frames
> @@ -1160,6 +1163,21 @@ static void sbr_qmf_analysis(AVFloatDSPContext *dsp, 
> FFTContext *mdct,
>  dsp->vector_fmul_reverse(z, sbr_qmf_window_ds, x, 320);
>  sbrdsp->sum64x5(z);
>  sbrdsp->qmf_pre_shuffle(z);
> +#if USE_FIXED
> +for (j = 64; j < 128; j++) {
> +if (z[j] > 1<<24) {
> +av_log(NULL, AV_LOG_WARNING,
> +   "sbr_qmf_analysis: value %09d too large, setting to 
> %09d\n",
> +   z[j], 1<<24);
> +z[j] = 1<<24;
> +} else if (z[j] < -(1<<24)) {
> +av_log(NULL, AV_LOG_WARNING,
> +   "sbr_qmf_analysis: value %09d too small, setting to 
> %09d\n",
> +   z[j], -(1<<24));
> +z[j] = -(1<<24);
> +}
> +}
> +#endif
>  mdct->imdct_half(mdct, z, z+64);
>  sbrdsp->qmf_post_shuffle(W[buf_idx][i], z);
>  x += 32;
> 

Ping.

If nobody objects, I'll push this soon, as it fixes crashes.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aac_fixed: fix overflow in sbr_sum_square_c

[Andreas Cadhalpun]

On 19.11.2015 01:01, Andreas Cadhalpun wrote:
> Subject: [PATCH] sbrdsp_fixed: assert that input values for sbr_sum_square_c
>  are valid
> 
> Larger values can cause overflows, leading to this function returning a
> negative value.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/sbrdsp_fixed.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/sbrdsp_fixed.c b/libavcodec/sbrdsp_fixed.c
> index 5b7b7a6..f4e3de0 100644
> --- a/libavcodec/sbrdsp_fixed.c
> +++ b/libavcodec/sbrdsp_fixed.c
> @@ -38,9 +38,14 @@ static SoftFloat sbr_sum_square_c(int (*x)[2], int n)
>  int i, nz, round;
>  
>  for (i = 0; i < n; i += 2) {
> +// Larger values are inavlid and could cause overflows of accu.
> +av_assert2(FFABS(x[i + 0][0]) >> 29 == 0);
>  accu += (int64_t)x[i + 0][0] * x[i + 0][0];
> +av_assert2(FFABS(x[i + 0][1]) >> 29 == 0);
>  accu += (int64_t)x[i + 0][1] * x[i + 0][1];
> +av_assert2(FFABS(x[i + 1][0]) >> 29 == 0);
>  accu += (int64_t)x[i + 1][0] * x[i + 1][0];
> +av_assert2(FFABS(x[i + 1][1]) >> 29 == 0);
>  accu += (int64_t)x[i + 1][1] * x[i + 1][1];
>  }
>  

Ping.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.

[Ronald S. Bultje]

Hi,

On Tue, Dec 1, 2015 at 1:21 PM, Ronald S. Bultje  wrote:

> Hi,
>
> On Tue, Dec 1, 2015 at 12:34 PM, Hendrik Leppkes 
> wrote:
>
>> On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje 
>> wrote:
>> > Fixes mozilla bug 1229128.
>> > ---
>> >  libavcodec/vp9.c | 43 ++-
>> >  1 file changed, 22 insertions(+), 21 deletions(-)
>> >
>> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
>> > index d4061e2..dc0 100644
>> > --- a/libavcodec/vp9.c
>> > +++ b/libavcodec/vp9.c
>> > @@ -69,6 +69,7 @@ typedef struct VP9Context {
>> >  uint8_t ss_h, ss_v;
>> >  uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
>> >  uint8_t last_keyframe;
>> > +enum AVPixelFormat pix_fmt, last_fmt;
>> >  ThreadFrame next_refs[8];
>> >
>> >  struct {
>> > @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx,
>> VP9Frame *dst, VP9Frame *src)
>> >  return 0;
>> >  }
>> >
>> > -static int update_size(AVCodecContext *ctx, int w, int h, enum
>> AVPixelFormat fmt)
>> > +static int update_size(AVCodecContext *ctx, int w, int h)
>> >  {
>> >  VP9Context *s = ctx->priv_data;
>> >  uint8_t *p;
>> > @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int
>> w, int h, enum AVPixelFormat fmt
>> >
>> >  av_assert0(w > 0 && h > 0);
>> >
>> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height
>> && ctx->pix_fmt == fmt)
>> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height
>> && s->pix_fmt == s->last_fmt)
>> >  return 0;
>> >
>> >  if ((res = ff_set_dimensions(ctx, w, h)) < 0)
>> >  return res;
>> > -ctx->pix_fmt = fmt;
>> > +s->last_fmt  = ctx->pix_fmt = s->pix_fmt;
>> >  s->sb_cols   = (w + 63) >> 6;
>> >  s->sb_rows   = (h + 63) >> 6;
>> >  s->cols  = (w + 7) >> 3;
>> > @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
>> >  255 - inv_recenter_nonneg(inv_map_table[d], 255 -
>> p);
>> >  }
>> >
>> > -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
>> > +static int read_colorspace_details(AVCodecContext *ctx)
>> >  {
>> >  static const enum AVColorSpace colorspaces[8] = {
>> >  AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
>> AVCOL_SPC_SMPTE170M,
>> >  AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
>> AVCOL_SPC_RGB,
>> >  };
>> >  VP9Context *s = ctx->priv_data;
>> > -enum AVPixelFormat res;
>> >  int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(>gb); // 0:8,
>> 1:10, 2:12
>> >
>> >  s->bpp_index = bits;
>> > @@ -401,10 +401,10 @@ static enum AVPixelFormat
>> read_colorspace_details(AVCodecContext *ctx)
>> >  static const enum AVPixelFormat pix_fmt_rgb[3] = {
>> >  AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
>> >  };
>> > +s->ss_h = s->ss_v = 0;
>> > +ctx->color_range = AVCOL_RANGE_JPEG;
>> > +s->pix_fmt = pix_fmt_rgb[bits];
>> >  if (ctx->profile & 1) {
>> > -s->ss_h = s->ss_v = 0;
>> > -res = pix_fmt_rgb[bits];
>> > -ctx->color_range = AVCOL_RANGE_JPEG;
>> >  if (get_bits1(>gb)) {
>> >  av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
>> >  return AVERROR_INVALIDDATA;
>> > @@ -427,7 +427,8 @@ static enum AVPixelFormat
>> read_colorspace_details(AVCodecContext *ctx)
>> >  if (ctx->profile & 1) {
>> >  s->ss_h = get_bits1(>gb);
>> >  s->ss_v = get_bits1(>gb);
>> > -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
>> AV_PIX_FMT_YUV420P) {
>> > +s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
>> > +if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
>> >  av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
>> profile %d\n",
>> > ctx->profile);
>> >  return AVERROR_INVALIDDATA;
>> > @@ -438,11 +439,11 @@ static enum AVPixelFormat
>> read_colorspace_details(AVCodecContext *ctx)
>> >  }
>> >  } else {
>> >  s->ss_h = s->ss_v = 1;
>> > -res = pix_fmt_for_ss[bits][1][1];
>> > +s->pix_fmt = pix_fmt_for_ss[bits][1][1];
>> >  }
>> >  }
>> >
>> > -return res;
>> > +return 0;
>> >  }
>> >
>> >  static int decode_frame_header(AVCodecContext *ctx,
>> > @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
>> >  {
>> >  VP9Context *s = ctx->priv_data;
>> >  int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
>> > -enum AVPixelFormat fmt = ctx->pix_fmt;
>> >  int last_invisible;
>> >  const uint8_t *data2;
>> >
>> > @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
>> >  av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
>> >  return 

Re: [FFmpeg-devel] [PATCH 1/2] avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 01:50:13PM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Fixes integer overflow
> Fixes: mozilla bug 1229167
> 
> Found-by: Tyson Smith
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/mathematics.c |   13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)

patchset applied

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

[FFmpeg-devel] [PATCH] aacenc: remove experimental flag

[Rostislav Pehlivanov]

This commit removes the experimental flag from the native AAC Encoder
and thus makes it the default.

After a lot of work, done by myself and Claudio Freire, the quality of
this encoder rivals and surpasses libfdk_aac in some situations. The
encoder had instability issues earlier which prevented it from having
its experimental flag removed, however the last commit done by Claudio
removed the last known source of instability and solved a lot of
problems which were previously observed. The issues were caused by the
various coding tools interfering with the scalefactor indices. Thus,
with these problems solved, it should now be possible to declare this
encoder as the default and recommend that the users should use it
instead of others provided by external libraries, as it is both faster
and has a subjectively higher quality with selected tracks.
The encoder has still yet to be fine tuned for every possible audio file
type like music or voice, so it is hoped that with the experimental flag
removed the users should be able to provide feedback and make the
encoder better than the alternatives for every type of audio.

The documentation will be edited and commited with a later commit.
---
 libavcodec/aacenc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 971f8ab..2473a14 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -1039,8 +1039,7 @@ AVCodec ff_aac_encoder = {
 .close  = aac_encode_end,
 .supported_samplerates = mpeg4audio_sample_rates,
 .caps_internal  = FF_CODEC_CAP_INIT_THREADSAFE,
-.capabilities   = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY |
-  AV_CODEC_CAP_EXPERIMENTAL,
+.capabilities   = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY,
 .sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_FLTP,
  AV_SAMPLE_FMT_NONE },
 .priv_class = _class,
-- 
2.6.2

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

[FFmpeg-devel] [PATCH] aacenc: mark coders other than twoloop as experimental

[Rostislav Pehlivanov]

This commit marks any coders beside twoloop as experimental and gives
out a warning that some of they might be silently removed in the future.

Users are highly encouraged to use the twoloop coder, which is the
default.
---
 libavcodec/aacenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 971f8ab..7a34806 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -967,6 +967,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
 s->coder = _aac_coders[s->options.coder];
 
 if (s->options.coder != AAC_CODER_TWOLOOP) {
+ERROR_IF(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL,
+ "Coders other than twoloop require -strict -2 and some may be 
removed in the future\n");
 s->options.intensity_stereo = 0;
 s->options.pns = 0;
 }
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH 2/3] aacsbr: ensure strictly monotone time borders

[Andreas Cadhalpun]

On 08.11.2015 22:04, Andreas Cadhalpun wrote:
> This fixes a SIGFPE crash in the aac_fixed decoder.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/aacsbr_template.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
> index 66f4159..f69d2f8 100644
> --- a/libavcodec/aacsbr_template.c
> +++ b/libavcodec/aacsbr_template.c
> @@ -718,8 +718,8 @@ static int read_sbr_grid(AACContext *ac, 
> SpectralBandReplication *sbr,
>  }
>  
>  for (i = 1; i <= ch_data->bs_num_env; i++) {
> -if (ch_data->t_env[i-1] > ch_data->t_env[i]) {
> -av_log(ac->avctx, AV_LOG_ERROR, "Non monotone time borders\n");
> +if (ch_data->t_env[i-1] >= ch_data->t_env[i]) {
> +av_log(ac->avctx, AV_LOG_ERROR, "Not strictly monotone time 
> borders\n");
>  return -1;
>  }
>  }
> 

Ping.

Unless there are objections, I'll push this soon, as it fixes crashes.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

[wm4]

On Wed, 2 Dec 2015 02:23:15 +0100
Michael Niedermayer  wrote:

> On Tue, Dec 01, 2015 at 10:47:53AM -0800, Chris Cunningham wrote:
> > Thanks wm4, next patch will fix that declaration.
> > 
> > Michael, any concerns?  
> 
> iam fine with the patch
> 
> 
> >
> > On Mon, Nov 30, 2015 at 2:51 PM, wm4  wrote:  
> [...]
> > > Other than that LGTM.  
> 
> wm4, your replies are missing from the mailing list

Must be my mail client again, which replied to the CC instead of the ML.

> (and i dont know what "Other" was meant for so dunno if i should apply
>  or wait)
> 
> [...]

There was a declaration after statement. I guess I can fix as I push,
later.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavutil/tablegen: add missing math.h include

[Paul B Mahol]

On 12/2/15, Hendrik Leppkes  wrote:
> ---
>  libavutil/tablegen.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
> index f81b46b..02acdd6 100644
> --- a/libavutil/tablegen.h
> +++ b/libavutil/tablegen.h
> @@ -24,6 +24,8 @@
>  #ifndef AVUTIL_TABLEGEN_H
>  #define AVUTIL_TABLEGEN_H
>
> +#include 
> +
>  // we lack some functions on all host platforms, and we don't care about
>  // performance and/or strict ISO C semantics as it's performed at build
> time
>  static inline double ff_cbrt(double x)
> --
> 2.6.2.windows.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] [PATCH 1/3] libavutil/tablegen: add missing math.h include

[Hendrik Leppkes]

---
 libavutil/tablegen.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/tablegen.h b/libavutil/tablegen.h
index f81b46b..02acdd6 100644
--- a/libavutil/tablegen.h
+++ b/libavutil/tablegen.h
@@ -24,6 +24,8 @@
 #ifndef AVUTIL_TABLEGEN_H
 #define AVUTIL_TABLEGEN_H
 
+#include 
+
 // we lack some functions on all host platforms, and we don't care about
 // performance and/or strict ISO C semantics as it's performed at build time
 static inline double ff_cbrt(double x)
-- 
2.6.2.windows.1

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

[FFmpeg-devel] [PATCH 2/3] avcodec: include tablegen compat header before the tablegen functionality

[Hendrik Leppkes]

---
 libavcodec/cbrt_tablegen_template.c | 2 +-
 libavcodec/mpegaudio_tablegen.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cbrt_tablegen_template.c 
b/libavcodec/cbrt_tablegen_template.c
index 1d71d34..7dcab91 100644
--- a/libavcodec/cbrt_tablegen_template.c
+++ b/libavcodec/cbrt_tablegen_template.c
@@ -22,8 +22,8 @@
 
 #include 
 #define CONFIG_HARDCODED_TABLES 0
-#include "cbrt_tablegen.h"
 #include "libavutil/tablegen.h"
+#include "cbrt_tablegen.h"
 #include "tableprint.h"
 
 int main(void)
diff --git a/libavcodec/mpegaudio_tablegen.c b/libavcodec/mpegaudio_tablegen.c
index 9a9bb4d..ede7c8e 100644
--- a/libavcodec/mpegaudio_tablegen.c
+++ b/libavcodec/mpegaudio_tablegen.c
@@ -22,8 +22,8 @@
 
 #include 
 #define CONFIG_HARDCODED_TABLES 0
-#include "mpegaudio_tablegen.h"
 #include "libavutil/tablegen.h"
+#include "mpegaudio_tablegen.h"
 #include "tableprint.h"
 
 int main(void)
-- 
2.6.2.windows.1

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

[FFmpeg-devel] [PATCH 3/3] libavcodec/aacsbr_tablegen: fix tablegen on windows

[Hendrik Leppkes]

Including these headers is not needed and breaks building on Windows as it
tries to activate the full compat tools, which are not needed for host
tools.
---
 libavcodec/aacsbr_fixed_tablegen.c  | 3 ---
 libavcodec/aacsbr_tablegen.c| 3 ---
 libavcodec/aacsbr_tablegen_common.h | 3 ++-
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavcodec/aacsbr_fixed_tablegen.c 
b/libavcodec/aacsbr_fixed_tablegen.c
index b896d75..832fcb7 100644
--- a/libavcodec/aacsbr_fixed_tablegen.c
+++ b/libavcodec/aacsbr_fixed_tablegen.c
@@ -21,9 +21,6 @@
  */
 
 #include 
-#include "libavutil/internal.h"
-#include "libavutil/common.h"
-#undef CONFIG_HARDCODED_TABLES
 #define CONFIG_HARDCODED_TABLES 0
 #define USE_FIXED 1
 #include "aacsbr_fixed_tablegen.h"
diff --git a/libavcodec/aacsbr_tablegen.c b/libavcodec/aacsbr_tablegen.c
index ee0d818..c331c57 100644
--- a/libavcodec/aacsbr_tablegen.c
+++ b/libavcodec/aacsbr_tablegen.c
@@ -21,9 +21,6 @@
  */
 
 #include 
-#include "libavutil/internal.h"
-#include "libavutil/common.h"
-#undef CONFIG_HARDCODED_TABLES
 #define CONFIG_HARDCODED_TABLES 0
 #define USE_FIXED 0
 #include "aacsbr_tablegen.h"
diff --git a/libavcodec/aacsbr_tablegen_common.h 
b/libavcodec/aacsbr_tablegen_common.h
index 0a64552..d7fc306 100644
--- a/libavcodec/aacsbr_tablegen_common.h
+++ b/libavcodec/aacsbr_tablegen_common.h
@@ -22,7 +22,8 @@
 
 #ifndef AVCODEC_AACSBR_TABLEGEN_COMMON_H
 #define AVCODEC_AACSBR_TABLEGEN_COMMON_H
-#include "aac.h"
+#include "aac_defines.h"
+#include "libavutil/mem.h"
 
 #if CONFIG_HARDCODED_TABLES
 #define aacsbr_tableinit()
-- 
2.6.2.windows.1

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

[FFmpeg-devel] [PATCH 2/2] ffmdec: reject zero-sized chunks

[Andreas Cadhalpun]

If size is zero, avio_get_str fails, leaving the buffer uninitialized.
This causes invalid reads in av_set_options_string.

Signed-off-by: Andreas Cadhalpun 
---
 libavformat/ffmdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
index 9ad771e..afba905 100644
--- a/libavformat/ffmdec.c
+++ b/libavformat/ffmdec.c
@@ -423,7 +423,7 @@ static int ffm2_read_header(AVFormatContext *s)
 }
 break;
 case MKBETAG('S', '2', 'V', 'I'):
-if (f_stvi++) {
+if (f_stvi++ || !size) {
 ret = AVERROR(EINVAL);
 goto fail;
 }
@@ -438,7 +438,7 @@ static int ffm2_read_header(AVFormatContext *s)
 goto fail;
 break;
 case MKBETAG('S', '2', 'A', 'U'):
-if (f_stau++) {
+if (f_stau++ || !size) {
 ret = AVERROR(EINVAL);
 goto fail;
 }
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacenc: mark coders other than twoloop as experimental

[Claudio Freire]

On Wed, Dec 2, 2015 at 4:47 PM, Rostislav Pehlivanov
 wrote:
> This commit marks any coders beside twoloop as experimental and gives
> out a warning that some of they might be silently removed in the future.
>
> Users are highly encouraged to use the twoloop coder, which is the
> default.
> ---
>  libavcodec/aacenc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index 971f8ab..7a34806 100644
> --- a/libavcodec/aacenc.c
> +++ b/libavcodec/aacenc.c
> @@ -967,6 +967,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
>  s->coder = _aac_coders[s->options.coder];
>
>  if (s->options.coder != AAC_CODER_TWOLOOP) {
> +ERROR_IF(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL,
> + "Coders other than twoloop require -strict -2 and some may 
> be removed in the future\n");
>  s->options.intensity_stereo = 0;
>  s->options.pns = 0;
>  }


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

Re: [FFmpeg-devel] [PATCH] Allow mpjpeg demuxer to process MIME parts which do not include Content-Length header.

[wm4]

On Wed, 2 Dec 2015 09:28:40 -0500
Alexander Agranovsky  wrote:


> Hi guys -- where do we stand with this? Are there any additional comments?
> 
> - A.

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

[FFmpeg-devel] [PATCH 1/2] ffmdec: only seek back at EOF if a server is attached

[Andreas Cadhalpun]

Otherwise the ffm demuxer can return the same packets endlessly, if
there is no server attached.
---

I haven't tested ffserver, but since it sets server_attached, it
should still work as previously.

---
 libavformat/ffmdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/ffmdec.c b/libavformat/ffmdec.c
index e7c1449..9ad771e 100644
--- a/libavformat/ffmdec.c
+++ b/libavformat/ffmdec.c
@@ -100,7 +100,10 @@ static int ffm_read_data(AVFormatContext *s,
 len = size;
 if (len == 0) {
 if (avio_tell(pb) == ffm->file_size)
-avio_seek(pb, ffm->packet_size, SEEK_SET);
+if (ffm->server_attached)
+avio_seek(pb, ffm->packet_size, SEEK_SET);
+else
+return AVERROR_EOF;
 retry_read:
 if (pb->buffer_size != ffm->packet_size) {
 int64_t tell = avio_tell(pb);
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacenc: mark coders other than twoloop as experimental

[Hendrik Leppkes]

On Wed, Dec 2, 2015 at 10:04 PM, Claudio Freire  wrote:
> On Wed, Dec 2, 2015 at 4:47 PM, Rostislav Pehlivanov
>  wrote:
>> This commit marks any coders beside twoloop as experimental and gives
>> out a warning that some of they might be silently removed in the future.
>>
>> Users are highly encouraged to use the twoloop coder, which is the
>> default.
>> ---
>>  libavcodec/aacenc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
>> index 971f8ab..7a34806 100644
>> --- a/libavcodec/aacenc.c
>> +++ b/libavcodec/aacenc.c
>> @@ -967,6 +967,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
>>  s->coder = _aac_coders[s->options.coder];
>>
>>  if (s->options.coder != AAC_CODER_TWOLOOP) {
>> +ERROR_IF(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL,
>> + "Coders other than twoloop require -strict -2 and some may 
>> be removed in the future\n");
>>  s->options.intensity_stereo = 0;
>>  s->options.pns = 0;
>>  }
>
>
> LGTM

Sounds good to me, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AAC experimental flag: the sequel

[Claudio Freire]

On Wed, Dec 2, 2015 at 12:51 PM, Ganesh Ajjanagadde  wrote:
> On Wed, Dec 2, 2015 at 10:37 AM, Claudio Freire  
> wrote:
>> So, here comes the discussion again.
>>
>> This time, the AAC encoder is in good shape. It's not perfect. I have
>> a list of known bugs to address that still has some issues, but I'm
>> not really certain whether they should block the flag's removal.
>>
>> The bugs will be addressed in time, but maybe the encoder is in good
>> enough shape as it is?
>
> IIUC, JBK responded at VDD 2015 to the question of for which types of
> files they don't use avcodec. He mentioned AAC due to some user's
> complaints about quality on certain files. This was likely referring
> to the decoder and not encoder. Nevertheless, I suggest a conversation
> with them (or other users) to obtain problematic files to test.

I'm always on the lookout for problematic files to add to my "test
samples" collection, so if anyone has one they should contact me in
private.

In fact fate needs a few more samples since most of the samples there
fail to trigger any of the bugs we've been working on of late.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avutil/crc: avoid needless space wastage of hardcoded crc table

[Nicolas George]

Le tridi 13 frimaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> There was no reason AFAIK for making AV_CRC_24_IEEE 12.

The reason was to leave room for the fork to add its own new constants
without causing ABI incompatibilities.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 8:38 PM, James Almer  wrote:
> On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 1, 2015 at 8:08 PM, James Almer  wrote:
>>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
 There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
 resulted in wasted space under --enable-hardcoded-tables:
 dynamic: 1318672 libavutil/libavutil.so.55
 old: 1330680 libavutil/libavutil.so.55
 new: 1326488 libavutil/libavutil.so.55

 Minor version number is bumped, with ifdefry due to API breakage.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavutil/crc.h | 4 
  libavutil/version.h | 5 -
  2 files changed, 8 insertions(+), 1 deletion(-)

 diff --git a/libavutil/crc.h b/libavutil/crc.h
 index e86bf1d..9af4421 100644
 --- a/libavutil/crc.h
 +++ b/libavutil/crc.h
 @@ -40,7 +40,11 @@ typedef enum {
  AV_CRC_32_IEEE,
  AV_CRC_32_IEEE_LE,  /*< reversed bitorder version of AV_CRC_32_IEEE */
  AV_CRC_16_ANSI_LE,  /*< reversed bitorder version of AV_CRC_16_ANSI */
 +#if FF_API_CRC_BIG_TABLE
  AV_CRC_24_IEEE = 12,
 +#else
 +AV_CRC_24_IEEE,
 +#endif /* FF_API_CRC_BIG_TABLE */
  AV_CRC_MAX, /*< Not part of public API! Do not use outside 
 libavutil. */
  }AVCRCId;

 diff --git a/libavutil/version.h b/libavutil/version.h
 index e0ddfd2..67e778a 100644
 --- a/libavutil/version.h
 +++ b/libavutil/version.h
 @@ -56,7 +56,7 @@
   */

  #define LIBAVUTIL_VERSION_MAJOR  55
 -#define LIBAVUTIL_VERSION_MINOR   9
 +#define LIBAVUTIL_VERSION_MINOR  10
  #define LIBAVUTIL_VERSION_MICRO 100

  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
 @@ -108,6 +108,9 @@
  #ifndef FF_API_ERROR_FRAME
  #define FF_API_ERROR_FRAME  (LIBAVUTIL_VERSION_MAJOR < 56)
  #endif
 +#ifndef FF_API_CRC_BIG_TABLE
 +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT < 
 AV_VERSION_INT(55, 10, 100))
>>>
>>> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
>>> of these FF_API defines is to make sure they are true until the next major
>>> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
>>> done for the rest.
>>
>> Finally getting a sense for these things, thanks. Barring that, does
>> it look fine?
>
> Yes. You can also skip bumping minor. You're scheduling a change for the next
> major bump and not making any changes with immediate effects, so a minor bump
> is not necessary.

pushed with an additional header include version.h needed to work
correctly, thanks.

>
>>
>>>
 +#endif


  /**

>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> ___
> ffmpeg-devel 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 1/9] avfilter/vsrc_mptestsrc: use lrint instead of floor hack

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 9:11 PM, Michael Niedermayer  wrote:
> On Tue, Dec 01, 2015 at 07:27:50PM -0500, Ganesh Ajjanagadde wrote:
>> lrint is faster, and is more consistent across the codebase.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vsrc_mptestsrc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> should be ok

pushed, thanks

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> While the State exists there can be no freedom; when there is freedom there
> will be no State. -- Vladimir Lenin
>
> ___
> 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 2/9] avfilter/vf_perspective: use lrint instead of floor hack

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 9:10 PM, Michael Niedermayer  wrote:
> On Tue, Dec 01, 2015 at 07:27:51PM -0500, Ganesh Ajjanagadde wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/vf_perspective.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> should be ok

pushed, thanks

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the problem
> conveniently.
> New school: Use the highest level language in which the latest supercomputer
> can solve the problem without the user falling asleep waiting.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack

[Ganesh Ajjanagadde]

On Wed, Dec 2, 2015 at 7:39 AM, Paul B Mahol  wrote:
> On 12/2/15, Ganesh Ajjanagadde  wrote:
>> On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol  wrote:
>>> On 12/2/15, Ganesh Ajjanagadde  wrote:
 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libavfilter/af_flanger.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c
 index f8ec830..a92367c 100644
 --- a/libavfilter/af_flanger.c
 +++ b/libavfilter/af_flanger.c
 @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink)
  return AVERROR(ENOMEM);

  ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo,
 s->lfo_length,
 -   floor(s->delay_min * inlink->sample_rate +
 0.5),
 +   rint(s->delay_min * inlink->sample_rate),
 s->max_samples - 2., 3 * M_PI_2);

  return av_samples_alloc_array_and_samples(>delay_buffer, NULL,
 --
 2.6.2

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

>>>
>>> Have you checked that output is same?
>>
>> Well if is not, rint is more accurate than floor, this is the whole
>> point of the patch. What I can tell is that FATE passes.
>>
>> One can craft input so that floor(x + 0.5) is not identical to
>> rint(x), and that is the point of these patches - to be more accurate
>> when we can be. A simple example: what happens at half-integers, i.e
>> 1.5? Then, floor always returns the next up, e.g 2.0, while rint(x)
>> rounds to the nearest even integer in accord with IEEE-754. This is
>> done to reduce rounding biases on floating point numbers - think of a
>> large number of half integer samples, the floor hack results in
>> consistent upward bias, the rint (or llrint, lrint more generally)
>> avoids this.
>>
>> I care about technical purity of filters; you seem to care about
>> copying it over from some other place and matching another filter
>> exactly, regardless of the quality of such filters. In that case, I
>> think FFmpeg's monolithic filter design needs to be reconsidered; we
>> should allow seamless integration of external filters. These two goals
>> are at odds with each other, and I will always personally prefer the
>> first, since it actually allows greater flexibility for improvements.
>> Ultimately, I am not a maintainer for these things and I have no say
>> on the matter or personal interest in it.
>>
>
> On 2nd look, patch should be fine.

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

Re: [FFmpeg-devel] [PATCH 1/3] common.mak: Use CCFLAGS for assembly generation as well

[Timothy Gu]

On Wed, Dec 02, 2015 at 08:03:33PM +0100, Michael Niedermayer wrote:
> On Tue, Dec 01, 2015 at 09:46:04PM -0800, Timothy Gu wrote:
> > CCFLAGS is equivalent to CPPFLAGS + CFLAGS.
> > ---
> >  common.mak | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> does this fix any case or just simplifies common.mak ?
> 

It just simplifies it. I'll amend the commit message.

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

Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.

[wm4]

On Wed, 02 Dec 2015 00:32:46 +
Aaron Colwell  wrote:

> On Mon, Nov 30, 2015 at 4:35 PM wm4  wrote:
> 
> >
> > I tried your patch, and it actually makes it work better (looks correct
> > with the patch). The patch itself also LGTM.
> >
> >  
> Ok. Great. Thanks for the review. What do I need to do next to get this
> checked in. I don't have commit access.

Well, first it has to be determined whether the patch is accepted, and
then someone has to push it. I just did the latter.

Before pushing, I slightly modified the subject line to add a prefix
and to make it somewhat shorter (as the prefix made it too long). I
hope this is ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization

[Claudio Freire]

On Tue, Dec 1, 2015 at 11:12 PM, Claudio Freire  wrote:
> On Tue, Dec 1, 2015 at 10:47 PM, Michael Niedermayer  wrote:
>>>  libavcodec/aaccoder.c |   60 --
>>>  libavcodec/aaccoder_twoloop.h |  136 
>>> --
>>>  libavcodec/aacenc.c   |2
>>>  libavcodec/aacenc_is.c|   11 ++-
>>>  libavcodec/aacenc_utils.h |   63 +++
>>>  libavcodec/aacpsy.c   |   20 --
>>>  libavcodec/psymodel.c |1
>>>  libavcodec/psymodel.h |1
>>>  tests/fate/aac.mak|   18 ++---
>>>  9 files changed, 231 insertions(+), 81 deletions(-)
>>> 404ff616bb267619be431a7c45afa4db82070b65  
>>> 0001-AAC-encoder-improve-SF-range-utilization.patch
>>
>> some stuff in mips will need to be updated by someone or disabled
>> after this is pushed:
>> CC  libavcodec/aacpsy.o
>> /ffmpeg/libavcodec/aacpsy.c: In function ‘psy_3gpp_analyze_channel’:
>> /ffmpeg/libavcodec/aacpsy.c:666: error: too many arguments to function 
>> ‘calc_thr_3gpp_mips’
>> make: *** [libavcodec/aacpsy.o] Error 1
>> make: Target `all' not remade because of errors.
>
>
> Oh, didn't realize mips had an alternative calc_thr_3gpp.
>
> I'll see about updating it as I push.

Also refreshed search_for_ms_mips and pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack

[Paul B Mahol]

On 12/2/15, Paul B Mahol  wrote:
> On 12/2/15, Ganesh Ajjanagadde  wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/af_stereotools.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c
>> index a22efb0..e878824 100644
>> --- a/libavfilter/af_stereotools.c
>> +++ b/libavfilter/af_stereotools.c
>> @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink,
>> AVFrame
>> *in)
>>  const double sc_level = s->sc_level;
>>  const double delay = s->delay;
>>  const int length = s->length;
>> -const int mute_l = floor(s->mute_l + 0.5);
>> -const int mute_r = floor(s->mute_r + 0.5);
>> -const int phase_l = floor(s->phase_l + 0.5);
>> -const int phase_r = floor(s->phase_r + 0.5);
>> +const int mute_l = lrint(s->mute_l);
>> +const int mute_r = lrint(s->mute_r);
>> +const int phase_l = lrint(s->phase_l);
>> +const int phase_r = lrint(s->phase_r);
>>  double *buffer = s->buffer;
>>  AVFrame *out;
>>  double *dst;
>> --
>> 2.6.2
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> ok
>

Actually lrint is not needed. Fixed differently.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.

[wm4]

On Tue,  1 Dec 2015 10:54:38 -0800
chcunning...@chromium.org wrote:

> From: Chris Cunningham 
> 
> "Fast seek" uses linear interpolation to find the position of the
> requested seek time. For CBR this is more direct than using the
> mp3 TOC and bypassing the TOC avoids problems with TOC precision.
> (see https://crbug.com/545914#c13)
> 
> For VBR, fast seek is not precise, so continue to prefer the TOC
> when available (the lesser of two evils).
> 
> Also, some re-ordering of the logic in mp3_seek to simplify and
> give usetoc=1 precedence over fastseek flag.
> ---
>  libavformat/mp3dec.c| 39 +++
>  libavformat/seek-test.c |  8 +---
>  tests/fate/seek.mak |  2 +-
>  3 files changed, 25 insertions(+), 24 deletions(-)
> 
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 32ca00c..04c9861 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t 
> filesize, int64_t duration
>  {
>  int i;
>  MP3DecContext *mp3 = s->priv_data;
> -int fill_index = mp3->usetoc == 1 && duration > 0;
> +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> +int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
>  
>  if (!filesize &&
>  !(filesize = avio_size(s->pb))) {
> @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
>  int ret;
>  int i;
>  
> -if (mp3->usetoc < 0)
> -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
> -
>  st = avformat_new_stream(s, NULL);
>  if (!st)
>  return AVERROR(ENOMEM);
> @@ -501,35 +499,36 @@ static int mp3_seek(AVFormatContext *s, int 
> stream_index, int64_t timestamp,
>  MP3DecContext *mp3 = s->priv_data;
>  AVIndexEntry *ie, ie1;
>  AVStream *st = s->streams[0];
> -int64_t ret  = av_index_search_timestamp(st, timestamp, flags);
>  int64_t best_pos;
> -int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
> +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
>  int64_t filesize = mp3->header_filesize;
>  
> -if (mp3->usetoc == 2)
> -return -1; // generic index code
> -
>  if (filesize <= 0) {
>  int64_t size = avio_size(s->pb);
>  if (size > 0 && size > s->internal->data_offset)
>  filesize = size - s->internal->data_offset;
>  }
>  
> -if (   (mp3->is_cbr || fast_seek)
> -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> -&& st->duration > 0
> -&& filesize > 0) {
> -ie = 
> -timestamp = av_clip64(timestamp, 0, st->duration);
> -ie->timestamp = timestamp;
> -ie->pos   = av_rescale(timestamp, filesize, st->duration) + 
> s->internal->data_offset;
> -} else if (mp3->xing_toc) {
> +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
> +// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is worse
> +// for bigger files.
> +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be 
> imprecise.\n");
> +
> +int64_t ret = av_index_search_timestamp(st, timestamp, flags);

I moved this line above the av_log() to avoid
declaration-after-statement.

>  if (ret < 0)
>  return ret;
>  
>  ie = >index_entries[ret];
> +} else if (fast_seek && st->duration > 0 && filesize > 0) {
> +if (!mp3->is_cbr)
> +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be 
> imprecise.\n");
> +
> +ie = 
> +timestamp = av_clip64(timestamp, 0, st->duration);
> +ie->timestamp = timestamp;
> +ie->pos   = av_rescale(timestamp, filesize, st->duration) + 
> s->internal->data_offset;
>  } else {
> -return -1;
> +return -1; // generic index code
>  }
>  
>  best_pos = mp3_sync(s, ie->pos, flags);
> @@ -546,7 +545,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index, 
> int64_t timestamp,
>  }
>  
>  static const AVOption options[] = {
> -{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), 
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
> +{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc), 
> AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
>  { NULL },
>  };
>  
> diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
> index 1926f21..bfd06db 100644
> --- a/libavformat/seek-test.c
> +++ b/libavformat/seek-test.c
> @@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts, AVRational 
> base)
>  int main(int argc, char **argv)
>  {
>  const char *filename;
> -AVFormatContext *ic = NULL;
> +AVFormatContext *ic = avformat_alloc_context();
>  int i, ret, stream_id;
>  int j;
>  int64_t timestamp;
> @@ -76,8 +76,10 @@ int main(int argc, char **argv)
>  frame_count = atoi(argv[i+1]);
>  } else 

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Clément Bœsch]

On Tue, Dec 01, 2015 at 06:49:29PM +0100, Nicolas George wrote:
> Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit :
> > Ah. Well then the user can not do it himself since he has no way of
> > acquiring the queue lock (AVThreadMessageQueue is opaque)
> 
> Yes, but why does it matter, if the elements are to be discarded anyway.
> 

because concurrent read/write accesses on the fifo needs to be locked? I
don't understand...

-- 
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] tests/api: Fix API test build on windows with --enable-shared

[Hendrik Leppkes]

On Wed, Dec 2, 2015 at 2:29 AM, Michael Niedermayer  wrote:
> On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote:
>> On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes  
>> wrote:
>> > ---
>> > I'm not quite sure if this fix is 100% correct, but it works here.
>> >
>> > The problem is that FF_DEP_LIBS points to the .dll files, but you can't 
>> > link to the .dll files,
>> > you need to point to the import libraries. Unfortunately there is no 
>> > variable which simply
>> > holds all import libraries - but they do appear to be part of 
>> > FF_EXTRALIBS, so thats used instead.
>> >
>> > tests/api/Makefile | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/tests/api/Makefile b/tests/api/Makefile
>> > index c48c34a..a6d8e42 100644
>> > --- a/tests/api/Makefile
>> > +++ b/tests/api/Makefile
>> > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST
>> >  $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain
>> >
>> >  $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS)
>> > -   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) 
>> > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS)
>> > +   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) 
>> > $(FF_EXTRALIBS) $(ELIBS)
>> >
>> >  testclean::
>> > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF))
>> > --
>> > 2.6.2.windows.1
>> >
>>
>> Anyone that knows the build system a bit more? Or maybe anyone that
>
>> just feels like testing on some other systems than mine? :)
>
> seems to work on everything i tried but that probably is a small
> subset of what is out there
>

Considering this is only in the FATE Makefile, I'll push this later
and address any fallout on FATE, if any, unless someone objects in the
next couple hours.

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

Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack

[Ganesh Ajjanagadde]

On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol  wrote:
> On 12/2/15, Ganesh Ajjanagadde  wrote:
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/af_flanger.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c
>> index f8ec830..a92367c 100644
>> --- a/libavfilter/af_flanger.c
>> +++ b/libavfilter/af_flanger.c
>> @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink)
>>  return AVERROR(ENOMEM);
>>
>>  ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo,
>> s->lfo_length,
>> -   floor(s->delay_min * inlink->sample_rate + 0.5),
>> +   rint(s->delay_min * inlink->sample_rate),
>> s->max_samples - 2., 3 * M_PI_2);
>>
>>  return av_samples_alloc_array_and_samples(>delay_buffer, NULL,
>> --
>> 2.6.2
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Have you checked that output is same?

Well if is not, rint is more accurate than floor, this is the whole
point of the patch. What I can tell is that FATE passes.

One can craft input so that floor(x + 0.5) is not identical to
rint(x), and that is the point of these patches - to be more accurate
when we can be. A simple example: what happens at half-integers, i.e
1.5? Then, floor always returns the next up, e.g 2.0, while rint(x)
rounds to the nearest even integer in accord with IEEE-754. This is
done to reduce rounding biases on floating point numbers - think of a
large number of half integer samples, the floor hack results in
consistent upward bias, the rint (or llrint, lrint more generally)
avoids this.

I care about technical purity of filters; you seem to care about
copying it over from some other place and matching another filter
exactly, regardless of the quality of such filters. In that case, I
think FFmpeg's monolithic filter design needs to be reconsidered; we
should allow seamless integration of external filters. These two goals
are at odds with each other, and I will always personally prefer the
first, since it actually allows greater flexibility for improvements.
Ultimately, I am not a maintainer for these things and I have no say
on the matter or personal interest in it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack

[Ganesh Ajjanagadde]

On Wed, Dec 2, 2015 at 6:03 AM, Paul B Mahol  wrote:
> On 12/2/15, Paul B Mahol  wrote:
>> On 12/2/15, Ganesh Ajjanagadde  wrote:
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavfilter/af_stereotools.c | 8 
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c
>>> index a22efb0..e878824 100644
>>> --- a/libavfilter/af_stereotools.c
>>> +++ b/libavfilter/af_stereotools.c
>>> @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink,
>>> AVFrame
>>> *in)
>>>  const double sc_level = s->sc_level;
>>>  const double delay = s->delay;
>>>  const int length = s->length;
>>> -const int mute_l = floor(s->mute_l + 0.5);
>>> -const int mute_r = floor(s->mute_r + 0.5);
>>> -const int phase_l = floor(s->phase_l + 0.5);
>>> -const int phase_r = floor(s->phase_r + 0.5);
>>> +const int mute_l = lrint(s->mute_l);
>>> +const int mute_r = lrint(s->mute_r);
>>> +const int phase_l = lrint(s->phase_l);
>>> +const int phase_r = lrint(s->phase_r);
>>>  double *buffer = s->buffer;
>>>  AVFrame *out;
>>>  double *dst;
>>> --
>>> 2.6.2
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> ok
>>
>
> Actually lrint is not needed. Fixed differently.

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

Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack

[Paul B Mahol]

On 12/2/15, Ganesh Ajjanagadde  wrote:
> On Wed, Dec 2, 2015 at 1:18 AM, Paul B Mahol  wrote:
>> On 12/2/15, Ganesh Ajjanagadde  wrote:
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavfilter/af_flanger.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c
>>> index f8ec830..a92367c 100644
>>> --- a/libavfilter/af_flanger.c
>>> +++ b/libavfilter/af_flanger.c
>>> @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink)
>>>  return AVERROR(ENOMEM);
>>>
>>>  ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo,
>>> s->lfo_length,
>>> -   floor(s->delay_min * inlink->sample_rate +
>>> 0.5),
>>> +   rint(s->delay_min * inlink->sample_rate),
>>> s->max_samples - 2., 3 * M_PI_2);
>>>
>>>  return av_samples_alloc_array_and_samples(>delay_buffer, NULL,
>>> --
>>> 2.6.2
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> Have you checked that output is same?
>
> Well if is not, rint is more accurate than floor, this is the whole
> point of the patch. What I can tell is that FATE passes.
>
> One can craft input so that floor(x + 0.5) is not identical to
> rint(x), and that is the point of these patches - to be more accurate
> when we can be. A simple example: what happens at half-integers, i.e
> 1.5? Then, floor always returns the next up, e.g 2.0, while rint(x)
> rounds to the nearest even integer in accord with IEEE-754. This is
> done to reduce rounding biases on floating point numbers - think of a
> large number of half integer samples, the floor hack results in
> consistent upward bias, the rint (or llrint, lrint more generally)
> avoids this.
>
> I care about technical purity of filters; you seem to care about
> copying it over from some other place and matching another filter
> exactly, regardless of the quality of such filters. In that case, I
> think FFmpeg's monolithic filter design needs to be reconsidered; we
> should allow seamless integration of external filters. These two goals
> are at odds with each other, and I will always personally prefer the
> first, since it actually allows greater flexibility for improvements.
> Ultimately, I am not a maintainer for these things and I have no say
> on the matter or personal interest in it.
>

On 2nd look, patch should be fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()

[Nicolas George]

Le duodi 12 frimaire, an CCXXIV, Clement Boesch a écrit :
> because concurrent read/write accesses on the fifo needs to be locked?

No, of course not.

> I don't understand...

*I* do not understand what you need, what you want to do with this API. To
discard all elements, just read them until there are no more, no need of
locking (except internally to read them, of course), no need for anything
else. So what am I missing?

Regards,

-- 
  Nicolas George


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