[FFmpeg-devel] CrystalHD and ffmpeg probe behaviour

Philip Langdale philipl at overt.org
Sun Jan 15 06:20:08 CET 2012

On Sun, 15 Jan 2012 00:26:53 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> And also, a possible solution might be to prefer the CrystalHD decoder
> so it is always used when it would work (i.e. compiled in, hardware
> available, compatible format), while a bit risky it would only
> affect people who have such a decoder so at least I don't mind
> the risk :-)

Unfortunately, the decoder is a terrible choice for transcode work.
It can't go faster than realtime and only returns yuyv422 frames, so
there's a lossy conversion happening - and the conversion wastes CPU
too. In almost all cases you are better off with the usual software
decoder. That's why I never cared about making the transcode path
work properly before, but I was contacted by a user who's got very
specific circumstances where the crystalhd hardware could help him;
he's trying to do streaming transcodes and doesn't have enough CPU
power to decode and encode at the same time. I'm not fully convinced
that once the bugs are fixed it will work, but it's enough for me
to try and get it working.


More information about the ffmpeg-devel mailing list