Hello Marton, On Wed, Apr 26, 2023 at 3:36 AM Marton Balint <c...@passwd.hu> wrote: > Okay, I realized there is one thing here I don't understand. What if we > interleave data packets the same way as others, but we don't wait for them > in order to start flushing packet queues? > > So I wonder, if you removed the AV_CODEC_ID_SMPTE_2038 exception > from init_muxer when calculating si->nb_interleaved_streams but keep the > exception in ff_interleave_packet_per_dts, and set > max_interleave_delta to 1, would that work?
I was actually wondering the same thing after our email exchange yesterday. I haven't tried it yet, but I suspect it might very well result in the 2038 packets not being very far ahead of the video. We still need an intermediate data structure to hold onto the 2038 packets (and there could be multiple) before the corresponding video frame arrives, and a queue is still a reasonable data structure to store those packets within the decklink module. Your suggestion might be a good one, and it might change the behavior such that the packets in general would be more often held in the mux queue rather than the decklink queue. But I don't think it changes anything about the fundamental design, and it doesn't eliminate the need for stashing the data packets until the corresponding video is to be sent out. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
