[Ffmpeg-devel] [PATCH] flacenc - md5

[Justin Ruggles]

Hello,

Regarding the organization/writing of the extradata, first of all, I am
now convinced of the craziness of the FLAC file format design. :)  I
have not been nearly as up-to-snuff on the lavf side of FFmpeg as I am
with lavc, so I've done a bit of code studying.

The format which raw FLAC seems to be closest to is ADTS, which just has
a small header followed by raw frames.  But FLAC has what can be a
fairly large header with incomplete information at the time of writing.

My first thought is that it might be a better solution to put the
FLAC-specific raw format encoding in a separate file similar to what is
done with adtsenc.c, mainly to keep raw.c cleaner.

Also, I am leaning toward a mixed-solution for what the muxer does and
what the encoder does regarding the header.  The encoder really only
needs to write the bare essentials when it comes to metadata, which is
just the streaminfo block.

The raw flac muxer can write the the other blocks such as vorbiscomment,
padding, and seektable, without any information at all from the encoder.
 It is also uniquely suited to write the vorbiscomment block because it
has access to the tag information (album, title, etc..).

The muxer can parse through the extradata to determine which metadata
blocks are present & which it may need to append.  Luckily, the order of
the metadata blocks does not matter except that the streaminfo must be
first.  This way the user could also optionally add, for example, a
cuesheet or a very detailed vorbiscomment to the extradata before
writing the header.

There is still the issue of updating the MD5 and sample count at the end
of encoding.  I think I might be able to move the sample count part to
the muxer by calculating it from some combination of packet duration,
packet pts, and codec sample_rate?...if this sounds wrong or overly
complex let me know.

The MD5 checksum does have to be generated in the encoder though since
it would be quite rediculous to have the muxer decode each packet just
to calculate the checksum. :(  Also, it seems like not writing the MD5
or sample count in any muxers except for raw FLAC might be the best
option.  Even in the FLAC muxer it is still somewhat sketchy to assume
the extradata can be used at the end of encoding.  Maybe a different
solution could be to add "uint8_t md5sum[16]" to AVCodecContext or even
something more generic like "checksum[32]" so that the hash algorithm
could be codec-specific and use more than 128-bits if the need ever
arises...

Thoughts? Comments?

-Justin