Хитрая очередь 2
Приветствую, отдельно потужно постоянных читателей моих тем ))
Требуется реализовать очередную хитро.опую очередь для многопоточной обработки, поступающих с h264 камеры nalu блоков, которые в контексте libav библиотек от ffmpeg будем считать условными кадрами.
Для мжпег камер на базе std::deque получился рабочий вариант - поток чтения берет например с начала индекс выделенного массива под кадры и прочитав в элемент кладет этот индекс с другой стороны очереди. Потоки записи кадров, онлайн трансляции, определения движения и просто запроса снимков делают тоже самое только наибарот к очереди - что позволяет во всех случая получать условно самый свежий кадр и отбрасывать все старье.
Теперича хочется тоже самое но в контексте 264 кодека - т.е. для случая чтения например я бы мог заполнять очередь до поступления И кадра и сразу ее опустошать при его считывании (тем самым гарантируя что в начале очереди всегда ключевой кадр), но вот никак не соображу - а как же «потребители» будут понимать что очередь сброшена и надо начинать читать ее сначала? uint64_t счётчик сброса у всех потоков вести!?
Может многопоточники на плюсах сорентируют какие стандартные алгоритмы для таких вещей используются!?