Hitfilm Not Responding

Hitfilm has run pretty well for me for the most part, until just recently.

Lately I've been editing quite a bit of footage from my Canon T4i, and while in the editor, Hitfilm will suddenly stop responding. I have no idea how long it would stay like that for, so I close the program and restart it, usually only losing a tiny bit of progress as I save frequently.

It seems to occur most often when I click on the timeline-zoom-bar to zoom in, or when I quickly jump to another point on the timeline, with the bottom scroll bar or the cursor. I have quite a bit of media files imported, mostly video files from the T4i.

Here is a media info of one of the files:

General
Complete name : C:\Users\jeffz\Desktop\Skit Video\Imports\2017-11-15\MVI_1941.MOV
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 2007.09 (qt /CAEP)
File size : 107 MiB
Duration : 19 s 19 ms
Overall bit rate : 47.1 Mb/s
Encoded date : UTC 2017-11-15 20:12:56
Tagged date : UTC 2017-11-15 20:12:56
com.apple.quicktime.make : Canon
com.apple.quicktime.model : Canon EOS REBEL T4i

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L5
Format settings : 1 Ref Frames
Format settings, CABAC : No
Format settings, RefFrames : 1 frame
Format settings, GOP : M=1, N=12
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 19 s 19 ms
Bit rate : 45.5 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Original height : 1 088 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.916
Stream size : 103 MiB (97%)
Language : English
Encoded date : UTC 2017-11-15 20:12:56
Tagged date : UTC 2017-11-15 20:12:56
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : PCM
Format settings : Little / Signed
Codec ID : sowt
Duration : 19 s 19 ms
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 3.48 MiB (3%)
Language : English
Encoded date : UTC 2017-11-15 20:12:56
Tagged date : UTC 2017-11-15 20:12:56

Here is what I could find for system specs:

OS: Windoes 10 Home 64-bit 

Processor: AMD FX(tm)-4300 Quad-Core Processor

Memory: 8192MB RAM

Graphics: AMD Radeon R7 200 Series w/ 2029 MB VRAM

Last I checked my system specs met the requirements for Hitfilm. I understand  that trans-coding footage helps with performance, but I don't think that's the problem here as the editing isn't really slow or choppy. 

Any help is greatly appreciated!

Comments

  • I think you're probably running into the limitations of QuickTime more than anything else. Unfortunately QuickTime sucks. It's ancient and will never improve since Apple has officially killed it. 

    Your files have uncompressed audio and this might limit your options as far as changing the container without transcoding anything. As a test try just changing the file extension from MOV to MP4. If your clip works then you completely avoid QuickTime. It might not work though so fair warning. 

    Another option is to use FFMpeg to extract the audio to a separate wav file then copy the video to a video only MP4. Performance and stability wise this is probably the best option. Since you wouldn't be transcoding, the operations would go pretty fast.

    The last option would be to transcode. You can transcode just the audio to AAC or MP3 and copy the video track to make a new MP4. Converting just audio goes pretty quick too but the downside is both AAC and MP3 are lossy compression. You could also do a full transcode to NormanAVC but looking at your MediaInfo report you wouldn't gain much doing that.

  • @Aladdin4d thank you for the quick response.

    Could I just batch export the clips I'm using to a Cineform format? Audio compression shouldn't be a big problem as I have separately recorded WAV files to merge anyway. 

  • @ZachAlan_Productions You certainly can and that's the best option overall. I didn't mention it before because edit performance-wise, your files are actually pretty good  other than being QuickTime

  • edited November 22

    To get Hitfilm to bypass Quicktime for those files you can just rename the file extension to MP4 from MOV. If the issue is Quicktime related it will cure it. You will also get better edit performance but the big thing is to get reliably working in general.

    https://hitfilm.com/forum/discussion/40059/timeline-playback-performance-with-mov-dslrs-phones-etc

  • @Aladdin4d @NormanPCN

    Thanks guys. I'll probably stick with transcoding for now as it seems like the easiest solution. May as well get a performance boost as well as reliability. I'll get back to you if there is any more problems. 

    Thanks!

  • @NormanPCN His audio is uncompressed PCM which isn't "legal" for MP4 so changing the extension might not be the best choice. It might work and work very well but there is a chance it could make things worse too because of the "illegal" format.

  • edited November 23

    @Aladdin4d "uncompressed PCM which isn't "legal" for MP4"

    I think I understand the quoting of legal. It is a legal audio format, and defined within the MP4 registration authority and a specific ISO spec. PCM audio (twos) is only allowed when the video codec is jpeg2000 in the same file.

    I doubt you could find a Qt/mp4 demuxer that actually looks at video+audio codec combinations and validates those against specific ISO(mpeg) or Quicktime specs. That they do is decode what they know. They usually know PCM. Meaning a specific codec ID defines a specific binary datastream format. PCM audio is either twos or swot. Big endian, little endian. Thus some combo not in one of the many targeted ISO specs actually works.

    Let us not ignore that Sony XDCAM MP4 files always have PCM audio (twos). Not a smart thing to exclude Sony files from given their market penetration.

    Let us not forget that simply renaming the file extension from MOV to MP4 does not make the file an "MP4" file. There are very specific IDs in the MOOV header that ID Qt and MP4 separately. So the PCM audio is always "legal" in that sense because it is still a "Quicktime" file regardless of file name extension.

    That Hitfilm identifies a "Quicktime" file by a MOV extension and not the file header is really a bug if one wants go so far as to use the word bug. While MOV/MP4 are structurally identical the header does ID them uniquely. The rename trick should not work. I think it is fine, in real world use, to ID by extension. Not technically correct, is fine probably 99+% of the time.

    It really boils down to, does it work (decode) or it does not in the real world. You will quickly find this out. There really are no maybes.

    All apps are different. Vegas has a bit of a quirky setup. They separate formats into subgroups and only certain decoders are available to certain subgroups. So while MP3 audio is valid in mp4 files Vegas will not support it even though they have an mp3 decoder. Hitfilm is much more generic in this regard. Somewhat like libavcodec/ffmpeg.

    The advantages to bypassing Qt, on Windows, for DSLR type MOV files are absolutely huge. Probably why Vegas does it. You cannot stop it from doing so. It's a bypass of narrow scope.

  • @NormanPCN Considering HitFilm does NOT import any XDCAM MP4 file I have and Sony shipped import plugins for major NLE's until native support was added or instructs owners to use the camera browser software to re-wrap camera files to something compatible with your NLE of choice but I can import different MOV's with PCM audio renamed to MP4 with different results on a per file basis, I have to respectfully disagree with pretty much everything you just said with one exception. I do agree in this day and age you shouldn't rely on the extension to ID a file but since typing a file by it's extension has been the default Microsoft method since PC-DOS 1.0, doing so should never be considered a bug.

    The MP4 muxers from FFMpeg, VLC and AVIDemux will not allow you to actually mux a PCM stream to an MP4 container. All three PCM entry code registrations are actually for QuickTime, not MP4 or MJ2. As far as I know without the full MJ2 spec in front of me, any audio should be a raw stream. The renamed MOV that is working contains Linear PCM audio. The one that isn't working still has PCM audio and it isn't linear but I don't know exactly what it is beyond that. Both are 16 bit little endian.

Sign in to comment

Leave a Comment