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?
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 :-)
>
>
>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.
>
>
>> 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
>
Mika
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
