[YouTube Live Chat] Playback issue record

lcr = $('yt-live-chat-renderer') replayQueue = lcr.replayBuffer_.replayQueue

(Ticked if fixed)

playerOffsetMs issue

[x] issue "backward the timeline and then chat appearance get stopped" was resolved by youtube engineers in 2023(?)
[x] &playerOffsetMs=XXX has been set for VODs with default collapsed live chat (sample link)
[x] &playerOffsetMs=XXX has NOT been set for VODs with default expanded live chat (sample link)
[x] playerOffsetMs would be the actual player's progress when the live chat get expanded, but if it is default expanded.. become a bug
[x] replayQueue would have the initial data (by window.ytInitialData) when the live chat first loaded, but if the progress time from top window's player is far from that time, it will still keep and therefore those messages are fake. (e.g. progress = 80s, replayQueue is storing t=0s as ytInitialData is based on playerOffsetMs)
WTF is "yt-iframed-parent-ready". This looks reasonable but why no handling?

[x] ticker animation do not have a proper mechanism for checking whether ticker shall animate or not.
[x] the mechanism is simple and dumb - assume the video is playing and such that ticker appear must start countdown, and the animation will pause when the video is paused, then resume when video is resumed.
[x] how can you assume the video is always playing? can't i just pause it and seek the progress? then the animation will automatically start WTF?
[x] 2 obvious point to mention. first, if the chat is expanded when the video is paused, the status in iframe is always "video is playing". second, if the video is paused and then go backwards, there will be a seek continuation action so that the past tickers will be shown. the iframe already know it is paused but still start the animation without question.
[x] the one by one adding by splice and then notify, make the entire page frozen when it is changed from background to foreground. (if there are many insertions and deletions during the time that the page is invisible)

ticker startime might not be the time when it is added to the dom tree.

[x] delaying for batch rendering
[ ] the tickers at the t=0s are actually the tickers before the live show. therefore they will suddenly disappear as the engine only checks when it shall be disappear but without when it was started.