Hi,
2016-04-20 2:01 GMT+02:00 Ronald S. Bultje :
> This is typically only an issue if the data came from stack. On win64 as
> well as unix64, the 4th argument never comes from stack but is a direct
> register argument instead.
So no benefit except consistency. I don't mind either way, though.
On
Thank you the adding the D fixed it!
On Wed, 20 Apr 2016 at 09:36 Akshat Singh wrote:
> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu This guide, so
> should I switch to the other mailing list, yes I have a 64 bit platform,
> I'll try compiling using the new command...
>
> On Wed, 20 Apr
https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu This guide, so should
I switch to the other mailing list, yes I have a 64 bit platform, I'll try
compiling using the new command...
On Wed, 20 Apr 2016 at 01:57 Moritz Barsnick wrote:
> On Tue, Apr 19, 2016 at 19:53:07 +, Akshat Singh wrot
Signed-off-by: James Almer
---
tests/lavf-regression.sh | 2 +-
tests/ref/lavf-fate/latm | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
index f390dd9..7d7ed2c 100755
--- a/tests/lavf-regression.sh
+++ b/tests/lavf-reg
On 2016-04-19 12:56:23 +, KO Myung-Hun said:
I don't understand why you insist on using symlink. Even if without it,
current FFmpeg works well, maybe better in according to Dave. I don't
know what is the benefit from using symlink.
Likewise, I don't understand why you insist on not using s
On Thu, Apr 14, 2016 at 10:42:31PM -0300, James Almer wrote:
> On 4/14/2016 10:18 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > tests/fate-run.sh |4
> > tests/fate/vorbis.mak |7 ++-
> > tests/ref/fate/vorbis-18
Hi,
On Tue, Apr 19, 2016 at 4:42 PM, James Almer wrote:
> On 4/18/2016 6:25 PM, Christophe Gisquet wrote:
> > 2016-04-18 21:18 GMT+02:00 Michael Niedermayer :
> >> > this breaks (only noise)
> >> > \[CCCP\]_Mega_Weird_Audio_Test.mkv track 23
> > Worthwhile sample.
> >
> > I rewrote the patch to
On 4/18/2016 6:25 PM, Christophe Gisquet wrote:
> 2016-04-18 21:18 GMT+02:00 Michael Niedermayer :
>> > this breaks (only noise)
>> > \[CCCP\]_Mega_Weird_Audio_Test.mkv track 23
> Worthwhile sample.
>
> I rewrote the patch to reduce code duplication, and I fixed the issue
> (misread a shift).
>
>
On Mon, Apr 18, 2016 at 03:07:28PM +0200, Christophe Gisquet wrote:
> Cosmetics before macroing it and another function.
> ---
> libavcodec/wmalosslessdec.c | 94
> ++---
> 1 file changed, 47 insertions(+), 47 deletions(-)
ok
[...]
--
Michael GnuPG f
On Tue, Apr 19, 2016 at 05:41:05PM +, Petru Rares Sincraian wrote:
> Ups, sorry. Here is the patch :)
>
>
> From: ffmpeg-devel on behalf of Michael
> Niedermayer
> Sent: Tuesday, April 19, 2016 7:15 PM
> To: FFmpeg development discussions and patches
2016-04-13 20:17 GMT+02:00 Martin Vignali :
> Hello,
>
> In attach a patch, to change the way PXR24 uncompress calc the expected
> size.
>
> My previous patch (fix PXR24 float) doesn't work when all channels of a
> file
> doesn't have the same pixel type.
>
> Now this patch calc the expected_len c
On Tue, Apr 19, 2016 at 19:53:07 +, Akshat Singh wrote:
> I use this guide to compile ffmpeg and other libraries but I have come to
Which guide?
Questions regarding the compilation of ffmpeg and the use of the
command line tools should be directed to the ffmpeg-user mailing list.
What's more,
I used this guide to compile ffmpeg
https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu and I modified one
command as I described earlier... Do I have to edit some file in my library
or edit a file before compiling?
On Wed, 20 Apr 2016 at 01:32 Akshat Singh wrote:
> How do I apply this patch?
>
How do I apply this patch?
On Wed, 20 Apr 2016 at 01:24 Reimar Döffinger
wrote:
> ---
> libavcodec/dvbsub.c | 4 ++--
> libavfilter/drawutils.c | 8
> libavfilter/vf_drawbox.c | 4 ++--
> libavutil/colorspace.h | 8
> 4 files changed, 12 insertions(+), 12 deletions(-)
---
libavcodec/dvbsub.c | 4 ++--
libavfilter/drawutils.c | 8
libavfilter/vf_drawbox.c | 4 ++--
libavutil/colorspace.h | 8
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/libavcodec/dvbsub.c b/libavcodec/dvbsub.c
index 3cdbade..d2faef0 100644
--- a/lib
I use this guide to compile ffmpeg and other libraries but I have come to
learn that for x265 to support 10 bit encoding it has to manually specified
during the time of its compilation and from the information I could look up
I found that I had to add another command to cmake while compiling which
Carl Eugen Hoyos ag.or.at> writes:
> New patch attached that should improve conformance.
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, Apr 7, 2016 at 3:03 AM, Mark Thompson wrote:
> On 06/04/16 14:25, Amancio Hasty wrote:
> >
> >> On Apr 6, 2016, at 3:42 AM, wm4 wrote:
> >>
> >> On Wed, 6 Apr 2016 02:56:49 -0700
> >> Amancio Hasty wrote:
> >>
> >>> If you think is better and it works , are there any plans to
> incorpor
Ups, sorry. Here is the patch :)
From: ffmpeg-devel on behalf of Michael
Niedermayer
Sent: Tuesday, April 19, 2016 7:15 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] Add test for mts2 (mss4) codec
On Tue, Apr 19,
This is a tricky one.. I tried your sample in VLC, and it has the same
issue as the latest version of ffmpeg.
The previous behavior of ffmpeg can be restored with the following patch:
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 3b15149..9eff843 100644
--- a/libavcodec
On Tue, Apr 19, 2016 at 04:26:12PM +, Petru Rares Sincraian wrote:
> Hi there,
>
> Here is a patch for the mts2 codec. You can download the sample here:
> https://drive.google.com/open?id=0ByhGgswO8BQcbVBwS2pEUkNTN2c
> The sample is supposed to be in $(TARGET_SAMPLES)/mts2/sample.xesc
>
> md
On Tue, Apr 19, 2016 at 11:49:12AM +0200, wm4 wrote:
> This affects the wrapper for the old decode API. The new decode API uses
> EAGAIN to signal that a packet must be sent again, while the old API
> considers the packet fully consumed (and it's also not an error).
>
> This affects e.g.: tickets/
Hi there,
Here is a patch for the mts2 codec. You can download the sample here:
https://drive.google.com/open?id=0ByhGgswO8BQcbVBwS2pEUkNTN2c
The sample is supposed to be in $(TARGET_SAMPLES)/mts2/sample.xesc
md5: 47f13a4a49bd8955491a9421b6db3751
Thanks,
Petru Rares.
__
On Tue, Apr 19, 2016 at 3:15 PM, Carl Eugen Hoyos wrote:
> Could you explain how I can reproduce the incompleteness?
> Visibly if possible...
It seems right now that we have a function (macro) to convert
(seemingly limited range?) YCbCr to limited range or full range RGB,
both (seemingly) followi
On Tue, Apr 19, 2016 at 01:28:01AM -0500, Rodger Combs wrote:
> ---
> libavutil/opt.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index eae4f75..83093e0 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -275,11 +2
On Tue, 19 Apr 2016 16:31:40 +0200
Michael Niedermayer wrote:
> On Tue, Apr 19, 2016 at 11:49:11AM +0200, wm4 wrote:
> > Until now, the decoding API was restricted to outputting 0 or 1 frames
> > per input packet. It also enforces a somewhat rigid dataflow in general.
> >
> > This new API seeks
Updated patch attached.
On Sat, Apr 16, 2016 at 7:08 PM, Michael Niedermayer
wrote:
> On Sun, Apr 03, 2016 at 03:38:33PM -0700, Neil Birkbeck wrote:
>> Use "master_display" key/value pair to specify mastering metadata in a
>> similar formatting as accepted by libx265 (unless there is some other
>
On Dienstag, 19. April 2016 13:25:53 CEST Moritz Barsnick wrote:
> Just some random observations from me.
>
> > BTW:
> > ./ffmpeg -i ~/test2.mkv -vf signature=xml:filename=signature.xml -f null -
> > fails because xml is not a valid parameter.
> > ./ffmpeg -i ~/test2.mkv -vf
> > signature=xml:fil
On Tue, Apr 19, 2016 at 11:49:11AM +0200, wm4 wrote:
> Until now, the decoding API was restricted to outputting 0 or 1 frames
> per input packet. It also enforces a somewhat rigid dataflow in general.
>
> This new API seeks to relax these restrictions by decoupling input and
> output. Instead of d
On 2016-04-19 06:03:52 +, Dave Yeo said:
The problem is that symlinks on OS/2 (unless using TVFS.IFS) are
inherently fragile. It just takes one utility that is not aware of them
to break things and not everything is linked against kLIBC. In FFmpegs
case we use lxlite, which is a Pascal progr
Hi/2.
Dmitriy Kuminov wrote:
> On 2016-04-18 11:52:15 +, KO Myung-Hun said:
>
>> Strange conclusion. Anyway not important.
>
> In Dave's case the symlink functionality check fails because it is
> performed in TMPDIR which is located on ramfs.ifs (which fails to use
> symlinks). But I believe
Hendrik Leppkes gmail.com> writes:
> Maybe we should define a "proper" solution (ie. creating a BT.709
> conversion for HD)
I am waiting for your patches since yesterday;-(
> instead of pushing for an incomplete fix.
Could you explain how I can reproduce the incompleteness?
Visibly if possible
On Tue, 19 Apr 2016 08:07:05 + (UTC)
Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
> > the original patch "improves" it to some degree, as the PAL8
> > format that subtitles come in should be considered a full-range
> > RGB format, but its still not the correct HD RGB colo
Just some random observations from me.
> BTW:
> ./ffmpeg -i ~/test2.mkv -vf signature=xml:filename=signature.xml -f null -
> fails because xml is not a valid parameter.
> ./ffmpeg -i ~/test2.mkv -vf
> signature=xml:filename=signature.xml:detectmode=full -f null -
> fails not, but write binary to
On Tue, Apr 19, 2016 at 10:07 AM, Carl Eugen Hoyos wrote:
> Hendrik Leppkes gmail.com> writes:
>
>> the original patch "improves" it to some degree, as the PAL8
>> format that subtitles come in should be considered a full-range
>> RGB format, but its still not the correct HD RGB colorspace.
>
> S
On Mon, Apr 18, 2016 at 11:25:30PM +0200, Christophe Gisquet wrote:
> 2016-04-18 21:18 GMT+02:00 Michael Niedermayer :
> > this breaks (only noise)
> > \[CCCP\]_Mega_Weird_Audio_Test.mkv track 23
>
> Worthwhile sample.
>
> I rewrote the patch to reduce code duplication, and I fixed the issue
> (m
Le septidi 27 ventôse, an CCXXIV, Kieran Kunhya a écrit :
> I want to try and use the libavfilter API to overlay bitmap subtitles on
> video from a realtime source. This seems difficult/impossible to do with
> the current API hence asking on the main devel list.
Have you looked at what the command
This affects the wrapper for the old decode API. The new decode API uses
EAGAIN to signal that a packet must be sent again, while the old API
considers the packet fully consumed (and it's also not an error).
This affects e.g.: tickets/574/Issue200Regression.latm
---
Can be squashed with previous c
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the p
From Libav commit 8bc4accc37ab047d2fd85d672c577b39dfc918e1, with
additional code for decoding subtitles (not present in Libav).
Signed-off-by: Anton Khirnov
---
This commit was skipped during merge.
Not touching ffmpeg.c yet, because its handling of drain packet
DTS simply is incompatible with t
---
libavcodec/audiotoolboxdec.c | 82 +---
1 file changed, 54 insertions(+), 28 deletions(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 58d05f8..2748e8d 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoo
---
libavcodec/audiotoolboxdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 31e14d4..58d05f8 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -414,6 +414,7 @@ static OSStatus ffat_decode_callb
Hendrik Leppkes gmail.com> writes:
> the original patch "improves" it to some degree, as the PAL8
> format that subtitles come in should be considered a full-range
> RGB format, but its still not the correct HD RGB colorspace.
So does everybody agree that it should be committed?
Carl Eugen
__
Hi,
I've been playing for the last couple of days with FFMpeg and FFServer as
are considering as a candidate for live-streaming between an embedded
device(with an integrated HD camera) and various clients(smartphones).
I've managed to achieve this using with the following config for FFServer:
HT
44 matches
Mail list logo
