• 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • 龙船礼 有讲究 百岁龙 抖精神 2019-03-17
  • 新加坡航空将开通 全球最长商业航线 2019-03-17
  • 传说中的自由飞“翔” 当厕所被狂风吹上天 2019-03-12
  • 导游强迫交易获刑 曾辱骂威胁强迫游客消费上万元--旅游频道 2019-03-09
  • 北京正式推出租赁型职工集体宿舍 每间居住人数不超8人 2019-03-09
  • 美元短线拉升 随后回吐涨幅 2019-03-07
  • Welcome to

    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 > New and alternative video codecs

    Reply
     
    Thread Tools Search this Thread Display Modes
    Old 18th February 2019, 00:03   #1141  |  Link
    Member
     
    Mr_Khyron's Avatar
     
    Join Date: Nov 2002
    Location: Sweden
    Posts: 85
    SVT-VP9 Is Intel's Latest Open-Source Video Encoder Yielding High Performance VP9

    https://phoronix.com/scan.php?page=n...P9-Open-Source
    Quote:
    At the start of the month Intel open-sourced SVT-AV1 aiming for high-performance AV1 video encoding on CPUs. That complemented their existing SVT-HEVC encoder for H.265 content and already SVT-AV1 has been seeing nice performance improvements. Intel now has released SVT-VP9 as a speedy open-source VP9 video encoder.

    Uploaded on Friday was the initial public open-source commit of SVT-VP9, the Intel Scalable Video Technology VP9 encoder. With this encoder they are focusing on being able to provide real-time encoding of up to two 4Kp60 streams on an Intel Xeon Gold 6140 processor. SVT-VP9 is under a BSD-style license and currently runs on Windows and Linux.

    Earlier today I added now the SVT-VP9 test profile for benchmarking this new VP9 encoder via the Phoronix Test Suite. I've been testing SVT-VP9 on a few Intel/AMD Linux systems so far today and the early results are extremely promising.
    Mr_Khyron is offline   Reply With Quote
    Old 21st February 2019, 20:07   #1142  |  Link
    Registered User
     
    Join Date: Feb 2003
    Location: New York, NY (USA)
    Posts: 50
    Quote:
    Originally Posted by benwaggoner View Post
    So, N=maximum number of alt-ref frames that can be currently used, ala the --ref parameter in x264?
    Yes, it's somewhat similar to that. Note that the distance between equi-level ref-frames isn't necessarily the same, so it's not exactly the same. (I can explain this a bit further if I'm not making sense here.)

    Quote:
    I wish VP9 had a x265.readthedocs.io equivalent .
    Good luck getting Google to spend effort on that .

    [edit]

    Maybe I'm being unfair in that last comment, bit snarky also, so allow me to re-phrase that. I guess Google would have hoped that if they provide engineering talent, that other community contributors would have done these things that make it more widely useful but aren't necessary for Google internally. Obviously this never happened, but it would make sense from Google's perspective to hope for some more community participation than they've seen.

    Last edited by Beelzebubu; 21st February 2019 at 20:09.
    Beelzebubu is offline   Reply With Quote
    Old 21st February 2019, 20:26   #1143  |  Link
    Moderator
     
    Join Date: Jan 2006
    Location: Portland, OR
    Posts: 2,810
    Quote:
    Originally Posted by Beelzebubu View Post
    Good luck getting Google to spend effort on that .

    [edit]

    Maybe I'm being unfair in that last comment, bit snarky also, so allow me to re-phrase that. I guess Google would have hoped that if they provide engineering talent, that other community contributors would have done these things that make it more widely useful but aren't necessary for Google internally. Obviously this never happened, but it would make sense from Google's perspective to hope for some more community participation than they've seen.
    Doing it with community support would make plenty of sense. It seems more likely for AV1, which has a much broader set of stakeholders and a lot more options to choose between.
    __________________
    Ben Waggoner
    Principal Video Specialist, Amazon Prime Video

    My Compression Book
    benwaggoner is offline   Reply With Quote
    Old 28th February 2019, 23:26   #1144  |  Link
    Registered User
     
    Join Date: Oct 2014
    Posts: 268
    With vpxenc (tried with 1.7.0 and 1.8.0) I get weird rate-control.. 1.7.0 was undershooting quite a bit, 1.8.0 seemed to do better but with the same source and less bitrate it starts to overshoot out of nowhere (by quite a lot).

    Code:
    vpxenc --cpu-used=9 --good --end-usage=vbr --auto-alt-ref=6 --target-bitrate=6000 --passes=2 --pass=1 (and 2) --aq-mode=1 --row-mt=1
    I also tried adding '--cq-level=0' in there when which I've read in this thread somewhere. Am I doing something wrong (I get a videostream of 6856 kbit/sec, while x264 hits 5847 and x265 hits 5888) or is this just a VP9 thing that the rate-control might be a bit all over the place?
    dipje is offline   Reply With Quote
    Old 2nd March 2019, 05:49   #1145  |  Link
    Registered User
     
    Join Date: Jan 2019
    Posts: 5
    Quote:
    Originally Posted by dipje View Post
    Code:
    vpxenc --cpu-used=9 --good --end-usage=vbr --auto-alt-ref=6 --target-bitrate=6000 --passes=2 --pass=1 (and 2) --aq-mode=1 --row-mt=1
    1. For general-purpose encoding is recommended to set --cpu-used to [0 .. 3]. The latter, namely 3, is already reasonably fast (when properly supported by multithreading, more on this later on) while still maintaining decent quality.
    2. Do keep in mind that --auto-alt-ref accepts the full range of integers in [0 .. 6], not only 0/1/6. The benefits of switching from 0 to 1 are usually (most sources, at most resolutions) significantly greater than switching from 1 to any >1 value; higher values such as 6 may provide negligible gains over lower values such 2/3, in which case the speed penalty may become undesirable. As you are already instructing the encoder to be fast with --cpu-used, it's probably a saner option to set --auto-alt-ref to 1. For general-purpose encoding, I'd look at auto-alt-ref 2/3 for cpu-used 1/2 thus reserving the highest possible value of 6 to cpu-used 0.
    3. It's redundant to manually specify a --pass, by setting up --passes the encoder can automatically run multi-pass encodings.
    4. While --aq-mode 1/2 will occasionally (some sources, at some resolutions) provide better results, accompanied or not by --alt-ref-aq >0, for general-purpose encoding is strongly recommended to disable AQ by setting aq-mode to 0.
    5. For general-purpose encoding is recommended to use explicitly --lag-in-frames 25, and also --enable-tpl 1.

    Properly enabling multithreading in vpxenc/libvpx requires several parameters, not just --row-mt on its own. In addition to setting row-mt to 1, it's needed to set up the tiles too and that can be achieved as it follows: explicitly disable tile rows (--tile-rows 0), and explicitly enable tile columns instead (set --tile-columns to 5/6, 5 is already enough for 99.9999% of encodings; do note that the encoder will automatically use as many horizontal tiles as permitted by the horizontal resolution, i.e. width, of the source. In practical scenarios, the encoder will restrict tile-columns to [0 .. 3] much more often than not because that corresponds to sources up to 16:9 2160p). Lastly, enable explicitly --threads by setting up a high value, for instance 64 (do NOT change --threads according to the number of actual logical cores of the machine used for encoding, set up a high value and the encoder will spawn automatically as many threads as it needs). Wrapping it up, this is how multithreading should be set up for file-based encoding (nota bene, chunk-based encoding is addressed differently): --tile-rows=0 --tile-columns=5 --row-mt=1 --threads=64.

    The rate control of vpxenc/libvpx is peculiar, to say the least. It works better with quantizers (--end-usage cq/q, plus --cq-level [desired CRF], plus --min-q and/or --max-q [desired QP]) than with bitrates (--end-usage vbr/cbr, plus --target-bitrate, plus --undershoot-pct and/or --overshot-pct, plus --bias-pct). The absolute best results are achieved through chunk-based encoding (i.e. the very way vpxenc was designed to be used), rather than the file-based encoding that would be expected by normal people (a very non-specific alias for consumers). Yes, it's probably fair to state that "rate control in libvpx sucks", as long as it's understood that attempting to achieve strict rate control in file-based encoding will undershoot/overshoot much more often than not especially when using lax parameters (for instance only --target-bitrate on its own, without the other RC tools).

    Belated disclaimer: my insight of vpxenc/libvpx is purely empirical, gained from using them extensively myself on various sources, at various resolutions, with various parameter sets. Professionals such as Ronald can provide technical insight, if you can actually persuade them to do so.
    Asilurr is offline   Reply With Quote
    Old 13th March 2019, 13:21   #1146  |  Link
    German doom9/Gleitz SuMo
     
    LigH's Avatar
     
    Join Date: Oct 2001
    Location: Germany, rural Altmark
    Posts: 5,812
    New upload (MSYS2; MinGW32: GCC 7.4.0 / MinGW64: GCC 8.3.0):

    VPx v1.8.0-226-g7969c6e0b
    __________________

    New German Gleitz board
    MediaFire: x264 | x265 | VPx | AOM | Xvid
    LigH is offline   Reply With Quote
    Old 15th March 2019, 10:42   #1147  |  Link
    Registered User
     
    Join Date: Nov 2007
    Posts: 49
    Quote:
    Originally Posted by LigH View Post
    New upload (MSYS2; MinGW32: GCC 7.4.0 / MinGW64: GCC 8.3.0):

    VPx v1.8.0-226-g7969c6e0b
    Thanks for your work !

    Is there any changelog about VP9 evolution ?
    Each new build is slower than its predecessor... I expected that there could be some speed optimization all over the time and not the contrary
    Leeloo Mina?is offline   Reply With Quote
    Old 18th March 2019, 01:57   #1148  |  Link
    German doom9/Gleitz SuMo
     
    LigH's Avatar
     
    Join Date: Oct 2001
    Location: Germany, rural Altmark
    Posts: 5,812
    The commit log is at https://chromium.googlesource.com/webm/libvpx
    __________________

    New German Gleitz board
    MediaFire: x264 | x265 | VPx | AOM | Xvid
    LigH is offline   Reply With Quote
    Old 13th April 2019, 02:04   #1149  |  Link
    Registered User
     
    Join Date: Aug 2018
    Posts: 17
    I'm getting VMAF score of VP9 video which is less than H.264 at 500Kbps using highest quality settings on each. Anyone encounter this before?

    the ffmpeg 2-pass settings for

    x264 - VMAF score 72.8

    Code:
    ./ffmpeg -i scene1.mp4 -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -preset placebo -pass 1 -f mp4 -y /dev/null /
    && ./ffmpeg -i scene1.mp4 -movflags +faststart -pix_fmt yuv420p -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -pass 2 -preset placebo ./x264/scene1/x264_500k.mp4
    vp9 - VMAF score 67.1


    Quote:
    ./ffmpeg -i scene1.mp4 -c:v libvpx-vp9 -an -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 0 -tile-columns 2 -threads 8 -pass 1 -f webm -y /dev/null && /
    ./ffmpeg -i scene1.mp4 -pix_fmt yuv420p -c:v libvpx-vp9 -an -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 0 -tile-columns 2 -threads 8 -pass 2 ./vp9/scene1/vp9_500k.webm

    This seems completely unexpected! I've attached both encoded files below




    VMAF was then measure with the following command
    Code:
    ../../ffmpeg -i vp9_500k.webm -i ../../scene1.mp4 -filter_complex "[0:v]scale=1920x800:flags=bicubic[main];[main][1:v]libvmaf=model_path=/home/kay/vmaf/model/vmaf_v0.6.1.pkl" -f null - >>vmaf-scene1.txt -hide_banner
    The encoded files can be downloaded from here https://github.com/Netflix/vmaf/file...oded-files.zip
    singhkays is offline   Reply With Quote
    Old 13th April 2019, 02:52   #1150  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,758
    Quote:
    Originally Posted by singhkays View Post
    I'm getting VMAF score of VP9 video which is less than H.264 at 500Kbps using highest quality settings on each. Anyone encounter this before?

    the ffmpeg 2-pass settings for

    x264 - VMAF score 72.8

    Code:
    ./ffmpeg -i scene1.mp4 -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -preset placebo -pass 1 -f mp4 -y /dev/null /
    && ./ffmpeg -i scene1.mp4 -movflags +faststart -pix_fmt yuv420p -c:v libx264 -an -b:v 500k -filter:v scale=720:-1 -pass 2 -preset placebo ./x264/scene1/x264_500k.mp4
    vp9 - VMAF score 67.1





    This seems completely unexpected! I've attached both encoded files below




    VMAF was then measure with the following command
    Code:
    ../../ffmpeg -i vp9_500k.webm -i ../../scene1.mp4 -filter_complex "[0:v]scale=1920x800:flags=bicubic[main];[main][1:v]libvmaf=model_path=/home/kay/vmaf/model/vmaf_v0.6.1.pkl" -f null - >>vmaf-scene1.txt -hide_banner
    The encoded files can be downloaded from here https://github.com/Netflix/vmaf/file...oded-files.zip



    something buggy about your vp9 encode , and the frames are not aligned at the end between x264 and vp9 . You didn't upload the immediate source, but both encodes have duplicate frames that aren't in the movie

    You can decode to uncompressed or lossless I-frame like utvideo and compare them

    ffmpeg gives warning when encoding the vp9 version too
    Quote:
    #invalid length 0x11 > 0x3dfb4 in parent
    poisondeathray is offline   Reply With Quote
    Old 13th April 2019, 14:50   #1151  |  Link
    Registered User
     
    Join Date: Feb 2003
    Location: New York, NY (USA)
    Posts: 50
    Quote:
    Originally Posted by poisondeathray View Post
    something buggy about your vp9 encode
    Sometimes the timebase is different. You can ignore timestamps by using "settb=1/30,setpts=N" as extra lavfilters in your commandline for each of the two video streams.
    Beelzebubu is offline   Reply With Quote
    Old 13th April 2019, 15:43   #1152  |  Link
    Registered User
     
    Join Date: Sep 2007
    Posts: 3,758
    Quote:
    Originally Posted by Beelzebubu View Post
    Sometimes the timebase is different. You can ignore timestamps by using "settb=1/30,setpts=N" as extra lavfilters in your commandline for each of the two video streams.
    Still buggy . More frame drops now, gaps in motion, and the framecount does not match when setting timebase and pts

    You can index it with avisynth/vapoursynth, but frames still don't match

    I suspect he had issues with the immediate source
    poisondeathray is offline   Reply With Quote
    Old 13th April 2019, 16:13   #1153  |  Link
    Registered User
     
    Join Date: Apr 2018
    Posts: 21
    What is the proper way to multithread in 2019? Is it possible to achieve 100% cpu usage on 8 cores? Also, I read somewhere that frame parallel is not needed anymore. Is that correct?

    Last edited by user1085; 13th April 2019 at 16:16.
    user1085 is offline   Reply With Quote
    Old 14th April 2019, 03:58   #1154  |  Link
    Registered User
     
    Join Date: Aug 2018
    Posts: 17
    Quote:
    Originally Posted by poisondeathray View Post
    Still buggy . More frame drops now, gaps in motion, and the framecount does not match when setting timebase and pts

    You can index it with avisynth/vapoursynth, but frames still don't match

    I suspect he had issues with the immediate source
    I think I fixed it. I changed the VP9 in WebM container to VP9 in MP4 container and getting expected VMAF scores now

    72.8 for x264 vs 74.7 for VP9
    singhkays is offline   Reply With Quote
    Old 16th April 2019, 12:45   #1155  |  Link
    Registered User
     
    Join Date: Feb 2003
    Location: New York, NY (USA)
    Posts: 50
    Quote:
    Originally Posted by user1085 View Post
    What is the proper way to multithread in 2019? Is it possible to achieve 100% cpu usage on 8 cores?
    Using aomenc, --tile-columns=3 --threads=8 should give you 8 tile col threads. Also try --row-mt and non-zero values for --tile-rows.

    Quote:
    Originally Posted by user1085 View Post
    Also, I read somewhere that frame parallel is not needed anymore. Is that correct?
    See last paragraph in //www.zs-x.com/showthread.p...91#post1859991
    Beelzebubu is offline   Reply With Quote
    Old 16th April 2019, 20:28   #1156  |  Link
    Registered User
     
    Join Date: Aug 2018
    Posts: 17
    Quote:
    Originally Posted by poisondeathray View Post
    Still buggy . More frame drops now, gaps in motion, and the framecount does not match when setting timebase and pts

    You can index it with avisynth/vapoursynth, but frames still don't match

    I suspect he had issues with the immediate source
    Quote:
    Originally Posted by Beelzebubu View Post
    Sometimes the timebase is different. You can ignore timestamps by using "settb=1/30,setpts=N" as extra lavfilters in your commandline for each of the two video streams.
    I'm seeing another issue with my VP9 encode. I'm getting the following message after 1st pass -"output file is empty". Is this expected for first pass?

    Code:
    [libvpx-vp9 @ 0x5f5d480] v1.8.0-366-gc46694c1d
    Output #0, mp4, to '/dev/null':
      Metadata:
        major_brand     : isom
        minor_version   : 512
        compatible_brands: isomiso2avc1mp41
        encoder         : Lavf58.27.101
        Stream #0:0(eng): Video: vp9 (libvpx-vp9) (vp09 / 0x39307076), yuv420p, 720x300 [SAR 1:1 DAR 12:5], q=-1--1, 500 kb/s, 24 fps, 12288 tbn, 24 tbc (default)
        Metadata:
          handler_name    : VideoHandler
          encoder         : Lavc58.49.100 libvpx-vp9
        Side data:
          cpb: bitrate max/min/avg: 500000/500000/500000 buffer size: 1000000 vbv_delay: -1
    frame=  158 fps=0.0 q=0.0 Lsize=       0kB time=00:00:00.00 bitrate=N/A speed=   0x
    video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
    Output file is empty, nothing was encoded
    Here's the CLI for trying to get a 500K file
    Code:
    ./ffmpeg -i scene6.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -auto-alt-ref 1 -lag-in-frames 25 -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 1 -tile-rows 2 -tile-columns 2 -threads 16  -enable-tpl 1 -pass 1 -minrate 500k -maxrate 500k -bufsize 1000k -g 240 -f mp4 -hide_banner -y /dev/null && \
    ./ffmpeg -i scene6.mp4 -c:v libvpx-vp9 -pix_fmt yuv420p -auto-alt-ref 1 -lag-in-frames 25 -b:v 500k -filter:v scale=720:-1 -row-mt 1 -quality best -cpu-used 1 -tile-rows 2 -tile-columns 2 -threads 16 -enable-tpl 1 -pass 2 -minrate 500k -maxrate 500k -bufsize 1000k -g 240 -hide_banner -movflags faststart ./vp9/scene6/vp9_500k.mp4
    singhkays is offline   Reply With Quote
    Old 17th April 2019, 06:54   #1157  |  Link
    Registered User
     
    Join Date: Jan 2019
    Posts: 5
    These suggestions will probably help you:
    1. With contemporary versions of libvpx there's no real benefit to using tile-rows>0. The combination of tile-rows=0/tile-columns>0/row-mt>0 is advisable.
    2. Do not expect multithreading miracles when working with sources which have a paltry 720 pixels horizontal resolution. There are "thresholds" which allow specific values of tile-columns (the primary MT mechanism of libvpx), and then there's row-mt which basically "doubles" the thread count (it's not exactly a 2x count, it depends on the source). Practical example: with your 720 pixels horizontal resolution source, you input tile-columns=2 and threads=16 to the encoder. It accepts them without throwing errors back at you, but it will default to what it can actually use on your source: tile-columns=1 and threads~4 (assuming row-mt=1); the encoder simply can't "fit in" 16 threads working with a 720 width source.
    Code:
    horizontal resolution | superblock columns | horizontal tiles | tile-columns | rough thread count with row-mt=1
    0001-0448 | 001-007 | 01 | 0 | ~02
    0449-0960 | 008-015 | 02 | 1 | ~04
    0961-1984 | 016-031 | 04 | 2 | ~08
    1985-4032 | 032-063 | 08 | 3 | ~16
    4033-8128 | 064-127 | 16 | 4 | ~32
    3. Considering your current quality best, you don't really care about the encoding speed; however do keep in mind that quality good usually provides superior results (yes, really). As such, switching to quality good/cpu-used=0/auto-alt-ref=6 is advisable.
    4. FFmpeg's "output file is empty" notification is entirely expected, you are outputting the first pass to /dev/null.
    Asilurr is offline   Reply With Quote
    Old 17th April 2019, 07:39   #1158  |  Link
    Registered User
     
    Join Date: Aug 2018
    Posts: 17
    Quote:
    Originally Posted by Asilurr View Post
    These suggestions will probably help you:
    1. With contemporary versions of libvpx there's no real benefit to using tile-rows>0. The combination of tile-rows=0/tile-columns>0/row-mt>0 is advisable.
    2. Do not expect multithreading miracles when working with sources which have a paltry 720 pixels horizontal resolution. There are "thresholds" which allow specific values of tile-columns (the primary MT mechanism of libvpx), and then there's row-mt which basically "doubles" the thread count (it's not exactly a 2x count, it depends on the source). Practical example: with your 720 pixels horizontal resolution source, you input tile-columns=2 and threads=16 to the encoder. It accepts them without throwing errors back at you, but it will default to what it can actually use on your source: tile-columns=1 and threads~4 (assuming row-mt=1); the encoder simply can't "fit in" 16 threads working with a 720 width source.
    Code:
    horizontal resolution | superblock columns | horizontal tiles | tile-columns | rough thread count with row-mt=1
    0001-0448 | 001-007 | 01 | 0 | ~02
    0449-0960 | 008-015 | 02 | 1 | ~04
    0961-1984 | 016-031 | 04 | 2 | ~08
    1985-4032 | 032-063 | 08 | 3 | ~16
    4033-8128 | 064-127 | 16 | 4 | ~32
    3. Considering your current quality best, you don't really care about the encoding speed; however do keep in mind that quality good usually provides superior results (yes, really). As such, switching to quality good/cpu-used=0/auto-alt-ref=6 is advisable.
    4. FFmpeg's "output file is empty" notification is entirely expected, you are outputting the first pass to /dev/null.
    Thank you for the recommendations, will update my scripts!

    Re: quality = good - wow! the more I delve into VP9, the more I'm surprised who came up with all these quirks! Is there more info on why quality = good is better?

    Re: auto-alt-ref - Is there more info on what values 1 to 6 mean?

    Re: output file - The reason I ask is that ffmpeg VP9 wiki states - "In pass 1, output to a null file descriptor, not an actual file. (This will generate a logfile that ffmpeg needs for the second pass.)" https://trac.ffmpeg.org/wiki/Encode/VP9

    Few other questions
    • Do you have recommendations for aq-mode?
    • Any other recommendations on preventing the VP9 encoder from undershooting the target bitrate?

    Last edited by singhkays; 17th April 2019 at 07:45.
    singhkays is offline   Reply With Quote
    Old 17th April 2019, 12:22   #1159  |  Link
    Registered User
     
    Join Date: Nov 2007
    Posts: 49
    Quote:
    Originally Posted by singhkays View Post
    Re: output file - The reason I ask is that ffmpeg VP9 wiki states - "In pass 1, output to a null file descriptor, not an actual file. (This will generate a logfile that ffmpeg needs for the second pass.)" https://trac.ffmpeg.org/wiki/Encode/VP9
    If you are under Windows, you may have not noticed the following note on https://trac.ffmpeg.org/wiki/Encode/VP9 :
    Quote:
    Note: Windows users should use NUL instead of /dev/null
    Leeloo Mina?is offline   Reply With Quote
    Old 17th April 2019, 18:32   #1160  |  Link
    Registered User
     
    Join Date: Aug 2018
    Posts: 17
    Quote:
    Originally Posted by Leeloo Mina?/strong> View Post
    If you are under Windows, you may have not noticed the following note on https://trac.ffmpeg.org/wiki/Encode/VP9 :
    I did but I'm on Linux
    singhkays is offline   Reply With Quote
    Reply

    Tags
    google, ngov, vp8, vp9, vpx, webm


    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 09:19.


    Powered by vBulletin® Version 3.8.11
    Copyright ©2000 - 2019, vBulletin Solutions Inc.
  • 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • 龙船礼 有讲究 百岁龙 抖精神 2019-03-17
  • 新加坡航空将开通 全球最长商业航线 2019-03-17
  • 传说中的自由飞“翔” 当厕所被狂风吹上天 2019-03-12
  • 导游强迫交易获刑 曾辱骂威胁强迫游客消费上万元--旅游频道 2019-03-09
  • 北京正式推出租赁型职工集体宿舍 每间居住人数不超8人 2019-03-09
  • 美元短线拉升 随后回吐涨幅 2019-03-07
  • 天津时时彩走 北京pk10彩票官网 北京赛车在线计划 双色球中大奖记录 99彩票平台怎么样 pk10 22选5河南最新开奖 江西新时时彩论坛 p3试机号后分析 网易足彩 北京赛车怎么玩 福彩3d试机号开奖号综合走势图 安徽时时彩是真的吗 重庆时时彩软件 11选5决杀号公式 3d澳客网专家杀号