Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dump_markers.py returns incorrect timecode for audio markers #30

Open
mjiggidy opened this issue Nov 21, 2024 · 2 comments
Open

dump_markers.py returns incorrect timecode for audio markers #30

mjiggidy opened this issue Nov 21, 2024 · 2 comments

Comments

@mjiggidy
Copy link

From what I can tell, marker timecodes from video tracks are correctly given as sequence timecode where they occur.

From audio tracks, however, marker timecodes appear to be the offset from the beginning of the subclip they live on in the sequence, + sequence start timecode.

Apologies for the crude screenshots here, but here's an example:

image

This marker should be reported with timecode 01:10:28:09. But instead...

image

...it is listed as 01:00:01:11, which is the relative offset from the beginning of the clip in the timeline (01:11) + the timecode start of the sequence (01:00:00:00)

@mjiggidy
Copy link
Author

mjiggidy commented Dec 2, 2024

Ahah! I think I tracked it down -- the issue seems to be specifically with audio tracks which have RTAS effects applied. In this case, the audio track's component becomes an avb.trackgroups.TrackEffect track group rather than a typical avb.components.Sequence component. So instead of passing it directly into find_track_markers(), we first need to iterate over each of the trackgroup's tracks and pass those to find_track_markers().

I have it working for me, I believe, and I'll plan to submit a pull request once I test more thoroughly. But if anyone else has been struggling with this, hopefully my findings help.

@mjiggidy
Copy link
Author

mjiggidy commented Dec 7, 2024

Submitted pull request #32 to address this. Most straightforward way I could find to do this was to pull the "get components from track" logic into its own function, so that it could be recursed into if the track component is a TrackGroup. Happy to answer any questions or address any potential issues!

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

No branches or pull requests

1 participant