because the offset should use one byte
Reported-by: Zhao Jun >
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 5ba7feb245..04a1baea15 100644
--- a/libavformat/dashdec.c
+++
Allows specifying avctx->profile with string type profile for
h264 encoders.
Private field/option "profile" may be abled to be removed for basic
h264 profiles, directly for encoders like libopenh264/h264_vaapi,
or with an map to hardware profile like h264_qsv.
Signed-off-by: Linjie Fu
---
One co
> 2020年5月6日 下午12:17，Andreas Rheinhardt 写道：
>
> The mapping of streams to the various variant streams to be created by
> the HLS muxer is roughly as follows: Space and tab separate variant
> stream group maps while the entries in each variant stream group map are
> separated by ','.
>
> The par
Andreas Rheinhardt:
> avformat_alloc_output_context2() already sets the oformat member, so
> that there is no reason to overwrite it again with the value it already
> has.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
The mapping of streams to the various variant streams to be created by
the HLS muxer is roughly as follows: Space and tab separate variant
stream group maps while the entries in each variant stream group map are
separated by ','.
The parsing process of each variant stream group proceeded as follow
May 5, 2020, 11:29 by d...@lynne.ee:
> May 5, 2020, 09:59 by andreas.rheinha...@gmail.com:
>
>> Lynne:
>>
>>> The only adjustable field is the gain. Some ripping/transcoding programs
>>> have started to use it for replaygain adjustments.
>>>
>>> Patch attached.
>>>
>>> >
>>> +typedef struct OpusB
Hi Kartik,
On Mon, Mar 30, 2020, at 4:50 AM, Kartik K. Khullar wrote:
> This is my WIP patch for GSoC and I worked on transformations involved
> in encoding/decoding FLIF images. I have created a module under
> libavcodec and as guided by my mentors I have tried to use pixel data
> from AVFrame
On Tue, Apr 21, 2020 at 11:35:24PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> The patch will make audio and subtitle packets be marked as AV_PKT_FLAG_KEY.
>
> For audio, it'll caused the audio sample to be sync sample.
> To verify ref/fate/movenc results:
> 1. Get the movenc tes
On Sun, Apr 26, 2020 at 05:49:17PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> fftools/ffmpeg.c | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> ind
May 5, 2020, 23:15 by geo...@nsup.org:
> Lynne (12020-05-05):
>
>> Pushed.
>>
>
> I find rather rude that you did not even acknowledge the suggestion in
> this mail:
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262151.html
>
I did acknowledge it but I didn't comment on it because I disl
Lynne (12020-05-05):
> Pushed.
I find rather rude that you did not even acknowledge the suggestion in
this mail:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262151.html
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-d
On Thu, 30. Apr 01:39, Ming Qian wrote:
> > From: Andriy Gelman
> >
> > v4l2_m2m devices may send an empty packet/frame while draining to indicate
> > that all capture buffers have been flushed.
> >
> > Currently, the empty packet/frame is not handled correctly:
> > When encoding, the empty pack
On 5/5/2020 9:42 AM, Andreas Rheinhardt wrote:
> As time passed, the API-violating behaviour of aac_adtstoasc was fixed
> and d6d605eb05c3ca32f591016c345eb2ad9e81c554 stopped delaying writing
> the header. The very same patchset containing said commit also contained
> a patch to deprecate AVFMT_FLA
> > From: ffmpeg-devel ffmpeg-devel-boun...@ffmpeg.org On Behalf Of
> > Josh de Kock
> > Sent: Tuesday, April 28, 2020 23:47
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
> > frame computation based on level
> > On 26/04/2020 12:46, Jos
Jim DeLaHunt (12020-05-02):
> Nicolas, I strongly disagree with the term "lazy beginners". This points to
> a much larger question: who is the FFmpeg documentation for?
Subscribe to ffmpeg-user, do support there, and then tell me if there
are no lazy users.
> This does not make them "lazy". What
On Tue, 5 May 2020, Andreas Rheinhardt wrote:
Marton Balint:
On Tue, 5 May 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.
This chang
On Sun, May 03, 2020 at 04:10:02PM -0700, mindm...@gmail.com wrote:
> From: Mark Reid
>
> changes since v1
> - added missing fillPlane32 function
> - tests should pass now for qemu-mips
> - removed exr patch for now
>
> Mark Reid (2):
> libswscale: add input support AV_PIX_FMT_GBRAPF32
> lib
On Mon, May 04, 2020 at 02:25:56PM +, Zane van Iperen wrote:
> Adds support for the soundbank files used by the Pro Pinball series of games.
>
> v13:
> - Increment current_track after reading a packet.
>
> v12: [9]
> - Read packets in a round-robin fashion to
> avoid "Too many packets
On Sun, May 3, 2020 at 10:17 AM Michael Niedermayer
wrote:
> On Sun, May 03, 2020 at 02:01:21AM -0700, Mark Reid wrote:
> > On Thu., Apr. 30, 2020, 11:46 a.m. Mark Reid,
> wrote:
> >
> > >
> > >
> > > On Thu, Apr 30, 2020 at 7:59 AM Michael Niedermayer
>
> > > wrote:
> > >
> > >> On Wed, Apr 29
On Sun, May 03, 2020 at 04:13:47PM -0700, David Bryant wrote:
> On 5/2/20 2:08 PM, Michael Niedermayer wrote:
> > Fixes: shift exponent 32 is too large for 32-bit type 'int'
> > Fixes:
> > 21647/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5686168323883008
> >
> > Found-by: con
Hi,
On Wed, Apr 29, 2020 at 8:08 AM Fu, Linjie wrote:
> > From: ffmpeg-devel On Behalf Of Fu,
> > Linjie
> > Sent: Friday, March 20, 2020 09:49
> > To: Ronald S. Bultje ; FFmpeg development
> > discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame
>
Am Di., 5. Mai 2020 um 14:07 Uhr schrieb Nico Coesel :
> I want to report a bug in the jpeg encoding but I can't
> seem to register to trac.
Alternatives are to report the issue on the user mailing
list or on irc.
Carl Eugen
___
ffmpeg-devel mailing li
> From: ffmpeg-devel On Behalf Of
> Josh Brewster
> Sent: Tuesday, May 5, 2020 23:52
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/libx264: fix reference
> frame computation based on level
>
> > > From: ffmpeg-devel ffmpeg-
Bump...
On Wed, Apr 29, 2020 at 11:23 PM Roger Pack wrote:
>
> > > c9153590e5f167e41910d867639eb887164e28d2
> > > 0001-closed-caption-decoder-accept-and-decode-a-new-codec.patch
> > > From bf29fe5330e83e37cf064b18918185c6b00d9b9f Mon Sep 17 00:00:00 2001
> > > From: rogerdpack
> > > Date: Tue,
Extend range of video_track_timescale flag value to -1 to indicate video stream
timescale should be used for track timebase. Add debug message if
video_track_timescale is not specified and the video stream timescale is
clamped to greater than 1.
Signed-off-by: vectronic
---
libavformat/mo
indent
Signed-off-by: vectronic
---
libavformat/movenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bcc0ab4377..989ba5b857 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6461,11 +6461,11 @@ st
Revised patch based on feedback. Instead of introducing a new flag, this extend
the range of video_track_timescale down to -1
which indicates to use the video stream timescale for video the track.
Still providing a debug message in default case if video timescale specified
has been clamped to ab
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/profiles.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index eaf0d68..e59a3a5 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -99,7 +99,6 @@ const AVProfile ff_mpeg2_
May 5, 2020, 09:59 by andreas.rheinha...@gmail.com:
> Lynne:
>
>> The only adjustable field is the gain. Some ripping/transcoding programs
>> have started to use it for replaygain adjustments.
>>
>> Patch attached.
>>
>> >
>> +typedef struct OpusBSFContext {
>> +const AVClass *class;
>> +
When writing the header, the NUT muxer allocates an array with as many
entries as there are chapters containing information about the used
timebase. This information is used when writing the headers and also
when resending the headers (as the NUT muxer does from time to time).
When the NUT muxer w
On Mon, May 04, 2020 at 08:22:41PM +0200, Andreas Rheinhardt wrote:
> calculate_checksum in put_packet() is always 1.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/nutenc.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
probably ok
thx
[...]
--
On Mon, May 04, 2020 at 08:22:42PM +0200, Andreas Rheinhardt wrote:
> NUT uses variable-length integers in order to for length fields.
> Therefore the NUT muxer often writes data into a dynamic buffer in order
> to get the length of it, then writes the length field using the fewest
> amount of byte
On Mon, May 04, 2020 at 08:22:43PM +0200, Andreas Rheinhardt wrote:
> It allows to combine several ffio_free_dyn_buf().
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and
On Mon, May 04, 2020 at 08:22:44PM +0200, Andreas Rheinhardt wrote:
> and make it static again.
>
> These functions have been moved from nutenc to aviobuf and internal.h
> in f8280ff4c00eeaa245085fa9691035203abd168c in order to use them in a
> forthcoming patch in utils.c. Said patch never happene
On Tue, May 05, 2020 at 03:31:27PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, May 04, 2020 at 08:22:49PM +0200, Andreas Rheinhardt wrote:
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/nutenc.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Mon, May 04, 2020 at 08:22:47PM +0200, Andreas Rheinhardt wrote:
> For nut_write_trailer() this includes actually returning such errors.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/nutenc.c | 33 -
> 1 file changed, 24 insertions(+), 9 deletions(-
Michael Niedermayer:
> On Mon, May 04, 2020 at 08:22:49PM +0200, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/nutenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
>> index 5735055d1
On Mon, May 04, 2020 at 08:22:49PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/nutenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index 5735055d19..6df7dfe210 100644
> --- a/
> From: Fu, Linjie
> Sent: Thursday, April 30, 2020 09:13
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [PATCH] MAINTAINERS: Add myself to libopenh264enc
>
> Reviewed-by: Martin Storsjö
> Signed-off-by: Linjie Fu
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> dif
May 3, 2020, 21:21 by d...@lynne.ee:
> The only adjustable field is the gain. Some ripping/transcoding programs
> have started to use it for replaygain adjustments.
>
> Patch attached.
>
Planning to push this tonight if there are no objections.
___
ffm
Marton Balint:
>
>
> On Tue, 5 May 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.
>>>
>>> This change also allows muxers
Hi,
I broke the threading with my last reply, i apologise. Here goes another
attempt:
On Tue, Apr 28, 2020 at 6:23 PM Neil Birkbeck
wrote:
> On Tue, Apr 28, 2020 at 3:18 AM Nicolas George wrote:
>
> > Andreas Rheinhardt (12020-04-28):
> > > That's expected. The patch provided only provides the
Hello all,
I want to report a bug in the jpeg encoding but I can't seem to register
to trac.
Is there a special trick to it?
Regards,
N. Coesel
--
o---o
| N C T Developments |
|Innovative em
Hi Neil,
I have to look deeper into the MKV side of things and most likely raise it
with the cellar mailing list so that better minds than mine can weigh in. I
do see that the rounding up to 704 could be an issue alright.
As for MOV, your patch appears to generate the same output clap values as
th
Andreas Rheinhardt (12020-05-05):
> > +static const AVOption opus_metadata_options[] = {
> > +{ "gain", "Gain, actual amplification is pow(10, gain/(20.0*256))",
> > OFFSET(gain),
> > + AV_OPT_TYPE_INT, { .i64 = 0 }, -(INT16_MAX + 1), INT16_MAX, .flags =
> > FLAGS },
> > +
> > +{ NUL
Lynne:
> The only adjustable field is the gain. Some ripping/transcoding programs
> have started to use it for replaygain adjustments.
>
> Patch attached.
>
> >
> +typedef struct OpusBSFContext {
> +const AVClass *class;
> +int64_t gain;
> +} OpusBSFContext;
[...]
>
> +static const AVOp
Marton Balint:
>
>
> On Tue, 5 May 2020, Tao Zhang wrote:
>
>> Marton Balint 于2020年5月5日周二 上午3:48写道：
>>>
>>>
>>>
>>> On Sat, 2 May 2020, Tao Zhang wrote:
>>>
>>> > Marton Balint 于2020年5月2日周六 下午7:05写道：
>>>
>>> [...]
>>>
>>> >> I see. But you could add an option to the fifo muxer to only write
>>
On Tue, 5 May 2020, Tao Zhang wrote:
Marton Balint 于2020年5月5日周二 上午3:48写道：
On Sat, 2 May 2020, Tao Zhang wrote:
> Marton Balint 于2020年5月2日周六 下午7:05写道：
[...]
>> I see. But you could add an option to the fifo muxer to only write header
>> when the first packet arrives. This way you will
Marton Balint:
>
>
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>
>> Marton Balint:
>>>
>>>
>>> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>>>
Marton Balint:
>
>
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>
>> Marton Balint:
>>> Previously only 1:1 bitstre
On Tue, 5 May 2020, Andreas Rheinhardt wrote:
Marton Balint:
On Tue, 5 May 2020, Andreas Rheinhardt wrote:
Marton Balint:
On Tue, 5 May 2020, Andreas Rheinhardt wrote:
Marton Balint:
Previously only 1:1 bitstream filters were supported, the end of the
stream was
not signalled to the
Marton Balint:
>
>
> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>
>> Marton Balint:
>>>
>>>
>>> On Tue, 5 May 2020, Andreas Rheinhardt wrote:
>>>
Marton Balint:
> Previously only 1:1 bitstream filters were supported, the end of the
> stream was
> not signalled to the bitstrea
On Tue, 5 May 2020, Andreas Rheinhardt wrote:
Marton Balint:
On Tue, 5 May 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.
This chang
Marton Balint:
>
>
> On Tue, 5 May 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.
>>>
>>> This change also allows muxers
On Tue, 5 May 2020, Andreas Rheinhardt wrote:
Marton Balint:
Signed-off-by: Marton Balint
---
Changelog | 1 +
doc/bitstream_filters.texi | 30 ++
libavcodec/Makefile| 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/pcm_rechunk_bsf.c |
On Tue, 5 May 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.
This change also allows muxers to set up bitstream filters regardless of the
Andreas Rheinhardt:
> Up until now, SeekEntries were already added before
> start_ebml_master_crc32() was even called and before we were actually
> sure that we really write the element the SeekHead references; after
> all, we might also error out later; and given that the allocations
> implicit in
56 matches
Mail list logo
