[FFmpeg-devel] FFmpeg MT and HWACCEL mess

[Michael Niedermayer]

On Sun, Mar 27, 2011 at 08:37:26PM +0200, Reimar Döffinger wrote:
> On Sun, Mar 27, 2011 at 07:59:35PM +0200, Michael Niedermayer wrote:
> > On Sun, Mar 27, 2011 at 02:40:58PM +0200, Reimar Döffinger wrote:
> > > I just had to realize that due all the new thread code in avcodec_open
> > > making the HWACCEL stuff anything than a messy, broken hack has become
> > > even harder.
> > > Since it both initializes the threads and skips calling init, that means
> > > whether to use threads or not has to be decided during init.
> > > However we do not have any data available during init, so we have no chance
> > > of testing whether the hardware supports the given input, nor can we use
> > > get_format to decide which if any hwaccel to use.
> > > This also pretty much puts a block on implementing a codec what would
> > > automatically decide between hwaccel with readback and software decoding.
> > > Any ideas or should I just finally take the hint and give up on FFmpeg
> > > supporting hardware decoding in a way that isn't a PITA?
> > 
> > How would you sugest that ffmpeg should handle it?
> 
> I've said from the beginning that I consider the whole CODEC_CAP thing
> a misadventure born of laziness.
> However my early attempts to change it got no real reaction and more
> and more code is added that makes things more and more brittle and
> thus harder to actually improve anything.


Let me just make sure i understand you correctly as ive been unable
to find much with a search for reimar & CODEC_CAP
You want a single codec that automatically uses hw/sw/threads as
is best for the video at hand ?


>
> > about having sufficient information early enough, there is extradata
> > available during init. And our parsers contain code to extract the
> > global header into extradata.
> 
> That's however not even remotely how the codecs are designed, the
> MPEG1/2 decoder doesn't even decide between MPEG-1 and MPEG-2 before
> decoding.

its not hard to fix for mpeg1/2 if you want me to look into it


> 
> > And a decoder that switches between hw and multiframe-threaded software
> > can be done with a codec that switches between 2 codec instances.
> > It still has the problem that the 2 variants have different delay
> > (multiframe software has higher delay) and this should cause problems
> > with switching independant of implementation
> 
> First, there is no real problem in adding delay, even if it is probably
> not a good idea.
> However I don't care so much about runtime switching, just the case
> "I want it to use the hardware when it is available and not when it is
> not" working without 100 lines that exist for no other reason than a
> bad API would be great!

we could have a h264auto codec that tries to open the various h264
decoders in order of fastest to slowest until one succeeds.



> For example how is an application even supposed to find that hardware-accelerated
> codec?
> Just trawling through the list and looking for both a matching codec id and
> CODEC_CAP works, as does hardcoding the name but both sure aren't a sensible way!

a avcodec_find_decoder2(id, cap)
could be added

maybe you could suggest a API that would be easier to use for you?

[...]
--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- 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/20110327/5e27e577/attachment.asc>