Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Michael Niedermayer]

On Mon, May 23, 2016 at 05:09:35PM +, Davinder Singh wrote:
>  vf_codecview.c |   55 +--
>  1 file changed, 45 insertions(+), 10 deletions(-)
> 464b23c4638d1a408e8237651facf327994945bf  
> 0001-vf_codecview-added-new-options.patch
> From 641d6f92e792ea7def3610f5462b6bbec019c4b7 Mon Sep 17 00:00:00 2001
> From: dsmudhar 
> Date: Mon, 23 May 2016 22:29:51 +0530
> Subject: [PATCH] vf_codecview: added new options
> 
> ---
>  libavfilter/vf_codecview.c | 55 
> +-
>  1 file changed, 45 insertions(+), 10 deletions(-)
> 
> diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
> index e70b397..1cb521d 100644
> --- a/libavfilter/vf_codecview.c
> +++ b/libavfilter/vf_codecview.c
> @@ -38,21 +38,39 @@
>  #define MV_P_FOR  (1<<0)
>  #define MV_B_FOR  (1<<1)
>  #define MV_B_BACK (1<<2)
> +#define MV_TYPE_FOR  (1<<0)
> +#define MV_TYPE_BACK (1<<1)
> +#define FRAME_TYPE_I (1<<0)
> +#define FRAME_TYPE_P (1<<1)
> +#define FRAME_TYPE_B (1<<2)
>  
>  typedef struct {
>  const AVClass *class;
>  unsigned mv;
> +unsigned frame_type;
> +unsigned mv_type;
>  int hsub, vsub;
>  int qp;
>  } CodecViewContext;
>  
>  #define OFFSET(x) offsetof(CodecViewContext, x)
>  #define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> +#define CONST(name, help, val, unit) { name, help, 0, AV_OPT_TYPE_CONST, 
> {.i64=val}, 0, 0, FLAGS, unit }
> +
>  static const AVOption codecview_options[] = {
>  { "mv", "set motion vectors to visualize", OFFSET(mv), 
> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv" },
> -{"pf", "forward predicted MVs of P-frames",  0, AV_OPT_TYPE_CONST, 
> {.i64 = MV_P_FOR },  INT_MIN, INT_MAX, FLAGS, "mv"},
> -{"bf", "forward predicted MVs of B-frames",  0, AV_OPT_TYPE_CONST, 
> {.i64 = MV_B_FOR },  INT_MIN, INT_MAX, FLAGS, "mv"},
> -{"bb", "backward predicted MVs of B-frames", 0, AV_OPT_TYPE_CONST, 
> {.i64 = MV_B_BACK }, INT_MIN, INT_MAX, FLAGS, "mv"},
> +CONST("pf", "forward predicted MVs of P-frames",  MV_P_FOR,  "mv"),
> +CONST("bf", "forward predicted MVs of B-frames",  MV_B_FOR,  "mv"),
> +CONST("bb", "backward predicted MVs of B-frames", MV_B_BACK, "mv"),
> +{ "mv_type", "set motion vectors type", OFFSET(mv_type), 
> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
> +{ "mvt", "set motion vectors type", OFFSET(mv_type), 
> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
> +CONST("fp", "forward predicted MVs",  MV_TYPE_FOR,  "mv_type"),
> +CONST("bp", "backward predicted MVs", MV_TYPE_BACK, "mv_type"),
> +{ "frame_type", "set frame types to visualize motion vectors of", 
> OFFSET(frame_type), AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, 
> "frame_type" },
> +{ "ft", "set frame types to visualize motion vectors of", 
> OFFSET(frame_type), AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, 
> "frame_type" },
> +CONST("if", "I-frames", FRAME_TYPE_I, "frame_type"),
> +CONST("pf", "P-frames", FRAME_TYPE_P, "frame_type"),
> +CONST("bf", "B-frames", FRAME_TYPE_B, "frame_type"),
>  { "qp", NULL, OFFSET(qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags = 
> FLAGS },

the new options should be added at the end, inserting them in the middle
breaks for example
-flags2 +export_mvs -vf codecview=0:1

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] IRC meeting

[Michael Niedermayer]

On Mon, May 30, 2016 at 02:11:12AM +0200, Michael Niedermayer wrote:
> On Sun, May 29, 2016 at 09:11:38PM +0200, Marton Balint wrote:
> > 
> > 
> > On Sat, 28 May 2016, Stefano Sabatini wrote:
> > 
> > >On date Saturday 2016-05-28 18:57:00 +0200, Paul B Mahol encoded:
> > >>On 5/28/16, Clement Boesch  wrote:
> > >>> On Wed, May 18, 2016 at 10:33:23PM +0200, Paul B Mahol wrote:
> >  Hi,
> > 
> >  I want to propose to have an FFmpeg IRC meeting on
> >  the Saturday of the next week, Saturday May 28,
> >  UTC 17.
> > 
> > >>>
> > >>> So I suppose this happens in about half an hour. Can you remind us the
> > >>> IRC channel?
> > >>
> > >
> > >>It could be #ffmpeg-devel or any other channel.
> > >
> > >The FFmpeg IRC meeting will start soon (17:15 UTC) on the
> > >#ffmpeg-meeting2016 channel.
> > 
> > Will somebody submit the log to the trac wiki?
> 
> https://trac.ffmpeg.org/wiki/FFmeeting/2016-05

also posting it here as saste asked in the meeting for it to be posted
to teh ML 

 BEGIN LOGGING AT Sat May 28 18:51:04 2016

May 28 18:51:04 *   Now talking on #ffmpeg-meeting2016
May 28 18:51:21 *   durandal_1707 (~duran...@m83-184-22-75.cust.tele2.hr) 
has joined #ffmpeg-meeting2016
May 28 18:51:34 *   jamrial (~jamrial@181.22.62.26) has joined 
#ffmpeg-meeting2016
May 28 18:51:49 *   durandal_170 gives channel operator status to 
durandal_1707
May 28 18:52:22 *   BBB (~rbultje@65.206.95.146) has joined 
#ffmpeg-meeting2016
May 28 18:52:48 *   mateo` (~ma...@static-5-51-29-67.ftth.abo.bbox.fr) has 
joined #ffmpeg-meeting2016
May 28 18:53:35 *   cehoyos (~ceho...@80-110-89-243.cgn.dynamic.surfer.at) 
has joined #ffmpeg-meeting2016
May 28 18:53:36 *   ubitux (~ubi...@bre75-1-78-192-242-8.fbxo.proxad.net) 
has joined #ffmpeg-meeting2016
May 28 18:54:55 *   c_14 (~c_14@unaffiliated/c-14/x-8913907) has joined 
#ffmpeg-meeting2016
May 28 18:55:10 *   saste (~saste___@151.56.85.76) has joined 
#ffmpeg-meeting2016
May 28 18:57:41 *   kurosu_ (020d4d7f@gateway/web/freenode/ip.2.13.77.127) 
has joined #ffmpeg-meeting2016
May 28 18:58:06 *   iive (~iive@unaffiliated/iive) has joined 
#ffmpeg-meeting2016
May 28 18:59:53 *   nevcairiel (nev@WoWUIDev/WoWAce/Ace3/nevcairiel) has 
joined #ffmpeg-meeting2016
May 28 19:00:24   we will start at at 17:15 UTC
May 28 19:03:11 *   Timothy_Gu (~timothy_g@wikipedia/timothy-gu) has joined 
#ffmpeg-meeting2016
May 28 19:03:45 *   kurosu (020d4d7f@gateway/web/freenode/ip.2.13.77.127) 
has joined #ffmpeg-meeting2016
May 28 19:03:48 *   j-b (~jb@videolan/developer/j-b) has joined 
#ffmpeg-meeting2016
May 28 19:04:09 *   kurosu_ has quit ()
May 28 19:04:43   so lets start
May 28 19:04:46   first topic: Code of Conduct and policy around 
it
May 28 19:04:52yes
May 28 19:05:29the "first version" was voted and commited, so 
that's done
May 28 19:06:01   michaelni commited first version, should it be 
extended and other stuff added to it?
May 28 19:06:09 I still maintain that some solid repercussions 
should be specified in the CoC. The ML root idea is good, but it should be 
written as a reference for future.
May 28 19:06:27the VLC one is useful for reference
May 28 19:06:56 We don't have to go as solid as "this --> 1 day 
ban; that --> 2-day ban" but it should be clear what could happen
May 28 19:06:56atomnuker was against adding that, afaik
May 28 19:07:19i also think it should be added
May 28 19:07:32BBB where's vlc's?
May 28 19:07:54https://wiki.videolan.org/Code_of_Conduct/
May 28 19:09:30 This clause doesn't go against the assumption 
of good faith, as atomnuker seems to suggest. It's more for the clarity of the 
entire community, to show that our community is a mature one governed by a set 
of clear rules.
May 28 19:09:51 I'm also for adding some - in spite of the 
issues that were raised
May 28 19:10:29   like one VLC have or more rigid?
May 28 19:11:27  I dislike the notion that very well defined 
rules and (especially ZERO TOLERANCE POLICIES) are needed to maintain order or 
say a community is "mature"
May 28 19:11:41 *   DSM_ (~textual@150.129.198.154) has joined 
#ffmpeg-meeting2016
May 28 19:12:10 we would all be happy if its never invoked, but 
alas we're here because precedence exists that we need it
May 28 19:12:15  I think that defining some rules is okay, as 
long as they're not set in stone and are debateable
May 28 19:12:25   nevcairiel: and what is that precedence?
May 28 19:12:29atomnuker: “NB: Before applying any of those following 
disciplinary policies, the VideoLAN team will try to discuss the problem with 
the offender in order to solve it in a more peaceful way.”
May 28 19:12:39atomnuker: from the VLC CoC “disciplinary actions"
May 28 19:12:49  yeah, that's okay
May 28 19:12:50 VLC's, in my interpretation, is for issues 
caused by situations going out of control, so it looks f

Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: propagate shift_data errors properly

[Michael Niedermayer]

On Sun, May 29, 2016 at 05:17:13PM +0200, Marton Balint wrote:
> The second one is not explicitly needed, as res is not reset, but it is there
> for consistency.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/movenc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

LGTM if the error path was tested

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/movenc: remove useless if and reindent

[Michael Niedermayer]

On Sun, May 29, 2016 at 05:17:14PM +0200, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavformat/movenc.c | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)

LGTM

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 0/2] cleanup unused symver macro and configure check

[Natanael Copa]

This is a re-send of:
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194443.html

I mistakenly only sent one of the two patches, which caused compiler
warnings.
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194455.html

Those two patches removes unused symver macro and configure check.

Natanael Copa (2):
  libavutil: cleanup unused FF_SYMVER macro
  configure: cleanup unused checks for symver

 configure| 21 -
 libavutil/internal.h | 28 
 2 files changed, 49 deletions(-)

-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 1/2] libavutil: cleanup unused FF_SYMVER macro

[Natanael Copa]

There is nothing using it since commit d63443b9 (lavc: drop the
av_fast_{re,m}alloc compatibility wrappers).

Signed-off-by: Natanael Copa 
---
 libavutil/internal.h | 28 
 1 file changed, 28 deletions(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 61784b5..69d63d5 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -177,34 +177,6 @@
 #endif
 
 /**
- * Define a function with only the non-default version specified.
- *
- * On systems with ELF shared libraries, all symbols exported from
- * FFmpeg libraries are tagged with the name and major version of the
- * library to which they belong.  If a function is moved from one
- * library to another, a wrapper must be retained in the original
- * location to preserve binary compatibility.
- *
- * Functions defined with this macro will never be used to resolve
- * symbols by the build-time linker.
- *
- * @param type return type of function
- * @param name name of function
- * @param args argument list of function
- * @param ver  version tag to assign function
- */
-#if HAVE_SYMVER_ASM_LABEL
-#   define FF_SYMVER(type, name, args, ver) \
-type ff_##name args __asm__ (EXTERN_PREFIX #name "@" ver);  \
-type ff_##name args
-#elif HAVE_SYMVER_GNU_ASM
-#   define FF_SYMVER(type, name, args, ver) \
-__asm__ (".symver ff_" #name "," EXTERN_PREFIX #name "@" ver);  \
-type ff_##name args;\
-type ff_##name args
-#endif
-
-/**
  * Return NULL if a threading library has not been enabled.
  * Used to disable threading functions in AVCodec definitions
  * when not needed.
-- 
2.8.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: Add Pro-MPEG CoP #3-R2 FEC protocol

[Vlad Tarca]

Hello,

> I think size needs to be checked to avoid integer overflow
> there is a check later but unless iam mising somthng thats too late

They were checked indirectly by av_malloc_array() and used only iff the init 
succeeded.
I added checks to avoid setting garbage in the context.

> this looks duplicated, can this be factored with the similar previous code ?

> sizeof(buf) or something, hardcoded 256 is bad, that can be missed
> if someone changes the array size

Some artefacts from rtpproto.c, someone might need to take a look at it at some 
point.
Fixed and used just prompeg_close() for cleanup.

Thanks


Signed-off-by: Vlad Tarca 
---
 Changelog   |   1 +
 doc/general.texi|   1 +
 doc/protocols.texi  |  35 
 libavformat/Makefile|   1 +
 libavformat/prompeg.c   | 491 
 libavformat/protocols.c |   1 +
 libavformat/rtpproto.c  |  64 ++-
 7 files changed, 591 insertions(+), 3 deletions(-)
 create mode 100644 libavformat/prompeg.c

diff --git a/Changelog b/Changelog
index 697b430..34bc23a 100644
--- a/Changelog
+++ b/Changelog
@@ -37,6 +37,7 @@ version :
 - Direct Stream Transfer (DST) decoder
 - loudnorm filter
 - MTAF demuxer and decoder
+- Pro-MPEG CoP #3-R2 FEC protocol
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/doc/general.texi b/doc/general.texi
index 2d3dd0b..80a434a 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1126,6 +1126,7 @@ performance on systems without hardware floating point 
support).
 @item MMSH @tab X
 @item MMST @tab X
 @item pipe @tab X
+@item Pro-MPEG FEC @tab X
 @item RTMP @tab X
 @item RTMPE@tab X
 @item RTMPS@tab X
diff --git a/doc/protocols.texi b/doc/protocols.texi
index a9c9d0c..875fdac 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -513,6 +513,41 @@ time, which is valuable if data transmission is slow.
 Note that some formats (typically MOV), require the output protocol to
 be seekable, so they will fail with the pipe output protocol.
 
+@section prompeg
+
+Pro-MPEG Code of Practice #3 Release 2 FEC protocol.
+
+The Pro-MPEG CoP#3 FEC is a 2D parity-check forward error correction mechanism
+for MPEG-2 Transport Streams sent over RTP.
+
+This protocol must be used in conjunction with the @code{rtp_mpegts} muxer and
+the @code{rtp} protocol.
+
+The required syntax is:
+@example
+-f rtp_mpegts -fec prompeg=@var{option}=@var{val}... 
rtp://@var{hostname}:@var{port}
+@end example
+
+The destination UDP ports are @code{port + 2} for the column FEC stream
+and @code{port + 4} for the row FEC stream.
+
+This protocol accepts the following options:
+@table @option
+
+@item l=@var{n}
+The number of columns (4-20, LxD <= 100)
+
+@item d=@var{n}
+The number of rows (4-20, LxD <= 100)
+
+@end table
+
+Example usage:
+
+@example
+-f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
+@end example
+
 @section rtmp
 
 Real-Time Messaging Protocol.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..90d7587 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -547,6 +547,7 @@ OBJS-$(CONFIG_MD5_PROTOCOL)  += md5proto.o
 OBJS-$(CONFIG_MMSH_PROTOCOL) += mmsh.o mms.o asf.o
 OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o asf.o
 OBJS-$(CONFIG_PIPE_PROTOCOL) += file.o
+OBJS-$(CONFIG_PROMPEG_PROTOCOL)  += prompeg.o
 OBJS-$(CONFIG_RTMP_PROTOCOL) += rtmpproto.o rtmppkt.o
 OBJS-$(CONFIG_RTMPE_PROTOCOL)+= rtmpproto.o rtmppkt.o
 OBJS-$(CONFIG_RTMPS_PROTOCOL)+= rtmpproto.o rtmppkt.o
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
new file mode 100644
index 000..3e365c6
--- /dev/null
+++ b/libavformat/prompeg.c
@@ -0,0 +1,491 @@
+/*
+ * Pro-MPEG Code of Practice #3 Release 2 FEC
+ * Copyright (c) 2016 Mobibase, France (http://www.mobibase.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 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
+ * Pro-MPEG Code of Practice #3 Release 2 FEC protocol
+ * @author Vlad Tarca 
+ */
+
+/*
+ * Reminder:
+
+ [RFC 2733] FEC Packet Structure
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  

[FFmpeg-devel] [PATCH v2 2/2] configure: cleanup unused checks for symver

[Natanael Copa]

Nothing uses symvers since commit d63443b9 (lavc: drop the
av_fast_{re,m}alloc compatibility wrappers).

Signed-off-by: Natanael Copa 
---
 configure | 21 -
 1 file changed, 21 deletions(-)

diff --git a/configure b/configure
index cc2c9e7..e40b90e 100755
--- a/configure
+++ b/configure
@@ -358,7 +358,6 @@ Toolchain options:
 Advanced options (experts only):
   --malloc-prefix=PREFIX   prefix malloc and related names with PREFIX
   --custom-allocator=NAME  use a supported custom allocator
-  --disable-symver disable symbol versioning
   --enable-hardcoded-tables use hardcoded tables instead of runtime generation
   --disable-safe-bitstream-reader
disable buffer boundary checking in bitreaders
@@ -1782,7 +1781,6 @@ BUILTIN_LIST="
 "
 HAVE_LIST_CMDLINE="
 inline_asm
-symver
 yasm
 "
 
@@ -1956,8 +1954,6 @@ TOOLCHAIN_FEATURES="
 inline_asm_nonlocal_labels
 pragma_deprecated
 rsync_contimeout
-symver_asm_label
-symver_gnu_asm
 vfp_args
 xform_asm
 xmm_clobbers
@@ -2260,7 +2256,6 @@ fast_unaligned_if_any="aarch64 ppc x86"
 simd_align_16_if_any="altivec neon sse"
 
 # system capabilities
-symver_if_any="symver_asm_label symver_gnu_asm"
 valgrind_backtrace_deps="!optimizations valgrind_valgrind_h"
 
 # threading support
@@ -4574,7 +4569,6 @@ case $target_os in
 enabled shared && add_ldflags -Wl,-brtl
 ;;
 android)
-disable symver
 enable section_data_rel_ro
 SLIB_INSTALL_NAME='$(SLIBNAME)'
 SLIB_INSTALL_LINKS=
@@ -4602,13 +4596,11 @@ case $target_os in
 SLIB_CREATE_DEF_CMD='$(Q)perl 
$(SRC_PATH)/compat/solaris/make_sunver.pl $$(filter %.ver,$$^) $(OBJS) | grep 
-v @ > $(SUBDIR)lib$(NAME).ver-sol2'
 ;;
 netbsd)
-disable symver
 oss_indev_extralibs="-lossaudio"
 oss_outdev_extralibs="-lossaudio"
 enabled gcc || check_ldflags -Wl,-zmuldefs
 ;;
 openbsd|bitrig)
-disable symver
 SHFLAGS='-shared'
 SLIB_INSTALL_NAME='$(SLIBNAME).$(LIBMAJOR).$(LIBMINOR)'
 SLIB_INSTALL_LINKS=
@@ -4616,7 +4608,6 @@ case $target_os in
 oss_outdev_extralibs="-lossaudio"
 ;;
 dragonfly)
-disable symver
 ;;
 freebsd)
 ;;
@@ -4699,7 +4690,6 @@ case $target_os in
 fi
 ;;
 win32|win64)
-disable symver
 if enabled shared; then
 # Link to the import library instead of the normal static library
 # for shared libs.
@@ -6011,15 +6001,6 @@ elif test_ldflags -Wl,-M,$TMPV; then
 append SHFLAGS '-Wl,-M,\$(SUBDIR)lib\$(NAME).ver-sol2'
 fi
 
-check_cc 

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Thilo Borgmann]

Am 30.05.16 um 03:39 schrieb Ronald S. Bultje:
> Hi Thilo,
> 
> On Sun, May 29, 2016 at 8:59 PM, Thilo Borgmann 
> wrote:
> 
>> Hi,
>>
>>> [...]

 The vote will end 1 week from now, simple 50% majority (Yes vs no)
 I dont really know who should be eligible for voting, so i suggest
 everyone from the vote comittee but iam happy with anything, just
 stating somethng ...

>>>
>>> I am in favor of adding AVClass.
>>
>>
>> You're not in the list [1]?
>>
>> Ronald
>>
>> [1]
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html
>
> At least one the person in the list has apparently left the project, so
 maybe
> we could suggest adding recurrent contributors like Marton and Thilo.

 Probably, yes. Is it just Thilo or are others missing also? What were
>> the
 criteria again?

 Ronald
>>>
>>> The original criteria was i think 50 commits in the past year or so. This
>>> was back in mid 2015. After that a couple people were added based on
>>> suggestions since many long time contributors and maintainers didn't meet
>>> that criteria.
>>
>> Thanks for pointing out, Ronald. Sorry, I've just missed the committee
>> part...
>>
>> I'd like not to be added to the committee while a vote is ongoing.
>> Please consider my vote to be void.
> 
> 
> (If you want,) I still think you could be added for e.g. future votes?

Yes probably, assuming people want me to be in it I'd be glad.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] 答复: 答复: [PATCH]Filter: Add snapshot filter. It is enable to save snapshot.

[Tobias Rapp]

On 28.05.2016 07:31, kl222 wrote:
> On 27.05.2016 13:49, Nicolas George wrote: 
>> Can you explain your use case for this filter?
>>
>> I ask because I am very uncomfortable with filters that perform direct output
>> instead of producing frames for the rest of the graph. They need to duplicate
>> the encoding and muxing code, usually with fewer options and features, and
>> that duplicated code becomes itself a maintenance burden in case of API
>> changes and such.
>>
>> IMHO, a better solution would be some kind of "interactive select" (or just 
>> an
>> option of plain select) filter, and encode its output as image2.
>>
> 
> I want to implement to the snapshot function whenever push stream, 
> and set the file name of snapshot picture. 
> this function can snapshot pictures before, between or after the other 
> filters.
> Because I want to change the file in filter, so duplicate the encoding and 
> muxing code
> can not be avoided. 
> OK, add it to "select" filter and a single filter patch. Chosen by you. see 
> annex.

The way you added it to the select filter it still uses own muxing code and 
doesn't 
allow to take full advantage of output format options.

To give an idea what I had in mind when suggesting the select filter: The 
following 
command uses current FFmpeg code to generate snapshot files of the first two 
video 
frames:

ffmpeg -i input-file.avi -f image2 -q 5 -filter:v "select=lt(selected_n\,2)" -y 
snapshot-%03d.jpg

Now if the select filter code would be improved to allow updating the evaluated 
expression at run-time, sending filter commands like

expr lt(selected_n,2)  // save two snapshot files
expr lt(selected_n,3)  // add another snapshot file
expr lt(selected_n,4)  // add another snapshot file

could be used to trigger saving snapshot files on demand.

Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Add a G.729 muxer

[Carl Eugen Hoyos]

Michael Niedermayer  niedermayer.cc> writes:

> can you list which regressions you spoke about

https://trac.ffmpeg.org/query?keywords=~codecpar

I was hoping that somebody understands and explains #5348 
before closing it.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Rostislav Pehlivanov]

On 30 May 2016 at 10:34, Thilo Borgmann  wrote:

> Am 30.05.16 um 03:39 schrieb Ronald S. Bultje:
> > Hi Thilo,
> >
> > On Sun, May 29, 2016 at 8:59 PM, Thilo Borgmann 
> > wrote:
> >
> >> Hi,
> >>
> >>> [...]
> 
>  The vote will end 1 week from now, simple 50% majority (Yes vs no)
>  I dont really know who should be eligible for voting, so i suggest
>  everyone from the vote comittee but iam happy with anything, just
>  stating somethng ...
> 
> >>>
> >>> I am in favor of adding AVClass.
> >>
> >>
> >> You're not in the list [1]?
> >>
> >> Ronald
> >>
> >> [1]
> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html
> >
> > At least one the person in the list has apparently left the project,
> so
>  maybe
> > we could suggest adding recurrent contributors like Marton and Thilo.
> 
>  Probably, yes. Is it just Thilo or are others missing also? What were
> >> the
>  criteria again?
> 
>  Ronald
> >>>
> >>> The original criteria was i think 50 commits in the past year or so.
> This
> >>> was back in mid 2015. After that a couple people were added based on
> >>> suggestions since many long time contributors and maintainers didn't
> meet
> >>> that criteria.
> >>
> >> Thanks for pointing out, Ronald. Sorry, I've just missed the committee
> >> part...
> >>
> >> I'd like not to be added to the committee while a vote is ongoing.
> >> Please consider my vote to be void.
> >
> >
> > (If you want,) I still think you could be added for e.g. future votes?
>
> Yes probably, assuming people want me to be in it I'd be glad.
>
> -Thilo
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

For the past one year and nine months you've had 4 commits:

 git log --no-merges --since=2015-05-30T00:00:00Z --pretty=fuller | grep
'^Commit:' | sed 's/<.*//' |sort | uniq -c | sort -nr | grep
--line-buffered "Thilo Borgmann"
  4 Commit: Thilo Borgmann

We agreed the committee should contain only active contributors. The
members that were added later were added because they were slightly below
the threshold but had done much during the last few months.

In short, no.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Carl Eugen Hoyos]

Rostislav Pehlivanov  gmail.com> writes:

> We agreed the committee should contain only active contributors. 
> The members that were added later were added because they were 
> slightly below the threshold but had done much during the last 
> few months.
> 
> In short, no.

Thilo has presented FFmpeg on different technology fairs over 
the last years, I never had the impression that other 
contributors would like to go instead of him. He is a GSoC 
mentor this year (and did offer to mentor last year). He has 
lately fixed a regression (that was mentioned today) showing 
that he actively maintains FFmpeg code.

He definitely is an active contributor.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Rostislav Pehlivanov]

On 30 May 2016 at 12:20, Carl Eugen Hoyos  wrote:

> Rostislav Pehlivanov  gmail.com> writes:
>
> > We agreed the committee should contain only active contributors.
> > The members that were added later were added because they were
> > slightly below the threshold but had done much during the last
> > few months.
> >
> > In short, no.
>
> Thilo has presented FFmpeg on different technology fairs over
> the last years, I never had the impression that other
> contributors would like to go instead of him. He is a GSoC
> mentor this year (and did offer to mentor last year). He has
> lately fixed a regression (that was mentioned today) showing
> that he actively maintains FFmpeg code.
>
> He definitely is an active contributor.
>
> Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Anyone can go to fairs, mentor for GSoC, write on the MLs, etc. Not
everyone has the time.
The committe was made to govern this project in case questions (mainly
technical) need to be resolved. And answering technical questions requires
knowledge of the codebase. The codebase changes over time. New features
like codecpar were added a bit more than a month ago. So someone who
continuously improves the codebase would also follow what happens in the
project and be qualified to make an answer. Hence why commits over time
were chosen
as the metric. Someone who makes commits and occasional bugfixes to a part
of the codebase that doesn't get touched as much wouldn't know so much
about the problem at hand.

The committee was also made to be dynamically updated every year by
removing inactive contributors and adding new contributors. Since the
committee was made on September the 5th last year, this means that on
September the 5th this year active or returning contributors would be added
and people who haven't done much would be removed. So while voting could
get someone in, staying would still require them to continuously improve
the codebase. Adding someone right now without them doing much would be
enough to make them stay until September on the committee.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Carl Eugen Hoyos]

Rostislav Pehlivanov  gmail.com> writes:

> Anyone can go to fairs, mentor for GSoC, write on the MLs, etc. 
> Not everyone has the time.

This is true, I completely agree.
I am not sure if I understand the relevance though: The list of 
people on the voters committee contains both people who have 
(a certain amount of) patches in FFmpeg but also people with 
no (or only a very small number of) commits.
So I don't think this is related.

> The committe was made to govern this project in case questions 
> (mainly technical) need to be resolved.

Yes, probably.

> And answering technical questions requires knowledge of the 
> codebase.

Of course, this is why Thilo should be part of the committee.

> The codebase changes over time. New features like codecpar were 
> added a bit more than a month ago. So someone who continuously 
> improves the codebase would also follow what happens in the
> project and be qualified to make an answer.

Yes.
Note that I did mention Thilo fixed one of the codecpar regressions 
making him qualified under your conditions.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Christophe Gisquet]

Hi,

2016-05-29 21:51 GMT+02:00 Paul B Mahol :
> +typedef struct Slice {
> +uint32_t start;
> +uint32_t size;
> +} Slice;

I'm not a security expert, but is there a reason for not using plain int there ?

> +typedef struct MagicYUVContext {
> +AVFrame*p;
> +int slice_height;
> +int nb_slices;
> +int planes;
> +uint8_t *buf;
> +int hshift[4];
> +int vshift[4];
> +Slice   *slices[4];
> +int slices_size[4];
> +uint8_t freq[4][256];
> +VLC vlc[4];
> +HuffYUVDSPContext   hdsp;
> +} MagicYUVContext;

I guess someone able to understand the code immediately understand
what those are, but that's pretty sparse comment-wise.

> +typedef struct HuffEntry {

And another Huffman+prediction codec... I don't really see any
valuable addition here... :(

> +uint8_t  sym;
> +uint8_t  len;
> +uint32_t code;
> +} HuffEntry;
> +
> +static int ff_magy_huff_cmp_len(const void *a, const void *b)
> +{
> +const HuffEntry *aa = a, *bb = b;
> +return (aa->len - bb->len) * 256 + aa->sym - bb->sym;
> +}
> +
> +static int build_huff(VLC *vlc, uint8_t *freq)
> +{
> +HuffEntry he[256];
> +uint32_t codes[256];
> +uint8_t bits[256];
> +uint8_t syms[256];
> +uint32_t code;
> +int i, last;
> +
> +for (i = 0; i < 256; i++) {
> +he[i].sym = 255 - i;
> +he[i].len = freq[i];
> +}
> +qsort(he, 256, sizeof(*he), ff_magy_huff_cmp_len);

ffmpeg seems to have libavutil/qsort.h, but I don't even know how much
effort is needed to use it here.

> +pred = get_bits(&b, 8);
> +dst = p->data[i] + j * sheight * stride;
> +for (k = 0; k < height; k++) {
> +for (x = 0; x < width; x++) {
> +int pix;
> +if (get_bits_left(&b) <= 0) {
> +return AVERROR_INVALIDDATA;
> +}
> +pix = get_vlc2(&b, s->vlc[i].table, s->vlc[i].bits, 3);
> +if (pix < 0) {
> +return AVERROR_INVALIDDATA;
> +}
> +dst[x] = 255 - pix;
> +}
> +dst += stride;
> +}
> +
> +if (pred == LEFT) {
> +dst = p->data[i] + j * sheight * stride;
> +s->hdsp.add_hfyu_left_pred(dst, dst, width, 0);
> +dst += stride;
> +for (k = 1; k < height; k++) {
> +s->hdsp.add_hfyu_left_pred(dst, dst, width, dst[-stride]);
> +dst += stride;
> +}
> +} else if (pred == GRADIENT) {
[...]

That's somewhat similar to png paeth, except not actually reusable. I
wonder if there's something in libavcodec that could be reused, in
which case moving it to the hdsp context would be nice)

> +} else if (pred == MEDIAN) {
[...]
> +} else {

So, that's maybe a detail at this point, and you want to move quickly
to other stuff, but:
would you like to look at e.g. huffyuvdec or pngdec for a code that is
not as nice looking, but more cache-friendly?

Basically, you move the first line out of the loops, and then do
sequentially, per row in the loop, bitstream reading, reconstruction
(residual+prediction) and any post-processing...

> +if (decorrelate) {
> +uint8_t *b = p->data[0];
> +uint8_t *g = p->data[1];
> +uint8_t *r = p->data[2];
> +
> +for (i = 0; i < p->height; i++) {
> +for (x = 0; x < p->width; x++) {
> +b[x] += g[x];
> +r[x] += g[x];
> +}
> +b += p->linesize[0];
> +g += p->linesize[1];
> +r += p->linesize[2];
> +}
> +}

... in particular, this step, that could be done line-wise, inside the
threaded decoding, if I'm not mistaken. (cf. also png's deloco)

Otherwise, I don't see much of anything that would require another
reviewing round.
-- 
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat: Copy properties from internal context

[Michael Niedermayer]

Fixes Ticket5467 "Lossless j2k information no longer shown"

Based on suggestion by Hendrik Leppkes
Signed-off-by: Michael Niedermayer 
---
 libavformat/dump.c  |3 +++
 libavformat/utils.c |3 +++
 2 files changed, 6 insertions(+)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index 9eb6146..e016a37 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -453,6 +453,9 @@ static void dump_stream_format(AVFormatContext *ic, int i,
 return;
 }
 
+// Fields which are missing from AVCodecParameters need to be taken from 
the AVCodecContext
+avctx->properties = st->codec->properties;
+
 if (separator)
 av_opt_set(avctx, "dump_separator", separator, 0);
 avcodec_string(buf, sizeof(buf), avctx, is_output);
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 47f5ba0..8f0361a 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3807,6 +3807,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
 }
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
+// Fields unavailable in AVCodecParameters
+st->codec->properties = st->internal->avctx->properties;
+
 
 st->internal->avctx_inited = 0;
 }
-- 
1.7.9.5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: Copy properties from internal context

[Hendrik Leppkes]

On Mon, May 30, 2016 at 2:25 PM, Michael Niedermayer
 wrote:
> Fixes Ticket5467 "Lossless j2k information no longer shown"
>
> Based on suggestion by Hendrik Leppkes
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/dump.c  |3 +++
>  libavformat/utils.c |3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 9eb6146..e016a37 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -453,6 +453,9 @@ static void dump_stream_format(AVFormatContext *ic, int i,
>  return;
>  }
>
> +// Fields which are missing from AVCodecParameters need to be taken from 
> the AVCodecContext
> +avctx->properties = st->codec->properties;
> +
>  if (separator)
>  av_opt_set(avctx, "dump_separator", separator, 0);
>  avcodec_string(buf, sizeof(buf), avctx, is_output);
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 47f5ba0..8f0361a 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3807,6 +3807,9 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  }
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
> +// Fields unavailable in AVCodecParameters
> +st->codec->properties = st->internal->avctx->properties;
> +

st->codec is deprecated, so it should be in deprecation guards so the
code doesn't break when the version is bumped.

>
>  st->internal->avctx_inited = 0;
>  }
> --
> 1.7.9.5
>
> ___
> 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] avcodec/qsv: fix coding options

[Ivan Uskov]

Hello Kyle,

Saturday, May 28, 2016, 8:07:07 AM, you wrote:

zgc> From: Kyle Schwarz 

zgc> ---
zgc>  libavcodec/qsvenc.c | 34 ++
zgc>  1 file changed, 2 insertions(+), 32 deletions(-)

zgc> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
zgc> index 132cf47..b4821fc 100644
zgc> --- a/libavcodec/qsvenc.c
zgc> +++ b/libavcodec/qsvenc.c
zgc> @@ -132,9 +132,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc>  #if QSV_HAVE_CO2
zgc>  mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
zgc> print_profile(info->CodecProfile), info->CodecLevel);
zgc> @@ -186,13 +183,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc> info->ICQQuality, co2->LookAheadDepth);
zgc>  }
zgc>  #endif
zgc> -#if QSV_HAVE_QVBR
-else if (info->>RateControlMethod == MFX_RATECONTROL_QVBR) {
zgc> -av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
zgc> -   co3->QVBRQuality);
zgc> -}
zgc> -#endif
zgc> -
zgc>  av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16"; NumRefFrame: 
%"PRIu16"\n",
zgc> info->NumSlice, info->NumRefFrame);
zgc>  av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
zgc> @@ -567,31 +557,11 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  .PPSBuffer = pps_buf, .PPSBufSize = sizeof(pps_buf)
zgc>  };
zgc>  
zgc> -mfxExtCodingOption co = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION,
zgc> -.Header.BufferSz = sizeof(co),
zgc> -};
zgc> -#if QSV_HAVE_CO2
zgc> -mfxExtCodingOption2 co2 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2,
zgc> -.Header.BufferSz = sizeof(co2),
zgc> -};
zgc> -#endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 co3 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
zgc> -.Header.BufferSz = sizeof(co3),
zgc> -};
zgc> -#endif
zgc> -
zgc>  mfxExtBuffer *ext_buffers[] = {
zgc>  (mfxExtBuffer*)&extradata,
zgc> -(mfxExtBuffer*)&co,
zgc> +(mfxExtBuffer*)&q->extco,
zgc>  #if QSV_HAVE_CO2
zgc> -(mfxExtBuffer*)&co2,
zgc> -#endif
zgc> -#if QSV_HAVE_CO3
zgc> -(mfxExtBuffer*)&co3,
zgc> +(mfxExtBuffer*)&q->extco2,
zgc>  #endif
zgc>  };
zgc>  
Could you please explain what exactly you are trying to fix by this patch?
I do not like this changes by two reasons:
1.   The   dump_video_param()   intended   to   dump   parameters  returned  by
MFXVideoENCODE_GetVideoParam();  You can  not use q->extco and q->extco2 here
because  are  can be differ that values really used by encoder, here internal
adjustments possible.
2. Disabling preprocessor conditions does break compatibility with different 
MSDK
versions.  For  example  MFX_EXTBUFF_CODING_OPTION2  existing since MSDK 1.6,
MFX_EXTBUFF_CODING_OPTION3 existing since MSDK 1.11



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Thilo Borgmann]

Am 30.05.16 um 14:15 schrieb Carl Eugen Hoyos:
> Rostislav Pehlivanov  gmail.com> writes:
> 
>> Anyone can go to fairs, mentor for GSoC, write on the MLs, etc. 
>> Not everyone has the time.
> 
> This is true, I completely agree.
> I am not sure if I understand the relevance though: The list of 
> people on the voters committee contains both people who have 
> (a certain amount of) patches in FFmpeg but also people with 
> no (or only a very small number of) commits.
> So I don't think this is related.
> 
>> The committe was made to govern this project in case questions 
>> (mainly technical) need to be resolved.
> 
> Yes, probably.
> 
>> And answering technical questions requires knowledge of the 
>> codebase.
> 
> Of course, this is why Thilo should be part of the committee.
> 
>> The codebase changes over time. New features like codecpar were 
>> added a bit more than a month ago. So someone who continuously 
>> improves the codebase would also follow what happens in the
>> project and be qualified to make an answer.
> 
> Yes.
> Note that I did mention Thilo fixed one of the codecpar regressions 
> making him qualified under your conditions.

Let's stop arguing, please. I'm out of the current vote anyway and if for
Rostislav (and probably others) it's just about counting commits I'm definitely
not among the top committers. If that's a valid metric for activity is another
question. However, IIRC the current committee has been chosen by that and
therefore it is kind of valid to weight that against me.

Thus if the voting committee wants me in, just vote me in. Everyone there should
be able to judge about my activity in the project including Rostislav who was
among the devs I've met and talked to at VDD'15 (IIRC). It's completely ok if he
thinks I'm not active enough for the committee.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Gerion Entrup]

On Sonntag, 29. Mai 2016 16:45:26 CEST Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, May 29, 2016 at 3:25 PM, Thilo Borgmann 
> wrote:
> 
> > Am 29.05.16 um 01:32 schrieb Michael Niedermayer:
> > > Hi
> > >
> > > It was suggested in the IRC meeting today that i start a vote to
> > > resolve if AVClass & AVOption should be added to AVCodecParameters
> > > This question needs to be awnsered before the next release because
> > > the ABI would be broken if its added afterwards
> > > the lack of any decission blocks the release which is worse than
> > > either decission, otherwise a vote might be silly for such technical
> > > question but eve a bad decission is better than no decission here
> > >
> > >
> > > The disadvanatges are:
> > > 1 more field in the struct
> > > a high level API that some feel is unneeded for AVCodecParameters
> > > it could be confusing to some that there are 2 different ways to
> > > access the fields
> > > people might use it as av_log() context when they intended to use a
> > > different context for it
> > > There are probably more please help fill the list if you know more
> > >
> > > The advanatges are:
> > > More consistent availability of AVOptions and AVClass in public
> > > structs
> > > Makes supporting multiple FFmpeg versions and distros easier and
> > > cleaner for applications. (reduces lists of #if version checks)
> > > Provides default/min/max values, allows basic validity checking within
> > > min/max
> > > Avoids mysterious crashes if an application uses avoption functions
> > > on AVCodecParameters
> > > Introspection
> > > Serialization support that may be usefull for ffserver or an application
> > > replacing ffserver
> > >
> > >
> > > An application that doesnt want to use AVOptions or AVClass can
> > > completey ignore them.
> > >
> > > Please state clearly if you agree to add AVClass&AVOption to
> > > AVCodecParameters or if you disagree about adding it or if you dont
> > > care either way
> >
> > I'm in favor of adding them.
> 
> 
> And you are not in the list either [1]...
Let me make a suggestion. I'm a member of several university commitees. I have 
not always voting rights in this commitees but nevertheless could say what is 
my opinion and be involved in the discussion.
So eventually do here. Everybody could say, what is his/her opinion, but only 
count (when the vote ends) the votes of the committee members. This could 
represent the comprehensive opinion maybe better, but defines also a definite 
voting mechanism.

Gerion


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Paul B Mahol]

On 5/30/16, Christophe Gisquet  wrote:
> Hi,
>
> 2016-05-29 21:51 GMT+02:00 Paul B Mahol :
>> +typedef struct Slice {
>> +uint32_t start;
>> +uint32_t size;
>> +} Slice;
>
> I'm not a security expert, but is there a reason for not using plain int
> there ?

I added check for offsets locally before those are set.

>
>> +typedef struct MagicYUVContext {
>> +AVFrame*p;
>> +int slice_height;
>> +int nb_slices;
>> +int planes;
>> +uint8_t *buf;
>> +int hshift[4];
>> +int vshift[4];
>> +Slice   *slices[4];
>> +int slices_size[4];
>> +uint8_t freq[4][256];
>> +VLC vlc[4];
>> +HuffYUVDSPContext   hdsp;
>> +} MagicYUVContext;
>
> I guess someone able to understand the code immediately understand
> what those are, but that's pretty sparse comment-wise.

Will add something.

>
>> +typedef struct HuffEntry {
>
> And another Huffman+prediction codec... I don't really see any
> valuable addition here... :(
>
>> +uint8_t  sym;
>> +uint8_t  len;
>> +uint32_t code;
>> +} HuffEntry;
>> +
>> +static int ff_magy_huff_cmp_len(const void *a, const void *b)
>> +{
>> +const HuffEntry *aa = a, *bb = b;
>> +return (aa->len - bb->len) * 256 + aa->sym - bb->sym;
>> +}
>> +
>> +static int build_huff(VLC *vlc, uint8_t *freq)
>> +{
>> +HuffEntry he[256];
>> +uint32_t codes[256];
>> +uint8_t bits[256];
>> +uint8_t syms[256];
>> +uint32_t code;
>> +int i, last;
>> +
>> +for (i = 0; i < 256; i++) {
>> +he[i].sym = 255 - i;
>> +he[i].len = freq[i];
>> +}
>> +qsort(he, 256, sizeof(*he), ff_magy_huff_cmp_len);
>
> ffmpeg seems to have libavutil/qsort.h, but I don't even know how much
> effort is needed to use it here.

Changed, doesn't help but maybe will for other archs.

>
>> +pred = get_bits(&b, 8);
>> +dst = p->data[i] + j * sheight * stride;
>> +for (k = 0; k < height; k++) {
>> +for (x = 0; x < width; x++) {
>> +int pix;
>> +if (get_bits_left(&b) <= 0) {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +pix = get_vlc2(&b, s->vlc[i].table, s->vlc[i].bits, 3);
>> +if (pix < 0) {
>> +return AVERROR_INVALIDDATA;
>> +}
>> +dst[x] = 255 - pix;
>> +}
>> +dst += stride;
>> +}
>> +
>> +if (pred == LEFT) {
>> +dst = p->data[i] + j * sheight * stride;
>> +s->hdsp.add_hfyu_left_pred(dst, dst, width, 0);
>> +dst += stride;
>> +for (k = 1; k < height; k++) {
>> +s->hdsp.add_hfyu_left_pred(dst, dst, width,
>> dst[-stride]);
>> +dst += stride;
>> +}
>> +} else if (pred == GRADIENT) {
> [...]
>
> That's somewhat similar to png paeth, except not actually reusable. I
> wonder if there's something in libavcodec that could be reused, in
> which case moving it to the hdsp context would be nice)

Our Huffyuv decoder is still missing gradient prediction...

>
>> +} else if (pred == MEDIAN) {
> [...]
>> +} else {
>
> So, that's maybe a detail at this point, and you want to move quickly
> to other stuff, but:
> would you like to look at e.g. huffyuvdec or pngdec for a code that is
> not as nice looking, but more cache-friendly?
>
> Basically, you move the first line out of the loops, and then do
> sequentially, per row in the loop, bitstream reading, reconstruction
> (residual+prediction) and any post-processing...

Just tried, didn't help much here.

>
>> +if (decorrelate) {
>> +uint8_t *b = p->data[0];
>> +uint8_t *g = p->data[1];
>> +uint8_t *r = p->data[2];
>> +
>> +for (i = 0; i < p->height; i++) {
>> +for (x = 0; x < p->width; x++) {
>> +b[x] += g[x];
>> +r[x] += g[x];
>> +}
>> +b += p->linesize[0];
>> +g += p->linesize[1];
>> +r += p->linesize[2];
>> +}
>> +}
>
> ... in particular, this step, that could be done line-wise, inside the
> threaded decoding, if I'm not mistaken. (cf. also png's deloco)

Moved.

>
> Otherwise, I don't see much of anything that would require another
> reviewing round.
> --
> Christophe
> ___
> 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] avcodec: add MagicYUV decoder

[Piotr Bandurski]

Hi,

> patch attached.

Is decoding of interlaced video supported? Because I get here invalid output.

Also crash happens with this fuzzed file:

https://www.datafilehost.com/d/c64eb5b1

Regards

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Michael Niedermayer]

On Sun, May 29, 2016 at 09:39:58PM -0400, Ronald S. Bultje wrote:
> Hi Thilo,
> 
> On Sun, May 29, 2016 at 8:59 PM, Thilo Borgmann 
> wrote:
> 
> > Hi,
> >
> > > [...]
> > >>
> > >> The vote will end 1 week from now, simple 50% majority (Yes vs no)
> > >> I dont really know who should be eligible for voting, so i suggest
> > >> everyone from the vote comittee but iam happy with anything, just
> > >> stating somethng ...
> > >>
> > >
> > > I am in favor of adding AVClass.
> > 
> > 
> >  You're not in the list [1]?
> > 
> >  Ronald
> > 
> >  [1]
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182207.html
> > >>>
> > >>> At least one the person in the list has apparently left the project, so
> > >> maybe
> > >>> we could suggest adding recurrent contributors like Marton and Thilo.
> > >>
> > >> Probably, yes. Is it just Thilo or are others missing also? What were
> > the
> > >> criteria again?
> > >>
> > >> Ronald
> > >
> > > The original criteria was i think 50 commits in the past year or so. This
> > > was back in mid 2015. After that a couple people were added based on
> > > suggestions since many long time contributors and maintainers didn't meet
> > > that criteria.
> >
> > Thanks for pointing out, Ronald. Sorry, I've just missed the committee
> > part...
> >
> > I'd like not to be added to the committee while a vote is ongoing.
> > Please consider my vote to be void.
> 
> 
> (If you want,) I still think you could be added for e.g. future votes?

+1

[...]
-- 
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] [PATCH] rtpenc: packetizer for VP9 RTP payload format (draft v2)

[Thomas Volkert]

From: Thomas Volkert 

---
 libavformat/Makefile |  1 +
 libavformat/rtpenc.c | 14 +
 libavformat/rtpenc.h |  1 +
 libavformat/rtpenc_vp9.c | 54 
 libavformat/sdp.c|  4 
 5 files changed, 74 insertions(+)
 create mode 100644 libavformat/rtpenc_vp9.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6684ead..481f3b1 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -413,6 +413,7 @@ OBJS-$(CONFIG_RTP_MUXER) += rtp.o \
 rtpenc.o  \
 rtpenc_vc2hq.o  \
 rtpenc_vp8.o  \
+rtpenc_vp9.o\
 rtpenc_xiph.o \
 avc.o hevc.o
 OBJS-$(CONFIG_RTSP_DEMUXER)  += rtsp.o rtspdec.o httpauth.o \
diff --git a/libavformat/rtpenc.c b/libavformat/rtpenc.c
index f477650..db1ec81 100644
--- a/libavformat/rtpenc.c
+++ b/libavformat/rtpenc.c
@@ -75,6 +75,7 @@ static int is_supported(enum AVCodecID id)
 case AV_CODEC_ID_VORBIS:
 case AV_CODEC_ID_THEORA:
 case AV_CODEC_ID_VP8:
+case AV_CODEC_ID_VP9:
 case AV_CODEC_ID_ADPCM_G722:
 case AV_CODEC_ID_ADPCM_G726:
 case AV_CODEC_ID_ILBC:
@@ -211,6 +212,16 @@ static int rtp_write_header(AVFormatContext *s1)
 s->nal_length_size = (st->codecpar->extradata[21] & 0x03) + 1;
 }
 break;
+case AV_CODEC_ID_VP9:
+if (s1->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL) {
+av_log(s, AV_LOG_ERROR,
+   "Packetizing VP9 is experimental and its specification is "
+   "still in draft state. "
+   "Please set -strict experimental in order to enable it.\n");
+ret = AVERROR_EXPERIMENTAL;
+goto fail;
+}
+break;
 case AV_CODEC_ID_VORBIS:
 case AV_CODEC_ID_THEORA:
 s->max_frames_per_packet = 15;
@@ -594,6 +605,9 @@ static int rtp_write_packet(AVFormatContext *s1, AVPacket 
*pkt)
 case AV_CODEC_ID_VP8:
 ff_rtp_send_vp8(s1, pkt->data, size);
 break;
+case AV_CODEC_ID_VP9:
+ff_rtp_send_vp9(s1, pkt->data, size);
+break;
 case AV_CODEC_ID_ILBC:
 rtp_send_ilbc(s1, pkt->data, size);
 break;
diff --git a/libavformat/rtpenc.h b/libavformat/rtpenc.h
index dc30a6d..70f18ed 100644
--- a/libavformat/rtpenc.h
+++ b/libavformat/rtpenc.h
@@ -93,6 +93,7 @@ void ff_rtp_send_mpegvideo(AVFormatContext *s1, const uint8_t 
*buf1, int size);
 void ff_rtp_send_xiph(AVFormatContext *s1, const uint8_t *buff, int size);
 void ff_rtp_send_vc2hq(AVFormatContext *s1, const uint8_t *buf, int size, int 
interlaced);
 void ff_rtp_send_vp8(AVFormatContext *s1, const uint8_t *buff, int size);
+void ff_rtp_send_vp9(AVFormatContext *s1, const uint8_t *buff, int size);
 void ff_rtp_send_jpeg(AVFormatContext *s1, const uint8_t *buff, int size);
 
 const uint8_t *ff_h263_find_resync_marker_reverse(const uint8_t *av_restrict 
start,
diff --git a/libavformat/rtpenc_vp9.c b/libavformat/rtpenc_vp9.c
new file mode 100644
index 000..172ab21
--- /dev/null
+++ b/libavformat/rtpenc_vp9.c
@@ -0,0 +1,54 @@
+/*
+ * RTP packetizer for VP9 payload format (draft version 02) - experimental
+ * Copyright (c) 2016 Thomas Volkert 
+ *
+ * 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 "rtpenc.h"
+
+#define RTP_VP9_DESC_REQUIRED_SIZE 1
+
+void ff_rtp_send_vp9(AVFormatContext *ctx, const uint8_t *buf, int size)
+{
+RTPMuxContext *rtp_ctx = ctx->priv_data;
+int len;
+
+rtp_ctx->timestamp  = rtp_ctx->cur_timestamp;
+rtp_ctx->buf_ptr= rtp_ctx->buf;
+
+/* mark the first fragment */
+*rtp_ctx->buf_ptr++ = 0x08;
+
+while (size > 0) {
+len = FFMIN(size, rtp_ctx->max_payload_size - 
RTP_VP9_DESC_REQUIRED_SIZE);
+
+if (len == size) {
+/* mark the last fragment */
+rtp_ctx->buf[0] |= 0x04;
+}
+
+memcpy(rtp_ctx->buf_ptr, buf, len);
+ff_rtp_send_data(ctx, rtp_ctx->buf, len + RTP_VP9_DESC_REQ

Re: [FFmpeg-devel] AVClass & AVOption [VOTE]

[Nicolas George]

Le primidi 11 prairial, an CCXXIV, Ronald S. Bultje a écrit :
> Probably, yes. Is it just Thilo or are others missing also? What were the
> criteria again?

There are no criteria. There were criteria for the initial list, but after
that the list evolves by co-optation.

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] rtpenc: packetizer for VP9 RTP payload format (draft v2)

[Ronald S. Bultje]

Hi,

On Mon, May 30, 2016 at 10:41 AM, Thomas Volkert  wrote:

> From: Thomas Volkert 
>
> ---
>  libavformat/Makefile |  1 +
>  libavformat/rtpenc.c | 14 +
>  libavformat/rtpenc.h |  1 +
>  libavformat/rtpenc_vp9.c | 54
> 
>  libavformat/sdp.c|  4 
>  5 files changed, 74 insertions(+)
>  create mode 100644 libavformat/rtpenc_vp9.c


No opinion on the patch itself yet, but I'm wondering if you've tested this
under real conditions with the built-in and libvpx-based decoders? I'm
asking because IIRC the built-in ffvp9 decoder doesn't deal with missing
references well at all (it just bails out), so it might be that under real
network conditions, it doesn't work all that well...

(That doesn't disqualify the patch in any way, but it would be good to
document somewhere for people trying to use this.)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Paul B Mahol]

On 5/30/16, Piotr Bandurski  wrote:
> Hi,
>
>> patch attached.
>
> Is decoding of interlaced video supported? Because I get here invalid
> output.
>
> Also crash happens with this fuzzed file:
>
> https://www.datafilehost.com/d/c64eb5b1
>
> Regards

Can you create YUVA video somehow? I can't with virtualdub.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat: Add Pro-MPEG CoP #3-R2 FEC protocol

[Michael Niedermayer]

On Mon, May 30, 2016 at 11:04:03AM +0200, Vlad Tarca wrote:
[...]
> +static int prompeg_init(URLContext *h, const uint8_t *buf, int size) {
> +PrompegContext *s = h->priv_data;
> +uint32_t seed;
> +int recovery_len, bitstring_len, rtp_buf_len;
> +int i;
> +
> +s->fec_buf = NULL;
> +s->rtp_buf = NULL;
> +
> +s->packet_idx = 0;
> +s->packet_idx_max = s->l * s->d;
> +s->packet_size = size;
> +

> +recovery_len = size - 12;

can size be INT_MIN ?
if so this can overflow and nothing after this line can correct this
the compiler has every right to crash you here or do anything else
signed overflow is undefined in C, unsigned is defined


> +if (recovery_len <= 0) {
> +av_log(h, AV_LOG_ERROR, "Invalid recovery length\n");
> +return AVERROR_INVALIDDATA;
> +}
> +s->recovery_len = recovery_len;
> +
> +rtp_buf_len = 12 + 16 + s->recovery_len;

same issue here


> +if (rtp_buf_len <= 0 || rtp_buf_len >= INT_MAX / sizeof (uint8_t)) {

sizeof (uint8_t) is 1

rtp_buf_len can never be larger than INT_MAX as its a int


[...]
> +static int prompeg_close(URLContext *h) {
> +PrompegContext *s = h->priv_data;
> +int i;
> +
> +ffurl_close(s->fec_col_hd);
> +ffurl_close(s->fec_row_hd);

ffurl_closep() also clears the pointer


[...]
> @@ -561,6 +616,9 @@ static int rtp_close(URLContext *h)
>  
>  ffurl_close(s->rtp_hd);
>  ffurl_close(s->rtcp_hd);

> +if (s->fec) {
> +ffurl_close(s->fec_hd);
> +}

why does this need a check ?
isnt fec_hd NULL if it shouldnt be closed ?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 回复: Re:Re:Re: [PATCH 07/11] avcodec/mips: loongson optimize h264qpel with mmi v2

[周晓勇]

please review this patch again, thank you


在2016年05月25日 17:40 ，周晓勇写道：

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Piotr Bandurski]

> Can you create YUVA video somehow? I can't with virtualdub.

https://www.datafilehost.com/d/49ea26f8

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Paul B Mahol]

On 5/30/16, Piotr Bandurski  wrote:
> Hi,
>
>> patch attached.
>
> Is decoding of interlaced video supported? Because I get here invalid
> output.

Will try to fix it.

>
> Also crash happens with this fuzzed file:
>
> https://www.datafilehost.com/d/c64eb5b1

Locally fixed.

>
> Regards
>
> ___
> 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] avcodec: add MagicYUV decoder

[Paul B Mahol]

On 5/29/16, Paul B Mahol  wrote:
> Hi,
>
> patch attached.
>

Updated patch attached.
From 6986dd8f6ee3625daaa0ff80256e4a353c4268c1 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Sun, 22 May 2016 15:18:30 +0200
Subject: [PATCH] avocdec: add MagicYUV decoder

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavcodec/magicyuv.c   | 467 
 libavformat/riff.c  |   1 +
 6 files changed, 478 insertions(+)
 create mode 100644 libavcodec/magicyuv.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 46dd9e1..a343f71 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -348,6 +348,7 @@ OBJS-$(CONFIG_LOCO_DECODER)+= loco.o
 OBJS-$(CONFIG_M101_DECODER)+= m101.o
 OBJS-$(CONFIG_MACE3_DECODER)   += mace.o
 OBJS-$(CONFIG_MACE6_DECODER)   += mace.o
+OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
 OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
 OBJS-$(CONFIG_METASOUND_DECODER)   += metasound.o metasound_data.o \
   twinvq.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6d0a7e7..7aa54ee 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -219,6 +219,7 @@ void avcodec_register_all(void)
 REGISTER_ENCODER(LJPEG, ljpeg);
 REGISTER_DECODER(LOCO,  loco);
 REGISTER_DECODER(M101,  m101);
+REGISTER_DECODER(MAGICYUV,  magicyuv);
 REGISTER_DECODER(MDEC,  mdec);
 REGISTER_DECODER(MIMIC, mimic);
 REGISTER_ENCDEC (MJPEG, mjpeg);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 00d0ef8..339a1b2 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -406,6 +406,7 @@ enum AVCodecID {
 AV_CODEC_ID_CFHD,
 AV_CODEC_ID_TRUEMOTION2RT,
 AV_CODEC_ID_M101,
+AV_CODEC_ID_MAGICYUV,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 077b2d4..5fd946e 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1542,6 +1542,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("Duck TrueMotion 2.0 Real Time"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_MAGICYUV,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "magicyuv",
+.long_name = NULL_IF_CONFIG_SMALL("MagicYUV Lossless Video"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
 
 /* various PCM "codecs" */
 {
diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
new file mode 100644
index 000..4f84d19
--- /dev/null
+++ b/libavcodec/magicyuv.c
@@ -0,0 +1,467 @@
+/*
+ * MagicYUV decoder
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * 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 "libavutil/qsort.h"
+#include "avcodec.h"
+#include "bytestream.h"
+#include "get_bits.h"
+#include "huffyuvdsp.h"
+#include "internal.h"
+#include "thread.h"
+
+typedef struct Slice {
+uint32_t start;
+uint32_t size;
+} Slice;
+
+typedef enum Prediction {
+LEFT = 1,
+GRADIENT,
+MEDIAN,
+} Prediction;
+
+typedef struct MagicYUVContext {
+AVFrame*p;
+int slice_height;
+int nb_slices;
+int planes; // number of encoded planes in bitstream
+int decorrelate;// postprocessing work
+int interlaced; // video is interlaced
+uint8_t *buf;   // pointer to AVPacket->data
+int hshift[4];
+int vshift[4];
+Slice   *slices[4]; // slice positions and size in bitstream for each plane
+int slices_size[4];
+uint8_t len[4][256];// table of code lengths for each plane
+VLC vlc[4]; // VLC f

[FFmpeg-devel] has_b_frames is larger in decoder than demuxer

[gaggag1]

hi there,
so i was creating thumbnails of some... special video files.. and one of  
the video files caused this error


[mpeg4 @ 0458fc00] has_b_frames is larger in decoder than demuxer 1 > 0.

with the note that i should tell you people. the file is 450MB though, and  
i dont know how to generate a "sample" that i can upload. should i upload  
the whole file?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Piotr Bandurski]

> Updated patch attached.

There seems to be some bug in interlaced support (related to "Full range YUV" 
option in encoder).

How to reproduce: encode video with enabled "Interlaced" and "Full range YUV" 
options together
and then try to decode this with your latest version of decoder.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add MagicYUV decoder

[Paul B Mahol]

On 5/30/16, Piotr Bandurski  wrote:
>> Updated patch attached.
>
> There seems to be some bug in interlaced support (related to "Full range
> YUV" option in encoder).
>
> How to reproduce: encode video with enabled "Interlaced" and "Full range
> YUV" options together
> and then try to decode this with your latest version of decoder.

Fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] has_b_frames is larger in decoder than demuxer

[Michael Niedermayer]

On Sat, May 28, 2016 at 05:12:42PM +0200, gaggag1 wrote:
> hi there,
> so i was creating thumbnails of some... special video files.. and
> one of the video files caused this error
> 
> [mpeg4 @ 0458fc00] has_b_frames is larger in decoder than demuxer 1 > 0.
> 
> with the note that i should tell you people. the file is 450MB
> though, and i dont know how to generate a "sample" that i can
> upload. should i upload the whole file?

if you cannot make it smaller, and noone has another file (maybe wait
a day or 2 for replies) then yes upload

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 07/11] avcodec/mips: loongson optimize h264qpel with mmi v2

[Michael Niedermayer]

On Wed, May 25, 2016 at 05:40:44PM +0800, 周晓勇 wrote:
> i have fix up the error functions in h264qpel_mmi, please try the new patch 
> below
> 
> 
> ---
> From a55e3a93a30226e3f0fb7d2d8ac43e74b5eae5d6 Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong 
> Date: Wed, 25 May 2016 16:07:38 +0800
> Subject: [PATCH] avcodec/mips/h264qpel_mmi.c: Version 2 of the optimizations
>  for loongson mmi
> 
> 
> 1. no longer use the register names directly and optimized code format
> 2. to be compatible with O32, specify type of address variable with mips_reg 
> and handle the address variable with PTR_ operator
> 3. use uld and mtc1 to workaround cpu 3A2000 gslwlc1 bug (gslwlc1 instruction 
> extension bug in O32 ABI)
> 4. h264qpel use hepldsp optimizations
> ---
>  libavcodec/mips/h264qpel_mmi.c | 3824 
> +++-
>  1 file changed, 2225 insertions(+), 1599 deletions(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/movenc: propagate shift_data errors properly

[Marton Balint]

On Mon, 30 May 2016, Michael Niedermayer wrote:


On Sun, May 29, 2016 at 05:17:13PM +0200, Marton Balint wrote:

The second one is not explicitly needed, as res is not reset, but it is there
for consistency.

Signed-off-by: Marton Balint 
---
 libavformat/movenc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)


LGTM if the error path was tested


Applied the series with the styling modification suggested by carl.

Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffplay: simplify display code

[Marton Balint]

On Sun, 22 May 2016, Marton Balint wrote:


And get rid of frame_queue_prev.



Applied.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] webp decode not supported yet?

[Dan WU]

Hey guys, I just want to confirm if webp decode is not supported yet? I
build ffmpeg and enabled as many libraries as I can like:

> ./configure  --prefix=/usr/local --enable-gpl --enable-nonfree
> --enable-libass --enable-libfdk-aac --enable-libfreetype
> --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis
> --enable-libvpx --enable-libx264 --enable-libxvid --enable-libwebp
> --enable-demuxer=webp_pipe --enable-decoder=webp
> --extra-ldflags=-L/usr/local/lib --extra-cflags=-I/usr/local/include

but then I do this: *./ffmpeg -i test.webp -vframes 1 frame.jpg *

want to extract 1 frame from webp animated image.

I still got the error like:

> ffmpeg version N-80121-gbe96ebd Copyright (c) 2000-2016 the FFmpeg
> developers
>   built with Apple LLVM version 7.3.0 (clang-703.0.31)
>   configuration: --prefix=/usr/local --enable-gpl --enable-nonfree
> --enable-libass --enable-libfdk-aac --enable-libfreetype
> --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis
> --enable-libvpx --enable-libx264 --enable-libxvid --enable-libwebp
> --enable-demuxer=webp_pipe --enable-decoder=webp
> --extra-ldflags=-L/usr/local/lib --extra-cflags=-I/usr/local/include
>   libavutil  55. 24.100 / 55. 24.100
>   libavcodec 57. 43.100 / 57. 43.100
>   libavformat57. 37.101 / 57. 37.101
>   libavdevice57.  0.101 / 57.  0.101
>   libavfilter 6. 46.100 /  6. 46.100
>   libswscale  4.  1.100 /  4.  1.100
>   libswresample   2.  0.101 /  2.  0.101
>   libpostproc54.  0.100 / 54.  0.100
> [webp @ 0x7fb023801c00] skipping unsupported chunk: ANIM
> [webp @ 0x7fb023801c00] skipping unsupported chunk: ANMF
> Last message repeated 793 times
> [webp @ 0x7fb023801c00] image data not found
> [webp_pipe @ 0x7fb023800a00] decoding for stream 0 failed
> [webp_pipe @ 0x7fb023800a00] Could not find codec parameters for stream 0
> (Video: webp, none): unspecified size
> Consider increasing the value for the 'analyzeduration' and 'probesize'
> options
> Input #0, webp_pipe, from 'test.webp':
>   Duration: N/A, bitrate: N/A
> Stream #0:0: Video: webp, none, 25 tbr, 25 tbn
> [buffer @ 0x7fb022f00120] Unable to parse option value "0x0" as image size
> [buffer @ 0x7fb022f00120] Unable to parse option value "-1" as pixel
> format
> [buffer @ 0x7fb022f00120] Unable to parse option value "0x0" as image size
> [buffer @ 0x7fb022f00120] Error setting option video_size to value 0x0.
> [graph 0 input from stream 0:0 @ 0x7fb022f00060] Error applying options
> to the filter.


the code here http://ffmpeg.org/doxygen/trunk/webp_8c_source.html#l01503

shows
the ANMF chunk been skipped? does that mean I cannot extract frame from
webp using ffmpeg for now?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel