Re: [FFmpeg-devel] [PATCH 1/3] avcodec/nvenc: Fix b-frame parameter handling
>> +/* 0 is intra-only, 1 is I/P only, 2 is one B Frame, 3 two B frames, >> and so on. */ >> +ctx->encode_config.frameIntervalP = avctx->max_b_frames + 1; > > how can the user choose between intra only and IP ? > > i would have assumed that gop_size <= 1 would select intra only > max_b_frames goes from -1 to INT_MAX, so -1 would be intra-only, 0, the default, I/P only, 1 IBP, 2 IBBP, and so on. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Question about supported_fps in libavutil/timecode.c::check_fps
On 24.01.2015, at 21:09, wm4 wrote: > On Sat, 24 Jan 2015 18:37:01 + > Derek Buitenhuis wrote: > >> On 1/24/2015 4:33 PM, wm4 wrote: >>> Which ones? We even expect C99 support from the compiler. >> >> Doesn't matter. It's the project's policy to have decls at >> block beginnings. Yes some of us think it's better. >> >> We know you don't. Don't start an ideological troll war. > > Having dumb policies is fine, but then don't use broken compilers as > excuse. Just say it's your policy to do it this way, even if there's no > technical necessity. Maybe not really relevant, but since I wrote it... Skip it unless you have time to waste ;) I guess it's an old habit from when we still used to support gcc 2.95 :) Which btw last I tried some months ago still worked except for very few cases. Thing is, we require not that much of C99 and most is header or preprocessor-related or used very, very rarely. And while I don't know where they come from, every now and then I hear about someone asking for C89 support for some product (possibly custom in-house compilers for strange architectures/OS? Symbian maybe still hiding in some hole?). But with even tinycc supporting it I guess it's reasonable to say that any "technical" reasons that might exist are more related to someone's laziness than a real technical reason. That said, I still prefer it even though I write C++ every day. Maybe it's just an old habit and secretly longing back to writing PASCAL as in my childhood days ;) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On 25.01.2015, at 03:08, Michael Niedermayer wrote: > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: >> As an experienced API user, I don't have the slightest clue what I'd do with this API, or where to find information about it. >>> >>> the primary goal is to remove duplicated disposition type tables, >>> which needs one of the tables to be public first >>> >>> [...] >> >> And this is the most awkward way you could find to do this? > > No, i could certainly find a more akward way, if people prefer > > this is just the way that would be a big step towards consistent > and simple access to the structs > All public structs use AVClass and AVOptions to allow applications > to extract/enumerate fields except a few like AVStream > this patch would add these AVClass & AVOption for AVStream, its > indeed not populated for all fields and AVStream doesnt have a > AVClass as its first field due to ABI. But its a step toward it > > Would people prefer that each field in AVStream has a custom and > different way to access it, as long as it looks simpler when looked > at in isolation ? Sorry if it's useless of me to only state some obvious questions, but: I think it's clear we all want a simple, obvious and consistent API :) If it's a bit messy, might there be a point in holding off a bit so we aren't stuck with something complicated? Could possibly another approach after a major bump be nicer? Or maybe better documentation/examples? I think this started with a valid complaint/concern but unfortunately no better alternative, could we stick to considering that instead of going over to agressive rhethoric? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/7] hevc: pass the full HEVCNAL struct to decode_nal_unit
This enables decode_nal_unit to access additional fields added in
subsequent commits.
---
libavcodec/hevc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 2bd89ec..8f60b3d 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2580,13 +2580,13 @@ fail:
return ret;
}
-static int decode_nal_unit(HEVCContext *s, const uint8_t *nal, int length)
+static int decode_nal_unit(HEVCContext *s, const HEVCNAL *nal)
{
HEVCLocalContext *lc = s->HEVClc;
GetBitContext *gb= &lc->gb;
int ctb_addr_ts, ret;
-ret = init_get_bits8(gb, nal, length);
+ret = init_get_bits8(gb, nal->data, nal->size);
if (ret < 0)
return ret;
@@ -2685,7 +2685,7 @@ static int decode_nal_unit(HEVCContext *s, const uint8_t
*nal, int length)
}
if (s->threads_number > 1 && s->sh.num_entry_point_offsets > 0)
-ctb_addr_ts = hls_slice_data_wpp(s, nal, length);
+ctb_addr_ts = hls_slice_data_wpp(s, nal->data, nal->size);
else
ctb_addr_ts = hls_slice_data(s);
if (ctb_addr_ts >= (s->sps->ctb_width * s->sps->ctb_height)) {
@@ -2937,7 +2937,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t
*buf, int length)
s->skipped_bytes = s->skipped_bytes_nal[i];
s->skipped_bytes_pos = s->skipped_bytes_pos_nal[i];
-ret = decode_nal_unit(s, s->nals[i].data, s->nals[i].size);
+ret = decode_nal_unit(s, &s->nals[i]);
if (ret < 0) {
av_log(s->avctx, AV_LOG_WARNING,
"Error parsing NAL unit #%d.\n", i);
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/7] hevc: store the escaped/raw bitstream in HEVCNAL
Hardware Accelerators require access to the escaped bitstream.
---
libavcodec/hevc.c | 8 ++--
libavcodec/hevc.h | 3 +++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 8f60b3d..bcbb889 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2772,8 +2772,10 @@ int ff_hevc_extract_rbsp(HEVCContext *s, const uint8_t
*src, int length,
#endif /* HAVE_FAST_UNALIGNED */
if (i >= length - 1) { // no escaped 0
-nal->data = src;
-nal->size = length;
+nal->data =
+nal->raw_data = src;
+nal->size =
+nal->raw_size = length;
return length;
}
@@ -2823,6 +2825,8 @@ nsc:
nal->data = dst;
nal->size = di;
+nal->raw_data = src;
+nal->raw_size = si;
return si;
}
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 8fdefbb..c0fad27 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -734,6 +734,9 @@ typedef struct HEVCNAL {
int size;
const uint8_t *data;
+
+int raw_size;
+const uint8_t *raw_data;
} HEVCNAL;
typedef struct HEVCLocalContext {
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/7] hevc: store the short term rps flag and size in the context
For future use by hardware accelerators.
---
libavcodec/hevc.c | 8 +---
libavcodec/hevc.h | 2 ++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index bcbb889..1a908d5 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -474,7 +474,7 @@ static int hls_slice_header(HEVCContext *s)
sh->colour_plane_id = get_bits(gb, 2);
if (!IS_IDR(s)) {
-int short_term_ref_pic_set_sps_flag, poc;
+int poc;
sh->pic_order_cnt_lsb = get_bits(gb, s->sps->log2_max_poc_lsb);
poc = ff_hevc_compute_poc(s, sh->pic_order_cnt_lsb);
@@ -487,12 +487,14 @@ static int hls_slice_header(HEVCContext *s)
}
s->poc = poc;
-short_term_ref_pic_set_sps_flag = get_bits1(gb);
-if (!short_term_ref_pic_set_sps_flag) {
+sh->short_term_ref_pic_set_sps_flag = get_bits1(gb);
+if (!sh->short_term_ref_pic_set_sps_flag) {
+int pos = get_bits_left(gb);
ret = ff_hevc_decode_short_term_rps(s, &sh->slice_rps, s->sps,
1);
if (ret < 0)
return ret;
+sh->short_term_ref_pic_set_size = pos - get_bits_left(gb);
sh->short_term_rps = &sh->slice_rps;
} else {
int numbits, rps_idx;
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index c0fad27..8555d47 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -575,6 +575,8 @@ typedef struct SliceHeader {
uint8_t colour_plane_id;
///< RPS coded in the slice header itself is stored here
+int short_term_ref_pic_set_sps_flag;
+int short_term_ref_pic_set_size;
ShortTermRPS slice_rps;
const ShortTermRPS *short_term_rps;
LongTermRPS long_term_rps;
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/7] hevc: reindent after previous commit
---
libavcodec/hevc.c | 38 +++---
libavcodec/hevc_refs.c | 24
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 71cb9b4..7173c10 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2706,18 +2706,18 @@ static int decode_nal_unit(HEVCContext *s, const
HEVCNAL *nal)
if (ret < 0)
goto fail;
} else {
-if (s->threads_number > 1 && s->sh.num_entry_point_offsets > 0)
-ctb_addr_ts = hls_slice_data_wpp(s, nal->data, nal->size);
-else
-ctb_addr_ts = hls_slice_data(s);
-if (ctb_addr_ts >= (s->sps->ctb_width * s->sps->ctb_height)) {
-s->is_decoded = 1;
-}
+if (s->threads_number > 1 && s->sh.num_entry_point_offsets > 0)
+ctb_addr_ts = hls_slice_data_wpp(s, nal->data, nal->size);
+else
+ctb_addr_ts = hls_slice_data(s);
+if (ctb_addr_ts >= (s->sps->ctb_width * s->sps->ctb_height)) {
+s->is_decoded = 1;
+}
-if (ctb_addr_ts < 0) {
-ret = ctb_addr_ts;
-goto fail;
-}
+if (ctb_addr_ts < 0) {
+ret = ctb_addr_ts;
+goto fail;
+}
}
break;
case NAL_EOS_NUT:
@@ -3077,16 +3077,16 @@ static int hevc_decode_frame(AVCodecContext *avctx,
void *data, int *got_output,
av_log(avctx, AV_LOG_ERROR,
"hardware accelerator failed to decode picture\n");
} else {
-/* verify the SEI checksum */
-if (avctx->err_recognition & AV_EF_CRCCHECK && s->is_decoded &&
-s->is_md5) {
-ret = verify_md5(s, s->ref->frame);
-if (ret < 0 && avctx->err_recognition & AV_EF_EXPLODE) {
-ff_hevc_unref_frame(s, s->ref, ~0);
-return ret;
+/* verify the SEI checksum */
+if (avctx->err_recognition & AV_EF_CRCCHECK && s->is_decoded &&
+s->is_md5) {
+ret = verify_md5(s, s->ref->frame);
+if (ret < 0 && avctx->err_recognition & AV_EF_EXPLODE) {
+ff_hevc_unref_frame(s, s->ref, ~0);
+return ret;
+}
}
}
-}
s->is_md5 = 0;
if (s->is_decoded) {
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index c705f11..8f61cf6 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -407,18 +407,18 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s,
int poc)
return NULL;
if (!s->avctx->hwaccel) {
-if (!s->sps->pixel_shift) {
-for (i = 0; frame->frame->buf[i]; i++)
-memset(frame->frame->buf[i]->data, 1 << (s->sps->bit_depth - 1),
- frame->frame->buf[i]->size);
-} else {
-for (i = 0; frame->frame->data[i]; i++)
-for (y = 0; y < (s->sps->height >> s->sps->vshift[i]); y++)
-for (x = 0; x < (s->sps->width >> s->sps->hshift[i]); x++) {
-AV_WN16(frame->frame->data[i] + y *
frame->frame->linesize[i] + 2 * x,
-1 << (s->sps->bit_depth - 1));
-}
-}
+if (!s->sps->pixel_shift) {
+for (i = 0; frame->frame->buf[i]; i++)
+memset(frame->frame->buf[i]->data, 1 << (s->sps->bit_depth -
1),
+ frame->frame->buf[i]->size);
+} else {
+for (i = 0; frame->frame->data[i]; i++)
+for (y = 0; y < (s->sps->height >> s->sps->vshift[i]); y++)
+for (x = 0; x < (s->sps->width >> s->sps->hshift[i]); x++)
{
+AV_WN16(frame->frame->data[i] + y *
frame->frame->linesize[i] + 2 * x,
+1 << (s->sps->bit_depth - 1));
+}
+}
}
frame->poc = poc;
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/7] hevc: add hwaccel hooks
---
libavcodec/hevc.c | 38 --
libavcodec/hevc.h | 3 +++
libavcodec/hevc_refs.c | 18 ++
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 1a908d5..71cb9b4 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -300,6 +300,8 @@ static int get_buffer_sao(HEVCContext *s, AVFrame *frame,
const HEVCSPS *sps)
static int set_sps(HEVCContext *s, const HEVCSPS *sps)
{
+#define HWACCEL_MAX (0)
+enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
int ret;
unsigned int num = 0, den = 0;
@@ -312,9 +314,16 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
s->avctx->coded_height= sps->height;
s->avctx->width = sps->output_width;
s->avctx->height = sps->output_height;
-s->avctx->pix_fmt = sps->pix_fmt;
s->avctx->has_b_frames= sps->temporal_layer[sps->max_sub_layers -
1].num_reorder_pics;
+*fmt++ = sps->pix_fmt;
+*fmt = AV_PIX_FMT_NONE;
+
+ret = ff_thread_get_format(s->avctx, pix_fmts);
+if (ret < 0)
+goto fail;
+s->avctx->pix_fmt = ret;
+
ff_set_sar(s->avctx, sps->vui.sar);
if (sps->vui.video_signal_type_present_flag)
@@ -337,7 +346,7 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
ff_hevc_dsp_init (&s->hevcdsp, sps->bit_depth);
ff_videodsp_init (&s->vdsp,sps->bit_depth);
-if (sps->sao_enabled) {
+if (sps->sao_enabled && !s->avctx->hwaccel) {
av_frame_unref(s->tmp_frame);
ret = get_buffer_sao(s, s->tmp_frame, sps);
s->sao_frame = s->tmp_frame;
@@ -2686,6 +2695,17 @@ static int decode_nal_unit(HEVCContext *s, const HEVCNAL
*nal)
}
}
+if (s->sh.first_slice_in_pic_flag && s->avctx->hwaccel) {
+ret = s->avctx->hwaccel->start_frame(s->avctx, NULL, 0);
+if (ret < 0)
+goto fail;
+}
+
+if (s->avctx->hwaccel) {
+ret = s->avctx->hwaccel->decode_slice(s->avctx, nal->raw_data,
nal->raw_size);
+if (ret < 0)
+goto fail;
+} else {
if (s->threads_number > 1 && s->sh.num_entry_point_offsets > 0)
ctb_addr_ts = hls_slice_data_wpp(s, nal->data, nal->size);
else
@@ -2698,6 +2718,7 @@ static int decode_nal_unit(HEVCContext *s, const HEVCNAL
*nal)
ret = ctb_addr_ts;
goto fail;
}
+}
break;
case NAL_EOS_NUT:
case NAL_EOB_NUT:
@@ -3051,6 +3072,11 @@ static int hevc_decode_frame(AVCodecContext *avctx, void
*data, int *got_output,
if (ret < 0)
return ret;
+if (avctx->hwaccel) {
+if (s->ref && avctx->hwaccel->end_frame(avctx) < 0)
+av_log(avctx, AV_LOG_ERROR,
+ "hardware accelerator failed to decode picture\n");
+} else {
/* verify the SEI checksum */
if (avctx->err_recognition & AV_EF_CRCCHECK && s->is_decoded &&
s->is_md5) {
@@ -3060,6 +3086,7 @@ static int hevc_decode_frame(AVCodecContext *avctx, void
*data, int *got_output,
return ret;
}
}
+}
s->is_md5 = 0;
if (s->is_decoded) {
@@ -3103,6 +3130,13 @@ static int hevc_ref_frame(HEVCContext *s, HEVCFrame
*dst, HEVCFrame *src)
dst->flags = src->flags;
dst->sequence = src->sequence;
+if (src->hwaccel_picture_private) {
+dst->hwaccel_priv_buf = av_buffer_ref(src->hwaccel_priv_buf);
+if (!dst->hwaccel_priv_buf)
+goto fail;
+dst->hwaccel_picture_private = dst->hwaccel_priv_buf->data;
+}
+
return 0;
fail:
ff_hevc_unref_frame(s, dst, ~0);
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 8555d47..1727b60 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -718,6 +718,9 @@ typedef struct HEVCFrame {
AVBufferRef *rpl_tab_buf;
AVBufferRef *rpl_buf;
+AVBufferRef *hwaccel_priv_buf;
+void *hwaccel_picture_private;
+
/**
* A sequence counter, so that old frames are output first
* after a POC reset
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 92196a1..c705f11 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -21,6 +21,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "libavutil/avassert.h"
#include "libavutil/pixdesc.h"
#include "internal.h"
@@ -46,6 +47,9 @@ void ff_hevc_unref_frame(HEVCContext *s, HEVCFrame *frame,
int flags)
frame->refPicList = NULL;
frame->collocated_ref = NULL;
+
+av_buffer_unref(&frame->hwaccel_priv_buf);
+frame->hwaccel_picture_private = NULL;
}
}
@@ -106,6 +110,18 @@ static HEVCFrame *alloc_frame(HEVCContext *s)
frame->frame->top_field_first = s->picture_struct ==
AV_PICTURE_STRUCTURE_TOP_FIELD;
frame->frame
[FFmpeg-devel] [PATCH 6/7] Add DXVA2 HEVC HWAccel
---
configure | 5 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dxva2_hevc.c | 375
libavcodec/hevc.c | 8 +-
5 files changed, 389 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/dxva2_hevc.c
diff --git a/configure b/configure
index 0b6be39..871772a 100755
--- a/configure
+++ b/configure
@@ -1788,6 +1788,7 @@ TOOLCHAIN_FEATURES="
TYPES_LIST="
CONDITION_VARIABLE_Ptr
+DXVA_PicParams_HEVC
socklen_t
struct_addrinfo
struct_group_source_req
@@ -2293,6 +2294,8 @@ h264_vdpau_decoder_deps="vdpau"
h264_vdpau_decoder_select="h264_decoder"
h264_vdpau_hwaccel_deps="vdpau"
h264_vdpau_hwaccel_select="h264_decoder"
+hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
+hevc_dxva2_hwaccel_select="hevc_decoder"
mpeg_vdpau_decoder_deps="vdpau"
mpeg_vdpau_decoder_select="mpeg2video_decoder"
mpeg_xvmc_hwaccel_deps="xvmc"
@@ -4805,6 +4808,8 @@ check_lib2 "windows.h psapi.h" GetProcessMemoryInfo
-lpsapi
check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
+check_type "windows.h dxva.h" "DXVA_PicParams_HEVC"
+
if ! disabled w32threads && ! enabled pthreads; then
check_func_headers "windows.h process.h" _beginthreadex &&
enable w32threads || disable w32threads
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 80ee389..db8d45a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -665,6 +665,7 @@ OBJS-$(CONFIG_H264_DXVA2_HWACCEL) += dxva2_h264.o
OBJS-$(CONFIG_H264_VAAPI_HWACCEL) += vaapi_h264.o
OBJS-$(CONFIG_H264_VDA_HWACCEL) += vda_h264.o
OBJS-$(CONFIG_H264_VDPAU_HWACCEL) += vdpau_h264.o
+OBJS-$(CONFIG_HEVC_DXVA2_HWACCEL) += dxva2_hevc.o
OBJS-$(CONFIG_MPEG1_VDPAU_HWACCEL)+= vdpau_mpeg12.o
OBJS-$(CONFIG_MPEG1_XVMC_HWACCEL) += mpegvideo_xvmc.o
OBJS-$(CONFIG_MPEG2_DXVA2_HWACCEL)+= dxva2_mpeg2.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 29b45f3..2fe3609 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -81,6 +81,7 @@ void avcodec_register_all(void)
REGISTER_HWACCEL(H264_VDA, h264_vda);
REGISTER_HWACCEL(H264_VDA_OLD, h264_vda_old);
REGISTER_HWACCEL(H264_VDPAU,h264_vdpau);
+REGISTER_HWACCEL(HEVC_DXVA2,hevc_dxva2);
REGISTER_HWACCEL(MPEG1_XVMC,mpeg1_xvmc);
REGISTER_HWACCEL(MPEG1_VDPAU, mpeg1_vdpau);
REGISTER_HWACCEL(MPEG2_XVMC,mpeg2_xvmc);
diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
new file mode 100644
index 000..a9df5f4
--- /dev/null
+++ b/libavcodec/dxva2_hevc.c
@@ -0,0 +1,375 @@
+/*
+ * DXVA2 HEVC HW acceleration.
+ *
+ * copyright (c) 2014 - 2015 Hendrik Leppkes
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+
+#include "dxva2_internal.h"
+#include "hevc.h"
+
+#define MAX_SLICES 256
+
+struct hevc_dxva2_picture_context {
+DXVA_PicParams_HEVC pp;
+DXVA_Qmatrix_HEVC qm;
+unsigned slice_count;
+DXVA_Slice_HEVC_Short slice_short[MAX_SLICES];
+const uint8_t *bitstream;
+unsigned bitstream_size;
+};
+
+static void fill_picture_entry(DXVA_PicEntry_HEVC *pic,
+ unsigned index, unsigned flag)
+{
+av_assert0((index & 0x7f) == index && (flag & 0x01) == flag);
+pic->bPicEntry = index | (flag << 7);
+}
+
+static int get_refpic_index(const DXVA_PicParams_HEVC *pp, int surface_index)
+{
+int i;
+for (i = 0; i < FF_ARRAY_ELEMS(pp->RefPicList); i++) {
+if ((pp->RefPicList[i].bPicEntry & 0x7f) == surface_index)
+ return i;
+}
+return 0xff;
+}
+
+static void fill_picture_parameters(struct dxva_context *ctx, const
HEVCContext *h,
+DXVA_PicParams_HEVC *pp)
+{
+const HEVCFrame *current_picture = h->ref;
+int i, j, k;
+
+memset(pp, 0, sizeof(*pp));
+
+pp->PicWidthInMinCbsY = h->sps->min_cb_width;
+pp->PicHeightInMinCbsY = h->sps->min_cb_height;
+
+pp->wFormatAndSequenceInfoFlags = (h->sps->chroma_format_idc <<
0) |
+ (h->sps->separate_colou
Re: [FFmpeg-devel] [PATCH 1/7] hevc: pass the full HEVCNAL struct to decode_nal_unit
I forgot that this one was already applied, but it also didn't change in the new set, so no harm in re-sending it. Now it all lines up perfectly! The other patches got a few cosmetic changes, and one added error check in the "add hwaccel hooks" patch. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/7] ffmpeg_dxva2: add hevc support
---
ffmpeg_dxva2.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/ffmpeg_dxva2.c b/ffmpeg_dxva2.c
index 3c91d26..741c55b 100644
--- a/ffmpeg_dxva2.c
+++ b/ffmpeg_dxva2.c
@@ -52,6 +52,7 @@ DEFINE_GUID(DXVA2_ModeH264_F, 0x1b81be69,
0xa0c7,0x11d3,0xb9,0x84,0x00,0
DEFINE_GUID(DXVADDI_Intel_ModeH264_E, 0x604F8E68,
0x4951,0x4C54,0x88,0xFE,0xAB,0xD2,0x5C,0x15,0xB3,0xD6);
DEFINE_GUID(DXVA2_ModeVC1_D, 0x1b81beA3,
0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
DEFINE_GUID(DXVA2_ModeVC1_D2010, 0x1b81beA4,
0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
+DEFINE_GUID(DXVA2_ModeHEVC_VLD_Main, 0x5b11d51b,
0x2f4c,0x4452,0xbc,0xc3,0x09,0xf2,0xa1,0x16,0x0c,0xc0);
DEFINE_GUID(DXVA2_NoEncrypt, 0x1b81beD0,
0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
DEFINE_GUID(GUID_NULL,0x,
0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
@@ -80,6 +81,9 @@ static const dxva2_mode dxva2_modes[] = {
{ &DXVA2_ModeVC1_D, AV_CODEC_ID_VC1 },
{ &DXVA2_ModeVC1_D, AV_CODEC_ID_WMV3 },
+/* HEVC/H.265 */
+{ &DXVA2_ModeHEVC_VLD_Main, AV_CODEC_ID_HEVC },
+
{ NULL, 0 },
};
@@ -526,6 +530,10 @@ static int dxva2_create_decoder(AVCodecContext *s)
but it causes issues for H.264 on certain AMD GPUs. */
if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO)
surface_alignment = 32;
+/* the HEVC DXVA2 spec asks for 128 pixel aligned surfaces to ensure
+ all coding features have enough room to work with */
+else if (s->codec_id == AV_CODEC_ID_HEVC)
+surface_alignment = 128;
else
surface_alignment = 16;
@@ -533,7 +541,7 @@ static int dxva2_create_decoder(AVCodecContext *s)
ctx->num_surfaces = 4;
/* add surfaces based on number of possible refs */
-if (s->codec_id == AV_CODEC_ID_H264)
+if (s->codec_id == AV_CODEC_ID_H264 || s->codec_id == AV_CODEC_ID_HEVC)
ctx->num_surfaces += 16;
else
ctx->num_surfaces += 2;
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Döffinger wrote: > On 25.01.2015, at 03:08, Michael Niedermayer wrote: > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: > >> > > As an experienced API user, I don't have the slightest clue what I'd do > with this API, or where to find information about it. > >>> > >>> the primary goal is to remove duplicated disposition type tables, > >>> which needs one of the tables to be public first > >>> > >>> [...] > >> > >> And this is the most awkward way you could find to do this? > > > > No, i could certainly find a more akward way, if people prefer > > > > this is just the way that would be a big step towards consistent > > and simple access to the structs > > All public structs use AVClass and AVOptions to allow applications > > to extract/enumerate fields except a few like AVStream > > this patch would add these AVClass & AVOption for AVStream, its > > indeed not populated for all fields and AVStream doesnt have a > > AVClass as its first field due to ABI. But its a step toward it > > > > Would people prefer that each field in AVStream has a custom and > > different way to access it, as long as it looks simpler when looked > > at in isolation ? > > Sorry if it's useless of me to only state some obvious questions, but: > I think it's clear we all want a simple, obvious and consistent API :) > If it's a bit messy, might there be a point in holding off a bit so we aren't > stuck with something complicated? > Could possibly another approach after a major bump be nicer? > Or maybe better documentation/examples? > I think this started with a valid complaint/concern but unfortunately no > better alternative, could we stick to considering that instead of going over > to agressive rhethoric? absolutley i would strongly prefer if others could take this over, my interrest was just in the technical side and i wanted to move AVStream to the same system we use for all other structs. As well as fixing the quite valid issue nicolas had raised with the duplicated tables. I am quite surprised that others dont see this as a clear and uncontroversal step, there really are just 1. If we want AVStream to be consistent with other structs, that means AVOption & AVClass. And this patch is a step toward it, one could make a bigger or smaller step but its then either more or less code not different code. 2. There could be a different system be used for this field or for AVStream, this would be inconsistent 3. We can implement both a system based on AVOptions/AVClass and a system without them, why would this field that noone cared about until now need this, iam not sure though 4. We can leave the triplicated tables as is and hope not to forget updating them in sync To me the best choice is clear, move toward the same system we use elsewhere. Change that system everywhere if it could be improved I see nothing controversal on this patch but others do apparently. As i dont see what issue people have with this, i certainly cannot help fixing the patch. But iam happy to review & approve the solution that people do prefer [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote: > On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Döffinger wrote: > > On 25.01.2015, at 03:08, Michael Niedermayer wrote: > > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: > > >> > > > > As an experienced API user, I don't have the slightest clue what I'd do > > with this API, or where to find information about it. > > >>> > > >>> the primary goal is to remove duplicated disposition type tables, > > >>> which needs one of the tables to be public first > > >>> > > >>> [...] > > >> > > >> And this is the most awkward way you could find to do this? > > > > > > No, i could certainly find a more akward way, if people prefer > > > > > > this is just the way that would be a big step towards consistent > > > and simple access to the structs > > > All public structs use AVClass and AVOptions to allow applications > > > to extract/enumerate fields except a few like AVStream > > > this patch would add these AVClass & AVOption for AVStream, its > > > indeed not populated for all fields and AVStream doesnt have a > > > AVClass as its first field due to ABI. But its a step toward it > > > > > > Would people prefer that each field in AVStream has a custom and > > > different way to access it, as long as it looks simpler when looked > > > at in isolation ? > > > > Sorry if it's useless of me to only state some obvious questions, but: > > I think it's clear we all want a simple, obvious and consistent API :) > > If it's a bit messy, might there be a point in holding off a bit so we > > aren't stuck with something complicated? > > Could possibly another approach after a major bump be nicer? > > Or maybe better documentation/examples? > > > I think this started with a valid complaint/concern but unfortunately no > > better alternative, could we stick to considering that instead of going > > over to agressive rhethoric? > > absolutley > i would strongly prefer if others could take this over, my interrest > was just in the technical side and i wanted to move AVStream to > the same system we use for all other structs. As well as fixing the > quite valid issue nicolas had raised with the duplicated tables. > I am quite surprised that others dont see this as a clear and > uncontroversal step, there really are just > 1. If we want AVStream to be consistent with other structs, that means >AVOption & AVClass. And this patch is a step toward it, one could >make a bigger or smaller step but its then either more or less >code not different code. > 2. There could be a different system be used for this field or for >AVStream, this would be inconsistent > 3. We can implement both a system based on AVOptions/AVClass and a >system without them, why would this field that noone cared about >until now need this, iam not sure though > 4. We can leave the triplicated tables as is and hope not to forget >updating them in sync > > To me the best choice is clear, move toward the same system we use > elsewhere. Change that system everywhere if it could be improved > I see nothing controversal on this patch but others do apparently. > As i dont see what issue people have with this, i certainly cannot > help fixing the patch. But iam happy to review & approve the solution > that people do prefer About the documentation & example side, i dont think this should yet be used from outside, its only a partial implementation of AVOption for AVStream, a full implementation needs a ABI bump due to the first field needing to be a AVClass [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/nvenc: Fix b-frame parameter handling
On Sun, Jan 25, 2015 at 10:28:22AM +0100, Timo Rothenpieler wrote: > >> +/* 0 is intra-only, 1 is I/P only, 2 is one B Frame, 3 two B frames, > >> and so on. */ > >> +ctx->encode_config.frameIntervalP = avctx->max_b_frames + 1; > > > > how can the user choose between intra only and IP ? > > > > i would have assumed that gop_size <= 1 would select intra only > > > > max_b_frames goes from -1 to INT_MAX, so -1 would be intra-only, 0, the > default, I/P only, 1 IBP, 2 IBBP, and so on. In libavcodec, intra only is selected by setting gop_size to 0 which is what happens when -intra is passed on the commad line to ffmpeg. Also other applications using libavcodec will use the gop_size and not contain code to change max_b_frames in the nvenc case so i dont think using max_b_frames would work very well [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/sbrdsp: add ff_sbr_autocorrelate_{sse, sse3}
Hi, 2015-01-25 2:05 GMT+01:00 James Almer : > 2 to 2.5 times faster. > > Signed-off-by: James Almer > --- > libavcodec/x86/sbrdsp.asm| 114 > +++ Not the first time that I notice that, but memmoves are often suboptimal using old SSE ones. While movlhps is fine, movlps isn't, on my old core i5. You may want to validate this with the attached patch, where storing ps_mask3 in m8 is a gain in Win64 (the gain does not match the number of loops, but it is still there). Benchmarks: x64: 6023 decicycles in g, 262108 runs, 36 skips SSE: 3049 decicycles in g, 262130 runs, 14 skips SSE3: 2843 decicycles in g, 262086 runs, 58 skips movq: 2693 decicycles in g, 262117 runs, 27 skips m8: 2648 decicycles in g, 262083 runs, 61 skips Thanks for doing it, I had only 3yo scraps left and no further motivation to tackle the start/tail parts. -- Christophe From 49e41dd86eb65a774f3561420dd5e9de83f328f2 Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Sun, 25 Jan 2015 13:52:16 +0100 Subject: [PATCH 2/2] Use different mem moves. --- libavcodec/x86/sbrdsp.asm | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/libavcodec/x86/sbrdsp.asm b/libavcodec/x86/sbrdsp.asm index c9f2d88..955d6cc 100644 --- a/libavcodec/x86/sbrdsp.asm +++ b/libavcodec/x86/sbrdsp.asm @@ -448,19 +448,27 @@ cglobal sbr_qmf_deint_neg, 2,4,4,v,src,vrev,c REP_RET %macro SBR_AUTOCORRELATE 0 -cglobal sbr_autocorrelate, 2,3,8,32, x, phi, cnt +cglobal sbr_autocorrelate, 2,3,8+ARCH_X86_64,32, x, phi, cnt movcntq, 37*8 addxq, cntq negcntq +%if ARCH_X86_64 +mova m8, [ps_mask3] +%define MASK m8 +%else +%define MASK [ps_mask3] +%endif %if cpuflag(sse3) +%define MOVH movq movddup m5, [xq+cntq] %else +%define MOVH movlps movlps m5, [xq+cntq] movlhps m5, m5 %endif -movlps m7, [xq+cntq+8 ] -movlps m1, [xq+cntq+16] +MOVHm7, [xq+cntq+8 ] +MOVHm1, [xq+cntq+16] shufps m7, m7, q0110 shufps m1, m1, q0110 mulps m3, m5, m7 ; x[0][0] * x[1][0], x[0][1] * x[1][1], x[0][0] * x[1][1], x[0][1] * x[1][0] @@ -470,7 +478,7 @@ cglobal sbr_autocorrelate, 2,3,8,32, x, phi, cnt movaps [rsp+16], m4 add cntq, 8 -movlps m2, [xq+cntq+16] +MOVHm2, [xq+cntq+16] movlhps m7, m7 shufps m2, m2, q0110 mulps m6, m7, m1 ; real_sum1 = x[1][0] * x[2][0], x[1][1] * x[2][1], x[1][0] * x[2][1], x[1][1] * x[2][0] @@ -481,7 +489,7 @@ cglobal sbr_autocorrelate, 2,3,8,32, x, phi, cnt align 16 .loop: add cntq, 8 -movlps m0, [xq+cntq+16] +MOVHm0, [xq+cntq+16] movlhps m1, m1 shufps m0, m0, q0110 mulps m3, m1, m2 @@ -491,7 +499,7 @@ align 16 addps m5, m4 ; real_sum2 += x[i][0] * x[i + 2][0], x[i][1] * x[i + 2][1], x[i][0] * x[i + 2][1], x[i][1] * x[i + 2][0]; addps m7, m1 ; real_sum0 += x[i][0] * x[i][0], x[i][1] * x[i][1]; add cntq, 8 -movlps m1, [xq+cntq+16] +MOVHm1, [xq+cntq+16] movlhps m2, m2 shufps m1, m1, q0110 mulps m3, m2, m0 @@ -501,7 +509,7 @@ align 16 addps m5, m4 ; real_sum2 += x[i][0] * x[i + 2][0], x[i][1] * x[i + 2][1], x[i][0] * x[i + 2][1], x[i][1] * x[i + 2][0]; addps m7, m2 ; real_sum0 += x[i][0] * x[i][0], x[i][1] * x[i][1]; add cntq, 8 -movlps m2, [xq+cntq+16] +MOVHm2, [xq+cntq+16] movlhps m0, m0 shufps m2, m2, q0110 mulps m3, m0, m1 @@ -520,9 +528,9 @@ align 16 addps m6, [rsp ] ; real_sum1 + x[ 0][0] * x[ 1][0] + x[ 0][1] * x[ 1][1]; imag_sum1 + x[ 0][0] * x[ 1][1] - x[ 0][1] * x[ 1][0]; addps m7, [rsp+16] ; real_sum0 + x[ 0][0] * x[ 0][0] + x[ 0][1] * x[ 0][1]; -xorps m4, [ps_mask3] -xorps m5, [ps_mask3] -xorps m6, [ps_mask3] +xorps m4, MASK +xorps m5, MASK +xorps m6, MASK %if cpuflag(sse3) movshdup m2, m1 haddps m4, m5 -- 1.9.2.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: support MSYS2
MSYS2 uses a system name of "MSYS_NT-6.3" instead of "MINGW32_NT-6.3" in MSYS1.
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 0b6be39..eacacdf 100755
--- a/configure
+++ b/configure
@@ -3097,7 +3097,7 @@ fi
exesuf() {
case $1 in
-mingw32*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo
.exe ;;
+
mingw32*|msys*|win32|win64|cygwin*|*-dos|freedos|opendos|os/2*|symbian) echo
.exe ;;
esac
}
@@ -4060,7 +4060,7 @@ case $target_os in
enabled_any pic shared ||
{ check_cflags -mdynamic-no-pic && add_asflags -mdynamic-no-pic; }
;;
-mingw32*)
+mingw32*|msys*)
if test $target_os = "mingw32ce"; then
disable network
else
--
1.9.5.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes wrote: > MSYS2 uses a system name of "MSYS_NT-6.3" instead of "MINGW32_NT-6.3" in > MSYS1. > Apparently this isn't quite correct, and you have to start MSYS2 with a special batch file that overrides this for you. Just running bash.exe or sh.exe from a DOS prompt results in this and is apparently considered "wrong usage". Oh well. I think I'll stick to my simpler MSYS1 world. So disregard this patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes > wrote: > > > MSYS2 uses a system name of "MSYS_NT-6.3" instead of "MINGW32_NT-6.3" in > > MSYS1. > > > > Apparently this isn't quite correct, and you have to start MSYS2 with a > special batch file that overrides this for you. > Just running bash.exe or sh.exe from a DOS prompt results in this and is > apparently considered "wrong usage". I don't really see anything wrong with this, however I'd rather have a compiler-based detection. I.e. if the compiler define __MINGW32__ set the host to mingw (unless set explicitly). This should also address my other annoyance that you have to specify --host when it really should be obvious that you are cross-compiling to MINGW for example. If nobody else cares about it I might work on it. And if you have objections, now is a good time. Because I've dropped enough variants of this because nobody cares even though it's a constant annoyance as seen by the various issues and different patches that all go back to our configure being too stupid to figure out on its own what is compiling for even when it should be obvious. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options
On Thu, Jan 22, 2015 at 03:49:09PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> On 22.01.2015 15:31, wm4 wrote:
> >If the build date is not correct, then what value does the build date
> >have at all?
>
> How do you know it is 'correct' currently?
> One can change the system clock (or use faketime).
And someone could hand-edit the revision number...
I think we have to assume non-maliciousness, otherwise it's all
pointless.
> What value has the 'correct' build date?
> If you build an ffmpeg version from a year ago today it will contain the
> current date. That's rather misleading.
As it is the build date I see nothing misleading about that at all.
I would buy the argument though that having the build date at all
is useless and should be removed.
> With the --build-{date,time} options one can specify meaningful values such
> as the time of the last change to the source.
Then it's not the build date.
If we want a last-changed-date we should change it to
that.
But having a build date that in Debian actually is the
last-source-change date, except when something goes
wrong and it's something completely wrong seems to me
to defeat the purpose (assuming there is one in the first place).
I vote for just removing the build date.
As an alternative I vote to change it to use the date of
the last commit if the source tree is clean and has git info
available, current date otherwise.
What do others think?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On Sun, 25 Jan 2015 13:39:10 +0100 Michael Niedermayer wrote: > On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote: > > On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Döffinger wrote: > > > On 25.01.2015, at 03:08, Michael Niedermayer wrote: > > > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: > > > >> > > > > > > As an experienced API user, I don't have the slightest clue what I'd > > > do > > > with this API, or where to find information about it. > > > >>> > > > >>> the primary goal is to remove duplicated disposition type tables, > > > >>> which needs one of the tables to be public first > > > >>> > > > >>> [...] > > > >> > > > >> And this is the most awkward way you could find to do this? > > > > > > > > No, i could certainly find a more akward way, if people prefer > > > > > > > > this is just the way that would be a big step towards consistent > > > > and simple access to the structs > > > > All public structs use AVClass and AVOptions to allow applications > > > > to extract/enumerate fields except a few like AVStream > > > > this patch would add these AVClass & AVOption for AVStream, its > > > > indeed not populated for all fields and AVStream doesnt have a > > > > AVClass as its first field due to ABI. But its a step toward it > > > > > > > > Would people prefer that each field in AVStream has a custom and > > > > different way to access it, as long as it looks simpler when looked > > > > at in isolation ? > > > > > > Sorry if it's useless of me to only state some obvious questions, but: > > > I think it's clear we all want a simple, obvious and consistent API :) > > > If it's a bit messy, might there be a point in holding off a bit so we > > > aren't stuck with something complicated? > > > Could possibly another approach after a major bump be nicer? > > > Or maybe better documentation/examples? > > > > > I think this started with a valid complaint/concern but unfortunately no > > > better alternative, could we stick to considering that instead of going > > > over to agressive rhethoric? > > > > absolutley > > i would strongly prefer if others could take this over, my interrest > > was just in the technical side and i wanted to move AVStream to > > the same system we use for all other structs. As well as fixing the > > quite valid issue nicolas had raised with the duplicated tables. > > I am quite surprised that others dont see this as a clear and > > uncontroversal step, there really are just > > 1. If we want AVStream to be consistent with other structs, that means > >AVOption & AVClass. And this patch is a step toward it, one could > >make a bigger or smaller step but its then either more or less > >code not different code. > > 2. There could be a different system be used for this field or for > >AVStream, this would be inconsistent > > 3. We can implement both a system based on AVOptions/AVClass and a > >system without them, why would this field that noone cared about > >until now need this, iam not sure though > > 4. We can leave the triplicated tables as is and hope not to forget > >updating them in sync > > > > To me the best choice is clear, move toward the same system we use > > elsewhere. Change that system everywhere if it could be improved > > I see nothing controversal on this patch but others do apparently. > > As i dont see what issue people have with this, i certainly cannot > > help fixing the patch. But iam happy to review & approve the solution > > that people do prefer > > About the documentation & example side, i dont think this should yet > be used from outside, its only a partial implementation of AVOption > for AVStream, a full implementation needs a ABI bump due to the > first field needing to be a AVClass > > [...] > How is it even consistent with "other structs"? Doesn't it just resolve flags? Resolving flags with a complicated AVOption contraption (which every user has to understand and duplicate) doesn't seem like a good choice to me at all. I hear about API users fighting with the basics of the FFmpeg API because it's so weird and complicated; seeing patches like this just feel like a bad joke in contrast. What's wrong with: int av_parse_disposition_flags(const char *s); ? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On 1/25/15, wm4 wrote: > On Sun, 25 Jan 2015 13:39:10 +0100 > Michael Niedermayer wrote: > >> On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote: >> > On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Doeffinger wrote: >> > > On 25.01.2015, at 03:08, Michael Niedermayer wrote: >> > > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: >> > > >> >> > > >> > > As an experienced API user, I don't have the slightest clue what >> > > I'd do >> > > with this API, or where to find information about it. >> > > >>> >> > > >>> the primary goal is to remove duplicated disposition type tables, >> > > >>> which needs one of the tables to be public first >> > > >>> >> > > >>> [...] >> > > >> >> > > >> And this is the most awkward way you could find to do this? >> > > > >> > > > No, i could certainly find a more akward way, if people prefer >> > > > >> > > > this is just the way that would be a big step towards consistent >> > > > and simple access to the structs >> > > > All public structs use AVClass and AVOptions to allow applications >> > > > to extract/enumerate fields except a few like AVStream >> > > > this patch would add these AVClass & AVOption for AVStream, its >> > > > indeed not populated for all fields and AVStream doesnt have a >> > > > AVClass as its first field due to ABI. But its a step toward it >> > > > >> > > > Would people prefer that each field in AVStream has a custom and >> > > > different way to access it, as long as it looks simpler when looked >> > > > at in isolation ? >> > > >> > > Sorry if it's useless of me to only state some obvious questions, but: >> > > I think it's clear we all want a simple, obvious and consistent API :) >> > > If it's a bit messy, might there be a point in holding off a bit so we >> > > aren't stuck with something complicated? >> > > Could possibly another approach after a major bump be nicer? >> > > Or maybe better documentation/examples? >> > >> > > I think this started with a valid complaint/concern but unfortunately >> > > no better alternative, could we stick to considering that instead of >> > > going over to agressive rhethoric? >> > >> > absolutley >> > i would strongly prefer if others could take this over, my interrest >> > was just in the technical side and i wanted to move AVStream to >> > the same system we use for all other structs. As well as fixing the >> > quite valid issue nicolas had raised with the duplicated tables. >> > I am quite surprised that others dont see this as a clear and >> > uncontroversal step, there really are just >> > 1. If we want AVStream to be consistent with other structs, that means >> >AVOption & AVClass. And this patch is a step toward it, one could >> >make a bigger or smaller step but its then either more or less >> >code not different code. >> > 2. There could be a different system be used for this field or for >> >AVStream, this would be inconsistent >> > 3. We can implement both a system based on AVOptions/AVClass and a >> >system without them, why would this field that noone cared about >> >until now need this, iam not sure though >> > 4. We can leave the triplicated tables as is and hope not to forget >> >updating them in sync >> > >> > To me the best choice is clear, move toward the same system we use >> > elsewhere. Change that system everywhere if it could be improved >> > I see nothing controversal on this patch but others do apparently. >> > As i dont see what issue people have with this, i certainly cannot >> > help fixing the patch. But iam happy to review & approve the solution >> > that people do prefer >> >> About the documentation & example side, i dont think this should yet >> be used from outside, its only a partial implementation of AVOption >> for AVStream, a full implementation needs a ABI bump due to the >> first field needing to be a AVClass >> >> [...] >> > > How is it even consistent with "other structs"? Doesn't it just resolve > flags? Resolving flags with a complicated AVOption contraption (which > every user has to understand and duplicate) doesn't seem like a good > choice to me at all. I hear about API users fighting with the basics of > the FFmpeg API because it's so weird and complicated; seeing patches > like this just feel like a bad joke in contrast. > > What's wrong with: > > int av_parse_disposition_flags(const char *s); > > ? How than one can know which flags are available? > ___ > 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 stream_options to avformat
On Sun, 25 Jan 2015 16:18:53 + Paul B Mahol wrote: > On 1/25/15, wm4 wrote: > > On Sun, 25 Jan 2015 13:39:10 +0100 > > Michael Niedermayer wrote: > > > >> On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote: > >> > On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Doeffinger wrote: > >> > > On 25.01.2015, at 03:08, Michael Niedermayer wrote: > >> > > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: > >> > > >> > >> > > > >> > > As an experienced API user, I don't have the slightest clue what > >> > > I'd do > >> > > with this API, or where to find information about it. > >> > > >>> > >> > > >>> the primary goal is to remove duplicated disposition type tables, > >> > > >>> which needs one of the tables to be public first > >> > > >>> > >> > > >>> [...] > >> > > >> > >> > > >> And this is the most awkward way you could find to do this? > >> > > > > >> > > > No, i could certainly find a more akward way, if people prefer > >> > > > > >> > > > this is just the way that would be a big step towards consistent > >> > > > and simple access to the structs > >> > > > All public structs use AVClass and AVOptions to allow applications > >> > > > to extract/enumerate fields except a few like AVStream > >> > > > this patch would add these AVClass & AVOption for AVStream, its > >> > > > indeed not populated for all fields and AVStream doesnt have a > >> > > > AVClass as its first field due to ABI. But its a step toward it > >> > > > > >> > > > Would people prefer that each field in AVStream has a custom and > >> > > > different way to access it, as long as it looks simpler when looked > >> > > > at in isolation ? > >> > > > >> > > Sorry if it's useless of me to only state some obvious questions, but: > >> > > I think it's clear we all want a simple, obvious and consistent API :) > >> > > If it's a bit messy, might there be a point in holding off a bit so we > >> > > aren't stuck with something complicated? > >> > > Could possibly another approach after a major bump be nicer? > >> > > Or maybe better documentation/examples? > >> > > >> > > I think this started with a valid complaint/concern but unfortunately > >> > > no better alternative, could we stick to considering that instead of > >> > > going over to agressive rhethoric? > >> > > >> > absolutley > >> > i would strongly prefer if others could take this over, my interrest > >> > was just in the technical side and i wanted to move AVStream to > >> > the same system we use for all other structs. As well as fixing the > >> > quite valid issue nicolas had raised with the duplicated tables. > >> > I am quite surprised that others dont see this as a clear and > >> > uncontroversal step, there really are just > >> > 1. If we want AVStream to be consistent with other structs, that means > >> >AVOption & AVClass. And this patch is a step toward it, one could > >> >make a bigger or smaller step but its then either more or less > >> >code not different code. > >> > 2. There could be a different system be used for this field or for > >> >AVStream, this would be inconsistent > >> > 3. We can implement both a system based on AVOptions/AVClass and a > >> >system without them, why would this field that noone cared about > >> >until now need this, iam not sure though > >> > 4. We can leave the triplicated tables as is and hope not to forget > >> >updating them in sync > >> > > >> > To me the best choice is clear, move toward the same system we use > >> > elsewhere. Change that system everywhere if it could be improved > >> > I see nothing controversal on this patch but others do apparently. > >> > As i dont see what issue people have with this, i certainly cannot > >> > help fixing the patch. But iam happy to review & approve the solution > >> > that people do prefer > >> > >> About the documentation & example side, i dont think this should yet > >> be used from outside, its only a partial implementation of AVOption > >> for AVStream, a full implementation needs a ABI bump due to the > >> first field needing to be a AVClass > >> > >> [...] > >> > > > > How is it even consistent with "other structs"? Doesn't it just resolve > > flags? Resolving flags with a complicated AVOption contraption (which > > every user has to understand and duplicate) doesn't seem like a good > > choice to me at all. I hear about API users fighting with the basics of > > the FFmpeg API because it's so weird and complicated; seeing patches > > like this just feel like a bad joke in contrast. > > > > What's wrong with: > > > > int av_parse_disposition_flags(const char *s); > > > > ? > > How than one can know which flags are available? Well yes, C doesn't have reflection, but I doubt AVOption is a good replacement for that. But you still could fall back to awkward things like messing with AVClasses if you really need. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.or
Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options
On Sun, Jan 25, 2015 at 5:15 PM, Reimar Döffinger
wrote:
> On Thu, Jan 22, 2015 at 03:49:09PM +0100, Andreas Cadhalpun wrote:
> > Hi,
> >
> > On 22.01.2015 15:31, wm4 wrote:
> > >If the build date is not correct, then what value does the build date
> > >have at all?
> >
> > How do you know it is 'correct' currently?
> > One can change the system clock (or use faketime).
>
> And someone could hand-edit the revision number...
> I think we have to assume non-maliciousness, otherwise it's all
> pointless.
>
> > What value has the 'correct' build date?
> > If you build an ffmpeg version from a year ago today it will contain the
> > current date. That's rather misleading.
>
> As it is the build date I see nothing misleading about that at all.
> I would buy the argument though that having the build date at all
> is useless and should be removed.
>
> > With the --build-{date,time} options one can specify meaningful values
> such
> > as the time of the last change to the source.
>
> Then it's not the build date.
> If we want a last-changed-date we should change it to
> that.
> But having a build date that in Debian actually is the
> last-source-change date, except when something goes
> wrong and it's something completely wrong seems to me
> to defeat the purpose (assuming there is one in the first place).
> I vote for just removing the build date.
> As an alternative I vote to change it to use the date of
> the last commit if the source tree is clean and has git info
> available, current date otherwise.
> What do others think?
>
>
Remove it for all I care, the important part is the revision info and the
compiler used.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Question about supported_fps in libavutil/timecode.c::check_fps
On Sun, 25 Jan 2015 12:06:33 +0100 Reimar Döffinger wrote: > On 24.01.2015, at 21:09, wm4 wrote: > > On Sat, 24 Jan 2015 18:37:01 + > > Derek Buitenhuis wrote: > > > >> On 1/24/2015 4:33 PM, wm4 wrote: > >>> Which ones? We even expect C99 support from the compiler. > >> > >> Doesn't matter. It's the project's policy to have decls at > >> block beginnings. Yes some of us think it's better. > >> > >> We know you don't. Don't start an ideological troll war. > > > > Having dumb policies is fine, but then don't use broken compilers as > > excuse. Just say it's your policy to do it this way, even if there's no > > technical necessity. > > Maybe not really relevant, but since I wrote it... Skip it unless you have > time to waste ;) > I guess it's an old habit from when we still used to support gcc 2.95 :) > Which btw last I tried some months ago still worked except for very few cases. > Thing is, we require not that much of C99 and most is header or > preprocessor-related or used very, very rarely. Well, it was enough that someone wrote a c99-to-c89 converter (using clang), which was the only way to compile ffmpeg on C89-only MSVC. (Newer MSVC versions support C99 or parts of it, so this is not a problem anymore.) > And while I don't know where they come from, every now and then I hear about > someone asking for C89 support for some product (possibly custom in-house > compilers for strange architectures/OS? Symbian maybe still hiding in some > hole?). > But with even tinycc supporting it I guess it's reasonable to say that any > "technical" reasons that might exist are more related to someone's laziness > than a real technical reason. > That said, I still prefer it even though I write C++ every day. Maybe it's > just an old habit and secretly longing back to writing PASCAL as in my > childhood days ;) PASCAL at least has reasonable syntax for it. Anyway, I didn't mean to start a flamewar, but if it's the project's policy, then just say it, instead of using inadequate excuses like compilers that someone dug out from an archeological site from before the Neolithic. Because people will look at the technical because and realize it doesn't make much sense. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On Sun, Jan 25, 2015 at 05:24:18PM +0100, wm4 wrote: > On Sun, 25 Jan 2015 16:18:53 + > Paul B Mahol wrote: > > > On 1/25/15, wm4 wrote: > > > On Sun, 25 Jan 2015 13:39:10 +0100 > > > Michael Niedermayer wrote: > > > > > >> On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote: > > >> > On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Doeffinger wrote: > > >> > > On 25.01.2015, at 03:08, Michael Niedermayer > > >> > > wrote: > > >> > > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: > > >> > > >> > > >> > > > > >> > > As an experienced API user, I don't have the slightest clue what > > >> > > I'd do > > >> > > with this API, or where to find information about it. > > >> > > >>> > > >> > > >>> the primary goal is to remove duplicated disposition type tables, > > >> > > >>> which needs one of the tables to be public first > > >> > > >>> > > >> > > >>> [...] > > >> > > >> > > >> > > >> And this is the most awkward way you could find to do this? > > >> > > > > > >> > > > No, i could certainly find a more akward way, if people prefer > > >> > > > > > >> > > > this is just the way that would be a big step towards consistent > > >> > > > and simple access to the structs > > >> > > > All public structs use AVClass and AVOptions to allow applications > > >> > > > to extract/enumerate fields except a few like AVStream > > >> > > > this patch would add these AVClass & AVOption for AVStream, its > > >> > > > indeed not populated for all fields and AVStream doesnt have a > > >> > > > AVClass as its first field due to ABI. But its a step toward it > > >> > > > > > >> > > > Would people prefer that each field in AVStream has a custom and > > >> > > > different way to access it, as long as it looks simpler when looked > > >> > > > at in isolation ? > > >> > > > > >> > > Sorry if it's useless of me to only state some obvious questions, > > >> > > but: > > >> > > I think it's clear we all want a simple, obvious and consistent API > > >> > > :) > > >> > > If it's a bit messy, might there be a point in holding off a bit so > > >> > > we > > >> > > aren't stuck with something complicated? > > >> > > Could possibly another approach after a major bump be nicer? > > >> > > Or maybe better documentation/examples? > > >> > > > >> > > I think this started with a valid complaint/concern but unfortunately > > >> > > no better alternative, could we stick to considering that instead of > > >> > > going over to agressive rhethoric? > > >> > > > >> > absolutley > > >> > i would strongly prefer if others could take this over, my interrest > > >> > was just in the technical side and i wanted to move AVStream to > > >> > the same system we use for all other structs. As well as fixing the > > >> > quite valid issue nicolas had raised with the duplicated tables. > > >> > I am quite surprised that others dont see this as a clear and > > >> > uncontroversal step, there really are just > > >> > 1. If we want AVStream to be consistent with other structs, that means > > >> >AVOption & AVClass. And this patch is a step toward it, one could > > >> >make a bigger or smaller step but its then either more or less > > >> >code not different code. > > >> > 2. There could be a different system be used for this field or for > > >> >AVStream, this would be inconsistent > > >> > 3. We can implement both a system based on AVOptions/AVClass and a > > >> >system without them, why would this field that noone cared about > > >> >until now need this, iam not sure though > > >> > 4. We can leave the triplicated tables as is and hope not to forget > > >> >updating them in sync > > >> > > > >> > To me the best choice is clear, move toward the same system we use > > >> > elsewhere. Change that system everywhere if it could be improved > > >> > I see nothing controversal on this patch but others do apparently. > > >> > As i dont see what issue people have with this, i certainly cannot > > >> > help fixing the patch. But iam happy to review & approve the solution > > >> > that people do prefer > > >> > > >> About the documentation & example side, i dont think this should yet > > >> be used from outside, its only a partial implementation of AVOption > > >> for AVStream, a full implementation needs a ABI bump due to the > > >> first field needing to be a AVClass > > >> > > >> [...] > > >> > > > > > > How is it even consistent with "other structs"? The only public change the patch makes is adding avstream_get_class() git grep '_get_class' */*.h libavcodec/avcodec.h:const AVClass *avcodec_get_class(void); libavcodec/avdct.h:const AVClass *avcodec_dct_get_class(void); libavfilter/avfilter.h:const AVClass *avfilter_get_class(void); libavformat/avformat.h: * from avformat_get_class()). Private (format-specific) options are provided by libavformat/avformat.h:const AVClass *avformat_get_class(void); libavresample/avresample.h:const AVClass *avresample_get_class(void); libswresample/swresample.h:c
Re: [FFmpeg-devel] [PATCH] Move stream_options to avformat
On Sun, Jan 25, 2015 at 05:15:33PM +0100, wm4 wrote: > On Sun, 25 Jan 2015 13:39:10 +0100 > Michael Niedermayer wrote: > > > On Sun, Jan 25, 2015 at 01:18:31PM +0100, Michael Niedermayer wrote: > > > On Sun, Jan 25, 2015 at 12:15:40PM +0100, Reimar Döffinger wrote: > > > > On 25.01.2015, at 03:08, Michael Niedermayer wrote: > > > > > On Sun, Jan 25, 2015 at 02:31:33AM +0100, wm4 wrote: > > > > >> > > > > > > > > As an experienced API user, I don't have the slightest clue what > > > > I'd do > > > > with this API, or where to find information about it. > > > > >>> > > > > >>> the primary goal is to remove duplicated disposition type tables, > > > > >>> which needs one of the tables to be public first > > > > >>> > > > > >>> [...] > > > > >> > > > > >> And this is the most awkward way you could find to do this? > > > > > > > > > > No, i could certainly find a more akward way, if people prefer > > > > > > > > > > this is just the way that would be a big step towards consistent > > > > > and simple access to the structs > > > > > All public structs use AVClass and AVOptions to allow applications > > > > > to extract/enumerate fields except a few like AVStream > > > > > this patch would add these AVClass & AVOption for AVStream, its > > > > > indeed not populated for all fields and AVStream doesnt have a > > > > > AVClass as its first field due to ABI. But its a step toward it > > > > > > > > > > Would people prefer that each field in AVStream has a custom and > > > > > different way to access it, as long as it looks simpler when looked > > > > > at in isolation ? > > > > > > > > Sorry if it's useless of me to only state some obvious questions, but: > > > > I think it's clear we all want a simple, obvious and consistent API :) > > > > If it's a bit messy, might there be a point in holding off a bit so we > > > > aren't stuck with something complicated? > > > > Could possibly another approach after a major bump be nicer? > > > > Or maybe better documentation/examples? > > > > > > > I think this started with a valid complaint/concern but unfortunately > > > > no better alternative, could we stick to considering that instead of > > > > going over to agressive rhethoric? > > > > > > absolutley > > > i would strongly prefer if others could take this over, my interrest > > > was just in the technical side and i wanted to move AVStream to > > > the same system we use for all other structs. As well as fixing the > > > quite valid issue nicolas had raised with the duplicated tables. > > > I am quite surprised that others dont see this as a clear and > > > uncontroversal step, there really are just > > > 1. If we want AVStream to be consistent with other structs, that means > > >AVOption & AVClass. And this patch is a step toward it, one could > > >make a bigger or smaller step but its then either more or less > > >code not different code. > > > 2. There could be a different system be used for this field or for > > >AVStream, this would be inconsistent > > > 3. We can implement both a system based on AVOptions/AVClass and a > > >system without them, why would this field that noone cared about > > >until now need this, iam not sure though > > > 4. We can leave the triplicated tables as is and hope not to forget > > >updating them in sync > > > > > > To me the best choice is clear, move toward the same system we use > > > elsewhere. Change that system everywhere if it could be improved > > > I see nothing controversal on this patch but others do apparently. > > > As i dont see what issue people have with this, i certainly cannot > > > help fixing the patch. But iam happy to review & approve the solution > > > that people do prefer > > > > About the documentation & example side, i dont think this should yet > > be used from outside, its only a partial implementation of AVOption > > for AVStream, a full implementation needs a ABI bump due to the > > first field needing to be a AVClass > > > > [...] > > > > How is it even consistent with "other structs"? Doesn't it just resolve > flags? Resolving flags with a complicated AVOption contraption (which > every user has to understand and duplicate) doesn't seem like a good > choice to me at all. I hear about API users fighting with the basics of > the FFmpeg API because it's so weird and complicated; seeing patches > like this just feel like a bad joke in contrast. > > What's wrong with: > > int av_parse_disposition_flags(const char *s); * requires more code to use once the first field of AVStream is made an AVClass compare: myctx->disposition = av_parse_disposition_flags(mystring); vs. av_opt_set(myctx, "disposition", mystring, 0); * Supports just a subset of the features: like "-forced" to remove the "forced" disposition type while leaving the other flags in place [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes th
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > > On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes > > wrote: > > > > > MSYS2 uses a system name of "MSYS_NT-6.3" instead of "MINGW32_NT-6.3" in > > > MSYS1. > > > > > > > Apparently this isn't quite correct, and you have to start MSYS2 with a > > special batch file that overrides this for you. > > Just running bash.exe or sh.exe from a DOS prompt results in this and is > > apparently considered "wrong usage". > > I don't really see anything wrong with this, however I'd rather have > a compiler-based detection. > I.e. if the compiler define __MINGW32__ set the host to mingw (unless > set explicitly). > This should also address my other annoyance that you have to specify > --host when it really should be obvious that you are cross-compiling to > MINGW for example. i dont use "--host*" for my mingw building just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --target_exec=wine the rest i use should not be mingw specific [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer wrote: > On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > > On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > > > On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes > > > wrote: > > > > > > > MSYS2 uses a system name of "MSYS_NT-6.3" instead of > "MINGW32_NT-6.3" in > > > > MSYS1. > > > > > > > > > > Apparently this isn't quite correct, and you have to start MSYS2 with a > > > special batch file that overrides this for you. > > > Just running bash.exe or sh.exe from a DOS prompt results in this and > is > > > apparently considered "wrong usage". > > > > I don't really see anything wrong with this, however I'd rather have > > a compiler-based detection. > > I.e. if the compiler define __MINGW32__ set the host to mingw (unless > > set explicitly). > > > This should also address my other annoyance that you have to specify > > --host when it really should be obvious that you are cross-compiling to > > MINGW for example. > > i dont use "--host*" for my mingw building > just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 --target-os=mingw32 > --cross-prefix=x86_64-w64-mingw32- --target_exec=wine > > the rest i use should not be mingw specific > > I've never had to specify --host things either, the only problem with MSYS2 I ran into was that you still need to specify --target-os unless you use their fancy batch file, and that tripped me up a bit. Never a problem with old MSYS and my own gcc build. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options
On Sun, Jan 25, 2015 at 05:29:08PM +0100, Hendrik Leppkes wrote:
> On Sun, Jan 25, 2015 at 5:15 PM, Reimar Döffinger
> wrote:
>
> > On Thu, Jan 22, 2015 at 03:49:09PM +0100, Andreas Cadhalpun wrote:
> > > Hi,
> > >
> > > On 22.01.2015 15:31, wm4 wrote:
> > > >If the build date is not correct, then what value does the build date
> > > >have at all?
> > >
> > > How do you know it is 'correct' currently?
> > > One can change the system clock (or use faketime).
> >
> > And someone could hand-edit the revision number...
> > I think we have to assume non-maliciousness, otherwise it's all
> > pointless.
> >
> > > What value has the 'correct' build date?
> > > If you build an ffmpeg version from a year ago today it will contain the
> > > current date. That's rather misleading.
> >
> > As it is the build date I see nothing misleading about that at all.
> > I would buy the argument though that having the build date at all
> > is useless and should be removed.
> >
> > > With the --build-{date,time} options one can specify meaningful values
> > such
> > > as the time of the last change to the source.
> >
> > Then it's not the build date.
> > If we want a last-changed-date we should change it to
> > that.
> > But having a build date that in Debian actually is the
> > last-source-change date, except when something goes
> > wrong and it's something completely wrong seems to me
> > to defeat the purpose (assuming there is one in the first place).
> > I vote for just removing the build date.
> > As an alternative I vote to change it to use the date of
> > the last commit if the source tree is clean and has git info
> > available, current date otherwise.
> > What do others think?
> >
> >
> Remove it for all I care, the important part is the revision info and the
> compiler used.
+1
[..]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg
I have updated the patch.
I checked the output with many combinations of parameters. It is bitexact
now.
I am facing problems in rebasing against the latest master.
From f6c6a66b306475e3bc7977f59287c920f5e867a7 Mon Sep 17 00:00:00 2001
From: Arwa Arif
Date: Mon, 19 Jan 2015 03:56:48 +0530
Subject: [PATCH] Port mp=eq/eq2 to FFmpeg
---
configure| 38 +++
doc/filters.texi | 43 +++
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/vf_eq.c | 285 ++
libavfilter/vf_eq.h | 63 ++
libavfilter/x86/Makefile |1 +
libavfilter/x86/vf_eq.c | 96
8 files changed, 503 insertions(+), 25 deletions(-)
create mode 100644 libavfilter/vf_eq.c
create mode 100644 libavfilter/vf_eq.h
create mode 100644 libavfilter/x86/vf_eq.c
diff --git a/configure b/configure
index c73562b..d122720 100755
--- a/configure
+++ b/configure
@@ -60,7 +60,6 @@ show_help(){
cat <= 1.4" xcb/xcb.h xcb_connect || {
+enabled libxcb && die "ERROR: libxcb >= 1.4 not found";
} && disable x11grab && enable libxcb
if enabled libxcb; then
@@ -5694,7 +5684,7 @@ cat > $TMPH <
+ * Copyright (c) 2015 Arwa Arif
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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.
+ */
+
+/**
+ * @file
+ * very simple video equalizer
+ */
+
+/**
+ * TODO:
+ * - Add support to process_command
+ */
+
+#include "libavfilter/internal.h"
+#include "libavutil/common.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "vf_eq.h"
+
+static void create_lut(EQParameters *param)
+{
+unsigned i;
+double g, v;
+double lw, gw;
+
+g = param->gamma;
+gw = param->gamma_weight;
+lw = 1.0 - gw;
+
+g = 1.0 / g;
+
+for (i = 0; i < 256; i++) {
+v = (double) i / 255.0;
+v = param->contrast * (v - 0.5) + 0.5 + param->brightness;
+
+if (v <= 0.0)
+param->lut[i] = 0;
+
+else {
+v = v*lw + pow(v, g)*gw;
+if (v >= 1.0)
+param->lut[i] = 255;
+else
+param->lut[i] = (unsigned char) (256.0 * v);
+}
+}
+
+for (i = 0; i < 256 * 256; i++)
+param->lut16[i] = param->lut[i & 0xFF] + (param->lut[i >> 8] << 8);
+
+param->lut_clean = 1;
+}
+
+static void apply_lut(EQParameters *param, uint8_t *dst, int dst_stride,
+ uint8_t *src, int src_stride, int w, int h)
+{
+int x, y;
+
+if (!param->lut_clean)
+create_lut(param);
+
+for (y = 0; y < h; y++) {
+for (x = 0; x < w; x++) {
+dst[y * dst_stride + x] = param->lut[src[y * src_stride + x]];
+}
+}
+}
+
+static void process_c(EQParameters *param, uint8_t *dst, int dst_stride,
+ uint8_t *src, int src_stride, int w, int h)
+{
+int x, y, pel;
+
+int contrast = (int) (param->contrast * 256 * 16);
+int brightness = ((int) (100.0 * param->brightness + 100.0) * 511) / 200 - 128 - contrast / 32;
+
+for (y = 0; y < h; y++) {
+for (x = 0; x < w; x++) {
+pel = ((src[y * src_stride + x] * contrast) >> 16) + brightness;
+
+if (pel & 768)
+pel = (-pel) >> 31;
+
+dst[y * dst_stride + x] = pel;
+}
+}
+}
+
+static void check_values(EQParameters *param, EQContext *eq)
+{
+if (param->contrast == 1.0 && param->brightness == 0.0 && param->gamma == 1.0)
+param->adjust = NULL;
+else if (param->gamma == 1.0)
+param->adjust = eq->process;
+else
+param->adjust = apply_lut;
+}
+
+static void set_contrast(EQContext *eq)
+{
+eq->param[0].contrast = eq->contrast;
+eq->param[0].lut_clean = 0;
+check_values(&eq->param[0], eq);
+}
+
+static void set_brightness(EQContext *eq)
+{
+eq->param[0].brightness = eq->brightness;
+eq->param[0].lut_clean = 0;
+check_values(&eq->param[0], eq);
+}
+
+static void set_gamma(EQContext *eq)
+{
+int i;
+eq->param[0].gamma = eq->gamma * eq->gamma_u;
+eq->param[1].gamma = sqrt(eq->gamma_v / eq->gamma_u);
+eq->param[2].gamma = sqrt(eq->gamma_y / eq->gamma_u);
+
+for (i = 0; i < 3; i++) {
+eq->param[i].gamma_weight = eq->gamm
Re: [FFmpeg-devel] libavutil: Added twofish block cipher
Hello,
I have made all the changes as suggested. If the number of if-else loops in
init() seem to be too many, please let me know I will change it but I have
put them to handle the return values and overflow issues. If there are any
other changes, please let me know.
Thanks,
Supraja
On Sun, Jan 25, 2015 at 2:22 AM, Giorgio Vazzana wrote:
> Hello,
>
> thanks for the new patch. As I said the code looks quite good, here's
> what I spotted in my review:
>
> > From b46d6a457aeee319fc6e56217a265c9881a34c2c Mon Sep 17 00:00:00 2001
> > From: Supraja Meedinti
> > Date: Thu, 15 Jan 2015 21:35:16 +0530
> > Subject: [PATCH] libavutil: Added Twofish block cipher
> >
> > Signed-off-by: Supraja Meedinti
> > ---
> > libavutil/Makefile | 3 +
> > libavutil/twofish.c | 373
>
> > libavutil/twofish.h | 70 ++
>
> Missing changelog entry.
>
> > 3 files changed, 446 insertions(+)
> > create mode 100644 libavutil/twofish.c
> > create mode 100644 libavutil/twofish.h
> >
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index 4db89b8..6caf896 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -60,6 +60,7 @@ HEADERS = adler32.h
> \
> >time.h
> \
> >timecode.h
> \
> >timestamp.h
> \
> > + twofish.h
> \
> >version.h
> \
> >xtea.h
> \
> >
> > @@ -129,6 +130,7 @@ OBJS = adler32.o
> \
> > time.o
> \
> > timecode.o
> \
> > tree.o
> \
> > + twofish.o
> \
> > utils.o
> \
> > xga_font_data.o
> \
> > xtea.o
> \
> > @@ -184,6 +186,7 @@ TESTPROGS = adler32
>\
> > sha512
> \
> > softfloat
> \
> > tree
> \
> > +twofish
> \
> > utf8
> \
> > xtea
> \
> >
> > diff --git a/libavutil/twofish.c b/libavutil/twofish.c
> > new file mode 100644
> > index 000..b57a48c
> > --- /dev/null
> > +++ b/libavutil/twofish.c
> > @@ -0,0 +1,373 @@
> > +/*
> > + * An implementation of the TwoFish algorithm
> > + * Copyright (c) 2015 Supraja Meedinti
> > + *
> > + * 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
> > + */
> > +#include "twofish.h"
> > +#include "common.h"
> > +#include "intreadwrite.h"
> > +#include "attributes.h"
> > +
> > +#define LR(x, n) ((x) << (n) | (x) >> (32 - (n)))
> > +#define RR(x, n) ((x) >> (n) | (x) << (32 - (n)))
>
> > +#define R4(x) ((x) >> 1 | (x) << 3)
>
> This macro is never used.
>
> > +#define sk_inc 0x02020202
> > +#define sk_nex 0x01010101
>
> I believe these are not needed, see below.
>
> > +
> > +typedef struct AVTWOFISH {
> > +uint32_t K[40];
> > +uint32_t S[4];
> > +int ksize;
> > +} AVTWOFISH;
> > +
> > +static const uint8_t MD1[256] = {
> > +0x00, 0x5b, 0xb6, 0xed, 0x05, 0x5e, 0xb3, 0xe8, 0x0a, 0x51, 0xbc,
> 0xe7, 0x0f, 0x54, 0xb9, 0xe2,
> > +0x14, 0x4f, 0xa2, 0xf9, 0x11, 0x4a, 0xa7, 0xfc, 0x1e, 0x45, 0xa8,
> 0xf3, 0x1b, 0x40, 0xad, 0xf6,
> > +0x28, 0x73, 0x9e, 0xc5, 0x2d, 0x76, 0x9b, 0xc0, 0x22, 0x79, 0x94,
> 0xcf, 0x27, 0x7c, 0x91, 0xca,
> > +0x3c, 0x67, 0x8a, 0xd1, 0x39, 0x62, 0x8f, 0xd4, 0x36, 0x6d, 0x80,
> 0xdb, 0x33, 0x68, 0x85, 0xde,
> > +0x50, 0x0b, 0xe6, 0xbd, 0x55, 0x0e, 0xe3, 0xb8, 0x5a, 0x01, 0xec,
> 0xb7, 0x5f, 0x04, 0xe9, 0xb2,
> > +0x44, 0x1f, 0xf2, 0xa9, 0x41, 0x1a, 0xf7, 0xac, 0x4e, 0x15, 0xf8,
> 0xa3, 0x4b, 0x10, 0xfd, 0xa6,
> > +0x78, 0x23, 0xce, 0x95, 0x7d, 0x26, 0xcb, 0x90, 0x72, 0x29, 0xc4,
> 0x9f, 0x77, 0x2c, 0xc1, 0x9a,
> > +0x6c, 0x37, 0xda, 0x81, 0x69, 0x32, 0xdf, 0x84, 0x66, 0x3d, 0xd0,
> 0x8b, 0x63, 0x38, 0xd5, 0x8e,
> > +0xa0, 0xfb, 0x16, 0x4d, 0xa5, 0xfe, 0x13, 0x48, 0xaa, 0xf1, 0x1c,
> 0x47, 0xaf, 0xf4, 0x19, 0x42,
> > +0xb4, 0xef, 0x02, 0x59, 0xb1, 0xea, 0x07, 0x5c, 0xbe, 0xe5, 0x08,
> 0x53, 0xbb, 0xe0, 0x0d, 0x56,
> > +0x88, 0xd3, 0x3e, 0x65, 0x8d, 0xd6, 0x3b, 0x60, 0x82, 0xd9, 0x34,
> 0x6f, 0x87, 0xdc, 0x31, 0x6a,
> > +0x9c, 0xc7, 0x2a, 0x71, 0x99, 0xc2, 0x2f, 0x74, 0x96, 0xcd, 0x20,
> 0x7b, 0x93, 0xc8, 0x25, 0x7e,
> > +0xf0, 0xab, 0x46, 0x1d, 0xf5, 0xae, 0x43, 0x18, 0xfa, 0xa1, 0x4c,
> 0x17, 0
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On 25/01/15 2:47 PM, Hendrik Leppkes wrote: > On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer > wrote: > >> On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: >>> On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes wrote: > MSYS2 uses a system name of "MSYS_NT-6.3" instead of >> "MINGW32_NT-6.3" in > MSYS1. > Apparently this isn't quite correct, and you have to start MSYS2 with a special batch file that overrides this for you. Just running bash.exe or sh.exe from a DOS prompt results in this and >> is apparently considered "wrong usage". >>> >>> I don't really see anything wrong with this, however I'd rather have >>> a compiler-based detection. >>> I.e. if the compiler define __MINGW32__ set the host to mingw (unless >>> set explicitly). >> >>> This should also address my other annoyance that you have to specify >>> --host when it really should be obvious that you are cross-compiling to >>> MINGW for example. >> >> i dont use "--host*" for my mingw building >> just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 --target-os=mingw32 >> --cross-prefix=x86_64-w64-mingw32- --target_exec=wine >> >> the rest i use should not be mingw specific >> >> > I've never had to specify --host things either, the only problem with MSYS2 > I ran into was that you still need to specify --target-os unless you use > their fancy batch file, and that tripped me up a bit. > Never a problem with old MSYS and my own gcc build. As you said the old MSYS uses "MINGW32" as part of the system name, while the normal batch file for MSYS2 sets it as "MSYS". If you instead use the x86 batch file it will be set as "MINGW32", or "MINGW64" if you use the x86_64 batch file. The different batch files exist not just to change the output of uname, but also to change the PATH environment variable too include either /mingw32 or /mingw64 respectively. Their package manager offers a complete toolchain and precompiled libraries, which get installed in one of the two folders above. Ideally speaking, if you don't want to use their gcc toolchains, you should install your own in some other folder (/usr/local, /opt, etc) and use the normal batch file. configure currently only checks for mingw32 since that's what MSYS sets, so it needs to be updated to also check for mingw64 and msys, so this patch is IMO correct but incomplete as its missing the check for the former. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] avformat/gif: use first packet palette as global for PAL8
From: Clément Bœsch
This will allow the payload in PAL8 packets to not contain 768B of local
palette (which is not LZW compressed).
---
libavformat/gif.c | 70 +++
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/libavformat/gif.c b/libavformat/gif.c
index b4c5e8b..a729cc7 100644
--- a/libavformat/gif.c
+++ b/libavformat/gif.c
@@ -28,6 +28,28 @@
#include "libavutil/log.h"
#include "libavutil/opt.h"
+/* XXX: random value that shouldn't be taken into effect if there is no
+ * transparent color in the palette (the transparency bit will be set to 0) */
+#define DEFAULT_TRANSPARENCY_INDEX 0x1f
+
+static int get_palette_transparency_index(const uint32_t *palette)
+{
+int transparent_color_index = -1;
+unsigned i, smallest_alpha = 0xff;
+
+if (!palette)
+return -1;
+
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+const uint32_t v = palette[i];
+if (v >> 24 < smallest_alpha) {
+smallest_alpha = v >> 24;
+transparent_color_index = i;
+}
+}
+return smallest_alpha < 128 ? transparent_color_index : -1;
+}
+
static int gif_image_write_header(AVIOContext *pb, const AVCodecContext *avctx,
int loop_count, uint32_t *palette)
{
@@ -47,8 +69,10 @@ static int gif_image_write_header(AVIOContext *pb, const
AVCodecContext *avctx,
avio_wl16(pb, avctx->height);
if (palette) {
+const int bcid = get_palette_transparency_index(palette);
+
avio_w8(pb, 0xf7); /* flags: global clut, 256 entries */
-avio_w8(pb, 0x1f); /* background color index */
+avio_w8(pb, bcid < 0 ? DEFAULT_TRANSPARENCY_INDEX : bcid); /*
background color index */
avio_w8(pb, aspect);
for (i = 0; i < 256; i++) {
const uint32_t v = palette[i] & 0xff;
@@ -73,6 +97,7 @@ static int gif_image_write_header(AVIOContext *pb, const
AVCodecContext *avctx,
avio_w8(pb, 0x00); /* Data Sub-block Terminator */
}
+avio_flush(pb);
return 0;
}
@@ -103,21 +128,20 @@ static int gif_write_header(AVFormatContext *s)
avpriv_set_pts_info(s->streams[0], 64, 1, 100);
if (avpriv_set_systematic_pal2(palette, video_enc->pix_fmt) < 0) {
av_assert0(video_enc->pix_fmt == AV_PIX_FMT_PAL8);
-gif_image_write_header(s->pb, video_enc, gif->loop, NULL);
+/* delay header writing: we wait for the first palette to put it
+ * globally */
} else {
gif_image_write_header(s->pb, video_enc, gif->loop, palette);
}
-avio_flush(s->pb);
return 0;
}
static int flush_packet(AVFormatContext *s, AVPacket *new)
{
GIFContext *gif = s->priv_data;
-int size;
+int size, bcid;
AVIOContext *pb = s->pb;
-uint8_t flags = 0x4, transparent_color_index = 0x1f;
const uint32_t *palette;
AVPacket *pkt = gif->prev_pkt;
@@ -131,19 +155,7 @@ static int flush_packet(AVFormatContext *s, AVPacket *new)
av_log(s, AV_LOG_ERROR, "Invalid palette extradata\n");
return AVERROR_INVALIDDATA;
}
-if (palette) {
-unsigned i, smallest_alpha = 0xff;
-
-for (i = 0; i < AVPALETTE_COUNT; i++) {
-const uint32_t v = palette[i];
-if (v >> 24 < smallest_alpha) {
-smallest_alpha = v >> 24;
-transparent_color_index = i;
-}
-}
-if (smallest_alpha < 128)
-flags |= 0x1; /* Transparent Color Flag */
-}
+bcid = get_palette_transparency_index(palette);
if (new && new->pts != AV_NOPTS_VALUE)
gif->duration = av_clip_uint16(new->pts - gif->prev_pkt->pts);
@@ -154,9 +166,9 @@ static int flush_packet(AVFormatContext *s, AVPacket *new)
avio_w8(pb, 0x21);
avio_w8(pb, 0xf9);
avio_w8(pb, 0x04); /* block size */
-avio_w8(pb, flags);
+avio_w8(pb, 1<<2 | (bcid >= 0));
avio_wl16(pb, gif->duration);
-avio_w8(pb, transparent_color_index);
+avio_w8(pb, bcid < 0 ? DEFAULT_TRANSPARENCY_INDEX : bcid);
avio_w8(pb, 0x00);
avio_write(pb, pkt->data, pkt->size);
@@ -171,11 +183,29 @@ static int flush_packet(AVFormatContext *s, AVPacket *new)
static int gif_write_packet(AVFormatContext *s, AVPacket *pkt)
{
GIFContext *gif = s->priv_data;
+const AVCodecContext *video_enc = s->streams[0]->codec;
if (!gif->prev_pkt) {
gif->prev_pkt = av_malloc(sizeof(*gif->prev_pkt));
if (!gif->prev_pkt)
return AVERROR(ENOMEM);
+
+/* Write the first palette as global palette */
+if (video_enc->pix_fmt == AV_PIX_FMT_PAL8) {
+int size;
+void *palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE,
&size);
+
+if (!palette) {
+av_log(s, AV_LOG_ERROR, "PAL8 packet is missing palette in
extradata\n");
+return AVERROR_INVALIDDATA;
+}
+if (size != AVPA
[FFmpeg-devel] Color quantization for GIF
Hi folks, I've been trying to improve GIF support even more recently. This is the result: http://lucy.pkh.me/gone-nutty-current.gif → http://lucy.pkh.me/gone-nutty.gif How it works in 2 lines: ffmpeg -i in -vf palettegen -y palette.png ffmpeg -i in -i palette.png -lavfi paletteuse out.gif The +: • 1 single optimal palette for the whole stream • no high memory requirement (works in 2 pass) • obviously better quality The -: • indecent size because the dithering is way too noisy, and as a result the transparency mechanism of GIF is inefficient (or worse: -gifflags -transdiff to disable it often makes the output smaller) If someone has a suggestion for the dithering, please stand up. Small summary: Changelog | 1 + doc/filters.texi| 55 +++ libavcodec/gif.c| 53 +- libavfilter/Makefile| 2 + libavfilter/allfilters.c| 2 + libavfilter/version.h | 4 +- libavfilter/vf_palettegen.c | 382 libavfilter/vf_paletteuse.c | 282 libavformat/gif.c | 84 ++ tests/ref/fate/gifenc-pal8 | 346 +++ 10 files changed, 1001 insertions(+), 210 deletions(-) > [PATCH 1/6] avformat/gif: simplify gif_image_write_header() prototype > [PATCH 2/6] avformat/gif: use first packet palette as global for PAL8 > [PATCH 3/6] avcodec/gif: support crop and transparency with PAL8 So these 3 commits are basically to make the GIF support properly PAL8 (one single global palette for the format, and the transparency/crop optimizations .encoder side). > [PATCH 4/6] avfilter: add palettegen filter > [PATCH 5/6] avfilter: add paletteuse filter The 2 main filters, derived from Paul Heckbert paper (1982). It's using a 5-bit component resolution for simplicity, and there are many room for improvement (look for TODO/XXX/FIXME). No FATE test yet, but should be easy to add (no floating point). > [PATCH 6/6] avfilter: bump minor and Changelog document the new (bumping only once at the end, I hope no one mind) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] avcodec/gif: support crop and transparency with PAL8
---
libavcodec/gif.c | 53 ++-
tests/ref/fate/gifenc-pal8 | 346 ++---
2 files changed, 220 insertions(+), 179 deletions(-)
diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index 27d054e..12a039e 100644
--- a/libavcodec/gif.c
+++ b/libavcodec/gif.c
@@ -46,6 +46,9 @@ typedef struct {
AVFrame *last_frame;
int flags;
uint32_t palette[AVPALETTE_COUNT]; ///< local reference palette for !pal8
+int palette_loaded;
+int transparent_index;
+uint8_t *pal_exdata;
uint8_t *tmpl; ///< temporary line buffer
} GIFContext;
@@ -78,11 +81,11 @@ static int gif_image_write_image(AVCodecContext *avctx,
{
GIFContext *s = avctx->priv_data;
int len = 0, height = avctx->height, width = avctx->width, x, y;
-int x_start = 0, y_start = 0, trans = -1;
+int x_start = 0, y_start = 0, trans = s->transparent_index;
+int honor_transparency = (s->flags & GF_TRANSDIFF) && s->last_frame;
const uint8_t *ptr;
/* Crop image */
-// TODO support with palette change
if ((s->flags & GF_OFFSETTING) && s->last_frame && !palette) {
const uint8_t *ref = s->last_frame->data[0];
const int ref_linesize = s->last_frame->linesize[0];
@@ -151,20 +154,23 @@ static int gif_image_write_image(AVCodecContext *avctx,
}
}
-/* TODO: support with palette change (pal8) */
-if ((s->flags & GF_TRANSDIFF) && s->last_frame && !palette) {
+if (honor_transparency && trans < 0) {
trans = pick_palette_entry(buf + y_start*linesize + x_start,
linesize, width, height);
if (trans < 0) { // TODO, patch welcome
av_log(avctx, AV_LOG_DEBUG, "No available color, can not use
transparency\n");
} else {
-uint8_t *pal_exdata = av_packet_new_side_data(pkt,
AV_PKT_DATA_PALETTE, AVPALETTE_SIZE);
+uint8_t *pal_exdata = s->pal_exdata;
+if (!pal_exdata)
+pal_exdata = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE,
AVPALETTE_SIZE);
if (!pal_exdata)
return AVERROR(ENOMEM);
memcpy(pal_exdata, s->palette, AVPALETTE_SIZE);
pal_exdata[trans*4 + 3*!HAVE_BIGENDIAN] = 0x00;
}
}
+if (trans < 0)
+honor_transparency = 0;
bytestream_put_byte(bytestream, 0x08);
@@ -172,7 +178,7 @@ static int gif_image_write_image(AVCodecContext *avctx,
12, FF_LZW_GIF, put_bits);
ptr = buf + y_start*linesize + x_start;
-if (trans >= 0) {
+if (honor_transparency) {
const int ref_linesize = s->last_frame->linesize[0];
const uint8_t *ref = s->last_frame->data[0] + y_start*ref_linesize +
x_start;
@@ -223,6 +229,8 @@ static av_cold int gif_encode_init(AVCodecContext *avctx)
avctx->coded_frame->pict_type = AV_PICTURE_TYPE_I;
avctx->coded_frame->key_frame = 1;
+s->transparent_index = -1;
+
s->lzw = av_mallocz(ff_lzw_encode_state_size);
s->buf = av_malloc(avctx->width*avctx->height*2);
s->tmpl = av_malloc(avctx->width);
@@ -235,6 +243,25 @@ static av_cold int gif_encode_init(AVCodecContext *avctx)
return 0;
}
+/* FIXME: duplicated with lavc */
+static int get_palette_transparency_index(const uint32_t *palette)
+{
+int transparent_color_index = -1;
+unsigned i, smallest_alpha = 0xff;
+
+if (!palette)
+return -1;
+
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+const uint32_t v = palette[i];
+if (v >> 24 < smallest_alpha) {
+smallest_alpha = v >> 24;
+transparent_color_index = i;
+}
+}
+return smallest_alpha < 128 ? transparent_color_index : -1;
+}
+
static int gif_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
const AVFrame *pict, int *got_packet)
{
@@ -254,6 +281,20 @@ static int gif_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
return AVERROR(ENOMEM);
memcpy(pal_exdata, pict->data[1], AVPALETTE_SIZE);
palette = (uint32_t*)pict->data[1];
+
+s->pal_exdata = pal_exdata;
+
+/* The first palette with PAL8 will be used as generic palette by the
+ * muxer so we don't need to write it locally in the packet. We store
+ * it as a reference here in case it changes later. */
+if (!s->palette_loaded) {
+memcpy(s->palette, palette, AVPALETTE_SIZE);
+s->transparent_index = get_palette_transparency_index(palette);
+s->palette_loaded = 1;
+palette = NULL;
+} else if (!memcmp(s->palette, palette, AVPALETTE_SIZE)) {
+palette = NULL;
+}
}
gif_image_write_image(avctx, &outbuf_ptr, end, palette,
diff --git a/tests/ref/fate/gifenc-pal8 b/tests/ref/fate/gifenc-pal8
index 203a154..ede614c 100644
--- a/tests/ref/fate/gifenc-pal8
+++ b/tests/ref/fate/gifenc-pal8
@@ -1,174 +
[FFmpeg-devel] [PATCH 6/6] avfilter: bump minor and Changelog document the new filters
--- Changelog | 1 + libavfilter/version.h | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Changelog b/Changelog index 04f1728..b3b95e2 100644 --- a/Changelog +++ b/Changelog @@ -16,6 +16,7 @@ version : - Closed caption Decoder - fspp, uspp, pp7 MPlayer postprocessing filters ported to native filters - showpalette filter +- palettegen and paletteuse filters version 2.5: diff --git a/libavfilter/version.h b/libavfilter/version.h index 01a9348..e677289 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -30,8 +30,8 @@ #include "libavutil/version.h" #define LIBAVFILTER_VERSION_MAJOR 5 -#define LIBAVFILTER_VERSION_MINOR 8 -#define LIBAVFILTER_VERSION_MICRO 101 +#define LIBAVFILTER_VERSION_MINOR 9 +#define LIBAVFILTER_VERSION_MICRO 100 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ LIBAVFILTER_VERSION_MINOR, \ -- 2.2.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] avformat/gif: simplify gif_image_write_header() prototype
---
libavformat/gif.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/libavformat/gif.c b/libavformat/gif.c
index e817121..b4c5e8b 100644
--- a/libavformat/gif.c
+++ b/libavformat/gif.c
@@ -28,13 +28,12 @@
#include "libavutil/log.h"
#include "libavutil/opt.h"
-static int gif_image_write_header(AVFormatContext *s, int width, int height,
+static int gif_image_write_header(AVIOContext *pb, const AVCodecContext *avctx,
int loop_count, uint32_t *palette)
{
-AVIOContext *pb = s->pb;
-AVRational sar = s->streams[0]->codec->sample_aspect_ratio;
int i;
int64_t aspect = 0;
+const AVRational sar = avctx->sample_aspect_ratio;
if (sar.num > 0 && sar.den > 0) {
aspect = sar.num * 64LL / sar.den - 15;
@@ -44,8 +43,8 @@ static int gif_image_write_header(AVFormatContext *s, int
width, int height,
avio_write(pb, "GIF", 3);
avio_write(pb, "89a", 3);
-avio_wl16(pb, width);
-avio_wl16(pb, height);
+avio_wl16(pb, avctx->width);
+avio_wl16(pb, avctx->height);
if (palette) {
avio_w8(pb, 0xf7); /* flags: global clut, 256 entries */
@@ -89,7 +88,6 @@ static int gif_write_header(AVFormatContext *s)
{
GIFContext *gif = s->priv_data;
AVCodecContext *video_enc;
-int width, height;
uint32_t palette[AVPALETTE_COUNT];
if (s->nb_streams != 1 ||
@@ -101,15 +99,13 @@ static int gif_write_header(AVFormatContext *s)
}
video_enc = s->streams[0]->codec;
-width = video_enc->width;
-height = video_enc->height;
avpriv_set_pts_info(s->streams[0], 64, 1, 100);
if (avpriv_set_systematic_pal2(palette, video_enc->pix_fmt) < 0) {
av_assert0(video_enc->pix_fmt == AV_PIX_FMT_PAL8);
-gif_image_write_header(s, width, height, gif->loop, NULL);
+gif_image_write_header(s->pb, video_enc, gif->loop, NULL);
} else {
-gif_image_write_header(s, width, height, gif->loop, palette);
+gif_image_write_header(s->pb, video_enc, gif->loop, palette);
}
avio_flush(s->pb);
--
2.2.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] avfilter: add paletteuse filter
---
doc/filters.texi| 31 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_paletteuse.c | 282
4 files changed, 315 insertions(+)
create mode 100644 libavfilter/vf_paletteuse.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 5e27ae5..77415b4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6884,6 +6884,7 @@ pad="2*iw:2*ih:ow-iw:oh-ih"
@end example
@end itemize
+@anchor{palettegen}
@section palettegen
Generate one palette for a whole video stream.
@@ -6908,6 +6909,36 @@ ffmpeg -i input.mkv -vf palettegen palette.png
@end example
@end itemize
+@section paletteuse
+
+Use a palette to downsample an input video stream.
+
+The filter takes two inputs: one video stream and a palette. The palette must
+be a 256 pixels image.
+
+It accepts the following option:
+
+@table @option
+@item dither
+Select dithering mode. Available algorithms are:
+@table @samp
+@item heckbert
+dithering as defined by Paul Heckbert in 1982.
+@end table
+Default is @var{heckbert}.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Use a palette (generated for example with @ref{palettegen}) to encode a GIF
+using @command{ffmpeg}:
+@example
+ffmpeg -i input.mkv -i palette.png -lavfi paletteuse output.gif
+@end example
+@end itemize
+
@section perspective
Correct perspective of video not recorded perpendicular to the screen.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6ea7e9c..9328453 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -160,6 +160,7 @@ OBJS-$(CONFIG_OVERLAY_FILTER)+=
vf_overlay.o dualinput.o framesy
OBJS-$(CONFIG_OWDENOISE_FILTER) += vf_owdenoise.o
OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
+OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o
OBJS-$(CONFIG_PERMS_FILTER) += f_perms.o
OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
OBJS-$(CONFIG_PHASE_FILTER) += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a3443a0..333c05f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -175,6 +175,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(OWDENOISE, owdenoise, vf);
REGISTER_FILTER(PAD,pad,vf);
REGISTER_FILTER(PALETTEGEN, palettegen, vf);
+REGISTER_FILTER(PALETTEUSE, paletteuse, vf);
REGISTER_FILTER(PERMS, perms, vf);
REGISTER_FILTER(PERSPECTIVE,perspective,vf);
REGISTER_FILTER(PHASE, phase, vf);
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
new file mode 100644
index 000..67b20ff
--- /dev/null
+++ b/libavfilter/vf_paletteuse.c
@@ -0,0 +1,282 @@
+/*
+ * 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
+ */
+
+/**
+ * @file
+ * Use a palette to downsample an input video stream.
+ *
+ * @todo add an option for smaller palettes
+ */
+
+#include "libavutil/opt.h"
+#include "dualinput.h"
+#include "avfilter.h"
+
+enum dithering_mode {
+DITHERING_NONE,
+DITHERING_HECKBERT,
+NB_DITHERING
+};
+
+typedef struct {
+const AVClass *class;
+FFDualInputContext dinput;
+uint32_t map[1<<15];
+uint32_t palette[AVPALETTE_COUNT];
+int palette_loaded;
+enum dithering_mode dither;
+} PaletteUseContext;
+
+#define OFFSET(x) offsetof(PaletteUseContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+static const AVOption paletteuse_options[] = {
+{ "dither", "select dithering mode", OFFSET(dither), AV_OPT_TYPE_INT,
{.i64=DITHERING_HECKBERT}, 0, NB_DITHERING-1, FLAGS, "dithering_mode" },
+{ "heckbert", "dithering as defined by Paul Heckbert in 1982", 0,
AV_OPT_TYPE_CONST, {.i64=DITHERING_HECKBERT}, INT_MIN, INT_MAX, FLAGS,
"dithering_mode" },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(paletteuse);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat in_fmts[]= {AV_PIX_FMT_RGB32,
AV_PIX_FMT_NONE};
+static const enum AVPixelFormat inpal_fmts[] = {AV_PIX_FMT_RGB32,
AV_PIX_FMT_
[FFmpeg-devel] [PATCH 4/6] avfilter: add palettegen filter
---
doc/filters.texi| 24 +++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_palettegen.c | 382
4 files changed, 408 insertions(+)
create mode 100644 libavfilter/vf_palettegen.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 64384d0..5e27ae5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6884,6 +6884,30 @@ pad="2*iw:2*ih:ow-iw:oh-ih"
@end example
@end itemize
+@section palettegen
+
+Generate one palette for a whole video stream.
+
+It accepts the following option:
+
+@table @option
+@item reserve_transparent
+Create a palette of 255 colors maximum and reserve the last one for
+transparency. Reserving the transparency color is useful for GIF optimization.
+If not set, the maximum of colors in the palette will be 256.
+Set by default.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Generate a representative palette of a given video using @command{ffmpeg}:
+@example
+ffmpeg -i input.mkv -vf palettegen palette.png
+@end example
+@end itemize
+
@section perspective
Correct perspective of video not recorded perpendicular to the screen.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f7285b3..6ea7e9c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -159,6 +159,7 @@ OBJS-$(CONFIG_OPENCL)+=
deshake_opencl.o unsharp_opencl.
OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o dualinput.o
framesync.o
OBJS-$(CONFIG_OWDENOISE_FILTER) += vf_owdenoise.o
OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
+OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
OBJS-$(CONFIG_PERMS_FILTER) += f_perms.o
OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
OBJS-$(CONFIG_PHASE_FILTER) += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 028e3ea..a3443a0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -174,6 +174,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(OVERLAY,overlay,vf);
REGISTER_FILTER(OWDENOISE, owdenoise, vf);
REGISTER_FILTER(PAD,pad,vf);
+REGISTER_FILTER(PALETTEGEN, palettegen, vf);
REGISTER_FILTER(PERMS, perms, vf);
REGISTER_FILTER(PERSPECTIVE,perspective,vf);
REGISTER_FILTER(PHASE, phase, vf);
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
new file mode 100644
index 000..eaa4938
--- /dev/null
+++ b/libavfilter/vf_palettegen.c
@@ -0,0 +1,382 @@
+/*
+ * 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
+ */
+
+/**
+ * @file
+ * Generate one palette for a whole video stream.
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+
+/* Reference a color and how much it's used */
+struct color_ref {
+uint16_t rgb555;
+int count; // copied from the histogram value
+};
+
+/* Store a range of colors */
+struct range_box {
+int start; // index in PaletteGenContext->refs
+int len;// number of referenced colors
+int sorted_by; // whether range of colors is sorted by red (0), green (1)
or blue (2)
+};
+
+typedef struct {
+const AVClass *class;
+int reserve_transparent;
+uint32_t cdist[1<<15]; // color distribution
+struct color_ref refs[1<<15]; // references of all the colors used in
the stream
+int nb_refs;
+struct range_box boxes[256];// define the segmentation of the
colorspace
+int nb_boxes;
+} PaletteGenContext;
+
+#define OFFSET(x) offsetof(PaletteGenContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+static const AVOption palettegen_options[] = {
+{ "reserve_transparent", "reserve a palette entry for transparency",
OFFSET(reserve_transparent), AV_OPT_TYPE_INT, {.i64=1}, 0, 1, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(palettegen);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat in_fmts[] = {AV_PIX_FMT_RGB32,
AV_PIX_FMT_NONE};
+static const enum AVPixelFormat out_fmts[] = {AV_PIX_FMT_RGB3
Re: [FFmpeg-devel] libavutil: Added twofish block cipher
Sorry. I forgot to make a small change. Updated the patch.
Thanks,
Supraja
On Mon, Jan 26, 2015 at 12:12 AM, supraja reddy
wrote:
> Hello,
>
> I have made all the changes as suggested. If the number of if-else loops
> in init() seem to be too many, please let me know I will change it but I
> have put them to handle the return values and overflow issues. If there are
> any other changes, please let me know.
>
> Thanks,
> Supraja
>
> On Sun, Jan 25, 2015 at 2:22 AM, Giorgio Vazzana
> wrote:
>
>> Hello,
>>
>> thanks for the new patch. As I said the code looks quite good, here's
>> what I spotted in my review:
>>
>> > From b46d6a457aeee319fc6e56217a265c9881a34c2c Mon Sep 17 00:00:00 2001
>> > From: Supraja Meedinti
>> > Date: Thu, 15 Jan 2015 21:35:16 +0530
>> > Subject: [PATCH] libavutil: Added Twofish block cipher
>> >
>> > Signed-off-by: Supraja Meedinti
>> > ---
>> > libavutil/Makefile | 3 +
>> > libavutil/twofish.c | 373
>>
>> > libavutil/twofish.h | 70 ++
>>
>> Missing changelog entry.
>>
>> > 3 files changed, 446 insertions(+)
>> > create mode 100644 libavutil/twofish.c
>> > create mode 100644 libavutil/twofish.h
>> >
>> > diff --git a/libavutil/Makefile b/libavutil/Makefile
>> > index 4db89b8..6caf896 100644
>> > --- a/libavutil/Makefile
>> > +++ b/libavutil/Makefile
>> > @@ -60,6 +60,7 @@ HEADERS = adler32.h
>>\
>> >time.h
>> \
>> >timecode.h
>> \
>> >timestamp.h
>> \
>> > + twofish.h
>> \
>> >version.h
>> \
>> >xtea.h
>> \
>> >
>> > @@ -129,6 +130,7 @@ OBJS = adler32.o
>> \
>> > time.o
>> \
>> > timecode.o
>> \
>> > tree.o
>> \
>> > + twofish.o
>> \
>> > utils.o
>> \
>> > xga_font_data.o
>> \
>> > xtea.o
>> \
>> > @@ -184,6 +186,7 @@ TESTPROGS = adler32
>> \
>> > sha512
>> \
>> > softfloat
>> \
>> > tree
>> \
>> > +twofish
>> \
>> > utf8
>> \
>> > xtea
>> \
>> >
>> > diff --git a/libavutil/twofish.c b/libavutil/twofish.c
>> > new file mode 100644
>> > index 000..b57a48c
>> > --- /dev/null
>> > +++ b/libavutil/twofish.c
>> > @@ -0,0 +1,373 @@
>> > +/*
>> > + * An implementation of the TwoFish algorithm
>> > + * Copyright (c) 2015 Supraja Meedinti
>> > + *
>> > + * 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
>> > + */
>> > +#include "twofish.h"
>> > +#include "common.h"
>> > +#include "intreadwrite.h"
>> > +#include "attributes.h"
>> > +
>> > +#define LR(x, n) ((x) << (n) | (x) >> (32 - (n)))
>> > +#define RR(x, n) ((x) >> (n) | (x) << (32 - (n)))
>>
>> > +#define R4(x) ((x) >> 1 | (x) << 3)
>>
>> This macro is never used.
>>
>> > +#define sk_inc 0x02020202
>> > +#define sk_nex 0x01010101
>>
>> I believe these are not needed, see below.
>>
>> > +
>> > +typedef struct AVTWOFISH {
>> > +uint32_t K[40];
>> > +uint32_t S[4];
>> > +int ksize;
>> > +} AVTWOFISH;
>> > +
>> > +static const uint8_t MD1[256] = {
>> > +0x00, 0x5b, 0xb6, 0xed, 0x05, 0x5e, 0xb3, 0xe8, 0x0a, 0x51, 0xbc,
>> 0xe7, 0x0f, 0x54, 0xb9, 0xe2,
>> > +0x14, 0x4f, 0xa2, 0xf9, 0x11, 0x4a, 0xa7, 0xfc, 0x1e, 0x45, 0xa8,
>> 0xf3, 0x1b, 0x40, 0xad, 0xf6,
>> > +0x28, 0x73, 0x9e, 0xc5, 0x2d, 0x76, 0x9b, 0xc0, 0x22, 0x79, 0x94,
>> 0xcf, 0x27, 0x7c, 0x91, 0xca,
>> > +0x3c, 0x67, 0x8a, 0xd1, 0x39, 0x62, 0x8f, 0xd4, 0x36, 0x6d, 0x80,
>> 0xdb, 0x33, 0x68, 0x85, 0xde,
>> > +0x50, 0x0b, 0xe6, 0xbd, 0x55, 0x0e, 0xe3, 0xb8, 0x5a, 0x01, 0xec,
>> 0xb7, 0x5f, 0x04, 0xe9, 0xb2,
>> > +0x44, 0x1f, 0xf2, 0xa9, 0x41, 0x1a, 0xf7, 0xac, 0x4e, 0x15, 0xf8,
>> 0xa3, 0x4b, 0x10, 0xfd, 0xa6,
>> > +0x78, 0x23, 0xce, 0x95, 0x7d, 0x26, 0xcb, 0x90, 0x72, 0x29, 0xc4,
>> 0x9f, 0x77, 0x2c, 0xc1, 0x9a,
>> > +0x6c, 0x37, 0xda, 0x81, 0x69, 0x32, 0xdf, 0x84, 0x66, 0x3d, 0xd0,
>> 0x8b, 0x63, 0x38, 0xd5, 0x8e,
>> > +0xa0, 0xfb, 0x16, 0x4d, 0xa5, 0xfe, 0x13, 0x48, 0xaa, 0xf1, 0x1c,
>> 0x47, 0xaf, 0xf4, 0x19, 0x42,
>> > +0xb4, 0xef, 0x02, 0x59, 0xb1, 0xea, 0x07, 0x5c, 0xbe, 0xe5, 0x08,
>> 0x5
Re: [FFmpeg-devel] Color quantization for GIF
On Sun, Jan 25, 2015 at 07:55:17PM +0100, Clément Bœsch wrote: > Hi folks, > > I've been trying to improve GIF support even more recently. This is the > result: > http://lucy.pkh.me/gone-nutty-current.gif → http://lucy.pkh.me/gone-nutty.gif > I added more here: http://lucy.pkh.me/gif-experiment/ with other dithering (in what is available currently): gif-experiment/bbb: total 119M -rw-r--r-- 1 ux ux 13M Jan 25 20:28 out-current-ad.gif -rw-r--r-- 1 ux ux 41M Jan 25 20:28 out-current-ed.gif -rw-r--r-- 1 ux ux 13M Jan 25 20:28 out-current.gif -rw-r--r-- 1 ux ux 14M Jan 25 20:28 out-current-xd.gif -rw-r--r-- 1 ux ux 40M Jan 25 20:28 out-dither.gif gif-experiment/gone-nutty: total 77M -rw-r--r-- 1 ux ux 6.5M Jan 25 20:19 out-current-ad.gif -rw-r--r-- 1 ux ux 29M Jan 25 20:19 out-current-ed.gif -rw-r--r-- 1 ux ux 6.1M Jan 25 20:18 out-current.gif -rw-r--r-- 1 ux ux 7.3M Jan 25 20:19 out-current-xd.gif -rw-r--r-- 1 ux ux 29M Jan 25 20:19 out-dither.gif gif-experiment/matrix: total 111M -rw-r--r-- 1 ux ux 12M Jan 25 20:22 out-current-ad.gif -rw-r--r-- 1 ux ux 36M Jan 25 20:22 out-current-ed.gif -rw-r--r-- 1 ux ux 14M Jan 25 20:22 out-current.gif -rw-r--r-- 1 ux ux 14M Jan 25 20:22 out-current-xd.gif -rw-r--r-- 1 ux ux 38M Jan 25 20:22 out-dither.gif So indeed, with the heckbert/floyd-steinburg dithering I implemented in paletteuse, the results are very similar in size with error diffusion dithering. The quality is IMO better with the palette though, except for a bug in BBB where it seems the palette has no black (so the opening fade in looks like shit). I used the following for testing: #!/bin/sh ./ffmpeg -i $1 -vf trim=start=$2:end=$3,palettegen -y palette.png filt="trim=start=$2:end=$3,scale=480:-1" ./ffmpeg -i $1-lavfi $filt -y out-current.gif ./ffmpeg -i $1-lavfi $filt:sws_dither=ed -y out-current-ed.gif ./ffmpeg -i $1-lavfi $filt:sws_dither=a_dither -y out-current-ad.gif ./ffmpeg -i $1-lavfi $filt:sws_dither=x_dither -y out-current-xd.gif ./ffmpeg -i $1 -i palette.png -lavfi $filt,paletteuse -y out-dither.gif -- Clément B. pgppiaXOe8Vyb.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On Sun, Jan 25, 2015 at 03:44:30PM -0300, James Almer wrote: > On 25/01/15 2:47 PM, Hendrik Leppkes wrote: > > On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer > > wrote: > > > >> On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > >>> On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes > wrote: > > > MSYS2 uses a system name of "MSYS_NT-6.3" instead of > >> "MINGW32_NT-6.3" in > > MSYS1. > > > > Apparently this isn't quite correct, and you have to start MSYS2 with a > special batch file that overrides this for you. > Just running bash.exe or sh.exe from a DOS prompt results in this and > >> is > apparently considered "wrong usage". > >>> > >>> I don't really see anything wrong with this, however I'd rather have > >>> a compiler-based detection. > >>> I.e. if the compiler define __MINGW32__ set the host to mingw (unless > >>> set explicitly). > >> > >>> This should also address my other annoyance that you have to specify > >>> --host when it really should be obvious that you are cross-compiling to > >>> MINGW for example. > >> > >> i dont use "--host*" for my mingw building > >> just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 --target-os=mingw32 > >> --cross-prefix=x86_64-w64-mingw32- --target_exec=wine > >> > >> the rest i use should not be mingw specific > >> > >> > > I've never had to specify --host things either, the only problem with MSYS2 > > I ran into was that you still need to specify --target-os unless you use > > their fancy batch file, and that tripped me up a bit. > > Never a problem with old MSYS and my own gcc build. > > As you said the old MSYS uses "MINGW32" as part of the system name, while the > normal batch file for MSYS2 sets it as "MSYS". > If you instead use the x86 batch file it will be set as "MINGW32", or > "MINGW64" > if you use the x86_64 batch file. > > The different batch files exist not just to change the output of uname, but > also > to change the PATH environment variable too include either /mingw32 or > /mingw64 > respectively. Their package manager offers a complete toolchain and > precompiled > libraries, which get installed in one of the two folders above. > Ideally speaking, if you don't want to use their gcc toolchains, you should > install your own in some other folder (/usr/local, /opt, etc) and use the > normal > batch file. > > configure currently only checks for mingw32 since that's what MSYS sets, so > it > needs to be updated to also check for mingw64 and msys, so this patch is IMO > correct but incomplete as its missing the check for the former. should i apply it ? or theres a reason to wait? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: add --build-date and --build-time options
Hi,
On 25.01.2015 18:53, Michael Niedermayer wrote:
On Sun, Jan 25, 2015 at 05:29:08PM +0100, Hendrik Leppkes wrote:
On Sun, Jan 25, 2015 at 5:15 PM, Reimar Döffinger
wrote:
I vote for just removing the build date.
[...]
Remove it for all I care, the important part is the revision info and the
compiler used.
+1
OK, if that's preferred. New patch attached.
The ffmpeg_program_string function in t2h.pm is just the
_default_program_string function from texinfo [1] without the timestamp.
Best regards,
Andreas
1:
https://anonscm.debian.org/cgit/debian-tex/texinfo.git/tree/tp/Texinfo/Convert/HTML.pm/#n6118
>From 3163612fb5da694a4ebcc39605561558566d85ed Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 25 Jan 2015 21:13:18 +0100
Subject: [PATCH] stop embedding the build date
Theis makes the build binary reproducible.
Signed-off-by: Andreas Cadhalpun
---
cmdutils.c | 3 +--
doc/Doxyfile | 2 +-
doc/Makefile | 4 ++--
doc/t2h.pm | 17 +
ffprobe.c| 2 --
5 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/cmdutils.c b/cmdutils.c
index 53268d8..6c40df9 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -1081,8 +1081,7 @@ static void print_program_info(int flags, int level)
av_log(NULL, level, " Copyright (c) %d-%d the FFmpeg developers",
program_birth_year, CONFIG_THIS_YEAR);
av_log(NULL, level, "\n");
-av_log(NULL, level, "%sbuilt on %s %s with %s\n",
- indent, __DATE__, __TIME__, CC_IDENT);
+av_log(NULL, level, "%sbuilt with %s\n", indent, CC_IDENT);
av_log(NULL, level, "%sconfiguration: " FFMPEG_CONFIGURATION "\n", indent);
}
diff --git a/doc/Doxyfile b/doc/Doxyfile
index 8697e6c..5d18b10 100644
--- a/doc/Doxyfile
+++ b/doc/Doxyfile
@@ -839,7 +839,7 @@ HTML_COLORSTYLE_GAMMA = 80
# page will contain the date and time when the page was generated. Setting
# this to NO can help when comparing the output of multiple runs.
-HTML_TIMESTAMP = YES
+HTML_TIMESTAMP = NO
# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
# documentation will contain sections that can be hidden and shown after the
diff --git a/doc/Makefile b/doc/Makefile
index 2502922..745576c 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -114,9 +114,9 @@ doc/%-all.pod: doc/%.texi $(SRC_PATH)/doc/texi2pod.pl $(GENTEXI)
doc/%.1 doc/%.3: TAG = MAN
doc/%.1: doc/%.pod $(GENTEXI)
- $(M)pod2man --section=1 --center=" " --release=" " $< > $@
+ $(M)pod2man --section=1 --center=" " --release=" " --date=" " $< > $@
doc/%.3: doc/%.pod $(GENTEXI)
- $(M)pod2man --section=3 --center=" " --release=" " $< > $@
+ $(M)pod2man --section=3 --center=" " --release=" " --date=" " $< > $@
$(DOCS) doc/doxy/html: | doc/
$(DOC_EXAMPLES:%$(EXESUF)=%.o): | doc/examples
diff --git a/doc/t2h.pm b/doc/t2h.pm
index ca77842..5efb2da 100644
--- a/doc/t2h.pm
+++ b/doc/t2h.pm
@@ -186,6 +186,23 @@ EOT
}
texinfo_register_formatting_function('begin_file', \&ffmpeg_begin_file);
+sub ffmpeg_program_string($)
+{
+ my $self = shift;
+ if (defined($self->get_conf('PROGRAM'))
+ and $self->get_conf('PROGRAM') ne ''
+ and defined($self->get_conf('PACKAGE_URL'))) {
+return $self->convert_tree(
+ $self->gdt('This document was generated using @uref{{program_homepage}, @emph{{program}}}.',
+ { 'program_homepage' => $self->get_conf('PACKAGE_URL'),
+ 'program' => $self->get_conf('PROGRAM') }));
+ } else {
+return $self->convert_tree(
+ $self->gdt('This document was generated automatically.'));
+ }
+}
+texinfo_register_formatting_function('program_string', \&ffmpeg_program_string);
+
# Customized file ending
sub ffmpeg_end_file($)
{
diff --git a/ffprobe.c b/ffprobe.c
index 38879f1..d352bb6 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2562,8 +2562,6 @@ static void ffprobe_show_program_version(WriterContext *w)
print_str("version", FFMPEG_VERSION);
print_fmt("copyright", "Copyright (c) %d-%d the FFmpeg developers",
program_birth_year, CONFIG_THIS_YEAR);
-print_str("build_date", __DATE__);
-print_str("build_time", __TIME__);
print_str("compiler_ident", CC_IDENT);
print_str("configuration", FFMPEG_CONFIGURATION);
writer_print_section_footer(w);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
On Sun, Jan 25, 2015 at 7:44 PM, James Almer wrote: > On 25/01/15 2:47 PM, Hendrik Leppkes wrote: > > On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer > > wrote: > > > >> On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > >>> On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes > > wrote: > > > MSYS2 uses a system name of "MSYS_NT-6.3" instead of > >> "MINGW32_NT-6.3" in > > MSYS1. > > > > Apparently this isn't quite correct, and you have to start MSYS2 with > a > special batch file that overrides this for you. > Just running bash.exe or sh.exe from a DOS prompt results in this and > >> is > apparently considered "wrong usage". > >>> > >>> I don't really see anything wrong with this, however I'd rather have > >>> a compiler-based detection. > >>> I.e. if the compiler define __MINGW32__ set the host to mingw (unless > >>> set explicitly). > >> > >>> This should also address my other annoyance that you have to specify > >>> --host when it really should be obvious that you are cross-compiling to > >>> MINGW for example. > >> > >> i dont use "--host*" for my mingw building > >> just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 > --target-os=mingw32 > >> --cross-prefix=x86_64-w64-mingw32- --target_exec=wine > >> > >> the rest i use should not be mingw specific > >> > >> > > I've never had to specify --host things either, the only problem with > MSYS2 > > I ran into was that you still need to specify --target-os unless you use > > their fancy batch file, and that tripped me up a bit. > > Never a problem with old MSYS and my own gcc build. > > As you said the old MSYS uses "MINGW32" as part of the system name, while > the > normal batch file for MSYS2 sets it as "MSYS". > If you instead use the x86 batch file it will be set as "MINGW32", or > "MINGW64" > if you use the x86_64 batch file. > > The different batch files exist not just to change the output of uname, > but also > to change the PATH environment variable too include either /mingw32 or > /mingw64 > respectively. Their package manager offers a complete toolchain and > precompiled > libraries, which get installed in one of the two folders above. > Ideally speaking, if you don't want to use their gcc toolchains, you should > install your own in some other folder (/usr/local, /opt, etc) and use the > normal > batch file. > > configure currently only checks for mingw32 since that's what MSYS sets, > so it > needs to be updated to also check for mingw64 and msys, so this patch is > IMO > correct but incomplete as its missing the check for the former. > > My problem really is with their choice of default. Apparently (or so I am told), the MSYS_* string is for building things actually for MSYS itself, which is imho a bad default. If I just call sh/bash.exe (like I do in a multitude of my scripts), I wouldn't want that to be the default value, especially since it breaks with compat for all sorts of projects (we're not the only project with that problem) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/sbrdsp: add ff_sbr_autocorrelate_{sse, sse3}
On 25/01/15 10:11 AM, Christophe Gisquet wrote:
> Hi,
>
> 2015-01-25 2:05 GMT+01:00 James Almer :
>> 2 to 2.5 times faster.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/x86/sbrdsp.asm| 114
>> +++
>
> Not the first time that I notice that, but memmoves are often
> suboptimal using old SSE ones.
> While movlhps is fine, movlps isn't, on my old core i5. You may want
> to validate this with the attached patch, where storing ps_mask3 in m8
> is a gain in Win64 (the gain does not match the number of loops, but
> it is still there).
I can reproduce the gains using mov{q,sd} instead of movlps, but not with the
mask loaded into m8 (Tested on win64 using a k10 cpu and linux x64 using a
Haswell cpu).
>
> Benchmarks:
> x64: 6023 decicycles in g, 262108 runs, 36 skips
> SSE: 3049 decicycles in g, 262130 runs, 14 skips
> SSE3: 2843 decicycles in g, 262086 runs, 58 skips
> movq: 2693 decicycles in g, 262117 runs, 27 skips
> m8: 2648 decicycles in g, 262083 runs, 61 skips
>
> Thanks for doing it, I had only 3yo scraps left and no further
> motivation to tackle the start/tail parts.
I applied the first part for now.
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] configure: support MSYS2
On Sun, Jan 25, 2015 at 06:43:54PM +0100, Michael Niedermayer wrote: > On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > > I don't really see anything wrong with this, however I'd rather have > > a compiler-based detection. > > I.e. if the compiler define __MINGW32__ set the host to mingw (unless > > set explicitly). > > > This should also address my other annoyance that you have to specify > > --host when it really should be obvious that you are cross-compiling to > > MINGW for example. > > i dont use "--host*" for my mingw building > just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 --target-os=mingw32 > --cross-prefix=x86_64-w64-mingw32- --target_exec=wine Sorry, I meant --target-os, not --host. And --arch is something configure could figure out equally well from the compiler in most cases (__i386__, __x86_64__, __arm__ etc defines). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg
On Mon, Jan 19, 2015 at 01:19:00PM +0100, Stefano Sabatini wrote:
> On date Monday 2015-01-19 04:04:45 +0530, Arwa Arif encoded:
[...]
> > +{ "gamma_b","gamma value for the luma plane",
> > +OFFSET(gamma_b),AV_OPT_TYPE_DOUBLE, {.dbl = 1.0}, 0.1, 10.0,
> > FLAGS },
> > +{ "gamma_g","gamma value for the 1st chroma plane",
> > +OFFSET(gamma_g),AV_OPT_TYPE_DOUBLE, {.dbl = 1.0}, 0.1, 10.0,
> > FLAGS },
> > +{ "gamma_r","gamma value for the 2st chroma plane",
> > +OFFSET(gamma_r),AV_OPT_TYPE_DOUBLE, {.dbl = 1.0}, 0.1, 10.0,
> > FLAGS },
>
> gamma_{y,u,v} are probably better names.
gamma is in RGB space
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to FFmpeg
On Sun, Jan 25, 2015 at 11:53:26PM +0530, arwa arif wrote: > I have updated the patch. > > I checked the output with many combinations of parameters. It is bitexact > now. merged with pauls changes and applied > I am facing problems in rebasing against the latest master. i asked stefano to help/explain git rebase tell me in case he doesnt have time Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Port mp=eq/eq2 to lavfi
On Sat, Jan 24, 2015 at 09:06:33PM +, Paul B Mahol wrote: > From: Arwa Arif > > Code adapted from James Darnley's port > > Signed-off-by: Paul B Mahol merged with arwas latest patch and applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: support MSYS2
2015-01-25 21:36 GMT+01:00 Hendrik Leppkes : > On Sun, Jan 25, 2015 at 7:44 PM, James Almer wrote: > > > On 25/01/15 2:47 PM, Hendrik Leppkes wrote: > > > On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer > > > > wrote: > > > > > >> On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote: > > >>> On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote: > > On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes < > h.lepp...@gmail.com > > > > > wrote: > > > > > MSYS2 uses a system name of "MSYS_NT-6.3" instead of > > >> "MINGW32_NT-6.3" in > > > MSYS1. > > > > > > > Apparently this isn't quite correct, and you have to start MSYS2 > with > > a > > special batch file that overrides this for you. > > Just running bash.exe or sh.exe from a DOS prompt results in this > and > > >> is > > apparently considered "wrong usage". > > >>> > > >>> I don't really see anything wrong with this, however I'd rather have > > >>> a compiler-based detection. > > >>> I.e. if the compiler define __MINGW32__ set the host to mingw (unless > > >>> set explicitly). > > >> > > >>> This should also address my other annoyance that you have to specify > > >>> --host when it really should be obvious that you are cross-compiling > to > > >>> MINGW for example. > > >> > > >> i dont use "--host*" for my mingw building > > >> just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 > > --target-os=mingw32 > > >> --cross-prefix=x86_64-w64-mingw32- --target_exec=wine > > >> > > >> the rest i use should not be mingw specific > > >> > > >> > > > I've never had to specify --host things either, the only problem with > > MSYS2 > > > I ran into was that you still need to specify --target-os unless you > use > > > their fancy batch file, and that tripped me up a bit. > > > Never a problem with old MSYS and my own gcc build. > > > > As you said the old MSYS uses "MINGW32" as part of the system name, while > > the > > normal batch file for MSYS2 sets it as "MSYS". > > If you instead use the x86 batch file it will be set as "MINGW32", or > > "MINGW64" > > if you use the x86_64 batch file. > > > > The different batch files exist not just to change the output of uname, > > but also > > to change the PATH environment variable too include either /mingw32 or > > /mingw64 > > respectively. Their package manager offers a complete toolchain and > > precompiled > > libraries, which get installed in one of the two folders above. > > Ideally speaking, if you don't want to use their gcc toolchains, you > should > > install your own in some other folder (/usr/local, /opt, etc) and use the > > normal > > batch file. > > > > configure currently only checks for mingw32 since that's what MSYS sets, > > so it > > needs to be updated to also check for mingw64 and msys, so this patch is > > IMO > > correct but incomplete as its missing the check for the former. > > > > > My problem really is with their choice of default. Apparently (or so I am > told), the MSYS_* string is for building things actually for MSYS itself, > which is imho a bad default. > If I just call sh/bash.exe (like I do in a multitude of my scripts), I > wouldn't want that to be the default value, especially since it breaks with > compat for all sorts of projects (we're not the only project with that > problem) > > I agree that this change of behavior comparing to MSYS1 can be confusing. But I think they made it sane enough. If we set MSYSTEM environmental variable to MINGW32 anywhere before call to sh/bash.exe it will present itself as MINGW32_* and work fine. This doesn't require any tricks just one env variable to be set. Additionally when calling "bash --login" it will alter PATH to include /mingw32 bin dir, but this is optional if we take care about it ourself. As for the path itself I think it is incorrect because we can't consider MSYS and MINGW the same thing. - Kacper ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/6] avformat/gif: simplify gif_image_write_header() prototype
On Sun, Jan 25, 2015 at 07:55:18PM +0100, Clément Bœsch wrote: > --- > libavformat/gif.c | 16 ++-- > 1 file changed, 6 insertions(+), 10 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tests/fate: added mxf tests for essencegroups and missing index
hi, This patch addes 2 mxf tests for formats that I've been working on. Opatom mxf files with missing index segments and ones with essence groups. the 2 fate can be downloaded here: https://dl.dropboxusercontent.com/u/170952/fate/mxf/opatom_missing_index.mxf goes in FATE_ROOT/mxf/opatom_missing_index.mxf https://dl.dropboxusercontent.com/u/170952/fate/mxf/opatom_essencegroup_alpha_raw.mxf goes in FATE_ROOT/mxf/opatom_essencegroup_alpha_raw.mxf --- tests/Makefile | 1 + tests/fate/mxf.mak | 11 +++ tests/ref/fate/mxf-essencegroup-demux | 2 ++ tests/ref/fate/mxf-missing-index-demux | 1 + 4 files changed, 15 insertions(+) create mode 100644 tests/fate/mxf.mak create mode 100644 tests/ref/fate/mxf-essencegroup-demux create mode 100644 tests/ref/fate/mxf-missing-index-demux diff --git a/tests/Makefile b/tests/Makefile index 84caed6..a4d4b15 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -135,6 +135,7 @@ include $(SRC_PATH)/tests/fate/monkeysaudio.mak include $(SRC_PATH)/tests/fate/mp3.mak include $(SRC_PATH)/tests/fate/mpc.mak include $(SRC_PATH)/tests/fate/mpeg4.mak +include $(SRC_PATH)/tests/fate/mxf.mak include $(SRC_PATH)/tests/fate/opus.mak include $(SRC_PATH)/tests/fate/pcm.mak include $(SRC_PATH)/tests/fate/probe.mak diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak new file mode 100644 index 000..6032c85 --- /dev/null +++ b/tests/fate/mxf.mak @@ -0,0 +1,11 @@ + +FATE_MXF += fate-mxf-missing-index-demux +fate-mxf-missing-index-demux: CMD = crc -i $(TARGET_SAMPLES)/mxf/opatom_missing_index.mxf -acodec copy + +FATE_MXF += fate-mxf-essencegroup-demux +fate-mxf-essencegroup-demux: CMD = framecrc -i $(TARGET_SAMPLES)/mxf/opatom_essencegroup_alpha_raw.mxf -vcodec copy + +FATE_MXF-$(CONFIG_MXF_DEMUXER) += $(FATE_MXF) + +FATE_SAMPLES_AVCONV += $(FATE_MXF-yes) +fate-mxf: $(FATE_MXF-yes) diff --git a/tests/ref/fate/mxf-essencegroup-demux b/tests/ref/fate/mxf-essencegroup-demux new file mode 100644 index 000..8420db9 --- /dev/null +++ b/tests/ref/fate/mxf-essencegroup-demux @@ -0,0 +1,2 @@ +#tb 0: 1001/24000 +0, 0, 0,1, 2080768, 0xe99233d9 diff --git a/tests/ref/fate/mxf-missing-index-demux b/tests/ref/fate/mxf-missing-index-demux new file mode 100644 index 000..8f03fc1 --- /dev/null +++ b/tests/ref/fate/mxf-missing-index-demux @@ -0,0 +1 @@ +CRC=0x48508eed -- 2.2.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tools/crypto_bench: add Camellia support
Signed-off-by: James Almer
---
tools/crypto_bench.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/tools/crypto_bench.c b/tools/crypto_bench.c
index 6037ead..5e56d12 100644
--- a/tools/crypto_bench.c
+++ b/tools/crypto_bench.c
@@ -75,6 +75,7 @@ struct hash_impl {
#include "libavutil/sha512.h"
#include "libavutil/ripemd.h"
#include "libavutil/aes.h"
+#include "libavutil/camellia.h"
#include "libavutil/cast5.h"
#define IMPL_USE_lavu IMPL_USE
@@ -112,6 +113,16 @@ static void run_lavu_aes128(uint8_t *output,
av_aes_crypt(aes, output, input, size >> 4, NULL, 0);
}
+static void run_lavu_camellia(uint8_t *output,
+ const uint8_t *input, unsigned size)
+{
+static struct AVCAMELLIA *camellia;
+if (!camellia && !(camellia = av_camellia_alloc()))
+fatal_error("out of memory");
+av_camellia_init(camellia, hardcoded_key, 128);
+av_camellia_crypt(camellia, output, input, size >> 4, NULL, 0);
+}
+
static void run_lavu_cast128(uint8_t *output,
const uint8_t *input, unsigned size)
{
@@ -132,6 +143,7 @@ static void run_lavu_cast128(uint8_t *output,
#include
#include
#include
+#include
#include
#define DEFINE_CRYPTO_WRAPPER(suffix, function) \
@@ -159,6 +171,18 @@ static void run_crypto_aes128(uint8_t *output,
AES_encrypt(input + i, output + i, &aes);
}
+static void run_crypto_camellia(uint8_t *output,
+const uint8_t *input, unsigned size)
+{
+CAMELLIA_KEY camellia;
+unsigned i;
+
+Camellia_set_key(hardcoded_key, 128, &camellia);
+size -= 15;
+for (i = 0; i < size; i += 16)
+Camellia_ecb_encrypt(input + i, output + i, &camellia, 1);
+}
+
static void run_crypto_cast128(uint8_t *output,
const uint8_t *input, unsigned size)
{
@@ -206,6 +230,16 @@ static void run_gcrypt_aes128(uint8_t *output,
gcry_cipher_encrypt(aes, output, size, input, size);
}
+static void run_gcrypt_camellia(uint8_t *output,
+const uint8_t *input, unsigned size)
+{
+static gcry_cipher_hd_t camellia;
+if (!camellia)
+gcry_cipher_open(&camellia, GCRY_CIPHER_CAMELLIA128,
GCRY_CIPHER_MODE_ECB, 0);
+gcry_cipher_setkey(camellia, hardcoded_key, 16);
+gcry_cipher_encrypt(camellia, output, size, input, size);
+}
+
static void run_gcrypt_cast128(uint8_t *output,
const uint8_t *input, unsigned size)
{
@@ -257,6 +291,18 @@ static void run_tomcrypt_aes128(uint8_t *output,
aes_ecb_encrypt(input + i, output + i, &aes);
}
+static void run_tomcrypt_camellia(uint8_t *output,
+ const uint8_t *input, unsigned size)
+{
+symmetric_key camellia;
+unsigned i;
+
+camellia_setup(hardcoded_key, 16, 0, &camellia);
+size -= 15;
+for (i = 0; i < size; i += 16)
+camellia_ecb_encrypt(input + i, output + i, &camellia);
+}
+
static void run_tomcrypt_cast128(uint8_t *output,
const uint8_t *input, unsigned size)
{
@@ -350,6 +396,7 @@ struct hash_impl implementations[] = {
"7c25b9e118c200a189fcd5a01ef106a4e200061f3e97dbf50ba065745fd46bef")
IMPL_ALL("RIPEMD-160", ripemd160,
"62a5321e4fc8784903bb43ab7752c75f8b25af00")
IMPL_ALL("AES-128",aes128,"crc:ff6bc888")
+IMPL_ALL("CAMELLIA", camellia, "crc:7abb59a7")
IMPL_ALL("CAST-128", cast128, "crc:456aa584")
};
--
2.2.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add Camellia test
Signed-off-by: James Almer --- tests/fate/libavutil.mak | 5 + 1 file changed, 5 insertions(+) diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak index eadebdb..92a7f05 100644 --- a/tests/fate/libavutil.mak +++ b/tests/fate/libavutil.mak @@ -8,6 +8,11 @@ fate-aes: libavutil/aes-test$(EXESUF) fate-aes: CMD = run libavutil/aes-test fate-aes: REF = /dev/null +FATE_LIBAVUTIL += fate-camellia +fate-camellia: libavutil/camellia-test$(EXESUF) +fate-camellia: CMD = run libavutil/camellia-test +fate-camellia: REF = /dev/null + FATE_LIBAVUTIL += fate-cast5 fate-cast5: libavutil/cast5-test$(EXESUF) fate-cast5: CMD = run libavutil/cast5-test -- 2.2.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add Camellia test
On Sun, Jan 25, 2015 at 11:05:48PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > tests/fate/libavutil.mak | 5 + > 1 file changed, 5 insertions(+) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add Camellia test
On 26/01/15 1:53 AM, Michael Niedermayer wrote: > On Sun, Jan 25, 2015 at 11:05:48PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> tests/fate/libavutil.mak | 5 + >> 1 file changed, 5 insertions(+) > > LGTM Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
