Description of problem: Original netpbm 10.27 included in FC4 worked well for me in making movies using ppmtompeg. The netpbm 10.31 form updates segfaults. Just try it. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. get a previously working set of snapshots and parameter file 2. try to make a movie with 10.31 3. Actual results: Segmentation fault Expected results: Additional info: I downgraded to fix the problem
This is fixed in 10.32 by upstream. Netpbm-10.32 should now be available in rawhide. Could you please check it fixes you problem? From my basic testing ppmtompeg doesn't crash any more. I'll release FC4 updates then, when I get a positive feedback from you. Thanks.
Could you please rebuild if for FC4 and put it in updates/testing? Rawhide version needs glibc-2.4.
Ok, testing update will be released in a while.
netpbm-10.32-0.FC4 is now built and in update queue. Please report back if that fixes your problem.
Yes, it's fixed in 10.32. Thank you. I hope to see the official update in a few days.
It's not fixed for me; I just discovered this bug today, saw this report, tried the netpbm*-10.32-0.FC4 rpms, and get the same segfault. I've only got four jpeg files, so it shouldn't be too much of a strain for it. PATTERN IBBPBBPBBPBBPBB OUTPUT /var/www/html/timelapse/movie.mpg INPUT_DIR /var/www/html/timelapse INPUT f*.jpg [001-004] END_INPUT BASE_FILE_FORMAT JPG INPUT_CONVERT * GOP_SIZE 15 SLICES_PER_FRAME 1 PIXEL HALF RANGE 2 PSEARCH_ALG LOGARITHMIC BSEARCH_ALG SIMPLE IQSCALE 1 PQSCALE 1 BQSCALE 1 REFERENCE_FRAME DECODED ASPECT_RATIO 1 FRAME_RATE 24 BIT_RATE 1024 BUFFER_SIZE 2048
Oh, and I've got a 'full' install of FC4 on i386.
Yes, reproduced the segfault with your parameter file. Tried it also with PPM files as the source of encoding and it seems like upstream fixed the segfault in case of encoding of PNM files as it doesn't segfault with netpbm-10.32 any more. However in case of JPEG encoding it segfaults so that it needs some additional fixes.
It used to be the case that ppmtompeg was very picky about the size of jpeg frames. Height and width needed be divisible by 4 or even 16, segfaulting otherwise. Since then I always make my frames 640x480. Maybe I was just day dreaming. Can you try with "very even" frames?
Ok, this is an upstream "feature". I can see it now from Fsize_note() in fsize.c, what calls Fsize_Validate(): /*===========================================================================* * * Fsize_Validate * * make sure that the x, y values are 16-pixel aligned * * RETURNS: modifies the x, y values to 16-pixel alignment * * SIDE EFFECTS: none * *===========================================================================*/ void Fsize_Validate(x, y) int *x; int *y; { *x &= ~(DCTSIZE * 2 - 1); *y &= ~(DCTSIZE * 2 - 1); } In the case of an image with dimensions that aren't integer multiples of 16 the situation is handled like this: Fsize_Validate(&Fsize_x, &Fsize_y); if ((Fsize_x==0) || (Fsize_y==0)) { fprintf(stderr,"Frame %d: size is zero!\n",id); /* exit(1); */ } so ppmtompeg goes on with image encoding even if it's sure that it's not possible by the MPEG-1 encoder implementation in ppmtompeg and accessing memory out of the frame dimensions causes the segfault...
So I patched the ppmtompeg in the way that it shows this message when one passes a JPG with wrong dimensions to ppmtompeg: image dimensions need to be integer multiples of 16 for ppmtompeg! It will occur in netpbm-10.33, which is now built in rawhide.
Could you also suggest (in the error message) a netpbm command to do that? Something like " Try 'pamcut -width %d -height %d -pad < infile > outfile'", with the %d's filled in with the next multiple of 16 size. Actually, I'd prefer an option to ppmtompeg that would do this automatically (-pad). If trying to read a pixel off the edge, substitute black. Thanks!
Warnings should be brief, preferably one line. JPEG size requirements should be mentioned in man pages. Crop/pad command belongs to tutorial. Frankly, JPEGs should be prepared correctly from the start. Cropping/padding with inevitable re-encoding will damage the quality.
netpbm-10.33-0.FC4 has been pushed for fc4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Errata works for me. I'll take the liberty of closing the bug.