![]() ![]() Unfortunately, this still leaves the question of why the download includes the delay in the first place. This means mkvmerge’s behavior is correct the mp4 delays the video by 83ms and so the same is done in the mkv, and various tools just aren’t reporting all the info on both files correctly. This prompted me to check the MP4 metadata more thoroughly, and sure enough, those first two samples were actually just the specified 83ms of delay. However, after dumping the full MKV info, it appeared the timecodes were just copied exactly from the MP4. My initial guess was that the muxer noticed the pattern and attempted to fix the FPS, but didn’t know how to handle those initial two samples. MediaInfo and mkv2vfr were both reporting that the MKV file used a constant FPS of 23.976, as opposed to the alternating pattern in the MP4. An example from the file I tested is below, which will hopefully make what I’m talking about a little more clear: Upon checking the track metadata, most of it seemed to be just that. When encoding to HLS the encoder simply alternates between these two deltas, in this case using a 1-3-1-3 pattern, to achieve something very close to the original framerate. This means no integer delta value can produce 23.976 the closest two are 3754 (23.9744) and 3753 (23.9808). The time scale used for all of CR’s video is 90000, which is mandated for MPEG-TS. The format lists a sequence of paired frame counts and corresponding frame time deltas, which can be converted to an FPS by dividing the time scale specified elsewhere in the file by the delta. HLS with MPEG-TS, however, can’t match this frame rate by default. Using MediaInfo on the MP4 files wasn’t even showing any delay! The next step was to start looking directly at the MP4 metadata in the downloaded file, and suddenly things started to make a bit more sense.Īs mentioned earlier, the videos are 23.976 fps, which is standard for anime. ![]() Maybe it’s the FFmpeg HLS downloader? Nope, same behavior with the native one. Doing so is pretty easy with youtube-dl, so I grabbed the same episode off the CR site directly, muxed into MKV with mkvmerge, and sure enough: 83ms of video delay. My curiosity got the best of me, and I decided to see what was going on.įirst, I wanted to make sure I could reproduce this with a video I downloaded myself. The files were otherwise normal, with MediaInfo reporting a constant video framerate of 24000/1001, or roughly 23.976. ![]() There’s no obvious reason for that, and it means that anyone watching CR video downloads is seeing incorrect subtitle timing and has been for quite some time. However, every file downloaded from CR had the same characteristic: a flat 83ms video delay. Easy enough to deal with, right? File an issue with the relevant repo and call it a day. Some brief debugging revealed that the relevant Aegisub dependency ( ffms2) wasn’t properly handling a delayed video track. Typically, you set the delay on the audio track instead as it’s better supported, makes more intuitive sense, and the value is relative anyway. The reason why was quickly made obvious upon looking at the file: there appeared to be 83ms of video delay set. Sure enough, the bug was easy to reproduce locally. The first step I took was to download a sample video, in this case a random episode of 僕のヒーローアカデミア. Hopefully between the two, it’ll prove both informative and interesting. In addition, I’ve tried to include brief explanations of relevant video encoding topics. I’ve narrated below the actual process I took to figure this out. As it turns out, this seemingly simple bug was quite the rabbit hole. A while back, some users reported a bug where if they attempted to time subtitles to video downloaded from Crunchyroll (henceforth CR), the timing and preview in Aegisub did not reflect what would occur in playback-it was off by two frames. I sometimes work on Aegisub, an open-source subtitle editor. ![]()
0 Comments
Leave a Reply. |