Can you post the png fix please so i can backport this
On Thursday, 30 April 2015, 4:03, Michael Niedermayer
wrote:
On Wed, Apr 29, 2015 at 10:43:18PM +, JULIAN GARDNER wrote:
> I converted to 8bit greyscale, i did check the code to see what format it
> wants.
> My question
There was a patch to fix this, but I don't think it was ever applied:
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2006-June/013107.html
Did you test the patch?
Carl Eugen
No. I don't know if it works and don't really know how to apply it. It's
also a bit old.
_
On Wed, Apr 29, 2015 at 10:43:18PM +, JULIAN GARDNER wrote:
> I converted to 8bit greyscale, i did check the code to see what format it
> wants.
> My question was really about the fact that one of my own filters now fails
> with any png from gimp so I have to run 2 versions of ffmpeg one whic
ill gmail.com> writes:
> There was a patch to fix this, but I don't think it was ever applied:
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2006-June/013107.html
Did you test the patch?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
The jpg output plugin is outputting a stream (with no mimetype) instead
of an image file, so browsers like firefox can't view it properly and
try to download it or try to grab the never ending stream instead of
just a single image.
There was a patch to fix this, but I don't think it was ever a
Timo Rothenpieler rothenpieler.org> writes:
> The other issue is the pixel format conversions done
> by this filter. It seems like libavfilter expects a
> filter to be able to convert from any of its input
> formats to any of its output formats.
>From a user's perspective, I don't think this
I converted to 8bit greyscale, i did check the code to see what format it wants.
My question was really about the fact that one of my own filters now fails with
any png from gimp so I have to run 2 versions of ffmpeg one which works and the
newer one.
this is the problem[png @ 0x260cda0] PNG2
[pn
On Wed, Apr 29, 2015 at 09:58:55PM +, JULIAN GARDNER wrote:
> Just thought i would give this a test and took a video i had, cropped a
> static bit from the picture, using gimp, and tried to run this.
> but I have the same problem as one of my own filters, png decode does not
> work, well not
Just thought i would give this a test and took a video i had, cropped a static
bit from the picture, using gimp, and tried to run this.
but I have the same problem as one of my own filters, png decode does not work,
well not with a png generated with gimp.
anybody know how to export a VALID png f
On Mon, Mar 30, 2015 at 09:57:35PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_vignette.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0
On 29.04.2015 21:28, Luca Barbato wrote:
> Probably something like the following is simpler though.
>
> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> index ed28107..8a58845 100644
> --- a/libavformat/nutdec.c
> +++ b/libavformat/nutdec.c
> @@ -707,7 +707,7 @@ static int nut_read_heade
On 29.04.2015 21:04, Luca Barbato wrote:
> On 28/04/15 00:30, Andreas Cadhalpun wrote:
>> Otherwise range_start_decoding is not necessarily run and thus
>> ctx->rc.range still 0 in range_dec_normalize leading to an infinite
>> loop.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/aped
Its nice to see this added, but why 4 years ago when I pushed these same
changes, was I told it was not being added because it would break older streams
created with ffmpeg.
Has there been a change in policy now to try to adhere to specifications.
Just wondering boys as my personal build has had
On Wed, Apr 29, 2015 at 10:30:56PM +0200, Hendrik Leppkes wrote:
> On Wed, Apr 29, 2015 at 10:24 PM, Michael Niedermayer
> wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/mpegts.c | 22 ++
> > 1 file changed, 14 insertions(+), 8 deletions(-)
> >
> > d
On Wed, Apr 29, 2015 at 10:24 PM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mpegts.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 0e5c2ba..d707cc3 1
Signed-off-by: Michael Niedermayer
---
libavformat/mpegts.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0e5c2ba..d707cc3 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -580,6 +580,
Based on suggestion by: John Högberg
Signed-off-by: Michael Niedermayer
---
libavformat/mpegts.c |5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index d707cc3..d8b5308 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2176,6
On 29.04.2015 20:32, Luca Barbato wrote:
> On 29/04/15 17:36, Luca Barbato wrote:
>> On 28/04/15 15:21, Andreas Cadhalpun wrote:
>>> I think it's better to change the function not to need 64 blocks,
>>> as in the second patch I sent.
>>
>> Your patch assumes that the required block number informati
Michael Niedermayer gmx.at> writes:
> + * it under the terms of the GNU General Public License as published by
This would need a line in configure.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ff
Signed-off-by: Michael Niedermayer
---
libavfilter/Makefile |1 +
libavfilter/allfilters.c |1 +
libavfilter/vf_findandcover.c | 400 +
3 files changed, 402 insertions(+)
create mode 100644 libavfilter/vf_findandcover.c
diff --git a
On Fri, Apr 24, 2015 at 10:46:06PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/libx264.c |7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
DNS
On Wed, Apr 29, 2015 at 12:13:53PM +, Nedeljko Babic wrote:
> Ok, I'll split this patch some more and since this takes already too long I
> will eliminate any change that is not absolutely necessary for implementation
> of fixed point aac decoder (I am thinking here on new recip and div
> func
On Wed, Apr 29, 2015 at 02:14:55PM +0300, foo86 wrote:
> Check extended sync word for 16-bit LE and BE core streams to reduce
> probability of alias sync detection. Previously sync word extension was
> checked only for 14-bit streams (and this check did not properly work
> across buffer boundary).
Ok, I'll split this patch some more and since this takes already too long I
will eliminate any change that is not absolutely necessary for implementation
of fixed point aac decoder (I am thinking here on new recip and div functions).
Since there will be two or three new patches from this patch I'l
Am 28.04.15 um 16:49 schrieb Daniel Ly:
> This makes avdevice_list_input_sources() available for
> device_name = "avfoundation". avf_read_header is retrofitted
> to use the new method.
>
> Signed-off-by: Daniel Ly
> ---
> libavdevice/avfoundation.m | 139
> +-
Check extended sync word for 16-bit LE and BE core streams to reduce
probability of alias sync detection. Previously sync word extension was
checked only for 14-bit streams (and this check did not properly work
across buffer boundary).
Use 64-bit parser state to make extended sync word detection w
26 matches
Mail list logo
