On 01/02/2018 14:02, Martin Storsjö wrote:
This makes sure that consumers of the side data actually can
rely on the padding as intended, without having the callers of
av_packet_new_side_data to explicitly zero initialize it.
---
libavcodec/avpacket.c | 1 +
1 file changed, 1 insertion(+)
diff
On Thu, 1 Feb 2018, wm4 wrote:
On Thu, 1 Feb 2018 15:02:37 +0200
Martin Storsjö wrote:
This makes sure that consumers of the side data actually can
rely on the padding as intended, without having the callers of
av_packet_new_side_data to explicitly zero initialize it.
---
libavcodec/avpacke
On Thu, 1 Feb 2018 15:02:37 +0200
Martin Storsjö wrote:
> This makes sure that consumers of the side data actually can
> rely on the padding as intended, without having the callers of
> av_packet_new_side_data to explicitly zero initialize it.
> ---
> libavcodec/avpacket.c | 1 +
> 1 file chang
This makes sure that consumers of the side data actually can
rely on the padding as intended, without having the callers of
av_packet_new_side_data to explicitly zero initialize it.
---
libavcodec/avpacket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avpacket.c b/libavcodec/avp
On 01/02/2018 12:42, Martin Storsjö wrote:
The other alternative would be to make av_packet_new_side_data
zero-initialize the side data that it allocates (or at least the
padding?), to avoid having to keep assumptions like these over here.
(That would also match what ffmpeg does.) Would that pe
On Thu, 1 Feb 2018, Luca Barbato wrote:
On 01/02/2018 11:44, Martin Storsjö wrote:
We already allocate the internal extradata buffer with initialized
padding in flv_queue_extradata, but when copied into side data
(which is allocated by av_packet_new_side_data, which does allocate
the padding bu
On 01/02/2018 10:47, Maxym Dmytrychenko wrote:
it actually should fail-down to VBR but we have VBR already exposed.
LGTM , no other objection(s) ?
Seems the easiest way to go.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.lib
On 01/02/2018 11:44, Martin Storsjö wrote:
We already allocate the internal extradata buffer with initialized
padding in flv_queue_extradata, but when copied into side data
(which is allocated by av_packet_new_side_data, which does allocate
the padding but doesn't initialize it), we forgot to ini
We already allocate the internal extradata buffer with initialized
padding in flv_queue_extradata, but when copied into side data
(which is allocated by av_packet_new_side_data, which does allocate
the padding but doesn't initialize it), we forgot to initialize
the padding there.
---
libavformat/f
it actually should fail-down to VBR but we have VBR already exposed.
LGTM , no other objection(s) ?
On Tue, Jan 30, 2018 at 11:07 AM, Zhong Li wrote:
> AVBR is supported from API 1.3 but only available for Windows
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 17 ++---
10 matches
Mail list logo