[FFmpeg-devel] [PATCH] doc/filters: Correct scale doc regarding w/h <= 0
According to libavfilter/scale.c, if the width and height are both less than or equal to 0 then the input size is used for both dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which is the same as -10:-42, etc. if (w < 0 && h < 0) eval_w = eval_h = 0; Signed-off-by: Kevin Mark --- doc/filters.texi | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/filters.texi b/doc/filters.texi index 65eef89d07..b9d6eafc74 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -12125,12 +12125,13 @@ the complete list of scaler options. Set the output video dimension expression. Default value is the input dimension. -If the value is 0, the input width is used for the output. +If the width value is 0, the input width is used for the output. If the +height value is 0, the input height is used for the output. If one of the values is -1, the scale filter will use a value that maintains the aspect ratio of the input image, calculated from the -other specified dimension. If both of them are -1, the input size is -used +other specified dimension. If both of them are negative, the behavior +will be identical to both values being set to 0 as explained above. If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other -- 2.13.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter
Dear Moritz,
On Mon, Jun 5, 2017 at 3:21 PM, Moritz Barsnick wrote:
> I can't comment on the rest (and still really like the concept), but
> just this:
>
>> +Allowed values are positive integers between @code{1} and @code{65535}.
>
> This maximum value is no longer correct.
It's correct as far as I can tell. From the code:
{ "step", "set frame step", OFFSET(frame_step), AV_OPT_TYPE_INT64,
{.i64=1}, 1, UINT16_MAX, FLAGS},
So you can see that UINT16_MAX (=65535) is the maximum value for the
step size, as documented. (Note that the type is AV_OPT_TYPE_INT64
because UINT16_MAX doesn't necessarily fit into an int, as you
correctly pointed out earlier.)
>> +Allowed values are positive integers between @code{1} and @code{step},
>> +where @code{1} corresponds to no motion blur, and @code{step}
>> +corresponds to maximal motion blur.
>
> Just wondering: Isn't this also useful for a slideshow-like
> transition/fade, not just for motion blur? (I'm saying: If so, the user
> needs to know.)
Good point, one could use it that way too, yes. I don't think it's
essential to the patch, but I'd be happy to submit a follow-on patch
to mention this use as well.
> I think I need to build and test it, to see if it fits
> my needs. ;)
Ok, thanks!
Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: add log time info into report log file
On 03.06.2017 08:41, Steven Liu wrote:
2017-06-03 0:30 GMT+08:00 Nicolas George :
Le quintidi 15 prairial, an CCXXV, Steven Liu a écrit :
add time info into every line of log report
the time info can be used to find out error message occur time.
Signed-off-by: Steven Liu
---
cmdutils.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/cmdutils.c b/cmdutils.c
index 3d428f3eea..b760a0565d 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -47,6 +47,7 @@
#include "libavutil/libm.h"
#include "libavutil/parseutils.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
#include "libavutil/eval.h"
#include "libavutil/dict.h"
#include "libavutil/opt.h"
@@ -103,6 +104,8 @@ void log_callback_help(void *ptr, int level, const char
*fmt, va_list vl)
static void log_callback_report(void *ptr, int level, const char *fmt, va_list
vl)
{
va_list vl2;
+char *tmp_string = NULL;
+char time_value[32];
char line[1024];
static int print_prefix = 1;
@@ -111,7 +114,10 @@ static void log_callback_report(void *ptr, int level,
const char *fmt, va_list v
av_log_format_line(ptr, level, fmt, vl2, line, sizeof(line),
&print_prefix);
va_end(vl2);
if (report_file_level >= level) {
-fputs(line, report_file);
+snprintf(time_value, sizeof(time_value), "\n[%"PRId64"] - ",
av_gettime());
+tmp_string = av_strireplace(line, "\n", time_value);
It looks like you are printing the time of a line at the beginning of
the next line. Or am I missing something.
Also, I do not like the dynamic alloc in this function, especially since
the same task can be done without: find \n, print the time and the
single line, loop.
+fputs(tmp_string, report_file);
+av_free(tmp_string);
fflush(report_file);
}
}
Regards,
Hi Nicolas,
I get some problem of the log output:
1. the log output by multiple av_log to one line,
for example:
av_log(NULL, "major_brand :");
av_log(NULL, "isom\n");
then if add the time to the line head, it will output looks like this:
[1496470846077636] - major_brand :
[1496470846077643] - isom[1496470846077650] -
2. but if add the time to the end of line, it maybe need control
right alignment
3. maybe the better solution is add the time into line head when
the log level big than AV_LOG_WARNING ?
Maybe you could use the existing "print_prefix" flag to check whether a
timestamp prefix shall be added?
And it would be good if the timestamp prefix would be made optional
similar to the AV_LOG_PRINT_LEVEL flag.
Regards,
Tobias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mpegvideo_enc: allow to force low_delay by increasing strict_std_compliance
On date Saturday 2017-05-27 00:07:38 +0200, Michael Niedermayer encoded: > On Wed, May 24, 2017 at 10:31:10AM +0200, Stefano Sabatini wrote: [...] > > mpegvideo_enc.c |6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > 0fa1dff6e9dbb5122cbea81ba56eb1892a0bb398 > > 0003-lavc-mpegvideo_enc-allow-low_delay-for-non-MPEG2-cod.patch > > From 536d88be287613a3a49dd60c1023c2418e9b8810 Mon Sep 17 00:00:00 2001 > > From: Stefano Sabatini > > Date: Tue, 23 May 2017 12:22:41 +0200 > > Subject: [PATCH] lavc/mpegvideo_enc: allow low_delay for non MPEG2 codecs > > depending on strict_std_compliance > > > > Forcing low_delay can be useful, even if not officially supported. > > --- > > libavcodec/mpegvideo_enc.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > probably ok > > thanks Applied, thanks. -- FFmpeg = Faithless and Friendly Merciless Powerful Enhanced Game ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter
On Tue, Jun 06, 2017 at 10:09:04 +0100, Matthias Troffaes wrote: > > This maximum value is no longer correct. > It's correct as far as I can tell. From the code: Sorry, you're right and I'm wrong. I missed the change to int64. > > Just wondering: Isn't this also useful for a slideshow-like > > transition/fade, not just for motion blur? (I'm saying: If so, the user > > needs to know.) > > Good point, one could use it that way too, yes. I don't think it's > essential to the patch, but I'd be happy to submit a follow-on patch > to mention this use as well. Yes, because "motion blur" is quite abstract to me. I used the previously available filter(s) to "blend", i.e. blend "over" from one image to another. On the time scale, that's still a blur, but a blur is not what comes to mind visually. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters: Correct scale doc regarding w/h <= 0
On Tue, Jun 06, 2017 at 03:27:06 -0400, Kevin Mark wrote: > According to libavfilter/scale.c, if the width and height are both > less than or equal to 0 then the input size is used for both > dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which > is the same as -10:-42, etc. This makes it obvious that the paragraph following the one you fixed is a bit misleading (to me): If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary. This is true only if *exactly* one of the two values is "-n with n > 1". (It also doesn't apply to "-1:-2". Good luck finding words to describe this behavior. ;-)) Just nitpicking, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: add log time info into report log file
On Tue, Jun 06, 2017 at 11:42:10 +0200, Tobias Rapp wrote: > And it would be good if the timestamp prefix would be made optional > similar to the AV_LOG_PRINT_LEVEL flag. Yes indeed, please. It's already hard diff'ing two logfiles, this would require even more awk-ward stuff on the command line (or plain frustration under Windows). Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_colorspace: Add support for gbr color space
Hi,
On Mon, Jun 5, 2017 at 4:08 PM, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara
> ---
> libavfilter/vf_colorspace.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index 0024505a44..0b1bc81f99 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -183,6 +183,13 @@ static const double ycgco_matrix[3][3] =
> { 0.5, 0, -0.5 },
> };
>
> +static const double gbr_matrix[3][3] =
> +{
> +{ 0,1, 0 },
> +{ 0, -0.5, 0.5 },
> +{ 0.5, -0.5, 0 },
> +};
> +
> /*
> * All constants explained in e.g. https://linuxtv.org/downloads/
> v4l-dvb-apis/ch02s06.html
> * The older ones (bt470bg/m) are also explained in their respective ITU
> docs
> @@ -196,6 +203,7 @@ static const struct LumaCoefficients
> luma_coefficients[AVCOL_SPC_NB] = {
> [AVCOL_SPC_BT709] = { 0.2126, 0.7152, 0.0722 },
> [AVCOL_SPC_SMPTE240M] = { 0.212, 0.701, 0.087 },
> [AVCOL_SPC_YCOCG] = { 0.25, 0.5,0.25 },
> +[AVCOL_SPC_RGB]= { 1, 1, 1 },
> [AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
> [AVCOL_SPC_BT2020_CL] = { 0.2627, 0.6780, 0.0593 },
> };
> @@ -222,6 +230,9 @@ static void fill_rgb2yuv_table(const struct
> LumaCoefficients *coeffs,
> if (coeffs->cr == 0.25 && coeffs->cg == 0.5 && coeffs->cb == 0.25) {
> memcpy(rgb2yuv, ycgco_matrix, sizeof(double) * 9);
> return;
> +} else if (coeffs->cr == 1 && coeffs->cg == 1 && coeffs->cb == 1) {
> +memcpy(rgb2yuv, gbr_matrix, sizeof(double) * 9);
> +return;
Not a big fan of these special cases, but I guess it's OK and I don't quite
know how to prevent it. So LGTM. Need me to push?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/vp9: ipred_dl_32x32_16 avx2 implementation
Hi, On Mon, Jun 5, 2017 at 1:41 PM, James Almer wrote: > On 6/4/2017 2:52 PM, Ilia Valiakhmetov wrote: > > vp9_diag_downleft_32x32_8bpp_c: 580.2 > > vp9_diag_downleft_32x32_8bpp_sse2: 75.6 > > vp9_diag_downleft_32x32_8bpp_ssse3: 73.7 > > vp9_diag_downleft_32x32_8bpp_avx: 72.7 > > vp9_diag_downleft_32x32_10bpp_c: 1101.2 > > vp9_diag_downleft_32x32_10bpp_sse2: 145.4 > > vp9_diag_downleft_32x32_10bpp_ssse3: 137.5 > > vp9_diag_downleft_32x32_10bpp_avx: 134.8 > > vp9_diag_downleft_32x32_10bpp_avx2: 94.0 > > vp9_diag_downleft_32x32_12bpp_c: 1108.5 > > vp9_diag_downleft_32x32_12bpp_sse2: 145.5 > > vp9_diag_downleft_32x32_12bpp_ssse3: 137.3 > > vp9_diag_downleft_32x32_12bpp_avx: 135.2 > > vp9_diag_downleft_32x32_12bpp_avx2: 94.0 > > > > ~30% faster than avx implementation > > Nice. > > > > > --- > > libavcodec/x86/vp9dsp_init_16bpp.c| 2 ++ > > libavcodec/x86/vp9intrapred_16bpp.asm | 63 > +++ > > 2 files changed, 65 insertions(+) > > > > diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c > b/libavcodec/x86/vp9dsp_init_16bpp.c > > index 4576ff1..d1b8fcd 100644 > > --- a/libavcodec/x86/vp9dsp_init_16bpp.c > > +++ b/libavcodec/x86/vp9dsp_init_16bpp.c > > @@ -52,6 +52,7 @@ decl_ipred_fns(dc, 16, mmxext, sse2); > > decl_ipred_fns(dc_top, 16, mmxext, sse2); > > decl_ipred_fns(dc_left, 16, mmxext, sse2); > > decl_ipred_fn(dl, 16, 16, avx2); > > +decl_ipred_fn(dl, 32, 16, avx2); > > > > #define decl_ipred_dir_funcs(type) \ > > decl_ipred_fns(type, 16, sse2, sse2); \ > > @@ -135,6 +136,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext > *dsp) > > init_fpel_func(1, 1, 64, avg, _16, avx2); > > init_fpel_func(0, 1, 128, avg, _16, avx2); > > init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2); > > +init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2); > > } > > > > #endif /* HAVE_YASM */ > > diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm > b/libavcodec/x86/vp9intrapred_16bpp.asm > > index 212e413..5cd6a3e 100644 > > --- a/libavcodec/x86/vp9intrapred_16bpp.asm > > +++ b/libavcodec/x86/vp9intrapred_16bpp.asm > > @@ -861,6 +861,7 @@ cglobal vp9_ipred_dl_16x16_16, 2, 4, 5, dst, stride, > l, a > > DEFINE_ARGS dst, stride, stride3, cnt > > mov cntd, 2 > > lea stride3q, [strideq*3] > > + > > Trailing whitespaces. > > > .loop: > > mova [dstq+strideq*0], m0 > > vpalignrm3, m2, m0, 2 > > @@ -884,6 +885,68 @@ cglobal vp9_ipred_dl_16x16_16, 2, 4, 5, dst, > stride, l, a > > dec cntd > > jg .loop > > RET > > + > > Same. > > > +cglobal vp9_ipred_dl_32x32_16, 2, 6, 7, dst, stride, l, a > > +movifnidn aq, amp > > +movam0, [aq+mmsize*0+ 0] ; > abcdefghijklmnop > > +movam1, [aq+mmsize*1+ 0] ; > qrstuvwxyz012345 > > +vpbroadcastw xm4, [aq+mmsize*1+30] ; > > +vperm2i128 m5, m0, m1, q0201 ; > ijklmnopqrstuvwx > > +vpalignrm2, m5, m0, 2 ; > bcdefghijklmnopq > > +vpalignrm3, m5, m0, 4 ; > cdefghijklmnopqr > > +LOWPASS 0, 2, 3 ; > BCDEFGHIJKLMNOPQ > > +vperm2i128 m5, m1, m4, q0201 ; > yz012345 > > +vpalignrm2, m5, m1, 2 ; > rstuvwxyz0123455 > > +vpalignrm3, m5, m1, 4 ; > stuvwxyz01234555 > > +LOWPASS 1, 2, 3 ; > RSTUVWXYZ..5 > > +vperm2i128 m2, m1, m4, q0201 ; > Z..5 > > +vperm2i128 m5, m0, m1, q0201 ; > JKLMNOPQRSTUVWXY > > +DEFINE_ARGS dst, stride, stride3, cnt > > +lea stride3q, [strideq*3] > > +mov cntd, 4 > > + > > Same. > > Ronald can fix them before pushing (I think the git hooks would prevent > him to push this with them anyway), so no need to resend a fixed patch. > Just keep it in mind for future patchsets. Same with tabs on files other > than Makefile stuff. Pushed with that fixed. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP] [PATCH 0/6] sse2/xmm version of 8-bit simple_idct
Hi, On Mon, Jun 5, 2017 at 8:02 AM, Ronald S. Bultje wrote: > On Mon, Jun 5, 2017 at 7:23 AM, James Darnley wrote: > >> I forgot to mention in my cover letter that although the dct test >> passes, fate does not. As I mentioned on IRC, changing them causes >> errors elsewhere in fate. I am currently looking into this problem and >> I'm sure I will speak to you or others about it. > > > I'll have a look at this. > This makes the output of dct-test exact: diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm index ae848b7..0dd1ae5 100644 --- a/libavcodec/x86/simple_idct10.asm +++ b/libavcodec/x86/simple_idct10.asm @@ -52,6 +52,9 @@ times 4 dw %2, %3 %define W6sh2 8867 ; W6 = 35468 = 8867<<2 %define W7sh2 4520 ; W7 = 18081 = 4520<<2 + 1 +pw_round_20_div_w4: times 8 dw ((1 << (20 - 1)) / W4sh2) + + CONST_DEC w4_plus_w2, W4sh2, +W2sh2 CONST_DEC w4_min_w2,W4sh2, -W2sh2 CONST_DEC w4_plus_w6, W4sh2, +W6sh2 @@ -71,7 +74,7 @@ SECTION .text %macro idct_fn 0 cglobal simple_idct8, 1, 1, 16, block -IDCT_FN"", 11, "", 20 +IDCT_FN"", 11, pw_round_20_div_w4, 20 RET cglobal simple_idct10, 1, 1, 16, block How the final patch should look (i.e. change coefficients only for mpeg idct and not for prores idct to keep fate happy? Or change C code for prores so coefficients are identical?) is up to you, I don't have a preference. Michael might have an opinion on that. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.
On Sat, 3 Jun 2017 19:31:37 -0700
Sasi Inguva wrote:
> > -// Offset the DTS by ctts[0] to make the PTS of the first frame 0
> > -if (ctts_data_old && ctts_count_old > 0) {
> > -edit_list_dts_entry_end -= ctts_data_old[0].duration;
> > -av_log(mov->fc, AV_LOG_DEBUG, "Offset DTS by ctts[%d].duration:
> %d\n", 0, ctts_data_old[0].duration);
> > +av_log(mov->fc, AV_LOG_DEBUG, "Shifting DTS by %d because of
> negative CTTS.\n", msc->dts_shift);
> > }
>
> The above lines were the cause of making the first frame PTS of videos
> starting with B-frames negative. If the videos starts with B frame, then
> the minimum composition time as computed by stts + ctts will be non-zero.
> Hence we need to shift the DTS, so that the first pts is zero. This was the
> intention of that code-block. However it was subtracting by the wrong
> amount.
> For example, for one of the videos in the bug nonFormatted.mp4 we have
> stts:
> sample_count duration
> 960 1001
> ctts:
> sample_count duration
> 1 3003
> 2 0
> 1 3003
>
>
> The resulting composition times are : 3003, 1001, 2002, 6006, ...
> Hence the minimum composition time or PTS is 1001, which should be used to
> offset DTS. However the code block was wrongly using ctts[0] which is 3003
> . Hence the PTS was negative.
>
> About the fate test expectations, fate-suite/h264/twofields_packet.mp4 is a
> similar file starting with 2 Bframes. Before this change the PTS of first
> two B-frames was -6006 and -3003, and I am guessing one of them got dropped
> when being decoded and remuxed to the framecrc before, and now it is not
> being dropped but I dont understand why.
All of this should go into the commit message.
Can't judge the correctness of the actual code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls
On Tue, 6 Jun 2017 04:59:58 +0200 Michael Niedermayer wrote: > I disagree that the issue is minor and far fetched. > > The exploit that i have was successfully used against multiple > companies (it was a demonstration and AFAIK no harm was done). > That same attack works against all recent releases. > > My oppinion was and is that a exploit working basically on 100% of > targets and can leak private information is a serious issue. Until I see actual proof, I call bullshit. It also might be that there are better solutions, but we can't know, because you withhold information. I'm sick of these "security" fixes, which just make everything trickier, worse, and not necessarily much more secure. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/utils: Slightly un-clutter code in determinable_frame_size() by using a switch
On Sun, 4 Jun 2017 02:25:46 +0200
Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/utils.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index c5f1eac185..bbc7a7b547 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -894,12 +894,13 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>
> static int determinable_frame_size(AVCodecContext *avctx)
> {
> -if (/*avctx->codec_id == AV_CODEC_ID_AAC ||*/
> -avctx->codec_id == AV_CODEC_ID_MP1 ||
> -avctx->codec_id == AV_CODEC_ID_MP2 ||
> -avctx->codec_id == AV_CODEC_ID_MP3/* ||
> -avctx->codec_id == AV_CODEC_ID_CELT*/)
> +switch(avctx->codec_id) {
> +case AV_CODEC_ID_MP1:
> +case AV_CODEC_ID_MP2:
> +case AV_CODEC_ID_MP3:
> return 1;
> +}
> +
> return 0;
> }
>
Seems like an improvement.
Is there any reason for this function to exist, though? (I bet nobody
knows.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] compat: LoadLibrary isn't available on UWP/WinRT
On Sat, 3 Jun 2017 10:54:08 -0700
Aaron Levinson wrote:
> On 6/2/2017 7:11 AM, wm4 wrote:
> > On Fri, 2 Jun 2017 15:29:07 +0200
> > Hugo Beauzée-Luyssen wrote:
> >
> >> ---
> >> compat/w32dlfcn.h | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
> >> index bc9bb8c9f5..308763be53 100644
> >> --- a/compat/w32dlfcn.h
> >> +++ b/compat/w32dlfcn.h
> >> @@ -71,7 +71,11 @@ exit:
> >> #ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
> >> # define LOAD_LIBRARY_SEARCH_SYSTEM320x0800
> >> #endif
> >> +#if WINAPI_FAMILY_PARTITION (WINAPI_PARTITION_DESKTOP)
> >> return LoadLibraryExA(name, NULL,
> >> LOAD_LIBRARY_SEARCH_APPLICATION_DIR | LOAD_LIBRARY_SEARCH_SYSTEM32);
> >> +#else
> >> +return NULL;
> >> +#endif
> >> }
> >> #define dlopen(name, flags) win32_dlopen(name)
> >> #define dlclose FreeLibrary
> >
> > Isn't it that LoadLibraryW is available, just not the A version?
>
> According to
> https://msdn.microsoft.com/en-us/library/windows/apps/mt654039.aspx#_api-ms-win-core-libraryloader-l1-2-0.dll
>
> , both the A and W versions of LoadLibrary and LoadLibraryEx would seem
> to be available on UWP. However, at the same time, I don't see any of
> the LoadLibrary APIs listed at either
> https://msdn.microsoft.com/en-us/library/windows/apps/dn424765.aspx ,
> https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis , or
> https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-extension-apis
> , so perhaps LoadLibrary and LoadLibraryEx aren't supported. So, there
> appears to be some conflicting information on MSDN. According to
> https://msdn.microsoft.com/en-us/library/mt186162.aspx , it is necessary
> to use LoadPackagedLibrary in UWP apps instead of LoadLibrary or
> LoadLibraryEx.
>
> According to the article, "These macros are only available in Windows
> SDK 8.1 and later, so if your code needs to compile with earlier
> versions of the Windows SDK or for other platforms besides Windows, then
> you should also consider the case that none of them are defined." I'm
> not aware of ffmpeg necessarily having a requirement that it be built
> with the Windows 8.1 SDK or later, and this lack of requirement would
> tend to indicate that the proposed patch isn't sufficient. Plus, there
> is no reason to #define LOAD_LIBRARY_SEARCH_SYSTEM32 if the code won't
> be built anyway.
Actually libwinstorecompat seems to have a wrapper:
HMODULE WINAPI LoadLibraryW(LPCWSTR lpFileName)
{
return LoadPackagedLibrary(lpFileName, 0);
}
(Good one, Microsoft...)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/vorbisenc: Fix memory leak on errors
Switches temporary samples for processing to be stored in the encoder's
context, avoids memory leaks if any errors occur while encoding a frame.
Fixes CID1412026
Signed-off-by: Tyler Jones
---
libavcodec/vorbisenc.c | 49 -
1 file changed, 12 insertions(+), 37 deletions(-)
diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
index 856f590..afded40 100644
--- a/libavcodec/vorbisenc.c
+++ b/libavcodec/vorbisenc.c
@@ -112,6 +112,7 @@ typedef struct vorbis_enc_context {
float *samples;
float *floor; // also used for tmp values for mdct
float *coeffs; // also used for residue after floor
+float *scratch; // used for tmp values for psy model
float quality;
AudioFrameQueue afq;
@@ -452,7 +453,9 @@ static int create_vorbis_context(vorbis_enc_context *venc,
venc->samples= av_malloc_array(sizeof(float) * venc->channels, (1 <<
venc->log2_blocksize[1]));
venc->floor = av_malloc_array(sizeof(float) * venc->channels, (1 <<
venc->log2_blocksize[1]) / 2);
venc->coeffs = av_malloc_array(sizeof(float) * venc->channels, (1 <<
venc->log2_blocksize[1]) / 2);
-if (!venc->saved || !venc->samples || !venc->floor || !venc->coeffs)
+venc->scratch= av_malloc_array(sizeof(float) * venc->channels, (1 <<
venc->log2_blocksize[1]) / 2);
+
+if (!venc->saved || !venc->samples || !venc->floor || !venc->coeffs ||
!venc->scratch)
return AVERROR(ENOMEM);
if ((ret = dsp_init(avctx, venc)) < 0)
@@ -992,7 +995,7 @@ static int residue_encode(vorbis_enc_context *venc,
vorbis_enc_residue *rc,
}
static int apply_window_and_mdct(vorbis_enc_context *venc,
- float **audio, int samples)
+ float *audio, int samples)
{
int channel;
const float * win = venc->win[0];
@@ -1017,7 +1020,7 @@ static int apply_window_and_mdct(vorbis_enc_context *venc,
for (channel = 0; channel < venc->channels; channel++) {
float *offset = venc->samples + channel * window_len * 2 +
window_len;
-fdsp->vector_fmul_reverse(offset, audio[channel], win, samples);
+fdsp->vector_fmul_reverse(offset, audio + channel * window_len,
win, samples);
fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
}
} else {
@@ -1034,7 +1037,7 @@ static int apply_window_and_mdct(vorbis_enc_context *venc,
for (channel = 0; channel < venc->channels; channel++) {
float *offset = venc->saved + channel * window_len;
-fdsp->vector_fmul(offset, audio[channel], win, samples);
+fdsp->vector_fmul(offset, audio + channel * window_len, win,
samples);
fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
}
venc->have_saved = 1;
@@ -1068,28 +1071,8 @@ static AVFrame *spawn_empty_frame(AVCodecContext *avctx,
int channels)
return f;
}
-static float **alloc_audio_arrays(int channels, int frame_size)
-{
-float **audio = av_mallocz_array(channels, sizeof(float *));
-if (!audio)
-return NULL;
-
-for (int ch = 0; ch < channels; ch++) {
-audio[ch] = av_mallocz_array(frame_size, sizeof(float));
-if (!audio[ch]) {
-// alloc has failed, free everything allocated thus far
-for (ch--; ch >= 0; ch--)
-av_free(audio[ch]);
-av_free(audio);
-return NULL;
-}
-}
-
-return audio;
-}
-
/* Concatenate audio frames into an appropriately sized array of samples */
-static void move_audio(vorbis_enc_context *venc, float **audio, int *samples,
int sf_size)
+static void move_audio(vorbis_enc_context *venc, float *audio, int *samples,
int sf_size)
{
AVFrame *cur = NULL;
int frame_size = 1 << (venc->log2_blocksize[1] - 1);
@@ -1102,7 +1085,7 @@ static void move_audio(vorbis_enc_context *venc, float
**audio, int *samples, in
for (int ch = 0; ch < venc->channels; ch++) {
const float *input = (float *) cur->extended_data[ch];
const size_t len = cur->nb_samples * sizeof(float);
-memcpy(&audio[ch][sf*sf_size], input, len);
+memcpy(audio + ch*frame_size + sf*sf_size, input, len);
}
av_frame_free(&cur);
}
@@ -1112,7 +1095,6 @@ static int vorbis_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
const AVFrame *frame, int *got_packet_ptr)
{
vorbis_enc_context *venc = avctx->priv_data;
-float **audio = NULL;
int i, ret, need_more;
int samples = 0, frame_size = 1 << (venc->log2_blocksize[1] - 1);
vorbis_enc_mode *mode;
@@ -1132,10 +1114,6 @@ static int vorbis_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
if (need_more)
return 0;
-audio = alloc_audio_arrays(venc->channels, frame_size);
-if (!audio)
-return AVERROR(ENOMEM);
-
/* Pad the bufqueue wi
Re: [FFmpeg-devel] [PATCH 1/3] checkasm: add a checkasm_checked_call function that doesn't issue emms
On 6/1/2017 8:10 PM, James Almer wrote: > Meant for DSP functions returning a float or double, as they'd fail if emms > is called after every run on x86_32. > > Signed-off-by: James Almer > --- > tests/checkasm/checkasm.h | 11 +++ > tests/checkasm/x86/checkasm.asm | 13 +++-- > 2 files changed, 18 insertions(+), 6 deletions(-) Ping for set. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/utils: Slightly un-clutter code in determinable_frame_size() by using a switch
On Tue, Jun 06, 2017 at 03:57:22PM +0200, wm4 wrote:
> On Sun, 4 Jun 2017 02:25:46 +0200
> Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/utils.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index c5f1eac185..bbc7a7b547 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -894,12 +894,13 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
> >
> > static int determinable_frame_size(AVCodecContext *avctx)
> > {
> > -if (/*avctx->codec_id == AV_CODEC_ID_AAC ||*/
> > -avctx->codec_id == AV_CODEC_ID_MP1 ||
> > -avctx->codec_id == AV_CODEC_ID_MP2 ||
> > -avctx->codec_id == AV_CODEC_ID_MP3/* ||
> > -avctx->codec_id == AV_CODEC_ID_CELT*/)
> > +switch(avctx->codec_id) {
> > +case AV_CODEC_ID_MP1:
> > +case AV_CODEC_ID_MP2:
> > +case AV_CODEC_ID_MP3:
> > return 1;
> > +}
> > +
> > return 0;
> > }
> >
>
> Seems like an improvement.
applied
>
> Is there any reason for this function to exist, though? (I bet nobody
> knows.)
If i remember correctly
It lists the audio codecs for which the parser will set the frame
size upon encountering a valid undamaged (key) frame.
I think some streams require waiting for this point to have correct
information.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil/eval: Add round function to expression parser
On Tue, Jun 06, 2017 at 12:43:13AM -0400, Kevin Mark wrote: > We have floor, ceil, and trunc. Let's add round. > > Signed-off-by: Kevin Mark > --- > doc/utils.texi | 3 +++ > libavutil/eval.c | 5 - > 2 files changed, 7 insertions(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/scale: More descriptive in/ref/out logging
On Mon, Jun 05, 2017 at 06:55:20AM -0400, Kevin Mark wrote: > This change makes it more clear when using the scale and scale2ref > filters what is actually happening. The old format did not > differentiate between scale and scale2ref which would make it seem > that, when using scale2ref, the ref was what was truly being scaled. > > Old format for both scale and scale2ref: > > w:640 h:360 fmt:rgb24 sar:1/1 -> w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2 > > The left side is the input and the right side is the output. While > this is sufficiently clear for scale, for scale2ref it appears to > conflate the main input with the reference input. To be fair that is > exactly what the code is doing (and on purpose) but that's not a very > intuitive implementation detail to expose to the user. Now that the > main input's constants are exposed in scale2ref it makes even more > sense to correct this. > > New format for scale: > > in w:320 h:240 fmt:rgb24 sar:1/1 > out w:80 h:60 fmt:rgb24 sar:1/1 flags:0xc > > New format for scale2ref: > > in w:320 h:240 fmt:rgb24 sar:1/1 > ref w:640 h:360 fmt:rgb24 sar:1/1 > out w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2 > > The increase in clarity is self-evident. yes but its much harder to grep for as its not a single line anymore [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] lavc: add mpeg2 decoder/hwaccel to mediacodec
On Mon, Jun 5, 2017 at 1:22 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> Android TV and FireOS hardware supports mpeg2 hardware decoding via
> MediaCodec.
>
I tested this patch on an NVIDIA SHIELD, FireTV gen1 and FireTV Stick gen2
and they all worked as expected.
Let me know if you want me to make any other changes before it can be
merged.
Thanks.
> ---
> configure | 2 ++
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c| 2 ++
> libavcodec/mediacodecdec.c| 40 ++
> -
> libavcodec/mediacodecdec_common.c | 7 +++
> 5 files changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 72060ef0e9..5816de2398 100755
> --- a/configure
> +++ b/configure
> @@ -2656,6 +2656,7 @@ mpeg2_d3d11va_hwaccel_deps="d3d11va"
> mpeg2_d3d11va_hwaccel_select="mpeg2video_decoder"
> mpeg2_dxva2_hwaccel_deps="dxva2"
> mpeg2_dxva2_hwaccel_select="mpeg2video_decoder"
> +mpeg2_mediacodec_hwaccel_deps="mediacodec"
> mpeg2_mmal_hwaccel_deps="mmal"
> mpeg2_qsv_hwaccel_deps="libmfx"
> mpeg2_qsv_hwaccel_select="qsvdec_mpeg2"
> @@ -2762,6 +2763,7 @@ mpeg1_vdpau_decoder_select="mpeg1video_decoder"
> mpeg2_crystalhd_decoder_select="crystalhd"
> mpeg2_cuvid_decoder_deps="cuda cuvid"
> mpeg2_mmal_decoder_deps="mmal"
> +mpeg2_mediacodec_decoder_deps="mediacodec"
> mpeg2_qsv_decoder_deps="libmfx"
> mpeg2_qsv_decoder_select="qsvdec mpeg2_qsv_hwaccel"
> mpeg2_qsv_encoder_deps="libmfx"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 0818950ad9..a752f87ef5 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -423,6 +423,7 @@ OBJS-$(CONFIG_MPEG2_QSV_DECODER) +=
> qsvdec_other.o
> OBJS-$(CONFIG_MPEG2_QSV_ENCODER) += qsvenc_mpeg2.o
> OBJS-$(CONFIG_MPEG2VIDEO_DECODER) += mpeg12dec.o mpeg12.o
> mpeg12data.o
> OBJS-$(CONFIG_MPEG2VIDEO_ENCODER) += mpeg12enc.o mpeg12.o
> +OBJS-$(CONFIG_MPEG2_MEDIACODEC_DECODER) += mediacodecdec.o
> OBJS-$(CONFIG_MPEG2_VAAPI_ENCODER) += vaapi_encode_mpeg2.o
> OBJS-$(CONFIG_MPEG4_DECODER) += xvididct.o
> OBJS-$(CONFIG_MPEG4_MEDIACODEC_DECODER) += mediacodecdec.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 89fadcd2fa..4373ebd975 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -96,6 +96,7 @@ static void register_all(void)
> REGISTER_HWACCEL(MPEG2_VAAPI, mpeg2_vaapi);
> REGISTER_HWACCEL(MPEG2_VDPAU, mpeg2_vdpau);
> REGISTER_HWACCEL(MPEG2_VIDEOTOOLBOX, mpeg2_videotoolbox);
> +REGISTER_HWACCEL(MPEG2_MEDIACODEC, mpeg2_mediacodec);
> REGISTER_HWACCEL(MPEG4_CUVID, mpeg4_cuvid);
> REGISTER_HWACCEL(MPEG4_MEDIACODEC, mpeg4_mediacodec);
> REGISTER_HWACCEL(MPEG4_MMAL,mpeg4_mmal);
> @@ -257,6 +258,7 @@ static void register_all(void)
> REGISTER_DECODER(MPEG2_MMAL,mpeg2_mmal);
> REGISTER_DECODER(MPEG2_CRYSTALHD, mpeg2_crystalhd);
> REGISTER_DECODER(MPEG2_QSV, mpeg2_qsv);
> +REGISTER_DECODER(MPEG2_MEDIACODEC, mpeg2_mediacodec);
> REGISTER_DECODER(MSA1, msa1);
> REGISTER_DECODER(MSCC, mscc);
> REGISTER_DECODER(MSMPEG4V1, msmpeg4v1);
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index ccfcb4b9ce..5bdeb6c1d7 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -1,5 +1,5 @@
> /*
> - * Android MediaCodec H.264 / H.265 / MPEG-4 / VP8 / VP9 decoders
> + * Android MediaCodec MPEG-2 / H.264 / H.265 / MPEG-4 / VP8 / VP9 decoders
> *
> * Copyright (c) 2015-2016 Matthieu Bouron >
> *
> @@ -267,6 +267,19 @@ done:
> }
> #endif
>
> +#if CONFIG_MPEG2_MEDIACODEC_DECODER
> +static int mpeg2_set_extradata(AVCodecContext *avctx, FFAMediaFormat
> *format)
> +{
> +int ret = 0;
> +
> +if (avctx->extradata) {
> +ff_AMediaFormat_setBuffer(format, "csd-0", avctx->extradata,
> avctx->extradata_size);
> +}
> +
> +return ret;
> +}
> +#endif
> +
> #if CONFIG_MPEG4_MEDIACODEC_DECODER
> static int mpeg4_set_extradata(AVCodecContext *avctx, FFAMediaFormat
> *format)
> {
> @@ -333,6 +346,15 @@ static av_cold int mediacodec_decode_init(AVCodecContext
> *avctx)
> goto done;
> break;
> #endif
> +#if CONFIG_MPEG2_MEDIACODEC_DECODER
> +case AV_CODEC_ID_MPEG2VIDEO:
> +codec_mime = "video/mpeg2";
> +
> +ret = mpeg2_set_extradata(avctx, format);
> +if (ret < 0)
> +goto done;
> +break;
> +#endif
> #if CONFIG_MPEG4_MEDIACODEC_DECODER
> case AV_CODEC_ID_MPEG4:
> codec_mime = "video/mp4v-es",
> @@ -575,6 +597,22 @@ AVCodec ff_hevc_mediacodec_decoder = {
> };
> #endif
>
> +#if CONFIG_MPEG2_MEDIACODEC_DECODER
> +AVCodec ff_mpeg2_mediacodec_decoder = {
> +.name = "mpeg2_mediacodec",
> +.long_name = NULL_IF_CONFIG_SMALL("MPEG-2 Android MediaCodec
> decoder"),
> +.
Re: [FFmpeg-devel] [PATCH] avcodec/vorbisenc: Fix memory leak on errors
On 6 June 2017 at 15:06, Tyler Jones wrote:
> Switches temporary samples for processing to be stored in the encoder's
> context, avoids memory leaks if any errors occur while encoding a frame.
> Fixes CID1412026
>
> Signed-off-by: Tyler Jones
> ---
> libavcodec/vorbisenc.c | 49 --
> ---
> 1 file changed, 12 insertions(+), 37 deletions(-)
>
> diff --git a/libavcodec/vorbisenc.c b/libavcodec/vorbisenc.c
> index 856f590..afded40 100644
> --- a/libavcodec/vorbisenc.c
> +++ b/libavcodec/vorbisenc.c
> @@ -112,6 +112,7 @@ typedef struct vorbis_enc_context {
> float *samples;
> float *floor; // also used for tmp values for mdct
> float *coeffs; // also used for residue after floor
> +float *scratch; // used for tmp values for psy model
> float quality;
>
> AudioFrameQueue afq;
> @@ -452,7 +453,9 @@ static int create_vorbis_context(vorbis_enc_context
> *venc,
> venc->samples= av_malloc_array(sizeof(float) * venc->channels, (1
> << venc->log2_blocksize[1]));
> venc->floor = av_malloc_array(sizeof(float) * venc->channels, (1
> << venc->log2_blocksize[1]) / 2);
> venc->coeffs = av_malloc_array(sizeof(float) * venc->channels, (1
> << venc->log2_blocksize[1]) / 2);
> -if (!venc->saved || !venc->samples || !venc->floor || !venc->coeffs)
> +venc->scratch= av_malloc_array(sizeof(float) * venc->channels, (1
> << venc->log2_blocksize[1]) / 2);
> +
> +if (!venc->saved || !venc->samples || !venc->floor || !venc->coeffs
> || !venc->scratch)
> return AVERROR(ENOMEM);
>
> if ((ret = dsp_init(avctx, venc)) < 0)
> @@ -992,7 +995,7 @@ static int residue_encode(vorbis_enc_context *venc,
> vorbis_enc_residue *rc,
> }
>
> static int apply_window_and_mdct(vorbis_enc_context *venc,
> - float **audio, int samples)
> + float *audio, int samples)
> {
> int channel;
> const float * win = venc->win[0];
> @@ -1017,7 +1020,7 @@ static int apply_window_and_mdct(vorbis_enc_context
> *venc,
> for (channel = 0; channel < venc->channels; channel++) {
> float *offset = venc->samples + channel * window_len * 2 +
> window_len;
>
> -fdsp->vector_fmul_reverse(offset, audio[channel], win,
> samples);
> +fdsp->vector_fmul_reverse(offset, audio + channel *
> window_len, win, samples);
> fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
> }
> } else {
> @@ -1034,7 +1037,7 @@ static int apply_window_and_mdct(vorbis_enc_context
> *venc,
> for (channel = 0; channel < venc->channels; channel++) {
> float *offset = venc->saved + channel * window_len;
>
> -fdsp->vector_fmul(offset, audio[channel], win, samples);
> +fdsp->vector_fmul(offset, audio + channel * window_len, win,
> samples);
> fdsp->vector_fmul_scalar(offset, offset, 1/n, samples);
> }
> venc->have_saved = 1;
> @@ -1068,28 +1071,8 @@ static AVFrame *spawn_empty_frame(AVCodecContext
> *avctx, int channels)
> return f;
> }
>
> -static float **alloc_audio_arrays(int channels, int frame_size)
> -{
> -float **audio = av_mallocz_array(channels, sizeof(float *));
> -if (!audio)
> -return NULL;
> -
> -for (int ch = 0; ch < channels; ch++) {
> -audio[ch] = av_mallocz_array(frame_size, sizeof(float));
> -if (!audio[ch]) {
> -// alloc has failed, free everything allocated thus far
> -for (ch--; ch >= 0; ch--)
> -av_free(audio[ch]);
> -av_free(audio);
> -return NULL;
> -}
> -}
> -
> -return audio;
> -}
> -
> /* Concatenate audio frames into an appropriately sized array of samples
> */
> -static void move_audio(vorbis_enc_context *venc, float **audio, int
> *samples, int sf_size)
> +static void move_audio(vorbis_enc_context *venc, float *audio, int
> *samples, int sf_size)
> {
> AVFrame *cur = NULL;
> int frame_size = 1 << (venc->log2_blocksize[1] - 1);
> @@ -1102,7 +1085,7 @@ static void move_audio(vorbis_enc_context *venc,
> float **audio, int *samples, in
> for (int ch = 0; ch < venc->channels; ch++) {
> const float *input = (float *) cur->extended_data[ch];
> const size_t len = cur->nb_samples * sizeof(float);
> -memcpy(&audio[ch][sf*sf_size], input, len);
> +memcpy(audio + ch*frame_size + sf*sf_size, input, len);
> }
> av_frame_free(&cur);
> }
> @@ -1112,7 +1095,6 @@ static int vorbis_encode_frame(AVCodecContext
> *avctx, AVPacket *avpkt,
> const AVFrame *frame, int *got_packet_ptr)
> {
> vorbis_enc_context *venc = avctx->priv_data;
> -float **audio = NULL;
> int i, ret, need_more;
> int samples = 0, frame_size = 1 << (venc->log2_blocksize[1] - 1);
> vorbis_enc_mode *mode;
> @@
[FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.
Fixes t/6421. If the videos starts with B frame, then the minimum composition
time as computed by stts + ctts will be non-zero. Hence we need to shift the
DTS, so that the first pts is zero. This was the intention of that code-block.
However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
stts:
sample_count duration
960 1001
ctts:
sample_count duration
1 3003
2 0
1 3003
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to offset
DTS. However the code block was wrongly using ctts[0] which is 3003. Hence the
PTS was negative. This change computes the minimum pts encountered while fixing
the index, and then subtracts it from all the timestamps after the edit list
fixes are applied.
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2 Bframes.
Before this change the PTS of first two B-frames was -6006 and -3003, and I am
guessing one of them got dropped when being decoded and remuxed to the
framecrc before, and now it is not being dropped.
Signed-off-by: Sasi Inguva
---
libavformat/mov.c| 57 --
tests/ref/fate/h264-twofields-packet | 60 ++--
2 files changed, 70 insertions(+), 47 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 3845e63b53..d7d64c3361 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3039,6 +3039,9 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
int64_t edit_list_dts_entry_end = 0;
int64_t edit_list_start_ctts_sample = 0;
int64_t curr_cts;
+int64_t curr_ctts = 0;
+int64_t min_corrected_pts = -1;
+int64_t empty_edits_sum_duration = 0;
int64_t edit_list_index = 0;
int64_t index;
int64_t index_ctts_count;
@@ -3053,6 +3056,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
int first_non_zero_audio_edit = -1;
int packet_skip_samples = 0;
MOVIndexRange *current_index_range;
+int i;
if (!msc->elst_data || msc->elst_count <= 0 || nb_old <= 0) {
return;
@@ -3080,13 +3084,9 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
// If the dts_shift is positive (in case of negative ctts values in mov),
// then negate the DTS by dts_shift
-if (msc->dts_shift > 0)
+if (msc->dts_shift > 0) {
edit_list_dts_entry_end -= msc->dts_shift;
-
-// Offset the DTS by ctts[0] to make the PTS of the first frame 0
-if (ctts_data_old && ctts_count_old > 0) {
-edit_list_dts_entry_end -= ctts_data_old[0].duration;
-av_log(mov->fc, AV_LOG_DEBUG, "Offset DTS by ctts[%d].duration: %d\n",
0, ctts_data_old[0].duration);
+av_log(mov->fc, AV_LOG_DEBUG, "Shifting DTS by %d because of negative
CTTS.\n", msc->dts_shift);
}
start_dts = edit_list_dts_entry_end;
@@ -3100,6 +3100,7 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
edit_list_dts_entry_end += edit_list_duration;
num_discarded_begin = 0;
if (edit_list_media_time == -1) {
+empty_edits_sum_duration += edit_list_duration;
continue;
}
@@ -3179,11 +3180,13 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
// frames (pts) before or after edit list
curr_cts = current->timestamp + msc->dts_shift;
+curr_ctts = 0;
if (ctts_data_old && ctts_index_old < ctts_count_old) {
-av_log(mov->fc, AV_LOG_DEBUG, "shifted frame pts, curr_cts:
%"PRId64" @ %"PRId64", ctts: %d, ctts_count: %"PRId64"\n",
- curr_cts, ctts_index_old,
ctts_data_old[ctts_index_old].duration, ctts_count_old);
-curr_cts += ctts_data_old[ctts_index_old].duration;
+curr_ctts = ctts_data_old[ctts_index_old].duration;
+av_log(mov->fc, AV_LOG_DEBUG, "stts: %"PRId64" ctts:
%"PRId64", ctts_index: %"PRId64", ctts_count: %"PRId64"\n",
+ curr_cts, curr_ctts, ctts_index_old, ctts_count_old);
+curr_cts += curr_ctts;
ctts_sample_old++;
if (ctts_sample_old == ctts_data_old[ctts_index_old].count) {
if (add_ctts_entry(&msc->ctts_data, &msc->ctts_count,
@@ -3244,14 +3247,21 @@ static void mov_fix_index(MOVContext *mov, AVStream *st)
}
}
}
-} else if (edit_list_start_encountered == 0) {
-edit_list_start_encountered = 1;
-// Make timestamps strictly monotonically increasing for
audio, by rewriting timestamps for
-// discarded packets.
-if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
frame_duration_buffer) {
-fix_index_entry_timestamps(st, st->nb_index_entries,
edit_list
Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.
Got it. Added to the description.
On Tue, Jun 6, 2017 at 6:51 AM, wm4 wrote:
> On Sat, 3 Jun 2017 19:31:37 -0700
> Sasi Inguva wrote:
>
> > > -// Offset the DTS by ctts[0] to make the PTS of the first frame 0
> > > -if (ctts_data_old && ctts_count_old > 0) {
> > > -edit_list_dts_entry_end -= ctts_data_old[0].duration;
> > > -av_log(mov->fc, AV_LOG_DEBUG, "Offset DTS by
> ctts[%d].duration:
> > %d\n", 0, ctts_data_old[0].duration);
> > > +av_log(mov->fc, AV_LOG_DEBUG, "Shifting DTS by %d because of
> > negative CTTS.\n", msc->dts_shift);
> > > }
> >
> > The above lines were the cause of making the first frame PTS of videos
> > starting with B-frames negative. If the videos starts with B frame, then
> > the minimum composition time as computed by stts + ctts will be non-zero.
> > Hence we need to shift the DTS, so that the first pts is zero. This was
> the
> > intention of that code-block. However it was subtracting by the wrong
> > amount.
> > For example, for one of the videos in the bug nonFormatted.mp4 we have
> > stts:
> > sample_count duration
> > 960 1001
> > ctts:
> > sample_count duration
> > 1 3003
> > 2 0
> > 1 3003
> >
> >
> > The resulting composition times are : 3003, 1001, 2002, 6006, ...
> > Hence the minimum composition time or PTS is 1001, which should be used
> to
> > offset DTS. However the code block was wrongly using ctts[0] which is
> 3003
> > . Hence the PTS was negative.
> >
> > About the fate test expectations, fate-suite/h264/twofields_packet.mp4
> is a
> > similar file starting with 2 Bframes. Before this change the PTS of first
> > two B-frames was -6006 and -3003, and I am guessing one of them got
> dropped
> > when being decoded and remuxed to the framecrc before, and now it is not
> > being dropped but I dont understand why.
>
> All of this should go into the commit message.
>
> Can't judge the correctness of the actual code.
> ___
> 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 3/3] avformat: set the default whitelist to disable hls
On Tue, 6 Jun 2017, Michael Niedermayer wrote: On Mon, Jun 05, 2017 at 05:33:29PM +0200, Nicolas George wrote: Le septidi 17 prairial, an CCXXV, Michael Niedermayer a écrit : [...] You dont need to convince me that the extension check or changes within just hls are not a complete solution. Iam quite well aware of this. This is intended to stop an existing exploit and variants of it in practice and do so quickly. It depends on the severity of the threat. This one seems quite minor and far-fetched, and thus I think we could take our time to fix it properly. We all have noticed that temporary quick-and-dirty fixes usually stay here a long time unless whoever implemented them is actively working on a real fix. I disagree that the issue is minor and far fetched. Do we really want to impelment a whole security framework inside an AV library? Can't we decouple this from libav*? E.g. let the user implement his security framework via callbacks or something? We can provide a good enough reference implementation for the command line tools (outside the libraries), so things won't break too much, but if you ask me, by default, all reference openings should be disabled, that is the only truly secure thing, anything else can be insecure based on your use case. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/scale: More descriptive in/ref/out logging
On Tue, Jun 6, 2017 at 11:49 AM, Michael Niedermayer wrote: > yes but its much harder to grep for as its not a single line anymore I agree that it's not going to be as pretty a regular expression to grep through, as there is 33% more data, but it should still be doable without too much effort. How important is it that we maintain "API" compatibility on verbose CLI output? ffmpeg [...] scale2ref=0:0 [...] -v verbose - 2>&1 >/dev/null | grep -oP 'regex' Where regex is: (in|out|ref) +w:(\d+) h:(\d+) fmt:(\w+) sar:(\d+)\/(\d+)(?: flags:0x[[:xdigit:]]+)? Assuming GNU grep 2.25+, you'll get: in w:320 h:240 fmt:rgb24 sar:1/1 ref w:640 h:360 fmt:rgb24 sar:1/1 out w:640 h:360 fmt:rgb24 sar:3/4 flags:0x2 It also works with BSD grep 2.5.1-FreeBSD included in macOS if you use the -E option instead of -P. These would be considered three separate matches so if you're using a good regex engine it'd be pretty easy to loop over each match, check the first group to determine if it's in, ref, or out and act accordingly on the rest of the captured data. You could also, if you wanted, assume that the first line is in and the second line is out if you only have two matches (or lines even) and if you have three matches/lines the first is in, second is ref, third is out. If you needed it to work with less sophisticated engines it shouldn't be too hard to dumb down the regex above. Live-ish example: https://regex101.com/r/wvHLpa/1 Is there a special property that makes single lines much easier to grep? Something specific to bash? I wouldn't think bash would have any problems looping over this by line. Thanks, Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters: Correct scale doc regarding w/h <= 0
Hey Moritz, Thanks for the feedback. On Tue, Jun 6, 2017 at 7:59 AM, Moritz Barsnick wrote: > This makes it obvious that the paragraph following the one you fixed is > a bit misleading (to me): > > If one of the values is -n with n > 1, the scale filter will also > use a value that maintains the aspect ratio of the input image, > calculated from the other specified dimension. After that it will, > however, make sure that the calculated dimension is divisible by n > and adjust the value if necessary. > > This is true only if *exactly* one of the two values is "-n with n > 1". > (It also doesn't apply to "-1:-2". Good luck finding words to describe > this behavior. ;-)) Haha, you're right. The best approach seems to be involve removing the paragraph about the -1 stuff (since it's technically -n) and expand the -n paragraph to include -1. So something like: If the width value is 0, the input width is used for the output. If the height value is 0, the input height is used for the output. If one and only one of the values is -n with n >= 1, the scale filter will use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary. If both values are -n with n >= 1, the behavior will be identical to both values being set to 0 as previously detailed. - I noticed the z-scale documentation is very similar. I might need to look at that too. Thanks, Kevin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC
frame: Add av_frame_get_side_data_at() to allow retrival of multiple side
data of the same type.
---
libavcodec/mpeg12enc.c | 52 ++
libavutil/frame.c | 8
libavutil/frame.h | 38 +++-
3 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index f45598a..01fda83 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -543,6 +543,58 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
+/* MPEG closed caption user data is limited to 31 3-byte "closed
+ * caption constructs" per user data block. There can be serveral
+ * such user data blocks per frame.
+ */
+for (int i = 0;; ++i) {
+side_data = av_frame_get_side_data_at(s->current_picture_ptr->f, i);
+if (!side_data)
+break;
+
+if (side_data->type == AV_FRAME_DATA_A53_CC) {
+avpriv_align_put_bits(&s->pb);
+put_header(s, USER_START_CODE);
+
+/* ATSC user data identifier for CC or BAR data */
+put_bits(&s->pb, 8, 'G');
+put_bits(&s->pb, 8, 'A');
+put_bits(&s->pb, 8, '9');
+put_bits(&s->pb, 8, '4');
+
+/* MPEG CC data type code */
+put_bits(&s->pb, 8, 0x03);
+
+/* cc_data() {
+ * reserved (1 bits) ’1’
+ * process_cc_data_flag (1 bits) bslbf
+ * additional_data_flag (1 bits) bslbf
+ * cc_count (5 bits) uimsbf
+ * reserved (8 bits) ‘ ’
+ * for (i=0 ; i < cc_count ; ++i) {
+ * marker_bits (5 bits) ‘ 1’
+ * cc_valid(1 bits) bslbf
+ * cc_type (2 bits) bslbf
+ * cc_data_1 (8 bits) bslbf
+ * cc_data_2 (8 bits) bslbf
+ * }
+ * marker_bits (8 bits) ‘ ’
+ * if (additional_data_flag) {
+ * while (nextbits() != ‘ 0001’) {
+ * additional_cc_data
+ * }
+ * }
+ * }
+ */
+for(int j = 0; j < side_data->size; ++j) {
+put_bits(&s->pb, 8, side_data->data[j]);
+}
+
+/* Marker bits */
+put_bits(&s->pb, 8, 0xFF);
+}
+}
+
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
}
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 24d5d5f..8912f52 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -688,6 +688,14 @@ AVFrameSideData *av_frame_get_side_data(const AVFrame
*frame,
return NULL;
}
+AVFrameSideData *av_frame_get_side_data_at(const AVFrame *frame, int idx)
+{
+if (idx < frame->nb_side_data)
+return frame->side_data[idx];
+
+ return NULL;
+}
+
static int frame_copy_video(AVFrame *dst, const AVFrame *src)
{
const uint8_t *src_data[4];
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 26261d7..5503106 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -52,8 +52,39 @@ enum AVFrameSideDataType {
AV_FRAME_DATA_PANSCAN,
/**
* ATSC A53 Part 4 Closed Captions.
- * A53 CC bitstream is stored as uint8_t in AVFrameSideData.data.
+ * A53 CC bitstream (cc_data) is stored as uint8_t in AVFrameSideData.data.
* The number of bytes of CC data is AVFrameSideData.size.
+ *
+ * Data format:
+ *
+ * bslbf -- Bit string, left bit first, where “left” is the order in
+ * which bit strings are written in the Standard. Bit strings are
+ * written as a string of 1s and 0s within single quote marks,
+ * e.g. ‘1000 0001’. Blanks within a bit string are for ease of
+ * reading and have no significance
+ *
+ * uimsbf -- Unsigned integer, most significant bit first.
+ *
+ * cc_data() {
+ * reserved (1 bits) ’1’
+ * process_cc_data_flag (1 bits) bslbf
+ * additional_data_flag (1 bits) bslbf
+ * cc_count (5 bits) uimsbf
+ * reserved (8 bits) ‘ ’
+ * for (i=0 ; i < cc_count ; ++i) {
+ * marker_bits (5 bits) ‘ 1’
+ * cc_valid(1 bits) bslbf
+ * cc_type (2 bits) bslbf
+ * cc_data_1 (8 bits) bslbf
+ * cc_data_2 (8 bits) bslbf
+ * }
+ * marker_bits (8 bits) ‘ ’
+ * if (additional_data_flag) {
+ * while (nextbits() != ‘ 0001’) {
+ * additional_cc_data
+ * }
+ * }
+ * }
*/
AV_FRAME_DATA_A53_CC,
/**
@@ -759,6 +790,11 @@ AVFrameSideData *av_frame_new
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
On Tue, 6 Jun 2017, John Poet wrote: ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC frame: Add av_frame_get_side_data_at() to allow retrival of multiple side data of the same type. As far as I remember multiple side data of the same type is not something we wanted to support. Why do you need it? Can't a single AV_FRAME_DATA_A53_CC side data packet contain many CC entries? In general, split API additions and ordinary features into separate patches. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint wrote: > > On Tue, 6 Jun 2017, John Poet wrote: > >> ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC >> frame: Add av_frame_get_side_data_at() to allow retrival of multiple side >>data of the same type. > > > As far as I remember multiple side data of the same type is not something we > wanted to support. Why do you need it? Can't a single AV_FRAME_DATA_A53_CC > side data packet contain many CC entries? > Indeed, multiple entries of the same type are really a bad idea and we basically made them impossible with stream sidedata, although maybe not with frame side data yet. We should not add API for them or encourage their use. If there is a real need for multiple of the same type, maybe the type should be expanded to hold more information. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
On Tue, Jun 6, 2017 at 3:59 PM Hendrik Leppkes wrote: > On Tue, Jun 6, 2017 at 11:45 PM, Marton Balint wrote: > > > > On Tue, 6 Jun 2017, John Poet wrote: > > > >> ff_mpeg1_encode_picture_header: Add support for AV_FRAME_DATA_A53_CC > >> frame: Add av_frame_get_side_data_at() to allow retrival of multiple > side > >>data of the same type. > > > > > > As far as I remember multiple side data of the same type is not > something we > > wanted to support. Why do you need it? Can't a single > AV_FRAME_DATA_A53_CC > > side data packet contain many CC entries? > > > > Indeed, multiple entries of the same type are really a bad idea and we > basically made them impossible with stream sidedata, although maybe > not with frame side data yet. We should not add API for them or > encourage their use. > If there is a real need for multiple of the same type, maybe the type > should be expanded to hold more information. > > The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption constructs" will fit in a "block".Testing this with 1080i60 material, I found that 2 or 3 blocks was often necessary to hold all of the CC data. I tried ignoring that limit of 31 "constructs" per block, and ended up with corrupt captions. By preserving the 2 or 3 separate blocks I observed from the original source, the captions are perfect. If you would like me to go about this a different way, please give me some direction. Thank you, John ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
> > The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption > constructs" will fit in a "block".Testing this with 1080i60 material, I > found that 2 or 3 blocks was often necessary to hold all of the CC data. > > I tried ignoring that limit of 31 "constructs" per block, and ended up with > corrupt captions. By preserving the 2 or 3 separate blocks I observed > from the original source, the captions are perfect. > Odd, ATSC specifies specific bitrate requirements in this area. Are you sure your insertion process isn't bursting? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
Indeed, multiple entries of the same type are really a bad idea and we basically made them impossible with stream sidedata, although maybe not with frame side data yet. We should not add API for them or encourage their use. If there is a real need for multiple of the same type, maybe the type should be expanded to hold more information. The cc_count is only 5 bits, which mean that only 31 3-byte "closed caption constructs" will fit in a "block".Testing this with 1080i60 material, I found that 2 or 3 blocks was often necessary to hold all of the CC data. I tried ignoring that limit of 31 "constructs" per block, and ended up with corrupt captions. By preserving the 2 or 3 separate blocks I observed from the original source, the captions are perfect. According to CEA-708, in the case of 1080i60, the correct number for cc_count is 10. The highest number that cc_count is allowed to be is 30 in the case of repeating a frame three times for film mode. Exceeding the correct cc_count for the frame rate would cause the CC channel data rate to exceed 9,600bps. ~Brian ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add A53 Closed Captions to MPEG header if they are available.
On Tue, Jun 6, 2017 at 4:40 PM Kieran Kunhya wrote: > > > > The cc_count is only 5 bits, which mean that only 31 3-byte "closed > caption > > constructs" will fit in a "block".Testing this with 1080i60 > material, I > > found that 2 or 3 blocks was often necessary to hold all of the CC data. > > > > I tried ignoring that limit of 31 "constructs" per block, and ended up > with > > corrupt captions. By preserving the 2 or 3 separate blocks I observed > > from the original source, the captions are perfect. > > > > Odd, ATSC specifies specific bitrate requirements in this area. Are you > sure your insertion process isn't bursting? > > Kieran > The source is SDI with embedded 708 captions. I supposed there may be an issue there. I have not tried this with any other source. John ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" option in h26[45] vaapi encoder.
From 5c88956e36e7318cf1d1b7c41a9d4108fcf9d0a5 Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Fri, 12 May 2017 08:30:43 +0800
Subject: [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" in h26[45] vaapi
encoder.
Enable multi-slice support in AVC/HEVC vaapi encoder.
Signed-off-by: Wang, Yi A
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode.c | 36
libavcodec/vaapi_encode.h | 9 +++--
libavcodec/vaapi_encode_h264.c | 24 ++--
libavcodec/vaapi_encode_h265.c | 28 ++--
4 files changed, 79 insertions(+), 18 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 7e9c00f51d..14a3fba7b1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -36,13 +36,18 @@ static int vaapi_encode_make_packed_header(AVCodecContext
*avctx,
VAAPIEncodeContext *ctx = avctx->priv_data;
VAStatus vas;
VABufferID param_buffer, data_buffer;
+VABufferID *tmp;
VAEncPackedHeaderParameterBuffer params = {
.type = type,
.bit_length = bit_len,
.has_emulation_bytes = 1,
};
-av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
+tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp),
(pic->nb_param_buffers + 2));
+if (!tmp) {
+return AVERROR(ENOMEM);
+}
+pic->param_buffers = tmp;
vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
VAEncPackedHeaderParameterBufferType,
@@ -77,9 +82,14 @@ static int vaapi_encode_make_param_buffer(AVCodecContext
*avctx,
{
VAAPIEncodeContext *ctx = avctx->priv_data;
VAStatus vas;
+VABufferID *tmp;
VABufferID buffer;
-av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
+tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp),
(pic->nb_param_buffers + 1));
+if (!tmp) {
+return AVERROR(ENOMEM);
+}
+pic->param_buffers = tmp;
vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
type, len, 1, data, &buffer);
@@ -122,6 +132,8 @@ static int vaapi_encode_wait(AVCodecContext *avctx,
// Input is definitely finished with now.
av_frame_free(&pic->input_image);
+av_freep(&pic->param_buffers);
+
pic->encode_complete = 1;
return 0;
}
@@ -313,7 +325,10 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
}
}
-av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
+pic->slices = (VAAPIEncodeSlice **)av_malloc(sizeof(VAAPIEncodeSlice *) *
pic->nb_slices);
+if (pic->slices == NULL)
+goto fail;
+
for (i = 0; i < pic->nb_slices; i++) {
slice = av_mallocz(sizeof(*slice));
if (!slice) {
@@ -322,7 +337,6 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
}
slice->index = i;
pic->slices[i] = slice;
-
if (ctx->codec->slice_params_size > 0) {
slice->codec_slice_params =
av_mallocz(ctx->codec->slice_params_size);
if (!slice->codec_slice_params) {
@@ -427,6 +441,8 @@ fail:
vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
fail_at_end:
av_freep(&pic->codec_picture_params);
+av_freep(&pic->param_buffers);
+av_freep(&pic->slices);
av_frame_free(&pic->recon_image);
return err;
}
@@ -542,6 +558,8 @@ static int vaapi_encode_free(AVCodecContext *avctx,
av_frame_free(&pic->input_image);
av_frame_free(&pic->recon_image);
+av_freep(&pic->param_buffers);
+av_freep(&pic->slices);
// Output buffer should already be destroyed.
av_assert0(pic->output_buffer == VA_INVALID_ID);
@@ -949,6 +967,7 @@ static av_cold int
vaapi_encode_config_attributes(AVCodecContext *avctx)
{ VAConfigAttribRTFormat },
{ VAConfigAttribRateControl },
{ VAConfigAttribEncMaxRefFrames },
+{ VAConfigAttribEncMaxSlices },
{ VAConfigAttribEncPackedHeaders },
};
@@ -1079,6 +1098,15 @@ static av_cold int
vaapi_encode_config_attributes(AVCodecContext *avctx)
}
}
break;
+case VAConfigAttribEncMaxSlices:
+if (avctx->slices > attr[i].value) {
+av_log(avctx, AV_LOG_ERROR, "Slices per frame more than %#x "
+ "is not supported.\n", attr[i].value);
+err = AVERROR(EINVAL);
+goto fail;
+}
+ctx->multi_slices_available = 1;
+break;
case VAConfigAttribEncPackedHeaders:
if (ctx->va_packed_headers & ~attr[i].value) {
// This isn't fatal, but packed headers are always
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 0edf27e4cb..4afe4fa103 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -73,7 +73,7 @@ typedef struct VAAPIEncodePicture {
VASurfaceID recon_surface;
int
Re: [FFmpeg-devel] [PATCH V2] lavc/golomb: Fix UE golomb overwrite issue.
On Mon, Jun 05, 2017 at 08:43:35AM +0800, Jun Zhao wrote:
> V2: Add Add set_ue_golomb_long() to support 32bits UE golomb and update the
> unit test.
> golomb.h | 20 +++-
> put_bits.h | 35 +++
> tests/golomb.c | 19 +++
> 3 files changed, 73 insertions(+), 1 deletion(-)
> 491565dd491fc4ebd1717069d9c7655bfe0bd08a
> 0001-lavc-golomb-Fix-UE-golomb-overwrite-issue.patch
> From 6fe36e4e2a41f70e2a41c5eba90b5143b4eeba7b Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Fri, 2 Jun 2017 15:05:49 +0800
> Subject: [PATCH V2] lavc/golomb: Fix UE golomb overwrite issue.
>
> put_bits just support write up to 31 bits, when write 32 bit in
> put_bits, it's will overwrite the bit buffer, because the default
> assert level is 0, the av_assert2(n <= 31 && value < (1U << n))
> in put_bits can not be trigger runtime. Add set_ue_golomb_long()
> to support 32bits UE golomb.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/golomb.h | 20 +++-
> libavcodec/put_bits.h | 35 +++
> libavcodec/tests/golomb.c | 19 +++
> 3 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
> index 0833aff468..47ab884282 100644
> --- a/libavcodec/golomb.h
> +++ b/libavcodec/golomb.h
> @@ -458,7 +458,7 @@ static inline int get_te(GetBitContext *s, int r, char
> *file, const char *func,
> #endif /* TRACE */
>
> /**
> - * write unsigned exp golomb code.
> + * write unsigned exp golomb code. 2^16-2 at most.
> */
> static inline void set_ue_golomb(PutBitContext *pb, int i)
> {
> @@ -473,6 +473,24 @@ static inline void set_ue_golomb(PutBitContext *pb, int
> i)
> }
>
> /**
> + * write unsigned exp golomb code. 2^32-2 at most.
> + */
> +static inline void set_ue_golomb_long(PutBitContext *pb, uint32_t i)
> +{
> +av_assert2(i <= (0x - 2));
> +
> +if (i < 256)
> +put_bits(pb, ff_ue_golomb_len[i], i + 1);
> +else {
Please add {} for if else so its if { } else
> +int e = av_log2(i + 1);
> +if (e < 16)
> +put_bits(pb, 2 * e + 1, i + 1);
> +else
> +put_bits64(pb, 2 * e + 1, i + 1);
put_bits64 tests for <32 it tests for ==64 neither are possible
here. And this is a inline function so these impossible code pathes
might get duplicated many times
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V2] lavc/golomb: Fix UE golomb overwrite issue.
On 2017/6/7 9:22, Michael Niedermayer wrote:
> On Mon, Jun 05, 2017 at 08:43:35AM +0800, Jun Zhao wrote:
>> V2: Add Add set_ue_golomb_long() to support 32bits UE golomb and update the
>> unit test.
>
>> golomb.h | 20 +++-
>> put_bits.h | 35 +++
>> tests/golomb.c | 19 +++
>> 3 files changed, 73 insertions(+), 1 deletion(-)
>> 491565dd491fc4ebd1717069d9c7655bfe0bd08a
>> 0001-lavc-golomb-Fix-UE-golomb-overwrite-issue.patch
>> From 6fe36e4e2a41f70e2a41c5eba90b5143b4eeba7b Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Fri, 2 Jun 2017 15:05:49 +0800
>> Subject: [PATCH V2] lavc/golomb: Fix UE golomb overwrite issue.
>>
>> put_bits just support write up to 31 bits, when write 32 bit in
>> put_bits, it's will overwrite the bit buffer, because the default
>> assert level is 0, the av_assert2(n <= 31 && value < (1U << n))
>> in put_bits can not be trigger runtime. Add set_ue_golomb_long()
>> to support 32bits UE golomb.
>>
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/golomb.h | 20 +++-
>> libavcodec/put_bits.h | 35 +++
>> libavcodec/tests/golomb.c | 19 +++
>> 3 files changed, 73 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
>> index 0833aff468..47ab884282 100644
>> --- a/libavcodec/golomb.h
>> +++ b/libavcodec/golomb.h
>> @@ -458,7 +458,7 @@ static inline int get_te(GetBitContext *s, int r, char
>> *file, const char *func,
>> #endif /* TRACE */
>>
>> /**
>> - * write unsigned exp golomb code.
>> + * write unsigned exp golomb code. 2^16-2 at most.
>> */
>> static inline void set_ue_golomb(PutBitContext *pb, int i)
>> {
>> @@ -473,6 +473,24 @@ static inline void set_ue_golomb(PutBitContext *pb, int
>> i)
>> }
>>
>> /**
>> + * write unsigned exp golomb code. 2^32-2 at most.
>> + */
>> +static inline void set_ue_golomb_long(PutBitContext *pb, uint32_t i)
>> +{
>> +av_assert2(i <= (0x - 2));
>> +
>> +if (i < 256)
>> +put_bits(pb, ff_ue_golomb_len[i], i + 1);
>> +else {
>
> Please add {} for if else so its if { } else
>
Ok, will add {} for if.
>> +int e = av_log2(i + 1);
>> +if (e < 16)
>> +put_bits(pb, 2 * e + 1, i + 1);
>> +else
>
>> +put_bits64(pb, 2 * e + 1, i + 1);
>
> put_bits64 tests for <32 it tests for ==64 neither are possible
> here. And this is a inline function so these impossible code pathes
> might get duplicated many times
>
> [...]
I think av_assert2(i <= (0x - 2)) have cover this condition, and maybe
av_assert0(i <= (0x - 2)) is a better choice for this assert.
>
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/scale: Populate ow/oh when using 0 as w/h
The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.
Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do something like "scale=0:ow/4" which one could
reasonably expect to work as well, but does not as ow is 0 not the
real value.
This change handles the 0 case for w/h immediately so the ow/oh
variables work as expected. Consequently, the rest of the code does
not need to handle 0 input. w/h will always be > 0 or < 0.
Signed-off-by: Kevin Mark
---
libavfilter/scale.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..cc2bea5caf 100644
--- a/libavfilter/scale.c
+++ b/libavfilter/scale.c
@@ -158,19 +158,19 @@ int ff_scale_eval_dimensions(void *log_ctx,
av_expr_parse_and_eval(&res, (expr = w_expr),
names, var_values,
NULL, NULL, NULL, NULL, NULL, 0, log_ctx);
-eval_w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
+eval_w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res == 0.0 ?
inlink->w : res;
if ((ret = av_expr_parse_and_eval(&res, (expr = h_expr),
names, var_values,
NULL, NULL, NULL, NULL, NULL, 0,
log_ctx)) < 0)
goto fail;
-eval_h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res;
+eval_h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res == 0.0 ?
inlink->h : res;
/* evaluate again the width, as it may depend on the output height */
if ((ret = av_expr_parse_and_eval(&res, (expr = w_expr),
names, var_values,
NULL, NULL, NULL, NULL, NULL, 0,
log_ctx)) < 0)
goto fail;
-eval_w = res;
+eval_w = res == 0.0 ? inlink->w : res;
w = eval_w;
h = eval_h;
@@ -186,13 +186,10 @@ int ff_scale_eval_dimensions(void *log_ctx,
factor_h = -h;
}
-if (w < 0 && h < 0)
-eval_w = eval_h = 0;
-
-if (!(w = eval_w))
+if (w < 0 && h < 0) {
w = inlink->w;
-if (!(h = eval_h))
h = inlink->h;
+}
/* Make sure that the result is divisible by the factor we determined
* earlier. If no factor was set, it is nothing will happen as the default
--
2.13.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
