MattKC:
> ==Summary==
>
> I've been implementing ffmpeg/libav into an application, and have run
> into timing-related issues when playing back Matroska/MKV videos created
> by my application in VLC. I tried asking about this on the libav-user
> mailing list and received no response so I thought
On 2021-08-06 11:34 pm, James Almer wrote:
From: Matthieu Patou
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
fftools/cmdutils.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 912e881174..fc58277df7
==Summary==
I've been implementing ffmpeg/libav into an application, and have run
into timing-related issues when playing back Matroska/MKV videos created
by my application in VLC. I tried asking about this on the libav-user
mailing list and received no response so I thought I'd try here.
Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
value_len > UINT16_MAX.
As a consequence, attached images of sizes larger than UINT16_MAX could no
longer be read.
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 2 +-
1 file changed, 1 insertion(+), 1
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Sunday, 8 August 2021 03:19
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
> bug when reading image attachments
>
> On 8/7/2021 10:00 PM, Soft Works
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Sunday, 8 August 2021 03:19
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
> bug when reading image attachments
>
> On 8/7/2021 10:00 PM, Soft Works
On 8/7/2021 10:00 PM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
James Almer
Sent: Sunday, 8 August 2021 02:47
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
bug when reading image attachments
On 8/7/2021
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Sunday, 8 August 2021 03:03
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
> bug when reading image
Am So., 8. Aug. 2021 um 03:00 Uhr schrieb Soft Works :
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > James Almer
> > Sent: Sunday, 8 August 2021 02:47
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
> > bug
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Sunday, 8 August 2021 02:47
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
> bug when reading image attachments
>
> On 8/7/2021 9:38 PM, Soft Works
Am Sa., 7. Aug. 2021 um 18:14 Uhr schrieb James Almer :
>
> On 8/7/2021 1:06 PM, Derek Buitenhuis wrote:
> > On 8/6/2021 7:04 PM, James Almer wrote:
> >> From: Matthieu Patou
> >>
> >> Suggested-by: ffm...@fb.com
> >> Signed-off-by: James Almer
> >> ---
> >> fftools/cmdutils.c | 5 +++--
> >>
On 8/7/2021 9:38 PM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Carl Eugen Hoyos
Sent: Sunday, 8 August 2021 01:58
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
bug when reading image
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Sunday, 8 August 2021 01:58
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression
> bug when reading image
Am So., 8. Aug. 2021 um 01:33 Uhr schrieb Carl Eugen Hoyos :
>
> Am So., 8. Aug. 2021 um 01:26 Uhr schrieb Soft Works :
> >
> > Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
> > value_len > UINT16_MAX.
> > As a consequence, attached images of sizes larger than
Am So., 8. Aug. 2021 um 01:53 Uhr schrieb Soft Works :
>
> Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
> value_len > UINT16_MAX.
> As a consequence, attached images of sizes larger than UINT16_MAX could no
> longer be read.
>
> Signed-off-by: softworkz
> ---
> v2:
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Sunday, 8 August 2021 01:53
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] libavformat/asfdec: Fix regression bug
> when reading image attachments
>
> Commit
Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
value_len > UINT16_MAX.
As a consequence, attached images of sizes larger than UINT16_MAX could no
longer be read.
Signed-off-by: softworkz
---
v2: Fix without changing variable type
libavformat/asfdec_f.c | 2 +-
1
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Sunday, 8 August 2021 01:33
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] libavformat/asfdec: Fix regression bug
> when reading image attachments
>
Am Do., 5. Aug. 2021 um 11:03 Uhr schrieb Michael Krebs
:
>
> * Let older tags on the same place as originally
> * Add new fate tests for rawvideo and v210 and update checksum for mxf tests
This commit message indicates that the patch should be split.
Carl Eugen
On 03.08.2021 17:14, Ricardo Monteiro wrote:
Hi Timo,
I do wonder if that information isn't (also) available via metadata on
the incoming frames, so it could be inferred from those by default.
Are you talking about a transcoding scenario? Where you would load the
parameters from the input
Am So., 8. Aug. 2021 um 01:26 Uhr schrieb Soft Works :
>
> Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
> value_len > UINT16_MAX.
> As a consequence, attached images of sizes larger than UINT16_MAX could no
> longer be read.
>
> Signed-off-by: softworkz
> ---
>
Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check for
value_len > UINT16_MAX.
As a consequence, attached images of sizes larger than UINT16_MAX could no
longer be read.
Signed-off-by: softworkz
---
libavformat/asfdec_f.c | 7 ---
1 file changed, 4 insertions(+), 3
On 8/7/2021 6:54 PM, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
This is in reply to James' opinion here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283267.html
libavcodec/ass_split.c | 2 +-
libavcodec/ass_split.h | 4 ++--
libavcodec/movtextenc.c | 2 +-
Andreas Rheinhardt:
> The function definition used float *data_buf[14], although there are
> only 13 elements (and only 13 are used); the declaration used 13.
> Given that the type will be converted to float **data_buf anyway,
> this is not in violation of the C specs, but nevertheless a bug.
>
>
Signed-off-by: Andreas Rheinhardt
---
This is in reply to James' opinion here:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283267.html
libavcodec/ass_split.c | 2 +-
libavcodec/ass_split.h | 4 ++--
libavcodec/movtextenc.c | 2 +-
libavcodec/srtenc.c | 2 +-
libavcodec/ttmlenc.c
On 8/6/2021 10:47 PM, Andreas Rheinhardt wrote:
Unused since 1f63665ca567fbc49fa80166d468a822c2999efa.
Signed-off-by: Andreas Rheinhardt
---
Shall I rename ff_ass_split_dialogue2 to ff_ass_split_dialogue?
IMO, yes.
libavcodec/ass_split.c | 19 ---
libavcodec/ass_split.h
Andreas Rheinhardt:
> The flite filter apparently only wanted to declare a struct,
> but mistakenly also defined an unused and zero-initialized element
> with external linkage.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Would not have happened if one had actually defined a typedef.
>
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Saturday, 7 August 2021 13:51
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] doc/developer: Add description
> about safely sending patches via E-Mail clients
>
> Soft Works:
> >
Signed-off-by: softworkz
---
v3: fixed typo
doc/developer.texi | 16
1 file changed, 16 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index b33cab0fc7..86f63c49b3 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -494,6 +494,22 @@ patch is inline
On Sat, Aug 07, 2021 at 06:15:05PM +0800, Linjie Fu wrote:
> From: Linjie Fu
>
> This reverts commit b3a0548a981db52911dd34d9de254c4fee0a8f79.
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who would give up essential Liberty, to purchase a
On Fri, Aug 06, 2021 at 06:17:25PM +0200, Andreas Rheinhardt wrote:
> Before 3793caa5e2d1d16ed45771574b2ffc932497cfcf the code was
> "if (...) do { ... } while (...);". After said commit this became
> "if (...) av_assert0(...); do { ... } while (...);", i.e. the loop
> is always executed. This
On Sat, 7 Aug 2021, Michael Niedermayer wrote:
On Sat, Aug 07, 2021 at 09:21:36AM +0200, Marton Balint wrote:
On Fri, 6 Aug 2021, Michael Niedermayer wrote:
On Mon, Aug 02, 2021 at 08:50:05PM +0200, Marton Balint wrote:
Also split error message to error and warning.
Signed-off-by:
On Fri, 6 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/indevs.texi | 16 +++-
doc/outdevs.texi| 16 +++-
libavdevice/decklink_common.cpp | 8
libavdevice/decklink_common.h | 11
On Sat, Aug 07, 2021 at 09:21:36AM +0200, Marton Balint wrote:
>
>
> On Fri, 6 Aug 2021, Michael Niedermayer wrote:
>
> > On Mon, Aug 02, 2021 at 08:50:05PM +0200, Marton Balint wrote:
> > > Also split error message to error and warning.
> > >
> > > Signed-off-by: Marton Balint
> > > ---
> >
On Fri, 6 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
just rebase the code to the master branch to fix the first warning.
doc/outdevs.texi| 4
libavdevice/decklink_common.cpp | 17 +
On Fri, 6 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/outdevs.texi| 4
libavdevice/decklink_common.cpp | 11 +++
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_enc_c.c| 1 +
4 files changed, 17
On Fri, 6 Aug 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/outdevs.texi| 5 +
libavdevice/decklink_common.cpp | 9 +
libavdevice/decklink_common.h | 8
libavdevice/decklink_common_c.h | 1 +
On 8/7/2021 1:17 PM, Derek Buitenhuis wrote:
On 8/7/2021 5:13 PM, James Almer wrote:
It's just to reduce the amount of information printed by default. Most
command line utilities don't bother showing build time configuration
options outside of --version or --help output, if at all.
And the
On 8/7/2021 5:13 PM, James Almer wrote:
> It's just to reduce the amount of information printed by default. Most
> command line utilities don't bother showing build time configuration
> options outside of --version or --help output, if at all.
> And the string is obviously in the binary
On 8/7/2021 1:06 PM, Derek Buitenhuis wrote:
On 8/6/2021 7:04 PM, James Almer wrote:
From: Matthieu Patou
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
fftools/cmdutils.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
What exactly is the point of this?
You've
On 8/6/2021 7:04 PM, James Almer wrote:
> From: Matthieu Patou
>
> Suggested-by: ffm...@fb.com
> Signed-off-by: James Almer
> ---
> fftools/cmdutils.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
What exactly is the point of this?
You've provided a patch with no explanation
Linjie Fu:
> From: Linjie Fu
>
> To pass the swscale options for the inserted scalers.
>
> ffmpeg -i input.mp4 -filter_complex \
> "scale_sws_opts=alphablend=checkerboard;format=nv12" \
> -t 0.5 output.mp4
>
> Update docs.
>
> Signed-off-by: Linjie Fu
> ---
> doc/filters.texi
Linjie Fu:
> From: Linjie Fu
>
> Printed verbose log doesn't match the sws_flags specified in the cmdline
> for simple filter graph.
>
> ffmpeg .. -sws_flags bicubic ..
> [auto_scaler_0] w:iw h:ih flags:'' interl:0
> [auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449
Soft Works:
> (v2: fix doc build)
This should be directly after the --- below.
>
> Signed-off-by: softworkz
> ---
> doc/developer.texi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index b33cab0fc7..ce5500b85d 100644
>
On Sat, Aug 7, 2021 at 2:33 AM Michael Niedermayer
wrote:
> On Thu, Aug 05, 2021 at 02:30:32PM +, Linjie Fu wrote:
> > ffmpeg | branch: master | Linjie Fu | Sun
> Aug 1 18:58:19 2021 +0800| [b3a0548a981db52911dd34d9de254c4fee0a8f79] |
> committer: Linjie Fu
> >
> > fftools/ffmpeg_filter:
From: Linjie Fu
To pass the swscale options for the inserted scalers.
ffmpeg -i input.mp4 -filter_complex \
"scale_sws_opts=alphablend=checkerboard;format=nv12" \
-t 0.5 output.mp4
Update docs.
Signed-off-by: Linjie Fu
---
doc/filters.texi | 7 ---
From: Linjie Fu
Printed verbose log doesn't match the sws_flags specified in the cmdline
for simple filter graph.
ffmpeg .. -sws_flags bicubic ..
[auto_scaler_0] w:iw h:ih flags:'' interl:0
[auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449 fmt:yuv420p
sar:0/1 flags:0x0
From: Linjie Fu
This reverts commit b3a0548a981db52911dd34d9de254c4fee0a8f79.
This breaks the usage of swscale options, scale_sws_opts should be passed
to auto-inserted scale-filters.
The auto-inserted scaler accepts sws_flags in filtergraph complex which
overrides the 'flags' option for
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Saturday, 7 August 2021 08:52
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avutils/hwcontext: When deriving a
> hwdevice, search for existing
On Fri, 6 Aug 2021, Michael Niedermayer wrote:
On Mon, Aug 02, 2021 at 08:50:05PM +0200, Marton Balint wrote:
Also split error message to error and warning.
Signed-off-by: Marton Balint
---
libavcodec/mpeg12dec.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff
On Sat, Aug 7, 2021 at 3:46 AM Soft Works wrote:
>
> The test /libavutil/tests/hwdevice checks that when deriving a device
> from a source device and then deriving back to the type of the source
> device, the result is matching the original source device, i.e. the
> derivation mechanism doesn't
51 matches
Mail list logo
