Re: [FFmpeg-devel] [PATCH 1/1] avformat/http: flushing tcp receive buffer when it is write only mode

[Steven Liu]

> On 28 Mar 2018, at 12:52, vdi...@akamai.com wrote:
> 
> From: Vishwanath Dixit 
> 
> In write only mode, the TCP receive buffer keeps growing and eventually
> becomes full. This results in zero tcp window size, which in turn causes
> unwanted issues, like, terminated tcp connection. The issue is apparent
> when http persistent connection is enabled in hls/dash streaming use
> cases. To overcome this issue, the logic here reads and discards the data
> from the tcp socket.
> ---
> libavformat/http.c | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 983034f..e6d414b 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -1627,6 +1627,13 @@ static int http_shutdown(URLContext *h, int flags)
> ((flags & AVIO_FLAG_READ) && s->chunked_post && s->listen)) {
> ret = ffurl_write(s->hd, footer, sizeof(footer) - 1);
> ret = ret > 0 ? 0 : ret;
> +/* flush the receive buffer when it is write only mode */
> +if (!(flags & AVIO_FLAG_READ)) {
> +char buf[1024];
> +s->hd->flags |= AVIO_FLAG_NONBLOCK;
> +ffurl_read(s->hd, buf, sizeof(buf));
ffurl_read have a int return value.

407 int ffurl_read(URLContext *h, unsigned char *buf, int size)
408 {
409 if (!(h->flags & AVIO_FLAG_READ))
410 return AVERROR(EIO);
411 return retry_transfer_wrapper(h, buf, size, 1, h->prot->url_read);
412 }


> +s->hd->flags &= ~AVIO_FLAG_NONBLOCK;
> +}
> s->end_chunked_post = 1;
> }
> 
> -- 
> 1.9.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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

[FFmpeg-devel] [PATCH 1/1] avformat/http: flushing tcp receive buffer when it is write only mode

[vdixit]

From: Vishwanath Dixit 

In write only mode, the TCP receive buffer keeps growing and eventually
becomes full. This results in zero tcp window size, which in turn causes
unwanted issues, like, terminated tcp connection. The issue is apparent
when http persistent connection is enabled in hls/dash streaming use
cases. To overcome this issue, the logic here reads and discards the data
from the tcp socket.
---
 libavformat/http.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 983034f..e6d414b 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1627,6 +1627,13 @@ static int http_shutdown(URLContext *h, int flags)
 ((flags & AVIO_FLAG_READ) && s->chunked_post && s->listen)) {
 ret = ffurl_write(s->hd, footer, sizeof(footer) - 1);
 ret = ret > 0 ? 0 : ret;
+/* flush the receive buffer when it is write only mode */
+if (!(flags & AVIO_FLAG_READ)) {
+char buf[1024];
+s->hd->flags |= AVIO_FLAG_NONBLOCK;
+ffurl_read(s->hd, buf, sizeof(buf));
+s->hd->flags &= ~AVIO_FLAG_NONBLOCK;
+}
 s->end_chunked_post = 1;
 }
 
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: Make sure the input bitstream with padding can be addressed

[James Almer]

On 3/25/2018 9:13 PM, Michael Niedermayer wrote:
> On Sat, Mar 24, 2018 at 01:56:26AM +0100, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavcodec/get_bits.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> will apply

HOSTCC  libavcodec/qdm2_tablegen.o
In file included from src/libavcodec/tableprint_vlc.h:40,
 from src/libavcodec/qdm2_tablegen.c:25:
src/libavcodec/get_bits.h: In function 'init_get_bits':
src/libavcodec/get_bits.h:432: error: 'AV_INPUT_BUFFER_PADDING_SIZE'
undeclared (first use in this function)
src/libavcodec/get_bits.h:432: error: (Each undeclared identifier is
reported only once
src/libavcodec/get_bits.h:432: error: for each function it appears in.)
/home/fate/src/ffbuild/common.mak:152: recipe for target
'libavcodec/qdm2_tablegen.o' failed

When compiling with --enable-hardcoded-tables
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] movtextenc: fix handling of utf-8 subtitles

[Philip Langdale]

See the earlier fix for movtextdec for details. The equivalent bug is
present on the encoder side as well.

We need to track the text length in 'characters' (which seems to really
mean codepoints) to ensure that styles are applied across the correct
ranges.

Signed-off-by: Philip Langdale 
---
 libavcodec/movtextenc.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index d795e317c3..fd0743f752 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -304,11 +304,33 @@ static void mov_text_color_cb(void *priv, unsigned int 
color, unsigned int color
  */
 }
 
+static uint16_t utf8_strlen(const char *text, int len)
+{
+uint16_t i = 0, ret = 0;
+while (i < len) {
+char c = text[i];
+if (c >= 0)
+i += 1;
+else if ((c & 0xE0) == 0xC0)
+i += 2;
+else if ((c & 0xF0) == 0xE0)
+i += 3;
+else if ((c & 0xF8) == 0xF0)
+i += 4;
+else
+return 0;
+ret++;
+}
+return ret;
+}
+
 static void mov_text_text_cb(void *priv, const char *text, int len)
 {
+uint16_t utf8_len = utf8_strlen(text, len);
 MovTextContext *s = priv;
 av_bprint_append_data(>buffer, text, len);
-s->text_pos += len;
+// If it's not utf-8, just use the byte length
+s->text_pos += utf8_len ? utf8_len : len;
 }
 
 static void mov_text_new_line_cb(void *priv, int forced)
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: add OpenCL scale filter

[Rostislav Pehlivanov]

On 27 March 2018 at 15:54, Gabriel Machado  wrote:

> On 3/27/18 10:18 AM Rostislav Pehlivanov wrote:
>
> > No license, can't use it. Shadertoy has no explicit license.
> >
> >
> > Moreover the whole filter is incorrectly designed. Take a look at what
> mpv
> > does and how it has no explicit per-algorithm scaling functions.
>
> Thanks for the feedback!
>
> I removed it for the time being. I'll try to implement it correctly in a
> future patch.
>

Well, we're not in a hurry.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avutil/buffer: add a dynamic size buffer pool API

[James Almer]

Signed-off-by: James Almer 
---
Implemented as a completely separate API as suggested. Missing
Changelog, APIChanges and version bump as usual.

 libavutil/buffer.c  | 159 
 libavutil/buffer.h  |  53 +++
 libavutil/buffer_internal.h |  14 
 3 files changed, 226 insertions(+)

diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 8d1aa5fa84..c39a14c3c7 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -24,6 +24,7 @@
 #include "common.h"
 #include "mem.h"
 #include "thread.h"
+#include "tree.h"
 
 AVBufferRef *av_buffer_create(uint8_t *data, int size,
   void (*free)(void *opaque, uint8_t *data),
@@ -355,3 +356,161 @@ AVBufferRef *av_buffer_pool_get(AVBufferPool *pool)
 
 return ret;
 }
+
+AVBufferDynPool *av_buffer_dyn_pool_init(AVBufferRef* (*alloc)(int size))
+{
+AVBufferDynPool *pool = av_mallocz(sizeof(*pool));
+if (!pool)
+return NULL;
+
+ff_mutex_init(>mutex, NULL);
+
+pool->alloc = alloc ? alloc : av_buffer_alloc;
+
+atomic_init(>refcount, 1);
+
+return pool;
+}
+
+static int free_node(void *opaque, void *elem)
+{
+BufferPoolEntry *buf = elem;
+
+buf->free(buf->opaque, buf->data);
+av_free(buf);
+
+return 0;
+}
+
+static void buffer_dyn_pool_free(AVBufferDynPool *pool)
+{
+av_tree_enumerate(pool->root, NULL, NULL, free_node);
+av_tree_destroy(pool->root);
+
+ff_mutex_destroy(>mutex);
+
+av_freep();
+}
+
+void av_buffer_dyn_pool_uninit(AVBufferDynPool **ppool)
+{
+AVBufferDynPool *pool;
+
+if (!ppool || !*ppool)
+return;
+pool   = *ppool;
+*ppool = NULL;
+
+if (atomic_fetch_add_explicit(>refcount, -1, memory_order_acq_rel) 
== 1)
+buffer_dyn_pool_free(pool);
+}
+
+static int cmp_insert(const void *key, const void *node)
+{
+int ret = ((const BufferPoolEntry *) key)->size - ((const BufferPoolEntry 
*) node)->size;
+
+if (!ret)
+ret = ((const BufferPoolEntry *) key)->data - ((const BufferPoolEntry 
*) node)->data;
+return ret;
+}
+
+static void pool_release_dyn_buffer(void *opaque, uint8_t *data)
+{
+BufferPoolEntry *buf = opaque;
+AVBufferDynPool *pool = buf->dynpool;
+
+if(CONFIG_MEMORY_POISONING)
+memset(buf->data, FF_MEMORY_POISON, buf->size);
+
+ff_mutex_lock(>mutex);
+/* Add the buffer into the pool, using the preallocated
+ * AVTreeNode stored in buf->node */
+av_tree_insert(>root, buf, cmp_insert, >node);
+ff_mutex_unlock(>mutex);
+
+if (atomic_fetch_add_explicit(>refcount, -1, memory_order_acq_rel) 
== 1)
+buffer_dyn_pool_free(pool);
+}
+
+static AVBufferRef *pool_alloc_dyn_buffer(AVBufferDynPool *pool, int size)
+{
+BufferPoolEntry *buf;
+AVBufferRef *ret;
+
+ret = pool->alloc(size);
+if (!ret)
+return NULL;
+
+buf = av_mallocz(sizeof(*buf));
+if (!buf) {
+av_buffer_unref();
+return NULL;
+}
+
+buf->node = av_tree_node_alloc();
+if (!buf->node) {
+av_free(buf);
+av_buffer_unref();
+return NULL;
+}
+
+buf->data= ret->buffer->data;
+buf->opaque  = ret->buffer->opaque;
+buf->free= ret->buffer->free;
+buf->size= size;
+buf->dynpool = pool;
+
+ret->buffer->opaque = buf;
+ret->buffer->free   = pool_release_dyn_buffer;
+
+return ret;
+}
+
+static int cmp_find(const void *key, const void *node)
+{
+return *(const int *)key - ((const BufferPoolEntry *) node)->size;
+}
+
+AVBufferRef *av_buffer_dyn_pool_get(AVBufferDynPool *pool, int size)
+{
+AVBufferRef *ret;
+BufferPoolEntry *buf, *next[2] = { NULL, NULL };
+
+ff_mutex_lock(>mutex);
+/* Find a big enough buffer in the pool. */
+buf = av_tree_find(pool->root, , cmp_find, (void **)next);
+
+if (!buf)
+/* If none of the requested size exists, use a bigger one. */
+buf = next[1];
+if (!buf && (buf = next[0])) {
+/* If the pool also doesn't have a bigger buffer, but does
+ * have a smaller one, then replace it with a new buffer of
+ * the requested size. */
+av_tree_insert(>root, buf, cmp_insert, >node);
+buf->free(buf->opaque, buf->data);
+av_free(buf->node);
+av_freep();
+}
+
+if (buf) {
+ret = av_buffer_create(buf->data, buf->size, pool_release_dyn_buffer,
+   buf, 0);
+if (ret) {
+/* Remove the buffer from the pool. Zero and store the
+ * AVTreeNode used for it in buf->node so we can use it
+ * again once the buffer is put back in the pool. */
+av_tree_insert(>root, buf, cmp_insert, >node);
+memset(buf->node, 0, av_tree_node_size);
+ret->size = size;
+}
+} else {
+ret = pool_alloc_dyn_buffer(pool, size);
+}
+ff_mutex_unlock(>mutex);
+
+if (ret)
+

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

On 3/27/2018 11:46 PM, Alexander Strasser wrote:
>> + * of the stream's rate, for example: 1.2 means play back this entry at 
>> 1.2x speed.
>> + * If this value is 0, then the first sample (located at 'start') must 
>> be displayed
>> + * for the duration of the entry.
>> + */
>> +AVRational media_rate;
> 
> Wouldn't it better be called rate_mult or rate_multiplier or rate_factor
> or something in that fashion?

The name is taken directly from the ISOBMFF and MOV spec, which is where this
field will mostly come from. I figured changing it might be needless renaming.
>> +/**
>> + * Number of entries in the timeline.
>> + */
>> +size_t entry_count;
> 
> I think usually we prefix these with nb_ e.g. nb_entries
> This comment also applies to all _count suffixed names
> following later in this patch.

I modeled this after the recently pushed encryption side data. That is, I wanted
to be consistent with other side data APIs. It uses the _count suffix rather 
than
an nb_ prefix. I can use whichever people prefer.


>> +} AVTimeline;
>> +
>> +typedef struct AVTimelineList {
> 
> Would it be better to name it AVTimelineArray?

I'd prefer to use whichever is convention in FFmpeg's codebase.


>> + *
>> + * @param entry_count The number of entries in the timeline.
>> + *
>> + * @return The new AVTimeline structure, or NULL on error.
>> + */
>> +AVTimeline *av_timeline_alloc(size_t entry_count);
> 
> The allocated entries will be uninitialized?
> Either way it's probably worth it to document it.

OK.

>> +/**
>> + * Frees an AVTimeline structure and its members.
>> + *
>> + * @param timeline The AVTimeline structure to free.
>> + */
>> +void av_timeline_free(AVTimeline *timeline);
> 
> Is passing a NULL pointer OK?
> Would some other signature and semantic similar to av_freep be better?

This is another thing where I tried to match how other side data APIs
like encryption had their APIs, and this is how they did it.


>> +
>> +/**
>> + * Allocates an AVTimeline strcture with room for the request number of 
>> timelines.
>      ^^^
> Should it say AVTimelineList instead of AVTimeline ?

Yeah.

>> + *
>> + * @param timeline_count The number of entries in the timeline.
> 
>   The number of _time lines_ that can be stored in the list


Yeah, copypaste fail. Woops.




>> +AVTimelineList *av_timeline_list_get_side_data(const uint8_t *side_data, 
>> size_t side_data_size);
> 
> The name av_timeline_list_get_side_data seems a bit odd to me.
> 
> Maybe it is in line with other functions, then it might be just
> fine. To me something like
> 
>   av_timeline_list_create_from_side_data
> 
> or similar would be more concise.

I would rather keep this name since it is consistent with how we namespace, and
name the other side data APIs
>> +uint8_t *av_timeline_list_add_side_data(const AVTimelineList 
>> *timeline_list, size_t *side_data_size);
> 
> As above this function name doesn't sound very intuitive to me. I didn't
> check if we have similar naming patterns around already. So it might
> be consistent; I don't know.

Ditto.

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

Re: [FFmpeg-devel] [PATCH] hwcontext_d3d11: Fix crash with valid adapter but no device

[Mark Thompson]

On 27/03/18 16:10, wm4 wrote:
> On Tue, 27 Mar 2018 01:22:34 +0100
> Mark Thompson  wrote:
> 
>> This crash was introduced by 8bbf2dacbfb4ead1535dea411035994f507f517d,
>> which could incorrectly overwrite the failure result from creating the
>> device.
>>
>> Fixes ticket #7108.
>> ---
>>  libavutil/hwcontext_d3d11va.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
>> index 960883c9d8..d39fdd3fc8 100644
>> --- a/libavutil/hwcontext_d3d11va.c
>> +++ b/libavutil/hwcontext_d3d11va.c
>> @@ -556,8 +556,6 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
>> const char *device,
>>  }
>>  }
>>  
>> -hr = mD3D11CreateDevice(pAdapter, pAdapter ? D3D_DRIVER_TYPE_UNKNOWN : 
>> D3D_DRIVER_TYPE_HARDWARE, NULL, creationFlags, NULL, 0,
>> -   D3D11_SDK_VERSION, _hwctx->device, NULL, NULL);
>>  if (pAdapter) {
>>  DXGI_ADAPTER_DESC2 desc;
>>  hr = IDXGIAdapter2_GetDesc(pAdapter, );
>> @@ -565,8 +563,12 @@ static int d3d11va_device_create(AVHWDeviceContext 
>> *ctx, const char *device,
>>  av_log(ctx, AV_LOG_INFO, "Using device %04x:%04x (%ls).\n",
>> desc.VendorId, desc.DeviceId, desc.Description);
>>  }
>> -IDXGIAdapter_Release(pAdapter);
>>  }
>> +
>> +hr = mD3D11CreateDevice(pAdapter, pAdapter ? D3D_DRIVER_TYPE_UNKNOWN : 
>> D3D_DRIVER_TYPE_HARDWARE, NULL, creationFlags, NULL, 0,
>> +   D3D11_SDK_VERSION, _hwctx->device, NULL, NULL);
>> +if (pAdapter)
>> +IDXGIAdapter_Release(pAdapter);
>>  if (FAILED(hr)) {
>>  av_log(ctx, AV_LOG_ERROR, "Failed to create Direct3D device 
>> (%lx)\n", (long)hr);
>>  return AVERROR_UNKNOWN;
> 
> LGTM

Pushed.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Mark Thompson]

On 27/03/18 21:38, Michael Niedermayer wrote:
> On Tue, Mar 27, 2018 at 01:31:43AM +0100, Mark Thompson wrote:
>> On 27/03/18 01:20, Michael Niedermayer wrote:
>>> On Sun, Mar 25, 2018 at 06:41:34PM +0100, Mark Thompson wrote:
 Allows insertion (from side data), extraction (to side data), and removal
 of closed captions in SEI messages.
 ---
  libavcodec/Makefile|   2 +-
  libavcodec/h264_metadata_bsf.c | 138 
 +
  2 files changed, 139 insertions(+), 1 deletion(-)
>>>
>>> This breaks build on mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5
>>>
>>>
>>> In file included from src/libavcodec/cbs_misc.c:25:
>>> src/libavcodec/cbs_misc.h:73: warning: declaration does not declare anything
>>> src/libavcodec/cbs_misc.h:86: warning: declaration does not declare anything
>>> In file included from src/libavcodec/cbs_misc.c:57:
>>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>>> ‘cbs_misc_read_a53_atsc_user_data’:
>>> src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
>>> no member named ‘cc_data’
>>> src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
>>> no member named ‘bar_data’
>>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>>> ‘cbs_misc_read_a53_user_data’:
>>> src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
>>> member named ‘atsc’
>>> src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
>>> member named ‘afd’
>>> In file included from src/libavcodec/cbs_misc.c:82:
>>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>>> ‘cbs_misc_write_a53_atsc_user_data’:
>>> src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
>>> no member named ‘cc_data’
>>> src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
>>> no member named ‘bar_data’
>>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>>> ‘cbs_misc_write_a53_user_data’:
>>> src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
>>> member named ‘atsc’
>>> src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
>>> member named ‘afd’
>>> src/libavcodec/cbs_misc.c: In function ‘ff_cbs_read_a53_cc_side_data’:
>>> src/libavcodec/cbs_misc.c:153: error: unknown field ‘atsc’ specified in 
>>> initializer
>>> src/libavcodec/cbs_misc.c:153: error: extra brace group at end of 
>>> initializer
>>> src/libavcodec/cbs_misc.c:153: error: (near initialization for 
>>> ‘(anonymous)’)
>>> src/libavcodec/cbs_misc.c:156: error: extra brace group at end of 
>>> initializer
>>> src/libavcodec/cbs_misc.c:156: error: (near initialization for 
>>> ‘(anonymous)’)
>>> src/libavcodec/cbs_misc.c:165: warning: excess elements in struct 
>>> initializer
>>> src/libavcodec/cbs_misc.c:165: warning: (near initialization for 
>>> ‘(anonymous)’)
>>> src/libavcodec/cbs_misc.c:167: error: ‘A53UserData’ has no member named 
>>> ‘atsc’
>>> src/libavcodec/cbs_misc.c: In function ‘ff_cbs_write_a53_cc_side_data’:
>>> src/libavcodec/cbs_misc.c:193: error: ‘A53UserData’ has no member named 
>>> ‘atsc’
>>> src/libavcodec/cbs_misc.c:196: error: ‘A53UserData’ has no member named 
>>> ‘atsc’
>>> CC  libavcodec/dpxenc.o
>>> CC  libavcodec/dpx_parser.o
>>> make: *** [libavcodec/cbs_misc.o] Error 1
>>> make: *** Waiting for unfinished jobs
>>> src/libavcodec/dnxhddec.c:146: warning: ‘dnxhd_decode_init_thread_copy’ 
>>> defined but not used
>>> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_init’:
>>> src/libavcodec/dnxhdenc.c:518: warning: ‘coded_frame’ is deprecated 
>>> (declared at src/libavcodec/avcodec.h:2760)
>>> src/libavcodec/dnxhdenc.c:519: warning: ‘coded_frame’ is deprecated 
>>> (declared at src/libavcodec/avcodec.h:2760)
>>> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_load_picture’:
>>> src/libavcodec/dnxhdenc.c:1272: warning: ‘coded_frame’ is deprecated 
>>> (declared at src/libavcodec/avcodec.h:2760)
>>> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_picture’:
>>> src/libavcodec/dnxhdenc.c:1337: warning: ‘coded_frame’ is deprecated 
>>> (declared at src/libavcodec/avcodec.h:2760)
>>> src/libavcodec/dpxenc.c: In function ‘encode_frame’:
>>> src/libavcodec/dpxenc.c:180: warning: ‘need_align’ may be used 
>>> uninitialized in this function
>>> src/libavcodec/dpxenc.c:180: warning: ‘len’ may be used uninitialized in 
>>> this function
>>>
>>>
>>> [...]
>>
>> Do you happen to know what set of compilers lack anonymous union support 
>> like this?  It's quite tempting to add a configure option to just not build 
>> it for them.
> 
> I dont know which compilers, in the sense of names and versions but
> 
> anonymous unions are AFAIK C11, so compilers that support just C99 could
> fail.
> I think we should not drop support for pure C99 compilers yet. Doing that
> would also require better understanding the impact ...

To clarify, I wasn't intending to suggest that we kill pre-C11 support 

Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API

[James Almer]

On 3/27/2018 2:58 PM, wm4 wrote:
> On Tue, 27 Mar 2018 14:16:15 -0300
> James Almer  wrote:
> 
>> On 3/20/2018 7:44 PM, James Almer wrote:
>>> On 3/16/2018 3:21 PM, James Almer wrote:  
 Signed-off-by: James Almer 
 ---
 This is a proof of concept for a dynamic size buffer pool API.

 For the purpose of easy testing and reviewing I replaced the current
 linked list used to keep a pool of fixed size buffers with the tree
 based pool that will be used to keep a pool of varying size buffers,
 instead of adding a new set of functions exclusively for the new API.
 The final committed work doesn't necessarely have to do the above, as
 there's no real benefit using a tree when you only need a fixed size
 buffer pool, other than simplying things.

 I'm open to suggestions about how to introduce this. Completely
 separate set of functions and struct names? Sharing the struct and
 init/uninit functions and only adding a new get() one like in this
 patch?
 Any preferences with function/struct naming, for that matter?  
>>>
>>> Ping?  
>>
>> No comments or preferences at all on how to introduce this?
> 
> Well, it's a pretty big mess (so many things to consider). That's
> mostly about the implementation details.
> 
> I think the API you picked is relatively nice. It feels weird that a
> pool that is initialized with a size has a function to allocate buffers
> with a different size.

I submitted it like this for easy review and testing. I wasn't really
expecting to push it without changes precisely because the init()
function is meant for fixed sized buffers.

> So if you want some bikeshedding, sure, I can
> provide you with some colors:
> 
>  AVDynamicBufferPool *av_dynamic_buffer_pool_create(alloc_fn, free_fn);
>  AVBufferRef *av_dynamic_buffer_pool_get(AVDynamicBufferPool *pool,
>  size_t size);
>  void av_dynamic_buffer_pool_uininit(AVDynamicBufferPool **pool);
> 
> or:
> 
>  // sets *pool if it was NULL
>  // (where to put alloc/free FNs for custom alloc?)
>  AVBufferRef *av_dynamic_buffer_pool_get(AVDynamicBufferPool **pool,
>  size_t size);
>  void av_dynamic_buffer_pool_uininit(AVDynamicBufferPool **pool);
> 
> or:
> 
>   // sets *pool if it was NULL
>   // free the pool with av_buffer_unref()
>   AVBufferRef *av_dynamic_buffer_pool_get(AVBufferRef **pool,
>  size_t size);

Ok so, separate set of struct and functions. Probably best in order to
avoid having to add all kinds of workarounds for things like calling dyn
functions using pools created with the fixed size init().

> 
> or just force the API user to pass size=0 to av_buffer_pool_init() and
> enforce the use of the correct alloc function (fixed size/dynamic size)
> at runtime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/5 v2] avformat/utils: make AVPacketList helper functions shared

[James Almer]

Based on a patch by Luca Barbato.

Signed-off-by: James Almer 
---
 libavformat/internal.h | 38 +
 libavformat/utils.c| 57 +-
 2 files changed, 71 insertions(+), 24 deletions(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index a020b1b417..9f987436e0 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -731,6 +731,44 @@ int ff_unlock_avformat(void);
  */
 void ff_format_set_url(AVFormatContext *s, char *url);
 
+#define FF_PACKETLIST_FLAG_REF_PACKET (1 << 0) /**< Create a new reference for 
the packet instead of
+transferring the ownership 
of the existing one to the
+list. */
+
+/**
+ * Append an AVPacket to the list.
+ *
+ * @param head  List head element
+ * @param tail  List tail element
+ * @param pkt   The packet being appended
+ * @param flags Any combination of FF_PACKETLIST_FLAG_* flags
+ * @return 0 on success, negative AVERROR value on failure. On failure,
+   the list is unchanged
+ */
+int ff_packet_list_put(AVPacketList **head, AVPacketList **tail,
+   AVPacket *pkt, int flags);
+
+/**
+ * Remove the oldest AVPacket in the list and return it.
+ *
+ * @note The pkt will be overwritten completely. The caller owns the
+ *   packet and must unref it by itself.
+ *
+ * @param head List head element
+ * @param tail List tail element
+ * @param pkt  Pointer to an initialized AVPacket struct
+ */
+int ff_packet_list_get(AVPacketList **head, AVPacketList **tail,
+   AVPacket *pkt);
+
+/**
+ * Wipe the list and unref all the packets in it.
+ *
+ * @param head List head element
+ * @param tail List tail element
+ */
+void ff_packet_list_free(AVPacketList **head, AVPacketList **tail);
+
 #if FF_API_NEXT
 /**
   * Register devices in deprecated format linked list.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f13c8208b1..d38d4c0bec 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -444,8 +444,9 @@ static int init_input(AVFormatContext *s, const char 
*filename,
  s, 0, s->format_probesize);
 }
 
-static int add_to_pktbuf(AVPacketList **packet_buffer, AVPacket *pkt,
- AVPacketList **plast_pktl, int ref)
+int ff_packet_list_put(AVPacketList **packet_buffer,
+   AVPacketList **plast_pktl,
+   AVPacket  *pkt, int flags)
 {
 AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
 int ret;
@@ -453,12 +454,15 @@ static int add_to_pktbuf(AVPacketList **packet_buffer, 
AVPacket *pkt,
 if (!pktl)
 return AVERROR(ENOMEM);
 
-if (ref) {
+if (flags & FF_PACKETLIST_FLAG_REF_PACKET) {
 if ((ret = av_packet_ref(>pkt, pkt)) < 0) {
 av_free(pktl);
 return ret;
 }
 } else {
+// TODO: Adapt callers in this file so the line below can use
+//   av_packet_move_ref() to effectively move the reference
+//   to the list.
 pktl->pkt = *pkt;
 }
 
@@ -485,9 +489,10 @@ int avformat_queue_attached_pictures(AVFormatContext *s)
 continue;
 }
 
-ret = add_to_pktbuf(>internal->raw_packet_buffer,
->streams[i]->attached_pic,
->internal->raw_packet_buffer_end, 1);
+ret = ff_packet_list_put(>internal->raw_packet_buffer,
+ >internal->raw_packet_buffer_end,
+ >streams[i]->attached_pic,
+ FF_PACKETLIST_FLAG_REF_PACKET);
 if (ret < 0)
 return ret;
 }
@@ -913,8 +918,9 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 if (!pktl && st->request_probe <= 0)
 return ret;
 
-err = add_to_pktbuf(>internal->raw_packet_buffer, pkt,
->internal->raw_packet_buffer_end, 0);
+err = ff_packet_list_put(>internal->raw_packet_buffer,
+ >internal->raw_packet_buffer_end,
+ pkt, 0);
 if (err)
 return err;
 s->internal->raw_packet_buffer_remaining_size -= pkt->size;
@@ -1412,7 +1418,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
 
-static void free_packet_buffer(AVPacketList **pkt_buf, AVPacketList 
**pkt_buf_end)
+void ff_packet_list_free(AVPacketList **pkt_buf, AVPacketList **pkt_buf_end)
 {
 while (*pkt_buf) {
 AVPacketList *pktl = *pkt_buf;
@@ -1504,8 +1510,9 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt, int stream_index)
 
 compute_pkt_fields(s, st, st->parser, _pkt, next_dts, next_pts);
 
-ret = add_to_pktbuf(>internal->parse_queue, _pkt,
-

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Alexander Strasser]

Hi Derek,

I am happy to see someone trying to extend FFmpeg to support these kind
of features in a deeper way. Good luck on this journey!

Below I am mostly commenting on typos and rather minor things.

So you should for now mostly ignore my comments, but it is easier to
write them now that I read the patch. Just saying taking immediate action
in this early stage when things will probably be dropped or modified could
result in unneeded extra work.


On 2018-03-27 20:44 +0100, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/avcodec.h |   8 +++
>  libavutil/timeline.h | 160 
> +++
>  2 files changed, 168 insertions(+)
>  create mode 100644 libavutil/timeline.h
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 50c34db..6f54495 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1358,6 +1358,14 @@ enum AVPacketSideDataType {
>  AV_PKT_DATA_ENCRYPTION_INFO,
>  
>  /**
> + * This side data contains timeline entries for a given stream. This type
> + * will only apear as stream side data.
> + *
> + * The format is not part of the ABI, use av_timeline_* method to access.
> + */
> +AV_PKT_DATA_TIMELINE,
> +
> +/**
>   * The number of side data types.
>   * This is not part of the public API/ABI in the sense that it may
>   * change when new side data types are added.
> diff --git a/libavutil/timeline.h b/libavutil/timeline.h
> new file mode 100644
> index 000..f1f3e1b
> --- /dev/null
> +++ b/libavutil/timeline.h
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (C) 2018 Derek Buitenhuis
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#ifndef AVUTIL_TIMELINE_H
> +#define AVUTIL_TIMELINE_H
> +
> +#include 
> +#include 
> +
> +#include "rational.h"
> +
> +typedef struct AVTimelineEntry {
> +/**
> + * The start time of the given timeline entry, in stream timebase units.
> + * If this value is AV_NOPTS_VALUE, you must display black for the 
> duration
> + * of the entry. For audio, silence must be played.
> + */
> +int64_t start;
> +
> +/**
> + * The duration of the given timeline entry, in steam timebase units.
   ^
stream


> + */
> +int64_t duration;
> +
> +/**
> + * The rate at which this entry should be played back. The value is a 
> multipier
 
^
multiplier


> + * of the stream's rate, for example: 1.2 means play back this entry at 
> 1.2x speed.
> + * If this value is 0, then the first sample (located at 'start') must 
> be displayed
> + * for the duration of the entry.
> + */
> +AVRational media_rate;

Wouldn't it better be called rate_mult or rate_multiplier or rate_factor
or something in that fashion?

Nit: As this member is of type AVRational it might be better to word
it more precisely like "if the numerator is 0".


> +} AVTimelineEntry;
> +
> +/**
> + * Describes a timeline for a stream in terms of edits/entries. Each entry 
> must be
> + * played back in order, according to the information in each. Each stream 
> may have
> + * multiple timelines which need to be correlated between different streams.
> + */
> +typedef struct AVTimeline {
> +/**
> + * The ID of a given timeline. Since each stream may have multiple 
> timelines
> + * defined, this value is used to correlated different streams' timelines
 ^^
correlate?


> + * which should be used together. For example, if one has two streams,
> + * one video, and one audio, with two timelines each, the timelines
> + * with matching IDs should be used in conjuction, to assure everything
  ^^
conjunction


> + * is in sync and matches. The concept is similar to that of EditionUID
> + * in Matroska.
> + */
> +uint32_t id;
> +
> +/**
> + * An in-order array of entries for the given timeline.
> + * Each entry contains information on which samples to display 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/eac3: add support for dependent stream

[Michael Niedermayer]

On Tue, Mar 27, 2018 at 10:55:05PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/aac_ac3_parser.c |   9 ++-
>  libavcodec/ac3_parser.c |   2 +-
>  libavcodec/ac3dec.c | 177 
> +++-
>  libavcodec/ac3dec.h |  10 ++-
>  libavcodec/eac3dec.c|  11 +--
>  5 files changed, 160 insertions(+), 49 deletions(-)

this changes fate:
h264
TESTfifo-muxer-wav
TESTfilter-owdenoise-sample
--- ./tests/ref/fate/ts-demux   2018-03-26 22:16:55.300383350 +0200
+++ tests/data/fate/ts-demux2018-03-28 00:36:45.599977471 +0200
@@ -13,7 +13,7 @@
 1,  0,  0, 2880, 1536, 0x773ffeea, S=1,1, 
0x00bd00bd
 1,   2880,   2880, 2880, 1536, 0x6dc10748
 1,   5760,   5760, 2880, 1536, 0xbab5129c
-1,   8640,   8640, 2880, 1536, 0x602f034b
+1,   8640,   8640, 2880, 1536, 0x602f034b, S=1,1, 
0x00bd00bd
 1,  11520,  11520, 2880,  906, 0x69cdcbcd
 0,  32037,  36541, 1501,   114336, 0x37a215a8, S=1,1, 
0x00e000e0
 0,  33538,  33538, 1501,12560, 0xb559a3d4, F=0x0, S=1,
1, 0x00e000e0
TESTfilter-delogo
Test ts-demux failed. Look at tests/data/fate/ts-demux.err for details.
make: *** [fate-ts-demux] Error 1
make: *** Waiting for unfinished jobs


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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH 1/5] avformat/utils: make AVPacketList helper functions shared

[Michael Niedermayer]

On Tue, Mar 27, 2018 at 06:17:09PM -0300, James Almer wrote:
> On 3/27/2018 5:22 PM, Michael Niedermayer wrote:
> > On Mon, Mar 26, 2018 at 03:02:35PM -0300, James Almer wrote:
> >> Based on a patch by Luca Barbato.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavformat/internal.h | 35 ++
> >>  libavformat/utils.c| 51 
> >> +++---
> >>  2 files changed, 63 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/libavformat/internal.h b/libavformat/internal.h
> >> index a020b1b417..7e1b24ebe6 100644
> >> --- a/libavformat/internal.h
> >> +++ b/libavformat/internal.h
> >> @@ -731,6 +731,41 @@ int ff_unlock_avformat(void);
> >>   */
> >>  void ff_format_set_url(AVFormatContext *s, char *url);
> >>  
> >> +/**
> >> + * Append an AVPacket to the list.
> >> + *
> > 
> >> + * @param head List head
> >> + * @param tail List tail
> > 
> > about the terminology
> > Shouldnt this be a single List element or 2 ListEntry elements ?
> 
> What do you suggest to write instead? I don't think the current
> terminology is confusing. It's two AVPacketList arguments, one pointing
> to the head/first item of the list and the other to the tail/last item.

hmm i guess the simplest would be
@param head List head element.

It feels a bit inelegant to have to keep track of 2 elements but changing
this is probably too much work


[...]
> > 
> > 
> >> + */
> >> +int ff_packet_list_put(AVPacketList **head, AVPacketList **tail,
> >> +   AVPacket *pkt, int ref);
> > 
> > ref should not be a int but a enum
> > ff_packet_list_put(,,,1)
> > ff_packet_list_put(,,,0)
> > 
> > is alot more confusing to a new developer than with english words
> > the code should be self explanatory not requiring looking up the
> > documentation
> 
> Adding an enum like this seems extreme for an internal API, but ok.

yes, i was thinking a bit ahead.
For a internal API it is not that important but this API is quite usefull
i think theres a good chance it might become public in the future.
But even for a internal API named constants seem better IMHO

thx

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH 1/5] avformat/utils: make AVPacketList helper functions shared

[James Almer]

On 3/27/2018 5:22 PM, Michael Niedermayer wrote:
> On Mon, Mar 26, 2018 at 03:02:35PM -0300, James Almer wrote:
>> Based on a patch by Luca Barbato.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/internal.h | 35 ++
>>  libavformat/utils.c| 51 
>> +++---
>>  2 files changed, 63 insertions(+), 23 deletions(-)
>>
>> diff --git a/libavformat/internal.h b/libavformat/internal.h
>> index a020b1b417..7e1b24ebe6 100644
>> --- a/libavformat/internal.h
>> +++ b/libavformat/internal.h
>> @@ -731,6 +731,41 @@ int ff_unlock_avformat(void);
>>   */
>>  void ff_format_set_url(AVFormatContext *s, char *url);
>>  
>> +/**
>> + * Append an AVPacket to the list.
>> + *
> 
>> + * @param head List head
>> + * @param tail List tail
> 
> about the terminology
> Shouldnt this be a single List element or 2 ListEntry elements ?

What do you suggest to write instead? I don't think the current
terminology is confusing. It's two AVPacketList arguments, one pointing
to the head/first item of the list and the other to the tail/last item.

> 
> 
>> + * @param pkt  The packet being appended
>> + * @param ref  Create a new reference for the packet instead of
>> +   transferring the ownership of the existing one to the
>> + * list.
> 
>> + * @return < 0 on failure and 0 on success
> 
> if its an AVERROR code on failure this should be documented, ATM it just
> says some unspecifified negative value

Ok.

> 
> 
>> + */
>> +int ff_packet_list_put(AVPacketList **head, AVPacketList **tail,
>> +   AVPacket *pkt, int ref);
> 
> ref should not be a int but a enum
> ff_packet_list_put(,,,1)
> ff_packet_list_put(,,,0)
> 
> is alot more confusing to a new developer than with english words
> the code should be self explanatory not requiring looking up the
> documentation

Adding an enum like this seems extreme for an internal API, but ok.

> 
> thx
> 
> [...]
> 
> 
> 
> ___
> 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] [RFC] Exporting virtual timelines as stream side data

[wm4]

On Tue, 27 Mar 2018 16:45:23 -0400
Dave Rice  wrote:

> > On Mar 27, 2018, at 4:33 PM, wm4  wrote:
> > 
> > On Tue, 27 Mar 2018 16:11:11 -0400
> > Dave Rice  wrote:
> >   
> >>> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis 
> >>>  wrote:
> >>> 
> >>> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
>  I think we should drop the internal crap if the tools and the API support
>  it. Would also solve a lot of issues like ffmpeg.c not trimming the start
>  frame (so people complain all the time about longer files).
> >>> 
> >>> I personally agree, but I thought I'd be diplomatic about it, since it 
> >>> would
> >>> technically be losing a 'feature', since it would no longer Just Work(ish)
> >>> and require user applications to apply timelines themselves - and I 
> >>> figured
> >>> some would argue that point.
> >> 
> >> +1 I’m willing to contribute what information or samples would be needed 
> >> to help with Matroska support with virtual timelines. IMO, this would be a 
> >> valuable feature to have in ffmpeg.
> >> Dave Rice  
> > 
> > Some explanations how this interacts with editions would be good.  
> 
> I put an example with two editions at 
> https://archive.org/download/chapters_test/chapters_test.mkv which mimics a 
> digitized video 

Also this file lacks a chapter end time in the second edition. How is
that valid?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[wm4]

On Tue, 27 Mar 2018 16:45:23 -0400
Dave Rice  wrote:

> > On Mar 27, 2018, at 4:33 PM, wm4  wrote:
> > 
> > On Tue, 27 Mar 2018 16:11:11 -0400
> > Dave Rice  wrote:
> >   
> >>> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis 
> >>>  wrote:
> >>> 
> >>> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
>  I think we should drop the internal crap if the tools and the API support
>  it. Would also solve a lot of issues like ffmpeg.c not trimming the start
>  frame (so people complain all the time about longer files).
> >>> 
> >>> I personally agree, but I thought I'd be diplomatic about it, since it 
> >>> would
> >>> technically be losing a 'feature', since it would no longer Just Work(ish)
> >>> and require user applications to apply timelines themselves - and I 
> >>> figured
> >>> some would argue that point.
> >> 
> >> +1 I’m willing to contribute what information or samples would be needed 
> >> to help with Matroska support with virtual timelines. IMO, this would be a 
> >> valuable feature to have in ffmpeg.
> >> Dave Rice  
> > 
> > Some explanations how this interacts with editions would be good.  
> 
> I put an example with two editions at 
> https://archive.org/download/chapters_test/chapters_test.mkv which mimics a 
> digitized video tape. One edition depicts the stored video encoding in its 
> entire presentation and the other default edition plays from the video 
> encoding selectively. When the file is played in VLC, the default edition is 
> used to show a shortened presentation, but the other editions may be selected 
> within the Program menu option. In the proposal there should be an option to 
> mimic the current behavior and ignore the editions (equivalent of 
> -ignore_editlist in mov), to use the first default edition, or to select a 
> specific edition.

Simple editions are... simple. It's more about the interaction with
segment linking specifically I guess.

> > Or documenting ordered chapters and segment linking in the mkv "spec"
> > at all.  
> 
> This document, http://mod16.org/hurfdurf/?p=8 
> ,  is unofficially a good resource on that.
> 
> More officially the Cellar working group has this section on Linked Segments: 
> https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-23 
> , and 
> this one on Ordered Editions: 
> https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-10.1.2.3 
> .
>  This documentation is a work in progress so comments/reviews/suggestions are 
> welcome (issues can be filed at 
> https://github.com/Matroska-Org/matroska-specification 
>  or via 
> https://www.ietf.org/mailman/listinfo/cellar 
> ).

There isn't much about how ChapterSegmentEditionUID should be handled.
I remember this because it brought a non-trivial change in mpv's
ordered chapters/segment linking handling, and I never understood how
the heck it works.

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

[FFmpeg-devel] [PATCH 1/2] avcodec/eac3: add support for dependent stream

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/aac_ac3_parser.c |   9 ++-
 libavcodec/ac3_parser.c |   2 +-
 libavcodec/ac3dec.c | 177 +++-
 libavcodec/ac3dec.h |  10 ++-
 libavcodec/eac3dec.c|  11 +--
 5 files changed, 160 insertions(+), 49 deletions(-)

diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 4e834b4424..019074b0dd 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_parser.c
@@ -86,13 +86,16 @@ get_next:
the frame). */
 if (avctx->codec_id != AV_CODEC_ID_AAC) {
 avctx->sample_rate = s->sample_rate;
-avctx->channels = s->channels;
-avctx->channel_layout = s->channel_layout;
+if (avctx->codec_id != AV_CODEC_ID_EAC3) {
+avctx->channels = s->channels;
+avctx->channel_layout = s->channel_layout;
+}
 s1->duration = s->samples;
 avctx->audio_service_type = s->service_type;
 }
 
-avctx->bit_rate = s->bit_rate;
+if (avctx->codec_id != AV_CODEC_ID_EAC3)
+avctx->bit_rate = s->bit_rate;
 }
 
 return i;
diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1015245a90..f4618bf215 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -218,8 +218,8 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext 
*hdr_info,
 else if (hdr_info->codec_id == AV_CODEC_ID_NONE)
 hdr_info->codec_id = AV_CODEC_ID_AC3;
 
-*need_next_header = (hdr.frame_type != EAC3_FRAME_TYPE_AC3_CONVERT);
 *new_frame_start  = (hdr.frame_type != EAC3_FRAME_TYPE_DEPENDENT);
+*need_next_header = *new_frame_start || (hdr.frame_type != 
EAC3_FRAME_TYPE_AC3_CONVERT);
 return hdr.frame_size;
 }
 
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 244a18323f..554eae9218 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -106,6 +106,25 @@ static const uint8_t ac3_default_coeffs[8][5][2] = {
 { { 2, 7 }, { 5, 5 }, { 7, 2 }, { 6, 7 }, { 7, 6 }, },
 };
 
+static const uint64_t custom_channel_map_locations[16][2] = {
+{ 1, AV_CH_FRONT_LEFT },
+{ 1, AV_CH_FRONT_CENTER },
+{ 1, AV_CH_FRONT_RIGHT },
+{ 1, AV_CH_SIDE_LEFT },
+{ 1, AV_CH_SIDE_RIGHT },
+{ 0, AV_CH_FRONT_LEFT_OF_CENTER | AV_CH_FRONT_RIGHT_OF_CENTER },
+{ 0, AV_CH_BACK_LEFT | AV_CH_BACK_RIGHT },
+{ 0, AV_CH_BACK_CENTER },
+{ 0, AV_CH_TOP_CENTER },
+{ 0, AV_CH_SURROUND_DIRECT_LEFT | AV_CH_SURROUND_DIRECT_RIGHT },
+{ 0, AV_CH_WIDE_LEFT | AV_CH_WIDE_RIGHT },
+{ 0, AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT},
+{ 0, AV_CH_TOP_FRONT_CENTER },
+{ 0, AV_CH_TOP_BACK_LEFT | AV_CH_TOP_BACK_RIGHT },
+{ 0, AV_CH_LOW_FREQUENCY_2 },
+{ 1, AV_CH_LOW_FREQUENCY },
+};
+
 /**
  * Symmetrical Dequantization
  * reference: Section 7.3.3 Expansion of Mantissas for Symmetrical Quantization
@@ -317,6 +336,7 @@ static int parse_frame_header(AC3DecodeContext *s)
 s->fbw_channels = s->channels - s->lfe_on;
 s->lfe_ch   = s->fbw_channels + 1;
 s->frame_size   = hdr.frame_size;
+s->superframe_size += hdr.frame_size;
 s->preferred_downmix= AC3_DMIXMOD_NOTINDICATED;
 s->center_mix_level = hdr.center_mix_level;
 s->center_mix_level_ltrt= 4; // -3.0dB
@@ -683,7 +703,7 @@ static void do_rematrixing(AC3DecodeContext *s)
  * Convert frequency domain coefficients to time-domain audio samples.
  * reference: Section 7.9.4 Transformation Equations
  */
-static inline void do_imdct(AC3DecodeContext *s, int channels)
+static inline void do_imdct(AC3DecodeContext *s, int channels, int offset)
 {
 int ch;
 
@@ -695,25 +715,25 @@ static inline void do_imdct(AC3DecodeContext *s, int 
channels)
 x[i] = s->transform_coeffs[ch][2 * i];
 s->imdct_256.imdct_half(>imdct_256, s->tmp_output, x);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
 for (i = 0; i < 128; i++)
 x[i] = s->transform_coeffs[ch][2 * i + 1];
-s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1], x);
+s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1 + offset], 
x);
 } else {
 s->imdct_512.imdct_half(>imdct_512, s->tmp_output, 
s->transform_coeffs[ch]);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], 

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Dave Rice]

> On Mar 27, 2018, at 4:33 PM, wm4  wrote:
> 
> On Tue, 27 Mar 2018 16:11:11 -0400
> Dave Rice  wrote:
> 
>>> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis  
>>> wrote:
>>> 
>>> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:  
 I think we should drop the internal crap if the tools and the API support
 it. Would also solve a lot of issues like ffmpeg.c not trimming the start
 frame (so people complain all the time about longer files).  
>>> 
>>> I personally agree, but I thought I'd be diplomatic about it, since it would
>>> technically be losing a 'feature', since it would no longer Just Work(ish)
>>> and require user applications to apply timelines themselves - and I figured
>>> some would argue that point.  
>> 
>> +1 I’m willing to contribute what information or samples would be needed to 
>> help with Matroska support with virtual timelines. IMO, this would be a 
>> valuable feature to have in ffmpeg.
>> Dave Rice
> 
> Some explanations how this interacts with editions would be good.

I put an example with two editions at 
https://archive.org/download/chapters_test/chapters_test.mkv which mimics a 
digitized video tape. One edition depicts the stored video encoding in its 
entire presentation and the other default edition plays from the video encoding 
selectively. When the file is played in VLC, the default edition is used to 
show a shortened presentation, but the other editions may be selected within 
the Program menu option. In the proposal there should be an option to mimic the 
current behavior and ignore the editions (equivalent of -ignore_editlist in 
mov), to use the first default edition, or to select a specific edition.

> Or documenting ordered chapters and segment linking in the mkv "spec"
> at all.

This document, http://mod16.org/hurfdurf/?p=8 , 
 is unofficially a good resource on that.

More officially the Cellar working group has this section on Linked Segments: 
https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-23 
, and 
this one on Ordered Editions: 
https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#section-10.1.2.3 
. 
This documentation is a work in progress so comments/reviews/suggestions are 
welcome (issues can be filed at 
https://github.com/Matroska-Org/matroska-specification 
 or via 
https://www.ietf.org/mailman/listinfo/cellar 
).

Dave Rice

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

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Michael Niedermayer]

On Tue, Mar 27, 2018 at 01:31:43AM +0100, Mark Thompson wrote:
> On 27/03/18 01:20, Michael Niedermayer wrote:
> > On Sun, Mar 25, 2018 at 06:41:34PM +0100, Mark Thompson wrote:
> >> Allows insertion (from side data), extraction (to side data), and removal
> >> of closed captions in SEI messages.
> >> ---
> >>  libavcodec/Makefile|   2 +-
> >>  libavcodec/h264_metadata_bsf.c | 138 
> >> +
> >>  2 files changed, 139 insertions(+), 1 deletion(-)
> > 
> > This breaks build on mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5
> > 
> > 
> > In file included from src/libavcodec/cbs_misc.c:25:
> > src/libavcodec/cbs_misc.h:73: warning: declaration does not declare anything
> > src/libavcodec/cbs_misc.h:86: warning: declaration does not declare anything
> > In file included from src/libavcodec/cbs_misc.c:57:
> > src/libavcodec/cbs_misc_syntax_template.c: In function 
> > ‘cbs_misc_read_a53_atsc_user_data’:
> > src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
> > no member named ‘cc_data’
> > src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
> > no member named ‘bar_data’
> > src/libavcodec/cbs_misc_syntax_template.c: In function 
> > ‘cbs_misc_read_a53_user_data’:
> > src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
> > member named ‘atsc’
> > src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
> > member named ‘afd’
> > In file included from src/libavcodec/cbs_misc.c:82:
> > src/libavcodec/cbs_misc_syntax_template.c: In function 
> > ‘cbs_misc_write_a53_atsc_user_data’:
> > src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
> > no member named ‘cc_data’
> > src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
> > no member named ‘bar_data’
> > src/libavcodec/cbs_misc_syntax_template.c: In function 
> > ‘cbs_misc_write_a53_user_data’:
> > src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
> > member named ‘atsc’
> > src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
> > member named ‘afd’
> > src/libavcodec/cbs_misc.c: In function ‘ff_cbs_read_a53_cc_side_data’:
> > src/libavcodec/cbs_misc.c:153: error: unknown field ‘atsc’ specified in 
> > initializer
> > src/libavcodec/cbs_misc.c:153: error: extra brace group at end of 
> > initializer
> > src/libavcodec/cbs_misc.c:153: error: (near initialization for 
> > ‘(anonymous)’)
> > src/libavcodec/cbs_misc.c:156: error: extra brace group at end of 
> > initializer
> > src/libavcodec/cbs_misc.c:156: error: (near initialization for 
> > ‘(anonymous)’)
> > src/libavcodec/cbs_misc.c:165: warning: excess elements in struct 
> > initializer
> > src/libavcodec/cbs_misc.c:165: warning: (near initialization for 
> > ‘(anonymous)’)
> > src/libavcodec/cbs_misc.c:167: error: ‘A53UserData’ has no member named 
> > ‘atsc’
> > src/libavcodec/cbs_misc.c: In function ‘ff_cbs_write_a53_cc_side_data’:
> > src/libavcodec/cbs_misc.c:193: error: ‘A53UserData’ has no member named 
> > ‘atsc’
> > src/libavcodec/cbs_misc.c:196: error: ‘A53UserData’ has no member named 
> > ‘atsc’
> > CC  libavcodec/dpxenc.o
> > CC  libavcodec/dpx_parser.o
> > make: *** [libavcodec/cbs_misc.o] Error 1
> > make: *** Waiting for unfinished jobs
> > src/libavcodec/dnxhddec.c:146: warning: ‘dnxhd_decode_init_thread_copy’ 
> > defined but not used
> > src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_init’:
> > src/libavcodec/dnxhdenc.c:518: warning: ‘coded_frame’ is deprecated 
> > (declared at src/libavcodec/avcodec.h:2760)
> > src/libavcodec/dnxhdenc.c:519: warning: ‘coded_frame’ is deprecated 
> > (declared at src/libavcodec/avcodec.h:2760)
> > src/libavcodec/dnxhdenc.c: In function ‘dnxhd_load_picture’:
> > src/libavcodec/dnxhdenc.c:1272: warning: ‘coded_frame’ is deprecated 
> > (declared at src/libavcodec/avcodec.h:2760)
> > src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_picture’:
> > src/libavcodec/dnxhdenc.c:1337: warning: ‘coded_frame’ is deprecated 
> > (declared at src/libavcodec/avcodec.h:2760)
> > src/libavcodec/dpxenc.c: In function ‘encode_frame’:
> > src/libavcodec/dpxenc.c:180: warning: ‘need_align’ may be used 
> > uninitialized in this function
> > src/libavcodec/dpxenc.c:180: warning: ‘len’ may be used uninitialized in 
> > this function
> > 
> > 
> > [...]
> 
> Do you happen to know what set of compilers lack anonymous union support like 
> this?  It's quite tempting to add a configure option to just not build it for 
> them.

I dont know which compilers, in the sense of names and versions but

anonymous unions are AFAIK C11, so compilers that support just C99 could
fail.
I think we should not drop support for pure C99 compilers yet. Doing that
would also require better understanding the impact ...

thanks

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

Elect your leaders based on what they did 

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[wm4]

On Tue, 27 Mar 2018 16:11:11 -0400
Dave Rice  wrote:

> > On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis  
> > wrote:
> > 
> > On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:  
> >> I think we should drop the internal crap if the tools and the API support
> >> it. Would also solve a lot of issues like ffmpeg.c not trimming the start
> >> frame (so people complain all the time about longer files).  
> > 
> > I personally agree, but I thought I'd be diplomatic about it, since it would
> > technically be losing a 'feature', since it would no longer Just Work(ish)
> > and require user applications to apply timelines themselves - and I figured
> > some would argue that point.  
> 
> +1 I’m willing to contribute what information or samples would be needed to 
> help with Matroska support with virtual timelines. IMO, this would be a 
> valuable feature to have in ffmpeg.
> Dave Rice

Some explanations how this interacts with editions would be good.
Or documenting ordered chapters and segment linking in the mkv "spec"
at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/5] avformat/utils: make AVPacketList helper functions shared

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 03:02:35PM -0300, James Almer wrote:
> Based on a patch by Luca Barbato.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/internal.h | 35 ++
>  libavformat/utils.c| 51 
> +++---
>  2 files changed, 63 insertions(+), 23 deletions(-)
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index a020b1b417..7e1b24ebe6 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -731,6 +731,41 @@ int ff_unlock_avformat(void);
>   */
>  void ff_format_set_url(AVFormatContext *s, char *url);
>  
> +/**
> + * Append an AVPacket to the list.
> + *

> + * @param head List head
> + * @param tail List tail

about the terminology
Shouldnt this be a single List element or 2 ListEntry elements ?


> + * @param pkt  The packet being appended
> + * @param ref  Create a new reference for the packet instead of
> +   transferring the ownership of the existing one to the
> + * list.

> + * @return < 0 on failure and 0 on success

if its an AVERROR code on failure this should be documented, ATM it just
says some unspecifified negative value


> + */
> +int ff_packet_list_put(AVPacketList **head, AVPacketList **tail,
> +   AVPacket *pkt, int ref);

ref should not be a int but a enum
ff_packet_list_put(,,,1)
ff_packet_list_put(,,,0)

is alot more confusing to a new developer than with english words
the code should be self explanatory not requiring looking up the
documentation

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Rostislav Pehlivanov]

On 27 March 2018 at 21:01, Derek Buitenhuis 
wrote:

> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
> > I think we should drop the internal crap if the tools and the API support
> > it. Would also solve a lot of issues like ffmpeg.c not trimming the start
> > frame (so people complain all the time about longer files).
>
> I personally agree, but I thought I'd be diplomatic about it, since it
> would
> technically be losing a 'feature', since it would no longer Just Work(ish)
> and require user applications to apply timelines themselves - and I figured
> some would argue that point.
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

It wouldn't be breaking anything - technically making this part of lavf in
the first place and enabling it by default broke behaviour. API users had
to disable it for which there was no option to do so until after it was
merged, IIRC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] avformat/mp3enc: use AVPacketList helper functions to queue packets

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 03:02:39PM -0300, James Almer wrote:
> Simplifies code.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/mp3enc.c | 23 +++
>  1 file changed, 7 insertions(+), 16 deletions(-)

LGTM

thx



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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Dave Rice]

> On Mar 27, 2018, at 4:01 PM, Derek Buitenhuis  
> wrote:
> 
> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
>> I think we should drop the internal crap if the tools and the API support
>> it. Would also solve a lot of issues like ffmpeg.c not trimming the start
>> frame (so people complain all the time about longer files).
> 
> I personally agree, but I thought I'd be diplomatic about it, since it would
> technically be losing a 'feature', since it would no longer Just Work(ish)
> and require user applications to apply timelines themselves - and I figured
> some would argue that point.

+1 I’m willing to contribute what information or samples would be needed to 
help with Matroska support with virtual timelines. IMO, this would be a 
valuable feature to have in ffmpeg.
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Paul B Mahol]

On 3/27/18, Derek Buitenhuis  wrote:
> On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
>> I think we should drop the internal crap if the tools and the API support
>> it. Would also solve a lot of issues like ffmpeg.c not trimming the start
>> frame (so people complain all the time about longer files).
>
> I personally agree, but I thought I'd be diplomatic about it, since it would
> technically be losing a 'feature', since it would no longer Just Work(ish)
> and require user applications to apply timelines themselves - and I figured
> some would argue that point.

Lost is minimal if ffmpeg.c have it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Derek Buitenhuis]

On 3/27/2018 8:52 PM, Rostislav Pehlivanov wrote:
> I think we should drop the internal crap if the tools and the API support
> it. Would also solve a lot of issues like ffmpeg.c not trimming the start
> frame (so people complain all the time about longer files).

I personally agree, but I thought I'd be diplomatic about it, since it would
technically be losing a 'feature', since it would no longer Just Work(ish)
and require user applications to apply timelines themselves - and I figured
some would argue that point.

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

Re: [FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Rostislav Pehlivanov]

On 27 March 2018 at 20:44, Derek Buitenhuis 
wrote:

> So, I know we have edit list "support" in mov.c, but I am steadfast in my
> belief that it is incorrect to implement it at the demuxing layer. By the
> ISOBMFF spec, it is supposed to be applied at the presenattion layer. I'm
> aware we probably cannot remove the current implementation very easily
> (or at all?) because many will argue it is "removing a feature". Thus, for
> ISOBMFF and mov support, this will likely have to live under a movflag,
> I assume?
>
> Anyway, this is my proposal for generic stream side data for virtual
> timelines.
> This is also meant to cover Matroska ordered chapters and editions, though
> I
> am not entirely sure how segment linking would work into this, if I am
> honest.
>
> If/once I have the side data structs and API (in the following RFC patch)
> agreed
> upon, I am willing to write:
>
> * Support for exporting MOV/ISOBMFF edit lists via side data
> * Support for exporting Matroska edit lists via side data
> * Porting the fftools to use it (if wanted)
>
> As a side note, I would appreciate input from someone who unerstands
> Matroska
> better than I do on this. I haven't included e.g. the Hidden/Enabled flags
> in
> AVtimelineEntry since they don't seem to actually be useful to the actual
> timeline (they seem to be mostly related to displaying chapter names or
> not).
>
> The side data structs and API are based off of the recently pushed
> encryption
> side data changes. The media rate is a rational, because exporting a float
> would change on different platforms, and would make adding regression tests
> problematic.
>
> So, everyone, rev up your diesel powered bikesheds and drive them full
> steam
> into this thread's back yard, over my daffodils.
>
> Derek Buitenhuis (1):
>   avcodec/avutil: Add timeline side data
>
>  libavcodec/avcodec.h |   8 +++
>  libavutil/timeline.h | 160 ++
> +
>  2 files changed, 168 insertions(+)
>  create mode 100644 libavutil/timeline.h
>
> --
> 1.8.3.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


I think we should drop the internal crap if the tools and the API support
it. Would also solve a lot of issues like ffmpeg.c not trimming the start
frame (so people complain all the time about longer files).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] avfilter: add OpenCL scale filter

[Gabriel Machado]

> > +__kernel void bilinear(__write_only image2d_t dst,
> > +   __read_only  image2d_t src)
> > +{
> > +const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
> > +   CLK_ADDRESS_CLAMP_TO_EDGE |
> > +   CLK_FILTER_LINEAR);
> > +
> > +int2 coord = {get_global_id(0), get_global_id(1)};
> > +int2 size = {get_global_size(0), get_global_size(1)};
> > +
> > +float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
> >

>
> Doesn't opencl have an option to use a sampler with non-normalized
> addressing mode?

Using CLK_NORMALIZED_COORDS_FALSE and mapping the output position to the input
position works just as fine:
float2 pos = (convert_float2(coord) + 0.5) * (src_size / dst_size);

Is that what you mean?


> You completely ignored what I said. This function doesn't have a license,
> you can't use it in a modified form. Either rewrite it or remove it.

Rewrote it based on the code in libswscale/utils.c

---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/scale.cl   | 113 +
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_scale_opencl.c | 284 ++
 6 files changed, 401 insertions(+)
 create mode 100644 libavfilter/opencl/scale.cl
 create mode 100644 libavfilter/vf_scale_opencl.c

diff --git a/configure b/configure
index 5ccf3ce..4007ee8 100755
--- a/configure
+++ b/configure
@@ -2821,6 +2821,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
 
 hwupload_cuda_filter_deps="ffnvcodec"
 scale_npp_filter_deps="ffnvcodec libnpp"
+scale_opencl_filter_deps="opencl"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..6303cbd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o opencl.o 
opencl/scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1cf1340..3185b17 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -309,6 +309,7 @@ static void register_all(void)
 REGISTER_FILTER(SCALE,  scale,  vf);
 REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
 REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
+REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
 REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
 REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
 REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
new file mode 100644
index 000..777344e
--- /dev/null
+++ b/libavfilter/opencl/scale.cl
@@ -0,0 +1,113 @@
+/*
+ * Copyright (c) 2018 Gabriel Machado
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+__kernel void neighbor(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+__kernel void bilinear(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   

[FFmpeg-devel] [PATCH 1/2] avcodec/eac3: add support for dependent stream

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/ac3_parser.c |   2 +-
 libavcodec/ac3dec.c | 167 +++-
 libavcodec/ac3dec.h |   9 ++-
 libavcodec/eac3dec.c|  11 +---
 4 files changed, 147 insertions(+), 42 deletions(-)

diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1015245a90..f4618bf215 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -218,8 +218,8 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext 
*hdr_info,
 else if (hdr_info->codec_id == AV_CODEC_ID_NONE)
 hdr_info->codec_id = AV_CODEC_ID_AC3;
 
-*need_next_header = (hdr.frame_type != EAC3_FRAME_TYPE_AC3_CONVERT);
 *new_frame_start  = (hdr.frame_type != EAC3_FRAME_TYPE_DEPENDENT);
+*need_next_header = *new_frame_start || (hdr.frame_type != 
EAC3_FRAME_TYPE_AC3_CONVERT);
 return hdr.frame_size;
 }
 
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 244a18323f..e208ec3568 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -106,6 +106,25 @@ static const uint8_t ac3_default_coeffs[8][5][2] = {
 { { 2, 7 }, { 5, 5 }, { 7, 2 }, { 6, 7 }, { 7, 6 }, },
 };
 
+static const uint64_t custom_channel_map_locations[16][2] = {
+{ 1, AV_CH_FRONT_LEFT },
+{ 1, AV_CH_FRONT_CENTER },
+{ 1, AV_CH_FRONT_RIGHT },
+{ 1, AV_CH_SIDE_LEFT },
+{ 1, AV_CH_SIDE_RIGHT },
+{ 0, AV_CH_FRONT_LEFT_OF_CENTER | AV_CH_FRONT_RIGHT_OF_CENTER },
+{ 0, AV_CH_BACK_LEFT | AV_CH_BACK_RIGHT },
+{ 0, AV_CH_BACK_CENTER },
+{ 0, AV_CH_TOP_CENTER },
+{ 0, AV_CH_SURROUND_DIRECT_LEFT | AV_CH_SURROUND_DIRECT_RIGHT },
+{ 0, AV_CH_WIDE_LEFT | AV_CH_WIDE_RIGHT },
+{ 0, AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT},
+{ 0, AV_CH_TOP_FRONT_CENTER },
+{ 0, AV_CH_TOP_BACK_LEFT | AV_CH_TOP_BACK_RIGHT },
+{ 0, AV_CH_LOW_FREQUENCY_2 },
+{ 1, AV_CH_LOW_FREQUENCY },
+};
+
 /**
  * Symmetrical Dequantization
  * reference: Section 7.3.3 Expansion of Mantissas for Symmetrical Quantization
@@ -317,6 +336,7 @@ static int parse_frame_header(AC3DecodeContext *s)
 s->fbw_channels = s->channels - s->lfe_on;
 s->lfe_ch   = s->fbw_channels + 1;
 s->frame_size   = hdr.frame_size;
+s->superframe_size += hdr.frame_size;
 s->preferred_downmix= AC3_DMIXMOD_NOTINDICATED;
 s->center_mix_level = hdr.center_mix_level;
 s->center_mix_level_ltrt= 4; // -3.0dB
@@ -683,7 +703,7 @@ static void do_rematrixing(AC3DecodeContext *s)
  * Convert frequency domain coefficients to time-domain audio samples.
  * reference: Section 7.9.4 Transformation Equations
  */
-static inline void do_imdct(AC3DecodeContext *s, int channels)
+static inline void do_imdct(AC3DecodeContext *s, int channels, int offset)
 {
 int ch;
 
@@ -695,25 +715,25 @@ static inline void do_imdct(AC3DecodeContext *s, int 
channels)
 x[i] = s->transform_coeffs[ch][2 * i];
 s->imdct_256.imdct_half(>imdct_256, s->tmp_output, x);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
 for (i = 0; i < 128; i++)
 x[i] = s->transform_coeffs[ch][2 * i + 1];
-s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1], x);
+s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1 + offset], 
x);
 } else {
 s->imdct_512.imdct_half(>imdct_512, s->tmp_output, 
s->transform_coeffs[ch]);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
-memcpy(s->delay[ch - 1], s->tmp_output + 128, 128 * 
sizeof(FFTSample));
+memcpy(s->delay[ch - 1 + offset], s->tmp_output + 128, 128 * 
sizeof(FFTSample));
 }
 }
 }
@@ -1063,7 +1083,7 @@ static inline int coupling_coordinates(AC3DecodeContext 
*s, int blk)
 /**
  * Decode a single audio block from the AC-3 bitstream.
  */
-static int decode_audio_block(AC3DecodeContext *s, int blk)
+static int decode_audio_block(AC3DecodeContext *s, int blk, int 

[FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
 libavcodec/avcodec.h |   8 +++
 libavutil/timeline.h | 160 +++
 2 files changed, 168 insertions(+)
 create mode 100644 libavutil/timeline.h

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 50c34db..6f54495 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1358,6 +1358,14 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_ENCRYPTION_INFO,
 
 /**
+ * This side data contains timeline entries for a given stream. This type
+ * will only apear as stream side data.
+ *
+ * The format is not part of the ABI, use av_timeline_* method to access.
+ */
+AV_PKT_DATA_TIMELINE,
+
+/**
  * The number of side data types.
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
diff --git a/libavutil/timeline.h b/libavutil/timeline.h
new file mode 100644
index 000..f1f3e1b
--- /dev/null
+++ b/libavutil/timeline.h
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2018 Derek Buitenhuis
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVUTIL_TIMELINE_H
+#define AVUTIL_TIMELINE_H
+
+#include 
+#include 
+
+#include "rational.h"
+
+typedef struct AVTimelineEntry {
+/**
+ * The start time of the given timeline entry, in stream timebase units.
+ * If this value is AV_NOPTS_VALUE, you must display black for the duration
+ * of the entry. For audio, silence must be played.
+ */
+int64_t start;
+
+/**
+ * The duration of the given timeline entry, in steam timebase units.
+ */
+int64_t duration;
+
+/**
+ * The rate at which this entry should be played back. The value is a 
multipier
+ * of the stream's rate, for example: 1.2 means play back this entry at 
1.2x speed.
+ * If this value is 0, then the first sample (located at 'start') must be 
displayed
+ * for the duration of the entry.
+ */
+AVRational media_rate;
+} AVTimelineEntry;
+
+/**
+ * Describes a timeline for a stream in terms of edits/entries. Each entry 
must be
+ * played back in order, according to the information in each. Each stream may 
have
+ * multiple timelines which need to be correlated between different streams.
+ */
+typedef struct AVTimeline {
+/**
+ * The ID of a given timeline. Since each stream may have multiple 
timelines
+ * defined, this value is used to correlated different streams' timelines
+ * which should be used together. For example, if one has two streams,
+ * one video, and one audio, with two timelines each, the timelines
+ * with matching IDs should be used in conjuction, to assure everything
+ * is in sync and matches. The concept is similar to that of EditionUID
+ * in Matroska.
+ */
+uint32_t id;
+
+/**
+ * An in-order array of entries for the given timeline.
+ * Each entry contains information on which samples to display for a
+ * particular edit.
+ */
+AVTimelineEntry *entries;
+
+/**
+ * Number of entries in the timeline.
+ */
+size_t entry_count;
+} AVTimeline;
+
+typedef struct AVTimelineList {
+/**
+ * An array of timelines associated with the stream.
+ */
+AVTimeline *timelines;
+
+/**
+ * Then number of timelines associated with the stream.
+ */
+size_t timeline_count;
+} AVTimelineList;
+
+/**
+ * Allocates an AVTimeline strcture with the requested number of entires.
+ *
+ * @param entry_count The number of entries in the timeline.
+ *
+ * @return The new AVTimeline structure, or NULL on error.
+ */
+AVTimeline *av_timeline_alloc(size_t entry_count);
+
+
+/**
+ * Frees an AVTimeline structure and its members.
+ *
+ * @param timeline The AVTimeline structure to free.
+ */
+void av_timeline_free(AVTimeline *timeline);
+
+/**
+ * Allocates an AVTimeline strcture with room for the request number of 
timelines.
+ *
+ * @param timeline_count The number of entries in the timeline.
+ *
+ * @return The new AVTimelineList structure, or NULL on error.
+ */
+AVTimelineList *av_timeline_list_alloc(size_t timeline_count);
+
+
+/**
+ * Frees an AVTimelineList structure and its timelines, and their entries.
+ 

[FFmpeg-devel] [RFC] Exporting virtual timelines as stream side data

[Derek Buitenhuis]

So, I know we have edit list "support" in mov.c, but I am steadfast in my
belief that it is incorrect to implement it at the demuxing layer. By the
ISOBMFF spec, it is supposed to be applied at the presenattion layer. I'm
aware we probably cannot remove the current implementation very easily
(or at all?) because many will argue it is "removing a feature". Thus, for
ISOBMFF and mov support, this will likely have to live under a movflag,
I assume?

Anyway, this is my proposal for generic stream side data for virtual timelines.
This is also meant to cover Matroska ordered chapters and editions, though I
am not entirely sure how segment linking would work into this, if I am honest.

If/once I have the side data structs and API (in the following RFC patch) agreed
upon, I am willing to write:

* Support for exporting MOV/ISOBMFF edit lists via side data
* Support for exporting Matroska edit lists via side data
* Porting the fftools to use it (if wanted)

As a side note, I would appreciate input from someone who unerstands Matroska
better than I do on this. I haven't included e.g. the Hidden/Enabled flags in
AVtimelineEntry since they don't seem to actually be useful to the actual
timeline (they seem to be mostly related to displaying chapter names or not).

The side data structs and API are based off of the recently pushed encryption
side data changes. The media rate is a rational, because exporting a float
would change on different platforms, and would make adding regression tests
problematic.

So, everyone, rev up your diesel powered bikesheds and drive them full steam
into this thread's back yard, over my daffodils.

Derek Buitenhuis (1):
  avcodec/avutil: Add timeline side data

 libavcodec/avcodec.h |   8 +++
 libavutil/timeline.h | 160 +++
 2 files changed, 168 insertions(+)
 create mode 100644 libavutil/timeline.h

-- 
1.8.3.1

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

Re: [FFmpeg-devel] State of decklink_ctx vs. decklink_cctx

[Devin Heitmueller]

Hi Grady,

> On Mar 27, 2018, at 3:05 PM, grady player  wrote:
> 
> So I haven't looked in great detail so this may all be info that you know, 
> and maybe not helpful...
> 
> 1. You can easily link C objects to C++ code by marking it `extern "C"`
> 2. You can not easily link C++ objects to C code, because there are classes, 
> vtables, name mangling etc.
> 3. The solution for this interop is usually a shim layer that is compiled in 
> C++ and has a C interface, and is imported as extern "C" so the names aren't 
> mangled.
> 4. there are  2 common headers for decklink, one that can contain C++ symbols 
> and one that contains only C symbols ( `IDeckLink`  is a c++ class and can't 
> be included C Code)

Right.  My goal was to confirm the purpose of the two structs really was 
entirely about the issues related to referencing C++ stuff from within C.

> 
> So I don't know how you would really combine everything... you could keep the 
> all of the DeckLink classes in the decklink_cctx as (void *) but that isn't 
> elegant.

Ugh, no.  That is definitely not what I want to do.  See below.

> The only thing that seems useful would be de-duplication of the duplicate 
> fields and if those are only for state to be read on opening, then I dont 
> know that is exactly useful either,
> but you could make an options struct and keep one ref to it in both contexts, 
> they are similar but slightly different...

To be clear, I’m not saying that the two structs should be combined into one.  
What I’m proposing is refactoring to eliminate any duplicate members between 
the two, and move everything that isn’t C++ into the decklink_cctx, so that the 
*only* things that are specified in decklink_ctx are the C++ members.  That 
eliminates any ambiguity about which struct should be used.

For the most part, I’m just trying to understand if the members were duplicated 
intentionally across both structs for some good reason that isn’t obvious, or 
if it was just an oversight or misunderstanding as to the role of the two 
structs.

Regards,

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

Re: [FFmpeg-devel] State of decklink_ctx vs. decklink_cctx

[grady player]

So I haven't looked in great detail so this may all be info that you know, and 
maybe not helpful...

1. You can easily link C objects to C++ code by marking it `extern "C"`
2. You can not easily link C++ objects to C code, because there are classes, 
vtables, name mangling etc.
3. The solution for this interop is usually a shim layer that is compiled in 
C++ and has a C interface, and is imported as extern "C" so the names aren't 
mangled.
4. there are  2 common headers for decklink, one that can contain C++ symbols 
and one that contains only C symbols ( `IDeckLink`  is a c++ class and can't be 
included C Code)

So I don't know how you would really combine everything... you could keep the 
all of the DeckLink classes in the decklink_cctx as (void *) but that isn't 
elegant.
The only thing that seems useful would be de-duplication of the duplicate 
fields and if those are only for state to be read on opening, then I dont know 
that is exactly useful either,
but you could make an options struct and keep one ref to it in both contexts, 
they are similar but slightly different...


> On Mar 27, 2018, at 12:27 PM, Devin Heitmueller  
> wrote:
> 
> Hello,
> 
> I’m continuing to do some cleanup work on the decklink libavdevice 
> input/output, and I’m trying to understand how the way state is managed has 
> evolved over time.
> 
> Specifically, there are two key state structures - decklink_ctx and 
> decklink_cctx.  It would appear the motivation behind this was to store any 
> C++ members (mainly stuff exported by the Blackmagic driver) in a context 
> which doesn’t need to be accessed by the C code.  At one point I had assumed 
> the decklink_cctx was intended for the “capture" specific features (as 
> opposed to output), but after further review it looks like the goal is not 
> exposing the C++ members to the C code.
> 
> My concern is that I’m seeing a couple of trends:
> 
> 1.  Lots of C members appearing in the decklink_ctx state (i.e. stuff that 
> could be in decklink_cctx).  Presumably if the goal was to partition the C++ 
> stuff out, why not put everything except the actual C++ members into the 
> decklink_cctx state?
> 
> 2.  Duplicate members between the two state structs.  Both structs contain a 
> number of the same members (e.g. list_devices, list_formats, etc).  In some 
> cases the members are copied from one to the other after initialization, but 
> it’s not clear why the members are duplicated in the first place - why not 
> just reference the original member?
> 
> Can anyone offer any background on how this evolved?  I would like to see if 
> I can improve the situation, but I need to better understand what the goal(s) 
> were.  Also as I’m adding new features to both capture and output, it would 
> be good to better understand which of the two structs is appropriate to own 
> the state information.
> 
> Thanks in advance,
> 
> Devin
> 
> ---
> Devin Heitmueller - LTN Global Communications
> dheitmuel...@ltnglobal.com
> 
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] State of decklink_ctx vs. decklink_cctx

[Devin Heitmueller]

Hello,

I’m continuing to do some cleanup work on the decklink libavdevice 
input/output, and I’m trying to understand how the way state is managed has 
evolved over time.

Specifically, there are two key state structures - decklink_ctx and 
decklink_cctx.  It would appear the motivation behind this was to store any C++ 
members (mainly stuff exported by the Blackmagic driver) in a context which 
doesn’t need to be accessed by the C code.  At one point I had assumed the 
decklink_cctx was intended for the “capture" specific features (as opposed to 
output), but after further review it looks like the goal is not exposing the 
C++ members to the C code.

My concern is that I’m seeing a couple of trends:

1.  Lots of C members appearing in the decklink_ctx state (i.e. stuff that 
could be in decklink_cctx).  Presumably if the goal was to partition the C++ 
stuff out, why not put everything except the actual C++ members into the 
decklink_cctx state?

2.  Duplicate members between the two state structs.  Both structs contain a 
number of the same members (e.g. list_devices, list_formats, etc).  In some 
cases the members are copied from one to the other after initialization, but 
it’s not clear why the members are duplicated in the first place - why not just 
reference the original member?

Can anyone offer any background on how this evolved?  I would like to see if I 
can improve the situation, but I need to better understand what the goal(s) 
were.  Also as I’m adding new features to both capture and output, it would be 
good to better understand which of the two structs is appropriate to own the 
state information.

Thanks in advance,

Devin

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com




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

Re: [FFmpeg-devel] [PATCH 4/5] mpeg2_metadata: Add support for A/53 closed captions

[Aman Gupta]

On Sun, Mar 25, 2018 at 10:41 AM, Mark Thompson  wrote:

> Allows extraction (to side data) and removal of closed captions in
> user data blocks.
> ---
>  doc/bitstream_filters.texi  | 12 ++
>  libavcodec/Makefile |  2 +-
>  libavcodec/mpeg2_metadata_bsf.c | 81 ++
> ++-
>  3 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 41424cf42f..f115f7b0c5 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -465,6 +465,18 @@ table 6-6).
>  Set the colour description in the stream (see H.262 section 6.3.6
>  and tables 6-7, 6-8 and 6-9).
>
> +@item a53_cc
> +Modify A/53 closed captions in user data blocks.
> +
> +@table @samp
> +@item remove
> +Remove all closed caption data from the stream.
> +
> +@item extract
> +Extract closed captions from the stream so that they are available as
> +as packet side data.
> +@end table
> +
>  @end table
>
>  @section mpeg4_unpack_bframes
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index cfde104055..e5430ab10b 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1057,7 +1057,7 @@ OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF)   +=
> mpeg4_unpack_bframes_bsf.o
>  OBJS-$(CONFIG_MOV2TEXTSUB_BSF)+= movsub_bsf.o
>  OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += mp3_header_decompress_bsf.o
> \
>   mpegaudiodata.o
> -OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o
> +OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o
> cbs_misc.o
>  OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
>  OBJS-$(CONFIG_NULL_BSF)   += null_bsf.o
>  OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
> diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_
> bsf.c
> index e787cb3782..49335d7fcb 100644
> --- a/libavcodec/mpeg2_metadata_bsf.c
> +++ b/libavcodec/mpeg2_metadata_bsf.c
> @@ -22,9 +22,17 @@
>
>  #include "bsf.h"
>  #include "cbs.h"
> +#include "cbs_misc.h"
>  #include "cbs_mpeg2.h"
>  #include "mpeg12.h"
>
> +enum {
> +PASS,
> +INSERT,
> +REMOVE,
> +EXTRACT,
> +};
> +
>  typedef struct MPEG2MetadataContext {
>  const AVClass *class;
>
> @@ -42,6 +50,8 @@ typedef struct MPEG2MetadataContext {
>  int transfer_characteristics;
>  int matrix_coefficients;
>
> +int a53_cc;
> +
>  int mpeg1_warned;
>  } MPEG2MetadataContext;
>
> @@ -184,7 +194,9 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  MPEG2MetadataContext *ctx = bsf->priv_data;
>  AVPacket *in = NULL;
>  CodedBitstreamFragment *frag = >fragment;
> -int err;
> +int err, i;
> +uint8_t *a53_side_data = NULL;
> +size_t a53_side_data_size = 0;
>
>  err = ff_bsf_get_packet(bsf, );
>  if (err < 0)
> @@ -202,6 +214,51 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
>  goto fail;
>  }
>
> +if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
> +for (i = 0; i < frag->nb_units; i++) {
> +MPEG2RawUserData *ud;
> +A53UserData a53_ud;
> +
> +if (frag->units[i].type != MPEG2_START_USER_DATA)
> +continue;
> +ud = frag->units[i].content;
> +
> +err = ff_cbs_read_a53_user_data(ctx->cbc, _ud,
> ud->user_data,
> +ud->user_data_length);
> +if (err < 0) {
> +// Invalid or something completely different.
> +continue;
> +}
> +if (a53_ud.user_identifier != A53_USER_IDENTIFIER_ATSC ||
> +a53_ud.atsc.user_data_type_code !=
> +A53_USER_DATA_TYPE_CODE_CC_DATA) {
> +// Valid but something else (e.g. AFD).
> +continue;
> +}
> +
> +if (ctx->a53_cc == REMOVE) {
> +err = ff_cbs_delete_unit(ctx->cbc, frag, i);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to delete "
> +   "A/53 CC user data.\n");
> +goto fail;
> +}
> +--i;
> +break;
> +} else if(ctx->a53_cc == EXTRACT) {
> +err = ff_cbs_write_a53_cc_side_data(ctx->cbc,
> +_side_data,
> +_side_data_size,
> +_ud);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to write "
> +   "A/53 user data for packet side data.\n");
> +goto fail;
> +}
> +}
> +}
> +}
> +
>  err = ff_cbs_write_packet(ctx->cbc, out, frag);
>

Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API

[wm4]

On Tue, 27 Mar 2018 14:16:15 -0300
James Almer  wrote:

> On 3/20/2018 7:44 PM, James Almer wrote:
> > On 3/16/2018 3:21 PM, James Almer wrote:  
> >> Signed-off-by: James Almer 
> >> ---
> >> This is a proof of concept for a dynamic size buffer pool API.
> >>
> >> For the purpose of easy testing and reviewing I replaced the current
> >> linked list used to keep a pool of fixed size buffers with the tree
> >> based pool that will be used to keep a pool of varying size buffers,
> >> instead of adding a new set of functions exclusively for the new API.
> >> The final committed work doesn't necessarely have to do the above, as
> >> there's no real benefit using a tree when you only need a fixed size
> >> buffer pool, other than simplying things.
> >>
> >> I'm open to suggestions about how to introduce this. Completely
> >> separate set of functions and struct names? Sharing the struct and
> >> init/uninit functions and only adding a new get() one like in this
> >> patch?
> >> Any preferences with function/struct naming, for that matter?  
> > 
> > Ping?  
> 
> No comments or preferences at all on how to introduce this?

Well, it's a pretty big mess (so many things to consider). That's
mostly about the implementation details.

I think the API you picked is relatively nice. It feels weird that a
pool that is initialized with a size has a function to allocate buffers
with a different size. So if you want some bikeshedding, sure, I can
provide you with some colors:

 AVDynamicBufferPool *av_dynamic_buffer_pool_create(alloc_fn, free_fn);
 AVBufferRef *av_dynamic_buffer_pool_get(AVDynamicBufferPool *pool,
 size_t size);
 void av_dynamic_buffer_pool_uininit(AVDynamicBufferPool **pool);

or:

 // sets *pool if it was NULL
 // (where to put alloc/free FNs for custom alloc?)
 AVBufferRef *av_dynamic_buffer_pool_get(AVDynamicBufferPool **pool,
 size_t size);
 void av_dynamic_buffer_pool_uininit(AVDynamicBufferPool **pool);

or:

  // sets *pool if it was NULL
  // free the pool with av_buffer_unref()
  AVBufferRef *av_dynamic_buffer_pool_get(AVBufferRef **pool,
 size_t size);

or just force the API user to pass size=0 to av_buffer_pool_init() and
enforce the use of the correct alloc function (fixed size/dynamic size)
at runtime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [GSOC] [PATCH] SRCNN filter

[Michael Niedermayer]

On Sun, Mar 25, 2018 at 08:04:17PM +0300, Sergey Lavrushkin wrote:
> Hello,
> 
> This is my implementation of qualification task for GSOC Super Resolution
> Filter project.
> For default x2 upsampling with provided srcnn filter following command can
> be used:
> ffmpeg -i input -vf scale=iw*2:-1,srcnn output
> Also other models for x2, x3, x4 upsampling can be specified using
> following command:
> ffmpeg -i input -vf scale=iw*factor:-1,srcnn=path_to_model output
> Configuration files with other models can be found here:
> https://drive.google.com/drive/folders/1-M9azWTtZ4egf8ndRU7Y
> _tiGP6QtN-Fp?usp=sharing
> And here are some examples of its work:
> https://drive.google.com/drive/folders/1jMVMKnre2KG0avq2zNw6
> CMqUKdPWnlQo?usp=sharing

[...]
> +#define OFFSET(x) offsetof(SRCNNContext, x)
> +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
> +static const AVOption srcnn_options[] = {
> +{ "config_file", "path to configuration file with network parameters", 
> OFFSET(config_file_path), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(srcnn);
> +
> +#define CHECK_FILE(file)if (ferror(file) || feof(file)){ \
> +av_log(context, AV_LOG_ERROR, "error reading 
> configuration file\n");\
> +fclose(file); \
> +return AVERROR(EIO); \
> +}
> +
> +#define CHECK_ALLOCATION(conv, file)if 
> (allocate_and_read_convolution_data(, file)){ \
> +av_log(context, AV_LOG_ERROR, 
> "could not allocate memory for convolutions\n"); \
> +fclose(file); \
> +return AVERROR(ENOMEM); \
> +}
> +

> +static int allocate_and_read_convolution_data(Convolution* conv, FILE* 
> config_file)
> +{
> +int32_t kernel_size = conv->output_channels * conv->size * conv->size * 
> conv->input_channels;
> +conv->kernel = av_malloc(kernel_size * sizeof(double));
> +if (!conv->kernel){
> +return 1;

this should return an AVERROR code for consistency with the rest of
the codebase


> +}

> +fread(conv->kernel, sizeof(double), kernel_size, config_file);

directly reading data types is not portable, it would for example be
endian specific
and using avio for reading may be better, though fread is as far as iam
concerned also ok

[...]
> +/**
> + * @file
> + * Default cnn weights for x2 upsampling with srcnn filter.
> + */
> +
> +/// First convolution kernel

> +static double conv1_kernel[] = {

static data should be also const, otherwise it may be changed and could cause
thread saftey issues

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API

[James Almer]

On 3/20/2018 7:44 PM, James Almer wrote:
> On 3/16/2018 3:21 PM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>> This is a proof of concept for a dynamic size buffer pool API.
>>
>> For the purpose of easy testing and reviewing I replaced the current
>> linked list used to keep a pool of fixed size buffers with the tree
>> based pool that will be used to keep a pool of varying size buffers,
>> instead of adding a new set of functions exclusively for the new API.
>> The final committed work doesn't necessarely have to do the above, as
>> there's no real benefit using a tree when you only need a fixed size
>> buffer pool, other than simplying things.
>>
>> I'm open to suggestions about how to introduce this. Completely
>> separate set of functions and struct names? Sharing the struct and
>> init/uninit functions and only adding a new get() one like in this
>> patch?
>> Any preferences with function/struct naming, for that matter?
> 
> Ping?

No comments or preferences at all on how to introduce this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 RESEND] avfilter: add OpenCL scale filter

[Rostislav Pehlivanov]

On 27 March 2018 at 16:09, Gabriel Machado  wrote:

> Sorry, my mail client corrupted the patch.
>
> ---
>  configure |   1 +
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/opencl/scale.cl   | 111 +
>  libavfilter/opencl_source.h   |   1 +
>  libavfilter/vf_scale_opencl.c | 284 ++
> 
>  6 files changed, 399 insertions(+)
>  create mode 100644 libavfilter/opencl/scale.cl
>  create mode 100644 libavfilter/vf_scale_opencl.c
>
> diff --git a/configure b/configure
> index 5ccf3ce..4007ee8 100755
> --- a/configure
> +++ b/configure
> @@ -2821,6 +2821,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
>
>  hwupload_cuda_filter_deps="ffnvcodec"
>  scale_npp_filter_deps="ffnvcodec libnpp"
> +scale_opencl_filter_deps="opencl"
>  scale_cuda_filter_deps="cuda_sdk"
>  thumbnail_cuda_filter_deps="cuda_sdk"
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a90ca30..6303cbd 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+=
> vf_sab.o
>  OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
>  OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o
> vf_scale_cuda.ptx.o
>  OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
> +OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o
> opencl.o opencl/scale.o
>  OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
>  OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
> vaapi_vpp.o
>  OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 1cf1340..3185b17 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -309,6 +309,7 @@ static void register_all(void)
>  REGISTER_FILTER(SCALE,  scale,  vf);
>  REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
>  REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
> +REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
>  REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
>  REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
>  REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
> diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
> new file mode 100644
> index 000..3436694
> --- /dev/null
> +++ b/libavfilter/opencl/scale.cl
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2018 Gabriel Machado
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +__kernel void neighbor(__write_only image2d_t dst,
> +   __read_only  image2d_t src)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
> +   CLK_ADDRESS_CLAMP_TO_EDGE |
> +   CLK_FILTER_NEAREST);
> +
> +int2 coord = {get_global_id(0), get_global_id(1)};
> +int2 size = {get_global_size(0), get_global_size(1)};
> +
> +float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
> +
> +float4 c = read_imagef(src, sampler, pos);
> +write_imagef(dst, coord, c);
> +}
> +
> +__kernel void bilinear(__write_only image2d_t dst,
> +   __read_only  image2d_t src)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
> +   CLK_ADDRESS_CLAMP_TO_EDGE |
> +   CLK_FILTER_LINEAR);
> +
> +int2 coord = {get_global_id(0), get_global_id(1)};
> +int2 size = {get_global_size(0), get_global_size(1)};
> +
> +float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
>

Doesn't opencl have an option to use a sampler with non-normalized
addressing mode?


> +
> +float4 c = read_imagef(src, sampler, pos);
> +write_imagef(dst, coord, c);
> +}
> +
> +// https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch24.html
> +float MitchellNetravali(float x, float B, float C)
>

You completely ignored what I said. This function doesn't have a license,
you can't use it in a modified form. Either rewrite it or remove it.

[FFmpeg-devel] [PATCH 2/2] avcodec: add eac3_core bitstream filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/bitstream_filters.texi |  4 
 libavcodec/Makefile|  1 +
 libavcodec/bitstream_filters.c |  1 +
 libavcodec/eac3_core_bsf.c | 52 ++
 4 files changed, 58 insertions(+)
 create mode 100644 libavcodec/eac3_core_bsf.c

diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 982e3edac8..7322af6550 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -75,6 +75,10 @@ the header stored in extradata to the key packets:
 ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v dump_extra 
out.ts
 @end example
 
+@section eac3_core
+
+Extract the core from a E-AC-3 stream, dropping extra channels.
+
 @section extract_extradata
 
 Extract the in-band extradata.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index aaef6c3ab8..8220ad855d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1041,6 +1041,7 @@ OBJS-$(CONFIG_AAC_ADTSTOASC_BSF)  += 
aac_adtstoasc_bsf.o mpeg4audio.o
 OBJS-$(CONFIG_CHOMP_BSF)  += chomp_bsf.o
 OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
 OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
+OBJS-$(CONFIG_EAC3_CORE_BSF)  += eac3_core_bsf.o
 OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o\
  h2645_parse.o
 OBJS-$(CONFIG_FILTER_UNITS_BSF)   += filter_units_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 12211225bb..18b698a85f 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -28,6 +28,7 @@ extern const AVBitStreamFilter ff_aac_adtstoasc_bsf;
 extern const AVBitStreamFilter ff_chomp_bsf;
 extern const AVBitStreamFilter ff_dump_extradata_bsf;
 extern const AVBitStreamFilter ff_dca_core_bsf;
+extern const AVBitStreamFilter ff_eac3_core_bsf;
 extern const AVBitStreamFilter ff_extract_extradata_bsf;
 extern const AVBitStreamFilter ff_filter_units_bsf;
 extern const AVBitStreamFilter ff_h264_metadata_bsf;
diff --git a/libavcodec/eac3_core_bsf.c b/libavcodec/eac3_core_bsf.c
new file mode 100644
index 00..e722339f8f
--- /dev/null
+++ b/libavcodec/eac3_core_bsf.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avcodec.h"
+#include "bsf.h"
+#include "get_bits.h"
+#include "libavutil/mem.h"
+#include "ac3_parser.h"
+
+static int eac3_core_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+uint16_t frame_size;
+uint8_t bitstream_id;
+int ret;
+
+ret = ff_bsf_get_packet_ref(ctx, pkt);
+if (ret < 0)
+return ret;
+
+ret = av_ac3_parse_header(pkt->data, pkt->size, _id, 
_size);
+if (ret < 0)
+return ret;
+pkt->size = frame_size;
+return 0;
+}
+
+static const enum AVCodecID codec_ids[] = {
+AV_CODEC_ID_EAC3, AV_CODEC_ID_NONE,
+};
+
+const AVBitStreamFilter ff_eac3_core_bsf = {
+.name  = "eac3_core",
+.filter= eac3_core_filter,
+.codec_ids = codec_ids,
+};
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/2] avcodec/eac3: add support for dependent stream

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/ac3_parser.c |   2 +-
 libavcodec/ac3dec.c | 160 +++-
 libavcodec/ac3dec.h |   9 ++-
 libavcodec/eac3dec.c|  11 +---
 4 files changed, 140 insertions(+), 42 deletions(-)

diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1015245a90..f4618bf215 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -218,8 +218,8 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext 
*hdr_info,
 else if (hdr_info->codec_id == AV_CODEC_ID_NONE)
 hdr_info->codec_id = AV_CODEC_ID_AC3;
 
-*need_next_header = (hdr.frame_type != EAC3_FRAME_TYPE_AC3_CONVERT);
 *new_frame_start  = (hdr.frame_type != EAC3_FRAME_TYPE_DEPENDENT);
+*need_next_header = *new_frame_start || (hdr.frame_type != 
EAC3_FRAME_TYPE_AC3_CONVERT);
 return hdr.frame_size;
 }
 
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 244a18323f..8e2c095118 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -106,6 +106,25 @@ static const uint8_t ac3_default_coeffs[8][5][2] = {
 { { 2, 7 }, { 5, 5 }, { 7, 2 }, { 6, 7 }, { 7, 6 }, },
 };
 
+static const uint64_t custom_channel_map_locations[16][2] = {
+{ 1, AV_CH_FRONT_LEFT },
+{ 1, AV_CH_FRONT_CENTER },
+{ 1, AV_CH_FRONT_RIGHT },
+{ 1, AV_CH_SIDE_LEFT },
+{ 1, AV_CH_SIDE_RIGHT },
+{ 0, AV_CH_FRONT_LEFT_OF_CENTER | AV_CH_FRONT_RIGHT_OF_CENTER },
+{ 0, AV_CH_BACK_LEFT | AV_CH_BACK_RIGHT },
+{ 0, AV_CH_BACK_CENTER },
+{ 0, AV_CH_TOP_CENTER },
+{ 0, AV_CH_SURROUND_DIRECT_LEFT | AV_CH_SURROUND_DIRECT_RIGHT },
+{ 0, AV_CH_WIDE_LEFT | AV_CH_WIDE_RIGHT },
+{ 0, AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT},
+{ 0, AV_CH_TOP_FRONT_CENTER },
+{ 0, AV_CH_TOP_BACK_LEFT | AV_CH_TOP_BACK_RIGHT },
+{ 0, AV_CH_LOW_FREQUENCY_2 },
+{ 1, AV_CH_LOW_FREQUENCY },
+};
+
 /**
  * Symmetrical Dequantization
  * reference: Section 7.3.3 Expansion of Mantissas for Symmetrical Quantization
@@ -317,6 +336,7 @@ static int parse_frame_header(AC3DecodeContext *s)
 s->fbw_channels = s->channels - s->lfe_on;
 s->lfe_ch   = s->fbw_channels + 1;
 s->frame_size   = hdr.frame_size;
+s->superframe_size += hdr.frame_size;
 s->preferred_downmix= AC3_DMIXMOD_NOTINDICATED;
 s->center_mix_level = hdr.center_mix_level;
 s->center_mix_level_ltrt= 4; // -3.0dB
@@ -683,7 +703,7 @@ static void do_rematrixing(AC3DecodeContext *s)
  * Convert frequency domain coefficients to time-domain audio samples.
  * reference: Section 7.9.4 Transformation Equations
  */
-static inline void do_imdct(AC3DecodeContext *s, int channels)
+static inline void do_imdct(AC3DecodeContext *s, int channels, int offset)
 {
 int ch;
 
@@ -695,25 +715,25 @@ static inline void do_imdct(AC3DecodeContext *s, int 
channels)
 x[i] = s->transform_coeffs[ch][2 * i];
 s->imdct_256.imdct_half(>imdct_256, s->tmp_output, x);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
 for (i = 0; i < 128; i++)
 x[i] = s->transform_coeffs[ch][2 * i + 1];
-s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1], x);
+s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1 + offset], 
x);
 } else {
 s->imdct_512.imdct_half(>imdct_512, s->tmp_output, 
s->transform_coeffs[ch]);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
-memcpy(s->delay[ch - 1], s->tmp_output + 128, 128 * 
sizeof(FFTSample));
+memcpy(s->delay[ch - 1 + offset], s->tmp_output + 128, 128 * 
sizeof(FFTSample));
 }
 }
 }
@@ -1063,7 +1083,7 @@ static inline int coupling_coordinates(AC3DecodeContext 
*s, int blk)
 /**
  * Decode a single audio block from the AC-3 bitstream.
  */
-static int decode_audio_block(AC3DecodeContext *s, int blk)
+static int decode_audio_block(AC3DecodeContext *s, int blk, int 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[wm4]

On Tue, 27 Mar 2018 12:14:55 +0200
Michael Niedermayer  wrote:

> On Mon, Mar 26, 2018 at 10:56:47PM +0100, Mark Thompson wrote:
> > On 26/03/18 22:44, Michael Niedermayer wrote:  
> > > On Mon, Mar 26, 2018 at 08:34:06AM +0200, Paul B Mahol wrote:  
> > >> On 3/26/18, Michael Niedermayer  wrote:  
> > >>> On Wed, Mar 21, 2018 at 09:18:21AM +0100, Paul B Mahol wrote:  
> >  On 3/20/18, Michael Niedermayer  wrote:  
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavfilter/vf_scale.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > > index 9f45032e85..2f6fa4791d 100644
> > > --- a/libavfilter/vf_scale.c
> > > +++ b/libavfilter/vf_scale.c
> > > @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, 
> > > AVFrame
> > > *in)
> > >  AVFilterLink *outlink = link->dst->outputs[0];
> > >  AVFrame *out;
> > >  const AVPixFmtDescriptor *desc =
> > > av_pix_fmt_desc_get(link->format);
> > > +const AVPixFmtDescriptor *out_desc =
> > > av_pix_fmt_desc_get(outlink->format);
> > >  char buf[32];
> > >  int in_range;
> > >
> > > @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link,
> > > AVFrame
> > > *in)
> > >   table, out_full,
> > >   brightness, contrast,
> > > saturation);
> > >
> > > -out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > > AVCOL_RANGE_MPEG;
> > > +// color_range describes YUV, it is undefined for RGB
> > > +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> > > out_desc->nb_components != 1) {
> > > +out->color_range = AVCOL_RANGE_UNSPECIFIED;
> > > +} else
> > > +out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > > AVCOL_RANGE_MPEG;
> > >  }
> > >
> > >  av_reduce(>sample_aspect_ratio.num,
> > > >sample_aspect_ratio.den,
> > > --
> > > 2.16.2
> > >  
> > 
> >  This is not optimal, as full color_range should remain full when not
> >  changed.  
> > >>>
> > >>> there is no range for rgb formats. The range is specific to YUV based
> > >>> formats.
> > >>> Thats, if iam guessing correctly what you meant. You did not really say
> > >>> which case you meant here. So maybe there is an issue and i 
> > >>> misunderstand
> > >>> what you refer to  
> > >>
> > >> Maybe not for swscale here but does exist otherwise.  
> > > 
> > > It has no meaning for RGB. There is no limited range RGB
> > > also, the API defines it only for YUV. So if it had meaning for RGB its 
> > > not defined
> > > what meaning that would be. The ranges for luma and chroma differ so its 
> > > not
> > > natural or obvious how to extend it to RGB.
> > > Iam also not aware of any specification that defines limited range RGB  
> > See HDMI, HD-SDI, CEA-861, pretty much anything related to sending RGB over 
> > wires in a non-PC context.
> > 
> > (No comment on whether it is useful to include it, but dismissing limited 
> > range RGB as not a thing is probably not a good idea.  I would kindof 
> > expect things like DeckLink to be using limited-range RGB everywhere, but 
> > I'm not familiar with the details there.)  
> 
> Is this used just over wires or also in software ?

Yes, it can happen that you "need" to output limited RGB for consumer
burning trash fire hardware.

> aka should we update our enum to also cover this and 
> If yes then we also probably should add support for this
> to swscale


I tried to use it once and considered it a libswscale bug and reported
it, but was overruled or something.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hwcontext_d3d11: Fix crash with valid adapter but no device

[wm4]

On Tue, 27 Mar 2018 01:22:34 +0100
Mark Thompson  wrote:

> This crash was introduced by 8bbf2dacbfb4ead1535dea411035994f507f517d,
> which could incorrectly overwrite the failure result from creating the
> device.
> 
> Fixes ticket #7108.
> ---
>  libavutil/hwcontext_d3d11va.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> index 960883c9d8..d39fdd3fc8 100644
> --- a/libavutil/hwcontext_d3d11va.c
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -556,8 +556,6 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
> const char *device,
>  }
>  }
>  
> -hr = mD3D11CreateDevice(pAdapter, pAdapter ? D3D_DRIVER_TYPE_UNKNOWN : 
> D3D_DRIVER_TYPE_HARDWARE, NULL, creationFlags, NULL, 0,
> -   D3D11_SDK_VERSION, _hwctx->device, NULL, NULL);
>  if (pAdapter) {
>  DXGI_ADAPTER_DESC2 desc;
>  hr = IDXGIAdapter2_GetDesc(pAdapter, );
> @@ -565,8 +563,12 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
> const char *device,
>  av_log(ctx, AV_LOG_INFO, "Using device %04x:%04x (%ls).\n",
> desc.VendorId, desc.DeviceId, desc.Description);
>  }
> -IDXGIAdapter_Release(pAdapter);
>  }
> +
> +hr = mD3D11CreateDevice(pAdapter, pAdapter ? D3D_DRIVER_TYPE_UNKNOWN : 
> D3D_DRIVER_TYPE_HARDWARE, NULL, creationFlags, NULL, 0,
> +   D3D11_SDK_VERSION, _hwctx->device, NULL, NULL);
> +if (pAdapter)
> +IDXGIAdapter_Release(pAdapter);
>  if (FAILED(hr)) {
>  av_log(ctx, AV_LOG_ERROR, "Failed to create Direct3D device 
> (%lx)\n", (long)hr);
>  return AVERROR_UNKNOWN;

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

[FFmpeg-devel] [PATCH v2 RESEND] avfilter: add OpenCL scale filter

[Gabriel Machado]

Sorry, my mail client corrupted the patch.

---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/scale.cl   | 111 +
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_scale_opencl.c | 284 ++
 6 files changed, 399 insertions(+)
 create mode 100644 libavfilter/opencl/scale.cl
 create mode 100644 libavfilter/vf_scale_opencl.c

diff --git a/configure b/configure
index 5ccf3ce..4007ee8 100755
--- a/configure
+++ b/configure
@@ -2821,6 +2821,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
 
 hwupload_cuda_filter_deps="ffnvcodec"
 scale_npp_filter_deps="ffnvcodec libnpp"
+scale_opencl_filter_deps="opencl"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..6303cbd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o opencl.o 
opencl/scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1cf1340..3185b17 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -309,6 +309,7 @@ static void register_all(void)
 REGISTER_FILTER(SCALE,  scale,  vf);
 REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
 REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
+REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
 REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
 REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
 REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
new file mode 100644
index 000..3436694
--- /dev/null
+++ b/libavfilter/opencl/scale.cl
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2018 Gabriel Machado
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+__kernel void neighbor(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+__kernel void bilinear(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_LINEAR);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+// https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch24.html
+float MitchellNetravali(float x, float B, float C)
+{
+float t = fabs(x);
+float tt = t*t;
+float ttt = tt*t;
+
+if (t < 1) {
+return ((12 - 9 * B - 6 * C) * ttt +
+(-18 + 12 * B + 6 * C) * tt + (6 - 2 * B)) / 6;
+} else if ((t >= 1) && (t < 2)) {
+return ((-B - 6 * C) * ttt +
+(6 * B + 30 * C) * tt + (-12 * B - 48 * C) *
+t + (8 * B + 24 * C)) / 6;
+} else {
+return 0;
+}
+}
+
+float4 cubic(float4 c0, float4 c1, float4 c2, float4 c3, float t)
+{
+float B = 0, C = 0.6; // libswscale default
+

Re: [FFmpeg-devel] Moving enum AVFieldOrder to libavutil?

[wm4]

On Mon, 26 Mar 2018 11:48:01 -0400
Devin Heitmueller  wrote:

> Hello all,
> 
> > On Mar 24, 2018, at 6:37 AM, Michael Niedermayer  
> > wrote:
> > 
> > On Sat, Mar 24, 2018 at 01:07:48AM +0100, Marton Balint wrote:  
> >> 
> >> 
> >> On Fri, 23 Mar 2018, Devin Heitmueller wrote:
> >>   
> >>> Hello,
> >>> 
> >>> I am in the process of reworking libavfilter to pass along the field order
> >>> across links.  For the moment I followed the model found in AVFrame where
> >>> there are two int fields: “interlaced_frame” and “top_field_first”.
> >>> However it seems like it would be more appropriate to use the enum
> >>> AVFieldOrder, which is a single field and provides more flexibility
> >>> (including being able to be set to “unknown” if appropriate).
> >>> 
> >>> Does anyone have an objection to moving the definition of AVFieldOrder to
> >>> libavutil, so it can be taken advantage of by libavfilter?  Right now it’s
> >>> in libavcodec, and from what I understand libavfilter does not depend on
> >>> libavcodec.  
> >>   
> >   
> >> AVFieldOrder is already a mess,   
> > 
> > +1  
> 
> Well, I really opened up a can of worms, eh?
> 
> As someone who used to work on Linux video capture drivers in a former life, 
> I can appreciate how confusing interlaced formats can be, perhaps even among 
> some of the ffmpeg developers.  It gets even worse when you have to deal with 
> the buffers delivered directly from embedded hardware such as SOCs, where the 
> formats can be even more esoteric than what you might find in various codecs 
> (most of which make at least some effort to normalize down to only a few 
> formats).
> 
> For what it’s worth, there were similar such debates years ago on what sort 
> of definitions are necessary to specify interlaced formats, and this is what 
> we arrived at (and have been using for many years):
> 
> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/field-order.html 
> 
> 
> The enum values described on that page cover pretty much all the cases you 
> can come across, including buffers organized as interleaved versus separate 
> fields, etc.
> 
> The above page is nice because it has some pictures/diagrams which allow you 
> to visualize the actual differences between the different modes.  It also 
> gives a good summary of the differences between spatial ordering and temporal 
> ordering (which I suspect is a cause of much of the confusing).
> 
> My goal was to solve an immediate business problem - making sure that when 
> playing a 1080i H.264 or MPEG-2 video that the decklink output gets properly 
> configured to 1080i59.  The scope creep came in after I realized this data 
> had no means of being propagated through the filter framework.  Now it’s 
> being suggested that we would have to redesign the whole way AVFieldOrder is 
> done, presumably including some sort of backward compatibility with the 
> existing system and API deprecation path for what is already there.
> 
> I’m not confident I have the time required to achieve such a goal.  This 
> presents several options:
> 
> 1.  Do nothing.  I’ll maintain my patch out-of-tree and Decklink will 
> continue to make bad choices on setting the output format.
> 
> 2.  Somebody else create a replacement for AVFieldOrder, go through all the 
> rounds of feedback/debate, merge the functionality and fix all the various 
> codecs/demuxers/etc which would need to use the new framework.  I’m happy to 
> rework my patch to use such replacement, but given ffmpeg has gone for many 
> years with AVFieldOrder in the state it’s in, I’m not confident there are 
> many volunteers willing to take on such an endeavor.
> 
> 3.  Try to get some variant of my patch upstream which leverages either the 
> existing AVFieldOrder or the AVFrame approach (i.e. 
> interlaced_frame/top_field_first struct members), and continue to live with 
> the deficiencies in the API.  I don’t think this makes the situation any 
> worse, it lays the groundwork for propagating this data through pipelines 
> (which can be converted to use some other struct member at a later date), and 
> it solves all the use cases that I care about.
> 
> I’m happy to contribute where I can, but part of me feels like let’s not let 
> “perfect be the enemy of good”.

Just adding a new summary enum would probably be a good idea. I suggest
you make a patch that's not too much effort, and that _only_ adds a new
enum to libavutil (though it will probably need to list all possible
variants).

Whether merging all interlaced flag things into a single enum makes
sense or not, no idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] avfilter: add OpenCL scale filter

[Gabriel Machado]

On 3/27/18 10:18 AM Rostislav Pehlivanov wrote:

> No license, can't use it. Shadertoy has no explicit license.
> 
> 
> Moreover the whole filter is incorrectly designed. Take a look at what mpv
> does and how it has no explicit per-algorithm scaling functions.

Thanks for the feedback!

I removed it for the time being. I'll try to implement it correctly in a
future patch.

---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/scale.cl   | 111 +
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_scale_opencl.c | 284 ++
 6 files changed, 399 insertions(+)
 create mode 100644 libavfilter/opencl/scale.cl
 create mode 100644 libavfilter/vf_scale_opencl.c

diff --git a/configure b/configure
index 5ccf3ce..4007ee8 100755
--- a/configure
+++ b/configure
@@ -2821,6 +2821,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
 
 hwupload_cuda_filter_deps="ffnvcodec"
 scale_npp_filter_deps="ffnvcodec libnpp"
+scale_opencl_filter_deps="opencl"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..6303cbd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o opencl.o 
opencl/scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1cf1340..3185b17 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -309,6 +309,7 @@ static void register_all(void)
 REGISTER_FILTER(SCALE,  scale,  vf);
 REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
 REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
+REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
 REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
 REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
 REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
new file mode 100644
index 000..3436694
--- /dev/null
+++ b/libavfilter/opencl/scale.cl
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2018 Gabriel Machado
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
USA
+ */
+
+__kernel void neighbor(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+__kernel void bilinear(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_LINEAR);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+// https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch24.html
+float MitchellNetravali(float x, float B, float C)
+{
+float t = fabs(x);
+float tt = t*t;
+float ttt = tt*t;
+
+if (t < 1) {
+return ((12 - 9 * B - 6 * C) * ttt +
+(-18 + 12 * B + 6 * C) * tt + (6 - 2 * B)) / 6;
+} else if ((t >= 

Re: [FFmpeg-devel] [PATCH] avcodec/ac3: add support for dependent stream

[Paul B Mahol]

On 3/27/18, Hendrik Leppkes  wrote:
> On Tue, Mar 27, 2018 at 1:57 PM, Paul B Mahol  wrote:
>>  /* keep last block for error concealment in next frame */
>>  for (ch = 0; ch < s->out_channels; ch++)
>> -memcpy(s->output[ch], output[ch],
>> AC3_BLOCK_SIZE*sizeof(SHORTFLOAT));
>> +memcpy(s->output[ch + offset], output[ch],
>> AC3_BLOCK_SIZE*sizeof(SHORTFLOAT));
>> +
>> +/* check if there is dependent frame */
>> +if (buf_size > s->frame_size) {
>> +AC3HeaderInfo hdr;
>> +int err;
>> +
>> +if ((ret = init_get_bits8(>gbc, buf + s->frame_size, buf_size
>> - s->frame_size)) < 0)
>> +return ret;
>> +
>> +err = ff_ac3_parse_header(>gbc, );
>> +if (err)
>> +return err;
>> +
>> +if (hdr.frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
>> +buf += s->frame_size;
>> +buf_size -= s->frame_size;
>> +s->prev_output_mode = s->output_mode;
>> +goto dependent_frame;
>> +}
>
> Maybe some general safety checks might be reasonable here? Like, same
> sample rate, number of audio blocks being equal to the core? The 'hdr'
> variable has all of that anyway.

Yes, will add.

>
>> +}
>> +
>> +frame->decode_error_flags = err ? FF_DECODE_ERROR_INVALID_BITSTREAM :
>> 0;
>> +
>> +for (ch = 0; ch < 16; ch++)
>> +extended_channel_map[ch] = ch;
>> +
>> +if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
>> +uint64_t ich_layout =
>> avpriv_ac3_channel_layout_tab[s->prev_output_mode & ~AC3_OUTPUT_LFEON];
>> +uint64_t channel_layout;
>> +int extend = 0;
>> +
>> +if (s->prev_output_mode & AC3_OUTPUT_LFEON)
>> +ich_layout |= AV_CH_LOW_FREQUENCY;
>> +
>> +channel_layout = ich_layout;
>> +for (ch = 0; ch < 16; ch++) {
>> +if (s->channel_map & (1 << (15 - ch))) {
>> +channel_layout |= custom_channel_map_locations[ch][1];
>> +}
>> +}
>> +
>> +avctx->channel_layout = channel_layout;
>> +avctx->channels =
>> av_get_channel_layout_nb_channels(channel_layout);
>> +
>> +for (ch = 0; ch < 16; ch++) {
>> +if (s->channel_map & (1 << (15 - ch))) {
>> +if (custom_channel_map_locations[ch][0]) {
>> +int index =
>> av_get_channel_layout_channel_index(channel_layout,
>> +
>> custom_channel_map_locations[ch][1]);
>> +if (index < 0)
>> +return AVERROR_INVALIDDATA;
>> +extended_channel_map[index] = offset +
>> channel_map[extend++];
>> +} else {
>> +int i;
>> +
>> +for (i = 0; i < 64; i++) {
>> +if ((1LL << i) &
>> custom_channel_map_locations[ch][1]) {
>> +int index =
>> av_get_channel_layout_channel_index(channel_layout,
>> +
>>   1LL << i);
>> +if (index < 0)
>> +return AVERROR_INVALIDDATA;
>> +extended_channel_map[index] = offset +
>> channel_map[extend++];
>> +}
>> +}
>> +}
>> +}
>> +}
>> +}
>> +
>
> The channel mapping code looks a bit confusing, but I don't have any
> idea how to make it any better right now either, so..
>
> --
> Maybe a fate test might be useful?

Sure, but not right now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ac3: add support for dependent stream

[Hendrik Leppkes]

On Tue, Mar 27, 2018 at 1:57 PM, Paul B Mahol  wrote:
>  /* keep last block for error concealment in next frame */
>  for (ch = 0; ch < s->out_channels; ch++)
> -memcpy(s->output[ch], output[ch], AC3_BLOCK_SIZE*sizeof(SHORTFLOAT));
> +memcpy(s->output[ch + offset], output[ch], 
> AC3_BLOCK_SIZE*sizeof(SHORTFLOAT));
> +
> +/* check if there is dependent frame */
> +if (buf_size > s->frame_size) {
> +AC3HeaderInfo hdr;
> +int err;
> +
> +if ((ret = init_get_bits8(>gbc, buf + s->frame_size, buf_size - 
> s->frame_size)) < 0)
> +return ret;
> +
> +err = ff_ac3_parse_header(>gbc, );
> +if (err)
> +return err;
> +
> +if (hdr.frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
> +buf += s->frame_size;
> +buf_size -= s->frame_size;
> +s->prev_output_mode = s->output_mode;
> +goto dependent_frame;
> +}

Maybe some general safety checks might be reasonable here? Like, same
sample rate, number of audio blocks being equal to the core? The 'hdr'
variable has all of that anyway.

> +}
> +
> +frame->decode_error_flags = err ? FF_DECODE_ERROR_INVALID_BITSTREAM : 0;
> +
> +for (ch = 0; ch < 16; ch++)
> +extended_channel_map[ch] = ch;
> +
> +if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
> +uint64_t ich_layout = 
> avpriv_ac3_channel_layout_tab[s->prev_output_mode & ~AC3_OUTPUT_LFEON];
> +uint64_t channel_layout;
> +int extend = 0;
> +
> +if (s->prev_output_mode & AC3_OUTPUT_LFEON)
> +ich_layout |= AV_CH_LOW_FREQUENCY;
> +
> +channel_layout = ich_layout;
> +for (ch = 0; ch < 16; ch++) {
> +if (s->channel_map & (1 << (15 - ch))) {
> +channel_layout |= custom_channel_map_locations[ch][1];
> +}
> +}
> +
> +avctx->channel_layout = channel_layout;
> +avctx->channels = av_get_channel_layout_nb_channels(channel_layout);
> +
> +for (ch = 0; ch < 16; ch++) {
> +if (s->channel_map & (1 << (15 - ch))) {
> +if (custom_channel_map_locations[ch][0]) {
> +int index = 
> av_get_channel_layout_channel_index(channel_layout,
> +
> custom_channel_map_locations[ch][1]);
> +if (index < 0)
> +return AVERROR_INVALIDDATA;
> +extended_channel_map[index] = offset + 
> channel_map[extend++];
> +} else {
> +int i;
> +
> +for (i = 0; i < 64; i++) {
> +if ((1LL << i) & 
> custom_channel_map_locations[ch][1]) {
> +int index = 
> av_get_channel_layout_channel_index(channel_layout,
> +
> 1LL << i);
> +if (index < 0)
> +return AVERROR_INVALIDDATA;
> +extended_channel_map[index] = offset + 
> channel_map[extend++];
> +}
> +}
> +}
> +}
> +}
> +}
> +

The channel mapping code looks a bit confusing, but I don't have any
idea how to make it any better right now either, so..

--
Maybe a fate test might be useful?

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

Re: [FFmpeg-devel] [PATCH v3] libavformat/dashdec: Support signaling of last segment number

[Steven Liu]

> On 27 Mar 2018, at 9:28 PM, sanilraut  wrote:
> 
> Last segment indicated by mpd is not parsed.
> Example stream: 
> http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd
> 
> This patch supports parsing of Supplemental Descriptor with @schemeIdUri set 
> to http://dashif.org/guide-
> lines/last-segment-number with the @value set to the last segment number.
> 
> ---
> libavformat/dashdec.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 7b79b93..8bfde4d 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -805,7 +805,8 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
>  xmlNodePtr fragment_template_node,
>  xmlNodePtr content_component_node,
>  xmlNodePtr adaptionset_baseurl_node,
> - xmlNodePtr 
> adaptionset_segmentlist_node)
> + xmlNodePtr 
> adaptionset_segmentlist_node,
> + xmlNodePtr 
> adaptionset_supplementalproperty_node)
> {
> int32_t ret = 0;
> int32_t audio_rep_idx = 0;
> @@ -825,6 +826,7 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
> char *timescale_val = NULL;
> char *initialization_val = NULL;
> char *media_val = NULL;
> +char *val = NULL;
> xmlNodePtr baseurl_nodes[4];
> xmlNodePtr representation_node = node;
> char *rep_id_val = xmlGetProp(representation_node, "id");
> @@ -920,6 +922,17 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
> rep->first_seq_no = (int64_t) strtoll(startnumber_val, NULL, 
> 10);
> xmlFree(startnumber_val);
> }
> +if (adaptionset_supplementalproperty_node) {
> +if 
> (!av_strcasecmp(xmlGetProp(adaptionset_supplementalproperty_node,"schemeIdUri"),
>  "http://dashif.org/guidelines/last-segment-number;)) {
> +val = 
> xmlGetProp(adaptionset_supplementalproperty_node,"value");
> +if (!val) {
> +av_log(s, AV_LOG_ERROR, "Missing value attribute in 
> adaptionset_supplementalproperty_node\n");
> +} else {
> +rep->last_seq_no =(int64_t) strtoll(val, NULL, 10) - 
> 1;
> +xmlFree(val);
> +}
> + }
> +}
> 
> fragment_timeline_node = 
> find_child_node_by_name(representation_segmenttemplate_node, 
> "SegmentTimeline");
> 
> @@ -1054,6 +1067,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
> xmlNodePtr content_component_node = NULL;
> xmlNodePtr adaptionset_baseurl_node = NULL;
> xmlNodePtr adaptionset_segmentlist_node = NULL;
> +xmlNodePtr adaptionset_supplementalproperty_node = NULL;
> xmlNodePtr node = NULL;
> 
> node = xmlFirstElementChild(adaptionset_node);
> @@ -1066,6 +1080,8 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
> adaptionset_baseurl_node = node;
> } else if (!av_strcasecmp(node->name, (const char *)"SegmentList")) {
> adaptionset_segmentlist_node = node;
> +} else if (!av_strcasecmp(node->name, (const char 
> *)"SupplementalProperty")) {
> +adaptionset_supplementalproperty_node = node;
> } else if (!av_strcasecmp(node->name, (const char 
> *)"Representation")) {
> ret = parse_manifest_representation(s, url, node,
> adaptionset_node,
> @@ -1076,7 +1092,8 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
> fragment_template_node,
> content_component_node,
> adaptionset_baseurl_node,
> -
> adaptionset_segmentlist_node);
> +adaptionset_segmentlist_node,
> +
> adaptionset_supplementalproperty_node);
> if (ret < 0) {
> return ret;
> }
> @@ -1819,7 +1836,10 @@ static int open_demux_for_component(AVFormatContext 
> *s, struct representation *p
> 
> pls->parent = s;
> pls->cur_seq_no  = calc_cur_seg_no(s, pls);
> -pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
> +
> +if (!pls->last_seq_no) {
> +pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
> +}
> 
> ret = reopen_demux_for_component(s, pls);
> if (ret < 0) {
> -- 
> 2.7.4

Re: [FFmpeg-devel] [PATCH] avcodec/avpacket: remove unnecessary check in av_packet_make_writable()

[James Almer]

On 3/25/2018 9:25 PM, James Almer wrote:
> Zero sized packets are already handled below in the function.
> This is more in line with av_packet_ref().
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/avpacket.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 0693ca6f62..0993481961 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -660,9 +660,6 @@ int av_packet_make_writable(AVPacket *pkt)
>  if (pkt->buf && av_buffer_is_writable(pkt->buf))
>  return 0;
>  
> -if (!pkt->data)
> -return AVERROR(EINVAL);
> -
>  ret = packet_alloc(, pkt->size);
>  if (ret < 0)
>  return ret;

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

Re: [FFmpeg-devel] [PATCH] avcodec/ac3: add support for dependent stream

[Paul B Mahol]

On 3/27/18, James Almer  wrote:
> On 3/27/2018 8:57 AM, Paul B Mahol wrote:
>> @@ -1511,7 +1534,7 @@ static int ac3_decode_frame(AVCodecContext * avctx,
>> void *data,
>>  break;
>>  case AAC_AC3_PARSE_ERROR_FRAME_TYPE:
>>  /* skip frame if CRC is ok. otherwise use error concealment.
>> */
>> -/* TODO: add support for substreams and dependent frames */
>> +/* TODO: add support for substreams */
>>  if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT ||
>> s->substreamid) {
>>  av_log(avctx, AV_LOG_DEBUG,
>> "unsupported frame type %d: skipping frame\n",
>
> Shouldn't you also change the check below the TODO?

Yes, fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/ac3: add support for dependent stream

[James Almer]

On 3/27/2018 8:57 AM, Paul B Mahol wrote:
> @@ -1511,7 +1534,7 @@ static int ac3_decode_frame(AVCodecContext * avctx, 
> void *data,
>  break;
>  case AAC_AC3_PARSE_ERROR_FRAME_TYPE:
>  /* skip frame if CRC is ok. otherwise use error concealment. */
> -/* TODO: add support for substreams and dependent frames */
> +/* TODO: add support for substreams */
>  if (s->frame_type == EAC3_FRAME_TYPE_DEPENDENT || 
> s->substreamid) {
>  av_log(avctx, AV_LOG_DEBUG,
> "unsupported frame type %d: skipping frame\n",

Shouldn't you also change the check below the TODO?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] libavformat/dashdec: Support signaling of last segment number

[sanilraut]

Last segment indicated by mpd is not parsed.
Example stream: 
http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd

This patch supports parsing of Supplemental Descriptor with @schemeIdUri set to 
http://dashif.org/guide-
lines/last-segment-number with the @value set to the last segment number.

---
 libavformat/dashdec.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 7b79b93..8bfde4d 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -805,7 +805,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
  xmlNodePtr fragment_template_node,
  xmlNodePtr content_component_node,
  xmlNodePtr adaptionset_baseurl_node,
- xmlNodePtr 
adaptionset_segmentlist_node)
+ xmlNodePtr 
adaptionset_segmentlist_node,
+ xmlNodePtr 
adaptionset_supplementalproperty_node)
 {
 int32_t ret = 0;
 int32_t audio_rep_idx = 0;
@@ -825,6 +826,7 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 char *timescale_val = NULL;
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *val = NULL;
 xmlNodePtr baseurl_nodes[4];
 xmlNodePtr representation_node = node;
 char *rep_id_val = xmlGetProp(representation_node, "id");
@@ -920,6 +922,17 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 rep->first_seq_no = (int64_t) strtoll(startnumber_val, NULL, 
10);
 xmlFree(startnumber_val);
 }
+if (adaptionset_supplementalproperty_node) {
+if 
(!av_strcasecmp(xmlGetProp(adaptionset_supplementalproperty_node,"schemeIdUri"),
 "http://dashif.org/guidelines/last-segment-number;)) {
+val = 
xmlGetProp(adaptionset_supplementalproperty_node,"value");
+if (!val) {
+av_log(s, AV_LOG_ERROR, "Missing value attribute in 
adaptionset_supplementalproperty_node\n");
+} else {
+rep->last_seq_no =(int64_t) strtoll(val, NULL, 10) - 1;
+xmlFree(val);
+}
+ }
+}
 
 fragment_timeline_node = 
find_child_node_by_name(representation_segmenttemplate_node, "SegmentTimeline");
 
@@ -1054,6 +1067,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
*s, const char *url,
 xmlNodePtr content_component_node = NULL;
 xmlNodePtr adaptionset_baseurl_node = NULL;
 xmlNodePtr adaptionset_segmentlist_node = NULL;
+xmlNodePtr adaptionset_supplementalproperty_node = NULL;
 xmlNodePtr node = NULL;
 
 node = xmlFirstElementChild(adaptionset_node);
@@ -1066,6 +1080,8 @@ static int parse_manifest_adaptationset(AVFormatContext 
*s, const char *url,
 adaptionset_baseurl_node = node;
 } else if (!av_strcasecmp(node->name, (const char *)"SegmentList")) {
 adaptionset_segmentlist_node = node;
+} else if (!av_strcasecmp(node->name, (const char 
*)"SupplementalProperty")) {
+adaptionset_supplementalproperty_node = node;
 } else if (!av_strcasecmp(node->name, (const char *)"Representation")) 
{
 ret = parse_manifest_representation(s, url, node,
 adaptionset_node,
@@ -1076,7 +1092,8 @@ static int parse_manifest_adaptationset(AVFormatContext 
*s, const char *url,
 fragment_template_node,
 content_component_node,
 adaptionset_baseurl_node,
-adaptionset_segmentlist_node);
+adaptionset_segmentlist_node,
+
adaptionset_supplementalproperty_node);
 if (ret < 0) {
 return ret;
 }
@@ -1819,7 +1836,10 @@ static int open_demux_for_component(AVFormatContext *s, 
struct representation *p
 
 pls->parent = s;
 pls->cur_seq_no  = calc_cur_seg_no(s, pls);
-pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
+
+if (!pls->last_seq_no) {
+pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
+}
 
 ret = reopen_demux_for_component(s, pls);
 if (ret < 0) {
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH v2] avformat/dashdec: Support signaling of last segment number

[sanilraut]

Thanks. Have re-submitted the patch.

Sanil

On Mon, Mar 26, 2018 at 7:10 PM, Steven Liu  wrote:

>
>
> > On 26 Mar 2018, at 04:01, sanilraut  wrote:
> >
> > Last segment indicated by mpd is not parsed.
> > Example stream: http://dash.akamaized.net/dash264/TestCasesIOP41/
> LastSegmentNumber/1/manifest_last_segment_num.mpd
> >
> > This patch supports parsing of Supplemental Descriptor with @schemeIdUri
> set to http://dashif.org/guide-
> > lines/last-segment-number with the @value set to the last segment number.
> >
> > ---
> > libavformat/dashdec.c | 22 +++---
> > 1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index 7b79b93..db63a99 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -805,7 +805,8 @@ static int parse_manifest_representation(AVFormatContext
> *s, const char *url,
> >  xmlNodePtr
> fragment_template_node,
> >  xmlNodePtr
> content_component_node,
> >  xmlNodePtr
> adaptionset_baseurl_node,
> > - xmlNodePtr
> adaptionset_segmentlist_node)
> > + xmlNodePtr
> adaptionset_segmentlist_node,
> > + xmlNodePtr adaptionset_
> supplementalproperty_node)
> > {
> > int32_t ret = 0;
> > int32_t audio_rep_idx = 0;
> > @@ -825,6 +826,7 @@ static int parse_manifest_representation(AVFormatContext
> *s, const char *url,
> > char *timescale_val = NULL;
> > char *initialization_val = NULL;
> > char *media_val = NULL;
> > +char *val = NULL;
> > xmlNodePtr baseurl_nodes[4];
> > xmlNodePtr representation_node = node;
> > char *rep_id_val = xmlGetProp(representation_node, "id");
> > @@ -920,6 +922,13 @@ static int 
> > parse_manifest_representation(AVFormatContext
> *s, const char *url,
> > rep->first_seq_no = (int64_t) strtoll(startnumber_val,
> NULL, 10);
> > xmlFree(startnumber_val);
> > }
> > +if (adaptionset_supplementalproperty_node) {
> > +if (!strcmp(xmlGetProp(adaptionset_
> supplementalproperty_node,"schemeIdUri"), "http://dashif.org/guidelines/
> last-segment-number")) {
> av_strcasecmp
> > +val = xmlGetProp(adaptionset_
> supplementalproperty_node,"value”);
> val need be checked if xmlGetProp will be failed
> > +rep->last_seq_no =(int64_t) strtoll(val, NULL, 10)
> - 1;
> > +xmlFree(val);
> > + }
> > +}
> >
> > fragment_timeline_node = find_child_node_by_name(
> representation_segmenttemplate_node, "SegmentTimeline");
> >
> > @@ -1054,6 +1063,7 @@ static int 
> > parse_manifest_adaptationset(AVFormatContext
> *s, const char *url,
> > xmlNodePtr content_component_node = NULL;
> > xmlNodePtr adaptionset_baseurl_node = NULL;
> > xmlNodePtr adaptionset_segmentlist_node = NULL;
> > +xmlNodePtr adaptionset_supplementalproperty_node = NULL;
> > xmlNodePtr node = NULL;
> >
> > node = xmlFirstElementChild(adaptionset_node);
> > @@ -1066,6 +1076,8 @@ static int 
> > parse_manifest_adaptationset(AVFormatContext
> *s, const char *url,
> > adaptionset_baseurl_node = node;
> > } else if (!av_strcasecmp(node->name, (const char
> *)"SegmentList")) {
> > adaptionset_segmentlist_node = node;
> > +} else if (!av_strcasecmp(node->name, (const char
> *)"SupplementalProperty")) {
> > +adaptionset_supplementalproperty_node = node;
> > } else if (!av_strcasecmp(node->name, (const char
> *)"Representation")) {
> > ret = parse_manifest_representation(s, url, node,
> > adaptionset_node,
> > @@ -1076,7 +1088,8 @@ static int 
> > parse_manifest_adaptationset(AVFormatContext
> *s, const char *url,
> > fragment_template_node,
> > content_component_node,
> > adaptionset_baseurl_node,
> > -
> adaptionset_segmentlist_node);
> > +
> adaptionset_segmentlist_node,
> > +adaptionset_
> supplementalproperty_node);
> > if (ret < 0) {
> > return ret;
> > }
> > @@ -1819,7 +1832,10 @@ static int open_demux_for_component(AVFormatContext
> *s, struct representation *p
> >
> > pls->parent = s;
> > pls->cur_seq_no  = calc_cur_seg_no(s, pls);
> > -pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
> > +
> > +if (!pls->last_seq_no) {
> > +pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
> > +}
> >
> > ret = reopen_demux_for_component(s, pls);
> > 

Re: [FFmpeg-devel] [PATCH] avfilter: add OpenCL scale filter

[Rostislav Pehlivanov]

On 27 March 2018 at 05:48, Gabriel Machado  wrote:

> From: Gabriel Machado 
>
> Some scaling filters implemented as OpenCL kernels. Can be used as:
>
> scale_opencl=::flags=
> where  can be `neighbor', `bilinear', `bicubic' or `fast_bicubic'
>
> This is an initial draft, there's still a long way to go in terms of
> completeness, configurability and performance.
>
> ---
>  configure |   1 +
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/opencl/scale.cl   | 165 
>  libavfilter/opencl_source.h   |   1 +
>  libavfilter/vf_scale_opencl.c | 289 ++
> 
>  6 files changed, 458 insertions(+)
>  create mode 100644 libavfilter/opencl/scale.cl
>  create mode 100644 libavfilter/vf_scale_opencl.c
>
> diff --git a/configure b/configure
> index 5ccf3ce..4007ee8 100755
> --- a/configure
> +++ b/configure
> @@ -2821,6 +2821,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
>
>  hwupload_cuda_filter_deps="ffnvcodec"
>  scale_npp_filter_deps="ffnvcodec libnpp"
> +scale_opencl_filter_deps="opencl"
>  scale_cuda_filter_deps="cuda_sdk"
>  thumbnail_cuda_filter_deps="cuda_sdk"
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a90ca30..6303cbd 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+=
> vf_sab.o
>  OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
>  OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o
> vf_scale_cuda.ptx.o
>  OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
> +OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o
> opencl.o opencl/scale.o
>  OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
>  OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
> vaapi_vpp.o
>  OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 1cf1340..3185b17 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -309,6 +309,7 @@ static void register_all(void)
>  REGISTER_FILTER(SCALE,  scale,  vf);
>  REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
>  REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
> +REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
>  REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
>  REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
>  REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
> diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
> new file mode 100644
> index 000..b0e6cb2
> --- /dev/null
> +++ b/libavfilter/opencl/scale.cl
> @@ -0,0 +1,165 @@
> +/*
> + * Copyright (c) 2018 Gabriel Machado
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +__kernel void neighbor(__write_only image2d_t dst,
> +   __read_only  image2d_t src)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
> +   CLK_ADDRESS_CLAMP_TO_EDGE |
> +   CLK_FILTER_NEAREST);
> +
> +int2 coord = {get_global_id(0), get_global_id(1)};
> +int2 size = {get_global_size(0), get_global_size(1)};
> +
> +float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
> +
> +float4 c = read_imagef(src, sampler, pos);
> +write_imagef(dst, coord, c);
> +}
> +
> +__kernel void bilinear(__write_only image2d_t dst,
> +   __read_only  image2d_t src)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
> +   CLK_ADDRESS_CLAMP_TO_EDGE |
> +   CLK_FILTER_LINEAR);
> +
> +int2 coord = {get_global_id(0), get_global_id(1)};
> +int2 size = {get_global_size(0), get_global_size(1)};
> +
> +float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
> +
> +float4 c = read_imagef(src, sampler, pos);
> +write_imagef(dst, coord, c);
> +}
> +
> +// https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch24.html
> +float 

[FFmpeg-devel] [PATCH v3] avcodec/arm/hevcdsp_sao : add NEON optimization for sao

[Yingming Fan]

From: Meng Wang 

Signed-off-by: Meng Wang 
---
This v3 patch removed unused codes 'stride_dst /= sizeof(uint8_t);' compared to 
v1. V1 have this codes because we referred to hevc dsp template codes.
Also removed type cast like 'uint8_t *dst = (uint8_t *)_dst;' compared to v2.

As FFmpeg hevc decoder have no SAO neon optimization, we add sao_band and 
sao_edge neon codes in this patch.
I have already submit a patch called 'checkasm/hevc_sao : add hevc_sao for 
checkasm' several days ago.
Results below was printed by hevc_sao checkasm on an armv7 device Nexus 5. 
From the results we can see: hevc_sao_band speed up ~2x, hevc_sao_edge speed up 
~4x. 
Also passed FATE under armv7 linux and x86_64 linux MacOS.

hevc_sao_band_8x8_8_c: 804.9
hevc_sao_band_8x8_8_neon: 452.4
hevc_sao_band_16x16_8_c: 2638.1
hevc_sao_band_16x16_8_neon: 1169.9
hevc_sao_band_32x32_8_c: 9259.9
hevc_sao_band_32x32_8_neon: 3956.1
hevc_sao_band_48x48_8_c: 20344.6
hevc_sao_band_48x48_8_neon: 8649.6
hevc_sao_band_64x64_8_c: 35684.6
hevc_sao_band_64x64_8_neon: 15213.1
hevc_sao_edge_8x8_8_c: 1761.6
hevc_sao_edge_8x8_8_neon: 414.6
hevc_sao_edge_16x16_8_c: 6844.4
hevc_sao_edge_16x16_8_neon: 1589.9
hevc_sao_edge_32x32_8_c: 27156.4
hevc_sao_edge_32x32_8_neon: 6116.6
hevc_sao_edge_48x48_8_c: 60004.6
hevc_sao_edge_48x48_8_neon: 13686.4
hevc_sao_edge_64x64_8_c: 106708.1
hevc_sao_edge_64x64_8_neon: 24240.1

 libavcodec/arm/Makefile|   3 +-
 libavcodec/arm/hevcdsp_init_neon.c |  59 
 libavcodec/arm/hevcdsp_sao_neon.S  | 181 +
 3 files changed, 242 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/arm/hevcdsp_sao_neon.S

diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 1eeac5449e..9c164f82ae 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -136,7 +136,8 @@ NEON-OBJS-$(CONFIG_DCA_DECODER)+= 
arm/synth_filter_neon.o
 NEON-OBJS-$(CONFIG_HEVC_DECODER)   += arm/hevcdsp_init_neon.o   \
   arm/hevcdsp_deblock_neon.o\
   arm/hevcdsp_idct_neon.o   \
-  arm/hevcdsp_qpel_neon.o
+  arm/hevcdsp_qpel_neon.o   \
+  arm/hevcdsp_sao_neon.o
 NEON-OBJS-$(CONFIG_RV30_DECODER)   += arm/rv34dsp_neon.o
 NEON-OBJS-$(CONFIG_RV40_DECODER)   += arm/rv34dsp_neon.o\
   arm/rv40dsp_neon.o
diff --git a/libavcodec/arm/hevcdsp_init_neon.c 
b/libavcodec/arm/hevcdsp_init_neon.c
index a4628d2a93..201a088dac 100644
--- a/libavcodec/arm/hevcdsp_init_neon.c
+++ b/libavcodec/arm/hevcdsp_init_neon.c
@@ -21,8 +21,16 @@
 #include "libavutil/attributes.h"
 #include "libavutil/arm/cpu.h"
 #include "libavcodec/hevcdsp.h"
+#include "libavcodec/avcodec.h"
 #include "hevcdsp_arm.h"
 
+void ff_hevc_sao_band_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src,
+  ptrdiff_t stride_dst, ptrdiff_t stride_src,
+  int16_t *sao_offset_val, int sao_left_class,
+  int width, int height);
+void ff_hevc_sao_edge_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src, 
ptrdiff_t stride_dst, int16_t *sao_offset_val,
+  int eo, int width, int height);
+
 void ff_hevc_v_loop_filter_luma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
_beta, int *_tc, uint8_t *_no_p, uint8_t *_no_q);
 void ff_hevc_h_loop_filter_luma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
_beta, int *_tc, uint8_t *_no_p, uint8_t *_no_q);
 void ff_hevc_v_loop_filter_chroma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
*_tc, uint8_t *_no_p, uint8_t *_no_q);
@@ -142,6 +150,47 @@ QPEL_FUNC_UW(ff_hevc_put_qpel_uw_h3v2_neon_8);
 QPEL_FUNC_UW(ff_hevc_put_qpel_uw_h3v3_neon_8);
 #undef QPEL_FUNC_UW
 
+void ff_hevc_sao_band_filter_neon_8(uint8_t *dst, uint8_t *src, ptrdiff_t 
stride_dst, ptrdiff_t stride_src, int width, int height, int16_t *offset_table);
+
+void ff_hevc_sao_band_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src,
+  ptrdiff_t stride_dst, ptrdiff_t stride_src,
+  int16_t *sao_offset_val, int sao_left_class,
+  int width, int height) {
+uint8_t *dst = _dst;
+uint8_t *src = _src;
+int16_t offset_table[32] = {0};
+int k;
+
+for (k = 0; k < 4; k++) {
+offset_table[(k + sao_left_class) & 31] = sao_offset_val[k + 1];
+}
+
+ff_hevc_sao_band_filter_neon_8(dst, src, stride_dst, stride_src, width, 
height, offset_table);
+}
+
+void ff_hevc_sao_edge_filter_neon_8(uint8_t *dst, uint8_t *src, ptrdiff_t 
stride_dst, ptrdiff_t stride_src, int width, int height,
+int a_stride, int b_stride, int16_t 
*sao_offset_val, uint8_t 

Re: [FFmpeg-devel] [PATCH] avcodec/ac3: add support for dependent stream

[Paul B Mahol]

On 3/27/18, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/ac3_parser.c |   2 +-
>  libavcodec/ac3dec.c | 152
> +++-
>  libavcodec/ac3dec.h |   9 ++-
>  libavcodec/eac3dec.c|  11 +---
>  4 files changed, 134 insertions(+), 40 deletions(-)
>

Also fixes #4608.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/ac3: add support for dependent stream

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/ac3_parser.c |   2 +-
 libavcodec/ac3dec.c | 152 +++-
 libavcodec/ac3dec.h |   9 ++-
 libavcodec/eac3dec.c|  11 +---
 4 files changed, 134 insertions(+), 40 deletions(-)

diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1015245a90..f4618bf215 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -218,8 +218,8 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext 
*hdr_info,
 else if (hdr_info->codec_id == AV_CODEC_ID_NONE)
 hdr_info->codec_id = AV_CODEC_ID_AC3;
 
-*need_next_header = (hdr.frame_type != EAC3_FRAME_TYPE_AC3_CONVERT);
 *new_frame_start  = (hdr.frame_type != EAC3_FRAME_TYPE_DEPENDENT);
+*need_next_header = *new_frame_start || (hdr.frame_type != 
EAC3_FRAME_TYPE_AC3_CONVERT);
 return hdr.frame_size;
 }
 
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 244a18323f..a6aff333e6 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -106,6 +106,25 @@ static const uint8_t ac3_default_coeffs[8][5][2] = {
 { { 2, 7 }, { 5, 5 }, { 7, 2 }, { 6, 7 }, { 7, 6 }, },
 };
 
+static const uint64_t custom_channel_map_locations[16][2] = {
+{ 1, AV_CH_FRONT_LEFT },
+{ 1, AV_CH_FRONT_CENTER },
+{ 1, AV_CH_FRONT_RIGHT },
+{ 1, AV_CH_SIDE_LEFT },
+{ 1, AV_CH_SIDE_RIGHT },
+{ 0, AV_CH_FRONT_LEFT_OF_CENTER | AV_CH_FRONT_RIGHT_OF_CENTER },
+{ 0, AV_CH_BACK_LEFT | AV_CH_BACK_RIGHT },
+{ 0, AV_CH_BACK_CENTER },
+{ 0, AV_CH_TOP_CENTER },
+{ 0, AV_CH_SURROUND_DIRECT_LEFT | AV_CH_SURROUND_DIRECT_RIGHT },
+{ 0, AV_CH_WIDE_LEFT | AV_CH_WIDE_RIGHT },
+{ 0, AV_CH_TOP_FRONT_LEFT | AV_CH_TOP_FRONT_RIGHT},
+{ 0, AV_CH_TOP_FRONT_CENTER },
+{ 0, AV_CH_TOP_BACK_LEFT | AV_CH_TOP_BACK_RIGHT },
+{ 0, AV_CH_LOW_FREQUENCY_2 },
+{ 1, AV_CH_LOW_FREQUENCY },
+};
+
 /**
  * Symmetrical Dequantization
  * reference: Section 7.3.3 Expansion of Mantissas for Symmetrical Quantization
@@ -317,6 +336,7 @@ static int parse_frame_header(AC3DecodeContext *s)
 s->fbw_channels = s->channels - s->lfe_on;
 s->lfe_ch   = s->fbw_channels + 1;
 s->frame_size   = hdr.frame_size;
+s->superframe_size += hdr.frame_size;
 s->preferred_downmix= AC3_DMIXMOD_NOTINDICATED;
 s->center_mix_level = hdr.center_mix_level;
 s->center_mix_level_ltrt= 4; // -3.0dB
@@ -683,7 +703,7 @@ static void do_rematrixing(AC3DecodeContext *s)
  * Convert frequency domain coefficients to time-domain audio samples.
  * reference: Section 7.9.4 Transformation Equations
  */
-static inline void do_imdct(AC3DecodeContext *s, int channels)
+static inline void do_imdct(AC3DecodeContext *s, int channels, int offset)
 {
 int ch;
 
@@ -695,25 +715,25 @@ static inline void do_imdct(AC3DecodeContext *s, int 
channels)
 x[i] = s->transform_coeffs[ch][2 * i];
 s->imdct_256.imdct_half(>imdct_256, s->tmp_output, x);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
 for (i = 0; i < 128; i++)
 x[i] = s->transform_coeffs[ch][2 * i + 1];
-s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1], x);
+s->imdct_256.imdct_half(>imdct_256, s->delay[ch - 1 + offset], 
x);
 } else {
 s->imdct_512.imdct_half(>imdct_512, s->tmp_output, 
s->transform_coeffs[ch]);
 #if USE_FIXED
-s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1],
+s->fdsp->vector_fmul_window_scaled(s->outptr[ch - 1], s->delay[ch 
- 1 + offset],
s->tmp_output, s->window, 128, 8);
 #else
-s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1],
+s->fdsp->vector_fmul_window(s->outptr[ch - 1], s->delay[ch - 1 + 
offset],
s->tmp_output, s->window, 128);
 #endif
-memcpy(s->delay[ch - 1], s->tmp_output + 128, 128 * 
sizeof(FFTSample));
+memcpy(s->delay[ch - 1 + offset], s->tmp_output + 128, 128 * 
sizeof(FFTSample));
 }
 }
 }
@@ -1063,7 +1083,7 @@ static inline int coupling_coordinates(AC3DecodeContext 
*s, int blk)
 /**
  * Decode a single audio block from the AC-3 bitstream.
  */
-static int decode_audio_block(AC3DecodeContext *s, int blk)
+static int decode_audio_block(AC3DecodeContext *s, int blk, int 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 10:56:47PM +0100, Mark Thompson wrote:
> On 26/03/18 22:44, Michael Niedermayer wrote:
> > On Mon, Mar 26, 2018 at 08:34:06AM +0200, Paul B Mahol wrote:
> >> On 3/26/18, Michael Niedermayer  wrote:
> >>> On Wed, Mar 21, 2018 at 09:18:21AM +0100, Paul B Mahol wrote:
>  On 3/20/18, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavfilter/vf_scale.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index 9f45032e85..2f6fa4791d 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, AVFrame
> > *in)
> >  AVFilterLink *outlink = link->dst->outputs[0];
> >  AVFrame *out;
> >  const AVPixFmtDescriptor *desc =
> > av_pix_fmt_desc_get(link->format);
> > +const AVPixFmtDescriptor *out_desc =
> > av_pix_fmt_desc_get(outlink->format);
> >  char buf[32];
> >  int in_range;
> >
> > @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link,
> > AVFrame
> > *in)
> >   table, out_full,
> >   brightness, contrast,
> > saturation);
> >
> > -out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > AVCOL_RANGE_MPEG;
> > +// color_range describes YUV, it is undefined for RGB
> > +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> > out_desc->nb_components != 1) {
> > +out->color_range = AVCOL_RANGE_UNSPECIFIED;
> > +} else
> > +out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > AVCOL_RANGE_MPEG;
> >  }
> >
> >  av_reduce(>sample_aspect_ratio.num,
> > >sample_aspect_ratio.den,
> > --
> > 2.16.2
> >
> 
>  This is not optimal, as full color_range should remain full when not
>  changed.
> >>>
> >>> there is no range for rgb formats. The range is specific to YUV based
> >>> formats.
> >>> Thats, if iam guessing correctly what you meant. You did not really say
> >>> which case you meant here. So maybe there is an issue and i misunderstand
> >>> what you refer to
> >>
> >> Maybe not for swscale here but does exist otherwise.
> > 
> > It has no meaning for RGB. There is no limited range RGB
> > also, the API defines it only for YUV. So if it had meaning for RGB its not 
> > defined
> > what meaning that would be. The ranges for luma and chroma differ so its not
> > natural or obvious how to extend it to RGB.
> > Iam also not aware of any specification that defines limited range RGB
> See HDMI, HD-SDI, CEA-861, pretty much anything related to sending RGB over 
> wires in a non-PC context.
> 
> (No comment on whether it is useful to include it, but dismissing limited 
> range RGB as not a thing is probably not a good idea.  I would kindof expect 
> things like DeckLink to be using limited-range RGB everywhere, but I'm not 
> familiar with the details there.)

Is this used just over wires or also in software ?
aka should we update our enum to also cover this and 
If yes then we also probably should add support for this
to swscale

thx

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH] lavc/hevc: Don't parse NAL unit for a dummy buffer

[Steven Liu]

> On 27 Mar 2018, at 15:57, Haihao Xiang  wrote:
> 
> hevc parser mistakenly reports the following message if a dummy buffer
> is padded for EOF
> 
>   [hevc @ 0x559b63848610] missing picture in access unit
> 
> Signed-off-by: Haihao Xiang 
> ---
> libavcodec/hevc_parser.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index a468682ed33..228784e946f 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -294,6 +294,8 @@ static int hevc_parse(AVCodecParserContext *s, 
> AVCodecContext *avctx,
> int next;
> HEVCParserContext *ctx = s->priv_data;
> ParseContext *pc = >pc;
> +int is_dummy_buf = (buf_size == 0);
What about use !buf_size
> +const uint8_t *dummy_buf = buf;
> 
> if (avctx->extradata && !ctx->parsed_extradata) {
> ff_hevc_decode_extradata(avctx->extradata, avctx->extradata_size, 
> >ps, >sei,
> @@ -313,7 +315,10 @@ static int hevc_parse(AVCodecParserContext *s, 
> AVCodecContext *avctx,
> }
> }
> 
> -parse_nal_units(s, buf, buf_size, avctx);
> +is_dummy_buf = (is_dummy_buf && (dummy_buf == buf));
> +
> +if (!is_dummy_buf)
> +parse_nal_units(s, buf, buf_size, avctx);
> 
> *poutbuf  = buf;
> *poutbuf_size = buf_size;
> -- 
> 2.14.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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

[FFmpeg-devel] [PATCH] lavc/hevc: Don't parse NAL unit for a dummy buffer

[Haihao Xiang]

hevc parser mistakenly reports the following message if a dummy buffer
is padded for EOF

   [hevc @ 0x559b63848610] missing picture in access unit

Signed-off-by: Haihao Xiang 
---
 libavcodec/hevc_parser.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index a468682ed33..228784e946f 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -294,6 +294,8 @@ static int hevc_parse(AVCodecParserContext *s, 
AVCodecContext *avctx,
 int next;
 HEVCParserContext *ctx = s->priv_data;
 ParseContext *pc = >pc;
+int is_dummy_buf = (buf_size == 0);
+const uint8_t *dummy_buf = buf;
 
 if (avctx->extradata && !ctx->parsed_extradata) {
 ff_hevc_decode_extradata(avctx->extradata, avctx->extradata_size, 
>ps, >sei,
@@ -313,7 +315,10 @@ static int hevc_parse(AVCodecParserContext *s, 
AVCodecContext *avctx,
 }
 }
 
-parse_nal_units(s, buf, buf_size, avctx);
+is_dummy_buf = (is_dummy_buf && (dummy_buf == buf));
+
+if (!is_dummy_buf)
+parse_nal_units(s, buf, buf_size, avctx);
 
 *poutbuf  = buf;
 *poutbuf_size = buf_size;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/cfhd: error due to improper allocation of height in buffers

[Gagandeep Singh]

On Tue, 27 Mar 2018, 12:41 Gagandeep Singh, 
wrote:

> ticket #6675 the distortion in the bottom 8 pixels fixed
> ---
>  libavcodec/cfhd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index e35732df45..f10742f4fa 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
> @@ -213,13 +213,14 @@ static int alloc_buffers(AVCodecContext *avctx)
>  int width  = i ? avctx->width  >> chroma_x_shift : avctx->width;
>  int height = i ? avctx->height >> chroma_y_shift : avctx->height;
>  ptrdiff_t stride = FFALIGN(width  / 8, 8) * 8;
> -height   = FFALIGN(height / 8, 2) * 8;
> +if (chroma_y_shift)
> +height = FFALIGN(height / 8, 2) * 8;
>  s->plane[i].width  = width;
>  s->plane[i].height = height;
>  s->plane[i].stride = stride;
>
>  w8 = FFALIGN(s->plane[i].width  / 8, 8);
> -h8 = FFALIGN(s->plane[i].height / 8, 2);
> +h8 = height / 8;
>  w4 = w8 * 2;
>  h4 = h8 * 2;
>  w2 = w4 * 2;
> --
> 2.14.1
>
>
> From b1912774babcf737bd20ce0264c9b10fd0ca0183 Mon Sep 17 00:00:00 2001
> From: Gagandeep Singh 
> Date: Tue, 27 Mar 2018 12:34:27 +0530
> Subject: [FFmpeg-devel][PATCH 2/2] tests/ref/fate/cfhd-3: updated
> reference to work with the
>  patch
>
> the output can be confirmed to be better than the one with the reference
> hash.
> ---
>  tests/ref/fate/cfhd-3 | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/tests/ref/fate/cfhd-3 b/tests/ref/fate/cfhd-3
> index 60e13c64a7..59fdc92260 100644
> --- a/tests/ref/fate/cfhd-3
> +++ b/tests/ref/fate/cfhd-3
> @@ -3,13 +3,13 @@
>  #codec_id 0: rawvideo
>  #dimensions 0: 496x241
>  #sar 0: 0/1
> -0,  0,  0,1,   478144, 0x6ed01dcd
> -0,  1,  1,1,   478144, 0x6ed01dcd
> -0,  2,  2,1,   478144, 0x6ed01dcd
> -0,  3,  3,1,   478144, 0xb1b4a74b
> -0,  4,  4,1,   478144, 0x94c345c3
> -0,  5,  5,1,   478144, 0x05e0388d
> -0,  6,  6,1,   478144, 0xe747476a
> -0,  7,  7,1,   478144, 0x8c1561f1
> -0,  8,  8,1,   478144, 0x8c1561f1
> -0,  9,  9,1,   478144, 0x8c1561f1
> +0,  0,  0,1,   478144, 0x48a01dbb
> +0,  1,  1,1,   478144, 0x48a01dbb
> +0,  2,  2,1,   478144, 0x48a01dbb
> +0,  3,  3,1,   478144, 0xb978a72f
> +0,  4,  4,1,   478144, 0x7bbb4679
> +0,  5,  5,1,   478144, 0xc3fd3f59
> +0,  6,  6,1,   478144, 0xfd2a4816
> +0,  7,  7,1,   478144, 0x207f65d3
> +0,  8,  8,1,   478144, 0x207f65d3
> +0,  9,  9,1,   478144, 0x207f65d3
> --
> 2.14.1
>


Don't use this patch, I have sent updated patch mail , here I messed up
combining two commits

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

[FFmpeg-devel] [PATCH] lavc/cfhd: debugged padding issue for last 8 pixels distortion

[Gagandeep Singh]

fate reference has also been updated and can be tested that the patched
output is better for the sample cfhd_odd.mov in fate reference. fixes
ticket #6675.
---
 libavcodec/cfhd.c |  5 +++--
 tests/ref/fate/cfhd-3 | 20 ++--
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index e35732df45..f10742f4fa 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -213,13 +213,14 @@ static int alloc_buffers(AVCodecContext *avctx)
 int width  = i ? avctx->width  >> chroma_x_shift : avctx->width;
 int height = i ? avctx->height >> chroma_y_shift : avctx->height;
 ptrdiff_t stride = FFALIGN(width  / 8, 8) * 8;
-height   = FFALIGN(height / 8, 2) * 8;
+if (chroma_y_shift)
+height = FFALIGN(height / 8, 2) * 8;
 s->plane[i].width  = width;
 s->plane[i].height = height;
 s->plane[i].stride = stride;
 
 w8 = FFALIGN(s->plane[i].width  / 8, 8);
-h8 = FFALIGN(s->plane[i].height / 8, 2);
+h8 = height / 8;
 w4 = w8 * 2;
 h4 = h8 * 2;
 w2 = w4 * 2;
diff --git a/tests/ref/fate/cfhd-3 b/tests/ref/fate/cfhd-3
index 60e13c64a7..59fdc92260 100644
--- a/tests/ref/fate/cfhd-3
+++ b/tests/ref/fate/cfhd-3
@@ -3,13 +3,13 @@
 #codec_id 0: rawvideo
 #dimensions 0: 496x241
 #sar 0: 0/1
-0,  0,  0,1,   478144, 0x6ed01dcd
-0,  1,  1,1,   478144, 0x6ed01dcd
-0,  2,  2,1,   478144, 0x6ed01dcd
-0,  3,  3,1,   478144, 0xb1b4a74b
-0,  4,  4,1,   478144, 0x94c345c3
-0,  5,  5,1,   478144, 0x05e0388d
-0,  6,  6,1,   478144, 0xe747476a
-0,  7,  7,1,   478144, 0x8c1561f1
-0,  8,  8,1,   478144, 0x8c1561f1
-0,  9,  9,1,   478144, 0x8c1561f1
+0,  0,  0,1,   478144, 0x48a01dbb
+0,  1,  1,1,   478144, 0x48a01dbb
+0,  2,  2,1,   478144, 0x48a01dbb
+0,  3,  3,1,   478144, 0xb978a72f
+0,  4,  4,1,   478144, 0x7bbb4679
+0,  5,  5,1,   478144, 0xc3fd3f59
+0,  6,  6,1,   478144, 0xfd2a4816
+0,  7,  7,1,   478144, 0x207f65d3
+0,  8,  8,1,   478144, 0x207f65d3
+0,  9,  9,1,   478144, 0x207f65d3
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/2] lavc/cfhd: error due to improper allocation of height in buffers

[Gagandeep Singh]

ticket #6675 the distortion in the bottom 8 pixels fixed
---
 libavcodec/cfhd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index e35732df45..f10742f4fa 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -213,13 +213,14 @@ static int alloc_buffers(AVCodecContext *avctx)
 int width  = i ? avctx->width  >> chroma_x_shift : avctx->width;
 int height = i ? avctx->height >> chroma_y_shift : avctx->height;
 ptrdiff_t stride = FFALIGN(width  / 8, 8) * 8;
-height   = FFALIGN(height / 8, 2) * 8;
+if (chroma_y_shift)
+height = FFALIGN(height / 8, 2) * 8;
 s->plane[i].width  = width;
 s->plane[i].height = height;
 s->plane[i].stride = stride;
 
 w8 = FFALIGN(s->plane[i].width  / 8, 8);
-h8 = FFALIGN(s->plane[i].height / 8, 2);
+h8 = height / 8;
 w4 = w8 * 2;
 h4 = h8 * 2;
 w2 = w4 * 2;
-- 
2.14.1


From b1912774babcf737bd20ce0264c9b10fd0ca0183 Mon Sep 17 00:00:00 2001
From: Gagandeep Singh 
Date: Tue, 27 Mar 2018 12:34:27 +0530
Subject: [FFmpeg-devel][PATCH 2/2] tests/ref/fate/cfhd-3: updated reference to 
work with the
 patch

the output can be confirmed to be better than the one with the reference
hash.
---
 tests/ref/fate/cfhd-3 | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tests/ref/fate/cfhd-3 b/tests/ref/fate/cfhd-3
index 60e13c64a7..59fdc92260 100644
--- a/tests/ref/fate/cfhd-3
+++ b/tests/ref/fate/cfhd-3
@@ -3,13 +3,13 @@
 #codec_id 0: rawvideo
 #dimensions 0: 496x241
 #sar 0: 0/1
-0,  0,  0,1,   478144, 0x6ed01dcd
-0,  1,  1,1,   478144, 0x6ed01dcd
-0,  2,  2,1,   478144, 0x6ed01dcd
-0,  3,  3,1,   478144, 0xb1b4a74b
-0,  4,  4,1,   478144, 0x94c345c3
-0,  5,  5,1,   478144, 0x05e0388d
-0,  6,  6,1,   478144, 0xe747476a
-0,  7,  7,1,   478144, 0x8c1561f1
-0,  8,  8,1,   478144, 0x8c1561f1
-0,  9,  9,1,   478144, 0x8c1561f1
+0,  0,  0,1,   478144, 0x48a01dbb
+0,  1,  1,1,   478144, 0x48a01dbb
+0,  2,  2,1,   478144, 0x48a01dbb
+0,  3,  3,1,   478144, 0xb978a72f
+0,  4,  4,1,   478144, 0x7bbb4679
+0,  5,  5,1,   478144, 0xc3fd3f59
+0,  6,  6,1,   478144, 0xfd2a4816
+0,  7,  7,1,   478144, 0x207f65d3
+0,  8,  8,1,   478144, 0x207f65d3
+0,  9,  9,1,   478144, 0x207f65d3
-- 
2.14.1

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