> > > Lets check H264 > claim "They do not have a timestamp" > immedeatly after the pic_struct field which tells you about the repeating > behavior there is a loop for each repeated value with a timestamp. > This timestamp is lost, if at CFR one can call it that way. > > about "Every encoded frame should produce a decoded frame" > quote about this timestamp from the h264 spec > "The contents of the clock timestamp syntax elements indicate a time of > origin, capture, or alternative ideal display." >
This is a simple misunderstanding of the difference between timecode and timestamp. I point you to numerous publications about the difference. > "origin, capture" implies that the repeated frame can have come from > a real input packet because otherwise it wouldnt have a capture or origin > time. > So an encoder could use this as a way to represent some input frames > And in that case only a decoder that follows these repeats exactly would > have input == output > which again brings us full circle as this matches what we see in qtrle > repeats > You conflate presentation (with repeated fields/frame) and decoding which are not the same thing. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
