Ok - it's a vocabulary issue. A "queue" (or "list") consists of "elements" (chunks of memory) and each of these elements incorporates a pointer to (address of) the next element and some data (in your case the data from AVRcam). An element might be defined like:
typedef struct element_d
{ struct element_d *next; /* points to next element in the queue */
unsigned char data[41]; /* the data associated with this element */
} element;
Now, to keep track of a queue, it's common to define a "head" pointer that points to the first element in the queue. It's sometimes convenient to define a "tail" pointer that points to the last element in the queue, so we might define another structure type as:
typedef struct queue_d
{ element *head; /* pointer to first element */
element *tail; /* pointer to final element */
} queue;
By convention, the pointers that don't point to anything (like the next element pointer in the last element of a queue) are set to NULL. As you'd expect, the head and tail pointers of a queue that currently has no elements will both be NULL.
Queues are classified according to how they're used: If elements are added to and removed from the same end (like a spring-loaded plate dispenser in a cafeteria) then they're classified as "LIFO" (Last In First Out), and if elements are added to one end and removed from the other then they're classified as "FIFO" (First In First Out).
Two more vocabulary words: The act of adding an element to a queue is called "enqueue" (pronounced N-Q), and the act of removing an element from a queue is called "dequeue" (pronounced D-Q).
One of the really handy uses for queues is reduction or elimination of the requirement for synchronicity between two processes. Process A can dequeue an available empty buffer (from a queue of empty buffers), load input data into the buffer, queue the filled buffer for Process B to deal with, and forget about it. Process B dequeues full buffers, processes the data, and returns the buffer to the empty buffer queue for Process A to re-use.
What makes this handy is that Process A is now able to suck up input at full speed without concern for whether the previous buffer has yet been processed - and Process B can go full speed without being limited by the delays inherent in physical I/O.
In your scenario (under the assumptions I listed) the get_packets() routine will suck data out of cam.read() and buffer/queue it until, at some point, cam.available() reports that the next byte hasn't yet arrived. As soon as that happens, proc() is invoked to dequeue a full buffer and process its data, return the buffer to the empty buffer queue for re-use, and return control to get_packets() in time to resume buffering data before the cam buffer overflows.
The advantage lies in making productive use of the time that would otherwise be wasted polling cam.available() for data that hasn't yet arrived - and in taking advantage of the fact that cam will buffer up to 64 bytes to somewhat relax the timing requirements on processing the data.
At 115200 baud and 8N1, the input byte rate will be approximately 11520 bytes/sec (86.8 usec/byte), which means that the 64-byte cam buffer will fill in 5555.6 usecs, and this determines the maximum amount of time available to proc() for each buffer.
Edit: Added 115200 baud timing remarks.