A fade out (usually at the end of a video) can easily start beyond
INT32_MAX (about 36 minutes). Regression since d40dc64173.
---
libavfilter/vf_fade.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_fade.c b/libavfilter/vf_fade.c
index
On 11/8/18 10:27 PM, Andrey Semashev wrote:
> This commit restores the ability to create DASH streams with codecs
> that require different containers that was lost after commit
> 2efdbf7367989cf9d296c25fa3d2aff8d6e25fdd. It extends the dash_segment_type
> option syntax to allow to specify segment
On Wed, Oct 24, 2018 at 11:10 PM Jun Zhao wrote:
>
> Signed-off-by: Jun Zhao
> ---
> tests/fate/microsoft.mak |6 ++
> tests/ref/fate/vc1test_smm0005 | 29 +
> tests/ref/fate/vc1test_smm0015 | 30 ++
> 3 files changed, 65
On Tue, Oct 30, 2018 at 1:25 PM Jun Zhao wrote:
>
> fix slice number check logic.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/vaapi_encode.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index
On Sun, Nov 11, 2018 at 4:47 AM Michael Niedermayer
wrote:
>
> On Fri, Nov 09, 2018 at 09:11:31PM +0800, Jun Zhao wrote:
> > They are come from 2003 and delete them.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > fftools/ffmpeg.c |6 --
> > 1 files changed, 0 insertions(+), 6 deletions(-)
On Fri, Nov 9, 2018 at 11:11 PM Carl Eugen Hoyos wrote:
>
> 2018-11-09 14:11 GMT+01:00, Jun Zhao :
> > move the variable declaration at start of upper for block and
> > remove the redundant brace.
>
> Why?
>
> (You never had to use git blame and were unhappy about the
> necessary iterations?)
>
>
On 11/11/18 22:43, Andreas Rheinhardt wrote:
> Instead of using a combination of bitreader and -writer for copying data,
> one can byte-align the (obsolete and removed) bitreader to improve
> performance.
> With the right alignment one can even use memcpy. The right alignment
> normally exists
Instead of using a combination of bitreader and -writer for copying data,
one can byte-align the (obsolete and removed) bitreader to improve performance.
With the right alignment one can even use memcpy. The right alignment
normally exists for CABAC and hence for H.265 in general.
For aligned data
I have created a new version that addresses all your concerns. Will send it in
a moment.
I actually wanted to make a separate function, but decided against it because
the code already contained the duplication, so I thought that is how you liked
it.
Thanks for the review. Btw: What was the
On 11/11/2018 7:20 PM, James Almer wrote:
> On 11/8/2018 6:31 PM, Martin Vignali wrote:
>> Le dim. 28 oct. 2018 à 12:59, Martin Vignali a
>> écrit :
>>
>>> Thanks for the comments
>>>
>>> New patch in attach
>>>
>>> - Change the options, to only authorized few value in prores frame (based
>>> on
On 11/8/2018 6:31 PM, Martin Vignali wrote:
> Le dim. 28 oct. 2018 à 12:59, Martin Vignali a
> écrit :
>
>> Thanks for the comments
>>
>> New patch in attach
>>
>> - Change the options, to only authorized few value in prores frame (based
>> on rdd36).
>> - Change option name to match setparams
On Sun, Nov 11, 2018 at 10:47:58AM -0300, James Almer wrote:
> On 11/11/2018 8:57 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > I think we need another volunteer to help with uploading fate samples
> > why i think so, well, if i dont do it it seems to not happen currently
> > until i do it
On Sun, Nov 11, 2018 at 03:47:42PM +0100, Paul B Mahol wrote:
> On 11/11/18, James Almer wrote:
> > On 11/11/2018 11:01 AM, Paul B Mahol wrote:
> >> On 11/11/18, Michael Niedermayer wrote:
> >>> Hi all
> >>>
> >>> I think we need another volunteer to help with uploading fate samples
> >>> why i
On 11/11/18, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> Changelog | 1 +
> configure | 1 +
> doc/filters.texi | 29 +
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c | 1 +
>
On 04/11/18 04:48, Andreas Rheinhardt wrote:
> Instead of using a combination of bitreader and -writer for copying data,
> one can byte-align the (obsolete and removed) bitreader to improve
> performance.
> With the right alignment one can even use memcpy. The right alignment
> normally exists
After adding field type management to the common yadif logic, we can
remove the duplicate copy of that logic from bwdif.
---
libavfilter/bwdif.h | 34 +
libavfilter/vf_bwdif.c | 235 +---
libavfilter/x86/vf_bwdif_init.c | 3 +-
3 files
The bwdif filter can use common yadif frame management if we track
when a field is the first or last field in a sequence. While this
information is not used by yadif, the added benefit of removing the
duplicated frame management logic makes it worth tracking this state
in the common code.
---
vf_bwdif's frame management logic is almost identical to that of yadif.
The only difference is that it tracks the first and last fields in a
sequence, and that requires slight changes to the common code.
Assuming it's reasonable to do that tracking even though yadif doesn't
need it, we can then
Signed-off-by: Marton Balint
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 29 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
On Sat, 10 Nov 2018, Marton Balint wrote:
On Sun, 4 Nov 2018, Marton Balint wrote:
On Sun, 4 Nov 2018, James Almer wrote:
On 11/4/2018 9:06 AM, Marton Balint wrote:
Also add SIMD which works on lines because it is faster then calculating
it on
8x8 blocks using pixelutils.
On 04/11/18 04:48, Andreas Rheinhardt wrote:
> Instead of using a combination of bitreader and -writer for copying data,
> one can byte-align the (obsolete and removed) bitreader to improve
> performance.
> One can even use memcpy in the normal case.
> This improved the time needed for writing
On 11/11/18 17:32, James Almer wrote:
> On 11/11/2018 2:27 PM, Mark Thompson wrote:
>> Supports both prefix and suffix SEI, decoding all of the common SEI
>> types and some more obscure ones. Most of this is tested by the
>> existing tests in fate.
>> ---
>> On 11/11/18 15:57, James Almer wrote:
On 11/11/2018 2:27 PM, Mark Thompson wrote:
> Supports both prefix and suffix SEI, decoding all of the common SEI
> types and some more obscure ones. Most of this is tested by the
> existing tests in fate.
> ---
> On 11/11/18 15:57, James Almer wrote:
>> On 10/27/2018 6:39 PM, Mark Thompson
Supports both prefix and suffix SEI, decoding all of the common SEI
types and some more obscure ones. Most of this is tested by the
existing tests in fate.
---
On 11/11/18 15:57, James Almer wrote:
> On 10/27/2018 6:39 PM, Mark Thompson wrote:
>> Supports both prefix and suffix SEI, decoding all
Am Sa., 10. Nov. 2018 um 18:47 Uhr schrieb Philip Langdale <
phil...@overt.org>:
> The bwdif filter can use common yadif frame management if we track
> when a field is the first or last field in a sequence. While this
> information is not used by yadif, the added benefit of removing the
>
Signed-off-by: Paul B Mahol
---
libavutil/avstring.c | 938 +++
libavutil/avstring.h | 6 +
2 files changed, 944 insertions(+)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index f03dd25141..d33153a8f3 100644
--- a/libavutil/avstring.c
+++
Signed-off-by: Paul B Mahol
---
libavfilter/vf_lut3d.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index e7601a05ac..93053ed263 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -367,7
These may be used by hwaccel decoders when the standard tables are not
otherwise available. At the same time, clean up that code into an array
so it's a little less repetitive.
---
On 29/10/18 10:26, Jun Zhao wrote:
> From: Jun Zhao
>
> Now VA-API HWAccel MJPEG decoding uninitialized huffman
On 10/27/2018 6:39 PM, Mark Thompson wrote:
> Supports both prefix and suffix SEI, decoding all of the common SEI
> types and some more obscure ones. Most of this is tested by the
> existing tests in fate.
It would be neat to make the *_metadata filters not decompose unit types
it doesn't care
On 10/27/2018 7:19 PM, Mark Thompson wrote:
> ---
> tests/fate/libavcodec.mak | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/fate/libavcodec.mak b/tests/fate/libavcodec.mak
> index aa4c36b112..5dde1243fa 100644
> --- a/tests/fate/libavcodec.mak
> +++
It does exactly the same thing as the default get_buffer.
---
fftools/ffmpeg_qsv.c | 8
1 file changed, 8 deletions(-)
diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
index 9c4285b6c7..aef0c26bcc 100644
--- a/fftools/ffmpeg_qsv.c
+++ b/fftools/ffmpeg_qsv.c
@@ -30,13 +30,6 @@
Assertion avctx->codec_id != AV_CODEC_ID_NONE failed at
src/libavcodec/parser.c:128
The setting on the internal AVCodecContext used for parsing only is
otherwise irrelevant, so just set it to avoid the assert.
---
libavcodec/qsvdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Since nothing sets hwaccel_get_buffer any more, this is always equivalent
to the default case.
---
fftools/ffmpeg.c | 11 ---
fftools/ffmpeg.h | 1 -
2 files changed, 12 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 38c21e944a..e0ffd1b779 100644
---
On 09/11/18 09:05, Linjie Fu wrote:
> Currently ff_get_format will go through all usable choices if the chosen
> format was not supported. It will fallback to software path if the hardware
> init fails.
>
> Provided an option "-require_hwaccel 1" in user-code to detect frame->format
> and
>
Fixes #7519.
---
I've had this lying around for a bit with intent to use it to support
non-hwaccel hardware decoders (in particular, v4l2m2m), but it actually fixes
the force-hwaccel use-case too in a sensible way.
doc/ffmpeg.texi | 12
fftools/ffmpeg.c | 4
On 11/11/2018 11:47 AM, Paul B Mahol wrote:
> On 11/11/18, James Almer wrote:
>> On 11/11/2018 11:01 AM, Paul B Mahol wrote:
>>> On 11/11/18, Michael Niedermayer wrote:
Hi all
I think we need another volunteer to help with uploading fate samples
why i think so, well, if i
On 11/11/18, James Almer wrote:
> On 11/11/2018 11:01 AM, Paul B Mahol wrote:
>> On 11/11/18, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> I think we need another volunteer to help with uploading fate samples
>>> why i think so, well, if i dont do it it seems to not happen currently
>>> until i
On 11/11/2018 11:01 AM, Paul B Mahol wrote:
> On 11/11/18, Michael Niedermayer wrote:
>> Hi all
>>
>> I think we need another volunteer to help with uploading fate samples
>> why i think so, well, if i dont do it it seems to not happen currently
>> until i do it ...
>> This is worsened as james
On 11/11/18, Gyan wrote:
> On Sun, Nov 11, 2018 at 5:00 PM Paul B Mahol wrote:
>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavfilter/vf_alphamerge.c | 88 ++---
>> 1 file changed, 44 insertions(+), 44 deletions(-)
>>
>
> Does this fix #7543?
For me Yes.
On 29/10/18 05:56, Ruiling Song wrote:
> The main input may have alpha channel, we just ignore it.
This doesn't ignore it - it leaves it uninitialised in the output, so a YUVA or
GBRAP output will never write to the A plane. I don't think that's what you're
intending.
> Also add some checks
On 11/11/18, Michael Niedermayer wrote:
> Hi all
>
> I think we need another volunteer to help with uploading fate samples
> why i think so, well, if i dont do it it seems to not happen currently
> until i do it ...
> This is worsened as james has technical problems with uploads ATM
>
> Do we
On Sun, Nov 11, 2018 at 5:00 PM Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/vf_alphamerge.c | 88 ++---
> 1 file changed, 44 insertions(+), 44 deletions(-)
>
Does this fix #7543?
Gyan
___
On 11/11/2018 8:57 AM, Michael Niedermayer wrote:
> Hi all
>
> I think we need another volunteer to help with uploading fate samples
> why i think so, well, if i dont do it it seems to not happen currently
> until i do it ...
> This is worsened as james has technical problems with uploads ATM
>
This patch removes some duplicate code in hls_start that prevents the usage
of strftime base filenames in conjuction with hls_segment_size.
Signed-off-by: Stephen Dawkins
---
libavformat/hlsenc.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/libavformat/hlsenc.c
Hi all
I think we need another volunteer to help with uploading fate samples
why i think so, well, if i dont do it it seems to not happen currently
until i do it ...
This is worsened as james has technical problems with uploads ATM
Do we have anyone who wants to help upload fate samples for
Signed-off-by: Paul B Mahol
---
libavfilter/vf_alphamerge.c | 88 ++---
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/libavfilter/vf_alphamerge.c b/libavfilter/vf_alphamerge.c
index 45fa340fcc..b0a590adb3 100644
--- a/libavfilter/vf_alphamerge.c
Add a new option "abr_pipeline" with mutil-thread to improve the 1:N
transcode performance, currently, the code just as a PoC(proof of
concept) prototype, and post it to maillist for RFC(Requect for
Comment).
Jun Zhao (1):
ffmpeg: Improved the performance of 1:N for adaptive bitrate
Improved the performance of 1 decode + N filter graphs and adaptive
bitrate scenario.
With new option "-abr_pipeline"
1. It enabled multiple filter graph concurrency, which bring above
about 5%~20% improvement in some 1:N scenario by CPU or GPU
acceleration
2. Next step will continue to improve
48 matches
Mail list logo
