Re: [FFmpeg-devel] [PATCH v2] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
On Mon, Apr 8, 2019 at 6:23 PM Liu Steven wrote:
>
>
> > 在 2019年4月9日，上午8:54，Jun Li 写道：
> >
> > Ping.
> >
> > On Fri, Apr 5, 2019 at 12:00 PM Jun Li wrote:
> >
> >>
> >>
> >> On Fri, Apr 5, 2019 at 11:50 AM Jun Li wrote:
> >>
> >>> stimeout option is already used in tcp transport, since
> >>> http is based on tcp, pass the option to http for tunneling
> >>> case.
> >>> ---
> >>> libavformat/rtsp.c | 10 --
> >>> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> >>> index 033095905d..8349840c96 100644
> >>> --- a/libavformat/rtsp.c
> >>> +++ b/libavformat/rtsp.c
> >>> @@ -1744,6 +1744,9 @@ redirect:
> >>> char httpname[1024];
> >>> char sessioncookie[17];
> >>> char headers[1024];
> >>> +AVDictionary *options = NULL;
>>> +
> >>> +av_dict_set_int(&options, "timeout", rt->stimeout, 0);
> >>>
> >>> ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https"
> :
> >>> "http", auth, host, port, "%s", path);
> >>> snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
> >>> @@ -1774,7 +1777,8 @@ redirect:
> >>> }
> >>>
> >>> /* complete the connection */
> >>> -if (ffurl_connect(rt->rtsp_hd, NULL)) {
> >>> +if (ffurl_connect(rt->rtsp_hd, &options)) {
> >>> +av_dict_free(&options);
> >>> err = AVERROR(EIO);
> >>> goto fail;
> >>> }
> >>> @@ -1818,10 +1822,12 @@ redirect:
> >>> ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
> >>>
> >>> /* complete the connection */
> >>> -if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
> >>> +if (ffurl_connect(rt->rtsp_hd_out, &options)) {
> >>> +av_dict_free(&options);
> >>> err = AVERROR(EIO);
> >>> goto fail;
> >>> }
> >>> +av_dict_free(&options);
> Why don’t move the av_dict_free(&options) to the fail?
Since the diff does not show the whole picture of the code, I simplify the
code as follows:
if (is_tunnel) {
AVDictionary *options = NULL;
.
if (err) {
av_dict_free(&options);
goto fail;
}
av_dict_free(&options);
} else {
}
fail:
// some clean-up code.
So if I put the "av_dict_free" in the fail, then I have to put the
"options" declaration outside of the if condition, to expand its scope so
that clean-up code can see/use.
Option 2 is to add a label tunnel_fail like this:
if (is_tunnel) {
AVDictionary *options = NULL;
.
..
if (err) {
goto tunnel_fail;
}
*tunnel_fail: *
av_dict_free(&options);
if (err) {
goto fai;
}
} else {
}
fail:
// some clean-up code.
The "tunnel_fail" label may be a little heavy if it is just for
"av_dict_free". But it still has its point.
And option 1 -- move the variable scope outside of the if condition is also
a little heavy.
What do you think ?
>>> } else {
> >>> int ret;
> >>> /* open the tcp connection */
> >>> --
> >>> 2.17.1
> >>>
> >>>
> >>
> >> Updated the version, free the memory in error path, patch is here:
> >> https://patchwork.ffmpeg.org/patch/12620/
> >> I initially planned to do that then I realized the error path will
> trigger
> >> whole process to exit, which may be safe. But I agree with you, it is a
> >> better practice to clean-up here.
> >>
> >> Thanks for review, Michael.
> >>
> >> Best Regards,
> >> Jun
> >>
> >>
> >>
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”.
>
>
>
>
> Thanks
>
> Steven
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Thanks for review Steven ! I commented in-line.
Best Regards
-Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi: add nlmeans_opencl filter
Thanks for the valuable comments!
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Tuesday, April 9, 2019 4:26 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add nlmeans_opencl filter
>
> On 01/04/2019 08:52, Ruiling Song wrote:
> > Signed-off-by: Ruiling Song
> > ---
> > This filter runs about 2x faster on integrated GPU than nlmeans on my
> > Skylake
> CPU.
> > Anybody like to give some comments?
>
> Nice!
>
> > configure | 1 +
> > doc/filters.texi| 4 +
> > libavfilter/Makefile| 1 +
> > libavfilter/allfilters.c| 1 +
> > libavfilter/opencl/nlmeans.cl | 108 +
> > libavfilter/opencl_source.h | 1 +
> > libavfilter/vf_nlmeans_opencl.c | 390
> > 7 files changed, 506 insertions(+)
> > create mode 100644 libavfilter/opencl/nlmeans.cl
> > create mode 100644 libavfilter/vf_nlmeans_opencl.c
> >
> > diff --git a/configure b/configure
> > index f6123f53e5..a233512491 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3460,6 +3460,7 @@ mpdecimate_filter_select="pixelutils"
> > minterpolate_filter_select="scene_sad"
> > mptestsrc_filter_deps="gpl"
> > negate_filter_deps="lut_filter"
> > +nlmeans_opencl_filter_deps="opencl"
> > nnedi_filter_deps="gpl"
> > ocr_filter_deps="libtesseract"
> > ocv_filter_deps="libopencv"
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 867607d870..21c2c1a4b5 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -19030,6 +19030,10 @@ Apply erosion filter with threshold0 set to 30,
> threshold1 set 40, threshold2 se
> > @end example
> > @end itemize
> >
> > +@section nlmeans_opencl
> > +
> > +Non-local Means denoise filter through OpenCL, this filter accepts same
> options as @ref{nlmeans}.
> > +
> > @section overlay_opencl
> >
> > Overlay one video on top of another.
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index fef6ec5c55..92039bfdcf 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -291,6 +291,7 @@ OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o
> > OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
> > OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
> > OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
> > +OBJS-$(CONFIG_NLMEANS_OPENCL_FILTER) += vf_nlmeans_opencl.o
> opencl.o opencl/nlmeans.o
> > OBJS-$(CONFIG_NNEDI_FILTER) += vf_nnedi.o
> > OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
> > OBJS-$(CONFIG_NOISE_FILTER) += vf_noise.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> > index c51ae0f3c7..2a6390c92d 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -277,6 +277,7 @@ extern AVFilter ff_vf_mix;
> > extern AVFilter ff_vf_mpdecimate;
> > extern AVFilter ff_vf_negate;
> > extern AVFilter ff_vf_nlmeans;
> > +extern AVFilter ff_vf_nlmeans_opencl;
> > extern AVFilter ff_vf_nnedi;
> > extern AVFilter ff_vf_noformat;
> > extern AVFilter ff_vf_noise;
> > diff --git a/libavfilter/opencl/nlmeans.cl b/libavfilter/opencl/nlmeans.cl
> > new file mode 100644
> > index 00..dcb04834ca
> > --- /dev/null
> > +++ b/libavfilter/opencl/nlmeans.cl
> > @@ -0,0 +1,108 @@
> > +/*
> > + * 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
> > + */
> > +
> > +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
> > + CLK_ADDRESS_CLAMP_TO_EDGE |
> > + CLK_FILTER_NEAREST);
> > +
> > +kernel void horiz_sum(__global uint4 *ii,
> > + __read_only image2d_t src,
> > + int width,
> > + int height,
> > + int4 dx,
> > + int4 dy)
> > +{
> > +
> > +int y = get_global_id(0);
> > +int work_size = get_global_size(0);
> > +
> > +uint4 sum = (uint4)(0);
> > +float4 s2;
> > +for (int i = 0; i < width; i++) {
> > +float s1 = read_imagef(src, sampler, (int2)(i, y)).x;
> > +s
[FFmpeg-devel] [PATCH, v4] lavc/vaapi_decode: find exact va_profile for HEVC_REXT
Use the profile constraint flags to determine the exact va_profile for
HEVC_REXT.
Directly cast PTLCommon to H265RawProfileTierLevel, and use ff_h265_get_profile
to get the exact profile.
Add h265_profile_level.o to build objects for vaapi_decode to fix the compile
dependency issue.
Signed-off-by: Linjie Fu
---
[v2]: use constraint flags to determine the exact profile, expose the
codec-specific stuff at the beginning.
[v3]: move the VA version check to fix the compile issue.
[v4]: fix the build issue.
libavcodec/Makefile | 2 +-
libavcodec/vaapi_decode.c | 73 +++
2 files changed, 59 insertions(+), 16 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8a6a..c0df0ad90a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -857,7 +857,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER) += adpcmenc.o
adpcm_data.o
OBJS-$(CONFIG_D3D11VA)+= dxva2.o
OBJS-$(CONFIG_DXVA2) += dxva2.o
OBJS-$(CONFIG_NVDEC) += nvdec.o
-OBJS-$(CONFIG_VAAPI) += vaapi_decode.o
+OBJS-$(CONFIG_VAAPI) += vaapi_decode.o
h265_profile_level.o
OBJS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.o
OBJS-$(CONFIG_VDPAU) += vdpau.o
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 69512e1d45..47db6c874a 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -24,6 +24,8 @@
#include "decode.h"
#include "internal.h"
#include "vaapi_decode.h"
+#include "hevcdec.h"
+#include "h265_profile_level.h"
int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
@@ -401,6 +403,33 @@ static const struct {
#undef MAP
};
+/*
+ * Find exact va_profile for HEVC Range Extension
+ */
+static VAProfile vaapi_decode_find_exact_profile(AVCodecContext *avctx)
+{
+const HEVCContext *h = avctx->priv_data;
+const HEVCSPS *sps = h->ps.sps;
+const PTL *ptl = &(sps->ptl);
+const PTLCommon *general_ptl = &(ptl->general_ptl);
+const H265ProfileDescriptor *profile;
+
+/* PTLCommon should match the member sequence in H265RawProfileTierLevel*/
+profile = ff_h265_get_profile((H265RawProfileTierLevel *)general_ptl);
+
+#if VA_CHECK_VERSION(1, 2, 0)
+if (!strcmp(profile->name, "Main 4:2:2 10"))
+return VAProfileHEVCMain422_10;
+else if (!strcmp(profile->name, "Main 4:4:4"))
+return VAProfileHEVCMain444;
+else if (!strcmp(profile->name, "Main 4:4:4 10"))
+return VAProfileHEVCMain444_10;
+#else
+av_log(avctx, AV_LOG_WARNING, "HEVC profile %s is "
+"not supported with this VA version.\n",
profile->name);
+#endif
+return VAProfileNone;
+}
/*
* Set *va_config and the frames_ref fields from the current codec parameters
* in avctx.
@@ -447,24 +476,38 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
matched_va_profile = VAProfileNone;
exact_match = 0;
-for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
-int profile_match = 0;
-if (avctx->codec_id != vaapi_profile_map[i].codec_id)
-continue;
-if (avctx->profile == vaapi_profile_map[i].codec_profile ||
-vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
-profile_match = 1;
-for (j = 0; j < profile_count; j++) {
-if (vaapi_profile_map[i].va_profile == profile_list[j]) {
-exact_match = profile_match;
+if (avctx->profile == FF_PROFILE_HEVC_REXT) {
+/* find the exact va_profile for HEVC_REXT */
+VAProfile va_profile = vaapi_decode_find_exact_profile(avctx);
+for (i = 0; i < profile_count; i++) {
+if (va_profile == profile_list[i]) {
+exact_match = 1;
+matched_va_profile = va_profile;
+matched_ff_profile = FF_PROFILE_HEVC_REXT;
break;
}
}
-if (j < profile_count) {
-matched_va_profile = vaapi_profile_map[i].va_profile;
-matched_ff_profile = vaapi_profile_map[i].codec_profile;
-if (exact_match)
-break;
+} else {
+/* find the exact va_profile according to codec_id and profile */
+for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
+int profile_match = 0;
+if (avctx->codec_id != vaapi_profile_map[i].codec_id)
+continue;
+if (avctx->profile == vaapi_profile_map[i].codec_profile ||
+vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
+profile_match = 1;
+for (j = 0; j < profile_count; j++) {
+if (vaapi_profile_map[i].va_profile == profile_list[j]) {
+exact_match = profile_match;
+break;
+}
+}
+if (j < profile_count) {
+matched_v
Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of James Almer > Sent: Monday, April 8, 2019 21:56 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find > exact va_profile for HEVC_REXT > > On 4/7/2019 11:02 PM, Fu, Linjie wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > >> Of Michael Niedermayer > >> Sent: Friday, April 5, 2019 00:52 > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find > >> exact va_profile for HEVC_REXT > >> > >> On Thu, Apr 04, 2019 at 04:10:35PM +0800, Linjie Fu wrote: > >>> Use the profile constraint flags to determine the exact va_profile for > >>> HEVC_REXT. > >>> > >>> Directly cast PTLCommon to H265RawProfileTierLevel, and use > >> ff_h265_get_profile > >>> to get the exact profile. > >>> > >>> Signed-off-by: Linjie Fu > >>> --- > >>> [v2]: use constraint flags to determine the exact profile, expose the > >>> codec-specific stuff at the beginning. > >>> [v3]: move the VA version check to fix the compile issue. > >>> [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for > >>> convenience? The members in PTLCommon should be strictly matched > in > >>> H265RawProfileTierLevel. > >>> > >>> libavcodec/vaapi_decode.c | 73 > +++-- > >> -- > >>> 1 file changed, 58 insertions(+), 15 deletions(-) > >> > >> breaks build with shared libs: > >> > >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' > >> clang: error: linker command failed with exit code 1 (use -v to see > invocation) > >> make: *** [ffmpeg_g] Error 1 > >> make: *** Waiting for unfinished jobs > >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' > >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' > >> clang: error: linker command failed with exit code 1 (use -v to see > invocation) > >> make: *** [ffplay_g] Error 1 > >> clang: error: linker command failed with exit code 1 (use -v to see > invocation) > >> make: *** [ffprobe_g] Error 1 > >> > >> > > > > Hi Michael, > > > > Thanks for the build check and compile error messages. > > Actually, I also did the compile check locally and through pre-patch system. > > > > We do shared libs compile with gcc and latest libva and msdk master deps, > and it passes the check. > > It seems this error occurs with clang. > > > > Could you provide some details on how to reproduce it? (e.g. compiler, > distro, deps, flags, etc.). > > > > Thus we can add into the system to refine the pre-patch check and have > this clang compile issue fixed? > > > > Thanks, > > Linjie > > You need to add h265_profile_level.o to the build objects related to > this module in libavcodec/Makefile. It's currently only being built for > the hevc vaapi encoder, so if that's disabled, linking will fail. > > It's most likely not an issue with shared builds. I'm guessing Michael's > environment for that build had the hevc vaapi encoder disabled. Yes, that's the problem and thanks for the comments. I disabled hevc_vaapi encoder and reproduced this build issue. With h265_profile_level.o added to the build objects of vaapi_decode, this issue can be fixed. Thanks, Linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavf/matroskaenc: Fix memory leak after write trailer
On Mon, Apr 8, 2019 at 3:29 PM myp...@gmail.com wrote:
>
> On Mon, Apr 8, 2019 at 9:09 AM myp...@gmail.com wrote:
> >
> >
> >
> > On Fri, Apr 5, 2019 at 12:38 AM Andreas Rheinhardt via ffmpeg-devel
> > wrote:
> > >
> > > Jun Zhao:
> > > > From: Jun Zhao
> > > >
> > > > Fix memory leak after write trailer for #7827, only store a audio
> > > > packet whose buffer has size greater than zero in cur_audio_pkt.
> > > >
> > > > Thanks to Andreas Rheinhardt for the suggestions.
> > > >
> > > > Signed-off-by: Jun Zhao
> > > > ---
> > > > libavformat/matroskaenc.c |3 ++-
> > > > 1 files changed, 2 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > > > index b9f99c4..06f3aeb 100644
> > > > --- a/libavformat/matroskaenc.c
> > > > +++ b/libavformat/matroskaenc.c
> > > > @@ -2534,7 +2534,8 @@ static int mkv_write_packet(AVFormatContext *s,
> > > > AVPacket *pkt)
> > > > // buffer an audio packet to ensure the packet containing the video
> > > > // keyframe's timecode is contained in the same cluster for WebM
> > > > if (codec_type == AVMEDIA_TYPE_AUDIO) {
> > > > -ret = av_packet_ref(&mkv->cur_audio_pkt, pkt);
> > > > +if (pkt->size > 0)
> > > > +ret = av_packet_ref(&mkv->cur_audio_pkt, pkt);
> > > > } else
> > > > ret = mkv_write_packet_internal(s, pkt, 0);
> > > > return ret;
> > > >
> > > Seems that I took quite a lot of time to write my commit message. I
> > > don't care which patch gets committed, but I presume you did run
> > > valgrind to make sure that it actually fixes #7827?
> > >
> > > - Andreas
> > Yes, I've run the valgrind for muxing with FLAC and other audio codec for
> > this issue.
>
> Will close the https://trac.ffmpeg.org/ticket/7827, Thanks
Pushed (updated the commit message from Andreas Rheinhardt's patch and
add Andreas Rheinhardt to Signed-off-by list). Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
> 在 2019年4月9日，上午8:54，Jun Li 写道：
>
> Ping.
>
> On Fri, Apr 5, 2019 at 12:00 PM Jun Li wrote:
>
>>
>>
>> On Fri, Apr 5, 2019 at 11:50 AM Jun Li wrote:
>>
>>> stimeout option is already used in tcp transport, since
>>> http is based on tcp, pass the option to http for tunneling
>>> case.
>>> ---
>>> libavformat/rtsp.c | 10 --
>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>>> index 033095905d..8349840c96 100644
>>> --- a/libavformat/rtsp.c
>>> +++ b/libavformat/rtsp.c
>>> @@ -1744,6 +1744,9 @@ redirect:
>>> char httpname[1024];
>>> char sessioncookie[17];
>>> char headers[1024];
>>> +AVDictionary *options = NULL;
>>> +
>>> +av_dict_set_int(&options, "timeout", rt->stimeout, 0);
>>>
>>> ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
>>> "http", auth, host, port, "%s", path);
>>> snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
>>> @@ -1774,7 +1777,8 @@ redirect:
>>> }
>>>
>>> /* complete the connection */
>>> -if (ffurl_connect(rt->rtsp_hd, NULL)) {
>>> +if (ffurl_connect(rt->rtsp_hd, &options)) {
>>> +av_dict_free(&options);
>>> err = AVERROR(EIO);
>>> goto fail;
>>> }
>>> @@ -1818,10 +1822,12 @@ redirect:
>>> ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
>>>
>>> /* complete the connection */
>>> -if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
>>> +if (ffurl_connect(rt->rtsp_hd_out, &options)) {
>>> +av_dict_free(&options);
>>> err = AVERROR(EIO);
>>> goto fail;
>>> }
>>> +av_dict_free(&options);
Why don’t move the av_dict_free(&options) to the fail?
>>> } else {
>>> int ret;
>>> /* open the tcp connection */
>>> --
>>> 2.17.1
>>>
>>>
>>
>> Updated the version, free the memory in error path, patch is here:
>> https://patchwork.ffmpeg.org/patch/12620/
>> I initially planned to do that then I realized the error path will trigger
>> whole process to exit, which may be safe. But I agree with you, it is a
>> better practice to clean-up here.
>>
>> Thanks for review, Michael.
>>
>> Best Regards,
>> Jun
>>
>>
>>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”.
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavutil/hwcontext_opencl.c: fix bug in `opencl_get_plane_format`
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Tuesday, April 9, 2019 3:49 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] libavutil/hwcontext_opencl.c: fix bug
> in
> `opencl_get_plane_format`
>
> On 08/04/2019 03:01, Jarek Samic wrote:
> > The `opencl_get_plane_format` function was incorrectly determining the
> > value used to set the image channel order. This resulted in all RGB
> > pixel formats being set to the `CL_RGBA` pixel format, regardless of
> > whether or not they actually *were* RGBA.
> >
> > This patch fixes the issue by using the `offset` and depth of components
> > rather than the loop index to determine the value of `order`.
> >
> > Signed-off-by: Jarek Samic
> > ---
> > I have updated this patch in response to the comments on the first version.
> > RGB is no longer special-cased, the 2, 3, and 4 mappings to `CL_R` have been
> > removed, and the mapping for `CL_ARGB` has been changed to the correct
> value.
> >
> > libavutil/hwcontext_opencl.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> > index b116c5b708..593de1ca41 100644
> > --- a/libavutil/hwcontext_opencl.c
> > +++ b/libavutil/hwcontext_opencl.c
> > @@ -1419,8 +1419,9 @@ static int opencl_get_plane_format(enum
> AVPixelFormat pixfmt,
> > // from the same component.
> > if (step && comp->step != step)
> > return AVERROR(EINVAL);
> > -order = order * 10 + c + 1;
> > +
> > depth = comp->depth;
> > +order = order * 10 + comp->offset / ((depth + 7) / 8) + 1;
> > step = comp->step;
> > alpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA &&
> > c == desc->nb_components - 1);
>
> This part LGTM, I can split it off and apply it on its own if you like.
>
> > @@ -1456,14 +1457,11 @@ static int opencl_get_plane_format(enum
> AVPixelFormat pixfmt,
> > case order: image_format->image_channel_order = type; break;
> > switch (order) {
> > CHANNEL_ORDER(1,CL_R);
> > -CHANNEL_ORDER(2,CL_R);
> > -CHANNEL_ORDER(3,CL_R);
> > -CHANNEL_ORDER(4,CL_R);
> > CHANNEL_ORDER(12, CL_RG);
> > CHANNEL_ORDER(23, CL_RG);
>
> 23 should be gone too, I think?
Agree.
>
> > CHANNEL_ORDER(1234, CL_RGBA);
> > +CHANNEL_ORDER(2341, CL_ARGB);
> > CHANNEL_ORDER(3214, CL_BGRA);
> > -CHANNEL_ORDER(4123, CL_ARGB);
>
> I'm not sure I believe this part:
>
> 1 = R
> 2 = G
> 3 = B
> 4 = A
The above assumption is not true.
The new logic changes to use combination of offset-index of RGBA.
So for CL_ARGB, the R offset at 2, G is offset at 3, B is offset at 4, A is
offset at 1.
So, it is 2341 that maps to ARGB.
It's interesting that these two ways of representing the swizzle sometime
match, sometime not.
Thanks!
Ruiling
>
> gives
>
> RGBA -> 1234
> BGRA -> 3214
> ARGB -> 4123
> ABGR -> 4321
>
> The others match, so why would ARGB be different? 2341 should be GBAR.
>
> (Can you try this with multiple ARGB sources or OpenCL ICDs? Maybe there is a
> bug somewhere else...)
>
> > #ifdef CL_ABGR
> > CHANNEL_ORDER(4321, CL_ABGR);
> > #endif
> >
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavf/rtsp.c: Fix stimeout option not applied on http tunnel
Ping.
On Fri, Apr 5, 2019 at 12:00 PM Jun Li wrote:
>
>
> On Fri, Apr 5, 2019 at 11:50 AM Jun Li wrote:
>
>> stimeout option is already used in tcp transport, since
>> http is based on tcp, pass the option to http for tunneling
>> case.
>> ---
>> libavformat/rtsp.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
>> index 033095905d..8349840c96 100644
>> --- a/libavformat/rtsp.c
>> +++ b/libavformat/rtsp.c
>> @@ -1744,6 +1744,9 @@ redirect:
>> char httpname[1024];
>> char sessioncookie[17];
>> char headers[1024];
>> +AVDictionary *options = NULL;
>> +
>> +av_dict_set_int(&options, "timeout", rt->stimeout, 0);
>>
>> ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
>> "http", auth, host, port, "%s", path);
>> snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
>> @@ -1774,7 +1777,8 @@ redirect:
>> }
>>
>> /* complete the connection */
>> -if (ffurl_connect(rt->rtsp_hd, NULL)) {
>> +if (ffurl_connect(rt->rtsp_hd, &options)) {
>> +av_dict_free(&options);
>> err = AVERROR(EIO);
>> goto fail;
>> }
>> @@ -1818,10 +1822,12 @@ redirect:
>> ff_http_init_auth_state(rt->rtsp_hd_out, rt->rtsp_hd);
>>
>> /* complete the connection */
>> -if (ffurl_connect(rt->rtsp_hd_out, NULL)) {
>> +if (ffurl_connect(rt->rtsp_hd_out, &options)) {
>> +av_dict_free(&options);
>> err = AVERROR(EIO);
>> goto fail;
>> }
>> +av_dict_free(&options);
>> } else {
>> int ret;
>> /* open the tcp connection */
>> --
>> 2.17.1
>>
>>
>
> Updated the version, free the memory in error path, patch is here:
> https://patchwork.ffmpeg.org/patch/12620/
> I initially planned to do that then I realized the error path will trigger
> whole process to exit, which may be safe. But I agree with you, it is a
> better practice to clean-up here.
>
> Thanks for review, Michael.
>
> Best Regards,
> Jun
>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 2/6] Add common V4L2 request API code
On 2019-04-09 00:35, James Almer wrote:
> On 4/8/2019 5:12 PM, Jonas Karlman wrote:
>> Signed-off-by: Jonas Karlman
>> ---
>> configure | 8 +
>> libavcodec/Makefile | 1 +
>> libavcodec/hwaccel.h | 2 +
>> libavcodec/v4l2_request.c | 885 ++
>> libavcodec/v4l2_request.h | 65 +++
>> 5 files changed, 961 insertions(+)
>> create mode 100644 libavcodec/v4l2_request.c
>> create mode 100644 libavcodec/v4l2_request.h
>> +int ff_v4l2_request_uninit(AVCodecContext *avctx)
>> +{
>> +V4L2RequestContext *ctx = avctx->internal->hwaccel_priv_data;
>> +int ret;
>> +
>> +av_log(avctx, AV_LOG_DEBUG, "%s: avctx=%p ctx=%p\n", __func__, avctx,
>> ctx);
>> +
>> +if (ctx->video_fd >= 0) {
>> +ret = ioctl(ctx->video_fd, VIDIOC_STREAMOFF, &ctx->output_type);
>> +if (ret < 0)
>> +av_log(avctx, AV_LOG_ERROR, "%s: output stream off failed, %s
>> (%d)\n", __func__, strerror(errno), errno);
>> +
>> +ret = ioctl(ctx->video_fd, VIDIOC_STREAMOFF, &ctx->format.type);
>> +if (ret < 0)
>> +av_log(avctx, AV_LOG_ERROR, "%s: capture stream off failed, %s
>> (%d)\n", __func__, strerror(errno), errno);
>> +}
>> +
>> +if (avctx->hw_frames_ctx) {
>> +AVHWFramesContext *hwfc =
>> (AVHWFramesContext*)avctx->hw_frames_ctx->data;
>> +av_buffer_pool_reclaim(hwfc->pool);
> What's the idea behind this? Calling this function will free all the
> unused buffers currently residing in the pool, but will do nothing with
> those already in assigned to some AVBufferRef created with
> av_buffer_pool_get(). Those will in fact go back to the pool once they
> are not needed anymore.
>
> Other than immediately freeing up some memory, the new function you
> added is not going to do much. It wont be until av_buffer_pool_uninit()
> is called and all the assigned buffers if any returned to the pool that
> everything will be effectively freed.
This was added to solve an issue with seeking h264 files, during seeking a new
hwaccel instance / buffer pool would be created (pps/sps changed)
and since we need to pre-allocate output/capture buffers during hwaccel init
there was situations where too much CMA memory got consumed
while there was multiple hwaccel instances / buffer pools active.
This may have been a bigger issue in the beginning when we pre-allocated 20
buffers similar to vaapi hwaccel and when we had a bug in Kodi that
would hold reference on two instead of one AVFrame while waiting on next frame
being decoded, in some situations (seeking too fast) this bug
resulted in Kodi having reference on AVFrame's from three different buffer
pools requiring enough CMA memory for 60 capture and output buffers.
We have since then fixed the bug in Kodi and minimized the number of buffers
that is pre-allocated in hwaccel.
Immediately freeing up unused buffers helps the likelihood of successful
initializing a new hwaccel instance / buffer pool, especially useful for 4K
content.
Regards,
Jonas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 2/6] Add common V4L2 request API code
On 4/8/2019 5:12 PM, Jonas Karlman wrote:
> Signed-off-by: Jonas Karlman
> ---
> configure | 8 +
> libavcodec/Makefile | 1 +
> libavcodec/hwaccel.h | 2 +
> libavcodec/v4l2_request.c | 885 ++
> libavcodec/v4l2_request.h | 65 +++
> 5 files changed, 961 insertions(+)
> create mode 100644 libavcodec/v4l2_request.c
> create mode 100644 libavcodec/v4l2_request.h
> +int ff_v4l2_request_uninit(AVCodecContext *avctx)
> +{
> +V4L2RequestContext *ctx = avctx->internal->hwaccel_priv_data;
> +int ret;
> +
> +av_log(avctx, AV_LOG_DEBUG, "%s: avctx=%p ctx=%p\n", __func__, avctx,
> ctx);
> +
> +if (ctx->video_fd >= 0) {
> +ret = ioctl(ctx->video_fd, VIDIOC_STREAMOFF, &ctx->output_type);
> +if (ret < 0)
> +av_log(avctx, AV_LOG_ERROR, "%s: output stream off failed, %s
> (%d)\n", __func__, strerror(errno), errno);
> +
> +ret = ioctl(ctx->video_fd, VIDIOC_STREAMOFF, &ctx->format.type);
> +if (ret < 0)
> +av_log(avctx, AV_LOG_ERROR, "%s: capture stream off failed, %s
> (%d)\n", __func__, strerror(errno), errno);
> +}
> +
> +if (avctx->hw_frames_ctx) {
> +AVHWFramesContext *hwfc =
> (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> +av_buffer_pool_reclaim(hwfc->pool);
What's the idea behind this? Calling this function will free all the
unused buffers currently residing in the pool, but will do nothing with
those already in assigned to some AVBufferRef created with
av_buffer_pool_get(). Those will in fact go back to the pool once they
are not needed anymore.
Other than immediately freeing up some memory, the new function you
added is not going to do much. It wont be until av_buffer_pool_uninit()
is called and all the assigned buffers if any returned to the pool that
everything will be effectively freed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/udp: add options send_pkt_size for udp over ip, for ts over ip, this value must be 1316(7*188)
At 2019-04-09 00:29:43, "Marton Balint" wrote: > > >On Mon, 8 Apr 2019, edward_email wrote: > >> From: “Edward.Wu” <“edward_em...@126.com”> >> >> Signed-off-by: “Edward.Wu” <“edward_em...@126.com”> >> --- >> libavformat/udp.c | 45 - >> 1 file changed, 44 insertions(+), 1 deletion(-) > >Why is this patch needed at all? If you want fixed packet size, you simply >use -pkt_size 1316 -flush_packets 0. thanks for your reminding，I try these two parameters, it's OK. > >Regards, >Marton >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link above, or email >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/bintext: Add error message when resolution is too small for font.
---
libavcodec/bintext.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/bintext.c b/libavcodec/bintext.c
index d85f2c2dd4..49b75c9e27 100644
--- a/libavcodec/bintext.c
+++ b/libavcodec/bintext.c
@@ -93,8 +93,10 @@ static av_cold int decode_init(AVCodecContext *avctx)
break;
}
}
-if (avctx->width < FONT_WIDTH || avctx->height < s->font_height)
+if (avctx->width < FONT_WIDTH || avctx->height < s->font_height) {
+av_log(avctx, AV_LOG_ERROR, "Resolution too small for font.\n");
return AVERROR_INVALIDDATA;
+}
return 0;
}
--
2.21.0.392.gf8f6787159e-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 1/6] avutil: add av_buffer_pool_reclaim()
On 2019-04-08 23:04, James Almer wrote:
> On 4/8/2019 5:12 PM, Jonas Karlman wrote:
>> Signed-off-by: Jonas Karlman
>> ---
>> libavutil/buffer.c | 13 +
>> libavutil/buffer.h | 5 +
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
>> index 8d1aa5fa84..9c5d530c7a 100644
>> --- a/libavutil/buffer.c
>> +++ b/libavutil/buffer.c
>> @@ -272,6 +272,19 @@ static void buffer_pool_free(AVBufferPool *pool)
>> av_freep(&pool);
>> }
>>
>> +void av_buffer_pool_reclaim(AVBufferPool *pool)
>> +{
>> +ff_mutex_lock(&pool->mutex);
>> +while (pool->pool) {
>> +BufferPoolEntry *buf = pool->pool;
>> +pool->pool = buf->next;
>> +
>> +buf->free(buf->opaque, buf->data);
>> +av_freep(&buf);
>> +}
>> +ff_mutex_unlock(&pool->mutex);
>> +}
>> +
>> void av_buffer_pool_uninit(AVBufferPool **ppool)
>> {
>> AVBufferPool *pool;
>> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
>> index 73b6bd0b14..fab745f853 100644
>> --- a/libavutil/buffer.h
>> +++ b/libavutil/buffer.h
>> @@ -266,6 +266,11 @@ AVBufferPool *av_buffer_pool_init2(int size, void
>> *opaque,
>> AVBufferRef* (*alloc)(void *opaque, int
>> size),
>> void (*pool_free)(void *opaque));
>>
>> +/**
>> + * Free all available buffers in a buffer pool.
>> + */
>> + void av_buffer_pool_reclaim(AVBufferPool *pool);
> Maybe flush instead of reclaim? It'd be more in line with other API.
>
> Also, you need to add an entry for the new function in doc/APIChanges,
> and increase LIBAVUTIL_VERSION_MINOR by 1 in libavutil/version.h
Thanks, I will rename to av_buffer_pool_flush() and add to doc/APIChanges and
fix LIBAVUTIL_VERSION_MINOR in v2.
Regards,
Jonas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 6/6] Add and use private linux headers for V4L2 request API ctrls
On 2019-04-08 22:57, Carl Eugen Hoyos wrote: > 2019-04-08 22:14 GMT+02:00, Jonas Karlman : >> From: Jernej Skrabec >> >> --- >> libavcodec/h264-ctrls.h | 192 +++ >> libavcodec/hevc-ctrls.h | 197 >> libavcodec/mpeg2-ctrls.h| 82 + >> libavcodec/v4l2_request_h264.c | 5 +- >> libavcodec/v4l2_request_hevc.c | 1 + >> libavcodec/v4l2_request_mpeg2.c | 1 + >> 6 files changed, 476 insertions(+), 2 deletions(-) >> create mode 100644 libavcodec/h264-ctrls.h >> create mode 100644 libavcodec/hevc-ctrls.h >> create mode 100644 libavcodec/mpeg2-ctrls.h >> >> diff --git a/libavcodec/h264-ctrls.h b/libavcodec/h264-ctrls.h >> new file mode 100644 >> index 00..e2f83b3cdb >> --- /dev/null >> +++ b/libavcodec/h264-ctrls.h >> @@ -0,0 +1,192 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +/* >> + * These are the H.264 state controls for use with stateless H.264 >> + * codec drivers. > If this is the sixth patch, how does compilation of the first > five patches work without it? It currently does not, the non-public kernel headers containing format ctrls was added to patchset if someone wants to compile the code. I forgot to add a DO-NOT-MERGE tag to this patch, the V4L2 format ctrls should come from kernel linux/videodev2.h uapi header once they are stable in a future kernel version. Regards, Jonas > > Carl Eugen > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 2/6] Add common V4L2 request API code
On 2019-04-08 22:52, Carl Eugen Hoyos wrote: > 2019-04-08 22:12 GMT+02:00, Jonas Karlman : >> Signed-off-by: Jonas Karlman >> --- >> configure | 8 + >> libavcodec/Makefile | 1 + >> libavcodec/hwaccel.h | 2 + >> libavcodec/v4l2_request.c | 885 ++ >> libavcodec/v4l2_request.h | 65 +++ >> 5 files changed, 961 insertions(+) >> create mode 100644 libavcodec/v4l2_request.c >> create mode 100644 libavcodec/v4l2_request.h >> >> diff --git a/configure b/configure >> index f6123f53e5..ea3945d34a 100755 >> --- a/configure >> +++ b/configure >> @@ -271,6 +271,7 @@ External library support: >>--enable-libtls enable LibreSSL (via libtls), needed for https >> support >> if openssl, gnutls or mbedtls is not used [no] >>--enable-libtwolame enable MP2 encoding via libtwolame [no] >> + --enable-libudev enable libudev [no] >>--enable-libv4l2 enable libv4l2/v4l-utils [no] >>--enable-libvidstab enable video stabilization using vid.stab [no] >>--enable-libvmaf enable vmaf filter via libvmaf [no] >> @@ -335,6 +336,7 @@ External library support: >>--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no] >>--enable-rkmpp enable Rockchip Media Process Platform code [no] >>--disable-v4l2-m2m disable V4L2 mem2mem code [autodetect] >> + --enable-v4l2-requestenable V4L2 request API code [no] > Why can't this be auto-detected? I guess it could, will look into using auto-detected for v2. Regards, Jonas > > Carl Eugen > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 0/6] Add V4L2 request API hwaccels
On 2019-04-08 22:41, Mark Thompson wrote: > On 08/04/2019 21:09, Jonas Karlman wrote: >> Hello, >> >> This is a request for comments on a new hwaccel using the V4L2 request API >> that was created in collaboration with Jernej Skrabec. >> >> The V4L2 ctrls needed for statless decoding is not yet stable and reside in >> private kernel headers. This patchset adds a copy of the kernel private >> headers >> needed for the hwaccel to compile. > When is the interface likely to become stable? The V4L2 request API should already be considered stable and is part of linux uapi since v4.20. Hwaccels make use of a function v4l2_timeval_to_ns that was added in v5.0, configure should check for this function. The format ctrls needed for stateless decoding is however not stable and only MPEG-2 ctrls has been added in a non-public kernel header at [1], it will hopefully be promoted to linux/videodev2.h uapi header in 2-4 linux versions. H264 and HEVC ctrls is currently in review on linux-media mailing list and is even further away. [1] https://github.com/torvalds/linux/blob/master/include/media/mpeg2-ctrls.h > > I don't think including kernel headers here is a good idea. Please just > check for appropriate headers - if the user is capable of building this then > they can also install the headers for their kernel. Sorry for not being more clear in my cover letter, the headers is not intended to be added to ffmpeg and was only added to patchset in order to be able to build working hwaccels. The format ctrls has intentionally been put in non-public kernel headers that wont be installed into userspace since the ctrls currently is considered unstable. My hope is to get early feedback on current code and to re-submit hwaccels once format ctrls have been promoted to public kernel uapi headers. > > > If I wanted to buy a single Allwinner SBC to test this on, what should I get? The Pine H64 "Model B" at [2] could be a good candidate. The MPEG-2 hwaccel should also works on Rockchip RK3399 SBCs with rockchip vpu patchset at [3]. Support for Rockchip RK3288 SBCs requires additional patches at [4] and [5]. [2] https://www.pine64.org/?product_cat=model-b [3] https://patchwork.kernel.org/project/linux-media/list/?series=87499 [4] https://github.com/Kwiboo/linux-rockchip/commit/1f78093e05c7360515a185f48b7c5cb8ba1e3e15 [5] https://github.com/Kwiboo/linux-rockchip/commit/9216da3f1521a0be5889235abe7fa093a4894160 Regards, Jonas > > Thanks, > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 1/6] avutil: add av_buffer_pool_reclaim()
On 4/8/2019 5:12 PM, Jonas Karlman wrote:
> Signed-off-by: Jonas Karlman
> ---
> libavutil/buffer.c | 13 +
> libavutil/buffer.h | 5 +
> 2 files changed, 18 insertions(+)
>
> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
> index 8d1aa5fa84..9c5d530c7a 100644
> --- a/libavutil/buffer.c
> +++ b/libavutil/buffer.c
> @@ -272,6 +272,19 @@ static void buffer_pool_free(AVBufferPool *pool)
> av_freep(&pool);
> }
>
> +void av_buffer_pool_reclaim(AVBufferPool *pool)
> +{
> +ff_mutex_lock(&pool->mutex);
> +while (pool->pool) {
> +BufferPoolEntry *buf = pool->pool;
> +pool->pool = buf->next;
> +
> +buf->free(buf->opaque, buf->data);
> +av_freep(&buf);
> +}
> +ff_mutex_unlock(&pool->mutex);
> +}
> +
> void av_buffer_pool_uninit(AVBufferPool **ppool)
> {
> AVBufferPool *pool;
> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
> index 73b6bd0b14..fab745f853 100644
> --- a/libavutil/buffer.h
> +++ b/libavutil/buffer.h
> @@ -266,6 +266,11 @@ AVBufferPool *av_buffer_pool_init2(int size, void
> *opaque,
> AVBufferRef* (*alloc)(void *opaque, int
> size),
> void (*pool_free)(void *opaque));
>
> +/**
> + * Free all available buffers in a buffer pool.
> + */
> + void av_buffer_pool_reclaim(AVBufferPool *pool);
Maybe flush instead of reclaim? It'd be more in line with other API.
Also, you need to add an entry for the new function in doc/APIChanges,
and increase LIBAVUTIL_VERSION_MINOR by 1 in libavutil/version.h
> +
> /**
> * Mark the pool as being available for freeing. It will actually be freed
> only
> * once all the allocated buffers associated with the pool are released.
> Thus it
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] Added XV Support
2019-04-08 22:37 GMT+02:00, Shivam Goyal : > Updated patch for ticket #3720 . > > I have tried to improve the patch as suggested. Please fix the commit message as suggested by Lauri and please make above (first) line part of the commit message. The first avio_seek() should be a skip, the header function always starts reading the file from the top. > +offset = (((avio_r8(ic) + rot)&0xff)<<24) | > +(((avio_r8(ic) + rot)&0xff)<<16) | > +(((avio_r8(ic) + rot)&0xff)<<8) | > +(((avio_r8(ic) + rot)&0xff)) + 0x20; offset = ((avio_r8(ic) + rot & 0xff) << 24 | (avio_r8(ic) + rot & 0xff) << 16... assuming this produces no warnings. There is no 12-char indentation, only vertical alignment. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 2/6] Add common V4L2 request API code
2019-04-08 22:12 GMT+02:00, Jonas Karlman : > Signed-off-by: Jonas Karlman > --- > configure | 8 + > libavcodec/Makefile | 1 + > libavcodec/hwaccel.h | 2 + > libavcodec/v4l2_request.c | 885 ++ > libavcodec/v4l2_request.h | 65 +++ > 5 files changed, 961 insertions(+) > create mode 100644 libavcodec/v4l2_request.c > create mode 100644 libavcodec/v4l2_request.h > > diff --git a/configure b/configure > index f6123f53e5..ea3945d34a 100755 > --- a/configure > +++ b/configure > @@ -271,6 +271,7 @@ External library support: >--enable-libtls enable LibreSSL (via libtls), needed for https > support > if openssl, gnutls or mbedtls is not used [no] >--enable-libtwolame enable MP2 encoding via libtwolame [no] > + --enable-libudev enable libudev [no] >--enable-libv4l2 enable libv4l2/v4l-utils [no] >--enable-libvidstab enable video stabilization using vid.stab [no] >--enable-libvmaf enable vmaf filter via libvmaf [no] > @@ -335,6 +336,7 @@ External library support: >--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no] >--enable-rkmpp enable Rockchip Media Process Platform code [no] >--disable-v4l2-m2m disable V4L2 mem2mem code [autodetect] > + --enable-v4l2-requestenable V4L2 request API code [no] Why can't this be auto-detected? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 6/6] Add and use private linux headers for V4L2 request API ctrls
2019-04-08 22:14 GMT+02:00, Jonas Karlman : > From: Jernej Skrabec > > --- > libavcodec/h264-ctrls.h | 192 +++ > libavcodec/hevc-ctrls.h | 197 > libavcodec/mpeg2-ctrls.h| 82 + > libavcodec/v4l2_request_h264.c | 5 +- > libavcodec/v4l2_request_hevc.c | 1 + > libavcodec/v4l2_request_mpeg2.c | 1 + > 6 files changed, 476 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/h264-ctrls.h > create mode 100644 libavcodec/hevc-ctrls.h > create mode 100644 libavcodec/mpeg2-ctrls.h > > diff --git a/libavcodec/h264-ctrls.h b/libavcodec/h264-ctrls.h > new file mode 100644 > index 00..e2f83b3cdb > --- /dev/null > +++ b/libavcodec/h264-ctrls.h > @@ -0,0 +1,192 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * These are the H.264 state controls for use with stateless H.264 > + * codec drivers. If this is the sixth patch, how does compilation of the first five patches work without it? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC 0/6] Add V4L2 request API hwaccels
On 08/04/2019 21:09, Jonas Karlman wrote: > Hello, > > This is a request for comments on a new hwaccel using the V4L2 request API > that was created in collaboration with Jernej Skrabec. > > The V4L2 ctrls needed for statless decoding is not yet stable and reside in > private kernel headers. This patchset adds a copy of the kernel private > headers > needed for the hwaccel to compile. When is the interface likely to become stable? I don't think including kernel headers here is a good idea. Please just check for appropriate headers - if the user is capable of building this then they can also install the headers for their kernel. If I wanted to buy a single Allwinner SBC to test this on, what should I get? Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] Added XV Support
Updated patch for ticket #3720 .
I have tried to improve the patch as suggested.
>From 8c4cd8cfc2b7b07cebbfefb96fc9bb9e92668385 Mon Sep 17 00:00:00 2001
From: Shivam Goyal
Date: Tue, 9 Apr 2019 02:01:17 +0530
Subject: [PATCH] Added XV Support v3
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/flvdec.c | 84
3 files changed, 86 insertions(+)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..262df876e9 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -563,6 +563,7 @@ OBJS-$(CONFIG_XBIN_DEMUXER) += bintext.o sauce.o
OBJS-$(CONFIG_XMV_DEMUXER) += xmv.o
OBJS-$(CONFIG_XVAG_DEMUXER) += xvag.o
OBJS-$(CONFIG_XWMA_DEMUXER) += xwma.o
+OBJS-$(CONFIG_XV_DEMUXER)+= flvdec.o
OBJS-$(CONFIG_YOP_DEMUXER) += yop.o
OBJS-$(CONFIG_YUV4MPEGPIPE_DEMUXER) += yuv4mpegdec.o
OBJS-$(CONFIG_YUV4MPEGPIPE_MUXER)+= yuv4mpegenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d316a0529a..b499186071 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -456,6 +456,7 @@ extern AVOutputFormat ff_wv_muxer;
extern AVInputFormat ff_xa_demuxer;
extern AVInputFormat ff_xbin_demuxer;
extern AVInputFormat ff_xmv_demuxer;
+extern AVInputFormat ff_xv_demuxer;
extern AVInputFormat ff_xvag_demuxer;
extern AVInputFormat ff_xwma_demuxer;
extern AVInputFormat ff_yop_demuxer;
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index b531a39adc..e98f32f94f 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -127,6 +127,19 @@ static int kux_probe(const AVProbeData *p)
return 0;
}
+static int xv_probe(const AVProbeData *p)
+{
+const uint8_t *d = p->buf;
+
+if (d[0] == 'X' &&
+d[1] == 'L' &&
+d[2] == 'V' &&
+d[3] == 'F') {
+return AVPROBE_SCORE_EXTENSION + 1;
+}
+return 0;
+}
+
static void add_keyframes_index(AVFormatContext *s)
{
FLVContext *flv = s->priv_data;
@@ -459,6 +472,12 @@ static int parse_keyframes_index(AVFormatContext *s, AVIOContext *ioc, int64_t m
}
}
+if(!strcmp(s->iformat->name , "xv")){
+for (i=0; i < FFMIN(2,fileposlen); i++){
+filepositions[i] += 0x20;
+}
+}
+
if (timeslen == fileposlen && fileposlen>1 && max_pos <= filepositions[0]) {
for (i = 0; i < FFMIN(2,fileposlen); i++) {
flv->validate_index[i].pos = filepositions[i];
@@ -783,6 +802,50 @@ static int flv_read_header(AVFormatContext *s)
return 0;
}
+static int xv_read_header(AVFormatContext *s)
+{
+int flags;
+FLVContext *xv = s->priv_data;
+AVIOContext *ic = s->pb;
+int offset;
+int rot;
+
+//Find the rot value for rotating the bytes
+avio_seek(ic, 0x20, SEEK_SET);
+rot = 0x46 - avio_r8(ic);
+
+avio_skip(ic, 3);
+
+flags = (avio_r8(ic) + rot ) & 0xff;
+
+xv->missing_streams = flags & (FLV_HEADER_FLAG_HASVIDEO | FLV_HEADER_FLAG_HASAUDIO);
+
+s->ctx_flags |= AVFMTCTX_NOHEADER;
+
+offset = (((avio_r8(ic) + rot)&0xff)<<24) |
+(((avio_r8(ic) + rot)&0xff)<<16) |
+(((avio_r8(ic) + rot)&0xff)<<8) |
+(((avio_r8(ic) + rot)&0xff)) + 0x20;
+
+avio_seek(ic, offset + 4, SEEK_SET);
+
+
+// Will modify the current buffer, as only
+// the bytes from 0x20 to 0x200400 are needed to decode
+int64_t pos = ic->pos + ic->buf_ptr - ic->buf_end;
+for(int i = 0; i < 0x400; i++){
+if(pos >= 0x200400) break;
+ic->buf_ptr[i] = (ic->buf_ptr[i] + rot) & 0xff;
+pos++;
+}
+
+s->start_time = 0;
+xv->sum_flv_tag_size = 0;
+xv->last_keyframe_stream_index = -1;
+
+return 0;
+}
+
static int flv_read_close(AVFormatContext *s)
{
int i;
@@ -1424,3 +1487,24 @@ AVInputFormat ff_kux_demuxer = {
.extensions = "kux",
.priv_class = &kux_class,
};
+
+static const AVClass xv_class = {
+.class_name = "xvdec",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+AVInputFormat ff_xv_demuxer = {
+.name = "xv",
+.long_name = NULL_IF_CONFIG_SMALL("Xunlei(Thunder) Video File"),
+.priv_data_size = sizeof(FLVContext),
+.read_probe = xv_probe,
+.read_header= xv_read_header,
+.read_packet= flv_read_packet,
+.read_seek = flv_read_seek,
+.read_close = flv_read_close,
+.extensions = "xv",
+.priv_class = &xv_class,
+.flags = AVFMT_TS_DISCONT
+};
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On Sat, Apr 6, 2019, at 8:42 AM, Balint Marton wrote: > > Question: Do you support extending the voting committte with the people > above? Yes ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi: add nlmeans_opencl filter
On 01/04/2019 08:52, Ruiling Song wrote:
> Signed-off-by: Ruiling Song
> ---
> This filter runs about 2x faster on integrated GPU than nlmeans on my Skylake
> CPU.
> Anybody like to give some comments?
Nice!
> configure | 1 +
> doc/filters.texi| 4 +
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/opencl/nlmeans.cl | 108 +
> libavfilter/opencl_source.h | 1 +
> libavfilter/vf_nlmeans_opencl.c | 390
> 7 files changed, 506 insertions(+)
> create mode 100644 libavfilter/opencl/nlmeans.cl
> create mode 100644 libavfilter/vf_nlmeans_opencl.c
>
> diff --git a/configure b/configure
> index f6123f53e5..a233512491 100755
> --- a/configure
> +++ b/configure
> @@ -3460,6 +3460,7 @@ mpdecimate_filter_select="pixelutils"
> minterpolate_filter_select="scene_sad"
> mptestsrc_filter_deps="gpl"
> negate_filter_deps="lut_filter"
> +nlmeans_opencl_filter_deps="opencl"
> nnedi_filter_deps="gpl"
> ocr_filter_deps="libtesseract"
> ocv_filter_deps="libopencv"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 867607d870..21c2c1a4b5 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19030,6 +19030,10 @@ Apply erosion filter with threshold0 set to 30,
> threshold1 set 40, threshold2 se
> @end example
> @end itemize
>
> +@section nlmeans_opencl
> +
> +Non-local Means denoise filter through OpenCL, this filter accepts same
> options as @ref{nlmeans}.
> +
> @section overlay_opencl
>
> Overlay one video on top of another.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fef6ec5c55..92039bfdcf 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -291,6 +291,7 @@ OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o
> OBJS-$(CONFIG_MPDECIMATE_FILTER) += vf_mpdecimate.o
> OBJS-$(CONFIG_NEGATE_FILTER) += vf_lut.o
> OBJS-$(CONFIG_NLMEANS_FILTER)+= vf_nlmeans.o
> +OBJS-$(CONFIG_NLMEANS_OPENCL_FILTER) += vf_nlmeans_opencl.o opencl.o
> opencl/nlmeans.o
> OBJS-$(CONFIG_NNEDI_FILTER) += vf_nnedi.o
> OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
> OBJS-$(CONFIG_NOISE_FILTER) += vf_noise.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c51ae0f3c7..2a6390c92d 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -277,6 +277,7 @@ extern AVFilter ff_vf_mix;
> extern AVFilter ff_vf_mpdecimate;
> extern AVFilter ff_vf_negate;
> extern AVFilter ff_vf_nlmeans;
> +extern AVFilter ff_vf_nlmeans_opencl;
> extern AVFilter ff_vf_nnedi;
> extern AVFilter ff_vf_noformat;
> extern AVFilter ff_vf_noise;
> diff --git a/libavfilter/opencl/nlmeans.cl b/libavfilter/opencl/nlmeans.cl
> new file mode 100644
> index 00..dcb04834ca
> --- /dev/null
> +++ b/libavfilter/opencl/nlmeans.cl
> @@ -0,0 +1,108 @@
> +/*
> + * 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
> + */
> +
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
> + CLK_ADDRESS_CLAMP_TO_EDGE |
> + CLK_FILTER_NEAREST);
> +
> +kernel void horiz_sum(__global uint4 *ii,
> + __read_only image2d_t src,
> + int width,
> + int height,
> + int4 dx,
> + int4 dy)
> +{
> +
> +int y = get_global_id(0);
> +int work_size = get_global_size(0);
> +
> +uint4 sum = (uint4)(0);
> +float4 s2;
> +for (int i = 0; i < width; i++) {
> +float s1 = read_imagef(src, sampler, (int2)(i, y)).x;
> +s2.x = read_imagef(src, sampler, (int2)(i+dx.x, y+dy.x)).x;
> +s2.y = read_imagef(src, sampler, (int2)(i+dx.y, y+dy.y)).x;
> +s2.z = read_imagef(src, sampler, (int2)(i+dx.z, y+dy.z)).x;
> +s2.w = read_imagef(src, sampler, (int2)(i+dx.w, y+dy.w)).x;
> +sum += convert_uint4((s1-s2)*(s1-s2) * 255*255);
> +ii[y * width + i] = sum;
> +}
> +}
> +
> +kernel void vert_sum(__global uint4 *ii,
> + int width,
> + int height)
> +{
> +int x =
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On Sat, Apr 6, 2019 at 6:42 PM Balint Marton wrote: > > Hi All > > Here is a call for the people in the voting committee [1] on the decision > of extending it. > > Using the same guidelines as in the second extension [2], the following > candidates were found: > > git log libav/master..master --no-merges --since=2018-03-30T00:00:00Z > --until 2019-03-30T00:00:00Z --pretty=fuller | grep '^Commit:' | sed > 's/<.*//' |sort | uniq -c | sort -nr > > 662 Commit: Michael Niedermayer > 528 Commit: Paul B Mahol > 227 Commit: James Almer > 194 Commit: Carl Eugen Hoyos > 183 Commit: Mark Thompson > 141 Commit: Marton Balint > 99 Commit: Jun Zhao > 84 Commit: Steven Liu > 73 Commit: Martin Vignali > 64 Commit: Gyan Doshi > 55 Commit: Aman Gupta > 42 Commit: Timo Rothenpieler > 35 Commit: Zhong Li > 31 Commit: Karthick Jeyapal > 31 Commit: Karthick J > 23 Commit: Rostislav Pehlivanov > 22 Commit: Peter Ross > 22 Commit: Clément Bœsch > 21 Commit: Lou Logan > 21 Commit: Jan Ekström > > Some of these developers are already in the voting committee, the new ones > would be: > > Aman Gupta > Gyan Doshi > Jan Ekström > Jun Zhao > Karthick Jeyapal > Mark Thompson > Martin Vignali > Peter Ross > Steven Liu > Timo Rothenpieler > Zhong Li > Yes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC 6/6] Add and use private linux headers for V4L2 request API ctrls
From: Jernej Skrabec
---
libavcodec/h264-ctrls.h | 192 +++
libavcodec/hevc-ctrls.h | 197
libavcodec/mpeg2-ctrls.h| 82 +
libavcodec/v4l2_request_h264.c | 5 +-
libavcodec/v4l2_request_hevc.c | 1 +
libavcodec/v4l2_request_mpeg2.c | 1 +
6 files changed, 476 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/h264-ctrls.h
create mode 100644 libavcodec/hevc-ctrls.h
create mode 100644 libavcodec/mpeg2-ctrls.h
diff --git a/libavcodec/h264-ctrls.h b/libavcodec/h264-ctrls.h
new file mode 100644
index 00..e2f83b3cdb
--- /dev/null
+++ b/libavcodec/h264-ctrls.h
@@ -0,0 +1,192 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * These are the H.264 state controls for use with stateless H.264
+ * codec drivers.
+ *
+ * It turns out that these structs are not stable yet and will undergo
+ * more changes. So keep them private until they are stable and ready to
+ * become part of the official public API.
+ */
+
+#ifndef _H264_CTRLS_H_
+#define _H264_CTRLS_H_
+
+/*
+ * This is put insanely high to avoid conflicting with controls that
+ * would be added during the phase where those controls are not
+ * stable. It should be fixed eventually.
+ */
+#define V4L2_CID_MPEG_VIDEO_H264_SPS (V4L2_CID_MPEG_BASE+1000)
+#define V4L2_CID_MPEG_VIDEO_H264_PPS (V4L2_CID_MPEG_BASE+1001)
+#define V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX
(V4L2_CID_MPEG_BASE+1002)
+#define V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS (V4L2_CID_MPEG_BASE+1003)
+#define V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (V4L2_CID_MPEG_BASE+1004)
+
+/* enum v4l2_ctrl_type type values */
+#define V4L2_CTRL_TYPE_H264_SPS0x0110
+#define V4L2_CTRL_TYPE_H264_PPS0x0111
+#define V4L2_CTRL_TYPE_H264_SCALING_MATRIX 0x0112
+#define V4L2_CTRL_TYPE_H264_SLICE_PARAMS 0x0113
+#define V4L2_CTRL_TYPE_H264_DECODE_PARAMS 0x0114
+
+#define V4L2_H264_SPS_CONSTRAINT_SET0_FLAG 0x01
+#define V4L2_H264_SPS_CONSTRAINT_SET1_FLAG 0x02
+#define V4L2_H264_SPS_CONSTRAINT_SET2_FLAG 0x04
+#define V4L2_H264_SPS_CONSTRAINT_SET3_FLAG 0x08
+#define V4L2_H264_SPS_CONSTRAINT_SET4_FLAG 0x10
+#define V4L2_H264_SPS_CONSTRAINT_SET5_FLAG 0x20
+
+#define V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE 0x01
+#define V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS 0x02
+#define V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO 0x04
+#define V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED 0x08
+#define V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY 0x10
+#define V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD 0x20
+#define V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE0x40
+
+struct v4l2_ctrl_h264_sps {
+ __u8 profile_idc;
+ __u8 constraint_set_flags;
+ __u8 level_idc;
+ __u8 seq_parameter_set_id;
+ __u8 chroma_format_idc;
+ __u8 bit_depth_luma_minus8;
+ __u8 bit_depth_chroma_minus8;
+ __u8 log2_max_frame_num_minus4;
+ __u8 pic_order_cnt_type;
+ __u8 log2_max_pic_order_cnt_lsb_minus4;
+ __u8 max_num_ref_frames;
+ __u8 num_ref_frames_in_pic_order_cnt_cycle;
+ __s32 offset_for_ref_frame[255];
+ __s32 offset_for_non_ref_pic;
+ __s32 offset_for_top_to_bottom_field;
+ __u16 pic_width_in_mbs_minus1;
+ __u16 pic_height_in_map_units_minus1;
+ __u32 flags;
+};
+
+#define V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE 0x0001
+#define V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT 0x0002
+#define V4L2_H264_PPS_FLAG_WEIGHTED_PRED 0x0004
+#define V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT 0x0008
+#define V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED 0x0010
+#define V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT 0x0020
+#define V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE 0x0040
+#define V4L2_H264_PPS_FLAG_PIC_SCALING_MATRIX_PRESENT 0x0080
+
+struct v4l2_ctrl_h264_pps {
+ __u8 pic_parameter_set_id;
+ __u8 seq_parameter_set_id;
+ __u8 num_slice_groups_minus1;
+ __u8 num_ref_idx_l0_default_active_minus1;
+ __u8 num_ref_idx_l1_default_active_minus1;
+ __u8 weighted_bipred_idc;
+ __s8 pic_init_qp_minus26;
+ __s8 pic_init_qs_minus26;
+ __s8 chroma_qp_index_offset;
+ __s8 second_chroma_qp_index_offset;
+ __u16 flags;
+};
+
+struct v4l2_ctrl_h264_scaling_matrix {
+ __u8 scaling_list_4x4[6][16];
+ __u8 scaling_list_8x8[6][64];
+};
+
+struct v4l2_h264_weight_factors {
+ __s16 luma_weight[32];
+ __s16 luma_offset[32];
+ __s16 chroma_weight[32][2];
+ __s16 chroma_offset[32][2];
+};
+
+struct v4l2_h264_pred
[FFmpeg-devel] [RFC 5/6] Add V4L2 request API hevc hwaccel
From: Jernej Skrabec
Signed-off-by: Jernej Skrabec
Signed-off-by: Jonas Karlman
---
configure | 3 +
libavcodec/Makefile| 1 +
libavcodec/hevcdec.c | 10 +
libavcodec/hwaccels.h | 1 +
libavcodec/v4l2_request_hevc.c | 391 +
5 files changed, 406 insertions(+)
create mode 100644 libavcodec/v4l2_request_hevc.c
diff --git a/configure b/configure
index b4fda11e13..6853ec258d 100755
--- a/configure
+++ b/configure
@@ -2893,6 +2893,8 @@ hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
hevc_dxva2_hwaccel_select="hevc_decoder"
hevc_nvdec_hwaccel_deps="nvdec"
hevc_nvdec_hwaccel_select="hevc_decoder"
+hevc_v4l2request_hwaccel_deps="v4l2_request hevc_v4l2_request"
+hevc_v4l2request_hwaccel_select="hevc_decoder"
hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
hevc_vaapi_hwaccel_select="hevc_decoder"
hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
@@ -6386,6 +6388,7 @@ check_cc vp9_v4l2_m2m linux/videodev2.h "int i =
V4L2_PIX_FMT_VP9;"
check_func_headers "linux/media.h linux/videodev2.h" v4l2_timeval_to_ns
check_cc h264_v4l2_request linux/videodev2.h "int i =
V4L2_PIX_FMT_H264_SLICE_RAW;"
+check_cc hevc_v4l2_request linux/videodev2.h "int i = V4L2_PIX_FMT_HEVC_SLICE;"
check_cc mpeg2_v4l2_request linux/videodev2.h "int i =
V4L2_PIX_FMT_MPEG2_SLICE;"
check_headers sys/videoio.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a6b9f1b5e2..f13dd25212 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -878,6 +878,7 @@ OBJS-$(CONFIG_HEVC_D3D11VA_HWACCEL) += dxva2_hevc.o
OBJS-$(CONFIG_HEVC_DXVA2_HWACCEL) += dxva2_hevc.o
OBJS-$(CONFIG_HEVC_NVDEC_HWACCEL) += nvdec_hevc.o
OBJS-$(CONFIG_HEVC_QSV_HWACCEL) += qsvdec_h2645.o
+OBJS-$(CONFIG_HEVC_V4L2REQUEST_HWACCEL) += v4l2_request_hevc.o
OBJS-$(CONFIG_HEVC_VAAPI_HWACCEL) += vaapi_hevc.o
OBJS-$(CONFIG_HEVC_VDPAU_HWACCEL) += vdpau_hevc.o
OBJS-$(CONFIG_MJPEG_NVDEC_HWACCEL)+= nvdec_mjpeg.o
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 857c10dd12..bb9b7f28d1 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -362,6 +362,7 @@ static enum AVPixelFormat get_format(HEVCContext *s, const
HEVCSPS *sps)
#define HWACCEL_MAX (CONFIG_HEVC_DXVA2_HWACCEL + \
CONFIG_HEVC_D3D11VA_HWACCEL * 2 + \
CONFIG_HEVC_NVDEC_HWACCEL + \
+ CONFIG_HEVC_V4L2REQUEST_HWACCEL + \
CONFIG_HEVC_VAAPI_HWACCEL + \
CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL + \
CONFIG_HEVC_VDPAU_HWACCEL)
@@ -388,6 +389,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const
HEVCSPS *sps)
#endif
#if CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL
*fmt++ = AV_PIX_FMT_VIDEOTOOLBOX;
+#endif
+#if CONFIG_HEVC_V4L2REQUEST_HWACCEL
+*fmt++ = AV_PIX_FMT_DRM_PRIME;
#endif
break;
case AV_PIX_FMT_YUV420P10:
@@ -406,6 +410,9 @@ static enum AVPixelFormat get_format(HEVCContext *s, const
HEVCSPS *sps)
#endif
#if CONFIG_HEVC_NVDEC_HWACCEL
*fmt++ = AV_PIX_FMT_CUDA;
+#endif
+#if CONFIG_HEVC_V4L2REQUEST_HWACCEL
+*fmt++ = AV_PIX_FMT_DRM_PRIME;
#endif
break;
case AV_PIX_FMT_YUV420P12:
@@ -3577,6 +3584,9 @@ AVCodec ff_hevc_decoder = {
#endif
#if CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL
HWACCEL_VIDEOTOOLBOX(hevc),
+#endif
+#if CONFIG_HEVC_V4L2REQUEST_HWACCEL
+ HWACCEL_V4L2REQUEST(hevc),
#endif
NULL
},
diff --git a/libavcodec/hwaccels.h b/libavcodec/hwaccels.h
index 003200edea..d183675abe 100644
--- a/libavcodec/hwaccels.h
+++ b/libavcodec/hwaccels.h
@@ -35,6 +35,7 @@ extern const AVHWAccel ff_hevc_d3d11va_hwaccel;
extern const AVHWAccel ff_hevc_d3d11va2_hwaccel;
extern const AVHWAccel ff_hevc_dxva2_hwaccel;
extern const AVHWAccel ff_hevc_nvdec_hwaccel;
+extern const AVHWAccel ff_hevc_v4l2request_hwaccel;
extern const AVHWAccel ff_hevc_vaapi_hwaccel;
extern const AVHWAccel ff_hevc_vdpau_hwaccel;
extern const AVHWAccel ff_hevc_videotoolbox_hwaccel;
diff --git a/libavcodec/v4l2_request_hevc.c b/libavcodec/v4l2_request_hevc.c
new file mode 100644
index 00..300c1866ce
--- /dev/null
+++ b/libavcodec/v4l2_request_hevc.c
@@ -0,0 +1,391 @@
+/*
+ * 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
[FFmpeg-devel] [RFC 4/6] Add V4L2 request API h264 hwaccel
From: Jernej Skrabec
Signed-off-by: Jernej Skrabec
Signed-off-by: Jonas Karlman
---
configure | 3 +
libavcodec/Makefile| 1 +
libavcodec/h264_slice.c| 4 +
libavcodec/h264dec.c | 3 +
libavcodec/hwaccels.h | 1 +
libavcodec/v4l2_request_h264.c | 368 +
6 files changed, 380 insertions(+)
create mode 100644 libavcodec/v4l2_request_h264.c
diff --git a/configure b/configure
index 79fa5530f1..b4fda11e13 100755
--- a/configure
+++ b/configure
@@ -2877,6 +2877,8 @@ h264_dxva2_hwaccel_deps="dxva2"
h264_dxva2_hwaccel_select="h264_decoder"
h264_nvdec_hwaccel_deps="nvdec"
h264_nvdec_hwaccel_select="h264_decoder"
+h264_v4l2request_hwaccel_deps="v4l2_request h264_v4l2_request"
+h264_v4l2request_hwaccel_select="h264_decoder"
h264_vaapi_hwaccel_deps="vaapi"
h264_vaapi_hwaccel_select="h264_decoder"
h264_vdpau_hwaccel_deps="vdpau"
@@ -6383,6 +6385,7 @@ check_cc vp8_v4l2_m2m linux/videodev2.h "int i =
V4L2_PIX_FMT_VP8;"
check_cc vp9_v4l2_m2m linux/videodev2.h "int i = V4L2_PIX_FMT_VP9;"
check_func_headers "linux/media.h linux/videodev2.h" v4l2_timeval_to_ns
+check_cc h264_v4l2_request linux/videodev2.h "int i =
V4L2_PIX_FMT_H264_SLICE_RAW;"
check_cc mpeg2_v4l2_request linux/videodev2.h "int i =
V4L2_PIX_FMT_MPEG2_SLICE;"
check_headers sys/videoio.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a26c6b38ea..a6b9f1b5e2 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -870,6 +870,7 @@ OBJS-$(CONFIG_H264_D3D11VA_HWACCEL) += dxva2_h264.o
OBJS-$(CONFIG_H264_DXVA2_HWACCEL) += dxva2_h264.o
OBJS-$(CONFIG_H264_NVDEC_HWACCEL) += nvdec_h264.o
OBJS-$(CONFIG_H264_QSV_HWACCEL) += qsvdec_h2645.o
+OBJS-$(CONFIG_H264_V4L2REQUEST_HWACCEL) += v4l2_request_h264.o
OBJS-$(CONFIG_H264_VAAPI_HWACCEL) += vaapi_h264.o
OBJS-$(CONFIG_H264_VDPAU_HWACCEL) += vdpau_h264.o
OBJS-$(CONFIG_H264_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 1c9a270fb6..a0bba6f17e 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -765,6 +765,7 @@ static enum AVPixelFormat get_pixel_format(H264Context *h,
int force_callback)
#define HWACCEL_MAX (CONFIG_H264_DXVA2_HWACCEL + \
(CONFIG_H264_D3D11VA_HWACCEL * 2) + \
CONFIG_H264_NVDEC_HWACCEL + \
+ CONFIG_H264_V4L2REQUEST_HWACCEL + \
CONFIG_H264_VAAPI_HWACCEL + \
CONFIG_H264_VIDEOTOOLBOX_HWACCEL + \
CONFIG_H264_VDPAU_HWACCEL)
@@ -849,6 +850,9 @@ static enum AVPixelFormat get_pixel_format(H264Context *h,
int force_callback)
#endif
#if CONFIG_H264_VIDEOTOOLBOX_HWACCEL
*fmt++ = AV_PIX_FMT_VIDEOTOOLBOX;
+#endif
+#if CONFIG_H264_V4L2REQUEST_HWACCEL
+*fmt++ = AV_PIX_FMT_DRM_PRIME;
#endif
if (h->avctx->codec->pix_fmts)
choices = h->avctx->codec->pix_fmts;
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 837c3b7538..161fefba1c 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1075,6 +1075,9 @@ AVCodec ff_h264_decoder = {
#endif
#if CONFIG_H264_VIDEOTOOLBOX_HWACCEL
HWACCEL_VIDEOTOOLBOX(h264),
+#endif
+#if CONFIG_H264_V4L2REQUEST_HWACCEL
+ HWACCEL_V4L2REQUEST(h264),
#endif
NULL
},
diff --git a/libavcodec/hwaccels.h b/libavcodec/hwaccels.h
index ef54de2a3b..003200edea 100644
--- a/libavcodec/hwaccels.h
+++ b/libavcodec/hwaccels.h
@@ -27,6 +27,7 @@ extern const AVHWAccel ff_h264_d3d11va_hwaccel;
extern const AVHWAccel ff_h264_d3d11va2_hwaccel;
extern const AVHWAccel ff_h264_dxva2_hwaccel;
extern const AVHWAccel ff_h264_nvdec_hwaccel;
+extern const AVHWAccel ff_h264_v4l2request_hwaccel;
extern const AVHWAccel ff_h264_vaapi_hwaccel;
extern const AVHWAccel ff_h264_vdpau_hwaccel;
extern const AVHWAccel ff_h264_videotoolbox_hwaccel;
diff --git a/libavcodec/v4l2_request_h264.c b/libavcodec/v4l2_request_h264.c
new file mode 100644
index 00..a5c56d81c3
--- /dev/null
+++ b/libavcodec/v4l2_request_h264.c
@@ -0,0 +1,368 @@
+/*
+ * 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
+ * Foundati
[FFmpeg-devel] [RFC 3/6] Add V4L2 request API mpeg2 hwaccel
Signed-off-by: Jonas Karlman
---
configure | 3 +
libavcodec/Makefile | 1 +
libavcodec/hwaccels.h | 1 +
libavcodec/mpeg12dec.c | 6 ++
libavcodec/v4l2_request_mpeg2.c | 154
5 files changed, 165 insertions(+)
create mode 100644 libavcodec/v4l2_request_mpeg2.c
diff --git a/configure b/configure
index ea3945d34a..79fa5530f1 100755
--- a/configure
+++ b/configure
@@ -2919,6 +2919,8 @@ mpeg2_dxva2_hwaccel_deps="dxva2"
mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
mpeg2_nvdec_hwaccel_deps="nvdec"
mpeg2_nvdec_hwaccel_select="mpeg2video_decoder"
+mpeg2_v4l2request_hwaccel_deps="v4l2_request mpeg2_v4l2_request"
+mpeg2_v4l2request_hwaccel_select="mpeg2video_decoder"
mpeg2_vaapi_hwaccel_deps="vaapi"
mpeg2_vaapi_hwaccel_select="mpeg2video_decoder"
mpeg2_vdpau_hwaccel_deps="vdpau"
@@ -6381,6 +6383,7 @@ check_cc vp8_v4l2_m2m linux/videodev2.h "int i =
V4L2_PIX_FMT_VP8;"
check_cc vp9_v4l2_m2m linux/videodev2.h "int i = V4L2_PIX_FMT_VP9;"
check_func_headers "linux/media.h linux/videodev2.h" v4l2_timeval_to_ns
+check_cc mpeg2_v4l2_request linux/videodev2.h "int i =
V4L2_PIX_FMT_MPEG2_SLICE;"
check_headers sys/videoio.h
test_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse; vfse.discrete.width
= 0;" && enable_sanitized struct_v4l2_frmivalenum_discrete
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 796727dde7..a26c6b38ea 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -889,6 +889,7 @@ OBJS-$(CONFIG_MPEG2_D3D11VA_HWACCEL) += dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
OBJS-$(CONFIG_MPEG2_NVDEC_HWACCEL)+= nvdec_mpeg12.o
OBJS-$(CONFIG_MPEG2_QSV_HWACCEL) += qsvdec_other.o
+OBJS-$(CONFIG_MPEG2_V4L2REQUEST_HWACCEL) += v4l2_request_mpeg2.o
OBJS-$(CONFIG_MPEG2_VAAPI_HWACCEL)+= vaapi_mpeg2.o
OBJS-$(CONFIG_MPEG2_VDPAU_HWACCEL)+= vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL) += videotoolbox.o
diff --git a/libavcodec/hwaccels.h b/libavcodec/hwaccels.h
index 7d73da8676..ef54de2a3b 100644
--- a/libavcodec/hwaccels.h
+++ b/libavcodec/hwaccels.h
@@ -47,6 +47,7 @@ extern const AVHWAccel ff_mpeg2_d3d11va_hwaccel;
extern const AVHWAccel ff_mpeg2_d3d11va2_hwaccel;
extern const AVHWAccel ff_mpeg2_nvdec_hwaccel;
extern const AVHWAccel ff_mpeg2_dxva2_hwaccel;
+extern const AVHWAccel ff_mpeg2_v4l2request_hwaccel;
extern const AVHWAccel ff_mpeg2_vaapi_hwaccel;
extern const AVHWAccel ff_mpeg2_vdpau_hwaccel;
extern const AVHWAccel ff_mpeg2_videotoolbox_hwaccel;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 83e537884b..305127bc94 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1156,6 +1156,9 @@ static const enum AVPixelFormat
mpeg2_hwaccel_pixfmt_list_420[] = {
#endif
#if CONFIG_MPEG2_VIDEOTOOLBOX_HWACCEL
AV_PIX_FMT_VIDEOTOOLBOX,
+#endif
+#if CONFIG_MPEG2_V4L2REQUEST_HWACCEL
+AV_PIX_FMT_DRM_PRIME,
#endif
AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE
@@ -2941,6 +2944,9 @@ AVCodec ff_mpeg2video_decoder = {
#endif
#if CONFIG_MPEG2_XVMC_HWACCEL
HWACCEL_XVMC(mpeg2),
+#endif
+#if CONFIG_MPEG2_V4L2REQUEST_HWACCEL
+HWACCEL_V4L2REQUEST(mpeg2),
#endif
NULL
},
diff --git a/libavcodec/v4l2_request_mpeg2.c b/libavcodec/v4l2_request_mpeg2.c
new file mode 100644
index 00..782b9c2471
--- /dev/null
+++ b/libavcodec/v4l2_request_mpeg2.c
@@ -0,0 +1,154 @@
+/*
+ * 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 "hwaccel.h"
+#include "mpegvideo.h"
+#include "v4l2_request.h"
+
+typedef struct V4L2RequestControlsMPEG2 {
+struct v4l2_ctrl_mpeg2_slice_params slice_params;
+struct v4l2_ctrl_mpeg2_quantization quantization;
+} V4L2RequestControlsMPEG2;
+
+static int v4l2_request_mpeg2_start_frame(AVCodecContext *avctx,
+ av_unused const uint8_t *buffer,
+ av_unused uint32_t size)
+{
+const MpegEncContext *s = avctx->priv_data;
+V4L2RequestControlsMPEG2 *controls =
s->current_picture_ptr->hwaccel_picture_private;
+V4L2RequestDescriptor *req =
(V4L2RequestDescri
[FFmpeg-devel] [RFC 2/6] Add common V4L2 request API code
Signed-off-by: Jonas Karlman
---
configure | 8 +
libavcodec/Makefile | 1 +
libavcodec/hwaccel.h | 2 +
libavcodec/v4l2_request.c | 885 ++
libavcodec/v4l2_request.h | 65 +++
5 files changed, 961 insertions(+)
create mode 100644 libavcodec/v4l2_request.c
create mode 100644 libavcodec/v4l2_request.h
diff --git a/configure b/configure
index f6123f53e5..ea3945d34a 100755
--- a/configure
+++ b/configure
@@ -271,6 +271,7 @@ External library support:
--enable-libtls enable LibreSSL (via libtls), needed for https
support
if openssl, gnutls or mbedtls is not used [no]
--enable-libtwolame enable MP2 encoding via libtwolame [no]
+ --enable-libudev enable libudev [no]
--enable-libv4l2 enable libv4l2/v4l-utils [no]
--enable-libvidstab enable video stabilization using vid.stab [no]
--enable-libvmaf enable vmaf filter via libvmaf [no]
@@ -335,6 +336,7 @@ External library support:
--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
--enable-rkmpp enable Rockchip Media Process Platform code [no]
--disable-v4l2-m2m disable V4L2 mem2mem code [autodetect]
+ --enable-v4l2-requestenable V4L2 request API code [no]
--disable-vaapi disable Video Acceleration API (mainly Unix/Intel)
code [autodetect]
--disable-vdpau disable Nvidia Video Decode and Presentation API
for Unix code [autodetect]
--disable-videotoolbox disable VideoToolbox code [autodetect]
@@ -1786,6 +1788,7 @@ EXTERNAL_LIBRARY_LIST="
libtesseract
libtheora
libtwolame
+libudev
libv4l2
libvorbis
libvpx
@@ -1838,6 +1841,7 @@ HWACCEL_LIBRARY_LIST="
mmal
omx
opencl
+v4l2_request
"
DOCUMENT_LIST="
@@ -2855,6 +2859,7 @@ d3d11va_deps="dxva_h ID3D11VideoDecoder
ID3D11VideoContext"
dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32"
ffnvcodec_deps_any="libdl LoadLibrary"
nvdec_deps="ffnvcodec"
+v4l2_request_deps="linux_videodev2_h linux_media_h v4l2_timeval_to_ns libdrm
libudev"
vaapi_x11_deps="xlib"
videotoolbox_hwaccel_deps="videotoolbox pthreads"
videotoolbox_hwaccel_extralibs="-framework QuartzCore"
@@ -6201,6 +6206,7 @@ enabled libtls&& require_pkg_config libtls
libtls tls.h tls_configur
enabled libtwolame&& require libtwolame twolame.h twolame_init
-ltwolame &&
{ check_lib libtwolame twolame.h
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and
version must be >= 0.3.10"; }
+enabled libudev && require_pkg_config libudev libudev libudev.h
udev_new
enabled libv4l2 && require_pkg_config libv4l2 libv4l2 libv4l2.h
v4l2_ioctl
enabled libvidstab&& require_pkg_config libvidstab "vidstab >= 0.98"
vid.stab/libvidstab.h vsMotionDetectInit
enabled libvmaf && require_pkg_config libvmaf "libvmaf >= 1.3.9"
libvmaf.h compute_vmaf
@@ -6374,6 +6380,8 @@ check_cc h264_v4l2_m2m linux/videodev2.h "int i =
V4L2_PIX_FMT_H264;"
check_cc vp8_v4l2_m2m linux/videodev2.h "int i = V4L2_PIX_FMT_VP8;"
check_cc vp9_v4l2_m2m linux/videodev2.h "int i = V4L2_PIX_FMT_VP9;"
+check_func_headers "linux/media.h linux/videodev2.h" v4l2_timeval_to_ns
+
check_headers sys/videoio.h
test_code cc sys/videoio.h "struct v4l2_frmsizeenum vfse; vfse.discrete.width
= 0;" && enable_sanitized struct_v4l2_frmivalenum_discrete
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index de873c1643..796727dde7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -147,6 +147,7 @@ OBJS-$(CONFIG_VP3DSP) += vp3dsp.o
OBJS-$(CONFIG_VP56DSP) += vp56dsp.o
OBJS-$(CONFIG_VP8DSP) += vp8dsp.o
OBJS-$(CONFIG_V4L2_M2M)+= v4l2_m2m.o v4l2_context.o
v4l2_buffers.o v4l2_fmt.o
+OBJS-$(CONFIG_V4L2_REQUEST)+= v4l2_request.o
OBJS-$(CONFIG_WMA_FREQS) += wma_freqs.o
OBJS-$(CONFIG_WMV2DSP) += wmv2dsp.o
diff --git a/libavcodec/hwaccel.h b/libavcodec/hwaccel.h
index 3aaa92571c..2eefc91e7e 100644
--- a/libavcodec/hwaccel.h
+++ b/libavcodec/hwaccel.h
@@ -80,5 +80,7 @@ typedef struct AVCodecHWConfigInternal {
HW_CONFIG_HWACCEL(0, 0, 1, D3D11VA_VLD, NONE, ff_ ## codec ##
_d3d11va_hwaccel)
#define HWACCEL_XVMC(codec) \
HW_CONFIG_HWACCEL(0, 0, 1, XVMC, NONE, ff_ ## codec ##
_xvmc_hwaccel)
+#define HWACCEL_V4L2REQUEST(codec) \
+HW_CONFIG_HWACCEL(1, 0, 0, DRM_PRIME,DRM, ff_ ## codec ##
_v4l2request_hwaccel)
#endif /* AVCODEC_HWACCEL_H */
diff --git a/libavcodec/v4l2_request.c b/libavcodec/v4l2_request.c
new file mode 100644
index 00..f66cba3ae8
--- /dev/null
+++ b/libavcodec/v4l2_request.c
@@ -0,0 +1,885 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free softwar
[FFmpeg-devel] [RFC 1/6] avutil: add av_buffer_pool_reclaim()
Signed-off-by: Jonas Karlman
---
libavutil/buffer.c | 13 +
libavutil/buffer.h | 5 +
2 files changed, 18 insertions(+)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 8d1aa5fa84..9c5d530c7a 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -272,6 +272,19 @@ static void buffer_pool_free(AVBufferPool *pool)
av_freep(&pool);
}
+void av_buffer_pool_reclaim(AVBufferPool *pool)
+{
+ff_mutex_lock(&pool->mutex);
+while (pool->pool) {
+BufferPoolEntry *buf = pool->pool;
+pool->pool = buf->next;
+
+buf->free(buf->opaque, buf->data);
+av_freep(&buf);
+}
+ff_mutex_unlock(&pool->mutex);
+}
+
void av_buffer_pool_uninit(AVBufferPool **ppool)
{
AVBufferPool *pool;
diff --git a/libavutil/buffer.h b/libavutil/buffer.h
index 73b6bd0b14..fab745f853 100644
--- a/libavutil/buffer.h
+++ b/libavutil/buffer.h
@@ -266,6 +266,11 @@ AVBufferPool *av_buffer_pool_init2(int size, void *opaque,
AVBufferRef* (*alloc)(void *opaque, int
size),
void (*pool_free)(void *opaque));
+/**
+ * Free all available buffers in a buffer pool.
+ */
+ void av_buffer_pool_reclaim(AVBufferPool *pool);
+
/**
* Mark the pool as being available for freeing. It will actually be freed only
* once all the allocated buffers associated with the pool are released. Thus
it
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC 0/6] Add V4L2 request API hwaccels
Hello, This is a request for comments on a new hwaccel using the V4L2 request API that was created in collaboration with Jernej Skrabec. The V4L2 ctrls needed for statless decoding is not yet stable and reside in private kernel headers. This patchset adds a copy of the kernel private headers needed for the hwaccel to compile. Patch 1 contains a new buffer pool function av_buffer_pool_reclaim() that will free all available buffers in a buffer pool. This can be used to save memory when seeking in e.g. H264 where a new hwaccel instance may get init:ed before the current one is uninit. VAAPI may alloc 20+20 buffers during such overlap. Patch 2 adds common code used in the hwaccels, libudev is used to enumerate media and video devices to locate devices that supports stateless decoding. Patch 3-5 adds hwaccels for MPEG-2, H264 and HEVC. Patch 6 adds private linux headers for V4L2 ctrls. These headers will not be needed once stable ctrls is moved to linux uapi headers. Use --enable-v4l2-request --enable-libdrm --enable-libudev to enable hwaccels. Playback can be tested using mpv patched with [1] or kodi-gbm on Allwinner (H3, H6, A64) devices using the cedrus driver running linux v5.0.x with patches from [2]. This hwaccel has in one form or another been used in Jernej Skrabec's LibreELEC community images for Allwinner at [4] since Dec 20th 2018. Latest work-in-progress version of this patchset can be found at [3]. Any feedback is welcomed, thanks. [1] https://github.com/mpv-player/mpv/pull/6461 [2] https://github.com/LibreELEC/LibreELEC.tv/tree/allwinner/projects/Allwinner/patches/linux [3] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel [4] https://forum.libreelec.tv/thread/13228-early-community-images-for-h3-h6-and-a64/?postID=99416#post99416 Regards, Jonas --- Jernej Skrabec (3): Add V4L2 request API h264 hwaccel Add V4L2 request API hevc hwaccel Add and use private linux headers for V4L2 request API ctrls Jonas Karlman (3): avutil: add av_buffer_pool_reclaim() Add common V4L2 request API code Add V4L2 request API mpeg2 hwaccel configure | 17 + libavcodec/Makefile | 4 + libavcodec/h264-ctrls.h | 192 +++ libavcodec/h264_slice.c | 4 + libavcodec/h264dec.c| 3 + libavcodec/hevc-ctrls.h | 197 +++ libavcodec/hevcdec.c| 10 + libavcodec/hwaccel.h| 2 + libavcodec/hwaccels.h | 3 + libavcodec/mpeg12dec.c | 6 + libavcodec/mpeg2-ctrls.h| 82 +++ libavcodec/v4l2_request.c | 885 libavcodec/v4l2_request.h | 65 +++ libavcodec/v4l2_request_h264.c | 369 + libavcodec/v4l2_request_hevc.c | 392 ++ libavcodec/v4l2_request_mpeg2.c | 155 ++ libavutil/buffer.c | 13 + libavutil/buffer.h | 5 + 18 files changed, 2404 insertions(+) create mode 100644 libavcodec/h264-ctrls.h create mode 100644 libavcodec/hevc-ctrls.h create mode 100644 libavcodec/mpeg2-ctrls.h create mode 100644 libavcodec/v4l2_request.c create mode 100644 libavcodec/v4l2_request.h create mode 100644 libavcodec/v4l2_request_h264.c create mode 100644 libavcodec/v4l2_request_hevc.c create mode 100644 libavcodec/v4l2_request_mpeg2.c -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On 06-04-2019 10:12 PM, Balint Marton wrote: Some of these developers are already in the voting committee, the new ones would be: ... Martin Vignali This developer has left the project. http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6dc1da416e14ede6cf8018183f86aeec5cfae86b Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavutil/hwcontext_opencl.c: fix bug in `opencl_get_plane_format`
On 08/04/2019 03:01, Jarek Samic wrote:
> The `opencl_get_plane_format` function was incorrectly determining the
> value used to set the image channel order. This resulted in all RGB
> pixel formats being set to the `CL_RGBA` pixel format, regardless of
> whether or not they actually *were* RGBA.
>
> This patch fixes the issue by using the `offset` and depth of components
> rather than the loop index to determine the value of `order`.
>
> Signed-off-by: Jarek Samic
> ---
> I have updated this patch in response to the comments on the first version.
> RGB is no longer special-cased, the 2, 3, and 4 mappings to `CL_R` have been
> removed, and the mapping for `CL_ARGB` has been changed to the correct value.
>
> libavutil/hwcontext_opencl.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> index b116c5b708..593de1ca41 100644
> --- a/libavutil/hwcontext_opencl.c
> +++ b/libavutil/hwcontext_opencl.c
> @@ -1419,8 +1419,9 @@ static int opencl_get_plane_format(enum AVPixelFormat
> pixfmt,
> // from the same component.
> if (step && comp->step != step)
> return AVERROR(EINVAL);
> -order = order * 10 + c + 1;
> +
> depth = comp->depth;
> +order = order * 10 + comp->offset / ((depth + 7) / 8) + 1;
> step = comp->step;
> alpha = (desc->flags & AV_PIX_FMT_FLAG_ALPHA &&
> c == desc->nb_components - 1);
This part LGTM, I can split it off and apply it on its own if you like.
> @@ -1456,14 +1457,11 @@ static int opencl_get_plane_format(enum AVPixelFormat
> pixfmt,
> case order: image_format->image_channel_order = type; break;
> switch (order) {
> CHANNEL_ORDER(1,CL_R);
> -CHANNEL_ORDER(2,CL_R);
> -CHANNEL_ORDER(3,CL_R);
> -CHANNEL_ORDER(4,CL_R);
> CHANNEL_ORDER(12, CL_RG);
> CHANNEL_ORDER(23, CL_RG);
23 should be gone too, I think?
> CHANNEL_ORDER(1234, CL_RGBA);
> +CHANNEL_ORDER(2341, CL_ARGB);
> CHANNEL_ORDER(3214, CL_BGRA);
> -CHANNEL_ORDER(4123, CL_ARGB);
I'm not sure I believe this part:
1 = R
2 = G
3 = B
4 = A
gives
RGBA -> 1234
BGRA -> 3214
ARGB -> 4123
ABGR -> 4321
The others match, so why would ARGB be different? 2341 should be GBAR.
(Can you try this with multiple ARGB sources or OpenCL ICDs? Maybe there is a
bug somewhere else...)
> #ifdef CL_ABGR
> CHANNEL_ORDER(4321, CL_ABGR);
> #endif
>
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
Hi, On Sat, Apr 6, 2019 at 12:42 PM Balint Marton wrote: > Hi All > > Here is a call for the people in the voting committee [1] on the decision > of extending it. > > Using the same guidelines as in the second extension [2], the following > candidates were found: > > git log libav/master..master --no-merges --since=2018-03-30T00:00:00Z > --until 2019-03-30T00:00:00Z --pretty=fuller | grep '^Commit:' | sed > 's/<.*//' |sort | uniq -c | sort -nr > > 662 Commit: Michael Niedermayer > 528 Commit: Paul B Mahol > 227 Commit: James Almer > 194 Commit: Carl Eugen Hoyos > 183 Commit: Mark Thompson > 141 Commit: Marton Balint > 99 Commit: Jun Zhao > 84 Commit: Steven Liu > 73 Commit: Martin Vignali > 64 Commit: Gyan Doshi > 55 Commit: Aman Gupta > 42 Commit: Timo Rothenpieler > 35 Commit: Zhong Li > 31 Commit: Karthick Jeyapal > 31 Commit: Karthick J > 23 Commit: Rostislav Pehlivanov > 22 Commit: Peter Ross > 22 Commit: Clément Bœsch > 21 Commit: Lou Logan > 21 Commit: Jan Ekström > > Some of these developers are already in the voting committee, the new ones > would be: > > Aman Gupta > Gyan Doshi > Jan Ekström > Jun Zhao > Karthick Jeyapal > Mark Thompson > Martin Vignali > Peter Ross > Steven Liu > Timo Rothenpieler > Zhong Li > > Question: Do you support extending the voting committte with the people > above Yes. (Didn't we use to do anonymous voting? I personally have no issue with this approach, but I can imagine that someone who wanted to vote against a particular person might prefer to do so privately... This is obviously more important for the actual vote, not the extension of the voting roll...) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On 2019-04-06 09:42, Balint Marton wrote: Hi All Here is a call for the people in the voting committee [1] on the decision of extending it. Using the same guidelines as in the second extension [2], the following candidates were found: git log libav/master..master --no-merges --since=2018-03-30T00:00:00Z --until 2019-03-30T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 's/<.*//' |sort | uniq -c | sort -nr 662 Commit: Michael Niedermayer 528 Commit: Paul B Mahol 227 Commit: James Almer 194 Commit: Carl Eugen Hoyos 183 Commit: Mark Thompson 141 Commit: Marton Balint 99 Commit: Jun Zhao 84 Commit: Steven Liu 73 Commit: Martin Vignali 64 Commit: Gyan Doshi 55 Commit: Aman Gupta 42 Commit: Timo Rothenpieler 35 Commit: Zhong Li 31 Commit: Karthick Jeyapal 31 Commit: Karthick J 23 Commit: Rostislav Pehlivanov 22 Commit: Peter Ross 22 Commit: Clément Bœsch 21 Commit: Lou Logan 21 Commit: Jan Ekström Some of these developers are already in the voting committee, the new ones would be: Aman Gupta Gyan Doshi Jan Ekström Jun Zhao Karthick Jeyapal Mark Thompson Martin Vignali Peter Ross Steven Liu Timo Rothenpieler Zhong Li Question: Do you support extending the voting committte with the people above? Yes. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On 2019-04-08 12:10, Marton Balint wrote: I emailed Marton out-of-band, but I am not in the list because a few of my recent commits were pushed by Timo instead of me pushing them directly. My authored list is 23 commits but 4 were pushed by Timo, so Marton's command line returns '19' for me. You know you are already in the committe because you were included in the second extension, right? :) Hah. No, I did not realise that; in my defence, it was a long time ago. I guess I should also apologise for not voting. :-) I said that if we are excluding people without commit rights, then we need to correctly assign commit ownership when the author and committer both have commit rights to avoid mis-counting. Obviously the metric can be improved, but since this is only a guideline to gather a list for an extension proposal, it is not that big of a deal if it is not perfect. With some scripting I guess it is doable to count authorship then exclude people who have not committed (therefore have no commit rights). Right. It's likely I'm the only person that this affected, and now it turns out I'm not actually affected, but something to do next time round. Thanks, --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On Mon, 8 Apr 2019, Philip Langdale via ffmpeg-devel wrote: On 2019-04-06 10:35, Marton Balint wrote: On Sat, 6 Apr 2019, Jean-Baptiste Kempf wrote: Hello, On Sat, 6 Apr 2019, at 18:42, Balint Marton wrote: Here is a call for the people in the voting committee [1] on the decision of extending it. Why do you limit at those ones? There are more commiters, even in the last year. I don't see Philip or Vittorio, for example. Same guidelines were used to select the people as in the second extension: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html I emailed Marton out-of-band, but I am not in the list because a few of my recent commits were pushed by Timo instead of me pushing them directly. My authored list is 23 commits but 4 were pushed by Timo, so Marton's command line returns '19' for me. You know you are already in the committe because you were included in the second extension, right? :) I said that if we are excluding people without commit rights, then we need to correctly assign commit ownership when the author and committer both have commit rights to avoid mis-counting. Obviously the metric can be improved, but since this is only a guideline to gather a list for an extension proposal, it is not that big of a deal if it is not perfect. With some scripting I guess it is doable to count authorship then exclude people who have not committed (therefore have no commit rights). Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/agm: add support for higher compression
On 4/8/19, James Almer wrote:
> On 4/8/2019 12:42 PM, Paul B Mahol wrote:
+static int decode_huffman2(AVCodecContext *avctx, int header, int size)
+{
+AGMContext *s = avctx->priv_data;
+GetBitContext *gb = &s->gb;
+uint8_t lens[256];
+uint32_t output_size;
+int ret, x, len;
+
+if ((ret = init_get_bits8(gb, s->gbyte.buffer,
+ bytestream2_get_bytes_left(&s->gbyte))) <
0)
+return ret;
+
+output_size = get_bits_long(gb, 32);
+
+av_fast_padded_malloc(&s->output, &s->output_size,
+ output_size * sizeof(*s->output));
>>> Several chances for overflow here.
>> Yes, changed output_size to int.
>
> No, it needs to be unsigned for av_fast_padded_malloc(). What you need
> to also make unsigned is s->output_size instead.
>
> Also, that sizeof(*s->output) seems superfluous.
Done locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/opengl_enc: fix build error using msvc compiler
2019-04-08 17:07 GMT+02:00, BIGLER Don (Framatome) : > diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c > index 54c7e610bd..4263f0e4ef 100644 > --- a/libavdevice/opengl_enc.c > +++ b/libavdevice/opengl_enc.c > @@ -25,7 +25,7 @@ > #include > #include > #include > -#include > +#include Why is stdint needed? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/utils: Use av_packet_move_ref for packet ownership transfer
From: Andriy Gelman
This commit replaces packet assignment operator with av_packet_move_ref
when there is a packet ownership transfer.
---
Michael, the update patch now has correct behavior for ticket 4221.
libavformat/utils.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9b3f0d28e6..9653ebb4f4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -460,10 +460,7 @@ int ff_packet_list_put(AVPacketList **packet_buffer,
return ret;
}
} else {
-// TODO: Adapt callers in this file so the line below can use
-// av_packet_move_ref() to effectively move the reference
-// to the list.
-pktl->pkt = *pkt;
+av_packet_move_ref(&pktl->pkt, pkt);
}
if (*packet_buffer)
@@ -832,19 +829,21 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
{
int ret, i, err;
AVStream *st;
+AVPacket *buffer_pkt; /*view packet contents only. does not take
ownership*/
for (;;) {
AVPacketList *pktl = s->internal->raw_packet_buffer;
if (pktl) {
-*pkt = pktl->pkt;
-st = s->streams[pkt->stream_index];
+buffer_pkt = &pktl->pkt;
+st = s->streams[buffer_pkt->stream_index];
if (s->internal->raw_packet_buffer_remaining_size <= 0)
if ((err = probe_codec(s, st, NULL)) < 0)
return err;
if (st->request_probe <= 0) {
s->internal->raw_packet_buffer = pktl->next;
-s->internal->raw_packet_buffer_remaining_size += pkt->size;
+s->internal->raw_packet_buffer_remaining_size +=
buffer_pkt->size;
+av_packet_move_ref(pkt, &pktl->pkt);
av_free(pktl);
return 0;
}
@@ -914,14 +913,17 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
if (!pktl && st->request_probe <= 0)
return ret;
+/*transfer pkt ownership to list*/
err = ff_packet_list_put(&s->internal->raw_packet_buffer,
&s->internal->raw_packet_buffer_end,
pkt, 0);
if (err)
return err;
-s->internal->raw_packet_buffer_remaining_size -= pkt->size;
-if ((err = probe_codec(s, st, pkt)) < 0)
+buffer_pkt = &s->internal->raw_packet_buffer_end->pkt;
+s->internal->raw_packet_buffer_remaining_size -= buffer_pkt->size;
+
+if ((err = probe_codec(s, st, buffer_pkt)) < 0)
return err;
}
}
@@ -1662,7 +1664,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (!st->need_parsing || !st->parser) {
/* no parsing needed: we just output the packet as is */
-*pkt = cur_pkt;
+av_packet_move_ref(pkt, &cur_pkt);
compute_pkt_fields(s, st, NULL, pkt, AV_NOPTS_VALUE,
AV_NOPTS_VALUE);
if ((s->iformat->flags & AVFMT_GENERIC_INDEX) &&
(pkt->flags & AV_PKT_FLAG_KEY) && pkt->dts != AV_NOPTS_VALUE) {
@@ -3779,15 +3781,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
break;
}
-pkt = &pkt1;
-
if (!(ic->flags & AVFMT_FLAG_NOBUFFER)) {
ret = ff_packet_list_put(&ic->internal->packet_buffer,
&ic->internal->packet_buffer_end,
- pkt, 0);
+ &pkt1, 0);
if (ret < 0)
goto find_stream_info_err;
-}
+pkt = &ic->internal->packet_buffer_end->pkt;
+} else
+pkt = &pkt1;
st = ic->streams[pkt->stream_index];
if (!(st->disposition & AV_DISPOSITION_ATTACHED_PIC))
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
2019-04-08 19:51 GMT+02:00, Philip Langdale via ffmpeg-devel : > On 2019-04-06 10:35, Marton Balint wrote: >> On Sat, 6 Apr 2019, Jean-Baptiste Kempf wrote: >> >>> Hello, >>> >>> On Sat, 6 Apr 2019, at 18:42, Balint Marton wrote: Here is a call for the people in the voting committee [1] on the decision of extending it. >>> >>> Why do you limit at those ones? There are more commiters, even in the >>> last year. >>> I don't see Philip or Vittorio, for example. >> >> Same guidelines were used to select the people as in the second >> extension: >> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html > > I emailed Marton out-of-band, but I am not in the list because a few of > my recent commits > were pushed by Timo instead of me pushing them directly. My authored > list is 23 commits > but 4 were pushed by Timo, so Marton's command line returns '19' for me. > > I said that if we are excluding people without commit rights (Sorry if I misunderstand) It is of course absurd to count pushes, commits have to be counted. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
On 2019-04-06 10:35, Marton Balint wrote: On Sat, 6 Apr 2019, Jean-Baptiste Kempf wrote: Hello, On Sat, 6 Apr 2019, at 18:42, Balint Marton wrote: Here is a call for the people in the voting committee [1] on the decision of extending it. Why do you limit at those ones? There are more commiters, even in the last year. I don't see Philip or Vittorio, for example. Same guidelines were used to select the people as in the second extension: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html I emailed Marton out-of-band, but I am not in the list because a few of my recent commits were pushed by Timo instead of me pushing them directly. My authored list is 23 commits but 4 were pushed by Timo, so Marton's command line returns '19' for me. I said that if we are excluding people without commit rights, then we need to correctly assign commit ownership when the author and committer both have commit rights to avoid mis-counting. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/agm: add support for higher compression
On 4/8/2019 12:42 PM, Paul B Mahol wrote:
>>> +static int decode_huffman2(AVCodecContext *avctx, int header, int size)
>>> +{
>>> +AGMContext *s = avctx->priv_data;
>>> +GetBitContext *gb = &s->gb;
>>> +uint8_t lens[256];
>>> +uint32_t output_size;
>>> +int ret, x, len;
>>> +
>>> +if ((ret = init_get_bits8(gb, s->gbyte.buffer,
>>> + bytestream2_get_bytes_left(&s->gbyte))) <
>>> 0)
>>> +return ret;
>>> +
>>> +output_size = get_bits_long(gb, 32);
>>> +
>>> +av_fast_padded_malloc(&s->output, &s->output_size,
>>> + output_size * sizeof(*s->output));
>> Several chances for overflow here.
> Yes, changed output_size to int.
No, it needs to be unsigned for av_fast_padded_malloc(). What you need
to also make unsigned is s->output_size instead.
Also, that sizeof(*s->output) seems superfluous.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/agm: add support for higher compression
Paul B Mahol (12019-04-08): > Yes, changed output_size to int. Sounds worse. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/udp: add options send_pkt_size for udp over ip, for ts over ip, this value must be 1316(7*188)
On Mon, 8 Apr 2019, edward_email wrote: From: “Edward.Wu” <“edward_em...@126.com”> Signed-off-by: “Edward.Wu” <“edward_em...@126.com”> --- libavformat/udp.c | 45 - 1 file changed, 44 insertions(+), 1 deletion(-) Why is this patch needed at all? If you want fixed packet size, you simply use -pkt_size 1316 -flush_packets 0. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/udp: add options send_pkt_size for udp over ip, for ts over ip, this value must be 1316(7*188)
Hi,
On 08.04.19 17:42, edward_email wrote:
From: “Edward.Wu” <“edward_em...@126.com”>
Signed-off-by: “Edward.Wu” <“edward_em...@126.com”>
---
libavformat/udp.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index cf73d331e0..7563b671fe 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -73,6 +73,7 @@
#define UDP_TX_BUF_SIZE 32768
#define UDP_MAX_PKT_SIZE 65536
#define UDP_HEADER_SIZE 8
+#define UDP_PACKET_MAX 1472
Could you explain how you calculate this value and why it generally
valid in this case?
typedef struct UDPContext {
const AVClass *class;
@@ -81,6 +82,9 @@ typedef struct UDPContext {
int udplite_coverage;
int buffer_size;
int pkt_size;
+int send_pkt_size;
+uint8_t send_pkt_buf[UDP_PACKET_MAX];
+int cur_send_pkt_len;
int is_multicast;
int is_broadcast;
int local_port;
@@ -125,6 +129,7 @@ static const AVOption options[] = {
{ "localaddr", "Local address",
OFFSET(localaddr), AV_OPT_TYPE_STRING, { .str = NULL }, .flags = D|E },
{ "udplite_coverage", "choose UDPLite head size which should be validated by
checksum", OFFSET(udplite_coverage), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, D|E },
{ "pkt_size", "Maximum UDP packet size",
OFFSET(pkt_size), AV_OPT_TYPE_INT,{ .i64 = 1472 }, -1, INT_MAX, .flags = D|E },
+{ "send_pkt_size", "Send UDP packet size, ts over ip must be 1316",
OFFSET(send_pkt_size), AV_OPT_TYPE_INT,{ .i64 = 0 }, -1, 1472, .flags = D|E },
I assume ts means "MPEG-TS": why does it need to be 7 times an MPEG-TS
packet? Why not 6 times or less? What about jumbo packets which exceeds
the size of an 1500 MTU and are definitely possible under defined
circumstances?
Best regards,
Thomas.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/udp: add options send_pkt_size for udp over ip, for ts over ip, this value must be 1316(7*188)
> 在 2019年4月8日，23:42，edward_email 写道：
>
> From: “Edward.Wu” <“edward_em...@126.com”>
>
> Signed-off-by: “Edward.Wu” <“edward_em...@126.com”>
> —
Document please.
> libavformat/udp.c | 45 -
> 1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index cf73d331e0..7563b671fe 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -73,6 +73,7 @@
> #define UDP_TX_BUF_SIZE 32768
> #define UDP_MAX_PKT_SIZE 65536
> #define UDP_HEADER_SIZE 8
> +#define UDP_PACKET_MAX 1472
>
> typedef struct UDPContext {
> const AVClass *class;
> @@ -81,6 +82,9 @@ typedef struct UDPContext {
> int udplite_coverage;
> int buffer_size;
> int pkt_size;
> +int send_pkt_size;
> +uint8_t send_pkt_buf[UDP_PACKET_MAX];
> +int cur_send_pkt_len;
> int is_multicast;
> int is_broadcast;
> int local_port;
> @@ -125,6 +129,7 @@ static const AVOption options[] = {
> { "localaddr", "Local address",
> OFFSET(localaddr), AV_OPT_TYPE_STRING, { .str = NULL },
> .flags = D|E },
> { "udplite_coverage", "choose UDPLite head size which should be validated
> by checksum", OFFSET(udplite_coverage), AV_OPT_TYPE_INT, {.i64 = 0}, 0,
> INT_MAX, D|E },
> { "pkt_size", "Maximum UDP packet size",
> OFFSET(pkt_size), AV_OPT_TYPE_INT,{ .i64 = 1472 }, -1, INT_MAX,
> .flags = D|E },
> +{ "send_pkt_size", "Send UDP packet size, ts over ip must be 1316",
> OFFSET(send_pkt_size), AV_OPT_TYPE_INT,{ .i64 = 0 }, -1, 1472, .flags =
> D|E },
> { "reuse", "explicitly allow reusing UDP sockets",
> OFFSET(reuse_socket), AV_OPT_TYPE_BOOL, { .i64 = -1 },-1, 1,
> D|E },
> { "reuse_socket", "explicitly allow reusing UDP sockets",
> OFFSET(reuse_socket), AV_OPT_TYPE_BOOL, { .i64 = -1 },-1, 1,
> .flags = D|E },
> { "broadcast", "explicitly allow or disallow broadcast destination",
> OFFSET(is_broadcast), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E
> },
> @@ -390,6 +395,7 @@ static int udp_port(struct sockaddr_storage *addr, int
> addr_len)
> * option: 'ttl=n' : set the ttl value (for multicast only)
> * 'localport=n' : set the local port
> * 'pkt_size=n' : set max packet size
> + * 'send_pkt_size=n' : set send packet size
> * 'reuse=1' : enable reusing the socket
> * 'overrun_nonfatal=1': survive in case of circular buffer overrun
> *
> @@ -683,6 +689,13 @@ static int udp_open(URLContext *h, const char *uri, int
> flags)
> if (av_find_info_tag(buf, sizeof(buf), "pkt_size", p)) {
> s->pkt_size = strtol(buf, NULL, 10);
> }
> +if (av_find_info_tag(buf, sizeof(buf), "send_pkt_size", p)) {
> +s->send_pkt_size = strtol(buf, NULL, 10);
> +if (s->send_pkt_size > UDP_PACKET_MAX) {//UDP max
> +av_log(h, AV_LOG_WARNING, "send_pkt_size is %s, bigger than
> %d, set as %d.\n", buf, UDP_PACKET_MAX, UDP_PACKET_MAX);
> +s->send_pkt_size = UDP_PACKET_MAX;
> +}
> +}
> if (av_find_info_tag(buf, sizeof(buf), "buffer_size", p)) {
> s->buffer_size = strtol(buf, NULL, 10);
> }
> @@ -1001,7 +1014,8 @@ static int udp_read(URLContext *h, uint8_t *buf, int
> size)
> return ret;
> }
>
> -static int udp_write(URLContext *h, const uint8_t *buf, int size)
> +
> +static int udp_write_internal(URLContext *h, const uint8_t *buf, int size)
> {
> UDPContext *s = h->priv_data;
> int ret;
> @@ -1050,6 +1064,35 @@ static int udp_write(URLContext *h, const uint8_t
> *buf, int size)
>
> return ret < 0 ? ff_neterrno() : ret;
> }
> +static int udp_write(URLContext *h, const uint8_t *buf, int size)
> +{
> +UDPContext *s = h->priv_data;
> +int copied = 0;
> +int capacity = 0;
> +uint8_t * p = NULL;
uint8_t *p = NULL;
> +uint8_t * p_end = NULL;
uint8_t *p_end = NULL;
> +int re = 0;
What about change re to ret?
> +
> +if (s->send_pkt_size == 0) {
> +return udp_write_internal(h, buf, size);
> +} else {
> +p = (uint8_t*)buf;
> +p_end = p + size;
> +while (p < p_end) {
> +if ( s->cur_send_pkt_len >= s->send_pkt_size ){
> +re += udp_write_internal(h, s->send_pkt_buf,
> s->cur_send_pkt_len);
Maybe you want check the return value of the udp_write_internal?
What do you want to use when the re + the value of udp_write_internal result?
> +s->cur_send_pkt_len = 0;
> +}
> +
> +capacity = s->send_pkt_size - s->cur_send_pkt_len;
> +copied = capacity > (p_end - p) ? (p_end - p) : capacity;
> +memcpy(s->send_pkt_buf + s->cur_send_pkt_len, p, copied);
> +p += copied;
> +s->cur_send_pkt_
Re: [FFmpeg-devel] [PATCH] avcodec/agm: add support for higher compression
On 4/8/19, Nicolas George wrote:
> Paul B Mahol (12019-04-08):
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/agm.c | 403 +++--
>> libavformat/riff.c | 4 +
>> 2 files changed, 392 insertions(+), 15 deletions(-)
>>
>> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
>> index cbd45e8095..e183b7f508 100644
>> --- a/libavcodec/agm.c
>> +++ b/libavcodec/agm.c
>> @@ -71,9 +71,14 @@ typedef struct AGMContext {
>> unsigned flags;
>> unsigned fflags;
>>
>> +uint8_t *output;
>> +int output_size;
>> +
>> MotionVector *mvectors;
>> int mvectors_size;
>>
>> +VLC vlc;
>> +
>> AVFrame *prev_frame;
>>
>> int luma_quant_matrix[64];
>> @@ -81,6 +86,13 @@ typedef struct AGMContext {
>>
>> ScanTable scantable;
>> DECLARE_ALIGNED(32, int16_t, block)[64];
>> +
>> +int16_t *wblocks;
>> +int wblocks_size;
>> +
>> +int *map;
>> +int map_size;
>> +
>> IDCTDSPContext idsp;
>> } AGMContext;
>>
>> @@ -173,7 +185,84 @@ static int read_code(GetBitContext *gb, int *oskip,
>> int *level, int *map, int mo
>> return 0;
>> }
>>
>> -static int decode_intra_block(AGMContext *s, GetBitContext *gb, int
>> size,
>> +static int decode_intra_blocks(AGMContext *s, GetBitContext *gb,
>> + const int *quant_matrix, int *skip, int
>> *dc_level)
>> +{
>> +const uint8_t *scantable = s->scantable.permutated;
>> +int level, ret, map = 0;
>> +
>> +memset(s->wblocks, 0, s->wblocks_size);
>> +
>> +for (int i = 0; i < 64; i++) {
>> +int16_t *block = s->wblocks + scantable[i];
>> +
>> +for (int j = 0; j < s->blocks_w;) {
>> +if (*skip > 0) {
>> +int rskip;
>> +
>> +rskip = FFMIN(*skip, s->blocks_w - j);
>> +j += rskip;
>> +if (i == 0) {
>> +for (int k = 0; k < rskip; k++)
>> +block[64 * k] = *dc_level * quant_matrix[0];
>> +}
>> +block += rskip * 64;
>> +*skip -= rskip;
>> +} else {
>> +ret = read_code(gb, skip, &level, &map, s->flags & 1);
>> +if (ret < 0)
>> +return ret;
>> +
>> +if (i == 0)
>> +*dc_level += level;
>> +
>> +block[0] = (i == 0 ? *dc_level : level) *
>> quant_matrix[i];
>> +block += 64;
>> +j++;
>> +}
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int decode_inter_blocks(AGMContext *s, GetBitContext *gb,
>> + const int *quant_matrix, int *skip,
>> + int *map)
>> +{
>> +const uint8_t *scantable = s->scantable.permutated;
>> +int level, ret;
>> +
>> +memset(s->wblocks, 0, s->wblocks_size);
>> +memset(s->map, 0, s->map_size);
>> +
>> +for (int i = 0; i < 64; i++) {
>> +int16_t *block = s->wblocks + scantable[i];
>> +
>> +for (int j = 0; j < s->blocks_w;) {
>> +if (*skip > 0) {
>> +int rskip;
>> +
>> +rskip = FFMIN(*skip, s->blocks_w - j);
>> +j += rskip;
>> +block += rskip * 64;
>> +*skip -= rskip;
>> +} else {
>> +ret = read_code(gb, skip, &level, &map[j], s->flags &
>> 1);
>> +if (ret < 0)
>> +return ret;
>> +
>> +block[0] = level * quant_matrix[i];
>> +block += 64;
>> +j++;
>> +}
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int decode_intra_block(AGMContext *s, GetBitContext *gb,
>>const int *quant_matrix, int *skip, int
>> *dc_level)
>> {
>> const uint8_t *scantable = s->scantable.permutated;
>> @@ -218,18 +307,38 @@ static int decode_intra_plane(AGMContext *s,
>> GetBitContext *gb, int size,
>>int plane)
>> {
>> int ret, skip = 0, dc_level = 0;
>> +const int offset = s->plus ? 0 : 1024;
>>
>> if ((ret = init_get_bits8(gb, s->gbyte.buffer, size)) < 0)
>> return ret;
>>
>> -for (int y = 0; y < s->blocks_h; y++) {
>> -for (int x = 0; x < s->blocks_w; x++) {
>> -ret = decode_intra_block(s, gb, size, quant_matrix, &skip,
>> &dc_level);
>> +if (s->flags & 1) {
>> +av_fast_padded_malloc(&s->wblocks, &s->wblocks_size,
>> + 64 * s->blocks_w * sizeof(*s->wblocks));
>> +if (!s->wblocks)
>> +return AVERROR(ENOMEM);
>> +
>> +for (int y = 0; y < s->blocks_h; y++) {
>> +ret = decode_intra_blocks(s, gb, quant_matrix, &skip,
>> &dc_level);
>> if (ret < 0)
>> return ret;
>>
>> -s->idsp.idct_put(frame->data[plane] + (s->blocks_h - 1 - y)
[FFmpeg-devel] [PATCH] libavformat/udp: add options send_pkt_size for udp over ip, for ts over ip, this value must be 1316(7*188)
From: “Edward.Wu” <“edward_em...@126.com”>
Signed-off-by: “Edward.Wu” <“edward_em...@126.com”>
---
libavformat/udp.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index cf73d331e0..7563b671fe 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -73,6 +73,7 @@
#define UDP_TX_BUF_SIZE 32768
#define UDP_MAX_PKT_SIZE 65536
#define UDP_HEADER_SIZE 8
+#define UDP_PACKET_MAX 1472
typedef struct UDPContext {
const AVClass *class;
@@ -81,6 +82,9 @@ typedef struct UDPContext {
int udplite_coverage;
int buffer_size;
int pkt_size;
+int send_pkt_size;
+uint8_t send_pkt_buf[UDP_PACKET_MAX];
+int cur_send_pkt_len;
int is_multicast;
int is_broadcast;
int local_port;
@@ -125,6 +129,7 @@ static const AVOption options[] = {
{ "localaddr", "Local address",
OFFSET(localaddr), AV_OPT_TYPE_STRING, { .str = NULL },
.flags = D|E },
{ "udplite_coverage", "choose UDPLite head size which should be validated
by checksum", OFFSET(udplite_coverage), AV_OPT_TYPE_INT, {.i64 = 0}, 0,
INT_MAX, D|E },
{ "pkt_size", "Maximum UDP packet size",
OFFSET(pkt_size), AV_OPT_TYPE_INT,{ .i64 = 1472 }, -1, INT_MAX,
.flags = D|E },
+{ "send_pkt_size", "Send UDP packet size, ts over ip must be 1316",
OFFSET(send_pkt_size), AV_OPT_TYPE_INT,{ .i64 = 0 }, -1, 1472, .flags =
D|E },
{ "reuse", "explicitly allow reusing UDP sockets",
OFFSET(reuse_socket), AV_OPT_TYPE_BOOL, { .i64 = -1 },-1, 1, D|E
},
{ "reuse_socket", "explicitly allow reusing UDP sockets",
OFFSET(reuse_socket), AV_OPT_TYPE_BOOL, { .i64 = -1 },-1, 1,
.flags = D|E },
{ "broadcast", "explicitly allow or disallow broadcast destination",
OFFSET(is_broadcast), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
@@ -390,6 +395,7 @@ static int udp_port(struct sockaddr_storage *addr, int
addr_len)
* option: 'ttl=n' : set the ttl value (for multicast only)
* 'localport=n' : set the local port
* 'pkt_size=n' : set max packet size
+ * 'send_pkt_size=n' : set send packet size
* 'reuse=1' : enable reusing the socket
* 'overrun_nonfatal=1': survive in case of circular buffer overrun
*
@@ -683,6 +689,13 @@ static int udp_open(URLContext *h, const char *uri, int
flags)
if (av_find_info_tag(buf, sizeof(buf), "pkt_size", p)) {
s->pkt_size = strtol(buf, NULL, 10);
}
+if (av_find_info_tag(buf, sizeof(buf), "send_pkt_size", p)) {
+s->send_pkt_size = strtol(buf, NULL, 10);
+if (s->send_pkt_size > UDP_PACKET_MAX) {//UDP max
+av_log(h, AV_LOG_WARNING, "send_pkt_size is %s, bigger than
%d, set as %d.\n", buf, UDP_PACKET_MAX, UDP_PACKET_MAX);
+s->send_pkt_size = UDP_PACKET_MAX;
+}
+}
if (av_find_info_tag(buf, sizeof(buf), "buffer_size", p)) {
s->buffer_size = strtol(buf, NULL, 10);
}
@@ -1001,7 +1014,8 @@ static int udp_read(URLContext *h, uint8_t *buf, int size)
return ret;
}
-static int udp_write(URLContext *h, const uint8_t *buf, int size)
+
+static int udp_write_internal(URLContext *h, const uint8_t *buf, int size)
{
UDPContext *s = h->priv_data;
int ret;
@@ -1050,6 +1064,35 @@ static int udp_write(URLContext *h, const uint8_t *buf,
int size)
return ret < 0 ? ff_neterrno() : ret;
}
+static int udp_write(URLContext *h, const uint8_t *buf, int size)
+{
+UDPContext *s = h->priv_data;
+int copied = 0;
+int capacity = 0;
+uint8_t * p = NULL;
+uint8_t * p_end = NULL;
+int re = 0;
+
+if (s->send_pkt_size == 0) {
+return udp_write_internal(h, buf, size);
+} else {
+p = (uint8_t*)buf;
+p_end = p + size;
+while (p < p_end) {
+if ( s->cur_send_pkt_len >= s->send_pkt_size ){
+re += udp_write_internal(h, s->send_pkt_buf,
s->cur_send_pkt_len);
+s->cur_send_pkt_len = 0;
+}
+
+capacity = s->send_pkt_size - s->cur_send_pkt_len;
+copied = capacity > (p_end - p) ? (p_end - p) : capacity;
+memcpy(s->send_pkt_buf + s->cur_send_pkt_len, p, copied);
+p += copied;
+s->cur_send_pkt_len += copied;
+}
+}
+return size;
+}
static int udp_close(URLContext *h)
{
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/agm: add support for higher compression
Paul B Mahol (12019-04-08):
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/agm.c | 403 +++--
> libavformat/riff.c | 4 +
> 2 files changed, 392 insertions(+), 15 deletions(-)
>
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index cbd45e8095..e183b7f508 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.c
> @@ -71,9 +71,14 @@ typedef struct AGMContext {
> unsigned flags;
> unsigned fflags;
>
> +uint8_t *output;
> +int output_size;
> +
> MotionVector *mvectors;
> int mvectors_size;
>
> +VLC vlc;
> +
> AVFrame *prev_frame;
>
> int luma_quant_matrix[64];
> @@ -81,6 +86,13 @@ typedef struct AGMContext {
>
> ScanTable scantable;
> DECLARE_ALIGNED(32, int16_t, block)[64];
> +
> +int16_t *wblocks;
> +int wblocks_size;
> +
> +int *map;
> +int map_size;
> +
> IDCTDSPContext idsp;
> } AGMContext;
>
> @@ -173,7 +185,84 @@ static int read_code(GetBitContext *gb, int *oskip, int
> *level, int *map, int mo
> return 0;
> }
>
> -static int decode_intra_block(AGMContext *s, GetBitContext *gb, int size,
> +static int decode_intra_blocks(AGMContext *s, GetBitContext *gb,
> + const int *quant_matrix, int *skip, int
> *dc_level)
> +{
> +const uint8_t *scantable = s->scantable.permutated;
> +int level, ret, map = 0;
> +
> +memset(s->wblocks, 0, s->wblocks_size);
> +
> +for (int i = 0; i < 64; i++) {
> +int16_t *block = s->wblocks + scantable[i];
> +
> +for (int j = 0; j < s->blocks_w;) {
> +if (*skip > 0) {
> +int rskip;
> +
> +rskip = FFMIN(*skip, s->blocks_w - j);
> +j += rskip;
> +if (i == 0) {
> +for (int k = 0; k < rskip; k++)
> +block[64 * k] = *dc_level * quant_matrix[0];
> +}
> +block += rskip * 64;
> +*skip -= rskip;
> +} else {
> +ret = read_code(gb, skip, &level, &map, s->flags & 1);
> +if (ret < 0)
> +return ret;
> +
> +if (i == 0)
> +*dc_level += level;
> +
> +block[0] = (i == 0 ? *dc_level : level) * quant_matrix[i];
> +block += 64;
> +j++;
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
> +static int decode_inter_blocks(AGMContext *s, GetBitContext *gb,
> + const int *quant_matrix, int *skip,
> + int *map)
> +{
> +const uint8_t *scantable = s->scantable.permutated;
> +int level, ret;
> +
> +memset(s->wblocks, 0, s->wblocks_size);
> +memset(s->map, 0, s->map_size);
> +
> +for (int i = 0; i < 64; i++) {
> +int16_t *block = s->wblocks + scantable[i];
> +
> +for (int j = 0; j < s->blocks_w;) {
> +if (*skip > 0) {
> +int rskip;
> +
> +rskip = FFMIN(*skip, s->blocks_w - j);
> +j += rskip;
> +block += rskip * 64;
> +*skip -= rskip;
> +} else {
> +ret = read_code(gb, skip, &level, &map[j], s->flags & 1);
> +if (ret < 0)
> +return ret;
> +
> +block[0] = level * quant_matrix[i];
> +block += 64;
> +j++;
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
> +static int decode_intra_block(AGMContext *s, GetBitContext *gb,
>const int *quant_matrix, int *skip, int
> *dc_level)
> {
> const uint8_t *scantable = s->scantable.permutated;
> @@ -218,18 +307,38 @@ static int decode_intra_plane(AGMContext *s,
> GetBitContext *gb, int size,
>int plane)
> {
> int ret, skip = 0, dc_level = 0;
> +const int offset = s->plus ? 0 : 1024;
>
> if ((ret = init_get_bits8(gb, s->gbyte.buffer, size)) < 0)
> return ret;
>
> -for (int y = 0; y < s->blocks_h; y++) {
> -for (int x = 0; x < s->blocks_w; x++) {
> -ret = decode_intra_block(s, gb, size, quant_matrix, &skip,
> &dc_level);
> +if (s->flags & 1) {
> +av_fast_padded_malloc(&s->wblocks, &s->wblocks_size,
> + 64 * s->blocks_w * sizeof(*s->wblocks));
> +if (!s->wblocks)
> +return AVERROR(ENOMEM);
> +
> +for (int y = 0; y < s->blocks_h; y++) {
> +ret = decode_intra_blocks(s, gb, quant_matrix, &skip, &dc_level);
> if (ret < 0)
> return ret;
>
> -s->idsp.idct_put(frame->data[plane] + (s->blocks_h - 1 - y) * 8
> * frame->linesize[plane] + x * 8,
> - frame->linesize[plane], s->block);
> +for (int x = 0; x < s->blocks_w; x++) {
> +
[FFmpeg-devel] [PATCH] avcodec/agm: add support for higher compression
Signed-off-by: Paul B Mahol
---
libavcodec/agm.c | 403 +++--
libavformat/riff.c | 4 +
2 files changed, 392 insertions(+), 15 deletions(-)
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index cbd45e8095..e183b7f508 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -71,9 +71,14 @@ typedef struct AGMContext {
unsigned flags;
unsigned fflags;
+uint8_t *output;
+int output_size;
+
MotionVector *mvectors;
int mvectors_size;
+VLC vlc;
+
AVFrame *prev_frame;
int luma_quant_matrix[64];
@@ -81,6 +86,13 @@ typedef struct AGMContext {
ScanTable scantable;
DECLARE_ALIGNED(32, int16_t, block)[64];
+
+int16_t *wblocks;
+int wblocks_size;
+
+int *map;
+int map_size;
+
IDCTDSPContext idsp;
} AGMContext;
@@ -173,7 +185,84 @@ static int read_code(GetBitContext *gb, int *oskip, int
*level, int *map, int mo
return 0;
}
-static int decode_intra_block(AGMContext *s, GetBitContext *gb, int size,
+static int decode_intra_blocks(AGMContext *s, GetBitContext *gb,
+ const int *quant_matrix, int *skip, int
*dc_level)
+{
+const uint8_t *scantable = s->scantable.permutated;
+int level, ret, map = 0;
+
+memset(s->wblocks, 0, s->wblocks_size);
+
+for (int i = 0; i < 64; i++) {
+int16_t *block = s->wblocks + scantable[i];
+
+for (int j = 0; j < s->blocks_w;) {
+if (*skip > 0) {
+int rskip;
+
+rskip = FFMIN(*skip, s->blocks_w - j);
+j += rskip;
+if (i == 0) {
+for (int k = 0; k < rskip; k++)
+block[64 * k] = *dc_level * quant_matrix[0];
+}
+block += rskip * 64;
+*skip -= rskip;
+} else {
+ret = read_code(gb, skip, &level, &map, s->flags & 1);
+if (ret < 0)
+return ret;
+
+if (i == 0)
+*dc_level += level;
+
+block[0] = (i == 0 ? *dc_level : level) * quant_matrix[i];
+block += 64;
+j++;
+}
+}
+}
+
+return 0;
+}
+
+static int decode_inter_blocks(AGMContext *s, GetBitContext *gb,
+ const int *quant_matrix, int *skip,
+ int *map)
+{
+const uint8_t *scantable = s->scantable.permutated;
+int level, ret;
+
+memset(s->wblocks, 0, s->wblocks_size);
+memset(s->map, 0, s->map_size);
+
+for (int i = 0; i < 64; i++) {
+int16_t *block = s->wblocks + scantable[i];
+
+for (int j = 0; j < s->blocks_w;) {
+if (*skip > 0) {
+int rskip;
+
+rskip = FFMIN(*skip, s->blocks_w - j);
+j += rskip;
+block += rskip * 64;
+*skip -= rskip;
+} else {
+ret = read_code(gb, skip, &level, &map[j], s->flags & 1);
+if (ret < 0)
+return ret;
+
+block[0] = level * quant_matrix[i];
+block += 64;
+j++;
+}
+}
+}
+
+return 0;
+}
+
+static int decode_intra_block(AGMContext *s, GetBitContext *gb,
const int *quant_matrix, int *skip, int
*dc_level)
{
const uint8_t *scantable = s->scantable.permutated;
@@ -218,18 +307,38 @@ static int decode_intra_plane(AGMContext *s,
GetBitContext *gb, int size,
int plane)
{
int ret, skip = 0, dc_level = 0;
+const int offset = s->plus ? 0 : 1024;
if ((ret = init_get_bits8(gb, s->gbyte.buffer, size)) < 0)
return ret;
-for (int y = 0; y < s->blocks_h; y++) {
-for (int x = 0; x < s->blocks_w; x++) {
-ret = decode_intra_block(s, gb, size, quant_matrix, &skip,
&dc_level);
+if (s->flags & 1) {
+av_fast_padded_malloc(&s->wblocks, &s->wblocks_size,
+ 64 * s->blocks_w * sizeof(*s->wblocks));
+if (!s->wblocks)
+return AVERROR(ENOMEM);
+
+for (int y = 0; y < s->blocks_h; y++) {
+ret = decode_intra_blocks(s, gb, quant_matrix, &skip, &dc_level);
if (ret < 0)
return ret;
-s->idsp.idct_put(frame->data[plane] + (s->blocks_h - 1 - y) * 8 *
frame->linesize[plane] + x * 8,
- frame->linesize[plane], s->block);
+for (int x = 0; x < s->blocks_w; x++) {
+s->wblocks[64 * x] += offset;
+s->idsp.idct_put(frame->data[plane] + (s->blocks_h - 1 - y) *
8 * frame->linesize[plane] + x * 8,
+ frame->linesize[plane], s->wblocks + 64 * x);
+}
+}
+} else {
+for (int y = 0; y < s->blocks_h; y++) {
+for (int x =
[FFmpeg-devel] [PATCH] avdevice/opengl_enc: fix build error using msvc compiler
0001-avdevice-opengl_enc-fix-build-error-using-msvc-compi.patch Description: 0001-avdevice-opengl_enc-fix-build-error-using-msvc-compi.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/av1: Initialize padding in ff_isom_write_av1c
On 4/8/2019 10:53 AM, Jeremy Dorfman via ffmpeg-devel wrote: > Judging by the code, I think flush_put_bits only pads out to a byte > boundary rather than the end of the buffer. By my read it will run the body > of the while loop 3 times in this case, for bit_left = 8, 16, 24, so only 3 > bytes are filled in header. > > I'd expect this to only affect the actual output in uncommon cases. It > requires the reuse of a stack with non-zero values at the location of > uint8_t header[4]. In the common case of running FFmpeg, it looks like this > is called from the main thread so it should typically be zeroed by the OS. > MemorySanitizer is tagging that region of the stack as uninitialized, so I > don't think this is a false positive -- it doesn't appear to ever be > intentionally written. > > Thanks, > -Jeremy Alright, thanks for the explanation. Pushed. > > On Mon, Apr 8, 2019 at 9:33 AM James Almer wrote: > >> On 4/8/2019 9:14 AM, Jeremy Dorfman via ffmpeg-devel wrote: >>> Otherwise, AV1 encodes with FFmpeg trigger use-of-uninitialized-value >>> warnings under MemorySanitizer, and the output buffer potentially >>> changes from run to run. >>> --- >>> libavformat/av1.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/libavformat/av1.c b/libavformat/av1.c >>> index a0aad436a6..5fde8df97e 100644 >>> --- a/libavformat/av1.c >>> +++ b/libavformat/av1.c >>> @@ -372,6 +372,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const >> uint8_t *buf, int size) >>> put_bits(&pbc, 1, seq_params.chroma_subsampling_x); >>> put_bits(&pbc, 1, seq_params.chroma_subsampling_y); >>> put_bits(&pbc, 2, seq_params.chroma_sample_position); >>> +put_bits(&pbc, 8, 0); // padding >> >> Shouldn't flush_put_bits() below do this? The doxy says "Pad the end of >> the output stream with zeros". >> In any case, i just tried remuxing a single file several times, and in >> all cases the hash of the output file was the same, so it could be a >> false positive from MemorySanitizer. >> >> Patch is fine either way, but i'd like to know why you're getting those >> warnings. >> >>> flush_put_bits(&pbc); >>> >>> avio_write(pb, header, sizeof(header)); >>> >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/dashenc : Fix streaming mode support for webm output
Karthick J via ffmpeg-devel:
> ---
> libavformat/dashenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index f8d71166d4..9dd520787f 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1750,10 +1750,10 @@ static int dash_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
>
> //write out the data immediately in streaming mode
> -if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
> +if (c->streaming) {
> int len = 0;
> uint8_t *buf = NULL;
> -if (!os->written_len)
> +if (!os->written_len && os->segment_type == SEGMENT_TYPE_MP4)
> write_styp(os->ctx->pb);
> avio_flush(os->ctx->pb);
> len = avio_get_dyn_buf (os->ctx->pb, &buf);
>
Did you test this and did it really improve latency? Because it
shouldn't. The matroska/webm muxer always uses its own internal
dynamic buffer for writing the current cluster, i.e. most of your
ff_write_chained() calls that write frames don't generate output at
all. The only difference that your patch seems to make is flushing
os->ctx->pb, which prevents the Matroska muxer from updating the
clusters' length fields (writing clusters as unknown-length might
worsen compability with some clients that don't support this).
It might be that you write and send the cluster header (the cluster
EBML ID + the cluster length field (this is not the real cluster
length, but a length denoting "unknown length"; currently, this length
field will be overwritten with the real size lateron) a bit earlier,
but you don't send the actual packets earlier.
If you want to decrease latency, you basically have two options:
a) You can explicitly flush the muxer (send a NULL packet). You
probably want to use/adapt flush_dynbuf() for this.
b) You can generally lower the cluster size and cluster time limits of
the used Matroska muxer. Currently large limits are used for this. The
Matroska muxer uses way lower default values in case the output isn't
seekable (viewed from the Matroska muxer, the output is seekable).
- Andreas
PS: The above description of the Matroska muxer is based upon current
git head. If [1] gets accepted, there will be two changes:
1. At first only the EBML ID and no length field at all will be written.
2. When the cluster is finally written, the length field will be
written correctly and on the lowest number of bytes possible
(currently it is always written on eight bytes).
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242041.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/av1: Initialize padding in ff_isom_write_av1c
Judging by the code, I think flush_put_bits only pads out to a byte boundary rather than the end of the buffer. By my read it will run the body of the while loop 3 times in this case, for bit_left = 8, 16, 24, so only 3 bytes are filled in header. I'd expect this to only affect the actual output in uncommon cases. It requires the reuse of a stack with non-zero values at the location of uint8_t header[4]. In the common case of running FFmpeg, it looks like this is called from the main thread so it should typically be zeroed by the OS. MemorySanitizer is tagging that region of the stack as uninitialized, so I don't think this is a false positive -- it doesn't appear to ever be intentionally written. Thanks, -Jeremy On Mon, Apr 8, 2019 at 9:33 AM James Almer wrote: > On 4/8/2019 9:14 AM, Jeremy Dorfman via ffmpeg-devel wrote: > > Otherwise, AV1 encodes with FFmpeg trigger use-of-uninitialized-value > > warnings under MemorySanitizer, and the output buffer potentially > > changes from run to run. > > --- > > libavformat/av1.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/libavformat/av1.c b/libavformat/av1.c > > index a0aad436a6..5fde8df97e 100644 > > --- a/libavformat/av1.c > > +++ b/libavformat/av1.c > > @@ -372,6 +372,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const > uint8_t *buf, int size) > > put_bits(&pbc, 1, seq_params.chroma_subsampling_x); > > put_bits(&pbc, 1, seq_params.chroma_subsampling_y); > > put_bits(&pbc, 2, seq_params.chroma_sample_position); > > +put_bits(&pbc, 8, 0); // padding > > Shouldn't flush_put_bits() below do this? The doxy says "Pad the end of > the output stream with zeros". > In any case, i just tried remuxing a single file several times, and in > all cases the hash of the output file was the same, so it could be a > false positive from MemorySanitizer. > > Patch is fine either way, but i'd like to know why you're getting those > warnings. > > > flush_put_bits(&pbc); > > > > avio_write(pb, header, sizeof(header)); > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT
On 4/7/2019 11:02 PM, Fu, Linjie wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Michael Niedermayer >> Sent: Friday, April 5, 2019 00:52 >> To: FFmpeg development discussions and patches > de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find >> exact va_profile for HEVC_REXT >> >> On Thu, Apr 04, 2019 at 04:10:35PM +0800, Linjie Fu wrote: >>> Use the profile constraint flags to determine the exact va_profile for >>> HEVC_REXT. >>> >>> Directly cast PTLCommon to H265RawProfileTierLevel, and use >> ff_h265_get_profile >>> to get the exact profile. >>> >>> Signed-off-by: Linjie Fu >>> --- >>> [v2]: use constraint flags to determine the exact profile, expose the >>> codec-specific stuff at the beginning. >>> [v3]: move the VA version check to fix the compile issue. >>> [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for >>> convenience? The members in PTLCommon should be strictly matched in >>> H265RawProfileTierLevel. >>> >>> libavcodec/vaapi_decode.c | 73 +++-- >> -- >>> 1 file changed, 58 insertions(+), 15 deletions(-) >> >> breaks build with shared libs: >> >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make: *** [ffmpeg_g] Error 1 >> make: *** Waiting for unfinished jobs >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile' >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make: *** [ffplay_g] Error 1 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make: *** [ffprobe_g] Error 1 >> >> > > Hi Michael, > > Thanks for the build check and compile error messages. > Actually, I also did the compile check locally and through pre-patch system. > > We do shared libs compile with gcc and latest libva and msdk master deps, and > it passes the check. > It seems this error occurs with clang. > > Could you provide some details on how to reproduce it? (e.g. compiler, > distro, deps, flags, etc.). > > Thus we can add into the system to refine the pre-patch check and have this > clang compile issue fixed? > > Thanks, > Linjie You need to add h265_profile_level.o to the build objects related to this module in libavcodec/Makefile. It's currently only being built for the hevc vaapi encoder, so if that's disabled, linking will fail. It's most likely not an issue with shared builds. I'm guessing Michael's environment for that build had the hevc vaapi encoder disabled. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: export operational pattern UL as file metadata
On 2019-04-03 21:35, Marton Balint wrote:
Can be useful for API users as ffmpeg/libavformat can't properly support some
operational patterns.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 7 +++
tests/ref/fate/mxf-probe-d10 | 1 +
tests/ref/fate/mxf-probe-dnxhd | 1 +
tests/ref/fate/mxf-probe-dv25 | 1 +
4 files changed, 10 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1ba8ecd4a6..8c65a2bbcf 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -718,6 +719,12 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
}
nb_essence_containers = avio_rb32(pb);
+if (partition->type == Header) {
+char str[36];
+snprintf(str, sizeof(str), "%08x.%08x.%08x.%08x", AV_RB32(&op[0]),
AV_RB32(&op[4]), AV_RB32(&op[8]), AV_RB32(&op[12]));
I was unsure wheter this was the official format for UL, so I went and
checked. SMPTE uses the same in their XML registry:
https://registry.smpte-ra.org/view/published/Labels.xml
Example: urn:smpte:ul:060e2b34.04010101.01010100.
In other words: looks OK to me
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/av1: Initialize padding in ff_isom_write_av1c
On 4/8/2019 9:14 AM, Jeremy Dorfman via ffmpeg-devel wrote: > Otherwise, AV1 encodes with FFmpeg trigger use-of-uninitialized-value > warnings under MemorySanitizer, and the output buffer potentially > changes from run to run. > --- > libavformat/av1.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/av1.c b/libavformat/av1.c > index a0aad436a6..5fde8df97e 100644 > --- a/libavformat/av1.c > +++ b/libavformat/av1.c > @@ -372,6 +372,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t > *buf, int size) > put_bits(&pbc, 1, seq_params.chroma_subsampling_x); > put_bits(&pbc, 1, seq_params.chroma_subsampling_y); > put_bits(&pbc, 2, seq_params.chroma_sample_position); > +put_bits(&pbc, 8, 0); // padding Shouldn't flush_put_bits() below do this? The doxy says "Pad the end of the output stream with zeros". In any case, i just tried remuxing a single file several times, and in all cases the hash of the output file was the same, so it could be a false positive from MemorySanitizer. Patch is fine either way, but i'd like to know why you're getting those warnings. > flush_put_bits(&pbc); > > avio_write(pb, header, sizeof(header)); > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/1] libavformat/dashenc : Prevent writing manifest files multiple times
---
libavformat/dashenc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f8d71166d4..4585a46202 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -145,6 +145,8 @@ typedef struct DASHContext {
int ignore_io_errors;
int lhls;
int master_publish_rate;
+int nr_of_streams_to_flush;
+int nr_of_streams_flushed;
} DASHContext;
static struct codec_string {
@@ -1089,6 +1091,7 @@ static int dash_init(AVFormatContext *s)
char *ptr;
char basename[1024];
+c->nr_of_streams_to_flush = 0;
if (c->single_file_name)
c->single_file = 1;
if (c->single_file)
@@ -1302,12 +1305,18 @@ static int dash_init(AVFormatContext *s)
os->max_pts = AV_NOPTS_VALUE;
os->last_dts = AV_NOPTS_VALUE;
os->segment_index = 1;
+
+if (s->streams[i]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO)
+c->nr_of_streams_to_flush++;
}
if (!c->has_video && c->seg_duration <= 0) {
av_log(s, AV_LOG_WARNING, "no video stream and no seg duration set\n");
return AVERROR(EINVAL);
}
+
+c->nr_of_streams_flushed = 0;
+
return 0;
}
@@ -1616,8 +1625,16 @@ static int dash_flush(AVFormatContext *s, int final, int
stream)
}
}
}
-if (ret >= 0)
+if (ret >= 0) {
+if (c->has_video) {
+c->nr_of_streams_flushed++;
+if (c->nr_of_streams_flushed != c->nr_of_streams_to_flush)
+return ret;
+
+c->nr_of_streams_flushed = 0;
+}
ret = write_manifest(s, final);
+}
return ret;
}
--
2.17.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/1] libavformat/dashenc : Prevent writing manifest files multiple times
This is the second attempt which prevents writing the manifest files too many times. I fixed the audio only case. joepadmiraal (1): libavformat/dashenc : Prevent writing manifest files multiple times libavformat/dashenc.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) -- 2.17.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/av1: Initialize padding in ff_isom_write_av1c
Otherwise, AV1 encodes with FFmpeg trigger use-of-uninitialized-value warnings under MemorySanitizer, and the output buffer potentially changes from run to run. --- libavformat/av1.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/av1.c b/libavformat/av1.c index a0aad436a6..5fde8df97e 100644 --- a/libavformat/av1.c +++ b/libavformat/av1.c @@ -372,6 +372,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, int size) put_bits(&pbc, 1, seq_params.chroma_subsampling_x); put_bits(&pbc, 1, seq_params.chroma_subsampling_y); put_bits(&pbc, 2, seq_params.chroma_sample_position); +put_bits(&pbc, 8, 0); // padding flush_put_bits(&pbc); avio_write(pb, header, sizeof(header)); -- 2.21.0.392.gf8f6787159e-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/dashenc : Fix streaming mode support for webm output
---
libavformat/dashenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index f8d71166d4..9dd520787f 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1750,10 +1750,10 @@ static int dash_write_packet(AVFormatContext *s,
AVPacket *pkt)
}
//write out the data immediately in streaming mode
-if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
+if (c->streaming) {
int len = 0;
uint8_t *buf = NULL;
-if (!os->written_len)
+if (!os->written_len && os->segment_type == SEGMENT_TYPE_MP4)
write_styp(os->ctx->pb);
avio_flush(os->ctx->pb);
len = avio_get_dyn_buf (os->ctx->pb, &buf);
--
2.20.1 (Apple Git-117)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 08/21] avformat/matroskadec: Improve error messages
Steve Lhomme:
>> On April 7, 2019 at 11:24 AM Andreas Rheinhardt via ffmpeg-devel
>> wrote:
>>
>>
>> Steve Lhomme:
>>> On 3/27/2019 12:18 PM, Andreas Rheinhardt via ffmpeg-devel wrote:
ebml_read_num had a number of flaws:
1. The check for read errors/EOF was totally wrong. E.g. an EBML number
beginning with the invalid 0x00 would be considered a read error,
although it is just invalid data.
2. The check for read errors/EOF was done just once, after reading the
first byte of the EBML number. But errors/EOF can happen inbetween, of
course, and this wasn't checked.
3. There was no way to distinguish when EOF should be an error (because
the data has to be there) for which an error message should be emitted
and when it is not necessarily an error (namely during parsing of EBML
IDs). Such a possibility has been added and used.
>>>
>>> Maybe the title of the patch should rather mention that it's fixing
>>> the EOF handling when reading EBML ID/Length. The changed error
>>> messages is a less important consequence.
>>>
>> How about "avformat/matroskadec: Improve (in particular) EOF checks"?
>>>
Some useless initializations were also fixed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 61
++-
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index a6617a607b..aa2266384a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -820,29 +820,19 @@ static int ebml_level_end(MatroskaDemuxContext
*matroska)
* Returns: number of bytes read, < 0 on error
*/
static int ebml_read_num(MatroskaDemuxContext *matroska,
AVIOContext *pb,
- int max_size, uint64_t *number)
+ int max_size, uint64_t *number, int
eof_forbidden)
{
- int read = 1, n = 1;
- uint64_t total = 0;
+ int read, n = 1;
+ uint64_t total;
+ int64_t pos;
- /* The first byte tells us the length in bytes - avio_r8()
can normally
- * return 0, but since that's not a valid first ebmlID byte, we
can
- * use it safely here to catch EOS. */
- if (!(total = avio_r8(pb))) {
- /* we might encounter EOS here */
- if (!avio_feof(pb)) {
- int64_t pos = avio_tell(pb);
- av_log(matroska->ctx, AV_LOG_ERROR,
- "Read error at pos. %"PRIu64" (0x%"PRIx64")\n",
- pos, pos);
- return pb->error ? pb->error : AVERROR(EIO);
- }
- return AVERROR_EOF;
- }
+ /* The first byte tells us the length in bytes - except when it
is zero. */
+ total = avio_r8(pb);
+ if (avio_feof(pb))
+ goto err;
/* get the length of the EBML number */
- read = 8 - ff_log2_tab[total];
- if (read > max_size) {
+ if (!total || (read = 8 - ff_log2_tab[total]) > max_size) {
int64_t pos = avio_tell(pb) - 1;
av_log(matroska->ctx, AV_LOG_ERROR,
"Invalid EBML number size tag 0x%02x at pos
%"PRIu64" (0x%"PRIx64")\n",
@@ -855,9 +845,27 @@ static int ebml_read_num(MatroskaDemuxContext
*matroska, AVIOContext *pb,
while (n++ < read)
total = (total << 8) | avio_r8(pb);
+ if (avio_feof(pb)) {
+ eof_forbidden = 1;
+ goto err;
+ }
>>>
>>> You're forcing an error if the data ends after reading a number ?
>>> Ending a Matroska file with a number should be fine. It could also be
>>> an element with a size of 0. It doesn't contain any data but it's
>>> still valid (depending on the semantic of the element).
>>>
>>> So this forced error seem wrong. Let the next read catch the EOF if it
>>> finds one.
>>>
>> avio_feof doesn't indicate an error if we reach EOF, only if we
>> attempt to read past EOF (or if another error occurred). If the EBML
>> number we intend to parse is completely read, then no error is
>> indicated here at all. If the input ends immediately after this EBML
>> number, then the next read will trigger EOF and will have to catch it.
>
> OK, it makes sense.
>
>> If avio_feof is set at this point, it means that the first byte of the
>> EBML number says that the EBML number is total bytes long, but an
>> error or EOF occured during reading of these bytes. I think this
>> warrants an error. eof_forbidden is set at this point so that an
>> incomplete EBML number will always trigger an error.
>
> OK
>
+
*number = total;
return read;
+
+err:
+ pos = avio_tell(pb);
+ if (pb->error) {
+ av_log(matroska->ctx, AV_LOG_ERROR,
+ "Read e
Re: [FFmpeg-devel] [PATCH RFC v2 2/3] libavcodec: Add thumbnail output to vaapi_h264 decoder
On Mon, Apr 8, 2019 at 10:54 AM Zachary Zhou wrote:
>
> This is sample code for reference
>
> HW support for decode+scaling in a single HW command (VDBOX+SFC).
> The primary target usage is video analytics, but can be used playback,
> transcoding, etc.
>
> For VAAPI -
> https://github.com/intel/libva
> basically, it allows multiple outputs (in different resolutions) using the
> decode context in a single call (you can search for “additional_outputs” in
> va.h).
>
> VAAPI sample code -
> https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
> ---
> libavcodec/avcodec.h | 8 +++
> libavcodec/decode.c| 16 +
> libavcodec/options_table.h | 4 ++
> libavcodec/vaapi_decode.c | 122 ++---
> libavcodec/vaapi_decode.h | 30 +
> libavcodec/vaapi_h264.c| 13
> 6 files changed, 185 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 0ce22ec4fa..36db21c0a5 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3357,6 +3357,14 @@ typedef struct AVCodecContext {
> * - encoding: unused
> */
> int discard_damaged_percentage;
> +
> +/*
> + * Thumbnail options
> + */
> +int thumbnail_flags;
> +int thumbnail_format;
> +int thumbnail_width;
> +int thumbnail_height;
> } AVCodecContext;
>
Global fields for such a purpose seem not appropriate. We try to get
away from fields that only serve a single purpose with a single
decoder. Nevermind that they aren't even documented.
In general I must say I'm not sure I like this entire patchset. We
have component seperation for a reason, so trying to add magic
features like that is generally a bad idea.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH RFC v2 1/3] fftools: Add thumbnail output to vaapi_h264 decoder
On Mon, Apr 8, 2019 at 4:54 PM Zachary Zhou wrote:
>
> This is sample code for reference
>
> HW support for decode+scaling in a single HW command (VDBOX+SFC).
> The primary target usage is video analytics, but can be used playback,
> transcoding, etc.
>
> For VAAPI -
> https://github.com/intel/libva
> basically, it allows multiple outputs (in different resolutions) using the
> decode context in a single call (you can search for “additional_outputs” in
> va.h).
>
> VAAPI sample code -
> https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
> ---
> fftools/ffmpeg_opt.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 53d688b764..c0dc376541 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -111,6 +111,10 @@ int filter_nbthreads = 0;
> int filter_complex_nbthreads = 0;
> int vstats_version = 2;
>
> +int thumbnail_flags = 0;
> +int thumbnail_width = 0;
> +int thumbnail_height = 0;
> +char *thumbnail_format;
>
> static int intra_only = 0;
> static int file_overwrite = 0;
> @@ -1100,6 +1104,13 @@ static int open_input_file(OptionsContext *o, const
> char *filename)
> av_dict_set(&o->g->format_opts, "scan_all_pmts", "1",
> AV_DICT_DONT_OVERWRITE);
> scan_all_pmts_set = 1;
> }
> +
> +//thumbnail opt
> +av_dict_set_int(&o->g->codec_opts, "thumbnail_flags", thumbnail_flags,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_set_int(&o->g->codec_opts, "thumbnail_width", thumbnail_width,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_set_int(&o->g->codec_opts, "thumbnail_height", thumbnail_height,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_set(&o->g->codec_opts, "thumbnail_format", thumbnail_format,
> AV_DICT_DONT_OVERWRITE);
> +
> /* open the input file with generic avformat function */
> err = avformat_open_input(&ic, filename, file_iformat,
> &o->g->format_opts);
> if (err < 0) {
> @@ -2898,6 +2909,13 @@ static int opt_vstats_file(void *optctx, const char
> *opt, const char *arg)
> return 0;
> }
>
> +static int opt_thumbnail_format(void *optctx, const char *opt, const char
> *arg)
> +{
> +av_free (thumbnail_format);
> +thumbnail_format = av_strdup (arg);
> +return 0;
> +}
> +
> static int opt_vstats(void *optctx, const char *opt, const char *arg)
> {
> char filename[40];
> @@ -3746,5 +3764,15 @@ const OptionDef options[] = {
> { "filter_hw_device", HAS_ARG | OPT_EXPERT, { .func_arg =
> opt_filter_hw_device },
> "set hardware device used when filtering", "device" },
>
> +//thumbnail opt
> +{ "thumbnail_flags",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, {
> &thumbnail_flags },
> + "set thumbnail flags", "thumbnail" },
> +{ "thumbnail_width",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, {
> &thumbnail_width },
> + "set thumbnail width", "thumbnail" },
> +{ "thumbnail_height", OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, {
> &thumbnail_height },
> + "set thumbnail height", "thumbnail" },
> +{ "thumbnail_format", OPT_VIDEO | HAS_ARG | OPT_EXPERT , { .func_arg =
> opt_thumbnail_format },
> +"set thumbnail format", "thumbnail" },
> +
> { NULL, },
> };
> --
> 2.17.1
Changed the FFmpeg tools for a hardware specific feature is not good
idea, I think.
The other question is, how to enable this function from FFmpeg API
level？ (We can not just enable a feature from the FFmpeg command
tools).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH RFC v2 3/3] libavutil: Add thumbnail output to vaapi_h264 decoder
This is sample code for reference
HW support for decode+scaling in a single HW command (VDBOX+SFC).
The primary target usage is video analytics, but can be used playback,
transcoding, etc.
For VAAPI -
https://github.com/intel/libva
basically, it allows multiple outputs (in different resolutions) using the
decode context in a single call (you can search for “additional_outputs” in
va.h).
VAAPI sample code -
https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
---
libavutil/frame.c | 1 +
libavutil/frame.h | 13 +++
libavutil/hwcontext_vaapi.c | 73 -
libavutil/hwcontext_vaapi.h | 6 +++
4 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index dcf1fc3d17..14bcb456c9 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -842,6 +842,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
#endif
case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
SMPTE2094-40 (HDR10+)";
case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
+case AV_FRAME_DATA_THUMBNAIL_INFO: return "Thumbnail Information";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 8aa3e88367..2f3ac0cb23 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -179,6 +179,11 @@ enum AVFrameSideDataType {
* array element is implied by AVFrameSideData.size /
AVRegionOfInterest.self_size.
*/
AV_FRAME_DATA_REGIONS_OF_INTEREST,
+
+/**
+ * VDENC Thumbnail information.
+ */
+AV_FRAME_DATA_THUMBNAIL_INFO,
};
enum AVActiveFormatDescription {
@@ -235,6 +240,14 @@ typedef struct AVRegionOfInterest {
AVRational qoffset;
} AVRegionOfInterest;
+/**
+ * Structure to hold Information of Thumbnail.
+ *
+ */
+typedef struct AVThumbnailInfo {
+uint8_t *data;
+} AVThumbnailInfo;
+
/**
* This structure describes decoded (raw) audio or video data.
*
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 8624369bb9..cacd352ebb 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -642,8 +642,74 @@ static void vaapi_frames_uninit(AVHWFramesContext *hwfc)
av_freep(&ctx->attributes);
}
+static int vaapi_get_thumbnail_buffer(AVHWFramesContext *hwfc, AVFrame *frame)
+{
+AVVAAPIFramesContext *avfc = hwfc->hwctx;
+AVFrameSideData *frame_thumbnail_sd = av_frame_get_side_data(frame,
+
AV_FRAME_DATA_THUMBNAIL_INFO);
+if (frame_thumbnail_sd) {
+AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
+VASurfaceID thumbnail_surface_id;
+VASurfaceAttrib attrib;
+unsigned int rt_format;
+AVBufferRef *ref;
+VAStatus vas;
+
+memset(&attrib, 0, sizeof(attrib));
+attrib.type = VASurfaceAttribPixelFormat;
+attrib.flags = VA_SURFACE_ATTRIB_SETTABLE;
+attrib.value.type = VAGenericValueTypeInteger;
+
+switch (avfc->thumbnail_format) {
+case AV_PIX_FMT_NV12:
+attrib.value.value.i = VA_FOURCC_NV12;
+rt_format = VA_RT_FORMAT_YUV420;
+break;
+case AV_PIX_FMT_ARGB:
+attrib.value.value.i = VA_FOURCC_ARGB;
+rt_format = VA_RT_FORMAT_RGB32;
+break;
+default:
+av_log(hwfc, AV_LOG_ERROR, "Unknown sfc format: %d\n",
avfc->thumbnail_format);
+return AVERROR(EINVAL);
+}
+
+vas = vaCreateSurfaces(hwctx->display, rt_format,
+ avfc->thumbnail_width, avfc->thumbnail_height,
+ &thumbnail_surface_id, 1,
+ &attrib, 1);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(hwfc, AV_LOG_ERROR, "Failed to create sfc surface: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR(EIO);
+}
+
+av_log(hwfc, AV_LOG_DEBUG, "Created sfc surface %#x.
thumbnail_format(%d), w(%d), h(%d)\n",
+ thumbnail_surface_id, avfc->thumbnail_format,
avfc->thumbnail_width, avfc->thumbnail_height);
+
+ref = av_buffer_create((uint8_t*)(uintptr_t)thumbnail_surface_id,
+ sizeof(thumbnail_surface_id),
&vaapi_buffer_free,
+ hwfc, AV_BUFFER_FLAG_READONLY);
+if (!ref) {
+vaDestroySurfaces(hwctx->display, &thumbnail_surface_id, 1);
+return AVERROR(EIO);
+}
+
+frame_thumbnail_sd->buf = ref;
+
+av_log(hwfc, AV_LOG_DEBUG, "Created sfc av buffer ref: %p\n", ref);
+
+} else {
+av_log(hwfc, AV_LOG_DEBUG, "VDSFC frame_thumbnail_sd is null\n");
+}
+
+return 0;
+}
+
static int vaapi_get_buffer(AVHWFramesContext *hwfc, AVFrame *frame)
{
+int err;
+
frame->buf[0] = av_buffer_pool_get(hwfc->pool);
if (!fra
[FFmpeg-devel] [PATCH RFC v2 2/3] libavcodec: Add thumbnail output to vaapi_h264 decoder
This is sample code for reference
HW support for decode+scaling in a single HW command (VDBOX+SFC).
The primary target usage is video analytics, but can be used playback,
transcoding, etc.
For VAAPI -
https://github.com/intel/libva
basically, it allows multiple outputs (in different resolutions) using the
decode context in a single call (you can search for “additional_outputs” in
va.h).
VAAPI sample code -
https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
---
libavcodec/avcodec.h | 8 +++
libavcodec/decode.c| 16 +
libavcodec/options_table.h | 4 ++
libavcodec/vaapi_decode.c | 122 ++---
libavcodec/vaapi_decode.h | 30 +
libavcodec/vaapi_h264.c| 13
6 files changed, 185 insertions(+), 8 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0ce22ec4fa..36db21c0a5 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3357,6 +3357,14 @@ typedef struct AVCodecContext {
* - encoding: unused
*/
int discard_damaged_percentage;
+
+/*
+ * Thumbnail options
+ */
+int thumbnail_flags;
+int thumbnail_format;
+int thumbnail_width;
+int thumbnail_height;
} AVCodecContext;
#if FF_API_CODEC_GET_SET
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a32ff2fcd3..2107751197 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1795,6 +1795,22 @@ FF_ENABLE_DEPRECATION_WARNINGS
frame->channels = avctx->channels;
break;
}
+
+//thumbnail side data
+if (avctx->thumbnail_flags) {
+AVFrameSideData *frame_thumbnail_sd = av_frame_new_side_data(frame,
+
AV_FRAME_DATA_THUMBNAIL_INFO,
+
sizeof(AVThumbnailInfo));
+if (frame_thumbnail_sd) {
+av_dict_set_int(&frame_thumbnail_sd->metadata, "thumbnail_flags",
avctx->thumbnail_flags, 0);
+av_dict_set_int(&frame_thumbnail_sd->metadata, "thumbnail_width",
avctx->thumbnail_width, 0);
+av_dict_set_int(&frame_thumbnail_sd->metadata, "thumbnail_height",
avctx->thumbnail_height, 0);
+av_dict_set_int(&frame_thumbnail_sd->metadata, "thumbnail_format",
avctx->thumbnail_format, 0);
+
+av_log(avctx, AV_LOG_DEBUG, "Thumbnail new side data\n");
+}
+}
+
return 0;
}
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index a3235bcd57..aa158f713c 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -480,6 +480,10 @@ static const AVOption avcodec_options[] = {
{"allow_profile_mismatch", "attempt to decode anyway if HW accelerated
decoder's supported profiles do not exactly match the stream", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN,
INT_MAX, V | D, "hwaccel_flags"},
{"extra_hw_frames", "Number of extra hardware frames to allocate for the
user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
V|D },
{"discard_damaged_percentage", "Percentage of damaged samples to discard a
frame", OFFSET(discard_damaged_percentage), AV_OPT_TYPE_INT, {.i64 = 95 }, 0,
100, V|D },
+{"thumbnail_flags", "set thumbnail flags", OFFSET(thumbnail_flags),
AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, V|D, "thumbnail"},
+{"thumbnail_format", "set thumbnail format", OFFSET(thumbnail_format),
AV_OPT_TYPE_PIXEL_FMT, {.i64=AV_PIX_FMT_ARGB}, -1, INT_MAX, V|D, "thumbnail"},
+{"thumbnail_width", "set thumbnail width", OFFSET(thumbnail_width),
AV_OPT_TYPE_INT, {.i64 = 480}, 0, INT_MAX, V|D, "thumbnail"},
+{"thumbnail_height", "set thumbnail height", OFFSET(thumbnail_height),
AV_OPT_TYPE_INT, {.i64 = 360}, 0, INT_MAX, V|D, "thumbnail"},
{NULL},
};
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 69512e1d45..2e9e762dc0 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -145,6 +145,17 @@ static void ff_vaapi_decode_destroy_buffers(AVCodecContext
*avctx,
pic->slice_buffers[i], vas, vaErrorStr(vas));
}
}
+
+//destory thumbnail buffer
+if (avctx->thumbnail_flags) {
+vas = vaDestroyBuffer(ctx->hwctx->display,
+ pic->thumbnail_buffer);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to destroy thumbnail "
+ "buffer %#x: %d (%s).\n",
+ pic->thumbnail_buffer, vas, vaErrorStr(vas));
+}
+}
}
int ff_vaapi_decode_issue(AVCodecContext *avctx,
@@ -184,6 +195,56 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
goto fail_with_picture;
}
+//add thumbnail buffer
+if (avctx->thumbnail_flags) {
+VARectangle rect_src; /**< @brief Rectangle for source
input */
+VARectangle rect_thumbnail;/**< @brief Rectang
[FFmpeg-devel] [PATCH RFC v2 1/3] fftools: Add thumbnail output to vaapi_h264 decoder
This is sample code for reference
HW support for decode+scaling in a single HW command (VDBOX+SFC).
The primary target usage is video analytics, but can be used playback,
transcoding, etc.
For VAAPI -
https://github.com/intel/libva
basically, it allows multiple outputs (in different resolutions) using the
decode context in a single call (you can search for “additional_outputs” in
va.h).
VAAPI sample code -
https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
---
fftools/ffmpeg_opt.c | 28
1 file changed, 28 insertions(+)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 53d688b764..c0dc376541 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -111,6 +111,10 @@ int filter_nbthreads = 0;
int filter_complex_nbthreads = 0;
int vstats_version = 2;
+int thumbnail_flags = 0;
+int thumbnail_width = 0;
+int thumbnail_height = 0;
+char *thumbnail_format;
static int intra_only = 0;
static int file_overwrite = 0;
@@ -1100,6 +1104,13 @@ static int open_input_file(OptionsContext *o, const char
*filename)
av_dict_set(&o->g->format_opts, "scan_all_pmts", "1",
AV_DICT_DONT_OVERWRITE);
scan_all_pmts_set = 1;
}
+
+//thumbnail opt
+av_dict_set_int(&o->g->codec_opts, "thumbnail_flags", thumbnail_flags,
AV_DICT_DONT_OVERWRITE);
+av_dict_set_int(&o->g->codec_opts, "thumbnail_width", thumbnail_width,
AV_DICT_DONT_OVERWRITE);
+av_dict_set_int(&o->g->codec_opts, "thumbnail_height", thumbnail_height,
AV_DICT_DONT_OVERWRITE);
+av_dict_set(&o->g->codec_opts, "thumbnail_format", thumbnail_format,
AV_DICT_DONT_OVERWRITE);
+
/* open the input file with generic avformat function */
err = avformat_open_input(&ic, filename, file_iformat, &o->g->format_opts);
if (err < 0) {
@@ -2898,6 +2909,13 @@ static int opt_vstats_file(void *optctx, const char
*opt, const char *arg)
return 0;
}
+static int opt_thumbnail_format(void *optctx, const char *opt, const char *arg)
+{
+av_free (thumbnail_format);
+thumbnail_format = av_strdup (arg);
+return 0;
+}
+
static int opt_vstats(void *optctx, const char *opt, const char *arg)
{
char filename[40];
@@ -3746,5 +3764,15 @@ const OptionDef options[] = {
{ "filter_hw_device", HAS_ARG | OPT_EXPERT, { .func_arg =
opt_filter_hw_device },
"set hardware device used when filtering", "device" },
+//thumbnail opt
+{ "thumbnail_flags",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, {
&thumbnail_flags },
+ "set thumbnail flags", "thumbnail" },
+{ "thumbnail_width",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, {
&thumbnail_width },
+ "set thumbnail width", "thumbnail" },
+{ "thumbnail_height", OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, {
&thumbnail_height },
+ "set thumbnail height", "thumbnail" },
+{ "thumbnail_format", OPT_VIDEO | HAS_ARG | OPT_EXPERT , { .func_arg =
opt_thumbnail_format },
+"set thumbnail format", "thumbnail" },
+
{ NULL, },
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 00/21] New Version
> On April 7, 2019 at 8:56 PM Andreas Rheinhardt via ffmpeg-devel > wrote: > > > Hello, > > thanks for taking the time to review this. Much appreciated. > > Steve Lhomme: > > Hi, > > > > On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote: > >> This also changed the handling of unknown-sized elements: They are now > >> ended whenever an element not known to be allowed in them is > >> encountered. If we are already on level 1 and encounter an element not > >> known to be allowed in an unknown-sized segment, this is treated as an > >> indication that an error might have occured. I hope this is fine. > > > > I haven't looked at the code yet, but an unknown element doesn't mean > > it's an upper level element. I think it should be either skipped or > > considered as bad data. If it's a known element but complitely > > misplaced it should not be going upper in the hierarchy. Only when a > > valid upper element it should go up in the hierarchy. > > > 1. Actually the current approach is equivalent to considering unknown > elements in an unknown-sized element as bad data: If a new ID isn't in > the current syntax list, then we treat this as an indication that the > current level ended and test with the next higher level and so on > until we arrive at level 1. If it then isn't a valid level 1 element, > then it is being treated as an error. > > 2. But as you have said (in your last mail), this approach won't work > with extensions like RAWCooked. So a check for whether an element is > from a higher level needs to be implemented and unknown elements with > finite size should be skipped. > > 3. But there are practical complications: > a) If an error occurred, then it is possible that we encounter garbage > that looks like a very big unknown element. I'd image that trying to > skip it might very well lead to problems, in particular in case of > livestreaming. So there should be a sanity check for this, i.e. very > big unknown elements should be considered as errors. In libebml when we read an element we read the ID and length at once and verify that the length is valid for that ID (based on its type) and its parent (doesn't go over the boundary if there is one). If an element is unknown (known at a different level is considered unknown) with a valid size then we either keep it as such or consider it's an error (that's a flag when reading telling which behavior we want). That's basically like choosing between a strict respect of the specs or allow extensions/customization. By default the more relaxed approach should be used in a reader, so keeping the elements as unknown. If the direct parent (Cluster) doesn't have a known size and you encounter some unknown IDs, you have no way to know if the data are correct or not. Given unknown length/live streaming already imposes restrictions on what elements are allowed, it would be OK to assume that anything outside of known elements is an error. But considering it's bad data and wait for known data would work as well. In any case you're not going to make use of the data (unlike libebml which may be used to track/report such cases) it doesn't really matter which way you decide to use. > b) And it is also possible that we encounter quite a few possibly > legal unknown elements (that are skipped) in a row. I think it's > reasonable to view this as an indication that an error occurred, too. > How long should these chains of unknown elements be for it to trigger > this error? Three? Four? Five? > c) In both cases, resyncing should begin at the last known good > position, not at the current position. You can't resync during live streaming which is what the unknown length feature is for. But then I don't know if the current demuxer code is ready for that. In VLC I had to use a stream filter disabling seeking to make sure we never try to seek during live streaming. > Do you agree with me regarding 2. and 3.? Yes, with my additional remarks. > 4. Would it actually be legal for an extension like RAWCooked to > implement new potentially unknown-sized elements? I haven't found > anything on this topic that says it is illegal, so I presume it is > legal. But it shouldn't be IMO if it wants to be an extension that can > be played by normal players (that don't know these extra elements), as > unknown-sized elements simply can't be skipped. I wouldn't know how to > handle them other than resyncing to the next known level 1 element, so > it would be nice not to have to worry about unknown master elements > with unknown size. That's probably something to discuss on the CELLAR mailing list. I don't have a strong opinion on this. As said above it shouldn't impact much playback since in both cases you'd drop the data and find the following proper data. > >> > >> Dale's sample "bear-320x240-live.webm" btw has cues at the end that use > >> unknown-sized elements (wastefully coded on eight bytes) for > >> CuePoints and > >> CueTrackPositions which is spec-incomplian
Re: [FFmpeg-devel] [PATCH v1 2/3] libavcodec: Add thumbnail output to vaapi_h264 decoder
> -Original Message-
> From: Zhou, Zachary
> Sent: Monday, April 8, 2019 3:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhou, Zachary
> Subject: [PATCH v1 2/3] libavcodec: Add thumbnail output to vaapi_h264
> decoder
>
> This is sample code for reference
>
> HW support for decode+scaling in a single HW command (VDBOX+SFC).
> The primary target usage is video analytics, but can be used playback,
> transcoding, etc.
>
> For VAAPI -
> https://github.com/intel/libva
> basically, it allows multiple outputs (in different resolutions) using the
> decode
> context in a single call (you can search for “additional_outputs” in va.h).
>
> VAAPI sample code -
> https://github.com/intel/libva-
> utils/commit/957a269f02b00760b7e807643c821ee26abc529b
> ---
> libavcodec/avcodec.h | 8 +++
> libavcodec/decode.c| 16 +
> libavcodec/options_table.h | 4 ++
> libavcodec/vaapi_decode.c | 122 ++---
> libavcodec/vaapi_decode.h | 30 +
> libavcodec/vaapi_h264.c| 13
> 6 files changed, 185 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index
> 0ce22ec4fa..86ab18011c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3357,6 +3357,14 @@ typedef struct AVCodecContext {
> * - encoding: unused
> */
> int discard_damaged_percentage;
> +
> +/*
> + * VDSFC options
> + */
> +int sfc_flags;
> +int sfc_format;
> +int sfc_width;
> +int sfc_height;
> } AVCodecContext;
>
> #if FF_API_CODEC_GET_SET
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c index
> a32ff2fcd3..df5f5b6eed 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1795,6 +1795,22 @@ FF_ENABLE_DEPRECATION_WARNINGS
> frame->channels = avctx->channels;
> break;
> }
> +
> +//sfc side data
> +if (avctx->sfc_flags) {
> +AVFrameSideData *frame_sfc_sd = av_frame_new_side_data(frame,
> +
> AV_FRAME_DATA_SFC_INFO,
> +
> sizeof(AVSFCInfo));
> +if (frame_sfc_sd) {
> +av_dict_set_int(&frame_sfc_sd->metadata, "sfc_flags", avctx-
> >sfc_flags, 0);
> +av_dict_set_int(&frame_sfc_sd->metadata, "sfc_width", avctx-
> >sfc_width, 0);
> +av_dict_set_int(&frame_sfc_sd->metadata, "sfc_height", avctx-
> >sfc_height, 0);
> +av_dict_set_int(&frame_sfc_sd->metadata, "sfc_format",
> + avctx->sfc_format, 0);
> +
> +av_log(avctx, AV_LOG_DEBUG, "VDSFC new side data\n");
> +}
> +}
> +
> return 0;
> }
>
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h index
> a3235bcd57..c14ff08678 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -480,6 +480,10 @@ static const AVOption avcodec_options[] =
> { {"allow_profile_mismatch", "attempt to decode anyway if HW accelerated
> decoder's supported profiles do not exactly match the stream", 0,
> AV_OPT_TYPE_CONST, {.i64 =
> AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN, INT_MAX, V |
> D, "hwaccel_flags"}, {"extra_hw_frames", "Number of extra hardware frames
> to allocate for the user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64
> = -1 }, -1, INT_MAX, V|D }, {"discard_damaged_percentage", "Percentage of
> damaged samples to discard a frame", OFFSET(discard_damaged_percentage),
> AV_OPT_TYPE_INT, {.i64 = 95 }, 0, 100, V|D },
> +{"sfc_flags", "set sfc flags", OFFSET(sfc_flags), AV_OPT_TYPE_INT, {
> +.i64 = 1 }, 0, 1, V|D, "sfc"}, {"sfc_format", "set sfc format",
> +OFFSET(sfc_format), AV_OPT_TYPE_PIXEL_FMT, {.i64=AV_PIX_FMT_ARGB}, -
> 1,
> +INT_MAX, V|D, "sfc"}, {"sfc_width", "set sfc width", OFFSET(sfc_width),
> +AV_OPT_TYPE_INT, {.i64 = 480}, 0, INT_MAX, V|D, "sfc"}, {"sfc_height",
> +"set sfc height", OFFSET(sfc_height), AV_OPT_TYPE_INT, {.i64 = 360}, 0,
> +INT_MAX, V|D, "sfc"},
> {NULL},
> };
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c index
> 69512e1d45..2917ee951e 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -145,6 +145,17 @@ static void
> ff_vaapi_decode_destroy_buffers(AVCodecContext *avctx,
> pic->slice_buffers[i], vas, vaErrorStr(vas));
> }
> }
> +
> +//destory sfc buffer
> +if (avctx->sfc_flags) {
> +vas = vaDestroyBuffer(ctx->hwctx->display,
> + pic->sfc_buffer);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to destroy sfc "
> + "buffer %#x: %d (%s).\n",
> + pic->sfc_buffer, vas, vaErrorStr(vas));
> +}
> +}
> }
>
> int ff_vaapi_decode_issue(AVCodecContext *avctx, @@ -184,6 +195,56 @@
> int ff_vaapi_decode_issue(AVCodecContext *avctx,
> goto fail_with_picture;
> }
>
> +//add sf
Re: [FFmpeg-devel] [PATCH v1 3/3] libavutil: Add thumbnail output to vaapi_h264 decoder
> -Original Message-
> From: Zhou, Zachary
> Sent: Monday, April 8, 2019 3:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhou, Zachary
> Subject: [PATCH v1 3/3] libavutil: Add thumbnail output to vaapi_h264
> decoder
>
> This is sample code for reference
>
> HW support for decode+scaling in a single HW command (VDBOX+SFC).
> The primary target usage is video analytics, but can be used playback,
> transcoding, etc.
>
> For VAAPI -
> https://github.com/intel/libva
> basically, it allows multiple outputs (in different resolutions) using the
> decode
> context in a single call (you can search for “additional_outputs” in va.h).
>
> VAAPI sample code -
> https://github.com/intel/libva-
> utils/commit/957a269f02b00760b7e807643c821ee26abc529b
> ---
> libavutil/frame.c | 1 +
> libavutil/frame.h | 13 +++
> libavutil/hwcontext_vaapi.c | 73 -
> libavutil/hwcontext_vaapi.h | 6 +++
> 4 files changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c index
> dcf1fc3d17..aa9cd744ae
> 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -842,6 +842,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type) #endif
> case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic
> Metadata SMPTE2094-40 (HDR10+)";
> case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of
> Interest";
> +case AV_FRAME_DATA_SFC_INFO: return "SFC Information";
> }
> return NULL;
> }
> diff --git a/libavutil/frame.h b/libavutil/frame.h index
> 8aa3e88367..616e7d9d4e 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -179,6 +179,11 @@ enum AVFrameSideDataType {
> * array element is implied by AVFrameSideData.size /
> AVRegionOfInterest.self_size.
> */
> AV_FRAME_DATA_REGIONS_OF_INTEREST,
> +
> +/**
> + * VDENC SFC information.
> + */
> +AV_FRAME_DATA_SFC_INFO,
> };
>
> enum AVActiveFormatDescription {
> @@ -235,6 +240,14 @@ typedef struct AVRegionOfInterest {
> AVRational qoffset;
> } AVRegionOfInterest;
>
> +/**
> + * Structure to hold Information of SFC.
> + *
> + */
> +typedef struct AVSFCInfo {
> +uint8_t *data;
> +} AVSFCInfo;
> +
> /**
> * This structure describes decoded (raw) audio or video data.
> *
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> 8624369bb9..caa6d02b15 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -642,8 +642,74 @@ static void
> vaapi_frames_uninit(AVHWFramesContext *hwfc)
> av_freep(&ctx->attributes);
> }
>
> +static int vaapi_get_sfc_buffer(AVHWFramesContext *hwfc, AVFrame
> +*frame) {
> +AVVAAPIFramesContext *avfc = hwfc->hwctx;
> +AVFrameSideData *frame_sfc_sd = av_frame_get_side_data(frame,
> +
> AV_FRAME_DATA_SFC_INFO);
> +if (frame_sfc_sd) {
> +AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
> +VASurfaceID sfc_surface_id;
> +VASurfaceAttrib attrib;
> +unsigned int rt_format;
> +AVBufferRef *ref;
> +VAStatus vas;
> +
> +memset(&attrib, 0, sizeof(attrib));
> +attrib.type = VASurfaceAttribPixelFormat;
> +attrib.flags = VA_SURFACE_ATTRIB_SETTABLE;
> +attrib.value.type = VAGenericValueTypeInteger;
> +
> +switch (avfc->sfc_format) {
> +case AV_PIX_FMT_NV12:
> +attrib.value.value.i = VA_FOURCC_NV12;
> +rt_format = VA_RT_FORMAT_YUV420;
> +break;
> +case AV_PIX_FMT_ARGB:
> +attrib.value.value.i = VA_FOURCC_ARGB;
> +rt_format = VA_RT_FORMAT_RGB32;
> +break;
> +default:
> +av_log(hwfc, AV_LOG_ERROR, "Unknown sfc format: %d\n", avfc-
> >sfc_format);
> +return AVERROR(EINVAL);
> +}
> +
> +vas = vaCreateSurfaces(hwctx->display, rt_format,
> + avfc->sfc_width, avfc->sfc_height,
> + &sfc_surface_id, 1,
> + &attrib, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(hwfc, AV_LOG_ERROR, "Failed to create sfc surface: "
> + "%d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR(EIO);
> +}
> +
> +av_log(hwfc, AV_LOG_DEBUG, "Created sfc surface %#x. sfc_format(%d),
> w(%d), h(%d)\n",
> + sfc_surface_id, avfc->sfc_format, avfc->sfc_width,
> + avfc->sfc_height);
> +
> +ref = av_buffer_create((uint8_t*)(uintptr_t)sfc_surface_id,
> + sizeof(sfc_surface_id), &vaapi_buffer_free,
> + hwfc, AV_BUFFER_FLAG_READONLY);
> +if (!ref) {
> +vaDestroySurfaces(hwctx->display, &sfc_surface_id, 1);
> +return AVERROR(EIO);
> +}
> +
> +frame_sfc_sd->buf = ref;
> +
> +av
Re: [FFmpeg-devel] [PATCH v1 1/3] fftools: Add thumbnail output to vaapi_h264 decoder
> -Original Message-
> From: Zhou, Zachary
> Sent: Monday, April 8, 2019 3:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhou, Zachary
> Subject: [PATCH v1 1/3] fftools: Add thumbnail output to vaapi_h264 decoder
>
> This is sample code for reference
>
> HW support for decode+scaling in a single HW command (VDBOX+SFC).
> The primary target usage is video analytics, but can be used playback,
> transcoding, etc.
>
> For VAAPI -
> https://github.com/intel/libva
> basically, it allows multiple outputs (in different resolutions) using the
> decode
> context in a single call (you can search for “additional_outputs” in va.h).
>
> VAAPI sample code -
> https://github.com/intel/libva-
> utils/commit/957a269f02b00760b7e807643c821ee26abc529b
> ---
> fftools/ffmpeg_opt.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c index
> 53d688b764..bfb0f882b5 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -111,6 +111,10 @@ int filter_nbthreads = 0; int
> filter_complex_nbthreads = 0; int vstats_version = 2;
>
> +int sfc_flags = 0;
> +int sfc_width = 0;
> +int sfc_height = 0;
> +char *sfc_format;
>
> static int intra_only = 0;
> static int file_overwrite = 0;
> @@ -1100,6 +1104,13 @@ static int open_input_file(OptionsContext *o,
> const char *filename)
> av_dict_set(&o->g->format_opts, "scan_all_pmts", "1",
> AV_DICT_DONT_OVERWRITE);
> scan_all_pmts_set = 1;
> }
> +
> +//sfc opt
> +av_dict_set_int(&o->g->codec_opts, "sfc_flags", sfc_flags,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_set_int(&o->g->codec_opts, "sfc_width", sfc_width,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_set_int(&o->g->codec_opts, "sfc_height", sfc_height,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_set(&o->g->codec_opts, "sfc_format", sfc_format,
> + AV_DICT_DONT_OVERWRITE);
> +
> /* open the input file with generic avformat function */
> err = avformat_open_input(&ic, filename, file_iformat, &o->g-
> >format_opts);
> if (err < 0) {
> @@ -2898,6 +2909,13 @@ static int opt_vstats_file(void *optctx, const char
> *opt, const char *arg)
> return 0;
> }
>
> +static int opt_sfc_format(void *optctx, const char *opt, const char
> +*arg) {
> +av_free (sfc_format);
> +sfc_format = av_strdup (arg);
> +return 0;
> +}
> +
> static int opt_vstats(void *optctx, const char *opt, const char *arg) {
> char filename[40];
> @@ -3746,5 +3764,15 @@ const OptionDef options[] = {
> { "filter_hw_device", HAS_ARG | OPT_EXPERT, { .func_arg =
> opt_filter_hw_device },
> "set hardware device used when filtering", "device" },
>
> +//sfc opt
> +{ "sfc_flags",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT,
> { &sfc_flags },
> + "set sfc flags", "sfc" },
> +{ "sfc_width",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT,
> { &sfc_width },
> + "set sfc width", "sfc" },
> +{ "sfc_height", OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT,
> { &sfc_height },
> + "set sfc height", "sfc" },
> +{ "sfc_format", OPT_VIDEO | HAS_ARG | OPT_EXPERT , { .func_arg =
> opt_sfc_format },
> +"set sfc format", "sfc" },
> +
> { NULL, },
> };
Please ignore this patch, new version will be send out soon.
Sorry for inconvenience.
> --
> 2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavf/matroskaenc: Fix memory leak after write trailer
On Mon, Apr 8, 2019 at 9:09 AM myp...@gmail.com wrote:
>
>
>
> On Fri, Apr 5, 2019 at 12:38 AM Andreas Rheinhardt via ffmpeg-devel
> wrote:
> >
> > Jun Zhao:
> > > From: Jun Zhao
> > >
> > > Fix memory leak after write trailer for #7827, only store a audio
> > > packet whose buffer has size greater than zero in cur_audio_pkt.
> > >
> > > Thanks to Andreas Rheinhardt for the suggestions.
> > >
> > > Signed-off-by: Jun Zhao
> > > ---
> > > libavformat/matroskaenc.c |3 ++-
> > > 1 files changed, 2 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > > index b9f99c4..06f3aeb 100644
> > > --- a/libavformat/matroskaenc.c
> > > +++ b/libavformat/matroskaenc.c
> > > @@ -2534,7 +2534,8 @@ static int mkv_write_packet(AVFormatContext *s,
> > > AVPacket *pkt)
> > > // buffer an audio packet to ensure the packet containing the video
> > > // keyframe's timecode is contained in the same cluster for WebM
> > > if (codec_type == AVMEDIA_TYPE_AUDIO) {
> > > -ret = av_packet_ref(&mkv->cur_audio_pkt, pkt);
> > > +if (pkt->size > 0)
> > > +ret = av_packet_ref(&mkv->cur_audio_pkt, pkt);
> > > } else
> > > ret = mkv_write_packet_internal(s, pkt, 0);
> > > return ret;
> > >
> > Seems that I took quite a lot of time to write my commit message. I
> > don't care which patch gets committed, but I presume you did run
> > valgrind to make sure that it actually fixes #7827?
> >
> > - Andreas
> Yes, I've run the valgrind for muxing with FLAC and other audio codec for
> this issue.
Will close the https://trac.ffmpeg.org/ticket/7827, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1 3/3] libavutil: Add thumbnail output to vaapi_h264 decoder
This is sample code for reference
HW support for decode+scaling in a single HW command (VDBOX+SFC).
The primary target usage is video analytics, but can be used playback,
transcoding, etc.
For VAAPI -
https://github.com/intel/libva
basically, it allows multiple outputs (in different resolutions) using the
decode context in a single call (you can search for “additional_outputs” in
va.h).
VAAPI sample code -
https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
---
libavutil/frame.c | 1 +
libavutil/frame.h | 13 +++
libavutil/hwcontext_vaapi.c | 73 -
libavutil/hwcontext_vaapi.h | 6 +++
4 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index dcf1fc3d17..aa9cd744ae 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -842,6 +842,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type)
#endif
case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
SMPTE2094-40 (HDR10+)";
case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
+case AV_FRAME_DATA_SFC_INFO: return "SFC Information";
}
return NULL;
}
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 8aa3e88367..616e7d9d4e 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -179,6 +179,11 @@ enum AVFrameSideDataType {
* array element is implied by AVFrameSideData.size /
AVRegionOfInterest.self_size.
*/
AV_FRAME_DATA_REGIONS_OF_INTEREST,
+
+/**
+ * VDENC SFC information.
+ */
+AV_FRAME_DATA_SFC_INFO,
};
enum AVActiveFormatDescription {
@@ -235,6 +240,14 @@ typedef struct AVRegionOfInterest {
AVRational qoffset;
} AVRegionOfInterest;
+/**
+ * Structure to hold Information of SFC.
+ *
+ */
+typedef struct AVSFCInfo {
+uint8_t *data;
+} AVSFCInfo;
+
/**
* This structure describes decoded (raw) audio or video data.
*
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 8624369bb9..caa6d02b15 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -642,8 +642,74 @@ static void vaapi_frames_uninit(AVHWFramesContext *hwfc)
av_freep(&ctx->attributes);
}
+static int vaapi_get_sfc_buffer(AVHWFramesContext *hwfc, AVFrame *frame)
+{
+AVVAAPIFramesContext *avfc = hwfc->hwctx;
+AVFrameSideData *frame_sfc_sd = av_frame_get_side_data(frame,
+
AV_FRAME_DATA_SFC_INFO);
+if (frame_sfc_sd) {
+AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
+VASurfaceID sfc_surface_id;
+VASurfaceAttrib attrib;
+unsigned int rt_format;
+AVBufferRef *ref;
+VAStatus vas;
+
+memset(&attrib, 0, sizeof(attrib));
+attrib.type = VASurfaceAttribPixelFormat;
+attrib.flags = VA_SURFACE_ATTRIB_SETTABLE;
+attrib.value.type = VAGenericValueTypeInteger;
+
+switch (avfc->sfc_format) {
+case AV_PIX_FMT_NV12:
+attrib.value.value.i = VA_FOURCC_NV12;
+rt_format = VA_RT_FORMAT_YUV420;
+break;
+case AV_PIX_FMT_ARGB:
+attrib.value.value.i = VA_FOURCC_ARGB;
+rt_format = VA_RT_FORMAT_RGB32;
+break;
+default:
+av_log(hwfc, AV_LOG_ERROR, "Unknown sfc format: %d\n",
avfc->sfc_format);
+return AVERROR(EINVAL);
+}
+
+vas = vaCreateSurfaces(hwctx->display, rt_format,
+ avfc->sfc_width, avfc->sfc_height,
+ &sfc_surface_id, 1,
+ &attrib, 1);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(hwfc, AV_LOG_ERROR, "Failed to create sfc surface: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR(EIO);
+}
+
+av_log(hwfc, AV_LOG_DEBUG, "Created sfc surface %#x. sfc_format(%d),
w(%d), h(%d)\n",
+ sfc_surface_id, avfc->sfc_format, avfc->sfc_width,
avfc->sfc_height);
+
+ref = av_buffer_create((uint8_t*)(uintptr_t)sfc_surface_id,
+ sizeof(sfc_surface_id), &vaapi_buffer_free,
+ hwfc, AV_BUFFER_FLAG_READONLY);
+if (!ref) {
+vaDestroySurfaces(hwctx->display, &sfc_surface_id, 1);
+return AVERROR(EIO);
+}
+
+frame_sfc_sd->buf = ref;
+
+av_log(hwfc, AV_LOG_DEBUG, "Created sfc av buffer ref: %p\n", ref);
+
+} else {
+av_log(hwfc, AV_LOG_DEBUG, "VDSFC frame_sfc_sd is null\n");
+}
+
+return 0;
+}
+
static int vaapi_get_buffer(AVHWFramesContext *hwfc, AVFrame *frame)
{
+int err;
+
frame->buf[0] = av_buffer_pool_get(hwfc->pool);
if (!frame->buf[0])
return AVERROR(ENOMEM);
@@ -653,6 +719,11 @@ static int vaapi_get_buffer(AVHWFramesContext *hwfc,
AVFrame *frame)
frame->width = hwfc-
[FFmpeg-devel] [PATCH v1 2/3] libavcodec: Add thumbnail output to vaapi_h264 decoder
This is sample code for reference
HW support for decode+scaling in a single HW command (VDBOX+SFC).
The primary target usage is video analytics, but can be used playback,
transcoding, etc.
For VAAPI -
https://github.com/intel/libva
basically, it allows multiple outputs (in different resolutions) using the
decode context in a single call (you can search for “additional_outputs” in
va.h).
VAAPI sample code -
https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
---
libavcodec/avcodec.h | 8 +++
libavcodec/decode.c| 16 +
libavcodec/options_table.h | 4 ++
libavcodec/vaapi_decode.c | 122 ++---
libavcodec/vaapi_decode.h | 30 +
libavcodec/vaapi_h264.c| 13
6 files changed, 185 insertions(+), 8 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0ce22ec4fa..86ab18011c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3357,6 +3357,14 @@ typedef struct AVCodecContext {
* - encoding: unused
*/
int discard_damaged_percentage;
+
+/*
+ * VDSFC options
+ */
+int sfc_flags;
+int sfc_format;
+int sfc_width;
+int sfc_height;
} AVCodecContext;
#if FF_API_CODEC_GET_SET
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a32ff2fcd3..df5f5b6eed 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1795,6 +1795,22 @@ FF_ENABLE_DEPRECATION_WARNINGS
frame->channels = avctx->channels;
break;
}
+
+//sfc side data
+if (avctx->sfc_flags) {
+AVFrameSideData *frame_sfc_sd = av_frame_new_side_data(frame,
+
AV_FRAME_DATA_SFC_INFO,
+
sizeof(AVSFCInfo));
+if (frame_sfc_sd) {
+av_dict_set_int(&frame_sfc_sd->metadata, "sfc_flags",
avctx->sfc_flags, 0);
+av_dict_set_int(&frame_sfc_sd->metadata, "sfc_width",
avctx->sfc_width, 0);
+av_dict_set_int(&frame_sfc_sd->metadata, "sfc_height",
avctx->sfc_height, 0);
+av_dict_set_int(&frame_sfc_sd->metadata, "sfc_format",
avctx->sfc_format, 0);
+
+av_log(avctx, AV_LOG_DEBUG, "VDSFC new side data\n");
+}
+}
+
return 0;
}
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index a3235bcd57..c14ff08678 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -480,6 +480,10 @@ static const AVOption avcodec_options[] = {
{"allow_profile_mismatch", "attempt to decode anyway if HW accelerated
decoder's supported profiles do not exactly match the stream", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN,
INT_MAX, V | D, "hwaccel_flags"},
{"extra_hw_frames", "Number of extra hardware frames to allocate for the
user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
V|D },
{"discard_damaged_percentage", "Percentage of damaged samples to discard a
frame", OFFSET(discard_damaged_percentage), AV_OPT_TYPE_INT, {.i64 = 95 }, 0,
100, V|D },
+{"sfc_flags", "set sfc flags", OFFSET(sfc_flags), AV_OPT_TYPE_INT, { .i64 = 1
}, 0, 1, V|D, "sfc"},
+{"sfc_format", "set sfc format", OFFSET(sfc_format), AV_OPT_TYPE_PIXEL_FMT,
{.i64=AV_PIX_FMT_ARGB}, -1, INT_MAX, V|D, "sfc"},
+{"sfc_width", "set sfc width", OFFSET(sfc_width), AV_OPT_TYPE_INT, {.i64 =
480}, 0, INT_MAX, V|D, "sfc"},
+{"sfc_height", "set sfc height", OFFSET(sfc_height), AV_OPT_TYPE_INT, {.i64 =
360}, 0, INT_MAX, V|D, "sfc"},
{NULL},
};
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 69512e1d45..2917ee951e 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -145,6 +145,17 @@ static void ff_vaapi_decode_destroy_buffers(AVCodecContext
*avctx,
pic->slice_buffers[i], vas, vaErrorStr(vas));
}
}
+
+//destory sfc buffer
+if (avctx->sfc_flags) {
+vas = vaDestroyBuffer(ctx->hwctx->display,
+ pic->sfc_buffer);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to destroy sfc "
+ "buffer %#x: %d (%s).\n",
+ pic->sfc_buffer, vas, vaErrorStr(vas));
+}
+}
}
int ff_vaapi_decode_issue(AVCodecContext *avctx,
@@ -184,6 +195,56 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
goto fail_with_picture;
}
+//add sfc buffer
+if (avctx->sfc_flags) {
+VARectangle rect_src; /**< @brief Rectangle for source
input */
+VARectangle rect_sfc; /**< @brief Rectangle for SFC output
*/
+VAProcPipelineParameterBuffer buffer;
+
+memset(&rect_src, 0, sizeof(rect_src));
+memset(&rect_sfc, 0, sizeof(rect_sfc));
+memset(&buffer, 0, sizeof(buffer));
+
+rect_src.x = rect_src.y = 0;
+rect_src.width = (uint16_t)
[FFmpeg-devel] [PATCH v1 1/3] fftools: Add thumbnail output to vaapi_h264 decoder
This is sample code for reference
HW support for decode+scaling in a single HW command (VDBOX+SFC).
The primary target usage is video analytics, but can be used playback,
transcoding, etc.
For VAAPI -
https://github.com/intel/libva
basically, it allows multiple outputs (in different resolutions) using the
decode context in a single call (you can search for “additional_outputs” in
va.h).
VAAPI sample code -
https://github.com/intel/libva-utils/commit/957a269f02b00760b7e807643c821ee26abc529b
---
fftools/ffmpeg_opt.c | 28
1 file changed, 28 insertions(+)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 53d688b764..bfb0f882b5 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -111,6 +111,10 @@ int filter_nbthreads = 0;
int filter_complex_nbthreads = 0;
int vstats_version = 2;
+int sfc_flags = 0;
+int sfc_width = 0;
+int sfc_height = 0;
+char *sfc_format;
static int intra_only = 0;
static int file_overwrite = 0;
@@ -1100,6 +1104,13 @@ static int open_input_file(OptionsContext *o, const char
*filename)
av_dict_set(&o->g->format_opts, "scan_all_pmts", "1",
AV_DICT_DONT_OVERWRITE);
scan_all_pmts_set = 1;
}
+
+//sfc opt
+av_dict_set_int(&o->g->codec_opts, "sfc_flags", sfc_flags,
AV_DICT_DONT_OVERWRITE);
+av_dict_set_int(&o->g->codec_opts, "sfc_width", sfc_width,
AV_DICT_DONT_OVERWRITE);
+av_dict_set_int(&o->g->codec_opts, "sfc_height", sfc_height,
AV_DICT_DONT_OVERWRITE);
+av_dict_set(&o->g->codec_opts, "sfc_format", sfc_format,
AV_DICT_DONT_OVERWRITE);
+
/* open the input file with generic avformat function */
err = avformat_open_input(&ic, filename, file_iformat, &o->g->format_opts);
if (err < 0) {
@@ -2898,6 +2909,13 @@ static int opt_vstats_file(void *optctx, const char
*opt, const char *arg)
return 0;
}
+static int opt_sfc_format(void *optctx, const char *opt, const char *arg)
+{
+av_free (sfc_format);
+sfc_format = av_strdup (arg);
+return 0;
+}
+
static int opt_vstats(void *optctx, const char *opt, const char *arg)
{
char filename[40];
@@ -3746,5 +3764,15 @@ const OptionDef options[] = {
{ "filter_hw_device", HAS_ARG | OPT_EXPERT, { .func_arg =
opt_filter_hw_device },
"set hardware device used when filtering", "device" },
+//sfc opt
+{ "sfc_flags",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, { &sfc_flags
},
+ "set sfc flags", "sfc" },
+{ "sfc_width",OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, { &sfc_width
},
+ "set sfc width", "sfc" },
+{ "sfc_height", OPT_VIDEO | HAS_ARG | OPT_INT | OPT_INPUT, { &sfc_height
},
+ "set sfc height", "sfc" },
+{ "sfc_format", OPT_VIDEO | HAS_ARG | OPT_EXPERT , { .func_arg =
opt_sfc_format },
+"set sfc format", "sfc" },
+
{ NULL, },
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
