Closed brycefisher closed 6 years ago
Done.
Note that mkv.rs
is my first Rust project, started before Rust 1.0 and never refactored. Also it is incomplete - looking inside Blocks/SimpleBlocks to extract actual data and timestamps is not implemented yet. So that it may be sub-par choice for the job.
If you are interested in it the development can be revitalized although. The first step would be re-design to use nom
and friends (and proper Result and so on). If you have some specific use case in mind, it can be done earlier.
So cool! Thank you, Thank you!
I would really like to parse the binary content inside Blocks/SimpleBlocks, actually; my use case would be trying to feed data in libvpx and do some decoding (if I can figure out the public API).
I'm sort of on the fence about trying to contribute a PR to this repo that migrates the parsing to nom
-- I have some time this week, but that sounds like a potential major refactor of this crate. How much thought have you given how using nom would work in this crate? What do you want to see in terms of tests / code style? How much time do you have to review PRs this week?
I already have a bit of nom
-based implementation (published into new branch ng) that reads EBML numbers and element headers.
According to the plan, nom
should have a limited use for parsing mkv: nom parsers are expected to be mostly stateless (which does not work well for matroska) and data returned by each nom-style function should be small (it should be cheap to discard it and re-parse if needed). So Nom things are lowest-level things.
My current view of the architecture layers is like this:
Turning the Matroska event stream back into mkv files is typically simpler and provided as a bonus.
If you want to contribute and especially ready to do the rewrite based on principles above, I can provide some mentoring, both about Rust and about Matroska format. Trying to incrementally improve current legacy code may be counterproductive (not sure).
You can also ask me to join in if you want to publish your independent crate for this.
I've read through about half the commits in that branch, and it seems totally awesome. I'd love to hunker down and contribute to this library as much as I can until Friday!
My original goal was just to decode a single keyframe using only rust from a real webm file, but I think contributing to the refactoring effort here would be a very valuable use of my time and help me learn a great deal about both Rust and Matroska in a short period of time. I'll let go of the "re-implement (some of) VP9" goal.
I also think there's a much higher chance of producing code that might actually be useful by contributing directly to this crate VS creating a higher level crate that's try to bolt features on top of the existing code here.
If that sounds good to you as well, what could feature would be helpful to implement next in that branch? (I imagine I'd do PRs against the ng
branch.) Also, do you prefer to communicate in a different way? I'm happy to IRC, Slack, Telegram or keep colaborating on github.
EDIT How close are you to merging the ng
branch into master OR are you planning to just make a new crate here?
I'm cooking a quick&dirty frame extractor based on current (unrefactored) mkv
now specially for you.
Woot!! Thanks!!
On Jan 9, 2018 5:49 PM, "Vitaly Shukela" notifications@github.com wrote:
I'm cooking a quick&dirty frame extractor based on current (unrefactored) mkv now specially for you.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vi/mkv.rs/issues/1#issuecomment-356440118, or mute the thread https://github.com/notifications/unsubscribe-auth/AANbyiKXSpQlYh2lk89oSn44z-8tpsnBks5tI-0PgaJpZM4RYQAZ .
Done, also published 0.0.7 for this. Example:
frame ts=0 tn=1 len=6614 0019d365...
frame ts=0 tn=2 len=1399 044116c0...
frame ts=0.033 tn=1 len=1133 00046a41...
frame ts=0.067 tn=1 len=1518 0005eb41...
Hooray! That's awesome. Thank you! So, do you happen to know how I could feed this into libvpx to decode those frames? I've been trying to port https://chromium.googlesource.com/webm/libvpx/+/master/examples/simple_decoder.c and having no luck.
(Also this issue is actually closed!! And in record time. You're amazing @vi !)
What are you trying? Are you using the vpx crate?
Maybe you should first write an example that decodes a single hard coded frame (not taked from any file)?
@brycefisher , Note: there is also https://github.com/rust-av/matroska now. Does it work for you?
Unfortunately, this means I can't run the dom_dumper.rs example because some of the method signatures have diverged since version 0.0.5 was published.
Would you mind pushing the latest changes to crates.io as a v0.0.6? Thanks so much!!