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.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th September 2008, 11:31   #81  |  Link
lilhobo
Registered User
 
Join Date: Mar 2002
Posts: 410
the first user on a fresh vista install is the admin i would guess
lilhobo is offline   Reply With Quote
Old 30th September 2008, 11:46   #82  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,175
Quote:
Originally Posted by lilhobo View Post
how can i install for vista64?? the bat wont work for me
Same way you install huffyuv in win64 (xp or vista): http://www.dvinfo.net//conf/what-hap...ta-64-bit.html
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
foxyshadis is offline   Reply With Quote
Old 10th October 2008, 10:11   #83  |  Link
totya
Registered User
 
Join Date: Feb 2004
Posts: 127
Hi!

v1.3.19 uninstall function is bad under XP32 again (and again and again and again...)

I wrote this before.

Thx.
totya is offline   Reply With Quote
Old 23rd November 2009, 18:49   #84  |  Link
ipanema
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.
ipanema is offline   Reply With Quote
Old 23rd November 2009, 23:22   #85  |  Link
weaker
Registered User
 
Join Date: Feb 2008
Posts: 24
The homepage http://lags.leetcode.net/codec.html had an update in July 2009, so I guess it is still developed.
weaker is offline   Reply With Quote
Old 24th May 2010, 15:12   #86  |  Link
Jim_Pansen
Registered User
 
Join Date: Oct 2006
Posts: 15
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
Jim_Pansen is offline   Reply With Quote
Old 25th May 2010, 10:56   #87  |  Link
johnsonlam
Registered User
 
johnsonlam's Avatar
 
Join Date: Nov 2003
Location: Kowloon, Hong Kong
Posts: 161
Mac OSX should have some lossless codec, both video and audio!
__________________
Hong Kong - International Joke Center (after 1997-6-30)
johnsonlam is offline   Reply With Quote
Old 25th May 2010, 20:21   #88  |  Link
Jim_Pansen
Registered User
 
Join Date: Oct 2006
Posts: 15
Quote:
Originally Posted by johnsonlam View Post
Mac OSX should have some lossless codec, both video and audio!
My question was related to interoperability, not to the general question "Is there any losless MAC codec"!

Your answer doesn't match my question.

Jim
Jim_Pansen is offline   Reply With Quote
Old 25th May 2010, 22:59   #89  |  Link
Boolsheet
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!
Boolsheet is offline   Reply With Quote
Old 27th May 2010, 13:43   #90  |  Link
Jim_Pansen
Registered User
 
Join Date: Oct 2006
Posts: 15
Quote:
Originally Posted by Boolsheet View Post
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.
THX for your reply. This explains something for me!

Jim
Jim_Pansen is offline   Reply With Quote
Old 3rd January 2011, 22:06   #91  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,395
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?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Instant Video

My Compression Book

Amazon Instant Video is hiring! PM me if you're interested.
benwaggoner is offline   Reply With Quote
Old 4th January 2011, 10:21   #92  |  Link
mariush
Registered User
 
Join Date: Dec 2008
Posts: 559
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.
mariush is offline   Reply With Quote
Old 4th January 2011, 14:20   #93  |  Link
totya
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:
Originally Posted by benwaggoner View Post
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?
totya is offline   Reply With Quote
Old 9th January 2011, 09:11   #94  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 890
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.
qyot27 is offline   Reply With Quote
Old 10th January 2011, 13:41   #95  |  Link
Reimar
Registered User
 
Join Date: Jun 2005
Posts: 278
Quote:
Originally Posted by qyot27 View Post
The decoder has been committed to ffmpeg:
http://git.ffmpeg.org/?p=ffmpeg;a=co...092d643006af3c
Please consider it experimental though, it's been committed due to demand and too little time of the original author, but it does have some issues (I am not aware of it decoding anything incorrectly though, but I wouldn't 100% exclude the possibility either).
Reimar is offline   Reply With Quote
Old 10th January 2011, 17:34   #96  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 890
Quote:
Originally Posted by Reimar View Post
Please consider it experimental though, it's been committed due to demand and too little time of the original author, but it does have some issues (I am not aware of it decoding anything incorrectly though, but I wouldn't 100% exclude the possibility either).
I'm sure it's already known, but there is one specific case that I've seen it choke on. From what I can recall of how Lagarith's methodology was described, if it detects frames of a solid color it stores them as a flag or something rather than a full frame (the video generated by the below script at 640x480 results in a 10KB Lagarith file, as does that same script with a resize to 1920x1080). This behavior can't be turned off, so it can occur in the middle of any given sort of video material. But the fflagarith decoder outputs green frames instead of the intended color.

It can be duplicated by artificial means.
Code:
BlankClip(40) ++ BlankClip(40).Invert()
would be sufficient.
qyot27 is offline   Reply With Quote
Old 10th January 2011, 20:57   #97  |  Link
Reimar
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.
Reimar is offline   Reply With Quote
Old 11th January 2011, 05:29   #98  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 890
Report submitted with attached sample. Hopefully I did it correctly.
qyot27 is offline   Reply With Quote
Old 11th January 2011, 09:50   #99  |  Link
Reimar
Registered User
 
Join Date: Jun 2005
Posts: 278
Quote:
Originally Posted by qyot27 View Post
Report submitted with attached sample. Hopefully I did it correctly.
I think so. It's very strange that you do not get any error messages in the output though, there's probably more than one bug there.
Reimar is offline   Reply With Quote
Old 14th February 2011, 12:43   #100  |  Link
video_magic
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
video_magic is offline   Reply With Quote
Reply

Tags
lagarith

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 01:48.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.