On Sat, Feb 27, 2016 at 01:05:35AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 10:34:45PM +0100, Clément Bœsch wrote:
> > ---
> > libswscale/yuv2rgb.c | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
>
> LGTM
>
> thanks
>
applied
--
Clément B.
On Sat, Feb 27, 2016 at 01:06:08AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 10:34:46PM +0100, Clément Bœsch wrote:
> > It makes easier looking at the difference with the generic code just
> > below.
> > ---
> > libswscale/yuv2rgb.c | 12 ++--
> > 1 file changed, 6 insert
Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You're saying that the size of the packet isn't
fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes
exclusively. Will thi
On 02/27/2016 11:44 AM, Mats Peterson wrote:
Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You're saying that the size of the packet isn't
fixed to 1024 bytes, but currently it seems to be
On 02/27/2016 11:51 AM, Mats Peterson wrote:
On 02/27/2016 11:44 AM, Mats Peterson wrote:
Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You're saying that the size of the packet isn't
fix
On 02/27/2016 12:02 PM, Mats Peterson wrote:
On 02/27/2016 11:51 AM, Mats Peterson wrote:
On 02/27/2016 11:44 AM, Mats Peterson wrote:
Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You'r
Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 27 +++
libavutil/frame.h |
On Sat, Feb 27, 2016 at 02:21:18AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 11:06:22PM +0100, Reimar Döffinger wrote:
> > +static void validate_avframe_allocation(const AVCodecContext *avctx,
> > AVFrame *frame)
> > +{
> > +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
> >
On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 22:59:17 +0100
> Reimar Döffinger wrote:
> > > Can you move it to a separate function? Say, ff_verify_frame(). This
> > > could get much more complicated too when checking AVBufferRef usage or
> > > audio.
> >
> > Why ff
Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.
Signed-off-by: Reimar Döffinger
---
doc/APIchanges | 6 ++
libavcodec/utils.c | 27 ++
On Sat, Feb 27, 2016 at 01:01:40PM +0100, Reimar Döffinger wrote:
> Check that the required plane pointers and only
> those are set up.
> Currently does not enforce anything for the palette
> pointer of pseudopal formats as I am unsure about the
> requirements.
>
> Signed-off-by: Reimar Döffinger
On Sat, 27 Feb 2016 12:54:50 +0100
Reimar Döffinger wrote:
> On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote:
> > On Fri, 26 Feb 2016 22:59:17 +0100
> > Reimar Döffinger wrote:
> > > > Can you move it to a separate function? Say, ff_verify_frame(). This
> > > > could get much more complica
On 2016-02-27 04:09, Ryan Schott wrote:
> Hello,
>
> I am not sure if this is the right page to post this, but your consulting
> page recommended I use this list. I recent built an audio visualization app
> using html5. I'm currently using that app with xsplit to stream music to an
> RTMP endpoint
On Wed, Feb 24, 2016 at 04:59:51PM -0600, Rodger Combs wrote:
> ---
> libavcodec/Makefile | 1 +
> 1 file changed, 1 insertion(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
On Fri, Feb 26, 2016 at 01:07:54PM +0100, Reimar Döffinger wrote:
> On Fri, Feb 26, 2016 at 12:59:08PM +0100, Michael Niedermayer wrote:
> > This should return an error to the decoder if the struct it tried to
> > getbuffer is dirty
>
> It seems like a good idea, however it likely won't help
> fo
On Sat, 27 Feb 2016 13:01:40 +0100
Reimar Döffinger wrote:
> Check that the required plane pointers and only
> those are set up.
> Currently does not enforce anything for the palette
> pointer of pseudopal formats as I am unsure about the
> requirements.
>
> Signed-off-by: Reimar Döffinger
> --
Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I have
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
movenc.c for calculating the number of palette entries in packets
containing a palet
On Thu, Feb 25, 2016 at 8:55 AM, Hendrik Leppkes wrote:
> On Thu, Feb 25, 2016 at 8:27 AM, wm4 wrote:
>> On Thu, 25 Feb 2016 15:48:17 +1100
>> Matt Oliver wrote:
>>
>>> On 25 February 2016 at 13:20, Ganesh Ajjanagadde wrote:
>>>
>>> > From: Ganesh Ajjanagadde
>>> >
>>> > These use __builtin_ex
On Thu, Feb 25, 2016 at 7:25 AM, Nicolas George wrote:
> Le sextidi 6 ventôse, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Actual performance benefit is impossible to accurately quantify due to the
>> context-dependence of the branch predictor. Nonetheless, as a ballpark
>> estimate, it yields ~ 5%
On 02/27/2016 02:03 PM, Mats Peterson wrote:
Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I have
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
movenc.c for calculating the number of pa
On Thu, Feb 25, 2016 at 8:56 AM, Derek Buitenhuis
wrote:
> On 2/25/2016 2:20 AM, Ganesh Ajjanagadde wrote:
>> -// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64
>> +// (int64_t)rint() and llrint() do not work with gcc on ia64 and
>> sparc64,
>> +// see Ticket271
On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:
> On 02/27/2016 02:03 PM, Mats Peterson wrote:
> >Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
> >In case there will be other palettized formats in the future, I have
> >"guarded" myself by using 1 << bits_pe
Hi,
On Sat, Feb 27, 2016 at 8:11 AM, Ganesh Ajjanagadde
wrote:
> On Thu, Feb 25, 2016 at 8:55 AM, Hendrik Leppkes
> wrote:
> > On Thu, Feb 25, 2016 at 8:27 AM, wm4 wrote:
> >> On Thu, 25 Feb 2016 15:48:17 +1100
> >> Matt Oliver wrote:
> >>
> >>> On 25 February 2016 at 13:20, Ganesh Ajjanagadd
On 02/27/2016 02:44 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:
On 02/27/2016 02:03 PM, Mats Peterson wrote:
Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I ha
On 02/27/2016 02:55 PM, Mats Peterson wrote:
On 02/27/2016 02:44 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:
On 02/27/2016 02:03 PM, Mats Peterson wrote:
Currently the only palettized pixel format in FFmpeg is
AV_PIX_FMT_PAL8.
In case there will b
On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote:
> And yes, QuickTime has a "default palette" for each bit depth that it can
> use, and no palette will be stored in the video sample description in that
> case. But that's only sensible to use for 1 bpp black & white or 8 bpp
> grayscal
On 02/27/2016 03:11 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote:
And yes, QuickTime has a "default palette" for each bit depth that it can
use, and no palette will be stored in the video sample description in that
case. But that's only sensible to us
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 309ee0932eda48b340f2da9f2bc9ac3ea667edf9 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sat, 27 Feb 2016 15:31:08 +0100
Subject: [PATCH 1/2] lavf/avienc: Simplify palette handling
---
libavformat/avienc.c |4 ++--
1 file changed,
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From eec3d4bb49d0ac4b73a10f8436d517a130999892 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sat, 27 Feb 2016 15:31:35 +0100
Subject: [PATCH 2/2] lavf/movenc: Simplify palette handling
---
libavformat/movenc.c |9 -
1 file chan
On 02/27/2016 03:37 PM, Mats Peterson wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I suppose this is what you mean, Reimar. Treating the palette, if a
packet contains one at the end
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
> On 02/27/2016 03:37 PM, Mats Peterson wrote:
> >
> >
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> I suppose
On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
On 02/27/2016 03:37 PM, Mats Peterson wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffm
On 02/27/2016 04:07 PM, Mats Peterson wrote:
On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
On 02/27/2016 03:37 PM, Mats Peterson wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
On 02/27/2016 04:08 PM, Mats Peterson wrote:
On 02/27/2016 04:07 PM, Mats Peterson wrote:
On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
On 02/27/2016 03:37 PM, Mats Peterson wrote:
On 02/27/2016 04:13 PM, Mats Peterson wrote:
On 02/27/2016 04:08 PM, Mats Peterson wrote:
On 02/27/2016 04:07 PM, Mats Peterson wrote:
On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
On 02/27/2016 03:37 PM, Mats Peterson wrote:
On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > On Tue, 23 Feb 2016 09:53:43 +0100
> > Matthieu Bouron wrote:
> >
> > > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer wrote:
> > > > On Mon, Feb 22, 2016 at
On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:
> On 02/27/2016 04:13 PM, Mats Peterson wrote:
> >On 02/27/2016 04:08 PM, Mats Peterson wrote:
> >>On 02/27/2016 04:07 PM, Mats Peterson wrote:
> >>>On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
> On Sat, Feb 27, 2016 at 03:57:06P
On 02/27/2016 05:45 PM, Reimar Döffinger wrote:
I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anywa
My observation of the current state of palette storage in FFmpeg is as
follows:
On the demuxer side, side data packets are usually used for the palette,
except for nut, where the palette is appended to the video data in each
packet, in the same way as on the muxer side.
On the muxer side, th
On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote:
> On 02/27/2016 05:45 PM, Reimar Döffinger wrote:
> >>Not that it couldn't be done with side data packets, though.
> >
> >If it doesn't support side data then the muxers are plain broken.
>
> The muxers should support side data, I agre
On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote:
On 02/27/2016 05:45 PM, Reimar Döffinger wrote:
Not that it couldn't be done with side data packets, though.
If it doesn't support side data then the muxers are plain broken.
The m
On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.
Stream copying of raw palettized data seldom works well, due to
different strides of A
On 02/27/2016 07:40 PM, Mats Peterson wrote:
On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.
Stream copying of raw palettized data sel
On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
> On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
> >That's not what e.g. the matroska demuxer produces, so stream
> >copying with some generic remuxing example I am really sure that is
> >NOT how the packets come in.
> >
>
> Stream co
On Sat, Feb 27, 2016 at 05:45:57PM +0100, Reimar Döffinger wrote:
> On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:
> > On 02/27/2016 04:13 PM, Mats Peterson wrote:
> > >On 02/27/2016 04:08 PM, Mats Peterson wrote:
> > >>On 02/27/2016 04:07 PM, Mats Peterson wrote:
> > >>>On 02/27/20
On 02/27/2016 07:46 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT ho
On 02/27/2016 07:51 PM, Michael Niedermayer wrote:
On Sat, Feb 27, 2016 at 05:45:57PM +0100, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:
On 02/27/2016 04:13 PM, Mats Peterson wrote:
On 02/27/2016 04:08 PM, Mats Peterson wrote:
On 02/27/2016 04:07 PM,
16 bits were definitely not enough and caused artifacts to appear on
images even on high bitrates.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 1d
---
libavformat/rtpdec_h264.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
index b399be4..e707d03 100644
--- a/libavformat/rtpdec_h264.c
+++ b/libavformat/rtpdec_h264.c
@@ -166,6 +166,10 @@ static int sdp_parse_fmtp_config_h264(AVFor
Sorry, wrong From: header, sended again with correct
On Sat, Feb 27, 2016 at 9:30 PM, Andrew Shulgin wrote:
> ---
> libavformat/rtpdec_h264.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
> index b399be4..e707d03 100644
> ---
Previously used the luma size only.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 27db6c0..600a8ac 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -
Needed for following commits, also a speed increase.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index fd2abd5..1d74cd5 100644
---
This commit redistributes the leftover bytes amongst the top 150 slices
in terms of size (in the hopes that they'll be the ones bitrate starved).
A more perceptual method would probably need to cut bits off from slices
which don't need much, but that'll be implemented later.
The cached quantizer
4 level transforms seem to work better for "real world content" although
testing on images still results in 5 level transforms needing less bits.
Slice sizes can now be reduced as they work better. The bits which would
have been wasted are now used.
Signed-off-by: Rostislav Pehlivanov
---
libav
On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
> should rawvideo AVPackets palette use data[] or sidedata, honestly i
> do not know, but i dont think it makes a big difference
> even supporting both, likely only adds 3-5 lines of code or so
> its more a philosophical question
Previously a global average was used. Using the previous quantizer
resulted in a fairly significant speedup as slice size selection settled
down quicker.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/l
The encoder crashed on verly low bitrates since there wasn't enough
space allocated.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/vc2enc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 5e11aa1..27db6c0 100644
--
On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote:
> On 02/27/2016 07:46 PM, Reimar Döffinger wrote:
> >On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
> >>On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
> >>>That's not what e.g. the matroska demuxer produces, so stream
>
Some Hikvison RTSP cameras send wrong sprop-parameter-sets in SDP - it's
missing PPS.
Example of correct sprop-parameter-sets:
sprop-parameter-sets=Z0IAH5W4PASaEAAAcIAAFfkAQA==,aM48gA==
Example of wrong sprop-parameter-sets:
sprop-parameter-sets=Z0IAH5WoPASaEAAAcIAAFfkIQA==,
My patch adds a worka
On 02/27/2016 08:44 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote:
On 02/27/2016 07:46 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
That's not what e.g. th
On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a big difference
even supporting both, likely only adds 3-5 lines of co
On 2/26/16, wm4 wrote:
> This does obviously not work.
>
> (Additions based on vf_crop.c.)
> ---
> libavfilter/vf_copy.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/libavfilter/vf_copy.c b/libavfilter/vf_copy.c
> index fb9a906..b0159cf 100644
> --- a/libavfilter/v
On 02/27/2016 09:21 PM, Mats Peterson wrote:
On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a big difference
even sup
On Sat, Feb 27, 2016 at 08:42:25PM +0100, Reimar Döffinger wrote:
> On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
> > should rawvideo AVPackets palette use data[] or sidedata, honestly i
> > do not know, but i dont think it makes a big difference
> > even supporting both, lik
On 02/27/2016 09:33 PM, Michael Niedermayer wrote:
On Sat, Feb 27, 2016 at 08:42:25PM +0100, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a
On Sat, Feb 27, 2016 at 19:29:05 +, Rostislav Pehlivanov wrote:
> +av_log(avctx, AV_LOG_WARNING,
> + "Bitrate too low, clipping to minimum = %.2lf Mbps!\n",
> + (double)avctx->bit_rate/100.0f);
"%lf" is undefined in C90, and otherwise identical to "%f".
Just for fun, here is an experimental patch that makes use of palette
side data packets if they exist. I suppose the packets (including side
data packets) will be unaltered from demuxing to muxing when using
stream copy, right? In any case, it produces flickering output for some
reason.
Mats
Still as experimental as the first one. Seems that the packets are empty
(zero bytes) now and then when doing stream copy. It would be
interesting to know why, Michael. I'm new at this.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From a803d1d4995b371e357f3e280ee37019d77c254e Mon Sep 17 0
This avoids enabling and building the x264rgb encoder when its actually not
supported and
thus would not work
Signed-off-by: Michael Niedermayer
---
configure|3 ++-
libavcodec/libx264.c | 22 --
2 files changed, 14 insertions(+), 11 deletions(-)
diff --gi
This affects rawvideo and wraped_avframe, no others are affected atm
Signed-off-by: Michael Niedermayer
---
doc/examples/transcoding.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index d5d410b..8633362 100644
This would require listing supported formats for rawvideo and wrapped_avframe
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c |5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2690d0d..267c973 100644
--- a/libavcodec/utils.c
+++ b
On Wed, Feb 03, 2016 at 05:07:26PM +0100, Michael Niedermayer wrote:
> Fixes CID1271742
>
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/imgutils.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF1336
On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote:
> On 02/27/2016 09:21 PM, Mats Peterson wrote:
> >On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
> >>Well, then we know I can only blame Mats for "only" making it
> >>better instead of perfect :)
> >>___
On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
> -if (!avist->hdr_pal_done) {
> -int64_t cur_offset = avio_tell(pb);
> -avio_seek(pb, avist->pal_offset, SEEK_SET);
> -for (i = 0; i < pal_size; i++) {
> -
On 02/28/2016 12:34 AM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
-
On 02/28/2016 12:22 AM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote:
On 02/27/2016 09:21 PM, Mats Peterson wrote:
On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
Well, then we know I can only blame Mats for "only" making it
better instead of perfect :)
On 02/28/2016 01:13 AM, Mats Peterson wrote:
On 02/28/2016 12:34 AM, Reimar Döffinger wrote:
On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, a
On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer
wrote:
> This would require listing supported formats for rawvideo and wrapped_avframe
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/utils.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/utils.c b/lib
On 28.02.2016, at 01:13, Mats Peterson wrote:
> On 02/28/2016 12:34 AM, Reimar Döffinger wrote:
>
>> On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
>>> -if (!avist->hdr_pal_done) {
>>> -int64_t cur_offset = avio_tell(pb);
>>> -
On Sun, Feb 28, 2016 at 01:26:16AM +0100, Hendrik Leppkes wrote:
> On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer
> wrote:
> > This would require listing supported formats for rawvideo and
> > wrapped_avframe
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/utils.c |
On 02/28/2016 02:15 AM, Reimar Döffinger wrote:
+for (i = 0; i < pkt->side_data_elems; i++) {
+if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
+pal = pkt->side_data[i].data;
+break;
+}
+}
av_frame_get_side_data
No fr
On Wed, Feb 03, 2016 at 11:20:05PM +0100, Andreas Cadhalpun wrote:
> On 03.02.2016 03:41, Michael Niedermayer wrote:
> > On Wed, Feb 03, 2016 at 01:51:55AM +0100, Andreas Cadhalpun wrote:
> >> @@ -274,4 +282,5 @@ URLProtocol ff_ffrtmphttp_protocol = {
> >> .priv_data_size = sizeof(RTMP_HTTPCon
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 40adfd0b3be94dfaf88187ee9f71bd85ad858f9d Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 28 Feb 2016 02:58:36 +0100
Subject: [PATCH 1/2] lavf/avienc: Add support for palette side data packets
---
libavformat/avienc.c | 49 ++
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From ec165732b5677f412112c114b09760d26f1f96bd Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 28 Feb 2016 02:58:57 +0100
Subject: [PATCH 2/2] lavf/movenc: Add support for palette side data packets
---
libavformat/movenc.c | 16 ++
On 02/28/2016 03:00 AM, Mats Peterson wrote:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Why is the packet data in AVI packets sometimes zero bytes when using
stream copy, Michael? There c
On Mon, Feb 15, 2016 at 06:25:01PM -0300, James Almer wrote:
> On 2/7/2016 8:24 PM, wm4 wrote:
> > On Sun, 7 Feb 2016 23:25:53 +0100
> > Andreas Cadhalpun wrote:
> >
> >> The pkg-config file contains all opencv libraries, not only the
> >> neccessary ones.
> >>
> >> This change makes it possible
On Thu, Feb 04, 2016 at 04:45:09PM +, Carl Eugen Hoyos wrote:
> Syed Andaleeb Roomy gmail.com> writes:
>
> > I worked on the attached patch to enable timecode tracks in MP4 files
> > written by ffmpeg. Could someone please take a look to see if it is
> > acceptable?
>
> Ping, see ticket #470
On Mon, Feb 08, 2016 at 11:27:51AM -0800, Timothy Gu wrote:
> ---
> libavcodec/x86/constants.c | 3 ++-
> libavcodec/x86/constants.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
LGTM if these are or will be used
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133
On 2/28/2016 12:43 AM, Michael Niedermayer wrote:
> On Mon, Feb 08, 2016 at 11:27:51AM -0800, Timothy Gu wrote:
>> ---
>> libavcodec/x86/constants.c | 3 ++-
>> libavcodec/x86/constants.h | 2 +-
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> LGTM if these are or will be used
>
> thx
N
Check for palette side data being AVPALETTE_SIZE bytes.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 8c72d4c41615dcc651913f83154e5df1d884af8d Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 28 Feb 2016 05:16:38 +0100
Subject: [PATCH v2 1/2] lavf/avienc: Add support for palette
Check for palette side data being AVPALETTE_SIZE bytes.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 1e6f27735442ddac19775fe5e03d8429fe6f3448 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 28 Feb 2016 05:16:56 +0100
Subject: [PATCH v2 2/2] lavf/movenc: Add support for palette
Use "palette side data" instead of "palette extradata" in error message.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 962582ec4c265573a3230c089929854e1058c4af Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 28 Feb 2016 05:25:36 +0100
Subject: [PATCH v3 1/2] lavf/avienc: Add su
Use "palette side data" instead of "palette extradata" in error message.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 506fe35051a51e0a4a42579b0a5f3d974531c1ae Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Sun, 28 Feb 2016 05:25:53 +0100
Subject: [PATCH v3 2/2] lavf/movenc: Add su
On 02/28/2016 05:27 AM, Mats Peterson wrote:
Use "palette side data" instead of "palette extradata" in error message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Michael, I would like to a
On 02/28/2016 05:38 AM, Mats Peterson wrote:
On 02/28/2016 05:27 AM, Mats Peterson wrote:
Use "palette side data" instead of "palette extradata" in error message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listin
On Sun, 28 Feb 2016 02:14:20 +0100
Michael Niedermayer wrote:
> On Sun, Feb 28, 2016 at 01:26:16AM +0100, Hendrik Leppkes wrote:
> > On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer
> > wrote:
> > > This would require listing supported formats for rawvideo and
> > > wrapped_avframe
> > >
96 matches
Mail list logo
