구차니의 잡동사니 모음

• Coded slice (regular VCL data),

• Coded data partition A, B, C (DPA, DPB, DPC),

• Instantaneous decoder refresh (IDR),

• Supplemental enhancement information (SEI),

• Sequence and picture parameter set (SPS, PPS),

• Picture delimiter (PD) and filler data (FD).

[링크 : http://iphome.hhi.de/wiegand/assets/pdfs/DIC_H264_07.pdf]

[링크 : http://stackoverflow.com/questions/12320604/embedding-metadata-to-h-264-encoded-file]

[링크 : http://egloos.zum.com/yajino/v/782492]

[링크 : http://mmlab.knu.ac.kr/Lecture/hci/multi_2008_2/H.264_AVC_2008_7.pdf]

SODB (String Of Data Bits)

RBSP (Raw Byte Sequence Payload)

NAL(Netwrok Abstract Layer)

[링크 : https://codesequoia.wordpress.com/2009/10/18/h-264-stream-structure/]

[링크 : http://vaplab.ee.ncu.edu.tw/~mktsai/data/h264_introduction.ppt]

format pdf

[링크 : http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200305-S!!PDF-E&type=items]

[링크 : http://mmlab.knu.ac.kr/Lecture/hci/multi_2008_2/H.264_AVC_2008_4.pdf]

[링크 : http://iphome.hhi.de/wiegand/assets/pdfs/DIC_H264_07.pdf]

raid5가 의외로 고자라니... ㄷㄷㄷ

raid5는 N-1의 공간 효율을 가지는데

CRC 하나라서 동시 디스크 2개 이상의 손상에 대해서는 복구할 방법이 없다.

그런데 정작 필드에서 복구율을 보면 raid 라고 하기 처참한 상황

아래 그래프가 맞자면 raid0이랑 별반 다름없는 상황인데

하드가 3년 정도 주기로 서버에서는 교체할테니 고장률 35%대..

[링크 : http://linux.krauss.kr/doku.php/raid_신뢰성_고찰]

아무튼 이런 이유로 대세는 raid6 라고..

음.. 대충 이해한걸로는

하드 데이터 복구랑 비슷한 기분?

파일이 삭제 되거나 수정하면

다른 inode에 저장/삭제를 할 텐데

file system 레벨에서

그걸 삭제한게 아니라 version history 관리하듯

촤르륵 목록으로 냅두고 실제로 삭제하지 않음으로서

inode 목록만 저장(snapshot) 해두고

그걸로 이전의 시간대로 복구하는 개념..

CoW(Copy on Write) 는 스냅샷을 구현하는 방법론이 되려나?

[링크 : http://hybridstoragekorea.blogspot.com/2013/10/blog-post_4204.html]

[링크 : http://searchdatabackup.techtarget.com/...snapshot-technologies-for-data-protection]

고민을 해보니.. SSD에서는 구현 못하는거 아냐? inode가 붕뜨면 삭제처리 할텐데?(Trim)

했는데.. fs 레벨에서 inode 삭제가 아니라 삭제된 inode로 다른 테이블에서 실 데이터로 관리해주면

trim에 의해서 삭제 되지 않을테니 문제 없음! 이 될 것 같고

하드 공간이 넉넉하지 않으면 엄청난 성능 저하 및

snapshot으로 복구 할 가능성이나 시간대역이 짧아질 문제가 있을 것으로 보인다.

만약.. 4T 하드에 3T 내용이 있고

그 내용 전부를 크립토락커로 당했다면.. 전부 복구가 불가능 해질 가능성도 존재할 것으로 생각이 된다...

(아니면 말고..)

한마디로.. 삭제 된 파일도 실제 FS 상에서는 .remove 식으로 관리해둔다고 보면 될 듯?(리눅스 기준)

+

저널링은 갑작스런 전원 중단으로 인한 불일치를 복구하는데 유리한 시스템이고

(commit이 완료되면 엎어씀)

스냅샷은 엎어쓰지 않아서 정전과 상관없는 백업을 유리하게 하는 시스템..

Versioning file systems should not be confused with journaling file systems. Whereas journaling file systems work by keeping a log of the changes made to a file before committing those changes to that file system (and overwriting the prior version), a versioning file system keeps previous copies of a file when saving new changes. The two features serve different purposes and are not mutually exclusive.

[링크 : https://en.wikipedia.org/wiki/Versioning_file_system]

예전 멀티프로세서 환경에서의 세마포어 등을 공부할때(OS 수업)

들은거 같은데 기억이 안나서 뒤적이다가 겨우 찾았네..

왜 쓸데없는(?!) TLB랑 용어를 헷갈린거지?

[링크 : https://en.wikipedia.org/wiki/Test-and-set]

정확도 면에서는 NTP 만큼의 정확도를 요구하지 않는 표준안

PTP > NTP > SNTP 순일려나?

[링크 : https://www.meinbergglobal.com/english/faq/faq_37.htm]

[링크 : https://www.meinbergglobal.com/english/glossary/sntp.htm]

[링크 : http://www.rfc-base.org/txt/rfc-2030.txt]

[링크 : https://en.wikipedia.org/wiki/Network_Time_Protocol#SNTP]

MMIO 반대말이 안떠올라서 저장 ㅋ

Memory-mapped I/O (not to be confused with memory-mapped file I/O) uses the same address bus to address both memory and I/O devices – the memory and registers of the I/O devices are mapped to (associated with) address values. So when an address is accessed by the CPU, it may refer to a portion of physical RAM, but it can also refer to memory of the I/O device. Thus, the CPU instructions used to access the memory can also be used for accessing devices. Each I/O device monitors the CPU's address bus and responds to any CPU access of an address assigned to that device, connecting the data bus to the desired device's hardware register. To accommodate the I/O devices, areas of the addresses used by the CPU must be reserved for I/O and must not be available for normal physical memory. The reservation might be temporary, such as with the Commodore 64 that does bank switching between its I/O devices and regular memory, or permanent.

Port-mapped I/O often uses a special class of CPU instructions designed specifically for performing I/O, such as the in and out instructions found on microprocessors based on the x86 and x86-64 architectures. Different forms of these two instructions can copy one, two or four bytes (outb, outw and outl, respectively) between the EAX register or one of that register's subdivisions on the CPU and a specified I/O port which is assigned to an I/O device. I/O devices have a separate address space from general memory, either accomplished by an extra "I/O" pin on the CPU's physical interface, or an entire bus dedicated to I/O. Because the address space for I/O is isolated from that for main memory, this is sometimes referred to as isolated I/O.

[링크 : https://en.wikipedia.org/wiki/Memory-mapped_I/O]

쓸일이 있을진 모르겠다 -_-a

[링크 : https://users.cs.jmu.edu/buchhofp/forensics/formats/pkzip.html]

wear leveling에는 여러단계가 있는데..

찾아는 봐야 할 듯?

그리고 wear는 닳다, 닳음 정도로 해석하면 균등 닳기 라고 하면 되려나? (어?)

none wear-leveling 일반적인 HDD가 쓰는 방식으로 물리 주소에 수정할 내용을 바로바로 같은 위치에 쓰고

dynamic wear-leveling 비어있는 셀에 만 돌아가면서 쓰고

advanced wear-leveling hot cell을 static cell과 바꾸어서 균등하게 돌려가는 방식

static (or global) wear-leveling 데이터가 있는 부분까지 돌려가면서 쓰는방식

음.. advanced와 static의 설명이 모호한 기분인데..

advanced는 hot cell(빈번하게 데이터가 바뀌는 셀, 그렇다면 MRU 를 관리한다는 의미?)이 발생하면

static cell과 가끔 교체해서 전반적으로 노후율을 비슷하게 유지하는 것이고

static의 경우 전체적인 write count를 비교하여 static 이던 hot이던 상관없이 조금이라도 낮은 것과 교체하는 것이다.

이론적으로야 static/global이 가장 균등하게 소모하고

write count로 하므로 초반부터 균등하게 사용해 들어가는 장점이 있을 것으로 보여진다.

아무튼 wear-leveling은 SLC MLC TLC로 오면서

cell 별 보장하는 write 횟수가 기하급수 적으로 떨어짐으로 인해 더더욱 중요도가 올라가고 있으며

용량이 엄청나게 커질수록 이론상 셀의 수명이 기하급수적으로 늘어나기에

나중에 테라급이 보편화 되면 수명이라는걸 논할 가치도 없어 질지도 모르겠다.

[링크 : http://en.wikipedia.org/wiki/Wear_leveling]

[링크 : http://kr.apacer.com/business/technology/wear-leveling/]

[링크 : http://ap.apacer.com/business/technology/wear-leveling/]

[링크 : http://en.wikipedia.org/wiki/Write_amplification]

IrDA는 FIR / SIR / CIR 모드로 작동이 가능한데

CIR 모드는 지원할 수도 있고 아닐수도 있다고 한다.

일반적인 리모컨은 CIR 모드를 지원해야 하고

그게 아니라면 38k * 3 = 114kbps < 115200bps

로 SIR 모드를 지원하는 경우 UART모드로 해서 읽으면 3비트를 하나의 데이터로 해서 읽어 오면

약간의 오류가 있을순 있지만 인식이 가능한 수준이 되는 것으로 보인다.

FIR은 SIR을 지원해야 가능한 것처럼 보이긴 한데..

IrDA 스펙상 SIR 과 FIR이 OSI 1계층으로 따로 있는거 보면..

연관이 없는건 아니지만 그래도 필요충분 조건은 아닌 느낌?

[링크 : http://irdajp.info/specifications.html]

MPEG4 오디오는 크게 AAC-LC와 HE-AAC로 나누어 진다.

확장자나 상품명 content type으로 치면

AAC-LC는 aac로

HE-AAC v1은 aacplus / aacp / aac+

HE-AAC v2는 eAAC+ / enhanced aacPlus / aacPlus v2

이런식으로 갈리는 것으로 보여진다.

VLC에서 확인하면

HE-AAC는 

AAC 확장: SBR 이라는 항목이 추가되어 출력된다.

Low Complexity AAC (AAC LC)

High-Efficiency Advanced Audio Coding (HE-AAC)

    HE-AAC v1 - SBR = aacplus / AAC+ / aacp(?)

    HE-AAC v2 - SBR + PS = Enhanced aacPlus

[링크 : http://en.wikipedia.org/wiki/High-Efficiency_Advanced_Audio_Coding]

nero 인코더/디코더를 보면

기본적으로 quality로 설정해서 압축하면 VBR 이며

0.25 quality 정도면(25%) 66kbps 에서

VBR로 대략 40kbps~56kbps 사이에서 데이터가 실제 전송양이 측정될 것으로 예상된다.

[링크 : http://www.nero.com/enu/company/about-nero/nero-aac-codec.php] nero non-commercial

[링크 : http://wiki.multimedia.cx/index.php?title=AAC_Reference_Software#mp4mcDec] official codec