On 4/4/18, 4:38 PM, "vdi...@akamai.com" wrote:
>
>From: Vishwanath Dixit
>
>In write only mode, the TCP receive buffer's data keeps growing with
>http response messages and the buffer eventually becomes full.
>This results in zero tcp window size, which in turn causes unwanted
>issues, like, t
On Thu, Apr 19, 2018 at 8:31 PM, James Almer wrote:
>
> > +film->sample_table[i].duration = AV_RB32(&scratch[12]);
>
> While for video tracks this field seems to report the same packet
> durations that were being calculated pre patch, this field for audio
> tracks is always 1.
>
> Before t
From: dongsheng7
Signed-off-by: dongsheng7
---
libavformat/dashdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 6304ad933b..4b845262ed 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -588,7 +588,7
Hello Sir,
I do understand that just 56 lines were inserted but sir 621 lines were
deleted which were of no use for hellosubs and it included functons like
expand_text(), expand_function() and other which were being called by the
drawtext filter but not needed by the hellosubs filter as the text a
Signed-off-by: Rostislav Pehlivanov
---
libavutil/hwcontext_opencl.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 43b5c5ae0c..1d18da37bf 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext
Used to fix unmapping when no direct interop exists between APIs.
Signed-off-by: Rostislav Pehlivanov
---
libavutil/hwcontext.c | 7 +++
libavutil/hwcontext_internal.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 70c5
The plan is to eventually be able to apply effects and encode entirely
on the GPU.
Rostislav Pehlivanov (8):
hwcontext_internal: add ff_hwframe_map_replace
hwcontext_opencl: use ff_hwframe_map_replace()
lavu: add a Vulkan hwcontext
lavfi: add common Vulkan filtering code
lavfi: add a Vul
Can convert to RGB using very fast fixed-function conversions.
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_scale_vulkan.c | 386 ++
4 fi
It tries to do something similar to it with YUV images, but RGB images
are done properly.
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfi
This commit adds a common code for use in Vulkan filters. It attempts
to ease the burden of writing Vulkan image filtering to a minimum,
which is pretty much a requirement considering how verbose the API is.
It supports both compute and graphic pipelines and manages to abstract
the API to such a l
Could be done in-plane with the main image but framesync segfaults.
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_overlay_vulkan.c | 458 +++
Signed-off-by: Rostislav Pehlivanov
---
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_avgblur_vulkan.c | 343
4 files changed, 346 insertions(+)
create mode 100644 libavfi
This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
VAAPI frames but additional functionality can be added later to support
importing of D3D11 surfaces as well as exporting to various other APIs.
This context requires the newest stable version of the Vulkan API,
and once the
---
libavformat/hlsenc.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c27a66ea79..b6260b262d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1026,26 +1026,28 @@ static int hls
This patch make ffmpeg able to create a single HLS m3u8 with different
duration in the same manifest for VOD playlist ype.
This has benefit on optimizing HLS stream to start faster, having
initially shorter duration. The later part of the
stream could have longer duration, which lower server load
On 4/20/18 2:20 AM, Ronak wrote:
> Hi,
>
> I've been testing FFMPEG's HLS fragmented MP4 options with some M4A audio
> files.
>
> I've noticed that if I ask ffmpeg to fragment an 11 minute file vs a 10 hour
> file, the byte ranges are different, even if the channel count/sampling
> rate/bit ra
On 4/20/18 9:02 AM, Steven Liu wrote:
> reference hls support fmp4 file from draft-pantos-http-live-streaming-20
> the spec describes version 7 of hls protocol
>
> Suggested-by: Ronak
> Signed-off-by: Steven Liu
> ---
> libavformat/dashenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
> On 19 Apr 2018, at 20:28, guikunzhi wrote:
>
> Signed-off-by: guikunzhi
> ---
> libavformat/dashdec.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 6304ad933b..b9f1a40dfe 100644
> --- a/libavform
reference hls support fmp4 file from draft-pantos-http-live-streaming-20
the spec describes version 7 of hls protocol
Suggested-by: Ronak
Signed-off-by: Steven Liu
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/
On 4/18/2018 4:29 PM, mi...@brew.sh wrote:
> From: Misty De Meo
>
> ---
> libavformat/segafilm.c | 20 +++-
> 1 file changed, 3 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
> index e72c26b144..1529fc385e 100644
> --- a/libavform
> On 20 Apr 2018, at 04:50, Ronak wrote:
>
> Hi,
>
> I've been testing FFMPEG's HLS fragmented MP4 options with some M4A audio
> files.
>
> I've noticed that if I ask ffmpeg to fragment an 11 minute file vs a 10 hour
> file, the byte ranges are different, even if the channel count/sampling
On Thu, Apr 19, 2018 at 01:31:33PM +0200, Hendrik Leppkes wrote:
> On Wed, Apr 18, 2018 at 11:15 PM, Michael Niedermayer
> wrote:
> > On Wed, Apr 18, 2018 at 04:09:41PM +0200, Hendrik Leppkes wrote:
> >> On Mon, Apr 16, 2018 at 1:24 PM, Michael Niedermayer
> >> wrote:
> >> > On Sat, Apr 14, 2018
From: Aman Gupta
---
libavformat/utils.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 705b79031d..c25eab4d49 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2620,7 +2620,6 @@ static void
From: Aman Gupta
Similar to 4c9c4fe8b21, but for durations. This fixes #7151, where
the report duration and bitrate on a mpegts stream is wildly off
due to the dvb_teletext stream's timings.
---
libavformat/utils.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git
On Thu, Apr 19, 2018 at 09:32:18PM +0200, Marton Balint wrote:
> The specs says that the the first color component in the color array is
> not alpha, but simply 0.
>
> Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
>
> Signed-off-by: Marton Balint
> ---
> libavformat/qtpalette.
On Thu, Apr 19, 2018 at 10:08:25PM +0200, Stephan Holljes wrote:
> On Fri, Jan 12, 2018 at 7:16 PM, Stephan Holljes
> wrote:
> > Signed-off-by: Stephan Holljes
> > ---
> > libavformat/http.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/http.c b/libavformat/http.
On Thu, Apr 19, 2018 at 01:35:20PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> Similar to 4c9c4fe8b21, but for durations. This fixes #7151, where
> the report duration and bitrate on a mpegts stream is wildly off
> due to the dvb_teletext stream's timings.
> ---
> libavformat/utils.c | 33 ++
On Fri, Apr 20, 2018 at 01:21:15AM +0200, Michael Niedermayer wrote:
> On Thu, Apr 19, 2018 at 09:32:18PM +0200, Marton Balint wrote:
> > The specs says that the the first color component in the color array is
> > not alpha, but simply 0.
> >
> > Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8
On Thu, Apr 19, 2018 at 09:32:18PM +0200, Marton Balint wrote:
> The specs says that the the first color component in the color array is
> not alpha, but simply 0.
>
> Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
>
> Signed-off-by: Marton Balint
> ---
> libavformat/qtpalette.
On Thu, Apr 19, 2018 at 09:32:19PM +0200, Marton Balint wrote:
> A pixel format which has a palette also has alpha, without this patch the
> format negotiation might have preferred formats without alpha even if the
> source had alpha.
>
> Signed-off-by: Marton Balint
> ---
> libavfilter/avfilter
From: Aman Gupta
Older iOS devices don't have a hardware HEVC decoder, but the
software decoder offered by VideoToolbox is well-optimized and
performs much better than the ffmpeg decoder.
---
libavcodec/videotoolbox.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --gi
On Thu, Apr 19, 2018 at 2:07 AM, Michael Niedermayer
wrote:
> On Tue, Jan 09, 2018 at 10:27:28AM -0800, Jacob Trimble wrote:
>> On Mon, Jan 8, 2018 at 5:39 PM, Carl Eugen Hoyos wrote:
>> > 2018-01-08 23:34 GMT+01:00 Jacob Trimble
>> > :
>> >> On Fri, Jan 5, 2018 at 3:41 PM, Carl Eugen Hoyos
>>
On Thu, 19 Apr 2018 23:25:03 +0200
Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges| 3 +++
> libavutil/pixdesc.c | 3 +--
> libavutil/pixdesc.h | 8 ++--
> libavutil/tests/pixdesc.c | 4
> libavutil/version.h | 2 +-
> 5 files ch
Signed-off-by: Marton Balint
---
fftools/ffmpeg_filter.c | 2 +-
libavcodec/ffv1enc.c| 4 ++--
libavfilter/avfiltergraph.c | 2 +-
libavutil/pixdesc.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index
Signed-off-by: Marton Balint
---
doc/APIchanges| 3 +++
libavutil/pixdesc.c | 3 +--
libavutil/pixdesc.h | 8 ++--
libavutil/tests/pixdesc.c | 4
libavutil/version.h | 2 +-
5 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/doc/APIchanges b/doc
Hi,
I've been testing FFMPEG's HLS fragmented MP4 options with some M4A audio files.
I've noticed that if I ask ffmpeg to fragment an 11 minute file vs a 10 hour
file, the byte ranges are different, even if the channel count/sampling
rate/bit rate and codec are the same.
Here's an example of w
Hi there,
I'm using ffmpeg to generate MPEG DASH & HLS content using a backing fragmented
MP4 asset, and I've noticed some inconsistencies with ffmpeg that I wasn't sure
about.
For reference, I'm running the following commands:
Generate a fMP4 backed HLS stream:
ffmpeg -i "${FILE}.mp4" -codec
On Thu, Apr 19, 2018 at 09:35:22AM -0700, Jacob Trimble wrote:
> Signed-off-by: Jacob Trimble
> ---
> libavformat/mov.c | 1 +
> 1 file changed, 1 insertion(+)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, reali
From: Aman Gupta
Similar to 4c9c4fe8b21, but for durations. This fixes #7151, where
the report duration and bitrate on a mpegts stream is wildly off
due to the dvb_teletext stream's timings.
---
libavformat/utils.c | 33 +
1 file changed, 21 insertions(+), 12 dele
On Tue, Apr 17, 2018 at 02:13:46AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 6306/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSICINVIDEO_fuzzer-5079253549842432
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On Tue, Apr 17, 2018 at 02:13:45AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/dsicinvideo.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
On Tue, Apr 17, 2018 at 02:13:44AM +0200, Michael Niedermayer wrote:
> The headers from where the dimensions are read in actual files
> are limited to 16bit per component.
>
> Fixes: Timeout
> Fixes:
> 6305/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFA_fuzzer-4824270749302784
>
> Found-b
On Fri, Jan 12, 2018 at 7:16 PM, Stephan Holljes
wrote:
> Signed-off-by: Stephan Holljes
> ---
> libavformat/http.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 4806b1e59b..537d0a4773 100644
> --- a/libavformat/http.c
> +++ b/libavf
On Wed, Apr 18, 2018 at 09:07:20PM +0200, Tomas Härdin wrote:
> tis 2018-04-17 klockan 14:24 +0200 skrev Michael Niedermayer:
> > On Tue, Apr 17, 2018 at 10:32:16AM +0200, Tomas Härdin wrote:
> > > tis 2018-04-17 klockan 02:13 +0200 skrev Michael Niedermayer:
> > > > Speeds up decoding from 8 to 3
On Thu, Apr 19, 2018 at 1:04 PM, wm4 wrote:
> On Thu, 19 Apr 2018 12:55:00 -0700
> rshaf...@tunein.com wrote:
>
> > From: Richard Shaffer
> >
> > This refactors get_cookies to simplify some code paths, specifically for
> > skipping logic in the while loop or exiting it. It also simplifies the
>
On Thu, 19 Apr 2018 12:55:00 -0700
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> This refactors get_cookies to simplify some code paths, specifically for
> skipping logic in the while loop or exiting it. It also simplifies the logic
> for appending additional values to *cookies by repla
From: Richard Shaffer
This refactors get_cookies to simplify some code paths, specifically for
skipping logic in the while loop or exiting it. It also simplifies the logic
for appending additional values to *cookies by replacing strlen/malloc/snprintf
with one call av_asnprintf.
This refactor fi
On Thu, 19 Apr 2018 21:44:36 +0200
Hendrik Leppkes wrote:
> ex
>
> On Thu, Apr 19, 2018 at 9:39 PM, wm4 wrote:
> > On Thu, 19 Apr 2018 21:32:20 +0200
> > Marton Balint wrote:
> >
> >> Signed-off-by: Marton Balint
> >> ---
> >> doc/APIchanges | 3 +++
> >> libavutil/pixdesc.h | 11 ++
On Tue, 17 Apr 2018 16:37:13 -0700
rshaf...@tunein.com wrote:
> From: Richard Shaffer
>
> This refactors get_cookies to simplify some code paths, specifically for
> skipping logic in the while loop or exiting it. It also simplifies the logic
> for appending additional values to *cookies by repla
ex
On Thu, Apr 19, 2018 at 9:39 PM, wm4 wrote:
> On Thu, 19 Apr 2018 21:32:20 +0200
> Marton Balint wrote:
>
>> Signed-off-by: Marton Balint
>> ---
>> doc/APIchanges | 3 +++
>> libavutil/pixdesc.h | 11 +++
>> libavutil/version.h | 2 +-
>> 3 files changed, 15 insertions(+), 1
On Thu, 19 Apr 2018 21:32:20 +0200
Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges | 3 +++
> libavutil/pixdesc.h | 11 +++
> libavutil/version.h | 2 +-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchange
On Tue, Apr 17, 2018 at 4:37 PM, wrote:
> From: Richard Shaffer
>
> This refactors get_cookies to simplify some code paths, specifically for
> skipping logic in the while loop or exiting it. It also simplifies the
> logic
> for appending additional values to *cookies by replacing
> strlen/malloc
Signed-off-by: Marton Balint
---
libavfilter/avfiltergraph.c | 2 +-
libavutil/pixdesc.c | 8 ++--
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index e18f733e23..1e77cc8495 100644
--- a/libavfilter/avfiltergra
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/pixdesc.h | 11 +++
libavutil/version.h | 2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4f6ac2a031..2a0b6f057a 100644
--- a/doc/APIchanges
+++ b/doc/APIch
A pixel format which has a palette also has alpha, without this patch the
format negotiation might have preferred formats without alpha even if the
source had alpha.
Signed-off-by: Marton Balint
---
libavfilter/avfiltergraph.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/l
The specs says that the the first color component in the color array is
not alpha, but simply 0.
Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
Signed-off-by: Marton Balint
---
libavformat/qtpalette.c | 12 ++--
tests/ref/lavf-fate/mov_qtrle_mace6 | 2 +-
2
On Thu, Apr 19, 2018 at 09:37:17AM -0700, Jacob Trimble wrote:
> On Thu, Apr 19, 2018 at 7:01 AM, James Almer wrote:
> > On 4/18/2018 9:42 PM, Michael Niedermayer wrote:
> >> On Wed, Apr 18, 2018 at 09:47:17AM -0700, Jacob Trimble wrote:
> >>> On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer
>
On Wed, Apr 18, 2018 at 02:45:36PM +0530, ANURAG SINGH IIT BHU wrote:
> Hello Sir,
>
> I have implemented the suggested changes, now the filter does not break
> builds, also now it works for all inputs and
You are still removing the Copyright statments from the filter you copy
--- libavfilter/vf
On Wed, Apr 18, 2018 at 04:40:28PM -0700, Rahul Chaudhry wrote:
> On Wed, Apr 18, 2018 at 3:46 PM, Michael Niedermayer
> wrote:
> > please make sure this works on apple based arm (unless you know it works)
> > (ive tested qemu linux based)
> >
> > Also please add a commit message
>
> If by 'apple
On Thu, Apr 19, 2018 at 7:01 AM, James Almer wrote:
> On 4/18/2018 9:42 PM, Michael Niedermayer wrote:
>> On Wed, Apr 18, 2018 at 09:47:17AM -0700, Jacob Trimble wrote:
>>> On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer
>>> wrote:
On Tue, Apr 03, 2018 at 04:08:51PM -0700, Jacob Trimble
Signed-off-by: Jacob Trimble
---
libavformat/mov.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index fc512b8d72..4eda48d617 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5833,6 +5833,7 @@ static int mov_read_sample_encryption_info(MOVCont
On Thu, 19 Apr 2018 17:01:56 +0200
Nicolas George wrote:
> James Almer (2018-04-19):
> > It would have not been backwards compatible in such scenario to load at
> > runtime an hypotetical 3.4.x lavf library with that change in an
> > application that was built against 3.3.x or older. Regardless o
James Almer (2018-04-19):
> It would have not been backwards compatible in such scenario to load at
> runtime an hypotetical 3.4.x lavf library with that change in an
> application that was built against 3.3.x or older. Regardless of 0 being
> defined as EOF or not in documentation, the behavior of
On Thu, 19 Apr 2018 11:47:54 -0300
James Almer wrote:
> On 4/19/2018 11:43 AM, wm4 wrote:
> > On Thu, 19 Apr 2018 16:33:47 +0200
> > Nicolas George wrote:
> >
> >> James Almer (2018-04-19):
> >>> Had it been in 3.4 it would have mean a considerable ABI breakage as
> >>> well, at least witho
On Thu, Apr 19, 2018 at 4:45 PM, wm4 wrote:
> On Thu, 19 Apr 2018 16:33:09 +0200
> Hendrik Leppkes wrote:
>
>> On Thu, Apr 19, 2018 at 12:40 PM, wm4 wrote:
>> >
>> > Regarding this patch, personally I don't think using getenv() to
>> > configure what is pretty much API semantics is acceptable. B
On 4/19/2018 11:43 AM, wm4 wrote:
> On Thu, 19 Apr 2018 16:33:47 +0200
> Nicolas George wrote:
>
>> James Almer (2018-04-19):
>>> Had it been in 3.4 it would have mean a considerable ABI breakage as
>>> well, at least without the eventual backwards compat change.
>>
>> Can you explain why you t
On 4/19/2018 11:33 AM, Nicolas George wrote:
> James Almer (2018-04-19):
>> Had it been in 3.4 it would have mean a considerable ABI breakage as
>> well, at least without the eventual backwards compat change.
>
> Can you explain why you think that?
>
> When advising on these changes and reviewing
On Thu, 19 Apr 2018 16:33:09 +0200
Hendrik Leppkes wrote:
> On Thu, Apr 19, 2018 at 12:40 PM, wm4 wrote:
> >
> > Regarding this patch, personally I don't think using getenv() to
> > configure what is pretty much API semantics is acceptable. But a new
> > API function that restricts what codecs a
On Thu, 19 Apr 2018 16:33:47 +0200
Nicolas George wrote:
> James Almer (2018-04-19):
> > Had it been in 3.4 it would have mean a considerable ABI breakage as
> > well, at least without the eventual backwards compat change.
>
> Can you explain why you think that?
>
> When advising on these cha
On 4/19/2018 11:19 AM, Derek Buitenhuis wrote:
> On 4/19/2018 11:40 AM, wm4 wrote:
>> Regarding this patch, personally I don't think using getenv() to
>> configure what is pretty much API semantics is acceptable. But a new
>> API function that restricts what codecs are used based on a string
>> arg
On Thu, Apr 19, 2018 at 12:40 PM, wm4 wrote:
>
> Regarding this patch, personally I don't think using getenv() to
> configure what is pretty much API semantics is acceptable. But a new
> API function that restricts what codecs are used based on a string
> argument might be ok. Then applications co
James Almer (2018-04-19):
> Had it been in 3.4 it would have mean a considerable ABI breakage as
> well, at least without the eventual backwards compat change.
Can you explain why you think that?
When advising on these changes and reviewing patches, I was very careful
that they do not introduce A
On Thu, Apr 19, 2018 at 4:21 PM, Derek Buitenhuis
wrote:
> On 4/18/2018 9:27 AM, Timo Rothenpieler wrote:
>> On 18.04.2018 10:05, Wang Bin wrote:
-elif $_cc -nologo- 2>&1 | grep -q Microsoft; then
+elif $_cc -nologo- 2>&1 | grep -q Microsoft || $_cc -v 2>&1 | grep -q
>>
On 4/19/2018 3:49 AM, Hendrik Leppkes wrote:
> On Thu, Apr 19, 2018 at 12:56 AM, wm4 wrote:
>> On Thu, 19 Apr 2018 00:40:21 +0200
>> Michael Niedermayer wrote:
>>
>>> On Wed, Apr 18, 2018 at 11:55:09PM +0200, Paul B Mahol wrote:
On 4/18/18, wm4 wrote:
> On Wed, 18 Apr 2018 23:15:47 +020
On 4/18/2018 9:27 AM, Timo Rothenpieler wrote:
> On 18.04.2018 10:05, Wang Bin wrote:
>>>
>>>
>>> -elif $_cc -nologo- 2>&1 | grep -q Microsoft; then
>>> +elif $_cc -nologo- 2>&1 | grep -q Microsoft || $_cc -v 2>&1 | grep -q
>>> clang && $_cc -? > /dev/null 2>&1; then
>>> _type=msvc
On 4/19/2018 11:40 AM, wm4 wrote:
> Regarding this patch, personally I don't think using getenv() to
> configure what is pretty much API semantics is acceptable. But a new
> API function that restricts what codecs are used based on a string
> argument might be ok. Then applications could use it to
On 4/18/2018 9:42 PM, Michael Niedermayer wrote:
> On Wed, Apr 18, 2018 at 09:47:17AM -0700, Jacob Trimble wrote:
>> On Tue, Apr 17, 2018 at 7:11 PM, Michael Niedermayer
>> wrote:
>>> On Tue, Apr 03, 2018 at 04:08:51PM -0700, Jacob Trimble wrote:
>>
>> Ping again. I know this is low prior
On 4/7/2018 4:33 PM, Gyan Doshi wrote:
Please first read the commit msg below, which is, I hope,
self-explanatory, but I want to note a few things.
When searching to see how this issue was addressed in the past, I saw
the recommendation was to set git global autocrlf to false. That's
inadvi
On 4/17/2018 11:09 PM, Dale Curtis wrote:
> Yes, to cross-compile on Linux you need to use llvm-ar and llvm-nm. This is
> pretty chromium specific, but you can get the gist of what's necessary from
> this Chromium change:
>
> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+
On 4/18/2018 11:08 PM, Jan Ekström wrote:
> Just an off-hand comment that given that audio frames in AAC tend to
> have 1024 samples usually (or in more general, "1028 samples is quite
> unlikely for AAC"), I'd say 1024 is correct for a duration of an AAC
> frame. Looking at the hash, the actual da
Signed-off-by: guikunzhi
---
libavformat/dashdec.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 6304ad933b..b9f1a40dfe 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -706,6 +706,7 @@ stat
On Thu, Apr 19, 2018 at 02:08:58PM +0200, Hendrik Leppkes wrote:
> On Thu, Apr 19, 2018 at 1:57 PM, Matthieu Bouron
> wrote:
> > On Wed, Apr 18, 2018 at 6:13 PM, Matthieu Bouron
> > wrote:
> >
> >> On Mon, Apr 16, 2018 at 03:53:23PM +0200, Matthieu Bouron wrote:
> >> > On Wed, Apr 11, 2018 at 3:1
On Thu, Apr 19, 2018 at 1:57 PM, Matthieu Bouron
wrote:
> On Wed, Apr 18, 2018 at 6:13 PM, Matthieu Bouron
> wrote:
>
>> On Mon, Apr 16, 2018 at 03:53:23PM +0200, Matthieu Bouron wrote:
>> > On Wed, Apr 11, 2018 at 3:14 PM, Matthieu Bouron <
>> matthieu.bou...@gmail.com>
>> > wrote:
>> >
>> > > F
On Wed, Apr 18, 2018 at 6:13 PM, Matthieu Bouron
wrote:
> On Mon, Apr 16, 2018 at 03:53:23PM +0200, Matthieu Bouron wrote:
> > On Wed, Apr 11, 2018 at 3:14 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > Fixes decoding on the Samsung Chromebook Pro which do not set the cod
On Thu, 19 Apr 2018 08:49:07 +0200
Hendrik Leppkes wrote:
> On Thu, Apr 19, 2018 at 12:56 AM, wm4 wrote:
> > On Thu, 19 Apr 2018 00:40:21 +0200
> > Michael Niedermayer wrote:
> >
> >> On Wed, Apr 18, 2018 at 11:55:09PM +0200, Paul B Mahol wrote:
> >> > On 4/18/18, wm4 wrote:
> >> > > On
On Wed, Apr 18, 2018 at 11:15 PM, Michael Niedermayer
wrote:
> On Wed, Apr 18, 2018 at 04:09:41PM +0200, Hendrik Leppkes wrote:
>> On Mon, Apr 16, 2018 at 1:24 PM, Michael Niedermayer
>> wrote:
>> > On Sat, Apr 14, 2018 at 02:04:43PM +0200, Michael Niedermayer wrote:
>> >> On Fri, Apr 13, 2018 at
On Wed, Apr 18, 2018 at 9:10 PM, Jan Ekström wrote:
> On Wed, Apr 18, 2018 at 9:37 PM, Hendrik Leppkes wrote:
>> ---
>> libavformat/tls_schannel.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
>> ind
On Thu, 19 Apr 2018 12:49:21 +0200
Nicolas George wrote:
> Hendrik Leppkes (2018-04-19):
> > Lets just fix the issues and move on, there is no point in more arguing.
>
> Thanks (and also thanks to Michael).
>
> When something has been badly designed for a long time (and this
> particular issu
Hendrik Leppkes (2018-04-19):
> Lets just fix the issues and move on, there is no point in more arguing.
Thanks (and also thanks to Michael).
When something has been badly designed for a long time (and this
particular issue predates FFmpeg: the Unix socket API itself is bad,
FFmpeg only followed
On Thu, 19 Apr 2018 12:15:07 +0200
Martin Dørum wrote:
> When a program uses FFmpeg to decode or encode media, and uses
> `avcodec_find_decoder` or `avcodec_find_encoder`, I interpret that as
> the program not caring a whole lot what AVCodec is used; it just wants
> something which can encode or
When a program uses FFmpeg to decode or encode media, and uses
`avcodec_find_decoder` or `avcodec_find_encoder`, I interpret that as
the program not caring a whole lot what AVCodec is used; it just wants
something which can encode or decode the desired format. I think it
makes sense for the user t
On Thu, 19 Apr 2018 08:49:07 +0200
Hendrik Leppkes wrote:
> On Thu, Apr 19, 2018 at 12:56 AM, wm4 wrote:
> > On Thu, 19 Apr 2018 00:40:21 +0200
> > Michael Niedermayer wrote:
> >
> >> On Wed, Apr 18, 2018 at 11:55:09PM +0200, Paul B Mahol wrote:
> >> > On 4/18/18, wm4 wrote:
> >> > > On
On Thu, 19 Apr 2018 02:19:06 +0200
Michael Niedermayer wrote:
> On Thu, Apr 19, 2018 at 12:56:05AM +0200, wm4 wrote:
> > On Thu, 19 Apr 2018 00:40:21 +0200
> > Michael Niedermayer wrote:
> >
> > > On Wed, Apr 18, 2018 at 11:55:09PM +0200, Paul B Mahol wrote:
> > > > On 4/18/18, wm4 wrote:
On Wed, Apr 18, 2018 at 11:08 AM, Hendrik Leppkes wrote:
> On Thu, Feb 1, 2018 at 11:52 AM, Alexander Bilyak
> wrote:
>> When using clang-cl it expects parameters passed in MSVC-style, so
>> appropriate toolchain should be selected.
>> As soon as both clang and clang-cl report themselfs as "clan
On Tue, Jan 09, 2018 at 10:27:28AM -0800, Jacob Trimble wrote:
> On Mon, Jan 8, 2018 at 5:39 PM, Carl Eugen Hoyos wrote:
> > 2018-01-08 23:34 GMT+01:00 Jacob Trimble
> > :
> >> On Fri, Jan 5, 2018 at 3:41 PM, Carl Eugen Hoyos
> >> wrote:
> >>> 2018-01-05 23:58 GMT+01:00 Jacob Trimble
> >>> :
>
On Wed, Apr 18, 2018 at 4:57 PM, Hendrik Leppkes wrote:
> On Wed, Apr 18, 2018 at 4:34 PM, Hendrik Leppkes wrote:
>> Without properly grouping the checks, the second test would execute for
>> MSVC cl.exe, which results in configure getting stuck since cl.exe -? is
>> an interactive paginated help
96 matches
Mail list logo
