From: Wenbin Chen
PyTorch is an open source machine learning framework that accelerates
the path from research prototyping to production deployment. Official
website: https://pytorch.org/. We call the C++ library of PyTorch as
LibTorch, the same below.
To build FFmpeg with LibTorch, please take
From: Haihao Xiang
This may reduce the number of internal threads when using hwupload or
hwdownload filter.
Signed-off-by: Haihao Xiang
---
libavutil/hwcontext_qsv.c | 24
1 file changed, 24 insertions(+)
diff --git a/libavutil/hwcontext_qsv.c
From: Haihao Xiang
When all cached frames are drained, the output mfxSyncPoint pointer is
NULL and MFX_ERR_MORE_DATA is returned, hence needn't print warning for
this expected behavior, otherwise the user might think the output from
qsv decoders are wrong.
Signed-off-by: Haihao Xiang
---
Greetings Martin et al,
I've been trying to resubmit this patch based on your earlier suggestions. Most
of the tools in the toolchain for this are new to me, so it's been awkward
going.
I did finally get the email sent with the new patch, but for some reason I
haven't been able to figure out
When the silencedetect filter is run against long files, the output
timestamps gradually lose precision as the scan proceeds further into
the file. This is because the output is formatted (in
libavutil/timestamp.h) as "%.6g", which limits the total field
length. Eventually, for offsets greater
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 formatted
timestamp exceeds the length of
On Sat, 2024-03-09 at 19:59 +0800, Nuo Mi wrote:
Hi Fei,
Thank you fei,
Better provide more comments
Added in V2.
Is there any clip fail for this?
No, just notice the defect when I check why recovering frames been outputted in
GDR_D_ERICSSON_1.bit.
Thanks
Fei
On Fri, Mar 8, 2024 at 8:55 AM
From: Fei Wang
The NoOutputBeforeRecoveryFlag of an IDR frame should be set to 1 as
spec says in 8.1.1.
Signed-off-by: Fei Wang
---
libavcodec/vvc/vvc_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index
From: Fei Wang
Signed-off-by: Fei Wang
---
libavcodec/vvc/vvc_refs.c | 8
libavcodec/vvc/vvcdec.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c
index 99f2dcf3ec..afcfc09da7 100644
---
On Sat, 2024-03-09 at 19:57 +0800, Nuo Mi wrote:
Thank you, Fei,
Do you happen to know why the following clips are still failing?
CROP_A_Panasonic_4.bit
Ffmepg decode doesn't apply crop strictly. It will adjust crop for alignment,
see av_frame_apply_cropping().
Thanks
Fei
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 space, so a blank padding is rendered over the black CC box.
This
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: Marth64
---
libavcodec/ccaption_dec.c | 8 ++--
1 file changed, 6
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 exist, therefore allowing one format
to overwrite the other during
On Sun, Mar 10, 2024 at 11:49:12PM +0100, 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
On Fri, Mar 08, 2024 at 11:00:50AM -0300, James Almer wrote:
> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> >
> > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > Hi all
> > > >
> > > > As it was a
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)
> On Fri, Mar 08, 2024 at
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)
On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote:
Quoting Michael
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)
> > > On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2024-03-07 21:37:39)
>
Hi,
> Is 99 an actual limit here of DVDs or is it something you picked? You
> can always use INT_MAX if this is the latter case.
It is the actual limit (as are all of them to the best of my studying.)
> Is there any risk this will be called twice? If so, we should zero out
> state->vob_file
On 3/9/24 13:27, Marth64 wrote:
Signed-off-by: Marth64
---
doc/demuxers.texi | 43 +-
libavformat/dvdvideodec.c | 314 --
2 files changed, 339 insertions(+), 18 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index
On 2/29/24 20:13, Michael Niedermayer wrote:
Every codec we develop is experimental and used by nobody
then by nobody outside ffmpeg
and if we dont allow this then we can never create a new codec.
FFv1 would not exist if we could not have added it at ta time
noone used it. FFv1 would not have
On 3/9/24 15:49, Poorva wrote:
I have attached the git patch containing the changes for your review.
This patch is submitted as part of my qualification task for Google Summer
of Code (GSoC)
Your editor appears to have stripped the newline at the end of the file.
- Leo Izen (Traneptora)
On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-03-10 04:36:29)
> > On Fri, Mar 08, 2024 at 06:34:36AM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2024-03-07 21:37:39)
> > > > On Wed, Mar 06, 2024 at 12:03:03PM +0100, Anton
add_program() will deallocate the whole array on failure so
we must clear nb_prgs
Fixes: null pointer dereference
Fixes: crash-35a3b39ddcc5babeeb005b7399a3a1217c8781bc
Found-by: Catena cyber
Signed-off-by: Michael Niedermayer
---
libavformat/mpegts.c | 3 ++-
1 file changed, 2 insertions(+), 1
On Wed, Feb 28, 2024 at 09:08:34PM +0100, Michael Niedermayer wrote:
> According to kostya, it is not based on Wassermans encoder
>
> CC: Kostya Shishkov
> CC: Anatoliy Wasserman
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/proresenc_kostya.c | 3 ---
> 1 file changed, 3
On Tue, Feb 27, 2024 at 11:47:08PM +0100, Michael Niedermayer wrote:
> Fixes: timeout
> Fixes:
> 66326/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VORBIS_fuzzer-629529186304
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On Mon, Feb 26, 2024 at 12:23:52AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 64479/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EIGHTBPS_fuzzer-5434435386081280
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1db3e0f0a3b7061be6be28d00c675a0.
Signed-off-by: Andreas Rheinhardt
---
Untested except via godbolt.
MSVC actually uses it for optimizations:
LGTM from a helpfulness standpoint. (Only chiming in as I just touched the
same area in a different thread).
Cheers,
On Sun, Mar 10, 2024 at 10:52 Stefano Sabatini wrote:
> On date Sunday 2024-03-10 16:34:23 +0100, Andreas Rheinhardt wrote:
> > Signed-off-by: Andreas Rheinhardt
> > ---
> >
Stefano Sabatini:
> On date Sunday 2024-03-10 15:15:02 +0100, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/mjpegdec.c | 1 -
>> libavcodec/tiff.c | 1 +
>> libavcodec/tiff.h | 3 ---
>> libavcodec/tiffenc.c | 3 +--
>> 4 files changed, 2
On date Sunday 2024-03-10 16:34:23 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> doc/bitstream_filters.texi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 61539d2473..3351625225
On date Sunday 2024-03-10 15:15:02 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mjpegdec.c | 1 -
> libavcodec/tiff.c | 1 +
> libavcodec/tiff.h | 3 ---
> libavcodec/tiffenc.c | 3 +--
> 4 files changed, 2 insertions(+), 6 deletions(-)
>
>
On date Sunday 2024-03-10 15:15:01 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tiff.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
LGTM, thanks.
___
ffmpeg-devel mailing list
Signed-off-by: Andreas Rheinhardt
---
doc/bitstream_filters.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 61539d2473..3351625225 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -199,6
On date Sunday 2024-03-10 15:15:00 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tiff.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index 4c7460cf41..afa1289e27 100644
> ---
Thanks, Stefano, I agree it’s not ideal with just having magic numbers. If
I think of a creative solution I'll let you know.
Appreciate your time,
On Sun, Mar 10, 2024 at 09:56 Stefano Sabatini wrote:
> On date Saturday 2024-03-09 19:56:49 -0600, Marth64 wrote:
> > Following up on this from
On date Sunday 2024-03-10 15:12:16 +0100, Andreas Rheinhardt wrote:
> For unknown geokey values, get_geokey_val() returns
> "Unknown-%d" with val being used for %d. This string
> is allocated and therefore all the known geokey values
> (static strings) are strdup'ed. In case this fails
> it is
On date Sunday 2024-03-10 14:20:12 +, ffmpeg-devel Mailing List wrote:
> Great, thank you very much!
> I'm attaching the (hopefully) final version of the patch.
>
> MD studio was a piece of software created by a company called "EDL",
> which in combination with alternative firmware for the
On date Saturday 2024-03-09 19:56:49 -0600, Marth64 wrote:
> Following up on this from December 2023. I simplified the content and
> hopefully addressed the feedback.
>
> Signed-off-by: Marth64
> ---
> doc/bitstream_filters.texi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff
On date Saturday 2024-03-09 13:17:23 -0600, Marth64 wrote:
> Fixes compiler warning introduced in v2 due to incorrect printf format for
> ssize_t.
>
> Apologies for the inconvenience.
>
> Signed-off-by: Marth64
> ---
> doc/demuxers.texi | 43 +-
> libavformat/dvdvideodec.c | 314
Great, thank you very much!
I'm attaching the (hopefully) final version of the patch.
MD studio was a piece of software created by a company called "EDL", which in
combination with alternative firmware for the Sony MDH-10 MiniDisc recorder
(https://www.minidisc.wiki/equipment/sony/misc/mdh-10)
On date Saturday 2024-03-09 12:48:22 -0600, Marth64 wrote:
> I am willing to maintain these into the future as needed. Thank you.
>
> Signed-off-by: Marth64
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
Will apply (not sure if there is a more formal process to add a
maintainer,
They are incorrect according to [1]. They also share keys with valid
entries, so that it is unspecified which entry bsearch returns
in this case. Fix this by removing the incorrect values.
[1]: https://www.earthdata.nasa.gov/s3fs-public/imported/19-008r4.pdf
Signed-off-by: Andreas Rheinhardt
Instead store all the strings in one continugous string
(with internal \0) and use offsets to access the actual
substrings. This replaces the pointers to the strings
and therefore avoids relocations (and on x64, it actually
shrinks TiffGeoTagNameType by reusing padding to store
the offset field).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 1 -
libavcodec/tiff.c | 1 +
libavcodec/tiff.h | 3 ---
libavcodec/tiffenc.c | 3 +--
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 43b36d0a8f..c9409eac6c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index afa1289e27..5d350f4e7e 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -132,11 +132,8 @@ static void
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 4c7460cf41..afa1289e27 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -2028,7 +2028,8 @@ again:
For unknown geokey values, get_geokey_val() returns
"Unknown-%d" with val being used for %d. This string
is allocated and therefore all the known geokey values
(static strings) are strdup'ed. In case this fails
it is either ignored or treated as "Unknown-%d".
(Furthermore it is possible to call
On date Saturday 2024-03-09 12:39:56 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> libavcodec/ccaption_dec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index d03413265a..faf058ce97 100644
> ---
On date Saturday 2024-03-09 12:39:55 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> libavcodec/ccaption_dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index 1550e4b253..d03413265a 100644
> ---
On date Saturday 2024-03-09 12:27:51 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> libavformat/Makefile | 2 +-
> libavformat/dvdclut.c | 75 +++
> libavformat/dvdclut.h | 37 +++
> libavformat/dvdvideodec.c | 14
From: Niklas Haas
Changes since v1:
- Greatly simplified EMDF implementation, after gaining insight to the
specification (which states that the emdf header must used certain
hard-coded values)
- Tested and validated on official samples
---
Instead of the nal_prefix, this profile inside
From: Niklas Haas
See previous commit.
---
libavcodec/av1dec.c | 25 +
libavcodec/av1dec.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index bbb5634773f..e6346b51dbe 100644
--- a/libavcodec/av1dec.c
+++
From: Niklas Haas
This is thankfully passed through verbatim by libdav1d, so we can parse
it in our own code.
In theory, taking the DV profile from the packet-level configuration
struct is redundant since there is currently only one possible DV level
for AV1 (and all others would fail parsing),
On date Saturday 2024-03-09 12:27:50 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> libavformat/dvdvideodec.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
> index b3cc32b864..ca85aa8d3d 100644
> ---
On date Saturday 2024-03-09 17:20:49 +, ffmpeg-devel Mailing List wrote:
> Thank you both for the suggestions. I've updated the code as requested, and I
> apologize for the AV_LOG_WARNING instead of AV_LOG_ERROR - it was an
> oversight on my part.
> I have also added the stream codec check,
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 a/doc/examples/qsv_decode.c b/doc/examples/qsv_decode.c
> index
Hi Mark,
Do you think the broken vaapi dec-filter-encode (and other hw acceleration
method using fixed-size pool) is a blocking issue ? See more info below:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231220071050.3175819-11-haihao.xi...@intel.com/
On 2024-02-28 19:36 +0100, Jean-Baptiste Kempf wrote:
>
> On Wed, 28 Feb 2024, at 18:55, James Almer wrote:
> > On 2/28/2024 10:31 AM, J. Dekker wrote:
> >>
> >> Michael Niedermayer writes:
> >>
> >>> [[PGP Signed Part:Undecided]]
> >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote:
>
On Sun, Mar 10, 2024 at 10:24 AM Kieran Kunhya wrote:
> On Sun, 10 Mar 2024, 01: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
On Sun, 10 Mar 2024, 01: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
61 matches
Mail list logo
