[FFmpeg-user] Force target DTS == source DTS -- How?

Mark Filipak markfilipak.imdb at gmail.com
Wed Jan 10 23:26:23 EET 2024


On 1/10/24 15:46, Mark Filipak wrote:
> On 1/10/24 13:55, Devin Heitmueller wrote:
>> On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak <markfilipak.imdb at gmail.com> 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.

The change from 1048560 to 1174560 has to be happening inside the muxer, wouldn't you say? We now 
know that what's going into the muxer is right. Here is what went to the target file in the last run:

0,    1170806,    1174560,     3753,   640646, 0x900a1a7a, S=1,        1




More information about the ffmpeg-user mailing list