Làm nghiên cứu như thế nào (Phần 2)

Phần Introduction là phần mở đầu của một bài báo, và thường bao gồm 3 phần chính:

1. Giới thiệu tổng quan bối cảnh của nghiên cứu (context)

2. Giới thiệu vấn đề bài báo sẽ giải quyết (problem)

3. Giới thiệu tổng quan về phương pháp bài báo đề xuất (solution) 

***********************************************************************************

1. Giới thiệu tổng quan bối cảnh của nghiên cứu (context)

Ở phần đầu tiên (context), mục đích là giúp người đọc nắm được các thông tin cơ bản về đề tài nghiên cứu (topics) của bài báo. Ví dụ khi đề tài nghiên cứu là "Viewport Adaptive Streaming for 360 Video", thì phần context phải cung cấp được thông tin về 1) 360 Video và 2) Viewport Adaptive Streaming. Đây là đoạn viết về 360 Video:

360-degree video (360 video for short) is the main content type in Virtual Reality [1], being used in a wide range of applications such as VR sport, VR games [2]. 360 video has a much higher resolution and frame rate than conventional flat video. For example, to offer true immersion to the user, 360 video is expected to have a resolution of 24K and a frame rate of 60fps [3]. As a result, 360 video requires high bandwidth when streaming over networks.

Ở đây, đầu tiên mình bắt đầu bằng việc giới thiệu 360 video là một loại nội dung chính trong hệ thống thực tế ảo (Virtual Reality) cũng như các ứng dụng của nó. Sau đó, mình tập trung vào giới thiệu các sự khác biêt của 360 video so với video thông thường: độ phân giải và frame rate rất lớn. Một cách hiệu quả để giúp người đọc dễ hình dung là đưa ra các con số cụ thể như ở câu số 3. Cuối cùng, mình đề cập đến hệ quả của chúng lên tốc độ đường truyền cần thiết cho loại video này. Câu cuối cùng này là tiền đề để giới thiệu về "Viewport Adaptive Streaming" ở đoạn tiếp theo. Đây là một cách mình thường dùng để tạo kết nối giữa các đoạn trong bài báo.

To reduce the bandwidth required for 360 video streaming, Viewport Adaptive Streaming (VAS) has been proposed. The basic idea is to deliver the viewport (i.e., video part visible to the user) at a high bitrate (quality) while delivering the other parts at a lower bitrate (quality) [4]. In the literature, Viewport Adaptive Streaming is usually implemented using the so-called tiling-based approach [4], [5]. In tiling-based VAS, a 360 video is spatially divided into multiple parts called tiles. Each tile is independently encoded into multiple versions of different bitrates (quality levels). Tiles overlapping (non-overlapping) the viewport are delivered at high (low) bitrate.

Ở phần giới thiệu về Viewport Adaptive Streaming, đầu tiên mình giới thiệu về mục đích của công nghệ này theo cấu trúc: 

To ..., Viewport Adaptive Streaming has been proposed.

Tiếp theo, ý tưởng cơ bản của công nghệ này được giới thiệu bằng cấu trúc:

The basic idea is to .....

Ở đây tốt nhất là bạn nên viết trong 2,3 câu ngắn ngọn. Theo sau bởi một phần mô tả ở mức độ chi tiết hơn, trong ví dụ này là về tile-based approach. 

Khi mô tả về các khái niệm và cách thức liên quan đến một công nghệ, việc sử dụng các trợ từ (adverb) cho các động từ là rất cần thiết. Ví dụ, khi nói "360 video được chia thành nhiều phần gọi là tiles", thì động từ chia "divide" phải được đi kèm bời trạng từ "spatially" để chỉ rõ việc chia ở đây là theo miền không gian. Nếu không, người đọc có thể nhầm lẫn với việc chia video theo miền thời gian thành các segments. Tương tự với câu tiếp theo khi đề cập đến việc nén các tiles thành nhiều versions. Việc sử dụng trạng từ "independently" ở đây để chỉ rõ rằng, việc nén được thực hiện sau khi chia video thành các tiles, và được tiến hành độc lập với nhau. Câu cuối cùng của đoạn này mình áp dụng một cấu trúc hay dùng khi mô tả một hành động tác động lên hai thành phần khác nhau của hệ thống theo hai cách khác nhau. Trong trường hợp này, thay vì viết hai câu đơn lẻ, mình sẽ kết hợp thành một câu theo câu trúc.

A(B) is ... at A*(B*)

dấu ... là động từ chỉ hành động tác động lên  thành phần A và B. A* và B* là cách thức tác động.

2. Giới thiệu vấn đề bài báo sẽ giải quyết (problem)

Trong phần này, bạn cần mô tả được một cách rõ ràng câu hỏi (vấn đề) mà báo báo giải quyết. Ở trong bài báo này, vấn đề ở đây là "trade-off between viewport adaptivity and bitrate adaptivity". Thông thường sẽ có hai cách viết: một cách là đưa ra vấn đề trước sau đó giải thích, hai là đưa ra các dẫn chứng sau đó mới đưa ra vấn đề. Đây là một ví dụ:

Since the user tends to change his/her viewing direction when watching a 360 video, the viewport is usually varying during a streaming session [6]. Hence, adaptation methods for VAS should be able to adapt the tiles’ bitrates according to the time-varying viewport. In addition, the throughput in mobile networks may fluctuate significantly over time. Significant reductions in network throughput can lead to playback interruptions [7], which can greatly reduce the user viewing experience [8]. Hence, adaptation methods for VAS must also adapt the tiles’ bitrates according to the time-varying network throughput. To provide smooth playback under varying network conditions, the client should buffer some amount of video data before the playback of the video begins [7]. However, large buffer sizes can severely reduce the performances of VAS methods, as shown in [9]. Thus, there exists a trade-off between network adaptivity and viewport adaptivity in viewport adaptive streaming.

Trong đoạn này, tác giả sử dụng cách thứ hai. Đầu tiên, khái niệm về viewport adaptability được giải thích:

Since..., viewport is usually varying .... Hence, adaptations methods for VAS should be able to ...

Ở đây, tác giả giả thích bằng việc đưa ra một đặc trưng của người dùng khi xem video 360, đó là việc thay đổi góc nhìn liên tục, dẫn đến việc viewport thay đổi. Để đảm bảo tính khoa học cho bài báo, bạn phải đưa ra dẫn chứng để chứng minh tính đúng đắn của các câu trong bài bằng việc cite các tài liệu khoa học khác (bài báo, sách, technical report, vv.) ở cuối câu. Tương tự, sự cần thiết của network adaptivity được giải thích từ việc băng thông của mạng thay đổi liên tục theo thời gian. Cuối cùng, vấn đề chính của bài báo (trade-off between viewport adaptivity and bitrate adaptivity) được phân tích thông qua tác động của một biến trung gian là buffer.

3. Giới thiệu tổng quan về phương pháp bài báo đề xuất (solution) 

Phần này cần giới thiệu được 1) các điểm quan trọng của phương pháp đề xuất và 2) các kết quả chính của bài báo. Dưới đây là một ví dụ về phần 1.

In this paper, we propose a novel adaptation method for 360 video streaming over mobile networks that can provide high viewing experience to the users with the following key features.

•  Scalable Video Coding (SVC) is utilized to tackle the trade-off between network adaptivity and viewport adaptivity.
• The tile layer selection problem is formulated and an efficient algorithm is proposed.
• A late tile layer termination scheme is presented that can save network resources by terminating the delivery of late tile layers using HTTP/2’s stream termination feature.
• A tile layer updating scheme that can effectively deal with viewport estimation errors is proposed. The scheme makes use of HTTP/2’s stream priority feature.

Ở đây, tác giả đưa ra các kỹ thuật bài báo đề xuất và tác dụng cụ thể của từng kỹ thuật. Việc viết theo kiểu liệt kê như ở trên nên được sử dụng để giúp người đọc dễ hiểu. Một điểm quan trọng nữa là nếu đã có các phương pháp trước đây (existing methods) thì đoạn này cũng phải nêu được sự ưu việt (advantages) của phương pháp đề xuất so với các phương pháp cũ. Ở phần thứ hai, các kết quả chính của bài báo được giới thiệu như ví dụ ở phía dưới.

Experimental results using real head movement traces and real network throughput traces show that the proposed method can improve the average viewport bitrate by 16-17% compared to a reference method. Also, our method can avoid significant reductions in the buffer level.

Khi đề xuất một phương pháp mới, thì ở đoạn này bạn phải nêu bật được sự hiệu quả của phương pháp đề xuất một cách định lượng. Cấu trúc phổ biến có thể dùng ở đây là:

The proposed method can improve ... by ... compared to reference methods.

Ở dấu ba chấm đầu tiên là tên metric dùng để đánh giá (average viewport bitrate), dấu ba chấm thứ hai mức độ cải thiện của phương pháp đề xuất. Như đã nói ở trên, việc đưa ra các con số cụ thể sẽ làm cho bài báo có sức thuyết phục cao hơn.

Trên đây là giới thiệu về các thành phần và điểm chú ý khi viết phần Introduction của một bài báo khoa học. Các ví dụ sử dụng trong bài này được trích dẫn từ bài báo bên đưới.

Duc V. Nguyen, Hoang Van Trung, Hoang Le Dieu Huong, Truong Thu Huong, Pham Ngoc Nam, Truong Cong Thang, "Scalable 360 video streaming using HTTP/2", IEEE MMSP 2019 .

Làm nghiên cứu như thế nào? (Phần 1)

Hôm nay có bạn hỏi mình làm thế nào để viết được một bài báo nghiên cứu khoa học. Sau đây là tóm tắt các khái niệm và quá trình làm nghiên cứu theo kinh nghiệm của bản thân mình. Hy vọng sẽ giúp các bạn có cái nhìn tốt hơn về làm nghiên cứu.

Đầu tiên phải nói đến khái niệm cơ bản liên quan đến làm nghiên cứu (research). Làm nghiên cứu tức đi tìm câu trả lời (answer/solution) cho một câu hỏi (question/problem) mà chưa ai trả lời được. Một ví dụ nổi tiếng là câu hỏi: Các hành tinh chuyển động xung quanh mặt trời theo quỹ đạo hình gì? Để trả lời câu hỏi này, đầu tiên chúng ta cần tập hợp dữ liệu (data collection) về chuyển động của các hành tinh theo thời gian. Điều này được thực hiện đầu tiên bởi Tycho Brahe ở thế kỷ 16. Trong thời đại chưa có kính viễn vọng, Tycho ghi lại vị trí của các hành tinh bằng cách quan sát bằng mắt thường từ đêm này qua đêm khác. Độ chính xác cao từ dữ liệu của Tycho chính là tiền đề để Kepler trả lời câu hỏi về chuyển động của các hành tinh. Phương pháp mà Kepler sử dụng là trial-and-error. Đầu tiên ông giả thuyết (hypothesis) quỹ đạo của các hành tinh là đường tròn, sau khi tính toán vị trí của các hành tinh và so sánh với dữ liệu thực tế, ông nhận thấy sai số (error) là quá lớn. Kepler lặp đi lặp lại quá trình này và tìm ra rằng quỹ đạo phù hợp nhất với dữ liệu thực tế là hình ellipse với mặt trời nằm ở một trong hai focal points. Các kiến thức được đưa vào trong sách giáo khoa như định luật vạn vật hấp dẫn, định luật Faraday, thuyết tương đối cũng đều được xây dựng để trả lời các câu hỏi tương tự. (Việc xây dựng mô hình để dự đoán Quality of Experience (QoE) tương đương với việc trả lời câu hỏi: QoE phụ thuộc vào những nhân tố nào? Cách chúng ta trả lời câu hỏi này cũng không khác gì so với cách mà Kepler, Faraday, hay Einstein sử dụng!)

Làm nghiên cứu vì vậy sẽ có hai bước 1) xác định câu hỏi và 2) tìm câu trả lời. Đây là ví dụ về một câu hỏi.

Trong live streaming over HTTP, biết trước độ dài buffer và bitrate của từng version, tải version cho từng segment như thế nào để đem lại trải nghiệm tốt nhất cho người dùng?

Phần đầu tiên của câu hỏi này "Trong live streaming over HTTP", định nghĩa bối cảnh (context) mà câu hỏi này áp dụng. Bối cảnh cũng sẽ xác định các ràng buộc (constraints) mà câu trả lời phải thỏa mãn. Ví dụ trong live streaming, bạn chỉ có thể gửi request cho một segment sau khi nó đã được tạo ra ở server. Một ràng buộc khác là độ trễ của tín hiệu phải nhỏ hơn một giá trị cho trước. Phần tiếp theo  "biết trước độ dài buffer và bitrate của từng version" định nghĩa các thông tin đầu vào (inputs) của bài toán. Phần cuối cùng "đem lại trải nghiệm tốt nhất cho người dùng" định nghĩ mục tiêu (objective) của câu trả lời. Vì vậy, xác định được câu hỏi tức là bản phải xác định được:

1. Bối cảnh (context)

2. Đầu vào (inputs)

3. Các ràng buộc (constraints)

4. Mục tiêu (objectives)

Cách mình thường dùng để tìm câu trả lời như sau:

1. Xác định giá trị của mục tiêu với các câu trả lời đơn giản nhất (baselines). Việc này sẽ giúp cho bạn đánh giá được hiệu quả mà phương pháp của bạn sẽ đề ra.

2. Đề xuất câu trả lời mới, đánh giá, và so sánh với giá trị ở bước 1

3. Cải tiến câu trả lời và lặp lại bước 2

Bước 2,3 là nơi mà mình thích nhất trong quá trình làm research vì được thoải mái sáng tạo, đưa ra ý tưởng và kiểm chứng tính hiệu quả của chúng. Đây cũng là nơi mà bạn phải dành nhiều thời gian nhất trong quá trình làm. Quá trình trial-and-error mà Kepler dùng để tìm ra dạng quỹ đạo của các hành tinh cũng nằm ở hai bước này.

Sau khi đã có một câu trả lời, việc quan trọng tiếp theo là phải so sánh với các câu  trả lời trước đây. Với các câu hỏi quan trọng, thì việc có khoảng 10 câu trả lời trước đây là việc rất bình thường. Nếu inputs của bạn hoàn toàn giống với inputs trong các bài báo trước đây thì bạn có thể dùng kết quả mà tác giả ghi trong bài báo của họ để đánh giá. Nếu không bạn sẽ cần phải implement và đánh giá lại câu trả lời của họ với dữ liệu đầu vào mà bạn đang dùng.

Sau khi đã chứng minh được rằng câu trả lời của bạn tốt hơn các đề xuất trước đây, bước cuối cùng là trình bày câu trả lời của bạn thành một bài báo để người đọc có thể hiểu và kiểm chứng được câu trả lời bạn đề xuất. Trong thực tế thì việc viết này sẽ được tiến hành ngay từ đầu và mình cũng khuyến khích các bạn như vậy. Nó sẽ giúp các bạn hiểu rõ hơn câu hỏi mà mình đang giải quyết. 

Kết: Làm nghiên cứu là một công việc mà bạn có thể rèn luyện được rất nhiều kĩ năng: tìm kiếm và giải quyết vấn đề, trình bày, làm việc nhóm, tiếng Anh. Tuy nhiên, nó cần rất nhiều nỗ lực và thời gian và phụ thuộc nhiều vào câu hỏi bạn giải quyết. Einstein chỉ mất 3 tháng để phát triển thuyết tương đối hẹp, nhưng mất tới 10 năm để tìm lời giải cho thuyết tương đối rộng. Trong bài tiếp theo, mình sẽ nói về hội nghị, tạp chí và các vấn đề liên quan.

Học về thuyết tương đối (special relativity and general relativity)

Albert Einstein được xem như là một trong những nhà bác học vĩ đại nhất mọi thời đại. Tên của ông đồng nghĩa với thiên tài (genius). Hai công trình khoa học quan trong nhất của Einstein là thuyết tương đối hẹp (special relativity) và thuyết tương đối rộng (general relativity). Vậy thuyết tương đối hẹp là gì? Nó được tạo ra như thế nào? Các hệ quả của nó là gì? Ứng dụng của nó là gì? trả lời những câu hỏi này sẽ là mục tiêu của bài viết này.

Đầu tiên nói về bối cảnh, thuyết tương đối hẹp được Einstein đề xuất lần đầu tiên trong một bài báo ông viết vào năm 1905 đăng trên tạp chí vật lý Annalen der Physik . Lúc này ông 26 tuổi và đang là nhân viên ở văn phòng phụ trách đăng ký bản quyền ở Zurich, Thụy Sĩ. Cùng trong năm này, ông còn viết 3 bài báo quan trọng ở các lĩnh vực khác bao gồm 1) phân tích chuyển động của phân tử, 2) giải thích hiệu ứng quang điện (photoelectric effect), và 3) mối liên hệ giữa khối lượng và năng lượng (E=mc^2). Ông được trao giải thưởng Nobel vật lý năm 1921 do đóng góp trong việc giải thích hiệu ứng quang điện (photoelectronic effect). Năm 1905 vì vậy được gọi là Annus mirabilis , có nghĩa là năm kỳ diệu của Einstein.

Thuyết tương đối hẹp ra đời để giải thích sự không đồng nhất giữa cơ học cổ điển của Newton và thuyết điện từ phát triển bởi Maxwell liên quan đến vận tốc của ánh sáng. Theo Newton, vận tốc của mọi vật là tương đối phụ thuộc theo hệ quy chiếu, ví dụ nếu bạn ngồi trên tàu đang di chuyển với vận tốc là 60km/h thì vận tốc của bạn so với côt mốc bên đường là 60km/h, nhưng so với người ngồi cạnh thì sẽ là 0km/h. Tuy nhiên, Maxwell đã chứng minh rằng ánh sáng là một loại sóng điện từ (electromagnetic wave), và có vận tốc không đổi 3x10^8 (km/h) trong chân không. Điều này dẫn đến việc nếu bạn ngồi trên tàu và chiếu đèn cùng hướng di chuyển với một chuyến tàu đang di chuyển với vận tốc 10^8 (km/h) thì một người đứng ở cạnh đường ray vẫn sẽ đo được vận tốc ánh sáng từ đèn của bạn là 3x10^8 (km/h) chứ không phải là 4x10^8(km/h).

Để giải thích cho sự không đồng nhất này, Einstein đã sử dụng kết quả của Maxwell và đặt ra tiên đề: "Vận tốc ánh sáng là cố định và không phụ thuộc vào hệ quy chiếu". Đây chính là một trong hai tiên đề của thuyết tương đối hẹp. Tiên đề còn lại là: "Các định luật vật lý là như nhau trong mọi hệ quy chiếu quán tính".

Nếu vận tốc ánh sáng là không đổi thì so với một người ngồi trên tàu, thời gian của một người đứng ở bên đường sẽ trôi nhanh hơn. Lý do là bởi vì người đứng bên đường sẽ thấy ánh sáng đi được một quãng đường xa hơn so với người ở trên tàu. Vì thời gian bằng quãng đường chia cho vận tốc nên thời gian người đứng ở bên đường trải qua sẽ dài hơn. Do vậy, thời gian không còn là tuyệt đối mà chỉ là tương đối và phụ thuộc vào vận tốc.

Sự liên hệ về thời gian t của một hệ quy chiếu đứng yên so với thời gian t' của một hệ quy chiếu chuyển động có thể được tính toán rất đơn giản như sau. Giả sử trên một chiếc tàu chuyển động với vận tốc không đổi v, một photon (đơn vị nhỏ nhất cấu tạo nên ánh sáng) di chuyển qua lại giữa hai tấm gương đặt song song với nhau và song song với mặt đất. Xem xét sự kiện một photo di chuyển từ tấm gương phía dưới lên tấm gương phía trên. Giả sử thời gian photon di chuyển t' đối với một người đứng trên tàu, là t đối với một người quan sát trên mặt đất. Đối với người quan sát trên mặt đất, quãng đường photon di chuyển sẽ là AB vì vị trí chiếc gương bị xa ra do tàu di chuyển một đoạn là CB trong khoảng thời gian photon di chuyển. Ta sẽ tính được giá trị các độ dài AB, BC, và AC như sau:

AB = c x t với c là vận tốc của ánh sáng
BC = v x t với v là vận tốc di chuyển của tàu
AC = c x t' với t' là thời gian của một người đứng trên tàu.

Vì ABC là tam giác vuông, sử dụng định lý Pythago và một số bước biến đổi ta thu được kết quả liên hệ giữa t và t' như công thức ở trên. Vì vận tốc di chuyển của tàu (v) nhỏ hơn vận tốc ánh sáng (c), ta suy ra được là t' nhỏ hơn t. Nói cách khác, thời gian đối với người di chuyển thì trôi chậm hơn so với người đứng yên. Trong cuộc sống của con người, v thường rất nhỏ so với c nên sự khác biêt là gần như không đáng kể. Đối với các vật di chuyển nhanh, sự khác biệt có thể là rất đáng kể. Có một điểm thú vị là nếu di chuyển với vận tốc ánh sáng (v=c) thì thời gian sẽ ngừng trôi (t' = 0).

Tương tự như thời gian, không gian (độ dài) cũng có tính tương đối và phụ thuộc vào vận tốc di chuyển: "độ dài của một vật khi di chuyển thì ngắn hơn độ dài của cùng vật đó khi đứng yên". Và khi di chuyển với vận tốc ánh sáng, thì độ dài sẽ bằng 0.

Dù nổi tiếng nhưng thuyết tương đối hẹp của Einstein không có nhiều ứng dụng trong thực tiễn cuộc sống vì chúng ta di chuyển với vận tốc rất nhỏ so với vận tốc ánh sáng, nên thời gian giữa các hệ quy chiếu có thể xem là giống nhau mà ko gây ra nhiều vấn đề. Đây cũng là một lý do cho việc ông không được trao giải Nobel cho thuyết tương đối hẹp. Một ứng dụng có thể kể đến là việc căn chỉnh thời gian của các vệ tinh của hệ thống định vị toàn cầu GPS. Các vệ tinh này di chuyển với vận tốc hàng chục nghìn ki lô mét một giờ nên thời gian đối với các vệ tinh này sẽ chậm hơn so với người di chuyển trên mặt đất. Do vậy, việc tính toán tọa độ của người dùng phải tính đến sự chênh lêch thời gian này.

Người ta gọi 1905 là năm kỳ diệu của Estein nhưng thực ra thời gian này không thực sự tốt đẹp với ông. Bài báo về thuyết tương đối hẹp dù được xuất bản trong năm này nhưng gần như không ai trong giới khoa học để ý đến vì ông chỉ là một nhân viên văn phòng không phải là giáo sư của trường đại học. Ông chỉ thực sự được chú ý khi Max Plank, một nhà khoa học nổi tiếng đương thời, cha đẻ của cơ học lượng tử (quantum mechanic) và là chủ biên của tờ tạp chí Annalen der Physik, đọc bài báo của Einstein và nhận ra tầm quan trọng của kết quả này. 

Dù không hoàn toàn bị thuyết phục bởi kết quả trong bài báo, Max Plank yêu cầu Einstein giải thích kỹ hơn về kết quả, cũng như yêu cầu ông mở rộng lý thuyết cho trường hợp hệ quy chiếu chuyển động có gia tốc (vận tốc thay đổi theo thời gian). Einstein mất 10 năm để mở rộng thuyết tương đối hẹp cho trường hợp hệ quy chiếu có gia tốc, và kết quả của nó là thuyết tương đối rộng (general relativity). Dù được gọi là thuyết tương đối rộng, nhưng general relativity lại giải quyết một vấn đề hoàn toàn khác biệt là lực trọng trường (Gravity). 

Giới thiệu về Behavioral Targeting (Phần 1)

Behavioral Targeting là gì?

Chắc hẳn đã có nhiều lần bạn cảm thấy khó chịu và phải tắt các quảng cáo không phù hợp khi đang lướt web. Behavioral targeting là một phương pháp marketing sử dụng thông tin của người dùng để tăng tính hiệu quả cho các chiến dịch quảng cáo cũng như tạo sự thoải mái cho người dùng. Một ví dụ của Behavioral targeting là việc bạn có thể nhìn thấy các quảng cáo về máy tính của Amazon xuất hiện khi bạn xem Facebook, sau khi bạn xem hoặc mua các sản phẩm liên quan đến máy tính trên Amazon. Kỹ thuật này hoạt động dựa trên việc tập hợp dữ liệu và phân tích hành vi (behaviors) của người dùng. Ví dụ như bạn hay tìm kiếm các thông tin gì, các trang web ưa thích của bạn là gì, trong quá khứ bạn đã mua những gì qua các trang web bán hàng online.

Các công ty tập hợp dữ liệu của khách hàng như thế nào?

Hình trên là thông báo mà bạn sẽ gặp khi vào một trang web mới. Khi bạn chọn "I ACCEPT", các công ty sẽ có thể theo dõi cách bạn tìm kiếm và sử dụng thông tin trên website của họ thông qua một công cụ gọi là Cookie. Cách thức hoạt động của Cookie rất đơn giản, đầu tiên các website sẽ tạo ra một mã số (ID) cho mỗi một người dùng. Trình duyệt web trên thiết bị người dùng sẽ lưu lại mã số này. Mỗi lần người dùng truy nhập lại vào website đó, trình duyệt web sẽ chèn thêm ID vào thông tin nó gửi đến máy chủ web server. Bằng cách này, các công ty có thể thu thập được thông tin về thời gian, nội dung một người dùng hay xem, và thậm chí là các quảng cáo người đó đã click. Nếu bạn đã tạo tài khoản (User Account) trên một website, thì các công ty có thể kết hợp các thông tin cá nhân như tuổi, giới tính, nghề nghiệp của bạn với thông tin thu được từ Cookie.

Dữ liệu khách hàng mà các công ty có được từ khách hàng của chính mình được gọi là "first-party data". Để mở rộng đối tượng khách hàng, các công ty có thể mua first-party data từ các công ty khác. Dữ liệu loại này được gọi là second-party data. Loại dữ liệu thứ ba được gọi là third-party data,  đây là dữ liệu người dùng được tập hợp từ nhiều nguồn bởi các công ty gọi là Content Aggregrators. Điểm mạnh của loại dữ liệu này là nó được cập nhật thường xuyên với số lượng lớn. Trong lĩnh vực quảng cáo online, first-party data là loại dữ liệu mang lại hiệu quả nhất. Sự thành công của các công ty bán hàng trực tuyến như Amazon, Ebay, Alibaba có vai trò quan trọng của việc phân tích và sử dụng first-party data.

Tổng quan về hệ thống live video streaming (Phần 2)

Trễ trong hệ thống live streaming

Như đã phân tích trong phần 1, video sau khi thu phải trải qua các công đoạn nén (encoding), truyền (transmission), giải nén (decoding) trước khi được hiển thị lên màn hình của người dùng.  Thời gian cần để xử lý mỗi công đoạn trên gây ra trễ (delay) giữa thời gian thực tế của sự kiện và thời gian người dùng xem sự kiện. Các thành phần trễ chính trong hệ thống live streaming được chỉ ra trong hình trên. Ở đây, trễ được tính từ lúc một ảnh được đưa vào Encoder cho đến khi ảnh đó ra khỏi Decoder.

1. Encoding delay: Đây là thời gian Encoder cần để nén một ảnh của video. Các Encoder sẽ có các lựa chọn về thời gian nén cho các ứng dụng khác nhau. Với cùng một mức chất lượng đầu ra, thời gian nén càng nhanh sẽ làm cho hiệu suất nén giảm và ngược lại. Thời gian thực tế để nén một ảnh phụ thuộc vào nhiều yếu tố, ví dụ như encoder được cài đặt trên phần mềm (software-based encoder) hay phần cứng (harward-based encoder), kích thước của ảnh, chất lượng đầu ra của ảnh. Các encoders nhanh nhất hiện nay có thể nén một ảnh dưới 1 mili giây.  
2. Packetization delay: Như đã phân tích trong phần 1, việc truyền dữ liệu từ bên gửi đến bên nhận được thực hiện thông qua các giao thức streaming (streaming protocols). Bạn có thể xem các giao thức này như các công ty vận chuyển hàng hóa. Để có thể chuyển hàng đến đúng người nhận thì sau khi nhận hàng, các công ty này sẽ phải đóng gói, thêm địa chỉ người nhận/gửi rồi mới gửi đi. Công việc của các streaming ptococols cũng tương tự như vậy. Và việc đóng gói (Packetization) gây ra trễ trong hệ thống. Thời gian cho việc đóng gói này có thể chỉ vài mili giây (RTP, RTMP) nhưng cũng có thể lên đến vài giây (MPEG-DASH, HLS). 
3. Transmission delay: Đây là thời gian để chuyển dữ liệu từ bên gửi đến bên nhận. Cũng tương tự như việc vận chuyển hàng hóa. Thời gian chuyền dữ liệu phụ thuộc vào 1) khoảng cách giữa bên gửi và bên nhận, 2) tốc độ của đường truyền, 3) đặc tính của giao thức truyền.
4. Client buffering delay: Khi bạn bắt đầu nhấn nút play, các ảnh trong video được giải nén và hiện thị lên màn hình với tốc độ không đổi bằng frame rate của video. Do vậy, nếu một ảnh không đến được phía nhận trước thời gian nó phải được hiện thị, quá trình hiển thị video sẽ bị chậm, gây ra hiện tượng giật lag khi xem. Do mạng Internet không đảm bảo một băng thông cố định, thời gian truyền mỗi ảnh sẽ rất biến động. Do vậy, khả năng cao là người xem sẽ phải chứng kiến rất nhiều hiện tượng giật lag nếu việc hiển thị video được thực hiện ngay sau khi ảnh đầu tiên của video đến. Để xử lý vấn đề này, bên nhận sẽ không bắt đầu quá trình hiện thị video ngay khi ảnh đầu tiên đến, mà thay vào đó đợi cho đến khi một số lượng ảnh nhất định đã được nhận thì mới bắt đầu. Thời gian này gọi là "client buffering delay". Thời gian này có thể từ vài trăm mili giây đến vài giây, phụ thuộc vào từng hệ thống.

Các hệ thống live streaming có nhiều yêu cầu khác nhau về thời gian trễ.

1. 1s-5s: Các ứng dụng như trực tiếp các sự kiện thể thao, tin tức yêu cầu trễ từ 1-5 giây. Điều này để đảm bảo rằng tín hiệu nhận được không bị chậm hơn tín hiệu trên tivi. Trung bình trễ trong các hệ thống truyền hình cáp là 5-6 giây. Với các dịch vụ OTT, đây sẽ là mục tiêu chính để có thể tiến tới thay thế hoàn toàn tivi.  
2. 200ms-1s: Mức trễ này là yêu cầu đối với các ứng dụng như cá cược/đấu giá trực tuyến, camera giám sát.
3. < 200ms: Các hệ thống tương tác như video call, cloud gaming, hay telepresence yêu cầu mức trễ này để có thể đảm bảo được chất lượng dịch vụ. Các hệ thống video call tốt nhất hiện nay (Google Hangout, Skype) có trễ gần với mức này. Các ứng dụng như cloud gaming hay telepresence yêu cầu trễ phải dưới 100ms. Các công nghệ, kỹ thuật mới là rất cần thiết để có thể đảm bảo được mức trễ này. 

Tổng quan về hệ thống live video streaming (Phần 1)

Live video streaming là gì?

Live video streaming là hệ thống giúp bạn xem trực tiếp bóng đá, tivi, concert qua mạng Internet, gọi video call cho bạn bè qua Skype, Facebook Messenger, hay điều khiển robot từ xa (telepresence).

Hai vấn đề chính với hệ thống live streaming?

1. Tín hiệu nhận từ hệ thống live streaming bị chậm hơn so với tín hiệu trên tivi: Bạn hẳn sẽ rất khó chịu khi nhà bên cạnh đã hò hét ầm ĩ khi có bàn thắng trong khi tỷ số trên màn hình máy tính của bạn vẫn là 0-0.

2. Bị dừng hình trong lúc đang xem (buffering): Vấn đề này gây ra do hệ thống không thích ứng được sự biến động đường truyền Internet , đặc biệt là trong các trường hợp dùng Wifi hay mạng di động.

Hệ thống live streaming hoạt động như thế nào?

Trước hết, các bạn cần phải hiểu một số khái niệm, thành phần cơ bản cho việc truyền video qua mạng Internet.

1. Video Capturing (Thu video): Việc thu video được thực hiện bằng việc chụp các ảnh liên tiếp nhau. Phổ biến nhất hiện nay là 30 hoặc 60 ảnh trên 1 giây (30/60fps). Bạn có thể thu video từ camera của smartphone, webcam của laptop, hay từ các máy quay chuyên nghiệp.

2. Video encoding/decoding (Nén/giải nén video): Video gốc thường chứa rất nhiều thông tin dư thừa, ví dụ như hai ảnh  liên tiếp nhau thường có rất nhiều phần giống nhau, thậm chí trong cùng một ảnh cũng có những phần giống nhau. Ngoài ra, có rất nhiều thông tin trong video mà mắt con người không phân biệt được. Những đặc tính này được sử dụng để làm giảm kích thước của video gốc thông qua loại bỏ các thông tin dư thừa. Quá trình này được gọi là nén video. Các công cụ tốt nhất hiện nay có thể làm giảm kích thước của video gốc vài trăm lần. Video với độ phân giải HD sau khi nén  có bitrate từ 6Mbps-10Mbps (Bitrate: số lượng dữ liệu tính theo bit có trong 1 giây video). Giải nén video là quá trình khôi phục lại video gốc từ video đã được nén. Việc này sẽ được thực hiện ở phía nhận tín hiệu, cụ thể các trình duyệt Web hoặc các Mobile apps sẽ chịu trách nhiệm việc này.

3. Protocol (Giao thức): Protocol là ngôn ngữ mà các máy tính dùng để giao tiếp với nhau. Cụ thể, thì nó là một tập hợp các quy tắc, định dạng, và hành động để truyền dữ liệu từ máy tính này đến  máy tính khác. Có rất nhiều giao thức được sử dụng cho nhiều mục đích khác nhau. Bài này sẽ chỉ tập trung vào các giao thức để truyền video.

Hình 1: Các thành phần của hệ thống live streaming.

Hệ thống live streaming hoạt động như sau:
1. Camera thu video sau đó chuyển cho Encoder
2. Encoder nén video rồi chuyển cho Sender
3. Sender sẽ gửi video đã được nén đến bên nhận Receiver
4. Receiver nhận video rồi chuyển cho Decoder
5. Decoder sẽ giải nén video và sau đó video sẽ được hiển thị lên màn hình người dùng.

Chú ý rằng camera sẽ gửi dữ liệu đến Encoder sau khi thu được một số lượng ảnh nhất định. Các Encoder phổ biến hiện nay bao gồm x264, x265, và OBS. Để phù hợp với live streaming, các encoders hiện nay thường được cài đặt trên phần cứng (hardware-based encoding). Tương tự như vậy, việc giải nén video ở phía nhận cũng có thể được chuyển lên phần cứng để tăng tốc độ.

Việc truyền dữ liệu từ Sender đến Receiver được thực hiện thông qua các giao thức truyền video như HLS, MPEG-DASH, RTMP, RTP/RTSP. RTMP (phát triển bởi Adobe) vẫn đang là lựa chọn phổ biến cho hệ thống live streaming vì nó có thể đảm bảo được trễ thấp. HLS và MPEG-DASH là hai giao thức phổ biến cho trường hợp truyền on-demand (không trực tiếp). Tuy nhiên, nhiều kỹ thuật để giảm trễ cho HLS/MPEG-DASH đã và đang được triển khai.

Việc chạy video ở phía nhận hiện nay phổ biến nhất là sử dụng HTLM5 Video Tag vì nó cho phép chạy video ngay trong trình duyệt web mà không cần cài đặt thêm các plugin bên ngoài như Flash, VLC.

Phần tới sẽ phân tích về trễ của hệ thống live streaming so với hệ thống truyền hình.