VideoHelp Forum
+ Reply to Thread
Page 1 of 27
1 2 3 11 ... LastLast
Results 1 to 30 of 782
Thread
  1. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Perhaps it's time to open a fresh thread, not focused specifically on MinGW builds.

    I just posted a revised version of the x265 Evaluator's Guide.

    Feedback and suggestions are welcomed.

    Thanks,
    Tom
    MulticoreWare
    Quote Quote  
  2. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    i assume you have read my (p)review, overall i'd say x265 is coming along quite nicely, i'm really surprised at the quality of the encodes. you guys should consider offering official builds, and as i also said in the other thread seriously consider a feature freeze until you can get the encoding speeds up a bit; maybe also consider an official x265 decoder that can easily be implemented in existing media players easily.
    Quote Quote  
  3. Feedback and suggestions are welcomed.
    here, you go:
    • Why "At least 8GB of RAM recommended" ?
    • if you post command line inside a guide stick with either the '--'-options or the '-'-options mixing them is just confusing.
    • "turn on aq with --aq-mode to have better visual quality while using rate control" -> 'using rate contol' is the same as not using --cq ?
    • "x265 can now be built by the Mac OS X clang compiler" -> will test tomorrow
    • "-V/--version Version details" -> or not:
      x265.exe --version
      x265.exe: unrecognized option `--version'
    • " -[no-]ssim Calculation and reporting of Structural similarity values
      -[no-]psnr Calculation and reporting Peak Signal to Noise Radio"
      should be '--[no-]..."
    • "--recon-depth Bit-depth of output file" -> better stay with the command line help wording "--recon-depth Bit-depth of reconstructed raw image file" to avoid confusion
      (same for '--recon-depth Bit-depth of output file')
    • "-s/--ctu Maximum CU size (width and height)
      Values: 16, 32, 64 (Default)
      --tu-intra-depth Max TU recursive depth for intra CUs
      Values: 1, 2, 3 (Default)
      --tu-inter-depth Max TU recursive depth for inter CUs
      Values: 1, 2, 3 (Default))"
      Why are these so limited? With 1080p and higher higher values should be possible.
    • "medium
      --tu-inter-depth 1 --tu-intra-depth 1 --rd 0 --max-merge 3 --no-tskip"
      Shouldn't the medium preset be 'empty' since it should only consist of the default settings?
      Also this is still conflicting with:
      --tu-intra-depth Max TU recursive depth for intra CUs
      Values: 1, 2, 3 (Default)
      --tu-inter-depth Max TU recursive depth for inter CUs
      Values: 1, 2, 3 (Default)
      --rd Level of RD in mode decision
      Range of values: 0: Least; 1: Lightweight RDO Analysis;
      2: Full RDO Analysis (Default)
      --max-merge Maximum number of merge candidates
      Range of values: 1 to 5
      Default: 5
      --tskip-fast Enable fast intra transform skipping (Default)



    Cu Selur
    Quote Quote  
  4. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Necessary nitpick:

    The PDF still says:

    If not building on Windows XP but want the binary to be XP compatible, enable WINXP_SUPPORT CMake option
    Since sometime before 1975, I've been telling you, the MCW people, that "enabling WINXP_SUPPORT CMake option" IS NOT sufficient for generating XP-compatible binaries on Windows Vista / Seven / whatever. Please include correct AND complete information in both the Evaluators's Guide and the x265 wiki.
    You really should stop being sooooo MSVC-centric, BTW && IMNSHO.
    Last edited by El Heggunte; 7th Nov 2013 at 19:25. Reason: \\\\\\\\\\\\
    Quote Quote  
  5. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by Selur View Post
    Feedback and suggestions are welcomed.
    here, you go:
    • Why "At least 8GB of RAM recommended" ?
    • if you post command line inside a guide stick with either the '--'-options or the '-'-options mixing them is just confusing.
    • "turn on aq with --aq-mode to have better visual quality while using rate control" -> 'using rate contol' is the same as not using --cq ?
    • "x265 can now be built by the Mac OS X clang compiler" -> will test tomorrow
    • "-V/--version Version details" -> or not:
      x265.exe --version
      x265.exe: unrecognized option `--version'
    • " -[no-]ssim Calculation and reporting of Structural similarity values
      -[no-]psnr Calculation and reporting Peak Signal to Noise Radio"
      should be '--[no-]..."
    • "--recon-depth Bit-depth of output file" -> better stay with the command line help wording "--recon-depth Bit-depth of reconstructed raw image file" to avoid confusion
      (same for '--recon-depth Bit-depth of output file')
    • "-s/--ctu Maximum CU size (width and height)
      Values: 16, 32, 64 (Default)
      --tu-intra-depth Max TU recursive depth for intra CUs
      Values: 1, 2, 3 (Default)
      --tu-inter-depth Max TU recursive depth for inter CUs
      Values: 1, 2, 3 (Default))"
      Why are these so limited? With 1080p and higher higher values should be possible.
    • "medium
      --tu-inter-depth 1 --tu-intra-depth 1 --rd 0 --max-merge 3 --no-tskip"
      Shouldn't the medium preset be 'empty' since it should only consist of the default settings?
      Also this is still conflicting with:
      --tu-intra-depth Max TU recursive depth for intra CUs
      Values: 1, 2, 3 (Default)
      --tu-inter-depth Max TU recursive depth for inter CUs
      Values: 1, 2, 3 (Default)
      --rd Level of RD in mode decision
      Range of values: 0: Least; 1: Lightweight RDO Analysis;
      2: Full RDO Analysis (Default)
      --max-merge Maximum number of merge candidates
      Range of values: 1 to 5
      Default: 5
      --tskip-fast Enable fast intra transform skipping (Default)
    Good feedback. Thanks. Let me discuss with the team before I respond.

    Tom
    Quote Quote  
  6. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by El Heggunte View Post
    Necessary nitpick:

    The PDF still says:

    If not building on Windows XP but want the binary to be XP compatible, enable WINXP_SUPPORT CMake option
    Since sometime before 1975, I've been telling you, the MCW people, that "enabling WINXP_SUPPORT CMake option" IS NOT sufficient for generating XP-compatible binaries on Windows Vista / Seven / whatever. Please include correct AND complete information in both the Evaluators's Guide and the x265 wiki.
    You really should stop being sooooo MSVC-centric, BTW && IMNSHO.
    I'm personally not well versed in this subject (building on/for Win XP). Can you suggest the instructions we should have there, or point me to the right place?

    I agree that there are some opportunities for improvement in our guide for building x265. We have some quick instructions on the main Wiki Page, and more detailed instructions on another page. But maybe we need to put together a more comprehensive document. Again... contributions are welcomed.


    Tom
    Quote Quote  
  7. x265 can now be built by the Mac OS X clang compiler
    compiling using XCode 4 on OS X 10.6.8 doesn't work, neither does following the linux instructions.

    -> Please add tested instructions how to build x265 for Mac OS X 10.6.8 to the wiki. Thanks.
    Quote Quote  
  8. Forgive me if this is the wrong place to post this problem (If so, please tell me where the correct place is). I have not been able to get an encode at anything but 25 fps. I need 23.976. I have tried various formats of --fps but have been unable to get it to work and all video/audio is out of sync. Can someone please point me in the right direction?

    edit:clarify
    Last edited by gaak; 9th Nov 2013 at 17:29.
    Quote Quote  
  9. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    ^ @ gaak: you MUST specify the framerate when muxing to MP4 (via MP4Box) or to AVI/MKV (in Graphstudio). The up-to-date HEVC Source Filter from Strongene can set the correct framerate to the DirectShow muxers, *if* the filename includes such information,

    for example, "test_23.976fps.265".
    Quote Quote  
  10. Thank you for the quick reply.
    Quote Quote  
  11. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    I just posted an updated x265 Evaluator's Guide. Feedback is welcomed.

    Tom
    Quote Quote  
  12. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    i'm still not clear with most of the command parameters, what each do.

    an in-depth glossary explaining how to use them, and in which scenario benefit most, etc. would come in handy.

    and with a few example encoding sitatuions to get us going. you know.. encoding film source, interlace source, what works best when dealing with dark vs brighter scenes, and low motion vs higher motion, etc.

    i mean, what's one more document to complete this encoder. it would definately help!
    Quote Quote  
  13. @x265:
    first thoughts:
    - 'Slice decision options': order in '--b-adapt' below '--bframes'; seems more logical since '--b-adapt' is a b-frame sub-option.
    - Question regarding 'Sample Adaptive Offset loop filter:'
    --sao-lcu-opt 0: SAO picture-based optimization (requires -F1); 1: SAO LCU-based optimization (Default)
    Since '1: SAO LCU-based optimization' doesn't have any requirements and unlike '0: SAO picture-based optimization' shouldn't it be number '0' ? (Or did I misunderstand the whole thing and '-F1' is a requirement for '--sao' to be usable at all?

    Note: I like the 'Quality Presets' overview table. (cosmetics: some of the lines in the table are missing)

    ----

    @vhelp:
    It's like asking for car-tuning recommendations, while the mechanic is still doing test drives in an restricted are to make sure the car works at all,... it's far to early to write down any 'in-depth' feature explanations. Most features do not work 100% or have not be tested properly.

    Regarding interlaced content:
    1. read http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Video_coding_layer (reading the linked documents there might also be a good idea)
    2. HEVC does not really 'like' interlaced content (FINALLY!!). Interlaced content will be sent either by coding each field as a separate picture or by coding each frame as a separate picture. Like one can imagine, both methods should harm coding efficiency quite a bit, so my recommendation would be to move away from interlaced content. There is no MBAFF, PAFF or other optimizations for interlaced content in HEVC. The world is not interlaced and people should more away from interlaced content. (+ from the looks of it x265 can't properly handle interlaced content atm., so no separate field or frame splitting)

    Cu Selur
    Quote Quote  
  14. Also does "--frame-threads 0" (0 = auto; which is the default) imply that '--sao-lcu-opt 1' can't be used, since it requires '-F1', or isn't 0 = auto ?

    thought 0 = auto because of:
    Code:
    void x265_param_default(x265_param *param) {
         memset(param, 0, sizeof(x265_param));
          /* Applying non-zero default values to all elements in the param structure */
         param->logLevel = X265_LOG_INFO;
         param->bEnableWavefront = 1;
         param->frameNumThreads = 0;
         param->poolNumThreads = 0;
    Last edited by Selur; 25th Nov 2013 at 05:46.
    Quote Quote  
  15. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by vhelp View Post
    i'm still not clear with most of the command parameters, what each do.

    an in-depth glossary explaining how to use them, and in which scenario benefit most, etc. would come in handy.

    and with a few example encoding sitatuions to get us going. you know.. encoding film source, interlace source, what works best when dealing with dark vs brighter scenes, and low motion vs higher motion, etc.

    i mean, what's one more document to complete this encoder. it would definately help!
    I agree. We continue to work on to improve our documentation... but contributions are welcomed! Ping me directly if you want to help out.

    Tom
    Quote Quote  
  16. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    a) post #1 of the topic
    https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds
    has been updated "for your pleasure"

    b) it must have always been quite obvious, but your name has been on my Ignore List since 2013-August-13
    So far, you have done nothing that could change my opinion about yourself
    Quote Quote  
  17. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Stay classy JMK
    Quote Quote  
  18. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    We've updated x265's performance presets, providing better performance and compression efficiency (quality at any given bitrate) for most presets. We've also worked to provide a good range of values along the speed vs. efficiency curve.

    I've posted a new x265 Evaluator's Guide.

    As always, constructive feedback is welcomed.

    Tom
    Quote Quote  
  19. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    We've declared version 0.6, merging the stable and default tip for this build.

    Release notes...
    x265 0.6 is a regularly scheduled release

    There were large improvements in compression efficiency since 0.5, mostly a result of the completion of weightp and b-pyramid. There is also a large amount of new assembly code; replacing most of the compiler intrinsic functions and adding coverage for some new primitives.


    = New Features =
    * CLI reads input video from stdin
    * Main10 profile is enabled, requires a HIGH_BIT_DEPTH build
    * weightp is now complete enough to be enabled by default
    * performance presets have been defined, matching x264 preset names
    * b-pyramid (hierarchical B frames) now supported
    * Constant Rate Factor rate control is considered stable
    * Adaptive Quantization introduced (experimental)

    Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.


    = API Changes =
    * x265_nal data members renamed
    * x265_picture now has colorSpace member
    * --weightp enabled by default
    * default parameters now match our medium preset
    * new x265_param_default_preset() method for assigning preset and tune
    * new x265_param_alloc() and x265_param_free() methods for version safety
    * new x265_picture_alloc() and x265_picture_free() methods for version safety

    The public data structures have changed enough that apps compiled against previous versions of x265 must be recompiled to use x265 0.6. We are taking steps to add version safety to the public interface. If you use the new alloc/free methods for the param and picture structures, and use x265_param_parse() to set param values by name, you will likely not have to recompile your application to dynamically link against later releases of x265.


    = New Command Options =
    * --y4m overrides detection of Y4M input stream, ex: x265 --y4m - out.hevc < vid.y4m
    * --version long option alias for -V
    * -p/--preset sets performance preset
    * -t/--tune sets parameter tuning
    * --b-pyramid enabled by default
    * --input-csp color space parameter (only i420 is supported in this release)
    * --crf constant rate factor rate control
    * --aq-mode and --aq-strength

    See x265 --help for more details


    = Upcoming improvements =
    * motion compensated weightp analysis (using lookahead data)
    * CU-tree (adapted from x264 macroblock tree)
    * VBV rate control
    * assembly code optimization for HIGH_BIT_DEPTH builds 1
    Quote Quote  
  20. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    We are in the process of enabling CUTree (the HEVC successor to MBtree) by default. Settings are a bit complicated at the moment due to inter-dependencies between modes. We will clean this up in the coming days (expect changes to defaults and presets). If you're doing any critical work, use a build from the stable branch.

    The current default setting in the repo is... --tune psnr (CUTree ON, AQ-strength zero, weightP ON).

    --no-cutree turns both CUTree and AQ off

    --tune ssim turns both CUTree and AQ on

    Note that some of these optimizations improve visual quality, but are not as noticeable with respect to objective measurements. The x265 team uses objective (video noise) measurements like PSNR and SSIM to measure the effect of improvements, but we are more focused on subjective visual quality than objective measurements.

    As always, feedback (with supporting data please) is welcomed.

    Thanks,
    Tom
    Quote Quote  
  21. We are in the process of enabling CUTree (the HEVC successor to MBtree) by default.
    Nice, may be this will also help a bit with the blurring.

    expect changes to defaults and presets
    Would be nice if someone could then also clean-up the preset definitions in common.cpp.

    In example:
    'ultra fast' uses:
    Code:
    param->bEnableLoopFilter = 1;
    since the defaults already contain:
    Code:
    param->bEnableLoopFilter = 1;
    this is unneeded and should be cleaned up.

    Cu Selur
    Quote Quote  
  22. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    [QUOTE=Selur;2289287]

    expect changes to defaults and presets
    Would be nice if someone could then also clean-up the preset definitions in common.cpp.

    In example:
    'ultra fast' uses:
    Code:
    param->bEnableLoopFilter = 1;
    since the defaults already contain:
    Code:
    param->bEnableLoopFilter = 1;
    this is unneeded and should be cleaned up.

    Cu Selur
    Good catch. The presets should only set parameters to non-default values.

    Tom
    Quote Quote  
  23. Member
    Join Date
    Nov 2013
    Location
    Taiwan
    Search PM
    Hi, I used my PC to encode any video with x265 and if not set --no-wpp it's will be crash

    my PC is http://valid.canardpc.com/ea0wc6
    Quote Quote  
  24. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by hiritsuki View Post
    Hi, I used my PC to encode any video with x265 and if not set --no-wpp it's will be crash

    my PC is http://valid.canardpc.com/ea0wc6
    Hiritsuki,
    Thanks for your feedback. I will send you a private message to connect directly. To see exactly where the crash occurs we will need you to run a "Release With Debug Information" (RelWithDebInfo) build.

    Tom
    MulticoreWare
    Quote Quote  
  25. Member
    Join Date
    Nov 2013
    Location
    Taiwan
    Search PM
    ok, I send mail to you with my contact information.
    Quote Quote  
  26. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    @x265 and team, thanks for all the updates so far. i could multicoresware that the speed has increased much more (10secs in my case per my usual std test video, i.e, 574kb vs speed imp'vmt 139kb) , but you did say the defaults and other things may have changes since those latest enhances. the size difference has me worried...what did i miss, or something else i need to now be aware of.

    please consider adding *all* the parameters in the completed encoding output report. this way, we can better gauge on the improvements. right now, all that is reported is the parameters that we initially feed the encoder--but does not include the default parameters and their values and the --preset parameters and values. including all this info in each new build will provide accurate measurements or assessments of the encodes from build to build, especially since they and other things change and are not fully documented in each new build. we need all the parameters and values spelled out in the final encoded output report.

    again, thank you!
    Last edited by vhelp; 20th Dec 2013 at 21:19.
    Quote Quote  
  27. Member x265's Avatar
    Join Date
    Aug 2013
    Location
    Sunnyvale, CA
    Search Comp PM
    Originally Posted by vhelp View Post
    @x265 and team, thanks for all the updates so far.
    You're welcome.
    ... speed has increased much more (10secs in my case per my usual std test video, i.e, 574kb vs speed imp'vmt 139kb) , but you did say the defaults and other things may have changes since those latest enhances. the size difference has me worried...what did i miss, or something else i need to now be aware of.
    Hard to say without more data.

    please consider adding *all* the parameters in the completed encoding output report. this way, we can better gauge on the improvements. right now, all that is reported is the parameters that we initially feed the encoder--but does not include the default parameters and their values and the --preset parameters and values. including all this info in each new build will provide accurate measurements or assessments of the encodes from build to build, especially since they and other things change and are not fully documented in each new build. we need all the parameters and values spelled out in the final encoded output report.

    again, thank you!
    Interesting suggestion. We thought about this early on. We decided to keep it simple, capturing only the input command-line options, to keep the log files from getting too big and difficult to read. But I could see the benefit from logging all the encoding parameters explicitly when you compare results from different builds over time, or do regression testing of settings.

    Tom
    Quote Quote  
  28. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    due to my slow dual core x2 speed cpu, for general quick testing, i've been using the same 100 frame video source file for every new build. two things i look for are: speed increases and quality difference. i am not trying assertain every specifics, just general observation results when using the following parameters:

    --preset ultrafast --input-res 720x480 --fps 23.976 --frames 100 --crf 17 --input - -o "h:\video.hm10"

    every encode that i complete i rename the file (for record keeping) to the following layout, for ver/build/enc_speed:

    Code:
    video.[0.6+193].[00.00.40].[ultrafast.2.47fps].hm10 - 574kb
    video.[0.6+195].[00.00.41].[ultrafast.2.46fps].hm10 - 574kb
    video.[0.6+198].[00.00.41].[ultrafast.2.47fps].hm10 - 574kb
    video.[0.6+200].[00.00.28].[ultrafast.3.73fps].hm10 - 139kb
    video.[0.6+204].[00.00.27].[ultrafast.3.80fps].hm10 - 139kb
    video.[0.6+207].[00.00.27].[ultrafast.3.59fps].hm10 - 139kb
    video.[0.6+208].[00.00.27].[ultrafast.3.85fps].hm10 - 139kb
    video.[0.6+209].[00.00.27].[ultrafast.3.87fps].hm10 - 139kb
    video.[0.6+210].[00.00.27].[ultrafast.3.86fps].hm10 - 139kb
    video.[0.6+219].[00.00.27].[ultrafast.3.72fps].hm10 - 139kb
    and if i have any of the ms office tools open, ie, ms access, the length of encoding time increases, as it did in the above results i just did. they should have been 2 seconds faster for that test clip.

    edit: it is difficult to measure performance gains/loss when you use --preset and the parameters and values are not available. worse, or compounding, is when you have parameters that are not set inside the x265.exe string and the x265 encoder adds those in, either as default or some other logic and whatever values it chooses to use with them, are all missing.

    hope all this helps.
    Last edited by vhelp; 20th Dec 2013 at 23:45.
    Quote Quote  
  29. Member PuzZLeR's Avatar
    Join Date
    Oct 2006
    Location
    Toronto Canada
    Search Comp PM
    Originally Posted by Selur
    so my recommendation would be to move away from interlaced content
    Yes indeed, it's not in the HEVC standard. Maybe a pre-mature question but, if you wish to use older, interlaced, content with x265, would you need to de-interlace it independently, or just not use it at all? I'm just curious how this all unfolds without MBAFF/PAFF in the mix.

    Yeah, I agree interlacing, a 1930s tech, shouldn't be honored for present/future content, but it sounds like alot of older footage is going to look even worse than it does today if, say in ten years from now, the video world is running entirely on HEVC.
    I hate VHS. I always did.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!