Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Sun, 24 Jan 2016 20:03:01 -0500 "Ronald S. Bultje" wrote: > Hi, > > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes > wrote: > > Unfortunately that doesn't alleviate the other issues, like the > > complexity needed in the decoders during frame threading, or the extra > > resources needed (extra image surfaces for every thread). > > > > So, the extra code is just in the decoders, which already need it anyway > (because they implement frame-mt), right? Or do hwaccels need extra code > also? > > The extra resources aren't a big deal IMO. Memory use isn't typically a big > issue, we're adding a fw kb extra for contexts but practically all memory > is in framebuffers regardless. It's can be a big deal for hardware decoding, because hw surfaces might be a more constrained resource than system RAM. Also, you often have to preallocate _all_ surfaces you're going to use, so you'll have to add the exact number of additionally needed surfaces to the preallocation. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/demuxers: add some concat demuxer script examples
On 19.01.2016 15:47, Tobias Rapp wrote: Attached patch adds some example scripts for the concat demuxer to the documentation. Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
On 1/25/16, Kieran Kunhya wrote: > Decodes YUV 4:2:2 10-bit and RGB 12-bit files. > Older files with more subbands, skips, Bayer, alpha not supported. > Alpha requires addition of GBRAP12 pixel format. > --- > libavcodec/Makefile | 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/avcodec.h| 1 + > libavcodec/cfhd.c | 744 > > libavcodec/cfhd.h | 107 +++ > libavcodec/cfhddata.c | 327 + > libavcodec/codec_desc.c | 7 + > libavformat/riff.c | 1 + > 8 files changed, 1189 insertions(+) > create mode 100644 libavcodec/cfhd.c > create mode 100644 libavcodec/cfhd.h > create mode 100644 libavcodec/cfhddata.c > [...] > +s->plane[i].idwt_buf = av_malloc(height * stride * > sizeof(*s->plane[i].idwt_buf)); > +s->plane[i].idwt_tmp = av_malloc(height * stride * > sizeof(*s->plane[i].idwt_tmp)); av_malloc_array() rest LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
On 25 January 2016 at 00:34, Kieran Kunhya wrote: > Decodes YUV 4:2:2 10-bit and RGB 12-bit files. > Older files with more subbands, skips, Bayer, alpha not supported. > Alpha requires addition of GBRAP12 pixel format. > --- > libavcodec/Makefile | 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/avcodec.h| 1 + > libavcodec/cfhd.c | 744 > > libavcodec/cfhd.h | 107 +++ > libavcodec/cfhddata.c | 327 + > libavcodec/codec_desc.c | 7 + > libavformat/riff.c | 1 + > 8 files changed, 1189 insertions(+) > create mode 100644 libavcodec/cfhd.c > create mode 100644 libavcodec/cfhd.h > create mode 100644 libavcodec/cfhddata.c > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile Something minor: replace the 2 "for (;;)" loops with a "while (1)". The rest of the (modern) code uses this notation. Any compilers that don't support this have long been unsupported. Otherwise LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun wrote: > On 24.01.2016 22:57, Hendrik Leppkes wrote: >> While links are in theory a good idea, creating directory links on >> windows requires elevated privileges. Don't ask me why, I don't know, >> but that makes this unfortunately impractical. >> Copying files around between different physical media is not a >> solution, but an ugly hack and a build performance regression. See >> earlier point about re-opening the review phase of this change to >> discuss such "solutions". > > Oh well, MSVC just doesn't want this to work... > > Then let's do it the other way around: create a link from the destination > path to the source path. > If that link can be created, it can be used as relative path and otherwise > one can still use the full source path. > > Attached is a patch implementing this. > It should not be possible that this breaks anywhere. > > Feel free to apply this if it makes MSVC builds work again. > msys doesn't seem to like creating directory symlinks with ln -s, for some reason it copies the folder instead, which is of course terribly slow. Could try to use the windows link creating function, but thats probably too much trouble. If we already have a way to fallback to the "old way", maybe this could be put under a OS conditional, ie. exclude msys/cygwin? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
On Mon, Jan 25, 2016 at 11:01 AM, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun > wrote: >> On 24.01.2016 22:57, Hendrik Leppkes wrote: >>> While links are in theory a good idea, creating directory links on >>> windows requires elevated privileges. Don't ask me why, I don't know, >>> but that makes this unfortunately impractical. >>> Copying files around between different physical media is not a >>> solution, but an ugly hack and a build performance regression. See >>> earlier point about re-opening the review phase of this change to >>> discuss such "solutions". >> >> Oh well, MSVC just doesn't want this to work... >> >> Then let's do it the other way around: create a link from the destination >> path to the source path. >> If that link can be created, it can be used as relative path and otherwise >> one can still use the full source path. >> >> Attached is a patch implementing this. >> It should not be possible that this breaks anywhere. >> >> Feel free to apply this if it makes MSVC builds work again. >> > > msys doesn't seem to like creating directory symlinks with ln -s, for > some reason it copies the folder instead, which is of course terribly > slow. > Could try to use the windows link creating function, but thats > probably too much trouble. > > If we already have a way to fallback to the "old way", maybe this > could be put under a OS conditional, ie. exclude msys/cygwin? > Looking at it, we even have a handy configure property that identifies problem systems: if enabled dos_paths; then - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for 1, 2, 4 and 8 bpp
On Mon, Jan 25, 2016 at 03:42:44AM +, Mats Peterson wrote: > Alright Michael, I'm currently rather ambivalent regarding whether 1 bpp in > AVI should be just black & white or any color. But the term "monochrome" has > to mean black & white after all. Windows Paint forces black & white when > saving a 1 bpp BMP file, for example. So does several Mac programs when > saving 1-bit files, but the QuickTime File Format Specification explicitly > says that 1-bit mode is palettized, and mentions nothing about its being > "monochrome" or black & white. > > So, here's a patch that doesn't touch the AVI part, but fixes the line > alignment of 1 bpp for QuickTime, and 2, 4 and 8 bpp for AVI and QuickTime. > It also caters for the packet row stride at the same time. These two issues > together are rather atomic by nature, and not easily split, as you can > probably understand. > > 1 bpp AVI, when using monow, will still be "incorrectly" aligned on 4-byte > boundaries when using odd-width files, but that's another matter. I don't > want to touch the default 4-byte alignment, since I'm not entirely sure of > how it will affect other depths. > > Should it later on be desirable to use pal8 for AVI as well, it's just a > matter of changing one line in raw.c. But then FATE will fail, unless the > pal8 to yuv420p conversion discrepancies are fixed. As I wrote to you by > e-mail, it currently produces different output from using monow as the source. > > Mats > > -- > Mats Peterson > http://matsp888.no-ip.org/~mats/ > rawdec.c | 92 > +-- > 1 file changed, 61 insertions(+), 31 deletions(-) > 2787ced9908b56c3db03b112e158b1ce4bcd437e > 0001-lavc-rawdec-Use-16-byte-line-alignment-for-1-2-4-and.patch > From 83d773382c1c1e42964542a782f14ffe64ba8859 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Mon, 25 Jan 2016 03:59:49 +0100 > Subject: [PATCH] lavc/rawdec: Use 16-byte line alignment for 1, 2, 4 and 8 bpp > > This patch aligns the lines of 1 bpp depth for QuickTime, and 2, 4 and 8 > bpp depths for AVI and QuickTime, on 16-byte boundaries. At the same > time, the packet row stride is properly catered for. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add streamselect and astreamselect filter
On 1/21/16, Paul B Mahol wrote:
> Hi,
> patch attached.
>
2nd version attached.
From 1ec18cd004e227fae2e4f34654cdc02474a38b7d Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 18 Jan 2016 11:22:32 +0100
Subject: [PATCH] avfilter: add streamselect and astreamselect filter
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Clément Bœsch
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 23 +++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_streamselect.c | 341 +++
4 files changed, 368 insertions(+)
create mode 100644 libavfilter/f_streamselect.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 8545a2e..e1cb91c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11212,6 +11212,29 @@ stereo3d=abl:sbsr
@end example
@end itemize
+@section streamselect, astreamselect
+Select video or audio streams.
+
+The filter accepts the following options:
+
+@table @option
+@item inputs
+Set number of inputs. Default is 2.
+
+@item map
+Set input indexes to remap to outputs.
+@end table
+
+@subsection Commands
+
+The @code{streamselect} and @code{astreamselect} filter supports the following
+commands:
+
+@table @option
+@item map
+Set input indexes to remap to outputs.
+@end table
+
@anchor{spp}
@section spp
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b93e5f2..2225c8a 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -57,6 +57,7 @@ OBJS-$(CONFIG_ASETTB_FILTER) += settb.o
OBJS-$(CONFIG_ASHOWINFO_FILTER) += af_ashowinfo.o
OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
+OBJS-$(CONFIG_ASTREAMSELECT_FILTER) += f_streamselect.o
OBJS-$(CONFIG_ASYNCTS_FILTER)+= af_asyncts.o
OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
OBJS-$(CONFIG_ATRIM_FILTER) += trim.o
@@ -236,6 +237,7 @@ OBJS-$(CONFIG_SPLIT_FILTER) += split.o
OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
OBJS-$(CONFIG_SSIM_FILTER) += vf_ssim.o dualinput.o framesync.o
OBJS-$(CONFIG_STEREO3D_FILTER) += vf_stereo3d.o
+OBJS-$(CONFIG_STREAMSELECT_FILTER) += f_streamselect.o
OBJS-$(CONFIG_SUBTITLES_FILTER) += vf_subtitles.o
OBJS-$(CONFIG_SUPER2XSAI_FILTER) += vf_super2xsai.o
OBJS-$(CONFIG_SWAPUV_FILTER) += vf_swapuv.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1d48970..eff5af9 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -78,6 +78,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(ASHOWINFO, ashowinfo, af);
REGISTER_FILTER(ASPLIT, asplit, af);
REGISTER_FILTER(ASTATS, astats, af);
+REGISTER_FILTER(ASTREAMSELECT, astreamselect, af);
REGISTER_FILTER(ASYNCTS,asyncts,af);
REGISTER_FILTER(ATEMPO, atempo, af);
REGISTER_FILTER(ATRIM, atrim, af);
@@ -256,6 +257,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(SPP,spp,vf);
REGISTER_FILTER(SSIM, ssim, vf);
REGISTER_FILTER(STEREO3D, stereo3d, vf);
+REGISTER_FILTER(STREAMSELECT, streamselect, vf);
REGISTER_FILTER(SUBTITLES, subtitles, vf);
REGISTER_FILTER(SUPER2XSAI, super2xsai, vf);
REGISTER_FILTER(SWAPUV, swapuv, vf);
diff --git a/libavfilter/f_streamselect.c b/libavfilter/f_streamselect.c
new file mode 100644
index 000..2d2167c
--- /dev/null
+++ b/libavfilter/f_streamselect.c
@@ -0,0 +1,341 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct StreamSelectContext {
+const AVClass *class;
+int nb_inputs;
+char *map_str;
+int *map;
+int nb_map;
+int is_audio;
+
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libaacplus
Timothy Gu gmail.com> writes: > It's inferior to fdk-aac and has an arguably more problematic > license. Needs a Changelog entry and a news entry together with libvo. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.
Kieran Kunhya kunhya.com> writes: > The internal encoder is superior to libvo-aacenc. I thought this was the case for several years? Needs a Changelog entry and a news entry together with libaacplus. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for 1, 2, 4 and 8 bpp
applied thanks Thanks Michael. I'm actually working on a patch that aligns monow data properly on 16-byte boundaries. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)
On 21/01/16 23:17, Michael Niedermayer wrote: > On Wed, Jan 20, 2016 at 02:33:21PM +, Vicente Olivert Riera wrote: >> On 20/01/16 13:15, Michael Niedermayer wrote: >>> On Wed, Jan 20, 2016 at 12:21:37PM +, Vicente Olivert Riera wrote: On 20/01/16 12:05, Michael Niedermayer wrote: > On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote: >> Hello Michael, >> >> On 19/01/16 22:11, Michael Niedermayer wrote: >>> On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote: Signed-off-by: Vicente Olivert Riera --- Changes v5 -> v6: - Multiple changes: - Use separate if blocks when detecting the MIPS ISA, this way when a block disables one ISA it will be detected by the next one. Before the elif was preventing this to be done. - Don't use check_cflags and use only check_ldflags instead, which will check if that flag is valid for compiling and linking. The compiler may accept some cflags for compiling but not for linking, so if we check first for the cflags it will succeed, and the cflags will be added to the CFLAGS variable despite of the check_ldflags failing after that. This can cause problems because of having multiple incompatible cflags enabled at the same time. - Check if mipsfpu has been disabled, and if so, then use -msoft-float. This way we override the compiler default behavious which can be building for hard-float. - Explicitly disable the features that fail any check by adding "|| disable $feature" at the end of the checks chain. Changes v4 -> v5: - Check for msa.h and disable msa if not found. Changes v3 -> v4: - Nothing. Changes v2 -> v3: - Nothing. Changes v1 -> v2: - Add a block of code for mipsdspr2 which was previously placed in the first patch of this series causing a syntax error in the configure script. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html >>> >>> make distclean ; ../configure --cross-prefix=/usr/mips-linux-gnu/bin/ >>> --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux >>> --enable-cross-compile --disable-mipsfpu && make -j12 >>> results in pages of: >>> >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libswresample/libswresample.a(dither.o) uses soft float >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libswresample/libswresample.a(resample.o) uses soft float >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libswresample/libswresample.a(resample_dsp.o) uses soft float >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libavutil/libavutil.a(adler32.o) uses soft float >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libavutil/libavutil.a(aes.o) uses soft float >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libavutil/libavutil.a(aes_ctr.o) uses soft float >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: >>> Warning: libavfilter/filtfmts-test uses hard float, >>> libavutil/libavutil.a(audio_fifo.o) uses soft float >>> >>> >>> [...] >>> >> >> I can't reproduce your issue. Look: >> >> $ make distclean ; ./configure --cross-prefix=mips-linux-gnu- >> --arch=mips --target-os=linux --enable-cross-compile --disable-mipsfpu >> >> And then: >> >> $ make -j1 V=1 2>&1 | tee build.log >> >> And then: >> >> $ grep "uses soft float" build.log >> $ grep "filtfmts-test" build.log >> >> It gives me nothing. >> >> Also I try to find for that filtfmts-test file which your logs say that >> is using hard-float, and I cannot find it: >> > >> $ find . -name "filtfmts-test*" >> $ > > see libavfilter/filtfmts.c But do you have a generated filtfmts-test binary or a filtfmts.o file? Because when my build is finished I don't any anything of that. >>> >>> make libavfilter/filtfmts-test >>> CC libavfilter/filtfmts-test.o >>> libavfilter/fil
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.
On Mon, Jan 25, 2016 at 11:24 AM, Carl Eugen Hoyos wrote: > Kieran Kunhya kunhya.com> writes: > >> The internal encoder is superior to libvo-aacenc. > > I thought this was the case for several years? > It was, but now the internal one at least isn't marked experimental anymore, so users don't get deterred from using it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
On Mon, Jan 25, 2016 at 11:09 AM, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 11:01 AM, Hendrik Leppkes wrote: >> On Mon, Jan 25, 2016 at 2:34 AM, Andreas Cadhalpun >> wrote: >>> On 24.01.2016 22:57, Hendrik Leppkes wrote: While links are in theory a good idea, creating directory links on windows requires elevated privileges. Don't ask me why, I don't know, but that makes this unfortunately impractical. Copying files around between different physical media is not a solution, but an ugly hack and a build performance regression. See earlier point about re-opening the review phase of this change to discuss such "solutions". >>> >>> Oh well, MSVC just doesn't want this to work... >>> >>> Then let's do it the other way around: create a link from the destination >>> path to the source path. >>> If that link can be created, it can be used as relative path and otherwise >>> one can still use the full source path. >>> >>> Attached is a patch implementing this. >>> It should not be possible that this breaks anywhere. >>> >>> Feel free to apply this if it makes MSVC builds work again. >>> >> >> msys doesn't seem to like creating directory symlinks with ln -s, for >> some reason it copies the folder instead, which is of course terribly >> slow. >> Could try to use the windows link creating function, but thats >> probably too much trouble. >> >> If we already have a way to fallback to the "old way", maybe this >> could be put under a OS conditional, ie. exclude msys/cygwin? >> > > Looking at it, we even have a handy configure property that identifies > problem systems: > if enabled dos_paths; then > Thinking about it dos_paths refers to the target OS, not the host, but a similar condition can of course be found to put this to bed. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)
On Mon, Jan 25, 2016 at 10:35:12AM +, Vicente Olivert Riera wrote: > On 21/01/16 23:17, Michael Niedermayer wrote: > > On Wed, Jan 20, 2016 at 02:33:21PM +, Vicente Olivert Riera wrote: > >> On 20/01/16 13:15, Michael Niedermayer wrote: > >>> On Wed, Jan 20, 2016 at 12:21:37PM +, Vicente Olivert Riera wrote: > On 20/01/16 12:05, Michael Niedermayer wrote: > > On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote: > >> Hello Michael, > >> > >> On 19/01/16 22:11, Michael Niedermayer wrote: > >>> On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote: > Signed-off-by: Vicente Olivert Riera > --- > Changes v5 -> v6: > - Multiple changes: > - Use separate if blocks when detecting the MIPS ISA, this way > when a block > disables one ISA it will be detected by the next one. Before > the elif was > preventing this to be done. > - Don't use check_cflags and use only check_ldflags instead, > which will > check if that flag is valid for compiling and linking. The > compiler may > accept some cflags for compiling but not for linking, so if we > check first > for the cflags it will succeed, and the cflags will be added to > the CFLAGS > variable despite of the check_ldflags failing after that. This > can cause > problems because of having multiple incompatible cflags enabled > at the same > time. > - Check if mipsfpu has been disabled, and if so, then use > -msoft-float. This > way we override the compiler default behavious which can be > building for > hard-float. > - Explicitly disable the features that fail any check by adding > "|| disable > $feature" at the end of the checks chain. > > Changes v4 -> v5: > - Check for msa.h and disable msa if not found. > > Changes v3 -> v4: > - Nothing. > > Changes v2 -> v3: > - Nothing. > > Changes v1 -> v2: > - Add a block of code for mipsdspr2 which was previously placed in > the > first patch of this series causing a syntax error in the configure > script. > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html > >>> > >>> make distclean ; ../configure --cross-prefix=/usr/mips-linux-gnu/bin/ > >>> --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > >>> --enable-cross-compile --disable-mipsfpu && make -j12 > >>> results in pages of: > >>> > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libswresample/libswresample.a(dither.o) uses soft float > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libswresample/libswresample.a(resample.o) uses soft float > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libswresample/libswresample.a(resample_dsp.o) uses soft float > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libavutil/libavutil.a(adler32.o) uses soft float > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libavutil/libavutil.a(aes.o) uses soft float > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libavutil/libavutil.a(aes_ctr.o) uses soft float > >>> /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > >>> Warning: libavfilter/filtfmts-test uses hard float, > >>> libavutil/libavutil.a(audio_fifo.o) uses soft float > >>> > >>> > >>> [...] > >>> > >> > >> I can't reproduce your issue. Look: > >> > >> $ make distclean ; ./configure --cross-prefix=mips-linux-gnu- > >> --arch=mips --target-os=linux --enable-cross-compile --disable-mipsfpu > >> > >> And then: > >> > >> $ make -j1 V=1 2>&1 | tee build.log > >> > >> And then: > >> > >> $ grep "uses soft float" build.log > >> $ grep "filtfmts-test" build.log > >> > >> It gives me nothing. > >> > >> Also I try to find for that filtfmts-test file which your logs say that > >> is using hard-float, and I cannot find it: > >> > > > >> $ find . -name "filtfmts-te
Re: [FFmpeg-devel] [PATCH v6 1/3] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)
On 25/01/16 11:32, Michael Niedermayer wrote: > On Mon, Jan 25, 2016 at 10:35:12AM +, Vicente Olivert Riera wrote: >> On 21/01/16 23:17, Michael Niedermayer wrote: >>> On Wed, Jan 20, 2016 at 02:33:21PM +, Vicente Olivert Riera wrote: On 20/01/16 13:15, Michael Niedermayer wrote: > On Wed, Jan 20, 2016 at 12:21:37PM +, Vicente Olivert Riera wrote: >> On 20/01/16 12:05, Michael Niedermayer wrote: >>> On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote: Hello Michael, On 19/01/16 22:11, Michael Niedermayer wrote: > On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote: >> Signed-off-by: Vicente Olivert Riera >> --- >> Changes v5 -> v6: >> - Multiple changes: >>- Use separate if blocks when detecting the MIPS ISA, this way >> when a block >> disables one ISA it will be detected by the next one. Before >> the elif was >> preventing this to be done. >>- Don't use check_cflags and use only check_ldflags instead, >> which will >> check if that flag is valid for compiling and linking. The >> compiler may >> accept some cflags for compiling but not for linking, so if we >> check first >> for the cflags it will succeed, and the cflags will be added to >> the CFLAGS >> variable despite of the check_ldflags failing after that. This >> can cause >> problems because of having multiple incompatible cflags enabled >> at the same >> time. >>- Check if mipsfpu has been disabled, and if so, then use >> -msoft-float. This >> way we override the compiler default behavious which can be >> building for >> hard-float. >>- Explicitly disable the features that fail any check by adding >> "|| disable >> $feature" at the end of the checks chain. >> >> Changes v4 -> v5: >> - Check for msa.h and disable msa if not found. >> >> Changes v3 -> v4: >> - Nothing. >> >> Changes v2 -> v3: >> - Nothing. >> >> Changes v1 -> v2: >> - Add a block of code for mipsdspr2 which was previously placed in >> the >>first patch of this series causing a syntax error in the configure >>script. >> >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html > > make distclean ; ../configure --cross-prefix=/usr/mips-linux-gnu/bin/ > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > --enable-cross-compile --disable-mipsfpu && make -j12 > results in pages of: > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libswresample/libswresample.a(dither.o) uses soft float > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libswresample/libswresample.a(resample.o) uses soft float > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libswresample/libswresample.a(resample_dsp.o) uses soft float > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libavutil/libavutil.a(adler32.o) uses soft float > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libavutil/libavutil.a(aes.o) uses soft float > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libavutil/libavutil.a(aes_ctr.o) uses soft float > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > Warning: libavfilter/filtfmts-test uses hard float, > libavutil/libavutil.a(audio_fifo.o) uses soft float > > > [...] > I can't reproduce your issue. Look: $ make distclean ; ./configure --cross-prefix=mips-linux-gnu- --arch=mips --target-os=linux --enable-cross-compile --disable-mipsfpu And then: $ make -j1 V=1 2>&1 | tee build.log And then: $ grep "uses soft float" build.log $ grep "filtfmts-test" build.log It gives me nothing. Also I try to find for that filtfmts-test file which your logs say that is using hard-float, and I cannot find it:
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.
On Mon, Jan 25, 2016 at 10:24:36AM +, Carl Eugen Hoyos wrote: > Kieran Kunhya kunhya.com> writes: > > > The internal encoder is superior to libvo-aacenc. > > I thought this was the case for several years? > > Needs a Changelog entry and a news entry together with > libaacplus. how does the speed of all the aac encoders compare ? we should keep the fastest and the one havng best quality per bit (assuming thats a single one and not multiple due to different behavior at different bitrates) also it may make sense to keep activly developed encoders so users and develoeprs can continue to test/compare and use them in case they improve [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libaacplus
On Sun, Jan 24, 2016 at 09:50:01AM -0800, Timothy Gu wrote: > It's inferior to fdk-aac and has an arguably more problematic > license. a reference to the comparision finding its inferriority should be added to the commit message the exact license should also be mentioned maybe [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-bit line alignment for AV_PIX_FMT_MONOWHITE
The line alignment for 1 bpp raw AV_PIX_FMT_MONOWHITE video (currently
used for AVI) was previously 4 bytes, which generated alignment warning
messages, not only for odd-width files. The alignment is now 16 bytes.
Mats
From 950fe2cd5da4b56feb2bd0e74173cd1c2c223df5 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Mon, 25 Jan 2016 13:02:52 +0100
Subject: [PATCH] lavc/rawdec: Use 16-bit line alignment for AV_PIX_FMT_MONOWHITE
The line alignment for 1 bpp raw AV_PIX_FMT_MONOWHITE video (currently
used for AVI) was previously 4 bytes, which generated alignment warning
messages, not only for odd-width files. The alignment is now 16 bytes.
---
libavcodec/rawdec.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 87cda32..3536943 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -41,7 +41,7 @@ typedef struct RawVideoContext {
AVBufferRef *palette;
int frame_size; /* size of the frame in bytes */
int flip;
-int is_1_2_4_8_bpp; // 1 bpp in mov, and 2, 4 and 8 bpp in avi/mov
+int is_1_2_4_8_bpp; // 1, 2, 4 and 8 bpp in avi/mov
int is_yuv2;
int is_lt_16bpp; // 16bpp pixfmt and bits_per_coded_sample < 16
int tff;
@@ -176,12 +176,18 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
|| avctx->bits_per_coded_sample == 2 || avctx->bits_per_coded_sample == 1) &&
-avctx->pix_fmt == AV_PIX_FMT_PAL8 &&
- (!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
+(avctx->pix_fmt == AV_PIX_FMT_PAL8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) &&
+(!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
context->is_1_2_4_8_bpp = 1;
-context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
- FFALIGN(avctx->width, 16),
- avctx->height, 1);
+if (avctx->bits_per_coded_sample == 1 && avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
+int row_bytes = avctx->width / 8 + (avctx->width & 7 ? 1 : 0);
+context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
+ FFALIGN(row_bytes, 16) * 8,
+ avctx->height, 1);
+} else
+context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
+ FFALIGN(avctx->width, 16),
+ avctx->height, 1);
} else {
context->is_lt_16bpp = av_get_bits_per_pixel(desc) == 16 && avctx->bits_per_coded_sample && avctx->bits_per_coded_sample < 16;
context->frame_size = av_image_get_buffer_size(avctx->pix_fmt, avctx->width,
@@ -217,16 +223,18 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if (!frame->buf[0])
return AVERROR(ENOMEM);
-// 1 bpp in mov, and 2, 4 and 8 bpp in avi/mov
+// 1, 2, 4 and 8 bpp in avi/mov
if (context->is_1_2_4_8_bpp) {
int i, j, row_pix = 0;
uint8_t *dst = frame->buf[0]->data;
-buf_size = context->frame_size - AVPALETTE_SIZE;
-if (avctx->bits_per_coded_sample == 8) {
+buf_size = context->frame_size -
+(avctx->pix_fmt == AV_PIX_FMT_PAL8 ? AVPALETTE_SIZE : 0);
+if (avctx->bits_per_coded_sample == 8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
+int pix_per_byte = avctx->pix_fmt == AV_PIX_FMT_MONOWHITE ? 8 : 1;
for (i = 0, j = 0; j < buf_size && isize; i++, j++) {
dst[j] = buf[i];
-row_pix++;
-if (row_pix == avctx->width) {
+row_pix += pix_per_byte;
+if (row_pix >= avctx->width) {
i += avpkt_stride - (i % avpkt_stride) - 1;
j += 16 - (j % 16) - 1;
row_pix = 0;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)
On Mon, Jan 25, 2016 at 11:50:36AM +, Vicente Olivert Riera wrote: > On 25/01/16 11:32, Michael Niedermayer wrote: > > On Mon, Jan 25, 2016 at 10:35:12AM +, Vicente Olivert Riera wrote: > >> On 21/01/16 23:17, Michael Niedermayer wrote: > >>> On Wed, Jan 20, 2016 at 02:33:21PM +, Vicente Olivert Riera wrote: > On 20/01/16 13:15, Michael Niedermayer wrote: > > On Wed, Jan 20, 2016 at 12:21:37PM +, Vicente Olivert Riera wrote: > >> On 20/01/16 12:05, Michael Niedermayer wrote: > >>> On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote: > Hello Michael, > > On 19/01/16 22:11, Michael Niedermayer wrote: > > On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera > > wrote: > >> Signed-off-by: Vicente Olivert Riera > >> --- > >> Changes v5 -> v6: > >> - Multiple changes: > >>- Use separate if blocks when detecting the MIPS ISA, this way > >> when a block > >> disables one ISA it will be detected by the next one. Before > >> the elif was > >> preventing this to be done. > >>- Don't use check_cflags and use only check_ldflags instead, > >> which will > >> check if that flag is valid for compiling and linking. The > >> compiler may > >> accept some cflags for compiling but not for linking, so if > >> we check first > >> for the cflags it will succeed, and the cflags will be added > >> to the CFLAGS > >> variable despite of the check_ldflags failing after that. > >> This can cause > >> problems because of having multiple incompatible cflags > >> enabled at the same > >> time. > >>- Check if mipsfpu has been disabled, and if so, then use > >> -msoft-float. This > >> way we override the compiler default behavious which can be > >> building for > >> hard-float. > >>- Explicitly disable the features that fail any check by adding > >> "|| disable > >> $feature" at the end of the checks chain. > >> > >> Changes v4 -> v5: > >> - Check for msa.h and disable msa if not found. > >> > >> Changes v3 -> v4: > >> - Nothing. > >> > >> Changes v2 -> v3: > >> - Nothing. > >> > >> Changes v1 -> v2: > >> - Add a block of code for mipsdspr2 which was previously placed > >> in the > >>first patch of this series causing a syntax error in the > >> configure > >>script. > >> > >> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html > > > > make distclean ; ../configure > > --cross-prefix=/usr/mips-linux-gnu/bin/ --cc='ccache > > mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux > > --enable-cross-compile --disable-mipsfpu && make -j12 > > results in pages of: > > > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libswresample/libswresample.a(dither.o) uses soft float > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libswresample/libswresample.a(resample.o) uses soft float > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libswresample/libswresample.a(resample_dsp.o) uses soft float > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libavutil/libavutil.a(adler32.o) uses soft float > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libavutil/libavutil.a(aes.o) uses soft float > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libavutil/libavutil.a(aes_ctr.o) uses soft float > > /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: > > Warning: libavfilter/filtfmts-test uses hard float, > > libavutil/libavutil.a(audio_fifo.o) uses soft float > > > > > > [...] > > > > I can't reproduce your issue. Look: > > $ make distclean ; ./configure --cross-prefix=mips-linux-gnu- > --arch=mips --target-os=linux --enable-cross-compile > --disable-mipsfpu > > And then: > > $ make -j1 V=1 2>&1 | t
Re: [FFmpeg-devel] [PATCH] doc/demuxers: add some concat demuxer script examples
Le decadi 30 nivôse, an CCXXIV, Tobias Rapp a écrit : > Attached patch adds some example scripts for the concat demuxer to the > documentation. Well, I maintain the code, not really the documentation. > >From 5ffc11e8139476d18cd2eaa28338adb0dda80999 Mon Sep 17 00:00:00 2001 > From: Tobias Rapp > Date: Tue, 19 Jan 2016 15:42:33 +0100 > Subject: [PATCH] doc/demuxers: add some concat demuxer script examples > > Signed-off-by: Tobias Rapp > --- > doc/demuxers.texi | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/doc/demuxers.texi b/doc/demuxers.texi > index fb1e4fb..3900272 100644 > --- a/doc/demuxers.texi > +++ b/doc/demuxers.texi > @@ -214,6 +214,27 @@ The default is 0. > > @end table > > +@subsection Examples > + > +Example script which uses absolute filenames and includes some comments: I am not sure that "which" is the most idiomatic here, "that" sound better, but I am not a native speaker. > +@example > +# my first filename > +file /mnt/share/file-1.wav > +# my second filename including whitespace > +file '/mnt/share/file 2.wav' > +# my third filename including whitespace plus single quote > +file '/mnt/share/file 3'\''.wav' > +@end example > + > +Example script which allows for input format auto-probing, uses safe > filenames > +and sets the duration of the first file: > +@example > +ffconcat version 1.0 > +file file-1.wav > +duration 20.0 > +file 'file 2.wav' > +@end example > + > @section flv > > Adobe Flash Video Format demuxer. No objection apart from that. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
Hi, On Mon, Jan 25, 2016 at 4:01 AM, wm4 wrote: > On Sun, 24 Jan 2016 20:03:01 -0500 > "Ronald S. Bultje" wrote: > > > Hi, > > > > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes > > wrote: > > > > > Unfortunately that doesn't alleviate the other issues, like the > > > complexity needed in the decoders during frame threading, or the extra > > > resources needed (extra image surfaces for every thread). > > > > > > > So, the extra code is just in the decoders, which already need it anyway > > (because they implement frame-mt), right? Or do hwaccels need extra code > > also? > > > > The extra resources aren't a big deal IMO. Memory use isn't typically a > big > > issue, we're adding a fw kb extra for contexts but practically all memory > > is in framebuffers regardless. > > It's can be a big deal for hardware decoding, because hw surfaces > might be a more constrained resource than system RAM. Also, you often > have to preallocate _all_ surfaces you're going to use, so you'll have > to add the exact number of additionally needed surfaces to the > preallocation. If only one thread is active, the rest never has to be inited and thus contains no surfaces (or framebuffers, or anything), right? If not, that should be a trivial win. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/flvenc: copyts in FLV muxer
The purpose of this patch is to preserve timestamps when using ffmpeg for
publishing RTMP streams, e.g. ffmpeg -i rtmp://source/stream -f flv
rtmp://target/stream.
There is a setting "copyts" for that purpose. Unfortunately it doesn't work
with FLV muxer because it has its own timestamp correction which makes global
setting "copyts" ineffective.
This patch removes timestamp correction in FLV muxer. This means FLV will rely
on ffmpeg timestamp correction which makes it possible to use copyts.
---
libavformat/flvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 3925768..8fd5d29 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -562,7 +562,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
*pkt)
return AVERROR(EINVAL);
}
-ts = pkt->dts + flv->delay; // add delay to force positive dts
+ts = pkt->dts;
if (s->event_flags & AVSTREAM_EVENT_FLAG_METADATA_UPDATED) {
write_metadata(s, ts);
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH][WIP]: multithreaded audio frame encoding
Hi,
nonworking patch atttached.
From 5d5f16ec7a6f471401ce753ed88c63c47a8c3eba Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 25 Jan 2016 13:36:01 +0100
Subject: [PATCH] avcodec: multithread frame encoding
Signed-off-by: Paul B Mahol
---
libavcodec/flacenc.c | 2 +-
libavcodec/frame_thread_encoder.c | 14 +++---
libavcodec/frame_thread_encoder.h | 2 +-
libavcodec/utils.c| 10 +++---
4 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index c769833..773e34a 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -1483,7 +1483,7 @@ AVCodec ff_flac_encoder = {
.init = flac_encode_init,
.encode2= flac_encode_frame,
.close = flac_encode_close,
-.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_LOSSLESS,
+.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY | AV_CODEC_CAP_LOSSLESS | AV_CODEC_CAP_FRAME_THREADS,
.sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16,
AV_SAMPLE_FMT_S32,
AV_SAMPLE_FMT_NONE },
diff --git a/libavcodec/frame_thread_encoder.c b/libavcodec/frame_thread_encoder.c
index f4d35f9..d54e3de 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -83,7 +83,14 @@ static void * attribute_align_arg worker(void *v){
pthread_mutex_unlock(&c->task_fifo_mutex);
frame = task.indata;
-ret = avcodec_encode_video2(avctx, pkt, frame, &got_packet);
+switch (avctx->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+ret = avcodec_encode_audio2(avctx, pkt, frame, &got_packet);
+break;
+case AVMEDIA_TYPE_VIDEO:
+ret = avcodec_encode_video2(avctx, pkt, frame, &got_packet);
+break;
+}
pthread_mutex_lock(&c->buffer_mutex);
av_frame_unref(frame);
pthread_mutex_unlock(&c->buffer_mutex);
@@ -115,7 +122,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx, AVDictionary *options){
if( !(avctx->thread_type & FF_THREAD_FRAME)
- || !(avctx->codec->capabilities & AV_CODEC_CAP_INTRA_ONLY))
+ || (avctx->codec_type == AVMEDIA_TYPE_VIDEO &&
+!(avctx->codec->capabilities & AV_CODEC_CAP_INTRA_ONLY)))
return 0;
if( !avctx->thread_count
@@ -239,7 +247,7 @@ void ff_frame_thread_encoder_free(AVCodecContext *avctx){
av_freep(&avctx->internal->frame_thread_encoder);
}
-int ff_thread_video_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr){
+int ff_thread_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr){
ThreadContext *c = avctx->internal->frame_thread_encoder;
Task task;
int ret;
diff --git a/libavcodec/frame_thread_encoder.h b/libavcodec/frame_thread_encoder.h
index 1da0ce1..fdaaea5 100644
--- a/libavcodec/frame_thread_encoder.h
+++ b/libavcodec/frame_thread_encoder.h
@@ -22,5 +22,5 @@
int ff_frame_thread_encoder_init(AVCodecContext *avctx, AVDictionary *options);
void ff_frame_thread_encoder_free(AVCodecContext *avctx);
-int ff_thread_video_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr);
+int ff_thread_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index fb6c5f4..b00bf1e 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1704,6 +1704,10 @@ int attribute_align_arg avcodec_encode_audio2(AVCodecContext *avctx,
*got_packet_ptr = 0;
+if (CONFIG_FRAME_THREAD_ENCODER &&
+avctx->internal->frame_thread_encoder && (avctx->active_thread_type&FF_THREAD_FRAME))
+return ff_thread_encode_frame(avctx, avpkt, frame, got_packet_ptr);
+
if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY) && !frame) {
av_packet_unref(avpkt);
av_init_packet(avpkt);
@@ -1843,9 +1847,9 @@ int attribute_align_arg avcodec_encode_video2(AVCodecContext *avctx,
*got_packet_ptr = 0;
-if(CONFIG_FRAME_THREAD_ENCODER &&
- avctx->internal->frame_thread_encoder && (avctx->active_thread_type&FF_THREAD_FRAME))
-return ff_thread_video_encode_frame(avctx, avpkt, frame, got_packet_ptr);
+if (CONFIG_FRAME_THREAD_ENCODER &&
+avctx->internal->frame_thread_encoder && (avctx->active_thread_type&FF_THREAD_FRAME))
+return ff_thread_encode_frame(avctx, avpkt, frame, got_packet_ptr);
if ((avctx->flags&AV_CODEC_FLAG_PASS1) && avctx->stats_out)
avctx->stats_out[0] = '\0';
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
On Mon, Jan 25, 2016 at 12:34:03AM +, Kieran Kunhya wrote: > Decodes YUV 4:2:2 10-bit and RGB 12-bit files. > Older files with more subbands, skips, Bayer, alpha not supported. > Alpha requires addition of GBRAP12 pixel format. > --- > libavcodec/Makefile | 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/avcodec.h| 1 + > libavcodec/cfhd.c | 744 > > libavcodec/cfhd.h | 107 +++ > libavcodec/cfhddata.c | 327 + > libavcodec/codec_desc.c | 7 + > libavformat/riff.c | 1 + > 8 files changed, 1189 insertions(+) > create mode 100644 libavcodec/cfhd.c > create mode 100644 libavcodec/cfhd.h > create mode 100644 libavcodec/cfhddata.c breaks build for arm libavcodec/cfhd.c: In function ‘cfhd_decode’: libavcodec/cfhd.c:482:13: warning: ISO C90 forbids mixed declarations and code In file included from ffmpeg/libavutil/intmath.h:30:0, from ffmpeg/libavutil/common.h:103, from libavcodec/cfhd.c:27: ffmpeg/libavutil/arm/intmath.h: In function ‘filter’: ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ [...] -- 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
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
On 25 Jan 2016 2:29 p.m., "Michael Niedermayer" wrote: > > On Mon, Jan 25, 2016 at 12:34:03AM +, Kieran Kunhya wrote: > > Decodes YUV 4:2:2 10-bit and RGB 12-bit files. > > Older files with more subbands, skips, Bayer, alpha not supported. > > Alpha requires addition of GBRAP12 pixel format. > > --- > > libavcodec/Makefile | 1 + > > libavcodec/allcodecs.c | 1 + > > libavcodec/avcodec.h| 1 + > > libavcodec/cfhd.c | 744 > > libavcodec/cfhd.h | 107 +++ > > libavcodec/cfhddata.c | 327 + > > libavcodec/codec_desc.c | 7 + > > libavformat/riff.c | 1 + > > 8 files changed, 1189 insertions(+) > > create mode 100644 libavcodec/cfhd.c > > create mode 100644 libavcodec/cfhd.h > > create mode 100644 libavcodec/cfhddata.c > > breaks build for arm > > libavcodec/cfhd.c: In function ‘cfhd_decode’: > libavcodec/cfhd.c:482:13: warning: ISO C90 forbids mixed declarations and code > In file included from ffmpeg/libavutil/intmath.h:30:0, > from ffmpeg/libavutil/common.h:103, > from libavcodec/cfhd.c:27: > ffmpeg/libavutil/arm/intmath.h: In function ‘filter’: > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably doesn’t match constraints > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in ‘asm’ > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Looks like an existing bug, no? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
Hi, On Mon, Jan 25, 2016 at 9:34 AM, Kieran Kunhya wrote: > On 25 Jan 2016 2:29 p.m., "Michael Niedermayer" > wrote: > > > > On Mon, Jan 25, 2016 at 12:34:03AM +, Kieran Kunhya wrote: > > > Decodes YUV 4:2:2 10-bit and RGB 12-bit files. > > > Older files with more subbands, skips, Bayer, alpha not supported. > > > Alpha requires addition of GBRAP12 pixel format. > > > --- > > > libavcodec/Makefile | 1 + > > > libavcodec/allcodecs.c | 1 + > > > libavcodec/avcodec.h| 1 + > > > libavcodec/cfhd.c | 744 > > > > libavcodec/cfhd.h | 107 +++ > > > libavcodec/cfhddata.c | 327 + > > > libavcodec/codec_desc.c | 7 + > > > libavformat/riff.c | 1 + > > > 8 files changed, 1189 insertions(+) > > > create mode 100644 libavcodec/cfhd.c > > > create mode 100644 libavcodec/cfhd.h > > > create mode 100644 libavcodec/cfhddata.c > > > > breaks build for arm > > > > libavcodec/cfhd.c: In function ‘cfhd_decode’: > > libavcodec/cfhd.c:482:13: warning: ISO C90 forbids mixed declarations and > code > > In file included from ffmpeg/libavutil/intmath.h:30:0, > > from ffmpeg/libavutil/common.h:103, > > from libavcodec/cfhd.c:27: > > ffmpeg/libavutil/arm/intmath.h: In function ‘filter’: > > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably > doesn’t match constraints > > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably > doesn’t match constraints > > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably > doesn’t match constraints > > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably > doesn’t match constraints > > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably > doesn’t match constraints > > ffmpeg/libavutil/arm/intmath.h:77:5: warning: asm operand 2 probably > doesn’t match constraints > > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in > ‘asm’ > > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in > ‘asm’ > > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in > ‘asm’ > > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in > ‘asm’ > > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in > ‘asm’ > > ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in > ‘asm’ > > > > > > [...] > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Looks like an existing bug, no? av_clip_uintp2 requires an integer literal instead of a variable as input. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
Hi, On Sun, Jan 24, 2016 at 7:34 PM, Kieran Kunhya wrote: > +static inline void filter(int16_t *output, ptrdiff_t out_stride, int16_t > *low, ptrdiff_t low_stride, > + int16_t *high, ptrdiff_t high_stride, int len, > uint8_t clip) Should this be a DSP function? (That is, the functions calling this.) They seem very SIMD'able. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje wrote: > Hi, > > On Mon, Jan 25, 2016 at 4:01 AM, wm4 wrote: > >> On Sun, 24 Jan 2016 20:03:01 -0500 >> "Ronald S. Bultje" wrote: >> >> > Hi, >> > >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes >> > wrote: >> >> >> > > Unfortunately that doesn't alleviate the other issues, like the >> > > complexity needed in the decoders during frame threading, or the extra >> > > resources needed (extra image surfaces for every thread). >> > > >> > >> > So, the extra code is just in the decoders, which already need it anyway >> > (because they implement frame-mt), right? Or do hwaccels need extra code >> > also? >> > >> > The extra resources aren't a big deal IMO. Memory use isn't typically a >> big >> > issue, we're adding a fw kb extra for contexts but practically all memory >> > is in framebuffers regardless. >> >> It's can be a big deal for hardware decoding, because hw surfaces >> might be a more constrained resource than system RAM. Also, you often >> have to preallocate _all_ surfaces you're going to use, so you'll have >> to add the exact number of additionally needed surfaces to the >> preallocation. > > > If only one thread is active, the rest never has to be inited and thus > contains no surfaces (or framebuffers, or anything), right? If not, that > should be a trivial win. > If you can implement it like this, ie. only make one single thread do the work, that would also avoid a bunch of the complexity with copying contexts around and avoiding multiple init calls of the hwaccel. On top of that, avoid the extra resource requirements and the delay inherent to frame threading otherwise, since no extra frames are "cached" inside the other worker threads. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCHv3] avcodec: Cineform HD Decoder
On Sun, Jan 24, 2016 at 7:34 PM, Kieran Kunhya wrote:
> Decodes YUV 4:2:2 10-bit and RGB 12-bit files.
> Older files with more subbands, skips, Bayer, alpha not supported.
> Alpha requires addition of GBRAP12 pixel format.
Actually you could set AV_PIX_FMT_GBRAP16 and tweak the
bits_per_raw_sample, not sure about the repercussion on the users
though.
> ---
> +static av_cold int cfhd_decode_init(AVCodecContext *avctx)
is this function _decode or _init? or is it decoder_init? imho names
would be simpler with just _ scheme.
> +{
> +CFHDContext *s = avctx->priv_data;
> +
> +avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
if the decoder supports multiple pixel formats it's better not to
initialize the pixel format here, and wait until decode(). Otherwise
it's going to cause a "parameters changed" warning and reinit any
previous filter chain.
> +avctx->bits_per_raw_sample = 10;
> +s->avctx = avctx;
> +avctx->width = 0;
> +avctx->height = 0;
isn't the context mallocz anyway?
> +return ff_cfhd_init_vlcs(s);
> +}
> +
> +static inline void filter(int16_t *output, ptrdiff_t out_stride, int16_t
> *low, ptrdiff_t low_stride,
> + int16_t *high, ptrdiff_t high_stride, int len,
> uint8_t clip)
> +{
> +int16_t tmp;
> +
> +int i;
> +for (i = 0; i < len; i++) {
> +if (i == 0) {
> +tmp = (11*low[0*low_stride] - 4*low[1*low_stride] +
> low[2*low_stride] + 4) >> 3;
> +output[(2*i+0)*out_stride] = (tmp + high[0*high_stride]) >> 1;
> +if (clip)
> +output[(2*i+0)*out_stride] =
> av_clip_uintp2(output[(2*i+0)*out_stride], clip);
> +
> +tmp = ( 5*low[0*low_stride] + 4*low[1*low_stride] -
> low[2*low_stride] + 4) >> 3;
> +output[(2*i+1)*out_stride] = (tmp - high[0*high_stride]) >> 1;
> +if (clip)
> +output[(2*i+1)*out_stride] =
> av_clip_uintp2(output[(2*i+1)*out_stride], clip);
> +}
> +else if (i == len-1){
nit, spacing and new line are still off
> +tmp = ( 5*low[i*low_stride] + 4*low[(i-1)*low_stride] -
> low[(i-2)*low_stride] + 4) >> 3;
> +output[(2*i+0)*out_stride] = (tmp + high[i*high_stride]) >> 1;
> +if (clip)
> +output[(2*i+0)*out_stride] =
> av_clip_uintp2(output[(2*i+0)*out_stride], clip);
> +
> +tmp = (11*low[i*low_stride] - 4*low[(i-1)*low_stride] +
> low[(i-2)*low_stride] + 4) >> 3;
> +output[(2*i+1)*out_stride] = (tmp - high[i*high_stride]) >> 1;
> +if (clip)
> +output[(2*i+1)*out_stride] =
> av_clip_uintp2(output[(2*i+1)*out_stride], clip);
> +}
> +else {
> +tmp = (low[(i-1)*low_stride] - low[(i+1)*low_stride] + 4) >> 3;
> +output[(2*i+0)*out_stride] = (tmp + low[i*low_stride] +
> high[i*high_stride]) >> 1;
> +if (clip)
> +output[(2*i+0)*out_stride] =
> av_clip_uintp2(output[(2*i+0)*out_stride], clip);
> +
> +tmp = (low[(i+1)*low_stride] - low[(i-1)*low_stride] + 4) >> 3;
> +output[(2*i+1)*out_stride] = (tmp + low[i*low_stride] -
> high[i*high_stride]) >> 1;
> +if (clip)
> +output[(2*i+1)*out_stride] =
> av_clip_uintp2(output[(2*i+1)*out_stride], clip);
> +}
> +}
> +}
+1 on the dsp suggestion
> +}
> +
> +static int alloc_buffers(AVCodecContext *avctx)
> +{
> +CFHDContext *s = avctx->priv_data;
> +int i, j, k;
> +
> +avctx->width = s->coded_width;
> +avctx->height = s->coded_height;
I think ff_set_dimensions is the function you're looking for (make
sure to check its return value)
> +avcodec_get_chroma_sub_sample(avctx->pix_fmt, &s->chroma_x_shift,
> &s->chroma_y_shift);
this again? :)
> +for (i = 0; i < 3; i++) {
> +int width = i ? avctx->width >> s->chroma_x_shift : avctx->width;
> +int height = i ? avctx->height >> s->chroma_y_shift : avctx->height;
could these be candidates for AV_CEIL_RSHIFT?
> +int stride = FFALIGN(width / 8, 8) * 8;
> +int w8, h8, w4, h4, w2, h2;
> +height = FFALIGN(height / 8, 2) * 8;
> +s->plane[i].width = width;
> +s->plane[i].height = height;
> +s->plane[i].stride = stride;
> +
> +w8 = FFALIGN(s->plane[i].width / 8, 8);
> +h8 = FFALIGN(s->plane[i].height / 8, 2);
> +w4 = w8 * 2;
> +h4 = h8 * 2;
> +w2 = w4 * 2;
> +h2 = h4 * 2;
> +
> +s->plane[i].idwt_buf = av_malloc(height * stride *
> sizeof(*s->plane[i].idwt_buf));
> +s->plane[i].idwt_tmp = av_malloc(height * stride *
> sizeof(*s->plane[i].idwt_tmp));
> +if (!s->plane[i].idwt_buf || !s->plane[i].idwt_tmp) {
> +return AVERROR(ENOMEM);
need to av_freep both since you don't know which one failed
> +}
> +av_log(avctx, AV_LOG_DEBUG, "Start subband coef
[FFmpeg-devel] [PATCH v2] lavc/rawdec: Use 16-byte line alignment for AV_PIX_FMT_MONOWHITE
16-byte, not 16-bit.
>From 950fe2cd5da4b56feb2bd0e74173cd1c2c223df5 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Mon, 25 Jan 2016 13:02:52 +0100
Subject: [PATCH v2] lavc/rawdec: Use 16-byte line alignment for AV_PIX_FMT_MONOWHITE
The line alignment for 1 bpp raw AV_PIX_FMT_MONOWHITE video (currently
used for AVI) was previously 4 bytes, which generated alignment warning
messages, not only for odd-width files. The alignment is now 16 bytes.
---
libavcodec/rawdec.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 87cda32..3536943 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -41,7 +41,7 @@ typedef struct RawVideoContext {
AVBufferRef *palette;
int frame_size; /* size of the frame in bytes */
int flip;
-int is_1_2_4_8_bpp; // 1 bpp in mov, and 2, 4 and 8 bpp in avi/mov
+int is_1_2_4_8_bpp; // 1, 2, 4 and 8 bpp in avi/mov
int is_yuv2;
int is_lt_16bpp; // 16bpp pixfmt and bits_per_coded_sample < 16
int tff;
@@ -176,12 +176,18 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
|| avctx->bits_per_coded_sample == 2 || avctx->bits_per_coded_sample == 1) &&
-avctx->pix_fmt == AV_PIX_FMT_PAL8 &&
- (!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
+(avctx->pix_fmt == AV_PIX_FMT_PAL8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) &&
+(!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
context->is_1_2_4_8_bpp = 1;
-context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
- FFALIGN(avctx->width, 16),
- avctx->height, 1);
+if (avctx->bits_per_coded_sample == 1 && avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
+int row_bytes = avctx->width / 8 + (avctx->width & 7 ? 1 : 0);
+context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
+ FFALIGN(row_bytes, 16) * 8,
+ avctx->height, 1);
+} else
+context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
+ FFALIGN(avctx->width, 16),
+ avctx->height, 1);
} else {
context->is_lt_16bpp = av_get_bits_per_pixel(desc) == 16 && avctx->bits_per_coded_sample && avctx->bits_per_coded_sample < 16;
context->frame_size = av_image_get_buffer_size(avctx->pix_fmt, avctx->width,
@@ -217,16 +223,18 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if (!frame->buf[0])
return AVERROR(ENOMEM);
-// 1 bpp in mov, and 2, 4 and 8 bpp in avi/mov
+// 1, 2, 4 and 8 bpp in avi/mov
if (context->is_1_2_4_8_bpp) {
int i, j, row_pix = 0;
uint8_t *dst = frame->buf[0]->data;
-buf_size = context->frame_size - AVPALETTE_SIZE;
-if (avctx->bits_per_coded_sample == 8) {
+buf_size = context->frame_size -
+(avctx->pix_fmt == AV_PIX_FMT_PAL8 ? AVPALETTE_SIZE : 0);
+if (avctx->bits_per_coded_sample == 8 || avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
+int pix_per_byte = avctx->pix_fmt == AV_PIX_FMT_MONOWHITE ? 8 : 1;
for (i = 0, j = 0; j < buf_size && isize; i++, j++) {
dst[j] = buf[i];
-row_pix++;
-if (row_pix == avctx->width) {
+row_pix += pix_per_byte;
+if (row_pix >= avctx->width) {
i += avpkt_stride - (i % avpkt_stride) - 1;
j += 16 - (j % 16) - 1;
row_pix = 0;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP]: multithreaded audio frame encoding
On 1/25/16, Paul B Mahol wrote:
> Hi,
>
> nonworking patch atttached.
>
Working patch attached.
From 1e6ed69925ff05a934b2fe68830512246e616367 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 25 Jan 2016 18:39:23 +0100
Subject: [PATCH] avcodec: multithread audio frame encoding for wavpack and
alac
Signed-off-by: Paul B Mahol
---
libavcodec/alacenc.c | 2 +-
libavcodec/frame_thread_encoder.c | 14 +++---
libavcodec/frame_thread_encoder.h | 2 +-
libavcodec/utils.c| 14 ++
libavcodec/wavpackenc.c | 8
5 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index a87c373..7ada570 100644
--- a/libavcodec/alacenc.c
+++ b/libavcodec/alacenc.c
@@ -653,7 +653,7 @@ AVCodec ff_alac_encoder = {
.init = alac_encode_init,
.encode2= alac_encode_frame,
.close = alac_encode_close,
-.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME,
+.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_FRAME_THREADS,
.channel_layouts = ff_alac_channel_layouts,
.sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S32P,
AV_SAMPLE_FMT_S16P,
diff --git a/libavcodec/frame_thread_encoder.c b/libavcodec/frame_thread_encoder.c
index f4d35f9..d54e3de 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -83,7 +83,14 @@ static void * attribute_align_arg worker(void *v){
pthread_mutex_unlock(&c->task_fifo_mutex);
frame = task.indata;
-ret = avcodec_encode_video2(avctx, pkt, frame, &got_packet);
+switch (avctx->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+ret = avcodec_encode_audio2(avctx, pkt, frame, &got_packet);
+break;
+case AVMEDIA_TYPE_VIDEO:
+ret = avcodec_encode_video2(avctx, pkt, frame, &got_packet);
+break;
+}
pthread_mutex_lock(&c->buffer_mutex);
av_frame_unref(frame);
pthread_mutex_unlock(&c->buffer_mutex);
@@ -115,7 +122,8 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx, AVDictionary *options){
if( !(avctx->thread_type & FF_THREAD_FRAME)
- || !(avctx->codec->capabilities & AV_CODEC_CAP_INTRA_ONLY))
+ || (avctx->codec_type == AVMEDIA_TYPE_VIDEO &&
+!(avctx->codec->capabilities & AV_CODEC_CAP_INTRA_ONLY)))
return 0;
if( !avctx->thread_count
@@ -239,7 +247,7 @@ void ff_frame_thread_encoder_free(AVCodecContext *avctx){
av_freep(&avctx->internal->frame_thread_encoder);
}
-int ff_thread_video_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr){
+int ff_thread_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr){
ThreadContext *c = avctx->internal->frame_thread_encoder;
Task task;
int ret;
diff --git a/libavcodec/frame_thread_encoder.h b/libavcodec/frame_thread_encoder.h
index 1da0ce1..fdaaea5 100644
--- a/libavcodec/frame_thread_encoder.h
+++ b/libavcodec/frame_thread_encoder.h
@@ -22,5 +22,5 @@
int ff_frame_thread_encoder_init(AVCodecContext *avctx, AVDictionary *options);
void ff_frame_thread_encoder_free(AVCodecContext *avctx);
-int ff_thread_video_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr);
+int ff_thread_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *frame, int *got_packet_ptr);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index abddd6f..ea73e8a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1317,7 +1317,9 @@ int attribute_align_arg avcodec_open2(AVCodecContext *avctx, const AVCodec *code
if (!HAVE_THREADS)
av_log(avctx, AV_LOG_WARNING, "Warning: not compiled with thread support, using thread emulation\n");
-if (CONFIG_FRAME_THREAD_ENCODER && av_codec_is_encoder(avctx->codec)) {
+if (CONFIG_FRAME_THREAD_ENCODER && av_codec_is_encoder(avctx->codec) && (avctx->codec_type == AVMEDIA_TYPE_VIDEO ||
+ (avctx->codec_type == AVMEDIA_TYPE_AUDIO &&
+ (avctx->codec->capabilities & AV_CODEC_CAP_FRAME_THREADS {
ff_unlock_avcodec(codec); //we will instanciate a few encoders thus kick the counter to prevent false detection of a problem
ret = ff_frame_thread_encoder_init(avctx, options ? *options : NULL);
ff_lock_avcodec(avctx, codec);
@@ -1704,6 +1706,10 @@ int attribute_align_arg avcodec_encode_audio2(AVCodecContext *avctx,
*got_packet_ptr = 0;
+if (CONFIG_FRAME_THREAD_ENCODER &&
+avctx->internal->frame_thread_encoder && (avctx->active_thread_type&FF_THREAD_FRAME))
+return ff_thread_encode_frame(avctx, avpkt, frame, got_packet_ptr);
Re: [FFmpeg-devel] [PATCH] avcodec: split off synth_filter
On 1/24/2016 6:48 PM, James Almer wrote: > On 1/24/2016 6:41 PM, Hendrik Leppkes wrote: >> On Sun, Jan 24, 2016 at 9:53 PM, James Almer wrote: >>> Signed-off-by: James Almer >>> --- >>> This should make replacing the current dca decoder for foo86's easier, >>> without >>> having to disable/reenable the compilation of synth_filter files in between >>> removal/addition commits. >>> >> >> While it would make the migration easier, the synth filter is purely >> a dca concept, is it not? Would it have any chance of being useful for >> anything else ever again? >> If the answer is no, spinning it out seems like a bit of overkill, but >> if you think its useful I won't object to it either way. > > It wouldn't be the first. See iirfilter and how it's used by aac_encoder > only, or tpeldsp and svq3_decoder. > > The context, the functions and most of the files were already separated > from dca, so it's IMO cleaner to have it this way. Applied it without making it a separate "component". Less useful but still cleaner, especially on x86. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP]: multithreaded audio frame encoding
On Mon, Jan 25, 2016 at 06:47:57PM +0100, Paul B Mahol wrote: > On 1/25/16, Paul B Mahol wrote: > > Hi, > > > > nonworking patch atttached. > > > > Working patch attached. > alacenc.c |2 +- > frame_thread_encoder.c | 14 +++--- > frame_thread_encoder.h |2 +- > utils.c| 14 ++ > wavpackenc.c |8 is it intended that wavpack encoding differ with threads ? it seems they are smaller so nothing wrong, just unexpected ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -flags +bitexact -fflags +bitexact -t 30 new.wv ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -flags +bitexact -fflags +bitexact -t 30 -threads 1 -thread_type 0 old.wv md5sum old.wv new.wv 4979304cc5b1149ebddc2a4c5c94aef7 old.wv f9a6cd192ace7ec69496096cd3bd1796 new.wv -rw-r- 1 michael michael 2177102 Jan 25 19:16 new.wv -rw-r- 1 michael michael 2199058 Jan 25 19:17 old.wv ./ffmpeg -i new.wv -f crc - ./ffmpeg -i old.wv -f crc - CRC=0x30bad4dd CRC=0x30bad4dd [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Fix multi program so that it supports adding the same stream to multiple programs.
On Sun, Jan 24, 2016 at 03:54:34PM +0100, Vittorio Gambaletta (VittGam) wrote:
> Hi,
>
> On 24/01/2016 12:01:38 CET, Michael Niedermayer wrote:
> >On Sun, Jan 24, 2016 at 06:06:36AM +0100, Vittorio Gambaletta (VittGam)
> >wrote:
> >>Signed-off-by: Vittorio Gambaletta
> >>---
> >> libavformat/mpegtsenc.c | 15 +--
> >> 1 file changed, 13 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> >>index 2c12043..a20e229 100644
> >>--- a/libavformat/mpegtsenc.c
> >>+++ b/libavformat/mpegtsenc.c
> >>@@ -275,8 +275,19 @@ static int mpegts_write_pmt(AVFormatContext *s,
> >>MpegTSService *service)
> >> AVDictionaryEntry *lang = av_dict_get(st->metadata, "language",
> >> NULL, 0);
> >>
> >> if (s->nb_programs) {
> >>-AVProgram *program = av_find_program_from_stream(s, NULL, i);
> >>-if (program->id != service->sid)
> >>+int j, k, found = 0;
> >>+
> >>+for (j = 0; j < s->nb_programs; j++)
> >>+if (s->programs[j]->id == service->sid) {
> >>+for (k = 0; k < s->programs[j]->nb_stream_indexes; k++)
> >>+if (s->programs[j]->stream_index[k] == i) {
> >>+found = 1;
> >>+break;
> >>+}
> >>+break;
> >>+}
> >
> >av_find_program_from_stream() should be run in a loop to enumerate
> >the programs, see other uses of av_find_program_from_stream()
>
> Wouldn't this solve the problem backwards?
yes, though it would avoid directly accessing the data structs.
no big problem really though, i see the av_find_program_from_stream()
isnt exactly optimal here
so applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have often repented speaking, but never of holding my tongue.
-- Xenocrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/imdct36: use extractps inside the STORE macro
Signed-off-by: James Almer --- libavcodec/x86/imdct36.asm | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavcodec/x86/imdct36.asm b/libavcodec/x86/imdct36.asm index 7218f06..fcf007b 100644 --- a/libavcodec/x86/imdct36.asm +++ b/libavcodec/x86/imdct36.asm @@ -143,6 +143,12 @@ SECTION .text %endmacro %macro STORE 4 +%if cpuflag(sse4) +extractps [%3 ], %1, 0 +extractps [%3 + %4], %1, 1 +extractps [%3 + 2*%4], %1, 2 +extractps [%3 + 3*%4], %1, 3 +%else movhlps %2, %1 movss [%3 ], %1 movss [%3 + 2*%4], %2 @@ -150,6 +156,7 @@ SECTION .text movss [%3 + %4], %1 movhlps %2, %1 movss [%3 + 3*%4], %2 +%endif %endmacro %macro LOAD 4 -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavc/rawdec: Use 16-byte line alignment for AV_PIX_FMT_MONOWHITE
On Mon, Jan 25, 2016 at 06:09:18PM +0100, Mats Peterson wrote: > 16-byte, not 16-bit. > rawdec.c | 30 +++--- > 1 file changed, 19 insertions(+), 11 deletions(-) > 9c1e9ec71fe79221522dabf321143e4bbce483f7 0001-v2.patch > From 950fe2cd5da4b56feb2bd0e74173cd1c2c223df5 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Mon, 25 Jan 2016 13:02:52 +0100 > Subject: [PATCH v2] lavc/rawdec: Use 16-byte line alignment for > AV_PIX_FMT_MONOWHITE > > The line alignment for 1 bpp raw AV_PIX_FMT_MONOWHITE video (currently > used for AVI) was previously 4 bytes, which generated alignment warning > messages, not only for odd-width files. The alignment is now 16 bytes. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP]: multithreaded audio frame encoding
On 1/25/16, Michael Niedermayer wrote: > On Mon, Jan 25, 2016 at 06:47:57PM +0100, Paul B Mahol wrote: >> On 1/25/16, Paul B Mahol wrote: >> > Hi, >> > >> > nonworking patch atttached. >> > >> >> Working patch attached. > >> alacenc.c |2 +- >> frame_thread_encoder.c | 14 +++--- >> frame_thread_encoder.h |2 +- >> utils.c| 14 ++ >> wavpackenc.c |8 > > is it intended that wavpack encoding differ with threads ? It looks like somewhere something is cached by encoder. > it seems they are smaller so nothing wrong, just unexpected It is "random", can be bigger too. > > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -flags +bitexact -fflags > +bitexact -t 30 new.wv > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -flags +bitexact -fflags > +bitexact -t 30 -threads 1 -thread_type 0 old.wv > md5sum old.wv new.wv > 4979304cc5b1149ebddc2a4c5c94aef7 old.wv > f9a6cd192ace7ec69496096cd3bd1796 new.wv > -rw-r- 1 michael michael 2177102 Jan 25 19:16 new.wv > -rw-r- 1 michael michael 2199058 Jan 25 19:17 old.wv > > ./ffmpeg -i new.wv -f crc - > ./ffmpeg -i old.wv -f crc - > CRC=0x30bad4dd > CRC=0x30bad4dd > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I do not agree with what you have to say, but I'll defend to the death your > right to say it. -- Voltaire > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/flvenc: copyts in FLV muxer
On Mon, Jan 25, 2016 at 02:43:40PM +0200, Ivan wrote: > The purpose of this patch is to preserve timestamps when using ffmpeg for > publishing RTMP streams, e.g. ffmpeg -i rtmp://source/stream -f flv > rtmp://target/stream. > There is a setting "copyts" for that purpose. Unfortunately it doesn't work > with FLV muxer because it has its own timestamp correction which makes global > setting "copyts" ineffective. > > This patch removes timestamp correction in FLV muxer. This means FLV will > rely on ffmpeg timestamp correction which makes it possible to use copyts. indeed, avoid_negative_ts should handle this i intend to apply this, unless someone sees a case for which this code is still needed ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Mon, Jan 25, 2016 at 04:39:49PM +0100, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Mon, Jan 25, 2016 at 4:01 AM, wm4 wrote: > > > >> On Sun, 24 Jan 2016 20:03:01 -0500 > >> "Ronald S. Bultje" wrote: > >> > >> > Hi, > >> > > >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes > >> > wrote: > >> > >> > >> > > Unfortunately that doesn't alleviate the other issues, like the > >> > > complexity needed in the decoders during frame threading, or the extra > >> > > resources needed (extra image surfaces for every thread). > >> > > > >> > > >> > So, the extra code is just in the decoders, which already need it anyway > >> > (because they implement frame-mt), right? Or do hwaccels need extra code > >> > also? > >> > > >> > The extra resources aren't a big deal IMO. Memory use isn't typically a > >> big > >> > issue, we're adding a fw kb extra for contexts but practically all memory > >> > is in framebuffers regardless. > >> > >> It's can be a big deal for hardware decoding, because hw surfaces > >> might be a more constrained resource than system RAM. Also, you often > >> have to preallocate _all_ surfaces you're going to use, so you'll have > >> to add the exact number of additionally needed surfaces to the > >> preallocation. > > > > > > If only one thread is active, the rest never has to be inited and thus > > contains no surfaces (or framebuffers, or anything), right? If not, that > > should be a trivial win. > > > > If you can implement it like this, ie. only make one single thread do > the work, that would also avoid a bunch of the complexity with copying > contexts around and avoiding multiple init calls of the hwaccel. > On top of that, avoid the extra resource requirements and the delay > inherent to frame threading otherwise, since no extra frames are > "cached" inside the other worker threads. is there no hwaccel that (can) work(s) with MT ? iam bringing that up here before code is unconditionally removed that might be needed for such case [] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Mon, Jan 25, 2016 at 7:50 PM, Michael Niedermayer wrote: > On Mon, Jan 25, 2016 at 04:39:49PM +0100, Hendrik Leppkes wrote: >> On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje wrote: >> > Hi, >> > >> > On Mon, Jan 25, 2016 at 4:01 AM, wm4 wrote: >> > >> >> On Sun, 24 Jan 2016 20:03:01 -0500 >> >> "Ronald S. Bultje" wrote: >> >> >> >> > Hi, >> >> > >> >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes >> >> > wrote: >> >> >> >> >> >> > > Unfortunately that doesn't alleviate the other issues, like the >> >> > > complexity needed in the decoders during frame threading, or the extra >> >> > > resources needed (extra image surfaces for every thread). >> >> > > >> >> > >> >> > So, the extra code is just in the decoders, which already need it anyway >> >> > (because they implement frame-mt), right? Or do hwaccels need extra code >> >> > also? >> >> > >> >> > The extra resources aren't a big deal IMO. Memory use isn't typically a >> >> big >> >> > issue, we're adding a fw kb extra for contexts but practically all >> >> > memory >> >> > is in framebuffers regardless. >> >> >> >> It's can be a big deal for hardware decoding, because hw surfaces >> >> might be a more constrained resource than system RAM. Also, you often >> >> have to preallocate _all_ surfaces you're going to use, so you'll have >> >> to add the exact number of additionally needed surfaces to the >> >> preallocation. >> > >> > >> > If only one thread is active, the rest never has to be inited and thus >> > contains no surfaces (or framebuffers, or anything), right? If not, that >> > should be a trivial win. >> > >> >> If you can implement it like this, ie. only make one single thread do >> the work, that would also avoid a bunch of the complexity with copying >> contexts around and avoiding multiple init calls of the hwaccel. >> On top of that, avoid the extra resource requirements and the delay >> inherent to frame threading otherwise, since no extra frames are >> "cached" inside the other worker threads. > > is there no hwaccel that (can) work(s) with MT ? > iam bringing that up here before code is unconditionally removed that > might be needed for such case > Like I explained in an earlier post above, hwaccels don't MT, they execute async on a worker thread, but never more than one at the same time. The only reason someone might potentially see any speed up from using hwaccel+MT is from the sheer lack of optimizations in ffmpeg_.c. Some very basic pipelining would give the same speed up, instead of forcing the hardware to sync every frame immediately as it is right now. Thats really all the MT case does today: It adds a "delay", that allows the hardware internally to work more in parallel, but you don't need MT to do that, you can just buffer 2-4 output frames before trying to process them and achieve the exact same speedup. This behavior was confirmed by an NVIDIA engineer some years ago - the hardware has several "stages", and for optimal performance you should keep multiple frames inside the hardware. The decode APIs don't allow this, so the GPU already returns you a frame while its still being decoded in a later stage - and once you try to access it, the GPU has to "sync" the frame and wait until its done. If you just buffer it for a bit (say a 2 frame ring buffer), this bottleneck goes away and all is fast. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
On 25.01.2016 11:01, Hendrik Leppkes wrote: > msys doesn't seem to like creating directory symlinks with ln -s, for > some reason it copies the folder instead, which is of course terribly > slow. There is a fast configure check, which I added to prevent actually creating the link to the source directory, if it wouldn't be a real link, but a copy instead. Does that check not work for you? It works here: After replacing '$ln_s "$link_dest" "$link_name"' with 'cp -r "$link_dest" "$link_name"' it doesn't create the src link and falls back to using the full path instead. > Could try to use the windows link creating function, but thats > probably too much trouble. That would be easy, if you can tell me which command that is and in which environment it should work. > If we already have a way to fallback to the "old way", maybe this > could be put under a OS conditional, ie. exclude msys/cygwin? That could be done, but I don't think it is necessary, as the current check should already be sufficient. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
On Mon, Jan 25, 2016 at 8:07 PM, Andreas Cadhalpun wrote: > On 25.01.2016 11:01, Hendrik Leppkes wrote: >> msys doesn't seem to like creating directory symlinks with ln -s, for >> some reason it copies the folder instead, which is of course terribly >> slow. > > There is a fast configure check, which I added to prevent actually > creating the link to the source directory, if it wouldn't be a real > link, but a copy instead. > Does that check not work for you? > It works here: After replacing '$ln_s "$link_dest" "$link_name"' > with 'cp -r "$link_dest" "$link_name"' it doesn't create the src > link and falls back to using the full path instead. It works fine now, I cleaned up my tree and re-applied the patch, who knows what happened before, possibly some changes from debugging left. I didn't check the code if you actually tried to handle such a case. Tried both normal in-tree and out-of-tree across drives, and it seems to run fine. Thanks. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
On Mon, Jan 25, 2016 at 08:01:02PM +0100, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 7:50 PM, Michael Niedermayer > wrote: > > On Mon, Jan 25, 2016 at 04:39:49PM +0100, Hendrik Leppkes wrote: > >> On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje > >> wrote: > >> > Hi, > >> > > >> > On Mon, Jan 25, 2016 at 4:01 AM, wm4 wrote: > >> > > >> >> On Sun, 24 Jan 2016 20:03:01 -0500 > >> >> "Ronald S. Bultje" wrote: > >> >> > >> >> > Hi, > >> >> > > >> >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes > >> >> > wrote: > >> >> > >> >> > >> >> > > Unfortunately that doesn't alleviate the other issues, like the > >> >> > > complexity needed in the decoders during frame threading, or the > >> >> > > extra > >> >> > > resources needed (extra image surfaces for every thread). > >> >> > > > >> >> > > >> >> > So, the extra code is just in the decoders, which already need it > >> >> > anyway > >> >> > (because they implement frame-mt), right? Or do hwaccels need extra > >> >> > code > >> >> > also? > >> >> > > >> >> > The extra resources aren't a big deal IMO. Memory use isn't typically > >> >> > a > >> >> big > >> >> > issue, we're adding a fw kb extra for contexts but practically all > >> >> > memory > >> >> > is in framebuffers regardless. > >> >> > >> >> It's can be a big deal for hardware decoding, because hw surfaces > >> >> might be a more constrained resource than system RAM. Also, you often > >> >> have to preallocate _all_ surfaces you're going to use, so you'll have > >> >> to add the exact number of additionally needed surfaces to the > >> >> preallocation. > >> > > >> > > >> > If only one thread is active, the rest never has to be inited and thus > >> > contains no surfaces (or framebuffers, or anything), right? If not, that > >> > should be a trivial win. > >> > > >> > >> If you can implement it like this, ie. only make one single thread do > >> the work, that would also avoid a bunch of the complexity with copying > >> contexts around and avoiding multiple init calls of the hwaccel. > >> On top of that, avoid the extra resource requirements and the delay > >> inherent to frame threading otherwise, since no extra frames are > >> "cached" inside the other worker threads. > > > > is there no hwaccel that (can) work(s) with MT ? > > iam bringing that up here before code is unconditionally removed that > > might be needed for such case > > > > Like I explained in an earlier post above, hwaccels don't MT, they > execute async on a worker thread, but never more than one at the same > time. > The only reason someone might potentially see any speed up from using > hwaccel+MT is from the sheer lack of optimizations in > ffmpeg_.c. Some very basic pipelining would give the same > speed up, instead of forcing the hardware to sync every frame > immediately as it is right now. > > Thats really all the MT case does today: It adds a "delay", that > allows the hardware internally to work more in parallel, but you don't > need MT to do that, you can just buffer 2-4 output frames before > trying to process them and achieve the exact same speedup. > This behavior was confirmed by an NVIDIA engineer some years ago - the > hardware has several "stages", and for optimal performance you should > keep multiple frames inside the hardware. The decode APIs don't allow > this, so the GPU already returns you a frame while its still being > decoded in a later stage - and once you try to access it, the GPU has > to "sync" the frame and wait until its done. If you just buffer it for > a bit (say a 2 frame ring buffer), this bottleneck goes away and all > is fast. ok thanks for explaining [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Fix multi program so that it supports adding the same stream to multiple programs.
Hi,
On 25/01/2016 19:35:58 CET, Michael Niedermayer wrote:
On Sun, Jan 24, 2016 at 03:54:34PM +0100, Vittorio Gambaletta (VittGam) wrote:
Hi,
On 24/01/2016 12:01:38 CET, Michael Niedermayer wrote:
>On Sun, Jan 24, 2016 at 06:06:36AM +0100, Vittorio Gambaletta (VittGam) wrote:
>>Signed-off-by: Vittorio Gambaletta
>>---
>> libavformat/mpegtsenc.c | 15 +--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>>diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
>>index 2c12043..a20e229 100644
>>--- a/libavformat/mpegtsenc.c
>>+++ b/libavformat/mpegtsenc.c
>>@@ -275,8 +275,19 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
>> AVDictionaryEntry *lang = av_dict_get(st->metadata, "language",
NULL, 0);
>>
>> if (s->nb_programs) {
>>-AVProgram *program = av_find_program_from_stream(s, NULL, i);
>>-if (program->id != service->sid)
>>+int j, k, found = 0;
>>+
>>+for (j = 0; j < s->nb_programs; j++)
>>+if (s->programs[j]->id == service->sid) {
>>+for (k = 0; k < s->programs[j]->nb_stream_indexes; k++)
>>+if (s->programs[j]->stream_index[k] == i) {
>>+found = 1;
>>+break;
>>+}
>>+break;
>>+}
>
>av_find_program_from_stream() should be run in a loop to enumerate
>the programs, see other uses of av_find_program_from_stream()
Wouldn't this solve the problem backwards?
yes, though it would avoid directly accessing the data structs.
no big problem really though, i see the av_find_program_from_stream()
isnt exactly optimal here
so applied
thanks
You're welcome!
Well, if the same logic needs to be reused somewhere else, it could
always be put in a new function, maybe av_check_stream_is_in_program().
Cheers,
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add streamselect and astreamselect filter
On Mon, Jan 25, 2016 at 11:12:33AM +0100, Paul B Mahol wrote: > On 1/21/16, Paul B Mahol wrote: > > Hi, > > patch attached. > > > > 2nd version attached. > doc/filters.texi | 23 ++ > libavfilter/Makefile |2 > libavfilter/allfilters.c |2 > libavfilter/f_streamselect.c | 341 > +++ > 4 files changed, 368 insertions(+) > a5293d8464fdbdd1431114e2a4969ef05bf30bf6 > 0001-avfilter-add-streamselect-and-astreamselect-filter.patch > From 1ec18cd004e227fae2e4f34654cdc02474a38b7d Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Mon, 18 Jan 2016 11:22:32 +0100 > Subject: [PATCH] avfilter: add streamselect and astreamselect filter > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Signed-off-by: Clément Bœsch > Signed-off-by: Paul B Mahol > --- > doc/filters.texi | 23 +++ > libavfilter/Makefile | 2 + > libavfilter/allfilters.c | 2 + > libavfilter/f_streamselect.c | 341 > +++ > 4 files changed, 368 insertions(+) > create mode 100644 libavfilter/f_streamselect.c no objections from me [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: fix make checkheaders in out-of-tree builds
On 25.01.2016 20:28, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 8:07 PM, Andreas Cadhalpun > wrote: >> On 25.01.2016 11:01, Hendrik Leppkes wrote: >>> msys doesn't seem to like creating directory symlinks with ln -s, for >>> some reason it copies the folder instead, which is of course terribly >>> slow. >> >> There is a fast configure check, which I added to prevent actually >> creating the link to the source directory, if it wouldn't be a real >> link, but a copy instead. >> Does that check not work for you? >> It works here: After replacing '$ln_s "$link_dest" "$link_name"' >> with 'cp -r "$link_dest" "$link_name"' it doesn't create the src >> link and falls back to using the full path instead. > > It works fine now, I cleaned up my tree and re-applied the patch, who > knows what happened before, possibly some changes from debugging left. > I didn't check the code if you actually tried to handle such a case. > Tried both normal in-tree and out-of-tree across drives, and it seems > to run fine. Thanks for testing, I pushed it now. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/opt: check for and handle errors in av_opt_set_dict2()
On Sun, Jan 24, 2016 at 03:42:46AM +0100, Michael Niedermayer wrote: > From: Michael Niedermayer > > Previously errors could result in random entries to be lost. > > Signed-off-by: Michael Niedermayer > --- > libavutil/opt.c |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/thp: implement seeking
On Sun, Nov 22, 2015 at 12:58:51AM +0100, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > libavformat/thp.c | 44 +--- > 1 file changed, 41 insertions(+), 3 deletions(-) confirmed to be working [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/thp: implement seeking
On 1/25/16, Michael Niedermayer wrote: > On Sun, Nov 22, 2015 at 12:58:51AM +0100, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> libavformat/thp.c | 44 +--- >> 1 file changed, 41 insertions(+), 3 deletions(-) > > confirmed to be working No, it doesnt always. AFAIK its not possible to fix. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add Ulead DV Audio decoder
Hi,
patch attached.
From 654a9d565d963eeb7c2e1c72559d0df17a9814ab Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 25 Jan 2016 21:54:17 +0100
Subject: [PATCH] avcodec: add Ulead DV audio decoder
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/dvaudiodec.c | 144
libavformat/riff.c | 2 +
4 files changed, 148 insertions(+)
create mode 100644 libavcodec/dvaudiodec.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 472c662..696f699 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -244,6 +244,7 @@ OBJS-$(CONFIG_DVBSUB_DECODER) += dvbsubdec.o
OBJS-$(CONFIG_DVBSUB_ENCODER) += dvbsub.o
OBJS-$(CONFIG_DVDSUB_DECODER) += dvdsubdec.o
OBJS-$(CONFIG_DVDSUB_ENCODER) += dvdsubenc.o
+OBJS-$(CONFIG_DVAUDIO_DECODER) += dvaudiodec.o
OBJS-$(CONFIG_DVVIDEO_DECODER) += dvdec.o dv.o dvdata.o
OBJS-$(CONFIG_DVVIDEO_ENCODER) += dvenc.o dv.o dvdata.o
OBJS-$(CONFIG_DXA_DECODER) += dxa.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2128546..66a57b0 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -160,6 +160,7 @@ void avcodec_register_all(void)
REGISTER_ENCDEC (DNXHD, dnxhd);
REGISTER_ENCDEC (DPX, dpx);
REGISTER_DECODER(DSICINVIDEO, dsicinvideo);
+REGISTER_DECODER(DVAUDIO, dvaudio);
REGISTER_ENCDEC (DVVIDEO, dvvideo);
REGISTER_DECODER(DXA, dxa);
REGISTER_DECODER(DXTORY,dxtory);
diff --git a/libavcodec/dvaudiodec.c b/libavcodec/dvaudiodec.c
new file mode 100644
index 000..84db509
--- /dev/null
+++ b/libavcodec/dvaudiodec.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2012 Laurent Aimar
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "internal.h"
+
+typedef struct DVAudioContext {
+int block_size;
+int is_12bit;
+int is_pal;
+int16_t shuffle[2000];
+} DVAudioContext;
+
+static av_cold int decode_init(AVCodecContext *avctx)
+{
+DVAudioContext *s = avctx->priv_data;
+int i;
+
+if (avctx->channels > 2) {
+av_log(avctx, AV_LOG_ERROR, "invalid number of channels\n");
+return AVERROR(EINVAL);
+}
+
+if (avctx->codec_tag == 0x0215) {
+s->block_size = 7200;
+s->is_pal = 0;
+} else if (avctx->codec_tag == 0x0216) {
+s->block_size = 8640;
+s->is_pal = 1;
+} else {
+return AVERROR(EINVAL);
+}
+
+s->is_12bit = avctx->bits_per_raw_sample == 12;
+avctx->sample_fmt = AV_SAMPLE_FMT_S16;
+
+for (i = 0; i < FF_ARRAY_ELEMS(s->shuffle); i++) {
+const unsigned a = s->is_pal ? 18 : 15;
+const unsigned b = 3 * a;
+
+s->shuffle[i] = 80 * ((21 * (i % 3) + 9 * (i / 3) + ((i / a) % 3)) % b) +
+ (2 + s->is_12bit) * (i / b) + 8;
+}
+
+return 0;
+}
+
+static inline int dv_get_audio_sample_count(const uint8_t *buffer, int dsf)
+{
+int samples = buffer[0] & 0x3f; /* samples in this frame - min samples */
+
+switch ((buffer[3] >> 3) & 0x07) {
+case 0:
+return samples + (dsf ? 1896 : 1580);
+case 1:
+return samples + (dsf ? 1742 : 1452);
+case 2:
+default:
+return samples + (dsf ? 1264 : 1053);
+}
+}
+
+static inline uint16_t dv_audio_12to16(uint16_t sample)
+{
+uint16_t shift, result;
+
+sample = (sample < 0x800) ? sample : sample | 0xf000;
+shift = (sample & 0xf00) >> 8;
+
+if (shift < 0x2 || shift > 0xd) {
+result = sample;
+} else if (shift < 0x8) {
+shift--;
+result = (sample - (256 * shift)) << shift;
+} else {
+shift = 0xe - shift;
+result = ((sample + ((256 * shift) + 1)) << shift) - 1;
+}
+
+return result;
+}
+
+static int decode_frame(AVCodecContext *avctx, void *data,
+int *got_frame_ptr, AVPacket *pkt)
+{
+DVAudioContext *s = avctx->priv_data;
+AVFrame *frame = data;
+const uint8_t *src = pkt->data;
+int16_t *dst;
+int ret, i;
+
+if (pkt->size != s->block
Re: [FFmpeg-devel] [PATCH v2] lavc/rawdec: Use 16-byte line alignment for AV_PIX_FMT_MONOWHITE
On 01/25/2016 07:42 PM, Michael Niedermayer wrote: The line alignment for 1 bpp raw AV_PIX_FMT_MONOWHITE video (currently used for AVI) was previously 4 bytes, which generated alignment warning messages, not only for odd-width files. The alignment is now 16 bytes. applied thanks Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavc/libzvbi-teletextdec: add support for setting background opacity
On Fri, 22 Jan 2016, Marton Balint wrote: Signed-off-by: Marton Balint --- doc/decoders.texi| 8 +++- libavcodec/libzvbi-teletextdec.c | 18 -- 2 files changed, 23 insertions(+), 3 deletions(-) Pushed the series with a micro bump. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.
On Fri, Jan 22, 2016 at 02:54:21PM -0800, Neil Birkbeck wrote: > Hmm. I don't have a good idea of how likely it is for this conversion to > float (by dividing a constant) to not be bit-exact on different > architectures (compilers?) when there should not be any other math > transforming the metadata (other than the conversion back to the integer > coding for cases like hevc, which for a given architecture is possible > without loss). The fact that this could happen at all does make it annoying > in terms of bit-exact test expectations across arch, and this is the main > concern, right? (for this type of metadata, it is really a hint to > TVs/algorithms, and some will ignore it altogether) bitexactness is one concern, also theres the issue with what is ideally correct. that is what are the ideal values dictated by various standards that hardware (cammeras, ...) aim at ? are these rational or float or what can represent them better ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/thp: implement seeking
On Mon, Jan 25, 2016 at 10:29:08PM +0100, Paul B Mahol wrote: > On 1/25/16, Michael Niedermayer wrote: > > On Sun, Nov 22, 2015 at 12:58:51AM +0100, Paul B Mahol wrote: > >> Signed-off-by: Paul B Mahol > >> --- > >> libavformat/thp.c | 44 +--- > >> 1 file changed, 41 insertions(+), 3 deletions(-) > > > > confirmed to be working > > No, it doesnt always. AFAIK its not possible to fix. it worked with the thp files i had locally :( where can i find a file with which it doesnt work ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.
On Mon, Jan 25, 2016 at 10:37 PM, Michael Niedermayer wrote: > On Fri, Jan 22, 2016 at 02:54:21PM -0800, Neil Birkbeck wrote: >> Hmm. I don't have a good idea of how likely it is for this conversion to >> float (by dividing a constant) to not be bit-exact on different >> architectures (compilers?) when there should not be any other math >> transforming the metadata (other than the conversion back to the integer >> coding for cases like hevc, which for a given architecture is possible >> without loss). The fact that this could happen at all does make it annoying >> in terms of bit-exact test expectations across arch, and this is the main >> concern, right? (for this type of metadata, it is really a hint to >> TVs/algorithms, and some will ignore it altogether) > > bitexactness is one concern, also theres the issue with what is ideally > correct. > that is what are the ideal values dictated by various standards > that hardware (cammeras, ...) aim at ? > are these rational or float or what can represent them better ? > Both HEVC and the HDMI Info Frames use fixed-point integers (the same scales too, apparently), I do not know of the formats anything else uses. Maybe we should be using AVRationals? I would argue that MKV storing floats is a terrible idea, and someone should bonk them over the head and store fixed point as well. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/thp: implement seeking
On 1/25/16, Michael Niedermayer wrote: > On Mon, Jan 25, 2016 at 10:29:08PM +0100, Paul B Mahol wrote: >> On 1/25/16, Michael Niedermayer wrote: >> > On Sun, Nov 22, 2015 at 12:58:51AM +0100, Paul B Mahol wrote: >> >> Signed-off-by: Paul B Mahol >> >> --- >> >> libavformat/thp.c | 44 +--- >> >> 1 file changed, 41 insertions(+), 3 deletions(-) >> > >> > confirmed to be working >> >> No, it doesnt always. AFAIK its not possible to fix. > > it worked with the thp files i had locally :( > where can i find a file with which it doesnt work ? https://www.dropbox.com/s/zr8034va0y6tfyy/KilllaKillOP.thp ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.
On Mon, Jan 25, 2016 at 1:13 PM, Michael Niedermayer wrote: > On Mon, Jan 25, 2016 at 10:24:36AM +, Carl Eugen Hoyos wrote: >> Kieran Kunhya kunhya.com> writes: >> >> > The internal encoder is superior to libvo-aacenc. >> >> I thought this was the case for several years? >> >> Needs a Changelog entry and a news entry together with >> libaacplus. > > how does the speed of all the aac encoders compare ? > we should keep the fastest and the one havng best quality per bit > (assuming thats a single one and not multiple due to different behavior > at different bitrates) > > also it may make sense to keep activly developed encoders so users and > develoeprs can continue to test/compare and use them in case they > improve > libvo-aacenc is a dump from an earlier Android build. Android has since switched to fdk-aac and libvo-aacenc is just dead. So from that perspective, there is definitely nothing lost. Can't judge the speed, but libvo-aacenc has the worst quality of all aac lc encoders we had, so I doubt anyone is going to miss it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat: add protocol_whitelist
On 24.01.2016 21:32, Nicolas George wrote: > Le quintidi 5 pluviôse, an CCXXIV, Andreas Cadhalpun a écrit : >> No. It would have prevented the issue with hls. > > Reacting to known attacks by ad-hoc hole-plugging is no way of building > proper security. The ad-hoc fix was the change done in the hls demuxer. The protocol_whitelist approach would prevent this class of issues, while being a rather simple mechanism that could be implemented in a backwards compatible way for almost all usecases. >> But it's usually only used with local files. > > I do not know that. Do you? I suspect it. For instance that's the example in the documentation. And it should less dangerous restricting the concat protocol to handling of local files by default. >> Why not? > > Because remote files can be more sensitive than local ones. It's not possible for libavformat to know what is sensitive and what not. But sending local files to remote is definitely problematic, when it happens unintentionally. Even just accessing a remote site when opening a local file can be considered a privacy breach. > Because some environment may download files, turning remote to local. I don't see how that is a problem. >> How? > > I do not know, Then you shouldn't have claimed it would be insecure. > but you can assume that someone knows and is selling that > information to the highest bidder. That can be said about any approach and it's not possible to prove it right or wrong. Thus stating this is completely pointless. > We know that playlists can be abused to leak information. Reimar was warning > about it years ago. People implemented them nonetheless, and guess what, it > did cause information leak. > > Now, your reaction is among the lines "the burglar left a footprint in front > of that window, let us wall it". Using this metaphor I would describe the situation differently: "The burglar knocked on the window and an unsuspecting person, let's call him Henry Louis Simplex, opened it for him. The quick fix for preventing this from happening again is to tell H.L.S. not to open that window. A better fix is to lock all windows so that people can only open windows they have a key for (i.e. which are on the whitelist)." > I say no, walling is overkill, and walling only that particular window is > useless. I don't know why you say 'walling', which would mean it's impossible to ever get through. However, with the right keys/whitelist one could still open any desired combination of windows/protocols. > We need to properly lock all the windows. That's exactly what the protocol_whitelist approach would do. You seem to be aiming for a complex mechanism of enforcing a security policy, which would require fundamental API changes. But there haven't been many details about how you envision the security policy, or how it could be implemented. Maybe you can add some more about this? In any case, the more complex a solution is, the more likely is it to contain bugs. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Avid DNxHR / UK DPP
Tomorrow I'm attending an event run by the Digital Production Partnership, a body that has brought together mainstream digital television delivery and workflow standards for UK broadcasters. My production company is a member, and we assisted a little in the development of their UHD workflow document. If you don't already have a line of communication open to them, I'm asking you if there is anything you would like mentioned to them about UHD codecs in FFmpeg e.g. DNxHR development and assistance in the process? J ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one
On Mon, Jan 25, 2016 at 2:57 AM, James Almer wrote: > On 1/22/2016 7:25 PM, Michael Niedermayer wrote: >> On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote: >>> Updated version of the patch. I choose to split it into even smaller >>> commits to >>> make reviewing easier; you may prefer to squash it as needed. >>> >>> Changes since the first version: >>> >>> * Removed checkasm test for dcadsp >>> * Removed FATE test for dca-xll (didn't check if this works) >>> * Core decoder now uses butterflies_fixed() for sumdiff decoding >>> * avpriv_request_sample() is now used for reporting missing features >>> * Core decoder now stays in fixed point mode during intermittent XLL >>> decoding errors >>> * X96 extension is no longer parsed (and left unused) when decoding XLL >>> * Minor code refactoring >>> >>> foo86 (16): >>> avcodec/dca: remove old decoder >>> avcodec/dca: remove unused assembly >>> avcodec/dca: remove unused data >>> tests/fate/audio: remove dca-xll test >>> tests/checkasm: remove dcadsp test >>> avcodec/dca: add REV1AUX sync word >>> avcodec/dca: add more tables >>> avcodec/dca: add math helpers and fixed point DCT >>> avcodec/synth_filter: fix whitespace >>> avcodec/synth_filter: add more filters >>> avcodec/dca: add DSP implementation >>> avcodec/dca: add generic defines >>> avcodec/dca: add core decoder >>> avcodec/dca: add EXSS parser >>> avcodec/dca: add XLL decoder >>> avcodec/dca: add new decoder based on libdcadec >> >> This breaks decoding >> https://trac.ffmpeg.org/raw-attachment/ticket/3550/WorstCase.wav >> didnt investgate what or why > > Foo86: When you fix this, if it's a trivial change to any of the patches you > sent then just resend that patch alone, not the full set. > That is, unless you're also making other changes, like disabling fate-dca, > fate-dts_es and any remaining reference to CONFIG_DCA_DECODER after patch 5. The decoder in itself looks fine to me, short of the regression michael found. If you could look at that, that would be great. I can squash and re-shuffle the commits appropriately for pushing and make sure all intermediate steps still build, so don't worry about that as much. I would love to get this in soon, we can do further improvements and more FATE coverage after. There doesn't seem to be much agreement yet of the order of pushing. I would argue that since we're replacing the decoder entirely anyway, a tiny period in between where we don't actually have a dca decoder wouldn't break any bisect flow, since it would probably end there anyway. So considering that, it feels cleaner to me to push the removal first, and then the additions for the new decoder for "prettier" history. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec: Remove libvo-aacenc support.
On Mon, Jan 25, 2016 at 11:21:11PM +0100, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 1:13 PM, Michael Niedermayer > wrote: > > On Mon, Jan 25, 2016 at 10:24:36AM +, Carl Eugen Hoyos wrote: > >> Kieran Kunhya kunhya.com> writes: > >> > >> > The internal encoder is superior to libvo-aacenc. > >> > >> I thought this was the case for several years? > >> > >> Needs a Changelog entry and a news entry together with > >> libaacplus. > > > > how does the speed of all the aac encoders compare ? > > we should keep the fastest and the one havng best quality per bit > > (assuming thats a single one and not multiple due to different behavior > > at different bitrates) > > > > also it may make sense to keep activly developed encoders so users and > > develoeprs can continue to test/compare and use them in case they > > improve > > > > > libvo-aacenc is a dump from an earlier Android build. Android has > since switched to fdk-aac and libvo-aacenc is just dead. > So from that perspective, there is definitely nothing lost. > > Can't judge the speed, but libvo-aacenc has the worst quality of all > aac lc encoders we had, so I doubt anyone is going to miss it. i didnt suggest to keep it, i mean it more in general [...] -- 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] [PATCH] vf_libopencv: add support for opencv 3
On 22.01.2016 00:44, Michael Niedermayer wrote: > On Thu, Jan 21, 2016 at 11:39:16PM +0100, Andreas Cadhalpun wrote: >> It dropped the old headers, but the replacements are already available >> with opencv 2. >> >> Signed-off-by: Andreas Cadhalpun >> --- >> >> Only tested compilation with opencv 2.4.9.1 and 3.0.0. > > builds here with 2.3.1-7 too > > cant comment further but i see nothing wrong in the patch Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Avid DNxHR / UK DPP
On Mon, Jan 25, 2016 at 10:41 PM, John Warburton wrote: > Tomorrow I'm attending an event run by the Digital Production Partnership, > a body that has brought together mainstream digital television delivery and > workflow standards for UK broadcasters. My production company is a member, > and we assisted a little in the development of their UHD workflow document. > > If you don't already have a line of communication open to them, I'm asking > you if there is anything you would like mentioned to them about UHD codecs > in FFmpeg e.g. DNxHR development and assistance in the process? If they are considering VC-5 (Cineform) basically point them to this: https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c tl;dr The VC-5 document isn't enough to implement things in the real-world (like many useless SMPTE documents). Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one
On Fri, Jan 22, 2016 at 11:25 PM, Michael Niedermayer wrote: > On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote: >> Updated version of the patch. I choose to split it into even smaller commits >> to >> make reviewing easier; you may prefer to squash it as needed. >> >> Changes since the first version: >> >> * Removed checkasm test for dcadsp >> * Removed FATE test for dca-xll (didn't check if this works) >> * Core decoder now uses butterflies_fixed() for sumdiff decoding >> * avpriv_request_sample() is now used for reporting missing features >> * Core decoder now stays in fixed point mode during intermittent XLL >> decoding errors >> * X96 extension is no longer parsed (and left unused) when decoding XLL >> * Minor code refactoring >> >> foo86 (16): >> avcodec/dca: remove old decoder >> avcodec/dca: remove unused assembly >> avcodec/dca: remove unused data >> tests/fate/audio: remove dca-xll test >> tests/checkasm: remove dcadsp test >> avcodec/dca: add REV1AUX sync word >> avcodec/dca: add more tables >> avcodec/dca: add math helpers and fixed point DCT >> avcodec/synth_filter: fix whitespace >> avcodec/synth_filter: add more filters >> avcodec/dca: add DSP implementation >> avcodec/dca: add generic defines >> avcodec/dca: add core decoder >> avcodec/dca: add EXSS parser >> avcodec/dca: add XLL decoder >> avcodec/dca: add new decoder based on libdcadec > > This breaks decoding > https://trac.ffmpeg.org/raw-attachment/ticket/3550/WorstCase.wav > didnt investgate what or why > That file seems rather funky. The dts parser outputs DTS frames of 16384 bytes, while the frame headers say 4097 bytes. Seems like a parser problem to start with. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCHv3] avcodec: Cineform HD Decoder
On Mon, Jan 25, 2016 at 4:51 PM, Vittorio Giovara
wrote:
> On Sun, Jan 24, 2016 at 7:34 PM, Kieran Kunhya wrote:
>> Decodes YUV 4:2:2 10-bit and RGB 12-bit files.
>> Older files with more subbands, skips, Bayer, alpha not supported.
>> Alpha requires addition of GBRAP12 pixel format.
>
> Actually you could set AV_PIX_FMT_GBRAP16 and tweak the
> bits_per_raw_sample, not sure about the repercussion on the users
> though.
>
>> ---
>> +static av_cold int cfhd_decode_init(AVCodecContext *avctx)
>
> is this function _decode or _init? or is it decoder_init? imho names
> would be simpler with just _ scheme.
Dunno was told to do that.
>> +{
>> +CFHDContext *s = avctx->priv_data;
>> +
>> +avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
>
> if the decoder supports multiple pixel formats it's better not to
> initialize the pixel format here, and wait until decode(). Otherwise
> it's going to cause a "parameters changed" warning and reinit any
> previous filter chain.
There are some samples which don't have a pixel format flagged and are
implicitly AV_PIX_FMT_YUV422P10.
>> +avctx->bits_per_raw_sample = 10;
>> +s->avctx = avctx;
>> +avctx->width = 0;
>> +avctx->height = 0;
>
> isn't the context mallocz anyway?
No it's allocated from the demuxer
>> +return ff_cfhd_init_vlcs(s);
>> +}
>> +
>
>> +static inline void filter(int16_t *output, ptrdiff_t out_stride, int16_t
>> *low, ptrdiff_t low_stride,
>> + int16_t *high, ptrdiff_t high_stride, int len,
>> uint8_t clip)
>> +{
>> +int16_t tmp;
>> +
>> +int i;
>> +for (i = 0; i < len; i++) {
>> +if (i == 0) {
>> +tmp = (11*low[0*low_stride] - 4*low[1*low_stride] +
>> low[2*low_stride] + 4) >> 3;
>> +output[(2*i+0)*out_stride] = (tmp + high[0*high_stride]) >> 1;
>> +if (clip)
>> +output[(2*i+0)*out_stride] =
>> av_clip_uintp2(output[(2*i+0)*out_stride], clip);
>> +
>> +tmp = ( 5*low[0*low_stride] + 4*low[1*low_stride] -
>> low[2*low_stride] + 4) >> 3;
>> +output[(2*i+1)*out_stride] = (tmp - high[0*high_stride]) >> 1;
>> +if (clip)
>> +output[(2*i+1)*out_stride] =
>> av_clip_uintp2(output[(2*i+1)*out_stride], clip);
>> +}
>> +else if (i == len-1){
>
> nit, spacing and new line are still off
>
>> +tmp = ( 5*low[i*low_stride] + 4*low[(i-1)*low_stride] -
>> low[(i-2)*low_stride] + 4) >> 3;
>> +output[(2*i+0)*out_stride] = (tmp + high[i*high_stride]) >> 1;
>> +if (clip)
>> +output[(2*i+0)*out_stride] =
>> av_clip_uintp2(output[(2*i+0)*out_stride], clip);
>> +
>> +tmp = (11*low[i*low_stride] - 4*low[(i-1)*low_stride] +
>> low[(i-2)*low_stride] + 4) >> 3;
>> +output[(2*i+1)*out_stride] = (tmp - high[i*high_stride]) >> 1;
>> +if (clip)
>> +output[(2*i+1)*out_stride] =
>> av_clip_uintp2(output[(2*i+1)*out_stride], clip);
>> +}
>> +else {
>> +tmp = (low[(i-1)*low_stride] - low[(i+1)*low_stride] + 4) >> 3;
>> +output[(2*i+0)*out_stride] = (tmp + low[i*low_stride] +
>> high[i*high_stride]) >> 1;
>> +if (clip)
>> +output[(2*i+0)*out_stride] =
>> av_clip_uintp2(output[(2*i+0)*out_stride], clip);
>> +
>> +tmp = (low[(i+1)*low_stride] - low[(i-1)*low_stride] + 4) >> 3;
>> +output[(2*i+1)*out_stride] = (tmp + low[i*low_stride] -
>> high[i*high_stride]) >> 1;
>> +if (clip)
>> +output[(2*i+1)*out_stride] =
>> av_clip_uintp2(output[(2*i+1)*out_stride], clip);
>> +}
>> +}
>> +}
>
> +1 on the dsp suggestion
>
>> +}
>> +
>> +static int alloc_buffers(AVCodecContext *avctx)
>> +{
>> +CFHDContext *s = avctx->priv_data;
>> +int i, j, k;
>> +
>> +avctx->width = s->coded_width;
>> +avctx->height = s->coded_height;
>
> I think ff_set_dimensions is the function you're looking for (make
> sure to check its return value)
>
>> +avcodec_get_chroma_sub_sample(avctx->pix_fmt, &s->chroma_x_shift,
>> &s->chroma_y_shift);
>
> this again? :)
>
>> +for (i = 0; i < 3; i++) {
>> +int width = i ? avctx->width >> s->chroma_x_shift : avctx->width;
>> +int height = i ? avctx->height >> s->chroma_y_shift : avctx->height;
>
> could these be candidates for AV_CEIL_RSHIFT?
>
>> +int stride = FFALIGN(width / 8, 8) * 8;
>> +int w8, h8, w4, h4, w2, h2;
>> +height = FFALIGN(height / 8, 2) * 8;
>> +s->plane[i].width = width;
>> +s->plane[i].height = height;
>> +s->plane[i].stride = stride;
>> +
>> +w8 = FFALIGN(s->plane[i].width / 8, 8);
>> +h8 = FFALIGN(s->plane[i].height / 8, 2);
>> +w4 = w8 * 2;
>> +h4 = h8 * 2;
>> +w2 = w4 * 2;
>> +h2 = h4 * 2;
>> +
>> +s->plane[i].idwt_buf = av_malloc(height * strid
Re: [FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one
On Tue, Jan 26, 2016 at 12:05 AM, Hendrik Leppkes wrote: > On Fri, Jan 22, 2016 at 11:25 PM, Michael Niedermayer > wrote: >> On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote: >>> Updated version of the patch. I choose to split it into even smaller >>> commits to >>> make reviewing easier; you may prefer to squash it as needed. >>> >>> Changes since the first version: >>> >>> * Removed checkasm test for dcadsp >>> * Removed FATE test for dca-xll (didn't check if this works) >>> * Core decoder now uses butterflies_fixed() for sumdiff decoding >>> * avpriv_request_sample() is now used for reporting missing features >>> * Core decoder now stays in fixed point mode during intermittent XLL >>> decoding errors >>> * X96 extension is no longer parsed (and left unused) when decoding XLL >>> * Minor code refactoring >>> >>> foo86 (16): >>> avcodec/dca: remove old decoder >>> avcodec/dca: remove unused assembly >>> avcodec/dca: remove unused data >>> tests/fate/audio: remove dca-xll test >>> tests/checkasm: remove dcadsp test >>> avcodec/dca: add REV1AUX sync word >>> avcodec/dca: add more tables >>> avcodec/dca: add math helpers and fixed point DCT >>> avcodec/synth_filter: fix whitespace >>> avcodec/synth_filter: add more filters >>> avcodec/dca: add DSP implementation >>> avcodec/dca: add generic defines >>> avcodec/dca: add core decoder >>> avcodec/dca: add EXSS parser >>> avcodec/dca: add XLL decoder >>> avcodec/dca: add new decoder based on libdcadec >> >> This breaks decoding >> https://trac.ffmpeg.org/raw-attachment/ticket/3550/WorstCase.wav >> didnt investgate what or why >> > > That file seems rather funky. The dts parser outputs DTS frames of > 16384 bytes, while the frame headers say 4097 bytes. > Seems like a parser problem to start with. So I did some further checking, and that file is just crazy, and the parser behaves like it should. The frames are actually 16384 bytes in size, padded with a bunch of zeroes. One theory was that a spdif encoder spit this out. So on to the error - The decoder complains about overreading the dca frame, and yes, its reading more than the designated frame size in the core header - however, its not actually overreading the input buffer. Maybe the check can be "relaxed" a bit, since it doesn't actually overread the input, and the frame size in the header is just bogus? The header says 4096+1, but looking at the bitstream I can clearly see it just going on with seemingly meaningful data after. An "explode" type check might make sense here? If the input buffer is this large, and the core header is just lying, do we really need to error out? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/thp: implement seeking
On Mon, Jan 25, 2016 at 11:02:35PM +0100, Paul B Mahol wrote: > On 1/25/16, Michael Niedermayer wrote: > > On Mon, Jan 25, 2016 at 10:29:08PM +0100, Paul B Mahol wrote: > >> On 1/25/16, Michael Niedermayer wrote: > >> > On Sun, Nov 22, 2015 at 12:58:51AM +0100, Paul B Mahol wrote: > >> >> Signed-off-by: Paul B Mahol > >> >> --- > >> >> libavformat/thp.c | 44 +--- > >> >> 1 file changed, 41 insertions(+), 3 deletions(-) > >> > > >> > confirmed to be working > >> > >> No, it doesnt always. AFAIK its not possible to fix. > > > > it worked with the thp files i had locally :( > > where can i find a file with which it doesnt work ? > > https://www.dropbox.com/s/zr8034va0y6tfyy/KilllaKillOP.thp seeking (clicking right/left arrows in ffplay) seems to work with this file too [...] -- 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] [PATCH] svq1enc: fix out of bounds reads
On 22.01.2016 00:57, Michael Niedermayer wrote:
> On Thu, Jan 21, 2016 at 11:04:14PM +0100, Andreas Cadhalpun wrote:
>> level can be up to 5, but there are only four codebooks.
>>
>> Fixes ubsan runtime error: index 5 out of bounds for type 'int8_t
>> [4][96]'
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/svq1enc.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
>> index 1e1745e..7ff72b4 100644
>> --- a/libavcodec/svq1enc.c
>> +++ b/libavcodec/svq1enc.c
>> @@ -104,7 +104,7 @@ static int encode_block(SVQ1EncContext *s, uint8_t *src,
>> uint8_t *ref,
>> best_score = 0;
>> // FIXME: Optimize, this does not need to be done multiple times.
>> if (intra) {
>> -codebook_sum = svq1_intra_codebook_sum[level];
>> +codebook_sum = level < 4 ? svq1_intra_codebook_sum[level] : NULL;
>> codebook = ff_svq1_intra_codebooks[level];
>> mean_vlc = ff_svq1_intra_mean_vlc;
>> multistage_vlc = ff_svq1_intra_multistage_vlc[level];
>> @@ -117,7 +117,7 @@ static int encode_block(SVQ1EncContext *s, uint8_t *src,
>> uint8_t *ref,
>> }
>> }
>> } else {
>> -codebook_sum = svq1_inter_codebook_sum[level];
>> +codebook_sum = level < 4 ? svq1_inter_codebook_sum[level] : NULL;
>> codebook = ff_svq1_inter_codebooks[level];
>> mean_vlc = ff_svq1_inter_mean_vlc + 256;
>> multistage_vlc = ff_svq1_inter_multistage_vlc[level];
>
>> @@ -143,7 +143,7 @@ static int encode_block(SVQ1EncContext *s, uint8_t *src,
>> uint8_t *ref,
>> const int8_t *vector;
>>
>> for (i = 0; i < 16; i++) {
>> -int sum = codebook_sum[stage * 16 + i];
>> +int sum = codebook_sum ? codebook_sum[stage * 16 + i] : 0;
>> int sqr, diff, score;
>
> this is uneeded, it cannot be NULL
Indeed. That explains how FATE could pass...
> the other 2 checks should be commented to say something about the
>> = 4 case being unused
Attached patch has comments there.
Best regards,
Andreas
>From 5168bee94d1e7e09ebfcfe2bdab94430d4366cb2 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Thu, 21 Jan 2016 22:36:36 +0100
Subject: [PATCH] svq1enc: fix out of bounds reads
level can be 5, but there are only four codebooks.
Fixes ubsan runtime error: index 5 out of bounds for type 'int8_t
[4][96]'
Signed-off-by: Andreas Cadhalpun
---
libavcodec/svq1enc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
index 1e1745e..d968d36 100644
--- a/libavcodec/svq1enc.c
+++ b/libavcodec/svq1enc.c
@@ -104,7 +104,9 @@ static int encode_block(SVQ1EncContext *s, uint8_t *src, uint8_t *ref,
best_score = 0;
// FIXME: Optimize, this does not need to be done multiple times.
if (intra) {
-codebook_sum = svq1_intra_codebook_sum[level];
+// level is 5 when encode_block is called from svq1_encode_plane
+// and always < 4 when called recursively from this function.
+codebook_sum = level < 4 ? svq1_intra_codebook_sum[level] : NULL;
codebook = ff_svq1_intra_codebooks[level];
mean_vlc = ff_svq1_intra_mean_vlc;
multistage_vlc = ff_svq1_intra_multistage_vlc[level];
@@ -117,7 +119,8 @@ static int encode_block(SVQ1EncContext *s, uint8_t *src, uint8_t *ref,
}
}
} else {
-codebook_sum = svq1_inter_codebook_sum[level];
+// level is 5 or < 4, see above for details.
+codebook_sum = level < 4 ? svq1_inter_codebook_sum[level] : NULL;
codebook = ff_svq1_inter_codebooks[level];
mean_vlc = ff_svq1_inter_mean_vlc + 256;
multistage_vlc = ff_svq1_inter_multistage_vlc[level];
--
2.7.0.rc3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder
On Mon, Jan 25, 2016 at 2:42 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, Jan 24, 2016 at 7:34 PM, Kieran Kunhya wrote: > >> +static inline void filter(int16_t *output, ptrdiff_t out_stride, int16_t >> *low, ptrdiff_t low_stride, >> + int16_t *high, ptrdiff_t high_stride, int len, >> uint8_t clip) > > > Should this be a DSP function? (That is, the functions calling this.) > > They seem very SIMD'able. > > Ronald I plan to split this all up in the future, for now I want to get it in. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] svq1enc: fix out of bounds reads
On Tue, Jan 26, 2016 at 01:04:05AM +0100, Andreas Cadhalpun wrote:
> On 22.01.2016 00:57, Michael Niedermayer wrote:
> > On Thu, Jan 21, 2016 at 11:04:14PM +0100, Andreas Cadhalpun wrote:
> >> level can be up to 5, but there are only four codebooks.
> >>
> >> Fixes ubsan runtime error: index 5 out of bounds for type 'int8_t
> >> [4][96]'
> >>
> >> Signed-off-by: Andreas Cadhalpun
> >> ---
> >> libavcodec/svq1enc.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
> >> index 1e1745e..7ff72b4 100644
> >> --- a/libavcodec/svq1enc.c
> >> +++ b/libavcodec/svq1enc.c
> >> @@ -104,7 +104,7 @@ static int encode_block(SVQ1EncContext *s, uint8_t
> >> *src, uint8_t *ref,
> >> best_score = 0;
> >> // FIXME: Optimize, this does not need to be done multiple times.
> >> if (intra) {
> >> -codebook_sum = svq1_intra_codebook_sum[level];
> >> +codebook_sum = level < 4 ? svq1_intra_codebook_sum[level] :
> >> NULL;
> >> codebook = ff_svq1_intra_codebooks[level];
> >> mean_vlc = ff_svq1_intra_mean_vlc;
> >> multistage_vlc = ff_svq1_intra_multistage_vlc[level];
> >> @@ -117,7 +117,7 @@ static int encode_block(SVQ1EncContext *s, uint8_t
> >> *src, uint8_t *ref,
> >> }
> >> }
> >> } else {
> >> -codebook_sum = svq1_inter_codebook_sum[level];
> >> +codebook_sum = level < 4 ? svq1_inter_codebook_sum[level] :
> >> NULL;
> >> codebook = ff_svq1_inter_codebooks[level];
> >> mean_vlc = ff_svq1_inter_mean_vlc + 256;
> >> multistage_vlc = ff_svq1_inter_multistage_vlc[level];
> >
> >> @@ -143,7 +143,7 @@ static int encode_block(SVQ1EncContext *s, uint8_t
> >> *src, uint8_t *ref,
> >> const int8_t *vector;
> >>
> >> for (i = 0; i < 16; i++) {
> >> -int sum = codebook_sum[stage * 16 + i];
> >> +int sum = codebook_sum ? codebook_sum[stage * 16 + i] : 0;
> >> int sqr, diff, score;
> >
> > this is uneeded, it cannot be NULL
>
> Indeed. That explains how FATE could pass...
>
> > the other 2 checks should be commented to say something about the
> >> = 4 case being unused
>
> Attached patch has comments there.
>
> Best regards,
> Andreas
>
> svq1enc.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
> 303a9f08a561047395172ac4f7abbc63a78c9021
> 0001-svq1enc-fix-out-of-bounds-reads.patch
> From 5168bee94d1e7e09ebfcfe2bdab94430d4366cb2 Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun
> Date: Thu, 21 Jan 2016 22:36:36 +0100
> Subject: [PATCH] svq1enc: fix out of bounds reads
>
> level can be 5, but there are only four codebooks.
>
> Fixes ubsan runtime error: index 5 out of bounds for type 'int8_t
> [4][96]'
>
> Signed-off-by: Andreas Cadhalpun
should be ok
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/h264_cabac: Check decode_cabac_mb_mvd() for failure
From: Michael Niedermayer Fixes harmless integer overflow Fixes Ticket5150 No speedloss measured, actually its slightly faster, but please benchmark & double check this Signed-off-by: Michael Niedermayer --- libavcodec/h264_cabac.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264_cabac.c b/libavcodec/h264_cabac.c index 04d412b..deab35a 100644 --- a/libavcodec/h264_cabac.c +++ b/libavcodec/h264_cabac.c @@ -1540,8 +1540,12 @@ static int decode_cabac_mb_mvd(H264SliceContext *sl, int ctxbase, int amvd, int int amvd1 = sl->mvd_cache[list][scan8[n] - 1][1] +\ sl->mvd_cache[list][scan8[n] - 8][1];\ \ -mx += decode_cabac_mb_mvd(sl, 40, amvd0, &mpx);\ -my += decode_cabac_mb_mvd(sl, 47, amvd1, &mpy);\ +int mxd = decode_cabac_mb_mvd(sl, 40, amvd0, &mpx);\ +int myd = decode_cabac_mb_mvd(sl, 47, amvd1, &mpy);\ +if (mxd == INT_MIN || myd == INT_MIN) \ +return AVERROR_INVALIDDATA; \ +mx += mxd;\ +my += myd;\ } static av_always_inline int get_cabac_cbf_ctx(H264SliceContext *sl, -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] sdp: print a=framesize for MJPEG
On Tue, Dec 08, 2015 at 02:10:31PM +0200, Andrey Utkin wrote: > Signed-off-by: Andrey Utkin > --- > libavformat/sdp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/sdp.c b/libavformat/sdp.c > index 2ab37a8..27112ef 100644 > --- a/libavformat/sdp.c > +++ b/libavformat/sdp.c > @@ -657,6 +657,8 @@ static char *sdp_write_media_attributes(char *buff, int > size, AVCodecContext *c, > if (payload_type >= RTP_PT_PRIVATE) > av_strlcatf(buff, size, "a=rtpmap:%d JPEG/9\r\n", > payload_type); > +av_strlcatf(buff, size, "a=framesize:%d %d-%d\r\n", > +payload_type, c->width, c->height); should this always be stored or only for dimensions which need it ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] rtpdec_jpeg: use framesize from SDP if present
On Tue, Dec 08, 2015 at 02:10:32PM +0200, Andrey Utkin wrote:
> This enables us to process pics larger than 2040 pixels in dimensions,
> overcoming the limitation of RFC 2435.
>
> Signed-off-by: Andrey Utkin
> ---
> libavformat/rtpdec_jpeg.c | 46 +++---
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c
> index 6bf88f8..0a83468 100644
> --- a/libavformat/rtpdec_jpeg.c
> +++ b/libavformat/rtpdec_jpeg.c
> @@ -24,9 +24,11 @@
> #include "rtpdec.h"
> #include "rtpdec_formats.h"
> #include "libavutil/intreadwrite.h"
> +#include "libavutil/avstring.h"
> #include "libavcodec/jpegtables.h"
> #include "libavcodec/mjpeg.h"
> #include "libavcodec/bytestream.h"
> +#include "libavformat/rtpdec_formats.h"
>
> /**
> * RTP/JPEG specific private data.
> @@ -35,6 +37,14 @@ struct PayloadContext {
> AVIOContext *frame; ///< current frame buffer
> uint32_ttimestamp; ///< current frame timestamp
> int hdr_size; ///< size of the current frame header
> +/**
> + * Flag, shows whether we got framesize explicitly from SDP.
> + * If set, override dimensions from RTP header.
> + * Workaround for dimensions larger than 2040 (limitation of RFC 2435).
> + */
> +int sdp_framesize_set;
> +int sdp_width;
> +int sdp_height;
> uint8_t qtables[128][128];
> uint8_t qtables_len[128];
> };
> @@ -215,7 +225,8 @@ static int jpeg_parse_packet(AVFormatContext *ctx,
> PayloadContext *jpeg,
> const uint8_t *buf, int len, uint16_t seq,
> int flags)
> {
> -uint8_t type, q, width, height;
> +uint8_t type, q;
> +uint32_t width, height;
> const uint8_t *qtables = NULL;
> uint16_t qtable_len;
> uint32_t off;
> @@ -230,8 +241,13 @@ static int jpeg_parse_packet(AVFormatContext *ctx,
> PayloadContext *jpeg,
> off= AV_RB24(buf + 1); /* fragment byte offset */
> type = AV_RB8(buf + 4); /* id of jpeg decoder params */
> q = AV_RB8(buf + 5); /* quantization factor (or table id) */
> -width = AV_RB8(buf + 6); /* frame width in 8 pixel blocks */
> -height = AV_RB8(buf + 7); /* frame height in 8 pixel blocks */
> +if (jpeg->sdp_framesize_set) {
> +width = FF_CEIL_RSHIFT(jpeg->sdp_width, 3);
> +height = FF_CEIL_RSHIFT(jpeg->sdp_height, 3);
i dont think the lowest 3 bits should be discarded
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: prefer to use -liconv when possible
OSX's ld sometimes does and sometimes doesn't need -liconv. For instance, -Wl,-dead_strip in LDFLAGS will make the iconv conf check pass without -liconv, but linking ffmpeg_g will fail. There are likely other awkward interactions that could cause that sort of issue. Thus, we'll try to use the -liconv arg and fallback on not using it, rather than the other way around. --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index e5cd88e..0d4d7cb 100755 --- a/configure +++ b/configure @@ -5773,7 +5773,7 @@ enabled vdpau && enabled xlib && enable vdpau_x11 # Funny iconv installations are not unusual, so check it after all flags have been set -disabled iconv || check_func_headers iconv.h iconv || check_lib2 iconv.h iconv -liconv || disable iconv +disabled iconv || check_func_headers iconv.h iconv -liconv || check_lib2 iconv.h iconv || disable iconv enabled debug && add_cflags -g"$debuglevel" && add_asflags -g"$debuglevel" -- 2.7.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Feature Suggestion/Idea: auto create profile from supplied media file.
An idea for a new feature of ffmpeg: Detect media, and generate profile for future transcoding. The feature would add the ability to point ffmpeg at a media file and analyze the file for its container type, codecs, channels, bit rates, etc, and build a PROFILE according to what it discovers. Then, in the future, if you need to transcode/conform media to a specific target destination format, for a specific device, or platform, you would just point ffmpeg at a media file known to work properly on the destination platform, have it learn the specific parameters of that media container and format, create a profile based on what it discovers, and then in the future when you transcode you just use the newly created profile when transcoding. I imagine ffmpeg already has the ability to detect media because I can see it making determinations about the media at the beginning of its transcoding or encoding process. create a profile called vtech-kids-smartwatch based on using video-file-known-to-work-well-on-destination-platform.avi : $ ffmpeg --profile_auto_generate video-file-known-to-work-well-on-destination-platform.avi vtech-kids-smartwatch conform/transcode media input to the vtech-kids-smartwatch profile : $ ffmpeg -i incompatibel-media-file.mov -o --profile vtech-kids-smartwatch conformed-video-file.avi syntax just for concept Thanks for considering. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] stream changes for QT Movie files
I want do feed kodi with existing QT Movie files (mp4 muxed audio + video) wich can change codec / resolutions during the playback. Currently I have solved this issue by writing new MOOV Atoms every time the stream changes, but this works only with an hack inside mov.c (replace the existing avstreams with the new once). ffmpeg doesn't support multiple MOOV atoms for now and kodi doesn't want to have patches for ffmpeg (what I can understand) My question is now: What is the best solution for codec / resolution changes using QT Movie file format. Is there already anything working for this problem? Thanks! Markus ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/rtsp: Fix rtsps, do not force tcp transport
rtsp over ssl is not working. tls does not implement prot->url_get_file_handle
so ffurl_get_file_handle() fails.
struct sockaddr_storage peer is initialized but not used, remove it.
rtsps lower transport was set to TCP. Transport could be UDP. It permits to use
RTSPS + SRTP.
---
libavformat/rtsp.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 39539e9..25451fb 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1651,13 +1651,11 @@ int ff_rtsp_connect(AVFormatContext *s)
char proto[128], host[1024], path[1024];
char tcpname[1024], cmd[2048], auth[128];
const char *lower_rtsp_proto = "tcp";
-int port, err, tcp_fd;
+int port, err;
RTSPMessageHeader reply1 = {0}, *reply = &reply1;
int lower_transport_mask = 0;
int default_port = RTSP_DEFAULT_PORT;
char real_challenge[64] = "";
-struct sockaddr_storage peer;
-socklen_t peer_len = sizeof(peer);
if (rt->rtp_port_max < rt->rtp_port_min) {
av_log(s, AV_LOG_ERROR, "Invalid UDP port range, max port %d less "
@@ -1688,7 +1686,6 @@ redirect:
if (!strcmp(proto, "rtsps")) {
lower_rtsp_proto = "tls";
default_port = RTSPS_DEFAULT_PORT;
-rt->lower_transport_mask = 1 << RTSP_LOWER_TRANSPORT_TCP;
}
if (*auth) {
@@ -1809,16 +1806,6 @@ redirect:
}
rt->seq = 0;
-tcp_fd = ffurl_get_file_handle(rt->rtsp_hd);
-if (tcp_fd < 0) {
-err = tcp_fd;
-goto fail;
-}
-if (!getpeername(tcp_fd, (struct sockaddr*) &peer, &peer_len)) {
-getnameinfo((struct sockaddr*) &peer, peer_len, host, sizeof(host),
-NULL, 0, NI_NUMERICHOST);
-}
-
/* request options supported by the server; this also detects server
* type */
for (rt->server_type = RTSP_SERVER_RTP;;) {
--
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.
I guess png is another example; 10 is the denominator for the 32-bit integer: https://github.com/FFmpeg/FFmpeg/blob/b58cfa616c169c90166938608e7135cdab5820e0/libavcodec/pngenc.c#L290 In the standards, the primaries and white point coords are usually only referenced in 2-4 significant figures (ISO/IEC 23001-8:2013(E) has them all in one doc). The display primaries can be different from these, but I don't think you'd see them measured with any more precision (more precision is unlikely to matter for this metadata anyway). It seems that most are in favor of AVRational, so I'll change the avutil struct float internal fields to rational. On Mon, Jan 25, 2016 at 1:43 PM, Hendrik Leppkes wrote: > On Mon, Jan 25, 2016 at 10:37 PM, Michael Niedermayer > wrote: > > On Fri, Jan 22, 2016 at 02:54:21PM -0800, Neil Birkbeck wrote: > >> Hmm. I don't have a good idea of how likely it is for this conversion to > >> float (by dividing a constant) to not be bit-exact on different > >> architectures (compilers?) when there should not be any other math > >> transforming the metadata (other than the conversion back to the integer > >> coding for cases like hevc, which for a given architecture is possible > >> without loss). The fact that this could happen at all does make it > annoying > >> in terms of bit-exact test expectations across arch, and this is the > main > >> concern, right? (for this type of metadata, it is really a hint to > >> TVs/algorithms, and some will ignore it altogether) > > > > bitexactness is one concern, also theres the issue with what is ideally > > correct. > > that is what are the ideal values dictated by various standards > > that hardware (cammeras, ...) aim at ? > > are these rational or float or what can represent them better ? > > > > Both HEVC and the HDMI Info Frames use fixed-point integers (the same > scales too, apparently), I do not know of the formats anything else > uses. > Maybe we should be using AVRationals? > > I would argue that MKV storing floats is a terrible idea, and someone > should bonk them over the head and store fixed point as well. > > - 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
