Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.
On 29 August 2016 at 16:43, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-29 8:17 GMT+02:00 Matt Oliver : > > The fifo muxer works without pthreads due to the existing pthread > > wrappers already available within ffmpeg for other platforms. > > It should probably still depend on "threads" at least, assuming the > thread-wrapper we have provides enough threading features for the > muxer. > You are correct updated patch is attached. > How did you test this? > (How can I test?) > There is a FATE test already added for the fifo muxer. I used that to test for mingw and msvc. 0001-configure-Remove-fifo-muxers-dependency-on-pthreads.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.
Hi! 2016-08-29 9:00 GMT+02:00 Matt Oliver : > On 29 August 2016 at 16:43, Carl Eugen Hoyos wrote: > >> How did you test this? >> (How can I test?) > > There is a FATE test already added for the fifo muxer. I used that to test > for mingw and msvc. What I meant is: If I remove pthreads from my system, fifo compilation fails, which imo implies that the patch is wrong. But I may miss something. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.
On Mon, Aug 29, 2016 at 9:28 AM, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-29 9:00 GMT+02:00 Matt Oliver : >> On 29 August 2016 at 16:43, Carl Eugen Hoyos wrote: >> >>> How did you test this? >>> (How can I test?) >> >> There is a FATE test already added for the fifo muxer. I used that to test >> for mingw and msvc. > > What I meant is: > If I remove pthreads from my system, fifo compilation fails, which imo > implies that the patch is wrong. > But I may miss something. > Obviously it requires some sort of thread implementation, but that doesn't necessarily have to be pthreads, it could be w32threads. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.
On 29 August 2016 at 17:28, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-29 9:00 GMT+02:00 Matt Oliver : > > On 29 August 2016 at 16:43, Carl Eugen Hoyos wrote: > > > >> How did you test this? > >> (How can I test?) > > > > There is a FATE test already added for the fifo muxer. I used that to > test > > for mingw and msvc. > > What I meant is: > If I remove pthreads from my system, fifo compilation fails, which imo > implies that the patch is wrong. > But I may miss something. > The second version is the correct one. You need w32threads/os2threads enabled if not using pthreads. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Remove fifo muxers dependency on pthreads.
2016-08-29 10:04 GMT+02:00 Matt Oliver : > > The second version is the correct one. You need > w32threads/os2threads enabled if not using pthreads. Thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support
> Hi all > > Attached is a patch for the above. > > 10-bit HEVC encoding is a new feature of the latest Pascal Nvidia GPUs, > released in the past few months; I’ve added support for the yuv420p10le and > yuv444p10le pixel formats. > > Rate control lookahead is available on pre-Pascal models too but is available > with the latest SDK/latest drivers. > > As part of this I’ve bumped the required SDK version to the latest, which is > 7. > > Feedback welcome. This is only my second patch; I seem to average about one a > year :) > > Regards > > Oliver pushed with minimal changes adjusting for the changes in configure and adding the lookahead parameter to h264 as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Patch for libavformat/crypto to add seeking on read
crypto allows reading of data which has been aes-128-cbc encrypted given a
key and an iv.
But it did not handle filetypes which require seeking... e.g. it failed on
an encrypted .mp4 file.
example:
take 25.mp4 created with:
ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0
-f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22
-timecode 10:00:00:00 -r 25 -y out\25.mp4
encrypt with:
openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv
12345678901234567890123456789012 -in 25.mp4 -out 25.enc
then to transcode in ffmpeg:
ffmpeg -key 12345678901234567890123456789012 -iv
12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y
25dec.mp4
prior to this modification, the transcode would fail.
Note also: crypto previously marked both reads and writes as streamed,
which caused the whole file
to be read before the transcode started. Now, for read only, if the
underlying layer is not marked as streamed,
then crypto is not. This should enable efficient reading of encrypted
containers which require seeking.
this is my first patch for ffmpeg; guidance appreciated.
---
libavformat/crypto.c | 115
+--
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/libavformat/crypto.c b/libavformat/crypto.c
index 2999f50..23bc0a6 100644
--- a/libavformat/crypto.c
+++ b/libavformat/crypto.c
@@ -26,7 +26,8 @@
#include "internal.h"
#include "url.h"
-#define MAX_BUFFER_BLOCKS 150
+// encourage reads of 4096 bytes - 1 block is always retained.
+#define MAX_BUFFER_BLOCKS 257
#define BLOCKSIZE 16
typedef struct CryptoContext {
@@ -36,6 +37,8 @@ typedef struct CryptoContext {
outbuffer[BLOCKSIZE*MAX_BUFFER_BLOCKS];
uint8_t *outptr;
int indata, indata_used, outdata;
+int64_t position; // position in file - used in seek
+int flags;
int eof;
uint8_t *key;
int keylen;
@@ -109,6 +112,7 @@ static int crypto_open2(URLContext *h, const char *uri,
int flags, AVDictionary
const char *nested_url;
int ret = 0;
CryptoContext *c = h->priv_data;
+c->flags = flags;
if (!av_strstart(uri, "crypto+", &nested_url) &&
!av_strstart(uri, "crypto:", &nested_url)) {
@@ -117,6 +121,8 @@ static int crypto_open2(URLContext *h, const char *uri,
int flags, AVDictionary
goto err;
}
+c->position = 0L;
+
if (flags & AVIO_FLAG_READ) {
if ((ret = set_aes_arg(c, &c->decrypt_key, &c->decrypt_keylen,
c->key, c->keylen, "decryption key")) < 0)
@@ -152,6 +158,10 @@ static int crypto_open2(URLContext *h, const char
*uri, int flags, AVDictionary
ret = av_aes_init(c->aes_decrypt, c->decrypt_key, BLOCKSIZE*8, 1);
if (ret < 0)
goto err;
+
+// pass back information about the context we openned
+if (c->hd->is_streamed)
+h->is_streamed = c->hd->is_streamed;
}
if (flags & AVIO_FLAG_WRITE) {
@@ -163,12 +173,13 @@ static int crypto_open2(URLContext *h, const char
*uri, int flags, AVDictionary
ret = av_aes_init(c->aes_encrypt, c->encrypt_key, BLOCKSIZE*8, 0);
if (ret < 0)
goto err;
+// for write, we must be streamed
+// - linear write only for crytpo aes-128-cbc
+h->is_streamed = 1;
}
c->pad_len = 0;
-h->is_streamed = 1;
-
err:
return ret;
}
@@ -183,6 +194,7 @@ retry:
memcpy(buf, c->outptr, size);
c->outptr += size;
c->outdata -= size;
+c->position = c->position + size;
return size;
}
// We avoid using the last block until we've found EOF,
@@ -222,6 +234,102 @@ retry:
goto retry;
}
+static int64_t crypto_seek(URLContext *h, int64_t pos, int whence)
+{
+CryptoContext *c = h->priv_data;
+int64_t block;
+int64_t newpos;
+
+if (c->flags & AVIO_FLAG_WRITE) {
+av_log(h, AV_LOG_ERROR,
+"Crypto: seek not supported for write\r\n");
+return -1L;
+}
+
+// reset eof, else we won't read it correctly if we already hit eof.
+c->eof = 0;
+
+switch (whence) {
+case SEEK_SET:
+break;
+case SEEK_CUR:
+pos = pos + c->position;
+break;
+case SEEK_END: {
+int64_t newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
+if (newpos < 0) {
+av_log(h, AV_LOG_ERROR,
+"Crypto: seek_end - can't get file size (pos=%lld)\r\n",
pos);
+return newpos;
+}
+pos = newpos - pos;
+}
+break;
+case AVSEEK_SIZE:
+return ffurl_seek( c->hd, pos, AVSEEK_SIZE );
+default:
+av_log(h, AV_LOG_ERROR,
+"Crypto: no support for seek where 'whence' is %d\r\n",
whence);
+return -1L;
+}
+
+c->outdata = 0;
+c->indata = 0;
+c->indata_used = 0;
+c->outptr = c->outbuffer;
+
+// identify the block containing the IV for the
+
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On Mon, Aug 29, 2016 at 04:49:02PM +1000, Matt Oliver wrote: > On 28 August 2016 at 19:58, Michael Niedermayer > wrote: > > > On Sun, Aug 28, 2016 at 06:50:58PM +1000, Matt Oliver wrote: > > > The dlopen function is modified to prevent loading dll's from the current > > > directory for improved program security for library users. This extends > > > similar functionality from the recently applied SetDllDirectory patch > > > except that it adds additional security for library users as well (as > > > opposed to just program users). > > > > > os_support.h | 49 + > > > 1 file changed, 49 insertions(+) > > > 89c775ecc8ac03d001131dd50e043ba57ffe5420 0001-lavf-os_support-Add-safe- > > win32-dlopen-dlclose-dlsym-.patch > > > From 666ab2f7d64cfa94984881aca83035993365 Mon Sep 17 00:00:00 2001 > > > From: Matt Oliver > > > Date: Sun, 21 Aug 2016 16:06:59 +1000 > > > Subject: [PATCH 1/2] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym > > > functions. > > > > breaks mingw32 > > > > In file included from src/libavformat/internal.h:28:0, > > from src/libavdevice/lavfi.c:44: > > src/libavformat/os_support.h: In function ‘win32_dlopen’: > > src/libavformat/os_support.h:303:46: error: > > ‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’ > > undeclared (first use in this function) > > src/libavformat/os_support.h:303:46: note: each undeclared identifier is > > reported only once for each function it appears in > > src/libavformat/os_support.h:303:84: error: > > ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ undeclared (first use in this function) > > In file included from src/libavformat/internal.h:28:0, > > from src/libavdevice/gdigrab.c:32: > > src/libavformat/os_support.h: In function ‘win32_dlopen’: > > src/libavformat/os_support.h:303:46: error: > > ‘LOAD_LIBRARY_SEARCH_APPLICATION_DIR’ > > undeclared (first use in this function) > > src/libavformat/os_support.h:303:46: note: each undeclared identifier is > > reported only once for each function it appears in > > src/libavformat/os_support.h:303:84: error: > > ‘LOAD_LIBRARY_SEARCH_SYSTEM32’ undeclared (first use in this function) > > make: *** [libavdevice/lavfi.o] Error 1 > > > > It appears older versions of mingw must not have the appropriate defines > (as the version i tested against worked fine). > Anyway updated patch attached which corrects the issue. > os_support.h | 55 +++ > 1 file changed, 55 insertions(+) > c2ef0f80c68893318f803e65204583ee119636e7 > 0001-lavf-os_support-Add-safe-win32-dlopen-dlclose-dlsym-.patch > From b77d65f76d22b4e9c5e630a8ae9154e98f9bfd88 Mon Sep 17 00:00:00 2001 > From: Matt Oliver > Date: Mon, 29 Aug 2016 16:45:02 +1000 > Subject: [PATCH 1/2] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym > functions. > > The dlopen function is modified to prevent loading dll's from the > current directory for improved program security for library users and > not just those that use ffmpeg programs. > --- > libavformat/os_support.h | 55 > > 1 file changed, 55 insertions(+) Tested-by: michael on mingw32 & 64 cant comment on the code itsef [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder
> Am 28.08.2016 um 22:11 schrieb Michael Niedermayer : > >> On Sun, Aug 28, 2016 at 09:50:41PM +0200, Hendrik Leppkes wrote: >> On Sun, Aug 28, 2016 at 9:21 PM, Michael Niedermayer >> wrote: >>> On Sun, Aug 28, 2016 at 12:03:38PM -0300, James Almer wrote: >>> [...] Also, the changelog entry line can be part of the encoder patch, no need to have it separate. >>> >>> actually, i was just thinking having Changelog + version + APIChanges >>> changes separate from the main patch could make sense as these "always" >>> conflict and need an extra manual >>> step to work around. Having them separate makes testing slightly >>> simpler >>> not specific to this patch of course >> >> Perhaps during development, but it should really be squashed in when >> its applied then. > > yes of course The always changing review was my reason to ask Umair to split it. As said, it's not a pain during review then. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Only read JFIF thumbnail size if the segment is long enough.
On Mon, Aug 29, 2016 at 12:12:34AM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #5805. > > Please comment, Carl Eugen > mjpegdec.c |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > 4ccdddc80ba0dbd460f9d7ecb046cad73d50ea51 > 0001-lavc-mjpegdec-Only-read-JFIF-thumbnail-size-if-the-s.patch > From 215d45b2226cb5681be09bb4e0a2c135925ed6f5 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos > Date: Mon, 29 Aug 2016 00:09:06 +0200 > Subject: [PATCH] lavc/mjpegdec: Only read JFIF thumbnail size if the segment > is long enough. > > Fixes ticket #5805. LGTM, can you add a fate test for this ? thx [...] -- 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
Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option
2016-08-26 0:11 GMT+08:00 Michael Niedermayer : > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote: > > Tested passed at : > > 1. OSX > > 2. Linux > > 3. Windows > > > 4. Ubuntu+wine+MinGW > > confirmed it works > but > doesnt work on qemu-mips > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L > /usr/mips-linux-gnu/' \ > --samples=... --enable-gpl --cross-prefix=/usr/mips-linux-gnu/bin/ \ > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > --enable-cross-compile --disable-pthreads --disable-mipsfpu --disable-iconv > > make distclean ; ./c-qemu && make -j12 fate-filter-hls-append > first it fails with > GEN tests/data/hls-list-append.m3u8 > make: *** [tests/data/hls-list-append.m3u8] Error 255 > > reruning make -j12 fate-filter-hls-append > results in: > > --- tests/ref/fate/filter-hls-append2016-08-25 17:43:18.565618034 > +0200 > +++ tests/data/fate/filter-hls-append 2016-08-25 17:47:18.681623092 > +0200 > @@ -3,1154 +3,770 @@ > #codec_id 0: pcm_s16le > #sample_rate 0: 44100 > #channel_layout 0: 4 > -0, 0, 0, 1152, 2304, 0x593ea430 > -0, 1152, 1152, 1152, 2304, 0xde328304 > -0, 2304, 2304, 1152, 2304, 0x12f673c9 > -0, 3456, 3456, 1152, 2304, 0x4c7672a1 > -0, 4608, 4608, 1152, 2304, 0xd38577f4 > -0, 5760, 5760, 1152, 2304, 0xc9d677cc > -0, 6912, 6912, 1152, 2304, 0xc97e882a > -0, 8064, 8064, 1152, 2304, 0xaacf67ec > -0, 9216, 9216, 1152, 2304, 0x3a9b7ea5 > -0, 10368, 10368, 1152, 2304, 0x30258348 > -0, 11520, 11520, 1152, 2304, 0x08da8783 > -0, 12672, 12672, 1152, 2304, 0x4830619e > -0, 13824, 13824, 1152, 2304, 0xcf476f69 > -0, 14976, 14976, 1152, 2304, 0x377e7ce5 > -0, 16128, 16128, 1152, 2304, 0x00a27fad > -0, 17280, 17280, 1152, 2304, 0xe4a46de3 > -0, 18432, 18432, 1152, 2304, 0x938c8751 > -0, 19584, 19584, 1152, 2304, 0x239982b5 > -0, 20736, 20736, 1152, 2304, 0x9a0d7655 > -0, 21888, 21888, 1152, 2304, 0x4adf7fbf > -0, 23040, 23040, 1152, 2304, 0xdb8b7b16 > -0, 24192, 24192, 1152, 2304, 0x25908560 > -0, 25344, 25344, 1152, 2304, 0xb5dd7be7 > -0, 26496, 26496, 1152, 2304, 0x4368796d > -0, 27648, 27648, 1152, 2304, 0xba3a7fd0 > ... > make: *** [fate-filter-hls-append] Error 1 > > [...] > > > Is this base on Ubuntu? What's the Ubuntu version? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] add option hls_init_time to set init hls window segment
On Sat, Aug 27, 2016 at 10:42:25PM +0800, Steven Liu wrote:
> 2016-08-27 19:15 GMT+08:00 Steven Liu :
>
> >
> >
> > 2016-08-27 18:25 GMT+08:00 Michael Niedermayer :
> >
> >> On Sat, Aug 27, 2016 at 07:44:01AM +0800, Steven Liu wrote:
> >> > 2016-08-27 4:49 GMT+08:00 Michael Niedermayer :
> >> >
> >> > > On Fri, Aug 26, 2016 at 05:30:41PM +0800, Steven Liu wrote:
> >> > > > recover segments duration time by hls_time after init hls window.
> >> > > > This is reuqested by Ibrahim Tachijian
> >> > > >
> >> > > > Signed-off-by: LiuQi
> >> > > > ---
> >> > > > libavformat/hlsenc.c | 14 +-
> >> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
> >> > > [...]
> >> > > > hlsenc.c | 14 +-
> >> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
> >> > > > f38066079d46206d1bc970f026a7a9de25ace8d1
> >> 0001-add-option-hls_init_time-
> >> > > to-set-init-hls-window-segm.patch
> >> > > > From 937e5301414f1c43c4c564ee59a4dfeee690293c Mon Sep 17 00:00:00
> >> 2001
> >> > > > From: Steven Liu
> >> > > > Date: Fri, 26 Aug 2016 14:34:58 +0800
> >> > > > Subject: [PATCH 1/2] add option hls_init_time to set init hls window
> >> > > segment
> >> > > > duration
> >> > > >
> >> > > > And recover segments duration time by hls_time after init hls
> >> window.
> >> > > > This is reuqested by Ibrahim Tachijian
> >> > > >
> >> > > > Signed-off-by: LiuQi
> >> > > > ---
> >> > > > libavformat/hlsenc.c | 14 +-
> >> > > > 1 file changed, 13 insertions(+), 1 deletion(-)
> >> > > >
> >> > > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> > > > index e65f002..f5ceb60 100644
> >> > > > --- a/libavformat/hlsenc.c
> >> > > > +++ b/libavformat/hlsenc.c
> >> > > > @@ -85,6 +85,7 @@ typedef struct HLSContext {
> >> > > > AVFormatContext *vtt_avf;
> >> > > >
> >> > > > float time;// Set by a private option.
> >> > > > +float init_time;// Set by a private option.
> >> > > > int max_nb_segments; // Set by a private option.
> >> > > > int wrap; // Set by a private option.
> >> > >
> >> > > the comment looks oddly aligned, it should be at the same horizontal
> >> > > position as teh others
> >> > >
> >> > >
> >> > > > uint32_t flags;// enum HLSFlags
> >> > > > @@ -706,7 +707,7 @@ static int hls_write_header(AVFormatContext *s)
> >> > > > int vtt_basename_size;
> >> > > >
> >> > > > hls->sequence = hls->start_sequence;
> >> > > > -hls->recording_time = hls->time * AV_TIME_BASE;
> >> > > > +hls->recording_time = (hls->init_time ? hls->init_time :
> >> hls->time)
> >> > > * AV_TIME_BASE;
> >> > > > hls->start_pts = AV_NOPTS_VALUE;
> >> > > >
> >> > > > if (hls->format_options_str) {
> >> > > > @@ -860,9 +861,19 @@ static int hls_write_packet(AVFormatContext
> >> *s,
> >> > > AVPacket *pkt)
> >> > > > AVStream *st = s->streams[pkt->stream_index];
> >> > > > int64_t end_pts = hls->recording_time * hls->number;
> >> > > > int is_ref_pkt = 1;
> >> > >
> >> > > > +int init_list_dur = 0;
> >> > > > +int after_init_list_dur = 0;
> >> > >
> >> > > the initialized value is not used
> >> > > also the declaration can be moved into the if() below
> >> > >
> >> > > > int ret, can_split = 1;
> >> > > > int stream_index = 0;
> >> > > >
> >> > > > +if (hls->sequence - hls->nb_entries > hls->start_sequence &&
> >> > > hls->init_time > 0) {
> >> > > > +/* reset end_pts, hls->recording_time at end of the init
> >> hls
> >> > > list */
> >> > > > +init_list_dur = hls->init_time * hls->nb_entries *
> >> AV_TIME_BASE;
> >> > > > +after_init_list_dur = (hls->sequence - hls->nb_entries ) *
> >> > > hls->time * AV_TIME_BASE;
> >> > > > +hls->recording_time = hls->time * AV_TIME_BASE;
> >> > > > +end_pts = init_list_dur + after_init_list_dur ;
> >> > > > +}
> >> > > > +
> >> > > > if( st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE ) {
> >> > > > oc = hls->vtt_avf;
> >> > > > stream_index = 0;
> >> > > > @@ -972,6 +983,7 @@ static int hls_write_trailer(struct
> >> AVFormatContext
> >> > > *s)
> >> > > [...]
> >> > >
> >> > >
> >> > > --
> >> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> >> 87040B0FAB
> >> > >
> >> > > Let us carefully observe those good qualities wherein our enemies
> >> excel us
> >> > > and endeavor to excel them, by avoiding what is faulty, and imitating
> >> what
> >> > > is excellent in them. -- Plutarch
> >> > >
> >> > > ___
> >> > > ffmpeg-devel mailing list
> >> > > ffmpeg-devel@ffmpeg.org
> >> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> > >
> >> > > Update patch
> >>
> >> > hlsenc.c | 14 +-
> >> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >> > 2feb683487b70430f2ea423d2678d7f30d0c3079
> >> 0001-add-option-hls_init_time-to-set-init-hls-window-segm.patch
> >> > From dfad
Re: [FFmpeg-devel] [PATCH 2/2] add option hls_init_time document
On Sat, Aug 27, 2016 at 07:42:18AM +0800, Steven Liu wrote:
> 2016-08-27 6:00 GMT+08:00 Ibrahim Tachijian :
>
> > What do you think about something like this?
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index 2548aeb..c39a6a0 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -357,6 +357,12 @@ segmentation.
> > This muxer supports the following options:
> >
> > @table @option
> > +@item hls_init_time @var{seconds}
> > +Set the initial target segment length in seconds. Default value is
> > @var{0}.
> > +Segment will be cut on the next key frame after this time has passed on
> > the first m3u8 list.
> > +After the initial playlist is filled @command{ffmpeg} will cut segments
> > +at duration equal to @code{hls_time}
> > +
> > @item hls_time @var{seconds}
> > Set the target segment length in seconds. Default value is 2.
> > Segment will be cut on the next key frame after this time has passed.
> >
> > On Fri, Aug 26, 2016 at 11:32 AM Steven Liu
> > wrote:
> >
> >>
> >> 2016-08-26 17:31 GMT+08:00 Steven Liu :
> >>
> >>>
> >>> Signed-off-by: LiuQi
> >>> ---
> >>> doc/muxers.texi | 7 +++
> >>> 1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >>> index 2548aeb..4db3809 100644
> >>> --- a/doc/muxers.texi
> >>> +++ b/doc/muxers.texi
> >>> @@ -357,6 +357,13 @@ segmentation.
> >>> This muxer supports the following options:
> >>>
> >>> @table @option
> >>> +@item hls_init_time @var{seconds}
> >>> +Set the target segment length in seconds. Default value is @var{0}.
> >>> +Segment will be cut duration is @code{hls_init_time} value for the
> >>> +first m3u8 list segments, After update m3u8 to the end of the
> >>> +first m3u8 list, @command{ffmpeg} will cut segments
> >>> +at duration equ @code{hls_time}.
> >>> +
> >>> @item hls_time @var{seconds}
> >>> Set the target segment length in seconds. Default value is 2.
> >>> Segment will be cut on the next key frame after this time has passed.
> >>> --
> >>> 2.7.4 (Apple Git-66)
> >>>
> >>> Hi Ibrahim Tachijian,
> >>
> >> Can you review this doc? My English is poor :D
> >>
> > Reviewed-by: Ibrahim Tachijian
> Signed-off-by: LiuQi
> ---
> doc/muxers.texi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 2548aeb..c39a6a0 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -357,6 +357,12 @@ segmentation.
> This muxer supports the following options:
>
> @table @option
> +@item hls_init_time @var{seconds}
> +Set the initial target segment length in seconds. Default value is @var{0}.
> +Segment will be cut on the next key frame after this time has passed on
> the first m3u8 list.
> +After the initial playlist is filled @command{ffmpeg} will cut segments
> +at duration equal to @code{hls_time}
> +
> @item hls_time @var{seconds}
> Set the target segment length in seconds. Default value is 2.
> Segment will be cut on the next key frame after this time has passed.
> --
> 2.7.4 (Apple Git-66)
> muxers.texi |6 ++
> 1 file changed, 6 insertions(+)
> 9c534308910fa4559ecd159dfc461e9b1085d3ab
> 0002-add-option-hls_init_time-document.patch
> From a67c3c43a2ee58156b5817d26632ec6c15756957 Mon Sep 17 00:00:00 2001
> From: Steven Liu
> Date: Sat, 27 Aug 2016 07:35:54 +0800
> Subject: [PATCH 2/2] add option hls_init_time document
>
> Reviewed-by: Ibrahim Tachijian
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cmdutils: fix implicit declaration of SetDllDirectory function
Attached patch fixes a build error on my system (Ubuntu 14.04, mingw-w64 3.1.0, gcc-mingw-w64 4.8.2) introduced by commit 3bf142c77337814458ed8e036796934032d9837f. As the original commit has been backported to older releases (2.8, 3.0 and 3.1 as far as I can see) it probably makes sense to backport this fix, too. Regards, Tobias >From 97c153fab37a44946e54fcea6b48259cb0c24143 Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Mon, 29 Aug 2016 15:25:58 +0200 Subject: [PATCH] cmdutils: fix implicit declaration of SetDllDirectory function Signed-off-by: Tobias Rapp --- cmdutils.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cmdutils.c b/cmdutils.c index 6960f8c..44f44cd 100644 --- a/cmdutils.c +++ b/cmdutils.c @@ -61,6 +61,9 @@ #include #include #endif +#ifdef _WIN32 +#include +#endif static int init_report(const char *env); -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option
On Mon, Aug 29, 2016 at 07:52:23PM +0800, Steven Liu wrote: > 2016-08-26 0:11 GMT+08:00 Michael Niedermayer : > > > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote: > > > Tested passed at : > > > 1. OSX > > > 2. Linux > > > 3. Windows > > > > > 4. Ubuntu+wine+MinGW > > > > confirmed it works > > but > > doesnt work on qemu-mips > > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L > > /usr/mips-linux-gnu/' \ > > --samples=... --enable-gpl --cross-prefix=/usr/mips-linux-gnu/bin/ \ > > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > > --enable-cross-compile --disable-pthreads --disable-mipsfpu --disable-iconv > > > > make distclean ; ./c-qemu && make -j12 fate-filter-hls-append > > first it fails with > > GEN tests/data/hls-list-append.m3u8 > > make: *** [tests/data/hls-list-append.m3u8] Error 255 > > > > reruning make -j12 fate-filter-hls-append > > results in: > > > > --- tests/ref/fate/filter-hls-append2016-08-25 17:43:18.565618034 > > +0200 > > +++ tests/data/fate/filter-hls-append 2016-08-25 17:47:18.681623092 > > +0200 > > @@ -3,1154 +3,770 @@ > > #codec_id 0: pcm_s16le > > #sample_rate 0: 44100 > > #channel_layout 0: 4 > > -0, 0, 0, 1152, 2304, 0x593ea430 > > -0, 1152, 1152, 1152, 2304, 0xde328304 > > -0, 2304, 2304, 1152, 2304, 0x12f673c9 > > -0, 3456, 3456, 1152, 2304, 0x4c7672a1 > > -0, 4608, 4608, 1152, 2304, 0xd38577f4 > > -0, 5760, 5760, 1152, 2304, 0xc9d677cc > > -0, 6912, 6912, 1152, 2304, 0xc97e882a > > -0, 8064, 8064, 1152, 2304, 0xaacf67ec > > -0, 9216, 9216, 1152, 2304, 0x3a9b7ea5 > > -0, 10368, 10368, 1152, 2304, 0x30258348 > > -0, 11520, 11520, 1152, 2304, 0x08da8783 > > -0, 12672, 12672, 1152, 2304, 0x4830619e > > -0, 13824, 13824, 1152, 2304, 0xcf476f69 > > -0, 14976, 14976, 1152, 2304, 0x377e7ce5 > > -0, 16128, 16128, 1152, 2304, 0x00a27fad > > -0, 17280, 17280, 1152, 2304, 0xe4a46de3 > > -0, 18432, 18432, 1152, 2304, 0x938c8751 > > -0, 19584, 19584, 1152, 2304, 0x239982b5 > > -0, 20736, 20736, 1152, 2304, 0x9a0d7655 > > -0, 21888, 21888, 1152, 2304, 0x4adf7fbf > > -0, 23040, 23040, 1152, 2304, 0xdb8b7b16 > > -0, 24192, 24192, 1152, 2304, 0x25908560 > > -0, 25344, 25344, 1152, 2304, 0xb5dd7be7 > > -0, 26496, 26496, 1152, 2304, 0x4368796d > > -0, 27648, 27648, 1152, 2304, 0xba3a7fd0 > > ... > > make: *** [fate-filter-hls-append] Error 1 > > > > [...] > > > > > > Is this base on Ubuntu? What's the Ubuntu version? the build environment was from emdebian, i am still using it as it still works flawless, mips qemu was built from source long ago, i would expect the qemu from ubuntu to work fine. Does it work for you with whatever version is easily available to you? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: vf_minterpolate: fix green line issue
On Sun, Aug 28, 2016 at 10:48 PM, Michael Niedermayer < mich...@niedermayer.cc> wrote: > On Sun, Aug 28, 2016 at 06:32:21PM +, Davinder Singh wrote: > > hi, > > > > the mv can be negative. right shifting rounds off it to -ve infinity. > > changed to division, doesn't seem to affect speed at all. > > this fixes the green line that appear on top or left in bidir mode. also > > improved the quality by +0.08dB > > > > > > thanks, > > DSM_ > > > vf_minterpolate.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > 7f04535f4aa373aa3a28cae65fff2dd2a995f10b 0002-avfilter-vf_minterpolate- > fix-green-line-issue.patch > > From abe0f4cbe3bf5fc85f509bdc1d0369791d9a9677 Mon Sep 17 00:00:00 2001 > > From: Davinder Singh > > Date: Sun, 28 Aug 2016 23:45:00 +0530 > > Subject: [PATCH 2/2] avfilter: vf_minterpolate: fix green line issue > > LGTM > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The greatest way to live with honor in this world is to be what we pretend > to be. -- Socrates > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: vf_minterpolate: rename chroma log vars
On Sun, Aug 28, 2016 at 10:51 PM, Paul B Mahol wrote:
>
>
> On Sun, Aug 28, 2016 at 10:47 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Sun, Aug 28, 2016 at 06:24:14PM +, Davinder Singh wrote:
>> > hi,
>> >
>> > this rename confusing chroma variables to one used in
>> AVPixFmtDescriptor.
>> > more consistent.
>> > also removed some useless vars from context.
>> >
>> > thanks
>> > DSM_
>>
>> [...]
>>
>> > @@ -900,6 +894,8 @@ static void bidirectional_obmc(MIContext *mi_ctx,
>> int alpha)
>> > }
>> > }
>> >
>> > +
>> > +
>> > static void set_frame_data(MIContext *mi_ctx, int alpha, AVFrame
>> *avf_out)
>> > {
>> > int x, y, plane;
>>
>> stray change
>>
>>
>> > @@ -936,8 +932,8 @@ static void set_frame_data(MIContext *mi_ctx, int
>> alpha, AVFrame *avf_out)
>> > for (i = 0; i < pixel->nb; i++) {
>> > Frame *frame = &mi_ctx->frames[pixel->refs[i]];
>> > if (chroma) {
>> > -x_mv = (x >> mi_ctx->chroma_h_shift) +
>> (pixel->mvs[i][0] >> mi_ctx->chroma_h_shift);
>> > -y_mv = (y >> mi_ctx->chroma_v_shift) +
>> (pixel->mvs[i][1] >> mi_ctx->chroma_v_shift);
>> > +x_mv = (x >> mi_ctx->log2_chroma_w) +
>> (pixel->mvs[i][0] >> mi_ctx->log2_chroma_w);
>> > +y_mv = (y >> mi_ctx->log2_chroma_h) +
>> (pixel->mvs[i][1] >> mi_ctx->log2_chroma_h);
>> > } else {
>> > x_mv = x + pixel->mvs[i][0];
>> > y_mv = y + pixel->mvs[i][1];
>> > @@ -949,7 +945,7 @@ static void set_frame_data(MIContext *mi_ctx, int
>> alpha, AVFrame *avf_out)
>> > val = ROUNDED_DIV(val, weight_sum);
>> >
>> > if (chroma)
>> > -avf_out->data[plane][(x >> mi_ctx->chroma_h_shift)
>> + (y >> mi_ctx->chroma_v_shift) * avf_out->linesize[plane]] = val;
>> > +avf_out->data[plane][(x >> mi_ctx->log2_chroma_w)
>> + (y >> mi_ctx->log2_chroma_h) * avf_out->linesize[plane]] = val;
>> > else
>> > avf_out->data[plane][x + y *
>> avf_out->linesize[plane]] = val;
>> > }
>> > @@ -1092,8 +1088,8 @@ static void interpolate(AVFilterLink *inlink,
>> AVFrame *avf_out)
>> > int height = avf_out->height;
>> >
>> > if (plane == 1 || plane == 2) {
>> > -width = mi_ctx->chroma_width;
>> > -height = mi_ctx->chroma_height;
>> > +width = width >> mi_ctx->log2_chroma_w;
>> > +height = height >> mi_ctx->log2_chroma_h;
>>
>> this is rounded differntly if wdith / height is odd,
>> is that intended ?
>>
>
> It should use AV_CEIL_RSHIFT
>
And using avcodec* stuff is in lavfi is not needed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option
2016-08-29 22:18 GMT+08:00 Michael Niedermayer : > On Mon, Aug 29, 2016 at 07:52:23PM +0800, Steven Liu wrote: > > 2016-08-26 0:11 GMT+08:00 Michael Niedermayer : > > > > > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote: > > > > Tested passed at : > > > > 1. OSX > > > > 2. Linux > > > > 3. Windows > > > > > > > 4. Ubuntu+wine+MinGW > > > > > > confirmed it works > > > but > > > doesnt work on qemu-mips > > > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L > > > /usr/mips-linux-gnu/' \ > > > --samples=... --enable-gpl --cross-prefix=/usr/mips-linux-gnu/bin/ \ > > > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > > > --enable-cross-compile --disable-pthreads --disable-mipsfpu > --disable-iconv > > > > > > make distclean ; ./c-qemu && make -j12 fate-filter-hls-append > > > first it fails with > > > GEN tests/data/hls-list-append.m3u8 > > > make: *** [tests/data/hls-list-append.m3u8] Error 255 > > > > > > reruning make -j12 fate-filter-hls-append > > > results in: > > > > > > --- tests/ref/fate/filter-hls-append2016-08-25 17:43:18.565618034 > > > +0200 > > > +++ tests/data/fate/filter-hls-append 2016-08-25 17:47:18.681623092 > > > +0200 > > > @@ -3,1154 +3,770 @@ > > > #codec_id 0: pcm_s16le > > > #sample_rate 0: 44100 > > > #channel_layout 0: 4 > > > -0, 0, 0, 1152, 2304, 0x593ea430 > > > -0, 1152, 1152, 1152, 2304, 0xde328304 > > > -0, 2304, 2304, 1152, 2304, 0x12f673c9 > > > -0, 3456, 3456, 1152, 2304, 0x4c7672a1 > > > -0, 4608, 4608, 1152, 2304, 0xd38577f4 > > > -0, 5760, 5760, 1152, 2304, 0xc9d677cc > > > -0, 6912, 6912, 1152, 2304, 0xc97e882a > > > -0, 8064, 8064, 1152, 2304, 0xaacf67ec > > > -0, 9216, 9216, 1152, 2304, 0x3a9b7ea5 > > > -0, 10368, 10368, 1152, 2304, 0x30258348 > > > -0, 11520, 11520, 1152, 2304, 0x08da8783 > > > -0, 12672, 12672, 1152, 2304, 0x4830619e > > > -0, 13824, 13824, 1152, 2304, 0xcf476f69 > > > -0, 14976, 14976, 1152, 2304, 0x377e7ce5 > > > -0, 16128, 16128, 1152, 2304, 0x00a27fad > > > -0, 17280, 17280, 1152, 2304, 0xe4a46de3 > > > -0, 18432, 18432, 1152, 2304, 0x938c8751 > > > -0, 19584, 19584, 1152, 2304, 0x239982b5 > > > -0, 20736, 20736, 1152, 2304, 0x9a0d7655 > > > -0, 21888, 21888, 1152, 2304, 0x4adf7fbf > > > -0, 23040, 23040, 1152, 2304, 0xdb8b7b16 > > > -0, 24192, 24192, 1152, 2304, 0x25908560 > > > -0, 25344, 25344, 1152, 2304, 0xb5dd7be7 > > > -0, 26496, 26496, 1152, 2304, 0x4368796d > > > -0, 27648, 27648, 1152, 2304, 0xba3a7fd0 > > > ... > > > make: *** [fate-filter-hls-append] Error 1 > > > > > > [...] > > > > > > > > > Is this base on Ubuntu? What's the Ubuntu version? > > the build environment was from emdebian, i am still using it as it > still works flawless, mips qemu was built from source long ago, i would > expect the qemu from ubuntu to work fine. > > Does it work for you with whatever version is easily available to you? > > :D Because i'm not a debian and ubuntu user, I usually using CentOS and OSX on x86, So i'm learning how to use ubuntu and mips arm for FATE :D ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] vf_colorspace: Allow overriding input color properties
The filter needs input frames with color properties filled out by
the decoder. Since this is not always possible, add input options to
the filter so that user may override color space, color primaries,
transfer characteristics, and color range, as well as a generic option
to set all properties at once.
Signed-off-by: Vittorio Giovara
---
* added iall option
* updated filter documentation
Please CC.
Vittorio
doc/filters.texi| 20
libavfilter/vf_colorspace.c | 39 ++-
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index b50d7a6..8045840 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5235,6 +5235,7 @@ Convert colorspace, transfer characteristics or color
primaries.
The filter accepts the following options:
@table @option
+@anchor{all}
@item all
Specify all color properties at once.
@@ -5266,6 +5267,10 @@ BT.2020
@end table
+@item iall
+Override all input properties at once. Same accepted values as @ref{all}.
+
+@anchor{space}
@item space
Specify output colorspace.
@@ -5291,6 +5296,10 @@ BT.2020 with non-constant luminance
@end table
+@item ispace
+Override input colorspace. Same accepted values as @ref{space}.
+
+@anchor{trc}
@item trc
Specify output transfer characteristics.
@@ -5319,6 +5328,10 @@ BT.2020 for 12-bits content
@end table
+@item itrc
+Override input transfer characteristics. Same accepted values as @ref{trc}.
+
+@anchor{primaries}
@item primaries
Specify output color primaries.
@@ -5344,6 +5357,10 @@ BT.2020
@end table
+@item iprimaries
+Override input color primaries. Same accepted values as @ref{primaries}.
+
+@anchor{range}
@item range
Specify output color range.
@@ -5357,6 +5374,9 @@ JPEG (full) range
@end table
+@item irange
+Override input color range. Same accepted values as @ref{range}.
+
@item format
Specify output color format.
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index e4022f8..c1ef5b3 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -128,11 +128,11 @@ typedef struct ColorSpaceContext {
ColorSpaceDSPContext dsp;
-enum Colorspace user_all;
-enum AVColorSpace in_csp, out_csp, user_csp;
-enum AVColorRange in_rng, out_rng, user_rng;
-enum AVColorTransferCharacteristic in_trc, out_trc, user_trc;
-enum AVColorPrimaries in_prm, out_prm, user_prm;
+enum Colorspace user_all, user_iall;
+enum AVColorSpace in_csp, out_csp, user_csp, user_icsp;
+enum AVColorRange in_rng, out_rng, user_rng, user_irng;
+enum AVColorTransferCharacteristic in_trc, out_trc, user_trc, user_itrc;
+enum AVColorPrimaries in_prm, out_prm, user_prm, user_iprm;
enum AVPixelFormat in_format, user_format;
int fast_mode;
enum DitherMode dither;
@@ -581,6 +581,10 @@ static int create_filtergraph(AVFilterContext *ctx,
if (!s->out_primaries || !s->in_primaries) {
s->in_prm = in->color_primaries;
+if (s->user_iall != CS_UNSPECIFIED)
+s->in_prm = default_prm[FFMIN(s->user_iall, CS_NB)];
+if (s->user_iprm != AVCOL_PRI_UNSPECIFIED)
+s->in_prm = s->user_iprm;
s->in_primaries = get_color_primaries(s->in_prm);
if (!s->in_primaries) {
av_log(ctx, AV_LOG_ERROR,
@@ -638,6 +642,10 @@ static int create_filtergraph(AVFilterContext *ctx,
if (!s->in_txchr) {
av_freep(&s->lin_lut);
s->in_trc = in->color_trc;
+if (s->user_iall != CS_UNSPECIFIED)
+s->in_trc = default_trc[FFMIN(s->user_iall, CS_NB)];
+if (s->user_itrc != AVCOL_TRC_UNSPECIFIED)
+s->in_trc = s->user_itrc;
s->in_txchr = get_transfer_characteristics(s->in_trc);
if (!s->in_txchr) {
av_log(ctx, AV_LOG_ERROR,
@@ -680,7 +688,13 @@ static int create_filtergraph(AVFilterContext *ctx,
if (!s->in_lumacoef) {
s->in_csp = in->colorspace;
+if (s->user_iall != CS_UNSPECIFIED)
+s->in_csp = default_csp[FFMIN(s->user_iall, CS_NB)];
+if (s->user_icsp != AVCOL_SPC_UNSPECIFIED)
+s->in_csp = s->user_icsp;
s->in_rng = in->color_range;
+if (s->user_irng != AVCOL_RANGE_UNSPECIFIED)
+s->in_rng = s->user_irng;
s->in_lumacoef = get_luma_coefficients(s->in_csp);
if (!s->in_lumacoef) {
av_log(ctx, AV_LOG_ERROR,
@@ -1002,6 +1016,9 @@ static const AVOption colorspace_options[] = {
{ "all","Set all color properties together",
OFFSET(user_all), AV_OPT_TYPE_INT, { .i64 = CS_UNSPECIFIED },
CS_UNSPECIFIED, CS_NB - 1, FLAGS, "all" },
+{ "iall", "Set all input color properties together",
+ OFFSET(user_iall), AV_OPT_TYPE_INT, { .i64 = CS_UNSPECIFIED },
+ CS_UNSPECIFIED, CS_NB - 1, FLAGS, "all" },
ENUM("bt470m", CS_BT470M, "all"),
ENUM("bt470b
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On 8/29/2016 3:49 AM, Matt Oliver wrote: > From 7c70764508643c45b037f1ed9d77a95c24b05f6e Mon Sep 17 00:00:00 2001 > From: Matt Oliver > Date: Mon, 29 Aug 2016 16:46:10 +1000 > Subject: [PATCH 2/2] Modify existing dll loading to use new safe dlopen. > > --- > libavcodec/nvenc.c | 9 ++--- > libavformat/avisynth.c | 13 - > libavutil/hwcontext_dxva2.c | 16 > 3 files changed, 14 insertions(+), 24 deletions(-) > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > index 283f29f..f94a930 100644 > --- a/libavcodec/nvenc.c > +++ b/libavcodec/nvenc.c > @@ -33,16 +33,11 @@ > # define NVENC_LIBNAME "libnvidia-encode.so.1" > #endif > > -#if defined(_WIN32) > -#include > - > -#define dlopen(filename, flags) LoadLibrary(TEXT(filename)) > -#define dlsym(handle, symbol) GetProcAddress(handle, symbol) > -#define dlclose(handle) FreeLibrary(handle) > -#else > +#if !defined(_WIN32) > #include > #endif > > +#include "libavformat/os_support.h" FYI, last time i tried to include this file from libavcodec i was told not to since it's libavformat specific. The proper place for these wrappers is probably the compat folder, in a new file similar to w32threads.h > #include "libavutil/hwcontext.h" > #include "libavutil/imgutils.h" > #include "libavutil/avassert.h" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] vf_colorspace: Allow overriding input color properties
Hi, On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > The filter needs input frames with color properties filled out by > the decoder. Since this is not always possible, add input options to > the filter so that user may override color space, color primaries, > transfer characteristics, and color range, as well as a generic option > to set all properties at once. > > Signed-off-by: Vittorio Giovara > --- > * added iall option > * updated filter documentation > > Please CC. > Vittorio > > doc/filters.texi| 20 > libavfilter/vf_colorspace.c | 39 ++- > 2 files changed, 54 insertions(+), 5 deletions(-) lgtm. (I wonder if the error message - if the input AVFrame has no trc/rng/csp/prm - should be changed to reflect that you can override them using the added properties? This isn't a big deal but maybe someone feels that's important.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
On 28 Aug, Matt Oliver wrote : > The dlopen function is modified to prevent loading dll's from the current > directory for improved program security for library users. This extends > similar functionality from the recently applied SetDllDirectory patch > except that it adds additional security for library users as well (as > opposed to just program users). Why allowing it to open the local folder? Said differently, what are you allowing to open, and why? With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_dctdnoiz: add YUV444P support
Hi, patch attached. 0001-avfilter-vf_dctdnoiz-add-yuv444p-format-support.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for libavformat/crypto to add seeking on read
On Mon, Aug 29, 2016 at 11:08:36AM +0100, Simon H wrote:
> crypto allows reading of data which has been aes-128-cbc encrypted given a
> key and an iv.
> But it did not handle filetypes which require seeking... e.g. it failed on
> an encrypted .mp4 file.
>
> example:
> take 25.mp4 created with:
> ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0
> -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22
> -timecode 10:00:00:00 -r 25 -y out\25.mp4
>
> encrypt with:
> openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv
> 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
> then to transcode in ffmpeg:
> ffmpeg -key 12345678901234567890123456789012 -iv
> 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y
> 25dec.mp4
>
> prior to this modification, the transcode would fail.
>
> Note also: crypto previously marked both reads and writes as streamed,
> which caused the whole file
> to be read before the transcode started. Now, for read only, if the
> underlying layer is not marked as streamed,
> then crypto is not. This should enable efficient reading of encrypted
> containers which require seeking.
>
> this is my first patch for ffmpeg; guidance appreciated.
> ---
> libavformat/crypto.c | 115
> +--
> 1 file changed, 112 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/crypto.c b/libavformat/crypto.c
> index 2999f50..23bc0a6 100644
> --- a/libavformat/crypto.c
> +++ b/libavformat/crypto.c
> @@ -26,7 +26,8 @@
> #include "internal.h"
> #include "url.h"
>
> -#define MAX_BUFFER_BLOCKS 150
> +// encourage reads of 4096 bytes - 1 block is always retained.
> +#define MAX_BUFFER_BLOCKS 257
> #define BLOCKSIZE 16
>
> typedef struct CryptoContext {
> @@ -36,6 +37,8 @@ typedef struct CryptoContext {
> outbuffer[BLOCKSIZE*MAX_BUFFER_BLOCKS];
> uint8_t *outptr;
> int indata, indata_used, outdata;
> +int64_t position; // position in file - used in seek
> +int flags;
> int eof;
> uint8_t *key;
> int keylen;
> @@ -109,6 +112,7 @@ static int crypto_open2(URLContext *h, const char *uri,
> int flags, AVDictionary
> const char *nested_url;
> int ret = 0;
> CryptoContext *c = h->priv_data;
> +c->flags = flags;
>
> if (!av_strstart(uri, "crypto+", &nested_url) &&
> !av_strstart(uri, "crypto:", &nested_url)) {
> @@ -117,6 +121,8 @@ static int crypto_open2(URLContext *h, const char *uri,
> int flags, AVDictionary
patch corrupted by newlines
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder
Hi,
On Sun, Aug 28, 2016 at 4:26 PM, Michael Niedermayer
wrote:
> On Sun, Aug 28, 2016 at 01:34:46PM +0530, Umair Khan wrote:
>> Hi,
>>
>> Patches attached. :)
>>
>> - Umair
>
>> Changelog |1 +
>> 1 file changed, 1 insertion(+)
>> d3f30e62d803d967bd5c27dc5dfad278ce5c02e9
>> 0001-Changelog-Add-entry-for-ALS-encoder.patch
>> From 020370545a82c8c1304ec9c177a75e27e59b84e8 Mon Sep 17 00:00:00 2001
>> From: Umair Khan
>> Date: Sat, 27 Aug 2016 22:22:02 +0530
>> Subject: [PATCH 1/2] Changelog: Add entry for ALS encoder
>>
>> Signed-off-by: Umair Khan
>> ---
>> Changelog | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Changelog b/Changelog
>> index b903e31..90c15ad 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -15,6 +15,7 @@ version :
>> - True Audio (TTA) muxer
>> - crystalizer audio filter
>> - acrusher audio filter
>> +- ALS encoder
>>
>>
>> version 3.1:
>> --
>> 2.7.4 (Apple Git-66)
>>
>
> [...]
>> +static int calc_short_term_prediction(ALSEncContext *ctx, ALSBlock *block,
>> + int order)
>> +{
>> +ALSSpecificConfig *sconf = &ctx->sconf;
>> +int i, j;
>> +
>> +int32_t *res_ptr = block->res_ptr;
>> +int32_t *smp_ptr = block->cur_ptr;
>> +
>> +assert(order > 0);
>
> should be av_assertX (X=0/1/2)
>
>
> [...]
>> +int ff_window_init(WindowContext *wctx, enum WindowType type, int length,
>> + double param)
>> +{
>> +if (!length || length < -1)
>> +return AVERROR(EINVAL);
>> +
>> +wctx->type = type;
>> +wctx->length = length;
>> +wctx->param = param;
>> +
>> +switch (type) {
>> +case WINDOW_TYPE_RECTANGLE:
>> +rectangle_init(wctx);
>> +break;
>> +case WINDOW_TYPE_WELCH:
>> +WINDOW_INIT(welch)
>> +break;
>> +case WINDOW_TYPE_SINERECT:
>> +WINDOW_INIT(sinerect)
>> +break;
>> +case WINDOW_TYPE_HANNRECT:
>> +WINDOW_INIT(hannrect)
>> +break;
>> +default:
>> +return AVERROR(EINVAL);
>> +}
>> +
>
>> +if (HAVE_MMX)
>> +ff_window_init_mmx(wctx);
>
> breaks build on non x86 as the function declaration / prototype is
> not there in that case
What should I do with this then? I'm not too aware of how the whole
code works because I didn't originally write it.
So, I'll need some help here. :)
> [...]
>> +static int als_write_trailer(struct AVFormatContext *s)
>> +{
>> +AVIOContext *pb = s->pb;
>> +AlsEncContext *ctx = s->priv_data;
>
>> +int header_size;
>> +
>> +header_size = ctx->header_size;
>> +
>> +if (pb->seekable) {
>> +/* rewrite the header */
>> +int64_t file_size = avio_tell(pb);
>> +int header_size = ctx->header_size;
>
> there are 2 "int header_size" here
>
>
> [,..]
>
> something in this patch seems to break fate
> --- ./tests/ref/fate/mpeg4-als-conformance-00 2016-08-28 12:44:08.726700510
> +0200
> +++ tests/data/fate/mpeg4-als-conformance-002016-08-28 12:46:01.142702882
> +0200
> @@ -1 +1 @@
> -CRC=0x7e67db0b
> +CRC=0x2f028a7d
> Test mpeg4-als-conformance-00 failed. Look at
> tests/data/fate/mpeg4-als-conformance-00.err for details.
> make: *** [fate-mpeg4-als-conformance-00] Error 1
> TESTmpeg4-als-conformance-05
> --- ./tests/ref/fate/mpeg4-als-conformance-02 2016-08-28 12:44:08.726700510
> +0200
> +++ tests/data/fate/mpeg4-als-conformance-022016-08-28 12:46:01.166702883
> +0200
> @@ -1 +1 @@
> -CRC=0x7e67db0b
> +CRC=0xe1118061
> Test mpeg4-als-conformance-02 failed. Look at
> tests/data/fate/mpeg4-als-conformance-02.err for details.
> make: *** [fate-mpeg4-als-conformance-02] Error 1
> TESTamrnb-4k75
> --- ./tests/ref/fate/mpeg4-als-conformance-03 2016-08-28 12:44:08.726700510
> +0200
> +++ tests/data/fate/mpeg4-als-conformance-032016-08-28 12:46:01.214702884
> +0200
> @@ -1 +1 @@
> -CRC=0x7e67db0b
> +CRC=0xf6bddab8
> Test mpeg4-als-conformance-03 failed. Look at
> tests/data/fate/mpeg4-als-conformance-03.err for details.
> make: *** [fate-mpeg4-als-conformance-03] Error 1
> TESTamrnb-5k15
> TESTamrnb-5k9
> --- ./tests/ref/fate/mpeg4-als-conformance-04 2016-08-28 12:44:08.726700510
> +0200
> +++ tests/data/fate/mpeg4-als-conformance-042016-08-28 12:46:01.226702884
> +0200
> @@ -1 +1 @@
> -CRC=0x7e67db0b
> +CRC=0x0f585e71
> Test mpeg4-als-conformance-04 failed. Look at
> tests/data/fate/mpeg4-als-conformance-04.err for details.
> make: *** [fate-mpeg4-als-conformance-04] Error 1
> TESTamrnb-6k7
> TESTamrnb-7k4
> --- ./tests/ref/fate/mpeg4-als-conformance-01 2016-08-28 12:44:08.726700510
> +0200
> +++ tests/data/fate/mpeg4-als-conformance-012016-08-28 12:46:01.278702885
> +0200
> @@ -1 +1 @@
> -CRC=0x7e67db0b
> +CRC=0x84528af2
> TESTamrnb-10k2
> Test mpeg4-als-conformance-01 failed. Look at
> tests/data/fate/mpeg4-als-conformance-01.err for details.
> make: *** [fate-mpeg4-als-conformance-01] Error 1
> TESTamrnb-12k2
> --- ./tests/ref/fate/mpeg
[FFmpeg-devel] MAINTAINERS: Add myself for alsdec
Hi, Patch attached. - Umair 0001-MAINTAINERS-Add-myself-for-alsdec.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder
On 8/29/2016 2:17 PM, Umair Khan wrote: >>> +if (HAVE_MMX) >>> >> +ff_window_init_mmx(wctx); >> > >> > breaks build on non x86 as the function declaration / prototype is >> > not there in that case > What should I do with this then? I'm not too aware of how the whole > code works because I didn't originally write it. > So, I'll need some help here. :) Use ARCH_X86 instead of HAVE_MMX. Don't wrap the ff_window_init_mmx declaration in the header with any pre-processor check, and also rename it to ff_window_init_x86 since there's no mmx code whatsoever. This all of course after it's been ported to yasm. As i said earlier you can keep that for a latter patch and focus on the encoder without all the assembly optimization part. For that matter, shouldn't this code be added to lpc.c/h instead of a new file? Chances are you may be duplicating parts of it as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] avcodec/als: Add ALS encoder
On Mon, Aug 29, 2016 at 10:47:59PM +0530, Umair Khan wrote:
> Hi,
>
> On Sun, Aug 28, 2016 at 4:26 PM, Michael Niedermayer
> wrote:
> > On Sun, Aug 28, 2016 at 01:34:46PM +0530, Umair Khan wrote:
> >> Hi,
> >>
> >> Patches attached. :)
> >>
> >> - Umair
> >
> >> Changelog |1 +
> >> 1 file changed, 1 insertion(+)
> >> d3f30e62d803d967bd5c27dc5dfad278ce5c02e9
> >> 0001-Changelog-Add-entry-for-ALS-encoder.patch
> >> From 020370545a82c8c1304ec9c177a75e27e59b84e8 Mon Sep 17 00:00:00 2001
> >> From: Umair Khan
> >> Date: Sat, 27 Aug 2016 22:22:02 +0530
> >> Subject: [PATCH 1/2] Changelog: Add entry for ALS encoder
> >>
> >> Signed-off-by: Umair Khan
> >> ---
> >> Changelog | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Changelog b/Changelog
> >> index b903e31..90c15ad 100644
> >> --- a/Changelog
> >> +++ b/Changelog
> >> @@ -15,6 +15,7 @@ version :
> >> - True Audio (TTA) muxer
> >> - crystalizer audio filter
> >> - acrusher audio filter
> >> +- ALS encoder
> >>
> >>
> >> version 3.1:
> >> --
> >> 2.7.4 (Apple Git-66)
> >>
> >
> > [...]
> >> +static int calc_short_term_prediction(ALSEncContext *ctx, ALSBlock *block,
> >> + int order)
> >> +{
> >> +ALSSpecificConfig *sconf = &ctx->sconf;
> >> +int i, j;
> >> +
> >> +int32_t *res_ptr = block->res_ptr;
> >> +int32_t *smp_ptr = block->cur_ptr;
> >> +
> >> +assert(order > 0);
> >
> > should be av_assertX (X=0/1/2)
> >
> >
> > [...]
> >> +int ff_window_init(WindowContext *wctx, enum WindowType type, int length,
> >> + double param)
> >> +{
> >> +if (!length || length < -1)
> >> +return AVERROR(EINVAL);
> >> +
> >> +wctx->type = type;
> >> +wctx->length = length;
> >> +wctx->param = param;
> >> +
> >> +switch (type) {
> >> +case WINDOW_TYPE_RECTANGLE:
> >> +rectangle_init(wctx);
> >> +break;
> >> +case WINDOW_TYPE_WELCH:
> >> +WINDOW_INIT(welch)
> >> +break;
> >> +case WINDOW_TYPE_SINERECT:
> >> +WINDOW_INIT(sinerect)
> >> +break;
> >> +case WINDOW_TYPE_HANNRECT:
> >> +WINDOW_INIT(hannrect)
> >> +break;
> >> +default:
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >
> >> +if (HAVE_MMX)
> >> +ff_window_init_mmx(wctx);
> >
> > breaks build on non x86 as the function declaration / prototype is
> > not there in that case
>
> What should I do with this then? I'm not too aware of how the whole
> code works because I didn't originally write it.
> So, I'll need some help here. :)
IIRC the declaration / prototype is under #if
but the call is not under #if
thus if the condition on the #if is untrue this fails to build
(this is not the same as the functions implementation being missing
for if(0) code, that one works with all supported platforms)
its probably best to split the whole *_mmx code out into a seperate
patch and also either the call must be under #if or the declaration
must be available independant of an #if
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option
On Mon, Aug 29, 2016 at 11:17:25PM +0800, Steven Liu wrote: > 2016-08-29 22:18 GMT+08:00 Michael Niedermayer : > > > On Mon, Aug 29, 2016 at 07:52:23PM +0800, Steven Liu wrote: > > > 2016-08-26 0:11 GMT+08:00 Michael Niedermayer : > > > > > > > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote: > > > > > Tested passed at : > > > > > 1. OSX > > > > > 2. Linux > > > > > 3. Windows > > > > > > > > > 4. Ubuntu+wine+MinGW > > > > > > > > confirmed it works > > > > but > > > > doesnt work on qemu-mips > > > > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L > > > > /usr/mips-linux-gnu/' \ > > > > --samples=... --enable-gpl --cross-prefix=/usr/mips-linux-gnu/bin/ \ > > > > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > > > > --enable-cross-compile --disable-pthreads --disable-mipsfpu > > --disable-iconv > > > > > > > > make distclean ; ./c-qemu && make -j12 fate-filter-hls-append > > > > first it fails with > > > > GEN tests/data/hls-list-append.m3u8 > > > > make: *** [tests/data/hls-list-append.m3u8] Error 255 > > > > > > > > reruning make -j12 fate-filter-hls-append > > > > results in: > > > > > > > > --- tests/ref/fate/filter-hls-append2016-08-25 17:43:18.565618034 > > > > +0200 > > > > +++ tests/data/fate/filter-hls-append 2016-08-25 17:47:18.681623092 > > > > +0200 > > > > @@ -3,1154 +3,770 @@ > > > > #codec_id 0: pcm_s16le > > > > #sample_rate 0: 44100 > > > > #channel_layout 0: 4 > > > > -0, 0, 0, 1152, 2304, 0x593ea430 > > > > -0, 1152, 1152, 1152, 2304, 0xde328304 > > > > -0, 2304, 2304, 1152, 2304, 0x12f673c9 > > > > -0, 3456, 3456, 1152, 2304, 0x4c7672a1 > > > > -0, 4608, 4608, 1152, 2304, 0xd38577f4 > > > > -0, 5760, 5760, 1152, 2304, 0xc9d677cc > > > > -0, 6912, 6912, 1152, 2304, 0xc97e882a > > > > -0, 8064, 8064, 1152, 2304, 0xaacf67ec > > > > -0, 9216, 9216, 1152, 2304, 0x3a9b7ea5 > > > > -0, 10368, 10368, 1152, 2304, 0x30258348 > > > > -0, 11520, 11520, 1152, 2304, 0x08da8783 > > > > -0, 12672, 12672, 1152, 2304, 0x4830619e > > > > -0, 13824, 13824, 1152, 2304, 0xcf476f69 > > > > -0, 14976, 14976, 1152, 2304, 0x377e7ce5 > > > > -0, 16128, 16128, 1152, 2304, 0x00a27fad > > > > -0, 17280, 17280, 1152, 2304, 0xe4a46de3 > > > > -0, 18432, 18432, 1152, 2304, 0x938c8751 > > > > -0, 19584, 19584, 1152, 2304, 0x239982b5 > > > > -0, 20736, 20736, 1152, 2304, 0x9a0d7655 > > > > -0, 21888, 21888, 1152, 2304, 0x4adf7fbf > > > > -0, 23040, 23040, 1152, 2304, 0xdb8b7b16 > > > > -0, 24192, 24192, 1152, 2304, 0x25908560 > > > > -0, 25344, 25344, 1152, 2304, 0xb5dd7be7 > > > > -0, 26496, 26496, 1152, 2304, 0x4368796d > > > > -0, 27648, 27648, 1152, 2304, 0xba3a7fd0 > > > > ... > > > > make: *** [fate-filter-hls-append] Error 1 > > > > > > > > [...] > > > > > > > > > > > > Is this base on Ubuntu? What's the Ubuntu version? > > > > the build environment was from emdebian, i am still using it as it > > still works flawless, mips qemu was built from source long ago, i would > > expect the qemu from ubuntu to work fine. > > > > Does it work for you with whatever version is easily available to you? > > > > :D Because i'm not a debian and ubuntu user, > I usually using CentOS and OSX on x86, > So i'm learning how to use ubuntu and mips arm for FATE :D if you have a cross build env for mips in centos and qemu that should give similar results i would be surprised if the exact linux distro woul make a difference -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/APIChanges: mention nb_threads addition to AVFilterContext
Signed-off-by: James Almer --- doc/APIchanges | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/APIchanges b/doc/APIchanges index 2572b1c..7ac809c 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2015-08-28 API changes, most recent first: +2016-08-29 - 4493390 - lavfi 6.58.100 - avfilter.h + Add AVFilterContext.nb_threads. + 2016-08-15 - c3c4c72 - lavc 57.53.100 - avcodec.h Add trailing_padding to AVCodecContext to match the corresponding field in AVCodecParameters. -- 2.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On 8/27/2016 9:58 AM, Timo Rothenpieler wrote:
> @@ -5996,6 +5992,22 @@ enabled vdpau && enabled xlib &&
> check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11
> -lvdpau &&
> enable vdpau_x11
>
> +case $target_os in
> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
> +disabled nvenc || enable nvenc
> +;;
> +*)
> +disable nvenc
> +;;
> +esac
> +
> +if enabled nvenc; then
> +{
> +echo '#include "compat/nvenc/nvEncodeAPI.h"'
> +echo 'int main(void) { return 0; }'
> +} | check_cc -I$source_path || disable nvenc
In what situation could this test fail? nvenc is only enabled if $target_os
is one of the supported ones, and the test does nothing but compile the
header.
If it only supports x86 then you can just check "enabled x86" instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_dctdnoiz: add YUV444P support
On Mon, Aug 29, 2016 at 07:00:54PM +0200, Paul B Mahol wrote: > Hi, > > patch attached. The color decorrelation is an important part of the denoising algorithm described in http://www.ipol.im/pub/art/2011/ys-dct/ (see 2.3) Can we really consider the YUV planes as properly decorrelated ones? It seems to me that allowing YUV444 means that sometimes the denoising will be different (randomly if picked). -- Clément B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/APIChanges: mention nb_threads addition to AVFilterContext
On Mon, Aug 29, 2016 at 8:17 PM, James Almer wrote: > Signed-off-by: James Almer > --- > doc/APIchanges | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 2572b1c..7ac809c 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,6 +15,9 @@ libavutil: 2015-08-28 > > API changes, most recent first: > > +2016-08-29 - 4493390 - lavfi 6.58.100 - avfilter.h > + Add AVFilterContext.nb_threads. > + > 2016-08-15 - c3c4c72 - lavc 57.53.100 - avcodec.h >Add trailing_padding to AVCodecContext to match the corresponding >field in AVCodecParameters. > -- > 2.9.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_dctdnoiz: add YUV444P support
On Mon, Aug 29, 2016 at 8:52 PM, Clément Bœsch wrote: > On Mon, Aug 29, 2016 at 07:00:54PM +0200, Paul B Mahol wrote: > > Hi, > > > > patch attached. > > The color decorrelation is an important part of the denoising algorithm > described in http://www.ipol.im/pub/art/2011/ys-dct/ (see 2.3) > > Can we really consider the YUV planes as properly decorrelated ones? It > seems to me that allowing YUV444 means that sometimes the denoising will > be different (randomly if picked). > > -- > Clément B. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > They also say that gray should not be (de)correlated at all. Y is basically gray. U/V is already correlated with Y. Those number to me look random, they should be set via filter options. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 3/4] median compare function for ffv1 me
Info added to codecs.texi 2016-08-22 15:43 GMT+01:00 Michael Niedermayer : > On Thu, Aug 18, 2016 at 02:53:29PM +0300, Станислав Долганов wrote: > > Trailing whitespaces were removed. > > > > 2016-08-17 14:07 GMT+03:00 Станислав Долганов < > stanislav.dolga...@gmail.com> > > : > > > > > Hello, > > > > > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > > > frame support. The current FFV1 uses the same OBMC code as the Snow > > > codec. Also new median_me_mp function has appeared. > > > > > > I'm attaching speed&compression report to every patch to proof > effectivity > > > of each implemented part. > > > > > > I'll appreciate feedback > > > > > > Best regards, > > > Stanislav > > > > > > > > > > > -- > > Станислав Долганов > > > avcodec.h | 33 > > ffv1enc.c |2 + > > me_cmp.c| 76 ++ > ++ > > me_cmp.h|1 > > motion_est.c|1 > > mpegvideo.h |3 +- > > obme.c |1 > > options_table.h |1 > > 8 files changed, 101 insertions(+), 17 deletions(-) > > patch applied > (without changes in obme and ffv1enc) > > Please update the docs in doc/*.texi > > Thanks > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Old school: Use the lowest level language in which you can solve the > problem > conveniently. > New school: Use the highest level language in which the latest > supercomputer > can solve the problem without the user falling asleep waiting. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > -- Станислав Долганов 0003-median-compare-function-for-ffv1-me.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add max value output option to psnr stats log.
> if the user sets output_max without stats_version 2 this would just
silently ignore the option
Do you think this warrants a fatal error? A warning seems insufficient as
the output_max option is explicitly requested by the user.
> also missing doc/*.texi update
Should I send that in a followup patch once this one is finalized or would
you prefer them both in the same patch?
On 27 August 2016 at 03:13, Michael Niedermayer
wrote:
> On Fri, Aug 26, 2016 at 12:10:17PM -0700, Lucas Cooper wrote:
> > This allows retroactive calculation/aggregation of PSNR from the stats
> > log.
> > ---
> > libavfilter/vf_psnr.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
> > index 3bec747..9ad1423 100644
> > --- a/libavfilter/vf_psnr.c
> > +++ b/libavfilter/vf_psnr.c
> > @@ -45,6 +45,7 @@ typedef struct PSNRContext {
> > char *stats_file_str;
> > int stats_version;
> > int stats_header_written;
> > +int stats_add_max;
> > int max[4], average_max;
> > int is_rgb;
> > uint8_t rgba_map[4];
> > @@ -63,6 +64,7 @@ static const AVOption psnr_options[] = {
> > {"stats_file", "Set file where to store per-frame difference
> information", OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0,
> 0, FLAGS },
> > {"f", "Set file where to store per-frame difference
> information", OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0,
> 0, FLAGS },
> > {"stats_version", "Set the format version for the stats file.",
>OFFSET(stats_version), AV_OPT_TYPE_INT,{.i64=1},1, 2,
> FLAGS },
> > +{"output_max", "Add raw stats (max values) to the output log.",
> OFFSET(stats_add_max), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> > { NULL }
> > };
> >
> > @@ -182,6 +184,12 @@ static AVFrame *do_psnr(AVFilterContext *ctx,
> AVFrame *main,
> > for (j = 0; j < s->nb_components; j++) {
> > fprintf(s->stats_file, ",psnr_%c", s->comps[j]);
> > }
> > +if (s->stats_add_max) {
> > +fprintf(s->stats_file, ",max_avg");
> > +for (j = 0; j < s->nb_components; j++) {
> > +fprintf(s->stats_file, ",max_%c", s->comps[j]);
> > +}
> > +}
> > fprintf(s->stats_file, "\n");
> > s->stats_header_written = 1;
> > }
> > @@ -196,6 +204,13 @@ static AVFrame *do_psnr(AVFilterContext *ctx,
> AVFrame *main,
> > fprintf(s->stats_file, "psnr_%c:%0.2f ", s->comps[j],
> > get_psnr(comp_mse[c], 1, s->max[c]));
> > }
> > +if (s->stats_version == 2 && s->stats_add_max) {
> > +fprintf(s->stats_file, "max_avg:%d ", s->average_max);
> > +for (j = 0; j < s->nb_components; j++) {
> > +c = s->is_rgb ? s->rgba_map[j] : j;
> > +fprintf(s->stats_file, "max_%c:%d ", s->comps[j],
> s->max[c]);
> > +}
> > +}
> > fprintf(s->stats_file, "\n");
>
> if the user sets output_max without stats_version 2 this would just
> silently ignore the option
> also missing doc/*.texi update
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite
> number
> of states N, and will either halt in less than N cycles or never halt.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/version: Mention similarities and differences to semver
On Sat, Aug 06, 2016 at 12:52:53PM +0200, Michael Niedermayer wrote: > QUESTION: is this the best place for this ? > > Signed-off-by: Michael Niedermayer > --- > libavutil/version.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/libavutil/version.h b/libavutil/version.h > index b2dffb7..7692def 100644 > --- a/libavutil/version.h > +++ b/libavutil/version.h > @@ -35,6 +35,12 @@ > * Useful to check and match library version in order to maintain > * backward compatibility. > * > + * The FFmpeg libraries follow a versioning sheme very similar to > + * Semantic Versioning (http://semver.org/) > + * The difference is that the component called PATCH is called MICRO in > FFmpeg > + * and its value is reset to 100 instead of 0 to keep it above or equal to > 100. > + * Also we do not increase MICRO for every bugfix or change. i added "in git master", iam not sure this is the best so feel free to improve applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On 8/29/2016 8:43 PM, James Almer wrote:
> On 8/27/2016 9:58 AM, Timo Rothenpieler wrote:
>> @@ -5996,6 +5992,22 @@ enabled vdpau && enabled xlib &&
>> check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11
>> -lvdpau &&
>> enable vdpau_x11
>>
>> +case $target_os in
>> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
>> +disabled nvenc || enable nvenc
>> +;;
>> +*)
>> +disable nvenc
>> +;;
>> +esac
>> +
>> +if enabled nvenc; then
>> +{
>> +echo '#include "compat/nvenc/nvEncodeAPI.h"'
>> +echo 'int main(void) { return 0; }'
>> +} | check_cc -I$source_path || disable nvenc
>
> In what situation could this test fail? nvenc is only enabled if $target_os
> is one of the supported ones, and the test does nothing but compile the
> header.
Strange/broken compiler like ancient MinGW or Cygwin, or old MSVC.
> If it only supports x86 then you can just check "enabled x86" instead.
NVENC is not supported on FreeBSD or OSX for example.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] [RFC] avutil/version: Improve lib versioning sheme for release branches with the next major release
On Sat, Aug 06, 2016 at 03:26:04PM +0200, Moritz Barsnick wrote: > On Sat, Aug 06, 2016 at 12:52:54 +0200, Michael Niedermayer wrote: > > + * Prior FFmpeg 3.2 point releases did not change any lib version number to > ^ Prior to > > > + * a seperate MAJOR.MINOR that is not used on the master development branch > ^ separate > > > + * that is if we branch a release of master 55.10.123 we will bump to > > 55.11.100 > ^ . That is [I.e. split sentences here.] > > > + * point release will then bump the MICRO improving the usefullness of the > > lib >^ usefulness typos fixed applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for libavformat/crypto to add seeking on read
thanks Michael,
try the attached file. I assume the corruption came from email word
wrapping? or was there something else wrong?
simon
On Mon, Aug 29, 2016 at 6:11 PM, Michael Niedermayer wrote:
> On Mon, Aug 29, 2016 at 11:08:36AM +0100, Simon H wrote:
> > crypto allows reading of data which has been aes-128-cbc encrypted given
> a
> > key and an iv.
> > But it did not handle filetypes which require seeking... e.g. it failed
> on
> > an encrypted .mp4 file.
> >
> > example:
> > take 25.mp4 created with:
> > ffmpeg -f lavfi -i sine=frequency=1000:beep_
> factor=2:r=48000:duration=720.0
> > -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22
> > -timecode 10:00:00:00 -r 25 -y out\25.mp4
> >
> > encrypt with:
> > openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv
> > 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
> > then to transcode in ffmpeg:
> > ffmpeg -key 12345678901234567890123456789012 -iv
> > 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y
> > 25dec.mp4
> >
> > prior to this modification, the transcode would fail.
> >
> > Note also: crypto previously marked both reads and writes as streamed,
> > which caused the whole file
> > to be read before the transcode started. Now, for read only, if the
> > underlying layer is not marked as streamed,
> > then crypto is not. This should enable efficient reading of encrypted
> > containers which require seeking.
> >
> > this is my first patch for ffmpeg; guidance appreciated.
> > ---
> > libavformat/crypto.c | 115
> > +--
> > 1 file changed, 112 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/crypto.c b/libavformat/crypto.c
> > index 2999f50..23bc0a6 100644
> > --- a/libavformat/crypto.c
> > +++ b/libavformat/crypto.c
> > @@ -26,7 +26,8 @@
> > #include "internal.h"
> > #include "url.h"
> >
> > -#define MAX_BUFFER_BLOCKS 150
> > +// encourage reads of 4096 bytes - 1 block is always retained.
> > +#define MAX_BUFFER_BLOCKS 257
> > #define BLOCKSIZE 16
> >
> > typedef struct CryptoContext {
> > @@ -36,6 +37,8 @@ typedef struct CryptoContext {
> > outbuffer[BLOCKSIZE*MAX_BUFFER_BLOCKS];
> > uint8_t *outptr;
> > int indata, indata_used, outdata;
> > +int64_t position; // position in file - used in seek
> > +int flags;
> > int eof;
> > uint8_t *key;
> > int keylen;
> > @@ -109,6 +112,7 @@ static int crypto_open2(URLContext *h, const char
> *uri,
> > int flags, AVDictionary
> > const char *nested_url;
> > int ret = 0;
> > CryptoContext *c = h->priv_data;
> > +c->flags = flags;
> >
> > if (!av_strstart(uri, "crypto+", &nested_url) &&
> > !av_strstart(uri, "crypto:", &nested_url)) {
> > @@ -117,6 +121,8 @@ static int crypto_open2(URLContext *h, const char
> *uri,
> > int flags, AVDictionary
>
> patch corrupted by newlines
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
libavformat_crypto_seek_patch.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swscale: add support for P010LE/BE output
---
libswscale/output.c | 98 +++-
libswscale/utils.c | 4 +-
libswscale/x86/swscale.c | 4 +-
tests/ref/fate/filter-pixdesc-p010be | 1 +
tests/ref/fate/filter-pixdesc-p010le | 1 +
tests/ref/fate/filter-pixfmts-copy | 2 +
tests/ref/fate/filter-pixfmts-crop | 2 +
tests/ref/fate/filter-pixfmts-field | 2 +
tests/ref/fate/filter-pixfmts-hflip | 2 +
tests/ref/fate/filter-pixfmts-il | 2 +
tests/ref/fate/filter-pixfmts-null | 2 +
tests/ref/fate/filter-pixfmts-pad| 1 +
tests/ref/fate/filter-pixfmts-scale | 2 +
tests/ref/fate/filter-pixfmts-vflip | 2 +
14 files changed, 120 insertions(+), 5 deletions(-)
create mode 100644 tests/ref/fate/filter-pixdesc-p010be
create mode 100644 tests/ref/fate/filter-pixdesc-p010le
diff --git a/libswscale/output.c b/libswscale/output.c
index f340c53..62cbe2f 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -311,6 +311,98 @@ static void yuv2nv12cX_c(SwsContext *c, const int16_t
*chrFilter, int chrFilterS
}
}
+
+#define output_pixel(pos, val) \
+if (big_endian) { \
+AV_WB16(pos, av_clip_uintp2(val >> shift, 10) << 6); \
+} else { \
+AV_WL16(pos, av_clip_uintp2(val >> shift, 10) << 6); \
+}
+
+static void yuv2p010l1_c(const int16_t *src,
+ uint16_t *dest, int dstW,
+ int big_endian)
+{
+int i;
+int shift = 5;
+
+for (i = 0; i < dstW; i++) {
+int val = src[i] + (1 << (shift - 1));
+output_pixel(&dest[i], val);
+}
+}
+
+static void yuv2p010lX_c(const int16_t *filter, int filterSize,
+ const int16_t **src, uint16_t *dest, int dstW,
+ int big_endian)
+{
+int i, j;
+int shift = 17;
+
+for (i = 0; i < dstW; i++) {
+int val = 1 << (shift - 1);
+
+for (j = 0; j < filterSize; j++)
+val += src[j][i] * filter[j];
+
+output_pixel(&dest[i], val);
+}
+}
+
+static void yuv2p010cX_c(SwsContext *c, const int16_t *chrFilter, int
chrFilterSize,
+ const int16_t **chrUSrc, const int16_t **chrVSrc,
+ uint8_t *dest8, int chrDstW)
+{
+uint16_t *dest = (uint16_t*)dest8;
+int shift = 17;
+int big_endian = c->dstFormat == AV_PIX_FMT_P010BE;
+int i, j;
+
+for (i = 0; i < chrDstW; i++) {
+int u = 1 << (shift - 1);
+int v = 1 << (shift - 1);
+
+for (j = 0; j < chrFilterSize; j++) {
+u += chrUSrc[j][i] * chrFilter[j];
+v += chrVSrc[j][i] * chrFilter[j];
+}
+
+output_pixel(&dest[2*i] , u);
+output_pixel(&dest[2*i+1], v);
+}
+}
+
+static void yuv2p010l1_LE_c(const int16_t *src,
+uint8_t *dest, int dstW,
+const uint8_t *dither, int offset)
+{
+yuv2p010l1_c(src, (uint16_t*)dest, dstW, 0);
+}
+
+static void yuv2p010l1_BE_c(const int16_t *src,
+uint8_t *dest, int dstW,
+const uint8_t *dither, int offset)
+{
+yuv2p010l1_c(src, (uint16_t*)dest, dstW, 1);
+}
+
+static void yuv2p010lX_LE_c(const int16_t *filter, int filterSize,
+const int16_t **src, uint8_t *dest, int dstW,
+const uint8_t *dither, int offset)
+{
+yuv2p010lX_c(filter, filterSize, src, (uint16_t*)dest, dstW, 0);
+}
+
+static void yuv2p010lX_BE_c(const int16_t *filter, int filterSize,
+const int16_t **src, uint8_t *dest, int dstW,
+const uint8_t *dither, int offset)
+{
+yuv2p010lX_c(filter, filterSize, src, (uint16_t*)dest, dstW, 1);
+}
+
+#undef output_pixel
+
+
#define accumulate_bit(acc, val) \
acc <<= 1; \
acc |= (val) >= 234
@@ -2085,7 +2177,11 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
enum AVPixelFormat dstFormat = c->dstFormat;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(dstFormat);
-if (is16BPS(dstFormat)) {
+if (dstFormat == AV_PIX_FMT_P010LE || dstFormat == AV_PIX_FMT_P010BE) {
+*yuv2plane1 = isBE(dstFormat) ? yuv2p010l1_BE_c : yuv2p010l1_LE_c;
+*yuv2planeX = isBE(dstFormat) ? yuv2p010lX_BE_c : yuv2p010lX_LE_c;
+*yuv2nv12cX = yuv2p010cX_c;
+} else if (is16BPS(dstFormat)) {
*yuv2planeX = isBE(dstFormat) ? yuv2planeX_16BE_c : yuv2planeX_16LE_c;
*yuv2plane1 = isBE(dstFormat) ? yuv2plane1_16BE_c : yuv2plane1_16LE_c;
} else if (is9_OR_10BPS(dstFormat)) {
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 576d8f0..0aef672 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -246,8 +246,8 @@ static const FormatEntry format_entries[AV_PIX_FMT_NB] = {
[AV_PIX_FMT_XYZ12BE] = { 1, 1, 1 },
[AV_PIX_FMT_XYZ12LE] = { 1, 1, 1 },
[AV_PIX_FMT_AYUV64LE]= { 1, 1},
-[AV_PIX_FMT_P010LE] =
Re: [FFmpeg-devel] [GSOC][PATCH 3/4] median compare function for ffv1 me
On Mon, Aug 29, 2016 at 09:11:25PM +0100, Станислав Долганов wrote: > Info added to codecs.texi please rebase this on git master, most of this patch been applied already thx [...] -- 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] added expr evaluation to drawtext - fontsize
Before I fix the patch, can you clarify the intended functionality?
The docs say that 16 is the default fontsize, however if
CONFIG_LIBFONTCONFIG is configured and ffmpeg if called with:
-vf drawtext=text=abc:fontcolor=white
on my system the font used will be /opt/X11/share/fonts/TTF/Vera.ttf (the
default chosen by libfontconfig) and the fontsize will be set to 12.
However if ffmpeg is called with:
-vf
drawtext=text=abc:fontcolor=white:fontfile=/opt/X11/share/fonts/TTF/Vera.ttf
This is the same font that libfontconfig used, however this time fontsize
16 is used as stated in the docs.
The difference is this line of code in load_font_fontconfig
if (!s->fontsize)
s->fontsize = size + 0.5;
I didn't set the fontsize in either command, but the output was different.
Do we want to keep this as is?
On Sun, Aug 28, 2016 at 6:09 PM, Michael Niedermayer wrote:
> On Sat, Aug 27, 2016 at 04:30:05PM -0700, Brett Harrison wrote:
> > Fixed patch based on comments.
> >
> > This time attaching patch file.
> >
> > On Sat, Aug 27, 2016 at 6:21 AM, Moritz Barsnick
> wrote:
> >
> > > On Fri, Aug 26, 2016 at 14:37:42 -0700, Brett Harrison wrote:
> > >
> > > > +if (diff != 0) {
> > > > + return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > > > +}
> > >
> > > If diff != 0, it can only be >0 or <0, nothing else:
> > >if (diff != 0)
> > > return diff > 0 ? 1 : -1;
> > > (And you can drop the curly brackets.)
> > >
> > > > +else {
> > > > + int64_t diff = (int64_t)a->fontsize - (int64_t)bb->fontsize;
> > > > + return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> > > > +}
> > >
> > > There's a macro for this:
> > >else
> > >return FFDIFFSIGN((int64_t)a->fontsize,
> (int64_t)bb->fontsize);
> > >
> > > Moritz
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
>
> > vf_drawtext.c | 86 ++
> +++-
> > 1 file changed, 79 insertions(+), 7 deletions(-)
> > dd219d9b4d4f02ca4299a0bfd6ea3d5c15545f2b 0001-added-expr-evaluation-to-
> drawtext-fontsize.patch
> > From 5c9d7d18a5d2f15f48605021d7f5a7890a318cc4 Mon Sep 17 00:00:00 2001
> > From: Brett Harrison
> > Date: Fri, 26 Aug 2016 14:29:34 -0700
> > Subject: [PATCH] added expr evaluation to drawtext - fontsize
>
> this changes the output and fontsize when fontsize is not explicitly
> specified
>
> for example:
> -vf drawtext=text=abc:fontcolor=white
>
>
> >
> > ---
> > libavfilter/vf_drawtext.c | 86 ++
> +
> > 1 file changed, 79 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > index 214aef0..5311e29 100644
> > --- a/libavfilter/vf_drawtext.c
> > +++ b/libavfilter/vf_drawtext.c
> > @@ -156,6 +156,8 @@ typedef struct DrawTextContext {
> > int max_glyph_h;///< max glyph height
> > int shadowx, shadowy;
> > int borderw;///< border width
> > +char *fontsize_expr;///< expression for fontsize
> > +AVExpr *fontsize_pexpr; ///< parsed expressions for fontsize
> > unsigned int fontsize; ///< font size to use
> >
> > short int draw_box; ///< draw box around text - true or
> false
> > @@ -209,7 +211,7 @@ static const AVOption drawtext_options[]= {
> > {"shadowcolor", "set shadow color", OFFSET(shadowcolor.rgba),
> AV_OPT_TYPE_COLOR, {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > {"box", "set box", OFFSET(draw_box),
> AV_OPT_TYPE_BOOL, {.i64=0}, 0,1 , FLAGS},
> > {"boxborderw", "set box border width", OFFSET(boxborderw),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
> > -{"fontsize","set font size",OFFSET(fontsize),
> AV_OPT_TYPE_INT,{.i64=0}, 0,INT_MAX , FLAGS},
> > +{"fontsize","set font size",OFFSET(fontsize_expr),
> AV_OPT_TYPE_STRING, {.str="16"}, CHAR_MIN, CHAR_MAX , FLAGS},
> > {"x", "set x expression", OFFSET(x_expr),
> AV_OPT_TYPE_STRING, {.str="0"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > {"y", "set y expression", OFFSET(y_expr),
> AV_OPT_TYPE_STRING, {.str="0"}, CHAR_MIN, CHAR_MAX, FLAGS},
> > {"shadowx", "set shadow x offset", OFFSET(shadowx),
> AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
> > @@ -280,6 +282,7 @@ typedef struct Glyph {
> > FT_Glyph glyph;
> > FT_Glyph border_glyph;
> > uint32_t code;
> > +unsigned int fontsize;
> > FT_Bitmap bitmap; ///< array holding bitmaps of font
> > FT_Bitmap border_bitmap; ///< array holding bitmaps of font border
> > FT_BBox bbox;
> > @@ -292,7 +295,11 @@ static int glyph_cmp(const void *key, const void *b)
> > {
> > const Glyph *a = key, *bb = b;
> > int64_t
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On 8/29/2016 5:31 PM, Timo Rothenpieler wrote:
> On 8/29/2016 8:43 PM, James Almer wrote:
>> On 8/27/2016 9:58 AM, Timo Rothenpieler wrote:
>>> @@ -5996,6 +5992,22 @@ enabled vdpau && enabled xlib &&
>>> check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11
>>> -lvdpau &&
>>> enable vdpau_x11
>>>
>>> +case $target_os in
>>> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
>>> +disabled nvenc || enable nvenc
>>> +;;
>>> +*)
>>> +disable nvenc
>>> +;;
>>> +esac
>>> +
>>> +if enabled nvenc; then
>>> +{
>>> +echo '#include "compat/nvenc/nvEncodeAPI.h"'
>>> +echo 'int main(void) { return 0; }'
>>> +} | check_cc -I$source_path || disable nvenc
>>
>> In what situation could this test fail? nvenc is only enabled if $target_os
>> is one of the supported ones, and the test does nothing but compile the
>> header.
>
> Strange/broken compiler like ancient MinGW or Cygwin, or old MSVC.
I don't think anything in those could break compilation of this header. It
doesn't seem to use any api, define or struct from windows only headers
aside from RECT, GUID and __stdcall.
If any of the nvenc files from libavcodec depends on something that could
be missing in old and broken compilers then a more specific check should
be done for it.
>
>> If it only supports x86 then you can just check "enabled x86" instead.
>
> NVENC is not supported on FreeBSD or OSX for example.
I figured as much seeing the OS list above. What i meant was that if the
check was meant to make sure it's only enabled on x86 linux/windows
targets, and not for example ARM like when building for WinRT, then you
could simply check for supported OSes and x86 arch.
This test succeeds on every Linux/Windows target. It includes only
stdint.h, stdlib.h, windows.h if necessary, and defines RECT and GUID
on non-Windows platforms.
See http://fate.ffmpeg.org/. All the nvenc files are being compiled on
every platform (arm, aarch64, alpha, mips, etc).
> ___
> 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] avisynth: support pix_fmts added to AviSynth+
On Tue, Aug 16, 2016 at 06:45:21PM -0400, Stephen Hutchinson wrote: > A number of new pix_fmts have been added to AviSynth+: > 16-bit packed RGB and RGBA > 10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4 > 8-, 10-, 12-, 14-, and 16-bit Planar RGB > 8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA* > 10-, 12-, 14-, and 16-bit GRAY variants* > 32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY* > > *some of which are not currently available pix_fmts here and were > not added to the demuxer due to this > --- > libavformat/avisynth.c | 183 > - > 1 file changed, 182 insertions(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add max value output option to psnr stats log.
On Mon, Aug 29, 2016 at 01:12:10PM -0700, Lucas Cooper wrote: > > if the user sets output_max without stats_version 2 this would just > silently ignore the option > > Do you think this warrants a fatal error? A warning seems insufficient as > the output_max option is explicitly requested by the user. yes > > > also missing doc/*.texi update > > Should I send that in a followup patch once this one is finalized or would > you prefer them both in the same patch? iam fine with either but a single patch for docs and corresponding feature makes more sense to me thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added expr evaluation to drawtext - fontsize
On Mon, Aug 29, 2016 at 02:23:44PM -0700, Brett Harrison wrote: > Before I fix the patch, can you clarify the intended functionality? > > The docs say that 16 is the default fontsize, however if > CONFIG_LIBFONTCONFIG is configured and ffmpeg if called with: > > -vf drawtext=text=abc:fontcolor=white > > on my system the font used will be /opt/X11/share/fonts/TTF/Vera.ttf (the > default chosen by libfontconfig) and the fontsize will be set to 12. > > However if ffmpeg is called with: > > -vf > drawtext=text=abc:fontcolor=white:fontfile=/opt/X11/share/fonts/TTF/Vera.ttf > > This is the same font that libfontconfig used, however this time fontsize > 16 is used as stated in the docs. > > The difference is this line of code in load_font_fontconfig > if (!s->fontsize) > s->fontsize = size + 0.5; > > I didn't set the fontsize in either command, but the output was different. > Do we want to keep this as is? I think no can you send a seperate patch that changes this ? (it should really not change as a sideeffect of this patch) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Patch for libavformat/crypto to add seeking on read
On Mon, Aug 29, 2016 at 09:56:59PM +0100, Simon H wrote:
> thanks Michael,
>
> try the attached file. I assume the corruption came from email word
> wrapping?
likely
> or was there something else wrong?
[...]
> example:
> take 25.mp4 created with:
> ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0
> -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22 -timecode
> 10:00:00:00 -r 25 -y out\25.mp4
>
> encrypt with:
> openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv
> 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
> then to transcode in ffmpeg:
> ffmpeg -key 12345678901234567890123456789012 -iv
> 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y
> 25dec.mp4
>
> prior to this modification, the transcode would fail.
>
> Note also: crypto previously marked both reads and writes as streamed, which
> caused the whole file
> to be read before the transcode started. Now, for read only, if the
> underlying layer is not marked as streamed,
> then crypto is not. This should enable efficient reading of encrypted
> containers which require seeking.
> ---
> libavformat/crypto.c | 115
> +--
> 1 file changed, 112 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/crypto.c b/libavformat/crypto.c
> index 2999f50..23bc0a6 100644
> --- a/libavformat/crypto.c
> +++ b/libavformat/crypto.c
> @@ -26,7 +26,8 @@
> #include "internal.h"
> #include "url.h"
>
> -#define MAX_BUFFER_BLOCKS 150
> +// encourage reads of 4096 bytes - 1 block is always retained.
> +#define MAX_BUFFER_BLOCKS 257
> #define BLOCKSIZE 16
>
> typedef struct CryptoContext {
this should be in a separate patch
> @@ -36,6 +37,8 @@ typedef struct CryptoContext {
> outbuffer[BLOCKSIZE*MAX_BUFFER_BLOCKS];
> uint8_t *outptr;
> int indata, indata_used, outdata;
> +int64_t position; // position in file - used in seek
> +int flags;
> int eof;
> uint8_t *key;
> int keylen;
> @@ -109,6 +112,7 @@ static int crypto_open2(URLContext *h, const char *uri,
> int flags, AVDictionary
> const char *nested_url;
> int ret = 0;
> CryptoContext *c = h->priv_data;
> +c->flags = flags;
>
> if (!av_strstart(uri, "crypto+", &nested_url) &&
> !av_strstart(uri, "crypto:", &nested_url)) {
> @@ -117,6 +121,8 @@ static int crypto_open2(URLContext *h, const char *uri,
> int flags, AVDictionary
> goto err;
> }
>
> +c->position = 0L;
> +
> if (flags & AVIO_FLAG_READ) {
> if ((ret = set_aes_arg(c, &c->decrypt_key, &c->decrypt_keylen,
> c->key, c->keylen, "decryption key")) < 0)
> @@ -152,6 +158,10 @@ static int crypto_open2(URLContext *h, const char *uri,
> int flags, AVDictionary
> ret = av_aes_init(c->aes_decrypt, c->decrypt_key, BLOCKSIZE*8, 1);
> if (ret < 0)
> goto err;
> +
> +// pass back information about the context we openned
> +if (c->hd->is_streamed)
> +h->is_streamed = c->hd->is_streamed;
> }
>
> if (flags & AVIO_FLAG_WRITE) {
> @@ -163,12 +173,13 @@ static int crypto_open2(URLContext *h, const char *uri,
> int flags, AVDictionary
> ret = av_aes_init(c->aes_encrypt, c->encrypt_key, BLOCKSIZE*8, 0);
> if (ret < 0)
> goto err;
> +// for write, we must be streamed
> +// - linear write only for crytpo aes-128-cbc
> +h->is_streamed = 1;
> }
>
> c->pad_len = 0;
>
> -h->is_streamed = 1;
> -
> err:
> return ret;
> }
> @@ -183,6 +194,7 @@ retry:
> memcpy(buf, c->outptr, size);
> c->outptr += size;
> c->outdata -= size;
> +c->position = c->position + size;
> return size;
> }
> // We avoid using the last block until we've found EOF,
> @@ -222,6 +234,102 @@ retry:
> goto retry;
> }
>
> +static int64_t crypto_seek(URLContext *h, int64_t pos, int whence)
> +{
> +CryptoContext *c = h->priv_data;
> +int64_t block;
> +int64_t newpos;
> +
> +if (c->flags & AVIO_FLAG_WRITE) {
> +av_log(h, AV_LOG_ERROR,
> +"Crypto: seek not supported for write\r\n");
> +return -1L;
should be a AVERROR* code
> +}
> +
> +// reset eof, else we won't read it correctly if we already hit eof.
> +c->eof = 0;
> +
> +switch (whence) {
> +case SEEK_SET:
> +break;
> +case SEEK_CUR:
> +pos = pos + c->position;
> +break;
> +case SEEK_END: {
> +int64_t newpos = ffurl_seek( c->hd, pos, AVSEEK_SIZE );
> +if (newpos < 0) {
> +av_log(h, AV_LOG_ERROR,
> +"Crypto: seek_end - can't get file size (pos=%lld)\r\n",
> pos);
libavformat/crypto.c: In function ‘crypto_seek’:
libavformat/crypto.c:262:17: warning: format ‘%lld’ expects argument of type
‘long long int’, but arg
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: vf_minterpolate: rename chroma log vars
On Mon, Aug 29, 2016 at 8:59 PM Paul B Mahol wrote: [...] And using avcodec* stuff is in lavfi is not needed. uses AVPixFmtDesc now. should I also not use libavcodec/mathops.h? median of 3 function is shared. can it be moved? updated patch attached. 0001-avfilter-vf_minterpolate-rename-chroma-log-vars.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/APIChanges: mention nb_threads addition to AVFilterContext
On 8/29/2016 4:56 PM, Paul B Mahol wrote: > On Mon, Aug 29, 2016 at 8:17 PM, James Almer wrote: > >> Signed-off-by: James Almer >> --- >> doc/APIchanges | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/doc/APIchanges b/doc/APIchanges >> index 2572b1c..7ac809c 100644 >> --- a/doc/APIchanges >> +++ b/doc/APIchanges >> @@ -15,6 +15,9 @@ libavutil: 2015-08-28 >> >> API changes, most recent first: >> >> +2016-08-29 - 4493390 - lavfi 6.58.100 - avfilter.h >> + Add AVFilterContext.nb_threads. >> + >> 2016-08-15 - c3c4c72 - lavc 57.53.100 - avcodec.h >>Add trailing_padding to AVCodecContext to match the corresponding >>field in AVCodecParameters. >> -- >> 2.9.1 >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > LGTM Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Sat, Aug 27, 2016 at 6:15 PM Robert Krüger wrote: > [...] > what is the way to best contribute with test cases? I have two samples that > I use for testing, so far the results look very, very promising but there > are still a few artefact problems, so these could maybe serve as a good > test case. In some cases the artefacts almost certainly look like there is > a bug in motion vector calculation as a very large area suddenly begins to > move in which really only a small part is/should be moving. > > How do I make this available to you or other devs at this stage? Just trac > tickets or is it too early for that and you would like to work on this > differently? After all it is always a grey area, when this can be > considered solved, as it is a process of gradual improvements, so maybe > it's not well-suited for a ticket. > > Let me know. Happy to contribute samples and some testing time here and > there. > I'm currently testing support for unrestricted search area which can be used with EPZS, which has improved the quality. Once I send the patch you can test if it actually reduces the artifacts or doesn't make it worse. For smaller details newer recursive algorithms should perform better. Like this one, https://www.osapublishing.org/jdt/abstract.cfm?uri=jdt-11-7-580 which uses Modified 3D recursive search iteratively. So, at this point before any new algorithm is implemented, best way to test is to verify the experiments I do improves the quality for most of the samples or not. One would like to compare PSNR, as it's hard compare each frame visually. http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/193067.html (for better results, original sample should be 60fps, subsampled to 30) for visual testing, I used to transcode interpolate sample to images and compared them to original ones. Thanks for testing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Mon, Aug 29, 2016 at 12:20 PM Clément Bœsch wrote: > On Sun, Aug 28, 2016 at 11:31:10AM +0200, Paul B Mahol wrote: > > On Sat, Aug 27, 2016 at 2:45 PM, Robert Krüger > > > wrote: > > > > > > what is the way to best contribute with test cases? I have two samples > that > > > I use for testing, so far the results look very, very promising but > there > > > are still a few artefact problems, so these could maybe serve as a good > > > test case. In some cases the artefacts almost certainly look like > there is > > > a bug in motion vector calculation as a very large area suddenly > begins to > > > move in which really only a small part is/should be moving. > > > > > > How do I make this available to you or other devs at this stage? Just > trac > > > tickets or is it too early for that and you would like to work on this > > > differently? After all it is always a grey area, when this can be > > > considered solved, as it is a process of gradual improvements, so maybe > > > it's not well-suited for a ticket. > > > > > > Let me know. Happy to contribute samples and some testing time here and > > > there. > > > > > > You can provide them either publicly or privately to any of devs > interested. > > I'm always interested in short samples exhibiting the problem. > > Using http://b.pkh.me/sfx-sky.mov and comparing: > > ./ffplay -flags2 +export_mvs sfx-sky.mov -vf codecview=mv=pf > > with > > ./ffplay sfx-sky.mov -vf mestimate,codecview=mv=pf > > The encoded mvs looks much more meaningful that the ones found with > mestimate. Typically, if you're looking for a global motion of some sort, > the "native" mvs makes much more clear that there is a mostly static area > at the bottom and a panning one on top with its direction pretty obvious. > With mestimate, it just looks like small noise. Any plan to improve this? > > -- > Clément B > that's probably because the mestimate doesn't use penalty term as used in minterpolate and encoders to make the motion field smooth. mestimate just stores the best match. it can be easily done by adding https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_minterpolate.c#L274 to default function https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/motion_estimation.c#L59 The reason I didn't do that yet, we've plans to make Motion Estimation API and the cost function doesn't seem to be correct place for penalty term. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: fix implicit declaration of SetDllDirectory function
On 8/29/2016 10:42 AM, Tobias Rapp wrote: > Attached patch fixes a build error on my system (Ubuntu 14.04, mingw-w64 > 3.1.0, gcc-mingw-w64 4.8.2) introduced by commit > 3bf142c77337814458ed8e036796934032d9837f. Interesting. windows.h is already included if CommandLineToArgvW() is available. I guess this means old mingw-w64 doesn't define it. > > As the original commit has been backported to older releases (2.8, 3.0 and > 3.1 as far as I can see) it probably makes sense to backport this fix, too. Applied where it's needed. Thanks. > > Regards, > Tobias > > 0001-cmdutils-fix-implicit-declaration-of-SetDllDirectory.patch > > > From 97c153fab37a44946e54fcea6b48259cb0c24143 Mon Sep 17 00:00:00 2001 > From: Tobias Rapp > Date: Mon, 29 Aug 2016 15:25:58 +0200 > Subject: [PATCH] cmdutils: fix implicit declaration of SetDllDirectory > function > > Signed-off-by: Tobias Rapp > --- > cmdutils.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/cmdutils.c b/cmdutils.c > index 6960f8c..44f44cd 100644 > --- a/cmdutils.c > +++ b/cmdutils.c > @@ -61,6 +61,9 @@ > #include > #include > #endif > +#ifdef _WIN32 > +#include > +#endif > > static int init_report(const char *env); > > -- 1.9.1 > > > > ___ > 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] avcodec/nvenc: Include nvEncodeAPI v7 SDK header
On 8/29/2016 7:13 PM, James Almer wrote:
> On 8/29/2016 5:31 PM, Timo Rothenpieler wrote:
>> On 8/29/2016 8:43 PM, James Almer wrote:
>>> On 8/27/2016 9:58 AM, Timo Rothenpieler wrote:
@@ -5996,6 +5992,22 @@ enabled vdpau && enabled xlib &&
check_lib2 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11
-lvdpau &&
enable vdpau_x11
+case $target_os in
+mingw32*|mingw64*|win32|win64|linux|cygwin*)
+disabled nvenc || enable nvenc
+;;
+*)
+disable nvenc
+;;
+esac
+
+if enabled nvenc; then
+{
+echo '#include "compat/nvenc/nvEncodeAPI.h"'
+echo 'int main(void) { return 0; }'
+} | check_cc -I$source_path || disable nvenc
>>>
>>> In what situation could this test fail? nvenc is only enabled if $target_os
>>> is one of the supported ones, and the test does nothing but compile the
>>> header.
>>
>> Strange/broken compiler like ancient MinGW or Cygwin, or old MSVC.
>
> I don't think anything in those could break compilation of this header. It
> doesn't seem to use any api, define or struct from windows only headers
> aside from RECT, GUID and __stdcall.
> If any of the nvenc files from libavcodec depends on something that could
> be missing in old and broken compilers then a more specific check should
> be done for it.
Indeed, the fact this test succeeds on pretty much every target revealed
that nvenc.c isn't compiling with msvc 2012, probably because of c99-to-89.
http://fate.ffmpeg.org/log.cgi?time=20160829225456&log=compile&slot=x86_32-msvc11-windows-native
And mingw32 (Not mingw-w64) but in this case because of missing defines.
http://fate.ffmpeg.org/log.cgi?time=20160829044509&log=compile&slot=x86_64-freebsd10-mingw32
It also broke gcc-asan on linux x86.
http://fate.ffmpeg.org/log.cgi?time=20160830020159&log=compile&slot=x86_64-archlinux-gcc-asan
>
>>
>>> If it only supports x86 then you can just check "enabled x86" instead.
>>
>> NVENC is not supported on FreeBSD or OSX for example.
>
> I figured as much seeing the OS list above. What i meant was that if the
> check was meant to make sure it's only enabled on x86 linux/windows
> targets, and not for example ARM like when building for WinRT, then you
> could simply check for supported OSes and x86 arch.
>
> This test succeeds on every Linux/Windows target. It includes only
> stdint.h, stdlib.h, windows.h if necessary, and defines RECT and GUID
> on non-Windows platforms.
> See http://fate.ffmpeg.org/. All the nvenc files are being compiled on
> every platform (arm, aarch64, alpha, mips, etc).
>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: vf_minterpolate: rename chroma log vars
On Tuesday, August 30, 2016, Davinder Singh wrote: > On Mon, Aug 29, 2016 at 8:59 PM Paul B Mahol > wrote: > [...] > > And using avcodec* stuff is in lavfi is not needed. > > uses AVPixFmtDesc now. should I also not use libavcodec/mathops.h? median > of 3 function is shared. can it be moved? They appear to be inlined, so not needed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/os_support: Add safe win32 dlopen/dlclose/dlsym functions.
> > FYI, last time i tried to include this file from libavcodec i was told > not to since it's libavformat specific. > > The proper place for these wrappers is probably the compat folder, in > a new file similar to w32threads.h > It occurred to me as well that this should be a common header perhaps supplied in libavutil. Currently os_support has many similar functions that provide win32 specific implementations of missing functionality so adding this patch to the existing list of functions supplied in that header seemed the most suitable place to include it as it keeps all the similar functions together. Which to me makes the issue that most of the code in os_support should probably not be in an avformat specific header and in fact should be moved. So for simplicity I added it to the existing code, but if it is decided that this os specific header should be moved to a more central location then Ill write up a second patch after this one get applied that will move all the shared code from os_support (as opposed to putting this patches code in a different location and ending up with similar code spread out in different locations throughout the code base). On 30 August 2016 at 02:26, Jean-Baptiste Kempf wrote: > On 28 Aug, Matt Oliver wrote : > > The dlopen function is modified to prevent loading dll's from the current > > directory for improved program security for library users. This extends > > similar functionality from the recently applied SetDllDirectory patch > > except that it adds additional security for library users as well (as > > opposed to just program users). > > Why allowing it to open the local folder? > > Said differently, what are you allowing to open, and why? So this is for opening of dynamic link libraries which under normal circumstances the function to load a dll will search multiple different directories in order to find the requested dll. This patch is a result of a discussion on the ffmpeg-security mailing list about the ability for hackers to create a fake dll that gets picked during the dll search and loaded instead. So this patch adds code to limit the search for a dll to the applications install directory and the system directory only. Initially I was just going to limit it to the system folder (which would be the most secure) but others requested the application directory also be included as they use that functionality during testing by adding their own test versions of dlls to the application dir. Also given that although the application dir may be less secure but if someone can modify dlls in that folder then they can modify the application itself anyway so allowing it doesnt really make things any worse. So the main thing is that this patch limits where dll's can be loaded from to limit the ability for someone to inject insecure code into a program. It does this by limiting the standard searched locations to just a subset that only includes the application directory (searched first in case the app requires specific version of dlls that differ from the system version) and then the system directory. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
