On Sat, 15 Oct 2016 15:52:48 +0200
Nicolas George wrote:
> Le tridi 23 vendémiaire, an CCXXV, wm4 a écrit :
> > XML is very complex
>
> This is the usual, and often only, argument raised in this kind of
> situation. And unfortunately, I already addressed it in this very thread.
>
> XML is
Hello,
Given the practical constraints I can not thoroughly fulfill all the
requirements for submitting a patch. I hope it can make it at least to
the list archive, for possible future perusal by someone.
The patch addresses the missing Kate subtitles support, reflected
in trac as
http
On Sun, 23 Oct 2016 13:02:01 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Sat, Oct 22, 2016 at 11:36 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
> > On Sat, Oct 22, 2016 at 10:10:01PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > general comment about all other dec p
On Sun, 23 Oct 2016 05:37:25 +0200
Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/x86/emms.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/x86/emms.h b/libavutil/x86/emms.h
> index 6fda6e2..42c18e2 100644
> --- a/libavutil/x86/emms.h
>
On Sat, 22 Oct 2016 22:06:22 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Sat, Oct 22, 2016 at 3:02 PM, Michael Niedermayer > wrote:
>
> > This decreases the number of FPU state violations in fate on x86-64 from
> > 309 to 79
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcode
On Sun, 23 Oct 2016 12:27:41 +0200
Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> libavfilter/Makefile | 1 +
> libavfilter/framequeue.c | 123 +
> libavfilter/framequeue.h | 173
> +++
> 3 files c
On Sun, 23 Oct 2016 18:27:02 +0200
Andreas Cadhalpun wrote:
> A negative sample rate doesn't make sense and triggers assertions in
> av_rescale_rnd.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/bfi.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/bfi.c b/
On Mon, 24 Oct 2016 09:31:25 +0200
u-9...@aetey.se wrote:
> Hello,
>
> Given the practical constraints I can not thoroughly fulfill all the
> requirements for submitting a patch. I hope it can make it at least to
> the list archive, for possible future perusal by someone.
>
> The patch addresses
On Mon, Oct 24, 2016 at 10:00:38AM +0200, wm4 wrote:
> > The patch addresses the missing Kate subtitles support, reflected
> > in trac as
> >https://trac.ffmpeg.org/ticket/3039
> I don't quite get it. Doesn't this just demux kate subtitles as text
> without stripping whatever formattin
2016-10-24 15:22 GMT+08:00 wm4 :
> On Sat, 15 Oct 2016 15:52:48 +0200
> Nicolas George wrote:
>
> > Le tridi 23 vendémiaire, an CCXXV, wm4 a écrit :
> > > XML is very complex
> >
> > This is the usual, and often only, argument raised in this kind of
> > situation. And unfortunately, I already
worth to mention:
On Mon, Oct 24, 2016 at 10:25:44AM +0200, u-9...@aetey.se wrote:
> > >https://trac.ffmpeg.org/ticket/3039
The ticket refers to a sample with graphical subtitles. This is _not_
being solved by the proposed patch.
A sample with text subtitles can be seen e.g. at
http
On Mon, 24 Oct 2016 10:52:14 +0200
u-9...@aetey.se wrote:
> worth to mention:
>
> On Mon, Oct 24, 2016 at 10:25:44AM +0200, u-9...@aetey.se wrote:
> > > >https://trac.ffmpeg.org/ticket/3039
>
> The ticket refers to a sample with graphical subtitles. This is _not_
> being solved by
On Mon, Oct 24, 2016 at 11:09:43AM +0200, wm4 wrote:
> > Text subtitles in ogg kate are a straightforward way to put srt-like data
>
> Note that srt supports simple HTML-like tags.
Yes, you are right, the patch just ignores the possible presence
of Kate markup (does not try to interpret it, nor r
2016-10-24 10:52 GMT+02:00 :
> worth to mention:
>
> On Mon, Oct 24, 2016 at 10:25:44AM +0200, u-9...@aetey.se wrote:
>> > >https://trac.ffmpeg.org/ticket/3039
>
> The ticket refers to a sample with graphical subtitles. This is _not_
> being solved by the proposed patch.
>
> A sample w
On Mon, Oct 24, 2016 at 11:39:40AM +0200, u-9...@aetey.se wrote:
> On Mon, Oct 24, 2016 at 11:09:43AM +0200, wm4 wrote:
> > > Text subtitles in ogg kate are a straightforward way to put srt-like data
> >
> > Note that srt supports simple HTML-like tags.
>
> Yes, you are right, the patch just igno
On Mon, Oct 24, 2016 at 11:46:07AM +0200, Clément Bœsch wrote:
> On Mon, Oct 24, 2016 at 11:39:40AM +0200, u-9...@aetey.se wrote:
> > On Mon, Oct 24, 2016 at 11:09:43AM +0200, wm4 wrote:
> > > > Text subtitles in ogg kate are a straightforward way to put srt-like
> > > > data
> > >
> > > Note tha
On Mon, Oct 24, 2016 at 11:46:07AM +0200, Clément Bœsch wrote:
> On Mon, Oct 24, 2016 at 11:39:40AM +0200, u-9...@aetey.se wrote:
> > Yes, you are right, the patch just ignores the possible presence
> > of Kate markup (does not try to interpret it, nor removes).
> > This is probably not too bad, fo
On Mon, Oct 24, 2016 at 11:58:41AM +0200, u-9...@aetey.se wrote:
[...]
> Could be added later if desired, either as an incremental patch or by
> introducing an optional dependency on libkate (which would open for full
> Kate functionality).
No, it's a blocking requirement (see my next mail), it ne
On Mon, Oct 24, 2016 at 11:49:25AM +0200, Clément Bœsch wrote:
> > It is bad if you don't strip the markup in the decoder.
> To expand on this: it is extremely worrisome that ffmpeg could be the
> source of yet another wave of insane .srt files with kate markup in it
> because someone decided to r
On Mon, Oct 24, 2016 at 12:12:23PM +0200, u-9...@aetey.se wrote:
> On Mon, Oct 24, 2016 at 11:49:25AM +0200, Clément Bœsch wrote:
> > > It is bad if you don't strip the markup in the decoder.
>
> > To expand on this: it is extremely worrisome that ffmpeg could be the
> > source of yet another wave
On Mon, Oct 24, 2016 at 09:38:00AM +0200, wm4 wrote:
> On Sun, 23 Oct 2016 05:37:25 +0200
> Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/x86/emms.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavutil/x86/emms.h b/libavutil/x86
On Mon, Oct 24, 2016 at 12:18:23PM +0200, Clément Bœsch wrote:
> Today, in practice, we have to support all kind of mix of subtitles markup
> in various formats because of this. It would be great not to make things
> worst :)
Let's see.
Looking at kateenc code I believe that the intention was to
Hi,
On Mon, Oct 24, 2016 at 7:24 AM, Michael Niedermayer wrote:
> On Mon, Oct 24, 2016 at 09:38:00AM +0200, wm4 wrote:
> > On Sun, 23 Oct 2016 05:37:25 +0200
> > Michael Niedermayer wrote:
> >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavutil/x86/emms.h | 2 ++
> > > 1 file c
Hi,
On Mon, Oct 24, 2016 at 3:36 AM, wm4 wrote:
> On Sun, 23 Oct 2016 13:02:01 -0400
> "Ronald S. Bultje" wrote:
>
> > Hi,
> >
> > On Sat, Oct 22, 2016 at 11:36 PM, Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> >
> > > On Sat, Oct 22, 2016 at 10:10:01PM -0400, Ronald S. Bultje wrot
On Mon, Oct 24, 2016 at 01:31:10PM +0200, u-9...@aetey.se wrote:
> On Mon, Oct 24, 2016 at 12:18:23PM +0200, Clément Bœsch wrote:
> > Today, in practice, we have to support all kind of mix of subtitles markup
> > in various formats because of this. It would be great not to make things
> > worst :)
On Mon, 24 Oct 2016 13:24:38 +0200
Michael Niedermayer wrote:
> On Mon, Oct 24, 2016 at 09:38:00AM +0200, wm4 wrote:
> > On Sun, 23 Oct 2016 05:37:25 +0200
> > Michael Niedermayer wrote:
> >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavutil/x86/emms.h | 2 ++
> > > 1 file c
On Mon, 24 Oct 2016 07:54:47 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Mon, Oct 24, 2016 at 3:36 AM, wm4 wrote:
>
> > On Sun, 23 Oct 2016 13:02:01 -0400
> > "Ronald S. Bultje" wrote:
> >
> > > Hi,
> > >
> > > On Sat, Oct 22, 2016 at 11:36 PM, Michael Niedermayer <
> > > mich...@niederm
Hi,
On Mon, Oct 24, 2016 at 8:47 AM, wm4 wrote:
> On Mon, 24 Oct 2016 07:54:47 -0400
> "Ronald S. Bultje" wrote:
>
> > Hi,
> >
> > On Mon, Oct 24, 2016 at 3:36 AM, wm4 wrote:
> >
> > > On Sun, 23 Oct 2016 13:02:01 -0400
> > > "Ronald S. Bultje" wrote:
> > >
> > > > Hi,
> > > >
> > > > On Sat,
On Mon, Oct 24, 2016 at 02:36:23PM +0200, wm4 wrote:
> On Mon, 24 Oct 2016 13:24:38 +0200
> Michael Niedermayer wrote:
>
> > On Mon, Oct 24, 2016 at 09:38:00AM +0200, wm4 wrote:
> > > On Sun, 23 Oct 2016 05:37:25 +0200
> > > Michael Niedermayer wrote:
> > >
> > > > Signed-off-by: Michael Nied
On Fri, Sep 09, 2016 at 11:37:21PM -0500, Rodger Combs wrote:
> This is disabled by default when the empty_moov flag is enabled
> ---
> libavformat/dashenc.c | 43 +++-
> libavformat/movenc.c | 107
> +++---
> 2 files changed, 124 inse
On Sunday, October 23, 2016, Richard Kern wrote:
>
> > On Oct 19, 2016, at 8:45 PM, Aman Gupta >
> wrote:
> >
> > From: Aman Gupta >
> >
> > ff_videotoolbox_avcc_extradata_create() was never being called if
> > avctx->extradata_size==0, even though the function does not need or use
> > the avctx-
On Mon, 24 Oct 2016 18:08:11 +0200
Michael Niedermayer wrote:
> On Mon, Oct 24, 2016 at 02:36:23PM +0200, wm4 wrote:
> > On Mon, 24 Oct 2016 13:24:38 +0200
> > Michael Niedermayer wrote:
> >
> > > On Mon, Oct 24, 2016 at 09:38:00AM +0200, wm4 wrote:
> > > > On Sun, 23 Oct 2016 05:37:25 +020
On Mon, Oct 24, 2016 at 8:09 PM, wm4 wrote:
> B) add a compile time option that runs emms() unconditionally at the end
>of each mmx asm block
>
> Since musl intentionally evades detection, neither can be enabled
> automatically, probably. It would be interesting to see what the speed
> impact
On Mon, Oct 24, 2016 at 08:09:09PM +0200, wm4 wrote:
> B) add a compile time option that runs emms() unconditionally at the end
>of each mmx asm block
> It would be interesting to see what the speed
> impact of B) actually is.
+1
Regards,
Rune
___
On 24.10.2016 09:55, wm4 wrote:
> On Sun, 23 Oct 2016 18:27:02 +0200
> Andreas Cadhalpun wrote:
>
>> A negative sample rate doesn't make sense and triggers assertions in
>> av_rescale_rnd.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/bfi.c | 4
>> 1 file changed, 4 insertio
On 23.10.2016 20:18, Carl Eugen Hoyos wrote:
> 2016-10-23 12:14 GMT+02:00 Andreas Cadhalpun
> :
>
>> I also don't like adding emms_c in various places, but I don't see a
>> realistic alternative
>
> (+1!)
>
>> other than not fixing the problem. And I think that would be worse
>> than this patch
On Sun, Oct 23, 2016 at 11:20 PM, Aman Gupta wrote:
>
>
> On Sunday, October 23, 2016, Richard Kern wrote:
>
>>
>> > On Oct 19, 2016, at 8:45 PM, Aman Gupta wrote:
>> >
>> > From: Aman Gupta
>> >
>> > ff_videotoolbox_avcc_extradata_create() was never being called if
>> > avctx->extradata_size=
On 24.10.2016 16:14, Ronald S. Bultje wrote:
> On Mon, Oct 24, 2016 at 8:47 AM, wm4 wrote:
>> On Mon, 24 Oct 2016 07:54:47 -0400
>> "Ronald S. Bultje" wrote:
>>> On Mon, Oct 24, 2016 at 3:36 AM, wm4 wrote:
I was under the impression that it is UB to have the FPU in MMX state
at any tim
On Mon, 24 Oct 2016 12:18:07 -0700
Aman Gupta wrote:
> On Sun, Oct 23, 2016 at 11:20 PM, Aman Gupta wrote:
>
> >
> >
> > On Sunday, October 23, 2016, Richard Kern wrote:
> >
> >>
> >> > On Oct 19, 2016, at 8:45 PM, Aman Gupta wrote:
> >> >
> >> > From: Aman Gupta
> >> >
> >> > ff_videoto
On Mon, 24 Oct 2016 21:19:46 +0200
Andreas Cadhalpun wrote:
> On 24.10.2016 16:14, Ronald S. Bultje wrote:
> > On Mon, Oct 24, 2016 at 8:47 AM, wm4 wrote:
> >> On Mon, 24 Oct 2016 07:54:47 -0400
> >> "Ronald S. Bultje" wrote:
> >>> On Mon, Oct 24, 2016 at 3:36 AM, wm4 wrote:
> I was
On 24.10.2016 21:34, wm4 wrote:
> On Mon, 24 Oct 2016 21:19:46 +0200
> Andreas Cadhalpun wrote:
>> On 24.10.2016 16:14, Ronald S. Bultje wrote:
>>> On Mon, Oct 24, 2016 at 8:47 AM, wm4 wrote:
The next safest assumption is that it's fine as long as we explicitly
don't use floating poin
On Mon, Oct 24, 2016 at 9:34 PM, wm4 wrote:
> a ASM function must, according to the calling convention, reset the
> MMX state when returning.
>
> What FFmpeg does here was misdesigned from the very start.
The decision to issue emms manually instead of after every MMX
function was a deliberate dec
Hi,
On Mon, Oct 24, 2016 at 3:34 PM, wm4 wrote:
> On Mon, 24 Oct 2016 21:19:46 +0200
> Andreas Cadhalpun wrote:
>
> > On 24.10.2016 16:14, Ronald S. Bultje wrote:
> > > On Mon, Oct 24, 2016 at 8:47 AM, wm4 wrote:
> > >> On Mon, 24 Oct 2016 07:54:47 -0400
> > >> "Ronald S. Bultje" wrote:
> > >
On Mon, 24 Oct 2016 21:53:22 +0200
Henrik Gramner wrote:
> On Mon, Oct 24, 2016 at 9:34 PM, wm4 wrote:
> > a ASM function must, according to the calling convention, reset the
> > MMX state when returning.
> >
> > What FFmpeg does here was misdesigned from the very start.
>
> The decision to i
Hi,
On Thu, Oct 20, 2016 at 12:37 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> On Tue, Oct 18, 2016 at 03:17:26PM -0400, Vittorio Giovara wrote:
> > Signed-off-by: Vittorio Giovara
> > ---
> > Special thanks to Andrew Roland for helping me figure out these numbers.
> > Please keep
Hi,
On Fri, Oct 14, 2016 at 2:09 PM, James Zern wrote:
> Ronald,
>
> On Fri, Oct 14, 2016 at 10:01 AM, Ronald S. Bultje
> wrote:
> > This is intended to workaround bug "665 Integer Divide Instruction May
> > Cause Unpredictable Behavior" on some early AMD CPUs, which causes a
> > div-by-zero in
On 10/23/16, Nicolas George wrote:
> AVFilterLink.frame_count is supposed to count the number of frames
> that were passed on the link, but with min_samples, that number is
> not always the same for the source and destination filters.
> With the addition of a FIFO on the link, the difference will
Hi,
On Sat, Oct 22, 2016 at 10:02 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Sat, Oct 22, 2016 at 12:19 PM, Moritz Barsnick
> wrote:
>
>> On Sat, Oct 22, 2016 at 08:43:26 -0400, Ronald S. Bultje wrote:
>> > Is there documentation on what coverity expects?
>>
>> I found this:
>> https://lost-conta
Hello,
In attach new patchs.
I tested with zzuf using
zzuf -c -s0:1 -r0.01 ./ffmpeg -i inFile -f null -
on one sample
and with
zzuf -c -s0:5000 -r0.01 ./ffmpeg -i inFile -f null
on 10 others samples
Martin
From 37a7ee0fb3b32336c5376f85f1caeafb03f9c0e5 Mon Sep 17 00:00:00 2001
From: Mart
On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje wrote:
> Good idea to reference Hendrik Gramner here, who keeps insisting we get rid
> of all MMX code in ffmpeg (at least as an option) for future Intel CPUs in
> which MMX will be deprecated.
Replacing MMX with SSE2 is indeed the most "proper" f
Hi,
On Mon, Oct 24, 2016 at 4:26 PM, Henrik Gramner wrote:
> On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje
> wrote:
> > Good idea to reference Hendrik Gramner here, who keeps insisting we get
> rid
> > of all MMX code in ffmpeg (at least as an option) for future Intel CPUs
> in
> > which MM
---
Not sure if the chunk is even needed
---
ffmpeg.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 3b91710..e8088c0 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2317,10 +2317,9 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_o
Video doesn't exit ffmpeg on error anymore, and audio now prints an
error.
---
ffmpeg.c | 64 ++--
1 file changed, 30 insertions(+), 34 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index e8088c0..b7b0dc6 100644
--- a/ffmpeg.c
+++ b/ffmp
Hello,
In attach a patch to add 2 test for aphasemeter metadata
The sample can be found here :
https://we.tl/AP7SY8eNSe
As aphasemeter use float, i choose two "extreme" cases :
- a mono file, with result of 1.
- a out of phase 1000 Hz with result of -1.
Martin
From 73056155b32ad39c370518985de8
From: liangsi
---
libavformat/isom.h | 1 +
libavformat/mov.c | 5 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 2246fed..6824f7e 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -214,6 +214,7 @@ typedef struct MOVCo
On 9/5/16, Roger Pack wrote:
> On 9/4/16, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> 2016-08-20 12:09 GMT+02:00 Timo Rothenpieler :
>>> On 8/19/2016 3:28 PM, Roger Pack wrote:
No complaints, would someone please push it for me? Sorry still
haven't figured out the key thing yet.
>>>
>>> pushed
On 10/16/16, Michael Niedermayer wrote:
> On Mon, Oct 10, 2016 at 02:56:24PM -0600, Roger Pack wrote:
>> On 9/22/16, Roger Pack wrote:
>> > On 1/4/12, Yuval Adam wrote:
>> >> From: Yuval Adam
>> >>
>> >> The image2 muxer now supports timestamps in output filenames.
>> >> When used in an output
2016-10-24 23:11 GMT+02:00 Zhenni Huang :
[...]
Does the following inlined patch help you?
Carl Eugen
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 357d800..ed099fc 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4884,6 +4884,7 @@
a.type = avio_rl32(pb);
On Mon, Oct 24, 2016 at 10:31 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Oct 24, 2016 at 4:26 PM, Henrik Gramner wrote:
>
>> On Mon, Oct 24, 2016 at 9:59 PM, Ronald S. Bultje
>> wrote:
>> > Good idea to reference Hendrik Gramner here, who keeps insisting we get
>> rid
>> > of all MMX code in
2016-10-24 22:21 GMT+02:00 Martin Vignali :
> Hello,
>
> In attach new patchs.
> /* reorganize uncompress data. Each channel is stored one after the other */
(Sorry if I misread the code.)
Did you see AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_GBRP16
and AV_PIX_FMT_GBRAP16?
And the more I thin
On Sun, Oct 23, 2016 at 10:41:52PM -0700, Sasi Inguva wrote:
> Attaching the fate sample.
uploaded
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to
Hi Carl,
Thanks for your reply. Setting strict_std_compliance to 2 could help in
this case. However, as it is a global flag, it could influence other parts
in demuxers. It is preferable if we can have control of whether to use moov
in free with one separate flag.
Thanks,
Zhenni
On Mon, Oct 24, 2
2016-10-25 1:23 GMT+02:00 Zhenni Huang :
> Thanks for your reply. Setting strict_std_compliance to 2 could
> help in this case. However, as it is a global flag, it could influence
> other parts in demuxers.
Yes, this is intended: If you don't want to read invalid mov files, it
seems logical that
This should reduce the impact of a demuxer (or API user) setting bogus
codec parameters.
Suggested-by: wm4
Signed-off-by: Andreas Cadhalpun
---
libavcodec/utils.c | 82 +-
1 file changed, 81 insertions(+), 1 deletion(-)
diff --git a/libavcodec
The pass through mode is broken, since error is returned when none of the
stages is needed. In such a case only 0 should be returned.
Try command line with i/p resolution = o/p resolution to observe the issue.
Sample Command Line : ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i
amazing_10
Hi,
I have one question about some rare usage for avfilter graph:
Sometimes, I want to change the setting in avfilter graph. For example, fps
filter is used to set output frame rate, and it's expected that fps can be
changed in accordance to real needs. Sometimes, fps is set to 25, and later
66 matches
Mail list logo
