#137 frei0r producer time inconsistency

[Andrew Wason]

I'm not sure if this is actually a bug. I have a producer that needs to know "normalized" time (0.0->1.0). The producer_frei0r.c is similar in that it needs to know time in seconds.

In producer_frei0r.c:producer_get_frame() it stores mlt_producer_position() on the frame with mlt_frame_set_position(), then in producer_get_image() it retrieves the frame position with mlt_frame_get_position().

If you run something like "melt -blank 400 frei0r.nois0r", then in gdb you can see the initial position stored on the frame in producer_get_frame() is 0, but when producer_get_image() is called the frame position is now 401 - because mlt_playlist.c:producer_get_frame() has reset the frame position on the frame.

This may not matter for producer_frei0r because A) none of the frei0r generators actually use the time passed in and B) it's not clear if frei0r time has to start at 0, so having it offset by the -blank may not matter.

For my producer it matters, so in my get_frame I store the mlt_producer_position() in a frame property ("webvfx.position") and retrieve it in get_image. Possibly producer_frei0r should be doing something similar?

[Dan Dennedy]

The frei0r specification is ambiguous about the time parameter and intentionally so according to salsaman who was involved in the drafting of the specification. Going by the comment documentation for that parameter, it can be determined to be either an elapsed wall-clock time relative to start of the application session or a frame's "time" ala timecode. I suppose one could make a frei0r producer that "works better" when starting from zero like say, color cycling. We will leave this open for now.