On 07/09/14 00:38, "Martin Storsjö" <[email protected]> wrote:
>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. One version of the timestamping problem is when the start times are not (nearly) 0: [mfra] size=8+239916 [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 [0000] = time=3115917330450, moof_offset=2698, traf_number=1, trun_number=1, sample_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. > >// Martin Mika _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
