Re: [FFmpeg-devel] [PATCH 2/4] avformat/avienc: write chained master index only if std_compliance is normal or below
On 17.01.2017 14:39, Tobias Rapp wrote: OpenDML specification v1.02 states that entries of a master index chunk shall point to standard or field index chunks. Changed incorrect duration of last master index entry to -1 in case it points to another master index. Propagate error when index write fails. Signed-off-by: Tobias Rapp --- libavformat/avienc.c | 30 +++--- 1 file changed, 23 insertions(+), 7 deletions(-) Sorry, I messed up something with Git send-email in-reply-to. This patch is part of obsolete patch-series version 2, please consider it as dropped. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/avienc: add reserve_index_space option
On 17.01.2017 14:39, Tobias Rapp wrote: Allows the user to reserve space for the ODML master index. A sufficient sized master index in the AVI header avoids storing follow-up master indexes within the 'movi' data later. If the option is omitted or zero the index size is estimated from output duration and bitrate. A worst-case bitrate for video streams is assumed in case it is not available. Note: fate reference files changed because the video stream had zero bitrate before and is guessed now. Signed-off-by: Tobias Rapp --- libavformat/avi.h | 1 - libavformat/avienc.c| 84 + libavformat/version.h | 2 +- tests/ref/fate/mpeg4-bsf-unpack-bframes | 2 +- tests/ref/lavf-fate/avi_cram| 2 +- 5 files changed, 78 insertions(+), 13 deletions(-) Sorry, I messed up something with Git send-email in-reply-to. This patch is part of patch-series version 2 which is supersede by version 3: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/205905.html Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix too many open files bug
I test the new patch, it is OK.
Thanks
Yin Jiaoyuan
At 2017-01-19 10:20:38, "Steven Liu" wrote:
>When use http method to delete the old segments,
>there is only io_open, hove not io_close yet,
>this patch is used to fix it
>
>Signed-off-by: Steven Liu
>---
> libavformat/hlsenc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>index 1f4bf8b..85d3955 100644
>--- a/libavformat/hlsenc.c
>+++ b/libavformat/hlsenc.c
>@@ -300,6 +300,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
> av_dict_set(&options, "method", "DELETE", 0);
> if ((ret = hls->avf->io_open(hls->avf, &out, path,
> AVIO_FLAG_WRITE, &options)) < 0)
> goto fail;
>+ff_format_io_close(hls->avf, &out);
> } else if (unlink(path) < 0) {
> av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s: %s\n",
> path, strerror(errno));
>@@ -322,6 +323,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
> av_free(sub_path);
> goto fail;
> }
>+ff_format_io_close(hls->avf, &out);
> } else if (unlink(sub_path) < 0) {
> av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s:
> %s\n",
> sub_path, strerror(errno));
>--
>2.10.1.382.ga23ca1b.dirty
>
>
>
>___
>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] [PATCH] avformat/hlsenc: fix too many open files bug
When use http method to delete the old segments,
there is only io_open, hove not io_close yet,
this patch is used to fix it
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1f4bf8b..85d3955 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -300,6 +300,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
av_dict_set(&options, "method", "DELETE", 0);
if ((ret = hls->avf->io_open(hls->avf, &out, path,
AVIO_FLAG_WRITE, &options)) < 0)
goto fail;
+ff_format_io_close(hls->avf, &out);
} else if (unlink(path) < 0) {
av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s: %s\n",
path, strerror(errno));
@@ -322,6 +323,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
av_free(sub_path);
goto fail;
}
+ff_format_io_close(hls->avf, &out);
} else if (unlink(sub_path) < 0) {
av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s:
%s\n",
sub_path, strerror(errno));
--
2.10.1.382.ga23ca1b.dirty
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix bug of hlsenc http delete old segments
2017-01-19 9:35 GMT+08:00 殷焦元 :
> I test this patch, I found it show below log info and ffmpeg term auto.
>
> av_interleaved_write_frame(): Too many open files
> No more output streams to write to, finishing.
>
> I think it is not OK.
> Yin Jiaoyuan
>
ok , i wll make a new patch to file the too many open files
>
>
>
>
> At 2017-01-19 07:08:08, "Steven Liu" wrote:
> >2017-01-17 14:28 GMT+08:00 Steven Liu :
> >
> >> when push hls to http server, the old segemnts can not delete by hls
> >> formats.
> >> so add the http option into hls_delete_old_segments
> >>
> >> Reported-by: Yin Jiaoyuan
> >> Signed-off-by: Steven Liu
> >> ---
> >> libavformat/hlsenc.c | 17 +++--
> >> 1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> index f02b887..87f7717 100644
> >> --- a/libavformat/hlsenc.c
> >> +++ b/libavformat/hlsenc.c
> >> @@ -245,6 +245,8 @@ static int hls_delete_old_segments(HLSContext
> *hls) {
> >> int ret = 0, path_size, sub_path_size;
> >> char *dirname = NULL, *p, *sub_path;
> >> char *path = NULL;
> >> +AVDictionary *options = NULL;
> >> +AVIOContext *out = NULL;
> >>
> >> segment = hls->segments;
> >> while (segment) {
> >> @@ -294,7 +296,11 @@ static int hls_delete_old_segments(HLSContext
> *hls) {
> >> av_strlcat(path, segment->filename, path_size);
> >> }
> >>
> >> -if (unlink(path) < 0) {
> >> +if (hls->method) {
> >> +av_dict_set(&options, "method", "DELETE", 0);
> >> +if ((ret = hls->avf->io_open(hls->avf, &out, path,
> >> AVIO_FLAG_WRITE, &options)) < 0)
> >> +goto fail;
> >> +} else if (unlink(path) < 0) {
> >> av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s:
> >> %s\n",
> >> path, strerror(errno));
> >> }
> >> @@ -309,7 +315,14 @@ static int hls_delete_old_segments(HLSContext
> *hls) {
> >>
> >> av_strlcpy(sub_path, dirname, sub_path_size);
> >> av_strlcat(sub_path, segment->sub_filename, sub_path_size);
> >> -if (unlink(sub_path) < 0) {
> >> +
> >> +if (hls->method) {
> >> +av_dict_set(&options, "method", "DELETE", 0);
> >> +if ((ret = hls->avf->io_open(hls->avf, &out, sub_path,
> >> AVIO_FLAG_WRITE, &options)) < 0) {
> >> +av_free(sub_path);
> >> +goto fail;
> >> +}
> >> +} else if (unlink(sub_path) < 0) {
> >> av_log(hls, AV_LOG_ERROR, "failed to delete old segment
> >> %s: %s\n",
> >> sub_path, strerror(errno));
> >> }
> >> --
> >> 2.10.1.382.ga23ca1b.dirty
> >>
> >>
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> >applied!
> >
> >
> >Thanks
> >___
> >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] avformat/caf: add 'aacl' codec tag
On Thu, Jan 19, 2017 at 12:35:28AM +0100, Paul B Mahol wrote: > On 1/18/17, Piotr Bandurski wrote: > > > > > > > LGTM applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: pass output stream duration as a hint to the muxer
On Tue, Jan 17, 2017 at 02:39:18PM +0100, Tobias Rapp wrote: > Signed-off-by: Tobias Rapp > --- > ffmpeg.c | 9 + > libavformat/avformat.h | 3 +++ > 2 files changed, 12 insertions(+) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264: simplify find_unused_picture()
On Wed, Jan 18, 2017 at 06:13:02PM +0100, Clément Bœsch wrote: > --- > libavcodec/h264_slice.c | 16 +++- > 1 file changed, 3 insertions(+), 13 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix bug of hlsenc http delete old segments
I test this patch, I found it show below log info and ffmpeg term auto.
av_interleaved_write_frame(): Too many open files
No more output streams to write to, finishing.
I think it is not OK.
Yin Jiaoyuan
At 2017-01-19 07:08:08, "Steven Liu" wrote:
>2017-01-17 14:28 GMT+08:00 Steven Liu :
>
>> when push hls to http server, the old segemnts can not delete by hls
>> formats.
>> so add the http option into hls_delete_old_segments
>>
>> Reported-by: Yin Jiaoyuan
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/hlsenc.c | 17 +++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index f02b887..87f7717 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -245,6 +245,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
>> int ret = 0, path_size, sub_path_size;
>> char *dirname = NULL, *p, *sub_path;
>> char *path = NULL;
>> +AVDictionary *options = NULL;
>> +AVIOContext *out = NULL;
>>
>> segment = hls->segments;
>> while (segment) {
>> @@ -294,7 +296,11 @@ static int hls_delete_old_segments(HLSContext *hls) {
>> av_strlcat(path, segment->filename, path_size);
>> }
>>
>> -if (unlink(path) < 0) {
>> +if (hls->method) {
>> +av_dict_set(&options, "method", "DELETE", 0);
>> +if ((ret = hls->avf->io_open(hls->avf, &out, path,
>> AVIO_FLAG_WRITE, &options)) < 0)
>> +goto fail;
>> +} else if (unlink(path) < 0) {
>> av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s:
>> %s\n",
>> path, strerror(errno));
>> }
>> @@ -309,7 +315,14 @@ static int hls_delete_old_segments(HLSContext *hls) {
>>
>> av_strlcpy(sub_path, dirname, sub_path_size);
>> av_strlcat(sub_path, segment->sub_filename, sub_path_size);
>> -if (unlink(sub_path) < 0) {
>> +
>> +if (hls->method) {
>> +av_dict_set(&options, "method", "DELETE", 0);
>> +if ((ret = hls->avf->io_open(hls->avf, &out, sub_path,
>> AVIO_FLAG_WRITE, &options)) < 0) {
>> +av_free(sub_path);
>> +goto fail;
>> +}
>> +} else if (unlink(sub_path) < 0) {
>> av_log(hls, AV_LOG_ERROR, "failed to delete old segment
>> %s: %s\n",
>> sub_path, strerror(errno));
>> }
>> --
>> 2.10.1.382.ga23ca1b.dirty
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>applied!
>
>
>Thanks
>___
>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] [FFmpeg-cvslog] avcodec/wmaprodec: >2 channel support for XMA
On Thu, Jan 19, 2017 at 12:44:38AM +0100, Paul B Mahol wrote: > ffmpeg | branch: master | Paul B Mahol | Tue Jan 17 > 15:54:57 2017 +0100| [6c43f33ac2e7606b2013f6261144389589394196] | committer: > Paul B Mahol > > avcodec/wmaprodec: >2 channel support for XMA > > Signed-off-by: Paul B Mahol > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6c43f33ac2e7606b2013f6261144389589394196 > --- > > libavcodec/wmaprodec.c | 274 > - > libavformat/wavdec.c | 3 + > 2 files changed, 204 insertions(+), 73 deletions(-) This causes an assertion failure: [xma2 @ 0x2093b40] get_buffer() failed [asf @ 0x2092500] packet fragment position invalid 0,0 not in 0 Last message repeated 1 times Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:265 Program received signal SIGABRT, Aborted. 0x701af035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt Python Exception No module named gdb.frames: #0 0x701af035 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x701b279b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00c4dc1e in get_bits (s=0x7fffec42eda0, n=0) at libavcodec/get_bits.h:265 #3 0x00c52e26 in decode_packet (avctx=0x2093b40, s=0x7fffec41e040, data=0x0, got_frame_ptr=0x7fffd6ac, avpkt=0x7fffd700) at libavcodec/wmaprodec.c:1627 #4 0x00c5333f in xma_decode_packet (avctx=0x2093b40, data=0x2094a80, got_frame_ptr=0x7fffd7f4, avpkt=0x7fffd700) at libavcodec/wmaprodec.c:1752 #5 0x00b444b9 in avcodec_decode_audio4 (avctx=0x2093b40, frame=0x2094a80, got_frame_ptr=0x7fffd7f4, avpkt=0x7fffd8b0) at libavcodec/utils.c:2363 #6 0x00b45ef3 in do_decode (avctx=0x2093b40, pkt=0x7fffd8b0) at libavcodec/utils.c:2794 #7 0x00b4629d in avcodec_send_packet (avctx=0x2093b40, avpkt=0x7fffd8b0) at libavcodec/utils.c:2878 #8 0x007582cb in try_decode_frame (s=0x2092500, st=0x20931a0, avpkt=0x7fffd9a0, options=0x2093160) at libavformat/utils.c:2983 #9 0x0075b12e in avformat_find_stream_info (ic=0x2092500, options=0x2093160) at libavformat/utils.c:3684 #10 0x0041ba23 in open_input_file (o=0x7fffde00, filename=0x7fffe6b2 "a.wma") at ffmpeg_opt.c:1021 #11 0x00425350 in open_files (l=0x2092318, inout=0x10bf117 "input", open_file=0x41b097 ) at ffmpeg_opt.c:3233 #12 0x004254d3 in ffmpeg_parse_options (argc=3, argv=0x7fffe408) at ffmpeg_opt.c:3273 #13 0x0043b047 in main (argc=3, argv=0x7fffe408) at ffmpeg.c:4566 [...9 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/avienc: write chained master index only if std_compliance is normal or below
On Wed, Jan 18, 2017 at 10:18:36AM +0100, Tobias Rapp wrote: > On 17.01.2017 19:10, Michael Niedermayer wrote: > >On Tue, Jan 17, 2017 at 02:44:28PM +0100, Tobias Rapp wrote: > >>On 13.01.2017 17:42, Michael Niedermayer wrote: > >>>On Tue, Jan 10, 2017 at 09:26:53AM +0100, Tobias Rapp wrote: > On 10.01.2017 00:19, Michael Niedermayer wrote: > >[...] > >isnt it better to warn the user and inform him at the end what size > >of reserved space would have been needed? > > > >not saying iam against this, i do see how it is formally correct to > >fail hard but it feels painfull to me to fail > >muxing at 256gb hard when we can perfectly fine just continue and > >the user can just remux the file with bigger reserved master index > >to fix it > > But then adding "-strict strict" just enables a warning message and > a non-compliant file is written still? Or do you mean that > additionally a warning message could be written in case > std_compliance is <= normal? > > Background story: I'm working on an application that fetches some > AVI file byte range from tape storage and restores the file header. > The header restoration requires the ODML master index in the header > to be complete. Thus I'd like to ensure that all AVI files put into > the archive have a compliant/compatible index structure. > > For such automated processes failing hard is more safe than > continuing with a warning message, checking for log messages in the > host application and possibly re-running the transcoding with > adapted options. > >>> > >>>whats your oppinion on an option that selects muxer error behavior ? > >>>something that can > >>>fail immedeatly on error or > >>>warn but continue, return failure after writing the file and trailer > >>> > >>>that is a option to make it possible for a muxer to continue even > >>>if there was an error, maybe even a int max_muxer_error or something > >>>else? > >> > > > >>You mean something like extending the current use of > >>error_recognition and AV_EF_EXPLODE to encoders/muxers? In general > > > >no, the semantic meaning is different > >recogniing errors in the input material and recognizing errors in the > >muxer "implementation" in relation to the used input or other are not > >the same thing. > >They may have different values, different defaults, and would have > >different explanation in the docs > > > >>it might be a good idea but I don't see how it helps in the current > >>case. > > > >well, it gives the user the option > >d) write a working file with chained master index and fail at trailer > >writing time to indicate that its not spec compliant but loose no > >data. The use case is anything that has non recoverable input, > >anything that cannot be re-run with a larger reserved space > > I agree this would be better e.g. when recording live data coming > from an input device. Would the indication be done by some special > return code "AV_PROBLEM_BUT_CONTINUE" on API level? Or maybe a > separate error reporting field/buffer within the AVFormatContext > struct? Trying to understand how it would integrate into the host > application (ffmpeg/other) ... what i was thinking about would when enabled not return an error before the end, but a AV_PROBLEM_BUT_CONTINUE would be an option too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/caf: add 'aacl' codec tag
On 1/18/17, Piotr Bandurski wrote: > > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/caf: add 'aacl' codec tag
On 1/19/17, Piotr Bandurski wrote: > Hi, > Have samples? Yes: www.megafileupload.com > www.megafileupload.com Regards > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Your mailer is broken, I can't dechiper links. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/caf: add 'aacl' codec tag
Hi, > Have samples? Yes: www.megafileupload.com www.megafileupload.com Regards ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avfilter:vf_drawtext: add new line space size set parameter
2017-01-18 6:24 GMT+08:00 Steven Liu :
> add line_spacing parameter to set the space between two lines
>
> Based on an idea by: Leandro Santiago
> Reviewed-by: Michael Niedermayer
> Signed-off-by: Steven Liu
> ---
> doc/filters.texi | 4
> libavfilter/vf_drawtext.c | 4 +++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 94548b1..a0c2980 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -6750,6 +6750,10 @@ option, check the "Color" section in the
> ffmpeg-utils manual.
>
> The default value of @var{boxcolor} is "white".
>
> +@item line_spacing
> +Set the line spacing in pixels of the border to be drawn around the box
> using @var{box}.
> +The default value of @var{line_spacing} is 0.
> +
> @item borderw
> Set the width of the border to be drawn around the text using
> @var{bordercolor}.
> The default value of @var{borderw} is 0.
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index 649240b..d8f7730 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -158,6 +158,7 @@ typedef struct DrawTextContext {
> int borderw;///< border width
> unsigned int fontsize; ///< font size to use
>
> +int line_spacing; ///< lines spacing in pixels
> short int draw_box; ///< draw box around text - true or
> false
> int boxborderw; ///< box border width
> int use_kerning;///< font kerning is used - true/false
> @@ -209,6 +210,7 @@ static const AVOption drawtext_options[]= {
> {"shadowcolor", "set shadow color", OFFSET(shadowcolor.rgba),
> AV_OPT_TYPE_COLOR, {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
> {"box", "set box", OFFSET(draw_box),
> AV_OPT_TYPE_BOOL, {.i64=0}, 0,1 , FLAGS},
> {"boxborderw", "set box border width", OFFSET(boxborderw),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
> +{"line_spacing", "set line spacing in pixels",
> OFFSET(line_spacing), AV_OPT_TYPE_INT,{.i64=0}, INT_MIN,
> INT_MAX,FLAGS},
> {"fontsize","set font size",OFFSET(fontsize),
> AV_OPT_TYPE_INT,{.i64=0}, 0,INT_MAX , FLAGS},
> {"x", "set x expression", OFFSET(x_expr),
> AV_OPT_TYPE_STRING, {.str="0"}, CHAR_MIN, CHAR_MAX, FLAGS},
> {"y", "set y expression", OFFSET(y_expr),
> AV_OPT_TYPE_STRING, {.str="0"}, CHAR_MIN, CHAR_MAX, FLAGS},
> @@ -1250,7 +1252,7 @@ static int draw_text(AVFilterContext *ctx, AVFrame
> *frame,
> if (is_newline(code)) {
>
> max_text_line_w = FFMAX(max_text_line_w, x);
> -y += s->max_glyph_h;
> +y += s->max_glyph_h + s->line_spacing;
> x = 0;
> continue;
> }
> --
> 2.10.1.382.ga23ca1b.dirty
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
pushed!
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix bug of hlsenc http delete old segments
2017-01-17 14:28 GMT+08:00 Steven Liu :
> when push hls to http server, the old segemnts can not delete by hls
> formats.
> so add the http option into hls_delete_old_segments
>
> Reported-by: Yin Jiaoyuan
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index f02b887..87f7717 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -245,6 +245,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
> int ret = 0, path_size, sub_path_size;
> char *dirname = NULL, *p, *sub_path;
> char *path = NULL;
> +AVDictionary *options = NULL;
> +AVIOContext *out = NULL;
>
> segment = hls->segments;
> while (segment) {
> @@ -294,7 +296,11 @@ static int hls_delete_old_segments(HLSContext *hls) {
> av_strlcat(path, segment->filename, path_size);
> }
>
> -if (unlink(path) < 0) {
> +if (hls->method) {
> +av_dict_set(&options, "method", "DELETE", 0);
> +if ((ret = hls->avf->io_open(hls->avf, &out, path,
> AVIO_FLAG_WRITE, &options)) < 0)
> +goto fail;
> +} else if (unlink(path) < 0) {
> av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s:
> %s\n",
> path, strerror(errno));
> }
> @@ -309,7 +315,14 @@ static int hls_delete_old_segments(HLSContext *hls) {
>
> av_strlcpy(sub_path, dirname, sub_path_size);
> av_strlcat(sub_path, segment->sub_filename, sub_path_size);
> -if (unlink(sub_path) < 0) {
> +
> +if (hls->method) {
> +av_dict_set(&options, "method", "DELETE", 0);
> +if ((ret = hls->avf->io_open(hls->avf, &out, sub_path,
> AVIO_FLAG_WRITE, &options)) < 0) {
> +av_free(sub_path);
> +goto fail;
> +}
> +} else if (unlink(sub_path) < 0) {
> av_log(hls, AV_LOG_ERROR, "failed to delete old segment
> %s: %s\n",
> sub_path, strerror(errno));
> }
> --
> 2.10.1.382.ga23ca1b.dirty
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
applied!
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c Reduce initialization time for gpu id > 0
Made this into a patch: https://github.com/BtbN/FFmpeg/commit/cbd128a67fc4621c953419dddc5cc17612764a57 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/8] arm: Add NEON optimizations for 10 and 12 bit vp9 loop filter
This work is sponsored by, and copyright, Google.
This is pretty much similar to the 8 bpp version, but in some senses
simpler. All input pixels are 16 bits, and all intermediates also fit
in 16 bits, so there's no lengthening/narrowing in the filter at all.
For the full 16 pixel wide filter, we can only process 4 pixels at a time
(using an implementation very much similar to the one for 8 bpp),
but we can do 8 pixels at a time for the 4 and 8 pixel wide filters with
a different implementation of the core filter.
Examples of relative speedup compared to the C version, from checkasm:
CortexA7 A8 A9A53
vp9_loop_filter_h_4_8_10bpp_neon: 1.83 2.16 1.40 2.09
vp9_loop_filter_h_8_8_10bpp_neon: 1.39 1.67 1.24 1.70
vp9_loop_filter_h_16_8_10bpp_neon: 1.56 1.47 1.10 1.81
vp9_loop_filter_h_16_16_10bpp_neon:1.94 1.69 1.33 2.24
vp9_loop_filter_mix2_h_44_16_10bpp_neon: 2.01 2.27 1.67 2.39
vp9_loop_filter_mix2_h_48_16_10bpp_neon: 1.84 2.06 1.45 2.19
vp9_loop_filter_mix2_h_84_16_10bpp_neon: 1.89 2.20 1.47 2.29
vp9_loop_filter_mix2_h_88_16_10bpp_neon: 1.69 2.12 1.47 2.08
vp9_loop_filter_mix2_v_44_16_10bpp_neon: 3.16 3.98 2.50 4.05
vp9_loop_filter_mix2_v_48_16_10bpp_neon: 2.84 3.64 2.25 3.77
vp9_loop_filter_mix2_v_84_16_10bpp_neon: 2.65 3.45 2.16 3.54
vp9_loop_filter_mix2_v_88_16_10bpp_neon: 2.55 3.30 2.16 3.55
vp9_loop_filter_v_4_8_10bpp_neon: 2.85 3.97 2.24 3.68
vp9_loop_filter_v_8_8_10bpp_neon: 2.27 3.19 1.96 3.08
vp9_loop_filter_v_16_8_10bpp_neon: 3.42 2.74 2.26 4.40
vp9_loop_filter_v_16_16_10bpp_neon:2.86 2.44 1.93 3.88
The speedup vs C code measured in checkasm is around 1.1-4x.
These numbers are quite inconclusive though, since the checkasm test
runs multiple filterings on top of each other, so later rounds might
end up with different codepaths (different decisions on which filter
to apply, based on input pixel differences).
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 2-4x.
---
libavcodec/arm/Makefile |1 +
libavcodec/arm/vp9dsp_init_16bpp_arm_template.c | 62 ++
libavcodec/arm/vp9lpf_16bpp_neon.S | 1044 +++
3 files changed, 1107 insertions(+)
create mode 100644 libavcodec/arm/vp9lpf_16bpp_neon.S
diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 856c154..1eeac54 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -144,6 +144,7 @@ NEON-OBJS-$(CONFIG_VORBIS_DECODER) +=
arm/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP6_DECODER)+= arm/vp6dsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER)+= arm/vp9itxfm_16bpp_neon.o \
arm/vp9itxfm_neon.o \
+ arm/vp9lpf_16bpp_neon.o \
arm/vp9lpf_neon.o \
arm/vp9mc_16bpp_neon.o\
arm/vp9mc_neon.o
diff --git a/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
b/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
index 95f2bbc..3620535 100644
--- a/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
+++ b/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c
@@ -187,8 +187,70 @@ static av_cold void vp9dsp_itxfm_init_arm(VP9DSPContext
*dsp)
}
}
+#define define_loop_filter(dir, wd, size, bpp) \
+void ff_vp9_loop_filter_##dir##_##wd##_##size##_##bpp##_neon(uint8_t *dst,
ptrdiff_t stride, int E, int I, int H)
+
+#define define_loop_filters(wd, size, bpp) \
+define_loop_filter(h, wd, size, bpp); \
+define_loop_filter(v, wd, size, bpp)
+
+define_loop_filters(4, 8, BPP);
+define_loop_filters(8, 8, BPP);
+define_loop_filters(16, 8, BPP);
+
+define_loop_filters(16, 16, BPP);
+
+define_loop_filters(44, 16, BPP);
+define_loop_filters(48, 16, BPP);
+define_loop_filters(84, 16, BPP);
+define_loop_filters(88, 16, BPP);
+
+static av_cold void vp9dsp_loopfilter_init_arm(VP9DSPContext *dsp)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+#define init_lpf_func_8(idx1, idx2, dir, wd, bpp) \
+dsp->loop_filter_8[idx1][idx2] =
ff_vp9_loop_filter_##dir##_##wd##_8_##bpp##_neon
+
+#define init_lpf_func_16(idx, dir, bpp) \
+dsp->loop_filter_16[idx] = ff_vp9_loop_filter_##dir##_16_16_##bpp##_neon
+
+#define init_lpf_func_mix2(idx1, idx2, idx3, dir, wd, bpp) \
+dsp->loop_filter_mix2[idx1][idx2][idx3] =
ff_vp9_loop_filter_##dir##_##wd##_16_##bpp##_neon
+
+#define init_lpf_funcs_8_wd(idx, wd, bpp) \
+init_lpf_func_8(idx, 0, h, wd, bpp); \
+init_lpf_func_8(idx, 1, v, wd, bpp)
+
+#define init_lpf_funcs_16(bpp) \
+init_lpf_func_16(0, h, bpp); \
+init_lpf_func_16(1, v, bpp)
+
+#define init_lpf_funcs_mi
[FFmpeg-devel] [PATCH 1/8] arm: vp9dsp: Restructure the bpp checks
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
---
libavcodec/arm/vp9dsp_init_arm.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/libavcodec/arm/vp9dsp_init_arm.c b/libavcodec/arm/vp9dsp_init_arm.c
index 05e50d7..0b76eb1 100644
--- a/libavcodec/arm/vp9dsp_init_arm.c
+++ b/libavcodec/arm/vp9dsp_init_arm.c
@@ -94,13 +94,10 @@ define_8tap_2d_funcs(8)
define_8tap_2d_funcs(4)
-static av_cold void vp9dsp_mc_init_arm(VP9DSPContext *dsp, int bpp)
+static av_cold void vp9dsp_mc_init_arm(VP9DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-if (bpp != 8)
-return;
-
if (have_neon(cpu_flags)) {
#define init_fpel(idx1, idx2, sz, type) \
dsp->mc[idx1][FILTER_8TAP_SMOOTH ][idx2][0][0] = \
@@ -160,13 +157,10 @@ define_itxfm(idct, idct, 32);
define_itxfm(iwht, iwht, 4);
-static av_cold void vp9dsp_itxfm_init_arm(VP9DSPContext *dsp, int bpp)
+static av_cold void vp9dsp_itxfm_init_arm(VP9DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-if (bpp != 8)
-return;
-
if (have_neon(cpu_flags)) {
#define init_itxfm(tx, sz) \
dsp->itxfm_add[tx][DCT_DCT] = ff_vp9_idct_idct_##sz##_add_neon; \
@@ -218,13 +212,10 @@ lf_mix_fns(4, 8)
lf_mix_fns(8, 4)
lf_mix_fns(8, 8)
-static av_cold void vp9dsp_loopfilter_init_arm(VP9DSPContext *dsp, int bpp)
+static av_cold void vp9dsp_loopfilter_init_arm(VP9DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-if (bpp != 8)
-return;
-
if (have_neon(cpu_flags)) {
dsp->loop_filter_8[0][1] = ff_vp9_loop_filter_v_4_8_neon;
dsp->loop_filter_8[0][0] = ff_vp9_loop_filter_h_4_8_neon;
@@ -249,7 +240,10 @@ static av_cold void
vp9dsp_loopfilter_init_arm(VP9DSPContext *dsp, int bpp)
av_cold void ff_vp9dsp_init_arm(VP9DSPContext *dsp, int bpp)
{
-vp9dsp_mc_init_arm(dsp, bpp);
-vp9dsp_loopfilter_init_arm(dsp, bpp);
-vp9dsp_itxfm_init_arm(dsp, bpp);
+if (bpp != 8)
+return;
+
+vp9dsp_mc_init_arm(dsp);
+vp9dsp_loopfilter_init_arm(dsp);
+vp9dsp_itxfm_init_arm(dsp);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/8] aarch64: Add NEON optimizations for 10 and 12 bit vp9 MC
This work is sponsored by, and copyright, Google. This has mostly got the same differences to the 8 bit version as in the arm version. For the horizontal filters, we do 16 pixels in parallel as well. For the 8 pixel wide vertical filters, we can accumulate 4 rows before storing, just as in the 8 bit version. Examples of runtimes vs the 32 bit version, on a Cortex A53: ARM AArch64 vp9_avg4_10bpp_neon: 35.7 30.7 vp9_avg8_10bpp_neon: 93.5 84.7 vp9_avg16_10bpp_neon:324.4 296.6 vp9_avg32_10bpp_neon: 1236.51148.2 vp9_avg64_10bpp_neon: 4639.64571.1 vp9_avg_8tap_smooth_4h_10bpp_neon: 130.0 128.0 vp9_avg_8tap_smooth_4hv_10bpp_neon: 440.0 440.5 vp9_avg_8tap_smooth_4v_10bpp_neon: 114.0 105.5 vp9_avg_8tap_smooth_8h_10bpp_neon: 327.0 314.0 vp9_avg_8tap_smooth_8hv_10bpp_neon: 918.7 865.4 vp9_avg_8tap_smooth_8v_10bpp_neon: 330.0 300.2 vp9_avg_8tap_smooth_16h_10bpp_neon: 1187.51155.5 vp9_avg_8tap_smooth_16hv_10bpp_neon:2663.12591.0 vp9_avg_8tap_smooth_16v_10bpp_neon: 1107.41078.3 vp9_avg_8tap_smooth_64h_10bpp_neon:17754.6 17454.7 vp9_avg_8tap_smooth_64hv_10bpp_neon: 33285.2 33001.5 vp9_avg_8tap_smooth_64v_10bpp_neon:16066.9 16048.6 vp9_put4_10bpp_neon: 25.5 21.7 vp9_put8_10bpp_neon: 56.0 52.0 vp9_put16_10bpp_neon/armv8: 183.0 163.1 vp9_put32_10bpp_neon/armv8: 678.6 563.1 vp9_put64_10bpp_neon/armv8: 2679.92195.8 vp9_put_8tap_smooth_4h_10bpp_neon: 120.0 118.0 vp9_put_8tap_smooth_4hv_10bpp_neon: 435.2 435.0 vp9_put_8tap_smooth_4v_10bpp_neon: 107.0 98.2 vp9_put_8tap_smooth_8h_10bpp_neon: 303.0 290.0 vp9_put_8tap_smooth_8hv_10bpp_neon: 893.7 828.7 vp9_put_8tap_smooth_8v_10bpp_neon: 305.5 263.5 vp9_put_8tap_smooth_16h_10bpp_neon: 1089.11059.2 vp9_put_8tap_smooth_16hv_10bpp_neon:2578.82452.4 vp9_put_8tap_smooth_16v_10bpp_neon: 1009.5 933.5 vp9_put_8tap_smooth_64h_10bpp_neon:16223.4 15918.6 vp9_put_8tap_smooth_64hv_10bpp_neon: 32153.0 31016.2 vp9_put_8tap_smooth_64v_10bpp_neon:14516.5 13748.1 These are generally about as fast as the corresponding ARM routines on the same CPU (at least on the A53), in most cases marginally faster. The speedup vs C code is around 4-9x. --- libavcodec/aarch64/Makefile| 5 +- libavcodec/aarch64/vp9dsp_init.h | 29 + libavcodec/aarch64/vp9dsp_init_10bpp_aarch64.c | 23 + libavcodec/aarch64/vp9dsp_init_12bpp_aarch64.c | 23 + .../aarch64/vp9dsp_init_16bpp_aarch64_template.c | 163 ++ libavcodec/aarch64/vp9dsp_init_aarch64.c | 9 +- libavcodec/aarch64/vp9mc_16bpp_neon.S | 631 + 7 files changed, 881 insertions(+), 2 deletions(-) create mode 100644 libavcodec/aarch64/vp9dsp_init.h create mode 100644 libavcodec/aarch64/vp9dsp_init_10bpp_aarch64.c create mode 100644 libavcodec/aarch64/vp9dsp_init_12bpp_aarch64.c create mode 100644 libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c create mode 100644 libavcodec/aarch64/vp9mc_16bpp_neon.S diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile index 5593863..0766e90 100644 --- a/libavcodec/aarch64/Makefile +++ b/libavcodec/aarch64/Makefile @@ -15,7 +15,9 @@ OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_init.o OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o OBJS-$(CONFIG_VC1DSP) += aarch64/vc1dsp_init_aarch64.o OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_init.o -OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9dsp_init_aarch64.o +OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9dsp_init_10bpp_aarch64.o \ + aarch64/vp9dsp_init_12bpp_aarch64.o \ + aarch64/vp9dsp_init_aarch64.o # ARMv8 optimizations @@ -42,4 +44,5 @@ NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_neon.o \ aarch64/vp9lpf_neon.o \ + aarch64/vp9mc_16bpp_neon.o \ aarch64/vp9mc_neon.o diff --git a/libavcodec/aarch64/vp9dsp_init.h b/libavcodec/aarch64/vp9dsp_init.h new file mode 100644 index 000..9df1752 --- /dev/null +++ b/libavcodec/aarch64/vp9dsp_init.h @@ -0,0 +1,29 @@ +/* + * Copyright (c) 2017 Google Inc. + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or
[FFmpeg-devel] [PATCH 7/8] aarch64: Add NEON optimizations for 10 and 12 bit vp9 itxfm
This work is sponsored by, and copyright, Google.
Compared to the arm version, on aarch64 we can keep the full 8x8
transform in registers, and for 16x16 and 32x32, we can process
it in slices of 4 pixels instead of 2.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_sub4_add_10_neon: 111.0109.7
vp9_inv_adst_adst_8x8_sub8_add_10_neon: 914.0733.5
vp9_inv_adst_adst_16x16_sub16_add_10_neon: 5184.0 3745.7
vp9_inv_dct_dct_4x4_sub1_add_10_neon: 65.0 65.7
vp9_inv_dct_dct_4x4_sub4_add_10_neon: 100.0 96.7
vp9_inv_dct_dct_8x8_sub1_add_10_neon: 111.0119.7
vp9_inv_dct_dct_8x8_sub8_add_10_neon: 618.0494.7
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 295.1284.6
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 2303.2 1883.9
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 2984.8 2189.3
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 3890.0 2799.4
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1044.4 1012.7
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 1.7 9695.1
vp9_inv_dct_dct_32x32_sub16_add_10_neon:18531.3 12459.8
vp9_inv_dct_dct_32x32_sub32_add_10_neon:24470.7 16160.2
vp9_inv_wht_wht_4x4_sub4_add_10_neon: 83.0 79.7
The larger transforms are significantly faster than the corresponding
ARM versions.
The speedup vs C code is smaller than in 32 bit mode, probably
because the 64 bit intermediates in the C code can be expressed
more efficiently in aarch64.
---
libavcodec/aarch64/Makefile|3 +-
.../aarch64/vp9dsp_init_16bpp_aarch64_template.c | 47 +
libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 1517
3 files changed, 1566 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/vp9itxfm_16bpp_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 0766e90..715cc6f 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -42,7 +42,8 @@ NEON-OBJS-$(CONFIG_MPEGAUDIODSP)+=
aarch64/mpegaudiodsp_neon.o
# decoders/encoders
NEON-OBJS-$(CONFIG_DCA_DECODER) += aarch64/synth_filter_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
-NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_neon.o
\
+NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o
\
+ aarch64/vp9itxfm_neon.o
\
aarch64/vp9lpf_neon.o
\
aarch64/vp9mc_16bpp_neon.o
\
aarch64/vp9mc_neon.o
diff --git a/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
b/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
index 4719ea3..0e86b02 100644
--- a/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
+++ b/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
@@ -157,7 +157,54 @@ static av_cold void vp9dsp_mc_init_aarch64(VP9DSPContext
*dsp)
}
}
+#define define_itxfm2(type_a, type_b, sz, bpp)
\
+void ff_vp9_##type_a##_##type_b##_##sz##x##sz##_add_##bpp##_neon(uint8_t
*_dst,\
+ ptrdiff_t
stride, \
+ int16_t
*_block, int eob)
+#define define_itxfm(type_a, type_b, sz, bpp) define_itxfm2(type_a, type_b,
sz, bpp)
+
+#define define_itxfm_funcs(sz, bpp) \
+define_itxfm(idct, idct, sz, bpp); \
+define_itxfm(iadst, idct, sz, bpp); \
+define_itxfm(idct, iadst, sz, bpp); \
+define_itxfm(iadst, iadst, sz, bpp)
+
+define_itxfm_funcs(4, BPP);
+define_itxfm_funcs(8, BPP);
+define_itxfm_funcs(16, BPP);
+define_itxfm(idct, idct, 32, BPP);
+define_itxfm(iwht, iwht, 4, BPP);
+
+
+static av_cold void vp9dsp_itxfm_init_aarch64(VP9DSPContext *dsp)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+#define init_itxfm2(tx, sz, bpp)
\
+dsp->itxfm_add[tx][DCT_DCT] = ff_vp9_idct_idct_##sz##_add_##bpp##_neon;
\
+dsp->itxfm_add[tx][DCT_ADST] = ff_vp9_iadst_idct_##sz##_add_##bpp##_neon;
\
+dsp->itxfm_add[tx][ADST_DCT] = ff_vp9_idct_iadst_##sz##_add_##bpp##_neon;
\
+dsp->itxfm_add[tx][ADST_ADST] = ff_vp9_iadst_iadst_##sz##_add_##bpp##_neon
+#define init_itxfm(tx, sz, bpp) init_itxfm2(tx, sz, bpp)
+
+#define init_idct2(tx, nm, bpp) \
+dsp->itxfm_add[tx][DCT_DCT] = \
+dsp->itxfm_add[tx][ADST_DCT] = \
+dsp->itxfm_add[tx][DCT_ADST] = \
+dsp->itxfm_add[tx][ADST_ADST] = ff_vp9_##nm##_add_##bpp##_neon
+#define init_idct(tx, nm, bpp) init_idct2(tx, nm, bpp)
+
+init_itxfm(TX_4X4, 4x4, BPP);
+init_itxfm(TX_8X8, 8x8, BPP);
+init_itxfm(TX_1
[FFmpeg-devel] [PATCH 3/8] arm: Add NEON optimizations for 10 and 12 bit vp9 itxfm
This work is sponsored by, and copyright, Google. This is structured similarly to the 8 bit version. In the 8 bit version, the coefficients are 16 bits, and intermediates are 32 bits. Here, the coefficients are 32 bit. For the 4x4 transforms for 10 bit content, the intermediates also fit in 32 bits, but for all other transforms (4x4 for 12 bit content, and 8x8 and larger for both 10 and 12 bit) the intermediates are 64 bit. For the existing 8 bit case, the 8x8 transform fit all coefficients in registers; for 10/12 bit, when the coefficients are 32 bit, the 8x8 transform also has to be done in slices of 4 pixels (just as 16x16 and 32x32 for 8 bit). The slice width also shrinks from 4 elements to 2 elements in parallel for the 16x16 and 32x32 cases. The 16 bit coefficients from idct_coeffs and similar tables also need to be lenghtened to 32 bit in order to be used in multiplication with vectors with 32 bit elements. This leads to the fixed coefficient vectors needing more space, leading to more cases where they have to be reloaded within the transform (in iadst16). This technically would need testing in checkasm for subpartitions in increments of 2, but that slows down normal checkasm runs excessively. Examples of relative speedup compared to the C version, from checkasm: CortexA7 A8 A9A53 vp9_inv_adst_adst_4x4_sub4_add_10_neon: 4.83 11.36 5.22 6.77 vp9_inv_adst_adst_8x8_sub8_add_10_neon: 4.12 7.60 4.06 4.84 vp9_inv_adst_adst_16x16_sub16_add_10_neon: 3.93 8.16 4.52 5.35 vp9_inv_dct_dct_4x4_sub1_add_10_neon:1.36 2.57 1.41 1.61 vp9_inv_dct_dct_4x4_sub4_add_10_neon:4.24 8.66 5.06 5.81 vp9_inv_dct_dct_8x8_sub1_add_10_neon:2.63 4.18 1.68 2.87 vp9_inv_dct_dct_8x8_sub4_add_10_neon:4.52 9.47 4.24 5.39 vp9_inv_dct_dct_8x8_sub8_add_10_neon:3.45 7.34 3.45 4.30 vp9_inv_dct_dct_16x16_sub1_add_10_neon: 3.56 6.21 2.47 4.32 vp9_inv_dct_dct_16x16_sub2_add_10_neon: 5.68 12.73 5.28 7.07 vp9_inv_dct_dct_16x16_sub8_add_10_neon: 4.42 9.28 4.24 5.45 vp9_inv_dct_dct_16x16_sub16_add_10_neon: 3.41 7.29 3.35 4.19 vp9_inv_dct_dct_32x32_sub1_add_10_neon: 4.52 8.35 3.83 6.40 vp9_inv_dct_dct_32x32_sub2_add_10_neon: 5.86 13.19 6.14 7.04 vp9_inv_dct_dct_32x32_sub16_add_10_neon: 4.29 8.11 4.59 5.06 vp9_inv_dct_dct_32x32_sub32_add_10_neon: 3.31 5.70 3.56 3.84 vp9_inv_wht_wht_4x4_sub4_add_10_neon:1.89 2.80 1.82 1.97 The speedup compared to the C functions is around 1.3 to 7x for the full transforms, even higher for the smaller subpartitions. --- libavcodec/arm/Makefile |3 +- libavcodec/arm/vp9dsp_init_16bpp_arm_template.c | 47 + libavcodec/arm/vp9itxfm_16bpp_neon.S| 1515 +++ 3 files changed, 1564 insertions(+), 1 deletion(-) create mode 100644 libavcodec/arm/vp9itxfm_16bpp_neon.S diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile index fb35d25..856c154 100644 --- a/libavcodec/arm/Makefile +++ b/libavcodec/arm/Makefile @@ -142,7 +142,8 @@ NEON-OBJS-$(CONFIG_RV40_DECODER) += arm/rv34dsp_neon.o\ arm/rv40dsp_neon.o NEON-OBJS-$(CONFIG_VORBIS_DECODER) += arm/vorbisdsp_neon.o NEON-OBJS-$(CONFIG_VP6_DECODER)+= arm/vp6dsp_neon.o -NEON-OBJS-$(CONFIG_VP9_DECODER)+= arm/vp9itxfm_neon.o \ +NEON-OBJS-$(CONFIG_VP9_DECODER)+= arm/vp9itxfm_16bpp_neon.o \ + arm/vp9itxfm_neon.o \ arm/vp9lpf_neon.o \ arm/vp9mc_16bpp_neon.o\ arm/vp9mc_neon.o diff --git a/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c b/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c index 05efd29..95f2bbc 100644 --- a/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c +++ b/libavcodec/arm/vp9dsp_init_16bpp_arm_template.c @@ -141,7 +141,54 @@ static av_cold void vp9dsp_mc_init_arm(VP9DSPContext *dsp) } } +#define define_itxfm2(type_a, type_b, sz, bpp) \ +void ff_vp9_##type_a##_##type_b##_##sz##x##sz##_add_##bpp##_neon(uint8_t *_dst,\ + ptrdiff_t stride, \ + int16_t *_block, int eob) +#define define_itxfm(type_a, type_b, sz, bpp) define_itxfm2(type_a, type_b, sz, bpp) + +#define define_itxfm_funcs(sz, bpp) \ +define_itxfm(idct, idct, sz, bpp); \ +define_itxfm(iadst, idct, sz, bpp); \ +define_itxfm(idct, iadst, sz, bpp); \ +define_itxfm(iadst, iadst, sz, bpp) + +define_itxfm_funcs(4, BPP); +define_itxfm_funcs(8, BPP); +define_itxfm_funcs(16, BPP); +define_itxfm(idct,
[FFmpeg-devel] [PATCH 8/8] aarch64: Add NEON optimizations for 10 and 12 bit vp9 loop filter
This work is sponsored by, and copyright, Google.
This is similar to the arm version, but due to the larger registers
on aarch64, we can do 8 pixels at a time for all filter sizes.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_10bpp_neon: 213.2 172.6
vp9_loop_filter_h_8_8_10bpp_neon: 281.2 244.2
vp9_loop_filter_h_16_8_10bpp_neon: 657.0 444.5
vp9_loop_filter_h_16_16_10bpp_neon: 1280.4 877.7
vp9_loop_filter_mix2_h_44_16_10bpp_neon: 397.7 358.0
vp9_loop_filter_mix2_h_48_16_10bpp_neon: 465.7 429.0
vp9_loop_filter_mix2_h_84_16_10bpp_neon: 465.7 428.0
vp9_loop_filter_mix2_h_88_16_10bpp_neon: 533.7 499.0
vp9_loop_filter_mix2_v_44_16_10bpp_neon: 271.5 244.0
vp9_loop_filter_mix2_v_48_16_10bpp_neon: 330.0 305.0
vp9_loop_filter_mix2_v_84_16_10bpp_neon: 329.0 306.0
vp9_loop_filter_mix2_v_88_16_10bpp_neon: 386.0 365.0
vp9_loop_filter_v_4_8_10bpp_neon: 150.0 115.2
vp9_loop_filter_v_8_8_10bpp_neon: 209.0 175.5
vp9_loop_filter_v_16_8_10bpp_neon: 492.7 345.2
vp9_loop_filter_v_16_16_10bpp_neon:951.0 682.7
This is significantly faster than the ARM version in almost
all cases except for the mix2 functions.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 2-3x.
---
libavcodec/aarch64/Makefile| 1 +
.../aarch64/vp9dsp_init_16bpp_aarch64_template.c | 62 ++
libavcodec/aarch64/vp9lpf_16bpp_neon.S | 873 +
3 files changed, 936 insertions(+)
create mode 100644 libavcodec/aarch64/vp9lpf_16bpp_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 715cc6f..37666b4 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -44,6 +44,7 @@ NEON-OBJS-$(CONFIG_DCA_DECODER) +=
aarch64/synth_filter_neon.o
NEON-OBJS-$(CONFIG_VORBIS_DECODER) += aarch64/vorbisdsp_neon.o
NEON-OBJS-$(CONFIG_VP9_DECODER) += aarch64/vp9itxfm_16bpp_neon.o
\
aarch64/vp9itxfm_neon.o
\
+ aarch64/vp9lpf_16bpp_neon.o
\
aarch64/vp9lpf_neon.o
\
aarch64/vp9mc_16bpp_neon.o
\
aarch64/vp9mc_neon.o
diff --git a/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
b/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
index 0e86b02..d5649f7 100644
--- a/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
+++ b/libavcodec/aarch64/vp9dsp_init_16bpp_aarch64_template.c
@@ -203,8 +203,70 @@ static av_cold void
vp9dsp_itxfm_init_aarch64(VP9DSPContext *dsp)
}
}
+#define define_loop_filter(dir, wd, size, bpp) \
+void ff_vp9_loop_filter_##dir##_##wd##_##size##_##bpp##_neon(uint8_t *dst,
ptrdiff_t stride, int E, int I, int H)
+
+#define define_loop_filters(wd, size, bpp) \
+define_loop_filter(h, wd, size, bpp); \
+define_loop_filter(v, wd, size, bpp)
+
+define_loop_filters(4, 8, BPP);
+define_loop_filters(8, 8, BPP);
+define_loop_filters(16, 8, BPP);
+
+define_loop_filters(16, 16, BPP);
+
+define_loop_filters(44, 16, BPP);
+define_loop_filters(48, 16, BPP);
+define_loop_filters(84, 16, BPP);
+define_loop_filters(88, 16, BPP);
+
+static av_cold void vp9dsp_loopfilter_init_aarch64(VP9DSPContext *dsp)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+#define init_lpf_func_8(idx1, idx2, dir, wd, bpp) \
+dsp->loop_filter_8[idx1][idx2] =
ff_vp9_loop_filter_##dir##_##wd##_8_##bpp##_neon
+
+#define init_lpf_func_16(idx, dir, bpp) \
+dsp->loop_filter_16[idx] = ff_vp9_loop_filter_##dir##_16_16_##bpp##_neon
+
+#define init_lpf_func_mix2(idx1, idx2, idx3, dir, wd, bpp) \
+dsp->loop_filter_mix2[idx1][idx2][idx3] =
ff_vp9_loop_filter_##dir##_##wd##_16_##bpp##_neon
+
+#define init_lpf_funcs_8_wd(idx, wd, bpp) \
+init_lpf_func_8(idx, 0, h, wd, bpp); \
+init_lpf_func_8(idx, 1, v, wd, bpp)
+
+#define init_lpf_funcs_16(bpp) \
+init_lpf_func_16(0, h, bpp); \
+init_lpf_func_16(1, v, bpp)
+
+#define init_lpf_funcs_mix2_wd(idx1, idx2, wd, bpp) \
+init_lpf_func_mix2(idx1, idx2, 0, h, wd, bpp); \
+init_lpf_func_mix2(idx1, idx2, 1, v, wd, bpp)
+
+#define init_lpf_funcs_8(bpp)\
+init_lpf_funcs_8_wd(0, 4, bpp); \
+init_lpf_funcs_8_wd(1, 8, bpp); \
+init_lpf_funcs_8_wd(2, 16, bpp)
+
+#define init_lpf_funcs_mix2(bpp) \
+init_lpf_funcs_mix2_wd(0, 0, 44, bpp); \
+init_lpf_funcs_mix2_wd(0, 1, 48, bpp); \
+init_lpf_funcs_mix2_wd(1, 0, 84, bpp); \
+init_lpf_funcs_mix2_wd(1, 1, 88, bpp)
+
+init_lpf_funcs_8(BPP);
+init_lpf_funcs_16(BPP);
+init_lpf_funcs_mix2(BPP);
+}
+}
+
av_co
[FFmpeg-devel] [PATCH 2/8] arm: Add NEON optimizations for 10 and 12 bit vp9 MC
This work is sponsored by, and copyright, Google. The plain pixel put/copy functions are used from the 8 bit version, for the double size (e.g. put16 uses ff_vp9_copy32_neon), and a new copy128 is added. Compared with the 8 bit version, the filters can no longer use the trick to accumulate in 16 bit with only saturation at the end, but now the accumulators need to be 32 bit. This avoids the need to keep track of which filter index is the largest though, reducing the size of the executable code for these filters. For the horizontal filters, we only do 4 or 8 pixels wide in parallel (while doing two rows at a time), since we don't have enough register space to filter 16 pixels wide. For the vertical filters, we still do 4 and 8 pixels in parallel just as in the 8 bit case, but we need to store the output after every 2 rows instead of after every 4 rows. Examples of relative speedup compared to the C version, from checkasm: CortexA7 A8 A9A53 vp9_avg4_10bpp_neon: 2.25 2.44 3.05 2.16 vp9_avg8_10bpp_neon: 3.66 8.48 3.86 3.50 vp9_avg16_10bpp_neon: 3.39 8.26 3.37 2.72 vp9_avg32_10bpp_neon: 4.03 10.20 4.07 3.42 vp9_avg64_10bpp_neon: 4.15 10.01 4.13 3.70 vp9_avg_8tap_smooth_4h_10bpp_neon: 3.38 6.22 3.41 4.75 vp9_avg_8tap_smooth_4hv_10bpp_neon:3.89 6.39 4.30 5.32 vp9_avg_8tap_smooth_4v_10bpp_neon: 5.32 9.73 6.34 7.31 vp9_avg_8tap_smooth_8h_10bpp_neon: 4.45 9.40 4.68 6.87 vp9_avg_8tap_smooth_8hv_10bpp_neon:4.64 8.91 5.44 6.47 vp9_avg_8tap_smooth_8v_10bpp_neon: 6.44 13.42 8.68 8.79 vp9_avg_8tap_smooth_64h_10bpp_neon:4.66 9.02 4.84 7.71 vp9_avg_8tap_smooth_64hv_10bpp_neon: 4.61 9.14 4.92 7.10 vp9_avg_8tap_smooth_64v_10bpp_neon:6.90 14.13 9.57 10.41 vp9_put4_10bpp_neon: 1.33 1.46 2.09 1.33 vp9_put8_10bpp_neon: 1.57 3.42 1.83 1.84 vp9_put16_10bpp_neon: 1.55 4.78 2.17 1.89 vp9_put32_10bpp_neon: 2.06 5.35 2.14 2.30 vp9_put64_10bpp_neon: 3.00 2.41 1.95 1.66 vp9_put_8tap_smooth_4h_10bpp_neon: 3.19 5.81 3.31 4.63 vp9_put_8tap_smooth_4hv_10bpp_neon:3.86 6.22 4.32 5.21 vp9_put_8tap_smooth_4v_10bpp_neon: 5.40 9.77 6.08 7.21 vp9_put_8tap_smooth_8h_10bpp_neon: 4.22 8.41 4.46 6.63 vp9_put_8tap_smooth_8hv_10bpp_neon:4.56 8.51 5.39 6.25 vp9_put_8tap_smooth_8v_10bpp_neon: 6.60 12.43 8.17 8.89 vp9_put_8tap_smooth_64h_10bpp_neon:4.41 8.59 4.54 7.49 vp9_put_8tap_smooth_64hv_10bpp_neon: 4.43 8.58 5.34 6.63 vp9_put_8tap_smooth_64v_10bpp_neon:7.26 13.92 9.27 10.92 For the larger 8tap filters, the speedup vs C code is around 4-14x. --- libavcodec/arm/Makefile | 5 +- libavcodec/arm/vp9dsp_init.h| 29 ++ libavcodec/arm/vp9dsp_init_10bpp_arm.c | 23 + libavcodec/arm/vp9dsp_init_12bpp_arm.c | 23 + libavcodec/arm/vp9dsp_init_16bpp_arm_template.c | 147 ++ libavcodec/arm/vp9dsp_init_arm.c| 9 +- libavcodec/arm/vp9mc_16bpp_neon.S | 615 7 files changed, 849 insertions(+), 2 deletions(-) create mode 100644 libavcodec/arm/vp9dsp_init.h create mode 100644 libavcodec/arm/vp9dsp_init_10bpp_arm.c create mode 100644 libavcodec/arm/vp9dsp_init_12bpp_arm.c create mode 100644 libavcodec/arm/vp9dsp_init_16bpp_arm_template.c create mode 100644 libavcodec/arm/vp9mc_16bpp_neon.S diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile index 7f18daa..fb35d25 100644 --- a/libavcodec/arm/Makefile +++ b/libavcodec/arm/Makefile @@ -44,7 +44,9 @@ OBJS-$(CONFIG_MLP_DECODER) += arm/mlpdsp_init_arm.o OBJS-$(CONFIG_RV40_DECODER)+= arm/rv40dsp_init_arm.o OBJS-$(CONFIG_VORBIS_DECODER) += arm/vorbisdsp_init_arm.o OBJS-$(CONFIG_VP6_DECODER) += arm/vp6dsp_init_arm.o -OBJS-$(CONFIG_VP9_DECODER) += arm/vp9dsp_init_arm.o +OBJS-$(CONFIG_VP9_DECODER) += arm/vp9dsp_init_10bpp_arm.o \ + arm/vp9dsp_init_12bpp_arm.o \ + arm/vp9dsp_init_arm.o # ARMv5 optimizations @@ -142,4 +144,5 @@ NEON-OBJS-$(CONFIG_VORBIS_DECODER) += arm/vorbisdsp_neon.o NEON-OBJS-$(CONFIG_VP6_DECODER)+= arm/vp6dsp_neon.o NEON-OBJS-$(CONFIG_VP9_DECODER)+= arm/vp9itxfm_neon.o \ arm/vp9lpf_neon.o \ + arm/vp9mc_16bpp_neon.o\ arm/vp9mc_neon.o diff --git a/libavcodec/arm/vp9dsp_init.h b/libavcodec/arm/vp9dsp_init.h new file mode 100644 index 000..0dc1c2d --- /dev/null +++ b/libavcodec/arm/vp9ds
[FFmpeg-devel] [PATCH 5/8] aarch64: vp9dsp: Restructure the bpp checks
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
---
libavcodec/aarch64/vp9dsp_init_aarch64.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/libavcodec/aarch64/vp9dsp_init_aarch64.c
b/libavcodec/aarch64/vp9dsp_init_aarch64.c
index 0bc200e..7b50540 100644
--- a/libavcodec/aarch64/vp9dsp_init_aarch64.c
+++ b/libavcodec/aarch64/vp9dsp_init_aarch64.c
@@ -96,13 +96,10 @@ define_8tap_2d_funcs(16)
define_8tap_2d_funcs(8)
define_8tap_2d_funcs(4)
-static av_cold void vp9dsp_mc_init_aarch64(VP9DSPContext *dsp, int bpp)
+static av_cold void vp9dsp_mc_init_aarch64(VP9DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-if (bpp != 8)
-return;
-
#define init_fpel(idx1, idx2, sz, type, suffix) \
dsp->mc[idx1][FILTER_8TAP_SMOOTH ][idx2][0][0] = \
dsp->mc[idx1][FILTER_8TAP_REGULAR][idx2][0][0] = \
@@ -173,13 +170,10 @@ define_itxfm(idct, idct, 32);
define_itxfm(iwht, iwht, 4);
-static av_cold void vp9dsp_itxfm_init_aarch64(VP9DSPContext *dsp, int bpp)
+static av_cold void vp9dsp_itxfm_init_aarch64(VP9DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-if (bpp != 8)
-return;
-
if (have_neon(cpu_flags)) {
#define init_itxfm(tx, sz) \
dsp->itxfm_add[tx][DCT_DCT] = ff_vp9_idct_idct_##sz##_add_neon; \
@@ -219,13 +213,10 @@ define_loop_filters(48, 16);
define_loop_filters(84, 16);
define_loop_filters(88, 16);
-static av_cold void vp9dsp_loopfilter_init_aarch64(VP9DSPContext *dsp, int bpp)
+static av_cold void vp9dsp_loopfilter_init_aarch64(VP9DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-if (bpp != 8)
-return;
-
if (have_neon(cpu_flags)) {
dsp->loop_filter_8[0][1] = ff_vp9_loop_filter_v_4_8_neon;
dsp->loop_filter_8[0][0] = ff_vp9_loop_filter_h_4_8_neon;
@@ -250,7 +241,10 @@ static av_cold void
vp9dsp_loopfilter_init_aarch64(VP9DSPContext *dsp, int bpp)
av_cold void ff_vp9dsp_init_aarch64(VP9DSPContext *dsp, int bpp)
{
-vp9dsp_mc_init_aarch64(dsp, bpp);
-vp9dsp_loopfilter_init_aarch64(dsp, bpp);
-vp9dsp_itxfm_init_aarch64(dsp, bpp);
+if (bpp != 8)
+return;
+
+vp9dsp_mc_init_aarch64(dsp);
+vp9dsp_loopfilter_init_aarch64(dsp);
+vp9dsp_itxfm_init_aarch64(dsp);
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/caf: add 'aacl' codec tag
On 1/18/17, Piotr Bandurski wrote: > > Have samples? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov: ignore edit list with duration equals to 0 for covers art
2017-01-18 19:38 GMT+09:00 Matthieu Bouron :
> Discards edit list with duration equals to 0 for video streams with only
> one frame and avoid discarding covers art muxed as a single frame video
> stream.
> ---
> Hello,
>
> The following patch discards single edit list with duration equals to 0
> for video streams with only one frame which prevents discarding covers art
> muxed as a single frame video stream.
>
> The patch can be extended to make it always discards single edit list with
> duration equals to 0 (even if the video streams has more than one sample).
> What do you think ?
>
> Matthieu
> ---
> libavformat/mov.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index d1b929174d..88ffd0e5f2 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2988,6 +2988,17 @@ static void mov_fix_index(MOVContext *mov, AVStream
> *st)
> if (!msc->elst_data || msc->elst_count <= 0 || nb_old <= 0) {
> return;
> }
> +
> +// Discard edit list with duration equals to 0 for video streams with
> only
> +// one frame and avoid discarding covers art muxed as a single frame
> video
> +// stream
> +if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> +msc->chunk_count == 1 &&
> +msc->elst_count == 1 &&
> +msc->elst_data[0].duration == 0) {
>
This can be false positive since segment_duration=0 could be used for
implicit segment_duration when movie fragments. The spec explicitly says
that only when initial movie has no samples but
w16161-14496-12-DefectReport-R4.docx implies that the 14496-12 spec will
also apply it to more generic cases. And why msc->chunk_count == 1? The
chunk_count is the number of chunks but not samples.
> +return;
> +}
> +
> // Clean AVStream from traces of old index
> st->index_entries = NULL;
> st->index_entries_allocated_size = 0;
> --
> 2.11.0
>
> ___
> 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] avfilter: add EIA-608 line extractor
On Wed, 18 Jan 2017 at 08:40 Paul B Mahol wrote: > On 1/18/17, Kieran Kunhya wrote: > > On Tue, 17 Jan 2017, 22:31 Paul B Mahol, wrote: > > > >> On 1/17/17, Kieran Kunhya wrote: > >> > On Tue, 17 Jan 2017 at 19:44 Paul B Mahol wrote: > >> > > >> >> Signed-off-by: Dave Rice > >> >> Signed-off-by: Paul B Mahol > >> >> > >> > > >> > Is this better than libzvbi? > >> > >> The only code that does similar thing is contrib/ntsc-cc.c > >> > >> So its not part of library anyway. > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > The API supports VBI extraction (and creation). > > I'm not aware of it. It works only with devices. > Here is an example for WSS: https://github.com/kierank/libzvbi-obe-dev/blob/master/examples/wss.c#L175 CC is similar. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/h264: simplify find_unused_picture()
---
libavcodec/h264_slice.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index fe71d57421..ad7a75fa2e 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -254,25 +254,15 @@ fail:
return (ret < 0) ? ret : AVERROR(ENOMEM);
}
-static inline int pic_is_unused(H264Context *h, H264Picture *pic)
-{
-if (!pic->f->buf[0])
-return 1;
-return 0;
-}
-
static int find_unused_picture(H264Context *h)
{
int i;
for (i = 0; i < H264_MAX_PICTURE_COUNT; i++) {
-if (pic_is_unused(h, &h->DPB[i]))
-break;
+if (!h->DPB[i].f->buf[0])
+return i;
}
-if (i == H264_MAX_PICTURE_COUNT)
-return AVERROR_INVALIDDATA;
-
-return i;
+return AVERROR_INVALIDDATA;
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/h264dec: remove flush goto in decode callback
On Tue, Jan 17, 2017 at 08:36:14PM +0100, Michael Niedermayer wrote: > On Tue, Jan 17, 2017 at 10:50:31AM +0100, Clément Bœsch wrote: > > From: Clément Bœsch > > > > --- > > libavcodec/h264dec.c | 70 > > +++- > > 1 file changed, 37 insertions(+), 33 deletions(-) > > LGTM, > > thx > applied -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/matroska: comment a missing error check.
L'octidi 28 nivôse, an CCXXV, Michael Niedermayer a écrit : > instructions to reproduce the issue or a stack trace would make it > easier for interrested people to fix this > > i can guess that maybe buf is NULL but thats just a guess Yes, it happens when flirting with OOM, when OOM happens in one of the allocations for dyn_buf, the error is kept and reported when calling avio_close_dyn_buf(), and in that case buf is NULL and causes a segfault a few lines below. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/caf: add 'aacl' codec tag
0001-PATCH-avformat-caf-add-aacl-codec-tag.diff Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/nvenc.c Reduce initialization time for gpu id > 0
Seems like a good idea to run the full set of capability checks only on the device that's actually about to be used. The only issue I see is that if a system has a bunch of different GPUs, of which some don't support the required capabilities, one might get unexpected results with the device indices. Like, a system with 4 GPUs all with the required minimum nvenc version, GPU 0 and 2 support capability X. Now if you're working on GPU 0, with this patch applied, it will list all 4 GPUs as supported. So if you want to start another session, on GPU one, it will now skip that GPU, and instead end up on GPU 2. Or even worse cases might happen, the logic for this seems way overcomplicated at the moment. This is not only an issue with this patch applied. At the moment it also happens that depending on the capabilities required for an encode, the device indices might mean something else, depending on which GPUs support the required caps. That seems bad to me, having universally unique indices on the same machine no matter what settings are to be used, with some of them failing if trying to use them, would be much better. So what I propose instead of this patch: Make the device index independent of which GPUs support the required caps. Basically just means that https://github.com/FFmpeg/FFmpeg/blob/f7e9275f83ec116fc859367d61998eae8af438fc/libavcodec/nvenc.c#L365 should compare against idx instead of the nvenc_device_count. Add another check here: https://github.com/FFmpeg/FFmpeg/blob/f7e9275f83ec116fc859367d61998eae8af438fc/libavcodec/nvenc.c#L340 That aborts early if the requested ctx->device does not match idx, achieving the desired speedup. Didn't fully plan this out yet, but that plus some cosmetics, like adjusting error messages and so on, should work. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mov: ignore edit list with duration equals to 0 for covers art
Discards edit list with duration equals to 0 for video streams with only
one frame and avoid discarding covers art muxed as a single frame video
stream.
---
Hello,
The following patch discards single edit list with duration equals to 0 for
video streams with only one frame which prevents discarding covers art muxed as
a single frame video stream.
The patch can be extended to make it always discards single edit list with
duration equals to 0 (even if the video streams has more than one sample).
What do you think ?
Matthieu
---
libavformat/mov.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d1b929174d..88ffd0e5f2 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2988,6 +2988,17 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
if (!msc->elst_data || msc->elst_count <= 0 || nb_old <= 0) {
return;
}
+
+// Discard edit list with duration equals to 0 for video streams with only
+// one frame and avoid discarding covers art muxed as a single frame video
+// stream
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+msc->chunk_count == 1 &&
+msc->elst_count == 1 &&
+msc->elst_data[0].duration == 0) {
+return;
+}
+
// Clean AVStream from traces of old index
st->index_entries = NULL;
st->index_entries_allocated_size = 0;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] ffmpeg: pass output stream duration as a hint to the muxer
Signed-off-by: Tobias Rapp
---
ffmpeg.c | 9 +
libavformat/avformat.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index 6d1e358..977708c 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2908,6 +2908,10 @@ static int init_output_stream_streamcopy(OutputStream
*ost)
if (ost->st->time_base.num <= 0 || ost->st->time_base.den <= 0)
ost->st->time_base = av_add_q(av_stream_get_codec_timebase(ost->st),
(AVRational){0, 1});
+// copy estimated duration as a hint to the muxer
+if (ost->st->duration <= 0 && ist->st->duration > 0)
+ost->st->duration = av_rescale_q(ist->st->duration,
ist->st->time_base, ost->st->time_base);
+
// copy disposition
ost->st->disposition = ist->st->disposition;
@@ -,6 +3337,11 @@ static int init_output_stream(OutputStream *ost, char
*error, int error_len)
// copy timebase while removing common factors
if (ost->st->time_base.num <= 0 || ost->st->time_base.den <= 0)
ost->st->time_base = av_add_q(ost->enc_ctx->time_base,
(AVRational){0, 1});
+
+// copy estimated duration as a hint to the muxer
+if (ost->st->duration <= 0 && ist && ist->st->duration > 0)
+ost->st->duration = av_rescale_q(ist->st->duration,
ist->st->time_base, ost->st->time_base);
+
ost->st->codec->codec= ost->enc_ctx->codec;
} else if (ost->stream_copy) {
ret = init_output_stream_streamcopy(ost);
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index af257e4..ebb0e05 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -930,6 +930,9 @@ typedef struct AVStream {
* Decoding: duration of the stream, in stream time base.
* If a source file does not specify a duration, but does specify
* a bitrate, this value will be estimated from bitrate and file size.
+ *
+ * Encoding: May be set by the caller before avformat_write_header() to
+ * provide a hint to the muxer about the estimated duration.
*/
int64_t duration;
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] doc/muxers: add AVI muxer documentation
Signed-off-by: Tobias Rapp
---
doc/muxers.texi | 33 +
1 file changed, 33 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 26a8f2d..4372078 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -57,6 +57,39 @@ fragmentation or muxer overhead depending on your source.
Default value is
@end table
+@anchor{avi}
+@section avi
+
+Audio Video Interleaved muxer.
+
+@subsection Options
+
+It accepts the following options:
+
+@table @option
+@item reserve_index_space
+Reserve the specified amount of bytes for the OpenDML master index of each
+stream within the file header. By default additional master indexes are
+embedded within the data packets if there is no space left in the first master
+index and are linked together as a chain of indexes. This index structure can
+cause problems for some use cases, e.g. third-party software strictly relying
+on the OpenDML index specification or when file seeking is slow. Reserving
+enough index space in the file header avoids these problems.
+
+The required index space depends on the output file size and should be about 16
+bytes per gigabyte. When this option is omitted or set to zero the necessary
+index space is guessed.
+
+@item write_channel_mask
+Write the channel layout mask into the audio stream header.
+
+This option is enabled by default. Disabling the channel mask can be useful in
+specific scenarios, e.g. when merging multiple audio streams into one for
+compatibility with software that only supports a single audio stream in AVI
+(see @ref{amerge,,the "amerge" section in the ffmpeg-filters
manual,ffmpeg-filters}).
+
+@end table
+
@anchor{chromaprint}
@section chromaprint
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avformat/avienc: add reserve_index_space option
Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later.
If the option is omitted or zero the index size is estimated from output
duration and bitrate. A worst-case bitrate for video streams is assumed
in case it is not available.
Note: fate reference files changed because the video stream had zero
bitrate before and is guessed now.
Signed-off-by: Tobias Rapp
---
libavformat/avi.h | 1 -
libavformat/avienc.c| 77 ++---
libavformat/version.h | 2 +-
tests/ref/fate/mpeg4-bsf-unpack-bframes | 2 +-
tests/ref/lavf-fate/avi_cram| 2 +-
5 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/libavformat/avi.h b/libavformat/avi.h
index af21f2c..b1711f0 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -29,7 +29,6 @@
#define AVIF_COPYRIGHTED0x0002
#define AVI_MAX_RIFF_SIZE 0x4000LL
-#define AVI_MASTER_INDEX_SIZE 256
#define AVI_MAX_STREAM_COUNT100
/* stream header flags */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index fd16fff..dfe6039 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -21,6 +21,8 @@
//#define DEBUG
+#include
+
#include "avformat.h"
#include "internal.h"
#include "avi.h"
@@ -29,6 +31,7 @@
#include "mpegts.h"
#include "libavformat/avlanguage.h"
#include "libavutil/avstring.h"
+#include "libavutil/avutil.h"
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/dict.h"
@@ -51,6 +54,9 @@ typedef struct AVIIentry {
} AVIIentry;
#define AVI_INDEX_CLUSTER_SIZE 16384
+#define AVI_MASTER_INDEX_PREFIX_SIZE(8+2+1+1+4+8+4+4)
+#define AVI_MASTER_INDEX_ENTRY_SIZE 16 /* bytes per entry */
+#define AVI_MASTER_INDEX_SIZE_DEFAULT 256 /* number of entries */
typedef struct AVIIndex {
int64_t indx_start;
@@ -66,6 +72,8 @@ typedef struct AVIContext {
int64_t riff_start, movi_list, odml_list;
int64_t frames_hdr_all;
int riff_id;
+int reserve_index_space;
+int master_index_max_size;
int write_channel_mask;
} AVIContext;
@@ -134,6 +142,21 @@ static int avi_add_ientry(AVFormatContext *s, int
stream_index, char *tag,
return 0;
}
+static av_cold int avi_init(struct AVFormatContext *s)
+{
+AVIContext *avi = s->priv_data;
+
+if (avi->reserve_index_space > 0) {
+avi->master_index_max_size = (avi->reserve_index_space -
AVI_MASTER_INDEX_PREFIX_SIZE) / AVI_MASTER_INDEX_ENTRY_SIZE;
+avi->master_index_max_size = FFMAX(avi->master_index_max_size, 16);
+} else
+avi->master_index_max_size = AVI_MASTER_INDEX_SIZE_DEFAULT;
+av_log(s, AV_LOG_DEBUG, "reserve_index_space:%d
master_index_max_size:%d\n",
+ avi->reserve_index_space, avi->master_index_max_size);
+
+return 0;
+}
+
static int64_t avi_start_new_riff(AVFormatContext *s, AVIOContext *pb,
const char *riff_tag, const char *list_tag)
{
@@ -210,6 +233,7 @@ static int avi_write_counters(AVFormatContext *s, int
riff_id)
static void write_odml_master(AVFormatContext *s, int stream_index)
{
AVIOContext *pb = s->pb;
+AVIContext *avi = s->priv_data;
AVStream *st = s->streams[stream_index];
AVCodecParameters *par = st->codecpar;
AVIStream *avist = st->priv_data;
@@ -229,7 +253,7 @@ static void write_odml_master(AVFormatContext *s, int
stream_index)
/* dwChunkId */
avio_wl64(pb, 0); /* dwReserved[3] */
avio_wl32(pb, 0); /* Must be 0.*/
-for (j = 0; j < AVI_MASTER_INDEX_SIZE * 2; j++)
+for (j = 0; j < avi->master_index_max_size * 2; j++)
avio_wl64(pb, 0);
ff_end_tag(pb, avist->indexes.indx_start);
}
@@ -239,6 +263,7 @@ static int avi_write_header(AVFormatContext *s)
AVIContext *avi = s->priv_data;
AVIOContext *pb = s->pb;
int bitrate, n, i, nb_frames, au_byterate, au_ssize, au_scale;
+int64_t max_stream_duration = 0;
AVCodecParameters *video_par;
AVStream *video_st = NULL;
int64_t list1, list2, strh, strf;
@@ -269,13 +294,43 @@ static int avi_write_header(AVFormatContext *s)
video_par = NULL;
for (n = 0; n < s->nb_streams; n++) {
AVCodecParameters *par = s->streams[n]->codecpar;
-bitrate += par->bit_rate;
+AVStream *st = s->streams[n];
+int64_t stream_bitrate = par->bit_rate;
+/* when bitrate is unset, assume uncompressed as a worst-case value */
+if (!stream_bitrate && par->codec_type == AVMEDIA_TYPE_VIDEO &&
+(st->avg_frame_rate.num > 0) && (st->avg_frame_rate.den > 0)) {
+stream_bitrate = (int64_t)par->bits_per_coded_sample * par->width
* par->height *
+ st->avg_frame_rate.num / st->avg_frame_rate.den;
+av_log(s, AV_LOG_DEBUG, "Bit
[FFmpeg-devel] [PATCH v3 0/3] avformat/avienc: update write of master index
Changes since version 1: Added suggested output stream duration hinting. Uses output stream duration and bitrate as a hint for better filesize guessing. If stream bitrate is unknown a worst-case value is assumed. Changes since version 2: Removed the patch which changes avi muxer to fail hard immediately when a chained master index is to be written and "-strict" is above "normal". Sidenote: Noticed during tests that most loss-less encoders don't set bitrate and thus the options_table.h default value of 200k is used in avi_write_header. Not sure whether to fix this per encoder or just clear bitrate somewhere in avcodec_open2 based on AV_CODEC_PROP_LOSSLESS. I see this as a possible improvement not blocking the current patch series. Tobias Rapp (3): ffmpeg: pass output stream duration as a hint to the muxer avformat/avienc: add reserve_index_space option doc/muxers: add AVI muxer documentation doc/muxers.texi | 33 ++ ffmpeg.c| 9 libavformat/avformat.h | 3 ++ libavformat/avi.h | 1 - libavformat/avienc.c| 77 ++--- libavformat/version.h | 2 +- tests/ref/fate/mpeg4-bsf-unpack-bframes | 2 +- tests/ref/lavf-fate/avi_cram| 2 +- 8 files changed, 119 insertions(+), 10 deletions(-) -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/avienc: write chained master index only if std_compliance is normal or below
On 17.01.2017 19:10, Michael Niedermayer wrote: On Tue, Jan 17, 2017 at 02:44:28PM +0100, Tobias Rapp wrote: On 13.01.2017 17:42, Michael Niedermayer wrote: On Tue, Jan 10, 2017 at 09:26:53AM +0100, Tobias Rapp wrote: On 10.01.2017 00:19, Michael Niedermayer wrote: [...] isnt it better to warn the user and inform him at the end what size of reserved space would have been needed? not saying iam against this, i do see how it is formally correct to fail hard but it feels painfull to me to fail muxing at 256gb hard when we can perfectly fine just continue and the user can just remux the file with bigger reserved master index to fix it But then adding "-strict strict" just enables a warning message and a non-compliant file is written still? Or do you mean that additionally a warning message could be written in case std_compliance is <= normal? Background story: I'm working on an application that fetches some AVI file byte range from tape storage and restores the file header. The header restoration requires the ODML master index in the header to be complete. Thus I'd like to ensure that all AVI files put into the archive have a compliant/compatible index structure. For such automated processes failing hard is more safe than continuing with a warning message, checking for log messages in the host application and possibly re-running the transcoding with adapted options. whats your oppinion on an option that selects muxer error behavior ? something that can fail immedeatly on error or warn but continue, return failure after writing the file and trailer that is a option to make it possible for a muxer to continue even if there was an error, maybe even a int max_muxer_error or something else? You mean something like extending the current use of error_recognition and AV_EF_EXPLODE to encoders/muxers? In general no, the semantic meaning is different recogniing errors in the input material and recognizing errors in the muxer "implementation" in relation to the used input or other are not the same thing. They may have different values, different defaults, and would have different explanation in the docs it might be a good idea but I don't see how it helps in the current case. well, it gives the user the option d) write a working file with chained master index and fail at trailer writing time to indicate that its not spec compliant but loose no data. The use case is anything that has non recoverable input, anything that cannot be re-run with a larger reserved space I agree this would be better e.g. when recording live data coming from an input device. Would the indication be done by some special return code "AV_PROBLEM_BUT_CONTINUE" on API level? Or maybe a separate error reporting field/buffer within the AVFormatContext struct? Trying to understand how it would integrate into the host application (ffmpeg/other) ... Anyway, will send version 3 of the patch series with this patch excluded. [...] Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add EIA-608 line extractor
On 1/18/17, Kieran Kunhya wrote: > On Tue, 17 Jan 2017, 22:31 Paul B Mahol, wrote: > >> On 1/17/17, Kieran Kunhya wrote: >> > On Tue, 17 Jan 2017 at 19:44 Paul B Mahol wrote: >> > >> >> Signed-off-by: Dave Rice >> >> Signed-off-by: Paul B Mahol >> >> >> > >> > Is this better than libzvbi? >> >> The only code that does similar thing is contrib/ntsc-cc.c >> >> So its not part of library anyway. >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > The API supports VBI extraction (and creation). I'm not aware of it. It works only with devices. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add EIA-608 line extractor
On 1/18/17, Tobias Rapp wrote:
> On 17.01.2017 20:43, Paul B Mahol wrote:
>> Signed-off-by: Dave Rice
>> Signed-off-by: Paul B Mahol
>> ---
>> doc/filters.texi| 70
>> libavfilter/Makefile| 1 +
>> libavfilter/allfilters.c| 1 +
>> libavfilter/vf_readeia608.c | 268
>>
>> 4 files changed, 340 insertions(+)
>> create mode 100644 libavfilter/vf_readeia608.c
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 94548b1..57170e3 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -11249,6 +11249,76 @@ less than @code{0}, the filter will try to use a
>> good random seed on a
>> best effort basis.
>> @end table
>>
>> +@section readeia608
>> +
>> +Read closed captioning (EIA-608) information from the top lines of a
>> video frame.
>> +
>> +This filter adds frame metadata for @code{lavfi.readeia608.cc.X} and
>> +@code{lavfi.readeia608.line.X}, where @code{X} is the number of the
>> identified line
>> +with EIA-608 data (starting from 0). A description of each metadata value
>> follows:
>> +
>> +@table @option
>> +@item lavfi.readeia608.cc.X
>> +The two bytes stored as EIA-608 data (printed in hexadecimal).
>> +
>> +@item lavfi.readeia608.line.X
>> +The number of the line on which the EIA-608 data was identified and read.
>> +@end table
>
> From what I see this is a pair of values that belong together.
>
> lavfi.readeia608.X.cc
> lavfi.readeia608.X.line
>
> would indicate that better, IMHO.
Changed.
>
>> +
>> +This filter accepts the following options:
>> +
>> +@table @option
>> +@item start
>> +Set the line to start scanning for EIA-608 data. Default is @code{0}.
>> +
>> +@item end
>> +Set the line to end scanning for EIA-608 data. Default is @code{29}.
>
> What about naming them "scan_min/scan_max" for alignment with "readvitc"
> filter?
OK.
>
>> +
>> +@item mac
>> +Set minimal acceptable amplitude change for sync codes detection.
>> +Default is @code{0.2}. Allowed range is @code{[0.001 - 1]}.
>> +
>> +@item spw
>> +Set the ratio of width reserved for sync code detection.
>> +Default is @code{0.27}. Allowed range is @code{[0.01 - 0.7]}.
>> +
>> +@item mhd
>> +Set the max peaks height difference for sync code detection.
>> +Default is @code{0.1}. Allowed range is @code{[0.0 - 0.5]}.
>> +
>> +@item mpd
>> +Set max peaks period difference for sync code detection.
>> +Default is @code{0.1}. Allowed range is @code{[0.0 - 0.5]}.
>> +
>> +@item msd
>> +Set the first two max start code bits differences.
>> +Default is @code{0.02}. Allowed range is @code{[0.0 - 0.5]}.
>> +
>> +@item bhd
>> +Set the minimum ratio of bits height compared to 3rd start code bit.
>> +Default is @code{0.75}. Allowed range is @code{[0.01 - 1]}.
>> +
>> +@item wth
>> +Set the white color threshold. Default is @code{0.35}. Allowed range is
>> @code{[0.1 - 1]}.
>> +
>> +@item bth
>> +Set the black color threshold. Default is @code{0.15}. Allowed range is
>> @code{[0.0 - 0.5]}.
>
> "thr_w/thr_b"?
Could change...
>
>> +
>> +@item chp
>> +Enable checking the parity bit. In the event of a parity error, the
>> filter will output
>> +@code{0x00} for that character. Default is false.
>> +@end table
>> +
>> +@subsection Examples
>> +
>> +@itemize
>> +@item
>> +Output a csv with presentation time and the first two lines of identified
>> EIA-608 captioning data.
>> +@example
>> +ffprobe -f lavfi -i movie=captioned_video.mov,readeia608 -show_entries
>> frame=pkt_pts_time:frame_tags=lavfi.readeia608.cc.0,lavfi.readeia608.cc.1
>> -of csv
>> +@end example
>> +@end itemize
>> +
>> @section readvitc
>>
>> Read vertical interval timecode (VITC) information from the top lines of
>> a
>>
>> [...]
>
> BTW: Do you have some example file available for testing?
Yes, but I'm afraid I can not share them.
Here is one available:
https://archive.org/details/cc_sample
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] ffmpeg: Pass the global device context to encoder and decoder instances
On Tue, 17 Jan 2017 22:32:15 +
Mark Thompson wrote:
> ---
> ffmpeg.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 6d1e358..781c0a4 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2748,6 +2748,12 @@ static int init_input_stream(int ist_index, char
> *error, int error_len)
> * audio, and video decoders such as cuvid or mediacodec */
> av_codec_set_pkt_timebase(ist->dec_ctx, ist->st->time_base);
>
> +if (hw_device_ctx) {
> +ist->dec_ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
> +if (!ist->dec_ctx->hw_device_ctx)
> +return AVERROR(ENOMEM);
> +}
> +
> if (!av_dict_get(ist->decoder_opts, "threads", NULL, 0))
> av_dict_set(&ist->decoder_opts, "threads", "auto", 0);
> if ((ret = avcodec_open2(ist->dec_ctx, codec, &ist->decoder_opts)) <
> 0) {
> @@ -3271,6 +3277,12 @@ static int init_output_stream(OutputStream *ost, char
> *error, int error_len)
> !av_dict_get(ost->encoder_opts, "ab", NULL, 0))
> av_dict_set(&ost->encoder_opts, "b", "128000", 0);
>
> +if (hw_device_ctx) {
> +ost->enc_ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
> +if (!ost->enc_ctx->hw_device_ctx)
> +return AVERROR(ENOMEM);
> +}
> +
> if (ost->filter &&
> av_buffersink_get_hw_frames_ctx(ost->filter->filter)) {
> ost->enc_ctx->hw_frames_ctx =
> av_buffer_ref(av_buffersink_get_hw_frames_ctx(ost->filter->filter));
> if (!ost->enc_ctx->hw_frames_ctx)
Doesn't this break the case when hw decoder and encoder are different?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] ffmpeg: Always make the qsv device if the option is set
On Tue, 17 Jan 2017 22:31:48 +
Mark Thompson wrote:
> Previously it was only created if the decode hwaccel was requested;
> this makes it unconditionally so we can use it without the hwaccel.
> ---
> ffmpeg.h | 4 +---
> ffmpeg_opt.c | 13 -
> ffmpeg_qsv.c | 14 ++
> 3 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/ffmpeg.h b/ffmpeg.h
> index 75bf50e..7362c2d 100644
> --- a/ffmpeg.h
> +++ b/ffmpeg.h
> @@ -604,9 +604,6 @@ extern const OptionDef options[];
> extern const HWAccel hwaccels[];
> extern int hwaccel_lax_profile_check;
> extern AVBufferRef *hw_device_ctx;
> -#if CONFIG_QSV
> -extern char *qsv_device;
> -#endif
>
>
> void term_init(void);
> @@ -641,6 +638,7 @@ int vdpau_init(AVCodecContext *s);
> int dxva2_init(AVCodecContext *s);
> int vda_init(AVCodecContext *s);
> int videotoolbox_init(AVCodecContext *s);
> +int qsv_device_init(const char *device);
> int qsv_init(AVCodecContext *s);
> int qsv_transcode_init(OutputStream *ost);
> int vaapi_decode_init(AVCodecContext *avctx);
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index a1c02fc..49397be 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -462,6 +462,17 @@ static int opt_vaapi_device(void *optctx, const char
> *opt, const char *arg)
> }
> #endif
>
> +#if CONFIG_QSV
> +static int opt_qsv_device(void *optctx, const char *opt, const char *arg)
> +{
> +int err;
> +err = qsv_device_init(arg);
> +if (err < 0)
> +exit_program(1);
> +return 0;
> +}
> +#endif
> +
> /**
> * Parse a metadata specifier passed as 'arg' parameter.
> * @param arg metadata string to parse
> @@ -3694,7 +3705,7 @@ const OptionDef options[] = {
> #endif
>
> #if CONFIG_QSV
> -{ "qsv_device", HAS_ARG | OPT_STRING | OPT_EXPERT, { &qsv_device },
> +{ "qsv_device", HAS_ARG | OPT_EXPERT, { .func_arg = opt_qsv_device },
> "set QSV hardware device (DirectX adapter index, DRM path or X11
> display name)", "device"},
> #endif
>
> diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
> index 86824b6..9356f05 100644
> --- a/ffmpeg_qsv.c
> +++ b/ffmpeg_qsv.c
> @@ -28,8 +28,6 @@
>
> #include "ffmpeg.h"
>
> -char *qsv_device = NULL;
> -
> static int qsv_get_buffer(AVCodecContext *s, AVFrame *frame, int flags)
> {
> InputStream *ist = s->opaque;
> @@ -43,19 +41,19 @@ static void qsv_uninit(AVCodecContext *s)
> av_buffer_unref(&ist->hw_frames_ctx);
> }
>
> -static int qsv_device_init(InputStream *ist)
> +int qsv_device_init(const char *device)
> {
> int err;
> AVDictionary *dict = NULL;
>
> -if (qsv_device) {
> -err = av_dict_set(&dict, "child_device", qsv_device, 0);
> +if (device) {
> +err = av_dict_set(&dict, "child_device", device, 0);
> if (err < 0)
> return err;
> }
>
> err = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_QSV,
> - ist->hwaccel_device, dict, 0);
> + device, dict, 0);
> if (err < 0) {
> av_log(NULL, AV_LOG_ERROR, "Error creating a QSV device\n");
> goto err_out;
> @@ -76,7 +74,7 @@ int qsv_init(AVCodecContext *s)
> int ret;
>
> if (!hw_device_ctx) {
> -ret = qsv_device_init(ist);
> +ret = qsv_device_init(ist->hwaccel_device);
> if (ret < 0)
> return ret;
> }
> @@ -148,7 +146,7 @@ int qsv_transcode_init(OutputStream *ost)
> av_log(NULL, AV_LOG_VERBOSE, "Setting up QSV transcoding\n");
>
> if (!hw_device_ctx) {
> -err = qsv_device_init(ist);
> +err = qsv_device_init(ist->hwaccel_device);
> if (err < 0)
> goto fail;
> }
Like the vaapi case, this leaks a device context each time the option
is used after the first time.
Also, shouldn't this maybe only set the hwcontext type, and ffmpeg.c
should call av_hwdevice_ctx_create() in a common code path later?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
