This is really just a matter of choice. If you don't care about
spec-conformance in this particular case, top_field_first *could* be 1
and/or picture_structure *could* be not 3 even when
progressive_sequence is 1, so which one do you choose to believe? The
truth is, it doesn't even matter.
If you
In our documentation, we state
'Our IRC channels are publically logged and archives of both channels
can be viewed at ffmpeg-devel-irc.'
However, the archives in the link end with June 2020 i.e. at the time of
the Libera switchover. The topic for #ffmpeg-devel at Libera does
include "This
Gyan Doshi:
>
> In our documentation, we state
>
> 'Our IRC channels are publically logged and archives of both channels
> can be viewed at ffmpeg-devel-irc.'
>
> However, the archives in the link end with June 2020 i.e. at the time of
> the Libera switchover. The topic for #ffmpeg-devel at Libe
the top_field_first bit is only used to indicate the field order
when the picture is a frame picture (which consists of two fields)
but not when it is a field picture (which consists of one single
top or bottom field).
Signed-off-by: Tom Yan
---
libavcodec/mpegvideo_parser.c | 15 +--
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 24 ++
libavfilter/Makefile | 1 +
libavfilter/af_dialogenhance.c | 409 +
libavfilter/allfilters.c | 1 +
4 files changed, 435 insertions(+)
create mode 100644 libavfilter/af_di
On 2022-02-06 03:55 pm, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 24 ++
libavfilter/Makefile | 1 +
libavfilter/af_dialogenhance.c | 409 +
libavfilter/allfilters.c | 1 +
4 files changed, 4
That will make two e.
___
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".
Signed-off-by: Paul B Mahol
---
configure | 3 -
libavfilter/af_atempo.c | 126
2 files changed, 64 insertions(+), 65 deletions(-)
diff --git a/configure b/configure
index 5a8b52c77d..6ec25dd622 100755
--- a/configure
+++ b/configure
@@ -3
On 2022-02-06 04:54 pm, Paul B Mahol wrote:
That will make two e.
enhancedialogue
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-
On Sun, Feb 6, 2022 at 12:45 PM Gyan Doshi wrote:
>
>
> On 2022-02-06 04:54 pm, Paul B Mahol wrote:
> > That will make two e.
>
> enhancedialogue
>
> I very dislike that approach.
I will use dialoguenhance
> Gyan
> ___
> ffmpeg-devel mailing list
> f
It works in three mode:
0: don't ignore in-band ps
1: ignore in-band ps
-1: if corrupted data is detected, then ignore in-band ps afterwards
h264dec working hard to do error resilience, it doesn't drop a
whole packet when error is detected in a nalu. Then there is a
higher chance for fake sps/pps
Paul, thanks a lot for reviewing. The answer is - yes, the move saves up to
30% of performance for a single thread execution, so it is necessary.
I wasn't aware of the cases where width/height can change between frames -
never seen them in real life, but right you are, iI will change my code
accor
On Sun, Feb 6, 2022 at 3:58 PM Zhao Zhili wrote:
>
> It works in three mode:
> 0: don't ignore in-band ps
> 1: ignore in-band ps
> -1: if corrupted data is detected, then ignore in-band ps afterwards
>
> h264dec working hard to do error resilience, it doesn't drop a
> whole packet when error is de
On Sun, Feb 6, 2022 at 4:24 AM Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure | 3 -
> libavfilter/af_atempo.c | 126
> 2 files changed, 64 insertions(+), 65 deletions(-)
>
> diff --git a/configure b/configure
> index
On Sun, Feb 6, 2022 at 6:16 PM Pavel Koshevoy wrote:
> On Sun, Feb 6, 2022 at 4:24 AM Paul B Mahol wrote:
>
> > Signed-off-by: Paul B Mahol
> > ---
> > configure | 3 -
> > libavfilter/af_atempo.c | 126
> > 2 files changed, 64 insertion
> On Feb 6, 2022, at 11:31 PM, Hendrik Leppkes wrote:
>
> On Sun, Feb 6, 2022 at 3:58 PM Zhao Zhili wrote:
>>
>> It works in three mode:
>> 0: don't ignore in-band ps
>> 1: ignore in-band ps
>> -1: if corrupted data is detected, then ignore in-band ps afterwards
>>
>> h264dec working hard to
On Sun, Feb 6, 2022 at 10:24 AM Paul B Mahol wrote:
> On Sun, Feb 6, 2022 at 6:16 PM Pavel Koshevoy wrote:
>
> > On Sun, Feb 6, 2022 at 4:24 AM Paul B Mahol wrote:
> >
> > > Signed-off-by: Paul B Mahol
> > > ---
> > > configure | 3 -
> > > libavfilter/af_atempo.c | 126 ++
6 Feb 2022, 19:04 by pkoshe...@gmail.com:
> On Sun, Feb 6, 2022 at 10:24 AM Paul B Mahol wrote:
>
>> On Sun, Feb 6, 2022 at 6:16 PM Pavel Koshevoy wrote:
>>
>> > On Sun, Feb 6, 2022 at 4:24 AM Paul B Mahol wrote:
>>
>> > >
>> > >
>> > Is the old API being removed or deprecated?
>> > Just wonder
Signed-off-by: Paul B Mahol
---
doc/filters.texi| 28 +++
libavfilter/Makefile| 1 +
libavfilter/af_dialoguenhance.c | 407
libavfilter/allfilters.c| 1 +
4 files changed, 437 insertions(+)
create mode 100644 libavfilter/a
On Sun, Feb 6, 2022 at 11:52 AM Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi| 28 +++
> libavfilter/Makefile| 1 +
> libavfilter/af_dialoguenhance.c | 407
> libavfilter/allfilters.c| 1 +
>
On Thu, 27 Jan 2022, myp...@gmail.com wrote:
On Thu, Jan 27, 2022 at 1:09 PM "zhilizhao(赵志立)" wrote:
> On Jan 27, 2022, at 12:22 AM, Zhao Zhili wrote:
>
> ---
> libavformat/udp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
On Sun, 6 Feb 2022, lance.lmw...@gmail.com wrote:
On Sat, Feb 05, 2022 at 01:26:18PM -0800, Chad Fraleigh wrote:
Since any [valid] value over 255 is impossible in the IPv4 protocol (the TTL
field is only 8-bits), it should always be capped at 255 (for consistency) or
return an invalid valu
On 2/5/2022 6:09 PM, lance.lmw...@gmail.com wrote:
> On Sat, Feb 05, 2022 at 01:26:18PM -0800, Chad Fraleigh wrote:
>> Since any [valid] value over 255 is impossible in the IPv4 protocol (the TTL
>> field is only 8-bits), it should always be capped at 255 (for consistency)
>> or return an inval
On Sat, 5 Feb 2022, Gyan Doshi wrote:
bca30570d2 added a user option to set max_packet_size replacing
a hardcoded value. This had a side-effect of leaving the field
set to 0 when packet demuxing is carried out from another demuxer
using avpriv functions, which could lead to demux failure.
Ha
On Sun, Feb 06, 2022 at 02:27:09PM -0800, Chad Fraleigh wrote:
>
> On 2/5/2022 6:09 PM, lance.lmw...@gmail.com wrote:
> > On Sat, Feb 05, 2022 at 01:26:18PM -0800, Chad Fraleigh wrote:
> >> Since any [valid] value over 255 is impossible in the IPv4 protocol (the
> >> TTL field is only 8-bits), it
Several of our decoders support both frame- as well as slice-threading;
in case of the latter avctx->internal->thread_ctx points to
a SliceThreadContext, not to a frame-thread PerThreadContext.
So only treat avctx->internal->thread_ctx as the latter after
having checked that frame-threading is acti
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hapdec.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavcodec/hapdec.c b/libavcodec/hapdec.c
index 2c8c5c36ba..45c44ad78d 100644
--- a/libavcodec/hapdec.c
+++ b/libavcodec/hapdec.c
@@ -352,9 +352,6 @@ static int hap_decode(AVCodecContex
This is in preparation for further commits that will stop
using ThreadFrame for frame-threaded codecs that don't use
ff_thread_(await|report)_progress(); the API for those codecs
having inter-frame dependencies will live in threadframe.h.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/error_re
These will be used by the codecs that need allocated progress
and is in preparation for no longer using ThreadFrame by the codecs
that don't.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ffv1.c | 5 +++--
libavcodec/ffv1dec.c | 9 +
libavcodec/h264_picture.c | 4 ++
Use ff_thread_release_buffer() instead of av_frame_unref(),
as the former handles the case of non-thread-safe callbacks
properly. (This is possible now that ff_thread_release_buffer()
no longer requires a ThreadFrame.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/pthread_frame.c | 2 +-
1 fi
The majority of frame-threaded decoders (mainly the intra-only)
need exactly one part of ThreadFrame: The AVFrame. They don't
need the owners nor the progress, yet they had to use it because
ff_thread_(get|release)_buffer() requires it.
This commit changes this and makes these functions work with
Anton Khirnov:
> XvMC was last relevant over 10 years ago, if ever. There is no reason to
> use it today.
> ---
> MAINTAINERS| 1 -
> configure | 9 -
> libavcodec/Makefile| 2 -
> libavcodec/avcodec.h | 12 --
> libavcodec/erro
On 2/6/2022 10:46 PM, Andreas Rheinhardt wrote:
Anton Khirnov:
XvMC was last relevant over 10 years ago, if ever. There is no reason to
use it today.
---
MAINTAINERS| 1 -
configure | 9 -
libavcodec/Makefile| 2 -
libavcodec/avcode
Andreas Rheinhardt:
> Use -1 as the position in ff_cbs_insert_unit_data()
> which implicitly reuses frag->nb_units as the counter.
>
> Also switch to a do-while-loop, as it is more natural
> than a for-loop now that the counter is gone.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/c
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Monday, February 7, 2022 2:53 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC
> hwaccel code
>
> On 2/6/2022 10:46 PM, Andreas Rheinhardt wrote:
> > Anton K
As the potential failure of the av_mallocz(), the 's->alpha_context'
could be NULL and be dereferenced later.
Therefore, it should be better to check it and deal with it if fails
in order to prevent memory leak, same as the av_frame_alloc() in
ff_vp56_init().
Fixes: 39a3894ad5 ("lavc/vp6: Implemen
On 2022-02-07 03:59 am, Marton Balint wrote:
On Sat, 5 Feb 2022, Gyan Doshi wrote:
bca30570d2 added a user option to set max_packet_size replacing
a hardcoded value. This had a side-effect of leaving the field
set to 0 when packet demuxing is carried out from another demuxer
using avpriv f
On Wed, 2022-01-05 at 10:48 +0800, Wenbin Chen wrote:
> Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> decrease. The reason is that vaRenderPicture() and vaSyncBuffer() are
> called at the same time (vaRenderPicture() always followed by a
> vaSyncBuffer()). When we encod
> On Wed, 2022-01-05 at 10:48 +0800, Wenbin Chen wrote:
> > Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> > decrease. The reason is that vaRenderPicture() and vaSyncBuffer() are
> > called at the same time (vaRenderPicture() always followed by a
> > vaSyncBuffer()). Whe
39 matches
Mail list logo
