Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
30th September 2008, 11:46 | #82 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Same way you install huffyuv in win64 (xp or vista): http://www.dvinfo.net//conf/what-hap...ta-64-bit.html
|
23rd November 2009, 18:49 | #84 | Link |
Registered User
Join Date: Apr 2009
Posts: 93
|
Does anyone know if Lagarith is still being developed? I submitted a bug report a couple of times to the author a few months ago but there was no reply.
I'll pasted the details below in the hope that he may see it here. I'm getting crashes with the Lagarith encoder when it is configured to YUY2 or YV12 in its settings. This only happens when the input video size is 1280x720, there is no problem when it is 1920x1080. I'm feeding 1280x720 RGB24 video frames from Mainconcept or Elecard H.264 decoders to Lagarith for encoding. Both of these H.264 decoders cause Lagarith to crash with an access violation at the first sample delivered - here is a stack traceback when using the Mainconcept decoder: lagarith.dll!0b581b7b() lagarith.dll!0b584e9c() lagarith.dll!0b5852d2() lagarith.dll!0b587863() msvfw32.dll!6c2718e6() msvfw32.dll!6c274fb7() qcap.dll!6c32a394() qcap.dll!6c349455() qcap.dll!6c349840() ...... However, when the ffdshow H.264 decoder filter is feeding Lagarith then there is NO crash and the filter graph runs fine. Having looked at the media types it looks like the sample size and actualdatalength for ffdshow are set to sample actual data length 2764800 sample size 3686400 but for Mainconcept and Elecard, the sample size and actualdatalength are BOTH set to 2764800. I therefore wonder if Lagarith is making an incorrect calculation of the sample size giving it a size beyond 2764800 which leads to an access voliation for Mainconcept and Elecard; but not with ffdshow because its sample size is much larger at 3686400. If lagarith is set to RGB in its options sheet then this also avoids the crash and the filter graph runs OK. So maybe lagarith is getting the data size incorrect when doing its internal RGB to YUY2 conversion? Strange that this doesn't happen for 1920x1080 sized video though. I also noticed that one of the last fixes is "Fixed a bug that would corrupt video when downsampling to YUY2 and the resolution was not a multiple of 32". Notice that 720 is not an exact multiple of 32, so maybe this has something to do with the problem too. Also if "Use multithreading" is selected in Lagarith's options when the above crash happens, the program seems to terminate but Task Manager shows that there is a thread still running inside Lagarith and using approx 40% of CPU time. The only way to get rid of this is the End Process button in Task Manager. If "Use multithreading" is NOT selected then this vestigial thread is not left running and the process disappears completely from Task Manager's list. |
23rd November 2009, 23:22 | #85 | Link |
Registered User
Join Date: Feb 2008
Posts: 26
|
The homepage http://lags.leetcode.net/codec.html had an update in July 2009, so I guess it is still developed.
|
24th May 2010, 15:12 | #86 | Link |
Registered User
Join Date: Oct 2006
Posts: 24
|
Hi folks,
is there any chance to see the Lagarith Codec for MAC in future? :) For easier handshakes on exchanging material PC <--> MAC it would be a great plus for the workflow. THX a lot for developing this great codec. Jim |
25th May 2010, 22:59 | #89 | Link |
Registered User
Join Date: Apr 2009
Location: Switzerland
Posts: 69
|
I believe the lagarith source itself is Windows specific. I also read it uses a floating point arithmetic (or range?) coder, which makes portability less fun. Nathan Caldwell started a yv12 decoder for FFMpeg and they came up with something to emulate the problem with the entropy coder. The git of the fork is here. Looks like everyone is busy with higher priorities, so it's more likley the far future.
Once it gets finished, it probably gets comitted to FFMpeg and usable with perian (I'm assuming that's the ffdshow equivalent on OS X) or something. I don't know if there are any other porting projects for lagarith.
__________________
My nightmares are horrifying, they're all interlaced! |
27th May 2010, 13:43 | #90 | Link | |
Registered User
Join Date: Oct 2006
Posts: 24
|
Quote:
Jim |
|
3rd January 2011, 22:06 | #91 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Another Lagarith question: why are settings not persistant in some apps? I can set Colorspace to YV12 and Multithreading on in VirtualDub 32-bit just fine. But if I "Okay" and go back to the dialog in VDub 64-bit or any Adobe video apps, everything is back at the defaults when I return.
Any ideas/workarounds? |
4th January 2011, 10:21 | #92 | Link |
Registered User
Join Date: Dec 2008
Posts: 589
|
Settings are saved in C:\Windows\Lagarith.ini - maybe the 64bit windows API functions used by Lagarith report a different folder instead of "C:\Windows", like "c:\windows\Sys64" or something like that.
Use Filemon from SysInternals Suite to see where's is the codec trying to find the ini file. |
4th January 2011, 14:20 | #93 | Link | |
Registered User
Join Date: Feb 2004
Posts: 127
|
Run these 64bit apps with admin rights (run with admin), and u see, settings is saved.
My idea: try x264 vfw codec, lossless mode is very good. Quote:
|
|
9th January 2011, 09:11 | #94 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
The decoder has been committed to ffmpeg:
http://git.ffmpeg.org/?p=ffmpeg;a=co...092d643006af3c If only I had been aware of this going on on the mailing list over the last few days, I wouldn't have gone to the trouble of adjusting a local clone of the repo.or.cz branch to current ffmpeg manually last night (to use with FFMS2), just 12 hours before the official commit occurred. |
10th January 2011, 13:41 | #95 | Link | |
Registered User
Join Date: Jun 2005
Posts: 278
|
Quote:
|
|
10th January 2011, 17:34 | #96 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
It can be duplicated by artificial means. Code:
BlankClip(40) ++ BlankClip(40).Invert() |
|
10th January 2011, 20:57 | #97 | Link |
Registered User
Join Date: Jun 2005
Posts: 278
|
Upload a sample, preferably as an attachment to an FFmpeg bug report.
A report on this board with instructions to reproduce that require Windows when basically none of the developers (including me) use Windows, if they can avoid it, is unlikely to help getting a fix any time soon. |
14th February 2011, 12:43 | #100 | Link |
Registered User
Join Date: Jan 2005
Posts: 368
|
New version 1.3.21
http://lags.leetcode.net/codec.html The changelog looks like it delivers significant performance improvements. Version 1.3.21 released on 2-13-2011 Fixed a bug that would cause the codec to crash when downsampling certain resolutions. Thanks to Richard Jones for reporting this bug and tracking down the cause. Several speed improvements: - Integrated RLE restoration into range decoder so decoding only takes one pass through the data. - Increased range decoder hash table size. - Removed RLE level 2, testing indicates that it doesn't offer any real benefit verses levels 1 or 3. - RLE compression now encodes all levels in parallel and selects the best one rather than perform an estimation run and then an RLE run. - RLE compression now has a faster SSE version for processors that support SSE. - Added and improved existing MMX/SSE/SSE2 optimizations for several functions relating to median prediction and image layout. Overall I typically see about a 10-30% speed improvement. Tweaked how RLE level is selected to improve compression by about 1%. Tweaked how the work is distributed in multithreading to reduce wasting CPU time. Removed Reduced Resolution mode, I don't think it is useful enough to justify maintaining.
__________________
Thankyou!, I am grateful for any help Last edited by video_magic; 14th February 2011 at 12:44. Reason: add changelog info |
Tags |
lagarith |
|
|