On Sat, 6 Sep 2014, Raento Mika wrote:
On 06/09/14 18:19, "Martin Storsjö" <[email protected]> wrote:
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.
Thanks for the detailed explanation. I agree that a lot of the code is
different and sharing would be non-trivial.
I'm not too familiar with architectural policies for libac, but would it be
possible to split out code a .c file that is included into both the lib
and ismindex.c?
Yes, that would probably be one way of sharing at least some code. I don't
think there's any existing case of such sharing between the tools though.
Since the build system (as far as I know) doesn't allow linking in more
than one .c file (plus the libs) when building a "tool", it would probably
have to be a .c file containing static functions, included in ismindex.c.
As an example, parse_fragment in smoothstreamingenc.c could be used in
ismindex
to figure out actual durations for segments (instead of relying on the
stream to be continuous/not outputting discontinuities).
I also tried to feed some of my files into the muxer, which choked on them
the same way ismindex used to :-)
Ok, fair point ;-)
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.
I agree that this would be useful. The inputs are copyrighted (as I guess
is
typical) and cutting them is annoying as they are broken and hard to get
tools
to handle them well. I'll talk to some of our other guys to see what I
could
do.
Ok - that's a quite usual case I guess. If it helps, you can share it with
me privately (although e.g. signing an NDA or something for it feels a
little like overkill - in most similar cases people just promise to not
share it). And if you have access to the tool that can produce such broken
files you could try creating more files with some more shareable content.
If I understand the issue properly, I could probably create a similar file
by taking an ismv file and dropping a few fragments from the middle? That
shouldn't be too hard to create myself I guess.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
