---
libavformat/Makefile | 2 +-
libavformat/hlsenc.c | 115 +++---
libavformat/hlsplaylist.c | 138 ++
libavformat/hlsplaylist.h | 51 +
4 files changed, 211 insertions(+), 95 deletions(-)
cr
On 11/25/17, 9:16 AM, "Karthick J" wrote:
>---
> libavformat/Makefile | 2 +-
> libavformat/hlsenc.c | 115 +++---
> libavformat/hlsplaylist.c | 138 ++
> libavformat/hlsplaylist.h | 51 +
> 4 fil
On 11/29/17, Rostislav Pehlivanov wrote:
> On 28 November 2017 at 19:55, Paul B Mahol wrote:
>
>> Decreases artifacts.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/mlpenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlp
On 2017-11-29 05:11, Mark Reid wrote:
@@ -980,7 +980,7 @@ static void mxf_write_structural_component(AVFormatContext
*s, AVStream *st, MXF
// write uid
mxf_write_local_tag(pb, 16, 0x3C0A);
-mxf_write_uuid(pb, package->type == MaterialPackage ? SourceClip: SourceClip
+ TypeBo
On 2017-11-29 05:11, Mark Reid wrote:
---
libavformat/mxf.h| 1 +
libavformat/mxfenc.c | 42 +++---
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 2d5b44943b..ffcc429a8b 100644
--- a/libavfor
Le mer. 22 nov. 2017 à 17:54, Michael Niedermayer
a écrit :
> On Wed, Nov 22, 2017 at 10:24:30AM +, Marc-Antoine ARNAUD wrote:
> > New patch version which fixe the last remark.
> >
> >
> > Le ven. 10 nov. 2017 à 00:47, Michael Niedermayer >
> > a écrit :
> >
> > > On Thu, Nov 09, 2017 at 10:
Where can i find the v6 2/2 ?
> 在 2017年11月29日，16:52，Karthick J 写道：
>
> ---
> libavformat/Makefile | 2 +-
> libavformat/hlsenc.c | 115 +++---
> libavformat/hlsplaylist.c | 138 ++
> libavformat/hlsplaylist.h |
On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
> +if (type == AV_HWDEVICE_TYPE_NONE) {
> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
> +fprintf(stderr, "Available device types:");
> +type = AV_HWDEVICE_TYPE_NONE;
> +while((type
Am 29.11.2017 um 13:22 schrieb Moritz Barsnick:
On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
+if (type == AV_HWDEVICE_TYPE_NONE) {
+fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
+fprintf(stderr, "Available device types:");
+type = AV_
On 11/29/17, 5:16 PM, "刘歧" wrote:
>
>Where can i find the v6 2/2 ?
Patch 2/2 didn’t change since v4.
So didn’t repost it. You have to use v4 2/2.
I am sorry. I was not sure what is the normal practice here. I didn’t repost
it, so that the people don’t waste time in re-reviewing it.
Is it custom
This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
doc/muxers.texi | 3 ++
libavformat/Makefile | 2 +-
libavformat/dashenc.c | 103 --
3 files ch
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 38 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_fillborders.c | 277 +++
4 files changed, 317 insertions(+)
create mode 100644 libavfilter
2017-11-29 13:41 GMT+01:00 Timo Rothenpieler :
> Am 29.11.2017 um 13:22 schrieb Moritz Barsnick:
>>
>> On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
>>>
>>> +if (type == AV_HWDEVICE_TYPE_NONE) {
>>> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
>>> +
Hello,
maybe this isn't the correct mail address.
We want to integrate ffmpeg.exe in our application to convert an MP4 to an low
resolution MP4 and a view file in JPEG format.
On https://ffmpeg.org/legal.html we only find a License Compliance Check if we
compile FFmpeg and bind against the DLL.
2017-11-29 14:12 GMT+01:00 Werner Schindler :
> maybe this isn't the correct mail address.
There is a user mailing list for such questions.
If you do not distribute FFmpeg yourself, there
may be no issue (only distribution and warranty
are limited), in any case, ask your lawyer.
[...]
> This e
Paul B Mahol (2017-11-29):
> +Fill borders of the input video.
Am I missing something or are you proposing 277 lines of code for
something that drawbox or crop+pad can already do?
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel
On Tue, Nov 28, 2017 at 22:42:59 -0300, James Almer wrote:
> Subject: avformat/avc: return an error in ff_isom_write_avcc if the buffer
> lenght is too small
^
length
> -if (len > 6) {
> +if (len < 6)
> +
2017-11-29 22:05 GMT+08:00 Steven Liu :
> 2017-11-29 20:48 GMT+08:00 Karthick J :
>> This is to take full advantage of Common Media Application Format.
>> Now server can generate one content and serve both HLS and DASH players.
>> ---
>> doc/muxers.texi | 3 ++
>> libavformat/Makefile |
2017-11-29 20:48 GMT+08:00 Karthick J :
> This is to take full advantage of Common Media Application Format.
> Now server can generate one content and serve both HLS and DASH players.
> ---
> doc/muxers.texi | 3 ++
> libavformat/Makefile | 2 +-
> libavformat/dashenc.c | 103
> +++
2017-11-29 20:40 GMT+08:00 Jeyapal, Karthick :
> On 11/29/17, 5:16 PM, "刘歧" wrote:
>>
>>Where can i find the v6 2/2 ?
> Patch 2/2 didn’t change since v4.
> So didn’t repost it. You have to use v4 2/2.
>
> I am sorry. I was not sure what is the normal practice here. I didn’t repost
> it, so that t
On Wed, Nov 29, 2017 at 13:41:29 +0100, Timo Rothenpieler wrote:
> Am 29.11.2017 um 13:22 schrieb Moritz Barsnick:
> > On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
> >> +if (type == AV_HWDEVICE_TYPE_NONE) {
> >> +fprintf(stderr, "Device type %s is not supported.\n", argv
On 11/29/2017 11:09 AM, Moritz Barsnick wrote:
> On Tue, Nov 28, 2017 at 22:42:59 -0300, James Almer wrote:
>> Subject: avformat/avc: return an error in ff_isom_write_avcc if the buffer
>> lenght is too small
>
> ^ lengt
On Wed, Nov 29, 2017 at 13:56:08 +0100, Paul B Mahol wrote:
> +@section fillborders
> +
> +Fill borders of the input video.
Nice, but isn't this something the drawbox filter could be enhanced to
do?
> +fill blank pixels
Does this mean "fill with blank pixels"? Does this imply transparency?
(Sorr
On Mon, 27 Nov 2017 20:46:00 -0800
Philip Langdale wrote:
> If hardware acceleration is implemented through an HWAccel, then it's
> easy to recognise, but some hardware implementations are best suited
> to implementation as full decoders, and these are not easy to identify.
> Clients typically ne
On Tue, 28 Nov 2017 00:43:25 +
Mark Thompson wrote:
> ...
>
> Ok; done, plus some trivial testing to make sure it works. If you're happy
> with this and noone else says anything then I'll push it tomorrow.
>
> Relatedly: your name on patches does not match your full name - I've
> preserv
On Mon, 27 Nov 2017 23:46:30 -0800, Jim DeLaHunt
wrote:
> On 2017-11-27 15:00, Carl Eugen Hoyos wrote:
> > 2017-11-26 22:44 GMT+01:00 Jim DeLaHunt :
> >> So, how realistic is this concern about non-subscribers sending
> >> patches to
> >> ffmpeg-devel? Does it actually happen?
> > This is very
On Mon, 27 Nov 2017 02:15:12 +
"Mironov, Mikhail" wrote:
> Hi,
> I would like to summarize thoughts on several threads on this forum related
> to the issue of including AMD/AMF header file into FFmpeg source tree.
> It looks like they reflect some policies formal or informal.
> Mark tried t
On Tue, 28 Nov 2017 16:09:57 +
"Mironov, Mikhail" wrote:
> >
> > Pavel Koshevoy (2017-11-27):
> > > That is unnecessarily un-diplomatic and will likely offend the
> > > contributors from nvidia and amd.
> >
> > Well, I find offensive that they benefit from my work yet make extra efforts
2017-11-29 15:58 GMT+01:00 wm4 :
> Well, don't worry too much. People like him are, as some would say,
> toxic members of the community. Frequent drama and flame wars happen.
> (And here's where I wished ffmpeg were a properly managed project.)
Look who's talking!
Given that you started a fork o
On 11/29/17, Nicolas George wrote:
> Paul B Mahol (2017-11-29):
>> +Fill borders of the input video.
>
> Am I missing something or are you proposing 277 lines of code for
> something that drawbox or crop+pad can already do?
By careful patch examination, one can find out that filter provides
addit
On 11/29/17, Moritz Barsnick wrote:
> On Wed, Nov 29, 2017 at 13:56:08 +0100, Paul B Mahol wrote:
>> +@section fillborders
>> +
>> +Fill borders of the input video.
>
> Nice, but isn't this something the drawbox filter could be enhanced to
> do?
Nope.
>
>> +fill blank pixels
>
> Does this mean "
>
> > +{ AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
>
> Wut, really? It's not a typo? It looks tricky.
>
> I assume AMF has D3D11 input, but then it'd still need to exclude P010.
> I don't think this is ever done, and sending a P010 frame probably
> crashes the thing?
>
> > +};
There is a
On 11/29/17, Carl Eugen Hoyos wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
>> Well, don't worry too much. People like him are, as some would say,
>> toxic members of the community. Frequent drama and flame wars happen.
>> (And here's where I wished ffmpeg were a properly managed project.)
>
> Look
This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
doc/muxers.texi | 3 ++
libavformat/Makefile | 2 +-
libavformat/dashenc.c | 103 --
3 files ch
From: Karthick Jeyapal
---
libavformat/hlsenc.c | 7 +--
libavformat/hlsplaylist.h | 5 +
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f63b08d..cdfbf45 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@
On 11/29/17, 7:43 PM, "Steven Liu" wrote:
>> +target_duration = lrint((double) target_duration / timescale);
>What value will set when the target_duration is 1.023 ? I think we
>have talk about the value and the specification describe the standard
>process way.
>You can move the functio
On Wed, 29 Nov 2017 15:58:29 +0100, wm4 wrote:
> On Tue, 28 Nov 2017 16:09:57 +
> "Mironov, Mikhail" wrote:
> >
> > I wanted to stay out of license issues and this forum is oriented more
> > towards
> > technical discussion but I can't resist putting my two cents: Yes, HW
> > manufacture
webm usually has invisible superframes merged with normal frames.
(vpxenc muxes them in this form, which is evidence enough that this is
the standard webm packet format. It's rather unclear whether ffmpeg is
even allowed to remux them with split packets.)
The vp9 decoder needs them to be in separa
On Wed, 29 Nov 2017 15:13:01 +
"Mironov, Mikhail" wrote:
> >
> > > +{ AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
> >
> > Wut, really? It's not a typo? It looks tricky.
> >
> > I assume AMF has D3D11 input, but then it'd still need to exclude P010.
> > I don't think this is ever don
On Wed, 29 Nov 2017 16:07:36 +0100
Carl Eugen Hoyos wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
> > Well, don't worry too much. People like him are, as some would say,
> > toxic members of the community. Frequent drama and flame wars happen.
> > (And here's where I wished ffmpeg were a properly
On 11/29/2017 12:24 PM, wm4 wrote:
> webm usually has invisible superframes merged with normal frames.
> (vpxenc muxes them in this form, which is evidence enough that this is
> the standard webm packet format. It's rather unclear whether ffmpeg is
> even allowed to remux them with split packets.)
On Wed, 29 Nov 2017 10:23:54 -0500
Compn wrote:
> On Wed, 29 Nov 2017 15:58:29 +0100, wm4 wrote:
>
> > On Tue, 28 Nov 2017 16:09:57 +
> > "Mironov, Mikhail" wrote:
> > >
> > > I wanted to stay out of license issues and this forum is oriented more
> > > towards
> > > technical discussi
On Wed, 29 Nov 2017 16:16:12 +0100, Paul B Mahol
wrote:
> On 11/29/17, Carl Eugen Hoyos wrote:
> > 2017-11-29 15:58 GMT+01:00 wm4 :
> >
> >> Well, don't worry too much. People like him are, as some would say,
> >> toxic members of the community. Frequent drama and flame wars happen.
> >> (And he
On Wed, Nov 29, 2017 at 4:07 PM, Carl Eugen Hoyos wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
>> Well, don't worry too much. People like him are, as some would say,
>> toxic members of the community. Frequent drama and flame wars happen.
>> (And here's where I wished ffmpeg were a properly managed
From: Karthick Jeyapal
---
libavformat/hlsenc.c | 7 +--
libavformat/hlsplaylist.h | 5 +
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f63b08d..cdfbf45 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@
This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
doc/muxers.texi | 3 ++
libavformat/Makefile | 2 +-
libavformat/dashenc.c | 110 +++---
3 files ch
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: November 29, 2017 10:16 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
>
> On 11/29/17, Carl Euge
Please ignore the below patch and use v2.
Sorry for the inconvenience.
Regards,
Karthick
On 11/29/17, 8:47 PM, "Karthick J" wrote:
This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
doc/muxers.texi
On Wed, 29 Nov 2017 15:45:28 +, "Mironov, Mikhail"
wrote:
> May I suggest to go down to business of enabling HW encoders by default?
> Yesterday Mark submitted the initial implementation and I really want
> to thank him for his mentoring and participation - it was very useful.
> Question is:
On Wed, 29 Nov 2017 15:45:28 +
"Mironov, Mikhail" wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Paul B Mahol
> > Sent: November 29, 2017 10:16 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
We did this for the sake of the decoder. With the vp9 change, it's not
necessary anymore.
---
libavcodec/vp9_parser.c | 127 --
libavformat/hlsplaylist.h | 4 +-
2 files changed, 12 insertions(+), 119 deletions(-)
diff --git a/libavcodec/vp9_parser.
On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp wrote:
> On 27.11.2017 17:14, Pavel Koshevoy wrote:
>> Personally, I would prefer if the bundled external headers were
>> installed together with ffmpeg public headers (so nvenc/cuda/etc...
>> weren't simply private headers within ffmpeg). There ar
On Wed, 29 Nov 2017 09:09:14 -0700
Pavel Koshevoy wrote:
> On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp wrote:
> > On 27.11.2017 17:14, Pavel Koshevoy wrote:
>
>
>
> >> Personally, I would prefer if the bundled external headers were
> >> installed together with ffmpeg public headers (so nv
On Wed, 29 Nov 2017 16:24:42 +0100
wm4 wrote:
> webm usually has invisible superframes merged with normal frames.
> (vpxenc muxes them in this form, which is evidence enough that this is
> the standard webm packet format. It's rather unclear whether ffmpeg is
> even allowed to remux them with spl
On Wed, Nov 29, 2017 at 5:24 PM, wm4 wrote:
>
> What really irks me is that nvidia is not giving us any support for
> supporting their stuff. AFAIK the current headers are the last MIT
> licensed ones, and future headers are closed?
No, thats not how it is. They re-licensed the video related head
On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes wrote:
> On Wed, Nov 29, 2017 at 5:24 PM, wm4 wrote:
> >
> > What really irks me is that nvidia is not giving us any support for
> > supporting their stuff. AFAIK the current headers are the last MIT
> > licensed ones, and future headers are clo
On Wed, Nov 29, 2017 at 03:51:34AM +, Rostislav Pehlivanov wrote:
> On 28 November 2017 at 20:23, Michael Niedermayer
> wrote:
>
> > On Mon, Nov 27, 2017 at 04:30:19AM +, Rostislav Pehlivanov wrote:
> > > Atomics were entirely pointless and did nothing but slow and complicate
> > > the pr
On 28.11.2017 10:25, Timo Rothenpieler wrote:
Your use-case looks like an argument for moving the external headers
into some separate repository. Not that I personally care much about
bundling or not bundling. To me the more important question seems to
be whether to auto-enable the encoders/dec
Am 29.11.2017 um 17:40 schrieb wm4:
On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes wrote:
On Wed, Nov 29, 2017 at 5:24 PM, wm4 wrote:
What really irks me is that nvidia is not giving us any support for
supporting their stuff. AFAIK the current headers are the last MIT
licensed ones, and
On Wed, 29 Nov 2017 17:42:05 +0100
Timo Rothenpieler wrote:
> Am 29.11.2017 um 17:40 schrieb wm4:
> > On Wed, 29 Nov 2017 17:27:01 +0100
> > Hendrik Leppkes wrote:
> >
> >> On Wed, Nov 29, 2017 at 5:24 PM, wm4 wrote:
> >>>
> >>> What really irks me is that nvidia is not giving us any suppo
Yeah, I understand that. But the function loading should make only a
small part of it, and could just be a normal source file. (We do
ad-hoc function loading for a lot of other stuff too.)
Then we could depend on external, unmodified SDK headers, which someone
could extract to a git repo, to avoi
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of wm4
> Sent: November 29, 2017 11:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] AMD external header
>
> On Wed, 29 Nov 2017 15:45:28 +
> "Mironov, Mikhail" wrote:
>
>
>
> It also should be made clear that nvidia does not somehow receive preferred
> treatment over other vendors.
Respectfully, but it does by inaction.
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listi
Paul B Mahol (2017-11-29):
> Nope.
Well, then learn how to write documentation.
Regards,
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, 29 Nov 2017 18:10:49 +
"Mironov, Mikhail" wrote:
> >
> > It also should be made clear that nvidia does not somehow receive preferred
> > treatment over other vendors.
>
> Respectfully, but it does by inaction.
> Thanks,
> Mikhail
Not really. Intel has the best hardware transcodin
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 4
libavfilter/vf_tile.c | 12 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..4eb302448b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14637,
Paul B Mahol (2017-11-29):
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 4
> libavfilter/vf_tile.c | 12 +++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4a4efc70c8..4eb302448b 100644
> --- a/doc/f
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 40 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_fillborders.c | 277 +++
4 files changed, 319 insertions(+)
create mode 100644 libavfilte
Hello Derek,
Comments inline.
>>
>> +afd[0] = pkt->hdr.payload[0] >> 3;
>> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
>> +av_free(afd);
>
> Is there a reason we shouldn't fail hard here?
Not really. The parser will log an error if the callback retu
On Wed, 29 Nov 2017 18:06:46 +, "Mironov, Mikhail"
wrote:
> This was a suggestion in one of the posts, not my idea. I personally would
> prefer to include headers.
i also prefer including headers into ffmpeg. only for the big 3 intel
amd and nvidia... unless something else comes along i hav
Hello James,
Thanks for reviewing.
>> +afd[0] = pkt->hdr.payload[0] >> 3;
>> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
>> +av_free(afd);
>
> For this, av_packet_new_side_data() seems more adequate than av_malloc()
> + av_packet_add_side_data().
>
>
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 5 +
libavfilter/vf_tile.c | 16 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..ec37b9dcb8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1
On Tue, Nov 28, 2017 at 4:32 PM, Michael Niedermayer wrote:
>
>
> This breaks converting of this:
> ./ffmpeg -i bgc.sub.dub.ogm -vf subtitles=bgc.sub.dub.ogm -an file.avi
>
> https://samples.ffmpeg.org/ogg/bgc.sub.dub.ogm
>
>
That's due to the vorbis parser returning AVERROR_INVALIDDATA here, wit
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Compn
> Sent: November 29, 2017 2:17 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
>
> On Wed, 29 Nov 2017 18:06:46 +
Mironov, Mikhail (2017-11-29):
> Now we have seven people not counting me
I suggest we weight this based on how often people voicing an opinion
need to run git grep.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpe
On 11/29/2017 7:17 PM, Devin Heitmueller wrote:
>> Is there a reason we shouldn't fail hard here?
>
> Not really. The parser will log an error if the callback returns a nonzero
> value, but beyond the return value isn’t actively used. That said, no
> objection to having it return -1 for clarit
TwoLAME and OpenAL both provide .pc files, so
add checks to allow pkg-config/pkgconf to
handle that.
I tried to keep the existing checks in place
instead of replacing them with the pkg-config
version. Hopefully I set it up correctly
so the old checks aren't unreachable now.
Stephen Hutchinson (2
---
configure | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 4e7254eaeb..3c08125da3 100755
--- a/configure
+++ b/configure
@@ -5888,7 +5888,9 @@ enabled libssh&& require_pkg_config libssh
libssh libssh/sftp.h sftp
enabled libspeex
---
configure | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 3c08125da3..141c8b742f 100755
--- a/configure
+++ b/configure
@@ -5952,11 +5952,13 @@ enabled mmal && { check_lib mmal
interface/mmal/mmal.h mmal_port_co
Dear Mark,
On Wed, Nov 29, 2017 at 4:11 AM, Mark Reid wrote:
> @@ -1445,12 +1463,13 @@ static int
> mxf_write_header_metadata_sets(AVFormatContext *s)
> AVDictionaryEntry *entry = NULL;
> AVStream *st = NULL;
> int i;
> -
> -MXFPackage packages[2] = {};
> +MXFPackage packa
On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson wrote:
> ---
> configure | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/configure b/configure
> index 3c08125da3..141c8b742f 100755
> --- a/configure
> +++ b/configure
> @@ -5952,11 +5952,13 @@ enabled mmal
On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson wrote:
> ---
> configure | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 4e7254eaeb..3c08125da3 100755
> --- a/configure
> +++ b/configure
> @@ -5888,7 +5888,9 @@ enabled libssh
On 2017-11-29 06:53, Compn wrote:
[...]
Also, someone once observed that common sense is not very common. :-)
sure, but please remember the DOCS are already quite verbose, and
brevity is the soul of wit. so if you can say more with less verbiage
that would be great.
[...]
Also please note that
On 11/29/2017 5:57 PM, Hendrik Leppkes wrote:
> On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson wrote:
>> ---
>> configure | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 4e7254eaeb..3c08125da3 100755
>> --- a/configure
>> +++ b/co
On 11/29/2017 6:11 PM, James Almer wrote:
> On 11/29/2017 5:57 PM, Hendrik Leppkes wrote:
>> On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson wrote:
>>> ---
>>> configure | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 4e7254eae
On Mon, Nov 27, 2017 at 02:56:32PM +0800, Pan Bian wrote:
> In function sami_paragraph_to_ass(), the return value of av_strdup() is
> not checked. To avoid potential NULL dereference, the return value
> should be checked against NULL.
>
> Signed-off-by: Pan Bian
> ---
> V2: fix patcheck warnings
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 4
libavfilter/vf_stereo3d.c | 35 ---
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..e8da5e21a6 100644
--- a/doc/filters.texi
+
On 11/29/17, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 4
> libavfilter/vf_stereo3d.c | 35 ---
> 2 files changed, 36 insertions(+), 3 deletions(-)
>
This breaks if one uses other filters right after this one.
Is
---
libavcodec/vaapi_encode_h264.c | 48 --
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 5fd0bf7796..6940823b8e 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcod
Also fixes the default, which previously contained a nonsense value.
---
On 29/11/17 03:51, Li, Zhong wrote:
>> On 28/11/17 07:46, Ruiling Song wrote:
>>> Signed-off-by: Ruiling Song
>>> ---
>>> libavcodec/vaapi_encode_h265.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff
On 29/11/17 12:22, Moritz Barsnick wrote:
> On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
>> +if (type == AV_HWDEVICE_TYPE_NONE) {
>> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
>> +fprintf(stderr, "Available device types:");
>> +type
V2: fix the V1 lead to webp crash issue.
From b943c2814789288d09b4032fa6cdfbc3fd672a2b Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Wed, 29 Nov 2017 10:22:03 +0800
Subject: [PATCH V2] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution
change.
Use the following command to reproduce this
On 29/11/17 00:48, Jun Zhao wrote:
> On 2017/11/29 8:34, Mark Thompson wrote:
>> This removes all remaining device-type specificity.
>> ---
>> doc/examples/hw_decode.c | 55
>>
>> 1 file changed, 23 insertions(+), 32 deletions(-)
>>
>> diff --git a
On Wed, Nov 29, 2017 at 11:28:40AM +, Marc-Antoine ARNAUD wrote:
> Le mer. 22 nov. 2017 à 17:54, Michael Niedermayer
> a écrit :
>
> > On Wed, Nov 22, 2017 at 10:24:30AM +, Marc-Antoine ARNAUD wrote:
> > > New patch version which fixe the last remark.
> > >
> > >
> > > Le ven. 10 nov. 201
On Tue, Nov 28, 2017 at 10:43:03PM -0300, James Almer wrote:
> Addresses ticket #6864
>
> Signed-off-by: James Almer
> ---
> I don't have the h264 in isobmff spec at hand, so i just looked at what
> the h264_mp4toannexb bsf does to handle more than one sps and pps and
> worked with that.
> If the
On Tue, Nov 28, 2017 at 10:43:02PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/avc.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index 7542db684b..6ef6e08778 100644
> --- a/libavformat/
On 11/29/2017 3:58 PM, Hendrik Leppkes wrote:
The same applies here as with twolame, we don't really want to
duplicate all sorts of checks, so if pkg-config has been available for
a sufficiently long time, then just use it always.
Ok. TwoLAME is pretty clear-cut, but OpenAL raises more questi
2017-11-29 16:42 GMT+01:00 Hendrik Leppkes :
> On Wed, Nov 29, 2017 at 4:07 PM, Carl Eugen Hoyos wrote:
>> 2017-11-29 15:58 GMT+01:00 wm4 :
>>
>>> Well, don't worry too much. People like him are, as some would say,
>>> toxic members of the community. Frequent drama and flame wars happen.
>>> (And
On Tue, Nov 28, 2017 at 04:49:46PM -0800, Steven Robertson wrote:
> The existing logic overrides container metadata even in cases where the
> container metadata must be trusted (e.g. HDR). The original spec had no
> provision for specifying color volume, so many files rely on the
> assumption of Re
2017-11-29 16:30 GMT+01:00 wm4 :
> You won't hear any lies from me.
That's too good to be true;-(
> But it's well known that you twist the
> truth whenever it fits you.
I finally realize that you staying anonymous to get away
with defamation.
Thank you for the explanation, Carl Eugen
_
1 - 100 of 118 matches
Mail list logo
