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
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

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
(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

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.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to