Support Multi-manifest Streams

[Kethsar]

It appears occasionally youtube will actually create a new manifest for a Stream. That, or the streamer can by messing with something. Currently ytarchive fails when this happens as the new manifest resets the fragment number back to 0.
The manifest and googlevideo URLs will have an id parameter set to <videoid>.<manifest number>. Check this parameter and keep track of the manifest number, resetting the fragment number as necessary.

Also turns out a new manifest can end up with different qualities. So a stream starting with up to 1080p can end up only having up to 720p if the streamer decided to reduce their quality without making a new frame.
This may require muxing for each manifest rather than appending to the stream as a whole.

EDIT: Turns out the manifest ID is also in the player response, under playabilityStatus.liveStreamability.liveStreamabilityRenderer.broadcastId

[Lytexx]

@Kethsar just got this issue on a stream for the first time

2022/01/22 16:31:01 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found                                                                                                                                        
2022/01/22 16:31:01 DEBUG: audio3: Fragment 12654: 10/10 retries                                                                                                                                                       
2022/01/22 16:31:01 DEBUG: audio3: Fragment 12654: Stream still live, continuing download attempt                                                                                                                      
2022/01/22 16:31:02 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found                                                                                                                                        
2022/01/22 16:31:03 DEBUG: video2: HTTP Error for fragment 12654: 404 Not Found                                                                                                                                        
2022/01/22 16:31:04 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found                                                                                                                                        
2022/01/22 16:31:05 DEBUG: video2: HTTP Error for fragment 12654: 404 Not Found                                                                                                                                        
2022/01/22 16:31:05 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found                                                                                                                                        
2022/01/22 16:31:07 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found                   

and the googleurl says id=<id>.4 instead of .1 for some reason, there was only one manifest change from what i can tell
this worries me a lot since it can happen without warning and make ytarchive run in a loop forever ;w; please look over it whenever you have motivation again

edit: just happened again and it uses .5 now so I probably just missed the first 3

[nosoop]

Here's a script that can be used to stream to YouTube in a way that can occasionally reproduce the issue. It simulates disconnections, resolution / framerate changes, and aspect ratio changes.

Still fairly inconsistent; YouTube may continue serving reencoded fragments under the same manifest / broadcast ID despite parameter changes on the streamer's side; you may need to run it a second time or adjust delays. It might be the case that it just doesn't run long enough for YouTube to serve a new manifest or for the first one to expire — I've seen at least one stream where the first manifest went for two minutes before changing over.

I think some incremented broadcast IDs may be from the streamer configuring their tools before going live. Got one instance where the broadcast started at 2 but the resulting VOD had the same length as the download.