Bug 185970 - netpbm-10.31's ppmtompeg segfaults where it used to work
Summary: netpbm-10.31's ppmtompeg segfaults where it used to work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: netpbm
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-20 16:21 UTC by Alexei Podtelezhnikov
Modified: 2013-07-02 23:15 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-04-09 19:50:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexei Podtelezhnikov 2006-03-20 16:21:19 UTC
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

Comment 1 Jindrich Novy 2006-03-21 12:56:18 UTC
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.

Comment 2 Alexei Podtelezhnikov 2006-03-21 13:53:19 UTC
Could you please rebuild if for FC4 and put it in updates/testing? 
Rawhide version needs glibc-2.4. 

Comment 3 Jindrich Novy 2006-03-21 14:12:32 UTC
Ok, testing update will be released in a while.

Comment 4 Jindrich Novy 2006-03-21 15:13:50 UTC
netpbm-10.32-0.FC4 is now built and in update queue. Please report back if that
fixes your problem.

Comment 5 Alexei Podtelezhnikov 2006-03-21 18:47:09 UTC
Yes, it's fixed in 10.32. Thank you. I hope to see the official update in a 
few days. 

Comment 6 Penelope Fudd 2006-03-31 07:50:41 UTC
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

Comment 7 Penelope Fudd 2006-03-31 07:51:38 UTC
Oh, and I've got a 'full' install of FC4 on i386.

Comment 8 Jindrich Novy 2006-03-31 10:30:33 UTC
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.

Comment 9 Alexei Podtelezhnikov 2006-04-05 02:09:39 UTC
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? 

Comment 10 Jindrich Novy 2006-04-05 10:45:11 UTC
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...

Comment 11 Jindrich Novy 2006-04-05 12:08:07 UTC
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.

Comment 12 Penelope Fudd 2006-04-06 05:01:23 UTC
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!

Comment 13 Alexei Podtelezhnikov 2006-04-06 15:02:07 UTC
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. 
 

Comment 14 Fedora Update System 2006-04-07 19:07:01 UTC
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.

Comment 15 Alexei Podtelezhnikov 2006-04-09 19:50:55 UTC
Errata works for me. I'll take the liberty of closing the bug. 


Note You need to log in before you can comment on or make changes to this bug.