Am So., 5. Apr. 2020 um 03:30 Uhr schrieb Andriy Gelman
:
>
> On Sun, 05. Apr 02:05, Carl Eugen Hoyos wrote:
> > Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Carl Eugen Hoyos
> > > :
> > > > New patch attached, it should n
Am Di., 13. Aug. 2019 um 12:45 Uhr schrieb Carl Eugen Hoyos
:
> Attached patch fixes several compilation warnings when building with
> chromapring.
I will push this patch if there are no objections.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel
Am Mo., 30. März 2020 um 15:38 Uhr schrieb Carl Eugen Hoyos
:
>
> Am Fr., 27. März 2020 um 19:00 Uhr schrieb phunkyfish :
> >
> > ffmpeg | branch: master | phunkyfish | Mon Mar 2
> > 19:21:09 2020 +| [b71685865fe761925feedda3cd0b288224d9a509] |
> > committer: Aman Gupta
> >
> > avformat/rtp
Am Sa., 4. Apr. 2020 um 18:46 Uhr schrieb Ryo Hirafuji
:
>
> > In an ideal world, crf 0 would force all other settings for a lossless
> > encoding.
>
> I forgot to say that if "-lossless 1" is set, "crf" will also be 0 (in
> libaom, internally).
>
> All those conditions will be forced (ot at least
Carl Eugen Hoyos:
> Am Mo., 30. März 2020 um 15:38 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am Fr., 27. März 2020 um 19:00 Uhr schrieb phunkyfish :
>>>
>>> ffmpeg | branch: master | phunkyfish | Mon Mar 2
>>> 19:21:09 2020 +| [b71685865fe761925feedda3cd0b288224d9a509] |
>>> committer: Aman Gu
On Sun, 5 Apr 2020, Andreas Rheinhardt wrote:
Carl Eugen Hoyos:
Am Mo., 30. März 2020 um 15:38 Uhr schrieb Carl Eugen Hoyos
:
Am Fr., 27. März 2020 um 19:00 Uhr schrieb phunkyfish :
ffmpeg | branch: master | phunkyfish | Mon Mar 2
19:21:09 2020 +| [b71685865fe761925feedda3cd0b28822
On Sun, Apr 05, 2020 at 10:28:17 +0530, gautamr...@gmail.com wrote:
> +tile->has_ppt = 1; // this tile has a ppt marker
> +/*Zppt = */ bytestream2_get_byte(&s->g); // Zppt is skipped and not used
I don't know what others think, but, as mentioned in my first review, I
really dislike this s
Am So., 5. Apr. 2020 um 11:06 Uhr schrieb Andreas Rheinhardt
:
>
> Carl Eugen Hoyos:
> > Am Mo., 30. März 2020 um 15:38 Uhr schrieb Carl Eugen Hoyos
> > :
> >>
> >> Am Fr., 27. März 2020 um 19:00 Uhr schrieb phunkyfish :
> >>>
> >>> ffmpeg | branch: master | phunkyfish | Mon Mar 2
> >>> 19:21:09
On Sat, Apr 04, 2020 at 18:53:41 +0900, Ryo Hirafuji wrote:
> AV1 support lossless encoding.
> In this patch, I added a command line flag to enable it.
> @@ -154,7 +158,7 @@ static av_cold void dump_enc_cfg(AVCodecContext *avctx,
> av_log(avctx, level, "aom_codec_enc_cfg\n");
> av_log(av
On Sun, Apr 5, 2020 at 3:13 PM Moritz Barsnick wrote:
>
> On Sun, Apr 05, 2020 at 10:28:17 +0530, gautamr...@gmail.com wrote:
> > +tile->has_ppt = 1; // this tile has a ppt marker
> > +/*Zppt = */ bytestream2_get_byte(&s->g); // Zppt is skipped and not
> > used
>
> I don't know what othe
> I would prefer this but I am not the maintainer.
Oh, I see.
Hi, Rostislav Pehlivanov, please tell me your idea.
(How can I address him/her in ML...?)
I think it is more useful to execute this line when "-crf 0" is set:
> codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
It could let use
Hi, Moritz.
Yeah, you are right! And sorry.
After the discussion, I will move this change from "lossless patch" to
"gray patch".
Thanks.
2020年4月5日(日) 19:28 Moritz Barsnick :
> On Sat, Apr 04, 2020 at 18:53:41 +0900, Ryo Hirafuji wrote:
> > AV1 support lossless encoding.
> > In this patch, I ad
From: Gautam Ramakrishnan
This patch adds functional changes to support the
PPT marker. This patch fixes bug ticket #4610.
---
libavcodec/jpeg2000dec.c | 88 +++-
1 file changed, 77 insertions(+), 11 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavc
Am So., 5. Apr. 2020 um 12:42 Uhr schrieb Ryo Hirafuji
:
>
> Hi, Moritz.
>
> Yeah, you are right! And sorry.
>
> After the discussion, I will move this change from "lossless patch" to
> "gray patch".
And please mention "Fixes ticket #7599" for the gray patch,
"Fixes ticket #7600" for the lossless
OK, I will.
Thanks!
2020年4月5日(日) 19:45 Carl Eugen Hoyos :
> Am So., 5. Apr. 2020 um 12:42 Uhr schrieb Ryo Hirafuji
> :
> >
> > Hi, Moritz.
> >
> > Yeah, you are right! And sorry.
> >
> > After the discussion, I will move this change from "lossless patch" to
> > "gray patch".
>
> And please mentio
> From: "Linjie Fu"
> Sent Time: 2020-04-03 23:12:20 (Friday)
> To: ffmpeg-devel@ffmpeg.org
> Cc: "Linjie Fu"
> Subject: [FFmpeg-devel] [PATCH 00/10] Patch set for the enhancement of
> libopenh264 encoder
>
> Docs will be provided later.
>
> Linjie Fu (10):
> lavc/libopenh264enc: Add default
Lynne, could you tell me your idea?
2020年4月5日(日) 19:39 Ryo Hirafuji :
> > I would prefer this but I am not the maintainer.
>
> Oh, I see.
>
> Hi, Rostislav Pehlivanov, please tell me your idea.
> (How can I address him/her in ML...?)
>
> I think it is more useful to execute this line when "-crf 0
On Sun, 5 Apr 2020, Carl Eugen Hoyos wrote:
Am So., 5. Apr. 2020 um 11:06 Uhr schrieb Andreas Rheinhardt
:
Carl Eugen Hoyos:
> Am Mo., 30. März 2020 um 15:38 Uhr schrieb Carl Eugen Hoyos
> :
>>
>> Am Fr., 27. März 2020 um 19:00 Uhr schrieb phunkyfish :
>>>
>>> ffmpeg | branch: master | phunk
Am So., 5. Apr. 2020 um 13:32 Uhr schrieb Marton Balint :
>
>
>
> On Sun, 5 Apr 2020, Carl Eugen Hoyos wrote:
>
> > Am So., 5. Apr. 2020 um 11:06 Uhr schrieb Andreas Rheinhardt
> > :
> >>
> >> Carl Eugen Hoyos:
> >> > Am Mo., 30. März 2020 um 15:38 Uhr schrieb Carl Eugen Hoyos
> >> > :
> >> >>
> >>
Am Fr., 19. Apr. 2019 um 01:04 Uhr schrieb Carl Eugen Hoyos
:
>
> Hi!
>
> I needed attached patch to use libmfx.
I will push this as I can reproduce the same issue on Linux.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg
On Sat, Apr 04, 2020 at 12:46:36AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch makes the alloc array functions more similar to
> av_malloc, depending on max_alloc_size instead of INT_MAX.
>
> Allows a work-around for ticket #7140
>
> Please comment, Carl Eugen
> mem.c |8 --
On Sun, 05. Apr 10:34, Carl Eugen Hoyos wrote:
> Am So., 5. Apr. 2020 um 03:30 Uhr schrieb Andriy Gelman
> :
> >
> > On Sun, 05. Apr 02:05, Carl Eugen Hoyos wrote:
> > > Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
> > > :
> > > >
> > > > Am Sa., 4. Apr. 2020 um 00:44 Uhr schrieb Car
Andriy Gelman:
> On Sun, 05. Apr 10:34, Carl Eugen Hoyos wrote:
>> Am So., 5. Apr. 2020 um 03:30 Uhr schrieb Andriy Gelman
>> :
>>>
>>> On Sun, 05. Apr 02:05, Carl Eugen Hoyos wrote:
Am So., 5. Apr. 2020 um 01:02 Uhr schrieb Carl Eugen Hoyos
:
>
> Am Sa., 4. Apr. 2020 um 00:44 Uh
On 4/5/2020 3:31 AM, Peter Ross wrote:
> ---
> libavcodec/vp9.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 7ee375d4d0..c125e22975 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -1216,18 +1216,24 @@ static av_cold int v
On 1/30/2019 10:47 AM, Carl Eugen Hoyos wrote:
> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
>> Hi!
>>
>> Attached patch fixes decoding NO_DATA amr-wb frames.
>
> Now with patch.
>
> Carl Eugen
> From 0a8c318c49ec358ad646ed601588154cf7d7da37 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
Am So., 5. Apr. 2020 um 16:45 Uhr schrieb James Almer :
>
> On 1/30/2019 10:47 AM, Carl Eugen Hoyos wrote:
> > 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
> >> Hi!
> >>
> >> Attached patch fixes decoding NO_DATA amr-wb frames.
> >
> > Now with patch.
> >
> > Carl Eugen
>
> > From 0a8c318c49ec358
Hi!
Attached patch simplifies a funtion in the amrwb decoder, as suggested by James.
Please comment, Carl Eugen
From 91d50f466728d7d0680882f6f63217f39808c2af Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 5 Apr 2020 17:04:44 +0200
Subject: [PATCH] lavc/amrwbdec: Use av_samples_set_si
On 4/5/2020 12:07 PM, Carl Eugen Hoyos wrote:
> Am So., 5. Apr. 2020 um 16:45 Uhr schrieb James Almer :
>>
>> On 1/30/2019 10:47 AM, Carl Eugen Hoyos wrote:
>>> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
Hi!
Attached patch fixes decoding NO_DATA amr-wb frames.
>>>
>>> Now with pa
Am So., 5. Apr. 2020 um 17:10 Uhr schrieb James Almer :
>
> On 4/5/2020 12:07 PM, Carl Eugen Hoyos wrote:
> > Am So., 5. Apr. 2020 um 16:45 Uhr schrieb James Almer :
> >>
> >> On 1/30/2019 10:47 AM, Carl Eugen Hoyos wrote:
> >>> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> >>>
On 4/5/2020 12:06 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch simplifies a funtion in the amrwb decoder, as suggested by
> James.
>
> Please comment, Carl Eugen
> From 91d50f466728d7d0680882f6f63217f39808c2af Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Sun, 5 Apr 2020 17
Am So., 5. Apr. 2020 um 17:14 Uhr schrieb James Almer :
>
> On 4/5/2020 12:06 PM, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch simplifies a funtion in the amrwb decoder, as suggested by
> > James.
> >
> > Please comment, Carl Eugen
>
> > From 91d50f466728d7d0680882f6f63217f39808c2af Mon
Am So., 5. Apr. 2020 um 02:01 Uhr schrieb Carl Eugen Hoyos :
> Attached patch makes the output of the file in ticket #7113 very
> similar to the reference decoder.
New patch attached.
Carl Eugen
From c5c63dd531aac11f0c927c09a66d2bcff6ea5356 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date:
This patchset is sort-of a revival of the part of a patchset I sent
earlier [1], but which couldn't be applied fully because the way the
webm_chunk muxer bypassed the API [2]. Now that this has been fixed [3],
I have taken the opportunity to resend this patchset in an updated form.
It does not yet
Tags in the Matroska file format can be summarized as follows: There is
a level 1-element called Tags containing one or many Tag elements each
of which in turn contain a Targets element and one or many SimpleTags.
Each SimpleTag roughly corresponds to a single key-value pair similar to
an AVDiction
AVChapters have an int as id field and therefore this value can appear
<= 0. When remuxing from Matroska, this value actually contains
the lower 32 bits of the original ChapterUID (which can be 64 bits).
In order to ensure that the ChapterUID is always > 0, they were offset
as follows (since 07704
Our code can actually write tracks with a TrackNumber in the range of
1..127 without problems. Variable length integers that only have '1'
bits after the marker bit are not reserved when being used to encode
the TrackNumber in a Block (there is no equivalent of unknown length
elements here).
Signe
When creating DASH streams, the TrackNumber is externally prescribed
and not derived from the number of streams in the AVFormatContext. Up
until now, a TrackNumber of zero was allowed, although this is invalid.
Furthermore, it was not checked whether the number of tracks for a file
using an explic
Up until now, the TrackUID of a Matroska track which is supposed to be
random was not random at all: It always coincided with the TrackNumber
which is usually the 1-based index of the corresponding stream in the
array of AVStreams. This has been changed: It is now set via an AVLFG
if AVFMT_FLAG_BIT
This commit reuses the random seed generated in mkv_init() (to determine
the TrackUIDs) for the SegmentUID in order to avoid a potentially
expensive call to av_get_random_seed().
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 19 +--
1 file changed, 9 insertion
Up until now, mkv_write_track() received the index of the stream whose
header data it is about to write as parameter; this index has until
recently been explicitly used to generate both TrackNumber and TrackUID.
But this is no longer so and as there is no reason why the function
for writing a singl
If there are Attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
AttachedFile containing just the stream index of the corresponding
stream and the FileUID used for this AttachedFile; and a structure with
a pointer to said array and a co
In order to determine whether the current Cluster needs to be closed
because of the limits on clustersize and clustertime,
mkv_write_packet() would first get the size of the current Cluster by
applying avio_tell() on the dynamic buffer holding the current Cluster.
It did this without checking wheth
Attachments are streams in FFmpeg, but they are not tracks in Matroska.
Yet they were counted when checking a limit for the number of tracks that
the Matroska muxer imposes. This is unnecessary and has been changed.
Also use unsigned variables for the variables denoting TrackNumbers as
negative Tr
mkv_cuepoint (the structure used to store the index entries in the
Matroska muxer) currently contains fields for both the index of the
packet's stream in the AVFormatContext.streams array and for the
Matroska TrackNumber; correspondingly, mkv_add_cuepoint() has arguments
for both. But these two num
Using random values for TrackUID and FileUID (as happens when the
AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
the output indeterministic. This commit mitigates this by writing the
potentially random values with a fixed size of eight byte, even if their
actual values woul
As WebM doesn't support Attachments, the Matroska muxer drops them when
in WebM mode. This happened silently until this commit which adds a
warning for this.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
The Matroska muxer currently only adds CuePoints in three cases:
a) For video keyframes. b) For the first audio frame in a new Cluster if
in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
files won't have any Cues which impedes seeking.
This commit changes this. For every tra
Several EBML Master elements for which a good upper bound of the final
length was available were nevertheless written without giving an
upper bound of the final length to start_ebml_master(), so that their
length fields were eight bytes long. This has been changed.
Signed-off-by: Andreas Rheinhard
Reindentation, removal of { } if they contain only one statement,
removal of other useless parentheses and moving the return statement
to a line of its own in situations like "if (ret < 0) return ret;".
Moreover, several overlong lines were made shorter and a camelCase
variable received a name in l
At the end of encoding, the FLAC encoder sends a packet whose side data
contains updated extradata (e.g. a correct md5 checksum). The Matroska
muxer uses this to update the CodecPrivate.
In doing so, the stream's codecpar was copied. But given that writing
a FLAC CodecPrivate does not modify the u
The Matroska muxer does not write every stream as a Matroska track;
some streams are written as AttachedFile. But should no stream be
written as a Matroska track, the Matroska muxer would nevertheless
write a Tracks element without a TrackEntry. This is against the spec.
This commit changes this an
Up until now, the Matroska muxer would mark a track as default if it had
the disposition AV_DISPOSITION_DEFAULT or if there was no track with
AV_DISPOSITION_DEFAULT set; in the latter case even more than one track
of a kind (audio, video, subtitles) was marked as default which is not
sensible.
Thi
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 68 +--
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 17e1f8dec9..3981986e86 100644
--- a/libavformat/matroskaenc.c
+
Andreas Rheinhardt:
> 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 red
Andreas Rheinhardt:
> The WebM DASH Manifest muxer only supports VP8, VP9, Vorbis and Opus,
> but there was no check for this. The codec type is used to get a pointer
> to a string containing the codec name or NULL if it is not one of those
> four codecs. Said pointer has then been used without fur
lgtm with a couple of minor comments
On Sun, 05. Apr 10:49, Carl Eugen Hoyos wrote:
> Am Di., 13. Aug. 2019 um 12:45 Uhr schrieb Carl Eugen Hoyos
> :
>
> > Attached patch fixes several compilation warnings when building with
> > chromapring.
>
> I will push this patch if there are no objections.
Am Mo., 30. März 2020 um 09:30 Uhr schrieb Andreas Rheinhardt
:
>
> The WebM DASH Manifest muxer only supports VP8, VP9, Vorbis and Opus,
> but there was no check for this. The codec type is used to get a pointer
> to a string containing the codec name or NULL if it is not one of those
> four codec
Carl Eugen Hoyos:
> Am Mo., 30. März 2020 um 09:30 Uhr schrieb Andreas Rheinhardt
> :
>>
>> The WebM DASH Manifest muxer only supports VP8, VP9, Vorbis and Opus,
>> but there was no check for this. The codec type is used to get a pointer
>> to a string containing the codec name or NULL if it is not
On Sun, Apr 05, 2020 at 04:13:28PM +0530, gautamr...@gmail.com wrote:
> From: Gautam Ramakrishnan
>
> This patch adds functional changes to support the
> PPT marker. This patch fixes bug ticket #4610.
> ---
> libavcodec/jpeg2000dec.c | 88 +++-
> 1 file change
---
libavcodec/pthread_frame.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 172731a98e..0e51e89653 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -982,10 +982
They are not forbidden by the specification.
---
libavformat/wvdec.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/libavformat/wvdec.c b/libavformat/wvdec.c
index b9fc6a59f9..4159bf1253 100644
--- a/libavformat/wvdec.c
+++ b/libavformat/wvdec.c
@@ -208,24 +208,6 @@ static
Fix invalid memory access on DSD streams with changing channel count.
---
libavcodec/wavpack.c | 122 +++
1 file changed, 90 insertions(+), 32 deletions(-)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index b27262b94e..9cc4104dd0 100644
--- a/li
Merge ff_get_buffer() and get_buffer_internal() to simplify the code.
---
libavcodec/decode.c | 37 +++--
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index af6bb3f952..de1e9fa4a4 100644
--- a/libavcodec/d
Am So., 5. Apr. 2020 um 19:51 Uhr schrieb Andriy Gelman
:
>
> lgtm with a couple of minor comments
>
> On Sun, 05. Apr 10:49, Carl Eugen Hoyos wrote:
> > Am Di., 13. Aug. 2019 um 12:45 Uhr schrieb Carl Eugen Hoyos
> > :
> >
> > > Attached patch fixes several compilation warnings when building with
Fixes: OOM
Fixes:
20774/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5678608951803904
Fixes:
20956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5713643025203200
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Si
Fixes: out of array access
Fixes:
21469/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5199357982015488
Alternatively the arrays can be made bigger or the index can be clipped.
In case a real file with such huge tiles exist we ask the user to upload it.
Signed-off-by: Michael Niede
On Mon, Mar 23, 2020 at 05:18:36PM +0100, Michael Niedermayer wrote:
> Fixes: assertion failure
> Fixes:
> 20390/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5683400772157440
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
ffmpeg now throws an error during configure:
ERROR: avisynth/avisynth_c.h not found
I'm pretty sure it has something to do with removing the headers in commit
0c75acb4ce.
Cheers,
K. C.
- --
regards Helmut K. C. Tessarek KeyID 0x17
On Sun, 5 Apr 2020, Helmut K. C. Tessarek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
ffmpeg now throws an error during configure:
ERROR: avisynth/avisynth_c.h not found
I'm pretty sure it has something to do with removing the headers in commit
0c75acb4ce.
Well, do you have the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2020-04-05 18:57, Marton Balint wrote:
> Well, do you have the headers installed?
No, because they were always part of ffmpeg. You can't just remove stuff
without proper documentation.
I have been compiing the macOS binaries for 8 years now and t
Signed-off-by: Marton Balint
---
libavdevice/xv.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index c3ed2e48bd..2c5f1a4432 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -113,8 +113,8 @@ static int xv_write_head
The same goal can be achieved using the WRAPPED_AVFRAME codec with the existing
API.
Signed-off-by: Marton Balint
---
doc/APIchanges | 4
libavdevice/alsa_enc.c | 4
libavdevice/opengl_enc.c | 4
libavdevice/pulse_audio_enc.c| 4
li
Signed-off-by: Marton Balint
---
libavdevice/opengl_enc.c | 54 +---
1 file changed, 10 insertions(+), 44 deletions(-)
diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index ae03caa8c5..b8bc46ebb5 100644
--- a/libavdevice/opengl_enc.c
+
On Sun, 5 Apr 2020, Helmut K. C. Tessarek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2020-04-05 18:57, Marton Balint wrote:
Well, do you have the headers installed?
No, because they were always part of ffmpeg.
The headers got removed because the ffmpeg source tree is no pl
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Guo, Yejun
> Sent: Monday, March 30, 2020 10:01 AM
> To: Steven Liu ; FFmpeg development discussions and
> patches
> Subject: Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_derain.c: put all the
On 4/5/20 1:32 PM, Anton Khirnov wrote:
> Fix invalid memory access on DSD streams with changing channel count.
> ---
> libavcodec/wavpack.c | 122 +++
> 1 file changed, 90 insertions(+), 32 deletions(-)
>
> diff --git a/libavcodec/wavpack.c b/libavcodec/wav
On Sun, 5 Apr 2020 at 16:01, Andreas Rheinhardt
wrote:
>
> The Matroska muxer currently only adds CuePoints in three cases:
> a) For video keyframes. b) For the first audio frame in a new Cluster if
> in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
> files won't have any Cu
On Mon, Apr 6, 2020 at 1:16 AM Michael Niedermayer
wrote:
>
> On Sun, Apr 05, 2020 at 04:13:28PM +0530, gautamr...@gmail.com wrote:
> > From: Gautam Ramakrishnan
> >
> > This patch adds functional changes to support the
> > PPT marker. This patch fixes bug ticket #4610.
> > ---
> > libavcodec/jp
On 4/2/20 11:32 PM, Anton Khirnov wrote:
> Quoting David Bryant (2020-04-03 07:14:21)
>> On 4/2/20 2:13 AM, Anton Khirnov wrote:
>>> Quoting David Bryant (2020-04-01 23:35:13)
On 3/31/20 2:47 AM, Anton Khirnov wrote:
>>> Looking at wavpack, the code looks suspicious to me. You allocate one
From: Andriy Gelman
v4l2_m2m uses device memory mapped buffers to store dequeued
frames/packets (reference counted by AVBufferRef). When the
reference count drops to zero, the buffer ownership is returned back to
the device, so that they can re-filled with frames/packets.
There are some cases wh
From: Andriy Gelman
Signed-off-by: Andriy Gelman
---
libavcodec/v4l2_context.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 8110bbb555..31af10d28e 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l
On 4/5/20 1:32 PM, Anton Khirnov wrote:
> They are not forbidden by the specification.
> ---
> libavformat/wvdec.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/libavformat/wvdec.c b/libavformat/wvdec.c
> index b9fc6a59f9..4159bf1253 100644
> --- a/libavformat/wvdec.c
Place HAVE_MIPSFPU further up so that functions that use floating point
ASM are defined away. Otherwise compilation failures result when soft
float in enabled on the toolchain.
Signed-off-by: Rosen Penev
---
libavcodec/mips/aacdec_mips.c | 4 ++--
libavcodec/mips/aacpsdsp_mips.c | 4 ++--
liba
83 matches
Mail list logo
