> On Jun 8, 2016, at 11:03 PM, Neil Birkbeck wrote:
>
> The most recent patch should still apply cleanly (unless we have a
> better way to set these elements). Thanks
There are specific mastering metadata elements as recently defined in the
Matroska specification [1]. It would be better to use
On Tue, Jun 7, 2016 at 5:42 AM, Michael Niedermayer
wrote:
> On Wed, Jun 01, 2016 at 12:03:32PM +0800, XinZheng Zhang wrote:
>> On Tue, May 31, 2016 at 9:33 PM, Hendrik Leppkes wrote:
>> >
>> > On Tue, May 31, 2016 at 2:58 PM, Xinzheng Zhang
>> > wrote:
>> > > ---
>> > > libavformat/tcp.c | 21
The most recent patch should still apply cleanly (unless we have a
better way to set these elements). Thanks
On Tue, Apr 19, 2016 at 8:12 AM, Neil Birkbeck wrote:
> Updated patch attached.
>
> On Sat, Apr 16, 2016 at 7:08 PM, Michael Niedermayer
> wrote:
>> On Sun, Apr 03, 2016 at 03:38:33PM -07
Fixes: Ticket5297
Needs review by maintainer / author to check that this is ok and sufficient
---
libavcodec/alsdec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
index a7e58a2..9410f52 100644
--- a/libavcodec/alsdec.c
Hi, I took the time to investigate it and I find a few bugs which I'm
attaching a patch for them.
Yet I'm not convinced that it is a definitive fix, since the output of
swscale-test differs in some cases when scaling the whole frame or in
slices.
Also there is a few fixes needed in this patch which
On 06/08, Will Kelleher wrote:
>
> That works for me. I can update the patch with that warning. Thanks!
>
Updated patch attached.
>From 3229edf9e52dfd61580209630f20ddef3e39e78e Mon Sep 17 00:00:00 2001
From: Will Kelleher
Date: Tue, 7 Jun 2016 20:49:48 -0500
Subject: [PATCH] vaapi_encode: expl
On 06/08, Mark Thompson wrote:
> On 08/06/16 21:02, Will Kelleher wrote:
> > On 06/08, Mark Thompson wrote:
> >> On 08/06/16 18:23, Will Kelleher wrote:
> >>> Hi all -
> >>>
> >>> I'm experiencing some significant heap growth when encoding with VAAPI on
> >>> my Ivy Bridge hardware. Based on what
On 09.06.2016 00:25, Michael Niedermayer wrote:
> On Thu, Jun 02, 2016 at 02:29:47PM +0200, Camille Gonnet wrote:
>> When writing files to FTP, if the data connection is closed before the
>> control connection, the server may handle it as an aborted file transfer
>> and create and leave the file em
On Thu, Jun 02, 2016 at 02:29:47PM +0200, Camille Gonnet wrote:
> When writing files to FTP, if the data connection is closed before the
> control connection, the server may handle it as an aborted file transfer
> and create and leave the file empty.
which ftp server, or is that in the RFC, if so
On 08/06/2016 06:34 p.m., Marton Balint wrote:
Hi All,
Please comment, thanks,
Be careful that : in Windows do not currently parse well if you need to
use them in a path, like F:/filter/ or Z:/movie. They are parsed as F
and /filter/ and Z and /movie/ respectively.
Hi All,
My GSOC student Jan is working on improving the tee muxer, and as a side
project he is also working on converting the tee muxer to the new BSF API.
I have checked his WIP patches, and it seems to me that developing some
API which we can use for BSF chains would be really useful not on
From: Matthieu Bouron
Allows to select a codec (encoder or decoder) only if it supports a
specific profile.
Adds ff_AMediaCodecProfile_getProfileFromAVCodecContext to convert an
AVCodecContext profile to a MediaCodec profile. It only supports H264
for now.
The codepath using MediaCodecList.find
On 08/06/16 21:02, Will Kelleher wrote:
> On 06/08, Mark Thompson wrote:
>> On 08/06/16 18:23, Will Kelleher wrote:
>>> Hi all -
>>>
>>> I'm experiencing some significant heap growth when encoding with VAAPI on
>>> my Ivy Bridge hardware. Based on what I'm seeing from Massif, it seems like
>>> the
On 4 June 2016 at 20:37, Rostislav Pehlivanov wrote:
> All HE-AAC samples with an LFE channel make this warning get spammed on
> every frame. Turning off SBR for LFE channels makes sense (since it has
> much less coefficients than normal channels do), so this error print is
> of no value in this
On 06/08, Mark Thompson wrote:
> On 08/06/16 18:23, Will Kelleher wrote:
> > Hi all -
> >
> > I'm experiencing some significant heap growth when encoding with VAAPI on
> > my Ivy Bridge hardware. Based on what I'm seeing from Massif, it seems like
> > the parameter buffers allocated in vaapi_enco
On Thu, Jun 2, 2016 at 3:01 PM, Muhammad Faiz wrote:
> fix error 'Channel layout change is not supported' when
> opening wav file
>
> Signed-off-by: Muhammad Faiz
> ---
> libavfilter/src_movie.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
applied
thanks
On 6/8/2016 1:49 PM, Michael Niedermayer wrote:
> On Wed, Jun 08, 2016 at 12:04:44AM -0300, James Almer wrote:
>> On 5/31/2016 4:23 PM, Michael Niedermayer wrote:
>>> adding demuxer and other logs should be easy
>>> This forces single threaded decoding for simplicity
>>> It also requires pthreads,
On 08/06/16 18:23, Will Kelleher wrote:
> Hi all -
>
> I'm experiencing some significant heap growth when encoding with VAAPI on
> my Ivy Bridge hardware. Based on what I'm seeing from Massif, it seems like
> the parameter buffers allocated in vaapi_encode_make_param_buffer are leaking.
>
> I ca
On Wed, Jun 8, 2016 at 9:59 PM, Michael Niedermayer
wrote:
> On Wed, Jun 08, 2016 at 07:46:07AM +0700, Muhammad Faiz wrote:
>> see Ticket #5618
>>
>> Signed-off-by: Muhammad Faiz
>> ---
>> libavfilter/avf_showcqt.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> probably (1) o
On Wed, Jun 8, 2016 at 11:34 PM, James Almer wrote:
> On 6/7/2016 6:18 AM, Muhammad Faiz wrote:
+sub lend, 2
>> +lea dstq, [dstq + 16]
>>> >
>>> > Use add
>>> >
>> +lea coeffsq, [coeffsq + 2*Coeffs.sizeof]
>>> >
>>> > Same, assuming sizeof is an i
> On Jun 8, 2016, at 12:30 PM, Michael Niedermayer
> wrote:
>
> On Tue, Jun 07, 2016 at 08:06:35PM -0400, Dave Rice wrote:
>>
>>> On May 31, 2016, at 3:23 PM, Michael Niedermayer
>>> wrote:
>>>
>>> adding demuxer and other logs should be easy
>>> This forces single threaded decoding for sim
Michael et al., is this good to merge as-is? I just tested and a round trip
with ffmpeg from wav -> mp3 -> wav retains the correct number of samples.
Jon Toohill | Google Play Music | jtooh...@google.com | (650) 215-0770
On Wed, Jun 1, 2016 at 5:58 PM, Jon Toohill wrote:
> Based on my under
Hi all -
I'm experiencing some significant heap growth when encoding with VAAPI on
my Ivy Bridge hardware. Based on what I'm seeing from Massif, it seems like
the parameter buffers allocated in vaapi_encode_make_param_buffer are leaking.
I came across this thread [1] that indicates that vaEndPic
On Wed, Jun 08, 2016 at 12:04:44AM -0300, James Almer wrote:
> On 5/31/2016 4:23 PM, Michael Niedermayer wrote:
> > adding demuxer and other logs should be easy
> > This forces single threaded decoding for simplicity
> > It also requires pthreads, this could be avoided either with
> > some lockless
On 6/7/2016 6:18 AM, Muhammad Faiz wrote:
>>> +sub lend, 2
>>> >> +lea dstq, [dstq + 16]
>> >
>> > Use add
>> >
>>> >> +lea coeffsq, [coeffsq + 2*Coeffs.sizeof]
>> >
>> > Same, assuming sizeof is an immediate.
>> >
> This is optimization to separate sub and jnz w
On Tue, Jun 07, 2016 at 08:06:35PM -0400, Dave Rice wrote:
>
> > On May 31, 2016, at 3:23 PM, Michael Niedermayer
> > wrote:
> >
> > adding demuxer and other logs should be easy
> > This forces single threaded decoding for simplicity
> > It also requires pthreads, this could be avoided either w
Hello,
Yes it's planned. (with YCbCr, and display window).
Martin
Jokyo images
2016-06-08 17:26 GMT+02:00 Piotr Bandurski :
> Hi,
>
> > In attach, patch to add entry to the changelog, for recently add OpenExr
> > features
>
> Could you add support for grayscale images as well?
>
> https://trac.
On Sun, Jun 05, 2016 at 12:56:08PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2016-05-31 21:23:27 +0200, Michael Niedermayer encoded:
> > adding demuxer and other logs should be easy
> > This forces single threaded decoding for simplicity
> > It also requires pthreads, this could be avoided e
In dxva2 code there is bug with context_mutex usage -
if ID3D11VideoContext_DecoderBeginFrame return E_PENDING -
WaitForSingleObjectEx(context_mutex) will be called again, but each call to
it must have corresponding ReleaseMutex, otherwise it will not be released
- so after E_PENDING context mutex
On Jun 4, 2016 09:45, "Michael Niedermayer" wrote:
>
> CCing lukasz and ganesh ...
> so they can correct what we misremember if they want, also dont want
> to speak about people behind their back ...
>
> On Sat, Jun 04, 2016 at 12:26:22PM -0300, James Almer wrote:
> > On 6/4/2016 7:33 AM, Michael
On Tue, Jun 07, 2016 at 02:49:38PM +0300, ale...@netup.ru wrote:
> From: Alex Shumsky
>
> ---
> libavformat/mpegtsenc.c | 64
> -
> 1 file changed, 37 insertions(+), 27 deletions(-)
did you test this ?
if so please provide information & test resu
Hi,
> In attach, patch to add entry to the changelog, for recently add OpenExr
> features
Could you add support for grayscale images as well?
https://trac.ffmpeg.org/ticket/5621
Regards
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffm
On Wed, Jun 08, 2016 at 07:46:07AM +0700, Muhammad Faiz wrote:
> see Ticket #5618
>
> Signed-off-by: Muhammad Faiz
> ---
> libavfilter/avf_showcqt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
probably (1) ok
(1) (unless a different meaning for max/min is intended)
[...]
--
Mark Thompson jkqxz.net> writes:
> The point here is that the driver has declared its
> capabilities, and the given stream is not within those
> capabilities so the hwaccel should not be used because
> it will not work
Can you explain how it "will not work"?
On my nvidia hardware, any level c
Le 08/06/2016 15:37, Michael Niedermayer a écrit :
> On Wed, Jun 08, 2016 at 12:03:10AM +0200, miniupnp wrote:
On 6/1/16, miniupnp wrote:
> Hello,
>
> I'm using the .AU audio file format and noticed that FFmpeg always put 8
> zero's in the annotation field.
> SOX does use
On 08/06/16 13:59, Carl Eugen Hoyos wrote:
> Mark Thompson jkqxz.net> writes:
>
>> Uses the global -hwaccel_lax_profile_check option (may be
>> misnamed for this purpose, but it has the right spirit).
>
> Iirc, all old x264 files have a very high profile set (5.0?).
> Is there a usecase for the
On Wed, Jun 08, 2016 at 12:03:10AM +0200, miniupnp wrote:
>
> >> On 6/1/16, miniupnp wrote:
> >>> Hello,
> >>>
> >>> I'm using the .AU audio file format and noticed that FFmpeg always put 8
> >>> zero's in the annotation field.
> >>> SOX does use the annotation field to put metadata
> >>> (Title/
On Mon, Jun 06, 2016 at 10:10:03PM +0100, Mark Thompson wrote:
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionar
---
configure | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 7c463a5..ebd01d9 100755
--- a/configure
+++ b/configure
@@ -243,6 +243,7 @@ External library support:
--enable-libnut enable NUT (de)muxing via libnut,
---
ffmpeg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index 7c60075..1d58a5d 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -550,6 +550,7 @@ static void ffmpeg_cleanup(int ret)
av_frame_free(&ist->sub2video.frame);
av_freep(&ist->filters);
av_free
Mark Thompson jkqxz.net> writes:
> Uses the global -hwaccel_lax_profile_check option (may be
> misnamed for this purpose, but it has the right spirit).
Iirc, all old x264 files have a very high profile set (5.0?).
Is there a usecase for the default not being to accept any
profile?
Carl Eugen
Am 06.06.2016 um 11:35 schrieb Timo Rothenpieler:
> I'd like to merge the cuvid decoder/hwaccel for 3.1.
Scratching that for now, will put some more work into that.
If it gets ready before 3.1, that's nice.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
On Thu, Jun 02, 2016 at 02:43:56AM -0400, Rick Kern wrote:
> VideoToolbox doesn't supply parameter sets until the first frame is done
> encoding. This spins up a temporary encoder and encodes a single frame to
> get this data.
>
> Signed-off-by: Rick Kern
> ---
> libavcodec/videotoolboxenc.c | 3
Hi,
find attached a patch to $subj
This would have been useful at least to me :-)
--
Ben
From aac7f87102337b7b1a59f88fc69766a20dfa0790 Mon Sep 17 00:00:00 2001
From: Benoit Fouet
Date: Wed, 8 Jun 2016 11:42:51 +0200
Subject: [PATCH] hls muxer doc: clarify segment splitting option
---
doc/mux
On Tue, Jun 7, 2016 at 4:18 PM, Muhammad Faiz wrote:
> On Tue, Jun 7, 2016 at 10:36 AM, James Almer wrote:
>> On 6/4/2016 4:36 AM, Muhammad Faiz wrote:
>>> benchmark on x86_64
>>> cqt_time:
>>> plain = 3.292 s
>>> SSE = 1.640 s
>>> SSE3 = 1.631 s
>>> AVX = 1.395 s
>>> FMA3 = 1.271 s
>>> FMA
On Tue, Jun 7, 2016 at 2:51 PM, Muhammad Faiz wrote:
> On Tue, Jun 7, 2016 at 9:49 AM, Michael Niedermayer
> wrote:
>> On Tue, Jun 07, 2016 at 08:07:45AM +0700, Muhammad Faiz wrote:
>>> On Sat, Jun 4, 2016 at 2:36 PM, Muhammad Faiz wrote:
>>> > benchmark on x86_64
>>> > cqt_time:
>>> > plain = 3
On Tue Jun 7 Marton Balint wrote:
On Wed, 1 Jun 2016, Adrian Cruceru wrote:
>/Hi, />//>/Patch is attached, />//>/Quick notes: />/- Playing HLS streams - FFPlay stalls a
bit before each segment download />/- Stalls accumulate and FFPlay falls behind />/- We get log warning
and segment skip. /
On Wed, Jun 8, 2016 at 3:02 AM, Richard Kern wrote:
>
>> On Jun 6, 2016, at 9:00 AM, Richard Kern wrote:
>>
>> Ping. This fixes #5595.
>>
>>> On Jun 1, 2016, at 10:06 PM, Rick Kern wrote:
>>>
>>> Fixes VTDecompressionSessionCreate() error.
>>>
>>> Signed-off-by: Rick Kern
>>> ---
>>> libavcodec
48 matches
Mail list logo
