> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Tuesday, March 26, 2019 6:36 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Michael Niedermayer
> Sent: Wednesday, March 27, 2019 5:24 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Wednesday, March 27, 2019 6:44 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N filter graphs and
2019-03-26 23:44 GMT+01:00, Mark Thompson :
> * Run exhaustively in tsan/valgrind/other race detectors and fix every
> problem it finds, then provide evidence from that to help with review.
In addition to issues you mention, I wonder if this wouldn't trigger
many unresolved issues in existing
On 26/03/2019 22:07, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> ...
> ---
> The patch will only effect on multiple SIMPLE filter graphs pipeline,
> Passed fate and
On Tue, Mar 26, 2019 at 06:07:21PM -0400, Shaofei Wang wrote:
> It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> Below are some test cases and comparison as reference.
> (Hardware platform:
2019-03-26 23:07 GMT+01:00, Shaofei Wang :
> It enabled MULTIPLE SIMPLE filter graph concurrency, which
> bring above about 4%~20% improvement in some 1:N
> scenarios by CPU or GPU acceleration
Which version of the patch did you test to get this numbers?
The following is not an actual review,
It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above about
4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software: Intel iHD driver -
2019-01-11 11:18 GMT+01:00, Wang, Shaofei :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Friday, January 11, 2019 1:14 AM
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 1:14 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode +
> N filter graphs and adaptive
2019-01-10 9:18 GMT+01:00, Wang, Shaofei :
> Please ignore those commented lines which will be removed in
> the v2 patch, they were referred from previous reap_filters() code.
>
> "if (HAVE_THREADS && !abr_pipeline)" looks better.
> Could you add more about "not work with thread emulation"?
My
Also caused by some old mingw64 toolchain? Will try to avoid the error in v2
patch. Thanks
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
Michael Niedermayer
Sent: Thursday, January 10, 2019 7:36 AM
To: FFmpeg development discussions and
Please ignore those commented lines which will be removed in the v2 patch, they
were referred from previous reap_filters() code.
"if (HAVE_THREADS && !abr_pipeline)" looks better.
Could you add more about "not work with thread emulation"? Thx.
-Original Message-
From: ffmpeg-devel
On Wed, Jan 09, 2019 at 03:50:03PM -0500, Shaofei Wang wrote:
> With new option "-abr_pipeline"
> It enabled multiple filter graph concurrency, which bring obove about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> Below are some test cases and comparison as reference.
2019-01-09 21:50 GMT+01:00, Shaofei Wang :
> +//if (ost->source_index >= 0)
> +//*filtered_frame=
> *input_streams[ost->source_index]->decoded_frame; //for me_threshold
Is there a reason why this is commented?
> @@ -2179,7 +2285,15 @@ static int
With new option "-abr_pipeline"
It enabled multiple filter graph concurrency, which bring obove about
4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software:
On Sat, Dec 29, 2018 at 04:09:21PM -0500, Shaofei Wang wrote:
> With new option "-abr_pipeline"
> It enabled multiple filter graph concurrency, which bring obvious
> improvement in some 1:N scenarios by CPU and GPU acceleration
>
> Below are some test cases and comparison as reference.
>
With new option "-abr_pipeline"
It enabled multiple filter graph concurrency, which bring obvious
improvement in some 1:N scenarios by CPU and GPU acceleration
Below are some test cases and comparison as reference.
(Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
(Software: Intel iHD
18 matches
Mail list logo
