#timvideos

mithro: aps is

shenki: great!

Google is still offering the grant for GSoC students to attend conferences, which helps reduce the dependence on LA ponying up the money

nice

shenki: I'm currently chatting with them to see if we could get slightly larger amount because of the international travel.

mithro: cool

mithro: good luck

mithro: i had a few discussions about the US-centric thinking they have

mithro: where they think that $1k is enough to get anywhere

mithro: because it only costs $1k to get to anywhere in America, right?

shenki: you mean $500

mithro: ah, this was in the context of gsoc reunion

mithro: but yeah

mithro: $500 was all i managed to get when going to cambridge

shenki: yeah, I doubt they'll do anything - but you never know

that was lh bending the rules to make my summer of code in the US a 'conference' :)

mithro: on the gst-s gui there is the thumb and what do you call the large area?

canvas comes to mind

CarlFK: dunno

k, canvas till someone comes up with better. anyway...

there is huge (like seconds) lag between the thumb and the canvas

CarlFK: can you capture a video?

CarlFK: can you also check your CPU usage?

CarlFK: the creation of the thumb images is very CPU intensive

CarlFK: can you tell if it's dropping frames?

CarlFK: btw - gst-switch is quite a bit more CPU intensive than dvswitch

du no - I am using the bouncing ball test pattern. it looks smooth, but it could be dropping every 10 frames and I wouldn't noticed

top shows 22% cpu

okay, so that isn't the problem

load average: 2.20, 1.93, 1.22

its a 1 core box

CarlFK: how many cores?

oh

You really need ~1 core per video stream

but X is responsive - I can drag the window around no problem

CarlFK: well, create an issue on the issue tracker with as much information as you can

CarlFK: and I'll try and take a look at it

https://github.com/CarlFK/gst-switch/commits/ma... can you look over those 2 commits

Title: Commits · CarlFK/gst-switch · GitHub (at github.com)

CarlFK: send a pull request and I'll comment on it there

mithro: gitub lumped them into one PR - do you want that or should I split them?

CarlFK: I'll tell you when I look at them

CarlFK: probably one PR is going to be okay

[gst-switch] CarlFK opened pull request #29: minimal trusty build and demo (master...master) http://git.io/CImRxg

you can see that the two balls are not even close to the same

puck: can you fill out https://docs.google.com/forms/d/1u_fEtT0NtYm7WO... ?

Title: TimVideos Sprints before Linux.conf.au 2015 (at docs.google.com)

done

CarlFK: comments sent

mithro: whats with the sleeps causing fail? (guessing if it isn't long enough)

CarlFK: yeah

er, might not be long enough, then fail cuz it isn't ready

CarlFK: also you don't really get a useful messages about whats going on either

for demo, I would say keep it dirt simple, so bash script with longer sleeps if needed

I may try using my dvs-mon thing. the use case is about the same.. may just work

CarlFK: I want to demo to actually work, or tell you why it didn't work - but for now lets just merge your current script

well.. ideally demos work :D

CarlFK: yeah, it's also a balance between simplicity and a good demo too

dvswitch is almost 10 year old, and there still isn't a good system for launching the bits

CarlFK: yes, I know this - your little Python GUI thing was kind of nice but annoying because it needs a GUI

I used to worry about that, now I just go with what seems to be good enough

CarlFK: yeah

I also think it is like a sql server - you get the server and a cli, but that does not give you a contact management app

changes pushed - does that update my pull request?

CarlFK: yes, can you reply to the comments in the pull request?

mithro: I did, committed, pushed

er, I made the changes to the files (not reply)

CarlFK: can you reply to each comment with "Done" or "Did something else which is better"?

CarlFK: basic the process for pull requests normally is, 1) Send Pull request, 2) have it commented on, 3) push new commits, 4) reply to comments, 5) repeat steps 2->5 until it's merged.

CarlFK: generally the idea is to reply to each comment

it gets hard to follow what needs to be replied to

personally I think that was way more work than needed

I did figure out how to see that the canvas is way behind

CarlFK: it looks like you were trying to use email to do it?

github sends me email, I hit reply. pretty sure that attaches it back to the comment?

"Reply to this email directly or view it on GitHub."

CarlFK: yeah, it's much clearer on the web interface

CarlFK: btw, using correct punctuation in commit messages is a good idea

[gst-switch] mithro closed pull request #29: minimal trusty build and demo (master...master) http://git.io/CImRxg

look at the OS clock in the upper right - 57 sec, vs 52 (time coming from same box)

also, the thumb image stopped showing up. I have no idea why

CarlFK: how are you starting the connections?

hmm.. #ed out the 2nd source from run-demo, ran it. killed the gst-launch-1.0 process. been running variations of gst-launch-1.0 videotestsrc on the command line

killed srv and ui, ./run-demo.sh and now I have a thumb

what is the gst-launch commands you are using?

gst-launch-1.0 videotestsrc pattern=smpte is-live=1 \

! clockoverlay time-format="%S" font-desc="Sans 240" \

! video/x-raw, width=300, height=200 \

! gdppay \

! tcpclientsink port=3000 \

k, looks like it doesn't like it when I kill gst-launch and run it again - I get the empty thumb

I think I can script this

CarlFK: I *think* you want a leaky queue before the gdppay - but this is where thaytan could help us with what is going on exactly :)

huh, my script to demo the blank thumb doesn't, but it uncovered some other oddness

I think it is a side effect of the 5 second lag - I kill the source, then restart it, but the server is still running the old source for the 5 seconds

so it puts the new source in the 2nd slot

I have no idea what should be happening, so hard to file an issue

CarlFK: describe what you think should be happening and start from there

I expect the bug not to go away, and it isn't. so no problem

where does the server have 5 seconds worth of buffering?

that seems like a lot of HD video sitting in memory somewhere

mithro, atm it looks like I'll be flying into Auckland in the afternoon of the 7th

thaytan: okay awesome

but I'll be with my Dad, so I'll be not-really-available-except-for-some-debugging-sessions

thaytan: hopefully nowhere

That is, I can probably do a couple of hours a day, but not full 8 hour sessions

okay

http://nextdayvideo.com/site_media/static/img/t... I can't reliably get the thumb to be white. even reboot.. run script, sometimes it is blank, sometimes it has the image

CarlFK, you mean you can't capture a frame from the video stream succesfully?

CarlFK: how often does it happen?

thaytan: no. see the white thumb?

yp

yep

CarlFK: it's probably a good idea to have something to compare too :P

CarlFK, what's supposed to be drawing the thumb image?

thaytan: it should be colored and have a 57 in it.

mithro: I have rebooted 3 or 4 times. pretty sure I got the broken thumb (thats what I'll call it) the first time, but it has worked the other times

CarlFK: I mean screenshot wise

mithro: what about screenshot?

CarlFK: if you provide a screenshot of the working and the broken versions its easier for people to see what is going on

thaytan: no idea - I haven't looked at the code

http://nextdayvideo.com/site_media/static/img/t... thats shows the thumbs working

CarlFK, it looks like it is using a GstVideoOverlay into a drawing area

the most common problem there is usually a race between the xid being created vs when the pipeline needs an xwindow ID configured

tools/gstvideodisp.c

and/or running out of Xv ports, since it uses xvimagesink for each inpu

im guessing race, give I get different results across reboots

but the 5 sec lag is a bigger issue

there's no queue in the receiver pipeline - I'm not sure where 5 seconds delay would happen

unless it's in the TCP socket itself

but then you'd expect that to disappear when the sender disappears

there are a couple of locations that things could be being queued

let me pull up a diagram

<http://ln-s.net/-K7E>; (at docs.google.com)

there could be a queue from the video acceptor to the preview socket (inside the server), or in the preview socket to the display (in the UI stuff)

if I start the ui 15 sec after the server, then the lag is 15 sec

CarlFK: sounds like there is a buffer/queue on the output of the server to the UI

mithro: except the thumb doesn't suffer