Gesendet: Montag, 05. September 2022 um 12:45 Uhr
Von: "Andreas Rheinhardt"
An: ffmpeg-devel@ffmpeg.org
Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
initialization
Lukas Fellechner:
>>> Moreover, older pthread standards d
ally not much.
I do not have a CPU with so many cores, but when doing 4K -> 4K transcode,
I sure see a benefit of using 32 vs 16 cores.
Maybe the best approach would really be to decide auto thread count
on the amount of pixels to process (I would not use line count because
when line count dou
Gesendet: Dienstag, 06. September 2022 um 23:11 Uhr
Von: "Andreas Rheinhardt"
An: ffmpeg-devel@ffmpeg.org
Betreff: Re: [FFmpeg-devel] [PATCH] slicethread: Limit the automatic number of
threads to 16
Lukas Fellechner:
>> 1. Running out of address space in 32-bit processes
>>
>Gesendet: Montag, 05. September 2022 um 21:58 Uhr
>Von: "Martin Storsjö"
>An: ffmpeg-devel@ffmpeg.org
>Betreff: Re: [FFmpeg-devel] [PATCH] slicethread: Limit the automatic number of
>threads to 16
>On Mon, 5 Sep 2022, Martin Storsjö wrote:
>
>> This matches a similar cap on the number of automat
Whitespace change only. No functional changes.
---
libavformat/dashdec.c | 74 +--
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 19e657d836..22f727da3b 100644
--- a/libavformat/dashdec.c
+
For adding multithreading to the DASH decoder initialization,
the open_demux_for_component() method must be split up into two parts:
begin_open_demux_for_component(): Opens the stream and does probing
and format detection. This can be run in parallel.
end_open_demux_for_component(): Creates the A
This patch adds an "init_threads" option, specifying the max
number of threads to use. Multiple worker threads are spun up
to massively bring down init times.
---
libavformat/dashdec.c | 286 +-
1 file changed, 285 insertions(+), 1 deletion(-)
diff --git a/
open_url modifies the shared avio_opts dict (update cookies).
This can cause problems during multithreaded initialization.
To prevent this, I take a copy of avio_opts, use that in open_url,
and copy the updated dict back afterwards.
---
libavformat/dashdec.c | 34 --
Initializing DASH streams is currently slow, because each individual
stream is opened and probed sequentially. With DASH streams often
having somewhere between 10-20 streams, this can easily take up to
half a minute on slow connections.
This patch adds an "init_threads" option, specifying the max
> Gesendet: Freitag, 02. September 2022 um 01:46 Uhr
> Von: "Timo Rothenpieler"
> An: ffmpeg-devel@ffmpeg.org
> Betreff: Re: [FFmpeg-devel] [RFC] d3dva security hw+threads
> On 02.09.2022 01:32, Michael Niedermayer wrote:
>> Hi all
>>
>> Theres a use after free issue in H.264 Decoding on d3d11va w
>Gesendet: Montag, 05. September 2022 um 12:45 Uhr
>Von: "Andreas Rheinhardt"
>An: ffmpeg-devel@ffmpeg.org
>Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
>initialization
>Lukas Fellechner:
>>> Gesendet: Montag, 05. Septembe
> Gesendet: Montag, 05. September 2022 um 00:50 Uhr
> Von: "Andreas Rheinhardt"
> An: ffmpeg-devel@ffmpeg.org
> Betreff: Re: [FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH
> initialization
> Lukas Fellechner:
> > Andreas Rheinhardt andreas.rheinh
Andreas Rheinhardt andreas.rheinhardt at outlook.com
Wed Aug 31 05:54:12 EEST 2022
>
> > +#if HAVE_THREADS
> > +
> > +struct work_pool_data
> > +{
> > +AVFormatContext *ctx;
> > +struct representation *pls;
> > +struct representation *common_pls;
> > +pthread_mutex_t *common_mutex;
Gesendet: Dienstag, 23. August 2022 um 05:19 Uhr
Von: "Steven Liu"
An: "FFmpeg development discussions and patches"
Betreff: Re: [FFmpeg-devel] [PATCH v2] lavf/dashdec: Multithreaded DASH
initialization
Lukas Fellechner 于2022年8月22日周一 03:27写道：
>
> I look
---
libavformat/dashdec.c | 74 +--
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 20f2557ea3..f653b9850e 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -2412,54 +2412,54
This patch adds an "init-threads" option, specifying the max
number of threads to use. Multiple worker threads are spun up
to massively bring down init times.
---
libavformat/dashdec.c | 351 +-
1 file changed, 350 insertions(+), 1 deletion(-)
diff --git a/
For adding multithreading to the DASH decoder initialization,
the open_demux_for_component() method must be split up into two parts:
begin_open_demux_for_component(): Opens the stream and does probing
and format detection. This can be run in parallel.
end_open_demux_for_component(): Creates the A
Initializing DASH streams is currently slow, because each individual
stream is opened and probed sequentially. With DASH streams often
having somewhere between 10-20 streams, this can easily take up to
half a minute on slow connections.
This patch adds an "init-threads" option, specifying the max
Initializing DASH streams is currently slow, because each individual stream is
opened and probed sequentially. With DASH streams often having somewhere
between 10-20 streams, this can easily take up to half a minute. This patch
adds an "init-threads" option, specifying the max number of threads
>> + struct representation* common_pls;
>> + pthread_mutex_t* common_mutex;
>> + pthread_cond_t* common_condition;
> Should add #if HAVE_THREADS to check if the pthread supported.
You are right, I will add HAVE_THREADS checks.
___
ffmpeg-devel mailing li
Trying with inline PATCH since attached file was not showing up...
---
From: Lukas Fellechner
Subject: [PATCH 1/1] lavf/dashdec: Multithreaded DASH initialization
Initializing DASH streams is currently slow, because each individual stream is
opened and probed sequentially. With DASH streams
lean as possible and added multiple comments.
- Multithreading is never simple, so a proper review is needed.
If this gets merged, I might try to do the same for HLS.
This is my first PR by the way, so please be nice :)
Lukas
0001-lavf-dashdec-Multithreaded-DASH-initialization.patch
Desc
There is no reason to enforce a high minimum. In the context
of streaming only a few output buffers and capture buffers
are even needed for continuous playback. This also helps
alleviate memory pressure when decoding 4K media.
---
libavcodec/v4l2_m2m.h | 2 +-
libavcodec/v4l2_m2m_dec.c | 2 +-
eplied when i saw your patch
> i just didnt reply because of migraine ...
>
> Thx
>
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Thank you Michael, I just compiled successfully with gas-preprocessor from the
FFmpeg git repo.
All the best!
Lukas
___
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".
f other fixes as well not present in the
> repo referenced above, exist at
> https://git.libav.org/?p=gas-preprocessor.git;a=summary.
>
> // Martin
Thank you, indeed the updated preprocessor fixes the build for me.
Maybe the changes form libav should be merged into the FFmpeg repository the
> > On Oct 1, 2019, at 23:07, Lukas Fellechner wrote:
> >
> > This has worked very well for quite a long time. But after upgrading to
> > FFmpeg 4.2, the build fails. A lot of changes and additions have been done
> > for ARM/NEON 64-bit, and it looks like many o
change which causes those errors?
Below I will post build errors that I see on ARM and ARM64 builds. Other files
could be affected as well (build cancels out after a few errors).
Thank you for your help.
Best Regards
Lukas
Errors with ARM64 target:
C:\Source\FFmpegInterop-lukasf\ffmpeg\Output
Compiling FFmpeg with gas-preprocessor.pl and armasm or armasm64 fails since
FFmpeg 4.2.
New .rdata sections have been added in ARM NEON assembly code (e.g.
libavutil/aarch64/asm.S).
This fix allows gas-preprocessor to translate those sections to armasm
compatible code.
Gas-preprocessor is mai
is there some other way to get this working, without completely disabling
NEON optimizations?
Thank you, all the best
Lukas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit li
On Thu, 2019-04-11 at 21:03 +0200, Hendrik Leppkes wrote:
> On Thu, Apr 11, 2019 at 7:47 PM Peter F
> wrote:
> > Hi,
> >
> > Am Do., 11. Apr. 2019 um 00:50 Uhr schrieb Hendrik Leppkes
> > :
> > > On Thu, Apr 11, 2019 at 12:39 AM Lukas Rusak
> > >
This will allow applications to properly init the decoder in
cases where a hardware decoder is tried first and and software
decoder is tried after by calling the get_format callback.
Even though there is no hardware pixel formats available
we still need to return the software pixel format.
Tested
Just an FYI i will be developing here if anyone wants to comment and/or
PR other changes for V4.
https://github.com/lrusak/FFmpeg/commits/v4l2-drmprime-v4
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo
On Sat, 2018-08-04 at 22:43 +0100, Mark Thompson wrote:
> On 04/08/18 01:40, Lukas Rusak wrote:
> > This allows for a zero-copy output by exporting the v4l2 buffer
> > then wrapping that buffer
> > in the AVDRMFrameDescriptor like it is done in rkmpp.
> >
> > Th
just some simple formatting fixes that unify the code quality
---
libavcodec/v4l2_buffers.c | 23 +++
libavcodec/v4l2_buffers.h | 1 -
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index e5c46ac81e..897c3c
From: Jorge Ramirez-Ortiz
Signed-off-by: Jorge Ramirez-Ortiz
---
libavcodec/v4l2_context.c | 19 ---
libavcodec/v4l2_m2m_dec.c | 9 +++--
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 9457fadb1e..
This just makes the M2MDEC_CLASS similar to how it is done in rkmpp. It looks
clean and has proper indentation
---
libavcodec/v4l2_m2m_dec.c | 46 ---
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m
This allows for a zero-copy output by exporting the v4l2 buffer then wrapping
that buffer
in the AVDRMFrameDescriptor like it is done in rkmpp.
This has been in use for quite some time with great success on many platforms
including:
- Amlogic S905
- Raspberry Pi
- i.MX6
- Dragonboard 410c
T
This was found using valgrind. Using this patch there is no more memleak
present.
---
libavcodec/v4l2_m2m_dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 598dc10781..710e40efd8 100644
--- a/libavcodec/v4l2_m
This is just some formatting that is taken from the rkmpp decoder. I find that
this make is more readable.
---
libavcodec/v4l2_m2m_dec.c | 44 ---
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_de
From: Jorge Ramirez-Ortiz
Signed-off-by: Jorge Ramirez-Ortiz
---
libavcodec/v4l2_context.c | 19 ---
libavcodec/v4l2_m2m_dec.c | 11 ---
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 9457fadb1e
This is V2 of my previous patch. I have worked together with Jorge to get this
working properly.
We have made it so that AV_PIX_FMT_DRM_PRIME output can be selected by setting
avctx->pix_fmt.
This allows v4l2 to export the buffer so we can use it for zero-copy. If
AV_PIX_FMT_DRM_PRIME is
not sel
15:27:39 -0800
> Lukas Rusak wrote:
>
> > This default time base should be set in order for ffmpeg to rescale the
> timebase in v4l2_get_pts and v4l2_set_pts
> >
> > ---
> > libavcodec/v4l2_m2m_dec.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
&g
Hmm ok, disregard then.
On Mon, Jan 8, 2018 at 3:53 PM wm4 wrote:
> On Mon, 8 Jan 2018 15:27:38 -0800
> Lukas Rusak wrote:
>
> > we check for a valid pts in v4l2_set_pts so we should do the same here
> >
> > ---
> > libavcodec/v4l2_buffers.c | 5 -
> &
This is a patch I have been testing for a while in combination with kodi's
drmprime renderer
I have been testing this with i.MX6 and Dragonboard 410c. So it covers single
and multiplanar formats.
I'm looking to get some comments on how to integrate this properly so that if
we request
AV_PIX_FM
This default time base should be set in order for ffmpeg to rescale the
timebase in v4l2_get_pts and v4l2_set_pts
---
libavcodec/v4l2_m2m_dec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 8308613978..4de091a011 100644
--- a/li
Some small fixes that I have done while working with v4l2
Lukas Rusak (3):
libavcodec/v4l2_buffers: return int64_t in v4l2_get_pts
libavcodec/v4l2_buffers: check for valid pts value
libavcodec/v4l2_m2m_dec: set default time base
libavcodec/v4l2_buffers.c | 7 +--
libavcodec
we check for a valid pts in v4l2_set_pts so we should do the same here
---
libavcodec/v4l2_buffers.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index fdafe7edca..5337f6f287 100644
--- a/libavcodec/v4l2_buffers.c
++
v4l2_pts is type int64_t we should return that instead of uint64_t
---
libavcodec/v4l2_buffers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ba70c5d14b..fdafe7edca 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/liba
m4b is commonly used as extension for m4a audiobook files.
The format is exactly the same. The only thing that differs
is the extension.
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a34987a7dc..a920eb
> On 5. Oct 2017, at 10:51, wm4 wrote:
>
> On Thu, 5 Oct 2017 03:34:19 +0200
> Lukas Stabe wrote:
>
>> These changes store id3 chapter data in ID3v2ExtraMeta and introduce
>> ff_id3v2_parse_chapters to parse them into the format context if needed.
>>
>&
> On 5. Oct 2017, at 09:08, Paul B Mahol wrote:
>
> On 10/5/17, Lukas Stabe wrote:
>> These changes store id3 chapter data in ID3v2ExtraMeta and introduce
>> ff_id3v2_parse_chapters to parse them into the format context if needed.
>>
>> Encoders using ff_id
These changes store id3 chapter data in ID3v2ExtraMeta and introduce
ff_id3v2_parse_chapters to parse them into the format context if needed.
Encoders using ff_id3v2_read, which previously parsed chapters into the format
context automatically, were adjusted to call ff_id3v2_parse_chapters.
---
> Kind of worried what happens if the ID3 information conflicts with the
> normal container information. As you know, libavformat accepts even mp4
> or mkv files with ID3v2 header.
>
> Do you think this is a potential issue?
I'm quite new to the ffmpeg source, but if I'm reading things correctly,
The format context (when not NULL) is used to store chapter information,
which was not previously supported by ff_id3v2_read_dict.
This fixes https://trac.ffmpeg.org/ticket/6558
---
libavformat/hls.c | 2 +-
libavformat/id3v2.c | 4 ++--
libavformat/id3v2.h | 6 --
libavformat/utils.c | 2 +
from
teletext?
Best regards,
Lukas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2015-08-27 12:45 GMT+02:00 wm4 :
> [..]
>
> When can this happen? Shouldn't it just return an error somewhere if
> this is not an encoder?
I'm working on a Rust wrapper library and apparently am doing something
wrong (it segfaulted). `avcodec_encode_video2()` has this assertion, so I
thought it mi
56 matches
Mail list logo
