On Sun, Nov 26, 2017 at 8:44 PM Rostislav Pehlivanov
wrote:
> @@ -103,8 +104,7 @@ static int default_lockmgr_cb(void **arg, enum
> AVLockOp op)
> case AV_LOCK_DESTROY:
> if (*mutex)
> pthread_mutex_destroy(*mutex);
> -av_free(*mutex);
> -avpriv_atomic_pt
discard corrupted track and good track have chance to play.
Signed-off-by: tiejun.peng
---
libavformat/mov.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index c901859..5c2ce39 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov
On 11/30/17, 8:47 AM, "Steven Liu" wrote:
[..]
>Patchset pushed
Thanks.
>
>
>Thanks
regards,
Karthick
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Nov 29, 2017 at 8:19 PM, Mark Reid wrote:
>
>
> On Wed, Nov 29, 2017 at 12:56 PM, Matthias Troffaes <
> matthias.troff...@gmail.com> wrote:
>
>> 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
On Wed, Nov 29, 2017 at 12:56 PM, Matthias Troffaes <
matthias.troff...@gmail.com> wrote:
> 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;
>
On Wed, Nov 29, 2017 at 1:36 AM, Tomas Härdin wrote:
> 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_uui
On Wed, Nov 29, 2017 at 7:40 PM, Neil Birkbeck
wrote:
>
>>
>> If you are searching for a case where the patch makes a difference
>> one is:
>> ./ffmpeg -i ~/tickets/4493/AVCI100.mov out.nut
>> file should be here:
>> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/
>>
>> if you want more cas
>
>
>
> If you are searching for a case where the patch makes a difference
> one is:
> ./ffmpeg -i ~/tickets/4493/AVCI100.mov out.nut
> file should be here:
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/
>
> if you want more cases that change, ill see if i can find more
>
Perfect, thanks
On 11/29/2017 9:58 PM, Michael Niedermayer wrote:
> 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 m
On 11/29/2017 10:12 PM, Michael Niedermayer wrote:
> 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
On Tue, Nov 28, 2017 at 05:14:37PM -0800, Neil Birkbeck wrote:
> On higher bit depth YUV inputs with range metadata signaled as PC/full levels,
> this change makes the results of scaling without explicitly
> setting the input range on vf_scale as if it were explicitly set.
>
> For example, the res
2017-11-29 23:44 GMT+08:00 Karthick J :
> 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
On Wed, 29 Nov 2017 23:15:44 +0100
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(-)
>
> diff --git a/doc/filters.texi b/doc/fi
On Thu, 30 Nov 2017 02:41:44 +0100
Carl Eugen Hoyos wrote:
> 2017-11-29 16:30 GMT+01:00 wm4 :
>
> > You won't hear any lies from me.
>
> That's too good to be true;-(
So you admit you're denying the truth because the truth hurts you?
That's pretty hilarious, but entirely consistent with your
On Wed, Nov 29, 2017 at 01:06:06PM -0800, Jim DeLaHunt wrote:
> 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 s
2017-11-29 23:46 GMT+01:00 Paul B Mahol :
> 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 break
On Wed, Nov 29, 2017 at 11:57:17AM -0800, Dale Curtis wrote:
> 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.og
2017-11-29 21:57 GMT+01:00 Hendrik Leppkes :
> 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/con
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
_
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: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 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
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 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 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 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
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 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
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
---
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
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
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 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
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 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 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 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 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
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
---
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
---
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
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
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
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
> -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 +
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
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
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().
>
>
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 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
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
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 | 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,
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
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
>
> 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
> -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:
>
>
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
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
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, 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 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 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 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, 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 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
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 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>
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:
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
> -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
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
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 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
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, 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 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 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 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
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: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
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
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 | 103 --
3 files ch
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
>
> > +{ 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, 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 "
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
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 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
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 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 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 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 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 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: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
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
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
> +++
1 - 100 of 118 matches
Mail list logo
