| *** tpb has joined #timvideos | 00:00 | |
| *** Niharika has joined #timvideos | 03:22 | |
| *** droy has joined #timvideos | 04:52 | |
| droy | hi | 04:54 |
|---|---|---|
| Niharika | mithro: Around? | 06:10 |
| *** Niharika has left #timvideos | 06:17 | |
| *** Niharika has quit IRC | 06:17 | |
| *** Niharika has joined #timvideos | 08:08 | |
| *** droy has quit IRC | 08:39 | |
| *** droy has joined #timvideos | 08:57 | |
| *** Niharika has left #timvideos | 09:06 | |
| *** sarwarc_ has joined #timvideos | 09:18 | |
| *** sarwarc has quit IRC | 09:18 | |
| *** jahanzeb has joined #timvideos | 09:56 | |
| droy | mithro around ? | 10:09 |
| *** Niharika has joined #timvideos | 12:03 | |
| *** droy has quit IRC | 13:46 | |
| *** droy has joined #timvideos | 13:46 | |
| *** slomo has quit IRC | 14:12 | |
| *** jahanzeb has left #timvideos | 14:59 | |
| *** droy_2 has joined #timvideos | 15:13 | |
| *** droy has quit IRC | 15:13 | |
| *** droy_2 has quit IRC | 15:31 | |
| *** sarwarc_ has quit IRC | 16:43 | |
| *** sarwarc_ has joined #timvideos | 16:44 | |
| *** Niharika1 has joined #timvideos | 16:54 | |
| *** Niharika has quit IRC | 16:56 | |
| *** Niharika1 has left #timvideos | 16:57 | |
| CarlFK | is https://github.com/jahanzeb/HDMI2USB/raw/master/release/R2/pre-build /hdmi2usb_mjpeg.bit and .hex the most recent ? | 17:29 |
| CarlFK | never mind, that no longer exists | 17:42 |
| CarlFK | whatever 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 1 | 17:50 |
| *** tariq786 has joined #timvideos | 18:08 | |
| tariq786 | CarlFK or mithro! anyone of you here? | 18:09 |
| CarlFK | tariq786: here | 18:10 |
| tariq786 | hey hows it going? | 18:10 |
| tariq786 | did you get my question from yesterday? | 18:10 |
| tariq786 | ? | 18:12 |
| CarlFK | tariq786 - it can be hardcoded - use gstreamer's default of 5004 (someone can repeat this when he comes back) | 18:12 |
| tariq786 | awesome | 18:12 |
| tariq786 | do you know when joelw is gonna be here | 18:13 |
| CarlFK | well, you kinda had 2 questions | 18:13 |
| tariq786 | yes yes, please answer the 2nd question as well. THanks | 18:13 |
| CarlFK | I think.. the server will be on 5004, when a client connects I tink it will specify what port it is using. | 18:14 |
| CarlFK | so I don't think that can be hardcoded | 18:14 |
| tariq786 | it can be hardcoded initially then can be changed later. | 18:15 |
| tariq786 | I will double check by googling further and discussing with Joelw | 18:16 |
| tariq786 | do you know when joelw is gonna be around for chat? | 18:16 |
| CarlFK | no idea | 18:16 |
| tariq786 | hmm | 18:16 |
| tariq786 | ok | 18:16 |
| tariq786 | I am assuming the stream is going to be uncompressed | 18:17 |
| tariq786 | here is the packet flow | 18:17 |
| tariq786 | HDMI -> BUFFER -> RTP Packet Processing -> UDP Packet Processing -> IP Packet Processing -> MAC Packet Processing -> Marvell PHY -> bits on the wire | 18:18 |
| tariq786 | The receiving end (which is computer) will receive the UDP packets and play them live. | 18:19 |
| tariq786 | How does that sound? | 18:19 |
| tariq786 | ? | 18:21 |
| CarlFK | where is the resolution, color depth and fps defined? (I would think the client needs to know this) | 18:22 |
| tariq786 | isn't that encapsulated in HDMI frame | 18:23 |
| CarlFK | I don't know what you are reading from BUFFER | 18:25 |
| tariq786 | HDMI frame | 18:25 |
| tariq786 | Look at this | 18:26 |
| *** droy has joined #timvideos | 18:26 | |
| tariq786 | Supporting document DSD-0000326 on | 18:26 |
| tariq786 | http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS&CFID=4256119&CFTOKEN=b08e308e00594c51-2505FAB8-5056-0201-02D30F6FE617BFE7 | 18:26 |
| tariq786 | scroll to the bottom of the page | 18:27 |
| tpb | Title: Digilent Inc. - Digital Design Engineer's Source (at www.digilentinc.com) | 18:27 |
| tariq786 | if it does not make sense, no worries | 18:30 |
| CarlFK | Support Documents ? | 18:31 |
| CarlFK | ah I ssee it | 18:31 |
| CarlFK | so on the client side, what will decode that format ? | 18:33 |
| CarlFK | http://gstreamer.freedesktop.org/documentation/plugins.html I don't see anything like hdmi | 18:33 |
| tpb | <http://ln-s.net/74Zw> (at gstreamer.freedesktop.org) | 18:33 |
| CarlFK | but it may be some other name | 18:33 |
| tariq786 | hmm | 18:34 |
| tariq786 | may be | 18:34 |
| tariq786 | i can look into that | 18:34 |
| tariq786 | i think this will make the scope of the project bigger than SoC | 18:34 |
| tariq786 | i want to quantify what can be done in 3 months | 18:34 |
| CarlFK | https://github.com/timvideos/HDMI2USB-firmware-prebuilt/tree/master/Archive hdmi2usb_mjpeg.bit .hex | 18:36 |
| tpb | Title: HDMI2USB-firmware-prebuilt/Archive at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 18:36 |
| CarlFK | my guess is you should use that | 18:36 |
| CarlFK | so that it will be easier to test because we know there are libraries that can decode it | 18:37 |
| tariq786 | ok. I see your point | 18:39 |
| tariq786 | you want to transmit HDMI2USB over ethernet | 18:39 |
| tariq786 | that is absolutely fair and valid thing to do | 18:39 |
| CarlFK | Do you have the atlys board? | 18:40 |
| tariq786 | actually that is a good point | 18:40 |
| tariq786 | No i don't have that. I have other boards. If accepted, i will buy not one but two | 18:40 |
| CarlFK | why two? | 18:40 |
| tariq786 | ok never mind | 18:41 |
| tariq786 | one is good enough | 18:41 |
| tariq786 | i could donate the other one to school. You see buy one, get one free | 18:42 |
| CarlFK | ah | 18:42 |
| tariq786 | I can convince the school to buy 2 and give me one. They keep one and i keep one | 18:42 |
| tariq786 | ok i don't have atlys board right now. But does that change any thing? | 18:43 |
| CarlFK | I was hoping for help with mine | 18:43 |
| CarlFK | when I load the firmware... | 18:43 |
| CarlFK | dmesg shows: | 18:43 |
| CarlFK | [ 2599.352447] hub 3-0:1.0: unable to enumerate USB device on port 1 | 18:44 |
| tariq786 | seems like a driver issue | 18:44 |
| tariq786 | do you have linux driver for the board | 18:44 |
| tariq786 | or are you using HDMI2USB? | 18:45 |
| CarlFK | well.. before I load, lsusb shows: Bus 001 Device 019: ID 1443:0007 Digilent Development board JTAG | 18:45 |
| CarlFK | after I load, no entry on lsusb | 18:45 |
| tariq786 | you mean you load HDMI2USB? | 18:45 |
| CarlFK | right | 18:45 |
| tariq786 | ahh ok | 18:46 |
| tariq786 | hang on | 18:46 |
| CarlFK | https://github.com/timvideos/HDMI2USB/wiki/Digilent-Atlys-Board:-Loading-Firmware or https://github.com/timvideos/HDMI2USB/wiki/Firmware-load-scripts | 18:46 |
| tpb | <http://ln-s.net/-H0v> (at github.com) | 18:46 |
| tariq786 | did you use prebuilt firmware | 18:48 |
| tariq786 | or you compiled the firmware from the scratch? | 18:48 |
| CarlFK | brb | 18:50 |
| tariq786 | ok | 18:50 |
| CarlFK | using prebuilt | 18:52 |
| tariq786 | ok | 18:54 |
| tariq786 | and you followed the steps on the page that you have posted | 18:54 |
| CarlFK | the first page is a bit confusing, and I wrote the 2nd page ;) | 18:55 |
| tariq786 | where is the confusion. Can you pinpoint? | 18:57 |
| tariq786 | will be back in 20 minutes | 18:58 |
| CarlFK | when the board is first powered on, it sends a test pattern like http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/SMPTE_Color_Bars.svg/500px-SMPTE_Color_Bars.svg.png | 19:00 |
| CarlFK | kl | 19:00 |
| tpb | <http://ln-s.net/+b9K> (at upload.wikimedia.org) | 19:00 |
| tariq786 | i am back | 19:48 |
| tariq786 | Carl, i would recommend you to follow up with Jahanzeb as he is the HDMI2USB guy | 19:48 |
| tariq786 | i don't have the board so i can't follow along exactly | 19:49 |
| *** slomo has joined #timvideos | 19:53 | |
| *** slomo has joined #timvideos | 19:53 | |
| CarlFK | slomo: www.digilentinc.com/Data/Products/ATLYS/Atlys_HDMI_PLB_demo.zip 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 |
| slomo | CarlFK: ok? | 20:03 |
| CarlFK | if those frames were sent over udp to gst-launch-1.0 udpsrc... | 20:03 |
| CarlFK | is there something that would be able to make sense out of it? | 20:03 |
| slomo | not magically, also don't send raw video frames directly over udp | 20:04 |
| CarlFK | thats what I figured. just making sure | 20:05 |
| slomo | shouldn't be difficult to add support for that in one way or another, but should definitely be wrapped in some protocol | 20:05 |
| slomo | also that's RGB565, that's supported by gstreamer | 20:06 |
| CarlFK | for gsoc, trying to figure out what will keep the project simple | 20:06 |
| CarlFK | so using mjpeg is good, but might take too long to implement | 20:06 |
| slomo | mjpeg 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 |
| CarlFK | sender will be the Atlys fpga board | 20:08 |
| CarlFK | I would prefer the receiver was stable gstreamer | 20:08 |
| slomo | i see | 20:08 |
| slomo | i guess you don't want the student to implement rtp on the fpga ;) | 20:09 |
| slomo | so maybe just a stupid simple protocol that splits the frames into smaller chunks? | 20:09 |
| tariq786 | i had the same point. CarlFK suggested to implement RTP | 20:09 |
| tariq786 | I am trying to propose HDMI2Ethernet and here is the implementation pipeline | 20:10 |
| slomo | note that there's no rtp mapping that supports RGB565 to my knowledge (but for RGB24, etc), but a custom one should be easy | 20:10 |
| tariq786 | HDMI -> BUFFER -> RTP Packet Processing -> UDP Packet Processing -> IP Packet Processing -> MAC Packet Processing -> Marvell PHY -> bits on the wire | 20:10 |
| CarlFK | https://github.com/timvideos/getting-started/issues/6 | 20:10 |
| tpb | Title: [HDMI2USB #14] Supporting Marvell Ethernet chip on Digilent board · Issue #6 · timvideos/getting-started · GitHub (at github.com) | 20:10 |
| tariq786 | If i could skip RTP, i'll have one less step to work | 20:11 |
| slomo | RTP is not too difficult if you keep it minimal | 20:12 |
| slomo | and don't handle RTCP and stuff | 20:12 |
| CarlFK | I think this works: https://github.com/timvideos/HDMI2USB-firmware-prebuilt/tree/master/Archive hdmi2usb_mjpeg.bit .hex | 20:13 |
| tpb | Title: HDMI2USB-firmware-prebuilt/Archive at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com) | 20:13 |
| CarlFK | (but currently when I try to test the usb device goes away ...) | 20:14 |
| slomo | CarlFK: sending mjpeg directly over udp directly is still not great | 20:14 |
| CarlFK | I am assuming that because it is in master someone thinks it works | 20:14 |
| CarlFK | slomo: what are the down sides? | 20:16 |
| slomo | udp does not fragment packets for you, if you send packets larger than the mtu on your path the packets will silently disappear | 20:17 |
| slomo | so you need something that splits the mjpeg frames, and reassambles them on the other side | 20:17 |
| slomo | and then there are nice things like dropped packets and packet reordering :) | 20:18 |
| CarlFK | ah, so if 1/2 a frame gets dropped, you need someway to know to ignore the 2nd half, right? | 20:19 |
| slomo | well, 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 |
| slomo | rtp allows to handle all this, and in the end is also just udp with a small additional header | 20:20 |
| slomo | if you keep it simple it shouldn't be too much work to implement, compared to the other things | 20:20 |
| CarlFK | small additional header - I like the sound of that :) | 20:20 |
| tariq786 | slomo, if you have to add RTP, why not then use TCP | 20:24 |
| tariq786 | it will help in fragment and reassemble at end | 20:24 |
| slomo | tcp is difficult | 20:24 |
| CarlFK | I think tcp deals with re-transmitting | 20:24 |
| slomo | should be more fun to implement ;) | 20:25 |
| CarlFK | lol! | 20:25 |
| tariq786 | yeah right ;) | 20:25 |
| slomo | also more overhead and features you don't really want (like the retransmissions on failure) | 20:25 |
| CarlFK | yeah, if there is a error, just drop the frame and get onto the next one | 20:25 |
| tariq786 | right. it depends upon how much you implement in TCP | 20:26 |
| tariq786 | but i agree | 20:26 |
| slomo | well, if you implement tcp you want to implement enough to work with other tcp implementations | 20:26 |
| slomo | that's much much more work than just doing rtp over udp | 20:26 |
| tariq786 | true | 20:26 |
| CarlFK | ignoring bandwith, would it be ok to send RGB565 frames? | 20:26 |
| slomo | especially tcp needs communication in both directions, udp doesn't | 20:27 |
| slomo | CarlFK: what's the resolution, framerate and available bandwidth? | 20:27 |
| CarlFK | even if we have to hard code that stuff on the receiver | 20:27 |
| slomo | but sure, why not? | 20:28 |
| CarlFK | just checking. | 20:28 |
| CarlFK | I wasn't sure if the wad of bytes that the Atlys board has in memory was anything that gstremer could make use of | 20:29 |
| slomo | could implement a variant of rfc 4421 | 20:29 |
| slomo | if you want it to work without any changes on the gstreamer side, you would need to convert to RGB24 or mjpeg or whatever though | 20:30 |
| CarlFK | oh. | 20:30 |
| slomo | ah actually rfc4421 has rgb565 support | 20:31 |
| slomo | it's just not implemented in gstreamer yet, but that's easy to fix | 20:31 |
| CarlFK | yay! lol | 20:32 |
| CarlFK | I mainly want to make sure that testing isn't burdened by not knowing which side is failing | 20:32 |
| slomo | and with easy to fix i mean maybe adding 10 lines of code ;) | 20:33 |
| CarlFK | I suspect we can pick a single resolution / color depth that the Atlys will support, and so devices (laptop hdmi output) will adjust to that | 20:35 |
| CarlFK | Atlys sends, gstreamer receives = success | 20:36 |
| slomo | \o/ | 20:36 |
| CarlFK | later it can be enhanced to work with the mjpeg, which will likely take care of resolution / color depth | 20:36 |
| CarlFK | we (timvideos) have 2 uses for Atlys | 20:37 |
| CarlFK | 1. stream from a video camera | 20:37 |
| CarlFK | 2. stream from a the hdmi out of a presenter's laptop hooked to a projector | 20:38 |
| CarlFK | #1 needs ~20 fps | 20:38 |
| slomo | right, with rtp you need to communicate the stream parameters (incl resolution) out of band somehow | 20:38 |
| CarlFK | #2 can get by with about 2 :p | 20:38 |
| CarlFK | for gsoc, I am OK picking a set of parameters that get hardcoded on both sides | 20:39 |
| CarlFK | let's hope mithro is too :D | 20:40 |
| slomo | is there some kind of other communication with the atlys? like for telling it to start sending? | 20:40 |
| CarlFK | well... there is usb, but personally I wold hope not to need that | 20:41 |
| CarlFK | otherwise I envision a raspberry pi and 4 port eithernet hub tied to the top of the atlys | 20:42 |
| CarlFK | and a power bar | 20:42 |
| CarlFK | and lots of rubber bands to hold it all together | 20:42 |
| CarlFK | slomo: are you at all familiar with http://dvswitch.alioth.debian.org/wiki/ ? | 20:43 |
| tpb | Title: DVswitch (at dvswitch.alioth.debian.org) | 20:43 |
| CarlFK | it is what we use for recording presentations | 20:43 |
| slomo | i read that wikipage once :) | 20:44 |
| CarlFK | http://dvswitch.alioth.debian.org/wiki/component_interaction/#small "VGA to DV" | 20:46 |
| tpb | Title: component interaction (at dvswitch.alioth.debian.org) | 20:46 |
| CarlFK | that is currently a Canopus Twinpact100 | 20:46 |
| CarlFK | we want to replace it | 20:46 |
| CarlFK | that is use #2 | 20:47 |
| CarlFK | for interfacing to hdmi cameras, personally I am OK with using usb | 20:47 |
| CarlFK | The compression/resolution/fps is less than desirable, but to me it is good enough for seeing someone's face | 20:48 |
| *** techman83 has quit IRC | 20:48 | |
| *** sarwarc_ has quit IRC | 20:48 | |
| CarlFK | slomo: why do you ask about other communication? | 20:49 |
| slomo | you could exchange information about the resolution and other stuff then | 20:51 |
| CarlFK | way too complicated | 20:54 |
| *** techman83 has joined #timvideos | 20:55 | |
| CarlFK | that would all be handed with mjpeg/rtp, right? | 20:55 |
| *** ChanServ sets mode: +v techman83 | 20:55 | |
| slomo | with jpeg over rtp, yes... just need to tell the atlys a port and ip where it should send the data | 20:56 |
| *** techman83 has quit IRC | 21:01 | |
| *** sarwarc_ has joined #timvideos | 21:05 | |
| CarlFK | I am hoping we can get by with a static IP | 21:06 |
| CarlFK | then implement dhcp later | 21:06 |
| slomo | the ip on the sender doesn't really matter, you just need to tell the sender where to send the packets | 21:09 |
| CarlFK | isn't that normally done when the client connects? (I have never really studied this stuff) | 21:11 |
| slomo | there is no connection, we're talking about udp here | 21:13 |
| slomo | data just goes from the sender to the receiver | 21:13 |
| *** techman83 has joined #timvideos | 21:15 | |
| *** ChanServ sets mode: +v techman83 | 21:15 | |
| CarlFK | gst-launch-1.0 udpsrc uri=udp://127.0.0.1:5004 caps="application/x-rtp" ! queue ! rtpjitterbuffer ! rtpjpegdepay ! queue ! avdec_mjpeg ! videoconvert ! videoscale ! autovideosink | 21:19 |
| CarlFK | doesn't that tell the source where to send to? | 21:19 |
| CarlFK | source being: gst-launch-1.0 videotestsrc is-live=true pattern=18 ! avenc_mjpeg ! rtpjpegpay ! udpsink host=127.0.0.1 | 21:19 |
| slomo | no | 21:22 |
| slomo | it just captures whatever arrives on 127.0.0.1 on port 5004 | 21:22 |
| CarlFK | oh neat. gsoc thing just got a little easier (well, in my eyes. seems it already was easier ) | 21:24 |
| *** slomo has quit IRC | 21:35 | |
| droy | hi | 22:05 |
| droy | CarlFK hi | 22:08 |
| CarlFK | hi droy | 22:11 |
| *** droy has quit IRC | 22:43 | |
| *** droy has joined #timvideos | 22:45 | |
| *** droy has quit IRC | 23:18 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!
