Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > (HD) DVD, Blu-ray & (S)VCD > (HD) DVD & Blu-ray authoring

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd July 2020, 19:38   #1001  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
Quote:
Originally Posted by SpasV View Post
… 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!

Last edited by videofan3d; 2nd July 2020 at 22:28.
videofan3d is offline   Reply With Quote
Old 3rd July 2020, 04:28   #1002  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
view/check the output from decoding of HEVC

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

Last edited by SpasV; 3rd July 2020 at 05:46.
SpasV is offline   Reply With Quote
Old 3rd July 2020, 05:47   #1003  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
Quote:
Originally Posted by SpasV View Post


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....
videofan3d is offline   Reply With Quote
Old 3rd July 2020, 16:35   #1004  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
pixel format yuv420p10le corresponds to yv12

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
SpasV is offline   Reply With Quote
Old 3rd July 2020, 17:27   #1005  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
Quote:
Originally Posted by SpasV View Post
..
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.
videofan3d is offline   Reply With Quote
Old 4th July 2020, 01:26   #1006  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
I don't fully understand:
Quote:
Originally Posted by videofan3d View Post
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.
SpasV is offline   Reply With Quote
Old 4th July 2020, 08:47   #1007  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
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.
videofan3d is offline   Reply With Quote
Old 4th July 2020, 19:33   #1008  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
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.

Quote:
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
Quote:
Output format P010
RawSourcePlus supports
Quote:
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.

Last edited by SpasV; 4th July 2020 at 19:56.
SpasV is offline   Reply With Quote
Old 4th July 2020, 20:24   #1009  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
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)
videofan3d is offline   Reply With Quote
Old 4th July 2020, 23:18   #1010  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
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
SpasV is offline   Reply With Quote
Old 5th July 2020, 08:47   #1011  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
Quote:
Originally Posted by SpasV View Post
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.
videofan3d is offline   Reply With Quote
Old 5th July 2020, 16:04   #1012  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
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.
Quote:
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 is offline   Reply With Quote
Old 10th July 2020, 01:50   #1013  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
I cannot get proper output from FRIMDecode64

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:
Quote:
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:
Quote:
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
Quote:
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

Last edited by SpasV; 10th July 2020 at 04:20.
SpasV is offline   Reply With Quote
Old 10th July 2020, 18:18   #1014  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
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.
videofan3d is offline   Reply With Quote
Old 10th July 2020, 20:21   #1015  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
No P010 format converter

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.
SpasV is offline   Reply With Quote
Old 11th July 2020, 22:01   #1016  |  Link
videofan3d
Registered User
 
Join Date: Sep 2013
Location: Czech Republic
Posts: 312
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.)

Code:
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.
videofan3d is offline   Reply With Quote
Old 12th July 2020, 21:18   #1017  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
Quick test - FRIMDecode works with option -yuv420p10le

Thank you very much.
I've successfully run a quick test with a short (1005 frames) clip and FFPlay.
Quote:
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.
Quote:
string "pixel_type" - P010, P016 (chroma interleaved 16bit horizontally and vertically subsampled, those are converted to AviSynth+'s YUV420P16)
SpasV is offline   Reply With Quote
Old 13th July 2020, 19:40   #1018  |  Link
SpasV
Registered User
 
Join Date: Nov 2013
Location: Sofia, Bulgaria
Posts: 63
psnr - two inputs test

I've used the ffmpeg's psnr filter which works with two inputs.
Quote:
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.

Last edited by SpasV; 16th July 2020 at 15:48.
SpasV is offline   Reply With Quote
Reply

Tags
encoders, mvc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.