<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   paulk-leonov: if we're to re-send h264, could be work having h265 along with it
   <br> so that we can focus on improving the interface
   <br> could be worth*
   hverkuil: paulk-leonov: Fine by me.
   paulk-leonov: ndufresne, another thing, how about ditching CamelCase as much as possible in the libva backend?
   <br> hverkuil, great, so feel free to ping me whenever you feel the need for rebased series :)
   hverkuil: Just post it once 5.2-rc1 is merged in our master.
   <br> (should happen next week)
   paulk-leonov: noted
   hverkuil: Did I remember it correctly that you will also post a new h264 series?
   paulk-leonov: hverkuil, indeed, either I'll send the rebased version or mripard will do it
   hverkuil: OK, I'll remove my old pull request from patchwork.
   <br> BTW, today is a public holiday in Norway, so I will be absent here for most of the day.
   paulk-leonov: oh I see, have a nice holiday then :)
   ***: sailus_ has left
   <br> prabhakarlad has left
   <br> benjiG has left
   koike: o/ I'm trying to compile v4l-utils in arm64, but I'm getting this not so useful message "moc: could not find a Qt installation of ''", I wonder if anyone have an idea of what is missing
   shuah: <u>koike</u>: you have to install qt packages - let me give you the list from my dpkg
   <br> <u>koike</u>: I installed qt5-default on Ubuntu - that pulled in others - start there
   koike: <u>shuah</u>: thanks! I thought I had qt5-default installed, it turns out I hadn't, now the compilation didn't stop at that point anymore, thanks a lot
   shuah: Great
   koike: <u>neg</u>: Hi, I remember you mentioned that you had managed to get the media framework to allow multiple streams at the same time in the same topology. tonyk is working to add an output video device in vimc, and he is testing with an output-&gt;capture topology (a loopback), but he can't stream in both entities
   neg: <u>koike</u>: I managed to get to two streams running with a hack and it crashed horribly when one tried to stop one of them, so "working" is stretching it a bit ;-)
   ndufresne: paulk-leonov, I really like that we had came case to match the ops function, but the namespace Request is quite random to me, I'd use v4l2_
   paulk-leonov: agreed
   ndufresne: paulk-leonov, so I've replied on your last message about start-code, that was not my favorite, but I've given all my argument, tfiga and you still things start-code is better, so I guess we'll add start-codes
   <br> * thinks
   <br> paulk-leonov, I also notice the STDC registers, (start code detector), there is a reg that give you back the end pointer, just like the hantro and the rkvdec
   <br> if you can figure-out how that works, it means changing this would be with no extra cost, and no rist that the slice data is no longer aligned as expected (if the pointer needs any alignment in the first place)
   paulk-leonov: ndufresne, that's because the engine has some helper block for parsing the bitstream
   <br> it doesn't really have any logic
   <br> and we want to avoid parsing in kernel drivers
   <br> any logic wrt configuring the pipeline
   <br> ndufresne, also I have quite mixed feelings about the start code thing
   <br> and we haven't reached a consensus I'm not sure we should go along with it
   <br> I mean, what you are suggesting is the clean proper way
   <br> if you're not buying the quirky way that I think could be more beneficial, then there's a chance it's not that beneficial
   <br> and you make good points
   <br> I guess I'll need the week-end to think it over :)
   <br> as we haven't reached a consensus*
   Kwiboo: ndufresne, bbrezillon: I found a timestamp issue in ffmpeg code yesterday that affected field encoded h264 references due to wrong predicted timestamp, should be fixed by https://github.com/Kwiboo/FFmpeg/commit/40b957f924f73b679c6166b89c88857866d6ed9a (setting initial timestamp after querybuf)
   <br> also changed to use index + 1 in order to avoid using timestamp=0 as a valid reference
   <br> that change fixes the issue jernej had with his vsynctest.ts sample and using copying_timestamp
   ndufresne: paulk-leonov, totally agree, I think I made the answer of someone getting borred of not having a better answer :-S ok, hopefully weekend will help setting this, I do have a 3 day weekend !
   <br> Kwiboo, ok, but why is timestamp 0 a problem ?
   <br> Kwiboo, paulk-leonov: Just a curiosity, you know that parameters in V4L2 are always in/out, and that you are suppose to validate that the driver didn't change anything ?
   <br> just asking, since I saw things like S_FMT followed by G_FMT in the VA driver notably, but now I see this error where it expected the driver not to change the timestamp in QBUF