Add CTE LL-DASH ingest publisher

[mondain]

Summary

• Add a CTE LL-DASH live ingest server for HTTP/1.1 chunked PUT/POST CMAF feeds.
• Support multiple concurrent ingest paths from day one and publish them through the existing live object API.
• Add CLI flags, tests, implementation plan, and usage docs.

Test Plan

• cmake --build build
• ctest --test-dir build --output-on-failure
• git diff --check

[TilsonJoji]

Noticed that stop() shuts down the listen socket and then joins all worker threads. In a scenario (e.g. a stalled encoder, interrupted network connection etc. ) where worker threads may still be blocked in recv() on already accepted client sockets, this could cause shutdown to hang if a client connects but does not finish sending the request/body.

One possible consideration could be to track active client sockets and shut them down during stop(), or use receive timeouts / non-blocking IO so worker threads can exit cleanly.

[mondain]

Fixed in dcb2a4b. LiveDashIngestServer::stop() now tracks active accepted client sockets and shuts them down before joining worker threads, so a stalled chunked request blocked in recv() no longer hangs shutdown. Added a regression test that opens a partial chunked PUT, calls stop(), and verifies it returns without waiting for the client to finish the body.

[TilsonJoji]

Noticed that each accepted connection appends a new worker thread, and completed workers seem to be joined only during stop(). In a long-running ingest server with many reconnects/requests, it could cause worker_threads to keep growing for the lifetime of the process

One possible consideration could be to periodically reap completed workers.

[mondain]

Fixed in dcb2a4b. Completed workers now mark themselves done, and the accept loop reaps/join-removes completed worker records before adding another accepted connection. stop() still joins any remaining active workers after shutting down the listen socket and active clients.

[piersoh]

I've run it:
./build/openmoq-publisher --live-source dash --dash-listen 0.0.0.0:8088 --dash-path /ingest --endpoint https://relay.moq:9668/moq --namespace live --draft 16 --publish-catalog --forward 0
And then pushed a test ingest feed like so:
ffmpeg -re -f lavfi -i "testsrc2=size=1280x720:rate=25" -f lavfi -i "anullsrc=r=48000:cl=stereo" -filter_complex "[0:v]split=2[v1][v2];[v1]scale=1280:720[v720];[v2]scale=640:360[v360]" -map "[v720]" -c:v:0 libx264 -b:v:0 1500k -g 50 -keyint_min 50 -sc_threshold 0 -map "[v360]" -c:v:1 libx264 -b:v:1 500k -g 50 -keyint_min 50 -sc_threshold 0 -map 1:a -c:a aac -b:a 128k -f dash -seg_duration 2 -use_template 1 -use_timeline 0 -init_seg_name 'video$RepresentationID$' -media_seg_name 'video$RepresentationID$' -adaptation_sets "id=0,streams=v id=1,streams=a" -multiple_requests 1 -streaming 1 -remove_at_exit 0 -window_size 20 -extra_window_size 20 http://localhost:8088/ingest/
Once ffmpeg starts pushing the media segments the publisher logs:
connection_id=1301d0605748f2ec
But it fails to go into await-subscribe mode and I'm unable to subscribe to the stream on the relay.

[mondain]

Follow-up for @piersoh's FFmpeg usage: dcb2a4b adds a live DASH ingest regression test based on that shape. The test uses FFmpeg-style representation paths under the ingest prefix (/ingest/video0, /ingest/video1, /ingest/video2) with separate init requests followed by media requests to the same representation paths, then verifies the server exposes catalog plus representation tracks and emits media objects.

I also probed the minimized FFmpeg command locally and confirmed that the DASH muxer writes video0, video1, and video2 for that naming pattern.