Master is ahead of latest published version on crates.io about mkv.rs

[vi]

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.

[brycefisher]

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?

[vi]

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:

• Lowest level: Parsing EBML numbers, EBML element IDs and sizes. Determining EBML element types based on looked up database. Usage of nom: yes.
• Second level: Grouping elements in small hierarchies. Flattening big elements. (Segment, Cluster, Block, BlockGroup, SimpleBlock, Attachement, etc.). Maybe corruption recovery. Usage of nom: maybe/partial.
• Third level: Producing stream of low-level events: BeginElement, ElementContent, EndElement. Maybe optionally computing DOM for SegmentInfo or Tracks. To be designed later. Usage of nom: no.
• Matroska level: Consuming the stream from Third level. Looking into SegmentInfo for TimecodeScale. Looking into Tracks for necessary info for parsing. Maybe looking at Cues/SeekHeads. Decoding Frames / delacing. Producing simplified user-consumable Matroska event stream like in my other mkv parsers: in python or in Haskell.

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.

[brycefisher]

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?

[vi]

I'm cooking a quick&dirty frame extractor based on current (unrefactored) mkv now specially for you.

[brycefisher]

Woot!! Thanks!!

…

On Jan 9, 2018 5:49 PM, "Vitaly Shukela" ***@***.***> 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 <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANbyiKXSpQlYh2lk89oSn44z-8tpsnBks5tI-0PgaJpZM4RYQAZ> .

[vi]

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...

[brycefisher]

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 !)

[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)?

[vi]

@brycefisher , Note: there is also https://github.com/rust-av/matroska now. Does it work for you?