Free H.264 MVC 3D Encoder

[SpasV]

Sorry my absentmindedness.

The context is avs2yuv64.exe. It is avs2yuv-0.24bm5 - the last version.

When I use ffms2-2.23.1 as a source FFMS2(<"file_name.m2ts">, colorspace = "yuv420p10")
it works and the process displays the mesage:
encode-FFMS2.265.avs: 3840x2160, YUV420P10, 10-bits, progressive, 12500/473 fps, 3171 frames

When I use FRIMSource - FRIMSource(codec="h265", filename=<"file_name.m2ts">, cache=1, num_frames=24, platform="sw")
the mesage is:
avisynth 16-bit hack enabled
encode-FRIM.265.avs: 1920x2160, YV12, 10-bits, progressive, 24000/1001 fps, 24 frames

The same mesage I've got with ffms2-2.23.1 when I used the old avs2yuv64.exe version - avs2yuv-0.24bm3

[videofan3d]

Sorry my absentmindedness.

The context is avs2yuv64.exe. It is avs2yuv-0.24bm5 - the last version.

When I use ffms2-2.23.1 as a source FFMS2(<"file_name.m2ts">, colorspace = "yuv420p10")
it works and the process displays the mesage:
encode-FFMS2.265.avs: 3840x2160, YUV420P10, 10-bits, progressive, 12500/473 fps, 3171 frames

When I use FRIMSource - FRIMSource(codec="h265", filename=<"file_name.m2ts">, cache=1, num_frames=24, platform="sw")
the mesage is:
avisynth 16-bit hack enabled
encode-FRIM.265.avs: 1920x2160, YV12, 10-bits, progressive, 24000/1001 fps, 24 frames

The same mesage I've got with ffms2-2.23.1 when I used the old avs2yuv64.exe version - avs2yuv-0.24bm3

When using file.m2ts (i.e. TS-container), you have to add

FRIMSource(… ,container="ts",...)

For more FRIMSource details see FRIMSource_readme.pdf from distribution...


I'm not familiar with avs2yuv64.exe …

[SpasV]

All plugins are in place, obviously.
Intel/MediaSDKPlugin
C:\Programs\AviSynth+\FRIM_x64_version_1.29\x64\
With container="ts"

error: ERROR: expect more data at input (-10), c:\prj\intelmedia\frim_decode\src\pipeline_decode.cpp (587)
ERROR: expect more data at input (-10), c:\prj\intelmedia\frim_decode\src\pipeline_decode.cpp (262)

[videofan3d]

All plugins are in place, obviously.

With container="ts"

Can you open your script encode-FRIM.265.avs directly using e.g. MPC-HC(x64) media player?
(You need to use some 64-bit media player which is capable to play Avisynth+ scripts. MPC-HC(x64) is able to do it).

If yes then script is correct and problem is somewhere in avs2yuv64.exe - this I cannot help...

If not, MPC-HC(x64) will show you error message to resolve...

[SpasV]

MPC-HC(x64), AvsPmod too, can play the scripts.
When playing FFMS2("file_name.m2ts", colorspace = "yuv420p10") there is a normal 3640x2160 picture.
When playing FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240) there is no picture.
https://imagez.to/i/Rbn3pw4t.png
with FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")
there is the Error message above when I've tried .mkv file.

but FRIMSource(codec="h265", filename="file_name.h265", cache=1, num_frames=240) plays and V: rawvideo, yuv420p, 3840x2140

[SpasV]

@videofan3d
Are you capable of developing an MVC encoder?

[videofan3d]

@videofan3d
Are you capable of developing an MVC encoder?

I'm not sure whether you read the first post of this thread
Free H.264 MVC 3D Encoder (http://forum.doom9.org/showthread.php?t=169651) ...

[videofan3d]

MPC-HC(x64), AvsPmod too, can play the scripts.
When playing FFMS2("file_name.m2ts", colorspace = "yuv420p10") there is a normal 3640x2160 picture.
When playing FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240) there is no picture.
https://imagez.to/i/Rbn3pw4t.png
with FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")
there is the Error message above when I've tried .mkv file.

but FRIMSource(codec="h265", filename="file_name.h265", cache=1, num_frames=240) plays and V: rawvideo, yuv420p, 3840x2140

Send me the script - I'll check it....

[SpasV]

Send me the script - I'll check it....
The scripts:
container not specified - no picture
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240)

container="ts" - error
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")

[SpasV]

As to "I'm not sure whether you read the first post of this thread
Free H.264 MVC 3D Encoder ..."
Sorry, I've missed the important part.

I've tried it and I would like to ask you some questions about:
(Better if there is a written instruction.)
- VBR - avg, maximum; obviously I can change them. But, working with x264, I prefer Constant QP with control over the maximum bitrate.
- are there other parameters avilable
- performance - with no more than 38% CPU load I've got 7 fps.

In general, the most information the better.

[videofan3d]

The scripts:
container not specified - no picture
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240)

container="ts" - error
FRIMSource(codec="h265", filename="file_name.m2ts", cache=1, num_frames=240, container="ts")

So it is only single command FRIMSource() ?
Than it shall work. You have to have something wrong in installation.

Try to check the following:

1. Install FRIM package into single directory, e.g. c:\FRIM
(and remove all other occurrences)
2. Add this directory to PATH
3. set this path into plugins64.reg and load to registry
4. test it first with some h.264 encoded file

[videofan3d]

As to "I'm not sure whether you read the first post of this thread
Free H.264 MVC 3D Encoder ..."
Sorry, I've missed the important part.

I've tried it and I would like to ask you some questions about:
(Better if there is a written instruction.)
- VBR - avg, maximum; obviously I can change them. But, working with x264, I prefer Constant QP with control over the maximum bitrate.
- are there other parameters available
- performance - with no more than 38% CPU load I've got 7 fps.

In general, the most information the better.

FRIMencode32.exe -help will show all options (and there are planty od them - you can play with them and find most suitable for you)

Performance: MVC encoding is heavy process, depending on CPU and also disk speed (using SSD will make it a bit faster). It operates with uncompressed video which is 6 MB per frame! If you have i5/i7, you can use -hw mode (install always latest GPU drivers)

[SpasV]

When I've tried x265 with 3840x2160 frames the CPU load was around 100% and the result was 0.7 fps.
I have 6-core 2 CPU @3.33 GHz 48 GB RAM machine, GeForce GTX 1050. Not shure if x265 used GPUs. Probably not.
HDD @150 MBps siquential read/write. I don't do encoding at all. Now, out of curiosity, I'm trying 3D Blu-ray reencode.

As to the FRIMSource() I'm happy with .264, .265 files.
At the beginning, I've used Intel's SDK plug-ins, later - FRIM's.

[SpasV]

@videofan3d
Is it possible for you to compile an MVC encoder using x265/244 encoder?
I'm not entirely happy with FRIM Encoder - its performance and parameters.

[videofan3d]

@videofan3d
Is it possible for you to compile an MVC encoder using x265/244 encoder?
I'm not entirely happy with FRIM Encoder - its performance and parameters.

You are missing the point:
- x265 is HEVC, it has no MVC - even not defined by norm specification
- x264 is only AVC, it has never ever implemented MVC.
- Intel Media SDK it likely the only free MVC encoder...

But you can purchase the professional one - from Sony... enjoy

[SpasV]

It seems my idea of mvc encoding dosn't work.
It is a cycle:
difference_view=left_eye (subtraction) right_eye;
encoding left_eye;
encoding difference_view;
something more;

Nevertheless I'm runnig SOFTWARE (C:\Programs\FRIM_x64_version_1.29\x64\libmfxsw64.dll)
-length 232608 -profile high -level 4.1 -u 1 -rf 16 -cqp 16 17 19 -Bpyramid on -o:mvc Avatar.h264
and
Processing started (maybe 48 hours ago)
Frame number: 163495
Probably 28 hours to go at 23% CPU load.
Not very bad, anyway.
I've tried two Video Editor software. They are terible with my test.
I doubt they could do 232,608 HD frames at all.

As to "you can purchase the professional one - from Sony..." I'm not a proffesional video encoder.
I, even, don't do Blu-ray re-encoding at all. I'm just trying mvc encoding because nobody does it in my tracker community and I would like to show them results from a working mvc encoder. They do half HD frame size re-encoding only.

Besides, there is a $10k mvc encoder and maybe cheaper.

[r0lZ]

It is a cycle:
difference_view=left_eye (subtraction) right_eye;
encoding left_eye;
encoding difference_view;
something more;
It's not so simple.

The main view (that can be the left or right view) is encoded in h264 (aka AVC). That's theoretically easy to do with x264, although there are specific constraints for a bly-ray.

It is right that the other view contains only the differences. It is called "dependent view" because it depends of the main view. But it is not encoded in h264/AVC like the main view. MVC is not just like AVC applied to a dependent view. I'm not a specialist, but I know that you cannot simply encode the differences in AVC, say with x264, to obtain the MVC stream. It's why it is necessary to use a complete AVC+MVC encoder. And currently, the only free encoder able to do that is the Intel MVC encoder. It is used internally by FRIM, and you cannot change that.

You cannot expect that somebody will spend years in developing alone a new MVC encoder simply because the Intel encoder is not perfect. That would require the work of a big team of very advanced programmers working during several years. Simply impossible, especially given the fact that there is already a free MVC encoder, and that the demand for such encoder is not really important.

[SpasV]

@r0lZ
Thanks for expresing your opinion about an idea for amateur mvc compressor development.

Besides, DVDFab offer a product - Geekit: MVC Codecs
"a professional toolkit specifically designed for those knowledgeable videophiles who have a geek-level enthusiasm for video editing".
It didn't work with my test.

[r0lZ]

Besides, DVDFab offer a product - Geekit: MVC Codecs
Hum, according to what I have read on the DVDFab site, their codec is only able to decode the original MVC streams from a 3D-BD. There is nothing to re-encode in MVC. And for a decoder, it is extremely expensive (75€), especially given the fact that the Intel MVC codec is free, its decoder part works perfectly, and you have the encoder also for free. IMO, buying the DVDFab decoder doesn't make sense.

[EDIT] No, I was wrong. The DVDFab MVC codec can encode in MVC. I don't know if the quality is good, but it remains that it is not free. And they explain that their codec is the only MVC codec available currently. That's not true, as you can use the Intel MVC codec for free.

[SpasV]

I don't know what their MVC codec do. I've tried to get something from it and the result was zero.
First, I wasn't satisfied from the decoder and using FRIMDecode I had two (L/R) raw files I put in mkv container with ffmpeg.
Every file (L/R.yuv and l/R.mkv) were playable.
Second, I've started their MVC encoder and it crashed.

[SpasV]

@videofan3d

Thank you very much for your work. :)
I've tried the MVC encoder and the first impression satisfies me.
I didn't do many test to determine suitable parameters for an encode.
With the idea to have high quality encode I chose at a glance
-u 1 -rf 16 -cqp 16 17 19 -Bpyramid on, so I got
Bitrate control CQP
QPI,QPP,QPB 16,17,19
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 1 (quality)

Then
Processing started
Frame number: 232608
Processing finished in 148433.81 seconds, which is 41:13:54.
The last result seems not very bad - 1.567 3Dfps

These, practically, random chosen parameters for QP:
QPI, QPP, QPB 16, 17, 19
turned out to be as used by the original encoder.
The file sizes, average bit-rate, bit-rate vs time are undistinguished compared to the source. Even the PSNR for every color channel is 100 dB.
Some examples.
encode:10,591 - 21,149 kbps
source: 10,608 - 21,166 kbps


Two screens from left eye frames #27,349 (00:19:00.681) where the bit-rate is about 34 Mbps.

https://thumbs2.imgbox.com/68/85/5EqIODCi_t.png (http://imgbox.com/5EqIODCi) https://thumbs2.imgbox.com/87/89/yEZCKFBo_t.png (http://imgbox.com/yEZCKFBo)

[Emulgator]

Even the PSNR for every color channel is 100 dB.
Would not have thought that. 100dB means fault level of 1/100.000 full scale,
so in a 8-bit world source and encode should be bit-identical. Are they ?

[SpasV]

Practically, yes.
Following this formula:
https://wikimedia.org/api/rest_v1/media/math/render/svg/fc22801ed1232ff1231c4156b589de5c32063a8a
where
https://wikimedia.org/api/rest_v1/media/math/render/svg/3a34719b4f391dba26b3e8e4460b7595d62eece4
In average, the total sum of absolute values for the differences between identical numbered pixels - sqrt(MSE) is
m.n*MAXi*(10 to power of -5) =1920*1080*255*0.00001= 5287.68
So, there could be almost 5,288 pixels out of 2,073,600 whose numbers differ by one, all others are bit-identical.
These are 0.0255%

[jamt]

@videofan3d Thanks for continuing to support this tool, I've been using it with great success for a couple years now.

I had a couple random questions that have been in the back of my mind for a long time. So not really that important but keep meaning to ask..

1) When transcoding from an MVC file the easiest way to do so (from the docs) is something like

FRIMDecode -i:mvc input.h264 input_depend.h264 -sbs -o - | FRIMEncode -sbs 2 -i - -o:mvc combined.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000


This uses sbs as an intermediate format; would tab work exactly the same? I always expected tab would be more efficient since it doesn't require merging & splitting every single scan line during the process, but wasn't sure if there was something special about this scenario leading the docs to recommend sbs.

2) Do you have any sense for whether it's safe to use MVC codec levels above 4.1 on typical devices these days? 3D blu ray discs are always encoded at 4.1; I assume this is some baseline support offered by BD players. But I'm not playing back on a BD player. I assume this would be chipset dependent, but there's basically no information easily available about this setting and device support that I can find, unlike for AVC. Just wondering if you had any ad-hoc experience with higher codec level different settings.

Thanks again!

[videofan3d]

@videofan3d Thanks for continuing to support this tool, I've been using it with great success for a couple years now.

I had a couple random questions that have been in the back of my mind for a long time. So not really that important but keep meaning to ask..

1) When transcoding from an MVC file the easiest way to do so (from the docs) is something like



This uses sbs as an intermediate format; would tab work exactly the same? I always expected tab would be more efficient since it doesn't require merging & splitting every single scan line during the process, but wasn't sure if there was something special about this scenario leading the docs to recommend sbs.

2) Do you have any sense for whether it's safe to use MVC codec levels above 4.1 on typical devices these days? 3D blu ray discs are always encoded at 4.1; I assume this is some baseline support offered by BD players. But I'm not playing back on a BD player. I assume this would be chipset dependent, but there's basically no information easily available about this setting and device support that I can find, unlike for AVC. Just wondering if you had any ad-hoc experience with higher codec level different settings.

Thanks again!

Hi,

thanks for appreciation :-)

Regarding SBS vs. TAB - yes, in this pipe you can use both: SBS as well as TAB. It is only how interim frames are tiled by decoder and then separated again by encoder. Result will be in both cases identical.

Regarding the levels: Technically, level (4.0, 4.1, etc. ) is only number which is written into the AVC stream, and you can theoretically fake it as you want.
But it is not good idea because level number might be (and I guess rather it IS) identified and recognized by particular AVC decoder which may use e.g. it for some buffer pre-settings.
Therefore it is wise to mark the output stream with correct level number according to selected bitrate.

I personally play 3D only from 3D-media player (i.e. not from Bluray-3D player) and I set bitrate around 40 mbit/s (for both base+dependent stream). I have no need to set it higher since my separate L,R video sources are 21 mbit/s at most.

[r0lZ]

Do you have any sense for whether it's safe to use MVC codec levels above 4.1 on typical devices these days?
Full-SBS and Full-TAB require level 5 or above, due to the buffer necessary to hold the double image, and possibly also to the high bitrate. Levels 5 and greater are not compatible with most Full-HD TV, but should be compatible with all UHD players.

Level 4.0 to 4.2 are sufficient for Half-SBS and Half-TAB. The advantage is that level 4.1 is fully compatible with all 3D TVs.

But as videofan3d wrote, the encoder may use the level provided via the command line only to write it in the header, regardless of the real level. It doesn't enforce the corresponding maximum bitrate and buffer sizes. (It's the case at least of the regular branch of x264. Not sure for FRIM.) However, x264 writes the correct level based of the actual max bitrate and buffer size if you DO NOT explicitly provide it. So, IMO, unless you want to encode with a very high bitrate, near the maximum supported by your equipment or a specific level, you should leave the encoder free to write the level it has really used due to the other encoding parameters.

[frank]

Here a fast working script without Avisynth.
First demux the 3D stream or use BD3D2MK3D. Put the two FRIM...exe into toolset folder.

set path=C:\Users\%username%\BD3D2MK3D\toolset;%path%
FRIMDecode64.exe -i:mvc MKV3D.track_1.264 MKV3D.track_1.mvc -alt -hw -o - | ^
FRIMEncode64.exe -alt 2 -i - -o:mvc film3d.264 -hw -d3d11 ^
-viewoutput -w 1920 -h 1080 -f 24000/1001 -icq 22 -profile high -level 4.1 ^
-gop 48 4 0 C -bPyramid off -length 156975 ^
-colorprim bt709 -colormatrix bt709 -colortransfer bt709
length = number of frames
icq = intelligent constant quality, use 20...26
I get about 60 fps!

The dependent mvc stream unfortunately has the same bitrate as the avc main stream. Intel media SDK cannot do it better. :rolleyes:
Normal is about 50 %. So the 3D feature doubles the stream size! Not very effective.

[frank]

@videofan3d
I have a Dell 9560 (Kaby Lake).
There are decoder issues in HW mode on some movies with DGMVCsource or old versions of FRIM. (The Marsian 3D, Geostorm 3D, look my examples -> BD3D2MK3D)
Same issue in BD Rebuilder with it's old FRIM version. The decoder hangs about 10 sec and then you get black frames.
But your latest version v1.29 compiled with SDK 2018 works! :)

So we thought the Intel SDK is the cause, and videoh (Donald G.) compiled his DGMVCsource with the latest SDK. But it doesn't work with this movies, same behavior.

Something else must have changed in your new version, because it works.
Do you have any idea what the cause is? Donald asked it.

[videofan3d]

@videofan3d
I have a Dell 9560 (Kaby Lake).
There are decoder issues in HW mode on some movies with DGMVCsource or old versions of FRIM. (The Marsian 3D, Geostorm 3D, look my examples -> BD3D2MK3D)
Same issue in BD Rebuilder with it's old FRIM version. The decoder hangs about 10 sec and then you get black frames.
But your latest version v1.29 compiled with SDK 2018 works! :)

So we thought the Intel SDK is the cause, and videoh (Donald G.) compiled his DGMVCsource with the latest SDK. But it doesn't work with this movies, same behavior.

Something else must have changed in your new version, because it works.
Do you have any idea what the cause is? Donald asked it.

Actually, I even didn't know there is some issue with decoding. (I personally don't decode/transcode original BD3D)
Therefore - I didn't change anything specific to fix it :)

In 1.29 I made changes mainly related to HEVC and also to include VPP unit into FRIMDecode.
To incorporate VPP I had to rework all internal loops there.
Probably - as positive side-effect of this - something has changed/improved what impacted the previous HW decoding - in positive manner.

It's good it happened :)
But to identify which particular line(s) of code affected it ... it is impossible to find out.
(Really, changes were quite big and spread over all decoding routines)

[videofan3d]

The dependent mvc stream unfortunately has the same bitrate as the avc main stream. Intel media SDK cannot do it better. :rolleyes:
Normal is about 50 %. So the 3D feature doubles the stream size! Not very effective.

Yes, I noticed this phenomenon already few years ago when started FRIM project.
I 3D-encoded the same content for L and R eye (i.e. practically 2D) and I expected that mvc-stream will be almost zero. And it didn't happen.

I also reported it to Intel Media SDK support, they recorded this issue ... and apparently didn't do anything with it.
Maybe they didn't succeed to solve it, maybe it had low priority. Anyway, nowadays when world has decline from 3D I guess they will NOT do any changes in 3D-MVC encoding...

[videoh]

In 1.29 I made changes mainly related to HEVC and also to include VPP unit into FRIMDecode.
To incorporate VPP I had to rework all internal loops there.
Probably - as positive side-effect of this - something has changed/improved what impacted the previous HW decoding - in positive manner. Thanks for the info, videofan3d. I'll probably have to rebase my code off the latest Intel sample code. Or I may just let it be, as you seem to have things covered very well with FRIMSource().

[r0lZ]

Hi Videofan3D.

A BD3D2MK3D user has reported a problem with FRIMSource here (https://forum.doom9.org/showthread.php?p=1869947#post1869947). It seems that with some 3DBD using the unusual view order (base view = right view instead of left), FRIMSource is unable to return the two 3D views correctly. According to the tests the user did, it returns two times the same view, or, if you swap the left and right views in the avisynth script, it returns the two views, but in inverted order. It's very strange. Note that DGMVCSource doesn't have that problem.

Can you have a look ? Perhaps there is something wrong in the script generated by BD3D2MK3D, but it worked fine previously.

Thanks in advance!

[videofan3d]

Hi Videofan3D.

A BD3D2MK3D user has reported a problem with FRIMSource here (https://forum.doom9.org/showthread.php?p=1869947#post1869947). It seems that with some 3DBD using the unusual view order (base view = right view instead of left), FRIMSource is unable to return the two 3D views correctly. According to the tests the user did, it returns two times the same view, or, if you swap the left and right views in the avisynth script, it returns the two views, but in inverted order. It's very strange. Note that DGMVCSource doesn't have that problem.

Can you have a look ? Perhaps there is something wrong in the script generated by BD3D2MK3D, but it worked fine previously.

Thanks in advance!

Could you please send me examples - which BD3D are affected? I will try it.
And also snippet of the script which BD3D2MK3D is using.

Thanks

[r0lZ]

AFAIK, all BDs with the inverted views are affected, notably the Boss Baby, Shrek the Third and Epic. I did my test with the Boss Baby. I will try to cut a sample of the movie...
In the meantime, here is the script:

LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\FRIMSource.dll")
interleaved = FRIMSource("mvc", "00600.track_4113.264", "00600.track_4114.mvc", layout = "alt", num_frames = 2000, cache = 2, platform = "")
right = SelectEven(interleaved)
left = SelectOdd(interleaved)
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))

I know that it is possible to return directly a Full-SBS or Full-TAB image, with the layout option, but BD3D2MK3D requires two different streams, for technical reasons. I haven't tried the direct method.

[r0lZ]

And here is the sample: FRIMSource inverted views bug sample.7z (http://download.videohelp.com/r0lZ/tmp/FRIMSource inverted views bug sample.7z)

[videofan3d]

And here is the sample: FRIMSource inverted views bug sample.7z (http://download.videohelp.com/r0lZ/tmp/FRIMSource inverted views bug sample.7z)

Funny defect :-) (it is there for several years)

I will issue bugfix next weekend.

[r0lZ]

Funny defect :-) (it is there for several years)

I will issue bugfix next weekend.
Yes, I wonder why nobody has noticed it !
Thanks in advance for the update.
BTW, perhaps it is also time to use the new Intel libs.

[videofan3d]

Yes, I wonder why nobody has noticed it !
Thanks in advance for the update.
BTW, perhaps it is also time to use the new Intel libs.

Here is bugfix for FRIMSourceNN.dll (https://drive.google.com/file/d/1GTjAQ659QtWtUBqEfa9n07ErrGI9L_JR).
Would be good if you could independently test it.

(I will provide full release once I complete integration of latest Intel Media libraries 2018R2.1 )

[r0lZ]

Thanks, and sorry for the late reply.

I have just tested the new DLL, with two movies. One has the common views order, and the other has the right-view as AVC stream. Both give the correct 3D effect. It's perfect, but note that I have tested only the 32-bit DLL with the layout="alt" mode and with the software platform. However, I'm pretty sure that the bug is fixed, and I don't think that new bugs have been introduced. So, unless you really think that more testing is necessary, you have my green light to integrate the new Intel libs and release it officially. If you want more testing, please let us know what tests you need.

Thanks again!

[videofan3d]

Thanks, and sorry for the late reply.

I have just tested the new DLL, with two movies. One has the common views order, and the other has the right-view as AVC stream. Both give the correct 3D effect. It's perfect, but note that I have tested only the 32-bit DLL with the layout="alt" mode and with the software platform. However, I'm pretty sure that the bug is fixed, and I don't think that new bugs have been introduced. So, unless you really think that more testing is necessary, you have my green light to integrate the new Intel libs and release it officially. If you want more testing, please let us know what tests you need.

Thanks again!

Fix is independent on HW or SW platform - defect was purely in my code, after obtaining L+R frame from Intel library. Actually, the particular code section is now even clearer and simpler than before.
I checked also SBS and TAB - and seemed to be fine as well.

Version with new Intel libs uploaded (2019-04-16).

[mindsong]

I don't think this is necro-ing a thread - I hope not, as it seems like the right place to ask/archive this info.

I'm struggling with a latest-version-based FRIMEncode<-AVISynth script effort that could be caused by any number of setup errors on my side, so perhaps it would be best to post my simplest example and see if the problem is more widespread, or just my environment, before I pursue it with the gory details.

Could someone with a stable/working FRIMEncode/AVISynth environment try this simple AVIsynth script that generates a basic/short test 3840x1080 SBS stream for encoding into a base.avc+dep.mvc file pair?

AVISynth Script (MyScript.AVS) - creates a simple 100 frame SBS stream:

L = ColorBars(1920,1080,"YV12")
L = KillAudio(L)
L = Info(L)

R = ColorBars(1920,1080,"YV12")
R = KillAudio(R)
R = Info(R)

V = StackHorizontal(L,R)
V = Trim(V,0,-100)
# redundant, but...
V = ConvertToYV12(V)
return(V)


FRIMEncode command:

FRIMencode32 ^
-avi ^
-i MyScript.avs ^
-sbs 2 ^
-viewoutput ^
-o:mvc 01_base.avc 01_dependent.mvc ^
-u 1

It's intended to be as *minimal* as possible, with the real script/workflow doing something that's actually meaningful... (real mpeg2 interlaced 3D -> MVC-3D)

Does this basic sequence work for anyone else, w any specific FRIM and toolset versions? Should it be able to, or have I missed something simple (some import or ...?) ?

I'm using an up-to-date W10 x64 system with a current x86 FRIM/AVISynth/Intel/codec toolchain and I'm seeing a colorspace mismatch. I've tried with a current x64 workflow to the same effect, so any test that works is welcomed, if it's possible. It seems like something FRIMencode is trivially able to do, so I'm wondering what I'm missing.

I'm fairly competent with these tools and environment, so I've got variations, various tool versions, specs, samples, variations, that I can share to ID my specifics, and maybe we can then pursue the fix to my puzzle, but fixing *my* workflow only makes sense if we know that this *can* work at all in anyone's stable environment - so this seems like a safe/easy place to start.

I'd appreciate if anyone could take this quick test for a spin and share their results - or perhaps correct some basic assumptions I'm making as I go down this path.

I've really done a bunch of research and experiments on getting this to work, so any help is truly appreciated at this point.

Cheers, and thanks in advance,

--ms

[videofan3d]

AVISynth Script (MyScript.AVS) …..

FRIMEncode command: … 01_base.avc

… I'm seeing a colorspace mismatch.


I opened MyScript.avs (as defined above) using MPC-HC
and then 01_base.avc (created as defined above) also using MPC-HC...

But honestly - I see identical colorbars on screen.
No visual difference.

So what is the problem?

[mindsong]

hello videofan3d,

Thanks for the reply (and for your great work on this project).

In your short reply, you've confirmed that my system is (still) not configured correctly. Most folks in here are working with a different data-flow (BD-3D to standalone MVC-3D), so I wanted to check to see if my simple test/approach was working for others before hitting up the thread with a "it doesn't work" assertion... Apparently it does work... :)

For me, the 'parts' all seem to be working on their own, but FRIMEncode isn't seeing my simple (or slightly more complex) AVISynth output as I420 and exits before it creates the avc/mvc pair - the error has been mentioned before and most folks have been able to fix their issues. I've read enough to see that the system setup is as likely (or more likely) to be a source of problems as the final FIRM/Intel step, so I wanted to be sure my ultimate target was viable (simple AVS script to avvc/mvc). Thanks for verifying that.


In gory detail, for those that might 'see' my problem, and future readers who go down this debugging path:

As I assumed (and still do) that the problem *is* my system, so my resolution efforts follow:

1) I've worked to match my x86/x64 toolchains with 'proper' (bitwise) versions of the AVISynth, ffdshow/VFW, FRIM, and Intel MSDK as a foundation. (everything is x86 for now)

2) I've then checked to be sure my simple AVS script is viable (it renders fine using AVIsynth 2.60 and AviSynth+ in 32-bit Vdub2, WMP, MPC-HC, and ffmpeg's avs renderer to both pipes and files)

3) I've done everything I know how to ensure that the AVS script outputs are YV12/I420 AVI streams and files, using Vdub2 and ffmpeg - files and pipes show lossless 4:2:0 YV12 or I420 content at various resolutions and framerates. The files/streams/pipes seem to play well enough on the above players and media-info/ffprobe indicate appropriate content/formats

4) I'm pretty certain that my ffdshow layer is causing the issue in the pipeline, but after hacking at that for a day, thought I'd ask some smarter folks to be sure my approach was/is plausible and that the script/workflow wasn't missing some obvious understanding ("of course that doesn't work!..." kind of thing).

5) with ffdshow(-tryout from sourceforge ffdshow_rev4533_20140929_clsid.exe) , the default install (32bit) with the default settings and the VFW decode "RGB raw video" set to "all-supported", I get the mentioned error from the above FRIMEncode32.exe command and script:


ERROR: Cannot get I420 frame from input avi-file MyScript.avs
Frame was written in default format to file MyScript.avs.error.bmp


and the bmp file that is produced *looks correct* (double-wide colorbars), so I assume that the AVISynth framework is operating properly (I have removed/disabled *all* of my avisynth plugins to ensure no side-effects/conflicts)

Also - when run *without* the "-avi" option, my FRIMEncode32.exe is able to run, ingest, process, and output a avc/mvc pair (660K.avc - 654k.mvc - mvc should be 520k-ish?) from an AVI file created from the above AVS script (~600 M avi for the 100 frames) using vdub2 (latest).

For good reason, I think the output is correct but not useful (the input file looks fine in WMP, but the avc file has sliding/blocky content from the FRIM/Intel stage (in WMP), and a tsmuxer m2ts from the pair plays, but also looks 'wrong' in the same way (no errors in the tsmuxer stage).

I assume FRIMEncode is expecting raw video and my AVI has repeating/confusing header/frame info that causes this corruption/sliding image effect. Probably doing the right thing. It only processes 50 frames (of 100).

If I run the command *with* the "-avi" switch, I get the same I420 related error message.



Infile specs (generated from vdub2 with the above AVS script):


General
Complete name : C:\Users\mindsong\Desktop\at\I420_3840x1080.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 593 MiB
Duration : 4 s 167 ms
Overall bit rate : 1 194 Mb/s
Writing application : Lavf58.29.100

Video
ID : 0
Format : YUV
Codec ID : I420
Codec ID/Info : 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes.
Duration : 4 s 167 ms
Bit rate : 1 194 Mb/s
Width : 3 840 pixels
Height : 1 080 pixels
Display aspect ratio : 3.556
Frame rate : 24.000 FPS
Compression mode : Lossless
Bits/(Pixel*Frame) : 12.000
Stream size : 593 MiB (100%)



FRIM Command that processes this file (with funky output avc/mvc files (size = 660K.avc - 654k.mvc) :


FrimEncode32 -i I420_3840x1080.avi -sbs 2 -viewoutput -o:mvc b.avc d.mvc -w 3840 -h 1080 -dsth 1080 -dstw 1920 -u 4

FRIM Encoder version 1.30 - Win32 (build: Apr 16 2019)
- based on Intel(R) Media SDK

Media SDK impl HARDWARE (3) - D3D9 (C:\Program Files\Intel\Media SDK\libmfxhw32.dll)
Media SDK version 1.20
Memory type System
Async depth 4

Input format I420

Encoder AVC

Input picture:
Resolution 3840x1088
PAR 0:0
Structure Progressive
Crop X,Y,W,H 0,0,3840,1080
Frame rate 23.976
Output picture:
Resolution 1920x1088
PAR 0:0
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control CBR
bitrate 3572
GOP structure:
GOP length 24
I-/P-frame distance 4
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 4 (balanced)

Processing started
Frame number: 50
Processing finished in 3.00 seconds


(and adding the -avi option causes the process to fail with the mentioned I420 colorspace format error.)


So I believe that my FRIM (1.30) tools are not able to ingest my (seemingly) I420 4.2.0 lossless AVI streams, and probably due to my ffdshow/VFW/raw-video conduit setup.

I saw mention earlier in this thread of the ffdshow version being an issue for someone. Is there a preferred version/source (x64 and x32) of ffdshow? (or any of the tools that I'm using?)

Again, I may be missing something *really* basic and have no idea that I'm overlooking something - Are the above steps (toolchain, tests, workflow) rational for what I'm trying to do?

Of course I can provide samples and config screenshots if they would help!

Thanks again for all insights and advice!

cheers,

mindsong

[videofan3d]

ERROR: Cannot get I420 frame from input avi-file MyScript.avs
Frame was written in default format to file MyScript.avs.error.bmp


…

If I run the command *with* the "-avi" switch, I get the same I420 related error message.


Hi,

Yes, FRIMEncode assumes flat YUV files (I420 or YV12, i.e. chroma 4:2:0) because this is what underlaying Intel Media SDK can encode. (unfortunately 4:2:2 is not implemented there but this is another story)

I added -avi option long time ago, primarily for output from Adobe Premiere using DebugMode frame server (this was long before I wrote FRIMExport.prm).

Yes, -avi + Avisynth together need somehow ffdshow in the chain. Frankly speaking - configuration of all these Windows filters is magic - you never know what you have in the system and how they impact/influence each other.

Just play with it and try to find working combination.
These two links (mentioned in the past in this thread) may bring some advise
http://forum.doom9.org/showthread.php?p=1655564&highlight=ffdshow#post1655564
http://forum.doom9.org/showthread.php?p=1663488&highlight=ffdshow#post1663488

Good luck! :)

[mindsong]

Thanks! I will continue to experiment.

I am more comfortable now, knowing that amidst these 'magical' system dataflow path variables (codecs, etc.), that my goals with FRIM are plausible. If I learn anything specific, I will share the knowledge here.

lurking questions for me (to anyone/everyone):

For AVI files,

- what versions of ffdshow are folks working with? There are a number of versions and forks. Is anyone using clsid's latest to good effect, or is there a agreed-upon favorite older version that 'just works'.

- x86 or x64 - are folks working with avi files with the x86 versions, or does the x64 toolchain work too?

- avisynth+ ... or some previous version (w avi files...)

Any other tidbits that have haunted users in their setups are welcomed.

Thanks again videofan3d!

be well,
--ms

[mindsong]

Still trying:

Cranked up a VM with a raw W7, and both the completely minimal x86/x64 toolchains - frim/intel/ffdshow/avisynth - x86/x64 isolated

No luck - same I420 issue.

The reason I revisit this thread, is when the FRIM tools start and run the many tested avisynth variants and fails to 'see' the output, even though the error process indicates that the avisynth is *working*, because a valid BMP file is created when the error occurs - it seems like AVIsynth is properly starting and working, but not 'sharing' its results with the FRIM tools. How to test this?

I wonder if perhaps there's an environment setting I've missed - perhaps not in the fddshow side, but maybe in a temp-file location, named-pipe setup (I haven't used them), or maybe some 'assumed' avisynth plugin/routine that tries to send the output to FRIMENcode, but fails if that plugin/script isn't available, etc. (I've removed all plugins - my testing AVIsynth is 'naked' - is this OK?)

I've used the frim (1.30) -debug modes, but there is no magic window into how FRIM starts avisynth, and how it gathers and then passes the stream data to the Intel conversion engines. Just the proper BMP on error. It feels so close to working.

Another angle I've experimented with is using ffmpeg's avisynth mode to generate outputs that I think should be readable to my FRIM tools. The files also look reasonable to my eye (media-info/ffprobe), but aren't handled any better (or differently) as uncompressed YUV4:2:0 AVIs, and I don't know how to generate a transport stream (3840x1080 sbs) output that makes FRIMencode happy. I've tried many of the raw outputs and get 600M files from ffmpeg for the MyScript.avs script above, but none of them generate the output I'm hoping for (or expecting).

Questions:

- is there any way to 'see' the avisynth output as FRIMencode sees it, and perhaps see a proper media-info AVS patterns am I looking for

- is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?

- lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?

(Maybe FRIM is working perfectly and my Intel stuff is partially broken - it *seems* to be working, so I'm not looking there (yet)).

Thanks a bunch for any feedback!

--ms

[videofan3d]

Questions:

- is there any way to 'see' the avisynth output as FRIMencode sees it, and perhaps see a proper media-info AVS patterns am I looking for

- is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?

- lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?



Q: is there any way to 'see' the avisynth output as FRIMencode sees it
A: FRIM uses old native Windows API from vfw.h: AVIFileOpen(), AVIFileGetStream(), ... , AVIFileRelease()
Thus all AviSynth magic is hidden to it somewhere in background

Q: is there a way to use an ffmpeg/avs script to generate an uncompressed transport stream (rather than an AVI file), that FRIMencode can 'see' and use with less 'resistance'?
A: indeed, ffmpeg can produce raw video in requested format, check its help for all options

(only principle description, but working)

ffmpeg -i inputfile -pix_fmt yuv420p -vcodec rawvideo -an outputfile.yuv

where outputfile.yuv will be in YV12 or I420 (I'm not exactly sure, they differ only by order of UV, VU respectively)

Now, you can connect ffmpeg to FRIM using pipes

ffmpeg -i inputfile -pix_fmt yuv420p -vcodec rawvideo -an pipe:1.yuv | FRIMencode32 -i - -o:h264 output.h264 -w 1920 -h 1080 -f 23.976 [and other FRIM encoding options]

Optionally you could use also named pipes, which is a bit more tricky. The abobe stdout-stdin pipe works as well.

Q: lastly, is the I420 error coming from FRIMEncode, or the Intel engine w FRIMEncode is just passing it on? Is there a way I can directly test the Intel setup with these various raw test files and verify my Intel setup?
A: This error is coming from FRIM, when it requests video stream in I420 chroma format using AVIStreamGetFrameOpen(). When it fails, you get this bitmap.

[videofan3d]

FRIM version 1.31 released

All - build with Intel Media SDK 2019 R1 and MS Visual Studio 2017

FRIMTranscode:
- h265 (HEVC) codec added
- plugin support added with optional parameters:
-iguid decode-GUID-code
-iplugin full-decode-plugin-path-name
-oguid encode-GUID-code
-oplugin full-encode-plugin-path-name

FRIMSource:
- HEVC decoding uses 10-bit processing with AviSynth+

FRIMImport:
FRIMExport:
- HEVC decoding/encoding uses 10-bit processing with Adobe Premiere

[r0lZ]

Thanks, videofan3d !

[SpasV]

Thank you videofan3d for your work.

I am on setting FRIM version 1.31 and couldn't resolve the problem I have. It is seen below - FRIMDecode generates colorless stream.

https://thumbs2.imgbox.com/1d/e8/6FMB94Wl_t.png (http://imgbox.com/6FMB94Wl) https://thumbs2.imgbox.com/18/19/5afxOq57_t.png (http://imgbox.com/5afxOq57)

Command line:
"D:\Program Files\FRIM\x64\FRIMDecode64" -i:h265 "Rambo Last Blood 2019.h265" -o frim(1240).yuv -start 1240 -length 653 -sw

FRIM Decoder version 1.31 - Win64 (build: Mar 8 2020)
- based on Intel(R) Media SDK

Media SDK impl SOFTWARE (D:\Program Files\FRIM\x64\libmfxsw64.dll)
Media SDK version 1.28
Memory type System
Async depth 4

Decoder HEVC

Input picture:
Resolution 3840x2160
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,0,0
Frame rate 23.976
Output picture:
Resolution 3840x2160
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,3840,2160
Frame rate 23.976

Output format P010

Processing started
Frame number: 653
Processing finished in 69.70 seconds

Notes:

The peculiarities:
CPU: Ryzen 3900X, Graphics: NVIDIA 1660S


FRIMDecode64() works the same way without option sw


EDIT
There should be a general problem.
Here is an illustration with FRIMEncode
https://thumbs2.imgbox.com/d6/0c/MAg8jBp7_t.png (http://imgbox.com/MAg8jBp7) https://thumbs2.imgbox.com/9c/49/rJ09OZLU_t.png (http://imgbox.com/rJ09OZLU)