@Scenestealer

Hi Peter.

I'm also acutely aware that people are complaining that it didn't occur in earlier versions of MEP or VPX.

It's unlikely their screen recorders changed how they worked so IMHO It would seem to point to a problem with the Infusion Engine coding and perhaps be on the bug list, although there are plenty of warnings on the screen recoding program sites and the Go-Pro site about using variable frame rate video with video editing programs that it seems no-one reads. Mainly because like Magix, they bury such information of flaws or incompatibility problems that would seem to tarnish the capabilities of their programs.

I'm beginning to hate H265 and H264 variants. You can find problems with both posted all over the net.

Ray.

@CubeAce

Hi Ray

. . . . there are plenty of warnings on the screen recoding program sites and the Go-Pro site about using variable frame rate video with video editing programs that it seems no-one reads . . . .

Very true - the other side of the coin, and this is where video editing software is always at least one step behind, hindered by licensing fees or just plain locked out of using, is that some manufacturers are bending the specifications to make their devices/software 'better' than the rest.

The standards are a little vague when it comes to VFR which is has become much more prevalent due to mobile devices and social media sites trying to improve performance, VFR makes for great marketing spiel, however they also do not list the deficiencies or limitations.

Game recording has increased dramatically over the years. In the early days PCs did not have the power to run the game and screen record at CFR. With the higher performance capabilities of computers you would expect this to become less of a problem, however the games makers quest for high resolution, high (realistic) detail, high frame rate game playing - these make good marketing points - 'performance requirements' is the main goal in game playing, screen recording has to take the back seat - back to VFR.

The situation then got worse a few years ago, when a 'well known company' dropped support for the Windows version their 'standard' encoding format which requires their supplemental software installed, necessitating the use of Video conversion on PC's.

John EB

@johnebaker

I totally agree. The whole situation is a mess but then that seems to be the normal now.

Everyone is a beta tester and the larger the diversity comes, the more problems we are likely to see.

What gets me most though is everyone automatically blames the video editing program and few ever look to see if it is a combination or errors produced from a lot of complex interactions. Could even be something seemingly unrelated like a Windows update.

Ray.

@Scenestealer

That's exactly the problem I experience if my Nvidia card is selected under "Preview in arranger" in Program Settings: on playback from the timeline some clips jump back and appear to repeat several frames, and this also happens (subjectively to a greater degree) on export. On one project, there is a section where a particular clip will consistently jump back around 1 second of video when exported, but that is an extreme case. It also seemed that some glitches happened at different points of the video when I reloaded the project. So there is an element of randomness in the way it happens.

Sev.

@Scenestealer

Hi Peter

I have been doing more testing with different combinations of graphics settings in Windows and MEP - and while I cannot reproduce Sev's issue with the 'jump backs' either in preview or export, however I did manage to crash MEP twice with the log file showing:

Error in module "nvcuda64.dll"

The section of the timeline where this occurred had 4K UHD video clips with some contrast, colour correction and gamma applied.

This also partially answers the question is CUDA being used.

@SevCardy

Hi

Have you ever had MEP crash or freeze on you when seeing the 'jump backs'?

What version Nvidia driver are you using and is it the Studio driver or Gaming Driver ? I may have missed this info regarding drivers, I can only find this comment

. . . I've an older version 1060 with only 3GB memory and it has always given some problems with MEP. It may be that there is a hardware problem. . . .

John EB

Greetings,

I wasn't sure where to put this post as I don't think it's worth a new topic, but as it's about MEP2021 and its quirks I thought I'd put it here so apologies before I even start.

Turned on the computer this morning, read my emails and checked the news then loaded MEP 2021. For the first time in ages, a pop-up popped up(?) offering me MEP2021 in yet another sale. After a little smirk I cleared it and tried to load my current project.

I couldn't load it as MEP had frozen in exactly the same manner as the store problem we all experienced some time ago - disk spinning, MEP showing CPU / Memory usage and the program being totally unresponsive. It's been like that for 25 minutes as I write. All other programs work as usual.

The only difference in my system that I know to is that Windows updated yesterday (feature update to Windows 10, version 20H2) before I turned off the system for the day,

Annoying.

AndyW

edit - 68 minutes and MEP now working. Seems to possibley be a case of beware the Windows update.

@johnebaker @Scenestealer

Around the time I upgraded to MEP 2021 (I can't remember if it was just before or just after) I used GeForce Experience to download and install the latest Studio driver (version 457.30). I've just checked and GeForce Experience says that is still the latest driver for my card.

I haven't had MEP crash or freeze while exporting or previewing at all. But I have had it crash on exit after switching from Nvidia back to Intel in the program settings while a project is open. I do, however get a multitude of error messages in the log when using the Nvdia, but I'd need to work back through thousand of lines in the log to try to work out what I was doing when they occurred.

@me_again I'm running Windows 10 2004, but Windows update says 20H2 is available. No doubt it will be eventually forced on me and I'll have a whole new set of issues to investigate. Thanks for the heads-up.

Sev.

@johnebaker @CubeAce @Scenestealer @browj2 

This very annoying "jump back" has just started occurring for me too, in VPX (with apologies, since this thread is about MEP!) And I'm running an AMD Radeon card, latest drivers, as per my signature.

The mobile phone file (not my phone!) is a .MOV, MediaInfo detail below:

General
Complete name                            : J:\My Record\Projects\Keswick\Jan 21\IMG_0107.MOV
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.00 (qt  )
File size                                : 185 MiB
Duration                                 : 3 min 29 s
Overall bit rate mode                    : Variable
Overall bit rate                         : 7 403 kb/s
Encoded date                             : UTC 2020-12-09 15:18:17
Tagged date                              : UTC 2020-12-09 15:21:47
Writing library                          : Apple QuickTime
com.apple.quicktime.location.accuracy.ho : 65.000000
com.apple.quicktime.location.ISO6709     : +52.9886-000.4306+025.863/
com.apple.quicktime.make                 : Apple
com.apple.quicktime.model                : iPad (8th generation)
com.apple.quicktime.software             : 14.2
com.apple.quicktime.creationdate         : 2020-12-09T15:18:17+0000

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main@L3.1@Main
Codec ID                                 : hvc1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 3 min 29 s
Bit rate                                 : 7 235 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Rotation                                 : 180°
Frame rate mode                          : Variable
Frame rate                               : 29.970 (29970/1000) FPS
Minimum frame rate                       : 28.571 FPS
Maximum frame rate                       : 30.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 0.262
Stream size                              : 181 MiB (98%)
Title                                    : Core Media Video
Encoded date                             : UTC 2020-12-09 15:18:17
Tagged date                              : UTC 2020-12-09 15:21:47
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : hvcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 3 min 29 s
Source duration                          : 3 min 29 s
Bit rate mode                            : Variable
Bit rate                                 : 96.0 kb/s
Channel(s)                               : 1 channel
Channel layout                           : C
Sampling rate                            : 44.1 kHz
Frame rate                               : 43.066 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 2.40 MiB (1%)
Source stream size                       : 2.40 MiB (1%)
Title                                    : Core Media Audio
Encoded date                             : UTC 2020-12-09 15:18:17
Tagged date                              : UTC 2020-12-09 15:21:47

Other #1
Type                                     : meta
Duration                                 : 3 min 29 s
Bit rate mode                            : Variable

Other #2
Type                                     : meta
Duration                                 : 3 min 29 s
Bit rate mode                            : Constant

Other #3
Type                                     : meta
Duration                                 : 3 min 29 s

Yes, the frame rate is "variable" but not excessively so.

I've run the file through Handbrake to create constant 30fps and 48kHz Audio Sample rate, without success; the file still "jumps back" at least once on playback, often at a different point in the video each time.

MediaInfo for the "converted" file:

General
Complete name                            : J:\My Record\Handbrake\Img 0107-1.m4v
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (isom/iso2/avc1/mp41)
File size                                : 68.6 MiB
Duration                                 : 3 min 29 s
Overall bit rate                         : 2 748 kb/s
Encoded date                             : UTC 2020-12-10 20:05:58
Tagged date                              : UTC 2020-12-10 20:05:58
Writing application                      : HandBrake 1.3.3 2020061300

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : Main@L4
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 3 min 29 s
Bit rate                                 : 2 570 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 30.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.093
Stream size                              : 64.1 MiB (94%)
Writing library                          : x264 core 157 r2935 545de2f
Encoding settings                        : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Encoded date                             : UTC 2020-12-10 20:05:58
Tagged date                              : UTC 2020-12-10 20:05:58
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                                 : 3 min 29 s
Bit rate mode                            : Constant
Bit rate                                 : 168 kb/s
Channel(s)                               : 1 channel
Channel layout                           : C
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 4.19 MiB (6%)
Title                                    : Mono
Default                                  : Yes
Alternate group                          : 1
Encoded date                             : UTC 2020-12-10 20:05:58
Tagged date                              : UTC 2020-12-10 20:05:58

I'll feely admit to being annoyed and worried!

Jeff

Hi All

Thanks for the extra info.

@SevCardy @emmrecs

It also seemed that some glitches happened at different points of the video when I reloaded the project. So there is an element of randomness in the way it happens.

So from this can we assume that it would be adding glitches to the existing glitches that have been burned in to the rendered file if you rendered it again?

As a matter of interest which driver is your Intel HD630 using?

Also, are you running a 2 x Monitors, one from each GPU and which GPU is driving the main program GUI and is the preview monitor on that (standard config.) or on the other monitor?

Is there any difference in the jumping between the default preview monitor size and full screen?

@johnebaker

This also partially answers the question is CUDA being used.

Yes interesting that! I have never seen that but I do recall seeing it once on a screen shot that @CubeAce once posted. As we discussed earlier the CUDA cores must be being used but maybe Task Manager just doesn't report that reliably.

@emmrecs

I'll freely admit to being annoyed and worried!

Me too Jeff, and I would like to blame it all on the Infusion Engine 2 but I have a nasty suspicion that I saw similar behaviour, in preview at least,in a much earlier version of MEP or VPX but I can not remember how I got rid of it - maybe a driver update......?

Peter

@SevCardy, @Scenestealer, @CubeAce, @emmrecs, @browj2, @me_again

Hi everyone

Peter said: . . . . I would like to blame it all on the Infusion Engine 2 but I have a nasty suspicion that I saw similar behaviour . . . .

I do believe you are correct in that we have seen this before and it is an inherent feature of VFR video.

I managed to find a long video clip taken with my mobile which had a frame rate variation of 27.322 to 29.906 fps which is demonstrating this 'step back' jerkiness when played on the timeline - we can definitely rule out the Infusion 2 engine as the video clip exhibits the same issue in MEP 2015 and 2016.

What we cannot rule out is the interaction between MEP, the GPU card and the Intel GPU, though I do not think there is an issue there - see below.

Other notes:

• The 'step back' is visible in the original video when played with WMP and Films & TV
• Converting the video to CFR made no improvement and oddly enough made the 'step back' worse in places.
• Applying the Interpolate Intermediate images option to the video clip made no difference to the 'step back'
• The 'step back' is more obvious the higher the speed of motion across the screen.
• MEP 2015 and 2016 were also using the 3D shader of my RTX 2060 to a similar level as MEP 2021 20 - 21%
• Changing the project frame rate made no difference

I have put a copy of the original file here for anyone who wants to test it - it is a little long at 2m 13s however I did not what to cut it. The 'step back' becomes apparent from ~ 30 secs in to the video clip.

Unfortunately I cannot test the video on the mobile it was taken with - has since been replaced after it failed

John EB

@Scenestealer @CubeAce @johnebaker @browj2

This is a follow-up to my earlier post to this thread, concerning the problematic .MOV files, which showed jerkiness/stuttering and jumping back on the VPX timeline, which no amount of converting, to a variety of formats, would resolve.

So I decided to take a different approach: in desperation I suppose, I began to wonder whether the fact the audio was 44.1kHz, Mono, AAC was any part of the problem. So I opened the original .MOV in Adobe Audition, converted the audio to 48kHz, Stereo, PCM (.wav) - Audition makes no changes to the actual video files - saved the "new" audio, added it to the next available track, aligned it to the .MOV file, muted the original audio track, and the file played perfectly! No stuttering, no jumping back! I then ungrouped the original video and audio, deleted that audio from the timeline and replaced it with the "new" file. Problem gone!

I'm sure there is other software which can convert only the audio, perhaps Handbrake or similar, but since I have Audition and am quite a regular user of it it was the "easiest" method for me.

I wonder if other users who are seeing these sorts of problems are also using AAC audio? If that is converted to .wav, does the problem disappear?

Jeff

@johnebaker @emmrecs @browj2 @SevCardy @me_again @Scenestealer

Hi John EB.

I downloaded your file and tried it in what seems to be a new version of Movie and TV player.(I think it is a new version because it asked me which player to use and that hasn't happened for a long time.) I had no problems watching on either screen. It seemed relatively smooth for the frame rate and the only thing I could discern was the normal 'micro jumps' you get between frames caused by the relative short exposure times of each frame taken in sunlight compared to the time gap between each frame before the next frame arrives. This is somewhat uneven with a VFR video recording. I did not notice any 'jumping back' of frames.

As I don't have VPX 12, I used MEP 2021 and while the playback was not quite as smooth, again I saw no evidence of frames being repeated or missed and no real visible jumping. The file was not imported into MEP but run from the C: drive. The playback again was checked on both monitors although the recording below was from the monitor powered by my nvidia card.

I have recorded for better or worse my project settings for playback and a video of the playback within MEP.

Ray.

@Scenestealer

So from this can we assume that it would be adding glitches to the existing glitches that have been burned in to the rendered file if you rendered it again?

Errm, no. I'm talking in this instance about playback from the timeline. If I experience glitches in a particular section of the video in the project, then close down MEP (without saving the project - I'm not even editing it in this testing!) and start it up again and load the same project, I sometimes get glitches on playback from the timeline in another part of the project. I also noticed yesterday that if I replayed the offending section from the timeline repeatedly the glitches got worse, and then MEP did an auto-save (why? I haven't changed anything!) and the glitches disappeared for a while until I'd replayed the section a few times. Maybe some cache is getting out of sync and the auto-save cleared the cache?

As a matter of interest which driver is your Intel HD630 using?

27.20.100.8682 dated 05/09/2020

Also, are you running a 2 x Monitors, one from each GPU and which GPU is driving the main program GUI and is the preview monitor on that (standard config.) or on the other monitor?

I'm running one monitor which is currently connected to the H630 because in the previous release of MEP I found this the only way to get HWA available. In Windows Graphics Settings I have MEP set to Power saving so it is using the H630. Then I change the MEP Program settings to switch between the two GPUs for testing. But, believe me, I've tried just about every combination including reverting to connecting the monitor to the Nvidia (but then no option in MEP Program settings to use the H630) and still have the same problems.

Sev.

@CubeAce

All my video source files are constant frame rate. But there is one project (in fact the one that consistently has the most glitches) that has source files with different constant frame rates. It also has the most complex effects processing (a lot of colour/speed adjustments and overlays for example).

Sev.

@CubeAce

Hi Ray

. . . . what seems to be a new version of Movie and TV player.. . . . relatively smooth for the frame rate and the only thing I could discern was the normal 'micro jumps' you get between frames caused by the relative short exposure times of each frame . . . .

The Movie and TV player is called Films & TV on my PC and is the current download from Microsoft.

Did you watch the buildings bottom right from 0:24 to 1:20 the jumps are not 'constant width' and appear to be in groups.

The 'micro jumps' I would expect eye persistence to smooth out at ~30fps, however these are not uniform jumps, they are more like block jumps - you get a short sequence of more or less equal jumps then one or two smaller (~ 1/2 size) or larger jumps - the smaller jumps make the video appear to be stepping back, it isn't - it just looks like it - this you can see if you step through some of the video frame by frame (I used VLC).

I did compare this to the video taken a week later departing the same airport with my sportscam (CFR) and that is smooth.

John EB

@SevCardy

Hi Sev.

I'm going to try to be careful with my reply on this point.

My last reply was purely down to John EB's invitation to download his file and see if others experienced the same results he was seeing on his system. This was to test the files' performance purely at this point in both Windows Movie and TV app and played within MEP.

I would not want to confuse that with the problems with systems not being able to cope with either editing of such footage where once such a file is split up can exhibit very strange behaviour that includes out of sync audio and occasional movement of the placing of such clips on the timeline. Or indeed problems with systems causing playback stuttering due to the load placed on it while adding effects. Those are separate problems and while both can be present was not what I was checking for in my reply to Johns invite.

Anyone on any system can experience the latter depending on how much the system is stressed and needs to use proxy files and even perhaps further rendering using the additional pre-render function which is only useful until a further change is made and has to then be re-rendered to achieve a smooth playback. None of which should effect the final render whereas VFR footage often seems to.

I would love to know more answers on what is important on a system and for what purpose or reason it would kick up a particular problem but it seems it remains a mystery to most of us here trying to figure that out. Another problem is most of us are using the programs for different outcomes. Some need to produce DVDs others are working at higher resolutions and only concerned with either distributing content via the web or download to another system.

Last but not least is the ever increasing problem of trying to get all of this to work even when someone has just bought a shiny new bit of kit that demands even more from the software even though their system specs may be lagging behind or the tech so new the software developers have not had either the time or inclination to get on top of one problem over another problem that in their eyes is of more concern.

In your instance, one thing I would check is how fragmented your drive is containing your source files, or if you import copies of your files into a project then check that drive for fragmentation as well. If the drive has files at non contiguous block of data the glitching could partially be cause by the pauses cause by the drive heads while searching for the relevant block of data. Even a solid state drive does not have equal read and write speeds in a majority of instances although should be more of a negligible problem as speeds of such drives are often much faster although sometimes problems arise handling very large files where they slow down well beyond their quoted speeds. Sometime to an almost comparative crawl.

Ray.

@SevCardy

Hi

. . . . 27.20.100.8682 . . . .

There have been at least two if not three updates since this version, the current non Beta version is 27.20.100.8935.

. . . . All my video source files are constant frame rate . . . .

That rules out what @emmrecs and I are seeing with Variable Frame Rate video. Jeff, yet to test your AAC/WAV experience.

John EB

@SevCardy @browj2 @emmrecs @Scenestealer @me_again@me_again

Hi John.

Hi John. Yes I had noticed but also noticing what to me looks like some form of in camera stabilisation going on as the some consecutive frames expand and contract very slightly (most evident in the corners of the frames.) but I'm not really noticing any skipping or repeating of frames on playback. Each frame though looks pin sharp on any edges of detail and larger sections get compressed to larger blocks of colour such as the trees, plane wing, car bodies etc. This suggests to me quite the fast exposure time for each frame so the gaps between the slower frame rates will be greater and sudden jumps could just be the frame rate suddenly going from the slowest frame rate to the fastest. Maybe it is a persistence of vision thing as only the brain interprets what the eye 'sees' and will vary quite a bit between individuals. We know the film frame rate was set at 24fps because of that but since gaming has become more popular tests have been done proving that some people can see changes up to 70 fps or slightly above if the the equipment is fast enough to accurately reproduce the frames and therein may lie yet another problem. Not just the refresh rate of a screen but how fast is the display LCD / LED / OLED?

We may all be accurately describing what we see and not what another can see. I think we all need to be around the same monitor and PC so we can all observe the same set or variables. 😉😅

Ray.

@CubeAce

Hi Ray

. . . . We may all be accurately describing what we see and not what another can see. I think we all need to be around the same monitor and PC so we can all observe the same set or variables . . . .

Very true - in particular the monitors display response time is critical to higher frame rates, however this in itself also leads to other issues (and a very large rabbit hole again) 😂.

I will probably look into the 'stabilisation' further, AFAICR that mobile had no stabilisation feature, the movement you are seeing may be a result of me stabilising it against the window this can be seen when the pilot did a 'Ryanair' landing - there was only a small amount of vibration transmitted to the phone.

I have run the video clip through Handbrake trying different parameters and audio codecs following @emmrecs comments, and have gained no improvements in smoothing the micro jumps in any of the various exports, in one case it was aggravated, or trying some options eg stabilisation, calculate intermediate images etc.

As you know with audio, if somethings in the recording that shouldn't be there, then it is an absolute pain (to put it politely) to remove it.

Jeff - I cannot replicate what you got using my video source.

John EB

@johnebaker

Hi John.

AFAICR that mobile had no stabilisation feature, the movement you are seeing may be a result of me stabilising it against the window

The only other times I've seen the sort of slight increase and decrease of the field of view from small sensors (or some larger ones come to that but they are more obvious) is when there is a slight shift in where the point of focus rests. With these small sensors they tend to have large apertures ranging from about f1.8 to f2.8 making the image pretty much in focus from from near to far but. (Not from having such a wide aperture but the sensor sizes being so small.) A shift in where the focus spot has landed can result in a focus pulse or an imperceptible small amount of focus shift.

So to check I took screen shots of where the focus point should be (assuming it was in the middle as often these things rest there when no focus point is selected).

This is the result from just four frames.

Obviously they are not consecutive frames but you can catch my point. It's possible. It's a pity cameras don't also capture focus point information as well as other data from stills raw files.

Ray.

@SevCardy @CubeAce @johnebaker @emmrecs

Sev - you said:-

Errm, no. I'm talking in this instance about playback from the timeline.

But I was referring to what you said earlier:-

if my Nvidia card is selected under "Preview in arranger" in Program Settings: on playback from the timeline some clips jump back and appear to repeat several frames, and this also happens (subjectively to a greater degree) on export.

So can we be clear that you are seeing this on an exported clip in say a media player, or in MEP if that exported clip is dragged back into the timeline?

All - this is not a subtle effect it is a major picture disturbance that you might expect to see if a frame or several frames some distance away from the current displayed frame was randomly inserted.

Please watch this example in @Joshua-Burner example here:- https://www.magix.info/us/forum/stuttering-video-files-on-import--1260475/#ca1613220.

Note that I never use variable frame rate files in MEP / VPX - they are all from camcorders UHD 25p MP4 Sony and AVCHD 50p .mts Panasonic - constant FR.

I have seen the Joshua's effect only in playback of the VPX12 timeline, and something quite similar in an earlier version - VPX8 or maybe VPX9.

I am not sure if everybody realises that the smoothness of display of MEP/VPX generally is reflected in the very bottom left hand of the program interface next to the CPU usage % indication. There are 2 numbers 35/35 that indicate the number of frames processed ready for display - when one drops down into single figures you can expect to see playback become jerky due to dropped frames. 35 is the max.

Please post what you can see there when you observe the Jumpback effect.

Peter

@Scenestealer @SevCardy @browj2 @emmrecs @johnebaker @me_again

Hi Peter.

I am not sure if everybody realises that the smoothness of display of MEP/VPX generally is reflected in the very bottom left hand of the program interface next to the CPU usage % indication. There are 2 numbers 35/35 that indicate the number of frames processed ready for display -

I had never noticed that in VPX 😇. Me being a relatively new user an all' to VPX.

Interesting. I loaded one of my heavy effects 4K projects into VPX 11 and watched like a hawk. Four times it dropped to 1/35 and I saw delays of less than a quarter of a second or possibly less. At those moments another three times it dropped to 2/35 and the pause was there but only just. The rest of the time it got as low as 11/35 with no discernable disturbance but the majority of the time it hovered between 35/35 and 34/35.

Loading John's supplied clip it barely ever went down to 34/35.Four times at the most.

I have never personally seen what I saw in the clip you refer to on my system. Certainly I have never produced such an export. I have had failures to export using mpeg2 but little else.

[Edit]

I just noticed it's in MEP 2021 as well.

I tried Johns' clip again, had almost an identical result as using VPX 11. I also noticed CPU% showing mainly1% but a few times showed briefly 2%.

Ray.