[FFmpeg-devel] [PATCH v2] avformat/movenc: properly handle cover image codecs
Timo Teras
timo.teras at iki.fi
Sat Jun 2 03:35:33 EEST 2018
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:
AV_DISPOSITION_ATTACHED_PIC | AV_DISPOSITION_TIMED_THUMBNAILS
- cover image in the metadata given out as
AV_DISPOSITION_ATTACHED_PIC
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.
Timo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180602/b7eddd82/attachment.sig>
More information about the ffmpeg-devel
mailing list