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

[r0lZ]

Thanks for your help. I don't know the exact requirements, but Win7 is probably one, yes. Are you still under XP only?
I don't think the Intel decoder requires special hardware. It can run with hardware optimisation on specific Intel hardware, but it should run without problem on any CPU.

[Guest]

Are you still under XP only?
Sadly, yes. I was planning to upgrade OS at my next hardware upgrade. May be time to accelerate that. It's not so easy to upgrade existing systems, as I'm sure you know.

[Nico8583]

Thanks a lot neuron2 to consider our demand :)
I accept your help but I have never made Visual Studio 2010 project or Avisynth project, so I'm a beginner :D

[Nico8583]

Sadly, yes. I was planning to upgrade OS at my next hardware upgrade. May be time to accelerate that. It's not so easy to upgrade existing systems, as I'm sure you know.
Perhaps could you make a VM with VMWare Player ? :confused:
It's what I do when I need :)

[frencher]

Very good idea Nico8583 ;)
Same Thanks slavanap, neuron2 and all to try to help us !

[Guest]

Started shopping for my new system. :sly:

It will enable me to consider this project and also QuickSync support for DG tools.

[r0lZ]

Started shopping for my new system. :sly:

It will enable me to consider this project and also QuickSync support for DG tools.Excellent news, Neuron2! I wish you all the best with your new system. :-)

[Nico8583]

Excellent news, Neuron2! I wish you all the best with your new system. :-)

Very good, thanks a lot !

[Guest]

Order placed; delivery on Thursday. :p

[frencher]

Very nice news :D

[Nico8583]

Order placed; delivery on Thursday. :p
So we can hope a plugin for sunday ? :D
It's a joke of course ;) I hope your new hardware will give you all satisfactions

[Sparktank]

QuickSync support for DG tools.

Order placed; delivery on Thursday. :p

:'( I'm going to love 2014.

:goodpost:

[Guest]

I will do my best not to disappoint you. ;)

That one (QuickSync for DGDecNV) will be licensed like DGDecNV, however, while an MVC source filter will be fully open. Don't hate me.

[Wilbert]

If I made it I would release under suitable re-usable license, not like DGDecNV.
Changed your mind? Pity.

[Guest]

The MVC source filter will be open. QuickSync for DGDecNV not. I hope it is clear and I edited my post to clarify.

[Sharc]

I will do my best not to disappoint you. ;)

That one (QuickSync for DGDecNV) will be licensed like DGDecNV, however, while an MVC source filter will be fully open. Don't hate me.

Really good news. Thank you in anticipation :)

[r0lZ]

Yes. Thanks again!

[Guest]

While I wait for delivery can anyone point me to, or place here, a concise and complete specification for what the source filter must do? I confess to having little experience in the area of MVC, although obviously I have a lot of experience creating source filters.

[r0lZ]

I have tried to describe what the current MVCSource plugin does here (http://forum.doom9.org/showthread.php?p=1659623#post1659623).

To summarize, the decoder should ideally be able to take the two demuxed video streams as input (AVC and MVC), and output a single interleaved stream with one frame from one stream followed by one frame from the other stream, and so on. The order of the images (AVC in odd and MVC in even frames or vice versa) must be controlled by a parameter. (Alternative outputs such as side by side or top & bottom combined frames can be considered if you wish, but since avisynth has the possibilities to build them from the interleaved stream, it's not necessary.)

As far as I know, the Intel example CLI command requires a single "combined" AVC+MVC video stream as input. I don't now if the library has the same limitation, but I suppose not, since the current MVCSource plugin can accept the 2 streams. (It can also accept a combined AVC+MVC single stream, but, unless it's easy to do, I don't think it's an useful feature.)

The current plugin can also decode and output the AVC stream only (but it is easy to decode it with other Source commands), or the MVC stream only (more useful, but not really necessary). It can also enable the hardware acceleration feature of the Intel library, but I suppose that that part can be added later, and I'm not sure it is really useful, as I don't know if the required hardware is frequent.

There is currently no audio support in MVCSource, and I don't think we need it.

Of course, it would be nice if the plugin could also accept a MPLS (or SSIF) file as input, but that requires probably some kind of demuxer, and I suppose it's a difficult and long work.

Another feature that is currently missing and that could be a very great improvement is some kind of seek support. Currently, all frames must be decoded sequentially. Not a big deal.

[Guest]

Thank you, r0lZ, that is very helpful. And the job doesn't sound too difficult.

Of course, it would be nice if the plugin could also accept a MPLS (or SSIF) file as input, but that requires probably some kind of demuxer, and I suppose it's a difficult and long work. Not at all, I already have written an MPLS parser. However, can you please tell me what an SSIF file is? Thank you.

[r0lZ]

In 2D blu-ray discs, the MPLS references one or several M2TS files. For compatibility reasons, the same thing is true for 3D BDs. But a 3D player "knows" that it must replace the M2TS file(s) (from the BDMV/STREAM directory) with the file(s) with the same base name(s) but with the extension .ssif, from the BDMV/STREAM/SSIF directory. Only the 3D movies have one (or several) SSIF files in that directory. So, for example, 00001.mpls can reference, say, 00010.m2ts, and a 2D-only player will read that M2TS, but a 3D player will read 00010.ssif instead.

The 3D files are in fact made of 2 MPLS files for each "part". (In my previous example, the 2 mpls files can be 00010.m2ts and 00011.m2ts.) The first M2TS contains the AVC video stream and the audio and subtitle streams, exactly like on a 2D BD. The second M2TS contain usually only the MVC stream (but it can also contain subtitle streams, for a reason that I have never understood), and of course, it cannot be decoded by a 2D player, or without the AVC stream from the other file. That second M2TS file is ignored by the 2D players, and is not used when the 3D movie is watched in 2D on a 3D player.

The SSIF file contains the two M2TS files interleaved at the file system level. In other words, the data on disc contained in the SSIF file is the data of the two M2TS file, arranged in such a way that it is possible to read the two files without having to seek continually to different places on the disc. The SSIF file is therefore used when the 3D player must play the movie in 3D, and provides a fast access to the 2 M2TS files.

I don't know how your MPLS parser works, but of course, to decode a 3D movie, it must be able to read the corresponding SSIF file instead of the M2TS, to retrieve also the MVC stream. Or, if you prefer, it should read the two M2TS files at the same time, but I don't know if the second M2TS file is explicitly referenced in the MPLS. Anyway, if it is referenced, it's not in the normal way, as it must not be visible to the 2D-only players.

Sorry if I can't be more technical and explain exactly the differences in the MPLS file format. I have only written a GUI using other tools, and the decoding part is not my speciality. :rolleyes:

[Guest]

Thanks, it's starting to come together coherently in my aging brain.

[Nico8583]

Thanks r0lZ for all your explanation :)

Here are some informations about Intel Media SDK (from Intel website or Intel forum) :
- Download Intel Media SDK (http://software.intel.com/en-us/vcsource/tools/media-sdk)
- Download Intel Media SDK tutorial (http://software.intel.com/en-us/articles/intel-media-sdk-tutorial)

Informations about mvc_dec_filter.dll (a DirectShow sample MVC decoder include in Intel Media SDK and open source) :
You should be able to use regular File Source Async Filter to read an MP4 MVC file, then connect it to Intel Media SDK MP4 splitter Filter and further to MVC Decoder Filter.

For rendering you need to use a custom EVR rendering approach as illustrated in the "custom_evr_presenter" sample.

Keep in mind that the Media SDK DirectShow samples are just sample code and may not fit all use cases. You may have to adapt the code to your needs. The binary splitters and muxers provided with the SDK are not fully capable so you may want to explore commercial or community supported split/mux components instead.

Informations about color space and output :
Media SDK decoder only supports output to NV12 format (exception is the JPEG decoder which also supports direct RGB32 output). You can use Media SDK VPP to convert from NV12 to RGB32. If you need other color space format then you will have to use external color space conversion routine.

The Media SDK package includes several DirectShow source code samples.

Media SDK (Windows) samples are supplied with solution/project files for Microsoft Visual Studio.

Thanks !

[Guest]

Nice, thank you.

I already have fast code to convert NV12 that I can take from DGDecNV. IIRC, it's described in the development log at my website.

[Wilbert]

The MVC source filter will be open. QuickSync for DGDecNV not. I hope it is clear and I edited my post to clarify.
I misread your post, sorry. Btw, just curious. What is QuickSync?

[Guest]

"Intel Quick Sync Video is Intel's hardware video encoding and decoding technology, which is integrated into some Intel CPUs."

http://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

It would obviate the need for a supported nVidia graphics adapter for DG tools.

[Guest]

Bringing up my new machine now...

Oy, Windows 8! Gnyah. Gonna take me a little while to make it usable, create recovery disks, then update to 8.1, and then finally get going on development.

Any recommendations for Windows 7-like shell, etc.? I grant myself this little OT as it will facilitate our goal here. :D

EDIT: For the curious, this is the first PC I have not built myself. It is an ASUS M51AC-US004S. Not bad for $870. The only sucky thing is the keyboard letters are in light gray -- almost invisible! It's OK I have a spare illuminated keyboard in the closet.

[r0lZ]

I use Classic Shell (http://www.classicshell.net/) to bring the start menu back in Win8, and to boot directly in desktop mode. It is very good and stable, and highly customizable. It has also other features that I have not enabled.
Thanks to Classic Shell, I have almost totally forgiven the start screen and the M$ apps. They are useless anyway.

[Guest]

:thanks:

Did you update to 8.1?

[Nico8583]

With Windows 8 or 8.1, you must think to use Windows key on your keyboard and shortcuts, like Windows + X to access a menu with main functionnalities, Windows + R to run a command, etc...

Like r0lZ, I use a little soft to add start menu, it's Start8. There are several others softs like that ;)

Windows 8.1 add a very "useless" button, with it you can switch between Modern UI and desktop, and you boot directly to desktop :)

[r0lZ]

:thanks:

Did you update to 8.1?
No, not yet. But I think 8.1 is slightly better than 8.0.

[Asmodian]

Windows 8.1 add a very "useless" button, with it you can switch between Modern UI and desktop, and you boot directly to desktop :)

I actually like that new "start" button from Win 8.1. It has a nice list of options if you right-click it. :)

I too believe 8.1 to be a welcome if minor upgrade from 8.0.

[Guest]

Thanks guys. I've installed Classic Shell as it lets me pretend I still have WinXP. :D

I won't bother with Win 8.1.

What do I need to build Intel Media SDK? I have MS Visual Studio 2005 Pro. Will that suffice?

[Asmodian]

Once on 8.0 I don't understand why you wouldn't want 8.1?

Auto login to desktop is worth it by itself.

Sorry, I guess this is a bit off topic. :o

[Guest]

Once on 8.0 I don't understand why you wouldn't want 8.1?

Auto login to desktop is worth it by itself.

Sorry, I guess this is a bit off topic. :o It's OK, I didn't see anything. ;)

And on another matter I already get boot to desktop from Classic Shell. I may upgrade at some point but I am itching to get the project going, as Nico8583 has set a Sunday deadline. :)

[Nico8583]

It's OK, I didn't see anything. ;)

And on another matter I already get boot to desktop from Classic Shell. I may upgrade at some point but I am itching to get the project going, as Nico8583 has set a Sunday deadline. :)
Tic tac tic tac, time goes by :D

When I have tried to compile, I have used Visual Studio 2010 but I think 2005 and 2008 works also because when you open a Intel Media SDK project to VS 2010, it asks you to convert it because project files where created in an older version of VS. It needs Windows SDK 7.0 or above also, and that's all if I don't forget anything :)

[Guest]

Thank you Microsoft. Not! My expensive VC++ 2005 will not install on Windows 8.

Trying 2013 Express.

[Guest]

2013 Express is a no go as it is missing ATL.

Looks like I have to back off to 2010 and windows SDK 7.1. Hope it will all work on Windows 8.

If somebody that has done this I would really appreciate your help. Thanks.

[Guest]

I have tested sample_decode.exe with a small clip, and it works well Can you please describe your environment, i.e., VS version, platform SDK, OS, etc. I am running into nightmares trying to get a working environment. Thank you.

[Guest]

Maybe junk Win8 and install Win7 so I can use my VS 2005 Pro?

[noee]

NOt sure if this helps, but if you can find the ATL folder from another devenv, copy it to 2013 Express, it may work. WOrked for me with the last LAV compiles with 2013 Express.

[Guest]

NOt sure if this helps, but if you can find the ATL folder from another devenv, copy it to 2013 Express, it may work. WOrked for me with the last LAV compiles with 2013 Express. Well, I have one from VC 6 :). I can try it, but are you sure it is only the header files that are needed, because that is all that is in there?

[r0lZ]

Can you please describe your environment, i.e., VS version, platform SDK, OS, etc. I am running into nightmares trying to get a working environment. Thank you.I have only tested the pre-compiled exe included in the SDK as example. I haven't compiled it myself. Sorry, I can't help.

[Guest]

VC6++ ATL headers don't work. Guess I'm not surprised.

Hmm, thinking...

[noee]

Yeah, well, I used 2010 version, so I guess I got lucky....

[Guest]

2010 Express?

[Guest]

Ha ha. I found a way to install 2005. :D

[frencher]

Maybe junk Win8 and install Win7 so I can use my VS 2005 Pro?

Yeah version pro = x64 :)

Ha ha. I found a way to install 2005. :D

Yeahhhhhhhhhhh increase compatibility :p

[Guest]

Just hoping I can dispense with all that ATL crap. We'll see.

[Nico8583]

You can also make a VM with Windows 7 ;)

I have tested Visual Studio 2010 Ultimate on Windows 7 Pro x64 and Windows SDK 7.1, it works to compile Intel Media SDK. But on Windows 8.1, I use only Embarcadero Delphi XE2 so not our need.

Do you have some AVC/MVC samples to try ?

[Guest]

I'm not making a VM, forget it. I have lots of samples.

2005 is a no go, it doesn't link the WinSDK properly. Going back to 2013 Express as I had been building the wrong sample and the correct sample does not use ATL. Will advise my results...

[Guest]

Oh happy day! Have built OK with Visual Studio 2013 Express. I'll test the executable now and then start on the MVC source filter.

[noee]

Cool. DId you actually take some action to eliminate ATL or was it just the sample....

[Nico8583]

I'm not making a VM, forget it. I have lots of samples.

2005 is a no go, it doesn't link the WinSDK properly. Going back to 2013 Express as I had been building the wrong sample and the correct sample does not use ATL. Will advise my results...

Oh happy day! Have built OK with Visual Studio 2013 Express. I'll test the executable now and then start on the MVC source filter.

No problem for VM.

Very good news :)

[Sparktank]

Oh happy day! Have built OK with Visual Studio 2013 Express. I'll test the executable now and then start on the MVC source filter.

This forum seriously needs a "like" button.
Really looking forward it!

[Guest]

DId you actually take some action to eliminate ATL or was it just the sample.... Just the sample.

My first decode did not go well. Using the simple decode sample with a short bluray ES, the result has corruptions. I will post at their forum about it. This will be a test of their support. I hope it will be satisfying.

[Guest]

Simple_2_decode works but simple_6_decode does not. I have posted at the forum. I can proceed with simple_2_decode for now.

[Guest]

Anybody know how to demux an SSIF file to an ES that the Intel Media SDK decoder can accept?

I see that the latest MPC-HC can play the SSIF file directly so I can investigate that angle but I am hoping someone knows. madshi? nevcairiel?

[r0lZ]

Previously, we have used MVCCombine to combine the 2 video streams (that must have been demuxed). IIRC, it can create the file suitable for the Intel decoder. You can still download it here (http://www.share-online.biz/download.php?id=5HN7MELMCJW). The original post about MVCCombine (CLI version) is here (http://forum.doom9.org/showthread.php?p=1624598#post1624598). I strongly suggest to avoid the GUI version. It is extremely slow.

[Guest]

Nice. Thank you, r0lZ. Demuxing to separate ES is easy. Now you have given me the step to get from those to a combined ES for the Intel Media SDK. Off and running...

[Guest]

oops, no source code for MVCCombine. Is it available?

[r0lZ]

I don't think so. And Neisklar, its author, is not active any more. Sorry, I don't have a better solution. I thought you needed it only to do a test of the decoder.

[Guest]

I don't think so. And Neisklar, its author, is not active any more. Sorry, I don't have a better solution. I thought you needed it only to do a test of the decoder. Well, yes, it is still useful and I can reverse engineer it by inspecting its inputs and outputs. Just looking for shortcuts. Don't forget that Sunday deadline. :)

[Guest]

r0lZ, do you have a sample combined MVC stream that is accepted by the Intel decoder? I'd like to work backwards that way if possible. Thank you.

[Guest]

I made one with eac3to and MVCCombine. Now to see what the decoder does with it...

[Sharc]

Cool. Busy weekend ahead. Ready for testing ......:)

[Guest]

The simple_decode_2 sample delivered only one eye from the combined stream, so I have to find out how to enable it for MVC. Investigating...

EDIT: Found the relevant documentation: mediasdkmvc-man.pdf. :)

[r0lZ]

I haven't kept any combined stream here, but any one recreated with two ES and MVCCombine should work.

[r0lZ]

Sorry, but I gave you a link to the first version of MVCCombine. The most recent version can be found here (http://forum.doom9.org/showthread.php?p=1628058&highlight=MVCCombine#post1628058). That post has also a description of the CLI options.
I have searched the whole thread about some explanation on what MVCCombine does exactly, but without success.

[frencher]

r0lZ, do you have a sample combined MVC stream that is accepted by the Intel decoder? I'd like to work backwards that way if possible. Thank you.

Other example: Trailer AVC/MVC (http://ul.to/8f9mskio)

[Guest]

Thanks, guys. I am making progress. Will advise...

[frencher]

Thanks, guys. I am making progress. Will advise...

Thank for your work neuron2

[allanlee]

Anybody know how to demux an SSIF file to an ES that the Intel Media SDK decoder can accept?

I see that the latest MPC-HC can play the SSIF file directly so I can investigate that angle but I am hoping someone knows. madshi? nevcairiel?

Another method to do it is by connecting filters in GraphStudio:

1. AVC_ES & MVC_ES (extracted by eac3to) import via File Source (Async.)
2. Feed these 2 ES to 2 MainConcept(Sonic) MPEG Demultiplexer Filters respectively
3. Connect the two outputs from last step to MainConcept(Sonic) MVC Muxer;
4. Write to File by MainConcept(Sonic) File Writer, which should be identical to the output of MVCCombine.

[Nico8583]

It's sunday :D
More seriously, I have spent many time to find MVCCombine source but I haven't found. Neisklar owns a Github with 4 projects but not MVCCombine. I've tried to contact him but he doesn't respond so I can't help you with MVCSource.
But if Intel mvc_dec_filter.dll accepts MVC input and Intel h264_dec_filter.dll accepts H264 input, perhaps there is a solution on this way :confused:

[Zathor]

Likely already know but nevertheless:
Since two days a new Intel Media SDK (2014) is available. I had only a quick view into the release notes. This sounds interesting:
- The new release also introduces support for media container muxing and demuxing(split). Container formats: MPEG TS and MPEG-4 are supported
Seems to be done with FFmpeg. Not sure if this will help at all.

[Nico8583]

Likely already know but nevertheless:
Since two days a new Intel Media SDK (2014) is available. I had only a quick view into the release notes. This sounds interesting:

Seems to be done with FFmpeg. Not sure if this will help at all.

Yes good news, it seems to be several ameliorations in 2014 version (HEVC/H265 support but no need now, file muxing and demuxing, splitters and co). I'm looking for documentation.

[Guest]

I already have 2104 gold.

Things are getting murky. The 2014 introduces a new API version that does not match the sample code. The only sample code that claims to support MVC is the bloated ATL sample, which I cannot build. But it too uses the old API. So I need either updated samples using the new API or I need the old API docs, which I cannot find. I've posted about it at their forum but they have to approve posts and both my last two posts are still pending.

Thus, I will not be able to rely on the samples. I will have to figure everything out from scratch on my own by experimenting. It won't be done today. :p

I know they're busy but to me up-to-date sample code is crucial to deliver a usable SDK. It's not a good omen for me that things are in such a mess. Persevering...

[r0lZ]

Persevering...It's much appreciated!

[Nico8583]

Have you seen this sample code ?
http://software.intel.com/sites/default/files/IntelMediaSDK_VideoDecodingSample_0.msi or http://software.intel.com/sites/default/files/IntelMediaSDK_DirectShowSample_0.msi

[Guest]

No. Also I'm not interested in DirectShow. What is the first one and where is it described at the Intel site? Anyway, I doubt it's relevant here with all that ffmpeg stuff inside.

[Nico8583]

You can find informations here (http://software.intel.com/en-us/media-solutions-portal)

There is a "Samples" tab, with Intel Media SDK 2014 samples are provided as standalone packages.

Informations about the first one :
Video Decoding Sample
Console application which performs decoding of elementary compressed video stream to raw frames. Includes the following features:

stereoscopic 3D (S3D) rendering of elementary MVC (Multi-View Video Coding) streams
decoding of VP8* video via VP8 Decoder Plug-in Sample using FFmpeg*
decoding of HEVC (High Efficiency Video Coding) video via Intel® Media SDK HEVC Software Decode Plug-in from Intel Media SDK 2014 HEVC Software Pack

You can also find informations in "Documents" tab, like "Intel Media SDK 2014 Developer’s Guide" or "Intel Media SDK 2014 Samples Guide"

[Guest]

:thanks::goodpost:

Ah, thanks, that may be just what I'm looking for, as I do not see any ATL in there. I'll try to build and run it.

They need to flush the old samples off their site as they are confusing as [censored].

[Nico8583]

:thanks::goodpost:

Ah, thanks, that may be just what I'm looking for, as I do not see any ATL in there. I'll try to build and run it.

They need to flush the old samples off their site as they are confusing as [censored].

You're welcome, happy to help you :)

[Guest]

Darn, it still requires ATL. :devil: I'll probably back off to Win7 to allow me to use my VS 2005 pro.

[Nico8583]

Darn, it still requires ATL. :devil: I'll probably back off to Win7 to allow me to use my VS 2005 pro.

Thanks to Microsoft to not include ATL in Express Edition :(

[Guest]

Indeed. Actually that sample is the same as the first one I tried, which I reported as requiring ATL. Windows 7, here I come.

[Nico8583]

Good luck ;)

[Guest]

I brought up a Win7 Pro on an older machine I have just for testing. If things work out on it I will migrate it to the new hardware and ditch win8.

So first the old machine started bluscreening for CPU temp too high. I cleaned it up with compressed air and it seems stable now. Then I decided to get a CPU temp monitor SW on there but was careless and caught conduit crap all over the place. I got that cleaned up.

Then I installed the needed .NET framework and a Win7 SDK. Then VS 2005 followed by Intel Media SDK and the decode sample. Tried to build and got undefs in some directx 11 headers in the win7 SDK. So now the Intel stuff is wired to win8 SDK. I worked around it by adding the new enum values to the win7 SDK files. The sample now builds. Yay!

Off to test the executable now...

[r0lZ]

Great news! I was far to imagine that complexity to get it compiling. Now, lets hope it will be simpler to get it working!

[Guest]

OK, the decoder successfully decoded both eyes of the MVC! That gives me all the API calls and etc. that I will need.

Reverse engineering MVCCombine now...

[HWK]

Marvelous, to hear it. Would consider ability decode to gpu?

[Guest]

Marvelous, to hear it. Would consider ability decode to gpu? You mean QuickSync? Or you mean add MVC to DGDecNV?

[HWK]

Second option, I currently have gtx 580 and when I play 3D, decoding is done on GPU and any gpu with VP4 or higher can do it. I was wondering if it is possible for you to implement.

[Update 1]
I was thinking it would be great to have avisynth plugin to decode all formats supported by Intel Media SDK. What do you think of this option?

[Guest]

Sorry, HWK, it's all off topic for this thread. Anyway, let's go a step at a time.

[HWK]

No problem, I fully understand you intent on this matter. Just wanted you to consider it.

[Nico8583]

I'm agree with HWK, after MVC decoder it will be good to have an avisynth plugin for all formats (H264 / VC1 / MVC / HEVC...), but firstly MVC decoder :D

Thanks neuron2 ! Happy to read you everyday ;)

[HWK]

Nico8583


You do know Intel media sdk does not support VC-1. Neuron2 has to write separate program to handle this part along with HEVC.

[Nico8583]

Nico8583


You do know Intel media sdk does not support VC-1. Neuron2 has to write separate program to handle this part along with HEVC.
It seems you are wrong :)
Extract from Intel Media Developer's Guide :
Video Decoders : H.264 (AVC and MVC), MPEG-2, VC-1, JPEG*/Motion JPEG, HEVC(SW)
While Intel Media SDK is designed to be a flexible solution for many media workloads, it focuses
only on the media pipeline components which are commonly used and usually the most in need
of acceleration. These are:
- Decoding from video elementary stream formats (H.264, MPEG-2, VC-1, and
JPEG*/Motion JPEG, new: HEVC) to uncompressed frames
Intel Media SDK also includes DirectShow filter for H264, MPEG2, VC-1 and JPG streams :)
But yes for HEVC, it's necessary to buy Intel SDK if you want to use hardware acceleration with this codec.

[nevcairiel]

Anybody know how to demux an SSIF file to an ES that the Intel Media SDK decoder can accept?

I see that the latest MPC-HC can play the SSIF file directly so I can investigate that angle but I am hoping someone knows. madshi? nevcairiel?

I don't know what the Intel decoder accepts (yet, its on my own TODO to investigate it for decoding MVC streams), but SSIF files are just plain MPEG-TS streams, one primary ordinary H264 stream, and a second with the MVC specific data for the second eye.

I always assumed you simply interleave those based on timestamps and feed that to a decoder, but thats where my knowledge ends so far.

[Guest]

[Let's stay on topic please. This thread is about an MVC source filter. All discussion/speculation about further things has to wait for a new thread. Thank you.]

I've made some good progress. I totally stripped down the Intel sample to a "simple sample" that no longer requires ATL, dispenses with all the extra stuff not needed for AVC/MVC decode, replaces the CLI parsing with direct configuration (source filter won't have CLI), and combines everything into a single project, deleting all unneeded files. Of course, because I removed the ATL dependency I was able to move back to Win8 and build with Visual Studio 2013 Express. This opens the door for other Avisynth developers that don't like to drop $$$ for no good reason. I'll give the source code for the simple sample soon, but not right now, as I want to be the first to produce the open-source source filter. :p I plan to stay with Win8 as there is no reason to downgrade anymore.

Next step is to bring up and validate Avisynth on this Win8 machine and then begin developing the source filter based on the simple sample code I created.

Initially, the filter will accept only the combined MVC elementary stream, which you can make with eac3to+mvccombine. Later I will integrate that and accept an SSIF file directly.

[r0lZ]

Good progress, indeed! I can't wait for the first beta...

[Nico8583]

Very good news again ! ;)

Perhaps pistacho could help you to implement separated streams ? :)

[Guest]

Perhaps pistacho could help you to implement separated streams? I don't anticipate needing any help, but your suggestion is nevertheless appreciated. Please don't dump on pistacho; he's doing his thing and we're doing ours. No need to create any unnecessary antinomies. We thank him for what we learn from his work that he shares with us, and wish him well. IMHO.

[Nico8583]

No problem :) it was not to tell him to share any part of his sourcecode, only to share theory and how he has proceeded to use separated streams (with a routine includes in Intel Media SDK, with a routine writes by himself, with a routine takes from another free soft, etc...) ;)

About your simple sample : input is combined stram but output is left view and right view ? Or is it already possible to have only left view or only right view ?

[frencher]

neuron2, Here is my contribution for the detection of the First view of SSIF

#cs ----------------------------------------------------------------------------

AutoIt Version: 3.3.6.1
From idea of: Web Free Software
In help: mikell

Script Function:
_Include_Extract_Chapters_List.au3.

#ce ----------------------------------------------------------------------------

#include-once

; analyse de fichier playlist *.mpls

#Include <Array.au3>

#Include <EditConstants.au3>
#include <String.au3>



; -------------------------------------------------------------------------------------------------------------------------------------------------------------

Global $Input = "" ;Varible for Input
Global $Output = "" ;Varible for Output
Global $ShowMessage

;;Get Parameters
ReadCmdLineParams()

;; Display message
;MsgBox(0, "", "Input: " & $Input & @LF & "Output: " & $Output)

Func ReadCmdLineParams() ;Read in the optional switch set in the users profile and set a variable - used in case selection

;;Loop through every arguement
;;$cmdLine[0] is an integer that is eqaul to the total number of arguements that we passwed to the command line
for $i = 1 to $cmdLine[0]

select

;;If the arguement equal -i
case $CmdLine[$i] = "-i"
;check for missing argument
if $i == $CmdLine[0] Then cmdLineHelpMsg()

;Make sure the next argument is not another paramter
if StringLeft($cmdline[$i+1], 1) == "-" Then
cmdLineHelpMsg()
Else
;;Stip white space from the begining and end of the input
;;Not alway nessary let it in just in case
$Input = StringStripWS($CmdLine[$i + 1], 3)
endif

;;If the arguement equal -o
case $CmdLine[$i] = "-o"

;check for missing arguement
if $i == $CmdLine[0] Then cmdLineHelpMsg()

;Make sure the next argument is not another paramter
if StringLeft($cmdline[$i+1], 1) == "-" Then
cmdLineHelpMsg()
Else
;;Stip white space from the begining and end of the input
;;Not alway nessary let it in just in case
$Output = StringStripWS($CmdLine[$i + 1], 3)
EndIf

EndSelect

Next

;Make sure required options are set and if not display the Help Message
If $Input == "" Or $Output == "" Then

If $cmdline[0] <> "" Then
;cmdLineHelpMsg()
;If $i == $CmdLine[0] Then cmdLineHelpMsg()

;Make sure the next argument is not another paramter
;;Stip white space from the begining and end of the input
;;Not alway nessary let it in just in case
$Input = $CmdLine[1]
$Output = @ScriptDir & "\First view of SSIF.txt"
;Msgbox(0, "$Input", $Input)
$ShowMessage = '1'
;Msgbox(0, "$ShowMessage", $ShowMessage)
Else
cmdLineHelpMsg()
EndIf

EndIf

EndFunc

Func cmdLineHelpMsg()
MsgBox(0,"", 'First view of SSIF by Web Free Software' & @LF & @LF & 'Drag and Drop "xxxxx.mpls" to "First view of SSIF.exe"' & @LF & @LF & 'Other Required Options:' & @LF & @LF & '-i ' & @tab & ' [xxxxx.mpls]' & @tab & @tab & 'mpls for input' & @LF & '-o ' & @tab & ' [output with extension]' & @tab & 'Return value' & @LF)
Exit
EndFunc

; -------------------------------------------------------------------------------------------------------------------------------------------------------------

Global $mfile = $Input, $info, $n = 82, $ch, $chap[1][2], $m2ts[1][3] , $m2, $ps, $ChaptersMKVmerge

$size = FileGetSize($mfile)
$mpls = FileOpen($mfile, 16)
Global $caract = StringRegExp(FileRead($mpls), '[[:xdigit:]]{2}', 3)
FileClose($mpls)
;_arraydisplay($caract, "fichier")

$hexa = $caract[56]
$Binary = HexaToBinary($hexa)
;Msgbox(0, "Binary", $Binary)

Func HexaToBinary($hexa)
$hexvalue = StringSplit($hexa,'')
$Result = ''
$bits = "0000|0001|0010|0011|0100|0101|0110|0111|1000|1001|1010|1011|1100|1101|1110|1111"
$bits = stringsplit($bits,'|')
for $n = 1 to $hexvalue[0]
$result &= $bits[Dec($hexvalue[$n])+1]
Next
Return $result
EndFunc

$Reverse_Left_Right_View = StringSplit($Binary, '')
$Reverse_Left_Right_View = $Reverse_Left_Right_View[4]

;Msgbox(0, "Array", $Reverse_Left_Right_View)


If $Reverse_Left_Right_View = 1 Then
$AVC_MVC_Order = "#Left__View = MVC" & @CRLF & "#Right_View = AVC" & @CRLF & "#Return = " & $Binary
Local $TMP = FileOpen( $Output, 2) ; Efface les données précédentes du fichier: $Output
FileWrite( $Output, $AVC_MVC_Order) ; Met à jour: $Output
FileClose( $Output) ; Ferme le fichier: $Output avec FileOpen
If $ShowMessage <> '' Then
Msgbox(0, "First view of SSIF", $AVC_MVC_Order)
EndIf
Else
$AVC_MVC_Order = "#Left__View = AVC" & @CRLF & "#Right_View = MVC" & @CRLF & "#Return = " & $Binary
Local $TMP = FileOpen( $Output, 2) ; Efface les données précédentes du fichier: $Output
FileWrite( $Output, $AVC_MVC_Order) ; Met à jour: $Output
FileClose( $Output) ; Ferme le fichier: $Output avec FileOpen
If $ShowMessage <> '' Then
Msgbox(0, "First view of SSIF", $AVC_MVC_Order)
EndIf
EndIf

[Guest]

I brought up Avisynth on the Win8 machine. Also I ported DGAVCDecode and brought it up successfully with Visual Studio 2013. Cloned DGAVCDecode to DGMVCDecode, which is the new filter.

Next I will rip out the lavc decoder in DGMVCDecode and replace it with the Intel decoder. Then I have to write code to replace the YUV output with proper YV12 to return to Avisynth.

@frencher

I'm not ready for SSIF yet and likely will write my own parser. But thanks for the contribution. I'm not sure what language that is. I code in C++ here.

[Guest]

About your simple sample : input is combined stream but output is left view and right view? Or is it already possible to have only left view or only right view ? That can be done but you can also select views in your script, so the initial version will output base and dependent views interleaved by frame.

[Guest]

Can somebody tell me how this will be used in a script and process? I need to understand the use cases to ensure that it meets requirements. So, what are your scripts that would use MVCSource(), and how will you use the scripts?

[Thalyn]

Basic gist of a current MVCSource script is as follows:

Source = MVCSource ("AVC or combined.264", "MVC if not combined.264", FrameCount, 2)
AVC = SelectEven (Source)
MVC = SelectOdd (Source)

FrameCount has to be determined beforehand but you can use EAC3To, TSMuxer or even MediaInfo to find that. The 2 can also be changed accordingly, with 0 giving only AVC, 1 giving only MVC, and 2 or -2 giving AVC + MVC interleaved but the order dependant on whether it is positive or negative. If the 2 is positive than AVC is first (starting from frame 0, hence SelectEven).

[Sharc]

Suggested scenarios (Examples for 1000 frames):


LoadPlugin("c:\Program Files Video\MVCSource\MVCsource.dll")

#------------Regular Left and Right
Interleaved = MVCsource("c:\Movies\00049.track_4113.264", "c:\Movies\00050.track_4114.mvc",1000,2)
V1 = SelectOdd(Interleaved)
V2 = SelectEven(interleaved)
return StackHorizontal(V2,V1) #SBS full



#---------------Flip Left and Right views --------------
Interleaved = MVCsource("c:\Movies\00049.track_4113.264", "c:\Movies\00050.track_4114.mvc",1000,-2)
V1 = SelectOdd(Interleaved)
V2 = SelectEven(Interleaved)
return StackHorizontal(V2,V1) #SBS full
#---------------------------------------------




#----------------Base View only ------------
Base = MVCsource("c:\Movies\00049.track_4113.264", "c:\Movies\00050.track_4114.mvc",1000,0)
return Base
#-------------------------------------------



#---------------Dependent view only------------
Dependent = MVCsource("c:\Movies\00049.track_4113.264", "c:\Movies\00050.track_4114.mvc",1000,1)
return Dependent
#----------------------------------------------

[allanlee]

Can somebody tell me how this will be used in a script and process? I need to understand the use cases to ensure that it meets requirements. So, what are your scripts that would use MVCSource(), and how will you use the scripts?

Left - Right view interleaved by frame will be a good idea. :-)

Alternatively, SBS & OU might be necessary. I believe that a majority of users will apply this filter in encoding to & playing as (Half) SBS or OU.

[r0lZ]

Creating the Half-SBS or Half-T&B can easily be done with some avisynth commands. You should use StackHorizontal and HorizontalReduceBy2 (for SBS) or StackVertical and VerticalReduceBy2 (for T&B). No need to add that features in the Source plugin. IMO, it should be kept as simple as possible.

[DarkSpace]

Can somebody enlighten me why you want to specify how many frames the source filter should output?
Isn't it just fine if the source filter outputs all frames that are in the source, just like all other source filters that I know do? If you want to omit frames, you can always add a Trim to your script...

[Sharc]

Can somebody enlighten me why you want to specify how many frames the source filter should output?
Isn't it just fine if the source filter outputs all frames that are in the source, just like all other source filters that I know do? If you want to omit frames, you can always add a Trim to your script...
It's a heritage from the current implementation.
For "trim" to work the filter would need to support seeking (all non-commercial 3D-filters/decoders are so far sequential only, AFAIK)

[Sharc]

Creating the Half-SBS or Half-T&B can easily be done with some avisynth commands. You should use StackHorizontal and HorizontalReduceBy2 (for SBS) or StackVertical and VerticalReduceBy2 (for T&B). No need to add that features in the Source plugin. IMO, it should be kept as simple as possible.
Agree that it should be kept simple.
However, AFAIK for OU (T&B) and HDMI compliance one would have to include the a horizontal gap of 45 scanlines between the top and bottom picture, plus ensure the even number of scanlines, see for example the tutorial here (http://www.pantarheon.org/AviSynth3DToolbox/). According to this, HDMI does not even support half size ....

[Guest]

I've run into a little issue with the Intel code crashing when it is packaged into an Avisynth DLL. See here for my posting at their forum:

http://software.intel.com/en-us/forums/topic/499486

I have to get this solved before I can proceed.

[r0lZ]

However, AFAIK for OU (T&B) and HDMI compliance one would have to include the a horizontal gap of 45 scanlines between the top and bottom picture, plus ensure the even number of scanlines, see for example the tutorial here (http://www.pantarheon.org/AviSynth3DToolbox/). According to this, HDMI does not even support half size ....
AFAIK, stacking the 2 frames on top of each other and dividing the vertical resolution by 2 produces a perfect Half-OU picture. Some guys want to remove the black horizontal bars from Cinemascope 3D movies before stacking them together (in SBS or OU mode), but that causes many problems, and most TVs cannot show that cropped 3D format at all, or at least without distortions. Anyway, that's a problem related to the composition of the final format, and not at all to the decoding of the AVC and MVC streams. The Source filter should just output what it decodes. The rest is the responsibility of the avisynth script (and its author!)

@neuron2
Damn! Another problem. Let see if the Intel guys can help...

[Sharc]

Anyway, that's a problem related to the composition of the final format, and not at all to the decoding of the AVC and MVC streams. The Source filter should just output what it decodes. The rest is the responsibility of the avisynth script (and its author!)
Agree.

[DarkSpace]

For "trim" to work the filter would need to support seeking (all non-commercial 3D-filters/decoders are so far sequential only, AFAIK)
I see, thank you. In that case, however, does it make sense to set both start frame (in case you want to omit frames from the beginning of the clip) and length instead of only length? That way, you should be able to accurately split the video without having to use Trim or processing all frames before the beginning with whatever filter chain you have just so you can discard them.

[Guest]

Damn! Another problem. Let see if the Intel guys can help... I discovered I could disable break on that exception and things seem to go on, but I don't like having unexpected exceptions. I'll go on with the development and try to get this fixed in parallel.

[Nico8583]

It's a heritage from the current implementation.
For "trim" to work the filter would need to support seeking (all non-commercial 3D-filters/decoders are so far sequential only, AFAIK)
In Intel Media SDK, there is a video player for MVC and it is announced to support seeking, but I never tried it. Perhaps it works, I'll try when I could do that :)

[frencher]

In Intel Media SDK, there is a video player for MVC and it is announced to support seeking, but I never tried it. Perhaps it works, I'll try when I could do that :)

Very good news for MVC Player Free :p

[frencher]

Can somebody enlighten me why you want to specify how many frames the source filter should output?
Isn't it just fine if the source filter outputs all frames that are in the source, just like all other source filters that I know do? If you want to omit frames, you can always add a Trim to your script...

Left View 100000
Right View 100001

Some crash is possible, not if limited at 100000

Or both idea enabled or disabled ;)
LoadPlugin("c:\Program Files Video\MVCSource\MVCsource.dll")

#------------Regular Left and Right
Interleaved = MVCsource("c:\Movies\00049.track_4113.264", "c:\Movies\00050.track_4114.mvc",frames=1000,2) #1000 frames
or
Interleaved = MVCsource("c:\Movies\00049.track_4113.264", "c:\Movies\00050.track_4114.mvc",frames=-1,2) #all frames
V1 = SelectOdd(Interleaved)
V2 = SelectEven(interleaved)
...
From allanlee
Left - Right view interleaved by frame will be a good idea. :-)

Yes very good idea and work easy with avisynth 2.58 fix for not compressed video and high memory: ffdshow video decoder choose all supported format is not necessary

[Guest]

Good news guys. I have succeeded to decode and display my first MVC stream using my version of MVCSource(). It's luma only until I add the NV12-->YV12 code but that will be easy. It's easy to copy the Y plane but need some code to massage the NV12 chroma.

I worked around the exception mentioned earlier and will address it properly later. It doesn't stop things from working.

So, looking good. Still need lots of cleanup and some code to make it work right with SelectEven() and SelectOdd() as it doesn't support seeking at this time.

[Sharc]

Congratulations, neuron2 :)

[frencher]

Good news guys. I have succeeded to decode and display my first MVC stream using my version of MVCSource(). It's luma only until I add the NV12-->YV12 code but that will be easy. It's easy to copy the Y plane but need some code to massage the NV12 chroma.

I worked around the exception mentioned earlier and will address it properly later. It doesn't stop things from working.

So, looking good. Still need lots of cleanup and some code to make it work right with SelectEven() and SelectOdd() as it doesn't support seeking at this time.

Jeeeeeeeez very good neuron2
Your news are a joy :goodpost:

[allanlee]

Good news guys. I have succeeded to decode and display my first MVC stream using my version of MVCSource(). It's luma only until I add the NV12-->YV12 code but that will be easy. It's easy to copy the Y plane but need some code to massage the NV12 chroma.

I worked around the exception mentioned earlier and will address it properly later. It doesn't stop things from working.

So, looking good. Still need lots of cleanup and some code to make it work right with SelectEven() and SelectOdd() as it doesn't support seeking at this time.

:goodpost: Congratulations! To start with outputting one view (controlled by parameter) will be great as well. (at least for me :-D)

[Thalyn]

In the interest of reducing confusion, can we perhaps refer to the new plugin/function by a different name? There's already an existing MVCSource plugin with a correspondingly named function.

Might I suggest N2MVC?

[Overdrive80]

In the interest of reducing confusion, can we perhaps refer to the new plugin/function by a different name? There's already an existing MVCSource plugin with a correspondingly named function.

Might I suggest N2MVC?

Or OpenMVCSource... Haha

[r0lZ]

Keep up the good work Neuron2!

Can somebody enlighten me why you want to specify how many frames the source filter should output?I think also that the avisynth script must "know" the number of frames of the returned clip, for the Info() command, and because the calling program must often know it. For example, x264 can only show the percentage of the progress if it knows the total number of frames to encode. As long as it is not possible to seek, I suppose that the only way to tell how many frames the source filter will decode is to specify it with a parameter. Of course, if the filter can retrieve it automatically, it's the best solution, but apparently, it's not easy.

Also, Frencher is right. Sometimes, there is a slightly different number of frames in the AVC and MVC streams, and it may be necessary to specify exactly the number of frames to decode. Of course, that parameter has also the advantage that it can limit the number of frames to decode, for example to do a little test. Anyway, it it's possible and easy enough, I vote for an optional parameter.

[Overdrive80]

Framecount() is function that return total frames of video. Maybe, could be used as variable. ^^

[DarkSpace]

I think also that the avisynth script must "know" the number of frames of the returned clip, for the Info() command, and because the calling program must often know it. For example, x264 can only show the percentage of the progress if it knows the total number of frames to encode. As long as it is not possible to seek, I suppose that the only way to tell how many frames the source filter will decode is to specify it with a parameter. Of course, if the filter can retrieve it automatically, it's the best solution, but apparently, it's not easy.
Thanks, that elaborates it a bit. My main confusion came from not knowing about the inability to seek, I just assumed that seeking was possible and all that.

Also, Frencher is right. Sometimes, there is a slightly different number of frames in the AVC and MVC streams, and it may be necessary to specify exactly the number of frames to decode. Of course, that parameter has also the advantage that it can limit the number of frames to decode, for example to do a little test. Anyway, it it's possible and easy enough, I vote for an optional parameter.
Wasn't the different number of frames between views an eac3to extraction bug? I remember this coming up in the eac3to thread in any case, and I think that madshi either fixed it already or said he would fix it.
Also, I think that such files are broken, and I honestly don't like the idea of assuming that files are going to be broken. ;)

Anyway, I agree that the parameter is necessary as long as seeking is impossible, and if/when seeking becomes possible, it could become optional.

[r0lZ]

Wasn't the different number of frames between views an eac3to extraction bug? I remember this coming up in the eac3to thread in any case, and I think that madshi either fixed it already or said he would fix it.
Also, I think that such files are broken, and I honestly don't like the idea of assuming that files are going to be broken. ;)I don't know exactly. I haver noticed a very different number of frames in a 3D BD, but it was due to a bad rip. But I have also had once a difference of one single frame, and in that case, the rip was correct, or at least, I haven't found any problem, and a second rip gave exactly the same result. It may be due to a bad authoring. I agree however that such thing should normally never happen.

[Guest]

All right, boys and girls, I have a beta for you!

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

The ZIP contains a text document with usage information. A sample combined MVC stream is also included.

Planned improvements:

* Avisynth 2.6 and Avisynth+ support
* HW acceleration
* integrated frame counting if the frames parameter is missing
* accept separate view elementary streams
* accept SSIF input directly

I would appreciate your feedback and prioritization on the planned improvements. I think HW acceleration is high on the list.

[allanlee]

All right, boys and girls, I have a beta for you!

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

The ZIP contains a text document with usage information. A sample combined MVC stream is also included.

Planned improvements:

* Avisynth 2.6 and Avisynth+ support
* HW acceleration
* integrated frame counting if the frame parameter is missing
* accept separate view elementary streams
* accept SSIF input directly

I would appreciate your feedback and prioritization on the planned improvements. I think HW acceleration is high on the list.

:goodpost:

;) Fantastic! Great job!
Downloaded & hunting for bugs :D

[Guest]

"Can somebody enlighten me why you want to specify how many frames the source filter should output?"

It's not that you want to, it's that you have to. The source filter does not know how many frames are in the source elementary stream yet it has to report the number of frames to Avisynth at the stream open (e.g., that's how VirtualDub's File/Information knows the frame count). Of course one could parse the entire stream and count the frames on the first open and store it in a primitive index file for later opens. This will be a useful addition.

Other source filters that use an index file already know the count because they can determine it from the index file.

[Guest]

In the interest of reducing confusion, can we perhaps refer to the new plugin/function by a different name? There's already an existing MVCSource plugin with a correspondingly named function.

Might I suggest N2MVC? Yeah, you're right about that. Sticking to my pattern, I prefer DGMVCSource().

[RieGo]

hey, nice job! i'm gonna try it out later. :)
is there any chance to implement reading MVC MP4 directly?

[Sharc]

All right, boys and girls, I have a beta for you!

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

The ZIP contains a text document with usage information. A sample combined MVC stream is also included.

Planned improvements:

* Avisynth 2.6 and Avisynth+ support
* HW acceleration
* integrated frame counting if the frames parameter is missing
* accept separate view elementary streams
* accept SSIF input directly

I would appreciate your feedback and prioritization on the planned improvements. I think HW acceleration is high on the list.
Bingo! It works here. Thanks !!

Just a note to the script examples:
Should "Left" and "Right" be replaced by "Base" and "Dependent" or similar? I am asking because the allocation of left and right views to the streams are not standardized.

Priorities: I would wish to have 2 streams (base, dependent) as source (or ssif) rather than a combinedMVC stream.

[Nico8583]

Thanks a lot neuron2, you're a king ! I'll try this afternoon ;-)
For me, this is order of improvments :
* accept separate view elementary streams
* HW acceleration
* integrated frame counting if the frames parameter is missing
* Avisynth 2.6 and Avisynth+ support
* accept SSIF input directly
Separate elementary streams is more important for me than other, and HW acceleration would be a great thing if it is a parameter (use or not). Integrated frame counting is not a problem.

[Sharc]

@neuron2
The plugin seems to work fine so far, I just came across following issue:
When I demux your sample "combined.264" with tsMuxeR 2.6.12, I get - as expected - 2 files like "combined_2.264" (base view) and "combined.mvc" (dependent view). Both files seem to be ok. Now I remux these 2 files with tsMuxeR to "combined_2.ts" which plays without issues 2D or 3D depending on player.
However, trying to decode the "combined_2.ts" with DGMVCsource fails. Is this because of the *.ts format?

Edit:
When deuxing, tsMuxeR reports:
.....
Processed 621 video frames
Processed 658 video frames
.....
i.e. unequal number of frames.

Edit2:
Same happens with other samples. When remuxed with tsMuxeR, decoding with DGMVCsource fails.
If so, it means that we can't produce combinedMVC files with tsMuxeR but would have to do use other tools like eac3to.

[Nico8583]

TsMuxeR can't produce raw h264 combined stream, it includes AVC and MVC to a container like TS or M2TS and Intel Media SDK accept only raw streams, IMHO.

@neuron2 : for the name of the filter, I suggest DGIntelSource() or similar because if in a next future you decide to include all decoders from Intel Media SDK, MVC would not have sense :confused:

[r0lZ]

Bingo! It works here. Thanks !!

Just a note to the script examples:
Should "Left" and "Right" be replaced by "Base" and "Dependent" or similar? I am asking because the allocation of left and right views to the streams are not standardized.

Priorities: I would wish to have 2 streams (base, dependent) as source (or ssif) rather than a combinedMVC stream.
I agree to the two remarks: base and dependent (or dep), or AVC and MVC are much better terms, given the fact that sometimes, the left and right views are inverted.

And for me too, taking input from the two ES is the most useful improvement.

[Sharc]

TsMuxeR can't produce raw h264 combined stream, it includes AVC and MVC to a container like TS or M2TS and Intel Media SDK accept only raw streams, IMHO.
Yes, I think this explains it. Thanks.
(Perhaps a good reason for prioritizing the acceptance of separate elementary streams and skip the "combined" intermediate step ;) )

[r0lZ]

Not a big deal, but I have had some difficulties to get it working, because I have removed all instances of libmfxsw32.dll from my system. Without that file in the PATH, DGMVCDecode.dll cannot work, and the script hangs for ever. It should instead issue a red error message. Also, I don't know if it's possible, but it will be a good thing if that DLL could be loaded automatically from the location of the DGMVCDecode.dll, even if that directory is not in the PATH, so that it will be possible to simply put both DLL in any directory. Currently, it's not possible to load the Intel dll if it is not in the current directory or in a directory in the system PATH.

Also, IMO, libmfxsw32.dll should be distributed with the final version of the plugin, unless it's forbidden by the Intel license. In the meantime, it is important to add it in the list of requirements in the readme file.

[r0lZ]

Another problem: I haven't been able to invert the two views (to decode a movie with the right view in the AVC stream, and the left view in the MVC stream). I don't understand what's happening. I start with your example script:

interleaved=mvcsource("combined.264",view=0,frames=2172)
left=interleaved.selecteven()
right=interleaved.selectodd()
stackhorizontal(horizontalreduceby2(left),horizontalreduceby2(right))

It works as expected, and the result is correct for the common order of views (left in AVC).

Now, with exactly the same combined tile, I did a test with inverted views:

interleaved=mvcsource("combined.264",view=0,frames=2172)
right=interleaved.selecteven()
left=interleaved.selectodd()
stackhorizontal(horizontalreduceby2(left),horizontalreduceby2(right))

But the output is exactly the same than with the previous script.
Same thing with this script:

interleaved=mvcsource("combined.264",view=0,frames=2172)
left=interleaved.selecteven()
right=interleaved.selectodd()
stackhorizontal(horizontalreduceby2(right),horizontalreduceby2(left))

I'm puzzled!

If, for whatever magical reason, inverting the views in the script is not possible, it will be necessary to add another value for the view argument, to invert the order of the interleaved frames.

[Nico8583]

Same issue than r0lZ with inverted views, left is allways left and right is allways right.

[Guest]

Another problem: I haven't been able to invert the two views (to decode a movie with the right view in the AVC stream, and the left view in the MVC stream). I don't understand what's happening. Hmm, strange, I'll have to look into that. Does this happen also with pistacho's filter?

[r0lZ]

Does this happen also with pistacho's filter? Pistacho's filter has 4 values for its "view" parameter: interleaved with AVC first, interleaved with MVC first, AVC only and MVC only. It is therefore always possible to get the frames in the correct order. However, if you decode, say, the AVC first and you try to swap the views with the following commands in the AVS script, it crashes. It's because the StackHorizontal (or Vertical) command reads the image from its first argument and then the image from its second argument, and since the filter doesn't support seeking, it is impossible to invert the order of the Stack command.

Your filter doesn't crash, even when the user tries to seek (for example with AVSpMod), but it returns always the next frame, regardless of the current frame number it is supposed to return. I suppose something similar happens when the even and odd frames are retrieved. It's always the first frame from the input file that is returned. Of course, I can't be sure. You know your code better than me. ;-)

[Nico8583]

With pistacho's filter :
- With this script, it's OK, like your filter :
LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Combined.264", "", 4898, 2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

- With this filter (invert left and right for even/odd), I have got a black screen, no returned view :
LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Combined.264", "", 4898, 2)

Left = SelectOdd(Interleaved)
Right = SelectEven(interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

- With this script (-2 instead of 2), views are inverted and all is OK :
LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Combined.264", "", 4898, -2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)

return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

[Guest]

r0lZ, when you try to swap by either of your methods, it results in requests to the filter being 1, 0, 3, 2, 5, 4, ... etc. But the filter ignores the request number and just returns the next decoded frame. So your analysis is correct. And thanks for the confirmation of the behavior, Nico8583.

I can handle it without a parameter. If I get a request number that is one beyond the linear (e.g., I expect 0 but get 1) then I know to use the swapping mode of delivery. The filter should act sensibly with selecteven()/selectodd() and not require extra parameters, IMHO.

I will prioritize as follows for now:

1. selecteven/selectodd behavior
2. accept separate streams
3. HW acceleration
4. SSIF support
5. library loading error messages, etc.
6. frame counting
7. Avisynth 2.6 and Avisynth+ support

Naming and stuff: As long as *this* filter accepts only MVC then it will be called DGMVCSource(). Speculations about future developments are OT in this thread and will be ignored. Patience guys, I am a fast coder but not *that* fast. :p

[Guest]

Here's pseudocode for GetFrame() to do this properly for interleaved delivery:

if (requested == expected + 1)
decode 2 frames, return the second, and save the first
else if (requested == expected - 1)
return the saved frame
else
decode one frame and return it

Off to try it now...

[r0lZ]

I see. Your method should be perfect. And the absence of an additional value for the view parameter is very elegant. :-)
I agree also with your order of priorities. It's perfect for me.

However, note that the SSIF support may not be as useful as supposed. Many movies are made of several (if not hundreds) SSIF files, and decoding only one of them doesn't make much sense. IMO, it's a support for MPLS that should be implemented later. In many cases, it will be (almost) equivalent to the SSIF support, but it will make it possible to decode all SSIF files referenced by the MPLS, thus the whole movie in one shot, in case of multi-angles movies. And the right left/right order of the views can be automatically retrieved from the MPLS, but not from the SSIF. Anyway, that's for later...

[Nico8583]

Is it more difficult do add a parameter for odd/even view ? Or your detection should allways be correct ? Perhaps there is one (or more) blu ray (with bad encoding for example) and you're detection will not work ? I don't know, it's only speculation :) but if we could delete this parameter it will be nice ;)

And OK, I'm sorry, I stop speculations about future developments in this thread :)

[r0lZ]

Nico, the detection of the frame order considered by Neuron2 doesn't depend of the BD. Only of the AVS script. If the even frame is requested before the odd, the order of the frames must be inverted. That's all. Of course, doing so requires to save the odd frame in a buffer, to serve it later without having to seek backward to decode it, but I suppose it's exactly the same thing with an "inverted view parameter".

[Nico8583]

OK, after reading again I've understand neuron2's pseudocode :)
Thanks r0lZ and thanks neuron2 for your work and your availability ;)

[Guest]

The auto detection of request order is working just fine. :D

I will upload a new beta shortly. Standby...

[Nico8583]

You're perfect :D

[Guest]

Here is beta 2:

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

This fixes the inability to swap the views in your script. Please be aware that the filter name is now dgmvcsource().

On to separate stream input...

[Nico8583]

If I have found this if it can help you to understand how AVC + MVC could become an elementary stream :
The first NAL-Unit in the bytestream is preceded by a four byte sequence which is
0x00000001. Every other NAL-Unit is preceded by a three byte sequence which is
0x000001. In addition each NAL-Unit can be succeeded by one or more null bytes (0x00).
As explained before, the NAL-Unit header is one byte, but it can be three additional
octets for MVC NAL-Units. The first byte of the header consists of a zero bit (a bit
which is always zero), the next two bits indicate whether the data in the NAL-Unit is
used by upcoming frames or if it can be discarded after decoding. The five remaining bits
in the one byte NAL-Unit header is the NAL-Unit type. A value of 14 or 20 indicates
an extended header for MVC. That means that whenever a NAL-Unit header has one of
those two types that NAL-Unit can be ignored for decoding when only 2D-playback is
desired.
The resulting bytestream is a AVC/MVC Elementary Stream (ES). It needs to be
packetized and encapsulated once again into a Packetized Elementary Stream (PES) as
described in ISO/IEC 13818-1:2000

It is extracted from this : http://www.nt.uni-saarland.de/fileadmin/file_uploads/theses/master/Master_Thesis_Hanjo_Viets_01.pdf page 19 & 20

[Guest]

Thanks, but it is too light on details. Don't worry, I have adequate information sources. ;)

[Nico8583]

I have tested beta 2, it works very well for left & right views inverted :D

[Guest]

Sweet. Thank you for your testing.

[r0lZ]

I confirm. Good job! :-)

However, the problem of the script freezing when libmfxsw32.dll is not in the system path is still present. Neuron2, can you do something to load it from the same directory than DGMVCDecode.dll, or at least issue a meaningful error message when it cannot be loaded? It's not urgent, but imo something must be done for the final version, as currently the situation is confusing for the new users, because there is nothing to inform them of the necessity to properly install the Intel DLL.

[Guest]

Ah, changing your perfect priorities now, eh? :p

I will look into it. Tell me, as I am new to all this Intel stuff, where does that DLL normally come from for users? Is it part of Windows, part of an Intel driver, part of the Media SDK, ...?

[Sharc]

It's part of the Intel Media SDK, AFAIK.
I am on Windows 7/64 and had to put it into the SysWOW64 folder in order to "forget" it.

[Nico8583]

This DLL must be in a path described in environment variable path like %SystemRoot%\system32,%SystemRoot%,etc...
When you install Intel Media SDK, it adds C:\Program Files (x86)\Intel\Media SDK 2013 R2\bin\x64 and C:\Program Files (x86)\Intel\Media SDK 2013 R2\bin\win32 to environment variable path
But I don't know if it must be register via regsvr32 or not :confused:

[Guest]

For now I have included libmfxsw32.dll in the ZIP file and in the instructions I say to copy it to your system directory. Maybe later I will do something more intelligent but I am not totally free because of the Intel restrictions.

"Copy the included libmfxsw32.dll to your c:\Windows\System32 directory for 32-bit Windows,
or your c:\Windows\SysWOW64 directory for 64-bit Windows."

[r0lZ]

Ah, changing your perfect priorities now, eh? :pNot really. I just think that dealing with the intel DLL properly is important, and should be in the todo list, but not necessarily at the first position.

Indeed, I confirm that your filter works fine only if the Intel DLL is copied in syswow64, or if it is in the same directory than the AVS script. Of course, the second solution is not acceptable. I wonder if it is possible to locate it and pre-load it in memory if it is in the same directory than the plugin. That way, it will not be necessary to install the intel SDK the official way, and it will be sufficient to just copy the two DLLs somewhere. Honestly, I don't know if it's possible. (I know however that it's not possible with pistacho's DLL.)

Please forget it for the moment, and continue to implement the more important things...

[Guest]

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.

[r0lZ]

Why two DLLs? I checked dependencies and it seems only libmfxsw32.dll is needed. What other one are you talking about?Your DLL, the avisynth source. I would like to have the possibility to leave them grouped together, in the same directory. Unfortunately, usually, the avisynth plugins are not placed in the system PATH. It's why I suggest to try to find a way to pre-load the intel DLL. It seems that that doesn't work. Not a big deal.

Rather than get bogged down in this, let's move on and possibly revisit it, as you suggest.
I agree. Other things are more important.

[Nico8583]

I agree. Other things are more important.
At this rate the "to do list" will quickly decrease :D

[LoRd_MuldeR]

Indeed, I confirm that your filter works fine only if the Intel DLL is copied in syswow64, or if it is in the same directory than the AVS script. Of course, the second solution is not acceptable. I wonder if it is possible to locate it and pre-load it in memory if it is in the same directory than the plugin.

It's simply because of Windows DLL search order. If a DLL is not loaded explicitly via LoadLibrary() and with a full path, then the standard DLL search order applies!

This means Windows will look at those directories:

1. The directory where the current program's EXE file resides
2. The System32 directory (Syswow64 for 32-Bit programs running on Win64)
3. The Windows directory
4. The current directory (this one is skipped with "safe" DLL loading enabled)
5. The directories in your PATH environment variable

This means that if the application loads DLL X (e.g. the Avisynth plug-in) from some directory, and DLL X depends on another DLL Y (e.g. the Intel DLL), then Windows will not search for DLL Y in the directory where DLL X is located :eek:

But it will, eventually, look in the "current" directory - which probably is why it works if you put the Intel DLL into the folder where the Avisynth script is located (assuming that one becomes the application's "current" directory).

Of course it also works if you put DLL Y into the System directory or into the directory where the program's EXE file is located. One workaround would be modifying DLL X to not depend on DLL Y, but instead make DLL X load DLL Y at runtime.

When DLL X uses LoadLibrary() at runtime, it can load DLL Y from wherever it wants to. So it could, for example, determine it's own module path and then try to load DLL Y from exactly that directory.

[r0lZ]

Thanks for the clarification, Lord, although I did know that.
And, yes, it seems that avisynth changes its CD to the directory containing the AVS script. I use that feature often to test a new avisynth filter without having to install it in the avisynth plugins directory or type its full path. It works in the case of the DGMVCDecode and libmfxsw32 DLLs, but it's not a practical solution.
One workaround would be modifying DLL X to not depend on DLL Y, but instead make DLL X load DLL Y at runtime.

When DLL X uses LoadLibrary() at runtime, it can load DLL Y from wherever it wants to. So it could, for example, determine it's own module path and then try to load DLL Y from exactly that directory.
It's exactly what I suggested. But in our case, that means that DGMVCDecode.dll must know the path of the directory where it is located and from where it is loaded by avisynth, to search for libmfxsw32.dll in that location. I don't know if it's possible. And libmfxsw32.dll must also support to be loaded with LoadLibrary(). Is it the case of all libraries?

In the worse case, it will be necessary to copy the intel DLL in system32/syswow64. I don't like that much, as touching the system folders without a good reason is always a bad thing, and anyway, I prefer standalone or portable installations. Currently, my GUI builds a batch file that must be launched to compute the output file, and it adds its toolset folder to the PATH in that script. With that trick, it is possible to modify locally the system PATH variable to include the toolset, without having to modify it in the whole system. That works pretty well, but that means that the avs script cannot be encoded by another application (such as for example your Simple x264 Launcher), because it will not have the correct PATH. It's why I would like a solution for that problem.

Anyway, that DLL path problem is for later.

[LoRd_MuldeR]

But in our case, that means that DGMVCDecode.dll must know the path of the directory where it is located and from where it is loaded by avisynth, to search for libmfxsw32.dll in that location. I don't know if it's possible.

Call GetModuleFileName() (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683197%28v=vs.85%29.aspx) with hinstDLL (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx) :)

(Doen't give you the DLL's directory, but the full path of the DLL file itself. But extracting the desired path should be trivial)

[Guest]

Do you have working code that I can put in an Avisynth filter DLL that prints the path of that DLL file? If so, I can temporarily change the current directory for the IM SDK init to allow it to find the co-located libmfxsw32.dll.

[jdobbs]

Thanks for all the hard work DG. I'm setting up for testing... exciting stuff.

[Guest]

Do you have working code that I can put in an Avisynth filter DLL that prints the path of that DLL file? If so, I can temporarily change the current directory for the IM SDK init to allow it to find the co-located libmfxsw32.dll. I made something that works:

char dllpath[1024];
HMODULE hm = NULL;
AVSValue __cdecl Create_AVCSource(AVSValue args, void*, IScriptEnvironment* env);

if (!GetModuleHandleExA(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS |
GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
(LPCSTR) &Create_AVCSource,
&hm))
{
int ret = GetLastError();
fprintf(stderr, "GetModuleHandle returned %d\n", ret);
}
GetModuleFileNameA(hm, dllpath, sizeof(dllpath));
Now I will try changing the current directory to there and see if the libmfxsw32.dll can be loaded from there.

@jdobbs

Thanks! It's always a pleasure to work with you.

[jdobbs]

It seems to work fine... I just created a test with a 3 minute "Road Runner" cartoon. All works as it should. One note, though, I noticed that if I try to open the AVS in MPC, and the source file name is misspelled, it hung and required me to kill it from Task Manager. But that's a minor thing.

Cool.

[Guest]

OK, I'll fix that. Thanks for reporting it.

On the libmfxsw32.dll loading, the Intel Media SDK just will not load from a direct specified path, or using the method I described above. I'll put this on the back burner and maybe ask at the Intel forum about it later.

[r0lZ]

Pity. But thanks for having tried.

[Guest]

Never mind, I got it working to load libmfxsw32.dll from the plugin folder. :p

New beta coming shortly...

[r0lZ]

Great!
I will not test it today, because I go to a fiesta soon, but I will check it tomorrow...

[Guest]

Have fun at your fiesta. I wish I could join you!

Please re-download dgmvcsource.zip to get the new beta 3. It fixes jdobbs' reported problem and it loads the libmfxsw32 from the Avisynth plugin directory. It won't look elsewhere, so it has to be there.

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

[Guest]

I've reverse engineered the muxing required to combine streams. Here is a schematic of how the muxing is done, showing all the NALUs and where they come from.

base combined dependent
------------------------------------------------------------------

---------------------------------
9 9
24
7 7
15 15
8 8
8 8
5 5
5 5
5 5
5 5
5 5
5 5
20 20
20 20
20 20
20 20
20 20
20 20
---------------------------------
repeat for all access units

Now I will write a stand-alone combiner to test this and then implement it in the filter.

[Guest]

I will make the first source code release when the separate stream support is complete.

[Reel.Deel]

Hi neuron2, just tried beta 3 with the included sample and everything seems good so far.
one very small thing, the examples in readme name the included sample as "combined_mvc.264" when it should be "combined.264".
Regardless good work! :)


P.S. looking forward to DGDecQS! :-D

[Guest]

P.S. looking forward to DGDecQS! You are very naughty. No dessert for you.

[LoRd_MuldeR]

Do you have working code that I can put in an Avisynth filter DLL that prints the path of that DLL file?

#include "targetver.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

HMODULE g_instance;

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
g_instance = hModule;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

/*Returns the directory where *this* DLL is located
__declspec(dllexport) int getDllDirectory(wchar_t *outBuffer, size_t len)
{
size_t i = GetModuleFileNameW(g_instance, outBuffer, len);

if((i < 1) || (i == ERROR_INSUFFICIENT_BUFFER))
{
return 0;
}

while(i > 0)
{
wchar_t c = outBuffer[i];
outBuffer[i--] = L'\0';
if((c == L'\\') || (c == L'/'))
{
return 1;
}
}

return 0;
}

If so, I can temporarily change the current directory for the IM SDK init to allow it to find the co-located libmfxsw32.dll.

I think AddDllDirectory() would be a better choice than relying on "current" directory.

[Guest]

Too late, I already released a beta with my own implementation. But thank you anyway.

[jdobbs]

I like the way it works too... all I have to do is put the two dlls in the same folder and point to dgmvcsource.dll with LoadPlugin().

Thanks.

[Sharc]

The plugin or avisynth seems to report half frame rate only i.e. 11.988fps (12000/1001) for a 23.976 MVCcombined footage.
(It gets adjusted when I set --fps 23.976 in x264 for encoding).

If at all, I think it should actually report double the framerate because a stereo combo consists of the left and right picture or frame..... :confused:

[Guest]

The plugin or avisynth seems to report half frame rate only i.e. 11.988fps (12000/1001) for a 23.976 MVCcombined footage. I'm not seeing that. Please give me your script.

[Sharc]

I'm not seeing that. Please give me your script.
Script:
Video = DGMVCsource("c:\Users\Movies\Test_Movie\3-D samples\DG_combined.264",frames=1350,view=0)
V1 = SelectEven(video)
V2 = SelectOdd(video)
return StackHorizontal(horizontalreduceby2(V1),horizontalreduceby2(V2))

Command:
x264.exe "c:\Program Files Video\DGMVCSource_.avs" --bluray-compat --crf 20 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "C:\temp\scratch\DGMVCsourceTox264.h264"

[Guest]

OK, I see. I will double the frame rate reported to Avisynth when delivering interleaved. Thank you for pointing it out.

[Sharc]

I think it should just be reported as 23.976fps - i.e. same as base view. What irritated me was the 11.988 fps.

[vivan]

I think it should just be reported as 23.976fps - i.e. same as base view. What irritated me was the 11.988 fps.If it will report 23.976 fps, then SelectOdd/SelectEven will halve it and resulting fps will be 11.988. That's exactly what's happening now.

[Sharc]

I see, thanks.

[jdobbs]

I see, thanks.I always add "AssumeFPS()" as the last line in the file when I know the source framerate.

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

[r0lZ]

Yes, a buffer overflow is a good candidate for that kind of erratic errors.
I'll post a sample from Paperman for you, but without guarantee that you'll see anything wrong.

[Guest]

Thanks for the sample in PM. Right now I am ripping Escape from Planet Earth and will test with that initially.

[Sharc]

In order to speed up the plugin+encoder testing time significantly I think one could reduce the output resolution of the encodes, e.g. to 1280x720 or even lower, rather than keeping it at full HD. This should not adversely affect the validity of the test regarding glitches. Correct or am I missing something?

[Guest]

In order to speed up the plugin+encoder testing time significantly I think one could reduce the output resolution of the encodes, e.g. to 1280x720 or even lower, rather than keeping it at full HD. This should not adversely affect the validity of the test regarding glitches, correct? Correct. But I would ask if encoding is even required to see the issue. I am testing right now.

[Sharc]

oooops! I just run into an issue:
- BD: Man of Steel, Base view garbled about 30 minutes into the movie
- Decoder: DGMVCDecode.dll beta 4 (I missed your update)
- Decoder Input: separate elementary streams
- Encoder: FRIM mvc

I'll try with beta 5 now.

Edit:
Same problem with beta 5 (at slightly different position it seems).
As I did this movie successfully before with FRIM (pipe), I tend to believe that the problem is with DGMVCdecode ...:o

[Guest]

I found an underrun condition on the reader/writer that I have fixed. Testing further locally before pushing a new beta.

[frencher]

I created a video with AVC / MVC flow and it seems that the MVC view is not dependent on the stroke order in any case we can put 2 different views, very strange. :stupid:
Someone can tell me why?
AVC+MVC - Not dependent view.m2ts (http://ul.to/79mi47e2)

[Guest]

I created a video with AVC / MVC flow and it seems that the MVC view is not dependent on the stroke order in any case we can put 2 different views, very strange. Sorry, I don't understand your report.

[r0lZ]

I suppose he wants to say that we can use the AVC stream of one BD with the MVC stream of another one. Indeed, it's not a good idea, but nothing can stop us to do strange things like that.

(@Frencher: Si je n'ai pas compris ton post, dis-le en français, et je traduirai.)

[frencher]

I suppose he wants to say that we can use the AVC stream of one BD with the MVC stream of another one. Indeed, it's not a good idea, but nothing can stop us to do strange things like that.

(@Frencher: Si je n'ai pas compris ton post, dis-le en français, et je traduirai.)
@r0lZ ;)

Yes

What I mean is that the AVC standard / MVC was created to slow the development of software.
Is that we expect in the near future (Ultra HD 4k 8k) to see the same flower x265/UltraMVC system with a folder like "/ SSIFUltra/00001.ussif"
In brief the MVC view is not so dependent upon ???

[Guest]

@frencher

I'm sorry but again I find your post to be unintelligible. Can someone please explain what he's talking about?

If it's OT, take it elsewhere!

[frencher]

@frencher

I'm sorry but again I find your post to be unintelligible. Can someone please explain what he's talking about?

If it's OT, take it elsewhere!

You understand the source code Intel SDK and see how it works.
I wanted to know if it uses very basic view for decoding dependent view knowing that we just use two different videos in AVC / MVC stream?
It is true that this is a little off topic but it is to understand the principle of decoding.
It was also a sample for your test to improve DGMVCSource.
You can delete my posts relating my question if you really find out about and apologize.

In french
Vous comprenez le code source Intel SDK et vous voyez comment il travaille.
C'était pour savoir si celui-ci utilise bien la vue de base pour décoder la vue dépendante sachant que l'on peu utiliser deux videos différentes dans un flux AVC/MVC ?
C'est vrai que c'est un peu hors sujet mais c'est pour comprendre le principe du décodage.
C'était aussi un échantillon pour que vous puissiez le tester pour améliorer DGMVCSource.
Vous pouvez supprimer mes posts relatant ma question si vous les trouvez vraiment hors sujet et m'en excuse.

[Guest]

I still don't understand. I just don't know what you mean by "very basic view". Anyway, the decoder doesn't know we have two files, because I combine them before passing to the decoder.

[Thalyn]

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

I'm a little reluctant to mention other decoders (the whole, "But X does it like Y - why don't you do it that way!?" whining) and though I've already done it, yes I have tested with FRIMSource. No issue presented using the two separate input streams (cache set to 4, in case it's relevant in any way, shape or form).

Interestingly, the transcode I ran last night bombed out as soon as it ticked to 5:34, or what should be frame 8,008. MeGUI is apparently less tolerant than VirtualDub of whatever is going AWOL.

[Tom Keller]

@neuron2

I know, there are more mandatory things to do and (maybe more... but hopefully no) problems to solve... but just out of curiosity:

Are you planning on adding direct support for *.mts files (created by MPEG4-MVC/H.264 AVCHD 3D camcorders... like Sony's HDR-TD10, or like Panasonic's Z10000) in a future release of DGMVCDecode?

Btw... seems like 'frencher' uses Google to translate his native French text into English. Since automatic translations are far from being perfect (or even 'good'), it's no big surprise, that he's hard to understand ;) . Maybe 'r0lZ' can come to the rescue... again?

[Guest]

As I said MANY TIMES I don't want to discuss future stuff in this thread. Is it so hard to understand? :devil:

[Guest]

I'm a little reluctant to mention other decoders (the whole, "But X does it like Y - why don't you do it that way!?" whining) and though I've already done it, yes I have tested with FRIMSource. No issue presented using the two separate input streams (cache set to 4, in case it's relevant in any way, shape or form).

Interestingly, the transcode I ran last night bombed out as soon as it ticked to 5:34, or what should be frame 8,008. MeGUI is apparently less tolerant than VirtualDub of whatever is going AWOL. It's broken, OK. I am fixing it. I know what the problem is and I am working on it. Please be patient or use another filter if you have immediate needs.

[Guest]

I just found and fixed the bug. Expect a new beta tomorrow morning.

[Selur]

Nice!
Btw. will DGIndexMVC also have an option to check if the system supports it?

[r0lZ]

In french
Vous comprenez le code source Intel SDK et vous voyez comment il travaille.
C'était pour savoir si celui-ci utilise bien la vue de base pour décoder la vue dépendante sachant que l'on peu utiliser deux videos différentes dans un flux AVC/MVC ?
C'est vrai que c'est un peu hors sujet mais c'est pour comprendre le principe du décodage.
C'était aussi un échantillon pour que vous puissiez le tester pour améliorer DGMVCSource.
Vous pouvez supprimer mes posts relatant ma question si vous les trouvez vraiment hors sujet et m'en excuse.
Here is my (approximative) translation of his message:
You [Neuron2] understand well how the Intel decoder works.
I want to know if it uses really the base view to decode the dependent view, given the fact that it is [theoretically] possible to put two totally different videos in the two streams.
It is true that this question is somewhat out of topic, but I want to understand the principle of the decoding.
[The next sentence is very obscure for me, even in French:] It's also a sample [or idea?] for you to improve DGMVCSource.
You can delete my posts related to this question if you think they are really OT. In that case I'm sorry.

I can already reply that yes, in the 3D BDs, the dep view is really dependent of the base view. They did that that way because it's a good way to gain disc space. There is only a few differences between the base and dep views, and it is necessary to encode that differences only in the MVC stream. It's why the demuxed MVC file is always much smaller than the h264 file of the base view.
And yes, IMO, that question is out of topic, as it is not related directly to the development of DGMVCSource.

[r0lZ]

I just found and fixed the bug. Expect a new beta tomorrow morning.
Might be too late, but I've finished to examine the test encodes I did during the night.

I have encoded 10 times Paperman with the combined.264 file created with MVCCombine: No problem at all.

I have also encoded 10 times the same movie but this time with the 2 ES and the internal combiner. There are errors in 3 files. (It is easy to find them, because the size of the files are different.) Two times, some garbage appears during one GOP or two, and one time, the movie stops abruptly and is followed by totally black frames.

Given the fact that these errors are different at each encode, I guess that the buffer bug you have fixed is indeed the cause of the problem. Is it in the code you have added to combine the two streams? It it's the case, you have probably fixed the right bug. :-)

I will repeat that test when the new beta will be available...

[Tom Keller]

As I said MANY TIMES I don't want to discuss future stuff in this thread. Is it so hard to understand? :devil:
I must have skipped those passages - sorry :( . I didn't want to bother you. Keep up the good work!

[Thalyn]

It's broken, OK. I am fixing it. I know what the problem is and I am working on it. Please be patient or use another filter if you have immediate needs.

Better too much information than not enough. Please don't confuse that for impatience - I understand how long these things can take, especially to do it right.

I'm pretty sure everyone else here also understands that, and we all appreciate your efforts. You're helping us out and we're just doing the best we can to return the favour; albeit without actually being able to program.

I just found and fixed the bug. Expect a new beta tomorrow morning.

Looking forward to giving it a run through. I've kept the streams to make proper comparisons.

[allanlee]

@neuron2

I know, there are more mandatory things to do and (maybe more... but hopefully no) problems to solve... but just out of curiosity:

Are you planning on adding direct support for *.mts files (created by MPEG4-MVC/H.264 AVCHD 3D camcorders... like Sony's HDR-TD10, or like Panasonic's Z10000) in a future release of DGMVCDecode?

Btw... seems like 'frencher' uses Google to translate his native French text into English. Since automatic translations are far from being perfect (or even 'good'), it's no big surprise, that he's hard to understand ;) . Maybe 'r0lZ' can come to the rescue... again?

To my knowledge, MTS is pretty similar to m2ts or ssif stream, TSMuxer and eac3to can already deal with such format. So all you need to do is demux into elementary streams and feed them into either MVCCombine or directly DGMVCSource.
I tested that TSMuxer and eac3to work pefectly with the 2D MTS generated by Sony and JVC cameras. But since I don't have a 3D MTS sample file -- maybe you can have a test? :p

[Guest]

Might be too late, but I've finished to examine the test encodes I did during the night.

I have encoded 10 times Paperman with the combined.264 file created with MVCCombine: No problem at all.

I have also encoded 10 times the same movie but this time with the 2 ES and the internal combiner. There are errors in 3 files. (It is easy to find them, because the size of the files are different.) Two times, some garbage appears during one GOP or two, and one time, the movie stops abruptly and is followed by totally black frames.

Given the fact that these errors are different at each encode, I guess that the buffer bug you have fixed is indeed the cause of the problem. Is it in the code you have added to combine the two streams? It it's the case, you have probably fixed the right bug. :-)

I will repeat that test when the new beta will be available... My fix stopped one problem, as it started decoding past the point where it was going nuts before. But later in the stream the decoder threw an exception and crashed. I am making the combined file and will compare the streams delivered in the two cases to see what is going wrong in the combiner.

Yes, I do plan to add container support.

[Guest]

Oy, fseek() does not work for files >16GB. Replacing with _fseeki64(). Waiting for 70,000 frames each test run is inconvenient but there is no other way. I am hopeful...

[Guest]

Seems to be working fine now. I have to teach a swimming lesson and when I get back I'll post a new beta.

[r0lZ]

Good news! But it is time to sleep here. I'll test your beta tomorrow...

[Guest]

Here is beta 6 with bug fixes and performance improvements for the combiner.

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

If you think Franks's pseudo seeking is useful, that would be easy to add. I'm thinking more in terms of unlimited full frame-accurate random access without long delays when seeking. Isn't that a requirement for a correct source filter?

[Thalyn]

Using exactly the same "Escape from Planet Earth" source, I have good news and bad news.

The good news is that it appears all the errors I was encountering previously are gone and the transcode went through to the end. Previewing with VirtualDub was also happening in constant real-time, so viewing without transcoding was much easier on the brain.

The bad news is that a brief glitch (on both AVC and MVC frames, starting with the MVC) hit at frame 14,100 (~6,000 frames past where it previously stalled) and affected 24 frames, followed by the output going completely blank at frame 22,895 - and that's how it stayed for the rest of the movie. What makes these two occurrences particularly unusual, at least to me, is that the glitching at frame 14,100 appeared in both the x264 encode and when previewing with VirtualDub, however only the transcode went blank while VirtualDub continued playing as normal. I'm running the transcode again to see if that's an isolated occurrence and will update shortly when I know more.

Update:
Second transcode attempt has passed frame 22,895 without speeding up to over 8x realtime, so I can only assume it's not compressing blank frames this time. I'll let it run to the end (approximately 80 minutes) and see what else, if anything, has changed.

Update 2:
Dangit. Glitch at 14,100 still occurred (as I suspected), but unfortunately so did the blanking. This time at frame 26,066. I may not know much about modern programming, but I know inconsistency is a pain to diagnose... sorry.

[Guest]

Make sure you clear your cache and re-download beta 6 as I had a bad version up for quite a while. I don't see any issues with that disk on my side.

I may not know much about modern programming, but I know inconsistency is a pain to diagnose... sorry. You could make it a lot easier by giving your full script.

There is some simulated blocking drawn by the artist at some scene changes. I hope you aren't confusing them with glitches.

Video goes black if your frames parameter is too low. You may have to double the frames parameter in interleaved mode depending on your script.

[Thalyn]

Re-downloading now just in case - I would have originally grabbed it shortly after your edit so it could be the bad version. I'll run it again when I get an idle moment on my rig as I like to test speed as well, but that may not be for a couple hours yet. Will keep you posted. I'll also include the script I used at exactly the time I started it, just to make sure I'm not doing anything daft.

I'm fairly confidant that they're not deliberate "glitches" in the output. My connection is happy today (touch wood!) so these are exactly what I was seeing: Frame 14,099 (fine) (http://s204.photobucket.com/user/Lord_Thalyn/media/Fine_zps821a987d.png.html), Frame 14,100 (going) (http://s204.photobucket.com/user/Lord_Thalyn/media/Going_zps6251ccdb.png.html), Frame 14,101 (gone!) (http://s204.photobucket.com/user/Lord_Thalyn/media/Gone_zps8903bb3c.png.html)

[r0lZ]

If you think Franks's pseudo seeking is useful, that would be easy to add. I'm thinking more in terms of unlimited full frame-accurate random access without long delays when seeking. Isn't that a requirement for a correct source filter?Ideally yes, but that's not necessary if you just want to transcode. But it's very useful to preview the video or to split a movie in several independent parts.
I suppose that will require to build an index, and if it's time consuming, I propose to add an option to skip the index creation and, of course, keep the current behaviour.

Now, I will test b6...

[Thalyn]

Well, I'm at a loss. I keep getting that exact same error in the exact same place, and every time I run it I get slightly further through the transcode before it goes black (up to 57,116 now!). If you [Neuron2] aren't having an issue than it's probably safe to say that the issue is at my end. I'm not exactly sure what it is that's causing it but that's all I can come up with.

That being the case, it's possible that further feedback from me won't necessarily be useful if I'm unable to figure out what the problem here is and correct it.

The exact script I'm using is as follows:
## *Load plugins
LoadPlugin ("T:\BRD\DGMVCDecode.dll")
## *Load video files.
Source = DGMVCSource ("T:\BRD\Escape.264", "T:\BRD\Escape.MVC", view = 0, frames = 256696) # Frames is doubled
## *Crop stream
Source = Source.Crop (0, 128, 0, -128)
## *Split interleaved frames
Left = SelectEven (Source)
Right = SelectOdd (Source)
## *Merge to HOU.
HOU = StackVertical (Left.BilinearResize (1920, 412), Right.BilinearResize (1920, 412))
## *Output.
return HOU
A fully-updated MeGUI is being used to do the transcode.

[allanlee]

I'm thinking more in terms of unlimited full frame-accurate random access without long delays when seeking. Isn't that a requirement for a correct source filter?

Adding the frame-accurate seeking is fantastic! And I agree that if indexing (like DGNV) is required, having a method to skip it (and remain in sequencial access mode) is also very useful.
Thanks for the great work! Tested b6 on several sample clips and so far no probem. :-)

[r0lZ]

Tests done. I have again transcoded 10 times the Paperman short movie, with the 2 ES as input, and everything went fine. So, for me, the bug is fixed. :-)

Well, I'm at a loss. I keep getting that exact same error in the exact same place, and every time I run it I get slightly further through the transcode before it goes black (up to 57,116 now!). If you [Neuron2] aren't having an issue than it's probably safe to say that the issue is at my end. I'm not exactly sure what it is that's causing it but that's all I can come up with.Could it be a bad rip?

[Thalyn]

It's possible but unlikely. I've used the same files with other source filters without issue, and even as the input for MVCCombine which I then fed through beta 3 without a problem.

Guess it won't hurt to rip it again and try, though, just in case.

[Nico8583]

Have you tried without crop and with a resize filter other than bilinearresize ?

[Thalyn]

I really should do a "essentials" run just to make absolutely sure.

That having been said, re-ripping it is proving awkward - I'm trying to ensure I use a different method to what I used previously (first rip simply used TSMuxer to extract from the SSIF with AnyDVD HD active), and in doing so I found that MakeMKV would fail every time regardless of which of my drives I used. Given that, I can't say for certain that it wasn't a bad rip, so I can't say with any certainty that my feedback using this particular title is of any actual value. I'm trying working from the M2TS files to see if there's any change.

However, I think I might step back from this thread. Given I don't trust the value of my own feedback I can't reasonably expect it to be of any value to Neuron2. I do intend to keep following and testing, though - just quietly.

[Guest]

@Thalyn

You're always welcome here to post your feedback and I will certainly pay attention and try to help you. At the moment it seems you may have some system issues, as I experience no issues with your title and no-one else has reported further issues. When you have evidence of an issue in DGMVCSource(), or course, I encourage you to bring it up.

@all

I have released my stand-alone MVC streams combiner (open source equivalent of MVCCombine) with source code:

http://neuron2.net/dgmvccombine/dgmvccombine100.zip

[r0lZ]

Just did a new short test with Puppy (a short animated movie from Despicable Me 2), and... the last part of the movie, corresponding to the end credits, is totally blank! I'm encoding it again with FRIMSource, to verify if it works, and I'll report the result later. I may have to do a lot of tests to verify, so don't expect a confirmation today...

I have released my stand-alone MVC streams combiner (open source equivalent of MVCCombine) with source code:

http://neuron2.net/dgmvccombine/dgmvccombine100.zip
Is it exactly identical to the one embedded in DGMVCDecode? I can perhaps combine several movies with your version and the original MVCCombine.exe, and compare them to see if there are differences.

[Guest]

Just did a new short test with Puppy (a short animated movie from Despicable Me 2), and... the last part of the movie, corresponding to the end credits, is totally blank! I'm encoding it again with FRIMSource, to verify if it works, and I'll report the result later. I may have to do a lot of tests to verify, so don't expect a confirmation today... OK, please keep me informed. And if you can give me the stream for testing I can look at it. Make sure you specify the correct number of frames, and see the new beta linked below, which changes how the frames parameter is handled.

Is it exactly identical to the one embedded in DGMVCDecode? I can perhaps combine several movies with your version and the original MVCCombine.exe, and compare them to see if there are differences. Yes, they use an identical algorithm.

Here is beta 7, which internally doubles the frames parameter when delivering interleaved (view= 0).

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

[Guest]

Please re-download beta 7 if you already got it. I increased some timeouts that might have explained a clip going prematurely black.

[r0lZ]

404 Not found!

Unfortunately, I can confirm the problem: It is OK when encoded with FRIM, but the end credits are blank for the two tries I did with DGMVCSource. Luckilly, this time, the problem seems reproducible. I will try to upload the 2 ES soemwhere, but be patient. I have to upload around 1GB, and I have to go now...

Small request: Can you add the version of the build in the files properties of the DLL? Currently, it is always 1.0.0.0. And, afaik, the file properties are the only way to verify if we use really the latest version.

[Sharc]

Can't access the beta 7. 404 file not found.

Edit: r0IZ was faster, sorry.

[r0lZ]

Please re-download beta 7 if you already got it.Can you upload it? The link is still dead.
[EDIT] Shark was faster.

[Guest]

404 Not found! Sorry, fixed.

Unfortunately, I can confirm the problem: It is OK when encoded with FRIM, but the end credits are blank for the two tries I did with DGMVCSource. Luckilly, this time, the problem seems reproducible. I will try to upload the 2 ES soemwhere, but be patient. I have to upload around 1GB, and I have to go now... OK, with the streams I can fix it if it still happens with the b7 redownloaded.

Small request: Can you add the version of the build in the files properties of the DLL? Currently, it is always 1.0.0.0. And, afaik, the file properties are the only way to verify if we use really the latest version. Yes, for future betas.

[r0lZ]

The problem persists with b7. I will upload the two ES for you when I'm not at home, and I should give you the link when I'm back, in 5 hours or so.

[Sharc]

beta 7: 51'000 frames transcoded with DGMVCSource beta 7 + FRIMEncode.
No issues so far, way past the position where I had the former failure with beta 5.
Ongoing ......

Edit:
And oh yes, true seeking would be great, option for trim, perhaps even cutting a snippet ....

[Guest]

The problem persists with b7. I will upload the two ES for you when I'm not at home, and I should give you the link when I'm back, in 5 hours or so. Tested with your files and the problem is clear. The dependent stream runs out of frames when the credits start, presumably because the credits are not in 3D. The EOF on the dependent stream currently stops things. Fixing...

[r0lZ]

Tested with your files and the problem is clear. The dependent stream runs out of frames when the credits start, presumably because the credits are not in 3D. The EOF on the dependent stream currently stops things. Fixing...Oh, I was far to imagine that it is possible to mix 2D and 3D in the same MPLS! The fix is welcome. :-)

[Guest]

That was just a guess. :) Now I am back from the pool I will find out what is really happening.

[Guest]

My end of stream handling was defective and could lose up to 3MB of the end of the stream. I wasn't flushing the combined stream buffer properly. I have fixed it and offer you beta 8:

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

I have removed the sample files to make downloads faster. If you need them, get them from an earlier beta, or use your own source files.

Also note that I have updated DGMVCCombine to version 1.0.1 with the same fixes:

http://neuron2.net/dgmvccombine/dgmvccombine101.zip

[Sharc]

Thank you for the new beta.
No issues so far with beta 8 and separate streams.
Anything we should pay special attention to?

Is the speed bottleneck given by the decoding process?

For View=0: Do the even frames always present the base view, and the odd frames the dependent view?

[r0lZ]

For View=0: Do the even frames always present the base view, and the odd frames the dependent view?Yes. Swap the "left" and "right" clip names in the SelectEven and SelectOdd commands to restore the common order (left first) if the order is inverted in the original BD.

[Sharc]

Yes. Swap the "left" and "right" clip names in the SelectEven and SelectOdd commands to restore the common order (left first) if the order is inverted in the original BD.
ok, that's what I assumed. No problem as it is.
I was just in doubt if the decoder would eventually read from the stream (flag or similar) which one is left or right and make the assignment accordingly.

[r0lZ]

That info is not in the stream. Only in the MPLS.

[r0lZ]

Finally got some time to test b8. It's better, but the problem is not totally fixed.
I have encoded Puppy again. The end credits are now partially visible, but they are cut at approx 4:25, about 8 seconds before the end of the movie. So, it seems that the eof fix is not sufficient. I can do other tests if you need so...

[Guest]

Third time is the charm! I hope. Anyway, for me beta 9 now delivers all the frames from your streams:

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

[r0lZ]

Indeed, this one is OK. I'll do some other tests in the next days, but I think you can go on with the next thing in your todo list. :-)

[Guest]

Indeed, this one is OK. I'll do some other tests in the next days, but I think you can go on with the next thing in your todo list. :-) Sweet, thank you for your testing. Your provision of this short really sped things up for me because I didn't have to wait over an hour each time to hit EOF.
:thanks:

I want to make a source code drop as I promised and then I'll move on with my to-do list. Please let me know if you need anything for immediate usability.

BTW, DGMVCCombine didn't require an update. It was a problem only in the source filter; it wasn't signaling the decoder to take the last partial buffer of combined data (after EOF). Things should be robust now.

[r0lZ]

No, afaik, I can use the plugin as it is.

Can I assume that the parameters will not change? Or at least that, if it is necessary to add new parameters, that they will be added after the current ones, for compatibility reasons?

[Nico8583]

I have made a quick test with hardware acceleration enable (with videofan3d plugin) and result is very smooth on my i5-3360M. Without hardware acceleration, display is slow, I don't have 23.976fps, all frames don't appear on screen but with hardware acceleration, video play like a charm, very smooth ;) so I think hardware acceleration will be a good improvment :)
I don't have tried x264 encode for the moment...

[Guest]

Can I assume that the parameters will not change? Or at least that, if it is necessary to add new parameters, that they will be added after the current ones, for compatibility reasons? Yes, I will follow that protocol.

[Guest]

I think hardware acceleration will be a good improvement. HW acceleration is the next item on my to-do list, but thank you for reminding me about it. :p

[Nico8583]

HW acceleration is the next item on my to-do list, but thank you for reminding me about it. :p
It was only to tell you that is not useless :D

[Sharc]

beta9 / separate files input: It appears that the last few frames (10....20) of the source don't get encoded. The black filler frames at the end seem to kick in too early.
I am using DGIndexNV for playback.

[r0lZ]

Damn! I haven't noticed that with my test, because the last frames of the original "Puppy" movie are black anyway. I will test with other streams...

[Sharc]

Hmmm.... strange. I can't reproduce it now.
It got missing end frames in repeated tests when I posted, but now running the same script and cmd, all seems to be good.
Unless someone else discovers something similar, let's assume that the issue was just a local one here....

Edit:
Ugggh ... it appears that my all-clear came to early. Now it happened again - even worse. At about 80% of the file the black filler frames start to kick in. It seems not to be reproducible though :confused:

[Guest]

That's surprising. I will make a debug build for you and post it in a little while.

[Guest]

Here is a debug load:

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

To debug with it first get the DebugView utility here:

http://neuron2.net/dbgv.zip

Open that and do Edit/Filter and then put this in the include field: DGMVCSource
Then do OK.

Now start your decode. You should see a message immediately that DGMVCSource has been instantiated. At the completion of the encode, wait 15 seconds before doing anything else. If you see a timeout message tell me what it says (it gives a timeout number and a frame number). Also give your script. Thank you.

[Sharc]

[2592] DGMVCSource: timeout 3 at frame 3218

The encode looks ok, no missing frames at the end.

Script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\DGMVCDecode.dll")
# View Parameter:
# 0 : interleaved
# 1 : base view (AVC)
# 2 : dependent view (MVC)

Video = DGMVCsource("c:\Program Files Video\FRIM\panama.264","c:\Program Files Video\FRIM\panama.mvc",frames=1650,view=0)
V1 = SelectEven(video)
V2 = SelectOdd(video)
return StackHorizontal(horizontalreduceby2(V1),horizontalreduceby2(V2)) # for half SBS x264 input


Edit:
Now I continue with repetitions of the encode until I catch one which fails. Maybe after 10 or 20 attempts ...

[Guest]

It may not fail anymore. :) I lengthened the timeout. Note that the timeout should kick in only when you specify the frames parameter with more frames than the source contains. It may have been triggering falsely before I increased the timeout. And when proper random access is implemented, this whole issue goes away because you won't need to specify frames and the filter will never get requests for frames that don't exist.

[Sharc]

Great. Thanks!

[Guest]

I think I found a way to stop properly without needing a timeout. Testing it...

[Guest]

OK, here is beta 11. Decoding will switch immediately to black frames after the end of stream without needing a timeout. If you ever see a timeout, then we need to investigate that, assuming the stream is not hosed.

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

[Sharc]

beta 11:
[12244] DGMVCSource: timeout 3 at frame 596

No luck ....

Added:
The next attempt went well:
[5624] DGMVCSource: Decoder has delivered all available frames. Setting end of stream EOS.

Added 2:
Failed again:
[6584] DGMVCSource: timeout 3 at frame 2420

I'll PM you a link.

[Guest]

Are you transcoding? I can't believe the encoder would hold up the decoder for 10 seconds but I suppose it is possible. Can you tell me how you are encoding, your command line, etc., so I can try to duplicate this? Thanks.

Maybe I'll just remove all the timeouts.

[Sharc]

Yes, I transcode.
Command:
x264.exe "c:\Program Files Video\DGMVCSource_.avs" --bluray-compat --crf 22 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "out_DGMVCSource-to-x264.h264"
pause
The script is same as posted earlier.

[Guest]

OK, I have your streams you sent in PM. Will try to duplicate your timeout...

[Sharc]

OK, thanks.
I'll be away for about 2 hours now.

[Guest]

I transcoded with your source files and encode line five times without issues. Maybe you have a network drive involved?

[r0lZ]

Are you transcoding? I can't believe the encoder would hold up the decoder for 10 seconds but I suppose it is possible.That can happen due to external conditions, such as heavy disc access during the decoding. In that case, the bottleneck is the speed of the disc, not the transcoding. I have such problems easily with my current hardware and Win8.

Maybe it's time to add a "timeout" parameter? Or at least while the plugin is still under heavy development, so that we can test with other values.

[Guest]

@r0lZ

Have you seen any timeouts?

[r0lZ]

No, but currently, I can't do tests. I hope I'll be able to do a few tests tomorrow...

[Guest]

I'll just remove the timeouts. They serve no purpose now anyway, because I get the end of stream signal from the decode pipeline.

[Guest]

Here is beta 12 with timeouts of 120 seconds. :sly:

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

[r0lZ]

... I get end the of stream signal from the decode pipeline.Does it mean that you know for sure when the movie finishes? If yes, then it might be a good idea to stop adding black frames, even if the user has specified more frames in the parameters. But I'm not sure it's a good idea.

And I wonder what your decoder does if the two streams do not have exactly the same number of frames. Will it truncate the additional frames, or try to decode them anyway? (It's purely an academical question. My GUI passes the lower number as the argument anyway.)

[EDIT] Thanks for b12. :-)

[Guest]

Does it mean that you know for sure when the movie finishes? If yes, then it might be a good idea to stop adding black frames, even if the user has specified more frames in the parameters. But I'm not sure it's a good idea. Good question. Yes, I know for sure when there are no more frames. But you have to return something to Avisynth's GetFrame() call. You can't just block in there. A proper source filter will set vi.num_frames to the correct number, without needing a frames parameter and without requests ever being made for frames that do not exist.

And I wonder what your decoder does if the two streams do not have exactly the same number of frames. Will it truncate the additional frames, or try to decode them anyway? (It's purely an academical question. My GUI passes the lower number as the argument anyway.)
Our behaviors match up, because I end the stream when either the base or dependent streams run out of frames.

[Sharc]

beta 12:
Same again. It seems to stall at some frame, waiting for something. CPU load is almost Nil.
[6572] DGMVCSource: timeout 3 at frame 2420

I seem not to get this with FRIM plugin.

Doing more tests ...

[Guest]

Really strange. I've run your scenario many times. How often does it happen?

[Sharc]

I can have up to say 20 runs without issues. I have also seen it happening ever 2nd or 3rd run. I can't spot a regular or specific pattern. It's weird.

Edit:
I wonder why the timeouts refer to frames >> total number of the source frames (1608) or frames=1650 parameter.
How are the frames counted/numbered?

Edit2:
After 12 successful runs:
[6540] DGMVCSource: timeout 3 at frame 2822
CPU load 0%, very low I/O disc activity.

Yawn .... time for me to go to sleep.

[Sharc]

I can't produce a timeout when running the script in MPC-HC, so far. It seems to produce these random hangers only when frameserving to x264.
I'll try with an different version of x264.

Edit:
No joy. With the latest build of x264 r2389 I got after 12 successful runs
[6100] DGMVCSource: timeout 3 at frame 2950
(I assume that a stereo pair counts as 2 frames?)

[r0lZ]

I have a big problem with b12, when trying to decode The Blue Umbrella with this script:

LoadPlugin("DGMVCDecode.dll")
DGMVCSource("00261.track_4113.264", "00261.track_4114.mvc", 9748, 0)

The script doesn't work when launched from the command prompt. When I try to preview it with AvsPmod, it displays this error message, after its traceback:

AttributeError: AvsClip instance has no attribute 'display_pitch'
And it displays -1 as the current frame number in its GUI. It seems that the plugin cannot decode any more that movie, that I have already decoded without problem.

FRIMSource works fine.

Any idea?

[EDIT] Hum, really strange. I can't get b12 to work with another movie too. So, I've tried b11, then b10 and b9, and I have the same behaviour with all versions! The Source command cannot decode any frame.
I don't understand. Something must have changed in my computer that makes all DGMVCDecode plugins to fail. But I wonder what! I have not changed or installed anything important recently.

[Guest]

@Sharc

In interleaved mode, the printed frame number is doubled. For the timeout, I suppose somehow the two threads are getting into deadlock. I will review the design and add some code to detect deadlocks and give you a new debug version to help us understand what is happening. BTW, I did your encode 200 times straight without issues.

@r0lZ

Well that is baffling. Have you tried rebooting? What happens if you just load the script in VirtualDub?

[Sharc]

I have a big problem with b12, when trying to decode The Blue Umbrella with this script:

LoadPlugin("DGMVCDecode.dll")
DGMVCSource("00261.track_4113.264", "00261.track_4114.mvc", 9748, 0)

The script doesn't work when launched from the command prompt. When I try to preview it with AvsPmod, it displays this error message, after its traceback:

AttributeError: AvsClip instance has no attribute 'display_pitch'
And it displays -1 as the current frame number in its GUI. It seems that the plugin cannot decode any more that movie, that I have already decoded without problem.

FRIMSource works fine.

Any idea?

[EDIT] Hum, really strange. I can't get b12 to work with another movie too. So, I've tried b11, then b10 and b9, and I have the same behaviour with all versions! The Source command cannot decode any frame.
I don't understand. Something must have changed in my computer that makes all DGMVCDecode plugins to fail. But I wonder what! I have not changed or installed anything important recently.
Re-install Avisynth?

[r0lZ]

Damn, that was my fault! :o
I have copied, pasted and modified a command from another script, and I have accidently changed the order of the frames and views parameters. DGMVCSource has just encoded the requested number of frames: 0.
Sorry for the false alarm!

So, now, I am able to do some new tests, and I have tested b12 with The Blue Umbrella. Unfortunately, it seems that there are still a few frames missing at the end of the movie. I am currently investigating the problem, and I will come back here if I find why.

[r0lZ]

Forget my previous bug report. I just did a new test, after having rebooted my PC, and this time, it went OK. The prev encode may have failed because I had still b10 in memory. Anyway, if I encounter the problem again, I will report it here.

[Guest]

@sharc

Would you please re-download beta 12? I have added full debug. If you can run DbgView and when a timeout occurs give me the contents of the DbgView capture buffer. That should tell me what I need to see what is happening.

Thanks!

[Sharc]

I resumed the testing with the re-downloaded beta 12. Surprisingly no timeout/deadlock after about 20 runs.
I'll do more testing later this week.

[Guest]

I did make one small change. :)

Your trace of any timeout that might still occur will be really helpful.

I plan to simplify my interface to the Intel SDK code (eliminating one thread entirely), but what I have should work fine so I'd like to get to the bottom of it.

[Sharc]

OK, good.
I let the cmd batch now loop for a while and save the debug log.

Added:
With another 26 rounds in succession without issues I am very positive that the problem is now solved ...... :cool:

[Guest]

With another 26 rounds in succession without issues I am very positive that the problem is now solved Great to hear! Thank you for your testing.

Onward to interface simplification followed by hardware acceleration...

Anybody need an immediate source code drop or should I wait for the above?

[Nico8583]

Great to hear! Thank you for your testing.

Onward to interface simplification followed by hardware acceleration...

Anybody need an immediate source code drop or should I wait for the above?
Thanks for your work !
No need for source code now for me ;)

[Guest]

Sorry guys, single stream output got broke in b12. So here is b14 (yes I am superstitious) to fix that.

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

[Sharc]

Resuming my favourite test with beta 14 ...... :D

[Guest]

Just in time for beta 15!

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

I added the capability to decode a normal AVC stream (not a combined MVC stream). You just specify like this in the same way as if it was MVC combined:

dgmvcsource("normal_avc.264", "", view=0, frames=1000)

The specified file is examined and the decoder is opened in the correct mode depending on whether the file has MVC startcodes or not. So again, we avoid needing an additional parameter. If a normal AVC file is detected, the view parameter is ignored.

Obviously, DGDecIM is going to need to work on normal AVC files also (and normal VC-1, MPEG2, HEVC). ;)

[Nico8583]

Just in time for beta 15!

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

I added the capability to decode a normal AVC stream (not a combined MVC stream). You just specify like this in the same way as if it was MVC combined:

dgmvcsource("normal_avc.264", "", view=0, frames=1000)

The specified file is examined and the decoder is opened in the correct mode depending on whether the file has MVC startcodes or not. So again, we avoid needing an additional parameter. If a normal AVC file is detected, the view parameter is ignored.

Obviously, DGDecIM is going to need to work on normal AVC files also (and normal VC-1, MPEG2, HEVC). ;)
Very good news for multi codec support :D but why "IM" in DGDecIM ? Input Multiple ?

[Guest]

Intel Media

[Nico8583]

Of course, it was evident ;)

[Guest]

I'm trying to turn on HW acceleration but no Intel graphics HW is detected. Hmm, I have an NVidia card installed and so I suppose the integrated Intel graphics is turned off in the BIOS. I have to turn it back on and hope I can use it as a secondary, etc. Anybody have this working?

[r0lZ]

As far as I know, the HW acceleration requires a specific Intel CPU, not a nVidia graphics card. It's not CUDA.
Unfortunately, I don't have the right hardware, and I can't help you much on that subject. IIRC, Nico8583 has the right CPU and he should be able to test your builds.

[Guest]

I have the right CPU and I well know the difference between the Intel stuff and CUDA. I am just looking to enable it alongside the NVidia adapter. If I can't do that I lose DGDecNV and that's not something I can accept.

EDIT: I found a post by Eric Gur at the Intel forum explaining how to do this and it is working for me now. :)

[r0lZ]

Ah, OK, I have not understood your request. Sorry.

[Guest]

No problem, r0lZ! I always appreciate your feedback and testing!

Here is beta 16 with HW acceleration. It will be used automatically if available, otherwise SW will be used.

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

So, in case you didn't figure it out, this little project for me is a warmup for DGDecIM, sort of a test to see if I can use the Intel Media SDK in the way that will be needed. It's apparent that I can. So I propose to wait a bit for feedback on this last version of DGMVCSource. If no problems arise I'll release the source code and then move on to the fully frame-accurate DGDecIM (with MVC support, of course).

EDIT: To see how fast the HW acceleration can be, add AssumeFPS(1000) to your script and then play it in VirtualDub.

[Guest]

@r0lZ

Could you please verify that b16 is still working in SW mode? Thanks!

[r0lZ]

Yes, it works. Slowly for me, but it works. ;-)

[Zathor]

Thank you very much for this filter!

I just tried it the first time and of course also within MeGUI. Sadly it does crash MeGUI. I expected that when using the preview when MeGUI tries to jump into the preview but it also crashes simply opening and closing the avs script environment. frimsource does not have this behaviour. I am currently debugging MeGUI to get the step where it crashes. Likely the problem is within MeGUI or the related avs wrapper.

Also in VirtualDub (it does not crash there) I noticed that I cannot reopen the video while in the middle of the video - it will start from the beginning. Once again with frimsource and this pseudo caching set to >1 it is possible to do this.

[Guest]

Can you please give me the script you opened in MEGUI?

I will try it here too with some scripts.

The re-open stuff will be automatically fixed by correct random access, and I'm not that interested in pseudo seeking. As an interim expedient, sure go for it, but I don't think it's a good long-term solution.

[Nico8583]

Thanks a lot for HW acceleration, I'll try to test tomorrow ;)

[Guest]

OK, it's obvious what is happening. MEGUI is asking for multiple instantiations of dgmvcsource(). It's on my to-do list and I suppose I'll have to support that right now. Standby...

[Zathor]

My current script is quite simple:
LoadPlugin("D:\MVC\DGMVCDecode.dll")
vid=dgmvcsource("D:\MVC\combined.264","",view=0,frames=2000)

I am not sure if multiple instances are the problem. Based on the MeGUI debug the crash happens after the third opening of the script but the other two are already closed. Or do you see on your side that these other two instances are not correctly closed? In that case the wrapper may have a problem as the dispose is called in the managed code and executed in the unmanaged wrapper code.

[MeteorRain]

Honestly I'm quite exciting when hearing about QuickSync for DG series. (DGQuick?)

[Guest]

My current script is quite simple:
LoadPlugin("D:\MVC\DGMVCDecode.dll")
vid=dgmvcsource("D:\MVC\combined.264","",view=0,frames=2000)

I am not sure if multiple instances are the problem. Based on the MeGUI debug the crash happens after the third opening of the script but the other two are already closed. Or do you see on your side that these other two instances are not correctly closed? In that case the wrapper may have a problem as the dispose is called in the managed code and executed in the unmanaged wrapper code. I'll check. I had a trace only on the instantiation and not the destruction so I wouldn't have noticed what you say. Assuming you are correct can you continue please to find the cause of MEGUI crashing? Thanks.

Meanwhile I am removing all global data anyway as it needs to be done.

EDIT: You're right, I see the destructor called as you say.

[osgZach]

Thread's a bit big to read through... But is this basically for decoding 3D stuff? i.e useless for non 3D ?

And about the Quicksync. I have had trouble finding any reliable answer on exactly what needs to happen to enable it. Does it require a CPU with a GPU or something? I can't get Quicksync to enable in LAV filters for instance.. Its just a decoder right?
I have an i5 3570K Ivybridge. Which supposedly supports it, but then people say you need an onboard GPU....? Is this a motherboard specific thing and not the IGPU's in newer CPUs ?

If so that is pretty retarded on Intel's part.. why even include the technology if you're going to gimp it with the requirement of an inferior GPU on the chip or motherboard

[Stereodude]

And about the Quicksync. I have had trouble finding any reliable answer on exactly what needs to happen to enable it. Does it require a CPU with a GPU or something? I can't get Quicksync to enable in LAV filters for instance.. Its just a decoder right?
I have an i5 3570K Ivybridge. Which supposedly supports it, but then people say you need an onboard GPU....? Is this a motherboard specific thing and not the IGPU's in newer CPUs ?

If so that is pretty retarded on Intel's part.. why even include the technology if you're going to gimp it with the requirement of an inferior GPU on the chip or motherboardAre you using the integrated graphics on your Ivybridge to drive a display? Ivybridge supports QuickSync. I believe you need to run some additional software for Ivybridge processors to enable the iGPU if you're using a PCIe display adapter to drive your display so you can still use QuickSync if you don't have a monitor attached to it.

[Thalyn]

Most motherboards have the option to have the iGPU enabled with a discrete GPU. It's an option in BIOS. Both my Sandy Bridge and Haswell have the option, at least on Z68 and Z87 boards respectively. I believe only certain H and P boards can do it, though.

However, unless the implementation is Windows 8 aware (thus supporting "headless" mode) you need to have a monitor attached - either real or fake. If you don't do this than DirectX won't enumerate the device, thus it won't be available to use for acceleration. This page here (http://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html) outlines how you can create a fake monitor and it seems to work with the latest drivers from Intel (but not with the latest Windows Update ones). If you're using a fake screen you can reposition it up to the very corner of the real one to stop your cursor getting "lost".

[Zathor]

I'll check. I had a trace only on the instantiation and not the destruction so I wouldn't have noticed what you say. Assuming you are correct can you continue please to find the cause of MEGUI crashing? Thanks.

Meanwhile I am removing all global data anyway as it needs to be done.

EDIT: You're right, I see the destructor called as you say.
Sorry, I did not had the time to dig deeper. For me it is quiete complicated to find the root cause of the crash as it is happening somewhere in unmanaged external code. Regarding the log it crashes in the module DGMVCDecode.dll_unloaded

[Guest]

Sorry, I did not had the time to dig deeper. For me it is quiete complicated to find the root cause of the crash as it is happening somewhere in unmanaged external code. Regarding the log it crashes in the module DGMVCDecode.dll_unloaded Thanks, Zathor. I found and fixed the problem. I wasn't properly deallocating the decode pipeline when the filter was deinstantiated. I'll make a new beta after some more testing.

[Guest]

Here is the fix for running in MEGUI:

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

[Guest]

Thread's a bit big to read through... But is this basically for decoding 3D stuff? i.e useless for non 3D ? It can decode normal AVC as well.

Think of it as a trial run for a version of DGDecNV that will use the Intel Media SDK rather than NVidia's CUVID. The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.

[Guest]

Please re-download beta 17. The first upload was, umm, suboptimal. ;)

[Video Dude]

Thanks for working on another great program!


The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.
Is there any difference in decode quality between software and hardware mode?

[Guest]

Is there any difference in decode quality between software and hardware mode? I haven't tested anything like that but theoretically the outputs should be identical.

[Guest]

Release candidate:

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

This supports multiple instantiation in a script.

[Nico8583]

Doom9 is up :D
I'll try to make an other test today to compare SW and HW speed with AVSMeter and x264 :)

[Guest]

Here is a version that allows you to force SW or HW decoding. Use the hw parameter as needed.

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

[Nico8583]

Thanks for this version, I'm going to test :)

[rack04]

It can decode normal AVC as well.

Think of it as a trial run for a version of DGDecNV that will use the Intel Media SDK rather than NVidia's CUVID. The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.

Would an NVidia user with an ivy bridge processor be able to use DGDecIM without having intel's video drivers installed? This may be useful if there are streams that don't work with NVidia, which I have yet to encounter.

[Guest]

Would an NVidia user with an ivy bridge processor be able to use DGDecIM without having intel's video drivers installed? This may be useful if there are streams that don't work with NVidia, which I have yet to encounter. You will be able to use the SW decoding mode if no Intel drivers are installed, or if the Intel GPU is not enabled in the BIOS. My current thinking is to have one application, DGDec, that can use any available decoding engine, SW or HW. So even if you don't enable the Intel GPU, you could still use the Intel Media SDK decoder in SW mode. Or CUDA/CUVID, all in one application.

If you want QuickSync, however, you have to install the Intel driver. I have done this as a secondary. My i7-4770 machine came with an nVidia 620 installed. I had to enable the Intel GPU in the BIOS and then install the Intel driver. The nVidia 620 remains the primary video so I get both CUDA/CUVID and QuickSync available.

QuickSync appears to be somewhat faster than CUDA/CUVID, so that could be a reason to prefer it. CUDA/CUVID always has to pass decoded pictures back to the CPU over the video bus. The Intel GPU is presumably closer to CPU memory and that accounts for some of the speedup.

[MeteorRain]

For DGDecIM, would it be usable under remote desktop connection?

If I have 3 monitors, 2 of them plug on nVidia while 1 on IGP, will it still be able to use QS?

[Nico8583]

So I have made 4 tests with DGMVCSource and FRIMSource. Here are results with my i5-3570, 8GB RAM and latest Intel drivers.

DGMVCSource SW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 16.01 | 30.97 | 20.52
CPU usage (average): 19%
Thread count: 9
Physical Memory usage (peak): 592 MB
Virtual Memory usage (peak): 594 MB
Time (elapsed): 000:02:16.473

DGMVCSource HW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 33.32 | 65.83 | 54.57
CPU usage (average): 7%
Thread count: 17
Physical Memory usage (peak): 650 MB
Virtual Memory usage (peak): 737 MB
Time (elapsed): 000:00:51.310

FRIMSource SW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 17.33 | 35.12 | 21.69
CPU usage (average): 41%
Thread count: 12
Physical Memory usage (peak): 730 MB
Virtual Memory usage (peak): 778 MB
Time (elapsed): 000:02:09.120

FRIMSource HW :
Frames processed: 2800 (0 - 2799)
FPS (min | max | average): 55.87 | 74.81 | 63.93
CPU usage (average): 25%
Thread count: 20
Physical Memory usage (peak): 771 MB
Virtual Memory usage (peak): 973 MB
Time (elapsed): 000:00:43.797

For both tests, FRIMSource is faster than DGMVCSource but it uses more CPU (about 2x or 3x) than DG plugin. Both are based on Intel Media SDK so how could we interpret that :confused:

[Sharc]

I did similar tests which I posted in neuron2's Forum.
I can't HW decode, however for SW decoding I also found that FRIM seems to be faster than DGMVC for pure decoding, HOWEVER:
When I transcode half-SBS with x264, DGMVCsource produced faster overall results for my 3D testclip:
DGMVCsource_SW_decoding + x264_encoding time = 180 sec.
FRIMsource_SW_decoding + x264_encoding time = 195 sec

[Nico8583]

I did similar tests which I posted in neuron2's Forum.
I can't HW decode, however for SW decoding I also found that FRIM seems to be faster than DGMVC for pure decoding, HOWEVER:
When I transcode half-SBS with x264, DGMVCsource produced faster overall results for my 3D testclip:
DGMVCsource_SW_decoding + x264_encoding time = 180 sec.
FRIMsource_SW_decoding + x264_encoding time = 195 sec
Could you post here or PM your AVS scripts and x264 cmdline ? I'll try to make tests like you with my CPU (and HW support)

[Groucho2004]

HOWEVER:
When I transcode half-SBS with x264, DGMVCsource produced faster overall results for my 3D testclip:
DGMVCsource_SW_decoding + x264_encoding time = 180 sec.
FRIMsource_SW_decoding + x264_encoding time = 195 sec
That makes sense considering the larger CPU overhead of FRIMSource().

[Sharc]

That makes sense considering the larger CPU overhead of FRIMSource().
Exactly my thoughts......

[sef]

Nico8583: So I have made 4 tests with DGMVCSource and FRIMSource. Here are results with my i5-3570, 8GB RAM and latest Intel drivers.

I Agree..

[Sharc]

Could you post here or PM your AVS scripts and x264 cmdline ? I'll try to make tests like you with my CPU (and HW support)
Here we go:

FRIM script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\FRIMSource.dll")
FRIMsource(codec="mvc", filename="base.264", filename_dep="dep.mvc", layout="SBS", cache=24, num_frames=1650)
horizontalreduceby2()

x264-FRIM cmd:
x264.exe "FRIMSource_.avs" --bluray-compat --crf 22 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "out_FRIMSource-to-x264.h264"


DGMVC script:
LoadPlugin("c:\Program Files Video\AviSynth 2.5\plugins\DGMVCDecode.dll")
Video=DGMVCsource("base.264","dep.mvc",frames=1650,view=0,hw=0)
V1 = SelectEven(video)
V2 = SelectOdd(video)
return StackHorizontal(horizontalreduceby2(V1),horizontalreduceby2(V2))


x264-DGMVC cmd:
x264.exe "DGMVCSource_.avs" --bluray-compat --crf 22 --vbv-bufsize 15000 --vbv-maxrate 15000 --sar 1:1 --fps 23.976 --output "out_DGMVCSource-to-x264.h264"

[sef]

Very good neuron2! Thank you for the work done, you become the favorite ..:)

[Nico8583]

Thanks Sharc, I'm going to try in few hours and I'll tell you results :)

[Sharc]

We are greatful to videofan3d and neuron2 for having given to us 2 excellent plug-in decoders! We now even have the choice and may select the most suitable solution, depending on the application scenario and HW infrastructure.
:thanks: :thanks: :thanks:

[Nico8583]

So I have made new tests with same script and same cmdline than Sharc. Here are results :
- DGMVCSource SW : average 17,58 fps
- DGMVCSource HW : average 22,71 fps
- FRIMSource SW : average 16,90 fps
- FRIMSource HW : average 19,85 fps

So yes with x264 encoding DGMVCSource is faster than FRIMSource :)

[Sharc]

In a transcoding scenario the required overall time seems to be dominated by the SW encoding which tends to mask the benefit of fast HW decoding, I guess.
No reason for me to buy a new PC :D

[Guest]

In a transcoding scenario the required overall time seems to be dominated by the SW encoding which tends to mask the benefit of fast HW decoding, I guess. Yes, I think you are correct about that.

[Nico8583]

So no reason to go to Intel for me too :D

[Sharc]

Although it's off topic I like to add that the fastest method is FRIMDecode via stdout to x264. So for my previous half-SBS example (http://forum.doom9.org/showpost.php?p=1665166&postcount=393) the total time becomes:
FRIMDecode(SW) > stdout > x264 = 175 sec.

[jdobbs]

Although it's off topic I like to add that the fastest method is FRIMDecode via stdout to x264. So for my previous half-SBS example (http://forum.doom9.org/showpost.php?p=1665166&postcount=393) the total time becomes:
FRIMDecode(SW) > stdout > x264 = 175 sec.Yeah... but you also lose the functionality of AVISYNTH -- which is pretty important.

[Sharc]

Yeah... but you also lose the functionality of AVISYNTH -- which is pretty important.
Sure -- fully agree -- but same is true when piping FRIMDecode to FRIMEncode.

[Thalyn]

I know I said I'd take a step back from this thread, but I've run across an issue a few times now - enough that I'm fairly sure it's not specifically my fault, though it appears to be caused by my workflow.

Basically, attempting to use DGMVSCSource (Hardware mode - I'll admit I haven't tried software) with Jack the Giant Slayer, Man of Steel, Pacific Rim and The Smurfs 2 is giving pretty messed up results. Both the AVC and MVC frame go crazy before it finally appears to time out and go blank. The good news is this behaviour seems very consistent - Jack, for example, would pack in the towel around frame 850 each and every time, and would even crash entirely when attempting to preview it with VirtualDub.

Now, the reason I suspect it's due to my workflow is because I don't quite follow exactly what seems to be the more popular option of using EAC3To to extract it from a disc decrypted with AnyDVD HD. Instead, I'm using MakeMKV to extract from the disc, then tsMuxeR to extract from the resulting MKV as EAC3To cannot correctly identify a multi-view MKV file and only extracts the AVC stream. These are then run through my standard script and the problem follows, either kicking back an error in MeGUI or stalling briefly before taking off at an incredible speed (the blank frames).

FRIMSource (also in Hardware mode) works for these files, though, which is why I believe them to not be faulty. I'll understand if you don't place too much value on that belief after my earlier posts. It is, however, slower to process - hence my desire to use DGMVCSource instead (Pacific Rim is processing at barely 14fps even using DGMVCSource, compared to my usual 20-26fps, so faster is better).

However, if I use MKVExtract to dig out the pre-combined multi-view stream and feed that through DGMVCSource instead than it works. This again suggests that the issue is somewhere between the way MakeMKV is creating the streams, tsMuxer is outputting those certain streams and the way your plugin is reading them. It just seems odd that there would be 4 that cause problems against the other 23 I've done so far without issue (not including Escape). Obviously I can use this method instead but I feel avoiding the issue isn't the best solution possible.

I've uploaded an MKV with the first 1,001 frames of Pacific Rim. I've tested to be sure and that's sufficient to see the garbled output I was talking about, as well as the stall which should occur at or around frame 967. tsMuxeR 2.6.12 is what I used to extract the individual streams when the error occurs, while the MKVExtract as provided by MKVToolNix v6.7.0 produces the working, pre-combined stream.

Pacific.mkv (https://mega.co.nz/#!0hNjVQwZ!1M92_Hh9GTBE7h8X4BbjwEv-ZRDL9gQmb2bYT2AoiqA) (111MB)

NB I'm not very familiar with these file-hosting services, so if that doesn't work then let me know.

[Guest]

@Thalyn

Can you please do the demuxing for me? You can give me the two sets of corresponding elementary streams, one of which works, and one does not. That will be the best thing for me to have to solve your issue.

[Guest]

My plan to have a single DGDec has forced me to back off to Visual Studio 2012 Express, as the latest CUDA toolkit 5.5 does not support VS 2013. I have managed to build DGDecNV and DGMVCSource in VS 2012, so all systems are now go. Who knows, I might even add support for libav SW decoding. :D

[jdobbs]

My plan to have a single DGDec has forced me to back off to Visual Studio 2012 Express, as the latest CUDA toolkit 5.5 does not support VS 2013. I have managed to build DGDecNV and DGMVCSource in VS 2012, so all systems are now go. Who knows, I might even add support for libav SW decoding. :DThat would be too cool.

[Guest]

That would be too cool. Yeah, as long as I don't end up in another Hall of Shame. ;)

What's going on with all that after the coup d'état? Is it still split into warring factions?

[Nico8583]

Dear neuron2 :D no I will not ask a new feature ;)
I would like to know if you have a to do list updated ?
And do you plan to implement MPLS support ? Because like r0lZ said in another topic, there are MPLS and multi angle inside this MPLS so it could be more difficult to support this ?!

[jdobbs]

Yeah, as long as I don't end up in another Hall of Shame. ;)

What's going on with all that after the coup d'état? Is it still split into warring factions?I haven't heard much on that subject in quite a while.

[Sharc]

@Thalyn
I demuxed your .mkv with tsMuxeR 2.6.12. I confirm that SW Decoding with DGMVCsource fails (garbled output).

Did you try without the intermediate .mkv i.e. demux with tsMuxer directly from the source .ssif?

Edit:
I just did this with Pacific Rim:
- demux the .ssif with tsMuxeR 2.6.12.
- Decoded the 2 Input files with DGMVCsource¨
=> Everything is perfect.
So I guess there is something odd with the .mkv. IIRC there is something special or proprietary with the MakeMKV 3D format. I just didn't find the post ....

[Guest]

Thanks, Sharc, for your feedback. Did you try the files demuxed from the MKV with frimsource? I would be surprised if they worked there but not in dgmvcsource, and would want to address that.

The best thing is to give me what I asked for, the two sets of files. Then I can simply compare them to see what is going on. Can you provide the two sets of demuxed files?

[Sharc]

Uploading ..... it may take a while ...

Yes, decoding with FRIMsource works, and so does viewing with Stereoscopic Player which uses CoreAVC decoder.


Thalyn's demuxed .mkv:
http://www.mediafire.com/download/xez6wecvz86sqnq/Bad.zip

Demuxed .ssif:
http://www.mediafire.com/download/4j0r3rp889naivz/Good.zip

[Guest]

Thanks, Sharc, I'll see if I can figure out what is happening here.

[Thalyn]

Sorry about the delay. I pretty much turned in for the night after making that post (was 3am), but I've separated the streams and just finished uploading them.

MKVExtract combined stream (https://mega.co.nz/#!d0UCmAaD!Y95vemF0xBaUXYN0ud99luz6eVEc5Ej5VibhOKEEe4g) (111MB)
Script:
## *Load plugins
LoadPlugin ("T:\BluRay Tools\Plugins\DGMVCDecode.dll") # Primary decoder
#LoadPlugin ("T:\BluRay Tools\Plugins\FRIMSource.dll") # Backup decoder
LoadPlugin ("T:\BluRay Tools\Plugins\SupTitle.dll")
LoadPlugin ("T:\BluRay Tools\Plugins\VSFilter.dll")
## *Source files
SP = "T:\BRD\" # Source path (must end in "\")
SF = "Pacific (MKVExtract)" # Source file names (raw streams only)
# AVC and MVC must be H.264 format
# (Optional) Subtitles must be SUP
FC = 1001 # Frame count of source
FR = FC # Frames to return (default: FC)
SFL = "" # (Optional) Left subtitle file for non-SUP
# Can be SUB/IDX, SSA, ASS, SRT, SUB, SMI, PSB, USF or SSF
SFR = 9 # (Optional) Right subtitle information
# (.SUP only) Subtitle horizontal offset. Good offsets are 6-12
# (Non-SUP) right subtitle file (non-SUP). Can be set to SFL for 0 offset
LC = 0 # Left cropping (typically 0)
TC = 0 # Top cropping (typically 0, 20, 132, 138 or 140)
RC = LC # Right cropping (typically the same as LC)
BC = TC # Bottom cropping (typically but not always the same as TC)
## *Load video file - default assumes AVC is Left (most common).
Try { # Attempt to use backup FRIM decoder
Source = FRIMSource (codec="mvc", filename=SP + SF + ".264", filename_dep=SP + SF + ".mvc", \
cache=4, num_frames=FC)
}
Catch (errDec) { # Attempt to use DGMVC decoder if FRIM is unavailable (default)
Source = DGMVCSource (SP + SF + ".264", "", view = 0, frames = FC)
}
## *Crop stream
Source = Source.Crop (LC, TC, -RC, -BC)
## *Split interleaved frames
AVC = SelectEven (Source)
MVC = SelectOdd (Source)
## *Assign left and right streams - switch as necessary (default Left = AVC).
Left = AVC
Right = MVC
## *Hard subtitles - add/change as necessary.
Try { # Attempt to add subtitle file as offset PGS
Left = Left.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset="0, " + String (TC) + ", " + String (SFR) + ", 0")
Right = Right.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset=String (SFR) + ", " + String (TC) + ", 0, 0")
}
Catch (errPGS) { # Try to read subtitles with VSFilter if not PGS format
Try { # First attempt to read as IDX/VOB
Left = Left.VobSub (SP + SFL)
Right = Right.VobSub (SP + SFR)
}
Catch (errVOB) { # If not IDX/VOB, attempt to read as text subs
Try {
Left = Left.TextSub (SP + SFL) # Recommend SSA/ASS for text subs
Right = Right.TextSub (SP + SFR)
}
Catch (errTXT) { NOP } # If subtitle file not found or not compatible, do nothing at all.
}
}
## *Merge to HOU.
Try { # Attempt to merge frames normally
HOU = StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2))
}
Catch (errCrop) { # If reduction fails, convert to RGB for the merge then back to YV12
Left = ConvertToRGB (Left, matrix = "rec709")
Right = ConvertToRGB (Right, matrix = "rec709")
HOU = ConvertToYV12 (StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2)), matrix = "rec709")
}
## *Output - adjust trim as necessary.
return HOU.Trim (0, FR - 1)

tsMuxeR AVC stream (https://mega.co.nz/#!0sM1FLSa!S_ABwOOkGkQ-UE-Wa8rCoTW0YSXKH9I1mYJjAQ7Z_Gs) (74.5MB)
tsMuxeR MVC stream (https://mega.co.nz/#!IxUnRJTQ!4bdQ2St4h0yKCqjeKy_WEs1ZTiQd6nsqTqgJo9-oWIE) (36.7MB)
Script:
## *Load plugins
LoadPlugin ("T:\BluRay Tools\Plugins\DGMVCDecode.dll") # Primary decoder
LoadPlugin ("T:\BluRay Tools\Plugins\FRIMSource.dll") # Backup decoder
LoadPlugin ("T:\BluRay Tools\Plugins\SupTitle.dll")
LoadPlugin ("T:\BluRay Tools\Plugins\VSFilter.dll")
## *Source files
SP = "T:\BRD\" # Source path (must end in "\")
SF = "Pacific (tsMuxeR)" # Source file names (raw streams only)
# AVC and MVC must be H.264 format
# (Optional) Subtitles must be SUP
FC = 1001 # Frame count of source
FR = FC # Frames to return (default: FC)
SFL = "" # (Optional) Left subtitle file for non-SUP
# Can be SUB/IDX, SSA, ASS, SRT, SUB, SMI, PSB, USF or SSF
SFR = 9 # (Optional) Right subtitle information
# (.SUP only) Subtitle horizontal offset. Good offsets are 6-12
# (Non-SUP) right subtitle file (non-SUP). Can be set to SFL for 0 offset
LC = 0 # Left cropping (typically 0)
TC = 0 # Top cropping (typically 0, 20, 132, 138 or 140)
RC = LC # Right cropping (typically the same as LC)
BC = TC # Bottom cropping (typically but not always the same as TC)
## *Load video file - default assumes AVC is Left (most common).
Try { # Attempt to use backup FRIM decoder
Source = FRIMSource (codec="mvc", filename=SP + SF + ".264", filename_dep=SP + SF + ".mvc", \
cache=4, num_frames=FC)
}
Catch (errDec) { # Attempt to use DGMVC decoder if FRIM is unavailable (default)
Source = DGMVCSource (SP + SF + ".264", "", view = 0, frames = FC)
}
## *Crop stream
Source = Source.Crop (LC, TC, -RC, -BC)
## *Split interleaved frames
AVC = SelectEven (Source)
MVC = SelectOdd (Source)
## *Assign left and right streams - switch as necessary (default Left = AVC).
Left = AVC
Right = MVC
## *Hard subtitles - add/change as necessary.
Try { # Attempt to add subtitle file as offset PGS
Left = Left.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset="0, " + String (TC) + ", " + String (SFR) + ", 0")
Right = Right.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset=String (SFR) + ", " + String (TC) + ", 0, 0")
}
Catch (errPGS) { # Try to read subtitles with VSFilter if not PGS format
Try { # First attempt to read as IDX/VOB
Left = Left.VobSub (SP + SFL)
Right = Right.VobSub (SP + SFR)
}
Catch (errVOB) { # If not IDX/VOB, attempt to read as text subs
Try {
Left = Left.TextSub (SP + SFL) # Recommend SSA/ASS for text subs
Right = Right.TextSub (SP + SFR)
}
Catch (errTXT) { NOP } # If subtitle file not found or not compatible, do nothing at all.
}
}
## *Merge to HOU.
Try { # Attempt to merge frames normally
HOU = StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2))
}
Catch (errCrop) { # If reduction fails, convert to RGB for the merge then back to YV12
Left = ConvertToRGB (Left, matrix = "rec709")
Right = ConvertToRGB (Right, matrix = "rec709")
HOU = ConvertToYV12 (StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2)), matrix = "rec709")
}
## *Output - adjust trim as necessary.
return HOU.Trim (0, FR - 1)

Yes, the two scripts are nearly identical. This is my standard "cover all" script. The key differences are uncommenting the LoadPlugin line for FRIMSource and changing the SF variable.

Incidentally, Pacific Rim failed on a full run even using the pre-combined source. Sections of the video were missing, about a second long each time it happened (total of about 5-6 occurrences though I didn't find them all). I plan on taking another look later to see if EAC3To streams work properly but for now I'm checking the stream with FRIM to see if that gives the same results.

Disregard - that seems to be a source problem. Next step is demuxing straight from the disc.

Update: Streams extracted straight from the disc using tsMuxeR are fine, however the same stutters I was getting before (eg circa frame 95,200) are still present. Between this and Escape I've clearly got another problem that needs fixing - will need to experiment.

[Guest]

Well, the bad streams are formally wrong. For example, at times there is an extra PPS at the end of a NALU just before the next AUD NALU. Somehow Frank's combiner is cleaning them up sufficiently to allow things to continue working, while mine is not. As my main goal now is on getting DGDec functionality working (full frame accuracy/seeking) and less on 3D stuff, I may leave it and just assert "bad streams". Or if I get curious enough, I'll look into what Frank's combiner is doing that allows it to survive these streams.

[Sharc]

I suspect that the tool which created the .mkv is the culprit.

[Guest]

Following is an example of the stream violations. Here the PPS is appearing before the AUD NALU when it should be after. I believe Frank's combiner is moving these to the right place. That's very thoughtful of him but I wonder if it is deliberate or just a lucky consequence of how he implemented the combiner.

[videofan3d]

Following is an example of the stream violations. Here the PPS is appearing before the AUD NALU when it should be after. I believe Frank's combiner is moving these to the right place. That's very thoughtful of him but I wonder of it is deliberate or just a lucky consequence of how he implemented the combiner.


It se definitely only good luck :-)

FRIM uses "MVCCombiner" which I sent you - and I wrote it only upon empiric observation of the structure of AVC and MVC and Combined streams which produces Intel Media MVC Encoder.
I really have no special knowledge in this domain :)
And I'm sure that this algorithm is far from perfection - the fact that nobody reported problems doesn't mean it is bug free - not at all ! :D

[Thalyn]

"Bad streams" sounds a fair enough declaration to me, given the information in the streams is in the wrong order. I guess that's just something to note: Don't use split-streams made from the output of MakeMKV (but the combined stream seems OK).

Now if I could only figure out what's messing up my extraction of both Pacific Rim and Escape. Both play back flawlessly under PowerDVD 13 so I'm fairly sure that my discs, drives and drivers aren't the problem. But I'll be buggered if I can successfully get a full run of either without one or more glitches (which seem to be isolated to my system) occurring...

[Guest]

It's definitely only good luck :-) Still, it will be interesting to trace your combiner to see how it avoids barfing on these malformed streams. Thanks for providing the source code. At first, I thought it didn't work but it turned out to be a problem on my side. :)

FRIM uses "MVCCombiner" which I sent you - and I wrote it only upon empiric observation of the structure of AVC and MVC and Combined streams which produces Intel Media MVC Encoder.
I really have no special knowledge in this domain :)
And I'm sure that this algorithm is far from perfection - the fact that nobody reported problems doesn't mean it is bug free - not at all ! :D There is one strange thing your combiner does with these streams. It outputs a combined stream with an 8 NALU immediately following the last base slice, but immediately preceding a 24 NALU. I would have thought that was wrong but Intel Media accepts it fine. I suspect they ignore 24 NALUs, and anyway my combiner suppresses them from the output and they work fine that way (with legal streams).

I think it is worth it for me to investigate this further as it will be useful to have a complete reliable specification of what a combiner should do and how it can be made as robust as possible against dubious input. If only Intel would document their combined format more thoroughy; the best I have seen from them is first present all the base slices and then the dependent slices!

[Guest]

So after looking everything over closely, including the test results and Frank's combiner, it's apparent that I've been overthinking what is required of a combiner, and the process is really very simple. All you have to do is interleave the base and dependent access units (access units are delimited by a 9 NALU in the base stream and a 24 NALU in the dependent stream). That's all, folks!

So I have released new versions of the standalone combiner DGMVCCombine and the source plugin DGMVCSource. The source filter now succeeds with the bad streams the same as FRIMSource.

http://neuron2.net/mine.html

[Thalyn]

After managing to screw myself around a whole heap (got my source streams well-and-truly mixed up and found myself processing an already-processed stream), quick testing is yielding the same results with B22 as with B20. That is to say good results aside from a couple of baffling exceptions that only I seem to be able to produce. I did, however, discover that using the driver provided from Windows Update for my HD 4600 had disabled hardware accelerated decoding, so if anyone's having trouble with it make sure you use the drivers from Intel and not MS.

Per your request I've uploaded a snippet from the middle of Pacific Rim as made by DGSplit with the only processing done by AnyDVD HD (7.4.2.0). In case it's in any way, shape or form relevant, it's bytes 21,670,573,312 to 21,870,573,312, containing around 35 seconds. The error I experience should present itself about half-way through, covering the scene transition just after the Kaiju (the monster if you haven't seen the movie before) roars, lasting only around a second, but I included extra to ensure as little important data is missing as possible (when I tried to cut it finer it appeared to miss parts of the MVC stream).

00098_0.ssif (https://mega.co.nz/#!wx1QjTaS!-NgZoX7BXDdL5LbG27iKxwnRVyyTwRpwViWPw87FUEA) (190.7MB)

[Sharc]

I transcoded Pacific Rim in full length and confirm Thalyn's observation of glitches shortly after frame 95300.
DGMVCsource 0.22b / SW.

[Guest]

Does it happen with FRIMSource also? In a PM, Thalyn said "I cannot for the life of me figure why feeding certain streams I've extracted through either Intel decoder doesn't work". If it is an issue in the Intel Media SDK, there's not much I can do about it; I don't have any special contacts with Intel support, and you can just as well post a thread at their forum about it as I can.

Also, I cannot use that SSIF file because eac3to will not open it. Something is wrong with it.

[Thalyn]

It's literally 200,000,000 bytes extracted from the middle of much larger ssif file using DGSplit. I lack the knowledge (and possibly tools) to make a more accurate "cut" without first demuxing the streams (even if to put them into another container) - like the streams I already linked to you - so that's unfortunately the best I can do while keeping the amount of pre-processing to an absolute minimum.

If there's another, more useful way to make the extraction I'm quite willing to give it a go.

*ed: Curiously, what made those extracted streams "bad"? Is it something that can be fixed during extraction (such as telling tsMuxeR to rebuild the SEi and VUI data) or by the plugin (like those NALU thingies - NB I don't know what any of these acronyms mean), or is it something irreparable like a missing keyframe?

[Guest]

I asked this but you did not answer: Does it happen with FRIMSource also? Can you please answer it?

Curiously, what made those extracted streams "bad"? Is it something that can be fixed during extraction (such as telling tsMuxeR to rebuild the SEi and VUI data) or by the plugin (like those NALU thingies - NB I don't know what any of these acronyms mean), or is it something irreparable like a missing keyframe? I don't know what streams you are talking about.

[Sharc]

I didn't try with FRIM, but I will do it now and report back.

[r0lZ]

Does it happen with FRIMSource also?I am currently encoding Pacific Rim with FRIMSource. I should be able to tell if it had the same problem in 2 hours or so...

I can already confirm the bug when it is encoded with DGMVCSource b22 (SW).

[Sharc]

Also, I cannot use that SSIF file because eac3to will not open it. Something is wrong with it.
I can open and demux it with tsMuxeR.
The .ssif however includes the base view only (which has no glitches). The dependent view seems to be missing.

[r0lZ]

Yes, I've seen that. Only the AVC stream is detected by tsMuxeR (as well as a lot of audio and 2 subpic streams).
... the base view only (which has no glitches).Are you sure? I have noticed with my test encoding that the base view is badly decoded too. IMO, it's the base view that the Intel decoder cannot decode properly. The glitch in the dep view is of course a consequence of the bad base view. When I will have some time, I'll encode the base view only, just to be sure...

[r0lZ]

Same problem with FRIMSource. :-(

[Guest]

Same problem with FRIMSource. :-( or :) from my point of view.

[Sharc]

Yes, I've seen that. Only the AVC stream is detected by tsMuxeR (as well as a lot of audio and 2 subpic streams).
Are you sure? I have noticed with my test encoding that the base view is badly decoded too. IMO, it's the base view that the Intel decoder cannot decode properly. The glitch in the dep view is of course a consequence of the bad base view. When I will have some time, I'll encode the base view only, just to be sure...
I mean that the demuxed base view is without glitches.
Glitches are introduced only when processed by DGMVC or FRIM. Both behave the same: The Base view AND the Dependent view have glitches.

[r0lZ]

or :) from my point of view.Yes, you have nothing to do. But it's a bad news anyway.
I mean that the demuxed base view is without glitches.
That means only that the decoder used by the player has no trouble with it, and (probably) that there is nothing wrong with the encoding or authoring of the BD. And that confirms probably that the culprit is Intel!

[jdobbs]

Yes, you have nothing to do. But it's a bad news anyway.

That means only that the decoder used by the player has no trouble with it, and (probably) that there is nothing wrong with the encoding or authoring of the BD. And that confirms probably that the culprit is Intel! Except, of course, that TSMUXER doesn't see the dependent view in the stream.

@Sharc

Have you tried demuxing from the two M2TS files?

[Sharc]

Yes, you have nothing to do. But it's a bad news anyway.

That means only that the decoder used by the player has no trouble with it, and (probably) that there is nothing wrong with the encoding or authoring of the BD. And that confirms probably that the culprit is Intel!
Yes, that seems to be most likely.
- The BD plays ok on a standalone
- The dumuxed base view has no glitches
=> The source (BD) is most probably clean.

- FRIM and DGMVC behave the same
=> the common set is Intel.

[Sharc]

Except, of course, that TSMUXER doesn't see the dependent view in the stream.

@Sharc

Have you tried demuxing from the two M2TS files?
The missing dependent view happened only with Thalyn's snippet.
I took the original .ssif and tsMuxeR demuxed the Base and Dependent files as expected.

[jdobbs]

The missing dependent view happened only with Thalyn's snippet.
I took the original .ssif and tsMuxeR demuxed the Base and Dependent files as expected.Ok. I misunderstood.

[Sharc]

I may just add that Stereoscopic Player (licensed, using CoreAVCdecoder.dll) plays Pacific Rim without issues.

[Nico8583]

Bad news for Intel SDK :-(
I think there is the same issue with MVCSource...
Does anyone already contact Intel support to report this bug ?

[Sharc]

@jdobbs (or anyone):
Did you try FRIMDecode piping into FRIMEncode (or stdout to x264 SBS)? Same problem as with the plugin-decoders for Pacific Rim?

[Guest]

Bad news for Intel SDK :-(
I think there is the same issue with MVCSource...
Does anyone already contact Intel support to report this bug ? I will be happy to pursue this with them, but right now all I have is an SSIF that I cannot demux. Somebody has to give me something I can use to duplicate the issue.

[Sharc]

Trying to produce a working cut ......

Got it. Uploading .... be patient ....

Edit:
Here we go (http://www.mediafire.com/download/bib2za0uxzcctfm/pr.zip). I hope you can duplicate the issue.

[r0lZ]

As I suspected, pistacho's MVCSource has the same problem.

[Sharc]

@jdobbs (or anyone):
Did you try FRIMDecode piping into FRIMEncode (or stdout to x264 SBS)? Same problem as with the plugin-decoders for Pacific Rim?
I can give the answer myself:
YES, it's exactly the same problem.
I guess this makes it pretty obvious that the root cause is the INTEL SDK.

[jdobbs]

@jdobbs (or anyone):
Did you try FRIMDecode piping into FRIMEncode (or stdout to x264 SBS)? Same problem as with the plugin-decoders for Pacific Rim?I don't have a 3D copy of "Pacific Rim", so I haven't tested it.

[Guest]

Thank you for the testing and streams, guys. This is going to be an interesting test case for Intel support. When I was doing the CUVID development NVidia was always very fast to respond and fix things like this. Intel has to do the same if they want the SDK to be successful. We shall see...

[Thalyn]

I don't know what streams you are talking about.

These streams (https://mega.co.nz/#!Jk8C1KBJ!wrSurXdtEdcJaQj6kw5cRCmH1RoBkAtXQ37N4UGyRuQ) are what I was referencing. There's only a couple seconds of video in each of those spanning where I notice the error, but I think tsMuxeR gave me 1 more frame for one of the streams (and wasn't kind enough to tell me which way the overhang should be).

Sorry about that. I should probably only try to make posts here when I'm more awake, but the time difference means I'll probably be responding well out of sequence.

[Sharc]

You have perhaps seen the comments of videofan3d (http://forum.doom9.org/showpost.php?p=1666422&postcount=81)about the Pacific Rim clip. His conclusion is "bad stream".
I have no clue at which stage between source and production of the clip the error has been introdcued, nor do I have other problematic sources (like Avenger) to test.
I used tsMuxeR for demuxing and producing the Clip. Has anybody tried eac3to, just to exclude tsMuxeR from being the culprit?

[Thalyn]

I've tried it with EAC3To, tsMuxeR and BD Demuxer Pro 3D - all produce slightly different streams but all yield the same error in the same place. I even tried telling tsMuxeR to extract with different options to see if something needed to be rebuilt

I will, however, re-try EAC3to just to confirm. I don't recall exactly how long ago it was I did that so a newer plugin may work.

[Sharc]

ok. I will also try now Pacific Rim with eac3to, and then we can see if we can confirm results.

Edit:
No luck.
- Demuxing Pacific Rim full length with eac3to. Base and dependent streams have identical number of frames (exactly the same number as I got with tsMuxeR)
- Base stream plays flawlessly with SW players (same as before with tsMuxer)
- transcoding from start using DGMVCsource as decoder
=> corruption starts with the same frame as before.

As tsMuxeR was not involved at any stage in this test we can exclude it from being the cause for the problem.

[r0lZ]

I did exactly the same test, and I confirm.

I can also confirm that DirectShowMVCSource and SSIFSource (both using CoreAVCDecoder) do not have the problem.

I have also played the base view with several players, and none exhibit the glitches.

IMO, there is no doubt any more that the culprit is the Intel Media library.

[Nico8583]

So we can only hope neuron2 will get a response from Intel support :/

[Sharc]

Perhaps we should provide to neuron2 a short clip of another problematic source for better evidence. So far most has been based on Pacific Rim. Anyone has a second example?

[Thalyn]

We need to find such a beast first. I know PR shows the same basic error multiple times, but so far only it and Escape from Planet Earth have given me any trouble - everything else appears to go through correctly. I'm progressively working through my collection of around 53 3D movies (28 down) and those are the only two I've seen a problem with, though I haven't done a frame-by-frame screening of them all.

That said, I'm in agreement with R0lz that it's the Intel libraries that are the source of the problem based on simple process of elimination:
- The drive doesn't appear to be the cause in that multiple drives from completely different locations produce identical results.
- The disc doesn't appear to be the problem in that multiple samples from completely different locations produce identical results.
- Decrypting does not appear to be the cause in that...
== an ISO created by AnyDVD HD plays back fine in PowerDVD 13.
== an MKV extracted by MakeMKV plays back fine using the LAV filters or PowerDVD (though this only verifies the AVC stream).
- Extracting the streams does not appear to be the cause in that...
== Four (4) different extraction tools yield identical errors.
== Repackaging the stream allows it to be played fine using the LAV filters or PowerDVD (though, again, this only verifies the AVC stream).
- The source plugins don't appear to be the cause in that it's unlikely the three authors (Neuron2, Pistacho and VideoFan3D) would have independently coded identical faults.
- Encoding doesn't appear to be the cause in that streaming directly to VirtualDub gives the same error.
- QuickSync itself doesn't appear to be the cause in that both Software and Hardware decrypting produce identical results.

And, of course...
- CoreAVC works (though it gives different errors for Escape)

Curiosity also got the better of me and I tried feeding it through Handbrake using its QSV path, which presumably uses the same IM libraries, both reading directly from the disc and from a repackaged stream (just the AVC stream to prevent MVC "taint" as I cannot easily test it). Both of these yielded identical results, which match the results from using any of the plugins based on the IM libraries. This also means that it's not the MVC stream responsible for the issue, but I'm sure it isn't helping.

With all that taken into consideration, the only thing left really is the IM libraries and, based on the errors which CoreAVC presents with certain sources, it's entirely possible that its present incarnation just simply isn't compatible with those streams for whatever reason.

[Sharc]

So it looks to me that we have so far only 2 candidates:
- Pacific Rim, which has been confirmed in several independent tests
- Escape from planet Earth (where even other decoders like CoreAVC seem to have problems)

This is a bit weak to make a strong case, I believe, means we should continue collecting more evidence and reporting back here with supporting material/clips from various sources & testers, supporting Thalyn in his huge efforts. Unfortunately this takes much time because one normally has to watch frame by frame, unless something very obvious pops up. Otherwise we have to wait and see if and how complaints from users will develop over time.

[Thalyn]

The following demonstrates what I've been able to discover so far. If anyone wants to confirm my findings, either using my provided source or their own source, than it would be appreciated.

Exhibit A (https://mega.co.nz/#!co8BzRpL!qXoCWL-vKmFry2RmLe2G1P3oHn0le6NZJ7NnjAMJOck) (97.7MB): a zip file with two (2) pre-combined sources from "Pacific Rim" and the results I got.
Exhibit B (https://mega.co.nz/#!h1l0CIJa!KCxY6TC506bf2aNrZhiD04qdy0GFhdVYdzz00zPHTNA) (50.5MB): a zip file with one (1) pre-combined source from "Escape from Planet Earth" and the results I got.

It may not be a strong case, but it's a start - and it may well be enough for Intel to do some investigating. It could very well be that these two are the only titles which exhibit problems because of some exact sequence in the source streams, however the fact that it applies to the AVC stream on its own as well opens up a lot more potentially "broken" streams (it extends my personal collection of potential issues 6 fold, plus it could apply to any other H.264 stream from any source).

[Guest]

however the fact that it applies to the AVC stream on its own What do you mean by that? You have a 2D stream that fails?

[r0lZ]

Yes, the problem with Pacific Rim is in the AVC stream (and, of course, also in the MVC stream, since it depends of the AVC).
I have not Escape from Planet Earth, but I suppose the problem is similar.

[Guest]

Where is this stream? I have seen the error only when decoding MVC.

[Thalyn]

You can use the same ones I've provided (linked in my last post), though it may satisfy your curiosity better if you split them again. I don't know about EAC3To, but tsMuxer can split already-combined streams.

My AVC tests were done using streams from the original disc (Pacific Rim), both extracted from the SSIF and individually from the M2TS to limit taint. A similar (I can't say identical because I haven't done a screen-capture comparison) issue presents in what appears to be exactly the same place. I checked it initially with DVIM and FRIM, and also with Handbrake (via VidCoder) since the newest versions have a QuickSync path that was co-developed with Intel (you actually have to manually disable QuickSync decoding in the latest Handbrake nightlies, even if you're not using the QSV encoder) and the results persisted.

So, in fairness, it's not strictly a 2D stream as it's a stream from a 3D movie. However, it's 2D in the sense that it was only the AVC stream without any interaction at all with the MVC stream. A thought occurs as I type this and tomorrow I'll check the 2D disc to see if it gives the same error.

PS Dredd (the 2012 one) worked perfectly start to finish. No visible issues to speak of on any frame, even through to the end of the credits. Some beautiful cinematography in that movie (and some very trippy lighting).

*ed: Screw tomorrow - I'll check it now. Interesting initial observation on scanning the original disc, though:
[h264 @ 000000001b664420] non-existing SPS 0 referenced in buffering period
[h264 @ 000000001b664420] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing SPS 0 referenced in buffering period
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] SEI type 83 truncated at 40
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b669960] non-existing SPS 0 referenced in buffering period
[h264 @ 000000001b669960] non-existing PPS referenced

Kicking along at 80fps+ thanks to the QSV encoder in Handbrake!

[Guest]

OK, I see it decoding 00098.264 by itself, and that same file is played fine by DGDecNV. So, I will use this one to discuss it with Intel.

What tool is producing the trace you gave?

[Thalyn]

That's the feedback from the scan log in VidCoder 1.5.16.0 beta (x64) when selecting the 2D BluRay as the source. Interestingly I just gave it a try with Handbrake proper (xvn5965 nightly) and it outright crashed citing an APPCRASH in "StackHash_87bd".

Loading the 3D one into VidCoder gives the following feedback:
[h264 @ 00000000265912a0] non-existing SPS 0 referenced in buffering period
[h264 @ 00000000265912a0] SEI type 30 truncated at 56
[h264 @ 00000000265912a0] non-existing PPS referenced
[h264 @ 00000000265912a0] SEI type 2 truncated at 56
[h264 @ 00000000265912a0] non-existing PPS referenced
[h264 @ 00000000265912a0] SEI type 4 truncated at 56
[h264 @ 00000000265912a0] non-existing PPS referenced
[h264 @ 0000000026590a80] non-existing SPS 0 referenced in buffering period
[h264 @ 0000000026590a80] SEI type 10 truncated at 56
[h264 @ 0000000026590a80] non-existing PPS referenced
[h264 @ 0000000026590a80] SEI type 2 truncated at 56
[h264 @ 0000000026590a80] non-existing PPS referenced

That said, VidCoder was able to fully process the 2D version of the film with no apparent errors, or it at least had them in different spots (I didn't look elsewhere - just the two errors I know about). The 2D and 3D versions are compressed differently on the discs, however, as there's only 7.3GB difference between the two source SSIFs and the MVC stream is 9.9GB.

To me, this suggests it isn't an issue with the studio and how it made the streams to begin with, unless it's just a lucky co-incidence (or unlucky, depending upon which stream you're referring to).

Unrelated side note: The QSV encode ran at 84fps (37:29 elapsed time) with CPU usage in the teens and GPU usage around 80% with a few tweaks to increase the quality and CQP set at 18. Resulting filesize was 10.6GB and the quality is pretty good but, if I'm honest, a little disappointing as it smears some detail (like skin texture). But if speed is your #1 priority it'd be extremely hard to beat!

[osgZach]

It can decode normal AVC as well.

Think of it as a trial run for a version of DGDecNV that will use the Intel Media SDK rather than NVidia's CUVID. The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.

Ah, cool.. :D

I haven't had a Nvidia GPU for ages so my license is practically worthless.. It sounds like it would allow me to use DGDecNV again, if I had a Quicksync setup then?

I know you said the source filter will be open, which is cool. Would it have an indexer like the other DG tools? (right now seems like it doesn't?).

[Guest]

It sounds like it would allow me to use DGDecNV again, if I had a Quicksync setup then? No, but you could use the new toolset, not the older DGDecNV.

I know you said the source filter will be open, which is cool. Would it have an indexer like the other DG tools? (right now seems like it doesn't?). I said that DGMVCSource() will be open, and it is. The new DGDec I am working on will not be open source. The former is linear decode only while the latter will have full frame accuracy via indexing, etc.

[osgZach]

Ok, so just so I make sure I am understanding.

There will be a brand new tool released, that I can buy a license for, and it won't be restricted to Nvidia hardware.. Yes?

[Guest]

Ok, so just so I make sure I am understanding.

There will be a brand new tool released, that I can buy a license for, and it won't be restricted to Nvidia hardware.. Yes? Correct.

[Audionut]

Excellent, thanks Don.

I've stayed away from decoding/encoding 3D until now since it's always been to much flaffing around. With SSIF support, that will mean one less step :P

Thanks again.

[HWK]

No, but you could use the new toolset, not the older DGDecNV.

I said that DGMVCSource() will be open, and it is. The new DGDec I am working on will not be open source. The former is linear decode only while the latter will have full frame accuracy via indexing, etc.

Correct.

Do you need me to donate again, or donation I made for dgdecnv will cover it. Just want to confirm how license system gone work?
Also will dgdec work with mvc source.

[Guest]

I haven't decided about licensing yet. Anyway, the chick needs to hatch first. Yes, I plan to support MVC decoding in DGDec.

[HWK]

I haven't decided about licensing yet. Anyway, the chick needs to hatch first. Yes, I plan to support MVC decoding in DGDec.

Thank you, for information.

[allanlee]

I've done a series of test, regarding the bad frames' problem using a short clip from Pacific Rim provided here by Sharc (http://forum.doom9.org/showthread.php?p=1666166#post1666166) and here by Thalyn (http://forum.doom9.org/showthread.php?p=1666217#post1666217).

Results: (use 00098.zip as example, pr.zip give exactly identical conclusions)
1. Using CoreAVC(CoreMVC) based DirectShowMVCSource and ssifSource2 (CoreAVCDecoder.dll from MVCtoAVI 0.33), ssif file muxed by tsMuxer3D (ISO mode).
No problem at all, receiving 100 valid SBS frames. This is what expected - decoder performed well, and the source should not have problem. (or CoreMVC is robust enough to correct them)
LoadPlugin("DirectShowMVCSource.dll")
DirectShowMVCSource("00098.ssif", stf=14)
Lanczos4Resize(1280,360)
LoadPlugin("ssifSource2.dll")
ssifSource2("00098.ssif",100,true,true,true)
Lanczos4Resize(1280,360)

2. Using DGMVCSource(100b22), FrimSource(1.22x86), MVCSource(2.0 from BDtoAVCHD v1.9.5)
6 bad frames (48~54), total 77 valid SBS frames received (including bad ones)
LoadPlugin("dgmvcdecode.dll")
vid=dgmvcsource("00098.264","00098.mvc",view=0,frames=100)
left=vid.selecteven()
right=vid.selectodd()
StackHorizontal(left,right)
Lanczos4Resize(1280,360)
LoadPlugin("FRIMSource.dll")
FRIMSource("mvc","00098.264","00098.mvc","sbs",num_frames=100)
Lanczos4Resize(1280,360)
LoadPlugin("MVCsource.dll")
V=MVCsource("00098.264", "00098.mvc", 100, 2)
R=SelectOdd(V)
L=SelectEven(V)
return StackHorizontal(L,R).Lanczos4Resize(1280,360)

3. Using ssifSource4.1 by slavanap (posted here (http://forum.doom9.org/showthread.php?p=1667073#post1667073))
77 GOOD frames received.
LoadPlugin("ssifSource2.dll")
ssifSource("00098.ssif", 100, horizontal_stack = true, intel_params = "-d3d", debug = true)
Lanczos4Resize(1280,360)

And I've done some further test as well:
a) try to feed m2ts streams from the ISO created by tsMuxer3D to FrimSource, no luck;
b) suspected that avc/mvc combining tool may be the problem - feed the combined avc+mvc stream to the sample_decode.exe (from ssifSource4.1 package), and view the decoded YUV. -- sample_decode.exe worked well with combined stream. Both MVCCombine.exe and dgmvccombine102 tested, same result.
# sample_decode.exe mvc -d3d -i 00098Combined.h264 -o 00098D.yuv
L=RawSource("00098D.yuv_0.yuv",1920,1080,"I420")
R=RawSource("00098D.yuv_1.yuv",1920,1080,"I420")
StackHorizontal(L,R).Lanczos4Resize(1280,360)
c) noticed that ssifSource4.1 calls x64 Intel Media SDK library as default, I tested both x86 & x64 - both give good frames;
d) noticed that ssifSource4.1 uses a different version of Intel Media SDK (4.12.12.3), when DGMVC/Frim use 5.13.12.7. I swapped the dll, but no luck;

Seems that:
- Intel Media SDK can give the correct frames, which was told by ssifSource4.1
- the only differences are the "calling interface" of the Intel dlls, e.g. sample_decode.exe and the AviSynth source filters

I'm really confused with all these results @_@ , but I have to admit slavanap did provide a solution (http://forum.doom9.org/showthread.php?p=1667080#post1667080). However, the key is likely to be at sample_decoder.exe, but may not be the demuxer (http://forum.doom9.org/showthread.php?p=1667274#post1667274).

Some other questions:
1) Anybody know how to dump the output from the directshow MPC MPEG2Splitter to files? The cause of the bad frames can be confirmed by feeding the elementary streams demuxed by the directshow filter to DGMVC/Frim etc;
2) Difference of frame number: DGMVCCombine tells "100 frams processed", CoreMVC returns 100, Intel returns only 77. It could be a problem caused by splitting of the file - anyhow not a big issue.

Hope these results can be reproduced and help solving the problem.

P.S. test platform - AvsPmod 2.2, VirtualDubMod. Intel Media SDK worked in sw mode.

[r0lZ]

I did several similar tests, and I can confirm your findings. It seems that the bug is NOT in the Intel Media SDK.

BTW, allanlee, how did you ran ssifSource4.1 with the "Pac1 (source 192 frames).264" sample file? AFAIK, ssifsource4 works only with SSIF file, and I have been unable to use it with the short sample files.

Now the question is: What is causing that bug in DGMVCSource and FRIMSource? Maybe slavanap has replied to that question here:
Maybe this MPEGSplitter I used to demux the ssif-file (instead eac3to & tsMuxer) can fix this issue with the films.
The same MPEGSplitter used with CoveAVCDecoder for ssifSource2 & DirectShowMVCSource, though it delivers both (main & dependent) streams independently right into CoreAVCDecoder.

[Nico8583]

Thanks for your tests :)
Like allanlee & r0lZ said, there is 2 causes possible :
- Intel Media SDK 5.* has introduced a bug in MVC decoding, but dll swap between 4 and 5 could solve the problem
- MPEGSplitter can fix the issue
Does anyone tried to use a CombinedMVC with DGMVCSource and FRIM ? And demux with eac3to and tsMuxeR with and without SEI data insertion ?

[Sharc]

I tried with lib 4.xxx, 32 bit. No luck, same problem.

[Nico8583]

Perhaps 4 and 5 coding is different :confused:

[r0lZ]

No, v4 and 5 give the same results. Good with ssifsource4, and bad with DGMVCSource, FRIMSource and NVCSource. IMO, it's the demuxer or the combiner that is the culprit. (I'm still doing tests, but so far it's my conclusion.)

[Nico8583]

Have you tried v5 with ssifsource4 ?
It's strange, all of 3 decoders use a different combiner or demuxer :confused: perhaps it will work with eac3to or tsMuxeR and MVCCombine ?

[Sharc]

eac3to or tsMuxeR for demuxing did not mak a difference in my tests. Same Problem with both.

[Nico8583]

Have you tried to demux AVC and MVC (with eac3to or tsMuxeR) and use MVCCombine.exe to create a single H264 file as source ?

[Sharc]

Not sure, I don't remember. Thalyn has done such test IIRC.

[allanlee]

BTW, allanlee, how did you ran ssifSource4.1 with the "Pac1 (source 192 frames).264" sample file? AFAIK, ssifsource4 works only with SSIF file, and I have been unable to use it with the short sample files.


2 methods:

(1) Use tsMuxer(3D) 2.6.11, mux the AVC & MVC elementary streams to BluRay(3D) ISO file, you get ssif (for ssifSource and CoreMVC decoders) and separated m2ts (for Frim, ts input)

(2) Since ssifSource4.1 is a connected pipeline, I've tried to break it apart. What I have done is just ignore the AviSynth plugin first, use only sample_decode.exe from the package to decode the combined avc+mvc stream to YUV files, and check.
I tried both MVCComibine.exe and DGMVCCombine (102), same result - sample_decode.exe always give good frames.


Like allanlee & r0lZ said, there is 2 causes possible :
- Intel Media SDK 5.* has introduced a bug in MVC decoding, but dll swap between 4 and 5 could solve the problem
- MPEGSplitter can fix the issue
Does anyone tried to use a CombinedMVC with DGMVCSource and FRIM ? And demux with eac3to and tsMuxeR with and without SEI data insertion ?

What I have done:
(1) swap the dlls for DGMVCSource/FrimSource/MVCSource and ssifSource4.1;
Result: always bad frames from the former 3 filters and always good ones from ssifSource4.1, so seem to be no bug for both versions in Intel dll.
(2) feed Combined avc+mvc into sample_decode.exe (which is using by ssifSource4.1), described above
Result: still good frames, that means the 2 combiners should not have problem, or at least sample_decode.exe is more robust that the other 3 and can fix some slight errors.
(3) Tried to cross-check. But I failed to dump the output from MPEGSplitter to files. If I can feed them to DGMVCSource/FrimSource/MVCSource, problem will be more clear.
I'm sure slavanap can help with that.


IMO, it's the demuxer or the combiner that is the culprit. (I'm still doing tests, but so far it's my conclusion.)
sample_decode.exe from ssifSource4.1 worked fine with combined streams, and actually ssifSource4.1 uses MVCCombine.exe in its pipline.


My conclusion is:

Seems that:
- the only differences are the "calling interface" of the Intel dlls, e.g. sample_decode.exe and the AviSynth source filters

Here is the most likely to be where the problem lies. But obviously, more tests need to be done to confirm.

[Thalyn]

Not sure, I don't remember. Thalyn has done such test IIRC.

I've used tsMuxeR and EAC3to, both separated and pre-combined, and extraction from the MakeMKV results - all produce the same end results when using FRIM or DGIM. There is some slight variation in the raw streams produced by each (they're not bit-identical) but that doesn't seem to have any effect at all on the output.

This makes things all the more curiouser, if that's even a real word.

On the plus side, if Sample_Decode works than it's possible that the solution is somewhere in the source code there-of, so perhaps a fix isn't too far off. I doubt it's called "Sample" without including source code, anyway.

[r0lZ]

(3) Tried to cross-check. But I failed to dump the output from MPEGSplitter to files. If I can feed them to DGMVCSource/FrimSource/MVCSource, problem will be more clear.
I'm sure slavanap can help with that.I've tried too, but without luck.
I hope slavanap can help us demux with MPEGSplitter, to isolate and confirm the origin of the problem.

[r0lZ]

Does anyone tried to use a CombinedMVC with DGMVCSource and FRIM ? And demux with eac3to and tsMuxeR with and without SEI data insertion ?The last check I did was without SEI data insertion. Same result.

[Thalyn]

Well, I just finished off the last of my 3D movie collection using DGMVC. 52 movies in all from a reasonable cross-section of studios and distributors and none of the others exhibited the same issue as Pacific Rim, in so much as they all remained perfectly in sync from start to finish. That's not to say that none of the others had any errors at all as I've not watched through them all frame-by-frame but quick analysis has found nothing worth mentioning - save Escape of course.

I realise we've already found a potential source of this issue but it really does seem to be extremely isolated, so it's rather lucky (or unlucky, depending on your view) that we even discovered it at all.

PS Yes I did also try with SEI/VUI insertion, leaving it as-is and rebuilding, as well as with and without SPS/PPS. Slightly different (not bit-identical) source files, same output.

[Nico8583]

Thanks for your feedback. For Pacific Rim, do you try allways with 2 inputs file (AVC and MVC) or have you tried with a Combined created by MVCCombine.exe (Neisklar) ?

[allanlee]

Thanks for your feedback. For Pacific Rim, do you try allways with 2 inputs file (AVC and MVC) or have you tried with a Combined created by MVCCombine.exe (Neisklar) ?

Tested just now - DGMVCSource/FrimSource/MVCSource give same output as separated avc & mvc stream input, when using the combined stream created by either MVCCombine.exe (Neisklar) or DGMVCCombine (102).

The sample_decode.exe from ssifSource4.1 accepts only combined stream, both combined streams mentioned above can be decoded without problem.

[Nico8583]

So I don't know where could be the problem :confused:

[r0lZ]

It's relatively simple. The Source filters that fail are all using demuxed files (with tsMuxeR or eac3to), combined with a variant of MVCCombine. ssifsource4 doesn't fail, and it demuxes with the MpegSplitter_mod.ax filter, and it combines the video streams with its own combiner. So, the problem is either in the demux by tsMuxeR or eac3to, or in the MVCCombine method. To determine more precisely the origin of the problem, we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4.

[Guest]

we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4. Is the ssifsource source code available?

[r0lZ]

Currently, no. But I'm sure slavanap can share it, or at least help you.
BTW, ssifsource4 (w/o the source) is available here (http://forum.doom9.org/showthread.php?p=1667073#post1667073).

[allanlee]

It's relatively simple. The Source filters that fail are all using demuxed files (with tsMuxeR or eac3to), combined with a variant of MVCCombine. ssifsource4 doesn't fail, and it demuxes with the MpegSplitter_mod.ax filter, and it combines the video streams with its own combiner. So, the problem is either in the demux by tsMuxeR or eac3to, or in the MVCCombine method. To determine more precisely the origin of the problem, we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4.

I suppose that the MVCCombine.exe ssifSource4.1 uses is an old version of Neisklar's work, somewhere after here (http://forum.doom9.org/showthread.php?p=1599681#post1599681), here (http://forum.doom9.org/showthread.php?p=1600201#post1600201) and before here (http://forum.doom9.org/showthread.php?p=1628058#post1628058). (Running through that HUGE thread is really big work....)
It's a 0.2 version, even before implanting the pipe support.

Tried again to feed the combined stream produced by the MVCCombine.exe (0.2, used by ssifSource4.1) to DGMVC/Frim, still bad frames.

-- Can I have a conclusion that:
(1)at least until the combined streams are "no errors", and
(2)because when DGMVC/Frim and ssifSource4.1 using identical Intel dll, identical combined avc+mvc stream, but produce different decoded frames, there likely to be problems in how the combined stream handled to the dll (decode lib), or how the decoded YUV frames fetched back from it
?

:confused:

[Thalyn]

It's relatively simple. The Source filters that fail are all using demuxed files (with tsMuxeR or eac3to), combined with a variant of MVCCombine. ssifsource4 doesn't fail, and it demuxes with the MpegSplitter_mod.ax filter, and it combines the video streams with its own combiner. So, the problem is either in the demux by tsMuxeR or eac3to, or in the MVCCombine method. To determine more precisely the origin of the problem, we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4.

Just to check this, using the streams I previously uploaded (Pac1 specifically), I tried loading them into a .ts so SSIFSource4.1 can get at them. This means it's already gone through all of the demuxing and what have you, so the only differences will be the way SSIFSource calls the decoder or the way it merges the streams internally.

Previewing with VirtualDub gave the same basic problem as experienced with DGMVC and FRIM. It didn't appear identical but it was in the same place, and it was actually followed by a brief second error. It was accompanied in the debug windows with the following:
Frame 121 written (100.00%) - 0:00:10 - 0:00:00
will terminate: \\.\pipe\bluray29730\dept_merge.h264
AnnexBReader-Thread ended: \\.\pipe\bluray29730\dept_merge.h264
will terminate: \\.\pipe\bluray29730\base_merge.h264
AnnexBReader-Thread ended: \\.\pipe\bluray29730\base_merge.h264

Decoding just the AVC stream doesn't give the extra "hic-up" using SSIFSource - just the one experienced when using DGMVC or FRIM. To me this suggests the extra glitch is the fault of the combiner in this case.

If you ask me, this just makes things worse, though. It suggests even more that the method of extraction is causing the problem, but that doesn't explain why the AVC stream can be decoded so easily and correctly with non-Intel libraries.

It does, however, suggest that simply using this alternative stream-reading tool (which I'm taken to believe is from MPC-HC and open source) could alleviate the problem entirely, whether it's as a separate demuxer or as part of the source plugin.

[slavanap]

I even don't know to what thread I should respond :)

Well, the way how to dump MPEGSplitter_mod.ax output is:
Install GraphStudioNext (you may already have one with "K-Lite Codec Pack Full" installed).
Insert splitter from file: Graph->Insert filter from file... menu.
Choose the .ax file, and use this GUIDs:
MPC MPEG Splitter {DC257063-045F-4BE2-BD5B-E12279C464F0}
or
MPC MPEG Source Splitter {1365BE7A-C86A-473C-9A41-C0A6E82C9FA3}

After inserting the filter into the graph you can insert the source filter, and dump the output pins output (right click -> dump). Output pins will appear after connecting input pin or opening the source.

Also you can use next version of ssifSource4, set stop_after = SA_DEMUXER, and specify avc264 & mvc264 for dest files.
http://rghost.ru/52455885
http://forum.doom9.org/showthread.php?p=1668501#post1668501

P.S. @allanlee Nothing special about sample_decode.exe. I just got one from here:
"c:\Program Files (x86)\Intel\Media SDK 2013\samples\_bin\x64\sample_decode.exe"

[allanlee]

Thank you so much, slavanap!

Managed to write the output of MPCHC filter to files:
(1) if the ssif is generated by tsMuxer3D (using elementary streams), the demuxed avc & mvc streams have the same md5 & sha1 compared to the original ones. Therefore, feeding MPCHC filter demuxed streams into DGMVCSource of course still have bad frames. :-(
(2) if the ssif is from original BluRay - eac3to demuxed ones and MPCHC filter demuxed ones are slightly different. (Tried with some sample clips) Since I don't have the Pacific Rim 3D BluRay here, currently I'm not able to run through the whole stream.
But personally I suppose that the demuxing step - use eac3to/tsmuxer3D/MPCHC/whatever-else should NOT be the source of problem.
Even the same combined avc+mvc stream will have different decode results - ssifSource4.x return good frames while DGMVC/Frim/MVCSource have problem. There must be some hidden bugs (or at least different algorithm compared to ssifSource4.x) after the "combined stream" step with DGMVCS/Frim/MVCSource.

[Thalyn]

Ran through the whole stream as demuxed from the source disc using a Graph to create the elementary streams. Same problem in the same place. Granted there's two different GUIDs I could choose from and I haven't tried both (I picked the Source Splitter), I'm still reasonably sure now that it's not the way the streams are demuxed that's causing the problem.

With that said, it appears Pistacho may have found a work-around. Not a fix, but still something usable in the short term for people who just want to get the movie done. All going well he'll share this info with Neuron2, or at least point him in the right direction (it sounds like it's something to do with using SW mode instead).

*ed: So this is interesting. ssifSource4 (first release) with its default settings works, aside from an issue I'm certain is the combiner which could be as a result of the cropped streams (testing with Pac1 - the extra issue occurs just after the one we've been troubleshooting and can be ignored). Changing the "intel_params" value, however, can make it trigger the problem:
The default "-d3d" is fine.
Changing to "-d3d -hw" is not fine, plus it runs slower, still uses SW and reverts from SDK v1.8 to v1.7.
Changing to "-d3d11 -hw" is not fine, reverts the SDK but does use HW.
Changing to "-hw" is not fine, reverts the SDK, still uses SW but runs better.
Changing to "-d3d11" caused VirtualDub to crash, probably because of whatever dismissed the Intel Media debug screen.
Changing to "" is fine (just uses System surfaces).

I'm gonna do another test with FRIM (since it gives identical results to DGMVC at the moment) and set it to software w/D3D surfaces. There's only one common element I can see here: everything which causes it to revert from v1.8 to v1.7 is problematic. According to the information I can find it should only revert when using hardware, pending a new driver (and possibly Broadwell's iGPU), which makes it weird it would do it while still claiming software mode. *end ed*

*2nd ed: 3:30 later and the results are inconclusive. Unfortunately the same issue presented but I have no way to determine whether setting "platform" to "sw" and "memory" to "d3d" results in FRIM using 1.8 instead of 1.7. *end*

*3rd ed: Nevermind. It was my fault the log wasn't being produced. Now that I have it logging I can see that it's still using 1.7 when set with those options, which explains why the issue persisted. *end*

*4th ed: Managed to get FRIM to use 1.8. Seems it just wanted a restart, as tends to be the fix for so many things. Will run Pacific Rim again tonight and report back. *end*

Also, has there been any word from Intel yet, Neuron2? When I got in touch with them over some driver issues they got back to me pretty quickly so I'm hoping they've at least acknowledged the issue. Seems they're the only ones who can really fix this by back-porting whatever they changed in 1.8 to 1.7.

[Guest]

Also, has there been any word from Intel yet, Neuron2? When I got in touch with them over some driver issues they got back to me pretty quickly so I'm hoping they've at least acknowledged the issue. Seems they're the only ones who can really fix this by back-porting whatever they changed in 1.8 to 1.7. I haven't posted about it yet at their forum, as I am currently focused on getting DGDecIM born. As I mentioned, anybody can post about it, and in any case, you have done more research about it than I have. I will be collecting all broken samples and posting about them but not for a while. Go ahead and post about it if you need immediate attention for it.

[Thalyn]

Gah! Got FRIM running again, the logs claim API v1.8, and it still has the errors. Even managed to get it running with the smaller fragments for quicker testing (apparently it wanted to use DLLs from at least 3 different locations) and they're glitching in FRIM where they don't in ssifSource4.

I... am at a loss.

[Guest]

Pistacho explains it in his thread:

http://forum.doom9.org/showthread.php?p=1669072#post1669072

He also tantalizes us with claims of 700fps decoding.

[pistacho]

Some had already realized this fact:
http://forum.doom9.org/showthread.php?p=1664548#post1664548

But it's also a fact that in this forum if you speak good of me or of my applications you become a loser... :D

[Thalyn]

Huh... interesting. I wonder if that means the issue continues into the 2014 SDK?

[jdobbs]

Some had already realized this fact:
http://forum.doom9.org/showthread.php?p=1664548#post1664548

But it's also a fact that in this forum if you speak good of me or of my applications you become a loser... :DWow. I hope you didn't mean that like it sounds...:confused:

[sef]

...you become a loser...

??? Do not understand..

..wants to talk about an older "discussion" between me & others members and him..

I remember, the "discussion" .. ;)

[Stereodude]

Wow. I hope you didn't mean that like it sounds...:confused:Well, he didn't exactly get a warm welcome (http://forum.doom9.org/showthread.php?t=170004).

[Nico8583]

I think pistacho wants to talk about an older "discussion" between me & others members and him, but it's past ;)

[jdobbs]

There's never a good excuse for bad behavior...

[Guest]

Guys, let's please stay on topic.

@pistacho

Don't tar everyone with the same brush. I have publicly praised and defended you and I'm sure many others also appreciate your work.

[Nico8583]

@neuron2 : Do you plan to release a version with "workaround" gives by pistacho ?

[Guest]

No, I won't back off to an older Intel Media SDK. Anyway, it is still broken for HW decoding. Better to get a proper fix from Intel. When I finish the DGDecIM basic functionality I will address problem streams.

[Nico8583]

Ok thanks :) DGDecIM will be released on another topic or here ?

[Guest]

You haven't noticed this thread?

http://forum.doom9.org/showthread.php?t=170237

[Nico8583]

Shame on me, I have not browsed this section... Thanks !
Edit : Does MVC will be included in DGDecIM or DGMVCSource will stay only decoder for MVC ?

[jdobbs]

You haven't noticed this thread?

http://forum.doom9.org/showthread.php?t=170237I'm glad you posted this link... I somehow missed that thread entirely.

[Guest]

It's weird. Doesn't everybody just hit Quick Links/Today's Posts every day?

Think of all the other things you're missing! :scared:

[Guest]

Does MVC will be included in DGDecIM or DGMVCSource will stay only decoder for MVC? At some point it will be added to DGDecIM.

[Nico8583]

Ok thanks :-) I'm following DGDecIM topic ;-)

[Nico8583]

I'm testing b22 but I had a problem : Unable to load dgmvcdecode.dll
So I've followed 3D topic and I've seen sef said it is necessary to install VC++ 2012 in order to dgmvcdecode works. And yes it works after install vcredist_x86.exe.
My question : is it possible to include dll with dgmvcdecode ? Or it's a particularity of VC++ 2012 ?
Thanks !

[Guest]

I'll look into that. Thanks for pointing it out. Does it apply to DGDecodeIM also?

[sef]

..Does it apply to DGDecodeIM also?

HI neuron2. No unnecessary. Although, I conclude only dgdecodeim_b2..

[Guest]

Hi sef! Thanks, it's probably just my linking options then. Ciao.

[qupfer]

Hi, what is the fasted (easiest) way to get the number of frames of a h264-video?

mediainfo doen't show it (yes, i switched to expert-mode).
At the moment, i create a avs-file for the "left.264" file (created by eac3to) and open it in virtualDub, skip to the last frame and note the number. But I think, this way is a little bit awkward :D

[Guest]

Things are different for elementary streams versus transport streams versus containerized streams. Specifically, what is the type of your video file? Also, is this for programmatic use by another application? What do you do with the number of frames?

If this is for counting frames to have the correct parameter to pass to one of the available MVC source filters, then any ad hoc method, such as yours, will suffice. I believe you can also use eac3to for counting frames. This will be mitigated when MVC support is added to DGDecIM.

[Sharc]

Workarounds which have been suggested to obtain the number of frames:
- open the files in MPC-HC, go to the end and press CTRL+G
- open a script in AvsPmod, start the internal player ad see the number of frames in the status bar
- get the duration from the playlist (e.g. with BdEdit or similar) and calculate the number of frames based on the framerate

[KreuzBlick]

@qupfer
You can open the h264-video with DirectshowSource() and use the property framecount().

[r0lZ]

I have received this PM from a user of BD3D2MK3D:
BTW, I noticed that you have a couple of libraries compiled with visual studio 2012 and starting _ENCODE.cmd it displays an error that avisynth cannot load dgmvcdecode.dll and breaks, but it doesn't display that popup message that it is missing msvcr110.dll. I've checked dgmvcdecode.dll with dependency walker and then saw that it is missing msvcr110.dll. Instaling VS 2012 redistributable fixed the problem.
I did not know that DGMVCSource requires a redistributable package, and it's obviously a bad thing (due to M$, not you).
Can you compile a static, standalone version of DGMVCSource ? If it's not possible, can you check if the dependencies are present, and if it's not the case, issue a meaningful error message ?
Or is it sufficient to copy msvcr110.dll in the same directory than DGMVCSource.dll ?

Thanks!

[Groucho2004]

I did not know that DGMVCSource requires a redistributable package, and it's obviously a bad thing
I just checked the latest DGMVCDecode.dll and it does not require the runtime.
Also, it's certainly not a bad thing to use dynamic linking with up to date runtime libraries. It's just annoying (IMO).

[Guest]

Earlier versions had the dependency. As Groucho2004 says, the latest one does not.

[r0lZ]

Oh, yes, sorry. For whatever reason, the version included with the beta of BD3D2MK3D was not the latest. I've downloaded the latest one, and now it's perfect.

[Sharc]

I re-downloaded DGMVCsource100b22 (dated 12.03.14) and found that the size of DGMVCdecode.dll is 402k. The version which I had on my HD is also 100b22 (dated 03.02.14) and has a much lower filesize of 62k only. Just wondering why there is such a difference.

[Groucho2004]

I re-downloaded DGMVCsource100b22 (dated 12.03.14) and found that the size of DGMVCdecode.dll is 402k. The version which I had on my HD is also 100b22 (dated 03.02.14) and has a much lower filesize of 62k only. Just wondering why there is such a difference.
Probably one of neuron2's silent slipstream updates where he changed from dynamic to static linking. Static linking requires all necessary code that usually resides in the runtime libraries to be linked into the binary.

[Sharc]

Probably one of neuron2's silent slipstream updates where he changed from dynamic to static linking. Static linking requires all necessary code that usually resides in the runtime libraries to be linked into the binary.
Oh I see. Yes, this possibly explains it.

[CaBleman]

'lo there,

sorry if this counts as a crosspost; and I don't know if it is directly related to DGMVCsource, but maybe it's of interest:
Please see a description of symptoms and error messages here in this entry (http://forum.doom9.org/showthread.php?p=1697429#post1697429) (and others) in the BD3D2MK3D thread...

In short: with hw=0 or hw=2 in the function call, it seems that blank/black frames are being decoded & served. With hw=1 it works fine.
Could this be due to the relatively new Haswell Refresh processor I5 4590S that I operate under Win 8.1?

Any hint is appreciated!

thx & bye,

CaBleman

BTW, I'm a happy "customer" for DGDecNV which I use on another system (Laptop with nVidia GFX)... ;)

[Selur]

If you want to contact Donald Graft you should post in his forum (http://rationalqm.us/board/index.php), which is afaik atm. the only official source for DG* support from Donald himself.

[tebasuna51]

Please guys, peace.

I removed 2 post because forum rule "4) Be nice to each other..."

I can't understand for what we need reopen this thread after 5 years.

And I removed 3 post because rule "8) No cross posting. Post your message once..." https://forum.doom9.org/showthread.php?p=1890366#post1890366

[tebasuna51]

I let the link to BD3D2MK3D thread to be know for BD3D2MK3D users.

If you want I can undelete the post here and delete the BD3D2MK3D posts, but the rule 8 is clear.

[Atak_Snajpera]

Because r0lZ is violating my licensing and using my software without permission and I want people to know that.

I object to your censorship.

Sue him ! :)