Re: [FFmpeg-devel] [PATCH] [RFC]doc/examples: alternative input handler

[Bodecs Bela]

2018.04.06. 1:34 keltezéssel, wm4 írta:

On Fri, 30 Mar 2018 14:47:25 +0200
Bodecs Bela  wrote:


Hi All,

regularly, on different forums and mailing lists a requirement popups
for a feature to automatically failover switching between main input and a
secondary input in case of main input unavailability.

The base motivation: let's say you have a unreliable live stream source
and you
want to transcode its video and audio streams in realtime but you
want to survive the ocasions when the source is unavailable. So use a
secondary live source but the transition should occur seamlessly without
breaking/re-starting the transcoding processs.

Some days ago there was a discussion on devel-irc about this topic and
we concluded that this feature is not feasible inside ffmpeg without
"hacking", but a separate client app could do this.

So I created this example app to handle two separate input sources and
switching realtime between them. I am not sure wheter it should be
inside the tools subdir.

The detailed description is available in the header section of the
source file.

I will appretiate your suggestions about it.

Thank you in advance.

best,

Bela Bodecs



Does this really quality as example? It's way too complex and seems to
be about a specific use case in place of ffmpeg.c, rather than
demonstrating API use in an educational way (what code examples are
supposed to do).

If someone wants to merge this, at least add it as top level program,
and not under the examples directory.

Thank you for your feedback.
Because on irc some said that other program can do this live switching, 
I only wanted to demonstrate that this feature is feasible based on ffmpeg.
As I wrote I am also not sure wheter it should be inside the tools 
subdir or as an example or something else.
Frankly, I do not know what formal requirements I  should include into 
the code to be qualified as a separate tool.


bb


___
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] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

[Valery Kot]

On Thu, Apr 5, 2018 at 9:02 PM, James Almer  wrote:
> On 4/5/2018 3:25 PM, Lou Logan wrote:
>> On Sun, Mar 25, 2018, at 10:51 PM, Valery Kot wrote:
>>>
>>> Just wondering: is there an active maintainer for avcodec/libopenh264?
>>
>> Doesn't appear to be so.
>>
>>> If yes - can he or she please review my patch. If no - how does
>>> maintenance works for "orphaned" modules?
>>
>> Any developer simply decides to review, approve, and/or push it. Sorry for 
>> the wait, but I recommend pinging this thread once a week until so.
>>
>> If it has been a while make sure your patch still applies cleanly to the git 
>> master branch before pinging. Otherwise please provide an updated patch.
>
> Pushed it. It's been a month and with no maintainer and apparently no
> devs using this module it's clear nobody is going to look at it.

Thanks, appreciated!

If needed, I volunteer to be a maintainer for libopenh264*, as I am
actively using this codec.

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

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[Alexander Kravchenko]

> 
> This breaks the testcase described in
> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
> one you described in this patch.
> 
> I get the following spammed repeatedly:
> 
> [AVHWFramesContext @ 0502d340] Static surface pool size exceeded.
> [mpeg2video @ 02f8d400] get_buffer() failed
> [mpeg2video @ 02f8d400] thread_get_buffer() failed
> [mpeg2video @ 02f8d400] get_buffer() failed (-12 )
> Error while decoding stream #0:1: Operation not permitted

Hi, could you please review the following updated patch
I added queue limit according initial pool size of incoming frame context.
This solves the problem running this pipeline without -extra_hw_frames 16 
option, but -extra_hw_frames option can be used to have bigger queue for 
encoder.


---
 libavcodec/amfenc.c | 97 -
 libavcodec/amfenc.h |  3 ++
 2 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 89a10ff253..eb7b20c252 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -157,6 +157,9 @@ static int amf_init_context(AVCodecContext *avctx)
 AmfContext *ctx = avctx->priv_data;
 AMF_RESULT  res = AMF_OK;
 
+ctx->hwsurfaces_in_queue = 0;
+ctx->hwsurfaces_in_queue_max = 16;
+
 // configure AMF logger
 // the return of these functions indicates old state and do not affect 
behaviour
 ctx->trace->pVtbl->EnableWriter(ctx->trace, AMF_TRACE_WRITER_DEBUG_OUTPUT, 
ctx->log_to_dbg != 0 );
@@ -187,6 +190,7 @@ static int amf_init_context(AVCodecContext *avctx)
 if (!ctx->hw_frames_ctx) {
 return AVERROR(ENOMEM);
 }
+ctx->hwsurfaces_in_queue_max = 
device_ctx->initial_pool_size - 1;
 } else {
 if(res == AMF_NOT_SUPPORTED)
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has D3D11 device which doesn't have D3D11VA interface, switching to default\n");
@@ -443,6 +447,73 @@ int ff_amf_encode_init(AVCodecContext *avctx)
 return ret;
 }
 
+#define AMF_AV_QUERY_INTERFACE(res, from, InterfaceTypeTo, to) \
+{ \
+AMFGuid guid_##InterfaceTypeTo = IID_##InterfaceTypeTo(); \
+res = from->pVtbl->QueryInterface(from, &guid_##InterfaceTypeTo, 
(void**)&to); \
+}
+
+#define AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, pThis, name, val) \
+{ \
+AMFInterface *amf_interface; \
+AMFVariantStruct var; \
+res = AMFVariantInit(&var); \
+if (res == AMF_OK) { \
+AMF_AV_QUERY_INTERFACE(res, val, AMFInterface, amf_interface)\
+if (res == AMF_OK) { \
+res = AMFVariantAssignInterface(&var, amf_interface); \
+amf_interface->pVtbl->Release(amf_interface); \
+} \
+if (res == AMF_OK) { \
+res = pThis->pVtbl->SetProperty(pThis, name, var); \
+} \
+AMFVariantClear(&var); \
+}\
+}
+
+#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
+{ \
+AMFVariantStruct var; \
+res = AMFVariantInit(&var); \
+if (res == AMF_OK) { \
+res = pThis->pVtbl->GetProperty(pThis, name, &var); \
+if (res == AMF_OK) { \
+if (var.type == AMF_VARIANT_INTERFACE && 
AMFVariantInterface(&var)) { \
+AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(&var), 
TargetType, val); \
+} else { \
+res = AMF_INVALID_DATA_TYPE; \
+} \
+} \
+AMFVariantClear(&var); \
+}\
+}
+
+static AMFBuffer* amf_create_buffer_with_frame_ref(const AVFrame* frame, 
AMFContext *context)
+{
+AVFrame *frame_ref;
+AMFBuffer *frame_ref_storage_buffer = NULL;
+AMF_RESULT res;
+
+res = context->pVtbl->AllocBuffer(context, AMF_MEMORY_HOST, 
sizeof(frame_ref), &frame_ref_storage_buffer);
+if (res == AMF_OK) {
+frame_ref = av_frame_clone(frame);
+if (frame_ref) {
+
memcpy(frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
&frame_ref, sizeof(frame_ref));
+} else {
+frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
+frame_ref_storage_buffer = NULL;
+}
+}
+return frame_ref_storage_buffer;
+}
+
+static void amf_release_buffer_with_frame_ref(AMFBuffer 
*frame_ref_storage_buffer)
+{
+AVFrame *av_frame_ref;
+memcpy(&av_frame_ref, 
frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
sizeof(av_frame_ref));
+av_frame_free(&av_frame_ref);
+frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
+} 
 
 int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
 {
@@ -484,6 +555,7 @@ int ff_amf_send_frame(AVCodecContext *a

[FFmpeg-devel] [PATCH] avformat/hlsenc: fix handling of delete_segments when %v is present

[Bodecs Bela]

Dear All,

when var_stream_map option is used, %v must appear either in segment 
name template or in the directory path. This latter case currently is 
not handled and using delete_segments flag of hls_flags is broken now. 
This patch fixes this issue.
The root cause of the bug was that HLSSegment struct only stores the 
final filename part, but not the final directory path. Most of the 
cases, final path info is unneded, It only necessary when you want to 
delete old segments (e.g in case of live streaming).
Without variant streams it was unnecessary to store the final directory 
path, because all segment were stored into the same directory. But 
introducing %v in directory names either require to store the final 
directory path into HLSSegment or associate segments with their variant 
streams to be able deleting them later. I have choosen the second 
solution and introduced a variant index data member into the segment struct.


please review this patch.

thank you in advance,

Bela Bodecs


>From ad97bcd1c4ff0b734de3bffc58e7421192a33e43 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 6 Apr 2018 12:21:59 +0200
Subject: [PATCH] avformat/hlsenc: fix handling of delete_segments when %v is
 present

When var_stream_map option is used, %v must appear either in segment
name template or in the directory path. This latter case currently is
not handled and delete_segments flag of hls_flags is broken now. This
patch fix this. The root cause of the bug was that HLSSegment struct
only stores the final filename part, but not the final directory path.
Most of the cases, final path info is unneded, It only necessary when
you want to delete old segments (e.g in case of live streaming).
Without variant streams it was unnecessary to store the final directory
path, because all segment were stored into the same directory. But
introducing %v in directory names either require to store the final
directory path into HLSSegment or associate segments with their variant
streams to be able deleting them later. I have choosen the second
solution and introduced a variant index data member into the segment
struct.

Signed-off-by: Bela Bodecs 
---
 libavformat/hlsenc.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2a54b43..8eb8421 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -75,6 +75,7 @@ typedef struct HLSSegment {
 int discont;
 int64_t pos;
 int64_t size;
+unsigned var_stream_idx;
 
 char key_uri[LINE_BUFFER_SIZE + 1];
 char iv_string[KEYSIZE*2 + 1];
@@ -106,6 +107,7 @@ typedef enum {
 } SegmentType;
 
 typedef struct VariantStream {
+unsigned var_stream_idx;
 unsigned number;
 int64_t sequence;
 AVOutputFormat *oformat;
@@ -478,9 +480,23 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 }
 p = (char *)av_basename(dirname);
 *p = '\0';
+
 }
 
 while (segment) {
+char * r_dirname = dirname;
+
+/* if %v is present in the file's directory */
+if (av_stristr(dirname, "%v")) {
+
+if (replace_int_data_in_filename(&r_dirname, dirname, 'v', 
segment->var_stream_idx) < 1) {
+ret = AVERROR(EINVAL);
+goto fail;
+}
+av_free(dirname);
+dirname = r_dirname;
+}
+
 av_log(hls, AV_LOG_DEBUG, "deleting old segment %s\n",
   segment->filename);
 path_size =  (hls->use_localtime_mkdir ? 0 : strlen(dirname)) + 
strlen(segment->filename) + 1;
@@ -965,6 +981,7 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls,
 if (!en)
 return AVERROR(ENOMEM);
 
+en->var_stream_idx = vs->var_stream_idx;
 ret = sls_flags_filename_process(s, hls, vs, en, duration, pos, size);
 if (ret < 0) {
 return ret;
@@ -1824,9 +1841,11 @@ static int 
parse_variant_stream_mapstring(AVFormatContext *s)
 while (varstr = av_strtok(p, " \t", &saveptr1)) {
 p = NULL;
 
-if (nb_varstreams < hls->nb_varstreams)
-vs = &(hls->var_streams[nb_varstreams++]);
-else
+if (nb_varstreams < hls->nb_varstreams) {
+vs = &(hls->var_streams[nb_varstreams]);
+vs->var_stream_idx = nb_varstreams;
+nb_varstreams++;
+} else
 return AVERROR(EINVAL);
 
 q = varstr;
@@ -1984,6 +2003,7 @@ static int update_variant_stream_info(AVFormatContext *s) 
{
 if (!hls->var_streams)
 return AVERROR(ENOMEM);
 
+hls->var_streams[0].var_stream_idx = 0;
 hls->var_streams[0].nb_streams = s->nb_streams;
 hls->var_streams[0].streams = av_mallocz(sizeof(AVStream *) *
 hls->var_streams[0].nb_streams);
-- 
2.5.3.windows.1

___
ffmpeg-devel mailing list
ffmpeg-

Re: [FFmpeg-devel] [PATCH] doc/developer: remove merge request method of contributing

[Josh de Kock]

On 2018/04/05 19:17, Lou Logan wrote:

This seems to confuse Github users into thinking that we may accept pull
requests. We do not accept pull requests.

Sending patches to the ffmpeg-devel mailing list is our preferred method
for users to contribute code.

Signed-off-by: Lou Logan 
---
  doc/developer.texi | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 0fc9c3f21c..a0eeefe242 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -30,13 +30,11 @@ consult @url{https://ffmpeg.org/legal.html}.
  
  @chapter Contributing
  
-There are 3 ways by which code gets into FFmpeg.

+There are 2 ways by which code gets into FFmpeg:
  @itemize @bullet
-@item Submitting patches to the main developer mailing list.
+@item Submitting patches to the ffmpeg-devel mailing list.
See @ref{Submitting patches} for details.
  @item Directly committing changes to the main tree.
-@item Committing changes to a git clone, for example on github.com or
-  gitorious.org. And asking us to merge these changes.
  @end itemize
  
  Whichever way, changes should be reviewed by the maintainer of the code




Consider removing 'Directly committing changes to the main tree.' as 
well. I'm not sure how often this is done, but certainly new 
contributors shouldn't be doing this.


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

Re: [FFmpeg-devel] [PATCH] doc/developer: remove merge request method of contributing

[Rostislav Pehlivanov]

On 6 April 2018 at 12:22, Josh de Kock  wrote:

> On 2018/04/05 19:17, Lou Logan wrote:
>
>> This seems to confuse Github users into thinking that we may accept pull
>> requests. We do not accept pull requests.
>>
>> Sending patches to the ffmpeg-devel mailing list is our preferred method
>> for users to contribute code.
>>
>> Signed-off-by: Lou Logan 
>> ---
>>   doc/developer.texi | 6 ++
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index 0fc9c3f21c..a0eeefe242 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -30,13 +30,11 @@ consult @url{https://ffmpeg.org/legal.html}.
>> @chapter Contributing
>>   -There are 3 ways by which code gets into FFmpeg.
>> +There are 2 ways by which code gets into FFmpeg:
>>   @itemize @bullet
>> -@item Submitting patches to the main developer mailing list.
>> +@item Submitting patches to the ffmpeg-devel mailing list.
>> See @ref{Submitting patches} for details.
>>   @item Directly committing changes to the main tree.
>> -@item Committing changes to a git clone, for example on github.com or
>> -  gitorious.org. And asking us to merge these changes.
>>   @end itemize
>> Whichever way, changes should be reviewed by the maintainer of the
>> code
>>
>>
> Consider removing 'Directly committing changes to the main tree.' as well.
> I'm not sure how often this is done, but certainly new contributors
> shouldn't be doing this.
>
> --
> Josh
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


New contributors don't have git access.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[James Almer]

On 4/6/2018 7:25 AM, Alexander Kravchenko wrote:
>>
>> This breaks the testcase described in
>> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
>> one you described in this patch.
>>
>> I get the following spammed repeatedly:
>>
>> [AVHWFramesContext @ 0502d340] Static surface pool size exceeded.
>> [mpeg2video @ 02f8d400] get_buffer() failed
>> [mpeg2video @ 02f8d400] thread_get_buffer() failed
>> [mpeg2video @ 02f8d400] get_buffer() failed (-12 )
>> Error while decoding stream #0:1: Operation not permitted
> 
> Hi, could you please review the following updated patch
> I added queue limit according initial pool size of incoming frame context.
> This solves the problem running this pipeline without -extra_hw_frames 16 
> option, but -extra_hw_frames option can be used to have bigger queue for 
> encoder.

Yes, this solves it, and the output does indeed look good now. Thanks.

I'll leave reviewing this patch to someone more familiar with hw encoding.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] FFmpeg filter for real time captioning.

[ANURAG SINGH IIT BHU]

How to write a ffmpeg-libavfilter filter which outputs a "Hello World
minute:sec" subtitle each second.The filter should produce packets/frames
of subtitles in a AVMEDIA_TYPE_SUBTITLE stream output from the avfilter.The
output from the filter should be passed through the filter chain back into
the application (ffmpeg*.c).


‌
 Sent with Mailtrack

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

Re: [FFmpeg-devel] [PATCH] avformat/rawenc: check stream type

[Gyan Doshi]

On 4/5/2018 12:09 AM, Michael Niedermayer wrote:


This does not work
breaks fate-unknown_layout-ac3

also the tests mayb too strict, there are similar codec_ids like mpeg1/2
or jpeg variants which are all basically the same from a muxers point of view


Revised patch passes FATE. Set looser conditions for mpeg-1/2/4 and jpeg 
muxer.


Regards,
Gyan
From a4ae3eb20af9a4c6e5feb201347b5b044541c59b Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Fri, 6 Apr 2018 20:21:57 +0530
Subject: [PATCH v2] avformat/rawenc: check stream type

Validate codec of stream to be muxed except for data muxer.
---
 libavformat/rawenc.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 809ca23b1a..19028329f7 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -34,12 +34,48 @@ int ff_raw_write_packet(AVFormatContext *s, AVPacket *pkt)
 
 static int force_one_stream(AVFormatContext *s)
 {
+enum AVCodecID id;
+const char *idname;
+
 if (s->nb_streams != 1) {
 av_log(s, AV_LOG_ERROR, "%s files have exactly one stream\n",
s->oformat->name);
 return AVERROR(EINVAL);
 }
+
+if (!strcmp("data", s->oformat->name))
+return 0;
+
+id = s->streams[0]->codecpar->codec_id;
+idname = avcodec_get_name(id);
+
+switch(s->streams[0]->codecpar->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+if (s->oformat->audio_codec != id)
+goto fail;
+break;
+case AVMEDIA_TYPE_VIDEO:
+if (strstr(s->oformat->name, "mpeg") != NULL) {
+if (strstr(idname, "mpeg") == NULL)
+goto fail;
+} else if (strstr(s->oformat->name, "m4v") != NULL) {
+   if (strstr(idname, "mpeg4") == NULL)
+   goto fail;
+} else if (strstr(s->oformat->name, "jpeg") != NULL) {
+   if (strstr(idname, "jpeg") == NULL)
+   goto fail;
+} else if (s->oformat->video_codec != id)
+   goto fail;
+break;
+default:
+goto fail;
+}
+
 return 0;
+
+fail:
+av_log(s, AV_LOG_ERROR, "Stream not of type %s\n", s->oformat->name);
+return AVERROR(EINVAL);
 }
 
 /* Note: Do not forget to add new entries to the Makefile as well. */
-- 
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 3/28/2018 10:42 AM, James Almer wrote:
> On 3/28/2018 6:59 AM, wm4 wrote:
>> On Tue, 27 Mar 2018 23:11:27 -0300
>> James Almer  wrote:
>>
>>> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
>>> index 73b6bd0b14..d06b301fe5 100644
>>> --- a/libavutil/buffer.h
>>> +++ b/libavutil/buffer.h
>>> @@ -284,6 +284,59 @@ void av_buffer_pool_uninit(AVBufferPool **pool);
>>>   */
>>>  AVBufferRef *av_buffer_pool_get(AVBufferPool *pool);
>>>  
>>> +/**
>>> + * @}
>>> + */
>>> +
>>> +/**
>>> + * @defgroup lavu_bufferdynpool AVBufferDynPool
>>> + * @ingroup lavu_data
>>> + *
>>> + * @{
>>> + * AVBufferDynPool is an API for a lock-free thread-safe pool of AVBuffers.
>>> + *
>>> + * Unlike AVBufferPool, AVBufferDynPool allows the user to request buffers
>>> + * of any arbitrary size. It is functionally the same otherwise.
>>> + */
>>> +
>>> +/**
>>> + * The buffer pool. This structure is opaque and not meant to be accessed
>>> + * directly. It is allocated with av_buffer_dyn_pool_init() and freed with
>>> + * av_buffer_dyn_pool_uninit().
>>> + */
>>> +typedef struct AVBufferDynPool AVBufferDynPool;
>>> +
>>> +/**
>>> + * Allocate and initialize a buffer pool.
>>> + *
>>> + * @param alloc a function that will be used to allocate new buffers when 
>>> the
>>> + * pool is empty. May be NULL, then the default allocator will be used
>>> + * (av_buffer_alloc()).
>>> + * @return newly created buffer pool on success, NULL on error.
>>> + */
>>> +AVBufferDynPool *av_buffer_dyn_pool_init(AVBufferRef* (*alloc)(int size));
>>
>> No custom free pool free function like the fixed buffer API? (Not sure if 
>> neded.)
> 
> That's only in the second, more "complex" kind of pool alloc, when you
> need to pass an opaque pointer to both the alloc and free buffer
> functions. It was added afaik for some hwaccel stuff, like vaapi encoder.
> 
> It can be added later if needed, as another init2() for this new API,
> but I'd rather not make it the default and only init function here as it
> wouldn't allow the caller to use the standard signature functions like
> av_buffer_alloc() as callback, forcing them to come up with custom
> wrappers even if they need a simple pool.

If there are no other comments, I'd like to push this soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

[Alexander Kravchenko]

> >> This breaks the testcase described in
> >> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
> >> one you described in this patch.
> >>
> >> I get the following spammed repeatedly:
> >>
> >> [AVHWFramesContext @ 0502d340] Static surface pool size exceeded.
> >> [mpeg2video @ 02f8d400] get_buffer() failed
> >> [mpeg2video @ 02f8d400] thread_get_buffer() failed
> >> [mpeg2video @ 02f8d400] get_buffer() failed (-12 )
> >> Error while decoding stream #0:1: Operation not permitted
> >
> > Hi, could you please review the following updated patch
> > I added queue limit according initial pool size of incoming frame context.
> > This solves the problem running this pipeline without -extra_hw_frames 16 
> > option, but -extra_hw_frames option can be used to
> have bigger queue for encoder.
> 
> Yes, this solves it, and the output does indeed look good now. Thanks.
> 
> I'll leave reviewing this patch to someone more familiar with hw encoding.
Thanks, James.

I think the following approaches could help to solve issues with pool size more 
flexible way
1) communication between decoder and the following frame consumer component 
(filter or encoder) about extra frames requirement in hw frame pool.
2) add function like av_buffer_pool_test(AVBufferPool *pool); which returns 
current status of pool (used/free frames count). 

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

[FFmpeg-devel] [PATCH] avformat/rtpenc_chain: use the proper function to free AVFormatContext

[Vittorio Giovara]

Yes the order of operations is a problem in a generic matrix, but for a
display matrix the order is more or less consolidated in a defacto standard:
check for flip first, then rotation. We have the same pattern in h264 and
hevc decoder for the rotation side data.

You are right that the description of the API does not convey the order
and that it should be better documented, although I don't have a specific
standard to quote (besides what is already mentioned in display.h).

> > The "special cases" are also the most common operations that every player
> > implements so I think it makes sense to have them readily available, with
> > as few calls as possible.
> 
> With what i suggest, not sure i explained it well enough
> there would be a single call to provide a struct or array of 4 scalars
> a 90 degree to the right rotation would for example have a
> {90, 1, 1, 0} and could be checked for by memcmp() or a more specialized
> function that returns a scalar "difference"
> so testing for these common operations should be very simple and compact.
> Testing for another angle of rotation or other transform would be similarly
> simple.


Well the only downside of that is that we are replacing a well-known set of
instructions coded in a 3x3 matrix with a ffmpeg-only 4x1 array of integers.
You would need special code and documentation to parse either the matrix or
the array, so it kinda defies my attempt at simplifying the API: I feel like
having a negative scale factor to represent a flip is as complex as having
euclidean math to compute the rotation angle when the allowed orientations
are just 4.

On the other hand, I'm not strongly advocating for one way of another, if
you could maybe point me to the right direction and share some code on how
you mean the matrix parsing should be carried out I'll try to prepare a
second version of this patch.

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

Re: [FFmpeg-devel] [PATCH] avformat/rtpenc_chain: use the proper function to free AVFormatContext

[Rostislav Pehlivanov]

On 6 April 2018 at 17:59, Vittorio Giovara 
wrote:

> Yes the order of operations is a problem in a generic matrix, but for a
> display matrix the order is more or less consolidated in a defacto
> standard:
> check for flip first, then rotation. We have the same pattern in h264 and
> hevc decoder for the rotation side data.
>
> You are right that the description of the API does not convey the order
> and that it should be better documented, although I don't have a specific
> standard to quote (besides what is already mentioned in display.h).
>
> > > The "special cases" are also the most common operations that every
> player
> > > implements so I think it makes sense to have them readily available,
> with
> > > as few calls as possible.
> >
> > With what i suggest, not sure i explained it well enough
> > there would be a single call to provide a struct or array of 4 scalars
> > a 90 degree to the right rotation would for example have a
> > {90, 1, 1, 0} and could be checked for by memcmp() or a more specialized
> > function that returns a scalar "difference"
> > so testing for these common operations should be very simple and compact.
> > Testing for another angle of rotation or other transform would be
> similarly
> > simple.
>
>
> Well the only downside of that is that we are replacing a well-known set of
> instructions coded in a 3x3 matrix with a ffmpeg-only 4x1 array of
> integers.
> You would need special code and documentation to parse either the matrix or
> the array, so it kinda defies my attempt at simplifying the API: I feel
> like
> having a negative scale factor to represent a flip is as complex as having
> euclidean math to compute the rotation angle when the allowed orientations
> are just 4.
>
> On the other hand, I'm not strongly advocating for one way of another, if
> you could maybe point me to the right direction and share some code on how
> you mean the matrix parsing should be carried out I'll try to prepare a
> second version of this patch.
>
> Vittorio
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I agree, I'd rather have a standard 3x3 matrix exposed than making
something new up.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer: remove merge request method of contributing

[Lou Logan]

On Thu, Apr 5, 2018, at 10:17 AM, Lou Logan wrote:
> This seems to confuse Github users into thinking that we may accept pull
> requests. We do not accept pull requests.
> 
> Sending patches to the ffmpeg-devel mailing list is our preferred method
> for users to contribute code.
> 
> Signed-off-by: Lou Logan 
> ---
>  doc/developer.texi | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/vivo: add support for siren codec

[Compn]

On Wed,  4 Apr 2018 16:09:37 +0200, Paul B Mahol 
wrote:

> +} else {
> +ast->codecpar->codec_id = AV_CODEC_ID_SIREN;
> +ast->codecpar->bits_per_coded_sample = 16;
> +ast->codecpar->block_align = 40;
> +ast->codecpar->bit_rate = 6400;


wow great!

now there is only the other vivo video codec left and then this format
can finally be completed?

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

Re: [FFmpeg-devel] [PATCH 2/3 v2] avformat/matroskadec: factor the prores packet parsing code out

[Michael Niedermayer]

On Thu, Apr 05, 2018 at 12:30:59PM -0300, James Almer wrote:
> Simplifies code in matroska_parse_frame(). This is in preparation for
> the following patch.
> 
> Signed-off-by: James Almer 
> ---
> Not overloading dst this time...
> 
>  libavformat/matroskadec.c | 50 
> +++
>  1 file changed, 38 insertions(+), 12 deletions(-)

seems to work now

thx

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

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/matroskadec: reference the existing data buffer when creating packets

[Michael Niedermayer]

On Thu, Apr 05, 2018 at 12:32:47PM -0300, James Almer wrote:
> Newly allocated data buffers (wavpack, prores, compressed buffers)
> are padded to meet the requirements of AVPacket.
> 

> About 10x speed up in matroska_parse_frame().

thats a nice speedup
patch seems to work fine

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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/3] avcodec: add siren audio decoder

[Compn]

On Wed,  4 Apr 2018 16:09:35 +0200, Paul B Mahol 
wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   8 +
>  libavcodec/siren.c  | 847 
> 
>  5 files changed, 858 insertions(+)

does this also decode msnsiren? or no?
did you use this patch ? 
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-July/127801.html

good work paul!

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

Re: [FFmpeg-devel] Patch for seg fault in swr_convert_internal() -> sum2_float during dithering

[Michael Niedermayer]

On Thu, Apr 05, 2018 at 02:38:03PM +0200, Hendrik Schreiber wrote:
> Hey there,
> 
> I have recently switched to using FFmpeg for conversions of 24bit stereo WAV 
> to 16bit stereo WAV (with dithering).
> 
> For some very large files, I occasionally encountered a segmentation fault in 
> _sum2_float. Unfortunately, I was not able to reproduce the issue in a small 
> test setting, but only in a quite large environment.
> 
> Debugging showed that the issue was caused in function swr_convert_internal() 
> in swresample.c, specifically in line 681
> 
> s->mix_2_1_f(
> conv_src->ch[ch] + off, // out array
> preout->ch[ch] + off,   // in1 array
> s->dither.noise.ch[ch] + s->dither.noise.bps * s->dither.noise_pos + off + 
> len1, // in2 array
> s->native_one,  // coefficients
> 0,  // coefficient index 1
> 0,  // coefficient index 2
> out_count - len1// length
> );
> 
> (https://github.com/FFmpeg/FFmpeg/blob/53688b62ca96ad9a3b0e7d201caca61c79a68648/libswresample/swresample.c#L681)
> 
> where dithering is applied. Here, s->mix_2_1_f() is the same as sum2_float(). 
> The in2 array pointer is too large.
> 
> I was able to log values before one of the crashs and found:
> 
> out_count=682
> len1=672
> (out_count - len1)=10
> off=2688
> s->dither.noise.bps  =4
> s->dither.noise_pos  =130262
> s->dither.noise.count=131072
> s->dither.noise.bps * s->dither.noise_pos + off + len1 = 524408 // in2 start 
> address offset greater than buffer size!!!
> 
> The buffer count has a total size of s->dither.noise.count * 
> s->dither.noise.bps = 524288
> Therefore the start address for the in2 array (3rd argument for 
> mix_2_1_f(...)) is already outside of the buffer.
> 
> I was not able to find a reason for the “+len1” in “s->dither.noise.bps * 
> s->dither.noise_pos + off + len1”. It looks out of place to me. Without it 
> the buffer overrun does not occur.
> 
> “make fate” worked like a charm.
> 
> -hendrik
> 
> tagtraum industries incorporated
> 724 Nash Drive
> Raleigh, NC 27608
> USA
> +1 (919) 809-7797
> http://www.tagtraum.com/
> http://www.beatunes.com/
> 

> From ef79e9286c4b8b694715e978f48abe1601956c0e Mon Sep 17 00:00:00 2001
> From: Hendrik Schreiber 
> Date: Thu, 5 Apr 2018 13:58:37 +0200
> Subject: [PATCH] Fix for seg fault in swr_convert_internal() -> sum2_float
>  during dithering. Removed +len1 in call to s->mix_2_1_f() as I found no
>  logical explanation for it. After removal, problem was gone.
> 
> Signed-off-by: Hendrik Schreiber 
> ---
>  libswresample/swresample.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] [PATCH 2/3 v2] avformat/matroskadec: factor the prores packet parsing code out

[James Almer]

On 4/6/2018 8:29 PM, Michael Niedermayer wrote:
> On Thu, Apr 05, 2018 at 12:30:59PM -0300, James Almer wrote:
>> Simplifies code in matroska_parse_frame(). This is in preparation for
>> the following patch.
>>
>> Signed-off-by: James Almer 
>> ---
>> Not overloading dst this time...
>>
>>  libavformat/matroskadec.c | 50 
>> +++
>>  1 file changed, 38 insertions(+), 12 deletions(-)
> 
> seems to work now
> 
> thx

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

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/matroskadec: reference the existing data buffer when creating packets

[James Almer]

On 4/6/2018 8:30 PM, Michael Niedermayer wrote:
> On Thu, Apr 05, 2018 at 12:32:47PM -0300, James Almer wrote:
>> Newly allocated data buffers (wavpack, prores, compressed buffers)
>> are padded to meet the requirements of AVPacket.
>>
> 
>> About 10x speed up in matroska_parse_frame().
> 
> thats a nice speedup
> patch seems to work fine
> 
> thx

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroskadec: use refcounted buffers in EbmlBin

[James Almer]

On 4/4/2018 8:43 PM, James Almer wrote:
> Data in EbmlBin objects is never changed after being read from the
> input file (save for two specific cases with encoded CodePrivate), so
> using AVBufferRef we can prevent unnecessary copy of data by instead
> creating new references to said constant data.
> 
> Signed-off-by: James Almer 
> ---
> The CodecPrivate parts are untested, as there's no FATE coverage of them.
> 
>  libavformat/matroskadec.c | 44 +++-
>  1 file changed, 31 insertions(+), 13 deletions(-)

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

Re: [FFmpeg-devel] lavfi/silencedetect v3

[James Almer]

On 4/1/2018 8:26 AM, Paul B Mahol wrote:
> On 3/5/18, Gaullier Nicolas  wrote:
>> Hello,
>> I have not received any comment yet on my patchset v3 ("add mono mode" new
>> feature + 4 fixes including a ticket), does it look good to you, could it be
>> committed ?
>>
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225494.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225495.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225496.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225497.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225498.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225499.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225500.html
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225501.html
>>
>> Thanks,
>> Nicolas Gaullier
> 
> I applied all except last two.

This broke the fate in a couple targets, like msvc 2017 and kfreebsd.
Tests like this shouldn't try to print float values...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] Add Sega FILM muxer

[Misty De Meo]

On Thu, Apr 5, 2018 at 2:06 PM, Josh de Kock  wrote:
> Thanks, pushed. I also clarified with wm4 on IRC that while he was against
> it he wasn't blocking the muxer if someone else pushes it.

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