Free H.264 MVC 3D Encoder

[videofan3d]

… It is seen below - FRIMDecode generates colorless stream.
[/URL]

How do you view/check the output from decoding of HEVC stream?

Please note that layout P010 is DIFFERENT than YV12.

mpeg2 and h264 are compressed in 8 bits, hence when decompressed you will get pixel layout known as yv12-planar:
1920x1080 bytes of luma-Y
960x540 bytes of chroma-U
960x540 bytes of chroma-V

h265 is compressed in 10 bits, hence when decompressed you will get pixel layout called P010:
3840x2160 words of luma-Y
3840x1080 words of chroma-interlaced-U+V
(… this chroma-interlaced format is used e.g. by nVidia cards)

So the presentation software needs to handle chroma differently than in case of decoded h264 stream!

[SpasV]

Here are the steps:


Decoding in named pipe
FRIMDecode64 -i:h265 "Rambo Last Blood 2019.h265" -start 1240 -length 653 -sw -o \\.\pipe\yuvpipe
....
Output format P010

Processing started
Frame number: 653
Processing finished in 70.45 seconds

ffmpeg -hide_banner -f rawvideo -s 3840x2160 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\yuvpipe frim2ffmpeg(653).yuv
Input #0, rawvideo, from '\\.\pipe\yuvpipe':

Duration: N/A, start: 0.000000, bitrate: 4772796 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160, 4772796 kb/s, 23.98 tbr, 23.98 tbn, 23.98 tbc
Output #0, rawvideo, to 'frim2ffmpeg(1240).yuv':
Metadata:
encoder : Lavf58.47.100
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160, q=2-31, 2982998 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
Metadata:
encoder : Lavc58.93.100 rawvideo
frame= 653 fps= 22 q=-0.0 Lsize=15867900kB time=00:00:27.23 bitrate=4772796.8kbits/s speed=0.912x

ffmpeg -hide_banner -f rawvideo -s 3840x2160 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\yuvpipe frim2ffmpeg(653).yuv
Input #0, rawvideo, from '\\.\pipe\yuvpipe':
Duration: N/A, start: 0.000000, bitrate: 4772796 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160, 4772796 kb/s, 23.98 tbr, 23.98 tbn, 23.98 tbc
Output #0, rawvideo, to 'frim2ffmpeg(1240).yuv':
Metadata:
encoder : Lavf58.47.100
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160, q=2-31, 2982998 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
Metadata:
encoder : Lavc58.93.100 rawvideo
frame= 653 fps= 22 q=-0.0 Lsize=15867900kB time=00:00:27.23 bitrate=4772796.8kbits/s speed=0.912x


Displaying/Taking screenshot with AvsPmod
RawSourcePlus(file="E:\AV Processing\Rambo Last Blood 2019\frim2ffmpeg(653).yuv", width=3840, height=2160, pixel_type="YUV420P10", fpsnum=24000, fpsden=1001, index="", show=true)

FRAME #597
https://thumbs2.imgbox.com/59/18/8Z0JsLAc_t.png (http://imgbox.com/8Z0JsLAc)

(Naturally, the CL: FRIMDecode64 -i:h265 "Rambo Last Blood 2019.h265" -start 1240 -length 653 -sw -o - | ffmpeg -hide_banner -f rawvideo -s 3840x2160 -r 23.976 -pix_fmt yuv420p10le -i - -vcodec copy frim2ffmpeg(653).2.yuv generates the same result.)

The pixel format yuv420p10le is used by YUV viewers when work with 10-bit color sampled 4:2:0

EDIT:
The same result (colorless) generates FRIMDecode64 -i:h265 Rambo_2019_1240_654.h265 -o Rambo_1240_654.yuv -sw

[videofan3d]

…

ffmpeg -hide_banner -f rawvideo -s 3840x2160 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\yuvpipe frim2ffmpeg(653).yuv
..


I guess this is the issue.

pixel format yuv420p10le corresponds to yv12 but in words, not bytes, i.e.:
3840x2160 words luma-Y
1920x1080 words chroma-U
1920x1080 words chroma-V
(and uses only 10 bits in little-endian)

This does not corresponds to output from FRIM where chroma U and V are interlaced.

Therefore you've got correct luma-Y, but corrupted chroma information....

[SpasV]

Thank you videofan3d.
I've run:
FRIMDecode64 -i:h265 Rambo_2019_1240_654.h265 -sw -length 200 -o - | FRIMEncode64 -i - -o:h265 FRIM.Rambo_2019.h265 -w 3840 -h 2160 -f 24000/1001 -sw -p010 -u 1 -profile main10 -level 5.1H -cqp 13 14 15
and the result is normal.


https://thumbs2.imgbox.com/41/01/OxYk8LLo_t.png (http://imgbox.com/OxYk8LLo) https://thumbs2.imgbox.com/ff/84/nrBtzNwD_t.png (http://imgbox.com/nrBtzNwD)


So, it turned out Intel use some intermediate YUV format for their Media SDK version 1.28 :)

[videofan3d]

..
So, it turned out Intel use some intermediate YUV format for their Media SDK version 1.28 :)

Intel MediaSDK internally produces/accepts NV12 (for 8-bit processing) and P010 (for 10-bit processing).

Conversion to/from YV12/I420 (which is standard for DVD and Bluray) is performed in FRIM itself.

[SpasV]

I don't fully understand:
Intel MediaSDK internally produces/accepts NV12 (for 8-bit processing) and P010 (for 10-bit processing).

Conversion to/from YV12/I420 (which is standard for DVD and Bluray) is performed in FRIM itself.

Can you explain this result:

https://thumbs2.imgbox.com/f3/a4/m6OEhY7u_t.png (http://imgbox.com/m6OEhY7u)

obtained:
FRIMDecode64 -i:h265 FRIM.Rambo_2019.test.h265 -o FRIM.Rambo_2019.test.yuv -sw
RawSourcePlus(file="E:\AV Processing\Rambo Last Blood 2019\FRIM.Rambo_2019.test.yuv", width=3840, height=2160, pixel_type="YUV420P10", fpsnum=24000, fpsden=1001, index="", show=true)

Thanks.

[videofan3d]

Pixel layout yv12 is planar 4:2:0:

YYYYYYYY
YYYYYYYY
YYYYYYYY
YYYYYYYY
UUUU
UUUU
VVVV
VVVV


Pixel layout nv12/p010 are semi-planar 4:2:0:

YYYYYYYY
YYYYYYYY
YYYYYYYY
YYYYYYYY
UVUVUVUV
UVUVUVUV


Overal frame size is identical, luma is identical, chroma differs.

FRIMDecode provides P010
but ffmpeg expects YV12 (in 16 bits)
Since luma is identical, you get correct B&W part.
But incorrectly interpreted color information.

[SpasV]

Thank you for explanation.

I think there is some discrepancy with pixel formats.
In the example below FRIMDecode64 generates an .yuv file and RawSourcePlus displays it in YUV420P10 pixel format.


FRIMDecode64 -i:h265 FRIM.Rambo_2019.test.h265 -o FRIM.Rambo_2019.test.yuv -sw

RawSourcePlus(file="E:\AV Processing\Rambo Last Blood 2019\FRIM.Rambo_2019.test.yuv", width=3840, height=2160, pixel_type="YUV420P10", fpsnum=24000, fpsden=1001, index="", show=true)


FRIMDecode64 generates the .yuv file FRIM.Rambo_2019.test.yuv in Output format P010
RawSourcePlus supports Additional colorspaces with RawSourcePlus and AviSynth+
pixel_type --- AviSynth colorspace
P010, P016 -- YUV420P16

(It is YUV420P10 which works with pixel_type P010)

and the screenshot from -o FRIM.Rambo_2019.test.yuv has no chroma.

It seems to me FRIMDecode64 implements a not common 10-bit per channel pixel format known to FRIMEncode64, of course.

[videofan3d]

I'm trying to explain the layout principles.

YUV420P10 in ffmpeg terminology is apparently yv12 layout in words (=2 bytes)
while P010 in FRIM/Intel Media SDK terminology is nv12 layout in words (=2 bytes)
They have identical luma but different chroma.

The phenomena which you are facing is typical when you try to interpret "nv12" as "yv12":
- correct luma (B&W part)
- kind of moire in color domain

Bit-depth(10 bits) is interpreted correctly, otherwise you would get completely burned luma as well.

To solve it you have three options:
1. find pixelmode in ffmpeg which corresponds to nv12 in words (if such exists)
2. find some interim pipeline software which will convert nv12->yv12 and put it in-between FRIMDecode and ffmpeg
3. wait till I implement "yv12 in words" into FRIM (maybe sometime I will)

[SpasV]

Sorry, if I've misunderstood something.

I haven't used ffmpeg for the particular post. I've used FRIMDecode64() and RawSourcePlus().

I've created an .yuv file using FRIMDecode:
FRIMDecode64 -i:h265 test.h265 -o test.yuv

No FFMPEG involved!

I've got a screenshot using RawSourcePlus:
RawSourcePlus(file="test.yuv", ... , pixel_type="YUV420P10")

RawSourcePlus supports P010 --> YUV420P10.

And no colors on the screenshot.

Respectfully,
Spas

[videofan3d]

RawSourcePlus(file="test.yuv", ... , pixel_type="YUV420P10")

RawSourcePlus supports P010 --> YUV420P10.


Apparently not.
Likely RawSourcePlus() uses the same terminology as ffmpeg, when YUV420P10 represents yv12 in words.

(Code-naming of pixel_modes is not important, the functional matter (i.e. layout itself) is)

Layout nv12 is used often by graphics-cards and this was probably the reason why Intel has chosen it as native format for its Media SDK.

Conclusion is the same, you have now three options to solve it - as I enlisted above.

[SpasV]

Thanks videofan3d.

The properly generated by FRIMDecode() .yuv file is recognized by ffmpeg and some yuv players as having pixel format yuv420p10le equivalent to YUV420P10 (played by RawSourcePlus as YUV420P16 also).

It seems to me the problem I've faced is due to my improper choosing the clips' start frame. The players play this .yuv clip as black&withe but ffmpeg refuses with an error mesage.

ffplay -hide_banner -i "FRIM.Rambo_2019.test.yuv"
[IMGUTILS @ 000000d26cdff380] Picture size 0x0 is invalid0B f=0/0
FRIM.Rambo_2019.test.yuv: Invalid argument


I have to look at this.

Thank you again.

[SpasV]

I highly appreciate your work videofan3d.
Thank you.

I am interesting in an intermediate result - Windows Named Pipe. In particular, FRIMDecode can serve as a Named Pipe Server for such pipes:

ffmpeg -hide_banner -f rawvideo -s 3840x1612 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\enc -f rawvideo -s 3840x1612 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\src -lavfi psnr="stats_file=enc.psnr.log" -frames:v 1005 -y -f null -

in order an objective encode evaluation to be generated.

Unfortunately, I cannot see a properly decoded output from FRIMDecode64, yet.

Here are comparison screens which are screenshots from ffplay receiving outputs from DGDecNV and FRIMDecode through a pipe
https://thumbs2.imgbox.com/61/2e/ufepcOoH_t.png (http://imgbox.com/ufepcOoH) https://thumbs2.imgbox.com/15/b4/nyvQ2jwb_t.png (http://imgbox.com/nyvQ2jwb)
and screens from YUView displaying images in .yuv files created by DGDecNV through ffmpeg and FRIMDecode directly.
https://thumbs2.imgbox.com/ac/6d/5SOJ3emJ_t.png (http://imgbox.com/5SOJ3emJ) https://thumbs2.imgbox.com/d9/db/OnSGA1Xb_t.png (http://imgbox.com/OnSGA1Xb)

Scripts:

avs2yuv64 -raw -depth 10 -frames 1 E:\AVProcessing\AVS\DGDecNV.Rambo_Last_Blood_2019(107209-108214).avs - | ffplay -hide_banner -f rawvideo -video_size 3840x2160 -pixel_format yuv420p10le -i - -color_primaries 9 bt2020
E:\AVProcessing\AVS\DGDecNV.Rambo_Last_Blood_2019(107209-108214).avs: 3840x2160, YUV420P10, 10-bits, progressive, 24000/1001 fps, 1005 frames
Input #0, rawvideo, from 'pipe:': 0KB vq= 0KB sq= 0B f=0/0
Duration: N/A, start: 0.000000, bitrate: 4976640 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160, 4976640 kb/s, 25 tbr, 25 tbn, 25 tbc

E:\AVProcessing\RamboLastBlood>avs2yuv64 -raw -depth 10 -frames 1 E:\AVProcessing\AVS\DGDecNV.Rambo_Last_Blood_2019(107209-108214).avs - | ffmpeg -hide_banner -f rawvideo -video_size 3840x2160 -pixel_format yuv420p10le -i - DGDecNV.Rambo_Last_Blood_2019(107209).yuv


E:\AVProcessing\RamboLastBlood>FRIMDecode64.exe -i:h265 E:\AVProcessing\RamboLastBlood\Rambo_Last_Blood_2019(107209-108214).hevc -length 1 -o \\.\pipe\frim1
E:\AVProcessing\RamboLastBlood>ffplay -hide_banner -f rawvideo -video_size 3840x2160 -pixel_format yuv420p10le -i \\.\pipe\frim1 -color_primaries 9 (bt2020)
Input #0, rawvideo, from '\\.\pipe\frim1': 0KB sq= 0B f=0/0
Duration: N/A, start: 0.000000, bitrate: 4976640 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160, 4976640 kb/s, 25 tbr, 25 tbn, 25 tbc

E:\AVProcessing\RamboLastBlood>FRIMDecode64.exe -i:h265 E:\AVProcessing\RamboLastBlood\Rambo_Last_Blood_2019(107209-108214).hevc -length 1 -o FRIMDecode.Rambo(107208).yuv

[videofan3d]

Pipe is just a memory bitstream (instead of file) - it saves diskspace and is very common in UNIX environment. It has nothing to do with pixel format or decoding/encoding.

You probably still don't understand the difference between pixel formats yv12 and nv12. See again my schematic depicting in previous posts.

yuv420p10le (in ffmpeg terminology) is NOT equal to P010 (in Intel/FRIM terminology). Full stop.

(You can read this yuv420p10le as "yuv420 planar 10-bits little-endian").

So, you need to wait some time till I implement this pixel format also into FRIM. Then you will get natively what you need.

Try to google in the meantime about pixel formats - there are many references and better explanations on the web.

[SpasV]

As long as I've searched there is no P010 format converter.
I've found s Named Pipe Client code with links to Named Pipe Server codes at https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipe-client.
I'll try to modify a server code.

[videofan3d]

Here is interim version FRIM 1.32 (https://drive.google.com/file/d/1yaMA4UxZAdz--Kn4wdusQcIZWO_fCOcb) which will solve your problem.
Please test it and confirm.
(I will publish it later as official release.)

set ISTREAM=input.h265
set OSTREAM=ouput.h265
set PSTREAM=\\.\pipe\yuvpipe

start /min .\FRIMDecode64 -i:h265 "%ISTREAM%" -sw -o %PSTREAM% -yuv420p10le

ffmpeg -hide_banner -f rawvideo -s 3840x2160 -r 23.976 -pix_fmt yuv420p10le -i %PSTREAM% -vcodec hevc "%OSTREAM%"


For this RawSourcePlus() it should work as well.

[SpasV]

Thank you very much.
I've successfully run a quick test with a short (1005 frames) clip and FFPlay.

FRIMDecode64.exe -i:h265 E:\AVProcessing\RamboLastBlood\Rambo_Last_Blood_2019(107209-108214).hevc -o \\.\pipe\test -yuv420p10le
ffplay -hide_banner -f rawvideo -video_size 3840x2160 -pixel_format yuv420p10le -i \\.\pipe\test -color_primaries 9


I'll run one more test, at least, with FFMPEG filter psnr also.

P.S. By the way, RawSourcePlus() supports format P010, too.

string "pixel_type" - P010, P016 (chroma interleaved 16bit horizontally and vertically subsampled, those are converted to AviSynth+'s YUV420P16)

[SpasV]

I've used the ffmpeg's psnr filter which works with two inputs.

FRIMDecode64.exe -i:h265 "G:\Video\Rambo 2019 1240-1955 2160p src.hevc" -o \\.\pipe\src -yuv420p10le -dstsize 3840 1612 -area 0 274 3840 1612
FRIMDecode64.exe -i:h265 "G:\wrk\Rambo 2019 1240-1955 1612p ref.hevc" -o \\.\pipe\enc -yuv420p10le

ffmpeg -hide_banner -f rawvideo -s 3840x1612 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\enc -f rawvideo -s 3840x1612 -r 23.976 -pix_fmt yuv420p10le -i \\.\pipe\src -lavfi psnr="stats_file=ref.psnr.log" -frames:v 743 -y -f null -


This setup works fine.

Something, probably, off topic.
There are peculiarities in two cases I saw:
* FRIMDecode with option -start
The decoder seeks slow and synchronization wasn't possible. So, I extracted hevc files using mkvmerge and tsMuxeR
* I made a mistake with cropping.
With these parameters -dstsize 3840 1612 -area 0 274 3840 1612 -dstarea 0 274 3840 1612 FRIMDecoder entered an infinite loop.

Thank you very much, videofan3d.

P.S. x265 doesn't support P010 but it does yuv420p10le.

[trevorjharris]

I have updated to Frim 1.31 64 bit and installed the example frim project into premiere pro cs6. When I try to export I get an empty file. The log is

Media SDK impl SOFTWARE (c:\UTL\FRIM\libmfxsw64.dll)
Media SDK version 1.28
Memory type System
Async depth 4

Input format I420

Encoder AVC

Input picture:
Resolution 1920x1088
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Output picture:
Resolution 1920x1088
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 28000,40000
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)

Encoded frames: 720
Processing finished in 0.20 seconds

As you can see it process the correct number of frames but the .h264 file is empty.

Please can someone help.

[trevorjharris]

Please can someone tell me how to get I420 frames using 1.31

FRIMEncode64 -avi -i frim2.avs -o:h264 output.h264 -vbr 16000 21000 -u 4

ERROR: Cannot get I420 frame from input avi-file frim2.avs

ERROR: File reader initialization failed.

ERROR: Cannot start encoding process.

The avs file is

avisource("garda-l3-test.avi", audio=false)
ConvertToYV12(interlaced=false)

[trevorjharris]

I have updated to Frim 1.31 64 bit and installed the example frim project into premiere pro cs6. When I try to export I get an empty file. The log is

Media SDK impl SOFTWARE (c:\UTL\FRIM\libmfxsw64.dll)
Media SDK version 1.28
Memory type System
Async depth 4

Input format I420

Encoder AVC

Input picture:
Resolution 1920x1088
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Output picture:
Resolution 1920x1088
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 28000,40000
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)

Encoded frames: 720
Processing finished in 0.20 seconds

As you can see it process the correct number of frames but the .h264 file is empty.

Please can someone help.

I tried this in Windows 7 so I think it might have something to do with Windows 10. Please can anyone help.

[trevorjharris]

What I meant to say was that it worker in windows 7. So I think that windows 10 broke it.

[trevorjharris]

OK I solved it. I reinstalled premiere pro and all was well. The i420 problem using avisynth still does not work but at least I can use premiere. Thanks

[trevorjharris]

In premiere pro I tried rendering the first sequence with 2 video tracks to an intermediate using cineform. I then imported this back into Premiere and then exported it with Frimencode This was alot faster than exporting a sequence with a sequence in it. Frim encoding was about 14 times faster but encoding to an intermediate does take time.

[3DJ]

Howdy folks!
I've been trying to convert an NVIDIA 3D Vision 1080p60 gameplay recording in full-resolution SBS MP4 format to a single MVC 3D MKV (like BD3D MakeMKV rips) with the hopes of saving HDD space by encoding redundant data efficiently without losing significant quality.
But so far, I've only gotten errors and corrupted (colored static) video files and I'm not sure what I'm missing/doing wrong.

Input: https://www.dropbox.com/sh/nzdws2k4cb33wte/AAAiQFI0NXv72npyT0KH8wHxa?dl=0
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 69.0 MiB
Duration : 6 s 681 ms
Overall bit rate : 86.7 Mb/s
encoder : Lavf58.76.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings : CABAC / 1 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference : 1 frame
Format settings, GOP : M=1, N=30
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 6 s 681 ms
Source duration : 6 s 714 ms
Bit rate : 85.6 Mb/s
Maximum bit rate : 96.7 Mb/s
Width : 3 840 pixels
Height : 1 080 pixels
Display aspect ratio : 3.556
Frame rate mode : Variable
Frame rate : 59.724 FPS
Minimum frame rate : 16.129 FPS
Maximum frame rate : 620.690 FPS
Original frame rate : 60.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.345
Stream size : 68.8 MiB (100%)
Source stream size : 68.8 MiB (100%)
Title : VideoHandle
Writing library : x264 core 164
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=85567 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601
mdhd_Duration : 6681
Codec configuration box : avcC

Audio #1
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 6 s 681 ms
Source duration : 6 s 664 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 159 KiB (0%)
Source stream size : 159 KiB (0%)
Title : SoundHandle
Default : Yes
Alternate group : 1
mdhd_Duration : 6681

Audio #2
ID : 3
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 6 s 680 ms
Source duration : 6 s 674 ms
Bit rate mode : Constant
Bit rate : 117 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 95.7 KiB (0%)
Source stream size : 95.7 KiB (0%)
Title : SoundHandle
Default : Yes
Alternate group : 2
mdhd_Duration : 6680

Command:
FRIMEncode64 -i i1.mp4 -sbs 2 -o:mvc o1.mkv -size 1920 1080 -dstsize 1920 1080 -f 60 -dar 16:9

Output: https://www.dropbox.com/sh/845ikih2nbyvmc0/AACzrgZwXnQuKi0JqbT9CVOqa?dl=0
FRIM Encoder version 1.31 - Win64 (build: Mar 8 2020)
- based on Intel(R) Media SDK

Media SDK impl HARDWARE (2) - D3D11 (C:\Windows\SYSTEM32\libmfxhw64.dll)
Media SDK version 1.34
Memory type System
Async depth 4

Input format I420

Encoder AVC

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

Processing started
Frame number: 11
Processing finished in 0.15 seconds
Not sure why it insists on 1920x1088 resolution even tho I already set -size 1920 1080 -dstsize 1920 1080

Here's how the output file looks:
https://i.imgur.com/AcKiOtF.jpeg

[videofan3d]

[QUOTE=3DJ;1969736]Howdy folks!
FRIMEncode input must be planar YUV (more precisely yv12 pixel format) - not any kind of compressed container.

Also output is elementary stream .h264/.mvc which need to be multiplexed using tsMuxer.

Finally, I'm worried that 1080p60 is not standard for 3D-Bluray.
I always used only 1080p24 with my videos.

[3DJ]

Woah, so the input must be a raw video? That sounds quite impractical, unless there's a way to pipe an ffmpeg uncompressed stream to avoid having to waste hundreds if not thousands of GBs?
The full video is like ~6hrs of 1080p60 3D (Side by Side so 2160 horizontal pixels).
I usually just upload my 3D videos onto YouTube but the quality drops noticeably even at "4K" resolution so I just wanted a more efficient method to store my 3D videos locally.

[videofan3d]

Woah, so the input must be a raw video? That sounds quite impractical, unless there's a way to pipe an ffmpeg uncompressed stream to avoid having to waste hundreds if not thousands of GBs?


Certainly you can connect using pipes.
Check the FRIMEncode_readme.pdf document in the package and make few experiments - I'm sure you will find how to use it.

[Cedvano]

Hi,

I would like to know if it's possible to create mkv with the combined output h264/mvc ?
When I use MkvToolNix, impossible to read with Sterescopic Player.

Thanks in advance.

[videofan3d]

Hi,

I would like to know if it's possible to create mkv with the combined output h264/mvc ?
When I use MkvToolNix, impossible to read with Sterescopic Player.

Thanks in advance.

Combined h264/mvc is specific elementary stream containing frames of both main-view and dependent-view, suitably multiplexed.
It is (probably) rarely used part of h264 MVC standard. As such, I doubt there is any available decoder who can even read it.

Furthermore to my knowledge, dependent view MVC elementary stream is not supported by MKVToolNix.
Author said in past that he will implement it if there will be demand but he wants to do it right.
Nowadays with decline of 3D I'd say there won't be any demand anymore. There are also no more mediaplayers capable of 3D.
Pity...

[Cedvano]

Combined h264/mvc is specific elementary stream containing frames of both main-view and dependent-view, suitably multiplexed.
It is (probably) rarely used part of h264 MVC standard. As such, I doubt there is any available decoder who can even read it.

Furthermore to my knowledge, dependent view MVC elementary stream is not supported by MKVToolNix.
Author said in past that he will implement it if there will be demand but he wants to do it right.
Nowadays with decline of 3D I'd say there won't be any demand anymore. There are also no more mediaplayers capable of 3D.
Pity...

Thanks for your answer.

[KSSW]

FRIM_ x64_ version_ 1.31 Whether MVC can conform to Blu ray 3D

Scenarist BD V8 MUI Tips

https://i.postimg.cc/8zy0VzjK/360-20230109154529631.png

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

Media SDK impl HARDWARE (2) - D3D11 (C:\windows\SYSTEM32\libmfxhw64.dll)
Media SDK version 1.35
Memory type System
Async depth 4

Input format I420

Encoder AVC

Input picture:
Resolution 1920x1088
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Output picture:
Resolution 1920x1088
PAR 1:1
Structure Progressive
Crop X,Y,W,H 0,0,1920,1080
Frame rate 23.976
Bitrate control VBR
avg,maximum 35000,38000
GOP structure:
GOP length 24
I-/P-frame distance 3
IDR-frame interval 0
GOP type Opened
Num of slices 6
Target usage 1 (quality)

Processing started
Frame number: 1438
Processing finished in 174.68 seconds

[KaraokeAmerica]

When I try to encode an .264 and MVC file I get this error:

ERROR: the previous asynchrous operation is in execution (1), c:\prj\frim\frim_encode\src\main_frim_encode.cpp (128)

I searched the forums for this exact error code, but even though it gave me search results I could never actually find the comments that contained this error so I don't know what it means. I don't even have that path on my system.

The command line I'm running is this:

FRIMEncode64 -i 00000.track_4113.264 00001.track_4114.mvc -o:mvc output_combined.h264 -w 1920 -h 1080 -f 23.976 -vbr 28000 40000 -level 4.1 -u 1

It doesn't happen until it has encoded 2930 frames. It creates an .h264 output file of about 600MB that if I examine in mediainfo shows up as:

First video stream: 1920*1080 (16:9), at 23.976 (24000/1001) FPS, AVC (Stereo High@L4.1 / High@L4.1)(CABAC/3 Ref Frames) which is precisely what I see when I have a complete 3D-MVC MKV rip.

I'm not sure if I am seeing an issue or it is operator error so any suggestions are appreciated!

[KaraokeAmerica]

FRIMEncode input must be planar YUV (more precisely yv12 pixel format) - not any kind of compressed container.

How do you make that yv12 pixel format?

[wcapes2101]

Hi all

Question about functionality

I'm just experimenting and playing on my 3D Blurays to make backups, as I like to keep the original stored away. So I've managed to rip my movie ( won't drop names to be safe in 2023 ) and managed to demux into
01000.track_4113.264
01000.track_4114.mvc
01000.track_4353.ac3

I have used NVEncC to re-encode the 264 stream to a lower bitrate.
Was wondering if I can use FRIM to reencode JUST the MVC stream based off my encode instead of the 01000.track_4113.264 one.

Reason being is I prefer NVEncC encoding as it's quicker ( I know not the best reason , I just like it )

Thanks :)

[Emulgator]

To achive the desired encoding efficieny a direct encoding parameter dependency of both streams is needed to be maintained.
Not only bitrate distribution, quantizer, frame type...
Conclusion: Base and dependent stream have to come out of one and the same encoder based on the same decisions.

[wcapes2101]

To achive the desired encoding efficieny a direct encoding parameter dependency of both streams is needed to be maintained.
Not only bitrate distribution, quantizer, frame type...
Conclusion: Base and dependent stream have to come out of one and the same encoder based on the same decisions.

Makes sense, thanks for the reply