[MPlayer-dev-eng] [PATCH] Activate FFmpeg's CrystalHD support

[Philip Langdale]

 On Fri, 11 Mar 2011 21:55:32 +0100, Reimar Döffinger 
 <Reimar.Doeffinger at gmx.de> wrote:
>
> You also said on the FFmpeg list that MPlayer has issues when the
> decoder neither produces a frame nor consumes anything, have you
> looked into that?
> I think it would be good if MPlayer and FFmpeg would support
> asynchronous decoders better.
> (note that it might be better if the codec returned AVERROR(EAGAIN) 
> though)
>>

 I wrote the decoder to be synchronous (hence the need to usleep() 
 internally)
 so that it's never in a situation where it needs to consume no bytes 
 and return
 no frame. The basic cause is that mplayer doesn't understand that a 
 decoder
 might not consume bytes. I did a quick test of returning MPI_NO_PICTURE 
 in
 this case and mplayer still queued up the pts and everything goes 
 south. I'm
 sure its fixable but mplayer needs to have a policy defining how to act 
 in the
 situation. It'll need to hold on to the packet for the next try and 
 that will
 cascade back to the demuxer and audio decoding - not trivial and well 
 outside
 my zone of expertise. I will certainly focus on sorting out the big 
 remaining
 issues (PAFF and 70012 hardware) before anything else.

 To be clear, the decoder works well with mplayer today - that's how I 
 did all my
 testing and I consider it the primary use-case; I've worked within the 
 constraints
 of mplayer's current capabilities - so there's no reason not to expose 
 it.

 While you can use it for an ffmpeg transcode job, it's a terrible idea 
 due to the
 silly colourspace and the fact that it's actually slower than software 
 decoding
 most of the time (It only needs to be real time, after all)

 --phil