Free H.264 MVC 3D Encoder

[videofan3d]

Originally Posted by SpasV

… 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!

Here are the steps:

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

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

Originally Posted by SpasV

…

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

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.

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

[videofan3d]

Originally Posted by SpasV

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

I don't fully understand:

Originally Posted by videofan3d

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:



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.

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)

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]

Originally Posted by SpasV

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.

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.

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

and screens from YUView displaying images in .yuv files created by DGDecNV through ffmpeg and FRIMDecode directly.

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.

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/win...ed-pipe-client.
I'll try to modify a server code.

[videofan3d]

Here is interim version FRIM 1.32 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.

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)

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)