Sunday, 2014-04-06

*** tpb has joined #timvideos00:00
*** Niharika has joined #timvideos03:22
*** droy has joined #timvideos04:52
Niharikamithro: Around?06:10
*** Niharika has left #timvideos06:17
*** Niharika has quit IRC06:17
*** Niharika has joined #timvideos08:08
*** droy has quit IRC08:39
*** droy has joined #timvideos08:57
*** Niharika has left #timvideos09:06
*** sarwarc_ has joined #timvideos09:18
*** sarwarc has quit IRC09:18
*** jahanzeb has joined #timvideos09:56
droymithro around ?10:09
*** Niharika has joined #timvideos12:03
*** droy has quit IRC13:46
*** droy has joined #timvideos13:46
*** slomo has quit IRC14:12
*** jahanzeb has left #timvideos14:59
*** droy_2 has joined #timvideos15:13
*** droy has quit IRC15:13
*** droy_2 has quit IRC15:31
*** sarwarc_ has quit IRC16:43
*** sarwarc_ has joined #timvideos16:44
*** Niharika1 has joined #timvideos16:54
*** Niharika has quit IRC16:56
*** Niharika1 has left #timvideos16:57
CarlFKis /hdmi2usb_mjpeg.bit and .hex the most recent ?17:29
CarlFKnever mind, that no longer exists17:42
CarlFKwhatever I load, things aren't working, I think this is key: [ 1429.988319] hub 3-0:1.0: unable to enumerate USB device on port 117:50
*** tariq786 has joined #timvideos18:08
tariq786CarlFK or mithro! anyone of you here?18:09
CarlFKtariq786: here18:10
tariq786hey hows it going?18:10
tariq786did you get my question from yesterday?18:10
CarlFKtariq786 - it can be hardcoded - use gstreamer's default  of  5004 (someone can repeat this when he comes back)18:12
tariq786do you know when joelw is gonna be here18:13
CarlFKwell, you kinda had 2 questions18:13
tariq786yes yes, please answer the 2nd question as well. THanks18:13
CarlFKI think.. the server will be on 5004, when a client connects I tink it will specify what port it is using.18:14
CarlFKso I don't think that can be hardcoded18:14
tariq786it can be hardcoded initially then can be changed later.18:15
tariq786I will double check by googling further and discussing with Joelw18:16
tariq786do you know when joelw is gonna be around for chat?18:16
CarlFKno idea18:16
tariq786I am assuming the stream is going to be uncompressed18:17
tariq786here is the packet flow18:17
tariq786HDMI -> BUFFER -> RTP Packet Processing -> UDP Packet Processing -> IP Packet Processing -> MAC Packet Processing -> Marvell PHY -> bits on the wire18:18
tariq786The receiving end (which is computer) will receive the UDP packets and play them live.18:19
tariq786How does that sound?18:19
CarlFKwhere is the resolution, color depth and fps defined?  (I would think the client needs to know this)18:22
tariq786isn't that encapsulated in HDMI frame18:23
CarlFKI don't know what you are reading from BUFFER18:25
tariq786HDMI frame18:25
tariq786Look at this18:26
*** droy has joined #timvideos18:26
tariq786Supporting document DSD-0000326 on18:26
tariq786scroll to the bottom of the page18:27
tpbTitle: Digilent Inc. - Digital Design Engineer's Source (at
tariq786if it does not make sense, no worries18:30
CarlFKSupport Documents ?18:31
CarlFKah  I ssee it18:31
CarlFKso on the client side, what will decode that format ?18:33
CarlFK  I don't see anything like hdmi18:33
tpb<> (at
CarlFKbut it may be some other name18:33
tariq786may be18:34
tariq786i can look into that18:34
tariq786i think this will make the scope of the project bigger than SoC18:34
tariq786i want to quantify what can be done in 3 months18:34
CarlFK  hdmi2usb_mjpeg.bit .hex18:36
tpbTitle: HDMI2USB-firmware-prebuilt/Archive at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at
CarlFKmy guess is you should use that18:36
CarlFKso that it will be easier to test because we know there are libraries that can decode it18:37
tariq786ok. I see your point18:39
tariq786you want to transmit HDMI2USB over ethernet18:39
tariq786that is absolutely fair and valid thing to do18:39
CarlFKDo you have the atlys board?18:40
tariq786actually that is a good point18:40
tariq786No i don't have that. I have other boards. If accepted, i will buy not one but two18:40
CarlFKwhy two?18:40
tariq786ok never mind18:41
tariq786one is good enough18:41
tariq786i could donate the other one to school. You see buy one, get one free18:42
tariq786I can convince the school to buy 2 and give me one. They keep one and i keep one18:42
tariq786ok i don't have atlys board right now. But does that change any thing?18:43
CarlFKI was hoping for help with mine18:43
CarlFKwhen I load the firmware...18:43
CarlFKdmesg shows:18:43
CarlFK[ 2599.352447] hub 3-0:1.0: unable to enumerate USB device on port 118:44
tariq786seems like a driver issue18:44
tariq786do you have linux driver for the board18:44
tariq786or are you using HDMI2USB?18:45
CarlFKwell.. before I load, lsusb shows: Bus 001 Device 019: ID 1443:0007 Digilent Development board JTAG18:45
CarlFKafter I load, no entry on lsusb18:45
tariq786you mean you load HDMI2USB?18:45
tariq786ahh ok18:46
tariq786hang on18:46
CarlFK  or
tpb<> (at
tariq786did you use prebuilt firmware18:48
tariq786or you compiled the firmware from the scratch?18:48
CarlFKusing prebuilt18:52
tariq786and you followed the steps on the page that you have posted18:54
CarlFKthe first page is a bit confusing, and I wrote the 2nd page ;)18:55
tariq786where is the confusion. Can you pinpoint?18:57
tariq786will be back in 20 minutes18:58
CarlFKwhen the board is first powered on, it sends a test pattern like
tpb<> (at
tariq786i am back19:48
tariq786Carl, i would recommend you to follow up with Jahanzeb as he is the HDMI2USB guy19:48
tariq786i don't have the board so i can't follow along exactly19:49
*** slomo has joined #timvideos19:53
*** slomo has joined #timvideos19:53
CarlFKslomo:  bottom of page 4: "Memory Format of Frame Buffer Video data is stored linearly in memory as 16 bit pixels with the upper left hand pixel of the frame...."20:02
slomoCarlFK: ok?20:03
CarlFKif those frames were sent over udp to gst-launch-1.0 udpsrc...20:03
CarlFKis there something that would be able to make sense out of it?20:03
slomonot magically, also don't send raw video frames directly over udp20:04
CarlFKthats what I figured.  just making sure20:05
slomoshouldn't be difficult to add support for that in one way or another, but should definitely be wrapped in some protocol20:05
slomoalso that's RGB565, that's supported by gstreamer20:06
CarlFKfor gsoc, trying to figure out what will keep the project simple20:06
CarlFKso using mjpeg is good, but might take too long to implement20:06
slomomjpeg over raw udp has the same problems, but what's the goal here? will the sender and receiver side code be written by the student?20:07
CarlFKsender will be the Atlys fpga board20:08
CarlFKI would prefer the receiver was stable gstreamer20:08
slomoi see20:08
slomoi guess you don't want the student to implement rtp on the fpga ;)20:09
slomoso maybe just a stupid simple protocol that splits the frames into smaller chunks?20:09
tariq786i had the same point. CarlFK suggested to implement RTP20:09
tariq786I am trying to propose HDMI2Ethernet and here is the implementation pipeline20:10
slomonote that there's no rtp mapping that supports RGB565 to my knowledge (but for RGB24, etc), but a custom one should be easy20:10
tariq786HDMI -> BUFFER -> RTP Packet Processing -> UDP Packet Processing -> IP Packet Processing -> MAC Packet Processing -> Marvell PHY -> bits on the wire20:10
tpbTitle: [HDMI2USB #14] Supporting Marvell Ethernet chip on Digilent board · Issue #6 · timvideos/getting-started · GitHub (at
tariq786If i could skip RTP, i'll have  one less step to work20:11
slomoRTP is not too difficult if you keep it minimal20:12
slomoand don't handle RTCP and stuff20:12
CarlFKI think this works:  hdmi2usb_mjpeg.bit .hex20:13
tpbTitle: HDMI2USB-firmware-prebuilt/Archive at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at
CarlFK(but currently when I try to test the usb device goes away ...)20:14
slomoCarlFK: sending mjpeg directly over udp directly is still not great20:14
CarlFKI am assuming that because it is in master someone thinks it works20:14
CarlFKslomo: what are the down sides?20:16
slomoudp does not fragment packets for you, if you send packets larger than the mtu on your path the packets will silently disappear20:17
slomoso you need something that splits the mjpeg frames, and reassambles them on the other side20:17
slomoand then there are nice things like dropped packets and packet reordering :)20:18
CarlFKah, so if 1/2 a frame gets dropped, you need someway to know to ignore the 2nd half, right?20:19
slomowell, or show what can be shown. but you need to notice it, and especially it could be that you get a part of the next frame before the last part of the current frame ;)20:19
slomortp allows to handle all this, and in the end is also just udp with a small additional header20:20
slomoif you keep it simple it shouldn't be too much work to implement, compared to the other things20:20
CarlFKsmall additional header - I like the sound of that :)20:20
tariq786slomo, if  you have to add RTP, why not then use TCP20:24
tariq786it will help in fragment and reassemble at end20:24
slomotcp is difficult20:24
CarlFKI think tcp deals with re-transmitting20:24
slomoshould be more fun to implement ;)20:25
tariq786yeah right ;)20:25
slomoalso more overhead and features you don't really want (like the retransmissions on failure)20:25
CarlFKyeah, if there is a error, just drop the frame and get onto the next one20:25
tariq786right. it depends upon how much you implement in TCP20:26
tariq786but i agree20:26
slomowell, if you implement tcp you want to implement enough to work with other tcp implementations20:26
slomothat's much much more work than just doing rtp over udp20:26
CarlFKignoring bandwith, would it be ok to send RGB565 frames?20:26
slomoespecially tcp needs communication in both directions, udp doesn't20:27
slomoCarlFK: what's the resolution, framerate and available bandwidth?20:27
CarlFKeven if we have to hard code that stuff on the receiver20:27
slomobut sure, why not?20:28
CarlFKjust checking.20:28
CarlFKI wasn't sure if the wad of bytes that the Atlys board has in memory was anything that gstremer could make use of20:29
slomocould implement a variant of rfc 442120:29
slomoif you want it to work without any changes on the gstreamer side, you would need to convert to RGB24 or mjpeg or whatever though20:30
slomoah actually rfc4421 has rgb565 support20:31
slomoit's just not implemented in gstreamer yet, but that's easy to fix20:31
CarlFKyay! lol20:32
CarlFKI mainly want to make sure that testing isn't burdened by not knowing which side is failing20:32
slomoand with easy to fix i mean maybe adding 10 lines of code ;)20:33
CarlFKI suspect we can pick a single resolution / color depth that the Atlys will support, and so devices (laptop hdmi output) will adjust to that20:35
CarlFKAtlys sends, gstreamer receives = success20:36
CarlFKlater it can be enhanced to work with the mjpeg, which will likely take care of resolution / color depth20:36
CarlFKwe (timvideos) have 2 uses for Atlys20:37
CarlFK1. stream from a video camera20:37
CarlFK2. stream from a the hdmi out of a presenter's laptop hooked to a projector20:38
CarlFK#1 needs ~20 fps20:38
slomoright, with rtp you need to communicate the stream parameters (incl resolution) out of band somehow20:38
CarlFK#2 can get by with about 2 :p20:38
CarlFKfor gsoc, I am OK picking a set of parameters that get hardcoded on both sides20:39
CarlFKlet's hope mithro is too :D20:40
slomois there some kind of other communication with the atlys? like for telling it to start sending?20:40
CarlFKwell... there is usb, but personally I wold hope not to need that20:41
CarlFKotherwise I envision a raspberry pi and 4 port eithernet hub tied to the top of the atlys20:42
CarlFKand a power bar20:42
CarlFKand lots of rubber bands to hold it all together20:42
CarlFKslomo: are you at all familiar with  ?20:43
tpbTitle: DVswitch (at
CarlFKit is what we use for recording presentations20:43
slomoi read that wikipage once :)20:44
CarlFK  "VGA to DV"20:46
tpbTitle: component interaction (at
CarlFKthat is currently a Canopus Twinpact10020:46
CarlFKwe want to replace it20:46
CarlFKthat is use #220:47
CarlFKfor interfacing to hdmi cameras, personally I am OK with using usb20:47
CarlFKThe compression/resolution/fps is less than desirable, but to me it is good enough for seeing someone's face20:48
*** techman83 has quit IRC20:48
*** sarwarc_ has quit IRC20:48
CarlFKslomo: why do you ask about other communication?20:49
slomoyou could exchange information about the resolution and other stuff then20:51
CarlFKway too complicated20:54
*** techman83 has joined #timvideos20:55
CarlFKthat would all be handed with mjpeg/rtp, right?20:55
*** ChanServ sets mode: +v techman8320:55
slomowith jpeg over rtp, yes... just need to tell the atlys a port and ip where it should send the data20:56
*** techman83 has quit IRC21:01
*** sarwarc_ has joined #timvideos21:05
CarlFKI am hoping we can get by with a static IP21:06
CarlFKthen implement dhcp later21:06
slomothe ip on the sender doesn't really matter, you just need to tell the sender where to send the packets21:09
CarlFKisn't that normally done when the client connects?   (I have never really studied this stuff)21:11
slomothere is no connection, we're talking about udp here21:13
slomodata just goes from the sender to the receiver21:13
*** techman83 has joined #timvideos21:15
*** ChanServ sets mode: +v techman8321:15
CarlFKgst-launch-1.0 udpsrc uri=udp:// caps="application/x-rtp" ! queue ! rtpjitterbuffer ! rtpjpegdepay ! queue ! avdec_mjpeg ! videoconvert ! videoscale ! autovideosink21:19
CarlFKdoesn't that tell the source where to send to?21:19
CarlFKsource being: gst-launch-1.0 videotestsrc is-live=true pattern=18 ! avenc_mjpeg ! rtpjpegpay ! udpsink host=
slomoit just captures whatever arrives on on port 500421:22
CarlFKoh neat.  gsoc thing just got a little easier (well, in my eyes. seems it already was easier )21:24
*** slomo has quit IRC21:35
droyCarlFK hi22:08
CarlFKhi droy22:11
*** droy has quit IRC22:43
*** droy has joined #timvideos22:45
*** droy has quit IRC23:18

Generated by 2.12.1 by Marius Gedminas - find it at!