Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test
On Fri, Feb 24, 2017 at 07:13:05PM -0800, Thomas Turner wrote: [...] > ccache gcc -m32 -c -o /tmp/ffconf.2gbznSmZ.o /tmp/ffconf.72hnkFGt.c > ./configure: 884: ./configure: ccache: not found > C compiler test failed. try without ccache [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: fix hls_flags temp_file bug
2017-02-22 7:53 GMT+08:00 Steven Liu :
> refer to ticket id: #6170
>
> rename file from temp to origin name after complete current segment
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 55 ++
> --
> 1 file changed, 27 insertions(+), 28 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 86a3b05..118aef2 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -691,6 +691,17 @@ static void write_m3u8_head_block(HLSContext *hls,
> AVIOContext *out, int version
> av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n",
> sequence);
> }
>
> +static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
> +{
> +size_t len = strlen(oc->filename);
> +char final_filename[sizeof(oc->filename)];
> +
> +av_strlcpy(final_filename, oc->filename, len);
> +final_filename[len-4] = '\0';
> +ff_rename(oc->filename, final_filename, s);
> +oc->filename[len-4] = '\0';
> +}
> +
> static int hls_window(AVFormatContext *s, int last)
> {
> HLSContext *hls = s->priv_data;
> @@ -833,15 +844,6 @@ static int hls_start(AVFormatContext *s)
> char *filename, iv_string[KEYSIZE*2 + 1];
> int err = 0;
>
> -if ((c->flags & HLS_TEMP_FILE) && oc->filename[0] != 0) {
> -size_t len = strlen(oc->filename);
> -char final_filename[sizeof(oc->filename)];
> -av_strlcpy(final_filename, oc->filename, len);
> -final_filename[len-4] = '\0';
> -ff_rename(oc->filename, final_filename, s);
> -oc->filename[len-4] = '\0';
> -}
> -
> if (c->flags & HLS_SINGLE_FILE) {
> av_strlcpy(oc->filename, c->basename,
> sizeof(oc->filename));
> @@ -1325,6 +1327,17 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> new_start_pos = avio_tell(hls->avf->pb);
> hls->size = new_start_pos - hls->start_pos;
> +
> +if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
> +if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <=
> 0))
> +if (hls->avf->oformat->priv_class && hls->avf->priv_data)
> +av_opt_set(hls->avf->priv_data, "mpegts_flags",
> "resend_headers", 0);
> +ff_format_io_close(s, &oc->pb);
> +if (hls->vtt_avf)
> +ff_format_io_close(s, &hls->vtt_avf->pb);
> +hls_rename_temp_file(s, oc);
> +}
> +
> ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
> hls->size);
> hls->start_pos = new_start_pos;
> if (ret < 0) {
> @@ -1336,21 +1349,14 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> hls->duration = 0;
>
> if (hls->flags & HLS_SINGLE_FILE) {
> -if (hls->avf->oformat->priv_class && hls->avf->priv_data)
> -av_opt_set(hls->avf->priv_data, "mpegts_flags",
> "resend_headers", 0);
> hls->number++;
> } else if (hls->max_seg_size > 0) {
> -if (hls->avf->oformat->priv_class && hls->avf->priv_data)
> -av_opt_set(hls->avf->priv_data, "mpegts_flags",
> "resend_headers", 0);
> if (hls->start_pos >= hls->max_seg_size) {
> hls->sequence++;
> -ff_format_io_close(s, &oc->pb);
> if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
> HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
> strlen(hls->current_segment_final_filename_fmt)) {
> ff_rename(old_filename, hls->avf->filename, hls);
> }
> -if (hls->vtt_avf)
> -ff_format_io_close(s, &hls->vtt_avf->pb);
> ret = hls_start(s);
> hls->start_pos = 0;
> /* When split segment by byte, the duration is short than
> hls_time,
> @@ -1359,13 +1365,10 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> hls->number++;
> } else {
> -ff_format_io_close(s, &oc->pb);
> if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
> HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
> strlen(hls->current_segment_final_filename_fmt)) {
> ff_rename(old_filename, hls->avf->filename, hls);
> }
> -if (hls->vtt_avf)
> -ff_format_io_close(s, &hls->vtt_avf->pb);
>
> ret = hls_start(s);
> }
> @@ -1402,6 +1405,11 @@ static int hls_write_trailer(struct AVFormatContext
> *s)
> if (oc->pb) {
> hls->size = avio_tell(hls->avf->pb) - hls->start_pos;
> ff_format_io_close(s, &oc->pb);
> +
> +if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
> +hls_rename_temp_file(s, oc);
> +}
> +
> /* after av_write_trailer, then duration + 1 duration per packet
> */
> hls_append_segment(s, hls, hls->d
Re: [FFmpeg-devel] [PATCH] hlsenc: don't use %s for strftime on msvc
2017-02-21 21:31 GMT+08:00 Steven Liu : > > > 2017-02-21 15:26 GMT+08:00 Hendrik Leppkes : > >> On Tue, Feb 21, 2017 at 8:24 AM, Hendrik Leppkes >> wrote: >> > MSVC doesn't support the %s time format, and instead of returning an >> > error the invalid parameter handler is invoked which (by default) >> > terminates the process. >> > --- >> > libavformat/hlsenc.c | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c >> > index e673f59710..cf2e3381c4 100644 >> > --- a/libavformat/hlsenc.c >> > +++ b/libavformat/hlsenc.c >> > @@ -1025,7 +1025,8 @@ static const char * get_default_pattern_localtime_ >> fmt(void) >> > struct tm *p, tmbuf; >> > p = localtime_r(&t, &tmbuf); >> > // no %s support when strftime returned error or left format >> string unchanged >> > -return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ? >> "-%Y%m%d%H%M%S.ts" : "-%s.ts"; >> > +// also no %s support on MSVC, which invokes the invalid parameter >> handler on unsupported format strings, instead of returning an error >> > +return (HAVE_LIBC_MSVCRT || !strftime(b, sizeof(b), "%s", p) || >> !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts"; >> > } >> > >> > static int hls_write_header(AVFormatContext *s) >> > -- >> > 2.11.0.windows.1 >> > >> >> An alternative would be testing for %s support in configure somehow >> and setting a config variable for that, instead of probing at runtime >> here. >> >> Yes, Agreed! > >> - Hendrik >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > > LGTM > Applied! Thanks ___ 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
On Fri, Feb 24, 2017 at 06:43:20PM -0800, Thomas Turner wrote: > On Wed, Feb 22, 2017 at 2:16 PM, Michael Niedermayer > wrote: > > > 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? > > > x86_32 machine produces a negative overflow for double precision value. But > unable to figure out precisely why. my guesstimation would be because of > the difference in floating point arithmetic. > > > or is that unknown ? > > did you succeed in reproduring the issue ? > > > trying to compile 32bit on my 64bit machine with: > > ./configure --enable-debug=3 --cc='cc -m32' > but i get the following error: > > cc -m32 is unable to create an executable file. > If cc -m32 is a cross-compiler, use the --enable-cross-compile option. > Only do this if you know what cross compiling means. > C compiler test failed. try this: ./configure --cc='ccache gcc' --enable-debug=3 --arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32 --enable-cross-compile [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ 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
On Wed, Feb 22, 2017 at 2:16 PM, Michael Niedermayer wrote: > 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? > x86_32 machine produces a negative overflow for double precision value. But unable to figure out precisely why. my guesstimation would be because of the difference in floating point arithmetic. > or is that unknown ? > did you succeed in reproduring the issue ? > trying to compile 32bit on my 64bit machine with: ./configure --enable-debug=3 --cc='cc -m32' but i get the following error: cc -m32 is unable to create an executable file. If cc -m32 is a cross-compiler, use the --enable-cross-compile option. Only do this if you know what cross compiling means. C compiler test failed. > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > There will always be a question for which you do not know the correct > answer. > > ___ > 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]lswr/rematrix: Remove an aggressive loop optimization / undefined behaviour
On Fri, Feb 24, 2017 at 11:21:54AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes a gcc warning (tested 6.3.0). > > Please comment, Carl Eugen > rematrix.c |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > 38e092f00db2021f4dfb7677cc1b18bc66808754 > 0001-lswr-rematrix-Remove-an-aggressive-loop-optimization.patch > From 422e4b2fba6f3c9fbf930908474029cb8088bc46 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Fri, 24 Feb 2017 11:16:26 +0100 > Subject: [PATCH] lswr/rematrix: Remove an aggressive loop optimization. > > Fixes undefined behaviour and a gcc warning: > libswresample/rematrix.c:376:47: warning: iteration 64 invokes undefined > behavior > --- > libswresample/rematrix.c |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) should be ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v7] - Added Turing codec interface for ffmpeg
On 23/02/17 20:47, Mark Thompson wrote:
> On 21/02/17 17:15, Saverio Blasi wrote:
>> Hi all,
>>
>> We have recently circulated this new iteration (see below) of our work
>> towards integrating our HEVC Turing codec within FFMpeg. Assuming that there
>> are no more requests for changes, we would like to understand what is the
>> timeline for integration within the project.
>>
>> Thanks a lot,
>>
>> All the best,
>>
>> Saverio Blasi, PhD
>> Senior Research Engineer
>> BBC Research & Development
>> Centre House|56 Wood Lane|London|W12 7SB
>>
>>
>>
>>
>> -Original Message-
>> From: Saverio Blasi [mailto:saverio.bl...@bbc.co.uk]
>> Sent: 13 February 2017 13:37
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Saverio Blasi
>> Subject: [PATCH v7] - Added Turing codec interface for ffmpeg
>>
>> - This patch contains the changes to interface the Turing codec
>> (http://turingcodec.org/) with ffmpeg. The patch was modified to address the
>> comments in the review as follows:
>> - Added a pkg-config file to list all dependencies required by libturing.
>> This should address the issue pointed out by Hendrik Leppkes on Fri
>> 18/11/2016
>> - As per suggestions of wm4, two functions (add_option and
>> finalise_options) have been created. The former appends new options while
>> the latter sets up the argv array of pointers to char* accordingly.
>> add_option re-allocates the buffer for options using av_realloc
>> - Additionally, both these functions handle the errors in case the memory
>> wasn't allocated correctly
>> - malloc|free|realloc have been substituted with their corresponding
>> av_{malloc|free|realloc} version
>> - Check on bit-depth has been removed since the ffmpeg already casts the
>> right pix_fmt and bit depth
>> - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
>> - Changed usage of av_free with av_freep and fixed calls to free arrays
>> - Added brackets to all if and for statements
>> - Avoid repetition of code to free arrays in case of failure to initialise
>> the libturing encoder
>> - Some fixes to address the review from wm4 and Mark Thompson received on
>> Wed 08/02/2017
>> - Fixed indentation
>> ---
>> LICENSE.md | 1 +
>> configure | 5 +
>> libavcodec/Makefile| 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/libturing.c | 320
>> +
>> 5 files changed, 328 insertions(+)
>> create mode 100644 libavcodec/libturing.c
>>
>> diff --git a/LICENSE.md b/LICENSE.md
>> index 640633c..86e5371 100644
>> --- a/LICENSE.md
>> +++ b/LICENSE.md
>> @@ -85,6 +85,7 @@ The following libraries are under GPL:
>> - frei0r
>> - libcdio
>> - librubberband
>> +- libturing
>> - libvidstab
>> - libx264
>> - libx265
>> diff --git a/configure b/configure
>> index 7154142..a27cb8b 100755
>> --- a/configure
>> +++ b/configure
>> @@ -255,6 +255,7 @@ External library support:
>>--enable-libssh enable SFTP protocol via libssh [no]
>>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
>>--enable-libtheora enable Theora encoding via libtheora [no]
>> + --enable-libturing enable H.265/HEVC encoding via libturing [no]
>>--enable-libtwolame enable MP2 encoding via libtwolame [no]
>>--enable-libv4l2 enable libv4l2/v4l-utils [no]
>>--enable-libvidstab enable video stabilization using vid.stab [no]
>> @@ -1562,6 +1563,7 @@ EXTERNAL_LIBRARY_LIST="
>> libssh
>> libtesseract
>> libtheora
>> +libturing
>> libtwolame
>> libv4l2
>> libvidstab
>> @@ -2858,6 +2860,7 @@ libspeex_decoder_deps="libspeex"
>> libspeex_encoder_deps="libspeex"
>> libspeex_encoder_select="audio_frame_queue"
>> libtheora_encoder_deps="libtheora"
>> +libturing_encoder_deps="libturing"
>> libtwolame_encoder_deps="libtwolame"
>> libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>> libvorbis_decoder_deps="libvorbis"
>> @@ -5131,6 +5134,7 @@ die_license_disabled gpl frei0r die_license_disabled
>> gpl libcdio die_license_disabled gpl librubberband die_license_disabled
>> gpl libsmbclient
>> +die_license_disabled gpl libturing
>> die_license_disabled gpl libvidstab
>> die_license_disabled gpl libx264
>> die_license_disabled gpl libx265
>> @@ -5789,6 +5793,7 @@ enabled libssh&& require_pkg_config libssh
>> libssh/sftp.h sftp_init
>> enabled libspeex && require_pkg_config speex speex/speex.h
>> speex_decoder_init -lspeex
>> enabled libtesseract && require_pkg_config tesseract tesseract/capi.h
>> TessBaseAPICreate
>> enabled libtheora && require libtheora theora/theoraenc.h
>> th_info_init -ltheoraenc -ltheoradec -logg
>> +enabled libturing && require_pkg_config libturing turing.h
>> turing_version
>> enabled libtwolame&& require libtwolame twolame.h twolame_init
>> -ltwolame &&
>>
Re: [FFmpeg-devel] [PATCH 3/3] MAINTAINERS: Add Rodger Combs to ffmpeg-security
On Thu, Feb 23, 2017 at 05:34:42PM +0100, Michael Niedermayer wrote: > Rodger Combs will be added to the ffmpeg-security alias when this patch is > applied > > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e39cf88798..6b17b13187 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -60,7 +60,7 @@ mailing lists Baptiste Coudurier, > Lou Logan > Google+ Paul B Mahol, Michael Niedermayer, > Alexander Strasser > Twitter Lou Logan, Reynaldo H. Verdejo > Pinochet > Launchpad Timothy Gu > -ffmpeg-security Andreas Cadhalpun, Carl Eugen Hoyos, > Clément Bœsch, Michael Niedermayer, Reimar Doeffinger, wm4 > +ffmpeg-security Andreas Cadhalpun, Carl Eugen Hoyos, > Clément Bœsch, Michael Niedermayer, Reimar Doeffinger, Rodger Combs, wm4 > sure -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] MAINTAINERS: add wm4 to ffmpeg-security
On Thu, Feb 23, 2017 at 05:34:41PM +0100, Michael Niedermayer wrote: > wm4 will be added to the ffmpeg-security alias when this patch is applied > > Signed-off-by: Michael Niedermayer > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index db5534639b..e39cf88798 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -60,7 +60,7 @@ mailing lists Baptiste Coudurier, > Lou Logan > Google+ Paul B Mahol, Michael Niedermayer, > Alexander Strasser > Twitter Lou Logan, Reynaldo H. Verdejo > Pinochet > Launchpad Timothy Gu > -ffmpeg-security Andreas Cadhalpun, Carl Eugen Hoyos, > Clément Bœsch, Michael Niedermayer, Reimar Doeffinger > +ffmpeg-security Andreas Cadhalpun, Carl Eugen Hoyos, > Clément Bœsch, Michael Niedermayer, Reimar Doeffinger, wm4 if you're waiting for someone on that list to ack, LGTM -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/utils: Fix a compilation warning, make a parameter const
2017-02-24 4:09 GMT+01:00 Michael Niedermayer : >> -static int apply_param_change(AVCodecContext *avctx, AVPacket *avpkt) >> +static int apply_param_change(AVCodecContext *avctx, const AVPacket *avpkt) > > should be ok Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lswr/rematrix: Remove an aggressive loop optimization / undefined behaviour
Hi!
Attached patch fixes a gcc warning (tested 6.3.0).
Please comment, Carl Eugen
From 422e4b2fba6f3c9fbf930908474029cb8088bc46 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 24 Feb 2017 11:16:26 +0100
Subject: [PATCH] lswr/rematrix: Remove an aggressive loop optimization.
Fixes undefined behaviour and a gcc warning:
libswresample/rematrix.c:376:47: warning: iteration 64 invokes undefined
behavior
---
libswresample/rematrix.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 4721063..03b9b20 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -371,9 +371,10 @@ av_cold static int auto_matrix(SwrContext *s)
s->matrix[1] - s->matrix[0], s->matrix_encoding, s);
if (ret >= 0 && s->int_sample_fmt == AV_SAMPLE_FMT_FLTP) {
-int i;
-for (i = 0; i <
FF_ARRAY_ELEMS(s->matrix[0])*FF_ARRAY_ELEMS(s->matrix[0]); i++)
-s->matrix_flt[0][i] = s->matrix[0][i];
+int i, j;
+for (i = 0; i < FF_ARRAY_ELEMS(s->matrix[0]); i++)
+for (j = 0; j < FF_ARRAY_ELEMS(s->matrix[0]); j++)
+s->matrix_flt[i][j] = s->matrix[i][j];
}
return ret;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey
Makes sure the output can be mapped as OpenGL texture. This is what at least video players normally want. --- libavcodec/videotoolbox.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c index 2ebe60fb5c..824f2d8e68 100644 --- a/libavcodec/videotoolbox.c +++ b/libavcodec/videotoolbox.c @@ -477,6 +477,7 @@ static CFDictionaryRef videotoolbox_buffer_attributes_create(int width, CFDictionarySetValue(buffer_attributes, kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties); CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w); CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h); +CFDictionarySetValue(buffer_attributes, kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue); CFRelease(io_surface_properties); CFRelease(cv_pix_fmt); -- 2.11.0 ___ 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/24/17, Carl Eugen Hoyos wrote: > 2017-02-24 1:55 GMT+01:00 Paul B Mahol : > >>> What I meant was: >>> How can I create a mov file with FFmpeg that fails without >>> ignore_editlist? >>> The sample you provided was made with FFmpeg / libavformat. >> >> The sample was only trimmed with FFmpeg. For full samples buy certain >> software. > > I understand this. > > So far, whenever I "trimmed" a sample with FFmpeg, I did not have to > use ignore_editlist for decoding. So my question was, did you do anything > special when trimming the sample or did I just not test often enough? Ask guy on doom9 forum who made that sample. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/videotoolbox: allow not setting the kCVPixelBufferPixelFormatTypeKey
If AVVideotoolboxContext.cv_pix_fmt_type is set to 0, don't set the kCVPixelBufferPixelFormatTypeKey value on the VT decoder. This makes VT output its native format, which can be much faster on some hardware iterations (if the native format does not match with the requested format, it will be converted, which is slow). The default is still forcing nv12. --- TODO: minor libavcodec bump --- libavcodec/videotoolbox.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c index 1288aa5087..2ebe60fb5c 100644 --- a/libavcodec/videotoolbox.c +++ b/libavcodec/videotoolbox.c @@ -472,7 +472,8 @@ static CFDictionaryRef videotoolbox_buffer_attributes_create(int width, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks); -CFDictionarySetValue(buffer_attributes, kCVPixelBufferPixelFormatTypeKey, cv_pix_fmt); +if (pix_fmt) +CFDictionarySetValue(buffer_attributes, kCVPixelBufferPixelFormatTypeKey, cv_pix_fmt); CFDictionarySetValue(buffer_attributes, kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties); CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w); CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h); -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink_enc: add support to specify field order
Am 24.02.2017 um 00:32 schrieb Marton Balint:
>
> On Thu, 23 Feb 2017, Matthias Hunstock wrote:
>
>> Am 23.02.2017 um 17:24 schrieb Marton Balint:
The "@mode" syntax does not work for output devices. Let me add a
patch,
I will send it tonight.
>>>
>>> Please don't. The @mode syntax is insane. You need a different @mode for
>>> different hardware to get the same output format. @mode may even be
>>> different across driver versions.
>>
>> I know... the numbers are really a mess.
>>
>> What about supporting the mode strings? They are constant:
>>
>> bmdModeHD1080i50 = /* 'Hi50' */ 0x48693530
>>
>> At least for capture this is IMO a benefit:
>>
>> ffmpeg -f decklink -i 'DeckLink Duo@Hi50'
>>
>> For playout... well if the automatic detection works and interlaced flag
>> is always correct, fps is always correct (30 vs 29.97)... to be honest:
>> if I'd do a setup, I'd sleep better with an explicit mode. But yeah, not
>> those numbers.
>
> Specifying the mode based on the decklink fourcc makes more sense.
>
> On the other hand, for output, you'd still have to check if the stream
> parameters are correct and if they are corresponding to the wanted mode.
> So if the user specify the mode with a decklink mode fourcc, you could
> only do a check like this (with &&):
>
> if ((bmd_width == width &&
> bmd_height == height &&
> !av_cmp_q(mode_tb, target_tb) &&
> field_order_eq(field_order, bmd_field_dominance) &&
> mode == bmd_mode) || i == num) {
This disallows "hacks" like doing interlaced playout of progressive
content or playout 30 fps with 29.97fps.
Maybe it should just check widht and height for a given mode? Like:
if ((bmd_width == width &&
bmd_height == height &&
mode == bmd_mode)
||
(!mode &&
!av_cmp_q(mode_tb, target_tb) &&
bmd_width == width &&
bmd_height == height &&
field_order_eq(field_order, bmd_field_dominance))
||
i == num /* deprecated */) {
(ORs seperated for readability)
Or would you suggest that a user forces such situation e.g. with -vf
setfields or -r ?
> For input, using a decklink fourcc to specify a mode would be definitely
> useful.
>
> However, I don't like the @anything part in the device name. If you add
> this feature, I'd very much prefer a separate option of the device,
> 'format' maybe. I'd even deprecate @mode in the device name later.
ACK
For the time being, I'd like to see your patches pushed since they
improve the situation and the patchset does lots of other things.
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
