Doom9's Forum - View Single Post

ipanema · 23rd November 2009, 18:49

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, 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.