#6375: [bug][regression] Too many packets buffered for output stream
------------------------------------+----------------------------------
Reporter: p137 | Owner:
Type: defect | Status: closed
Priority: important | Component: ffmpeg
Version: git-master | Resolution: fixed
Keywords: regression | Blocked By:
Blocking: | Reproduced by developer: 1
Analyzed by developer: 0 |
------------------------------------+----------------------------------
Changes (by eoe):
* status: reopened => closed
* resolution: => fixed
Comment:
Seems to have been fixed at latest git head (checked on
N-99980-g8f468c6668-g42ccef2846+5), by the above commit.
If anyone comes across this who is still using older versions, I found
that this was usually caused by a late starting track, where ffmpeg would
buffer encoded packets until there was at least 1 packet encoded for every
output stream before muxing, so the late starting track would
significantly delay this, going over the threshold for
max_muxing_queue_size, causing ffmpeg to drop the late track entirely in
order to not drop the original packets. This does mean that, so long as
you know that you'd have enough memory to buffer encoded packets before
any late tracks start, you're safe to increase max_muxing_queue_size to
whatever you want. Of course, I wouldn't set it too high without knowing
what's up with your sources, since it's possible that a track from a
broken input might never start, and then you're left buffering your entire
output until exiting.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/6375#comment:36>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
