Rtsp memo

Term

1
2
3
CC: CSRC Counter
CSRC: Contributing Source
SSRC: Synchronization Source

Sdp example

v=0
o=- 17618512456233465749 1 IN IP4 127.0.0.1
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=control:*
a=range:npt=0-
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:3000
a=rtpmap:96 H264/90000
a=framerate:30
a=fmtp:96 packetization-mode=1;sprop-parameter-sets=J2QAFKwrYKD9gIgAAAMACAAAAwHnQgAW4gAC3G173wdocKuA,KO48sA==;profile-level-id=640014;level-asymmetry-allowed=1
a=control:stream=0
a=ts-refclk:local
a=mediaclk:sender
a=ssrc:4060724388 cname:user1571168269@host-d3352119

refer to:
https://www.rfc-editor.org/rfc/rfc3550
https://www.rfc-editor.org/rfc/rfc3551
https://www.rfc-editor.org/rfc/rfc2326
https://www.rfc-editor.org/rfc/rfc4588
https://www.rfc-editor.org/rfc/rfc7273
https://blog.csdn.net/weixin_42462202/article/details/98986535
https://github.com/fanxiushu/xdisp_virt
https://www.cnblogs.com/tingweichen/p/14881639.html

onnx relocation R_X86_64_TPOFF32 against hidden symbol

1
2
3
export CMAKE_ARGS="-DONNX_USE_PROTOBUF_SHARED_LIBS=ON"
apt-get install libprotobuf-dev protobuf-compiler
pip install onnx -i https://pypi.tuna.tsinghua.edu.cn/simple

MacOs 3d presentation in VMWare

Although VMWare can't support hardware accelerated 3d rendering for macos, I happened to see Garageband running in my old laptop, it indicates 'macOS Catalina (Version 10.15.4)' supports middle layer OpenGL software simulation, while up-to-date macOS deviates from this style.

Speed up pip install

1
2
3
4
5
6
7
python3 -m pip install opencv-python==4.5.3.56 -i https://pypi.tuna.tsinghua.edu.cn/simple
 
http://mirrors.aliyun.com/pypi/simple/ 
https://pypi.mirrors.ustc.edu.cn/simple/ 
https://pypi.douban.com/simple/ 
https://pypi.tuna.tsinghua.edu.cn/simple/ 
http://pypi.mirrors.ustc.edu.cn/simple/

refer to:
https://www.cnblogs.com/huangguifeng/p/12002049.html

Rendering mp4 video not silky, why?

The original HD mp4 file 'movie.mp4' plays very smoothly. I picked out the h264 stream saved as 'movie.264' from it, then using mp4v2 converted 'movie.264' to a new mp4 file 'output.mp4'. However, experience of watching 'output.mp4' was very bad. Why?

I debugged the 'ClipTrack' function in 'mp4v2/test/OLD/mp4clip.cpp', found a key argument 'renderingOffset' of function 'MP4WriteSample'. All examples searched from the web about writing h264 to mp4 through mp4v2 set 'renderingOffset' to 0, while in 'ClipTrack', 'renderingOffset' of function 'MP4WriteSample' is directly set to the value from 'renderingOffset' of function 'MP4ReadSample'.

Here we make a concept clear, the 'sample' entity in mp4 file format specification is equal to a frame which can completely rendering as a picture. A sample consists of several nalus, a nalu whose start code is 0x00, 0x00, 0x00, 0x01 indicates a new sample, while a nalu which starts with 0x00, 0x00, 0x01 is among a sample, and a sample needs not to be a IDR key frame.

Through carrying 'renderingOffset' value at beginning of each sample in 'movie.264', I did generate an 'output.mp4' which displays as smoothly as the original one.

Did 'renderingOffset' mean time stamp of a sample? No, at least not exactly. By watching log, I found its value was not increasing as time went by.

I continued debugging mp4v2, then saw a key word 'ctts' atom, and searched a link from the web,

https://blog.csdn.net/cheyo809775692/article/details/100924523

I now understand, the decoding order of h264 samples is slightly different from the rendering order of them.

For example, in stts atom,

1
2
3
4
5
'decoding order'	'sample count'		'sample duration'
1,2,3,4			4			20
5			1			40
6,7,8			3			20
9			1			60

in ctts atom,

1
2
3
4
5
6
7
8
'decoding order'	'sample count'		'sample offset'
1,2,3			3			20
4			1			40
5			1			0
6			1			40
7			1			0
8			1			40
9			1			0

final rendering timing is

1
2
3
'decoding order'	1	2	3	4	5	6	7	8	9
'duration'		20	20	20	20	40	20	20	20	60
'rending order'			1	2	3	5	5,4	7	6	9	9,8	9

Terms

1
2
3
4
5
6
7
8
9
10
11
12
mvhd: movie header
tkhd: track header
mdhd: media header
stsd: sample descriptions
stts: time to sample
ctts: composition offset
stss: sync sample offset
stsc: sample to chunk
stsz: sample size
stco/stco64: chunk offset
dts: decoding timestamp
pts: presentation timestamp

expect scp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
auto_scp()
{
	local filepath=$1
	expect -c "
		set timeout 10
 
		spawn scp scp://someone@192.168.12.3:1234//home/someone/$filepath .
 
		expect \"password:\" 
		send \"toodangerous\r\"
 
		interact
	"
}

refer to:
https://blog.csdn.net/f_zyj/article/details/93475830
https://zhuanlan.zhihu.com/p/25164676

Select Windows SDK version when building using cmake

Read cmake online doc carefully, https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html

So when we build project which has CMakeLists.txt, we can select Windows SDK version in this way:

  1. In explorer, navigate to like C:\Program Files (x86)\Windows Kits\10\Include.
  2. For cmake always finds the newest version to build our project, we can just rename all sdk versions which is newer than we want. e.g. if we want 10.0.19041.0 to build our project, but 10.0.22581.0 is newer, we rename 10.0.22581.0 to 10.0.0.22581.0, the rule is among tokens split by period signs, the third token number is the key word that cmake sorts them to get the largest as newest.
  3. Start cmake to configure the project, it will find the right sdk version.
  4. After cmake is done in configuration, rename 10.0.0.22581.0 back to 10.0.22581.0.