[x264-devel] redundant SPS/PPS

[Peter.List at telekom.de]

Hallo Rahul,
SPS/PPS are necessary to start decoding. If  some H.264 content was streamed, it would not be possible to sync to this stream AT ALL if you had missed the very beginning of the stream (which hopefully still had contained the SPS/PPS).

This is very much like with I-frames. Therefore it is logical to send the SPS/PPS information, which is normally just around 20-30 bytes, together with every I-frame, to have a complete "sync-point" in the stream.

Regards, Peter



________________________________
Von: x264-devel-bounces at videolan.org [mailto:x264-devel-bounces at videolan.org] Im Auftrag von Rahul Arvind Jadhav
Gesendet: Montag, 10. Oktober 2011 14:27
An: x264-devel at videolan.org
Betreff: [x264-devel] redundant SPS/PPS

Is it necessary to "mandatorily" add SPS/PPS before every non-consecutive IDR frame even though the SPS/PPS to be sent are same as sent previously especially in context to "reliable transport mode" used such as TCP?

For e.g. After checking out YouTube H264 streams, I found that most of the SPS/PPS are redundant and transmitted before every non-consecutive IDR frame.

I assume the redundancy holds good for certain transport modes such as UDP, but for TCP it might be counter-productive.

So if i dont send multiple SPS/PPS will there be any interoperability problems and before that, is it ok to do as per the specs?

Thanks,
Rahul

--
***************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20111012/86c76108/attachment.html>