Quoting James Almer (2020-12-13 04:15:22)
> Fixes a decoding regression introduced by e9a2a87773, and as a side effect
> also
> fixes bogus values set to certain audio frames that had some samples
> discarded,
> where the offsets added to pts, pkt_dts and pkt_duration were not reflected in
> best
Quoting James Almer (2020-12-13 04:15:23)
> It's now set by the generic decode code.
>
> Signed-off-by: James Almer
> ---
> libavcodec/mjpegdec.c | 1 -
> 1 file changed, 1 deletion(-)
This and next one obviously ok
--
Anton Khirnov
___
ffmpeg-devel
Quoting James Almer (2020-12-13 01:17:52)
> On 12/12/2020 12:45 PM, Anton Khirnov wrote:
> > AVID streams, currently handled by the AVRN decoder can be (depending on
> > extradata contents) either MJPEG or raw video. To decode the MJPEG
> > variant, the AVRN decoder currently instantiates a MJPEG d
Am Sa., 12. Dez. 2020 um 10:57 Uhr schrieb Marton Balint :
>
> On Fri, 11 Dec 2020, Carl Eugen Hoyos wrote:
>
> > Attached patch fixes ticket #9005.
>
> Why are the codec_tags set at all? Can't we simply remove setting of all
> the codec tags in decklink? They hold no additional information to
> co
Quoting mindm...@gmail.com (2020-11-29 05:08:38)
> From: Mark Reid
>
> The current behaviour ends up squaring the avg_frame_rate if the conter mode
> flag is set.
> This messes up the timecode calculation, and looks to me as a regression that
> seems to have been introduced 428b4aac.
>
> The n
IMO checksumming side data contents is a bad idea and should not be done
at all. It's supposed to be an in-memory representation, which is
inherently platform-dependent - besides endianness there are potential
issues with padding or type sizes. If we want to test side data, we
should use some other
Why? Is it so hard to fix them work with latest API?
On Sat, Dec 12, 2020 at 5:05 PM Anton Khirnov wrote:
> Hi,
> as we are approaching the next major bump, vf_mcdeint and vf_uspp
> filters are still using deprecated libavcodec APIs.
>
> Does anyone care about preserving and maintaining them? If
Quoting Paul B Mahol (2020-12-13 13:40:15)
> Why? Is it so hard to fix them work with latest API?
It is not exactly obvious, since coded_frame is gone. I suppose you
could instantiate an encoder and a decoder to work around that, but it
all seems terribly inefficient. Lavfi seems to have some ME c
On Fri, Nov 20, 2020 at 12:28:59PM +0100, Matthias Neugebauer wrote:
> See FFmpeg patch:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/f7848cee-46c1-4caf-9191-a7babf5d6...@mailbox.org/
> ---
> docs/nut.txt | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/docs/n
On Sun, Dec 13, 2020 at 02:02:33PM +0100, Anton Khirnov wrote:
> Quoting Paul B Mahol (2020-12-13 13:40:15)
> > Why? Is it so hard to fix them work with latest API?
>
> It is not exactly obvious, since coded_frame is gone. I suppose you
> could instantiate an encoder and a decoder to work around t
On Sun, Dec 13, 2020 at 3:03 PM Michael Niedermayer
wrote:
> On Sun, Dec 13, 2020 at 02:02:33PM +0100, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2020-12-13 13:40:15)
> > > Why? Is it so hard to fix them work with latest API?
> >
> > It is not exactly obvious, since coded_frame is gone. I sup
On 12/13/2020 6:38 AM, Anton Khirnov wrote:
Quoting James Almer (2020-12-13 04:15:22)
Fixes a decoding regression introduced by e9a2a87773, and as a side effect also
fixes bogus values set to certain audio frames that had some samples discarded,
where the offsets added to pts, pkt_dts and pkt_du
On Sat, 28. Nov 14:46, Andriy Gelman wrote:
> From: Andriy Gelman
>
> As per signal() help (man 2 signal) the semantics of using signal may
> vary across platforms. It is suggested to use sigaction() instead.
>
> On my system, the capture signal is reset to the default handler after
> the first
Quoting Michael Niedermayer (2020-12-13 15:03:19)
> On Sun, Dec 13, 2020 at 02:02:33PM +0100, Anton Khirnov wrote:
> > Quoting Paul B Mahol (2020-12-13 13:40:15)
> > > Why? Is it so hard to fix them work with latest API?
> >
> > It is not exactly obvious, since coded_frame is gone. I suppose you
>
On Sun, Dec 13, 2020 at 2:05 AM Anton Khirnov wrote:
> Quoting mindm...@gmail.com (2020-11-29 05:08:38)
> > From: Mark Reid
> >
> > The current behaviour ends up squaring the avg_frame_rate if the conter
> mode flag is set.
> > This messes up the timecode calculation, and looks to me as a regres
Signed-off-by: James Almer
---
libavcodec/cuviddec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 61d7f36c79..331851231f 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -553,6 +553,12 @@ static int cuvid_output_fra
Signed-off-by: James Almer
---
libavcodec/cuviddec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 331851231f..49775b5a09 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -634,6 +634,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
On Sun, Dec 13, 2020 at 06:22:08PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-12-13 15:03:19)
> > On Sun, Dec 13, 2020 at 02:02:33PM +0100, Anton Khirnov wrote:
> > > Quoting Paul B Mahol (2020-12-13 13:40:15)
> > > > Why? Is it so hard to fix them work with latest API?
> > >
On Sun, 13 Dec 2020 15:51:04 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cuviddec.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 331851231f..49775b5a09 100644
> --- a/libavcodec/cuviddec.c
> +++ b
On Sun, 13 Dec 2020 15:51:03 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cuviddec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index 61d7f36c79..331851231f 100644
> --- a/libavcodec/cuviddec.c
> ++
On Wed, 9 Dec 2020 18:20:07 +0100
Paul B Mahol wrote:
>Signed-off-by: Paul B Mahol
>---
> doc/filters.texi | 34
> libavfilter/Makefile | 1 +
> libavfilter/af_stereoupmix.c | 352 +++
> libavfilter/allfilters.c | 1 +
> 4 files chan
21 matches
Mail list logo
