[FFmpeg-devel] [PATCH v2] avformat/movenc: support writing iTunes cover image

Rostislav Pehlivanov atomnuker at gmail.com
Tue Apr 17 02:01:42 EEST 2018


On 16 April 2018 at 15:05, Timo Teras <timo.teras at iki.fi> wrote:

> On Mon, 16 Apr 2018 10:53:43 -0300
> James Almer <jamrial at gmail.com> wrote:
>
> > On 4/14/2018 3:32 PM, Timo Teräs wrote:
> > > Fixes https://trac.ffmpeg.org/ticket/2798
> > >
> > > This makes movenc handle AV_DISPOSITION_ATTACHED_PIC and write
> > > the associated pictures in iTunes cover atom. This corresponds
> > > to how 'mov' demuxer parses and exposes the cover images when
> > > reading.
> > >
> > > Most of the existing track handling loops properly ignore
> > > these 'virtual streams' as MOVTrack->entry is never incremented
> > > for them. However, additional tests are added as needed to ignore
> > > them.
> > >
> > > Tested to produce valid output with:
> > >   ffmpeg -i movie.mp4 -i thumb.jpg -disposition:v:1 attached_pic \
> > >          -map 0 -map 1 -c copy movie-with-cover.mp4
> > >
> > > The cover image is also copied correctly with:
> > >   ffmpeg -i movie-with-cover.mp4 -map 0 -c copy out.mp4
> > >
> > > AtomicParseley says that the attached_pic stream is properly
> > > not visible in the main tracks of the file.
> > >
> > > Signed-off-by: Timo Teräs <timo.teras at iki.fi>
> > > ---
> > > v2:
> > > - Store the image in MOVTrack->cover_image instead of
> > >   AVStream->attached_pic per review request
> >
> > This is failing when i try to mux a jpg as cover art into m4a (Ipod
> > muxer). It complains about missing codec tag for mjpeg. Is the covr
> > atom valid for that format?
>
> Yes, it's valid for m4a.
>
> > Adding an entry to codec_ipod_tags[] may fix it, but that alone would
> > probably then allow non cover art video tracks using that codec,
> > which i assume is undesirable.
>
> For audio formats, e.g. mp3, query codec returns MKTAG('A', 'P', 'I',
> 'C') to indicate that the image works only as attached picture.
>
> But even for video formats, it would be nice if query codec can
> properly tell which image formats it does based on disposition. The
> codec list for cover images is different from generic video streams.
>
> Any suggestions how to do that properly?
>
> Timo
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

What's the problem with doing what mp3 does?


More information about the ffmpeg-devel mailing list