On Tue, Dec 5, 2017, at 09:36 PM, Gyan Doshi wrote:
> Both done.
Thanks, and LGTM.
As it is late here I plan to test and commit this tomorrow unless
someone else does first.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On 12/6/2017 4:08 AM, Lou Logan wrote:
Nit: change "set :" to "set:".
Would it be possible to list the profiles with x265_profile_names
similar to what is done for libx264?
Both done.
From 607ed6fd623cee0e2d49a70d9446b8360c799498 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 20
>
>
>
>On 12/4/17, 3:20 PM, "Steven Liu" wrote:
>
>
>
>Signed-off-by: Steven Liu
>
>---
>
> libavformat/hlsenc.c | 681 ++-
>
> 1 file changed, 345 insertions(+), 336 deletions(-)
>
>
>
>diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>
>in
On Tue, Dec 5, 2017, at 03:28 PM, Bang He wrote:
> can it list profiles and levels?
I don't know (also, too lazy to look into it). That's why I asked.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2017-12-06 9:42 GMT+08:00 Colin NG :
> ---
> libavformat/dashdec.c | 111
> --
> 1 file changed, 98 insertions(+), 13 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 3798649..6e35e91 100644
> --- a/libavformat/das
---
libavformat/dashdec.c | 111 --
1 file changed, 98 insertions(+), 13 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 3798649..6e35e91 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -148,6 +148,11
On 12/6/2017 12:36 AM, Jacob Trimble wrote:
> Would a 0-length array work? Otherwise I would need to have it be a
> 1-length array and have to account for that when calculating the size
> to allocate; it would also require a comment to ignore the size of the
> array.
Aren't 0-length arrays a GNU
On 12/6/2017 12:12 AM, Michael Niedermayer wrote:
> The test produces different output on qemu arm and x86-64.
> From this we know there is a bug, but not where the bug is.
> It can be in the test, the newly added code tested or code that was
> there before.
>
> My guess was, its the test, i canno
Add ifdef to support versions of x265 <= 2.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Used by movenc to fill sdtp box
---
libavcodec/libx265.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 4456e300f2..69bfc4fdaa 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -329,6 +329,13 @@ FF_DISABLE_DEPRECATION_WARN
On Tue, Dec 5, 2017 at 3:25 PM, Derek Buitenhuis
wrote:
> On 12/5/2017 11:00 PM, Jacob Trimble wrote:
>> Also, can I use the flexible array member feature, it was introduced
>> in C99? Would a 0-length array be better?
>
> No, I don't think this would be OK inside a public header, unfortunately.
can it list profiles and levels?
On Wed, Dec 6, 2017 at 6:38 AM, Lou Logan wrote:
> On Tue, 5 Dec 2017 19:46:09 +0530
> Gyan Doshi wrote:
>
> > From 13ad80871978fe7e5837863e0e2f7b7d6b356155 Mon Sep 17 00:00:00 2001
> > From: Gyan Doshi
> > Date: Tue, 5 Dec 2017 13:17:53 +0530
> > Subject: [PAT
On Tue, Dec 05, 2017 at 11:57:07AM +, Stefan _ wrote:
> On 04.12.2017 at 18:49 Michael Niedermayer wrote:
> > will apply
> >
> > can you add a fate test for this ?
> >
> > thanks
> >
> > [...]
> Sure.
>
> I've picked a random sample where skip_loop_filter={nokey,all} had
> different output. H
On Tue, Dec 05, 2017 at 08:17:14PM +, Derek Buitenhuis wrote:
> >> The commit that broke it should be reverted until the author
> >> of that commit can explain why it changed, or fix it.
> >
> > The commit that added the test was the one that broke fate. It never
> > worked.
> > So this "sort
From: ffmpeg-devel on behalf of Steven Liu
Sent: December 4, 2017 4:52 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix for ticket 6658
(Dash demuxer segfault)
2017-12-04 12:28 GMT+08:00 Colin NG :
On Tue, Dec 05, 2017 at 11:34:12AM +0800, tiejun.peng wrote:
> 1.add warning info about corrupted atom box parsing.
> 2.atom box parsing return eof cause mov_read_close called in mov_read_header
> and user have no chance to play the file.
i think someone should cleanup the english, it sounds a bit
On 12/5/2017 11:00 PM, Jacob Trimble wrote:
> Also, can I use the flexible array member feature, it was introduced
> in C99? Would a 0-length array be better?
No, I don't think this would be OK inside a public header, unfortunately.
- Derek
___
ffmpeg-
---
libavcodec/extract_extradata_bsf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_bsf.c
index ed6509c681..d40907a675 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
On Tue, 5 Dec 2017 22:38:11 +0100
Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 8:23 PM, James Almer wrote:
> > On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
> >> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
> >>> After some tests:
> >>> 1) #undef far
> >>> after #include is wrong -- i
I am trying to playback encrypted content. I know that libavformat
handles decryption already when using clearkey, but I want to handle
the decryption myself. The encryption info is parsed in mov.c but not
exposed to the app.
This adds some structures to hold new side-data that will hold the
inf
On Mon, 4 Dec 2017, John Stebbins wrote:
On 12/03/2017 01:12 PM, Marton Balint wrote:
On Thu, 30 Nov 2017, John Stebbins wrote:
---
fftools/ffplay.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 10a917194d
On Tue, 5 Dec 2017 19:46:09 +0530
Gyan Doshi wrote:
> From 13ad80871978fe7e5837863e0e2f7b7d6b356155 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Tue, 5 Dec 2017 13:17:53 +0530
> Subject: [PATCH] avcodec/libx265 - Add named option to set profile
>
> Adds call to x265_param_apply_profile a
On 04.12.2017 at 21:06 Carl Eugen Hoyos wrote:
> 2017-12-01 0:22 GMT+01:00 Stefan _ :
>
>> Attached patch adds full support for skip_loop_filter
>> (all levels) to the hevc decoder.
> Will you also work on -skip_frame for hevc?
>
> Carl Eugen
I gave it a try. The different levels should all work c
On Tue, Dec 5, 2017 at 8:23 PM, James Almer wrote:
> On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
>> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out
>> The commit that broke it should be reverted until the author
>> of that commit can explain why it changed, or fix it.
>
> The commit that added the test was the one that broke fate. It never
> worked.
> So this "sort of" reverts what caused the issue.
Wasn't the code it tests added directly be
On 12/5/2017 8:12 AM, Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which
On Tue, Dec 05, 2017 at 01:54:27PM +, Derek Buitenhuis wrote:
> On 12/5/2017 12:38 AM, Michael Niedermayer wrote:
> > Noone is known to work on fixing this, so it should be disabled
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > tests/fate/mov.mak | 1 -
> > 1 file changed, 1 deletio
W dniu 05.12.2017 o 12:12, Hendrik Leppkes pisze:
> On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' w
On 2017-12-05 02:07, Timothy Gu wrote:
Hi,
[...]
As the Documentation maintainer, this patch LGTM. With community consensus,
this is thusly applied.
Thanks to you all.
Timothy
Thank you, Timothy, and everyone who participated in this discussion.
The end product is a small change to the do
W dniu 05.12.2017 o 17:44, James Almer pisze:
> On 12/5/2017 1:40 PM, Mateusz wrote:
>> W dniu 05.12.2017 o 15:20, James Almer pisze:
>>> On 12/4/2017 8:31 PM, Mateusz wrote:
After some tests:
1) #undef far
after #include is wrong -- in oleauto.h is declaration
WINOLEAUTAPI Var
On Tue, Dec 5, 2017 at 5:25 PM, James Almer wrote:
> On 12/5/2017 1:13 PM, Hendrik Leppkes wrote:
>> On Tue, Dec 5, 2017 at 3:20 PM, James Almer wrote:
>>> On 12/4/2017 8:31 PM, Mateusz wrote:
After some tests:
1) #undef far
after #include is wrong -- in oleauto.h is declaration
>
On 5 December 2017 at 16:40, Mateusz wrote:
> W dniu 05.12.2017 o 15:20, James Almer pisze:
> > On 12/4/2017 8:31 PM, Mateusz wrote:
> >> After some tests:
> >> 1) #undef far
> >> after #include is wrong -- in oleauto.h is declaration
> >> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR*
On 12/5/2017 1:40 PM, Mateusz wrote:
> W dniu 05.12.2017 o 15:20, James Almer pisze:
>> On 12/4/2017 8:31 PM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>>> an
W dniu 05.12.2017 o 15:20, James Almer pisze:
> On 12/4/2017 8:31 PM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which is define a
On 12/5/2017 1:13 PM, Hendrik Leppkes wrote:
> On Tue, Dec 5, 2017 at 3:20 PM, James Almer wrote:
>> On 12/4/2017 8:31 PM, Mateusz wrote:
>>> After some tests:
>>> 1) #undef far
>>> after #include is wrong -- in oleauto.h is declaration
>>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR*
On Tue, Dec 5, 2017 at 3:20 PM, James Almer wrote:
> On 12/4/2017 8:31 PM, Mateusz wrote:
>> After some tests:
>> 1) #undef far
>> after #include is wrong -- in oleauto.h is declaration
>> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
>> and 'FAR' is defined as 'far' which is de
On Mon, Dec 04, 2017 at 08:41:42PM +0100, Timo Rothenpieler wrote:
> The external headers can be found at
> https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
> ---
> configure | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
i cloned the repo referenced and did a make install
bu
On 12/4/2017 8:31 PM, Mateusz wrote:
> After some tests:
> 1) #undef far
> after #include is wrong -- in oleauto.h is declaration
> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
> and 'FAR' is defined as 'far' which is define as empty.
>
> 2) #undef near
> after #include works
On 12/5/2017 7:37 PM, Derek Buitenhuis wrote:
Patch OK with log line dropped.
Revised patch v2 attached.
Thanks,
Gyan
From 13ad80871978fe7e5837863e0e2f7b7d6b356155 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PATCH] avcodec/libx265 - Add named op
On 12/5/2017 2:05 PM, Gyan Doshi wrote:
>
> On 12/5/2017 7:21 PM, Derek Buitenhuis wrote:
>
>> This is inconsistent with the way libx264.c does it. It calls the profile
>> function before the param parsing.
>
> From http://x265.readthedocs.io/en/default/cli.html#profile-level-tier
>
> "API use
On 12/5/2017 7:21 PM, Derek Buitenhuis wrote:
This is inconsistent with the way libx264.c does it. It calls the profile
function before the param parsing.
From http://x265.readthedocs.io/en/default/cli.html#profile-level-tier
"API users must call x265_param_apply_profile() after configuring
On 12/5/2017 12:38 AM, Michael Niedermayer wrote:
> Noone is known to work on fixing this, so it should be disabled
>
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate/mov.mak | 1 -
> 1 file changed, 1 deletion(-)
*NAK*
Disabling failing tests entirely defeats the point of having test!
On 12/5/2017 9:22 AM, Gyan Doshi wrote:
> Revised patch attached.
[...]
> From bbb8013e7404360139a13b58a377a29d3ca69552 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi
> Date: Tue, 5 Dec 2017 13:17:53 +0530
> Subject: [PATCH] avcodec/libx265 - Add named option to set profile
>
> Adds call to x265_p
On 04.12.2017 at 18:49 Michael Niedermayer wrote:
> will apply
>
> can you add a fate test for this ?
>
> thanks
>
> [...]
Sure.
I've picked a random sample where skip_loop_filter={nokey,all} had
different output. Hope that's fine.
From 2f4e5bf1e37d0fbfce0631ebb8e7011b5f8128f1 Mon Sep 17 00:00:
On Tue, Dec 5, 2017 at 12:31 AM, Mateusz wrote:
> After some tests:
> 1) #undef far
> after #include is wrong -- in oleauto.h is declaration
> WINOLEAUTAPI VarUI1FromI8(LONG64 i64In, _Out_ BYTE FAR* pbOut);
> and 'FAR' is defined as 'far' which is define as empty.
Yeah generally undefing all of
Hi,
On Mon, Dec 4, 2017 at 4:43 AM Carl Eugen Hoyos wrote:
> The patch is not ok, Carl Eugen
It is clear that you have no respect for community consensus.
9 for removal of mandatory status (10 counting myself):
TR: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220272.html
PBM:
i approve
On Tue, Dec 5, 2017 at 5:22 PM, Gyan Doshi wrote:
>
> On 12/5/2017 2:33 PM, Hendrik Leppkes wrote:
>
>>
>> Please just name the option "profile" to stay consistent with all the
>> other encoders.
>>
>
> Revised patch attached.
>
> ___
> ffmpe
On 12/5/2017 2:33 PM, Hendrik Leppkes wrote:
Please just name the option "profile" to stay consistent with all the
other encoders.
Revised patch attached.
From bbb8013e7404360139a13b58a377a29d3ca69552 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PA
On Tue, Dec 5, 2017 at 6:42 AM, Jun Zhao wrote:
>
>
> On 2017/12/5 2:32, Michael Niedermayer wrote:
>> On Mon, Dec 04, 2017 at 11:07:11AM +0100, Hendrik Leppkes wrote:
>>> On Mon, Dec 4, 2017 at 10:53 AM, Moritz Barsnick wrote:
On Mon, Dec 04, 2017 at 13:02:20 +0800, Jun Zhao wrote:
> Us
I prefer option 1). and microsoft vc++ uspport __FUNCTION__
On Tue, Dec 5, 2017 at 1:42 PM, Jun Zhao wrote:
>
>
> On 2017/12/5 2:32, Michael Niedermayer wrote:
> > On Mon, Dec 04, 2017 at 11:07:11AM +0100, Hendrik Leppkes wrote:
> >> On Mon, Dec 4, 2017 at 10:53 AM, Moritz Barsnick
> wrote:
> >
what is V1 and V2?
On Tue, Dec 5, 2017 at 11:03 AM, Jun Zhao wrote:
> ping ?
>
> On 2017/11/30 7:53, Jun Zhao wrote:
> > V2: fix the V1 lead to webp crash issue.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/
On Tue, Dec 5, 2017 at 9:12 AM, Gyan Doshi wrote:
> Attached patch allows users to set x265 encoding profile.
> Addresses ticket #6894.
>
Please just name the option "profile" to stay consistent with all the
other encoders.
- Hendrik
___
ffmpeg-devel m
On 05.12.2017 01:38, Michael Niedermayer wrote:
Noone is known to work on fixing this, so it should be disabled
Signed-off-by: Michael Niedermayer
---
tests/fate/mov.mak | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 680baea773..869784fd31 10
Attached patch allows users to set x265 encoding profile.
Addresses ticket #6894.
Regards,
Gyan
From e45cd99804dab980d3441c0450b22c5b69b18474 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Tue, 5 Dec 2017 13:17:53 +0530
Subject: [PATCH] avcodec/libx265.c - Add named option to set profile
Adds
54 matches
Mail list logo
