Re: [FFmpeg-devel] [PATCH]Set the default for --shlibdir to --libdir
On Sat, Dec 13, 2014 at 01:50:03AM +0100, Carl Eugen Hoyos wrote:
On Saturday 13 December 2014 01:12:02 am Ivan Kalvachev wrote:
On 12/12/14, Carl Eugen Hoyos ceho...@ag.or.at wrote:
Hi!
Attached patch fixes ticket #4183.
Please review, Carl Eugen
You should also update the configure help text, as the default is not
PREFIX/lib anymore.
New patch attached.
Thank you, Carl Eugen
diff --git a/configure b/configure
index e2e3619..0ec1a7c 100755
--- a/configure
+++ b/configure
@@ -84,7 +84,7 @@ Standard options:
--datadir=DIRinstall data files in DIR [PREFIX/share/ffmpeg]
--docdir=DIR install documentation in DIR
[PREFIX/share/doc/ffmpeg]
--libdir=DIR install libs in DIR [PREFIX/lib]
- --shlibdir=DIR install shared libs in DIR [PREFIX/lib]
+ --shlibdir=DIR install shared libs in DIR [LIBDIR]
--incdir=DIR install includes in DIR [PREFIX/include]
--mandir=DIR install man page in DIR [PREFIX/share/man]
--enable-rpath use rpath to allow installing libraries in paths
@@ -2685,7 +2685,7 @@ docdir_default='${prefix}/share/doc/ffmpeg'
incdir_default='${prefix}/include'
libdir_default='${prefix}/lib'
mandir_default='${prefix}/share/man'
-shlibdir_default=$libdir_default
+shlibdir_default='${LIBDIR}'
What if LIBDIR is not defined? (is it possible?)
Why not SHLIBDIR?
--
Clément B.
pgpnGyHfZ0YGW.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hevc_mc: fix sse register counts
Hi, 2014-12-10 8:11 GMT+01:00 Michael Niedermayer michae...@gmx.at: These fix failures of --enable-xmm-clobber-test Some old patches around the ml were I think trying to fix some of the macros, from where the superfluous regs are coming from. I guess being thorough with the ABI is better, though that particular issue has never seemed to actually cause harm. The patch was indeed fine. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Set the default for --shlibdir to --libdir
Clément Bœsch u at pkh.me writes: Attached patch fixes ticket #4183. --libdir=DIR install libs in DIR [PREFIX/lib] - --shlibdir=DIR install shared libs in DIR [PREFIX/lib] + --shlibdir=DIR install shared libs in DIR [LIBDIR] What if LIBDIR is not defined? (is it possible?) I believe you misunderstand (there are no shell variables involved afaict). I am not claiming that I am sure this patch is a good idea (I am against behaviour changes) but this was reported by a user and I believe the patch does what the user wants so a decision will have to be made: Either close as wont-fix or apply this (or a similar) patch. If you want to change the help text for the install options, please do it, I have no strong opinion. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Implement subtitle charenc guessing
Le duodi 22 frimaire, an CCXXIII, Rodger Combs a écrit : This also moves general charenc conversion from avcodec to avformat; the version in avcodec is left, but renamed; I'm not sure if that's the optimal solution. The documentation could probably use some improvements, and a few more options could be added to ENCA. This very simply prefers libguess over ENCA, and ENCA over uchardet, but will fall back on a less-preferred guess if something decodes wrong, and will drop illegal sequences in iconv if all else fails. It'd be possible to have ffmpeg.c present a UI if multiple guesses are returned, and other library consumers could do the same. So, now that I have a decent connection and time, here are some comments: First, your patch seems to happen after the text demuxers have parsed the text files. Therefore, this can not work for non-ASCII-compatible encodings, such as UTF-16. You might say that UTF-16 already works, but its implementation is bogus and leads to user-visible problems (see trac ticket #4059). But even if it was not, we would not want two competing detection layers. More importantly: the lavc API is ready to handle situations where the recoding has been done by the demuxer. See the doxy for sub_charenc_mode and the associated constants. So if you are discarding it or adding competing fields, you are certainly missing something on the proper use of the API. Of course, if you think the API is not actually ready, feel free to explain and discuss your point. Third point: detection is not something that works well, and people will frequently find versions of FFmpeg built without their favourite library. For both these reasons, applications using the library should be able to provide their own detection mechanism to complement or even replace the ones hardcoded in FFmpeg. Same goes for conversion, even if it is not as important. Fourth and last point: detecting text encoding is not useful only for text subtitles formats, other features may need it: filter graph files (think of drawtext options), ffmetadata files, etc. Here is the API I am considering. I had started to implement it until bickering and lack of enthusiasm discouraged me. The work happens in lavu, and is therefore available everywhere, replacing av_file_map() whenever it is used for text files. It is an API for reading text files / buffers / streams, taking care of all the gory details. Text encoding, of course, but also the LF / CRLF mess, possibly splitting lines at the same time, maybe normalizing spaces, etc. The text-file-read API is controlled with a context parameter, holding amongst other things a list of detection modules, and also recoding modules. Detection modules are just a structure with a callback. FFmpeg provides built-in modules, such as your proposed libguess, libenca and libuchardet code, but applications can also create their own modules. Then it is just a matter of changing the subtitle-specific FFTextReader API to use the new lavu text-file-read API. I hope this helps. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Implement subtitle charenc guessing
Rodger Combs rodger.combs at gmail.com writes: + --disable-libguess disable libguess [autodetect] + --disable-uchardet disable universalchardet [autodetect] I cannot comment on your actual patch, but both libraries should not be auto-detected imo. Imo, if your distribution contains the libraries but does not install them by default, it is a good indication that we should not auto-detect them. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hevc_mc: fix sse register counts
On Sat, Dec 13, 2014 at 11:45:27AM +0100, Christophe Gisquet wrote: Hi, 2014-12-10 8:11 GMT+01:00 Michael Niedermayer michae...@gmx.at: These fix failures of --enable-xmm-clobber-test Some old patches around the ml were I think trying to fix some of the macros, from where the superfluous regs are coming from. i remember such patches faintly too, was there one that wasnt applied ? I guess being thorough with the ABI is better, though that particular issue has never seemed to actually cause harm. The patch was indeed fine. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- 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] avcodec/x86/hevc_mc: fix sse register counts
Hi, 2014-12-13 13:17 GMT+01:00 Michael Niedermayer michae...@gmx.at: i remember such patches faintly too, was there one that wasnt applied ? Not your fault, mine actually, as I lost interest in that code. I think there were compilations issues iirc. That and multiple things (like gpr usage) needed to be fixed at the same time. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] lavu/dict: remove weird intptr_t cast
On Fri, Dec 12, 2014 at 06:15:41PM +0100, wm4 wrote: I can't come up with a reason why this would be needed. --- libavutil/dict.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) if people prefer this, i can apply it, it might cause an additional warning with some compilers though [...] -- 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
Re: [FFmpeg-devel] [PATCH] avformat: Implement subtitle charenc guessing
On Dec 13, 2014, at 05:34, Nicolas George geo...@nsup.org wrote: So, now that I have a decent connection and time, here are some comments: First, your patch seems to happen after the text demuxers have parsed the text files. Therefore, this can not work for non-ASCII-compatible encodings, such as UTF-16. You might say that UTF-16 already works, but its implementation is bogus and leads to user-visible problems (see trac ticket #4059). But even if it was not, we would not want two competing detection layers. Agreed, a single layer would be preferable. More importantly: the lavc API is ready to handle situations where the recoding has been done by the demuxer. See the doxy for sub_charenc_mode and the associated constants. So if you are discarding it or adding competing fields, you are certainly missing something on the proper use of the API. Of course, if you think the API is not actually ready, feel free to explain and discuss your point. I couldn't see a sensible way to do this in lavc, since the detector libraries generally require more than one packet to work effectively. Looking at that doxy again, I can see how the detection could be done in lavf and the conversion in lavc, but I don't really see an advantage there other than fewer API changes. Third point: detection is not something that works well, and people will frequently find versions of FFmpeg built without their favourite library. For both these reasons, applications using the library should be able to provide their own detection mechanism to complement or even replace the ones hardcoded in FFmpeg. Same goes for conversion, even if it is not as important. Yeah, a modular approach would be excellent. Fourth and last point: detecting text encoding is not useful only for text subtitles formats, other features may need it: filter graph files (think of drawtext options), ffmetadata files, etc. Here is the API I am considering. I had started to implement it until bickering and lack of enthusiasm discouraged me. The work happens in lavu, and is therefore available everywhere, replacing av_file_map() whenever it is used for text files. It is an API for reading text files / buffers / streams, taking care of all the gory details. Text encoding, of course, but also the LF / CRLF mess, possibly splitting lines at the same time, maybe normalizing spaces, etc. So, by default it'd just handle encoding, and then additional normalization features could be enabled by the consumer? Sounds useful indeed. The text-file-read API is controlled with a context parameter, holding amongst other things a list of detection modules, and also recoding modules. Detection modules are just a structure with a callback. FFmpeg provides built-in modules, such as your proposed libguess, libenca and libuchardet code, but applications can also create their own modules. I like this model in general, but it brings up a few questions that I kind of dodged in my patch. For instance, how should lavu determine which module's output to prefer if there are conflicting charenc guesses? How can the consumer choose between the given guesses? In my patch, preference is very simplistic and the order is hardcoded. In a more modular system, it'd have to be a bit more complex; I can imagine some form of scoring system, or even another type of module that ranks possible guesses, but that could get very complex very fast. Any ideas for this? In my patch, the consumer can override the choice of encoding by making changes to the AVFormatContext between header reading and retrieving the packet; it seems like the best way to do so in your system would be to pass a callback. On a bit of a side-note: my system is designed to make every possible effort to return a recoded packet, with multiple layers of fallback behavior in case the first guess turns out to be incorrect or the source file is outright invalid. I wouldn't expect that to be significantly more difficult with your design, but I wonder what your opinions on the setup are? Then it is just a matter of changing the subtitle-specific FFTextReader API to use the new lavu text-file-read API. So, the text-file-read API would buffer the entire input file and perform charenc detection/conversion and/or other normalization, then FFTextReader would read from the normalized buffer? I hope this helps. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 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 3/5] lavu/dict: remove weird intptr_t cast
I can't come up with a reason why this would be needed. Reading the commit message where this was introduced would be a good start: # commit 8aed90958d8bbf4a0652fdc56b9655ad9962fa50 # Author: Michael Niedermayer michae...@gmx.at # Date: 2011-10-17 22:56:13 +0200 # # dict: fix assignment discards qualifiers from pointer target type warnings. # # Signed-off-by: Michael Niedermayer michae...@gmx.at Le tridi 23 frimaire, an CCXXIII, Michael Niedermayer a écrit : if people prefer this, i can apply it, it might cause an additional warning with some compilers though For what it's worth, I prefer the code building with fewer warnings. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Implement subtitle charenc guessing
On Sat, 13 Dec 2014 12:34:28 +0100 Nicolas George geo...@nsup.org wrote: First, your patch seems to happen after the text demuxers have parsed the text files. Therefore, this can not work for non-ASCII-compatible encodings, such as UTF-16. You might say that UTF-16 already works, but its implementation is bogus and leads to user-visible problems (see trac ticket #4059). But even if it was not, we would not want two competing detection layers. For someone who complains about bickering and lack of enthusiasm you sure bicker and discourage a lot. What about it is bogus? #4059 is a problem with ffmpeg.c and the stuff in lavc, not the general approach. In fact, the UTF-16 change made UTF-16 just work with any API user. Recoding in the demuxer is unacceptable, because it makes it impossible to change the codepage later or get any kind of user interaction. Doing it on file opening unnecessarily complicates these things. Detection can't be done in lavc (and the way lavc does recoding, with fatal errors on failure, is also plain unacceptable). I agree with the comment though that ffmpeg isn't going to be linked to all these fancy detection mechanisms. This is mostly because you have to enable external libraries explicitly when compiling, so usually they won't be picked up. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Implement subtitle charenc guessing
Le tridi 23 frimaire, an CCXXIII, wm4 a écrit : What about it is bogus? Read the documentation. In fact, the UTF-16 change made UTF-16 just work with any API user. And inconsistent values in the context. Recoding in the demuxer is unacceptable, because it makes it impossible to change the codepage later or get any kind of user interaction. Broken application design. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] lavu/dict: remove weird intptr_t cast
On Sat, 13 Dec 2014 13:55:44 +0100 Nicolas George geo...@nsup.org wrote: I can't come up with a reason why this would be needed. Reading the commit message where this was introduced would be a good start: # commit 8aed90958d8bbf4a0652fdc56b9655ad9962fa50 # Author: Michael Niedermayer michae...@gmx.at # Date: 2011-10-17 22:56:13 +0200 # # dict: fix assignment discards qualifiers from pointer target type warnings. # # Signed-off-by: Michael Niedermayer michae...@gmx.at Sorry to disrupt your smartass moment, but I've already run blame when I first looked at it. The commit message explains nothing about the intptr_t. Le tridi 23 frimaire, an CCXXIII, Michael Niedermayer a écrit : if people prefer this, i can apply it, it might cause an additional warning with some compilers though For what it's worth, I prefer the code building with fewer warnings. A simple cast already prevents the warning. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Implement subtitle charenc guessing
On Sat, 13 Dec 2014 16:17:48 +0100 Nicolas George geo...@nsup.org wrote: Le tridi 23 frimaire, an CCXXIII, wm4 a écrit : What about it is bogus? Read the documentation. Broken library design. In fact, the UTF-16 change made UTF-16 just work with any API user. And inconsistent values in the context. What? Recoding in the demuxer is unacceptable, because it makes it impossible to change the codepage later or get any kind of user interaction. Broken application design. Broken reply. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavd/alsa-audio-common: mark default device in device list
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
libavdevice/alsa-audio-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavdevice/alsa-audio-common.c b/libavdevice/alsa-audio-common.c
index 749897f..b7f5313 100644
--- a/libavdevice/alsa-audio-common.c
+++ b/libavdevice/alsa-audio-common.c
@@ -379,6 +379,8 @@ int ff_alsa_get_device_list(AVDeviceInfoList *device_list,
snd_pcm_stream_t stre
device_list-nb_devices,
new_device)) 0) {
goto fail;
}
+if (!strcmp(new_device-device_name, default))
+device_list-default_device = device_list-nb_devices - 1;
new_device = NULL;
}
fail:
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cmdutils: use macros for device test
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
cmdutils.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/cmdutils.c b/cmdutils.c
index b68dae9..4e0a406 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -1213,12 +1213,7 @@ static int is_device(const AVClass *avclass)
{
if (!avclass)
return 0;
-return avclass-category == AV_CLASS_CATEGORY_DEVICE_VIDEO_OUTPUT ||
- avclass-category == AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT ||
- avclass-category == AV_CLASS_CATEGORY_DEVICE_AUDIO_OUTPUT ||
- avclass-category == AV_CLASS_CATEGORY_DEVICE_AUDIO_INPUT ||
- avclass-category == AV_CLASS_CATEGORY_DEVICE_OUTPUT ||
- avclass-category == AV_CLASS_CATEGORY_DEVICE_INPUT;
+return AV_IS_INPUT_DEVICE(avclass-category) ||
AV_IS_OUTPUT_DEVICE(avclass-category);
}
static int show_formats_devices(void *optctx, const char *opt, const char
*arg, int device_only)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: use macros for device test
On Sat, Dec 13, 2014 at 07:54:57PM +0100, Lukasz Marek wrote: Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com --- cmdutils.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] lavd/avdevice: replace av_ with ff_ for caps option table
This symbol is required for query capabilities callbacks.
This symbol is only required by libavdevice and should not be exported.
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
libavdevice/avdevice.c | 2 +-
libavdevice/avdevice.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index 755f251..86deb82 100644
--- a/libavdevice/avdevice.c
+++ b/libavdevice/avdevice.c
@@ -29,7 +29,7 @@
#define V AV_OPT_FLAG_VIDEO_PARAM
#define OFFSET(x) offsetof(AVDeviceCapabilitiesQuery, x)
-const AVOption av_device_capabilities[] = {
+const AVOption ff_device_capabilities[] = {
{ codec, codec, OFFSET(codec), AV_OPT_TYPE_INT,
{.i64 = AV_CODEC_ID_NONE}, AV_CODEC_ID_NONE, INT_MAX, E|D|A|V },
{ sample_format, sample format, OFFSET(sample_format), AV_OPT_TYPE_INT,
diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
index a395228..47e310b 100644
--- a/libavdevice/avdevice.h
+++ b/libavdevice/avdevice.h
@@ -415,7 +415,7 @@ typedef struct AVDeviceCapabilitiesQuery {
/**
* AVOption table used by devices to implement device capabilities API. Should
not be used by a user.
*/
-extern const AVOption av_device_capabilities[];
+extern const AVOption ff_device_capabilities[];
/**
* Initialize capabilities probing API based on AVOption API.
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavd/avdevice: use better option types for caps options
Using dedicated types allows to use format/layout names,
not just raw int values.
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
libavdevice/avdevice.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index 86deb82..e5ab0b7 100644
--- a/libavdevice/avdevice.c
+++ b/libavdevice/avdevice.c
@@ -32,16 +32,16 @@
const AVOption ff_device_capabilities[] = {
{ codec, codec, OFFSET(codec), AV_OPT_TYPE_INT,
{.i64 = AV_CODEC_ID_NONE}, AV_CODEC_ID_NONE, INT_MAX, E|D|A|V },
-{ sample_format, sample format, OFFSET(sample_format), AV_OPT_TYPE_INT,
-{.i64 = AV_SAMPLE_FMT_NONE}, -1, INT_MAX, E|D|A },
+{ sample_format, sample format, OFFSET(sample_format),
AV_OPT_TYPE_SAMPLE_FMT,
+{.i64 = AV_SAMPLE_FMT_NONE}, AV_SAMPLE_FMT_NONE, INT_MAX, E|D|A },
{ sample_rate, sample rate, OFFSET(sample_rate), AV_OPT_TYPE_INT,
{.i64 = -1}, -1, INT_MAX, E|D|A },
{ channels, channels, OFFSET(channels), AV_OPT_TYPE_INT,
{.i64 = -1}, -1, INT_MAX, E|D|A },
-{ channel_layout, channel layout, OFFSET(channel_layout),
AV_OPT_TYPE_INT64,
+{ channel_layout, channel layout, OFFSET(channel_layout),
AV_OPT_TYPE_CHANNEL_LAYOUT,
{.i64 = -1}, -1, INT_MAX, E|D|A },
-{ pixel_format, pixel format, OFFSET(pixel_format), AV_OPT_TYPE_INT,
-{.i64 = AV_PIX_FMT_NONE}, -1, INT_MAX, E|D|V },
+{ pixel_format, pixel format, OFFSET(pixel_format),
AV_OPT_TYPE_PIXEL_FMT,
+{.i64 = AV_PIX_FMT_NONE}, AV_PIX_FMT_NONE, INT_MAX, E|D|V },
{ window_size, window size, OFFSET(window_width),
AV_OPT_TYPE_IMAGE_SIZE,
{.str = NULL}, -1, INT_MAX, E|D|V },
{ frame_size, frame size, OFFSET(frame_width), AV_OPT_TYPE_IMAGE_SIZE,
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavd/avdevice: replace av_ with ff_ for caps option table
On 13/12/14 4:27 PM, Lukasz Marek wrote:
This symbol is required for query capabilities callbacks.
This symbol is only required by libavdevice and should not be exported.
This need a deprecation and an FF_API scheduled removal. We can't remove the
symbol
without a major bump.
Also, an internal.h header for stuff like this is probably a good idea.
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
libavdevice/avdevice.c | 2 +-
libavdevice/avdevice.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
index 755f251..86deb82 100644
--- a/libavdevice/avdevice.c
+++ b/libavdevice/avdevice.c
@@ -29,7 +29,7 @@
#define V AV_OPT_FLAG_VIDEO_PARAM
#define OFFSET(x) offsetof(AVDeviceCapabilitiesQuery, x)
-const AVOption av_device_capabilities[] = {
+const AVOption ff_device_capabilities[] = {
{ codec, codec, OFFSET(codec), AV_OPT_TYPE_INT,
{.i64 = AV_CODEC_ID_NONE}, AV_CODEC_ID_NONE, INT_MAX, E|D|A|V },
{ sample_format, sample format, OFFSET(sample_format),
AV_OPT_TYPE_INT,
diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
index a395228..47e310b 100644
--- a/libavdevice/avdevice.h
+++ b/libavdevice/avdevice.h
@@ -415,7 +415,7 @@ typedef struct AVDeviceCapabilitiesQuery {
/**
* AVOption table used by devices to implement device capabilities API.
Should not be used by a user.
*/
-extern const AVOption av_device_capabilities[];
+extern const AVOption ff_device_capabilities[];
/**
* Initialize capabilities probing API based on AVOption API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavd/avdevice: replace av_ with ff_ for caps option table
On 13.12.2014, at 20:42, James Almer jamr...@gmail.com wrote: On 13/12/14 4:27 PM, Lukasz Marek wrote: This symbol is required for query capabilities callbacks. This symbol is only required by libavdevice and should not be exported. This need a deprecation and an FF_API scheduled removal. We can't remove the symbol without a major bump. Well, there is a comment saying it should not be used (which raises the question why it was placed in that header though). If a search can't find anyone using it, it might not be _completely_ unreasonable to cheat and remove it without a major bump. But I have no strong opinion either way. Also, an internal.h header for stuff like this is probably a good idea. Yes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavd/avdevice: replace av_ with ff_ for caps option table
On 13.12.2014 20:48, Reimar Döffinger wrote: On 13.12.2014, at 20:42, James Almer jamr...@gmail.com wrote: On 13/12/14 4:27 PM, Lukasz Marek wrote: This symbol is required for query capabilities callbacks. This symbol is only required by libavdevice and should not be exported. This need a deprecation and an FF_API scheduled removal. We can't remove the symbol without a major bump. Well, there is a comment saying it should not be used (which raises the question why it was placed in that header though). If a search can't find anyone using it, it might not be _completely_ unreasonable to cheat and remove it without a major bump. But I have no strong opinion either way. Yes. There is a comment about that it is internal. So I don't think it is serious to rename it. We already renamed symbols, but probably in not exported headers though. Unless user created own device and implemented capabilities query, it is not used yet. It is not used in ffmpeg project. I'm about to push first implementations so I wanted to fix it before, as spotted. Also, an internal.h header for stuff like this is probably a good idea. Yes. OK, I will move it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavd/avdevice: replace av_ with ff_ for caps option table
On 13.12.2014 20:54, Lukasz Marek wrote: On 13.12.2014 20:48, Reimar Döffinger wrote: On 13.12.2014, at 20:42, James Almer jamr...@gmail.com wrote: On 13/12/14 4:27 PM, Lukasz Marek wrote: This symbol is required for query capabilities callbacks. This symbol is only required by libavdevice and should not be exported. This need a deprecation and an FF_API scheduled removal. We can't remove the symbol without a major bump. Well, there is a comment saying it should not be used (which raises the question why it was placed in that header though). If a search can't find anyone using it, it might not be _completely_ unreasonable to cheat and remove it without a major bump. But I have no strong opinion either way. Yes. There is a comment about that it is internal. So I don't think it is serious to rename it. We already renamed symbols, but probably in not exported headers though. Unless user created own device and implemented capabilities query, it is not used yet. It is not used in ffmpeg project. I'm about to push first implementations so I wanted to fix it before, as spotted. Now I have second thought, removing/renaming this symbol will not allow to do that. (to implement device outside ffmpeg project and use caps querying). It is quite long since discussion about this API and I forget context of some things. So this should stay as it is, just the comment have to be clarified it can be used just for this purpose, not to mangle with values manually Sorry for double posting. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: add colorlevels filter
On Thu, 11 Dec 2014 10:20:11 +, Paul B Mahol wrote: I added 3 examples from you. You can truncate my examples to three decimal places. I was being lazy and copy and pasted my calculated values. Looking at it again I couldn't tell a difference between the truncated ones and the long ones, but the long ones may intimidate or confuse users. The preset could be added later. I could not decipher attached ALV file. I couldn't either. Anyway, the rest of the docs LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavd/avdevice: use better option types for caps options
On Sat, Dec 13, 2014 at 08:27:08PM +0100, Lukasz Marek wrote: Using dedicated types allows to use format/layout names, not just raw int values. Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
I have tried to port fspp. Not sure, if it is correct or not.
From da23a3d94181a5d53454d3904d79a422ea1272ac Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Sun, 14 Dec 2014 12:03:31 +0530
Subject: [PATCH] Port fspp to FFmpeg
---
doc/filters.texi | 24 +
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/version.h |2 +-
libavfilter/vf_fspp.c | 324 +++
libavfilter/vf_fspp.h | 393 +
libavfilter/x86/Makefile |1 +
libavfilter/x86/vf_fspp.c | 1390 +
8 files changed, 2135 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vf_fspp.c
create mode 100644 libavfilter/vf_fspp.h
create mode 100644 libavfilter/x86/vf_fspp.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 882caa0..eefc507 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4997,6 +4997,30 @@ frei0r=perspective:0.2/0.2|0.8/0.2
For more information, see
@url{http://frei0r.dyne.org}
+@section fspp
+
+Faster version of the simple postprocessing filter - @ref{spp}.
+
+The filter accepts the following options:
+
+@table @option
+@item quality
+Set quality. This option defines the number of levels for averaging. It accepts
+an integer in the range 0-5. If set to @code{0}, the filter will have no
+effect. A value of @code{5} means the higher quality. For each increment of
+that value the speed drops by a factor of approximately 2. Default value is
+@code{4}.
+
+@item qp
+Force a constant quantization parameter. If not set, the filter will use the QP
+from the video stream (if available).
+
+@item use_bframe_qp
+Enable the use of the QP from the B-Frames if set to @code{1}. Using this
+option may cause flicker since the B-Frames have often larger QP. Default is
+@code{0} (not enabled).
+@end table
+
@section geq
The filter accepts the following options:
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6b7291e..8c523b4 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -125,6 +125,7 @@ OBJS-$(CONFIG_FRAMESTEP_FILTER) += vf_framestep.o
OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
OBJS-$(CONFIG_FRAMEPACK_FILTER) += vf_framepack.o
OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
+OBJS-$(CONFIG_FSPP_FILTER) += vf_fspp.o
OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
OBJS-$(CONFIG_HALDCLUT_FILTER) += vf_lut3d.o dualinput.o framesync.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index adb86be..4a915c7 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -141,6 +141,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(FRAMEPACK, framepack, vf);
REGISTER_FILTER(FRAMESTEP, framestep, vf);
REGISTER_FILTER(FREI0R, frei0r, vf);
+REGISTER_FILTER(FSPP, fspp, vf);
REGISTER_FILTER(GEQ,geq,vf);
REGISTER_FILTER(GRADFUN,gradfun,vf);
REGISTER_FILTER(HALDCLUT, haldclut, vf);
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 4bd18f3..22e3706 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
#define LIBAVFILTER_VERSION_MAJOR 5
#define LIBAVFILTER_VERSION_MINOR 2
-#define LIBAVFILTER_VERSION_MICRO 104
+#define LIBAVFILTER_VERSION_MICRO 105
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_fspp.c b/libavfilter/vf_fspp.c
new file mode 100644
index 000..c8a05df
--- /dev/null
+++ b/libavfilter/vf_fspp.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (c) 2003 Michael Niedermayer michae...@gmx.at
+ * Copyright (C) 2005 Nikolaj Poroshin poro...@psu.ru
+ * Copyright (c) 2014 Arwa Arif arwaarif1...@gmail.com
+ *
+ * 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
+ * Fast Simple Post-processing filter
+ * This implementation is based on an algorithm described in
+ * Aria Nosratinia Embedded Post-Processing for
+ * Enhancement of Compressed Images (1999)
+ *
