LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Well, I guess implementing the thing on the first chapter shouldn't be too hard, but the display of the subtitles on the third chapter could be problematic. We basically have that problem already with seeking in files without chapters - if you seek into the middle of a subtitle, it won't be displayed because the splitter doesn't know about the line. Its packet is interleaved into an earlier time. The new Matroska features are supposed to fix that but LAV does not implement it - nor does any other program that I know of for that matter.

Indeed. I managed to fix the too long display pretty easily (easier then i thought it would be), however re-displaying it for the second part of Segment A is something for the future, and it will then only work if its muxed with a very recent version of mkvmerge.

[nevcairiel]

LAV Filters 0.56

General
- Major ffmpeg update, the DLLs have had their version number increased

LAV Splitter
- Support for Matroska Ordered Chaptes / Segment Linking
- Improved support for parsing language tags from OGM files
- Small performance improvements by avoiding copying the stream data in memory needlessly
- Improved duration calculation for MP3 files

LAV Video
- Performance improvements for single-threaded decoders and YADIF (up to 20% in some situations)


Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.56.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.56.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.56-x64.zip)

While it may not seem like it, there are actually two big things in this version (and many may only care about one).

Performance Improvements
The overall performance of demuxing and decoding was improved (depending on the use-case up to 20%!), thanks to what in Libav/FFmpeg is called "The Evil Plan". In short, it allows to properly handle the data (both packets from the splitter and decoded video/audio) much more flexible than i could before, which means now i can finally use the full power of LAVs thread design for more than just the wmv3 dmo decoder. This avoids copying the frames in memory, allows parallel processing, and especially when combined with YADIF (or any external post-processing filter), can result in huge performance gains. It also helped to simplify a lot of tricky situations, so all in all, well worth all the effort put in on FFmpeg/Libav's side.

Matroska Ordered Chapters / Linked Segments
This is probably the one much more exciting for you guys.
LAV can now handle Matroska's ordered chapters, linked segments, and linked files. If you don't know what that means, its like seamless branching for Matroska - if you haven't heard that either, well, in short, it allows multiple versions of one movie in one file, or splitting parts of the movie into separate files (so for example the opening of a TV show can be reused by all episodes, instead of being included in every one)

Please note that the same restrictions apply that also apply when using Haali Splitter for ordered chapters: The tracks between different segments need to match, or who knows what will happen! :)

Personally, i use it to archive Blu-rays with multiple editions on one disc, like Avatar.

There has already been a lot of testing of these features, thanks to everyone taking the time to test and report in great detail, and even craft samples to help me reproduce difficult cases.
Nevertheless, i don't expect it to be completely bug-free, so if you encounter any issues, crashes, or other undesirable behaviour, please report them here or on the Google Code issue tracker, preferably with a sample (or info how to get/make one) for me to reproduce the problem, and then fix it. :)

And one last point, before it comes up, there is one known issue which i didn't get to yet, but wanted this version out anyway:
Fraps decoding currently only outputs its "key" frames, the repeated frames are not output, which basically means Fraps can be a VFR stream, and not CFR like it was before. I do plan to fix this again, possibly for 0.56.1 already (if i don't have to make an emergency release), but for the time being, thats how it is.

Anyway, take care and have fun!

[Sebastiii]

Very Big thanks :)
Works really nice :)

[Niyawa]

You just made history nev. Thanks.

[andyvt]

LAV Filters 0.56
In short, it allows to properly handle the data (both packets from the splitter and decoded video/audio) much more flexible than i could before...

Are the changes to the Packet class an e.g. of this?

[huhn]

great news no need for haali anymore.
big thx!

[DarkSpace]

the display of the subtitles on the third chapter could be problematic. We basically have that problem already with seeking in files without chapters - if you seek into the middle of a subtitle, it won't be displayed because the splitter doesn't know about the line. Its packet is interleaved into an earlier time. The new Matroska features are supposed to fix that but LAV does not implement it - nor does any other program that I know of for that matter.
however re-displaying it for the second part of Segment A is something for the future, and it will then only work if its muxed with a very recent version of mkvmerge.
Okay, thanks for the explanation. I already suspected that these new elements may be required and that it might take some while for it to be implemented, but for now, that's good enough for me - after all, I still consider such files broken (at least if they were created before LAV gained Ordered Chapters support;))

Also, on the matter of the new release version: Thank you very much, and congratulations!

[nevcairiel]

Are the changes to the Packet class an e.g. of this?

Indeed, the Packet class now does reference counting on the data so that it can be safely passed around.

[Niyawa]

Okay restarted MPC-HC no drop, it was copy-back indeed. Now I restart and it drops again. I'm not sure why... heh I give up. nev there must be something wrong with LAV.

Reinstalled madVR and LAV all together, issue seems to be gone... maybe I messed up somewhere in the update. Sorry again.

@Devrim
Updated to latest lite just to test and no crash.

[Devrim]

LAV Filters 0.56 seems to crash my MPC-HC

MPC-HC (Lite) 1.6.7.7063, madVR v0.86.1, AC3 Filter v2.5b

Anyone else got the same problems?

[Snowknight26]

Now all you need to do, nev, is to gently persuade madshi to drop gdsmux from eac3to in favor of another muxing library so us plebs can ditch Haali's splitter altogether. ;)

I look forward to that Fraps bug being fixed.

[bejita7]

R.I.P. Haali Matroska Splitter

Thank you very much!

[nevcairiel]

LAV Filters 0.56 seems to crash my MPC-HC

When does it crash? When closing the file/player by any chance, or somewhere else?
Or maybe a MKV with Vorbis audio?

In any case, try with this?
http://files.1f0.de/lavf/LAVFilters-0.56-2-gfa767af.zip

It fixes one crash bug that i managed to reproduce myself sporadically when closing the player after playing with native DXVA2, and another one i got reported when playing certain Vorbis MKV files.

[SamKook]

I was wondering, did I screw something up when installing directly from the dev build you just posted or is it normal that the splitter tray icon doesn't let you select the tracks/editions when you right click it like haali does.

Pardon me if it has already been mentioned(I have to admit I didn't search the thread and haven't been following it for long), but it would be really nice if this was implemented(if it isn't already) in a future version since it's now my only reason to still use haali.

[nevcairiel]

This is not supported yet, its planned for a future version, though.
The tray icons would be rather pointless if all they do is exist. :p

[Devrim]

When does it crash? When closing the file/player by any chance, or somewhere else?
Or maybe a MKV with Vorbis audio?

In any case, try with this?
http://files.1f0.de/lavf/LAVFilters-0.56-2-gfa767af.zip

It fixes one crash bug that i managed to reproduce myself sporadically when closing the player after playing with native DXVA2, and another one i got reported when playing certain Vorbis MKV files.

Hi,

It crashes whenever I try to open a file. When it loads it crashes. It crashes with the "normal" LAV 0.56 and with your fixed LAV 0.56.

I tried 2 different files
1. MKV with AAC audio (720P)
Result: Crash while loading
2. MKV with MP2 Audio (576P)
Result: No crash

-edit-

Hmm, it only seems to crash on 1 file

Mediainfo of the file it crashes on



General
Unique ID : 225070625897904004580006034380923570318 (0xA953069AF3A191A691FD9D973473888E)
Format : Matroska
Format version : Version 4 / Version 2
File size : 614 MiB
Duration : 21mn 8s
Overall bit rate : 4 058 Kbps
Movie name : Tosh.0 - Web Redemption: BK Chicken Fries (S05E10)
Encoded date : UTC 2013-04-10 12:03:38
Writing application : mkvmerge v6.1.0 ('Old Devil') built on Mar 2 2013 14:32:37
Writing library : libebml v1.3.0 + libmatroska v1.4.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 21mn 8s
Width : 960 pixels
Height : 718 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Title : Video
Language : English
Default : Yes
Forced : No
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 21mn 8s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : English Audio (AAC2.0)
Language : English
Default : Yes
Forced : No

Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : CC
Language : English
Default : Yes
Forced : No



Weird

[hubblec4]

LAV Filters 0.56
[CODE]
....
LAV Splitter
- Support for Matroska Ordered Chaptes / Segment Linking
......
Anyway, take care and have fun!

wow, i cant believe it.

Thank you very much.

i will try it.

[STaRGaZeR]

nev, with 0.56 this sample is stuttering when a combination of avcodec+yadif is used, and disappears when you disable yadif or use DXVA. Didn't happen with 0.55.2, I don't have 0.55.3 to test.

File: http://www.mediafire.com/?41wnivhs55o6z0d
Shot of the issue: http://www.imagebam.com/image/8ac700248179570

[nevcairiel]

Hmm, it only seems to crash on 1 file


Can you maybe cut a small part from this file?
You can try using a simple splitter like DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip), cut off the first 10mb or so, and test if the small file still crashes. With MKV that should usually work.

[nevcairiel]

nev, with 0.56 this sample is stuttering when a combination of avcodec+yadif is used, and disappears when you disable yadif or use DXVA. Didn't happen with 0.55.2, I don't have 0.55.3 to test.

Could this be a performance problem?
I see nothing obvious wrong in the timings or otherwise, but on my laptop i also see the spikes, even if it benchmarks with ~100fps on that sample with YADIF on.

Heck it even happens without YADIF on o.O

I have yet to compare to 0.55, though.

[STaRGaZeR]

Could this be a performance problem?
I see nothing obvious wrong in the timings or otherwise, but on my laptop i also see the spikes, even if it benchmarks with ~100fps on that sample with YADIF on.

Heck it even happens without YADIF on o.O

I have yet to compare to 0.55, though.

It certainly can be a performance problem, that was my first thought, but as it never happened before and in benchmarks it works fine (but slower than 55.2 here, 200 vs 211 fps, interesting) I started to look for other causes without success. It always fixes itself for me when I disable yadif or use DXVA on the ATI though.

BTW the source is BD.

[Devrim]

Can you maybe cut a small part from this file?
You can try using a simple splitter like DGSplit (http://neuron2.net/dgsplit/dgsplit12.zip), cut off the first 10mb or so, and test if the small file still crashes. With MKV that should usually work.

I did split the file and the split file did work, maybe the original file is corrupt, I will try to redownload the file and see if it crashes again

[nevcairiel]

It certainly can be a performance problem, that was my first thought, but as it never happened before and in benchmarks it works fine (but slower than 55.2 here, 200 vs 211 fps, interesting) I started to look for other causes without success. It always fixes itself for me when I disable yadif or use DXVA on the ATI though.

Try with this instead?
http://files.1f0.de/lavf/LAVFilters-0.56-3-g84019e5.zip

I changed something that was not really intentional to be activated for multi-threaded codecs, and may have a negative impact on performance for them, actually.

[Devrim]

I did split the file and the split file did work, maybe the original file is corrupt, I will try to redownload the file and see if it crashes again

I redownloaded the file and it kept crashing, I also downloaded the 1080P version of the same video and it also crashes. It seems the encoder of the file has done something to it that makes LAV+MPC-HC crash. When I split the file everything is fine.

[andyvt]

Indeed, the Packet class now does reference counting on the data so that it can be safely passed around.

Thanks. Will have a closer look at how it works.

[itsonlyjustincase]

CUVID decoding doesn't use the CUDA cores. It uses a separate decoder.

Oh i didn't know. I thought CUDA was a technology perfect for video encoding/decoding and thought CUVID was using it. Hope next Lav Filters will include CUDA usage

[paradoxical]

Oh i didn't know. I thought CUDA was a technology perfect for video encoding/decoding and thought CUVID was using it.

No, CUVID is simply an API to use the hardware decoder.

Hope next Lav Filters will include CUDA usage

For what exactly? Simply using CUDA does not make things faster.

[itsonlyjustincase]

No, CUVID is simply an API to use the hardware decoder.



For what exactly? Simply using CUDA does not make things faster.

Okay i thought it would :). I need something that permit me to play multiple H264 1080p vidz at the same time

[kerimcem]

my card ati3650 and mobillty ati 3450 lav dxva mode...both same..
are some of the green screen videos(wmv,vc1)
daum player dvxa mode+madvr no problem..works well....mpc,lav problem...
http://j1304.hizliresim.com/18/c/lzfg5.jpg

ile size : 300 MiB
Duration : 20mn 14s
Overall bit rate mode : Variable
Overall bit rate : 2 071 Kbps
Maximum Overall bit rate : 4 098 Kbps
Encoded date : UTC 2010-04-22 16:45:25.187

Video
ID : 2
Format : VC-1
Format profile : MP@HL
Codec ID : WMV3
Codec ID/Info : Windows Media Video 9
Codec ID/Hint : WMV3
Description of the codec : Windows Media Video 9 - Professional
Duration : 20mn 14s
Bit rate mode : Variable
Bit rate : 2 024 Kbps
Width : 960 pixels
Height : 540 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.163
Stream size : 293 MiB (98%)

Audio
ID : 1
Format : WMA
Format version : Version 2
Codec ID : 161
Codec ID/Info : Windows Media Audio
Description of the codec : Windows Media Audio 9.2 - 32 kbps, 32 kHz, stereo 2-pass CBR
Duration : 20mn 14s
Bit rate mode : Constant
Bit rate : 32.0 Kbps
Channel(s) : 2 channels
Sampling rate : 32.0 KHz
Bit depth : 16 bits
Stream size : 4.63 MiB (2%)

[paradoxical]

Okay i thought it would :). I need something that permit me to play multiple H264 1080p vidz at the same time

If your system can't currently do it it means you need to upgrade it. My GPU can playback multiple 1080p videos just fine as I've previously told you when you brought this up. If yours can't then you've hit the limitations of your hardware's performance. "Using CUDA" is not going to mystically solve your problem.

[yok833]

Is there a real difference of picture quality between cuvid and hardware decoding? I m thinking about changing my ATI hd 6850 for a GTX 660 dc2...

[paradoxical]

Is there a real difference of picture quality between cuvid and hardware decoding? I m thinking about changing my ATI hd 6850 for a GTX 660 dc2...

CUVID is hardware decoding...

[STaRGaZeR]

Try with this instead?
http://files.1f0.de/lavf/LAVFilters-0.56-3-g84019e5.zip

I changed something that was not really intentional to be activated for multi-threaded codecs, and may have a negative impact on performance for them, actually.

This one seems to work fine, however perfomance has decreased even more, CPU usage is lower:

0.55.2 ----------- 210fps 75-80% No stuttering
0.56 ------------- 200fps 75-80% Stuttering
This test build ---- 170fps 60-65% No stuttering

[Reino]

And I don't know what FFDShow's PC.709-->Rec601 conversion is based on, but since ffmpeg can do PC.709-->Rec601 conversions now (-pix_fmt yuv420p -vf colormatrix=bt709:bt601), is it possible to integrate it into LAV Filters? LAV Filters is based on ffmpeg, right?

If Fraps encoded YV12 is always in the same matrix, i can also hardcode that value somewhere.Any update on this one?
FPS1(yuvj420p) is always Full-range Rec.709 and needs to be TV-range Rec.601. Is it possible to integrate ffmpeg's PC.709-->Rec601 conversion method into LAV Filters and apply it on FPS1(yuvj420p) files only?

[nevcairiel]

This one seems to work fine, however perfomance has decreased even more, CPU usage is lower:

0.55.2 ----------- 210fps 75-80% No stuttering
0.56 ------------- 200fps 75-80% Stuttering
This test build ---- 170fps 60-65% No stuttering

I can reproduce this with YADIF.

Can you confirm that without YADIF (pure decoding) the speed is the same between all the versions, if not slightly faster with 0.56?

I'm trying to figure out why YADIF is having performance issues now, my initial testing of course was with the 0.56 version, which did cause the smoothness issues you saw, but it should at least be at 0.55 levels with that turned off again, oh well, something to dig.
Wonder if maybe YADIF itself has suffered a bit of a slow-down recently, which was masked by aggressive multithreading, and if that slow-down was at a certain point, i would've tested my changes against that (after updating ffmpeg, before updating my code, and after updating my code, but same ffmpeg)

Also, here is another test, which seems smooth to me and restores a tiny bit of the performance at least:
http://files.1f0.de/lavf/LAVFilters-0.56-mtdecode-test.zip

If it works properly, it means i can also remove some complexity from the decoder (which may have improved performance in benchmarks, but in real world just caused jittery playback, apparently)
Still looking for the big performance difference, but not today anymore.

[Asmodian]

Any update on this one?
FPS1(yuvj420p) is always Full-range Rec.709 and needs to be TV-range Rec.601. Is it possible to integrate ffmpeg's PC.709-->Rec601 conversion method into LAV Filters and apply it on FPS1(yuvj420p) files only?

I might be missing something but why does FPS1(yuvj420p) need to be TV-range Rec.601, wouldn't TV-range Rec.709 be good? Rec.709 vs Rec.601 would be in the resolution, which I would hope is usually >=720p?

Either outputting RGB from LAV or letting LAV tell MadVR "this video is Full-range Rec.709" seems like the correct solution for fraps.

I have no plans to add code to change the YUV color matrix. Its not something a decoder should be doing.

[Aleksoid1978]

Hi nevcairiel

There is issue in LAV Video(DXVA native) + LAV Splitter + ATI on H.264 interlaced material. After seek - image corrupted, crumbles & twitches. Microsoft or Cyberlink decoder do not have this issue. MPC DXVA Decoder also have this bug.
If instead LAV Splitter select internal MPC MPEG splitter - LAV Video decode ok after seek.

I found the reason for this behavior - when use MPC MPEGSplitter in
HRESULT CLAVVideo::Receive(IMediaSample *pIn)
after seek triggered a check:

AM_MEDIA_TYPE *pmt = NULL;
if (SUCCEEDED(pIn->GetMediaType(&pmt)) && pmt) {
CMediaType mt = *pmt;
DeleteMediaType(pmt);
if (mt != m_pInput->CurrentMediaType() || !(m_dwDecodeFlags & LAV_VIDEO_DEC_FLAG_DVD)) {
DbgLog((LOG_TRACE, 10, L"::Receive(): Input sample contained media type, dynamic format change..."));
m_Decoder.EndOfStream();
hr = m_pInput->SetMediaType(&mt);
if (FAILED(hr)) {
DbgLog((LOG_ERROR, 10, L"::Receive(): Setting new media type failed..."));
return hr;
}
}
}

and you recreate decoder.

Recreate decoder avoids all these problems after seeking.

There is some short sample - http://aleksoid.voserver.net/Sample/H264/Interlace/

Screen:
http://s12.postimg.org/6nl2p8k5l/image.jpg (http://postimg.org/image/6nl2p8k5l/)

http://s22.postimg.org/53g25c2al/image.jpg (http://postimg.org/image/53g25c2al/)

[Aleksoid1978]

Another issue - LAV Splitter can't correct change different video track. The problem is that - after select new video track LAV Splitter do not send new media type to the decoder.

Here is a sample, that contain 2 video stream - AVC/MPEG2
http://aleksoid.voserver.net/Sample/Mix/AVC_MPEG_MIX.m2ts

[nevcairiel]

Another issue - LAV Splitter can't correct change different video track. The problem is that - after select new video track LAV Splitter do not send new media type to the decoder.

It actually does send a new media type, but there was a bug that caused its internal H264 parser to not be turned off, and parsing MPEG2 as H264 ... doesn't work so well.

It'll be fixed in the next version, thanks for reporting.

[Aleksoid1978]

It actually does send a new media type, but there was a bug that caused its internal H264 parser to not be turned off, and parsing MPEG2 as H264 ... doesn't work so well.

It'll be fixed in the next version, thanks for reporting.

Thanks :)

What you think about this bug

LAV Video(DXVA native) + LAV Splitter + ATI on H.264 interlaced material

[nevcairiel]

I don't have a ATI system right now, need to setup test system with my ATI card first to check.
But i would think that someone would've reported it before if it was a generic issue? Maybe driver related?

[Qaq]

I can't confirm any bugs with ATI, LAV/DXVA N and H.264 interlaced.
Aleksoid, what exactly you are talking about?

Nev, thanks for the new version. So far, so good.

[kerimcem]

my card ati3650 and mobillty ati 3450 lav dxva mode...both same..
are some of the green screen videos(wmv,vc1)
daum player dvxa mode+madvr no problem..works well....mpc,lav problem...
http://j1304.hizliresim.com/18/c/lzfg5.jpg

this bug? pot player(internal codec) dxva mode no problem works well...lav and mpc problem damaged :(

[nevcairiel]

this bug? pot player(internal codec) dxva mode no problem works well...lav and mpc problem damaged :(

I don't have such ancient ATI hardware, and no way to get any, so i don't really expect much progress here.

[Aleksoid1978]

I can't confirm any bugs with ATI, LAV/DXVA N and H.264 interlaced.
Aleksoid, what exactly you are talking about?


http://forum.doom9.org/showpost.php?p=1623766&postcount=14764http://forum.doom9.org/showpost.php?p=1623766&postcount=14764

it's bug present on different ATI card and different drivers.

[Snowknight26]

I can confirm that issue using one of the samples Aleksoid provided on a Radeon HD 6870.

[nevcairiel]

There is issue in LAV Video(DXVA native) + LAV Splitter + ATI on H.264 interlaced material. After seek - image corrupted, crumbles & twitches.
I can confirm that issue using one of the samples Aleksoid provided on a Radeon HD 6870.

Does this version help? I've not setup my ATI card yet, but maybe this already does it.
http://files.1f0.de/lavf/LAVFilters-0.56-9-g4cd6666.zip

[Konrad Klar]

From quite different barrel:
I have Geforce GTX 560. CUVID MPEG-4 does not decode properly XVIDs encoded with GMC, 2 Warppoints (not tested GMC, 1 Warppoint).
Would it be possible to make a compatibility check and fallback to software decoding in case of GMC MPEG-4 ASP?

[nevcairiel]

I have Geforce GTX 560. CUVID MPEG-4 does not decode properly XVIDs encoded with GMC, 2 Warppoints (not tested GMC, 1 Warppoint).
Would it be possible to make a compatibility check and fallback to software decoding in case of GMC MPEG-4 ASP?

Possible? Maybe, but mpeg4-asp is not a high priority, especially concerning GMC, which is extremely rare.
Personally i would simply advice to use software decoding for MPEG-4 ASP, but i'll put it on the list to add such a check. A sample file would help so i have something to check against.

[STaRGaZeR]

i can reproduce this with yadif.

Can you confirm that without yadif (pure decoding) the speed is the same between all the versions, if not slightly faster with 0.56?

I'm trying to figure out why yadif is having performance issues now, my initial testing of course was with the 0.56 version, which did cause the smoothness issues you saw, but it should at least be at 0.55 levels with that turned off again, oh well, something to dig.
Wonder if maybe yadif itself has suffered a bit of a slow-down recently, which was masked by aggressive multithreading, and if that slow-down was at a certain point, i would've tested my changes against that (after updating ffmpeg, before updating my code, and after updating my code, but same ffmpeg)

also, here is another test, which seems smooth to me and restores a tiny bit of the performance at least:
http://files.1f0.de/lavf/lavfilters-0.56-mtdecode-test.zip

if it works properly, it means i can also remove some complexity from the decoder (which may have improved performance in benchmarks, but in real world just caused jittery playback, apparently)
still looking for the big performance difference, but not today anymore.

Since the link is down I used the last build you posted, here are the results:

Pure software decoding:

0.55.2 --------------- 201fps
0.56 ----------------- 205fps
Previous test build ---- 205fps
This test build -------- 205fps

With software+yadif:

0.55.2 --------------- 210fps 75-80% No stuttering
0.56 ----------------- 200fps 75-80% Stuttering
Previous test build ---- 170fps 60-65% No stuttering
This test build -------- 185fps 65-70% No stuttering

Stuttering is fixed and perfomance is up a bit indeed, still not the same levels as before but at least it doesn't stutter. The question about the performance drop still remains though :D