<div dir="ltr"><div><div><div><div>Yes, PTZ means pan, tilt, zoom. The network cache introduces a delay between the PTZ command and the video response. In a normal live stream 500ms-1000ms is ok for network cache, but when using PTZ, a reduced network cache around 100ms is more appropriate.<br><br></div>This will allow the video to show the movement with almost no delay from the command. Obviously this is interesting in a local network environment were network latency and speed are not an issue.<br><br></div><div>When playing the video the network cache can be set, but the application needed this change to happen while the video was already playing to allow a fast transition from one situation (PTZ disabled) to the other (PTZ enabled).<br></div><div><br></div>About, the documentation, I can rewrite to allow a better understanding of the api. <br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="color:rgb(116,27,71)">I doubt that even works with threaded demuxer, and I don't see why this should be triggered externally anyway.</span><br></blockquote><div><br></div><div>Sorry, but I didn't understand about the threaded demuxer. I've implemented this patch over 6 months ago, and have been using it without any issue. The application I've developed play live cameras that supports PTZ. Multiple cameras are displayed and a specific camera can be selected to allow PTZ commands to be sent.<br><br></div>So far, the patch didn't present any issue, but this doesn't mean that it won't fail in a specific case.<br><br></div><div>If there is another way to allow the network cache to be changed (reduced/increased) without the need to reset PCR and video buffer it would be great.<br></div><div><br></div>Thank you,<br></div>Paulo<br></div>