---
libavutil/display.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/display.h b/libavutil/display.h
index 515adad795..d87bf68425 100644
--- a/libavutil/display.h
+++ b/libavutil/display.h
@@ -88,7 +88,7 @@
double av_display_rotation_get(const int32_t matrix[9]);
Zhao Zhili:
> ---
> libavutil/display.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/display.h b/libavutil/display.h
> index 515adad795..d87bf68425 100644
> --- a/libavutil/display.h
> +++ b/libavutil/display.h
> @@ -88,7 +88,7 @@
> double av_display_rotatio
Andreas Rheinhardt:
> Zhao Zhili:
>> ---
>> libavutil/display.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/display.h b/libavutil/display.h
>> index 515adad795..d87bf68425 100644
>> --- a/libavutil/display.h
>> +++ b/libavutil/display.h
>> @@ -88,7 +88,7 @
From: Niklas Haas
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.
Contains some annoying machinery to persist these values in between
frames, which is needed in theory even
From: Jan Ekström
Co-authored-by: Niklas Haas
---
fftools/ffprobe.c | 173 +-
1 file changed, 170 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0711e02922..75263cd3a9 100644
--- a/fftools/ffprobe.c
+++ b/fftoo
From: Niklas Haas
Signed-off-by: Niklas Haas
---
libavfilter/vf_showinfo.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 62c7833247..8a7efc15b7 100644
--- a/libavfilter/vf_showinfo.c
+++
From: Niklas Haas
Signed-off-by: Niklas Haas
---
doc/APIchanges| 3 +
libavutil/dovi_meta.c | 12
libavutil/dovi_meta.h | 132 ++
libavutil/frame.c | 1 +
libavutil/frame.h | 9 ++-
libavutil/version.h | 2 +-
6 files chang
From: Niklas Haas
To avoid the ref for this growing to a very large size when attaching
the parsed RPU side data. Since this sample does not have any dynamic
metadata, two frames will serve just as well as 100.
Signed-off-by: Niklas Haas
---
tests/fate/hevc.mak| 2 +-
tests/ref/fate/
From: Niklas Haas
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something
On 11 Dec 2021, at 23:17, Andreas Rheinhardt wrote:
Thilo Borgmann:
On 10 Dec 2021, at 17:46, Michael Niedermayer wrote:
On Fri, Dec 10, 2021 at 12:36:21PM +0100, Thilo Borgmann wrote:
On 10 Dec 2021, at 3:47, zhilizhao(赵志立) wrote:
On Dec 10, 2021, at 3:11 AM, Thilo Borgmann
wrote:
> yesterday, it happened for the 4th and 5th times that another developer
> called my patchset a “hack”.
Hope it wasn't me. If I did, I'm sorry, didn't wanted to imply bad code
or lack of skills, or anything: I was trying to understand if there's some
way to actually unblock your patchset. And th
Daniel Cantarín (12021-12-12):
> Howerver, *if* subtitle_pts is truly the last point against softworkz
> patchset, then it's very close to see the light, and that's exciting.
Far from it. I have pointed the core flaws with the design a few times,
but having been received with rudeness, I did not b
Should fix Coverity tickets #1473572 and #1473504.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/speedhq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 91ba80ebd3..743dacc6ce 100644
--- a/libavcodec/speedhq.c
+++ b/lib
(This is not a leak as long as av_free() completely frees blank
packets.)
Signed-off-by: Andreas Rheinhardt
---
libavformat/moflex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/moflex.c b/libavformat/moflex.c
index 234b0fb06e..67adebe5e0 100644
--- a/libavformat/moflex.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavformat/moflex.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavformat/moflex.c b/libavformat/moflex.c
index 67adebe5e0..1d342417f7 100644
--- a/libavformat/moflex.c
+++ b/libavformat/moflex.c
@@ -172,7 +172,7 @@ st
From: Niklas Haas
Oops. The previous version of this patch forgot to actually forward the
dovi configuration record to the DOVIContext.
---
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
bei
> Far from it. I have pointed the core flaws with the design a few times,
> but having been received with rudeness, I did not bother insisting. This
> patch series is nowhere near anything that can be accepted.
>
This quickly went from exciting to depressing. :(
I guess some recent-times archeol
Daniel Cantarín (12021-12-12):
> This quickly went from exciting to depressing. :(
I find this whole situation depressing too.
> I guess some recent-times archeology will also be needed in order to
> discuss this, as the patchset is 23 versions now and has 21 parts. I'll give
> it some time start
Hi,
On Sun, Dec 12, 2021 at 1:21 PM Nicolas George wrote:
> I have told Soft Works they were going at it the wrong way when they
> posted the very first patch
>
There is no one magic correct way to do it. People work on things
differently, and that's OK.
Now, if there's issues with his approac
Quoting Marton Balint (2021-12-10 01:04:57)
>
>
> On Thu, 9 Dec 2021, Anton Khirnov wrote:
>
> > Quoting Nicolas George (2021-12-09 11:31:54)
> >> Anton Khirnov (12021-12-09):
> >>> I disagree. Technical limitations that were overcome 10 years ago should
> >>> not guide new API design.
> >>
> >>
Ronald S. Bultje (12021-12-12):
> There is no one magic correct way to do it. People work on things
> differently, and that's OK.
There are wrong ways to do it.
> Now, if there's issues with his approach, that's fine.
There are many issues, I pointed them at the time and was rudely
ignored.
--
Anton Khirnov (12021-12-12):
> So what are you proposing? In my view, such higher level information
> should live at a higher level - e.g. in the side data. You can then
> have a filter that reads this side data and gets you the group you want.
So, what is the point of this new API if anything of
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft Works
> Sent: Sunday, December 12, 2021 7:16 AM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] Politics
Hi,
let me clarify a bit on the status and the motivation.
I have started this development,
On Sun, Dec 12, 2021 at 8:42 PM Nicolas George wrote:
> Ronald S. Bultje (12021-12-12):
> > There is no one magic correct way to do it. People work on things
> > differently, and that's OK.
>
> There are wrong ways to do it.
And there is only one path dictated by you.
>
> > Now, if there's is
Thilo Borgman (12021-12-12):
> +@item localtime_ms
> +Same as @code{localtime} but with millisecond precision.
> +It can accept an argument: a strftime() format string.
What happens if the format string is something like '%H:%M:%S%z'? My
guess it it prints 21:12:42+0100.1234 instead of 21:12:42.12
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul B
> Mahol
> Sent: Sunday, December 12, 2021 9:09 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Politics
>
> On Sun, Dec 12, 2021 at 8:42 PM Nicolas George wrote:
>
> > Ronald S. Bultje (1
On Sun, Dec 12, 2021 at 02:21:42AM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Daniel
> > Cantarín
> > Sent: Sunday, December 12, 2021 12:39 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v20 02/20] avutil/frame: Prep
On Sat, Dec 11, 2021 at 06:03:39PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Michael
> > Niedermayer
> > Sent: Saturday, December 11, 2021 6:21 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v20
On Wed, Nov 24, 2021 at 1:15 PM wrote:
> From: Mark Reid
>
> changes since v2:
> * fixed label
> changes since v1:
> * remove vex intruction on sse4 path
> * some load/pack marcos use less intructions
> * fixed some typos
>
> yuv2gbrp_full_X_4_512_c: 12757.6
> yuv2gbrp_full_X_4_512_sse2: 894
It would definitely have to be an option.
I tried lowering MAX_DELAYED_FRAMES myself. While it might work for live
video
streams, games streaming in your case, RTSP from CCTV cameras in mine, lower
MAX_DELAYED_FRAMES seems to cause a decoding stall in any video with
re-ordered
frames.
Thanks for
Only used there and only by the main thread.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg12dec.c | 8 +---
libavcodec/mpegvideo.c | 1 -
libavcodec/mpegvideo.h | 1 -
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index
ff_mpeg_update_thread_context() is only used by decoders.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 55399a7478..b5ff4cec69 100644
--- a/libavcodec/mpegvideo.c
+++ b/l
Mpeg1EncContext.droppable is only nonzero for the FLV decoder.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 3 +--
libavcodec/vc1dec.c| 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index b5ff4cec69..e2cdba8bb1 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index be47ccb8ed..46e56ca08e 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -770,8
Forgotten in c46eeae2a80dfe0046c15b542e8b9a2c78f19bf7.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavcodec/h263.h b/libavcodec/h263.h
index d6bef8318d..84a3a19517 100644
--- a/libavcodec/h263.h
+++ b/libavcodec/h263.h
@@ -8
Reduces the amount of allocations and frees.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 46 ++
libavcodec/mpegvideo.h | 8
2 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mp
Ping for patch 1-3.
> On Dec 3, 2021, at 1:06 PM, Zhao Zhili wrote:
>
> ---
> libavformat/movenc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 38ff90833a..634a829f28 100644
> --- a/libavformat/movenc.c
On 9/12/21 13:55, p...@sandflow.com wrote:
+
+#define FF_UUID_FORMAT\
+"urn:uuid:%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-" \
+"%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
+
+/**
+ * UUID as defined in IETF RFC 422
+ */
+typedef uint8_t
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
The IMF demuxer accepts as input an IMF CPL. The assets referenced by the
CPL can be
contained in multiple deliveries, each defined by an ASSETMAP file:
ffmpeg -assetmaps ,,... -i
If -asset
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
Tests for the IMF demuxer.
libavformat/Makefile| 1 +
libavformat/tests/imf.c | 525
2 files changed, 526 insertions(+)
create mode 100644 libavformat/tests/imf.c
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Xiang,
> > Haihao
> > Sent: Thursday, December 9, 2021 9:35 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec/vpp_qsv: Copy side data
> > from input to output frame
> >
> > On Tue, 2021-12
On Sun, Dec 12, 2021 at 7:58 PM Zane van Iperen wrote:
>
>
> On 9/12/21 13:55, p...@sandflow.com wrote:
>
> > +
> > +#define FF_UUID_FORMAT\
> > +"urn:uuid:%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-" \
> > +"%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02h
The SDK checks Data.V when using system memory for VP9 encoding. This
fixed the error below:
$ ffmpeg -qsv_device /dev/dri/renderD129 -f lavfi -i yuvtestsrc -c:v
vp9_qsv -f null -
[vp9_qsv @ 0x55b8387cbe90] Error during encoding: NULL pointer (-2)
Video encoding failed
---
libavcodec/qsvenc.c |
The SDK doesn't support VC1 encoding. In addition, both
MFX_PROFILE_VC1_SIMPLE and MFX_PROFILE_HEVC_MAIN are 1 in the SDK, HEVC
main profile is recognized as simple profile in the verbose output if
don't remove VC1 profiles.
$ ffmpeg -v verbose -qsv_device /dev/dri/renderD129 -f lavfi -i
yuvtestsr
The SDK defines HEVC, VP9 and AV1 profiles in the same values
e.g.
MFX_PROFILE_HEVC_MAIN =1,
MFX_PROFILE_VP9_0 =1,
MFX_PROFILE_AV1_MAIN =1,
To avoid potential errors when adding VP9, AV1 profiles later,
this patch defines profile array per codec.
---
libav
---
libavcodec/qsvenc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7dab8bab0f..a2a8a79189 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -76,6 +76,15 @@ static const struct profile_names hevc_profiles[] = {
#e
---
libavcodec/qsvenc.c | 80 +
1 file changed, 80 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index a2a8a79189..106438f227 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -343,6 +343,84 @@ static void dump_video_p
---
libavcodec/qsvenc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 106438f227..92a8b49fe3 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -421,6 +421,18 @@ static void dump_video_vp9_param(AVCodecContext *avctx,
> -Original Message-
> From: ffmpeg-devel On Behalf Of Xiang,
> Haihao
> Sent: Monday, December 13, 2021 6:55 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 2/2] avcodec/vpp_qsv: Copy side data
> from input to output frame
>
>
> > > -Original Message-
This series solves some outstanding bugs in the dshow device, implements
get_device_list so that `ffmpeg -sources dshow` works and adds logic to
select a video format with extended color information (color range,
space, etc) if exposed by the device.
This is a new version of part of the patch seri
list_options true would crash when both a video and an audio device were
specified as input. Crash would occur on line 784 because
ctx->device_unique_name[otherDevType] would be NULL
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
The dshow avdevice ignores timestamps for video frames provided by the
DirectShow device, instead using wallclock time, apparently because the
implementer of this code had a device that provided unreliable
timestamps. Me (and others) would like to use the device's timestamps.
The new use_video_devi
Signed-off-by: Diederick Niehorster
---
doc/indevs.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 5be647f70a..9d8020311a 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -625,6 +625,12 @@ Save the currently used video capture filter dev
No need to query twice, use value we've already unconditionally got.
Improve variable names
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow_pin.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/libavdevice/dshow_pin.c b/libavdevice/dsh
GetTime may return an error indication that the sample has not
timestamps, or may return a NULL start time. In those cases, fall back
to graph time.
Better debug message in case sample dropped: could now be audio or
video frame
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow_pin.c | 19
avdevice/dshow is a realtime device and as such does not support
seeking. Therefore, its demuxer format should define the
AVFMT_NOBINSEARCH, AVFMT_NOGENSEARCH and AVFMT_NO_BYTE_SEEK flags.
With these flags set, attempting to seek (with, e.g.,
avformat_seek_file()) correctly yields -1 (operation not
Needed to enable programmatic discovery of DirectShow devices
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 80 +
1 file changed, 73 insertions(+), 7 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 0ef3b3d13e.
the list_devices option of dshow didn't indicate whether a specific
device provides audio or video output. This patch iterates through all
media formats of all pins exposed by the device to see what types it
provides for capture, and prints this to the console for each device.
Importantly, this now
An avdevice, regardless of whether its category says its an audio or
video device, may provide access to devices providing different media
types, or even single devices providing multiple media types. Also, some
devices may provide no media types. dshow is an example encompassing all
of these cases
The list returned by get_device_list now contains info about what media
type(s), if any, can be provided by each device.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index f25537db
fftools now print info about what media type(s), if any, are provided by
sink and source avdevices.
Signed-off-by: Diederick Niehorster
---
fftools/cmdutils.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmd
Enabled discovering a DirectShow device's color range, space, primaries,
transfer characteristics and chroma location, if the device exposes that
information. Sets them in the stream's codecpars.
Co-authored-by: Valerii Zapodovnikov
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c |
Some DirectShow devices (Logitech C920 webcam) expose each DirectShow
format they support twice, once without and once with extended color
information. During format selection, both match, this patch ensures
that the format with extended color information is selected if it is
available, else it fal
64 matches
Mail list logo
