diff options
author | Philip Langdale <philipl@overt.org> | 2016-10-16 14:14:52 -0700 |
---|---|---|
committer | Philip Langdale <philipl@overt.org> | 2016-11-02 13:47:57 -0700 |
commit | d0a9af851ee8b5254c0354444cfbe6c59d92887e (patch) | |
tree | f8c2b4daff66b5b5b103192050fe8f6ae9468645 /libavcodec | |
parent | a07c07e7aa627578cc532657088d0f9d12207ab1 (diff) | |
download | ffmpeg-d0a9af851ee8b5254c0354444cfbe6c59d92887e.tar.gz |
crystalhd: Update high level description
We don't need to document the horrible hacks that we removed.
Diffstat (limited to 'libavcodec')
-rw-r--r-- | libavcodec/crystalhd.c | 38 |
1 files changed, 5 insertions, 33 deletions
diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c index 7cf2c75898..d85e3518cc 100644 --- a/libavcodec/crystalhd.c +++ b/libavcodec/crystalhd.c @@ -34,39 +34,11 @@ * is not just a function of time, but also one of the dependency on additional * frames being fed into the decoder to satisfy the b-frame dependencies. * - * As such, a pipeline will build up that is roughly equivalent to the required - * DPB for the file being played. If that was all it took, things would still - * be simple - so, of course, it isn't. - * - * The hardware has a way of indicating that a picture is ready to be copied out, - * but this is unreliable - and sometimes the attempt will still fail so, based - * on testing, the code will wait until 3 pictures are ready before starting - * to copy out - and this has the effect of extending the pipeline. - * - * Finally, while it is tempting to say that once the decoder starts outputting - * frames, the software should never fail to return a frame from a decode(), - * this is a hard assertion to make, because the stream may switch between - * differently encoded content (number of b-frames, interlacing, etc) which - * might require a longer pipeline than before. If that happened, you could - * deadlock trying to retrieve a frame that can't be decoded without feeding - * in additional packets. - * - * As such, the code will return in the event that a picture cannot be copied - * out, leading to an increase in the length of the pipeline. This in turn, - * means we have to be sensitive to the time it takes to decode a picture; - * We do not want to give up just because the hardware needed a little more - * time to prepare the picture! For this reason, there are delays included - * in the decode() path that ensure that, under normal conditions, the hardware - * will only fail to return a frame if it really needs additional packets to - * complete the decoding. - * - * Finally, to be explicit, we do not want the pipeline to grow without bound - * for two reasons: 1) The hardware can only buffer a finite number of packets, - * and 2) The client application may not be able to cope with arbitrarily long - * delays in the video path relative to the audio path. For example. MPlayer - * can only handle a 20 picture delay (although this is arbitrary, and needs - * to be extended to fully support the CrystalHD where the delay could be up - * to 32 pictures - consider PAFF H.264 content with 16 b-frames). + * As such, the hardware can only be used effectively with a decode API that + * doesn't assume a 1:1 relationship between input packets and output frames. + * The new avcodec decode API is such an API (an m:n API) while the old one is + * 1:1. Consequently, we no longer support the old API, which allows us to avoid + * the vicious hacks that are required to approximate 1:1 operation. */ /***************************************************************************** |