On 3/10/2015 1:28 AM, Vittorio Giovara wrote:
+/* Paint a region over a buffer, without drawing out of its bounds. */
+static void tdsc_paint_cursor(AVCodecContext *avctx, uint8_t *dst, int
stride)
https://lists.libav.org/pipermail/libav-devel/2015-March/067831.html
- Derek
On 10/03/15 12:31, Derek Buitenhuis wrote:
On 3/10/2015 1:28 AM, Vittorio Giovara wrote:
+/* Paint a region over a buffer, without drawing out of its bounds. */
+static void tdsc_paint_cursor(AVCodecContext *avctx, uint8_t *dst, int stride)
On 10/03/15 12:32, wm4 wrote:
Uh, this error message is not much better.
How about: lavc is not thread-safe, you are fucked.
Or maybe add actual internal locking (instead of forcing the user to
use this infernal lock manager abomination), and change it to
recursive codec opening not supported.
On 10/03/15 02:28, Vittorio Giovara wrote:
No global variables are used and the VLC tables are allocated without
static elements. This will allow using a JPEG decoding context within
other decoders.
---
libavcodec/jpeglsdec.c | 2 ++
libavcodec/mjpegbdec.c | 2 ++
libavcodec/mjpegdec.c |
On Tue, Mar 10, 2015 at 6:46 AM, Anton Khirnov an...@khirnov.net wrote:
Quoting Vittorio Giovara (2015-03-10 00:02:00)
Rather than having an unitialized context on the stack, allocate it with
defaults and free it when unneeded.
CC: libav-sta...@libav.org
The patch looks fine, but why should
On Tue, Mar 10, 2015 at 11:31 AM, Derek Buitenhuis
derek.buitenh...@gmail.com wrote:
On 3/10/2015 1:28 AM, Vittorio Giovara wrote:
+/* Paint a region over a buffer, without drawing out of its bounds. */
+static void tdsc_paint_cursor(AVCodecContext *avctx, uint8_t *dst, int
stride)
On 10/03/15 02:28, Vittorio Giovara wrote:
+/* Prepare everything needed for JPEG decoding */
+codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG);
+if (!codec)
+return AVERROR_DECODER_NOT_FOUND;
Maybe BUG is a better error, the rest seems ok.
lu
On Tue, Mar 10, 2015 at 11:32 AM, wm4 nfx...@googlemail.com wrote:
On Tue, 10 Mar 2015 01:28:52 +
Vittorio Giovara vittorio.giov...@gmail.com wrote:
---
libavcodec/utils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
On Tue, 10 Mar 2015 01:28:53 +
Vittorio Giovara vittorio.giov...@gmail.com wrote:
This field is designed for marking codec properties useful to lavc internals.
Two internal capabilities are added:
- CODEC_INT_CAP_THREAD_SAFE: codec can be opened without locks;
-
Le 2015-03-10 04:28, Vittorio Giovara a écrit :
---
libavcodec/utils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index d568cbb..f8a8908 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1050,7 +1050,10 @@ int
On Tue, Mar 10, 2015 at 1:24 AM, Timothy Gu timothyg...@gmail.com wrote:
On Mon, Mar 9, 2015 at 4:02 PM Vittorio Giovara vittorio.giov...@gmail.com
wrote:
Subject: [libav-devel] [PATCH] mp3: Properly use AVCodecContext API
Can you make this a little more specific:
mp3: Properly allocate
On 3/10/2015 11:42 AM, Luca Barbato wrote:
I'd do that later.
I said that too when I added FIC... look how that turned out. ;)
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 3/10/2015 12:00 PM, Vittorio Giovara wrote:
I agree it would be good to have but currently it's a zoo (cit.):
- VMnc draws monochrome cursor on 8/16/32-bpp plane
- G2M draws full-colour cursor on RGB24 plane
- FIC draws full-colour cursor on YUV planes
- TDSC draws full-colour cursor
On 10/03/15 14:41, Derek Buitenhuis wrote:
On 3/10/2015 11:42 AM, Luca Barbato wrote:
I'd do that later.
I said that too when I added FIC... look how that turned out. ;)
Yes, I know that is a slippery slope.
lu
___
libav-devel mailing list
On 3/10/2015 12:18 PM, Rémi Denis-Courmont wrote:
Why don't you use standard __func__ and %s ?
https://lists.libav.org/pipermail/libav-commits/2014-March/013966.html
___
libav-devel mailing list
libav-devel@libav.org
From: Michael Niedermayer michae...@gmx.at
Originally removed in d66e305, however mpeg1 videos encoded with avconv
do not play correctly without it.
CC: libav-sta...@libav.org
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
---
libavcodec/error_resilience.c | 35
On Tue, Mar 10, 2015 at 5:18 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 10/03/15 18:13, Vittorio Giovara wrote:
On Tue, Mar 10, 2015 at 5:05 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 10/03/15 17:45, Vittorio Giovara wrote:
From: Michael Niedermayer michae...@gmx.at
Originally
On 10/03/15 18:13, Vittorio Giovara wrote:
On Tue, Mar 10, 2015 at 5:05 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 10/03/15 17:45, Vittorio Giovara wrote:
From: Michael Niedermayer michae...@gmx.at
Originally removed in d66e305, however mpeg1 videos encoded with avconv
do not play
Acts a silence source filter for now
---
I tried to make a quite simple audio source filter, comments on how to make it
more correct welcome.
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/asrc_atestsrc.c | 82 +
3
---
avconv.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/avconv.c b/avconv.c
index 8e76863..de9ae41 100644
--- a/avconv.c
+++ b/avconv.c
@@ -1292,8 +1292,12 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output)
All these casts do not avoid warnings, so there is no point in
obfuscating the code.
---
This of course exchanges of the type
warning: cast discards ‘const’ qualifier from pointer target type
for warnings of the type
warning: assignment discards ‘const’ qualifier from pointer target type
On Fri, Mar 06, 2015 at 01:24:34PM +0100, Anton Khirnov wrote:
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1726,8 +1694,8 @@ int ff_h264_decode_slice_header(H264Context *h,
H264SliceContext *sl, H264Contex
-h0-last_slice_type = slice_type;
-sl-slice_num
This fixes a number of assignment from incompatible pointer type warnings.
---
libavformat/avio.c| 4 +++-
libavformat/aviobuf.c | 4 +++-
libavformat/swfenc.c | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index
This fixes a number of assignment from incompatible pointer type warnings.
---
libavutil/hmac.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/hmac.c b/libavutil/hmac.c
index f87728e..1a02415 100644
--- a/libavutil/hmac.c
+++ b/libavutil/hmac.c
@@ -53,17
On Fri, Mar 06, 2015 at 01:24:38PM +0100, Anton Khirnov wrote:
--- a/libavcodec/h264.h
+++ b/libavcodec/h264.h
@@ -393,7 +404,7 @@ typedef struct H264SliceContext {
unsigned int ref_count[2]; /// counts frames or fields,
depending on current mb mode
unsigned int
Quoting Vittorio Giovara (2015-03-10 00:02:00)
Rather than having an unitialized context on the stack, allocate it with
defaults and free it when unneeded.
CC: libav-sta...@libav.org
The patch looks fine, but why should it go into stable?
--
Anton Khirnov
On Mon, 9 Mar 2015, Andreas Cadhalpun wrote:
Hi Martin,
On 09.03.2015 22:08, Martin Storsjö wrote:
Thanks for the patch, and thanks for finding the issue.
You're quite correct that the error handling here is broken, but I'm not
able to reproduce it by trying to mux bmp into this muxer - that
Quoting Vittorio Giovara (2015-03-10 02:28:52)
---
libavcodec/utils.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index d568cbb..f8a8908 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1050,7 +1050,10 @@ int
On 10/03/15 21:38, Diego Biurrun wrote:
All these casts do not avoid warnings, so there is no point in
obfuscating the code.
---
This of course exchanges of the type
warning: cast discards ‘const’ qualifier from pointer target type
for warnings of the type
warning: assignment discards
On Sat, 7 Mar 2015, Martin Storsjö wrote:
Even if this is a guess, it is way better than writing a zero duration
of the last sample in a fragment (because if the duration is zero,
the first sample of the next fragment will have the same timestamp
as the last sample in the previous one).
Since
30 matches
Mail list logo
