자바로 어플리케이션을 개발하다가 웹을 사용하기 위해 Webview를 사용하게 되었는데 이 때 load하는 웹페이지의 css 속성 때문에 원치 않는 스크롤바가 생길때가 있다.

본인이 관리하는 싸이트라면 css를 수정하여 보다 깔끔하게 해결할 수 있지만 그렇지 않을 경우 어플리케이션쪽에서 제거해 주어야 한다.

이때 아래와 같은 방법으로 스크롤바를 제거 할 수 있다.


WebView wv = new WebView();

wv.getChildrenUnmodifiable().addListener(new ListChangeListener<Node>()

{

        @Override

        public void onChanged(Change<? extends Node> change)

        {

                Set<Node> deadSeaScrools = wv.lookupAll(".scroll-bar");

                for(Node scroll : deadSeaScrools)

                {

                        scroll.setVisible(false);

                }

        }

});

커널 부팅중 모듈을 insmod하다가 invalid module 이슈 발생

no symbol version for module_layout

insmod: can't insert '어쩌구저쩌구.ko': invalid module



1. 문제 원인

원인을 찾아보니 커널 버전과 모듈 버전이 맞지 않아 발생한다고 함


그래서 버전 확인해 보니

모듈 버전

$ modinfo 어쩌고저쩌고.ko      

vermagic:       4.1.20-1.2 SMP mod_unload modversions ARMv7 p2v8 


커널버전

$ uname -r

4.1.20-1.2

$ uname -a

Linux (humax-stb) 4.1.20-1.2 #6 SMP Wed Dec 21 17:49:54 KST 2016 armv7l GNU/Linux

얼핏 보면 같아 보이지만 사실 버전 뒷부분의 정보가 다르다.



2. 문제 해결

이럴 경우 kernel config를 수정하여 해결할 수 있다.

Automatically append version information to the version string 옵션을 꺼서 해결해 주면된다.


커널 config 수정하자!

$ make menuconfig


General setup 메뉴에서 Automatically append version information to the version string 항목 앞에 체크를 풀어 주자.


저장은 아래 Save로 저장 후 Exit로 나가면 된다.


수정 후 다시 빌드 하면 정상 동작하는 것을 확인할 수 있다.

아래 두 명령어 중 아무거나 사용해도 확인 가능합니다.


첫번째 것은 현재 디렉토리에서 1 depth에 있는 폴더들의 사이즈를 계산해 주는 명령이고,

 $ du -h --max-depth=1      


두번째 것은 현재 디렉토리에서 1 depth에 있는 파일, 폴더들의 사이즈를 계산해 주는 명령이다.

 $ du -sh *                        


compile은 *.c소스를 *.o파일로 변경하는 작업이다. 이때 각 *.c파일에 어떠한 함수가 있다라는 것을 단순 알려주기 위해 *.h파일이 필요하다
단순히 함수가 있다 정도만 알려 주기 때문에 컴파일시 이 *.h파일이 없을 경우에 어떤 함수가 정의 되지 않았다, 찾을 수 없다 등의 에러 메시지를 출력한다.

link의 경우는 이렇게 모인 *.o파일 들을 모아 주는 역할을 한다. 이때에 비로소 어떤 파일에서 사용하는 함수가 어떤 파일에 있다와 같이 참조(reference)하는 부분을 포함하게 된다. 그렇기 때문에 컴파일시 참조 하는 부분을 나타내는 헤더 파일을 include하고 참조하는 library의 위치를 옵션에 넣어줘야 문제 업이 컴파일이 가능하다. 만약 잘못 입려하거나 없을 경우 함수를 참조할 수 없다는 메시지를 출력한다.
library는 -L를 통해 해당 library의 폴더 위치를 넣고 -l를 통해 파일명을 넣어 준다.
-L를 해주지 않아도 컴파일러가 기본으로 찾아가는 순은 /usr/lib -> /lib -> /자기 폴더 순이다.

이렇게 묶인 link파일은 *.a나 *,so파일로 나뉜다. 둘은 목적에 따라 그때그때 다르게 사용한다.

*.a는 static library로서 정적 라이브러리에 해당한다. 정적 라이브러리의 목적은 빠른 접근(속도)에 있다. 하지만 처리속도를 높이기 위해 해당 라이브러리를 참조하는 모든 코드에 매칭되기 때문에 그만큼 용량을 많이 차지하게 된다.(라이브러리 용량이 호출하는 함수의 양만큼 증가) - 미리 빌드
*.so는 dynamic으로서 동적 라이브러리에 해당한다. 동적 라이브러리의 목적은 경량에 있다. 하지만 한번 빌드된 라이브러리의 위치를 각각 빌드시 명시되지 않고 사용시에 호출하여 쓰기 때문에 속도가 정적 라이브러리에 비해 떨어지는 단점이 있다. - runtime시 호출하여 사용
이는 시간과 공간의 반비례 그래프와 같다.


git에 commit를 하면 취소를 할 수 있지만 push를 하면 해당 push를 삭제할 순 없다.


삭제하기 위해서는 해당 git server의 branch를 모두 삭제 하고 다시 올려야 한다.


local에 git history가 남아 있기 때문에 지우고 다시 push하면 된다.


브렌치 삭제 방법

 
$ git push origin :heads/<branch_name>
 


브렌치 다시 추가

 
$git push origin <branch_name>
 


* 주의 : 신중히 진행하길 바라며, 문제 시 책임지지 않습니다.

서버를 만들 PC에 접속해서..

 
$ mkdir test_git_server.git
$ cd test_git_server.git
$ git init --bare
 


작업 PC 작업 폴더 안에서...

 
$ git init
$ git add *
$ git commit -m "First commit"
$ git remote add origin 서버아이디@서버주소:서버위치(test_git_server.git)
$ git push origin master
$ git branch --set-upstream master origin/master   <= (항상 최신으로 유지하기 위해 하는 설정)
 

다른 작업 PC에서...

 
$ git clone 서버아이디@서버주소:서버위치(test_git_server.git)
 

access unit

    재생하고자 하는 단위의 부호화된 형태(coded representation)


bitrate

    압축된 비트 스트림이 채널로부터 디코더의 입력단으로 전달되는 속도, 한비트에 많은 영상이 들어갈수록 고화질(단, 용량이 커짐)


coded representation

    부호화된 형태로 표현되는 데이터 항목


compression

    데이터 항목을 표현할 때 사용되는 비트 수를 줄이는 것


constant bitrate

    압축된 비트 스트림의 처음부터 마지막까지 비트율이 일정한 것


CSPS (constrained system parameter stream)

    제한 조건이 적용되는 프로그램 스트림


CRC (cyclic redundancy check)

    데이터가 틀리지 않았는가를 검증하기 위한 순회 중복 체크 부호


data element

    부호화 이전과 복호화 이후에 표현된대로의 데이터 항목


DTS (decoding time stamp)

    PES 패킷 헤더에 나타나는 필드로서 시스템 목표디코더(STD)에서 액세스 단위가 디코딩되는 시각을 나타냄


DSM (degital storage media)

    디지털 저장, 전송 기기, 또는 시스템


ECM (entitlement control message)

    조건부 수신(conditional access)을 위하여 부가적으로 추가하는 제어명령이나 기타 제어 정보


EMM (entitlement management message)

    조건부 수신을 위하여 부가적으로 특정 디코더의 허가 범위나 서비스의 형태를 나타내는 정보


elementary stream

    부호화된 비디오, 부호화된 오디오 또는 기타 부호화된 비트 스트림 중의 하나를 나타내는 일반적인 용어


ESCR (elementary stream clock reference)

    PES 스트림의 디코딩을 위한 디코더가 시간을 맞추기 위해서 쓰는 시간기준값


entropy coding

    정보의 중복도(redundancy)를 줄이기 위하여 디지털로 표현된 신호에 적용되는 비손실 가변 길이 부호화(variable length coding)


event

    공통의 시간기준값과 시작 시간, 끝나는 시간을 갖는 elementary stream들의 집합


forbidden

    "사용금지"란 용어가 부호화 비트 스트림을 정의하는 조항에 사용되면 그 값은 절대 사용되지 않아야 함을 의미


layer

    ISO/IEC 13818-1과 ISO/I C13818-2에서 정의되는 비디오와 시스템규격의 데이터 계층구조에 있는 단계의 하나


pack

    팩은 팩 헤더와 그 뒤에 딸린 하나 이상의 패킷으로 구성


packet

    패킷은 헤더와 그 뒤에 딸린 여러 개의 연속된 elementary stream의 바이트들로 구성


packet data

    패킷 내에 있는 elementary stream의 연속된 데이터 바이트들


PID (packet identifier)

    하나 또는 여러 개의 transport stream에서 한 프로그램에 관련된 elementary stream들을 나타내기 위하여 사용되는 고유 번호


padding[audio]

    오디오 프레임에 슬롯을 추가함으로서 오디오 프레임의 평균 길이를 해당 PCM 샘플 구간에 맞추는 방법


payload

    Packet의 header 뒤에 따라 오는 byte들(유료부하)


PES (Packetized Elementary Stream)


PES packet

    Elementary stream의 데이터들을 운반하기 위하여 사용되어지는 데이터 구조, PES packet header와 유료부하로 구성


PES packet header

    PES packet에서 PES packet data byte 부분을 제외한 앞부분


PES stream

    유료부하에 같은 종류의 elementary stream을 포함하고 stream_id가 모두 같은 PES packet의 열


PTS (presentation time stamp)

    Packet header에 나타나는 필드로서 재생단위(presentation unit)가 시스템 목표디코더(STD)에서 디스플레이되는 시간을 나타냄


presentation unit

    복호된 오디오 액세스 단위 또는 복호된 picture로써 재생단위를 나타냄


program

    Program element들의 집합. Program element는 elementary stream들이 될 수 있으며, 규정된 시간기준(time base)를 갖을 필요는 없지만 공통의 동기된 재현을 위한 시간 기준은 있어야 함


PCR (program clock reference)

    Decoder의 시간을 맞추기 위하여 시간 기준값으로 transport stream에서 전송됨


program element

    하나의 프로그램에 연관된 elementary stream들 또는 data stream들의 총칭


PSI (program specific information)

    Program이 어떻게 구성되어 있는지를 나타내는 것으로써 transport stream으로부터 프로그램을 성공적으로 재현하기 위해서 쓰이는 정보


random access

    임의의 위치에서 부호화된 비트 스트림을 읽고 디코딩을 시작하는 과정


reserced

    부호화 비트 스트림을 정의하는 구문에 사용되는 이 용어는 그 값이 장차 ISO/IEC에 의한 확장에 사용될 수 있다는 것을 의미. 특별한 규정에 없으면 모든 reserved bit는 1이 되어야 함


scrambling

    허가받지 않는 수신을 방지하기 위하여 비디오, 오디오, 또는 그 밖의 데이터의 순서를 바꾸는 것


source stream

    압축부호화 이전의 다중화되지 않은 샘플들의 단일 스트림


splicing

    시스템레벨에서 두 개의 서로 다른 두개의 elementary stream들을 접목시키는 일


start codes

    비트 스트림 상의 32비트 부호로서 신택스내의 계층의 존재를 확인해주는 것을 포함하여 몇 가지 목적으로 사용됨.


STD input buffer

    시스템 목표 복호기의 입력단에 있는 FIFO 버퍼로서 복호하기 전에 elementary stream을 저장하기 위한 것


still picture

    Intra coding된 하나의 picture, 이 picture는 자신의 PTS를 갖고 있으며, 뒤따라오는 picture들의 재생시간은 적어도 2장의 picture 이상 떨어져야 함


system header

    System header는 ISO/IE 13818-1에 정의되는 데이터 구조로서 ISO/IEC13818-1다중화 스트림의 시스템 특성이 요약되어 있는 정보를 전달함


SCR (system clock reference)

    디코더의 시간을 맞추기 위하여 쓰는 시간기준값으로 program stream에서 전송됨


STD (system target decoder)

    ISO/IEC 13818-1 다중화 비트 스트림의 의미(semantics)를 기술할 때 사용되는 디코딩과정의 가상적 모델 (목표 디코더)


time stamp

    사건이 발생하는 시각을 나타내는 용어


transport stream packet header

    Transport stream packet에서의 처음부터 continuity_counter 변수까지의 부분


variable bitrate

    압축 비트 스트림을 복호할 때 비트율이 시간에 따라서 변하는 것

시스템은 비디오와 오디오 파트에서 만든 elementary stream을 저장, 전송 하기 위해 패킷화 하는 과정

이 과정은 크게 두가지로 나뉨

program stream : 저장 매체에 저장하기 위한 용도

transport stream : 네트워크에서의 전송 또는 방송을 위한 용도


MPEG1 표준 : 저장매체를 목표로 하기 때문에 프로그램 스트림에 사용

MPEG2 표준 : 프로그램 스트림과 트랜스포트 스트림 모두 포함


시스템 코딩 : 압축된 오디오나 비디오 스트림뿐만 아니라 필요에 따라 사용자 데이터를 다중화하여 전송 또는 저장에 적합하도록 만드는 포장(data formatting)

다중화 : 복수개의 elementary stream을 하나의 단일 스트림으로 묶어 저장 또는 전송 등의 응용에 적합하도록 하는 방법을 제시

신택스 : 포장(data formatting)칙하는 규칙


시스템 코딩시 이와 같은 규칙(신택스 규정)에 따라 시스템 비트 스트림을 만들어야 하며, 시스템 디코더는 이 규칙으로 만들어진 스트림을 디코딩 할 수 있어야 함


시스템 인코더는 다음 5가지 동작을 효율적으로 수행 할 수 있는 방법을 제공

- 동기화 : 복수개의 elementary stream도 디코딩 시 각 elementary stream 디코더 상호간의 동기를 맞추어 재생 가능 하도록 함

- 다중화 : 복수개의 elementary stream을 하나으 디나일 스트림으로 묶어 저장, 전송 할 수 있게 함

- 버퍼 초기화 : 디코딩 초기 동작 시 버퍼의 초기 동작 레벨을 맞추어 줌

- 버퍼 관리 : elementary stream 디코더의 버퍼 레벨제어를 효율적으로 수행하도록 하여 디코더 단의 모든 버퍼에서 underflow나 overflow가 발생하지 않도록 함

- 시간규정 : 각 elementarry stream 이나 프로그램마다 시간을 나타내는 값을 삽입하여 효율적으로 재생할 수 있도록 함


패킷 : 보통 header와 유료부하(payload)로 이루어짐


elementary stream이 패킷화(packetizing)된 것을 PES(packetized elementary stream) patket이라 함

이 과정에서 유료부하 부분에는 스트림이 일정한 길이로 잘려서 삽입되며, header에는 시간정보, 주소, 꼬리표 등 유용한 정보가 들어감


인코딩 : 압축된 오디오, 비디오 스트림들을 묶어 결합 + 디코딩 과정에서 디코딩 된 스트림들의 동기를 맞추어 재생하기 위한 변수들

인코딩의 2가지 형태

- TS : transport stream(전송 목적)

- PS : program stream(저장 목적)


TS : 일련의 TS packet으로 구성되는데 TS packet들은 각각의 길이가 188byte로 일정(전송 시 에러가 날수도 있어 형식을 정함)함

PS : 일련의 pack으로 구성되는데 전송 에러가 거으 이벗는 저장매체에 사용. 때문에 압축 또는 복원등에 적합한 방식. 인코딩시 추가된 시간정보와 디코더단의 클럭제어 과정을 통해 동기를 맞춤. 또한 디코딩 시 버퍼 제어도 적절히 수행되어 버퍼의 underflow나 overflow를 방지


TS stream과 PS stream간으 시아호 변환은 PES packet의 형태로 수행. PS/TS packet의 header부분에는 스트림간의 상호변환시 필요한 정보나 표 등이 있음.


TS, PS stream 비교 : TS packet의 길이는 항상 188byte로 동일한 반면, PS stream은 일련의 pack으로 구성되는데 pack의 길이가 가변적이고 보통 TS packet의 길이보다 훨씬 김.

TS packet의 장점 : Packet의 길이가 동일하면서 짧기 때문에 다중화(multiplexing), 재다중화(re-multiplexing) 및 역다중화(demultiplexing) 또는 수신기 제작 등에 있어서 용이하고 ATM에서 셀의 분실(cell loss)와 같은 전송 오차시의 손실이 적음


TS packet(188byte)은 4개의 ATM cell(53byte)로 변환

ATM cell(53byte)중 5byte의 head와 1byte AAL(ATM Adaptation Layer) 사용 후 남은 47byte를 유료부하로 사용


PS stream의 경우에는 pack header와 pack으로 구성

pack은 여러 개의 PES packet으로 구성

Pack의 유료부하에는 PES packet의 형태가 유지되므로 소프트웨어를 이용한 스트림의 처리에 적합

MPEG1의 system multiplex/demultiplex방식을 이용하는 시스템과 호환성이 있음


PES packet : header와 유료부하로 구성

header에는 유료 부하에 있는 데이터 특성 및 전체 스트림을 구성하는 모든 정보가 있기 때문에 header만을 이용하여 다른 스트림의 변환이나 재다중화동작등을 능률적으로 수행함


PES packerizer : Elementary stream을 입력받아 TS/PS stream의 구성에 맞추어 적절히 PES header 생성 후 header의 내용과 부합하도록 유료부하 구성하여 packet을 생성하는 과정(video와 audio로 나뉨)


PSI(프로그램 구성정보)는 4개의 테이블로 구성 됨

- PAT(Program Association Table) : 프로그램을 구성하고 있는 program element들에 관한 정보

- PMT(Program Map Table) : 프로그램을 구성하고 있는 program element들에 관한 정보

- NIT(Network Information Table) : 전송네트워크에 대한 규정값들

- CAT(Conditional Access Table) : 조건부 수신이 필요한 경우 스크램블링 혹은 사적인 스트림(private stream)에 관한 것

오늘 아는 동생네 사이트에 갑자기 사진 등록이 안된다고 도와 달라는 연락을 받았다.

실제 관리자 페이지에 들어가서 사진을 등록해 보니 전부 엑박으로 나오는게 아닌가..


혹시 호스팅 용량이 가득차서 업로드가 안되는건 아닌지 cafe24 사이트에 들어가서 확인해 보니 역시나 호스팅 용량 3기가를 모두 사용하고 있었다.


그래서 파일이 얼마나 많이 업로드 되었는지 FTP에 접속하여 확인을 해 보았는데... 몇개 되지 않았을 뿐더러 1기가도 채 되지 않았다.


혹시나 하여 그 동안 운영중에 쌓인 tomcat log가 원인이 아닐까 하여 


/tomcat/logs/ 안의 catalina.out 파일을 확인해 보니 역시나.. 3기가 가까이 로그가 쌓여 있었다.


자 이제 그럼 어떻게 할 것인가... 한번 알아 보자!


1. 우선 작업전 tomcat server를 내려 준다. (./shutdown.sh)

2. logs폴더 아래의 catalina.out 파일을 삭제한다.

3. catalina.sh 파일을 열어 아래 스크립트를 찾아 주석처리 한다(tomcat 버전에 따라 약간 차이가 있을 수는 있습니다.)

 
# >> "$CATALINA_OUT" 2>&1 "&" 
 

4. 저장 후 서버를 올려 준다.(./startup.sh)


자바개발을 하다 C를 해보려 하니 포인터 개념이 생겨 생각에 정리를 할겸 혼자 되뇌이며 몇자 적어 본다.


int a, b가 있는데 값을 대입하기 위해선 a = b 이렇게 하면된다

그런데 이말인 즉 *&a = *&b 란 뜻이다

&는 주소연산자이며 포인터를 뜻하고 &a하면 int형 변수 a를 가르키는 포인터이다

한마디로 a가 어디있는지 주소를 나타내는 것이다.

*는 참조연산자로서 기억공간을 사용하기 위해 사용되고 &앞에 *& 이렇게 붙이면 당연히 &가 가르키는 주소의 값을 *이걸로 가져다 쓰겠다는 의미이다.


다시 말해서 *&a는 int형 a의 주소에 있는 값을 가져온다는 의미이다.(포인터에 참조연산자를 사용하면 포인터가 가리키는 기억공간의 저장된 값을 사용할 수 있다.)


따라서, a = *&b로도 사용할 수 있다는 말이다.


그렇다면 이러한 &(주소연산자)를 저장할 순없을까?

일반적으로 선언된 int a 와같은 변수에는 값을 저장하는 것이지 주소를 저장할 수는 없다.

하지만 참조 연산자로 변수를 선언하게 되면 이러한 주소 값을 저장할 수 있다.


int *a (포인터변수 선언) 이렇게 말이다.

저장 방법은 int a, *b;  a=10; *b=&a;  이렇게 하면된다.


포인터는 포인터가 가르키는 자료형의 크기와 관계없이 모두 4바이트이다. 따라서 포인터변수의 크기도 모두 4바이트이다.(근데 컴파일러에 따라 달라질 수 있음)

하지만 이렇게 크기가 같다고 해도 형변환이 되는것은 아니다. int형 포인터 변수에 저장된 주소를 double형 포인터 변수에 저장 못함

하지만 강제 형변환은 됨

int *ip;

double db=6.5;

ip = &db; <--하면 에러가 나지만

ip = (int *) &db <-- 이렇게 강제 형변환 하면 문제 없음


정리하자면 포인터는 주소값을 의미함 즉, 상수인 것이고

포인터 변수는 하나의 기억공간이며 번듯한 이름이 있는 변수인 거다.

포인터와 포인터 변수는 모두 특정 기억공간을 가리키는 역할을 하므로 두 가지 모두 참조 연산자를 사용하면 그들이 가리키는 기억 공간을 참조할 수 있다!

그러나 분명한 차이점은 포인터는 상수이므로 가리키는 대상을 결코 바꿀 수 없고, 포인터변수는 다른 주소값을 저장하면 얼마든지 가리키는 대상을 바꿀 수 있다.

+ Recent posts