VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 15 of 15
Thread
  1. 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...
    Click image for larger version

Name:	20151224-1_00_10_55_001.png
Views:	55
Size:	1.11 MB
ID:	47620
    Click image for larger version

Name:	20151224-1 [Lagarith 1T].avi - 00_09_32 -2018-12-26-05h20m13s426.png
Views:	51
Size:	618.6 KB
ID:	47621
    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).
    Quote Quote  
  2. 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
    Quote Quote  
  3. 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.
    Quote Quote  
  4. HuffYUV looks better indeed :
    Click image for larger version

Name:	MVD HuffYUV.png
Views:	40
Size:	1.05 MB
ID:	47628
    Quote Quote  
  5. 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” :
    Click image for larger version

Name:	GraphStudioNext x64 propriétés AVI Decompressor pour fichier Lagarith.png
Views:	31
Size:	35.1 KB
ID:	47629
    I still don't know how to use this thing...
    Quote Quote  
  6. 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
    Quote Quote  
  7. IMHO you should reinstall your OS - seem you chasing unstable OS environment... too many renderers, too many codecs...
    Quote Quote  
  8. @poisondeathray
    Were huffyuv, magicyuv "fixed" as well ? It's unlikely that reinstalling lagarith should have any affect on them
    Unfortunately it came back with Lagarith... I guess that it was just random luck. é_č I haven't tried again with other lossless formats, I've already done the tedious work of re-editing the footage to match what was done previously with the raw M2TS source files, so I'm trying to obtain a correct export with Lagarith source files.

    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's indeed quite random, but it specifically affects lossless AVI files. How would a bad PSU have any bearing on an issue like this ? 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, but don't see how this could be related with a specific issue with lossless video formats and a specific NLE software – although, as you rightfully say, stranger things have been known to happen...

    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...
    Indeed... é_č

    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.
    Generally I just drag-and-drop files from Windows explorer, to place them approximately where I want instead of right at the end of the timeline. I don't see any particular option related to file importing.
    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...
    That's a bit radical... I generally don't like it when that solution is proposed on forums as a remedy for the slightest hiccup. I prefer to track down the specific malfunction which is causing a problem, and hopefully learn something out of it. Besides, re-installing the OS is a huge amount of work in and of itself, not something I want to do on a regular basis. I do have a system backup just a few months old, I could try to restore it with that, but it's always risky, I would still have to update quite a lot of things which have changed since then, and if it turns out that it didn't solve the issue I would have done all those steps for nothing.
    Last edited by abolibibelot; 27th Dec 2018 at 20:42.
    Quote Quote  
  9. 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.
    Quote Quote  
  10. It's indeed quite random, but it specifically affects lossless AVI files.
    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)

    "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
    But is this the full featured Mercalli , with all the functions of the standalone, or a limited version, or older version ?


    Memory would be more likely, but it would manifest in more frequent and pervasive ways, wouldn't it ?
    Serious memory issue usually results in BSOD ; but this type of less drastic random errors is often a first sign.


    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
    That doesn't exactly scream "stable" system to me... I'd run some diagnostics

    BSOD might have been "normal" for Win95,98 . Not now...
    Quote Quote  
  11. 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.
    I tried to create an AVS script opening the already pre-processed Lagarith file, loading it into the NLE through AVFS (which should be seen as raw RGB, and should not require any decoder, right ?) : same kind of wonky behaviour (but worked on another segment – it's totally unpredictable). Converted Lagarith RGB32 to Lagarith RGB24 (by the way I don't understand why it's converted as RGB32 by default when the Avisynth command is “ConvertToRGB”, not “ConvertToRGB32”) : seems to work better (which would seem to contradict the advice quoted above about using RGB32 colorspace), but still those flickering borders which shouldn't be there (and it could be wonky too the next time I try...).

    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)
    Unlikely an effect issue since it happens right away when the files have just been exported.

    That doesn't exactly scream "stable" system to me... I'd run some diagnostics
    BSOD might have been "normal" for Win95,98 . Not now...
    When it happens, most of the time it's after several days without a proper reboot, using hibernation once a day to get back to business ASAP, and typically running many different things at the same time, in those circumstances it could be considered as “pushing it” beyond a computer's “normal” use (at least that's what a hardware component manufacturer or someone from Microsoft would say – and they would perhaps advise to upgrade to Windows 10, as windows 7 is approaching the status of antiquated OS). Although a few days ago it happened repeatedly for no apparent reason; then it hasn't happened in 4 days.
    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 ?
    It's v2 and it's bundled with a relatively low-end software (compared with the likes of Premiere Pro), so it's probably limited, but I'm evaluating the options that I have available.
    Quote Quote  
  12. Originally Posted by abolibibelot View Post
    @pandy
    IMHO you should reinstall your OS - seem you chasing unstable OS environment... too many renderers, too many codecs...
    That's a bit radical... I generally don't like it when that solution is proposed on forums as a remedy for the slightest hiccup. I prefer to track down the specific malfunction which is causing a problem, and hopefully learn something out of it. Besides, re-installing the OS is a huge amount of work in and of itself, not something I want to do on a regular basis. I do have a system backup just a few months old, I could try to restore it with that, but it's always risky, I would still have to update quite a lot of things which have changed since then, and if it turns out that it didn't solve the issue I would have done all those steps for nothing.
    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.

    Originally Posted by abolibibelot View Post
    (by the way I don't understand why it's converted as RGB32 by default when the Avisynth command is “ConvertToRGB”, not “ConvertToRGB32”) : seems to work better (which would seem to contradict the advice quoted above about using RGB32 colorspace), but still those flickering borders which shouldn't be there (and it could be wonky too the next time I try...).
    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.
    Quote Quote  
  13. 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.
    Well it's powerful and versatile indeed, but you can't do everything with ffmpeg...

    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.
    Sometimes I wish I could reinstall my whole life, it would be easier than trying to isolate and fix everything that's wrong with it...

    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.
    The only “package” I installed is CCCP, which, if I understand it correctly, is just LAV filters with an extra configuration layer, it's supposed to be “as unintrusive on [the] system as possible”. Other than that I only have individual codecs like Lagarith and MagicYUV.

    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.
    How could I check the rendering path ?

    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_O
    Last edited by abolibibelot; 28th Dec 2018 at 18:30.
    Quote Quote  
  14. 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) :
    Click image for larger version

Name:	VD2 save file -- aperçu des fichiers “lossless”.png
Views:	11
Size:	158.5 KB
ID:	47650
    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 ?
    Quote Quote  
  15. 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
    Quote Quote  



Similar Threads