Friday, 2016-12-30

*** tpb has joined #timvideos00:00
*** hyadez has quit IRC01:01
*** aps has quit IRC01:03
tumbleweedxfxf: IIRC it is, but it's rather c3 specific01:21
tumbleweedalso, the pre-review publishing is different to the post-review publishing01:23
tumbleweedhttps://github.com/voc/voctoweb01:24
tpbTitle: GitHub - voc/voctoweb: voctoweb – the frontend and backend software behind media.ccc.de (at github.com)01:24
xfxfah, rails01:28
xfxfthis looks like the app that serves already edited files, not the veyepar-like workflow tool, or am i mis-grokking it?01:30
tumbleweedthat is correct01:30
xfxfi want to see the bits of their code that handle the almost immediate editing/uploading of video.  i'm assuming it's some tool that slurps down the live stream and chops/re-encapsulates/uploads01:30
tumbleweedthey don't have a veyepar01:30
xfxfokay, so how do they do that side of things?01:30
tumbleweedthe editing is done with a gui, using a fuse filesystem that mounts the recorded talks01:31
xfxfoh, wow, so they do that manually?01:31
xfxfand i've seen the fuse filesystem stuff01:31
xfxfi didn't think CCC actually did that at scale though01:31
xfxfthat's kinda nuts if they're turning around stuff within hours01:31
tumbleweedI haven't seen the process, that's just what I remember being told01:31
xfxfah, right01:31
xfxfi'm super keen to do the almost immediate publishing stuff01:32
tumbleweedI think it's quite reasonable to imagine that process to be quicker than veyepar01:32
tumbleweedthe almost immediate publishing is just stream dumping01:32
xfxfin theory it wouldn't be that hard01:32
xfxfbut everything seems 'not hard' until one attempts it01:32
tumbleweedyep01:32
tumbleweedit's about the corner cases, and making it all reliable01:33
xfxflike, 'in theory' we could run a second set of 'disk save' gstreamer pipelines on a remote server with sufficient network connectivity01:34
xfxfand enhance the way we're indicating/saving cuts a little so volunteers can actually live mark which ones denote a recording during the event01:35
tumbleweedso, they do MPEG HLS streams01:35
xfxfprobably not hard to write a little script that feeds the right data into veyepar and kicks off an encode01:35
tumbleweedwhich are essentially a stream dump to files01:35
tumbleweedthat the client treats as being a stream01:35
tumbleweederr sorry, probably DASH not HLS01:36
xfxfyeah, i think i saw that when poking around01:36
xfxfgstreamer behind the scenes for that?01:36
tumbleweednot sure what fits in where01:37
tumbleweedbut I seem to recall that most of the streaming infrastructure is nginx01:37
xfxfah, yes, they told me that the other day01:37
xfxffor LCA we'll stick with iterating on our current technologies but definitely going to play with all of this after01:38
xfxfhad hoped to attend CCC this year but couldn't make it - maybe next01:38
tumbleweedyeah, I think we're mostly sticking with icecast right now, too. webm in icecast has the advantage of being simple01:39
CarlFKthe blocker I run into is moving the data from the room to somewhere else - 1/2 the time I have no real network01:58
CarlFKI have people excited to give me the wifi password01:59
*** tpb has joined #timvideos03:22
*** hyadez has joined #timvideos05:34
*** CarlFK has quit IRC06:22
*** SamSagaZ has quit IRC07:51
markvandenborrexfxf: you may want to have a look at nginx rtmp pseudocutting08:09
markvandenborresorry, nginx http mp4 pseudocutting08:23
xfxfack, I assume it lets me reencapsulate streams into files or similar?08:24
*** sb0 has joined #timvideos09:35
markvandenborrexfxf: we throw an rtmp stream at nginx09:44
markvandenborrenginx dumps the stream into a (non-seekable) flv; when the stream to nginx stops, it calls ffmpeg to auto convert it into an indexed, seekable mp4 file09:46
xfxfneat09:51
markvandenborreit's really great to be able to do http://foo/bar.mp4?start=20&end=45010:21
*** SamSagaZ has joined #timvideos13:57
*** SamSagaZ has quit IRC14:24
*** sb0 has quit IRC15:01
markvandenborrexfxf: or even http://foo/bar.mp4?start=20&end=450#t=30,5016:11
cr1901_modern_florent_: If the peripheral clock in HDMI2USB is asynchronous to the system clock, does the wishbone interface provide the clock-domain crossing?19:15
cr1901_modernwishbone shared bus*19:15
cr1901_modernmithro: So... the firmware in fact does NOT work when booting from internal ROM20:23
cr1901_modernOnce it reaches a loop, it decides to spit garbage to the console. Mainly repeating the letter "L" many times20:24
_florent_cr1901_modern: no you have to do that manually (on the CSRs) or with something like this: https://github.com/enjoy-digital/opsis-soc/blob/master/gateware/encoder/core.py#L28720:24
tpbTitle: opsis-soc/core.py at master · enjoy-digital/opsis-soc · GitHub (at github.com)20:25
cr1901_modernIn a sense, this is "good news", b/c I can safely remove the SPIflash as a source of problems for now20:25
cr1901_modern_florent_: Okay thanks for the heads up on that20:25
cr1901_modern_florent_: Something bothers me about the wb_async_reg impl... I remember reading that if you're trying to synchronize a multi-bit signal, it is not sufficient to just include two flip-flops in series between src and dest domain20:29
cr1901_modernBut this seems to be exactly what wb_async_reg.v does20:29
cr1901_modernWell, I guess it's fine, taking a closer look, since the buses will be held constant while the synchronization takes place and thus will "eventually" settle on the correct value20:35
*** sb0 has joined #timvideos23:11

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!