On Fri, Jun 24, 2016 at 10:03:17PM -0400, Rick Kern wrote:
> decklink_common.cpp includes a .cpp file from the DeckLink API which fails
> to build because there are non-static functions in the included .cpp file.
> This disables the missing-prototypes error so the file can be included.
why does th
On Fri, Jun 24, 2016 at 09:54:54PM -0700, Amancio Hasty wrote:
>
> > On Jun 24, 2016, at 7:39 PM, Michael Niedermayer
> > wrote:
> >
> > On Fri, Jun 24, 2016 at 06:52:01PM -0700, Amancio Hasty wrote:
> >>
> >>> On Jun 24, 2016, at 6:31 PM, Michael Niedermayer
> >>> wrote:
> >>>
> >>> On Thu
On 6/25/16, Muhammad Faiz wrote:
> On Sat, Jun 25, 2016 at 1:23 AM, Paul B Mahol wrote:
>> Hi,
>>
>> patch attached.
>>
>
> >From 5b55c9c44ea103cdff3c34882dbcca29902728a4 Mon Sep 17 00:00:00 2001
>>From: Paul B Mahol
>>Date: Fri, 24 Jun 2016 20:16:22 +0200
>>Subject: [PATCH] avfilter/vf_rotate:
On Sat, Jun 25, 2016 at 11:03:27AM +0200, Michael Niedermayer wrote:
> On Fri, Jun 24, 2016 at 09:54:54PM -0700, Amancio Hasty wrote:
> >
> > > On Jun 24, 2016, at 7:39 PM, Michael Niedermayer
> > > wrote:
> > >
> > > On Fri, Jun 24, 2016 at 06:52:01PM -0700, Amancio Hasty wrote:
> > >>
> > >>
Hi,
patch attached.
From fbf2d600e048a417183ab32fdb2e7e2bcf238071 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sat, 25 Jun 2016 11:33:46 +0200
Subject: [PATCH] avformat/mov: parse rtmd track timecode
Signed-off-by: Paul B Mahol
---
libavformat/mov.c | 30 +-
1
On Sat, Jun 25, 2016 at 11:36:05AM +0200, Paul B Mahol wrote:
> Hi,
>
> patch attached.
> From fbf2d600e048a417183ab32fdb2e7e2bcf238071 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Sat, 25 Jun 2016 11:33:46 +0200
> Subject: [PATCH] avformat/mov: parse rtmd track timecode
>
> Signed-off
On Fri, Jun 24, 2016 at 06:27:38PM +0200, Jens Ziller wrote:
> Hello,
>
> deinterlacing need frame->interlaced_frame and format struct. This
> patch added this to AVFrame.
>
> Regards Jens.
> mmaldec.c | 16
> 1 file changed, 16 insertions(+)
> 6351a54c36d98d1f6ffdaeea96af8c0
On Fri, Jun 24, 2016 at 03:14:42PM -0700, Michael Graczyk wrote:
> I fixed a comment typo and slightly modified an error message in the second
> patch. I attached updated versions. Please let me know if you have any
> thoughts on these patches.
yes, rereading this a bit
can you explain what is the
On Thu, Jun 23, 2016 at 12:14:47AM +, sami.h...@gmail.com wrote:
> From: Sami Hult
>
> I changed output=print file handling of metadata filter to accept any ffmpeg
> url. This way multiple streams can for example be silencedetected and the
> result directed to different outputs.
>
> Exampl
On Fri, 17 Jun 2016, sebechlebsky...@gmail.com wrote:
From: Jan Sebechlebsky
Signed-off-by: Jan Sebechlebsky
---
I've missed that - sorry, should be fixed in this patch.
[...]
static int open_slave(AVFormatContext *avf, char *slave, TeeSlave *tee_slave)
@@ -443,24 +442,26 @@ static int
On Fri, Jun 24, 2016 at 09:20:35AM +0200, Benoit Fouet wrote:
[...]
> >>Any objection to this patch now?
> >iam ok with the patch, maybe give others a bit of time to reply
> >before applying though
>
> Yeah, I'm in no hurry, I just saw this FIXME in the context of one of
> Mateo's patches.
> I was
On Wed, Jun 22, 2016 at 07:13:12PM +0200, David Murmann wrote:
> movenc.c | 81
> +++
> movenc.h |1
> 2 files changed, 78 insertions(+), 4 deletions(-)
> 29f4a09d448563a71af25417c0db7bd7610f42a6
> 0002-avformat-movenc-add-optio
On 06/25/2016 11:17 AM, Michael Niedermayer wrote:
>> where is that patch ?
>> i see
>> " --enable-omx-rpi enable encoding via OpenMAX IL for Raspberry Pi
>> [no]"
>> in ffmpeg git, what is missing?
>
> looking at tmm1/rebase-omx i only see 2 one line patches that we
> dont have yet
> i c
On Sun, 12 Jun 2016, Nicolas George wrote:
Le quintidi 25 prairial, an CCXXIV, Marton Balint a écrit :
So you probably don't have to
support multiple filters, it is enough if you support a single one.
This is not settled. I still think a specific
> On Jun 25, 2016, at 5:41 AM, Jan Gerber wrote:
>
> On 06/25/2016 11:17 AM, Michael Niedermayer wrote:
>>> where is that patch ?
>>> i see
>>> " --enable-omx-rpi enable encoding via OpenMAX IL for Raspberry Pi
>>> [no]"
>>> in ffmpeg git, what is missing?
>>
>> looking at tmm1/rebase-
On 06/25/2016 02:45 PM, Amancio Hasty wrote:
> Most cool. Can you post the exact command line that you used to
> test h264_omx?
git remote add tmm1 https://github.com/tmm1/FFmpeg
git fetch tmmi1
git checkout -b omx
git cherry-pick 2a1fcc3775a390570679da7f507539a397fc7130
git cherry-pick 1087f0dc1
On Sat, Jun 25, 2016 at 3:02 PM, Jan Gerber wrote:
> On 06/25/2016 02:45 PM, Amancio Hasty wrote:
>> Most cool. Can you post the exact command line that you used to
>> test h264_omx?
>
> git remote add tmm1 https://github.com/tmm1/FFmpeg
> git fetch tmmi1
> git checkout -b omx
> git cherry-pick 2a
> On Jun 25, 2016, at 6:53 AM, Hendrik Leppkes wrote:
>
> On Sat, Jun 25, 2016 at 3:02 PM, Jan Gerber wrote:
>> On 06/25/2016 02:45 PM, Amancio Hasty wrote:
>>> Most cool. Can you post the exact command line that you used to
>>> test h264_omx?
>>
>> git remote add tmm1 https://github.com/tmm1/
From: Jan Sebechlebsky
Signed-off-by: Jan Sebechlebsky
---
You're right. Should be fixed here.
libavformat/tee.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index 806beaa..9d0a4cb 100644
--- a/libavform
On 6/25/16, Clement Boesch wrote:
> On Sat, Jun 25, 2016 at 11:36:05AM +0200, Paul B Mahol wrote:
>> Hi,
>>
>> patch attached.
>
>> From fbf2d600e048a417183ab32fdb2e7e2bcf238071 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Sat, 25 Jun 2016 11:33:46 +0200
>> Subject: [PATCH] avformat/mo
Hello,
In attach a patch who fix, the float decoding of b44 files when there is
half and float channel.
float (and uint32) data are not compressed when B44 compression is used
(only half data are compressed).
Comments welcome
Martin
Jokyo Images
From 56b7bda0aaaba9dc2833b5e31b8843c589ffd6fc Mo
On June 22, 2016 at 12:12:02 PM, Amancio Hasty (aha...@gmail.com) wrote:
On Jun 22, 2016, at 10:20 AM, Aman Gupta wrote:
This patch should fix the assertion failure you see:
https://github.com/FFmpeg/FFmpeg/commit/1087f0dc172a9adf779e41bf2dc82639fb04ebd4
Aman
On Sat, Jun 18, 2016 at 8:43 AM Am
On 6/25/16, Martin Vignali wrote:
> Hello,
>
> In attach a patch who fix, the float decoding of b44 files when there is
> half and float channel.
>
> float (and uint32) data are not compressed when B44 compression is used
> (only half data are compressed).
>
Applied.
>
> Comments welcome
>
> Mar
2016-06-25 18:17 GMT+02:00 Paul B Mahol :
> On 6/25/16, Martin Vignali wrote:
> > Hello,
> >
> > In attach a patch who fix, the float decoding of b44 files when there is
> > half and float channel.
> >
> > float (and uint32) data are not compressed when B44 compression is used
> > (only half data
On 6/25/16, Martin Vignali wrote:
> 2016-06-25 18:17 GMT+02:00 Paul B Mahol :
>
>> On 6/25/16, Martin Vignali wrote:
>> > Hello,
>> >
>> > In attach a patch who fix, the float decoding of b44 files when there
>> > is
>> > half and float channel.
>> >
>> > float (and uint32) data are not compresse
Hello,
In attach,
the diff between the two previous patch, in order to add fix for b44a
compression when there is float data inside the file
Before this patch, b44a block are not detected when there is float channel
before half channel (b44a only compress half channel).
Comments welcome
Martin
On 6/25/16, Martin Vignali wrote:
> Hello,
>
> In attach,
> the diff between the two previous patch, in order to add fix for b44a
> compression when there is float data inside the file
>
> Before this patch, b44a block are not detected when there is float channel
> before half channel (b44a only c
On Sat, Jun 25, 2016 at 03:02:30PM +0200, Jan Gerber wrote:
> On 06/25/2016 02:45 PM, Amancio Hasty wrote:
> > Most cool. Can you post the exact command line that you used to
> > test h264_omx?
>
> git remote add tmm1 https://github.com/tmm1/FFmpeg
> git fetch tmmi1
> git checkout -b omx
> git c
2016-06-25 18:39 GMT+02:00 Paul B Mahol :
> On 6/25/16, Martin Vignali wrote:
> > Hello,
> >
> > In attach,
> > the diff between the two previous patch, in order to add fix for b44a
> > compression when there is float data inside the file
> >
> > Before this patch, b44a block are not detected whe
On Thu, Jun 23, 2016 at 11:00:48PM +0200, Michael Niedermayer wrote:
> Hi all
>
> what shall FFmpeg 3.1 be called ?
>
> I still have these ideas from past suggestions:
> Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss,
> Galois, Viterbi, Darwin
>
> Are there other suggesti
On 06/25/2016 06:50 PM, Michael Niedermayer wrote:
>> git cherry-pick 1087f0dc172a9adf779e41bf2dc82639fb04ebd4
>
> is this or 0c9c4004ed57de210b4d83c7b39bbfb00b86b9af preferred ?
both are ok, would use 0c9c4004ed57de210b4d83c7b39bbfb00b86b9af
to keep the delta to libav smaller.
__
Paul B Mahol gmail.com> writes:
> >>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
> >
> > Why not use native endian format?
>
> Because of fate test.
Isn't the byte-swapping (that could be used for the
fate test) bit-exact? Or do I miss something?
Carl Eugen
___
Michael Niedermayer niedermayer.cc> writes:
> why does this happen ?
I thought it happens because FFmpeg include third-party
files that do not copmile with error=missing-prototypes.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
Hi,
Patch attached.
Umair
From 56281948ec484c19dd9009c861ded38905e1b786 Mon Sep 17 00:00:00 2001
From: Umair Khan
Date: Sat, 25 Jun 2016 22:48:02 +0530
Subject: [PATCH] avcodec/als: floating point support in ALS decoder
Signed-off-by: Umair Khan
---
libavcodec/Makefile | 2 +-
lib
Rick Kern gmail.com> writes:
> Fixes #5654.
Can you reproduce and test?
I was also looking at CVPixelBufferGetBytesPerRow() but I was
wondering if FFmpeg maybe uses an incorrect width; does
CVPixelBufferGetWidth() return the expected value?
> +int src_linesize[4];
> +memset(src_lines
On Sun, Jun 05, 2016 at 11:40:47PM +0200, Michael Niedermayer wrote:
> On Thu, Apr 07, 2016 at 08:08:41PM +0200, wm4 wrote:
> > On Thu, 7 Apr 2016 17:51:26 +0200
> > Michael Niedermayer wrote:
> >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/format.c | 16 ++--
Hello,
In attach patch in order to add several tests for tile and scanline exr file
who have half and float channels.
It also cover compression in tile (except for piz)
and now cover the layer option of exr.
(reason why each file have two tests (one for each layer))
There is more tests for pxr2
On 6/25/16, Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
>> >>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
>> >
>> > Why not use native endian format?
>>
>> Because of fate test.
>
> Isn't the byte-swapping (that could be used for the
> fate test) bit-exact? Or do I miss
Am 25.06.16 um 19:45 schrieb Carl Eugen Hoyos:
> Rick Kern gmail.com> writes:
>
>> Fixes #5654.
>
> Can you reproduce and test?
> I was also looking at CVPixelBufferGetBytesPerRow() but I was
> wondering if FFmpeg maybe uses an incorrect width; does
> CVPixelBufferGetWidth() return the expecte
On Sat, Jun 25, 2016 at 05:29:56PM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer niedermayer.cc> writes:
>
> > why does this happen ?
>
> I thought it happens because FFmpeg include third-party
> files that do not copmile with error=missing-prototypes.
but why should they build with ran
On Sat, Jun 25, 2016 at 07:21:15PM +0200, Jan Gerber wrote:
> On 06/25/2016 06:50 PM, Michael Niedermayer wrote:
> >> git cherry-pick 1087f0dc172a9adf779e41bf2dc82639fb04ebd4
> >
> > is this or 0c9c4004ed57de210b4d83c7b39bbfb00b86b9af preferred ?
>
> both are ok, would use 0c9c4004ed57de210b4d83c
Hello,
In attach a patch to add a fate test for WebP lossless rgb
Sample can be found here : https://we.tl/dmPsitbwXK
and need to be put inside ./fate-suite/webp (the webp folder doesn't exists)
to test :
make fate-webp SAMPLES=fate-suite/
I doesn't make fate test, for lossy rgb/rgba, because
On 6/25/2016 4:43 PM, Martin Vignali wrote:
> Hello,
>
> In attach a patch to add a fate test for WebP lossless rgb
>
> Sample can be found here : https://we.tl/dmPsitbwXK
>
> and need to be put inside ./fate-suite/webp (the webp folder doesn't exists)
>
> to test :
> make fate-webp SAMPLES=fat
2016-06-25 21:47 GMT+02:00 James Almer :
> On 6/25/2016 4:43 PM, Martin Vignali wrote:
> > Hello,
> >
> > In attach a patch to add a fate test for WebP lossless rgb
> >
> > Sample can be found here : https://we.tl/dmPsitbwXK
> >
> > and need to be put inside ./fate-suite/webp (the webp folder does
2016-06-25 21:52 GMT+02:00 Martin Vignali :
>
>
> 2016-06-25 21:47 GMT+02:00 James Almer :
>
>> On 6/25/2016 4:43 PM, Martin Vignali wrote:
>> > Hello,
>> >
>> > In attach a patch to add a fate test for WebP lossless rgb
>> >
>> > Sample can be found here : https://we.tl/dmPsitbwXK
>> >
>> > and n
On 6/25/2016 4:52 PM, Martin Vignali wrote:
> 2016-06-25 21:47 GMT+02:00 James Almer :
>
>> On 6/25/2016 4:43 PM, Martin Vignali wrote:
>>> Hello,
>>>
>>> In attach a patch to add a fate test for WebP lossless rgb
>>>
>>> Sample can be found here : https://we.tl/dmPsitbwXK
>>>
>>> and need to be p
On Sat, Jun 25, 2016 at 09:56:15PM +0200, Martin Vignali wrote:
> 2016-06-25 21:52 GMT+02:00 Martin Vignali :
>
> >
> >
> > 2016-06-25 21:47 GMT+02:00 James Almer :
> >
> >> On 6/25/2016 4:43 PM, Martin Vignali wrote:
> >> > Hello,
> >> >
> >> > In attach a patch to add a fate test for WebP lossle
On Sat, Jun 25, 2016 at 08:24:21PM +0200, Martin Vignali wrote:
> Hello,
>
> In attach patch in order to add several tests for tile and scanline exr file
> who have half and float channels.
>
>
> It also cover compression in tile (except for piz)
> and now cover the layer option of exr.
> (reaso
On Sat, Jun 25, 2016 at 10:52:40PM +0530, Umair Khan wrote:
> Hi,
>
> Patch attached.
>
> Umair
> libavcodec/Makefile |2
> libavcodec/alsdec.c | 286
> +-
> libavcodec/mlz.c | 162 +++
> libavc
---
libavformat/movenc.c | 70 ++--
1 file changed, 30 insertions(+), 40 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d614933..9668b9c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5475,21 +5475,18 @
---
tests/fate/hevc.mak | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 05266cd..fa63afd 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -225,6 +225,17 @@ $(foreach N,$(HEVC_SAMPLES_444_12BIT),$(eval $(call
FATE_HEVC_T
This is mostly useful for muxers that wrap other muxers, such as dashenc
and segment. The actual duplicated bitstream filtering is largely harmless,
but delaying the header can cause problems when the muxer intended the header
to be written to a separate file.
---
libavformat/avformat.h | 1 +
---
tests/fate/aac.mak | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
index 3d64031..b02b768 100644
--- a/tests/fate/aac.mak
+++ b/tests/fate/aac.mak
@@ -241,6 +241,10 @@ FATE_AAC_LATM += fate-aac-latm_stereo_to_51
fate-aac-l
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-autobsf-mp4toannexb | 1 +
2 files changed, 3 insertions(+)
create mode 100644 tests/ref/fate/h264-autobsf-mp4toannexb
diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index 4ae1305..e0a5446 100644
--- a/tests/fate/h26
---
libavformat/segment.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index d22d550..d8877f0 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -89,6 +89,7 @@ typedef struct SegmentCo
---
libavformat/segment.c | 47 ---
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 4c6c6d4..d22d550 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -627,8 +627,9 @@ st
---
libavformat/dashenc.c | 51 +--
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 519f9c4..0848052 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -580,16 +580,12
This is disabled by default when the empty_moov flag is enabled
---
libavformat/dashenc.c | 43 +++-
libavformat/movenc.c | 107 +++---
2 files changed, 124 insertions(+), 26 deletions(-)
diff --git a/libavformat/dashenc.c b/libavforma
This allows a consumer to run the muxer's init function without actually
writing the header, which is useful in chained muxers that support
automatic bitstream filtering.
---
libavformat/avformat.h | 34 +--
libavformat/internal.h | 10
libavformat/mux.c | 64
On June 25, 2016 at 12:42:52 PM, Michael Niedermayer (mich...@niedermayer.cc)
wrote:
On Sat, Jun 25, 2016 at 07:21:15PM +0200, Jan Gerber wrote:
> On 06/25/2016 06:50 PM, Michael Niedermayer wrote:
> >> git cherry-pick 1087f0dc172a9adf779e41bf2dc82639fb04ebd4
> >
> > is this or 0c9c4004ed57de210b4
On Sat, 25 Jun 2016, sebechlebsky...@gmail.com wrote:
From: Jan Sebechlebsky
Signed-off-by: Jan Sebechlebsky
---
You're right. Should be fixed here.
libavformat/tee.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
Thanks, applied.
Regards,
Marton
_
On Wed, May 25, 2016 at 06:07:24PM +0200, Michael Niedermayer wrote:
> TODO: docs
>
> This can also be extended to remove discontiuities caused by seek commands
>
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/src_movie.c | 22 ++
> 1 file changed, 22 insertions(
On Sat, Jun 25, 2016 at 12:43:35AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/dualinput.c |3 +++
> libavfilter/dualinput.h |1 +
> 2 files changed, 4 insertions(+)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF1336
On Tue, Jun 21, 2016 at 12:54:09PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_sei.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B
On Sun, Jun 26, 2016 at 1:51 AM, Paul B Mahol wrote:
> On 6/25/16, Carl Eugen Hoyos wrote:
>> Paul B Mahol gmail.com> writes:
>>
>>> >>+AV_PIX_FMT_YUV420P9LE, AV_PIX_FMT_YUVA420P9LE,
>>> >
>>> > Why not use native endian format?
>>>
>>> Because of fate test.
>>
>> Isn't the byte-swapping
Muhammad Faiz gmail.com> writes:
> I think it's not because of bit-exact problem.
> But because fate probes supported formats (with libavfilter/tests/filtfmts)
> On BE machine, code with native formats will generate error
> because fate-ref contains yuv*le entries but fate expects yuv*be
We cont
On Sat, Jun 25, 2016 at 12:43:36AM +0200, Michael Niedermayer wrote:
> Fixes crash due to unprocessed input being passed through
>
> This fixes the last segfault caused by mixing 3.0 and 3.1 libs and
> applications
>
> Signed-off-by: Michael Niedermayer
> ---
applied
[...]
--
Michael GnuP
Hi all
ive branched release/3.1 off from master
i will make the 3.1 release from HEAD of this branch tomorrow
If there are any last minute changes that should go in, thats your
very last chance to put them in !
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While th
68 matches
Mail list logo
