[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rohc] Video and header compression
I think that this is a good summary of what to take into account when
doing header compression for video applications. From this I believe
that the following two conclusions can be made:
* The ROHC scheme should aim at having sufficiently efficient
compression for the case were there are more than one RTP packet per
frame. It is probably better to do video applications like that over
lossy links to get better video quality, e.g. an entire video frame is
not lost if one RTP packet is lost. Further, compression is much more
justified in that case since the RTP payload is smaller. E.g., if there
is one frame per packet, that payload might have a size of 800 bytes and
compression of headers will not have that big impact on overall
efficiency. However, if the payload size goes down to 100-200 bytes the
gain of header compression becomes larger. Hence, the primary video
application target for ROHC should be one where there are more than one
RTP packet per video frame.
* The above conclusions complicates somewhat things for the ROHC scheme
:-(
It seems as 1 byte headers with SN bits and CRC as in unidirectional and
optimistic mode, or 1 bytes headers with SN and C-bit as in reliable
mode will not do the trick with the regular video cases. The timestamp
and the Marker will change often, which the SO cannot handle. It seems
as the most efficient method to compress video would still need a two
bytes header. If we look at the header Anton made earlier in the video
profile for ROCCO,
http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-rocco-video-00.txt
it had time stamp bits, marker bit as well as the CRC and the SN bits
and had a size of 2 bytes. I would assume that it is something like this
we would need to handle video efficently. Perhaps we can get this from
the FO format...
It seems as we will need to determine all the requirements on the FO
formats and start designing these....
Cheers,
/ Krister
Anton Mårtensson (ERA) wrote:
>
> Hi,
> I would like to take the opportunity to start the discussion about real-time video and IP/UDP/RTP header compression. I know that many of you know a lot about video but I think it is good that we start with a video summary. (Please forgive me if the mail is unstructured)
>
> VIDEO CODING FLEXIBILITY
> Video coding standards do not describe the encoder, but only the bitstream syntax and how the decoder shall interpret it. This leaves a large freedom to the encoder to do as good job as possible regarding compression and error robustness. There is also a freedom to seperate the picture into more than one segment that can be decoded independantly of each other.
>
> A video sequence consists of a sequence of pictures. For each input picture to the encoder, the encoder can choose between four choices:
>
> 1. Encode the picture as an Intra picture (I-picture). An still image that consumes many bits.
>
> 2. Encode the pictue as an Inter picture (P-picture). A predicted picture that is cheap to code but depends on prevoius picture.
>
> 3. Encode the pictue as an Bilinear picture (B-picture). A bi-linearly predicted picture depends on both previous and next picture. This picture type normally needs even fewer bits than a P-picture, but is normally not used for conversational services due to extra complexity and delay.
>
> 4. Skip the picture.
>
> For many conversational video applications a bandwidth limited channel and minimall delay leads to the goal of producing nearly constant number of bits per picture. This can only be achieved by allowing variation in picture quality and framerate.
>
> The input picture framerate (picture clock frequency = PCF) is different for different video standards.
> * H.262 and H.261 ver 1 the PCF is 29.97 Hz
> * For H.263 and MPEG-4, however, custom picture clock frequencies can be used corresponding to 25 Hz, 30 Hz and many other values
>
> PACKETIZATION OF VIDEO
> RTP packetization rules.
> * A picture can be coded in one or more RTP packets.
> * One packet may not contailn more than one picture.
>
> Timestamp:
> All relevant video profiles up to now uses a RTP reference clock at 90000 Hz. The change in RTP timestamp between two packets with successive sequence numbers will either be zero or increase by a multiple of a fixed value corresponding to to the picture clock frequency (PCF). To calculate the fixed value the following formula is used:
>
> PCFTS = 90000 / PCF
>
> Example:
> PCF PCFTS = PCF in TS ticks
> ==================
> 25 Hz 3600
> 29.97 Hz 3003
> 30 Hz 3000
>
> Markerbit:
> The marker bit should be set for the last packet of every picture.
>
> PACKET SIZES and RTP timestamp:
> If we assume that we encode video to 64kbit/s and 10 Hz. The size of each picture will in average be 800 bytes. Since the first picture in a video sequence "always" is an I-picture and normally is much larger than 800 bytes, the video codec has to skip pictures for 300-400 ms => The RTP TS normally makes a jump after an I-picture. After the first I-picture a new picture is sent every 100 ms => RTP TS increase with 9000 between two pictures.
>
> As I said before the RTP timestamp decrease if B-pictures are used. The reason to this is that both the previous and the next picture are sent before the B-picture. You can se the delivery order in the following example
>
> Assume a 30 Hz sequence:
> Picture: I P B P P B P
> Encoding order: 1 2 3 4 5 6 7
> Delivery order: 1 2 4 3 5 7 6
> TS difference: 3000 3000 3000 3000 3000
>
> In this case will the RTP timestamp decrease with 3000 as soon as a B-picture is sent. You can also see that when the next picture is sent the TS will increase with 6000.
>
> SUMMARY
>
> Due to the fact that we do not know how the increase of the TS will look like from one picture to the next and that the framerate is not constant over a sequence it is not possible to calculate the TS from RTP seqNr. It is necessary to code the TS separately to be able to handle TS jumps (both negative and positive).
>
> Best regards
> Anton Martensson
>
> ---------------------------------
> Anton Mårtensson
> Visual Technology
> Ericsson Research, Corporate Unit
> Ericsson Radio Systems AB
> Torshamnsgatan 23
> S-164 80 STOCKHOLM
> Sweden
> E-mail: anton.martensson@era.ericsson.se
> Phone: +46 (0) 8 404 3881
> Fax: +46 (0) 8 757 5550
>
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Krister Svanbro, M.Sc.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Phone : +46 920 20 20 77
Mobile : +46 70 621 69 42
mailto : Krister.Svanbro@epl.ericsson.se