Hybrid(Windows/Linux/Mac): Input -> x264/x265/Xvid/VP8/VP9

[Baldrick]

I agree with manono. Keep this about hybrid. Of course is it okey to mention other frontends but not so it takes over too much.

[DarrellS]

I agree with manono. Keep this about hybrid. Of course is it okey to mention other frontends but not so it takes over too much.

Can you remove all my posts from this thread and remove the link in "All threads I have posted in" so I'm not tempted to visit this thread every day and offend anyone?

[Gravitator]

A very long time is not corrected coding error in x265-10bit through the parameter "MotionParitioning"?

[Selur]

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -loglevel fatal -r 24000/1001 -i "E:\test\prometheus(black).mkv" -an -sn -threads 2 -vf crop=1920:800:0:140 -vsync 0 -r 24000/1001 -pix_fmt yuv420p10le -f rawvideo - | "C:\PROGRA~1\Hybrid\x265-16bit.exe" --input - --input-depth 10 --input-res 1920x800 --fps 23.976 --frames 410 --subme 0 --max-merge 5 --early-skip --no-strong-intra-smoothing --keyint 240 --min-keyint 24 --bframes 7 --rc-lookahead 60 --b-adapt 1 --ref 5 --bitrate 1500 --colormatrix bt470bg --output "C:\TEMP\test_21_37_08_8810_01.265"

-> I see no problem with the calls Hybrid uses, so my guess is that you should complain about it to the x265 developers.
Sorry, but I don't see how I can help. (switching out the x265 version with an older or newer version might help)

[Gravitator]

in hybrid also notice the color deviation in decoding HEVC-10bit ( video files in the given topic > transition )
In tandem MPC / LAV / MAD more approximate to the original.

[Gravitator]

Microsoft Windows [Version 6.1.7600]
(c) Корпорация Майкрософт, 2009. Все права защищены.

C:\Users\Администратор>"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -loglevel fatal -r 240
00/1001 -i "E:\test\prometheus(black).mkv" -an -sn -threads 2 -vf crop=1920:800:
0:140 -vsync 0 -r 24000/1001 -pix_fmt yuv420p10le -f rawvideo - | "C:\PROGRA~1\H
ybrid\x265-16bit.exe" --input - --input-depth 10 --input-res 1920x800 --fps 23.9
76 --frames 410 --subme 0 --max-merge 5 --early-skip --no-strong-intra-smoothing
--keyint 240 --min-keyint 24 --bframes 7 --rc-lookahead 60 --b-adapt 1 --ref 5
--bitrate 1500 --colormatrix bt470bg --output "C:\TEMP\test_21_37_08_8810_01.265
"
yuv [info]: 1920x800 fps 23976/1000 i420 unknown frame count
x265 [info]: HEVC encoder version 0.9+29-83ccf2f1453f
x265 [info]: build info [Windows][ICC 1400][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [info]: WPP streams / pool / frames : 13 / 2 / 1
x265 [info]: Main10 profile, Level-4 (Main tier)
x265 [info]: Internal bit depth : 10
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 0 / 5
x265 [info]: Keyframe min / max / scenecut : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 60 / 7 / 1
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-1500 kbps / 1.0 / 1
x265 [info]: tools: rect amp esd rd=3 lft sao-lcu sign-hide
[1.0%] 4/410 frames, 0.51 fps, 1759.89 kb/s, eta 0:13:15

------------
crashed after 1% percent

[Selur]

crashed after 1% percent

Like I said: The call Hybrid uses is correct, x265 is simply buggy. Nothing I can do about it.
The only advise I can give you atm. is: Try other x265 versions and if that doesn't help complain to the x265 authors.
My guess is that the crash only occurs if a bunch of options are used in combination and unless that combination is clear it's hard to reproduce.


-----------------

About the decoding: I don't see a difference looking at the images you posted.
In general decoding differences might occur due to:
a. the decoder not supporting the format or it's VUI flags
b. the content not being properly flagged
c. a mistake during conversion

That aside I'm not really sure if:
a. you wanted to point out that Hybrids preview is not good as MADVR
b. you wanted to show that Hybrid does something wrong
c. you wanted something totally different.

If you think Hybrid is doing something wrong during the conversion, it would be helpful if you could provide a method to verify this somehow.
Like I said, by simply looking at the images I don't really see a difference. (using Windows 7s Windows Photo Viewer)

Cu Selur

[Gravitator]

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -loglevel fatal -r 24000/1001 -i "E:\test\prometheus(black).mkv" -an -sn -threads 2 -vf crop=1920:800:0:140 -vsync 0 -r 24000/1001 -pix_fmt yuv420p10le -f rawvideo - | "C:\PROGRA~1\Hybrid\x265-16bit.exe" --input - --input-depth 10 --input-res 1920x800 --fps 23.976 --frames 410 --subme 0 --max-merge 5 --early-skip --no-strong-intra-smoothing --keyint 240 --min-keyint 24 --bframes 7 --rc-lookahead 60 --b-adapt 1 --ref 5 --bitrate 1500 --colormatrix bt470bg --output "C:\TEMP\test_21_37_08_8810_01.265"

-> I see no problem with the calls Hybrid uses, so my guess is that you should complain about it to the x265 developers.
Sorry, but I don't see how I can help. (switching out the x265 version with an older or newer version might help)

I ask users to check on their systems > link to file "prometheus (black). mkv"> download
Use these builds x265-10bit > transition

[Selur]

Which you luck with that endeavour!

To help a bit, I modified the paths to match my system (and used the x265-16bit.exe which did come with the latest Hybrid version):

"g:\Hybrid\ffmpeg.exe" -y -loglevel fatal -r 24000/1001 -i "F:\prometheus(black).mkv" -an -sn -threads 2 -vf crop=1920:800:0:140 -vsync 0 -r 24000/1001 -pix_fmt yuv420p10le -f rawvideo - | "g:\x265-16bit.exe" --input - --input-depth 10 --input-res 1920x800 --fps 23.976 --frames 410 --subme 0 --max-merge 5 --early-skip --no-strong-intra-smoothing --keyint 240 --min-keyint 24 --bframes 7 --rc-lookahead 60 --b-adapt 1 --ref 5 --bitrate 1500 --colormatrix bt470bg --output "h:\Output\test.265"

and had no problem reencoding your the clip.
Seeing that the RAM usage of x265 on it's own is around 2.7GB your problem might be that you run out of RAM.

"g:\Hybrid\ffmpeg.exe" -y -loglevel fatal -r 24000/1001 -i "F:\prometheus(black).mkv" -an -sn -threads 2 -vf crop=1920:800:0:140 -vsync 0 -r 24000/1001 -pix_fmt yuv420p10le -f rawvideo - | "g:\Hybrid\x265-16bit.exe" --input - --input-depth 10 --input-res 1920x800 --fps 23.976 --frames 410 --subme 0 --max-merge 5 --early-skip --no-strong-intra-smoothing --keyint 240 --min-keyint 24 --bframes 7 --rc-lookahead 60 --b-adapt 1 --ref 5 --bitrate 1500 --colormatrix bt470bg --output "h:\Output\test.265"
yuv  [info]: 1920x800 fps 23976/1000 i420 unknown frame count
x265 [info]: HEVC encoder version 0.8+268-261b3c2e788e
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main10 profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames         : 13 / 8 / 3
x265 [info]: Internal bit depth                  : 10
x265 [info]: CU size                             : 64
x265 [info]: Max RQT depth inter / intra         : 1 / 1
x265 [info]: ME / range / subpel / merge         : hex / 57 / 0 / 5
x265 [info]: Keyframe min / max / scenecut       : 24 / 240 / 40
x265 [info]: Lookahead / bframes / badapt        : 60 / 7 / 1
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-1500 kbps / 1.0 / 1
x265 [info]: tools: rect amp esd rd=3 lft sao-lcu sign-hide

x265 [info]: frame I: 4      Avg QP:18.91  kb/s: 20953.78
x265 [info]: frame P: 198    Avg QP:19.82  kb/s: 2348.56
x265 [info]: frame B: 208    Avg QP:21.37  kb/s: 541.54
x265 [info]: global : 410    Avg QP:20.60  kb/s: 1613.34
x265 [info]: Weighted P-Frames: Y:6.6% UV:5.1%
x265 [info]: consecutive B-frames: 3.0% 91.1% 5.9% 0.0% 0.0% 0.0% 0.0% 0.0%

encoded 410 frames in 54.37s (7.54 fps), 1613.34 kb/s

Cu Selur

Ps:. I also tried "x265-0.9.9-highbitdepth-icl14.0-64" using the same call and had no problem encoding the clip.
PPs.: I'm using an i7-4770k, may be some of the cpu optimizations does only run properly on some CPUs.

[Gravitator]

Like I said, by simply looking at the images I don't really see a difference. (using Windows 7s Windows Photo Viewer)

there is a difference
I suspect that is not optimized FFMPEG decoder. Few encodes in 10bit and pay attention to it
Prior to the release blu-ray/HEVC long. By watching various decoders, they are still in an experimental mode (DivX and Lentoid not in a hurry)

[Selur]

Strange thing is that mencoder, ffmpeg and LAV Filters, all use the same libraries for decoding.
So unless it's a difference thats caused by the one being older than the other, or a difference due to the renderer, there should be no difference.

[Gravitator]

Seeing that the RAM usage of x265 on it's own is around 2.7GB your problem might be that you run out of RAM.

8gb RAM (6-free), Core2duo E6600 - what he does not like / crud
---
Can you give us your latest build encoder?

[Selur]

build script fails atm.

[Gravitator]

build script fails atm.

then I'll wait until the next build (I suspect the processor cache is small, or optimizing SSE / AVX blame)

[Selur]

-> uploaded some fresh x265 compiles to: https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2314536&v...=1#post2314536

[Gravitator]

-> uploaded some fresh x265 compiles to: https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2314536&v...=1#post2314536

Thanks, but it seems that there is a conflict in my system / outdated
I hope that's not much to lose by turning off this feature.

[Gravitator]

it is not clear what is the reason ...

Hybrid_2013.12.06.2

x264-10bit --preset slower --pass 2 --bitrate 1500 --profile high10 --level 4.1 --ref 4 --keyint 240 --min-keyint 23 --bframes 6 --open-gop --cplxblur 0 --qblur 0 --no-mbtree --qpmax 81 --qpstep 1 --no-fast-pskip --no-dct-decimate --merange 32 --no-chroma-me --aq-strength 0.5 --vbv-maxrate 40000 --vbv-bufsize 30000 --qpfile GENERATED_QP_FILE --psnr --non-deterministic --stats "C:\TEMP\Hybrid_2013.12.06.2.stats" --fps 24000/1001 --input-res 1920x800 --opencl --opencl-clbin x264_lookahead.clbin --output "C:\TEMP\Hybrid_2013.12.06.2.264" -

Hybrid_2014.04.04.1

x264-10bit --preset slower --pass 2 --bitrate 1500 --profile high10 --level 4.1 --ref 4 --keyint 240 --min-keyint 23 --bframes 6 --open-gop --cplxblur 0 --qblur 0 --no-mbtree --qpmax 81 --qpstep 1 --no-fast-pskip --no-dct-decimate --merange 32 --no-chroma-me --aq-strength 0.5 --vbv-maxrate 40000 --vbv-bufsize 30000 --qpfile GENERATED_QP_FILE --psnr --non-deterministic --stats "C:\TEMP\Hybrid_2014.04.04.1.stats" --input-csp i420 --fps 24000/1001 --input-res 1920x800 --opencl --opencl-clbin x264_lookahead.clbin --output "C:\TEMP\Hybrid_2014.04.04.1.264" -

possible "--input-csp i420" - causes crash?

[Selur]

no, a '--input-depth 10' is missing, are you using the x264 binary which came with the 2014.04.04.1 release or another one? (if you changed the binary, did you reset the tool cache?)

[Gravitator]

yes.

where you can turn it off?

[Selur]

modified my post, did you specify that the calcualtion precision should be 10bit?

[Gravitator]

modified my post, did you specify that the calcualtion precision should be 10bit?

Yes (The old version works stably)
--
Maybe it helps to show light on the problem

[Gravitator]

Change the container?

[Selur]

Change the container?

I will now also try to change to short and strange sentences, may be that helps.

ffmpeg fails:

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -threads 2 -analyzeduration 100M -probesize 100M -i "E:\test\TimeScapes.flv" -vcodec copy -map_metadata -1 -metadata handler_name="Hybrid 2014.04.04.1" "C:\TEMP\TimeScapes_13_06_43_3110_02.265" -map 0:1 -acodec copy  -map_metadata -1 -metadata handler_name="Hybrid 2014.04.04.1" "C:\TEMP\iId_1_aid_0_13_06_43_3110_01.aac"

call terminal. What output?

-> file broken? ffmpeg not support flv(hevc) ? -> ffmpeg doesn't support (complain to ffmpeg folks)


=> I will may be look at it some more tomorrow.

[Gravitator]

came

Input #0, flv, from 'E:\test\TimeScapes.flv':
Metadata:
metadatacreator : MONOGRAM FLV Mux
hasCuePoints : false
canSeekToEnd : false
hasKeyframes : false
lasttimestamp : 129
hasVideo : true
hasAudio : true
Duration: 00:02:08.54, start: 0.000000, bitrate: 1368 kb/s
Stream #0:0: Video: none ([12][0][0][0] / 0x000C), 1259385 kb/s, 23.98 tbr,
1k tbn, 1k tbc
Stream #0:1: Audio: aac, 48000 Hz, stereo, fltp
[NULL @ 0291d6e0] Unable to find a suitable output format for 'C:\TEMP\TimeScape
s_13_06_43_3110_02.265'
C:\TEMP\TimeScapes_13_06_43_3110_02.265: Invalid argument

[Selur]

-> was right:

ffmpeg not support flv(hevc) -> ffmpeg doesn't support (complain to ffmpeg folks)

+ I checked: FLVExtract doesn't support it either.

=> atm. I don't know tool which can extract the video stream

[Gravitator]

what is the minimum size of the working blocks at x265?

[Selur]

Working blocks?
QuadTree supports 16x16 as min coding unit size.
subme uses quater pixel calculations.
Internally HEVC specifies four transform units (TUs) sizes of 4x4, 8x8, 16x16, and 32x32 to code the prediction residual.
The deblock filter is rougher than one is used to with AVC. (hevc: 8x8, avc: 4x4)

-> http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding should help answer your question

[Gravitator]

It turns out that when the frame flies fly / bee within a block of 4x4, then HEVC regarded as an object to be 16x16?

[Selur]

HEVC doesn't identify objects. http://forum.doom9.org/showthread.php?t=167081 has an nice overview regarding blocks&co.
-> you have to differ between coding and transform units and if you look at chroma or luma information or if you analyse motion information,... (better ask inside one of the x265 threads for technical details regarding H.265)

[Gravitator]

2014.04.04.1 trying to encode "park_joy_1080p50" in XviD, but hybrid does not add to his list of jobs?