On 12/5/22 05:29, Steven Liu wrote:
Hi Basel,
Could you send a new version patchset name lead by "v2" ?
git format -patch -v 2
Will do
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To un
hls_delete_file and dashenc_delete_file functions open a
new HTTP connection regardless of the http_persistent value,
So change the behaviour to keep http connections open
if http_persistent is set
Signed-off-by: Basel Sayeh
---
libavformat/hlsenc.c | 18 +-
1 file changed, 13
Signed-off-by: Basel Sayeh
---
libavformat/dashenc.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 9c1bcad9e3..2521568ea5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -179,6 +179,7 @@ ty
oops, another small mistake, please see v3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
oops, another small mistake, please see v3
From: Basel Sayeh
Sent: Monday, December 5, 2022 2:22 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Basel Sayeh
Subject: [PATCH v2 2/2] libavformat/dashenc: Enable HTTP persistent connections
for dashenc_delete_file
Signed-off-
V3
hls_delete_file and dashenc_delete_file functions open a
new HTTP connection regardless of the http_persistent value,
So change the behaviour to keep http connections open
if http_persistent is set
Signed-off-by: Basel Sayeh
---
libavformat/hlsenc.c | 18 +-
1 file changed
Signed-off-by: Basel Sayeh
---
libavformat/dashenc.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 9c1bcad9e3..ba0eb913a1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -179,6 +179,7 @@ ty
On Sun, Dec 4, 2022 at 12:51 PM Alessandro Di Nepi <
alessandro.din...@gmail.com> wrote:
> On 4 Dec 2022, 17:01 +0200, FFmpeg development discussions and patches <
> ffmpeg-devel@ffmpeg.org>, wrote:
> > When this happens, does it continue happening, or is it transient? My
> main
> > concern is log
This is fairly basic and makes a lot of assumptions, but it works
for the most simple cases.
For one, it only ever fetches exactly one packet per call to receive_frame.
Right now it's impossible for there to ever be more than one, but the API
allows for more, which might need handled in the future
In my tests, this lead to a notable speed increase with the amount
of threads used. Decoding a 720p sample gave the following results:
1 Thread: 1428 FPS
2 Threads: 2501 FPS
8 Threads: 7575 FPS
Automatic: 11326 FPS (On a 16 Core/32 Threads system)
---
libavcodec/jpeglsdec.c | 2 +-
libavcodec/mj
Timo Rothenpieler:
> In my tests, this lead to a notable speed increase with the amount
> of threads used. Decoding a 720p sample gave the following results:
>
> 1 Thread: 1428 FPS
> 2 Threads: 2501 FPS
> 8 Threads: 7575 FPS
> Automatic: 11326 FPS (On a 16 Core/32 Threads system)
> ---
> libavcod
On 12/5/22, Andreas Rheinhardt wrote:
> Timo Rothenpieler:
>> In my tests, this lead to a notable speed increase with the amount
>> of threads used. Decoding a 720p sample gave the following results:
>>
>> 1 Thread: 1428 FPS
>> 2 Threads: 2501 FPS
>> 8 Threads: 7575 FPS
>> Automatic: 11326 FPS (On
On Sun, 4 Dec 2022, Chris Ribble wrote:
More strict enforcement of sample size was introduced to avoid DOS/Timeout
with crafted (fuzzed) files and disallow emitting zero sized packets.
Invalid file support is not something that is always worth doing, there
are other, more important factors,
Hyper Encode uses Intel integrated and discrete graphics on one system
to accelerate encoding of a single video stream.
Depending on the selected parameters and codecs, performance gain on AlderLake
iGPU + ARC Gfx up to 1.6x.
More information:
https://www.intel.co.uk/content/www/uk/en/architectu
On Sun, Dec 04, 2022 at 09:36:19PM -0800, mindm...@gmail.com wrote:
> From: Mark Reid
>
> Also renamed bswap_buf to bswap32_buf
> ---
> configure | 56 ---
> libavcodec/4xm.c | 14 ++---
> libavcodec/Makefile
On Sun, Dec 04, 2022 at 06:52:24PM -0300, James Almer wrote:
> The idea behind last_pkt_props was to store the properties of the last packet
> fed to the decoder. Any sort of queueing required by decoders that consume
> several packets before they start outputting frames should be done by the
> dec
On Mon, Dec 5, 2022 at 12:33 PM Michael Niedermayer
wrote:
> On Sun, Dec 04, 2022 at 09:36:19PM -0800, mindm...@gmail.com wrote:
> > From: Mark Reid
> >
> > Also renamed bswap_buf to bswap32_buf
> > ---
> > configure | 56 ---
> > libavcodec/4
From: Mark Reid
There are some places in input.c that could use it too
but they aren't currently being pass the SwsContext
---
libswscale/output.c | 36 +++
libswscale/swscale_internal.h | 3 +++
libswscale/swscale_unscaled.c | 26 +-
From: Mark Reid
Also renamed bswap_buf to bswap32_buf
---
configure | 56 ---
libavcodec/4xm.c | 14 ++---
libavcodec/Makefile | 1 -
libavcodec/ac3dec.c | 4 +-
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 11 +++
libavcodec/options_table.h | 1 +
libavcodec/version.h | 2 +-
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ab7ce15fae..9c1f905a61 100644
--- a/doc/
---
libavcodec/nvdec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index fbaedf0b6b..76ee395734 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
CudaFunctio
On Mon, Dec 05, 2022 at 04:37:29AM +, Xiang, Haihao wrote:
> On Wed, 2022-11-23 at 13:54 -0800, Brian Norris wrote:
> > +} else if (!strncmp(info->name, "vgem", 4)) {
>
> The virtual GEM device is vgem, so better to use strcmp here.
Good point, we probably shouldn't be matchi
There can be more than one available render node, and it's not
guaranteed the first node we come across is the correct one. In
particular, 'vgem' devices are common, and are
never VAAPI-enabled and thus not valid here.
We have a 'kernel_driver' arg already for specifying a single driver we
*do* wa
On 05.12.2022 15:15, Andreas Rheinhardt wrote:
Timo Rothenpieler:
In my tests, this lead to a notable speed increase with the amount
of threads used. Decoding a 720p sample gave the following results:
1 Thread: 1428 FPS
2 Threads: 2501 FPS
8 Threads: 7575 FPS
Automatic: 11326 FPS (On a 16 Core/
This will be needed for the following commit, after which ff_get_buffer() will
stop setting frame->pts to AV_NOPTS_VALUE.
Signed-off-by: James Almer
---
This one goes before '[PATCH 2/5] Revert "avcodec/decode: use a packet list to
store packet properties"'
libavcodec/wmadec.c | 1 +
1 file cha
> On Dec 5, 2022, at 21:36, Rick Kern wrote:
>
> On Sun, Dec 4, 2022 at 12:51 PM Alessandro Di Nepi <
> alessandro.din...@gmail.com> wrote:
>
>> On 4 Dec 2022, 17:01 +0200, FFmpeg development discussions and patches <
>> ffmpeg-devel@ffmpeg.org>, wrote:
>>> When this happens, does it continue
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
libavfilter/qsvvpp.c | 2 ++
libavfilter/vf_vpp_qsv.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index a588a37610..6f58fe6017 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.
From: Haihao Xiang
$ ffmpeg -f lavfi -i testsrc -vf "format=nv12,vpp_qsv=scale_mode=hq" -f
null -
Signed-off-by: Haihao Xiang
---
libavfilter/vf_vpp_qsv.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index a14b3de7b5..8013e0da6c 10
On Mon, Dec 5, 2022 at 12:04 PM Marton Balint wrote:
>
> Share the sample please. If the patch I proposed does not fix it, I am not
> sure what is the best approach here.
>
Sure, I will send you the URL to the file so that you can try it.
___
ffmpeg-dev
29 matches
Mail list logo
