> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Tuesday, September 17, 2019 3:29 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Fix gif decoder max option
>
> On 9/16/2019 10:24 PM, Soft Works wrote:
> >&
e, Sep 17, 2019 at 00:07:37 +, Soft Works wrote:
> > This commit adds two logging flags: 'timing' and 'datetiming'.
>
> I like the whole idea. I haven't tested yet, but I will in a moment.
>
> > Usage:
> > ffmpeg -loglevel +timing
> >
s
>
> On Tue, Sep 17, 2019 at 01:36:33AM +, Soft Works wrote:
> > Integer values should not be printed using format specifier '%g' which leads
> to inexact display in case of higher values.
> >
> > Before this patch:
> > -trans_color
Hi,
I am looking for some guidance regarding future plans about processing subtitle
streams in filter graphs.
Please correct me where I'm wrong - this is the situation as I've understood it
so far:
- Currently, ffmpeg filter graphs do not support processing subtitle streams
- This is why filte
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Paul B Mahol
> Sent: Sunday, February 16, 2020 11:33 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
>
> On
/16/20, Paul B Mahol wrote:
> > On 2/16/20, Soft Works wrote:
> >>> -Original Message-
> >>> From: ffmpeg-devel On Behalf
> Of
> >>> Paul B Mahol
> >>> Sent: Sunday, February 16, 2020 11:33 AM
> >>> To: FFmpeg development d
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Paul B Mahol
> Sent: Sunday, February 16, 2020 4:12 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
>
> On
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Monday, February 17, 2020 8:37 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
>
> Soft Wo
This allows having a video stream as reference stream when using the segment
muxer:
The video stream serves as a kind of 'heartbeat' to ensure that VTT segments
are generated regularly, even when there aren't any subtitle packets for a
while.
Example:
ffmpeg -i INPUT -map 0:3 -c:0 webvtt -ma
It's often not obvious how option constants relate to numerical values.
Defaults are sometimes printed as numbers and from/to are always printed as
numbers.
Printing the numeric values of options constants avoids this confusion.
It also allows to see which constants are equivalent.
Before this pa
> -Original Message-
> From: Clément Bœsch
> Sent: Saturday, February 22, 2020 9:47 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Soft Works
> Subject: Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
>
> On Fri, Feb 1
> -Original Message-
> From: ffmpeg-devel On Behalf Of
>
> On Sat, Feb 22, 2020 at 10:59:46AM +, Soft Works wrote:
> [...]
> > Reading through the discussion around your patch was discouraging,
> > even destructive in some parts. I understand why you fel
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, February 24, 2020 3:55 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
>
> Quoting Carl Eugen Hoyos (2020-02-24 13:50
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Paul B Mahol
> Sent: Monday, February 24, 2020 5:39 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
>
> On
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Wednesday, May 26, 2021 6:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86
> optimized video scaling filter
>
>
>
> On 2021-05-25 20:17, Hendri
optimized video scaling filter
>
> Soft Works (12021-06-05):
> > And I agree to that disagreement. Also we shouldn't start acting as if
> > the nonfree category wouldn't exist at all and everything that would
> > fall into that category would suddenly no longer be acc
> -Original Message-
> From: ffmpeg-devel On Behalf Of Jan
> Ekström
> If you just go without any rhetoric and just look at what "nonfree"
> (which IMHO is an awful name for the configuration option, it's just
> "non-distributable")
>
> We can start with the history of the option - ori
-Original Message-
From: ffmpeg-devel On Behalf Of Haihao Xiang
Sent: Mittwoch, 23. Juni 2021 05:04
To: ffmpeg-devel@ffmpeg.org
Cc: Haihao Xiang
Subject: [FFmpeg-devel] [PATCH 1/2] qsvdec: add support for HW_DEVICE_CTX method
This allows user set hw_device_ctx instead of hw_frames_ctx
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Lynne
> Sent: Samstag, 26. Juni 2021 01:29
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Hardware purchase request
>
> Jun 25, 2021, 13:25 by t...@rothenpieler.org:
>
> > On 25
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Lynne
> Sent: Samstag, 26. Juni 2021 08:25
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Hardware purchase request
>
> Jun 26, 2021, 02:19 by softwo...@hotmail.com:
>
> >
> >
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Wednesday, 14 July 2021 21:05
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Mailing List Delay
>
> Derek Buitenhuis (12021-07-14):
> > Yeah, I know, but i
pport and already
> > > checked with several apps that use FFMPEG.
> > >
> > > Any particular review comments should be yet expected?
> > >
> > > Changes seem to be straight forward
> > > and incorporate prev. comments.
> > >
> > &g
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Thursday, 15 July 2021 05:21
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> d3d11va support, added mfxhdlpair
>
> On 7/15/2021
, 2021-07-15 at 03:49 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > James Almer
> > > Sent: Thursday, 15 July 2021 05:21
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel
, 2021-07-15 at 06:43 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Xiang, Haihao
> > > Sent: Thursday, 15 July 2021 07:43
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel
upport, added mfxhdlpair
>
> On Thu, Jul 15, 2021 at 5:49 AM Soft Works wrote:
>
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > James Almer
> > > Sent: Thursday, 15 July 2021 05:21
> > > T
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Artem Galin
> Sent: Thursday, 22 July 2021 12:57
> To: ffmpeg-devel@ffmpeg.org; ffmpeg-de...@ffmpeg.org
> Cc: Artem Galin
> Subject: [FFmpeg-devel] [PATCH 3/8] libavutil/hwcontext_qsv: enabling
> d3d11va usage by default, add usa
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Artem Galin
> Sent: Thursday, 22 July 2021 12:57
> To: ffmpeg-devel@ffmpeg.org; ffmpeg-de...@ffmpeg.org
> Cc: Artem Galin
> Subject: [FFmpeg-devel] [PATCH 3/8] libavutil/hwcontext_qsv: enabling
> d3d11va usage by default, add usa
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Haihao Xiang
> Sent: Thursday, 29 July 2021 09:04
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> HW_DEVICE_CTX method
>
> This allows user set hw_device_ctx in
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Sunday, 1 August 2021 19:02
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add (a)separate filters
>
> Paul B Mahol (12021-08-01):
> > Si
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Sunday, 1 August 2021 20:40
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add (a)separate filters
>
>
>
> On 2021-08-01 23:59, Soft Works wrote:
Hi,
I am posting to devel as I’m assuming that this won’t go without some changes
to the code base, so please bear with me even though it may sound like a user
issue at first sight:
This is about extracting images from a video file – every 10s in the following
example:
ffmpeg -i input.mkv
> > Signed-off-by: Nicolas George
> > ---
> > doc/developer.texi | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
> * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
> * http://ffmpeg.org/pipermail/ff
> On 5/12/2017 5:21 AM, Timo Rothenpieler wrote:
> Am 12.05.2017 um 15:34 schrieb James Almer:
> > On 5/12/2017 5:21 AM, Timo Rothenpieler wrote:
> >> Am 12.05.2017 um 07:32 schrieb Yogender Gupta:
> > +cuda_sdk
> > libnpp
> >>>
> >>> IMO, Libnpp is part of the CUDA SDK, and we ca
> > in the above context I'm wondering about whether it is mandatory to
> > treat the "cuda_sdk" option as a non-free option?
> >
> > In case of libnpp it's obviously required to statically link to
> > proprietary Nvidia code code for which there's not public source code
> > available.
> >
> > But
> > At least from my understanding it would be perfectly legal to exclude
> > the CUDA kernel code from ffmpeg and add an option to the filters
> > for specifying a file containing the compiled CUDA kernel to be loaded
> > at runtime (via cuModuleLoadData).
> >
> > What do you think?
>
> It's certa
> > Thanks again for your kind reply. Although I’m not a lawyer myself, I
> > know
> > that if you’re the sole(!) author of the yadif_cuda kernel source, then
> > you
> > would be allowed to publish that code under any additional license you
> > want.
> >
> > But that would be your very own decisi
> > From your explanations, the situation doesn't seem to be as
> > bad as it could be. When the CPU code of the filters can be
> > changed to dynamic linking
>
> The type of the linking of course cannot change the license.
Maybe I should have said 'dynamic loading' rather than 'dynamic
linking'.
> Subject: [FFmpeg-devel] [PATCH 4/5] avfilter/vf_thumbnail_cuda: Switch to
> using ffnvcodec
>
> This change switches the vf_thumbnail_cuda filter from using the
> full cuda sdk to using the ffnvcodec headers and loader.
>
> Most of the change is a direct mapping, but I also switched from
> using
> I've been thinking about this for a while, but I only recently made the
> realisation that compiling cuda kernels to the ptx format does not
> introduce any non-free dependencies - the ptx files are an intermediate
> assembly code format that is actually compiled to binary form at
> runtime. Wit
> From a technical standpoint, this whole series looks fine to me.
>
> However, it really does not fell non-nonfree to me that the only way to
> build these filters remains to register with nvidia, accept their
> various EULAs and download their SDK for nvcc and the libs around it.
>
> Even moving
> From: Jean-Baptiste Kempf
> Sent: Dienstag, 26. Februar 2019 15:01
>
> [...]
>
> I don't think nvcc fit the"normally distributed with the operating system".
I'm not sure if the role of nvcc has been fully understood.
nvcc is some kind of 'pre-compiler' which is not distributed or linked to.
Di
> From: Jean-Baptiste Kempf
> Sent: Dienstag, 26. Februar 2019 23:07
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and
> option for nvcc
>
> On Tue, 26 Feb 2019, at 21:26, Soft Works wrote:
> > It's an exte
> From: Nicolas George
>
> Yufei He (12019-03-11):
> > Matrox M264 is similar to other hardware codecs.
> >
> > I saw amf_load_library and nvenc_load_library in ffmpeg.
>
> Past practices do not constitute precedents.
>
> > We got a lot customers using ffmpeg and they want to use Matrox M264 to do
> From: Jean-Baptiste Kempf
>
> On Mon, 11 Mar 2019, at 17:21, Soft Works wrote:
> > While I don’t care much about Matrox, I’m a bit surprised about the
> > recent sounds here. Should we expect ffmpeg to drop most hw
> > accelerations, then?
>
> Absolute
Hello everybody,
it's been a while since my contribution to matroskaenc in July. In case you
don't remember my scenario - it's about realtime transcoding and and streaming
of mkv files.
That means that the header is sent to the client before the ffmpeg process is
completed.
In this context we
From: ffmpeg-devel on behalf of Paul B Mahol
Sent: Friday, December 23, 2016 12:21 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Serious Regression in matroskaenc:
On 12/23/16, Soft Works wrote:
> Hello everyb
>Le tridi 3 nivôse, an CCXXV, Soft Works a écrit :
>> Only thing that you shouldn't do is breaking the ffmpeg process via key
>> commands
>> because in this case the header would still be finalized.
>
>Then do that!
>
>Or possibly use the "live"
patches
Subject: Re: [FFmpeg-devel] Serious Regression in matroskaenc:
Le tridi 3 nivôse, an CCXXV, Soft Works a écrit :
> Are you making some fun out of me..?
No, sorry if it seemed that way.
> What I laid out was a method to reproduce as requested.
And the clear answer is: it is not a bug. Yo
On Fri, Dec 23, 2016 at 11:19:06AM +, Soft Works wrote:
> Hello everybody,
>
> it's been a while since my contribution to matroskaenc in July. In case you
> don't remember my scenario - it's about realtime transcoding and and
> streaming of mkv files.
> That
>> To matroskaenc were only a few.
I'm counting 33 commits since my change from 17 July 2016
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> Hello everybody,
>
> it's been a while since my contribution to matroskaenc in July. In case you
> don't remember my scenario - it's about realtime transcoding and and
> streaming of mkv files.
> That means that the header is sent to the client before the ffmpeg process is
> completed.
>> can
Nicolas George wrote:
>Le quintidi 25 messidor, an CCXXIV, Soft Works a écrit :
>> Such circumstances are not really "special" or even rare.
>> Especially in most trivial cases (like mkv to mkv) there is a known
>> duration from the source that could be used
Hi,
I just prepared a patch and I've also written a quite comprehensive explanation
(about 60 lines of text).
Should I put all the text into the git commit or should I use a shortened
version for the commit and post the long version to this list only?
Thanks,
softworkz
___
This commit addresses the following scenario:
we are using ffmpeg to transcode or remux mkv (or something else) to mkv. The
result is being streamed on-the-fly to an HTML5 client (streaming starts while
ffmpeg is still running). The problem here is that the client is unable to
detect the durati
Hendrik and Michael,
thanks for looking into my patch!
>> if (!strcmp(s->oformat->name, "webm"))
>> mkv->mode = MODE_WEBM;
>> @@ -1594,6 +1620,18 @@ static int mkv_write_header(AVFormatContext *s)
>> mkv->duration_offset = avio_tell(pb);
>> if (!mkv->is_live) {
>>
>From a04ec6e7ad1a96013ea1f49fa790abc6e6281ca3 Mon Sep 17 00:00:00 2001
From: softworkz
Date: Sun, 17 Jul 2016 04:19:41 +0200
Subject: [PATCH] avformat/matroskaenc: Write duration early during
mkv_write_header (Rev #2)
Revised patch: Fixes doubled header writing, checked FATE running without err
Hi,
>> We don't use CamelCase for anything but structs. Don't you see the variable
>> above and basically everywhere?
>> Change it to metadata_duration.
> And reduce its scope while at it. You can declare it in the same block
> you're using it.
I apologize - I'm new to this project and have to g
>From 7d6d6a7775fef707ea1e8e705acc3362f20b6b89 Mon Sep 17 00:00:00 2001
From: softworkz
Date: Sun, 17 Jul 2016 04:19:41 +0200
Subject: [PATCH] avformat/matroskaenc: Write duration early during
mkv_write_header (Rev #3)
Rev #2: Fixes doubled header writing, checked FATE running without errors
Rev
>> I apologize - I'm new to this project and have to get familiar with the
>> coding styles..
>
>Before writing your first line of code, read other ffmpeg code as well
>as the developer guidelines. Those things mentioned in this thread are
>all noted here:
>https://ffmpeg.org/developer.html#Codi
> From: ffmpeg-devel on behalf of Soft Works
>
> Sent: Tuesday, July 19, 2016 3:33 AM
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] avformat/matroskaenc: Write duration early
> during mkv_write_header
Hi,
we are using ffmpeg to transcode or remux mkv to mkv. The result is being
streamed on-the-fly to an HTML5 client (streaming starts while ffmpeg is still
running).
The problem here is that the client is unable to detect the duration because
the duration is only written to the mkv at the end
> Unfortunately the duration is not available in all cases, so writing
> it early would only work in a few special circumstances, so as a
> generic solution its not going to work.
Such circumstances are not really "special" or even rare.
Especially in most trivial cases (like mkv to mkv) there is
> There are two sides to this issue: change the muxer to write the value if it
> is known at the beginning and change the command-line tool to compute the
> value for their output.
> I suspect the muxer change would be reasonably easy.
> The change on the command-line tool, on the other hand, yo
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b63b5aca6e0a43483e89e64b0f7d2dd avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf822711720ff0f8d14db71ae47cdf97e652 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfbe777cd2916a35
> From: ffmpeg-devel on behalf of Michael
> Niedermayer
>
> this patch breaks fate
> make fate
I apologize, I had run fate but for some reason I hadn't got an error.
But now I ran again, found and fixed the error.
Please find attached a revised patch (still single patch for now).
> changes t
==> Revised patch in plain text (the attachment from my previous reply wasn't
recognized by patchwork)
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b63b5aca6e0a43483e89e64b0f7d2dd avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf822
This commit adds the avio_get_dyn_buf function which allows accessing the
content of a DynBuffer without destroying it.
This is required in matroskaenc for preliminary writing (correct) mkv headers.
Context for this change is fixing regression bug #5977.
---
libavformat/avio.h| 12 ++
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b63b5aca6e0a43483e89e64b0f7d2dd avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf822711720ff0f8d14db71ae47cdf97e652 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfbe777cd2916a35
> From: ffmpeg-devel on behalf of James Almer
>
> Sent: Friday, January 6, 2017 6:02 AM
>
> IMO, no point calculating and writing a CRC element for this temporary state.
> You can rename and simplify this function into something like
>
> static void end_ebml_master_preliminary(AVIOContext *pb,
> James Almer wrote
>
>
> start_ebml_master_crc32() only reserves the space needed for the CRC32
> element,
> which is then written by end_ebml_master_crc32(). The preliminary header will
> have a couple six bytes long Void elements that every parser will promptly
> ignore.
>
> CRC32 elements o
[PATCH] libavformat/avio: Add avio_get_dyn_buf function
Revision #2: Bumb version and add APIchanges entry
This commit adds the avio_get_dyn_buf function which allows accessing
the
content of a DynBuffer without destroying it.
This is required in matroskaenc for preliminary writing (correct) mkv
Revision #4: Don't create CRC32 for preliminary headers
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b63b5aca6e0a43483e89e64b0f7d2dd avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf822711720ff0f8d14db71ae47cdf97e652 avformat/matrosk
> Michael wrote
> Is the author name intended to be
> Author: softworkz
Yes please, if you don't mind, same as my previous commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=70c1647a3501fa6182c04c9ce66f477def64a611
PS: On behalf of the Emby project, I'd like to thank you for your kind
as
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Haihao Xiang
> Sent: Wednesday, September 16, 2020 8:45 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH 0/6] qsv: Fix compiler errors when using
> libmfx 2.0 (oneVPL)
>
> The oneAPI Video Proce
, 2020-09-16 at 08:12 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Haihao Xiang
> > > Sent: Wednesday, September 16, 2020 8:45 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Haih
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: Thursday, October 29, 2020 12:52 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavu/hwcontext_amf: Engine
> selection support for AMF context
>
> On 15/10/2020 01:16, OvchinnikovD
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Friday, August 26, 2022 10:47 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
>
> Quo
Hi,
I don’t want to get involved in the ipfsgateway discussion, but the part about
external library version dependencies and testability reminded me of some
recent thoughts: I wonder whether it wouldn’t make sense to maintain a version
reference for external libraries in a way that at any point i
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Wednesday, August 31, 2022 3:40 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
>
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Sunday, September 4, 2022 8:58 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
>
> Quoting Timo Rothenpieler (2022-09-02 0
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Monday, September 5, 2022 7:59 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
>
> Quoting S
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Wednesday, August 31, 2022 6:02 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
>
>
&
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Wednesday, August 31, 2022 3:40 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
>
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Monday, October 10, 2022 1:08 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 11/11] doc/filters.texi: update
> overlay_vaapi documentation
>
>
>
> On 2022-10-10 04:24 pm, softworkz wrot
> -Original Message-
> From: ffmpeg-devel On Behalf Of Jan
> Ekström
> Sent: Monday, October 10, 2022 2:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v5 3/3] ffmpeg: add video heartbeat
> capability to fix_sub_duration
>
> From: Jan Ekström
>
> Splits the curren
This is a friendly ping on these recent submissions:
Print filter input/output formats in help output
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7737
Fixes and Enhancements for VAAPI Overlay
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7722
Add option to log timing
h
> -Original Message-
> From: ffmpegagent
> Sent: Friday, July 22, 2022 1:40 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Mark Thompson ; Soft Works ;
> softworkz
> Subject: [PATCH v3 0/4] Add derive-device function which searches for
> existing devices in both di
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Thursday, July 21, 2022 11:56 PM
> To: Xiang, Haihao ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v5 0/6] Implement SEI parsing for
> QSV decoders
>
> Xiang, Haihao:
> > On Fri, 2022-0
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Tuesday, October 25, 2022 11:38 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare
> AVFrame for subtitle handling
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Thursday, October 27, 2022 7:54 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v9 23/25] avcodec/subtitles:
> Migrate subtitle encoders to fr
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Tuesday, October 25, 2022 11:59 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare
> AVFra
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Clément Bœsch
> Sent: Sunday, October 30, 2022 6:58 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softwo...@hotmail.com; Clément Bœsch
> Subject: [FFmpeg-devel] [PATCH] Revert "avfilter/vf_palette(gen|use):
> support palettes with alpha"
: support palettes with alpha"
>
> On Sun, Oct 30, 2022 at 09:19:05PM +, Soft Works wrote:
> [...]
> > At the time of submission I did a lot of experiments and the
> results
> > seemed to be very useful:
> >
> > https://gist.github.com/softworkz/dee
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Soft Works
> Sent: Sunday, October 30, 2022 10:41 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Revert
> "avfilter/vf_palette(gen|use)
: support palettes with alpha"
>
> On Sun, Oct 30, 2022 at 10:55:31PM +, Soft Works wrote:
> [...]
> > > I understand why. I know that it's not perfect. But it's the best
> > > what's achievable within the way the filter is working.
> > >
: support palettes with alpha"
>
> On Sun, Oct 30, 2022 at 10:55:31PM +, Soft Works wrote:
> [...]
>
> > Do you think it might make sense to put more weight on the
> > alpha value by tripling it? So it would be weighted equally to the
> > RGB value?
>
&
> -Original Message-
> From: Xiang, Haihao
> Sent: Monday, October 31, 2022 6:44 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softwo...@hotmail.com
> Subject: Re: [FFmpeg-devel] [PATCH 09/11] avfilter/overlay_vaapi:
> enable expressions for overlay parameters
>
> On Mon, 2022-10-10 at 10:54
: support palettes with alpha"
>
> On Mon, Oct 31, 2022 at 01:43:11AM +, Soft Works wrote:
> [...]
> > > > > The patch I had submitted doesn't change the previous
> behavior
> > > > > without the use_alpha parameter.
> > >
> &
: support palettes with alpha"
>
> On Mon, Oct 31, 2022 at 03:11:13PM +, Soft Works wrote:
> [...]
> > And pngquant doing the impossible as well:
> >
> > > Interestingly, pngquant which is supposed to have the best open
> source
> > > quantization al
501 - 600 of 1691 matches
Mail list logo
