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

Relation to libsmacker #1

Open
sskras opened this issue Jul 6, 2018 · 3 comments
Open

Relation to libsmacker #1

sskras opened this issue Jul 6, 2018 · 3 comments

Comments

@sskras
Copy link

sskras commented Jul 6, 2018

It seems nice to have independent implementation, but have you ever heard about the libsmacker lib written in C? http://libsmacker.sourceforge.net/

GH mirror / fork: https://github.com/JonnyH/libsmacker

Found it some minutes ago. As both projects rely on information from multimedia.cx, have you thought about contributing to the lib or vice versa?

@mewmew
Copy link
Member

mewmew commented Jul 6, 2018

Hi @sskras!

It seems nice to have independent implementation, but have you ever heard about the libsmacker lib written in C? http://libsmacker.sourceforge.net/

libsmacker seem like a great resource, especially for implementation in C/C++ game engines. We've not looked at libsmacker specifically, but we've previously looked at the FFMPEG sources for Smacker decoding:

https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/smacker.c

Found it some minutes ago. As both projects rely on information from multimedia.cx, have you thought about contributing to the lib or vice versa?

I would believe that libsmacker is feature complete? Thus, we'll probably keep implementing the Smacker decoder mostly independently, and then use it to cross-validate the implementations. If something differs we'll try to open up issues for either libsmacker or FFMPEG. As such, we'll try to refrain from looking at the source code, at least to start with :)

As with most projects, this is for educational purposes and to have fun.

In the end, I think it makes most sense to convert the *.SMK videos to modern file formats with open specifications, and then use decoders for these to implementing video playback in Devilution for instance, as indicated by @galaxyhaxz in diasurgical/devilution#17 (comment)

I think once we get Diablo running on linux, we could make a script which will convert all assets in the MPQ to open source formats. The script could use the Rad tools to convert the .smk to an open source format. Then repack everything back up into a .zip format, so we don't need the MPQ library at all!

@sskras
Copy link
Author

sskras commented Jul 20, 2019

BTW, the FFmpeg code is under LGPL license, while this project is under Unlicense. It seems to be illegal even to translate the source code into another language:
https://softwareengineering.stackexchange.com/questions/151515/rewrote-gnu-gpl-v2-code-in-another-language-can-i-change-a-license#151516

Which is a bit sad.

@mewmew
Copy link
Member

mewmew commented Jul 20, 2019

@sskras That's mostly fine I think. No code has been derived from FFmpeg. We only look at the source code in the sense that we treat it as one reference to learn about the file format specification. So, we should still be able to release the source code of this project into the public domain.

That being said, this project is on hold as other things are more exciting to explore as of current :)

Edit: for further reference, the file format specification upon which we base our understanding and implement the code for parsing these video files is located here: https://wiki.multimedia.cx/index.php?title=Smacker

Edit2: also, as noted above in #1 (comment),

As such, we'll try to refrain from looking at the source code, at least to start with :)

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

2 participants