Hi Mika, On Sat, 6 Sep 2014, Raento Mika wrote:
I've been robustifying ismindex to handle the outputs we are getting from our third-party ISMV packeter. ismindex and the smooth streaming muxer do a lot of the same things, but don't share code, so my changes are not benefiting the muxer. Should we try to unify the code between the two? I could definitely for example help to test and review code, or port my fixes to the muxer if ismindex was changed to use it.
There's actually surprisingly little code they even theoretically could share - mostly writing the manifest. Since smoothstreamingenc.c is a muxer, it takes raw elementary streams, muxes them and chops them up (similar to the -split option), but with extra care for being able to play back the result as a live stream while it is being muxed as well. Contrary, ismindex.c is supposed to take ready-made ismv files and not modify their content at all.
Since smoothstreamingenc.c is within libavformat, it's not too easy to share code with outside modules except for via the public API (e.g. actually using smoothstreamingenc.c as a muxer from ismindex.c), since I've written ismindex.c to not use any private API.
Using the muxer from ismindex.c wouldn't really help much either, the muxer literally doesn't do a single thing that is necessary for the ism/ismc creation, other than actually writing the ismc file.
I'll try to have a look at your latest fix sometime soon. This one might probably also be beneficial for the muxer case, but to even end up in that situation, the ismv muxer would need to do things it doesn't do currently.
So all in all, I agree that there are (some) cases where sharing code between the two might be useful, but I don't think it's worth the effort so far, because the ratio between amount of code actually shared vs the effort for doing it really isn't big enough. So far (within the 30 months that the code has been available in the public repos) you're the first one to actually find issues that would be common to them both.
Can you share a sample file that requires the normalization fix? That'd be useful for understanding it better.
Do you know if there are any mp4 libraries we could use instead of hand-written parsing? I've successfully used Bento4 for some other packaging tasks, but that's c++ :-/.
For the current tasks I don't see much problems with hand-written parsing - the manual parsing code here are only a couple dozens of lines. If we'd rewrite the tool to use some other mp4 parser library instead, it should probably be split out to a separate individual tool repo instead. And no, unfortunately I'm not too familiar off-hand with other mp4 libraries.
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
