[FFmpeg-devel] [PATCH] avformat/smacker: Support seeking to first frame

[Timotej Lazar]

Andreas Rheinhardt <andreas.rheinhardt at 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