On Sat, 5 Dec 2020, Andreas Rheinhardt wrote:
Normally, video packets are muxed before audio packets for mxf (there is
a dedicated interleave function for this); furthermore the first (video)
packet triggers writing the actual header. Yet when the first video packet
fails the checks performed
The decoders in this set either have a fixed channel count, or read it
from the bitstream, and thus do not require the channel count as
external information.
Fixes various regressions since
81503ac58a763a36b1f57264013b1e76acb62b68, which requires a valid channel
count for decoders which do not set
On Thu, 3 Dec 2020, at 21:50, Thilo Borgmann wrote:
> no more replies against, so we shift the time to 15:00 UTC (7:00 US West,
> 16:00
> Berlin/London/Paris, 23:00 Peking).
>
> Happening at #ffmpeg-meeting.
This is in 1 hour, now.
--
Jean-Baptiste Kempf - President
+33 672 704 734
_
---
doc/dev_community/resolution_process.md | 83 +
1 file changed, 83 insertions(+)
create mode 100644 doc/dev_community/resolution_process.md
diff --git a/doc/dev_community/resolution_process.md
b/doc/dev_community/resolution_process.md
new file mode 100644
index 0
On Fri, 04. Dec 23:57, Andreas Rheinhardt wrote:
> The mxf_d10 muxer is very picky regarding the input it accepts:
> The only video accepted is MPEG-2 with absolutely constant bitrate,
> i.e. all packets need to have exactly the same size; and only a few
> bitrates are accepted.
>
> The sample fil
ff_eac3_exponent_init() set values twice when initializing a static
table; ergo the initialization code must not run concurrently with
a running EAC-3 encoder. Yet this code is executed every time an EAC-3
encoder is initialized. So use ff_thread_once() for this and also for a
similar initializatio
Signed-off-by: Andreas Rheinhardt
---
The mdct_init and allocate_sample_buffers function pointers could
actually be completely avoided by allocating the buffers in the
respective init functions after ff_ac3_encode_init() has returned.
The end of allocate_buffers() (which already differs based upon
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.h | 6 +++---
libavcodec/ac3enc_fixed.c| 2 +-
libavcodec/ac3enc_float.c| 2 +-
libavcodec/ac3enc_template.c | 8
libavcodec/eac3enc.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3dec.c | 11 +++
libavcodec/ac3dec_fixed.c | 1 +
libavcodec/ac3dec_float.c | 2 ++
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index eaa327a3ee..3e4bec56b1 100644
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3dec.c | 5 -
libavcodec/ac3dec_fixed.c | 2 +-
libavcodec/ac3dec_float.c | 4 ++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 3e4bec56b1..c7deb56e1c 100644
--- a/libav
Runtime checks for whether the encoder is fixed-point or not are
unnecessary here as this is a template; furthermore, there is no
fixed-point EAC-3 encoder, so some checks for whether one is in EAC-3
mode can be omitted when doing fixed-point encoding.
Signed-off-by: Andreas Rheinhardt
---
libav
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 42 ++--
libavcodec/ac3enc.h | 14 ++--
libavcodec/ac3enc_template.c | 24 +
3 files changed, 39 insertions(+), 41 deletions(-)
diff --git a/libavcodec/ac3enc
On 12/1/2020 3:09 PM, Mohammad Izadi wrote:
Ian, can you please take a look into it? And if it's fine to push it.
Thanks,
Mohammad
I removed the packet side data addition since it was not used by any
module. It can be added when a demuxer needs to propagate it.
Also removed the entry for dy
On Sat, Dec 05, 2020 at 11:41:23AM +0100, Hendrik Leppkes wrote:
> The decoders in this set either have a fixed channel count, or read it
> from the bitstream, and thus do not require the channel count as
> external information.
>
> Fixes various regressions since
> 81503ac58a763a36b1f57264013b1e7
Michael Niedermayer:
> On Sat, Dec 05, 2020 at 11:41:23AM +0100, Hendrik Leppkes wrote:
>> The decoders in this set either have a fixed channel count, or read it
>> from the bitstream, and thus do not require the channel count as
>> external information.
>>
>> Fixes various regressions since
>> 815
On Fri, Dec 04, 2020 at 09:26:11PM -0500, Andriy Gelman wrote:
> From: Andriy Gelman
>
> One of the inputs to the fate test has an rgba pixel format which needs
> to be converted to rgb32 (argb on BE) for the hqx filter. Because auto
> scaling in the fate test is disabled, this needs a separate s
On Sun, Nov 15, 2020 at 01:14:55AM +0100, Marton Balint wrote:
>
>
> On Fri, 6 Nov 2020, Michael Niedermayer wrote:
>
> > On Wed, Nov 04, 2020 at 10:44:56PM +0100, Marton Balint wrote:
> > >
> > >
> > > On Wed, 4 Nov 2020, Michael Niedermayer wrote:
> > >
> > > > we have "millisecond" based f
Andriy Gelman:
> On Fri, 04. Dec 23:57, Andreas Rheinhardt wrote:
>> The mxf_d10 muxer is very picky regarding the input it accepts:
>> The only video accepted is MPEG-2 with absolutely constant bitrate,
>> i.e. all packets need to have exactly the same size; and only a few
>> bitrates are accepted
On Sat, Dec 5, 2020 at 11:44 PM Michael Niedermayer
wrote:
>
> On Sat, Dec 05, 2020 at 11:41:23AM +0100, Hendrik Leppkes wrote:
> > The decoders in this set either have a fixed channel count, or read it
> > from the bitstream, and thus do not require the channel count as
> > external information.
Nothing guarantees that the size of side data containing a palette
is actually divisible by four (although it should be); but for
big-endian systems, an algorithm is used that presupposed this.
So switch to an algorithm that does not overread: It processes
four bytes at a time, but only if all of t
Do this by converting big-endian side data to little endian for
checksumming. Fixes the ts-demux FATE test.
Signed-off-by: Andreas Rheinhardt
---
a) When commenting the #if HAVE_BIGENDIAN out, I get the same checksum
for the test in [1] as Andriy got on a real BE system; I have not done
more test
Andriy Gelman:
> On Fri, 04. Dec 23:57, Andreas Rheinhardt wrote:
>> The mxf_d10 muxer is very picky regarding the input it accepts:
>> The only video accepted is MPEG-2 with absolutely constant bitrate,
>> i.e. all packets need to have exactly the same size; and only a few
>> bitrates are accepted
On Sun, Nov 22, 2020 at 8:32 PM wrote:
> From: Mark Reid
>
> Hi,
> This patch handles NaNs more like the offical implentation handles them,
> preserving
> the original bits.
>
>
> https://github.com/AcademySoftwareFoundation/openexr/blob/RB-2.5/IlmBase/Half/toFloat.cpp#L111
>
> It also adds a fa
Marton Balint:
>
>
> On Sat, 5 Dec 2020, Andreas Rheinhardt wrote:
>
>> Normally, video packets are muxed before audio packets for mxf (there is
>> a dedicated interleave function for this); furthermore the first (video)
>> packet triggers writing the actual header. Yet when the first video
>> p
24 matches
Mail list logo
