Re: [FFmpeg-devel] [PATCH]lavf/http: Add httpproxy to the default protocol whitelist
On Sunday 13 March 2016 08:56:22 am Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch may fix an issue reported on the user mailing list.
Second try attached.
Please review, Carl Eugen
diff --git a/libavformat/http.c b/libavformat/http.c
index f18d9e2..814ca01 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1522,7 +1522,7 @@ const URLProtocol ff_http_protocol = {
.priv_data_size = sizeof(HTTPContext),
.priv_data_class = &http_context_class,
.flags = URL_PROTOCOL_FLAG_NETWORK,
-.default_whitelist = "http,https,tls,rtp,tcp,udp,crypto"
+.default_whitelist = "http,https,tls,rtp,tcp,udp,crypto,httpproxy"
};
#endif /* CONFIG_HTTP_PROTOCOL */
@@ -1541,7 +1541,7 @@ const URLProtocol ff_https_protocol = {
.priv_data_size = sizeof(HTTPContext),
.priv_data_class = &https_context_class,
.flags = URL_PROTOCOL_FLAG_NETWORK,
-.default_whitelist = "http,https,tls,rtp,tcp,udp,crypto"
+.default_whitelist = "http,https,tls,rtp,tcp,udp,crypto,httpproxy"
};
#endif /* CONFIG_HTTPS_PROTOCOL */
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2 v2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks
I hope this one is an acceptable compromise. Original description follows:
From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"biSize: Specifies the number of bytes required by the structure. This
value does not include the size of the color table or the size of the
color masks, if they are appended to the end of structure."
So, biSize is 40 for palettized video as well. And Windows Media Player
won't display any video when using Microsoft Video 1 in 8 bpp mode or
RLE4/RLE8 if this value is set to anything else than 40.
Regarding the biClrUsed field, I'm setting it to 1 <<
bits_per_coded_sample if palettized video, since setting it to 0 won't
work with Windows Media Player and AVI files with xxpc (palette change)
chunks for some reason.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 1abbf6d514963e94578160fabc829d8bdd6d72c0 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 13 Mar 2016 08:59:22 +0100
Subject: [PATCH 1/2 v2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks
---
libavformat/riffenc.c | 12 ++--
tests/ref/lavf-fate/avi_cram|2 +-
tests/ref/vsynth/vsynth1-bpp1 |2 +-
tests/ref/vsynth/vsynth2-bpp1 |2 +-
tests/ref/vsynth/vsynth3-bpp1 |2 +-
tests/ref/vsynth/vsynth_lena-bpp1 |2 +-
tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420 |4
7 files changed, 11 insertions(+), 15 deletions(-)
delete mode 100644 tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 195a58e..33879ea 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -219,11 +219,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
pix_fmt == AV_PIX_FMT_MONOWHITE ||
pix_fmt == AV_PIX_FMT_MONOBLACK);
-if (!enc->extradata_size && pal_avi)
-extradata_size = 4 * (1 << enc->bits_per_coded_sample);
-
-/* size */
-avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
+/* Size (not including the size of the color table or color masks) */
+avio_wl32(pb, 40 + (ignore_extradata || pal_avi ? 0 : extradata_size));
avio_wl32(pb, enc->width);
//We always store RGB TopDown
avio_wl32(pb, enc->codec_tag || keep_height ? enc->height : -enc->height);
@@ -236,7 +233,10 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
avio_wl32(pb, (enc->width * enc->height * (enc->bits_per_coded_sample ? enc->bits_per_coded_sample : 24)+7) / 8);
avio_wl32(pb, 0);
avio_wl32(pb, 0);
-avio_wl32(pb, 0);
+/* Number of color indices in the color table that are used.
+ * A value of 0 means 2^biBitCount indices, but this doesn't work
+ * with Windows Media Player and files containing xxpc chunks. */
+avio_wl32(pb, pal_avi ? 1 << enc->bits_per_coded_sample : 0);
avio_wl32(pb, 0);
if (!ignore_extradata) {
diff --git a/tests/ref/lavf-fate/avi_cram b/tests/ref/lavf-fate/avi_cram
index 7864ab9..7b4e69c 100644
--- a/tests/ref/lavf-fate/avi_cram
+++ b/tests/ref/lavf-fate/avi_cram
@@ -1,3 +1,3 @@
-e202447ccd6660149c17070204d258a4 *./tests/data/lavf-fate/lavf.avi
+ba77c5c8bd2b0d1e0478d143346cc3b3 *./tests/data/lavf-fate/lavf.avi
928228 ./tests/data/lavf-fate/lavf.avi
./tests/data/lavf-fate/lavf.avi CRC=0xa4770de2
diff --git a/tests/ref/vsynth/vsynth1-bpp1 b/tests/ref/vsynth/vsynth1-bpp1
index 92d5987..af1fb0e 100644
--- a/tests/ref/vsynth/vsynth1-bpp1
+++ b/tests/ref/vsynth/vsynth1-bpp1
@@ -1,4 +1,4 @@
-0fcba876d3e499c0bebf7bb32a7f83f2 *tests/data/fate/vsynth1-bpp1.avi
+a0b35707a9aa7144e3e1c70c1d01f4ce *tests/data/fate/vsynth1-bpp1.avi
640460 tests/data/fate/vsynth1-bpp1.avi
cd1e1448d9895561347ceb66d0add34d *tests/data/fate/vsynth1-bpp1.out.rawvideo
stddev: 84.48 PSNR: 9.60 MAXDIFF: 218 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth2-bpp1 b/tests/ref/vsynth/vsynth2-bpp1
index 2a2a63e..4005755 100644
--- a/tests/ref/vsynth/vsynth2-bpp1
+++ b/tests/ref/vsynth/vsynth2-bpp1
@@ -1,4 +1,4 @@
-af7eae5293b820493d1f4e6d258d8da0 *tests/data/fate/vsynth2-bpp1.avi
+a0330430d7dbd76cbd6d099b778397e8 *tests/data/fate/vsynth2-bpp1.avi
640460 tests/data/fate/vsynth2-bpp1.avi
f0dfc0e87e5d96bce29a5944b1bd7471 *tests/data/fate/vsynth2-bpp1.out.rawvideo
stddev: 68.98 PSNR: 11.36 MAXDIFF: 218 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth3-bpp1 b/tests/ref/vsynth/vsynth3-bpp1
index b3b757c..3c8c47a 100644
--- a/tests/ref/vsynth/vsynth3-bpp1
+++ b/tests/ref/vsynth/vsynth3-bpp1
@@ -1,4 +1,4 @@
-01b0fbf35305b50b1c148c0a23f2cff4 *tests/data/fate/vsynth3-bpp1.avi
+4c8777a88a9e52b99d5a345acffcbf06 *tests/data/fate/vsynth3-bpp1.avi
20460 tests/data/fate/vsynth3-bpp1.avi
52ae74ef7910e5b603c12288d425b9ae *tests/data/fate/vsynth3-bpp1.out.rawvideo
stddev: 84.76 PSNR: 9.57 MA
[FFmpeg-devel] [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index
Reposting it.
Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks being indexed.
Fixing the logic for reading and seeking with xxpc chunks in the demuxer
is a future task. Now the muxing of video with xxpc chunks works
properly at least.
Try playing the resulting test.avi file from the command line below with
Windows Media Player, with and without this patch.
ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From dde62d49f69c0685eb3fe704ec58d45017be64a2 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sat, 12 Mar 2016 16:18:36 +0100
Subject: [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index
---
libavformat/avi.h|6 ++-
libavformat/avienc.c | 100 --
tests/ref/lavf-fate/avi_cram |4 +-
3 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/libavformat/avi.h b/libavformat/avi.h
index 34da76f..af21f2c 100644
--- a/libavformat/avi.h
+++ b/libavformat/avi.h
@@ -32,7 +32,11 @@
#define AVI_MASTER_INDEX_SIZE 256
#define AVI_MAX_STREAM_COUNT100
+/* stream header flags */
+#define AVISF_VIDEO_PALCHANGES 0x0001
+
/* index flags */
-#define AVIIF_INDEX 0x10
+#define AVIIF_INDEX 0x0010
+#define AVIIF_NO_TIME 0x0100
#endif /* AVFORMAT_AVI_H */
diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ad50379..b48fa9c 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -44,13 +44,14 @@
*/
typedef struct AVIIentry {
-unsigned int flags, pos, len;
+char tag[4];
+unsigned int flags;
+unsigned int pos;
+unsigned int len;
} AVIIentry;
#define AVI_INDEX_CLUSTER_SIZE 16384
-#define AVISF_VIDEO_PALCHANGES 0x0001
-
typedef struct AVIIndex {
int64_t indx_start;
int64_t audio_strm_offset;
@@ -96,6 +97,43 @@ static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
return &idx->cluster[cl][id];
}
+static int avi_add_ientry(AVFormatContext *s, int stream_index, char *tag,
+ unsigned int flags, unsigned int size)
+{
+AVIContext *avi = s->priv_data;
+AVIOContext *pb = s->pb;
+AVIStream *avist = s->streams[stream_index]->priv_data;
+AVIIndex *idx= &avist->indexes;
+int cl = idx->entry / AVI_INDEX_CLUSTER_SIZE;
+int id = idx->entry % AVI_INDEX_CLUSTER_SIZE;
+
+if (idx->ents_allocated <= idx->entry) {
+idx->cluster = av_realloc_f(idx->cluster, sizeof(void*), cl+1);
+if (!idx->cluster) {
+idx->ents_allocated = 0;
+idx->entry = 0;
+return AVERROR(ENOMEM);
+}
+idx->cluster[cl] =
+av_malloc(AVI_INDEX_CLUSTER_SIZE * sizeof(AVIIentry));
+if (!idx->cluster[cl])
+return AVERROR(ENOMEM);
+idx->ents_allocated += AVI_INDEX_CLUSTER_SIZE;
+}
+
+if (tag)
+memcpy(idx->cluster[cl][id].tag, tag, 4);
+else
+*(idx->cluster[cl][id].tag) = '\0';
+idx->cluster[cl][id].flags = flags;
+idx->cluster[cl][id].pos = avio_tell(pb) - avi->movi_list;
+idx->cluster[cl][id].len = size;
+avist->max_size = FFMAX(avist->max_size, size);
+idx->entry++;
+
+return 0;
+}
+
static int64_t avi_start_new_riff(AVFormatContext *s, AVIOContext *pb,
const char *riff_tag, const char *list_tag)
{
@@ -612,9 +650,13 @@ static int avi_write_idx1(AVFormatContext *s)
}
if (!empty) {
avist = s->streams[stream_id]->priv_data;
-avi_stream2fourcc(tag, stream_id,
+if (*ie->tag)
+ffio_wfourcc(pb, ie->tag);
+else {
+avi_stream2fourcc(tag, stream_id,
s->streams[stream_id]->codec->codec_type);
-ffio_wfourcc(pb, tag);
+ffio_wfourcc(pb, tag);
+}
avio_wl32(pb, ie->flags);
avio_wl32(pb, ie->pos);
avio_wl32(pb, ie->len);
@@ -654,6 +696,7 @@ static int write_skip_frames(AVFormatContext *s, int stream_index, int64_t dts)
return 0;
}
+
static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
{
const int stream_index = pkt->stream_index;
@@ -709,6 +752,20 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
unsigned char tag[5];
avi_stream2fourcc(tag, stream_index, enc->codec_type);
tag[2] = 'p'; tag[3] = 'c';
+if (s->pb->seekable) {
+int ret;
+if (avist->strh_flags_offset) {
+int64_t cur_offset = avio_tell(pb);
+avio_seek(pb, avist->strh_flags_offset, SEEK_SET);
+
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
Le quartidi 24 ventôse, an CCXXIV, Thilo Borgmann a écrit :
> +static const AVOption coreimage_options[] = {
> +{ "list_filters", "list available filters", OFFSET(list_filters),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = FLAGS, "list_filters" },
> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, FLAGS,
> "list_filters" },
> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS,
> "list_filters" },
AV_OPT_TYPE_BOOL?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/hevc: Support GBR encoding and decoding
Hendrik Leppkes gmail.com> writes: > > Encoder and decoder patches should be separated, they are quite > > distinct code other then being related by codec, otherwise its > > probably fine. > > > > Actually some further comments: All comments applied and changes pushed. Thank you for the review, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
Am 13.03.16 um 09:41 schrieb Nicolas George:
> Le quartidi 24 ventôse, an CCXXIV, Thilo Borgmann a écrit :
>> +static const AVOption coreimage_options[] = {
>> +{ "list_filters", "list available filters", OFFSET(list_filters),
>> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = FLAGS, "list_filters" },
>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, FLAGS,
>> "list_filters" },
>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS,
>> "list_filters" },
>
> AV_OPT_TYPE_BOOL?
Changed locally.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix default display window offset for yuv422 and yuv444
Hi!
Attached patch fixes the default display window for cropped hevc and
pix_fmt != yuv420.
Tested with x265 --crop-rect and FFmpeg -apply_defdispwin.
Please review, Carl Eugen
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index a36c6ee..ce3f3df 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -596,11 +596,12 @@ static void decode_vui(GetBitContext *gb, AVCodecContext
*avctx,
memcpy(&backup, gb, sizeof(backup));
if (vui->default_display_window_flag) {
-//TODO: * 2 is only valid for 420
-vui->def_disp_win.left_offset = get_ue_golomb_long(gb) * 2;
-vui->def_disp_win.right_offset = get_ue_golomb_long(gb) * 2;
-vui->def_disp_win.top_offset= get_ue_golomb_long(gb) * 2;
-vui->def_disp_win.bottom_offset = get_ue_golomb_long(gb) * 2;
+int vert_mult = 1 + (sps->chroma_format_idc < 2);
+int horiz_mult = 1 + (sps->chroma_format_idc < 3);
+vui->def_disp_win.left_offset = get_ue_golomb_long(gb) * horiz_mult;
+vui->def_disp_win.right_offset = get_ue_golomb_long(gb) * horiz_mult;
+vui->def_disp_win.top_offset= get_ue_golomb_long(gb) * vert_mult;
+vui->def_disp_win.bottom_offset = get_ue_golomb_long(gb) * vert_mult;
if (apply_defdispwin &&
avctx->flags2 & AV_CODEC_FLAG2_IGNORE_CROP) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] ffmpeg: set tty mode and signals after parsing options.
Signed-off-by: Nicolas George --- ffmpeg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) It seems more logical, and the next patch does not work without. diff --git a/ffmpeg.c b/ffmpeg.c index 9a14294..1887946 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -4306,8 +4306,6 @@ int main(int argc, char **argv) show_banner(argc, argv, options); -term_init(); - /* parse options and open all input/output files */ ret = ffmpeg_parse_options(argc, argv); if (ret < 0) @@ -4330,6 +4328,8 @@ int main(int argc, char **argv) // exit_program(1); // } +term_init(); + current_time = ti = getutime(); if (transcode() < 0) exit_program(1); -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] ffmpeg: do not catch SIGQUIT.
SIGQUIT is meant for debugging purposes. A signal handler will corrupt stack traces and make everything more complicated. Signed-off-by: Nicolas George --- ffmpeg.c | 1 - 1 file changed, 1 deletion(-) diff --git a/ffmpeg.c b/ffmpeg.c index 45a22fa..f0e4966 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -383,7 +383,6 @@ void term_init(void) tcsetattr (0, TCSANOW, &tty); } -signal(SIGQUIT, sigterm_handler); /* Quit (POSIX). */ } #endif -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] ffmpeg: do not set tty mode if interaction is disabled.
Fix SIGTTOU when used in background with -nostdin but no
---
ffmpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 1887946..45a22fa 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -366,7 +366,7 @@ static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
void term_init(void)
{
#if HAVE_TERMIOS_H
-if(!run_as_daemon){
+if(stdin_interaction && !run_as_daemon){
struct termios tty;
if (tcgetattr (0, &tty) == 0) {
oldtty = tty;
--
2.7.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix default display window offset for yuv422 and yuv444
Hi, On Sun, Mar 13, 2016 at 5:36 AM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes the default display window for cropped hevc and > pix_fmt != yuv420. > Tested with x265 --crop-rect and FFmpeg -apply_defdispwin. > lgtm. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
Hi,
On Sat, Mar 12, 2016 at 11:40 AM, Ganesh Ajjanagadde
wrote:
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index da76ca2..aa43754 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -315,6 +315,22 @@ static av_always_inline float ff_exp10f(float x)
> }
>
> /**
> + * Compute x^y for floating point x, y. Note: this function is faster
> than the
> + * libm variant due to mainly 2 reasons:
> + * 1. It does not handle any edge cases. In particular, this is only
> guaranteed
> + * to work correctly for x > 0.
> + * 2. It is not as accurate as a standard nearly "correctly rounded" libm
> variant.
> + * @param x base
> + * @param y exponent
> + * @return x^y
> + */
> +static av_always_inline float ff_fast_pow(float x, float y)
> +{
> +return expf(logf(x) * y);
> +}
Thanks, mostly OK. Small comments:
- I wonder if this should move to a separate file, e.g. it seems more
fitting in mathematics.h or libm.h. internal.h seems like a strange choice.
I don't know which is better, I'd personally probably go for libm.h but I
can see why some people wouldn't like it since it slightly changes the
meaning of that file.
- it should be called ff_fast_powf since it's float-based, not double-based
(compare pow vs. powf)
(I also noticed there are some huge huge huge functions in libm.h that
probably shouldn't be in a header but move to a .c file instead, if anyone
is looking for a cleanup target - e.g. hypoth and erf.)
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2 v2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks
On Sun, Mar 13, 2016 at 09:33:41AM +0100, Mats Peterson wrote: > I hope this one is an acceptable compromise. Original description follows: > > From the Microsoft documentation for BITMAPINFOHEADER at > https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: > > "biSize: Specifies the number of bytes required by the structure. This > value does not include the size of the color table or the size of the > color masks, if they are appended to the end of structure." > > So, biSize is 40 for palettized video as well. And Windows Media > Player won't display any video when using Microsoft Video 1 in 8 bpp > mode or RLE4/RLE8 if this value is set to anything else than 40. > > Regarding the biClrUsed field, I'm setting it to 1 << > bits_per_coded_sample if palettized video, since setting it to 0 > won't work with Windows Media Player and AVI files with xxpc > (palette change) chunks for some reason. > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > b/libavformat/riffenc.c | 12 ++-- > b/tests/ref/lavf-fate/avi_cram |2 +- > b/tests/ref/vsynth/vsynth1-bpp1 |2 +- > b/tests/ref/vsynth/vsynth2-bpp1 |2 +- > b/tests/ref/vsynth/vsynth3-bpp1 |2 +- > b/tests/ref/vsynth/vsynth_lena-bpp1 |2 +- > tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420 |4 > 7 files changed, 11 insertions(+), 15 deletions(-) > cb7685dc61b70066287c456fde23317dd799048d > 0001-lavf-riffenc-Improve-spec-compliance-Fix-WMP-playbac.patch > From 1abbf6d514963e94578160fabc829d8bdd6d72c0 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Sun, 13 Mar 2016 08:59:22 +0100 > Subject: [PATCH 1/2 v2] lavf/riffenc: Improve spec compliance; Fix WMP > playback of AVI with xxpc chunks applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/hevc_ps: Fix default display window offset for yuv422 and yuv444
Ronald S. Bultje gmail.com> writes: > > Attached patch fixes the default display window for cropped > > hevc and pix_fmt != yuv420. > > Tested with x265 --crop-rect and FFmpeg -apply_defdispwin. > > > > lgtm. Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavf/mxfdec: Assume first track if track number is unknown
On Thu, 2016-03-10 at 15:06 +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #5312 here. > The OP claims that the file plays fine with Mainconcept softare, > afaict the track number of the video track in the mxf header > (0x15010800) does not match the track number of the video frames > (0x15010500 == 352388352). Hrm, this sounds suspicious. But I think happens for some other files too, and I guess playing something is better than nothing.. Perhaps we can have it be a bit more stringent with when it applies this hack? Like if there's only a single track /Tomas signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Fix canopus essence element size
On Thu, 2016-03-10 at 15:08 +0100, Carl Eugen Hoyos wrote: > Hi! > > While debugging ticket #5312, I realized that I included the > track number in the Canopus essence element. OK /Tomas signature.asc Description: This is a digitally signed message part ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
On Sat, 12 Mar 2016 15:13:21 +0100
Thilo Borgmann wrote:
> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann
> Date: Sat, 12 Mar 2016 14:52:17 +0100
> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
>
> ---
> libavutil/dict.c | 5 -
> libavutil/dict.h | 5 +++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index 8bb65a1..70c0184 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, const
> char *value,
> int flags)
> {
> AVDictionary *m = *pm;
> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
> +AVDictionaryEntry *tag = NULL;
> char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>
> +if (!(flags & AV_DICT_MULTIKEY)) {
> +tag = av_dict_get(m, key, NULL, flags);
> +}
> if (flags & AV_DICT_DONT_STRDUP_KEY)
> copy_key = (void *)key;
> else
> diff --git a/libavutil/dict.h b/libavutil/dict.h
> index b0aa784..c589bcd 100644
> --- a/libavutil/dict.h
> +++ b/libavutil/dict.h
> @@ -76,6 +76,7 @@
> #define AV_DICT_DONT_OVERWRITE 16 ///< Don't overwrite existing entries.
> #define AV_DICT_APPEND 32 /**< If the entry already exists, append
> to it. Note that no
>delimiter is added, the strings are
> simply concatenated. */
> +#define AV_DICT_MULTIKEY 64 /**< Allow to store several equal keys
> in the dictionary */
>
> typedef struct AVDictionaryEntry {
> char *key;
> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
> *
> * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
> * a dictionary struct is allocated and put in *pm.
> - * @param key entry key to add to *pm (will be av_strduped depending on
> flags)
> - * @param value entry value to add to *pm (will be av_strduped depending on
> flags).
> + * @param key entry key to add to *pm (will either be av_strduped or added
> as a new key depending on flags)
> + * @param value entry value to add to *pm (will be av_strduped or added as a
> new key depending on flags).
> *Passing a NULL value will cause an existing entry to be deleted.
> * @return >= 0 on success otherwise an error code <0
> */
Changing the semantics of AVDictionary just like this seems rather
questionable...
Are you sure you don't want a list instead?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2 v2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks
On 03/13/2016 01:11 PM, Michael Niedermayer wrote: On Sun, Mar 13, 2016 at 09:33:41AM +0100, Mats Peterson wrote: I hope this one is an acceptable compromise. Original description follows: From the Microsoft documentation for BITMAPINFOHEADER at https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx: "biSize: Specifies the number of bytes required by the structure. This value does not include the size of the color table or the size of the color masks, if they are appended to the end of structure." So, biSize is 40 for palettized video as well. And Windows Media Player won't display any video when using Microsoft Video 1 in 8 bpp mode or RLE4/RLE8 if this value is set to anything else than 40. Regarding the biClrUsed field, I'm setting it to 1 << bits_per_coded_sample if palettized video, since setting it to 0 won't work with Windows Media Player and AVI files with xxpc (palette change) chunks for some reason. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ b/libavformat/riffenc.c | 12 ++-- b/tests/ref/lavf-fate/avi_cram |2 +- b/tests/ref/vsynth/vsynth1-bpp1 |2 +- b/tests/ref/vsynth/vsynth2-bpp1 |2 +- b/tests/ref/vsynth/vsynth3-bpp1 |2 +- b/tests/ref/vsynth/vsynth_lena-bpp1 |2 +- tests/ref/vsynth/vsynth_lena-ffv1-v3-yuv420 |4 7 files changed, 11 insertions(+), 15 deletions(-) cb7685dc61b70066287c456fde23317dd799048d 0001-lavf-riffenc-Improve-spec-compliance-Fix-WMP-playbac.patch From 1abbf6d514963e94578160fabc829d8bdd6d72c0 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 13 Mar 2016 08:59:22 +0100 Subject: [PATCH 1/2 v2] lavf/riffenc: Improve spec compliance; Fix WMP playback of AVI with xxpc chunks applied thanks [...] Thanks, Michael. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index
On 03/13/2016 09:34 AM, Mats Peterson wrote: Reposting it. Here's an interesting one. Windows Media Player won't make any palette changes without the xxpc chunks being indexed. Fixing the logic for reading and seeking with xxpc chunks in the demuxer is a future task. Now the muxing of video with xxpc chunks works properly at least. Try playing the resulting test.avi file from the command line below with Windows Media Player, with and without this patch. ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Any questions about this one? -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC]lavf/mxfdec: Assume first track if track number is unknown
Tomas Härdin codemill.se> writes: > On Thu, 2016-03-10 at 15:06 +0100, Carl Eugen Hoyos wrote: > > > > Attached patch fixes ticket #5312 here. > > The OP claims that the file plays fine with Mainconcept software, > > afaict the track number of the video track in the mxf header > > (0x15010800) does not match the track number of the video frames > > (0x15010500 == 352388352). > > Hrm, this sounds suspicious. But I think happens for some other > files too, and I guess playing something is better than nothing.. > Perhaps we can have it be a bit more stringent with when it > applies this hack? > Like if there's only a single track The file in question has several tracks, see the console output in ticket #5312. The demuxer already accepts any track number for single-track files. I was hoping you could have a look at the sample in http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5312/ I hope I missed something... Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index
On Sun, Mar 13, 2016 at 09:34:41AM +0100, Mats Peterson wrote: > Reposting it. > > Here's an interesting one. Windows Media Player won't make any palette > changes without the xxpc chunks being indexed. > > Fixing the logic for reading and seeking with xxpc chunks in the > demuxer is a future task. Now the muxing of video with xxpc chunks > works properly at least. > > Try playing the resulting test.avi file from the command line below > with Windows Media Player, with and without this patch. > > ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > libavformat/avi.h|6 ++ > libavformat/avienc.c | 100 > --- > tests/ref/lavf-fate/avi_cram |4 - > 3 files changed, 73 insertions(+), 37 deletions(-) > b826d24043234c25613a421b5178762f1b4da973 > 0002-lavf-avienc-Add-xxpc-entries-to-index.patch > From dde62d49f69c0685eb3fe704ec58d45017be64a2 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Sat, 12 Mar 2016 16:18:36 +0100 > Subject: [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. 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 v3] lavf/avienc: Add xxpc entries to index
On 03/13/2016 04:04 PM, Michael Niedermayer wrote: On Sun, Mar 13, 2016 at 09:34:41AM +0100, Mats Peterson wrote: Reposting it. Here's an interesting one. Windows Media Player won't make any palette changes without the xxpc chunks being indexed. Fixing the logic for reading and seeking with xxpc chunks in the demuxer is a future task. Now the muxing of video with xxpc chunks works properly at least. Try playing the resulting test.avi file from the command line below with Windows Media Player, with and without this patch. ffmpeg -i TOON.AVI -c:v copy -c:a copy test.avi Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ libavformat/avi.h|6 ++ libavformat/avienc.c | 100 --- tests/ref/lavf-fate/avi_cram |4 - 3 files changed, 73 insertions(+), 37 deletions(-) b826d24043234c25613a421b5178762f1b4da973 0002-lavf-avienc-Add-xxpc-entries-to-index.patch From dde62d49f69c0685eb3fe704ec58d45017be64a2 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sat, 12 Mar 2016 16:18:36 +0100 Subject: [PATCH 2/2 v3] lavf/avienc: Add xxpc entries to index applied thanks [...] Thanks. I have a small fix coming, though. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry()
I don't know if this is necessary or relevant, but since you said snow encoding failed, and valgrind reported that the tag was uninitialised, why not clear the whole of it. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From a1d51457e12a488b7ad993a61579cb0ba3bdd9f9 Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Sun, 13 Mar 2016 16:09:45 +0100 Subject: [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry() --- libavformat/avienc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/avienc.c b/libavformat/avienc.c index dceb2ef..7a7abb8 100644 --- a/libavformat/avienc.c +++ b/libavformat/avienc.c @@ -124,7 +124,7 @@ static int avi_add_ientry(AVFormatContext *s, int stream_index, char *tag, if (tag) memcpy(idx->cluster[cl][id].tag, tag, 4); else -*(idx->cluster[cl][id].tag) = '\0'; +memset(idx->cluster[cl][id].tag, 0, 4); idx->cluster[cl][id].flags = flags; idx->cluster[cl][id].pos = avio_tell(pb) - avi->movi_list; idx->cluster[cl][id].len = size; -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/http: Add httpproxy to the default protocol whitelist
On Sun, Mar 13, 2016 at 09:00:32AM +0100, Carl Eugen Hoyos wrote: > On Sunday 13 March 2016 08:56:22 am Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch may fix an issue reported on the user mailing list. > > Second try attached. > > Please review, Carl Eugen probably ok thx PS: also please backport to 3.0 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- 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] lavf/avienc: Clear whole tag in avi_add_ientry()
Mats Peterson skrev: (13 mars 2016 16:11:54 CET) >I don't know if this is necessary or relevant, but since you said snow >encoding failed, and valgrind reported that the tag was uninitialised, >why not clear the whole of it. > >Mats Well, it's not needed, since I only check the first byte, but perhaps it's more elegant. You choose. -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry()
Mats Peterson skrev: (13 mars 2016 16:28:04 CET) >Mats Peterson skrev: (13 mars 2016 >16:11:54 CET) >>I don't know if this is necessary or relevant, but since you said snow > >>encoding failed, and valgrind reported that the tag was uninitialised, > >>why not clear the whole of it. >> >>Mats > >Well, it's not needed, since I only check the first byte, but perhaps >it's more elegant. You choose. >-- >Mats Peterson >http://matsp888.no-ip.org/~mats/ >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel And in this context, it would be nice if you perhaps could look into some logic for switching the palette based on the indexed xxpc chunks in the demuxer avidec.c, Michael. I'm not knowledgeable enough to deal with that. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry()
On Sun, Mar 13, 2016 at 04:11:54PM +0100, Mats Peterson wrote: > I don't know if this is necessary or relevant, but since you said > snow encoding failed, and valgrind reported that the tag was > uninitialised, why not clear the whole of it. > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > avienc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 09d41ec07547e966bc72be90af6949d25317e5c7 > 0001-lavf-avienc-Clear-whole-tag-in-avi_add_ientry.patch > From a1d51457e12a488b7ad993a61579cb0ba3bdd9f9 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Sun, 13 Mar 2016 16:09:45 +0100 > Subject: [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry() applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill hundred thousands of innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry()
Michael Niedermayer skrev: (13 mars 2016 16:45:43 CET) >On Sun, Mar 13, 2016 at 04:11:54PM +0100, Mats Peterson wrote: >> I don't know if this is necessary or relevant, but since you said >> snow encoding failed, and valgrind reported that the tag was >> uninitialised, why not clear the whole of it. >> >> Mats >> >> -- >> Mats Peterson >> http://matsp888.no-ip.org/~mats/ > >> avienc.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> 09d41ec07547e966bc72be90af6949d25317e5c7 >0001-lavf-avienc-Clear-whole-tag-in-avi_add_ientry.patch >> From a1d51457e12a488b7ad993a61579cb0ba3bdd9f9 Mon Sep 17 00:00:00 >2001 >> From: Mats Peterson >> Date: Sun, 13 Mar 2016 16:09:45 +0100 >> Subject: [PATCH] lavf/avienc: Clear whole tag in avi_add_ientry() > >applied > >thx > >[...] Alright, thanks! -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger wrote: > Allows sharing and reusing the data between different files. > > Signed-off-by: Reimar Döffinger > --- > libavcodec/Makefile | 10 +- > libavcodec/aacdec.c | 2 +- > libavcodec/aacdec_fixed.c | 6 +++--- > libavcodec/aacdec_template.c| 4 ++-- > libavcodec/cbrt_data.c | 28 +++ > libavcodec/cbrt_data.h | 38 > + > libavcodec/cbrt_data_fixed.c| 29 > libavcodec/cbrt_tablegen.h | 18 -- > libavcodec/cbrt_tablegen_template.c | 8 ++-- > 9 files changed, 116 insertions(+), 27 deletions(-) > create mode 100644 libavcodec/cbrt_data.c > create mode 100644 libavcodec/cbrt_data.h > create mode 100644 libavcodec/cbrt_data_fixed.c > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index 1cd9572..6bb1af1 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -137,17 +137,17 @@ OBJS-$(CONFIG_A64MULTI_ENCODER)+= a64multienc.o > elbg.o > OBJS-$(CONFIG_A64MULTI5_ENCODER) += a64multienc.o elbg.o > OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o > aacps_float.o \ >aacadtsdec.o mpeg4audio.o kbdwin.o > \ > - sbrdsp.o aacpsdsp_float.o > + sbrdsp.o aacpsdsp_float.o > cbrt_data.o > OBJS-$(CONFIG_AAC_FIXED_DECODER) += aacdec_fixed.o aactab.o > aacsbr_fixed.o aacps_fixed.o \ >aacadtsdec.o mpeg4audio.o kbdwin.o > \ > - sbrdsp_fixed.o aacpsdsp_fixed.o > + sbrdsp_fixed.o aacpsdsp_fixed.o > cbrt_data_fixed.o > OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o aaccoder.o aacenctab.o > \ >aacpsy.o aactab.o \ >aacenc_is.o \ >aacenc_tns.o \ >aacenc_ltp.o \ >aacenc_pred.o \ > - psymodel.o mpeg4audio.o kbdwin.o > + psymodel.o mpeg4audio.o kbdwin.o > cbrt_data.o > OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o > OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o ac3.o > kbdwin.o > OBJS-$(CONFIG_AC3_FIXED_DECODER) += ac3dec_fixed.o ac3dec_data.o ac3.o > kbdwin.o > @@ -1017,8 +1017,8 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h: > $(SUBDIR)%_tablegen$(HOSTEXESUF) > $(M)./$< > $@ > > ifdef CONFIG_HARDCODED_TABLES > -$(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h > -$(SUBDIR)aacdec_fixed.o: $(SUBDIR)cbrt_fixed_tables.h > +$(SUBDIR)cbrt_data.o: $(SUBDIR)cbrt_tables.h > +$(SUBDIR)cbrt_data_fixed.o: $(SUBDIR)cbrt_fixed_tables.h > $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h > $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h > $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h > diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c > index 26bdea1..ee9b4eb 100644 > --- a/libavcodec/aacdec.c > +++ b/libavcodec/aacdec.c > @@ -50,7 +50,7 @@ > #include "aac.h" > #include "aactab.h" > #include "aacdectab.h" > -#include "cbrt_tablegen.h" > +#include "cbrt_data.h" > #include "sbr.h" > #include "aacsbr.h" > #include "mpeg4audio.h" > diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c > index 396a874..acb8178 100644 > --- a/libavcodec/aacdec_fixed.c > +++ b/libavcodec/aacdec_fixed.c > @@ -75,7 +75,7 @@ > #include "aac.h" > #include "aactab.h" > #include "aacdectab.h" > -#include "cbrt_tablegen.h" > +#include "cbrt_data.h" > #include "sbr.h" > #include "aacsbr.h" > #include "mpeg4audio.h" > @@ -155,9 +155,9 @@ static void vector_pow43(int *coefs, int len) > for (i=0; i coef = coefs[i]; > if (coef < 0) > -coef = -(int)cbrt_tab[-coef]; > +coef = -(int)ff_cbrt_tab_fixed[-coef]; > else > -coef = (int)cbrt_tab[coef]; > +coef = (int)ff_cbrt_tab_fixed[coef]; > coefs[i] = coef; > } > } > diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c > index 6bc94c8..883ed52 100644 > --- a/libavcodec/aacdec_template.c > +++ b/libavcodec/aacdec_template.c > @@ -1104,7 +1104,7 @@ static av_cold void aac_static_table_init(void) > AAC_RENAME(ff_init_ff_sine_windows)( 9); > AAC_RENAME(ff_init_ff_sine_windows)( 7); > > -AAC_RENAME(cbrt_tableinit)(); > +AAC_RENAME(ff_cbrt_tableinit)(); > } > > static AVOnce aac_table_init = AV_ONCE_INIT; > @@ -1795,7 +1795,7 @@ static int decode_spectrum_and_dequant(AACContext *ac, > INTFLOAT coef[1024], >
Re: [FFmpeg-devel] [PATCHv2] lavc/aacenc_utils: replace powf(x, y) by expf(logf(x), y)
On Sun, Mar 13, 2016 at 7:51 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Mar 12, 2016 at 11:40 AM, Ganesh Ajjanagadde
> wrote:
>>
>> diff --git a/libavutil/internal.h b/libavutil/internal.h
>> index da76ca2..aa43754 100644
>> --- a/libavutil/internal.h
>> +++ b/libavutil/internal.h
>> @@ -315,6 +315,22 @@ static av_always_inline float ff_exp10f(float x)
>> }
>>
>> /**
>> + * Compute x^y for floating point x, y. Note: this function is faster
>> than the
>> + * libm variant due to mainly 2 reasons:
>> + * 1. It does not handle any edge cases. In particular, this is only
>> guaranteed
>> + * to work correctly for x > 0.
>> + * 2. It is not as accurate as a standard nearly "correctly rounded" libm
>> variant.
>> + * @param x base
>> + * @param y exponent
>> + * @return x^y
>> + */
>> +static av_always_inline float ff_fast_pow(float x, float y)
>> +{
>> +return expf(logf(x) * y);
>> +}
>
>
> Thanks, mostly OK. Small comments:
>
> - I wonder if this should move to a separate file, e.g. it seems more
> fitting in mathematics.h or libm.h. internal.h seems like a strange choice.
> I don't know which is better, I'd personally probably go for libm.h but I
> can see why some people wouldn't like it since it slightly changes the
> meaning of that file.
I don't like moving it to libm either for this reason.
I chose lavu/internal for 2 reasons:
1. simply to group with other similar things, (ff_exp10, ff_exp10f)
that also went into lavu/internal.
2. more fundamentally, it appears lavu/mathematics.h is a public
header. I am quite strongly against making ff_exp10, ff_fast_powf etc
public.
> - it should be called ff_fast_powf since it's float-based, not double-based
> (compare pow vs. powf)
Oops, changed.
>
> (I also noticed there are some huge huge huge functions in libm.h that
> probably shouldn't be in a header but move to a .c file instead, if anyone
> is looking for a cleanup target - e.g. hypoth and erf.)
Although I would like to do it myself, I won't simply because I can't
test effectively as I lack a broken libm. Note that lavu/libm is not
just bloated but also broken in other ways as well; recall discussion
on how some of the things there should not really be macros but
functions.
>
> Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 1/2] lavu/lfg-test: add simple sample mean, stddev checks
On Sat, Mar 12, 2016 at 11:01 AM, Michael Niedermayer wrote: > On Sat, Mar 12, 2016 at 08:58:40AM -0500, Ganesh Ajjanagadde wrote: >> Also added a TODO to change to a proper normality test in the future. >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavutil/lfg.c | 20 ++-- >> 1 file changed, 18 insertions(+), 2 deletions(-) > > LGTM > > thx pushed, thanks - note 2/2 v3 still needs review > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > > ___ > 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] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 5:24 PM, Ganesh Ajjanagadde wrote: > On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger > wrote: >> Allows sharing and reusing the data between different files. >> >> Signed-off-by: Reimar Döffinger >> --- >> libavcodec/Makefile | 10 +- >> libavcodec/aacdec.c | 2 +- >> libavcodec/aacdec_fixed.c | 6 +++--- >> libavcodec/aacdec_template.c| 4 ++-- >> libavcodec/cbrt_data.c | 28 +++ >> libavcodec/cbrt_data.h | 38 >> + >> libavcodec/cbrt_data_fixed.c| 29 >> libavcodec/cbrt_tablegen.h | 18 -- >> libavcodec/cbrt_tablegen_template.c | 8 ++-- >> 9 files changed, 116 insertions(+), 27 deletions(-) >> create mode 100644 libavcodec/cbrt_data.c >> create mode 100644 libavcodec/cbrt_data.h >> create mode 100644 libavcodec/cbrt_data_fixed.c >> >> diff --git a/libavcodec/Makefile b/libavcodec/Makefile >> index 1cd9572..6bb1af1 100644 >> --- a/libavcodec/Makefile >> +++ b/libavcodec/Makefile >> @@ -137,17 +137,17 @@ OBJS-$(CONFIG_A64MULTI_ENCODER)+= >> a64multienc.o elbg.o >> OBJS-$(CONFIG_A64MULTI5_ENCODER) += a64multienc.o elbg.o >> OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o >> aacps_float.o \ >>aacadtsdec.o mpeg4audio.o >> kbdwin.o \ >> - sbrdsp.o aacpsdsp_float.o >> + sbrdsp.o aacpsdsp_float.o >> cbrt_data.o >> OBJS-$(CONFIG_AAC_FIXED_DECODER) += aacdec_fixed.o aactab.o >> aacsbr_fixed.o aacps_fixed.o \ >>aacadtsdec.o mpeg4audio.o >> kbdwin.o \ >> - sbrdsp_fixed.o aacpsdsp_fixed.o >> + sbrdsp_fixed.o aacpsdsp_fixed.o >> cbrt_data_fixed.o >> OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o aaccoder.o aacenctab.o >> \ >>aacpsy.o aactab.o \ >>aacenc_is.o \ >>aacenc_tns.o \ >>aacenc_ltp.o \ >>aacenc_pred.o \ >> - psymodel.o mpeg4audio.o kbdwin.o >> + psymodel.o mpeg4audio.o kbdwin.o >> cbrt_data.o >> OBJS-$(CONFIG_AASC_DECODER)+= aasc.o msrledec.o >> OBJS-$(CONFIG_AC3_DECODER) += ac3dec_float.o ac3dec_data.o >> ac3.o kbdwin.o >> OBJS-$(CONFIG_AC3_FIXED_DECODER) += ac3dec_fixed.o ac3dec_data.o >> ac3.o kbdwin.o >> @@ -1017,8 +1017,8 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h: >> $(SUBDIR)%_tablegen$(HOSTEXESUF) >> $(M)./$< > $@ >> >> ifdef CONFIG_HARDCODED_TABLES >> -$(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h >> -$(SUBDIR)aacdec_fixed.o: $(SUBDIR)cbrt_fixed_tables.h >> +$(SUBDIR)cbrt_data.o: $(SUBDIR)cbrt_tables.h >> +$(SUBDIR)cbrt_data_fixed.o: $(SUBDIR)cbrt_fixed_tables.h >> $(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h >> $(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h >> $(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h >> diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c >> index 26bdea1..ee9b4eb 100644 >> --- a/libavcodec/aacdec.c >> +++ b/libavcodec/aacdec.c >> @@ -50,7 +50,7 @@ >> #include "aac.h" >> #include "aactab.h" >> #include "aacdectab.h" >> -#include "cbrt_tablegen.h" >> +#include "cbrt_data.h" >> #include "sbr.h" >> #include "aacsbr.h" >> #include "mpeg4audio.h" >> diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c >> index 396a874..acb8178 100644 >> --- a/libavcodec/aacdec_fixed.c >> +++ b/libavcodec/aacdec_fixed.c >> @@ -75,7 +75,7 @@ >> #include "aac.h" >> #include "aactab.h" >> #include "aacdectab.h" >> -#include "cbrt_tablegen.h" >> +#include "cbrt_data.h" >> #include "sbr.h" >> #include "aacsbr.h" >> #include "mpeg4audio.h" >> @@ -155,9 +155,9 @@ static void vector_pow43(int *coefs, int len) >> for (i=0; i> coef = coefs[i]; >> if (coef < 0) >> -coef = -(int)cbrt_tab[-coef]; >> +coef = -(int)ff_cbrt_tab_fixed[-coef]; >> else >> -coef = (int)cbrt_tab[coef]; >> +coef = (int)ff_cbrt_tab_fixed[coef]; >> coefs[i] = coef; >> } >> } >> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c >> index 6bc94c8..883ed52 100644 >> --- a/libavcodec/aacdec_template.c >> +++ b/libavcodec/aacdec_template.c >> @@ -1104,7 +1104,7 @@ static av_cold void aac_static_table_init(void) >> AAC_RENAME(ff_init_ff_sine_windows)( 9); >> AAC_RENAME(ff_init_ff_sine_windows)( 7); >> >> -AAC_RENAME(cbrt_tableinit)(); >> +AAC_RENAME(ff_cbrt_tableinit)(); >> } >>
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote: > On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger > wrote: > > for (i = 0; i < 1<<13; i++) > > -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]); > > +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]); > > } > > } > > Note that cbrt_tab_dbl is really intended to be shared by both the > fixed/floating table inits. This was another thing my patch achieved: > only doing the more expensive double table init once across > float/fixed, and then doing the cheap conversion to uint32_t via > av_float2int or lrint(x*8192). Please change; it could go into a > separate patch if you prefer. IMHO you really need to argue why that would be desirable. The only case I can see this as useful is if someone runs at the same time fixed-point AAC decode and AAC encode, where it saves a bit of startup time. In all other cases you waste time and memory initializing a table that will never be used. Also doing that you end up with 3 different things: one that should only be compiled in when there is fixed-point stuff, one you should only have for float, and one that is needed if either is enabled. As a result, you'd probably need a 3rd file (or some #ifdef mess that duplicates stuff in the Makefile). Though I admit once you have a single init function it becomes easier to put it all in one file. It still will be quite ugly ifdefs though. That you tried to cram three (mostly unrelated) changes in one patch definitely explains a good part of the problems. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 05:50:17PM +0100, Hendrik Leppkes wrote: > On Sun, Mar 13, 2016 at 5:24 PM, Ganesh Ajjanagadde > wrote: > >> @@ -75,9 +66,8 @@ static av_cold void AAC_RENAME(cbrt_tableinit)(void) > >> } > >> > >> for (i = 0; i < 1<<13; i++) > >> -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]); > >> +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]); > >> } > >> } > > > > Note that cbrt_tab_dbl is really intended to be shared by both the > > fixed/floating table inits. This was another thing my patch achieved: > > only doing the more expensive double table init once across > > float/fixed, and then doing the cheap conversion to uint32_t via > > av_float2int or lrint(x*8192). Please change; it could go into a > > separate patch if you prefer. > > > > Having both float and fixed decoders used at the same time seems like > a rather unlikely use-case, so if such an optimization takes rather > high complexity, its probably not worth going, IMHO. Nah, it should be done separately because it needs some code reshuffling that easily gets confusing, but I don't think it will be hard. I don't think it's a good idea though (well, it would be somewhat nice to share the function to reduce code size, but that is a kind of questionable benefit as well, if you care about code size why do you build in both fixed and float decoder in the first place?). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 12:49 PM, Reimar Döffinger wrote: > On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote: >> On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger >> wrote: >> > for (i = 0; i < 1<<13; i++) >> > -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]); >> > +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]); >> > } >> > } >> >> Note that cbrt_tab_dbl is really intended to be shared by both the >> fixed/floating table inits. This was another thing my patch achieved: >> only doing the more expensive double table init once across >> float/fixed, and then doing the cheap conversion to uint32_t via >> av_float2int or lrint(x*8192). Please change; it could go into a >> separate patch if you prefer. > > IMHO you really need to argue why that would be desirable. > The only case I can see this as useful is if someone > runs at the same time fixed-point AAC decode and AAC encode, > where it saves a bit of startup time. > In all other cases you waste time and memory initializing > a table that will never be used. I don't understand the waste; the double init anyway needs to be done, all tables are derived from it. This dates to an approach I did in commit: 07a11ebcab9b31e9fc784029e5d24e6fbf486ff3. > Also doing that you end up with 3 different things: > one that should only be compiled in when there is fixed-point > stuff, one you should only have for float, and one that is > needed if either is enabled. > As a result, you'd probably need a 3rd file (or some #ifdef > mess that duplicates stuff in the Makefile). > Though I admit once you have a single init function it becomes > easier to put it all in one file. It still will be quite ugly > ifdefs though. I had no fancy ifdefs for this, just some Makefile magic. > That you tried to cram three (mostly unrelated) changes in one > patch definitely explains a good part of the problems. That is a very fair assessment. Remarks dropped, patch tested and LGTM. Thanks. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 05:53:10PM +0100, Reimar Döffinger wrote:
> On Sun, Mar 13, 2016 at 05:50:17PM +0100, Hendrik Leppkes wrote:
> > On Sun, Mar 13, 2016 at 5:24 PM, Ganesh Ajjanagadde
> > wrote:
> > >> @@ -75,9 +66,8 @@ static av_cold void AAC_RENAME(cbrt_tableinit)(void)
> > >> }
> > >>
> > >> for (i = 0; i < 1<<13; i++)
> > >> -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]);
> > >> +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]);
> > >> }
> > >> }
> > >
> > > Note that cbrt_tab_dbl is really intended to be shared by both the
> > > fixed/floating table inits. This was another thing my patch achieved:
> > > only doing the more expensive double table init once across
> > > float/fixed, and then doing the cheap conversion to uint32_t via
> > > av_float2int or lrint(x*8192). Please change; it could go into a
> > > separate patch if you prefer.
> > >
> >
> > Having both float and fixed decoders used at the same time seems like
> > a rather unlikely use-case, so if such an optimization takes rather
> > high complexity, its probably not worth going, IMHO.
>
> Nah, it should be done separately because it needs some
> code reshuffling that easily gets confusing, but I don't
> think it will be hard.
Wasn't (though I haven't tested properly), see attached,
still don't think it is a good idea though.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6bb1af1..ec46d22 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -140,7 +140,7 @@ OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o aacps_float
sbrdsp.o aacpsdsp_float.o cbrt_data.o
OBJS-$(CONFIG_AAC_FIXED_DECODER) += aacdec_fixed.o aactab.o aacsbr_fixed.o aacps_fixed.o \
aacadtsdec.o mpeg4audio.o kbdwin.o \
- sbrdsp_fixed.o aacpsdsp_fixed.o cbrt_data_fixed.o
+ sbrdsp_fixed.o aacpsdsp_fixed.o cbrt_data.o
OBJS-$(CONFIG_AAC_ENCODER) += aacenc.o aaccoder.o aacenctab.o\
aacpsy.o aactab.o \
aacenc_is.o \
@@ -1017,8 +1017,7 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h: $(SUBDIR)%_tablegen$(HOSTEXESUF)
$(M)./$< > $@
ifdef CONFIG_HARDCODED_TABLES
-$(SUBDIR)cbrt_data.o: $(SUBDIR)cbrt_tables.h
-$(SUBDIR)cbrt_data_fixed.o: $(SUBDIR)cbrt_fixed_tables.h
+$(SUBDIR)cbrt_data.o: $(SUBDIR)cbrt_tables.h $(SUBDIR)cbrt_fixed_tables.h
$(SUBDIR)aacps_float.o: $(SUBDIR)aacps_tables.h
$(SUBDIR)aacps_fixed.o: $(SUBDIR)aacps_fixed_tables.h
$(SUBDIR)aactab_fixed.o: $(SUBDIR)aac_fixed_tables.h
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 883ed52..8554149 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -1103,8 +1103,7 @@ static av_cold void aac_static_table_init(void)
AAC_RENAME(ff_init_ff_sine_windows)(10);
AAC_RENAME(ff_init_ff_sine_windows)( 9);
AAC_RENAME(ff_init_ff_sine_windows)( 7);
-
-AAC_RENAME(ff_cbrt_tableinit)();
+ff_cbrt_tableinit();
}
static AVOnce aac_table_init = AV_ONCE_INIT;
diff --git a/libavcodec/cbrt_data.c b/libavcodec/cbrt_data.c
index f5d9778..962fc65 100644
--- a/libavcodec/cbrt_data.c
+++ b/libavcodec/cbrt_data.c
@@ -22,7 +22,12 @@
#include "cbrt_data.h"
#if CONFIG_HARDCODED_TABLES
+#if CONFIG_AAC_DECODER || CONFIG_AAC_ENCODER
#include "libavcodec/cbrt_tables.h"
+#endif
+#if CONFIG_AAC_FIXED_DECODER
+#include "libavcodec/cbrt_fixed_tables.h"
+#endif
#else
#include "cbrt_tablegen.h"
#endif
diff --git a/libavcodec/cbrt_data.h b/libavcodec/cbrt_data.h
index 232f74f..a3da456 100644
--- a/libavcodec/cbrt_data.h
+++ b/libavcodec/cbrt_data.h
@@ -24,13 +24,11 @@
#include
#if CONFIG_HARDCODED_TABLES
-#define ff_cbrt_tableinit_fixed()
#define ff_cbrt_tableinit()
extern const uint32_t ff_cbrt_tab[1 << 13];
extern const uint32_t ff_cbrt_tab_fixed[1 << 13];
#else
void ff_cbrt_tableinit(void);
-void ff_cbrt_tableinit_fixed(void);
extern uint32_t ff_cbrt_tab[1 << 13];
extern uint32_t ff_cbrt_tab_fixed[1 << 13];
#endif
diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
index 9af18d8..328c851 100644
--- a/libavcodec/cbrt_tablegen.h
+++ b/libavcodec/cbrt_tablegen.h
@@ -27,20 +27,22 @@
#include
#include "libavutil/attributes.h"
#include "libavutil/intfloat.h"
-#include "libavcodec/aac_defines.h"
-#if USE_FIXED
-#define CBRT(x) lrint((x) * 8192)
-#else
-#define CBRT(x) av_float2int((float)(x))
+#if CONFIG_AAC_DECODER || CONFIG_AAC_ENCODER
+uint32_t ff_cbrt_tab[1 << 13];
+#endif
+#if CONFIG_AAC_FIXED_DECODER
+uint32_t ff_cbrt_tab_fixed[1 << 13];
#endif
-uint32_t AAC_RENAME(ff_cbrt_tab)[1 << 13];
-
-av_cold void AAC_RENAME(ff_cbrt_tableinit)(void)
+av_cold void ff_cbrt_tableinit(void)
{
static double cbrt_tab_dbl[1 << 13];
-if (!AAC_RENAME(ff_cbrt_tab)[(1<<13) - 1]) {
+#if CON
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 01:12:57PM -0400, Ganesh Ajjanagadde wrote: > On Sun, Mar 13, 2016 at 12:49 PM, Reimar Döffinger > wrote: > > On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote: > >> On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger > >> wrote: > >> > for (i = 0; i < 1<<13; i++) > >> > -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]); > >> > +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]); > >> > } > >> > } > >> > >> Note that cbrt_tab_dbl is really intended to be shared by both the > >> fixed/floating table inits. This was another thing my patch achieved: > >> only doing the more expensive double table init once across > >> float/fixed, and then doing the cheap conversion to uint32_t via > >> av_float2int or lrint(x*8192). Please change; it could go into a > >> separate patch if you prefer. > > > > IMHO you really need to argue why that would be desirable. > > The only case I can see this as useful is if someone > > runs at the same time fixed-point AAC decode and AAC encode, > > where it saves a bit of startup time. > > In all other cases you waste time and memory initializing > > a table that will never be used. > > I don't understand the waste; the double init anyway needs to be done, > all tables are derived from it. This dates to an approach I did in > commit: 07a11ebcab9b31e9fc784029e5d24e6fbf486ff3. The waste is in writing to the table that will never be used. As long as it is left as 0, it will not use memory, as soon as you touch it it uses up memory. But see my patch, if people think it's better it can be added. > I had no fancy ifdefs for this, just some Makefile magic. Because you also always included both tables in the binary, whether used or not (and due to the shared init function the linker could not remove the unused one). I can see that one could argue either way concerning ifdef mess vs. a few kB wasted though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 06:14:18PM +0100, Reimar Döffinger wrote: > On Sun, Mar 13, 2016 at 01:12:57PM -0400, Ganesh Ajjanagadde wrote: > > On Sun, Mar 13, 2016 at 12:49 PM, Reimar Döffinger > > wrote: > > > On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote: > > >> On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger > > >> wrote: > > >> > for (i = 0; i < 1<<13; i++) > > >> > -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]); > > >> > +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]); > > >> > } > > >> > } > > >> > > >> Note that cbrt_tab_dbl is really intended to be shared by both the > > >> fixed/floating table inits. This was another thing my patch achieved: > > >> only doing the more expensive double table init once across > > >> float/fixed, and then doing the cheap conversion to uint32_t via > > >> av_float2int or lrint(x*8192). Please change; it could go into a > > >> separate patch if you prefer. > > > > > > IMHO you really need to argue why that would be desirable. > > > The only case I can see this as useful is if someone > > > runs at the same time fixed-point AAC decode and AAC encode, > > > where it saves a bit of startup time. > > > In all other cases you waste time and memory initializing > > > a table that will never be used. > > > > I don't understand the waste; the double init anyway needs to be done, > > all tables are derived from it. This dates to an approach I did in > > commit: 07a11ebcab9b31e9fc784029e5d24e6fbf486ff3. > > The waste is in writing to the table that will never be used. > As long as it is left as 0, it will not use memory, as soon > as you touch it it uses up memory. > But see my patch, if people think it's better it can be added. And looking at that commit, I actually realize now that the cbrt_tab_dbl will also permanently waste 64 kB of memory despite never being used again. Using malloc/free for it would potentially be better (though in general I have some doubts about the wisdom of optimizing for initialization time at the detriment of runtime performance or memory usage). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 1:21 PM, Reimar Döffinger wrote: > On Sun, Mar 13, 2016 at 06:14:18PM +0100, Reimar Döffinger wrote: >> On Sun, Mar 13, 2016 at 01:12:57PM -0400, Ganesh Ajjanagadde wrote: >> > On Sun, Mar 13, 2016 at 12:49 PM, Reimar Döffinger >> > wrote: >> > > On Sun, Mar 13, 2016 at 12:24:25PM -0400, Ganesh Ajjanagadde wrote: >> > >> On Sat, Mar 12, 2016 at 1:24 PM, Reimar Döffinger >> > >> wrote: >> > >> > for (i = 0; i < 1<<13; i++) >> > >> > -cbrt_tab[i] = CBRT(cbrt_tab_dbl[i]); >> > >> > +AAC_RENAME(ff_cbrt_tab)[i] = CBRT(cbrt_tab_dbl[i]); >> > >> > } >> > >> > } >> > >> >> > >> Note that cbrt_tab_dbl is really intended to be shared by both the >> > >> fixed/floating table inits. This was another thing my patch achieved: >> > >> only doing the more expensive double table init once across >> > >> float/fixed, and then doing the cheap conversion to uint32_t via >> > >> av_float2int or lrint(x*8192). Please change; it could go into a >> > >> separate patch if you prefer. >> > > >> > > IMHO you really need to argue why that would be desirable. >> > > The only case I can see this as useful is if someone >> > > runs at the same time fixed-point AAC decode and AAC encode, >> > > where it saves a bit of startup time. >> > > In all other cases you waste time and memory initializing >> > > a table that will never be used. >> > >> > I don't understand the waste; the double init anyway needs to be done, >> > all tables are derived from it. This dates to an approach I did in >> > commit: 07a11ebcab9b31e9fc784029e5d24e6fbf486ff3. >> >> The waste is in writing to the table that will never be used. >> As long as it is left as 0, it will not use memory, as soon >> as you touch it it uses up memory. >> But see my patch, if people think it's better it can be added. > > And looking at that commit, I actually realize now that the > cbrt_tab_dbl will also permanently waste 64 kB of memory despite > never being used again. > Using malloc/free for it would potentially be better (though > in general I have some doubts about the wisdom of optimizing > for initialization time at the detriment of runtime performance > or memory usage). --enable-hardcoded-tables partially does that; it increases memory usage as tables are burnt into the library at some gains for initialization time. > ___ > 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] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 01:27:52PM -0400, Ganesh Ajjanagadde wrote: > On Sun, Mar 13, 2016 at 1:21 PM, Reimar Döffinger > wrote: > >> > I don't understand the waste; the double init anyway needs to be done, > >> > all tables are derived from it. This dates to an approach I did in > >> > commit: 07a11ebcab9b31e9fc784029e5d24e6fbf486ff3. > >> > >> The waste is in writing to the table that will never be used. > >> As long as it is left as 0, it will not use memory, as soon > >> as you touch it it uses up memory. > >> But see my patch, if people think it's better it can be added. > > > > And looking at that commit, I actually realize now that the > > cbrt_tab_dbl will also permanently waste 64 kB of memory despite > > never being used again. > > Using malloc/free for it would potentially be better (though > > in general I have some doubts about the wisdom of optimizing > > for initialization time at the detriment of runtime performance > > or memory usage). > > --enable-hardcoded-tables partially does that; it increases memory > usage as tables are burnt into the library at some gains for > initialization time. No, exactly not. It increases disk usage, but it decreases memory usage. Tables are not loaded just because they are in the binary, not when they are in .rodata. If you are really lucky, even when the cbrt tables are used but only a small part of them, with --enable-hardcoded-tables you'd not even necessarily end up with all of them in RAM (admittedly you can also see that as a disadvantage: the chances that you end up with a page fault in the middle of decoding when you don't really want it is there, too). Gaining initialization time is absolutely not the point of that option, it doesn't make sense and I have no idea how that myth came to be (it may admittedly be true in some cases, but it's not the point or very relevant). Just for AAC CBRT tables (which are small in comparison), hardcoded tables saves 128 kB of RAM/swap once you no longer use the AAC codecs compared to your patch (64 kB for the double table + 2*32kB for the final tables + possibly a little bit from not needing the initialization code). Of course 128 kB less in swap space vs. 64 kB more in the binary/main storage is not really very useful in most cases, but I don't think one can argue it is worse. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On Sun, Mar 13, 2016 at 1:46 PM, Reimar Döffinger wrote: > On Sun, Mar 13, 2016 at 01:27:52PM -0400, Ganesh Ajjanagadde wrote: >> On Sun, Mar 13, 2016 at 1:21 PM, Reimar Döffinger >> wrote: >> >> > I don't understand the waste; the double init anyway needs to be done, >> >> > all tables are derived from it. This dates to an approach I did in >> >> > commit: 07a11ebcab9b31e9fc784029e5d24e6fbf486ff3. >> >> >> >> The waste is in writing to the table that will never be used. >> >> As long as it is left as 0, it will not use memory, as soon >> >> as you touch it it uses up memory. >> >> But see my patch, if people think it's better it can be added. >> > >> > And looking at that commit, I actually realize now that the >> > cbrt_tab_dbl will also permanently waste 64 kB of memory despite >> > never being used again. >> > Using malloc/free for it would potentially be better (though >> > in general I have some doubts about the wisdom of optimizing >> > for initialization time at the detriment of runtime performance >> > or memory usage). >> >> --enable-hardcoded-tables partially does that; it increases memory >> usage as tables are burnt into the library at some gains for >> initialization time. > > No, exactly not. It increases disk usage, but it decreases memory > usage. > Tables are not loaded just because they are in the binary, not > when they are in .rodata. > If you are really lucky, even when the cbrt tables are used but only > a small part of them, with --enable-hardcoded-tables you'd not > even necessarily end up with all of them in RAM (admittedly > you can also see that as a disadvantage: the chances that > you end up with a page fault in the middle of decoding when > you don't really want it is there, too). Correct me if I am wrong, but I don't think an OS/runtime system actually loads at the granularity of individual tables. It would load at the granularity of pages, there can be a greater chance of page faults with larger images, such as due to larger .rodata. > Gaining initialization time is absolutely not the point of > that option, it doesn't make sense and I have no idea > how that myth came to be (it may admittedly be true > in some cases, but it's not the point or very relevant). > Just for AAC CBRT tables (which are small in comparison), > hardcoded tables saves 128 kB of RAM/swap once you no longer > use the AAC codecs compared to your patch (64 kB for the > double table + 2*32kB for the final tables + possibly > a little bit from not needing the initialization code). Ok, so the tables are pulled into RAM on a as-needed basis. But then when are they offloaded? Savings (apart from the 64 kB for the double table) will only kick in at the time of offloading when the page is freed. > Of course 128 kB less in swap space vs. 64 kB more in the > binary/main storage is not really very useful in most cases, > but I don't think one can argue it is worse. > ___ > 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] Move cbrt tables to a separate cbrt_data(_fixed).c files.
On 13.03.2016, at 19:11, Ganesh Ajjanagadde wrote: > On Sun, Mar 13, 2016 at 1:46 PM, Reimar Döffinger > wrote: >> >>> >>> --enable-hardcoded-tables partially does that; it increases memory >>> usage as tables are burnt into the library at some gains for >>> initialization time. >> >> No, exactly not. It increases disk usage, but it decreases memory >> usage. >> Tables are not loaded just because they are in the binary, not >> when they are in .rodata. >> If you are really lucky, even when the cbrt tables are used but only >> a small part of them, with --enable-hardcoded-tables you'd not >> even necessarily end up with all of them in RAM (admittedly >> you can also see that as a disadvantage: the chances that >> you end up with a page fault in the middle of decoding when >> you don't really want it is there, too). > > Correct me if I am wrong, but I don't think an OS/runtime system > actually loads at the granularity of individual tables. It would load > at the granularity of pages, there can be a greater chance of page > faults with larger images, such as due to larger .rodata. The cbrt tables are a lot larger than a page, so I considered that unnecessary details. Also all tables, whether in .bss or .rodata share the page granularity issue. "greater chance of page faults" is not strictly true as initialising the tables in .bss will cause page faults, too. But yes the the .rodata page faults need to go to disk and are more costly. Unless you run a system supporting in-place execution... >> Gaining initialization time is absolutely not the point of >> that option, it doesn't make sense and I have no idea >> how that myth came to be (it may admittedly be true >> in some cases, but it's not the point or very relevant). >> Just for AAC CBRT tables (which are small in comparison), >> hardcoded tables saves 128 kB of RAM/swap once you no longer >> use the AAC codecs compared to your patch (64 kB for the >> double table + 2*32kB for the final tables + possibly >> a little bit from not needing the initialization code). > > Ok, so the tables are pulled into RAM on a as-needed basis. But then > when are they offloaded? Savings (apart from the 64 kB for the double > table) will only kick in at the time of offloading when the page is > freed. It will be swapped out normally, whenever the OS decides it has a better use for the RAM. .rodata will be easier to swap as it is non-dirty (does not require a write), but the exact priority compared to e.g. cache pages is up to the OS. It could keep .rodata pages just as part of its generic file system cache if it wants... Initialised .bss tables can of course be swapped out, too, but they require a write and the OS is less likely to do it, plus it requires you to have swap (systems designed to leave no traces cannot use swap for example, at least not with flash storage where securely erasing data is kind of not possible). If one were to dedicate sufficient craziness to it one could probably build a system that used munmap/madvise and SIGSEGV or user-space pagefault handling to combine the advantages of both. I certainly wouldn't recommend it though. And as said, in addition sharing the .bss tables across instances tends to not be possible but is trivial for .rodata tables. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
Am 12.03.16 um 15:14 schrieb Thilo Borgmann:
> Add coreimage filter for OSX.
Option type set to bool (Nicolas)
Proper Texinfo escaping (comments on trac ticket #4143)
New patch attached.
-Thilo
From 32198ec9a0522f181ac8a4974b7b36de4e08596d Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 13 Mar 2016 20:49:59 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
on OSX.
---
Changelog | 1 +
MAINTAINERS| 1 +
configure | 2 +
doc/filters.texi | 67 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_coreimage.m | 553 +
7 files changed, 626 insertions(+)
create mode 100644 libavfilter/vf_coreimage.m
diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- ciescope filter
- protocol blacklisting API
- MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
vf_colorbalance.c Paul B Mahol
vf_colorkey.c Timo Rothenpieler
vf_colorlevels.c Paul B Mahol
+ vf_coreimage.mThilo Borgmann
vf_deband.c Paul B Mahol
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC )
diff --git a/configure b/configure
index 1b189328..da51e06 100755
--- a/configure
+++ b/configure
@@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
frei0r_src_filter_extralibs='$ldl'
ladspa_filter_extralibs='$ldl'
nvenc_encoder_extralibs='$ldl'
+coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework
OpenGL"
if ! disabled network; then
check_func getaddrinfo $network_extralibs
@@ -5483,6 +5484,7 @@ enabled avisynth && { { check_lib2 "windows.h"
LoadLibrary; } ||
die "ERROR: LoadLibrary/dlopen not found for
avisynth"; }
enabled cuda && check_lib cuda.h cuInit -lcuda
enabled chromaprint && require chromaprint chromaprint.h
chromaprint_get_version -lchromaprint
+enabled coreimage_filter && { check_header_objcc QuartzCore/CoreImage.h ||
disable coreimage_filter; }
enabled decklink && { check_header DeckLinkAPI.h || die "ERROR:
DeckLinkAPI.h header not found"; }
enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h
header not found"; }
enabled gmp && require2 gmp gmp.h mpz_export -lgmp
diff --git a/doc/filters.texi b/doc/filters.texi
index d5d619e..a48b27b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4955,6 +4955,73 @@ convolution="-2 -1 0 -1 1 1 0 1 2:-2 -1 0 -1 1 1 0 1
2:-2 -1 0 -1 1 1 0 1 2:-2 -
Copy the input source unchanged to the output. This is mainly useful for
testing purposes.
+@anchor{coreimage}
+@section coreimage
+
+Video filtering on GPU using Apple's CoreImage API on OSX.
+
+Hardware acceleration is based on an OpenGL context. Usually, this means it is
processed by video hardware. However, software-based OpenGL implementations
exist which means there is no guarantee for hardware processing. It depends on
the respective OSX.
+
+There are many filters and image generators provided by Apple that come with a
large variety of options. The filter has to be referenced by its name along
with its options.
+
+The coreimage filter accepts the following options:
+@table @option
+@item list_filters
+List all available filters along with all their respective options as well as
possible minimum and maximum values along with the default values.
+@example
+coreimage=list_filters=true
+@end example
+
+@item filter
+Specifiy all filters by their respective name and options.
+Use @var{list_filters} to determine all valid filter names and options.
+Numerical options are specified by a float value and are automatically clamped
to their respective value range.
+Vector and color options have to be specified by a list of space separated
float values. Character escaping has to be done.
+A special option name @code{default} is available to use default options for a
filter.
+It is required to specify either @code{default} or at least one of the filter
options.
+All omitted options are used with their default values.
+The syntax of the filter string is as follows:
+@example
+filter=@@=[@@=][@@...][#@@=[@@=][@@...]]
+@end example
+@end table
+
+Several filters can be chained for successive processing without GPU-HOST
transfers allowing for fast processing of complex filter chains.
+Currently, only filters with zero (generators) or exactly one (filters) input
image and one output image are supported.
+Also, transition filters are not yet usable as intended.
+
+So
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
Le quartidi 24 ventôse, an CCXXIV, Thilo Borgmann a écrit :
> +{ "list_filters", "list available filters", OFFSET(list_filters),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS, "list_filters" },
> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, FLAGS,
> "list_filters" },
> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS,
> "list_filters" },
You forgot to remove the constants.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ffjni: remove use of private JniInvocation API to retreive the Java VM
On Fri, Mar 11, 2016 at 09:36:41PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> Android N will prevent users from loading non-public APIs.
>
> Users should only rely on the av_jni_set_java_vm function to set the
> Java VM.
> ---
> libavcodec/ffjni.c | 88
> ++
> 1 file changed, 3 insertions(+), 85 deletions(-)
>
> diff --git a/libavcodec/ffjni.c b/libavcodec/ffjni.c
> index da13699..54f3122 100644
> --- a/libavcodec/ffjni.c
> +++ b/libavcodec/ffjni.c
> @@ -35,80 +35,6 @@
> static JavaVM *java_vm = NULL;
> static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
>
> -/**
> - * Check if JniInvocation has been initialized. Only available on
> - * Android >= 4.4.
> - *
> - * @param log_ctx context used for logging, can be NULL
> - * @return 0 on success, < 0 otherwise
> - */
> -static int check_jni_invocation(void *log_ctx)
> -{
> -int ret = AVERROR_EXTERNAL;
> -void *handle = NULL;
> -void **jni_invocation = NULL;
> -
> -handle = dlopen(NULL, RTLD_LOCAL);
> -if (!handle) {
> -goto done;
> -}
> -
> -jni_invocation = (void **)dlsym(handle,
> "_ZN13JniInvocation15jni_invocation_E");
> -if (!jni_invocation) {
> -av_log(log_ctx, AV_LOG_ERROR, "Could not find
> JniInvocation::jni_invocation_ symbol\n");
> -goto done;
> -}
> -
> -ret = !(jni_invocation != NULL && *jni_invocation != NULL);
> -
> -done:
> -if (handle) {
> -dlclose(handle);
> -}
> -
> -return ret;
> -}
> -
> -/**
> - * Return created Java virtual machine using private JNI_GetCreatedJavaVMs
> - * function from the specified library name.
> - *
> - * @param name library name used for symbol lookups, can be NULL
> - * @param log_ctx context used for logging, can be NULL
> - * @return the current Java virtual machine in use
> - */
> -static JavaVM *get_java_vm(const char *name, void *log_ctx)
> -{
> -JavaVM *vm = NULL;
> -jsize nb_vm = 0;
> -
> -void *handle = NULL;
> -jint (*get_created_java_vms) (JavaVM ** vmBuf, jsize bufLen, jsize
> *nVMs) = NULL;
> -
> -handle = dlopen(name, RTLD_LOCAL);
> -if (!handle) {
> -return NULL;
> -}
> -
> -get_created_java_vms = (jint (*)(JavaVM **, jsize, jsize *))
> dlsym(handle, "JNI_GetCreatedJavaVMs");
> -if (!get_created_java_vms) {
> -av_log(log_ctx, AV_LOG_ERROR, "Could not find JNI_GetCreatedJavaVMs
> symbol in library '%s'\n", name);
> -goto done;
> -}
> -
> -if (get_created_java_vms(&vm, 1, &nb_vm) != JNI_OK) {
> -av_log(log_ctx, AV_LOG_ERROR, "Could not get created Java virtual
> machines\n");
> -goto done;
> -}
> -
> -done:
> -if (handle) {
> -dlclose(handle);
> -}
> -
> -return vm;
> -}
> -
> JNIEnv *ff_jni_attach_env(int *attached, void *log_ctx)
> {
> int ret = 0;
> @@ -117,21 +43,13 @@ JNIEnv *ff_jni_attach_env(int *attached, void *log_ctx)
> *attached = 0;
>
> pthread_mutex_lock(&lock);
> -if (java_vm == NULL && (java_vm = av_jni_get_java_vm(log_ctx)) == NULL) {
> -
> -av_log(log_ctx, AV_LOG_INFO, "Retrieving current Java virtual
> machine using Android JniInvocation wrapper\n");
> -if (check_jni_invocation(log_ctx) == 0) {
> -if ((java_vm = get_java_vm(NULL, log_ctx)) != NULL ||
> -(java_vm = get_java_vm("libdvm.so", log_ctx)) != NULL ||
> -(java_vm = get_java_vm("libart.so", log_ctx)) != NULL) {
> -av_log(log_ctx, AV_LOG_INFO, "Found Java virtual machine
> using Android JniInvocation wrapper\n");
> -}
> -}
> +if (java_vm == NULL) {
> +java_vm = av_jni_get_java_vm(log_ctx);
> }
> pthread_mutex_unlock(&lock);
>
> if (!java_vm) {
> -av_log(log_ctx, AV_LOG_ERROR, "Could not retrieve a Java virtual
> machine\n");
> +av_log(log_ctx, AV_LOG_ERROR, "No Java virtual machine has been
> registered\n");
> return NULL;
> }
>
If nobody objects, I will push the patch (with #include removed)
tomorrow.
Matthieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
Am 13.03.16 um 15:08 schrieb wm4:
> On Sat, 12 Mar 2016 15:13:21 +0100
> Thilo Borgmann wrote:
>
>> From a1d9ce388c69eabb256e6b351c2acd36d7f4076e Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann
>> Date: Sat, 12 Mar 2016 14:52:17 +0100
>> Subject: [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
>>
>> ---
>> libavutil/dict.c | 5 -
>> libavutil/dict.h | 5 +++--
>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>> index 8bb65a1..70c0184 100644
>> --- a/libavutil/dict.c
>> +++ b/libavutil/dict.c
>> @@ -70,9 +70,12 @@ int av_dict_set(AVDictionary **pm, const char *key, const
>> char *value,
>> int flags)
>> {
>> AVDictionary *m = *pm;
>> -AVDictionaryEntry *tag = av_dict_get(m, key, NULL, flags);
>> +AVDictionaryEntry *tag = NULL;
>> char *oldval = NULL, *copy_key = NULL, *copy_value = NULL;
>>
>> +if (!(flags & AV_DICT_MULTIKEY)) {
>> +tag = av_dict_get(m, key, NULL, flags);
>> +}
>> if (flags & AV_DICT_DONT_STRDUP_KEY)
>> copy_key = (void *)key;
>> else
>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>> index b0aa784..c589bcd 100644
>> --- a/libavutil/dict.h
>> +++ b/libavutil/dict.h
>> @@ -76,6 +76,7 @@
>> #define AV_DICT_DONT_OVERWRITE 16 ///< Don't overwrite existing entries.
>> #define AV_DICT_APPEND 32 /**< If the entry already exists,
>> append to it. Note that no
>>delimiter is added, the strings are
>> simply concatenated. */
>> +#define AV_DICT_MULTIKEY 64 /**< Allow to store several equal keys
>> in the dictionary */
>>
>> typedef struct AVDictionaryEntry {
>> char *key;
>> @@ -118,8 +119,8 @@ int av_dict_count(const AVDictionary *m);
>> *
>> * @param pm pointer to a pointer to a dictionary struct. If *pm is NULL
>> * a dictionary struct is allocated and put in *pm.
>> - * @param key entry key to add to *pm (will be av_strduped depending on
>> flags)
>> - * @param value entry value to add to *pm (will be av_strduped depending on
>> flags).
>> + * @param key entry key to add to *pm (will either be av_strduped or added
>> as a new key depending on flags)
>> + * @param value entry value to add to *pm (will be av_strduped or added as
>> a new key depending on flags).
>> *Passing a NULL value will cause an existing entry to be deleted.
>> * @return >= 0 on success otherwise an error code <0
>> */
>
> Changing the semantics of AVDictionary just like this seems rather
> questionable...
It changes nothing for existing code, just adds a new feature. I don't
think it hurts anyone or anything...
> Are you sure you don't want a list instead?
AVDictionary serves the purpose perfectly and already handles all the
key value seperation, parsing and error resilience... do we have a list
container ready to do that?
I'm not happy to use a deprecated thing either but AVTree seems not to
be ready yet (parsing from string, keeping insertion order of keys even
when rebalancing and most importantly enumeration (sequentially search
for keys) seems not to be ready for multiple keys - although the tree
itself can handle mutliple equal keys). This is why I decided to go with
adding a new flag to the AVDictionary rather than doing it with AVTree
nearly from scratch...
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
Am 13.03.16 um 20:55 schrieb Nicolas George:
> Le quartidi 24 ventôse, an CCXXIV, Thilo Borgmann a écrit :
>> +{ "list_filters", "list available filters", OFFSET(list_filters),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS, "list_filters" },
>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, FLAGS,
>> "list_filters" },
>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS,
>> "list_filters" },
>
> You forgot to remove the constants.
Removed. Patch attached.
-Thilo
From 4aef8c0d09e109cedd92e17cc04a6ef6236c07ab Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 13 Mar 2016 21:08:18 +0100
Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
on OSX.
---
Changelog | 1 +
MAINTAINERS| 1 +
configure | 2 +
doc/filters.texi | 67 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_coreimage.m | 551 +
7 files changed, 624 insertions(+)
create mode 100644 libavfilter/vf_coreimage.m
diff --git a/Changelog b/Changelog
index 1f57f5e..5053a86 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- ciescope filter
- protocol blacklisting API
- MediaCodec H264 decoding
+- coreimage filter (GPU based image filtering on OSX)
version 3.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 531c21d..a993a67 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -370,6 +370,7 @@ Filters:
vf_colorbalance.c Paul B Mahol
vf_colorkey.c Timo Rothenpieler
vf_colorlevels.c Paul B Mahol
+ vf_coreimage.mThilo Borgmann
vf_deband.c Paul B Mahol
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC )
diff --git a/configure b/configure
index 1b189328..da51e06 100755
--- a/configure
+++ b/configure
@@ -5255,6 +5255,7 @@ frei0r_filter_extralibs='$ldl'
frei0r_src_filter_extralibs='$ldl'
ladspa_filter_extralibs='$ldl'
nvenc_encoder_extralibs='$ldl'
+coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework
OpenGL"
if ! disabled network; then
check_func getaddrinfo $network_extralibs
@@ -5483,6 +5484,7 @@ enabled avisynth && { { check_lib2 "windows.h"
LoadLibrary; } ||
die "ERROR: LoadLibrary/dlopen not found for
avisynth"; }
enabled cuda && check_lib cuda.h cuInit -lcuda
enabled chromaprint && require chromaprint chromaprint.h
chromaprint_get_version -lchromaprint
+enabled coreimage_filter && { check_header_objcc QuartzCore/CoreImage.h ||
disable coreimage_filter; }
enabled decklink && { check_header DeckLinkAPI.h || die "ERROR:
DeckLinkAPI.h header not found"; }
enabled frei0r&& { check_header frei0r.h || die "ERROR: frei0r.h
header not found"; }
enabled gmp && require2 gmp gmp.h mpz_export -lgmp
diff --git a/doc/filters.texi b/doc/filters.texi
index d5d619e..7d0bb26 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4955,6 +4955,73 @@ convolution="-2 -1 0 -1 1 1 0 1 2:-2 -1 0 -1 1 1 0 1
2:-2 -1 0 -1 1 1 0 1 2:-2 -
Copy the input source unchanged to the output. This is mainly useful for
testing purposes.
+@anchor{coreimage}
+@section coreimage
+
+Video filtering on GPU using Apple's CoreImage API on OSX.
+
+Hardware acceleration is based on an OpenGL context. Usually, this means it is
processed by video hardware. However, software-based OpenGL implementations
exist which means there is no guarantee for hardware processing. It depends on
the respective OSX.
+
+There are many filters and image generators provided by Apple that come with a
large variety of options. The filter has to be referenced by its name along
with its options.
+
+The coreimage filter accepts the following options:
+@table @option
+@item list_filters
+List all available filters along with all their respective options as well as
possible minimum and maximum values along with the default values.
+@example
+coreimage=list_filters=true
+@end example
+
+@item filter
+Specifiy all filters by their respective name and options.
+Use @var{list_filters} to determine all valid filter names and options.
+Numerical options are specified by a float value and are automatically clamped
to their respective value range.
+Vector and color options have to be specified by a list of space separated
float values. Character escaping has to be done.
+A special option name @code{default} is available to use default options for a
filter.
+It is required to specify either @code{default} or at least one of the filter
options.
+All omitted options are used with their default values.
+The syntax of the filter string is as follows:
+@example
+filter=@@=[@@=][@@...][#@@=[@@=][@@...]]
+@end example
+@end table
+
+Several fi
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_bwdif: add x86 SIMD
> ffmpeg | branch: master | Thomas Mundt | Sun Mar 13 > 10:06:21 2016 +0100| [5024a82e9548d186224b3be4de4041dbd1c2a482] | committer: > Paul B Mahol > > avfilter/vf_bwdif: add x86 SIMD > > Signed-off-by: Thomas Mundt > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5024a82e9548d186224b3be4de4041dbd1c2a482 > --- > > libavfilter/bwdif.h | 72 +++ > libavfilter/vf_bwdif.c | 69 +++--- > libavfilter/x86/Makefile|2 + > libavfilter/x86/vf_bwdif.asm| 266 > +++ > libavfilter/x86/vf_bwdif_init.c | 78 > 5 files changed, 432 insertions(+), 55 deletions(-) > [...] > diff --git a/libavfilter/x86/vf_bwdif.asm b/libavfilter/x86/vf_bwdif.asm > new file mode 100644 > index 000..11aa025 > --- /dev/null > +++ b/libavfilter/x86/vf_bwdif.asm > @@ -0,0 +1,266 @@ > +;* > +;* x86-optimized functions for bwdif filter > +;* > +;* Copyright (C) 2016 Thomas Mundt Since you adapted quite a bit of this code from yadif simd, the copyright header should reflect that. > +;* > +;* This file is part of FFmpeg. > +;* > +;* FFmpeg is free software; you can redistribute it and/or > +;* modify it under the terms of the GNU Lesser General Public > +;* License as published by the Free Software Foundation; either > +;* version 2.1 of the License, or (at your option) any later version. > +;* > +;* FFmpeg is distributed in the hope that it will be useful, > +;* but WITHOUT ANY WARRANTY; without even the implied warranty of > +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +;* Lesser General Public License for more details. > +;* > +;* You should have received a copy of the GNU Lesser General Public > +;* License along with FFmpeg; if not, write to the Free Software > +;* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 > USA > +;** > + ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
On Sun, Mar 13, 2016 at 09:09:39PM +0100, Thilo Borgmann wrote:
> Am 13.03.16 um 20:55 schrieb Nicolas George:
> > Le quartidi 24 ventôse, an CCXXIV, Thilo Borgmann a écrit :
> >> +{ "list_filters", "list available filters", OFFSET(list_filters),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = FLAGS, "list_filters" },
> >> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0, FLAGS,
> >> "list_filters" },
> >> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0, FLAGS,
> >> "list_filters" },
> >
> > You forgot to remove the constants.
>
> Removed. Patch attached.
>
> -Thilo
>
> From 4aef8c0d09e109cedd92e17cc04a6ef6236c07ab Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann
> Date: Sun, 13 Mar 2016 21:08:18 +0100
> Subject: [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering
> on OSX.
>
> ---
> Changelog | 1 +
> MAINTAINERS| 1 +
> configure | 2 +
> doc/filters.texi | 67 ++
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
> libavfilter/vf_coreimage.m | 551
> +
Sorry to raise that now, but isn't this API available in C as well (just
like VT)?
[...]
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] getting wall clock time from rtsp stream
Hi, We tried this via the docs but got lost heavily. We need the actual wall clock time of video data from a camera which delivers via rtsp. I have read around that there are things like RTCP sender reports and such on the low level containing this info, and I have seen indication that it is somehow parsed by ffmpeg. What is the easiest way to get to this information? Best wpuld be command line dump of the time of the first frame, but rendering it somewhere, or even hacking ffmpeg would be doable too. Very thanlful for help, as we really need this to sync the video data to sensor data form other sources. Best Daniel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 2/2] avcodec/sinewin_tablegen: use sin instead of sinf for fixed point to improve precision
Signed-off-by: Marton Balint
---
libavcodec/sinewin_tablegen.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/sinewin_tablegen.h b/libavcodec/sinewin_tablegen.h
index 4432135..9c912aa 100644
--- a/libavcodec/sinewin_tablegen.h
+++ b/libavcodec/sinewin_tablegen.h
@@ -50,9 +50,9 @@ SINETABLE(8192);
#endif
#if USE_FIXED
-#define SIN_FIX(a) (int)floor((a) * 0x8000 + 0.5)
+#define SIN_FIX(a) (int)floor(sin(a) * 0x8000 + 0.5)
#else
-#define SIN_FIX(a) a
+#define SIN_FIX(a) sinf(a)
#endif
SINETABLE_CONST INTFLOAT * const AAC_RENAME(ff_sine_windows)[] = {
@@ -66,7 +66,7 @@ SINETABLE_CONST INTFLOAT * const
AAC_RENAME(ff_sine_windows)[] = {
av_cold void AAC_RENAME(ff_sine_window_init)(INTFLOAT *window, int n) {
int i;
for(i = 0; i < n; i++)
-window[i] = SIN_FIX(sinf((i + 0.5) * (M_PI / (2.0 * n;
+window[i] = SIN_FIX((i + 0.5) * (M_PI / (2.0 * n)));
}
av_cold void AAC_RENAME(ff_init_ff_sine_windows)(int index) {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavu/lfg: add 64 bit random number generator
This is based on the relatively well known xorshift128+ of Sebastiano
Vigna (https://en.wikipedia.org/wiki/Xorshift) that performs very well on the
BigCrush suite, is very efficient, and is thus used by a number of
clients: http://xorshift.di.unimi.it/ (see Introduction).
Moreover, the implementation is in the public domain:
http://xorshift.di.unimi.it/xorshift128plus.c.
Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits),
and has a much smaller cache (128 bits). Thus, the timings should also
be more stable.
This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and
likely less random as measured by BigCrush - most LFG's perform
quite poorly on the BigCrush suite:
http://www6.tw.freebsd.org/distfiles/testu01.pdf.
In particular, FFmpeg's seems to be Ran055 in the paper, see pg31.
Sample benchmark (Haswell, GCC + -march=native):
23200 decicycles in 624 calls of av_lfg_get, 1 runs, 0 skips
23040 decicycles in 624 calls of av_lfg_get, 2 runs, 0 skips
22810 decicycles in 624 calls of av_lfg_get, 4 runs, 0 skips
[...]
19884 decicycles in 624 calls of av_lfg_get, 65532 runs, 4 skips
19880 decicycles in 624 calls of av_lfg_get, 131067 runs, 5 skips
19884 decicycles in 624 calls of av_lfg_get, 262136 runs, 8 skips
19877 decicycles in 624 calls of av_lfg_get, 524276 runs, 12 skips
25380 decicycles in 624 calls of av_rand64_get, 1 runs, 0 skips
28560 decicycles in 624 calls of av_rand64_get, 2 runs, 0 skips
30112 decicycles in 624 calls of av_rand64_get, 4 runs, 0 skips
[...]
22627 decicycles in 624 calls of av_rand64_get, 65536 runs, 0 skips
22625 decicycles in 624 calls of av_rand64_get, 131072 runs, 0 skips
22625 decicycles in 624 calls of av_rand64_get, 262143 runs, 1 skips
22624 decicycles in 624 calls of av_rand64_get, 524286 runs, 2 skips
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/lfg.c | 33 -
libavutil/lfg.h | 26 ++
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/libavutil/lfg.c b/libavutil/lfg.c
index 5ffd76f..e8e4adf 100644
--- a/libavutil/lfg.c
+++ b/libavutil/lfg.c
@@ -1,6 +1,11 @@
/*
* Lagged Fibonacci PRNG
* Copyright (c) 2008 Michael Niedermayer
+ * 64 bit random number generator written by
+ * Written in 2015 by Sebastiano Vigna (vi...@acm.org)
+ * under public domain:
+ * https://creativecommons.org/publicdomain/zero/1.0/
+ *
*
* This file is part of FFmpeg.
*
@@ -44,6 +49,19 @@ av_cold void av_lfg_init(AVLFG *c, unsigned int seed)
c->index = 0;
}
+static inline uint64_t next64(uint64_t x) {
+uint64_t z = (x += UINT64_C(0x9E3779B97F4A7C15));
+z = (z ^ (z >> 30)) * UINT64_C(0xBF58476D1CE4E5B9);
+z = (z ^ (z >> 27)) * UINT64_C(0x94D049BB133111EB);
+return z ^ (z >> 31);
+}
+
+av_cold void av_rand64_init(AVRAND64 *rng, uint64_t seed)
+{
+rng->state[0] = seed;
+rng->state[1] = next64(seed);
+}
+
void av_bmg_get(AVLFG *lfg, double out[2])
{
double x1, x2, w;
@@ -66,11 +84,14 @@ void av_bmg_get(AVLFG *lfg, double out[2])
int main(void)
{
int x = 0;
+uint64_t y = 0;
int i, j;
AVLFG state;
+AVRAND64 state64;
av_lfg_init(&state, 0xdeadbeef);
-for (j = 0; j < 1; j++) {
+av_rand64_init(&state64, UINT64_C(0xdeadbeefdeadbeef));
+for (j = 0; j < 100; j++) {
START_TIMER
for (i = 0; i < 624; i++) {
//av_log(NULL, AV_LOG_ERROR, "%X\n", av_lfg_get(&state));
@@ -80,6 +101,16 @@ int main(void)
}
av_log(NULL, AV_LOG_ERROR, "final value:%X\n", x);
+for (j = 0; j < 100; j++) {
+START_TIMER
+for (i = 0; i < 624; i++) {
+//av_log(NULL, AV_LOG_ERROR, "%X\n", av_lfg_get(&state));
+y += av_rand64_get(&state64);
+//y += ((uint64_t)av_lfg_get(&state) << 32) | av_lfg_get(&state);
+}
+STOP_TIMER("624 calls of av_rand64_get");
+}
+
/* BMG usage example */
{
double mean = 1000;
diff --git a/libavutil/lfg.h b/libavutil/lfg.h
index ec90562..1f0f38d 100644
--- a/libavutil/lfg.h
+++ b/libavutil/lfg.h
@@ -1,6 +1,10 @@
/*
* Lagged Fibonacci PRNG
* Copyright (c) 2008 Michael Niedermayer
+ * 64 bit random number generator written by
+ * Written in 2015 by Sebastiano Vigna (vi...@acm.org)
+ * under public domain:
+ * https://creativecommons.org/publicdomain/zero/1.0/
*
* This file is part of FFmpeg.
*
@@ -21,15 +25,28 @@
#ifndef AVUTIL_LFG_H
#define AVUTIL_LFG_H
+#include
typedef struct AVLFG {
unsigned int state[64];
int index;
} AVLFG;
+typedef struct AVRAND64 {
+uint64_t state[2];
+} AVRAND64;
+
void av_lfg_init(AVLFG *c, unsigned int seed);
/**
+ * Initialize the 64 bit random number generator.
+ *
+ * @param rng AVRAND64 structure that is initialized
+ * @param seed 64 bit seed
+ */
+void av_rand64
Re: [FFmpeg-devel] [PATCHv2 2/2] avcodec/sinewin_tablegen: use sin instead of sinf for fixed point to improve precision
On Sun, Mar 13, 2016 at 6:50 PM, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavcodec/sinewin_tablegen.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/sinewin_tablegen.h b/libavcodec/sinewin_tablegen.h
> index 4432135..9c912aa 100644
> --- a/libavcodec/sinewin_tablegen.h
> +++ b/libavcodec/sinewin_tablegen.h
> @@ -50,9 +50,9 @@ SINETABLE(8192);
> #endif
>
> #if USE_FIXED
> -#define SIN_FIX(a) (int)floor((a) * 0x8000 + 0.5)
> +#define SIN_FIX(a) (int)floor(sin(a) * 0x8000 + 0.5)
Note that lrint may be preferred, it is faster and better rounded.
Hosts/hardcoded tables can use lavu/tablegen.h, which fall back to
floor based hacks.
> #else
> -#define SIN_FIX(a) a
> +#define SIN_FIX(a) sinf(a)
> #endif
Also, why is it essential that SIN_FIX is redefined, can't you just
change sinf to sin on line 69?
>
> SINETABLE_CONST INTFLOAT * const AAC_RENAME(ff_sine_windows)[] = {
> @@ -66,7 +66,7 @@ SINETABLE_CONST INTFLOAT * const
> AAC_RENAME(ff_sine_windows)[] = {
> av_cold void AAC_RENAME(ff_sine_window_init)(INTFLOAT *window, int n) {
> int i;
> for(i = 0; i < n; i++)
> -window[i] = SIN_FIX(sinf((i + 0.5) * (M_PI / (2.0 * n;
> +window[i] = SIN_FIX((i + 0.5) * (M_PI / (2.0 * n)));
> }
Could you please add a link in the commit message describing more
verbosely why you need this (e.g which platform)?
>
> av_cold void AAC_RENAME(ff_init_ff_sine_windows)(int index) {
> --
> 2.6.2
>
> ___
> 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] [PATCHv2 2/2] avcodec/sinewin_tablegen: use sin instead of sinf for fixed point to improve precision
On Sun, 13 Mar 2016, Ganesh Ajjanagadde wrote:
On Sun, Mar 13, 2016 at 6:50 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavcodec/sinewin_tablegen.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/sinewin_tablegen.h b/libavcodec/sinewin_tablegen.h
index 4432135..9c912aa 100644
--- a/libavcodec/sinewin_tablegen.h
+++ b/libavcodec/sinewin_tablegen.h
@@ -50,9 +50,9 @@ SINETABLE(8192);
#endif
#if USE_FIXED
-#define SIN_FIX(a) (int)floor((a) * 0x8000 + 0.5)
+#define SIN_FIX(a) (int)floor(sin(a) * 0x8000 + 0.5)
Note that lrint may be preferred, it is faster and better rounded.
Hosts/hardcoded tables can use lavu/tablegen.h, which fall back to
floor based hacks.
Ok.
#else
-#define SIN_FIX(a) a
+#define SIN_FIX(a) sinf(a)
#endif
Also, why is it essential that SIN_FIX is redefined, can't you just
change sinf to sin on line 69?
I just didn't want to touch existing floating point code, sin may be
slower then sinf (?), and if the result is rounded to float from double
anyway, what is the point.
SINETABLE_CONST INTFLOAT * const AAC_RENAME(ff_sine_windows)[] = {
@@ -66,7 +66,7 @@ SINETABLE_CONST INTFLOAT * const
AAC_RENAME(ff_sine_windows)[] = {
av_cold void AAC_RENAME(ff_sine_window_init)(INTFLOAT *window, int n) {
int i;
for(i = 0; i < n; i++)
-window[i] = SIN_FIX(sinf((i + 0.5) * (M_PI / (2.0 * n;
+window[i] = SIN_FIX((i + 0.5) * (M_PI / (2.0 * n)));
}
Could you please add a link in the commit message describing more
verbosely why you need this (e.g which platform)?
Ok, as far as I recall the fixed point table was different on x86_32 and
x86_64, x86_32 was precise, x86_64 wasn't which is strange.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv5 3/3] avformat/mov: read start_pad from edit list start time if codec is aac
On Sun, 13 Mar 2016, Marton Balint wrote: Related to ticket #2324, #2325. Stream duration still need to be fixed... Signed-off-by: Marton Balint --- libavformat/mov.c| 3 +++ tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 8 tests/ref/fate/gaplessenc-pcm-to-mov-aac | 8 3 files changed, 11 insertions(+), 8 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 4f446ba..3fa8fcc 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2688,6 +2688,9 @@ static void mov_build_index(MOVContext *mov, AVStream *st) st->codec->has_b_frames = 1; } } + +if (!unsupported && st->codec->codec_id == AV_CODEC_ID_AAC && start_time > 0) +sc->start_pad = start_time; I wonder if sc->time_offset might be better here, instead of start_time. Anybody? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/2] avcodec/sinewin_tablegen: use sin instead of sinf for fixed point to improve precision
On Sun, Mar 13, 2016 at 8:09 PM, Marton Balint wrote:
>
> On Sun, 13 Mar 2016, Ganesh Ajjanagadde wrote:
>
>> On Sun, Mar 13, 2016 at 6:50 PM, Marton Balint wrote:
>>>
>>> Signed-off-by: Marton Balint
>>> ---
>>> libavcodec/sinewin_tablegen.h | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavcodec/sinewin_tablegen.h
>>> b/libavcodec/sinewin_tablegen.h
>>> index 4432135..9c912aa 100644
>>> --- a/libavcodec/sinewin_tablegen.h
>>> +++ b/libavcodec/sinewin_tablegen.h
>>> @@ -50,9 +50,9 @@ SINETABLE(8192);
>>> #endif
>>>
>>> #if USE_FIXED
>>> -#define SIN_FIX(a) (int)floor((a) * 0x8000 + 0.5)
>>> +#define SIN_FIX(a) (int)floor(sin(a) * 0x8000 + 0.5)
>>
>>
>> Note that lrint may be preferred, it is faster and better rounded.
>> Hosts/hardcoded tables can use lavu/tablegen.h, which fall back to
>> floor based hacks.
>
>
> Ok.
>
>>
>>> #else
>>> -#define SIN_FIX(a) a
>>> +#define SIN_FIX(a) sinf(a)
>>> #endif
>>
>>
>> Also, why is it essential that SIN_FIX is redefined, can't you just
>> change sinf to sin on line 69?
>
>
> I just didn't want to touch existing floating point code, sin may be slower
> then sinf (?), and if the result is rounded to float from double anyway,
> what is the point.
Keep in mind that: double x; float y = sinf(x) and double x; float y =
sin(x) do not necessarily give the same result on a fixed platform,
often results in a few ulp differences due to lack of composability of
rounding with functions. This in 99.99% of the cases won't matter; I
believe our platforms libm's anyway have that much variation. In this
case, it seems like you anyway tested this, so it should be fine to
ignore.
>
>>>
>>> SINETABLE_CONST INTFLOAT * const AAC_RENAME(ff_sine_windows)[] = {
>>> @@ -66,7 +66,7 @@ SINETABLE_CONST INTFLOAT * const
>>> AAC_RENAME(ff_sine_windows)[] = {
>>> av_cold void AAC_RENAME(ff_sine_window_init)(INTFLOAT *window, int n) {
>>> int i;
>>> for(i = 0; i < n; i++)
>>> -window[i] = SIN_FIX(sinf((i + 0.5) * (M_PI / (2.0 * n;
>>> +window[i] = SIN_FIX((i + 0.5) * (M_PI / (2.0 * n)));
>>> }
>>
>>
>> Could you please add a link in the commit message describing more
>> verbosely why you need this (e.g which platform)?
>
>
> Ok, as far as I recall the fixed point table was different on x86_32 and
> x86_64, x86_32 was precise, x86_64 wasn't which is strange.
>
> Regards,
> Marton
>
> ___
> 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] [PATCHv3] lavu/lfg: switch to Ziggurat algorithm for normal random number generation (WIP)
On Sat, Mar 12, 2016 at 12:19 PM, Ganesh Ajjanagadde wrote: > Code taken from the Julia project, licensed under MIT: > https://github.com/JuliaLang/julia/blob/master/base/random.jl, in turn > derived from: "The Ziggurat Method for generating random variables" - > Marsaglia and Tsang. > > Paper and reference code: http://www.jstatsoft.org/v05/i08/. This is > well known to be the fastest method empirically for generating normal random > variables for a fixed PRNG source. > > Note that there are a large number of implementations with > various tunings, this was one of the simpler ones and also has a friendly > license. > > This results in ~ 3x speedup of random number generation: > old: > 15090 decicycles in av_bmg_get, 1 runs, 0 skips > 13140 decicycles in av_bmg_get, 2 runs, 0 skips > 10117 decicycles in av_bmg_get, 4 runs, 0 skips > [...] >2133 decicycles in av_bmg_get, 524268 runs, 20 skips=60.4x >2134 decicycles in av_bmg_get, 1048531 runs, 45 skips=61.3x >2135 decicycles in av_bmg_get, 2097061 runs, 91 skips=61.9x > > new: >7650 decicycles in av_gaussian_get, 1 runs, 0 skips >5490 decicycles in av_gaussian_get, 2 runs, 0 skips >3982 decicycles in av_gaussian_get, 4 runs, 0 skips >[...] > 812 decicycles in av_gaussian_get, 524281 runs, 7 skips > 813 decicycles in av_gaussian_get, 1048563 runs, 13 skips > 813 decicycles in av_gaussian_get, 2097131 runs, 21 skips > > and accordingly a ~2% speedup in aac encoding (-march=native, Haswell, clang): > > old: > ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac 5.30s user 0.02s system > 99% cpu 5.322 total > new: > ffmpeg -f lavfi -i anoisesrc -t 300 -y sin_new.aac 5.16s user 0.03s system > 99% cpu 5.198 total > > Function added as av_gaussian_get with documentation, minor bumped. > > Reviewed-by: Michael Niedermayer > Reviewed-by: Reimar Döffinger > Signed-off-by: Ganesh Ajjanagadde Shelved for now; I would like to get the 64 bit optimized rng in first. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table
There is no reason for computing cbrtf at runtime; we have a table for
this.
Yields a negligible speedup.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/aacenc.c | 2 ++
libavcodec/aacenc_quantization.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 023260a..11c9272 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -45,6 +45,7 @@
#include "aacenc.h"
#include "aacenctab.h"
#include "aacenc_utils.h"
+#include "cbrt_data.h"
#include "psymodel.h"
@@ -897,6 +898,7 @@ alloc_fail:
static av_cold void aac_encode_init_tables(void)
{
ff_aac_tableinit();
+ff_cbrt_tableinit();
}
static av_cold int aac_encode_init(AVCodecContext *avctx)
diff --git a/libavcodec/aacenc_quantization.h b/libavcodec/aacenc_quantization.h
index 4250407..29b3c97 100644
--- a/libavcodec/aacenc_quantization.h
+++ b/libavcodec/aacenc_quantization.h
@@ -32,6 +32,7 @@
#include "aacenc.h"
#include "aacenctab.h"
#include "aacenc_utils.h"
+#include "cbrt_data.h"
/**
* Calculate rate distortion cost for quantizing with given codebook
@@ -105,7 +106,7 @@ static av_always_inline float
quantize_and_encode_band_cost_template(
curbits += 21;
} else {
int c = av_clip_uintp2(quant(t, Q, ROUNDING), 13);
-quantized = c*cbrtf(c)*IQ;
+quantized = av_int2float(ff_cbrt_tab[c])*IQ;
curbits += av_log2(c)*2 - 4 + 1;
}
} else {
--
2.7.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/lfg: add 64 bit random number generator
On Sun, Mar 13, 2016 at 07:12:50PM -0400, Ganesh Ajjanagadde wrote: > This is based on the relatively well known xorshift128+ of Sebastiano > Vigna (https://en.wikipedia.org/wiki/Xorshift) that performs very well on the > BigCrush suite, is very efficient, and is thus used by a number of > clients: http://xorshift.di.unimi.it/ (see Introduction). > > Moreover, the implementation is in the public domain: > http://xorshift.di.unimi.it/xorshift128plus.c. > > Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits), > and has a much smaller cache (128 bits). Thus, the timings should also > be more stable. > > This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and > likely less random as measured by BigCrush - most LFG's perform > quite poorly on the BigCrush suite: > http://www6.tw.freebsd.org/distfiles/testu01.pdf. > In particular, FFmpeg's seems to be Ran055 in the paper, see pg31. > > Sample benchmark (Haswell, GCC + -march=native): > 23200 decicycles in 624 calls of av_lfg_get, 1 runs, 0 skips > 23040 decicycles in 624 calls of av_lfg_get, 2 runs, 0 skips > 22810 decicycles in 624 calls of av_lfg_get, 4 runs, 0 skips > [...] > 19884 decicycles in 624 calls of av_lfg_get, 65532 runs, 4 skips > 19880 decicycles in 624 calls of av_lfg_get, 131067 runs, 5 skips > 19884 decicycles in 624 calls of av_lfg_get, 262136 runs, 8 skips > 19877 decicycles in 624 calls of av_lfg_get, 524276 runs, 12 skips > > 25380 decicycles in 624 calls of av_rand64_get, 1 runs, 0 skips > 28560 decicycles in 624 calls of av_rand64_get, 2 runs, 0 skips > 30112 decicycles in 624 calls of av_rand64_get, 4 runs, 0 skips > [...] > 22627 decicycles in 624 calls of av_rand64_get, 65536 runs, 0 skips > 22625 decicycles in 624 calls of av_rand64_get, 131072 runs, 0 skips > 22625 decicycles in 624 calls of av_rand64_get, 262143 runs, 1 skips > 22624 decicycles in 624 calls of av_rand64_get, 524286 runs, 2 skips > > Signed-off-by: Ganesh Ajjanagadde > --- > libavutil/lfg.c | 33 - > libavutil/lfg.h | 26 ++ > 2 files changed, 58 insertions(+), 1 deletion(-) why do you add this code to lfg.* (Lagged Fibonacci Generator)? its not a lfg also the LFG could be trivially extended/changed to 64bit if one wants only needs uint64_t being used also theres av_mlfg_get() which passes all tests, though slower of course and does xorshift128+ really pass all tests ? what if the bits are reversed so that the least significant and most significant are exchanged ? the text seems unclear about that anyway, iam fine with the addition of xorshift128plus but please put it in a different file above questions are more due to curiousity and not a objection [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '81306fd4bdeb5c17d4db771e4fec684773b5790f'
On 16-02-16 at 17:27, Derek Buitenhuis wrote:
> ffmpeg | branch: master | Derek Buitenhuis | Tue
> Feb 16 16:26:49 2016 +| [d0fc5de3a643fe7f974ed14e410c2ac2f4147d7e] |
> committer: Derek Buitenhuis
>
> Merge commit '81306fd4bdeb5c17d4db771e4fec684773b5790f'
>
> * commit '81306fd4bdeb5c17d4db771e4fec684773b5790f':
> hls: eliminate ffurl_* usage
>
> Merged-by: Derek Buitenhuis
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d0fc5de3a643fe7f974ed14e410c2ac2f4147d7e
> ---
At least this change in hls.c seems to be incorrect, it breaks setting
the user-agent option for hls. Initially the correct user agent is used
when querying the hls, but when refreshing the playlist the user agent
is reset to Lavf/57.25.100. Reverting this specific hunk seems to fix
the issue. I assume the other changed call to update_options in open_url
is also broken, but didn't test.
diff --git a/libavformat/hls.c b/libavformat/hls.c
index fc1ff38..762e140 100644 (file)
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -1513,7 +1486,7 @@ static int save_avio_options(AVFormatContext *s)
static int hls_read_header(AVFormatContext *s)
{
-URLContext *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb->opaque;
+void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb->opaque;
HLSContext *c = s->priv_data;
int ret = 0, i, j, stream_offset = 0;
@@ -1525,19 +1498,18 @@ static int hls_read_header(AVFormatContext *s)
c->first_timestamp = AV_NOPTS_VALUE;
c->cur_timestamp = AV_NOPTS_VALUE;
-// if the URL context is good, read important options we must broker later
-if (u && u->prot->priv_data_class) {
+if (u) {
// get the previous user agent & set back to null if string size is
zero
-update_options(&c->user_agent, "user-agent", u->priv_data);
+update_options(&c->user_agent, "user-agent", u);
// get the previous cookies & set back to null if string size is zero
-update_options(&c->cookies, "cookies", u->priv_data);
+update_options(&c->cookies, "cookies", u);
// get the previous headers & set back to null if string size is zero
-update_options(&c->headers, "headers", u->priv_data);
+update_options(&c->headers, "headers", u);
// get the previous http proxt & set back to null if string size is
zero
-update_options(&c->http_proxy, "http_proxy", u->priv_data);
+update_options(&c->http_proxy, "http_proxy", u);
}
--
Simon Thelen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Merge commit of libav f8c34f4b8d62afad3f63cf3d9617d73735bef8c1
Luca Barbato from the libav project has apparently fixed the banding artifacts in Intel Video. Now I don't know how to contribute a merge commit. I would be thankful for some help, or if someone else would be willing to apply this one. Libav commit ID is f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 once again. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Merge commit of libav f8c34f4b8d62afad3f63cf3d9617d73735bef8c1
On 03/14/2016 05:25 AM, Mats Peterson wrote: Luca Barbato from the libav project has apparently fixed the banding artifacts in Intel Video. Now I don't know how to contribute a merge commit. I would be thankful for some help, or if someone else would be willing to apply this one. Libav commit ID is f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 once again. Mats The change concerns libavcodec/indeo2.c and libavcodec/indeo2data.h, for the record. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Merge commit of libav f8c34f4b8d62afad3f63cf3d9617d73735bef8c1
On 03/14/2016 05:33 AM, Mats Peterson wrote: On 03/14/2016 05:25 AM, Mats Peterson wrote: Luca Barbato from the libav project has apparently fixed the banding artifacts in Intel Video. Now I don't know how to contribute a merge commit. I would be thankful for some help, or if someone else would be willing to apply this one. Libav commit ID is f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 once again. Mats The change concerns libavcodec/indeo2.c and libavcodec/indeo2data.h, for the record. Mats There's still some banding, but it's much less washed-out than before. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Merge commit of libav f8c34f4b8d62afad3f63cf3d9617d73735bef8c1
On 03/14/2016 05:59 AM, Mats Peterson wrote: On 03/14/2016 05:33 AM, Mats Peterson wrote: On 03/14/2016 05:25 AM, Mats Peterson wrote: Luca Barbato from the libav project has apparently fixed the banding artifacts in Intel Video. Now I don't know how to contribute a merge commit. I would be thankful for some help, or if someone else would be willing to apply this one. Libav commit ID is f8c34f4b8d62afad3f63cf3d9617d73735bef8c1 once again. Mats The change concerns libavcodec/indeo2.c and libavcodec/indeo2data.h, for the record. Mats There's still some banding, but it's much less washed-out than before. Mats Sample Intel Realtime Video 2.1 (RT21) files are here: https://drive.google.com/open?id=0B3_pEBoLs0faei1Sd1h6SG11QlE Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
