<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#ffffff"
text="#000000">
On 03/11/2012 12:50 PM, Andrey Utkin wrote:
<blockquote
cite="mid:CANZNk80Qua1Y3=jsC7PvxfOxw3Hyv1Ms=RSWVrqAR7PDdfOmpw@mail.gmail.com"
type="cite">Camera Man, sorry to re-ask, because you probably have
posted it<br>
earlier. What is media container camera produces? Could delay be<br>
caused by muxing? E.g. from practice i saw that mpegts is usually<br>
"interleaved" with step of 4 packets, to bring signal loss
resilience.<br>
Does your camera have alternative media containers support? If so,<br>
what happens if you change container of media, produced by camera?<br>
(Just a speculation, with hope to be useful.)<br>
</blockquote>
<br>
Thanks for the reply. No, I haven't posted before - the camera
produces rtsp/rtp, but the same thing happens when I re-read it from
a raw file (h264 "container" - just h264 NALs one by one) which I
write for debugging.<br>
<br>
The SPS has the bitstream_restriction=1, and says it the
num_reorder_frame=4 (which is probably the culprit). But I don't
care about reordering - when running live, I only ever care about
showing the latest (pts-wise) as soon as it arrives, and if another
one arrives with an earlier pts, I don't want to even display it.<br>
<br>
Thanks in advance,<br>
Camera Man<br>
</body>
</html>