Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

Quoting Nicolas George (2020-02-27 19:44:39) > Vittorio Giovara (12020-02-27): > > joking aside, i see nothing wrong in having a bit more granular libraries, > > subtitle handling could be a good example usecase. > > Seriously? > > $ git grep avpriv | wc -l > 1648 > > This is how much "nothing

Re: [FFmpeg-devel] [PATCH 7/30] avformat/matroskaenc: Avoid allocations for SeekHead

On Tue, Feb 25, 2020 at 2:24 PM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Andreas Rheinhardt: > > Andreas Rheinhardt: > >> Andreas Rheinhardt: > >>> Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the > >>> beginning referencing the main level 1 elements (i.e.

Re: [FFmpeg-devel] [PATCH] lavc/v4l2_context: fix compile warning for incompatible pointer type

On Fri, 28. Feb 00:14, Linjie Fu wrote: > Signed-off-by: Linjie Fu > --- > libavcodec/v4l2_context.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c > index 95a2bfa..8110bbb 100644 > --- a/libavcodec/v4l2_context.c >

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

Quoting Clément Bœsch (2020-02-27 19:36:24) > On Thu, Feb 27, 2020 at 12:35:03PM +0100, Anton Khirnov wrote: > [...] > > AFAIU one of the still-open questions for the subtitle redesign is what > > does it mean to decode or encode a subtitle. > > There are multiple markups available for text

[FFmpeg-devel] [PATCH] avformat/mxfenc: Never set codec_ul UID to NULL

mxf distinguishes codec profiles by different UIDs and therefore needs to check that the input is actually compatible with mxf (i.e. if there is a defined UID for it). If not, then sometimes the UID would be set to NULL and writing the (video) packet would fail. Yet the following audio packet

[FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

Fixes ticket #8523. Signed-off-by: Marton Balint --- libavformat/mxf.c | 13 + 1 file changed, 13 insertions(+) diff --git a/libavformat/mxf.c b/libavformat/mxf.c index 14056647c5..987410258a 100644 --- a/libavformat/mxf.c +++ b/libavformat/mxf.c @@ -135,10 +135,23 @@ static const

[FFmpeg-devel] [PATCH 3/4] avformat/mxfenc: move content package rates and timebase combinations to a separate struct

Signed-off-by: Marton Balint --- libavformat/mxf.c | 28 libavformat/mxf.h | 5 + 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/libavformat/mxf.c b/libavformat/mxf.c index 10ccd770e3..14056647c5 100644 --- a/libavformat/mxf.c +++

[FFmpeg-devel] [PATCH 2/4] avformat/mxf: get rid of samples per frame array usage

Signed-off-by: Marton Balint --- libavformat/mxf.c| 44 libavformat/mxf.h| 6 -- libavformat/mxfdec.c | 23 +++ libavformat/mxfenc.c | 24 ++-- 4 files changed, 13 insertions(+), 84 deletions(-)

[FFmpeg-devel] [PATCH 1/4] avformat/audiointerleave: disallow using a samples_per_frame array

Only MXF used an actual sample array, and that is unneeded there because simple rounding rules can be used instead. Signed-off-by: Marton Balint --- libavformat/audiointerleave.c | 24 ++-- libavformat/audiointerleave.h | 7 --- libavformat/gxfenc.c | 2 +-

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

On Thu, Feb 27, 2020, at 19:44, Nicolas George wrote: > On the other side, would you be able to quote only one actual, practical > benefit of having several libraries instead of one that could not be > achieved more simply with configure options? I suspect not, because I > have looked for them and

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: Improve the position determination for avpriv_mpegts_parse_packet()

On Mon, Jan 27, 2020 at 07:21:16PM +0100, Michael Niedermayer wrote: > Fixes: assertion failure > Fixes: Ticket 8005 > > Signed-off-by: Michael Niedermayer > --- > libavformat/mpegts.c | 8 +++- > 1 file changed, 3 insertions(+), 5 deletions(-) will apply [...] -- Michael GnuPG

Re: [FFmpeg-devel] [PATCH] libavformat/avienc: Check bits per sample for PAL8

On Sun, Jan 26, 2020 at 11:06:53PM +0100, Michael Niedermayer wrote: > Fixes: assertion failure > Fixes: Ticket 8172 > > Signed-off-by: Michael Niedermayer > --- > libavformat/avienc.c | 8 > 1 file changed, 8 insertions(+) will apply [...] -- Michael GnuPG fingerprint:

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegaudioenc_template: fix invalid shift of sample

On Thu, Jan 23, 2020 at 01:03:11PM +0100, Michael Niedermayer wrote: > Fixes: Ticket8010 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpegaudioenc_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint:

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

On 2/27/2020 3:45 PM, Carl Eugen Hoyos wrote: > Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer : >> >> On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote: >>> Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer : This set follows the same logic as 061a0c14bb, but for the encode API:

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

Am Do., 27. Feb. 2020 um 19:32 Uhr schrieb James Almer : > > On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote: > > Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer : > >> > >> This set follows the same logic as 061a0c14bb, but for the encode API: The > >> new public API will no longer be a

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

Vittorio Giovara (12020-02-27): > joking aside, i see nothing wrong in having a bit more granular libraries, > subtitle handling could be a good example usecase. Seriously? $ git grep avpriv | wc -l 1648 This is how much "nothing wrong" we already have because the libraries are split. And

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

On Thu, Feb 27, 2020 at 07:36:24PM +0100, Clément Bœsch wrote: [...] > And then you can't have them in libavfilter, so you can't have a sane > harmony with medias including subtitle streams. It's problematic with many > basic use cases. One random example: if you're transcoding an audio/video >

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

On Thu, Feb 27, 2020 at 12:35:03PM +0100, Anton Khirnov wrote: [...] > AFAIU one of the still-open questions for the subtitle redesign is what > does it mean to decode or encode a subtitle. There are multiple markups available for text subtitles, and there are multiple ways of representing

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

On 2/27/2020 3:22 PM, Carl Eugen Hoyos wrote: > Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer : >> >> This set follows the same logic as 061a0c14bb, but for the encode API: The >> new public API will no longer be a wrapper around the old deprecated one, and >> the internal API used by the

Re: [FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

Am Do., 27. Feb. 2020 um 19:11 Uhr schrieb James Almer : > > This set follows the same logic as 061a0c14bb, but for the encode API: The > new public API will no longer be a wrapper around the old deprecated one, and > the internal API used by the encoders now consists of a single >

[FFmpeg-devel] [PATCH] [PATCH] avcodec: Fix h264_videotoolbox writing b-frames (fix ticket #8353)

Signed-off-by: Nomis101 --- libavcodec/videotoolboxenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c index cc08cf6a50..32d893e485 100644 --- a/libavcodec/videotoolboxenc.c +++ b/libavcodec/videotoolboxenc.c @@ -1355,6 +1355,7 @@

[FFmpeg-devel] [WIP][PATCH 0/4] Encoding API code restructuration

This set follows the same logic as 061a0c14bb, but for the encode API: The new public API will no longer be a wrapper around the old deprecated one, and the internal API used by the encoders now consists of a single receive_packet() callback that pulls frames as required. Because of the above,

[FFmpeg-devel] [PATCH 3/4] avcodec/encode: restructure the old encode API

Following the same logic as 061a0c14bb, this commit turns the old encode API into a wrapper for the new one. Signed-off-by: James Almer --- This could be squashed with the previous commit, like it was done in 061a0c14bb, but i figured it would be easier to review this way. libavcodec/encode.c

[FFmpeg-devel] [PATCH 4/4] avcodec/librav1e: adapt to the new internal encode API

Signed-off-by: James Almer --- Must be squashed into PATCH 2/2 libavcodec/librav1e.c | 65 --- 1 file changed, 36 insertions(+), 29 deletions(-) diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c index b8b1b4f8f1..02e9c0902f 100644 ---

[FFmpeg-devel] [PATCH 2/4] avcodec/encode: restructure the core encoding code

This commit follows the same logic as 061a0c14bb, but for the encode API: The new public encoding API will no longer be a wrapper around the old deprecated one, and the internal API used by the encoders now consists of a single receive_packet() callback that pulls frames as required.

[FFmpeg-devel] [PATCH 1/4] avcodec: move avcodec_flush_buffers from decode.c to utils.c

It's not a decoding exclusive function. Signed-off-by: James Almer --- libavcodec/decode.c | 36 libavcodec/utils.c | 33 + 2 files changed, 33 insertions(+), 36 deletions(-) diff --git a/libavcodec/decode.c

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

On Thu, Feb 27, 2020, at 18:33, Michael Niedermayer wrote: > > > I agree that the current QP code (not feature) should be deprecated as it > > > does not work with newer codec. > > > But before removing the deprecated code, it will be nice to have the same > > > feature available with a newer API,

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

On Thu, Feb 27, 2020 at 12:30:22PM +0100, Anton Khirnov wrote: > Quoting Thierry Foucu (2020-02-26 19:04:57) > > First of all, thanks for trying to clean up deprecated API > > > > On Wed, Feb 26, 2020 at 6:03 AM Jean-Baptiste Kempf > > wrote: > > > > > Yo, > > > > > > On Wed, Feb 26, 2020, at

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

On Thu, Feb 27, 2020 at 10:41 AM Hendrik Leppkes wrote: > On Thu, Feb 27, 2020 at 12:35 PM Anton Khirnov wrote: > > > > Quoting Hendrik Leppkes (2020-02-27 12:27:09) > > > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov > wrote: > > > > Why does it need to be within AVFrame? I am still

Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

> -Original Message- > From: ffmpeg-devel On Behalf Of Fu, > Linjie > Sent: Tuesday, February 18, 2020 23:06 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > >

[FFmpeg-devel] [PATCH] lavc/v4l2_context: fix compile warning for incompatible pointer type

Signed-off-by: Linjie Fu --- libavcodec/v4l2_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c index 95a2bfa..8110bbb 100644 --- a/libavcodec/v4l2_context.c +++ b/libavcodec/v4l2_context.c @@ -48,7 +48,7 @@ static

[FFmpeg-devel] [PATCH 3/3] fftools/ffmpeg: check caps of encoders for encoding frame with variable dimension

This ensures that an encoder is able to cope with input frames with changing resolution only if it declares the capability of AV_CODEC_CAP_VARIABLE_DIMENSIONS. Signed-off-by: Linjie Fu --- fftools/ffmpeg.c | 9 + 1 file changed, 9 insertions(+) diff --git a/fftools/ffmpeg.c

[FFmpeg-devel] [PATCH 2/3] lavc/avcodec.h: add an AVCodecContext flag to indicate caps of encoding

Signed-off-by: Linjie Fu --- doc/APIchanges | 3 +++ fftools/cmdutils.c | 2 ++ libavcodec/avcodec.h | 9 - libavcodec/rawenc.c | 1 + libavcodec/version.h | 2 +- 5 files changed, 15 insertions(+), 2 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index

[FFmpeg-devel] [PATCH 1/3] lavc/avcodec.h: fix missing line breaks in API documentation

"In both cases.." and "Repeat this call until.." would be better to be in a separate line. http://ffmpeg.org/doxygen/trunk/group__lavc__encdec.html Signed-off-by: Linjie Fu --- libavcodec/avcodec.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/avcodec.h

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

On Thu, Feb 27, 2020 at 12:35 PM Anton Khirnov wrote: > > Quoting Hendrik Leppkes (2020-02-27 12:27:09) > > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov wrote: > > > Why does it need to be within AVFrame? I am still unconvinced that is a > > > good idea. What do we gain from storing them in

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check for Tiled and Stripped TIFFs

On 2/27/2020 11:10 AM, Carl Eugen Hoyos wrote: > Am Do., 27. Feb. 2020 um 15:05 Uhr schrieb Anton Khirnov : >> >> Quoting Michael Niedermayer (2020-02-19 16:49:51) >>> TIFF 6 spec: "Do not use both strip-oriented and tile-oriented fields in >>> the same TIFF file." >>> >>> Fixes: null pointer

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check for Tiled and Stripped TIFFs

Am Do., 27. Feb. 2020 um 15:05 Uhr schrieb Anton Khirnov : > > Quoting Michael Niedermayer (2020-02-19 16:49:51) > > TIFF 6 spec: "Do not use both strip-oriented and tile-oriented fields in > > the same TIFF file." > > > > Fixes: null pointer use, crash > > Fixes:

Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check for Tiled and Stripped TIFFs

Quoting Michael Niedermayer (2020-02-19 16:49:51) > TIFF 6 spec: "Do not use both strip-oriented and tile-oriented fields in the > same TIFF file." > > Fixes: null pointer use, crash > Fixes: crash-762680f9d1b27f9b9085e12887ad44893fb2b020 > > Found-by: Shiziru > Signed-off-by: Michael

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

February 27, 2020 6:15 PM, "Moritz Barsnick" wrote: >> OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \ >> vorbis_data.o >> +OBJS-$(CONFIG_FLAC_PARSER) += flif16_parser.o > > > > This looks wrong. You are adding this object to a compile of the FLAC > parser, not your new

Re: [FFmpeg-devel] [PATCH v8] avfilter/avf_aphasemeter: Add out of phase and mono detection

Le mar. 24 déc. 2019 à 17:36, Romane Lafon a écrit : > I rewrote the patch I submitted a few months ago. > This patch extends aphasemeter to detect out of phase or mono sequences in > stereo streams. > > Regards, > Romane > Ping for review. Thanks, Romane

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

Welcome to ffmpeg! Since review has now started, I want to point out what was missed: On Wed, Feb 26, 2020 at 12:26:37 +0530, Anamitra Ghorui wrote: > a. Please tell me if I am right or wrong here: > 1. Each audio/video/image file format has a parser for converting the >file data into a

Re: [FFmpeg-devel] [PATCH] avformat/mux: allow non-monotonic ts with AVFMT_NOTIMESTAMPS

Quoting Andreas Rheinhardt (2020-02-26 16:06:00) > Anssi Hannula: > > Allow non-monotonic input timestamps for muxers with no timestamps at > > all (AVFMT_NOTIMESTAMPS). > > > > This is frequently hit when muxing TrueHD with spdifenc as many MKV > > files use 1ms timestamps while TrueHD frames

Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: Count last partial frame in probe.

Quoting Michael Niedermayer (2020-02-26 19:15:03) > Fixes: regression > Fixes: Ticket8511 > > Signed-off-by: Michael Niedermayer > --- > libavformat/mp3dec.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c >

Re: [FFmpeg-devel] [PATCH 3/3 v2] avformat/dashenc: always attempt to enable prft on ldash mode

Quoting James Almer (2020-02-26 01:28:48) > On 2/24/2020 6:54 AM, Anton Khirnov wrote: > > Quoting James Almer (2020-02-20 17:26:00) > >> Signed-off-by: James Almer > > > > Commit message is now misleading since it will only enable prft if it's > > not disabled. > > Sorry, i pushed this during

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

Quoting Hendrik Leppkes (2020-02-27 12:27:09) > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov wrote: > > Why does it need to be within AVFrame? I am still unconvinced that is a > > good idea. What do we gain from storing them in the same struct? > > It makes sense for audio and video, because

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

On Thu, Feb 27, 2020, at 12:30, Anton Khirnov wrote: > > Today, for example, when we want to visualize QP, we use libavcodec to > > decode the frame, use another piece of code to extract the QP and overlay > > both of them. This is almost (and i say ALMOST) decoding the frame twice. > > (BTW, we

Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

Quoting Thierry Foucu (2020-02-26 19:04:57) > First of all, thanks for trying to clean up deprecated API > > On Wed, Feb 26, 2020 at 6:03 AM Jean-Baptiste Kempf wrote: > > > Yo, > > > > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote: > > > > The patch in your link is not using this API.

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov wrote: > > Quoting Clément Bœsch (2020-02-25 18:40:13) > > On Sun, Feb 23, 2020 at 09:59:59PM +0100, Michael Niedermayer wrote: > > [...] > > > > The subtitles refactor requires to see the big picture and all the > > > > problems at > > > > once. >

Re: [FFmpeg-devel] [PATCH 01/12] fifo: uninline av_fifo_peek2() on the next major bump

Quoting James Almer (2020-02-25 22:28:57) > On 2/24/2020 9:37 AM, Anton Khirnov wrote: > > This patch will need a following one after the bump to remove dead code, > so IMO might as well just do this in one commit after the bump and save > all the ifdeffery. Sure, that makes sense. -- Anton

Re: [FFmpeg-devel] Status and Plans for Subtitle Filters

Quoting Clément Bœsch (2020-02-25 18:40:13) > On Sun, Feb 23, 2020 at 09:59:59PM +0100, Michael Niedermayer wrote: > [...] > > > The subtitles refactor requires to see the big picture and all the > > > problems at > > > once. > > > > really ? > > just hypothetically, and playing the devils

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

Hi Anamitra, On Wed, Feb 26, 2020 at 12:26:37PM +0530, Anamitra Ghorui wrote: This is a buildable "skeleton" of my component (the FLIF16 parser) i.e. everything is present aside from the logic itself. *** Hello, I am trying to implement a parser for the FLIF16 file format as a GSoC 2020

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

Am 27.02.20 um 11:56 schrieb Lynne: > Feb 27, 2020, 09:09 by agho...@teknik.io: > >> February 26, 2020 12:27 PM, "Anamitra Ghorui" wrote: >> >>> c. I have been looking at the decoder/encoder/parser of the BMP format >>> (which is one of the simplest image formats), the actual decoding work >>>

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

Feb 27, 2020, 09:09 by agho...@teknik.io: > February 26, 2020 12:27 PM, "Anamitra Ghorui" wrote: > >> c. I have been looking at the decoder/encoder/parser of the BMP format >> (which is one of the simplest image formats), the actual decoding work >> (according to me), i.e. Finding the magic

Re: [FFmpeg-devel] Two weird requests

tor 2020-02-27 klockan 00:03 -0800 skrev Unidef Defshrizzle: > Could you integrate this code into ffmpeg? > > > https://unidef.org/wp-content/uploads/2019/12/qlib.zip < > https://unidef.org/wp-content/uploads/2019/12/qlib.zip> It doesn't compile. Additionally: > General Purpose Quantum

Re: [FFmpeg-devel] [PATCH] [RFC] GSoC: FLIF16 Image format parser

February 26, 2020 12:27 PM, "Anamitra Ghorui" wrote: > c. I have been looking at the decoder/encoder/parser of the BMP format > (which is one of the simplest image formats), the actual decoding work > (according to me), i.e. Finding the magic numbers, seeing the various > segments is being done

Re: [FFmpeg-devel] [PATCH 1/2] avformat/ivfenc: Don't use size_t for size of file

lgtm On 2/27/20, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavformat/ivfenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c > index eb70421c44..45e5b238dc 100644 > --- a/libavformat/ivfenc.c >

[FFmpeg-devel] Two weird requests

Could you integrate this code into ffmpeg? https://unidef.org/wp-content/uploads/2019/12/qlib.zip And with bitshifting, there needs to be a master function I dont know the bit shifting code well, but I can try Void frame(FSTRUCT