date:20171018

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

2017-10-18 Thread Tobias Rapp


On 17.10.2017 20:12, Nicolas George wrote:

Le sextidi 26 vendémiaire, an CCXXVI, Tobias Rapp a écrit :

This commit seems to break transcoding of some input files on machines with
a lot of CPU cores. See attached script that reproduces the problem
("-threads 32" is used to simulate the situation of a multi-core CPU).

Sorry for noticing late but it took me some time to track down the problem
and git bisecting it. The issue seems to be triggered by the high number of
audio packets in the input file (~375 packets per second). Input files that
have a lower audio packet rate work fine.


Thanks for reporting. I fear this will be tricky to debug.

I think the change you  have tracked cannot be the cause of the issue,
since it does not touch anything related to threading.


Yes, I also don't see why this patch correlates with the number of 
threads. But when bypassing the push_frame() function from the patch by 
adding an immediate "return 0" the problem disappears.



What this change does, on the other hand, is increase the efficiency of
the scheduling in lavfi. That can cause more work for filters that do
use threading, and reveal a race condition there.

I do not have access to a 32-core system. Can the problem be reproduced
with your script with just "-threads 32" without such a system? How
ofter does it manifest?


I'm able to reproduce the issue reliably on each run of the test script 
on three test machines:


- Windows 64bit 32-core, without "-threads 32"
- Windows 64bit 2-core, with "-threads 32"
- GNU/Linux 64bit 2-core, with "-threads 32"

What seem to help as a work-around is adding "-max_muxing_queue_size 1000".

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

2017-10-18 Thread Jorge Ramirez


On 10/18/2017 12:34 AM, Mark Thompson wrote:

  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
  {
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mContext *m2m, *s = avctx->priv_data;
+int i, ret;
  
  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);

  if (ret)
@@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", s->capture.name);
  
  ff_v4l2_context_release(&s->output);

+sem_destroy(&s->refsync);
  
-if (atomic_load(&s->refcount))

-av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
buffers\n");
+if (atomic_load(&s->refcount)) {
+av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced buffers %d\n", 
atomic_load(&s->refcount));
+
+/* We are about to free the private data while the user still has 
references to the buffers.
+ * This means that when the user releases those buffers, the 
v4l2_free_buffer callback will be pointing to free'd memory.
+ * Duplicate the m2m context and update the buffers.
+ */
+m2m = av_mallocz(sizeof(*m2m));
+if (m2m) {
+memcpy(m2m, s, sizeof(V4L2m2mContext));
+for (i = 0; i < s->capture.num_buffers; i++)
+s->capture.buffers[i].m2m = m2m;
+
+return 0;
+}

No.

The user can call av_buffer_unref() and therefore v4l2_free_buffer() 
asynchronously on another thread while this manoeuvre is in progress.



right. as a matter of fact, this synchronization can not be done using 
private data (the opaque structure passed to the callback must contain 
all the required information (and updated!) at any time). On top of this 
being hard to implement would complicate the current code quite a bit 
making it also very hard to maintain. So agreed.


So back to a previous proposal, would the flag below be acceptable? [1]

Seems sensible to me to give responsibility of the private data 
deallocation to the codec itself independently of the close function 
since the buffers allocated by the codec controlled by a separate thread 
will need access to that data.


Put differently since the close function can not be made responsible for 
deallocating mmap/queued memory in V4L2 (or even closing the kernel 
driver) when the user keeps buffers, it should not be allowed to delete 
the codec private data since in my view it forces the design to take a 
lot of unnecessary actions for no real reason.


With the proposal below, the code remains cleaner and free of race 
conditions.


[1] ..

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0..0a3ca0c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -982,6 +982,11 @@ typedef struct RcOverride{
  * Do not reset ASS ReadOrder field on flush (subtitles decoding)
  */
 #define AV_CODEC_FLAG2_RO_FLUSH_NOOP  (1 << 30)
+/**
+ * Closing the codec doesnt release the context priv_data (it becomes 
the codec

+ * responsibility)
+ */
+#define AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE  (1 << 31)

 /* Unsupported options :
  *  Syntax Arithmetic coding (SAC)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 9551f31..b6c5adf 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1211,7 +1211,9 @@ av_cold int avcodec_close(AVCodecContext *avctx)
 if (avctx->priv_data && avctx->codec && avctx->codec->priv_class)
 av_opt_free(avctx->priv_data);
 av_opt_free(avctx);
-av_freep(&avctx->priv_data);
+if (!(avctx->flags2 & AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE))
+av_freep(&avctx->priv_data);
+


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

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

2017-10-18 Thread pkv.stream


Le 02/10/2017 à 8:39 PM, Rostislav Pehlivanov a écrit :

On 2 October 2017 at 18:43, pkv.stream  wrote:


Le 02/10/2017 à 7:23 PM, Michael Niedermayer a écrit :


On Mon, Oct 02, 2017 at 12:52:53AM +0200, pkv.stream wrote:


Le 02/10/2017 à 12:43 AM, Carl Eugen Hoyos a écrit :


2017-10-02 0:40 GMT+02:00 pkv.stream :


Hi atomnuker,

got your PCE working;


the patch you attached contains tabs, they cannot be committed
to the FFmpeg repository, please remove them.
(Or one tab.)


thanks for pointing out.
Removed the offending tab.

Thank you, Carl Eugen

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


   aacenc.h |  239 ++
+++--
   1 file changed, 233 insertions(+), 6 deletions(-)
929275fe34af4d0048bac2be928957288cb75ddd  0001-avcodec-aacenc-PCE-for-al
l-ffmpeg-usual-layouts.patch
  From 647fb61708bc1279f9dc17c679052a778dce5fbb Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sun, 24 Sep 2017 16:11:17 +0200
Subject: [PATCH] avcodec/aacenc: PCE for all ffmpeg usual layouts


this seems not to apply cleanly here, did i miss something ?


Hi Michael
this needs to be applied after the initial patch by atomnuker which he did
not apply since this required work.
What i submitted was not aimed at being pushed since there is probably
still work to do.
Depending on what he wants to do with his patch, I'll resubmit a working
patch later, properly rebased.
Sorry about the mess.
regards



Applying: avcodec/aacenc: PCE for all ffmpeg usual layouts
error: sha1 information is lacking or useless (libavcodec/aacenc.h).
error: could not build fake ancestor
Patch failed at 0001 avcodec/aacenc: PCE for all ffmpeg usual layouts
The copy of the patch that failed is found in: .git/rebase-apply/patch


[...]



___
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



Give me a few hours and I'll test it and submit a v2 of my patch with your
improvements.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Hi

any updates ?

regards

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 06:49:51AM +0200, wm4 wrote:
> I have realized that your veto is actually not valid:
> - it's a Libav merge

There is no exception for changes from Libav.
Not in the policy and not in actual actions. We never pushed
changes with standing objections.

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 07:26:01AM +0200, wm4 wrote:
[...]

> 
> > it also violates the API IMO, but thats not so much the point
> 
> It does not. I created the fucking API.
> 
> > The data the user application wants to attach to a AVFrame for the
> > user applications extrenal purposes
> > and
> > The data libavcodec wants to attach for internal (hwaccel) use.
> > 
> > Are 2 distinct things. You can have none, either one or both theres
> > no relation between them.
> 
> AVFrame does not dictate a use for this field. The use of the field is
> determined by the owner of the AVFrame, which is libavcodec while the
> frame is in libavcodec.
> 
> How often did I repeat this and how often did you not understand this?

opaque_ref is defined to have the same semantics as opaque.
opaque definitly does NOT have the semantics you write about in this
thread.
opaque is a field that exists for a very long time

I think you and Libav misunderstood the opaque field semantics

Just think about it, the opaque field existed when the *frame structure
was defined in libavcodec. The user of libavcodec is NOT libavcodec
This field was never intended to be used by any of our libs to store
their private data.

It was the move of AVFrame to libavutil that made the documentation
of opaque ambigous and this likely lead to this misunderstanding

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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

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

Re: [FFmpeg-devel] [PATCH] configure: add pkg-config check for alsa

2017-10-18 Thread Jan Ekstrom

On Mon, Oct 16, 2017 at 11:01 PM, Jan Ekström  wrote:
> ---
>  configure | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index b9a3a9bc1f..5aa642a9bb 100755
> --- a/configure
> +++ b/configure
> @@ -6254,7 +6254,8 @@ EOF
>  fi
>  check_header soundcard.h
>
> -enabled alsa && check_lib alsa alsa/asoundlib.h snd_pcm_htimestamp -lasound
> +enabled alsa && use_pkg_config alsa alsa "alsa/asoundlib.h" 
> snd_pcm_htimestamp ||
> +check_lib alsa alsa/asoundlib.h snd_pcm_htimestamp -lasound
>
>  enabled jack && check_lib jack jack/jack.h jack_client_open -ljack &&
>  check_func jack_port_get_latency_range -ljack
> --
> 2.13.6
>

Just noticed that random user on #ffmpeg had private messaged me, and
yes - this had indeed fixed his linking issues with a static ALSA
library.

Please apply.

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

2017-10-18 Thread Mark Thompson

On 18/10/17 08:46, Jorge Ramirez wrote:
> On 10/18/2017 12:34 AM, Mark Thompson wrote:
>>>  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>>>  {
>>> -V4L2m2mContext* s = avctx->priv_data;
>>> -int ret;
>>> +V4L2m2mContext *m2m, *s = avctx->priv_data;
>>> +int i, ret;
>>>  
>>>  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
>>>  if (ret)
>>> @@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>>>  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", 
>>> s->capture.name);
>>>  
>>>  ff_v4l2_context_release(&s->output);
>>> +sem_destroy(&s->refsync);
>>>  
>>> -if (atomic_load(&s->refcount))
>>> -av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
>>> buffers\n");
>>> +if (atomic_load(&s->refcount)) {
>>> +av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced 
>>> buffers %d\n", atomic_load(&s->refcount));
>>> +
>>> +/* We are about to free the private data while the user still has 
>>> references to the buffers.
>>> + * This means that when the user releases those buffers, the 
>>> v4l2_free_buffer callback will be pointing to free'd memory.
>>> + * Duplicate the m2m context and update the buffers.
>>> + */
>>> +m2m = av_mallocz(sizeof(*m2m));
>>> +if (m2m) {
>>> +memcpy(m2m, s, sizeof(V4L2m2mContext));
>>> +for (i = 0; i < s->capture.num_buffers; i++)
>>> +s->capture.buffers[i].m2m = m2m;
>>> +
>>> +return 0;
>>> +}
>> No.
>>
>> The user can call av_buffer_unref() and therefore v4l2_free_buffer() 
>> asynchronously on another thread while this manoeuvre is in progress.
>>
> 
> right. as a matter of fact, this synchronization can not be done using 
> private data (the opaque structure passed to the callback must contain all 
> the required information (and updated!) at any time). On top of this being 
> hard to implement would complicate the current code quite a bit making it 
> also very hard to maintain. So agreed.
> 
> So back to a previous proposal, would the flag below be acceptable? [1]
> 
> Seems sensible to me to give responsibility of the private data deallocation 
> to the codec itself independently of the close function since the buffers 
> allocated by the codec controlled by a separate thread will need access to 
> that data.
> 
> Put differently since the close function can not be made responsible for 
> deallocating mmap/queued memory in V4L2 (or even closing the kernel driver) 
> when the user keeps buffers, it should not be allowed to delete the codec 
> private data since in my view it forces the design to take a lot of 
> unnecessary actions for no real reason.
> 
> With the proposal below, the code remains cleaner and free of race conditions.
> 
> [1] ..
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 52cc5b0..0a3ca0c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -982,6 +982,11 @@ typedef struct RcOverride{
>   * Do not reset ASS ReadOrder field on flush (subtitles decoding)
>   */
>  #define AV_CODEC_FLAG2_RO_FLUSH_NOOP  (1 << 30)
> +/**
> + * Closing the codec doesnt release the context priv_data (it becomes the 
> codec
> + * responsibility)
> + */
> +#define AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE  (1 << 31)
> 
>  /* Unsupported options :
>   *  Syntax Arithmetic coding (SAC)
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 9551f31..b6c5adf 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1211,7 +1211,9 @@ av_cold int avcodec_close(AVCodecContext *avctx)
>  if (avctx->priv_data && avctx->codec && avctx->codec->priv_class)
>  av_opt_free(avctx->priv_data);
>  av_opt_free(avctx);
> -    av_freep(&avctx->priv_data);
> +    if (!(avctx->flags2 & AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE))
> +    av_freep(&avctx->priv_data);
> +
> 
> 

I'm not seeing the motivation for this at all.  Anything which possibly needs 
to persist beyond the codec close will be refcounted (with references from the 
codec instance itself and from the outstanding output frames, as you have), so 
it should be stored in a refcounted buffer.  That's how all other components 
with this problem work, so why does v4l2 want special API to behave differently?

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

2017-10-18 Thread Dave Rice

> On Oct 17, 2017, at 3:30 PM, Douglas Marsh  wrote:
> 
> On 2017-10-17 09:10, Dave Rice wrote:
> 
 -audio_depth   .D.. audio bitdepth (from 0 to 1)
 (default 16bits)
16bits   .D..
> 
>>> Hmm, first patch might be enough.
>> Sounds good to me. Unless anyone prefers "-audio_depth thirtytwo" :-D
>> Dave Rice
> 
> Yeah that works.. so if they have any other depths, can go 0, 1 or 2 (2=some 
> new bit depth yet to be created)
> 
> And for clarification: yes 32-bits (PCM_S32LE) -- I was just pointing out the 
> ADC/DAC's are 24-bit (8-bits padded).

I was suggesting `-audio_depth thirtytwo` in jest. IMHO assigning enumerated 
index numbers to purely numerical values will be confusing. For instance if in 
the future 12 bit is added then 24 bit, we'll have 
-audio_depth   .D.. audio bitdepth (from 0 to 3) (default 
16bits)
   16bits [0]
   32bits [1]
   12bits [2]
   24bits [3]

The alternative patch in the "decklink 24/32 bit question" thread, changes the 
default behavior of the decklink input which I think should be avoided. I agree 
with Moritz that the  first patch of this thread 
(https://patchwork.ffmpeg.org/patch/5588/) is the best option. Also the method 
used in the patch to validate a limited non-consecutive range of values is 
already in used elsewhere in the device for the channel count at 
https://github.com/FFmpeg/FFmpeg/blob/278588cd0bf788df0194f74e62745f68559616f9/libavdevice/decklink_dec.cpp#L859-L868.

Best Regards,

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Compn

On Tue, 17 Oct 2017 20:37:32 +0200, Thilo Borgmann
 wrote:

> I do care because I am delaying my work on some other cuvid related thing 
> because of this.
> 
> I would prefer not to dive into this topic any further because it seems 
> rather "not so important" to my task. And just another cook in the kitchen 
> would also more likely avoid conensus here.

thilo, can we bribe you to massage this patch a little?

it seems like wm4 and michael both are not budging...
a third party might be able to settle the stalemate.

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Compn

On Wed, 4 Oct 2017 11:34:18 +0200, wm4  wrote:

> > more so, opaque_ref is used in only 5 lines in the whole codebase,
> > so there is not much code to consider when using a different solution
> 
> We shouldn't add such special fields, we have enough hacks already. Is
> that your only suggestion how to do this? Because it's a bad one.

michael, do you have other suggestions how to solve this problem? are
you going to fix the errors in the doxygen that you noticed due to
merges?

wm4, would you object to adding another special field? if
someone else edited this and made a patch?

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

Re: [FFmpeg-devel] [PATCH] avcodec/cfhd: support cropped height tag

2017-10-18 Thread James Almer

On 10/17/2017 10:07 PM, James Almer wrote:
> Ported from libav. Authored by one of the following:
> 
> Anton Khirnov 
> Diego Biurrun 
> Vittorio Giovara 
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/cfhd.c | 6 ++
>  libavcodec/cfhd.h | 1 +
>  2 files changed, 7 insertions(+)

Oked by Kieran on IRC and pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Michael Niedermayer

On Wed, Oct 18, 2017 at 09:48:16AM -0400, Compn wrote:
[...]

> a third party might be able to settle the stalemate.

i strongly support this. And it was in part why i suggested to take
this to the vote comittee. Most people from the vote committee are
uninvolved in this

This should be carefully looked at by people with cool heads and
decided.

I had actually written something similar in my last reply but i edited
it out before sending as it seemed to get a bit lengthy and redundant.

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] configure: add pkg-config check for alsa

2017-10-18 Thread Jan Ekstrom

> Please apply.

Got my key registered onto the system and pushed along with an update
to the commit message noting the static linking use case.

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

2017-10-18 Thread Jorge Ramirez


On 10/18/2017 03:28 PM, Mark Thompson wrote:

On 18/10/17 08:46, Jorge Ramirez wrote:

On 10/18/2017 12:34 AM, Mark Thompson wrote:

  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
  {
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mContext *m2m, *s = avctx->priv_data;
+int i, ret;
  
  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);

  if (ret)
@@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", s->capture.name);
  
  ff_v4l2_context_release(&s->output);

+sem_destroy(&s->refsync);
  
-if (atomic_load(&s->refcount))

-av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
buffers\n");
+if (atomic_load(&s->refcount)) {
+av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced buffers %d\n", 
atomic_load(&s->refcount));
+
+/* We are about to free the private data while the user still has 
references to the buffers.
+ * This means that when the user releases those buffers, the 
v4l2_free_buffer callback will be pointing to free'd memory.
+ * Duplicate the m2m context and update the buffers.
+ */
+m2m = av_mallocz(sizeof(*m2m));
+if (m2m) {
+memcpy(m2m, s, sizeof(V4L2m2mContext));
+for (i = 0; i < s->capture.num_buffers; i++)
+s->capture.buffers[i].m2m = m2m;
+
+return 0;
+}

No.

The user can call av_buffer_unref() and therefore v4l2_free_buffer() 
asynchronously on another thread while this manoeuvre is in progress.


right. as a matter of fact, this synchronization can not be done using private 
data (the opaque structure passed to the callback must contain all the required 
information (and updated!) at any time). On top of this being hard to implement 
would complicate the current code quite a bit making it also very hard to 
maintain. So agreed.

So back to a previous proposal, would the flag below be acceptable? [1]

Seems sensible to me to give responsibility of the private data deallocation to 
the codec itself independently of the close function since the buffers 
allocated by the codec controlled by a separate thread will need access to that 
data.

Put differently since the close function can not be made responsible for 
deallocating mmap/queued memory in V4L2 (or even closing the kernel driver) 
when the user keeps buffers, it should not be allowed to delete the codec 
private data since in my view it forces the design to take a lot of unnecessary 
actions for no real reason.

With the proposal below, the code remains cleaner and free of race conditions.

[1] ..

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0..0a3ca0c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -982,6 +982,11 @@ typedef struct RcOverride{
   * Do not reset ASS ReadOrder field on flush (subtitles decoding)
   */
  #define AV_CODEC_FLAG2_RO_FLUSH_NOOP  (1 << 30)
+/**
+ * Closing the codec doesnt release the context priv_data (it becomes the codec
+ * responsibility)
+ */
+#define AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE  (1 << 31)

  /* Unsupported options :
   *  Syntax Arithmetic coding (SAC)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 9551f31..b6c5adf 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1211,7 +1211,9 @@ av_cold int avcodec_close(AVCodecContext *avctx)
  if (avctx->priv_data && avctx->codec && avctx->codec->priv_class)
  av_opt_free(avctx->priv_data);
  av_opt_free(avctx);
-av_freep(&avctx->priv_data);
+if (!(avctx->flags2 & AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE))
+av_freep(&avctx->priv_data);
+



I'm not seeing the motivation for this at all.


right. Yes, the motivation is implicit in the way v4l2 support was 
implemented (capture and output context are allocated on priv_data (they 
are not pointers) to enable navigating the data structures using 
container_of all over the code).
this makes the code not only fast and less prone to leaks but also 
easier to read and maintain (it is a pattern used in many drivers)
The v4l2 implementation only allocates two chunks of heap to accommodate 
all of its buffers. So leaks are extremely unlikely.



Anything which possibly needs to persist beyond the codec close will be 
refcounted (with references from the codec instance itself and from the 
outstanding output frames, as you have), so it should be stored in a refcounted 
buffer.


Not if the codec puts all its information on private_data as is done in 
v4l2.



That's how all other components with this problem work, so why does v4l2 want 
special API to behave differently?


Given the use case we are implementing against, I think it is sensible 
to give the codec the 'option' to handle its private_data (ie, the patch 
above)
But I would also like to understand your concern before replacing the 
structures with pointers

[FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Bradshaw

Hi,

Attached patch drops support for OpenJPEG 1.3, 1.4, 1.5, and 2.0. After
this patch, only versions 2.1 and above will be supported (and will require
pkg-config).

Tested locally on macOS with OpenJPEG 2.3 by both encoding and decoding a
jp2 file.

Please review.

Thanks,

--Michael


0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] decklink 24/32 bit question

2017-10-18 Thread Marton Balint




On Tue, 17 Oct 2017, Devin Heitmueller wrote:


> The decklink sdk only defines two BMDAudioSampleType values: 
bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I don't think 
there's an easy way to support a 24 bit input here. Generally in this case I've 
used bmdAudioSampleType32bitInteger and then encode it at pcm_s24le.
Dave Rice


For what it’s worth, I’ve got deinterleaving code in the works to handle 
capture of multiple pairs of audio (i.e. break 16 channels into 8 pairs 
and announce them as separate S16LE streams).  If we really thought 
24-bit was desirable, that code could be adjusted accordingly (the 
hardware would still capture 32-bit, but the deinterleaver would put out 
S24LE).


Breaking 8/16 channels to stereo streams can be done by an audio filter 
(by using "asplit" to multiply the source to 4 outputs and then "pan" or 
"channelmap" on each output to select the proper source channels), so I 
don't think direct support of splitting channels in the decklink device is 
acceptable.


If you have performance or convenience problems with using the 
filters above then propose a filter wich does this in a single step or 
extend one of the existing ones to be able to do this.


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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

2017-10-18 Thread Marton Balint



On Mon, 16 Oct 2017, Dave Rice wrote:


Hi,

I tested this with my Ultrastudio Express and confirmed that I'm getting 
higher bit depth recordings with the abitscope filter. This patch adds 
an option to get 32 bit audio as an input with the decklink device 
(beforehand only 16 bit audio was supported). This resolves 
http://trac.ffmpeg.org/ticket/6708 and is partly based upon Georg 
Lippitisch's earlier draft at 
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.



From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Thu, 12 Oct 2017 13:40:59 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support

Partially based upon Georg Lippitsch's patch at 
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
---
libavdevice/decklink_common.h   |  1 +
libavdevice/decklink_common_c.h |  1 +
libavdevice/decklink_dec.cpp| 17 ++---
libavdevice/decklink_dec_c.c|  1 +
4 files changed, 17 insertions(+), 3 deletions(-)


Missing docs/indevs.texi update and libavdevice micro bump.

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

Re: [FFmpeg-devel] [PATCH 6/9] opusenc: Fix double-declaration of variable

2017-10-18 Thread Mark Thompson

On 17/10/17 23:58, Rostislav Pehlivanov wrote:
> On 17 October 2017 at 22:12, Mark Thompson  wrote:
> 
>> ---
>>  libavcodec/opusenc_psy.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/libavcodec/opusenc_psy.c b/libavcodec/opusenc_psy.c
>> index b446d41f75..1b108ecb87 100644
>> --- a/libavcodec/opusenc_psy.c
>> +++ b/libavcodec/opusenc_psy.c
>> @@ -370,7 +370,6 @@ static int celt_search_for_tf(OpusPsyContext *s,
>> OpusPsyStep **start, CeltFrame
>>  for (cway = 0; cway < 2; cway++) {
>>  int mag[2];
>>  int base = f->transient ? 120 : 960;
>> -int i;
>>
>>  for (i = 0; i < 2; i++) {
>>  int c = ff_celt_tf_select[f->size][f->transient][cway][i];
>> --
>> 2.11.0
>>
> 
> LGTM
> 
On 17/10/17 23:59, Rostislav Pehlivanov wrote:
> On 17 October 2017 at 23:11, Mark Thompson  wrote:
> 
>> This can trigger a single-byte overread if the codebook has the maximum
>> number of entries.
>>
>> Fixes #6743.
>> ---
>>  libavcodec/vorbis.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/vorbis.c b/libavcodec/vorbis.c
>> index 399020eec5..ce23b947f0 100644
>> --- a/libavcodec/vorbis.c
>> +++ b/libavcodec/vorbis.c
>> @@ -58,7 +58,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes,
>> unsigned num)
>>  uint32_t exit_at_level[33] = { 404 };
>>  unsigned i, j, p, code;
>>
>> -for (p = 0; (bits[p] == 0) && (p < num); ++p)
>> +for (p = 0; (p < num) && (bits[p] == 0); ++p)
>>  ;
>>  if (p == num)
>>  return 0;
>> @@ -71,7 +71,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes,
>> unsigned num)
>>
>>  ++p;
>>
>> -for (i = p; (bits[i] == 0) && (i < num); ++i)
>> +for (i = p; (i < num) && (bits[i] == 0); ++i)
>>  ;
>>  if (i == num)
>>  return 0;
>> --
>> 2.11.0
>>
> 
> LGTM

Both applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

2017-10-18 Thread Dave Rice


> On Oct 18, 2017, at 3:07 PM, Marton Balint  wrote:
> 
> On Mon, 16 Oct 2017, Dave Rice wrote:
> 
>> Hi,
>> 
>> I tested this with my Ultrastudio Express and confirmed that I'm getting 
>> higher bit depth recordings with the abitscope filter. This patch adds an 
>> option to get 32 bit audio as an input with the decklink device (beforehand 
>> only 16 bit audio was supported). This resolves 
>> http://trac.ffmpeg.org/ticket/6708 and is partly based upon Georg 
>> Lippitisch's earlier draft at 
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>> 
>> 
>> From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
>> From: Dave Rice 
>> Date: Thu, 12 Oct 2017 13:40:59 -0400
>> Subject: [PATCH] libavdevice/decklink: 32 bit audio support
>> 
>> Partially based upon Georg Lippitsch's patch at 
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>> ---
>> libavdevice/decklink_common.h   |  1 +
>> libavdevice/decklink_common_c.h |  1 +
>> libavdevice/decklink_dec.cpp| 17 ++---
>> libavdevice/decklink_dec_c.c|  1 +
>> 4 files changed, 17 insertions(+), 3 deletions(-)
> 
> Missing docs/indevs.texi update and libavdevice micro bump.

Updated.

From 1e5ff78fec9b13eccac9a96acc358bbfd6a7015d Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Wed, 18 Oct 2017 15:21:46 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support

---
 doc/indevs.texi |  4 
 libavdevice/decklink_common.h   |  1 +
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 17 ++---
 libavdevice/decklink_dec_c.c|  1 +
 libavdevice/version.h   |  2 +-
 6 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 55a4084bb2..d308bbf7de 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -311,6 +311,10 @@ Sets maximum input buffer size in bytes. If the buffering 
reaches this value,
 incoming frames will be dropped.
 Defaults to @samp{1073741824}.
 
+@item audio_depth
+Sets the audio sample bit depth. Must be @samp{16} or @samp{32}.
+Defaults to @samp{16}.
+
 @end table
 
 @subsection Examples
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..b6acb01bb9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -97,6 +97,7 @@ struct decklink_ctx {
 int frames_buffer_available_spots;
 
 int channels;
+int audio_depth;
 };
 
 typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 5616ab32f9..368ac259e4 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -42,6 +42,7 @@ struct decklink_cctx {
 double preroll;
 int v210;
 int audio_channels;
+int audio_depth;
 int duplex_mode;
 DecklinkPtsSource audio_pts_source;
 DecklinkPtsSource video_pts_source;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index d9ac01ac91..7e97d5f064 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -771,7 +771,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 av_init_packet(&pkt);
 
 //hack among hacks
-pkt.size = audioFrame->GetSampleFrameCount() * 
ctx->audio_st->codecpar->channels * (16 / 8);
+pkt.size = audioFrame->GetSampleFrameCount() * 
ctx->audio_st->codecpar->channels * (ctx->audio_depth / 8);
 audioFrame->GetBytes(&audioFrameBytes);
 audioFrame->GetPacketTime(&audio_pts, ctx->audio_st->time_base.den);
 pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, 
ctx->audio_pts_source, ctx->audio_st->time_base, &initial_audio_pts);
@@ -854,6 +854,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 ctx->audio_pts_source = cctx->audio_pts_source;
 ctx->video_pts_source = cctx->video_pts_source;
 ctx->draw_bars = cctx->draw_bars;
+ctx->audio_depth = cctx->audio_depth;
 cctx->ctx = ctx;
 
 /* Check audio channel option for valid values: 2, 8 or 16 */
@@ -866,6 +867,16 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Value of channels option must be one 
of 2, 8 or 16\n");
 return AVERROR(EINVAL);
 }
+
+/* Check audio bit depth option for valid values: 16 or 32 */
+switch (cctx->audio_depth) {
+case 16:
+case 32:
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "Value for audio bit depth option must 
be either 16 or 32\n");
+return AVERROR(EINVAL);
+}
 
 /* List available devices. */
 if (ctx->list_devices) {
@@ -930,7 +941,7 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
 goto error;
 }
 st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id= AV_CODEC_ID_PCM_S16LE;
+st->codecpar->codec_id=

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread James Almer

On 10/18/2017 3:43 PM, Michael Bradshaw wrote:
> Hi,
> 
> Attached patch drops support for OpenJPEG 1.3, 1.4, 1.5, and 2.0. After
> this patch, only versions 2.1 and above will be supported (and will require
> pkg-config).
> 
> Tested locally on macOS with OpenJPEG 2.3 by both encoding and decoding a
> jp2 file.
> 
> Please review.
> 
> Thanks,
> 
> --Michael

Add a line to Changelog about dropping support for OpenJPEG <= 2.0.

> From b1f10da6e945c361b181364f396c5051410afcc4 Mon Sep 17 00:00:00 2001
> From: Michael Bradshaw 
> Date: Wed, 18 Oct 2017 11:34:06 -0700
> Subject: [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
> 
> We now require 2.1+ with pkg-config.
> 
> Signed-off-by: Michael Bradshaw 
> ---
>  configure   |  16 +
>  libavcodec/libopenjpegdec.c | 103 ++---
>  libavcodec/libopenjpegenc.c | 156 
> +++-
>  3 files changed, 32 insertions(+), 243 deletions(-)
> 
> diff --git a/configure b/configure
> index e4c4567138..95e7f83e79 100755
> --- a/configure
> +++ b/configure
> @@ -1938,11 +1938,6 @@ HEADERS_LIST="
>  machine_ioctl_meteor_h
>  malloc_h
>  opencv2_core_core_c_h
> -openjpeg_2_3_openjpeg_h
> -openjpeg_2_2_openjpeg_h
> -openjpeg_2_1_openjpeg_h
> -openjpeg_2_0_openjpeg_h
> -openjpeg_1_5_openjpeg_h
>  OpenGL_gl3_h
>  poll_h
>  soundcard_h
> @@ -6034,16 +6029,7 @@ enabled libopencv && { check_header 
> opencv2/core/core_c.h &&
>   require libopencv opencv2/core/core_c.h 
> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> require_pkg_config libopencv opencv 
> opencv/cxcore.h cvCreateImageHeader; }
>  enabled libopenh264   && require_pkg_config libopenh264 openh264 
> wels/codec_api.h WelsGetCodecVersion
> -enabled libopenjpeg   && { { check_lib libopenjpeg 
> openjpeg-2.3/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   check_lib libopenjpeg openjpeg-2.3/openjpeg.h 
> opj_version -lopenjp2 ||
> -   { check_lib libopenjpeg 
> openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   check_lib libopenjpeg openjpeg-2.2/openjpeg.h 
> opj_version -lopenjp2 ||
> -   { check_lib libopenjpeg 
> openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   check_lib libopenjpeg openjpeg-2.1/openjpeg.h 
> opj_version -lopenjp2 ||
> -   { check_lib libopenjpeg 
> openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   { check_lib libopenjpeg 
> openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   { check_lib libopenjpeg openjpeg.h 
> opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
> -   die "ERROR: libopenjpeg not found"; }
> +enabled libopenjpeg   && require_pkg_config libopenjpeg libopenjp2 
> openjpeg.h opj_version

OpenJPEG 2.0.1 ships a pkg-config file, so change the second argument to
"libopenjp2 >= 2.1.0".

Aside from that LGTM. It's nice to see all the bloat gone and every
future 2.x version being supported without further changes from now on.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] decklink 24/32 bit question

2017-10-18 Thread Devin Heitmueller

Hello Marton,

> On Oct 18, 2017, at 3:02 PM, Marton Balint  wrote:
> 
> 
> 
> On Tue, 17 Oct 2017, Devin Heitmueller wrote:
> 
>>> > The decklink sdk only defines two BMDAudioSampleType values: 
>>> > bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I 
>>> > don't think there's an easy way to support a 24 bit input here. Generally 
>>> > in this case I've used bmdAudioSampleType32bitInteger and then encode it 
>>> > at pcm_s24le.
>>> Dave Rice
>> 
>> For what it’s worth, I’ve got deinterleaving code in the works to handle 
>> capture of multiple pairs of audio (i.e. break 16 channels into 8 pairs and 
>> announce them as separate S16LE streams).  If we really thought 24-bit was 
>> desirable, that code could be adjusted accordingly (the hardware would still 
>> capture 32-bit, but the deinterleaver would put out S24LE).
> 
> Breaking 8/16 channels to stereo streams can be done by an audio filter (by 
> using "asplit" to multiply the source to 4 outputs and then "pan" or 
> "channelmap" on each output to select the proper source channels), so I don't 
> think direct support of splitting channels in the decklink device is 
> acceptable.

So using an audio filter sounds like a great idea and was my initial instinct.  
However then I dug into the ffmpeg API interfaces and discovered that audio 
filters cannot output anything but audio samples.  This prevents me from doing 
detection of compressed audio over SDI (i.e. S302M) during the probing phase 
(i.e. for Dolby-E or AC-3), since the output would be something other than 
uncompressed audio samples.

It also means you cannot do a simple use case for having the decklink demux 
announce 8 streams which can be easily fed to eight different encoders through 
the standard map facility.  You would have to probe the input, and use 
filter_complex to insert an audio filter which deinterleaves the audio, and 
then manually instantiate a series of audio encoders mapped to each output.

The approach I’ve proposed will “just work” in the ffmpeg command line use 
case.  Run the command, say “-map 0”, and eight streams will be fed to eight 
encoders (or pass through with the copy codec for compressed audio) and 
inserted into the transport stream.

I’m not against refactoring the existing S302 codec to create a demux to detect 
audio and create the streams with either raw or compressed codec type based on 
detection.  In that case the decklink demux would spawn an S302 sub-demux for 
each of the streams.  However in any case it would still require the audio to 
be de-interleaved in order to detect the S302 packets.

Now I welcome someone to better design the filter interface to allow filters 
which can take in raw audio and output compressed data.  Likewise I welcome 
someone to introduce improvements which allow filters to create new streams.  
However in the absence of either of these rather large redesigns of ffmpeg’s 
internals, the approach I’m proposing is the only thing I could come up with 
which allows for these decisions to be made at the probing phase.

I’m also not against the notion of invoking a filter from inside the demux  if 
such a deinterleaving filter exists (and then have the decklink demux create 
the streams based on passing the data through the filter).  That would allow 
for some code reuse but is still a hack to overcome the limitations of ffmpeg’s 
probing framework.

I’m also not against the notion of creating a demux which is fed all eight 
audio streams as one blob and having that demux create the streams (and then 
invoking that demux from inside the decklink demux).  While that might lend 
itself to a bit of code sharing if we had other SDI input cards we wanted to 
support (assuming the provide audio in the same basic format), it still 
wouldn’t be an audio filter and I’m not confident the extra abstraction is 
worth the effort.

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Marton Balint



On Wed, 18 Oct 2017, Michael Niedermayer wrote:


On Wed, Oct 18, 2017 at 09:48:16AM -0400, Compn wrote:
[...]


a third party might be able to settle the stalemate.


i strongly support this. And it was in part why i suggested to take
this to the vote comittee. Most people from the vote committee are
uninvolved in this

This should be carefully looked at by people with cool heads and
decided.


I tried to follow the discussion but I still don't get why adding a 
new "priv_ref" field to AVFrame for lavc internal use is frowned upon. 
It seems like the easiest solution to relax the concerns and a small 
price to pay to put this story behind us.


Unfortunately I don't know much about hwaccel, so I can't judge the 
whole patch series, but for me it is not evident that post-processing 
belongs to the decoder interface, if everybody agrees that it does, then 
OK.


I also find storing an AVBufferRef in an AVBufferRef a bit confusing, 
because sooner or later we won't know if we have to do a deep ref on 
referencing an avframe, or not, so I'd try to avoid that in general.


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

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

2017-10-18 Thread Devin Heitmueller


> On Oct 6, 2017, at 12:56 PM, Devin Heitmueller  
> wrote:
> 
> From: Devin Heitmueller 
> 
> Hook in libklvanc and use it for output of EIA-708 captions over
> SDI.  The bulk of this patch is just general support for ancillary
> data for the Decklink SDI module - the real work for construction
> of the EIA-708 CDP and VANC line construction is done by libklvanc.
> 
> Libklvanc can be found at: https://github.com/stoth68000/libklvanc
> 
> Signed-off-by: Devin Heitmueller 

Any additional technical comments related to this patch, or should I resubmit 
for merge?

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

2017-10-18 Thread Michael Niedermayer

On Wed, Oct 18, 2017 at 09:46:40AM +0200, Jorge Ramirez wrote:
> On 10/18/2017 12:34 AM, Mark Thompson wrote:
> >>  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
> >>  {
> >>-V4L2m2mContext* s = avctx->priv_data;
> >>-int ret;
> >>+V4L2m2mContext *m2m, *s = avctx->priv_data;
> >>+int i, ret;
> >>  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
> >>  if (ret)
> >>@@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
> >>  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", 
> >> s->capture.name);
> >>  ff_v4l2_context_release(&s->output);
> >>+sem_destroy(&s->refsync);
> >>-if (atomic_load(&s->refcount))
> >>-av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
> >>buffers\n");
> >>+if (atomic_load(&s->refcount)) {
> >>+av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced 
> >>buffers %d\n", atomic_load(&s->refcount));
> >>+
> >>+/* We are about to free the private data while the user still has 
> >>references to the buffers.
> >>+ * This means that when the user releases those buffers, the 
> >>v4l2_free_buffer callback will be pointing to free'd memory.
> >>+ * Duplicate the m2m context and update the buffers.
> >>+ */
> >>+m2m = av_mallocz(sizeof(*m2m));
> >>+if (m2m) {
> >>+memcpy(m2m, s, sizeof(V4L2m2mContext));
> >>+for (i = 0; i < s->capture.num_buffers; i++)
> >>+s->capture.buffers[i].m2m = m2m;
> >>+
> >>+return 0;
> >>+}
> >No.
> >
> >The user can call av_buffer_unref() and therefore v4l2_free_buffer() 
> >asynchronously on another thread while this manoeuvre is in progress.
> >
> 
> right. as a matter of fact, this synchronization can not be done
> using private data (the opaque structure passed to the callback must
> contain all the required information (and updated!) at any time). On
> top of this being hard to implement would complicate the current
> code quite a bit making it also very hard to maintain. So agreed.
> 
> So back to a previous proposal, would the flag below be acceptable? [1]
> 
> Seems sensible to me to give responsibility of the private data
> deallocation to the codec itself independently of the close function
> since the buffers allocated by the codec controlled by a separate
> thread will need access to that data.
> 
> Put differently since the close function can not be made responsible
> for deallocating mmap/queued memory in V4L2 (or even closing the
> kernel driver) when the user keeps buffers, it should not be allowed
> to delete the codec private data since in my view it forces the
> design to take a lot of unnecessary actions for no real reason.
> 
> With the proposal below, the code remains cleaner and free of race
> conditions.
> 
> [1] ..
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 52cc5b0..0a3ca0c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -982,6 +982,11 @@ typedef struct RcOverride{
>   * Do not reset ASS ReadOrder field on flush (subtitles decoding)
>   */
>  #define AV_CODEC_FLAG2_RO_FLUSH_NOOP  (1 << 30)
> +/**
> + * Closing the codec doesnt release the context priv_data (it
> becomes the codec
> + * responsibility)
> + */
> +#define AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE  (1 << 31)
> 
>  /* Unsupported options :
>   *  Syntax Arithmetic coding (SAC)
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 9551f31..b6c5adf 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -1211,7 +1211,9 @@ av_cold int avcodec_close(AVCodecContext *avctx)
>  if (avctx->priv_data && avctx->codec && avctx->codec->priv_class)
>  av_opt_free(avctx->priv_data);
>  av_opt_free(avctx);
> -av_freep(&avctx->priv_data);
> +if (!(avctx->flags2 & AV_CODEC_FLAG2_PRESERVE_PRIVDATA_ONCLOSE))
> +av_freep(&avctx->priv_data);


This may be solving a similar issue as our udp.c cleanup with its
thread. Not sure, i didnt follow this discussion closely.
just wanted to mention as one migt benefit from the other if its the
same issue.

Another thing that came to my mind, if the context (and other resources)
are deallocated with a delay beyond closing. Is this still correct if
the process terminates before or in the middle.
Or is that preented somehow ?

There would be at least spurious warnings from memory debuggers if
deallocation isnt run at all

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

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Bradshaw

Thanks for the review!

On Wed, Oct 18, 2017 at 12:26 PM, James Almer  wrote:
>
> Add a line to Changelog about dropping support for OpenJPEG <= 2.0.
>

Done.

> +enabled libopenjpeg   && require_pkg_config libopenjpeg libopenjp2
> openjpeg.h opj_version
>
> OpenJPEG 2.0.1 ships a pkg-config file, so change the second argument to
> "libopenjp2 >= 2.1.0".
>

Thanks for catching that; I didn't realize 2.0.1 included pkg-config
support. Fixed.

Aside from that LGTM. It's nice to see all the bloat gone and every
> future 2.x version being supported without further changes from now on.

Yeah, I look forward to the decreased maintenance costs!

Attached is an updated patch with the requested changes to configure and
Changelog. I plan on pushing this in a few hours (unless, of course, there
are additional critiques).

0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

2017-10-18 Thread Marton Balint




On Wed, 18 Oct 2017, Dave Rice wrote:




On Oct 18, 2017, at 3:07 PM, Marton Balint  wrote:

On Mon, 16 Oct 2017, Dave Rice wrote:


Hi,

I tested this with my Ultrastudio Express and confirmed that I'm getting higher 
bit depth recordings with the abitscope filter. This patch adds an option to 
get 32 bit audio as an input with the decklink device (beforehand only 16 bit 
audio was supported). This resolves http://trac.ffmpeg.org/ticket/6708 and is 
partly based upon Georg Lippitisch's earlier draft at 
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.


From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Thu, 12 Oct 2017 13:40:59 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support

Partially based upon Georg Lippitsch's patch at 
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
---
libavdevice/decklink_common.h   |  1 +
libavdevice/decklink_common_c.h |  1 +
libavdevice/decklink_dec.cpp| 17 ++---
libavdevice/decklink_dec_c.c|  1 +
4 files changed, 17 insertions(+), 3 deletions(-)


Missing docs/indevs.texi update and libavdevice micro bump.


Updated.


Thanks, applied.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: always init output stream before reaping filters

2017-10-18 Thread Marton Balint




On Thu, 12 Oct 2017, Marton Balint wrote:




On Sun, 8 Oct 2017, Marton Balint wrote:




On Sat, 7 Oct 2017, Hendrik Leppkes wrote:


On Wed, Oct 4, 2017 at 12:48 AM, Marton Balint  wrote:

Otherwise the frame size of the codec is not set in the buffersink.

Fixes ticket #6603 and the following simpler case:

ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac

Signed-off-by: Marton Balint 
---
 fftools/ffmpeg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1d248bc269..5be8788ea8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4528,6 +4528,15 @@ static int transcode_step(void)
 }

 if (ost->filter && ost->filter->graph->graph) {
+if (!ost->initialized) {
+char error[1024] = {0};
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error initializing output 

stream %d:%d -- %s\n",

+   ost->file_index, ost->index, error);
+exit_program(1);
+}
+}
 if ((ret = transcode_from_filter(ost->filter->graph, &ist)) < 0)
 return ret;
 if (!ist)


Doesn't this basically void all the work that was done to get proper
output frame information before initializing the output, so its
created with the proper info at all times?


To be frank, I am not entirely sure. Fate passes, so this can't be that 
bad. The original patch that caused the regression is 
af1761f7b5b1b72197dc40934953b775c2d951cc which in the commit message only 
mentions the delayed initialization of filters, this patch keeps that.




Will push this soon.



Pushed. Might make sense to backport this before making 3.4.1 if it does 
not cause any issues in git master until then.


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

[FFmpeg-devel] [PATCH 1/2] fate: add fate test for ticket #6603

2017-10-18 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 tests/fate/ffmpeg.mak  |  4 
 tests/ref/fate/ffmpeg-filter_complex_audio | 10 ++
 2 files changed, 14 insertions(+)
 create mode 100644 tests/ref/fate/ffmpeg-filter_complex_audio

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index d8f2e71590..8c25c8237f 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -26,6 +26,10 @@ fate-mapchan: $(FATE_MAPCHAN)
 FATE_FFMPEG-$(CONFIG_COLOR_FILTER) += fate-ffmpeg-filter_complex
 fate-ffmpeg-filter_complex: CMD = framecrc -filter_complex color=d=1:r=5 
-fflags +bitexact
 
+# Ticket 6603
+FATE_FFMPEG-$(call ALLYES, AEVALSRC_FILTER ASETNSAMPLES_FILTER 
AC3_FIXED_ENCODER) += fate-ffmpeg-filter_complex_audio
+fate-ffmpeg-filter_complex_audio: CMD = framecrc -filter_complex 
"aevalsrc=0:d=0.1,asetnsamples=1537" -c ac3_fixed
+
 FATE_SAMPLES_FFMPEG-$(CONFIG_COLORKEY_FILTER) += fate-ffmpeg-filter_colorkey
 fate-ffmpeg-filter_colorkey: tests/data/filtergraphs/colorkey
 fate-ffmpeg-filter_colorkey: CMD = framecrc -idct simple -fflags +bitexact 
-flags +bitexact  -sws_flags +accurate_rnd+bitexact -i 
$(TARGET_SAMPLES)/cavs/cavs.mpg -fflags +bitexact -flags +bitexact -sws_flags 
+accurate_rnd+bitexact -i $(TARGET_SAMPLES)/lena.pnm -an -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/colorkey -sws_flags 
+accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -qscale 2 -frames:v 10
diff --git a/tests/ref/fate/ffmpeg-filter_complex_audio 
b/tests/ref/fate/ffmpeg-filter_complex_audio
new file mode 100644
index 00..c424675061
--- /dev/null
+++ b/tests/ref/fate/ffmpeg-filter_complex_audio
@@ -0,0 +1,10 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: ac3
+#sample_rate 0: 44100
+#channel_layout 0: 4
+#channel_layout_name 0: mono
+0,   -256,   -256, 1536,  416, 0x3001fb2d
+0,   1280,   1280, 1536,  418, 0xba72fc16
+0,   2816,   2816, 1536,  418, 0xba72fc16
+0,   4352,   4352, 1536,  418, 0xba72fc16
-- 
2.13.6

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

[FFmpeg-devel] [PATCH 2/2] fate: add fate test for ticket #6375

2017-10-18 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 tests/fate/ffmpeg.mak   |   4 +
 tests/ref/fate/ffmpeg-attached_pics | 141 
 2 files changed, 145 insertions(+)
 create mode 100644 tests/ref/fate/ffmpeg-attached_pics

diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak
index 8c25c8237f..607cc79649 100644
--- a/tests/fate/ffmpeg.mak
+++ b/tests/fate/ffmpeg.mak
@@ -30,6 +30,10 @@ fate-ffmpeg-filter_complex: CMD = framecrc -filter_complex 
color=d=1:r=5 -fflags
 FATE_FFMPEG-$(call ALLYES, AEVALSRC_FILTER ASETNSAMPLES_FILTER 
AC3_FIXED_ENCODER) += fate-ffmpeg-filter_complex_audio
 fate-ffmpeg-filter_complex_audio: CMD = framecrc -filter_complex 
"aevalsrc=0:d=0.1,asetnsamples=1537" -c ac3_fixed
 
+# Ticket 6375
+FATE_SAMPLES_FFMPEG-$(call ALLYES, MOV_DEMUXER ALAC_DECODER ALAC_ENCODER) += 
fate-ffmpeg-attached_pics
+fate-ffmpeg-attached_pics: CMD = threads=2 framecrc -i 
$(TARGET_SAMPLES)/lossless-audio/inside.m4a -acodec alac -max_muxing_queue_size 
16
+
 FATE_SAMPLES_FFMPEG-$(CONFIG_COLORKEY_FILTER) += fate-ffmpeg-filter_colorkey
 fate-ffmpeg-filter_colorkey: tests/data/filtergraphs/colorkey
 fate-ffmpeg-filter_colorkey: CMD = framecrc -idct simple -fflags +bitexact 
-flags +bitexact  -sws_flags +accurate_rnd+bitexact -i 
$(TARGET_SAMPLES)/cavs/cavs.mpg -fflags +bitexact -flags +bitexact -sws_flags 
+accurate_rnd+bitexact -i $(TARGET_SAMPLES)/lena.pnm -an -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/colorkey -sws_flags 
+accurate_rnd+bitexact -fflags +bitexact -flags +bitexact -qscale 2 -frames:v 10
diff --git a/tests/ref/fate/ffmpeg-attached_pics 
b/tests/ref/fate/ffmpeg-attached_pics
new file mode 100644
index 00..3a0f151819
--- /dev/null
+++ b/tests/ref/fate/ffmpeg-attached_pics
@@ -0,0 +1,141 @@
+#extradata 1:   36, 0x45f80468
+#tb 0: 1/9
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 200x200
+#sar 0: 2834/2834
+#tb 1: 1/44100
+#media_type 1: audio
+#codec_id 1: alac
+#sample_rate 1: 44100
+#channel_layout 1: 3
+#channel_layout_name 1: stereo
+0,  0,  0,0,   12, 0x748cc771
+1,  0,  0, 4096,   32, 0x204b0676
+1,   4096,   4096, 4096, 5826, 0x56583236
+1,   8192,   8192, 4096, 5532, 0x5f047492
+1,  12288,  12288, 4096, 5245, 0xaa3f1897
+1,  16384,  16384, 4096, 4782, 0x392f3ac3
+1,  20480,  20480, 4096, 4602, 0x9bd6ffad
+1,  24576,  24576, 4096, 4357, 0x5df6530b
+1,  28672,  28672, 4096, 7443, 0x38ce542b
+1,  32768,  32768, 4096, 5803, 0x196ae519
+1,  36864,  36864, 4096, 5619, 0xd436cd94
+1,  40960,  40960, 4096, 4896, 0x42df7109
+1,  45056,  45056, 4096, 4755, 0xfbfdfd5f
+1,  49152,  49152, 4096, 4597, 0x93f3ce66
+1,  53248,  53248, 4096, , 0x56ffe620
+1,  57344,  57344, 4096, 5498, 0xa0865dc8
+1,  61440,  61440, 4096, 5343, 0x42134619
+1,  65536,  65536, 4096, 6261, 0xd60d1379
+1,  69632,  69632, 4096, 4496, 0x0eb49c68
+1,  73728,  73728, 4096, 4336, 0x21d541bd
+1,  77824,  77824, 4096, 8395, 0x02030a38
+1,  81920,  81920, 4096, 8174, 0x47bdb71d
+1,  86016,  86016, 4096, 7434, 0x2304318e
+1,  90112,  90112, 4096, 7619, 0x80e6a037
+1,  94208,  94208, 4096, 6086, 0xd3438d2f
+1,  98304,  98304, 4096, 6075, 0xd6019fbf
+1, 102400, 102400, 4096, 9597, 0x28f46a38
+1, 106496, 106496, 4096,10287, 0x9dbf0938
+1, 110592, 110592, 4096,10537, 0xc417fb81
+1, 114688, 114688, 4096,10360, 0xc580caa3
+1, 118784, 118784, 4096, 9778, 0xb9c2d3e5
+1, 122880, 122880, 4096,10307, 0x05b1b271
+1, 126976, 126976, 4096,11289, 0x97f07c63
+1, 131072, 131072, 4096,11561, 0x8a45194a
+1, 135168, 135168, 4096,11327, 0x86587829
+1, 139264, 139264, 4096,11347, 0x15659d6e
+1, 143360, 143360, 4096,11006, 0x9a002c7f
+1, 147456, 147456, 4096,11147, 0x853955e0
+1, 151552, 151552, 4096,11025, 0x7bdafbda
+1, 155648, 155648, 4096,11561, 0x2ec43d86
+1, 159744, 159744, 4096,11329, 0x6eaba39a
+1, 163840, 163840, 4096,10886, 0x5c31b777
+1, 167936, 167936, 4096,11505, 0xcd7f2b9a
+1, 172032, 172032, 4096,11243, 0xa1cb6c83
+1, 176128, 176128, 4096,11718, 0x5b0d6e74
+1, 180224, 180224, 4096,11898, 0xa649ca9a
+1, 184320, 184320, 4096,11358, 0x037bc2f4
+1, 188416, 188416, 4096,10864, 0x9239d22f
+1, 192512, 192512, 4096,12181, 0xd5c24fba
+1, 196608, 196608, 4096,

Re: [FFmpeg-devel] decklink 24/32 bit question

2017-10-18 Thread Douglas Marsh


On 2017-10-17 12:44, Devin Heitmueller wrote:


The decklink sdk only defines two BMDAudioSampleType values: 
bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I 
don't think there's an easy way to support a 24 bit input here. 
Generally in this case I've used bmdAudioSampleType32bitInteger and 
then encode it at pcm_s24le.

Dave Rice


For what it’s worth, I’ve got deinterleaving code in the works to
handle capture of multiple pairs of audio (i.e. break 16 channels into
8 pairs and announce them as separate S16LE streams).  If we really
thought 24-bit was desirable, that code could be adjusted accordingly
(the hardware would still capture 32-bit, but the deinterleaver would
put out S24LE).



I am not really sure I follow. I am not sure supporting 24-bit is a big 
issue. A sample size of 32-bit should work fine for most folks. I can 
only think of people (in the output stream) converting to 24-bits (via 
truncate or dither*) to save disk space or pre-processing for some other 
step [compression] (but video is really the bit-hog). I only mentioned 
24-bits because the ADC/DACs are mentioned at supporting PCM 24-bits 
natively meaning the PCI card is (assuming) padding the LSB (hence 
truncate is more logical for any conversion 32->24). AS for what comes 
in digitally over SDI or HDMI is too assumed to only support PCM 24-bits 
(but it is subject to standards that can update).


Making the workflow (stream capturing) of 32-bits is simpler, and moving 
any bit-depth conversion to the output stream side. Only concerns would 
be CPU processing (of which truncating bits is very fast and logical due 
to the assumed padding).


--Doug (dx9s)

*dither= I am not aware of any audio bit-depth dithering algorithms in 
FFMPEG, however it would make sense they do exist as this software is 
quite simply an amazing 'swiss-army knife'



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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Niedermayer

On Wed, Oct 18, 2017 at 12:46:13PM -0700, Michael Bradshaw wrote:
> Thanks for the review!
> 
> On Wed, Oct 18, 2017 at 12:26 PM, James Almer  wrote:
> >
> > Add a line to Changelog about dropping support for OpenJPEG <= 2.0.
> >
> 
> Done.
> 
> > +enabled libopenjpeg   && require_pkg_config libopenjpeg libopenjp2
> > openjpeg.h opj_version
> >
> > OpenJPEG 2.0.1 ships a pkg-config file, so change the second argument to
> > "libopenjp2 >= 2.1.0".
> >
> 
> Thanks for catching that; I didn't realize 2.0.1 included pkg-config
> support. Fixed.
> 
> Aside from that LGTM. It's nice to see all the bloat gone and every
> > future 2.x version being supported without further changes from now on.
> 
> 
> Yeah, I look forward to the decreased maintenance costs!
> 
> Attached is an updated patch with the requested changes to configure and
> Changelog. I plan on pushing this in a few hours (unless, of course, there
> are additional critiques).

>  Changelog   |2 
>  configure   |   16 
>  libavcodec/libopenjpegdec.c |  103 +
>  libavcodec/libopenjpegenc.c |  156 
> +++-
>  4 files changed, 34 insertions(+), 243 deletions(-)
> e3a7a5c8ebe0d5c0b0eb92c0e61871ab5e9e285e  
> 0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch
> From fb8334d0cecc889ebce3af968c56a3afbd2f6047 Mon Sep 17 00:00:00 2001
> From: Michael Bradshaw 
> Date: Wed, 18 Oct 2017 11:34:06 -0700
> Subject: [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
> 
> We now require 2.1+ with pkg-config.

This drops support for all ubuntu versions, there seems to be no
openjpeg above 1.5 in there

https://packages.ubuntu.com/search?keywords=openjpeg&searchon=names&suite=all§ion=all
from Package openjpeg-tools, the others are spread over multiple package names
trusty (14.04LTS) (graphics): command-line tools using the JPEG 2000 
library [universe]
1.3+dfsg-4.7ubuntu1: amd64 arm64 armhf i386 powerpc ppc64el
xenial (16.04LTS) (graphics): command-line tools using the JPEG 2000 
library [universe]
1:1.5.2-3.1: amd64 arm64 armhf i386 powerpc ppc64el s390x
zesty (graphics): command-line tools using the JPEG 2000 library [universe]
1:1.5.2-3.1 [ports]: powerpc

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Niedermayer

On Wed, Oct 18, 2017 at 10:22:13PM +0200, Michael Niedermayer wrote:
> On Wed, Oct 18, 2017 at 12:46:13PM -0700, Michael Bradshaw wrote:
> > Thanks for the review!
> > 
> > On Wed, Oct 18, 2017 at 12:26 PM, James Almer  wrote:
> > >
> > > Add a line to Changelog about dropping support for OpenJPEG <= 2.0.
> > >
> > 
> > Done.
> > 
> > > +enabled libopenjpeg   && require_pkg_config libopenjpeg libopenjp2
> > > openjpeg.h opj_version
> > >
> > > OpenJPEG 2.0.1 ships a pkg-config file, so change the second argument to
> > > "libopenjp2 >= 2.1.0".
> > >
> > 
> > Thanks for catching that; I didn't realize 2.0.1 included pkg-config
> > support. Fixed.
> > 
> > Aside from that LGTM. It's nice to see all the bloat gone and every
> > > future 2.x version being supported without further changes from now on.
> > 
> > 
> > Yeah, I look forward to the decreased maintenance costs!
> > 
> > Attached is an updated patch with the requested changes to configure and
> > Changelog. I plan on pushing this in a few hours (unless, of course, there
> > are additional critiques).
> 
> >  Changelog   |2 
> >  configure   |   16 
> >  libavcodec/libopenjpegdec.c |  103 +
> >  libavcodec/libopenjpegenc.c |  156 
> > +++-
> >  4 files changed, 34 insertions(+), 243 deletions(-)
> > e3a7a5c8ebe0d5c0b0eb92c0e61871ab5e9e285e  
> > 0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch
> > From fb8334d0cecc889ebce3af968c56a3afbd2f6047 Mon Sep 17 00:00:00 2001
> > From: Michael Bradshaw 
> > Date: Wed, 18 Oct 2017 11:34:06 -0700
> > Subject: [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
> > 
> > We now require 2.1+ with pkg-config.
> 
> This drops support for all ubuntu versions, there seems to be no
> openjpeg above 1.5 in there
> 
> https://packages.ubuntu.com/search?keywords=openjpeg&searchon=names&suite=all§ion=all
> from Package openjpeg-tools, the others are spread over multiple package names
> trusty (14.04LTS) (graphics): command-line tools using the JPEG 2000 
> library [universe]
> 1.3+dfsg-4.7ubuntu1: amd64 arm64 armhf i386 powerpc ppc64el
> xenial (16.04LTS) (graphics): command-line tools using the JPEG 2000 
> library [universe]
> 1:1.5.2-3.1: amd64 arm64 armhf i386 powerpc ppc64el s390x
> zesty (graphics): command-line tools using the JPEG 2000 library 
> [universe]
> 1:1.5.2-3.1 [ports]: powerpc

correction, xenial and zesty have 2.1.* under the name libopenjp2-7

trusty does not though

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] decklink 24/32 bit question

2017-10-18 Thread Devin Heitmueller

Hi Doug,

> On Oct 18, 2017, at 4:15 PM, Douglas Marsh  wrote:
> 
> I am not really sure I follow. I am not sure supporting 24-bit is a big 
> issue. A sample size of 32-bit should work fine for most folks. I can only 
> think of people (in the output stream) converting to 24-bits (via truncate or 
> dither*) to save disk space or pre-processing for some other step 
> [compression] (but video is really the bit-hog). I only mentioned 24-bits 
> because the ADC/DACs are mentioned at supporting PCM 24-bits natively meaning 
> the PCI card is (assuming) padding the LSB (hence truncate is more logical 
> for any conversion 32->24). AS for what comes in digitally over SDI or HDMI 
> is too assumed to only support PCM 24-bits (but it is subject to standards 
> that can update).
> 
> Making the workflow (stream capturing) of 32-bits is simpler, and moving any 
> bit-depth conversion to the output stream side. Only concerns would be CPU 
> processing (of which truncating bits is very fast and logical due to the 
> assumed padding).

I think you and I are on the same page.  It wasn't clear to me what would 
prompt someone to say they want 24-bit audio as opposed to 32 (which is way 
easier to work with because of alignment).  That said, if you had such a use 
case I think this could be done.

That said, I'm all about not adding functionality nobody cares about.

Thanks for adding this functionality, as I need it to reliably do compressed 
audio detection (which is next on my list after support for multi-channel audio 
is working).

Devin

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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Bradshaw

On Wed, Oct 18, 2017 at 1:26 PM, Michael Niedermayer  wrote:
>
> correction, xenial and zesty have 2.1.* under the name libopenjp2-7
>
> trusty does not though

Yeah, Ubuntu 14.04 is stuck on the ancient OpenJPEG 1.3. I think it's fine
to proceed with this patch since:

1) OpenJPEG 1.3 sets AV_CODEC_CAP_EXPERIMENTAL[1], so support for it was
already kinda experimental.
2) This doesn't impact old versions of ffmpeg. If people are building
ffmpeg 3.5+ on Ubuntu 14.04 on their own, then they can also build OpenJPEG
2.1+ on their own.

[1]: https://github.com/FFmpeg/FFmpeg/blob/master/
libavcodec/libopenjpegdec.c#L575
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread James Almer

On 10/18/2017 5:46 PM, Michael Bradshaw wrote:
> On Wed, Oct 18, 2017 at 1:26 PM, Michael Niedermayer > wrote:
>>
>> correction, xenial and zesty have 2.1.* under the name libopenjp2-7
>>
>> trusty does not though
> 
> 
> Yeah, Ubuntu 14.04 is stuck on the ancient OpenJPEG 1.3. I think it's fine
> to proceed with this patch since:
> 
> 1) OpenJPEG 1.3 sets AV_CODEC_CAP_EXPERIMENTAL[1], so support for it was
> already kinda experimental.
> 2) This doesn't impact old versions of ffmpeg. If people are building
> ffmpeg 3.5+ on Ubuntu 14.04 on their own, then they can also build OpenJPEG
> 2.1+ on their own.

+1

Also, ffmpeg is not in Trusty, so you have to build it yourself
regardless of version to use it there.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add more beep options to sine asrc

2017-10-18 Thread Michael Bradshaw

Sorry for the long delay in my response!

On Sun, Oct 8, 2017 at 11:14 AM, Nicolas George  wrote:
>
> Le quintidi 15 vendémiaire, an CCXXVI, Michael Bradshaw a écrit :
> > +OPT_DBL("beep_delay",beep_delay, 0, 0,
> DBL_MAX,   "set the delay for the first beep",),
> > +OPT_DBL("beep_period",   beep_period_opt,1, DBL_MIN,
> DBL_MAX, "set the gap between beeps",),
> > +OPT_DBL("beep_duration", beep_duration,   0.04, DBL_MIN,
> DBL_MAX, "set the duration of a beep",),
>
> I think these should use OPT_DUR / AV_OPT_TYPE_DURATION rather than
> doubles. Also, DBL_MIN seems strange: I do not think a negative value
> makes sense.
>

Fixed. DBL_MIN is actually positive. I use it to prevent the user from
setting the beep period or duration to 0. But I've changed it to now use 1.

>  OPT_INT("sample_rate",   sample_rate,44100, 1, INT_MAX,
>  "set the sample rate",),
> >  OPT_INT("r", sample_rate,44100, 1,
> INT_MAX,   "set the sample rate",),
> >  OPT_DUR("duration",  duration,   0, 0,
> INT64_MAX, "set the audio duration",),
> > @@ -152,10 +158,13 @@ static av_cold int init(AVFilterContext *ctx)
> >  make_sin_table(sine->sin);
> >
> >  if (sine->beep_factor) {
> > -sine->beep_period = sine->sample_rate;
> > -sine->beep_length = sine->beep_period / 25;
> > -sine->dphi_beep = ldexp(sine->beep_factor * sine->frequency,
> 32) /
> > -  sine->sample_rate + 0.5;
> > +unsigned beep_start = sine->beep_delay * sine->sample_rate;
> > +double beep_frequency = (sine->frequency ? sine->frequency :
> 1.0) *
> > +sine->beep_factor;
>
> > +sine->beep_period = sine->beep_period_opt * sine->sample_rate;
>
> With integer durations, av_rescale() would be better.
>

Fixed.

> +sine->beep_index = (sine->beep_period - beep_start) %
> sine->beep_period;
>
> I think this will produce strange results if beep_start is greater than
> beep_period. Maybe document the limitation, or adjust the arithmetic.


Good point. I fixed the arithmetic so now the beep_start can be greater
than the beep_period.

Attached is an updated patch.


0001-lavf-add-more-beep-options-to-sine-asrc.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Reino Wijnsma

On 18-10-2017 21:46, Michael Bradshaw 
wrote:
> From fb8334d0cecc889ebce3af968c56a3afbd2f6047 Mon Sep 17 00:00:00 2001
> From: Michael Bradshaw 
> Date: Wed, 18 Oct 2017 11:34:06 -0700
> Subject: [PATCH] lavc: drop support for OpenJPEG 1.3-2.0
>
> We now require 2.1+ with pkg-config.
>
> Signed-off-by: Michael Bradshaw 
> ---
>  Changelog   |   2 +
>  configure   |  16 +
>  libavcodec/libopenjpegdec.c | 103 ++---
>  libavcodec/libopenjpegenc.c | 156 
> +++-
>  4 files changed, 34 insertions(+), 243 deletions(-)
> [...]
> -enabled libopenjpeg   && { { check_lib libopenjpeg 
> openjpeg-2.3/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   check_lib libopenjpeg openjpeg-2.3/openjpeg.h 
> opj_version -lopenjp2 ||
> -   { check_lib libopenjpeg 
> openjpeg-2.2/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   check_lib libopenjpeg openjpeg-2.2/openjpeg.h 
> opj_version -lopenjp2 ||
> -   { check_lib libopenjpeg 
> openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   check_lib libopenjpeg openjpeg-2.1/openjpeg.h 
> opj_version -lopenjp2 ||
> -   { check_lib libopenjpeg 
> openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   { check_lib libopenjpeg 
> openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags 
> -DOPJ_STATIC; } ||
> -   { check_lib libopenjpeg openjpeg.h 
> opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
> -   die "ERROR: libopenjpeg not found"; }
> +enabled libopenjpeg   && require_pkg_config libopenjpeg "libopenjp2 >= 
> 2.1.0" openjpeg.h opj_version
Is there a reason you left out -DOPJ_STATIC?
'openjpeg_git/src/lib/openjp2/libopenjp2.pc.cmake.in' doesn't put it in.
With this patch ./configure therefor fails over here with:
"test.o:test.c:(.text+0x1): undefined reference to `_imp__opj_version@0'".

enabled libopenjpeg   && require_pkg_config libopenjpeg "libopenjp2
>= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC

This line fixes that.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Bradshaw

On Wed, Oct 18, 2017 at 2:44 PM, Reino Wijnsma  wrote:
>
> Is there a reason you left out -DOPJ_STATIC?
>

I assumed OpenJPEG's pkgconfig file would be smart enough to add it in if
needed. Apparently that's not the case. Dang.

'openjpeg_git/src/lib/openjp2/libopenjp2.pc.cmake.in' doesn't put it in.
> With this patch ./configure therefor fails over here with:
> "test.o:test.c:(.text+0x1): undefined reference to `_imp__opj_version@0'".
>
> enabled libopenjpeg   && require_pkg_config libopenjpeg "libopenjp2
> >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC
>
> This line fixes that.

-DOPJ_STATIC was originally added to ffmpeg's configure script for Windows.
Unconditionally adding -DOPJ_STATIC would conflict with people who are
dynamically linking. I'll look into this further. I'll start with the
following:

enabled libopenjpeg   && {{require_pkg_config libopenjpeg "libopenjp2
>= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
-DOPJ_STATIC;} ||
  require_pkg_config libopenjpeg "libopenjp2 >=
2.1.0" openjpeg.h opj_version;}

and see if it works for both static and dynamic builds of OpenJPEG.
Unfortunately, I don't have a Windows system to test on, so if anyone can
validate the above on Windows I'd appreciate it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

2017-10-18 Thread Deron


On 10/18/17 1:31 PM, Devin Heitmueller wrote:

On Oct 6, 2017, at 12:56 PM, Devin Heitmueller  
wrote:

From: Devin Heitmueller 

Hook in libklvanc and use it for output of EIA-708 captions over
SDI.  The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.

Libklvanc can be found at: https://github.com/stoth68000/libklvanc

Signed-off-by: Devin Heitmueller 

Any additional technical comments related to this patch, or should I resubmit 
for merge?

Devin


I was going to actually test this with some old broadcast equipment I 
have just dying for a purpose, but I don't see how to generate 
AV_PKT_DATA_A53_CC side packet data except using the Decklink capture. I 
have A53 documentation, but it just refers to CEA-708 (or SMPTE 334, or 
... what an unraveling ball of yarn it is. Looks like I could spend a 
months income on standards just trying to learn how this is encoded).


On a side note, can AV_PKT_DATA_A53_CC be used for something besides 
CEA-708? Not sure I understand the line between A53 CC encoding (which 
is at least in part what this generates, right?) and CEA-708 (which is 
what this takes, right?) and why this side data is called A53_CC?


I know these questions are outside the scope that you were asking...

Deron

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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread James Almer

On 10/18/2017 6:56 PM, Michael Bradshaw wrote:
> -DOPJ_STATIC was originally added to ffmpeg's configure script for Windows.
> Unconditionally adding -DOPJ_STATIC would conflict with people who are
> dynamically linking. I'll look into this further. I'll start with the
> following:
> 
> enabled libopenjpeg   && {{require_pkg_config libopenjpeg "libopenjp2
>> = 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
> -DOPJ_STATIC;} ||
>   require_pkg_config libopenjpeg "libopenjp2 >=
> 2.1.0" openjpeg.h opj_version;}
> 
> and see if it works for both static and dynamic builds of OpenJPEG.
> Unfortunately, I don't have a Windows system to test on, so if anyone can
> validate the above on Windows I'd appreciate it.

I have a Windows system. With a shared version of OpenJPEG the configure
check seems to succeed with and without -DOPJ_STATIC, but with a static
version it only succeed with it.
Ideally, pkg-config would have something like a "Cflags.private" field,
but it for some reason doesn't, so it's up to us to handle this.

It think the following should be enough:

> enabled libopenjpeg   && { use_pkg_config libopenjpeg "libopenjp2 >= 
> 2.1.0" openjpeg.h opj_version ||
>{ require_pkg_config libopenjpeg "libopenjp2 
> >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } 
> }

To make sure -DOPJ_STATIC is not used unless strictly necessary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

2017-10-18 Thread Devin Heitmueller

Hi Deron,

> I was going to actually test this with some old broadcast equipment I have 
> just dying for a purpose, but I don't see how to generate AV_PKT_DATA_A53_CC 
> side packet data except using the Decklink capture. I have A53 documentation, 
> but it just refers to CEA-708 (or SMPTE 334, or ... what an unraveling ball 
> of yarn it is. Looks like I could spend a months income on standards just 
> trying to learn how this is encoded).

Yeah.  You could certainly spend a good bit of cash if you had to buy the 
individual specs.  Worth noting that the ATSC specs are freely available though 
on their website, and the CEA-708 is largely described in the FCC specification 
(not a substitute for the real thing, but good enough for the casual reader).  
SMPTE has a “digital library” where you can get access to *all* their specs 
with a subscription of around $600/year.  It’s not ideal for a 
non-professional, but for people who *need* the specs it’s way cheaper than 
buying them piecemeal for $120/spec.

> 
> On a side note, can AV_PKT_DATA_A53_CC be used for something besides CEA-708? 
> Not sure I understand the line between A53 CC encoding (which is at least in 
> part what this generates, right?) and CEA-708 (which is what this takes, 
> right?) and why this side data is called A53_CC?
> 
> I know these questions are outside the scope that you were asking…
> 
No problem.  I should really write a primer on this stuff since there are a 
whole bunch of specs which are inter-related.  Briefly….

CEA-708 is what non-technical people typically consider to be “digital closed 
captions”.  They represent the standard that replaces old fashioned NTSC closed 
captions, which were described in EIA/CEA-608.  The spec describes what could 
be characterized as a protocol stack of functionality, including transport 
through presentation layers (i.e. how the captions are constructed, rules for 
how to render them on-screen, etc).  

CEA-708 also includes a construct for tunneling old CEA-608 packets.  In fact, 
most CEA-708 streams are really just up-converted from CEA-608, since the FCC 
requires both to be supported and 608 is a subset in functionality of 708.  On 
the other hand, you can’t typically down convert 708 to 608 since there are a 
bunch of formatting codes in 708 which have no corresponding capability in 608. 
 If you’re using VLC or most other applications, they will claim to render 708 
captions, but they’re really just rendering the 608 captions contained in 708.

One component of the CEA-708 spec describes a “CDP”, which is “Caption 
Distribution Packet”.  This is a low-level packet format which includes not 
just multiple caption streams but also timecodes and service data (e.g. caption 
languages, etc).  CDP packets can be sent over a number of different physical 
transports, including old-fashioned serial ports.

SMPTE 334M describes how to transport CEA-708 CDP packets over an SDI link in 
the VANC area of the frame.

A53 refers to the ATSC A/53 specification, which basically refers to how 
digital TV is transmitted over-the-air.  One part of that spec includes how to 
embed CEA-708 captions into an MPEG2 transport stream.  The A/53 spec basically 
says how to embed the CEA-708 caption bytes into an MPEG-2 stream, and then 
refers you to CEA-708 for the details of what to do with those bytes.

Both the CEA-708 CDP format and A/53 come down to a series of three byte 
packets which contain the actual captioning data.  This corresponds to what is 
being serialized in AV_PKT_DATA_A53_CC.  In order to encode an SDI feed into an 
MPEG-2 stream, you would need to deconstruct the CDP, extract the captioning 
bytes, and load them into the side data packet.  Once that’s done, the avpacket 
is handed off to an H.264/MPEG-2 video encoder, which knows how to take those 
captioning bytes and embed them into the compressed video (using the MPEG-2 
user_data field if it’s MPEG-2 video, or the SEI field if it’s H.264).

That series of three-byte packets is essentially the “lowest common 
denominator” representing the captioning data (assuming you only care about 
closed captions and not timecodes or service info).  I have use cases where 
this stuff should really be preserved, and am weighing the merits of 
introducing a new side data format for the CDP which preserves all the info, 
and then encoders can extract what they need.  There are plusses/minuses to 
this approach and it’s still under consideration.

I hope that gives you a bit more background.

Cheers,

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

2017-10-18 Thread Thilo Borgmann

Am 18.10.17 um 16:02 schrieb Compn:
> On Wed, 4 Oct 2017 11:34:18 +0200, wm4  wrote:
> 
>>> more so, opaque_ref is used in only 5 lines in the whole codebase,
>>> so there is not much code to consider when using a different solution
>>
>> We shouldn't add such special fields, we have enough hacks already. Is
>> that your only suggestion how to do this? Because it's a bad one.
> 
> michael, do you have other suggestions how to solve this problem? are
> you going to fix the errors in the doxygen that you noticed due to
> merges?
> 
> wm4, would you object to adding another special field? if
> someone else edited this and made a patch?

If the two of you could agree on an alternate, suitable approach, I could offer
to do the codemonkey's work like compn suggested. However, I still lack some
knowledge about API and HWACCEL which would result in certain inefficiency in
doing so. OTOH this comes along with a nonbiased perspective which might be a
positive thing here.

I'd appreciate it if anyone else would be willing to commit some coding to a
solution, though. I am not eager to do it but I can if we stall completely
otherwise.

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

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

2017-10-18 Thread Dave Rice


> On Oct 6, 2017, at 5:31 PM, Devin Heitmueller  
> wrote:
> 
>> Sorry, what I meant was:
>> Nothing inside FFmpeg except the decklink device could use
>> VANC?
> 
> Ah, I understand now.
> 
> Yes, the decklink device is currently the only SDI device which is supported 
> by libavdevice.  I’ve got a whole pile of patches coming which add support 
> for a variety of protocols for both capture and output (e.g. EIA-708, 
> SCTE-104, AFD, SMPTE 2038, etc).  But today the decklink module is the only 
> device supported.
> 
> Would love to see more SDI devices supported and potentially interested in 
> adding such support myself if we can find good candidates.  The DVEO/linsys 
> cards are largely obsolete and the AJA boards are significantly more 
> expensive than any of BlackMagic’s cards.  If anyone has good experiences 
> with other vendors I would like to hear about it (and there may be an 
> opportunity to extend libavdevice to support another SDI vendor).

The President of AJA has publicly stated an intent to add an open license to 
their SDK, https://twitter.com/ajaprez/status/910100436224499713 
. I’m glad to hear that 
handling other VANC data is in the works, I’m particularly interested in VITC 
and EIA-608 with inputs.

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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Reino Wijnsma

On 19-10-2017 0:22, James Almer  wrote:
> It think the following should be enough:
>> enabled libopenjpeg   && { use_pkg_config libopenjpeg "libopenjp2 >= 
>> 2.1.0" openjpeg.h opj_version ||
>>{ require_pkg_config libopenjpeg "libopenjp2 
>> >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; 
>> } }
> To make sure -DOPJ_STATIC is not used unless strictly necessary.

Works overhere. No errors.

A bit off-topic, but can you explain to me why you (FFmpeg developers)
/have/ added -DOPJ_STATIC to libopenjpeg in the past, but /haven't/
added -DCACA_STATIC, -DMODPLUG_STATIC and -DLIBTWOLAME_STATIC to
libcaca, libmodplug and libtwolame?

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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Ricardo Constantino

On 18 October 2017 at 23:22, James Almer  wrote:

> On 10/18/2017 6:56 PM, Michael Bradshaw wrote:
> > -DOPJ_STATIC was originally added to ffmpeg's configure script for
> Windows.
> > Unconditionally adding -DOPJ_STATIC would conflict with people who are
> > dynamically linking. I'll look into this further. I'll start with the
> > following:
> >
> > enabled libopenjpeg   && {{require_pkg_config libopenjpeg "libopenjp2
> >> = 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
> > -DOPJ_STATIC;} ||
> >   require_pkg_config libopenjpeg "libopenjp2
> >=
> > 2.1.0" openjpeg.h opj_version;}
> >
> > and see if it works for both static and dynamic builds of OpenJPEG.
> > Unfortunately, I don't have a Windows system to test on, so if anyone can
> > validate the above on Windows I'd appreciate it.
>
> I have a Windows system. With a shared version of OpenJPEG the configure
> check seems to succeed with and without -DOPJ_STATIC, but with a static
> version it only succeed with it.
> Ideally, pkg-config would have something like a "Cflags.private" field,
> but it for some reason doesn't, so it's up to us to handle this.
>
> It think the following should be enough:
>
> > enabled libopenjpeg   && { use_pkg_config libopenjpeg "libopenjp2 >=
> 2.1.0" openjpeg.h opj_version ||
> >{ require_pkg_config libopenjpeg
> "libopenjp2 >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
> -DOPJ_STATIC; } }
>
> To make sure -DOPJ_STATIC is not used unless strictly necessary.


There's a few other libs that require static-only Cflags (libxml2, at
least), so openjpeg shouldn't be different. pkgconf does support
Cflags.private, but no one uses it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread James Almer

On 10/18/2017 7:49 PM, Reino Wijnsma wrote:
> On 19-10-2017 0:22, James Almer  wrote:
>> It think the following should be enough:
>>> enabled libopenjpeg   && { use_pkg_config libopenjpeg "libopenjp2 >= 
>>> 2.1.0" openjpeg.h opj_version ||
>>>{ require_pkg_config libopenjpeg "libopenjp2 
>>> >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; 
>>> } }
>> To make sure -DOPJ_STATIC is not used unless strictly necessary.
> 
> Works overhere. No errors.
> 
> A bit off-topic, but can you explain to me why you (FFmpeg developers)
> /have/ added -DOPJ_STATIC to libopenjpeg in the past, but /haven't/
> added -DCACA_STATIC, -DMODPLUG_STATIC and -DLIBTWOLAME_STATIC to
> libcaca, libmodplug and libtwolame?

Different developers/maintainers, different amount of users reporting
issues with one library compared to another, etc.

> 
> -- Reino
> ___
> 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] [mov] When both edit list and start padding present, take maximum.

2017-10-18 Thread Sasi Inguva

Thanks for the patch. The bug is because mov_fix_index updates skip_samples
correctly, but not start_pad. Can you instead of taking the max, just
update the mov_fix_index function so that start_pad = skip_samples always.
Something like this
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 899690d920..355e1d09fd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3249,7 +3249,6 @@ static void mov_fix_index(MOVContext *mov, AVStream
*st)
 // Increment skip_samples for the first non-zero
audio edit list
 if (first_non_zero_audio_edit > 0 &&
st->codecpar->codec_id != AV_CODEC_ID_VORBIS) {
 st->skip_samples += frame_duration;
-msc->start_pad = st->skip_samples;
 }
 }
 }
@@ -3324,6 +3323,8 @@ static void mov_fix_index(MOVContext *mov, AVStream
*st)
 // Update av stream length
 st->duration = edit_list_dts_entry_end - start_dts;

+msc->start_pad = st->skip_samples;
+
 // Free the old index and the old CTTS structures
 av_free(e_old);
 av_free(ctts_data_old);


Thanks.

On Mon, Oct 16, 2017 at 2:25 PM, Dale Curtis 
wrote:

> More details on the issue which uncovered this can be seen here
> https://bugs.chromium.org/p/chromium/issues/detail?id=775042#c13
>
> - dale
>
> On Mon, Oct 16, 2017 at 2:22 PM, Dale Curtis 
> wrote:
>
>> Previously the start padding was used to blindly overwrite any skip
>> samples which may have come from an edit list. Instead take the maximum of
>> the two.
>>
>> A new fate test is added, fate-mov-440hz-10ms, to ensure this is handled
>> correctly.
>>
>> The sample can be downloaded and added to the fate-suite from
>>
>> https://cs.chromium.org/chromium/src/third_party/WebKit/
>> LayoutTests/webaudio/resources/media/440hz-10ms.m4a
>>
>> - dale
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread James Almer

On 10/18/2017 7:49 PM, Ricardo Constantino wrote:
> On 18 October 2017 at 23:22, James Almer  wrote:
> 
>> On 10/18/2017 6:56 PM, Michael Bradshaw wrote:
>>> -DOPJ_STATIC was originally added to ffmpeg's configure script for
>> Windows.
>>> Unconditionally adding -DOPJ_STATIC would conflict with people who are
>>> dynamically linking. I'll look into this further. I'll start with the
>>> following:
>>>
>>> enabled libopenjpeg   && {{require_pkg_config libopenjpeg "libopenjp2
 = 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
>>> -DOPJ_STATIC;} ||
>>>   require_pkg_config libopenjpeg "libopenjp2
>>> =
>>> 2.1.0" openjpeg.h opj_version;}
>>>
>>> and see if it works for both static and dynamic builds of OpenJPEG.
>>> Unfortunately, I don't have a Windows system to test on, so if anyone can
>>> validate the above on Windows I'd appreciate it.
>>
>> I have a Windows system. With a shared version of OpenJPEG the configure
>> check seems to succeed with and without -DOPJ_STATIC, but with a static
>> version it only succeed with it.
>> Ideally, pkg-config would have something like a "Cflags.private" field,
>> but it for some reason doesn't, so it's up to us to handle this.
>>
>> It think the following should be enough:
>>
>>> enabled libopenjpeg   && { use_pkg_config libopenjpeg "libopenjp2 >=
>> 2.1.0" openjpeg.h opj_version ||
>>>{ require_pkg_config libopenjpeg
>> "libopenjp2 >= 2.1.0" openjpeg.h opj_version -DOPJ_STATIC && add_cppflags
>> -DOPJ_STATIC; } }
>>
>> To make sure -DOPJ_STATIC is not used unless strictly necessary.
> 
> 
> There's a few other libs that require static-only Cflags (libxml2, at
> least), so openjpeg shouldn't be different. pkgconf does support
> Cflags.private, but no one uses it.

Where did you read it's supported? All the references to
"Cflags.private" i found on google were feature requests, and i just
tried to add such a line to a pkg-config and it was ignored (using
pkg-config 0.29.2).

In any case, openjpeg had checks with this cflag in configure before
this patch. Active maintainers for the wrappers that also need this kind
of cflag should look into adding them to configure (Should be a matter
of doing the same thing i did above).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] When both edit list and start padding present, take maximum.

2017-10-18 Thread Dale Curtis

On Wed, Oct 18, 2017 at 4:00 PM, Sasi Inguva  wrote:

> Thanks for the patch. The bug is because mov_fix_index updates
> skip_samples correctly, but not start_pad. Can you instead of taking the
> max, just update the mov_fix_index function so that start_pad =
> skip_samples always. Something like this
>

Thanks this works. Patch attached.


set_start_pad.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] When both edit list and start padding present, take maximum.

2017-10-18 Thread Sasi Inguva

Patch LGTM. Thanks.

On Wed, Oct 18, 2017 at 4:14 PM, Dale Curtis 
wrote:

> On Wed, Oct 18, 2017 at 4:00 PM, Sasi Inguva  wrote:
>
>> Thanks for the patch. The bug is because mov_fix_index updates
>> skip_samples correctly, but not start_pad. Can you instead of taking the
>> max, just update the mov_fix_index function so that start_pad =
>> skip_samples always. Something like this
>>
>
> Thanks this works. Patch attached.
>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/9] hevc: Fix aligned array declarations

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 10:12:23PM +0100, Mark Thompson wrote:
> (cherry picked from commit d41e10c1485ec34aa342f7bc2e5bf4f9b6e66414)
> ---
> This and the following patches were found with the TI ARM compiler.
> 
> 
>  libavcodec/hevcdsp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

ok

also theres a
DECLARE_ALIGNED(32, int16_t, tmp [MAX_PB_SIZE * MAX_PB_SIZE]);
in libavcodec/hevcdec.h

which seems to have the same issue

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH 2/7] nutdec: Fix repeated condition

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 11:11:54PM +0100, Mark Thompson wrote:
> Fixes #6742.
> ---
>  libavformat/nutdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

ok, also please backport this if this issue was in releases

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Ricardo Constantino

On 19 October 2017 at 00:14, James Almer  wrote:

> On 10/18/2017 7:49 PM, Ricardo Constantino wrote:
>
> > There's a few other libs that require static-only Cflags (libxml2, at
> > least), so openjpeg shouldn't be different. pkgconf does support
> > Cflags.private, but no one uses it.
>
> Where did you read it's supported? All the references to
> "Cflags.private" i found on google were feature requests, and i just
> tried to add such a line to a pkg-config and it was ignored (using
> pkg-config 0.29.2).
>
> In any case, openjpeg had checks with this cflag in configure before
> this patch. Active maintainers for the wrappers that also need this kind
> of cflag should look into adding them to configure (Should be a matter
> of doing the same thing i did above).
>
>
https://github.com/pkgconf/pkgconf not pkg-config.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Niedermayer

On Wed, Oct 18, 2017 at 01:46:59PM -0700, Michael Bradshaw wrote:
> On Wed, Oct 18, 2017 at 1:26 PM, Michael Niedermayer  > wrote:
> >
> > correction, xenial and zesty have 2.1.* under the name libopenjp2-7
> >
> > trusty does not though
> 
> 
> Yeah, Ubuntu 14.04 is stuck on the ancient OpenJPEG 1.3. I think it's fine
> to proceed with this patch since:
> 
> 1) OpenJPEG 1.3 sets AV_CODEC_CAP_EXPERIMENTAL[1], so support for it was
> already kinda experimental.
> 2) This doesn't impact old versions of ffmpeg. If people are building
> ffmpeg 3.5+ on Ubuntu 14.04 on their own, then they can also build OpenJPEG
> 2.1+ on their own.

i think  the patch should add some note to the release notes or
changelog

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 5/7] mxfdec: Fix return value check

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 11:11:57PM +0100, Mark Thompson wrote:
> Move the assignment out of the condition, because that was hiding the error.
> 
> Fixes #6750.
> ---
>  libavformat/mxfdec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

LGTM

thx

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

[FFmpeg-devel] [RFC] v4l2_m2m: Fix races around freeing data on close

2017-10-18 Thread Mark Thompson

Refcount all of the context information.
---
As discussed in the other thread, something like this.  We move most of the 
context into a refcounted buffer and AVCodecContext.priv_data is left as a stub 
holding a reference to it.

Thoughts:
* Change is rather ugly; some structures and function arguments could probably 
be rearranged to improve it.
* Not very well tested - I'm only testing it with the decoder on s5p-mfc.  
(Encoder might well be totally broken.)
* It currently adds an extra atomic to each buffer to keep track of the 
context-references that isn't really wanted.  Cleaning up the per-plane 
references so we only go through the buffer-free sequence once would remove it.

I found several more issues while looking at this (not treated here):
* The refsync process with the semaphore is racy - it will fall over if the 
buffer unrefs are called on multiple threads at the same time.
* Buffers are requeued once for every plane they have as a consequnce of the 
per-plane references (NV12 buffer -> enqueue twice).  The later enqueues are 
ignored by the driver (QBUF returns EINVAL; look at strace), but that should 
probably still be treated as a bug.
* It seems to be able to leak all of the input packets (if refcounted?) - 
valgrind shows this, but I didn't investigate further.

Thanks,

- Mark


 libavcodec/v4l2_buffers.c | 22 +--
 libavcodec/v4l2_buffers.h |  6 ++
 libavcodec/v4l2_m2m.c | 55 ---
 libavcodec/v4l2_m2m.h | 34 +++--
 libavcodec/v4l2_m2m_dec.c | 24 ++---
 libavcodec/v4l2_m2m_enc.c | 24 ++---
 6 files changed, 122 insertions(+), 43 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ba70c5d..9831bdb 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -211,16 +211,13 @@ static void v4l2_free_buffer(void *opaque, uint8_t 
*unused)
 if (s->reinit) {
 if (!atomic_load(&s->refcount))
 sem_post(&s->refsync);
-return;
-}
-
-if (avbuf->context->streamon) {
+} else if (avbuf->context->streamon) {
 ff_v4l2_buffer_enqueue(avbuf);
-return;
 }
 
-if (!atomic_load(&s->refcount))
-ff_v4l2_m2m_codec_end(s->avctx);
+if (atomic_fetch_sub(&avbuf->context_refcount, 1) == 1) {
+av_buffer_unref(&avbuf->context_ref);
+}
 }
 
 static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane, AVBufferRef **buf)
@@ -236,6 +233,17 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane, 
AVBufferRef **buf)
 if (!*buf)
 return AVERROR(ENOMEM);
 
+if (in->context_ref) {
+atomic_fetch_add(&in->context_refcount, 1);
+} else {
+in->context_ref = av_buffer_ref(s->self_ref);
+if (!in->context_ref) {
+av_buffer_unref(buf);
+return AVERROR(ENOMEM);
+}
+in->context_refcount = 1;
+}
+
 in->status = V4L2BUF_RET_USER;
 atomic_fetch_add_explicit(&s->refcount, 1, memory_order_relaxed);
 
diff --git a/libavcodec/v4l2_buffers.h b/libavcodec/v4l2_buffers.h
index e28a4a6..ce9f727 100644
--- a/libavcodec/v4l2_buffers.h
+++ b/libavcodec/v4l2_buffers.h
@@ -24,6 +24,7 @@
 #ifndef AVCODEC_V4L2_BUFFERS_H
 #define AVCODEC_V4L2_BUFFERS_H
 
+#include 
 #include 
 
 #include "avcodec.h"
@@ -41,6 +42,11 @@ typedef struct V4L2Buffer {
 /* each buffer needs to have a reference to its context */
 struct V4L2Context *context;
 
+/* This object is refcounted per-plane, so we need to keep track
+ * of how many context-refs we are holding. */
+AVBufferRef *context_ref;
+atomic_uint  context_refcount;
+
 /* keep track of the mmap address and mmap length */
 struct V4L2Plane_info {
 int bytesperline;
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 1d7a852..8a2da70 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -311,9 +311,22 @@ error:
 return ret;
 }
 
+static void v4l2_m2m_destroy_context(void *opaque, uint8_t *context)
+{
+V4L2m2mContext *s = (V4L2m2mContext*)context;
+
+ff_v4l2_context_release(&s->capture);
+sem_destroy(&s->refsync);
+
+close(s->fd);
+
+av_free(s);
+}
+
 int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
 {
-V4L2m2mContext* s = avctx->priv_data;
+V4L2m2mPriv *priv = avctx->priv_data;
+V4L2m2mContext* s = priv->context;
 int ret;
 
 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
@@ -326,17 +339,8 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
 
 ff_v4l2_context_release(&s->output);
 
-if (atomic_load(&s->refcount))
-av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
buffers\n");
-
-ff_v4l2_context_release(&s->capture);
-sem_destroy(&s->refsync);
-
-/* release the hardware */
-if (close(s->fd) < 0 )
-av_log(avctx, AV_LOG_ERROR, "failure closing %s (%s)\n", s->devname, 
av_err2str(AVER

Re: [FFmpeg-devel] [PATCH 4/7] xfacedec: Fix possible overread

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 11:11:56PM +0100, Mark Thompson wrote:
> Fixes #6745.
> ---
>  libavcodec/xfacedec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

this should not be needed, AVPacket.data should have padding at the end
but also shouldnt do any harm

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato

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

Re: [FFmpeg-devel] [PATCH 2/9] apngenc: Add missing error check

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 10:12:18PM +0100, Mark Thompson wrote:
> ---
>  libavformat/apngenc.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
> index 77c1c916c2..16ead54cc8 100644
> --- a/libavformat/apngenc.c
> +++ b/libavformat/apngenc.c
> @@ -217,8 +217,12 @@ static int flush_packet(AVFormatContext *format_context, 
> AVPacket *packet)
>  ++apng->frame_number;
>  
>  av_packet_unref(apng->prev_packet);
> -if (packet)
> -av_packet_ref(apng->prev_packet, packet);
> +if (packet) {
> +int ret;
> +ret = av_packet_ref(apng->prev_packet, packet);
> +if (ret < 0)
> +return ret;
> +}
>  return 0;
>  }
>  
> @@ -232,7 +236,9 @@ static int apng_write_packet(AVFormatContext 
> *format_context, AVPacket *packet)
>  if (!apng->prev_packet)
>  return AVERROR(ENOMEM);
>  
> -av_packet_ref(apng->prev_packet, packet);
> +ret = av_packet_ref(apng->prev_packet, packet);
> +if (ret < 0)
> +return ret;
>  } else {
>  ret = flush_packet(format_context, packet);
>  if (ret < 0)

probably ok

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH 1/9] lavc: Mark functions where ignoring returned error code is always wrong

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 10:12:17PM +0100, Mark Thompson wrote:
> ---
>  libavcodec/avcodec.h | 10 ++
>  1 file changed, 10 insertions(+)

if you checked that failure for each cannot be detected by another
way then it should be ok

thx

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

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/7] vf_cover_rect: Fix repeated condition

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 11:11:53PM +0100, Mark Thompson wrote:
> Fixes #6741.
> ---
>  libavfilter/vf_cover_rect.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued

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

Re: [FFmpeg-devel] [PATCH 8/9] cinepakenc: Move declaration out of for initialisation statement

2017-10-18 Thread Michael Niedermayer

On Tue, Oct 17, 2017 at 10:12:24PM +0100, Mark Thompson wrote:
> (cherry picked from commit 92f0aceb36c6e4412d4cf346e70dc74b5a4069e9)
> ---
>  libavcodec/cinepakenc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

LGTM

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI

2017-10-18 Thread Devin Heitmueller

Hi Dave,

> 
> The President of AJA has publicly stated an intent to add an open license to 
> their SDK, https://twitter.com/ajaprez/status/910100436224499713 
> .

This is certainly good news.  Looking at AJA’s offering is on my TODO list but 
I just haven’t found the time to pick up a card and dig into their SDK.

> I’m glad to hear that handling other VANC data is in the works, I’m 
> particularly interested in VITC and EIA-608 with inputs.

I am certainly interested in supporting VITC, assuming you’re talking about 
SMPTE 12M/RP-188 time codes.  EIA-608 wouldn’t be very hard to do, although 
there isn’t much equipment out there which does CEA-608 but not CEA-708.  Maybe 
some old legacy pre-HD equipment.

It would actually be pretty easy to do EIA-608 and just shoe-horn it in as 
AV_FRAME_DATA_A53_CC side data.  You would just need to compute the correct 
value for cc_count based on the frame rate, create an array of bytes of size 
[cc_count][3], and then fill the first two entries with the EIA-608 byte pairs. 
 Creating a new side-data type would seem like the reasonable approach at first 
glance, but then you have to duplicate all the logic on the insertion side for 
the various encoder codecs.

That said, supporting both 608 and 708 creates an unfortunate side effect - you 
have to write logic to decide which takes precedence if both are in an SDI 
frame (or expose configuration options to let the user specify).  Any SDI 
capture routine would have to choose one or the other, since downstream codecs 
general don’t have the capacity to insert both into a transport stream.  My 
inclination would probably be to simply ignore EIA-608 if there are also 708 
VANC packets present, but I can imagine you would also want a config option to 
allow the user to override that behavior.

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

Re: [FFmpeg-devel] decklink 24/32 bit question

2017-10-18 Thread Michael Niedermayer

On Wed, Oct 18, 2017 at 01:15:21PM -0700, Douglas Marsh wrote:
[...]
> *dither= I am not aware of any audio bit-depth dithering algorithms
> in FFMPEG, however it would make sense they do exist as this
> software is quite simply an amazing 'swiss-army knife'

i didnt follow the thread but theres dithering code for audio in
libswresample

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued

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

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Stephen Hutchinson


On 10/18/2017 6:49 PM, Ricardo Constantino wrote:


There's a few other libs that require static-only Cflags (libxml2, at
least), so openjpeg shouldn't be different. pkgconf does support
Cflags.private, but no one uses it.


To be fair, I did submit a pull request¹ to twolame that would
have -DLIBTWOLAME_STATIC placed under Cflags.private for the
pkgconf case, but got no response after I updated the PR with
that commit.

¹https://github.com/njh/twolame/pull/52
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

2017-10-18 Thread Sasi Inguva

Signed-off-by: Sasi Inguva 
---
 libavformat/mov.c   | 16 +++-
 tests/fate/mov.mak  |  6 ++-
 tests/ref/fate/mov-invalid-elst-entry-count | 57 +
 3 files changed, 76 insertions(+), 3 deletions(-)
 create mode 100644 tests/ref/fate/mov-invalid-elst-entry-count

diff --git a/libavformat/mov.c b/libavformat/mov.c
index b22a116140..8d2602c739 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4596,7 +4596,7 @@ free_and_return:
 static int mov_read_elst(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 MOVStreamContext *sc;
-int i, edit_count, version;
+int i, edit_count, version, elst_entry_size;
 
 if (c->fc->nb_streams < 1 || c->ignore_editlist)
 return 0;
@@ -4605,6 +4605,15 @@ static int mov_read_elst(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 version = avio_r8(pb); /* version */
 avio_rb24(pb); /* flags */
 edit_count = avio_rb32(pb); /* entries */
+atom.size -= 8;
+
+elst_entry_size = version == 1 ? 20 :  12;
+if (atom.size != edit_count * elst_entry_size &&
+c->fc->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid edit list entry_count: %d for 
elst atom of size: %"PRId64" bytes.\n",
+   edit_count, atom.size + 8);
+return AVERROR_INVALIDDATA;
+}
 
 if (!edit_count)
 return 0;
@@ -4617,17 +4626,20 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return AVERROR(ENOMEM);
 
 av_log(c->fc, AV_LOG_TRACE, "track[%u].edit_count = %i\n", 
c->fc->nb_streams - 1, edit_count);
-for (i = 0; i < edit_count && !pb->eof_reached; i++) {
+for (i = 0; i < edit_count && atom.size > 0 && !pb->eof_reached; i++) {
 MOVElst *e = &sc->elst_data[i];
 
 if (version == 1) {
 e->duration = avio_rb64(pb);
 e->time = avio_rb64(pb);
+atom.size -= 16;
 } else {
 e->duration = avio_rb32(pb); /* segment duration */
 e->time = (int32_t)avio_rb32(pb); /* media time */
+atom.size -= 8;
 }
 e->rate = avio_rb32(pb) / 65536.0;
+atom.size -= 4;
 av_log(c->fc, AV_LOG_TRACE, "duration=%"PRId64" time=%"PRId64" 
rate=%f\n",
e->duration, e->time, e->rate);
 
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index cfdada7a2e..012e6f61b7 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -6,7 +6,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-1elist-ends-last-bframe \
fate-mov-2elist-elist1-ends-bframe \
fate-mov-3elist-encrypted \
-   fate-mov-gpmf-remux \
+  fate-mov-invalid-elst-entry-count \
+  fate-mov-gpmf-remux \
 
 FATE_MOV_FFPROBE = fate-mov-aac-2048-priming \
fate-mov-zombie \
@@ -39,6 +40,9 @@ fate-mov-1elist-ends-last-bframe: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/mov-1e
 # Makes sure that we handle timestamps of packets in case of multiple edit 
lists with one of them ending on a B-frame correctly.
 fate-mov-2elist-elist1-ends-bframe: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/mov-2elist-elist1-ends-bframe.mov
 
+# Makes sure that we handle invalid edit list entry count correctly.
+fate-mov-invalid-elst-entry-count: CMD = framemd5 -i 
$(TARGET_SAMPLES)/mov/invalid_elst_entry_count.mov
+
 fate-mov-aac-2048-priming: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_packets 
-print_format compact $(TARGET_SAMPLES)/mov/aac-2048-priming.mov
 
 fate-mov-zombie: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_streams 
-show_packets -show_frames -bitexact -print_format compact 
$(TARGET_SAMPLES)/mov/white_zombie_scrunch-part.mov
diff --git a/tests/ref/fate/mov-invalid-elst-entry-count 
b/tests/ref/fate/mov-invalid-elst-entry-count
new file mode 100644
index 00..13b575816b
--- /dev/null
+++ b/tests/ref/fate/mov-invalid-elst-entry-count
@@ -0,0 +1,57 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 640x480
+#sar 0: 1/1
+#stream#, dts,pts, duration, size, hash
+0,  0,  0,1,   460800, 549730883a0b56e6accaf021903daecf
+0,  1,  1,1,   460800, 783389b4342d4be925fc5244791e760a
+0,  2,  2,1,   460800, 8384af6426d94a2077930c93013e09ad
+0,  3,  3,1,   460800, 9380a1d9ecacf5b3105383c1c8083188
+0,  4,  4,1,   460800, eb28174acfceb868b9058757bed049c5
+0,  5,  5,1,   460800, 9732bd4a58884dbf2be48d819433130f
+0,  6,  6,1,   460800, 0c553fb530cf042eb84f5b13817a96a6
+0,  7,  7,1,   460800, 621f02aded5e35fa1f373afd3ed283bd
+0,  8,  8,1,   460800, c76167c6bda91f657708c88252ea315d
+0,  9,  9,1,   460800, 872df2d8c522e2440ddd04bca7dce497

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

2017-10-18 Thread Michael Bradshaw

On Wed, Oct 18, 2017 at 5:04 PM, Michael Niedermayer  wrote:
>
> i think  the patch should add some note to the release notes or
> changelog
>

I've added a note to the Changelog. Let me know if there are additional
notices that should be made.

Updated patch attached (which contains James Almer's suggestion for the
-DOPJ_STATIC fix; thanks, James!).


0001-lavc-drop-support-for-OpenJPEG-1.3-2.0.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

66 matches

Mail list logo