> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: Wednesday, April 29, 2020 06:57
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: [FFmpeg-devel] [PATCH] ffmpeg: Don't require a known device to
> pass a frames context to an encoder
>
> The previous version
fix ticket: 8625
and add testcase into url for double dot corner case
Signed-off-by: Steven Liu
---
libavformat/tests/url.c | 5 +++
libavformat/url.c | 77 ++---
tests/ref/fate/url | 5 +++
3 files changed, 83 insertions(+), 4 deletions(-)
diff
segment duration is using vs duration which compute by frame per second,
that can not fix problem of VFR video stream, so compute the duration
when split the segment, set the segment target duration use
current packet pts minus the prev segment end pts and plus current
packet's duration.
Ignore this patch please.
> 2020年4月29日 下午12:33，Steven Liu 写道：
>
> add option for refresh init file after m3u8 refresh everytime.
>
> Reported-by: Zhao Jun
> Signed-off-by: Steven Liu
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 41 -
>
add option for refresh init file after m3u8 refresh everytime.
Reported-by: Zhao Jun
Signed-off-by: Steven Liu
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 41 -
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/doc/muxers.texi
From: Mark Reid
---
libavcodec/exr.c | 103 +++
1 file changed, 86 insertions(+), 17 deletions(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 73419eadb1..f86e97a433 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -161,6 +161,7 @@
From: Mark Reid
---
libswscale/input.c | 91 ++
libswscale/utils.c | 4 ++
2 files changed, 95 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index 099661cb6d..e74cf04133 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
From: Mark Reid
---
libswscale/output.c | 82
libswscale/slice.c | 28
libswscale/swscale_unscaled.c| 33 ++
libswscale/utils.c | 8 +--
"slice mode" option 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.
Add
It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.
Set these default values to -1 to check whether it's specified
by user explicitly.
Use 2Mbps bitrate as nvenc sugguested, and leave gop size
untouched
RC_BITRATE_MODE:
set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust
in RcCalculatePictureQp().
RC_BUFFERBASED_MODE:
use buffer status to adjust the video quality.
RC_TIMESTAMP_MODE:
bit rate control based on timestamp, introduced in release 1.4.
Default to use
Clip iMinQp/iMaxQp to (1, 51) for user specified qp range.
If not set, leave iMinQp/iMaxQp untouched and use the values (0, 51)
initialized in FillDefault(), and the QP range would be adjusted to the
defaults inside libopenh264 library according to the iUsageType, (12, 42)
for iUsageType ==
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 | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Mark Reid
Hi,
The following patches add initial input/output support for planer rgb floating
point pixel formats in
libswscale and adds a decoder option to exr to output as float.
Mark Reid (3):
libswscale: add input support AV_PIX_FMT_GBRAPF32
libswscale: add output support for
> From: Martin Storsjö
> Sent: Wednesday, April 29, 2020 03:18
> To: Fu, Linjie
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH v5 3/5] lavc/libopenh264enc: add bit
> rate control select support
>
> On Tue, 28 Apr 2020, Fu, Linjie wrote:
From: Andriy Gelman
This fixes several mem leaks when init of encoder/decoder failed.
Fixes ticket #8285
Signed-off-by: Andriy Gelman
---
Changes in v2:
- Use FF_CODEC_CAP_INIT_CLEANUP
This patch supersedes:
> -Original Message-
> From: ffmpeg-devel On Behalf Of Andriy
> Gelman
> Sent: Wednesday, April 29, 2020 1:07 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andriy Gelman
> Subject: [EXT] [FFmpeg-devel] [PATCH v5] avcodec/v4l2_m2m_enc: Support
> changing qmin/qmax
>
> Caution: EXT Email
>
>
The previous version here did not handle passing a frames context when
ffmpeg itself did not know about the device it came from (for example,
because it was created by device derivation inside a filter graph), which
would break encoders requiring that input. Fix that by checking for HW
frames and
Apr 29, 2020, 00:02 by ceffm...@gmail.com:
> Am Di., 28. Apr. 2020 um 20:20 Uhr schrieb Lynne :
>
>>
>> Part of this patch is based on Paul B Mahol's patch from last year.
>>
>> This also allows for single-stream parameter/codec changes.
>>
>> Must be applied on top of the latest version of other
Andreas Rheinhardt:
> hdsenc already had an explicit function to free all allocations in case
> of an error, but it was not marked as deinit function, so that it was
> not called automatically when the AVFormatContext for muxing gets freed.
>
> Using an explicit deinit function also makes the
Am Di., 28. Apr. 2020 um 20:20 Uhr schrieb Lynne :
>
> Part of this patch is based on Paul B Mahol's patch from last year.
>
> This also allows for single-stream parameter/codec changes.
>
> Must be applied on top of the latest version of other 3 patches I sent today.
Are they related to tickets
Attached is a small patch-in-concept to provide access to extension headers
received in RTP streams by passing the header as AVPacket side data. My
specific use case is accessing metadata embedded in streams from Parrot
hardware [1]. Is this functionality something you would be interested in
On Tue, 28 Apr 2020, Fu, Linjie wrote:
From: Martin Storsjö
Sent: Tuesday, April 28, 2020 18:31
To: FFmpeg development discussions and patches
Cc: Fu, Linjie
Subject: Re: [FFmpeg-devel] [PATCH v5 3/5] lavc/libopenh264enc: add bit
rate control select support
On Tue, 28 Apr 2020, Linjie Fu
Part of this patch is based on Paul B Mahol's patch from last year.
This also allows for single-stream parameter/codec changes.
Must be applied on top of the latest version of other 3 patches I sent today.
>From 70dcc91b32c89cb580bf13f2c081fa8e74f226f9 Mon Sep 17 00:00:00 2001
From: Lynne
From: Andriy Gelman
Hard coded parameters for qmin and qmax are currently used to initialize
v4l2_m2m device. This commit uses values from avctx->{qmin,qmax} if they
are set.
Signed-off-by: Andriy Gelman
---
Changes in v5:
- Check that qmin does not exceed qmax (thanks for feedback from
On Sun, 26 Apr 2020, James Almer wrote:
On 4/26/2020 5:34 AM, Marton Balint wrote:
void avcodec_flush_buffers(AVCodecContext *avctx)
{
AVCodecInternal *avci = avctx->internal;
@@ -2117,7 +2001,7 @@ void avcodec_flush_buffers(AVCodecContext *avctx)
avctx->pts_correction_last_pts =
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 | 220 +
It is not used by anything anymore.
Signed-off-by: Marton Balint
---
libavformat/retimeinterleave.c | 51 --
libavformat/retimeinterleave.h | 51 --
2 files changed, 102 deletions(-)
delete mode 100644
Generic retime functionality is replaced by a few lines of code directly in the
muxers which used it, which seems a lot easier to understand and this way the
retiming is not dependant of the input durations.
Signed-off-by: Marton Balint
---
libavformat/Makefile | 4 ++--
libavformat/gxfenc.c |
And rename it to retimeinterleave, use the pcm_rechunk bitstream filter for
rechunking.
By seperating the two functions we hopefully get cleaner code.
Signed-off-by: Marton Balint
---
configure | 2 +
libavformat/Makefile
Signed-off-by: Marton Balint
---
libavformat/mux.c | 52 +---
1 file changed, 21 insertions(+), 31 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index df0d9e993a..c91df91be8 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
In preparation for N:M bsf support.
Signed-off-by: Marton Balint
---
libavformat/mux.c | 87 ++-
1 file changed, 41 insertions(+), 46 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index c91df91be8..33aed9da90 100644
---
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
autobsf flag during write_header instead of during
Will be needed later to avoid a forward declaration.
Signed-off-by: Marton Balint
---
libavformat/mux.c | 208 +++---
1 file changed, 104 insertions(+), 104 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index
Apr 28, 2020, 16:07 by d...@lynne.ee:
> Apr 28, 2020, 15:59 by mattias.wad...@gmail.com:
>
>>
>>
> Well, I consider CRC checking a part of correctly parsing ogg, so I think its
> best to leave it on
> all the time.
>
Did a new version of the patches.
The first two are identical, save for some
On 4/28/20, Michael Niedermayer wrote:
> On Tue, Apr 28, 2020 at 12:05:24PM +0200, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> doc/filters.texi | 8 +
>> libavfilter/af_amix.c | 70 ++-
>> 2 files changed, 58 insertions(+), 20
On Tue, Apr 28, 2020 at 12:15:19AM -0600, Roger Pack wrote:
> I needed this in order to be able to parse raw analog TV closed
> caption byte pairs (analog line 21 CC's).
> configure |1
> libavcodec/Makefile |2
> libavcodec/allcodecs.c|1
>
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 structure in which
> > the values are intended to be exported; it does not add any demuxing or
> > muxing capabilities for mov or mkv (as you can
> From: ffmpeg-devel 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, Josh Brewster wrote:
> I only made sure
On Tue, Apr 28, 2020 at 12:05:24PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 8 +
> libavfilter/af_amix.c | 70 ++-
> 2 files changed, 58 insertions(+), 20 deletions(-)
This breaks fate
STRIP ffmpeg
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 18:28
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v5 1/5] lavc/libopenh264enc: Add
> qmin/qmax support
>
> On Tue, 28 Apr 2020, Linjie Fu wrote:
>
> > Clip
Am Mo., 27. Apr. 2020 um 08:18 Uhr schrieb :
The suggested patch is currently not ok.
> From: Jim DeLaHunt
>
> This is a complete rewrite of the documentation for the "fps" video
> filter. It describes the filter's behaviour more clearly and accurately.
> I based the rewrite on reading the
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 18:29
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v5 2/5] lavc/libopenh264enc: add
> default gop size and bit rate
>
> On Tue, 28 Apr 2020, Linjie Fu wrote:
>
>
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 18:31
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v5 3/5] lavc/libopenh264enc: add bit
> rate control select support
>
> On Tue, 28 Apr 2020, Linjie Fu wrote:
>
On 26/04/2020 12:46, Josh Brewster wrote:
I only made sure that the level was positive because its initial
value was -1.
else if (x4->params.i_level_idc >= 0) {
Let me know if I need to reject 0 too. It seemed like premature optimization
as the level simply wouldn't be present in x264_levels.
fix ticket: 8625
and add testcase into url for double dot corner case
Signed-off-by: Steven Liu
---
libavformat/tests/url.c | 5 +++
libavformat/url.c | 80 ++---
tests/ref/fate/url | 5 +++
3 files changed, 86 insertions(+), 4 deletions(-)
diff
Apr 28, 2020, 15:59 by mattias.wad...@gmail.com:
> On Tue, Apr 28, 2020 at 4:45 PM Lynne wrote:
>
>>
>> Apr 28, 2020, 15:31 by mattias.wad...@gmail.com:
>>
>> > Nice, test files works fine now
>> >
>> > Would it make sense to conditionally ignore crc mismatch based on
>> > s->error_recognition &
Apr 28, 2020, 15:31 by mattias.wad...@gmail.com:
> Nice, test files works fine now
>
> Would it make sense to conditionally ignore crc mismatch based on
> s->error_recognition & AV_EF_CRCCHECK ?
>
I don't think so. This container specifically relies on CRC matching to
identify packets
during a
On Tue, Apr 28, 2020 at 4:45 PM Lynne wrote:
>
> Apr 28, 2020, 15:31 by mattias.wad...@gmail.com:
>
> > Nice, test files works fine now
> >
> > Would it make sense to conditionally ignore crc mismatch based on
> > s->error_recognition & AV_EF_CRCCHECK ?
> >
>
> I don't think so. This container
On 27/04/2020 07:17, list+ffmpeg-...@jdlh.com wrote:
From: Jim DeLaHunt
This is a complete rewrite of the documentation for the "fps" video
filter. It describes the filter's behaviour more clearly and accurately.
I based the rewrite on reading the source code in vf_fps.c closely.
No code, or
On Tue, Apr 28, 2020 at 4:12 PM Lynne wrote:
>
> Apr 28, 2020, 14:05 by mattias.wad...@gmail.com:
>
> > On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
> >
> >>
> >> This makes decoding far more robust, since OggS, the ogg magic,
> >> can be commonly found randomly in streams, which previously made
Apr 28, 2020, 14:05 by mattias.wad...@gmail.com:
> On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
>
>>
>> This makes decoding far more robust, since OggS, the ogg magic,
>> can be commonly found randomly in streams, which previously made
>> the demuxer think there's a new stream or a change in
On Fri, Apr 24, 2020 at 01:27:13AM +0200, Michael Niedermayer wrote:
> On Thu, Apr 16, 2020 at 01:25:51AM +0200, Michael Niedermayer wrote:
> > On Wed, Apr 15, 2020 at 06:37:55PM -0300, James Almer wrote:
> > > On 4/15/2020 6:10 PM, 曾经的梦 wrote:
> > > > Because I added many custom features in
Andreas Rheinhardt:
> The data of an AVPacket may be a part of the data of an AVBufferRef;
> Therefore av_grow_packet() doesn't reallocate if the available space in
> the actual buffer is sufficient for the enlargement. But given that it
> also zeroes the padding it also needs to make sure that
On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
>
> This makes decoding far more robust, since OggS, the ogg magic,
> can be commonly found randomly in streams, which previously made
> the demuxer think there's a new stream or a change in such.
>
> Patch attached.
Maybe nitpick, could seek back
On Tue, Apr 28, 2020 at 1:59 PM Lynne wrote:
>
> This makes decoding far more robust, since OggS, the ogg magic,
> can be commonly found randomly in streams, which previously made
> the demuxer think there's a new stream or a change in such.
>
> Patch attached.
Should check version after
It furthermore tests the demuxer's handling of chained SeekHeads,
level 1-elements after the Clusters and the muxer's capability of
writing huge TrackNumbers as well as expanding the Cues' length field
by one byte if necessary to fill the reserved space. It also tests
propagation of metadata.
On Tue, Apr 28, 2020 at 2:01 PM Lynne wrote:
>
> Apr 27, 2020, 21:55 by mich...@niedermayer.cc:
>
> > On Mon, Apr 27, 2020 at 05:19:49PM +0200, Mattias Wadman wrote:
> >
> >> Fixes seek issue with ogg files that have segment data that happens to be
> >> encoded as a "OggS" page syncword. Very
On Fri, Apr 17, 2020 at 03:35:44 +0200, one...@oneric.de wrote:
> From 74d3f6bd0189b0f4922404fccbefe95e1f01093d Mon Sep 17 00:00:00 2001
> From: Oneric
> Date: Fri, 17 Apr 2020 00:38:53 +0200
> Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderAndShadow
> […]
> 25 files changed, 25
Apr 27, 2020, 21:55 by mich...@niedermayer.cc:
> On Mon, Apr 27, 2020 at 05:19:49PM +0200, Mattias Wadman wrote:
>
>> Fixes seek issue with ogg files that have segment data that happens to be
>> encoded as a "OggS" page syncword. Very unlikely but seems to happen.
>>
>> Have been observed to
This just cleans up the code and simplifies it.
Patch attached.
>From 401b0d86f38905c647cc591b0bd34662b0953e5c Mon Sep 17 00:00:00 2001
From: Lynne
Date: Tue, 28 Apr 2020 12:55:17 +0100
Subject: [PATCH 3/3] oggdec: use ffio_ensure_seekback() to not require seeking
to read the magic
This just
This makes decoding far more robust, since OggS, the ogg magic,
can be commonly found randomly in streams, which previously made
the demuxer think there's a new stream or a change in such.
Patch attached.
>From 61759b6b1ef3ca813eb39ee9ace2342eb121b3b0 Mon Sep 17 00:00:00 2001
From: Lynne
Date:
This also makes implementing CRC checking far simpler and more robust.
Patch attached.
>From 2a32f16108e6a424b20a15be4e06ebe6e92535a9 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Tue, 28 Apr 2020 12:41:34 +0100
Subject: [PATCH 1/3] oggdec: eliminate copies and extra buffers
This also makes
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/pp_bnk.c | 289 +++
libavformat/version.h| 4 +-
5 files changed, 294 insertions(+), 2 deletions(-)
On Sun, Apr 26, 2020 at 10:00 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Mark Thompson
> > Sent: Sunday, April 26, 2020 8:54 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3 4/4] libavutil/qsv: enabling
> d3d11va
> >
On Tue, Apr 28, 2020 at 1:06 PM Mattias Wadman wrote:
>
> Fixes seek issue with ogg files that have segment data that happens to be
> encoded as a "OggS" page syncword. Very unlikely but seems to happen.
>
> Have been observed to happen with ffmpeg+libvorbis and oggenc encoding
> to 441khz stereo
Fixes seek issue with ogg files that have segment data that happens to be
encoded as a "OggS" page syncword. Very unlikely but seems to happen.
Have been observed to happen with ffmpeg+libvorbis and oggenc encoding
to 441khz stereo at 160kbps.
---
libavformat/oggdec.c | 136
On Tue, 28 Apr 2020, Linjie Fu wrote:
"slice mode" option 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:
On Tue, 28 Apr 2020, Linjie Fu wrote:
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 | 2 ++
1 file
On Tue, 28 Apr 2020, Linjie Fu wrote:
RC_BITRATE_MODE:
set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust
in RcCalculatePictureQp().
RC_BUFFERBASED_MODE:
use buffer status to adjust the video quality, introduced in
release 1.2.
RC_TIMESTAMP_MODE:
bit rate control based
On Tue, 28 Apr 2020, Linjie Fu wrote:
It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.
Set these default values to -1 to check whether it's specified
by user explicitly.
Use 2Mbps bitrate as nvenc
On Tue, 28 Apr 2020, Linjie Fu wrote:
Clip iMinQp/iMaxQp to (1, 51) if user specified qp range
explicitly since QP = 0 is not well supported currently
in libopenh264, otherwise leave iMinQp/iMaxQp untouched
and use the values initialized in FillDefault().
I'd suggest changing the commit
Andreas Rheinhardt (12020-04-28):
> That's expected. The patch provided only provides the structure in which
> the values are intended to be exported; it does not add any demuxing or
> muxing capabilities for mov or mkv (as you can see from the fact that
> none of these (de)muxers have been
Kieran O Leary:
> Hi Neil,
>
> Thanks so much for working on this - what was the impetus?
> I started the ticket you mentioned. I applied your patch and tested it with
> the clap.mov file from that ticket. How do I know if behaviour has changed
> with this patch, how should I be testing?
> I
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 8 +
libavfilter/af_amix.c | 70 ++-
2 files changed, 58 insertions(+), 20 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 55edd564bf..fe661c0b4b 100644
---
Hi Neil,
Thanks so much for working on this - what was the impetus?
I started the ticket you mentioned. I applied your patch and tested it with
the clap.mov file from that ticket. How do I know if behaviour has changed
with this patch, how should I be testing?
I don't see any reference to the
Commit 6fd300ac6c2c3871736ce0e6df95603255004dc6 added support for WebM
Chunk livestreaming; in this case, both the header as well as each
Cluster is written to a file of its own, so that even if the AVIOContext
seems seekable, the muxer has to behave as if it were not. Yet one of
the added checks
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 16:08
> To: Fu, Linjie
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH v4 2/9] lavc/libopenh264enc: add
> default gop size and bit rate
>
> On Tue, 28 Apr 2020, Fu, Linjie wrote:
>
>
It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.
Set these default values to -1 to check whether it's specified
by user explicitly.
Use 2Mbps bitrate as nvenc sugguested, and leave gop size
untouched
"slice mode" option 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.
Add
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 | 2 ++
1 file changed, 2 insertions(+)
diff --git
Separate the set, and updated a v5 version as suggested.
Linjie Fu (5):
lavc/libopenh264enc: Add qmin/qmax support
lavc/libopenh264enc: add default gop size and bit rate
lavc/libopenh264enc: add bit rate control select support
lavc/libopenh264enc: prompt slice number changing inside
RC_BITRATE_MODE:
set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust
in RcCalculatePictureQp().
RC_BUFFERBASED_MODE:
use buffer status to adjust the video quality, introduced in
release 1.2.
RC_TIMESTAMP_MODE:
bit rate control based on timestamp, introduced in release
Clip iMinQp/iMaxQp to (1, 51) if user specified qp range
explicitly since QP = 0 is not well supported currently
in libopenh264, otherwise leave iMinQp/iMaxQp untouched
and use the values initialized in FillDefault().
Note that if iMaxQp/iMinQp equals 0, the QP range would
be adjusted inside
On Mon, Apr 27, 2020 at 4:38 AM Lynne wrote:
> Apr 27, 2020, 05:27 by neil.birkb...@gmail.com:
>
> > The clean aperature represents a cropping of the stored image data used
> to
> > relate the image data to a canonical video system and exists as container
> > metadata (see 'clap' section in
>
On 4/26/20, Sebastian Dröge wrote:
> From: Sebastian Dröge
>
> s->target_i and global are in dB but s->target_tp and true_peak are
> linear. Instead of mixing these in the calculations, convert the former
> first to have all following calculations in the same unit.
> ---
>
This avoids errors lateron after the file header has already been
partially written.
Signed-off-by: Andreas Rheinhardt
---
Also avoids a memleak in case of missing mimetype metadata.
libavformat/matroskaenc.c | 39 ---
1 file changed, 24 insertions(+), 15
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 668b18e9ee..09f08c1e9f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1463,6 +1463,7 @@
If a FLAC track uses an unconventional channel layout, the Matroska
muxer adds a WAVEFORMATEXTENSIBLE_CHANNEL_MASK VorbisComment to the
CodecPrivate to preserve this information. And given that FLAC uses
24bit length fields, the muxer checks if the length is more than this
and errors out if it is.
ff_vorbiscomment_write() used up until now the bytestream API to write
VorbisComments. Therefore the caller had to provide a sufficiently large
buffer to write the output.
Yet two of the three callers (namely the FLAC and the Matroska muxer)
actually want the output to be written via an
ff_vorbiscomment_write() used an AVDictionary ** parameter for a
dictionary whose contents ought to be written; yet this can be replaced
by AVDictionary * since commit 042ca05f0fdc5f4d56a3e9b94bc9cd67bca9a4bc;
and this in turn can be replaced by const AVDictionary * to indicate
that the dictionary
This has previously only been checked if the chapters were initially
available, but not if they were only written in the trailer.
Signed-off-by: Andreas Rheinhardt
---
Any Tags pertaining to Chapters added late are currently ignored/lost,
too. The Matroska specifications allow multiple Tags
On Tue, 28 Apr 2020, Fu, Linjie wrote:
From: Martin Storsjö
Sent: Tuesday, April 28, 2020 14:28
To: Fu, Linjie
Cc: FFmpeg development discussions and patches
Subject: RE: [FFmpeg-devel] [PATCH v4 2/9] lavc/libopenh264enc: add
default gop size and bit rate
On Tue, 28 Apr 2020, Fu, Linjie
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 04:02
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v4 6/9] lavc/libopenh264enc: separate
> svc_encode_init() into several functions
>
> On Wed, 15 Apr 2020, Linjie
On Tue, Apr 28, 2020 at 8:19 AM Roger Pack wrote:
>
> I didn't actually *need* this but thought the functionality was very
> nice to have, so here's my contribution.
>
> It allows for forcing "rollup" style closed captions to output one
> line at a time (basically, when there is a carriage
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 03:35
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: Re: [FFmpeg-devel] [PATCH v4 3/9] lavc/libopenh264enc: add bit
> rate control select support
>
> On Wed, 15 Apr 2020, Linjie Fu wrote:
>
> From: Martin Storsjö
> Sent: Tuesday, April 28, 2020 14:28
> To: Fu, Linjie
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH v4 2/9] lavc/libopenh264enc: add
> default gop size and bit rate
>
> On Tue, 28 Apr 2020, Fu, Linjie wrote:
>
>
On Tue, 28 Apr 2020, Fu, Linjie wrote:
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Tuesday, April 28, 2020 14:31
To: Fu, Linjie
Cc: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v4 1/9] lavc/libopenh264enc: Add
default qmin/qmax support
On Tue, 28
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Tuesday, April 28, 2020 14:31
> To: Fu, Linjie
> Cc: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/9] lavc/libopenh264enc: Add
> default qmin/qmax support
>
> On Tue, 28 Apr
Here's the final piece (to actually use the new codec), where we allow
to read raw CC 608 byte pairs from
analog directshow TV capture devices ("read" in a loose sense of the
term, it requires an intermediate dshow filter to extract the CC raw
bytes from the VBI incoming stream, but anyway it
1 - 100 of 108 matches
Mail list logo
