[FFmpeg-devel] [PATCH] [RFC] avformat/movenc: support writing iTunes cover image
Michael Niedermayer
michael at niedermayer.cc
Sun Apr 1 03:01:25 EEST 2018
On Sat, Mar 31, 2018 at 09:54:01AM +0300, Timo Teras wrote:
> Hi
>
> On Sat, 31 Mar 2018 02:13:14 +0200
> Michael Niedermayer <michael at niedermayer.cc> wrote:
>
> > On Thu, Mar 29, 2018 at 09:45:13AM +0300, 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.
> > [...]
> >
> > > @@ -5480,6 +5529,24 @@ static int mov_write_packet(AVFormatContext
> > > *s, AVPacket *pkt) if (!pkt) {
> > > mov_flush_fragment(s, 1);
> > > return 1;
> > > + } if (s->streams[pkt->stream_index]->disposition &
> > > AV_DISPOSITION_ATTACHED_PIC) {
> >
> > The if() should be in the next line or it should be a else if
> > it looks like someone forgot a "else" even though it makes no
> > difference here.
>
> Thanks. Will fix this, and have few other minor cleanups too. Will
> resend, but I have additional questions/notes too:
>
> I think I will audit all for (...; ... < mov->nb_streams; ...) loops
> to see if they need to skip these attachments. In most cases it's
> implicitly done because they don't get track->entry incremented now.
> However, there might be few off especially with empty_moov flag.
>
> Wondering also if all those "track->entry <= 0" checks should be made
> to static inline function mov_track_has_data() or similar?
sounds like a good idea
>
> Any comments if the patch should be split e.g. adding the attached_pic
> flag on it's own?
yes, that certainly should be split into a seperate patch
>
> Or if the code in mov_write_packet() to stuff the received data to the
> buffers should be in generic code, or made a helper function?
If it can be shared it could be in common code. yes
>
> And finally, should the codec tag/type negotiation code somehow be
> updated to recognize attachment_pic and accept only the valid three
> image formats supported for now? If yes, how to do it?
>
> Thanks,
> Timo
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/20180401/00d5242f/attachment.sig>
More information about the ffmpeg-devel
mailing list