Yeah, the dependence formula is quite sophisticated:) This is good news, most of real world streams fit into them. PTS-DTS shift is dependent on GopRefDist and NumRefFrame encoder initialization parameters in current h264 encoder implementation (although, in my opinion, the dependence on GopRefDist is superfluous).Ī few shifts only were possible to obtain with imsdk 1.7sw: 0, -40 and -80 msec (for 25p/50i streams). Or we will get time-holes/overlaps at joints otherwise. Thus, all concatenated segments must have the same PTS-DTS shift also. That PTS-DTS shift is equal to maximum number of (reference) frames that can be used by encoder for forward prediction. The notion of shift between PTS and DTS exists in all streams, where B-frames are present (in order to use the forward-prediction, first we need to decode one or more future frames) - see figure below. Also, the joints should not have holes/overlaps in time.Īnd now about the times. That is, all segments must have the same frame size, framerate, etc. Wherein a resulting stitched stream should look like as if it was coded continuously by one encoder from one uncompressed source. It is called "Multiple-Segment Encoding" at the imsdk documentation. Consider a scenario with several h264-streams stitching/concatenation (streams are created by different encoders).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |