DGMVCSource

[frencher]

Why two DLLs? I checked dependencies and it seems only libmfxsw32.dll is needed. What other one are you talking about?

I tried to load it directly from a path of my choosing but it failed unaccountably. The error was file not found but it is definitely there. Rather than get bogged down in this, let's move on and possibly revisit it, as you suggest.

Frim Decoder (http://forum.doom9.org/showthread.php?t=169651) work without Windows system path and without instel SDK instaled.
libmfxsw32.dll is in same folder of Frim path and works correctly :o
Contact videofan3d for help if possible :p
Thanks for work neuron2 ;)

[Guest]

Pay attention, frencher! I already solved all that on my own, and as I have said several times, I don't anticipate needing any help.

[Sharc]

I always add "AssumeFPS()" as the last line in the file when I know the source framerate.
Good practice, yes.

[Guest]

I completed my standalone DGMVCCombine implementing the muxing previously described. The combined files work fine with DGMVCSource(). Later today I will post the DGMVCCombine for you to test, and when it is verified I will integrate it into DGMVCSource(). Right now, I have to sleep for a while.

[Sharc]

Take a healthy rest!

[WBL]

Hello Donald,

tried your beta3 which can load the included MVC example, but when tying to load a MVC file created by the Panasonic Z10000 3D Camcorder or JVC TD1 one gets only garbage.

greetings
Werner

[videofan3d]

Hello Donald,

tried your beta3 which can load the included MVC example, but when tying to load a MVC file created by the Panasonic Z10000 3D Camcorder or JVC TD1 one gets only garbage.

greetings
Werner

Did you demux those Panny files to elementary streams (using e.g. eac3to) and merged base (_L.h264) and dependent view (_R.h264) to combined stream using MVCCombine first ?
Then it should work...

[r0lZ]

I don't know the format of your file, but it is probably not a "combined AVC+MVC" stream in the correct format. You should try to demux the two video streams, and combine them with MVCCombine.exe (http://forum.doom9.org/showthread.php?p=1628058&highlight=MVCCombine#post1628058) or, when it will be available, with DGMVCCombine.
[EDIT: videofan3d has posted his reply when I was writing mine.]

@Neuron2:
Just finished testing your latest beta. AFAIK, it works perfectly, and the problem of the directory containing libmfxsw32.dll seems to be fixed. I appreciate also the red message when the intel DLL cannot be loaded. Perfect! :-)
:thanks:

[WBL]

Well does it really make sense to first demux an original MVC file, then combine them again to one new MVC file just be be able to load them with AviSynth?
My goal is to be able to load original 3D MVC files from different 3D camcorders to be able to do a stereoscopic deshaking - this should be possible with the aid of a AVS file - without demixing and joining them again - what if you need to do this with 100 or even 1000 files?

greetings
Werner

[videofan3d]

Well does it really make sense to first demux an original MVC file, then combine them again to one new MVC file just be be able to load them with AviSynth?
My goal is to be able to load original 3D MVC files from different 3D camcorders to be able to do a stereoscopic deshaking - this should be possible with the aid of a AVS file - without demixing and joining them again - what if you need to do this with 100 or even 1000 files?

greetings
Werner

Obviously yes :-)
But it is more complicated structured task.... maybe sometime in the future somebody will white such great plugin to Avisynth :) ;)

[r0lZ]

@WBL:
It's a problem, I agree, but it is due to the intel decoder, that accepts only the AVC+MVC combined stream in a very specific format. If you re-read this thread, you'll see that DGMVCDecode is the first step to solve that problem, and Donald should release it soon. When it will be carefully tested (by us, and why not by you), Donald will integrate it in his DGMVCSource filter, and at that time, hopefully, you'll be able to load the elementary streams directly. It will still be necessary to demux them, but not to combine them. Later, perhaps there will be a solution to load directly a MPLS or SSIF file from a 3D BD. And perhaps that will work with your files too.
[EDIT: Again, videofan3d was faster than me.]

[WBL]

Obviously yes :-)
really? So even if the new joined MVC cannot be loaded by any 3D capable NLE or even with StereoscopicPlayer which uses the CoreCodec MVC decoder? I dont see the benefit of such an intermediate file format epecially if one cannot relaod it with other software which can do decode original MVC files from 3D camcorders...

greetings
Werner

[WBL]

When it will be carefully tested (by us, and why not by you)
I could do such tests - thats no problem

I see this is a 'problem' of the intel decoder

greetings
Werner

[videofan3d]

really? So even if the new joined MVC cannot be loaded by any 3D capable NLE or even with StereoscopicPlayer which uses the CoreCodec MVC decoder? I dont see the benefit of such an intermediate file format epecially if one cannot relaod it with other software which can do decode original MVC files from 3D camcorders...

greetings
Werner

I meant :) : it would be great if we would have plugin to Avisynth which could load MVC from Panny directly, but at this moment we don't have it - so we have to be patient until somebody smart will write it. :-)
So far we have to work in steps:
- demux MVC to L, R, audio
- process separately
- multiplex back to MVC (thanks to tsMuxer 3D we finally can do it!)

@Werner,
I'm also owner of Panny Z10000 (and I'm using some workflow, which is not simple, but working)
If you are interested, we can discuss about processing in some separate thread, or offline.
(as this thread is for Avisynth MVCSource() specifically)

Frank

[jdobbs]

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

[Sharc]

Any chance DGMVCSource() will evolve at some point so that it will read SSIF files directly?
It's on Donald's to-do list. (http://forum.doom9.org/showpost.php?p=1662589&postcount=152) ;)

[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 :p, 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]

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 :p, 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]

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.

[Nico8583]

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

[Guest]

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]

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]

Next step (when separated stream will be OK) : HW acceleration ? :) Seems logical to me.

[Nico8583]

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]

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 :p, 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]

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. :p

// 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]

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

[r0lZ]

Hum, really strange. I have demuxed again the first part of the movie, and I've tried to encode it, but this time, I have had no problem. I don't know what's happening. I will do some additional tests, and try to understand why it doesn't encode always correctly. It might not be a bug in DGMVCSource. Sorry for the (probably) false alarm.

[EDIT:]
Sorry again. That was really a false alarm. I have re-encoded the original files again, with exactly the same avs script and encoding parameters, and the problem is not present any more! I don't know how it's possible. Cosmic rays? Bad vibrations? ;-) Anyway, forget my previous message.

[Thalyn]

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.
While it's not impossible that there's still a mismatch, it's made up of only a single SSIF file. It can't be made up of any more - there's only one on the disc!

On the subject of The Blue Umbrella, it could be like I used to experience with CoreAVC-based decoders before. For no apparent reason some transcodes would just kick back glitches, while running them a second time produced normal results. I didn't understand the "why" of it then, and it still makes no sense now; I just accepted that sometimes it would happen (until I hit The Croods, where it had the same error each and every time).

[r0lZ]

I have just encoded Paperman, and there is again an error. I am currently re-encoding it again, just to see if the problem can be reproduced or not. But that erratic errors are very strange. I have never noticed that before.

[EDIT] Yep, same strange thing. A second encode of exactly the same thing with the same parameters went OK! Damn, that's very strange, and annoying! How can we be sure that the encode is good without having to watch it entirely?

Now, to return to the subject of this thread, the question is: is it avisynth, the Source filter or the encoder that is responsible of the problem? I have noticed that the two views are affected, not only the MVC (or right) view. That seems to incriminate the encoder (or perhaps the avisynth commands after the decoding step) rather than the decoder. But how to be sure?

[Guest]

Guys, top priority is for me to get me some streams that show the issue. I will see if Best Buy has any of the blurays you've mentioned. Anything you can give me too will be useful.

Do these errors occur when you just play the script and don't transcode? And does this happen only for separate stream input? If so, it pretty clearly implicates DGMVCSource.

I'll also do some testing on my reader/writer between the combiner and the decoder to make sure it is not underflowing.

[Thalyn]

Checked with VirtualDub 1.10.4, no transcoding in progress - the error circa frame 1800 is showing up when using separate streams. It's definitely consistent, though I can't say with absolute certainty as to whether it's the same every time.

There's a couple additional hic-ups starting from around frame 6700, and then the MVC view goes absolutely haywire at around 7800 - still recognisable as the movie, but definitely not right both in appearance and sync to the AVC stream (it appears to occasionally get 1 frame ahead). Unfortunately I don't seem to be able to preview it at exactly realtime, or even a consistent framerate (thus making watching it slow and nauseating), but watching to frame 13,000 the MVC stream is still wonky so it wouldn't surprise me if the rest of the movie continued the same. I'll run a full transcode tonight (with an appropriate filename!) to check so I can playback faster and let you know tomorrow what I find out.

[r0lZ]

I can do some additional tests, but it's not easy, as often, the whole movie is correctly re-encoded. And watching it playing in AVSpMod without re-encoding it takes a lot of time.
Do not buy one of my examples. I can't confirm that the problems I got are really coming from your plugin. It can come from my computer too. I have to reboot it and redo the tests to be sure. I'll try to do that this evening or tomorrow...

[Nico8583]

Have you tried with pistacho plugin or videofan3d plugin ? It's to determine if its cause this problem too

[Guest]

I need to have at least one so I will buy one. Have you ever seen the problem with a combined stream? That's important for me to know.

I will first increase my buffer sizes as they may be too small. I will then run a full bluray and see if anything unexpected happens with the reader/writer. I may also make a debug build for you but first let me do some investigation here.

[r0lZ]

No, I haven't tried with other decoders recently, but currently, I am doing tests with short movies I have already encoded in the past without problem. And I have never noticed a similar problem when I decode the combined stream, but I have only tested that method 2 or 3 times with DGMVCDecode, and that was with older versions. It's not enough to be sure. I will try that right now...

[Guest]

OK, thanks for your testing. I understand that it is time consuming. Right now I am thinking my buffer for the combined stream is too small. More later...