> > > On Jun 30, 2022, at 7:56 PM, Andreas Rheinhardt
> > wrote:
> > >
> > > "zhilizhao(赵志立)":
> > >>
> > >>
> > >>> On Jun 30, 2022, at 4:43 PM, Anton Khirnov
> wrote:
> > >>>
> > >>> Quoting Tong Wu (2022-06-30 04:45:56)
> > Add a function to get the corresponding AVHWDeviceType from a
>
Hi!
On upgrading our embedded system to ffmpeg version 5.0, I found that the
configure patch d5733936d857ce5c7d28c0bc9e89a2e2548f8895 that fixes
instruction detection for the PowerPC e500v2 architecture had gone missing,
causing ffmpeg to crash with SIGILL.
Re-applying the patch and rebuilding f
For 422 frames we should not use hard coded 8 to calculate mb size for
uv plane. Chroma shift should be taken into consideration to be
compatiple with different sampling format.
The error is reported by fate test when av_cpu_max_align() return 64
on the platform supporting AVX512. This is a hidden
On 2022-06-27 06:55 pm, Gyan Doshi wrote:
Ping for the set.
Plan to push on Monday.
Regards,
Gyan
On 2022-06-25 01:59 pm, Gyan Doshi wrote:
This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for th
> > On Jun 30, 2022, at 7:56 PM, Andreas Rheinhardt
> wrote:
> >
> > "zhilizhao(赵志立)":
> >>
> >>
> >>> On Jun 30, 2022, at 4:43 PM, Anton Khirnov wrote:
> >>>
> >>> Quoting Tong Wu (2022-06-30 04:45:56)
> Add a function to get the corresponding AVHWDeviceType from a given
> hardware pix
On Thu, Jun 30, 2022 at 4:47 AM Tong Wu
mailto:tong1.wu-at-intel@ffmpeg.org>>
wrote:
When a derive_device_type is not specified, the hwmap filter should be
able to retrieve AVHWDeviceType from outlink->format and create
corresponding hwdevice context.
Signed-off-by: Tong Wu mailto:tong1...
Wujian(Chin) 于2022年6月28日周二 19:15写道：
>
> Fixes ticket #9507.
>
> Signed-off-by: wujian_nanjing
> ---
> libavcodec/v4l2_m2m.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
> index 51932ba..9849360 100644
> --- a/libavcodec
Andreas Rheinhardt:
> encode_send_frame_internal() is always only called if
> the buffer packet is empty and except when we are dealing
> with an audio codec that does not allow variable frame size
> it stays that way until a call to av_frame_ref() at the end
> of encode_send_frame_internal(). In c
Paul B Mahol:
> On Tue, Jun 28, 2022 at 1:27 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> Maybe this was meant to be used somehow?
>>
>
> probably some not implemented logic to set probe depending on amount of
> invisible chars
While just at it, also use av_calloc() instead of zeroing
the array ourselves in a loop.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevcdec.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pthread_slice.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
index 756cc59dbf..a4d31c6f4d 100644
--- a/libavcodec/pthread_slice.c
+++ b/libavcodec/pthread_slice.c
Actually, ff_slice_thread_allocz_entries() always already
allocates zeroed entries, so ff_reset_entries() was already
unnecessary. Make this more clear by renaming it to
ff_slice_thread_allocz_entries().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevcdec.c | 3 +--
libavcodec/pthread
Also postpone it after the checks for invalid input.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevcdec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 048fcc76b4..5215f06e31 100644
--- a/libavcodec/hevcdec.c
+++
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet up until now that is not how it is handled in practice:
Each HEVCLocalContext has a unique HEVCContext allocated for it
and each of these coin
Right now the code passes a list of ints whose entry #i
is just i as opaque parameter to hls_decode_entry_wpp
via execute2; said list is even constantly allocated and freed.
This commit stops doing so and instead passes the list of
HEVCLocalContext* instead, so that the main HEVCContext
can be avo
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides except
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides except
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides except
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides with th
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides with th
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides except
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_cabac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
index 9b8c8e342d..a194f8a02a 100644
--- a/libavcodec/hevc_cabac.c
+++ b/libavcodec/hevc_cabac.c
@@ -1282,7 +128
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_filter.c | 16
libavcodec/hevc_mvs.c| 10 +-
libavcodec/hevc_refs.c | 5 +++--
libavcodec/hevcdec.h | 4 ++--
4 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/libavcodec/hevc_filter.c b/liba
It is safe for a slice thread to read the main context
and therefore it is safe to add a pointer to const HEVCContext
(namely the parent context) to each HEVCLocalContext.
It is also safe (and actually redundant) to add a pointer
to a logcontext to HEVCLocalContext.
Doing so allows to pass the HEV
The slicethread contexts need to be initialized for
every frame, not only the first one, so one can
remove the initialization when allocating these contexts,
because the ordinary per-frame initialization will
initialize them again just a few lines below.
Signed-off-by: Andreas Rheinhardt
---
lib
From: Xu Guangxin
Tests the issue fixed in c8bc0f66a875bc3708d8dc11b757f2198606ffd7.
Signed-off-by: Xu Guangxin
---
Thanks to James for uploading the sample.
There is something weird going on with this sample:
If I max out my computer and concurrently run this test
with slice threading, it som
It results in undefined behaviour. Instead initialize the mutexes
and condition variables once during init (and check these
initializations).
Also combine the corresponding mutex and condition variable
into one structure so that one can allocate their array
jointly.
Signed-off-by: Andreas Rheinha
Parse the alpha channel for still AVIF images and expose it as a
separate track. This is the simplest way of supporting AVIF alpha
channel in a codec independent manner (similar to how ffmpeg
supports animated AVIF with alpha channel).
One can use the alphamerge filter to get a transparent image w
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 Thu, Jun 30, 2022 at 11:15 PM Andreas Rheinhardt
wrote:
>
> Regression since c9de096851803d45444ae9dfe3a390a2d53ac71b.
> Fixes Coverity ID 1506839.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libav
Regression since c9de096851803d45444ae9dfe3a390a2d53ac71b.
Fixes Coverity ID 1506839.
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 0ef6b3c76e..a4dace7c1d 100644
---
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames unfortun
On Thu, Jun 30, 2022 at 9:42 AM Jan Ekström wrote:
>
> The simplified parsing currently in `mov_write_ac3_tag` trusts the content
> of the packets a bit too much (the AC-3 parser returns all data fed to it,
> including any possible data before the start code), while the existing E-AC-3
> logic doe
Hi
Previous version of this patch failed fate-fic-avi with
THREAD_TYPE=slice THREADS=2 due to thread_execute() always returning 0.
Fixed in this version.
The fic sample appears to indeed be broken. Some packets are truncated,
including one zero-length packet.
/Tomas
From 872354ff70f6e880d77e8bdd
Quoting Andreas Rheinhardt (2022-06-23 20:56:00)
> Anton Khirnov:
> > + */
> > +static inline uint32_t bitstream_read(BitstreamContext *bc, unsigned int n)
> > +{
> > +if (!n)
> > +return 0;
>
> This makes this function a get_bitsz equivalent. Why is there no
> get_bits() equivalent fo
> On Jun 30, 2022, at 7:56 PM, Andreas Rheinhardt
> wrote:
>
> "zhilizhao(赵志立)":
>>
>>
>>> On Jun 30, 2022, at 4:43 PM, Anton Khirnov wrote:
>>>
>>> Quoting Tong Wu (2022-06-30 04:45:56)
Add a function to get the corresponding AVHWDeviceType from a given
hardware pixel format.
>>
"zhilizhao(赵志立)":
>
>
>> On Jun 30, 2022, at 4:43 PM, Anton Khirnov wrote:
>>
>> Quoting Tong Wu (2022-06-30 04:45:56)
>>> Add a function to get the corresponding AVHWDeviceType from a given
>>> hardware pixel format.
>>>
>>> Signed-off-by: Tong Wu
>>> ---
>>> libavutil/hwcontext.c | 12 +++
> On Jun 30, 2022, at 4:43 PM, Anton Khirnov wrote:
>
> Quoting Tong Wu (2022-06-30 04:45:56)
>> Add a function to get the corresponding AVHWDeviceType from a given
>> hardware pixel format.
>>
>> Signed-off-by: Tong Wu
>> ---
>> libavutil/hwcontext.c | 12
>> libavutil/hwcontext.
On Thu, Jun 30, 2022 at 4:47 AM Tong Wu
wrote:
> When a derive_device_type is not specified, the hwmap filter should be
> able to retrieve AVHWDeviceType from outlink->format and create
> corresponding hwdevice context.
>
> Signed-off-by: Tong Wu
> ---
> libavfilter/vf_hwmap.c | 17
Fix looking for .ffmpeg subfolder in FFMPEG_DATADIR and inversely not in HOME.
Fix search order (documentation).
---
fftools/cmdutils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 69a6f54ea3..fcaefb9f1e 100644
--- a/fftools/
On 30.06.2022 10:46, Anton Khirnov wrote:
Hardware frames wrapped in frames pretending to be packets. Hacks upon
hacks upon hacks. Why do we need this "device" again?
Why not just use lavfi directly?
It should be definitely possible to make ffmpeg.c directly use a source
filter, but it's a big
It results in undefined behaviour. Instead initialize the mutexes
and condition variables once during init (and check these
initializations).
Also combine the corresponding mutex and condition variable
into one structure so that one can allocate their array
jointly.
Signed-off-by: Andreas Rheinha
> On Jun 30, 2022, at 5:09 PM, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Regression since ed0001482a74b60f3d5bc5.
>
> Tested with:
> ./ffmpeg -i foo.ape -f md5 -
> for samples in #9816 and #2239.
>
> It gives the same result as before ed0001482a for ticket #9816,
> and doesn't break ticke
Quoting Andreas Rheinhardt (2022-06-24 14:30:58)
> Anton Khirnov:
> > From: Alexandra Hájková
> >
> > The cached bitstream reader was originally written by Alexandra Hájková
> > for Libav, with significant input from Kostya Shishkov and Luca Barbato.
> > It was then committed to FFmpeg in ca079b0
From: Zhao Zhili
Regression since ed0001482a74b60f3d5bc5.
Tested with:
./ffmpeg -i foo.ape -f md5 -
for samples in #9816 and #2239.
It gives the same result as before ed0001482a for ticket #9816,
and doesn't break ticket #2239.
Signed-off-by: Zhao Zhili
---
libavcodec/apedec.c | 2 +-
1 file
Quoting Andreas Rheinhardt (2022-06-30 10:51:56)
> This function is only called from the decoder's init function
> and given that this decoder has FF_CODEC_CAP_INIT_CLEANUP set,
> hevc_decode_free() is called automatically (currently it would
> be called twice with the second call being redundant).
Quoting Andreas Rheinhardt (2022-06-30 10:51:55)
> All contexts are always initialized during init, regardless
> of whether frame threading is in use or not.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hevcdec.c | 7 ---
> libavcodec/hevcdec.h | 1 -
> 2 files changed, 8 deletio
Variant 2 is less bad, but the whole check seems hacky to me, since it
seems to make assumptions about swr defaults
Won't setting this unconditionally have the same effect?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
This function is only called from the decoder's init function
and given that this decoder has FF_CODEC_CAP_INIT_CLEANUP set,
hevc_decode_free() is called automatically (currently it would
be called twice with the second call being redundant).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc
All contexts are always initialized during init, regardless
of whether frame threading is in use or not.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevcdec.c | 7 ---
libavcodec/hevcdec.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
i
They are unnecessary since the SEI enum has been moved
to sei.h.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 10b3bcc70b..12e38c80b5 100644
--- a/libavcodec/cbs_h2645.c
+++
obviously ok
--
Anton Khirnov
___
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 "unsubscribe".
On Thu, Jun 30, 2022 at 10:31 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Zhao Zhili:
> > From: Zhao Zhili
> >
> > Fixes ticket #9816.
> > Regression since ed0001482a74b60f3d5bc5.
> >
> > Prediction value larger than INT32_MAX should be treated as
> > negative. The code alrea
Quoting Timo Rothenpieler (2022-06-29 21:52:50)
> The lavfi avdevice as it is right now can't output "special frames"
> like hardware frames.
> This patch makes the lavfi avdevice output wrapped AVFrames instead
> of copying the actual data, greatly simplifying it in the process.
>
> ---
> I am no
On Thu, Jun 30, 2022 at 10:34 AM Anton Khirnov wrote:
> Quoting Paul B Mahol (2022-06-30 08:59:53)
> > Updated.
>
> This comment is entirely useless. What was updated and why?
>
Lot of stuff, so do you not need to improve it.
>
> --
> Anton Khirnov
> ___
Quoting Tong Wu (2022-06-30 04:45:56)
> Add a function to get the corresponding AVHWDeviceType from a given
> hardware pixel format.
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext.c | 12
> libavutil/hwcontext.h | 9 +
> 2 files changed, 21 insertions(+)
>
> diff -
Quoting Paul B Mahol (2022-06-30 08:59:53)
> Updated.
This comment is entirely useless. What was updated and why?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, v
Zhao Zhili:
> From: Zhao Zhili
>
> Fixes ticket #9816.
> Regression since ed0001482a74b60f3d5bc5.
>
> Prediction value larger than INT32_MAX should be treated as
> negative. The code already depends on undefined right shift
> behavior before the patch, which doesn't get fixed by the patch.
>
>
From: Zhao Zhili
Fixes ticket #9816.
Regression since ed0001482a74b60f3d5bc5.
Prediction value larger than INT32_MAX should be treated as
negative. The code already depends on undefined right shift
behavior before the patch, which doesn't get fixed by the patch.
Signed-off-by: Zhao Zhili
---
59 matches
Mail list logo
