Hi Benjamin, On Wed, 2020-11-04 at 17:49 +0000, Benjamin Bara - SKIDATA wrote: > > -----Original Message----- > > From: Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> > > Sent: Mittwoch, 4. November 2020 18:01 > > Hi again! > > > Many thanks for your report. Indeed you managed to create a video that is quite > > problematic for CODA. > > Thanks for looking at it! > > > I must admit I can't fully wrap my head around your prefetch fix, and how the new > > condition would fix this issue. Could you explain it in more detail? > > I don't have access to the CODA960 documentation, so all my findings are based on tests > or code documentation. > > My starting point was the inline documentation [1]: > "If we managed to fill in at least a full reorder window of buffers and the bitstream > prefetcher has at least 2 256 bytes periods beyond the first buffer to fetch (...)". > > The current code checks if there are 512 bytes after the current meta. > When I comment out the following break, my test videos are working. > So for me, starvation is caused by this statement, because it hinders follow-up metas > for performance reasons (the decoder might also start hiccuping with too much data enqueued, > but not sure). > > I did some tests, and basically I found out that the sum doesn't matter, so something like > - Meta 2: 1024 > - Meta 3: 100 > - Meta 4: 100 > starves, even if it passes the current check. > > Next, I thought about "2x 256" is actually not the same as "1x 512". > With 2x 256, I could actually got a couple more test videos running, something like: > - Meta 2: 650 > - Meta 3: 50 > - Meta 4: 650 > > The crafting of such video is quite easy by varying the Group-of-Picture and the resolution. > > However, then I tried some smaller videos (with meta 2 & 4: 256 < meta < 512) > which lead to starvation again. > I haven't done additional tests, instead I shared my findings and asked for further documentation > hints about the actual starvation criteria. > > So my solution is just a Proof-of-Concept, found by testing and is not backed by documentation - > therefore I am also not sure if it is sufficient or has any side effects. > Please submit your patch on top of latest media master branch and let's start discussing it. BTW, Nicolas and I have started using https://github.com/fluendo/fluster/ conformance testing. Perhaps you can run the H264 test suite, with & without your patch (assuming it affects H264 in any way) and include that information in the cover letter. Thanks! Ezequiel
