[FFmpeg-trac] #4768(undetermined:new): FFmpeg preserving CFR during TS to MP4 conversion
FFmpeg
trac at avcodec.org
Wed Aug 12 12:31:36 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:8 cehoyos]:
> >
> > 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).
>
> Sorry if this sounds stupid:
> Did you test this and it does indeed work as expected for 30fps and
24fps or are you assuming it would work?
I am not the OP, I just helped him in the debugging.
I just say that there is no rounding issue with any other classic frame
rate (which can be transformed to 90 kHz units without rounding issues,
only integers) and that the origin of the issue the OP has is that PTS in
TS files are rounded in the case of 23.976 fps CFR streams and that FFmpeg
is fooled by the rounding (this is not a critisism, it is only factual and
FFmpeg has a correct behavior in the case we don't want to care about
rounding issues of TS).
Anyway, I just tested with a 29.970 fps TS file:
ffmpeg -i test.ts -c copy test.mp4
Dump of stts:
{{{
034EAB33 Time to Sample (24 bytes)
034EAB33 Header (8 bytes)
034EAB33 Size: 24 (0x00000018)
034EAB37 Name: stts
034EAB3B Version: 0 (0x00)
034EAB3C Flags: 0 (0x000000)
034EAB3F Number of entries: 1 (0x00000001)
034EAB43 Sample Count: 945 (0x000003B1)
034EAB47 Sample Duration: 3003 (0x00000BBB)
}}}
--> It is perfect (because the source PTS is perfect). Time scale is 90000
(TS time scale).
Any file with 23.976 streams (including official blu-rays) has the
rounding issue (no Blu-ray at 23.976 is strictly speaking CFR) so we never
get the expected remux (CFR) because the CFR is not detected (so we have a
huge stts atom instead of Sample Count = total sample count and Sample
Duration = 1001 and time scale = 24000 which is the theoritical output).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/4768#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list