Changes between Initial Version and Version 1 of Ticket #4513, comment 25


Ignore:
Timestamp:
Jun 6, 2019, 11:53:12 AM (2 months ago)
Author:
kmark
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #4513, comment 25

    initial v1  
    22
    33    By increasing the QUEUE_SIZE the chance of frames dropping out of the buffer is significantly reduced. It's been noted in trac #4513 by nickcrabtree that the current size of 4 is too low for most (any?) applications. 400 is ultimately an arbitrary-but-tested number.
    4    
     4
    55    I've noticed that even with QUEUE_SIZE set to 400 I can still run into a situation where it's not high enough as evidence by the log output. However this is always in instances where my system is consistently encoding at a rate slower than frames are being pulled from AVFoundation so the buffer overrun is inevitable unless the duration left to encode is short. So it's hard to put the blame on this code when the problem can be alleviated by changing a runtime configuration elsewhere.
    6    
     6
    77    Given the above limitation it seems clear that increasing QUEUE_SIZE is not a magic fix but gives the encoder more wiggle room to temporarily lag behind frames pulled in from AVFoundation. If you do see "video queue is full, the oldest frame has been dropped" in your log then increasing QUEUE_SIZE further may work in some instances but fixing the underlying issue would require an increase in encoder speed or a frame-rate reduction on the AVFoundation end.
    8    
     8
    99    One last note is that while I use the term encoder here (as that's likely to be the slowest part of your pipeline) I am really referring to anything downstream of AVFoundation's input.