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".

Reply via email to