I want to add support for the other formats, but I'm not sure how to find
video files to test it out. I tried looking through
https://samples.ffmpeg.org/, but I'm not sure which files on there are the
formats im looking for (AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P,
AV_PIX_FMT_P010, AV_PIX_FMT_P016,
Most of the times it's just 'url ', so it's not unknown.
---
By the way, there is a patch to add support for dref.url
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1596807454-17939-2-git-send-email-mypopy...@gmail.com/
I agree there are safety issues.
libavformat/mov.c | 4 ++--
1 file change
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).
It usually works undetected as pthread implementations allows NULL as a special
value (and should return EINVAL but
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL
v2: shorter commit lines and removed an extra space, now I realize it's
the wrong one, the original being also wrong...
On 2021-09-02 11:19, Steve Lhomme wrote:
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initializ
When using slice decoding vp9_free_entries() is called before
vp9_alloc_entries() is ever called. It should destroy properly
initialized variables (or check it was never called before).
It usually works undetected as pthread implementations allows NULL as a
special value (and should return EINVAL
Steve Lhomme:
> When using slice decoding vp9_free_entries is called before vp9_alloc_entries
> is ever called. It should destroy properly initialized variables (or check it
> was never called before).
>
> It usually works undetected as pthread implementations allows NULL as a
> special
> value (
On 2021-09-02 11:27, Andreas Rheinhardt wrote:
Steve Lhomme:
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).
It usually works undetected as pthread implementatio
Up until now, ff_write_chained() copied the packet (manually, not with
av_packet_move_ref()) from a packet given to it to a stack packet whose
timing and stream_index is then modified before being sent to another
muxer via av_(interleaved_)write_frame(). Afterwards it is intended to
sync the fields
When encoding yuva420 (alpha) frames, the vpx encoder uses a second
vpx_codec_ctx to encode the alpha stream. However, codec options were
only being applied to the primary encoder. This patch updates
codecctl_int and codecctl_intp to also apply codec options to the alpha
codec context when encoding
---
libavformat/mxfdec.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 34cbd2cd77..c28549f6a9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -203,8 +203,8 @@ typedef struct MXFDescri
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/nvenc.c | 12
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_h264.c | 2 ++
libavcodec/nvenc_hevc.c | 2 ++
libavcodec/version.h| 2 +-
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/libavcodec/
On 02.09.2021 19:50, Dylan Fernando wrote:
I want to add support for the other formats, but I'm not sure how to find
video files to test it out. I tried looking through
https://samples.ffmpeg.org/, but I'm not sure which files on there are the
formats im looking for (AV_PIX_FMT_YUV420P, AV_PIX_FM
Andreas Rheinhardt (12021-08-31):
> Our VobSub demuxer does not set the duration (it is encoded as part of
> the payload). So our muxer uses SimpleBlocks (because duration == 0
> actually says "play this until the next packet arrives", which coincides
> with the semantics for SimpleBlocks).
> mkvme
Andreas Rheinhardt (12021-08-31):
> realloc is not supposed to transfer ownership, av_dict_set() with these
> flags is. For me its behaviour makes sense (and avoids lots of av_free()
> on failure paths).
This is C, not Rust: ownership rules are in the eye of the beholder.
The objective thing to s
On Sun, Aug 29, 2021 at 06:38:58PM +0200, Anton Khirnov wrote:
> ---
> Now with a new public function to query required slice alignment, which
> fixes the yuv410p->yuv420p conversion issue reported by Michael.
{...]
> +/**
> + * Indicate that a horizontal slice of input data is available in the sou
On Sun, Aug 29, 2021 at 06:40:47PM +0200, Anton Khirnov wrote:
> ---
> Updated to conform to the slice alignment requirements
> ---
> libswscale/options.c | 3 ++
> libswscale/swscale.c | 59 +
> libswscale/swscale_internal.h | 14 ++
> libswscale/uti
Also do not destroy and reinitialize mutexes and conditions when
certain input parameters change. Given that the decoder did not
create these variables at all during init, uninitialized mutexes
and conditions are destroyed before the very first initialization.
This is undefined behaviour and certai
On 9/2/2021 3:53 AM, Hendrik Leppkes wrote:
On Thu, Sep 2, 2021 at 12:54 AM James Almer wrote:
On 8/27/2021 4:34 PM, James Almer wrote:
Suggested-by: BBB
Signed-off-by: James Almer
---
Changelog | 1 +
configure | 1 +
doc/general_contents.texi | 1 +
We have more mutexes/condition variables whose initialization is
unchecked.
Also use a proper namespace for these functions.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pthread.c | 38
libavcodec/pthread_frame.c| 55 +--
Also don't destroy uninitialized conditions/mutexes.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c| 17 +++--
libavcodec/vp9dec.h | 1 +
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 5c20a7ec5d..239475cdbe 1006
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them would be undefined behaviour
if they had not been ini
Signed-off-by: Andreas Rheinhardt
---
libavcodec/omx.c | 62
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/libavcodec/omx.c b/libavcodec/omx.c
index 7086ddd3a4..4078ac84a4 100644
--- a/libavcodec/omx.c
+++ b/libavcodec/omx.c
@@ -5
Otherwise the context would be in an inconsistent state
if vp9_alloc_entries() failed (and if this would be checked).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 8eb57eb8e6..8
Signed-off-by: Andreas Rheinhardt
---
libavcodec/frame_thread_encoder.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index 9bc48c7761..e5f6544750 100644
--- a/libavcodec/fr
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 239475cdbe..8eb57eb8e6 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -62,11 +62,8 @@ static int vp9_alloc_entries(AVCo
Signed-off-by: Andreas Rheinhardt
---
libavcodec/frame_thread_encoder.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index e5f6544750..8f8294374f 100644
--- a/libavcodec/frame_thread_encod
Signed-off-by: Andreas Rheinhardt
---
libavcodec/frame_thread_encoder.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index 8f8294374f..219d65cce7 100644
--- a/libavcodec/frame_thread_encoder.c
+
Signed-off-by: Andreas Rheinhardt
---
libavcodec/frame_thread_encoder.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index 219d65cce7..e9a5a146ca 100644
--- a/libavcodec/frame_thread_enc
Now that the mutexes and conditions are only initialized and destroyed
once, said function only had one purpose: free the entries array.
Given that vp9_alloc_entries() already does this if the array is already
allocated it is unnecessary to call vp9_free_entries() anywhere except
when closing. And
Signed-off-by: Andreas Rheinhardt
---
libavcodec/frame_thread_encoder.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index e9a5a146ca..d4f86f7418 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b
On Wed, Sep 01, 2021 at 09:50:20AM +1000, Peter Ross wrote:
> On Tue, Aug 31, 2021 at 08:33:41PM +0200, Michael Niedermayer wrote:
> > Fixes: Timeout
> > Fixes:
> > 36875/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PICTOR_fuzzer-4842960888922112
> >
> > Found-by: continuous fuzzing process
On 02.09.2021 15:32, Timo Rothenpieler wrote:
On 02.09.2021 19:50, Dylan Fernando wrote:
I want to add support for the other formats, but I'm not sure how to find
video files to test it out. I tried looking through
https://samples.ffmpeg.org/, but I'm not sure which files on there are
the
form
LGTM
___
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".
Hi,
On Thu, Sep 2, 2021 at 3:08 AM Adam Chelminski
wrote:
>
> When encoding yuva420 (alpha) frames, the vpx encoder uses a second
> vpx_codec_ctx to encode the alpha stream. However, codec options were
> only being applied to the primary encoder. This patch updates
> codecctl_int and codecctl_int
Fixes FATE failures after 61c2c9ef8e66920c8ba308e8fa9f36ae602f8245.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/wma.mak | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/fate/wma.mak b/tests/fate/wma.mak
index 12a8fa989a..bc530998e8 100644
--- a/tests/fate/wma.mak
+++ b/tests/fate/w
On Wed, Sep 01, 2021 at 10:26:25AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-08-30 14:34:30)
> > On Mon, Aug 30, 2021 at 11:38:53AM +0200, Michael Niedermayer wrote:
> > > > I am not familiar with the generic scaler code, but it seems independent
> > > > of this partitioning,
LGTM
___
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".
LGTM
___
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, 2 Sep 2021, Andreas Rheinhardt wrote:
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them woul
On 2021-09-02 17:34, Andreas Rheinhardt wrote:
Also do not destroy and reinitialize mutexes and conditions when
certain input parameters change. Given that the decoder did not
create these variables at all during init, uninitialized mutexes
and conditions are destroyed before the very first initi
On 2021-09-02 17:41, Andreas Rheinhardt wrote:
The earlier code did not properly check these initializations:
It only recorded whether the part of init where these initializations
are has been reached, but it did not check whether the initializations
were successful, although destroying them woul
42 matches
Mail list logo
