On 2013-11-03 23:27:45 +0100, Anton Khirnov wrote:
data[0] may be NULL for valid frames with hwaccel pixel formats.
I guess ok. Since there are hwaccels which set data[0] the decoder
shouldn't write into data[*]
Janne
___
libav-devel mailing list
On Sun, 3 Nov 2013 23:27:45 +0100, Anton Khirnov an...@khirnov.net
wrote:
data[0] may be NULL for valid frames with hwaccel pixel formats.
This looks OK (and VLC already supplies a dummy buf[0] for hwaccel
surfaces) but I would not expect downstreams to adapt anytime soon, for the
sake of
On Mon, Nov 4, 2013 at 1:05 PM, Rémi Denis-Courmont r...@remlab.net wrote:
On Sun, 3 Nov 2013 23:27:45 +0100, Anton Khirnov an...@khirnov.net
wrote:
data[0] may be NULL for valid frames with hwaccel pixel formats.
This looks OK (and VLC already supplies a dummy buf[0] for hwaccel
surfaces)
On Mon, 4 Nov 2013 13:12:36 +0100, Hendrik Leppkes h.lepp...@gmail.com
wrote:
If downstream uses get_buffer2, they absolutely need to provide a
buf[0], and if downstream uses get_buffer, the compat layer should
provide a buf[0], IIRC.
Or am I missing something?
I don't expect downstreams to
On Mon, 04 Nov 2013 13:37:55 +0100, Rémi Denis-Courmont r...@remlab.net wrote:
On Mon, 4 Nov 2013 13:12:36 +0100, Hendrik Leppkes h.lepp...@gmail.com
wrote:
If downstream uses get_buffer2, they absolutely need to provide a
buf[0], and if downstream uses get_buffer, the compat layer should
data[0] may be NULL for valid frames with hwaccel pixel formats.
---
libavcodec/h264.c | 14 +++---
libavcodec/h264_refs.c |4 ++--
libavcodec/mpegvideo.c | 26 +-
libavcodec/pthread.c |2 +-
4 files changed, 23 insertions(+), 23 deletions(-)
On 03/11/13 23:27, Anton Khirnov wrote:
data[0] may be NULL for valid frames with hwaccel pixel formats.
---
libavcodec/h264.c | 14 +++---
libavcodec/h264_refs.c |4 ++--
libavcodec/mpegvideo.c | 26 +-
libavcodec/pthread.c |2 +-
4 files
