Re: [issue855] ffserver hangs when feeding it via http

Hi, On 2/19/2009 4:35 PM, Fred Eisele wrote: > Fred Eisele added the comment: > > Running wireshark I saw that there was no problem with ffmpeg as I had > presumed. > > I removed the ... from the ffserver.conf and > the > problem went away. > > Now the ffm->header = > {0x00, 0x01, 0x00, 0x1f

[issue861] Failed to decode mjpeg (bad vlc)

New submission from Rod : Backgroung : This file was created using a Kodak V1073 (10MP). Goal : Convert jpg to png Other Apps (that work) : Linux gimp : OK kuickshow : OK kview : OK GQview : OK Windows mspaint : OK ffmpeg Uncut Output : ffmpeg -i 100_0169.jpg testimg.png FFmpeg version

[issue860] Segmentation fault using command line: ffmpeg -i in -acodec copy -vcodec copy out -vcodec codec_name -newvideo

New submission from Francesco Cosoleto : Hello. GDB output attached. -- files: gdb_output messages: 4303 priority: normal status: new substatus: new title: Segmentation fault using command line: ffmpeg -i in -acodec copy -vcodec copy out -vcodec codec_name -newvideo topic: ffmpeg type:

[issue855] ffserver hangs when feeding it via http

Fred Eisele added the comment: Running wireshark I saw that there was no problem with ffmpeg as I had presumed. I removed the ... from the ffserver.conf and the problem went away. Now the ffm->header = {0x00, 0x01, 0x00, 0x1f, 0x18, 0x03, 0xd0, 0x90, 0x00, 0x04, 0x63, 0x4e, 0x64, 0xc1, 0x7b,

[issue761] aac audio issues (can't play, wrong number of channels) in out_of_box.asf

Alex Converse added the comment: Fixed as of r17466. -- status: open -> closed substatus: reproduced -> fixed FFmpeg issue tracker

[issue855] ffserver hangs when feeding it via http

Fred Eisele added the comment: In libavformat/ffmdec.c ffm_read_packet(...) The ffm is received and it appears that the header is defective. line 395 : The header does not contain one of the expected stream indexes. The following is dump of the header. (gdb) p /x ffm->header $31 = {0xf0, 0x61

[issue849] Roundup migration

Vitor added the comment: I've contacted gmane about the server change: http://article.gmane.org/gmane.discuss/12155 . FFmpeg issue tracker _

[issue849] Roundup migration

Luca Barbato added the comment: Michael Niedermayer wrote: > Michael Niedermayer added the comment: > > On Thu, Feb 19, 2009 at 07:37:41PM +, Vitor wrote: >> Vitor added the comment: >> >> I'm not subscribed to the mailing list, but no message has arrived at the >> gmane >> archive since

[issue851] problem with decoding h263

Michael Niedermayer added the comment: On Tue, Feb 17, 2009 at 09:35:38AM +, johnny lee wrote: > > New submission from johnny lee : > > hi everyone, i have a problem with decoding an h263 stream generated by a > hardware encoder (VideoJet X20 from bosch). the output is corrupted and i get

[issue849] Roundup migration

Michael Niedermayer added the comment: On Thu, Feb 19, 2009 at 07:37:41PM +, Vitor wrote: > > Vitor added the comment: > > I'm not subscribed to the mailing list, but no message has arrived at the > gmane > archive since the migration and http://live.polito.it/pipermail/ffmpeg-issues/ >

[issue849] Roundup migration

Vitor added the comment: I'm not subscribed to the mailing list, but no message has arrived at the gmane archive since the migration and http://live.polito.it/pipermail/ffmpeg-issues/ is offline. Is the ML supposed to be working? -- nosy: +Vitor1001

[issue859] munmap_chunk(): invalid pointer when encoding a 5.1 file

Erwan Lerale added the comment: Oups, the trace :) FFmpeg issue tracker er...@menhir ~ $ gdb ffmpeg GNU gdb 6.8 Copyright (C) 2008 Free

[issue859] munmap_chunk(): invalid pointer when encoding a 5.1 file

New submission from Erwan Lerale : I'm trying to encode this : Stream #0.0(eng): Video: rawvideo, yuv420p, 1920x1080, 29.97 tb(r) Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, 5.1, s16, 4608 kb/s to : Stream #0.0(eng): Video: libx264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 20

[issue858] textrel patch for amd64

New submission from sera : The patch is against svn-16916 and eliminates the textrels in libavcodec.so on x86_64. As a remark, the pure C version of FFT seems even slightly faster than the assembly versions with gcc 4.1 and "-O2 -pipe -march=k8 -msse3". Don't know about x86_32 but I guess you co

[issue806] Regression in ffplay, end of file huge memory allocation with some common files

Francesco Cosoleto added the comment: r17455-17458 fixes the reported problems with mp4, avi and flv files. Thanks Peter Ross. Unfortunately there are still problems with others files, for example: http://samples.mplayerhq.hu/Matroska/rm-in-mkv.mkv and maybe more demuxers are involved.

[issue727] License violation, DoremiLabs

thomas.p added the comment: Hello, On our next release version I will add a readme.doremi with these instructions : FFmpeg rev : Unknown. - Compiler options used by DoremiLabs to compile FFmpeg under WIN32: ./configure --enable-shared --disable-static --enable-memalign-hack --enable-w32threa

[issue857] jpg allocating too much stuff on stack?

Andreas Öman added the comment: The problem lies in mjpegdec:ljpeg_decode_rgb_scan() uint16_t buffer[32768][4]; Allocates 256k onstack. -- status: new -> substatus: new -> FFmpeg issue tracker

[issue857] jpg allocating too much stuff on stack?

aviad rozenhek added the comment: change title -- title: * Edit post * Report this post * Reply with quote jpg allocating too much stuff on stack? -> jpg allocating too much stuff on stack? FFmpeg issue tracker

[issue857] * Edit post * Report this post * Reply with quote jpg allocating too much stuff on stack?

New submission from aviad rozenhek : attached is a code sample that shows a stack overflow crash when reading jpegs. it happens when the stack is small, because for some reason jpg codec probably allocates a lot of stuff on the stack, approximately ~100kb which is quite a lot. this can be fixed