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 mediacodec encoder, what do you think i should pay
attention to ?
t
Quoting Andreas Rheinhardt (2019-12-01 11:05:44)
> This commit updates the documentation of av_read_frame() to match its
> actual behaviour in several ways:
>
> 1. On success, av_read_frame() always returns refcounted packets.
> 2. It can handle uninitialized packets.
> 3. On error, it always retu
Quoting Andreas Rheinhardt (2020-03-27 03:25:13)
> av_packet_ref() mostly treated the destination packet dst as uninitialized,
> i.e. the destination fields were simply overwritten. But if the source
> packet was not reference-counted, dst->buf was treated as if it pointed
> to an already allocated
Quoting Andreas Rheinhardt (2020-03-27 03:25:14)
> Up until now, it was completely unspecified what the content of the
> destination packet dst was on error. Depending upon where the error
> happened calling av_packet_unref() on dst might be dangerous.
>
> This commit changes this by making sure t
Anton Khirnov:
> Quoting Andreas Rheinhardt (2019-12-01 11:05:44)
>> This commit updates the documentation of av_read_frame() to match its
>> actual behaviour in several ways:
>>
>> 1. On success, av_read_frame() always returns refcounted packets.
>> 2. It can handle uninitialized packets.
>> 3. On
An AVIStream (intended to be used as private data for an AVStream) would
leak in this scenario.
Also return a more fitting error code instead of AVERROR_INVALIDDATA.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avidec.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff -
If one uses a build without dv demuxer, an AVIStream struct that is
destined to be used as private data for an AVStream by the avi demuxer
would leak, because it has been moved from the AVStream (that is going
to be freed) and only stored in a local variable (in order to be used
for another AVStrea
Using ff_free_stream() makes the code more readable, more future-proof
(the old code freed AVCodecContexts and AVCodecParameters and its
substructures manually, so that there is a chance that there would be a
memleak for some time if new substructures were added) and reduces
code size.
Signed-off-
Quoting Moritz Barsnick (2020-03-24 09:47:14)
> On Sun, Mar 22, 2020 at 09:59:21 +0100, Steve Lhomme wrote:
> > Always use a comma at the end, order elements by value.
>
> IIUC, this is strictly a C99(+) "feature", so should probably be
> mentioned here:
> https://ffmpeg.org/developer.html#C-langu
The code for GAB2 subtitles predates refcounting AVPackets. So in order
to transfer the ownership of a packet's data pkt->data was simply stored
and the packet zeroed; in the end (i.e. in the read_close-function) this
data was then simply freed with av_freep(). This of course leads to a leak
of an
Please See the updated patch below which applies as expected.
From 8f741899b7f6b3884d613f622a548b353af2489e Mon Sep 17 00:00:00 2001
From: Tom Needham <06needh...@gmail.com>
Date: Sun, 21 Jul 2019 21:11:19 +0100
Subject: [PATCH] avformat: Add Dynacolor MVC Demuxer
This demuxer adds support for de
Specifically, between the user-facing one and the first frame thread
one.
This is fragile and dangerous, allocate separate private data for each
per-thread context.
---
libavcodec/pthread_frame.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.
This is extremely fragile against reordering and hides what is actually
being copied. Copy all the fields manually instead.
---
Review comments applied and branch rebased against master.
13/14 has been acked and is only included for completeness.
---
libavcodec/mpeg4videodec.c | 28 ++
Currently the frame pool used by the default get_buffer2()
implementation is a single struct, allocated when opening the decoder.
A pointer to it is simply copied to each frame thread and we assume that
no thread attempts to modify it at an unexpected time. This is rather
fragile and potentially da
This is a constant codec property, so a capability flag is more appropriate.
---
doc/multithreading.txt | 5 +++--
libavcodec/ffv1dec.c | 4 +---
libavcodec/h264dec.c | 5 ++---
libavcodec/hevcdec.c | 5 ++---
libavcodec/internal.h | 20 +---
libavcod
Use the AVFrame API to properly allocate and free frames for delayed
release.
---
libavcodec/pthread_frame.c | 40 --
1 file changed, 25 insertions(+), 15 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 19073b1253..639c5c
Such errors are not necessarily fatal and decoding might still be
possible, e.g. it happens for MVC streams where we do not handle the
subset SPS thus failing to parse its corresponding PPS.
---
libavcodec/h264dec.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/l
It represents the relationship between them more naturally and will be
useful in the following commits.
Allows significantly more frames in fate-h264-attachment-631 to be
decoded.
---
libavcodec/h264_parser.c | 16 +---
libavcodec/h264_ps.c | 30 +-
libavcodec/h264_p
Those SEIs refer to the currently active SPS. However, since the SEI
NALUs precede the coded picture data in the bitstream, the active SPS is
in general not known when we are decoding the SEI.
Therefore, store the content of the picture timing SEIs and actually
parse it when the active SPS is know
This is extremely fragile against reordering and hides what is actually
being copied. Copy all the fields manually instead.
---
libavcodec/pthread_frame.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 639c5ce
This has been cargo culted from mpegvideo and serves no useful purpose.
It will be initialize correctly in h264_field_start()
---
libavcodec/h264dec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 7679567548..57f4fec3ca 100644
--- a/libavcodec
---
libavcodec/decode.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 8925ce6edc..f43dc0dd5d 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1595,7 +1595,7 @@ static int update_frame_pool(AVCodecContext *a
This tells the parsing functions the payload size and prevents them from
overreading.
---
libavcodec/h264_sei.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index a565feabe2..32d13985f3 100644
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to
The name is misleading, this function does a lot more than just flushing
the DPB.
---
libavcodec/h264dec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 67a9cb5438..7679567548 100644
--- a/libavcodec/h264dec.c
+++ b/libav
From: Gautam Ramakrishnan
This patch adds support for the JPEG2000 PPT marker. This patch hence,
fixes #4610. The patch was tested on the samples posted along with
ticket #4610.
---
libavcodec/jpeg2000dec.c | 348 +--
1 file changed, 331 insertions(+), 17 dele
On Wed, 18 Mar 2020 15:19:19 +0100
"Carl Eugen Hoyos" wrote:
>
> Any restrictions on track_count and sample_rate that can be used for
> auto-detection?
>
I've done a preliminary probe function. How's this?
On all the files I tested, I received one of two values:
99 - For music (these have an e
Am Fr., 27. März 2020 um 14:47 Uhr schrieb :
>
> From: Gautam Ramakrishnan
>
> This patch adds support for the JPEG2000 PPT marker. This patch hence,
> fixes #4610. The patch was tested on the samples posted along with
> ticket #4610.
Your patch adds a compile-time warning here, please fix that.
Am Fr., 27. März 2020 um 15:29 Uhr schrieb Carl Eugen Hoyos
:
>
> Am Fr., 27. März 2020 um 14:47 Uhr schrieb :
> >
> > From: Gautam Ramakrishnan
> >
> > This patch adds support for the JPEG2000 PPT marker. This patch hence,
> > fixes #4610. The patch was tested on the samples posted along with
> >
On 3/27/2020 9:57 AM, Anton Khirnov wrote:
> Such errors are not necessarily fatal and decoding might still be
> possible, e.g. it happens for MVC streams where we do not handle the
> subset SPS thus failing to parse its corresponding PPS.
> ---
> libavcodec/h264dec.c | 12
> 1 file c
Hi,
I was a bit apprehensive about removing the jpeg2000_decode_packet()
function. I had basically split that function into 2 separate ones.
Should I keep it till we add more changes to the decoder or do I
remove it now itself?
On Fri, Mar 27, 2020 at 8:03 PM Carl Eugen Hoyos wrote:
>
> Am Fr.,
Am Fr., 27. März 2020 um 14:47 Uhr schrieb :
>
> From: Gautam Ramakrishnan
>
> This patch adds support for the JPEG2000 PPT marker. This patch hence,
> fixes #4610. The patch was tested on the samples posted along with
> ticket #4610.
Some frames in this sample are now decoded correctly, some sti
Am Fr., 27. März 2020 um 15:58 Uhr schrieb Gautam Ramakrishnan
:
> I was a bit apprehensive about removing the jpeg2000_decode_packet()
> function. I had basically split that function into 2 separate ones.
> Should I keep it till we add more changes to the decoder or do I
> remove it now itself?
On 3/27/2020 9:57 AM, Anton Khirnov wrote:
> ---
> libavcodec/decode.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 8925ce6edc..f43dc0dd5d 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -159
On Fri, Mar 27, 2020 at 8:30 PM Carl Eugen Hoyos wrote:
>
> Am Fr., 27. März 2020 um 15:58 Uhr schrieb Gautam Ramakrishnan
> :
>
> > I was a bit apprehensive about removing the jpeg2000_decode_packet()
> > function. I had basically split that function into 2 separate ones.
> > Should I keep it til
On 3/27/2020 9:57 AM, Anton Khirnov wrote:
> This tells the parsing functions the payload size and prevents them from
> overreading.
> ---
> libavcodec/h264_sei.c | 33 +++--
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/libavcodec/h264_sei.c b/l
From: Gautam Ramakrishnan
This patch adds functional changes to support the PPT marker. It
allows the PPT marker to be read in jpeg2000_read_main_headers().
---
libavcodec/jpeg2000dec.c | 270 ---
1 file changed, 82 insertions(+), 188 deletions(-)
diff --git
From: Gautam Ramakrishnan
This patch modifies the Jpeg2000Tile struct and breaks the
jpeg2000_decode_packet() function into two to decode packet
header and data separately.
---
libavcodec/jpeg2000dec.c | 250 ++-
1 file changed, 248 insertions(+), 2 deletions(
Am Fr., 27. März 2020 um 17:21 Uhr schrieb :
>
> From: Gautam Ramakrishnan
>
> This patch modifies the Jpeg2000Tile struct and breaks the
> jpeg2000_decode_packet() function into two to decode packet
> header and data separately.
The solution is also not to add functions that are unused at first.
On Fri, Mar 27, 2020 at 10:59 PM Carl Eugen Hoyos wrote:
>
> Am Fr., 27. März 2020 um 17:21 Uhr schrieb :
> >
> > From: Gautam Ramakrishnan
> >
> > This patch modifies the Jpeg2000Tile struct and breaks the
> > jpeg2000_decode_packet() function into two to decode packet
> > header and data separa
On Thu, Mar 26, 2020 at 10:28:32AM +, Tom Needham wrote:
> Thanks for your feedback. Please see the attached patch with all the style
> changes addressed which also applies properly.
> Changelog|1
> doc/general.texi |1
> libavformat/Makefile |1
>
Am Fr., 27. März 2020 um 18:48 Uhr schrieb Gautam Ramakrishnan
:
>
> On Fri, Mar 27, 2020 at 10:59 PM Carl Eugen Hoyos wrote:
> >
> > Am Fr., 27. März 2020 um 17:21 Uhr schrieb :
> > >
> > > From: Gautam Ramakrishnan
> > >
> > > This patch modifies the Jpeg2000Tile struct and breaks the
> > > jpe
---
libavformat/rtsp.c | 46 ++
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index cd6fc32a29..1aec070382 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2447,8 +2447,8 @@ static int
Hi!
Attached patch reduces warnings when decoding a file with 7.1(wide)
aac encoding.
Please comment, Carl Eugen
From fbbfb50842a5e47ac8aab34308c278d17df6ba12 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 27 Mar 2020 18:52:16 +0100
Subject: [PATCH] lavc/aacdec_template: Only warn on
On Fri, Mar 27, 2020 at 11:27 PM Carl Eugen Hoyos wrote:
>
> Am Fr., 27. März 2020 um 18:48 Uhr schrieb Gautam Ramakrishnan
> :
> >
> > On Fri, Mar 27, 2020 at 10:59 PM Carl Eugen Hoyos
> > wrote:
> > >
> > > Am Fr., 27. März 2020 um 17:21 Uhr schrieb :
> > > >
> > > > From: Gautam Ramakrishnan
Am Fr., 27. März 2020 um 19:24 Uhr schrieb Gautam Ramakrishnan
:
> > > > Did you already look at the sample file I pointed out?
> > > Yep, am going through the sample file. I shall try to see what
> > > is causing those errors. However I am assuming that the errors
> > > could be due to other bugs
On Thu, Mar 26, 2020 at 01:41:44AM +0100, Andreas Rheinhardt wrote:
> Matroska is built around the principle that a reader does not need to
> understand everything in a file in order to be able to make use of it;
> it just needs to ignore the data it doesn't know about.
>
> Our demuxer typically f
On Thu, Mar 26, 2020 at 07:04:24AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/af_adelay.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_adelay.c b/libavfilter/af_adelay.c
> index c9647771
On Wed, Mar 25, 2020 at 02:39:19PM -0700, John Rummell wrote:
> >
> > These would cause mov_read_adrm() to fail but not neccessarily return an
> > error code if any of these reads less.
> > Is that intended ?
>
>
> Not at all. Updated to always return AVERROR_INVALIDDATA.
[...]
> mov.c| 3
On Sat, Mar 28, 2020 at 12:45 AM Carl Eugen Hoyos wrote:
>
> Am Fr., 27. März 2020 um 19:24 Uhr schrieb Gautam Ramakrishnan
> :
>
> > > > > Did you already look at the sample file I pointed out?
> > > > Yep, am going through the sample file. I shall try to see what
> > > > is causing those errors.
Am Fr., 27. März 2020 um 20:57 Uhr schrieb Gautam Ramakrishnan
:
>
> On Sat, Mar 28, 2020 at 12:45 AM Carl Eugen Hoyos wrote:
> >
> > Am Fr., 27. März 2020 um 19:24 Uhr schrieb Gautam Ramakrishnan
> > :
> >
> > > > > > Did you already look at the sample file I pointed out?
> > > > > Yep, am going
On Sat, Mar 28, 2020 at 1:52 AM Carl Eugen Hoyos wrote:
>
> Am Fr., 27. März 2020 um 20:57 Uhr schrieb Gautam Ramakrishnan
> :
> >
> > On Sat, Mar 28, 2020 at 12:45 AM Carl Eugen Hoyos
> > wrote:
> > >
> > > Am Fr., 27. März 2020 um 19:24 Uhr schrieb Gautam Ramakrishnan
> > > :
> > >
> > > > > >
On Thu, Mar 26, 2020 at 10:24:36AM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> Validate the value of ST field in the TLM marker of JPEG2000.
> Throw an error when ST takes value of 0b11.
> ---
> libavcodec/jpeg2000dec.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 de
---
libavutil/frame.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index e4038096c2..0c64f4a422 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -25,6 +25,7 @@
#include "imgutils.h"
#include "mem.h"
#
---
libavcodec/nvdec.c | 92 +-
1 file changed, 75 insertions(+), 17 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index b60da24301..6168a7e3f1 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -44,6 +44,7 @@ typedef struct
---
libavutil/hwcontext.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index d09a15a249..b01612de05 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -557,6 +557,8 @@ int av_hwframe_get_buffer(AVBufferRef *hwframe_ref, AVFrame
On 3/27/2020 5:43 PM, Timo Rothenpieler wrote:
> ---
> libavutil/frame.c | 23 ---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index e4038096c2..0c64f4a422 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.
On 27.03.2020 21:53, James Almer wrote:
On 3/27/2020 5:43 PM, Timo Rothenpieler wrote:
---
libavutil/frame.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index e4038096c2..0c64f4a422 100644
--- a/libavutil/f
I came across something in libavformat/rawdec.h that looks like a typo to me.
The macro FF_DEF_RAWSUB_DEMUXER uses FF_RAWVIDEO_DEMUXER_CLASS in its
definition. Shouldn't it use FF_RAWSUB_DEMUXER_CLASS instead?
FF_RAWSUB_DEMUXER_CLASS is not referenced by anything else, so the
typo above is the mo
Am Fr., 27. März 2020 um 19:00 Uhr schrieb Carl Eugen Hoyos
:
> Attached patch reduces warnings when decoding a file with 7.1(wide)
> aac encoding.
New patch attached that does not lead to new crashes.
Please comment, Carl Eugen
From 93b3bbe35ea802a0a42c56d627606f2a634dd154 Mon Sep 17 00:00:00 2
phunkyfish:
> ---
> libavformat/rtsp.c | 46 ++
> 1 file changed, 38 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index cd6fc32a29..1aec070382 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@
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 private data is copied into private data for all the
> other threads
> - a "fixup" function is called for all the other threads to e.g.
> allocate d
The write_colr flag has been marked as "experimental, may be renamed or
changed, do not use from scripts" for over 5(!) years. I think it's time we
decide how to handle the colr atom.
I propose that we write the colr atom by default if the stream either has
an ICC color profile or has specified va
Updated patch attached. I forgot to remove the FF_MOV_FLAG_WRITE_COLR macro
in the original patch. My apologies.
>
0001-avformat-movenc-remove-write_colr-flag-and-write-col.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
phunkyfish:
> ---
> libavformat/rtsp.c | 49 ++
> 1 file changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index cd6fc32a29..d23ec5723e 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@
On Fri, Mar 27, 2020 at 08:34:02PM +0100, Michael Niedermayer wrote:
> On Thu, Mar 26, 2020 at 07:04:24AM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/af_adelay.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
>
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/af_adelay.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_adelay.c b/libavfilter/af_adelay.c
index c964777..2bb05e7 100644
--- a/libavfilter/af_adelay.c
+++ b/libavfilter/af_adelay.c
@@ -155,7 +1
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/af_acrossover.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_acrossover.c b/libavfilter/af_acrossover.c
index f70c50b..91f77cc 100644
--- a/libavfilter/af_acrossover.c
+++ b/libavfilter/af_acros
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_mix.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_mix.c b/libavfilter/vf_mix.c
index 9e1ae79..e47f7e2 100644
--- a/libavfilter/vf_mix.c
+++ b/libavfilter/vf_mix.c
@@ -108,7 +108,8 @@ static av
On Fri, Mar 27, 2020 at 01:42:02AM +0100, Michael Niedermayer wrote:
> On Wed, Mar 25, 2020 at 06:45:47PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_showinfo.c | 4
> > 1 file changed, 4 insertions(+)
>
> will app
Steven Liu:
> These member will be used for get more correct information of the MPD
>
> Suggested-by: Andreas Rheinhardt
> Suggested-by: Nicolas George
> Signed-off-by: Steven Liu
> ---
> libavformat/dashdec.c | 244 --
> 1 file changed, 214 insertions(+
> 2020年3月28日 上午9:37，Andreas Rheinhardt 写道：
>
> Steven Liu:
>> These member will be used for get more correct information of the MPD
>>
>> Suggested-by: Andreas Rheinhardt
>> Suggested-by: Nicolas George
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/dashdec.c | 244 +
Steven Liu:
>
>
>> 2020年3月28日 上午9:37，Andreas Rheinhardt 写道：
>>
>> Steven Liu:
>>> These member will be used for get more correct information of the MPD
>>>
>>> Suggested-by: Andreas Rheinhardt
>>> Suggested-by: Nicolas George
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavformat/dashdec.c | 2
On Sat, Mar 28, 2020 at 1:59 AM Gautam Ramakrishnan
wrote:
>
> On Sat, Mar 28, 2020 at 1:52 AM Carl Eugen Hoyos wrote:
> >
> > Am Fr., 27. März 2020 um 20:57 Uhr schrieb Gautam Ramakrishnan
> > :
> > >
> > > On Sat, Mar 28, 2020 at 12:45 AM Carl Eugen Hoyos
> > > wrote:
> > > >
> > > > Am Fr.,
From: toseven
---
libavcodec/tests/target_avpacket_fuzzer.c | 114 ++
1 file changed, 114 insertions(+)
create mode 100644 libavcodec/tests/target_avpacket_fuzzer.c
diff --git a/libavcodec/tests/target_avpacket_fuzzer.c
b/libavcodec/tests/target_avpacket_fuzzer.c
new file
> 2020年3月28日 上午10:15，Andreas Rheinhardt 写道：
>
> Steven Liu:
>>
>>
>>> 2020年3月28日 上午9:37，Andreas Rheinhardt 写道：
>>>
>>> Steven Liu:
These member will be used for get more correct information of the MPD
Suggested-by: Andreas Rheinhardt
Suggested-by: Nicolas George
Looking at this further, Apple's HDR requirements[1] say for Dolby Vision:
The color (‘colr’) atom with these values shall be present.
- Color Primaries shall be set to 2 (Unspecified).
- Color Transfer Function Index shall be set to 2 (Unspecified).
- Color Matrix Index shall be se
a397341...@163.com:
> From: toseven
>
> ---
> libavcodec/tests/target_avpacket_fuzzer.c | 114 ++
> 1 file changed, 114 insertions(+)
> create mode 100644 libavcodec/tests/target_avpacket_fuzzer.c
>
> diff --git a/libavcodec/tests/target_avpacket_fuzzer.c
> b/libavcodec/te
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-27 03:25:13)
>> av_packet_ref() mostly treated the destination packet dst as uninitialized,
>> i.e. the destination fields were simply overwritten. But if the source
>> packet was not reference-counted, dst->buf was treated as if it pointed
>> to
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-27 03:25:14)
>> Up until now, it was completely unspecified what the content of the
>> destination packet dst was on error. Depending upon where the error
>> happened calling av_packet_unref() on dst might be dangerous.
>>
>> This commit changes
Anton Khirnov:
> Quoting Andreas Rheinhardt (2020-03-13 14:28:33)
>> It already initializes the packet.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> Resending because of 3117f47f19d051d47ba29c9b78c2ca525f0fdb45.
>>
>> fftools/ffplay.c | 2 +-
>> libavcodec/qsvdec_h2645.c | 2 +-
>>
From: Gautam Ramakrishnan
This patch allows decoding of j2k streams which do
not have an EOC marker. OpenJPEG implements a similar
check.
---
libavcodec/jpeg2000dec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
inde
On Sat, Mar 28, 2020 at 9:49 AM wrote:
>
> From: Gautam Ramakrishnan
>
> This patch allows decoding of j2k streams which do
> not have an EOC marker. OpenJPEG implements a similar
> check.
> ---
> libavcodec/jpeg2000dec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --gi
From: Gautam Ramakrishnan
This patch modifies the Jpeg2000Tile struct and breaks the
jpeg2000_decode_packet() function into two to decode packet
header and data separately.
---
libavcodec/jpeg2000dec.c | 250 ++-
1 file changed, 248 insertions(+), 2 deletions(
> 2020年3月28日 下午12:24，Gautam Ramakrishnan 写道：
>
> On Sat, Mar 28, 2020 at 9:49 AM wrote:
should the title be jpeg2000dec?, it maybe is a typo if I don’t misunderstand.
>>
>> From: Gautam Ramakrishnan
>>
>> This patch allows decoding of j2k streams which do
>> not have an EOC marker. OpenJPEG
From: Gautam Ramakrishnan
This patch adds functional changes to support the PPT marker. It
allows the PPT marker to be read in jpeg2000_read_main_headers().
---
libavcodec/jpeg2000dec.c | 270 ---
1 file changed, 82 insertions(+), 188 deletions(-)
diff --git
On Sat, Mar 28, 2020 at 9:59 AM Steven Liu wrote:
>
>
>
> > 2020年3月28日 下午12:24，Gautam Ramakrishnan 写道：
> >
> > On Sat, Mar 28, 2020 at 9:49 AM wrote:
> should the title be jpeg2000dec?, it maybe is a typo if I don’t misunderstand.
You are right, it is a typo. It must be jpeg2000dec.
> >>
> >> Fr
87 matches
Mail list logo
