Sent on the go...
> On 19 Feb 2015, at 18:35, Michael Niedermayer wrote:
>
> theres no encoder, the data could instead come from another mov
> file or a binary encoder used by some user application with
> libavformat
Michael,
Thanks for your response, I must be confused then. What I thought
When receiving an RTCP packet, the difference between the last RTCP
timestamp and the base timestamp may be negative. As these timestamps
are of the uint32_t type, the result becomes a large integer. Cast
the difference to int32_t to avoid this issue.
The result of this issue is very large start t
On Thu, Feb 19, 2015 at 11:52:50PM +0100, Lukasz Marek wrote:
> ffm encoder fails when codec is not found.
> It may happen when stream is being copied.
> This commit allows to store such stream and provides
> backward compatibility with version prior 2.5 release.
>
> fixes #4266
>
> Signed-off-by
On date Thursday 2015-02-19 17:13:15 +0530, Arwa Arif encoded:
> Updated the patch.
> From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00 2001
> From: Arwa Arif
> Date: Thu, 19 Feb 2015 01:26:44 +0530
> Subject: [PATCH] Add process_command to eq.
>
> ---
> doc/filters.texi|
On Thu, Feb 19, 2015 at 05:13:15PM +0530, arwa arif wrote:
> Updated the patch.
> doc/filters.texi| 35 ++
> libavfilter/vf_eq.c | 171
> ++--
> libavfilter/vf_eq.h | 56 +++--
> 3 files changed, 210 insertions(+), 52 d
ffm encoder fails when codec is not found.
It may happen when stream is being copied.
This commit allows to store such stream and provides
backward compatibility with version prior 2.5 release.
fixes #4266
Signed-off-by: Lukasz Marek
---
libavformat/ffmenc.c | 13 -
1 file changed,
On Thu, Feb 19, 2015 at 05:13:19PM +, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
> > > Attached patch by Francisco Blas Izquierdo Riera
> > > fixes a compilation error in mlpdsp_init.c with
> > > -fstack-check and some gcc compilers (I reproduced
> > > the issue with gc
Le primidi 1er ventôse, an CCXXIII, Michael Niedermayer a écrit :
> merged
Thanks. The web page was regenerated a moment ago and the × looks fine.
OTOH, FATE shows:
# MAN doc/ffprobe.1
# doc/ffmpeg.pod:1: Unknown command paragraph "=encoding utf8"
# doc/ffprobe.pod:1: Unknown command paragraph
On Thu, Feb 19, 2015 at 06:26:16PM +, Kevin Wheatley wrote:
> Hi,
>
> I realise this potentially breaks through lots of API boundaries/good
> taste, but I've noticed a case where the movenc.c code should really
> ask the specific encoder context (DNXHDEncContext) for some of it's
> fields to e
Hi,
I realise this potentially breaks through lots of API boundaries/good
taste, but I've noticed a case where the movenc.c code should really
ask the specific encoder context (DNXHDEncContext) for some of it's
fields to ensure that the atoms written have a consistent setting with
what the codec d
Hendrik Leppkes gmail.com> writes:
> > Attached patch by Francisco Blas Izquierdo Riera
> > fixes a compilation error in mlpdsp_init.c with
> > -fstack-check and some gcc compilers (I reproduced
> > the issue with gcc 4.7.3) by simplifying the code.
> > I ran some benchmarks with a very large
On Thu, Feb 19, 2015 at 12:25:44PM +0100, Nicolas George wrote:
> Le nonidi 29 pluviôse, an CCXXIII, Michael Niedermayer a écrit :
> > iam a bit concerned about the possibility of this unneccesarily
> > allocating a million packets
> > i think IIUC this amount will actually be alloated no matter if
On Thu, Feb 19, 2015 at 4:25 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch by Francisco Blas Izquierdo Riera fixes a compilation
> error in mlpdsp_init.c with -fstack-check and some gcc compilers (I
> reproduced the issue with gcc 4.7.3) by simplifying the code.
> I ran some benchmarks with
On Thu, Feb 19, 2015 at 11:43:02AM +0100, Nicolas George wrote:
> Le decadi 30 pluviôse, an CCXXIII, Michael Niedermayer a écrit :
> > this x looks strange, and we had problems with these in the past
> > and removed them: 1afbb4c226203c1a0853c9ad469cd9ef337080e4
>
> The first related commit stated
On Thu Feb 19 2015 at 4:43:30 AM Michael Niedermayer
wrote:
>
> tools/model.c | 42 ++
> 1 file changed, 42 insertions(+)
> create mode 100644 tools/model.c
>
tools/coverity.c sounds better to me.
Timothy
___
Hi!
Attached patch by Francisco Blas Izquierdo Riera fixes a compilation
error in mlpdsp_init.c with -fstack-check and some gcc compilers (I
reproduced the issue with gcc 4.7.3) by simplifying the code.
I ran some benchmarks with a very large thd file, 'time' confirms
the results of '-benchmark
Thanks, just a reminder that reading ffmpeg generated DNxHD in .mov
won't work without a variant of my other patch, which correctly places
the padding in the stsd atom, I'll pull the latest master and rebase
to make sure it still holds.
Kevin
___
ffmpeg-
On Thu, Feb 19, 2015 at 11:25:34AM +, Kevin Wheatley wrote:
> V3 of the patch, I've attempted to include the general comments from the
> thread.
>
> New to this version, I've reworked the function that reads the atom
> into the extradata into one which calls 2 helper functions (one to
> reall
On Thu, Feb 19, 2015 at 06:36:17AM -0700, Roger Pack wrote:
> On 2/9/15, wm4 wrote:
> > On Mon, 9 Feb 2015 14:30:27 -0700
> > Roger Pack wrote:
> >
> >> Hello. I seem to have noticed that on ffmpeg trac's that I have
> >> commented on, if there's a later updated, I don't get any email
> >> notif
On 2/9/15, wm4 wrote:
> On Mon, 9 Feb 2015 14:30:27 -0700
> Roger Pack wrote:
>
>> Hello. I seem to have noticed that on ffmpeg trac's that I have
>> commented on, if there's a later updated, I don't get any email
>> notification of such. Is this expected [ I would *like* to be
>> notified in t
The comments/header of the file are taken from qemu, they provide some
basic documentation
The code from the examples
Ive no means to test this except uploading to coverity for FFmpeg, so each
commit should stay simple, making it easy to revert.
Also please help making this a useful and effective
Updated the patch.
From 66a8c9d03995c9e7c6ccc05fb9b20756f51c17f4 Mon Sep 17 00:00:00 2001
From: Arwa Arif
Date: Thu, 19 Feb 2015 01:26:44 +0530
Subject: [PATCH] Add process_command to eq.
---
doc/filters.texi| 35 +++
libavfilter/vf_eq.c | 171 +
Le nonidi 29 pluviôse, an CCXXIII, Michael Niedermayer a écrit :
> iam a bit concerned about the possibility of this unneccesarily
> allocating a million packets
> i think IIUC this amount will actually be alloated no matter if its
> needed or not
Yes, that will allocate all the FIFO, and with 1<<
V3 of the patch, I've attempted to include the general comments from the thread.
New to this version, I've reworked the function that reads the atom
into the extradata into one which calls 2 helper functions (one to
realloc, one to read), I've then reused these functions to read the
ACLR atom reli
Le primidi 1er ventôse, an CCXXIII, Michael Niedermayer a écrit :
> doesnt this also set it for the muxer ?
> otherwise it is probably ok but you know this code better than i do ...
True, I had not thought long enough to see that it could cause problems. I
have moved that to the demuxer, I will se
Le decadi 30 pluviôse, an CCXXIII, Michael Niedermayer a écrit :
> this x looks strange, and we had problems with these in the past
> and removed them: 1afbb4c226203c1a0853c9ad469cd9ef337080e4
The first related commit stated:
# Non-ascii chars are not correctly rendered in both MAN and HTML outpu
On Mon, Feb 09, 2015 at 11:04:47AM -0900, Lou Logan wrote:
> Also mention option defaults.
> Also fix incorrect k1 and k2 "no correction" values.
>
> Signed-off-by: Lou Logan
> ---
> doc/filters.texi | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/doc/fil
27 matches
Mail list logo
