> 7 Dec 2021, 10:05 by wenbin.c...@intel.com:
>
> > When vulkan image exports to drm, the tilling need to be
> > VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT. Now add code to
> create vulkan
> > image using this format.
> >
> > Now the following command line works:
> >
> > ffmpeg -hwaccel vaapi -hwacce
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Wenbin Chen
> > Sent: Friday, December 10, 2021 3:22 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Wenbin Chen
> > Subject: [FFmpeg-devel] [PATCH] libavfilter/vf_overlay_qsv: Use format of
> > first input to set output format for o
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Wenbin Chen
> > Sent: Friday, December 10, 2021 3:22 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Wenbin Chen
> > Subject: [FFmpeg-devel] [PATCH] libavfilter/vf_overlay_qsv: Use format of
> > first input to set output format for o
Quoting Andreas Rheinhardt (2021-12-09 14:08:01)
> From: Ho Ming Shun
>
> MMAL is an fundamentally an asynchronous decoder, which was a bad fit
> for the legacy dataflow API. Often multiple packets are enqueued before
> a flood of frames are returned from MMAL.
>
> The previous lockstep dataflow
Quoting Andreas Rheinhardt (2021-12-09 14:08:04)
> ffmal_add_packet() basically duplicated the logic in
> av_packet_make_refcounted() with the added twist that it always
> created a reference even if one is already available.
> This commit stops doing this.
>
> Signed-off-by: Andreas Rheinhardt
>
Test for buf[0] rather than data[0] (which is broken for some hwaccel
formats).
---
libavcodec/encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index dd25cf999b..5575cf23db 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encod
It is currently set in encode_simple_internal(), which is only called
for encoders using the "simple" encoding API.
---
libavcodec/encode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 5575cf23db..618be0573d 100644
--- a
On 12/13/2021 7:47 AM, Anton Khirnov wrote:
Test for buf[0] rather than data[0] (which is broken for some hwaccel
formats).
---
libavcodec/encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index dd25cf999b..5575cf23db 100644
Ping for patch v4: fftools/opts: Avoid crash when opts could not be allocated.
> 2021年12月8日 上午10:35，Yu Yang 写道：
>
> If 'opts' could not be allocated, exiting the program to avoid crash when
> release it.
> Before setup_find_stream_info_opts(), checking 'orig_nb_streams' is > 0.
>
> Reported-
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-12-09 14:08:01)
>> From: Ho Ming Shun
>>
>> MMAL is an fundamentally an asynchronous decoder, which was a bad fit
>> for the legacy dataflow API. Often multiple packets are enqueued before
>> a flood of frames are returned from MMAL.
>>
>> The prev
Yu Yang:
> If 'opts' could not be allocated, exiting the program to avoid crash when
> release it.
> Before setup_find_stream_info_opts(), checking 'orig_nb_streams' is > 0.
>
> Reported-by: TOTE Robot
> Signed-off-by: Yu Yang
> ---
> fftools/cmdutils.c | 4 +---
> fftools/cmdutils.h | 4
This is just a rebased patch (updated fate results).
I have not received any comment since my initial post.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211123172829.1674-1-nicolas.gaullier@cji.paris/
Thank you
Nicolas
Nicolas Gaullier (1):
avformat/concatdec: copy side data
libavforma
Fixes mpeg2video stream copy to mpeg muxer.
Note: this is a following of 1ec86be79b11.
Signed-off-by: Nicolas Gaullier
---
libavformat/concatdec.c | 11 +++
tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-extended-lav
> On Dec 12, 2021, at 7:19 PM, Andreas Rheinhardt
> wrote:
>
> 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
>>
Quoting James Almer (2021-12-13 12:40:49)
> On 12/13/2021 7:47 AM, Anton Khirnov wrote:
> > Test for buf[0] rather than data[0] (which is broken for some hwaccel
> > formats).
> > ---
> > libavcodec/encode.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcod
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index d33cf9477d..4adb95eca7 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@
On 12/13/2021 10:30 AM, Anton Khirnov wrote:
Quoting James Almer (2021-12-13 12:40:49)
On 12/13/2021 7:47 AM, Anton Khirnov wrote:
Test for buf[0] rather than data[0] (which is broken for some hwaccel
formats).
---
libavcodec/encode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 4adb95eca7..8865e38293 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 8865e38293..128d1a327c 100644
--- a/libavcodec/mpegvideo_enc.c
Use it to simplify check_init_output_file(). Will allow further
simplifications in the following commits.
---
fftools/ffmpeg.c | 10 +-
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_opt.c | 1 +
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/f
Stop accessing OutputFile.ctx. This will be useful in the following
commits, where it will become hidden.
---
fftools/ffmpeg_opt.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 9c820ab73f..f638edace9 100644
--
Stop calling avio_size()/avio_tell(), which are potentially heavy
operations and may interfere with muxer operation. Use the recently
introduced bytes_written field instead.
---
fftools/ffmpeg.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftoo
It is already set in open_output_file().
---
fftools/ffmpeg.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b77531cb7f..fb017a1e37 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2947,8 +2947,6 @@ static int check_init_output_file(OutputFil
---
fftools/ffmpeg.c | 16 +++-
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_mux.c | 21 +
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index a00fe58063..1fb10869b4 100644
--- a/fftools/ffmpeg.c
+++ b/fftool
Allows making the variable local to ffmpeg_mux.
---
fftools/ffmpeg.c | 9 +
fftools/ffmpeg.h | 1 -
fftools/ffmpeg_mux.c | 5 +
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 3ed1201fda..f76e5df8d2 100644
--- a/fftools/f
This is a first step towards making muxers more independent from the
rest of the code.
---
fftools/Makefile | 11 +-
fftools/ffmpeg.c | 273 ++--
fftools/ffmpeg.h | 10 ++
fftools/ffmpeg_mux.c | 293 +++
4 fi
---
fftools/ffmpeg.c | 14 ++
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_mux.c | 17 +
3 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1fb10869b4..86f7b11654 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmp
Allows accessing it without going through the muxer context. This will
be useful in the following commits, where the muxer context will be
hidden.
---
fftools/ffmpeg.c | 18 ++
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_opt.c | 1 +
3 files changed, 13 insertions(+), 8 delet
Move header_written into it, which is not (and should not be) used by
any code outside of ffmpeg_mux.
In the future this context will contain more muxer-private state that
should not be visible to other code.
---
fftools/ffmpeg.h | 6 --
fftools/ffmpeg_mux.c | 26 ++--
Move the file size checking code to ffmpeg_mux. Stop calling
avio_tell(), which is a potentially heavy operation - use the recently
introduced bytes_written instead.
---
fftools/ffmpeg.c | 4 +---
fftools/ffmpeg.h | 4 ++--
fftools/ffmpeg_mux.c | 14 +-
fftools/ffmpeg_opt.c |
All other logging goes to NULL context.
---
fftools/ffmpeg.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d69e4119ef..afd442ff4e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2954,7 +2954,6 @@ static void init_encoder_t
It stores pointers to AVPacket, not AVPackets themselves.
---
fftools/ffmpeg_mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 5a12a1c899..9281e6c94c 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -411,7 +41
---
fftools/ffmpeg_mux.c | 72 +++-
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 9281e6c94c..d4b674c9e2 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -63,12 +63,50 @@ stat
Figure out earlier whether the output stream/file should be bitexact and
store this information in a flag in OutputFile/OutputStream.
Stop accessing the muxer in set_encoder_id(), which will become
forbidden in future commits.
---
fftools/ffmpeg.c | 21 +
fftools/ffmpeg.h
It is private to the muxer, no reason to access it from outside.
---
fftools/ffmpeg.h | 3 +--
fftools/ffmpeg_mux.c | 9 ++---
fftools/ffmpeg_opt.c | 12 ++--
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 76c8dfa4c8..69
There is no reason to delay this.
---
fftools/ffmpeg.c | 11 ---
fftools/ffmpeg_mux.c | 7 +++
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f76e5df8d2..c01ff2fa92 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -
---
fftools/ffmpeg.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index bbedf867b4..538601e440 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1064,6 +1064,11 @@ static void do_video_out(OutputFile *of,
}
Avoid accessing the muxer context directly, as this will become
forbidden in future commits.
---
fftools/ffmpeg.c | 15 +--
fftools/ffmpeg.h | 2 ++
fftools/ffmpeg_mux.c | 7 +++
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ff
It is currently called from two places:
- output_packet() in ffmpeg.c, which submits the newly available output
packet to the muxer
- from of_check_init() in ffmpeg_mux.c after the header has been
written, to flush the muxing queue
Some packets will thus be processed by this function twice, so
The muxing queue currently lives in OutputStream, which is a very large
struct storing the state for both encoding and muxing. The muxing queue
is only used by the code in ffmpeg_mux, so it makes sense to restrict it
to that file.
This makes the first step towards reducing the scope of OutputStrea
It features in limiting the number of output frames (-frames option) and
currently can be incremented from two places:
- for video encoding (not streamcopy), in do_video_out() after each
successful avcodec_send_frame() call
- for all other cases, in of_submit_packet()
Not only is this inconsiste
Stop accessing muxer internals from outside of ffmpeg_mux.
---
fftools/ffmpeg.c | 6 +-
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_mux.c | 6 ++
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index c01ff2fa92..b7f26fe288 100644
--- a/
The current code postpones closing the files until after printing the
final report, which accesses the output file size. Deal with this by
storing the final file size before closing the file.
---
fftools/ffmpeg.c | 13 -
fftools/ffmpeg_mux.c | 15 ++-
2 files changed, 1
On Thu, Nov 25, 2021 at 06:19:32PM +0100, Michael Niedermayer wrote:
> Hi all
>
> just wanted to remind everyone of the plan (suggested by jb) to make the
> 5.0 release in december
> i dont know if that will work out but please avoid introducing
> risky changes until the release branch splits off
This is the first patch of a series of 3 that cleanup and enhance the
avfoundation implementation for libavdevice.
This patch:
* Implements support for AudioConverter
* Switches to AudioConverter's API to convert unsupported PCM
formats (non-interleaved, non-packed) to supported formats
* Minimiz
This is the second patch of a series of 3 that cleanup and enhance the
avfoundation implementation for libavdevice.
This patch fixes the concurrency model. Avfoundation runs its own producing
thread
to send produced frames and ffmpeg runs its own thread to consume them.
The existing implementati
This is the third patch of a series of 3 that cleanup and enhance the
avfoundation implementation for libavdevice.
This patch adds a digest to avfoundation devices, when available. This
is needed because device index can change while the machine is running when
devices are plugged or unplugged and
the v23_plus set still fails:
./ffmpeg -ss 20 -i dvbsubtest.ts -filter_complex
"[0:v][0:s]overlay[v]" -map '[v]' -map 0:a -acodec copy -vcodec mpeg4
-t 5 -bitexact /tmp/file.avi
Input #0, mpegts, from 'dvbsubtest.ts':
Duration: 00:00:34.64, start: 79677.098467, bitrate: 4842 kb/s
Program
Hello Softworkz
On Sun, 12 Dec 2021, at 07:15, Soft Works wrote:
> yesterday, it happened for the 4th and 5th times that another developer
> called my patchset a “hack”.
>
> In none of the 4 cases, anybody was able to give even a single reason.
> My assessment is that when a skilled developer is u
On Sun, 12 Dec 2021, at 20:42, Nicolas George wrote:
>> 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.
Would you care to share a link to that email?
It's been difficult to follow to be honest, with the numer
On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
> previous unused suggestions where:
> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois,
> Viterbi, Darwin
I'd love a "Lorentz" release :)
--
Jean-Baptiste Kempf - President
+33 672 704 734
___
On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
> If you know of any major issues which need to be done before the release do
> them
> now. If you know of any issues which are release-blocking list them in a reply
> here please.
Maybe the audio channel layout would be nice to settle bef
On 13 Dec 2021, at 17:40, Romain Beauxis wrote:
This is the third patch of a series of 3 that cleanup and enhance the
avfoundation implementation for libavdevice.
This patch adds a digest to avfoundation devices, when available. This
is needed because device index can change while the machine i
> -Original Message-
> From: Jean-Baptiste Kempf
> Sent: Monday, December 13, 2021 7:01 PM
> To: FFmpeg development discussions and patches
> Cc: Soft Works
> Subject: Re: [FFmpeg-devel] Politics
>
> Hello Softworkz
>
> On Sun, 12 Dec 2021, at 07:15, Soft Works wrote:
> > yesterday,
> On Dec 13, 2021, at 12:25 PM, Marvin Scholz wrote:
>
> On 13 Dec 2021, at 17:40, Romain Beauxis wrote:
>
>> This is the third patch of a series of 3 that cleanup and enhance the
>> avfoundation implementation for libavdevice.
>>
>> This patch adds a digest to avfoundation devices, when ava
On 13 Dec 2021, at 17:39, Romain Beauxis wrote:
This is the second patch of a series of 3 that cleanup and enhance the
avfoundation implementation for libavdevice.
This patch fixes the concurrency model. Avfoundation runs its own
producing thread
to send produced frames and ffmpeg runs its
On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
If you know of any major issues which need to be done before the release do them
now. If you know of any issues which are release-blocking list them in a reply
here please.
Maybe the
On Sun, 2021-12-12 at 06:15 +, Soft Works wrote:
> Good Morning,
>
> yesterday, it happened for the 4th and 5th times that another
> developer
> called my patchset a “hack”.
This might be partially a language problem.
Ffrom familiarity with the usage in several primarily-English
development
13 Dec 2021, 20:04 by jamr...@gmail.com:
>
>
> On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
>
>> On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
>>
>>> If you know of any major issues which need to be done before the release do
>>> them
>>> now. If you know of any issues which are
Quoting James Almer (2021-12-13 20:04:34)
>
>
> On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
> > On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
> >> If you know of any major issues which need to be done before the release
> >> do them
> >> now. If you know of any issues which are
13 Dec 2021, 19:26 by softwo...@hotmail.com:
>
>
>> -Original Message-
>> From: Jean-Baptiste Kempf
>> Sent: Monday, December 13, 2021 7:01 PM
>> To: FFmpeg development discussions and patches
>> Cc: Soft Works
>> Subject: Re: [FFmpeg-devel] Politics
>>
>> Hello Softworkz
>>
>> On Sun,
On 12/13/2021 4:47 PM, Anton Khirnov wrote:
Quoting James Almer (2021-12-13 20:04:34)
On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
If you know of any major issues which need to be done before the release do them
now. If you kn
On Mon, 2021-12-13 at 14:32 -0500, Calvin Walton wrote:
> like, for example, I rewrote the "fps" filter to use the activate
> callback to handle filling in large timestamp gaps a frame at a time
> rather than buffering a ton of frames all at once and causing OOM. But
> that only fixed the situation
> -Original Message-
> From: ffmpeg-devel On Behalf Of Calvin
> Walton
> Sent: Monday, December 13, 2021 8:32 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Politics
>
> On Sun, 2021-12-12 at 06:15 +, Soft Works wrote:
> > Good Morning,
> >
> > ye
Quoting James Almer (2021-12-13 20:51:05)
>
>
> On 12/13/2021 4:47 PM, Anton Khirnov wrote:
> > Quoting James Almer (2021-12-13 20:04:34)
> >>
> >>
> >> On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
> >>> On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
> If you know of any majo
On 12/13/2021 5:01 PM, Anton Khirnov wrote:
Quoting James Almer (2021-12-13 20:51:05)
On 12/13/2021 4:47 PM, Anton Khirnov wrote:
Quoting James Almer (2021-12-13 20:04:34)
On 12/13/2021 3:05 PM, Jean-Baptiste Kempf wrote:
On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
If yo
Quoting James Almer (2021-12-13 21:05:30)
>
>
> On 12/13/2021 5:01 PM, Anton Khirnov wrote:
> > Quoting James Almer (2021-12-13 20:51:05)
> >>
> >>
> >> On 12/13/2021 4:47 PM, Anton Khirnov wrote:
> >>> Quoting James Almer (2021-12-13 20:04:34)
>
>
> On 12/13/2021 3:05 PM, Jean-Bap
> On Dec 13, 2021, at 12:56 PM, Marvin Scholz wrote:
>
>
>
> On 13 Dec 2021, at 17:39, Romain Beauxis wrote:
>
>> This is the second patch of a series of 3 that cleanup and enhance the
>> avfoundation implementation for libavdevice.
>>
>> This patch fixes the concurrency model. Avfoundation
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: Monday, December 13, 2021 8:49 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Politics
>
> 13 Dec 2021, 19:26 by softwo...@hotmail.com:
>
> >
> >
> >> -Original Message-
> >
If ca_file was set, setting tls_verify=0 would not actually disable
verification.
From 2677353187c4e3c20b50a3f9aab53130e3ead99b Mon Sep 17 00:00:00 2001
From: sfan5
Date: Mon, 13 Dec 2021 21:35:40 +0100
Subject: [PATCH] lavf/tls_mbedtls: fix handling of tls_verify=0
If ca_file was set, setting t
This value is later passed to MediaCodec and checked at decoder init.
Notably decoding of 10-bit streams before this commit would "work" without
returning errors but only return garbage output (on most Android devices).
From 304d1bd55e72212c1e907922547d40da240b Mon Sep 17 00:00:00 2001
From: s
Lynne (12021-12-13):
> Consensus was reached. A 16-bit opaque identifier, which users can
> simply use as an index into their own frame opaque structure, if they
> want, and a 16-bit channel identifier, which would result in a 32-bit
> structure, which is pretty acceptable.
No, consensus was not r
James Almer (12021-12-13):
> I wholly agree. Hence me suggesting using AVBPrint in the meantime. It
> certainly beats a uint8_t* + size_t combination, and it's trivial to do.
There are a few misunderstanding here.
For the per-channel label, I insist on at least a string, but a plain C
string, eve
On 13 Dec 2021, at 21:29, Romain Beauxis wrote:
On Dec 13, 2021, at 12:56 PM, Marvin Scholz
wrote:
On 13 Dec 2021, at 17:39, Romain Beauxis wrote:
This is the second patch of a series of 3 that cleanup and enhance
the
avfoundation implementation for libavdevice.
This patch fixes the c
Hi Michael,
On Mon, Dec 13, 2021 at 4:26 PM Michael Niedermayer
wrote:
>
> If you know of any major issues which need to be done before the release do
> them
> now. If you know of any issues which are release-blocking list them in a reply
> here please.
Not major, but
https://ffmpeg.org/piperm
On Mon, 13 Dec 2021, Jean-Baptiste Kempf wrote:
On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
If you know of any major issues which need to be done before the release do them
now. If you know of any issues which are release-blocking list them in a reply
here please.
Maybe the a
On Mon, Dec 13, 2021 at 8:48 PM Anton Khirnov wrote:
>
> > - The request to wait for a new string handling API to land and be used
> > for the relevant functions in this set. This has not seen opposition
> > from anyone yet, but it's not very feasible if said new API is not yet
> > in a state beyo
On Sun, 12 Dec 2021, Anton Khirnov wrote:
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 ne
On 12/12/2021 5:00 PM, Nicolas George wrote:
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, wha
I need the ability to derive the poster time found in the mvhd, so I can
use that value to create a thumbnail from ffmpeg. More details can be
found here
https://www.mail-archive.com/ffmpeg-user@ffmpeg.org/msg30003.html.
Signed-off-by: Bryce Chester Newman
mailto:bryce.new...@gettyimages.com>>
--
James Almer (12021-12-13):
> To achieve this you don't need the same AVChannel value to appear several
> times in the same layout. You have INT_MAX values available, so just assign
> one to each of these you mentioned. No need for an abstract value "user
> defined" that would then show up several t
New in V24
- Fixes bugs as reported by Michal
- graphicsub2video: use 1x1 output frame size as long as subtitle size is
unknown (0x0) and no size is not explicitly set
- decode: set subtitle frame size from decoding context
- ffmpeg: re-init graph when subtitle size changes
- ffmpeg_filter: alway
Signed-off-by: softworkz
---
libavcodec/avcodec.h | 19 +
libavutil/Makefile | 1 +
libavutil/subfmt.h | 68
libavutil/version.h | 1 +
4 files changed, 71 insertions(+), 18 deletions(-)
create mode 100644 libavutil/subfmt.h
diff -
Root commit for adding subtitle filtering capabilities.
In detail:
- Add type (AVMediaType) field to AVFrame
Replaces previous way of distinction which was based on checking
width and height to determine whether a frame is audio or video
- Add subtitle fields to AVFrame
- Add new struct AVSubt
- Add avcodec_decode_subtitle3 which takes subtitle frames,
serving as compatibility shim to legacy subtitle decoding
- Add additional methods for conversion between old and new API
Signed-off-by: softworkz
---
libavcodec/avcodec.h| 8 +-
libavcodec/codec_desc.c | 11 +++
libavcodec/cod
Signed-off-by: softworkz
---
libavfilter/vf_subtitles.c | 54 +-
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
index 3fc4eeb63d..66b2082894 100644
--- a/libavfilter/vf_subtitles.c
+++ b/l
Also add
- hard_space callback (for upcoming fix)
- extensible callback (for future extension)
Signed-off-by: softworkz
---
libavcodec/Makefile | 56 +++
libavcodec/ass.h | 147 ++
libavcodec/assdec.c
Signed-off-by: softworkz
---
libavcodec/assenc.c| 90 +
libavcodec/avcodec.h | 5 +-
libavcodec/dvbsubenc.c | 96 +--
libavcodec/dvdsubenc.c | 100 +++--
libavcodec/encode.c| 63
Signed-off-by: softworkz
---
libavcodec/ass.h | 2 +-
libavcodec/assdec.c| 2 +-
libavcodec/dvbsubdec.c | 2 +-
libavcodec/dvdsubdec.c | 2 +-
libavcodec/dvdsubenc.c | 2 +-
libavcodec/pgssubdec.c | 2 +-
libavcodec/xsubdec.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
d
Signed-off-by: softworkz
---
fftools/ffplay.c | 102 +-
fftools/ffprobe.c | 48 ++
2 files changed, 78 insertions(+), 72 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index e7b20be76b..0af32888da 100644
--- a/fftoo
Analog to avfilter/video.c and avfilter/audio.c
Signed-off-by: softworkz
---
libavfilter/Makefile| 1 +
libavfilter/avfilter.c | 4 +++
libavfilter/internal.h | 1 +
libavfilter/subtitles.c | 63 +
libavfilter/subtitles.h | 44
Signed-off-by: softworkz
---
libavfilter/avfilter.c | 8 +---
libavfilter/avfilter.h | 11 +++
libavfilter/avfiltergraph.c | 5 +
libavfilter/formats.c | 22 ++
libavfilter/formats.h | 3 +++
libavfilter/internal.h | 18 +++
Signed-off-by: softworkz
---
configure| 2 +-
libavfilter/allfilters.c | 2 ++
libavfilter/buffersink.c | 54 ++
libavfilter/buffersink.h | 7
libavfilter/buffersrc.c | 72
libavfilter/buffersrc.h | 1
- overlaygraphicsubs (VS -> V)
Overlay graphic subtitles onto a video stream
- graphicsub2video {S -> V)
Converts graphic subtitles to video frames (with alpha)
Gets auto-inserted for retaining compatibility with
sub2video command lines
Signed-off-by: softworkz
---
doc/filters.texi
This commit actually enables subtitle filtering in ffmpeg by
sending and receiving subtitle frames to and from a filtergraph.
The heartbeat functionality from the previous sub2video implementation
is retained and applied to all subtitle frames (bitmap, text, ..).
The other part of sub2video funct
This fix targets (rare) cases where multiple input pads have a
.filter_frame function. ff_request_frame_to_filter needs
to call ff_request_frame with the correct input pad
instead of the hardcoded first one.
Signed-off-by: softworkz
---
libavfilter/avfilter.c | 18 +-
1 file chan
- overlaytextsubs {VS -> V)
Overlay text subtitles onto a video stream.
- textsubs2video {S -> V)
Converts text subtitles to video frames
Signed-off-by: softworkz
---
configure| 2 +
doc/filters.texi | 113 ++
libavfilter/Makefile |
s- textmod {S -> S)
Modify subtitle text in a number of ways
- censor {S -> S)
Censor subtitles using a word list
- show_speaker {S -> S)
Prepend speaker names from ASS subtitles to the visible text lines
Signed-off-by: softworkz
---
doc/filters.texi | 206
libavfilt
- stripstyles {S -> S)
Remove all inline styles from subtitle events
Signed-off-by: softworkz
---
doc/filters.texi | 37 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/sf_stripstyles.c | 196 +++
4 fi
- splitcc {V -> VS)
Extract closed-caption (A53) data from video
frames as subtitle Frames
ffmpeg -y -loglevel verbose -i
"https://streams.videolan.org/streams/ts/CC/NewsStream-608-ac3.ts";
-filter_complex
"[0:v]splitcc[vid1],textmod=mode=remove_chars:find='@',[vid1]overlay_textsubs"
outpu
1 - 100 of 128 matches
Mail list logo
