Re: [FFmpeg-devel] [PATCH] fix few compiler warnings

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 01:51:05AM +, Davinder Singh wrote:
> On Sun, May 22, 2016 at 2:09 AM Michael Niedermayer 
> wrote:
> 
> > On Sat, May 21, 2016 at 02:21:17PM +, Davinder Singh wrote:
> > > hi,
> > >
> > > this patch fixes following compiler warnings:
> > >
> > > libavcodec/cfhd.c:346:78: warning: format specifies type 'unsigned short'
> > > but the argument has type 'int' [-Wformat]
> > > av_log(avctx, AV_LOG_DEBUG, "Small chunk length %"PRIu16"
> > > %s\n", data * 4, tag < 0 ? "optional" : "required");
> > > ~~
> > >   ^~~~
> > > libavcodec/cfhd.c:472:110: warning: format specifies type 'unsigned
> > short'
> > > but the argument has type 'int' [-Wformat]
> > > av_log(avctx, AV_LOG_DEBUG, "Start of lowpass coeffs
> > component
> > > %"PRIu16" height:%d, width:%d\n", s->channel_num, lowpass_height,
> > > lowpass_width);
> > >
> > >  ~~^~
> > > libavcodec/cfhd.c:490:77: warning: format specifies type 'unsigned short'
> > > but the argument has type 'int' [-Wformat]
> > > av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients
> > %"PRIu16"\n",
> > > lowpass_width * lowpass_height);
> > >   ~~
> > >  ^~
> > >
> > >
> > >
> > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type 'char' but
> > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc, data[i].size)
> > > ~~~^~~~
> > > libavcodec/tableprint.h:37:29: note: expanded from macro
> > > 'WRITE_1D_FUNC_ARGV'
> > >printf(" "fmtstr",", __VA_ARGS__);\
> > > ^~~
> > > libavcodec/dv_tablegen.c:30:60: warning: format specifies type 'char' but
> > > the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
> > >"{0x%"PRIx32", %"PRId8"}", data[i].vlc, data[i].size)
> > > ~~~^~~~
> > >
> > >
> > >
> > > libavfilter/af_hdcd.c:896:57: warning: shifting a negative signed value
> > is
> > > undefined [-Wshift-negative-value]
> > > state->readahead = readaheadtab[bits & ~(-1 << 8)];
> > >
> > >
> > >
> > > libavfilter/vf_hwdownload.c:59:5: warning: ignoring return value of
> > > function declared with warn_unused_result attribute [-Wunused-result]
> > > ff_formats_ref(infmts,  >inputs[0]->out_formats);
> > > ^~ ~~~
> > > libavfilter/vf_hwdownload.c:60:5: warning: ignoring return value of
> > > function declared with warn_unused_result attribute [-Wunused-result]
> > > ff_formats_ref(outfmts, >outputs[0]->in_formats);
> > > ^~ ~~~
> > >
> > >
> > >
> > > libavutil/opencl.c:456:17: warning: variable 'kernel_source' is used
> > > uninitialized whenever 'for' loop exits because its condition is false
> > > [-Wsometimes-uninitialized]
> > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > ^~~~
> > > libavutil/opencl.c:466:10: note: uninitialized use occurs here
> > > if (!kernel_source) {
> > >  ^
> > > libavutil/opencl.c:456:17: note: remove the condition if it is always
> > true
> > > for (i = 0; i < opencl_ctx.kernel_code_count; i++) {
> > > ^~~~
> > > libavutil/opencl.c:448:30: note: initialize the variable 'kernel_source'
> > to
> > > silence this warning
> > > const char *kernel_source;
> > >  ^
> > >   = NULL
> >
> > >  libavcodec/cfhd.c   |6 +++---
> > >  libavcodec/dv_tablegen.c|2 +-
> > >  libavfilter/af_hdcd.c   |2 +-
> > >  libavfilter/vf_hwdownload.c |6 --
> > >  libavutil/opencl.c  |2 +-
> >
> > please split this patch
> > the fixed warnings are unrelated to each other and possibly differnt
> > developers would like to reply to different parts
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > I have often repented speaking, but never of holding my tongue.
> > -- Xenocrates
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  af_hdcd.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 0ff76093ae99c1ef8ae87b70d8bf5b6ef92c43b9  
> 0003-libavfilter-af_hdcd-fixed-negative-signed-value-shif.patch
> From c498d1a86f3cdbed94cc8bc4a9af7c87af03b275 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Sun, 22 May 2016 06:18:58 +0530
> Subject: [PATCH 3/7]

Re: [FFmpeg-devel] [PATCH] fate: add aecho test

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 08:56:18AM +, Petru Rares Sincraian wrote:
> 
> Hi Michael,
> 
> I have found some parameters that produce the same results in x64 and x32 
> architectures. Here is the patch :)

seem to work on mingw 32/64 and arm/mips qemu too
patch applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH] avcodec/iff: mention RGB8/RGBN decoder

2016-05-22 Thread Michael Niedermayer 
On Sun, May 22, 2016 at 06:49:35PM +0200, Piotr Bandurski wrote:


applied

thanks

[...]

-- 
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] Masked LZ Decompression

2016-05-22 Thread Umair Khan 
On Sun, May 22, 2016 at 11:11 PM, Paul B Mahol  wrote:
> On 5/22/16, Umair Khan  wrote:
>> On Fri, May 20, 2016 at 11:53 PM, Paul B Mahol  wrote:
>>> On 5/20/16, Umair Khan  wrote:
 Hi,

 I'm working on implementing floating point support in the ALS decoder.
 In this I've to use masked LZ decompression. I've written the code for
 myself for masked lz decompression using the help from the reference
 software.
 Although, I'm not yet sure if an implementation of masked LZ is
 already there in FFmpeg or not.
 If it is already there, it makes no sense to have my own implementation
 as
 well.

 So anybody has any idea if we have masked LZ implementation already or
 not ?
>>>
>>> IMHO we do not. Because its audio related.
>>
>> Hi Paul,
>>
>> Any idea about this https://ffmpeg.org/doxygen/2.8/lzw_8c.html ?
>> This looks like the encoder part -
>> https://ffmpeg.org/doxygen/2.8/lzwenc_8c.html
>
> Different thing, you can look at code.
>
>>
>> I'm not sure how masked LZ is different from LZW. There's almost zero
>> information available on internet about masked lz.
>> Also, there's a research paper available here -
>> http://www.aes.org/e-lib/browse.cfm?elib=13068
>> Any way if we can get this ?
>
> No need to get it if there is already code for it.
>
> When you will finally send patch?

I fixed the error which I was having in which the output of channel 0
was not correct.
I still have some features which are not working properly. I plan to
send the patch before Friday.

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

Re: [FFmpeg-devel] Masked LZ Decompression

2016-05-22 Thread Paul B Mahol 
On 5/22/16, Umair Khan  wrote:
> On Fri, May 20, 2016 at 11:53 PM, Paul B Mahol  wrote:
>> On 5/20/16, Umair Khan  wrote:
>>> Hi,
>>>
>>> I'm working on implementing floating point support in the ALS decoder.
>>> In this I've to use masked LZ decompression. I've written the code for
>>> myself for masked lz decompression using the help from the reference
>>> software.
>>> Although, I'm not yet sure if an implementation of masked LZ is
>>> already there in FFmpeg or not.
>>> If it is already there, it makes no sense to have my own implementation
>>> as
>>> well.
>>>
>>> So anybody has any idea if we have masked LZ implementation already or
>>> not ?
>>
>> IMHO we do not. Because its audio related.
>
> Hi Paul,
>
> Any idea about this https://ffmpeg.org/doxygen/2.8/lzw_8c.html ?
> This looks like the encoder part -
> https://ffmpeg.org/doxygen/2.8/lzwenc_8c.html

Different thing, you can look at code.

>
> I'm not sure how masked LZ is different from LZW. There's almost zero
> information available on internet about masked lz.
> Also, there's a research paper available here -
> http://www.aes.org/e-lib/browse.cfm?elib=13068
> Any way if we can get this ?

No need to get it if there is already code for it.

When you will finally send patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] [v2] libavcodec/options.c: handle hw_frames_ctx where necessary

2016-05-22 Thread Andrey Turkin 
Yeah, I saw that patch series today. Still should be fixed until the
function goes away. I'll send patch to libav as well shortly.

2016-05-22 16:39 GMT+03:00 Mark Thompson :

> Looks fine; it does fix an immediate problem.
>
> Note that development around hwcontext is mainly happening in libav, and
> this sort of copy support is not really an intended use.
>
> 
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Masked LZ Decompression

2016-05-22 Thread Umair Khan 
On Fri, May 20, 2016 at 11:53 PM, Paul B Mahol  wrote:
> On 5/20/16, Umair Khan  wrote:
>> Hi,
>>
>> I'm working on implementing floating point support in the ALS decoder.
>> In this I've to use masked LZ decompression. I've written the code for
>> myself for masked lz decompression using the help from the reference
>> software.
>> Although, I'm not yet sure if an implementation of masked LZ is
>> already there in FFmpeg or not.
>> If it is already there, it makes no sense to have my own implementation as
>> well.
>>
>> So anybody has any idea if we have masked LZ implementation already or not ?
>
> IMHO we do not. Because its audio related.

Hi Paul,

Any idea about this https://ffmpeg.org/doxygen/2.8/lzw_8c.html ?
This looks like the encoder part - https://ffmpeg.org/doxygen/2.8/lzwenc_8c.html

I'm not sure how masked LZ is different from LZW. There's almost zero
information available on internet about masked lz.
Also, there's a research paper available here -
http://www.aes.org/e-lib/browse.cfm?elib=13068
Any way if we can get this ?

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

[FFmpeg-devel] [PATCH] avcodec/iff: mention RGB8/RGBN decoder

2016-05-22 Thread Piotr Bandurski 


0001-avcodec-iff-mention-RGB8-RGBN-decoder.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Tee improvement - discussion

2016-05-22 Thread Marton Balint 


On Wed, 18 May 2016, Jan Sebechlebsky wrote:

[...]

I'm thinking of implementing this queue by wrapping up AVFifoBuffer 
(similarily than AVThreadMessageQueue does but with the configurable 
behaviour as described above).


Exactly what behaviour is missing from AVThreadMessageQueue? Isn't there a 
chance to extend that, or implement all additional logic on top of it?


What is missing is basically just the discussed configurable behaviour how to 
deal with overfilled queue. I originally thought that the queue would flush 
old packets automatically (from the point of view of consumer / producer it 
would be transparent). But if the consumer will be responsible for flushing 
the packets in non-blocking mode I guess the AVThreadMessageQueue will do the 
work. This really simplifies the whole task.


I just wonder, is simply flushing the whole buffer good solution? Shouldn't 
keyframe flag be considered (either flush until next keyframe(s)), or ignore 
packet which arrived after flush until new keyframe arrives? If so this 
wouldrequire some additional functionality to be added to 
AVThreadMessageQueue (since it would be no longer related to general message 
queue it should be probably implemented separately).


A consumer would flush the queue (every packet), then clear the overflow 
flag, and then - like you said - ignore (drop) all incoming packets until 
a keyframe arrives, and from that it would start actually processing 
packets. You don't need this functionality in the message queue, the 
consumer can do this as well.


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

Re: [FFmpeg-devel] Which additional files need to be modified when adding PPC-specific version of libswscale/input.c

2016-05-22 Thread Paul B Mahol 
On 5/21/16, Dan Parrot  wrote:
> I am working on a patch to improve ffmpeg performance on PPC by using
> vector SIMD facilities for those processor versions that have the
> capability.
>
> There are 50 functions in libswscale/input.c that I am modifying. Adding
> #ifdefs in all the functions probably isn't the way to go.
>
> Is there a preferred method to implement such a change?

Yes, look how it is done for x86. There is directory named x86 and ppc.
>
> Thanks.
> Dan Parrot.
>
>
> ___
> 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] libavcodec/mmaldec.c: add needs for deinterlacing

2016-05-22 Thread Jens Ziller 
Am Samstag, den 21.05.2016, 21:57 +0200 schrieb Michael Niedermayer:
> On Sat, May 21, 2016 at 09:20:55PM +0200, Jens Ziller wrote:
> > 
> > for deinterlacing is needed frame->interlaced_frame and format
> > struct. This patch added this.
> > 
> > Signed-off-by: Jens Ziller 
> > ---
> >  libavcodec/mmaldec.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index 52232d5..89f19a0 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
> >  int eos_received;
> >  int eos_sent;
> >  int extradata_sent;
> > +int interlaced_frame;
> >  } MMALDecodeContext;
> >  
> >  // Assume decoder is guaranteed to produce output after at least
> > this
> > many
> > @@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext
> > *avctx)
> the inline patch is corrupted by newlines
> the attached patch is missing the author
> "Patch does not have a valid e-mail address."
> and the whole mail cannot be applied as the inline patch is corrupted
> 
> [...]
> 

Sorry for inconvenience. Attached is the new version.

Regards Jens.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-develFrom f5818bde8e73b778c13b21e89d24f0d687c96714 Mon Sep 17 00:00:00 2001
From: Jens Ziller 
Date: Sun, 22 May 2016 09:49:45 +0200
Subject: [PATCH] for deinterlacing needed

---
 libavcodec/mmaldec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 52232d5..89f19a0 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
 int eos_received;
 int eos_sent;
 int extradata_sent;
+int interlaced_frame;
 } MMALDecodeContext;
 
 // Assume decoder is guaranteed to produce output after at least this many
@@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext *avctx)
 int ret = 0;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_ES_FORMAT_T *format_out = decoder->output[0]->format;
+MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T interlace_type;
 
 ffmmal_poolref_unref(ctx->pool_out);
 if (!(ctx->pool_out = av_mallocz(sizeof(*ctx->pool_out {
@@ -300,6 +302,15 @@ static int ffmal_update_format(AVCodecContext *avctx)
 if ((status = mmal_port_format_commit(decoder->output[0])))
 goto fail;
 
+interlace_type.hdr.id = MMAL_PARAMETER_VIDEO_INTERLACE_TYPE;
+interlace_type.hdr.size = sizeof(MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T);
+status = mmal_port_parameter_get(decoder->output[0], _type.hdr);
+if (status != MMAL_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Cannot read MMAL interlace information!\n");
+} else {
+ctx->interlaced_frame = !(interlace_type.eMode == MMAL_InterlaceProgressive);
+}
+
 if ((ret = ff_set_dimensions(avctx, format_out->es->video.crop.x + format_out->es->video.crop.width,
 format_out->es->video.crop.y + format_out->es->video.crop.height)) < 0)
 goto fail;
@@ -607,7 +618,12 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  AVFrame *frame,
 MMALDecodeContext *ctx = avctx->priv_data;
 int ret = 0;
 
+frame->interlaced_frame = ctx->interlaced_frame;
+
 if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
+// in data[2] give the format struct for configure deinterlacer and renderer
+frame->data[2] = ctx->decoder->output[0]->format;
+
 if (!ctx->pool_out)
 return AVERROR_UNKNOWN; // format change code failed with OOM previously
 
-- 
2.7.3

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

[FFmpeg-devel] Which additional files need to be modified when adding PPC-specific version of libswscale/input.c

2016-05-22 Thread Dan Parrot 
I am working on a patch to improve ffmpeg performance on PPC by using
vector SIMD facilities for those processor versions that have the
capability. 

There are 50 functions in libswscale/input.c that I am modifying. Adding
#ifdefs in all the functions probably isn't the way to go.

Is there a preferred method to implement such a change?

Thanks.
Dan Parrot.


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

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

2016-05-22 Thread Marton Balint 


On Sat, 21 May 2016, Felt, Patrick wrote:


On 5/21/16, 3:38 AM, "ffmpeg-devel on behalf of Marton Balint" 
 wrote:


--- 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,


Should be BMDDisplayMode, not long.


+   decklink_direction_t direction,
+   int ffmpeg_mode,
+   IDeckLinkDisplayMode **mode)


As far a I see you do not use **mode with a non-NULL arugment in your
code, so you can get rid of it and its functionality.


True, in this patch I do not use **mode, however I noticed that 
elsewhere we did a similar loop.  This could consolidate the code into 
one fuction so we don’t have duplicate code.  That would definitely be 
an unrelated change so I left it open enough to hopefully suffice.  We 
can take it out if we need to.




If you intend to submit that patch as well soon to the mailing list, then 
OK. You can also submit that as a patch series so we can see that keeping 
it is really useful, and no futher changes are necessary in the function.





+{
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;


unnecessary space before avctx


most of the spaces here are because I copied and pasted those lines from 
other, previously defined functions.  I removed from where I was seeing 
them, however I may have removed some extras.  Please don’t consider 
those a formatting change.


Please, don't mix cleaning up existing code with new features, it makes 
reviewing much harder.





+break;
+}
+
+internal_mode->Release();
+}
+
+itermode->Release();
+if (internal_mode) {


What if there is no match for ffmpeg_mode? Is it documented in the
Decklink SDK that internal_mode will be overwritten to NULL on the last
iteration?


Good catch.  I’ll rework this loop.


+int ff_decklink_mode_to_ffmpeg(AVFormatContext *avctx,
+   decklink_direction_t direction,
+   IDeckLinkDisplayMode **mode)


should use *mode, not **mode, because *mode is not overwritten in this
function


modified this one as there really isn’t a need to send back mode information


+int ff_decklink_device_autodetect(AVFormatContext *avctx)


Probably worth remaining to somehting like
ff_decklink_can_detect_input_format otherwise somebody may be
under the impression that this function will do the autodetection.


I’ve modified this to ff_decklink_device_supports_autodetect


Autodetect what? Sorry, but for me it is still not clear if this means 
supporting the input detection (one card can have multiple inputs), or the 
input format, that is why I would put "input format" somewhere in the name...





@@ -244,6 +245,12 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
BMDTimeValue frameTime;
BMDTimeValue frameDuration;

+/* if we don't have video, we are in the autodetect phase.  skip 
everything and let
+ * autodetect do its magic */
+if (!ctx->video) {
+return S_OK;
+}
+
ctx->frameCount++;

// Handle Video Frame
@@ -393,6 +400,14 @@ HRESULT decklink_input_callback::VideoInputFormatChanged(
BMDVideoInputFormatChangedEvents events, IDeckLinkDisplayMode *mode,
BMDDetectedVideoInputFormatFlags)
{
+
+/* undo all the autodetect stuff so we can move on with life */
+ctx->dli->PauseStreams();
+ctx->dli->FlushStreams();
+
+ctx->mode_num = ff_decklink_mode_to_ffmpeg(avctx, DIRECTION_IN, );
+ctx->video = 1;


I would only do anything in this function, if ctx->auto_detect is set
to 1, and I would also set ctx->auto_detect to 0, so you don't have to
use a separate ->video variable for signalling a successful autodetection.

Also don't you want to StopStreams and DisableAudio/VideoInput here?
Because you will be re-doing the whole initialization stuff later, and I
am not sure you are supposed to call ff_decklink_set_format when the
streams are already running.



The decklink sdk specifically states that there should be a pause here 
and not a stop/start.  Also, ff_decklink_set_format() only checks that a 
mode is supported.  It doesn’t actually do anything else with the 
decklink api.


Okay, but later, on decklink_start_input you create a whole new decklink 
input callback, shouldn't you release the old? Or am I missing something?


Also are you sure when you start the actual capture, no further 
FormatChange callbacks will fire? So even if the streams are paused, will 
the new EnableVideoInput override the old setting with the format 
detection flag?


That is why I think that maybe it is more simple and reliable to stop 
everything and restart the whole stuff after we acquired the format.



@@ -510,34 +525,74 @@ av_cold

Re: [FFmpeg-devel] [PATCH] [v2] libavcodec/options.c: handle hw_frames_ctx where necessary

2016-05-22 Thread Mark Thompson 
On 20/05/16 11:31, Andrey Turkin wrote:
> avcodec_copy_context didn't handle hw_frames_ctx references correctly which 
> could cause crashes.
> ---
> 
> Changes from v1: reverted changes to avcodec_free_context
> 
> 
>  libavcodec/options.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/libavcodec/options.c b/libavcodec/options.c
> index ea2563b..08c2259 100644
> --- a/libavcodec/options.c
> +++ b/libavcodec/options.c
> @@ -197,6 +197,7 @@ int avcodec_copy_context(AVCodecContext *dest, const 
> AVCodecContext *src)
>  av_freep(>inter_matrix);
>  av_freep(>extradata);
>  av_freep(>subtitle_header);
> +av_buffer_unref(>hw_frames_ctx);
>  
>  memcpy(dest, src, sizeof(*dest));
>  av_opt_copy(dest, src);
> @@ -225,6 +226,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  dest->inter_matrix= NULL;
>  dest->rc_override = NULL;
>  dest->subtitle_header = NULL;
> +dest->hw_frames_ctx   = NULL;
>  
>  #define alloc_and_copy_or_fail(obj, size, pad) \
>  if (src->obj && size > 0) { \
> @@ -245,6 +247,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  av_assert0(dest->subtitle_header_size == src->subtitle_header_size);
>  #undef alloc_and_copy_or_fail
>  
> +if (src->hw_frames_ctx) {
> +dest->hw_frames_ctx = av_buffer_ref(src->hw_frames_ctx);
> +if (!dest->hw_frames_ctx)
> +goto fail;
> +}
> +
>  return 0;
>  
>  fail:
> @@ -255,6 +263,7 @@ fail:
>  av_freep(>subtitle_header);
>  dest->subtitle_header_size = 0;
>  dest->extradata_size = 0;
> +av_buffer_unref(>hw_frames_ctx);
>  av_opt_free(dest);
>  return AVERROR(ENOMEM);
>  }
> 

Looks fine; it does fix an immediate problem.

Note that development around hwcontext is mainly happening in libav, and this 
sort of copy support is not really an intended use.



Thanks,

- Mark

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

Re: [FFmpeg-devel] [Vote] Code of Conduct

2016-05-22 Thread Michael Niedermayer 
On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> This is the version i had in my pending branch and should be the last 
> version of the Code of Conduct from march, IIRC there where no further 
> comments on the last version, so iam calling everyone to vote on this.
> Everyone because it should be binding to everyone.
> 
> Kieran and Thilo asked for a formal vote and i agree that this needs
> a vote.
> 
> I wanted to send this earlier, but was always busy with other things
> 

> Please state clearly if you agree to the text or if not.

agree

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

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


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

[FFmpeg-devel] [PATCH] vaapi: Enable more libva surface formats

2016-05-22 Thread Mark Thompson 
---
These were not already enabled because the other tine does not have suitable 
support for them.

BGR0/RGB0 tested and working.  I don't have any hardware for the others, but I 
believe they should work.

 libavutil/hwcontext_vaapi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index c2cdaa9..7c3e4bd 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -86,16 +86,16 @@ static struct {
 MAP(YUY2, YUV422,  YUYV422),
 MAP(Y800, YUV400,  GRAY8),
 #ifdef VA_FOURCC_P010
-  //MAP(P010, YUV420_10BPP, P010),
+MAP(P010, YUV420_10BPP, P010),
 #endif
 MAP(BGRA, RGB32,   BGRA),
-  //MAP(BGRX, RGB32,   BGR0),
+MAP(BGRX, RGB32,   BGR0),
 MAP(RGBA, RGB32,   RGBA),
-  //MAP(RGBX, RGB32,   RGB0),
+MAP(RGBX, RGB32,   RGB0),
 MAP(ABGR, RGB32,   ABGR),
-  //MAP(XBGR, RGB32,   0BGR),
+MAP(XBGR, RGB32,   0BGR),
 MAP(ARGB, RGB32,   ARGB),
-  //MAP(XRGB, RGB32,   0RGB),
+MAP(XRGB, RGB32,   0RGB),
 };
 #undef MAP

-- 
2.8.1

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

Re: [FFmpeg-devel] [Vote] Code of Conduct

2016-05-22 Thread Peter Ross 
On Sat, May 21, 2016 at 04:10:39PM +0200, Michael Niedermayer wrote:
> On Wed, May 18, 2016 at 08:40:07PM +0200, Michael Niedermayer wrote:
> > This is the version i had in my pending branch and should be the last 
> > version of the Code of Conduct from march, IIRC there where no further 
> > comments on the last version, so iam calling everyone to vote on this.
> > Everyone because it should be binding to everyone.
> > 
> > Kieran and Thilo asked for a formal vote and i agree that this needs
> > a vote.
> > 
> > I wanted to send this earlier, but was always busy with other things
> > 
> > Please state clearly if you agree to the text or if not.
> > we can extend and tune it later and do another vote if there are more
> >  suggestions
> 
> 3 days passed, 7 people casted a vote, 4 days left
> 
> Everyone please vote (unless you truely dont care either way)

I agree with the text.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

Re: [FFmpeg-devel] [PATCH] web/contact: correct the condition for op status on IRC

2016-05-22 Thread Michael Niedermayer 
On Sat, May 21, 2016 at 08:34:30PM -0800, Lou Logan wrote:
> On Sat, May 21, 2016, at 03:20 PM, Michael Niedermayer wrote:
> > we gave op status to commiters in the CVS and SVN days
> > since git an entry in MAINTAINERs was generally required to be offered
> > op status and push rights where not required.
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >src/contact |    4 ++--
> >1 file changed, 2 insertions(+), 2 deletions(-)
>  
> Fine with me.

applied

thanks

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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

Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add needs for deinterlacing

2016-05-22 Thread Jens Ziller 
Am Samstag, den 21.05.2016, 21:57 +0200 schrieb Michael Niedermayer:
> On Sat, May 21, 2016 at 09:20:55PM +0200, Jens Ziller wrote:
> > 
> > for deinterlacing is needed frame->interlaced_frame and format
> > struct. This patch added this.
> > 
> > Signed-off-by: Jens Ziller 
> > ---
> >  libavcodec/mmaldec.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
> > index 52232d5..89f19a0 100644
> > --- a/libavcodec/mmaldec.c
> > +++ b/libavcodec/mmaldec.c
> > @@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
> >  int eos_received;
> >  int eos_sent;
> >  int extradata_sent;
> > +int interlaced_frame;
> >  } MMALDecodeContext;
> >  
> >  // Assume decoder is guaranteed to produce output after at least
> > this
> > many
> > @@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext
> > *avctx)
> the inline patch is corrupted by newlines
> the attached patch is missing the author
> "Patch does not have a valid e-mail address."
> and the whole mail cannot be applied as the inline patch is corrupted
> 
> [...]
> 

Sorry for inconvenience. Attached is the new patch.

Regards Jens.

> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-develFrom f5818bde8e73b778c13b21e89d24f0d687c96714 Mon Sep 17 00:00:00 2001
From: Jens Ziller 
Date: Sun, 22 May 2016 09:49:45 +0200
Subject: [PATCH] for deinterlacing needed

---
 libavcodec/mmaldec.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 52232d5..89f19a0 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -88,6 +88,7 @@ typedef struct MMALDecodeContext {
 int eos_received;
 int eos_sent;
 int extradata_sent;
+int interlaced_frame;
 } MMALDecodeContext;
 
 // Assume decoder is guaranteed to produce output after at least this many
@@ -274,6 +275,7 @@ static int ffmal_update_format(AVCodecContext *avctx)
 int ret = 0;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_ES_FORMAT_T *format_out = decoder->output[0]->format;
+MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T interlace_type;
 
 ffmmal_poolref_unref(ctx->pool_out);
 if (!(ctx->pool_out = av_mallocz(sizeof(*ctx->pool_out {
@@ -300,6 +302,15 @@ static int ffmal_update_format(AVCodecContext *avctx)
 if ((status = mmal_port_format_commit(decoder->output[0])))
 goto fail;
 
+interlace_type.hdr.id = MMAL_PARAMETER_VIDEO_INTERLACE_TYPE;
+interlace_type.hdr.size = sizeof(MMAL_PARAMETER_VIDEO_INTERLACE_TYPE_T);
+status = mmal_port_parameter_get(decoder->output[0], _type.hdr);
+if (status != MMAL_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Cannot read MMAL interlace information!\n");
+} else {
+ctx->interlaced_frame = !(interlace_type.eMode == MMAL_InterlaceProgressive);
+}
+
 if ((ret = ff_set_dimensions(avctx, format_out->es->video.crop.x + format_out->es->video.crop.width,
 format_out->es->video.crop.y + format_out->es->video.crop.height)) < 0)
 goto fail;
@@ -607,7 +618,12 @@ static int ffmal_copy_frame(AVCodecContext *avctx,  AVFrame *frame,
 MMALDecodeContext *ctx = avctx->priv_data;
 int ret = 0;
 
+frame->interlaced_frame = ctx->interlaced_frame;
+
 if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
+// in data[2] give the format struct for configure deinterlacer and renderer
+frame->data[2] = ctx->decoder->output[0]->format;
+
 if (!ctx->pool_out)
 return AVERROR_UNKNOWN; // format change code failed with OOM previously
 
-- 
2.7.3

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

Re: [FFmpeg-devel] [PATCH] fate: add aecho test

2016-05-22 Thread Petru Rares Sincraian 

Hi Michael,

I have found some parameters that produce the same results in x64 and x32 
architectures. Here is the patch :)


Thanks,
Petru Rares.

From: ffmpeg-devel  on behalf of Michael 
Niedermayer 
Sent: Saturday, May 14, 2016 3:50:03 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] fate: add aecho test

On Sat, May 14, 2016 at 09:07:17AM +, Petru Rares Sincraian wrote:
>
>
> Hi there,
>
> Here I add a new test for aecho filter.

>  fate/filter-audio.mak |5
>  ref/fate/filter-aecho |  286 
> ++
>  2 files changed, 291 insertions(+)
> efd0670e8f0c0c23e9d1392052b03ac4b7e047f0  0001-fate-add-aecho-test.patch
> From 25e8de6f4caa08a1903a6756ca718ef06722d116 Mon Sep 17 00:00:00 2001
> From: Petru Rares Sincraian 
> Date: Sat, 14 May 2016 11:04:25 +0200
> Subject: [PATCH] fate: add aecho test

this fails on x86-32

--- ffmpeg/tests/ref/fate/filter-aecho 2016-05-14 13:33:43.477820778 +0200
+++ tests/data/fate/filter-aecho2016-05-14 15:16:00.441950067 +0200
@@ -46,241 +46,241 @@
 0,  40960,  40960, 1024, 4096, 0x7c4ce7e9
 0,  41984,  41984, 1024, 4096, 0x5eddeb19
 0,  43008,  43008, 1024, 4096, 0x351c08c4
-0,  44032,  44032, 1024, 4096, 0x30c6db8f
-0,  45056,  45056, 1024, 4096, 0x1c4b3258
-0,  46080,  46080, 1024, 4096, 0xe32d157e
+0,  44032,  44032, 1024, 4096, 0x4dd4db91
+0,  45056,  45056, 1024, 4096, 0x07ad3256
+0,  46080,  46080, 1024, 4096, 0xe6131580
 0,  47104,  47104, 1024, 4096, 0xbbe9e635
-0,  48128,  48128, 1024, 4096, 0x7e8214dc
-0,  49152,  49152, 1024, 4096, 0xd671e4c1
-0,  50176,  50176, 1024, 4096, 0xd268f457
-0,  51200,  51200, 1024, 4096, 0x6051018e
+0,  48128,  48128, 1024, 4096, 0x8f4014de
+0,  49152,  49152, 1024, 4096, 0xbc53e4bf
+0,  50176,  50176, 1024, 4096, 0xf2b6f459
+0,  51200,  51200, 1024, 4096, 0x83350192


you can test that with somethng like
./configure  --arch=x86_32 --target-os=linux --extra-cflags=-m32 
--extra-ldflags=-m32  --enable-cross-compile

aecho uses floats so rounding and precission differences can cause
differences between platforms
you could improve aecho so it does not depend on floats for filtering
of s16 samples
but maybe you can find parameters that give the same result on all
platforms without that
or a small reference file would need to be added and tiny_psnr used
for comparing

[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
From 5a3be60397e2f7bc0d84232736c8d44508bfbeff Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian 
Date: Sun, 22 May 2016 09:45:49 +0200
Subject: [PATCH] fate: add aecho test

---
 tests/fate/filter-audio.mak |   5 +
 tests/ref/fate/filter-aecho | 265 
 2 files changed, 270 insertions(+)
 create mode 100644 tests/ref/fate/filter-aecho

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 7f7e520..5e5f1f9 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -3,6 +3,11 @@ fate-filter-adelay: tests/data/asynth-44100-2.wav
 fate-filter-adelay: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-adelay: CMD = framecrc -i $(SRC) -af adelay=42
 
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, AECHO, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-aecho
+fate-filter-aecho: tests/data/asynth-44100-2.wav
+fate-filter-aecho: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-aecho: CMD = framecrc -i $(SRC) -af aecho=0.5:0.5:32:0.5
+
 tests/data/hls-list.m3u8: TAG = GEN
 tests/data/hls-list.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
 	$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-aecho b/tests/ref/fate/filter-aecho
new file mode 100644
index 000..f564fcc
--- /dev/null
+++ b/tests/ref/fate/filter-aecho
@@ -0,0 +1,265 @@
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: pcm_s16le
+#sample_rate 0: 44100
+#channel_layout 0: 3
+0,  0,  0, 1024, 4096, 0x3019edd5
+0,   1024,   1024, 1024, 4096, 0x2df2fe2f
+0,   2048,   2048, 1024, 4096, 0xde37ff37
+0,   3072,   3072, 1024, 4096, 0xe933f6a5
+0,   4096,   4096, 1024, 4096, 0xd5acf1f3
+0,   5120,   5120, 1024, 4096, 0x82a6f903
+0,   6144,   6144, 1024,