Re: [FFmpeg-devel] [PATCH v2 1/1] avformat/hlsenc: closed caption tags in the master playlist

[Dixit, Vishwanath]

On 1/14/18 8:38 PM, Liu Steven wrote:
>
>> 在 2018年1月9日，下午5:54，Dixit, Vishwanath  写道：
>>
>>
>>
>> On 1/9/18 3:05 PM, 刘歧 wrote:
>>
>
>
> I cannot sure use -cc_stream_map_ccgroup option is ok, because the 
> ccgroup string is not standard, maybe it can be defined bu user.
> Maybe two ways:
> 1. use -cc_stream_map_ccgroup ? this way is defined the name by ffmpeg, 
> cannot modify.
> 2. parse the closed captions group string by KeyValue way? maybe this is 
> better.

 Actually, these requirements have been already handled. The parsing is 
 happening based on key value pairs. The keys are ‘ccgroup’, ‘instreamid’, 
 ‘language’. The values for these keys can be set after ‘:’ as given the 
 examples in the patch. 
 I am assuming you are trying to set ccgroup name as closecgroup. In that 
 case, please modify the command as below. Because, the string ‘ccgroup’ is 
 a key value, whatever string that comes after ‘ccgroup:’ is the cc group 
 name.  
 ./ffmpeg -re -f lavfi -i color=red  -g 25  -b:v 1000k -b:a 64k -a53cc 1 -f 
 hls  -cc_stream_map "ccgroup:closecgroup,instreamid:CC1,language:en"   
 -master_pl_name master.m3u8  live/out.m3u8

 To clarify further, consider user wants to set cc group name as 
 ‘mycaptions’, instream id as ‘SERVICE60’ language as Spanish, in that 
 case, the map string would be
 -cc_stream_map "ccgroup:mycaptions,instreamid:SERVICE60,language:sp”  
>>> I understand and i got the point, 
>>> just one question, do you want force the user use ffmpeg must input a 
>>> string “ccgroup” ? if yes, maybe don’t let the user input it use string, 
>>> maybe use -cc_stream_map_ccgroup is better, What do you think about it?
>> Are you suggesting to change the string from ‘–cc_stream_map’ to 
>> ‘-cc_stream_map_ccgroup’ and remove the ‘ccgroup’ key from the value string? 
>> Could you please clarify?
>>
>> Apart from this, I would like to highlight some advanced use cases where 
>> current implementation will be more meaningful. It is possible that that 
>> there could be multiple instream ids under the same closed caption group or 
>> there can be different closed captions groups. Example:
>> -cc_stream_map "ccgroup:group1,instreamid:CC1,language:en 
>> ccgroup:group1,instreamid:CC2,language:sp”
>> -cc_stream_map "ccgroup:eng_group,instreamid:CC1,language:en 
>> ccgroup:span_group,instreamid:CC1,language:sp”
>>
>> In these cases, the same ccgroup is mentioned in the –var_stream_map string 
>> as well.
>> -var_stream_map "v:0,a:0,ccgroup:group1 v:1,a:1,ccgroup:group1" or
>> -var_stream_map "v:0,a:0,ccgroup:eng_group v:1,a:1,ccgroup:span_group"
>>
>> Here, ‘ccgroup’ is a common key between –cc_stream_map and –var_stream_map. 
>> So, it is better to keep this key so that it will more readable and easily 
>> configurable for the user.
>
> Hi Dixit,
>
> I cannot found “ccgroup” string in rfc8216, or dose it in some other 
> specifications? Or user MUST use “ccgroup” in the var_stream_map?
Hi Steven,

The string “ccgroup” is defined by me in both ‘var_stream_map’ and 
‘cc_stream_map’ just for convenience. In the list of key value attribute pairs 
that I have defined, “ccgroup” is a key to which user can set a GROUP-ID (as 
defined in section 4.3.4.1.  EXT-X-MEDIA of the RFC) for the closed captions 
group. This is a mandatory attribute in ‘cc_stream_map’ and optional attribute 
in ‘var_stream_map’.

Regards,
Vishwanath
>>
>>>
>>>
>>> Thanks
>>>
>>> Steven
>>>



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

Re: [FFmpeg-devel] [PATCH 1/5] lavfi: VAAPI VPP common infrastructure.

[Jun Zhao]

On 2018/1/15 6:16, Mark Thompson wrote:
> Whole series generally looks good, specific comments follow for each patch.
>
> Thanks,
>
> - Mark
Thanks the great review for whole series patches, Mark, will follow the
comments , Thanks.
>
>
> On 08/01/18 08:33, Jun Zhao wrote:
>> From 17278f448133826593941ac6b105a4e81cc8b255 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Mon, 8 Jan 2018 15:56:43 +0800
>> Subject: [PATCH 1/5] lavfi: VAAPI VPP common infrastructure.
>>
>> Re-work the VA-API common infrastructure.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavfilter/vaapi_vpp.c | 366 
>> 
>>  libavfilter/vaapi_vpp.h |  75 ++
>>  2 files changed, 441 insertions(+)
>>  create mode 100644 libavfilter/vaapi_vpp.c
>>  create mode 100644 libavfilter/vaapi_vpp.h
>>
>> diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
>> new file mode 100644
>> index 00..326a716990
>> --- /dev/null
>> +++ b/libavfilter/vaapi_vpp.c
>> @@ -0,0 +1,366 @@
>> +/*
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +#include 
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/hwcontext.h"
>> +#include "libavutil/hwcontext_vaapi.h"
>> +
>> +#include "avfilter.h"
>> +#include "formats.h"
>> +#include "vaapi_vpp.h"
>> +
>> +#include "libavutil/pixdesc.h"
> Put libavutil headers before libavfilter ones.
>
>> +
>> +int vaapi_vpp_query_formats(AVFilterContext *avctx)
>> +{
>> +enum AVPixelFormat pix_fmts[] = {
>> +AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
>> +};
>> +int err;
>> +
>> +if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
>> +  >inputs[0]->out_formats)) < 0)
>> +return err;
>> +if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
>> +  >outputs[0]->in_formats)) < 0)
>> +return err;
>> +
>> +return 0;
>> +}
>> +
>> +int vaapi_vpp_pipeline_uninit(VAAPIVPPContext *ctx)
>> +{
>> +int i;
>> +for (i = 0; i < ctx->nb_filter_buffers; i++) {
>> +if (ctx->filter_buffers[i] != VA_INVALID_ID) {
>> +vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffers[i]);
>> +ctx->filter_buffers[i] = VA_INVALID_ID;
>> +}
>> +}
>> +ctx->nb_filter_buffers = 0;
>> +
>> +if (ctx->va_context != VA_INVALID_ID) {
>> +vaDestroyContext(ctx->hwctx->display, ctx->va_context);
>> +ctx->va_context = VA_INVALID_ID;
>> +}
>> +
>> +if (ctx->va_config != VA_INVALID_ID) {
>> +vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
>> +ctx->va_config = VA_INVALID_ID;
>> +}
>> +
>> +av_buffer_unref(>output_frames_ref);
>> +av_buffer_unref(>device_ref);
>> +ctx->hwctx = 0;
> NULL, please.
>
>> +
>> +return 0;
>> +}
>> +
>> +int vaapi_vpp_config_input(AVFilterLink *inlink, VAAPIVPPContext *ctx)
>> +{
>> +AVFilterContext *avctx = inlink->dst;
>> +
>> +if (ctx->pipeline_uninit)
>> +ctx->pipeline_uninit(avctx);
> This function seems to return an error code, should it fail in that case?
>
>> +
>> +if (!inlink->hw_frames_ctx) {
>> +av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
>> +   "required to associate the processing device.\n");
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
> Can fail.
>
>> +ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
>> +
>> +return 0;
>> +}
>> +
>> +int vaapi_vpp_config_output(AVFilterLink *outlink, VAAPIVPPContext *ctx)
>> +{
>> +AVFilterContext *avctx = outlink->src;
>> +AVVAAPIHWConfig *hwconfig = NULL;
>> +AVHWFramesConstraints *constraints = NULL;
>> +AVVAAPIFramesContext *va_frames;
>> +VAStatus vas;
>> +int err, i;
>> +
>> +if (ctx->pipeline_uninit)
>> +ctx->pipeline_uninit(avctx);
> As above, should this fail?
>
>> +
>> +av_assert0(ctx->input_frames);
>> +ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
> Can fail.
>
>> +ctx->hwctx = ((AVHWDeviceContext*)ctx->device_ref->data)->hwctx;
>> +
>> +

[FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol

[Nablet Developer]

protocol requires libsrt (https://github.com/Haivision/srt) to be
installed

Signed-off-by: Nablet Developer 
---
 configure   |   9 +
 doc/protocols.texi  | 116 +
 libavformat/Makefile|   1 +
 libavformat/opensrt.c   | 622 
 libavformat/protocols.c |   1 +
 5 files changed, 749 insertions(+)
 create mode 100644 libavformat/opensrt.c

diff --git a/configure b/configure
index 5d53362..8b925a8 100755
--- a/configure
+++ b/configure
@@ -294,6 +294,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls or libtls is not used [no]
+  --enable-opensrt enable Haivision Open SRT protocol [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1641,6 +1642,7 @@ EXTERNAL_LIBRARY_LIST="
 mediacodec
 openal
 opengl
+opensrt
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -3148,6 +3150,8 @@ libssh_protocol_deps="libssh"
 libtls_conflict="openssl gnutls"
 mmsh_protocol_select="http_protocol"
 mmst_protocol_select="network"
+opensrt_protocol_select="network"
+opensrt_protocol_deps="opensrt"
 rtmp_protocol_conflict="librtmp_protocol"
 rtmp_protocol_select="tcp_protocol"
 rtmp_protocol_suggest="zlib"
@@ -5983,6 +5987,7 @@ enabled omx   && require_header OMX_Core.h
 enabled omx_rpi   && { check_header OMX_Core.h ||
{ ! enabled cross_compile && add_cflags 
-isystem/opt/vc/include/IL && check_header OMX_Core.h ; } ||
die "ERROR: OpenMAX IL headers not found"; } && 
enable omx
+enabled opensrt   && require_pkg_config libsrt "srt >= 1.2.0" 
srt/srt.h srt_socket
 enabled openssl   && { check_pkg_config openssl openssl openssl/ssl.h 
OPENSSL_init_ssl ||
check_pkg_config openssl openssl openssl/ssl.h 
SSL_library_init ||
check_lib openssl openssl/ssl.h 
SSL_library_init -lssl -lcrypto ||
@@ -6033,6 +6038,10 @@ if enabled decklink; then
 esac
 fi
 
+if enabled opensrt; then
+opensrt_protocol_extralibs="$opensrt_protocol_extralibs -lsrt"
+fi
+
 enabled securetransport &&
 check_func SecIdentityCreate "-Wl,-framework,CoreFoundation 
-Wl,-framework,Security" &&
 check_lib securetransport "Security/SecureTransport.h Security/Security.h" 
"SSLCreateContext" "-Wl,-framework,CoreFoundation -Wl,-framework,Security" ||
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 98deb73..a923749 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -755,6 +755,122 @@ Set the workgroup used for making connections. By default 
workgroup is not speci
 
 For more information see: @url{http://www.samba.org/}.
 
+@section srt
+
+Haivision Secure Reliable Transport Protocol via libsrt.
+
+The required syntax for a SRT url is:
+@example
+srt://@var{hostname}:@var{port}[?@var{options}]
+@end example
+
+@var{options} contains a list of &-separated options of the form
+@var{key}=@var{val}.
+
+This protocol accepts the following options.
+
+@table @option
+@item conntimeo=@var{milliseconds}
+Connection timeout, in milliseconds. SRT cannot connect for RTT > 1500 msec
+(2 handshake exchanges) with the default connect timeout of 3 seconds. This 
option
+applies to the caller and rendezvous connection modes. The connect timeout is 
10 times
+the value set for the rendezvous mode (which can be used as a workaround for 
this
+connection problem with earlier versions).
+
+@item fc=@var{bytes}
+Flight Flag Size (Window Size), in bytes. FC is actually an internal parameter 
and
+you should set it to not less than @option{recv_buffer_size} and @option{mss}.
+The default value is relatively large, therefore unless you set a very large
+receiver buffer, you do not need to change this option. Default value is 25600.
+
+@item inputbw=@var{bytes/seconds}
+Sender nominal input rate, in bytes per seconds. Used along with 
@option{oheadbw},
+when @option{maxbw} is set to relative (0), to calculate maximum sending rate 
when
+recovery packets are sent along with main media stream:
+@option{inputbw} * (100 + @option{oheadbw}) / 100
+if @option{inputbw} is not set while @option{maxbw} is set to relative (0), 
the actual
+ctual input rate is evaluated inside the library. Default value is 0.
+
+@item iptos=@var{tos}
+IP Type of Service. Applies to sender only. Default value is 0xB8.
+
+@item ipttl=@var{ttl}
+IP Time To Live. Applies to sender only. Default value is 64.
+
+@item listen_timeout=@var{milliseconds}
+Set listen timeout, expressed in milliseconds.
+
+@item maxbw=@var{bytes/seconds}
+Maximum sending bandwidth, in bytes per seconds.
+-1 infinite (CSRTCC limit is 

Re: [FFmpeg-devel] [PATCH] avformat/opensrt: add Haivision Open SRT protocol

[Nablet Developer]

On 1/13/2018 4:40 AM, Michael Niedermayer wrote:

On Wed, Dec 13, 2017 at 03:31:04PM +0700, Nablet Developer wrote:
[...]
this is commented out ?


yes, looks like leftover, thanks for pointing. will send updated patch soon.

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

[FFmpeg-devel] [PATCH] avcodec/snowdec: Fix integer overflow before htaps check

[Michael Niedermayer]

Fixes: runtime error: signed integer overflow: -1094995529 * 2 cannot be 
represented in type 'int'
Fixes: 4828/clusterfuzz-testcase-minimized-5100849937252352

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/snowdec.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/snowdec.c b/libavcodec/snowdec.c
index a9bdb8da5e..0146a2a4c9 100644
--- a/libavcodec/snowdec.c
+++ b/libavcodec/snowdec.c
@@ -363,9 +363,10 @@ static int decode_header(SnowContext *s){
 int htaps, i, sum=0;
 Plane *p= >plane[plane_index];
 p->diag_mc= get_rac(>c, s->header_state);
-htaps= get_symbol(>c, s->header_state, 0)*2 + 2;
-if((unsigned)htaps >= HTAPS_MAX || htaps==0)
+htaps= get_symbol(>c, s->header_state, 0);
+if((unsigned)htaps >= HTAPS_MAX/2 - 1)
 return AVERROR_INVALIDDATA;
+htaps = htaps*2 + 2;
 p->htaps= htaps;
 for(i= htaps/2; i; i--){
 p->hcoeff[i]= get_symbol(>c, s->header_state, 0) * 
(1-2*(i&1));
-- 
2.15.1

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

Re: [FFmpeg-devel] GSoC 2018

[Michael Niedermayer]

On Sun, Jan 14, 2018 at 09:28:58PM -0200, Pedro Arthur wrote:
> 2018-01-13 23:32 GMT-02:00 Michael Niedermayer :
> 
> > On Fri, Jan 12, 2018 at 11:56:07AM -0200, Pedro Arthur wrote:
> > > 2018-01-12 0:06 GMT-02:00 Michael Niedermayer :
> > >
> > > > if pedro is up to date on this stuff, then maybe he wants to mentor
> > this
> > > >
> > > > either way, links to relevant research, tests, literature are welcome
> > > >
> > > > I can mentor this.
> > >
> > > One of the first NN based method was [1] which has a very simple network
> > > layout, only 3 convolution layers. More complex methods can be found in
> > > [2], [3], [4].
> >
> > > The important question is where we are going to perfom only inference,
> > > using a pre-trained net or we will also train the net. The first is more
> > > easy to do but we don't exploit the content knowledge we have, the second
> > > is more powerful as it adapts to the content but requires training which
> > > may be  expensive, in this case it would be best to use some library to
> > > perform the training.
> >
> > Iam sure our users would want to train the filter in some cases.
> > use cases for different types of content anime vs movies with actors for
> > example likely benefit from seperate training sets.
> >
> > The training code could be seperate from the filter
> >
> > Also another issue is the space requirements that result out of the
> > training.
> > This was an issue with NNEDI previously IIRC
> >
> >
> > >
> > > There are also method which does not use NN like A+ [5] and ANR.
> >
> > How do these perform in relation to the latest NN based solutions ?
> >
> Comparing psnr the first NN method (SRCNN) achieves the same quality but
> evaluation is faster than A+, or better quality at same speed.
> 
> Newer NN methods ([3], [4]) uses "perceptual loss" functions which degrades
> the psnr but the images are much more sharp and appear to have better
> quality than those that maximize psnr.

it seems PSNR does not work as a way to compare these filters
though its possible that with video instead of still images there could
be instabilities in the details created by the filters.


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

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


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

Re: [FFmpeg-devel] [PATCH 6/7] avformat: migrate to AVFormatContext->url

[Michael Niedermayer]

On Sun, Jan 14, 2018 at 11:34:03PM +0100, Marton Balint wrote:
> 
> On Sun, 14 Jan 2018, Michael Niedermayer wrote:
> 
> >On Sat, Jan 06, 2018 at 09:50:31PM +0100, Marton Balint wrote:
> >>Signed-off-by: Marton Balint 
> >>---
> >> libavformat/concatdec.c  |  4 ++--
> >> libavformat/dashenc.c| 16 
> >> libavformat/fifo.c   |  8 
> >> libavformat/flvenc.c |  4 ++--
> >> libavformat/gxfenc.c |  4 ++--
> >> libavformat/hdsenc.c | 24 
> >> libavformat/img2dec.c|  4 ++--
> >> libavformat/img2enc.c|  4 ++--
> >> libavformat/matroskadec.c|  4 ++--
> >> libavformat/mlvdec.c |  4 ++--
> >> libavformat/mov.c|  2 +-
> >> libavformat/movenc.c | 10 +-
> >> libavformat/mpeg.c   |  4 ++--
> >> libavformat/mpegtsenc.c  |  2 +-
> >> libavformat/options.c|  2 +-
> >> libavformat/rtsp.c   | 18 --
> >> libavformat/rtspdec.c|  4 ++--
> >> libavformat/rtspenc.c|  4 +++-
> >> libavformat/sapdec.c |  2 +-
> >> libavformat/sapenc.c | 10 --
> >> libavformat/sdp.c|  4 ++--
> >> libavformat/segment.c| 36 +---
> >> libavformat/smoothstreamingenc.c | 12 ++--
> >> libavformat/tee.c|  4 ++--
> >> libavformat/utils.c  |  2 +-
> >> libavformat/webm_chunk.c | 10 +-
> >> 26 files changed, 111 insertions(+), 91 deletions(-)
> >>
> >>diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> >>index bd5174ada2..178fac86cb 100644
> >>--- a/libavformat/concatdec.c
> >>+++ b/libavformat/concatdec.c
> >>@@ -126,10 +126,10 @@ static int add_file(AVFormatContext *avf, char 
> >>*filename, ConcatFile **rfile,
> >> url = filename;
> >> filename = NULL;
> >> } else {
> >>-url_len = strlen(avf->filename) + strlen(filename) + 16;
> >>+url_len = strlen(avf->url) + strlen(filename) + 16;
> >> if (!(url = av_malloc(url_len)))
> >> FAIL(AVERROR(ENOMEM));
> >>-ff_make_absolute_url(url, url_len, avf->filename, filename);
> >>+ff_make_absolute_url(url, url_len, avf->url, filename);
> >> av_freep();
> >> }
> >>
> >>diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> >>index 3345b89118..59c55cc8b7 100644
> >>--- a/libavformat/dashenc.c
> >>+++ b/libavformat/dashenc.c
> >>@@ -685,7 +685,7 @@ static int write_manifest(AVFormatContext *s, int final)
> >> AVIOContext *out;
> >> char temp_filename[1024];
> >> int ret, i;
> >>-const char *proto = avio_find_protocol_name(s->filename);
> >>+const char *proto = avio_find_protocol_name(s->url);
> >> int use_rename = proto && !strcmp(proto, "file");
> >> static unsigned int warned_non_file = 0;
> >> AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
> >>@@ -694,7 +694,7 @@ static int write_manifest(AVFormatContext *s, int final)
> >> if (!use_rename && !warned_non_file++)
> >> av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, 
> >> this may lead to races and temporary partial files\n");
> >>
> >>-snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
> >>"%s", s->filename);
> >>+snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
> >>"%s", s->url);
> >
> >could be truncated, the same applies to other cases
> 
> We already did silent truncations in the past, so I think this is not
> worse than before.
> 
> Fixing the fixed length buffers all around the codebase is a lot of work and
> it is easy to make mistakes. So these can be fixed later by the relevant
> maintainers, or this can be a candiate for a janitor task.

iam fine if its fixed in seperate commits or by others but someone should fix
these.


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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

Re: [FFmpeg-devel] GSoC 2018

[Pedro Arthur]

2018-01-13 23:32 GMT-02:00 Michael Niedermayer :

> On Fri, Jan 12, 2018 at 11:56:07AM -0200, Pedro Arthur wrote:
> > 2018-01-12 0:06 GMT-02:00 Michael Niedermayer :
> >
> > > if pedro is up to date on this stuff, then maybe he wants to mentor
> this
> > >
> > > either way, links to relevant research, tests, literature are welcome
> > >
> > > I can mentor this.
> >
> > One of the first NN based method was [1] which has a very simple network
> > layout, only 3 convolution layers. More complex methods can be found in
> > [2], [3], [4].
>
> > The important question is where we are going to perfom only inference,
> > using a pre-trained net or we will also train the net. The first is more
> > easy to do but we don't exploit the content knowledge we have, the second
> > is more powerful as it adapts to the content but requires training which
> > may be  expensive, in this case it would be best to use some library to
> > perform the training.
>
> Iam sure our users would want to train the filter in some cases.
> use cases for different types of content anime vs movies with actors for
> example likely benefit from seperate training sets.
>
> The training code could be seperate from the filter
>
> Also another issue is the space requirements that result out of the
> training.
> This was an issue with NNEDI previously IIRC
>
>
> >
> > There are also method which does not use NN like A+ [5] and ANR.
>
> How do these perform in relation to the latest NN based solutions ?
>
Comparing psnr the first NN method (SRCNN) achieves the same quality but
evaluation is faster than A+, or better quality at same speed.

Newer NN methods ([3], [4]) uses "perceptual loss" functions which degrades
the psnr but the images are much more sharp and appear to have better
quality than those that maximize psnr.


> Also i think its a great project, you should definitly mentor this if it
> interrests you
>
>
> >
> > [1] - https://arxiv.org/abs/1501.00092
> > [2] - https://arxiv.org/abs/1609.05158
> > [3] - https://arxiv.org/abs/1603.08155
> > [4] - https://arxiv.org/abs/1609.04802
> > [5] -
> > http://www.vision.ee.ethz.ch/~timofter/publications/Timofte-
> ACCV-2014.pdf
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> --
> 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.
>
> ___
> 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 2/3] Add muxer/demuxer for raw codec2 and .c2 files

[Carl Eugen Hoyos]

2017-12-23 23:15 GMT+01:00 Tomas Härdin :

> +//check for 0xC0DEC2, return non-zero if it doesn't match
> +static int check_magic(uint8_t *ptr) {

> +return memcmp(ptr, avpriv_codec2_magic, 3);

AV_RB24(), or do I miss something?

> +static int codec2_probe(AVProbeData *p)
> +{
> +int score;
> +
> +//must be at least 7 bytes and start wih 0xC0DEC2

> +if (p->buf_size < AVPRIV_CODEC2_HEADER_SIZE ||

This check is unneeded.

> check_magic(p->buf)) {
+return 0;
+}
+
+//no .c2 files prior to 0.8

+if (p->buf[3] == 0 && p->buf[4] < 8) {

You chose to define the versions, please use the defines here.

+return 0;
+}
+
+//give a poor score if major version doesn't match
+//this allows such files to be detected at least, even if we
can't do much with them
+if (p->buf[3] != EXPECTED_CODEC2_MAJOR_VERSION) {
+return AVPROBE_SCORE_MAX/10;
+}

That may be ok.

+//if the minor version is known, no unknown mode is used and no
flags are set then -> max score,
+//else penalize 20% for each byte outside of expectations
+//this way if only the first four bytes are OK then we're
slightly less than AVPROBE_SCORE_MAX/2
+//cap score at max-1 unless file extension is .c2
+score = AVPROBE_SCORE_MAX;

+if (!av_match_ext(p->filename, "c2"))   score -= 1;

We don't do this for any other demuxer, if this makes sense, it should
be done in general code, not for a specific demuxer imo.

+if (p->buf[4] >  EXPECTED_CODEC2_MINOR_VERSION) score -=
AVPROBE_SCORE_MAX/5;
+if (p->buf[5] >  AVPRIV_CODEC2_MODE_MAX)score -=
AVPROBE_SCORE_MAX/5;
+if (p->buf[6] != 0) score -=
AVPROBE_SCORE_MAX/5;
+return score;

Imo, this is too complicated:
If the first 32bit are correct, return MAX/2, for 24bit, return less

Returning MAX for less than 64bit seems wrong to me.

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

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.

[Carl Eugen Hoyos]

2018-01-15 0:14 GMT+01:00 Mark Thompson :
> On 14/01/18 22:59, Carl Eugen Hoyos wrote:
>>> On 08/01/18 08:35, Jun Zhao wrote:
>>
 +VAStatus vas;
>>
 +av_log(avctx, AV_LOG_ERROR, "Failed to Query procamp "
 +   "query caps: %d (%s).\n", vas, vaErrorStr(vas));
>>
>> Is "%d" what it's supposed to be? Why is VAStatus needed then?
>
> Yes: .

Ok, I expected this.
But my question was actually:
If there is a typedef for a return value that you may be interested
in printing, shouldn't there be a define that is the correct format?

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

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.

[Mark Thompson]

On 14/01/18 22:59, Carl Eugen Hoyos wrote:
>> On 08/01/18 08:35, Jun Zhao wrote:
> 
>>> +VAStatus vas;
> 
>>> +av_log(avctx, AV_LOG_ERROR, "Failed to Query procamp "
>>> +   "query caps: %d (%s).\n", vas, vaErrorStr(vas));
> 
> Is "%d" what it's supposed to be? Why is VAStatus needed then?

Yes: .

I guess VAStatus is there to suggest to the user to keep different namespaces 
of error codes apart?  Since the types are the same the compiler unfortunately 
doesn't actually help to check it, though.

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

Re: [FFmpeg-devel] [PATCH 5/5] lavfi: add misc(denoise/sharpness) VPP video filter.

[Mark Thompson]

On 08/01/18 08:35, Jun Zhao wrote:
>> From 5be7c9c55e1ad092223a13f465da3b1a2f1d01b3 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 8 Jan 2018 16:19:17 +0800
> Subject: [PATCH 5/5] lavfi: add misc(denoise/sharpness) VPP video filter.
> 
> add misc(denoise/sharpness) VPP video filter.
> 
>  Signed-off-by: Yun Zhou 
>  Signed-off-by: Jun Zhao 
> ---
>  configure   |   1 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/vf_misc_vaapi.c | 328 
> 
>  4 files changed, 331 insertions(+)
>  create mode 100644 libavfilter/vf_misc_vaapi.c

git says:

Applying: lavfi: add misc(denoise/sharpness) VPP video filter.
.git/rebase-apply/patch:378: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

> 
> diff --git a/configure b/configure
> index 366a67d327..3b8743db4d 100755
> --- a/configure
> +++ b/configure
> @@ -3227,6 +3227,7 @@ kerndeint_filter_deps="gpl"
>  ladspa_filter_deps="ladspa libdl"
>  lv2_filter_deps="lv2"
>  mcdeint_filter_deps="avcodec gpl"
> +misc_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
>  movie_filter_deps="avcodec avformat"
>  mpdecimate_filter_deps="gpl"
>  mpdecimate_filter_select="pixelutils"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 43d0dd36e6..970597b706 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -247,6 +247,7 @@ OBJS-$(CONFIG_METADATA_FILTER)   += 
> f_metadata.o
>  OBJS-$(CONFIG_MIDEQUALIZER_FILTER)   += vf_midequalizer.o framesync.o
>  OBJS-$(CONFIG_MINTERPOLATE_FILTER)   += vf_minterpolate.o 
> motion_estimation.o
>  OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o
> +OBJS-$(CONFIG_MISC_VAAPI_FILTER) += vf_misc_vaapi.o vaapi_vpp.o

's' < 'x'

>  OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
>  OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
>  OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 63550628e5..e5b713ea08 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -257,6 +257,7 @@ static void register_all(void)
>  REGISTER_FILTER(MIDEQUALIZER,   midequalizer,   vf);
>  REGISTER_FILTER(MINTERPOLATE,   minterpolate,   vf);
>  REGISTER_FILTER(MIX,mix,vf);
> +REGISTER_FILTER(MISC_VAAPI, misc_vaapi, vf);
>  REGISTER_FILTER(MPDECIMATE, mpdecimate, vf);
>  REGISTER_FILTER(NEGATE, negate, vf);
>  REGISTER_FILTER(NLMEANS,nlmeans,vf);
> diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
> new file mode 100644
> index 00..f6ef764b09
> --- /dev/null
> +++ b/libavfilter/vf_misc_vaapi.c
> @@ -0,0 +1,328 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/hwcontext_vaapi.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "vaapi_vpp.h"
> +
> +typedef struct MiscVAAPIContext {
> +const AVClass *class;
> +
> +VAAPIVPPContext   *vpp_ctx;
> +
> +VAProcFilterCap denoise_caps;
> +int denoise; // enable denoise algo. level is the optional
> + // value from the interval [-1, 100], -1 means 
> disabled
> +
> +VAProcFilterCap sharpness_caps;
> +int sharpness;   // enable sharpness. level is the optional value
> + // from the interval [-1, 100], -1 means disabled
> +int num_filter_bufs;
> +VABufferID filter_bufs[VAProcFilterCount];
> +} MiscVAAPIContext;
> +
> +static int misc_vaapi_query_formats(AVFilterContext *avctx)
> +{
> +return vaapi_vpp_query_formats(avctx);
> +}
> +
> +static int misc_vaapi_pipeline_uninit(AVFilterContext *avctx)
> +{
> +MiscVAAPIContext *ctx =  avctx->priv;
> +VAAPIVPPContext *vpp_ctx =  ctx->vpp_ctx;

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_framerate: add SIMD functions for frame blending

[Marton Balint]

On Sun, 14 Jan 2018, Henrik Gramner wrote:


On Sat, Jan 13, 2018 at 10:57 PM, Marton Balint  wrote:

+.loop:
+movum0, [src1q + xq]
+movum1, [src2q + xq]
+punpckl%1%2 m5, m0, m2 ; 0e0f0g0h
+punpckh%1%2 m0, m2 ; 0a0b0c0d
+punpckl%1%2 m6, m1, m2 ; 0E0F0G0H
+punpckh%1%2 m1, m2 ; 0A0B0C0D
+pmull%2 m0, m3
+pmull%2 m5, m3
+pmull%2 m1, m4
+pmull%2 m6, m4
+padd%2  m0, m7
+padd%2  m5, m7
+padd%2  m0, m1
+padd%2  m5, m6


pmaddubsw should work here for the 8-bit case. pmaddwd might work for
the 16-bit case depending on how many bits are actually used.



As far as I see, I have to make the blending factors 7-bit (15-bit) in 
order for this to work because pmadd* functions are working on signed 
integers. Losing 1 bit of precision of the blending factors is 
probably not a problem for the framerate filter.


So my loop would look like this:

.loop:
movum0, [src1q + xq]
movum1, [src2q + xq]
SBUTTERFLY %1%2, 0, 1, 5; aAbBcCdD
; eEfFgGhH
pmadd%3 m0, m3
pmadd%3 m1, m3

padd%2  m0, m7
padd%2  m1, m7
psrl%2  m0, %4  ; 0A0B0C0D
psrl%2  m1, %4  ; 0E0F0G0H

packus%2%1  m0, m1  ; ABCDEFGH
movu   [dstq + xq], m0
add xq, mmsize
jl .loop

Is this what you had in mind?


+pinsrwxm3, r8m, 0   ; factor1
+pinsrwxm4, r9m, 0   ; factor2
+pinsrwxm7, r10m, 0  ; half
+SPLATW m3, xm3
+SPLATW m4, xm4
+SPLATW m7, xm7


vpbroadcast* from memory on avx2, otherwise movd instead of pxor+pinsrw.


+pxor   m3, m3
+pxor   m4, m4
+pxor   m7, m7
+pinsrwxm3, r8m, 0   ; factor1
+pinsrwxm4, r9m, 0   ; factor2
+pinsrwxm7, r10m, 0  ; half
+XSPLATD   3
+XSPLATD   4
+XSPLATD   7


Ditto.


+neg word r11m   ; shift = -shift
+add word r11m, 16   ; shift += 16
+pxor   m2, m2
+pinsrwxm2, r11m, 0  ; 16 - shift
+pslld  m3, xm2
+pslld  m4, xm2
+pslld  m7, xm2


You probably want to use a temporary register instead of doing slow
load-modify-store instructions.


Ok, I will rework these, although these parts are only the initialization 
code, so I guess these are not performance critical.


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

Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.

[Dmytro Humeniuk]

Hi
> On 14 Jan 2018, at 04:04, Michael Niedermayer  wrote:
> 
> On Sat, Jan 13, 2018 at 11:59:59PM +0100, Dmytro Humeniuk wrote:
>> Hi,
>>> On 12 Jan 2018, at 00:20, Dmitry Gumenyuk  wrote:
>>> --
>>> Best regards,
>>> Dmytro
>>> 
 On 11 Jan 2018, at 23:57, Paul B Mahol  wrote:
 
> On 1/11/18, Dmitry Gumenyuk  wrote:
> 
>>> On 11 Jan 2018, at 23:02, Paul B Mahol  wrote:
>>> 
>>> On 1/11/18, Dmitry Gumenyuk  wrote:
>>> 
> On 11 Jan 2018, at 22:41, Paul B Mahol  wrote:
> 
> On 1/11/18, Dmitry Gumenyuk  wrote:
> Hello
> 
> 2018-01-10 11:33 GMT+01:00 Moritz Barsnick :
>>> On Wed, Jan 10, 2018 at 08:58:05 +0100, dmitry.gumen...@gmail.com
>>> wrote:
>>> 
>>> +@table @option
>>> +@item d
>>> +Dimensions @code{WxH}.
>>> +@code{W} - number of data values in json, values will be scaled
>>> according to @code{H}.
>>> +The default value is @var{640x480}
>>> +
>>> +@item s
>>> +Samples count per value per channel
>> 
>> In most other filters/filtersources, s+size is used for dimensions,
>> d+duration for time, and n for an amount/number of frames/samples or
>> so. Might be a good idea to align with this. And use aliases (i.e.
>> implement both "s" and "size").
>> 
>>> +static const AVOption dumpwave_options[] = {
>>> +{ "d", "set width and height", OFFSET(w),
>>> AV_OPT_TYPE_IMAGE_SIZE,
>>> {.str = "640x480"}, 0, 0, FLAGS },
>>> +{ "s", "set number of samples per value per channel",
>>> OFFSET(s),
>>> AV_OPT_TYPE_INT64,  {.i64 = 0}, 0, INT64_MAX, FLAGS },
>>> +{ "json", "set json dump file", OFFSET(json),
>>> AV_OPT_TYPE_STRING,
>>> {
>>> .str = NULL }, 0, 0, FLAGS },
>>> +{ NULL }
>> [...]
>>> +static av_cold int init(AVFilterContext *ctx)
>>> +{
>>> +DumpWaveContext *dumpwave = ctx->priv;
>>> +if(!dumpwave->s) {
>>> +dumpwave->is_disabled = 1;
>>> +av_log(ctx, AV_LOG_ERROR, "Invalid samples per value
>>> config\n");
>>> +}
>>> +return 0;
>> 
>> I don't like the idea of having to provide the "s" parameter. Is
>> there
>> really no useful default?
>> 
>> And now, if s=0, what does the filter do? Just sit around? Couldn't
>> it
>> fail instead?
>> 
>> Apart from that:
>> "if (" is the bracket style ffmpeg uses.
>> 
>>> +if (dumpwave->json && !(dump_fp =
>>> av_fopen_utf8(dumpwave->json,
>>> "w")))
>>> +av_log(ctx, AV_LOG_WARNING, "Flushing dump failed\n");
>> 
>> I would appreciate evaluation of errno and printing the appropriate
>> string (using av_strerror(), I believe).
>> 
>>> +switch (inlink->format) {
>>> +case AV_SAMPLE_FMT_DBLP:
>> 
>> As Kyle hinted: Can this not force a conversion (implicit insertion
>> of
>> aformat filter) to e.g. double by only supporting this format, and
>> reducing this switch to one or two cases? (The filter's output isn't
>> really meant for transparent reuse anyway? af_volumedetect e.g. also
>> supports only one, meaning its output can be a different format than
>> its input.) It's also really hard to go through and later to
>> maintain.
>> It the big switch/case remains, one or two code macros would be
>> appropriate.
> 
> I checked solution used in volumedetect and couldn't find a way to
> read across formats.
 
 I do not understand what you are trying to do.
>>> Sorry, I'm trying to add support for 8, 16, 24, 32, 64 bit sample
>>> formats
> How would you implement such macros? Since version 3.2 astats filter
> uses same approach for reading different formats and as far as I know
> macros harder to debug
 
 astats is using all formats because of numerous reasons. astats uses
 raw
 values,
 your filter just convert each raw value to float representation.
>>> Is this wrong, as I'd like to have high precision?
>> 
>> For rendering to small size image?
> Data can be used for analysis as well. Any size I would say as user may
> define size
 
 Than use floats.
>>> Ok, will give it a try
>> Here is updated patch
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.

[Carl Eugen Hoyos]

> On 08/01/18 08:35, Jun Zhao wrote:

>> +VAStatus vas;

>> +av_log(avctx, AV_LOG_ERROR, "Failed to Query procamp "
>> +   "query caps: %d (%s).\n", vas, vaErrorStr(vas));

Is "%d" what it's supposed to be? Why is VAStatus needed then?

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

Re: [FFmpeg-devel] [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.

[Mark Thompson]

On 08/01/18 08:35, Jun Zhao wrote:
> 
> From 72b242449086d7366ee524e608bb8f178c15b8cf Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 8 Jan 2018 16:12:41 +0800
> Subject: [PATCH 4/5] lavfi: add ProcAmp(color balance) vaapi video filter.
> 
> add ProcAmp(color balance) vaapi video filter, use the option
> like -vf "procamp_vaapi=b=10:h=120:c=2.8:s=3.7" to set
> brightness/hue/contrast/saturation.
> 
> Signed-off-by: Yun Zhou 
> Signed-off-by: Jun Zhao 
> ---
>  configure  |   1 +
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/vf_procamp_vaapi.c | 308 
> +
>  4 files changed, 311 insertions(+)
>  create mode 100644 libavfilter/vf_procamp_vaapi.c

git says:

Applying: lavfi: add ProcAmp(color balance) vaapi video filter.
.git/rebase-apply/patch:358: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

> 
> diff --git a/configure b/configure
> index 1c3e505b04..366a67d327 100755
> --- a/configure
> +++ b/configure
> @@ -3245,6 +3245,7 @@ perspective_filter_deps="gpl"
>  phase_filter_deps="gpl"
>  pp7_filter_deps="gpl"
>  pp_filter_deps="gpl postproc"
> +procamp_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
>  program_opencl_filter_deps="opencl"
>  pullup_filter_deps="gpl"
>  removelogo_filter_deps="avcodec avformat swscale"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index bbc97a0831..43d0dd36e6 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -275,6 +275,7 @@ OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
>  OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
>  OBJS-$(CONFIG_PREMULTIPLY_FILTER)+= vf_premultiply.o framesync.o
>  OBJS-$(CONFIG_PREWITT_FILTER)+= vf_convolution.o
> +OBJS-$(CONFIG_PROCAMP_VAAPI_FILTER)  += vf_procamp_vaapi.o 
> vaapi_vpp.o
>  OBJS-$(CONFIG_PROGRAM_OPENCL_FILTER) += vf_program_opencl.o opencl.o 
> framesync.o
>  OBJS-$(CONFIG_PSEUDOCOLOR_FILTER)+= vf_pseudocolor.o
>  OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o framesync.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 42516bbdf9..63550628e5 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -284,6 +284,7 @@ static void register_all(void)
>  REGISTER_FILTER(PP7,pp7,vf);
>  REGISTER_FILTER(PREMULTIPLY,premultiply,vf);
>  REGISTER_FILTER(PREWITT,prewitt,vf);
> +REGISTER_FILTER(PROCAMP_VAAPI,  procamp_vaapi,  vf);
>  REGISTER_FILTER(PROGRAM_OPENCL, program_opencl, vf);
>  REGISTER_FILTER(PSEUDOCOLOR,pseudocolor,vf);
>  REGISTER_FILTER(PSNR,   psnr,   vf);
> diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
> new file mode 100644
> index 00..d169d54ebe
> --- /dev/null
> +++ b/libavfilter/vf_procamp_vaapi.c
> @@ -0,0 +1,308 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/hwcontext_vaapi.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "vaapi_vpp.h"
> +
> +typedef struct ProcampVAAPIContext {
> +const AVClass *class;
> +
> +VAAPIVPPContext   *vpp_ctx;
> +
> +float bright;
> +float hue;
> +float saturation;
> +float contrast;
> +} ProcampVAAPIContext;
> +
> +static int procamp_vaapi_query_formats(AVFilterContext *avctx)
> +{
> +return vaapi_vpp_query_formats(avctx);
> +}
> +
> +static int procamp_vaapi_pipeline_uninit(AVFilterContext *avctx)
> +{
> +ProcampVAAPIContext *ctx =  avctx->priv;
> +VAAPIVPPContext *vpp_ctx =  ctx->vpp_ctx;
> +
> +return vaapi_vpp_pipeline_uninit(vpp_ctx);
> +}
> +
> +static int procamp_vaapi_config_input(AVFilterLink *inlink)
> +{
> +AVFilterContext *avctx   = inlink->dst;
> +ProcampVAAPIContext *ctx = avctx->priv;
> +

Re: [FFmpeg-devel] [PATCH 3/5] lavfi: use common VPP infrastructure for vf_deinterlace_vaapi.

[Mark Thompson]

On 08/01/18 08:35, Jun Zhao wrote:
> 
> From 0274a13bc933e4d82a937afb6886b4132834ecff Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 8 Jan 2018 16:07:38 +0800
> Subject: [PATCH 3/5] lavfi: use common VPP infrastructure for
>  vf_deinterlace_vaapi.
> 
> Use the common VPP infrastructure re-work vf_deinterlace_vaapi.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/Makefile   |   2 +-
>  libavfilter/vf_deinterlace_vaapi.c | 318 
> ++---
>  2 files changed, 51 insertions(+), 269 deletions(-)
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 3d8dd2c890..bbc97a0831 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -171,7 +171,7 @@ OBJS-$(CONFIG_DECONVOLVE_FILTER) += 
> vf_convolve.o framesync.o
>  OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
>  OBJS-$(CONFIG_DEFLICKER_FILTER)  += vf_deflicker.o
>  OBJS-$(CONFIG_DEINTERLACE_QSV_FILTER)+= vf_deinterlace_qsv.o
> -OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o
> +OBJS-$(CONFIG_DEINTERLACE_VAAPI_FILTER)  += vf_deinterlace_vaapi.o 
> vaapi_vpp.o
>  OBJS-$(CONFIG_DEJUDDER_FILTER)   += vf_dejudder.o
>  OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
>  OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
> diff --git a/libavfilter/vf_deinterlace_vaapi.c 
> b/libavfilter/vf_deinterlace_vaapi.c
> index 44c5ae7642..f9f5fcd096 100644
> --- a/libavfilter/vf_deinterlace_vaapi.c
> +++ b/libavfilter/vf_deinterlace_vaapi.c
> @@ -33,31 +33,19 @@
>  #include "formats.h"
>  #include "internal.h"
>  #include "video.h"
> +#include "vaapi_vpp.h"
>  
>  #define MAX_REFERENCES 8
>  
>  typedef struct DeintVAAPIContext {
>  const AVClass *class;
>  
> -AVVAAPIDeviceContext *hwctx;
> -AVBufferRef   *device_ref;
> +VAAPIVPPContext   *vpp_ctx;
>  
>  intmode;
>  intfield_rate;
>  intauto_enable;
>  
> -intvalid_ids;
> -VAConfigID va_config;
> -VAContextIDva_context;
> -
> -AVBufferRef   *input_frames_ref;
> -AVHWFramesContext *input_frames;
> -
> -AVBufferRef   *output_frames_ref;
> -AVHWFramesContext *output_frames;
> -intoutput_height;
> -intoutput_width;
> -
>  VAProcFilterCapDeinterlacing
> deint_caps[VAProcDeinterlacingCount];
>  int nb_deint_caps;
> @@ -67,8 +55,6 @@ typedef struct DeintVAAPIContext {
>  intqueue_count;
>  AVFrame   *frame_queue[MAX_REFERENCES];
>  intextra_delay_for_timestamps;
> -
> -VABufferID filter_buffer;
>  } DeintVAAPIContext;
>  
>  static const char *deint_vaapi_mode_name(int mode)
> @@ -87,80 +73,43 @@ static const char *deint_vaapi_mode_name(int mode)
>  
>  static int deint_vaapi_query_formats(AVFilterContext *avctx)
>  {
> -enum AVPixelFormat pix_fmts[] = {
> -AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
> -};
> -int err;
> -
> -if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
> -  >inputs[0]->out_formats)) < 0)
> -return err;
> -if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
> -  >outputs[0]->in_formats)) < 0)
> -return err;
> -
> -return 0;
> +return vaapi_vpp_query_formats(avctx);
>  }
>  
>  static int deint_vaapi_pipeline_uninit(AVFilterContext *avctx)
>  {
>  DeintVAAPIContext *ctx = avctx->priv;
> +VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
>  int i;
>  
>  for (i = 0; i < ctx->queue_count; i++)
>  av_frame_free(>frame_queue[i]);
>  ctx->queue_count = 0;
>  
> -if (ctx->filter_buffer != VA_INVALID_ID) {
> -vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffer);
> -ctx->filter_buffer = VA_INVALID_ID;
> -}
> -
> -if (ctx->va_context != VA_INVALID_ID) {
> -vaDestroyContext(ctx->hwctx->display, ctx->va_context);
> -ctx->va_context = VA_INVALID_ID;
> -}
> -
> -if (ctx->va_config != VA_INVALID_ID) {
> -vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
> -ctx->va_config = VA_INVALID_ID;
> -}
> -
> -av_buffer_unref(>device_ref);
> -ctx->hwctx = NULL;
> -
> -return 0;
> +return vaapi_vpp_pipeline_uninit(vpp_ctx);
>  }
>  
>  static int deint_vaapi_config_input(AVFilterLink *inlink)
>  {
>  AVFilterContext   *avctx = inlink->dst;
> -DeintVAAPIContext *ctx = avctx->priv;
> -
> -deint_vaapi_pipeline_uninit(avctx);
> -
> -if (!inlink->hw_frames_ctx) {
> -av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
> -   "required to associate the processing device.\n");
> -return AVERROR(EINVAL);
> -}
> +DeintVAAPIContext *ctx   = 

Re: [FFmpeg-devel] [PATCH 6/7] avformat: migrate to AVFormatContext->url

[Marton Balint]

On Sun, 14 Jan 2018, Michael Niedermayer wrote:


On Sat, Jan 06, 2018 at 09:50:31PM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 libavformat/concatdec.c  |  4 ++--
 libavformat/dashenc.c| 16 
 libavformat/fifo.c   |  8 
 libavformat/flvenc.c |  4 ++--
 libavformat/gxfenc.c |  4 ++--
 libavformat/hdsenc.c | 24 
 libavformat/img2dec.c|  4 ++--
 libavformat/img2enc.c|  4 ++--
 libavformat/matroskadec.c|  4 ++--
 libavformat/mlvdec.c |  4 ++--
 libavformat/mov.c|  2 +-
 libavformat/movenc.c | 10 +-
 libavformat/mpeg.c   |  4 ++--
 libavformat/mpegtsenc.c  |  2 +-
 libavformat/options.c|  2 +-
 libavformat/rtsp.c   | 18 --
 libavformat/rtspdec.c|  4 ++--
 libavformat/rtspenc.c|  4 +++-
 libavformat/sapdec.c |  2 +-
 libavformat/sapenc.c | 10 --
 libavformat/sdp.c|  4 ++--
 libavformat/segment.c| 36 +---
 libavformat/smoothstreamingenc.c | 12 ++--
 libavformat/tee.c|  4 ++--
 libavformat/utils.c  |  2 +-
 libavformat/webm_chunk.c | 10 +-
 26 files changed, 111 insertions(+), 91 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index bd5174ada2..178fac86cb 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -126,10 +126,10 @@ static int add_file(AVFormatContext *avf, char *filename, 
ConcatFile **rfile,
 url = filename;
 filename = NULL;
 } else {
-url_len = strlen(avf->filename) + strlen(filename) + 16;
+url_len = strlen(avf->url) + strlen(filename) + 16;
 if (!(url = av_malloc(url_len)))
 FAIL(AVERROR(ENOMEM));
-ff_make_absolute_url(url, url_len, avf->filename, filename);
+ff_make_absolute_url(url, url_len, avf->url, filename);
 av_freep();
 }

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 3345b89118..59c55cc8b7 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -685,7 +685,7 @@ static int write_manifest(AVFormatContext *s, int final)
 AVIOContext *out;
 char temp_filename[1024];
 int ret, i;
-const char *proto = avio_find_protocol_name(s->filename);
+const char *proto = avio_find_protocol_name(s->url);
 int use_rename = proto && !strcmp(proto, "file");
 static unsigned int warned_non_file = 0;
 AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
@@ -694,7 +694,7 @@ static int write_manifest(AVFormatContext *s, int final)
 if (!use_rename && !warned_non_file++)
 av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this may 
lead to races and temporary partial files\n");

-snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : "%s", 
s->filename);
+snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : "%s", 
s->url);


could be truncated, the same applies to other cases


We already did silent truncations in the past, so I think this is not
worse than before.

Fixing the fixed length buffers all around the codebase is a lot of work 
and it is easy to make mistakes. So these can be fixed later by the 
relevant maintainers, or this can be a candiate for a janitor task.


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

Re: [FFmpeg-devel] [PATCH 2/5] lavfi: use common VPP infrastructure for vf_scale_vaapi.

[Mark Thompson]

On 08/01/18 08:35, Jun Zhao wrote:
> 
> From 24f60485868087906aa479ebf039590338320754 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 8 Jan 2018 16:02:35 +0800
> Subject: [PATCH 2/5] lavfi: use common VPP infrastructure for vf_scale_vaapi.
> 
> Use the common VPP infrastructure re-work vf_scale_vaapi.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/Makefile |   2 +-
>  libavfilter/vf_scale_vaapi.c | 298 
> ++-
>  2 files changed, 38 insertions(+), 262 deletions(-)
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index ef4729dd3f..3d8dd2c890 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -296,7 +296,7 @@ OBJS-$(CONFIG_SCALE_FILTER)  += 
> vf_scale.o scale.o
>  OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
> vf_scale_cuda.ptx.o
>  OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
>  OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
> -OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
> +OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
> vaapi_vpp.o
>  OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
>  OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
>  OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> index 22e928c098..9c019a4790 100644
> --- a/libavfilter/vf_scale_vaapi.c
> +++ b/libavfilter/vf_scale_vaapi.c
> @@ -33,87 +33,40 @@
>  #include "internal.h"
>  #include "scale.h"
>  #include "video.h"
> +#include "vaapi_vpp.h"
>  
>  typedef struct ScaleVAAPIContext {
>  const AVClass *class;
>  
> -AVVAAPIDeviceContext *hwctx;
> -AVBufferRef *device_ref;
> -
> -int valid_ids;
> -VAConfigID  va_config;
> -VAContextID va_context;
> -
> -AVBufferRef   *input_frames_ref;
> -AVHWFramesContext *input_frames;
> -
> -AVBufferRef   *output_frames_ref;
> -AVHWFramesContext *output_frames;
> +VAAPIVPPContext *vpp_ctx;
>  
>  char *output_format_string;
> -enum AVPixelFormat output_format;
>  
>  char *w_expr;  // width expression string
>  char *h_expr;  // height expression string
> -
> -int output_width;  // computed width
> -int output_height; // computed height
>  } ScaleVAAPIContext;
>  
>  
>  static int scale_vaapi_query_formats(AVFilterContext *avctx)
>  {
> -enum AVPixelFormat pix_fmts[] = {
> -AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
> -};
> -int err;
> -
> -if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
> -  >inputs[0]->out_formats)) < 0)
> -return err;
> -if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
> -  >outputs[0]->in_formats)) < 0)
> -return err;
> -
> -return 0;
> +return vaapi_vpp_query_formats(avctx);
>  }
>  
> -static int scale_vaapi_pipeline_uninit(ScaleVAAPIContext *ctx)
> +static int scale_vaapi_pipeline_uninit(AVFilterContext *avctx)
>  {
> -if (ctx->va_context != VA_INVALID_ID) {
> -vaDestroyContext(ctx->hwctx->display, ctx->va_context);
> -ctx->va_context = VA_INVALID_ID;
> -}
> -
> -if (ctx->va_config != VA_INVALID_ID) {
> -vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
> -ctx->va_config = VA_INVALID_ID;
> -}
> -
> -av_buffer_unref(>output_frames_ref);
> -av_buffer_unref(>device_ref);
> -ctx->hwctx = 0;
> +ScaleVAAPIContext *ctx = avctx->priv;
> +VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
>  
> -return 0;
> +return vaapi_vpp_pipeline_uninit(vpp_ctx);
>  }
>  
>  static int scale_vaapi_config_input(AVFilterLink *inlink)
>  {
>  AVFilterContext *avctx = inlink->dst;
>  ScaleVAAPIContext *ctx = avctx->priv;
> +VAAPIVPPContext *vpp_ctx = ctx->vpp_ctx;
>  
> -scale_vaapi_pipeline_uninit(ctx);
> -
> -if (!inlink->hw_frames_ctx) {
> -av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
> -   "required to associate the processing device.\n");
> -return AVERROR(EINVAL);
> -}
> -
> -ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);
> -ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
> -
> -return 0;
> +return vaapi_vpp_config_input(inlink, vpp_ctx);
>  }
>  
>  static int scale_vaapi_config_output(AVFilterLink *outlink)
> @@ -121,176 +74,46 @@ static int scale_vaapi_config_output(AVFilterLink 
> *outlink)
>  AVFilterLink *inlink = outlink->src->inputs[0];
>  AVFilterContext *avctx = outlink->src;
>  ScaleVAAPIContext *ctx = avctx->priv;
> -AVVAAPIHWConfig *hwconfig = NULL;
> -AVHWFramesConstraints *constraints = NULL;
> -AVVAAPIFramesContext *va_frames;
> -VAStatus vas;
> -int err, i;
> -
> -

Re: [FFmpeg-devel] [PATCH] fix: added more YUVA formats to idet query_formats

[Michael Niedermayer]

On Sat, Jan 13, 2018 at 04:51:43PM +0100, Robert Nagy wrote:
> ---
>  libavfilter/vf_idet.c | 2 ++
>  1 file changed, 2 insertions(+)

applied

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH 5/5] aptx: add raw muxer and demuxer for aptX HD

[Carl Eugen Hoyos]

2018-01-14 14:08 GMT+01:00 Aurelien Jacobs :

> Here is an updated version to match the single codec ID
> version of the encoder / decoder, by using codec_tag.

Please do not set the codec_tag field in the context that a
value that was invented within FFmpeg.

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

Re: [FFmpeg-devel] [PATCH 1/5] lavfi: VAAPI VPP common infrastructure.

[Mark Thompson]

Whole series generally looks good, specific comments follow for each patch.

Thanks,

- Mark


On 08/01/18 08:33, Jun Zhao wrote:
> From 17278f448133826593941ac6b105a4e81cc8b255 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 8 Jan 2018 15:56:43 +0800
> Subject: [PATCH 1/5] lavfi: VAAPI VPP common infrastructure.
> 
> Re-work the VA-API common infrastructure.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavfilter/vaapi_vpp.c | 366 
> 
>  libavfilter/vaapi_vpp.h |  75 ++
>  2 files changed, 441 insertions(+)
>  create mode 100644 libavfilter/vaapi_vpp.c
>  create mode 100644 libavfilter/vaapi_vpp.h
> 
> diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
> new file mode 100644
> index 00..326a716990
> --- /dev/null
> +++ b/libavfilter/vaapi_vpp.c
> @@ -0,0 +1,366 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include 
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/hwcontext_vaapi.h"
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "vaapi_vpp.h"
> +
> +#include "libavutil/pixdesc.h"

Put libavutil headers before libavfilter ones.

> +
> +int vaapi_vpp_query_formats(AVFilterContext *avctx)
> +{
> +enum AVPixelFormat pix_fmts[] = {
> +AV_PIX_FMT_VAAPI, AV_PIX_FMT_NONE,
> +};
> +int err;
> +
> +if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
> +  >inputs[0]->out_formats)) < 0)
> +return err;
> +if ((err = ff_formats_ref(ff_make_format_list(pix_fmts),
> +  >outputs[0]->in_formats)) < 0)
> +return err;
> +
> +return 0;
> +}
> +
> +int vaapi_vpp_pipeline_uninit(VAAPIVPPContext *ctx)
> +{
> +int i;
> +for (i = 0; i < ctx->nb_filter_buffers; i++) {
> +if (ctx->filter_buffers[i] != VA_INVALID_ID) {
> +vaDestroyBuffer(ctx->hwctx->display, ctx->filter_buffers[i]);
> +ctx->filter_buffers[i] = VA_INVALID_ID;
> +}
> +}
> +ctx->nb_filter_buffers = 0;
> +
> +if (ctx->va_context != VA_INVALID_ID) {
> +vaDestroyContext(ctx->hwctx->display, ctx->va_context);
> +ctx->va_context = VA_INVALID_ID;
> +}
> +
> +if (ctx->va_config != VA_INVALID_ID) {
> +vaDestroyConfig(ctx->hwctx->display, ctx->va_config);
> +ctx->va_config = VA_INVALID_ID;
> +}
> +
> +av_buffer_unref(>output_frames_ref);
> +av_buffer_unref(>device_ref);
> +ctx->hwctx = 0;

NULL, please.

> +
> +return 0;
> +}
> +
> +int vaapi_vpp_config_input(AVFilterLink *inlink, VAAPIVPPContext *ctx)
> +{
> +AVFilterContext *avctx = inlink->dst;
> +
> +if (ctx->pipeline_uninit)
> +ctx->pipeline_uninit(avctx);

This function seems to return an error code, should it fail in that case?

> +
> +if (!inlink->hw_frames_ctx) {
> +av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
> +   "required to associate the processing device.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +ctx->input_frames_ref = av_buffer_ref(inlink->hw_frames_ctx);

Can fail.

> +ctx->input_frames = (AVHWFramesContext*)ctx->input_frames_ref->data;
> +
> +return 0;
> +}
> +
> +int vaapi_vpp_config_output(AVFilterLink *outlink, VAAPIVPPContext *ctx)
> +{
> +AVFilterContext *avctx = outlink->src;
> +AVVAAPIHWConfig *hwconfig = NULL;
> +AVHWFramesConstraints *constraints = NULL;
> +AVVAAPIFramesContext *va_frames;
> +VAStatus vas;
> +int err, i;
> +
> +if (ctx->pipeline_uninit)
> +ctx->pipeline_uninit(avctx);

As above, should this fail?

> +
> +av_assert0(ctx->input_frames);
> +ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);

Can fail.

> +ctx->hwctx = ((AVHWDeviceContext*)ctx->device_ref->data)->hwctx;
> +
> +av_assert0(ctx->va_config == VA_INVALID_ID);
> +vas = vaCreateConfig(ctx->hwctx->display, VAProfileNone,
> + VAEntrypointVideoProc, 0, 0, >va_config);

The fourth argument is a pointer, so it should be NULL here.

> +if (vas != VA_STATUS_SUCCESS) {
> +

Re: [FFmpeg-devel] [PATCH 6/7] avformat: migrate to AVFormatContext->url

[Michael Niedermayer]

On Sat, Jan 06, 2018 at 09:50:31PM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavformat/concatdec.c  |  4 ++--
>  libavformat/dashenc.c| 16 
>  libavformat/fifo.c   |  8 
>  libavformat/flvenc.c |  4 ++--
>  libavformat/gxfenc.c |  4 ++--
>  libavformat/hdsenc.c | 24 
>  libavformat/img2dec.c|  4 ++--
>  libavformat/img2enc.c|  4 ++--
>  libavformat/matroskadec.c|  4 ++--
>  libavformat/mlvdec.c |  4 ++--
>  libavformat/mov.c|  2 +-
>  libavformat/movenc.c | 10 +-
>  libavformat/mpeg.c   |  4 ++--
>  libavformat/mpegtsenc.c  |  2 +-
>  libavformat/options.c|  2 +-
>  libavformat/rtsp.c   | 18 --
>  libavformat/rtspdec.c|  4 ++--
>  libavformat/rtspenc.c|  4 +++-
>  libavformat/sapdec.c |  2 +-
>  libavformat/sapenc.c | 10 --
>  libavformat/sdp.c|  4 ++--
>  libavformat/segment.c| 36 +---
>  libavformat/smoothstreamingenc.c | 12 ++--
>  libavformat/tee.c|  4 ++--
>  libavformat/utils.c  |  2 +-
>  libavformat/webm_chunk.c | 10 +-
>  26 files changed, 111 insertions(+), 91 deletions(-)
> 
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index bd5174ada2..178fac86cb 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -126,10 +126,10 @@ static int add_file(AVFormatContext *avf, char 
> *filename, ConcatFile **rfile,
>  url = filename;
>  filename = NULL;
>  } else {
> -url_len = strlen(avf->filename) + strlen(filename) + 16;
> +url_len = strlen(avf->url) + strlen(filename) + 16;
>  if (!(url = av_malloc(url_len)))
>  FAIL(AVERROR(ENOMEM));
> -ff_make_absolute_url(url, url_len, avf->filename, filename);
> +ff_make_absolute_url(url, url_len, avf->url, filename);
>  av_freep();
>  }
>  
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 3345b89118..59c55cc8b7 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -685,7 +685,7 @@ static int write_manifest(AVFormatContext *s, int final)
>  AVIOContext *out;
>  char temp_filename[1024];
>  int ret, i;
> -const char *proto = avio_find_protocol_name(s->filename);
> +const char *proto = avio_find_protocol_name(s->url);
>  int use_rename = proto && !strcmp(proto, "file");
>  static unsigned int warned_non_file = 0;
>  AVDictionaryEntry *title = av_dict_get(s->metadata, "title", NULL, 0);
> @@ -694,7 +694,7 @@ static int write_manifest(AVFormatContext *s, int final)
>  if (!use_rename && !warned_non_file++)
>  av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, 
> this may lead to races and temporary partial files\n");
>  
> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
> "%s", s->filename);
> +snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
> "%s", s->url);

could be truncated, the same applies to other cases

[...]
-- 
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 4/7] avdevice: migrate to AVFormatContext->url

[Michael Niedermayer]

On Sat, Jan 06, 2018 at 09:50:29PM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavdevice/alsa.c  |  4 ++--
>  libavdevice/avfoundation.m  |  2 +-
>  libavdevice/bktr.c  |  2 +-
>  libavdevice/caca.c  |  2 +-
>  libavdevice/decklink_common.cpp |  2 +-
>  libavdevice/decklink_dec.cpp|  4 ++--
>  libavdevice/decklink_enc.cpp|  4 ++--
>  libavdevice/dshow.c |  2 +-
>  libavdevice/fbdev_dec.c |  4 ++--
>  libavdevice/fbdev_enc.c |  4 ++--
>  libavdevice/gdigrab.c   |  2 +-
>  libavdevice/iec61883.c  |  8 
>  libavdevice/jack.c  |  6 +++---
>  libavdevice/lavfi.c |  2 +-
>  libavdevice/libcdio.c   |  6 +++---
>  libavdevice/libndi_newtek_dec.c |  2 +-
>  libavdevice/libndi_newtek_enc.c |  4 ++--
>  libavdevice/openal-dec.c|  2 +-
>  libavdevice/opengl_enc.c|  2 +-
>  libavdevice/oss_dec.c   |  2 +-
>  libavdevice/oss_enc.c   |  2 +-
>  libavdevice/pulse_audio_dec.c   |  4 ++--
>  libavdevice/pulse_audio_enc.c   |  4 ++--
>  libavdevice/sdl2.c  |  2 +-
>  libavdevice/sndio_dec.c |  2 +-
>  libavdevice/sndio_enc.c |  2 +-
>  libavdevice/v4l2.c  | 16 +---
>  libavdevice/v4l2enc.c   |  4 ++--
>  libavdevice/vfwcap.c|  4 ++--
>  libavdevice/xcbgrab.c   |  8 
>  libavdevice/xv.c|  2 +-
>  31 files changed, 59 insertions(+), 57 deletions(-)
[...]

> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -939,7 +939,7 @@ av_cold int ff_decklink_read_header(AVFormatContext 
> *avctx)
>  cctx->raw_format = MKBETAG('v','2','1','0');
>  }
>  
> -strcpy (fname, avctx->filename);
> +av_strlcpy(fname, avctx->url, sizeof(fname));

This could truncate the url

[...]
> @@ -1042,11 +1042,13 @@ static int v4l2_get_device_list(AVFormatContext *ctx, 
> AVDeviceInfoList *device_l
>  return ret;
>  }
>  while ((entry = readdir(dir))) {
> +char device_name[256];
> +
>  if (!v4l2_is_v4l_dev(entry->d_name))
>  continue;
>  
> -snprintf(ctx->filename, sizeof(ctx->filename), "/dev/%s", 
> entry->d_name);
> -if ((s->fd = device_open(ctx)) < 0)
> +snprintf(device_name, sizeof(device_name), "/dev/%s", entry->d_name);

This too could truncate the device name in theory

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

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 7/7] avformat: deprecate AVFormatContext filename field

[Michael Niedermayer]

On Sat, Jan 06, 2018 at 09:50:32PM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  doc/APIchanges |  4 
>  libavformat/avformat.h |  5 +
>  libavformat/mux.c  | 10 ++
>  libavformat/utils.c|  8 
>  libavformat/version.h  |  3 +++
>  5 files changed, 30 insertions(+)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 2/7] avformat: add url field to AVFormatContext

[Michael Niedermayer]

On Sat, Jan 06, 2018 at 09:50:27PM +0100, Marton Balint wrote:
> This will replace the 1024 character limited filename field. Compatiblity for
> output contexts are provided by copying filename field to URL if URL is unset
> and by providing an internal function for muxers to set both url and filename
> at once.
> 
> Signed-off-by: Marton Balint 
> ---
>  doc/APIchanges |  3 +++
>  libavformat/avformat.h | 15 +++
>  libavformat/internal.h |  7 +++
>  libavformat/mux.c  | 11 ++-
>  libavformat/utils.c| 14 ++
>  libavformat/version.h  |  2 +-
>  6 files changed, 50 insertions(+), 2 deletions(-)

LGTM

thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Carl Eugen Hoyos]

2018-01-14 14:06 GMT+01:00 Aurelien Jacobs :

> Well, here is an updated patch which uses codec tags for the decoder and
> profile for the encoder.

Sorry but I object to this patch:
We should not invent codec_tags.

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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Rostislav Pehlivanov]

On 14 January 2018 at 13:06, Aurelien Jacobs  wrote:

> On Tue, Jan 09, 2018 at 02:21:02PM +, Rostislav Pehlivanov wrote:
> > On 9 January 2018 at 14:07, Rostislav Pehlivanov 
> > wrote:
> >
> > >
> > >
> > > On 9 January 2018 at 09:00, Hendrik Leppkes 
> wrote:
> > >
> > >> On Tue, Jan 9, 2018 at 9:33 AM, Hendrik Leppkes 
> > >> wrote:
> > >> > On Tue, Jan 9, 2018 at 5:07 AM, Rostislav Pehlivanov
> > >> >  wrote:
> > >> >>
> > >> >>> Anyway, all this discussion is moot as Hendrik pointed out that
> > >> profile
> > >> >>> can't be set outside of lavc to determine a decoder behavior.
> > >> >>>
> > >> >>
> > >> >> What, based on a comment in lavc? Comments there describe the api
> but
> > >> they
> > >> >> rarely define it. We're free to adjust them if need be and in this
> > >> case,
> > >> >> since the codec profile may not be set, the API user is forced to
> deal
> > >> with
> > >> >> the lack of such set. Hence, we can clarify that it may be set by
> lavf
> > >> as
> > >> >> well as lavc as well as not being set at all. And the decoder may
> use
> > >> it.
> > >> >> I maintain that adding a new codec ID for this is unacceptable.
> > >> >>
> > >> >
> > >> > We already have established methods to select codec sub-variants, we
> > >> > don't need to invent a new one just because you feel like it.
> > >> >
> > >>
> > >> On that note, we also have cases where the same codec has different
> > >> codec ids based on popular known names.
> > >> For example wmv3/vc1 - wmv3 is simple/main profile, vc1 is advanced
> > >> profile, different codec ids, same implementation.
> > >>
> > >> Re-defining public API is what is unacceptable, it requires every
> > >> caller of lavc to suddenly start handling one more field for no real
> > >> reason.
> > >>
> > >
> > > Then its a good thing I suggested something that doesn't involve having
> > > every caller of lavc to handle another field.
> > >
> > >
> > >
> > >> Either use a separate codec ID if there is sufficient reason for that
> > >> (mostly driven by external factors, if its handled as different codecs
> > >> everywhere else, not only in marketing but actual (reference)
> > >> implementations), or use a codec_tag if one is available (the codec id
> > >> field from a2dp for example)
> > >
> > > I'd be fine with using codec tags, but not with codec IDs.
> >
> > Though for encoding using profiles would be best.
>
> Well, here is an updated patch which uses codec tags for the decoder and
> profile for the encoder.
>
> I still maintain that this solution is worse than using separate
> codec IDs.
> It is worse for developper / maintainer as it adds a bit of compexity to
> the code.
>
It is worse for user as it requires adding a mandatory parameter for
> encoding to aptX HD:
>   ffmpeg -i sample.wav -profile:a 1 sample.aptxhd
>

As opposed to having a mandatory parameter for encoder like -c:a aptx_hd?
Perhaps we should encode everything to aptx hd by default to not have to
mess about by confusing users with these codecs or profiles things.


Without this -profile parameter, the encoding will just fail but user
> will have to guess how to fix it.
>

Here's how you could fix it: don't have separate muxers for aptx and
aptxhd. Make the aptx muxer handle both .aptx and .aptxhd extensions and
the codec tags. There's no difference in how either are encoded since its
all raw. Sure, it prevents strictly mandating that an aptxhd extension will
always carry aptxhd bitstreams, but what do you expect, its a raw format
and there are no guarantees that extensions always mandate what's in a
file. That's why we probe.
I'm fine with either having a separate muxer or a common one with multiple
extensions, so I don't mind things as they are here.



> And the reported stream is much less explicit:
>   Stream #0:0: Audio: aptx ([36][0][215][0] / 0xD70024), 48000 Hz, 2
> channels, s32p
> vs.
>   Stream #0:0: Audio: aptx_hd, 48000 Hz, 2 channels, s32p
>

Profiles are still explicit
"Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp (16 bit), 128 kb/s"
vs
"Stream #0:0: Audio: aac (Main), 44100 Hz, stereo, fltp (16 bit), 128 kb/s"



> So for the good of users and maintainers, I suggest to follow the
> wmv3/vc1 example, that is to acknowledge that aptX and aptX HD are
> commonly used as 2 separate codecs (search for
> libaptX-1.0.0-rel-Android21-ARMv7A.so and
> libaptXHD-1.0.0-rel-Android21-ARMv7A.so for example) and use the
> original patch with 2 codec IDs.
>

Ah, android, a shining beacon of well-written, small, generic code, always
happy to reuse code and other people's work. No, wait, the other way around.


Anyway, code-wise, there's one or two minor issues:

+#define A2DP_VENDOR_ID_APT  0x004F
> +#define A2DP_APT_CODEC_ID_APTX  0x0001
> +
> +#define A2DP_VENDOR_ID_QUALCOMM 0x00D7
> +#define A2DP_QUALCOMM_CODEC_ID_APTX_HD  0x0024
>

You have 3 

Re: [FFmpeg-devel] [PATCH v2 1/1] avformat/hlsenc: closed caption tags in the master playlist

[Liu Steven]

> 在 2018年1月9日，下午5:54，Dixit, Vishwanath  写道：
> 
> 
> 
> On 1/9/18 3:05 PM, 刘歧 wrote:
> 
 
 
 I cannot sure use -cc_stream_map_ccgroup option is ok, because the ccgroup 
 string is not standard, maybe it can be defined bu user.
 Maybe two ways:
 1. use -cc_stream_map_ccgroup ? this way is defined the name by ffmpeg, 
 cannot modify.
 2. parse the closed captions group string by KeyValue way? maybe this is 
 better.
>>> 
>>> Actually, these requirements have been already handled. The parsing is 
>>> happening based on key value pairs. The keys are ‘ccgroup’, ‘instreamid’, 
>>> ‘language’. The values for these keys can be set after ‘:’ as given the 
>>> examples in the patch. 
>>> I am assuming you are trying to set ccgroup name as closecgroup. In that 
>>> case, please modify the command as below. Because, the string ‘ccgroup’ is 
>>> a key value, whatever string that comes after ‘ccgroup:’ is the cc group 
>>> name.  
>>> ./ffmpeg -re -f lavfi -i color=red  -g 25  -b:v 1000k -b:a 64k -a53cc 1 -f 
>>> hls  -cc_stream_map "ccgroup:closecgroup,instreamid:CC1,language:en"   
>>> -master_pl_name master.m3u8  live/out.m3u8
>>> 
>>> To clarify further, consider user wants to set cc group name as 
>>> ‘mycaptions’, instream id as ‘SERVICE60’ language as Spanish, in that case, 
>>> the map string would be
>>> -cc_stream_map "ccgroup:mycaptions,instreamid:SERVICE60,language:sp”  
>> I understand and i got the point, 
>> just one question, do you want force the user use ffmpeg must input a string 
>> “ccgroup” ? if yes, maybe don’t let the user input it use string, maybe use 
>> -cc_stream_map_ccgroup is better, What do you think about it?
> Are you suggesting to change the string from ‘–cc_stream_map’ to 
> ‘-cc_stream_map_ccgroup’ and remove the ‘ccgroup’ key from the value string? 
> Could you please clarify?
> 
> Apart from this, I would like to highlight some advanced use cases where 
> current implementation will be more meaningful. It is possible that that 
> there could be multiple instream ids under the same closed caption group or 
> there can be different closed captions groups. Example:
> -cc_stream_map "ccgroup:group1,instreamid:CC1,language:en 
> ccgroup:group1,instreamid:CC2,language:sp”
> -cc_stream_map "ccgroup:eng_group,instreamid:CC1,language:en 
> ccgroup:span_group,instreamid:CC1,language:sp”
> 
> In these cases, the same ccgroup is mentioned in the –var_stream_map string 
> as well.
> -var_stream_map "v:0,a:0,ccgroup:group1 v:1,a:1,ccgroup:group1" or
> -var_stream_map "v:0,a:0,ccgroup:eng_group v:1,a:1,ccgroup:span_group"
> 
> Here, ‘ccgroup’ is a common key between –cc_stream_map and –var_stream_map. 
> So, it is better to keep this key so that it will more readable and easily 
> configurable for the user.

Hi Dixit,

I cannot found “ccgroup” string in rfc8216, or dose it in some other 
specifications? Or user MUST use “ccgroup” in the var_stream_map?
> 
>> 
>> 
>> Thanks
>> 
>> Steven
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

Re: [FFmpeg-devel] [PATCH 6/6] dashdec: Support SegmentTemplate inside Period

[Liu Steven]

> 在 2018年1月8日，上午2:46，Stefan _  写道：
> 
> 
> <0006-dashdec-Support-SegmentTemplate-inside-Period.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Patchset pushed


Thanks

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

Re: [FFmpeg-devel] avcodec/utvideoenc : add SIMD (SSSE3) for sub_left_pred

[Martin Vignali]

Hello,

new patch in attach
no more segfault if i remove movsxdifnidn, after change in the
"declare_func_emms"
part

I also modify the checkasm test, following your comments

Martin


0001-avcodec-utvideoenc-add-SIMD-avx-for-sub_left_predict.patch
Description: Binary data


0002-checkasm-add-test-for-losslessvideoencdsp-for-diff.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/adtsenc - allow only AAC streams

[James Almer]

On 1/14/2018 9:06 AM, Gyan Doshi wrote:
> From c3da268449ca4677958856d99b0d1ce4695f0924 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Sun, 14 Jan 2018 17:30:23 +0530
> Subject: [PATCH] avformat/adtsenc - allow only AAC streams
> 
> The ADTS muxer will silently (attempt to) mux any audio stream passed to it.
> Patch adds a codec check.
> ---
>  libavformat/adtsenc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/adtsenc.c b/libavformat/adtsenc.c
> index a24f99c447..cb20d789c8 100644
> --- a/libavformat/adtsenc.c
> +++ b/libavformat/adtsenc.c
> @@ -99,6 +99,11 @@ static int adts_write_header(AVFormatContext *s)
>  ADTSContext *adts = s->priv_data;
>  AVCodecParameters *par = s->streams[0]->codecpar;
>  
> +if (par->codec_id != AV_CODEC_ID_AAC) {
> +av_log(s, AV_LOG_ERROR, "Only AAC streams can be muxed by the ADTS 
> muxer\n");
> +return AVERROR(EINVAL);
> +}
> +
>  if (adts->id3v2tag)
>  ff_id3v2_write_simple(s, 4, ID3v2_DEFAULT_MAGIC);
>  if (par->extradata_size > 0)
> -- 2.11.1.windows.1

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

Re: [FFmpeg-devel] [PATCH 5/5] aptx: add raw muxer and demuxer for aptX HD

[Aurelien Jacobs]

On Sun, Jan 07, 2018 at 04:55:43PM +0100, Aurelien Jacobs wrote:
> On Sun, Jan 07, 2018 at 12:53:27AM +0100, Michael Niedermayer wrote:
> > On Sat, Jan 06, 2018 at 05:48:08PM +0100, Aurelien Jacobs wrote:
> > > ---
> > >  Changelog|  2 +-
> > >  libavformat/Makefile |  2 ++
> > >  libavformat/allformats.c |  1 +
> > >  libavformat/aptxdec.c| 51 
> > > 
> > >  libavformat/rawenc.c | 13 
> > >  5 files changed, 64 insertions(+), 5 deletions(-)
> > [...]
> > > @@ -66,6 +94,7 @@ static const AVClass aptx_demuxer_class = {
> > >  .version= LIBAVUTIL_VERSION_INT,
> > >  };
> > >  
> > > +#if CONFIG_APTX_MUXER
> > >  AVInputFormat ff_aptx_demuxer = {
> > >  .name   = "aptx",
> > >  .long_name  = NULL_IF_CONFIG_SMALL("raw aptX"),
> > > @@ -76,3 +105,17 @@ AVInputFormat ff_aptx_demuxer = {
> > >  .flags  = AVFMT_GENERIC_INDEX,
> > 
> > >  .priv_class = _demuxer_class,
> > [...]
> > > +.priv_class = _demuxer_class,
> > 
> > this cause the code (for example fate) to infinite loop
> 
> Oh, indeed, it seems 2 demuxers can't share the same priv_class.
> Here is an updated patch.

Here is an updated version to match the single codec ID version of the
encoder / decoder, by using codec_tag.
>From a63645428b4d8332f5389dfe0f66229a5bfe8058 Mon Sep 17 00:00:00 2001
From: Aurelien Jacobs 
Date: Sat, 6 Jan 2018 17:33:01 +0100
Subject: [PATCH 5/5] aptx: add raw muxer and demuxer for aptX HD

---
 Changelog|  2 +-
 libavformat/Makefile |  2 ++
 libavformat/allformats.c |  1 +
 libavformat/aptxdec.c| 68 +---
 libavformat/rawenc.c | 33 ++-
 5 files changed, 100 insertions(+), 6 deletions(-)

diff --git a/Changelog b/Changelog
index 9349bf1e8d..3a97b0b02e 100644
--- a/Changelog
+++ b/Changelog
@@ -12,7 +12,7 @@ version :
 - Intel QSV-accelerated MJPEG encoding
 - PCE support for extended channel layouts in the AAC encoder
 - native aptX and aptX HD encoder and decoder
-- Raw aptX muxer and demuxer
+- Raw aptX and aptX HD muxer and demuxer
 - NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2/4, VC1, VP8/9 hwaccel decoding
 - Intel QSV-accelerated overlay filter
 - mcompand audio filter
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cb70eac920..dbe2890297 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -96,6 +96,8 @@ OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
 OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
 OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
+OBJS-$(CONFIG_APTX_HD_DEMUXER)   += aptxdec.o rawdec.o
+OBJS-$(CONFIG_APTX_HD_MUXER) += rawenc.o
 OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
 OBJS-$(CONFIG_ASF_DEMUXER)   += asfdec_f.o asf.o asfcrypt.o \
 avlanguage.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 6a9b9883c9..b70b7463b9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -70,6 +70,7 @@ static void register_all(void)
 REGISTER_DEMUXER (APE,  ape);
 REGISTER_MUXDEMUX(APNG, apng);
 REGISTER_MUXDEMUX(APTX, aptx);
+REGISTER_MUXDEMUX(APTX_HD,  aptx_hd);
 REGISTER_DEMUXER (AQTITLE,  aqtitle);
 REGISTER_MUXDEMUX(ASF,  asf);
 REGISTER_DEMUXER (ASF_O,asf_o);
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
index 3b8fae1b55..dfa07337b6 100644
--- a/libavformat/aptxdec.c
+++ b/libavformat/aptxdec.c
@@ -26,26 +26,59 @@
 #define APTX_BLOCK_SIZE   4
 #define APTX_PACKET_SIZE  (256*APTX_BLOCK_SIZE)
 
+#define APTX_HD_BLOCK_SIZE   6
+#define APTX_HD_PACKET_SIZE  (256*APTX_HD_BLOCK_SIZE)
+
+#define A2DP_VENDOR_ID_APT  0x004F
+#define A2DP_APT_CODEC_ID_APTX  0x0001
+
+#define A2DP_VENDOR_ID_QUALCOMM 0x00D7
+#define A2DP_QUALCOMM_CODEC_ID_APTX_HD  0x0024
+
 typedef struct AptXDemuxerContext {
 AVClass *class;
 int sample_rate;
 } AptXDemuxerContext;
 
-static int aptx_read_header(AVFormatContext *s)
+static AVStream *aptx_read_header_common(AVFormatContext *s)
 {
 AptXDemuxerContext *s1 = s->priv_data;
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st)
-return AVERROR(ENOMEM);
+return NULL;
 st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id = AV_CODEC_ID_APTX;
 st->codecpar->format = AV_SAMPLE_FMT_S32P;
 st->codecpar->channels = 2;
 st->codecpar->sample_rate = s1->sample_rate;
+st->start_time = 0;
+return st;
+}
+
+static int aptx_read_header(AVFormatContext *s)
+{
+AVStream *st = aptx_read_header_common(s);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_id = 

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Aurelien Jacobs]

On Tue, Jan 09, 2018 at 02:21:02PM +, Rostislav Pehlivanov wrote:
> On 9 January 2018 at 14:07, Rostislav Pehlivanov 
> wrote:
> 
> >
> >
> > On 9 January 2018 at 09:00, Hendrik Leppkes  wrote:
> >
> >> On Tue, Jan 9, 2018 at 9:33 AM, Hendrik Leppkes 
> >> wrote:
> >> > On Tue, Jan 9, 2018 at 5:07 AM, Rostislav Pehlivanov
> >> >  wrote:
> >> >>
> >> >>> Anyway, all this discussion is moot as Hendrik pointed out that
> >> profile
> >> >>> can't be set outside of lavc to determine a decoder behavior.
> >> >>>
> >> >>
> >> >> What, based on a comment in lavc? Comments there describe the api but
> >> they
> >> >> rarely define it. We're free to adjust them if need be and in this
> >> case,
> >> >> since the codec profile may not be set, the API user is forced to deal
> >> with
> >> >> the lack of such set. Hence, we can clarify that it may be set by lavf
> >> as
> >> >> well as lavc as well as not being set at all. And the decoder may use
> >> it.
> >> >> I maintain that adding a new codec ID for this is unacceptable.
> >> >>
> >> >
> >> > We already have established methods to select codec sub-variants, we
> >> > don't need to invent a new one just because you feel like it.
> >> >
> >>
> >> On that note, we also have cases where the same codec has different
> >> codec ids based on popular known names.
> >> For example wmv3/vc1 - wmv3 is simple/main profile, vc1 is advanced
> >> profile, different codec ids, same implementation.
> >>
> >> Re-defining public API is what is unacceptable, it requires every
> >> caller of lavc to suddenly start handling one more field for no real
> >> reason.
> >>
> >
> > Then its a good thing I suggested something that doesn't involve having
> > every caller of lavc to handle another field.
> >
> >
> >
> >> Either use a separate codec ID if there is sufficient reason for that
> >> (mostly driven by external factors, if its handled as different codecs
> >> everywhere else, not only in marketing but actual (reference)
> >> implementations), or use a codec_tag if one is available (the codec id
> >> field from a2dp for example)
> >
> > I'd be fine with using codec tags, but not with codec IDs.
>
> Though for encoding using profiles would be best.

Well, here is an updated patch which uses codec tags for the decoder and
profile for the encoder.

I still maintain that this solution is worse than using separate
codec IDs.
It is worse for developper / maintainer as it adds a bit of compexity to
the code.
It is worse for user as it requires adding a mandatory parameter for
encoding to aptX HD:
  ffmpeg -i sample.wav -profile:a 1 sample.aptxhd
Without this -profile parameter, the encoding will just fail but user
will have to guess how to fix it.
And the reported stream is much less explicit:
  Stream #0:0: Audio: aptx ([36][0][215][0] / 0xD70024), 48000 Hz, 2 channels, 
s32p
vs.
  Stream #0:0: Audio: aptx_hd, 48000 Hz, 2 channels, s32p

So for the good of users and maintainers, I suggest to follow the
wmv3/vc1 example, that is to acknowledge that aptX and aptX HD are
commonly used as 2 separate codecs (search for
libaptX-1.0.0-rel-Android21-ARMv7A.so and
libaptXHD-1.0.0-rel-Android21-ARMv7A.so for example) and use the
original patch with 2 codec IDs.
But anyway, if there is a consensus for using a single codec ID, this
new patch can be applied.
>From bdf5d5f4a3724a70efe0cad76179a57619c6fad0 Mon Sep 17 00:00:00 2001
From: Aurelien Jacobs 
Date: Sat, 6 Jan 2018 17:11:48 +0100
Subject: [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

---
 Changelog |   2 +-
 libavcodec/Makefile   |   2 +
 libavcodec/aptx.c | 352 +-
 libavcodec/avcodec.h  |   3 +
 libavcodec/profiles.c |   6 +
 libavcodec/profiles.h |   1 +
 6 files changed, 336 insertions(+), 30 deletions(-)

diff --git a/Changelog b/Changelog
index 3d966c202b..9349bf1e8d 100644
--- a/Changelog
+++ b/Changelog
@@ -11,7 +11,7 @@ version :
 - TiVo ty/ty+ demuxer
 - Intel QSV-accelerated MJPEG encoding
 - PCE support for extended channel layouts in the AAC encoder
-- native aptX encoder and decoder
+- native aptX and aptX HD encoder and decoder
 - Raw aptX muxer and demuxer
 - NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2/4, VC1, VP8/9 hwaccel decoding
 - Intel QSV-accelerated overlay filter
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cfacd6b70c..a9ecf7ea5e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -190,6 +190,8 @@ OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
 OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
 OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
+OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
+OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
 OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_APNG_ENCODER)+= 

[FFmpeg-devel] [PATCH] avformat/adtsenc - allow only AAC streams

[Gyan Doshi]

From c3da268449ca4677958856d99b0d1ce4695f0924 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sun, 14 Jan 2018 17:30:23 +0530
Subject: [PATCH] avformat/adtsenc - allow only AAC streams

The ADTS muxer will silently (attempt to) mux any audio stream passed to it.
Patch adds a codec check.
---
 libavformat/adtsenc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/adtsenc.c b/libavformat/adtsenc.c
index a24f99c447..cb20d789c8 100644
--- a/libavformat/adtsenc.c
+++ b/libavformat/adtsenc.c
@@ -99,6 +99,11 @@ static int adts_write_header(AVFormatContext *s)
 ADTSContext *adts = s->priv_data;
 AVCodecParameters *par = s->streams[0]->codecpar;
 
+if (par->codec_id != AV_CODEC_ID_AAC) {
+av_log(s, AV_LOG_ERROR, "Only AAC streams can be muxed by the ADTS 
muxer\n");
+return AVERROR(EINVAL);
+}
+
 if (adts->id3v2tag)
 ff_id3v2_write_simple(s, 4, ID3v2_DEFAULT_MAGIC);
 if (par->extradata_size > 0)
-- 
2.11.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/utvideoenc : add SIMD (SSSE3) for sub_left_pred

[James Almer]

On 1/14/2018 7:46 AM, Henrik Gramner wrote:
> On Sat, Jan 13, 2018 at 5:22 PM, Martin Vignali
>  wrote:
>> +#define randomize_buffers(buf, size) \
>> +do { \
>> +int j;   \
>> +uint8_t *tmp_buf = (uint8_t *)buf;\
>> +for (j = 0; j < size; j++)   \
>> +tmp_buf[j] = rnd() & 0xFF;   \
>> +} while (0)
> 
> Typecast is redundant since everything is already uint8_t (unless you
> plan to add more things that aren't).
> 
> & 0xFF is redundant for bytes.

AV_WN32 should be used here to write all four bytes instead of wasting
24 bits from every random value generated.

> 
>> +static void check_diff_bytes(LLVidEncDSPContext c)
> [...]
>> +static void check_sub_left_pred(LLVidEncDSPContext c)
> 
> Struct arguments should generallly be passed by reference (pointer).
> 
>> +if (!dst0 || !dst1)
>> +fail();
> [...]
>> +if (!dst0 || !dst1 || !src0)
>> +fail();
> 
> fail() is used to signal that the currently tested function has failed
> and shouldn't be used outside of the check_func() scope. In this case
> it wouldn't even prevent segfaults by dereferencing the NULL pointers
> anyway in case of malloc failure.
> 
> Actually, you could get rid of malloc and just use fixed-size stack
> buffers to simplify things.
> ___
> 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] avcodec/utvideoenc : add SIMD (SSSE3) for sub_left_pred

[Henrik Gramner]

On Sat, Jan 13, 2018 at 5:22 PM, Martin Vignali
 wrote:
> +#define randomize_buffers(buf, size) \
> +do { \
> +int j;   \
> +uint8_t *tmp_buf = (uint8_t *)buf;\
> +for (j = 0; j < size; j++)   \
> +tmp_buf[j] = rnd() & 0xFF;   \
> +} while (0)

Typecast is redundant since everything is already uint8_t (unless you
plan to add more things that aren't).

& 0xFF is redundant for bytes.

> +static void check_diff_bytes(LLVidEncDSPContext c)
[...]
> +static void check_sub_left_pred(LLVidEncDSPContext c)

Struct arguments should generallly be passed by reference (pointer).

> +if (!dst0 || !dst1)
> +fail();
[...]
> +if (!dst0 || !dst1 || !src0)
> +fail();

fail() is used to signal that the currently tested function has failed
and shouldn't be used outside of the check_func() scope. In this case
it wouldn't even prevent segfaults by dereferencing the NULL pointers
anyway in case of malloc failure.

Actually, you could get rid of malloc and just use fixed-size stack
buffers to simplify things.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_framerate: add SIMD functions for frame blending

[Henrik Gramner]

On Sat, Jan 13, 2018 at 10:57 PM, Marton Balint  wrote:
> +.loop:
> +movum0, [src1q + xq]
> +movum1, [src2q + xq]
> +punpckl%1%2 m5, m0, m2 ; 0e0f0g0h
> +punpckh%1%2 m0, m2 ; 0a0b0c0d
> +punpckl%1%2 m6, m1, m2 ; 0E0F0G0H
> +punpckh%1%2 m1, m2 ; 0A0B0C0D
> +pmull%2 m0, m3
> +pmull%2 m5, m3
> +pmull%2 m1, m4
> +pmull%2 m6, m4
> +padd%2  m0, m7
> +padd%2  m5, m7
> +padd%2  m0, m1
> +padd%2  m5, m6

pmaddubsw should work here for the 8-bit case. pmaddwd might work for
the 16-bit case depending on how many bits are actually used.

> +pinsrwxm3, r8m, 0   ; factor1
> +pinsrwxm4, r9m, 0   ; factor2
> +pinsrwxm7, r10m, 0  ; half
> +SPLATW m3, xm3
> +SPLATW m4, xm4
> +SPLATW m7, xm7

vpbroadcast* from memory on avx2, otherwise movd instead of pxor+pinsrw.

> +pxor   m3, m3
> +pxor   m4, m4
> +pxor   m7, m7
> +pinsrwxm3, r8m, 0   ; factor1
> +pinsrwxm4, r9m, 0   ; factor2
> +pinsrwxm7, r10m, 0  ; half
> +XSPLATD   3
> +XSPLATD   4
> +XSPLATD   7

Ditto.

> +neg word r11m   ; shift = -shift
> +add word r11m, 16   ; shift += 16
> +pxor   m2, m2
> +pinsrwxm2, r11m, 0  ; 16 - shift
> +pslld  m3, xm2
> +pslld  m4, xm2
> +pslld  m7, xm2

You probably want to use a temporary register instead of doing slow
load-modify-store instructions.

Doing this in SIMD might be an option as well, e.g. load data directly
into vector regs from the stack, shift, then splat.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel