October 2006 - ffmpeg-devel - lists.ffmpeg.org

[BUG] mpegts.c segfault
by yyymmmm＠gmail.com 23 Jan '07

23 Jan '07

Today I meet a problem with processing of one of HDTV streams. When I start ffmpeg, it crashes with segfault in mpegts.c:212 mpegts_close_filter() . Problem with parameter 'filter', it equals to 0. Routine are called from pat_cb(): 558 found: 559 mpegts_close_filter(ts, ts->pat_filter); 560 ts->pat_filter = NULL; so, here ts->pat_filter == 0. I don't know a logic of this routine, so I only added a check: if ts->pat_filter != 0, close filter, and so on. If its incorrent, people, who wrote this module, should examine it and fix. (ff passed regression tests with patch) some kind of log: $ ./ffmpeg -i /fat32-d/work/www/streams/b.mpg -vcodec copy -acodec copy -sameq -f mpegts 1 FFmpeg version SVN-r5781, Copyright (c) 2000-2004 Fabrice Bellard configuration: --disable-opts --disable-mmx --disable-iwmmxt libavutil version: 49.0.0 libavcodec version: 51.10.0 libavformat version: 50.5.0 built on Jul 25 2006 16:16:56, gcc: 3.3.6 Segmentation fault (core dumped) $ gdb ffmpeg_g core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-slackware-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". warning: core file may not match specified executable file. Core was generated by `./ffmpeg -i /fat32-d/work/www/streams/b.mpg -vcodec copy -acodec copy -sam'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/tls/libdl.so.2...done. Loaded symbols for /lib/tls/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x0809a393 in mpegts_close_filter (ts=0x83fb000, filter=0x0) at mpegts.c:212 212 pid = filter->pid; (gdb) bt #0 0x0809a393 in mpegts_close_filter (ts=0x83fb000, filter=0x0) at mpegts.c:212 #1 0x0809ac5a in pat_cb (opaque=0x83fb000, section=0x8404250 "", section_len=20) at mpegts.c:559 #2 0x0809a208 in write_section_data (s=0x83fa080, tss1=0x84030c0, buf=0xbf8d8b85 "", buf_size=183, is_start=1) at mpegts.c:150 #3 0x0809b946 in handle_packet (ts=0x83fb000, packet=0xbf8d8b80 "G@") at mpegts.c:1020 #4 0x0809bb39 in handle_packets (ts=0x83fb000, nb_packets=0) at mpegts.c:1099 #5 0x0809c5eb in mpegts_read_packet (s=0x83fa080, pkt=0x83faf90) at mpegts.c:1374 #6 0x080604c0 in av_read_packet (s=0x83fa080, pkt=0x83faf90) at utils.c:647 #7 0x08060fe9 in av_read_frame_internal (s=0x83fa080, pkt=0xbf8d9080) at utils.c:903 #8 0x08063520 in av_find_stream_info (ic=0x83fa080) at utils.c:1908 #9 0x0805be46 in opt_input_file (filename=0xbf8d95af "/fat32-d/work/www/streams/bikini.mpg") at ffmpeg.c:2853 #10 0x0805f451 in parse_options (argc=11, argv=0xbf8d92c4, options=0x8301980) at cmdutils.c:99 #11 0x0805ee3c in main (argc=11, argv=0xbf8d92c4) at ffmpeg.c:4257 (gdb) frame 1 #1 0x0809ac5a in pat_cb (opaque=0x83fb000, section=0x8404250 "", section_len=20) at mpegts.c:559 559 mpegts_close_filter(ts, ts->pat_filter); (gdb) print ts->pat_filter $1 = (MpegTSFilter *) 0x0 (gdb) print *ts $4 = {stream = 0x83fa080, raw_packet_size = 188, auto_guess = 1, set_service_ret = -1, mpeg2ts_raw = 0, mpeg2ts_compute_pcr = 0, cur_pcr = 0, pcr_incr = 0, pcr_pid = 0, stop_parse = 0, pkt = 0x83faf90, sdt_filter = 0x0, nb_services = 2, services = 0x83f1008, set_service_cb = 0x809bc2a <set_service_cb>, set_service_opaque = 0x83fb000, pat_filter = 0x0, pmt_filter = 0x0, req_sid = 2, pids = {0x84030c0, 0x0 <repeats 16 times>, 0x8405680, 0x0 <repeats 14 times>, 0x84055e0, 0x0 <repeats 448 times>, 0x8406630, 0x8406590, 0x0 <repeats 17 times>, 0x8403070, 0x8403250, 0x8405630, 0x0 <repeats 7689 times>}}

4 7

mpegts.c cleanup patch
by danielk＠cuymedia.net 23 Jan '07

23 Jan '07

This is a cleanup patch generated with a selective diff against the mythtv fork. This patch doesn't bring in any of the bug fixes in the mythtv version, it just brings over some documentation, gets rid of the definition for the mpegts crc function (which no longer exists), changes printf's to av_log's, adds a few debugging messages on non-fatal errors and changes C++ comments to C comments. -- Daniel

5 6

unable to play mpeg-4 file
by albx79＠gmail.com 23 Jan '07

23 Jan '07

hello I have a problem with ffplay not being able to display mpeg files encoded with a particular capture cards. The files should be compliant and VLC plays them correctly. The whole story is actually a bit complicated, it's all written here: http://www.albx79.it/stuff/ can somebody have a look at the files (available for download on the webpage above) and tell me what's wrong with them (or with gstreamer?) thankyou very much Is the #ffmpeg channel active? I'll try to be there as often as possible after 22.00GMT take care alberto -- ICQ#: 319420338

3 2

WMA optomisations have broken WMA decoding underBeOS
by Dennis.vanAmerongen＠nob.nl 23 Jan '07

23 Jan '07

> On 24/08/06, Luca Barbato <lu_zero at gentoo.org> wrote: > > > > > > > > Should be fixed now, make sure the buffers are aligned > > > If you mean the r6050 fixes, they don't fix it. Using r6058 here. > > Cian > > -- > ------------------------- > "We're busy running out of time" > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel at mplayerhq.hu > http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel > Ran into the same instant crash problem decoding wma samples on Windows XP using ffmpeg svn (6088) in VLC media player. Same workarounds apply: reverting to a revision before 6026 or disabling mmx altogether in the player. Using native codecs through "dmo" runs fine too. Compiled with Cygwin GCC 3.4.4-2. D

4 3

seeking in asf fails
by rbultje＠ronald.bitfreak.net 23 Jan '07

23 Jan '07

Hi guys, seeking in asf files (e.g. the wma samples on the mplayerhq samples ftp) appears to fail using a svn checkout of about a month ago (7/19). $ ~/Projects/Media/fopmed/ffmpeg/ffplay ~/Desktop/ffwma2_broken.wma Seek to 58% ( 0:02:03) of total duration ( 0:03:33) [asf @ 0x83101a0]seek failed [asf @ 0x83101a0]seek failed Cheers, Ronald

4 3

Possible bug in h264 dec
by francis_labonte＠hotmail.com 23 Jan '07

23 Jan '07

Hi, Runnning valgrind on a file, I got some invlid read. It points to: H264_CHROMA_MC8_TMPL in dsputil_h264_template_mmx.c called by mc_dir_part in h264.c In my opinion, I think it could come from here: if( full_mx < 0-extra_width || full_my < 0-extra_height || full_mx + 16/*FIXME*/ > pic_width + extra_width || full_my + 16/*FIXME*/ > pic_height + extra_height) "<" should become "<=" for the 2 FIXME. An index ( mx, my) ranging from 0-... is compared to a size ranging from 1-,,, Applying my modification fix my invalid. I would like to have have some input to know if my analysis make sens or not! Thank you Francis NOTE: I'me not using the latest version of CVS, but this line didn't change in HEAD, and a friend told me he got similar result with HEAD version.

2 1

SIGSEGV in h264.c, stream is available for debugging
by dario＠ip.tv 23 Jan '07

23 Jan '07

> > I've got a SIGSEGV decoding h264, the stream was generated by x264. > > > The following stream was recorded live and begins from the middle: > > > http://www.datscom.com.br/~dario/dump.SIGSEGV.h264 > > >the following command line reproduces the fault (the source code is updated >from cvs as of 09/05/2005 08:13pm GMT-3). > >$ ./ffmpeg -i dump.SIGSEGV.h264 -f null dump.SIGSEGV.h264.null > Has anyone got any status on that subject? Anyway, I've managed to increase the number of max reference pics (at least from what I could understand from the code), from 16 to 32 in h264.c, and it seems to help a little (the stream above now decodes to the end). btw, nice symbolic constants would be nicer than things like that spread all over the code: for (i = 0; i < 16; i++) ... Picture* delayed_pics[16]; etc... :-) The above stream now decodes ok, but the following one fails with "getbuffer() failed" and consequently (no checks for the getbuffer calls) SIGSEGV. I assume there is some leak somewhere? http://bule.ip.tv/~dario/dump.SIGSEGV.1.h264 Again, I'd appreciate any help on the subject. Regards, Dario Andrade R&D IP.TV

3 2

MP3 decoding from RTP stream. Getting "invalid new backstep"
by marthi＠graphics.cs.uni-sb.de 05 Jan '07

05 Jan '07

>>Hi, >> >>I'm using ffmpeg to encode MP3 data transmit it over RTP and decode it. >>If I start the RTP sender before the receiver I get warnings on the >>decoder side from the ffmpeg library (only at the very beginning): >> >>backstep:452, lastbuf:0 >>invalid new backstep 381 >>overread, skip -5 enddists: -4 -4 >>overread, skip -9 enddists: -1 -1 >>invalid new backstep 382 >> >>The sound is distorted as well (just for 1 second or so). Is it somehow >>possible to tell the AVParser or the decoder to discard the frames that >>leads to the distortion? > > > yes if you implement it and send a patch, and yes i fully agree that the > mp3 decoder should discard such packets instead of annoying the user > with the noise > just look at the code which outputs the error messages and silence the > output somehowm shouldnt be too hard > > [...] Hi, I'm trying to silence the distorted output now. What would you consider the best way: 1) Return a value that indicates a problem 2) Set a flag (which one?) in AVCodecContext that indicates a problem 3) Changing the buffer values to 0? Is 0 the right value for silence? Thanks, Martin

4 23

FreeBSD 6.1 amd64 and current SVN
by trilkk＠iki.fi 02 Jan '07

02 Jan '07

I tried to compile the current version with a FreeBSD-6.1-amd64 machine, and ran into some problems. First of all, the easy one. libavcodec/grab_bktr line 28 has a statement: # if __FreeBSD__ >= 502100 This tests for the ioctl_meteor.h and ioctl_bt848.h location on newer FreeBSD revisions. However, __FreeBSD__ equals 6 in 6.1, which will cause the compilation to fail. Changing the line to # if __FreeBSD__ >= 502100 || __FreeBSD__ == 6 fixes the problem. Also, search from /usr/local/include and /usr/local/lib is not enabled by default, which will cause ALL configure probes to fail, but this is probably an user (mine) error, as people should probably have -I/usr/local/include and -L/usr/local/lib in their C- and LDFLAGS. You could also add a note in the FAQ about the link order. If an user is stupid enough to issue `pkg-config --libs avcodec` and `pkg-config --libs avformat` simultaneously, this will cause the linking to fail crypticly, as -lavutil is in the command line before -lavformat. It took me quite a while to figure out I only need to check for avformat. -- -Tatu Kilappa <trilkk at iki.fi>

3 7

[PATCH] get rid of AVFrac
by Reimar.Doeffinger＠stud.uni-karlsruhe.de 26 Dec '06

26 Dec '06

Hello, since it is marked as deprecated... Does the attached path look correct to you? And would this need a version increment? Greetings, Reimar D?ffinger

4 13