Re: [FFmpeg-devel] [PATCH] Respect payload offset in av_packet_ref

2016-05-12 Thread Michael Niedermayer 
On Thu, May 12, 2016 at 05:47:09PM +0300, Andriy Lysnevych wrote:
> You are right
> ---
>  libavcodec/avpacket.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

applied

thx

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] avformat/dump.c: fix mixed log levels

2016-05-12 Thread Michael Niedermayer 
On Thu, May 12, 2016 at 04:38:41PM +0200, Tobias Rapp wrote:
> On 12.05.2016 16:00, Michael Niedermayer wrote:
> >On Thu, May 12, 2016 at 10:26:03AM +0200, Tobias Rapp wrote:
> >>Previously a partial log message without newline was printed in case of
> >>loglevel=warning.
> >>
> >>Signed-off-by: Tobias Rapp 
> >>---
> >> libavformat/dump.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/libavformat/dump.c b/libavformat/dump.c
> >>index d6a3249..9eb6146 100644
> >>--- a/libavformat/dump.c
> >>+++ b/libavformat/dump.c
> >>@@ -422,7 +422,7 @@ static void dump_sidedata(void *ctx, AVStream *st, 
> >>const char *indent)
> >> dump_mastering_display_metadata(ctx, );
> >> break;
> >> default:
> >>-av_log(ctx, AV_LOG_WARNING,
> >>+av_log(ctx, AV_LOG_INFO,
> >
> >this is ok if its wanted to change the log level
> >is that wanted ?
> >
> >if not the \n would have to be printed with the max log level
> >that was used so its not missning
> >
> >[..]
> >
> 
> I guess this wouldn't be enough. Also the whitespace separator log
> level has to be adapted, which will then produce confusing output in
> case of mixed known/unknown side data together with
> loglevel=warning.
> 
> A better option would be to assemble the log message into a buffer
> first using av_bprintf and then av_log the complete message either
> with AV_LOG_INFO or AV_LOG_WARNING depending on whether only known
> side data was found or not?
> 
> Or maybe always print the (assembled) side data info with
> AV_LOG_INFO plus additional AV_LOG_WARNING for each unknown side
> data item?

sounds like a complex mess, ill apply the patch as its simpler and
noone objected
it can always be replaced by another solution

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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Updated -- Add input mode autodetect to the decklink module.

2016-05-12 Thread Felt, Patrick 
-- Add input mode autodetect to the decklink module. Previously users had to 
supply the input format like this 'DeckLink Device@modenum'.  This patch allows 
users to either leave it off completely, or supply 0 or negative number to 
indicate autodetect is requested. Autodetect only works the first time so if 
the mode changes mid stream you'll die


---
 libavdevice/decklink_common.cpp | 110 
 libavdevice/decklink_common.h   |   5 ++
 libavdevice/decklink_common_c.h |   1 +
 libavdevice/decklink_dec.cpp|  85 +--
 libavdevice/decklink_dec_c.c|   1 +
 5 files changed, 187 insertions(+), 15 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index ac7964c..1d51294 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -98,6 +98,90 @@ HRESULT ff_decklink_get_display_name(IDeckLink *This, const 
char **displayName)
 return hr;
 }
 
+long ff_decklink_mode_to_bm(AVFormatContext *avctx,
+   decklink_direction_t direction,
+   int ffmpeg_mode,
+   IDeckLinkDisplayMode **mode)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+IDeckLinkDisplayModeIterator *itermode;
+IDeckLinkDisplayMode *internal_mode;
+
+int result=0;
+HRESULT res;
+
+if (direction == DIRECTION_IN) {
+res = ctx->dli->GetDisplayModeIterator ();
+} else {
+res = ctx->dlo->GetDisplayModeIterator ();
+}
+
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
+return -1;
+}
+
+while (itermode->Next(_mode) == S_OK) {
+if (++result == ffmpeg_mode) {
+break;
+}
+
+internal_mode->Release();
+}
+
+itermode->Release();
+if (internal_mode) {
+result = internal_mode->GetDisplayMode();
+if (mode) {
+*mode = internal_mode;
+} else {
+internal_mode->Release();
+}
+
+return result;
+}
+
+return 0;
+}
+
+int ff_decklink_mode_to_ffmpeg(AVFormatContext *avctx,
+   decklink_direction_t direction,
+   IDeckLinkDisplayMode **mode)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+IDeckLinkDisplayModeIterator *itermode;
+IDeckLinkDisplayMode *internal_mode;
+long bdm_mode_number = (*mode)->GetDisplayMode();
+int result=1, found=0;
+HRESULT res;
+
+if (direction == DIRECTION_IN) {
+res = ctx->dli->GetDisplayModeIterator ();
+} else {
+res = ctx->dlo->GetDisplayModeIterator ();
+}
+
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
+return -1;
+}
+
+while (itermode->Next(_mode) == S_OK) {
+if (internal_mode->GetDisplayMode() == bdm_mode_number) {
+internal_mode->Release();
+found = 1;
+break;
+}
+internal_mode->Release();
+result++;
+}
+
+itermode->Release();
+return (found) ? result : -1;
+}
+
 int ff_decklink_set_format(AVFormatContext *avctx,
int width, int height,
int tb_num, int tb_den,
@@ -197,6 +281,29 @@ int ff_decklink_list_devices(AVFormatContext *avctx)
 return 0;
 }
 
+int ff_decklink_device_autodetect(AVFormatContext *avctx)
+{
+HRESULT res;
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+IDeckLinkAttributes *attrs = NULL;
+bool auto_detect;
+
+res = ctx->dl->QueryInterface(IID_IDeckLinkAttributes, (void**));
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get decklink attributes\n");
+return -1;
+}
+
+res = attrs->GetFlag(BMDDeckLinkSupportsInputFormatDetection, 
_detect);
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Attribute fetch failed\n");
+return -1;
+}
+
+return (auto_detect) ? 1 : 0;
+}
+
 int ff_decklink_list_formats(AVFormatContext *avctx, decklink_direction_t 
direction)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
@@ -219,6 +326,9 @@ int ff_decklink_list_formats(AVFormatContext *avctx, 
decklink_direction_t direct
 
 av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
avctx->filename);
+if (ff_decklink_device_autodetect(avctx)) {
+av_log(avctx, AV_LOG_INFO, "\t-1\tAuto detection supported\n");
+}
 while (itermode->Next() == S_OK) {
 BMDTimeValue tb_num, tb_den;
 mode->GetFrameRate(_num, _den);
diff --git

Re: [FFmpeg-devel] [PATCH] -- Add input mode autodetect to the decklink module.

2016-05-12 Thread Felt, Patrick 
Ah.  Didn’t realize we had that.  Will do.

On 5/12/16, 1:37 PM, "ffmpeg-devel on behalf of Marton Balint" 
 wrote:

>
>
>On Thu, 12 May 2016, Matthias Hunstock wrote:
>
>> Am 12.05.2016 um 19:16 schrieb Felt, Patrick:
>>> +while (!ctx->video) {
>>> +if (autodetect_delay--) {
>>> +/* this could indicate we are in the right mode.  let's 
>>> assume so */
>>> +continue;
>>> +}
>>> +sleep(1);
>>> +}
>>
>> I don't get it. How does this loop sleep for autodetect_delay seconds? I
>> read it like "spin-loop for autodetect_delay times and then probe
>> ctx->video each second, possibly forever".
>>
>
>Also get rid of sleep and unistd.h, use av_usleep instead...
>
>Regards,
>Marton
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] -- Add input mode autodetect to the decklink module.

2016-05-12 Thread Matthias Hunstock 
Am 12.05.2016 um 19:16 schrieb Felt, Patrick:
> +while (!ctx->video) {
> +if (autodetect_delay--) {
> +/* this could indicate we are in the right mode.  let's 
> assume so */
> +continue;
> +}
> +sleep(1);
> +}

I don't get it. How does this loop sleep for autodetect_delay seconds? I
read it like "spin-loop for autodetect_delay times and then probe
ctx->video each second, possibly forever".



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

Re: [FFmpeg-devel] [PATCH] -- Add input mode autodetect to the decklink module.

2016-05-12 Thread Marton Balint 



On Thu, 12 May 2016, Matthias Hunstock wrote:


Am 12.05.2016 um 19:16 schrieb Felt, Patrick:

+while (!ctx->video) {
+if (autodetect_delay--) {
+/* this could indicate we are in the right mode.  let's assume 
so */
+continue;
+}
+sleep(1);
+}


I don't get it. How does this loop sleep for autodetect_delay seconds? I
read it like "spin-loop for autodetect_delay times and then probe
ctx->video each second, possibly forever".



Also get rid of sleep and unistd.h, use av_usleep instead...

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

[FFmpeg-devel] [PATCH] -- Add input mode autodetect to the decklink module.

2016-05-12 Thread Felt, Patrick 
Previously users had to supply the input format like this 'DeckLink 
Device@modenum'.  This patch allows users to either leave it off completely, or 
supply 0 or negative number to indicate autodetect is requested.
 Autodetect only works the first time so if the mode changes mid stream you'll 
die.

---
 libavdevice/decklink_common.cpp | 110 
 libavdevice/decklink_common.h   |   5 ++
 libavdevice/decklink_common_c.h |   1 +
 libavdevice/decklink_dec.cpp|  85 +--
 libavdevice/decklink_dec_c.c|   1 +
 5 files changed, 187 insertions(+), 15 deletions(-)

diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index ac7964c..1d51294 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -98,6 +98,90 @@ HRESULT ff_decklink_get_display_name(IDeckLink *This, const 
char **displayName)
 return hr;
 }

+long ff_decklink_mode_to_bm(AVFormatContext *avctx,
+   decklink_direction_t direction,
+   int ffmpeg_mode,
+   IDeckLinkDisplayMode **mode)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+IDeckLinkDisplayModeIterator *itermode;
+IDeckLinkDisplayMode *internal_mode;
+
+int result=0;
+HRESULT res;
+
+if (direction == DIRECTION_IN) {
+res = ctx->dli->GetDisplayModeIterator ();
+} else {
+res = ctx->dlo->GetDisplayModeIterator ();
+}
+
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
+return -1;
+}
+
+while (itermode->Next(_mode) == S_OK) {
+if (++result == ffmpeg_mode) {
+break;
+}
+
+internal_mode->Release();
+}
+
+itermode->Release();
+if (internal_mode) {
+result = internal_mode->GetDisplayMode();
+if (mode) {
+*mode = internal_mode;
+} else {
+internal_mode->Release();
+}
+
+return result;
+}
+
+return 0;
+}
+
+int ff_decklink_mode_to_ffmpeg(AVFormatContext *avctx,
+   decklink_direction_t direction,
+   IDeckLinkDisplayMode **mode)
+{
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+IDeckLinkDisplayModeIterator *itermode;
+IDeckLinkDisplayMode *internal_mode;
+long bdm_mode_number = (*mode)->GetDisplayMode();
+int result=1, found=0;
+HRESULT res;
+
+if (direction == DIRECTION_IN) {
+res = ctx->dli->GetDisplayModeIterator ();
+} else {
+res = ctx->dlo->GetDisplayModeIterator ();
+}
+
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get the mode iterator\n");
+return -1;
+}
+
+while (itermode->Next(_mode) == S_OK) {
+if (internal_mode->GetDisplayMode() == bdm_mode_number) {
+internal_mode->Release();
+found = 1;
+break;
+}
+internal_mode->Release();
+result++;
+}
+
+itermode->Release();
+return (found) ? result : -1;
+}
+
 int ff_decklink_set_format(AVFormatContext *avctx,
int width, int height,
int tb_num, int tb_den,
@@ -197,6 +281,29 @@ int ff_decklink_list_devices(AVFormatContext *avctx)
 return 0;
 }

+int ff_decklink_device_autodetect(AVFormatContext *avctx)
+{
+HRESULT res;
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
+struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
+IDeckLinkAttributes *attrs = NULL;
+bool auto_detect;
+
+res = ctx->dl->QueryInterface(IID_IDeckLinkAttributes, (void**));
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Could not get decklink attributes\n");
+return -1;
+}
+
+res = attrs->GetFlag(BMDDeckLinkSupportsInputFormatDetection, 
_detect);
+if (res != S_OK) {
+av_log(avctx, AV_LOG_ERROR, "Attribute fetch failed\n");
+return -1;
+}
+
+return (auto_detect) ? 1 : 0;
+}
+
 int ff_decklink_list_formats(AVFormatContext *avctx, decklink_direction_t 
direction)
 {
 struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
@@ -219,6 +326,9 @@ int ff_decklink_list_formats(AVFormatContext *avctx, 
decklink_direction_t direct

 av_log(avctx, AV_LOG_INFO, "Supported formats for '%s':\n",
avctx->filename);
+if (ff_decklink_device_autodetect(avctx)) {
+av_log(avctx, AV_LOG_INFO, "\t-1\tAuto detection supported\n");
+}
 while (itermode->Next() == S_OK) {
 BMDTimeValue tb_num, tb_den;
 mode->GetFrameRate(_num, _den);
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h

Re: [FFmpeg-devel] [PATCH] Const src in av_packet_clone declaration

2016-05-12 Thread Carl Eugen Hoyos 
wm4  googlemail.com> writes:

> > -AVPacket *av_packet_clone(AVPacket *src)
> > +AVPacket *av_packet_clone(const AVPacket *src)
> 
> That's a change that could break source-compatibility with C++

How can this breakage be reproduced?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/libx265: Support gray encoding

2016-05-12 Thread Derek Buitenhuis 
On 5/12/2016 4:18 PM, Carl Eugen Hoyos wrote:
> The feature is not new (and the necessary define in the header 
> was always there) but it did not work (at least for some 
> revisions).
> How should I proceed?

Hmm.

I'm not really a fan of bumping up the required x265 version,
since it has been stable for a good amount of time now...

One option is to add something like:
if (VERSION < SOMEVERSION)
goto fail;

Another option is to just leave the pacth as-is and claim it's
not our problem because it was x265's bug.

I don't have a strong opinion on either, so go with whichever people
are OK with.

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

Re: [FFmpeg-devel] [PATCH] Const src in av_packet_clone declaration

2016-05-12 Thread wm4 
On Thu, 12 May 2016 16:02:48 +0300
Andriy Lysnevych  wrote:

> ---
>  libavcodec/avcodec.h  | 2 +-
>  libavcodec/avpacket.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 97b2128..1ad0412 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -4300,7 +4300,7 @@ AVPacket *av_packet_alloc(void);
>   * @see av_packet_alloc
>   * @see av_packet_ref
>   */
> -AVPacket *av_packet_clone(AVPacket *src);
> +AVPacket *av_packet_clone(const AVPacket *src);
> 
>  /**
>   * Free the packet, if the packet is reference counted, it will be
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 9cdfafd..dd8b71e 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -584,7 +584,7 @@ fail:
>  return ret;
>  }
> 
> -AVPacket *av_packet_clone(AVPacket *src)
> +AVPacket *av_packet_clone(const AVPacket *src)
>  {
>  AVPacket *ret = av_packet_alloc();
> 

That's a change that could break source-compatibility with C++, I don't
think it can be made so easily.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/libx265: Support gray encoding

2016-05-12 Thread Carl Eugen Hoyos 
Derek Buitenhuis  gmail.com> writes:

> On 5/12/2016 10:43 AM, Carl Eugen Hoyos wrote:
> > I am also attaching the patch I just sent to x265-devel 
> > that allows to test the feature.
> 
> Would this not need a version requirement bump in configure, 
> if the feature is new?

The feature is not new (and the necessary define in the header 
was always there) but it did not work (at least for some 
revisions).
How should I proceed?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] Respect payload offset in av_packet_ref

2016-05-12 Thread Andriy Lysnevych 
You are right
---
 libavcodec/avpacket.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index dd8b71e..19597f2 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -568,16 +568,18 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
 if (ret < 0)
 goto fail;
 memcpy(dst->buf->data, src->data, src->size);
+dst->data = dst->buf->data;
 } else {
 dst->buf = av_buffer_ref(src->buf);
 if (!dst->buf) {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
+dst->data = src->data;
 }

 dst->size = src->size;
-dst->data = dst->buf->data;
+
 return 0;
 fail:
 av_packet_free_side_data(dst);
-- 
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/dump.c: fix mixed log levels

2016-05-12 Thread Tobias Rapp 

On 12.05.2016 16:00, Michael Niedermayer wrote:

On Thu, May 12, 2016 at 10:26:03AM +0200, Tobias Rapp wrote:

Previously a partial log message without newline was printed in case of
loglevel=warning.

Signed-off-by: Tobias Rapp 
---
 libavformat/dump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index d6a3249..9eb6146 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -422,7 +422,7 @@ static void dump_sidedata(void *ctx, AVStream *st, const 
char *indent)
 dump_mastering_display_metadata(ctx, );
 break;
 default:
-av_log(ctx, AV_LOG_WARNING,
+av_log(ctx, AV_LOG_INFO,


this is ok if its wanted to change the log level
is that wanted ?

if not the \n would have to be printed with the max log level
that was used so its not missning

[..]



I guess this wouldn't be enough. Also the whitespace separator log level 
has to be adapted, which will then produce confusing output in case of 
mixed known/unknown side data together with loglevel=warning.


A better option would be to assemble the log message into a buffer first 
using av_bprintf and then av_log the complete message either with 
AV_LOG_INFO or AV_LOG_WARNING depending on whether only known side data 
was found or not?


Or maybe always print the (assembled) side data info with AV_LOG_INFO 
plus additional AV_LOG_WARNING for each unknown side data item?


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/dump.c: fix mixed log levels

2016-05-12 Thread Michael Niedermayer 
On Thu, May 12, 2016 at 10:26:03AM +0200, Tobias Rapp wrote:
> Previously a partial log message without newline was printed in case of
> loglevel=warning.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  libavformat/dump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index d6a3249..9eb6146 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -422,7 +422,7 @@ static void dump_sidedata(void *ctx, AVStream *st, const 
> char *indent)
>  dump_mastering_display_metadata(ctx, );
>  break;
>  default:
> -av_log(ctx, AV_LOG_WARNING,
> +av_log(ctx, AV_LOG_INFO,

this is ok if its wanted to change the log level
is that wanted ?

if not the \n would have to be printed with the max log level
that was used so its not missning

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

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


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

Re: [FFmpeg-devel] [PATCH] Respect payload offset in av_packet_ref

2016-05-12 Thread Hendrik Leppkes 
On Thu, May 12, 2016 at 3:44 PM, Andriy Lysnevych
 wrote:
> Details are in the ticket https://trac.ffmpeg.org/ticket/5543
>
> ---
>  libavcodec/avpacket.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index dd8b71e..842d8ba 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -568,16 +568,18 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
>  if (ret < 0)
>  goto fail;
>  memcpy(dst->buf->data, src->data, src->size);
> +dst->data = dst->buf->data;
>  } else {
>  dst->buf = av_buffer_ref(src->buf);
>  if (!dst->buf) {
>  ret = AVERROR(ENOMEM);
>  goto fail;
>  }
> +dst->data = dst->buf->data + (src->data - src->buf->data);

av_buffer_ref always returns a clean copy of the source buffer, with
the exact same data buffer.
So, using "dst->data = src->data" is shorter, simpler, and safer.

>  }
>
>  dst->size = src->size;
> -dst->data = dst->buf->data;
> +
>  return 0;
>  fail:
>  av_packet_free_side_data(dst);
> --


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

Re: [FFmpeg-devel] [PATCH] swresample/arm: add ff_resample_common_apply_filter_{x4, x8}_{float, s16}_neon

2016-05-12 Thread Benoit Fouet 

Hi,

On 12/05/2016 15:22, Matthieu Bouron wrote:

On Thu, May 12, 2016 at 10:01 AM, Benoit Fouet  wrote:


Hi,

I mostly have nits remarks.

On 11/05/2016 18:39, Matthieu Bouron wrote:


From: Matthieu Bouron 



[...]

diff --git a/libswresample/arm/resample.S b/libswresample/arm/resample.S

new file mode 100644
index 000..13462e3
--- /dev/null
+++ b/libswresample/arm/resample.S
@@ -0,0 +1,77 @@

[...]

+function ff_resample_common_apply_filter_x4_float_neon, export=1
+vmov.f32q0, #0.0   @
accumulator
+1:  vld1.32 {q1}, [r1]!@
src
+vld1.32 {q2}, [r2]!@
filter
+vmla.f32q0, q1, q2 @
src + {0..3} * filter + {0..3}


nit: the comment could be "accu += src[0..3] . filter[0..3]"
same for the other ones below

[...]

+subsr3, #4 @

filter_length -= 4
+bgt 1b @
loop until filter_length
+vpadd.f32   d0, d0, d1 @
pair adding of the 4x32-bit accumulated values
+vpadd.f32   d0, d0, d0 @
pair adding of the 4x32-bit accumulator values
+vst1.32 {d0[0]}, [r0]  @
write accumulator
+mov pc, lr
+endfunc
+
+function ff_resample_common_apply_filter_x8_float_neon, export=1
+vmov.f32q0, #0.0   @
accumulator
+1:  vld1.32 {q1}, [r1]!@
src1
+vld1.32 {q2}, [r2]!@
filter1
+vld1.32 {q8}, [r1]!@
src2
+vld1.32 {q9}, [r2]!@
filter2
+vmla.f32q0, q1, q2 @
src1 + {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @
src2 + {0..3} * filter2 + {0..3}


instead of using src1 and src2, you may want to use src[0..3] and src[4..7]
so, if I reuse the formulation I proposed above:
accu += src[0..3] . filter[0..3]
accu += src[4..7] . filter[4..7]


Fixed locally (as well as the other case you mentionned) with:
-vmla.f32q0, q1, q2 @
src1 + {0..3} * filter1 + {0..3}
-vmla.f32q0, q8, q9 @
src2 + {0..3} * filter2 + {0..3}
+vmla.f32q0, q1, q2 @
accumulator += src1 + {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @
accumulator += src2 + {4..7} * filter2 + {4..7}

I prefer to use + {0..3} instead of [0..3] to make the comments consistent
with what has been done in swscale/arm.



Fine for me (I chose the "[]" notation to be consistent with the "." 
notation also, in order to do as if it were a dot product between two 
vectors).



+subsr3, #8 @

filter_length -= 4


-= 8


Fixed locally.



[...]

diff --git a/libswresample/arm/resample_init.c

b/libswresample/arm/resample_init.c
new file mode 100644
index 000..c817d03
--- /dev/null
+++ b/libswresample/arm/resample_init.c

[...]

+static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void
*dest, const void *source,   \
+int n, int update_ctx)
   \
+{
  \
+DELEM *dst = dest;
   \
+const DELEM *src = source;
   \
+int dst_index;
   \
+int index= c->index;
   \
+int frac= c->frac;
   \
+int sample_index = index >> c->phase_shift;
  \
+int x4_aligned_filter_length = c->filter_length & ~3;
  \
+int x8_aligned_filter_length = c->filter_length & ~7;
  \
+
   \
+index &= c->phase_mask;
  \
+for (dst_index = 0; dst_index < n; dst_index++) {
  \
+FELEM *filter = ((FELEM *) c->filter_bank) + c->filter_alloc *
index; \
+
   \
+FELEM2 val=0;
  \
+int i = 0;
   \
+if (x8_aligned_filter_length >= 8) {
   \
+ff_resample_common_apply_filter_x8_##TYPE##_neon(,
[sample_index],\
+ filter,
x8_aligned_filter_length);   \
+i += x8_aligned_filter_length;

[FFmpeg-devel] [PATCH] Respect payload offset in av_packet_ref

2016-05-12 Thread Andriy Lysnevych 
Details are in the ticket https://trac.ffmpeg.org/ticket/5543

---
 libavcodec/avpacket.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index dd8b71e..842d8ba 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -568,16 +568,18 @@ int av_packet_ref(AVPacket *dst, const AVPacket *src)
 if (ret < 0)
 goto fail;
 memcpy(dst->buf->data, src->data, src->size);
+dst->data = dst->buf->data;
 } else {
 dst->buf = av_buffer_ref(src->buf);
 if (!dst->buf) {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
+dst->data = dst->buf->data + (src->data - src->buf->data);
 }

 dst->size = src->size;
-dst->data = dst->buf->data;
+
 return 0;
 fail:
 av_packet_free_side_data(dst);
-- 
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swresample/arm: add ff_resample_common_apply_filter_{x4, x8}_{float, s16}_neon

2016-05-12 Thread Matthieu Bouron 
On Thu, May 12, 2016 at 10:01 AM, Benoit Fouet  wrote:

> Hi,
>
> I mostly have nits remarks.
>
> On 11/05/2016 18:39, Matthieu Bouron wrote:
>
>> From: Matthieu Bouron 
>>
>>
> [...]
>
> diff --git a/libswresample/arm/resample.S b/libswresample/arm/resample.S
>> new file mode 100644
>> index 000..13462e3
>> --- /dev/null
>> +++ b/libswresample/arm/resample.S
>> @@ -0,0 +1,77 @@
>>
>> [...]
>>
>> +function ff_resample_common_apply_filter_x4_float_neon, export=1
>> +vmov.f32q0, #0.0   @
>> accumulator
>> +1:  vld1.32 {q1}, [r1]!@
>> src
>> +vld1.32 {q2}, [r2]!@
>> filter
>> +vmla.f32q0, q1, q2 @
>> src + {0..3} * filter + {0..3}
>>
>
> nit: the comment could be "accu += src[0..3] . filter[0..3]"
> same for the other ones below
>
> [...]
>
> +subsr3, #4 @
>> filter_length -= 4
>> +bgt 1b @
>> loop until filter_length
>> +vpadd.f32   d0, d0, d1 @
>> pair adding of the 4x32-bit accumulated values
>> +vpadd.f32   d0, d0, d0 @
>> pair adding of the 4x32-bit accumulator values
>> +vst1.32 {d0[0]}, [r0]  @
>> write accumulator
>> +mov pc, lr
>> +endfunc
>> +
>> +function ff_resample_common_apply_filter_x8_float_neon, export=1
>> +vmov.f32q0, #0.0   @
>> accumulator
>> +1:  vld1.32 {q1}, [r1]!@
>> src1
>> +vld1.32 {q2}, [r2]!@
>> filter1
>> +vld1.32 {q8}, [r1]!@
>> src2
>> +vld1.32 {q9}, [r2]!@
>> filter2
>> +vmla.f32q0, q1, q2 @
>> src1 + {0..3} * filter1 + {0..3}
>> +vmla.f32q0, q8, q9 @
>> src2 + {0..3} * filter2 + {0..3}
>>
>
> instead of using src1 and src2, you may want to use src[0..3] and src[4..7]
> so, if I reuse the formulation I proposed above:
> accu += src[0..3] . filter[0..3]
> accu += src[4..7] . filter[4..7]
>

Fixed locally (as well as the other case you mentionned) with:
-vmla.f32q0, q1, q2 @
src1 + {0..3} * filter1 + {0..3}
-vmla.f32q0, q8, q9 @
src2 + {0..3} * filter2 + {0..3}
+vmla.f32q0, q1, q2 @
accumulator += src1 + {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @
accumulator += src2 + {4..7} * filter2 + {4..7}

I prefer to use + {0..3} instead of [0..3] to make the comments consistent
with what has been done in swscale/arm.


>
> +subsr3, #8 @
>> filter_length -= 4
>>
>
> -= 8
>

Fixed locally.


>
> [...]
>
> diff --git a/libswresample/arm/resample_init.c
>> b/libswresample/arm/resample_init.c
>> new file mode 100644
>> index 000..c817d03
>> --- /dev/null
>> +++ b/libswresample/arm/resample_init.c
>>
>> [...]
>>
>> +static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void
>> *dest, const void *source,   \
>> +int n, int update_ctx)
>>   \
>> +{
>>  \
>> +DELEM *dst = dest;
>>   \
>> +const DELEM *src = source;
>>   \
>> +int dst_index;
>>   \
>> +int index= c->index;
>>   \
>> +int frac= c->frac;
>>   \
>> +int sample_index = index >> c->phase_shift;
>>  \
>> +int x4_aligned_filter_length = c->filter_length & ~3;
>>  \
>> +int x8_aligned_filter_length = c->filter_length & ~7;
>>  \
>> +
>>   \
>> +index &= c->phase_mask;
>>  \
>> +for (dst_index = 0; dst_index < n; dst_index++) {
>>  \
>> +FELEM *filter = ((FELEM *) c->filter_bank) + c->filter_alloc *
>> index; \
>> +
>>   \
>> +FELEM2 val=0;
>>  \
>> +int i = 0;
>>   \
>> +if (x8_aligned_filter_length >= 8) {
>>   \
>> +ff_resample_common_apply_filter_x8_##TYPE##_neon(,
>> [sample_index],\
>> +

[FFmpeg-devel] [PATCH] Const src in av_packet_clone declaration

2016-05-12 Thread Andriy Lysnevych 
---
 libavcodec/avcodec.h  | 2 +-
 libavcodec/avpacket.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 97b2128..1ad0412 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4300,7 +4300,7 @@ AVPacket *av_packet_alloc(void);
  * @see av_packet_alloc
  * @see av_packet_ref
  */
-AVPacket *av_packet_clone(AVPacket *src);
+AVPacket *av_packet_clone(const AVPacket *src);

 /**
  * Free the packet, if the packet is reference counted, it will be
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 9cdfafd..dd8b71e 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -584,7 +584,7 @@ fail:
 return ret;
 }

-AVPacket *av_packet_clone(AVPacket *src)
+AVPacket *av_packet_clone(const AVPacket *src)
 {
 AVPacket *ret = av_packet_alloc();

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

Re: [FFmpeg-devel] [PATCH]lavc/libx265: Support gray encoding

2016-05-12 Thread Derek Buitenhuis 
On 5/12/2016 10:43 AM, Carl Eugen Hoyos wrote:
> I am also attaching the patch I just sent to x265-devel that allows to 
> test the feature.

Would this not need a version requirement bump in configure, if the feature is 
new?

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

Re: [FFmpeg-devel] [PATCHv3] h2645_parse: support badly muxed mp4 streams

2016-05-12 Thread Michael Niedermayer 
On Thu, May 12, 2016 at 12:07:40PM +0200, Hendrik Leppkes wrote:
> Some streams contain an additional AnnexB NAL inside the mp4/nalff NALU.
> This commonly occurs in interlaced streams where both fields are packed
> into the same MP4 NAL with an AnnexB startcode in between.
> 
> Port handling of this format from the previous h264 nal handling.
> 
> Fixes trac #5529
> ---
> 
> Third version which should be a bit more robust to odd corner cases.

LGTM

please also add a fate that for this

thanks

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

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


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

[FFmpeg-devel] [PATCHv3] h2645_parse: support badly muxed mp4 streams

2016-05-12 Thread Hendrik Leppkes 
Some streams contain an additional AnnexB NAL inside the mp4/nalff NALU.
This commonly occurs in interlaced streams where both fields are packed
into the same MP4 NAL with an AnnexB startcode in between.

Port handling of this format from the previous h264 nal handling.

Fixes trac #5529
---

Third version which should be a bit more robust to odd corner cases.

 libavcodec/h2645_parse.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 62d0447..9979b63 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -250,6 +250,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
   enum AVCodecID codec_id)
 {
 int consumed, ret = 0;
+const uint8_t *next_avc = is_nalff ? buf : buf + length;
 
 pkt->nb_nals = 0;
 while (length >= 4) {
@@ -257,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 int extract_length = 0;
 int skip_trailing_zeros = 1;
 
-if (is_nalff) {
+if (buf >= next_avc) {
 int i;
 for (i = 0; i < nal_length_size; i++)
 extract_length = (extract_length << 8) | buf[i];
@@ -268,6 +269,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit size.\n");
 return AVERROR_INVALIDDATA;
 }
+next_avc = buf + extract_length;
 } else {
 /* search start code */
 while (buf[0] != 0 || buf[1] != 0 || buf[2] != 1) {
@@ -282,12 +284,21 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 av_log(logctx, AV_LOG_ERROR, "No start code is 
found.\n");
 return AVERROR_INVALIDDATA;
 }
-}
+} else if (buf >= (next_avc - 3))
+break;
 }
 
 buf   += 3;
 length-= 3;
 extract_length = length;
+
+if (buf >= next_avc) {
+/* skip to the start of the next NAL */
+int offset = next_avc - buf;
+buf+= offset;
+length -= offset;
+continue;
+}
 }
 
 if (pkt->nals_allocated < pkt->nb_nals + 1) {
@@ -315,6 +326,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 if (consumed < 0)
 return consumed;
 
+if (is_nalff && (extract_length != consumed) && extract_length)
+av_log(logctx, AV_LOG_DEBUG,
+   "NALFF: Consumed only %d bytes instead of %d\n",
+   consumed, extract_length);
+
 pkt->nb_nals++;
 
 /* see commit 3566042a0 */
-- 
2.7.2.windows.1

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/bsf: add a null bitstream filter.

2016-05-12 Thread Nicolas George 
Le quartidi 24 floréal, an CCXXIV, wm4 a écrit :
> Conceptually, passing the packets just along is equivalent to copying.
> It's how refcounting works; without a real copy, the first write access
> to the packet will do the real copy.

And copying the packet is doing no filtering at all on it. You actual point
is...?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/bsf: add a null bitstream filter.

2016-05-12 Thread wm4 
On Thu, 12 May 2016 11:20:28 +0200
Nicolas George  wrote:

> Le quartidi 24 floréal, an CCXXIV, Paul B Mahol a écrit :
> > Yes. I object its name. Null name is misleading. Its name should be copy.  
> 
> I can live with that if other people agree, but for now we have null and
> anull in libavfilter, that would be inconsistent. Plus, the filter does not
> copy the packet, it just passes it without any filtering. Therefore, unless
> you have support on your side, I intend to keep the name.
> 
> Regards,
> 

Conceptually, passing the packets just along is equivalent to copying.
It's how refcounting works; without a real copy, the first write access
to the packet will do the real copy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/libx265: Support gray encoding

2016-05-12 Thread Carl Eugen Hoyos 
Hi!

Attached patch implements gray encoding with libx265, does not fix or 
workaround ticket #5536.

I am also attaching the patch I just sent to x265-devel that allows to 
test the feature.

Please comment, Carl Eugen
# HG changeset patch
# User Carl Eugen Hoyos 
# Date 1463045462 -7200
# Node ID 10763a24dfb97725b291a35787c207eb9931e1a0
# Parent  a5362b9533f6a5b77740b4e8f97dba2555b6f929
encoder/sao: Do not assume three planes.

Fixes a crash when encoding gray input.

diff -r a5362b9533f6 -r 10763a24dfb9 source/encoder/sao.cpp
--- a/source/encoder/sao.cppWed May 04 21:08:09 2016 +
+++ b/source/encoder/sao.cppThu May 12 11:31:02 2016 +0200
@@ -1265,7 +1265,7 @@
 if (!allowMerge[mergeIdx])
 continue;
 
-for (int plane = 0; plane < 3; plane++)
+for (int plane = 0; plane < planes; plane++)
 {
 int64_t estDist = 0;
 SaoCtuParam* mergeSrcParam = 
&(saoParam->ctuParam[plane][addrMerge[mergeIdx]]);
exporting patch:

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 11088b2..f8dd741 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -165,6 +165,9 @@ static av_cold int libx265_encode_init(AVCodecContext 
*avctx)
 case AV_PIX_FMT_YUV444P12:
 ctx->params->internalCsp = X265_CSP_I444;
 break;
+case AV_PIX_FMT_GRAY8:
+ctx->params->internalCsp = X265_CSP_I400;
+break;
 }
 
 if (ctx->crf >= 0) {
@@ -325,6 +328,7 @@ static const enum AVPixelFormat x265_csp_eight[] = {
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_GBRP,
+AV_PIX_FMT_GRAY8,
 AV_PIX_FMT_NONE
 };
 
@@ -337,6 +341,7 @@ static const enum AVPixelFormat x265_csp_ten[] = {
 AV_PIX_FMT_YUV422P10,
 AV_PIX_FMT_YUV444P10,
 AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GRAY8,
 AV_PIX_FMT_NONE
 };
 
@@ -353,6 +358,7 @@ static const enum AVPixelFormat x265_csp_twelve[] = {
 AV_PIX_FMT_YUV422P12,
 AV_PIX_FMT_YUV444P12,
 AV_PIX_FMT_GBRP12,
+AV_PIX_FMT_GRAY8,
 AV_PIX_FMT_NONE
 };
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavc/bsf: add a null bitstream filter.

2016-05-12 Thread Nicolas George 
Le quartidi 24 floréal, an CCXXIV, Paul B Mahol a écrit :
> Yes. I object its name. Null name is misleading. Its name should be copy.

I can live with that if other people agree, but for now we have null and
anull in libavfilter, that would be inconsistent. Plus, the filter does not
copy the packet, it just passes it without any filtering. Therefore, unless
you have support on your side, I intend to keep the name.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avformat/tee: Move to new BSF API

2016-05-12 Thread Nicolas George 
Le quartidi 24 floréal, an CCXXIV, Nicolas George a écrit :
> Le quartidi 24 floréal, an CCXXIV, Jan Sebechlebsky a écrit :
> > I can change it to array, the advantage of using linked list was that number
> > of bitstream
> > filters used is not known before arguments are parsed, this way the filters
> > were initialized and as the the filters were parsed. With array the argument
> > will be parsed twice - first pass just to count and allocate the array,
> > second to initialize the filters. But it's not big deal to do it that way.
> 
> There are several instances of similar code, the array is often reallocated.
> We have macros to reallocate an array with double size efficiently. But a
> quick pre-parsing to count the number of filters is also a legitimate idea.
> 
> > Should I wait with this patch until your changes are pushed?
> 
> You can apply it on a branch of your working tree to continue your task.
> 
> > Can you explain this little bit more?
> 
> Recursive filtering is annoying to debug (lots of nested stack frames, hard
> to put break points) and does not play well with threads.
> 
> > Should I rewrite it it non-recursive
> > way (process packets with first filter, accumulare resulting packets,
> > process with next one and so on)?
> 
> The code in avconv.c has a nice way of dealing with the issue, I encourage
> to look at it.
> 
> We briefly had an API to apply several bitstream filters sequentially, until
> it was NIHed by the fork. I would support re-adding one.

I had not noticed you replied in private. Please remember to keep the
mailing-list in copy, and then no need to send to me directly since I am no
the list.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/bsf: add a null bitstream filter.

2016-05-12 Thread Paul B Mahol 
On 5/12/16, Nicolas George  wrote:
> Le decadi 10 floreal, an CCXXIV, Nicolas George a ecrit :
>> From 9507a24a4774dc7542e6cd9739104bb7d9528185 Mon Sep 17 00:00:00 2001
>> From: Nicolas George 
>> Date: Thu, 28 Apr 2016 10:25:37 +0200
>> Subject: [PATCH 1/3] lavc/bsf: add a null bitstream filter.
>>
>> It passes packets unchanged with a very low overhead.
>> Using it allows to have the same code path when bitstream filtering
>> is not used, making the code simpler and avoiding bitroting.
>> The filter can not be disabled so that applications can rely on it.
>> It is added out of alphabetical order to keep the regularity.
>
> Does someone object to the patch as it is? If not, I intend to push 1/3 and
> 2/3 soon.

Yes. I object its name. Null name is misleading. Its name should be copy.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavc/bsf: add a null bitstream filter.

2016-05-12 Thread Nicolas George 
Le decadi 10 floréal, an CCXXIV, Nicolas George a écrit :
> From 9507a24a4774dc7542e6cd9739104bb7d9528185 Mon Sep 17 00:00:00 2001
> From: Nicolas George 
> Date: Thu, 28 Apr 2016 10:25:37 +0200
> Subject: [PATCH 1/3] lavc/bsf: add a null bitstream filter.
> 
> It passes packets unchanged with a very low overhead.
> Using it allows to have the same code path when bitstream filtering
> is not used, making the code simpler and avoiding bitroting.
> The filter can not be disabled so that applications can rely on it.
> It is added out of alphabetical order to keep the regularity.

Does someone object to the patch as it is? If not, I intend to push 1/3 and
2/3 soon.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] h2645_parse: support badly muxed mp4 streams

2016-05-12 Thread Hendrik Leppkes 
Some streams contain an additional AnnexB NAL inside the mp4/nalff NALU.
This commonly occurs in interlaced streams where both fields are packed
into the same MP4 NAL with an AnnexB startcode in between.

Port handling of this format from the previous h264 nal handling.

Fixes trac #5529
---
 libavcodec/h2645_parse.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 62d0447..c0dda79 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -250,6 +250,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
   enum AVCodecID codec_id)
 {
 int consumed, ret = 0;
+const uint8_t *next_avc = is_nalff ? buf : buf + length;
 
 pkt->nb_nals = 0;
 while (length >= 4) {
@@ -257,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 int extract_length = 0;
 int skip_trailing_zeros = 1;
 
-if (is_nalff) {
+if (buf >= next_avc) {
 int i;
 for (i = 0; i < nal_length_size; i++)
 extract_length = (extract_length << 8) | buf[i];
@@ -268,6 +269,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit size.\n");
 return AVERROR_INVALIDDATA;
 }
+next_avc = buf + extract_length;
 } else {
 /* search start code */
 while (buf[0] != 0 || buf[1] != 0 || buf[2] != 1) {
@@ -282,12 +284,22 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 av_log(logctx, AV_LOG_ERROR, "No start code is 
found.\n");
 return AVERROR_INVALIDDATA;
 }
+} else if (buf >= (next_avc - 3)) {
+/* skip straight to the end, right before the next NAL
+   (offset by 3 for the code below) */
+int remaining = next_avc - buf - 3;
+buf+= remaining;
+length -= remaining;
+break;
 }
 }
 
 buf   += 3;
 length-= 3;
 extract_length = length;
+
+if (buf >= next_avc)
+continue;
 }
 
 if (pkt->nals_allocated < pkt->nb_nals + 1) {
@@ -315,6 +327,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 if (consumed < 0)
 return consumed;
 
+if (is_nalff && (extract_length != consumed) && extract_length)
+av_log(logctx, AV_LOG_DEBUG,
+   "NALFF: Consumed only %d bytes instead of %d\n",
+   consumed, extract_length);
+
 pkt->nb_nals++;
 
 /* see commit 3566042a0 */
-- 
2.7.2.windows.1

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

Re: [FFmpeg-devel] [PATCH] h2645_parse: support badly muxed mp4 streams

2016-05-12 Thread Hendrik Leppkes 
On Thu, May 12, 2016 at 10:52 AM, Hendrik Leppkes  wrote:
> Some streams contain an additional AnnexB NAL inside the mp4/nalff NALU.
> This commonly occurs in interlaced streams where both fields are packed
> into the same MP4 NAL with an AnnexB startcode in between.
>
> Port handling of this format from the previous h264 nal handling.
>
> Fixes trac #5529
> ---
>  libavcodec/h2645_parse.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 62d0447..013d23c 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -250,6 +250,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>enum AVCodecID codec_id)
>  {
>  int consumed, ret = 0;
> +const uint8_t *next_avc = is_nalff ? buf : buf + length;
>
>  pkt->nb_nals = 0;
>  while (length >= 4) {
> @@ -257,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  int extract_length = 0;
>  int skip_trailing_zeros = 1;
>
> -if (is_nalff) {
> +if (buf >= next_avc) {
>  int i;
>  for (i = 0; i < nal_length_size; i++)
>  extract_length = (extract_length << 8) | buf[i];
> @@ -268,6 +269,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit size.\n");
>  return AVERROR_INVALIDDATA;
>  }
> +next_avc = buf + extract_length;
>  } else {
>  /* search start code */
>  while (buf[0] != 0 || buf[1] != 0 || buf[2] != 1) {
> @@ -282,6 +284,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const 
> uint8_t *buf, int length,
>  av_log(logctx, AV_LOG_ERROR, "No start code is 
> found.\n");
>  return AVERROR_INVALIDDATA;
>  }
> +} else if (buf >= (next_avc - 3)) {
> +int remaining = next_avc - buf;
> +buf+= remaining;
> +length -= remaining;
> +continue;

Actually this is supposed to continue the outer loop, not the inner
loop. Why does C not have a construct for that.

>  }
>  }
>
> @@ -315,6 +322,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const 
> uint8_t *buf, int length,
>  if (consumed < 0)
>  return consumed;
>
> +if (is_nalff && (extract_length != consumed) && extract_length)
> +av_log(logctx, AV_LOG_DEBUG,
> +   "NALFF: Consumed only %d bytes instead of %d\n",
> +   consumed, extract_length);
> +
>  pkt->nb_nals++;
>
>  /* see commit 3566042a0 */
> --
> 2.7.2.windows.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] h2645_parse: support badly muxed mp4 streams

2016-05-12 Thread Hendrik Leppkes 
Some streams contain an additional AnnexB NAL inside the mp4/nalff NALU.
This commonly occurs in interlaced streams where both fields are packed
into the same MP4 NAL with an AnnexB startcode in between.

Port handling of this format from the previous h264 nal handling.

Fixes trac #5529
---
 libavcodec/h2645_parse.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 62d0447..013d23c 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -250,6 +250,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
   enum AVCodecID codec_id)
 {
 int consumed, ret = 0;
+const uint8_t *next_avc = is_nalff ? buf : buf + length;
 
 pkt->nb_nals = 0;
 while (length >= 4) {
@@ -257,7 +258,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 int extract_length = 0;
 int skip_trailing_zeros = 1;
 
-if (is_nalff) {
+if (buf >= next_avc) {
 int i;
 for (i = 0; i < nal_length_size; i++)
 extract_length = (extract_length << 8) | buf[i];
@@ -268,6 +269,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit size.\n");
 return AVERROR_INVALIDDATA;
 }
+next_avc = buf + extract_length;
 } else {
 /* search start code */
 while (buf[0] != 0 || buf[1] != 0 || buf[2] != 1) {
@@ -282,6 +284,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 av_log(logctx, AV_LOG_ERROR, "No start code is 
found.\n");
 return AVERROR_INVALIDDATA;
 }
+} else if (buf >= (next_avc - 3)) {
+int remaining = next_avc - buf;
+buf+= remaining;
+length -= remaining;
+continue;
 }
 }
 
@@ -315,6 +322,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 if (consumed < 0)
 return consumed;
 
+if (is_nalff && (extract_length != consumed) && extract_length)
+av_log(logctx, AV_LOG_DEBUG,
+   "NALFF: Consumed only %d bytes instead of %d\n",
+   consumed, extract_length);
+
 pkt->nb_nals++;
 
 /* see commit 3566042a0 */
-- 
2.7.2.windows.1

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

[FFmpeg-devel] [PATCH] avformat/dump.c: fix mixed log levels

2016-05-12 Thread Tobias Rapp 
Previously a partial log message without newline was printed in case of
loglevel=warning.

Signed-off-by: Tobias Rapp 
---
 libavformat/dump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index d6a3249..9eb6146 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -422,7 +422,7 @@ static void dump_sidedata(void *ctx, AVStream *st, const 
char *indent)
 dump_mastering_display_metadata(ctx, );
 break;
 default:
-av_log(ctx, AV_LOG_WARNING,
+av_log(ctx, AV_LOG_INFO,
"unknown side data type %d (%d bytes)", sd.type, sd.size);
 break;
 }
-- 
1.9.1


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

Re: [FFmpeg-devel] [PATCH] swresample/arm: add ff_resample_common_apply_filter_{x4, x8}_{float, s16}_neon

2016-05-12 Thread Benoit Fouet 

Hi,

I mostly have nits remarks.

On 11/05/2016 18:39, Matthieu Bouron wrote:

From: Matthieu Bouron 



[...]


diff --git a/libswresample/arm/resample.S b/libswresample/arm/resample.S
new file mode 100644
index 000..13462e3
--- /dev/null
+++ b/libswresample/arm/resample.S
@@ -0,0 +1,77 @@

[...]

+function ff_resample_common_apply_filter_x4_float_neon, export=1
+vmov.f32q0, #0.0   @ 
accumulator
+1:  vld1.32 {q1}, [r1]!@ src
+vld1.32 {q2}, [r2]!@ filter
+vmla.f32q0, q1, q2 @ src + 
{0..3} * filter + {0..3}


nit: the comment could be "accu += src[0..3] . filter[0..3]"
same for the other ones below

[...]


+subsr3, #4 @ 
filter_length -= 4
+bgt 1b @ loop 
until filter_length
+vpadd.f32   d0, d0, d1 @ pair 
adding of the 4x32-bit accumulated values
+vpadd.f32   d0, d0, d0 @ pair 
adding of the 4x32-bit accumulator values
+vst1.32 {d0[0]}, [r0]  @ write 
accumulator
+mov pc, lr
+endfunc
+
+function ff_resample_common_apply_filter_x8_float_neon, export=1
+vmov.f32q0, #0.0   @ 
accumulator
+1:  vld1.32 {q1}, [r1]!@ src1
+vld1.32 {q2}, [r2]!@ 
filter1
+vld1.32 {q8}, [r1]!@ src2
+vld1.32 {q9}, [r2]!@ 
filter2
+vmla.f32q0, q1, q2 @ src1 
+ {0..3} * filter1 + {0..3}
+vmla.f32q0, q8, q9 @ src2 
+ {0..3} * filter2 + {0..3}


instead of using src1 and src2, you may want to use src[0..3] and src[4..7]
so, if I reuse the formulation I proposed above:
accu += src[0..3] . filter[0..3]
accu += src[4..7] . filter[4..7]


+subsr3, #8 @ 
filter_length -= 4


-= 8

[...]


diff --git a/libswresample/arm/resample_init.c 
b/libswresample/arm/resample_init.c
new file mode 100644
index 000..c817d03
--- /dev/null
+++ b/libswresample/arm/resample_init.c

[...]

+static int ff_resample_common_##TYPE##_neon(ResampleContext *c, void *dest, 
const void *source,   \
+int n, int update_ctx) 
   \
+{  
   \
+DELEM *dst = dest; 
   \
+const DELEM *src = source; 
   \
+int dst_index; 
   \
+int index= c->index;   
   \
+int frac= c->frac; 
   \
+int sample_index = index >> c->phase_shift;
   \
+int x4_aligned_filter_length = c->filter_length & ~3;  
   \
+int x8_aligned_filter_length = c->filter_length & ~7;  
   \
+   
   \
+index &= c->phase_mask;
   \
+for (dst_index = 0; dst_index < n; dst_index++) {  
   \
+FELEM *filter = ((FELEM *) c->filter_bank) + c->filter_alloc * index;  
   \
+   
   \
+FELEM2 val=0;  
   \
+int i = 0; 
   \
+if (x8_aligned_filter_length >= 8) {   
   \
+ff_resample_common_apply_filter_x8_##TYPE##_neon(, 
[sample_index],\
+ filter, 
x8_aligned_filter_length);   \
+i += x8_aligned_filter_length; 
   \
+   
   \
+} else if (x4_aligned_filter_length >= 4) {