On Thu, 2022-07-28 at 08:19 -0700, Dmitry Rogozhkin wrote:
> GPU hang is one of the most typical errors on Intel GPUs in
> case something goes wrong. It's important to recognize it
> explicitly for easier bugs triage. Also, this error code
> can be used to trigger GPU recovery path in self-written
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aarch64/h264chroma_init_aarch64.c | 12 +-
libavcodec/aarch64/h264cmc_neon.S| 4 +-
libavcodec/aarch64/rv40dsp_init_aarch64.c| 8 +-
libavcodec/aarch64/vc1dsp_init_aarch64.c | 8 +-
libavcodec/arm/h264chroma_init_arm.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/aarch64/videodsp_init.c | 2 +-
libavcodec/arm/videodsp_init_armv5te.c | 2 +-
libavcodec/loongarch/videodsp_init.c | 2 +-
libavcodec/mips/videodsp_init.c| 2 +-
libavcodec/ppc/videodsp.c | 2 +-
libavcodec/videodsp.c
From: Zhao Zhili
There was an implicit cast from double to int64_t in time unit of
second.
---
libavformat/flvdec.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 8dba92661b..10f0ea7736 100644
--- a/libavformat/
From: Zhao Zhili
---
libavformat/flvenc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 1c4ffb985a..5d574fa790 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -993,12 +993,9 @@ static int flv_write_p
From: Zhao Zhili
Firstly, the timestamps generated from framerate are inaccurate for
variable framerate mode.
Secondly, the timestamps always start from zero, while pts/dts can
start from nonzero. FLV demuxer rejects such index with message:
"Found invalid index entries, clearing the index".
---
From: Zhao Zhili
v2:
Simplify patch 2/3 as Michael's suggestion.
Zhao Zhili (3):
avformat/flvenc: fix timestamp of key frame index
avformat/flvdec: make key frame timestamps more accurate
avformat/flvenc: fix shadowed variable ts
libavformat/flvdec.c | 13 +++--
fre 2022-07-29 klockan 01:18 +0200 skrev Michael Niedermayer:
> On Tue, Jul 19, 2022 at 03:48:59PM +0200, Tomas Härdin wrote:
> > mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
> > >
> > > + { {
> > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,
> > > 0x09
>
On Tue, Jul 19, 2022 at 03:48:59PM +0200, Tomas Härdin wrote:
> mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
> >
> > + { {
> > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09
> > ,0x01,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V0 */
> > + { {
> > 0x0
On Wed, Jul 27, 2022 at 12:08:09AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/arm/mpegvideoencdsp_init_arm.c | 4 ++--
> libavcodec/mips/h263dsp_mips.h | 2 +-
> libavcodec/mips/mpegvideoencdsp_msa.c | 4 ++--
> libavcodec/mpegvide
On Wed, Jul 27, 2022 at 12:08:11AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/motion_est.c | 31 +--
> libavcodec/motion_est.h | 4 ++--
> 2 files changed, 19 insertions(+), 16 deletions(-)
LGTM
thx
[...]
--
Michael
On Wed, Jul 27, 2022 at 12:08:12AM +0200, Andreas Rheinhardt wrote:
> Also constify the corresponding code in mpegvideo.c that handles
> lowres.
> (Unfortunately, not everything that is const could be constified:
> ref_picture could be made const uint8_t* const* if C allowed the
> safe automatic co
On Wed, Jul 27, 2022 at 12:08:14AM +0200, Andreas Rheinhardt wrote:
> This is possible for most of the callers, because e.g. only
> the MPEG-4 decoder can have bits_per_raw_sample > 8.
> Also most mpegvideo-based codecs are 420 only.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/h261d
Stores the item ids of all the items found in the file and
processes the primary item at the end of the meta box. This patch
does not change any behavior. It sets up the code for parsing
alpha channel (and possibly images with 'grid') in follow up
patches.
Signed-off-by: Vignesh Venkatasubramanian
On Wed, Jul 27, 2022 at 12:40 PM Andreas Rheinhardt
wrote:
>
> Vignesh Venkatasubramanian:
> > Stores the item ids of all the items found in the file and
> > processes the primary item at the end of the meta box. This patch
> > does not change any behavior. It sets up the code for parsing
> > alph
Since this behavior is intentional, use the VERBOSE level instead of WARNING as
it's nothing the user should worry about.
Signed-off-by: James Almer
---
libavcodec/aac.h | 1 +
libavcodec/aacdec_template.c | 4
libavcodec/aacsbr_template.c | 2 ++
3 files changed, 7 insertions(+
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> dpeeters@MRU.MEDICAL.CANON
> Sent: Friday, July 8, 2022 4:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [EXTERNAL] [FFmpeg-devel] [PATCH] Allow exporting of RGB and
> BGR images to CUDA.
>
> Use the step size when calculating the n
GPU hang is one of the most typical errors on Intel GPUs in
case something goes wrong. It's important to recognize it
explicitly for easier bugs triage. Also, this error code
can be used to trigger GPU recovery path in self-written
applications.
There were 2 other statuses which MediaSDK can ppote
From: Niklas Haas
Handling this in general code makes more sense than handling it in
individual codec files, because it would be a lot of unnecessary code
duplication for the plenty of formats that support exporting ICC
profiles (jpg, png, tiff, webp, jxl, ...).
encode.c and decode.c will be in
From: Niklas Haas
This functionally already exists, but as pointed out in #9672 and #9673,
requiring users to manually include filters is clumsy, error-prone and
hard to use together with tools like ffplay.
To streamline ICC profile support, add a new AVCodecContext flag to
globally enable readi
From: Niklas Haas
Implementation for the decode side of the ICC profile API, roughly
matching the behavior of the existing vf_iccdetect filter.
Closes: #9673
Signed-off-by: Niklas Haas
---
libavcodec/decode.c | 61 +
1 file changed, 56 insertions(+)
From: Niklas Haas
This tests the new "-flags2 icc_profiles" option by making sure the
embedded ICC profile gets correctly detected as sRGB.
Signed-off-by: Niklas Haas
---
tests/fate/image.mak | 4 +++
tests/ref/fate/png-icc-parse | 48
2 files chan
From: Niklas Haas
Only if requested, and only if the codec signals support for ICC
profiles. Implementation roughly matches the functionality of the
existing vf_iccgen filter, albeit with some reduced flexibility and no
caching.
Ideally, we'd also only do this on the first frame (e.g. mjpeg, apn
From: Niklas Haas
Codecs that can read/write ICC profiles deserve a special capability so
the common logic in encode.c/decode.c can decide whether or not there
needs to be any special handling for ICC profiles. The motivation here
is to be able to use it to decide whether or not an ICC profile ne
This tidies up the previous patchset slightly and adds the necessary
user-facing bits to make it actually usable, plus tests.
Will merge this soon since there was no additional feedback on v3.
Changes in v4:
- add the "icc_profiles" option to "flags2", and document it
- fix the corresponding chec
From: Niklas Haas
We will need this helper inside libavcodec in the future, so move it
there, leaving behind an #include to the raw source file in its old
location in libvfilter. This approach is inspired by the handling of
vulkan.c, and avoids us needing to expose any of it publicly (or
semi-pub
On Thu, Jul 28, 2022 at 01:18:07AM +0300, Mohammad AlSaleh wrote:
> Don't give up on the whole frame just because a block failed to
> decode correctly.
>
> Try to continue decoding if the AV_EF_EXPLODE flag is not set.
>
> Signed-off-by: Mohammad AlSaleh
> ---
> libavcodec/mjpegdec.c | 3 ++-
On 7/28/2022 11:24 AM, Anton Khirnov wrote:
Bump the version requirement to 122, which introduced b_full_recon.
---
configure| 2 +-
libavcodec/libx264.c | 55 +++-
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/configure b
Bump the version requirement to 122, which introduced b_full_recon.
---
configure| 2 +-
libavcodec/libx264.c | 55 +++-
2 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 6629d14099..50d73a5325 100755
--
Quoting Amir Mazzarella (2022-07-19 23:21:00)
> Thank you for your response! A C++ compiler can't do implicit casts like a
> C compiler can, in this instance. This is fine for most of FFmpeg's
> codebase, since these tricks are in C source files, but in this instance it
> is in a header file. If an
Sorry, I do not like your patch. The problem is that this essentialy
codifies ffmpeg's internal structure and makes into a kind of a public
interface, which makes it harder for us to change it.
Given that I'm currently in the middle of a big reshuffle of ffmpeg's
internals, this patch would confli
Quoting Emil Velikov (2022-07-22 15:27:26)
>
> Assuming I'm reading the code correctly, currently when both are
> undefined vaapi_device_create() will be basically a dummy, doing some
> basic malloc + opts parsing and erroring out.
>
> So as-is functions like av_hwdevice_ctx_alloc() will return s
32 matches
Mail list logo
