• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 217 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is the IPIPE PREV_PREVIEW call synchronous?

Eric Chartier
Prodigy 220 points

I'm using the resizer, mostly for Noise Filtering, Color Correction and Color Space Transfer. I kinda figured that the PREV_PREVIEW is not synchronous since all those operation are reported to take either 0 or 1 millisecond.

This is a problem for me because further down my video path I am encoding the video with MPEG4 and this causes vertical tearing of the image. Is there a way to get notified when the PREV_PREVIEW call has finished or a way to block until it has?

There is some documentation about timing in the vpfe manual but I'm not sure how to use it properly. Any kind of pointers would be appreciated.

  • 0
    Prodigy 220 points

    Another hint that the call is not completed is that I can memset my whole image to 0 just after the PREV_PREVIEW call and I can still see between 1/2 and 1/4 of the picture. If the call was completed then the whole image should be green and not just a portion of it.

    Maybe it is a clock divider problem but this is much of a shot in the dark here.

  • 0 in reply to Eric Chartier
    Prodigy 220 points

    Followup:

    Sometimes the call takes either 0 or 1 ms. The elapsed time is calculated as follow :

    unsigned long timeBefore = GetTimeMS();
    ret = ioctl(m_hDevPreviewer, PREV_PREVIEW, &convert) < 0;
    DBG("Previewer took : %lu\n", GetTimeMS() - timeBefore);
    

    This is the case where the call gets asynchronous and my image will flicker. Otherwise the reported time is either 16 or 17 ms and the image is fine. It seems that the single shot mode gets disabled somehow, or is incorrectly set.
    

    I don't know if it is related or not but dmesg shows a flood of 
    

    [  191.250000] rsz_set_output_address 1
    [  191.280000] rsz_set_output_address 0
    [  191.280000] rsz_set_output_address 1
    [  191.310000] rsz_set_output_address 0
    [  191.310000] rsz_set_output_address 1
    

    which repeats at a regular interval
    
			
    

		
		
		
		
	
    
	
    
		
    
			
		
    
	
    

	            
                	
	
    
				
		                
                
                
                
                
                
                
        		
		
				
    
			
		
    
		
		 
		
		
     
    
	
    

    
			
    
			
    
		
    

		
    
	
    •