Wrong TB returned for use in '-bsf setts'

[markfilipak]

(0) This command:

ffmpeg -i "concat:VTS_04_1.VOB|VTS_04_2.VOB|VTS_04_3.VOB|VTS_04_4.VOB|VTS_04_5.VOB|VTS_04_6.VOB" \
-map 0 -codec copy -dn "(0).mkv"
provokes "Can't write packet with unknown timestamp" and aborts. To overcome that, I'll use a bitstream filter.

(1) However, this command:

ffmpeg -i "concat:VTS_04_1.VOB|VTS_04_2.VOB|VTS_04_3.VOB|VTS_04_4.VOB|VTS_04_5.VOB|VTS_04_6.VOB" \
-bsf "setts=pts=N/TB*1001/24000:dts=N/TB*1001/24000" -map 0 -codec copy -dn "(1).mkv"
doesn't work as expected -- MPV reports "FPS: 29.583 (specified) 0.266 (estimated)" and playback is very, very slow.
                                                                      \___=23.976*1000/90000

(2) But this command:

ffmpeg -i "concat:VTS_04_1.VOB|VTS_04_2.VOB|VTS_04_3.VOB|VTS_04_4.VOB|VTS_04_5.VOB|VTS_04_6.VOB" \
-bsf "setts=pts=N/(1/1000)*1001/24000:dts=N/(1/1000)*1001/24000" -map 0 -codec copy -dn "(2).mkv"
does work as expected -- MPV reports "FPS: 29.583 (specified) 23.976 (estimated)" and playback is normal.

Why doesn't (1) work? Because the value of 'TB' that's returned and used is the _decoder_'s time base: 1/90000.
But it needs to be the value of the _encoder_'s time base: 1/1000, as proven by (2).

[markfilipak]

Comment: At least 4 times I asked on the ffmpeg-list what "tbn" meant. No one responded. Now I know it means "time base numerator". So TB == 1/tbn. I wonder what FFPROBE and FFMPEG would report for a video stream's 'tbn' if I set TB to something like 2/2000?

[mkver]

Somehow the timestamps that the BSF receives have already been converted to the timebase of the muxing target (here: the 1/1000 timebase used by the Matroska muxer) although these are not the timebases the BSF was initialized with (which are still the 1/90000 mpeg timebases).

[markfilipak]

Replying to mkver:

Thank you for replicating the issue.

[mkver]

output_packet() in ffmpeg.c (where the bsfs are applied) indeed gets packets in the muxer's timebase, see e.g. lines 2109-2127 in ffmpeg.c.

PS: Simply setting the pts the way you intend to will not work, because of frame reordering (B-frames). Use makemkv to remux DVDs.

[markfilipak]

Yeah, I saw the reordering. But what I'm doing seems to work. Go figure.

[markfilipak]

Perhaps what I'm doing works because it's just scaling time stamps, not changing the ordering, eh?

PS: You know, I just took a 2nd look at what I'm doing and you're right, it shouldn't work because of the reordering, but it is working. When I single step through (2).MKV I can see that it's working. Even in a credit roll that should easily show out-of-order frames, it is clearly not out of order. I have no explanation.

PPS: All I can think of is this: 'N' takes as its value, not ++N, but is fetching the existing index of the 'current' frame. In other words, 'N' has the out-of-order indexing built in to the method that's being employed.