| *** tpb has joined #timvideos | 00:00 | |
| thaytan | mithro, however long the decoder chose - 1000 * gst_buffer_get_size() / (bytes_per_sample * channels) / sample_rate | 01:29 |
|---|---|---|
| mithro | thaytan: what is that likely to be? | 01:35 |
| mithro | shenki: Peter Hutterer is still being awesome..... | 01:52 |
| mithro | libinput originally only supported single-tap and double-tap. With version 0.15 we now support multi-tap, so you can tap repeatedly to get a triple, quadruple, etc. click. This is quite useful in text editors where a triple click highlights a line, four clicks highlight a paragraph, and 28 clicks order a new touchpad from ebay. | 01:52 |
| shenki | lol | 01:52 |
| shenki | nice | 01:52 |
| mithro | MaZderMind: I just found out that Monday is a public holiday here, so that is another option too | 01:53 |
| mithro | shenki: did you see the DVB article? | 01:56 |
| mithro | http://blogs.s-osg.org/media-controller-support-for-dvb-part-1/ | 01:56 |
| tpb | Title: Media Controller Support for Digital Video Broadcasting | Open Source Group (at blogs.s-osg.org) | 01:56 |
| mithro | shenki: ping? | 02:35 |
| shenki | mithro: pong | 02:36 |
| mithro | shenki: what are you doing over the long weekend? | 02:36 |
| mithro | Does SA get the public holiday? | 02:36 |
| shenki | mithro: yeah, we get one. bits and pieces, not going away or anything though | 02:37 |
| mithro | shenki: would you be up for doing some scheduled HDMI2USB hacking? | 02:38 |
| shenki | mithro: i dont have a good chunk of time. perhaps on monday? | 02:38 |
| shenki | mithro: i like the idea of it | 02:39 |
| mithro | shenki: Could we do something like 1pm till 6pm on Monday maybe? | 02:40 |
| shenki | mithro: ill check | 02:40 |
| mithro | shenki: I was thinking we could spend the afternoon trying to figure out the EDID issue - I could use the oscilloscope here at work and you could replicate with your own one? | 02:41 |
| mithro | MaZderMind: btw there is already a "do-timestamp" property on interXXXsrc elements - I don't know if it does exactly what you want though | 02:46 |
| mithro | do-timestamp : Apply current stream time to buffers | 02:46 |
| *** hyades has joined #timvideos | 03:20 | |
| *** thaytan has quit IRC | 05:04 | |
| *** thaytan has joined #timvideos | 05:13 | |
| *** ChanServ sets mode: +v thaytan | 05:13 | |
| MaZderMind | you're right. I'll test with one of our bmd-cards today | 05:53 |
| MaZderMind | I initially had code in place that took the timestamp of the first incoming buffer as 0, but that does not work out correctly because the first video frame comes with pts 1/25s and the first audio buffer comes with timestamp 1/40s | 05:55 |
| MaZderMind | so while audio + video would stay in sync, you had 20ms shift right from the start | 05:56 |
| MaZderMind | the inter* elemets are btw. still nonblocking (i can stop & start the playback and the pipeline keeps running) | 05:56 |
| thaytan | MaZderMind, I'm not sure which scenario you're talking about | 05:57 |
| mithro | MaZderMind: btw have you tried setting timeout to be like 0.5ms and seeing where the black frame ends up | 05:57 |
| thaytan | I can talk generally about capture timestamps in GStreamer though if you like :) | 05:57 |
| thaytan | (I talked about it a bit in Auckland) | 05:58 |
| mithro | thaytan: MaZderMind is currently trying to play a mkv file through an intervideo+interaudio and finding the output audio/video is out of sync | 05:58 |
| thaytan | ah, strange | 05:59 |
| mithro | thaytan: the reason is that the inter elements are restamping the output buffers | 06:00 |
| thaytan | the inter elements should preserve sync, if the inter(video|audio)sinks are running with sync=true | 06:00 |
| thaytan | buffers should wait on the clock in the sink, then get handed over to the source at the right moment | 06:00 |
| thaytan | and retimestamping then preserves the relative sync | 06:00 |
| mithro | thaytan: oh, I had forgot about that - MaZderMind are you setting sync=True on the sink? | 06:01 |
| MaZderMind | thaytan: on the ML i got this: http://lists.freedesktop.org/archives/gstreamer-devel/2015-June/053027.html | 06:01 |
| tpb | Title: debugging a/v-sync issues, possibly inter*-element related (at lists.freedesktop.org) | 06:01 |
| MaZderMind | mithro: sync=True is default imo | 06:01 |
| MaZderMind | the thing is that incoming audio buffers are not perfectly aligned, because of clock drift in the actual sources (soundcards, camers, …) | 06:01 |
| thaytan | MaZderMind, that's not the mkv scenario any more | 06:02 |
| MaZderMind | the inter*element restamp based on seen seconds of audio (https://github.com/MaZderMind/gst-plugins-bad/blob/master/gst/inter/gstinteraudiosrc.c#L415) | 06:02 |
| tpb | Title: gst-plugins-bad/gstinteraudiosrc.c at master · MaZderMind/gst-plugins-bad · GitHub (at github.com) | 06:02 |
| MaZderMind | thaytan: ignore the mkv for a while :) | 06:03 |
| MaZderMind | that's just one way to get timstamped video and audio into gstreamer | 06:03 |
| MaZderMind | i can reproduce all with uriplaybin | 06:03 |
| thaytan | MaZderMind, for the live capture case, you need to make sure the timestamps on video and audio can be compared | 06:03 |
| thaytan | so they need to share a clock and base-time | 06:04 |
| thaytan | when you're doing all the capture within one pipeline that's fairly easy | 06:04 |
| thaytan | distributing it across machines, you need to use a network clock to sync things up | 06:04 |
| thaytan | which is what flumotion does | 06:04 |
| MaZderMind | yes, i'm aware of that, but it's not the problem. the audio/video sync gets lost within the inter*elements. see this case for example: https://github.com/voc/voctomix/blob/c92b03943beeec94fab5afd68f22a5c0d249d7ab/voctocore/experiments/avsync-fileio-clock.py | 06:05 |
| tpb | Title: voctomix/avsync-fileio-clock.py at c92b03943beeec94fab5afd68f22a5c0d249d7ab · voc/voctomix · GitHub (at github.com) | 06:05 |
| thaytan | and my recollection of the inter*sinks is that they'll do synching OK if the incoming streams have sensible timestamps | 06:05 |
| thaytan | Nicolas says otherwise in that email, of course | 06:05 |
| thaytan | so maybe I should re-read the code | 06:05 |
| MaZderMind | thaytan: take a look here: https://github.com/MaZderMind/gst-plugins-bad/blob/master/gst/inter/gstinteraudiosrc.c#L415 | 06:05 |
| tpb | Title: gst-plugins-bad/gstinteraudiosrc.c at master · MaZderMind/gst-plugins-bad · GitHub (at github.com) | 06:05 |
| MaZderMind | that's not taking the incoming timestamp into account | 06:06 |
| * MaZderMind is afk for a while, driving to work | 06:06 | |
| thaytan | MaZderMind, no, it's retimestamping | 06:06 |
| thaytan | which will be OK as long as both inter*src are doing the same retimestamping | 06:07 |
| thaytan | I need to re-read that code | 06:07 |
| MaZderMind | it's ok for video but not for audio, because the audio sample timestamps are not always linear increasing | 06:09 |
| thaytan | the waiting in the sink is supposed to handle that | 06:14 |
| thaytan | samples getting handed over to the src element at the right moment | 06:14 |
| thaytan | while the src is generating a continuous output re-timestamped stream | 06:14 |
| thaytan | MaZderMind, nicolas' comment on the ML about using compositor these days is true though | 06:15 |
| thaytan | but requires a newer GStreamer than you guys want to | 06:15 |
| MaZderMind | thaytan: i'm running master, so no worries there | 06:22 |
| MaZderMind | but that hand-over cannot be guaranteed to be constant time? | 06:23 |
| MaZderMind | i measured the audio drifting with git master, so i know it does not work ;) | 06:24 |
| MaZderMind | and i also saw it in practice: i had a test-stream running for 20 hours and the audio drifted 2-3 seconds | 06:28 |
| *** miselin has quit IRC | 07:06 | |
| *** miselin has joined #timvideos | 07:52 | |
| MaZderMind | when readng from the decklink-card with ffmpeg and encapsulating the raw video/audio in mkv, as I were planning to do, the incoming timestamps start with 0:00:00.000000000 | 08:19 |
| MaZderMind | hihi but the streaming system reports 'Queue input is backward in time' xD | 08:23 |
| MaZderMind | yea, ok, i think my crude hyck is too simple, ffmpeg warns about '[segment @ 0x23c7640] Non-monotonous DTS in output stream 0:1; previous: 200255, current: 200207; changing to 200256. This may result in incorrect timestamps in the output file.' | 08:26 |
| *** CarlFK has quit IRC | 10:31 | |
| *** CarlFK has joined #timvideos | 13:19 | |
| *** ChanServ sets mode: +v CarlFK | 13:19 | |
| *** CarlFK has quit IRC | 13:57 | |
| *** f15h has joined #timvideos | 14:17 | |
| *** CarlFK has joined #timvideos | 14:21 | |
| *** ChanServ sets mode: +v CarlFK | 14:21 | |
| *** f15h has quit IRC | 16:44 | |
| *** hyades has quit IRC | 16:48 | |
| *** hyades has joined #timvideos | 17:17 | |
| *** hyades has quit IRC | 18:54 | |
| *** Niharika has quit IRC | 18:54 | |
| *** CARAM__ has quit IRC | 18:54 | |
| *** hyades has joined #timvideos | 20:41 | |
| *** CARAM__ has joined #timvideos | 20:50 | |
| *** Niharika has joined #timvideos | 20:55 | |
| *** _florent_ has joined #timvideos | 20:59 | |
| *** _florent_ has quit IRC | 22:49 | |
| *** CarlFK has quit IRC | 23:04 | |
| *** CarlFK has joined #timvideos | 23:11 | |
| *** ChanServ sets mode: +v CarlFK | 23:11 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!