On 1/10/24 13:55, Devin Heitmueller wrote:
On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak <[email protected]> wrote:
Thanks, Devin, but nope, they're a lot closer but they're still not the same.
set FORCE=-bsf:v setts=dts=DTS:pts=PTS
set SOURCE=h:\BDMV\STREAM\00305.m2ts
: IS: 0, 1044806, 1048560, 3753, 640646, 0x900a1a7a, S=1, 1
ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn
c:\target_2.m2ts
: RESULT: 0, 1170806, 1174560, 3753, 640646, 0x900a1a7a, S=1, 1
ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn
c:\target_1.m2ts
: RESULT: 0, 1170806, 1174560, 3753, 640646, 0x900a1a7a, S=1, 1
While I'm not sure why you're not getting the expected output, you can
add "-debug_ts" to your ffmpeg command line as a global option and it
will show the timestamps for the packets at every stage (i.e.
demux/rebasing/decoding/encoding/muxing). That should allow you to
track down where in the pipeline the timestamp is changing.
I have some beautified debug to paste in here, but first I need to say that here is where the packet
CRCs are really needed. Too bad they're not listed by '-debug_ts'.
Here is the first video packet: type pkt_pts pkt_dts duration
[vist#0:0/h264...] demuxer video 1048560 1044806 3753
[vist#0:0/h264...] demuxer+tsfixup video 1048560 1044806 3753
demuxer+ffmpeg video 1048560 1044806 3753 off:0
[aost#0:1/copy...] muxer <- audio pkt_pts:1048560 pkt_dts:1048560
duration:960 size:1084
As shown in my previous post, PTS=1048560 is being changed to PTS=1174560
Confirmed: 1048560 is the lowest PTS.
Confirmed: 1174560 doesn't appear anywhere.
So, the change from 1048560 to 1174560 remains mysterious.
_______________________________________________
ffmpeg-user mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
