Quoting Nicolas George (2023-12-01 15:50:39) > Anton Khirnov (12023-12-01): > > > When something succeeds with the current code and fails with “Error > > > while add the frame to buffer source(Cannot allocate memory)”, that is > > > broken. > > Not necessarily, when the current code is broken (which you agreed with > > in the last thread). > > I do not know what you are talking about, I agreed to no such thing.
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316787.html The current code is broken because its output depends on the order in which the frames from different inputs arrive at the filtergraph. It just so happens that it is deterministically broken currently. After this patchset it becomes non-deterministically broken, which forces me to do something about it. > The test case I gave you is correct and with the current code it works. > Your changes breaks it, removing an important features for users. Please > include it in your testing routine and only submit again when you have > fixed it. Your testcase offsets two streams by 60 seconds. That implies 60 seconds of buffering. You would get this same amount of bufering in the muxer if you did the same offsetting with transcoding or remuxing two streams from the same source. One can also avoid this buffering entirely by simply opening the file twice. So I don't think your demand is reasonable, unless you're also suggesting a specific way of implementing this. -- Anton Khirnov _______________________________________________ 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".
