[libav-devel] tools/ismindex.c vs libavformat/smoothstreamingenc.c
mika.raento at elisa.fi
Sat Sep 6 23:52:02 CEST 2014
On 07/09/14 00:38, "Martin Storsjö" <martin at martin.st> wrote:
>On Sat, 6 Sep 2014, Raento Mika wrote:
>> On 06/09/14 18:19, "Martin Storsjö" <martin at martin.st> wrote:
>>> Hi Mika,
>>> On Sat, 6 Sep 2014, Raento Mika wrote:
>>>> I've been robustifying ismindex to handle the outputs we are getting
>>>> 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
>>>> 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
>>> 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
>> 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
>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
>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
>> 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
>> the same way ismindex used to :-)
>Ok, fair point ;-)
>>> I'll try to have a look at your latest fix sometime soon. This one
>>> probably also be beneficial for the muxer case, but to even end up in
>>> situation, the ismv muxer would need to do things it doesn't do
>>> 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
>>> 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
>>> that the code has been available in the public repos) you're the first
>>> to actually find issues that would be common to them both.
>>> Can you share a sample file that requires the normalization fix? That'd
>>> useful for understanding it better.
>> I agree that this would be useful. The inputs are copyrighted (as I
>> typical) and cutting them is annoying as they are broken and hard to get
>> to handle them well. I'll talk to some of our other guys to see what I
>Ok - that's a quite usual case I guess. If it helps, you can share it
>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
>files you could try creating more files with some more shareable content.
>If I understand the issue properly, I could probably create a similar
>by taking an ismv file and dropping a few fragments from the middle? That
>shouldn't be too hard to create myself I guess.
One version of the timestamping problem is when the start times are not
[tfra] size=12+47968, version=1
track_ID = 1
length_size_of_traf_num = 0
length_size_of_trun_num = 0
length_size_of_sample_num = 0
entry count = 2524
 = time=3115917330450, moof_offset=2698, traf_number=1,
(output from bento4's mp4dump).
The previous issue of missing data had no tfra for one of the tracks, even
though it had trak/tkhd -atoms.
I'm not terribly happy with the packager, but I don't have anything to
switch to at the moment either.
More information about the libav-devel