:: #mythtv

Daily chat history

Current users (87):

aca20031, aloril, Anssi, Beirdo_, bobweaver, brfransen, Captain_Murdoch, cesman, Chutt, clever, coling_, Cougar, danielk22, danielk221, dblain, dekarl, ElmerFudd, fetzerch, foobum, foxbuntu`, ghoti, Gibby, gigem, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jhall_, jheizer_, joe_____, joki, jpabq, jpabq_, jpharvey, jst_, jwhite, jya, jya_, kc, kenni, knightr_, kormoc, KungFuJesus, kurre2, kwmonroe, laga, Moeabm, moparisthebest, MythBuild, MythLogBot, natanojl, nephyrin, neufeld, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, rsiebert, Seeker`, seld, Sharky112065, skd5aner, sl1ce_1g, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, unforgiven512, wagnerrp, wahrhaft, whoDat, wolfgang2, XChatMav, XDS2010_, xris, _charly_
Tuesday, June 25th, 2013, 00:03 UTC
[00:03:34] stichnot: neufeld: For HD-PVR .srt captions, if you're using the REC_STARTED_WRITING system event, is there any reason to use the "-endat" argument to ccextractor, as opposed to just killing the ccextractor process in the recording-end script?
[00:04:31] stichnot: If not, it's that much simpler to modify mythccextractor to be a replacement for ccextractor.
[00:05:35] stichnot: And I was thinking, it may be possible to have mythccextractor listen for the REC_FINISHED event and shut down by itself.
[00:06:04] bobweaver: Yeah you are right jya. seems like all the errors and logs talk about mythdbcon (connecting to db )and SignalHanderler is really freaking out . mythcorecontext and mythsocket keeps on not geting connections serverpool fails to bind to uds. the list goes on and on.
[00:06:33] bobweaver: s|uds|udp
[00:06:58] jya_: sounds like you have another instance of mythbackend already running
[00:07:12] bobweaver: huh ps aux says nothing
[00:07:37] jya_: i found in ubuntu that often service mythbackend doesn't properly kill the backend and I end up with zombies
[00:09:33] bobweaver: jya, but ps aux would find them or do you think I should maybe use htop ?
[00:09:42] bobweaver: jya, source that I got 0.27 from
[00:09:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds)
[00:10:01] jya_: yes, ps ax | grep backend should have found something
[00:10:16] bobweaver: atm I am DL qt5.1 and mythtv from github and try to see if it works out better
[00:10:26] jya_: anyhow, you probably have better success in mythtv-users for that
[00:43:38] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[01:14:15] ** neufeld returns to keyboard **
[01:14:27] neufeld: Ah, stichnot has vanished.
[01:17:13] neufeld: stichnot: the -endat argument is for safety. If, for some reason, the recording-end script doesn't run (maybe the backend crashes during the recording), then the ccextractor will keep running, holding the PVR-150/PVR-500 device. Subsequent recordings made on that device will fail, the scheduler won't know it's out of service. Subsequent caption captures on the HD-PVR will fail because the new ccextractor process
[01:17:13] neufeld: can't grab the stream. I do kill the process in the recording-end script, also. Redundancy for safety.
[01:20:03] stichnot (stichnot! has joined #mythtv
[01:20:04] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[01:20:04] stichnot (stichnot! has quit (Changing host)
[01:26:43] sl1ce (sl1ce! has joined #mythtv
[01:51:07] neufeld: stichnot: I answered your question, I can repeat it if you don't have it in scrollback logs
[02:06:44] nyloc (nyloc! has joined #mythtv
[02:10:24] _nyloc_ (_nyloc_! has quit (Ping timeout: 246 seconds)
[02:29:08] stichnot: neufeld: thanks, I saw your response in the logs.
[02:29:15] neufeld: stichnot: OK
[02:31:27] neufeld: stichnot: it can, of course, be faked up with a subshell, an appropriate sleep, and a kill $!
[02:31:28] stichnot: Good point about the backend potentially crashing/restarting in the middle of a ccextractor run.
[02:32:21] stichnot: And another good point about the subshell. :)
[02:32:35] neufeld: stichnot: also not sure whether the finalize script would be run if you deleted an in-progress recording because you changed your mind.
[02:33:31] stichnot: I think that the event should be sent regardless of why the backend stops the recording, but I'm not positive.
[02:37:57] neufeld: stichnot: there's a collection of potential edge cases to watch for. So, as I said, for safety I have it exit itself, if nothing else stops it. Oh, one more thing, I'm not sure if a kill makes it flush its output buffers. ccextractor doesn't output synchronously, at least with the arguments I use, so a kill might lose whatever buffered output is waiting to go to spinning metal.
[02:43:45] neufeld: stichnot: that might affect your live TV .srt work. You might need to patch in a setvbuf(*,*,_IONBF,*) in ccextractor, or even mythccextractor
[02:45:56] neufeld: Hmm. That might not work. Looking at the ccextractor code, it uses write(), not fwrite(), which means it must be doing its own buffering. That would make it immune to setvbuf() tweaking.
[02:48:03] stichnot: I tried adding stuff to make their writes unbuffered, but failed. I was thinking that certainly without the -endat option, it should be fairly simple to adapt mythccextractor.
[02:48:44] stichnot: As it is, my linux box seems to flush every 30 seconds, so if you can watch at least 30 seconds behind realtime, you'll be good.
[02:52:34] neufeld: I'm thinking I should take another look at mythccextractor. If I can teach it to put in timecode biases, and give it an -endat, I can probably use it in my scripts instead of ccextractor. The ccextractor project is very useful, an invaluable part of my system, but its code is a bit opaque to new entrants. I can also fix the biases in post-processing, I've already got perl scripts that know how to parse .srt files
[02:52:34] neufeld: and adjust the timestamps.
[02:53:05] ** neufeld pulls head **
[02:55:00] wilmoore-misc (wilmoore-misc! has joined #mythtv
[02:55:08] neufeld: Well, mythccextractor is mature... no checkins in a very long time
[02:57:24] neufeld: Umm, that's the wrapper. All the real work is in libraries in other directories. Well, I'll get to that later. It's late.
[03:03:52] ** neufeld goes AFK **
[03:05:13] tonsofpcs: hi
[03:06:10] tonsofpcs: neufeld: timecode biases?
[03:06:49] ** neufeld walks past and sees his name **
[03:07:13] tonsofpcs: yes, that indeed it is.
[03:07:32] tonsofpcs: I should make a CC timing reference file...
[03:08:08] tonsofpcs: (I need something to do with the new Premiere caption feature)
[03:09:27] neufeld: tonsofpcs: between the latency differences involved in the STB doing HD decoding vs. SD decoding, HD-PVR encoding latency vs. PVR-150/PVR-500 decoding latency, and HD-PVR keyframe wait (up to 4 seconds), if you pulled a straight .srt file off the PVR-150 and tried to watch the captions on the HD-PVR, you could not be certain you'd be close. The scripts I wrote dump the VBI data to a raw data format, and then compute
[03:09:27] neufeld: a bias based on the observed startup latencies, so it can generate a .srt file that corresponds to the PTS codes in the H.264 file.
[03:11:40] neufeld: tonsofpcs: however... as .srt files are easily parsed, it's trivial to modify the .srt timecodes after the fact, if necessary. I do that when I cut commercials out of HD-PVR recordings, because otherwise the .srt file would be unsynchronized.
[03:12:25] tonsofpcs: there's about 3 dozen ways (ok, closer to a half dozen) to store captions in the stream, why would you store them separately?
[03:13:57] neufeld: tonsofpcs: I start with it separate. The .srt file is generated by the PVR-500 module. Then, on my system, I like to use TS files because I often use the cutlist editor to jump around a file during playback. You can't mix a .srt stream into a TS, and I haven't taken the time to figure out how to convert the .srt file into DVB pixmaps.
[03:15:04] tonsofpcs: but SRT > SMPTE-TT is trivial, is it not? then SMPTE-TT > 708 should be easy....
[03:18:10] stichnot: neufeld: also, I shouldn't forget that mythccextractor and mythfrontend could cooperate on retaining the position info for the captions.
[03:18:14] neufeld: Well, I do have an SMPTE-TT spec document in my directory of helpful things, but I didn't go down that path. With the .srt file method, the captions are available within 3 seconds of the recording being completed, and I don't have to mux anything into it, so I don't modify the recording file on disc. I consider that safer, there's nothing my captioning scripts can do to make things go away.
[03:18:59] stichnot: neufeld: with the latest changes in Master, captions are available in real time (except for the ccextractor buffering delay)
[03:19:03] tonsofpcs: is it an issue that the captuer hardware can't handle storing the captions as transmitted?
[03:19:05] neufeld: stichnot: absolutely. I've been pondering that over the past couple of weeks. Still have the pain that the VBI data is in cursor I/J, and the srt file wants "pixel" X/Y, and who's to say how many pixels there are?
[03:19:24] neufeld: tonsofpcs: correct. The captions aren't transmitted over HD connectors
[03:19:26] stichnot: I say there are 1000 pixels.
[03:19:38] tonsofpcs: neufeld: huh?
[03:20:18] stichnot: tonsofpcs: there is nothing analogous to line-22 VBI for video transmitted over component or HDMI.
[03:20:34] neufeld: tonsofpcs: closed caption data is not available on high-definition outputs of set-top boxes in North America. It can be open-captioned in the STB, but there is no standard for the transmission of text data between STB and TV over HDMI or component.
[03:21:12] neufeld: tonsofpcs: so, my scripts work around it with a separate encoder.
[03:21:36] tonsofpcs: right, HDMI is terrible. Component *can* but no one uses the 1135 line system ...
[03:22:24] neufeld: tonsofpcs: the end result is that the HD-PVR capture device does not put closed captions into its H.264 transport stream. If you want captions, you have to come up with another trick.
[03:22:26] tonsofpcs: oh, I see what you're doing. You're taking CVBS Line 21 and storing it on the side
[03:22:58] stichnot: tonsofpcs: sorry, I meant line-21 not line-22
[03:22:58] neufeld: Yes. I'm using the fact that the STB outputs VBI data on the SD connection, sniff that, and drop it in beside the .mpg file.
[03:23:37] tonsofpcs: if there's XDS, you can use that to match time to the start of a program... I don't know anyone that inserts XDS anymore though (ok, I lied, I still put XDS into the direct feed I hand off to the cable company for their analog tier but that's gonna be gone soon
[03:23:42] tonsofpcs: )
[03:23:44] stichnot: neufeld: seriously, I would just arbitrarily dictate that the "virtual" screen is 1000x1000 pixels and map the cursor coordinates to and from that coordinate system.
[03:23:44] neufeld: tonsofpcs: so, my initial state is .srt file + .mpg file, but with imperfectly matching time codes.
[03:24:29] neufeld: tonsofpcs: there is XDS data sometimes, but I don't count on it. I just measure the .mpg file afterwards and count backwards.
[03:24:33] tonsofpcs: neufeld: can you do image fingerprinting? or perhaps a cruder version where you mark the first time beyond start that three random parts of the screen turn black and use that as a reference....
[03:24:54] stichnot: ooh, that would be cool
[03:25:04] tonsofpcs: you'd have to do it during capture time on the cvbs but you could do it post-capture on the high def
[03:25:19] neufeld: tonsofpcs: my VBI scanning doesn't pull out the .mpg file, just the VBI stream. I discard the video data.
[03:25:23] tonsofpcs: you could store it in the subtitle/caption file as a non-display event....
[03:25:40] tonsofpcs: right, you'd have to check the video data until the first instances for the fingerprinting
[03:25:54] neufeld: stichnot: OK, I'll look at 1000x1000 when I start poking at that code.
[03:27:01] tonsofpcs: why 1000x1000? why not 1152x864?
[03:27:55] neufeld: well, I'd never program a hard-coded 1000x1000, of course. It could be whatever the user wants, I'd just need a sane default.
[03:29:18] tonsofpcs: right, I propose that 1152x864 is a more sane default.
[03:29:36] tonsofpcs: (1440x1080 is 4:3 center in 1920x1080 16:9, 1152x864 is 80% of that....)
[03:30:49] tonsofpcs: well, 80% each H/V
[03:30:51] neufeld: well, that's convincing, there's even math!
[03:32:29] tonsofpcs: (AKA the 4:3 center-safe action-safe area of a 16:9 1920x1080 frame :)
[03:32:36] neufeld: Right
[03:32:40] tonsofpcs: err, title-safe
[03:32:43] ** tonsofpcs is tired **
[03:33:16] neufeld: Yeah, it's 23h30 here. OK, I'm really going AFK now. G'night all.
[03:33:29] tonsofpcs: g'nite
[03:33:40] ** tonsofpcs should too... got an encoder to configure in the am ;) **
[03:43:33] stichnot: tonsofpcs: The problem is that this part of the SRT specification says that each caption block can specify a bounding box for the caption text. The bounding box is supposedly specified in terms of pixel coordinates. But it's not clear what the canvas size is – video file dimensions? physical display dimensions? scaled video dimension? It would be much clearer if coordinates were given in...
[03:43:35] stichnot: ...percentages. My choice of 1000x1000 makes it look like percentages (times 10), and also isn't vastly far off from any of these dimension models.
[03:44:47] stichnot: Also, what are you supposed to do if the caption text falls outside the bounding box? Clip it? Shrink to fit? And is it supposed to be centered, left/right/top/bottom justified?
[03:45:33] stichnot: It's clear that very little thought went into this part, which I guess is related to the fact that no one actually uses it.
[03:49:21] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[03:50:25] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:51:14] tonsofpcs: stichnot: looking quickly at SRT refrence, it seems it should be relative to the file it is packaged with.
[03:51:29] tonsofpcs: if you scale the file, you should scale the SRT location data too
[04:12:17] joki (joki! has quit (Ping timeout: 248 seconds)
[04:17:42] joki (joki! has joined #mythtv
[05:33:14] Phobos (Phobos!b207f23f@gateway/web/freenode/ip. has joined #mythtv
[05:33:22] Phobos is now known as Pho128
[05:33:45] Pho128 (Pho128!b207f23f@gateway/web/freenode/ip. has left #mythtv ()
[05:39:38] stoffel (stoffel! has joined #mythtv
[05:58:48] SteveGoodey (SteveGoodey! has joined #mythtv
[06:09:57] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[06:12:44] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[06:22:53] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[06:23:11] FabriceMG (FabriceMG! has joined #mythtv
[06:31:50] stichnot: danielk22, jpabq: I'm seeing that in Live TV, if you change channels to a different multiplex on the same tuner, the RecordingInfo::cardid ends up 0, as observed by logging of SendMythSystemRecEvent(). I assume that a new RecordingInfo object is being created for the new channel but cardid is not being set and taking the default value. Any idea where to look?
[06:34:02] stichnot: (jpabq: I mentioned you because this is a continuation of the HD-PVR .srt saga that I dragged you into :) )
[07:16:52] stoffel (stoffel! has quit (Remote host closed the connection)
[08:14:02] jpabq___ (jpabq___! has joined #mythtv
[08:14:04] jpabq__ (jpabq__!~quassel@mythtv/developer/jpabq) has joined #mythtv
[08:14:25] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 246 seconds)
[08:15:21] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 268 seconds)
[08:52:20] jya: stuartm: you're there?
[08:53:35] jya: I'm creating a MythUINotificationCenter ; I want it to be created in the GUI thread; where would be a proper location to create it? In MythUIHelperPrivate::Init ?
[16:27:44] stichnot (stichnot!~stichnot@ has joined #mythtv
[16:27:44] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:27:44] stichnot (stichnot!~stichnot@ has quit (Changing host)
[16:30:07] jams: server is online again
[16:30:30] jams: no clues as to the problem. serial console was blank
[16:31:36] jams: messages just cuts off and picks up again with the reboot
[16:32:45] Steve-Goodey (Steve-Goodey! has joined #mythtv
[16:34:03] ** stuarta sighs **
[16:34:39] jams: i think it's kernel panicing..butl hard to tell
[16:34:47] jams: and or course no clue as to why
[16:36:38] stuarta: remote syslog may help us here
[16:42:40] stuarta: back later
[16:42:48] toeb (toeb! has quit (Quit: leaving)
[16:42:56] toeb (toeb! has joined #mythtv
[16:49:05] SteveGoodey (SteveGoodey! has joined #mythtv
[16:50:35] bobweaver (bobweaver!~bobweaver@ubuntu/member/bobweaver) has joined #mythtv
[17:14:05] MythLogBot (MythLogBot!~bot@mythtv/developer/beirdo) has quit (Ping timeout: 246 seconds)
[17:25:46] ElmerFudd (ElmerFudd! has quit (*.net *.split)
[17:26:14] ElmerFudd (ElmerFudd! has joined #mythtv
[17:29:07] sraue_ (sraue_! has joined #mythtv
[17:31:13] NightMonkey (NightMonkey!~NightrMon@ has joined #mythtv
[17:31:13] NightMonkey (NightMonkey!~NightrMon@ has quit (Changing host)
[17:31:13] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:35:02] sraue_ is now known as sraue
[17:35:13] sraue (sraue! has quit (Changing host)
[17:35:14] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[17:55:57] XChatMav (XChatMav! has joined #mythtv
[17:58:24] MavT (MavT! has quit (Ping timeout: 240 seconds)
[18:01:37] Steve_Goodey (Steve_Goodey! has joined #mythtv
[18:01:41] SteveGoodey (SteveGoodey! has quit (Ping timeout: 248 seconds)
[18:26:25] Moeabm09 (Moeabm09!~moeabm@ has quit ()
[18:48:15] stuartm: jams: if it is a panic, it would be worth upgrading to a newer kernel? Well whether it is or isn't a panic, it really couldn't hurt
[18:48:45] stuartm: heh, it's still on 2.6
[18:49:17] stuartm: 3.5 year old kernel
[18:49:32] stuartm: no, 4.5 year old
[18:49:54] stuartm: no, right first time, it was released Dec 09
[18:55:34] Steve_Goodey (Steve_Goodey! has quit (Quit: Konversation terminated!)
[19:02:31] SteveGoodey (SteveGoodey! has joined #mythtv
[19:07:26] peper03: stuartm, danielk22, anyone else: The DVD context class I introduced really needs to be passed along the chain (ringbuffer, AVF, player) to be of use. To get it to the player and keep it in sync, it seems that passing it in a VideoFrame would make the most sense.
[19:08:07] peper03: I could put the pointer into one of the 'priv' fields, but that seems a little risky long-term as you never know who is going to use those fields.
[19:08:58] peper03: Alternatively, I could add a new dedicated pointer variable, but that would be a DVD specific field in a 'generic' structure.
[19:09:15] peper03: Any preferences (in particular against)?
[19:09:18] peper03: Or other ideas?
[19:10:54] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[19:13:28] SteveGoodey (SteveGoodey! has joined #mythtv
[19:15:53] stuarta: stuartm: it's centos6, so it's a stable kernel, it doesn't start panicing for no reason. i put my money on slow hardware death
[19:18:26] stuarta: and that's assuming it's actually panicing, and not just hanging
[19:19:05] jams: since moving to centos6 it's done this off and on from the start. Not saying it isn't hardware just that this behaviour isn't new
[19:19:51] jams: once someone starts looking into replacments the server starts acting better for a bit
[19:20:03] stuarta: actually that's not that old a kernel
[19:20:23] stuarta: 2.6.32–358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013
[19:20:23] ** MythLogBot **
[19:20:46] stuarta: there are few changes since that, but nothing huge
[19:49:03] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[19:51:33] SteveGoodey (SteveGoodey! has joined #mythtv
[19:55:24] stichnot: peper03: (I have a meeting in 5 minutes, but...) What DVD context class are you referring to?
[19:55:49] SteveGoodey (SteveGoodey! has quit (Client Quit)
[19:57:48] peper03: stichnot: I added a context class recently to hold information about the state of DVD processing (e.g. 'are we in a still?' 'are we in a menu?') at any given moment. The ringbuffer can be some way ahead of the player and querying things like that directly means you're getting the current state of the ringbuffer as opposed to the current state of what you can see.
[19:58:35] peper03: In other words, the player gets information on what its state will be in a second or two.
[19:59:11] exoon (exoon! has joined #mythtv
[19:59:22] SteveGoodey (SteveGoodey! has joined #mythtv
[19:59:30] peper03: It could ask 'isInMenu' and get yes even though the menu data won't get through to the player for another second or two.
[20:02:36] peper03: Or 'what is the playback time?'. The player might be displaying the picture from 00:30 but the ringbuffer is already reading the data for 00:32, so we end up displaying "00:32" .
[20:02:58] peper03: Hope that isn't as clear as mud!
[20:03:38] DexterF (DexterF! has joined #mythtv
[20:03:41] DexterF: hi
[20:05:25] peper03: The context class should encapsulate that information and be passed down the chain so that each stage gets the information in sync with its current packet.
[20:10:28] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[20:13:13] SteveGoodey (SteveGoodey! has joined #mythtv
[20:20:29] Captain_Murdoch: peper03, not sure if it's off the wall or not, but could you add it as a 'private data' field to the RingBuffer and then access that field/data in the player if playing a DVD. could be a hash array of private data ptrs to future-proof. QMap<QString, void*>PrivateData
[20:22:37] Captain_Murdoch: guess that wouldn't be in line with your 'state of frame X' idea.
[20:22:44] peper03: Captain_Murdoch: The trick is keeping everything synchronized. I guess that could be done using the timecodes.
[20:23:19] peper03: At the moment, I've got it working ok between DVDRingBuffer and AVFormatDecoderDVD.
[20:24:06] peper03: The other trick is knowing when everyone who might be interested in the data has done with it. By passing it down the chain, you don't need to worry about it.
[20:25:03] peper03: Otherwise MythPlayerDVD needs to tell the Ringbuffer that it doesn't need instance 'X' any more, and so the ringbuffer needs to know about MythPlayerDVD etc.etc.
[20:26:11] Cougar (Cougar!~cougar@2a03:5880:104:10:ed2c:d960:4cca:c04e) has joined #mythtv
[20:27:53] peper03: The way I envisioned it (and I'm open to suggestions) is simply to use a reference counter. Every time one stage passes it on to the next, the counter is incremented. Every time a stage decides it's done (because the next has arrived) it decrements the counter. Eventually, it gets freed automatically.
[20:28:45] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[20:29:38] peper03: I did wonder about creating something like a PrivateData base class and adding that to VideoFrame but then I saw that VideoFrame is just C, so classes are out.
[20:29:58] Captain_Murdoch: if RingBuffer had a "QHash<QString,void*> PrivateData", then ringbuffer->PrivateData["DVDContext"] could be a ptr to a QMap<long long,DVDContext*>. let the ringbuffer just stuff items in as it encounters them and the player consumes and deletes.
[20:30:52] Captain_Murdoch: or maybe I shouldn't think too deep when I've been sick. :)
[20:31:59] peper03: :)
[20:33:29] SteveGoodey (SteveGoodey! has joined #mythtv
[20:34:39] peper03: I guess that *could* work. The context class is updated roughly twice per second, depending on how the DVD is encoded, so the decoder and player would presumably have to probe with each frame to see whether a new context instance was available.
[20:37:14] SteveGoodey (SteveGoodey! has quit (Client Quit)
[20:40:00] SteveGoodey (SteveGoodey! has joined #mythtv
[20:41:54] DexterF: should I have a designated user for myth at the database? configign mythtv-common, asks for a username used to access database
[20:42:10] DexterF: or should that be my exisitng "regular" user?
[20:49:34] peper03: DexterF: That's probably better asked in #mythtv-users
[20:49:50] DexterF: ouh, wrong tab
[20:50:17] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[20:50:49] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[20:53:36] stichnot: peper03: I realize this is inherited code, but it never made sense to me that the DVDRingBuffer would report the DVD state at the point of readahead, rather than at the point of most recently read by the player/decoder.
[20:54:12] peper03: stichnot: That's what I'm trying to change :)
[20:55:45] peper03: The problem is caused because the frames are buffered. I did a couple of tests a while back. Using OpenGL, there was a delta between ringbuffer and player of ~1400ms. With VDPAU, it was ~550ms.
[20:56:10] stichnot: The frames are buffered by whom? VideoFrames?
[20:57:12] peper03: Mainly AVFormatDecoder
[20:57:18] stichnot: ok
[20:58:30] peper03: The delta between AVF and the ringbuffer should be minimal. Basically whatever ffmpeg adds (can be a few packets, I think). The biggest difference is between AVF and Player.
[20:59:30] stichnot: Who needs to query the DVD context? Player?
[20:59:55] peper03: Player, tv_play, and AVFDVD
[21:00:04] Moeabm (Moeabm!~moeabm@ has joined #mythtv
[21:00:36] peper03: I haven't rounded up all the items that need to/could go into the context class, but there are a lot of 'get' methods in DVDRingBuffer.
[21:00:52] stichnot: ok, I'm familiar with those queries. :)
[21:01:35] stichnot: Now I see why you'd like to cache the context with the VideoFrame.
[21:01:46] Guest68228 is now known as dblain
[21:02:30] peper03: It would be nice to tidy a few things up in the player and tv_play. tv_play in particular is a bit messy. Sometimes it queries data from the player, sometimes directly from the ringbuffer. The data it gets from the player comes from the ringbuffer too.
[21:03:54] stichnot: "tv_play in particular is a bit messy" – understatement of the YEAR  :)
[21:04:28] peper03: Good. Then it's not only my opinion :)
[21:04:31] stichnot: What about keeping the context in VideoOutput?
[21:05:56] peper03: Does AVF have access to VideoOutput for storing?
[21:06:33] stichnot: Not sure, but access is probably relatively easy to arrange if necessary.
[21:07:27] peper03: I only see it in player. AVF requests a video frame from the player, which gets it from video_output and passes it back.
[21:07:40] stichnot: I'm not positive about VideoOutput, but I'm thinking that there could be a strong relationship between this context and calling one of the GetLastShownFrame() methods.
[21:08:35] peper03: That was kind of my idea (and my overview of this stuff is a bit shaky).
[21:10:02] stichnot: actually, I may have misunderstood slightly. Are you thinking that for every frame, you would capture a snapshot of the context?
[21:10:08] peper03: I intended adding/attaching the context to a VideoFrame in AvFormatDecoder::ProcessVideoFrame, and then processing it in MythPlayer::DisplayNormalFrame.
[21:10:44] peper03: No, it doesn't update that quickly. Basically once per NAV packet, so about every 12–30 frames.
[21:11:11] peper03: Every time there's a new context, it's attached to the next video frame. If there's no new context, a NULL pointer would be passed.
[21:12:02] peper03: So there could be one or two context instances underway at any given moment.
[21:12:22] stichnot: btw, are you aware of the ReferenceCounter class in libmythbase?
[21:12:40] peper03: Depends on the amount of buffering and how frequently the NAV packets come on the DVD.
[21:12:58] peper03: Yep, using it already :)
[21:13:03] stichnot: ok cool
[21:15:04] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[21:15:28] peper03: The context class is working well already between the ringbuffer and AVFormatDecoderDVD, where it's used to determine how many video frames to generate when we encounter a slideshow (single video frame with audio).
[21:15:29] stichnot: Just for context, I'll point out that the non-DVD player also has to keep track of some context with respect to what's currently displayed as opposed to what's been decoded, such as framerate and resolution changes. Assuming that stuff is implemented correctly (which is a very shaky assumption), that could potentially be leveraged.
[21:16:11] peper03: Yeah, I was just thinking that the same problem must exist for normal videos/recordings.
[21:16:36] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[21:16:51] peper03: Maybe because everything is linear there, it's not as big a problem.
[21:17:30] peper03: And there are no menus or still frames to worry about.
[21:19:31] peper03: If there's a way of doing this generically (via a base class or whatever), I'm all for it. Even if I do end up attaching the context to a VideoFrame, I've still got to work out where to do that since there's no easy spot to add it to AVFormatDecoderDVD. It's all in AVF.
[21:20:33] peper03: Adding a method to AVF like 'addPrivateData(VideoFrame& frame)' would make that easier.
[21:21:48] Tobbe5178 (Tobbe5178! has quit (Read error: Connection reset by peer)
[21:24:37] Tobbe5178 (Tobbe5178! has joined #mythtv
[21:29:50] Moeabm (Moeabm!~moeabm@ has quit (Read error: Connection reset by peer)
[21:30:31] Moeabm (Moeabm!~moeabm@ has joined #mythtv
[21:34:36] stuartm: stuarta: in theory it's stable, but in practise? I very much doubt every single bug fix gets backported any more than we backport every fix from master
[21:36:02] stuartm: stuarta: however what I meant in this case was updating to the latest version in the centos 6 repo, I'm assuming they patch the 2.6.32 kernel package periodically as fixes are made upstream
[21:38:45] stuartm: yeah, latest kernel package in the repo is 9 point releases ahead, 2.6.32–358.11.1.el6 vs 2.6.32–358.2.1.el6.x86_64
[21:40:19] stuartm: anyone object to doing a 'yum update' on the server, couldn't really hurt?
[21:51:49] stichnot: Captain_Murdoch: I was thinking that it might be a good idea to backport 4c9dc6d7eebe6853285efbe76a2f81ad80ebbc3c to 0.26-fixes, as I expect there's an fd leak every time metadata for a new recording is looked up.
[21:57:14] nephyrin (nephyrin!~neph@2620:101:8003:200:7a2b:cbff:fe9e:2e67) has joined #mythtv
[22:01:51] Captain_Murdoch: would be fine by me. If you want, go ahead, otherwise I'll try to get to it later tonight when I'm back at a computer. I'm about to head out for a while.
[22:04:12] DexterF (DexterF! has quit (Ping timeout: 260 seconds)
[22:17:25] stichnot: ok, I wouldn't be able to do it today, just thought it was something worth mentioning
[22:19:09] jwhite (jwhite! has quit (*.net *.split)
[22:22:28] exoon (exoon! has quit (Remote host closed the connection)
[22:24:34] moparisthebest (moparisthebest!~quassel@ has quit (Ping timeout: 276 seconds)
[22:29:53] moparisthebest (moparisthebest!~quassel@ has joined #mythtv
[22:34:43] moparisthebest (moparisthebest!~quassel@ has quit (Ping timeout: 264 seconds)
[22:38:58] stuartm: stichnot: you might want to look at b8b3ad1a if you're seeing memory leaks with metadata retrieval for recordings
[22:39:15] stuartm: I'm not sure why I didn't backport that one to 0.26-fixes
[22:41:24] moparisthebest (moparisthebest!~quassel@ has joined #mythtv
[22:48:49] stichnot: I never actually noticed a leak, until I exercised it with the .srt stuff, at which point it completely dwarfed anything metadata lookups might have cause
[23:02:32] jwhite (jwhite! has joined #mythtv
[23:31:53] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds)
[23:42:15] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:59:46] jya_: stuartm: are you still up?

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.