[RESOLVED] Half Image Corruption

[squallmx]

I getting a corrupted image when using DGIndexNV as decoder, it only affects the first second (¿GOP?) and only the top half, the internal DGIndexNV preview looks fine, but the resulting AVS script is affected on VirtualDub, MeGUI, and MPC:




The affected streams are from the X-Men: First Class Blu-ray, others decoders works fine.

I'm using a nVidia GeForce 540M Card, and no filters.

Sample:
http://www.fileserve.com/file/eQps7ZB/00886.m2ts

Thanks.

[admin]

That's a good one! Thanks for bringing it to my attention.

The stream has a packet boundary within the start code for the first IDR frame (and more like that elsewhere in the file):

... 00 00
[packet boundary]
01 65 88 ...

My indexer does not handle this correctly [causing me to miss the first slice of the IDR when locating to that IDR in DGSource()]. You can prove it by editing the DGI file to change the first IDR line to 958 instead of 966. Then open the AVS and it will be fine.

You can also prove it is the packetizing by demuxing to ES and then making a project out of it. That too will be fine.

I have to fix the handling for this case. It may take a few days.

[squallmx]

Thanks for your answer, i will be waiting patiently for the update version. Meanwhile I will use the workaround.

[admin]

At first I thought this case totally refuted my nested parsing architecture and I couldn't see what to do without redesigning a lot of code. I had a bad night's sleep over it. But while soaking in the bathtub this morning I conceived a fix that saves things. I now have it working in my local build. The fix is this: If a start code ends within 2 bytes of the start of the packet payload, then the start code must be split between packets. In that case adjust the index location backwards by the size of that packet's transport overhead. It's a bit fiddly but it preserves my high-performance parsing architecture.

Before making a release I need to do some regression testing and I want to add configurable CUDA versus CUVID for each video type.

BTW I have just installed a secondary GT 520 and find that it decodes 1080P at around 170 fps, consistent with other's findings. So the GT 520 displaces the 240 as the best bang for the buck solution. At that speed, the GPU decoding is unlikely to be a bottleneck for a transcoding process.

Look for a new release this weekend.

[laserfan]

BTW I have just installed a secondary GT 520 and find that it decodes 1080P at around 170 fps, consistent with other's findings.

If you don't mind telling, which card did you buy?

Congrats on the fix, and here's to a good night's sleep tonight!

[admin]

All I remember right now was it is an EVGA 2GB card. I'll give you the exact model when I get home.

[admin]

Actually it's a Galaxy GT520 w/2GB DDR3.

[admin]

Version 2041 with the fix has been released.

[laserfan]

Actually it's a Galaxy GT520 w/2GB DDR3.

Thanks for your reply!