Tuesday, 2016-01-12

*** tpb has joined #timvideos00:00
CarlFKthaytan: you are our local gst ninja right?00:17
thaytanCarlFK, for now!00:21
CarlFKthaytan: I am using this in place of vocto:00:22
thaytanalthough ystreet00 is technically closer to mithro :)00:22
CarlFKgst-launch-1.0 tcpserversrc port=10000 ! decodebin ! fpsdisplaysink00:22
CarlFKthis client https://github.com/xfxf/video-scripts/blob/master/carl/hu-alsa.sh00:22
tpbTitle: video-scripts/hu-alsa.sh at master · xfxf/video-scripts · GitHub (at github.com)00:22
thaytanneeds a queue, but OK00:22
CarlFKI bet that's it ;)00:23
thaytanafter tcpserversrc00:23
CarlFKcuz if that fixes is.. that's all that matters and we may have the last blocker00:23
CarlFKfine :p00:24
thaytanis the playback stuttery?00:24
CarlFKlet me put that in for good measure00:24
CarlFKplayback is fine for 5 min00:24
CarlFKthen over 30 seconds degrades to about 1fps00:24
thaytanah, that may be more of a clock drift issue00:25
CarlFKthat's my guess00:25
thaytanthe server is sending slightly slower than the client wants to receive00:25
CarlFKoh.. I was thinking v4l and alsa00:26
thaytanso after a while to client gets more than 1 frame out of sync and starts dropping things because they're arriving late00:26
CarlFKboth are on the same machine.. so...00:26
thaytanthere's 3 clocks there: v4l and alsa on the sender which will choose ALSA and sync delivery to that00:26
thaytanand on the receiver there's whichever clock it's choosing - probably the system clock00:26
thaytanso one pipeline is tracking time against the audio clock, and the receiver is tracking against the system clock00:27
thaytandepends how quickly they diverge by 1/fps00:27
CarlFKhow can I force the client to use the system clock ?00:28
CarlFKwhere client is the ting reading from v4l/alsa00:28
CarlFKseems you were calling that the server ?00:28
thaytanthere are a few solutions: 1 package things in RTP packets and use an RTP jitterbuffer 2 set sync=false on the fpsdisplaysink to not sync to a clock and just display as things arrive or 3) set provide-clock=false on the sender alsasrc and check both pieplines now choose GstSystemClock in the output they print00:29
CarlFK1 and 2 are out because I don't want (can't) change the server (voctomix)00:30
CarlFKso lets try 300:30
*** sb0 has joined #timvideos00:31
CarlFKserver side New clock: GstSystemClock00:31
CarlFKclient side got burried in debug=300:32
CarlFKclient side New clock: GstSystemClock00:32
CarlFKok, I am excited.  and now need to run for a moment.  bb in 10 where I expect to see no more problems and will go out and celebrate00:34
CarlFKthaytan: I think you nailed it.01:27
CarlFKtest server went 10 min without issue, so I put this into are full stack and ... 1 hour later, no probem01:28
CarlFKxfxf: ^^^01:28
xfxfrad. for me this sometimes took multiple hours01:46
xfxfalso ensure the saved files keep av sync01:46
CarlFK(06:22:21 PM) thaytan: so after a while to client gets more than 1 frame out of sync and starts dropping things because they're arriving late01:49
CarlFKthink about that...01:49
*** sb0 has quit IRC01:50
CarlFKI think that means if a remote box clock drifts but 1/30 seconds, it happens01:51
CarlFKlittle fuzzy on why we still get 1 frame and not 0 frames01:52
thaytanCarlFK, if frames are arriving late, GStreamer will still display 1 frame per second as emergency frames02:04
CarlFKthaytan: bingo.02:05
CarlFKI was hoping it was that simple02:05
CarlFKthaytan: all of my testing has been on the same box.  production will have a 1 local source and one on the other end of a cat5 run to a laptop02:06
CarlFKthat will be v4l and testaudiosrc02:06
thaytanCarlFK, back to different clocks02:07
CarlFKso it will use the laptop os clock02:07
thaytanbut with ntpd they hopefully stay synched well enough02:07
thaytanotherwise you need to learn about using RTP or GStreamer network clocks to sync things02:07
CarlFKoh, we have the laptops.  so testing now should be valid when we go live02:09
CarlFKthe remote source will be the presenters laptop feed, so we will survive with the 1fps emergency frame02:10
thaytanCarlFK, that's only for display, btw - it only applies to sinks with sync=true02:12
thaytanall the frames will still be received and muxed according to the timestamps in the matroska feed02:12
CarlFKthaytan: oh...02:13
CarlFKer oh02:13
thaytanif audio is captured somewhere else, and timestamps don't match then that'll lead to unsynched audio and video in the recording02:13
thaytanso still need to be careful02:13
thaytanyou may not notice a few hundreds of milliseconds drift on the presenter slides feed02:13
thaytanbut you will in their audio and presenter mouth video02:14
CarlFKaudio and camera are on  the box running the mixer02:14
thaytanflumotion avoids that by distributing a GStreamer network clock to all the capture machines so they're sharing and timestamping with a common clock02:14
mithro_florent_: That stuff in the HV30 issue is the "optimal" solution for the HV30 capture02:24
mithro_florent_: First, is to just capture the interlaced HDMI signal02:25
*** rohitksingh has joined #timvideos02:29
xfxfthaytan: in that case is this something voctomiz should be implementing?02:39
xfxfbecause remote feeds are fed in with a gst-launch pipeline feeding to tcp02:40
xfxfsorry for terseness, phone02:40
thaytanxfxf, yes, they need *something* to cope with long-term drift02:50
xfxfMaZderMind: see above? comments?02:51
CarlFKthaytan: what happens if ntpd adjusts the os clock while all this is happening?02:55
thaytanCarlFK, the clock GStreamer uses (CLOCK_MONOTONIC) will change frequency based on ntp adjustments02:57
thaytanntp is supposed to do gradual adjustments02:57
thaytanso you see some non-linearity in the clock02:57
thaytanbut it never 'jumps'02:57
thaytanand because it's the monotonic system clock, it especially never adjusts backwards02:58
CarlFKtrying to follow is making my head hurt ;)  so let me go high level...02:59
CarlFKgiven the way we are going to set things up, I get the feeling we are OK for lca - vidoes will be fine.  do you have enough info to agree ?03:00
mithrowe had this discussion at the hackfest last year03:56
mithroremeber the whiteboard diagrams?03:56
CarlFKmithro: I do.  stop trying to make my head hurt again :p04:02
CarlFKmithro: I mostly understand the problem, mostly understand the GStreamer network clock solution, but I do not really have comfortable level of understanding of what happens when ntp nudges the clock04:05
CarlFKand today I don't really want to know04:06
CarlFKI am now pondering how to run these things in production04:08
mithroCarlFK: with very expensive people04:09
CarlFKum.. what?04:09
*** rohitksingh has quit IRC05:16
mithroCarlFK: oh - in TV stations there is a piece of coax which runs around the building and provides the "sync clock" that everything locks too07:30
xfxffyi, i intend on hacking on voctomix and becoming less terrible at gstreamer post-lca.  i have some plans for my spare hdmi2usb boards which requires some automation which doesn't currently exist07:55
xfxfi'm just trying to stay as much in 'non technical project manager' territory for LCA07:56
xfxfalready started poking at voctomix code a few nights ago, but then stopped, not a good use of time right now07:56
xfxfCarlFK: did you submit your scripts now that work?  i want to re-rest on the slow i5 laptop i was having my original issues with...07:57
xfxfmithro: i just got shipment notification from numato - not arriving until week after next now07:57
xfxfer, sorry, next week rather, not this week07:57
*** se6astian|away is now known as se6astian08:00
mithroCan you send me shipping info?08:00
mithroxfxf: they are looking into what is up08:22
MaZderMindCarlFK: you *can* change the server by sending mie a ticket or a PR ;)09:43
MaZderMindthat thing with the 1 frame per second as emergency frames was new to mee, too09:46
MaZderMindIt would be trivial to add a NetworkClockProvider to voctocore09:47
MaZderMindbut I don't think it would be usable on a gst-lounch command-line09:47
MaZderMindone would need a simple c- or py-program around it09:48
MaZderMindup until now we had all sources running on the same host and using the same system clock, so this was not an issue. i'll add that soon: https://github.com/voc/voctomix/issues/4609:52
tpbTitle: Provide GstNetworkTime + Example Source · Issue #46 · voc/voctomix · GitHub (at github.com)09:52
xfxfMaZderMind: yay, thanks :)10:14
MaZderMindxfxf: those bugfixes ^ are just another prove why I want your scripts in the example-scripts directory10:20
MaZderMindand they are a prove that setting up a complete mixing solution will always need adaption to the actual conditions10:21
xfxfyeah, nod. agreed with example scripts, let us make them work first :)10:44
xfxfand i'm assuming for the thing above we'll have to have a python script using the gst bindings versus a gst-launch line10:44
xfxfbut from what i've seen you can practically shove a gst-launch like pipeline into it anyway with a little bit of boilerplate?10:44
xfxfblah, i just remembered i've done this before, but a long long time ago10:46
MaZderMindxfxf: I'll try to get an example up in the next days10:55
xfxfneat, ta10:55
mithroxfxf: so - that webcam...11:10
xfxfoh, right11:13
tpbTitle: video-scripts/webcam-mjpeg-v4l.sh at master · xfxf/video-scripts · GitHub (at github.com)11:13
xfxfthat was my attempt11:13
xfxfit did not work11:13
*** sb0 has joined #timvideos11:18
mithroI have so many domain names I have a spreadsheet to track them all..11:33
xfxfha, i used to do that11:33
xfxfi let many lapse a bunch of years back11:33
xfxfso many one page websites for lols11:33
xfxfor PTR records for stupid subdomains to use on IRC11:34
xfxfmithro: i believe you were going to help me with the script above? :)11:49
xfxfwebcam ready to go, keen to test vocto with 2x inputs, 1x via network11:49
mithroxfxf: so that looks like it should work11:53
mithroxfxf: what happens?11:53
*** Bertl_zZ is now known as Bertl11:54
xfxfoh, it does, it just errors on the alsa stuff for some reason11:56
xfxfchanging alsa to audiotestsrc makes it work11:56
xfxfhmm, for a hdmi2usb with no audio input, what audio source should i be muxing in (given voctomix requires audio+video)?11:56
xfxfaudiotestsrc isn't silent11:56
mithroaudiotestsrc volume=0 ?11:58
thaytanaudiotestsrc wave=silence12:00
xfxfright, it has parameters, but i mean as a higher level question, is audiotestsrc what i should be using to provide dummy input in a production scenario?12:01
xfxfi'm gathering yes12:01
thaytanif you need dummy input, it's the easiest choice12:03
xfxfcool, ta12:12
MaZderMindxfxf: splitting video- and audio-sources is a thing i was thinking about quite a lot, but it makes working with the bmd-capture cards somewhat harder, because then you'll read audio and video from the same device but need two muxers (rather: encapsulators) and two tcpsinks12:24
MaZderMindadding silence to the videosources that don't provide audio seemed simpler so me back then12:25
xfxfi'm fine with this for now13:09
xfxfokay, now testing with 2x 720p30 inputs (directly connected webcam w/ dummy audio, network connected hdmi2usb w/ alsa mux) using PiP13:09
xfxfwill let it capture overnight13:09
xfxfMaZderMind: amusingly i have a bmd capture card in one of the machines i'm capturing from too, but not using it13:14
*** travis-ci has joined #timvideos13:16
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#64] (7ad8505): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101829241)13:16
*** travis-ci has left #timvideos13:16
*** travis-ci has joined #timvideos13:16
travis-ci[timvideos/HDMI2USB-misoc-firmware/minispartan6+#312] (faa70f2): The build passed. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/101819503)13:16
*** travis-ci has left #timvideos13:16
*** travis-ci has joined #timvideos13:17
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#65] (aa72ada): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101829985)13:17
*** travis-ci has left #timvideos13:17
*** travis-ci has joined #timvideos13:19
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#67] (3454184): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101830940)13:19
*** travis-ci has left #timvideos13:19
*** travis-ci has joined #timvideos13:34
travis-ci[mithro/HDMI2USB-misoc-firmware/master#63] (0419564): The build passed. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101829045)13:34
*** travis-ci has left #timvideos13:34
mithroWell, I got a bunch of small things done today13:37
*** travis-ci has joined #timvideos13:38
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#74] (186c3ae): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101835454)13:38
*** travis-ci has left #timvideos13:38
xfxfmithro: what firmware should i be testing, btw - i'm just doing my tests on whatever was on the main branch a few days ago.  or are all of your changes more in line with getting things ready for the prod boards?13:39
*** travis-ci has joined #timvideos13:40
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#71] (b853f37): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101833020)13:40
*** travis-ci has left #timvideos13:40
mithroxfxf: last code change on main was on Dec 3, 201513:41
mithroxfxf: all the changes for the Opsis board have been in a separate branch13:41
mithroxfxf: the fx2 firmware rewrite has also been in a separate branch13:41
xfxfah, right, all good then13:46
*** travis-ci has joined #timvideos13:48
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#69] (6ca3cfd): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101831389)13:48
*** travis-ci has left #timvideos13:48
*** travis-ci has joined #timvideos14:08
travis-ci[timvideos/HDMI2USB-misoc-firmware/master#321] (606f11c): The build passed. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/101834136)14:08
*** travis-ci has left #timvideos14:08
*** travis-ci has joined #timvideos14:10
travis-ci[mithro/HDMI2USB-misoc-firmware/readme-update#72] (1f9da79): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101834449)14:10
*** travis-ci has left #timvideos14:10
*** travis-ci has joined #timvideos14:35
travis-ci[timvideos/HDMI2USB-misoc-firmware/master#323] (994e8a7): The build passed. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/101835724)14:35
*** travis-ci has left #timvideos14:35
CarlFKxfxf: thoughts on production - screenrc file with while loops?  that's what ccc did, but I don't really like it... but but it is done and tested.15:20
*** travis-ci has joined #timvideos15:40
travis-ci[mithro/HDMI2USB-misoc-firmware/master#75] (7f77c71): The build has errored. (https://travis-ci.org/mithro/HDMI2USB-misoc-firmware/builds/101835850)15:40
*** travis-ci has left #timvideos15:40
*** sb0 has quit IRC15:47
*** se6astian is now known as se6astian|away16:17
*** ivodd has quit IRC16:17
*** ivodd has joined #timvideos16:18
*** se6astian|away is now known as se6astian17:20
*** Bertl is now known as Bertl_zZ18:02
*** deeprave has joined #timvideos22:13
*** Bertl_zZ is now known as Bertl22:35
*** se6astian is now known as se6astian|away22:43

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