feat: Expose output_media_info for transcoded streams#56
Merged
Conversation
Pairs with the m3u-editor side: surfaces what ffmpeg is *producing* (encoder codec, target resolution, muxer container) alongside the existing media_info which describes the source ffmpeg is reading. The Stream Monitor UI's existing "Stream Info" badge row reflects the input; the editor adds an "Output Info" row to render this new payload separately. The parser now tracks state — once ffmpeg's "Output #" line is observed, subsequent "Stream #N: Video|Audio:" lines populate output_media_info instead of media_info. Live progress fields (bitrate/fps) describe encoder output and are dual-written so existing Stream Info readers keep working without coupling to a coordinated client release.
ffmpeg 8.1 (linuxserver/ffmpeg:latest as of May 2026) writes "Error reading HTTP response: End of file" to stderr at the end of every HLS segment fetch — the HTTP layer closes when the segment body is exhausted and -reconnect 1 silently reopens the connection for the next segment. ffmpeg 8.0.1 didn't surface this; 8.1 does, and it tripped the existing "end of file" entry in input_error_patterns, causing the proxy to fail over every ~10 seconds during normal playback of any HLS source. Drop the bare "end of file" string. Real upstream loss is still caught by: - the more specific input patterns (connection refused, server returned 4xx/5xx, error opening input, etc. — emitted when reconnect actually fails) - the low-bitrate / silence detectors in stream_manager.py, which trigger on actual data starvation regardless of stderr. Also: extract write/input pattern lists to module-level tuples so they can be referenced by tests and don't get rebuilt per stderr-reader call.
…pose-output-media-info
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Pairs with the editor PR that adds an "Output" badge row to the Stream Monitor — m3ue/m3u-editor#1095. The existing
media_infopublishes the source ffmpeg is reading; this PR adds anoutput_media_infocounterpart describing what ffmpeg is producing (encoder codec, target resolution, muxer container, plus the live progress numbers, which are technically output stats).Also includes the fix from #55 (merged into this branch). If #55 lands first I'll rebase to drop the duplicate commit; if you'd rather have one PR, #55 can be closed in favour of this.
What changed
Parser state machine (
src/pooled_stream_manager.py)SharedTranscodingProcessgains anoutput_media_info: Dict[str, Any]and a_parsing_output: boolflag. A new_parse_ffmpeg_output_linematches the"Output #N, FORMAT, to 'TARGET':"line ffmpeg prints once per output, captures the muxer container, and flips_parsing_output = True._parse_ffmpeg_stream_linethen routes subsequentStream # ... Video|Audio: ...lines tooutput_media_infoinstead ofmedia_info._parse_ffmpeg_progresskeeps writingbitrate_kbps/fps/frame/speedtomedia_info(so the existing Stream Info row in the editor doesn't regress) and additionally mirrors them intooutput_media_infoonce the output marker has been seen.API surface (
src/stream_manager.py)A symmetrical
_get_output_media_infomirrors_get_media_infoand is included alongsidemedia_infoin the per-stream payload ofget_stats(). Empty for plain HTTP-proxy streams (no ffmpeg → no encoder side) and for resolver-backed streams (yt-dlp/streamlink).EOF fix (carried from #55)
Drops the bare
"end of file"frominput_error_patterns. ffmpeg 8.1 emitsError reading HTTP response: End of fileon every HLS segment fetch end and silently reconnects via-reconnect 1, so that line was triggering false-positive failover roughly every 10 seconds against the latestlinuxserver/ffmpeg:latest. Real upstream loss is still caught by the more specific patterns and the data-starvation detectors.Test plan
output_media_inforeturned as{}so the editor's Output row stays hiddenoutput_media_infoempty (no ffmpeg encoder)Compatibility
media_infoshape is unchanged for existing readers (progress fields still present there)output_media_infofield is additive in the API response — older editor versions ignore it