[FFmpeg-devel] confusing trailing metadata for mpeg frames
Michael Niedermayer
michaelni
Tue Sep 28 02:08:34 CEST 2010
On Mon, Sep 27, 2010 at 12:20:27PM -0700, David Byron wrote:
i take the liberty to skip most of your talk and patch
(they look by a factor >10 too big for what they do)
[...]
> @@ -174,8 +274,28 @@ static int mp3_read_header(AVFormatContext *s,
> static int mp3_read_packet(AVFormatContext *s, AVPacket *pkt)
> {
> int ret, size;
> + MP3Context *mp3 = s->priv_data;
> + int64_t pos;
> +
> // AVStream *st = s->streams[0];
>
> + /* If we're into the trailing metadata, don't look for a packet */
> + if (mp3->trailing_metadata_offset != -1) {
> + pos = url_ftell(s->pb);
> + av_log(s, AV_LOG_DEBUG, "%s: \"%s\": current offset: %" PRId64 ", "
> + "trailing_metadata_offset: %" PRId64 "\n", __FUNCTION__,
> + s->filename, pos, mp3->trailing_metadata_offset);
> +
> + if (pos < 0)
> + return pos;
> + if (pos >= mp3->trailing_metadata_offset) {
> + av_log(s, AV_LOG_DEBUG, "%s: \"%s\": giving up at offset: %"
> + PRId64 " due to trailing metadata\n", __FUNCTION__,
> + s->filename, pos);
> + return AVERROR_EOF;
> + }
> + }
> +
> size= MP3_PACKET_SIZE;
how could this in any form work?
you want to truncate the data but you do NOT truncate you leave size as a
constant and only check once you already have read too far
if you want to win the most buggy patch of the month award you have a good
chance for that
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100928/a1a73115/attachment.pgp>
More information about the ffmpeg-devel
mailing list