On Wed, 7 Aug 2024 at 09:13, Josh Allmann wrote:
>
> On Thu, 1 Aug 2024 at 14:37, Josh Allmann wrote:
> >
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > During An
On Thu, 1 Aug 2024 at 14:37, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffer
On Thu, 1 Aug 2024 at 00:58, Anton Khirnov wrote:
>
Thanks for the review.
> Quoting Josh Allmann (2024-07-09 21:05:47)
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > D
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
On Mon, 22 Jul 2024 at 17:17, Timo Rothenpieler wrote:
>
> On 23/07/2024 01:01, Josh Allmann wrote:
> > On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
> >>
> >> Encoders may emit a buffering period SEI without a corresponding
> >> SPS/PPS if the SPS/P
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffer
On Mon, 15 Jul 2024 at 10:48, Josh Allmann wrote:
>
> On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
> >
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > During An
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffer
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
On Sat, 6 Jul 2024 at 09:37, Michael Niedermayer wrote:
>
> On Wed, Jul 03, 2024 at 02:05:06PM -0700, Josh Allmann wrote:
> > Encoders may emit a buffering period SEI without a corresponding
> > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >
> > D
Encoders may emit a buffering period SEI without a corresponding
SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
During Annex B conversion, this may result in the SPS/PPS being
inserted *after* the buffering period SEI but before the IDR NAL.
Since the buffering period SEI references
On Thu, 20 Jun 2024 at 17:39, Josh Allmann wrote:
>
> In intra-only mode, frameIntervalP is 0, which means the frame
> data array is smaller than the number of surfaces. This causes a
> crash when closing the encoder.
>
> Fix this by making sure the frame data array is at lea
In intra-only mode, frameIntervalP is 0, which means the frame
data array is smaller than the number of surfaces. This causes a
crash when closing the encoder.
Fix this by making sure the frame data array is at least as big as
the number of surfaces.
---
libavcodec/nvenc.c | 2 +-
1 file changed,
On Thu, 13 May 2021 at 16:38, Josh Allmann wrote:
>
> Previously, one or the other would have been ignored, but not both.
> Since the probe terminates at three streams, it could exit
> prematurely if both data and subtitles are present along with
> slightly trailing media, usually
Previously, one or the other would have been ignored, but not both.
Since the probe terminates at three streams, it could exit
prematurely if both data and subtitles are present along with
slightly trailing media, usually video trailing audio.
Trailing media is common in RTMP, and encoders write s
Hi Martin,
On Fri, 15 Jan 2021 at 04:59, Martin Storsjö wrote:
>
> Hi Josh,
>
> On Tue, 22 Dec 2020, Josh Allmann wrote:
>
> > Thank you for taking the time to look into this! Tested with your
> > alternative patch and it does seem to be an improvement. I was able
Hi Martin,
On Sat, 19 Dec 2020 at 15:10, Martin Storsjö wrote:
>
> On Fri, 11 Dec 2020, Josh Allmann wrote:
>
> > On Fri, 11 Dec 2020 at 14:07, Martin Storsjö wrote:
> >>
> >> On Fri, 11 Dec 2020, Josh Allmann wrote:
> >>
> >> > A negative
On Fri, 11 Dec 2020 at 14:07, Martin Storsjö wrote:
>
> On Fri, 11 Dec 2020, Josh Allmann wrote:
>
> > A negative start_dts value (eg, delay from edit lists) typically yields
> > a duration larger than end_pts. During edit list processing, the
> > delay is removed
A negative start_dts value (eg, delay from edit lists) typically yields
a duration larger than end_pts. During edit list processing, the
delay is removed again, yielding the correct duration within the elst.
However, other duration-carrying atoms (tkhd, mvhd, mdhd) still have
the delay incorporate
On Tue, 14 Apr 2020 at 01:53, Josh de Kock wrote:
>
> Hi,
>
> On Mon, Apr 13, 2020, at 10:32 PM, Josh Allmann wrote:
> > Hi,
> >
> > On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote:
> > >
> > > Signed-off-by: Josh de Kock
> > > ---
>
On Mon, 13 Apr 2020 at 04:39, Anton Khirnov wrote:
>
> Quoting Philip Langdale (2020-04-11 01:47:43)
> > We've been in this fuzzy situation where maybe you could call
> > avcodec_flush_buffers() on an encoder but there weren't any encoders
> > that supported it except maybe audiotoolboxenc. Then w
Hi,
On Sat, 24 Mar 2018 at 14:40, Josh de Kock wrote:
>
> Signed-off-by: Josh de Kock
> ---
> configure| 29 +-
> doc/APIchanges | 4 +
> doc/writing_filters.txt | 6 +-
> libavfilter/allfilters.c | 823
> +--
> libavf
On Mon, 30 Dec 2019 at 16:40, Philip Langdale wrote:
>
> On Sat, 21 Dec 2019 14:54:38 -0800
> Philip Langdale wrote:
>
> > On Fri, 20 Dec 2019 16:07:18 -0800
> > Josh Allmann wrote:
> >
> > > One concern I had was about the long-term stability of this
&
On Fri, 20 Dec 2019 at 15:34, Philip Langdale wrote:
>
> It can be useful to re-use an encoder instance when doing segmented
> encodings, and this requires flushing the encoder at the start of
> each segment.
> ---
> libavcodec/nvenc.c | 5 +
> libavcodec/nvenc.h | 2 ++
> libavcode
On Fri, 20 Dec 2019 at 15:36, Philip Langdale wrote:
>
> On 2019-11-18 17:13, Josh Allmann wrote:
> > This patch is meant to be an entry point for discussion around an
> > issue we are having with flushing the nvenc encoder while doing
> > segmented transcoding. Hopefu
This patch is meant to be an entry point for discussion around an
issue we are having with flushing the nvenc encoder while doing
segmented transcoding. Hopefully there will be a less kludgey
workaround than this.
First, some background some info on where this is coming from. We do
segmented trans
On Fri, 24 May 2019 at 09:55, Timo Rothenpieler wrote:
>
> On 24.05.2019 18:27, Josh Allmann wrote:
> > On Fri, 24 May 2019 at 06:00, Timo Rothenpieler
> > wrote:
> >>
> >> On 24/05/2019 01:49, Josh Allmann wrote:
> >>&
The first frame is scaled correctly, and subsequent frames are
over-scaled / cropped since the frame data is reset with the
hwframe after each invocation of the scaler.
The hwframe-allocated frame has a width/height that is 32-bit
aligned. The scaler uses this aligned width / height as its target,
On Fri, 24 May 2019 at 06:00, Timo Rothenpieler wrote:
>
> On 24/05/2019 01:49, Josh Allmann wrote:
> > Makes certain usages of the lavfi API easier.
> > ---
> > libavfilter/vf_scale_cuda.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
&g
Makes certain usages of the lavfi API easier.
---
libavfilter/vf_scale_cuda.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_scale_cuda.c b/libavfilter/vf_scale_cuda.c
index b7cdb81081..6b1ef2bb6f 100644
--- a/libavfilter/vf_scale_cuda.c
+++ b/libav
On 7 March 2018 at 18:03, Michael Niedermayer wrote:
> On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
>> ---
>> doc/bitstream_filters.texi | 5 +
>> libavcodec/noise_bsf.c | 12
>> libavcodec/version.h | 2 +-
>> 3 f
---
doc/bitstream_filters.texi | 5 +
libavcodec/noise_bsf.c | 12
libavcodec/version.h | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index cfd81fa12d..a9f17f32ec 100644
--- a/doc/bitstrea
On 6 February 2018 at 03:16, Rostislav Pehlivanov
wrote:
> On 6 February 2018 at 06:56, Josh Allmann
> wrote:
>
> > Fixes a leak that occurs if avctx->extradata contains any data
> > prior to opening the codec, eg left over from an initialization
> > call to a
Fixes a leak that occurs if avctx->extradata contains any data
prior to opening the codec, eg left over from an initialization
call to avcodec_parameters_from_context.
---
libavcodec/aacenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 6d
---
libavformat/rtmpproto.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index faf2a6f244..b741e421af 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2431,8 +2431,10 @@ static int get_packet(URLConte
35 matches
Mail list logo
