<!-- 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>
***: bingbu has joined #linux-media
<br> lexano__ has quit IRC (Ping timeout: 480 seconds)
<br> Bugies has quit IRC (Ping timeout: 480 seconds)
<br> ten157237743246305 has quit IRC (Remote host closed the connection)
<br> ten157237743246305 has joined #linux-media
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> BrianG61UK has quit IRC (Read error: Connection reset by peer)
<br> eelstrebor has quit IRC (Quit: Ex-Chat)
<br> Mo has joined #linux-media
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> ao2 has joined #linux-media
<br> djrscally has joined #linux-media
<br> GBenji has joined #linux-media
<br> charrus_ has joined #linux-media
<br> charrus has quit IRC (Ping timeout: 480 seconds)
z3ntu: <u>djrscally</u>: ok so pixel_rate is calculated based on link_freq, what's link_freq then? I see stuff like DPHY Bit clock and Output Clock in the datasheet but no direct mention of something like link frequency
<br> Finding some values now like 1075MHz which is the maximum VCO of output PLL, whatever that means
<br> that that might only be with a high mclk and my board (normally) only uses 24MHz for mclk it seems
***: ao2 has quit IRC (Quit: Leaving)
<br> charrus has joined #linux-media
z3ntu: A bit of my question also was, does the receiver on SoC side get misconfigured and cannot properly receive data if PIXEL_RATE and/or LINK_FREQ is wrong in the sensor driver?
***: charrus_ has quit IRC (Ping timeout: 480 seconds)
<br> jackson6lee has joined #linux-media
<br> syoung has joined #linux-media
djrscally: zentu link_freq is the frequency of the bus that connects the camera sensor to the receiver. On sensor drivers I've worked on it's often generated by a PLL within the sensor, usually called something like "MIPI clk"
<br> It probably depends on exactly what the receiver is; my recollection of messing it up in the past is that when the frequency is misconfigured on either the sensor or receiver you usually end up with broken data that looks like noise rather than nothing at all...but I wouldn't rule it out
<br> s/zentu/z3ntu:
***: jackson6lee has quit IRC (Remote host closed the connection)
z3ntu: <u>djrscally</u>: hm not easy... I'll keep digging a bit, maybe I find something useful...
<br> Does this link_freq depend on the resolution that's configured or the MIPI bitrate, or is the value static for a camera sensor (or at least per mclk frequency)?
djrscally: Yeah it's not easy...particularly since both of the names you gave could plausibly be the thing you're looking for.
<br> The link frequency is usually defined in devicetree and has to be supported and configured by both the camera sensor driver and the receiver's driver. It's chosen by vendors to give the best performance and as I understand it taking into account EM concerns
<br> It is _related_ to the resolution that's configured in that the link frequency will need to be high enough to support the resolutions you want to support
jmassot: <u>z3ntu</u>: the link frequency for mipi is the often given in the datasheet as the MIPI bit rate in Mbps/Gbps
djrscally: at the frame rates you want to support
jmassot: <u>z3ntu</u>: but since there is two symbols per clock pulse link freq = mipi bitrate / 2
z3ntu: "Maximum bitrate of MIPI" is "2.15 Gbps per lane" for this sensor
<br> but if it's a bit board-specific I need to check in vendor sources I guess?
jmassot: <u>z3ntu</u>: you might have some registers to set this mipi rate
<br> <u>z3ntu</u>: on the sensor
***: xiaer1922 has joined #linux-media
<br> xiaer1921 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1922 is now known as xiaer1921
djrscally: <u>z3ntu</u>: If it's just a development board it's probably less of a concern that it come from the vendor; I just mean to say that's usually how they're decided as I understand it
***: Bugies has joined #linux-media
<br> mvaittin has joined #linux-media
alien_lappy: <u>uajain</u>: hey, so, I put some codec patches based on your rpi4 test branch and got -22 on vchiq for all the modules, starting with vc_sm_cma; I enabled debug and saw this: https://pastebin.com/QUtFaxnT
<br> <u>uajain</u>: at this point, i feel like I did something wrong in the config.txt? the code is sending open and receiving closed; but since i'm a noob, i donno what the code on the other side is, is that firmware code? or some other vchiq kernel code i'm not aware of?
<br> <u>uajain</u>: any pointers or theories would be great; or maybe some doc on this?
***: gouchi has joined #linux-media
<br> gouchi has quit IRC ()
uajain: <u>alien_lappy</u>: probably the firmware code yes, I suggest you pull in the latest firmware and re-test
***: mvaittin has quit IRC (Ping timeout: 480 seconds)
z3ntu: <u>djrscally</u>: The hardware is a production phone but for now it's not important to me that it's not spending extra resources on e.g. having a faster bus if that doesn't cause any problems. Getting any image data from the sensor is good enough for me for now
alien_lappy: <u>uajain</u>: thanks, i'll go read up on how to update rpi4 firmware
***: Bugies has quit IRC (Ping timeout: 480 seconds)
CounterPillow: <u>z3ntu</u>: Fairphone 5? :)
alien_lappy: <u>uajain</u>: is this something i need to do in raspianOS itself?
***: xiaer1922 has joined #linux-media
<br> xiaer1921 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1922 is now known as xiaer1921
djrscally: <u>z3ntu</u>: Which sensor is it?
z3ntu: <u>CounterPillow</u>: Yes :)
CounterPillow: Nice
z3ntu: <u>djrscally</u>: S5KJN1SQ03 is front camera, the other sensors on the phone are IMX800 and IMX858. IMX800 I think for now is out of the question because the hardware is wired up for C-PHY and Qualcomm CAMSS doesn't seem to support C-PHY in mainline yet. The other two sensors are wired up for D-PHY
alien_lappy: <u>uajain</u>: seems like i need to use https://github.com/raspberrypi/rpi-eeprom on an actual raspian OS; thanks for all the help
djrscally: Nice indeed
***: haoshi has quit IRC (Quit: WeeChat 2.8)
<br> mvaittin has joined #linux-media
<br> Mo has quit IRC (Quit: Leaving)
<br> charrus_ has joined #linux-media
<br> charrus has quit IRC (Ping timeout: 480 seconds)
<br> Bugies has joined #linux-media
<br> xiaer1921 has quit IRC (Remote host closed the connection)
<br> xiaer1921 has joined #linux-media
<br> lexano__ has joined #linux-media
<br> charrus_ has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
<br> charrus has joined #linux-media
<br> xiaer1922 has joined #linux-media
<br> xiaer1921 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1922 is now known as xiaer1921
dv_: <u>ndufresne</u>: hm I see, I guess x264 is more aggressive in its data rate reduction, since I can go lower without frameskipping than what the H1 encoder can do
<br> <u>ndufresne</u>: also, from looking at the hantro userspace driver code, it seems that the rate control and rate distortion calcukations are done in there
<br> now I wonder if there is some sort of common rate distortion code used by upstream mem2mem drivers in cases where the actual HW does not do rate control on its own
ndufresne: <u>dv_</u>: in upstream Hantro H1 rfc, te rate control is left out to the application completely, currently it can only be driven by the size of previous size, and only uniform QP can be applied
<br> as for rate distortion, that seem specific to the chosen algorithm, in our PoC, we use PID ;-P
dv_: what's "uniform" about it?
<br> as in, one QP per picture?
<br> instead of per macroblock or such?
ndufresne: its not required to have the same QP on all the macroblocks, and H1 supports 8 regions + 4 roi
dv_: and, heh, the good ol' PID controller
ndufresne: we want to be certain our implementation was something impossible to patent
dv_: right
<br> software patents, the gift that keeps on messing things up
ndufresne: now, as for why the lower compression is bad with H1, this is because it has a pretty poor (but fast) search algorithm
dv_: ah, so poor motion compensation?
<br> makes sense - the results are not nearly as compressible then
ndufresne: we dit a comparions x264 vs H1, et found that H1 keeps using some I macroblocks in many situation were there would be an evident P option in previous frames
dv_: I also found that the imx-vpu-hantro code tends to use too low intra QP sometimes, causing IDR frames to be really big
ndufresne: x264 have a pre-process analyses, which I on paper looks brilliant, and in practice produce really nice result in selection which tool to use
***: mvaittin has quit IRC (Ping timeout: 480 seconds)
dv_: pre-process analysis? interesting
ndufresne: <u>dv_</u>: they execute some "sadamar something" complexity analyses, and that can be execute with lookahead
<br> I'm only 4-5 years away from being competent in that domain lol
CounterPillow: To truly become competent at developing video encoders, you must first master the game series "Touhou", I've been told.
linkmauve: Is writing a Touhou implementation counts? o:)
<br> It’s had built-in encoding support at some point!
dv_: hm ok so nothing that can be easily extracted and placed on top of imx-vpu-hantro for better rate control
<br> then I'll just use a fixed intra QP to reduce the intra frame sizes and make the bit rate more constant
***: GBenji has left
<br> xiaer1922 has joined #linux-media
<br> xiaer1921 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1922 is now known as xiaer1921
<br> charrus has quit IRC (Ping timeout: 480 seconds)
<br> charrus has joined #linux-media
<br> charrus_ has joined #linux-media
<br> charrus has quit IRC (Ping timeout: 480 seconds)
<br> ao2 has joined #linux-media
<br> jarthur has joined #linux-media
<br> xiaer1922 has joined #linux-media
<br> xiaer1921 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1922 is now known as xiaer1921
<br> charrus has joined #linux-media
<br> charrus_ has quit IRC (Ping timeout: 480 seconds)
<br> gouchi has joined #linux-media
<br> gouchi has quit IRC (Remote host closed the connection)
<br> gouchi has joined #linux-media
<br> gouchi has quit IRC ()
<br> BrianG61UK has joined #linux-media
<br> xiaer1922 has joined #linux-media
<br> xiaer1921 has quit IRC (Ping timeout: 480 seconds)
<br> xiaer1922 is now known as xiaer1921
<br> ten157237743246305 has quit IRC (Remote host closed the connection)
<br> ten157237743246305 has joined #linux-media
<br> Bugies has quit IRC (Ping timeout: 480 seconds)
<br> ten157237743246305 has quit IRC (Remote host closed the connection)
<br> ten157237743246305 has joined #linux-media
<br> cyrozap has quit IRC (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
<br> cyrozap has joined #linux-media
<br> ao2 has quit IRC (Quit: Leaving)
<br> djrscally has quit IRC (Ping timeout: 480 seconds)
<br> ten157237743246305 has quit IRC (Remote host closed the connection)
<br> ten157237743246305 has joined #linux-media