Re: [FFmpeg-devel] [PATCH 1/2] avutil/internal: Add ff_elog()
On Wed, 22 Feb 2017 19:16:46 +0100 Michael Niedermayerwrote: > This enables the extra error messages in case of DEBUG or high assrtion > levels. > High assertion levels imply slow checks in inner loops so any extra error > should > be insignificant. > Is it preferred to have a separate switch for ff_elog() so it doesnt depend on > DEBUG/assertion level ? > > Signed-off-by: Michael Niedermayer > --- > libavutil/internal.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/libavutil/internal.h b/libavutil/internal.h > index 7780a9a791..208f8f474f 100644 > --- a/libavutil/internal.h > +++ b/libavutil/internal.h > @@ -262,6 +262,12 @@ void avpriv_request_sample(void *avc, > # define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, > __VA_ARGS__); } while (0) > #endif > > +#if defined(DEBUG) || ASSERT_LEVEL > 1 > +# define ff_elog(ctx, ...) av_log(ctx, AV_LOG_ERROR, __VA_ARGS__) > +#else > +# define ff_elog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_ERROR, > __VA_ARGS__); } while (0) > +#endif > + > // For debuging we use signed operations so overflows can be detected (by > ubsan) > // For production we use unsigned so there are no undefined operations > #ifdef CHECKED Not really a fan of this. (And neither ff_dlog.) But I guess I don't mean to stop you. In my opinion, code that checks for overflow and fuzz issues should be as small and unintrusive as possible, or preferably not exist. It seems like all these fuzz fixes make code less readable. (Not just because of the additional logging and control flow, also because of all those unobvious tricky checks.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On 2/23/17, Michael Niedermayerwrote: > On Wed, Feb 22, 2017 at 07:40:24PM +0100, Paul B Mahol wrote: >> On 2/22/17, Michael Niedermayer wrote: >> > On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote: >> >> On 2/22/17, Michael Niedermayer wrote: >> >> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote: >> >> >> On 2/22/17, Michael Niedermayer wrote: >> >> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296 >> >> >> > >> >> >> > Found-by: continuous fuzzing process >> >> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg >> >> >> > Signed-off-by: Michael Niedermayer >> >> >> > --- >> >> >> > libavcodec/h264_ps.c | 11 +++ >> >> >> > 1 file changed, 11 insertions(+) >> >> >> > >> >> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c >> >> >> > index 8090178395..f4a4a01fbe 100644 >> >> >> > --- a/libavcodec/h264_ps.c >> >> >> > +++ b/libavcodec/h264_ps.c >> >> >> > @@ -828,6 +828,12 @@ int >> >> >> > ff_h264_decode_picture_parameter_set(GetBitContext >> >> >> > *gb, AVCodecContext *avct >> >> >> > pps->init_qp = get_se_golomb(gb) >> >> >> > + >> >> >> > 26 >> >> >> > + >> >> >> > qp_bd_offset; >> >> >> > pps->init_qs = get_se_golomb(gb) >> >> >> > + >> >> >> > 26 >> >> >> > + >> >> >> > qp_bd_offset; >> >> >> > pps->chroma_qp_index_offset[0]= >> >> >> > get_se_golomb(gb); >> >> >> > +if (pps->chroma_qp_index_offset[0] < -12 || >> >> >> > pps->chroma_qp_index_offset[0] > 12) { >> >> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] >> >> >> > %d >> >> >> > is >> >> >> >> >> >> This is nonsense. Please remove. >> >> > >> >> > Id like to keep the error messages or id like to have someone else >> >> > take over h264 maintaince in ffmpeg. >> >> >> >> Than why you are posting patches at all, if you do not want to listen >> >> to reviews. >> > >> > ive posted a patchset with ff_elog() instead >> > >> > do people prefer that ? >> > >> > [...] >> >> You could right now start adding such messages at every error path. > > ill push my patch without the error messages, i think i failed to > realize how much the error messages annoy you. You can apply elog variant if you really need it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/libx265: Add gray10 and gray12 encoding support
On 2/23/17, Carl Eugen Hoyoswrote: > Hi! > > Attached patch adds gray10 and gray12 native endian encoding support > to libx265. > > Please comment, Carl Eugen > Does this get decoded with native hevc? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/qdrw: add support for 0x0001 code
On 2/23/17, Michael Niedermayerwrote: > On Wed, Feb 22, 2017 at 09:25:04PM +0100, Paul B Mahol wrote: >> ffmpeg | branch: master | Paul B Mahol | Wed Feb 22 >> 15:32:26 2017 +0100| [fb5c9be82ea870fd0a7643214ebf8728d8e29991] | >> committer: Paul B Mahol >> >> avcodec/qdrw: add support for 0x0001 code >> >> Fixes decoding of files which sets frame width/height this way. >> >> Signed-off-by: Paul B Mahol >> >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=fb5c9be82ea870fd0a7643214ebf8728d8e29991 >> --- >> >> libavcodec/qdrw.c | 13 - >> 1 file changed, 12 insertions(+), 1 deletion(-) > > This breaks decoding of food.pct > i can upload or mail it if you dont have it I dont have it. > > thx ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit
On 2/23/17, Carl Eugen Hoyoswrote: > 2017-02-22 14:51 GMT+01:00 Paul B Mahol : >> On 2/22/17, Paul B Mahol wrote: >>> Signed-off-by: Paul B Mahol >>> --- >>> libavcodec/dnxhddec.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c >>> index 70ce264..cdbc0bc 100644 >>> --- a/libavcodec/dnxhddec.c >>> +++ b/libavcodec/dnxhddec.c >>> @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const >>> DNXHDContext >>> *ctx, >>> static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx, >>> RowContext *row, int n) >>> { >>> -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0); >>> +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0); >>> } >>> >>> static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx, >>> -- >>> 2.9.3 >>> >>> >> >> File can be found here: >> https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c > > The file does not decode here with your patch applied: > $ md5sum test.mov > 25e45b380250bb76296f623fee9d43f1 test.mov Disable edit list support. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency
On Wed, 22 Feb 2017 14:55:23 -0800 Kyle Schwarzwrote: > DeckLink depends on pthread, and is silently disabled if pthread is missing. > > Also fixes w32pthreads to support C++. > --- > > -sem_post(>semaphore); > +pthread_mutex_unlock(>mutex); > > return S_OK; > @@ -248,7 +246,7 @@ static int decklink_write_video_packet(AVFormatContext > *avctx, AVPacket *pkt) > } > > /* Always keep at most one second of frames buffered. */ > -sem_wait(>semaphore); > +pthread_cond_wait(>cond, >mutex); > > /* Schedule frame for playback. */ > hr = ctx->dlo->ScheduleVideoFrame((struct IDeckLinkVideoFrame *) frame, That doesn't really look convincing. These operations do different things. Moreover, calling pthread_mutex_unlock without a preceding pthread_mutex_lock is invalid. Calling pthread_cond_wait without locking the mutex is an error. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default
On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote: > Its been extensively tested and it gives gain for practically free, so > make it enabled by default. > > Signed-off-by: Rostislav Pehlivanov> --- > libavcodec/mjpegenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c > index cc917edb7f..03c3d0ab13 100644 > --- a/libavcodec/mjpegenc.c > +++ b/libavcodec/mjpegenc.c > @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS > { "left", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, > VE, "pred" }, > { "plane", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, > VE, "pred" }, > { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, > VE, "pred" }, > -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { > .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" > }, > +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { > .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" > }, > { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT > }, INT_MIN, INT_MAX, VE, "huffman" }, > { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL > }, INT_MIN, INT_MAX, VE, "huffman" }, > { NULL}, > -- > 2.12.0.rc1.440.g5b76565f74 ./ffmpeg -i lena.pnm -threads 2 -thread_type slice file.jpg fails with Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157 I dont think slice threads work with optimal huffman [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default
On Wed, Feb 22, 2017 at 11:03:58PM -0300, James Almer wrote: > On 2/22/2017 10:56 PM, Michael Niedermayer wrote: > > On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote: > >> Its been extensively tested and it gives gain for practically free, so > >> make it enabled by default. > >> > >> Signed-off-by: Rostislav Pehlivanov> >> --- > >> libavcodec/mjpegenc.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c > >> index cc917edb7f..03c3d0ab13 100644 > >> --- a/libavcodec/mjpegenc.c > >> +++ b/libavcodec/mjpegenc.c > >> @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS > >> { "left", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, > >> INT_MAX, VE, "pred" }, > >> { "plane", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, > >> INT_MAX, VE, "pred" }, > >> { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, > >> INT_MAX, VE, "pred" }, > >> -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, > >> { .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, > >> "huffman" }, > >> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, > >> { .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, > >> "huffman" }, > >> { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = > >> HUFFMAN_TABLE_DEFAULT }, INT_MIN, INT_MAX, VE, "huffman" }, > >> { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = > >> HUFFMAN_TABLE_OPTIMAL }, INT_MIN, INT_MAX, VE, "huffman" }, > >> { NULL}, > > > > breaks fate > > > > --- ./tests/ref/vsynth/vsynth1-amv 2017-02-20 17:22:51.769108273 +0100 > > +++ tests/data/fate/vsynth1-amv 2017-02-23 02:54:42.983732697 +0100 > > @@ -1,4 +1,4 @@ > > -9e155fcedb3b853876e9ea4233971803 *tests/data/fate/vsynth1-amv.avi > > -1365500 tests/data/fate/vsynth1-amv.avi > > -e38681b9527b6d2531942f8a176a0265 *tests/data/fate/vsynth1-amv.out.rawvideo > > -stddev: 10.07 PSNR: 28.06 MAXDIFF: 98 bytes: 7603200/ 7603200 > > +1ab7232e1948a9ae92c745b6ed1dc0b4 *tests/data/fate/vsynth1-amv.avi > > +1283516 tests/data/fate/vsynth1-amv.avi > > +58b9ac246e9888c71a7b4e502abb898b *tests/data/fate/vsynth1-amv.out.rawvideo > > +stddev: 117.66 PSNR: 6.72 MAXDIFF: 239 bytes: 7603200/ 7603200 > > Test vsynth1-amv failed. Look at tests/data/fate/vsynth1-amv.err for > > details. > > make: *** [fate-vsynth1-amv] Error 1 > > Aren't those numbers worse for that matter? yes, thats why i quoted that one there are other fate tests changing but not getting worse. the amv ones get worse IIRC [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default
On 2/22/2017 10:56 PM, Michael Niedermayer wrote: > On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote: >> Its been extensively tested and it gives gain for practically free, so >> make it enabled by default. >> >> Signed-off-by: Rostislav Pehlivanov>> --- >> libavcodec/mjpegenc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c >> index cc917edb7f..03c3d0ab13 100644 >> --- a/libavcodec/mjpegenc.c >> +++ b/libavcodec/mjpegenc.c >> @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS >> { "left", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, >> VE, "pred" }, >> { "plane", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, >> VE, "pred" }, >> { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, >> VE, "pred" }, >> -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { >> .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, >> "huffman" }, >> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { >> .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, >> "huffman" }, >> { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT >> }, INT_MIN, INT_MAX, VE, "huffman" }, >> { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL >> }, INT_MIN, INT_MAX, VE, "huffman" }, >> { NULL}, > > breaks fate > > --- ./tests/ref/vsynth/vsynth1-amv 2017-02-20 17:22:51.769108273 +0100 > +++ tests/data/fate/vsynth1-amv 2017-02-23 02:54:42.983732697 +0100 > @@ -1,4 +1,4 @@ > -9e155fcedb3b853876e9ea4233971803 *tests/data/fate/vsynth1-amv.avi > -1365500 tests/data/fate/vsynth1-amv.avi > -e38681b9527b6d2531942f8a176a0265 *tests/data/fate/vsynth1-amv.out.rawvideo > -stddev: 10.07 PSNR: 28.06 MAXDIFF: 98 bytes: 7603200/ 7603200 > +1ab7232e1948a9ae92c745b6ed1dc0b4 *tests/data/fate/vsynth1-amv.avi > +1283516 tests/data/fate/vsynth1-amv.avi > +58b9ac246e9888c71a7b4e502abb898b *tests/data/fate/vsynth1-amv.out.rawvideo > +stddev: 117.66 PSNR: 6.72 MAXDIFF: 239 bytes: 7603200/ 7603200 > Test vsynth1-amv failed. Look at tests/data/fate/vsynth1-amv.err for details. > make: *** [fate-vsynth1-amv] Error 1 Aren't those numbers worse for that matter? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default
On Wed, Feb 22, 2017 at 10:47:13PM +, Rostislav Pehlivanov wrote: > Its been extensively tested and it gives gain for practically free, so > make it enabled by default. > > Signed-off-by: Rostislav Pehlivanov> --- > libavcodec/mjpegenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c > index cc917edb7f..03c3d0ab13 100644 > --- a/libavcodec/mjpegenc.c > +++ b/libavcodec/mjpegenc.c > @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS > { "left", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, > VE, "pred" }, > { "plane", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, > VE, "pred" }, > { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, > VE, "pred" }, > -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { > .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" > }, > +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { > .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" > }, > { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT > }, INT_MIN, INT_MAX, VE, "huffman" }, > { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL > }, INT_MIN, INT_MAX, VE, "huffman" }, > { NULL}, breaks fate --- ./tests/ref/vsynth/vsynth1-amv 2017-02-20 17:22:51.769108273 +0100 +++ tests/data/fate/vsynth1-amv 2017-02-23 02:54:42.983732697 +0100 @@ -1,4 +1,4 @@ -9e155fcedb3b853876e9ea4233971803 *tests/data/fate/vsynth1-amv.avi -1365500 tests/data/fate/vsynth1-amv.avi -e38681b9527b6d2531942f8a176a0265 *tests/data/fate/vsynth1-amv.out.rawvideo -stddev: 10.07 PSNR: 28.06 MAXDIFF: 98 bytes: 7603200/ 7603200 +1ab7232e1948a9ae92c745b6ed1dc0b4 *tests/data/fate/vsynth1-amv.avi +1283516 tests/data/fate/vsynth1-amv.avi +58b9ac246e9888c71a7b4e502abb898b *tests/data/fate/vsynth1-amv.out.rawvideo +stddev: 117.66 PSNR: 6.72 MAXDIFF: 239 bytes: 7603200/ 7603200 Test vsynth1-amv failed. Look at tests/data/fate/vsynth1-amv.err for details. make: *** [fate-vsynth1-amv] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fixup! avcodec/mips: version 1 of vc1dsp optimizations for loongson mmi
On Wed, Feb 22, 2017 at 03:48:35PM +0100, Jacek Manko wrote: > --- > libavcodec/mips/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/qdrw: add support for 0x0001 code
On Wed, Feb 22, 2017 at 09:25:04PM +0100, Paul B Mahol wrote: > ffmpeg | branch: master | Paul B Mahol| Wed Feb 22 > 15:32:26 2017 +0100| [fb5c9be82ea870fd0a7643214ebf8728d8e29991] | committer: > Paul B Mahol > > avcodec/qdrw: add support for 0x0001 code > > Fixes decoding of files which sets frame width/height this way. > > Signed-off-by: Paul B Mahol > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=fb5c9be82ea870fd0a7643214ebf8728d8e29991 > --- > > libavcodec/qdrw.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) This breaks decoding of food.pct i can upload or mail it if you dont have it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support
On Wed, Feb 22, 2017 at 11:15:45PM +, Stefan _ wrote: > The rtmpdh patch was kinda (completly) broken, fixed patch is attached. > > Concerning LibreSSL: > They use OPENSSL_VERSION_NUMBER = 0x2050200fL which breaks the other > openssl code in tls_openssl.c anyway, > so LibreSSL support should probably be worried about in a different patch. > rtmpdh.c | 94 > +-- > rtmpdh.h | 13 +++- > 2 files changed, 49 insertions(+), 58 deletions(-) > 98f748d1ed2d6b28214fc053762e7b5a22073cba > 0002-rtmpdh-Stop-using-OpenSSL-provided-DH-functions-to-s.patch > From 0edf1d179824fa6400031c6d05b3f464f01abf36 Mon Sep 17 00:00:00 2001 > From: sfan5Is it intended that theres no full name in the git author field ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: fix PoC negative issue
Ping? I know the commit "eefa4b" give a fix, but I think this one more better for this issue :) On 2017/2/8 15:39, Jun Zhao wrote: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavfi: Add VAAPI deinterlacer
On 2017/2/20 1:23, Mark Thompson wrote: > (cherry picked from commit ade370a4d7eab1866b6023c91c135d27c77ca465) > (cherry picked from commit 2d518aec4c781316092be65893b47922c8f71b67) > --- > configure | 1 + > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/version.h | 2 +- cut > +AVFilter ff_vf_deinterlace_vaapi = { > +.name = "deinterlace_vaapi", > +.description= NULL_IF_CONFIG_SMALL("Deinterlacing of VAAPI > surfaces"), > +.priv_size = sizeof(DeintVAAPIContext), > +.init = _vaapi_init, > +.uninit = _vaapi_uninit, > +.query_formats = _vaapi_query_formats, > +.inputs = deint_vaapi_inputs, > +.outputs= deint_vaapi_outputs, > +.priv_class = _vaapi_class, > +}; > Tested and verified in the KBL, it's working well ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding
On Wed, 22 Feb 2017, wm4 wrote: > > Patch looks good, and I like it better than checking the codec ID. Ok, will apply soon. OK Thanks, pushed. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On Wed, Feb 22, 2017 at 07:40:24PM +0100, Paul B Mahol wrote: > On 2/22/17, Michael Niedermayerwrote: > > On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote: > >> On 2/22/17, Michael Niedermayer wrote: > >> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote: > >> >> On 2/22/17, Michael Niedermayer wrote: > >> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296 > >> >> > > >> >> > Found-by: continuous fuzzing process > >> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > >> >> > Signed-off-by: Michael Niedermayer > >> >> > --- > >> >> > libavcodec/h264_ps.c | 11 +++ > >> >> > 1 file changed, 11 insertions(+) > >> >> > > >> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c > >> >> > index 8090178395..f4a4a01fbe 100644 > >> >> > --- a/libavcodec/h264_ps.c > >> >> > +++ b/libavcodec/h264_ps.c > >> >> > @@ -828,6 +828,12 @@ int > >> >> > ff_h264_decode_picture_parameter_set(GetBitContext > >> >> > *gb, AVCodecContext *avct > >> >> > pps->init_qp = get_se_golomb(gb) + > >> >> > 26 > >> >> > + > >> >> > qp_bd_offset; > >> >> > pps->init_qs = get_se_golomb(gb) + > >> >> > 26 > >> >> > + > >> >> > qp_bd_offset; > >> >> > pps->chroma_qp_index_offset[0]= get_se_golomb(gb); > >> >> > +if (pps->chroma_qp_index_offset[0] < -12 || > >> >> > pps->chroma_qp_index_offset[0] > 12) { > >> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d > >> >> > is > >> >> > >> >> This is nonsense. Please remove. > >> > > >> > Id like to keep the error messages or id like to have someone else > >> > take over h264 maintaince in ffmpeg. > >> > >> Than why you are posting patches at all, if you do not want to listen > >> to reviews. > > > > ive posted a patchset with ff_elog() instead > > > > do people prefer that ? > > > > [...] > > You could right now start adding such messages at every error path. ill push my patch without the error messages, i think i failed to realize how much the error messages annoy you. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency
On Wed, Feb 22, 2017 at 6:55 PM, Marton Balintwrote: > > On Wed, 22 Feb 2017, Kyle Schwarz wrote: > >> DeckLink depends on pthread, and is silently disabled if pthread is >> missing. >> >> Also fixes w32pthreads to support C++. > > > You should split this into two patches, one the w32pthreads C++ support, > other the decklink patch. Would it be best to resubmit as two new threads for both, or simply split and reply to this thread? > Also, I checked the decklink part, and I am a bit confused. I don't see how > you ensure that ctx->frames_buffer number of frames are scheduled. Also, are > you sure you use the condition/mutexes properly? Your code does not even > contains a pthread_mutex_lock call, that seems odd. > > What I would expect is to protect the scheduled frame counter with a mutex, > and do a cond_signal in the scheduled frame completed callback. Or do you > have something else in mind? I'm not terribly familiar with mutex and pthread, so you're probably right. I'll look into your suggestions and come up with a revision. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/1] Add ETC1 encoder/decoder
2017-02-22 18:38 GMT+01:00 Devin Heitmueller: > This patch adds support for encoding and decoding the Ericsson Texture > Compression 1 (ETC1) format. This includes support for the PKM file > format. > > Note the actual codec uses Google's ETC1 implementation from Android > (Apache 2 licensed). Then you at least have to make sure that the code only gets compiled if both --enable-version3 and --enable-gpl were provided for configure. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency
On Wed, 22 Feb 2017, Kyle Schwarz wrote: DeckLink depends on pthread, and is silently disabled if pthread is missing. Also fixes w32pthreads to support C++. You should split this into two patches, one the w32pthreads C++ support, other the decklink patch. Also, I checked the decklink part, and I am a bit confused. I don't see how you ensure that ctx->frames_buffer number of frames are scheduled. Also, are you sure you use the condition/mutexes properly? Your code does not even contains a pthread_mutex_lock call, that seems odd. What I would expect is to protect the scheduled frame counter with a mutex, and do a cond_signal in the scheduled frame completed callback. Or do you have something else in mind? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit
2017-02-22 14:51 GMT+01:00 Paul B Mahol: > On 2/22/17, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> libavcodec/dnxhddec.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c >> index 70ce264..cdbc0bc 100644 >> --- a/libavcodec/dnxhddec.c >> +++ b/libavcodec/dnxhddec.c >> @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const DNXHDContext >> *ctx, >> static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx, >> RowContext *row, int n) >> { >> -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0); >> +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0); >> } >> >> static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx, >> -- >> 2.9.3 >> >> > > File can be found here: > https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c The file does not decode here with your patch applied: $ md5sum test.mov 25e45b380250bb76296f623fee9d43f1 test.mov $ ffmpeg -i test.mov -f null - ffmpeg version N-83619-g6a22d24 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-gpl --enable-libx265 libavutil 55. 47.100 / 55. 47.100 libavcodec 57. 81.100 / 57. 81.100 libavformat57. 66.102 / 57. 66.102 libavdevice57. 2.100 / 57. 2.100 libavfilter 6. 73.100 / 6. 73.100 libswscale 4. 3.101 / 4. 3.101 libswresample 2. 4.100 / 2. 4.100 libpostproc54. 2.100 / 54. 2.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mov': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt encoder : Lavf57.59.100 make: Atomos make-eng: Atomos Duration: 00:00:00.17, start: 0.00, bitrate: 697811 kb/s Stream #0:0(eng): Video: dnxhd (DNXHR HQX) (AVdh / 0x68645641), yuv422p10le(tv, bt709/unknown/unknown), 3840x2160, 698439 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default) Metadata: handler_name: DataHandler encoder : Avid DNxHR Codec timecode: 00:00:00:00 Stream #0:1(eng): Data: none (tmcd / 0x64636D74), 0 kb/s Metadata: handler_name: DataHandler timecode: 00:00:00:00 Output #0, null, to 'pipe:': Metadata: major_brand : qt minor_version : 512 compatible_brands: qt make-eng: Atomos make: Atomos encoder : Lavf57.66.102 Stream #0:0(eng): Video: wrapped_avframe, yuv422p10le, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc (default) Metadata: handler_name: DataHandler timecode: 00:00:00:00 encoder : Lavc57.81.100 wrapped_avframe Stream mapping: Stream #0:0 -> #0:0 (dnxhd (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help frame=0 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= 0x video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency
Indeed, an unintended change. 644 is preferred. On Wed, Feb 22, 2017 at 6:26 PM, Ricardo Constantinowrote: > On 22 February 2017 at 22:55, Kyle Schwarz wrote: > > > DeckLink depends on pthread, and is silently disabled if pthread is > > missing. > > > > Also fixes w32pthreads to support C++. > > --- > > compat/w32pthreads.h| 31 +++ > > configure | 4 ++-- > > libavdevice/decklink_common.cpp | 3 --- > > libavdevice/decklink_common.h | 4 +++- > > libavdevice/decklink_dec.cpp| 3 --- > > libavdevice/decklink_enc.cpp| 14 ++ > > 6 files changed, 30 insertions(+), 29 deletions(-) > > mode change 100644 => 100755 compat/w32pthreads.h > > mode change 100644 => 100755 libavdevice/decklink_common.cpp > > mode change 100644 => 100755 libavdevice/decklink_common.h > > mode change 100644 => 100755 libavdevice/decklink_dec.cpp > > mode change 100644 => 100755 libavdevice/decklink_enc.cpp > > > > > These modes are probably unintended? > ___ > 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/decklink: Remove pthread dependency
2017-02-22 23:55 GMT+01:00 Kyle Schwarz: > DeckLink depends on pthread, and is silently disabled if pthread is missing. > Also fixes w32pthreads to support C++. Please make this a separate patch. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/libx265: Add gray10 and gray12 encoding support
Hi! Attached patch adds gray10 and gray12 native endian encoding support to libx265. Please comment, Carl Eugen From f3ce6a1bfc6a5d3201541d51fc4547b1b0b555f8 Mon Sep 17 00:00:00 2001 From: Carl Eugen HoyosDate: Thu, 23 Feb 2017 00:28:22 +0100 Subject: [PATCH] lavc/libx265: Add gray10 and gray12 encoding support. --- libavcodec/libx265.c |5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c index f9b287e..5ca937a 100644 --- a/libavcodec/libx265.c +++ b/libavcodec/libx265.c @@ -167,6 +167,8 @@ static av_cold int libx265_encode_init(AVCodecContext *avctx) ctx->params->internalCsp = X265_CSP_I444; break; case AV_PIX_FMT_GRAY8: +case AV_PIX_FMT_GRAY10: +case AV_PIX_FMT_GRAY12: if (ctx->api->api_build_number < 85) { av_log(avctx, AV_LOG_ERROR, "libx265 version is %d, must be at least 85 for gray encoding.\n", @@ -349,6 +351,7 @@ static const enum AVPixelFormat x265_csp_ten[] = { AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10, AV_PIX_FMT_GBRP10, +AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE }; @@ -366,6 +369,8 @@ static const enum AVPixelFormat x265_csp_twelve[] = { AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV444P12, AV_PIX_FMT_GBRP12, +AV_PIX_FMT_GRAY12, +AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE }; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency
On 22 February 2017 at 22:55, Kyle Schwarzwrote: > DeckLink depends on pthread, and is silently disabled if pthread is > missing. > > Also fixes w32pthreads to support C++. > --- > compat/w32pthreads.h| 31 +++ > configure | 4 ++-- > libavdevice/decklink_common.cpp | 3 --- > libavdevice/decklink_common.h | 4 +++- > libavdevice/decklink_dec.cpp| 3 --- > libavdevice/decklink_enc.cpp| 14 ++ > 6 files changed, 30 insertions(+), 29 deletions(-) > mode change 100644 => 100755 compat/w32pthreads.h > mode change 100644 => 100755 libavdevice/decklink_common.cpp > mode change 100644 => 100755 libavdevice/decklink_common.h > mode change 100644 => 100755 libavdevice/decklink_dec.cpp > mode change 100644 => 100755 libavdevice/decklink_enc.cpp > > These modes are probably unintended? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/decklink: Remove pthread dependency
DeckLink depends on pthread, and is silently disabled if pthread is missing. Also fixes w32pthreads to support C++. --- compat/w32pthreads.h| 31 +++ configure | 4 ++-- libavdevice/decklink_common.cpp | 3 --- libavdevice/decklink_common.h | 4 +++- libavdevice/decklink_dec.cpp| 3 --- libavdevice/decklink_enc.cpp| 14 ++ 6 files changed, 30 insertions(+), 29 deletions(-) mode change 100644 => 100755 compat/w32pthreads.h mode change 100644 => 100755 libavdevice/decklink_common.cpp mode change 100644 => 100755 libavdevice/decklink_common.h mode change 100644 => 100755 libavdevice/decklink_dec.cpp mode change 100644 => 100755 libavdevice/decklink_enc.cpp diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h old mode 100644 new mode 100755 index 4ac2a99..45c565a --- a/compat/w32pthreads.h +++ b/compat/w32pthreads.h @@ -77,7 +77,7 @@ typedef struct pthread_cond_t { static av_unused unsigned __stdcall attribute_align_arg win32thread_worker(void *arg) { -pthread_t *h = arg; +pthread_t *h = (pthread_t*)arg; h->ret = h->func(h->arg); return 0; } @@ -270,7 +270,7 @@ static av_unused int pthread_cond_init(pthread_cond_t *cond, const void *unused_ } /* non native condition variables */ -win32_cond = av_mallocz(sizeof(win32_cond_t)); +win32_cond = (win32_cond_t*)av_mallocz(sizeof(win32_cond_t)); if (!win32_cond) return ENOMEM; cond->Ptr = win32_cond; @@ -288,7 +288,7 @@ static av_unused int pthread_cond_init(pthread_cond_t *cond, const void *unused_ static av_unused int pthread_cond_destroy(pthread_cond_t *cond) { -win32_cond_t *win32_cond = cond->Ptr; +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr; /* native condition variables do not destroy */ if (cond_init) return 0; @@ -305,7 +305,7 @@ static av_unused int pthread_cond_destroy(pthread_cond_t *cond) static av_unused int pthread_cond_broadcast(pthread_cond_t *cond) { -win32_cond_t *win32_cond = cond->Ptr; +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr; int have_waiter; if (cond_broadcast) { @@ -337,7 +337,7 @@ static av_unused int pthread_cond_broadcast(pthread_cond_t *cond) static av_unused int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex) { -win32_cond_t *win32_cond = cond->Ptr; +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr; int last_waiter; if (cond_wait) { cond_wait(cond, mutex, INFINITE); @@ -369,7 +369,7 @@ static av_unused int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mu static av_unused int pthread_cond_signal(pthread_cond_t *cond) { -win32_cond_t *win32_cond = cond->Ptr; +win32_cond_t *win32_cond = (win32_cond_t*)cond->Ptr; int have_waiter; if (cond_signal) { cond_signal(cond); @@ -397,20 +397,27 @@ static av_unused int pthread_cond_signal(pthread_cond_t *cond) static av_unused void w32thread_init(void) { #if _WIN32_WINNT < 0x0600 +typedef void (*init_cond_var)(pthread_cond_t*); +typedef void (*wake_all_cond_var)(pthread_cond_t*); +typedef void (*wake_cond_var)(pthread_cond_t*); +typedef BOOL (*sleep_cond_var)(pthread_cond_t*, pthread_mutex_t*, DWORD); +typedef BOOL (*init_once_begin_init)(pthread_once_t*, DWORD, BOOL*, void**); +typedef BOOL (*init_once_complete)(pthread_once_t*, DWORD, void*); + HANDLE kernel_dll = GetModuleHandle(TEXT("kernel32.dll")); /* if one is available, then they should all be available */ cond_init = -(void*)GetProcAddress(kernel_dll, "InitializeConditionVariable"); +(init_cond_var)GetProcAddress((HMODULE)kernel_dll, "InitializeConditionVariable"); cond_broadcast = -(void*)GetProcAddress(kernel_dll, "WakeAllConditionVariable"); +(wake_all_cond_var)GetProcAddress((HMODULE)kernel_dll, "WakeAllConditionVariable"); cond_signal= -(void*)GetProcAddress(kernel_dll, "WakeConditionVariable"); +(wake_cond_var)GetProcAddress((HMODULE)kernel_dll, "WakeConditionVariable"); cond_wait = -(void*)GetProcAddress(kernel_dll, "SleepConditionVariableCS"); +(sleep_cond_var)GetProcAddress((HMODULE)kernel_dll, "SleepConditionVariableCS"); initonce_begin = -(void*)GetProcAddress(kernel_dll, "InitOnceBeginInitialize"); +(init_once_begin_init)GetProcAddress((HMODULE)kernel_dll, "InitOnceBeginInitialize"); initonce_complete = -(void*)GetProcAddress(kernel_dll, "InitOnceComplete"); +(init_once_complete)GetProcAddress((HMODULE)kernel_dll, "InitOnceComplete"); #endif } diff --git a/configure b/configure index 6431313..ab9e005 100755 --- a/configure +++ b/configure @@ -2977,9 +2977,9 @@ avfoundation_indev_extralibs="-framework CoreVideo -framework Foundation -framew avfoundation_indev_select="avfoundation"
Re: [FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support
The rtmpdh patch was kinda (completly) broken, fixed patch is attached. Concerning LibreSSL: They use OPENSSL_VERSION_NUMBER = 0x2050200fL which breaks the other openssl code in tls_openssl.c anyway, so LibreSSL support should probably be worried about in a different patch. From 0edf1d179824fa6400031c6d05b3f464f01abf36 Mon Sep 17 00:00:00 2001 From: sfan5Date: Wed, 22 Feb 2017 15:38:16 +0100 Subject: [PATCH 2/2] rtmpdh: Stop using OpenSSL-provided DH functions to support 1.1.0 DH (struct dh_st) was made private in the 1.1 series, instead DH is now done the same way as with gcrypt / libgmp. --- libavformat/rtmpdh.c | 94 libavformat/rtmpdh.h | 13 +++- 2 files changed, 49 insertions(+), 58 deletions(-) diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c index 1876fd44f9..1ec1286d23 100644 --- a/libavformat/rtmpdh.c +++ b/libavformat/rtmpdh.c @@ -54,7 +54,6 @@ "F71C35FDAD44CFD2D74F9208BE258FF324943328F67329C0" \ "" -#if CONFIG_GMP || CONFIG_GCRYPT #if CONFIG_GMP #define bn_new(bn) \ do {\ @@ -93,7 +92,11 @@ else\ ret = 1;\ } while (0) -#define bn_modexp(bn, y, q, p) mpz_powm(bn, y, q, p) +#define bn_modexp(bn, y, q, p, ret) \ +do {\ +mpz_powm(bn, y, q, p); \ +ret = 1;\ +} while(0) #define bn_random(bn, num_bits) \ do { \ int bits = num_bits; \ @@ -125,8 +128,34 @@ #define bn_bn2bin(bn, buf, len) gcry_mpi_print(GCRYMPI_FMT_USG, buf, len, NULL, bn) #define bn_bin2bn(bn, buf, len) gcry_mpi_scan(, GCRYMPI_FMT_USG, buf, len, NULL) #define bn_hex2bn(bn, buf, ret) ret = (gcry_mpi_scan(, GCRYMPI_FMT_HEX, buf, 0, 0) == 0) -#define bn_modexp(bn, y, q, p) gcry_mpi_powm(bn, y, q, p) +#define bn_modexp(bn, y, q, p, ret) \ +do {\ +cry_mpi_powm(bn, y, q, p); \ +ret = 1;\ +} while (0) #define bn_random(bn, num_bits) gcry_mpi_randomize(bn, num_bits, GCRY_WEAK_RANDOM) +#elif CONFIG_OPENSSL +#define bn_new(bn) bn = BN_new() +#define bn_free(bn) BN_free(bn) +#define bn_set_word(bn, w) BN_set_word(bn, w) +#define bn_cmp(a, b)BN_cmp(a, b) +#define bn_copy(to, from) BN_copy(to, from) +#define bn_sub_word(bn, w) BN_sub_word(bn, w) +#define bn_cmp_1(bn)BN_cmp(bn, BN_value_one()) +#define bn_num_bytes(bn)BN_num_bytes(bn) +#define bn_bn2bin(bn, buf, len) BN_bn2bin(bn, buf) +#define bn_bin2bn(bn, buf, len) bn = BN_bin2bn(buf, len, 0) +#define bn_hex2bn(bn, buf, ret) ret = BN_hex2bn(, buf) +#define bn_modexp(bn, y, q, p, ret) \ +do { \ +BN_CTX *ctx = BN_CTX_new(); \ +if (!ctx)\ +ret = 0; \ +else \ +ret = BN_mod_exp(bn, y, q, p, ctx); \ +BN_CTX_free(ctx);\ +} while (0) +#define bn_random(bn, num_bits)BN_rand(bn, num_bits, 0, 0) #endif #define MAX_BYTES 18000 @@ -135,7 +164,7 @@ static FFBigNum dh_generate_key(FF_DH *dh) { -int num_bytes; +int num_bytes, ret; num_bytes = bn_num_bytes(dh->p) - 1; if (num_bytes <= 0 || num_bytes > MAX_BYTES) @@ -152,7 +181,9 @@ static FFBigNum dh_generate_key(FF_DH *dh) return NULL; } -bn_modexp(dh->pub_key, dh->g, dh->priv_key, dh->p); +bn_modexp(dh->pub_key, dh->g, dh->priv_key, dh->p, ret); +if (!ret) +return NULL; return dh->pub_key; } @@ -161,12 +192,15 @@ static int dh_compute_key(FF_DH *dh, FFBigNum pub_key_bn, uint32_t secret_key_len, uint8_t *secret_key) { FFBigNum k; +int ret; bn_new(k); if (!k) return -1; -bn_modexp(k, pub_key_bn, dh->priv_key, dh->p); +bn_modexp(k, pub_key_bn, dh->priv_key, dh->p, ret); +if (!ret) +return -1; bn_bn2bin(k, secret_key, secret_key_len); bn_free(k); @@ -184,53 +218,11 @@ void ff_dh_free(FF_DH *dh) bn_free(dh->priv_key); av_free(dh); } -#elif CONFIG_OPENSSL -#define bn_new(bn) bn = BN_new() -#define bn_free(bn) BN_free(bn) -#define bn_set_word(bn, w) BN_set_word(bn, w) -#define bn_cmp(a, b)BN_cmp(a, b) -#define bn_copy(to, from) BN_copy(to, from) -#define bn_sub_word(bn, w) BN_sub_word(bn, w) -#define bn_cmp_1(bn)BN_cmp(bn, BN_value_one()) -#define bn_num_bytes(bn)
[FFmpeg-devel] [PATCH] mjpegenc: make optimal huffman coding the default
Its been extensively tested and it gives gain for practically free, so make it enabled by default. Signed-off-by: Rostislav Pehlivanov--- libavcodec/mjpegenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c index cc917edb7f..03c3d0ab13 100644 --- a/libavcodec/mjpegenc.c +++ b/libavcodec/mjpegenc.c @@ -444,7 +444,7 @@ FF_MPV_COMMON_OPTS { "left", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, INT_MIN, INT_MAX, VE, "pred" }, { "plane", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, INT_MIN, INT_MAX, VE, "pred" }, { "median", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, INT_MIN, INT_MAX, VE, "pred" }, -{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { .i64 = HUFFMAN_TABLE_DEFAULT }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" }, +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT, { .i64 = HUFFMAN_TABLE_OPTIMAL }, 0, NB_HUFFMAN_TABLE_OPTION - 1, VE, "huffman" }, { "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_DEFAULT }, INT_MIN, INT_MAX, VE, "huffman" }, { "optimal", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = HUFFMAN_TABLE_OPTIMAL }, INT_MIN, INT_MAX, VE, "huffman" }, { NULL}, -- 2.12.0.rc1.440.g5b76565f74 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avdevice/decklink_dec: remove AVFMT_RAWPICTURE
It has no effect for input devices. Signed-off-by: Marton Balint--- libavdevice/decklink_dec_c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c index 543d16b..31818d2 100644 --- a/libavdevice/decklink_dec_c.c +++ b/libavdevice/decklink_dec_c.c @@ -77,7 +77,7 @@ static const AVClass decklink_demuxer_class = { AVInputFormat ff_decklink_demuxer = { .name = "decklink", .long_name = NULL_IF_CONFIG_SMALL("Blackmagic DeckLink input"), -.flags = AVFMT_NOFILE | AVFMT_RAWPICTURE, +.flags = AVFMT_NOFILE, .priv_class = _demuxer_class, .priv_data_size = sizeof(struct decklink_cctx), .read_header = ff_decklink_read_header, -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175
On Wed, 22 Feb 2017, 21:39 Rostislav Pehlivanov,wrote: > On 22 February 2017 at 20:18, Damien Riegel < > damien.rie...@savoirfairelinux.com> wrote: > > > On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote: > > > Hi, > > > > > > On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote: > > > > > > > > > > No, do this in libavfilter and do not introduce another useless > > pseudo > > > > > codec > > > > > > > > > > > > > *libavformat, sorry > > > > > > The advantage of using a pseudo codec just to depack the stream is that > > > the input and the codec are in separate threads in ffmpeg, so it can > > > handle a heavier workload. > > > > Please find attached a v2, with the implementation in libavformat. Note > > that I don't want to send it as a patch of its own because the > > performance issue is not addressed. > > > > Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p > > at 60fps. With the pseudo-codec, we are able to transcode it to h264 and > > dump it to a file. With unpacking done in the libavformat, the input > > thread gets too busy and can't stand the load. > > > > In the implementation you made [1] unpacking was done in libavcodec, so > > why is it not an acceptable solution for mainline? > > > > > I now think it was ok to have a custom codec format because V210 is > implemented in such a way in lavc. So I think the first version of your > patch was better. You just didn't bother to list a valid reason besides > "offload it to another thread" and I didn't think of V210 at the time. > libavformat has no support for assembly so putting the unpacking there > would be slower too. I suggest posting a v3 of the patch which is like v1 > (but please rename the codec name to something better) and which uses the > assembly for unpacking from the repository you linked. > > PS: In that repo its _not_ done in lavc and it was never done in lavc, the > point was to use lavc's assembly framework so that if you linked to it and > used the private functions you'd be able to use them _outside_ of lavc. > This was because upipe, which is something made to handle the stinkiest > kind of crap broadcasting people invent because ffmpeg couldn't (and it > absolutely doesn't have to), didn't have any support for assembly. > Eventually support for that was added and everything from the repo plus > more has been implemented there. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Further to what Rostislav said, please mark this as experimental. You're not going to be able to do more than one stream for architectural reasons and I don't want people blaming FFmpeg. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avdevice/decklink_enc: convert AVFMT_RAWPICTURE to AV_CODEC_ID_WRAPPED_AVFRAME
Signed-off-by: Marton Balint--- libavdevice/decklink_enc.cpp | 78 +--- libavdevice/decklink_enc_c.c | 4 +-- libavdevice/version.h| 4 +-- 3 files changed, 42 insertions(+), 44 deletions(-) diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp index 8fb6a9c..8892d19 100644 --- a/libavdevice/decklink_enc.cpp +++ b/libavdevice/decklink_enc.cpp @@ -28,6 +28,7 @@ extern "C" { #include "libavformat/avformat.h" #include "libavformat/internal.h" #include "libavutil/imgutils.h" +#include "libavutil/atomic.h" } #include "decklink_common.h" @@ -38,33 +39,43 @@ extern "C" { class decklink_frame : public IDeckLinkVideoFrame { public: -decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, long width, - long height, void *buffer) : - _ctx(ctx), _avframe(avframe), _width(width), - _height(height), _buffer(buffer), _refs(0) { } - -virtual long STDMETHODCALLTYPE GetWidth (void) { return _width; } -virtual long STDMETHODCALLTYPE GetHeight (void) { return _height; } -virtual long STDMETHODCALLTYPE GetRowBytes (void) { return _width<<1; } +decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe) : + _ctx(ctx), _avframe(avframe), _refs(1) { } + +virtual long STDMETHODCALLTYPE GetWidth (void) { return _avframe->width; } +virtual long STDMETHODCALLTYPE GetHeight (void) { return _avframe->height; } +virtual long STDMETHODCALLTYPE GetRowBytes (void) { return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] : _avframe->linesize[0]; } virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void) { return bmdFormat8BitYUV; } -virtual BMDFrameFlags STDMETHODCALLTYPE GetFlags (void) { return bmdVideoOutputFlagDefault; } -virtual HRESULTSTDMETHODCALLTYPE GetBytes (void **buffer) { *buffer = _buffer; return S_OK; } +virtual BMDFrameFlags STDMETHODCALLTYPE GetFlags (void) { return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical : bmdFrameFlagDefault; } +virtual HRESULTSTDMETHODCALLTYPE GetBytes (void **buffer) +{ +if (_avframe->linesize[0] < 0) +*buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] * (_avframe->height - 1)); +else +*buffer = (void *)(_avframe->data[0]); +return S_OK; +} virtual HRESULT STDMETHODCALLTYPE GetTimecode (BMDTimecodeFormat format, IDeckLinkTimecode **timecode) { return S_FALSE; } virtual HRESULT STDMETHODCALLTYPE GetAncillaryData(IDeckLinkVideoFrameAncillary **ancillary) { return S_FALSE; } virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID iid, LPVOID *ppv) { return E_NOINTERFACE; } -virtual ULONG STDMETHODCALLTYPE AddRef(void) { return ++_refs; } -virtual ULONG STDMETHODCALLTYPE Release(void) { if (!--_refs) {delete this; return 0;} return _refs; } +virtual ULONG STDMETHODCALLTYPE AddRef(void) { return avpriv_atomic_int_add_and_fetch(&_refs, 1); } +virtual ULONG STDMETHODCALLTYPE Release(void) +{ +int ret = avpriv_atomic_int_add_and_fetch(&_refs, -1); +if (!ret) { +av_frame_free(&_avframe); +delete this; +} +return ret; +} struct decklink_ctx *_ctx; AVFrame *_avframe; private: -long _width; -long _height; -void *_buffer; -int _refs; +volatile int _refs; }; class decklink_output_callback : public IDeckLinkVideoOutputCallback @@ -76,7 +87,7 @@ public: struct decklink_ctx *ctx = frame->_ctx; AVFrame *avframe = frame->_avframe; -av_frame_free(); +av_frame_unref(avframe); sem_post(>semaphore); @@ -209,41 +220,27 @@ static int decklink_write_video_packet(AVFormatContext *avctx, AVPacket *pkt) { struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data; struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx; -AVPicture *avpicture = (AVPicture *) pkt->data; -AVFrame *avframe, *tmp; +AVFrame *avframe, *tmp = (AVFrame *)pkt->data; decklink_frame *frame; buffercount_type buffered; HRESULT hr; -/* HACK while av_uncoded_frame() isn't implemented */ -int ret; - -tmp = av_frame_alloc(); -if (!tmp) -return AVERROR(ENOMEM); -tmp->format = AV_PIX_FMT_UYVY422; -tmp->width = ctx->bmd_width; -tmp->height = ctx->bmd_height; -ret = av_frame_get_buffer(tmp, 32); -if (ret < 0) { -av_frame_free(); -return ret; +if (tmp->format != AV_PIX_FMT_UYVY422 || +tmp->width != ctx->bmd_width || +
[FFmpeg-devel] [PATCH 2/4] avdevice/decklink_enc: add support to specify field order
Signed-off-by: Marton Balint--- doc/outdevs.texi| 4 ++-- libavdevice/decklink_common.cpp | 29 +++-- libavdevice/decklink_common.h | 2 +- libavdevice/decklink_enc.cpp| 4 ++-- libavdevice/version.h | 2 +- 5 files changed, 29 insertions(+), 12 deletions(-) diff --git a/doc/outdevs.texi b/doc/outdevs.texi index e68653f..df41cc8 100644 --- a/doc/outdevs.texi +++ b/doc/outdevs.texi @@ -131,8 +131,8 @@ and @code{--extra-ldflags}. On Windows, you need to run the IDL files through @command{widl}. DeckLink is very picky about the formats it supports. Pixel format is always -uyvy422, framerate and video size must be determined for your device with -@command{-list_formats 1}. Audio sample rate is always 48 kHz. +uyvy422, framerate, field order and video size must be determined for your +device with @command{-list_formats 1}. Audio sample rate is always 48 kHz. @subsection Options diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp index a3bc58d..92b4545 100644 --- a/libavdevice/decklink_common.cpp +++ b/libavdevice/decklink_common.cpp @@ -130,9 +130,23 @@ static int decklink_select_input(AVFormatContext *avctx, BMDDeckLinkConfiguratio return 0; } +static DECKLINK_BOOL field_order_eq(enum AVFieldOrder field_order, BMDFieldDominance bmd_field_order) +{ +if (field_order == AV_FIELD_UNKNOWN) +return true; +if (field_order == AV_FIELD_TT && bmd_field_order == bmdUpperFieldFirst) +return true; +if (field_order == AV_FIELD_BB && bmd_field_order == bmdLowerFieldFirst) +return true; +if (field_order == AV_FIELD_PROGRESSIVE && (bmd_field_order == bmdProgressiveFrame || bmd_field_order == bmdProgressiveSegmentedFrame)) +return true; +return false; +} + int ff_decklink_set_format(AVFormatContext *avctx, int width, int height, int tb_num, int tb_den, + enum AVFieldOrder field_order, decklink_direction_t direction, int num) { struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data; @@ -143,8 +157,8 @@ int ff_decklink_set_format(AVFormatContext *avctx, int i = 1; HRESULT res; -av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, frame timing %d/%d, direction %d, mode number %d\n", -width, height, tb_num, tb_den, direction, num); +av_log(avctx, AV_LOG_DEBUG, "Trying to find mode for frame size %dx%d, frame timing %d/%d, field order %d, direction %d, mode number %d\n", +width, height, tb_num, tb_den, field_order, direction, num); if (ctx->duplex_mode) { DECKLINK_BOOL duplex_supported = false; @@ -187,18 +201,21 @@ int ff_decklink_set_format(AVFormatContext *avctx, BMDTimeValue bmd_tb_num, bmd_tb_den; int bmd_width = mode->GetWidth(); int bmd_height = mode->GetHeight(); +BMDFieldDominance bmd_field_dominance = mode->GetFieldDominance(); mode->GetFrameRate(_tb_num, _tb_den); AVRational mode_tb = av_make_q(bmd_tb_num, bmd_tb_den); -if ((bmd_width == width && bmd_height == height && -!av_cmp_q(mode_tb, target_tb)) || i == num) { +if ((bmd_width == width && + bmd_height == height && + !av_cmp_q(mode_tb, target_tb) && + field_order_eq(field_order, bmd_field_dominance)) || i == num) { ctx->bmd_mode = mode->GetDisplayMode(); ctx->bmd_width = bmd_width; ctx->bmd_height = bmd_height; ctx->bmd_tb_den = bmd_tb_den; ctx->bmd_tb_num = bmd_tb_num; -ctx->bmd_field_dominance = mode->GetFieldDominance(); +ctx->bmd_field_dominance = bmd_field_dominance; av_log(avctx, AV_LOG_INFO, "Found Decklink mode %d x %d with rate %.2f%s\n", bmd_width, bmd_height, 1/av_q2d(mode_tb), (ctx->bmd_field_dominance==bmdLowerFieldFirst || ctx->bmd_field_dominance==bmdUpperFieldFirst)?"(i)":""); @@ -230,7 +247,7 @@ int ff_decklink_set_format(AVFormatContext *avctx, } int ff_decklink_set_format(AVFormatContext *avctx, decklink_direction_t direction, int num) { -return ff_decklink_set_format(avctx, 0, 0, 0, 0, direction, num); +return ff_decklink_set_format(avctx, 0, 0, 0, 0, AV_FIELD_UNKNOWN, direction, num); } int ff_decklink_list_devices(AVFormatContext *avctx) diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h index bfa2b08..4753287 100644 --- a/libavdevice/decklink_common.h +++ b/libavdevice/decklink_common.h @@ -128,7 +128,7 @@ static const BMDVideoConnection decklink_video_connection_map[] = { }; HRESULT ff_decklink_get_display_name(IDeckLink *This, const char **displayName); -int ff_decklink_set_format(AVFormatContext *avctx, int width, int height, int tb_num, int
[FFmpeg-devel] [PATCH 1/4] avdevice/decklink_enc: convert to codecpar
Signed-off-by: Marton Balint--- libavdevice/decklink_enc.cpp | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp index ad00224..944e9d3 100644 --- a/libavdevice/decklink_enc.cpp +++ b/libavdevice/decklink_enc.cpp @@ -92,20 +92,20 @@ static int decklink_setup_video(AVFormatContext *avctx, AVStream *st) { struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data; struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx; -AVCodecContext *c = st->codec; +AVCodecParameters *c = st->codecpar; if (ctx->video) { av_log(avctx, AV_LOG_ERROR, "Only one video stream is supported!\n"); return -1; } -if (c->pix_fmt != AV_PIX_FMT_UYVY422) { +if (c->format != AV_PIX_FMT_UYVY422) { av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!" " Only AV_PIX_FMT_UYVY422 is supported.\n"); return -1; } if (ff_decklink_set_format(avctx, c->width, c->height, -c->time_base.num, c->time_base.den)) { +st->time_base.num, st->time_base.den)) { av_log(avctx, AV_LOG_ERROR, "Unsupported video size or framerate!" " Check available formats with -list_formats 1.\n"); return -1; @@ -121,8 +121,8 @@ static int decklink_setup_video(AVFormatContext *avctx, AVStream *st) ctx->dlo->SetScheduledFrameCompletionCallback(ctx->output_callback); /* Start video semaphore. */ -ctx->frames_preroll = c->time_base.den * ctx->preroll; -if (c->time_base.den > 1000) +ctx->frames_preroll = st->time_base.den * ctx->preroll; +if (st->time_base.den > 1000) ctx->frames_preroll /= 1000; /* Buffer twice as many frames as the preroll. */ @@ -131,7 +131,7 @@ static int decklink_setup_video(AVFormatContext *avctx, AVStream *st) sem_init(>semaphore, 0, ctx->frames_buffer); /* The device expects the framerate to be fixed. */ -avpriv_set_pts_info(st, 64, c->time_base.num, c->time_base.den); +avpriv_set_pts_info(st, 64, st->time_base.num, st->time_base.den); ctx->video = 1; @@ -142,7 +142,7 @@ static int decklink_setup_audio(AVFormatContext *avctx, AVStream *st) { struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data; struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx; -AVCodecContext *c = st->codec; +AVCodecParameters *c = st->codecpar; if (ctx->audio) { av_log(avctx, AV_LOG_ERROR, "Only one audio stream is supported!\n"); @@ -352,7 +352,7 @@ av_cold int ff_decklink_write_header(AVFormatContext *avctx) ret = AVERROR(EIO); for (n = 0; n < avctx->nb_streams; n++) { AVStream *st = avctx->streams[n]; -AVCodecContext *c = st->codec; +AVCodecParameters *c = st->codecpar; if(c->codec_type == AVMEDIA_TYPE_AUDIO) { if (decklink_setup_audio(avctx, st)) goto error; @@ -380,9 +380,9 @@ int ff_decklink_write_packet(AVFormatContext *avctx, AVPacket *pkt) ctx->last_pts = FFMAX(ctx->last_pts, pkt->pts); -if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO) +if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) return decklink_write_video_packet(avctx, pkt); -else if (st->codec->codec_type == AVMEDIA_TYPE_AUDIO) +else if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) return decklink_write_audio_packet(avctx, pkt); return AVERROR(EIO); -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support
On 22 February 2017 at 15:17, Stefan _wrote: > 1) configure only looks for OPENSSL_init_ssl using pkg-config, this > breaks in case pkg-config is not available (cross-compiling) > > > 2) The rtmpdh code uses the DH struct from OpenSSL which was made > private in the 1.1 series > > Any idea if this works with LibreSSL? They use OPENSSL_VERSION_NUMBER >= 0x101fL but don't necessarily support anything that OpenSSL >1.1.0 does. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test
oops forgot to reply to all, this one went only to thomas by mistake On Tue, Feb 21, 2017 at 08:12:57PM -0800, Thomas Turner wrote: > > > On 02/17/2017 02:15 PM, Michael Niedermayer wrote: > > On Thu, Feb 16, 2017 at 08:29:38PM -0800, Thomas Turner wrote: > >> The Chen-Shapiro(CS) test was used to test normality for > >> Lagged Fibonacci PRNG. > >> > >> Normality Hypothesis Test: > >> > >> The null hypothesis formally tests if the population > >> the sample represents is normally-distributed. For > >> CS, when the normality hypothesis is True, the > >> distribution of QH will have a mean close to 1. > >> > >> Information on CS can be found here: > >> > >> http://www.stata-journal.com/sjpdf.html?articlenum=st0264 > >> http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm > >> > >> Signed-off-by: Thomas Turner> >> --- > >> libavutil/tests/lfg.c| 170 ++-- > >> tests/fate/libavutil.mak |4 + > >> tests/ref/fate/lfg | 1007 > >> ++ > >> 3 files changed, 1157 insertions(+), 24 deletions(-) > >> create mode 100644 tests/ref/fate/lfg > > > > works on x86_64 linux but fails on x86_32 > > What if we force gcc compiler to use IEEE 754 floating-point semantics...Will > adding the following gcc compilation flags to ffmpeg configuration allow the > test to pass? : -msse2 -mfpmath=sse there is no gurantee that the hardware this runs on supports sse nor that the compiler is gcc C has a somewhat loose definition of floating point operations, that allows C compilers to perform more optimizations and run on more hardware. There isnt much that can be done about this, short of not using floating point But why does it not work with default options? or is that unknown ? did you succeed in reproduring the issue ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175
On 22 February 2017 at 20:18, Damien Riegel < damien.rie...@savoirfairelinux.com> wrote: > On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote: > > Hi, > > > > On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote: > > > > > > > > No, do this in libavfilter and do not introduce another useless > pseudo > > > > codec > > > > > > > > > > *libavformat, sorry > > > > The advantage of using a pseudo codec just to depack the stream is that > > the input and the codec are in separate threads in ffmpeg, so it can > > handle a heavier workload. > > Please find attached a v2, with the implementation in libavformat. Note > that I don't want to send it as a patch of its own because the > performance issue is not addressed. > > Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p > at 60fps. With the pseudo-codec, we are able to transcode it to h264 and > dump it to a file. With unpacking done in the libavformat, the input > thread gets too busy and can't stand the load. > > In the implementation you made [1] unpacking was done in libavcodec, so > why is it not an acceptable solution for mainline? > > I now think it was ok to have a custom codec format because V210 is implemented in such a way in lavc. So I think the first version of your patch was better. You just didn't bother to list a valid reason besides "offload it to another thread" and I didn't think of V210 at the time. libavformat has no support for assembly so putting the unpacking there would be slower too. I suggest posting a v3 of the patch which is like v1 (but please rename the codec name to something better) and which uses the assembly for unpacking from the repository you linked. PS: In that repo its _not_ done in lavc and it was never done in lavc, the point was to use lavc's assembly framework so that if you linked to it and used the private functions you'd be able to use them _outside_ of lavc. This was because upipe, which is something made to handle the stinkiest kind of crap broadcasting people invent because ffmpeg couldn't (and it absolutely doesn't have to), didn't have any support for assembly. Eventually support for that was added and everything from the repo plus more has been implemented there. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding
On Wed, 22 Feb 2017 21:00:31 +0100 (CET) Marton Balintwrote: > On Wed, 22 Feb 2017, wm4 wrote: > > > On Wed, 22 Feb 2017 00:14:32 +0100 > > Marton Balint wrote: > > > >> This ensures that the wrapped avframe will not get reallocated later, which > >> would invalidate internal references such as extended data. > >> > >> Signed-off-by: Marton Balint > >> --- > >> libavcodec/wrapped_avframe.c | 16 ++-- > >> 1 file changed, 14 insertions(+), 2 deletions(-) > >> > >> diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c > >> index 13c8d8a..1436032 100644 > >> --- a/libavcodec/wrapped_avframe.c > >> +++ b/libavcodec/wrapped_avframe.c > >> @@ -43,19 +43,31 @@ static int wrapped_avframe_encode(AVCodecContext > >> *avctx, AVPacket *pkt, > >> const AVFrame *frame, int *got_packet) > >> { > >> AVFrame *wrapped = av_frame_clone(frame); > >> +uint8_t *data; > >> +int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE; > >> > >> if (!wrapped) > >> return AVERROR(ENOMEM); > >> > >> -pkt->buf = av_buffer_create((uint8_t *)wrapped, sizeof(*wrapped), > >> +data = av_mallocz(size); > >> +if (!data) { > >> +av_frame_free(); > >> +return AVERROR(ENOMEM); > >> +} > >> + > >> +pkt->buf = av_buffer_create(data, size, > >> wrapped_avframe_release_buffer, NULL, > >> AV_BUFFER_FLAG_READONLY); > >> if (!pkt->buf) { > >> av_frame_free(); > >> +av_freep(); > >> return AVERROR(ENOMEM); > >> } > >> > >> -pkt->data = (uint8_t *)wrapped; > >> +av_frame_move_ref((AVFrame*)data, wrapped); > >> +av_frame_free(); > > > > I think this could be done as just > > > > av_frame_ref((AVFrame*)data, frame); > > > > without calling av_frame_clone(), but it doesn't hurt either. (Changing > > it might be an optional, minor improvement.) > > You are right, yet I used av_frame_move_ref, because it overwrites the > contents of AVFrame directly, so it does not matter that I allocated it > with mallocz instead of av_frame_alloc, and av_frame_ref docs explicitly > requires an unref-ed or alloc-ed AVFrame. So this seemed more safe, even > if it involves a few more code lines. Shouldn't make a difference. I'm also just seeing that this violates ABI by using sizeof(AVFrame) (how typical of FFmpeg/Libav code to violate its own complicated ABI rules), but it was like this before and can't be fixed. Probably another thing that could be fixed with the next ABI bump. > > > >> + > >> +pkt->data = data; > >> pkt->size = sizeof(*wrapped); > >> > >> pkt->flags |= AV_PKT_FLAG_KEY; > > > > Patch looks good, and I like it better than checking the codec ID. > > Ok, will apply soon. OK ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175
On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote: > Hi, > > On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote: > > > > > > No, do this in libavfilter and do not introduce another useless pseudo > > > codec > > > > > > > *libavformat, sorry > > The advantage of using a pseudo codec just to depack the stream is that > the input and the codec are in separate threads in ffmpeg, so it can > handle a heavier workload. Please find attached a v2, with the implementation in libavformat. Note that I don't want to send it as a patch of its own because the performance issue is not addressed. Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p at 60fps. With the pseudo-codec, we are able to transcode it to h264 and dump it to a file. With unpacking done in the libavformat, the input thread gets too busy and can't stand the load. In the implementation you made [1] unpacking was done in libavcodec, so why is it not an acceptable solution for mainline? [1] https://github.com/funman/ffmpeg-sdi Thanks, -- Damien >From c81e69979433ed519932354e848889a90d25f1c5 Mon Sep 17 00:00:00 2001 From: Damien RiegelDate: Wed, 16 Nov 2016 15:27:13 -0500 Subject: [PATCH v2] rtp: rawvideo: add handler for YCbCr-4:2:2 This adds partial support for the RFC 4175 (raw video over RTP). The only supported formats are the YCbCr-4:2:2 8 and 10 bit. For 8-bit depth, the format is similar to AV_PIX_FMT_UYVY422, and for 10-bit, the stream is repacked to the planar format AV_PIX_FMT_YUV422P10LE. Signed-off-by: Damien Riegel --- libavformat/Makefile | 1 + libavformat/rtpdec.c | 1 + libavformat/rtpdec_formats.h | 1 + libavformat/rtpdec_rawvideo.c | 259 ++ 4 files changed, 262 insertions(+) create mode 100644 libavformat/rtpdec_rawvideo.c diff --git a/libavformat/Makefile b/libavformat/Makefile index fc2d76067b..e17ba95c23 100644 --- a/libavformat/Makefile +++ b/libavformat/Makefile @@ -55,6 +55,7 @@ OBJS-$(CONFIG_RTPDEC)+= rdt.o \ rtpdec_qcelp.o \ rtpdec_qdm2.o \ rtpdec_qt.o \ +rtpdec_rawvideo.o \ rtpdec_svq3.o \ rtpdec_vc2hq.o \ rtpdec_vp8.o\ diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c index 53cdad7396..345318c32c 100644 --- a/libavformat/rtpdec.c +++ b/libavformat/rtpdec.c @@ -114,6 +114,7 @@ void ff_register_rtp_dynamic_payload_handlers(void) ff_register_dynamic_payload_handler(_qt_rtp_vid_handler); ff_register_dynamic_payload_handler(_quicktime_rtp_aud_handler); ff_register_dynamic_payload_handler(_quicktime_rtp_vid_handler); +ff_register_dynamic_payload_handler(_rawvideo_rtp_handler); ff_register_dynamic_payload_handler(_svq3_dynamic_handler); ff_register_dynamic_payload_handler(_theora_dynamic_handler); ff_register_dynamic_payload_handler(_vc2hq_dynamic_handler); diff --git a/libavformat/rtpdec_formats.h b/libavformat/rtpdec_formats.h index 3292a3d265..fab12fd139 100644 --- a/libavformat/rtpdec_formats.h +++ b/libavformat/rtpdec_formats.h @@ -82,6 +82,7 @@ extern RTPDynamicProtocolHandler ff_qt_rtp_aud_handler; extern RTPDynamicProtocolHandler ff_qt_rtp_vid_handler; extern RTPDynamicProtocolHandler ff_quicktime_rtp_aud_handler; extern RTPDynamicProtocolHandler ff_quicktime_rtp_vid_handler; +extern RTPDynamicProtocolHandler ff_rawvideo_rtp_handler; extern RTPDynamicProtocolHandler ff_svq3_dynamic_handler; extern RTPDynamicProtocolHandler ff_theora_dynamic_handler; extern RTPDynamicProtocolHandler ff_vc2hq_dynamic_handler; diff --git a/libavformat/rtpdec_rawvideo.c b/libavformat/rtpdec_rawvideo.c new file mode 100644 index 00..7edde84306 --- /dev/null +++ b/libavformat/rtpdec_rawvideo.c @@ -0,0 +1,259 @@ +/* + * RTP Depacketization of RAW video (TR-03) + * Copyright (c) 2016 Savoir-faire Linux, Inc + * + * 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
Re: [FFmpeg-devel] [PATCH] avcodec/wrapped_avframe: allocate a buffer with padding
On Wed, 22 Feb 2017, wm4 wrote: On Wed, 22 Feb 2017 00:14:32 +0100 Marton Balintwrote: This ensures that the wrapped avframe will not get reallocated later, which would invalidate internal references such as extended data. Signed-off-by: Marton Balint --- libavcodec/wrapped_avframe.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/libavcodec/wrapped_avframe.c b/libavcodec/wrapped_avframe.c index 13c8d8a..1436032 100644 --- a/libavcodec/wrapped_avframe.c +++ b/libavcodec/wrapped_avframe.c @@ -43,19 +43,31 @@ static int wrapped_avframe_encode(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet) { AVFrame *wrapped = av_frame_clone(frame); +uint8_t *data; +int size = sizeof(*wrapped) + AV_INPUT_BUFFER_PADDING_SIZE; if (!wrapped) return AVERROR(ENOMEM); -pkt->buf = av_buffer_create((uint8_t *)wrapped, sizeof(*wrapped), +data = av_mallocz(size); +if (!data) { +av_frame_free(); +return AVERROR(ENOMEM); +} + +pkt->buf = av_buffer_create(data, size, wrapped_avframe_release_buffer, NULL, AV_BUFFER_FLAG_READONLY); if (!pkt->buf) { av_frame_free(); +av_freep(); return AVERROR(ENOMEM); } -pkt->data = (uint8_t *)wrapped; +av_frame_move_ref((AVFrame*)data, wrapped); +av_frame_free(); I think this could be done as just av_frame_ref((AVFrame*)data, frame); without calling av_frame_clone(), but it doesn't hurt either. (Changing it might be an optional, minor improvement.) You are right, yet I used av_frame_move_ref, because it overwrites the contents of AVFrame directly, so it does not matter that I allocated it with mallocz instead of av_frame_alloc, and av_frame_ref docs explicitly requires an unref-ed or alloc-ed AVFrame. So this seemed more safe, even if it involves a few more code lines. + +pkt->data = data; pkt->size = sizeof(*wrapped); pkt->flags |= AV_PKT_FLAG_KEY; Patch looks good, and I like it better than checking the codec ID. Ok, will apply soon. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: drawtext options update
On Tue, 21 Feb 2017 21:24:55 -0900, Lou Logan wrote: > This can occur if the patch itself is directly edited, but I can fix it > and apply within 24 hours. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] minterpolate filter
On Wed, Feb 22, 2017 at 08:02:00AM +, Ural wrote: > Hello all. First, thanks for doing great and hard work. I can't imagine > any video-(pre/post)processing exist without ffmpeg. > I am posting my question in devel, because I am not asking how to do > something. What I am trying to do works, but bad. > > I create videos from pictures and need to make them as smooth as > possible. I found, that what I need called 'motion interpolation'. I > started to search all forums, and found only 3 things can help me: > slowmovideo, butterflow and new ffmpeg's filter minterpolate. > > > slowmovideo needs many configuration, I was not able to get it to work > as I want. with butterflow, I tried anything. From installing OpenCL, > OpenGL and other stuff to switching to nvidia binary drivers and > installing all sdk tools and cuda. It never worked. Some error about > cuda, and google don't know about it. > > > So third option was the only one available. When I tried it, it did > exactly what I want! But it is incredibly SLOW. I have 8-core CPU, and > it processes about 0.1-0.3 fps. And uses just 1 CORE, no video card. > > Guys, do you have some plans about this awesome filter? Like to port it > to opencl, or use at least all cores? There are no any option available, > so all hopes only to this filter. Or maybe some other > alternatives/patches exist? theres mcfps https://github.com/michaelni/FFmpeg/tree/mcfps its not really designed for speed but if you switch it to use non iterative ME (see diff below) it does around 12fps here with matrixbench mcfps is far from finished, i had many ideas on how to improve it and as funding was mentioned in another reply in this thread and i think i didnt mention it before, there was a company funding the mcfps work. The ideas people had during review of the mcfps work conflicted with my ideas to improve the motion estimation code though and without these improvments, the quality the company would expect would not be achievable. Which kind of halted the project minterpolate came after that as a gsoc project and was supposed to be based on mcfps but wasnt really, so each of mcfps and minterpolate are better at some things and worse at others. Also noone is working on minterpolate anymore AFAIK Both mcfps and minterpolate are quality wise not as good as id like There were alot of ideas/improvments that should be tried. Optimizing the existing code should come after improving it quality wise, except were such optimizations arent in the way of improving the code. If i find the motivation to work on improving the quality of the now in git minterpolate, i guess i could check if that company still is interrested in funding that or if they dont want to hear anything from me and that filter anymore ... its quite a while. not saying that this would be boring work id only do if its payed diff --git a/libavfilter/vf_mcfps.c b/libavfilter/vf_mcfps.c index 0aa951e7a0..788d600f28 100644 --- a/libavfilter/vf_mcfps.c +++ b/libavfilter/vf_mcfps.c @@ -258,7 +258,7 @@ av_log(0,0, "FPS %d/%d\n", mcfps->frame_rate.num, mcfps->frame_rate.den); avctx_enc->flags |= CODEC_FLAG_QPEL; avctx_enc->strict_std_compliance = FF_COMPLIANCE_EXPERIMENTAL; avctx_enc->global_quality = 12; -avctx_enc->me_method = ME_ITER; +avctx_enc->me_method = ME_EPZS; // avctx_enc->dia_size = 16; avctx_enc->mb_decision = FF_MB_DECISION_RD; avctx_enc->scenechange_threshold = 20; [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure/rtmpdh: Fix OpenSSL 1.1.0 support
1) configure only looks for OPENSSL_init_ssl using pkg-config, this breaks in case pkg-config is not available (cross-compiling) 2) The rtmpdh code uses the DH struct from OpenSSL which was made private in the 1.1 series From 5cc140f85d8d7551ac0a2c51d5023bd8ba75ba4b Mon Sep 17 00:00:00 2001 From: sfan5Date: Wed, 22 Feb 2017 15:35:57 +0100 Subject: [PATCH 1/2] configure: Support OpenSSL 1.1.0 without pkg-config --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 6431313814..16db9edc1b 100755 --- a/configure +++ b/configure @@ -5892,6 +5892,7 @@ enabled omx && { check_header OMX_Core.h || die "ERROR: OpenMAX IL headers not found"; } enabled openssl && { use_pkg_config openssl openssl/ssl.h OPENSSL_init_ssl || use_pkg_config openssl openssl/ssl.h SSL_library_init || + check_lib openssl/ssl.h OPENSSL_init_ssl -lssl -lcrypto || check_lib openssl/ssl.h SSL_library_init -lssl -lcrypto || check_lib openssl/ssl.h SSL_library_init -lssl32 -leay32 || check_lib openssl/ssl.h SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 || -- 2.11.1 From ee02425f851d0c9cfb8a892f385394efe5b4fdda Mon Sep 17 00:00:00 2001 From: sfan5 Date: Wed, 22 Feb 2017 15:38:16 +0100 Subject: [PATCH 2/2] rtmpdh: Support OpenSSL 1.1.0 DH (struct dh_st) was made private in the 1.1 series, a replacement similar to the FF_DH struct for gcrypt/gmp is used instead. --- libavformat/rtmpdh.h | 9 + 1 file changed, 9 insertions(+) diff --git a/libavformat/rtmpdh.h b/libavformat/rtmpdh.h index 2b250f595d..2d1489b193 100644 --- a/libavformat/rtmpdh.h +++ b/libavformat/rtmpdh.h @@ -48,10 +48,19 @@ typedef struct FF_DH { #elif CONFIG_OPENSSL #include #include +#include typedef BIGNUM *FFBigNum; +#if OPENSSL_VERSION_NUMBER >= 0x101fL +typedef struct { +BIGNUM *p, *g; +BIGNUM *pub_key, *priv_key; +long length; +} FF_DH; +#else typedef DH FF_DH; #endif +#endif /** * Initialize a Diffie-Hellmann context. -- 2.11.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On 2/22/17, Michael Niedermayerwrote: > On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote: >> On 2/22/17, Michael Niedermayer wrote: >> > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote: >> >> On 2/22/17, Michael Niedermayer wrote: >> >> > Fixes: 647/clusterfuzz-testcase-5195745823031296 >> >> > >> >> > Found-by: continuous fuzzing process >> >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg >> >> > Signed-off-by: Michael Niedermayer >> >> > --- >> >> > libavcodec/h264_ps.c | 11 +++ >> >> > 1 file changed, 11 insertions(+) >> >> > >> >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c >> >> > index 8090178395..f4a4a01fbe 100644 >> >> > --- a/libavcodec/h264_ps.c >> >> > +++ b/libavcodec/h264_ps.c >> >> > @@ -828,6 +828,12 @@ int >> >> > ff_h264_decode_picture_parameter_set(GetBitContext >> >> > *gb, AVCodecContext *avct >> >> > pps->init_qp = get_se_golomb(gb) + >> >> > 26 >> >> > + >> >> > qp_bd_offset; >> >> > pps->init_qs = get_se_golomb(gb) + >> >> > 26 >> >> > + >> >> > qp_bd_offset; >> >> > pps->chroma_qp_index_offset[0]= get_se_golomb(gb); >> >> > +if (pps->chroma_qp_index_offset[0] < -12 || >> >> > pps->chroma_qp_index_offset[0] > 12) { >> >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d >> >> > is >> >> >> >> This is nonsense. Please remove. >> > >> > Id like to keep the error messages or id like to have someone else >> > take over h264 maintaince in ffmpeg. >> >> Than why you are posting patches at all, if you do not want to listen >> to reviews. > > ive posted a patchset with ff_elog() instead > > do people prefer that ? > > [...] You could right now start adding such messages at every error path. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] Add support for Ericsson Texture Compression 1 (ETC1)
On 2/22/17, Devin Heitmuellerwrote: > This patch adds support for encoding/decoding ETC1 compressed > textures. This includes support for the PKM file format. > > Example usage: > > ./ffmpeg -i input_image.jpg new.pkm > ./ffmpeg -i new.pkm foo.jpg > > Signed-off-by: Devin Heitmueller > --- > libavcodec/Makefile | 2 + > libavcodec/allcodecs.c | 1 + > libavcodec/avcodec.h| 1 + > libavcodec/codec_desc.c | 7 + > libavcodec/etc1.c | 707 > > libavcodec/etc1.h | 114 > libavcodec/etc1dec.c| 81 ++ > libavcodec/etc1enc.c| 90 ++ > libavcodec/utils.c | 3 +- > libavformat/img2.c | 1 + > libavformat/img2enc.c | 2 +- > 11 files changed, 1007 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/etc1.c > create mode 100644 libavcodec/etc1.h > create mode 100644 libavcodec/etc1dec.c > create mode 100644 libavcodec/etc1enc.c > Apache 2.0 license is bad in combination with LGPL. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On Wed, Feb 22, 2017 at 04:41:43PM +0100, Paul B Mahol wrote: > On 2/22/17, Michael Niedermayerwrote: > > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote: > >> On 2/22/17, Michael Niedermayer wrote: > >> > Fixes: 647/clusterfuzz-testcase-5195745823031296 > >> > > >> > Found-by: continuous fuzzing process > >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > >> > Signed-off-by: Michael Niedermayer > >> > --- > >> > libavcodec/h264_ps.c | 11 +++ > >> > 1 file changed, 11 insertions(+) > >> > > >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c > >> > index 8090178395..f4a4a01fbe 100644 > >> > --- a/libavcodec/h264_ps.c > >> > +++ b/libavcodec/h264_ps.c > >> > @@ -828,6 +828,12 @@ int > >> > ff_h264_decode_picture_parameter_set(GetBitContext > >> > *gb, AVCodecContext *avct > >> > pps->init_qp = get_se_golomb(gb) + 26 > >> > + > >> > qp_bd_offset; > >> > pps->init_qs = get_se_golomb(gb) + 26 > >> > + > >> > qp_bd_offset; > >> > pps->chroma_qp_index_offset[0]= get_se_golomb(gb); > >> > +if (pps->chroma_qp_index_offset[0] < -12 || > >> > pps->chroma_qp_index_offset[0] > 12) { > >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is > >> > >> This is nonsense. Please remove. > > > > Id like to keep the error messages or id like to have someone else > > take over h264 maintaince in ffmpeg. > > Than why you are posting patches at all, if you do not want to listen > to reviews. ive posted a patchset with ff_elog() instead do people prefer that ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil/internal: Add ff_elog()
This enables the extra error messages in case of DEBUG or high assrtion levels. High assertion levels imply slow checks in inner loops so any extra error should be insignificant. Is it preferred to have a separate switch for ff_elog() so it doesnt depend on DEBUG/assertion level ? Signed-off-by: Michael Niedermayer--- libavutil/internal.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/libavutil/internal.h b/libavutil/internal.h index 7780a9a791..208f8f474f 100644 --- a/libavutil/internal.h +++ b/libavutil/internal.h @@ -262,6 +262,12 @@ void avpriv_request_sample(void *avc, # define ff_dlog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_DEBUG, __VA_ARGS__); } while (0) #endif +#if defined(DEBUG) || ASSERT_LEVEL > 1 +# define ff_elog(ctx, ...) av_log(ctx, AV_LOG_ERROR, __VA_ARGS__) +#else +# define ff_elog(ctx, ...) do { if (0) av_log(ctx, AV_LOG_ERROR, __VA_ARGS__); } while (0) +#endif + // For debuging we use signed operations so overflows can be detected (by ubsan) // For production we use unsigned so there are no undefined operations #ifdef CHECKED -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/h264_ps: Check chroma_qp_index_offset
Fixes: 647/clusterfuzz-testcase-5195745823031296 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer--- libavcodec/h264_ps.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c index 8090178395..9417b6c037 100644 --- a/libavcodec/h264_ps.c +++ b/libavcodec/h264_ps.c @@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, AVCodecContext *avct pps->init_qp = get_se_golomb(gb) + 26 + qp_bd_offset; pps->init_qs = get_se_golomb(gb) + 26 + qp_bd_offset; pps->chroma_qp_index_offset[0]= get_se_golomb(gb); +if (pps->chroma_qp_index_offset[0] < -12 || pps->chroma_qp_index_offset[0] > 12) { +ff_elog(avctx, "chroma_qp_index_offset[0] %d is invalid\n", pps->chroma_qp_index_offset[0]); +ret = AVERROR_INVALIDDATA; +goto fail; +} + pps->deblocking_filter_parameters_present = get_bits1(gb); pps->constrained_intra_pred = get_bits1(gb); pps->redundant_pic_cnt_present= get_bits1(gb); @@ -845,6 +851,11 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, AVCodecContext *avct pps->scaling_matrix4, pps->scaling_matrix8); // second_chroma_qp_index_offset pps->chroma_qp_index_offset[1] = get_se_golomb(gb); +if (pps->chroma_qp_index_offset[1] < -12 || pps->chroma_qp_index_offset[1] > 12) { +ff_elog(avctx, "chroma_qp_index_offset[1] %d is invalid\n", pps->chroma_qp_index_offset[1]); +ret = AVERROR_INVALIDDATA; +goto fail; +} } else { pps->chroma_qp_index_offset[1] = pps->chroma_qp_index_offset[0]; } -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] Add support for Ericsson Texture Compression 1 (ETC1)
This patch adds support for encoding/decoding ETC1 compressed textures. This includes support for the PKM file format. Example usage: ./ffmpeg -i input_image.jpg new.pkm ./ffmpeg -i new.pkm foo.jpg Signed-off-by: Devin Heitmueller--- libavcodec/Makefile | 2 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h| 1 + libavcodec/codec_desc.c | 7 + libavcodec/etc1.c | 707 libavcodec/etc1.h | 114 libavcodec/etc1dec.c| 81 ++ libavcodec/etc1enc.c| 90 ++ libavcodec/utils.c | 3 +- libavformat/img2.c | 1 + libavformat/img2enc.c | 2 +- 11 files changed, 1007 insertions(+), 2 deletions(-) create mode 100644 libavcodec/etc1.c create mode 100644 libavcodec/etc1.h create mode 100644 libavcodec/etc1dec.c create mode 100644 libavcodec/etc1enc.c diff --git a/libavcodec/Makefile b/libavcodec/Makefile index a1ce264..f5eec15 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -280,6 +280,8 @@ OBJS-$(CONFIG_EIGHTSVX_EXP_DECODER)+= 8svx.o OBJS-$(CONFIG_EIGHTSVX_FIB_DECODER)+= 8svx.o OBJS-$(CONFIG_ESCAPE124_DECODER) += escape124.o OBJS-$(CONFIG_ESCAPE130_DECODER) += escape130.o +OBJS-$(CONFIG_ETC1_ENCODER)+= etc1enc.o etc1.o +OBJS-$(CONFIG_ETC1_DECODER)+= etc1dec.o etc1.o OBJS-$(CONFIG_EVRC_DECODER)+= evrcdec.o acelp_vectors.o lsp.o OBJS-$(CONFIG_EXR_DECODER) += exr.o OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index f12a54d..cd3a662 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -184,6 +184,7 @@ void avcodec_register_all(void) REGISTER_DECODER(EIGHTSVX_FIB, eightsvx_fib); REGISTER_DECODER(ESCAPE124, escape124); REGISTER_DECODER(ESCAPE130, escape130); +REGISTER_ENCDEC (ETC1, etc1); REGISTER_DECODER(EXR, exr); REGISTER_ENCDEC (FFV1, ffv1); REGISTER_ENCDEC (FFVHUFF, ffvhuff); diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index 5616fb0..bf86210 100644 --- a/libavcodec/avcodec.h +++ b/libavcodec/avcodec.h @@ -388,6 +388,7 @@ enum AVCodecID { AV_CODEC_ID_DXV, AV_CODEC_ID_SCREENPRESSO, AV_CODEC_ID_RSCC, +AV_CODEC_ID_ETC1, AV_CODEC_ID_Y41P = 0x8000, AV_CODEC_ID_AVRP, diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c index 35846c0..de7695d 100644 --- a/libavcodec/codec_desc.c +++ b/libavcodec/codec_desc.c @@ -1199,6 +1199,13 @@ static const AVCodecDescriptor codec_descriptors[] = { }, { +.id= AV_CODEC_ID_ETC1, +.type = AVMEDIA_TYPE_VIDEO, +.name = "etc1", +.long_name = NULL_IF_CONFIG_SMALL("ETC1 (Ericsson Texture Compression) image"), +.props = AV_CODEC_PROP_LOSSY, +}, +{ .id= AV_CODEC_ID_G2M, .type = AVMEDIA_TYPE_VIDEO, .name = "g2m", diff --git a/libavcodec/etc1.c b/libavcodec/etc1.c new file mode 100644 index 000..e28d83c --- /dev/null +++ b/libavcodec/etc1.c @@ -0,0 +1,707 @@ +// Copyright 2009 Google Inc. +// +// Licensed under the Apache License, Version 2.0 (the "License"); +// you may not use this file except in compliance with the License. +// You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. + +// + +// This is a fork of the AOSP project ETC1 codec. The original code can be found +// at the following web site: +// https://android.googlesource.com/platform/frameworks/native/+/master/opengl/include/ETC1/ + +// + +#include "etc1.h" + +//#include +#include + +/* From http://www.khronos.org/registry/gles/extensions/OES/OES_compressed_ETC1_RGB8_texture.txt + + The number of bits that represent a 4x4 texel block is 64 bits if + is given by ETC1_RGB8_OES. + + The data for a block is a number of bytes, + + {q0, q1, q2, q3, q4, q5, q6, q7} + + where byte q0 is located at the lowest memory address and q7 at + the highest. The 64 bits specifying the block is then represented + by the following 64 bit integer: + + int64bit = 256*(256*(256*(256*(256*(256*(256*q0+q1)+q2)+q3)+q4)+q5)+q6)+q7; + + ETC1_RGB8_OES: + + a) bit layout in bits 63 through 32 if diffbit = 0 + + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 +
[FFmpeg-devel] [PATCH 0/1] Add ETC1 encoder/decoder
This patch adds support for encoding and decoding the Ericsson Texture Compression 1 (ETC1) format. This includes support for the PKM file format. Note the actual codec uses Google's ETC1 implementation from Android (Apache 2 licensed). The only changes I made were a couple of very shallow fixes to compile in C90 mode (cases where variables were being declared in-line with code). Devin Heitmueller (1): Add support for Ericsson Texture Compression 1 (ETC1) libavcodec/Makefile | 2 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h| 1 + libavcodec/codec_desc.c | 7 + libavcodec/etc1.c | 707 libavcodec/etc1.h | 114 libavcodec/etc1dec.c| 81 ++ libavcodec/etc1enc.c| 90 ++ libavcodec/utils.c | 3 +- libavformat/img2.c | 1 + libavformat/img2enc.c | 2 +- 11 files changed, 1007 insertions(+), 2 deletions(-) create mode 100644 libavcodec/etc1.c create mode 100644 libavcodec/etc1.h create mode 100644 libavcodec/etc1dec.c create mode 100644 libavcodec/etc1enc.c -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3 3/3] mkv: Export bounds and padding from spherical metadata
On 2/21/2017 7:35 PM, Vittorio Giovara wrote: > --- > libavformat/matroskadec.c | 64 > -- > tests/ref/fate/matroska-spherical-mono | 6 +++- > 2 files changed, 66 insertions(+), 4 deletions(-) > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > index 7223e94..0a02237 100644 > --- a/libavformat/matroskadec.c > +++ b/libavformat/matroskadec.c > @@ -1913,16 +1913,65 @@ static int mkv_parse_video_projection(AVStream *st, > const MatroskaTrack *track) > AVSphericalMapping *spherical; > enum AVSphericalProjection projection; > size_t spherical_size; > +size_t l, t, r, b; > +size_t padding = 0; > int ret; > +GetByteContext gb; > + > +bytestream2_init(, track->video.projection.private.data, > + track->video.projection.private.size); private.size can be zero and private.data NULL. bytestream2_init() will trigger an assert in those cases. > + > +if (bytestream2_get_byte() != 0) { > +av_log(NULL, AV_LOG_WARNING, "Unknown spherical metadata\n"); > +return 0; > +} > + > +bytestream2_skip(, 3); // flags > > switch (track->video.projection.type) { > case MATROSKA_VIDEO_PROJECTION_TYPE_EQUIRECTANGULAR: > -projection = AV_SPHERICAL_EQUIRECTANGULAR; > +if (track->video.projection.private.size == 0) > +projection = AV_SPHERICAL_EQUIRECTANGULAR; > +else if (track->video.projection.private.size == 20) { > +t = bytestream2_get_be32(); > +b = bytestream2_get_be32(); > +l = bytestream2_get_be32(); > +r = bytestream2_get_be32(); > + > +if (b >= UINT_MAX - t || r >= UINT_MAX - l) { > +av_log(NULL, AV_LOG_ERROR, > + "Invalid bounding rectangle coordinates " > + "%zu,%zu,%zu,%zu\n", l, t, r, b); Use SIZE_SPECIFIER instead of zu. Msvc doesn't like the latter. Same with the mov implementation. > +return AVERROR_INVALIDDATA; > +} > + > +if (l || t || r || b) > +projection = AV_SPHERICAL_EQUIRECTANGULAR_TILE; > +else > +projection = AV_SPHERICAL_EQUIRECTANGULAR; > +} else { > +av_log(NULL, AV_LOG_ERROR, "Unknown spherical metadata\n"); > +return AVERROR_INVALIDDATA; > +} > break; Nit: I still think the Equi case looks better the way i suggested in my previous email. > case MATROSKA_VIDEO_PROJECTION_TYPE_CUBEMAP: > -if (track->video.projection.private.size < 4) > +if (track->video.projection.private.size < 4) { > +av_log(NULL, AV_LOG_ERROR, "Missing projection private > properties\n"); > +return AVERROR_INVALIDDATA; > +} else if (track->video.projection.private.size == 12) { > +uint32_t layout = bytestream2_get_be32(); > +if (layout == 0) { > +projection = AV_SPHERICAL_CUBEMAP; > +} else { > +av_log(NULL, AV_LOG_WARNING, > + "Unknown spherical cubemap layout %"PRIu32"\n", > layout); > +return 0; > +} > +padding = bytestream2_get_be32(); Nit: Maybe if (layout) { // return error } projection = AV_SPHERICAL_CUBEMAP; padding= bytestream2_get_be32(); > +} else { > +av_log(NULL, AV_LOG_ERROR, "Unknown spherical metadata\n"); > return AVERROR_INVALIDDATA; > -projection = AV_SPHERICAL_CUBEMAP; > +} > break; > default: > return 0; > @@ -1937,6 +1986,15 @@ static int mkv_parse_video_projection(AVStream *st, > const MatroskaTrack *track) > spherical->pitch = (int32_t)(track->video.projection.pitch * (1 << 16)); > spherical->roll = (int32_t)(track->video.projection.roll * (1 << 16)); > > +spherical->padding = padding; > + > +if (spherical->projection == AV_SPHERICAL_EQUIRECTANGULAR_TILE) { > +spherical->bound_left = l; > +spherical->bound_top= t; > +spherical->bound_right = r; > +spherical->bound_bottom = b; These four could also be zero initialized so you don't need to check the projection. > +} > + > ret = av_stream_add_side_data(st, AV_PKT_DATA_SPHERICAL, (uint8_t > *)spherical, >spherical_size); > if (ret < 0) { > diff --git a/tests/ref/fate/matroska-spherical-mono > b/tests/ref/fate/matroska-spherical-mono > index 8048aff..a70d879 100644 > --- a/tests/ref/fate/matroska-spherical-mono > +++ b/tests/ref/fate/matroska-spherical-mono > @@ -8,7 +8,11 @@ inverted=0 > [SIDE_DATA] > side_data_type=Spherical Mapping > side_data_size=56 > -projection=equirectangular > +projection=tiled equirectangular > +bound_left=148 > +bound_top=73 >
[FFmpeg-devel] [PATCH] lavf/dashenc: update bitrates on dash_write_trailer
From: Przemysław SobalaProvides a way to change bandwidth (bitrate) parameter after CRF H.264 encoding (details: http://ffmpeg.org/pipermail/libav-user/2017-February/010141.html) Signed-off-by: Przemysław Sobala --- libavformat/dashenc.c | 42 ++ 1 file changed, 30 insertions(+), 12 deletions(-) diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c index fa56505..011d2ea 100644 --- a/libavformat/dashenc.c +++ b/libavformat/dashenc.c @@ -561,6 +561,30 @@ static int write_manifest(AVFormatContext *s, int final) return 0; } +static int set_bitrate(AVFormatContext *s) +{ +DASHContext *c = s->priv_data; +int i; + +for (i = 0; i < s->nb_streams; i++) { +OutputStream *os = >streams[i]; + +os->bit_rate = s->streams[i]->codecpar->bit_rate; +if (os->bit_rate) { +snprintf(os->bandwidth_str, sizeof(os->bandwidth_str), + " bandwidth=\"%d\"", os->bit_rate); +} else { +int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ? +AV_LOG_ERROR : AV_LOG_WARNING; +av_log(s, level, "No bit rate set for stream %d\n", i); +if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT) +return AVERROR(EINVAL); +} +} + +return 0; +} + static int dash_init(AVFormatContext *s) { DASHContext *c = s->priv_data; @@ -597,6 +621,10 @@ static int dash_init(AVFormatContext *s) if (!c->streams) return AVERROR(ENOMEM); +ret = set_bitrate(s); +if (ret < 0) +return ret; + for (i = 0; i < s->nb_streams; i++) { OutputStream *os = >streams[i]; AVFormatContext *ctx; @@ -604,18 +632,6 @@ static int dash_init(AVFormatContext *s) AVDictionary *opts = NULL; char filename[1024]; -os->bit_rate = s->streams[i]->codecpar->bit_rate; -if (os->bit_rate) { -snprintf(os->bandwidth_str, sizeof(os->bandwidth_str), - " bandwidth=\"%d\"", os->bit_rate); -} else { -int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ? -AV_LOG_ERROR : AV_LOG_WARNING; -av_log(s, level, "No bit rate set for stream %d\n", i); -if (s->strict_std_compliance >= FF_COMPLIANCE_STRICT) -return AVERROR(EINVAL); -} - ctx = avformat_alloc_context(); if (!ctx) return AVERROR(ENOMEM); @@ -981,6 +997,8 @@ static int dash_write_trailer(AVFormatContext *s) { DASHContext *c = s->priv_data; +set_bitrate(s); + if (s->nb_streams > 0) { OutputStream *os = >streams[0]; // If no segments have been written so far, try to do a crude -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On 2/22/17, Michael Niedermayerwrote: > On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote: >> On 2/22/17, Michael Niedermayer wrote: >> > Fixes: 647/clusterfuzz-testcase-5195745823031296 >> > >> > Found-by: continuous fuzzing process >> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg >> > Signed-off-by: Michael Niedermayer >> > --- >> > libavcodec/h264_ps.c | 11 +++ >> > 1 file changed, 11 insertions(+) >> > >> > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c >> > index 8090178395..f4a4a01fbe 100644 >> > --- a/libavcodec/h264_ps.c >> > +++ b/libavcodec/h264_ps.c >> > @@ -828,6 +828,12 @@ int >> > ff_h264_decode_picture_parameter_set(GetBitContext >> > *gb, AVCodecContext *avct >> > pps->init_qp = get_se_golomb(gb) + 26 >> > + >> > qp_bd_offset; >> > pps->init_qs = get_se_golomb(gb) + 26 >> > + >> > qp_bd_offset; >> > pps->chroma_qp_index_offset[0]= get_se_golomb(gb); >> > +if (pps->chroma_qp_index_offset[0] < -12 || >> > pps->chroma_qp_index_offset[0] > 12) { >> > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is >> >> This is nonsense. Please remove. > > Id like to keep the error messages or id like to have someone else > take over h264 maintaince in ffmpeg. Than why you are posting patches at all, if you do not want to listen to reviews. > > > [...] > >> Having log message for every error case would make ffmpeg binary very >> big and slow. > > I think the effect of the strings and not executed calls is negligible > but iam not opposed to use a ff_elog() or av_elog() or avpriv_elog() > if such macro would exist. > > Is anyone against adding and using such a macro ? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On Wed, Feb 22, 2017 at 02:29:00PM +0100, Paul B Mahol wrote: > On 2/22/17, Michael Niedermayerwrote: > > Fixes: 647/clusterfuzz-testcase-5195745823031296 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/h264_ps.c | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c > > index 8090178395..f4a4a01fbe 100644 > > --- a/libavcodec/h264_ps.c > > +++ b/libavcodec/h264_ps.c > > @@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext > > *gb, AVCodecContext *avct > > pps->init_qp = get_se_golomb(gb) + 26 + > > qp_bd_offset; > > pps->init_qs = get_se_golomb(gb) + 26 + > > qp_bd_offset; > > pps->chroma_qp_index_offset[0]= get_se_golomb(gb); > > +if (pps->chroma_qp_index_offset[0] < -12 || > > pps->chroma_qp_index_offset[0] > 12) { > > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is > > This is nonsense. Please remove. Id like to keep the error messages or id like to have someone else take over h264 maintaince in ffmpeg. [...] > Having log message for every error case would make ffmpeg binary very > big and slow. I think the effect of the strings and not executed calls is negligible but iam not opposed to use a ff_elog() or av_elog() or avpriv_elog() if such macro would exist. Is anyone against adding and using such a macro ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fixup! avcodec/mips: version 1 of vc1dsp optimizations for loongson mmi
--- libavcodec/mips/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile index b118558..797df09 100644 --- a/libavcodec/mips/Makefile +++ b/libavcodec/mips/Makefile @@ -36,7 +36,7 @@ OBJS-$(CONFIG_MPEGVIDEO) += mips/mpegvideo_init_mips.o OBJS-$(CONFIG_MPEGVIDEOENC) += mips/mpegvideoencdsp_init_mips.o OBJS-$(CONFIG_ME_CMP) += mips/me_cmp_init_mips.o OBJS-$(CONFIG_MPEG4_DECODER) += mips/xvididct_init_mips.o -OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_init_mips.o +OBJS-$(CONFIG_VC1DSP) += mips/vc1dsp_init_mips.o OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_init_mips.o MSA-OBJS-$(CONFIG_HEVC_DECODER) += mips/hevcdsp_msa.o\ mips/hevc_mc_uni_msa.o\ -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/qdrw: add support for 0x0001 code
Fixes decoding of files which sets frame width/height this way. Signed-off-by: Paul B Mahol--- libavcodec/qdrw.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/libavcodec/qdrw.c b/libavcodec/qdrw.c index e3d69c2..2462e2f 100644 --- a/libavcodec/qdrw.c +++ b/libavcodec/qdrw.c @@ -33,6 +33,7 @@ #include "internal.h" enum QuickdrawOpcodes { +CLIP = 0x0001, PACKBITSRECT = 0x0098, PACKBITSRGN, DIRECTBITSRECT, @@ -309,7 +310,7 @@ static int decode_frame(AVCodecContext *avctx, AVFrame * const p = data; GetByteContext gbc; int colors; -int w, h, ret; +int w, h, x0, y0, x1, y1, ret; int ver; bytestream2_init(, avpkt->data, avpkt->size); @@ -353,6 +354,16 @@ static int decode_frame(AVCodecContext *avctx, int opcode = bytestream2_get_be16(); switch(opcode) { +case CLIP: +bytestream2_get_be16(); +y0 = bytestream2_get_be16(); +x0 = bytestream2_get_be16(); +y1 = bytestream2_get_be16(); +x1 = bytestream2_get_be16(); +ret = ff_set_dimensions(avctx, x1 - x0, y1 - y0); +if (ret < 0) +return ret; +break; case PACKBITSRECT: case PACKBITSRGN: av_log(avctx, AV_LOG_DEBUG, "Parsing Packbit opcode\n"); -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] minterpolate filter
On 2/22/17, Uralwrote: > Hello all. First, thanks for doing great and hard work. I can't imagine > any video-(pre/post)processing exist without ffmpeg. > I am posting my question in devel, because I am not asking how to do > something. What I am trying to do works, but bad. > Maybe perhaps if one provide some kind of bounty. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Using avfilter to watermark a video stream
Hello, Can anyone tell me where I can get the patch? Thanks a lot! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit
Signed-off-by: Paul B Mahol--- libavcodec/dnxhddec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 70ce264..cdbc0bc 100644 --- a/libavcodec/dnxhddec.c +++ b/libavcodec/dnxhddec.c @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const DNXHDContext *ctx, static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx, RowContext *row, int n) { -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0); +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0); } static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx, -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: fix decoding of DNxHR HQX 10-bit
On 2/22/17, Paul B Maholwrote: > Signed-off-by: Paul B Mahol > --- > libavcodec/dnxhddec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c > index 70ce264..cdbc0bc 100644 > --- a/libavcodec/dnxhddec.c > +++ b/libavcodec/dnxhddec.c > @@ -435,7 +435,7 @@ static int dnxhd_decode_dct_block_8(const DNXHDContext > *ctx, > static int dnxhd_decode_dct_block_10(const DNXHDContext *ctx, > RowContext *row, int n) > { > -return dnxhd_decode_dct_block(ctx, row, n, 6, 8, 4, 0); > +return dnxhd_decode_dct_block(ctx, row, n, 6, 32, 6, 0); > } > > static int dnxhd_decode_dct_block_10_444(const DNXHDContext *ctx, > -- > 2.9.3 > > File can be found here: https://drive.google.com/open?id=0B1hdyiz226iBV1llcDl3LW80U2c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
On 2/22/17, Michael Niedermayerwrote: > Fixes: 647/clusterfuzz-testcase-5195745823031296 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h264_ps.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c > index 8090178395..f4a4a01fbe 100644 > --- a/libavcodec/h264_ps.c > +++ b/libavcodec/h264_ps.c > @@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext > *gb, AVCodecContext *avct > pps->init_qp = get_se_golomb(gb) + 26 + > qp_bd_offset; > pps->init_qs = get_se_golomb(gb) + 26 + > qp_bd_offset; > pps->chroma_qp_index_offset[0]= get_se_golomb(gb); > +if (pps->chroma_qp_index_offset[0] < -12 || > pps->chroma_qp_index_offset[0] > 12) { > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is This is nonsense. Please remove. > invalid\n", pps->chroma_qp_index_offset[0]); > +ret = AVERROR_INVALIDDATA; > +goto fail; > +} > + > pps->deblocking_filter_parameters_present = get_bits1(gb); > pps->constrained_intra_pred = get_bits1(gb); > pps->redundant_pic_cnt_present= get_bits1(gb); > @@ -845,6 +851,11 @@ int ff_h264_decode_picture_parameter_set(GetBitContext > *gb, AVCodecContext *avct > pps->scaling_matrix4, > pps->scaling_matrix8); > // second_chroma_qp_index_offset > pps->chroma_qp_index_offset[1] = get_se_golomb(gb); > +if (pps->chroma_qp_index_offset[1] < -12 || > pps->chroma_qp_index_offset[1] > 12) { > +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[1] %d is > invalid\n", pps->chroma_qp_index_offset[1]); ditto. > +ret = AVERROR_INVALIDDATA; > +goto fail; > +} > } else { > pps->chroma_qp_index_offset[1] = pps->chroma_qp_index_offset[0]; > } > -- > 2.11.0 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Having log message for every error case would make ffmpeg binary very big and slow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add ffmpeg-security alias members
On Fri, Feb 10, 2017 at 08:55:26PM +0100, Michael Niedermayer wrote: > Iam listing the reason for each, this is mostly my oppinion and i didnt ask > most > if they agree with the listed reason to be listed with their name, so its > largly > my oppinion. Which is why i will remove the reasons before pushing i just > added them > to be transparent on this but as said its mostly my oppinion, i just talked > with ubitux and noone else ... changes made as described previously and pushed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_ps: Check chroma_qp_index_offset
Fixes: 647/clusterfuzz-testcase-5195745823031296 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer--- libavcodec/h264_ps.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c index 8090178395..f4a4a01fbe 100644 --- a/libavcodec/h264_ps.c +++ b/libavcodec/h264_ps.c @@ -828,6 +828,12 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, AVCodecContext *avct pps->init_qp = get_se_golomb(gb) + 26 + qp_bd_offset; pps->init_qs = get_se_golomb(gb) + 26 + qp_bd_offset; pps->chroma_qp_index_offset[0]= get_se_golomb(gb); +if (pps->chroma_qp_index_offset[0] < -12 || pps->chroma_qp_index_offset[0] > 12) { +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[0] %d is invalid\n", pps->chroma_qp_index_offset[0]); +ret = AVERROR_INVALIDDATA; +goto fail; +} + pps->deblocking_filter_parameters_present = get_bits1(gb); pps->constrained_intra_pred = get_bits1(gb); pps->redundant_pic_cnt_present= get_bits1(gb); @@ -845,6 +851,11 @@ int ff_h264_decode_picture_parameter_set(GetBitContext *gb, AVCodecContext *avct pps->scaling_matrix4, pps->scaling_matrix8); // second_chroma_qp_index_offset pps->chroma_qp_index_offset[1] = get_se_golomb(gb); +if (pps->chroma_qp_index_offset[1] < -12 || pps->chroma_qp_index_offset[1] > 12) { +av_log(avctx, AV_LOG_ERROR, "chroma_qp_index_offset[1] %d is invalid\n", pps->chroma_qp_index_offset[1]); +ret = AVERROR_INVALIDDATA; +goto fail; +} } else { pps->chroma_qp_index_offset[1] = pps->chroma_qp_index_offset[0]; } -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] minterpolate filter
Hello all. First, thanks for doing great and hard work. I can't imagine any video-(pre/post)processing exist without ffmpeg. I am posting my question in devel, because I am not asking how to do something. What I am trying to do works, but bad. I create videos from pictures and need to make them as smooth as possible. I found, that what I need called 'motion interpolation'. I started to search all forums, and found only 3 things can help me: slowmovideo, butterflow and new ffmpeg's filter minterpolate. slowmovideo needs many configuration, I was not able to get it to work as I want. with butterflow, I tried anything. From installing OpenCL, OpenGL and other stuff to switching to nvidia binary drivers and installing all sdk tools and cuda. It never worked. Some error about cuda, and google don't know about it. So third option was the only one available. When I tried it, it did exactly what I want! But it is incredibly SLOW. I have 8-core CPU, and it processes about 0.1-0.3 fps. And uses just 1 CORE, no video card. Guys, do you have some plans about this awesome filter? Like to port it to opencl, or use at least all cores? There are no any option available, so all hopes only to this filter. Or maybe some other alternatives/patches exist? Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel