DGMVCSource

[Guest]

This is something that could be fun to work on. But does Intel Media SDK require Haswell with QuickSync and all that? I have only i7 980X Gulftown at this time.

If I made it I would release under suitable re-usable license, not like DGDecNV.

Seems now it requires also Win7 which makes thing difficult for me at this time. Maybe it's time for me to get into the current century.

EDIT: The current DGMVCSource version will always be linked here:

http://neuron2.net/mine.html

[jdobbs]

Any chance DGMVCSource() will evolve at some point so that it will read SSIF files directly?

[Sharc]

Originally Posted by jdobbs

Any chance DGMVCSource() will evolve at some point so that it will read SSIF files directly?

It's on Donald's to-do list.

[Guest]

I have completed the initial separate stream support. There is a small bug in that the final frame is corrupted. I am fixing that. In the meantime, can you please test this with your separated base/dependent streams and report any failures. The ZIP also now includes the separated streams corresponding to combined.264. I have tested successfully with these files only.

My combiner is rather elegant (only 160 lines of code), if I may say so , as you will see when I release the source code. But I may not yet have covered all the NALU handling rules that your files may require. So feedback will be appreciated. Thank you.

http://neuron2.net/misc/dgmvcsource_b4.zip

The syntax for specifying streams was modeled on pistacho's syntax. Hat tip to pistacho.

[Nico8583]

Originally Posted by neuron2

I have completed the initial separate stream support. There is a small bug in that the final frame is corrupted. I am fixing that. In the meantime, can you please test this with your separated base/dependent streams and report any failures. The ZIP also now includes the separated streams corresponding to combined.264. I have tested successfully with these files only.

My combiner is rather elegant (only 160 lines of code), if I may say so , as you will see when I release the source code. But I may not yet have covered all the NALU handling rules that your files may require. So feedback will be appreciated. Thank you.

http://neuron2.net/misc/dgmvcsource_b4.zip

I have made a first test, it works very well for me
Thanks Donald !!

Edit : how can I test for NALU handling rules not covered ?

[Guest]

Originally Posted by Nico8583

I have made a first test, it works very well for me.

Great. Thanks for your testing.

Edit : how can I test for NALU handling rules not covered ?

Basically just test different source files. I pass along only a subset of NALU types to the decoder:

9
7/15
8
6
5/1/20

I don't know if there are any cases where I should pass along any other NALU types that may be in the source streams.

[Sharc]

Originally Posted by neuron2

I have completed the initial separate stream support. There is a small bug in that the final frame is corrupted. I am fixing that. In the meantime, can you please test this with your separated base/dependent streams and report any failures. The ZIP also now includes the separated streams corresponding to combined.264. I have tested successfully with these files only.

My combiner is rather elegant (only 160 lines of code), if I may say so , as you will see when I release the source code. But I may not yet have covered all the NALU handling rules that your files may require. So feedback will be appreciated. Thank you.

http://neuron2.net/misc/dgmvcsource_b4.zip

The syntax for specifying streams was modeled on pistacho's syntax. Hat tip to pistacho.

I did few tests with large separated base/dependent files. No issues so far. However i truncated all my tests at about 1000 frames. Does this matter for NALU handling verification?

P.S.
Reported framerate is correct now for all views, thanks.

[Guest]

Originally Posted by Sharc

I did few tests with large separated base/dependent files. No issues so far. However i truncated all my tests at about 1000 frames. Does this matter for NALU handling verification?

P.S.
Reported framerate is correct now for all views, thanks.

Your truncated tests are fine. Thanks.

Glad you noticed the fps fix.

[Guest]

Here is beta 5. It fixes the EOF problem in the separate stream mode. All the required functionality is now in place. (I don't see the point of Frank's frame caching as that is already provided free by Avisynth. Am I missing something?)

http://neuron2.net/misc/dgmvcsource_b5.zip

On to HW acceleration, unless anyone finds issues. If there are no issues I will make a source code release.

[Nico8583]

What should be the result if NALU doesn't exist ? Black screen ? Artifact ? No dependent view ?

[Guest]

Originally Posted by Nico8583

What should be the result if NALU doesn't exist ? Black screen ? Artifact ? No dependent view ?

I don't anticipate any such problems, but I don't have perfect knowledge of all files in the wild and so can't fully discount the possibility. As and if they are reported, additional handling can be added. Just report any unexpected behavior and I'll try to fix it.

[Nico8583]

Originally Posted by neuron2

I don't anticipate any such problems, but I don't have perfect knowledge of all files in the wild and so can't fully discount the possibility. As and if they are reported, additional handling can be added. Just report any unexpected behavior and I'll try to fix it.

OK, I'll try several movies and I'll report to you if I see any problem
Next step (when separated stream will be OK) : HW acceleration ?

[Guest]

Originally Posted by Nico8583

Next step (when separated stream will be OK) : HW acceleration ?

Seems logical to me.

[Nico8583]

Originally Posted by neuron2

Seems logical to me.

Very good, I'll receive my new notebook tomorrow, it owns an Intel CPU i5-4200U and Intel HD 4400 so I'll do some test

[jdobbs]

Works great in my tests... I've done several files with no issues.

[Thalyn]

Everything seems fine. Using "Escape from Planet Earth" as my source material (a title I know has issues with some older decoder implementations) I was able to parse both a separate and combined stream test encode with no problem. Even the SAR issue I was experiencing with cropping (something I was about to bring to your attention!) has been fixed in B5.

Interestingly, the output is actually a lot smaller than what I'd gotten previously on the same title using SSIFSource/CoreAVCCodec (which suggests it had minor errors that weren't visible, resulting in worse compression but no obvious problem in playback). In fact, using identical x264 settings it went from a 2.25GB video stream to just 1.09GB. If that persists across multiple titles it could mean full OU encodes are in my future instead of half.

[Guest]

Thanks for the thorough test. I'm doubtful that over a GB reduction is due to correction of minor errors. I'd guess you must have had some other variable involved or actually had different settings.

[Guest]

I wanted to show you my elegant combiner. Calling only two simple functions, the following code implements a sort of combiner language and constitutes the NALU handling I was talking about. Its output feeds a circular buffer for the decoder (a well-known reader-writer implementation). Well, I think it's cool.

	// Loop through the access units in the source streams, combine them, and
	// write them to the output combined stream buffer.
	while (1)
	{
		status = get_next_au(base_buffer, base_fp);
		status |= get_next_au(dependent_buffer, dependent_fp);
		write_all(base_buffer, 9);
		write_all(base_buffer, 7);
		write_all(dependent_buffer, 15);
		write_all(base_buffer, 8);
		write_all(dependent_buffer, 8);
		write_all(base_buffer, 6);
		write_all(base_buffer, 5);
		write_all(base_buffer, 1);
		write_all(dependent_buffer, 6);
		write_all(dependent_buffer, 20);
		if (status == 1)
			break;
	}

The function write_all() does this: From the current access unit in the specified base/dependent stream buffer, copy all the NALUs contained in the access unit having the specified NALU type to the output combined stream buffer. It blocks if the buffer is full and is resumed by the reader when data is removed.

[Thalyn]

Seems I may have spoken too soon. :/

Around frame 1860 there's a pretty nasty glitch when using separate streams as input. It's persistent in both B4 and B5. I'm honestly not quite sure how I didn't spot it before (I must have skipped over it) but I think I may have been too fixated on that SAR problem (which is seemingly of my own doing, despite not having actually changed anything, since now it's gone on older versions). Using the MVCCombine output file (same input streams) shows no problem. Sorry!

I'd try to upload demonstration streams somewhere but my connection is not exactly suitable for that sort of thing at the moment. I'm having issues with data corruption on my downloads so I can only assume uploading is equally unreliable - it'd be impossible to tell what was the merging and what was my connection causing the problem.

I'm going to also have to check something else regarding the frame count, too. It could explain why the output file was so small. I have a suspicion it's only outputting half the frames I'm giving it for the command line, which somewhat makes sense because of the interleaving. Unfortunately that will take full transcodes to test and they're running at about 16fps, so I won't know for certain for at least an hour.

[Guest]

Originally Posted by Thalyn

Around frame 1860 there's a pretty nasty glitch when using separate streams as input.

What bluray is it? I can buy it.