[FFmpeg-trac] #4768(undetermined:new): FFmpeg preserving CFR during TS to MP4 conversion

[FFmpeg]

#4768: FFmpeg preserving CFR during TS to MP4 conversion
-------------------------------------+-------------------------------------
             Reporter:  zer0z        |                    Owner:
                 Type:  enhancement  |                   Status:  new
             Priority:  wish         |                Component:
              Version:  unspecified  |  undetermined
             Keywords:  dts          |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by Zenitram):

 Replying to [comment:3 ffmpegreport]:
 >
 > If the source the CBR, the outfile should be CBR. Assuming a file to be
 VFR is unnecessary and produces false-positives. It seems obvious the
 proper approach would be to parse the file, even if that slows the process
 down at all. Accuracy and correct outfiles should trump assumptions.

 outfile is not CFR even if the source is CFR due to a rounding issue:
 The source file is at 96000/4004 fps (user defined).
 MPEG-TS has a precision of 90000 Hz (no choice).
 So the conversion to TS do some rounding (outfile file is at 90000/3753.75
 fps, and it is impossible to write .75 in a MPEG-TS file).

 And when it is back to MP4, FFmpeg creates that:
 0C1B9B08      Time to Sample (130664/130656 bytes)
 0C1B9B08       Header (8 bytes)
 0C1B9B08        Size:                               130664 (0x0001FE68)
 0C1B9B0C        Name:                               stts
 0C1B9B10       Version:                             0 (0x00)
 0C1B9B11       Flags:                               0 (0x000000)
 0C1B9B14       Number of entries:                   16331 (0x00003FCB)
 0C1B9B18       Sample Count:                        4 (0x00000004)
 0C1B9B1C       Sample Duration:                     3754 (0x00000EAA)
 0C1B9B20       Sample Count:                        1 (0x00000001)
 0C1B9B24       Sample Duration:                     3753 (0x00000EA9)
 0C1B9B28       Sample Count:                        3 (0x00000003)
 0C1B9B2C       Sample Duration:                     3754 (0x00000EAA)
 0C1B9B30       Sample Count:                        1 (0x00000001)
 0C1B9B34       Sample Duration:                     3753 (0x00000EA9)
 ...

 Which is exact if we read the PTS of MPEG-TS.
 Issue: the PTS was rounded, so the double transcoding MP4 --> MPEG-TS -->
 MP4 does not reproduce the exact source time stamps.
 Note: this is the case for any MPEG-TS (including BDAV) at 23.976 fps, no
 need to transcode from MP4 to MPEG-TS first. Just use any TS file with
 23.976 stream if you want to reproduce the issue.

 Replying to [comment:4 gjdfgh]:
 > > Accuracy and correct outfiles should trump assumptions.
 >
 > So how can we accurately detect that the source file is _actually_ CFR?

 Not 100% "sure", but the AVC VUI has the frame rate info (time_scale 48000
 / num_units_in_tick 1001) and there is a "template" in the PTS (3x 3753,
 then 1x 3754, then 3x 3753, then 1x 3754, then...) so it may be enough to
 consider it is CFR.
 So this depends of the level of accuracy you want. when I see AVC VUI +
 the form of PTS like the one I described, I don't see any reason to do
 that except that is is actually CFR with rounding due to technical
 limitations, there is 99.999% (or 99.99%, or 99.9%, or 99%, not easy to
 say) chances that the goal is a CFR stream.

 Replying to [comment:5 cehoyos]:
 > What happens if the input file has a frame rate of 25fps? Are the
 various output files CFR in that case?

 90000 / 25 = 3600.000000000 (exactly 3600) so there is no issue with 25
 fps streams, nor 30.000 fps (always 3000 units in tick), nor 24.000 fps
 (always 3750 units in tick), nor 29.970 fps (always 3003 units in tick).
 Issue is only with 23.976 fps (3x 3753, then 1x 3754 units in tick).

 Replying to [comment:1 heleppkes]:
 > In fact, preserving the exact timestamps as present in the TS file is
 the goal, and not re-interpretation to set some arbitrary CFR flag in some
 other container. I believe ffmpeg has features to overwrite the timestamp
 behavior of that is so desired.

 re-interpretation is definitely the issue: should or shouldn't we re-
 interpret and consider it is rounding issue?
 In all cases, this is a difficulty for analysers: a TS analyser is aware
 that there is a fixed frequency 90 kHz so can consider that rounding is
 possible and test the frame rate with this rounding, but a MP4 analyser
 can consider that there is no rounding because the format is more
 versatile and accept any time scale (and there is no metadata about the
 precision of the time stamp in MP4), there is no good solutions.

 Maybe an option saying we would like to apply subjective CFR detection?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4768#comment:6>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker