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
