<sorear>
did you know you can add an ELF header to binfmt_misc and it will preempt binfmt_elf, making it impossible to launch ELF binaries
<rqou>
lol
<whitequark>
there are also HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts
<rqou>
have you tried not messing up your qemu-user-static registration? :P
egg|egg is now known as egg|zzz|egg
<sorear>
rqou: what happened is I gave someone instructions for doing a qemu-user-static registration in bash, but they decided to use zsh instead which has *slightly* different rules for backslash escapes
<rqou>
lolol
<rqou>
"Instructions said bash. WONTFIX"
<awygle>
lol
<rqou>
"Go RTFM" :P
<awygle>
Lattice Diamond on Ubuntu doesn't work because Ubuntu uses bash as sh, not dash
<rqou>
you can change it lol
<awygle>
or, the opposite actually
<awygle>
(obviously this can be fixed but it's a dumb problem to have)
<rqou>
sure
<rqou>
just like setting up USB drivers? :P
<rqou>
(obscure reference to bunnie's 33C3 talk)
<rqou>
(which was excellent btw, everybody should watch it)
<whitequark>
rqou and his obsession with not having to set up usb drivers
<rqou>
hey, not my fault that OSs make this ridiculously difficult
<rqou>
have you seen bunnie's talk?
<awygle>
daveshah: the ice40 LMs have the fast fabric, not the slow fabric, right?
<whitequark>
i don't watch talks
<whitequark>
awygle: so i wonder if we could say, make a tiny PCB that converts ct256 into sg48
<rqou>
whitequark and her obsession with trying to avoid bga :P
<whitequark>
rqou: uh
<whitequark>
i've never soldered anything with paste in my life
<awygle>
whitequark: the ct256 is twice as big
<whitequark>
do you think i should have jumped straight to bga
<whitequark>
awygle: ok then whatever package is smaller than sg48
<whitequark>
... hm
<whitequark>
that
<whitequark>
could be a problem
<awygle>
none of them have enough I/O
<whitequark>
i don't wanna redo layoooouut
<rqou>
(channeling azonenberg) yes, bga is arguably easier than non-bga :P
<awygle>
hmm maybe the 49-ball ucBGA? 39+2?
<whitequark>
awygle: that's 0.5 right?
<awygle>
0.4
<awygle>
and it's an LM
<whitequark>
hm
<whitequark>
i imagine the assembly house won't like it
<awygle>
or no, there's an LP, but only up to 1K
<whitequark>
LP1K probably doesn't have enough BRAM
<awygle>
assembly house would be fine but the adapter pcb would be $$$ is my guess
<whitequark>
ok i think i should get my ass to the lab to get the supplies
<awygle>
the LM goes up to 4k
<whitequark>
and solder it already
<awygle>
oh actually the 81-ball LP goes up to 8K and is only 4mm^2
<awygle>
that's probably the best bet if we were actually to do this
<whitequark>
how slow is LP?
<rqou>
oh what
<whitequark>
and what's the pitch?
<awygle>
still 0.4mm
<rqou>
birbsite's algorithm just showed me sparkfun's new product announcement
<whitequark>
that's pretty bad but hm
<whitequark>
we could probably manage with only two outer rows?
<rqou>
and apparently they are _still_ designing boards around dedicated audio decode asics
<rqou>
the paper on arXiv still uses the lekernel.net email
<whitequark>
ha, that has a ring oscillator made from luts
<rqou>
sb0 is really good
<azonenberg>
awygle: would it be awful
<azonenberg>
if at some point in the future i made a board (no immediate plans, just thinking out loud)
<azonenberg>
that was powered by a usb3 connector, maybe included some stock chipset from ftdi etc to negotiate "give me X power"
<azonenberg>
and then used 1000base-T as the data link? :p
<awygle>
Not awful just wasteful lol
<azonenberg>
rqou: you're thinking BUFH/BUFR
<azonenberg>
6/7 series have those
<azonenberg>
ultrascale completely revamped the clock architecture and those dont exist anymore
<rqou>
iirc the old s3 had actual clock pins that only fed a quadrant
<azonenberg>
BUFH is basically one leaf of a global clock tree
<rqou>
i guess you can file that under "silly hacks to save silicon area"
<azonenberg>
meanwhile ultrascale uses BUFG for everything and the P&R figures out which buffer(s) to actually instantiate in the hardware
<rqou>
O_o
<azonenberg>
So you can have one global clock net with different legs being used by different nets
<azonenberg>
as long as they don't overlap
<rqou>
ok, they weren't quadrant clocks
<rqou>
but s3 had "left-half" and "right-half" clock input pins
<rqou>
that appear to be separate from the global nets
<rqou>
anyways, ice40 doesn't have BUFGMUX either afaik?
<whitequark>
no it just has a few BUFGs
<rqou>
azonenberg: does your favorite micrel gigE phy do gmii?
<rqou>
or only rgmii/sgmii?
<balrog>
rqou: did m-labs not renew lekernel.net? :p
<rqou>
oh
<rqou>
lol
<rqou>
whoops
<azonenberg>
rqou: the ksz9031R is a 48-pin package that does RGMII only
<azonenberg>
90x1, i should say... the 9021 is the original, the 9031 is a more power efficient die shrink that is register and pin compatible
<azonenberg>
The vanilla 90x1 does GMII too
<azonenberg>
Afaik there is no SGMII offering
<balrog>
rqou: yeahhhh.....
<rqou>
btw azonenberg idk if you saw this, but want to try and golf a vga demo on an xc2c32a?
<balrog>
btw if anyone here is interested in open tl866 firmware work, #proghq
<awygle>
ksz9031m does gmii
<rqou>
too bad your breakout board _sucks_ and has a slow af crystal
<azonenberg>
rqou: i did see it
<azonenberg>
i actually attempted it as one of my first cpld projects
<azonenberg>
on a 32a or 64a, i forget
<azonenberg>
And failed, i never figured out what was wrong with my timing but it easily fit
<azonenberg>
I might revisit it at some point if i'm bored but i have more important thigns to do with my time right now
<azonenberg>
So it wont be any time soon
<azonenberg>
(actually it might have been an xc9500*?)
<rqou>
hmm, "easily fit?"
<rqou>
you quickly run out of macrocells for the counters unless you are smart/low resolution
<azonenberg>
I cheated and ran the system at 20 MHz
<azonenberg>
for 640x480 with a 40 MHz pixel clock
<azonenberg>
And just accepted i was actually 320x480 (i.e. smallest addressible element 2 pixels wide)
<azonenberg>
But like i said, i never got the monitor to lock to the sync
<azonenberg>
it was a modern LCD monitor and just said "invalid signal"
<azonenberg>
i had no feedback on what was wrong like a CRT would have given
<azonenberg>
So i got nowhere
<azonenberg>
i dont think i had a good LA/DSO either at the time
<whitequark>
yeah LCD monitors are picky
<whitequark>
I had that issue when generating VGA on an atmega
<rqou>
meanwhile i managed to feed what (i thought is) 240p into one of mine and it worked fine
<rqou>
looked pretty f*cked up though
<whitequark>
why do you bleep out "fuck"
<rqou>
because the aspect ratio was all wrong
<sorear>
i wonder what fraction of late-stage CRT monitors would refuse to display, say, a 481 line display
<whitequark>
late-stage CRT monitors
<rqou>
1080i CRTs :P
<azonenberg>
rqou: see my latest tweet
<azonenberg>
rqou.dad halp?
<azonenberg>
:p
<rqou>
lol
<rqou>
hrm, do i want to do this last problem set?
<rqou>
i'm pretty low on time to finish it
<rqou>
and it's "lowest score is dropped"
<balrog>
I'd try it :P
<balrog>
worst case it gets dropped
<balrog>
maybe worth looking over it first and making a calculated judgment as to how likely it is you'll get a score higher than your other lowest score :P
<rqou>
not likely lol
<rqou>
full of stuff i don't know
<rqou>
herp derp how do i do feedback linearization and sliding mode control?
<rqou>
O_o this is actually cool
<rqou>
why is nonlinear systems so much fun (both fun and DF-style "fun")
pie_ has quit [Ping timeout: 264 seconds]
<whitequark>
rqou: any idea where to get solder paste in hk?
<rqou>
i don't know
<whitequark>
unrelated
<whitequark>
there's a taobao vendor that took my money and hasn't shipped jack shit
<whitequark>
can you write a maximally scathing review?
<whitequark>
i want to make them burst in flames from shame
<rqou>
lol i don't have time for this
ym has quit [Ping timeout: 240 seconds]
<whitequark>
aw
digshadow has quit [Ping timeout: 264 seconds]
<azonenberg>
whitequark: i had a hard enough time finding halfway decent flux in HK
<azonenberg>
i have no idea what the stuff i ended up using was, it did the job ok-enough that the board worked for the week i used it after i was there
<azonenberg>
:p
<whitequark>
where did you find it?
<azonenberg>
Some random electronics store next to soldering irons with an unlabeled pot for temperature control
<azonenberg>
Lol
<azonenberg>
it was in the big market area in sham shui po, but i can't recall the exact store name or location
<azonenberg>
at least i did find 30ga wire there
<whitequark>
at the golden computer centre or outside?
<rqou>
azonenberg: apliu street?
<azonenberg>
rqou: it was a year and a half ago
<rqou>
that's the "classic" place in hk to buy "cheap electronic crap"
<azonenberg>
i recall it was like a block from the SSP mtr station
<whitequark>
ah, so not gcc
<azonenberg>
to the... north?
<azonenberg>
no, i know the GCC
<azonenberg>
i walked past it to get lunch sometimes
<rqou>
almost certainly apliu street
<azonenberg>
and it wasnt there
<azonenberg>
ok
<azonenberg>
Yeah if you were walking from the gcc to the mtr station it was on your right maybe 3 blocks?
<azonenberg>
i think
<azonenberg>
sorry i meant, straight ahead
<azonenberg>
gcc to mtr statoin and keep going
<azonenberg>
whatever direction that is :p
<whitequark>
wow, google doesn't even have gcc on the map
<azonenberg>
Do they have LLVM?
* azonenberg
hides
<whitequark>
hmmm
<whitequark>
nope
<azonenberg>
ok so i was right
<azonenberg>
golden computer arcade is on fuk wa street right across from the mcdonalds
<azonenberg>
then if you go from there down yen chow or kweilin street
<azonenberg>
kweilin, yes
<azonenberg>
you hit the SSP MTR station next block
<azonenberg>
And then apliu street
<azonenberg>
So only 2 blocks, not 3
<azonenberg>
but that was it
<azonenberg>
I can't tell you the store, we looked at several before we found al lthe stuff we needed
<azonenberg>
rqou: Not that i expect to be back there any time soon
<whitequark>
doesn't matter, i'll find it
<azonenberg>
But is there a good place in HK to buy *higher end* electronic stuff?
<azonenberg>
like, actual temp controlled irons
<azonenberg>
good tacky syringe flux
<azonenberg>
etc
<rqou>
go to SZ? :P
<whitequark>
azonenberg: sure
<whitequark>
rs components
<azonenberg>
or is that all mail order from SZ
<rqou>
azonenberg: just physically go to SZ? :P
<whitequark>
they're expensive af but it's not like you would care
<azonenberg>
(or do you just hop on a train and go to SZ)
<azonenberg>
Lol
<whitequark>
of course, mouser and farnell and digikey also deliver
<whitequark>
rs delivers """next day"""
<azonenberg>
Yeah i know, i meant a big market like SZ has where you can buy high-end stuff
<azonenberg>
in person
<azonenberg>
I guess not
<whitequark>
not really
<azonenberg>
Rather than the cheap stuff in apliu st :p
<whitequark>
too expensive i suppose
<whitequark>
the rents i mean
<azonenberg>
yeah hk is dense :p
<whitequark>
you cant get any decent electronics either
<whitequark>
like I still don't have any DDR4 ECC UDIMMs
<whitequark>
not at ssp, not at wan chai, not at that other place
<whitequark>
whatever it was called, at mong kok
<azonenberg>
the mall we met at?
<azonenberg>
isquare?
<whitequark>
no
<azonenberg>
i only really was there, SSP, and tourist central aka nathan rd
<azonenberg>
and of course mlabs
<whitequark>
mongkok computer centre apparently
wpwrak has quit [Ping timeout: 264 seconds]
wpwrak has joined ##openfpga
digshadow has joined ##openfpga
<whitequark>
rqou: amazing
<whitequark>
the vendor DID ship actually
<whitequark>
i wanted two 4GB sticks and they sent me one 8GB
<whitequark>
idiots, i was going to use two channels
<rqou>
lolol
<whitequark>
and it's a different vendor
<whitequark>
at least it's actually an ECC UDIMM and not just a random stick
<rqou>
hey balrog thanks for encouraging me to actually do the problem set
<rqou>
i actually finished it
<rqou>
wasn't as hard as i initially expected
* rqou
nomnomnomz
Sellerie has quit [Ping timeout: 255 seconds]
Sellerie has joined ##openfpga
pie_ has joined ##openfpga
Bike has quit [Quit: Lost terminal]
scrts has quit [Ping timeout: 255 seconds]
benreynwar has joined ##openfpga
ym has joined ##openfpga
pie_ has quit [Ping timeout: 248 seconds]
rohitksingh has joined ##openfpga
X-Scale has quit [Ping timeout: 248 seconds]
X-Scale has joined ##openfpga
scrts has joined ##openfpga
bitd has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
user10032 has joined ##openfpga
pie_ has joined ##openfpga
Bike has joined ##openfpga
eduardo__ has joined ##openfpga
bitd has quit [Quit: Leaving]
rohitksingh has quit [Quit: Leaving.]
Lord_Nightmare has quit [Ping timeout: 248 seconds]
Lord_Nightmare has joined ##openfpga
xdeller has quit [Ping timeout: 248 seconds]
<eduardo__>
0
rohitksingh has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
<benreynwar>
I've been looking at the icestorm and symbiflow work. Is the plan to eventually use vtr-verilog-to-routing instead of arachne-pnr and icetime?
<daveshah>
Yes, work is being done on that
<daveshah>
Chances are vtr won't be a replacement but an alternative
<daveshah>
For people who need the best possible timing performance
<daveshah>
Whereas arachne-pnr will still probably have a shorter runtime and be less "clunky"
<benreynwar>
I haven't looked into the vtr code yet. How is it clunky?
<daveshah>
The problem is that it's not really designed for real FPGA architectures
<daveshah>
Its main users are academics exploring theoretical FPGA architectures
<benreynwar>
Ah, makes sense. I like the idea of being able to use the same codebase for different architectures though. Do you expect to get arachne-pnr working with the 7-series?
<daveshah>
But a lot of this is probably fixable
<daveshah>
No, arachne-pnr is too hardcoded for the iCE40 and its algorithms also wouldn't scale well enough to a large FPGA
<daveshah>
Most likely VTR will be used for the 7-series, but in the long term maybe there will be something else altogether
<benreynwar>
OK. Then I won't spend anymore timing looking at the icestorm and arachne-pnr code, but will look at VTR instead. Is there somewhere that lists what the remaining obstacles are to getting iCE40 support there?
bitd has joined ##openfpga
<daveshah>
Have a look at the #vtr-dev channel here and the symbiflow-arch-defs repo
<daveshah>
jhol, mithro and digshadow are mostly working on this
<daveshah>
I haven't been so involved recently
<daveshah>
My basic understanding is the main activities are getting HLC output from VPR to go into icestorm, and getting a routing graph (rr_graph) that is accurate into VPR
<benreynwar>
While I've got you here, I was curious about the HLS work you're doing. Is you're plan to eventually get P&R timing information back to the synthesizer to do transformations?
<benreynwar>
It'd be pretty exciting to get these tools to the point, where people could experiment with HLS languages more easily.
<daveshah>
As it stands I haven't thought about feeding back from P&R but using approximate models
<daveshah>
Because I'm an impatient bastard and I want the fastest flow possible
<daveshah>
But it's a nice idea
<benreynwar>
Cool. My main frustration with VHDL and verilog at the moment is that there's no way to express that I don't care how long the pipeline is. With a HLS flow the pipeline length could be estimated before synthesis, and then refined after the first iteration of P&R.
<daveshah>
Yeah that's exactly why I wrote the HLS tool in the first place
<daveshah>
Rapid prototyping image processing pipelines for an AR headset project
<daveshah>
I think I must have wrote it ages ago and never used it
<daveshah>
Lucky you found that, or it would be a nasty bug one day
<cr1901_modern>
I don't enjoy writing parsers. At. All. So I'm peering over how you do it to steal ideas.
<daveshah>
Sure. Beware a disturbing percentage of the parser code was written when I was 18/19 and didn't have any formal education in this stuff
<digshadow>
daveshah: got it
<daveshah>
Yes, I really do use modified shunting yard to parse C expresssions
<cr1901_modern>
I should consider reading that PDF of Dragon Book I conveniently found online to actually learn how to write parsers
rohitksingh1 has quit [Quit: Leaving.]
<Bike>
do you need to write parsers yourself
rohitksingh has joined ##openfpga
<cr1901_modern>
I suppose not, but lex/yacc have given me lots of frustration in the past
<daveshah>
Yeah, I've always found writing parsers surprisingly satsifying
<daveshah>
*satisfying
<daveshah>
I'm not sure if I were starting that project again whether I would use lex/yacc or not
user10032 has quit [Quit: Leaving]
<awygle>
lex/yacc drive me crazy
<awygle>
but I'm really interested in other parser generator techniques
<daveshah>
ANTLR looks nicer, but adds depedency hassles
<awygle>
PEG, parser combinators, that Marpa thing, etc
<awygle>
Lark, in python
<awygle>
ANTLR looks cool but I am put off by Java. Partly from a bias standpoint and partly because none of my projects have any other Java in them so it's a whole new thing
<daveshah>
Yeah, means you need Java on your build machine too
<daveshah>
Plus you have to link a runtime to your code, which is another build step and dependency. Unlike bison etc which just generates C
rohitksingh has quit [Ping timeout: 276 seconds]
pie__ has joined ##openfpga
Lord_Nightmare2 has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
Lord_Nightmare has quit [Ping timeout: 248 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 248 seconds]
user10032 has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 264 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
GenTooMan has joined ##openfpga
<mithro>
daveshah: you should use python as the basis of your HLS language
<daveshah>
mithro: I don't like Python :P
<daveshah>
Also want something naturally strongly typed
<mithro>
daveshah: have you looked at migen/LiteX/MiSoC?
<daveshah>
Yeah, I have, I'm aiming somewhere a bit different though
<daveshah>
My HLS stuff has always been focused on a specific niche of rapid prototyping pipelined streaming systems
<daveshah>
It's never really been designed as a general HDL
<mithro>
daveshah: I'm really interested in pipeline streaming systems because I do a lot of video stuff as you know
<mithro>
When cr1901_modern get the other stuff he owes me done, I want him to work on something I've been calling PixelBone
<daveshah>
Interesting, that does look like a similar direction to where I'm looking
<daveshah>
I'll happily work on that instead as it is always better to combine efforts
<mithro>
I'm already happy to have people work on my stuff
<daveshah>
I would be interested in slightly higher level processing than some of that stuff, but overall quite similar stuff
<daveshah>
One of my big things is automatically inserting pipeline registers to meet timing
<mithro>
daveshah: I would really like the HLS to do "negotiation" around supported pixel formats / layouts / etc
<daveshah>
Yeah, that would be awesome
<daveshah>
As would stream port (AXI etc) and buffer insertion
<mithro>
IE kind of like how gstreamer works
pie___ has quit [Ping timeout: 276 seconds]
<mithro>
daveshah: yeah, all that would be awesome
<rqou>
i don't think i would have ever considered gstreamer to be something you would want to emulate
<awygle>
lol
<mithro>
It's slightly complicated by the fact some thing are "pull" IE driven by needing the pixels at a certain time for output and some are "push" they receive pixels at a given rate from an input
<rqou>
also, why the heck are you still supporting "stupid 'AV people' unfeatures" like interlacing, YUV, and chroma subsampling?
<mithro>
rqou: why? Gstreamer is by far the most flexible and performant media framework that I have come across. Very pluggable and not afraid of getting their hands dirty when performance matters.
<mithro>
rqou: because I have to interface with those systems
<rqou>
including -plugins-bad and -plugins-ugly and the hilarious .nsf CVE?
<rqou>
interlacing _still_ exists as something you want to support?
<rqou>
i thought interlacing only existed because of idiots digitizing their formerly-analog data?
<mithro>
rqou: and actually YUV makes a huge amount of sense in many applications
<rqou>
you mean "make the gpu fuck up all your colors"?
<rqou>
ime that's basically all that ever happens thanks to dumb defaults
<mithro>
rqou: mostly want to support it on the input side (to get rid of it) and on the output side (to interface with broken systems)
<awygle>
anyone have suggestions for profanity i should grep for before showing this code to anybody? (also TIL `strings python` contains SHIT)
<rqou>
lol
<rqou>
mithro: if all you want to do is record conferences, why isn't "RGB888 only" sufficient?
<mithro>
Gstreamer is pretty clear about what you are getting in their "-bad" and "-ugly" plugin groups :-P
<rqou>
my experience has been that no matter how many of -bad and -ugly groups i installed, it can still never play my mp3/h.264
<rqou>
whereas VLC just works without any messing around
<mithro>
rqou: because uni A/V systems are frequently horribly broken and we have to feed into them
pie_ has joined ##openfpga
<mithro>
rqou: if you want a media *player* then VLC is a good choice - if you want to build your own multimedia system, then gstreamer is better
<rqou>
is gstreamer a similar idea to directshow?
<daveshah>
rqou: in more general FPGA systems, YUV is very important
<rqou>
because my experience with directshow was that that is _also_ a nice disaster
<rqou>
daveshah: why?
<daveshah>
for processing output from cameras for a start
<daveshah>
many high end camera modules with built in ISPs use YUV
<daveshah>
as do video encoders/decoders
<mithro>
rqou: best I've seen is a 16:9 screen advertising a resolution of 1024*768@50Hz and _not_ supporting any other resolution while having an EDID without that format
<rqou>
i thought cameras would output either RGB or bayer-filtered grayscale?
<rqou>
daveshah: yeah, well IMHO SDI is a piece of garbage that nobody should strive to emulate
<balrog>
[15:48:15] <mithro>rqou: because uni A/V systems are frequently horribly broken and we have to feed into them
<balrog>
looool what do you have to deal with?
<mithro>
rqou: YUV gives you half the bandwidth for video at the same perceptual quality
<daveshah>
yeah
<rqou>
so does... traditional compression?
<daveshah>
and it's more useful for compressing etc
<mithro>
balrog: most of the conferences I deal with are run at Universities - but frequently we only get access to the venues we are recording like the day before to set up
<balrog>
ah...
<rqou>
why would anybody make a projector that is _50_ Hz only?
<rqou>
where do you even find this crap?
<daveshah>
europe
<daveshah>
Some cameras sold in Europe are locked to record only 50Hz too IIRC
<rqou>
i thought computers always used 60 Hz anyways?
<rqou>
i thought only TVs used 50?
<daveshah>
By default, but most computers will be fine with 50Hz once they get the EDID
<rqou>
also, i thought everybody nowadays used PAL60 or something?
<rqou>
i.e. "vidya" mostly stopped supporting 50 Hz
<daveshah>
Broadcast in the UK at least is still 50Hz
<daveshah>
1080i50, etc
<rqou>
yeah, well, broadcast is silly :P
<rqou>
daveshah: what about web video?
<daveshah>
not something I've looked at actually
<Ultrasauce>
rqou: it's pretty far off the mark to be shitting on chroma subsampling imo
<rqou>
why?
<rqou>
just use "real compression" instead of hacks?
<Ultrasauce>
literally every format uses it for a reason
<rqou>
so that you can get artifacts because every MPEG<foo> did the subsampling slightly differently? :P
<sorear>
rqou: learn2colortheory
<sorear>
rqou: rgb is computer legacy crap
<Ultrasauce>
the sampling is well-specified and consistently implemented for the most part
<Ultrasauce>
the actual colour space conversions, slightly less so
<rqou>
sorear: then you should just directly use La*b*
<rqou>
yuv is AV legacy crap :P
<rqou>
Ultrasauce: this is the bug/mistake i was thinking of: There are three variants of 4:2:0 schemes, having different horizontal and vertical siting.[7]
<rqou>
In 4:2:0 DV, Cb and Cr are co-sited in the horizontal direction. In the vertical direction, they are co-sited on alternating lines.
<rqou>
In JPEG/JFIF, H.261, and MPEG-1, Cb and Cr are sited interstitially, halfway between alternate luma samples.
<rqou>
In MPEG-2, Cb and Cr are cosited horizontally. Cb and Cr are sited between pixels in the vertical direction (sited interstitially).
<daveshah>
rqou: just checked a random online video from an Austrian broadcaster and it was indeed 25fps