Den måndag 26 februari 2024 kl. 19:36:58 CET, Kristoffer Brånemyr via
ffmpeg-devel skrev:
>Hi,
>Here is a short patch to skip more parts of the header for the WebVTT subtitle
>format. Without this the parser seems to stop and no subtitles are produced
>for the user.You can find the WebVTT
On Mon, Mar 11, 2024 at 11:16:06AM +0100, Nicolas Gaullier wrote:
> Signed-off-by: Nicolas Gaullier
> ---
> doc/fate.texi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/fate.texi b/doc/fate.texi
> index 2fa8c34c2d..2fa7c70251 100644
> --- a/doc/fate.texi
> +++
Both of these two structures were first available with X264_BUILD
163, so make relevant functionality conditional on the version
being at least such.
Keep handle_side_data available in all cases as this way X264_init
does not require additional version based conditions within it.
Finally, add a
The newer of these two are the separate integers for content light
level, introduced in 3952bf3e98c76c31594529a3fe34e056d3e3e2ea ,
with X265_BUILD 75. As we already require X265_BUILD of at least
89, no further conditions are required.
---
libavcodec/libx265.c | 88
Hi Andrew,
Sorry, it took me some time to author DVDs to test this but I finally got
around to it.
DVD player # 1 (DVD only) -- pass for both 32k and 44.1k
DVD player # 2 (4K/BD/DVD) -- pass for both 32k and 44.1k
Interestingly, DVD player # 2 OSD showed sample rate as 48k but anyways it
played
On Sun, Mar 10, 2024 at 07:40:47PM -0500, Marth64 wrote:
> Currently, Closed Captions decoder prints multiple \pos ASS tags per line,
> per cue. This is invalid behavior, because only the first \pos tag in a cue
> is honored by ASS anyway. Don't write multiple \pos tags.
>
> Signed-off-by:
On 3/11/24 17:48, Marth64 wrote:
This breaks fate
Looking into it - thanks.
It is possible that the change is correct, and that the fate test needs
to be changed to reflect the correct behavior. Not necessarily, but
possibly.
- Leo Izen (Traneptora)
OpenPGP_signature.asc
Description:
On 3/9/24 20:25, Michael Niedermayer wrote:
Hi everyone
Some members of the CC want to indefinitely ban Balling
from trac. And as our doc/community.texi says:
"Indefinite bans from the community must be confirmed by the General Assembly, in a
majority vote."
Thus some CC member wishes to
On 3/11/2024 2:44 PM, Allan Cady via ffmpeg-devel wrote:
Could someone please have a look at an issue I'm having in resubmitting a
patch, trying to get the resubmission email to appear as a reply on an existing
thread? In order to conform to submission guidelines in ffmpeg-devel, I'm using
VVC's subpictures feature is not yet implemented in the native decoder.
Throw an AVERROR_PATCHWELCOME when trying to decode a bitstream using
the feature. Fixes crashes when trying to decode bitstreams which
use the feature.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvc_ps.c | 15
---
libavutil/frame.c | 5 +
libavutil/frame.h | 11 +++
2 files changed, 16 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index ab425b2235..baac0706db 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -78,6 +78,11 @@ static void
Differences to v7:
1. rebased on top of current master
2. Applied various review comments.
Comparison URL (mostly configure and wrappers, avutil/frame.c):
https://github.com/jeeb/ffmpeg/compare/avcodec_cll_mdcv_side_data_v7..avcodec_cll_mdcv_side_data_v8
This patch set I've now been working for
Additionally, add an API test to check that the no-duplicates
addition works after duplicates have been inserted.
---
libavutil/Makefile | 1 +
libavutil/frame.c | 17 ++
libavutil/frame.h | 22 +++
libavutil/tests/side_data_set.c | 103
This will make it possible to to reuse logic in further commits.
---
libavutil/frame.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 079cf6595b..ab425b2235 100644
--- a/libavutil/frame.c
+++
---
libavutil/frame.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index baac0706db..9ebe830c5c 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -679,23 +679,23 @@ AVBufferRef
This will make it possible to reuse logic in further commits.
---
libavutil/frame.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9ebe830c5c..dd27456031 100644
--- a/libavutil/frame.c
+++
---
libavutil/frame.c | 49 +++
libavutil/frame.h | 20 +++
2 files changed, 69 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 4074391a92..46f976a3ed 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@
> This breaks fate
Looking into it - thanks.
PS, sorry for previous top-posting in replies. Will be more cautious of
that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
On 08/03/2024 13:44, Niklas Haas wrote:
On Fri, 08 Mar 2024 10:31:28 -0300 James Almer wrote:
On 3/8/2024 10:21 AM, Niklas Haas wrote:
From: Niklas Haas
Implementation copied wholesale from dav1d, sans SIMD, under permissive
license. This implementation was extensively verified to be
On 11 Mar 2024, at 15:26, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> Allan Cady via ffmpeg-devel:
>>> From: "Allan Cady"
>>>
>>> I propose changing the format to "%.6f", which will
>>> give microsecond precision for all timestamps, regardless of
>>> offset. Trailing zeros can be
This allows API clients that wish to configure multiple entries
at a time to do so without writing the looping code themselves.
---
libavcodec/avcodec.c | 30 ++
libavcodec/avcodec.h | 21 +
2 files changed, 51 insertions(+)
diff --git
This enables further configuration of output based on the results
of input decoding and filtering in a similar manner as the color
information.
---
fftools/ffmpeg_enc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index
These two were added in 28e23d7f348c78d49a726c7469f9d4e38edec341
and 3558c1f2e97455e0b89edef31b9a72ab7fa30550 for version 0.9.0 of
SVT-AV1, which is also our minimum requirement right now.
In other words, no additional version limiting conditions seem
to be required.
Additionally, add a FATE
This allows configuring an encoder by using AVFrameSideData.
---
libavcodec/avcodec.h | 8
libavcodec/options.c | 2 ++
2 files changed, 10 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 21fc74707f..432a3fd153 100644
--- a/libavcodec/avcodec.h
+++
---
libavutil/frame.c | 20 +++-
libavutil/frame.h | 14 ++
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 30db83a5e5..47ecd964b8 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -830,16 +830,26 @@
This was requested to be added in review.
---
libavutil/frame.c | 43 ++-
libavutil/frame.h | 21 +
2 files changed, 51 insertions(+), 13 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 46f976a3ed..30db83a5e5
On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:
Allan Cady via ffmpeg-devel:
From: "Allan Cady"
I propose changing the format to "%.6f", which will
give microsecond precision for all timestamps, regardless of
offset. Trailing zeros can be trimmed from the fraction, without
losing
> On Monday, March 11, 2024 at 12:50:11 PM PDT, wrote:
> On 11 Mar 2024, at 15:26, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> Allan Cady via ffmpeg-devel:
From: "Allan Cady"
I propose changing the format to "%.6f", which will
give microsecond precision for all
I am working on an improved patchset to consolidate these patches, also
address feedback and other improvements. Will submit soon, thank you!
On Mon, Mar 11, 2024 at 11:38 AM Stefano Sabatini
wrote:
> On date Sunday 2024-03-10 19:44:11 -0500, Marth64 wrote:
> > In Closed Captions (US), the
Fixes #10900
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 05f8283af9..e0b5bcf589 100755
--- a/configure
+++ b/configure
@@ -3076,6 +3076,7 @@ nvdec_deps="ffnvcodec"
vaapi_x11_deps="xlib_x11"
videotoolbox_hwaccel_deps="videotoolbox pthreads"
Thanks, will follow up with a v3 set (consolidating/resolving feedback on
the other CC fixes as well).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On Monday, March 11, 2024 at 12:11:45 PM PDT, Marton Balint
wrote:
> On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:
> Allan Cady via ffmpeg-devel:
>> From: "Allan Cady"
>>
>> I propose changing the format to "%.6f", which will
>> give microsecond precision for all timestamps, regardless of
>>
On Mon, 2024-03-11 at 21:57 -0300, James Almer wrote:
> On 3/11/2024 9:49 PM, Michael Niedermayer wrote:
> > On Mon, Mar 11, 2024 at 06:53:31PM +, Frank Plowman wrote:
> > > VVC's subpictures feature is not yet implemented in the native
> > > decoder.
> > > Throw an AVERROR_PATCHWELCOME when
On 3/11/2024 9:49 PM, Michael Niedermayer wrote:
On Mon, Mar 11, 2024 at 06:53:31PM +, Frank Plowman wrote:
VVC's subpictures feature is not yet implemented in the native decoder.
Throw an AVERROR_PATCHWELCOME when trying to decode a bitstream using
the feature. Fixes crashes when trying
To test the patch I've been working on, I wrote a small standalone C program,
which I had saved in the project root. The file I'm patching is
libavutil/timestamp.h. At first I had duplicated a bunch of definitions out of
other include files (e.g. struct AVRational, in libavutil/rational.h) so I
On Mon, Mar 11, 2024 at 06:53:31PM +, Frank Plowman wrote:
> VVC's subpictures feature is not yet implemented in the native decoder.
> Throw an AVERROR_PATCHWELCOME when trying to decode a bitstream using
> the feature. Fixes crashes when trying to decode bitstreams which
> use the feature.
>
Agreed on both points, I will address them. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject
Quoting Michael Niedermayer (2024-03-11 00:37:07)
> > > >>> Because I don't want ffmpeg CLI to have codec-specific code for a
> > > >>> codec
> > > >>> that's been obsolete for 15+ years. One could also potentially do it
> > > >>> inside the encoder itself, but it is nontrivial since the
In my personnal experience, when running fate, --assert-level=2 has a very
limited performance impact,
so I think it can be recommended without further attention.
Nicolas Gaullier (1):
doc/fate: advise on --assert-level=2
doc/fate.texi | 7 +++
1 file changed, 7 insertions(+)
--
2.30.2
Signed-off-by: Nicolas Gaullier
---
doc/fate.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 2fa8c34c2d..2fa7c70251 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -79,6 +79,13 @@ Do not put a '~' character in the samples path to indicate a
On 2024-03-06 11:02 am, Gyan Doshi wrote:
On 2024-03-01 07:41 pm, Gyan Doshi wrote:
At present, consume_update evaluates timeline state on all links for
a multi-input filter. This can lead to the filter being incorrectly
en/dis-abled when evaluation on a frame on a secondary link leads to
From: Zhao Zhili
---
v3: Remove unnecessary inclusion
configure| 2 +-
libavcodec/libx264.c | 132 +++
2 files changed, 109 insertions(+), 25 deletions(-)
diff --git a/configure b/configure
index db7dc89755..24cb897d28 100755
---
On 10/03/2024 23:49, Anton Khirnov wrote:
Quoting James Almer (2024-03-10 23:29:27)
On 3/10/2024 7:24 PM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2024-03-10 20:21:47)
On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote:
Quoting Michael Niedermayer (2024-03-10 04:36:29)
Quoting Tobias Rapp (2024-03-11 11:12:38)
> On 10/03/2024 23:49, Anton Khirnov wrote:
>
> > Quoting James Almer (2024-03-10 23:29:27)
> >> On 3/10/2024 7:24 PM, Anton Khirnov wrote:
> >>> Quoting Michael Niedermayer (2024-03-10 20:21:47)
> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton
On Mon, 11 Mar 2024, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-11 11:12:38)
On 10/03/2024 23:49, Anton Khirnov wrote:
Quoting James Almer (2024-03-10 23:29:27)
On 3/10/2024 7:24 PM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2024-03-10 20:21:47)
On Sun, Mar 10, 2024 at
Quoting Martin Storsjö (2024-03-11 13:29:15)
> On Mon, 11 Mar 2024, Anton Khirnov wrote:
>
> > Quoting Tobias Rapp (2024-03-11 11:12:38)
> >> On 10/03/2024 23:49, Anton Khirnov wrote:
> >>
> >>> Quoting James Almer (2024-03-10 23:29:27)
> On 3/10/2024 7:24 PM, Anton Khirnov wrote:
> >
> 在 2024年3月10日，21:55，Stefano Sabatini 写道：
>
> On date Saturday 2024-03-09 02:17:19 +, hung kuishing wrote:
>>
>> Signed-off-by: clarkh
>> mailto:hungkuish...@outlook.com>>
>> ---
>> doc/examples/qsv_decode.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git
On Mon, 11 Mar 2024, Anton Khirnov wrote:
Well it IS obsolete. AFAIK it was never a particularly popular codec,
and was only really used by the anime and ripping scenes in early 2000s,
and even they dropped it very quickly once x264 appeared.
Within the scene of mobile HW, they commonly had
Mantissas are the last data in the channel subsegment and it appears it
is sometimes missing a very few bits for the parsing to complete.
This must not be confused with data corruption.
In standard conditions with certified products, it has been observed
that the occurence of this issue is pretty
A new ping for this same old topic. Previously with no feedback at all:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7482
I just "rebased"-retested it.
Updates: wrapped lines of commit msg
The samples (source/before patch/after patch) are still available on
https://0x0.st/oOvv.zip
Andreas Rheinhardt:
> Allan Cady via ffmpeg-devel:
>> From: "Allan Cady"
>>
>> I propose changing the format to "%.6f", which will
>> give microsecond precision for all timestamps, regardless of
>> offset. Trailing zeros can be trimmed from the fraction, without
>> losing precision. If the length
Allan Cady via ffmpeg-devel:
> From: "Allan Cady"
>
> I propose changing the format to "%.6f", which will
> give microsecond precision for all timestamps, regardless of
> offset. Trailing zeros can be trimmed from the fraction, without
> losing precision. If the length of the fixed-precision
On Mon, 11 Mar 2024, Anton Khirnov wrote:
I think the point is, that one can't just dismiss that anybody would want
to encode mpeg4 video any longer, even if it is obsolete. I also would
like to keep being able to do that.
That capability is not going away though, and I'm not arguing that it
On 11/03/2024 14:28, Anton Khirnov wrote:
Quoting Martin Storsjö (2024-03-11 13:29:15)
On Mon, 11 Mar 2024, Anton Khirnov wrote:
Quoting Tobias Rapp (2024-03-11 11:12:38)
On 10/03/2024 23:49, Anton Khirnov wrote:
Quoting James Almer (2024-03-10 23:29:27)
On 3/10/2024 7:24 PM, Anton
Quoting Martin Storsjö via ffmpeg-devel (2024-03-11 15:03:15)
> On Mon, 11 Mar 2024, Anton Khirnov wrote:
>
> >> I think the point is, that one can't just dismiss that anybody would want
> >> to encode mpeg4 video any longer, even if it is obsolete. I also would
> >> like to keep being able to
---
doc/muxers.texi | 138 ++--
1 file changed, 74 insertions(+), 64 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..34de187f5e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1421,104 +1421,114 @@ ffmpeg -i INPUT
---
libavformat/fifo.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 074a46485c..a3d41ba0d3 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -663,36 +663,36 @@ static void
Correct check on PTS nullness.
---
libavformat/fifo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index a3d41ba0d3..fcd80f217a 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -345,7 +345,7 @@ static int
Correct check on PTS nullness.
---
libavformat/fifo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index a3d41ba0d3..fcd80f217a 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -345,7 +345,7 @@ static int
---
doc/muxers.texi | 138 ++--
1 file changed, 74 insertions(+), 64 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..34de187f5e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1421,104 +1421,114 @@ ffmpeg -i INPUT
---
libavformat/fifo.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 074a46485c..a3d41ba0d3 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -663,36 +663,36 @@ static void
On date Sunday 2024-03-10 19:18:56 -0500, Marth64 wrote:
> In MPEG-2 user data, there can be different types of Closed Captions
> formats embedded (A53, SCTE-20, or DVD). The current behavior of the
> CC extraction code in the MPEG-2 decoder is to not be aware of
> multiple formats if multiple
On date Sunday 2024-03-10 19:40:47 -0500, Marth64 wrote:
> Currently, Closed Captions decoder prints multiple \pos ASS tags per line,
> per cue. This is invalid behavior, because only the first \pos tag in a cue
> is honored by ASS anyway. Don't write multiple \pos tags.
>
> Signed-off-by:
LGTM. Options before are the same as after change.
On Mon, Mar 11, 2024 at 11:15 AM Stefano Sabatini
wrote:
> ---
> libavformat/fifo.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> index
LGTM from readability perspective. Nice catch on the command missing slash.
On Mon, Mar 11, 2024 at 11:15 AM Stefano Sabatini
wrote:
> ---
> doc/muxers.texi | 138 ++--
> 1 file changed, 74 insertions(+), 64 deletions(-)
>
> diff --git
On date Sunday 2024-03-10 19:44:11 -0500, Marth64 wrote:
> In Closed Captions (US), the non-breaking space (0xA0) can be used to align
> text horizontally from the left by using it as a leading character.
> However, CC decoder does not ignore it as a leading character like it does
> an ordinary
LGTM. sha256 sum of my sample is bit-identical
ab6d14ea8b6ce04f3dd57c0be03bc34a064c9babe439d3882a0797f12c4e9d40
TEST_ATSC.cc.ass
ab6d14ea8b6ce04f3dd57c0be03bc34a064c9babe439d3882a0797f12c4e9d40
TEST_ATSC_SimplifyLinebreaks.cc.ass
On Sun, Feb 11, 2024 at 8:02 PM Oneric wrote:
>
On date Sunday 2024-03-10 17:06:18 +0100, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> >> diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h
> >> index e67c59abad..2dd21dea52 100644
> >> --- a/libavcodec/tiff.h
> >> +++ b/libavcodec/tiff.h
> >> @@ -30,9 +30,6 @@
> >> #ifndef AVCODEC_TIFF_H
>
Yet another probesize used to get the durations when
estimate_timings_from_pts is required. It is aimed at users interested
in better durations probing for itself, or because using
avformat_find_stream_info indirectly and requiring exact values: for
concatdec for example, especially if
Ping ?
v3 "bis" rebased and wrapped lines in commit msg
Nicolas Gaullier (1):
avformat/demux: Add durationprobesize AVOption
doc/APIchanges | 3 +++
doc/formats.texi| 16 +++-
libavformat/avformat.h | 12
libavformat/demux.c |
Could someone please have a look at an issue I'm having in resubmitting a
patch, trying to get the resubmission email to appear as a reply on an existing
thread? In order to conform to submission guidelines in ffmpeg-devel, I'm using
git format-patch and git send-email, using the --in-reply-to
71 matches
Mail list logo
