Re: [FFmpeg-devel] avcodec/proresenc_aw improvements
On Sat, Jul 21, 2018 at 02:33:24PM +0200, Martin Vignali wrote: [...] > 004 : calculate dct part before the quantif search. Avoid to recalculate it > each time > On a basic test Prores decoding -> prores encoding, the global speed > improvment is around 2% nice speedup [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file
On Sat, Jul 21, 2018 at 05:36:02PM -0300, James Almer wrote: > On 7/21/2018 4:54 PM, Michael Niedermayer wrote: > > On Sat, Jul 21, 2018 at 02:28:21PM -0300, James Almer wrote: > >> And add it to the list of configurable components in Makefile, so changes > >> to > >> the file will be tracked and the usual warning to suggest re-running > >> configure > >> will be shown. > >> > >> Signed-off-by: James Almer > >> --- > >> Makefile | 1 + > >> configure| 2 +- > >> libavcodec/Makefile | 1 + > >> libavcodec/parser.c | 85 -- > >> libavcodec/parsers.c | 106 +++ > >> 5 files changed, 109 insertions(+), 86 deletions(-) > >> create mode 100644 libavcodec/parsers.c > > > > parser.c, parsers.c parser_list.c > > > > decode.c (no decoder.c, no decoders, no decoder_list.c, no parse.c) > > encode.c (matching decode but differing from parser) > > > > seems a bit inconsistent, naming wise. > > decode.c and encode.c are not component related files. They are the same > as parser.c is now, containing API independent of available components. > > It still could use some cleaning, in any case. We have the following > right now: > > allcodecs.c (list of decoders and encoders, plus related > iteration/register API) > codec_list.c (generated file for enabled decoders and encoders) > decode.c (non iteration/register related decoder API functions) > encode.c (non iteration/register related encoder API functions) > > allfilters.c (list of filters, plus related iteration/register API) > filter_list.c (generated file for enabled filters) > > allformats.c (list of demuxers and muxers, plus related > iteration/register API) > demuxer_list.c (generated file for enabled demuxers) > muxer_list.c (generated file for enabled muxers) > > alldevices.c (list of indevs and outdevs, plus related > iteration/register API) > indev_list.c (generated file for enabled indevs) > outdev_list.c (generated file for enabled outdevs) > > protocols.c (list of protocols, plus related iteration/register API) > protocol_list.c (generated file for enabled protocols) > > bitstream_filters.c (list of bsfs, plus related iteration/register API) > bsf_list.c (generated file for enabled bsfs) > bsf.c (non iteration/register related bsf API functions) > bitstream_filter.c (deprecated bsf API, to be removed in a major bump) > > parsers.c (list of parsers, plus related iteration/register API) > parser_list.c (generated file for enabled parsers) > parser.c (non iteration/register related parser API functions) > > > We could add the "all" prefix to the last three component list files. We > could rename parser.c into parse.c to be in line with decode/encode.c. > We could split the generated list of decoders and encoders into their > own files. We could look into moving the deprecated bsf functions into > the main bsf file and choose a consistent naming for them all (bsf is > shorter and probably best), etc. > > I can look into doing some cleaning in this regard if we come to a > consensus as to what should be done. This patch was mainly to get the > file listing available parsers to trigger the Makefile message in case > of changes, while making sure it only happens when new parsers are added > instead of every time a bug is fixed in av_parser_parse2() or any other > such function. Iam in favor of any cleanup in respect to file naming that makes things more logically, easy to understand and consistently structured. Then again i also dont intend here to push anyone toward anything. If you have any doubt about some change on the naming then its better to leave it, we can always rename something later but renaming and then undoing would be alot more annoying. I just wanted to bring attention to the naming as it seemed to me that it was inconsistent for no obvious reason PS: the file list you wrote in that mail, this should be in some more vissible place i think than a mail on the ML thanks [...] -- 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: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mov: Make auxiliary_offsets consistently size_t.
On Sat, Jul 21, 2018 at 03:52:19PM +0200, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes a warning on ppc32: > libavformat/mov.c: In function ‘mov_read_saio’: > libavformat/mov.c:6207:45: warning: assignment from incompatible > pointer type [-Wincompatible-pointer-types] > encryption_index->auxiliary_offsets = auxiliary_offsets; > ^ > > Please comment, Carl Eugen This array is used to store 64bit values if version > 0, size_t may be smaller, is that intended ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file
On 7/21/2018 4:54 PM, Michael Niedermayer wrote: > On Sat, Jul 21, 2018 at 02:28:21PM -0300, James Almer wrote: >> And add it to the list of configurable components in Makefile, so changes to >> the file will be tracked and the usual warning to suggest re-running >> configure >> will be shown. >> >> Signed-off-by: James Almer >> --- >> Makefile | 1 + >> configure| 2 +- >> libavcodec/Makefile | 1 + >> libavcodec/parser.c | 85 -- >> libavcodec/parsers.c | 106 +++ >> 5 files changed, 109 insertions(+), 86 deletions(-) >> create mode 100644 libavcodec/parsers.c > > parser.c, parsers.c parser_list.c > > decode.c (no decoder.c, no decoders, no decoder_list.c, no parse.c) > encode.c (matching decode but differing from parser) > > seems a bit inconsistent, naming wise. decode.c and encode.c are not component related files. They are the same as parser.c is now, containing API independent of available components. It still could use some cleaning, in any case. We have the following right now: allcodecs.c (list of decoders and encoders, plus related iteration/register API) codec_list.c (generated file for enabled decoders and encoders) decode.c (non iteration/register related decoder API functions) encode.c (non iteration/register related encoder API functions) allfilters.c (list of filters, plus related iteration/register API) filter_list.c (generated file for enabled filters) allformats.c (list of demuxers and muxers, plus related iteration/register API) demuxer_list.c (generated file for enabled demuxers) muxer_list.c (generated file for enabled muxers) alldevices.c (list of indevs and outdevs, plus related iteration/register API) indev_list.c (generated file for enabled indevs) outdev_list.c (generated file for enabled outdevs) protocols.c (list of protocols, plus related iteration/register API) protocol_list.c (generated file for enabled protocols) bitstream_filters.c (list of bsfs, plus related iteration/register API) bsf_list.c (generated file for enabled bsfs) bsf.c (non iteration/register related bsf API functions) bitstream_filter.c (deprecated bsf API, to be removed in a major bump) parsers.c (list of parsers, plus related iteration/register API) parser_list.c (generated file for enabled parsers) parser.c (non iteration/register related parser API functions) We could add the "all" prefix to the last three component list files. We could rename parser.c into parse.c to be in line with decode/encode.c. We could split the generated list of decoders and encoders into their own files. We could look into moving the deprecated bsf functions into the main bsf file and choose a consistent naming for them all (bsf is shorter and probably best), etc. I can look into doing some cleaning in this regard if we come to a consensus as to what should be done. This patch was mainly to get the file listing available parsers to trigger the Makefile message in case of changes, while making sure it only happens when new parsers are added instead of every time a bug is fixed in av_parser_parse2() or any other such function. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file
On Sat, Jul 21, 2018 at 02:28:21PM -0300, James Almer wrote: > And add it to the list of configurable components in Makefile, so changes to > the file will be tracked and the usual warning to suggest re-running configure > will be shown. > > Signed-off-by: James Almer > --- > Makefile | 1 + > configure| 2 +- > libavcodec/Makefile | 1 + > libavcodec/parser.c | 85 -- > libavcodec/parsers.c | 106 +++ > 5 files changed, 109 insertions(+), 86 deletions(-) > create mode 100644 libavcodec/parsers.c parser.c, parsers.c parser_list.c decode.c (no decoder.c, no decoders, no decoder_list.c, no parse.c) encode.c (matching decode but differing from parser) seems a bit inconsistent, naming wise. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file
On 7/21/2018 2:58 PM, Rostislav Pehlivanov wrote: > On 21 July 2018 at 18:28, James Almer wrote: > >> And add it to the list of configurable components in Makefile, so changes >> to >> the file will be tracked and the usual warning to suggest re-running >> configure >> will be shown. >> >> Signed-off-by: James Almer >> --- >> Makefile | 1 + >> configure| 2 +- >> libavcodec/Makefile | 1 + >> libavcodec/parser.c | 85 -- >> libavcodec/parsers.c | 106 +++ >> 5 files changed, 109 insertions(+), 86 deletions(-) >> create mode 100644 libavcodec/parsers.c > > Looks fine Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swresample: Use channel count in rematrix initialization
Rematrixing supports up to 64 channels. However, there is only a limited number
of channel layouts defined. Since the in/out channel count is currently
obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11
channels etc.) the rematrixing fails.
This patch changes rematrix init methods to use in/out channel count directly
instead of computing it from channel layout.
---
libswresample/rematrix.c | 4 ++--
libswresample/x86/rematrix_init.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 8227730056..ec1909dc0c 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -384,8 +384,8 @@ av_cold static int auto_matrix(SwrContext *s)
av_cold int swri_rematrix_init(SwrContext *s){
int i, j;
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = s->in.ch_count;
+int nb_out = s->out.ch_count;
s->mix_any_f = NULL;
diff --git a/libswresample/x86/rematrix_init.c
b/libswresample/x86/rematrix_init.c
index d71b41a73e..1cdf97803f 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -33,8 +33,8 @@ D(int16, sse2)
av_cold int swri_rematrix_init_x86(struct SwrContext *s){
#if HAVE_X86ASM
int mm_flags = av_get_cpu_flags();
-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in = s->in.ch_count;
+int nb_out = s->out.ch_count;
int num= nb_in * nb_out;
int i,j;
--
2.18.0.233.g985f88cf7e-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresenc_aw : add support for prores 444
On 7/21/18, Martin Vignali wrote: > Hello > > Patch in attach add support for prores 444 profile in AW prores encoder > > Need to be apply after patch in discussion "avcodec/proresenc_aw > improvments" > > Speed (from prores 422 HQ file -> Prores 444) > > ./ffmpeg -i prores422hqfile.mov -pix_fmt yuv444p10 -c:v prores -an > -profile:v 4 res_aw.mov -y > ==> 25 fps > > ./ffmpeg -i prores422hqfile.mov -pix_fmt yuv444p10 -c:v prores_ks -an > -profile:v 4 res_ks.mov -y > ==> 10 fps This is unfair comparison. > > > 001 : Add support for Prores 444 (without alpha) > 002 : change the frame flag in header part, to be the same than the > official encoder in 422 mode > (and update fate test) Whatever you are doing regarding improving prores_aw is bad idea. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined
Of course, I will update the patch and send it out shortly.
Using in.ch_count should be ok. The relevant check is in swresample.c:292,
so we should never reach that code if the in.ch_count is 0.
On Fri, Jul 20, 2018 at 7:36 PM Michael Niedermayer
wrote:
> On Fri, Jul 20, 2018 at 09:51:49AM +0200, Tobias Rapp wrote:
> > On 19.07.2018 23:37, Michael Niedermayer wrote:
> > >On Thu, Jul 19, 2018 at 01:53:09PM +0200, Tobias Rapp wrote:
> > >>On 18.07.2018 19:31, Marcin Gorzel wrote:
> > >>>Rematrixing supports up to 64 channels. However, there is only a
> limited number of channel layouts defined. Since the in/out channel count
> is obtained from the channel layout, for undefined layouts (e.g. for 9, 10,
> 11 channels etc.) the rematrixing fails.
> > >>>
> > >>>In ticket #6790 the problem has been partially addressed by applying
> a patch to swr_set_matrix() in rematrix.c:72.
> > >>>However, a similar change must be also applied to
> swri_rematrix_init() in rematrix.c:389 and swri_rematrix_init_x86() in
> rematrix_init.c:36.
> > >>>---
> > >>> libswresample/rematrix.c | 6 --
> > >>> libswresample/x86/rematrix_init.c | 6 --
> > >>> 2 files changed, 8 insertions(+), 4 deletions(-)
> > >>>
> > >>>diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> > >>>index 8227730056..d1a0cfe7f8 100644
> > >>>--- a/libswresample/rematrix.c
> > >>>+++ b/libswresample/rematrix.c
> > >>>@@ -384,8 +384,10 @@ av_cold static int auto_matrix(SwrContext *s)
> > >>> av_cold int swri_rematrix_init(SwrContext *s){
> > >>> int i, j;
> > >>>-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > >>>-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > >>>+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
> > >>>+av_get_channel_layout_nb_channels(s->in_ch_layout);
> > >>>+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
> > >>>+av_get_channel_layout_nb_channels(s->out_ch_layout);
> > >>> s->mix_any_f = NULL;
> > >>>diff --git a/libswresample/x86/rematrix_init.c
> b/libswresample/x86/rematrix_init.c
> > >>>index d71b41a73e..4f9c92e4ab 100644
> > >>>--- a/libswresample/x86/rematrix_init.c
> > >>>+++ b/libswresample/x86/rematrix_init.c
> > >>>@@ -33,8 +33,10 @@ D(int16, sse2)
> > >>> av_cold int swri_rematrix_init_x86(struct SwrContext *s){
> > >>> #if HAVE_X86ASM
> > >>> int mm_flags = av_get_cpu_flags();
> > >>>-int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > >>>-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > >>>+int nb_in = (s->in.ch_count > 0) ? s->in.ch_count :
> > >>>+av_get_channel_layout_nb_channels(s->in_ch_layout);
> > >>>+int nb_out = (s->out.ch_count > 0) ? s->out.ch_count :
> > >>>+av_get_channel_layout_nb_channels(s->out_ch_layout);
> > >>> int num= nb_in * nb_out;
> > >>> int i,j;
> > >>>
> > >>
> > >>Patch looks good to me, except that the title should be updated to
> reflect
> > >>the new logic. I suggest something like "swresample: Use channel count
> for
> > >>rematrix initialization if defined".
> > >
> > >The patch does not look good to me
> > >There should be a field that represents the count of channels.
> > >No conditional should be needed
> > >
> > >please check that every field is wrong in at least some case.
> > >If true a new field must be added or a existing one needs to be set
> > >differently
> > >But there should be a field that represents the channel count.
> >
> > If I understand correctly you say that the fall-back to
> > av_get_channel_layout_nb_channels() is not needed here as both functions
> are
> > internal and called only as part of swr_init() so we may safely assume
> that
> > the in/out.ch_count fields have been initialized before this code is
> > reached.
>
> yes, if that is tested and works. If it does not work, it would be very
> interresting why not
>
>
> >
> > Fine with me. Marcin, would you update the patch once more? And there are
> > some additional FATE tests for the pan filter that I can post once this
> > patch is through, if you haven't made up your own tests.
> >
> > Regards,
> > Tobias
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "I am not trying to be anyone's saviour, I'm trying to think about the
> future and not be sad" - Elon Musk
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Marcin Gorzel | Software Engineer | gor...@google.com |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file
On 21 July 2018 at 18:28, James Almer wrote:
> And add it to the list of configurable components in Makefile, so changes
> to
> the file will be tracked and the usual warning to suggest re-running
> configure
> will be shown.
>
> Signed-off-by: James Almer
> ---
> Makefile | 1 +
> configure| 2 +-
> libavcodec/Makefile | 1 +
> libavcodec/parser.c | 85 --
> libavcodec/parsers.c | 106 +++
> 5 files changed, 109 insertions(+), 86 deletions(-)
> create mode 100644 libavcodec/parsers.c
>
> diff --git a/Makefile b/Makefile
> index 0cd0a1d6f2..4bf1dfedcf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -58,6 +58,7 @@ tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)
> CONFIGURABLE_COMPONENTS = \
> $(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \
> $(SRC_PATH)/libavcodec/bitstream_filters.c \
> +$(SRC_PATH)/libavcodec/parsers.c\
> $(SRC_PATH)/libavformat/protocols.c \
>
> config.h: ffbuild/.config
> diff --git a/configure b/configure
> index 534c62ed98..741f56d565 100755
> --- a/configure
> +++ b/configure
> @@ -3679,7 +3679,7 @@ CODEC_LIST="
> $ENCODER_LIST
> $DECODER_LIST
> "
> -PARSER_LIST=$(find_things_extern parser AVCodecParser
> libavcodec/parser.c)
> +PARSER_LIST=$(find_things_extern parser AVCodecParser
> libavcodec/parsers.c)
> BSF_LIST=$(find_things_extern bsf AVBitStreamFilter
> libavcodec/bitstream_filters.c)
> HWACCEL_LIST=$(find_things_extern hwaccel AVHWAccel
> libavcodec/hwaccels.h)
> PROTOCOL_LIST=$(find_things_extern protocol URLProtocol
> libavformat/protocols.c)
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 2d4bc48dab..e62603f0dd 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -44,6 +44,7 @@ OBJS = ac3_parser.o
>\
> options.o\
> mjpegenc_huffman.o \
> parser.o \
> + parsers.o\
> profiles.o \
> qsv_api.o\
> raw.o\
> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> index f43b197d5e..0a994a3f30 100644
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -27,95 +27,10 @@
> #include "libavutil/avassert.h"
> #include "libavutil/internal.h"
> #include "libavutil/mem.h"
> -#include "libavutil/thread.h"
>
> #include "internal.h"
> #include "parser.h"
>
> -/* Parsers */
> -extern AVCodecParser ff_aac_parser;
> -extern AVCodecParser ff_aac_latm_parser;
> -extern AVCodecParser ff_ac3_parser;
> -extern AVCodecParser ff_adx_parser;
> -extern AVCodecParser ff_bmp_parser;
> -extern AVCodecParser ff_cavsvideo_parser;
> -extern AVCodecParser ff_cook_parser;
> -extern AVCodecParser ff_dca_parser;
> -extern AVCodecParser ff_dirac_parser;
> -extern AVCodecParser ff_dnxhd_parser;
> -extern AVCodecParser ff_dpx_parser;
> -extern AVCodecParser ff_dvaudio_parser;
> -extern AVCodecParser ff_dvbsub_parser;
> -extern AVCodecParser ff_dvdsub_parser;
> -extern AVCodecParser ff_dvd_nav_parser;
> -extern AVCodecParser ff_flac_parser;
> -extern AVCodecParser ff_g729_parser;
> -extern AVCodecParser ff_gsm_parser;
> -extern AVCodecParser ff_h261_parser;
> -extern AVCodecParser ff_h263_parser;
> -extern AVCodecParser ff_h264_parser;
> -extern AVCodecParser ff_hevc_parser;
> -extern AVCodecParser ff_mjpeg_parser;
> -extern AVCodecParser ff_mlp_parser;
> -extern AVCodecParser ff_mpeg4video_parser;
> -extern AVCodecParser ff_mpegaudio_parser;
> -extern AVCodecParser ff_mpegvideo_parser;
> -extern AVCodecParser ff_opus_parser;
> -extern AVCodecParser ff_png_parser;
> -extern AVCodecParser ff_pnm_parser;
> -extern AVCodecParser ff_rv30_parser;
> -extern AVCodecParser ff_rv40_parser;
> -extern AVCodecParser ff_sbc_parser;
> -extern AVCodecParser ff_sipr_parser;
> -extern AVCodecParser ff_tak_parser;
> -extern AVCodecParser ff_vc1_parser;
> -extern AVCodecParser ff_vorbis_parser;
> -extern AVCodecParser ff_vp3_parser;
> -extern AVCodecParser ff_vp8_parser;
> -extern AVCodecParser ff_vp9_parser;
> -extern AVCodecParser ff_xma_parser;
> -
> -#include "libavcodec/parser_list.c"
> -
> -static AVOnce av_parser_next_init = AV_ONCE_INIT;
> -
> -static void av_parser_init_next(void)
> -{
> -AVCodecParser *prev = NULL, *p;
> -int i = 0;
> -while ((p = (AVCodecParser*)parser_list[i++])) {
> -if (prev)
> -prev->next = p;
> -prev = p;
> -}
> -}
> -
> -AVCodecParser *av_parser_next(const AVCodecParser *p)
> -{
> -
Re: [FFmpeg-devel] [PATCH] avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext
On 7/21/2018 2:34 PM, Michael Niedermayer wrote: > On Fri, Jul 20, 2018 at 08:30:19PM -0300, James Almer wrote: >> On 7/20/2018 8:23 PM, Michael Niedermayer wrote: >>> On Thu, Jul 19, 2018 at 10:54:23PM -0300, James Almer wrote: Certain AVCodecParameters, like the contents of the extradata, may be changed by the init() function of any of the bitstream filters in the chain. Signed-off-by: James Almer --- Things worked fine without this until now by pure chance. vp9_superframe_split doesn't use extradata, and those hardware decoders inserting h264_mp4toannexb and hevc_mp4toannexb passed the extradata to functions that could handle it unfiltered. libavcodec/decode.c | 4 1 file changed, 4 insertions(+) >>> >>> this breaks: >>> ./ffmpeg -i >>> https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png >>> -bitexact -pix_fmt rgba -f framecrc - >>> ... >>> [apng @ 0x2d431c0] chunk too big >>> [apng @ 0x2d44380] chunk too big >>> [apng @ 0x2d45b40] chunk too big >>> [apng @ 0x2d472c0] chunk too big >>> [apng @ 0x2d48a40] chunk too big >>> [apng @ 0x2d4a1c0] chunk too big >>> [apng @ 0x2d4b940] chunk too big >>> [apng @ 0x2d4d0c0] chunk too big >>> [apng @ 0x2d4e840] chunk too big >>> [apng @ 0x2d4ffc0] chunk too big >>> [apng @ 0x2d5fc00] chunk too big >>> [apng @ 0x2d612c0] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d62900] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d431c0] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d44380] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d45b40] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d472c0] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d48a40] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d4a1c0] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >>> [apng @ 0x2d4b940] chunk too big >>> Error while decoding stream #0:0: Invalid data found when processing input >> >> I can't reproduce this. Are you sure it was this patch and not some >> other change in your tree? > > this patch seems to trigger the crash and or some anomalies > valgrind output below. > The exact error differs between valgrind and no valgrind > > > ==3661== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised > byte(s) > ==3661==at 0xC7647D9: sendmmsg (sendmmsg.c:32) > ==3661==by 0x113FFAB0: __libc_res_nsend (res_send.c:1279) > ==3661==by 0x113FCE2B: __libc_res_nquery (res_query.c:227) > ==3661==by 0x113FD862: __libc_res_nsearch (res_query.c:591) > ==3661==by 0x11C1CC72: _nss_dns_gethostbyname4_r (dns-host.c:315) > ==3661==by 0xC735665: gaih_inet (getaddrinfo.c:858) > ==3661==by 0xC73896C: getaddrinfo (getaddrinfo.c:2414) > ==3661==by 0x7D29C5: tcp_open (tcp.c:116) > ==3661==by 0x67A36C: ffurl_connect (avio.c:209) > ==3661==by 0x67AA81: ffurl_open_whitelist (avio.c:345) > ==3661==by 0x83F149: ff_tls_open_underlying (tls.c:107) > ==3661==by 0x7D7D78: tls_open (tls_openssl.c:239) > ==3661==by 0x67A346: ffurl_connect (avio.c:209) > ==3661==by 0x67AA81: ffurl_open_whitelist (avio.c:345) > ==3661==by 0x6C957B: http_open_cnx_internal (http.c:235) > ==3661==by 0x6C9680: http_open_cnx (http.c:262) > ==3661==by 0x6CA560: http_open (http.c:557) > ==3661==by 0x67A346: ffurl_connect (avio.c:209) > ==3661==by 0x67AA81: ffurl_open_whitelist (avio.c:345) > ==3661==by 0x67E88D: ffio_open_whitelist (aviobuf.c:1167) > ==3661== Address 0x7feff9260 is on thread 1's stack > ==3661== Uninitialised value was created by a stack allocation > ==3661==at 0x113FEE6D: __libc_res_nsend (res_send.c:364) > ==3661== > Input #0, apng, from > 'https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png': > Duration: N/A, bitrate: N/A > Stream #0:0: Video: apng, rgba(pc), 100x100, 13.33 fps, 13.33 tbr, 100k > tbn, 100k tbc > Stream mapping: > Stream #0:0 -> #0:0 (apng (native) -> rawvideo (native)) > Press [q] to stop, [?] for help > ==3661== Thread 2: > ==3661== Invalid read of size 4 > ==3661==at 0xB1081F: bytestream_get_be32 (bytestream.h:92) > ==3661==by 0xB10841: bytestream2_get_be32u (bytestream.h:92) > ==3661==by 0xB1088F: bytestream2_get_be32 (bytestream.h:92) > ==3661==by 0xB14FA0: decode_frame_common (pngdec.c:1196) > ==3661==by 0xB1600B: decode_frame_apng (pngdec.c:1490) > ==3661==by 0xB25DA8: frame_worker_thread (pthread_frame.c:201) > ==3661==by 0xC44F183:
Re: [FFmpeg-devel] avcodec/proresenc_aw improvements
On Sat, Jul 21, 2018 at 02:33:24PM +0200, Martin Vignali wrote:
> Hello,
>
> Patch in attach improve some part of the prores_aw encoder.
>
> 001 : use scantable in prores_data instead of a duplicate one.
This could negativly affect the performance of the changed inner loop
have you checked that the changed function does not become slower ?
> 002 : use for the frame header, primaries, transfert, colorspace like in
> proresenc_ks
> avoid color shift on some software (update fate test)
> 003 : change qp start value for each profile based on official encoder
> output
> and update proxy qp end to a bigger value (also based on official encoder
> output)
> (update fate test)
> 004 : calculate dct part before the quantif search. Avoid to recalculate it
> each time
> On a basic test Prores decoding -> prores encoding, the global speed
> improvment is around 2%
>
> This encoder is cover by 4 fate test, can be run with :
> make fate-vsynth3-prores;make fate-vsynth2-prores;make
> fate-vsynth1-prores;make fate-vsynth_lena-prores SAMPLES=fate-suite/
>
> Plan to add later more part from the ks encoder to this one
>
> Martin
[...]
> libavcodec/proresenc_anatoliy.c |6 +++---
> tests/ref/vsynth/vsynth1-prores |2 +-
> tests/ref/vsynth/vsynth2-prores |2 +-
> tests/ref/vsynth/vsynth3-prores |2 +-
> tests/ref/vsynth/vsynth_lena-prores |2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
> f469d157875b5b92fd7053dde08c226296c0cf6b
> 0002-avcodec-proresenc_aw-use-AVframe-primaries-transfert.patch
> From 2891017d83b9a0e10c912d68bc64f67e960bff38 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sat, 21 Jul 2018 14:10:07 +0200
> Subject: [PATCH 2/4] avcodec/proresenc_aw : use AVframe primaries, transfert,
> colorspace for frame header instead of default (unknown, unknown, Rec601)
>
> avoid color shift, on some decoding software
> ---
> libavcodec/proresenc_anatoliy.c | 6 +++---
> tests/ref/vsynth/vsynth1-prores | 2 +-
> tests/ref/vsynth/vsynth2-prores | 2 +-
> tests/ref/vsynth/vsynth3-prores | 2 +-
> tests/ref/vsynth/vsynth_lena-prores | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index dd6b1dcfb1..91b9a17947 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -501,9 +501,9 @@ static int prores_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> bytestream_put_be16(, avctx->height);
> *buf++ = 0x83; // {10}(422){00}{00}(frame){11}
> *buf++ = 0;
> -*buf++ = 2;
> -*buf++ = 2;
> -*buf++ = 6;
> +*buf++ = pict->color_primaries;
> +*buf++ = pict->color_trc;
> +*buf++ = pict->colorspace;
Has someone confirmed that all values our enum contains or will
contain can just be written with no check ?
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext
On Fri, Jul 20, 2018 at 08:30:19PM -0300, James Almer wrote: > On 7/20/2018 8:23 PM, Michael Niedermayer wrote: > > On Thu, Jul 19, 2018 at 10:54:23PM -0300, James Almer wrote: > >> Certain AVCodecParameters, like the contents of the extradata, may be > >> changed > >> by the init() function of any of the bitstream filters in the chain. > >> > >> Signed-off-by: James Almer > >> --- > >> Things worked fine without this until now by pure chance. > >> vp9_superframe_split > >> doesn't use extradata, and those hardware decoders inserting > >> h264_mp4toannexb > >> and hevc_mp4toannexb passed the extradata to functions that could handle it > >> unfiltered. > >> > >> libavcodec/decode.c | 4 > >> 1 file changed, 4 insertions(+) > > > > this breaks: > > ./ffmpeg -i > > https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png > > -bitexact -pix_fmt rgba -f framecrc - > > ... > > [apng @ 0x2d431c0] chunk too big > > [apng @ 0x2d44380] chunk too big > > [apng @ 0x2d45b40] chunk too big > > [apng @ 0x2d472c0] chunk too big > > [apng @ 0x2d48a40] chunk too big > > [apng @ 0x2d4a1c0] chunk too big > > [apng @ 0x2d4b940] chunk too big > > [apng @ 0x2d4d0c0] chunk too big > > [apng @ 0x2d4e840] chunk too big > > [apng @ 0x2d4ffc0] chunk too big > > [apng @ 0x2d5fc00] chunk too big > > [apng @ 0x2d612c0] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d62900] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d431c0] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d44380] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d45b40] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d472c0] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d48a40] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d4a1c0] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > [apng @ 0x2d4b940] chunk too big > > Error while decoding stream #0:0: Invalid data found when processing input > > I can't reproduce this. Are you sure it was this patch and not some > other change in your tree? this patch seems to trigger the crash and or some anomalies valgrind output below. The exact error differs between valgrind and no valgrind ==3661== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==3661==at 0xC7647D9: sendmmsg (sendmmsg.c:32) ==3661==by 0x113FFAB0: __libc_res_nsend (res_send.c:1279) ==3661==by 0x113FCE2B: __libc_res_nquery (res_query.c:227) ==3661==by 0x113FD862: __libc_res_nsearch (res_query.c:591) ==3661==by 0x11C1CC72: _nss_dns_gethostbyname4_r (dns-host.c:315) ==3661==by 0xC735665: gaih_inet (getaddrinfo.c:858) ==3661==by 0xC73896C: getaddrinfo (getaddrinfo.c:2414) ==3661==by 0x7D29C5: tcp_open (tcp.c:116) ==3661==by 0x67A36C: ffurl_connect (avio.c:209) ==3661==by 0x67AA81: ffurl_open_whitelist (avio.c:345) ==3661==by 0x83F149: ff_tls_open_underlying (tls.c:107) ==3661==by 0x7D7D78: tls_open (tls_openssl.c:239) ==3661==by 0x67A346: ffurl_connect (avio.c:209) ==3661==by 0x67AA81: ffurl_open_whitelist (avio.c:345) ==3661==by 0x6C957B: http_open_cnx_internal (http.c:235) ==3661==by 0x6C9680: http_open_cnx (http.c:262) ==3661==by 0x6CA560: http_open (http.c:557) ==3661==by 0x67A346: ffurl_connect (avio.c:209) ==3661==by 0x67AA81: ffurl_open_whitelist (avio.c:345) ==3661==by 0x67E88D: ffio_open_whitelist (aviobuf.c:1167) ==3661== Address 0x7feff9260 is on thread 1's stack ==3661== Uninitialised value was created by a stack allocation ==3661==at 0x113FEE6D: __libc_res_nsend (res_send.c:364) ==3661== Input #0, apng, from 'https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png': Duration: N/A, bitrate: N/A Stream #0:0: Video: apng, rgba(pc), 100x100, 13.33 fps, 13.33 tbr, 100k tbn, 100k tbc Stream mapping: Stream #0:0 -> #0:0 (apng (native) -> rawvideo (native)) Press [q] to stop, [?] for help ==3661== Thread 2: ==3661== Invalid read of size 4 ==3661==at 0xB1081F: bytestream_get_be32 (bytestream.h:92) ==3661==by 0xB10841: bytestream2_get_be32u (bytestream.h:92) ==3661==by 0xB1088F: bytestream2_get_be32 (bytestream.h:92) ==3661==by 0xB14FA0: decode_frame_common (pngdec.c:1196) ==3661==by 0xB1600B: decode_frame_apng (pngdec.c:1490) ==3661==by 0xB25DA8: frame_worker_thread (pthread_frame.c:201) ==3661==by 0xC44F183: start_thread (pthread_create.c:312) ==3661==by 0xC76303C: clone (clone.S:111) ==3661== Address 0x1171d6c0 is 0 bytes inside a block of size 109
[FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file
And add it to the list of configurable components in Makefile, so changes to
the file will be tracked and the usual warning to suggest re-running configure
will be shown.
Signed-off-by: James Almer
---
Makefile | 1 +
configure| 2 +-
libavcodec/Makefile | 1 +
libavcodec/parser.c | 85 --
libavcodec/parsers.c | 106 +++
5 files changed, 109 insertions(+), 86 deletions(-)
create mode 100644 libavcodec/parsers.c
diff --git a/Makefile b/Makefile
index 0cd0a1d6f2..4bf1dfedcf 100644
--- a/Makefile
+++ b/Makefile
@@ -58,6 +58,7 @@ tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)
CONFIGURABLE_COMPONENTS = \
$(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \
$(SRC_PATH)/libavcodec/bitstream_filters.c \
+$(SRC_PATH)/libavcodec/parsers.c\
$(SRC_PATH)/libavformat/protocols.c \
config.h: ffbuild/.config
diff --git a/configure b/configure
index 534c62ed98..741f56d565 100755
--- a/configure
+++ b/configure
@@ -3679,7 +3679,7 @@ CODEC_LIST="
$ENCODER_LIST
$DECODER_LIST
"
-PARSER_LIST=$(find_things_extern parser AVCodecParser libavcodec/parser.c)
+PARSER_LIST=$(find_things_extern parser AVCodecParser libavcodec/parsers.c)
BSF_LIST=$(find_things_extern bsf AVBitStreamFilter
libavcodec/bitstream_filters.c)
HWACCEL_LIST=$(find_things_extern hwaccel AVHWAccel libavcodec/hwaccels.h)
PROTOCOL_LIST=$(find_things_extern protocol URLProtocol
libavformat/protocols.c)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 2d4bc48dab..e62603f0dd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -44,6 +44,7 @@ OBJS = ac3_parser.o
\
options.o\
mjpegenc_huffman.o \
parser.o \
+ parsers.o\
profiles.o \
qsv_api.o\
raw.o\
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index f43b197d5e..0a994a3f30 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -27,95 +27,10 @@
#include "libavutil/avassert.h"
#include "libavutil/internal.h"
#include "libavutil/mem.h"
-#include "libavutil/thread.h"
#include "internal.h"
#include "parser.h"
-/* Parsers */
-extern AVCodecParser ff_aac_parser;
-extern AVCodecParser ff_aac_latm_parser;
-extern AVCodecParser ff_ac3_parser;
-extern AVCodecParser ff_adx_parser;
-extern AVCodecParser ff_bmp_parser;
-extern AVCodecParser ff_cavsvideo_parser;
-extern AVCodecParser ff_cook_parser;
-extern AVCodecParser ff_dca_parser;
-extern AVCodecParser ff_dirac_parser;
-extern AVCodecParser ff_dnxhd_parser;
-extern AVCodecParser ff_dpx_parser;
-extern AVCodecParser ff_dvaudio_parser;
-extern AVCodecParser ff_dvbsub_parser;
-extern AVCodecParser ff_dvdsub_parser;
-extern AVCodecParser ff_dvd_nav_parser;
-extern AVCodecParser ff_flac_parser;
-extern AVCodecParser ff_g729_parser;
-extern AVCodecParser ff_gsm_parser;
-extern AVCodecParser ff_h261_parser;
-extern AVCodecParser ff_h263_parser;
-extern AVCodecParser ff_h264_parser;
-extern AVCodecParser ff_hevc_parser;
-extern AVCodecParser ff_mjpeg_parser;
-extern AVCodecParser ff_mlp_parser;
-extern AVCodecParser ff_mpeg4video_parser;
-extern AVCodecParser ff_mpegaudio_parser;
-extern AVCodecParser ff_mpegvideo_parser;
-extern AVCodecParser ff_opus_parser;
-extern AVCodecParser ff_png_parser;
-extern AVCodecParser ff_pnm_parser;
-extern AVCodecParser ff_rv30_parser;
-extern AVCodecParser ff_rv40_parser;
-extern AVCodecParser ff_sbc_parser;
-extern AVCodecParser ff_sipr_parser;
-extern AVCodecParser ff_tak_parser;
-extern AVCodecParser ff_vc1_parser;
-extern AVCodecParser ff_vorbis_parser;
-extern AVCodecParser ff_vp3_parser;
-extern AVCodecParser ff_vp8_parser;
-extern AVCodecParser ff_vp9_parser;
-extern AVCodecParser ff_xma_parser;
-
-#include "libavcodec/parser_list.c"
-
-static AVOnce av_parser_next_init = AV_ONCE_INIT;
-
-static void av_parser_init_next(void)
-{
-AVCodecParser *prev = NULL, *p;
-int i = 0;
-while ((p = (AVCodecParser*)parser_list[i++])) {
-if (prev)
-prev->next = p;
-prev = p;
-}
-}
-
-AVCodecParser *av_parser_next(const AVCodecParser *p)
-{
-ff_thread_once(_parser_next_init, av_parser_init_next);
-
-if (p)
-return p->next;
-else
-return (AVCodecParser*)parser_list[0];
-}
-
-const AVCodecParser *av_parser_iterate(void **opaque)
-{
-uintptr_t i = (uintptr_t)*opaque;
-const
[FFmpeg-devel] [PATCH] avformat/mov: Check default_encrypted_sample before use in mov_read_sample_encryption_info()
Fixes: 2018-0721-sample
Fixes: null pointer dereference
Found-by: Nikita Knyzhov (knnik...@yandex.ru)
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index eda3fff6d5..edd7778023 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5846,6 +5846,11 @@ static int mov_read_sample_encryption_info(MOVContext
*c, AVIOContext *pb, MOVSt
unsigned int subsample_count;
AVSubsampleEncryptionInfo *subsamples;
+if (!sc->cenc.default_encrypted_sample) {
+av_log(c->fc, AV_LOG_ERROR, "Missing schm or tenc\n");
+return AVERROR_INVALIDDATA;
+}
+
*sample = av_encryption_info_clone(sc->cenc.default_encrypted_sample);
if (!*sample)
return AVERROR(ENOMEM);
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avcodec/proresenc_aw : add support for prores 444
Hello Patch in attach add support for prores 444 profile in AW prores encoder Need to be apply after patch in discussion "avcodec/proresenc_aw improvments" Speed (from prores 422 HQ file -> Prores 444) ./ffmpeg -i prores422hqfile.mov -pix_fmt yuv444p10 -c:v prores -an -profile:v 4 res_aw.mov -y ==> 25 fps ./ffmpeg -i prores422hqfile.mov -pix_fmt yuv444p10 -c:v prores_ks -an -profile:v 4 res_ks.mov -y ==> 10 fps 001 : Add support for Prores 444 (without alpha) 002 : change the frame flag in header part, to be the same than the official encoder in 422 mode (and update fate test) Martin 0005-avcodec-proresenc_aw-add-support-for-prores-444.patch Description: Binary data 0006-avcodec-proresenc_aw-use-for-frame-flag-in-the-heade.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresenc_aw improvements
> > Am I correct that the output files also change? > Patch 002 : change the header of the output file only, not the compress data. Patch 003 : change the output file mainly for near uniform bloc, where the low scale quantif value where used. But IMHO is better by default to be close to official encoding. I can maybe add later an option to let user use another min_quantif_scale in order to use 1 for example if need. Patch 004 : Doesn't change the output file Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/mov: Make auxiliary_offsets consistently size_t.
Hi!
Attached patch fixes a warning on ppc32:
libavformat/mov.c: In function ‘mov_read_saio’:
libavformat/mov.c:6207:45: warning: assignment from incompatible
pointer type [-Wincompatible-pointer-types]
encryption_index->auxiliary_offsets = auxiliary_offsets;
^
Please comment, Carl Eugen
From dd861ac4c0fd18fab88de91a5b91b2114bb4fd89 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 21 Jul 2018 15:47:02 +0200
Subject: [PATCH] lavf/mov: Make auxiliary_offsets consistently size_t.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes a compilation warning if size_t != uint64_t:
libavformat/mov.c: In function ‘mov_read_saio’:
libavformat/mov.c:6207:45: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
encryption_index->auxiliary_offsets = auxiliary_offsets;
^
---
libavformat/mov.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 870c603..061cad0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6138,7 +6138,7 @@ static int mov_read_saiz(MOVContext *c, AVIOContext *pb, MOVAtom atom)
static int mov_read_saio(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
-uint64_t *auxiliary_offsets;
+size_t *auxiliary_offsets;
MOVEncryptionIndex *encryption_index;
MOVStreamContext *sc;
int i, ret;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/escape130: fixes and improvements
2018-07-20 12:31 GMT+02:00, Michael Chaban : > 2018-07-19 21:28 GMT+03:00 Carl Eugen Hoyos : >> The first commit breaks fate, you have to (confirm the fix and) >> change the reference values in the same patch. > > The first commit fixes the wrong decoding which was error in first > place for FFmpeg Escape130 implementation. I understand > The decoded frame examples and RPL video file were presented > in the first message. Yes. > Sorry, It's my first time in contributing to FFmpeg, so I don't > understand what exactly I have to do to make things right. FFmpeg contains a test suite called "fate", you can run it by first downloading the fate samples: $ make SAMPLES=fate-suite fate-rsync And then run the tests: $ make SAMPLES=fate-suite -j2 fate (or make V=1 SAMPLES... to see what's happening) Your commit must not break fate, so you first confirm that the change is intended for the given sample, and then change the actual output with $ make GEN=1 SAMPLES=fate-suite fate-armovie-escape130 > How to confirm the fix and change the reference values? I just meant that you do some basic verification that the change is not unintended for our sample. > 2018-07-19 21:28 GMT+03:00 Carl Eugen Hoyos : >> Is there an alternative to the second patch? Like setting the >> range correctly? > > Actually AVCOL_RANGE_JPEG can made the colorspace visually correct, > since T-REC-T.871 is primarily used by JPEG. But the original decoder > applies additional color patten to solid colour 2x2 pixel blocks (my > commit 3/3). If I use AV_PIX_FMT_YUV420P I cannot apply the same RGB > pattern. In this case I'll have to use Luma pattern instead, which is > little different. What is more inportant: original decoder algorythm > or YUV420P pixel format? My personal opinion is that YUV420P makes more sense but cinepak changed its output to RGB for the same (or a similar) reason so my opinion may not be relevant. It may come down to the question if the difference is (theoretically) visible or not: Off-by-one cannot be visible. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/filters: update info about avgblur filter to make it more understandable
On 20-07-2018 10:01 PM, Danil Iashchenko wrote:
doc/filters: update info about avgblur filter to make it more understandable
---
doc/filters.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 705d48e..e3005c3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5431,13 +5431,13 @@ The filter accepts the following options:
@table @option
@item sizeX
-Set horizontal kernel size.
+Set horizontal radius size.
@item planes
Set which planes to filter. By default all planes are filtered.
@item sizeY
-Set vertical kernel size, if zero it will be same as @code{sizeX}.
+Set vertical radius size, if zero it will be same as @code{sizeX}.
Default is @code{0}.
@end table
LGTM.
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] docs/filters: add documentation to all existing OpenCL filters
I'll review this within a couple of days. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresenc_aw improvements
2018-07-21 14:33 GMT+02:00, Martin Vignali : > Patch in attach improve some part of the prores_aw encoder. > > 001 : use scantable in prores_data instead of a duplicate one. > 002 : use for the frame header, primaries, transfert, colorspace like in > proresenc_ks avoid color shift on some software (update fate test) > 003 : change qp start value for each profile based on official encoder > output and update proxy qp end to a bigger value (also based on > official encoder output) > (update fate test) > 004 : calculate dct part before the quantif search. Avoid to recalculate > it each time > On a basic test Prores decoding -> prores encoding, the global speed > improvment is around 2% Am I correct that the output files also change? What about PSNR or SSIM or visual quality? The reason I ask is that iirc, PSNR was a little worse with ks. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avcodec/proresenc_aw improvements
Hello, Patch in attach improve some part of the prores_aw encoder. 001 : use scantable in prores_data instead of a duplicate one. 002 : use for the frame header, primaries, transfert, colorspace like in proresenc_ks avoid color shift on some software (update fate test) 003 : change qp start value for each profile based on official encoder output and update proxy qp end to a bigger value (also based on official encoder output) (update fate test) 004 : calculate dct part before the quantif search. Avoid to recalculate it each time On a basic test Prores decoding -> prores encoding, the global speed improvment is around 2% This encoder is cover by 4 fate test, can be run with : make fate-vsynth3-prores;make fate-vsynth2-prores;make fate-vsynth1-prores;make fate-vsynth_lena-prores SAMPLES=fate-suite/ Plan to add later more part from the ks encoder to this one Martin 0001-avcodec-proresenc_aw-use-scan-table-from-prores_data.patch Description: Binary data 0002-avcodec-proresenc_aw-use-AVframe-primaries-transfert.patch Description: Binary data 0003-avcodec-proresenc_aw-use-qp-close-to-the-official-en.patch Description: Binary data 0004-avcodec-prores_enc-not-calculate-dct-a-each-quantif.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
