Hi Benjamin, On Mon, 2020-10-12 at 14:47 +0000, Benjamin Bara - SKIDATA wrote: > Hi Ezequiel! > > I applied your series on top of bbf5c979011a099af5dc76498918ed7df445635b (5.9 tag). > Additionally, I applied the attached patch to print the active metas during coda_fill_bitstream(): > 0001-DEBUG-coda-print-list-of-current-active-metas.patch > > For verification, I used the attached single-color video: > MPEG4, 512x512, ~135 kb/s, 20 FPS, GoP = 5; see below for reproduction steps. > This might be a very "hard" and "theoretical" sample. > However, with this video, I still get a timeout (see error log below). > > When applying my "simplistic approach" (second patch) on top of that, the video is working. > I saw a padding to 512 byte in the H.264 implementation, therefore I assumed it's the same here. > Since I don't know how to pad the MPEG4 stream, I decided to keep adding frames > until the "requirement" (I have no documentation for that) is reached. > Therefore, this patch ensures that there are at least two buffers queued > which reach the 512 byte threshold (for simplistic reasons 3, since "beyond the current one"). > > Note that the second patch is also just a proof of concept, there might be more efficient solutions. > > If your reproduction attempts lead to different results, please write me an email. > > Regards & many thanks! > Benjamin > > > *Video creation:* > 1.) Create single color video: > gst-launch-1.0 videotestsrc num-buffers=100 pattern=blue ! \ > video/x-raw,format=I420,width=512,height=512 ! v4l2mpeg4enc output-io-mode=4 ! \ > avimux ! filesink location=temp.avi > > 2.) Re-encode with a GoP (IIRC this option is not provided by v4l2mpeg4enc, > even though enabled in the driver; I usually do this on my test pc, not the SuT): > ffmpeg -i temp.avi -vf scale=512:512 -vtag "xvid" -g 5 mpeg4.avi > > *Error log:* > [ 1067.150368] coda 2040000.vpu: 0: start streaming vid-cap > [ 1067.164871] coda 2040000.vpu: 0: not ready: need 2 buffers available (queue:1 + bitstream:0) > [ 1067.165490] coda 2040000.vpu: 0: job ready > [ 1067.166682] coda 2040000.vpu: 0: active metas: > [ 1067.166692] coda 2040000.vpu: 0: - payload: 60 > [ 1067.166697] coda 2040000.vpu: 0: - payload: 2913 > [ 1067.166702] coda 2040000.vpu: 0: - payload: 155 > [ 1067.166706] coda 2040000.vpu: 0: - payload: 155 > [ 1067.166711] coda 2040000.vpu: 0: - payload: 155 > [ 1067.166715] coda 2040000.vpu: 0: want to queue: payload: 155 > [ 1067.166973] coda 2040000.vpu: 0: active metas: > [ 1067.166982] coda 2040000.vpu: 0: - payload: 60 > [ 1067.166987] coda 2040000.vpu: 0: - payload: 2913 > [ 1067.166992] coda 2040000.vpu: 0: - payload: 155 > [ 1067.166996] coda 2040000.vpu: 0: - payload: 155 > [ 1067.167000] coda 2040000.vpu: 0: - payload: 155 > [ 1067.167005] coda 2040000.vpu: 0: want to queue: payload: 155 > [ 1068.168449] coda 2040000.vpu: CODA PIC_RUN timeout > Many thanks for your report. Indeed you managed to create a video that is quite problematic for CODA. Adding some debugging code to dump the metas, and then inspect the bitstream payload before/after a sync, we can see that the hardware buffer has 690 bytes. This seems a bit confusing, since the driver considers it's enough. From the log below, isn't this supposed to be enough metas? [ 274.087643] coda 2040000.vpu: CODA PIC_RUN timeout [ 274.092655] coda 2040000.vpu: meta 2: 432 - 804 (00 00 01 b0 01) [ 274.099133] coda 2040000.vpu: meta 3: 804 - 1176 (00 00 01 b0 01) [ 274.105551] coda 2040000.vpu: meta 4: 1176 - 1548 (00 00 01 b0 01) [ 274.112200] coda 2040000.vpu: meta 5: 1548 - 1920 (00 00 01 b0 01) [ 274.118840] coda 2040000.vpu: meta 6: 1920 - 2292 (00 00 01 b0 01) [ 274.125347] coda 2040000.vpu: bitstream payload: 690 (before sync) [ 274.130627] coda 2040000.vpu: bitstream payload: 690 (after sync) Philipp, what do you think? 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? Why wouldn't the prefetcher count chunks smaller than 512? Do you have some documentation for that? Thanks, Ezequiel
