On Tue, 13 Jul 2021, 02:45 James Almer, wrote:
> On 7/12/2021 10:01 PM, Kieran Kunhya wrote:
> >>
> >> Because it isn't something that should be marked as a keyframe as coded
> >> bitstream in any kind of container, like it's the case of mp4 sync
> samples.
> >>
> >
> > MPEG-TS Random Access Indi
On 7/12/2021 10:01 PM, Kieran Kunhya wrote:
Because it isn't something that should be marked as a keyframe as coded
bitstream in any kind of container, like it's the case of mp4 sync samples.
MPEG-TS Random Access Indicator expects keyframes to be signalled like this.
With intra-refresh and t
>
> Because it isn't something that should be marked as a keyframe as coded
> bitstream in any kind of container, like it's the case of mp4 sync samples.
>
MPEG-TS Random Access Indicator expects keyframes to be signalled like this.
With intra-refresh and this code removed, there will be no random
On 7/12/2021 8:53 PM, Kieran Kunhya wrote:
On Mon, 12 Jul 2021 at 20:33, James Almer wrote:
None of these packets contain keyframes, and tagging them as such can
result in
non spec compliant output when remuxing into containers like mp4 and
Matroska,
where bogus samples would be marked as Sync
On Mon, 12 Jul 2021 at 20:33, James Almer wrote:
> None of these packets contain keyframes, and tagging them as such can
> result in
> non spec compliant output when remuxing into containers like mp4 and
> Matroska,
> where bogus samples would be marked as Sync Samples.
>
> Some tests are updated
Thanks to Jan Ekström for details
---
src/security | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/security b/src/security
index 935823b..1248018 100644
--- a/src/security
+++ b/src/security
@@ -15,6 +15,7 @@ CVE-2020-21041, 5d9f44da460f781a1604d537d0555b78e29438ba,
ticket/7989
CVE-2020-
On 7/12/2021 4:39 PM, Michael Niedermayer wrote:
On Mon, Jul 12, 2021 at 01:07:07PM +0200, Anton Khirnov wrote:
---
libavfilter/vf_scale.c | 73 --
1 file changed, 49 insertions(+), 24 deletions(-)
crashes:
./ffmpeg -i ~/tickets/5264/gbrap16.tif -
On Mon, Jul 12, 2021 at 01:07:07PM +0200, Anton Khirnov wrote:
> ---
> libavfilter/vf_scale.c | 73 --
> 1 file changed, 49 insertions(+), 24 deletions(-)
crashes:
./ffmpeg -i ~/tickets/5264/gbrap16.tif -vf
format=yuva444p,scale=alphablend=checkerboard,
None of these packets contain keyframes, and tagging them as such can result in
non spec compliant output when remuxing into containers like mp4 and Matroska,
where bogus samples would be marked as Sync Samples.
Some tests are updated to reflect this.
Suggested-by: ffm...@fb.com
Signed-off-by: Ja
On Mon, Jul 12, 2021 at 01:07:09PM +0200, Anton Khirnov wrote:
> ---
> libavfilter/vf_scale.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index cdff3ab7ed..f676f5d82e 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.
On Mon, Jul 12, 2021 at 01:07:06PM +0200, Anton Khirnov wrote:
[...]
> diff --git a/libswscale/swscale.h b/libswscale/swscale.h
> index 50d6d46553..41eacd2dea 100644
> --- a/libswscale/swscale.h
> +++ b/libswscale/swscale.h
> @@ -30,6 +30,7 @@
> #include
>
> #include "libavutil/avutil.h"
> +#i
On Mon, 12. Jul 11:02, Dave Stevenson wrote:
> On Sat, 10 Jul 2021 at 00:56, Brad Hards wrote:
> >
> > On Saturday, 10 July 2021 8:53:27 AM AEST Andrii wrote:
> > > I am working on porting a Kodi player to an NVidia Jetson Nano device.
> > > I've
> > > been developing a decoder for quite some tim
On Mon, 12 Jul 2021 at 14:51, Andrii wrote:
>>
>> A quick Google implies that NVidia already has a stateful V4L2 M2M
>> driver in their vendor kernel. Other than the strange choice of device
>> node name (/dev/nvhost-nvdec), the details at [3] make it look like a
>> normal V4L2 M2M decoder that ha
>
> A quick Google implies that NVidia already has a stateful V4L2 M2M
> driver in their vendor kernel. Other than the strange choice of device
> node name (/dev/nvhost-nvdec), the details at [3] make it look like a
> normal V4L2 M2M decoder that has a good chance of working against
> h264_v4l2m2m.
12 Jul 2021, 13:53 by jamr...@gmail.com:
> On 7/12/2021 7:46 AM, Lynne wrote:
>
>> 12 Jul 2021, 11:29 by alankelly-at-google@ffmpeg.org:
>>
>>> On Fri, Jun 25, 2021 at 1:24 PM Alan Kelly wrote:
>>>
On Fri, Jun 25, 2021 at 10:40 AM Lynne wrote:
> Jun 25, 2021, 09:54 by alankelly
On Sat, 26 Jun 2021, Martin Storsjö wrote:
On Fri, 25 Jun 2021, Hayden Myers wrote:
Some encoders send GET_PARAMETER requests as a keep-alive mechanism.
If the client doesn't reply with an OK message, the encoder will close
the session. This was encountered with the impath i5110 encoder, when
On Tue, 22 Jun 2021, Jan Ekström wrote:
From: Jan Ekström
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
as this eases the initial review.
Hmm, I'm not sure I understand here, this seems to add at least som
On 7/12/2021 7:46 AM, Lynne wrote:
12 Jul 2021, 11:29 by alankelly-at-google@ffmpeg.org:
On Fri, Jun 25, 2021 at 1:24 PM Alan Kelly wrote:
On Fri, Jun 25, 2021 at 10:40 AM Lynne wrote:
Jun 25, 2021, 09:54 by alankelly-at-google@ffmpeg.org:
Broadwell and later and Zen3 and later
On Mon, Jul 12, 2021 at 12:34:55PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-07-03 18:27:36)
> > On Sat, Jul 03, 2021 at 03:27:36PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2021-06-01 11:35:13)
> > > > On Mon, May 31, 2021 at 09:55:15AM +0200, Anton Khirn
On Mon, Jul 12, 2021 at 12:35 PM Anton Khirnov wrote:
>
> Quoting Michael Niedermayer (2021-07-03 18:27:36)
> > On Sat, Jul 03, 2021 at 03:27:36PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2021-06-01 11:35:13)
> > > > On Mon, May 31, 2021 at 09:55:15AM +0200, Anton Khirnov wro
---
libswscale/swscale.c | 263 ++
libswscale/swscale.h | 80 +++
libswscale/swscale_internal.h | 19 +++
libswscale/utils.c| 70 +
4 files changed, 374 insertions(+), 58 deletions(-)
diff --git a/libswscale/swscale.
---
libavfilter/vf_scale.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index cdff3ab7ed..f676f5d82e 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -543,6 +543,7 @@ static int config_props(AVFilterLink *outlink)
---
libavfilter/vf_scale.c | 73 --
1 file changed, 49 insertions(+), 24 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 39ab3a4b28..cdff3ab7ed 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -620,29 +620,
---
libswscale/options.c | 3 ++
libswscale/swscale.c | 56
libswscale/swscale_internal.h | 14 ++
libswscale/utils.c| 82 +++
4 files changed, 155 insertions(+)
diff --git a/libswscale/options.c b/libswsc
It can be shared with other simple demux/decode tools.
---
tests/ref/fate/source | 1 +
tools/Makefile | 2 +
tools/decode_simple.c | 157 +
tools/decode_simple.h | 53 ++
tools/venc_data_dump.c | 156 +
EINVAL is the wrong error code here, since the arguments passed to the
function are valid. The error is that the function is not implemented in
the build, which corresponds to ENOSYS.
---
libavutil/slicethread.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/slicethr
It was intended for debugging only and has been superseded by the
standalone tool for testing sliced scaling.
---
libavfilter/vf_scale.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 71d7fa2890..39ab3a4b28 100644
--- a/liba
---
Makefile | 2 +
tests/Makefile| 1 +
tests/fate/libswscale.mak | 11 +++
tools/Makefile| 3 +-
tools/scale_slice_test.c | 190 ++
5 files changed, 206 insertions(+), 1 deletion(-)
create mode 100644 tools/sca
Hi,
here is a new iteration of $subj. Compared to the first version,
threading has been moved into sws using lavu slicethread.
There is also a new AVFrame-based API that allows submitting and
receiving partial slices (at least API-wise, the implementation will
still wait for complete input). There
sön 2021-07-11 klockan 09:47 -0700 skrev p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> Signed-off-by: Pierre-Anthony Lemieux
> ---
>
> Notes:
> For JPEG 2000 essence, the MXF input format module currently uses the
> value of byte 14 of the essence container UL to determines whether
12 Jul 2021, 11:29 by alankelly-at-google@ffmpeg.org:
> On Fri, Jun 25, 2021 at 1:24 PM Alan Kelly wrote:
>
>> On Fri, Jun 25, 2021 at 10:40 AM Lynne wrote:
>>
>>> Jun 25, 2021, 09:54 by alankelly-at-google@ffmpeg.org:
>>>
>>> > Broadwell and later and Zen3 and later have fast gather ins
Quoting Michael Niedermayer (2021-07-03 18:27:36)
> On Sat, Jul 03, 2021 at 03:27:36PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-06-01 11:35:13)
> > > On Mon, May 31, 2021 at 09:55:15AM +0200, Anton Khirnov wrote:
> > > > ---
> > > > libavfilter/vf_scale.c | 182 +++
On Fri, Jun 25, 2021 at 1:24 PM Alan Kelly wrote:
> On Fri, Jun 25, 2021 at 10:40 AM Lynne wrote:
>
>> Jun 25, 2021, 09:54 by alankelly-at-google@ffmpeg.org:
>>
>> > Broadwell and later and Zen3 and later have fast gather instructions.
>> > ---
>> > Gather requires between 9 and 12 cycles o
> This doesn't move the pointer back to the file end if par->block_align is set.
> I think that's fine though, since the function writes the trailer, which
> should
> mean that nothing more needs to be written.
Is it a convention to leave the pointer positioned at the end of
the file?
___
On Sat, 10 Jul 2021 at 00:56, Brad Hards wrote:
>
> On Saturday, 10 July 2021 8:53:27 AM AEST Andrii wrote:
> > I am working on porting a Kodi player to an NVidia Jetson Nano device. I've
> > been developing a decoder for quite some time now, and realized that the
> > best approach would be to hav
In-Reply-To:
References: <20210710011006.3383868-1-roman.bera...@prusa3d.cz>
Reply-To: FFmpeg development discussions and patches
> This doesn't move the pointer back to the file end if par->block_align is set.
> I think that's fine though, since the function writes the trailer, which
> shoul
On Sat, Jul 10, 2021 at 8:55 PM James Almer wrote:
>
> On 7/10/2021 1:26 PM, Jan Ekström wrote:
> > On Wed, Jul 7, 2021, 22:01 Jan Ekström wrote:
> >
> >> Changes compared to v2:
> >> - Kept the CONFIG_LIBX264RGB_ENCODER define check for ff_libx264rgb_encoder
> >>and the AVClass for libx264rg
On Sunday, 11 July 2021 10:01:47 PM AEST Derek Buitenhuis wrote:
> Can you amend the commit message to contain the reasoning from [1]?
Amended.
> A quick review:
> > +void *sei_data;
> > +int sei_data_size;
>
> I don't see sei_data freed anywhere at the end of decoding?
Fixed in v2. Inclu
MISB ST 0604 and ST 2101 require user data unregistered SEI messages
(precision timestamps and sensor identifiers) to be included. That
currently isn't supported for libx265. This patch adds support
for user data unregistered SEI messages in accordance with
ISO/IEC 23008-2:2020 Section D.2.7
The d
10 Jul 2021, 09:42 by d...@lynne.ee:
> 10 Jul 2021, 03:10 by roman.bera...@prusa3d.cz:
>
>> Frame size of Opus stream was previously presumed here to be 960 samples
>> (20ms), however sizes of 120, 240, 480, 1920, and 2880 are also allowed.
>> It can also alter on a per-packet basis and even multi
10 Jul 2021, 02:12 by sunguangy...@gmail.com:
> After fixing AV_PKT_DATA_SKIP_SAMPLES for reading vorbis packets from ogg,
> the actual decoded samples become fewer. Three fate tests are failing:
>
> fate-vorbis-20:
> The samples in 6.ogg are not frame aligned. 6.pcm file was generated by
> ffmpeg
41 matches
Mail list logo
