resolution limit using Intel H264 Encoder

[roman-miniailov]

Using latest Intel H264 Encoder from Intel INDE (that now contains Intel Media SDK) for a some reason muxer do not work if resolution is 2560x1440 (but work on 1920x1080, looks like maximal resolution supported). With original muxer all ok.

Sample graph - https://yadi.sk/i/qtFtst99hCui7 , used file http://red.cachefly.net/TimeScapes4K2560p.mp4

[roman380]

What do you mean by "does not work" exactly? Error code, or produced file does not play back? The MP4 file above looks good for me.

I remember some fragment that fixes a sort if Intel Media SDK issue in source code (possibly I merged it wrong?).

There should be no resolution limit there. It is rather compatibility problem or memory allocator related.

[roman380]

Intel media SDK related workaround is related to AAC audio, so disregard this.

[roman-miniailov]

Yes, that's video related. I've tried AAC encoder from Monogram, works good.

I can see the following graph events after press start:

1 - [15:41:02] - EC_ERRORABORT (hr = 0x80040204) 2 - [15:40:27] - EC_CLOCK_CHANGED

So, I just press Start and it's stopped after a moment. That's all, I have no any ideas why that can happen.

[roman380]

OK, maybe I know what it is about. Indeed there is a limit of 1920x1088 resolution, but it's a limit of MS decoder [1, 2], not multiplexer.

If you try another decoder, would this be of any help?

Yeah, I tried it with a non-MS decoder and it looks good for me.

[roman-miniailov]

Yes, I've made debug version of filter, and use LAV Video Decoder to be sure about MS and resolution.

Screenshot - https://yadi.sk/i/3e5VyGLlhCwCb

[roman380]

FYI I used Release build and I successfully re-encoded this file using Intel Media H.264 SDK encoder and this multiplexer.

It does not mean it's flawless, but at least it does work sometimes.

There might be a problem with this assertion because Intel encoder outputs H264, not AVC1.

[roman380]

It looks like a problem with latest Geraint's update around ContigBuffer::AppendAndLock and Suballocator, which you don't see in version on http://gdcl.co.uk. Appending to contiguous buffer does not work as expected.

[roman-miniailov]

Could you update this issue on your side? (this repository).

I'm testing release version now, but tell results a little later.

Original filter have another issues and do not have new features, so, your version much better.

[roman380]

Can you try an update I just pushed? It does not fix the assertion by the way (it's a different thing), but it does fix 32-bit math overflow (around checking against 200 MB limit for buffers).

[roman-miniailov]

Sure, one moment

[roman-miniailov]

In one app all ok, in another I got E_OUTOFMEM exception during IMediaControl.Run using code but all in using GraphStudio. So, it's very strange, trying to find issues in code. Using MP4 muxer from Intel same code works. Need some time for this.

[roman-miniailov]

Right now I have this ASSERT happen often - ASSERT((LONG) cActual == pSample->GetActualDataLength()); (32449 == 32447, 12662 == 12660), and so on, always 2 bytes bigger.

[roman-miniailov]

Update - for big resolution just got E_OUTOFMEM somewhere, return by IMediaControl.Run, not this ASSERT.

[roman380]

I will fix the assert, but it is unrelated.

[roman380]

The likely reason for E_OUTOFMEMORY is that your application hits 2GB limit of virtual address space. With this version of multiplexer, this is even more likely because it allocates 200 MB of contiguous buffer. I suppose that Geraint wanted to reduce memory copying with this change, but in terms of memory utilization it does not look good.

I suppose your app is managed? You might want to try this out: Can I set LARGEADDRESSAWARE from within Visual Studio? to add some space for your app breathing...

[roman380]

All together:

• MS H.264 decoder has a limit of 1920x1088
• there was an overflow bug around buffer size calculation in 32-bit builds - fixed
• false assertions fixed (unrelated to bug)
• there is a fundamental problem with the code that multiplexer allocates a contiguous buffer which might be pretty large; without going into major code modifications it is worth to know that copy allocator can be eliminated if connection memory allocator has 20+ buffers, or otherwise a new method IMuxInputPin::SetMaximalCopyMemAllocatorCapacity is added to alter maximal buffer size which is 200 MB by default, and in my understanding 32-64 MB would work equally well in the same time creating way smaller memory pressure

[roman-miniailov]

My cSpace value is near 1.1 GB, new cSpace after cSpace = min((INT64) m_nMaximalCopyBufferCapacity, cSpace); is 64 MB, but still have this issue. Yes, managed code.

After LARGEADDRESSAWARE trick all looks ok on first run, but second time problem happens and app takes near 300MB again and again. Not sure, but looks like a memory leak happen.

[roman380]

It is by far normal (usual) behavior when it comes to mix of native and managed code, 32-bit process, and high memory consumption. .NET garbage collector is freeing memory and resources slower than you want, and allocation of large piece of memory tends to fail earlier in conditions of memory fragmentation.

Basically I am not sure that this idea to use contiguous buffer is perfect, but it is merged in and is basically not the only cause of the problem here.

I would suggest that you make sure that you release the multiplexer once you don't need it, without waiting for GC to do the job. Use of 64-bit builds is of course a reliable solution for the problem, but it might be not available for multitude of other reasons.

[roman-miniailov]

Yes, thank you! You've made a great job, I agreed that this issues is managed-code related. Amazing job!