Michael Niedermayer [EMAIL PROTECTED] added the comment:
On Mon, Mar 31, 2008 at 10:30:35PM +, Aurelien Jacobs wrote:
[...]
It seems it's not really realated to matroska itself.
It seems to be due to generic ffmpeg conversion code behaving
differently when having one added unknown stream that he just
drop during the conversion. Maybe it still try to do some
synchronization or some timestamps handling with the dropped
stream ?
Anyway, just adding those lines in any demuxer should be
enough to trigger the bug in ffmpeg:
st = av_new_stream(s, id);
st-codec-codec_type = CODEC_TYPE_ATTACHMENT;
with
Index: libavformat/avidec.c
===
--- libavformat/avidec.c(revision 13251)
+++ libavformat/avidec.c(working copy)
@@ -608,6 +608,17 @@
if(avi-non_interleaved)
clean_index(s);
+st = av_new_stream(s, stream_index);
+if (!st)
+goto fail;
+
+ast = av_mallocz(sizeof(AVIStream));
+if (!ast)
+goto fail;
+st-priv_data = ast;
+st-codec-codec_type = CODEC_TYPE_ATTACHMENT;
+
+
return 0;
}
theres an attachment:
ffmpeg -i in.avi test.avi
...
Stream #0.0: Video: mpeg4, yuv420p, 320x240 [PAR 1:1 DAR 4:3], 30.00 tb(r)
Stream #0.1: Audio: pcm_s16le, 44100 Hz, stereo, 1411 kb/s
Stream #0.2: Attachment: 0x
...
frame= 300 fps=102 q=29.0 Lsize= 531kB time=9.98 bitrate= 436.0kbits/s
video:426kB audio:78kB global headers:0kB muxing overhead 5.391923%
but
e8f4026f798cdf423764d2a05df58ad1 test.avi
e8f4026f798cdf423764d2a05df58ad1 test-old.avi
so i cannot reproduce an issue with avi and fake attachments
[...]
__
FFmpeg issue tracker [EMAIL PROTECTED]
https://roundup.mplayerhq.hu/roundup/ffmpeg/issue412
__
