Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb_bsf: add No IDR frame situation
On Wed, Aug 15, 2018 at 2:38 PM Linjie Fu wrote:
>
> Fix the live stream encoding problem using qsv when the first frame
> is not an IDR frame.
>
> Add the extradata information when the IDR frame is missing in the
> first GOP.
>
> Fixes the bug reported in ticket #6418.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/h264_mp4toannexb_bsf.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c
> b/libavcodec/h264_mp4toannexb_bsf.c
> index 794c82e650..fbbfe3f7dd 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -33,6 +33,7 @@ typedef struct H264BSFContext {
> int32_t pps_offset;
> uint8_t length_size;
> uint8_t new_idr;
> + uint8_t new_nal_slice;
> uint8_t idr_sps_seen;
> uint8_t idr_pps_seen;
> int extradata_parsed;
> @@ -243,6 +244,7 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> buf, nal_size, 1)) < 0)
> goto fail;
> s->new_idr = 0;
> + s->new_nal_slice = 1;
> /* if only SPS has been seen, also insert PPS */
> } else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
> s->idr_sps_seen && !s->idr_pps_seen) {
> if (s->pps_offset == -1) {
> @@ -253,7 +255,16 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *out)
> ctx->par_out->extradata +
> s->pps_offset, ctx->par_out->extradata_size - s->pps_offset,
> buf, nal_size, 1)) < 0)
> goto fail;
> -} else {
> +}else if (s->new_idr && !s->new_nal_slice && H264_NAL_SLICE ==
> unit_type && !s->idr_sps_seen && !s->idr_pps_seen)
> + {
> + av_log(ctx, AV_LOG_WARNING, "first H264_NAL_SLICE
> when there is no IDR.\n");
> + if ((ret = alloc_and_copy(out,
> ctx->par_out->extradata, ctx->par_out->extradata_size, buf, nal_size, 1)) < 0)
> + goto fail;
> + s->new_nal_slice = 1;
> + s->new_idr = 0;
> + }
> +
> + else {
> if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size, unit_type
> == H264_NAL_SPS || unit_type == H264_NAL_PPS)) < 0)
> goto fail;
> if (!s->new_idr && unit_type == H264_NAL_SLICE) {
> --
Need to follow FFmpeg coding style, I think, more information, you can
refer to the link: https://www.ffmpeg.org/developer.html. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavc/mpeg4videodec: fix can't dump AVOptions issue.
On Tue, Aug 14, 2018 at 11:39 PM Michael Niedermayer
wrote:
>
> On Mon, Aug 13, 2018 at 09:51:47PM +0800, Jun Zhao wrote:
> > fix can't dump the mpeg4videodec option with the command
> > "ffmpeg -h decoder=mpeg4".
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/mpeg4videodec.c |5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
> > index 24c280d..549b7a5 100644
> > --- a/libavcodec/mpeg4videodec.c
> > +++ b/libavcodec/mpeg4videodec.c
> > @@ -3435,9 +3435,10 @@ static av_cold int decode_end(AVCodecContext
*avctx)
> > return ff_h263_decode_end(avctx, just );
> > }
> >
> > +#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> > static const AVOption mpeg4_options[] = {
> > -{"quarter_sample", "1/4 subpel MC", offsetof(MpegEncContext,
quarter_sample), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, 0},
> > -{"divx_packed", "divx style packed b frames",
offsetof(MpegEncContext, divx_packed), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
0},
> > +{"quarter_sample", "1/4 subpel MC", offsetof(MpegEncContext,
quarter_sample), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VD},
> > +{"divx_packed", "divx style packed b frames",
offsetof(MpegEncContext, divx_packed), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
VD},
> > {NULL}
>
> These are not options for the user to set, they are not supposed to be
> in the "ffmpeg -h decoder=mpeg4" listing
>
>
What's the reason
to
use the mpeg4_option for quarter_sample/divx_packed, just want to
initialize them?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/3] enable multi-slices in vaapi_h264/265 encoder
On Mon, Jul 30, 2018 at 7:49 PM Jun Zhao wrote: > > V6: - Use rectangular slices and refine the code. > > V5: - In h265_vaapi encoder, when setting slice number > max slice number > supported by driver, report error and return. Same as h264_vaapi. > - Clean the logic when setting first_slice_segment_in_pic_flags. > > V4: - Change the array malloc function. > - Clean the pointless condition check when free the memory. > > V3: - Making pic->slices be VAAPIEncodeSlice* instead of VAAPIEncodeSlice**. > - Fix resource (vaBuffer) lead when realloc pic->param_buffers fail. > - Adjust max_slices location in VAAPIEncodeContext. > - Re-work distributing the macro-blocks for multi-slices function. > > V2: - Change the slice/parameter buffers to dynamic alloc and split the > mutil-slice support for AVC/HEVC. > > Jun Zhao (3): > lavc/vaapi_encode: Add max slices number query. > lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder > lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder > > libavcodec/vaapi_encode.c |4 > libavcodec/vaapi_encode.h |4 > libavcodec/vaapi_encode_h264.c | 31 +-- > libavcodec/vaapi_encode_h265.c | 30 -- > 4 files changed, 57 insertions(+), 12 deletions(-) > Ping, some guys can you help to review the patches? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/hevcdec: add ONLY_IF_THREADS_ENABLED where it is missing.
On Fri, Aug 10, 2018 at 3:06 AM James Almer wrote:
>
> On 8/9/2018 4:06 AM, Jun Zhao wrote:
> > add add ONLY_IF_THREADS_ENABLED where it is missing.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/hevcdec.c |8 ++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 409e77f..a3b5c8c 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -3358,6 +3358,7 @@ fail:
> > return AVERROR(ENOMEM);
> > }
> >
> > +#if HAVE_THREADS
> > static int hevc_update_thread_context(AVCodecContext *dst,
> >const AVCodecContext *src)
> > {
> > @@ -3439,6 +3440,7 @@ static int hevc_update_thread_context(AVCodecContext
> > *dst,
> >
> > return 0;
> > }
> > +#endif
> >
> > static av_cold int hevc_decode_init(AVCodecContext *avctx)
> > {
> > @@ -3478,6 +3480,7 @@ static av_cold int hevc_decode_init(AVCodecContext
> > *avctx)
> > return 0;
> > }
> >
> > +#if HAVE_THREADS
> > static av_cold int hevc_init_thread_copy(AVCodecContext *avctx)
> > {
> > HEVCContext *s = avctx->priv_data;
> > @@ -3491,6 +3494,7 @@ static av_cold int
> > hevc_init_thread_copy(AVCodecContext *avctx)
> >
> > return 0;
> > }
> > +#endif
> >
> > static void hevc_decode_flush(AVCodecContext *avctx)
> > {
> > @@ -3529,8 +3533,8 @@ AVCodec ff_hevc_decoder = {
> > .close = hevc_decode_free,
> > .decode= hevc_decode_frame,
> > .flush = hevc_decode_flush,
> > -.update_thread_context = hevc_update_thread_context,
> > -.init_thread_copy = hevc_init_thread_copy,
> > +.update_thread_context =
> > ONLY_IF_THREADS_ENABLED(hevc_update_thread_context),
> > +.init_thread_copy =
> > ONLY_IF_THREADS_ENABLED(hevc_init_thread_copy),
> > .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
> > AV_CODEC_CAP_SLICE_THREADS |
> > AV_CODEC_CAP_FRAME_THREADS,
> > .caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> > FF_CODEC_CAP_EXPORTS_CROPPING,
>
> Should be ok.
>
Will apply with commit message clean (remove the unnecessary "add" in
commit message) , Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/hevcdec: add ONLY_IF_THREADS_ENABLED where it is missing.
On Wed, Aug 8, 2018 at 9:50 PM James Almer wrote:
> On 8/8/2018 7:56 AM, Jun Zhao wrote:
> > add add ONLY_IF_THREADS_ENABLED where it is missing.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/hevcdec.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 409e77f..fec9218 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -3529,8 +3529,8 @@ AVCodec ff_hevc_decoder = {
> > .close = hevc_decode_free,
> > .decode= hevc_decode_frame,
> > .flush = hevc_decode_flush,
> > -.update_thread_context = hevc_update_thread_context,
> > -.init_thread_copy = hevc_init_thread_copy,
> > +.update_thread_context =
> ONLY_IF_THREADS_ENABLED(hevc_update_thread_context),
> > +.init_thread_copy =
> ONLY_IF_THREADS_ENABLED(hevc_init_thread_copy),
> > .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
> > AV_CODEC_CAP_SLICE_THREADS |
> AV_CODEC_CAP_FRAME_THREADS,
> > .caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_EXPORTS_CROPPING,
>
> You should also wrap the two functions in question with HAVE_THREADS
> checks.
>
> Will update the patch as the comment, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb_bsf: use enum constants for the NAL unit type values
On Mon, Jul 30, 2018 at 5:22 AM James Almer wrote:
>
> Signed-off-by: James Almer
> ---
> libavcodec/h264_mp4toannexb_bsf.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
> index 292d106433..794c82e650 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -26,6 +26,7 @@
>
> #include "avcodec.h"
> #include "bsf.h"
> +#include "h264.h"
>
> typedef struct H264BSFContext {
> int32_t sps_offset;
> @@ -209,9 +210,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
> if (nal_size > buf_end - buf || nal_size < 0)
> goto fail;
>
> -if (unit_type == 7)
> +if (unit_type == H264_NAL_SPS)
> s->idr_sps_seen = s->new_idr = 1;
> -else if (unit_type == 8) {
> +else if (unit_type == H264_NAL_PPS) {
> s->idr_pps_seen = s->new_idr = 1;
> /* if SPS has not been seen yet, prepend the AVCC one to PPS
*/
> if (!s->idr_sps_seen) {
> @@ -232,18 +233,18 @@ static int h264_mp4toannexb_filter(AVBSFContext
*ctx, AVPacket *out)
> /* if this is a new IDR picture following an IDR picture, reset
the idr flag.
> * Just check first_mb_in_slice to be 0 as this is the simplest
solution.
> * This could be checking idr_pic_id instead, but would
complexify the parsing. */
> -if (!s->new_idr && unit_type == 5 && (buf[1] & 0x80))
> +if (!s->new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] &
0x80))
> s->new_idr = 1;
>
> /* prepend only to the first type 5 NAL unit of an IDR picture,
if no sps/pps are already present */
> -if (s->new_idr && unit_type == 5 && !s->idr_sps_seen &&
!s->idr_pps_seen) {
> +if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
!s->idr_sps_seen && !s->idr_pps_seen) {
> if ((ret=alloc_and_copy(out,
> ctx->par_out->extradata,
ctx->par_out->extradata_size,
> buf, nal_size, 1)) < 0)
> goto fail;
> s->new_idr = 0;
> /* if only SPS has been seen, also insert PPS */
> -} else if (s->new_idr && unit_type == 5 && s->idr_sps_seen &&
!s->idr_pps_seen) {
> +} else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
s->idr_sps_seen && !s->idr_pps_seen) {
> if (s->pps_offset == -1) {
> av_log(ctx, AV_LOG_WARNING, "PPS not present in the
stream, nor in AVCC, stream may be unreadable\n");
> if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size,
0)) < 0)
> @@ -253,9 +254,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
> buf, nal_size, 1)) < 0)
> goto fail;
> } else {
> -if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size,
unit_type == 7 || unit_type == 8)) < 0)
> +if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size,
unit_type == H264_NAL_SPS || unit_type == H264_NAL_PPS)) < 0)
> goto fail;
> -if (!s->new_idr && unit_type == 1) {
> +if (!s->new_idr && unit_type == H264_NAL_SLICE) {
> s->new_idr = 1;
> s->idr_sps_seen = 0;
> s->idr_pps_seen = 0;
> --
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.
On Mon, Jul 23, 2018 at 2:33 AM Marton Balint wrote: > > > > On Tue, 17 Jul 2018, myp...@gmail.com wrote: > > > On Sun, Jul 15, 2018 at 1:03 AM Michael Niedermayer > > wrote: > >> > >> On Sat, Jul > >> 14, 2018 at 12:04:46PM +0200, Marton Balint wrote: > >> > > >> > > >> > On Sat, 14 Jul 2018, Michael Niedermayer wrote: > >> > > >> > >On Fri, Jul 13, 2018 at 10:51:00AM +0200, Marton Balint wrote: > >> > >> > >> > >> > >> > >>On Thu, 12 Jul 2018, myp...@gmail.com wrote: > >> > >> > >> > >>>On Thu, Jul 12, 2018 at 12:43 AM Marton Balint wrote: > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>>On Wed, 11 Jul 2018, Jun Zhao wrote: > >> > >>>> > >> > >>>>>use pixelutils API for sad in motion estimation. > >> > >>>> > >> > >>>>Does it make sense to improve this code? I thought a superior and > >> > >>>>faster > >> > >>>>approach was a result of 2017 GSOC task: > >> > >>>> > >> > >>>>https://docs.google.com/document/d/1Hyh_rxP1KGsVkg7i7yU8Bcv92z0LIL4r-axpoKfvMFk/edit > >> > >>>> > >> > >>>>Maybe that code should be merged back, and any further optimalization > >> > >>>>should be done based on that code, no? > >> > >>>> > >> > >>>>Thanks, > >> > >>>>Marton > >> > >>>> > >> > >>>Hi, Marton: > >> > >>> > >> > >>>Yes, now I try to improve the > >> minterpolate, and after use perf > >> > >>>profiing the commands: > >> > >>> > >> > >> > >>>./ffmpeg -i a.ts -filter_complex > >> > >>>"minterpolate=mi_mode=mci:mc_mode=aobmc:vsbmc=1" -f null /dev/null > >> > >>>I found the hotspot is: > >> > >>>- get_sbad_ob > >> > >>>- get_sbad > >> > >>>- get_sad_ob > >> > >>>- bilateral_obmc > >> > >>>- set_frame_data > >> > >>> > >> > >>>So, as my plan, I will try to use sse2/avx2 > >> > >>>Scatter/Gather, optimized > >> > >>>sad function (use pixelutils API) > >> > >>>in get_sbad_ob / get_sbad / get_sad_ob first, for set_frame_data > >> > >>>case, maybe need to use Scatter/Gather SIMD instruction. > >> > >> > >> > >>That is great, all I am saying we should avoid diverging the two > >> > >>brances > >> > >>(FFmpeg branch, and GSOC 2017 branch), and try to merge back GSOC2017 > >> > >>if it > >> > >>can be done with reasonable amount of work before optimizing code, > >> > >>otherwise > >> > >>the GSOC2017 branch will rot and we will lose the result of the GSOC > >> > >>task. > >> > >> > >> > >>> > >> > >>>But if some guys have done some improve task in this case, I think > >> > >>>based on the pre-existing work is the better way. > >> > >> > >> > >>Michael was the mentor, maybe he can chip in on what should be done > >> > >>here. > >> > > > >> > >talk with the author/student who wrote the code, not me :) > >> > > >> > Well, his not active here, > >> > >> yes but last i heared from him, he was interrested in continuing this > >> project > >> i think ive not heared much from him after that but i now see that there > >> is a > >> small commit in his repo from 2018 so he is not completely inactive. > >> I think you should talk with him > >> > >> > >> > and the question is if his work is ready for > >> > mainline inclusion or not, and if he has done enough valuable work during > >> > GSOC that its worth working on mainlining it. > >> > >> He certainly did valuable work. Looking now at the ML, it seems the more or > >> less last thing on the ML was the RFC/Discussion thread about libmotion. > >> In that everyone wanted to dictate the design, and all that was > >> contradicting > >> each other. > >> If you want to work on unifying this entangled bikeshed ball of conflicting > >> oppinions, that surely is very welcome. Important is that it ends in > >> something > >> that is practical and high quality. > >> Personally i think the author should be given more authority in the design. > >> But again, please talk with the author of this code > >> I dont remember everything in as much detail about this ... > >> > >> also ive added him to the CC > >> > >> Thanks > >> > >> > > Now the minterpolate/libmotion auther didn't give a feedback or > > sugesstion, so I will update patch 1/2 (just add SSE2/AVX2 sad_32x32) > > with some perf data and hold on the patch 3 about minterpolate, any > > other comments? > > I checked the "libmotion" series, and it seems they are in > debug/development state and the commits are not clean, so some heavy > refactoring is needed before applying them anyway. > > Do what you prefer, snow codec based motion compenstaion is an additional > algorithm to the existing code anyway as far as I see. > As my point, I prefer improve current minterpolate filter first, then we can try to refactor the "libmotion" series, Done Is Better Than Perfect, any other comments or suggestion? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/formats: Add documentation for skip_estimate_duration_from_pts
On Wed, Jul 25, 2018 at 6:50 AM Michael Niedermayer
wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/formats.texi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/formats.texi b/doc/formats.texi
> index a97d61063a..738a4bb6e2 100644
> --- a/doc/formats.texi
> +++ b/doc/formats.texi
> @@ -220,6 +220,9 @@ ffprobe -dump_separator "
> @item max_streams @var{integer} (@emph{input})
> Specifies the maximum number of streams. This can be used to reject files
> that
> would require too many resources due to a large number of streams.
> +
> +@item skip_estimate_duration_from_pts @var{bool} (@emph{input})
> +skip duration calculation from pts.
> @end table
>
> @c man end FORMAT OPTIONS
> --
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/2] add sad 32x32 with sse2/avx2 optimizations.
On Tue, Jul 17, 2018 at 7:25 PM Jun Zhao wrote: > > V2: - update performance data > - hold on minterpolate filter improvement (need to more talk for > minterpolate improvement) > > Jun Zhao (2): > lavutil/pixelutils: add sad_32x32 in pixelutils API. > avutil/pixelutils: sad_32x32 sse2/avx2 optimizations. > > libavutil/pixelutils.c |2 + > libavutil/tests/pixelutils.c|2 +- > libavutil/x86/pixelutils.asm| 220 > +++ > libavutil/x86/pixelutils_init.c | 30 ++ > tests/ref/fate/pixelutils | 12 ++ > 5 files changed, 265 insertions(+), 1 deletions(-) > Ping? Any comments will be welcome, Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.
On Sun, Jul 15, 2018 at 1:03 AM Michael Niedermayer wrote: > > On Sat, Jul > 14, 2018 at 12:04:46PM +0200, Marton Balint wrote: > > > > > > On Sat, 14 Jul 2018, Michael Niedermayer wrote: > > > > >On Fri, Jul 13, 2018 at 10:51:00AM +0200, Marton Balint wrote: > > >> > > >> > > >>On Thu, 12 Jul 2018, myp...@gmail.com wrote: > > >> > > >>>On Thu, Jul 12, 2018 at 12:43 AM Marton Balint wrote: > > >>>> > > >>>> > > >>>> > > >>>>On Wed, 11 Jul 2018, Jun Zhao wrote: > > >>>> > > >>>>>use pixelutils API for sad in motion estimation. > > >>>> > > >>>>Does it make sense to improve this code? I thought a superior and faster > > >>>>approach was a result of 2017 GSOC task: > > >>>> > > >>>>https://docs.google.com/document/d/1Hyh_rxP1KGsVkg7i7yU8Bcv92z0LIL4r-axpoKfvMFk/edit > > >>>> > > >>>>Maybe that code should be merged back, and any further optimalization > > >>>>should be done based on that code, no? > > >>>> > > >>>>Thanks, > > >>>>Marton > > >>>> > > >>>Hi, Marton: > > >>> > > >>>Yes, now I try to improve the > minterpolate, and after use perf > > >>>profiing the commands: > > >>> > > > >>>./ffmpeg -i a.ts -filter_complex > > >>>"minterpolate=mi_mode=mci:mc_mode=aobmc:vsbmc=1" -f null /dev/null > > >>>I found the hotspot is: > > >>>- get_sbad_ob > > >>>- get_sbad > > >>>- get_sad_ob > > >>>- bilateral_obmc > > >>>- set_frame_data > > >>> > > >>>So, as my plan, I will try to use sse2/avx2 > > >>>Scatter/Gather, optimized > > >>>sad function (use pixelutils API) > > >>>in get_sbad_ob / get_sbad / get_sad_ob first, for set_frame_data > > >>>case, maybe need to use Scatter/Gather SIMD instruction. > > >> > > >>That is great, all I am saying we should avoid diverging the two brances > > >>(FFmpeg branch, and GSOC 2017 branch), and try to merge back GSOC2017 if > > >>it > > >>can be done with reasonable amount of work before optimizing code, > > >>otherwise > > >>the GSOC2017 branch will rot and we will lose the result of the GSOC task. > > >> > > >>> > > >>>But if some guys have done some improve task in this case, I think > > >>>based on the pre-existing work is the better way. > > >> > > >>Michael was the mentor, maybe he can chip in on what should be done here. > > > > > >talk with the author/student who wrote the code, not me :) > > > > Well, his not active here, > > yes but last i heared from him, he was interrested in continuing this project > i think ive not heared much from him after that but i now see that there is a > small commit in his repo from 2018 so he is not completely inactive. > I think you should talk with him > > > > and the question is if his work is ready for > > mainline inclusion or not, and if he has done enough valuable work during > > GSOC that its worth working on mainlining it. > > He certainly did valuable work. Looking now at the ML, it seems the more or > less last thing on the ML was the RFC/Discussion thread about libmotion. > In that everyone wanted to dictate the design, and all that was contradicting > each other. > If you want to work on unifying this entangled bikeshed ball of conflicting > oppinions, that surely is very welcome. Important is that it ends in something > that is practical and high quality. > Personally i think the author should be given more authority in the design. > But again, please talk with the author of this code > I dont remember everything in as much detail about this ... > > also ive added him to the CC > > Thanks > > Now the minterpolate/libmotion auther didn't give a feedback or sugesstion, so I will update patch 1/2 (just add SSE2/AVX2 sad_32x32) with some perf data and hold on the patch 3 about minterpolate, any other comments? Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2 2/2] lavc/hevc_ps: use skip_bits instead of get_bits when skip bits.
On Fri, Jul 13, 2018 at 6:28 PM Michael Niedermayer
wrote:
>
> On Thu, Jul 12, 2018 at 10:28:44PM +0800, Jun Zhao wrote:
> > use skip_bits when want to skip some bits.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/hevc_ps.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index bc5406b..116d938 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1679,7 +1679,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
AVCodecContext *avctx,
> >
> > if (get_bits1(gb)) { // pps_extension_present_flag
> > int pps_range_extensions_flag = get_bits1(gb);
> > -/* int pps_extension_7bits = */ get_bits(gb, 7);
>
> > +skip_bits(gb, 7); // pps_extension_7bits = get_bits(gb, 7)
>
> Theres no need to keep "= get_bits(gb, 7)" in the comment i think
>
Change the comment and applied, Thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Take away the freedom of one citizen and you will be jailed, take away
> the freedom of all citizens and you will be congratulated by your peers
> in Parliament.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2 1/2] lavc/hevc_ps: Refine sps_range_extension parse.
On Fri, Jul 13, 2018 at 6:34 PM Michael Niedermayer
wrote:
> On Thu, Jul 12, 2018 at 10:28:43PM +0800, Jun Zhao wrote:
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/hevc_ps.c |6 ++
> > 1 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index bca3abb..bc5406b 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1094,11 +1094,9 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
> *gb, unsigned int *sps_id,
> > decode_vui(gb, avctx, apply_defdispwin, sps);
> >
> > if (get_bits1(gb)) { // sps_extension_flag
> > -int sps_extension_flag[1];
> > -for (i = 0; i < 1; i++)
> > -sps_extension_flag[i] = get_bits1(gb);
> > +int sps_range_extension_flag = get_bits1(gb);
> > skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
> > -if (sps_extension_flag[0]) {
> > +if (sps_range_extension_flag) {
> > int extended_precision_processing_flag;
> > int cabac_bypass_alignment_enabled_flag;
>
> should be ok i think
>
Applied, Thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] mistake in patch "Add lensfun filter"
On Thu, Jul 12, 2018 at 12:47 PM Stephen Seo wrote: > > Hi, > > It appears I used the wrong license in libavfilter/vf_lensfun.c > > It derives from the Lensfun library that uses (L)GPL3, but I used GPL2 by > mistake. > > Should I 'git send-email' the whole patch again with this mistake resolved, > or should I email another patch with just the license correction? (I'm a > bit new to submitting code to mailing lists.) I think you can re-submit the version V2 full patch for this, Thanks > > Thanks, > Stephen Seo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.
On Thu, Jul 12, 2018 at 12:43 AM Marton Balint wrote: > > > > On Wed, 11 Jul 2018, Jun Zhao wrote: > > > use pixelutils API for sad in motion estimation. > > Does it make sense to improve this code? I thought a superior and faster > approach was a result of 2017 GSOC task: > > https://docs.google.com/document/d/1Hyh_rxP1KGsVkg7i7yU8Bcv92z0LIL4r-axpoKfvMFk/edit > > Maybe that code should be merged back, and any further optimalization > should be done based on that code, no? > > Thanks, > Marton > Hi, Marton: Yes, now I try to improve the minterpolate, and after use perf profiing the commands: ./ffmpeg -i a.ts -filter_complex "minterpolate=mi_mode=mci:mc_mode=aobmc:vsbmc=1" -f null /dev/null I found the hotspot is: - get_sbad_ob - get_sbad - get_sad_ob - bilateral_obmc - set_frame_data So, as my plan, I will try to use sse2/avx2 Scatter/Gather, optimized sad function (use pixelutils API) in get_sbad_ob / get_sbad / get_sad_ob first, for set_frame_data case, maybe need to use Scatter/Gather SIMD instruction. But if some guys have done some improve task in this case, I think based on the pre-existing work is the better way. BTW: I have tried to use SIMD to improve the blend data path (like a command: ./ffmpeg -i a.ts -filter_complex "minterpolate=mi_mode=blend:scd=fdiff:scd_threshold=1" -f null /dev/null ), after the SIMD improve, the fps increae about 100% (from 30fps to 60fps in 1080P) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/hevc_ps: use skip_bits instead of get_bits when skip bits.
On Mon, Jul 9, 2018 at 8:41 AM James Almer wrote:
>
> On 7/8/2018 9:16 PM, myp...@gmail.com wrote:
> > On Sat, Jul 7, 2018 at 6:32 PM Carl Eugen Hoyos
wrote:
> >>
> >> 2018-07-07 7:48 GMT+02:00, Jun Zhao :
> >>> use skip_bits when want to skip some bits.
> >>>
> >>> Signed-off-by: Jun Zhao
> >>> ---
> >>> libavcodec/hevc_ps.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >>> index bc5406b..278b928 100644
> >>> --- a/libavcodec/hevc_ps.c
> >>> +++ b/libavcodec/hevc_ps.c
> >>> @@ -1679,7 +1679,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> >>> AVCodecContext *avctx,
> >>>
> >>> if (get_bits1(gb)) { // pps_extension_present_flag
> >>> int pps_range_extensions_flag = get_bits1(gb);
> >>> -/* int pps_extension_7bits = */ get_bits(gb, 7);
> >>> +skip_bits(gb, 7);
> >>
> >> This seems to make the code less readable, no?
> >
> > You means keep old style? But I think skip_bits more clear in this
> > case, maybe I need to add some comment?
>
> He probably means leaving the comment about what the skipped field/s is.
I see, will keep the comment about the skipped fields
.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/hevc_ps: use skip_bits instead of get_bits when skip bits.
On Sat, Jul 7, 2018 at 6:32 PM Carl Eugen Hoyos wrote:
>
> 2018-07-07 7:48 GMT+02:00, Jun Zhao :
> > use skip_bits when want to skip some bits.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/hevc_ps.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index bc5406b..278b928 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1679,7 +1679,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> > AVCodecContext *avctx,
> >
> > if (get_bits1(gb)) { // pps_extension_present_flag
> > int pps_range_extensions_flag = get_bits1(gb);
> > -/* int pps_extension_7bits = */ get_bits(gb, 7);
> > +skip_bits(gb, 7);
>
> This seems to make the code less readable, no?
You means keep old style? But I think skip_bits more clear in this
case, maybe I need to add some comment?
>
>
> Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/minterpolate: fix blending calc issue.
On Fri, Jul 6, 2018 at 3:21 PM Steven Liu wrote:
>
> myp...@gmail.com 于2018年7月4日周三 下午3:05写道：
> >
> > On Wed, Jun 27, 2018 at 5:52 PM Jun Zhao wrote:
> > >
> > > the right blending calc is:
> > > (alpha * Frame_2 + (MAX - alpha) * Frame_1 + 512) >> 10
> > >
> > > Signed-off-by: Jun Zhao
> > > ---
> > > libavfilter/vf_minterpolate.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
> > > index d534315..c6a5e63 100644
> > > --- a/libavfilter/vf_minterpolate.c
> > > +++ b/libavfilter/vf_minterpolate.c
> > > @@ -1122,8 +1122,8 @@ static void interpolate(AVFilterLink *inlink,
> > AVFrame *avf_out)
> > > for (y = 0; y < height; y++) {
> > > for (x = 0; x < width; x++) {
> > > avf_out->data[plane][x + y *
> > > avf_out->linesize[plane]]
> > =
> > > - alpha *
> > > mi_ctx->frames[2].avf->data[plane][x
> > + y * mi_ctx->frames[2].avf->linesize[plane]] +
> > > -((ALPHA_MAX - alpha) *
> > > mi_ctx->frames[1].avf->data[plane][x
> > + y * mi_ctx->frames[1].avf->linesize[plane]] + 512) >> 10;
> > > +(alpha *
> > > mi_ctx->frames[2].avf->data[plane][x
> > + y * mi_ctx->frames[2].avf->linesize[plane]] +
> > > + (ALPHA_MAX - alpha) *
> > > mi_ctx->frames[1].avf->data[plane][x
> > + y * mi_ctx->frames[1].avf->linesize[plane]] + 512) >> 10;
> > > }
> > > }
> > > }
> > > --
> > > 2.7.4
> > >
> > ping, any comments for this fix?
>
> LGTM
Applied, thanks
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/minterpolate: fix blending calc issue.
On Wed, Jun 27, 2018 at 5:52 PM Jun Zhao wrote:
>
> the right blending calc is:
> (alpha * Frame_2 + (MAX - alpha) * Frame_1 + 512) >> 10
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_minterpolate.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
> index d534315..c6a5e63 100644
> --- a/libavfilter/vf_minterpolate.c
> +++ b/libavfilter/vf_minterpolate.c
> @@ -1122,8 +1122,8 @@ static void interpolate(AVFilterLink *inlink,
AVFrame *avf_out)
> for (y = 0; y < height; y++) {
> for (x = 0; x < width; x++) {
> avf_out->data[plane][x + y *
> avf_out->linesize[plane]]
=
> - alpha *
> mi_ctx->frames[2].avf->data[plane][x
+ y * mi_ctx->frames[2].avf->linesize[plane]] +
> -((ALPHA_MAX - alpha) *
> mi_ctx->frames[1].avf->data[plane][x
+ y * mi_ctx->frames[1].avf->linesize[plane]] + 512) >> 10;
> +(alpha * mi_ctx->frames[2].avf->data[plane][x
+ y * mi_ctx->frames[2].avf->linesize[plane]] +
> + (ALPHA_MAX - alpha) *
> mi_ctx->frames[1].avf->data[plane][x
+ y * mi_ctx->frames[1].avf->linesize[plane]] + 512) >> 10;
> }
> }
> }
> --
> 2.7.4
>
ping, any comments for this fix?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters: add documentation to all existing OpenCL filters, except tonemap filter
On Tue, Jul 3, 2018 at 10:51 AM Danil Iashchenko wrote:
>
> Add documentation to all existing OpenCL filters, except tonemap filter.
>
> ---
> Creation of the seperate section for OpenCL filters is motivated by
> developing support for Vulkan and CUDA and it is easier to show the
> capabilities of each platform by adding new sections.
>
> doc/filters.texi | 193
> +++
> 1 file changed, 193 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index fb5f3ee..3e18e5c 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -5423,6 +5423,7 @@ number in range [5, 129].
> Set what planes of frame filter will use for averaging. Default is all.
> @end table
>
> +@anchor{avgblur}
> @section avgblur
>
> Apply average blur filter.
> @@ -5715,6 +5716,7 @@ tblend=all_mode=grainextract
> @end example
> @end itemize
>
> +@anchor{boxblur}
> @section boxblur
>
> Apply a boxblur algorithm to the input video.
> @@ -6551,6 +6553,7 @@ For example to convert the input to SMPTE-240M, use the
> command:
> colorspace=smpte240m
> @end example
>
> +@anchor{convolution}
> @section convolution
>
> Apply convolution of 3x3, 5x5, 7x7 or horizontal/vertical up to 49 elements.
> @@ -12900,6 +12903,7 @@ By default value 0xf, all planes will be processed.
> Do not require 2nd input for processing, instead use alpha plane from input
> stream.
> @end table
>
> +@anchor{prewitt}
> @section prewitt
> Apply prewitt operator to input video stream.
>
> @@ -13591,6 +13595,7 @@ trim=end=5,reverse
> @end example
> @end itemize
>
> +@anchor{roberts}
> @section roberts
> Apply roberts cross operator to input video stream.
>
> @@ -15176,6 +15181,7 @@ asendcmd='5.0 astreamselect map
> 1',astreamselect=inputs=2:map=0
> @end example
> @end itemize
>
> +@anchor{sobel}
> @section sobel
> Apply sobel operator to input video stream.
>
> @@ -17422,6 +17428,193 @@ pixel format "yuv422p" @var{hsub} is 2 and
> @var{vsub} is 1.
>
> @c man end VIDEO FILTERS
>
> +@chapter OpenCL Video Filters
> +@c man begin OPENCL VIDEO FILTERS
> +
> +Below is a description of the currently available OpenCL video filters.
> +
> +To enable compilation of these filters you need to configure FFmpeg with
> +@code{--enable-opencl}.
> +
> +@section avgblur_opencl
> +
> +Apply average blur filter.
> +
> +Works like existing @ref{avgblur} filter.
> +
> +@subsection Example
> +
> +@itemize
> +@item
> +Apply average blur filter with sizeX and sizeY set to 3
> +@example
> +-i INPUT -filter_complex "hwupload, avgblur_opencl=3, hwdownload" OUTPUT
> +@end example
> +@end itemize
> +
> +@section boxblur_opencl
> +
> +Apply a boxblur algorithm to the input video.
> +
> +Works like existing @ref{boxblur} filter.
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Apply a boxblur filter with the luma, chroma, and alpha radius
> +set to 2:
> +@example
> +-i INPUT -filter_complex "hwupload,
> boxblur_opencl=luma_radius=2:luma_power=1, hwdownload" OUTPUT
> +-i INPUT -filter_complex "hwupload, boxblur_opencl=2:1, hwdownload" OUTPUT
> +@end example
> +
> +@item
> +Set the luma radius to 2, and alpha and chroma radius to 0:
> +@example
> +-i INPUT -filter_complex "hwupload, boxblur_opencl=2:1:cr=0:ar=0,
> hwdownload" OUTPUT
> +@end example
> +
> +@item
> +Set the luma and chroma radius to a fraction of the video dimension:
> +@example
> +-i INPUT -filter_complex "hwupload,
> boxblur_opencl=luma_radius=min(h\,w)/10:luma_power=1:chroma_radius=min(cw\,ch)/10:chroma_power=1,
> hwdownload" OUTPUT
> +@end example
> +@end itemize
> +
> +@section convolution_opencl
> +
> +Apply convolution of 3x3, 5x5, 7x7 or horizontal/vertical up to 49 elements.
> +
> +Works like existing @ref{convolution} filter.
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Apply sharpen:
> +@example
> +-i INPUT -filter_complex "hwupload, convolution_opencl=0 -1 0 -1 5 -1 0 -1
> 0:0 -1 0 -1 5 -1 0 -1 0:0 -1 0 -1 5 -1 0 -1 0:0 -1 0 -1 5 -1 0 -1 0,
> hwdownload" OUTPUT
> +@end example
> +
> +@item
> +Apply blur:
> +@example
> +-i INPUT -filter_complex "hwupload, convolution_opencl=1 1 1 1 1 1 1 1 1:1 1
> 1 1 1 1 1 1 1:1 1 1 1 1 1 1 1 1:1 1 1 1 1 1 1 1 1:1/9:1/9:1/9:1/9,
> hwdownload" OUTPUT
> +@end example
> +
> +@item
> +Apply edge enhance:
> +@example
> +-i INPUT -filter_complex "hwupload, convolution_opencl=0 0 0 -1 1 0 0 0 0:0
> 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:0 0 0 -1 1 0 0 0 0:5:1:1:1:0:128:128:128,
> hwdownload" OUTPUT
> +@end example
> +
> +@item
> +Apply edge detect:
> +@example
> +-i INPUT -filter_complex "hwupload, convolution_opencl=0 1 0 1 -4 1 0 1 0:0
> 1 0 1 -4 1 0 1 0:0 1 0 1 -4 1 0 1 0:0 1 0 1 -4 1 0 1 0:5:5:5:1:0:128:128:128,
> hwdownload" OUTPUT
> +@end example
> +
> +@item
> +Apply laplacian edge detector which includes diagonals:
> +@example
> +-i INPUT -filter_complex "hwupload, convolution_opencl=1 1 1 1 -8 1 1 1 1:1
> 1 1 1 -8 1 1 1 1:1 1 1 1 -8 1 1 1 1:1 1 1 1 -8 1 1 1 1:5:5:5:1:0:128:
Re: [FFmpeg-devel] [PATCH v2 3/4] hwcontext_opencl: Remove the opencl_device_init in opencl_device_derive
On Thu, Jun 28, 2018 at 11:50 PM Mark Thompson wrote:
>
> On 21/06/18 12:45, Jun Zhao wrote:
> > In opencl device derived case, don't need to call opencl_device_init.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavutil/hwcontext_opencl.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> > index 9e96e96..295d6be 100644
> > --- a/libavutil/hwcontext_opencl.c
> > +++ b/libavutil/hwcontext_opencl.c
> > @@ -1196,7 +1196,7 @@ static int opencl_device_derive(AVHWDeviceContext
> > *hwdev,
> > AVHWDeviceContext *src_ctx,
> > int flags)
> > {
> > -int err;
> > +int err = 0;
>
> This looks wrong - initialising it here may hide useful warnings. If there
> is a specific case where it isn't set then set it there.
Fixed this part and applied, thanks.
>
> > switch (src_ctx->type) {
> >
> > #if HAVE_OPENCL_DRM_BEIGNET
> > @@ -1362,10 +1362,7 @@ static int opencl_device_derive(AVHWDeviceContext
> > *hwdev,
> > break;
> > }
> >
> > -if (err < 0)
> > -return err;
> > -
> > -return opencl_device_init(hwdev);
> > +return err;
>
> This part looks good. (Not sure how I missed this case, the hwdevice test
> does show it when run at higher debug level.)
>
> > }
> >
> > static int opencl_get_plane_format(enum AVPixelFormat pixfmt,
> >
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 4/4] hwcontext_opencl: remove an unused variable
On Thu, Jun 28, 2018 at 11:52 PM Mark Thompson wrote: > > On 21/06/18 12:45, Jun Zhao wrote: > > remove an unused variable > > > > Signed-off-by: Jun Zhao > > --- > > libavutil/hwcontext_opencl.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c > > index 295d6be..4718a86 100644 > > --- a/libavutil/hwcontext_opencl.c > > +++ b/libavutil/hwcontext_opencl.c > > @@ -929,7 +929,6 @@ static int > > opencl_enumerate_intel_media_vaapi_devices(AVHWDeviceContext *hwdev, > > clGetDeviceIDsFromVA_APIMediaAdapterINTEL_fn > > clGetDeviceIDsFromVA_APIMediaAdapterINTEL; > > cl_int cle; > > -int err; > > > > clGetDeviceIDsFromVA_APIMediaAdapterINTEL = > > clGetExtensionFunctionAddressForPlatform(platform_id, > > > > LGTM. > > Thanks, > > - Mark Applied, thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 1/4] configure: fix check for opencl_vaapi_intel_media.
On Thu, Jun 28, 2018 at 11:51 PM Mark Thompson wrote:
>
> On 21/06/18 12:45, Jun Zhao wrote:
> > opencl_vaapi_intel_media doesn't depend on libmfx, OpenCL™ Drivers
> > and Runtimes for Intel® Architectureis is a standalone release, more
> > information can be found in the link:
> > https://software.intel.com/en-us/articles/opencl-drivers.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > configure| 6 ++
> > libavutil/hwcontext_opencl.c | 7 ++-
> > 2 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 6ad5ce8..717b2f1 100755
> > --- a/configure
> > +++ b/configure
> > @@ -6336,10 +6336,8 @@ fi
> >
> > if enabled_all opencl vaapi ; then
> > enabled opencl_drm_beignet && enable opencl_vaapi_beignet
> > -if enabled libmfx ; then
> > -check_type "CL/cl.h CL/va_ext.h"
> > "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
> > -enable opencl_vaapi_intel_media
> > -fi
> > +check_type "CL/cl.h CL/va_ext.h"
> > "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
> > +enable opencl_vaapi_intel_media
> > fi
> >
> > if enabled_all opencl dxva2 ; then
> > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> > index 07458c2..f6cceef 100644
> > --- a/libavutil/hwcontext_opencl.c
> > +++ b/libavutil/hwcontext_opencl.c
> > @@ -46,7 +46,9 @@
> > #endif
> >
> > #if HAVE_OPENCL_VAAPI_INTEL_MEDIA
> > +#if CONFIG_LIBMFX
> > #include
> > +#endif
> > #include
> > #include
> > #include "hwcontext_vaapi.h"
> > @@ -2249,10 +2251,13 @@ static int opencl_map_from_qsv(AVHWFramesContext
> > *dst_fc, AVFrame *dst,
> > cl_int cle;
> > int err, p;
> >
> > +#if CONFIG_LIBMFX
> > if (src->format == AV_PIX_FMT_QSV) {
> > mfxFrameSurface1 *mfx_surface = (mfxFrameSurface1*)src->data[3];
> > va_surface = *(VASurfaceID*)mfx_surface->Data.MemId;
> > -} else if (src->format == AV_PIX_FMT_VAAPI) {
> > +} else
> > +#endif
> > +if (src->format == AV_PIX_FMT_VAAPI) {
> > va_surface = (VASurfaceID)(uintptr_t)src->data[3];
> > } else {
> > return AVERROR(ENOSYS);
> >
>
> Looks ok to me.
>
> Thanks,
Applied, thanks
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 3/4] hwcontext_opencl: Remove the opencl_device_init in opencl_device_derive
On Thu, Jun 21, 2018 at 7:50 PM Carl Eugen Hoyos wrote:
>
> 2018-06-21 13:45 GMT+02:00, Jun Zhao :
> > In opencl device derived case, don't need to call opencl_device_init.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavutil/hwcontext_opencl.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
> > index 9e96e96..295d6be 100644
> > --- a/libavutil/hwcontext_opencl.c
> > +++ b/libavutil/hwcontext_opencl.c
> > @@ -1196,7 +1196,7 @@ static int opencl_device_derive(AVHWDeviceContext
> > *hwdev,
> > AVHWDeviceContext *src_ctx,
> > int flags)
> > {
> > -int err;
> > +int err = 0;
>
> Why is this necessary?
> And if it is necessary, why is it part of this patch?
Just give a default value , no special reason
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 1/2] lavfi: add opencl tonemap filter.
On Thu, Jun 21, 2018 at 8:33 AM Mark Thompson wrote: > > On 19/06/18 02:57, Ruiling Song wrote: > > This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping. > > > > An example command to use this filter with vaapi codecs: > > FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \ > > opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \ > > vaapi -i INPUT -filter_hw_device ocl -filter_complex \ > > '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \ > > [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT > > > > Signed-off-by: Ruiling Song > > --- > > As I didn't receive any other comment on v3, this version only fix the > > comment from Michael. > > And also include some little change to leverage CL_SET_KERNEL_ARG() macro. > > > > Thanks! > > Ruiling > > > > configure | 1 + > > libavfilter/Makefile| 2 + > > libavfilter/allfilters.c| 1 + > > libavfilter/colorspace.c| 90 + > > libavfilter/colorspace.h| 41 +++ > > libavfilter/opencl/colorspace_common.cl | 220 +++ > > libavfilter/opencl/tonemap.cl | 272 ++ > > libavfilter/opencl_source.h | 2 + > > libavfilter/vf_tonemap_opencl.c | 624 > > > > 9 files changed, 1253 insertions(+) > > create mode 100644 libavfilter/colorspace.c > > create mode 100644 libavfilter/colorspace.h > > create mode 100644 libavfilter/opencl/colorspace_common.cl > > create mode 100644 libavfilter/opencl/tonemap.cl > > create mode 100644 libavfilter/vf_tonemap_opencl.c > > I did a bit more testing, LGTM; therefore applied. > > Some further thoughts: > * Did you get anywhere with testing on other platforms? (I'm happy with the > current state with it working on at least two different platforms including > the actually-useful GPU-with-interop ones, but it would be nice to know what > was going wrong in the other cases.) Now I start to run intel NEO OpenCL GPU driver (now available on github (https://github.com/intel/compute-runtime).) + iHD open source driver(https://github.com/intel/media-driver), any status will update to the mail list. > * The single-frame-delay effect ends up looking a bit weird when I go looking > for it - I now keep seeing the flash of a single frame at a different > brightness on some transitions, though I'm not sure it's obvious enough that > I would often notice if I didn't already know it was there. How much > performance would it actually cost to use the correct frame rather than the > previous one? > * +1 to the comment from Moritz about documentation if you wouldn't mind > writing some as a separate patch. > +1 for comment, now OpenCL AVFilter use the complex command option, the other thing is if someone uses the FFmpeg API to enable the OpenCL AVFilter, I think we need some sample code in doc/examples to demo the API enable the OpenCL HWaccel. > Thanks, > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 00/11] Replace magic number by micro for bprint init
On Sun, Jun 10, 2018 at 5:28 PM Nicolas George wrote: > > Jun Zhao (2018-06-10): > > v1: - Replace magic number by micro for bprint init > > I will not oppose the patch series, but I think it is useless clutter of > the history. The special values are not magic, they are logical or > standard. > > But if anybody applies this, please fix the typo in the commit messages. > > Regards, Hi, Nicolas, I will apply the patchset with the commit message typo fix, any other comments? Thanks > > -- > Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: fix memory leak issue.
On Thu, Jun 14, 2018 at 9:44 PM Nicolas George wrote: > > Jun Zhao (2018-06-13): > > need to call av_bprint_finalize to free the memory source to match > > av_bprint_init. > > As you may have seen, in this case too, the buffer is never allocated > dynamically. > > The av_bprint_finalize() already present is thus useless (I think the > )mistake is mine), but not harmful either. > Yes, sometimes we didn't need to call av_bprint_finalize() because bprint just uses a fixed buffer (1024 - size of internal filed), but as my opinion, is it needed to recommend the caller call av_bprint_finalize() to prevent a potential memory leak if bprint using dynamically buffer and in fixed buffer case, call av_bprint_finalize() is not harmful too? Just a recommendation. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/v4l2enc: add video4linux2 name alias
On Fri, Jun 15, 2018 at 5:56 AM Lou Logan wrote: > > On Thu, Jun 14, 2018, at 1:39 PM, Lou Logan wrote: > > Makes v4l2 indev name consistent with the v4l2 indev. > > Should say: > Makes v4l2 outdev name consistent with the v4l2 indev. > > I changed this locally before sending, but forgot to re-make the updated > patch. LGTM if fix the commit message. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] fftools/ffmpeg_filter: fix memory leak issue.
On Wed, Jun 13, 2018 at 9:59 PM Nicolas George wrote: > > Jun Zhao (2018-06-13): > > need to call av_bprint_finalize to free the memory source to match > > av_bprint_init. > > No, this buffer is never allocated dynamically. > > Regards, Thanks the comments, I think I have some misunderstand for bprint API, will double-check this part. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 00/11] Replace magic number by micro for bprint init
On Mon, Jun 11, 2018 at 8:48 AM myp...@gmail.com wrote: > > On Sun, Jun 10, 2018 at 5:28 PM Nicolas George wrote: > > > > Jun Zhao (2018-06-10): > > > v1: - Replace magic number by micro for bprint init > > > > I will not oppose the patch series, but I think it is useless clutter of > > the history. The special values are not magic, they are logical or > > standard. > How about change the commit message with "Replace the number by micro > for code code readability"? a typo micro ->macro > > > > But if anybody applies this, please fix the typo in the commit messages. > > > > Regards, > > > > -- > > Nicolas George > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 00/11] Replace magic number by micro for bprint init
On Sun, Jun 10, 2018 at 5:28 PM Nicolas George wrote: > > Jun Zhao (2018-06-10): > > v1: - Replace magic number by micro for bprint init > > I will not oppose the patch series, but I think it is useless clutter of > the history. The special values are not magic, they are logical or > standard. How about change the commit message with "Replace the number by micro for code code readability"? > > But if anybody applies this, please fix the typo in the commit messages. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- === Jun zhao/赵军 +++ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 16/36] vaapi_encode: Clean up rate control configuration
On Fri, Jun 8, 2018 at 7:45 AM Mark Thompson wrote:
>
> Query which modes are supported and select between VBR and CBR based
> on that - this removes all of the codec-specific rate control mode
> selection code.
> ---
> doc/encoders.texi | 2 -
> libavcodec/vaapi_encode.c | 173
>
> libavcodec/vaapi_encode.h | 6 +-
> libavcodec/vaapi_encode_h264.c | 18 +
> libavcodec/vaapi_encode_h265.c | 14 +---
> libavcodec/vaapi_encode_mjpeg.c | 3 +-
> libavcodec/vaapi_encode_mpeg2.c | 9 +--
> libavcodec/vaapi_encode_vp8.c | 13 +--
> libavcodec/vaapi_encode_vp9.c | 13 +--
> 9 files changed, 137 insertions(+), 114 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 62a1509a96..0c0a307987 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2643,8 +2643,6 @@ Always encodes using the standard quantisation and
> huffman tables -
> @item mpeg2_vaapi
> @option{profile} and @option{level} set the value of
> @emph{profile_and_level_indication}.
>
> -No rate control is supported.
> -
> @item vp8_vaapi
> B-frames are not supported.
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index f4c063734c..5de5483454 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1217,7 +1217,6 @@ static av_cold int
> vaapi_encode_config_attributes(AVCodecContext *avctx)
> int i;
>
> VAConfigAttrib attr[] = {
> -{ VAConfigAttribRateControl },
> { VAConfigAttribEncMaxRefFrames },
> { VAConfigAttribEncPackedHeaders },
> };
> @@ -1241,32 +1240,6 @@ static av_cold int
> vaapi_encode_config_attributes(AVCodecContext *avctx)
> continue;
> }
> switch (attr[i].type) {
> -case VAConfigAttribRateControl:
> -// Hack for backward compatibility: CBR was the only
> -// usable RC mode for a long time, so old drivers will
> -// only have it. Normal default options may now choose
> -// VBR and then fail, however, so override it here with
> -// CBR if that is the only supported mode.
> -if (ctx->va_rc_mode == VA_RC_VBR &&
> -!(attr[i].value & VA_RC_VBR) &&
> -(attr[i].value & VA_RC_CBR)) {
> -av_log(avctx, AV_LOG_WARNING, "VBR rate control is "
> - "not supported with this driver version; "
> - "using CBR instead.\n");
> -ctx->va_rc_mode = VA_RC_CBR;
> -}
> -if (!(ctx->va_rc_mode & attr[i].value)) {
> -av_log(avctx, AV_LOG_ERROR, "Rate control mode %#x "
> - "is not supported (mask: %#x).\n",
> - ctx->va_rc_mode, attr[i].value);
> -return AVERROR(EINVAL);
> -}
> -ctx->config_attributes[ctx->nb_config_attributes++] =
> -(VAConfigAttrib) {
> -.type = VAConfigAttribRateControl,
> -.value = ctx->va_rc_mode,
> -};
> -break;
> case VAConfigAttribEncMaxRefFrames:
> {
> unsigned int ref_l0 = attr[i].value & 0x;
> @@ -1313,44 +1286,144 @@ static av_cold int
> vaapi_encode_config_attributes(AVCodecContext *avctx)
> static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> -int rc_bits_per_second;
> -int rc_target_percentage;
> -int rc_window_size;
> -int hrd_buffer_size;
> -int hrd_initial_buffer_fullness;
> +int64_t rc_bits_per_second;
> +int rc_target_percentage;
> +int rc_window_size;
> +int64_t hrd_buffer_size;
> +int64_t hrd_initial_buffer_fullness;
> int fr_num, fr_den;
> +VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
> +VAStatus vas;
> +
> +vas = vaGetConfigAttributes(ctx->hwctx->display,
> +ctx->va_profile, ctx->va_entrypoint,
> +&rc_attr, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query rate control "
> + "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR_EXTERNAL;
> +}
>
> -if (avctx->bit_rate > INT32_MAX) {
> -av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
> - "higher is not supported.\n");
> +if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> +av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> + "supported rate control modes: assuming constant-quality.\n");
> +ctx->va_rc_mode = VA_RC_CQP;
> +return 0;
> +}
> +if (avctx->flags & AV_CODEC_FLAG_QSCALE ||
> +avctx->bit_rate <= 0) {
> +if (rc_attr.value & VA_RC_CQP) {
> +av_log(avctx, AV_LOG_VERBOSE, "Using
Re: [FFmpeg-devel] [PATCH v2 24/36] lavc/cbs: Add JPEG support
On Fri, Jun 8, 2018 at 7:46 AM Mark Thompson wrote:
>
> ---
> configure | 2 +
> libavcodec/Makefile | 1 +
> libavcodec/cbs.c | 6 +
> libavcodec/cbs_internal.h | 1 +
> libavcodec/cbs_jpeg.c | 513
> ++
> libavcodec/cbs_jpeg.h | 128 +
> libavcodec/cbs_jpeg_syntax_template.c | 191 +
> 7 files changed, 842 insertions(+)
> create mode 100644 libavcodec/cbs_jpeg.c
> create mode 100644 libavcodec/cbs_jpeg.h
> create mode 100644 libavcodec/cbs_jpeg_syntax_template.c
>
> diff --git a/configure b/configure
> index 790f55be14..d908283954 100755
> --- a/configure
> +++ b/configure
> @@ -2244,6 +2244,7 @@ CONFIG_EXTRA="
> cbs
> cbs_h264
> cbs_h265
> +cbs_jpeg
> cbs_mpeg2
> cbs_vp9
> dirac_parse
> @@ -2507,6 +2508,7 @@ threads_if_any="$THREADS_LIST"
> # subsystems
> cbs_h264_select="cbs golomb"
> cbs_h265_select="cbs golomb"
> +cbs_jpeg_select="cbs"
> cbs_mpeg2_select="cbs"
> cbs_vp9_select="cbs"
> dct_select="rdft"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3ab071a039..2a1e0de110 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -64,6 +64,7 @@ OBJS-$(CONFIG_CABAC) += cabac.o
> OBJS-$(CONFIG_CBS) += cbs.o
> OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o h2645_parse.o
> OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o h2645_parse.o
> +OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o
> OBJS-$(CONFIG_CBS_MPEG2) += cbs_mpeg2.o
> OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
> OBJS-$(CONFIG_CRYSTALHD) += crystalhd.o
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index be6c043b58..bb3ce95971 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -35,6 +35,9 @@ static const CodedBitstreamType *cbs_type_table[] = {
> #if CONFIG_CBS_H265
> &ff_cbs_type_h265,
> #endif
> +#if CONFIG_CBS_JPEG
> +&ff_cbs_type_jpeg,
> +#endif
> #if CONFIG_CBS_MPEG2
> &ff_cbs_type_mpeg2,
> #endif
> @@ -50,6 +53,9 @@ const enum AVCodecID ff_cbs_all_codec_ids[] = {
> #if CONFIG_CBS_H265
> AV_CODEC_ID_H265,
> #endif
> +#if CONFIG_CBS_JPEG
> +AV_CODEC_ID_MJPEG,
> +#endif
> #if CONFIG_CBS_MPEG2
> AV_CODEC_ID_MPEG2VIDEO,
> #endif
> diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
> index 172b8a2515..e0e912e28e 100644
> --- a/libavcodec/cbs_internal.h
> +++ b/libavcodec/cbs_internal.h
> @@ -88,6 +88,7 @@ int ff_cbs_write_unsigned(CodedBitstreamContext *ctx,
> PutBitContext *pbc,
>
> extern const CodedBitstreamType ff_cbs_type_h264;
> extern const CodedBitstreamType ff_cbs_type_h265;
> +extern const CodedBitstreamType ff_cbs_type_jpeg;
> extern const CodedBitstreamType ff_cbs_type_mpeg2;
> extern const CodedBitstreamType ff_cbs_type_vp9;
>
> diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
> new file mode 100644
> index 00..365db73394
> --- /dev/null
> +++ b/libavcodec/cbs_jpeg.c
> @@ -0,0 +1,513 @@
> +/*
> + * 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 "cbs.h"
> +#include "cbs_internal.h"
> +#include "cbs_jpeg.h"
> +
> +
> +#define HEADER(name) do { \
> +ff_cbs_trace_header(ctx, name); \
> +} while (0)
> +
> +#define CHECK(call) do { \
> +err = (call); \
> +if (err < 0) \
> +return err; \
> +} while (0)
> +
> +#define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs,
> __VA_ARGS__ }) : NULL)
> +
> +#define u(width, name, range_min, range_max) \
> +xu(width, name, range_min, range_max, 0)
> +#define us(width, name, sub, range_min, range_max) \
> +xu(width, name, range_min, range_max, 1, sub)
> +
> +
> +#define READ
> +#define READWRITE read
> +#define RWContext GetBitContext
> +#define FUNC(name) cbs_jpeg_read_ ## name
> +
> +#define xu(width, name, range_min, range_max, subs, ...) do { \
> +uint32_t value = range_min; \
> +CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
> + SUBSCRIPTS(subs, __VA_ARGS__), \
> +
Re: [FFmpeg-devel] [PATCH 1/2] lavc/dolby_e: fix make checkheaders
2018-06-04 22:52 GMT+08:00 James Almer :
> On 6/4/2018 11:18 AM, Jun Zhao wrote:
>> move the the function init_tables() definitions from header file
>> to .c file to fix make checkheaders.
>
> What compile flags are you using? checkheaders seems to work just fine
> on a normal build.
> http://fate.ffmpeg.org/report.cgi?time=20180604121434&slot=x86_64-archlinux-gcc-checkheaders
>
>
I guess I give an inaccurate commit message, more accurate commits
message is "fix make checkheaders warning", will update the commit
message
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/dolby_e.c | 87
>>
>> libavcodec/dolby_e.h | 86
>> ---
>> 2 files changed, 87 insertions(+), 86 deletions(-)
>>
>> diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
>> index 91a00ce..429612e 100644
>> --- a/libavcodec/dolby_e.c
>> +++ b/libavcodec/dolby_e.c
>> @@ -681,6 +681,93 @@ static av_cold int dolby_e_close(AVCodecContext *avctx)
>> return 0;
>> }
>>
>> +
>> +static av_cold void init_tables(void)
>> +{
>> +int i, j;
>> +
>> +for (i = 1; i < 17; i++)
>> +mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
>> +
>> +for (i = 2; i < 16; i++) {
>> +mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
>> +mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
>> +mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
>> +}
>> +
>> +mantissa_tab1[i][1] = 0.5f / (1 << 15);
>> +mantissa_tab1[i][2] = 0.75f / (1 << 15);
>> +mantissa_tab1[i][3] = 0.875f / (1 << 15);
>> +
>> +for (i = 1; i < 17; i++) {
>> +mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
>> +mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
>> +mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
>> +for (j = 1; j < 4; j++)
>> +mantissa_tab3[i][j] = 1.0f / (1 << i) + 1.0f / (1 << j) - 1.0f
>> / (1 << i + j);
>> +}
>> +
>> +mantissa_tab3[1][3] = 0.6875f;
>> +
>> +for (i = 0; i < 25; i++) {
>> +exponent_tab[i * 2] = 1.0f / (1 << i);
>> +exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
>> +}
>> +
>> +for (i = 1; i < 1024; i++)
>> +gain_tab[i] = exp2f((i - 960) / 64.0f);
>> +
>> +// short 1
>> +ff_kbd_window_init(window, 3.0f, 128);
>> +for (i = 0; i < 128; i++)
>> +window[128 + i] = window[127 - i];
>> +
>> +// start
>> +for (i = 0; i < 192; i++)
>> +window[256 + i] = start_window[i];
>> +
>> +// short 2
>> +for (i = 0; i < 192; i++)
>> +window[448 + i] = short_window2[i];
>> +for (i = 0; i < 64; i++)
>> +window[640 + i] = window[63 - i];
>> +
>> +// short 3
>> +for (i = 0; i < 64; i++)
>> +window[704 + i] = short_window3[i];
>> +for (i = 0; i < 192; i++)
>> +window[768 + i] = window[64 + i];
>> +
>> +// bridge
>> +for (i = 0; i < 128; i++)
>> +window[960 + i] = window[i];
>> +for (i = 0; i < 64; i++)
>> +window[1088 + i] = 1.0f;
>> +
>> +// long
>> +ff_kbd_window_init(window + 1408, 3.0f, 256);
>> +for (i = 0; i < 640; i++)
>> +window[1664 + i] = 1.0f;
>> +for (i = 0; i < 256; i++)
>> +window[2304 + i] = window[1152 + i] = window[1663 - i];
>> +
>> +// reverse start
>> +for (i = 0; i < 192; i++)
>> +window[2560 + i] = window[447 - i];
>> +
>> +// reverse short 2
>> +for (i = 0; i < 256; i++)
>> +window[2752 + i] = window[703 - i];
>> +
>> +// reverse short 3
>> +for (i = 0; i < 256; i++)
>> +window[3008 + i] = window[959 - i];
>> +
>> +// reverse bridge
>> +for (i = 0; i < 448; i++)
>> +window[3264 + i] = window[1407 - i];
>> +}
>> +
>> static av_cold int dolby_e_init(AVCodecContext *avctx)
>> {
>> static AVOnce init_once = AV_ONCE_INIT;
>> diff --git a/libavcodec/dolby_e.h b/libavcodec/dolby_e.h
>> index 0390233..ae04bf6 100644
>> --- a/libavcodec/dolby_e.h
>> +++ b/libavcodec/dolby_e.h
>> @@ -644,90 +644,4 @@ static float gain_tab[1024];
>>
>> DECLARE_ALIGNED(32, static float, window)[3712];
>>
>> -static av_cold void init_tables(void)
>> -{
>> -int i, j;
>> -
>> -for (i = 1; i < 17; i++)
>> -mantissa_tab1[i][0] = 1.0f / (1 << i - 1);
>> -
>> -for (i = 2; i < 16; i++) {
>> -mantissa_tab1[i][1] = 1.0f / ((1 << i) - 1);
>> -mantissa_tab1[i][2] = 0.5f / ((1 << i) - 1);
>> -mantissa_tab1[i][3] = 0.25f / ((1 << i) - 1);
>> -}
>> -
>> -mantissa_tab1[i][1] = 0.5f / (1 << 15);
>> -mantissa_tab1[i][2] = 0.75f / (1 << 15);
>> -mantissa_tab1[i][3] = 0.875f / (1 << 15);
>> -
>> -for (i = 1; i < 17; i++) {
>> -mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5f;
>> -mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75f;
>> -mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875f;
>> -for (j = 1; j < 4; j++)
>> -mantissa_tab3[i][j
Re: [FFmpeg-devel] [PATCH v3 4/4] configure: fix check for opencl_vaapi_intel_media.
2018-06-04 2:18 GMT+08:00 Mark Thompson :
> On 03/06/18 04:15, Jun Zhao wrote:
>> opencl_vaapi_intel_media doesn't depend on libmfx, OpenCL™ Drivers
>> and Runtimes for Intel® Architectureis is a standalone release, more
>> information can be found in the link:
>> https://software.intel.com/en-us/articles/opencl-drivers.
>>
>> Signed-off-by: Jun Zhao
>> ---
>> configure| 6 ++
>> libavutil/hwcontext_opencl.c | 7 ++-
>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/configure b/configure
>> index ede32eb..aa17c13 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6326,10 +6326,8 @@ fi
>>
>> if enabled_all opencl vaapi ; then
>> enabled opencl_drm_beignet && enable opencl_vaapi_beignet
>> -if enabled libmfx ; then
>> -check_type "CL/cl.h CL/va_ext.h"
>> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
>> -enable opencl_vaapi_intel_media
>> -fi
>> +check_type "CL/cl.h CL/va_ext.h"
>> "clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
>> +enable opencl_vaapi_intel_media
>> fi
>>
>> if enabled_all opencl dxva2 ; then
>> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
>> index 9ecc361..f9b5ccc 100644
>> --- a/libavutil/hwcontext_opencl.c
>> +++ b/libavutil/hwcontext_opencl.c
>> @@ -46,7 +46,9 @@
>> #endif
>>
>> #if HAVE_OPENCL_VAAPI_INTEL_MEDIA
>> +#if CONFIG_LIBMFX
>> #include
>> +#endif
>> #include
>> #include
>> #include "hwcontext_vaapi.h"
>> @@ -2248,10 +2250,13 @@ static int opencl_map_from_qsv(AVHWFramesContext
>> *dst_fc, AVFrame *dst,
>> cl_int cle;
>> int err, p;
>>
>> +#if CONFIG_LIBMFX
>> if (src->format == AV_PIX_FMT_QSV) {
>> mfxFrameSurface1 *mfx_surface = (mfxFrameSurface1*)src->data[3];
>> va_surface = *(VASurfaceID*)mfx_surface->Data.MemId;
>> -} else if (src->format == AV_PIX_FMT_VAAPI) {
>> +} else
>> +#endif
>> +if (src->format == AV_PIX_FMT_VAAPI) {
>> va_surface = (VASurfaceID)(uintptr_t)src->data[3];
>> } else {
>> return AVERROR(ENOSYS);
>>
>
> Have you tested this in a non-MediaSDK environment? I don't think it will
> work, because it relies on proxying the special extension functions in the
> Media VAAPI driver (in particular, "DdiMedia_ExtGetSurfaceHandle") through
> libva.
The open source iHD driver will export DdiMedia_ExtGetSurfaceHandle
interface, this is the review link:
https://github.com/intel/media-driver/pull/177/commits/751110c4ca2a0515ddef843cbbd38c2ffc1f2c09,
so after this function enable by the iHD open source driver,
I think we don't need libmfx for opencl_vaapi_intel_media.
>
> I guess the patch is in itself harmless, but I'm not sure what the use-case
> of such a setup would be.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 3/4] configure: fix check for opencl
2018-06-03 11:04 GMT+08:00 James Almer :
> On 6/2/2018 11:58 PM, Jun Zhao wrote:
>> add pkg-config support for opencl check.
>>
>> Signed-off-by: Jun Zhao
>> ---
>> configure | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/configure b/configure
>> index 22eeca2..69b8827 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6130,6 +6130,7 @@ enabled openal&& { { for al_extralibs in
>> "${OPENAL_LIBS}" "-lopenal"
>> die "ERROR: openal must be installed and
>> version must be 1.1 or compatible"; }
>> enabled opencl&& { check_lib opencl OpenCL/cl.h
>> clEnqueueNDRangeKernel -Wl,-framework,OpenCL ||
>> check_lib opencl CL/cl.h
>> clEnqueueNDRangeKernel -lOpenCL ||
>> + check_pkg_config opencl OpenCL CL/cl.h
>> clEnqueueNDRangeKernel -lOpenCL ||
>
> Seeing this is exactly the same as last time and judging by your comment
> in 0/4, I assume you sent the wrong patch.
Yes, have updated the fix in the V3 patchsets
>
>> die "ERROR: opencl not found"; } &&
>> { test_cpp_condition "OpenCL/cl.h"
>> "defined(CL_VERSION_1_2)" ||
>> test_cpp_condition "CL/cl.h"
>> "defined(CL_VERSION_1_2)" ||
>>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 3/4] configure: fix check for opencl
2018-06-04 1:53 GMT+08:00 Mark Thompson :
>
> On 03/06/18 04:15, Jun Zhao wrote:
> > add pkg-config support for opencl check.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > configure | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index 22eeca2..ede32eb 100755
> > --- a/configure
> > +++ b/configure
> > @@ -6128,7 +6128,8 @@ enabled openal&& { { for al_extralibs in
> > "${OPENAL_LIBS}" "-lopenal"
> > die "ERROR: openal not found"; } &&
> > { test_cpp_condition "AL/al.h"
> > "defined(AL_VERSION_1_1)" ||
> > die "ERROR: openal must be installed and
> > version must be 1.1 or compatible"; }
> > -enabled opencl&& { check_lib opencl OpenCL/cl.h
> > clEnqueueNDRangeKernel -Wl,-framework,OpenCL ||
> > +enabled opencl&& { check_pkg_config opencl OpenCL CL/cl.h
> > clEnqueueNDRangeKernel ||
> > + check_lib opencl OpenCL/cl.h
> > clEnqueueNDRangeKernel -Wl,-framework,OpenCL ||
> > check_lib opencl CL/cl.h
> > clEnqueueNDRangeKernel -lOpenCL ||
> > die "ERROR: opencl not found"; } &&
> > { test_cpp_condition "OpenCL/cl.h"
> > "defined(CL_VERSION_1_2)" ||
> >
>
> Probably fine - what implementation(s) are you testing with here?
>
> (The official ICD loader not supporting pkg-config is kindof unfortunate.)
>
> Thanks,
I used the intel-opencl-r5.0 (SRB5.0) Linux driver package from
https://software.intel.com/en-us/articles/opencl-drivers#latest_linux_driver.
BTW: I fix a minor issue in the SRB5.0 pkg-config pc file, about
install docs, you can find in
http://registrationcenter-download.intel.com/akdlm/irc_nas/11396/SRB5.0_intel-opencl-installation.pdf
>
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/4] lavfi/opencl: remove redundancy header.
2018-06-04 1:43 GMT+08:00 Mark Thompson : > On 03/06/18 04:15, Jun Zhao wrote: >> remove redundancy header >> >> Signed-off-by: Jun Zhao >> --- >> libavfilter/opencl.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/libavfilter/opencl.c b/libavfilter/opencl.c >> index ae61667..ac5eec6 100644 >> --- a/libavfilter/opencl.c >> +++ b/libavfilter/opencl.c >> @@ -19,12 +19,9 @@ >> #include >> #include >> >> -#include "libavutil/hwcontext.h" >> -#include "libavutil/hwcontext_opencl.h" >> #include "libavutil/mem.h" >> #include "libavutil/pixdesc.h" >> >> -#include "avfilter.h" >> #include "formats.h" >> #include "opencl.h" >> >> > > "redundant", not "redundancy". > > Change is fine. Will change as the comment. Thanks. > > Thanks, > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- === Jun zhao/赵军 +++ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/4] lavu/hwcontext_opecl: fix the build warning
2018-06-04 1:42 GMT+08:00 Mark Thompson :
> On 03/06/18 04:15, Jun Zhao wrote:
>> fix the build warning when use Portable Computing Language (pocl).
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavutil/hwcontext_opencl.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
>> index 43b5c5a..9ecc361 100644
>> --- a/libavutil/hwcontext_opencl.c
>> +++ b/libavutil/hwcontext_opencl.c
>> @@ -2809,7 +2809,11 @@ static int opencl_map_from(AVHWFramesContext
*hwfc, AVFrame *dst,
>> static int opencl_map_to(AVHWFramesContext *hwfc, AVFrame *dst,
>> const AVFrame *src, int flags)
>> {
>> +#if HAVE_OPENCL_DRM_BEIGNET || HAVE_OPENCL_VAAPI_BEIGNET || \
>> +HAVE_OPENCL_VAAPI_INTEL_MEDIA || HAVE_OPENCL_DXVA2 || \
>> +HAVE_OPENCL_D3D11 || HAVE_OPENCL_DRM_ARM
>> OpenCLDeviceContext *priv = hwfc->device_ctx->internal->priv;
>> +#endif
>> av_assert0(dst->format == AV_PIX_FMT_OPENCL);
>> switch (src->format) {
>> #if HAVE_OPENCL_DRM_BEIGNET
>> @@ -2850,7 +2854,11 @@ static int opencl_map_to(AVHWFramesContext *hwfc,
AVFrame *dst,
>> static int opencl_frames_derive_to(AVHWFramesContext *dst_fc,
>> AVHWFramesContext *src_fc, int flags)
>> {
>> +#if HAVE_OPENCL_DRM_BEIGNET || HAVE_OPENCL_VAAPI_BEIGNET || \
>> +HAVE_OPENCL_VAAPI_INTEL_MEDIA || HAVE_OPENCL_DXVA2 || \
>> +HAVE_OPENCL_D3D11 || HAVE_OPENCL_DRM_ARM
>> OpenCLDeviceContext *priv = dst_fc->device_ctx->internal->priv;
>> +#endif
>> switch (src_fc->device_ctx->type) {
>> #if HAVE_OPENCL_DRM_BEIGNET
>> case AV_HWDEVICE_TYPE_DRM:
>>
>
> The condition is horrible and would need to be changed on any addition.
Just mark the variables unused instead.
Will use the unused mark to fix the warning.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
2018-05-29 13:54 GMT+08:00 Ruiling Song :
> This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping.
>
> An example command to use this filter with vaapi codecs:
> FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \
> opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \
> vaapi -i INPUT -filter_hw_device ocl -filter_complex \
> '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \
> [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT
>
> v2:
> add peak detection.
>
> Signed-off-by: Ruiling Song
> ---
> configure | 1 +
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 1 +
> libavfilter/colorspace_basic.c | 89 +
> libavfilter/colorspace_basic.h | 40 ++
> libavfilter/opencl/colorspace_basic.cl | 187 ++
> libavfilter/opencl/tonemap.cl | 278 ++
> libavfilter/opencl_source.h| 2 +
> libavfilter/vf_tonemap_opencl.c| 655
> +
> 9 files changed, 1255 insertions(+)
> create mode 100644 libavfilter/colorspace_basic.c
> create mode 100644 libavfilter/colorspace_basic.h
> create mode 100644 libavfilter/opencl/colorspace_basic.cl
> create mode 100644 libavfilter/opencl/tonemap.cl
> create mode 100644 libavfilter/vf_tonemap_opencl.c
>
> diff --git a/configure b/configure
> index e52f8f8..ee3586b 100755
> --- a/configure
> +++ b/configure
> @@ -3401,6 +3401,7 @@ tinterlace_filter_deps="gpl"
> tinterlace_merge_test_deps="tinterlace_filter"
> tinterlace_pad_test_deps="tinterlace_filter"
> tonemap_filter_deps="const_nan"
> +tonemap_opencl_filter_deps="opencl"
> unsharp_opencl_filter_deps="opencl"
> uspp_filter_deps="gpl avcodec"
> vaguedenoiser_filter_deps="gpl"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index c68ef05..0915656 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -352,6 +352,8 @@ OBJS-$(CONFIG_TINTERLACE_FILTER) +=
> vf_tinterlace.o
> OBJS-$(CONFIG_TLUT2_FILTER) += vf_lut2.o framesync.o
> OBJS-$(CONFIG_TMIX_FILTER) += vf_mix.o framesync.o
> OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o
> +OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o
> colorspace_basic.o opencl.o \
> +opencl/tonemap.o
> opencl/colorspace_basic.o
> OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
> OBJS-$(CONFIG_TRIM_FILTER) += trim.o
> OBJS-$(CONFIG_UNPREMULTIPLY_FILTER) += vf_premultiply.o framesync.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index b44093d..6873bab 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -343,6 +343,7 @@ extern AVFilter ff_vf_tinterlace;
> extern AVFilter ff_vf_tlut2;
> extern AVFilter ff_vf_tmix;
> extern AVFilter ff_vf_tonemap;
> +extern AVFilter ff_vf_tonemap_opencl;
> extern AVFilter ff_vf_transpose;
> extern AVFilter ff_vf_trim;
> extern AVFilter ff_vf_unpremultiply;
> diff --git a/libavfilter/colorspace_basic.c b/libavfilter/colorspace_basic.c
> new file mode 100644
> index 000..93f9f08
> --- /dev/null
> +++ b/libavfilter/colorspace_basic.c
> @@ -0,0 +1,89 @@
> +/*
> + * 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 "colorspace_basic.h"
> +
> +
> +void invert_matrix3x3(const double in[3][3], double out[3][3])
> +{
> +double m00 = in[0][0], m01 = in[0][1], m02 = in[0][2],
> + m10 = in[1][0], m11 = in[1][1], m12 = in[1][2],
> + m20 = in[2][0], m21 = in[2][1], m22 = in[2][2];
> +int i, j;
> +double det;
> +
> +out[0][0] = (m11 * m22 - m21 * m12);
> +out[0][1] = -(m01 * m22 - m21 * m02);
> +out[0][2] = (m01 * m12 - m11 * m02);
> +out[1][0] = -(m10 * m22 - m20 * m12);
> +out[1][1] = (m00 * m22 - m20 * m02);
> +out[1][2] = -(m00 * m12 - m10 * m02);
> +out[2][0] = (m10 * m21 - m20 * m11);
> +out[2][1] = -(m00 * m21 - m20 * m01);
> +out[2][2] = (m00 * m11 - m10 * m01);
> +
> +det = m00 * out[0][0] + m10 * out[0][1] + m20
Re: [FFmpeg-devel] [PATCH v2 0/2] dump more codec information
2018-05-27 21:04 GMT+08:00 Mark Thompson : > On 27/05/18 02:38, Jun Zhao wrote: >> V2: - fix the alignment as Reto Kromer's comment >> - improve the characterization as Mark's comments >> >> Jun Zhao (2): >> cmdutils: print missing caps in print_codec(). >> cmdutils: dump supported hardware devices in print_codec() >> >> fftools/cmdutils.c | 21 + >> 1 file changed, 21 insertions(+) >> > > Set LGTM. > > Thanks, > > - Mark will apply, thanks > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavu/hwcontext_vaapi: add nv21 map
2018-05-24 8:07 GMT+08:00 Mark Thompson :
> On 23/05/18 11:29, Jun Zhao wrote:
>> Signed-off-by: Jun Zhao
>> ---
>> libavutil/hwcontext_vaapi.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>> index 5bdb02f..7b3cbea 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -100,6 +100,9 @@ static const struct {
>> enum AVPixelFormat pix_fmt;
>> } vaapi_format_map[] = {
>> MAP(NV12, YUV420, NV12),
>> +#ifdef VA_FOURCC_NV21
>> +MAP(NV21, YUV420, NV21),// As NV12 with U and V reversed
>> +#endif
>> MAP(YV12, YUV420, YUV420P), // With U/V planes swapped.
>> MAP(IYUV, YUV420, YUV420P),
>> #ifdef VA_FOURCC_I420
>>
>
> Sure, but why would anyone ever use this format?
>
> - Mark
I don't know why iHD driver return NV21 in fact, I just
want to remove an unknow enrty dump when map the pixel format
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_vaapi: dump more decoding error details.
2018-05-24 8:05 GMT+08:00 Mark Thompson :
> On 23/05/18 11:29, Jun Zhao wrote:
>> dump more decoding error details when sync surface fail.
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavutil/hwcontext_vaapi.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>> index e55bb8d..5bdb02f 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -742,6 +742,23 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
>> av_log(hwfc, AV_LOG_ERROR, "Failed to sync surface "
>> "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>> err = AVERROR(EIO);
>> +/* query decode detail error */
>> +if (vas == VA_STATUS_ERROR_DECODING_ERROR) {
>> +VASurfaceDecodeMBErrors *dec_err = NULL;
>> +int i;
>> +vas = vaQuerySurfaceError(hwctx->display, surface_id,
>> VA_STATUS_ERROR_DECODING_ERROR,
>> + (void **)&dec_err);
>> +if (VA_STATUS_SUCCESS == vas) {
>> +if (NULL != dec_err) {
>
> Why this check?
maybe give a assert0?
>
>> +for (i = 0; dec_err[i].status != -1; i++) {
>
> How many items can be in this list? We probably don't want to print more
> than one in the error log if this can happen on every frame in a broken
> stream.
Oh, from the API define, "array is terminated if "status==-1" is
detected", so I don't know
the error entry number from VA-API level (but I checked the iHD source code,
I think iHD always return 2 error entries in this case). In current
FFmpeg VA-API
HWaccel decoding logic, I believe if vaSyncSurface fail, FFmpeg will return the
error and exit, so we don't have a change to print the error message
every frame.
>> + av_log(hwfc, AV_LOG_ERROR, "Decoding deatils
>> error, "
>
> "Decoding error details:" maybe?
Ok, will change it
>
>> + "type: %d, start mb: %d, end md: %d, num
>> mbs: %d.\n",
>> + dec_err[i].decode_error_type,
>> dec_err[i].start_mb,
>> + dec_err[i].end_mb, dec_err[i].num_mb);
>> +}
>> +}
>> +}
>> +}
>> goto fail;
>> }
>>
>>
>
> What is the lifetime of the returned pointer here? This can certainly be
> called on any thread asynchronously.
Yes, I have the same thought about this API, basically, I think
vaQuerySurfaceError()
need to return the pointer and ask the caller to free the error
entries like getaddressinfo()/freeaddrinfo(),
and I think need to submit a patch to VA-API/iHD driver for this part.
>
> It's a bit nasty to have this in the generic code rather than the decoder:
> very few actual uses are going to call SyncSurface directly on a decoder
> output - rather they will pass it to some other component (another VAAPI one,
> or export). Could we instead put this inside the decoder, enabled by some
> debug option? (Some sort of "catch decoder errors earlier at a cost of
> (possibly greatly) decreased performance" flag.)
I can give a case, when I debug the ticket #7200, I try to dump the
YUV but fail,
so I want to get more decoding error from iHD driver.
use the command like this: ./ffmpeg_g -hwaccel vaapi -vaapi_device
/dev/dri/renderD128 -hwaccel_flags allow_profile_mismatch -i test.ts
-f null /dev/null
I think give a decoder option in this case is a good suggestion, I
will check this way. Thanks.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
2018-05-21 14:50 GMT+08:00 Ruiling Song :
> This filter does HDR(HDR10/HLG) to SDR conversion with tone-mapping.
>
> An example command to use this filter with vaapi codecs:
> FFMPEG -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device \
> opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format \
> vaapi -i INPUT -filter_hw_device ocl -filter_complex \
> '[0:v]hwmap,tonemap_opencl=t=bt2020:tonemap=linear:format=p010[x1]; \
> [x1]hwmap=derive_device=vaapi:reverse=1' -c:v hevc_vaapi -profile 2 OUTPUT
>
> Signed-off-by: Ruiling Song
> ---
> configure | 1 +
> libavfilter/Makefile | 2 +
> libavfilter/allfilters.c | 1 +
> libavfilter/colorspace_basic.c | 89 ++
> libavfilter/colorspace_basic.h | 40 +++
> libavfilter/opencl/colorspace_basic.cl | 179 +++
> libavfilter/opencl/tonemap.cl | 258 +++
> libavfilter/opencl_source.h| 2 +
> libavfilter/vf_tonemap_opencl.c| 560
> +
> 9 files changed, 1132 insertions(+)
> create mode 100644 libavfilter/colorspace_basic.c
> create mode 100644 libavfilter/colorspace_basic.h
> create mode 100644 libavfilter/opencl/colorspace_basic.cl
> create mode 100644 libavfilter/opencl/tonemap.cl
> create mode 100644 libavfilter/vf_tonemap_opencl.c
>
> diff --git a/configure b/configure
> index e52f8f8..ee3586b 100755
> --- a/configure
> +++ b/configure
> @@ -3401,6 +3401,7 @@ tinterlace_filter_deps="gpl"
> tinterlace_merge_test_deps="tinterlace_filter"
> tinterlace_pad_test_deps="tinterlace_filter"
> tonemap_filter_deps="const_nan"
> +tonemap_opencl_filter_deps="opencl"
> unsharp_opencl_filter_deps="opencl"
> uspp_filter_deps="gpl avcodec"
> vaguedenoiser_filter_deps="gpl"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index c68ef05..0915656 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -352,6 +352,8 @@ OBJS-$(CONFIG_TINTERLACE_FILTER) +=
> vf_tinterlace.o
> OBJS-$(CONFIG_TLUT2_FILTER) += vf_lut2.o framesync.o
> OBJS-$(CONFIG_TMIX_FILTER) += vf_mix.o framesync.o
> OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o
> +OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o
> colorspace_basic.o opencl.o \
> +opencl/tonemap.o
> opencl/colorspace_basic.o
> OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
> OBJS-$(CONFIG_TRIM_FILTER) += trim.o
> OBJS-$(CONFIG_UNPREMULTIPLY_FILTER) += vf_premultiply.o framesync.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index b44093d..6873bab 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -343,6 +343,7 @@ extern AVFilter ff_vf_tinterlace;
> extern AVFilter ff_vf_tlut2;
> extern AVFilter ff_vf_tmix;
> extern AVFilter ff_vf_tonemap;
> +extern AVFilter ff_vf_tonemap_opencl;
> extern AVFilter ff_vf_transpose;
> extern AVFilter ff_vf_trim;
> extern AVFilter ff_vf_unpremultiply;
> diff --git a/libavfilter/colorspace_basic.c b/libavfilter/colorspace_basic.c
> new file mode 100644
> index 000..93f9f08
> --- /dev/null
> +++ b/libavfilter/colorspace_basic.c
> @@ -0,0 +1,89 @@
> +/*
> + * 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 "colorspace_basic.h"
> +
> +
> +void invert_matrix3x3(const double in[3][3], double out[3][3])
> +{
> +double m00 = in[0][0], m01 = in[0][1], m02 = in[0][2],
> + m10 = in[1][0], m11 = in[1][1], m12 = in[1][2],
> + m20 = in[2][0], m21 = in[2][1], m22 = in[2][2];
> +int i, j;
> +double det;
> +
> +out[0][0] = (m11 * m22 - m21 * m12);
> +out[0][1] = -(m01 * m22 - m21 * m02);
> +out[0][2] = (m01 * m12 - m11 * m02);
> +out[1][0] = -(m10 * m22 - m20 * m12);
> +out[1][1] = (m00 * m22 - m20 * m02);
> +out[1][2] = -(m00 * m12 - m10 * m02);
> +out[2][0] = (m10 * m21 - m20 * m11);
> +out[2][1] = -(m00 * m21 - m20 * m01);
> +out[2][2] = (m00 * m11 - m10 * m01);
> +
> +det = m00 * out[0][0] + m10 * out[0][1] + m20 * out[0][2];
> +det =
Re: [FFmpeg-devel] [PATCH v2 0/3] Enhancement NAL type debug
2018-05-14 17:45 GMT+08:00 Jun Zhao : > v2: - cover all h264/hevc NAL unit type > - use table replace switch when map NAL type to string/name > > Jun Zhao (3): > lavc/h2645_parse: log more HEVC NAL type. > lavc/h2645_parse: rename the nal_unit_name to hevc_nal_unit_name. > lavc/h2645_parse: add h264_nal_unit_name for h264 NAL type. > > libavcodec/h264.h| 23 +++- > libavcodec/h2645_parse.c | 147 > --- > libavcodec/hevc.h| 26 - > 3 files changed, 162 insertions(+), 34 deletions(-) > > -- > 2.7.4 > Ping, any comments for this patchset? Thanks. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] hwcontext: Do not call device_init again when deriving an existing device
2018-05-15 5:58 GMT+08:00 Mark Thompson : > The change in 309d660775e2b47af6723a0477c4d753bc0c54f4 to call device_init > when doing derivation missed this case - we should only call it if we > actually made a new device. > --- > libavutil/hwcontext.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c > index 70c556ecac..745016ed7e 100644 > --- a/libavutil/hwcontext.c > +++ b/libavutil/hwcontext.c > @@ -646,6 +646,9 @@ int av_hwdevice_ctx_create_derived(AVBufferRef > **dst_ref_ptr, > ret = AVERROR(ENOMEM); > goto fail; > } > +ret = av_hwdevice_ctx_init(dst_ref); > +if (ret < 0) > +goto fail; > goto done; > } > if (ret != AVERROR(ENOSYS)) > @@ -658,10 +661,6 @@ int av_hwdevice_ctx_create_derived(AVBufferRef > **dst_ref_ptr, > goto fail; > > done: > -ret = av_hwdevice_ctx_init(dst_ref); > -if (ret < 0) > -goto fail; > - > *dst_ref_ptr = dst_ref; > return 0; > > -- Patchset LGTM, thanks. > 2.16.3 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavc/cbs_h2645: fix no slice data trigger the assert.
2018-05-11 23:38 GMT+08:00 James Almer :
> On 5/11/2018 7:10 AM, Mark Thompson wrote:
>> On 11/05/18 06:11, Jun Zhao wrote:
>>> when the NALU data with zero, just give a warning.
>>>
>>> Fixes ticket #7200
>>>
>>> Signed-off-by: Jun Zhao
>>> ---
>>> libavcodec/cbs_h2645.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>>> index ab33cdb..08b060c 100644
>>> --- a/libavcodec/cbs_h2645.c
>>> +++ b/libavcodec/cbs_h2645.c
>>> @@ -521,7 +521,11 @@ static int
>>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>>> // Remove trailing zeroes.
>>> while (size > 0 && nal->data[size - 1] == 0)
>>> --size;
>>> -av_assert0(size > 0);
>>> +if (!size) {
>>> +av_log(ctx->log_ctx, AV_LOG_WARNING, "No slice data - that was
>>> just the header. "
>>> + "Probably invalid unaligned padding on non-final NAL
>>> unit.\n");
>>> +continue;
>>> +}
>>>
>>> data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
>>> if (!data)
>>>
>>
>> What do we actually want the result to be here?
>>
>> On IRC, James suggested:
>>
>>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
>>> index dbf2435677..d436d65f48 100644
>>> --- a/libavcodec/h2645_parse.c
>>> +++ b/libavcodec/h2645_parse.c
>>> @@ -371,7 +371,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
>>> uint8_t *buf, int length,
>>> ret = hevc_parse_nal_header(nal, logctx);
>>> else
>>> ret = h264_parse_nal_header(nal, logctx);
>>> -if (ret <= 0 || nal->size <= 0) {
>>> +if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
>>> if (ret < 0) {
>>> av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d,
>>> skipping.\n",
>>> nal->type);
>>
>> which removes it before it gets to the CBS code.
>>
>> Another thing we could do is:
>>
>>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>>> index ab33cdb69b..46cd887cdd 100644
>>> --- a/libavcodec/cbs_h2645.c
>>> +++ b/libavcodec/cbs_h2645.c
>>> @@ -519,7 +519,7 @@ static int
>>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>>> uint8_t *data;
>>>
>>> // Remove trailing zeroes.
>>> -while (size > 0 && nal->data[size - 1] == 0)
>>> +while (size > 1 && nal->data[size - 1] == 0)
>>> --size;
>>> av_assert0(size > 0);
>>>
>>
>> which would make it parse as an empty NAL unit of type 0 (unspecified), and
>> therefore pass through into the output stream in the h264_metadata case.
>>
>> So, what do you think? Do you know what made your sample stream?
>>
>> - Mark
>
> Taking into account the analysis by mkver in the trac ticket, where he
> found out the bitstream contains "00 00 00 01 00 00 00 01" with the
> second start code being a real valid NAL, i think this should definitely
> be fixed in h2645_parse. No reason to propagate a non existent NAL like
> this.
> We should either use my fix, or another that actually prevents nal->size
> from inexplicably becoming 1 in this scenario.
Now h2645_parse give a loose check in ff_h2645_packet_split(), and I agree
use your fix
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavc/cbs_h2645: fix no slice data trigger the assert.
2018-05-11 18:10 GMT+08:00 Mark Thompson :
> On 11/05/18 06:11, Jun Zhao wrote:
>> when the NALU data with zero, just give a warning.
>>
>> Fixes ticket #7200
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/cbs_h2645.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index ab33cdb..08b060c 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -521,7 +521,11 @@ static int
>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>> // Remove trailing zeroes.
>> while (size > 0 && nal->data[size - 1] == 0)
>> --size;
>> -av_assert0(size > 0);
>> +if (!size) {
>> +av_log(ctx->log_ctx, AV_LOG_WARNING, "No slice data - that was
>> just the header. "
>> + "Probably invalid unaligned padding on non-final NAL
>> unit.\n");
>> +continue;
>> +}
>>
>> data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
>> if (!data)
>>
>
> What do we actually want the result to be here?
>
> On IRC, James suggested:
>
>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
>> index dbf2435677..d436d65f48 100644
>> --- a/libavcodec/h2645_parse.c
>> +++ b/libavcodec/h2645_parse.c
>> @@ -371,7 +371,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
>> uint8_t *buf, int length,
>> ret = hevc_parse_nal_header(nal, logctx);
>> else
>> ret = h264_parse_nal_header(nal, logctx);
>> -if (ret <= 0 || nal->size <= 0) {
>> +if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
>> if (ret < 0) {
>> av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d,
>> skipping.\n",
>> nal->type);
>
> which removes it before it gets to the CBS code.
I agree this way, I think we need drop the invalid NAL unit as early
as possible.
>
> Another thing we could do is:
>
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index ab33cdb69b..46cd887cdd 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -519,7 +519,7 @@ static int
>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>> uint8_t *data;
>>
>> // Remove trailing zeroes.
>> -while (size > 0 && nal->data[size - 1] == 0)
>> +while (size > 1 && nal->data[size - 1] == 0)
>> --size;
>> av_assert0(size > 0);
>>
>
> which would make it parse as an empty NAL unit of type 0 (unspecified), and
> therefore pass through into the output stream in the h264_metadata case.
>
> So, what do you think? Do you know what made your sample stream?
I got this sample from a live streaming android phone APPs
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] lavc/h2645_parse: add h264_nal_unit_name for h264 NAL type.
2018-05-11 18:19 GMT+08:00 Mark Thompson :
> On 11/05/18 06:11, Jun Zhao wrote:
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/h2645_parse.c | 26 --
>> 1 file changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
>> index 579b2c9..8d67579 100644
>> --- a/libavcodec/h2645_parse.c
>> +++ b/libavcodec/h2645_parse.c
>> @@ -28,6 +28,7 @@
>>
>> #include "bytestream.h"
>> #include "hevc.h"
>> +#include "h264.h"
>> #include "h2645_parse.h"
>>
>> int ff_h2645_extract_rbsp(const uint8_t *src, int length,
>> @@ -193,6 +194,27 @@ static const char *hevc_nal_unit_name(int nal_type)
>> }
>> }
>>
>> +static const char *h264_nal_unit_name(int nal_type)
>> +{
>> +switch(nal_type) {
>> +case H264_NAL_SLICE : return "SLICE";
>> +case H264_NAL_DPA : return "DPA";
>> +case H264_NAL_DPB : return "DPB";
>> +case H264_NAL_DPC : return "DPC";
>> +case H264_NAL_IDR_SLICE : return "IDR_SLICE";
>> +case H264_NAL_SEI : return "SEI";
>> +case H264_NAL_SPS : return "SPS";
>> +case H264_NAL_PPS : return "PPS";
>> +case H264_NAL_AUD : return "AUD";
>> +case H264_NAL_END_SEQUENCE: return "END_SEQUENCE";
>> +case H264_NAL_END_STREAM : return "END_STREAM";
>> +case H264_NAL_FILLER_DATA : return "FILLER_DATA";
>> +case H264_NAL_SPS_EXT : return "SPS_EXT";
>> +case H264_NAL_AUXILIARY_SLICE : return "AUXILIARY_SLICE";
>
> Unlike H.265 these names aren't defined by the standard, so I think I'd write
> them normally ("IDR slice", "End of sequence") rather than using the shouty
> enum names. Doesn't really matter, though.
I will update the code as the comments, everything that makes the code
clearer is worthwhile to do.
>
>> +default : return "?";
>> +}
>> +}
>> +
>> static int get_bit_length(H2645NAL *nal, int skip_trailing_zeros)
>> {
>> int size = nal->size;
>> @@ -255,8 +277,8 @@ static int h264_parse_nal_header(H2645NAL *nal, void
>> *logctx)
>> nal->type= get_bits(gb, 5);
>>
>> av_log(logctx, AV_LOG_DEBUG,
>> - "nal_unit_type: %d, nal_ref_idc: %d\n",
>> - nal->type, nal->ref_idc);
>> + "nal_unit_type: %d(%s), nal_ref_idc: %d\n",
>> + nal->type, h264_nal_unit_name(nal->type), nal->ref_idc);
>>
>> return 1;
>> }
>>
>
> LGTM either way.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
===
Pixelworks
Room 301-303 No. 88,Lane 887 Zuchongzhi Road, Zhangjiang Hi-tech Park,
Shanghai 201203, China
Best Regards,
Jun zhao/赵军
+++
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] doc/protocols: documents tcp_mss
2018-05-06 23:16 GMT+08:00 Gyan Doshi :
>
>
> On 5/6/2018 8:42 PM, Jun Zhao wrote:
>
>> +@item tcp_mss=@var{bytes}
>> +Set maximum segment size for outgoing TCP packets, expressed bytes.
>
>
> 'expressed bytes' --> 'expressed in bytes'
>
> or just 'in bytes' (preferred).
>
>
Sounds good, will update in the V2. tks.
> Thanks,
> Gyan
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavf/tcp: add option to setting Maximum Segment Size
2018-05-07 5:17 GMT+08:00 Michael Niedermayer : > On Sun, May 06, 2018 at 11:12:13PM +0800, Jun Zhao wrote: >> This can change the the MSS value announced to the other end in >> the initial TCP packet, it's can be used when failed Path MTU >> discovery. >> >> Signed-off-by: Jun Zhao >> --- >> libavformat/tcp.c | 5 + >> 1 file changed, 5 insertions(+) > > breaks build on mingw64 > > CC libavformat/tcp.o > src/libavformat/tcp.c: In function ‘tcp_open’: > src/libavformat/tcp.c:159:27: error: ‘TCP_MAXSEG’ undeclared (first use in > this function) > setsockopt (fd, IPPROTO_TCP, TCP_MAXSEG, &s->tcp_mss, sizeof > (s->tcp_mss)); >^ > src/libavformat/tcp.c:159:27: note: each undeclared identifier is reported > only once for each function it appears in > make: *** [libavformat/tcp.o] Error 1 > make: Target `all' not remade because of errors. Will fix the mingw64 build fail, tks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No great genius has ever existed without some touch of madness. -- Aristotle > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > -- === Pixelworks Room 301-303 No. 88,Lane 887 Zuchongzhi Road, Zhangjiang Hi-tech Park, Shanghai 201203, China Best Regards, Jun zhao/赵军 +++ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
