[FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. Cheers, -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. Absolutely not: you cannot push until consensus is reached, and consensus is not reached since you are still breaking the sparseness of sub2video frame. I will answer the last mail in the ongoing discussion soon. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
> On Dec 6, 2023, at 18:55, Nicolas George wrote: > > Anton Khirnov (12023-12-06): >> this should hopefully be the last version of this set. If nobody has new >> comments, I will push it in a few days. > > Absolutely not: you cannot push until consensus is reached, and > consensus is not reached since you are still breaking the sparseness of > sub2video frame. I will answer the last mail in the ongoing discussion > soon. For such large patch set, it’s almost impossible to not break any corner case. Considering the improvements the patch set brings into fftools, those corner cases can be fixed after merge. And any body can try to figure out a proper fix after merged, rather than blocking the patch set and let Anton work on it alone. I want to discuss how to deal with libavdevice/SDL2 issue after applying the patch set, not before. > > -- > Nicolas George > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Zhao Zhili (12023-12-06): > For such large patch set, it’s almost impossible to not break any corner case. Yes, that is what review is for. > Considering the improvements the patch set brings into fftools, those corner > cases can be fixed after merge. That means never. No. > And any body can try to figure out a proper fix after merged, rather than > blocking > the patch set and let Anton work on it alone. I have offered Anton my help. But first he needs to acknowledge there he is breaking something instead of pretending it was already broken so that he can ignore the issue entirely and move on with the parts of the code that matter to himself. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Nicolas George (2023-12-06 13:10:41) > I have offered Anton my help. After weeks of discussion, you have NOT suggested any workable alternative. The single suggestion I did see from you * was already implemented * did not address the issues at all > But first he needs to acknowledge there he is breaking something > instead of pretending it was already broken Producing unpredictable output generally means broken. And "my feature produces random data, but needs very little memory for it" is not a valid argument. -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > After weeks of discussion, you have NOT suggested any workable > alternative. Indeed. And the reason for that is that all the time I have available on this is spent debunking your libel about the current logic. > Producing unpredictable output generally means broken. > And "my feature produces random data, but needs very little memory for > it" is not a valid argument. In this particular case you are absolutely wrong, probably because of a lack of familiarity with the use of subtitles in the real world. See the explanations in the mail I just sent. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hi all, As usual when someone disagrees with him, Nicolas converged to being utterly unreasonable and deaf to all arguments. I see no point in discussing this with him any further and intend to push the set tomorrow, unless somebody else has substantial objections. I've considered asking for a TC vote, but as he is not suggesting any viable alternative, there is really nothing to vote on. So the purpose of this email is just summarizing the dispute, so others can understand it more easily. The issue concerns sub2video code, which allows converting bitmap subtitles to video streams, mainly for hardsubbing purposes. As subtitles are typically sparse in time, the demuxer that produces the subtitle stream emits "heartbeat" frames that are sent to the filtering code just like real subtitle frames. The code in ffmpeg_filter.c then decides whether these heartbeat frames should be sent to the filtergraph or ignored. The problem is that this decision is currently made in a way that depends on what frames previously arrived on _other_ filtergraph inputs (e.g. on video frames in a graph with a subtitle and a video input). However, the inputs are not synchronized, and the interleaving of frames on different inputs is effectively arbitrary. E.g. it depends on the video decoder delay (and thus on the number of frame threads, when frame threading is used). The reason this arbitrariness has not become a major issue until now, is that it is deterministic for a given run on a given machine (sub2video FATE tests do not use a frame-threaded decoder, and so do not exhibit the problem). With ffmpeg CLI becoming fully parallel, the results become non-deterministic and change from run to run, which forces me to do something about this. My solution in patch 01/10 changes the filtering code to always send the heartbeat frames to the filtergraph. This not only makes the results deterministic, but also improves subtitle timing in FATE tests. Nicolas presented a testcase that consists of taking a video+subtitle streams from a single source, offsetting them against each other by a fixed delay, and overlaying subtitle onto video. After my patch, this results in the filtergraph buffering a number of heartbeat frames proportional to the offset, which causes higher memory consumption. However, * the testcase suffers from the above problem - its output can change significantly depending on the number of decoder frame threads; this is fixed by my patch; * the extra buffering added by the patch is similar to what would be added by the muxer interleaving queue, were the streams remuxed rather than overlaid; * the buffering can be avoided entirely by opening the input twice. I thus consider his argument (that the patch is "breaking" the testcase) invalid, as the testcase is * contrived; * already broken; * actually fixed by my patch. Nicolas has also NOT suggested any viable alternative approach. -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, 6 Dec 2023, Anton Khirnov wrote: Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. In some cases the performance penalty because of threading is quite significant: Example command line: ffmpeg -f lavfi -i sine -af volume=6dB -f null none After latest threading changes: speed=810x Before latest threading changes: speed=1.13e+03x With 6.0 branch: speed=1.43e+03x With 5.1 branch: speed=2.92e+03x This is a significant decline from 5.1, getting slower with each release... Is there anything that can be done about this? Thanks, Marton ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Marton Balint (2023-12-06 20:29:01) > > > On Wed, 6 Dec 2023, Anton Khirnov wrote: > > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > In some cases the performance penalty because of threading is quite > significant: > > Example command line: > > ffmpeg -f lavfi -i sine -af volume=6dB -f null none > > After latest threading changes: speed=810x > Before latest threading changes: speed=1.13e+03x > With 6.0 branch: speed=1.43e+03x > With 5.1 branch: speed=2.92e+03x > > This is a significant decline from 5.1, getting slower with each > release... Is there anything that can be done about this? Would guess this is caused by overhead from tons of tiny frames. So 1) generate larger frames 2) use -filter_complex with no inputs instead of -f lavfi to eliminate all overhead from demuxing, decoding, and demux-decode/decode-filter inter-thread communication -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 5:30 AM Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. > LGTM -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > As usual when someone disagrees with him, Nicolas converged to being > utterly unreasonable and deaf to all arguments. I see no point in Ad-hominem attack. > discussing this with him any further and intend to push the set > tomorrow, unless somebody else has substantial objections. > > I've considered asking for a TC vote, Stated intent to act without seeking consensus. > but as he is not suggesting any > viable alternative, Lie. I guess now that your side holds most of the power the mask is off. This mail you just sent should be enough to get you kicked out three times over. But that will not happen, will it? Congratulations, you are on track to become FFmpeg's de-facto dictator, just like you were libav's de-facto dictator and ran it to the ground with your blatant disregard for users and disrespect for fellow developers. I hope Fabrice keeps control of the domain, so that we can revive FFmpeg in a few years. -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames > 2) use -filter_complex with no inputs instead of -f lavfi to eliminate >all overhead from demuxing, decoding, and demux-decode/decode-filter >inter-thread communication Or maybe the threading code is just very inefficient because, just like the BufferRef code, it is riddled with unnecessary indirections and dynamic allocations. We will never know because your attitude made sure nobody competent looked at it. But that is not an issue, because you will ignore Marton's objection just like your ignored mine. -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. I have a case that becomes really non deterministic for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi -bitexact -t 1 -f crc - ; done CRC=0x52e2e323 CRC=0x747761ba CRC=0x747761ba CRC=0x52e2e323 CRC=0x9d872a4b CRC=0x5f5cacfd CRC=0xda55c458 CRC=0x2eccf1c8 CRC=0x747761ba CRC=0x1a4775bd sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ before: for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi -bitexact -t 1 -f crc - ; done CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
> On Dec 6, 2023, at 11:36 AM, Anton Khirnov wrote: > >> In some cases the performance penalty because of threading is quite >> significant: >> >> Example command line: >> >> ffmpeg -f lavfi -i sine -af volume=6dB -f null none >> >> After latest threading changes: speed=810x >> Before latest threading changes: speed=1.13e+03x >> With 6.0 branch: speed=1.43e+03x >> With 5.1 branch: speed=2.92e+03x >> >> This is a significant decline from 5.1, getting slower with each >> release... Is there anything that can be done about this? > > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames Larger frames would definitely help. With the command as is I get 4.75e+03x on 6.0 and 2.81e+03x on latest mutli-threading branch. However when adding asetnsamples this improves considerably. For example using asetnsamples=2048 as follows runs at 5.6e+03x on the multi-threading branch ./ffmpeg -f lavfi -i sine,asetnsamples=2048 -af volume=6dB -f null none and it can be further improved by increasing the asetnsamples values to 4096 for example (9.18e+03x). There is still a penalty as you could do asetnsamples without multi-threading and get even higher performance, but given the general benefits of multi-threading and the fact that it's possible to increase the performance of this usecase arbitrarily by using larger and larger frames I think that's an acceptable tradeoff for this use case. - Cosmin ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Also, the numbers I'm seeing on my 16-core Ryzen 9 5950X are quite different: * 5.0, your command:speed=3.25e+03x * 5.0, filter_complex: speed=5.29e+03x * 5.1, your command:speed=3.2e+03x * 5.1, filter_complex: speed=5.2e+03x * 6.0, your command:speed=2.44e+03x * 6.0, filter_complex: speed=3.44e+03x * 6.1, your command:speed=1.31e+03x * 6.1, filter_complex: speed=4.06e+03x * threading, your command:speed=3e+03x * threading, filter_complex:speed=4.1e+03x So while there is a drop from 5.0 to post-threading, it is not as dramatic, and threading is actually faster than 6.1. And finally you can get at least an order of magnitude faster by using a larger frame size. -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 3:14 PM Nicolas George wrote: > Lie. > A summary of your proposal or a link to your suggestion would be appreciated. Without reference we're all shouting in the void. > I guess now that your side holds most of the power the mask is off. > > This mail you just sent should be enough to get you kicked out three > times over. > I actually chuckled at this line :-D But that will not happen, will it? > > Congratulations, you are on track to become FFmpeg's de-facto dictator, > just like you were libav's de-facto dictator and ran it to the ground > with your blatant disregard for users and disrespect for fellow > developers. > I don't think improving the ffmpeg CLI tools shows any "disregard for users" and having code in parallel shows a lot of respect to fellow developers since it makes our life easier. You seem fixed on a crusade of keeping the status quo, but the consensus you speak of is instead to move forward. Yes some very minor use cases might break or see degraded performance, but that's the point of a development branch - so that we can all improve the code before the next stable release > I hope Fabrice keeps control of the domain, so that we can revive FFmpeg > in a few years. > See? this is what i mean, you're still in 2011. It's time to move on Nicolas, for your own sake, and for respect to your fellow developers and the users you hold so dear -- Vittorio ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Cosmin Stejerean via ffmpeg-devel (2023-12-06 21:29:11) > There is still a penalty as you could do asetnsamples without multi-threading > and get even higher performance, > but given the general benefits of multi-threading and the fact that it's > possible to increase the performance of this > usecase arbitrarily by using larger and larger frames I think that's an > acceptable tradeoff for this use case. Exactly, I don't think you can reasonably expect a generic transcoder to be optimally performant in all cases. Every major change like this is a tradeoff and we have to pick those that are most broadly useful. A transcoding setup that encodes PCM and throws it away is not particularly useful, and the picture could change quite a lot once you add actual encoding. -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Michael Niedermayer (2023-12-06 21:21:55) > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > I have a case that becomes really non deterministic > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > -bitexact -t 1 -f crc - ; done > CRC=0x52e2e323 > CRC=0x747761ba > CRC=0x747761ba > CRC=0x52e2e323 > CRC=0x9d872a4b > CRC=0x5f5cacfd > CRC=0xda55c458 > CRC=0x2eccf1c8 > CRC=0x747761ba > CRC=0x1a4775bd > > sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ > > before: > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > -bitexact -t 1 -f crc - ; done > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 > CRC=0x192dc994 Should now be fixed in my git tree. -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Thu, Dec 07, 2023 at 11:52:47AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-12-06 21:21:55) > > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > > Hi, > > > this should hopefully be the last version of this set. If nobody has new > > > comments, I will push it in a few days. > > > > I have a case that becomes really non deterministic > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x52e2e323 > > CRC=0x747761ba > > CRC=0x747761ba > > CRC=0x52e2e323 > > CRC=0x9d872a4b > > CRC=0x5f5cacfd > > CRC=0xda55c458 > > CRC=0x2eccf1c8 > > CRC=0x747761ba > > CRC=0x1a4775bd > > > > sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ > > > > before: > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > Should now be fixed in my git tree. Fresh stuck sample: ffmpeg -i tickets/2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 -level 0 file-2531.avi https://trac.ffmpeg.org/raw-attachment/ticket/2531/interlaced_top.wmv thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Thu, Dec 07, 2023 at 11:52:47AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-12-06 21:21:55) > > On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > > > Hi, > > > this should hopefully be the last version of this set. If nobody has new > > > comments, I will push it in a few days. > > > > I have a case that becomes really non deterministic > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x52e2e323 > > CRC=0x747761ba > > CRC=0x747761ba > > CRC=0x52e2e323 > > CRC=0x9d872a4b > > CRC=0x5f5cacfd > > CRC=0xda55c458 > > CRC=0x2eccf1c8 > > CRC=0x747761ba > > CRC=0x1a4775bd > > > > sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ > > > > before: > > > > for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi > > -bitexact -t 1 -f crc - ; done > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > CRC=0x192dc994 > > Should now be fixed in my git tree. Another failure: ./ffmpeg -analyzeduration 1M -y -i mm-short.mpg -vcodec copy -vframes 3 tmp.avi [in#0/mpeg @ 0x55f7cf529a40] Unable to send demuxed packet to consumers: Invalid argument [in#0/mpeg @ 0x55f7cf529a40] Task finished with error code: -22 (Invalid argument) [in#0/mpeg @ 0x55f7cf529a40] Terminating thread with return code -22 (Invalid argument) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
both should now be fixed in my tree -- 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hello, I wanted to call out 2 issues that I think are bugs from this, and that I was able to trace to the exact commit. *#1: Concat filter issues: *A user from IRC support reported it, and I was able to successfully reproduce it. When using concat filter on multiple inputs alongside -ss (same file or different file), it doesn't work correctly: output EOF after the first segment. https://trac.ffmpeg.org/ticket/10803 *#2 Wrong duration reported muxing graphical subtitles: *After re-architecture, ffmpeg CLI is printing incorrect output time and/or N/A after a job when muxing video with graphical subtitles (have reproduced with DVD and DVB). Issue is exaggerated with subtitle streams that have long gap like forced subs. https://trac.ffmpeg.org/ticket/10792 Thank you for your time and this improvement. Respectfully, On Mon, Dec 11, 2023 at 3:06 AM Anton Khirnov wrote: > both should now be fixed in my tree > > -- > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Marth64 (2024-01-16 00:51:14) > Hello, I wanted to call out 2 issues that I think are bugs from this, and > that I was able to trace to the exact commit. > > *#1: Concat filter issues: *A user from IRC support reported it, and I was > able to successfully reproduce it. > When using concat filter on multiple inputs alongside -ss (same file or > different file), it doesn't work correctly: output EOF after the first > segment. > https://trac.ffmpeg.org/ticket/10803 Thanks for the report, sent patches that should fix this. > *#2 Wrong duration reported muxing graphical subtitles: *After > re-architecture, ffmpeg CLI is printing incorrect output time and/or N/A > after a job when muxing video with graphical subtitles (have reproduced > with DVD and DVB). Issue is exaggerated with subtitle streams that have > long gap like forced subs. > https://trac.ffmpeg.org/ticket/10792 Hopefully will get to this soonish. -- 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".
