Comparing HLS and MPEG-DASH


After two years of HLS streaming, I still don’t see significant advantages on MPEG-DASH.
1. Standard: HLS made it’s way to rfc8216. in 2017.
2. Live subtitles: HLS can not only do VOD, but live streams too.
3. HLS made effort by providing HLS fMP4 so that streaming servers don’t have to provide duplicated copies of media file (.ts and .m4s) in order to satisfy both DASH and HLS clients.

Advertisements

Literally, what does YUV420 mean?


We know what YUV420 is, but literally what does the 0 mean?

In short, 0 means 0 uv values are sampled in the second row.

Details:

4: for each 4 pixels in each row

2: 2 uv samples on first row.

0: 0 rv samples on second row: reusing uv samples on first row.

Therefore, for YUV422, second 2 means second row is sampled the same way as the first row.

Why am I not allowed to send the DRM key to video player?


I don’t know exactly, and I am still thinking.

This is the current DRM flow: I, as the content provider, use a key to encrypt my video, and send to player, e.g. JW Player. I send the key to Third Party DRM Provider, e.g. DRMToday, and DRMToday sends the key to JW Player.

I cannot send my key to JW Player unless I have a contract with DRM OEM, e.g. Google WideVine. Why is a contract required? I think it is related to the fact that DRM is never open source; it’s security-by-obscurity. The contract would say: WideVine provides SDK to DRMToday to obscure the key, and DRMToday promises to keep obscuring process a secret. Otherwise, unauthorized party may get the key in clear text and therefore decrypt the video and defeat the DRM.

Sync video from multiple IP cameras


When live streaming the same hockey game with two RTSP H.264 cameras, can the two video streams play in sync?

No wall clock in this setup; both cameras are standalone.

I think Yes, in theory.

We expect the clocks on the two cameras accurate enough. (frequent NTP helps)

The two RTCP servers on the cameras map the RTP time stamps to UTC time.

PTS can be calculated from RTP time stamp.

By RTP and RTCP, we have the PTS in UTC, and therefore, sync the two videos.

Problem: packages from RTCP may not inaccurate/missing in reality.

References:

1: https://stackoverflow.com/questions/2439096/h264-rtp-timestamp

[“Non interleaved”, in which, you must set the RTP timestamp to the PTS + offset]

2: https://groups.google.com/forum/#!msg/discuss-webrtc/npLmOesI8A4/oL2p_HbhAgAJ

[synchronization between two RTP streams using RTCP SR]