Difference between revisions of "H.264"
From esoterum.org
(New page: == Trading power for PSNR == === Modifying the Encoder === *In contrast to Srini's proposal, we would like to look at modifying the encoder in order to make decisions about which blocks to...) |
|||
| Line 2: | Line 2: | ||
=== Modifying the Encoder === | === Modifying the Encoder === | ||
*In contrast to Srini's proposal, we would like to look at modifying the encoder in order to make decisions about which blocks to drop. In this case, the decoder need only decide how many blocks to drop. The encoder would categorize and arrange the blocks in the stream so that the "important" blocks are sent first, enabling the decoder to drop the last ''n'' blocks without even decoding them. | *In contrast to Srini's proposal, we would like to look at modifying the encoder in order to make decisions about which blocks to drop. In this case, the decoder need only decide how many blocks to drop. The encoder would categorize and arrange the blocks in the stream so that the "important" blocks are sent first, enabling the decoder to drop the last ''n'' blocks without even decoding them. | ||
| − | *One issue to be addressed in the encoder: how do we decide which blocks are more important? | + | *One issue to be addressed in the encoder: how do we decide which blocks are more important? Currently the idea is to look at blocks with smaller motion vectors and consider those less important. An important issue which arises is that this might prevent large slow moving objects from moving at all in the image. This might be avoided if the encoder looks at the average vector size, or vector statistics in order to avoid this situation. |
Revision as of 15:23, 12 September 2007
Contents
Trading power for PSNR
Modifying the Encoder
- In contrast to Srini's proposal, we would like to look at modifying the encoder in order to make decisions about which blocks to drop. In this case, the decoder need only decide how many blocks to drop. The encoder would categorize and arrange the blocks in the stream so that the "important" blocks are sent first, enabling the decoder to drop the last n blocks without even decoding them.
- One issue to be addressed in the encoder: how do we decide which blocks are more important? Currently the idea is to look at blocks with smaller motion vectors and consider those less important. An important issue which arises is that this might prevent large slow moving objects from moving at all in the image. This might be avoided if the encoder looks at the average vector size, or vector statistics in order to avoid this situation.
