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. > 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. 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. > 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. 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 _______________________________________________ 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".
