Skip to content

Conversation

@nathanbabcock
Copy link
Owner

TL;DR: audio events will have 0 for unsupported fields. Fixes #81


This is a quick non-breaking fix, supporting parsing audio progress messages which have a slightly different format than video ones:

Video progress:

[info] frame= 1996 fps=1984 q=-1.0 Lsize=     372kB time=00:01:19.72 bitrate=  38.2kbits/s speed=79.2x

Audio progress:

[info] size=      66kB time=00:00:02.21 bitrate= 245.0kbits/s speed=1.07x

Specifically audio progress omits frame, fps, and q fields.

The most thorough and typesafe fix will be to add a dedicated AudioProgress event type with those fields omitted. That would be a breaking change in conjunction with adding #[non_exhaustive] to support future added event types.

cc @ashhhleyyy fyi

@nathanbabcock nathanbabcock requested a review from Copilot July 27, 2025 19:30
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR enables parsing of audio progress events from ffmpeg, which have a different format than video progress events. The key change is making the video-specific fields (frame, fps, and q) optional by defaulting them to 0 when not present, allowing the same parser to handle both audio and video progress messages.

  • Modified try_parse_progress function to handle missing video-specific fields
  • Added test coverage for audio progress parsing
  • Updated documentation to clarify behavior for audio-only events

@nathanbabcock nathanbabcock merged commit 54cc377 into main Aug 2, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Log parser does not emit progress events for audio-only processing

2 participants