> Ok, dfov for width != height in (d)fisheye have been fixed.
Great, thanks :)
> The aspect ratio one breaks handling in case input is in equirectangular
> format.
That's not obvious to me - can you provide an example filtergraph
where it breaks, and explain why it's wrong?
> Dunno what to do
On Sun, 2021-04-11 at 23:24 +0800, Zhong Li wrote:
> Fei Wang 于2021年3月31日周三 上午10:11写道：
> >
> > Async depth will allow qsv filter cache few frames, and avoid force
> > switch and end filter task frame by frame. This change will improve
> > performance for some multi-task case, for example 1:N
From: Mark Reid
This also seems to prevent the audio format changing after format has been
identified.
This can happen in ffplay and might have something to do with sdl configuring
the audio devices.
---
libavdevice/avfoundation.m | 123 -
1 file changed,
From: Mark Reid
This fixes audio issues I've had with some capture devices. The audio
gets really choppy and stops working. This seems to be because avf_read_packet
stops outputting the audio frames because a video frame happens to be available
first.
It base on the approach used in a patch
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Pedro Arthur
> Sent: 2021年4月12日 5:12
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH V7 4/6] lavu: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Em dom., 11 de abr. de 2021 às 14:53,
On Mon, Apr 12, 2021 at 1:10 AM Jan Ekström wrote:
> For context, just checked some random sample I had on hand:
>
> ARIB caption info: DMF: 0xa, reserved: 0x3, timing: 0x1
>
> So "both caption streams are selectable/showable when both received
> and playing back a recording" (0b1010), reserved
This patch will fix following command:
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.264 \
-vf 'scale_vaapi=w=7680:h=4096' -c:v vp9_vaapi output.ivf
Max width of a vp9 tile is 4096. If the source frame > 4096, we need split to
multiple tiles.
Signed-off-by: Zhang yuankun
---
Em dom., 11 de abr. de 2021 às 14:53, Nicolas George escreveu:
>
> Anton Khirnov (12021-04-11):
> > We are a generic multimedia framework. "the field" for us is multimedia
> > in general, so we should use names meaningful in general multimedia
> > context.
> > I mostly agree with Lynne, "bounding
Signed-off-by: Nachiket Tarate
---
libavformat/hls.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 51b8da7c99..3c9a5bca90 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2051,23
Apple HTTP Live Streaming Sample Encryption:
https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption
Signed-off-by: Nachiket Tarate
---
libavformat/Makefile| 2 +-
libavformat/hls.c | 123 -
https://www.iso.org/standard/68042.html
Signed-off-by: Nachiket Tarate
---
libavformat/isom.h | 1 +
libavformat/mov.c | 86 ++
2 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index
These will be used by HLS demuxer in case of sample decryption.
Signed-off-by: Nachiket Tarate
---
libavcodec/adts_header.c | 1 +
libavcodec/adts_header.h | 14 ++
libavcodec/adts_parser.c | 28
3 files changed, 43 insertions(+)
diff --git
On 4/10/2021 10:21 PM, Andreas Rheinhardt wrote:
James Almer:
On 4/10/2021 9:43 PM, Andreas Rheinhardt wrote:
When writing the trailer, the WebP muxer unconditionally seeks back
to the front to update some elements. Yet this doesn't work if
the seek failed, so check for this.
(This has been
Am So., 11. Apr. 2021 um 19:53 Uhr schrieb Bernd Kuhls
:
>
> uClibc does not provide sys/auxv.h:
Unfortunately, this is also true for older glibc versions,
see ticket #9138.
A check in configure is necessary instead.
Carl Eugen
___
ffmpeg-devel
Anton Khirnov (12021-04-11):
> We are a generic multimedia framework. "the field" for us is multimedia
> in general, so we should use names meaningful in general multimedia
> context.
> I mostly agree with Lynne, "bounding box" is confusing and misleading
> when this structure is built around
uClibc does not provide sys/auxv.h:
libavutil/mips/cpu.c:26:10: fatal error: sys/auxv.h: No such file or directory
and not getauxval:
libavutil/mips/cpu.c: In function ‘cpucfg_available’:
libavutil/mips/cpu.c:37:12: error: implicit declaration of function ‘getauxval’
On Sat, Apr 10, 2021 at 07:38:36PM -0300, James Almer wrote:
> On 4/10/2021 7:24 PM, Michael Niedermayer wrote:
> > Fixes: left shift of negative value -224
> > Fixes:
> > 32144/clusterfuzz-testcase-minimized-ffmpeg_dem_MVI_fuzzer-4971479323246592
> >
> > Found-by: continuous fuzzing process
>
On 4/11/2021 2:15 PM, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 18:50 Uhr schrieb James Almer :
On 4/11/2021 1:30 PM, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 04:13 Uhr schrieb James Almer :
The libwebp_animencoder returns a single packet with the entire animated
stream, as
Am So., 11. Apr. 2021 um 18:50 Uhr schrieb James Almer :
>
> On 4/11/2021 1:30 PM, Carl Eugen Hoyos wrote:
> > Am So., 11. Apr. 2021 um 04:13 Uhr schrieb James Almer :
> >>
> >> The libwebp_animencoder returns a single packet with the entire animated
> >> stream, as that's what the external
On 4/11/2021 1:30 PM, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 04:13 Uhr schrieb James Almer :
The libwebp_animencoder returns a single packet with the entire animated
stream, as that's what the external library produces. As such, only ensure the
stream was produced by said encoder (or
Am So., 11. Apr. 2021 um 04:13 Uhr schrieb James Almer :
>
> The libwebp_animencoder returns a single packet with the entire animated
> stream, as that's what the external library produces. As such, only ensure the
> stream was produced by said encoder (or propagated by a demuxer, once support
>
Am So., 11. Apr. 2021 um 17:25 Uhr schrieb Paul B Mahol :
>
> I think this is invalid.
> Give explanation why you think your approach is correct one.
>
> On Sun, Apr 11, 2021 at 4:54 PM Zhong Li wrote:
>
> > Signed-off-by: Zhong Li
> > ---
> > libavfilter/vf_cas.c | 2 +-
> > 1 file changed, 1
Fei Wang 于2021年3月31日周三 上午10:11写道：
>
> Async depth will allow qsv filter cache few frames, and avoid force
> switch and end filter task frame by frame. This change will improve
> performance for some multi-task case, for example 1:N transcode(
> decode + vpp + encode) with all QSV plugins.
>
>
On Sun, Apr 11, 2021 at 5:51 PM Jan Ekström wrote:
>
> On Sun, Apr 11, 2021 at 4:58 PM Jan Ekström wrote:
> >
> > On Sun, Apr 11, 2021 at 4:25 PM magic xqq wrote:
> > >
> > > I have already tried to use st->stream_identifier directly in mpegtsenc.c
> > > while handling arib_caption stream in
On Sun, Apr 11, 2021 at 6:17 PM zheng qian wrote:
>
> Consider the remuxed stream could be handled by other clients rather
> than FFmpeg,
> e.g. I'm working on HTML5 playback for ISDB television with ARIB
> captions through
> mpegts.js + b24.js/aribb24.js. Other ISDB TV clients may also have
>
I think this is invalid.
Give explanation why you think your approach is correct one.
On Sun, Apr 11, 2021 at 4:54 PM Zhong Li wrote:
> Signed-off-by: Zhong Li
> ---
> libavfilter/vf_cas.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_cas.c
Consider the remuxed stream could be handled by other clients rather
than FFmpeg,
e.g. I'm working on HTML5 playback for ISDB television with ARIB
captions through
mpegts.js + b24.js/aribb24.js. Other ISDB TV clients may also have
possibilities to
check these fields, probably.
It will become more
Signed-off-by: Zhong Li
---
libavfilter/vf_cas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_cas.c b/libavfilter/vf_cas.c
index 7c32ed5f9b..b44a100421 100644
--- a/libavfilter/vf_cas.c
+++ b/libavfilter/vf_cas.c
@@ -65,7 +65,7 @@ static int
On Sun, Apr 11, 2021 at 4:58 PM Jan Ekström wrote:
>
> On Sun, Apr 11, 2021 at 4:25 PM magic xqq wrote:
> >
> > I have already tried to use st->stream_identifier directly in mpegtsenc.c
> > while handling arib_caption stream in mpegts_write_pmt() function.
> >
> > But in mpegtsenc.c,
On Sun, Apr 11, 2021 at 4:25 PM magic xqq wrote:
>
> I have already tried to use st->stream_identifier directly in mpegtsenc.c
> while handling arib_caption stream in mpegts_write_pmt() function.
>
> But in mpegtsenc.c, st->stream_identifier always provides
> an incorrect value of 0, which should
This patch fixes the detection score for spdif (IEC61937).
Signed-off-by: Denis Shulyaka
---
libavformat/spdifdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/spdifdec.c b/libavformat/spdifdec.c
index 1808fa9d65..05c155f49c 100644
---
The only packet produced by this encoder contains the entire animated stream,
so set its pts to the first frame encoded.
Signed-off-by: James Almer
---
Now setting pts to the value of the first frame as requested.
libavcodec/libwebpenc_animencoder.c | 9 +
1 file changed, 5
On 4/11/2021 6:56 AM, Anton Khirnov wrote:
Quoting James Almer (2021-04-10 23:00:20)
Signed-off-by: James Almer
---
libavcodec/h264dec.c | 5 +++--
tests/ref/fate/mov-zombie | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264dec.c
I have already tried to use st->stream_identifier directly in mpegtsenc.c
while handling arib_caption stream in mpegts_write_pmt() function.
But in mpegtsenc.c, st->stream_identifier always provides
an incorrect value of 0, which should be 0x30 for arib_caption A profile.
st->stream_identifier
On 2021-04-11 17:11, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-04-11 13:12:47)
On 2021-04-11 16:30, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-04-11 12:52:18)
On 2021-04-11 15:27, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
ffmpeg | branch:
Quoting Gyan Doshi (2021-04-11 13:12:47)
>
>
> On 2021-04-11 16:30, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2021-04-11 12:52:18)
> >>
> >> On 2021-04-11 15:27, Carl Eugen Hoyos wrote:
> >>> Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
> ffmpeg | branch: master | Gyan Doshi
On Sun, 11 Apr 2021, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-04-11 12:52:18)
On 2021-04-11 15:27, Carl Eugen Hoyos wrote:
> Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
>> ffmpeg | branch: master | Gyan Doshi | Sat Apr 10
16:35:53 2021 +0530|
On 2021-04-11 16:16, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 07:28 Uhr schrieb Gyan Doshi :
---
libavformat/rawenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index caec297f4a..0802d9a831 100644
--- a/libavformat/rawenc.c
+++
On 2021-04-11 16:30, Anton Khirnov wrote:
Quoting Gyan Doshi (2021-04-11 12:52:18)
On 2021-04-11 15:27, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
ffmpeg | branch: master | Gyan Doshi | Sat Apr 10 16:35:53
2021 +0530|
On Sun, Apr 11, 2021 at 1:16 PM Anton Khirnov wrote:
>
> Quoting Jan Ekström (2021-04-07 20:25:03)
> > Apparently for various image sequences libavformat/utils.c can
> > calculate rather fancy r_frame_rate values, such as `186/1921`,
> > and since ffmpeg.c utilizes r_frame_rate for the filter
Quoting Gyan Doshi (2021-04-11 12:52:18)
>
>
> On 2021-04-11 15:27, Carl Eugen Hoyos wrote:
> > Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
> >> ffmpeg | branch: master | Gyan Doshi | Sat Apr 10
> >> 16:35:53 2021 +0530| [47b8871ca6f9da4c0467466a43d204dec7fcbd4a] |
> >> committer:
Quoting Pedro Arthur (2021-04-09 16:35:52)
> +1
>
> I think it is wise to use the name which is widely used in the field.
We are a generic multimedia framework. "the field" for us is multimedia
in general, so we should use names meaningful in general multimedia
context.
I mostly agree with
On 2021-04-11 15:27, Carl Eugen Hoyos wrote:
Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
ffmpeg | branch: master | Gyan Doshi | Sat Apr 10 16:35:53
2021 +0530| [47b8871ca6f9da4c0467466a43d204dec7fcbd4a] | committer: Gyan Doshi
doc/muxers: add entries for raw muxers
Is this
Am So., 11. Apr. 2021 um 07:28 Uhr schrieb Gyan Doshi :
>
> ---
> libavformat/rawenc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
> index caec297f4a..0802d9a831 100644
> --- a/libavformat/rawenc.c
> +++ b/libavformat/rawenc.c
> @@ -433,6
On Sat, 10 Apr 2021, zheng qian wrote:
Changes since v1:
If desc_len < 3, break the switch statement instead of return
AVERROR_INVALIDDATA
to make it more robust.
For arib_caption, data_component_descriptor should contains at least 3 bytes:
data_component_id: uint16,
Hi Carl,
Thanks for the review.
сб, 10 апр. 2021 г. в 18:05, Carl Eugen Hoyos :
> Please use "&" instead of "%".
>
Fixed
Please remove this line.
>
Fixed
See above.
>
Fixed
Please remove this line or the default branch above.
>
Fixed. It was there as a safety feature in case someone
Am So., 11. Apr. 2021 um 08:41 Uhr schrieb Gyan Doshi :
>
> ffmpeg | branch: master | Gyan Doshi | Sat Apr 10 16:35:53
> 2021 +0530| [47b8871ca6f9da4c0467466a43d204dec7fcbd4a] | committer: Gyan Doshi
>
> doc/muxers: add entries for raw muxers
Is this really an improvement of our documentation?
Quoting Jan Ekström (2021-04-07 20:25:03)
> Apparently for various image sequences libavformat/utils.c can
> calculate rather fancy r_frame_rate values, such as `186/1921`,
> and since ffmpeg.c utilizes r_frame_rate for the filter chain
> time base, this can quite deteriorate the output frame
This patch adds support to decode IEC61937_EAC3 (aka dolby digital plus).
Signed-off-by: Denis Shulyaka
---
libavformat/spdifdec.c | 43 ++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavformat/spdifdec.c b/libavformat/spdifdec.c
Quoting zsugabubus (2021-04-10 03:54:12)
> On Sun, Mar 28, 2021 at 09:50:32PM +0100, Derek Buitenhuis wrote:
> > On 28/03/2021 21:05, Carl Eugen Hoyos wrote:
> > > The patch clearly mentions that it is a "rework".
> > > If the maintainer likes it, it would be nice if it can be simplified but
> > >
Quoting James Almer (2021-04-10 23:00:20)
> Signed-off-by: James Almer
> ---
> libavcodec/h264dec.c | 5 +++--
> tests/ref/fate/mov-zombie | 2 +-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 47b9abbc5c..f44c8c8175
Quoting James Almer (2021-04-11 04:12:37)
> The only packet produced by this encoder contains the entire animated stream,
> so its pts is 0.
Shouldn't it rather save the first frame's pts? It does not always have
to be 0.
--
Anton Khirnov
___
Ok, dfov for width != height in (d)fisheye have been fixed.
Dunno what to do with rest of patches.
The aspect ratio one breaks handling in case input is in equirectangular
format.
On Sun, Apr 11, 2021 at 6:48 AM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> > AFAIK, the h/v/d
53 matches
Mail list logo
