Many thanks @Rachel 🙂 Yeah, theirs is one of those. We'll have to try and see.

Hi - new stream developer here working to live stream using the CloudFlare Stream system - we have it all working but are confused by a few things. 1) Should we view using the Input UID or the Video UID, and is there a practical difference (in transcoding options, CDN, etc.) as the input ID is available as soon as we create the input, so we can save it, etc. on our side, but the video ID seems is only created once users start streaming sometime later, making it much harder to get & store the ID. We're mostly interested in always showing the live stream, so we're guessing we should use the input UID at all times (unless we want to show a recording), and that'll work fine for transcoding, CDN, etc.? 2) When is a video created from an input? Seems the first time the input is actually used/connected, then it reuses that video (and its ID) forever more. 3) The Cloudflare stream console have nice players, and on the input it's not clear how this is connected to the input, i.e. it appears to go through the transcoders (i.e. not raw input) and has quite a lag, is sometimes longer than the video output player does; I guess that's normal, but means we have no way to see the actual input in anything like real-time, for troubleshooting, etc. 4) What is the behavior when there is a connection to the input and what looks like 2-5Mbps of data, but no video, either that it's not started, or just black? This seems to result in players getting HTTP 204 codes and no results, too. Is there any way to troubleshoot this? 5) I assume 'videos' are essentially one per stream session, i.e. a connection and then disconnection from the input?

Input UIDs and video UIDs are a bit hard to compare, as they serve much different purposes. An Input is reusable, so each time something publishes to it, it'll create a new video with associated UID for that particular session. So in that way, it's about what you are trying to keep track of. I believe there is a timeout where if an input goes offline and back online within a certain amount of time (a few minutes IIRC), it will reuse the last video. Perhaps you're running into that behavior?

Regarding how the pipeline works:

-> DASH
input feed (rtmp/srt) -> transcoders -> HLS
                      -> outputs (rtmp/srt)
                      -> pulldowns (rtmp/srt)

is roughly how I understand it. If you want a lower latency preview of the stream, you'll need to use RTMP or SRT pulldown, as those are "source quality" and not transcoded

Assuming you're using RTMP to publish a stream to an input, the FLV spec requires exactly one video track and one audio track. I can't answer to the specific behavior of cloudflare stream with a scenario like that, but arguably something like that is undefined behavior and out of spec

5) pretty much, yeah. Outside of that reconnect period I mentioned before

Thanks - that makes sense, and we'll likely work on getting SRT/RTMP for testing. We were alarmed to see the code using input ID for fear of skipping some steps, but seems best as we'll always get the current stream that way (we also use several CDNs and this matches others' behavior).

@Steve Mushero using the source ID vs video ID depends on what you are doing. If you are using the source ID it will always livestream with the latest ingest, useful if you are embedding to a website. Video ID is more for convenience as the same HLS or Dash manifest will serve the recorded video after the live stream has ended. It really depends on your use case.

Currently once the livestream has started, there is some delay (about 3x your GOP) + about 5s (I can't remember the exact number) before the player will show the livestream. If after 30s of your livestream has started, the player still doesn't play, please @ me here again

We are currently dedicating basically half of thr team to work on lowering the latency, which will bring the latency down to like at most 1 GOP (again I can't remember the number on top of my head)

For sub-second latency, we offer WebRTC via WHIP/WHEP but currently under beta, an I'm working on improving the reliability in playback. However currently if you use webrtc, it doesn't support recording, nor it will support cross protocol (e.g. can't play back via HLS, must be used together with WHEP)

Roadmap is to unify all the protocols, but we are a small team, and we are working through thr roadmap

Another question - when playing a stream with HLS.js we almost always get the lowest stream rate, and if we watch on the HLS demo player (https://hlsjs.video-dev.org/demo/) we see it start at high rates, then within a few seconds go down to the lowest rate, usually with a buffer stall, too. This seems to be due to the first segments coming from CF slowly, fooling the player into thinking it's low bandwidth, even though in reality it supports 720p or 1080p with no problem, and works we'll if we add ?clientBandwidthHint=5 but that's not a good solution, as then it can't downgrade if it needs to. On the same connection, the demo HLS player works great with non-CF sources, always defaulting to 1080p so it's presumably a CF-related challenge we can't figure out. If you want to test, this stream is always active: https://customer-cmg27odg5g4vsjjl.cloudflarestream.com/95ab77947934930dd5a0f7885a586a7d/manifest/video.m3u8

@Schachte

endpoint for live disconnect: curl -X POST https://live-status.videodelivery.net/sources//disconnect @Slin and @tt2468

Can we generate thumbnails from stream live? or does it only work on videos? https://developers.cloudflare.com/stream/viewing-videos/displaying-thumbnails

@G4G4N you can generate from live - it will return the latest frame from the video

Is there anyway to get the first frame?

You can add "?time=1s" like https://customer-m033z5x00ks6nunl.cloudflarestream.com/b236bde30eb07b9d01318940e5fc3eda/thumbnails/thumbnail.jpg?time=1s

does it require

recording: { mode: 'automatic' }

to be set?

will it still work with?

recording: { mode: 'off' }

@User Might still work with recording off until you end the stream - give it a try

We have the same issues but with VOD and using Cloudflare Steam and VideoJS. The quality would stay very low even though we're on a 500 Mbps Fiber connection. We've moved over to the BitMovin Player now and almost immediately received the 1080p version. I think it's in the way CF builds the manifest, or something with the first segments. We couldn't solve it either. But as we were already using BitMovin in our App, we've migrated our Web App too which solves it. However we also are still receiving complaints from users using Chromecast that the quality isn’t up to par.

Although your current livestream seems capped at 1280x720 at 1902kbps which isn't that high (https://customer-cmg27odg5g4vsjjl.cloudflarestream.com/95ab77947934930dd5a0f7885a586a7d/manifest/video.m3u8)

Thanks - yes, we are capped on that one, but the HLS player goes to 240p and stays there - we can't see why or how, as the manifest seems fine.

hi, even if video is provided through webrtc whip, is the ip exposed?

Not to your viewers

Thank you for answer! then, is it correct for viewers expose their IP to other viewers?

No. If it is working correctly, no one should be able to see each others IPs(other than maybe the account owner)

huh It's completely different from the webrtc I know. I'll have to look into this. ty