r23764 - trunk/libavformat/mov.c
Author: bcoudurier Date: Fri Jun 25 03:19:03 2010 New Revision: 23764 Log: Improve mov atom parsing debug message, print parent atom and size in decimal Modified: trunk/libavformat/mov.c Modified: trunk/libavformat/mov.c ============================================================================== --- trunk/libavformat/mov.c Fri Jun 25 00:13:52 2010 (r23763) +++ trunk/libavformat/mov.c Fri Jun 25 03:19:03 2010 (r23764) @@ -266,8 +266,8 @@ static int mov_read_default(MOVContext * a.type = get_le32(pb); } total_size += 8; - dprintf(c->fc, "type: %08x %.4s sz: %"PRIx64" %"PRIx64" %"PRIx64"\n", - a.type, (char*)&a.type, a.size, atom.size, total_size); + dprintf(c->fc, "type: %08x '%.4s' parent:'%.4s' sz: %"PRId64" %"PRId64" %"PRId64"\n", + a.type, (char*)&a.type, (char*)&atom.type, a.size, total_size, atom.size); if (a.size == 1) { /* 64 bit extended size */ a.size = get_be64(pb) - 8; total_size += 8; @@ -960,7 +960,7 @@ static int mov_read_stsd(MOVContext *c, //Parsing Sample description table enum CodecID id; int dref_id = 1; - MOVAtom a = { 0 }; + MOVAtom a = { AV_RL32("stsd") }; int64_t start_pos = url_ftell(pb); int size = get_be32(pb); /* size */ uint32_t format = get_le32(pb); /* data format */ @@ -2366,7 +2366,7 @@ static int mov_read_header(AVFormatConte MOVContext *mov = s->priv_data; ByteIOContext *pb = s->pb; int err; - MOVAtom atom = { 0 }; + MOVAtom atom = { AV_RL32("root") }; mov->fc = s; /* .mov and .mp4 aren't streamable anyway (only progressive download if moov is before mdat) */ @@ -2430,7 +2430,7 @@ static int mov_read_packet(AVFormatConte if (!sample) { mov->found_mdat = 0; if (!url_is_streamed(s->pb) || - mov_read_default(mov, s->pb, (MOVAtom){ 0, INT64_MAX }) < 0 || + mov_read_default(mov, s->pb, (MOVAtom){ AV_RL32("root"), INT64_MAX }) < 0 || url_feof(s->pb)) return AVERROR_EOF; dprintf(s, "read fragments, offset 0x%llx\n", url_ftell(s->pb));
bcoudurier <subversion <at> mplayerhq.hu> writes:
- MOVAtom a = { 0 }; + MOVAtom a = { AV_RL32("stsd") };
Using icc 12.0 Beta leads to a segfault now: (gdb) r -i tests/data/acodec/alac.m4a FFmpeg version SVN-r25148, Copyright (c) 2000-2010 the FFmpeg developers built on Sep 21 2010 00:30:52 with icc 1200 configuration: --cc=/opt/intel/composerxe-2011.0.048/bin/intel64/icc libavutil 50.27. 0 / 50.27. 0 libavcore 0. 9. 0 / 0. 9. 0 libavcodec 52.89. 0 / 52.89. 0 libavformat 52.78. 5 / 52.78. 5 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter 1.39. 0 / 1.39. 0 libswscale 0.11. 0 / 0.11. 0 Program received signal SIGSEGV, Segmentation fault. mov_read_header (s=0x7fffffffd490, ap=0x7fffffffd9c0) at libavformat/mov.c:2390 2390 MOVAtom atom = { AV_RL32("root") }; (gdb) bt full #0 mov_read_header (s=0x7fffffffd490, ap=0x7fffffffd9c0) at libavformat/mov.c:2390 mov = 0x154e510 pb = 0x1556520 atom = {type = 0, size = 0} #1 0x00000000004c66b2 in av_open_input_file (ic_ptr=0x7fffffffd490, filename=0x7fffffffd9c0 "", fmt=0x0, buf_size=22340880, ap=0x78) at libavformat/utils.c:607 probe_data = {filename = 0x7fffffffe27b "tests/data/acodec/alac.m4a", buf = 0x0, buf_size = 0} pb = 0x1556520 logctx = 0x154d470 #2 0x0000000000412ca2 in opt_input_file (filename=0x7fffffffd490 "") at ffmpeg.c:3172 ic = 0x154d470 params = {time_base = {num = 0, den = 0}, sample_rate = 44100, channels = 1, width = 0, height = 0, pix_fmt = PIX_FMT_NONE, channel = 0, standard = 0x0, mpeg2ts_raw = 0, mpeg2ts_compute_pcr = 0, initial_pause = 0, prealloced_context = 1, video_codec_id = CODEC_ID_NONE, audio_codec_id = CODEC_ID_NONE} file_iformat = 0x0 rfps = 0 rfps_base = -7557 timestamp = 0 #3 0x000000000041c661 in parse_options (argc=-11120, argv=0x7fffffffd9c0, options=0x0, parse_arg_function=0x154e510) at cmdutils.c:179 bool_val = 114 opt = 0x78 <Address 0x78 out of bounds> arg = 0x154e510 "" po = 0x0 #4 0x0000000000405265 in main (argc=-11120, argv=0x7fffffffd9c0) at ffmpeg.c:4325 ti = 5 (gdb) disass $pc-47 $pc+32 Dump of assembler code from 0x470fea to 0x471039: 0x0000000000470fea <mov_read_header+0>: push %r13 0x0000000000470fec <mov_read_header+2>: push %r14 0x0000000000470fee <mov_read_header+4>: push %r15 0x0000000000470ff0 <mov_read_header+6>: push %rbx 0x0000000000470ff1 <mov_read_header+7>: sub $0x18,%rsp 0x0000000000470ff5 <mov_read_header+11>: mov %rdi,%r14 0x0000000000470ff8 <mov_read_header+14>: mov $0x0,%rax 0x0000000000471002 <mov_read_header+24>: lea (%rsp),%rdi 0x0000000000471006 <mov_read_header+28>: stos %rax,%es:(%rdi) 0x0000000000471008 <mov_read_header+30>: stos %rax,%es:(%rdi) 0x000000000047100a <mov_read_header+32>: movsbl 0x6fb0b7(%rip),%eax # 0xb6c0c8 0x0000000000471011 <mov_read_header+39>: mov 0x18(%r14),%r13 0x0000000000471015 <mov_read_header+43>: mov 0x20(%r14),%rbx 0x0000000000471019 <mov_read_header+47>: mov (%rax),%edx 0x000000000047101b <mov_read_header+49>: mov %r14,0x0(%r13) 0x000000000047101f <mov_read_header+53>: mov %edx,(%rsp) 0x0000000000471022 <mov_read_header+56>: cmpl $0x0,0x54(%rbx) 0x0000000000471026 <mov_read_header+60>: jne 0x471037 <mov_read_header+77> 0x0000000000471028 <mov_read_header+62>: mov %rbx,%rdi 0x000000000047102b <mov_read_header+65>: callq 0x43ab50 <url_fsize> 0x0000000000471030 <mov_read_header+70>: mov %rax,0x8(%rsp) 0x0000000000471035 <mov_read_header+75>: jmp 0x471046 <mov_read_header+92> 0x0000000000471037 <mov_read_header+77>: mov $0x7fffffffffffffff,%rax End of assembler dump. (gdb) info registers rax 0x72 114 rbx 0x1556520 22373664 rcx 0x154e510 22340880 rdx 0x0 0 rsi 0x7fffffffd9c0 140737488345536 rdi 0x7fffffffd490 140737488344208 rbp 0x7fffffffe27b 0x7fffffffe27b rsp 0x7fffffffd480 0x7fffffffd480 r8 0x78 120 r9 0xb1f611 11662865 r10 0x0 0 r11 0xb1f332 11662130 r12 0x7fffffffda00 140737488345600 r13 0x154e510 22340880 r14 0x154d470 22336624 r15 0x7fffffffd9c0 140737488345536 rip 0x471019 0x471019 <mov_read_header+47> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 fctrl 0x37f 895 fstat 0x0 0 ftag 0xffff 65535 fiseg 0x0 0 fioff 0x0 0 foseg 0x0 0 fooff 0x0 0 fop 0x0 0 mxcsr 0x9fe4 [ ZE PE DAZ IM DM ZM OM UM PM FZ ] I opened an Intel issue report, but is there any chance that is is not the compilers fault? Carl Eugen
Hi Carl Eugen, On 09/20/2010 04:42 PM, Carl Eugen Hoyos wrote:
bcoudurier<subversion<at> mplayerhq.hu> writes:
- MOVAtom a = { 0 }; + MOVAtom a = { AV_RL32("stsd") };
Using icc 12.0 Beta leads to a segfault now:
[...]
I opened an Intel issue report, but is there any chance that is is not the compilers fault?
I honestly don't know, if people that know better could advise that would be great. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org
Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:
Hi Carl Eugen,
On 09/20/2010 04:42 PM, Carl Eugen Hoyos wrote:
bcoudurier<subversion<at> mplayerhq.hu> writes:
- MOVAtom a = { 0 }; + MOVAtom a = { AV_RL32("stsd") };
Using icc 12.0 Beta leads to a segfault now:
[...]
I opened an Intel issue report, but is there any chance that is is not the compilers fault?
I honestly don't know, if people that know better could advise that would be great.
How can one obtain the icc 12 beta? I'd like to test it, but the intel website is less than helpful. -- M?ns Rullg?rd mans at mansr.com
M?ns Rullg?rd <mans <at> mansr.com> writes:
How can one obtain the icc 12 beta? I'd like to test it, but the intel website is less than helpful.
I don't know but I suspect I received the invitation for opening several bug reports. Can you comment on the assembly? Carl Eugen
Carl Eugen Hoyos <cehoyos at ag.or.at> writes:
M?ns Rullg?rd <mans <at> mansr.com> writes:
How can one obtain the icc 12 beta? I'd like to test it, but the intel website is less than helpful.
I don't know but I suspect I received the invitation for opening several bug reports.
So it's by invitation only...
Can you comment on the assembly?
Not really. All I can offer is to put it on FATE. -- M?ns Rullg?rd mans at mansr.com
participants (4)
-
baptiste.coudurier＠gmail.com -
cehoyos＠ag.or.at -
mans＠mansr.com -
subversion＠mplayerhq.hu