Problems getting 240fps footage to work in HitFilm

CleverTaglineCleverTagline ModeratorLas Vegas, NVModerator, Website User, Ambassador Posts: 3,013 Ambassador

I seldom shoot high speed footage on my phone, but from past experience, I assumed the process of getting a file that would work in HitFilm would be straightforward. Sadly, that wasn't the case yesterday, and I'm curious if anyone can spot something I did wrong.

As always, my first step after importing the file to my computer is to transcode it into something that's HitFilm-friendly. Handbrake has been my go-to for a while, using the "Norman AVC" custom preset I built a while back based on tips from @NormanPCN . Handbrake correctly read the high frame rate of the file, so I thought the output would work if I left the frame rate setting on "Same as source". However, after bringing the transcoded file into HitFilm Pro 14, the "from file" frame rate was showing as 60fps, not 240.

Curious how the original file would import, I tried that next, only to have the same result, which really blew my mind. How can Handbrake (and even Quicktime) recognize it at 240fps, but HitFilm see it as 60?

My next thought was to manually change Handbrake's output frame rate to 240, but sadly the drop-down options only go as high as 120, and there's no manual input to override it.

My next test was to try transcoding using my former favorite, MPEG Streamclip, where I knew I could enter the desired output frame rate manually. I could also trim the clip down to just the piece I want, which Handbrake doesn't allow. After transcoding and importing into HitFilm, it was read at 240fps, and my initial test of forcing it to 30 in the clip settings appeared to show that all was well.

I went ahead and edited the project, not worrying about frame-accurate playback during editing because I know my machine isn't the best at that, which is why I didn't notice the next oddity until after it was exported. When the slow-mo footage kicked in, the first several seconds of it felt stuttery, not smooth, and then things smoothed out to the end. Opening the file in Quicktime, I found that the opening stuttery part wasn't playing every frame of the original 240 fps footage, but every other frame, and that at some random point it switched to playing every frame.

I went back into HitFilm and confirmed that the anomaly was showing there, so I assumed it might've been some hiccup in how HitFilm interpreted the footage. However, I then opened the transcoded file made by MPEG Streamclip—the one that I thought was working properly—and found that the problem was there as well!

As a test, I went back to MPEG Streamclip just now (as I began typing this) and set it to transcode the same file again, this time without trimming it. It just finished a minute ago, and a quick look shows that the frame-skipping problem is still there, only now in different parts of the video than in the trimmed version.

Any idea why this is happening with MPEG Streamclip? Any idea why HitFilm somehow sees some 240fps footage—the original file, or the one transcoded via Handbrake—as 60fps? And most importantly, any idea how to fix any of this? I might try a test with 120fps footage later on and see if there are similar problems, but I somehow suspect there won't be.

Comments

  • kevin_nkevin_n Website User Posts: 1,775 Enthusiast
    edited February 13

    HitFilm's max FPS is 100 in the editor and comp.

    "HitFilm somehow sees some 240fps footage"

    Sounds like a bug, it shouldn't be able to import, or it's some behind the scenes things happening which just adjusts it, perhaps removes frames as well in the process?

  • NormanPCNNormanPCN Website User Posts: 3,879 Enthusiast
    edited February 13

    The timeline is limited to 100. Source media of different frame rates should be conformed to that rate. This is what I see.

    For high fps intended for slowmo, you are always going to change the fps in the media panel anyway. It's the Hitfilm way. 

    I don't have a camera that gens 240, so I generated a 240 (239.76) from a 30 (29.97) using ffmpeg. The source was a GoPro media file.

    ffmpeg.exe -i %1 -c:v libx264 -preset:v medium -profile:v high -crf 20 -g 8 -bf 0 -pix_fmt yuv420p -r 29.97*8 -filter:v "setpts=0.125*PTS" -an "%~dpn1_240.mp4"

    I then brought both media into Hitfilm. 30 and 240. Created a duplicate of the 240 and marked that as 30. I create a comp from the 30fps original and placed the 240 marked as 30 above it. I set the opacity of this layer to 50%. If any frame is off it should show. Seems fine from what I see. I also tried a Difference blend mode to compare the two. I tried viewer and export.

    This is one test so take that for what it is worth. At least any issue if present is not 100% systemic.

  • kevin_nkevin_n Website User Posts: 1,775 Enthusiast
    edited February 13

    @NormanPCN My mistake, obviously it's as you say, I wasn't thinking about slow mo at all. Long work day, lol.

  • CleverTaglineCleverTagline Moderator Las Vegas, NVModerator, Website User, Ambassador Posts: 3,013 Ambassador

    Sorry for the late follow up on this.

    I'm aware of the need to manually change a high-speed clip's FPS to match a lower FPS timeline when intending to use it as slow-mo footage. The problem I saw was twofold:

    1. HitFilm's interpretation of the rate of 240fps clips (some as 240, others as 60). When reading a 240fps clip as 60fps, it's already dropping/ignoring frames, so manually changing the clip FPS to 30 would have the same end result as going from a native 60fps clip to 30fps. A little slower, but not the same drop as 240 to 30.
    2. Frames being dropped from seemingly-random parts of a 240fps clip (correctly interpreted by HitFilm) that was manually changed to 30fps in its properties and used in a 30fps comp.

    I still haven't done a 120fps test, but if/when I do, I'll update again with how that goes.

  • Triem23Triem23 Moderator Moderator, Website User, Ambassador, Imerge Beta Tester, HitFilm Beta Tester Posts: 18,013 Ambassador

    Another user is also reporting an issue with high frame rate footage that isn't correctly interpreting when the frame rate is altered in Properties. This user is reporting errors in the trimmer. I don't know if you two have "random" issues, or if there's a bug happening? 

    @TheBenNorris I'm referring back to this thread https://fxhome.com/forum/discussion/52123/could-not-start-playback-in-trimmer-after-changing-frame-rate-for-clip#latest

  • TheBenNorrisTheBenNorris Staff Administrator, Website User, Imerge Beta Tester Posts: 1,490 Staff

    @Triem23 I'll check with the rest of the team, thanks for pointing this out.

  • TheBenNorrisTheBenNorris Staff Administrator, Website User, Imerge Beta Tester Posts: 1,490 Staff

    @CleverTagline I notice you've mentioned the footage was shot on your phone, is the video in constant or variable frame rate? It seems we have a known issue that fits quite closely to your problem if that was the case.

  • CleverTaglineCleverTagline Moderator Las Vegas, NVModerator, Website User, Ambassador Posts: 3,013 Ambassador

    @TheBenNorris Yes, it was shot on my phone, but I always transcode phone footage to a constant frame rate file before importing into HitFilm, in part because what's coming from the phone is (more often than not) variable frame rate. That's what I was doing with Handbrake and MPEG Streamclip in my earlier descriptions.

  • TheBenNorrisTheBenNorris Staff Administrator, Website User, Imerge Beta Tester Posts: 1,490 Staff

    @CleverTagline I'm not sure then, this doesn't sound like anything we know about. Could I ask you to contact support to see if we can diagnose what's going on? Thanks.

  • NormanPCNNormanPCN Website User Posts: 3,879 Enthusiast
    edited March 19

    @CleverTagline @TheBenNorris

    I just tried having Handbrake transcode and genuine constant frame rate 240 (239.79) media file. It appears that the Handbrake "bug" with certain frame rates exists with 240. Handbrake is generating a "variable" frame rate video from a constant frame rate source. Other known frame rates with issues are 23.98 and 59.96.

    Technically Handbrake is not generating variable frame rates in these cases. It is generating an alternating frame rate in a pattern. Often a two frame pattern. One just below target and the next just above and the two in combo align to a "perfect" frame rate. The reason for this is laziness on the Handbrake developers in choosing the numerator and denominator for the frame rate descriptor. Their common choice works properly for some and not others. The not others causes the pattern generation in the muxer. The sad thing is that Handbrake only supports limited user choices for frame like. Like Hitfilm. Not a roll your own like Vegas. Such limited choices allows one to have a trivially small lookup table for the available choices. For the who knows what this is option, same as source, just use the descriptor from the source media.

    The issue with Hitfilm is their VFR code just plain does not work. It tends to make things worse. It should be trash canned or fixed...but I digress. The ironic thing is that before Hitfilm "supported" VFR media this Handbrake issue (pattern mux) was not an issue in those Hitfilm versions.

    My quickie test, this thread, used ffmpeg. Which happens to be using the same encoder and muxer as Handbrake. Handbrake just fumbles the frame rate descriptor.

    This was a super quickie test generation of 240, so take it for what it is worth.

    Source video.

    Frame rate mode : Constant
    Frame rate : 239.760 (239760/1000) FPS

    Handbrake result.

    Frame rate mode : Variable

    Frame rate : 239.762 FPS
    Minimum frame rate : 239.362 FPS
    Maximum frame rate : 240.000 FPS
    Original frame rate : 239.761 FPS

  • CleverTaglineCleverTagline Moderator Las Vegas, NVModerator, Website User, Ambassador Posts: 3,013 Ambassador

    @NormanPCN That explains why Handbrake is messing things up, but what about MPEG Streamclip? That gave me a file that HitFilm correctly read as 240fps, but seemingly random parts had doubled frames (effectively 120fps) while others were smoother. This just occurred to me now: could this shifting be due to the fact that I had forced the transcoded file to a true 240, but the source was actually 239.760?

    I see another test in my near future...

  • CleverTaglineCleverTagline Moderator Las Vegas, NVModerator, Website User, Ambassador Posts: 3,013 Ambassador

    Drat. Forcing the MPEG Streamclip output to 239.76 didn't change anything. It still shifts between smooth and stuttery.

    FWIW, here's the full MediaInfo output from my original file from the phone. Notice the wide range for the minimum and maximum frame rates. Is that normal for high FPS files? Most files with lower frame rates don't have as much variance from what I recall.

    IMG_0598.MOV
    Format : MPEG-4
    Format profile : QuickTime
    Codec ID : qt 0000.00 (qt )
    File size : 855 MiB
    Duration : 38s 517ms
    Overall bit rate mode : Variable
    Overall bit rate : 186 Mbps
    Encoded date : UTC 2020-02-13 04:27:08
    Tagged date : UTC 2020-02-13 04:28:53
    Writing library : Apple QuickTime
    com.apple.quicktime.make : Apple
    com.apple.quicktime.model : iPhone 11
    com.apple.quicktime.software : 13.3.1
    com.apple.quicktime.creationdate : 2020-02-12T13:05:59-0800
    com.apple.photos.originating.signature : AYpPHKXO7fUJehOb1UfNRnConYNJ

    Video
    ID : 1
    Format : AVC
    Format/Info : Advanced Video Codec
    Format profile : [email protected]
    Format settings : CABAC / 1 Ref Frames
    Format settings, CABAC : Yes
    Format settings, ReFrames : 1 frame
    Format settings, GOP : M=1, N=15
    Codec ID : avc1
    Codec ID/Info : Advanced Video Coding
    Duration : 38s 517ms
    Bit rate : 173 Mbps
    Width : 1 920 pixels
    Height : 1 080 pixels
    Display aspect ratio : 16:9
    Rotation : 90°
    Frame rate mode : Variable
    Frame rate : 240.363 fps
    Minimum frame rate : 200.000 fps
    Maximum frame rate : 300.000 fps
    Color space : YUV
    Chroma subsampling : 4:2:0
    Bit depth : 8 bits
    Scan type : Progressive
    Bits/(Pixel*Frame) : 0.347
    Stream size : 794 MiB (93%)
    Title : Core Media Video
    Encoded date : UTC 2020-02-13 04:27:08
    Tagged date : UTC 2020-02-13 04:28:53
    Color range : Limited
    Color primaries : BT.709
    Transfer characteristics : BT.709
    Matrix coefficients : BT.709
    Codec configuration box : avcC

    Audio
    ID : 2
    Format : AAC LC
    Format/Info : Advanced Audio Codec Low Complexity
    Codec ID : mp4a-40-2
    Duration : 38s 515ms
    Source duration : 38s 568ms
    Bit rate mode : Variable
    Bit rate : 96.0 Kbps
    Channel(s) : 1 channel
    Channel layout : C
    Sampling rate : 44.1 KHz
    Frame rate : 43.066 fps (1024 SPF)
    Compression mode : Lossy
    Stream size : 443 KiB (0%)
    Source stream size : 444 KiB (0%)
    Title : Core Media Audio
    Encoded date : UTC 2020-02-13 04:27:08
    Tagged date : UTC 2020-02-13 04:28:53

  • NormanPCNNormanPCN Website User Posts: 3,879 Enthusiast

    @CleverTagline "Is that normal for high FPS files?"

    It could be from phones. A phone camera system is not a real time system (OS). That is the reason for the variance. A real camera will do all things in real time. The system has to be setup to function like that.

    The time blips that get in the way are probably common blips of real world time. At higher frame rates the blips account for more frames of time. It could be a somewhat similar percentage of variance to "normal" fps variance but with the higher fps number the it seems like more variance at a glance.

    "Forcing the MPEG Streamclip output to 239.76 didn't change anything. It still shifts between smooth and stuttery."

    The mpeg streamclip output is perfect, for lack of a better word? It's only the play of the media in Hitfilm that hiccups?

     

  • CleverTaglineCleverTagline Moderator Las Vegas, NVModerator, Website User, Ambassador Posts: 3,013 Ambassador

    @NormanPCN "The mpeg streamclip output is perfect, for lack of a better word? It's only the play of the media in Hitfilm that hiccups?"

    No. I forgot to mention that after I found the hiccups in HitFilm, I wanted to see if it was a HitFilm-only problem, so I opened the same file in QuickTime Player, where I can also step frame by frame, and the hiccups appear there too.

  • NormanPCNNormanPCN Website User Posts: 3,879 Enthusiast

    @CleverTagline I would need to see a media file, and timecodes to look at, to check out any possible workarounds for you. Possibly PC only as if my memory serves me you are on Mac?

    With the variation in the file shown in your MediaInfo report, the SloMo will not be "perfectly" smooth. It can't be by definition. There will be repeated frames and some drops to get the source onto the framerate target. It depends on how big the hiccups are.

    When you want slowmo, I would just let Hitfilm import directly and force a frame rate in the media panel. Hitfilm should just play every frame sequentially as is with no dups or drops. The Hitfilm conform stuff, and frame rate identification stuff should not get involved in that scenario. The frames are as good as the camera captured. No less, no more. Tag @TheBenNorris for a comment on that scenario..

  • paolalopez118paolalopez118 Website User Posts: 2

    What fellow NormanPCA says is true may be a phone setting that resizes frames

Sign In or Register to comment.