| *** tpb has joined #timvideos | 00:00 | |
| CarlFK | thaytan: you are our local gst ninja right? | 00:17 |
|---|---|---|
| thaytan | CarlFK, for now! | 00:21 |
| CarlFK | thaytan: I am using this in place of vocto: | 00:22 |
| thaytan | although ystreet00 is technically closer to mithro :) | 00:22 |
| CarlFK | gst-launch-1.0 tcpserversrc port=10000 ! decodebin ! fpsdisplaysink | 00:22 |
| thaytan | OK | 00:22 |
| CarlFK | this client https://github.com/xfxf/video-scripts/blob/master/carl/hu-alsa.sh | 00:22 |
| tpb | Title: video-scripts/hu-alsa.sh at master · xfxf/video-scripts · GitHub (at github.com) | 00:22 |
| thaytan | needs a queue, but OK | 00:22 |
| CarlFK | ha! | 00:22 |
| CarlFK | I bet that's it ;) | 00:23 |
| CarlFK | anyway... | 00:23 |
| CarlFK | er | 00:23 |
| CarlFK | where? | 00:23 |
| thaytan | after tcpserversrc | 00:23 |
| CarlFK | cuz if that fixes is.. that's all that matters and we may have the last blocker | 00:23 |
| CarlFK | oh... | 00:24 |
| CarlFK | fine :p | 00:24 |
| thaytan | is the playback stuttery? | 00:24 |
| CarlFK | let me put that in for good measure | 00:24 |
| CarlFK | playback is fine for 5 min | 00:24 |
| CarlFK | then over 30 seconds degrades to about 1fps | 00:24 |
| thaytan | ah, that may be more of a clock drift issue | 00:25 |
| CarlFK | that's my guess | 00:25 |
| thaytan | the server is sending slightly slower than the client wants to receive | 00:25 |
| CarlFK | oh.. I was thinking v4l and alsa | 00:26 |
| thaytan | so after a while to client gets more than 1 frame out of sync and starts dropping things because they're arriving late | 00:26 |
| CarlFK | both are on the same machine.. so... | 00:26 |
| thaytan | there's 3 clocks there: v4l and alsa on the sender which will choose ALSA and sync delivery to that | 00:26 |
| thaytan | and on the receiver there's whichever clock it's choosing - probably the system clock | 00:26 |
| CarlFK | ah | 00:27 |
| thaytan | so one pipeline is tracking time against the audio clock, and the receiver is tracking against the system clock | 00:27 |
| thaytan | depends how quickly they diverge by 1/fps | 00:27 |
| CarlFK | how can I force the client to use the system clock ? | 00:28 |
| CarlFK | where client is the ting reading from v4l/alsa | 00:28 |
| CarlFK | seems you were calling that the server ? | 00:28 |
| thaytan | there 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 print | 00:29 |
| CarlFK | 1 and 2 are out because I don't want (can't) change the server (voctomix) | 00:30 |
| CarlFK | so lets try 3 | 00:30 |
| *** sb0 has joined #timvideos | 00:31 | |
| CarlFK | server side New clock: GstSystemClock | 00:31 |
| CarlFK | client side got burried in debug=3 | 00:32 |
| CarlFK | client side New clock: GstSystemClock | 00:32 |
| CarlFK | ok, 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 celebrate | 00:34 |
| CarlFK | thaytan: I think you nailed it. | 01:27 |
| CarlFK | test server went 10 min without issue, so I put this into are full stack and ... 1 hour later, no probem | 01:28 |
| CarlFK | xfxf: ^^^ | 01:28 |
| xfxf | rad. for me this sometimes took multiple hours | 01:46 |
| xfxf | also ensure the saved files keep av sync | 01: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 late | 01:49 |
| CarlFK | think about that... | 01:49 |
| *** sb0 has quit IRC | 01:50 | |
| CarlFK | I think that means if a remote box clock drifts but 1/30 seconds, it happens | 01:51 |
| CarlFK | little fuzzy on why we still get 1 frame and not 0 frames | 01:52 |
| thaytan | CarlFK, if frames are arriving late, GStreamer will still display 1 frame per second as emergency frames | 02:04 |
| CarlFK | thaytan: bingo. | 02:05 |
| CarlFK | I was hoping it was that simple | 02:05 |
| CarlFK | thaytan: 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 laptop | 02:06 |
| CarlFK | that will be v4l and testaudiosrc | 02:06 |
| thaytan | CarlFK, back to different clocks | 02:07 |
| CarlFK | so it will use the laptop os clock | 02:07 |
| CarlFK | yeah | 02:07 |
| thaytan | but with ntpd they hopefully stay synched well enough | 02:07 |
| thaytan | otherwise you need to learn about using RTP or GStreamer network clocks to sync things | 02:07 |
| CarlFK | oh, we have the laptops. so testing now should be valid when we go live | 02:09 |
| CarlFK | the remote source will be the presenters laptop feed, so we will survive with the 1fps emergency frame | 02:10 |
| thaytan | CarlFK, that's only for display, btw - it only applies to sinks with sync=true | 02:12 |
| thaytan | all the frames will still be received and muxed according to the timestamps in the matroska feed | 02:12 |
| CarlFK | thaytan: oh... | 02:13 |
| CarlFK | er oh | 02:13 |
| CarlFK | ! | 02:13 |
| thaytan | if audio is captured somewhere else, and timestamps don't match then that'll lead to unsynched audio and video in the recording | 02:13 |
| thaytan | so still need to be careful | 02:13 |
| thaytan | you may not notice a few hundreds of milliseconds drift on the presenter slides feed | 02:13 |
| thaytan | but you will in their audio and presenter mouth video | 02:14 |
| CarlFK | audio and camera are on the box running the mixer | 02:14 |
| thaytan | flumotion avoids that by distributing a GStreamer network clock to all the capture machines so they're sharing and timestamping with a common clock | 02:14 |
| mithro | _florent_: That stuff in the HV30 issue is the "optimal" solution for the HV30 capture | 02:24 |
| mithro | _florent_: First, is to just capture the interlaced HDMI signal | 02:25 |
| *** rohitksingh has joined #timvideos | 02:29 | |
| xfxf | thaytan: in that case is this something voctomiz should be implementing? | 02:39 |
| xfxf | because remote feeds are fed in with a gst-launch pipeline feeding to tcp | 02:40 |
| xfxf | sorry for terseness, phone | 02:40 |
| thaytan | xfxf, yes, they need *something* to cope with long-term drift | 02:50 |
| xfxf | right | 02:51 |
| xfxf | MaZderMind: see above? comments? | 02:51 |
| CarlFK | thaytan: what happens if ntpd adjusts the os clock while all this is happening? | 02:55 |
| thaytan | CarlFK, the clock GStreamer uses (CLOCK_MONOTONIC) will change frequency based on ntp adjustments | 02:57 |
| thaytan | ntp is supposed to do gradual adjustments | 02:57 |
| thaytan | so you see some non-linearity in the clock | 02:57 |
| thaytan | but it never 'jumps' | 02:57 |
| thaytan | and because it's the monotonic system clock, it especially never adjusts backwards | 02:58 |
| CarlFK | trying to follow is making my head hurt ;) so let me go high level... | 02:59 |
| CarlFK | given 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 |
| thaytan | yes | 03:01 |
| CarlFK | yay! | 03:01 |
| mithro | we had this discussion at the hackfest last year | 03:56 |
| mithro | remeber the whiteboard diagrams? | 03:56 |
| CarlFK | mithro: I do. stop trying to make my head hurt again :p | 04:02 |
| CarlFK | mithro: 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 clock | 04:05 |
| CarlFK | and today I don't really want to know | 04:06 |
| CarlFK | I am now pondering how to run these things in production | 04:08 |
| mithro | CarlFK: with very expensive people | 04:09 |
| CarlFK | um.. what? | 04:09 |
| *** rohitksingh has quit IRC | 05:16 | |
| mithro | CarlFK: oh - in TV stations there is a piece of coax which runs around the building and provides the "sync clock" that everything locks too | 07:30 |
| xfxf | fyi, 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 exist | 07:55 |
| xfxf | i'm just trying to stay as much in 'non technical project manager' territory for LCA | 07:56 |
| xfxf | already started poking at voctomix code a few nights ago, but then stopped, not a good use of time right now | 07:56 |
| xfxf | CarlFK: 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 |
| xfxf | mithro: i just got shipment notification from numato - not arriving until week after next now | 07:57 |
| xfxf | er, sorry, next week rather, not this week | 07:57 |
| *** se6astian|away is now known as se6astian | 08:00 | |
| mithro | Can you send me shipping info? | 08:00 |
| xfxf | done | 08:02 |
| mithro | xfxf: they are looking into what is up | 08:22 |
| xfxf | thanks | 08:36 |
| MaZderMind | CarlFK: you *can* change the server by sending mie a ticket or a PR ;) | 09:43 |
| MaZderMind | that thing with the 1 frame per second as emergency frames was new to mee, too | 09:46 |
| MaZderMind | It would be trivial to add a NetworkClockProvider to voctocore | 09:47 |
| MaZderMind | but I don't think it would be usable on a gst-lounch command-line | 09:47 |
| MaZderMind | one would need a simple c- or py-program around it | 09:48 |
| MaZderMind | up 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/46 | 09:52 |
| tpb | Title: Provide GstNetworkTime + Example Source · Issue #46 · voc/voctomix · GitHub (at github.com) | 09:52 |
| xfxf | MaZderMind: yay, thanks :) | 10:14 |
| MaZderMind | xfxf: those bugfixes ^ are just another prove why I want your scripts in the example-scripts directory | 10:20 |
| MaZderMind | and they are a prove that setting up a complete mixing solution will always need adaption to the actual conditions | 10:21 |
| xfxf | yeah, nod. agreed with example scripts, let us make them work first :) | 10:44 |
| xfxf | and i'm assuming for the thing above we'll have to have a python script using the gst bindings versus a gst-launch line | 10:44 |
| xfxf | but 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 |
| xfxf | blah, i just remembered i've done this before, but a long long time ago | 10:46 |
| MaZderMind | xfxf: I'll try to get an example up in the next days | 10:55 |
| xfxf | neat, ta | 10:55 |
| mithro | xfxf: so - that webcam... | 11:10 |
| xfxf | oh, right | 11:13 |
| xfxf | so | 11:13 |
| xfxf | https://github.com/xfxf/video-scripts/blob/master/ryan/lca/webcam-mjpeg-v4l.sh | 11:13 |
| tpb | Title: video-scripts/webcam-mjpeg-v4l.sh at master · xfxf/video-scripts · GitHub (at github.com) | 11:13 |
| xfxf | that was my attempt | 11:13 |
| xfxf | it did not work | 11:13 |
| *** sb0 has joined #timvideos | 11:18 | |
| mithro | I have so many domain names I have a spreadsheet to track them all.. | 11:33 |
| xfxf | ha, i used to do that | 11:33 |
| xfxf | i let many lapse a bunch of years back | 11:33 |
| xfxf | so many one page websites for lols | 11:33 |
| xfxf | or PTR records for stupid subdomains to use on IRC | 11:34 |
| xfxf | mithro: i believe you were going to help me with the script above? :) | 11:49 |
| xfxf | webcam ready to go, keen to test vocto with 2x inputs, 1x via network | 11:49 |
| mithro | xfxf: so that looks like it should work | 11:53 |
| mithro | xfxf: what happens? | 11:53 |
| *** Bertl_zZ is now known as Bertl | 11:54 | |
| xfxf | oh, it does, it just errors on the alsa stuff for some reason | 11:56 |
| xfxf | changing alsa to audiotestsrc makes it work | 11:56 |
| xfxf | hmm, for a hdmi2usb with no audio input, what audio source should i be muxing in (given voctomix requires audio+video)? | 11:56 |
| xfxf | audiotestsrc isn't silent | 11:56 |
| mithro | audiotestsrc volume=0 ? | 11:58 |
| thaytan | audiotestsrc wave=silence | 12:00 |
| xfxf | right, 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 |
| xfxf | i'm gathering yes | 12:01 |
| thaytan | if you need dummy input, it's the easiest choice | 12:03 |
| xfxf | cool, ta | 12:12 |
| MaZderMind | xfxf: 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 tcpsinks | 12:24 |
| MaZderMind | adding silence to the videosources that don't provide audio seemed simpler so me back then | 12:25 |
| xfxf | i'm fine with this for now | 13:09 |
| xfxf | okay, now testing with 2x 720p30 inputs (directly connected webcam w/ dummy audio, network connected hdmi2usb w/ alsa mux) using PiP | 13:09 |
| xfxf | will let it capture overnight | 13:09 |
| xfxf | MaZderMind: amusingly i have a bmd capture card in one of the machines i'm capturing from too, but not using it | 13:14 |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:16 | |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:16 | |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:17 | |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:19 | |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:34 | |
| mithro | Well, I got a bunch of small things done today | 13:37 |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:38 | |
| xfxf | mithro: 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 #timvideos | 13: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 #timvideos | 13:40 | |
| mithro | xfxf: last code change on main was on Dec 3, 2015 | 13:41 |
| mithro | xfxf: all the changes for the Opsis board have been in a separate branch | 13:41 |
| mithro | xfxf: the fx2 firmware rewrite has also been in a separate branch | 13:41 |
| xfxf | ah, right, all good then | 13:46 |
| *** travis-ci has joined #timvideos | 13: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 #timvideos | 13:48 | |
| *** travis-ci has joined #timvideos | 14: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 #timvideos | 14:08 | |
| *** travis-ci has joined #timvideos | 14: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 #timvideos | 14:10 | |
| *** travis-ci has joined #timvideos | 14: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 #timvideos | 14:35 | |
| CarlFK | xfxf: 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 #timvideos | 15: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 #timvideos | 15:40 | |
| *** sb0 has quit IRC | 15:47 | |
| *** se6astian is now known as se6astian|away | 16:17 | |
| *** ivodd has quit IRC | 16:17 | |
| *** ivodd has joined #timvideos | 16:18 | |
| *** se6astian|away is now known as se6astian | 17:20 | |
| *** Bertl is now known as Bertl_zZ | 18:02 | |
| *** deeprave has joined #timvideos | 22:13 | |
| *** Bertl_zZ is now known as Bertl | 22:35 | |
| *** se6astian is now known as se6astian|away | 22:43 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!