DGMVCSource

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

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

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

[Thalyn]

"Escape from Planet Earth" for Region B - ID R-113745-8. It's not a bad watch, either, if you don't mind light-hearted, more kid-oriented movies like The Croods or Wreck it Ralph.

[Guest]

Do you happen to have a link for that at Amazon or somewhere? It has to be the same one you have.

[Thalyn]

I'm probably one of the few people left who doesn't like to shop online unless I have to. A part of it being the excruciatingly high cost of delivery to Australia, but I mostly like the prospect of browsing the shelves and discussing things with the sales staff.

http://www.ezydvd.com.au/blu-ray/escape-from-planet-earth-blu-ray-3d-blu-ray-ultraviolet/dp/6141878 is the only link I can easily find, but you can get an idea of what postage to Aus is normally like given that it's cheaper for me to buy that locally than to import!

http://www.blu-ray.com/movies/Escape-from-Planet-Earth-3D-Blu-ray/76585/ is the disc, but I don't know how much help that will be since it doesn't seem to list an availability.

*ed: Yep, it was half the size because it was only half the movie. I gave it 128348 for the "frames" variable and the over/under output only had 64,174 frames in it - but that would have been from 128,348 source frames if you considered that the AVC and MVC were playing sequentially(view = 0). It's not a major issue since it can be worked around but it doesn't appear to be mentioned in the documentation.

[r0lZ]

IMO, the number of frames should be the number of frames in the movie (or in one video stream) and not the total number of frames for both eyes. That seems more logical, and it's how pistacho's filter works.

[Thalyn]

That's how I assumed it worked but, as I said, it's a relatively minor issue given how easy it is to work around. More concerning is that all my efforts to use the two separate elementary streams (at least with Escape) have come back problematic - to the point where I must have been looking at the wrong file when I mentioned that it appeared to work fine. Unfortunately I run most of my transcodes overnight because of how long they can take, so I must have confused which output was what. I really need better naming conventions for test purposes.

In fact, my last few test-runs been getting errors as early as frame 760 and stop giving any video at frame 791. Inconsistency is a pain in the proverbials for troubleshooting...

*ed: Curiously, doesn't the Intel Media system have built-in support for separate AVC/MVC elementary streams? The FRIM documentation (sadly my programming knowledge doesn't extend recently enough to read the actual SDK) lists that as a feature, and I was able to get correct results out of FRIMSource, so unless Videofan3D added a combiner himself than it has to be in there somewhere.

Interestingly enough, FRIMSource also has the same framecount issue.

[r0lZ]

Is it a multi-angle movie (with several SSIF files referenced by the MPLS)? If it's the case, perhaps you have a problem I have already encountered, and not directly related to the decoder. It seems that in some rare cases, the AVC and MVC streams do not have exactly the same number of frames, and there is one additional frame in one stream. When the movie is made on a single SSIF, that doesn't matter, as only the last frame is affected. But when the movie is made of several SSIFs and the problem occurs, say, in the first one, that means that all subsequent frames are desynchronised, and the MVC decoder tries to decode the frames based on wrong AVC frames.
IMO, the only way to fix that problem is during the demux phase. The additional frames should be truncated.

[r0lZ]

Funny, I have just finished a test encode with b5, and I have a problem, but I'm not sure it is identical to yours, Thalyn.
The movie is "The Blue Umbrella", a short Pixar movie found on the "Monsters University" BD.
The problem happens exactly after the Disney and Pixar logos, when the first frame of the movie itself is shown. There is one GOP of garbage, badly decoded.
The rest of the movie seems to be perfect.
I will try to cut that part for you to test, Neuron2...