On Fri, 26 Jul 2013 17:30:56 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 26/07/13 17:24, wm4 wrote:
So everything was just shoehorned into something half-working. I
understand that; but what does it have to do with the flag that the
patch adds?
The patch adds some information
On Fri, 26 Jul 2013 17:39:50 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 26/07/13 17:32, wm4 wrote:
On Fri, 26 Jul 2013 17:30:56 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 26/07/13 17:24, wm4 wrote:
So everything was just shoehorned into something half-working. I
understand
On Tue, 16 Jul 2013 11:05:22 +0200
Luca Barbato lu_z...@gentoo.org wrote:
It maps part of API provided by AVFrame.
---
libavcodec/avcodec.h | 48 ++
libavcodec/avpacket.c | 107
-- 2 files changed,
143 insertions(+), 12
On Tue, 16 Jul 2013 11:05:23 +0200
Luca Barbato lu_z...@gentoo.org wrote:
+/**
+ * Remove the oldest AVPacket in the list and return it
+ * @param head List head.
+ * @param tail List tail.
+ * @param pkt Pointer to an AVPacket struct, its content will be
+ * overwritten.
+ *
On Mon, 15 Jul 2013 15:07:16 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 07/14/2013 12:05 AM, wm4 wrote:
Which perks does it actually have? Since even referencing an
AVPacket requires memory allocation for the AVBufferRef, what do
you win by not having to allocate the AVPacket?
Our
Should't the AVPacket documentation be extended about exact rules? For
example, with AVFrame it's pretty clear that AVFrame can be changed by
the owner of the AVFrame only. In particular, even the owner of an
AVFrame reference has to call av_frame_make_writable() before changing
the frame data
PS: I challenge the need for these AVPacket inplace functions. You
can't avoid memory allocation with it, because the buffer ref and the
side-data require it anyway. So why is there a need for av_packet_ref()
over av_packet_clone()? Maybe I'm overlooking something.
On Sat, 13 Jul 2013 19:44:47 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 07/13/2013 07:25 PM, wm4 wrote:
Should't the AVPacket documentation be extended about exact rules?
For example, with AVFrame it's pretty clear that AVFrame can be
changed by the owner of the AVFrame only
On Sat, 13 Jul 2013 19:48:01 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 07/13/2013 07:27 PM, wm4 wrote:
PS: I challenge the need for these AVPacket inplace functions. You
can't avoid memory allocation with it, because the buffer ref and
the side-data require it anyway. So why
On Sat, 13 Jul 2013 21:56:22 +0200
Luca Barbato lu_z...@gentoo.org wrote:
Personally, I think av_freep() is bad style (and probably even
violates the C standard's struct aliasing rules)
It does not violate the aliasing rules and it is just useful to
prevent some common mistakes.
As far
801 - 810 of 810 matches
Mail list logo
