Friday, 2015-06-05

*** tpb has joined #timvideos00:00
thaytanmithro, however long the decoder chose - 1000 * gst_buffer_get_size() / (bytes_per_sample * channels) / sample_rate01:29
mithrothaytan: what is that likely to be?01:35
mithroshenki: Peter Hutterer is still being awesome.....01:52
mithrolibinput 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
mithroMaZderMind: I just found out that Monday is a public holiday here, so that is another option too01:53
mithroshenki: did you see the DVB article?01:56
tpbTitle: Media Controller Support for Digital Video Broadcasting | Open Source Group (at
mithroshenki: ping?02:35
shenkimithro: pong02:36
mithroshenki: what are you doing over the long weekend?02:36
mithroDoes SA get the public holiday?02:36
shenkimithro: yeah, we get one. bits and pieces, not going away or anything though02:37
mithroshenki: would you be up for doing some scheduled HDMI2USB hacking?02:38
shenkimithro: i dont have a good chunk of time. perhaps on monday?02:38
shenkimithro: i like the idea of it02:39
mithroshenki: Could we do something like 1pm till 6pm on Monday maybe?02:40
shenkimithro: ill check02:40
mithroshenki: 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
mithroMaZderMind: btw there is already a "do-timestamp" property on interXXXsrc elements - I don't know if it does exactly what you want though02:46
mithro  do-timestamp        : Apply current stream time to buffers02:46
*** hyades has joined #timvideos03:20
*** thaytan has quit IRC05:04
*** thaytan has joined #timvideos05:13
*** ChanServ sets mode: +v thaytan05:13
MaZderMindyou're right. I'll test with one of our bmd-cards today05:53
MaZderMindI 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/40s05:55
MaZderMindso while audio + video would stay in sync, you had 20ms shift right from the start05:56
MaZderMindthe inter* elemets are btw. still nonblocking (i can stop & start the playback and the pipeline keeps running)05:56
thaytanMaZderMind, I'm not sure which scenario you're talking about05:57
mithroMaZderMind: btw have you tried setting timeout to be like 0.5ms and seeing where the black frame ends up05:57
thaytanI 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
mithrothaytan: MaZderMind is currently trying to play a mkv file through an intervideo+interaudio and finding the output audio/video is out of sync05:58
thaytanah, strange05:59
mithrothaytan: the reason is that the inter elements are restamping the output buffers06:00
thaytanthe inter elements should preserve sync, if the inter(video|audio)sinks are running with sync=true06:00
thaytanbuffers should wait on the clock in the sink, then get handed over to the source at the right moment06:00
thaytanand retimestamping then preserves the relative sync06:00
mithrothaytan: oh, I had forgot about that - MaZderMind are you setting sync=True on the sink?06:01
MaZderMindthaytan: on the ML i got this:
tpbTitle: debugging a/v-sync issues, possibly inter*-element related (at
MaZderMindmithro: sync=True is default imo06:01
MaZderMindthe thing is that incoming audio buffers are not perfectly aligned, because of clock drift in the actual sources (soundcards, camers, …)06:01
thaytanMaZderMind, that's not the mkv scenario any more06:02
MaZderMindthe inter*element restamp based on seen seconds of audio (
tpbTitle: gst-plugins-bad/gstinteraudiosrc.c at master · MaZderMind/gst-plugins-bad · GitHub (at
MaZderMindthaytan: ignore the mkv for a while :)06:03
MaZderMindthat's just one way to get timstamped video and audio into gstreamer06:03
MaZderMindi can reproduce all with uriplaybin06:03
thaytanMaZderMind, for the live capture case, you need to make sure the timestamps on video and audio can be compared06:03
thaytanso they need to share a clock and base-time06:04
thaytanwhen you're doing all the capture within one pipeline that's fairly easy06:04
thaytandistributing it across machines, you need to use a network clock to sync things up06:04
thaytanwhich is what flumotion does06:04
MaZderMindyes, 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:
tpbTitle: voctomix/ at c92b03943beeec94fab5afd68f22a5c0d249d7ab · voc/voctomix · GitHub (at
thaytanand my recollection of the inter*sinks is that they'll do synching OK if the incoming streams have sensible timestamps06:05
thaytanNicolas says otherwise in that email, of course06:05
thaytanso maybe I should re-read the code06:05
MaZderMindthaytan: take a look here:
tpbTitle: gst-plugins-bad/gstinteraudiosrc.c at master · MaZderMind/gst-plugins-bad · GitHub (at
MaZderMindthat's not taking the incoming timestamp into account06:06
* MaZderMind is afk for a while, driving to work06:06
thaytanMaZderMind, no, it's retimestamping06:06
thaytanwhich will be OK as long as both inter*src are doing the same retimestamping06:07
thaytanI need to re-read that code06:07
MaZderMindit's ok for video but not for audio, because the audio sample timestamps are not always linear increasing06:09
thaytanthe waiting in the sink is supposed to handle that06:14
thaytansamples getting handed over to the src element at the right moment06:14
thaytanwhile the src is generating a continuous output re-timestamped stream06:14
thaytanMaZderMind, nicolas' comment on the ML about using compositor these days is true though06:15
thaytanbut requires a newer GStreamer than you guys want to06:15
MaZderMindthaytan: i'm running master, so no worries there06:22
MaZderMindbut that hand-over cannot be guaranteed to be constant time?06:23
MaZderMindi measured the audio drifting with git master, so i know it does not work ;)06:24
MaZderMindand i also saw it in practice: i had a test-stream running for 20 hours and the audio drifted 2-3 seconds06:28
*** miselin has quit IRC07:06
*** miselin has joined #timvideos07:52
MaZderMindwhen 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.00000000008:19
MaZderMindhihi but the streaming system reports 'Queue input is backward in time' xD08:23
MaZderMindyea, 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 IRC10:31
*** CarlFK has joined #timvideos13:19
*** ChanServ sets mode: +v CarlFK13:19
*** CarlFK has quit IRC13:57
*** f15h has joined #timvideos14:17
*** CarlFK has joined #timvideos14:21
*** ChanServ sets mode: +v CarlFK14:21
*** f15h has quit IRC16:44
*** hyades has quit IRC16:48
*** hyades has joined #timvideos17:17
*** hyades has quit IRC18:54
*** Niharika has quit IRC18:54
*** CARAM__ has quit IRC18:54
*** hyades has joined #timvideos20:41
*** CARAM__ has joined #timvideos20:50
*** Niharika has joined #timvideos20:55
*** _florent_ has joined #timvideos20:59
*** _florent_ has quit IRC22:49
*** CarlFK has quit IRC23:04
*** CarlFK has joined #timvideos23:11
*** ChanServ sets mode: +v CarlFK23:11

Generated by 2.13.1 by Marius Gedminas - find it at!