<div dir="ltr">Hello,<div><br></div><div>First of all many thanks for your various suggestions, that helped a lot!</div><div><br></div><div>Here is a little followup,</div><div><br></div><div>I've been able using mp4mux with varying caps/resolution, with the help of h264timestamper (to prevent this error: "gst_qt_mux_add_buffer:<dry_recorder> error: Buffer has no PTS"), I also switched to h264 main profile and removed zerolatency.</div><div><br></div><div>I think your feedback "<span style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px">2 to 3 second IDR frame is good idea for general streaming" is the default value for nvh264enc here: </span><a href="https://gstreamer.freedesktop.org/documentation/nvcodec/GstNvBaseEnc.html?gi-language=c#GstNvBaseEnc:gop-size">https://gstreamer.freedesktop.org/documentation/nvcodec/GstNvBaseEnc.html?gi-language=c#GstNvBaseEnc:gop-size</a></div><div><br></div><div>What I could not do is:</div><div><ul><li>enable rc-lookahead (20): video freezes and does not recover</li><li>I could not find how to enable CVBR mode for the encoder</li></ul><div>In our scenario, we both record input streams and try to send them back modified (with a video effect) with as little latency as possible over webrtc. Controlling the encoder bitrate is helpful when network conditions vary, but we've lowered the bitrate update period (from 1 to 8 seconds). Anyway, it seems the encoder does not respect the max/target bitrate, especially when the limit is already high.</div></div><div><br></div><div>Thanks again for your leads,</div><div>Guillaume</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 2 juin 2023 à 20:18, vinod kesti <<a href="mailto:vinodkesti@yahoo.com">vinodkesti@yahoo.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><div id="m_-1614776242699858406ydpd01592cbyiv8248480477"><div><div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><div><div dir="ltr">x264 supports dynamic bitrate but I am not sure about the nvenc. <br><br>Here are my thoughts:</div><div dir="ltr">1) Updating bitrate every 1 second is bad idea. Use CVBR instead of VBR so that you have better control over the datarate and quality.</div><div dir="ltr">2) 2 to 3 second IDR frame is good idea for general streaming. May be you can increase if bitrate is too low. In case of <br>3) I would suggest control resolution/framerate based on the based bitrate you are choosing. </div><div dir="ltr"><br></div><div dir="ltr">By the way latest mp4 muxer supports the dynamic resolution change recording. You can consider using so the dry recording happens without any transcoding.<br>I am wondering why you are using zero latency and baseline for recording, You can go with rc-lookahead and main profile (Which is supported by most of the devices in todays world) so that you have better quality for same bitrate</div><div><br clear="none"></div><div><div><br clear="none"></div><div><br clear="none"></div><div>Sent from Yahoo Mail. <a shape="rect" href="https://yho.com/148vdq" rel="nofollow" target="_blank">Get the app</a></div></div></div>
<div><br clear="none"></div><div><br clear="none"></div>
</div></div></div></div><div id="m_-1614776242699858406yiv8248480477yqt06969"><div id="m_-1614776242699858406yiv8248480477yahoo_quoted_6370747089">
<div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div>
On Thursday, 1 June, 2023 at 02:18:19 am GMT-5, Guillaume Denis via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> wrote:
</div>
<div><br clear="none"></div>
<div><br clear="none"></div>
<div><div id="m_-1614776242699858406yiv8248480477"><div dir="ltr">Hello,<div><br clear="none"></div><div>We are using GStreamer within a WebRTC app (the WebRTC part is done with <a rel="nofollow noopener noreferrer" shape="rect" href="https://github.com/pion/webrtc" target="_blank">https://github.com/pion/webrtc</a>) where we estimate the best target bitrate depending on network conditions (congestion control).</div><div><br clear="none"></div><div>I was wondering if anyone has experience about the best way to control encoders (x264enc and nvcodec' nvh264enc) in particular:</div><div><ul><li>when we update the target bitrate: should it be done at a slow pace? (or: is updating every second could be useless or even harmful in any way)</li><li>can it have an impact on keyframes (other than their quality)?</li><li>are there other encoders' properties worth controlling?</li></ul><div>Just in case anyone is interested, below is a typical pipeline we use.</div><div><br clear="none"></div><div>Thanks,</div></div><div>Guillaume</div><div><br clear="none"></div><div><font face="monospace" size="1">## Pipeline with RTP in/out (appsrc/appsink)</font></div><div><font face="monospace" size="1">## and two filesinks (one for the in/dry stream, one after applying a video FX, here facedetect)</font></div><div><font face="monospace" size="1">## we force streams to a 800x600 resolution not to crash muxers with changing resolutions</font></div><div><font face="monospace" size="1"><br clear="none"></font></div><div><font face="monospace" size="1">appsrc name=video_src is-live=true format=GST_FORMAT_TIME min-latency=33333333<br clear="none">appsink name=video_sink qos=true<br clear="none">matroskamux name=dry_recorder ! filesink location=data/dry.mkv<br clear="none">matroskamux name=wet_recorder ! filesink location=data/wet.mkv<br clear="none"><br clear="none">video_src. !<br clear="none">application/x-rtp,encoding-name=H264 !<br clear="none">rtpjitterbuffer name=video_buffer do-lost=1 add-reference-timestamp-meta=true latency=200 !<br clear="none">rtph264depay wait-for-keyframe=true !<br clear="none">h264parse !<br clear="none">nvh264sldec min-force-key-unit-interval=3000000000 discard-corrupted-frames=true qos=true !<br clear="none">cudaupload !<br clear="none">cudaconvertscale !<br clear="none">cudadownload !<br clear="none">videorate !<br clear="none">video/x-raw, framerate=30/1, width=800, height=600, format=I420, colorimetry=bt601, chroma-site=jpeg, pixel-aspect-ratio=1/1 !<br clear="none"><br clear="none">tee name=tee_video_in !<br clear="none">queue !<br clear="none">nvh264enc name=video_encoder_dry rc-mode=3 preset=4 gop-size=15 zerolatency=true b-adapt=0 bframes=0 rc-lookahead=0 min-force-key-unit-interval=3000000000 qos=true ! video/x-h264, profile=constrained-baseline !<br clear="none">h264parse !<br clear="none">dry_recorder.<br clear="none"><br clear="none">tee_video_in. !<br clear="none">queue !<br clear="none">videoconvert !<br clear="none">facedetect !<br clear="none">queue !<br clear="none">cudaupload !<br clear="none">cudaconvertscale !<br clear="none">cudadownload !<br clear="none">video/x-raw, format=I420, colorimetry=bt601, chroma-site=jpeg, pixel-aspect-ratio=1/1 !<br clear="none">nvh264enc name=video_encoder_wet rc-mode=3 preset=4 gop-size=15 zerolatency=true b-adapt=0 bframes=0 rc-lookahead=0 min-force-key-unit-interval=3000000000 qos=true !<br clear="none">video/x-h264, profile=constrained-baseline !<br clear="none">h264parse !<br clear="none"><br clear="none">tee name=tee_video_out !<br clear="none">queue !<br clear="none">wet_recorder.<br clear="none"><br clear="none">tee_video_out. !<br clear="none">queue !<br clear="none">rtph264pay config-interval=-1 min-ptime=30000000 !<br clear="none">video_sink.</font><br clear="none"></div></div>
</div></div>
</div>
</div></div></div></blockquote></div>