<div dir="ltr">When rtspsrc streams are piped into mp4mux, the resulting mp4 files have widely varying sample durations and many negative composition time offsets.  Stepping frame-by-frame through these mp4s is inconsistent when using video players like quicktime -- steps often don't advance to the next frame or skip frames.  Also, in some cases the PTS values in the mp4 go backwards (momentarily decreasing instead of monotonically increasing).<div><br></div><div>The root of the issue appears to be that DTS is set to local clock time when rtspsrc receives the segment.  mp4mux uses the intervals between DTS's to determine sample duration.  Since the time between receiving segments can vary considerably, the mp4 sample duration varies in parallel.  (This variation is exaggerated by mp4mux because it pulls up the DTS of the last received segment for each frame).</div><div><br></div><div>The PTS is generated from the RTP timestamp, which tracks the remote camera's clock.  In our pipeline, DTS < PTS regularly.  Consequently, the mp4 sample composition time offsets are regularly negative and vary widely to counteract the variation in sample durations.  Also, as clocks drift the sample composition time offsets grow greater in magnitude.</div><div><br></div><div>My temporary solution is to set DTS=PTS in mp4mux (minor modifications to gst_qt_pad_adjust_buffer_dts() in gstqtmux.c to adjust DTS for every frame).  This fix produces a much "cleaner" mp4 that steps frame-by-frame consistently.  This fix does not handle B-frames, which is ok for our streams.</div><div><br></div><div>First question: has anyone had problems with this DTS/PTS behavior when piping RTP -> mp4?</div><div><br></div><div>Second question: is there a more general solution that can be applied in rtspsrc so there's more correspondence between DTS and PTS?</div><div><br></div><div>Third question: are there ramifications to the temporary solution of setting DTS=PTS in mp4mux that I've missed, besides ruining B-frame support?  And related, is it possible to extend the solution to support B-frames by recognizing gaps in PTS progressions and shifting DTS to preserve decode order?</div><div><br></div><div>Simplified pipeline:</div><div><div>rtspsrc location=URL  latency=500 do-retransmission=true ! rtph264depay ! h264parse ! mp4mux fragment-duration=2000 ! filesink name=filexxx location=diryyy<br></div></div><div><br></div><div>The issue described is true for both mp4's and fragmented mp4's.</div></div>