textoverlay timing

[James]

> On 13 Jan 2023, at 8:06 am, James <jam at tigger.ws> wrote:
> 
> I've got a pipeline that previews and records 1080.
> It has a clockoverlay and 9 textoverlay elements in the pipeline
> 
> I tried adding elements dynamically and statically having 9 elements with text of ""
> There was little performance difference, so I went for static, as it was easier
> 
> A feature I wanted was to change font and point size. My whole page is same font and size.
> Since you can't get a semaphore lock in a signal handler I do one line at a time with a very simple locking mechanism
> 
> producer creates a shm file with instructions for 1 line, then waits for file to not exist
> consumer does work then removes the file
> 
> All works, but if I have all 9 lines of text then
> [execute] new font or size
> usually half the lines change and I need to repeat 2x or 3x before all are done. Since the result is not predictable it must be a timing issue.
> 
> If I manually issue commands line by line then all works perfectly, confirming timing problems.
> 
> What timing? Where can I find out about it?

Feedback: solution might help someone:

To dynamically change textoverlay

I write a list of instructions into a /dev/shm file
I send the gstreamer process a signal
  it processes the instructions ie changing the font, or text or offset elements as needed

Some lines did not 'take'
I changed the algorithm

I write instructions for 1 line into my file
signal gstreamer process
when gstreamer is finished it removes the file
I write instructions for 1 line .... (sync with NO file, it is removed when gstreamer process is complete with 1 line change)

This works perfectly and the user perceives no delay at all.
James