[Ffmpeg-devel] dealloc AVFrame

Axel Gallus uh5d
Wed Feb 7 02:33:57 CET 2007 

When i use av_alloc_frame ( frame )
a frame structure gets initialized.

After that if i use avcodec_decode_video() on that frame, the data field of 
that frame gets filled with
uncompressed picture data.

At the end i use av_free ( frame ) and the structure of that frame gets 
freed, but what's with the data field?
Do i have to do a av_free ( frame->data ) before av_free ( frame )?

Obviously not, but maybe someone is able to give me a hint how this data 
stuff is handled internally by ffmpeg.

Thx

A.Gallus


----- Original Message ----- 
From: <ffmpeg-devel-request at mplayerhq.hu>
To: <ffmpeg-devel at mplayerhq.hu>
Sent: Wednesday, February 07, 2007 2:09 AM
Subject: ffmpeg-devel Digest, Vol 23, Issue 43


> Send ffmpeg-devel mailing list submissions to
> ffmpeg-devel at mplayerhq.hu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> or, via email, send a message with subject or body 'help' to
> ffmpeg-devel-request at mplayerhq.hu
>
> You can reach the person managing the list at
> ffmpeg-devel-owner at mplayerhq.hu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ffmpeg-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: [bug] wmav2 Encoder Abort Trap (Michael Niedermayer)
>   2. Re: [PATCH] Convert deprecated colorspace names
>      (Michael Niedermayer)
>   3. [RFC] libavcodec/mpeg12.c refactor (Nigel Pearson)
>   4. Re: [PATCH] Fix to loss of sync in ffplay when paused
>      (Michael Niedermayer)
>   5. Re: [RFC] libavcodec/mpeg12.c refactor (Michael Niedermayer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 7 Feb 2007 01:01:32 +0100
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [bug] wmav2 Encoder Abort Trap
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20070207000131.GY23313 at MichaelsNB>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi
>
> On Tue, Feb 06, 2007 at 03:32:12PM -0600, Tyler Loch wrote:
>> When converting some audio to wmav2 (which is great...thank you!) on
>> Mac OS X i386 (I haven't tested other systems yet), ffmpeg may abort
>> with the following error:
>> wmaenc.c:374: failed assertion `i>=0'
>>
>> It only seems to affect some files, and others only when resampling.
>> Attached is a gdb backtrace from a fresh SVN build:
>
> maybe fixed, please retry ...
>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> Url : 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070207/843989bf/attachment-0001.pgp
>
> ------------------------------
>
> Message: 2
> Date: Wed, 7 Feb 2007 01:11:50 +0100
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [PATCH] Convert deprecated colorspace
> names
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20070207001149.GZ23313 at MichaelsNB>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi
>
> On Tue, Feb 06, 2007 at 10:39:39PM +0100, Diego Biurrun wrote:
>> Attached is a patch that addresses the change of colorspace names
>> performed in libavutil/avutil.h:
>>
>> #if LIBAVUTIL_VERSION_INT < (50<<16)
>> #define PIX_FMT_UYVY411 PIX_FMT_UYYVYY411
>> #define PIX_FMT_RGBA32  PIX_FMT_RGB32
>> #define PIX_FMT_YUV422  PIX_FMT_YUYV422
>> #endif
>>
>> OK to apply?
>
> yes
>
>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> Url : 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070207/dab6e966/attachment-0001.pgp
>
> ------------------------------
>
> Message: 3
> Date: Wed, 7 Feb 2007 11:19:08 +1100
> From: Nigel Pearson <nigel at ind.tansu.com.au>
> Subject: [Ffmpeg-devel] [RFC] libavcodec/mpeg12.c refactor
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <213417B8-7E0B-4C9E-92B4-9277BFAE730A at ind.tansu.com.au>
> Content-Type: text/plain; charset="us-ascii"
>
> Aeons ago, Michael wrote:
>
>> Subject: Re: [Ffmpeg-devel] MPEG-2 Acceleration Under Mac OS X -
>> Can We Move This Forward?
>>
>> Hi
>>
>> On Tue, Aug 29, 2006 at 11:15:49AM +0200, Michael Niedermayer wrote:
>> [...]
>>> PS: also if anyone does that, please merge the decode_block_foobar
>>> () and
>>> decode_block_foobar_fast() functions they are nearly identical and
>>> i should
>>> have implemented them like descibed above furthermore merging them
>>> will half
>>> the number of functions which need to be changed for apple hw
>>> decoding support
>>
>> additional tip, to merge the functions, dump them to a file each
>> and run diff
>> over them
>
>
> Well, I finally got around to trying this. I know the attached
> diff isn't commit ready (I have purposely used bad formatting,
> and left dead code there, to minimise the size of the diff),
> but I would appreciate comments. e.g. Is this what was meant?
>
>
> Changes seem to pass regression tests, but I
> suspect that these don't use CODEC_FLAG2_FAST?
>
> I have not benchmarked these (still haven't worked out how).
> They may be marginally slower due to the extra conditional -
> if (fast) - inside some of the loops. If anyone has a clever
> way to optimise this, please share!
>
>
> Change 1:
> mpeg2_fast_decode_block_intra(...) => mpeg2_decode_block_intra(...,
> DECODE_FAST)
> mpeg2_decode_block_intra(...)      => mpeg2_decode_block_intra(...,
> DECODE_SLOW)
>
> There were only trivial diffs between these functions.
> Fast version used a pointer instead of an extra scantable
> index int, and the non-fast version has some debug,
> damaged ac-tex checking and mismatched block stuff.
>
>
> Change 2:
> mpeg1_fast_decode_block_inter(...) => mpeg1_decode_block_inter(...,
> DECODE_FAST)
> mpeg1_decode_block_inter(...)      => mpeg1_decode_block_inter(...,
> DECODE_SLOW)
> mpeg2_fast_decode_block_non_intra(...) => mpeg2_decode_block_non_intra
> (..., DECODE_FAST)
> mpeg2_decode_block_non_intra(...)      => mpeg2_decode_block_non_intra
> (..., DECODE_SLOW)
>
> These function pairs were also nearly identical. Fast
> versions didn't use quant_matrix[], check for damaged
> ac-tex or deal with mismatched blocks.
>
>
>
> % svn update
> At revision 7850.
>
> % svn diff libavcodec/mpeg12.c >mpeg12.c-refactor-1.diff
>
> %
>
> --
> Nigel Pearson, nigel at ind.tansu.com.au|"Gentlemen,
> Telstra Net. Eng., Sydney, Australia | you can't fight in here-
> Office: 9202 3900    Fax:  9261 3912 |   this is the war room!"
> Mobile: 0408 664435  Home: 9792 6998 |     Dr Strangelove
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: mpeg12.c-refactor-1.diff
> Type: application/octet-stream
> Size: 12598 bytes
> Desc: not available
> Url : 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070207/f272e85e/mpeg12.c-refactor-1-0001.obj
> -------------- next part --------------
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 7 Feb 2007 01:53:18 +0100
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [PATCH] Fix to loss of sync in ffplay when
> paused
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20070207005318.GA23313 at MichaelsNB>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi
>
> On Wed, Jan 31, 2007 at 10:39:08AM +0000, Michael McConnell wrote:
>> When a video in ffplay is paused, upon release it rushes ahead leaving
>> the audio and video way out of sync.
>>
>> This patch corrects that by updating the frame timer when pause is 
>> released.
>
> patch applied
>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many that live deserve death. And some that die deserve life. Can you give
> it to them? Then do not be too eager to deal out death in judgement. For
> even the very wise cannot see all ends. -- Gandalf
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> Url : 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070207/563ff26c/attachment-0001.pgp
>
> ------------------------------
>
> Message: 5
> Date: Wed, 7 Feb 2007 02:09:13 +0100
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [RFC] libavcodec/mpeg12.c refactor
> To: FFmpeg development discussions and patches
> <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20070207010913.GB23313 at MichaelsNB>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi
>
> On Wed, Feb 07, 2007 at 11:19:08AM +1100, Nigel Pearson wrote:
>> Aeons ago, Michael wrote:
>>
>> >Subject: Re: [Ffmpeg-devel] MPEG-2 Acceleration Under Mac OS X -
>> >Can We Move This Forward?
>> >
>> >Hi
>> >
>> >On Tue, Aug 29, 2006 at 11:15:49AM +0200, Michael Niedermayer wrote:
>> >[...]
>> >>PS: also if anyone does that, please merge the decode_block_foobar
>> >>() and
>> >>decode_block_foobar_fast() functions they are nearly identical and
>> >>i should
>> >>have implemented them like descibed above furthermore merging them
>> >>will half
>> >>the number of functions which need to be changed for apple hw
>> >>decoding support
>> >
>> >additional tip, to merge the functions, dump them to a file each
>> >and run diff
>> >over them
>>
>>
>> Well, I finally got around to trying this. I know the attached
>> diff isn't commit ready (I have purposely used bad formatting,
>
> it looks pretty good, formatting changes must be in a seperate patch
> anyway and removing the old code can be done in a seperate change too
> ...
>
>
>> and left dead code there, to minimise the size of the diff),
>> but I would appreciate comments. e.g. Is this what was meant?
>
> yes!
>
>
>>
>>
>> Changes seem to pass regression tests, but I
>> suspect that these don't use CODEC_FLAG2_FAST?
>
> then test it (the mpeg1 and 2 files in tests/data/ can simply be
> used with rawvideo output and md5sum)
>
>
>>
>> I have not benchmarked these (still haven't worked out how).
>
> see START/STOP_TIMER
>
>
>
>> They may be marginally slower due to the extra conditional -
>> if (fast) - inside some of the loops. If anyone has a clever
>> way to optimise this, please share!
>
> gcc will remove this if the code gets inlined which it should ... well
> theoretically
>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> There will always be a question for which you do not know the correct 
> awnser.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: not available
> Url : 
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070207/52fdf96d/attachment.pgp
>
> ------------------------------
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
> End of ffmpeg-devel Digest, Vol 23, Issue 43
> ********************************************

More information about the ffmpeg-devel mailing list