On Wed, Sep 02, 2015 at 05:33:04PM -0700, Ganesh Ajjanagadde wrote:
> On Wed, Sep 2, 2015 at 5:17 PM, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > This function avoids the undefined corner cases which affects other absolute
> > value functions and macros
>
> LGTM, except for
On Wed, 2 Sep 2015 14:06:43 -0700
Ganesh Ajjanagadde wrote:
> On Wed, Sep 2, 2015 at 1:57 PM, wm4 wrote:
> > On Wed, 2 Sep 2015 16:49:41 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde
> >> wrote:
> >>
> >> > On Wed, Sep 2, 2015 at
Hello,
I want to do some pixel operations on a decoded frame (AVFrame structure)
in function "ff_thread_decode_frame" of the file
"ffmpeg/libavcodec/pthread.c".
For example. I wrote a simple code to get y,u,v of the pixel(0,0) :
int x= 0;
int y= 0;
unsigned char y = picture->data[0][picture->li
> -原始邮件-
> 发件人: "Michael Niedermayer"
> 发送时间: 2015年9月2日 星期三
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH 1/3] avcodec: loongson delete invalid simple
> idct put and add optimization
>
> On Wed, Sep 02, 2015 at 06:00:24PM +0800, 周晓勇 wrote:
On Wed, Sep 2, 2015 at 5:17 PM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This function avoids the undefined corner cases which affects other absolute
> value functions and macros
LGTM, except for the comment/commit message. This does not avoid all
weird cases, see e.g
https://s
From: Michael Niedermayer
This function avoids the undefined corner cases which affects other absolute
value functions and macros
Signed-off-by: Michael Niedermayer
---
libavutil/common.h |4
1 file changed, 4 insertions(+)
diff --git a/libavutil/common.h b/libavutil/common.h
index 1
Tomas Härdin codemill.se> writes:
[...]
Please also look at the patch attached in ticket #4820,
I will add the additional uls if you don't object.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
Tomas Härdin codemill.se> writes:
> > Attached patch fixes decoding the sample from
> ticket #4820 for me.
> The JPEG2000 tag is in ff_mxf_codec_uls[] anyway, so
> mxf_codec_uls[] should be safe to nuke. I presume you
> rate make fate on this?
I did not (specifically) ran make fate for this c
Carl Eugen Hoyos ag.or.at> writes:
> +If your input has mixed telecined and progressive content which implies
> +changing framerates use the following filterchain to produce the
> +necessary cfr stream:
Changed locally to avoid the misinterpretation 30fps
telecined and 30fps progressive:
If you
Nicholas Robbins ffmpeg.org> writes:
> Do you have a sample where dejudder used like this helps?
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3968/
> If so does it work better with larger n?
I didn't test because it works fine afaict.
> Your suggestion is for material that is a mix of 30
On Tue, 2015-09-01 at 23:53 +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes decoding the sample from ticket #4820 for me.
>
> Please comment, Carl Eugen
> -static const MXFCodecUL mxf_codec_uls[] = {
> -{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x07,0x04,0x01,0x02,0x02,0x03,0x0
On Wed, 2 Sep 2015 14:06:43 -0700
Ganesh Ajjanagadde wrote:
> On Wed, Sep 2, 2015 at 1:57 PM, wm4 wrote:
> > On Wed, 2 Sep 2015 16:49:41 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde
> >> wrote:
> >>
> >> > On Wed, Sep 2, 2015 at
Hi Ganesh,
On Wed, Sep 2, 2015 at 5:06 PM, Ganesh Ajjanagadde wrote:
> On Wed, Sep 2, 2015 at 1:57 PM, wm4 wrote:
> > On Wed, 2 Sep 2015 16:49:41 -0400
> > "Ronald S. Bultje" wrote:
> >
> >> Hi,
> >>
> >> On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde
> wrote:
> >>
> >> > On Wed, Sep 2, 2
On Wed, Sep 02, 2015 at 07:40:18PM +0200, Peter B. wrote:
> On 09/02/2015 02:53 PM, Michael Niedermayer wrote:
> > the include breaks out of tree builds
> > mkdir delthisdir
> > cd delthisdir
> > ../configure
> > make -j12
> > /home/michael/ffmpeg/tests/fate/vcodec.mak:71: tests/fate/ffv1.mak: No s
On Wed, Sep 2, 2015 at 1:57 PM, wm4 wrote:
> On Wed, 2 Sep 2015 16:49:41 -0400
> "Ronald S. Bultje" wrote:
>
>> Hi,
>>
>> On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde wrote:
>>
>> > On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer
>> > wrote:
>> > > From: Michael Niedermayer
>> > >
>>
On Wed, 2 Sep 2015 16:49:41 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde wrote:
>
> > On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer
> > wrote:
> > > From: Michael Niedermayer
> > >
> > > a 32bit bitrate is insufficient for high resolution
On Wed, 2 Sep 2015 22:20:40 +0200
Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> a 32bit bitrate is insufficient for high resolution, high framerate material
> an example would be rawvideo
>
> Not all changes are covered by #if as its easier to just push when the
> bump is done in
Carl,
> Did you save the (h264) source for this output?
> (Could it be threads-related?)
I haven't saved the source but I'll try and replicate the problem tomorrow by
dropping frames at iptables and get back to you. The cameras that were causing
issues aren't online at the moment.
Should I ju
On Wed, 2 Sep 2015 20:42:25 +
Gregory J Wolfe wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of wm4
> > Sent: Wednesday, September 02, 2015 2:28 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] Add
Le sextidi 16 fructidor, an CCXXIII, Chema Gonzalez a écrit :
> +} else if (!strcmp(fmt, "raw")) {
> +av_bprintf(bp, "%ld", (long int) (s->var_values[VAR_T] * 9));
On 32 bits archs, long is smaller than int64_t.
And that 9 is only relevant for MPEG, AFAIK.
Regards,
--
Nic
On Wed, Sep 02, 2015 at 01:47:07PM -0700, Ganesh Ajjanagadde wrote:
> On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > a 32bit bitrate is insufficient for high resolution, high framerate material
> > an example would be rawvideo
> >
> > Not all chan
Hi,
On Wed, Sep 2, 2015 at 4:47 PM, Ganesh Ajjanagadde wrote:
> On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer
> wrote:
> > From: Michael Niedermayer
> >
> > a 32bit bitrate is insufficient for high resolution, high framerate
> material
> > an example would be rawvideo
> >
> > Not all cha
On Wed, Sep 2, 2015 at 1:20 PM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> a 32bit bitrate is insufficient for high resolution, high framerate material
> an example would be rawvideo
>
> Not all changes are covered by #if as its easier to just push when the
> bump is done instead
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of wm4
> Sent: Wednesday, September 02, 2015 2:28 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264
> encoder message log level and log function.
From: Chema Gonzalez
Example:
$ ffplay -vf
"drawtext=fontfile=/usr/share/fonts/truetype/ubuntu-font-family/UbuntuMono-R.ttf:text='%{pict_type}
%{pts\:hms} %{pts\:raw} %{eif\:n\:u}':
fontcolor=white@0.8:fontsize=40:x=7:y=680:box=1:boxcolor=black@0.8,showinfo"
file.ts
Signed-off-by: Chema Gonzal
From: Michael Niedermayer
a 32bit bitrate is insufficient for high resolution, high framerate material
an example would be rawvideo
Not all changes are covered by #if as its easier to just push when the
bump is done instead of making it coditional and removig the conditionallity
again
Signed-o
On Wed, 2 Sep 2015, Michael Niedermayer wrote:
On Mon, Aug 31, 2015 at 09:28:30PM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/fftools-common-opts.texi | 6 --
libavformat/utils.c | 12 +---
2 files changed, 13 insertions(+), 5 deletions(-)
no obje
On Wednesday, September 2, 2015 7:50 AM, Carl Eugen Hoyos
wrote:
>Hi!
>
>As Clément always pointed out correctly, the issues users see with
>fieldmatch and mixed telecined and progressive content have nothing
>to do with decimate (and of course not fieldmatch) but with the
>specifics of our fp
On 8/31/2015 6:49 PM, Andreas Cadhalpun wrote:
> And some of the more recent ones are problematic:
> Build failure:
> FF_API_CRYPTO_CONTEXT
This is not meant to be removed until at least avutil 56, and even
then there's no consensus if we want these deprecations at all or
not. They will be undone
What will be the resolution for no audio in RTMP output due to not having
extradata in the copyts mode i.e stream copy?
/opt/ripcode/bin/ffmpeg -copyts -i /root/ModernFamilyVMGCapture.ts -async 0
-vsync 0 -f flv -mpegts_pmt_start_pid 480 -map 0:2,0:0 -vcodec copy -b:v 544000
-muxdelay 0 -map 0:
On Wed, 2 Sep 2015 17:36:30 +
Gregory J Wolfe wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Paul B Mahol
> > Sent: Wednesday, September 02, 2015 1:15 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re:
On 09/02/2015 02:53 PM, Michael Niedermayer wrote:
> the include breaks out of tree builds
> mkdir delthisdir
> cd delthisdir
> ../configure
> make -j12
> /home/michael/ffmpeg/tests/fate/vcodec.mak:71: tests/fate/ffv1.mak: No such
> file or directory
> make: *** No rule to make target `tests/fate/
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, September 02, 2015 1:15 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] Add AVOptions for libopenh264
> encoder message
Dana 2. 9. 2015. 19:10 osoba "Gregory J. Wolfe" <
gregory.wo...@kodakalaris.com> napisala je:
>
> By default, the libopenh264 encoder logs error and warning messages to
> stderr. However, libopenh264 also provides a SetOption() function that
> allows the client to set the message logging level (e.
By default, the libopenh264 encoder logs error and warning messages to
stderr. However, libopenh264 also provides a SetOption() function that
allows the client to set the message logging level (e.g., error, warning,
debug) and a client-supplied message logging function (whose signature
must confor
On Tue, Sep 1, 2015 at 2:53 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes decoding the sample from ticket #4820 for me.
>
> Please comment, Carl Eugen
Probably ok; seems like in d0061e77 the existence of ff_mxf_codec_uls
was missed,
and the introduced mxf_codec_uls was actually redun
---
libavcodec/vp9.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 7035512..b1cf929 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1479,7 +1479,8 @@ static void decode_mode(AVCodecContext *ctx)
if (!s->segmentation.en
Hi,
I'm considering adding support for writing the QuickTime metadata atom
structure to support arbitrary key value pairs, similar to those
included by ARRI cameras see:
https://developer.apple.com/library/prerelease/mac/documentation/QuickTime/QTFF/qtff.pdf
p128
To start I was going to try add
On Wed, Sep 02, 2015 at 06:01:00PM +0800, 周晓勇 wrote:
> From b34ee3cd2569c0982af7bad704352c6db89f00ec Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong
> Date: Tue, 1 Sep 2015 20:26:53 +0800
> Subject: [PATCH 2/3] avcodec: loongson optimize mpeg2 dct unquantize intra and
> denoise dct
>
>
> Change-I
On Wed, Sep 02, 2015 at 06:00:24PM +0800, 周晓勇 wrote:
> From e7dc62a7edbf985268908adf942e838548c09ef0 Mon Sep 17 00:00:00 2001
> From: ZhouXiaoyong
> Date: Tue, 1 Sep 2015 09:34:18 +0800
> Subject: [PATCH 1/3] avcodec: loongson delete invalid simple idct put and add
> optimization
please document
Sailaja Mahendrakar rgbnetworks.com> writes:
> When you say decoder cant allocate and write extradata,
> why does the flv decoder do it?
The code you pasted is in the flv demuxer.
Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
Hendrik,
When you say decoder cant allocate and write extradata, why does the flv
decoder do it?
if (read) {
if (vcodec->extradata_size != 1) {
ff_alloc_extradata(vcodec, 1);
}
if (vcodec->extradata)
vcodec->extradata[0] = avio_
On Wed, Sep 02, 2015 at 12:01:06AM +0200, Peter B. wrote:
> On 09/01/2015 11:40 PM, Michael Niedermayer wrote:
> >> +include tests/fate/ffv1.mak
> > doesnt this belong in tests/Makefile ?
>
> I did so first, but then all the prerequisites set in vcodec.mak are not
> applied, causing ffv1.mak to fa
Michael Niedermayer gmx.at> writes:
> > Attached patch should fix ticket #1057.
> >
> > Please comment, Carl Eugen
>
> should be ok
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On 2 September 2015 at 08:30, Carl Eugen Hoyos wrote:
> Chris Wiggins chriswiggins.co.nz> writes:
>
>> however sometimes it washes the frame out:
>> http://i.imgur.com/o5YttPY.png
>
> Did you save the (h264) source for this output?
> (Could it be threads-related?)
No, its packet loss and/or reor
Kieran Kunhya obe.tv> writes:
> >> http://i.imgur.com/o5YttPY.png
> >
> > Did you save the (h264) source for this output?
> > (Could it be threads-related?)
>
> No, its packet loss and/or reordering.
Can you provide a sample?
I would expect the issue to be threads-related.
Carl Eugen
On Wed, Sep 02, 2015 at 01:14:03PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch should fix ticket #1057.
>
> Please comment, Carl Eugen
should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does n
Hi!
As Clément always pointed out correctly, the issues users see with
fieldmatch and mixed telecined and progressive content have nothing
to do with decimate (and of course not fieldmatch) but with the
specifics of our fps filter (see my ignored mail for details).
Attached patch should help,
Hi!
Attached patch should fix ticket #1057.
Please comment, Carl Eugen
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 42d2327..55818e1 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3085,8 +3085,8 @@ const OptionDef options[] = {
OPT_INPUT,
Hi
Enabling pns by default (b7eb7cb3a18093aea22d1aee2cbe293f6a214a5b)
broke aac-pns-encode
(http://fate.ffmpeg.org/report.cgi?time=20150901213100&slot=mips-ubuntu-qemu-gcc-4.4)
ive disabled the optimizations which cause this breakage
(933309a6ca0f18bf1d40e917fff455221f57fb4b),
someone should chec
From e7dc62a7edbf985268908adf942e838548c09ef0 Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Tue, 1 Sep 2015 09:34:18 +0800
Subject: [PATCH 1/3] avcodec: loongson delete invalid simple idct put and add
optimization
Change-Id: I23a36c65915f01a1cf20e317c14b8eaaa62958b4
Signed-off-by: ZhouXiaoy
From b34ee3cd2569c0982af7bad704352c6db89f00ec Mon Sep 17 00:00:00 2001
From: ZhouXiaoyong
Date: Tue, 1 Sep 2015 20:26:53 +0800
Subject: [PATCH 2/3] avcodec: loongson optimize mpeg2 dct unquantize intra and
denoise dct
Change-Id: I2f391ae912a079fb32f0703841dca86358aac72a
Signed-off-by: ZhouXiaoy
On Tue, 1 Sep 2015 11:35:17 -0700
Tsung-Hung Wu wrote:
> Hi FFmpeg developers,
>
> I am trying to solve an issue: seeking a large MP3 file is slow. This
> happens when play Podcast audio, for example
> http://podcastdownload.npr.org/anon.npr-podcasts/podcast/344098539/430765119/npr_430765119.mp3
Chris Wiggins chriswiggins.co.nz> writes:
> however sometimes it washes the frame out:
> http://i.imgur.com/o5YttPY.png
Did you save the (h264) source for this output?
(Could it be threads-related?)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-de
54 matches
Mail list logo
