Help! What the heck causes this rendering glitch?

edited August 22 in HitFilm Pro Support

Please take a look at this partial clip of WIP for a Star Wars fan film project:

https://www.dropbox.com/s/ytj1hyx4910hq1t/HitfilmPro11RenderGlitch.mp4?dl=0

EDITED AGAIN!

It was videoed with my cell phone off my monitor.

I occasionally get this same type of "glitch" showing up in composite shot renderings.  They do NOT show up in the editing mode in the compositor part of Hitfilm 11, nor do they show in a RAM preview done there.  I've had them happen on numerous composites before this one........ some on my old machine... and now this happening for the first time on my brand new machine with brand new top-end components (i9, SSDs, 64 Gig of RAM, RTX-2080Ti card, etc.). 

It seems to have no "logic" that I can find.  They've shown up occasionally in every version of Hitfilm I've used since I think version 9.  It always looks basically the same....... "leftovers" of the old image as the greenscreened object is moving.  Also with chromatic aberrations.  The only common factor I can find is that all the shots have greenscreens in them, and (maybe) all are set up with using 3-D planes (can't remember that for sure).  Some have a single green-screened element,....some have more than one.  Some have shadow planes set up under some of the 2-d elements that are creating shadows,....some not.

I've tried disabling various components in the above composited shot.  I can take all away except one greenscreen element and the background photo....and that moving element still 'breaks up' in rendering.  It matters not which single green-screened element I leave.... whatever is there breaks up.  I've tried moving the 3-d layers apart in 3-d space a bit more to make sure thay are not 'on top of each other' in 3-d space.  I've tried 'clicking off' some elements to see if that helps.  I've tried removing altogether completely from the project various components. 

It just seems to "happen when it happens".

This was a test shot.  It involved a public domain still photo as a background 'matte painting', and five separate greenscreen files (stormtroopers and Darth Vader).  Those same downloaded greenscreen files work OK in other shots I have done.  Just not in THIS one!

Ideas anyone?  Been driving me crazy for a year.

best,

.......................john

Comments

  •  That does not appear to be a *public* link to the example video.

  • edited August 22
  • That is still appears to be a private/personal link. Looking at the URL this seems implied, and your folder structure is visible in the URL.

    For example, here is a public dropbox link

    https://www.dropbox.com/s/51i671vmqtu6fsf/Shattermaps.zip?dl=0

  • edited August 22

    @NormanPCN I figured out what I was doing wrong with the Dropbox link.... DOH!  Never noticed that difference before.  I did the standard .... "copy Dropbox link" right click.  It was WHERE I WAS when I did that.

    https://www.dropbox.com/s/ytj1hyx4910hq1t/HitfilmPro11RenderGlitch.mp4?dl=0

    edited again above.

    best,

    ......................john

  • edited August 22

    That looks odd and given that it only occurs on export I think this is one where you are better off asking support rather than us users. They will probably ask for something reproducible.

    edit: I would only ask one thing. I noticed you switched the Hitfilm default to Baseline profile. Does this render problem only happen on Baseline profile. Try a normal High, or Main, profile.

  • @NormanPCN ; "I noticed you switched the Hitfilm default to Baseline profile. Does this render problem only happen on Baseline profile. Try a normal High, or Main, profile."

     

    I'm not sure what you mean here?  Can you please explain?

    best,

    ......................john

  • edited August 22

    @JBaymore The file you posted on Dropbox is using the Baseline AVC profile, which Hitfilm export presets do not default to Baseline. So I asked.

    I looked a little closer at the full specs and I do not believe this file comes from Hitfilm export. The file is variable frame rate. *Very* variable. Hitfilm cannot generate variable frame rate. Then there is this, "com.android.version : 8.0.0". Finally there are a few other things in the specs which indicate this file is not a Hitfilm export.

    ---

    File specifications.

    Complete name : C:\Users\Norman\Downloads\HitfilmPro11RenderGlitch.mp4
    Format : MPEG-4
    Format profile : Base Media / Version 2
    Codec ID : mp42 (isom/mp42)
    File size : 4.35 MiB
    Duration : 7 s 156 ms
    Overall bit rate : 5 104 kb/s
    Encoded date : UTC 2019-08-21 17:10:06
    Tagged date : UTC 2019-08-21 17:10:06
    com.android.version : 8.0.0

    Video
    ID : 1
    Format : AVC
    Format/Info : Advanced Video Codec
    Format profile : Baseline@L3
    Format settings : 1 Ref Frames
    Format settings, CABAC : No
    Format settings, Reference frames : 1 frame
    Format settings, GOP : M=1, N=30
    Codec ID : avc1
    Codec ID/Info : Advanced Video Coding
    Duration : 7 s 156 ms
    Bit rate : 4 973 kb/s
    Width : 640 pixels
    Height : 480 pixels
    Display aspect ratio : 4:3
    Frame rate mode : Variable
    Frame rate : 29.906 FPS
    Minimum frame rate : 17.493 FPS
    Maximum frame rate : 30.131 FPS
    Standard : NTSC
    Color space : YUV
    Chroma subsampling : 4:2:0
    Bit depth : 8 bits
    Scan type : Progressive
    Bits/(Pixel*Frame) : 0.541
    Stream size : 4.24 MiB (97%)
    Title : VideoHandle
    Language : English
    Encoded date : UTC 2019-08-21 17:10:06
    Tagged date : UTC 2019-08-21 17:10:06
    Color range : Limited
    Color primaries : BT.601 PAL
    Transfer characteristics : BT.601
    Matrix coefficients : BT.470 System B/G
    Codec configuration box : avcC

    Audio
    ID : 2
    Format : AAC LC
    Format/Info : Advanced Audio Codec Low Complexity
    Codec ID : mp4a-40-2
    Duration : 7 s 40 ms
    Bit rate mode : Constant
    Bit rate : 128 kb/s
    Channel(s) : 2 channels
    Channel layout : L R
    Sampling rate : 48.0 kHz
    Frame rate : 46.875 FPS (1024 SPF)
    Compression mode : Lossy
    Stream size : 110 KiB (2%)
    Title : SoundHandle
    Language : English
    Encoded date : UTC 2019-08-21 17:10:06
    Tagged date : UTC 2019-08-21 17:10:06

  • No... as my post said... I copied that short section via videoing it with my cell phone.  That is not the whole Hitfilm Pro export file... it is just a quick representation of the VISUAL that is happening when I export.  It is a video of the screen of my computer playing back the export.  Didn't want to upload the whole longer original Hitfilm export file.  So any file info is from the PHONE.

    best,

    .....................john

  • My bad for overlooking the cell phone comment. Once I had it and watched it, I went straight for the file hoping to find something. This leaves my ask support comment, which you should do.

  • @NormanPCN ; Thanks for the look see.  No biggie on the missing the cell phone comment.  

    I'll try a shorter duration export than the 25-ish seconds that particular whole clip is, and then upload the actual Hitfilm file to Dropbox.  Then you can see the "real deal" item.  The cell phone "resizing" of the video file to transfer it via email to my computer made it very poor quality.  

    And yeah..... I'll likely open a support ticket.  But I'm still on 11.0.8319.47197.   They might not be interested much.  Although as I said it has happened in every version I've used so far.  I'm in the middle of a couple projects, and even though my new beast of a machine can very well handle 13....... I am wary of "changing horses in the middle of the stream".  

    best,

    ................john

     

  • edited August 22

    "and even though my new beast of a machine can very well handle 13"

    If your old machine can handle 11 then it should handle 13. There really is not much diff beyond the HW AVC decode, for basic workflow. You are right, you should not switch(test) to 13, until your current slate is clear(enough). Any machine.

    Anyway if you have something reproducible for 11, 13 will be able to load the project. At least on the FxHome end. That your issue shows on the old HW and the new HW is promising that it is not some machine/installation quirky type thing which is really impossible to track down. 11 is not even a year old. They should be interested. Something possibly unfortunate here is that you state the problem never shows in playback/viewer. Only export. The export encoders are not Hitfilm code so if those are crapping out, it likely leaves little for FxHome to do. One thing you can try is to export to Cineform. Something without the LongGOP encoding like AVC. You did not state but your normal exports are probably AVC (MP4, H.264) in Hitfilm terms. If the problem goes away with a different encoder that says something. Exactly what, one needs inside info, but it does say something. At least it whittles the report to something more defined than just raw wood/material so to speak.

     

  • edited August 24

    OK..... here is the actual Hitfilm mp4 output file that shows the crazy aberration I've been getting at random times on clips in multiple Pro versions.  (Exported, not a picture from the monitor using the phone.)

    Glitch is VERY evident.

    https://www.dropbox.com/s/3r1z9n7n03pravb/DarthVader-HeIsHere-IveFeltHim3-10sectest.mp4?dl=0

    best,

    ..................john

     

    EDIT:  OK... this is bizarre......... the version when I play it back via the Dropbox link does not show that "glitch" as obviously as when I play back the file directly on my local machine here. ??????????  Resolution of the playback from Dropbox is also seeming far less.  Also the resolution on the Dropbox file seems to go from less to more as the clip progresses.  This is not evident on the original export.  And it is not evident if I click on the file I plopped INTO Dropbox on my local machine.

     

  • "EDIT:  OK... this is bizarre......... the version when I play it back via the Dropbox link does not show that "glitch" as obviously as when I play back the file directly on my local machine here. ??????????"

    Since things like Youtube/Vimeo/Dropbox/google streaming playback are always re-encoding what you send them you always just ignore that with respect to quality and/or glitches. With respect to Hitfilm all that ever matters is the actual Hitfilm output.

    Taking your clue indicating there might be something really quirky going on I tried the following tests.

    My normal video playback is VLC. 3.0.7.1 to be exact. The glitch on the Hitfilm file does show in VLC. VLC defaults to HW AVC decode. I turned the HW decode OFF in VLC. Playback now plays just fine. The HW AVC decode on my machine is handled by an Nvidia GTX 1080 (driver 431.60).

    If I import this file into Hitfilm and play it back it plays fine (full res setting). HW or software decode.

    Windows media player and Movies and TV both show the glitch. These two programs don't give me control/options over video file decode and they probably always use HW when available.

    The curious/interesting thing in these tests is that Hitfilm with HW decode is still fine. All other HW decode situations are fine. I don't have any other video editors installed right now and thus cannot test a second editor with HW decode.

    What exactly does that mean. Hard to say. One way to likely work around this could be to export from Hitfilm to Cineform and then generate your AVC encode via something like Handbrake/ffmpeg/whatever. 

     

  • edited August 24

    @NormanPCN,

    OK... I was just working on another pretty simple shot.  Got it done, and bingo... there is the glitch all over it.  Pain in the butt!  I newver knowwehn it will show up. 

    So I started playing with the way the shot was constructed to see what might be contributing to the issue.  I started taking out single components and effects in the clip and re-exporting.  An hour or so later........

    What I found was that I could export the parts that looked like they were the "glitching" components...... BY THEMSELVES.... and all was fine.  Taking out single effects or components did not remove the glitches.  But when I put the background image back in there behind everything....... all went to heck.  I tried re-sizing the background image file...... and changing its type (jpg / tiff/ png) and that did not help either.  All of the greenscreened and keyed elements with the effects added work FINE with none of that distortion unless I put the background back in place.  Then they glitch like you see in that other file.

    This has happened sporadically to me on my other machine (win 7 64 bit... win media player) as well as now with the new machine (win 10 64 bit, win media player and movies and TV).  It happens in WMP and also M&TV on my new Win 10 machine.   I tried the Win troubleshooter on Win Media Player........and no joy.

    Norman, a bit of what you were explaining above there was "over my head".   Can you re-run that in broader and more simple terms please?  Thanks.

    HW decode I assume means hardware decode.  Which I expect means via the video card.  I'm on a brand new RTX-2080Ti card.  The drivers  were downloaded just a couple days ago....so likely latest ones.  Says Nividea  7/17/19      26.21.14.3160.

    This is driving me crazy with the unpredictability.  Sometimes it happens... sometime not.  I've used this same machine and done a bunch of other far more complex composites.... many with "background images" of all types and sizes and they rendered fine, and play back on Win Media Player fine.

    EDIT:  I just downloaded and installed the VLC media player........and see the same glitches I see in Windows Media Player, for what that information is worth.

    best,

    .........................john

    PS:  Just filed a Support Ticket

     

     

  • "HW decode I assume means hardware decode."

    Yes. Hardware decode only works on AVC/H.264 media. It's more specific than that, (exact AVC specs),  but that is enough to say here for now. Everything else, all other media codec types, is software decode. In Hitfilm you can disable HW decode support. Media panel per media file or globally in Options.

    "Which I expect means via the video card. "

    Hitfilm also supports Intel Quicksync HW decode. This is in the integrated GPU in the CPU. It is possible to have both Intel and Nvidia available and Intel need to be an active GPU. Hitfilm probably just selects the "primary" video for this operation. Most people with external video cards have the integrated GPU disabled. Typically in BIOS, but the integrated GPU often disables itself when it is not connected to a monitor.

    "Norman, a bit of what you were explaining above there was "over my head".   Can you re-run that in broader and more simple terms please?"

    I said a lot of things. Can you be specific about what you would like clarification on.

    If you are referencing this comment, "One way to likely work around this could be..."

    What I am talking about here is to export to Cineform from Hitfilm. This is a very high quality format. Often called an intermediate format in the editing world. Intermediate because it is really never a "final" playback format. You can play but but it is serious overkill for such a task. It is an intermediate render format that will be subsequently used in some other action. Like editing again for a final render to a final playback format.

    After you have your Cineform export, then you use that file and pass it to some encoder for your final "playback" file which is likely in a desired AVC output. I listed Handbrake as one possible encoder option for that step. It is quite popular and free. For AVC/H.264 output, Handbrake is using the x264 encoder (really it is the best AVC encoder). If the source bug here is the Mainconcept AVC encoder used by Hitfilm, then using a different AVC encoder should get you past the issue.

    --

    One thing to remember about video file encoder (aka export) or even decode is that the video editor developers of the world, even the mighty Adobe, do not develop the decode/encode software. They use something written by someone else. The point here is if you come across some real bug in decode/encode there is nothing  the editor developer can do but report to the author and hope it gets fixed.

    At this point we do not know what you have found. But using a different AVC encoder is probably 99.999% likely to get by this issue. At some time expense on your part. That does not mean you should not get something (a project) reproducible to FxHome. You should. But you very likely have a way to move forward rather than sitting on your hands.

  • Thanks Norman.  That helped on the Cineform business.

    Is there a way to get Hitfilm to directly "see" a different encoder for mp4s?  As in, can I install a different codec in Win 10?  Not wanting to "add steps" here if possible.  If I have to... I work around.  But nicer to not have to.

    Also... I just tested that other file I mentioned I was working on in yet another way.  I turned off the image file background that was giving the problem (clicked the eyeball), and replaced it with another image file I imported.   Left everything else exactly the same as what created the "glitch" in the last export.  Exported it again... opened it in Win Media Player .. and voila... it plays back fine.

    One big difference between the two image files is the new background image was very light in tonality (mainly snow fields) and the original image was very dark (stump of a redwood).  Could be purely coincidental.  Maybe not.

    best,

    .......................john

     

     

  • "As in, can I install a different codec in Win 10?  Not wanting to "add steps" here if possible."

    No. All editors moved away from installable codecs. Probably due in large part to people installing stuff and causing support nightmares. DLL hell is a comment term here.

    On Windows, the only legacy Video for Windows (AVI) stuff still uses installable codecs. AVI seriously does not like modern LongGOP codecs like AVC, MPEG-2 and such.

    "I turned off the image file background that was giving the problem (clicked the eyeball), and replaced it with another image file I imported.   Left everything else exactly the same as what created the "glitch" in the last export.  Exported it again... opened it in Win Media Player .. and voila... it plays back fine."

    From reading your comments, one thing I would look at, if I were supporting this, is to check the keying of the media overlay. I am wondering if there is some faint ghost, for lack of a better word, in the key that leaves some residue in the final and in some way this is exposing a bug in the Mainconcept AVC encoder. Maybe with the deblocking feature of AVC. I am speculating wildly but this is something I would look at if I were trying to whittle the project to try and identify a source of the issue.

  • edited August 24

    @NormanPCN wrote:  "From reading your comments, one thing I would look at, if I were supporting this, is to check the keying of the media overlay. I am wondering if there is some faint ghost, for lack of a better word, in the key that leaves some residue in the final and in some way this is exposing a bug in the Mainconcept AVC encoder. Maybe with the deblocking feature of AVC. I am speculating wildly but this is something I would look at if I were trying to whittle the project to try and identify a source of the issue."

    I'll take a look for this and see if I can find something.  But I'm thinking that is kinda' unlikely.  It would have to be a similar "ghost" on multiple keyed (greenscreen) overlays often from different sources in the same composited shot sometimes.  And I almost always check the keyed mattes as I am working to see how "tight" they are and sometimes tweak them to get better results.  Not sure how to "see" such a ghost other than what shows in Hitfilm as I look at the matte it reveals.

    What is the "deblocking feature" you mention?

    As another possible "clue" though here, I think all of the "image breakups" like that are on greenscreens, and not on the few blue screen or demult or luminence keys I have done.  But again... that could be coincidence.

    Being a bit of an idiot at times ....... this is all likely something I'm doing wrong.

    best,

    ....................john

    PS:  Just did another composite clip with a background image file that is characteristically (darker values and tonality) like the one that would not work in the other shot... and it worked just fine with similar overlays. 

     

  • Triem23Triem23 Moderator
    edited August 24

    "Deblocking" is an inherent feature of JPEG and MPEG compressions (mp4 and h.265 are MPEG codecs). Long story shortish (and a little oversimplified), these codecs typically compress in 4x4, 8x8 or 16x16 "macroblocks" (one could also use 4x8, 8x16, etc - always multiples of 4 between 4 to up to 32, but 8x8 is most common). If you ever see a low quality JPEG or stream where you can see large blocky areas of color you're seeing the edges of the macroblocks. Some encoders allow more control over the varied codec parameters than Hitfilm. As Norman has noted, for mp4 conversion Handbrake allows deeper control than pretty much any other tools. Other tools with the same level of control generally have terrible interfaces.

    There are multiple encoder libraries with various strengths and weaknesses. Hitfilm uses the Main concept library. Handbrake can use x264. 

    Otherwise, I defer back to Norman, who is far more capable in this area than I. 

  • edited August 24

    Deblocking https://en.wikipedia.org/wiki/Deblocking_filter

    Deblocking blurs/softens the edges of macroblocks. This softening helps the image when low (insufficient) bitrates are used. MPEG-2 really does not have a deblocking filter and that is why those data streams always go blocky with (classes of ) dropouts or over compression (cable/satellite streams are typically MPEG-2). In AVC the deblocking is integrated to the codec on the encode as well as the decode side. It is a part of the codec itself.

    You have found a situation where something is flipping it's switches. We don't know what that something is right now. I wondered if it might be related to the deblocking. Your glitch is very edgy. Wild ass speculation. Then again, the deblock might not soften a whacked decode since the whacked is unexpected. The data is crapped which a deblock would/should not do, but something has flipped it switches so bets are off.

    VLC gives control over the decode deblock filter and it does not seem to affect the glitch. Then again, that deblock control might only work with the software decoder. I've no idea. In Vegas you get some control over AVC deblocking. The "Preview" display mode and lower disable the AVC deblock filter on decode. They do this to try and lower decode overhead for better performance.

    --

    My questions about the key situation is strictly related to the fact that keying is real common, exporting to AVC is real common. I don't see reports similar to this in this forum. So given that, my first questions lead to... is there something different that you are doing than most. Everyone can have style/mode that is a little different and that can have a chance of finding a boundary condition.

  • edited August 25

    @NormanPCN

    So here's a description of the sequence of 'building' a composite shot that when rendered CAN produce this "glitch" for me.  Sometimes it is a really simple shot like I'll describe here:

    Start with opening screen of make composite shot, and use Hitfilm defaults for 1080p at 30 fps

    Get a background jpg or png or sometimes tiff image for a background 'matte painting' image into the media panel. Drag that file into the composite shot lineup.  Typically rename. 

    Get a greenscreened video file in mp4 format into the media panel.  This might be a live video I've shot against greenscreen or it might be a youtube download of something like stormtroopers.   Drag that on "top" of the background image in the composite shot. Typically, rename.

    Get the 2-d default Hitfilm greenscreen key effect.  Drag that onto the greenscreen file already in the composite shot list.  Edit the position/length of the greenscreen element there to fit the intended shot.  Check the keying at the default settings to see if it is a good key.  Look at the  keyed matte.  If needed, adjust the keying properties.  If not, leave the defaults.

    At this point I could do an export test before any more "tuning".  Sometimes right here I see the glitch.  So I can stop right here on descriptions of whatever other stuff I might do to the various elements.  Or mention other layers of items that might get added also.

    best,

    .........................john

     

     

  • edited August 25

    OK...... more info on this situation.  @NormanPCN's comments above about 
    possible "ghosts" on the greenscreen keys started me thinking (thanks.)

    I've been working in the "standard" default Hitfilm youtube mp4 30 fps settings for most of what I've been working on.  For what I am doing at the moment, that level of quality is fine.  So those settings come up when I start Hitfilm Pro as 8 bit color depth, antialiasing at 4x MSA, reflection map at 512, shadow map at 2048, and 3-d model at 4096.

    I just took one of the existing sequences that I had done at that default project setup, and changed the project settings on the existing project (changed nothing except the "project" settings).  That original project had serious glitching on the final composite render.  I changed that project to 32 bit float color depth and 32x antialiasing. I then exported it still to a youtube mp4 @30 fps file.

    The glitch is gone on the render in Windows Media Player!

    After trying that to start, I also looked then at the keys on the greenscreened layers.  I found I could tweak them very slightly and get a bit of a better edge rendition on some.  But I did not find a huge "ghost" existing in the areas that "broke up" before.

    Rendering time on the clip went up dramatically, of course.  Even with the RTX-2080Ti.  20 sec clip........ 16 minutes.  Old time....about 3 minutes.

    So there may be some info in there from this result for someone who knows a lot more about the stuff than I.  Let me know what I found, please.  ;-)  I now know I can trade render time for no glitch if I have to.

    best,

    ....................john 

  • edited August 25

    As I said, you've stumbled across situation(s) where something is flipping it switches. Normally 1+1=2, but you've got situation(s) where x+y=yikes! You can have exact steps, a, b, c, but the actual data, the media must also be just so for your steps a,b,c and then only where media is just right(err wrong ) then something is flipping its switches and you get the glitch.

    You don't likely need 32-bit float. 16-bit float should be fine. If that is what you need to remove the glitch.

    You really, really do not want 32x AA. This really softens everything. This softening really changes the source which can really change the possible occurrence of the glitch. Hence your change in glitch. Stick to no more than 8x. In Nvidia terms 8xQ CSAA. About AA, your example steps have nothing that AA can affect but AA is always there and the super high settings, 16 and 32, soften everything regardless.

    Also, just playing with the key settings might remove this glitch when it happens. Heck, since you have Hitfilm Pro, try using the top Chroma key effect rather than the basic greenscreen key.  It should generate better keys more easily anyway.

    --

    I did try your steps, but could not reproduce the issue. Not surprising as the issue is intermittent as you state.

  • @NormanPCN,

    I tried 16 bit float with 32 AA with the same file that was "glitching".   No glitch.  Dropped the AA to 16... no glitch.  Dropped the AA to 8X.... glitch is back.....but maybe slightly less distorted.  Was hoping to get down to 8 AA.

    So likely confirms your comment it all appears to be about the AA and is not about the color bit depth. 

    Will "play" on this a bit more today. 

    best,

    ...................john

  • Your sources are 8-bit so 16 or 32-bit float Hitfilm internal computation is unlikely to make much change to the pixel source value much if at all.

    The high AA settings, 16x and 32x, do very noticeably soften the source media. In other words, the pixel values are changed quite a bit. Thus the motion analysis in the AVC encode changes and the glitch boundary condition trigger does not occur. Heck change Vader for a Luke, or the background and the glitch could disappear as well. You need the x+y=yikes to occur. Change the X or Y and the yikes condition disappears.

    If Hitfilm would let us turn AA off, I would for things that don't need AA. 3D models and text layers need/want AA. 

  • It apparently is not just x+y=yikes.  x+y=good   ( x+y)/q=yikes  There is a missing q factor in that equation that is the real issue.  We need to solve for q.

    best,

    .......................john

Sign In or Register to comment.