[FFmpeg-devel] [PATCH 1/2] lavf: add AVFMT_AVFRAME flag

[Michael Niedermayer]

On Thu, Dec 26, 2013 at 09:58:37AM +0100, Nicolas George wrote:
> Le quintidi 5 nivôse, an CCXXII, Ramiro Polla a écrit :
> > The problem with using plain AVFMT_RAWPICTURE is that the frame is
> > unreferenced in FFmpeg while the muxer might still be using it.
> 
> The problem with using plain AVFMT_RAWPICTURE is that it is an exceptional
> API. The application needs to add special case to handle it, or it will just
> not work, or even worse, crash.
> 
> It can be seen, in your patch, in the fact that you need to change both lavf
> and ffmpeg.c in the same commit.
> 
> Your proposal has exactly the same problem, with the additional issue that
> it causes an incompatibility with the fork. Therefore, I believe it is not a
> good idea as is.
> 
> I have, amongst other things, the project of adding an API to provide an
> AVFrame to willing devices/muxers, but it needs to be clean and transparent.
> My project is not yet finalized, and therefore you are welcome to take over
> if you can achieve it faster or have a better solution. The current draft is
> this:
> 
> * Add a write_undecoded_frame() method to AVOutputFormat.

what does "undecoded_frame" mean ?
muxers take as input packets, i imagine one could take a avframe
instead. Which then might be called a uncoded frame or raw frame maybe


> 
> * Add a av_write_undecoded_frame() public function to exploit that method
>   directly (leaving out the av_interleaved_ variant for now, as it does not
>   matter much for devices).

what happens when a muxer supports both raw frames and normal
avpackets with compressed content, for example in 4 seperate streams
raw pictures, raw pcm mjpeg & adpcm
the later 2 are supported by some hw IIRC and
we might not want to limit ourselfs to hw devices here, the API
could be used with normal muxers too
also what happens when the interleaved packet and
av_write_undecoded_frame, get mixed, this seems likely for such case

also
if a muxer indicates support for direct AVFrames by some means
and user applications would set a flag in AVPacket, packets without
that flag and normal encoded raw bytestream content in data could be
supported.



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131226/000b08b1/attachment.asc>