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 2nd December 2013, 02:42   #181  |  Link
SirLagsalot
Registered User
 
Join Date: Mar 2011
Posts: 10
Quote:
Originally Posted by LoRd_MuldeR
Well, as long as the encoder and the decoder need to do this step in the exactly same way, things could go still go wrong and break decoding, right?
No, the code and the inputs are identical, so the output will be identical as long as the same floating-point state (rounding mode and precision) are used.

Quote:
Originally Posted by LoRd_MuldeR
Hmm, to my knowledge there's at least the classical "x87" FPU with 80-Bit internal precision and the newer SIMD (MMX, SSE, etc) instructions with "only" 64-Bit precision. Even if all variables are 64-Bit (double) precision in memory, the compiler may still keep intermediate results in registers, which would then be either 80-Bit or 64-Bit. Furthermore, even if you don't use SIMD assembly/intrinsic explicitly, compilers may still generate such instructions when targeting CPU's with MMX/SSE support. Finally, there are various compiler settings that effect floating point math ("fast math" option, etc). So there's at least the danger of "portability" issues when the encoder/decoder are compiled with different compilers (compiler configuration).
Lagarith uses the 53-bit precision mode for floating point, so none of those variations in potential precision end up affecting the result. It also checks and sets the floating point state if need be, so even if Lagarith was compiled with the wrong settings by someone else, it would be corrected at run-time.
SirLagsalot is offline   Reply With Quote
Old 4th December 2013, 04:35   #182  |  Link
ChiDragon
Registered User
 
ChiDragon's Avatar
 
Join Date: Sep 2005
Location: Vancouver
Posts: 600
Quote:
Originally Posted by SirLagsalot View Post
Sure, I can check if it is using the full bit-depth.
Here you go, a VHS sample. Possibly not all that useful for you: WinRAR gave it a steady 51% compression, so I'm guessing it is 9-bit. That would also make sense because a guy opened up the next model in this line of AV syncs and found a Philips SAA7113 was the ADC.
ChiDragon is offline   Reply With Quote
Old 4th December 2013, 11:21   #183  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
So wait, does Lagarith not have the problem and just some people, or are you talking about something else (Lagalot?)
zerowalker is offline   Reply With Quote
Old 5th December 2013, 00:25   #184  |  Link
SirLagsalot
Registered User
 
Join Date: Mar 2011
Posts: 10
Zerowalker, I think early on some people were seeing glitches from other causes and assuming it was due to floating point math errors; and then the rumor stuck around long after the actual bugs were fixed.
SirLagsalot is offline   Reply With Quote
Old 9th December 2013, 13:09   #185  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Oh, well letīs hope thatīs the case, really like the codec and some fundamental error like that would really ruin it.
zerowalker is offline   Reply With Quote
Old 26th May 2014, 22:17   #186  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
It seems the "Floating Point" errors actually does exist, at least from my understanding in my discussion with an ffmpeg developer.

Not entirely sure, but if am understand things correctly, in normal circumstances the errors shouldn't appear.
But if it's not an x86 system it will, though that doesn't tell me much, as i am sure x64 is still an x86 system;S

Quote:
The original codec implementation uses floating point arithmetic which will fail on processors != x86 and might fail if you use another compiler. FFmpeg's implementation is fixed-point (which is what you expect for a lossless codec) meaning you can compile it for any hardware with any (non-broken) C compiler and you will always get correct (bitexact) output. Fixed-point arithmetic is often slower than floating-point on typical hardware.
See also (for example):
https://lists.ffmpeg.org/pipermail/f...er/079680.html
http://mod16.org/hurfdurf/?p=142

I personally have never seen any corrupt frames that i can think of, and i have been using Lagarith quite a bit, so i think i should have encountered it by now.
Though again, that depends what a "corrupt frame" is, if it's 1 pixel that's wrong, then it's not possible i have noticed it, but if it's an entire corrupted imaged, that's another story.
zerowalker is offline   Reply With Quote
Old 4th March 2015, 22:34   #187  |  Link
Kein
Registered User
 
Kein's Avatar
 
Join Date: Mar 2010
Posts: 79
Anyone by any chance has some speed stats mt LAGS 1.3.27 vs Huffyuv?
Kein is offline   Reply With Quote
Old 4th March 2015, 22:45   #188  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by Kein View Post
Anyone by any chance has some speed stats mt LAGS 1.3.27 vs Huffyuv?
http://forum.doom9.org/showthread.ph...92#post1668292
poisondeathray 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 09:06.


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