原创 研究了EXCEL的行高問題

  在EXCEL中,自選圖形的寬高,取決於格子的寬高。前幾天讀入一個文檔,因爲格子高度錯誤,導致圖形寬高錯誤。於是進行了一下研究: 格子的高度,取決於默認字體。 格子的寬度,取決於高度。   宋體情況下,格子高度基本正確;等線情況下,偏離

原创 FreeSwitch給會議室人員增加標識

命令如下: freeswitch@telecom> conference 3500 list 9;sofia/internal/[email protected];2b9fdbc4-d26d-4659-a643-1cc69adea0

原创 FFMPEG最簡解碼H264(NVIDIA硬解)

  關鍵:NVIDIA DECODER的結果是NV12,需要轉換爲YUV420P。 #include <stdio.h> #include <stdlib.h> extern "C" { #include <libavcodec/a

原创 曾經碰到一位不想幹活的專利律師,總是說“已經有了”

  以前在一公司,有一次公司想申請專利。於是頭目就找了一個律師,然後大家座談。神奇的事情出現了:面對專利點,這個律師反覆表示“這個已經有了”!讓吾等目瞪口呆。   事後聊天,都覺得不可思議。大哥你是來賺錢的,不要說你還沒有查有沒有同樣專利

原创 今天講解了WP的新思路

  吾以前做SS的計算系統的時候,也是從一個小破綻找到了突破口,進而建立了一整套完善的計算系統(僅次於EXCEL)。前一段時間研究了一下WORD,就明白了是怎麼做的。吾提出了兩點要使用新做法的原因。使用新做法,性能肯定有所提高,而提高幅度

原创 FFMpeg的avcodec_send_packet/avcodec_receive_frame是異步解碼

所以avcodec_receive_frame之後,要判斷AVFrame中是否有數據。 異步、同步各有好處。

原创 全網首發:FFMpeg使用NVIDIA DECODER,解碼後的數據是NV12,不是YUV420P

  在FreeSwitch順利啓用NVIDIA ENCODER之後(至少快10倍),下一步自然就是使用DECODER了。吾信心滿滿,結果是綠屏。嗯?怎麼回事? 從比例上來看,是解碼成功。 跟蹤代碼,也確實解碼成功。 既然是綠屏,應該是沒數

原创 FreeSwitch明明已經設置了H264,爲什麼通話時還是別的格式(如VP8)

檢查有哪些CODEC show codecs freeswitch@telecom> show codecs type,name,ikey codec,ADPCM (IMA),mod_spandsp codec,AMR / Band

原创 全網首發:FFMpeg使用NVIDIA DECODER,解碼後的數據轉換爲YUV420P

參考: https://blog.csdn.net/quantum7/article/details/107119487   我們日常所用格式雖然是RGB,視頻喜歡YUV420。如上文所述,解碼後的數據是NV12,如何轉換爲YUV420P

原创 軟件基本功:測試聽着簡單,會做的沒幾個

  寫專利時,不得不用WORD。作爲一個自視甚高的程序員,深以爲恥。經過一番雜事,這幾天終於有時間解決自選圖形的問題了。把代碼垃圾清理了一番,着手解決了連接線。包括:自選圖形的旋轉,翻轉,轉接線的位置、變形、連接點等問題。   正如上一文

原创 軟件基本功:開發測試中的窮舉歸納法

  最近研究了一下自選圖形的旋轉、翻轉,讀入兼容文檔時有問題。有時是對的,有時是錯的。怎麼辦?吾做了個文檔: 4個旋轉方向,0、90、180、270 橫向翻轉,左右、右左 豎向翻轉,上下、下上。 翻轉組合,橫向+豎向、橫向加橫向。   共

原创 FFMPEG編譯ffplay

關鍵就是要有SDL 安裝SDL(失敗) yum install -y SDL-devel 編譯SDL2(成功) https://blog.csdn.net/quantum7/article/details/104173159 編譯參數

原创 有的字體,用黑色渲染,效果是灰色

  昨天看到這個圖時,吾以爲是用了灰色繪製。有人研究認爲就是字體本身的問題。

原创 CentOS更改主機名

命令: hostnamectl set-hostname telecom  

原创 CENTOS安裝配置samba

比UBUNTU麻煩很多。 安裝samba yum install -y samba 允許WINDOWS訪問 /etc/sysconfig/selinux SELINUX=disabled 添加用戶 這個用戶是系統已有的用戶。 sm