Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 3:49 AM, Hendrik Leppkes wrote: > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes wrote: >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: 0001-avfilter-add-libebur128-port.patch This first patch ports libebur128 to ffmpeg. I haven't re-indented these yet, so please diff `ebur128.c' and `ebur128.h' with the original libebur128 files[1][2] to see what has changed. Also included is `queue.h' which comes from BSD, which AFAIK should be distributable if we decide to go this route. All these files still need their license header, as libebur128 is MIT licensed and needs its own copyright message. One other thing to take a look at is the section with the sse2 optimizations - does FFmpeg already have a macro we could use for this? 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch This patch removes the libebur128 dependency for the loudnorm and uses the new internal ebur128 API. >>> >>> Hi, >>> >>> Two updated patches attached. This is the libebur128 port and the >>> af_loudnorm update. Please review if you can, as I'd like to try push >>> these before v3.1. Updates to af_astats and f_ebur128 to use this new >>> API will be coming in the near future as well. >>> >> >> The libebur128 port still contains global state (ie. static data >> initialized at runtime), as commented on in the earlier reviews can >> you get rid of those and move them into a library context (ie. not >> static globals)? >> We really don't like global state like this because of thread safety issues. >> > > Also, in general I must say I really don't like the idea or the > precedence this sets of porting complex external libraries into the > avfilter code. > Whats wrong with simply linking the library when you want to use it? > This is how it works for everything else, what makes this different to > warrant such a step? Hi, af_loudnorm currently links libebur128. The port makes sense because libebur128 is tiny, MIT-licensed, has a good API, and would be useful in several filters. Perceptual loudness has become an important topic in broadcasting and audio in general, and it'd be nice to provide these filters to everybody without having to link an external library. FFmpeg already has some ebur128 logic in f_ebur128, which I was initially interested in breaking out into something reusable, but found libebur128 was better suited for this. This was discussed last month when the loudnorm filter was pushed, and also with the expectation that libebur128 would be ported to FFmpeg. Briefly, libebur128 allows several modes of measurement, custom channel mappings, doesn't require resampling the input stream, is faster, and has a reusable API. Thanks, Kyle > > - Hendrik > ___ > 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][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 6:00 AM, Clément Bœsch wrote: > On Sat, Jun 18, 2016 at 12:58:59PM +0200, Paul B Mahol wrote: >> On 6/18/16, Clement Boesch wrote: >> > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: >> >> On 6/18/16, Hendrik Leppkes wrote: >> >> > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes >> >> > wrote: >> >> >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >> >> >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: >> >> >> >> 0001-avfilter-add-libebur128-port.patch >> >> This first patch ports libebur128 to ffmpeg. I haven't re-indented >> >> these yet, so please diff `ebur128.c' and `ebur128.h' with the >> >> original libebur128 files[1][2] to see what has changed. Also >> >> included >> >> is `queue.h' which comes from BSD, which AFAIK should be >> >> distributable >> >> if we decide to go this route. All these files still need their >> >> license header, as libebur128 is MIT licensed and needs its own >> >> copyright message. One other thing to take a look at is the section >> >> with the sse2 optimizations - does FFmpeg already have a macro we >> >> could use for this? >> >> >> >> >> >> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >> >> This patch removes the libebur128 dependency for the loudnorm and >> >> uses >> >> the new internal ebur128 API. >> >> >> >> >>> >> >> >>> Hi, >> >> >>> >> >> >>> Two updated patches attached. This is the libebur128 port and the >> >> >>> af_loudnorm update. Please review if you can, as I'd like to try push >> >> >>> these before v3.1. Updates to af_astats and f_ebur128 to use this >> >> >>> new >> >> >>> API will be coming in the near future as well. >> >> >>> >> >> >> >> >> >> The libebur128 port still contains global state (ie. static data >> >> >> initialized at runtime), as commented on in the earlier reviews can >> >> >> you get rid of those and move them into a library context (ie. not >> >> >> static globals)? >> >> >> We really don't like global state like this because of thread safety >> >> >> issues. >> >> >> >> >> > >> >> > Also, in general I must say I really don't like the idea or the >> >> > precedence this sets of porting complex external libraries into the >> >> > avfilter code. >> >> > Whats wrong with simply linking the library when you want to use it? >> >> > This is how it works for everything else, what makes this different to >> >> > warrant such a step? >> >> >> >> Because f_ebur128 is GPL and unlikely to get relicensed. >> > >> > 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not >> >> But you are blocking other ebur128 implementation to be used in f_ebur128.c > > Yes but not because of licence issues. > Clément, you do great work here and I've used f_ebur128 for years. Understand, I'm just trying to make improvements. > -- > Clément B. > > ___ > 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] transcoding udp stream to HLS, using ffmpeg and ffserver
Hello all I try to transcode udp stream to HLS and quality is not good. Please kan you help me with some advice how to trascode udp stream. i have read for this problem but i could not find any thing. Best Regards Aurel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)
2016-06-18 13:46 GMT+02:00 Michael Niedermayer : > On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote: > > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer : > > > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote: > > > > Hi, > > > > > > > > i'm posting here for a feature that is missing in ffmpeg (or may be i > > > > missed something), which consist of decoding H.264 frame with a > scaling > > > > factor of 1/2, 1/4, 1/8... > > > > > > > > I found the parameter lowres, which works well with MJPEG stream but > it's > > > > not working with the H.264 decoder. > > > > > > > > I don't know if it's something possible to implement in the decoder, > but > > > if > > > > yes, my compagny agreed to sponsor the feature (depending on the > cost of > > > > course), if a developer qualified is interested to do it. > > > > > > > > Is someone know if it is possible, and if it can exist someone > interested > > > > to develop this feature? > > > > > > is it acceptable if the encoder enforces some restrictions on the used > > > features ? > > > > > > most general h264 likely cannot efficiently be decoded in lower > > > resolution with acceptable quality > > > Restricting the used intra modes may make it possible to do it though > > > i dont know what the quality would be but better than without > > > restrictions > > > > > > [...] > > > > > > > > > Actually, the main goal is for motion detection algorithm, so we need > small > > resolution and best quality is not required. We just need good estimation > > for the moving pixel. > > > > For now, we decode in H.264, and scale it close 320x240, the then we > > perform motion detection on it. The goal is to speed up the process and > > reduce the memory usage since decoding a 2048x1536 picture lead around a > 5 > > MB for the decoded image in memory. > > > > So i think it could be OK. > > i dont think that withut restrictions it would be good enough for > motion detection > I don't really understand what will be changed in the decoder with or without restriction... But do you think it is possible to get (with or without the restriction) an acceptable result with saving memory and/or CPU time? > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No great genius has ever existed without some touch of madness. -- > Aristotle > > ___ > 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] lavf: add libopenmpt demuxer
On Sun, Jun 19, 2016 at 12:40:57AM +0100, Josh de Kock wrote:
[...]
> +#define OFFSET(x) offsetof(OpenMPTContext, x)
> +#define A AV_OPT_FLAG_AUDIO_PARAM
> +#define D AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption options[] = {
> +{"sample_rate", "set sample rate",
> OFFSET(sample_rate), AV_OPT_TYPE_INT,{.i64 = 44100},
> 1000, INT_MAX, A|D},
> +{"layout", "set channel layout (default: stereo)", OFFSET(layout),
> AV_OPT_TYPE_CHANNEL_LAYOUT, {.i64 = AV_CH_LAYOUT_STEREO}, 0,
> INT64_MAX, A|D},
You can drop "(default: stereo)". If it doesn't appear in "ffmpeg -h
demuxer=libopenmpt" then libavutil/opt.c needs some patching (to use
av_get_channel_layout_string()).
> +{NULL}
> +};
> +
> +static void openmpt_logfunc(const char *message, void *userdata)
> +{
> +int level = AV_LOG_INFO;
> +if (strstr(message, "ERROR") != NULL) {
> +level = AV_LOG_ERROR;
> +}
> +av_log(userdata, level, "%s\n", message);
> +}
> +
> +static int probe_openmpt(AVProbeData *p)
> +{
> +FILE *file = fopen(p->filename, "rb");
Someone needs to confirm, but I wonder if filename can't be NULL under
certain circomstances. Also, you need to check the return value of
fopen().
> +double ret =
> openmpt_could_open_propability(openmpt_stream_get_file_callbacks(), file,
> 1.0, openmpt_logfunc, NULL);
pro...pa?
not proba?
> +fclose(file);
> +return ret ? ret * AVPROBE_SCORE_MAX : 0;
> +}
[...]
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +avpriv_set_pts_info(st, 64, 1, 1000);
> +if (st->duration > 0)
> +st->duration = (int64_t)(openmpt->duration*AV_TIME_BASE+0.5);
llrint()?
[...]
> +AVInputFormat ff_libopenmpt_demuxer = {
> +.name = "libopenmpt",
> +.long_name = NULL_IF_CONFIG_SMALL("Tracker formats (libopenmpt)"),
> +.priv_data_size = sizeof(OpenMPTContext),
> +.read_probe = probe_openmpt,
> +.read_header= read_header_openmpt,
> +.read_packet= read_packet_openmpt,
> +.read_close = read_close_openmpt,
> +.read_seek = read_seek_openmpt,
> +.priv_class = &class_openmpt,
> +.extensions = "mod",
Can you extend this list of extensions? libmodplug has the following
monster:
669,abc,amf,ams,dbm,dmf,dsm,far,it,mdl,med,mid,mod,mt2,mtm,okt,psm,ptm,s3m,stm,ult,umx,xm,itgz,itr,itz,mdgz,mdr,mdz,s3gz,s3r,s3z,xmgz,xmr,xmz
Does libopenmpt documentation (or source) provide such a list?
Anyway, aside from these things, next iteration should be good to go.
Thanks.
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] lavf: add libopenmpt demuxer
Fixes ticket #5623
TODO: bump lavf minor
---
Changelog| 1 +
configure| 4 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/libopenmpt.c | 188 +++
5 files changed, 195 insertions(+)
create mode 100644 libavformat/libopenmpt.c
diff --git a/Changelog b/Changelog
index 49bb557..5956a62 100644
--- a/Changelog
+++ b/Changelog
@@ -42,6 +42,7 @@ version :
- OpenExr improvements (tile data and B44/B44A support)
- BitJazz SheerVideo decoder
- CUDA CUVID H264/HEVC decoder
+- libopenmpt demuxer
version 3.0:
diff --git a/configure b/configure
index a220fa1..6fea69b 100755
--- a/configure
+++ b/configure
@@ -249,6 +249,7 @@ External library support:
--enable-libopencv enable video filtering via libopencv [no]
--enable-libopenh264 enable H.264 encoding via OpenH264 [no]
--enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no]
+ --enable-libopenmpt enable decoding tracked files via libopenmpt [no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
@@ -1496,6 +1497,7 @@ EXTERNAL_LIBRARY_LIST="
libopencv
libopenh264
libopenjpeg
+libopenmpt
libopus
libpulse
librtmp
@@ -2760,6 +2762,7 @@ libopencore_amrwb_decoder_deps="libopencore_amrwb"
libopenh264_encoder_deps="libopenh264"
libopenjpeg_decoder_deps="libopenjpeg"
libopenjpeg_encoder_deps="libopenjpeg"
+libopenmpt_demuxer_deps="libopenmpt"
libopus_decoder_deps="libopus"
libopus_encoder_deps="libopus"
libopus_encoder_select="audio_frame_queue"
@@ -5667,6 +5670,7 @@ enabled libopenjpeg && { check_lib
openjpeg-2.1/openjpeg.h opj_version -lo
check_lib openjpeg-1.5/openjpeg.h opj_version
-lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg
-DOPJ_STATIC ||
die "ERROR: libopenjpeg not found"; }
+enabled libopenmpt&& require_pkg_config libopenmpt
libopenmpt/libopenmpt.h openmpt_module_create
enabled libopus && require_pkg_config opus opus_multistream.h
opus_multistream_decoder_create
enabled libpulse && require_pkg_config libpulse pulse/pulseaudio.h
pa_context_new
enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h
RTMP_Socket
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 813872b..c9b0d14 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -522,6 +522,7 @@ OBJS-$(CONFIG_LIBGME_DEMUXER)+= libgme.o
OBJS-$(CONFIG_LIBMODPLUG_DEMUXER)+= libmodplug.o
OBJS-$(CONFIG_LIBNUT_DEMUXER)+= libnut.o
OBJS-$(CONFIG_LIBNUT_MUXER) += libnut.o
+OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
OBJS-$(CONFIG_LIBRTMP) += librtmp.o
OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ddf540c..de445b0 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -370,6 +370,7 @@ void av_register_all(void)
REGISTER_DEMUXER (LIBGME, libgme);
REGISTER_DEMUXER (LIBMODPLUG, libmodplug);
REGISTER_MUXDEMUX(LIBNUT, libnut);
+REGISTER_DEMUXER (LIBOPENMPT, libopenmpt);
initialized = 1;
}
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
new file mode 100644
index 000..4db820d
--- /dev/null
+++ b/libavformat/libopenmpt.c
@@ -0,0 +1,188 @@
+/*
+ * Tracked MOD demuxer (libopenmpt)
+ * Copyright (c) 2016 Josh de Kock
+ *
+ * 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
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct OpenMPTContext {
+const AVClass *class;
+openmpt_module *module;
+
+int channels;
+double duration;
+/* options */
+int sample_rate;
+int64_t layout;
+} OpenMPTContext;
+
+#define OFFSET(x) offsetof(OpenMPTCont
Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)
On Sun, Jun 19, 2016 at 09:59:22AM +0200, Eric Beuque wrote: > 2016-06-18 13:46 GMT+02:00 Michael Niedermayer : > > > On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote: > > > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer : > > > > > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote: > > > > > Hi, > > > > > > > > > > i'm posting here for a feature that is missing in ffmpeg (or may be i > > > > > missed something), which consist of decoding H.264 frame with a > > scaling > > > > > factor of 1/2, 1/4, 1/8... > > > > > > > > > > I found the parameter lowres, which works well with MJPEG stream but > > it's > > > > > not working with the H.264 decoder. > > > > > > > > > > I don't know if it's something possible to implement in the decoder, > > but > > > > if > > > > > yes, my compagny agreed to sponsor the feature (depending on the > > cost of > > > > > course), if a developer qualified is interested to do it. > > > > > > > > > > Is someone know if it is possible, and if it can exist someone > > interested > > > > > to develop this feature? > > > > > > > > is it acceptable if the encoder enforces some restrictions on the used > > > > features ? > > > > > > > > most general h264 likely cannot efficiently be decoded in lower > > > > resolution with acceptable quality > > > > Restricting the used intra modes may make it possible to do it though > > > > i dont know what the quality would be but better than without > > > > restrictions > > > > > > > > [...] > > > > > > > > > > > > > Actually, the main goal is for motion detection algorithm, so we need > > small > > > resolution and best quality is not required. We just need good estimation > > > for the moving pixel. > > > > > > For now, we decode in H.264, and scale it close 320x240, the then we > > > perform motion detection on it. The goal is to speed up the process and > > > reduce the memory usage since decoding a 2048x1536 picture lead around a > > 5 > > > MB for the decoded image in memory. > > > > > > So i think it could be OK. > > > > i dont think that withut restrictions it would be good enough for > > motion detection > > > > I don't really understand what will be changed in the decoder with or > without restriction... some of the features of h.264 will not decode "right" without the full resolution > But do you think it is possible to get (with or > without the restriction) an acceptable result with saving memory and/or CPU > time? memory usage should be reduced, cpu probably less so, the whole bitstream still needs to be decoded. also if you are in control of the encoder to restrict what it does it may be simpler to use mpeg4-asp, H.263 or mpeg2 which have lowres support in FFmpeg without these problems [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] transcoding udp stream to HLS, using ffmpeg and ffserver
Aurel Thanasi ffmpeg.org> writes: > I try to transcode udp stream to HLS and quality is not good. Please read https://ffmpeg.org/contact.html again. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter
On 2/7/2016 8:39 PM, Thomas Mundt wrote:
> +@item deint
> +Specify which frames to deinterlace. Accept one of the following
> +values:
> +
> +@table @option
> +@item 0, all
> +Deinterlace all frames.
> +@item 1, interlaced
> +Only deinterlace frames marked as interlaced.
> +@end table
> +
> +The default value is @code{all}.
This...
[...]
> +{ "deint", "specify which frames to deinterlace", OFFSET(deint),
> AV_OPT_TYPE_INT, {.i64=BWDIF_DEINT_INTERLACED}, 0, 1, FLAGS, "deint" },
...and this don't match. So either fix the docs line or change the
default here.
Bump lavfi micro version of you change the default.
For the record, every other deinterlace filter seems to default to
"all".
> +CONST("all","deinterlace all frames",
> BWDIF_DEINT_ALL,"deint"),
> +CONST("interlaced", "only deinterlace frames marked as interlaced",
> BWDIF_DEINT_INTERLACED, "deint"),
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec{, _h264}: set FF_CODEC_CAP_SETS_PKT_DTS capability
On Fri, Jun 17, 2016 at 09:47:35AM +0200, Matthieu Bouron wrote: > From: Matthieu Bouron > > And sets frames pkt_dts to AV_NOPTS_VALUE as we do not want lavc/utils > to overwrite the field with incorrect values as the decoder is > asynchronous. If there is no objection, I will push the patch in one day. Matthieu [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/magicyuv: fix undefined behaviour introduced in 8a135a55b
Order of evaluation of parameters in C is not defined.
---
libavcodec/magicyuv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
index ce0ea9b..3bb4c5a 100644
--- a/libavcodec/magicyuv.c
+++ b/libavcodec/magicyuv.c
@@ -245,7 +245,7 @@ static int decode_frame(AVCodecContext *avctx,
AVFrame *p = data;
GetByteContext gb;
GetBitContext b;
-int i, j, k;
+int i, j, k, width, height;
bytestream2_init(&gb, avpkt->data, avpkt->size);
if (bytestream2_get_le32(&gb) != MKTAG('M','A','G','Y'))
@@ -309,7 +309,9 @@ static int decode_frame(AVCodecContext *avctx,
s->interlaced = !!(bytestream2_get_byte(&gb) & 2);
bytestream2_skip(&gb, 3);
-if ((ret = ff_set_dimensions(avctx, bytestream2_get_le32(&gb),
bytestream2_get_le32(&gb))) < 0)
+width = bytestream2_get_le32(&gb);
+height = bytestream2_get_le32(&gb);
+if ((ret = ff_set_dimensions(avctx, width, height)) < 0)
return ret;
slice_width = bytestream2_get_le32(&gb);
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/magicyuv: fix undefined behaviour introduced in 8a135a55b
On 6/19/16, Clement Boesch wrote:
> Order of evaluation of parameters in C is not defined.
> ---
> libavcodec/magicyuv.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
> index ce0ea9b..3bb4c5a 100644
> --- a/libavcodec/magicyuv.c
> +++ b/libavcodec/magicyuv.c
> @@ -245,7 +245,7 @@ static int decode_frame(AVCodecContext *avctx,
> AVFrame *p = data;
> GetByteContext gb;
> GetBitContext b;
> -int i, j, k;
> +int i, j, k, width, height;
>
> bytestream2_init(&gb, avpkt->data, avpkt->size);
> if (bytestream2_get_le32(&gb) != MKTAG('M','A','G','Y'))
> @@ -309,7 +309,9 @@ static int decode_frame(AVCodecContext *avctx,
> s->interlaced = !!(bytestream2_get_byte(&gb) & 2);
> bytestream2_skip(&gb, 3);
>
> -if ((ret = ff_set_dimensions(avctx, bytestream2_get_le32(&gb),
> bytestream2_get_le32(&gb))) < 0)
> +width = bytestream2_get_le32(&gb);
> +height = bytestream2_get_le32(&gb);
> +if ((ret = ff_set_dimensions(avctx, width, height)) < 0)
> return ret;
>
> slice_width = bytestream2_get_le32(&gb);
> --
> 2.8.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
ok
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/magicyuv: fix undefined behaviour introduced in 8a135a55b
On Sun, Jun 19, 2016 at 07:00:50PM +0200, Paul B Mahol wrote:
> On 6/19/16, Clement Boesch wrote:
> > Order of evaluation of parameters in C is not defined.
> > ---
> > libavcodec/magicyuv.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
> > index ce0ea9b..3bb4c5a 100644
> > --- a/libavcodec/magicyuv.c
> > +++ b/libavcodec/magicyuv.c
> > @@ -245,7 +245,7 @@ static int decode_frame(AVCodecContext *avctx,
> > AVFrame *p = data;
> > GetByteContext gb;
> > GetBitContext b;
> > -int i, j, k;
> > +int i, j, k, width, height;
> >
> > bytestream2_init(&gb, avpkt->data, avpkt->size);
> > if (bytestream2_get_le32(&gb) != MKTAG('M','A','G','Y'))
> > @@ -309,7 +309,9 @@ static int decode_frame(AVCodecContext *avctx,
> > s->interlaced = !!(bytestream2_get_byte(&gb) & 2);
> > bytestream2_skip(&gb, 3);
> >
> > -if ((ret = ff_set_dimensions(avctx, bytestream2_get_le32(&gb),
> > bytestream2_get_le32(&gb))) < 0)
> > +width = bytestream2_get_le32(&gb);
> > +height = bytestream2_get_le32(&gb);
> > +if ((ret = ff_set_dimensions(avctx, width, height)) < 0)
> > return ret;
> >
> > slice_width = bytestream2_get_le32(&gb);
> > --
> > 2.8.3
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> ok
applied, thanks
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to extract PPS/SPS
On Mon, Jun 13, 2016 at 02:37:29PM +0200, Matthieu Bouron wrote:
> On Mon, Jun 13, 2016 at 12:23:07PM +0200, Hendrik Leppkes wrote:
> > On Mon, Jun 13, 2016 at 11:51 AM, Matthieu Bouron
> > wrote:
> > > On Fri, Jun 10, 2016 at 03:08:48PM +0200, Matthieu Bouron wrote:
> > >> From: Matthieu Bouron
> > >>
> > >> Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
> > >> to be set in their respective csd-{0,1} buffers.
> > >> ---
> > >>
> > >> Hello,
> > >>
> > >> The attached patch fixes playback of HLS streams on MediaTek devices
> > >> which
> > >> requires PPS/SPS to be set in their respetive csd-{0,1} buffers (instead
> > >> of
> > >> having sps+pps in the csd-0 which works on other devices).
> > >>
> > >> I'm not sure if I can use the ff_h264_decode_extradata this way (or at
> > >> least
> > >> initialize the H264Context with zeroes minus the avctx field).
> > >
> > > Rebased patch (after the h264 ps merged) attached.
> > >
> > > I still have the same question, is my use of
> > > H264Context + ff_h264_decode_extradata correct ?
> > >
> >
> > Using H264 decoder internals seems to be a rather unfortunate
> > solution, as its prone to breakage, often subtle, as the h264 decoder
> > gets changed and not all inter-module dependencies are known.
> > So if possible at all, not using something that uses H264Context for
> > example would be nice.
> >
> > For the record, ff_h264_decode_extradata is scheduled for refactoring
> > to make it independent of H264Context so it can be more easily shared
> > with the h264 decoder and the h264 parser.
> > Once that is done, it may give you a cleaner interface to use it from
> > mediacodec as well.
>
> Ok. I can wait for the refactor to be merged but the MediaCodec decoder
> will remain broken on those devices. I'm not too happy about that if a
> release is to be made in those following days. Do we have an ETA ? I'm
> also not too happy to write the same parsing code as I did before for the
> AVCC format to split/extract the PPS/SPS.
>
> Or ..., I can push this code (if its use is valid) and update it when the
> merge lands (I'm helping Clément with the merges, so I will take care
> about this part).
Updated patch attached (using the new ff_h264_decode_extradata API).
Matthieu
>From 30d70187e10f09231a59a255204c810d1662336b Mon Sep 17 00:00:00 2001
From: Matthieu Bouron
Date: Fri, 10 Jun 2016 13:16:09 +0200
Subject: [PATCH] lavc/mediacodecdec_h264: use ff_h264_decode_extradata to
extract PPS/SPS
Fixes playback of HLS streams on MediaTek devices which requires PPS/SPS
to be set in their respective csd-{0,1} buffers.
---
configure | 2 +-
libavcodec/mediacodecdec_h264.c | 140 +---
2 files changed, 30 insertions(+), 112 deletions(-)
diff --git a/configure b/configure
index a220fa1..eb08478 100755
--- a/configure
+++ b/configure
@@ -2548,7 +2548,7 @@ h264_d3d11va_hwaccel_select="h264_decoder"
h264_dxva2_hwaccel_deps="dxva2"
h264_dxva2_hwaccel_select="h264_decoder"
h264_mediacodec_decoder_deps="mediacodec"
-h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser"
+h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_decoder h264_parser"
h264_mmal_decoder_deps="mmal"
h264_mmal_decoder_select="mmal"
h264_mmal_hwaccel_deps="mmal"
diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 52e48ae..b63b395 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -32,6 +32,7 @@
#include "libavutil/atomic.h"
#include "avcodec.h"
+#include "h264.h"
#include "internal.h"
#include "mediacodecdec.h"
#include "mediacodec_wrapper.h"
@@ -50,104 +51,6 @@ typedef struct MediaCodecH264DecContext {
} MediaCodecH264DecContext;
-static int h264_extradata_to_annexb_sps_pps(AVCodecContext *avctx,
-uint8_t **extradata_annexb, int *extradata_annexb_size,
-int *sps_offset, int *sps_size,
-int *pps_offset, int *pps_size)
-{
-uint16_t unit_size;
-uint64_t total_size = 0;
-
-uint8_t i, j, unit_nb;
-uint8_t sps_seen = 0;
-uint8_t pps_seen = 0;
-
-const uint8_t *extradata;
-static const uint8_t nalu_header[4] = { 0x00, 0x00, 0x00, 0x01 };
-
-if (avctx->extradata_size < 8) {
-av_log(avctx, AV_LOG_ERROR,
-"Too small extradata size, corrupted stream or invalid MP4/AVCC bitstream\n");
-return AVERROR(EINVAL);
-}
-
-*extradata_annexb = NULL;
-*extradata_annexb_size = 0;
-
-*sps_offset = *sps_size = 0;
-*pps_offset = *pps_size = 0;
-
-extradata = avctx->extradata + 4;
-
-/* skip length size */
-extradata++;
-
-for (j = 0; j < 2; j ++) {
-
-if (j == 0) {
-/* number of sps unit(s) */
-unit_nb = *extradata++ & 0x1f;
-} else {
-/* number of pps unit(s) */
-unit_nb = *extradata++;
-}
-
-for (i = 0; i < unit_nb; i++) {
-int err;
-
Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter
James Almer schrieb am So, 19.6.2016:
>On 2/7/2016 8:39 PM, Thomas Mundt wrote:
>> + at item deint
>> +Specify which frames to deinterlace. Accept one of the following
>> +values:
>> +
>> + at table @option
>> + at item 0, all
>> +Deinterlace all frames.
>> + at item 1, interlaced
>> +Only deinterlace frames marked as interlaced.
>> + at end table
>> +
>> +The default value is @code{all}.
>
>This...
>
>[...]
>
>> +{ "deint", "specify which frames to deinterlace", OFFSET(deint),
>> AV_OPT_TYPE_INT, {.i64=BWDIF_DEINT_INTERLACED}, 0, 1, FLAGS, "deint" },
>
>...and this don't match. So either fix the docs line or change the
>default here.
>Bump lavfi micro version of you change the default.
>
>For the record, every other deinterlace filter seems to default to
>"all".
>
>> +CONST("all","deinterlace all frames",
>> BWDIF_DEINT_ALL,"deint"),
>> +CONST("interlaced", "only deinterlace frames marked as interlaced",
>> BWDIF_DEINT_INTERLACED, "deint"),
Oops, I also placed the documentation at the wrong alphabetical position.
Patches attached.
Sorry about that!!
Thomas
0001-avfilter-vf_bwdif-Change-default-to-deinterlace-all-.patch
Description: Binary data
0002-doc-filters.texi-Move-bwdif-to-correct-alphabetical-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSoC] Motion Interpolation
On Fri, Jun 17, 2016 at 11:45:51PM +0200, Michael Niedermayer wrote: > On Fri, Jun 17, 2016 at 08:19:00AM +, Davinder Singh wrote: [...] > Can i see your current "work in progress" ? I found https://github.com/dsmudhar/FFmpeg, i somehow wasnt aware of that repo even though you posted it in a patch previously, i must have missed that. [...] -- 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] [PATCHv3] lavf: add libopenmpt demuxer
On Sun, Jun 19, 2016 at 12:49:56PM +0100, Josh de Kock wrote:
[...]
> +static int probe_openmpt(AVProbeData *p)
> +{
> +if(!p->filename)
> +return AVERROR(enoent);
> +
I'd say return 0 here instead
> +FILE *file = fopen(p->filename, "rb");
> +if (!file)
> +return AVERROR(errno);
> +
> +double ret =
> openmpt_could_open_propability(openmpt_stream_get_file_callbacks(), file,
> 1.0, openmpt_logfunc, NULL);
Please move the declaration of file and ret at the beginning of the scope
> +fclose(file);
> +return ret ? ret * AVPROBE_SCORE_MAX : 0;
So apparently this breaks FATE as it detects some random mp3 and others as
supported. You probably need to lower it down a lot, something like ret *
AVPROBE_SCORE_EXTENSION/2 or something.
[...]
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/udp: replace packet_gap with bitrate option
On Mon, 13 Jun 2016, Michael Niedermayer wrote: On Sun, Jun 12, 2016 at 09:30:18PM +0200, Marton Balint wrote: We haven't had a stable release since the packet_gap addition, so probably it is worth reworking the option to something that makes more sense to the end user. Also add burst_bits option to specify maximum length of bit bursts. Signed-off-by: Marton Balint --- doc/protocols.texi| 9 +++-- libavformat/udp.c | 51 +-- libavformat/version.h | 2 +- 3 files changed, 41 insertions(+), 21 deletions(-) iam in favor of both patches Thanks, pushed both. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/version: Change the version bumping comment
On Mon, Jun 13, 2016 at 01:10:07PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/version.h |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/api/api-codec-param-test: Do not directly access caps_internal
On Thu, Jun 16, 2016 at 03:35:26PM +0200, Michael Niedermayer wrote: > The caps_internal field has moved without major bump and direct > access causes crashes, found when testing 3.1 > > Signed-off-by: Michael Niedermayer > --- > tests/api/api-codec-param-test.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)
2016-06-19 16:14 GMT+02:00 Michael Niedermayer : > On Sun, Jun 19, 2016 at 09:59:22AM +0200, Eric Beuque wrote: > > 2016-06-18 13:46 GMT+02:00 Michael Niedermayer : > > > > > On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote: > > > > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer > : > > > > > > > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote: > > > > > > Hi, > > > > > > > > > > > > i'm posting here for a feature that is missing in ffmpeg (or may > be i > > > > > > missed something), which consist of decoding H.264 frame with a > > > scaling > > > > > > factor of 1/2, 1/4, 1/8... > > > > > > > > > > > > I found the parameter lowres, which works well with MJPEG stream > but > > > it's > > > > > > not working with the H.264 decoder. > > > > > > > > > > > > I don't know if it's something possible to implement in the > decoder, > > > but > > > > > if > > > > > > yes, my compagny agreed to sponsor the feature (depending on the > > > cost of > > > > > > course), if a developer qualified is interested to do it. > > > > > > > > > > > > Is someone know if it is possible, and if it can exist someone > > > interested > > > > > > to develop this feature? > > > > > > > > > > is it acceptable if the encoder enforces some restrictions on the > used > > > > > features ? > > > > > > > > > > most general h264 likely cannot efficiently be decoded in lower > > > > > resolution with acceptable quality > > > > > Restricting the used intra modes may make it possible to do it > though > > > > > i dont know what the quality would be but better than without > > > > > restrictions > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > Actually, the main goal is for motion detection algorithm, so we need > > > small > > > > resolution and best quality is not required. We just need good > estimation > > > > for the moving pixel. > > > > > > > > For now, we decode in H.264, and scale it close 320x240, the then we > > > > perform motion detection on it. The goal is to speed up the process > and > > > > reduce the memory usage since decoding a 2048x1536 picture lead > around a > > > 5 > > > > MB for the decoded image in memory. > > > > > > > > So i think it could be OK. > > > > > > i dont think that withut restrictions it would be good enough for > > > motion detection > > > > > > > I don't really understand what will be changed in the decoder with or > > without restriction... > > some of the features of h.264 will not decode "right" without the > full resolution > Ok what features do you mean? Maybe it's out of our scope. > > > > But do you think it is possible to get (with or > > without the restriction) an acceptable result with saving memory and/or > CPU > > time? > > memory usage should be reduced, cpu probably less so, the whole > bitstream still needs to be decoded. > > also if you are in control of the encoder to restrict what it does > it may be simpler to use mpeg4-asp, H.263 or mpeg2 which have lowres > support in FFmpeg without these problems > > No i can't. I'm using stream from IP camera which can work only with MJPEG or H.264 stream. We need to use often H.264 to save network bandwidth. In that case if we are for example 80 stream with a resolution of 3 millions pixels, it can lead to a memory overflow. We would like to reduce the memory usage. CPU is less a problem but if we can win something, it will be also good. Generally we use a secondary stream with lower resolution, but sometimes it's not possible. So we are interested in improvement that can gain any memory usage and working with our environment. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The misfortune of the wise is better than the prosperity of the fool. > -- Epicurus > > ___ > 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] PPC64: Add IBM POWER8 SIMD Implementation
First commit addressing Trac ticket #5570. Functions defined in
libswscale/input.c
have corresponding SIMD definitions in libswscale/ppc/input_vsx.c
---
libswscale/ppc/Makefile |1 +
libswscale/ppc/input_vsx.c| 1070 +
libswscale/swscale.c |3 +
libswscale/swscale_internal.h |1 +
4 files changed, 1075 insertions(+)
create mode 100644 libswscale/ppc/input_vsx.c
diff --git a/libswscale/ppc/Makefile b/libswscale/ppc/Makefile
index d1b596e..2482893 100644
--- a/libswscale/ppc/Makefile
+++ b/libswscale/ppc/Makefile
@@ -1,3 +1,4 @@
OBJS += ppc/swscale_altivec.o \
+ppc/input_vsx.o \
ppc/yuv2rgb_altivec.o \
ppc/yuv2yuv_altivec.o \
diff --git a/libswscale/ppc/input_vsx.c b/libswscale/ppc/input_vsx.c
new file mode 100644
index 000..adb0e38
--- /dev/null
+++ b/libswscale/ppc/input_vsx.c
@@ -0,0 +1,1070 @@
+/*
+ * Copyright (C) 2016 Dan Parrot
+ *
+ * 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
+#include
+#include
+#include
+
+#include "libavutil/avutil.h"
+#include "libavutil/bswap.h"
+#include "libavutil/cpu.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/avassert.h"
+#include "config.h"
+#include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
+
+#define r ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE ||
origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? b_r : r_b)
+#define b ((origin == AV_PIX_FMT_BGR48BE || origin == AV_PIX_FMT_BGR48LE ||
origin == AV_PIX_FMT_BGRA64BE || origin == AV_PIX_FMT_BGRA64LE) ? r_b : b_r)
+
+#if HAVE_VSX
+
+// This is a SIMD version for IBM POWER8 of function rgb64ToY_c_template
+// in file libswscale/input.c
+static av_always_inline void
+rgb64ToY_c_template_vsx(uint16_t *dst, const uint16_t *src, int width,
+enum AVPixelFormat origin, int32_t *rgb2yuv)
+{
+int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = rgb2yuv[BY_IDX];
+int i, j;
+int num_vec, frag;
+
+num_vec = width / 8;
+frag= width % 8;
+
+vector int v_ry = vec_splats((int)ry);
+vector int v_gy = vec_splats((int)gy);
+vector int v_by = vec_splats((int)by);
+
+int s_opr2;
+s_opr2 = (int)(0x2001 << (RGB2YUV_SHIFT-1));
+
+vector int v_opr1 = vec_splats((int)RGB2YUV_SHIFT);
+vector int v_opr2 = vec_splats((int)s_opr2);
+
+vector int v_r, v_g, v_b, v_tmp;
+vector short v_tmpi, v_dst;
+
+for (i = 0; i < num_vec; i++) {
+for (j = 7; j >= 0 ; j--) {
+int r_b = input_pixel(&src[(i*8+j)*4+0]);
+int g = input_pixel(&src[(i*8+j)*4+1]);
+int b_r = input_pixel(&src[(i*8+j)*4+2]);
+
+v_r[j % 4] = r;
+v_g[j % 4] = g;
+v_b[j % 4] = b;
+
+if (!(j % 4)) {
+v_tmp = v_ry * v_r;
+v_tmp = v_tmp + v_gy * v_g;
+v_tmp = v_tmp + v_by * v_b;
+v_tmp = v_tmp + v_opr2;
+v_tmp = vec_sr(v_tmp, (vector unsigned int)v_opr1);
+
+v_tmpi = (vector short)v_tmp;
+v_dst[(j / 4) * 4 + 3] = v_tmpi[6];
+v_dst[(j / 4) * 4 + 2] = v_tmpi[4];
+v_dst[(j / 4) * 4 + 1] = v_tmpi[2];
+v_dst[(j / 4) * 4 + 0] = v_tmpi[0];
+}
+}
+vec_vsx_st(v_dst, 0, (short *)&dst[i*8]);
+}
+
+// computation for any less than vector-length items at tail end
+if( frag ) {
+for (i = 0; i < frag; i++) {
+unsigned int r_b = input_pixel(&src[(num_vec*8+i)*4+0]);
+unsigned int g = input_pixel(&src[(num_vec*8+i)*4+1]);
+unsigned int b_r = input_pixel(&src[(num_vec*8+i)*4+2]);
+
+dst[num_vec*8+i] = (ry*r + gy*g + by*b +
(0x2001<<(RGB2YUV_SHIFT-1))) >> RGB2YUV_SHIFT;
+}
+}
+
+}
+
+// This is a SIMD version for IB
Re: [FFmpeg-devel] [PATCH 2/2] ffplay: ensure that we buffer at least 1 second of content
On Sat, 11 Jun 2016, Marton Balint wrote: In order to do that, we keep track of the total duration of packets in a packet queue. Pushed the series. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add BobWeaver deinterlacing filter
On 6/19/2016 4:52 PM, Thomas Mundt wrote:
> James Almer schrieb am So, 19.6.2016:
>> On 2/7/2016 8:39 PM, Thomas Mundt wrote:
>>> + at item deint
>>> +Specify which frames to deinterlace. Accept one of the following
>>> +values:
>>> +
>>> + at table @option
>>> + at item 0, all
>>> +Deinterlace all frames.
>>> + at item 1, interlaced
>>> +Only deinterlace frames marked as interlaced.
>>> + at end table
>>> +
>>> +The default value is @code{all}.
>>
>> This...
>>
>> [...]
>>
>>> +{ "deint", "specify which frames to deinterlace", OFFSET(deint),
>>> AV_OPT_TYPE_INT, {.i64=BWDIF_DEINT_INTERLACED}, 0, 1, FLAGS, "deint" },
>>
>> ...and this don't match. So either fix the docs line or change the
>> default here.
>> Bump lavfi micro version of you change the default.
>>
>> For the record, every other deinterlace filter seems to default to
>> "all".
>>
>>> +CONST("all","deinterlace all frames",
>>> BWDIF_DEINT_ALL,"deint"),
>>> +CONST("interlaced", "only deinterlace frames marked as interlaced",
>>> BWDIF_DEINT_INTERLACED, "deint"),
>
> Oops, I also placed the documentation at the wrong alphabetical position.
> Patches attached.
> Sorry about that!!
>
> Thomas
Both applied, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix videotoolbox compile error on OS X 10.8.
Fixes error:
libavcodec/videotoolbox.c:511:18: error: implicit declaration of
function 'CMVideoFormatDescriptionCreateFromH264ParameterSets' is
invalid in C99
This was added in 10.9:
https://developer.apple.com/reference/coremedia/1489818-cmvideoformatdescriptioncreatefr?language=objc
---
libavcodec/videotoolbox.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 502b2e3..7b5245a 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -495,6 +495,8 @@ static CMVideoFormatDescriptionRef
videotoolbox_format_desc_create(AVCodecContex
{
CMFormatDescriptionRef cm_fmt_desc = NULL;
int status;
+
+#if TARGET_OS_IPHONE || defined(__MAC_10_9)
H264Context *h = codec_type == kCMVideoCodecType_H264 ?
avctx->priv_data : NULL;
if (h && h->ps.sps->data_size && h->ps.pps->data_size) {
@@ -522,6 +524,7 @@ static CMVideoFormatDescriptionRef
videotoolbox_format_desc_create(AVCodecContex
return NULL;
}
} else {
+#endif
status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
codec_type,
width,
@@ -533,7 +536,9 @@ static CMVideoFormatDescriptionRef
videotoolbox_format_desc_create(AVCodecContex
av_log(avctx, AV_LOG_ERROR, "Error creating format
description: %d\n", status);
return NULL;
}
+#if TARGET_OS_IPHONE || defined(__MAC_10_9)
}
+#endif
return cm_fmt_desc;
}
--
2.4.5
0001-Fix-videotoolbox-compile-error-on-OS-X-10.8.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/mux: do not call write_header multiple times if it fails the first time
On Sun, 12 Jun 2016, Michael Niedermayer wrote:
On Sat, Jun 11, 2016 at 11:54:31PM +0200, Marton Balint wrote:
On Sat, 11 Jun 2016, Michael Niedermayer wrote:
On Sat, Jun 11, 2016 at 08:33:42PM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/internal.h | 1 +
libavformat/mux.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 40ba089..b6c2020 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -124,6 +124,7 @@ struct AVFormatInternal {
* Whether or not a header has already been written
*/
int header_written;
+int write_header_ret;
};
struct AVStreamInternal {
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 08ed940..b1b65a1 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -479,6 +479,7 @@ static int write_header_internal(AVFormatContext *s)
int ret = s->oformat->write_header(s);
if (ret >= 0 && s->pb && s->pb->error < 0)
ret = s->pb->error;
+s->internal->write_header_ret = ret;
would
header_written = ret
be simpler ?
I can change it, but I found it a little less readable.
then better to leave it
Applied the rest of the series.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)
On 6/17/16, Eric Beuque wrote: > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer : > >> On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote: >> > Hi, >> > >> > i'm posting here for a feature that is missing in ffmpeg (or may be i >> > missed something), which consist of decoding H.264 frame with a scaling >> > factor of 1/2, 1/4, 1/8... >> > >> > I found the parameter lowres, which works well with MJPEG stream but >> > it's >> > not working with the H.264 decoder. >> > >> > I don't know if it's something possible to implement in the decoder, but >> if >> > yes, my compagny agreed to sponsor the feature (depending on the cost of >> > course), if a developer qualified is interested to do it. >> > >> > Is someone know if it is possible, and if it can exist someone >> > interested >> > to develop this feature? >> >> is it acceptable if the encoder enforces some restrictions on the used >> features ? >> >> most general h264 likely cannot efficiently be decoded in lower >> resolution with acceptable quality >> Restricting the used intra modes may make it possible to do it though >> i dont know what the quality would be but better than without >> restrictions >> >> [...] >> > > > Actually, the main goal is for motion detection algorithm, so we need small > resolution and best quality is not required. We just need good estimation > for the moving pixel. > > For now, we decode in H.264, and scale it close 320x240, the then we > perform motion detection on it. The goal is to speed up the process and > reduce the memory usage since decoding a 2048x1536 picture lead around a 5 > MB for the decoded image in memory. Have you tried to extract the motion vectors of the H.264 stream itself? If the encoder supports more than I-frames, it should do some Motion Estimation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix videotoolbox compile error on OS X 10.8.
> On Jun 19, 2016, at 6:11 PM, Dan Dennedy wrote:
>
> Fixes error:
> libavcodec/videotoolbox.c:511:18: error: implicit declaration of
> function 'CMVideoFormatDescriptionCreateFromH264ParameterSets' is
> invalid in C99
>
> This was added in 10.9:
> https://developer.apple.com/reference/coremedia/1489818-cmvideoformatdescriptioncreatefr?language=objc
Thanks for catching this - applied.
If you have access to OS X 10.8, can you test using this hwaccel?
> ---
> libavcodec/videotoolbox.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 502b2e3..7b5245a 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -495,6 +495,8 @@ static CMVideoFormatDescriptionRef
> videotoolbox_format_desc_create(AVCodecContex
> {
> CMFormatDescriptionRef cm_fmt_desc = NULL;
> int status;
> +
> +#if TARGET_OS_IPHONE || defined(__MAC_10_9)
> H264Context *h = codec_type == kCMVideoCodecType_H264 ?
> avctx->priv_data : NULL;
>
> if (h && h->ps.sps->data_size && h->ps.pps->data_size) {
> @@ -522,6 +524,7 @@ static CMVideoFormatDescriptionRef
> videotoolbox_format_desc_create(AVCodecContex
> return NULL;
> }
> } else {
> +#endif
> status = CMVideoFormatDescriptionCreate(kCFAllocatorDefault,
> codec_type,
> width,
> @@ -533,7 +536,9 @@ static CMVideoFormatDescriptionRef
> videotoolbox_format_desc_create(AVCodecContex
> av_log(avctx, AV_LOG_ERROR, "Error creating format
> description: %d\n", status);
> return NULL;
> }
> +#if TARGET_OS_IPHONE || defined(__MAC_10_9)
> }
> +#endif
>
> return cm_fmt_desc;
> }
> --
> 2.4.5
> <0001-Fix-videotoolbox-compile-error-on-OS-X-10.8.patch>___
> 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
