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 > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th October 2013, 00:45   #41  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Hmmm, according to this post, the patch suggested above "cannot be automated" or something.
filler56789 is offline   Reply With Quote
Old 17th October 2013, 08:04   #42  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
yes, I saw that in the mailing list...I think that can be retrieved by reading the reg value.

btw,

Quote:
Not really matters if you build the makefiles without the batch files. Simply add the "-T "v110_xp"" switch to cmake.
Anyway nice work for batch users.
this guy doesn't understand what my patch does...the switch goes to the cmake command line.
Kurtnoise is offline   Reply With Quote
Old 25th October 2013, 08:15   #43  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by LigH View Post
And yes: There is not even support for streaming video sources (pipe / AviSynth) yet. GUIs could not efficiently serve frames to such an encoder.
Piping is under way now...



Edit: test build uploaded.

Last edited by Kurtnoise; 25th October 2013 at 08:32.
Kurtnoise is offline   Reply With Quote
Old 25th October 2013, 12:01   #44  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Kurtnoise View Post
Piping is under way now...



Edit: test build uploaded.
Thanks for the experimental build, but you didn't say whether it works or doesn't work on your machine(s)

I took the time to compile the latest commit with GCC 4.8.1, including the stdin patch, and sadly the best the EXE does is encode 0 frames when fed through avs2yuv.

Last edited by filler56789; 25th October 2013 at 12:04.
filler56789 is offline   Reply With Quote
Old 25th October 2013, 12:36   #45  |  Link
Monarc
Registered User
 
Join Date: Jun 2002
Posts: 35
One question about x265.

on x265.org i can read:

Code:
x265 is a commercially funded open source implementation
on x265.com:

Code:
As the x265 reaches production, flat fee and per-unit commercial licenses will be available for companies that cannot accept x265 under a GPL license.
So x265 is a normal commercial product?
And x265 will be re-licensed under a new licence, when ready?
And sold like a normal product?
Monarc is offline   Reply With Quote
Old 25th October 2013, 12:46   #46  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
x265 is dual-licensed, like x264. Its available for free under GPL, but also available under a commercial license if your requirements are not compatible with the GPL. The text only states that the commercial license is not available until the product reaches a certain level of maturity.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 25th October 2013, 13:16   #47  |  Link
x265.cc
Registered User
 
Join Date: Oct 2013
Posts: 41
Quote:
Originally Posted by Kurtnoise View Post
this guy doesn't understand what my patch does...the switch goes to the cmake command line.
Can you please tell me what i haven't understood? It would be helpful for me. Thanks

btw. i've now implemented this (the commandline way) for my buildbot.
__________________
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the
x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization.

Last edited by x265.cc; 25th October 2013 at 13:24.
x265.cc is offline   Reply With Quote
Old 25th October 2013, 16:08   #48  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by filler56789 View Post
Thanks for the experimental build, but you didn't say whether it works or doesn't work on your machine(s)

I took the time to compile the latest commit with GCC 4.8.1, including the stdin patch, and sadly the best the EXE does is encode 0 frames when fed through avs2yuv.
Fact is, it does not work, at least on windows plateforms...Checking the code, it seems that the issue comes from guessFrameCount() function within the pipeline (i.e the seeking returns always 0). So, encoding cannot start and fails.

Last edited by Kurtnoise; 25th October 2013 at 16:10.
Kurtnoise is offline   Reply With Quote
Old 25th October 2013, 16:11   #49  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by x265.cc View Post
Can you please tell me what i haven't understood? It would be helpful for me. Thanks

btw. i've now implemented this (the commandline way) for my buildbot.
the batch file calls the patched cmake command line...what can I say moreover ?
Kurtnoise is offline   Reply With Quote
Old 25th October 2013, 16:32   #50  |  Link
x265.cc
Registered User
 
Join Date: Oct 2013
Posts: 41
Quote:
Originally Posted by Kurtnoise View Post
the batch file calls the patched cmake command line...what can I say moreover ?
The use of

Quote:
cmake -G "Visual Studio 11" -T "v110_xp" ..\..\source
only will not work.

Also the batch file cannot be automated due to the fact that it needs "cmake-gui".

Anyway, the automation of cmake (means commandline only) is really not a big deal.
__________________
encoder.pw buildbot is NOT affiliated with, endorsed, or sponsored by the
x265 development team, MultiCoreWare Inc, Xiph.Org Foundation nor VideoLAN organization.

Last edited by x265.cc; 25th October 2013 at 16:37.
x265.cc is offline   Reply With Quote
Old 25th October 2013, 16:37   #51  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Monarc View Post
One question about x265.

on x265.org i can read:

Code:
x265 is a commercially funded open source implementation
on x265.com:

Code:
As the x265 reaches production, flat fee and per-unit commercial licenses will be available for companies that cannot accept x265 under a GPL license.
So x265 is a normal commercial product?
And x265 will be re-licensed under a new licence, when ready?
And sold like a normal product?
Commercial licenses are available now for companies that wish to distribute x265 in their products without being subject to the conditions of the GPL license. Contact me - license at x265.com.

Tom
MulticoreWare

Last edited by x265_Project; 1st November 2015 at 06:50. Reason: correct email address
  Reply With Quote
Old 25th October 2013, 18:06   #52  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 95
Quote:
Originally Posted by Kurtnoise View Post
Fact is, it does not work, at least on windows plateforms...Checking the code, it seems that the issue comes from guessFrameCount() function within the pipeline (i.e the seeking returns always 0). So, encoding cannot start and fails.
You can't seek in pipes. That has nothing to do with the platform.

Input should be buffered instead.
Obviously, piping is useless if you need to buffer the whole input.
MoSal is offline   Reply With Quote
Old 26th October 2013, 03:02   #53  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
Concerning 16bpp, I'm wondering whether this is for the future implementation of higher bit depth output, to avoid the issues that have been noted regarding x264 and 12/14-bit support? Is it [mostly] irrelevant for current 8bpp-only encoding cases, or is there a generalized visual or coding efficiency benefit (I assume there might be) from having internal processing in 16bpp even though from what I can tell, the input and output of 16bpp builds is still restricted to only 8bpp? I'm assuming that there is some kind of performance hit from using 16bpp builds, just because of the higher complexity math and any discrepancies that might exist in the asm between the two versions.

I guess what I'm getting at here is, is the -DHIGH_BIT_DEPTH option actually worth using at this point in time? I've not seen this particular part explained.
qyot27 is offline   Reply With Quote
Old 26th October 2013, 05:38   #54  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Quote:
Originally Posted by MoSal View Post
You can't seek in pipes. That has nothing to do with the platform.

Input should be buffered instead.
Obviously, piping is useless if you need to buffer the whole input.
Well...I meant, guessFrameCount() uses the seekg/tellg to find the current position/size of the stream. That's all.
Kurtnoise is offline   Reply With Quote
Old 27th October 2013, 20:48   #55  |  Link
DarrellS
Registered User
 
Join Date: Mar 2013
Posts: 28
Finally, there are a couple of x265 builds that accept stdin "-".

http://forum.videohelp.com/attachments/208...ccac3a7d3622.7z


https://x265.cc/

Here is the working command argument for Virtualdub 1.10.3 external encoder...

--input-res %(width)x%(height) --fps %(fps) --q 24 --keyint 40 --max-merge 3 --hash 1 --no-rect --wpp --tu-intra-depth 1 --tu-inter-depth 1 --no-tskip --frame-threads 4 - -o "%(tempvideofile)"
DarrellS is offline   Reply With Quote
Old 28th October 2013, 09:18   #56  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
A source patch for reading YUV4MPEG from stdin was published in the mailinglist. So expect a build with Y4M piping support soon™...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th October 2013, 09:20   #57  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
It was already there in my package from here...
Kurtnoise is offline   Reply With Quote
Old 29th October 2013, 20:32   #58  |  Link
x265_Project
Guest
 
Posts: n/a
x265 reaches 0.5 milestone

New stable version tag 0.5

= New Features =
* x265 can now be built by Mac OS X clang compiler
* install/uninstall build targets (install-only for Windows)
* Our cmake scripts now build static and shared libraries
* --ref N is now supported for enabling multiple L0 references
* SSIM global statistic reporting (--ssim)
* CSV logging is now a core feature, introduced per-frame logging

= API Changes =
* "_t" suffix removed from public data types for POSIX compatibility
* public API is now versioned
* --cpuid meaning has changed from level to capability bitmap, same as x264
* param.bipredSearchRange has been removed (--bpredrange N)
* param.maxNumReferences has been added (--ref N)
* param.csvfn has been added (--csv FILENAME.csv)
* PSNR and/or SSIM reporting are optional (--[no-]psnr --[no-]ssim)
* x265_version_str exported string symbol with version (tag) info
* x265_build_info_str exported string symbol with compile info
* x265_encoder_get_stats() method for querying encoder statistics
* x265_encoder_log() method for writing to CSV log file
* x265_param_parse() method for configuring x265_param_t via strings
* x265 now requires cmake 2.8.8 or later in order to build
* Weightp options re-enabled, but feature is still unfinished
* param.rc.aqmode, param.rc.aqstrength for unfinished AQ support

= Improvements =
* x265 is deterministic at -F1 and separately deterministic for Fn>1
(ie: -F2 and -F12 will give the same outputs if all other args are same)
* We have adopted a bidir search more closely resembling x264's bidir
* Lookahead analysis now includes bidir candidates for B slice types
* Lookahead uses thread pool and wave-front block scheduling
* The "multiple of min CU size (4)" resolution requirement has been removed
* More x264 assembly is being used for motion search and bidir MC
* PSNR and SSIM are measured row-by-row after deblocking and SAO
* Use of Standard Template Library classes has been removed
* SIMD Vector Classes are no longer used for 8bpp primitives

= Upcoming improvements =
* support in CLI for reading YUV or Y4M on stdin (already in default)
* performance presets
* Main10 profile
* Weightp in lookahead, weight analysis adapted from x264
* lookahead worker thread
* Adaptive QP
  Reply With Quote
Old 30th October 2013, 10:50   #59  |  Link
Kurtnoise
Swallowed in the Sea
 
Kurtnoise's Avatar
 
Join Date: Oct 2002
Location: Aix-en-Provence, France
Posts: 5,191
Nice work...

btw, what is the status of high bits depth ? It looks like it's clamped to 8bits in the current code...but I'm just wondering.
Kurtnoise is offline   Reply With Quote
Old 30th October 2013, 10:51   #60  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
The buildbot author reported that the compiling fails for the 16bpp branch. He may publish the logs there too...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Reply

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 18:01.


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