So I have my Avisynth-processed Lagarith-encoded intermediate files loaded into the NLE, redid the edits, effects and whatnot...
Tried exporting the first part, about 11 minutes (good thing I didn't try exporting the whole thing !), and then... the Horror... the Horror...
I did many tests, screaming in the middle of the night (well, more like the end of the night), and found out that :
– When Lagarith is enabled in LAV filters, I get a seemingly random playback, with mixed frames from different parts of the same video showing completely out of order.
– when Lagarith is disabled in LAV filters, I get this sh*t when exporting a video segment containing a Lagarith source file, especially if there's a fade-in or cross-fade ; I usually don't see this scrambled aspect in preview, except when I move the transparency cursor, or sometimes on a random frame, but if I scroll again around that frame it appears normal again ; before attempting to actually export something I thought that it was only a glitch.
– It seems to export normally if I activate Intel QuickSync in LAV Video settings.
MagicYUV seems to behave about the same way, although I haven't tested as thoroughly.
Is it normal ? Why ? If not what is the likely cause ? Is it a known issue on systems based on Intel graphics from Skylake CPU ? Is activating Intel QuickSync indeed known to remedy that kind of issue ? Why does it seem to affect lossless codecs specifically ? Why is the world so mean to me ?
Taknhs ni vnadeca (sorry, I disabled LAV filters again).
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 15 of 15
Thread
-
-
Not normal; lagarith official decoder is stable, not sure about LAV because most NLE's use VFW (the official lagarith decoder) , lagarith is usually not decoded through directshow in a NLE. A video player, yes directshow possibly, but a NLE - typically no. Most NLE's have nothing to do with directshow, because it's not frame accurate when seeking (and accuracy is something you need to edit)
Quicksync has nothing to do with lagarith or magicyuv , so I don't know how that would affect it at all
But it might have to do with your GPU accelerated effects or transitions. Some NLE's can mix up frames or have issues like this, but ok if CPU is used for those operations -
I stopped using lagarith due similar issues very quickly and to be honest nowadays using only oldie but goldie huffyuv or if speed is not important (archive) ffv1 - they work always in Windows and ffmpeg, for long term archivization i would consider also h.264 in lossless mode if source demands lossless.
-
I don't know how or why, but reinstalling Lagarith (using the .exe installer) seems to have solved the issue... Yet I had verified before attempting this that the .dll was present in both System32 and SysWOW64, and both files were strictly identical to the ones in the Lagarith 1.3.27 zip archive. Perhaps it changed the “merits” or something ?
But if I open a Lagarith file in GraphStudioNext x64 it still shows “quartz.dll” as “AVI decompressor” :
I still don't know how to use this thing... -
It only matters what your NLE is using. It's unlikely directshow, so unlikely graphstudio will be of any help. But stranger things have been known to happen...
See if you can find out what it's actually using. There might be options when you click a file to import through the editor, or in the advanced options. Or uninstall a codec completely (including lav, or ffdshow or anything that has a connection to that codec) and see if it can still decode that one . If no, then you're reasonably sure it's not using an internal one. So then install one, test, repeat. Process of elimination.
Were huffyuv, magicyuv "fixed" as well ? It's unlikely that reinstalling lagarith should have any affect on them
So it has to be something else, maybe a simple reboot fixed things, or windows being windows
If the pattern is random , non repeatable, then I would start to look at hardware issues, such as bad memory, bad psu -
IMHO you should reinstall your OS - seem you chasing unstable OS environment... too many renderers, too many codecs...
-
@poisondeathray
Another issue is that I applied Magix internal stabilizer again (since pre-processing with DePanStabilize didn't produce a satisfying result, and doing a second batch of pre-processing with Deshaker would be tedious and add some more clutter to an already huge folder of intermediate files – although I keep that as an option if all else fails, at that point one more day of tediousness is not that much compared with the insane amount of hassle I already went through) : it still performs well enough (sometimes I have to re-do a scene with different parameters or a different analysis area to get a better result, but overall it's very good, and with experience I can often predict what is likely to make it fail, and how to fine-tune it the next time for an improved efficiency – no such impression of approximately knowing what I'm doing with the highly praised Mercalli plugin, which acts like a black box, with few useful and logical options, sometimes it adds bumps which weren't in the original footage for no apparent reason... well, I don't like it), BUT, when exporting a segment containing stabilized footage from a Lagarith file, with the option “eliminate black borders” enabled, there are thin borders of 1 pixel width remaining and flickering on all four sides, although they're small they're very distracting. This doesn't happen when stabilization is applied to M2TS files. I tried to disable the “eliminate black borders option” and then manually zoom in the picture, but it stupidly applies the zoom-in before the stabilization, even if it comes after in the list of effects. I tried to stabilize a cut from a M2TS file, and then apply the effect to the same cut from a Lagarith file : it worked for a while, the next test export was fine, but then it came back when I tried exporting the whole segment – as well as the other weird issues.
I've finally registered on the Magix forum and reported this issue there.
If the pattern is random , non repeatable, then I would start to look at hardware issues, such as bad memory, bad psu
It only matters what your NLE is using. It's unlikely directshow, so unlikely graphstudio will be of any help. But stranger things have been known to happen...
See if you can find out what it's actually using. There might be options when you click a file to import through the editor, or in the advanced options. Or uninstall a codec completely (including lav, or ffdshow or anything that has a connection to that codec) and see if it can still decode that one . If no, then you're reasonably sure it's not using an internal one. So then install one, test, repeat. Process of elimination.
I had a problem once importing virtual files from AVFS, which were identified as “raw YUV”, installing ffdshow x64 did the trick. So apparently, at least for some file types, it does rely on system codecs / filters.
@pandy
IMHO you should reinstall your OS - seem you chasing unstable OS environment... too many renderers, too many codecs...Last edited by abolibibelot; 27th Dec 2018 at 20:42.
-
Some hints in this old thread (2007) :
https://www.animemusicvideos.org/forum/viewtopic.php?t=79302
There are issues with Lagarith in Magix, and a few solutions.
1. Try using a newer version of Lagarith. (Some people have had issues with 1.3.12. If this is your case, you'll want to stick with 1.3.10. But clips made with a newer version may not work well (if they work at all) playing back with an older version.)
2. Don't use the multi-threading option when encoding with Lagarith.
3. Use RGB32 colorspace.
4. Switch to Huffyuv. -
It's indeed quite random, but it specifically affects lossless AVI files.
Mixed frames from different sections almost never affects I-frame codecs. That's more likely a NLE issue, such as a cache issue, or an effect issue (where it's overlaying some effects from different layers, and mixing them up)
"especially if there's a fade-in or cross-fade " - the timing strongly suggests NLE issue .
For you, since 3 lossless codecs have similar issues, it's unlikely a lagarith issue. There was a lot of fearmongering and jump on the bandwagon(ing) in the past. Some people were quick to jump to conclusions before investigating the issue properly
When people complain about lossless codec "corruption" it typically looks different than your screenshot.
Also, the defect typically affects the encode, not the decode. So the defect is permanent, and repeatable.
The thought was lagarith relied on floating point math in the arithmetic coder, and therefore prone to random error - but it turned out that was incorrect and the myth was debunked.
the highly praised Mercalli plugin
Memory would be more likely, but it would manifest in more frequent and pervasive ways, wouldn't it ?
I do have quite frequent BSODs, and a still unsolved issue of very long wake-up time from hibernation, which started when I migrated from a SATA SSD to a NVMe SSD
BSOD might have been "normal" for Win95,98 . Not now... -
It's probably all 3rd party AVI codecs , not just lossless ones. To me it "feels" like either a NLE issue, or system issue to me. It might be a bit of both.
Mixed frames from different sections almost never affects I-frame codecs. That's more likely a NLE issue, such as a cache issue, or an effect issue (where it's overlaying some effects from different layers, and mixing them up)
That doesn't exactly scream "stable" system to me... I'd run some diagnostics
BSOD might have been "normal" for Win95,98 . Not now...
Beyond the obvious I'm not sure what else I can do to properly diagnose this. I did some research several times, but it's highly frustrating to read dozens of articles and forum threads on that subject, as there are so many possible causes and no way of knowing beforehand if it's even one of the likeliest ones. At this point an exorcist might be better suited than a computer technician.
But is this the full featured Mercalli , with all the functions of the standalone, or a limited version, or older version ? -
All true but sometimes this is only one option we have - this is why i like ffmpeg - single, self sufficient binary, quite controllable dependencies, portable etc. Driver, renderer especially in heavily used (i mean lot of applications and driver installed) Windows may create difficult to isolate issues. Sometimes is easier to reinstall clean OS than chasing issues you described. Of course you can use process explorer and process monitor then do analysis and track dependencies but for sure i would start from uninstalling all suspicious software, particularly "complete" codecs packs that promising to solve issues at a cost of new issues. Staying clean with installed software is recommended. Also use ffplay or similar OS independent player to confirm that file is decoded correctly and issue is OS related not source related. Lot of patience and good luck.
Memory alignment? In your case i would check rendering path - it looks like some issue with YCbCr to RGB conversion (IMHO it is quite obvious that something going wrong with bytes order and perhaps bits order too). General shape is provided, some data can be seen but... but it looks like part of data is interpreted incorrectly. -
All true but sometimes this is only one option we have - this is why i like ffmpeg - single, self sufficient binary, quite controllable dependencies, portable etc.
Driver, renderer especially in heavily used (i mean lot of applications and driver installed) Windows may create difficult to isolate issues. Sometimes is easier to reinstall clean OS than chasing issues you described.
Of course you can use process explorer and process monitor then do analysis and track dependencies but for sure i would start from uninstalling all suspicious software, particularly "complete" codecs packs that promising to solve issues at a cost of new issues. Staying clean with installed software is recommended.
Memory alignment? In your case i would check rendering path - it looks like some issue with YCbCr to RGB conversion (IMHO it is quite obvious that something going wrong with bytes order and perhaps bits order too). General shape is provided, some data can be seen but... but it looks like part of data is interpreted incorrectly.
Doing further testing, as (un)expected, I got that wonkiness with RGB24 Lagarith too. Now, I consistently get what someone on the german Magix forum described as a “frame Salat” (unfortunately the poor dude only got frustrating replies like “convert the files with XMediaRecode”, and was harshly put down when he protested about this defeating the purpose – generally speaking on that forum it seems like they tend to question the purpose rather than attempt to solve the actual issue, for instance I was asked why I was using Lagarith files in the first place, and had to explain twice), I don't know exactly what's been changed since I can no longer get at least a normal playback for Lagarith files within MVD.
But MagicYUV files play fine now – hier is kein warum. I made further tests with a MagicYUV file :
– In a new project, I imported just the MagicYUV file, applied Magix stabilizer with the same parameters as before, a fade-in and a fade-out, then exported as Lagarith : no thin black borders, as flawless as can be (actually not quite true : see below).
– Then I copied that movie object (with stabilization and fade effects) into the current project, put it where it should be, to be displayed briefly over a longer sequence from an untouched M2TS file, and exported a few seconds, starting just before the fade-in and ending just after the fade-out : the thin flickering black borders are there.
– Then I copied all the relevant objects (including the stabilized MagicYUV sequence and the untouched M2TS) from the current project to yet another new project (or more accurately, in this case, an empty new movie within the already opened project), and exported approximately the same sequence : the thin flickering black borders are there but only at the fade-in and fade-out, the rest is fine.
I did those three tests again, after closing and re-opening the editor, with the same result. Actually, on further scrutinizing, those thin borders are already there at the fade-in and fade-out when exporting only the stabilized sequence in an otherwise empty project (same in the first test), it's just that it's less visible over a black background.
Weird... ‘O_OLast edited by abolibibelot; 28th Dec 2018 at 18:30.
-
If that's any relevant, I've noticed that the previews for lossless files were strange in Windows 7 explorer, with a sort of colored grid over the picture, orange-ish for Lagarith and MagicYUV (although for some reason the preview appears “normal” for some of them), and green for FFV1 (which I couldn't import correctly into MVD) :
Is this typical or not ?
So I'm going back to the Deshaker route... It seems to be working very well as far as I can see, problem is, if I notice any defect down the line I'll have to start all over again, at least for the affected chunk. One advantage in using MVD's stabilizer is that the effect is applied independently to each cut / movie object, if the stabilizer had some hiccups for a tricky shot it's relatively quick to re-apply the effect with different settings, and the result is immediately visible – well, except for those damn remnants of borders which keep ruining it.
Question : does it matter at all which value of zoom I set, with regards to the preservation of quality / detail ? For instance, I calculated that 2.5% should result in an integer calculation in both dimensions (either cropping the frame magnified to 1312x738, or magnifying the frame cropped to 1248x702, to get back to 1280x720, depending on how it's calculated), does this improve ever-so-slightly the accuracy of the interpolation, compared with 2% or 3%, or is it totally irrelevant ? Perhaps it's only when scaling by a multiple of 2 that the calculation is more accurate ? Or even that is not necessarily true ? -
Not sure about previews ; I don't have them enabled on any computer. There are some preview manager software IIRC, I don't recall the name
Not sure about zoom , but it makes sense that an integer would be more accurate. But I don't know the nitty gritty details of how deshaker actually implements it. You can do some quick tests and decide what is acceptable
Scaling by multiple of 2 has to do with nearest neighbor algorithm - it's lossless if done correctly, because you're just duplicating pixels (and dropping the same pixels when scaling back down). Unlikely that you'd scale that much for a stabliizer
Similar Threads
-
DV to Lagarith conversion help
By robmausser in forum Video ConversionReplies: 7Last Post: 19th Aug 2017, 22:27 -
Smart render. Lagarith > Vegas(edit) > Lagarith.
By ValentineStone in forum Video ConversionReplies: 11Last Post: 5th Oct 2016, 13:31 -
Lagarith to mp4
By timsky in forum Video ConversionReplies: 5Last Post: 22nd Aug 2016, 15:50 -
CD Autoplay weirdness in XP
By davexnet in forum ComputerReplies: 7Last Post: 16th Mar 2014, 21:16 -
Sony NEX-6 PAL/NTSC weirdness
By tchimento in forum Camcorders (DV/HDV/AVCHD/HD)Replies: 10Last Post: 24th Jan 2014, 11:54