From the changelog [1]:<p>> - DTS to PTS reorder bsf<p>Interesting, I wonder what this is / why you'd want it. In particular, when you have the DTS but not the PTS.<p>The recent gstreamer 1.22 release [2] had what I read as the opposite—calculate a plausible DTS from the order and PTS. They did a nice job of explaining why it's useful. AFAICT, this approach is the only viable way to get B frames to work properly from a received RTP stream.<p>> H.264/H.265 timestamp correction elements ... Muxers are often picky and need proper PTS/DTS timestamps set on the input buffers, but that can be a problem if the encoded input media stream comes from a source that doesn't provide proper signalling of DTS, such as is often the case for RTP, RTSP and WebRTC streams or Matroska container files. Theoretically parsers should be able to fix this up, but it would probably require fairly invasive changes in the parsers, so two new elements h264timestamper and h265timestamper bridge the gap in the meantime and can reconstruct missing PTS/DTS.<p>Looks like the ffmpeg thing is dts2pts_bsf.c. [3] I haven't really read the implementation, but I was hoping the comment at the top would illuminate things, but "Derive PTS by reordering DTS from supported streams" isn't enough for me.<p>[1] <a href="https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/6.0:/Changelog" rel="nofollow">https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/rel...</a><p>[2] <a href="https://gstreamer.freedesktop.org/releases/1.22/" rel="nofollow">https://gstreamer.freedesktop.org/releases/1.22/</a><p>[3] <a href="https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/6.0:/libavcodec/dts2pts_bsf.c" rel="nofollow">https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/rel...</a>