[GRASS-dev] OSX FFMPEG build instructions available

GRASS GIS GRASS GIS developer
1

I finally got back to FFMPEG on OSX. It went fairly smooth this time. I added build instructions to the GRASS OSX readme. My future OSX builds will now have ffmpeg support, yay!

Question: what is the minimum needed in the ffmpeg libraries for GRASS? I'm thinking of disabling codecs and formats that GRASS can't use to reduce the library size (a basic universal build without debug symbols added ~6.5MB to libgrass_ogsf!). Or can GRASS use any codec available in ffmpeg?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro

2

William Kyngesburye wrote:

I finally got back to FFMPEG on OSX. It went fairly smooth this
time. I added build instructions to the GRASS OSX readme. My future
OSX builds will now have ffmpeg support, yay!

Question: what is the minimum needed in the ffmpeg libraries for
GRASS? I'm thinking of disabling codecs and formats that GRASS can't
use to reduce the library size (a basic universal build without debug
symbols added ~6.5MB to libgrass_ogsf!). Or can GRASS use any codec
available in ffmpeg?

It only uses MPEG-1. There's a compile-time option to use XviD, but
that gives you a "raw" XviD stream (no AVI etc container), which isn't
much use.

--
Glynn Clements <glynn@gclements.plus.com>

3

On Mon, 2007-10-22 at 19:54 +0100, Glynn Clements wrote:

William Kyngesburye wrote:

> I finally got back to FFMPEG on OSX. It went fairly smooth this
> time. I added build instructions to the GRASS OSX readme. My future
> OSX builds will now have ffmpeg support, yay!
>
> Question: what is the minimum needed in the ffmpeg libraries for
> GRASS? I'm thinking of disabling codecs and formats that GRASS can't
> use to reduce the library size (a basic universal build without debug
> symbols added ~6.5MB to libgrass_ogsf!). Or can GRASS use any codec
> available in ffmpeg?

It only uses MPEG-1. There's a compile-time option to use XviD, but
that gives you a "raw" XviD stream (no AVI etc container), which isn't
much use.

I have attached a patch for gsd_img_mpeg.c (ogsf) which is based on the
later releases of ffmpeg (output_example.c). This uses a function
guess_format to guess the format based upon the file extension given. If
the format is unknown it reverts to mpeg1. With this patch you can save
to any (almost) format supported by ffmpeg. For example you can save to
asf, avi, flv, swf, etc. To use this with nviz the auto name extension
in panel_kanimator.tcl will have to be commented out ...

# if { [string compare $fnameExt ".mpg"] != 0 &&
# [string compare $fnameExt ".mpeg"] != 0 } then {
# append keyanimBaseName ".mpg"
# }

The patch needs testing, etc.

Let me know if you have any questions.

--
Bob

(attachments)

gsd_img_mpeg.patch (12.2 KB)

4

William Kyngesburye wrote:
> Or can GRASS use any codec available in ffmpeg?

Glynn Clements wrote:

It only uses MPEG-1. There's a compile-time option to use XviD, but
that gives you a "raw" XviD stream (no AVI etc container), which isn't
much use.

FWIW mplayer will play the raw Xvid stream without complaint. Actually it
wasn't until I tried to give someone else a copy of one of my animations that I
noticed things were not fully cooked, several months after putting in the Xvid
hack.

I would guess the ffmpeg library provides some way to the add the container,
but I've no idea how. At the time I remember searching the web for some sort of
documentation, example, or post-processing trick (e.g. mencoder rebuild index),
but to no avail.

Maybe the new method in Bob's patch helps?

Hamish

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

5

Bob Covill wrote:

On Mon, 2007-10-22, Glynn Clements wrote:
> William Kyngesburye wrote:
>
> > I finally got back to FFMPEG on OSX. It went fairly smooth this
> > time. I added build instructions to the GRASS OSX readme. My
> > future OSX builds will now have ffmpeg support, yay!
> >
> > Question: what is the minimum needed in the ffmpeg libraries for
> > GRASS? I'm thinking of disabling codecs and formats that GRASS
> > can't use to reduce the library size (a basic universal build
> > without debug symbols added ~6.5MB to libgrass_ogsf!). Or can
> > GRASS use any codec available in ffmpeg?
>
> It only uses MPEG-1. There's a compile-time option to use XviD, but
> that gives you a "raw" XviD stream (no AVI etc container), which isn't
> much use.
>

I have attached a patch for gsd_img_mpeg.c (ogsf) which is based on the
later releases of ffmpeg (output_example.c). This uses a function
guess_format to guess the format based upon the file extension given. If
the format is unknown it reverts to mpeg1. With this patch you can save
to any (almost) format supported by ffmpeg. For example you can save to
asf, avi, flv, swf, etc. To use this with nviz the auto name extension
in panel_kanimator.tcl will have to be commented out ...

# if { [string compare $fnameExt ".mpg"] != 0 &&
# [string compare $fnameExt ".mpeg"] != 0 } then {
# append keyanimBaseName ".mpg"
# }

The patch needs testing, etc.

Let me know if you have any questions.

--
Bob

Hi,

I have applied this patch now in 6.3-cvs.
I also reinserted the USE_XVID code to force the encoder to use the Xvid codec, but I haven't tested that.

In other NVIZ news for Max res PPM output I have changed the rendering logic in 6.3.0 release branch to use the safe methods by default and only use pixmaps/pbuffers if asked for with the GRASS_GLX_PIXMAPS or GRASS_GLX_PBUFFERS enviro vars.

For me, to get it to export the image correctly in 6.3-cvs I need to do:
export GRASS_NO_GLX_PIXMAPS=TRUE
( unset GRASS_NO_GLX_PBUFFERS )

otherwise NVIZ exits with an error:

G63.cvs> nviz elevation.dem
Loading Data
Update elev null mask
Loading Data
translating colors
recalculating normals...
Create PixMap Using GLX 1.1
X Error of failed request: GLXBadContext
  Major opcode of failed request: 143 (GLX)
  Minor opcode of failed request: 5 (X_GLXMakeCurrent)
  Serial number of failed request: 5281
  Current serial number in output stream: 5281

Hamish

6

Oh, I should mention that I too saw the case where the NVIZ positioning
puck/crosshair box vanished from the main panel a few times in the last month
(6.3cvs). Switching between the eye and center view methods brought it back.

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

7

Hamish wrote:

> > > I finally got back to FFMPEG on OSX. It went fairly smooth this
> > > time. I added build instructions to the GRASS OSX readme. My
> > > future OSX builds will now have ffmpeg support, yay!
> > >
> > > Question: what is the minimum needed in the ffmpeg libraries for
> > > GRASS? I'm thinking of disabling codecs and formats that GRASS
> > > can't use to reduce the library size (a basic universal build
> > > without debug symbols added ~6.5MB to libgrass_ogsf!). Or can
> > > GRASS use any codec available in ffmpeg?
> >
> > It only uses MPEG-1. There's a compile-time option to use XviD, but
> > that gives you a "raw" XviD stream (no AVI etc container), which isn't
> > much use.
> >
>
> I have attached a patch for gsd_img_mpeg.c (ogsf) which is based on the
> later releases of ffmpeg (output_example.c). This uses a function
> guess_format to guess the format based upon the file extension given. If
> the format is unknown it reverts to mpeg1. With this patch you can save
> to any (almost) format supported by ffmpeg. For example you can save to
> asf, avi, flv, swf, etc. To use this with nviz the auto name extension
> in panel_kanimator.tcl will have to be commented out ...
>
> # if { [string compare $fnameExt ".mpg"] != 0 &&
> # [string compare $fnameExt ".mpeg"] != 0 } then {
> # append keyanimBaseName ".mpg"
> # }
>
> The patch needs testing, etc.
>
> Let me know if you have any questions.

I have applied this patch now in 6.3-cvs.
I also reinserted the USE_XVID code to force the encoder to use the Xvid codec, but I haven't tested that.

In other NVIZ news for Max res PPM output I have changed the rendering
logic in 6.3.0 release branch to use the safe methods by default and
only use pixmaps/pbuffers if asked for with the GRASS_GLX_PIXMAPS or
GRASS_GLX_PBUFFERS enviro vars.

FWIW, there are no "safe" methods; rendering into the window has
problems of its own.

Having said that, as both GLX Pixmaps and pBuffers appear to fail on
most systems, I don't have any problem with using the window by
default.

--
Glynn Clements <glynn@gclements.plus.com>

8

> 2) d.vect default render mode in 6.3 has been changed to "l" from
> "g". For me (using xmons) this creates poorly rendered polylines and
> lots of bad artifacts in the "whitespace padding" at the edges.
>
> see examples here:
> http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/index.html
>
> (IIRC the min line width!=0 problem shown at the bottom of that page
> has been corrected)

no, it is just that the default width=0 has been reenabled since a couple
of months ago (it was being reset to 1 internally) and the problem is only
seen with width=1.

> Due to this I propose the default rendering should go back to "g" in
> the 6.3.0 release branch.

Glynn:

What's wrong with r, d and c?

I have now done some more tests. Scripts for easy comparison attached.

The first is with spearfish's vector streams; adjusting d.vect width=:

PNG driver (results seem to be identical)
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_PNGdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_PNGdriver.png

bonus problem:
I am not sure what's causing the frame breakage at the bottom of the "D"
frame. 90% of the time it looks ok in XDRIVER but not in PNG driver.
Happens in both sometimes. I would blame d.frame.quarter math but that only
runs once and the problem can come and go with d.redraw or d.out.file
format=png, so I begin to suspect d.frame, with some race condition which
makes the different speed of the PNG/X drivers trigger it or not??
Perhaps it is d.resize or d.save? Resizing to the same dimensions as the
monitor was opened with (d.resize w=800 h=900) causes it to happen.
?

back to d.vect rendering though,

XDRIVER: (for r,d,l width=1 polylines render poorly, as seem in original
examples from quoted link at the top of this email.
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_Xdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_Xdriver.png

ok so that's the tiny gaps in lines for XDRIVER polylines with width=1.

next problem- r,d inverse fill a small bay upon zoom in.
Also, "l" in XDRIVER fill is badly broken. "g" is correct in all cases.
  (the vector map for that section of coastline available upon request)
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_Xdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png

next problem- in the PNG driver for all rendering methods but "g" the
boundaries and fills don't line up. It's obvious if you look with xmag.
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_C_and_all_but_G_xmag_PNGdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png

next problem- (xdriver) g & l methods don't line up:
d.vect Coast_isl type=area color=red fcolor=220:220:220 render=g
d.vect Coast_isl type=area color=blue fcolor=none render=l
d.grid -n 1000
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/d_vect_gl_overlay.png

and finally- "c" still has 1 pixel of white at the top and bottom of the
display:
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/

Glynn:

g should only be used if none of the others can be made to work.

currently 'g' is still the only one that works properly in all cases for
both XDRIVER and PNG driver. But the bugs in the others are probably not
so hard to fix.

Do you have any objections to using "g" as the default for the 6.3.0
release? (and leaving as-is [a work in progress] in 6.3.cvs)

To get rid of the problem with render=l drawing beyond the edge of the
region, d.vect needs to set the raster clip window (R_set_window()) to
match the region (D_setup() sets it to match the frame), but it needs
to be set back afterwards (D_setup(0) should suffice).

Should we wait to know if "l" will be the default before adding that?

Also:

1. d.vect uses the same rendering mode for both fills and strokes,
which isn't necessarily desirable.

Once we have finished this debugging and all methods are rendering
crisply we can pick winners, remove the render= option from d.vect,
and use the multiple best methods for each task directly in the code,
yes?

2. There should probably be two polyline clipping functions. One which
fills the gap where a section has been clipped out, and one which
doesn't.

Hamish

(attachments)

render_trial_areafill.sh (903 Bytes)
render_trial_width.sh (921 Bytes)

9

Hamish wrote:
> In other NVIZ news for Max res PPM output I have changed the rendering
> logic in 6.3.0 release branch to use the safe methods by default and
> only use pixmaps/pbuffers if asked for with the GRASS_GLX_PIXMAPS or
> GRASS_GLX_PBUFFERS enviro vars.

Glynn:

FWIW, there are no "safe" methods; rendering into the window has
problems of its own.

Yes, I notice if the NVIZ window is obscured by another or slightly off the
edge of the screen you can get random garbage in the output image.

Having said that, as both GLX Pixmaps and pBuffers appear to fail on
most systems, I don't have any problem with using the window by
default.

6.3.cvs is currently left trying to use GLX Pixmaps and pBuffers, in the
hope that it annoys someone into fixing it. I don't mind leaving it like
that but we have to remember to change it each time we cut a new release
branch, which is a pain.

Hamish

      ____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/

10

On Sat, 2007-12-01 at 18:00 +1300, Hamish wrote:

Bob Covill wrote:
> On Mon, 2007-10-22, Glynn Clements wrote:
> > William Kyngesburye wrote:
> >
> > > I finally got back to FFMPEG on OSX. It went fairly smooth this
> > > time. I added build instructions to the GRASS OSX readme. My
> > > future OSX builds will now have ffmpeg support, yay!
> > >
> > > Question: what is the minimum needed in the ffmpeg libraries for
> > > GRASS? I'm thinking of disabling codecs and formats that GRASS
> > > can't use to reduce the library size (a basic universal build
> > > without debug symbols added ~6.5MB to libgrass_ogsf!). Or can
> > > GRASS use any codec available in ffmpeg?
> >
> > It only uses MPEG-1. There's a compile-time option to use XviD, but
> > that gives you a "raw" XviD stream (no AVI etc container), which isn't
> > much use.
> >
>
> I have attached a patch for gsd_img_mpeg.c (ogsf) which is based on the
> later releases of ffmpeg (output_example.c). This uses a function
> guess_format to guess the format based upon the file extension given. If
> the format is unknown it reverts to mpeg1. With this patch you can save
> to any (almost) format supported by ffmpeg. For example you can save to
> asf, avi, flv, swf, etc. To use this with nviz the auto name extension
> in panel_kanimator.tcl will have to be commented out ...
>
> # if { [string compare $fnameExt ".mpg"] != 0 &&
> # [string compare $fnameExt ".mpeg"] != 0 } then {
> # append keyanimBaseName ".mpg"
> # }
>
> The patch needs testing, etc.
>
> Let me know if you have any questions.
>
> --
> Bob

Hi,

I have applied this patch now in 6.3-cvs. I also reinserted the
USE_XVID code to force the encoder to use the Xvid codec, but I
haven't tested that.

You probably do not need this. The video format written will be
determined by the file extension passed from the GUI. The default
fall-back is the generic MPEG1 if it cannot figure out the format from
the extension. You should get an mp4 if you use "movie.mp4" as the
output name? The library still needs options to allow quality variables
supplied by the user (eg. qscale, bit rate, etc).

Note that with this change it is ALMOST possible to write an animated
GIF. If you supply the filename as "movie.gif" it will fail because the
pixel format is not compatible with the GIF output. It should be
possible to tweak the library to handle this and output an animated GIF
if requested.

In other NVIZ news for Max res PPM output I have changed the rendering
logic in 6.3.0 release branch to use the safe methods by default and
only use pixmaps/pbuffers if asked for with the GRASS_GLX_PIXMAPS or
GRASS_GLX_PBUFFERS enviro vars.

For me, to get it to export the image correctly in 6.3-cvs I need to do:
export GRASS_NO_GLX_PIXMAPS=TRUE
( unset GRASS_NO_GLX_PBUFFERS )

otherwise NVIZ exits with an error:

G63.cvs> nviz elevation.dem
Loading Data
Update elev null mask
Loading Data
translating colors
recalculating normals...
Create PixMap Using GLX 1.1
X Error of failed request: GLXBadContext
  Major opcode of failed request: 143 (GLX)
  Minor opcode of failed request: 5 (X_GLXMakeCurrent)
  Serial number of failed request: 5281
  Current serial number in output stream: 5281

Hamish

--
Bob

11

Hamish wrote:

> What's wrong with r, d and c?

I have now done some more tests. Scripts for easy comparison attached.

The first is with spearfish's vector streams; adjusting d.vect width=:

PNG driver (results seem to be identical)
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_PNGdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_PNGdriver.png

bonus problem:
I am not sure what's causing the frame breakage at the bottom of the "D"
frame. 90% of the time it looks ok in XDRIVER but not in PNG driver.
Happens in both sometimes. I would blame d.frame.quarter math but that only
runs once and the problem can come and go with d.redraw or d.out.file
format=png, so I begin to suspect d.frame, with some race condition which
makes the different speed of the PNG/X drivers trigger it or not??
Perhaps it is d.resize or d.save? Resizing to the same dimensions as the
monitor was opened with (d.resize w=800 h=900) causes it to happen.
?

Sorry, I don't understand. Can you clarify?

back to d.vect rendering though,

XDRIVER: (for r,d,l width=1 polylines render poorly, as seem in original
examples from quoted link at the top of this email.
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_0_Xdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_1_Xdriver.png

ok so that's the tiny gaps in lines for XDRIVER polylines with width=1.

I can't reproduce this.

Does it occur with the PNG driver, or with a different X server?

next problem- r,d inverse fill a small bay upon zoom in.
Also, "l" in XDRIVER fill is badly broken. "g" is correct in all cases.
  (the vector map for that section of coastline available upon request)
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_Xdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png

Please specify the region, so that I can attempt to reproduce this.

next problem- in the PNG driver for all rendering methods but "g" the
boundaries and fills don't line up. It's obvious if you look with xmag.
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_C_and_all_but_G_xmag_PNGdriver.png
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png

Okay, I think I know about this. Points and line vertices need to use
floor(), while polygon vertices need round().

next problem- (xdriver) g & l methods don't line up:
d.vect Coast_isl type=area color=red fcolor=220:220:220 render=g
d.vect Coast_isl type=area color=blue fcolor=none render=l
d.grid -n 1000
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/d_vect_gl_overlay.png

render=l selects culling, not clipping. It simply discards segments
which are entirely outside the clip window. It relies upon the
raster-level clip window (R_set_window()) being set appropriately,
which isn't the case for d.vect at present.

and finally- "c" still has 1 pixel of white at the top and bottom of the
display:
http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/

I'll look into this later.

> g should only be used if none of the others can be made to work.

currently 'g' is still the only one that works properly in all cases for
both XDRIVER and PNG driver. But the bugs in the others are probably not
so hard to fix.

Do you have any objections to using "g" as the default for the 6.3.0
release? (and leaving as-is [a work in progress] in 6.3.cvs)

Yes, as it only works with the raster drivers (and may not work right
with the cairo driver if using anti-aliasing).

> To get rid of the problem with render=l drawing beyond the edge of the
> region, d.vect needs to set the raster clip window (R_set_window()) to
> match the region (D_setup() sets it to match the frame), but it needs
> to be set back afterwards (D_setup(0) should suffice).

Should we wait to know if "l" will be the default before adding that?

I would recommend using l as the default, as it should be the fastest.

[Actually, I also need to add code to remove 0-length segments. When
zooming in, there could be a lot of these.]

> Also:
>
> 1. d.vect uses the same rendering mode for both fills and strokes,
> which isn't necessarily desirable.

Once we have finished this debugging and all methods are rendering
crisply we can pick winners, remove the render= option from d.vect,
and use the multiple best methods for each task directly in the code,
yes?

Some methods may have better performance with different types of data.
E.g. g will be quicker if the data doesn't need to be clipped, while l
will be quicker at high zoom.

--
Glynn Clements <glynn@gclements.plus.com>

12

Hamish wrote:

> > > I finally got back to FFMPEG on OSX. It went fairly smooth this
> > > time. I added build instructions to the GRASS OSX readme. My
> > > future OSX builds will now have ffmpeg support, yay!
> > >
> > > Question: what is the minimum needed in the ffmpeg libraries for
> > > GRASS? I'm thinking of disabling codecs and formats that GRASS
> > > can't use to reduce the library size (a basic universal build
> > > without debug symbols added ~6.5MB to libgrass_ogsf!). Or can
> > > GRASS use any codec available in ffmpeg?
> >
> > It only uses MPEG-1. There's a compile-time option to use XviD, but
> > that gives you a "raw" XviD stream (no AVI etc container), which isn't
> > much use.
> >
>
> I have attached a patch for gsd_img_mpeg.c (ogsf) which is based on the
> later releases of ffmpeg (output_example.c). This uses a function
> guess_format to guess the format based upon the file extension given. If
> the format is unknown it reverts to mpeg1. With this patch you can save
> to any (almost) format supported by ffmpeg. For example you can save to
> asf, avi, flv, swf, etc. To use this with nviz the auto name extension
> in panel_kanimator.tcl will have to be commented out ...
>
> # if { [string compare $fnameExt ".mpg"] != 0 &&
> # [string compare $fnameExt ".mpeg"] != 0 } then {
> # append keyanimBaseName ".mpg"
> # }
>
> The patch needs testing, etc.
>
> Let me know if you have any questions.

I have applied this patch now in 6.3-cvs.

This patch causes NVIZ compilation to fail.

It causes the OGSF library to depend upon libavformat, but nothing in
the patch adds -lavformat to the link command for libogsf.

I managed to work around the problem by hardcoding -lavformat into
lib/ogsf/Makefile, but this should be done via configure and
Platform.make, either by adding the relevant switch(es) to FFMPEGLIB
or by adding a new variable.

--
Glynn Clements <glynn@gclements.plus.com>

13

Glynn Clements wrote:

> next problem- in the PNG driver for all rendering methods but "g" the
> boundaries and fills don't line up. It's obvious if you look with xmag.
> http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_C_and_all_but_G_xmag_PNGdriver.png
> http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/dec2008/dvect_render_fill_PNGdriver.png

Okay, I think I know about this. Points and line vertices need to use
floor(), while polygon vertices need round().

Done.

> and finally- "c" still has 1 pixel of white at the top and bottom of the
> display:
> http://bambi.otago.ac.nz/hamish/grass/bugs/d.vect/

I'll look into this later.

This was caused by adding a clip margin so that thick lines didn't
extend outside of the clip region.

In retrospect, this was a mistake. That kind of clipping should be
left to the driver's clipping.

I have removed the clip margin.

> > To get rid of the problem with render=l drawing beyond the edge of the
> > region, d.vect needs to set the raster clip window (R_set_window()) to
> > match the region (D_setup() sets it to match the frame), but it needs
> > to be set back afterwards (D_setup(0) should suffice).
>
> Should we wait to know if "l" will be the default before adding that?

I would recommend using l as the default, as it should be the fastest.

[Actually, I also need to add code to remove 0-length segments. When
zooming in, there could be a lot of these.]

I have added code to remove zero-length segments.

--
Glynn Clements <glynn@gclements.plus.com>

14

On Mon, 2007-12-03 at 09:08 +0000, Glynn Clements wrote:

Hamish wrote:

> > > > I finally got back to FFMPEG on OSX. It went fairly smooth this
> > > > time. I added build instructions to the GRASS OSX readme. My
> > > > future OSX builds will now have ffmpeg support, yay!
> > > >
> > > > Question: what is the minimum needed in the ffmpeg libraries for
> > > > GRASS? I'm thinking of disabling codecs and formats that GRASS
> > > > can't use to reduce the library size (a basic universal build
> > > > without debug symbols added ~6.5MB to libgrass_ogsf!). Or can
> > > > GRASS use any codec available in ffmpeg?
> > >
> > > It only uses MPEG-1. There's a compile-time option to use XviD, but
> > > that gives you a "raw" XviD stream (no AVI etc container), which isn't
> > > much use.
> > >
> >
> > I have attached a patch for gsd_img_mpeg.c (ogsf) which is based on the
> > later releases of ffmpeg (output_example.c). This uses a function
> > guess_format to guess the format based upon the file extension given. If
> > the format is unknown it reverts to mpeg1. With this patch you can save
> > to any (almost) format supported by ffmpeg. For example you can save to
> > asf, avi, flv, swf, etc. To use this with nviz the auto name extension
> > in panel_kanimator.tcl will have to be commented out ...
> >
> > # if { [string compare $fnameExt ".mpg"] != 0 &&
> > # [string compare $fnameExt ".mpeg"] != 0 } then {
> > # append keyanimBaseName ".mpg"
> > # }
> >
> > The patch needs testing, etc.
> >
> > Let me know if you have any questions.
>
> I have applied this patch now in 6.3-cvs.

This patch causes NVIZ compilation to fail.

It causes the OGSF library to depend upon libavformat, but nothing in
the patch adds -lavformat to the link command for libogsf.

I managed to work around the problem by hardcoding -lavformat into
lib/ogsf/Makefile, but this should be done via configure and
Platform.make, either by adding the relevant switch(es) to FFMPEGLIB
or by adding a new variable.

The patch that I had sent out originally was just to upgrade the ogsf
lib. It will require -lavformat be added to configure(.in) so that
FFMPEGLIB in Platform.make includes it.

The changes to panel_kanimator.tcl listed above will also have be made
so that output filenames do not have the extension stripped and replaced
with "mpg".

--
Bob

15

I have backported a series of fixes (mainly documentation):

AUTHORS
REQUIREMENTS.html
SUBMITTING
SUBMITTING_DOCS
SUBMITTING_SCRIPTS
SUBMITTING_TCLTK
COPYING
INSTALL
contributors.csv
contributors_extra.csv
translators.csv

db/drivers/postgres/README
lib/grasslib.dox
lib/init/gis_set.tcl
lib/init/grass_intro.txt
lib/init/init.sh
macosx/app/Info.plist.in
macosx/Makefile
macosx/pkg/resources/Info.plist.in
ps/ps.map/description.html
raster/r.average/description.html
raster/r.buffer/description.html
raster/r.gwflow/description.html
raster/r.in.gdal/description.html
raster/r.le/r.le.setup/sample.c
raster/r.los/description.html
raster/r.report/description.html
raster/r.resamp.rst/description.html
raster/r.statistics/description.html
raster/r.stats/description.html
scripts/d.monsize/d.monsize
scripts/r.in.wms/description.html
scripts/r.in.wms/r.in.wms
scripts/r.regression.line/description.html
scripts/r.regression.line/r.regression.line
scripts/r.shaded.relief/r.shaded.relief
scripts/v.rast.stats/v.rast.stats
scripts/v.report/v.report
swig/perl/Makefile.PL.in
swig/perl/R_slope_aspect/r_slope_aspect/r_slope_aspect.c
vector/lidar/lidarlib/InterpSpline.c
vector/lidar/lidarlib/raster.c
vector/vectorintro.html
vector/v.in.ascii/in.c
vector/v.in.ogr/description.html
vector/v.in.ogr/main.c
vector/v.lrs/lrs.html
vector/v.net/description.html
vector/v.net.steiner/description.html
vector/v.segment/description.html
vector/v.surf.rst/README
vector/v.vol.rst/README
vector/v.vol.rst/user1.c
visualization/nviz/Makefile
visualization/xganim/description.html

See details at
http://trac.osgeo.org/grass/changeset/29461
http://trac.osgeo.org/grass/changeset/29462

Once
http://trac.osgeo.org/grass/ticket/1
is fixed, we could release 6.3.0 officially.

Markus

16

Dear list,

I recently tried to import some 3D sketches of perfect
vertical cross-sections, i.e. polygons with areas extending
only vertically, i.e. seen from above they have no extent.

I did not succeed, because v.in.ogr complained about those
areas being to small. Is it possible that it does not "see"
vertical extent and thus assumes there is no extent at all?

Would this only affect the check in v.in.ogr or is this
a general problem with the way in which GRASS handles
3D polygons?

Best,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

17

I have a question about general committing practices. Should all commits be applied against HEAD only, or should each author see to it that commits are backported to release branches as well?

Thanks,

~ Eric.

18

Markus Neteler wrote:

I have backported a series of fixes (mainly documentation):

Awesome.

Once
http://trac.osgeo.org/grass/ticket/1
is fixed, we could release 6.3.0 officially.

We need this one [1] fixed too. I'm uneasy about a release
that has long time known bug in it's main raster export
module, posing a threath of data corruption. See also notes
on WIKI [2].

[1]http://wald.intevation.org/tracker/?func=detail&atid=204&aid=405&group_id=21
[2]http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan#Must_do

Maciek

19

Patton, Eric wrote:

I have a question about general committing practices. Should all commits
be applied against HEAD only, or should each author see to it that
commits are backported to release branches as well?

IMHO, commit to head; leave it to the release manager to decide what
should be backported.

--
Glynn Clements <glynn@gclements.plus.com>

20

Hi,

2007/12/17, Markus Neteler <neteler@fbk.eu>:

[snip]

Once
http://trac.osgeo.org/grass/ticket/1
is fixed, we could release 6.3.0 officially.

it should be fixed now in trunk (since I don't know g.setproj, please
take a look), I left the ticket open since I am not sure if we can
uncomment ch1903 item in lib/gis/datumtransform.table.

See diff (sorry, I didn't split the patch, next time...:slight_smile:

http://trac.osgeo.org/grass/changeset/29468

@@ -455,5 +455,7 @@
     /* don't ask, use the default */

- if (G_strcasecmp(desc->type, "float") == 0) {
+ if (G_strcasecmp(desc->type, "float") == 0 ||
+ G_strcasecmp(desc->type, "lat") == 0 ||
+ G_strcasecmp(desc->type, "lon") == 0) {
         sprintf(tmp_buff, "%.10f", parm->deflt);
         G_set_key_value(desc->key, tmp_buff, out_proj_keys);

Martin

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *