You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my particular use case of this library, we don't need the seeking headers or durations that are normally written on finalization, so we should be able to use a writer that doesn't support seeking.
This will require some changes on the -sys side to support passing nullptr for get_position/set_position seek-related functions, as well as an alternative constructor for Writer. If an API break is okay, then it may be best to remove Writer::new(), and have Writer::from_seekable() and Writer::from_non_seekable() instead. If we want to avoid an API break, I think it'd be acceptable to consider the seekable one "blessed" with Writer::new() and just add a Writer::from_non_seekable().
I don't mind contributing these changes myself (once I'm ready to do so on my end), but I wanted to know what you guys thought about the API break. If we do plan to do it, we could probably lump it in the same major version bump as the change proposed in #14.
The text was updated successfully, but these errors were encountered:
In my particular use case of this library, we don't need the seeking headers or durations that are normally written on finalization, so we should be able to use a writer that doesn't support seeking.
This will require some changes on the
-sys
side to support passingnullptr
forget_position
/set_position
seek-related functions, as well as an alternative constructor forWriter
. If an API break is okay, then it may be best to removeWriter::new()
, and haveWriter::from_seekable()
andWriter::from_non_seekable()
instead. If we want to avoid an API break, I think it'd be acceptable to consider the seekable one "blessed" withWriter::new()
and just add aWriter::from_non_seekable()
.I don't mind contributing these changes myself (once I'm ready to do so on my end), but I wanted to know what you guys thought about the API break. If we do plan to do it, we could probably lump it in the same major version bump as the change proposed in #14.
The text was updated successfully, but these errors were encountered: