Re: [FFmpeg-devel] [RFC] Support dynamic loading of third-party libs
Hi Nicolas, On Wed, 14 Jan 2015 21:33:25 +0100 Nicolas George geo...@nsup.org wrote: Le quintidi 25 nivôse, an CCXXIII, Marc Giger a écrit : For example if they want use libfaac then they should be able to do so without that much hassle a full compilation inclusive all dependencies can be. I was expecting something like that. Unfortunately, it does not work that way: dlopen()ing libfaac will not allow you to omit --enable-nonfree and to redistribute the resulting binary, because the libfaac wrapper still includes the faac headers, which contain non-trivial code (including a big structure definition) that get translated into the resulting object file. That's a very good point. Never thought about it in this detail. Given that fact I have to admin that dynamic loading makes less sense. There may still be some usecases e.g. vaapi where it would make sense, but this seems to be the minority. Apart from that, I fully agree with Michael's last comment: using dynamic linker black magic to make this lazy linking transparent is the best option to implement that feature if it is deemed useful. libffi ? Thanks for the clarification. Marc On Linux/OpenSource OS's things are easy, on proprietary platforms ... Nothing prevents users on proprietary platforms from adopting automated repositories like Debian's apt system and everything that imitated it since to install Libre software, except the users' habits. Using such a repository to distribute your project is a good way of pushing users to change their habits for the better. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Support dynamic loading of third-party libs
On Thu, 15 Jan 2015 18:37:57 +0100 Marc Giger gigerst...@gmx.ch wrote: Hi Nicolas, On Wed, 14 Jan 2015 21:33:25 +0100 Nicolas George geo...@nsup.org wrote: Le quintidi 25 nivôse, an CCXXIII, Marc Giger a écrit : For example if they want use libfaac then they should be able to do so without that much hassle a full compilation inclusive all dependencies can be. I was expecting something like that. Unfortunately, it does not work that way: dlopen()ing libfaac will not allow you to omit --enable-nonfree and to redistribute the resulting binary, because the libfaac wrapper still includes the faac headers, which contain non-trivial code (including a big structure definition) that get translated into the resulting object file. That's a very good point. Never thought about it in this detail. Given that fact I have to admin that dynamic loading makes less sense. There may still be some usecases e.g. vaapi where it would make sense, but this seems to be the minority. Apart from that, I fully agree with Michael's last comment: using dynamic linker black magic to make this lazy linking transparent is the best option to implement that feature if it is deemed useful. libffi ? libavdynamiclinker? (Just joking...) Thanks for the clarification. Marc On Linux/OpenSource OS's things are easy, on proprietary platforms ... Nothing prevents users on proprietary platforms from adopting automated repositories like Debian's apt system and everything that imitated it since to install Libre software, except the users' habits. Using such a repository to distribute your project is a good way of pushing users to change their habits for the better. Regards, -- Nicolas George ___ 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] probable dshow bug or strangeness
On 3/11/14, Don Moir donm...@comcast.net wrote: - Original Message - From: Don Moir donm...@comcast.net To: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org Sent: Monday, March 10, 2014 5:27 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness - Original Message - From: Roger Pack rogerdpa...@gmail.com To: FFmpeg development discussions and patches ffmpeg-devel@ffmpeg.org Sent: Monday, March 10, 2014 2:58 PM Subject: Re: [FFmpeg-devel] probable dshow bug or strangeness On 3/7/14, Don Moir donm...@comcast.net wrote: I am posting here since not quite sure and need some advice. I got word that some captures devices were not working. Everything enumerated and went thru but no display. You get packets with zero size and then no decode success. I traced this into dshow_pin.c and function libAVMemInputPin_Receive. In this function there is: buf_size = IMediaSample_GetActualDataLength(sample); In this case, buf_size is always zero. I think it is supposed to be set somewhere with IMediaSample_SetActualDataLength and could be a coding issue with driver. This apparently happens enough where I can't just blame the driver if thats where it lies. Maybe it is supposed to be set in dshow_pin.c somewhere but don't know. When this happens (buf_size == 0), the real data length appears to be returned by IMediaSample_GetSize(sample); This is supposed to be the actual buffer length and not necessarily the data length. When I change it to use IMediaSample_GetSize it works perfect. Are you sure it's not just re-using the previous frame's worth of data? I think I am sure about that. It plays normal if I use GetSize and nothing with GetActualDataLength. Maybe you should just ignore frames with size 0? Just wondering. GetActualDataLength is always zero in this case. I think yes you should ignore it but as a quick fix I used: buf_size = GetActualDataLength(sample); if (!buf_size) buf_size = GetSize(sample); If you completely ignore nothing will display and basically same thing. The above is not correct and something else is going on. Still looking into it but have to do some other things first. If you have any ideas let me know. Using above quick fix only allows for some display. It is not correct though (display is a bit weird) and that does not overcome the real problem which is still unknown. The thing about GetSize in this case is it always returns the expected frame size. Be it RGB, YUV, etc, the size returned by GetSize is the expected frame size. I have about 3 or 4 normal USB cameras and they all work correctly with GetActualDataLength etc. Just some assortment of capture devices are not working and this information came to me from end users. The problem as reported to me was: Everything list ok but you get no display. So I had to find some software capture device that reproduced the problem. I came across MediaLooks capture device and it seems to indicate the problems reported by users. List ok but no display. Roger if you or anyone else wants to take a look, you can download the MediaLooks dshow filter here. It's free (ignore buy button) and easy. Download, Install, no BS. http://www.medialooks.com/screen_capture/ The latest Medialooks seem to work ok for me [windows 7] maybe they fixed a bug (I did report one to them LOL)? Do you have an older installer that repro's the problem [or, if you can repro it locally, maybe test this: http://test.freeldssheetmusic.org/music/download_file?download_id=46628name=ffmpeg.13.exe (it's got one minor change that may be related, plus multiple other medium size changes but hopefully unrelated) the minor change is https://github.com/rdp/FFmpeg/commit/d820fa3cd5c8aac256341965ce400efdf91b5edf basically I'm just curious to see if the problem's still there, since I can't seem to repro it with Medialooks anymore, thanks to their 30 day limit Thanks. -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add palettedbg filter
On Thu, Jan 15, 2015 at 03:55:04PM +0100, Michael Niedermayer wrote: On Thu, Jan 15, 2015 at 02:21:18PM +0100, Clément Bœsch wrote: From: Clément Bœsch clem...@stupeflix.com --- Changelog| 1 + doc/filters.texi | 13 ++ libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h| 4 +- libavfilter/vf_palettedbg.c | 127 tests/fate/filter-video.mak | 3 + tests/ref/fate/filter-palettedbg | 316 +++ 8 files changed, 464 insertions(+), 2 deletions(-) create mode 100644 libavfilter/vf_palettedbg.c create mode 100644 tests/ref/fate/filter-palettedbg LGTM fate passes on linux x86 mips Renamed to showpalette (see wm4's message) and applied. Thank you. [...] -- Clément B. pgp27airB83Hz.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami
On Wed, Jan 14, 2015 at 07:53:03PM +0100, Jean-Baptiste Kempf wrote: On 14 Jan, Ronald S. Bultje wrote : He specifically mentioned that yami supports (in addition to things ffmpeg already does) hardware h264 encoding, hardware vp8 decoding/decoding, hardware vp9 decoding and hardware jpeg encoding/decoding (all based on vaapi as underlying api). Well, first, I really doubt that the Intel chips actually have VP8 and VP9 encoding in hardware and not in an software driver. Actually I'm quite sure they don't. Then, adding 3 encoders to the VAAPI code directly in FFmpeg seems way better than adding yet another library, that will be unmaintained, buggy and riddled with security issues. i agree its better if there is a volunteer who does implement it but this hangs on that if I don't understand this new fetichism of adding external dependencies to FFmpeg, because we can. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] aversion to .cpp files?
Hello. I've noticed there are a few .cpp files in the codebase, but not many (most seem to be tied to windows). I have the choice, with the dshow stuff, to write in its native cpp style (much easier/clearer IMO) or to convert it to straight c wrapper style stuff. Is there a large preference for either? CPP might be more compatible [possibly] though I have not confirmed that, as well. Thank you. If no response I'll stick with CPP. thanks! -roger- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: fix dtspts when b frame = 1
On Wed, Jan 14, 2015 at 01:25:46PM +0800, Agatha Hu wrote: On 2015/1/11 0:44, Michael Niedermayer wrote: * PGP Signed by an unknown key On Sat, Jan 10, 2015 at 05:30:03PM +0100, Timo Rothenpieler wrote: Looks good to merge for me. i wanted to apply it but the patch is corrupted Applying: avcodec/nvenc: fix dtspts when b frame = 1 fatal: corrupt patch at line 10 its so badly corrupted, even unwrap-diff cant fix it Agatha, please disable line/word wrap for patches or attach them and if that doesnt help use a different MUA / SMTP server whatever is causing this [...] Try using the attachment, if it still doesn't work, I'll use my gmail account to send it. tabs removed applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libavutil: Added twofish block cipher
Hello,
I have attached the patch for twofish implementation. Please let me know if
there are any changes to be made.
Thank you,
Supraja
From f86554850a8b0be2e32fcd341ca297c7ce73a941 Mon Sep 17 00:00:00 2001
From: Supraja Meedinti supraja0...@gmail.com
Date: Thu, 15 Jan 2015 21:35:16 +0530
Subject: [PATCH] libavutil: Added Twofish block cipher
Signed-off-by: Supraja Meedinti supraja0...@gmail.com
---
libavutil/Makefile | 3 +
libavutil/twofish.c | 351
libavutil/twofish.h | 70 +++
3 files changed, 424 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..a66677b
--- /dev/null
+++ b/libavutil/twofish.c
@@ -0,0 +1,351 @@
+/*
+ * An implementation of the TwoFish algorithm as mentioned in RFC3713
+ * 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)
+#define sk_inc 0x02020202
+#define sk_nex 0x01010101
+
+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,
[FFmpeg-devel] [PATCH] avutil/pixdesc: rewrite AV_PIX_FMT_FLAG_PSEUDOPAL documentation
It seems many people do not understand its current documentation
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavutil/pixdesc.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
index a4376b2..705377d 100644
--- a/libavutil/pixdesc.h
+++ b/libavutil/pixdesc.h
@@ -129,10 +129,14 @@ typedef struct AVPixFmtDescriptor {
* The pixel format contains RGB-like data (as opposed to YUV/grayscale).
*/
#define AV_PIX_FMT_FLAG_RGB (1 5)
+
/**
- * The pixel format is pseudo-paletted. This means that FFmpeg treats it as
- * paletted internally, but the palette is generated by the decoder and is not
- * stored in the file.
+ * The pixel format is pseudo-paletted. This means that it contains a
+ * fixed palette in the 2nd plane but the palette is fixed/constant for each
+ * PIX_FMT. This allows interpreting the data as if it was PAL8, which can
+ * in some cases be simpler. Or the data can be interpreted purely based on
+ * the pixel format without using the palette.
+ * An example of a pseudo-paletted format is AV_PIX_FMT_GRAY8
*/
#define AV_PIX_FMT_FLAG_PSEUDOPAL(1 6)
/**
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/f_sendcmd: consider it an error if there are no commands
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavfilter/f_sendcmd.c |5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index 20d9fd1..e1e649c 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -403,6 +403,11 @@ static av_cold int init(AVFilterContext *ctx)
sendcmd-commands_str, ctx)) 0)
return ret;
+if (sendcmd-nb_intervals == 0) {
+av_log(ctx, AV_LOG_ERROR, No commands\n);
+return AVERROR(EINVAL);
+}
+
qsort(sendcmd-intervals, sendcmd-nb_intervals, sizeof(Interval),
cmp_intervals);
av_log(ctx, AV_LOG_DEBUG, Parsed commands:\n);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avcodec/nvenc: Fix b-frame parameter handling
---
libavcodec/nvenc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 5cd7727..90856be 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -155,7 +155,6 @@ typedef struct NvencContext
char *preset;
int cbr;
int twopass;
-int gobpattern;
int gpu;
} NvencContext;
@@ -582,6 +581,13 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
memcpy(ctx-encode_config, preset_config.presetCfg,
sizeof(ctx-encode_config));
ctx-encode_config.version = NV_ENC_CONFIG_VER;
+/* 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;
+
+/* when there're b frames, set dts offset */
+if (ctx-encode_config.frameIntervalP = 2)
+ctx-last_dts = -2;
+
if (avctx-gop_size = 0) {
ctx-encode_config.gopLength = avctx-gop_size;
ctx-encode_config.encodeCodecConfig.h264Config.idrPeriod =
avctx-gop_size;
@@ -656,15 +662,6 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
break;
}
-if (ctx-gobpattern = 0) {
-ctx-encode_config.frameIntervalP = ctx-gobpattern;
-}
-
-// when there're b frames, set dts offset
-if (ctx-encode_config.frameIntervalP = 2) {
-ctx-last_dts = -2;
-}
-
ctx-encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
= 1;
ctx-encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
= 1;
@@ -910,7 +907,7 @@ static int process_output_surface(AVCodecContext *avctx,
AVPacket *pkt, AVFrame
pkt-pts = lock_params.outputTimeStamp;
pkt-dts = timestamp_queue_dequeue(ctx-timestamp_list);
-// when there're b frame(s), set dts offset
+/* when there're b frame(s), set dts offset */
if (ctx-encode_config.frameIntervalP = 2)
pkt-dts -= 1;
@@ -1141,7 +1138,6 @@ static const AVOption options[] = {
{ preset, Set the encoding preset (one of hq, hp, bd, ll, llhq, llhp,
default), OFFSET(preset), AV_OPT_TYPE_STRING, { .str = hq }, 0, 0, VE },
{ cbr, Use cbr encoding mode, OFFSET(cbr), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, 1, VE },
{ 2pass, Use 2pass cbr encoding mode (low latency mode only),
OFFSET(twopass), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1, VE },
-{ goppattern, Specifies the GOP pattern as follows: 0: I, 1: IPP, 2:
IBP, 3: IBBP, OFFSET(gobpattern), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 3, VE },
{ gpu, Selects which NVENC capable GPU to use. First GPU is 0, second
is 1, and so on., OFFSET(gpu), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
{ NULL }
};
--
2.2.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: Handle non-square pixel aspect ratios
---
libavcodec/nvenc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 90856be..57ca130 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -471,6 +471,7 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
int i, num_mbs;
int isLL = 0;
int res = 0;
+int dw, dh;
NvencContext *ctx = avctx-priv_data;
NvencDynLoadFunctions *dl_fn = ctx-nvenc_dload_funcs;
@@ -564,8 +565,16 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
ctx-init_encode_params.encodeGUID = NV_ENC_CODEC_H264_GUID;
ctx-init_encode_params.encodeHeight = avctx-height;
ctx-init_encode_params.encodeWidth = avctx-width;
-ctx-init_encode_params.darHeight = avctx-height;
-ctx-init_encode_params.darWidth = avctx-width;
+
+if (avctx-sample_aspect_ratio.num avctx-sample_aspect_ratio.den) {
+av_reduce(dw, dh, avctx-sample_aspect_ratio.num,
avctx-sample_aspect_ratio.den, 4096);
+ctx-init_encode_params.darHeight = dw;
+ctx-init_encode_params.darWidth = dh;
+} else {
+ctx-init_encode_params.darHeight = avctx-height;
+ctx-init_encode_params.darWidth = avctx-width;
+}
+
ctx-init_encode_params.frameRateNum = avctx-time_base.den;
ctx-init_encode_params.frameRateDen = avctx-time_base.num *
avctx-ticks_per_frame;
--
2.2.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/nvenc: Add support for nvenc api version 5
---
libavcodec/nvenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 57ca130..85f6d43 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -67,7 +67,9 @@ typedef CUresult(CUDAAPI *PCUCTXDESTROY)(CUcontext ctx);
typedef NVENCSTATUS (NVENCAPI*
PNVENCODEAPICREATEINSTANCE)(NV_ENCODE_API_FUNCTION_LIST *functionList);
+#if NVENCAPI_MAJOR_VERSION 5
static const GUID dummy_license = { 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0 } };
+#endif
typedef struct NvencInputSurface
{
@@ -465,7 +467,6 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
CUcontext cu_context_curr;
CUresult cu_res;
GUID encoder_preset = NV_ENC_PRESET_HQ_GUID;
-GUID license = dummy_license;
NVENCSTATUS nv_status = NV_ENC_SUCCESS;
int surfaceCount = 0;
int i, num_mbs;
@@ -473,6 +474,10 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
int res = 0;
int dw, dh;
+#if NVENCAPI_MAJOR_VERSION 5
+GUID license = dummy_license;
+#endif
+
NvencContext *ctx = avctx-priv_data;
NvencDynLoadFunctions *dl_fn = ctx-nvenc_dload_funcs;
NV_ENCODE_API_FUNCTION_LIST *p_nvenc = dl_fn-nvenc_funcs;
@@ -494,7 +499,10 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
preset_config.presetCfg.version = NV_ENC_CONFIG_VER;
encode_session_params.version = NV_ENC_OPEN_ENCODE_SESSION_EX_PARAMS_VER;
encode_session_params.apiVersion = NVENCAPI_VERSION;
+
+#if NVENCAPI_MAJOR_VERSION 5
encode_session_params.clientKeyPtr = license;
+#endif
if (ctx-gpu = dl_fn-nvenc_device_count) {
av_log(avctx, AV_LOG_FATAL, Requested GPU %d, but only %d GPUs are
available!\n, ctx-gpu, dl_fn-nvenc_device_count);
@@ -1071,7 +1079,10 @@ static int nvenc_encode_frame(AVCodecContext *avctx,
AVPacket *pkt,
pic_params.inputDuration = 0;
pic_params.codecPicParams.h264PicParams.sliceMode =
ctx-encode_config.encodeCodecConfig.h264Config.sliceMode;
pic_params.codecPicParams.h264PicParams.sliceModeData =
ctx-encode_config.encodeCodecConfig.h264Config.sliceModeData;
+
+#if NVENCAPI_MAJOR_VERSION 5
memcpy(pic_params.rcParams, ctx-encode_config.rcParams,
sizeof(NV_ENC_RC_PARAMS));
+#endif
res = timestamp_queue_enqueue(ctx-timestamp_list, frame-pts);
--
2.2.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Add bitrate value under -progress action
On Thu, Jan 08, 2015 at 03:50:15AM +0100, Michael Niedermayer wrote: From: raxon1s teoubas@gmail.com --- ffmpeg.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: Handle non-square pixel aspect ratios
Le septidi 27 nivôse, an CCXXIII, Timo Rothenpieler a écrit : +av_reduce(dw, dh, avctx-sample_aspect_ratio.num, avctx-sample_aspect_ratio.den, 4096); +ctx-init_encode_params.darHeight = dw; +ctx-init_encode_params.darWidth = dh; Has this been actually tested? dar in the API does not seem to be the same thing as sample_aspect_ratio in FFmpeg's API. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avutil/buffer: Avoid moving the AVBufferRef to a new place in memory in av_buffer_make_writable()
On Thu, 15 Jan 2015 01:04:56 +0100 Michael Niedermayer michae...@gmx.at wrote: This allows making a AVBufferRef writable without the need to update all pointers to it Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/buffer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/buffer.c b/libavutil/buffer.c index b31f034..bb112c2 100644 --- a/libavutil/buffer.c +++ b/libavutil/buffer.c @@ -159,8 +159,8 @@ int av_buffer_make_writable(AVBufferRef **pbuf) return AVERROR(ENOMEM); memcpy(newbuf-data, buf-data, buf-size); -av_buffer_unref(pbuf); -*pbuf = newbuf; + +buffer_replace(pbuf, newbuf); return 0; } So this pretty much makes the double pointer pointless, and the signature could be: int av_buffer_make_writable(AVBufferRef *pbuf); ? (I wonder why the API didn't do this originally.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/swr: make int32_to_int32 un/pack_2ch functions SSE
Hi, On Wed, Jan 14, 2015 at 4:23 PM, James Almer jamr...@gmail.com wrote: On 14/01/15 1:59 PM, Michael Niedermayer wrote: On Wed, Jan 14, 2015 at 01:53:48AM -0300, James Almer wrote: unpack_2ch is already using sse float ops only, and pack_2ch is a trivial change. Rename both to float_to_float for consistency. Signed-off-by: James Almer jamr...@gmail.com --- libswresample/x86/audio_convert.asm| 14 -- libswresample/x86/audio_convert_init.c | 11 +++ 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/libswresample/x86/audio_convert.asm b/libswresample/x86/audio_convert.asm index 1617e0b..c13c26f 100644 --- a/libswresample/x86/audio_convert.asm +++ b/libswresample/x86/audio_convert.asm @@ -60,8 +60,8 @@ pack_2ch_%2_to_%1_u_int %+ SUFFIX punpcklwd m0, m2 punpckhwd m1, m2 %else -punpckldq m0, m2 -punpckhdq m1, m2 +unpcklps m0, m2 +unpckhps m1, m2 %endif %6 m0,m1,m2,m3,m4,m5 %else did you benchmark this ? ive just checked and on Pentium M, Core Solo and Core Duo these are listed as having only 1/5 the throughput on sandybridge they are still listed with half the throughput than their integer counterparts i didnt benchmark it though No, i didn't benchmark. And you're right, even on recent CPUs they seem to have half the throughput as the integer counterparts. Do you think it will mean a considerable performance hit? These functions aren't even that important in audio processing anyway (perf shows they represent less than 1% of total cpu time when doing pcm - pcm). Nonetheless, considering this maybe the other functions should be changed to not use SBUTTERFLYPS. Well, you can have SSE and SSE2 versions, right? That way it works for people with super-old CPUs (if you care about them), but still gives the better performance for 99.9% of the (x86) world with SSE2 or higher CPUs. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add palettedbg filter
From: Clément Bœsch clem...@stupeflix.com
---
Changelog| 1 +
doc/filters.texi | 13 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h| 4 +-
libavfilter/vf_palettedbg.c | 127
tests/fate/filter-video.mak | 3 +
tests/ref/fate/filter-palettedbg | 316 +++
8 files changed, 464 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/vf_palettedbg.c
create mode 100644 tests/ref/fate/filter-palettedbg
diff --git a/Changelog b/Changelog
index 4fc3800..4dd02e0 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version next:
- VOC seeking support
- Closed caption Decoder
- fspp, uspp, pp7 MPlayer postprocessing filters ported to native filters
+- palettedbg filter
version 2.5:
diff --git a/doc/filters.texi b/doc/filters.texi
index 154508c..faaeeaf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6885,6 +6885,19 @@ pad=2*iw:2*ih:ow-iw:oh-ih
@end example
@end itemize
+@section palettedbg
+
+Displays the 256 colors palette of each frame. This filter is only relevant for
+@var{pal8} pixel format frames.
+
+It accepts the following option:
+
+@table @option
+@item s
+Set the size of the box used to represent one palette color entry. Default is
+@code{30} (for a @code{30x30} pixel box).
+@end table
+
@section perspective
Correct perspective of video not recorded perpendicular to the screen.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 37f5a65..9a8983b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -162,6 +162,7 @@ OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
OBJS-$(CONFIG_PERMS_FILTER) += f_perms.o
OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
OBJS-$(CONFIG_PHASE_FILTER) += vf_phase.o
+OBJS-$(CONFIG_PALETTEDBG_FILTER) += vf_palettedbg.o
OBJS-$(CONFIG_PIXDESCTEST_FILTER)+= vf_pixdesctest.o
OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b19da61..87c17b0 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(PALETTEDBG, palettedbg, vf);
REGISTER_FILTER(PERMS, perms, vf);
REGISTER_FILTER(PERSPECTIVE,perspective,vf);
REGISTER_FILTER(PHASE, phase, vf);
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 383eb55..021f01c 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 7
-#define LIBAVFILTER_VERSION_MICRO 101
+#define LIBAVFILTER_VERSION_MINOR 8
+#define LIBAVFILTER_VERSION_MICRO 100
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_palettedbg.c b/libavfilter/vf_palettedbg.c
new file mode 100644
index 000..11c902b
--- /dev/null
+++ b/libavfilter/vf_palettedbg.c
@@ -0,0 +1,127 @@
+/*
+ * 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
+ * Palette (AV_PIX_FMT_PAL8) debugger
+ */
+
+#include libavutil/avassert.h
+#include libavutil/opt.h
+#include avfilter.h
+#include formats.h
+#include internal.h
+#include video.h
+
+typedef struct {
+const AVClass *class;
+int size;
+} PaletteDebugContext;
+
+#define OFFSET(x) offsetof(PaletteDebugContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+static const AVOption palettedbg_options[] = {
+{ s, set pixel box size, OFFSET(size), AV_OPT_TYPE_INT, {.i64=30}, 1,
100, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(palettedbg);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat in_fmts[] =
Re: [FFmpeg-devel] [PATCH] avfilter: add palettedbg filter
On Thu, 15 Jan 2015 14:21:18 +0100
Clément Bœsch u...@pkh.me wrote:
From: Clément Bœsch clem...@stupeflix.com
---
Changelog| 1 +
doc/filters.texi | 13 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h| 4 +-
libavfilter/vf_palettedbg.c | 127
tests/fate/filter-video.mak | 3 +
tests/ref/fate/filter-palettedbg | 316
+++
8 files changed, 464 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/vf_palettedbg.c
create mode 100644 tests/ref/fate/filter-palettedbg
diff --git a/Changelog b/Changelog
index 4fc3800..4dd02e0 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version next:
- VOC seeking support
- Closed caption Decoder
- fspp, uspp, pp7 MPlayer postprocessing filters ported to native filters
+- palettedbg filter
version 2.5:
diff --git a/doc/filters.texi b/doc/filters.texi
index 154508c..faaeeaf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6885,6 +6885,19 @@ pad=2*iw:2*ih:ow-iw:oh-ih
@end example
@end itemize
+@section palettedbg
+
+Displays the 256 colors palette of each frame. This filter is only relevant
for
+@var{pal8} pixel format frames.
+
Maybe call it show_palette? You could make it overly fancy by rendering
the palette on top of the video frame. (I don't know what this patch
makes it look like.)
Note: some other pixfmts have a palette too (PSEUDOPAL crap).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avutil/buffer: Avoid moving the AVBufferRef to a new place in memory in av_buffer_make_writable()
On Thu, Jan 15, 2015 at 12:10:10PM +0100, wm4 wrote: On Thu, 15 Jan 2015 01:04:56 +0100 Michael Niedermayer michae...@gmx.at wrote: This allows making a AVBufferRef writable without the need to update all pointers to it Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavutil/buffer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/buffer.c b/libavutil/buffer.c index b31f034..bb112c2 100644 --- a/libavutil/buffer.c +++ b/libavutil/buffer.c @@ -159,8 +159,8 @@ int av_buffer_make_writable(AVBufferRef **pbuf) return AVERROR(ENOMEM); memcpy(newbuf-data, buf-data, buf-size); -av_buffer_unref(pbuf); -*pbuf = newbuf; + +buffer_replace(pbuf, newbuf); return 0; } So this pretty much makes the double pointer pointless, and the signature could be: int av_buffer_make_writable(AVBufferRef *pbuf); ? yes, if the change wouldnt break ABI/API (I wonder why the API didn't do this originally.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil: Added twofish block cipher
On Thu, Jan 15, 2015 at 10:21:22PM +0530, supraja reddy wrote:
Hello,
I have attached the patch for twofish implementation. Please let me know if
there are any changes to be made.
Thank you,
Supraja
Makefile |3
twofish.c | 351
++
twofish.h | 70
3 files changed, 424 insertions(+)
b2382c15f440967745b06f0243a023647c5c78eb tf.patch
From f86554850a8b0be2e32fcd341ca297c7ce73a941 Mon Sep 17 00:00:00 2001
From: Supraja Meedinti supraja0...@gmail.com
Date: Thu, 15 Jan 2015 21:35:16 +0530
Subject: [PATCH] libavutil: Added Twofish block cipher
Signed-off-by: Supraja Meedinti supraja0...@gmail.com
---
libavutil/Makefile | 3 +
libavutil/twofish.c | 351
libavutil/twofish.h | 70 +++
3 files changed, 424 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..a66677b
--- /dev/null
+++ b/libavutil/twofish.c
@@ -0,0 +1,351 @@
+/*
+ * An implementation of the TwoFish algorithm as mentioned in RFC3713
+ * 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)
+#define sk_inc 0x02020202
+#define sk_nex 0x01010101
+
+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,
+
Re: [FFmpeg-devel] [PATCH] avcodec/parser: Check that the parser return code is valid
On Fri, Jan 09, 2015 at 01:36:00PM +0100, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer michae...@gmx.at --- libavcodec/parser.c |2 ++ 1 file changed, 2 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Support dynamic loading of third-party libs
On Thu, Jan 15, 2015 at 12:37 PM, Marc Giger gigerst...@gmx.ch wrote: That's a very good point. Never thought about it in this detail. Given that fact I have to admin that dynamic loading makes less sense. There may still be some usecases e.g. vaapi where it would make sense, but this seems to be the minority. I think the most obvious benefit at this point is something that was alluded to at the beginning of the discussion: avoidance of hard dependencies. There have been times I've run into issues because a shared library FFmpeg was linked against somehow got removed or was updated and broke compatibility. Dynamic loading allows the main binary to still function correctly if this occurs, with the issue only arising if the user attempts to use the missing library, in which case the methodology of doing dynamic loading allows for a graceful exit rather than the program crashing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Enable stream copy of data
On Wed, Jan 14, 2015 at 03:11:24PM +0530, Anshul wrote:
Hi
I have enabled demuxing and muxing path for datat stream
Please find attachment
Thanks
Anshul
ffmpeg.c|2 ++
ffmpeg_opt.c| 10 ++
libavcodec/avcodec.h|1 +
libavcodec/codec_desc.c |6 ++
libavformat/Makefile|1 +
libavformat/avformat.h | 17 +
libavformat/format.c|2 ++
libavformat/mpegts.c| 43 +--
libavformat/utils.c |1 +
9 files changed, 77 insertions(+), 6 deletions(-)
40306177e8bb3e95b98060f6202b38bb8acba26a 0001-Enable-data-stream-copy.patch
From 99bcdef2bcd9aa5bd18a0a005e0826e22ad2cf63 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari anshul.ffm...@gmail.com
Date: Wed, 14 Jan 2015 15:06:50 +0530
Subject: [PATCH] Enable data stream copy
Signed-off-by: Anshul Maheshwari anshul.ffm...@gmail.com
---
ffmpeg.c| 2 ++
ffmpeg_opt.c| 10 ++
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 6 ++
libavformat/Makefile| 1 +
libavformat/avformat.h | 17 +
libavformat/format.c| 2 ++
libavformat/mpegts.c| 43 +--
libavformat/utils.c | 1 +
9 files changed, 77 insertions(+), 6 deletions(-)
applied the generic data stream handling improvments to libavformat
and ffmpeg
please update APIChanges
also
[...]
@@ -1927,6 +1932,11 @@ static int open_output_file(OptionsContext *o, const
char *filename)
}
}
/* do something with data? */
+if (!o-data_disable av_guess_codec(oc-oformat, NULL, filename,
NULL, AVMEDIA_TYPE_DATA) != AV_CODEC_ID_NONE) {
+for (i = 0; i nb_input_streams; i++)
+if (input_streams[i]-st-codec-codec_type ==
AVMEDIA_TYPE_DATA)
+new_data_stream(o, oc, i);
+}
this probably needs something more to work, like we wouldnt
want to matchup a data stream with GPS data to a scte_35 stream
iam not sure how to best do this though
for stream copy the codec_id could be used though i guess
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
