- Add maxUploadSize config (default 1GB) for custom HttpBody streaming uploads;
maxReqSize now only controls in-memory buffering threshold
- Reject uploads exceeding maxUploadSize with 413 before writing any data
- Delete incomplete files on HttpFileStorage destruction
- Open HttpFileStorage in "wb" mode instead of "ab" to avoid stale data
- Pass content_size to writeData() for integrity validation
- Use uint64_t for content_len to support large file uploads
- Wrap HttpBody _on_completed callback in try-catch to prevent unhandled exceptions
- Make GET_CONFIG global variables read-only
- Update ZLToolKit submodule
---------
Co-authored-by: xiongziliang <771730766@qq.com>
### Motivation
- Prevent unbounded memory growth in `FramePacedSender` when many frames
share identical or tightly clustered DTS values by restoring an
insertion-time frame-count guard independent of DTS-span-based pressure.
### Description
- Add a `kMaxCacheSize` constant and force a cache `flushCache(...)`
when `_cache.size()` exceeds `kMaxCacheSize`, keeping paced-sender
buffering bounded even if `buf_ms` remains small; the guard is applied
immediately after `_cache.emplace(...)` in
`FramePacedSender::inputFrame`.
### Testing
- Performed static discovery of call sites and symbols with `rg`/`sed`
to verify the paced sender is created when `_option.paced_sender_ms` is
nonzero and that frames are routed to `_paced_sender->inputFrame(...)`;
this succeeded.
- Attempted to configure and build with `cmake -S . -B build
-DCMAKE_BUILD_TYPE=Release && cmake --build build -j2` and `cmake
--build build -j2`, both failed during configuration or build due to
missing third-party artifacts (`3rdpart/ZLToolKit/CMakeLists.txt`) or no
existing `build` directory in the checkout, so no binary tests were
executed.
------
[Codex
Task](https://chatgpt.com/codex/cloud/tasks/task_e_6a512c4481a883209d56b8e7109a91ba)
## Summary
This fixes RTMP playback audio corruption and VLC playback compatibility
when proxying some upstream RTMP streams through `addStreamProxy`. In
the reproduced case, HTTP-FLV playback was normal, while RTMP playback
had missing audio or occasional sharp noise in VLC.
## Root cause
- RTMP aggregate message parsing copied the 4-byte `PreviousTagSize`
field into the sub-message payload. This shifts the payload boundary and
can corrupt subsequent audio packets.
- `RtmpSession::onSendMedia` forwarded proxied audio/video packets with
the packet's original chunk stream id. This can make audio packets use
an unsuitable chunk id for RTMP playback.
- The RTMP play response emitted non-essential `MSG_DATA` notifications
(`|RtmpSampleAccess` and `NetStream.Data.Start`). FFmpeg tolerates
these, but VLC may expose them as an extra `Data: none` stream and
handle RTMP playback poorly.
## Changes
- Exclude `PreviousTagSize` from aggregate sub-message payloads while
still skipping it when advancing the parser cursor.
- Send audio packets on `CHUNK_AUDIO` and video packets on `CHUNK_VIDEO`
from `STREAM_MEDIA`; keep the original values for other packet types.
- Avoid sending the non-essential RTMP play data notifications before
metadata/config/media packets.
## Validation
- Built `MediaServer` locally in Debug mode.
- Proxied four live RTMP test streams via `addStreamProxy`.
- Verified local RTMP and HTTP-FLV playback expose AAC audio tracks.
- Decoded RTMP audio with `ffmpeg -xerror`; all tested streams completed
without AAC decode errors.
- Verified the VLC compatibility change removes the extra `Data: none`
stream from RTMP output while preserving Video + Audio streams.
- Built and deployed a Docker image locally with docker compose and
re-tested RTMP/FLV audio playback.
When performing a 302 redirect, if the server explicitly indicates that the connection is not a persistent connection, the current
connection should not be reused; this prevents potential failures caused
by certain servers actively closing the connection.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
