Signed-off-by: Linjie Fu
---
tests/api/api-h264-slice-test.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/api/api-h264-slice-test.c b/tests/api/api-h264-slice-test.c
index dee93b8..b7aa405 100644
--- a/tests/api/api-h264-slice-test.c
+++ b/tests/api/api-h264-slice-test.c
@@ -24,7
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Wednesday, April 1, 2020 04:26
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: [FFmpeg-devel] [PATCH]lavfi/deshake_opencl: Do not use bool
>
> Hi!
>
> Attached patch fixes compilation with opencl for
On Wed, 01. Apr 00:38, Michael Niedermayer wrote:
> On Sun, Mar 08, 2020 at 11:49:47AM -0400, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > struct v4l2_selection contains reserved bytes which should be set to
> > zero before the ioctl call.
> >
> > Fixes valgrind error:
> > Syscall param
Using a compiler with a different host triplet is considered
cross-compiling, even when it is for the same architecture as the
build system. With such a cross-compiler, it is still valid to
optimize builds with --cpu=host. Make the condition that aborts in
this case into a warning instead, since
Marton Balint:
>
>
> On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
>
>> It is unnecessary to call prepare_input_packet if there is no packet as
>> it doesn't do anything, except when the currently inactive code guarded
>> by !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX becomes active:
>>
when the last frame of capture is dequeueed,
driver may send this V4L2_EVENT_EOS event,
If this event is received, then the capture buffers have been flushed and
avcodec_receive_packet()/avcodec_receive_frame() can return AVERROR_EOF.
Otherwise, the draining continues until all the capture buffers
On Wed, Apr 1, 2020 at 6:17 AM Michael Niedermayer
wrote:
>
> On Tue, Mar 31, 2020 at 05:32:41PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > This patch adds functional changes to support the
> > PPT marker.
> > ---
> > libavcodec/jpeg2000dec.c | 85
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-29 06:14:37)
>> If one calls av_opt_set() with an incorrect string to set the value of
>> an option of type AV_OPT_TYPE_VIDEO_RATE, the given string is used in a
>> log message via %s. This also happens when the string is actually a
>>
On Tue, Mar 31, 2020 at 05:32:41PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch adds functional changes to support the
> PPT marker.
> ---
> libavcodec/jpeg2000dec.c | 85 +++-
> 1 file changed, 76 insertions(+), 9
On Sun, 29. Mar 10:53, Andriy Gelman wrote:
> On Tue, 17. Mar 19:29, Ming Qian wrote:
> > v4l2 set the frame rate through frame intervals,
> > not set frame rate directly.
> > the frame rate and frame intervals are reciprocal.
> > so in libavdevice/v4l2.c we can see the following code:
> >
Signed-off-by: Marton Balint
---
libavformat/segment.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 2a838c7da7..60b72b7d15 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -971,7 +971,8 @@ calc_times:
1 sec might not be enough for the cards to detect the format...
Signed-off-by: Marton Balint
---
libavdevice/decklink_dec.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index c8d931517e..82106aa69e 100644
On Sat, 28 Mar 2020, Andreas Rheinhardt wrote:
Marton Balint:
Previously only 1:1 bitstream filters were supported, the end of the stream was
not signalled to the bitstream filters and time base changes were ignored.
Signed-off-by: Marton Balint
---
libavformat/internal.h | 1 +
On Sun, Mar 08, 2020 at 11:49:47AM -0400, Andriy Gelman wrote:
> From: Andriy Gelman
>
> struct v4l2_selection contains reserved bytes which should be set to
> zero before the ioctl call.
>
> Fixes valgrind error:
> Syscall param ioctl(VKI_V4L2_S_SELECTION) points to uninitialised byte(s)
>
>
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
When no packet could be output, the interleavement functions
nevertheless initialized the packet destined for output (with the
exception of the data and size fields, making the initialization
pointless), although it will not be used at all. So
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
The earlier documentation claimed that av_interleaved_write_frame()
always orders by dts, which is not necessarily true when using muxers
with custom interleavement functions or the audio_preload option.
Furthermore, the documentation stated
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
av_interleaved_write_frame() already returns blank packets.
Signed-off-by: Andreas Rheinhardt
---
doc/examples/remuxing.c | 1 -
fftools/ffmpeg.c| 1 -
2 files changed, 2 deletions(-)
diff --git a/doc/examples/remuxing.c
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
write_packet() currently saves the original timestamps of the packet it
got and restores them in case writing fails. This is unnecessary as none
of write_packet()'s callers make any use of these timestamps at all. So
remove this and add a general
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
The documentation of av_write_frame() explicitly states that the function
doesn't take ownership of the packets sent to it; while av_write_frame()
does not directly unreference the packets after having written them, it
nevertheless modifies the
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
1. When an error happened in ff_interleave_add_packet() during
interleaving a packet for output, said packet would not be unreferenced
in ff_interleave_add_packet(), but would be zeroed in
av_interleaved_write_frame(), which results in a memleak.
Thanks. Updated.
On Tue, Mar 31, 2020 at 5:23 AM Moritz Barsnick wrote:
> On Mon, Mar 30, 2020 at 15:27:46 -0700, John Rummell wrote:
> > +if (c->aes_decrypt)
> > +av_free(c->aes_decrypt);
>
> av_free() already does the NULL pointer check for you.
>
> Moritz
>
Hi!
Attached patch fixes compilation with opencl for powerpc where bool
always had a meaning different from other architectures. Other
work-arounds certainly exist but we usually don't like bool anyway.
Fixes ticket #8591.
Please comment, Carl Eugen
From 3e5e2bf95aaf1e782eba7243e053f0b0d5955699
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
If writing an uncoded frame fails at the preparatory steps of
av_[interleaved_]write_frame(), the frame would be either not freed
at all in case of av_write_frame() or would leak when the fake packet
would be unreferenced like an ordinary packet.
I'm a lit bit crazy with some especific video files. I want to decode it
and change ffmpeg to specifically decode 608 Closed Captions.
The AVI file format/codec is DVCPRO at SD(720x480) resolution. The enconder
is "Matrox DSX AVI file . Format: 6. Build: 1.0.0.451"
That's was ok, until moment i
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet(); it is of course nonsense and has
been replaced by an accurate
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
If ff_interleave_add_packet failed, the content of the newly created
packet new_pkt would leak.
Also, it is unnecessary to zero-initialize a packet that will be put
into av_new_packet lateron as the latter already initializes the packet.
On Tue, 31 Mar 2020, Andreas Rheinhardt wrote:
It is unnecessary to call prepare_input_packet if there is no packet as
it doesn't do anything, except when the currently inactive code guarded
by !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX becomes active:
Then attempting to access
On Tue, Mar 31, 2020 at 03:51:06PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/x86/vf_v360.asm| 46 ++
> libavfilter/x86/vf_v360_init.c | 6 +
> 2 files changed, 52 insertions(+)
this fails to build on x86-32
On Tue, Mar 31, 2020 at 05:45:39PM +0200, Moritz Barsnick wrote:
> On Sat, Mar 28, 2020 at 22:12:45 +0100, Michael Niedermayer wrote:
> > +if (ctx->tex_size != (avctx->coded_width / TEXTURE_BLOCK_W)
> > +*(avctx->coded_height / TEXTURE_BLOCK_H)
> > +*tex_rat[t]) {
On Tue, Mar 31, 2020 at 09:20:34AM +0800, myp...@gmail.com wrote:
> On Tue, Mar 31, 2020 at 5:29 AM Michael Niedermayer
> wrote:
> >
> > On Mon, Mar 30, 2020 at 04:22:51PM +0800, Jun Zhao wrote:
> > > From: Jun Zhao
> > >
> > > There have been some reports about FLV timestamp discontinuities
On Sat, Mar 28, 2020 at 10:33:10PM +0100, Paul B Mahol wrote:
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin
On Sat, Mar 07, 2020 at 10:32:53AM -0500, David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system. With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host.
I just realized the patch contained some stray UTF-8 characters. Sorry
about that. Attached is a patch with an updated commit message without the
annoying characters. The code is unchanged.
>
0001-avformat-movenc-add-write_clli-flag-to-write-clli-at.patch
Description: Binary data
The mdcv atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as
experimental and the mdcv atom is not written by default.
The mdcv atom is referenced by e.g., [1][2] and is already parsed in FFmpeg
in mov.c.
Once ISO/IEC 14496-12 standardizes the mdcv atom (which I assume it will?)
then we
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Tuesday, March 31, 2020 23:44
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/7] lavc/libopenh264enc: Add default
> qmin/qmax support
>
> On 3/31/2020 12:31 PM, Linjie Fu wrote:
> > Set default QP range to (1, 51)
The switch cases were missing:
- Primaries: bt470m, film, smpte428, and ebu3213.
- TRCs: gamma22, gamma28, linear, log, log_sqrt, iec61966_2_4, bt1361,
iec61966_2_1, bt2020_10bit, and bt2020_12bit.
- Space: rgb, fcc, ycgco, bt2020_cl, smpte2085, chroma-derived-nc,
chroma-derived-c,
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Tuesday, March 31, 2020 23:46
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 7/7] lavc/libopenh264enc: separate
> svc_encode_init() into several functions
>
> On 3/31/2020 12:33 PM, Linjie Fu wrote:
> > Separate the
On 3/31/2020 12:31 PM, Linjie Fu wrote:
> Set default QP range to (1, 51) instead of (2, 32).
>
> QP = 0 is not well supported currently in libopenh264. If iMaxQp/iMinQp
> equals 0, the QP range would be changed unexpectedly inside libopenh264
> with a warning:
>
> Warning:Change QP Range
On 3/31/2020 10:51 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/x86/vf_v360.asm| 46 ++
> libavfilter/x86/vf_v360_init.c | 6 +
> 2 files changed, 52 insertions(+)
>
> diff --git a/libavfilter/x86/vf_v360.asm
On 3/31/2020 12:33 PM, Linjie Fu wrote:
> Separate the initialization procedure into different functions.
>
> Make it more readable and easier to be extended.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/libopenh264enc.c | 302
> +++-
> 1 file
On Sat, Mar 28, 2020 at 22:12:45 +0100, Michael Niedermayer wrote:
> +if (ctx->tex_size != (avctx->coded_width / TEXTURE_BLOCK_W)
> +*(avctx->coded_height / TEXTURE_BLOCK_H)
> +*tex_rat[t]) {
It would be easier to recognize that this is a multiplication and not a
ff_vaapi_encode_close() is not enough to free the resources like cbs
if initialization failure happens after codec->configure (except for
vp8/vp9).
We need to call avctx->codec->close() to deallocate, otherwise memory
leak happens.
Add FF_CODEC_CAP_INIT_CLEANUP for vaapi encoders and deallocate
Separate the initialization procedure into different functions.
Make it more readable and easier to be extended.
Signed-off-by: Linjie Fu
---
libavcodec/libopenh264enc.c | 302 +++-
1 file changed, 186 insertions(+), 116 deletions(-)
diff --git
"slice_mode" seems to be unnecessary since it could be determined by
-slices/max_nal_size.
default:SM_FIXEDSLCNUM_SLICE mode with cpu-number slices.
-slices N: SM_FIXEDSLCNUM_SLICE mode with N slices.
-max_nal_size: SM_SIZELIMITED_SLICE mode with limited size slices.
This could be
Libopenh264enc would set the slice according to the number of cpu cores
if uiSliceNum equals to 0 (auto) in SM_FIXEDSLCNUM_SLICE mode.
Prompt a warning for user to catch this.
Signed-off-by: Linjie Fu
---
libavcodec/libopenh264enc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Signed-off-by: Linjie Fu
---
libavcodec/libopenh264enc.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index fcf3e4d..56703a4 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@
Signed-off-by: Linjie Fu
---
libavcodec/libopenh264enc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 47d66e4..fcf3e4d 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -335,6 +335,8 @@ static
Signed-off-by: Linjie Fu
---
libavcodec/libopenh264enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 7cd1efe..47d66e4 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -202,8
Since it has been commented out, remove it.
Introduced in e37f161e66e.
Signed-off-by: Linjie Fu
---
libavcodec/libx264.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a08fe0c..9f9907a 100644
--- a/libavcodec/libx264.c
+++
Set default QP range to (1, 51) instead of (2, 32).
QP = 0 is not well supported currently in libopenh264. If iMaxQp/iMinQp
equals 0, the QP range would be changed unexpectedly inside libopenh264
with a warning:
Warning:Change QP Range from(0,51) to (12,42)
Signed-off-by: Linjie Fu
---
[1]
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/libsrt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 2d6fc4b..c01d639 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -96,8 +96,8 @@
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/libsrt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index c01d639..4de575b 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -361,7 +361,7 @@ static int
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/protocols.texi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index e510019..7aa7585 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1255,7 +1255,7 @@
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 2 ++
libavfilter/v360.h| 1 +
libavfilter/vf_v360.c | 56 +++
3 files changed, 59 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 44d41a87cf..8827aac316 100644
---
Signed-off-by: Paul B Mahol
---
libavfilter/x86/vf_v360.asm| 46 ++
libavfilter/x86/vf_v360_init.c | 6 +
2 files changed, 52 insertions(+)
diff --git a/libavfilter/x86/vf_v360.asm b/libavfilter/x86/vf_v360.asm
index 5b241220d8..e1908e5e71 100644
---
Marton Balint:
> Previously only 1:1 bitstream filters were supported, the end of the stream
> was
> not signalled to the bitstream filters and time base changes were ignored.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/internal.h | 1 +
> libavformat/mux.c | 128
>
If writing an uncoded frame fails at the preparatory steps of
av_[interleaved_]write_frame(), the frame would be either not freed
at all in case of av_write_frame() or would leak when the fake packet
would be unreferenced like an ordinary packet.
There is also a memleak when the output format is
Andreas Rheinhardt:
> According to C99, there has to be at least one argument for every ...
> in a variadic function-like macro. In practice most (all?) compilers also
> allow to leave it completely out, but it is nevertheless required: In a
> variadic macro "there shall be more arguments in the
When no packet could be output, the interleavement functions
nevertheless initialized the packet destined for output (with the
exception of the data and size fields, making the initialization
pointless), although it will not be used at all. So remove the
initializations.
Signed-off-by: Andreas
If writing an uncoded frame fails at the preparatory steps of
av_[interleaved_]write_frame(), the frame would be either not freed
at all in case of av_write_frame() or would leak when the fake packet
would be unreferenced like an ordinary packet.
There is also a memleak when the output format is
Marton Balint:
> In preparation for N:M bsf support.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/mux.c | 82
> +++
> 1 file changed, 47 insertions(+), 35 deletions(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index
If ff_interleave_add_packet failed, the content of the newly created
packet new_pkt would leak.
Also, it is unnecessary to zero-initialize a packet that will be put
into av_new_packet lateron as the latter already initializes the packet.
Therefore this has been removed, too.
Signed-off-by:
The earlier documentation claimed that av_interleaved_write_frame()
always orders by dts, which is not necessarily true when using muxers
with custom interleavement functions or the audio_preload option.
Furthermore, the documentation stated that libavformat takes ownership
of the reference of
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it
was forgotten to remove the comment pertaining to it. Said comment now
appeared to apply to interleave_packet(); it is of course nonsense and has
been replaced by an accurate description.
2. The description of
av_interleaved_write_frame() already returns blank packets.
Signed-off-by: Andreas Rheinhardt
---
doc/examples/remuxing.c | 1 -
fftools/ffmpeg.c| 1 -
2 files changed, 2 deletions(-)
diff --git a/doc/examples/remuxing.c b/doc/examples/remuxing.c
index 9e4d1031b4..13469d55ef 100644
---
The documentation of av_write_frame() explicitly states that the function
doesn't take ownership of the packets sent to it; while av_write_frame()
does not directly unreference the packets after having written them, it
nevertheless modifies the packet in various ways:
1. The timestamps might be
write_packet() currently saves the original timestamps of the packet it
got and restores them in case writing fails. This is unnecessary as none
of write_packet()'s callers make any use of these timestamps at all. So
remove this and add a general comment to the function that timestamps
may be
1. When an error happened in ff_interleave_add_packet() during
interleaving a packet for output, said packet would not be unreferenced
in ff_interleave_add_packet(), but would be zeroed in
av_interleaved_write_frame(), which results in a memleak.
2. When no error happened in
It is unnecessary to call prepare_input_packet if there is no packet as
it doesn't do anything, except when the currently inactive code guarded
by !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX becomes active:
Then attempting to access pkt->stream_index will crash.
Signed-off-by: Andreas
This patchset is a slightly revised version of the remaining patches of
a patchset I originally sent last August [1]. I resend it because Marton
requested it [2]. I have also added three new patches at the end (but
they actually don't depend on any of the earlier patches).
This patchset intends
On Mon, Mar 30, 2020 at 15:27:46 -0700, John Rummell wrote:
> +if (c->aes_decrypt)
> +av_free(c->aes_decrypt);
av_free() already does the NULL pointer check for you.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 31/03/2020 00:25, Michael Bradshaw wrote:
> If this really breaks things for people (which I highly doubt it will) they
> can always send a patch with a better and more robust implementation. But I
> feel strongly that we should not stabilize the write_colr flag with this
> auto-guessing logic.
There should have language in the metadata of streams which show to user
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 49 +++
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index
> Am 31.03.2020 um 12:24 schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2020-03-31 11:56:44)
>>> Am Di., 31. März 2020 um 11:18 Uhr schrieb Anton Khirnov
>>> :
>>>
>>> Quoting Carl Eugen Hoyos (2020-03-28 13:54:22)
Hi!
Attached patch allows to work-around ticket #7140,
From: Gautam Ramakrishnan
This patch splits the jpeg2000_decode_packet() function.
---
libavcodec/jpeg2000dec.c | 150 ++-
1 file changed, 116 insertions(+), 34 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index
From: Gautam Ramakrishnan
This patch adds functional changes to support the
PPT marker.
---
libavcodec/jpeg2000dec.c | 85 +++-
1 file changed, 76 insertions(+), 9 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index
From: Gautam Ramakrishnan
This patch allows decoding of j2k streams which do
not have an EOC marker.
---
libavcodec/jpeg2000dec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 23e43ff052..d27d753992 100644
Hi,
Thanks for your reply let me know the reasons why using java wrapper instead of
native apis.
These days I've already started the work of adding mediacodec encoder support.
And i also want to use the java wrappers, because I found the
mediacodec_wrapper.c
wrapped funcations should also can be
Quoting Carl Eugen Hoyos (2020-03-31 11:56:44)
> Am Di., 31. März 2020 um 11:18 Uhr schrieb Anton Khirnov :
> >
> > Quoting Carl Eugen Hoyos (2020-03-28 13:54:22)
> > > Hi!
> > >
> > > Attached patch allows to work-around ticket #7140, tested on a system
> > > with a lot of memory.
> >
> > This
Am Di., 31. März 2020 um 11:18 Uhr schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2020-03-28 13:54:22)
> > Hi!
> >
> > Attached patch allows to work-around ticket #7140, tested on a system
> > with a lot of memory.
>
> This looks very ad-hoc.
Is there another part of FFmpeg that rightfully
Quoting Andreas Rheinhardt (2020-03-29 06:14:37)
> If one calls av_opt_set() with an incorrect string to set the value of
> an option of type AV_OPT_TYPE_VIDEO_RATE, the given string is used in a
> log message via %s. This also happens when the string is actually a
> nullpointer in which case
Quoting Steven Liu (2020-03-29 03:04:26)
> There should have lang in the metadata of streams which show to user
>
> Signed-off-by: Steven Liu
> ---
> libavformat/dashdec.c | 49 +++
> 1 file changed, 45 insertions(+), 4 deletions(-)
>
> diff --git
Quoting David Bryant (2020-03-28 21:22:40)
> On 3/28/20 6:23 AM, Anton Khirnov wrote:
> > Quoting David Bryant (2020-03-27 23:51:19)
> >> On 3/27/20 5:57 AM, Anton Khirnov wrote:
> >>> The current design, where
> >>> - proper init is called for the first per-thread context
> >>> - first thread's
On Tue, Mar 31, 2020 at 9:20 AM myp...@gmail.com wrote:
>
> On Tue, Mar 31, 2020 at 5:29 AM Michael Niedermayer
> wrote:
> >
> > On Mon, Mar 30, 2020 at 04:22:51PM +0800, Jun Zhao wrote:
> > > From: Jun Zhao
> > >
> > > There have been some reports about FLV timestamp discontinuities present.
>
Quoting Carl Eugen Hoyos (2020-03-28 13:54:22)
> Hi!
>
> Attached patch allows to work-around ticket #7140, tested on a system
> with a lot of memory.
This looks very ad-hoc. The right thing to do is fix arbitrary limits in
av_malloc_array(). That INT_MAX there looks wrong.
--
Anton Khirnov
Am Di., 31. März 2020 um 06:50 Uhr schrieb Roger Pack :
>
> On Wed, Feb 26, 2020 at 4:36 AM Carl Eugen Hoyos wrote:
> >
> > Am Mi., 26. Feb. 2020 um 06:57 Uhr schrieb Roger Pack
> > :
> > >
> > > Original bigger patch is enough for now. Please merge, thanks!
> >
> > What happened to your git
Quoting Michael Niedermayer (2020-03-30 23:55:25)
> On Mon, Mar 30, 2020 at 01:45:23PM +0200, Anton Khirnov wrote:
> > Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS
> > flag.
> >
> > Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE*
> > API.
> > ---
>
On Tue, 31 Mar 2020, Matthieu Bouron wrote:
On Fri, Mar 27, 2020 at 04:21:59PM +0800, aistoy wrote:
Hi, I want to know why ffmpeg do not include mediacodec encoder, just include mediacodec decoder.
And why the decoder implemention don’t use mediacodec native api, but use jni call mediacodec
On Fri, Mar 27, 2020 at 04:21:59PM +0800, aistoy wrote:
> Hi, I want to know why ffmpeg do not include mediacodec encoder, just include
> mediacodec decoder.
> And why the decoder implemention don’t use mediacodec native api, but use jni
> call mediacodec java methods.
> If i plan to add the
---
libavcodec/mediacodecdec_common.c | 100 ++
1 file changed, 100 insertions(+)
diff --git a/libavcodec/mediacodecdec_common.c
b/libavcodec/mediacodecdec_common.c
index f0752fa6261..404ed282275 100644
--- a/libavcodec/mediacodecdec_common.c
+++
90 matches
Mail list logo
