[FFmpeg-trac] #4768(undetermined:new): FFmpeg preserving CFR during TS to MP4 conversion
trac at avcodec.org
Wed Aug 12 11:56:27 CEST 2015
#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 issue tracker
More information about the FFmpeg-trac