Chat flv.js

This article is a reflection inspired by the story of the author of flv.js, as shared in their story.

Currently, when it comes to web development related to live streaming services or video services, the most popular choices are hls.js or flv.js. Since the native video support in browsers does not include these formats, developers must find ways to decode them.

In the era of Flash, many issues could be solved with Flash; however, as Flash gradually phased out, alternative solutions became necessary. In recent years, Media Source Extensions have emerged to address this issue, but they require developers to read documentation, and there is generally limited information available online about MSE. Therefore, using existing solutions is often the most convenient approach.

At that time, the most well-known solutions were Bilibili's flv.js and hls.js.

Difference Between flv and hls

FLV was created to address the problem of large SWF file sizes generated by Flash for effective use over the internet. So, how can it be transmitted online?

Generally, to play content directly via RTMP on a webpage, Adobe Flash must be used for decoding. This was the solution before HTML5 matured. However, as Flash became part of history and browsers blocked it, different methods had to be developed. Using the RTMP protocol often faces firewall issues, making HTTP the most appropriate approach; nowadays, most live streaming protocols are based on HTTP-FLV.

MSE

The standard video tag only supports specific file formats (or containers). Formats like RTMP or m3u8, which are not supported, cannot be played directly via a video tag.

To add a layer of extensibility to existing audio and video, you can use the MSE API to modify or read the content of videos (provided the browser supports it), and then decode and play it using the video tag. However, this effort typically requires an understanding of the protocol itself or underlying knowledge of video encoding, along with time for maintenance and debugging. This is why flv.js and hls.js have stood out: they effectively address the current frontend demands for media playback.

Dealing with streams or encoding like HLS is not a simple task.

Developer's Story

This is a post by the core developer, Qianqian, on their blog. They had the idea of encapsulating FLV as MP4 for web playback back in high school while I was still figuring things out.

At that time, HLS already existed, but its architecture wasn't suitable for the progressive parsing needs of FLV, necessitating a separate design. A significant challenge in development was the level of browser support; around 2015 to 2016, support across browsers was still unstable. To develop flv.js, the author even delved into the source code of chromium/media.

Feeling bored with their current role, the author requested a job change to focus on developing flv.js. Although flv.js went live, aside from their supervisor, no one seemed to care about the results, and the final performance review resulted in a C rating.

“There were two employees: one wrote a large amount of relatively simple business code with consistent output; the other independently developed a core library, facing high difficulty, substantial engineering efforts, and a lengthy development cycle, ultimately blocked by external factors and unable to launch on time. The first employee received a high performance rating, while the second received a very low score. Is this fair?”

Upon realizing that this business-oriented company didn't value technical output, the author quietly planned to leave and hoped to open-source flv.js instead of letting it languish in the company.

Additionally, developers are human too; they have emotions and may feel dissatisfied with the current situation. I am personally grateful for joining some highly challenging companies early in my career, allowing me to pursue what I wanted and explore different fields.

Conclusion

Currently, flv.js handles most live streaming services. Even in self-developed solutions, it’s likely that a significant amount of code from FLV has been referenced. One can imagine the impact it has made in the software community and live streaming, all stemming from a cool idea and its implementation.

My first reaction after reading this was one of regret. Developers who have used flv.js likely understand the significant contributions it has made to the HTML5 live streaming domain; however, such results led to a C performance rating in a company context.

At the same time, I began to reflect on how more and more browsers support various APIs, along with the recent buzz around WebAssembly. Although there is a growing trend, it still feels like we’re at a point where the focus is on compiling languages into WebAssembly without seeing many practical applications.

Reflection

As I approach 26 years old, my life in Japan has indeed improved significantly, but it still doesn't match my expectations. Since taking on the Tech Lead role, my work efficiency has mostly been stuck in writing documentation and checking progress, leaving little time to focus on coding. Over time, this has led to feelings of being overwhelmed and mental fatigue.

Fortunately, I still have considerable flexibility to learn new things here, and my supervisor encourages me to pursue what I want, without too much pressure regarding performance reviews. However, in recent years, aside from exploring more aspects beyond frontend development, I haven’t made significant progress.

After graduating, I found it challenging to dedicate time and energy to learning a complete body of knowledge, which has been a source of anxiety and stress for me. I used to care deeply about the evolution of technology and tools, but in recent years, I’ve become increasingly indifferent. Perhaps one day, when resources allow, I will return to school to fill in some foundational knowledge and code I didn’t thoroughly learn before; for now, I will leave it to fate.