Hi, Ferdi,
Thank you for the tip. I checked it against what I'm doing.
The 'pts_time's that it returns do not correlate with the exact times
that are computed from frame counts. For example, pts_time=760.607200
should be exactly 760.3[364635..] (based on PTS=2854113 in a
24/1.001fps video having timebase = 90kHz). That is from my
investigation into cutting/concatenation errors that I'm continuing to
work on. There truly is something amiss inside FFmpeg's computations.
It would be welcome to have someone check my work. It's lonely work
and incredibly meticulous.
--Mark.
Hi Mark
I have been following your work on this, and admire your persistence in it.
However I think this is also related to the type of codec and container
that is used. Your work as far as I know is about Transport Streams.
Those are different from X265 in an MP4 or MKV container.
For what I can check on my own is when using MP4 or MKV containers the
times given for key frames with above command are exactly as specified
when encoding the original video with given specific I-frame intervals.
When cutting or trimming a video in an MKV container (what I do
regularly) on keyframes, I get a video with exactly the specific length
of time in between those keyframes as a result. However, I have never
checked the correctness of PTS etc. for those cut video's, as they were
always exactly what I wanted.
However, for this topic it is more about teaching the topic starter
about the limits of codec:copy and it's limits in extracting and
inserting streams.
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
