| *** tpb has joined #timvideos | 00:00 | |
| *** CarlFK has quit IRC | 00:03 | |
| *** techman83|home has joined #timvideos | 00:54 | |
| *** hyades has quit IRC | 01:07 | |
| *** sb0_ has joined #timvideos | 02:54 | |
| *** CarlFK has joined #timvideos | 04:02 | |
| *** ChanServ sets mode: +v CarlFK | 04:02 | |
| *** hyades has joined #timvideos | 04:02 | |
| *** sb0_ has quit IRC | 04:15 | |
| *** sb0_ has joined #timvideos | 04:23 | |
| mithro | MaZderMind: btw I'm actually not worried about the stability of the system under "static" conditions | 06:51 |
|---|---|---|
| mithro | MaZderMind: I did start writing down the things that I'm concerned about | 06:51 |
| *** sb0_ has quit IRC | 07:17 | |
| *** Niharika has joined #timvideos | 07:21 | |
| *** techman83|home has quit IRC | 09:20 | |
| *** Niharika has quit IRC | 09:35 | |
| mithro | MaZderMind: I'm around this evening if you are about and what to chat | 10:32 |
| *** tija has joined #timvideos | 12:17 | |
| mithro | hey tija! | 12:34 |
| mithro | Welcome back | 12:34 |
| tija | mithro: Hi! | 12:35 |
| tija | mithro: I finally got a job in a FPGA based company. They are trying to accelerate data centers using FPGA. | 12:36 |
| mithro | How's the job hunting going? | 12:37 |
| mithro | Ahh cool! | 12:37 |
| tija | http://www.reniac.com/ | 12:37 |
| tpb | Title: rENIAC Inc (at www.reniac.com) | 12:37 |
| mithro | tija: you should make sure that you get agreement from them to allow you to contribute to FOSS FPGA projects | 12:37 |
| tija | mithro: Do companies have problem with FOSS projects? | 12:38 |
| mithro | tija: they can | 12:39 |
| tija | mithro: Okay. Btw I was trying to add switch to change the resolution. I couldn't get it working yet. Sometimes I feel to chuck HDMI2USB and start everything from scratch. | 12:42 |
| mithro | tija: that is easy to say, but nobody has the time to rewrite everything | 12:44 |
| mithro | tija: I've been looking at misoc/migen stuff a bit | 12:44 |
| mithro | tija: it has everything apart from the mjpeg encoder and the usb interface | 12:45 |
| mithro | tija: why is the switch so hard? | 12:47 |
| tija | mithro: There are some signals whose functioning I don't understand. Is there a relation between DVI and 1024*768 and HDMI and 720p? | 12:49 |
| mithro | Well, DVI and HDMI are the same signal standard? | 12:50 |
| tija | mithro: What I understand is HDMI is DVI with audio. Isn't it? | 12:51 |
| mithro | tija: yeah, but we totally ignore all the audio data | 12:51 |
| tija | mithro: https://github.com/timvideos/HDMI2USB/blob/master/hdl/misc/controller.vhd | 12:52 |
| tpb | Title: HDMI2USB/controller.vhd at master · timvideos/HDMI2USB · GitHub (at github.com) | 12:52 |
| tija | look at line 61 | 12:52 |
| mithro | tija: hrm? | 12:53 |
| *** Niharika has joined #timvideos | 12:54 | |
| tija | and then 276 to 291 | 12:54 |
| tija | this is the part which causes the resolution to change using cdc commands | 12:56 |
| mithro | Well line 290 looks wrong | 12:57 |
| tija | oh yeah | 12:57 |
| mithro | tija: something for you to review -> https://github.com/timvideos/HDMI2USB/pull/125 | 13:00 |
| tpb | Title: Fix forcing HDMI port 1 to 1024x768 mode. by mithro · Pull Request #125 · timvideos/HDMI2USB · GitHub (at github.com) | 13:00 |
| *** tvCommitBot has joined #timvideos | 13:00 | |
| tvCommitBot | [HDMI2USB] mithro opened pull request #125: Fix forcing HDMI port 1 to 1024x768 mode. (master...720p-fix) http://git.io/vTpOc | 13:00 |
| *** tvCommitBot has left #timvideos | 13:00 | |
| tija | This can be merged of course. | 13:01 |
| mithro | wait for travis to confirm it builds :) | 13:01 |
| tija | so basically what that block of code does is set or unset hdmi_cmd and the does a uvc reset which is basically flushes the image pipeline. | 13:02 |
| mithro | tija: yeah | 13:03 |
| *** bjoern_ has quit IRC | 13:03 | |
| tija | I did exactly the same, detect a change in switch position, set/unset signal and then uvc reset but it didn't work. So something else is going on. Hence I asked you about DVI and HDMI | 13:03 |
| *** bjoern_ has joined #timvideos | 13:04 | |
| mithro | tija: did you test switching the mode works via USB in the first place? | 13:05 |
| tija | mithro: no :P | 13:05 |
| mithro | tija: assuming it works is possibly problematic :P | 13:06 |
| tija | mithro: That's why I want a re write. | 13:07 |
| mithro | tija: rewriting doesn't solve the problem - bugs always exist | 13:07 |
| mithro | tija: figuring out a better way to test might | 13:08 |
| tija | mithro: But the re written code will be highly commented so it will be more useful. | 13:08 |
| tija | mithro: But yeah re writing is not possible. | 13:09 |
| mithro | tija: you sure? It's not like we didn't want comments in the first place :) | 13:09 |
| tija | mithro: The biggest problem is that there isn't anyone with gud enuf knowledge of code base. Anyways, I was also fiddling with zybo. My poor linux skills turns out to be a road block. | 13:13 |
| tija | mithro: I was trying to see whether raw 720p images can be pushed via Ethernet atleast at 24 fps. | 13:14 |
| tija | But couldn't figure out Gstreamer :P | 13:15 |
| *** travis-ci has joined #timvideos | 13:24 | |
| travis-ci | [mithro/HDMI2USB/720p-fix#82] (ddcdac7): The build passed. (http://travis-ci.org/mithro/HDMI2USB/builds/63953298) | 13:24 |
| *** travis-ci has left #timvideos | 13:24 | |
| MaZderMind | mithro: well static… it changes the mix every 10 seconds and the sources stop and get restartet in a ~1h cycle (when the test-file ends) | 13:45 |
| mithro | MaZderMind: okay, that is a pretty good test - how are you running that? | 13:46 |
| *** Niharika has quit IRC | 13:47 | |
| mithro | MaZderMind: got some time to chat, or should I head home after pushing this change for tija? | 13:47 |
| mithro | tija: you should merge that other change | 13:48 |
| tija | mithro: which change? | 13:48 |
| *** tvCommitBot has joined #timvideos | 13:49 | |
| tvCommitBot | [HDMI2USB] mithro opened pull request #126: Adding better documentation to the EDID hack module. (master...edid-doc) http://git.io/vTpuC | 13:49 |
| *** tvCommitBot has left #timvideos | 13:49 | |
| mithro | tija -> https://github.com/timvideos/HDMI2USB/pull/125 | 13:49 |
| tpb | Title: Fix forcing HDMI port 1 to 1024x768 mode. by mithro · Pull Request #125 · timvideos/HDMI2USB · GitHub (at github.com) | 13:49 |
| mithro | tija: you should have a look at 126 too | 13:49 |
| MaZderMind | tija: 1920p@25fps raw I420 frames are ~650 MBit/s | 13:49 |
| MaZderMind | tija: I may help out with the linux side if desired | 13:50 |
| MaZderMind | mithro: whatever you want, we have a free day over here on the other side of the world and I'm just hanging around | 13:51 |
| MaZderMind | I'd have time to chat | 13:51 |
| mithro | MaZderMind: okay, let me grab a drink - I'll be back in 2 minutes | 13:51 |
| *** tvCommitBot has joined #timvideos | 13:52 | |
| tvCommitBot | [HDMI2USB] ajitmathew pushed 2 new commits to master: http://git.io/vTpgJ | 13:52 |
| tvCommitBot | HDMI2USB/master ddcdac7 Tim 'mithro' Ansell: Fix forcing HDMI port 1 to 1024x768 mode. | 13:52 |
| tvCommitBot | HDMI2USB/master 0422ee3 ajitmathew: Merge pull request #125 from mithro/720p-fix... | 13:52 |
| *** tvCommitBot has left #timvideos | 13:52 | |
| tija | sorry got some urgent work...brb in an hour | 13:55 |
| mithro | MaZderMind: okay, I'm back now | 13:57 |
| MaZderMind | btw. running for 40h now | 13:58 |
| MaZderMind | mithro: go ahead :) | 13:58 |
| mithro | MaZderMind: okay, so - firstly great work on the current stuff | 13:59 |
| MaZderMind | thank you! | 14:00 |
| mithro | MaZderMind: now you have a prototype working, you need to decide what the future entails for it | 14:00 |
| mithro | MaZderMind: a lot of my concerns are more about potential issues with things in the future | 14:01 |
| MaZderMind | well… there is just one feature missing and then it does everything the VOC needs | 14:01 |
| mithro | MaZderMind: so, the choice is - do you want to leave it at that? or do you want it to be extended / used by other people too? | 14:02 |
| MaZderMind | My choice would be to document the design desicions I made and why I made them and how the program could be extended -- and leave those extensions to the people that actually need them | 14:03 |
| MaZderMind | because If I now go on and implement features I don't need, I won't be a good maintainer on them | 14:03 |
| MaZderMind | I see code over configuration, why shouldn't there be a specialized mixer for the timvideos stuff that does exactly what you need and nothing else, based on the existing code | 14:04 |
| mithro | MaZderMind: the more code voctomix has, the harder things are keep stable (in any language - not just python) | 14:07 |
| mithro | More code == more bugs :) | 14:07 |
| MaZderMind | yes, exactly. that is why I have not implemented things like recording or streaming in the core, this is kept external for a reason | 14:09 |
| MaZderMind | but if you need it for your setup, why not add it and use the result? | 14:09 |
| mithro | MaZderMind: that is what I might do | 14:10 |
| MaZderMind | and we cann still work together, share code and bugfixes | 14:10 |
| mithro | MaZderMind: yes | 14:12 |
| mithro | MaZderMind: its definitely something I'm looking at | 14:13 |
| mithro | MaZderMind: so lets say we now have TimVideos stuff, DebConf stuff and CC VoC all contributing to your code base | 14:14 |
| *** travis-ci has joined #timvideos | 14:16 | |
| travis-ci | [mithro/HDMI2USB/edid-doc#83] (6bc80d6): The build passed. (http://travis-ci.org/mithro/HDMI2USB/builds/63959577) | 14:16 |
| *** travis-ci has left #timvideos | 14:16 | |
| mithro | MaZderMind: managing the complexity and making sure our features don't conflict can be hard | 14:17 |
| *** travis-ci has joined #timvideos | 14:17 | |
| travis-ci | [timvideos/HDMI2USB/master#38] (0422ee3): The build passed. (http://travis-ci.org/timvideos/HDMI2USB/builds/63960174) | 14:17 |
| *** travis-ci has left #timvideos | 14:17 | |
| mithro | So, the question is how to design a system which is extremely fault tolerant to failures in the code | 14:18 |
| MaZderMind | hm. I don't want to revolutionize the videomixer-world. I'm just solving a single problem | 14:19 |
| MaZderMind | It won't be as easy as lego to build your own mixer but there will be a base to start of | 14:20 |
| MaZderMind | I'm not saying that I won't take PRs with features, it's rather: solve one problem at a time | 14:21 |
| MaZderMind | and one usually is better at solving his own problems then those of others | 14:22 |
| mithro | MaZderMind: yes agreed | 14:24 |
| mithro | MaZderMind: I'm interested in enabling the type of features I've always wanted to support - like automatic speaker tracking | 14:27 |
| mithro | MaZderMind: so, how can we build something like that into / on top of voctomix without compromising the stability of your system | 14:29 |
| MaZderMind | mithro: the command-server can be used to dispatch commands between clients without interacting with the server | 14:30 |
| MaZderMind | this would be probably just a few lines of code that I'd be happy to add | 14:30 |
| MaZderMind | currently it already broadcasts successful function calls like "set-composition-mode" to connected clients | 14:30 |
| MaZderMind | I could see an visual-anylyisis-client taking commands from the gui and a video-stream from the mixer and posting commands to the mixers commandserver | 14:32 |
| MaZderMind | There might also be a camera-control-client that reads these commands and sends the video-stream to the server | 14:32 |
| MaZderMind | one might want to leave out the analysis-part and control the camera fro mthe gui directly | 14:33 |
| mithro | MaZderMind: yes, this sounds pretty reasonable | 14:33 |
| MaZderMind | or use a joystick to do that | 14:33 |
| mithro | MaZderMind: yeah | 14:33 |
| MaZderMind | the joystick-to-controlserver could be a simple python-script | 14:34 |
| mithro | MaZderMind: yeah | 14:34 |
| mithro | MaZderMind: what happens when my joystick-to-controlserver sends invalid commands to the server? | 14:35 |
| mithro | MaZderMind: Have you seen any bugs like this in Python yet? | 14:37 |
| mithro | https://www.irccloud.com/pastebin/WGagZ0KJ | 14:37 |
| tpb | Title: Pastebin | IRCCloud (at www.irccloud.com) | 14:37 |
| MaZderMind | mithro: https://github.com/voc/voctomix/commit/ad995edffb27d8cc0dd25c1a443cb38f1c678ec2 <- there you go | 14:37 |
| tpb | Title: Implement Messages as Client-to-Client Communication · voc/voctomix@ad995ed · GitHub (at github.com) | 14:37 |
| MaZderMind | mithro: well, if it sends unknown commands it get's an unknown-command error | 14:38 |
| MaZderMind | if a command raises an exception, you'll get that exception back and the call was not successful | 14:38 |
| MaZderMind | I have not fuzzed the control-server yet but I don't think I have to | 14:39 |
| MaZderMind | if your script kills your videomixer, well, you shot yourself in the foot, I guess | 14:39 |
| MaZderMind | what do you want to tell me with this paste? | 14:40 |
| mithro | MaZderMind: That is an example of a bug which can be very hard to catch and can exist even with 100% test coverage | 14:41 |
| mithro | (you need 100% branch coverage to find that bug) | 14:41 |
| MaZderMind | well, so be it. Are there bugs in DVSwitch? | 14:42 |
| mithro | MaZderMind: that exception bubbles up to the top level and now your mixer crashes | 14:42 |
| mithro | MaZderMind: I'm very good at shooting myself in the foot it seems :) | 14:42 |
| MaZderMind | yes of course there are bugs, yes! and they need to be found and fixed | 14:43 |
| mithro | MaZderMind: the reason I split the GUI and server into two separate processes is to deal with issues like this | 14:43 |
| MaZderMind | but no one will find them without using the project and no one will use the project if it is not in a usable staze | 14:43 |
| mithro | MaZderMind: it means that when the GUI crashes, the server continues to record and you can just reconnect the GUI | 14:44 |
| MaZderMind | yes, I'm all for separating things | 14:44 |
| mithro | MaZderMind: which you seem to adopted too - which is great :) | 14:44 |
| MaZderMind | voctomix currently has 912 lines of python | 14:45 |
| MaZderMind | it will be, say, 100 more when I implemented the stream-blanking-code | 14:45 |
| MaZderMind | this is a codebase that is easy enough to read and to find bugs in and I'll be sure we will find plenty of bugs as soon as we start using it in production | 14:46 |
| MaZderMind | this is excluding the gui | 14:47 |
| mithro | MaZderMind: yeah - this is a good | 14:48 |
| mithro | MaZderMind: I was trying to figure out a solution of how to reduce the "core must run" code even smaller | 14:50 |
| mithro | MaZderMind: I was thinking of the system as kind of like this; | 14:51 |
| mithro | gstreamer-pipelines > "pipeline configuration" > "business logic / GUI / tcp stuff" | 14:53 |
| mithro | Really, once the gstreamer pipelines are running, they should stay running until we need a "config change" (say the mixer) | 14:55 |
| mithro | s/say the mixer/say changing the inputs selected on the mixer/ | 14:55 |
| mithro | Then a config change is really just updating the running gstreamer pipelines in some way (starting / stopping / updating properties) | 14:56 |
| MaZderMind | there are some pipelines that need to be run when a source connects | 14:57 |
| MaZderMind | and designimg these pipelines is one of the main parts of building the mixer | 14:57 |
| mithro | MaZderMind: yes - I'm including that in the "config change" part too | 14:58 |
| MaZderMind | so you basicly talking about a confured-pipeline-runner | 14:58 |
| mithro | MaZderMind: confured? | 14:58 |
| MaZderMind | sorry, touchscreen | 14:59 |
| MaZderMind | configured | 14:59 |
| mithro | MaZderMind: this however doesn't protect gstreamer pipelines crashing either | 14:59 |
| MaZderMind | designing the pipelines correctly is an art in itsself | 14:59 |
| mithro | MaZderMind: if we stick to good modules, the chance of the pipelines being crashing is low | 15:00 |
| mithro | MaZderMind: but if we start using more exhotic plugins, things get more dicy | 15:00 |
| mithro | MaZderMind: so then you start wondering if you could separate different pipelines into different processes | 15:01 |
| mithro | MaZderMind: and you end up with a design similar to how flumotion works | 15:01 |
| MaZderMind | hm and there we come back to the beginning of this discussion: i want to solve a single problem | 15:02 |
| MaZderMind | not all problems of the world | 15:03 |
| MaZderMind | (video-)world | 15:03 |
| mithro | MaZderMind: yes | 15:03 |
| mithro | MaZderMind: which is why I mentioned the "ecide what the future entails for it" part | 15:03 |
| MaZderMind | if someone takes pieces of voctomix and sticks together a new mixer solution, that's perfectly valid | 15:03 |
| MaZderMind | and I'll happily help them :) | 15:04 |
| mithro | MaZderMind: I started trying to see if I could take voctomix and rebase it onto a "gstreamer pipeline manager" type interface | 15:05 |
| mithro | MaZderMind: but I got distracted with doing HDMI2USB stuff for the prod board | 15:09 |
| mithro | MaZderMind: It also adds some complexity to voctomix and I was wondering if it was worth it to you guys | 15:10 |
| mithro | MaZderMind: so, wanted to discuss why I think it would be useful / important and if it made sense | 15:12 |
| MaZderMind | I see | 15:12 |
| mithro | MaZderMind: on a related note | 15:13 |
| mithro | MaZderMind: I see that voctomix has a static source configuration? | 15:13 |
| MaZderMind | I for my part want to a) solve the problem for the VOC to produce HD Video everywhere. b) document our code and our design to c) help people use and modify our software | 15:13 |
| MaZderMind | yes, that's on purpose. It allows to show the sources with titles and in the correct order in the GUI and makes the pipelines a lot easier | 15:14 |
| mithro | MaZderMind: yeah - it does simplify a lot of things | 15:15 |
| MaZderMind | And in our setup we usually know ahead how nay inputs we will have. Ynd you still can restart the core in a break to fit another source | 15:15 |
| mithro | MaZderMind: it has *loads* of advantages are you point out | 15:16 |
| mithro | MaZderMind: it definitely seems like the right solution right now for (a) | 15:17 |
| mithro | MaZderMind: you guys seem *super* organised, so I doubt it has many down sides for you either | 15:18 |
| mithro | MaZderMind: less magic == good for stability | 15:18 |
| MaZderMind | and you could always add some 'for special use' sources ^^ | 15:19 |
| mithro | MaZderMind: yeah | 15:19 |
| mithro | MaZderMind: I was wondering, what happens at the moment when multiple gst commands connect to the same port? | 15:19 |
| MaZderMind | that's not possible | 15:19 |
| MaZderMind | the 2nd connection is closed | 15:20 |
| MaZderMind | https://github.com/voc/voctomix/blob/master/voctocore/lib/tcpsingleconnection.py#L32 | 15:20 |
| tpb | Title: voctomix/tcpsingleconnection.py at master · voc/voctomix · GitHub (at github.com) | 15:20 |
| mithro | MaZderMind: okay, "the second connection fails" | 15:20 |
| mithro | MaZderMind: yeah - that is what I thought would happen | 15:20 |
| MaZderMind | one small issue is when a source with the wrong video caps connects :> | 15:21 |
| MaZderMind | the pipeline just doesn't preroll and does not throw an error | 15:21 |
| MaZderMind | but this is a small issue in production, where the sources are usually tested well | 15:22 |
| mithro | MaZderMind: so, what happens when a source gets accidently power cycled by a conference attendee who wants to power their laptop? | 15:22 |
| MaZderMind | well the image turns black (intervideosrc sources black frames) until the source reconnects | 15:22 |
| mithro | MaZderMind: The old TCP connection will be still open as the client didn't go away cleanly, the new one is now rejected? | 15:22 |
| MaZderMind | the test-videos are currently sources by `while true; do ffmpeg -i … tcp://localhost:10000; done` | 15:23 |
| mithro | MaZderMind: yeah - when the ffmpeg command exits on a machine the tcp socket will be closed cleanly | 15:23 |
| CarlFK | hi folks | 15:24 |
| mithro | MaZderMind: so the server will call the "close_connection" function on line 39 | 15:24 |
| MaZderMind | CarlFK: hi | 15:24 |
| mithro | CarlFK: you should give voctomix a whirl and see if you can get it going | 15:24 |
| CarlFK | https://github.com/voc/voctomix right? | 15:25 |
| tpb | Title: voc/voctomix · GitHub (at github.com) | 15:25 |
| MaZderMind | when the tcp source goes down from the view of the kernel, the kernel coses the file descriptor. this makes the fdsrc element throw an error on the next read which in turn calls on_error in AVSource which will thenn call close_connection | 15:25 |
| MaZderMind | CarlFK: yes | 15:25 |
| mithro | MaZderMind: Yes | 15:25 |
| mithro | MaZderMind: however, the kernel doesn't view a connection as closed until it gets the fin packet or the tcp socket timeouts waiting on an ack | 15:25 |
| MaZderMind | mithro: I must admit I have seen that not working when the source sended wrong data | 15:26 |
| mithro | MaZderMind: so if you kill the machine by pulling the power, the fin packet will never arrive, so the tcp socket has to timeout | 15:26 |
| mithro | tcp socket timeouts are often on the order of minutes (or sometimes hours) | 15:26 |
| CarlFK | MaZderMind: have you ever run https://github.com/CarlFK/dvsmon ? | 15:27 |
| tpb | Title: CarlFK/dvsmon · GitHub (at github.com) | 15:27 |
| MaZderMind | CarlFK: yes, i used that for some things | 15:27 |
| mithro | MaZderMind: hence it could be hours before the source is allowed to connect again | 15:28 |
| MaZderMind | mithro: yep. That is a problem you will have with any tcp connection based system | 15:28 |
| mithro | MaZderMind: you can of course fix this by tweaking kernel settings and stuff | 15:28 |
| MaZderMind | and for a production system you will have to do this | 15:28 |
| mithro | MaZderMind: the alternative solution is to have "the latest always wins" solution | 15:28 |
| mithro | MaZderMind: when a new connection comes in, close the old connection and accept the new one | 15:29 |
| MaZderMind | as well as configure swappiness, ipv6 support, irqbalance, filesystems, raid and a shitload of other stuff" | 15:29 |
| MaZderMind | mithro: I will try to implement that | 15:29 |
| mithro | MaZderMind: this solves the above problem pretty neatly | 15:29 |
| MaZderMind | yes, that's true | 15:29 |
| mithro | MaZderMind: but you then run into the next problem | 15:29 |
| mithro | MaZderMind: two fighting sources | 15:29 |
| mithro | MaZderMind: where you have accidently configured two sources to connect to one port | 15:30 |
| CarlFK | MaZderMind: can you write me a dvsmon voctomix.sh/py to run what is needed, like https://github.com/CarlFK/dvsmon/blob/master/mixy.py | 15:30 |
| tpb | Title: dvsmon/mixy.py at master · CarlFK/dvsmon · GitHub (at github.com) | 15:30 |
| MaZderMind | If you don't have your enviroment in control, you're screwed anyway | 15:30 |
| mithro | MaZderMind: the first connects, the second then connects causing the first one to reconnect, which then causes the second one to reconnect, repeat..... | 15:30 |
| MaZderMind | CarlFK: no, i can't, but you can take a look at https://github.com/voc/voctomix/blob/master/voctocore/scripts/demo-local.sh | 15:31 |
| tpb | Title: voctomix/demo-local.sh at master · voc/voctomix · GitHub (at github.com) | 15:31 |
| MaZderMind | mithro: I repeat it: If you don't have your enviroment in control, you're screwed anyway :) | 15:31 |
| MaZderMind | you shouldn't have two sources confured that way :Y | 15:31 |
| MaZderMind | :> | 15:31 |
| mithro | MaZderMind: I've seen this happen in many different ways, IE when someone accidently connects a test system to the production network without knowing | 15:32 |
| MaZderMind | yes, but fixing this is out of scope of a video mixer | 15:32 |
| mithro | MaZderMind: that might be accidently done by the networking guys accidently bridging your av-test and av-prod vlans :( | 15:32 |
| CarlFK | MaZderMind: Exception: ('GStreamer version', (1, 4, 5, 0), 'is too old, at least', (1, 5), 'is required') | 15:32 |
| mithro | MaZderMind: that is a pretty obvious error | 15:33 |
| CarlFK | where are you getting gs from? | 15:33 |
| mithro | s/MaZderMind/CarlFK/ | 15:33 |
| MaZderMind | or you may have two devices with the same ip in the net. should the mixer deal with this, too? | 15:33 |
| MaZderMind | it can't. It needs a good environment to run in and multiple sources are an equally bad problem | 15:33 |
| CarlFK | readme says "Testet on Ubuntu 14.10 with the bundled gstreamer 1.4.3" | 15:34 |
| MaZderMind | mithro: but: the sources currently can only deliver raw frames / raw audio in mkv, so they will usually run on localhost anyway | 15:34 |
| MaZderMind | CarlFK: there are bugfixes in gst-master's inter | 15:34 |
| MaZderMind | CarlFK: there are bugfixes in gst-master's inter*-elements that are needed to keep a/v-sync | 15:35 |
| MaZderMind | CarlFK: so currently I build my gstreamer from git master | 15:35 |
| CarlFK | oh swell. | 15:35 |
| MaZderMind | we will later package this into debs but for development… | 15:35 |
| MaZderMind | I don't see a point in working around bugs that are fixed upstream | 15:35 |
| mithro | MaZderMind: The dynamic configuration of gst-switch does solve this (specific) problem but as you pointed out adds a bunch more complexity | 15:36 |
| CarlFK | mithro: you should give voctomix a whirl and see if you can get it going :p | 15:36 |
| mithro | MaZderMind: IE the two sources just appears in gst-switch | 15:37 |
| CarlFK | MaZderMind: does it have a cut button like in DVswitch? | 15:37 |
| mithro | CarlFK: I don't think it does recording yet? | 15:37 |
| MaZderMind | CarlFK: recording would be part of an external script | 15:38 |
| MaZderMind | the GUI could communicate a 'cut'-event to the recording client which could rotate output files | 15:38 |
| CarlFK | let me know when someone does that part. | 15:38 |
| MaZderMind | CarlFK: we do our recordign like this: https://github.com/voc/voctomix/blob/master/voctocore/scripts/av-record-output-ffmpeg-timestamps.sh | 15:38 |
| tpb | Title: voctomix/av-record-output-ffmpeg-timestamps.sh at master · voc/voctomix · GitHub (at github.com) | 15:38 |
| MaZderMind | a segment every 3 minutes | 15:38 |
| CarlFK | not my problem :p | 15:39 |
| MaZderMind | :) | 15:39 |
| mithro | CarlFK: it is if you want to use a HD pipeline | 15:39 |
| mithro | MaZderMind: I think the choice of dynamic verses static is the biggest reason I'm not just doing voctomix stuff right now | 15:40 |
| MaZderMind | mithro: sleep about it and think if you *really* want a videomixer that dynamicly reconfigures itsself | 15:40 |
| mithro | MaZderMind: my dream is the eventual zero-configuration, auto-deploy, no touching solution | 15:40 |
| mithro | MaZderMind: I have been thinking about it for a while | 15:41 |
| MaZderMind | I'll try to implement that reconnect-logic, maybe with a timeout-interval, it sounds pretty good | 15:41 |
| MaZderMind | but having a known configuration is actually something I really like | 15:41 |
| mithro | MaZderMind: I think in your known configuration model - the "last connection wins" is probably the right approach | 15:42 |
| MaZderMind | it makes things predictable | 15:42 |
| MaZderMind | yes | 15:42 |
| CarlFK | MaZderMind: when a talk scheduled to start at 10:00 starts at 10:01, (how) do you trim the 1 min of cruft? | 15:42 |
| MaZderMind | I'm heading over to dinner soon | 15:42 |
| mithro | MaZderMind: I should head to bed soon myself | 15:43 |
| MaZderMind | CarlFK: that's a looong story | 15:44 |
| mithro | MaZderMind: at the moment, the only part which really *needs* the configuration is your videomix and avsource elements | 15:44 |
| MaZderMind | CarlFK: I think it would be better explained via phone/mumble/hangout | 15:44 |
| MaZderMind | mithro: yes, but the GUI will need that, too | 15:44 |
| CarlFK | MaZderMind: na, pretty sure the end will be: | 15:44 |
| CarlFK | let me know when someone does that part. | 15:44 |
| MaZderMind | :) | 15:45 |
| CarlFK | (a cut button) | 15:45 |
| MaZderMind | I could imagine mithro will do that | 15:45 |
| CarlFK | "press cut, write down the time displayed on the screen, enter time into django form, hit save" | 15:45 |
| CarlFK | that's about what I want to see. | 15:45 |
| MaZderMind | the thing is not the cut button but a recording-script which rotates the output-file. this script will run outside of voctomix then and just communicate with the video-socket and the control-server | 15:46 |
| mithro | CarlFK: actually the two bits could actually be trivially automated | 15:46 |
| CarlFK | mithro: what two? | 15:46 |
| MaZderMind | I'mm afk, cya | 15:46 |
| mithro | MaZderMind: but once I replace avsource.py and videomix.py - is there much left of voctomix? | 15:47 |
| mithro | MaZderMind: at some point we should also discuss why using mkv is a terrible idea for your avsource format :) | 15:47 |
| mithro | MaZderMind: I'm going to head home now | 15:47 |
| mithro | MaZderMind: I assume you'll read the scrollback | 15:49 |
| mithro | MaZderMind: in summary, I'll need to give up the idea of dynamic sources to use voctomix and I'm still trying to figure out if I should do that | 15:50 |
| mithro | MaZderMind: anyway, we should chat more another time | 15:52 |
| mithro | MaZderMind: you have the advantage that you have developer time (your own) to get things working :) | 15:52 |
| mithro | Anyway, really leaving now | 15:52 |
| CarlFK | mithro: ping me when you get home. I am curious of your view of vocto's static config. | 15:59 |
| MaZderMind | mithro: yes, sure, it's a videomixer :) a/v in, mix, a/v out | 16:10 |
| mithro | CarlFK: its 2am here | 16:11 |
| MaZderMind | re mkv: I had a discussion with heftig on #gstreamer why mkv is better then gstdata - and also the fact that ffmpeg can read raw-frames in mkv via tcp is a nice addition | 16:12 |
| MaZderMind | mithro: let's discuss that another time | 16:13 |
| mithro | My issues on come up when transmitting over the network rather then locally | 16:14 |
| mithro | S/on/only/ | 16:14 |
| mithro | And probably only when things aren't going well too | 16:14 |
| *** Niharika has joined #timvideos | 17:17 | |
| *** Niharika has quit IRC | 17:21 | |
| *** Niharika has joined #timvideos | 17:28 | |
| *** Niharika has quit IRC | 18:09 | |
| *** tija has quit IRC | 18:23 | |
| *** thaytan has quit IRC | 18:38 | |
| *** thaytan has joined #timvideos | 18:54 | |
| *** ChanServ sets mode: +v thaytan | 18:54 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!