bedeho
commented
9 months ago Backdrop
Thanks for writing this up.
My understanding is that the purpose of the current fix is only to collect data to inform what codecs people are trying to use, so as to inform later work on how to transcode. You have tried to collect this data on client side to detect failed playback, and log - and possibly also give some new UI treatment, but that does not reliably work. For t
Analysis
- It's not clear to me that we actually need to collect much information about this ahead of time? At the time of implementing transcoding we could just do the required analysis by sampling data objects, and it also seems that QN may even hold decoded information about this already for many cases. In any case, adding tech debt, complexity and possible performance penalty to Argus does not seem worth it, or the best use of time right now.
- This does not actually sore the core user problem right now, which is that playback fails on certain options. We can actually never solve this for past uploads, because we don't have edit access to the channel, so the only thing which is relevant is future uploads. So to solve the core user problem we need either transcoding or to block uploads of formats we know are not universal. I honestly don't think either is terribly important right now, because such a gigantic share of uploads are through yt-synch.
attemka
Currently, there are no restrictions of the video asset encoding when Atlas user uploads a new file. However, some users are experiencing playback issues when the file has the unsupported codec. This issue should be solved by the transcoding, but since its only comes next year, according to our roadmap, it will be good to have an understanding of the codecs, which are causing the most issues. We tried to solve this on the client side in Atlas by using the mp4box, but unfortunately, it has some issues for mobile devices. So idea behind this issue would be to have the information about the video asset codec on the server-side and share it with the user in the response header, this way we can use either mp4box by gpac or ffmpeg (which we already using in monorepo in CLI). If the Argus performance would be noticeably affected by the ffmpeg\mp4box, maybe it'll worth it to add the codec info to the QN record of the asset.