[FFmpeg-devel] [PATCH v2] avformat/movenc: properly handle cover image codecs

Michael Niedermayer michael at niedermayer.cc
Sat Jun 2 13:14:42 EEST 2018

On Sat, Jun 02, 2018 at 03:35:33AM +0300, Timo Teras wrote:
> On Sat, 2 Jun 2018 02:15:29 +0300
> Timo Teras <timo.teras at iki.fi> wrote:
> > On Sat, 2 Jun 2018 00:46:30 +0200
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > 
> > > input can be found here:
> > > https://guiltyfeminist.libsyn.com/97-repeal-the-eighth-with-helen-linehan  
> > 
> > This has been broken all time, I think. It'll work correct with the
> > patch if you add "-c copy" to preserve the cover image codecs.
> Actually this file is more complicated. Seems theres:
>  - video track which the chapter track refers, so they are in fact
>    timed chapter marker images. mov demux gives them out as:
>  - cover image in the metadata given out as
> As the original cover image just checks for AV_DISPOSITION_ATTACHED_PIC
> bit, it broke this by treating the AV_DISPOSITION_ATTACHED_PIC |
> AV_DISPOSITION_TIMED_THUMBNAILS streams as cover image too. Seems
> closer scrutiny is needed to the disposition bits.
> I wonder if we should test ==AV_DISPOSITION_ATTACHED_PIC or check that
> specific set of bits match?
> Though, I believe with the problem with this input file go away if we
> treat attached_pic|timed_thumbnail combo as before. In fact, after
> testing, then the conversion will just turn it to regular video track,
> and without the -t 1 will FAIL for other reasons. This is how pre-4.0
> works too with this input file.
> Basically we just don't support properly muxing the
> AV_DISPOSITION_TIMED_THUMBNAILS streams currently, and thus the input
> file in question is not really handled right at all.
> > I wonder what the right thing to do would be?
> > a) not auto-map any attached_pic video streams
> > b) make ffmpeg by default just copy (not transcode) attached_pic
> > c) allow AVOutputFormat to communicate default codec based on
> >    disposition
> > d) have movenc ignore/warn about cover images in incorrect format
> > e) something else?
> This question is still valid.

well, ultimatly
ffmpeg should act close to what a inteligent user expects.
For example a simple ffmpeg -i inputfile outputfile
should produce a outputfile that results in similar presentation as the input
when played.
In respect to AV_DISPOSITION_TIMED_THUMBNAILS, one may expect that
concatenation of files each with a single AV_DISPOSITION_ATTACHED_PIC

behavior should be logic, predictable, simple. A user should be
able to predict what ffmpeg will do so she can adjust parameters without
much trial and error.
It may be good to minimize the amount of exceptions for how streams are


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180602/5b29ae97/attachment.sig>

More information about the ffmpeg-devel mailing list