El mié, 28 jun 2023 a las 7:15, Christopher Schultz (< ch...@christopherschultz.net>) escribió:
> Daniel, > > On 6/27/23 15:40, Daniel Andres Pelaez Lopez wrote: > > You are right, the CMAF format of the segment might bring the fragment > size > > information, but as you state, we might need to parse the segment as it > is > > being uploaded to figure out the fragment size, that's an option over the > > table, but being fast is also important here, as we are creating low > > latency streams (under 3 seconds glass to glass). Seems easier to just > read > > the chunk size from the CTE, as this DASH server example shows > > https://gitlab.com/fflabs/dash_server/-/blob/master/dash_server.py#L62 > > that's a DASH server in Python with pretty low-level network access. > > You are only trying to optimize one link, here, right? The > Tomcat-to-client link? The video-generator-to-Tomcat link need not be > particularly optimized, correct? > > It might be easier to parse the CMAF as it arrives and store your own > mapping metadata. It will require less hacking of Tomcat (which would > not work if you ever had to switch server vendors, for example) and it > would also work with *any* client, not just the specially-coded client > that already does this particularly-convenient upload-chunking you are > trying to capture. > > >> 1. The line which sets the output buffer size. If you use the default > >> buffer size, Tomcat may (okay, WILL) "chunk" the response in the middle > >> of your video-chunk of a video-chunk can get bigger than the current > >> buffer size. So you need to make sure that doesn't happen. > >> > >> Or, maybe it's okay if that happens, but you want to minimize the number > >> of times that happens or you waste bytes, cycles, etc. > > > > This is great info, I didn't know, as we would like to transfer full > > fragments, we might need to increase that above the max, I have seen 20 > kb > > fragments. > > While that's "not very big", I believe the default buffer size is 8kb so > you might have been bitten by this. > > > Streaming video is hard and harder in low latency glass to glass, so, > seems > > like optimizations on how to transfer the video are important, for > > instance, the HLS spec mentions how those fragments/byteranges should be > > returned > > > https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-6.2.6 > > (partial segments = fragments): > > > > When processing requests for a URI or a byte range of a URI that > > includes one or more Partial Segments that are not yet completely > > available to be sent - such as requests made in response to an EXT-X- > > PRELOAD-HINT tag - the server MUST refrain from transmitting any > > bytes belonging to a Partial Segment until all bytes of that Partial > > Segment can be transmitted at the full speed of the link to the > > client. If the requested range includes more than one Partial > > Segment then the server MUST enforce this delivery guarantee for each > > Partial Segment in turn. This enables the client to perform accurate > > Adaptive Bit Rate (ABR) measurements > > Yeah, it's not surprising that I'm ignorant of all that stuff. :) > > > Our understanding of that statement is that we must have the whole > > chunk/fragment/partial segment ready before transmitting it through the > > network, as a chunk. > > But I think it was mostly written to ensure that no other delay factors > would come into play during transmission -- such as waiting on some > OTHER network resource to provide the source data. I mean... you are > still going to be waiting on the disk/NAS/etc. right? Or are you reading > everything into memory before this? > > I'd still argue that math is fast and networks are slow, but it's not my > project :) > > > Regarding using org.apache.coyote.Request.setInputBuffer as a workaround, > > seems like we don't have access to org.apache.coyote.Request directly, we > > have access to org.apache.catalina.connector.RequestFacade, which doesn't > > offer any way to access the > > underlying org.apache.catalina.connector.Request, and therefore > > org.apache.coyote.Request. Any way to have access to > > org.apache.coyote.Request? > > Yeah, this is the part where I think you need some support added into > Tomcat itself at the source level. > > Tomcat doesn't expose the coyote.Request object to applications for two > reasons: (1) it's contrary to the spec and (2) it's potentially > dangerous, since it offers access to Tomcat internals. > > So we'll have to come up with the most convenient thing in Tomcat that > can reasonably help you out, here. > > It's possible that we won't come up with anything, because it will break > too much encapsulation / protection and you may have to resort to my > proposal above, which is to instrument the upload differently and > capture your metadata in a more product-agnostic way. > > -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Christopher, Thanks for the help and insights. We are going to evaluate what other options we have, but seems like hacking Tomcat is not the right path. -- Daniel Andrés Pelaez López Master’s Degree in IT Architectures, Universidad de los Andes. Software Construction Specialist, Universidad de los Andes. Bachelor's Degree in Computer Sciences, Universidad del Quindio. e. estigm...@gmail.com
