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

[Michael Niedermayer]

On Thu, Dec 26, 2013 at 01:08:15PM +0100, Michael Niedermayer wrote:
> 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.

what i meant here was, that if the existing methiods are used and
AVPacket have a flag set, then the compatibility problem this draft
fixes would not arise with ramiros variant AFAICS

[...]

-- 
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: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131226/2c584d5e/attachment.asc>