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

Andreas Rheinhardt andreas.rheinhardt at gmail.com
Fri Jul 3 03:25:36 EEST 2020


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


More information about the ffmpeg-devel mailing list