Timotej Lazar: > Andreas Rheinhardt <andreas.rheinha...@gmail.com> [2020-06-28 15:32:05+0200]: >> Moreover, I have a patchset for the Smacker demuxer [1] and you seem to >> know a lot about Smacker, so you might take a look. > > Thanks for the feedback! I don’t really know much about Smacker beyond > what I discovered while trying to get rewinding to work. That said, your > patches look good to me – while working on my patch I was wondering > about several issues you addressed, such as buffering audio packets. > Thanks for the review and confirmation.
>> In particular, I don't know if Smacker supports sparse tracks where >> the gaps between points where a track has data is filled by data >> from other tracks > > The description of the “Start mixing at what frame” setting¹ leads me > to believe that all audio tracks are “complete”, padded with silence > if necessary – at least when created with RAD tools. The same page > hints that multiple audio tracks were intended to be used simply as an > alternative to having a separate video file for each language. > That's good to hear. No need to worry about something that likely doesn't exist. > While there might be some program-specific extensions to do what you > describe (online docs also mention the possibility of using audio tracks > to store other data), I don’t think ffmpeg could or should support them. > >> Furthermore, do you have samples with PCM data as audio? > > I found no such files, the games I looked at use either smacker- or > bink-compressed audio. I was also not able to produce a file with > uncompressed audio using RAD tools. The libsmacker decoder² does what > you (and the MultimediaWiki) suggest, only reading UnpackedLength for > compressed audio tracks, so we should probably do the same. > I'll implement it. >> But in a seeking function you should perform the seek yourself, so >> that you can check whether the seek was successfull or not. > > Once your patches are merged, is it OK to redo the seek patch with the > changes you suggest? Not sure if supporting only seeks to beginning is > generally considered OK for ffmpeg. > It fixes something, i.e. ffmpeg's stream_loop option works with your patch, so I don't see a reason why it should not be applied. I'll update your patch (with your authorship retained) when I have implemented the PCM duration. > Finally, I’m not sure how to handle ring frames – the last frame of a > Smacker video can be a “ring frame”, which is visually identical to the > first frame and is intended to be used with looping videos. > > Libsmacker automatically loops a video indefinitely when a ring frame is > detected, skipping the first frame on all but the first iteration. This > doesn’t seem to fit well with ffmpeg. Another option would be to seek to > the second frame (only) when rewinding from the last frame. Or we could > simply ignore the ring frame. > > ¹ http://www.radgametools.com/binkhmas.htm > ² https://sourceforge.net/p/libsmacker/code/HEAD/tree/trunk/smacker.c#l1052 Not sure how (or if) to handle this. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
