Closed NoOneInPart closed 2 years ago
@NoOneInPart I don't know the pulldown option too much, but shouldn't it be pulldown 64 to go from 23.976p to 59.94i ?
Otherwise you could include a blank video as primary, and have the 720x480 23.976p as secondary (with the possibility of dragging the PiP full screen).
Hi @jcdr428, I believe 59.94i is actually out of spec because that would be 59.94 interlaced frames per second, or 119.88 fields per second. It's a bit confusing because people tend to mix fields vs frames, but I really do mean 29.97i, or 59.94 fields per second. If you display each field sequentially that would basically yield the equivalent of 59.94fps. The thing is, the original source footage is hard telecined 29.97i footage (59.94 fields), so what I wanted to accomplish was de-telecine the footage back to 23.976p, and then encode with soft pulldown because directly encoding interlaced content is less efficient. I managed to detelecine the footage and (to my knowledge) encode the video properly, it just won't mux correctly.
Since this is just a personal project, I don't have the tools to master a disc with PiP functionality, so if this does turns out to be an unsolvable issue, I'll just keep the video interlaced or probably upscale to 720 so I can store the video at 23.976p. Thanks.
When I refer to 59.94i it is indeed fields, which is the same as referred to by the Blu-ray specs:
Anyway... if the x264 --pulldown 64 does not work, the upscale to 720 is the easy solution.
I apologize, that was my misunderstanding. I have tested an encode with --pulldown 64
, and there are some interesting results. It plays at the correct speed, however, MediaInfo reports a framerate of 7.992 (8000/1001) FPS, which doesn't seem right, and on top of that, it identifies as a progressive stream. Doing some Googling yields this Doom9 forum page suggesting that --pulldown 64
is really designed to yield a 59.94p stream for HD-DVD compliance at 720p.
pulldown64.zip
I found this really old version of tsMuxer bundled with multiAVCHD which I was going to use to whip up a simple menu system, version 1.10.6, and that seems to have some sort of working soft pulldown support, but it plays ever so slightly too fast and the audio slowly drifts out of sync. I placed the executable of the old version into the same directory as the GUI and used the GUI to mux the file. pulldown32.1106.zip
MediaInfo identifies it as 29.97 FPS with interlaced frames, just like how it identifies interlaced DVD footage at 59.94i (fields).
@NoOneInPart if it is for a personal project, have you tried to leave the video at 720x480 @23.976p ? It is not blu-ray compliant but might play with your player.
Yes. But you can and should use ffplay and mpv. There it does work.
Hi, I've tested the bitstream against mpv-x86_64-20220821-git-37aea11, the speed issue persists with both the raw bitstream and the muxed output. Same results with ffplay version N-107453-g15785e044e-2022-07-20-nonfree, they both run at 29.97, ignoring the soft pulldown.
I just find it really strange that when muxed with tsMuxer 1.10.6, it seems to play at nearly the correct speed, just slightly faster, on all the players I've tested. I have not yet gotten around to burning the muxed files onto a disc to test on my Blu-ray player however, it won't play videos from USB. I'll report back once I finally do it.
Greetings, I am attempting to mux some H264 files encoded with x264 (tested with version core:164 r3095 baee400) and soft pulldown (--pulldown 32) to m2ts in an attempt to produce a muxed Blu-ray compatible 480i stream from 23.976p content without having to upscale to 720p. However, the resulting muxed file will playback at the full 29.97FPS through both PotPlayer and VLC, which is too fast, causing it to fall out of sync with the audio. The raw .264 bitstream, despite identifying as 29.97FPS through MediaInfo, plays at the correct speed through PotPlayer if you seek away from the start of the video, as well as if it is remuxed into an MP4 container with ffmpeg despite the many "pts has no value" errors (potentially a hint towards the issue?). This seems to imply that the pulldown is encoded properly, it just doesn't seem to work correctly after being muxed. VLC refuses to open raw H264 bitstreams.
This behavior seemingly persists regardless of what the SEI/VUI settings are or whether "Continually insert SPS/PPS" is enabled. Checking "Remove pulldown" or changing the FPS solves the problem, but that likely will break Blu-ray compliancy. Outputting directly to a Blu-ray or AVCHD folder doesn't work either.
An MPEG2 elementary stream with soft pulldown produced using Adobe Media Encoder 2020 seems to work properly.
I am using git version fafc3cd (2022-07-06-03-24-31) on Windows 11 x64.
Encoding options:
x264 --crf 22 --preset veryslow --level 3 --vbv-maxrate 2000 --vbv-bufsize 2000 --ref 6 --keyint 48 --open-gop --sar 32:27 --colorprim smpte170m --colormatrix smpte170m --transfer smpte170m --pulldown 32 --pic-struct --bluray-compat --force-cfr --nal-hrd vbr -o 00002.264 00002.avi
tsMuxer Meta file:
tsMuxer Output:
Sample of raw bitstream from x264 (H264): https://files.catbox.moe/248qef.264 Sample of elementary stream from AME2020 (MPEG2): https://files.catbox.moe/mh288n.m2v Output of tsMuxer at wrong speed (H264+AC3): https://files.catbox.moe/2n2pdq.m2ts Output of tsMuxer at correct speed (MPEG2+AC3): https://files.catbox.moe/8tu0t5.m2ts
I will admit that this might potentially be an encoding problem rather than an issue with tsMuxer, if so, any insight into how it might be solved would be helpful. Thanks!