:: #mythtv

Daily chat history

Current users (86):

aloril, amessina, Anssi, anykey_, Beirdo, brfransen, CaCtus491, Captain_Murdoch, cecil, Chutt_, clever, coling, Cougar, danielk22, dblain, dekarl, ElmerFudd, f33dMB, fetzerch_, foobum, ghoti, gregL, GreyFoxx, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jst_, jwhite, kc, kenni, Kevin`, knightr, kormoc, kurre2, kwmonroe, laga, marsilainen_, MaverickTech, monkeypet, mrand, MythBuild, MythLogBot, neufeld_AFK, NightMonkey, Peitolm, Peps, petefunk, pheld, poptix, purserj, rhpot1991, rsiebert_, Seeker`, seld_, Sharky112065, skd5aner, SmallR2002, sphery, sraue, stuartm, superm1, sutula, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, Vernon_at_work_, wagnerrp, wh0dat, wolfgang1, xavierh_, XDS2010_, xris, _charly_, _wilmoo__
Friday, December 21st, 2012, 00:09 UTC
[00:09:07] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[00:11:07] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Read error: Connection reset by peer)
[00:11:32] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[00:12:18] wagnerrp: mmm.... power failures...
[00:16:02] MythBuild: build #4466 of master-linux-64bit is complete: Failure [4failed compile plugins] Build details are at . . . /builds/4466 blamelist: Daniel Thor Kristjansson < >
[00:19:52] stuartm: danielk22: I think you meant 'deprecated'
[00:22:50] stuartm: although that's not obviously the important error in that particular commit message
[00:23:11] stuartm: obviously not
[00:23:21] stuartm: :)
[00:25:26] jya: taylorr: I have time today to look into the problem… Do you have a sample that exhibit the problem? and what playback profile are you using to see it? vdpau too?
[00:25:42] MythBuild: build #200 of master-debian-wheezy-64bit is complete: Failure [4failed compile plugins] Build details are at . . . t/builds/200 blamelist: Daniel Thor Kristjansson < >
[00:27:04] taylorr: jya: I just updated master with the latest ffmpeg and it didn't help :(
[00:27:05] ** stuartm opens his umbrella **
[00:27:21] taylorr: jya: it should be in stuartm's share
[00:27:26] MythBuild: build #3298 of master-freebsd-64bit is complete: Failure [4failed compile plugins] Build details are at . . . /builds/3298 blamelist: Gary Buhrmaster < >, Daniel Thor Kristjansson < >
[00:27:45] jya: taylorr: the h264 are all quite related to the handling of change in stream… i'd love to have that feature in myth though… for HLS proper playback support, where we can have change of quality in the stream, it's important, and right now: it's broken
[00:28:02] taylorr: jya: "11159 HD-PVR sample.mpg"
[00:28:18] jya: taylorr: latest ffmpeg you mean you did a full update of ffmpeg master ?
[00:28:35] taylorr: yes, it wasn't as bad as trying to bisect :)
[00:29:03] jya: danielk22: fixing the remaining deprecated call was on my todo list for this week-end
[00:29:34] jya: taylorr: yes… with the last resync, the changes are now fairly straight forward to apply...
[00:30:05] jya: taylorr: tbh, I'm fairly convinced the problem is on our side… maybe something we modified
[00:30:20] jya: taylorr: is the problem with vdpau only ?
[00:30:35] taylorr: jya: the 11159 sample will play with software decoding but if you look at the 'playback data' osd you'll notice that the buffers are down to around 14 when they should be closer to 32
[00:31:16] taylorr: with vdpau the buffers get so low that it constantly stutters
[00:31:43] jya: which vdpau profile? any of them?
[00:31:45] taylorr: so it's not vdpau specifically but it's more harmful to vdpau since it has fewer video buffers allocated
[00:32:03] jya: so for all the questions, just trying to get as much info as possible to reproduce the issue
[00:32:11] taylorr: yes, any of them should be a problem... try it out on 0.26-fixes or later with vdpau and it should play terribly
[00:32:22] jya: and it plays fine with 0.25...
[00:32:24] taylorr: err, "should be fine"
[00:32:30] taylorr: yes... 0.25 works great
[00:32:58] MythBuild: build #65 of master-linux-64bit-clang is complete: Failure [4failed compile plugins] Build details are at . . . ng/builds/65 blamelist: Daniel Thor Kristjansson < >
[00:33:01] jya: anything I can see in the log , error etc… or do I notice it playback issue looking at it ?
[00:33:12] taylorr: definitely try it out with 0.26-fixes or newer and make sure you are seeing what I'm seeing
[00:33:30] jya: reason I'm asking is that I have a headless machine with vdpau… if I can work on it it's great and will be faster for me
[00:33:50] taylorr: with vdpau you'll most likely see a playback issue... with software you'll have to look at the "playback data" osd to see the buffers are lower than normal
[00:34:07] taylorr: actually testing with vdpau would be best
[00:34:12] jya: is it the same as with the issue with HDPVR where everything stutter using vdpau ?
[00:34:35] Mousey (Mousey! has quit (Quit: Read Error: Connection reset by beer)
[00:34:55] taylorr: yes, exactly
[00:35:04] jya: taylorr: so, to summarise, if I play that file with vdpau, i'll see errors in the log of some kind when there's a problem (0.26), but not special error with 0.25?
[00:35:14] jya: so all I have to look at is the log
[00:35:26] jya: otherwise I have to get a TV to that box, going to be annoying
[00:35:55] tonsofpcs: any suggestions for decent ts analysis tools that run on linux? or should I just suck it up and drag these files to the Tek MTS at worrk?
[00:36:36] taylorr: jya: I'm not sure if the logs will tell you but they probably should show a lot of prebuffering continuously occurring
[00:36:50] jya: taylorr: ok let's see...
[00:37:48] tonsofpcs: gigem: I'm not building it myself (yet) so I guess hacking at the cron/upstart/whatever daemon is probably an easier way. thanks :)
[00:38:10] tonsofpcs: (feature request: logging mode/level/etc. configuration file entry)
[00:42:40] MythBuild: build #487 of master-linux-64bit-icc is complete: Failure [4failed compile plugins] Build details are at . . . c/builds/487 blamelist: Daniel Thor Kristjansson < >
[00:50:32] jya: taylorr: that file doesn't even play on my mac with VLC 9nor quicktime with perian)
[00:50:49] jya: oh, VLC crash
[00:51:38] jya: hum… that's weird.. All I see is a ESPNH SportsCenter – Press SEL for enhanced
[00:52:52] jya: mplayer does the same...
[00:53:36] jya: same with ffplay, latest ffmpeg
[00:53:53] jya: how can we expect myth to play the file fine, when no other players seem to play it ?
[00:59:29] tonsofpcs: jya: what's wrong with the file?
[00:59:52] jya: I either see garbage at the beginning (blocky squares), or a static image
[01:00:04] stichnot: peper03: (if you read the logs) I discovered that mythcommflag --rebuild should be adding an entry to the seektable for frame 0, otherwise when seeking during playback or the cutlist editor, all the frame numbers in the seektable get shifted back by the first frame number in the seektable. You might want to try manually adding a {0,0,0} entry into the seektable and see if that improves things.
[01:00:13] jya: let me do a screen capture
[01:00:48] tonsofpcs: jya: I was more looking for a diagnosis than a symptom report
[01:01:29] jya: tonsofpcs: sorry, I think there's a misunderstanding here.. I'm talking about the #11159 mpeg file
[01:01:29] ** MythLogBot **
[01:02:09] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Read error: Operation timed out)
[01:02:38] jya: taylorr: that's what I', seeing: . . . 59screen.png
[01:02:50] jya: VLC usually crash toward the end of the file
[01:04:12] jya: mythtv 0.25 plays it fine
[01:04:36] jya: likely the bug is in ffmpeg if you ask me… let see if ffmpeg straight at the version in 0.25 plays
[01:06:52] tonsofpcs: does oldvlc (1.x or 0.86 or 0.84) play it?
[01:07:24] jya: haven't tried.. don't have them at hand.
[01:07:30] jya: going to try ffmpeg as of 74d6871d6244865b5863a01c3dab16a2f06a1706
[01:07:48] jya: which is the version myth 0.25 was using (sync of March, 9th 2011)
[01:11:03] jya: ffplay of last year can play this file
[01:11:30] jya: it starts with the static screen, then switch to the football game
[01:11:56] jya: well, that the bug is reproducible within ffmpeg is going to be a great help
[01:12:04] jya: i can do a git divert on ffmpeg instead
[01:24:09] skd5aner: jya: that #11159 sample is from me, let me know if you have questions
[01:24:09] ** MythLogBot **
[01:24:42] jya: skd5aner: I posted most of it earlier
[01:24:57] skd5aner: reading backlog... will catch up in a bit
[01:25:37] jya: eg ffmpeg can play it as of 74d6871, and can't in the following resync at rev d3db8988
[01:27:34] jya: 13 steps for git bisect, will be back in about 30 minutes hopefully with the culprit
[01:29:11] skd5aner: jya: I probably have 100+ files that exhibit the stuttering behavior in 0.26, but all playback fine in 0.25
[01:29:26] jya: skd5aner: probably all the same
[01:29:44] jya: what I'm saying is that this regression is very obivously in ffmpeg as just using ffmpeg I can reproduce it
[01:29:52] skd5aner: yea – just wanted to let you know it wasn't a single occurance / one off
[01:30:10] skd5aner: jya: cool – that's good news
[01:30:36] jya: submitting a bug in ffmpeg right now to start
[01:31:28] skd5aner: jya: yea, you were mentioning it was causing issues in other players... and that could be, I'm sure the likelyhood is that the hd-pvr could be producing some level of corruption after a channel change... when it might not be fully stabilized...
[01:31:41] skd5aner: jya: I also see the corruption very frequently after a comm-skip
[01:31:58] jya: it could be related to the ffmpeg-mt change
[01:32:06] skd5aner: only on the h.264 content from my hd-pvr, none of my mpeg2 stuff exhibits the behavior
[01:32:07] jya: they don't handle change of resolution well at all
[01:32:30] jya: that's the multi-threaded h264 decoder
[01:32:44] skd5aner: yea, I actually knew that ;)
[01:33:10] skd5aner: but, best to assume I don't – heh – thanks :)
[01:33:11] jya: yeah: Cannot (re-)initialize context during parallel decoding
[01:33:27] jya: i'm sure ffmpeg is going to dismiss the bug report.
[01:33:34] jya: being "documented"
[01:33:59] jya: and that's using the built-in h264 decoder, not vdpau
[01:34:01] skd5aner: The interesting thing is that all versions prior to 0.26 can handle the "glitches" just fine...
[01:35:05] jya: not quote
[01:35:06] jya: quite
[01:35:31] jya: the first 0.26 resync was with ffmpeg d3db8988 on March 31, 2012. it has the problem
[01:36:45] jya: it's not even fixed by the latest h264 commits in ffmpeg master, supposed to add handling of resolution change in h264
[01:38:03] MythBuild: build #4467 of master-linux-64bit is complete: Success [3build successful] Build details are at . . . /builds/4467
[01:39:38] skd5aner: jya: saw your screenshot – I am able to play it back ok in VLC in windows
[01:39:52] jya: which version of VLC?
[01:40:22] skd5aner: 1.1.10
[01:40:57] jya: that's why
[01:41:03] jya: that version is over 1.5 years old
[01:41:13] jya: ffmpeg master as of today segfault on your file
[01:41:39] MythBuild: build #3299 of master-freebsd-64bit is complete: Success [3build successful] Build details are at . . . /builds/3299
[01:43:33] jya:
[01:44:24] skd5aner: funny – VLC is showing it's logo with a santa hat... now, how did it do that?
[01:44:34] jya: I'm willing to bet that the problem is the new multi-threaded code
[01:44:41] jya: same here...
[01:44:58] jya: when i start it or kill it, the hat disappear
[01:45:05] jya: must have a test on the date… very neat
[01:45:17] skd5aner: yea, pretty cool – does the same in the "about" menu
[01:45:24] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 250 seconds)
[01:47:39] jya: 10 bisect to go..
[01:47:46] jya: looks like it's going to take me more than 30 minutes
[01:48:37] MythBuild: build #201 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at . . . t/builds/201
[01:50:14] skd5aner: jya: thanks in advance for looking in to it
[01:50:55] taylorr: jya: I thought you could turn MT off?
[01:51:22] jya: taylorr: turning mt off will make most non-vdpau machine unsuitable for playback though
[01:51:40] jya: maybe there's a way when using vdpau to do it… will see
[01:53:14] skd5aner: I remember specific multithreading support being added – are you bisecting ffmpeg or mythtv commits?
[01:55:52] MythBuild: build #66 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at . . . ng/builds/66
[02:02:47] skd5aner: jya: interesting... the sample crashes Windows Media Player
[02:04:12] MythBuild: build #488 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at . . . c/builds/488
[02:06:55] jya: skd5aner: you're compiling from source?
[02:07:41] skd5aner: yes
[02:07:58] skd5aner: 0.26-fixes, a few weeks old
[02:09:07] jya: quite surprising that 0.26 would play it though… the change must be in the mpegts code
[02:09:13] jya: as we're using our own
[02:09:24] jya: that's the only thing that haven't changed between 0.25 and 0.26
[02:11:24] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:16:21] jya: damn.. git bisect give me ffmpeg change 4478e9d8db65ca827f2b3ef3ef6ee806bffdba45, it's a merge
[02:37:31] taylorr: jya: that's odd... git show doesn't really show much changing for that merge
[02:37:47] jya: it's actually the change of default in the configuration
[02:37:55] jya: in libavformat/utils.c
[02:38:03] jya: i've isolated the culprit
[02:38:37] taylorr: which commit?
[02:38:55] jya: the merge I mentioned earlier
[02:39:11] taylorr: how do you see the changes to utils.c?
[02:39:13] jya: going to test on myth if it applies
[02:41:18] wagnerrp: jya: a while back, you wanted the EDID stuff put in smolt
[02:41:29] wagnerrp: is there any easy way to access that EDID block from the filesystem?
[02:41:47] taylorr: jya: nm, just diff the prev and next hash
[02:41:49] jya: wagnerrp: the decoded edid can be found in /proc/asound/XXX
[02:43:11] wagnerrp: ok, never brought that machine back up after the power failure... checking...
[02:43:15] jya: that's weird.. the options.c in 0.26 is totally different to the one in ffmpeg at that revision
[02:43:33] gigem: tonsofpcs: I don't understand your feature request. Anyway, you can change the logging options of the running backend on the fly by running "mythutil --event 'SET_VERBOSE <xyzzy>'" and "mythutil --event 'SET_LOG_LEVEL <plugh>'".
[02:43:58] jya: ah it has been moved to options_table.h
[02:44:25] wagnerrp: i'm not seeing anything in there
[02:44:43] wagnerrp: lots of files, couple folders
[02:44:48] wagnerrp: but nothing that looks like a binary EDID
[02:45:10] jya: there won't be a binary edid
[02:45:15] jya: it will be the decoded one
[02:45:30] wagnerrp: oh, this thing in card0/eld#3.0 ?
[02:45:30] jya: in /proc/asound/cardX/eld#X.Y
[02:45:34] wagnerrp: ah
[02:45:46] jya: that's right, card number, device X, subdevice Y
[02:46:03] jya: you can get it in /var/log/messages usually
[02:46:11] jya: the kernel has it in the log
[02:46:27] jya: you can access the raw ELD with an ALSA api
[02:46:35] wagnerrp: so grab the output that system is configured to use, look up the processed data for it, and dump that into smolt?
[02:46:46] jya: can probably run the alsa utils command directly
[02:46:51] jya: except that I don't remember :)
[02:47:57] jya: ah.. here it is
[02:47:59] jya: amixer -cX contents
[02:48:30] jya: X is the card number
[02:48:45] jya: you need alsa > Oct 2011
[02:49:07] wagnerrp: this is kernel 3.6.7, so whatever comes with that
[02:49:12] jya: 1.0.25 is one
[02:49:16] wagnerrp: yeah
[02:49:19] jya: it's actually an alsa thing
[02:49:27] jya: will work with earlier kernel 2.6 too
[02:49:40] wagnerrp: /proc/asound/version says 1.0.25
[02:49:43] jya: the kernel had the eld reading for quite a while, just no way to export the raw data
[02:49:50] jya: ok
[02:49:56] skd5aner: gigem: cool – I never knew you could change the logging options on an already running myth process
[02:50:28] jya: so if you're using card0 you do:
[02:50:29] jya: amixer -c0 contents, check for the kcontrol named ELD
[02:50:31] wagnerrp: also, power failed, server shut down... any chance you'll need that build jail?
[02:50:43] wagnerrp: yeah, this thing... "numid=49,iface=PCM,name='ELD',device=3"
[02:51:14] jya: if you see values=0, on the line underneath, it means the ELD is null
[02:51:29] jya: otherwise you'll see something like ; type=BYTES,access=r-------,values=95
[02:51:30] wagnerrp: values is a bunch of bytes in hex
[02:51:33] jya: 95 bytes long
[02:51:36] jya: exactly
[02:51:39] jya: that's the ELD
[02:52:08] jya: that's what contains the peripheral name, the channels it supports, the format it supports etc
[02:52:15] wagnerrp: easier to grab the processed version out of /proc than process the ELD from amixer output
[02:52:53] jya: problem is finding the right card #, device # and sub#
[02:57:27] wagnerrp: right now, mythtv is configured to use "ALSA:hdmi:CARD=PCH,DEV=0"
[02:57:37] wagnerrp: /proc/asound/PCH/ ... is easy enough
[02:57:48] wagnerrp: but it's eld#3.0, not 0.0
[02:58:16] wagnerrp: device 0 is analog output
[02:58:59] wagnerrp: aplay -l lists: card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
[02:59:08] wagnerrp: aplay -L lists: hdmi:CARD=PCH,DEV=0
[02:59:39] wagnerrp: so i'm not sure why the different device IDs, unless those are two independent values i'm confusing
[03:03:24] jya: usually the subdevice is 0
[03:03:29] jya: cause there's only 1
[03:03:40] wagnerrp: so -L is listing the subdevice, not the device
[03:03:55] wagnerrp: and 'hdmi' is the device
[03:03:58] jya: you want to use play -l
[03:04:05] jya: that's what list the hardware
[03:04:29] wagnerrp: gotcha, i was just hoping to be able to go directly off the value in the database
[03:04:33] jya: hdmi is an alias
[03:05:31] tonsofpcs: gigem: as for the feature request, some config file entry(s) to make mythbackend's logging follow parameters specified so that when troubleshooting stuff and mythbackend is closed/opened by users and/or automated software, it logs
[03:05:52] jya: skd5aner: your sample crashes my 0.26 with vdpau every time
[03:06:38] wagnerrp: jya: seems i should be able to pull the ID from the name using /proc/asound pcm
[03:07:04] skd5aner: hmmm, interesting – I don't experience crashes... and I would say 90% of my HD-PVR recordins exhibit the behavior at this point
[03:07:20] skd5aner: jya: have you ever been able to play it back without a crash?
[03:07:27] jya: wagnerrp: you'll find that there are so many devices, all of them showing something different that it's pretty difficult to make a generic rule
[03:07:27] skd5aner: (... in mythtv)
[03:07:36] jya: skd5aner: on my mac, using VDA yes
[03:07:48] wagnerrp: ok
[03:09:18] wagnerrp: i have to get up at 5am, and drive to the far side of iowa, so i'm going to bed... i'll get something put together tomorrow night
[03:22:10] jheizer_laptop: hey all
[03:22:36] jheizer_laptop: would anyone be willing/interested to try out my mobile web FE?
[03:31:04] jya: taylorr: skd5aner : reverting just the change disabling multi-threading isn't sufficient to fix the problem in 0.26… since the commit that broke ffmpeg, there's been further change that broke it too… like they've added extra test testing the change of resolution and stopping half way
[03:31:12] jya: that's why it's failing now
[03:39:44] jheizer_laptop: bah one typo in ym install guide
[03:39:51] jheizer_laptop: MY
[03:40:02] jheizer_laptop: surprise surprise right?
[03:44:36] Captain_Murdoch (Captain_Murdoch! has joined #mythtv
[03:44:37] Captain_Murdoch (Captain_Murdoch! has quit (Changing host)
[03:44:37] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[03:45:35] Sharky112065 is now known as Sharky-Sleep
[03:51:33] jya: oh well, I'm giving up for
[03:55:14] jheizer_laptop: Well I'll try asking again tomorrow morning.
[03:55:34] jheizer_laptop: Would be nice to hear some one else say it works before I send out and email to the users list
[03:57:03] jheizer_laptop: Will be here for another hour or two if anyone reads this and is interested
[04:26:10] superm1_ (superm1_!uid4318@gateway/web/ has joined #mythtv
[04:34:37] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[04:43:52] XDS2010_ (XDS2010_!uid1218@gateway/web/ has joined #mythtv
[04:48:09] fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:49:33] stichnot (stichnot! has joined #mythtv
[04:49:34] stichnot (stichnot! has quit (Changing host)
[04:49:34] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[04:51:14] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[04:53:01] MavT (MavT! has quit (Read error: Connection reset by peer)
[05:12:04] Guest23783 (Guest23783! has quit (Remote host closed the connection)
[05:30:48] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[05:40:04] jheizer_laptop (jheizer_laptop! has quit (Ping timeout: 248 seconds)
[06:38:46] rsiebert_ (rsiebert_! has joined #mythtv
[06:42:06] rsiebert (rsiebert! has quit (Ping timeout: 264 seconds)
[06:47:26] Goga777 (Goga777! has joined #mythtv
[07:02:46] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[07:06:24] FabriceMG (FabriceMG!~Thunderbi@ has quit (Client Quit)
[07:06:39] FabriceMG (FabriceMG! has joined #mythtv
[07:28:11] stoffel (stoffel! has joined #mythtv
[07:37:53] sraue_ (sraue_! has joined #mythtv
[07:38:36] sraue_ is now known as sraue
[07:38:46] sraue (sraue! has quit (Changing host)
[07:38:46] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[07:42:50] Chutt_ (Chutt_! has joined #mythtv
[07:43:08] Chutt (Chutt! has quit (Read error: Connection reset by peer)
[08:13:23] stoffel (stoffel! has quit (Remote host closed the connection)
[08:28:43] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:29:26] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[08:29:27] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[08:30:25] jya (jya! has joined #mythtv
[08:30:26] jya (jya! has quit (Changing host)
[08:30:27] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:35:09] stuarta: danielk22: not sure what you are asking about, autoconf is installed on the wheezy builder
[08:41:20] jya: skd5aner: what version of nvidia drivers are you using ?
[08:44:06] marsilainen_ (marsilainen_! has quit (*.net *.split)
[08:44:07] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (*.net *.split)
[08:46:06] Goga777 (Goga777! has quit (Remote host closed the connection)
[08:46:09] marsilainen_ (marsilainen_! has joined #mythtv
[08:46:10] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[08:46:16] FabriceMG (FabriceMG! has quit (Remote host closed the connection)
[08:46:30] FabriceMG (FabriceMG! has joined #mythtv
[09:04:26] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:a400:bd2b:b621:aa34) has joined #mythtv
[09:52:37] XDS2010 (XDS2010!uid1218@gateway/web/ has quit (Remote host closed the connection)
[09:52:37] superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (Remote host closed the connection)
[09:53:59] superm1_ is now known as superm1
[09:54:51] superm1 (superm1!uid4318@gateway/web/ has quit (Remote host closed the connection)
[09:54:52] XDS2010_ (XDS2010_!uid1218@gateway/web/ has quit (Remote host closed the connection)
[10:00:47] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:01:11] wahrhaft (wahrhaft! has joined #mythtv
[10:07:36] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:08:06] wahrhaft (wahrhaft! has joined #mythtv
[10:13:04] XDS2010_ (XDS2010_!uid1218@gateway/web/ has joined #mythtv
[10:15:32] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:15:57] wahrhaft (wahrhaft! has joined #mythtv
[10:18:05] superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv
[10:18:26] dekarl: danielk22: wrt libmythhdhomerun, I was trying to ask about the part to the right of ".so" not to the left :/ can I simply replace -$${LIBVERSION}.$${QMAKE_EXTENSION_SHLIB} with -$${MYTH_SHLIB_EXT} ?
[10:19:23] dekarl: building the *buntu/debian fails with this error as "*.so" ends up in the -dev package but "*.so*" in the libs package
[10:19:24] dekarl: dpkg-shlibdeps: error: couldn't find library needed by debian/libmyth-0.27–0/usr/lib/ (ELF format: 'elf64-x86–64'; RPATH: '').
[10:21:24] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:21:50] wahrhaft (wahrhaft! has joined #mythtv
[10:25:50] wahrhaft (wahrhaft! has quit (Client Quit)
[10:26:17] wahrhaft (wahrhaft! has joined #mythtv
[10:34:12] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:34:34] wahrhaft (wahrhaft! has joined #mythtv
[10:38:32] wahrhaft (wahrhaft! has quit (Client Quit)
[10:39:21] wahrhaft (wahrhaft! has joined #mythtv
[10:44:58] dekarl: danielk22: superm1: I'll simply change the packaging to put "*.so" into the library package together with "*.so.*". The gained simplicity outweights restricting the "*.so" symlinks to the -dev package.
[10:48:21] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:48:48] wahrhaft (wahrhaft! has joined #mythtv
[10:56:13] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[10:56:38] wahrhaft (wahrhaft! has joined #mythtv
[11:00:06] wahrhaft (wahrhaft! has quit (Client Quit)
[11:00:29] wahrhaft (wahrhaft! has joined #mythtv
[11:08:55] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[11:13:19] wahrhaft (wahrhaft! has joined #mythtv
[11:17:19] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[11:17:55] wahrhaft (wahrhaft! has joined #mythtv
[11:20:42] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[11:22:25] wahrhaft (wahrhaft! has quit (Client Quit)
[11:22:49] wahrhaft (wahrhaft! has joined #mythtv
[11:29:16] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 272 seconds)
[11:30:44] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[11:31:08] wahrhaft (wahrhaft! has joined #mythtv
[11:34:33] wahrhaft (wahrhaft! has quit (Client Quit)
[11:35:51] wahrhaft (wahrhaft! has joined #mythtv
[11:42:14] wahrhaft (wahrhaft! has quit (Read error: Operation timed out)
[11:43:43] wahrhaft (wahrhaft! has joined #mythtv
[11:47:12] wahrhaft (wahrhaft! has quit (Client Quit)
[11:47:37] wahrhaft (wahrhaft! has joined #mythtv
[11:51:13] wahrhaft (wahrhaft! has quit (Client Quit)
[11:51:31] wahrhaft (wahrhaft! has joined #mythtv
[11:54:54] dekarl1 (dekarl1! has joined #mythtv
[11:54:57] wahrhaft (wahrhaft! has quit (Client Quit)
[11:55:20] wahrhaft (wahrhaft! has joined #mythtv
[11:56:50] dekarl (dekarl! has quit (Ping timeout: 250 seconds)
[11:59:30] wahrhaft (wahrhaft! has quit (Client Quit)
[11:59:49] wahrhaft (wahrhaft! has joined #mythtv
[11:59:54] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[12:03:18] wahrhaft (wahrhaft! has quit (Client Quit)
[12:04:00] wahrhaft (wahrhaft! has joined #mythtv
[12:07:25] wahrhaft (wahrhaft! has quit (Client Quit)
[12:08:35] wahrhaft (wahrhaft! has joined #mythtv
[12:12:05] wahrhaft (wahrhaft! has quit (Client Quit)
[12:12:36] Sharky-Sleep is now known as Sharky112065
[12:16:27] wahrhaft (wahrhaft! has joined #mythtv
[12:20:27] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[12:20:59] wahrhaft (wahrhaft! has joined #mythtv
[12:24:29] wahrhaft (wahrhaft! has quit (Client Quit)
[12:24:54] wahrhaft (wahrhaft! has joined #mythtv
[12:31:21] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[12:31:51] wahrhaft (wahrhaft! has joined #mythtv
[12:56:38] danielk22: stuarta: right, can you uninstall it? Our build unfortunately runs autoconf when it is available.
[12:58:45] IReboot (IReboot! has quit (Remote host closed the connection)
[13:00:14] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:a400:bd2b:b621:aa34) has quit (Read error: Connection reset by peer)
[13:01:55] IReboot (IReboot! has joined #mythtv
[13:05:59] stuarta: why is that a problem? all my builders have it installed
[13:06:16] stuarta: i'm fairly sure there is something it's required for
[13:11:39] bas-t (bas-t! has joined #mythtv
[13:12:46] stuartm: stuarta: it spews out a bunch of warnings that clutter up the output
[13:16:14] stuarta: meh, we can always fix that
[13:16:38] stuartm: . . . nings%20(22)
[13:26:32] dekarl1: superm1: tgm4883: are you attached to having libmyth-<version>-0? As we package some files like "*.so.0" into it there are collisions when two different versions are installed anyway and now with the hdhr library ending in just .so its another collision
[13:26:39] dekarl1 is now known as dekarl
[14:13:16] stichnot: gigem: the stichnot1.mpg file you gave me seems to have a consistent framerate throughout. However, I have a stichnotcc.mpg from you from a while back that changes framerates, which is good for testing.
[14:15:38] stichnot: In video editing, is there a standard way of displaying timecodes, to distinguish {hour,minute,second,fraction_of_second} from {hour,minute,second,frame_offset_from_second_boundary}?
[14:15:44] stichnot: And are there localization variants?
[14:16:51] stichnot: I guess {hour,minute,second,frame_offset_from_second_boundary} is rarely useful since frames rarely appear at exact second boundaries
[14:19:23] dekarl: fraction of second is in 1/1000th? and offset from second boundary counts from 0 to 29?
[14:20:32] stichnot: That seems right, except that the offset range would be [0:frame_rate)
[14:21:45] stichnot: The intention here is for the cutlist editor, which I believe is the only place where timecodes are displayed with that level of precision
[14:23:28] stichnot: I think it should probably be displayed as HH:MM:SS.mmm (which may be localized to e.g. HH:MM:SS,mmm)
[14:23:40] stichnot: where mmm=milliseconds
[14:23:43] dekarl: aye
[14:27:28] dekarl: I can't remember a difference between frame numer / millisecond display and google doesn't lead to any insight either. So I'd say the difference is that the ms is 3 digits and the frame number 2 digits (with or without leading zero).
[14:28:17] dekarl: but that obsiously breaks with >100fps
[14:28:32] dekarl: s/obsiously/obviously/
[14:30:19] stichnot: True. So I think it makes the most sense to show milliseconds. The actual frame number (relative to the beginning of the recording/video) is also displayable in the theme, so the person editing can keep track.
[14:34:21] dekarl: hmm, I've not seen the millisecond show for video frames, yet. But I don't really like showing "hh:mm:ss.15/25" or similar either
[14:36:34] dekarl: but millisecond + absolute frame number sounds like a good compromise.
[14:38:24] dekarl: What I sometimes miss is timecode relative to start of programme (without preroll/start-early) and absolute time (basically PTS). Not when editing, but when watching. The use case is finding out how much of start-early was actually used without doing maths :)
[14:38:53] dekarl: hmm, I think its actually DTS, I never get these right
[14:43:14] stichnot: That's an interesting idea. Could probably be made available as a theme string.
[14:53:31] joki (joki! has quit (Ping timeout: 244 seconds)
[14:53:34] dekarl: another thought was to start playback at announced program start (I start early 10 minutes but usualy get away with 8)
[14:53:47] dekarl: unless there is a cutlist
[14:54:08] danielk22: stichnot: The standard way to show timecodes is HH:MM:SS.ff, where ff is a 'frame' from 0–29, i.e. if the material is 60fps the counter advances on every other frame, and with 29.97 fps you skip the 0th frame at specific intervals.
[14:54:16] joki (joki! has joined #mythtv
[14:54:47] danielk22: The frame skip algorithm is 'Drop frame numbers 00:00 and 00:01 at the start of every minute except the tenth.'
[14:56:13] danielk22: This is the first relevant link from googling 'video timecode':
[15:12:39] Jordack (Jordack! has joined #mythtv
[15:14:13] FabriceMG (FabriceMG! has quit (Quit: FabriceMG)
[15:24:02] stichnot: danielk22: what does it say about varying frame rates? :)
[15:26:14] danielk22: I don't think that was considered in the design. I think for 30->60, and 25->50 fps transitions it's pretty clear what to do, but how to handle 30->24 or 25->60 fps is not so clear...
[15:33:33] stichnot: So, this is good information, but I'm going to give it low priority. :)
[15:45:06] gigem: stichnot: I don't specifically remember the stichnotcc.mpg sample, but I suspect it is fairly short and shows 30fps commercials in a normally 60fps stream. Anyway, either is prbably good for testings, but if you'd like bigger or other samples, just let me know. FYI, my local NBC affiliate used to use variable keyframe rates. If they still do, that would probably make for a good sample.
[15:47:21] stichnot: gigem: stichnotcc has varying keyframe distances, usually 15 but sometimes 12 or 18, so it's a good test of that as well.
[15:47:59] stichnot: and for further testing I can manually change the durations that I'm precomputing in the markup table
[15:48:12] gigem: Okay.
[15:48:23] stichnot: the harder part will be to test changes to the recorder, and your source should be useful there
[15:49:52] zombor (zombor!~zombor__@ has joined #mythtv
[15:49:53] zombor (zombor!~zombor__@ has quit (Changing host)
[15:49:53] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[15:50:16] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[15:50:40] wahrhaft (wahrhaft! has joined #mythtv
[15:53:04] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[16:04:39] jheizer_laptop (jheizer_laptop! has joined #mythtv
[16:12:33] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[16:13:43] bsilvereagle (bsilvereagle! has left #mythtv ("WeeChat 0.3.2")
[16:21:20] natanojl (natanojl! has joined #mythtv
[16:22:24] peper03 (peper03! has joined #mythtv
[16:26:13] peper03: stichnot: Regarding your suggestion about the seektable after mythcommflag – I can't try it at the moment but I'm not sure it would solve the problem. The second set of logs I mentioned had frame 18 after mythcommflag at the same offset as frame 36 before. The offset for (original) frame 18 doesn't exist at all. The cutlist editor might show me the correct frame number if I add 0,0,0 but it will still be at a different physical
[16:26:15] peper03: offset in the file, won't it?
[16:27:35] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[16:28:01] wahrhaft (wahrhaft! has joined #mythtv
[16:31:38] stichnot (stichnot!~stichnot@ has joined #mythtv
[16:31:39] stichnot (stichnot!~stichnot@ has quit (Changing host)
[16:31:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:33:14] jheizer_laptop (jheizer_laptop! has quit (Ping timeout: 252 seconds)
[16:34:30] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[16:36:14] wahrhaft (wahrhaft! has joined #mythtv
[16:36:20] ghoti (ghoti!~paul@ has joined #mythtv
[16:40:02] stichnot: peper03: This is interesting. I'm looking for possible explanations.
[16:41:14] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[16:41:38] wahrhaft (wahrhaft! has joined #mythtv
[16:42:08] peper03: stichnot: I have absolutely no idea of the any of the code but it looks as if mythcommflag doesn't find a keyframe until frame 18 (according to the original table). That's its frame 0. Possible?
[16:42:48] peper03: Unfortunately, it doesn't write frame 0 to the table, though.
[16:43:28] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[16:45:02] stichnot: peper03: One problem with mythcommflag is that it doesn't output keyframe info for frame 0. When the player loads the seektable from the DB (or from the recorder for playback of an in-progress recording), it subtracts the first keyframe number from all frame numbers, so that the keyframe table essentially becomes zero-based.
[16:45:04] wahrhaft (wahrhaft! has quit (Client Quit)
[16:45:06] sl1ce (sl1ce! has quit (Ping timeout: 264 seconds)
[16:45:27] wahrhaft (wahrhaft! has joined #mythtv
[16:45:36] stichnot: So if you manually insert keyframe 0 into the DB, at least the seeking during playback and editing should be corrected.
[16:46:14] stichnot: Except for a problem I've found where (I think) ffmpeg fails to seek to frames at the very beginning before the first keyframe.
[16:47:11] stichnot: Now, independent of the frame-0 keyframe, it still looks like mythcommflag and the recorder disagree by one keyframe.
[16:47:15] stichnot: (in your example)
[16:48:02] stichnot: too bad the recordings have a fixed keyframe distance, otherwise we could get more info on the discrepancy
[16:48:38] stichnot: peper03: What recorder was used for these samples?
[16:51:53] stichnot: and was the recording transcoded before you collected the seektable data?
[16:56:38] stichnot: (back in 30 minutes)
[16:58:04] peper03: stichnot: They were recorded from DVB-S. They weren't transcoded. Recording was sync'd to the SEQ header (or whatever that setting is called).
[16:59:52] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[17:00:18] peper03: The first logs I posted seem to have different keyframe distances – and
[17:00:28] wahrhaft (wahrhaft! has joined #mythtv
[17:01:10] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds)
[17:03:52] peper03: stichnot: I set the default recording profile to 'TV Only' in case that makes any difference. It doesn't actually seem to do anything though. My recordings still have all the data streams regardless of this setting.
[17:05:12] bas-t (bas-t! has quit (Quit: Quit)
[17:09:06] ghoti (ghoti!~paul@ has quit (Quit: leaving)
[17:09:23] ghoti (ghoti!~paul@ has joined #mythtv
[17:11:06] stichnot (stichnot!stichnot@nat/google/x-abqsrfqbrptejqil) has joined #mythtv
[17:11:06] stichnot (stichnot!stichnot@nat/google/x-abqsrfqbrptejqil) has quit (Changing host)
[17:11:07] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:13:23] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[17:13:48] wahrhaft (wahrhaft! has joined #mythtv
[17:17:16] wahrhaft (wahrhaft! has quit (Client Quit)
[17:17:46] wahrhaft (wahrhaft! has joined #mythtv
[17:21:12] wahrhaft (wahrhaft! has quit (Client Quit)
[17:21:29] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[17:21:57] xris: someone here refer me to Beirdo ? it was sent to my address
[17:22:08] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[17:23:32] wahrhaft (wahrhaft! has joined #mythtv
[17:25:56] ** Captain_Murdoch points out that it's not mythcommflag finding keyframes, it's the player code. mythcommflag --rebuild just uses the player code to rebuild the seek table. so the issue is the player doesn't detect the same as the recorder, that could happen without a seektable whether you run mythcommflag --rebuild or not since if you watch the recording, the player will build the wrong seektable in memory while you're watching the prog **
[17:28:53] xris: Captain_Murdoch: btw did you ever add the "multiple video files" code as part of your HLS code?
[17:29:02] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[17:29:38] wahrhaft (wahrhaft! has joined #mythtv
[17:29:51] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Quit: see you later)
[17:30:03] Captain_Murdoch: no, that's part of the schema design that I originally worked on but sphery has been taking over. right now it's just a page on the wiki detailing the new schema layout, there hasn't been any coding yet.
[17:30:53] Captain_Murdoch: I got diverted on HLS on-demand encoding so you can skip around during playback into sections that haven't been transcoded yet. the segments and playlist are generated on-demand rather than as a normal transcoding job with the playlist being updated as transcoding progresses.
[17:31:29] Captain_Murdoch: s/normal/semi-normal/
[17:32:27] jheizer: Are there any notes on what webservice changes may happen with that?
[17:32:37] Captain_Murdoch: still trying to think how or if these HLS segments should be handled as part of that new schema as well. with the on-demand encoding, you could have groups of non-consecutive files and currently theyre's no tracking in the DB at all for these.
[17:32:40] jheizer: Just curious so I can plan for them.
[17:33:05] Captain_Murdoch: jheizer, no changes at all, you won't even need the current add/stop/etc. service calls.
[17:33:31] jheizer: Yeah I remember you showed me an example link before
[17:33:44] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[17:33:59] jheizer: forgot about the start call not being needed
[17:35:19] Captain_Murdoch: just fetch http://backendip:port/HLS/somefile.mpg.hlsd.m3u8 or http://backendip:port/HLS/somefile.mpg.hlsd.6 . . . 00000001s.ts
[17:35:27] jheizer: on topic slightly, were there known issues with stopping/deleteing streams on .25.3?
[17:35:56] stichnot: peper03: I just took a look at two recent recordings on my system, one is mpeg2 from an HDHR and the other is h.264 from an HDPVR. For mpeg2, the keyframe marks were the same before and after mythcommflag (except for the lack of keyframe=0 after mythcommflag), and the offsets were very close – 188 bytes apart in each case.
[17:36:06] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[17:36:09] stichnot: For h.264, results are weird.
[17:36:31] jheizer: I tried to add that in last night and don't seem to be deleting and I was not able to delete them using the backend :6544 page ether
[17:37:06] Captain_Murdoch: trying to make it simpler. no reproduceable known issues with stopping/deleting, but the it's not that robust, almost fire and forget except that the transcoder checks every so often to see if it should stop.
[17:37:25] stichnot: The recorder finds a keyframe every 128 frames (the first keyframes are at frame 0 and frame 125, then interval 128 thereafter).
[17:37:58] jheizer: Ok, not sure what my problem has been then. I have manually deleted and purged the db table a few times as a result.
[17:38:08] stichnot: After mythcommflag, "keyframes" are found at every multiple of 32 frames.
[17:38:32] jheizer: wife hit a few bugs with me "preview" release version last night
[17:38:40] jheizer: hope to fix it this evening and release over the weekend
[17:39:10] stichnot: I think this has been discussed before – the mythcommflag player records a keyframe when it is really something finer-grain
[17:39:34] stichnot: or more accurately, the avfd code
[17:39:34] Captain_Murdoch: current method was a bit of a hack to get the feature out there, it was a definite work in progress, that's why I'm ditching most of how that's done in the new code. still using underlying classes for encoding, playlist generation, etc., but not using the old/pre-existing transcoding loop inside mythtranscode at all now.
[17:39:46] wahrhaft (wahrhaft! has joined #mythtv
[17:40:01] jheizer: Have to say it works damn good though
[17:40:10] jheizer: wife uses it 2–3 times a night now w/o issue
[17:40:46] stichnot: the especially weird thing is that if you match up file offsets before and after mythcommflag --rebuild, the frame numbers differ by 29 frames.
[17:40:47] jheizer: And any issue she does hit was my problem. aka new settings screen last night passing a video height of 240 vs 720.
[17:41:09] stichnot: peper03: what is the format of your recording?
[17:41:49] jheizer: Is the plan on your new version to have the transcoded streams all delete once the recording itself is deleted?
[17:42:34] Captain_Murdoch: newer method is even smoother. I modified the hls test .qsp page to give me .m3u8 links for the recordings/videos and I can just tap one and things get generated on the fly. it's a beauty to see in action. just need to work on some encoding issues and then deal with a lot of other stuff I left on the back burner like cleaning up these files somehow since there's no API necessary.
[17:42:56] Captain_Murdoch: haveven't given cleanup much though, but yeah, I'd say they'd be deleted when/if the recording was deleted.
[17:43:31] jheizer: One thing I was thinking about adding was a "clean up" job
[17:43:43] jheizer: remove any streams for recordings after xx days
[17:43:46] wahrhaft (wahrhaft! has quit (Quit: No Ping reply in 180 seconds.)
[17:43:59] Captain_Murdoch: thinking of creating just one or two settings to say "allow X GB of HLS files" or "keep HLS files for X minutes/hours/days". since anything deleted can get regenerated on the fly again if the recording still exists.
[17:44:14] Captain_Murdoch: need to think it through, haven't given it much thought yet.
[17:44:16] jheizer: yeah sounds good to me
[17:44:34] wahrhaft (wahrhaft! has joined #mythtv
[17:44:38] jheizer: Wife likes to keep some recordings for ages and is not a fan of moving them into videos
[17:45:29] Captain_Murdoch: eventually would probably convert the existing API stuff to use the new code, so calling an Add would pre-generate the playlist(s) and segments using the new code.
[17:46:42] Captain_Murdoch: don't want 2 ways to do the same thing. that may mean that the 'List' goes away or is just replaced by something that lists available media or found playlists, I'll tackle that when I get to it. :)
[17:47:13] _wilmoore_ (_wilmoore_! has joined #mythtv
[17:47:18] jheizer: Got ya.
[17:47:29] peper03: stichnot: In this case, MPEG2. I'm almost certain that I get the same on h.264 recordings though.
[17:48:03] jheizer: From a consumer perspective either way is easy enough to use. And supporting the .25/.26 calls would be no biggie.
[17:48:34] wahrhaft (wahrhaft! has quit (Client Quit)
[17:49:02] wahrhaft (wahrhaft! has joined #mythtv
[17:51:00] jheizer: Few screenshots if you are interested –
[17:52:27] wahrhaft (wahrhaft! has quit (Client Quit)
[17:56:33] peper03: stichnot: Just occurred to me – the samples are from 0.26-fixes on my production box. Maybe the ffmpeg merge in master has fixed something?
[18:04:44] Captain_Murdoch: jheizer, nice.
[18:09:41] stichnot: peper03: good point, that definitely complicates things as I don't currently have a 0.26 environment
[18:09:49] jpabq: stichnot: the HD-PVR produces 'I' frames that do not actually represent a "complete" frame. If you tell ffmpeg to start decoding at that location, you get pixelization. To get a "completel" from, you have to wait for an IDR (If my memory serves).
[18:10:12] jpabq: 'I' frames are every 32, but IDR is only every 128.
[18:10:42] SteveGoodey (SteveGoodey! has joined #mythtv
[18:11:19] jpabq: The thing is, when the HD-PVR first came out, you COULD tell ffmpeg to start decoding on any of those 'I' frames, and it worked fine. Then something changed in ffmpeg (or maybe the firmware of the HD-PVR?) that broke that...
[18:13:38] stichnot: jpabq: the seektable management is done in AvFormatDecoder::HandleGopStart(), which is called from AvFormatDecoder::MpegPreProcessPkt() and AvFormatDecoder::H264PreProcessPkt() (as well as the fallback AvFormatDecoder::PreProcessVideoPacket()). Any idea how to detect a "complete" I-frame within AvFormatDecoder::H264PreProcessPkt()?
[18:15:43] jpabq: stichnot: when recording, we use the logic in libs/libmythtv/mpeg/H264Parser.cpp
[18:16:36] stichnot: thanks, checking that now
[18:18:07] jpabq: H264Parser::addBytes scans for an IDR, and returns the offset.
[18:18:38] _wilmoore_ (_wilmoore_! has quit (Remote host closed the connection)
[18:18:53] jpabq: stichnot: it has been a long time since I looked at that stuff, but I can dive back into it a bit, if you need me to.
[18:32:11] cal (cal!~cal@ has joined #mythtv
[18:32:22] cal is now known as Guest99384
[18:36:09] Guest99384 is now known as wh0dat
[18:41:37] _wilmoore_ (_wilmoore_! has joined #mythtv
[18:46:51] _wilm____ (_wilm____! has joined #mythtv
[18:49:07] _wilmoore_ (_wilmoore_! has quit (Ping timeout: 244 seconds)
[18:51:09] stoffel (stoffel! has joined #mythtv
[18:58:18] peper03: stichnot: Yeah, I don't have a functional master environment. I probably can't run mythcommflag --rebuild on a specific file and output the seek table somewhere other than the DB. I ought to get a master environment set up but so far I haven't had the need so it's just been on my to-do list.
[18:58:21] stichnot: jpabq: after taking a quick look, I have no idea how to map the H264Parser functionality onto AVFormatDecoder, so I'm going to put that to the side for now.
[19:01:02] stichnot: trying to figure out how #10962 could possibly happen...
[19:01:02] ** MythLogBot **
[20:17:13] stoffel (stoffel! has quit (Remote host closed the connection)
[20:17:36] zombor_ (zombor_!~zombor__@ has joined #mythtv
[20:17:36] zombor_ (zombor_!~zombor__@ has quit (Changing host)
[20:17:36] zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv
[20:25:07] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[20:25:37] Jordack (Jordack! has quit ()
[20:34:28] zombor_ (zombor_!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:42:17] peper03: stichnot: Ok, got master up and running. Still getting the same result though: and
[20:54:21] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Remote host closed the connection)
[20:54:44] stichnot (stichnot!stichnot@nat/google/x-tiiupnotseydzjad) has joined #mythtv
[20:54:44] stichnot (stichnot!stichnot@nat/google/x-tiiupnotseydzjad) has quit (Changing host)
[20:54:45] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:01:03] stichnot: peper03: I'd like to get the first ~4MB of that sample. You could probably just email it.
[21:01:40] stichnot: also, what recording hardware/source do these recordings come from?
[21:11:20] _wilm____ (_wilm____! has quit (Ping timeout: 260 seconds)
[21:11:56] _wilmoor_ (_wilmoor_! has joined #mythtv
[21:19:29] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:38:54] jheizer_laptop (jheizer_laptop! has joined #mythtv
[21:47:55] peper03: stichnot: Mail is on its way. The recording is from a TBS6981 dual input DVB-S(2) card.
[21:51:09] peper03: stichnot: Sorry, that one is from a Pinnacle PCTV 400e DVB-S receiver. Not that I would expect that to make much difference.
[21:55:37] jheizer: Weird item of the day: iPad will not register a click on an elemnt that is floating above a <video>. Click passes through to the video frame.
[21:55:41] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[22:00:39] peper03 (peper03! has quit (Quit: Konversation terminated!)
[22:02:05] jheizer_laptop (jheizer_laptop! has quit (Ping timeout: 256 seconds)
[22:49:41] _wilmoore_ (_wilmoore_! has joined #mythtv
[22:51:16] _wilmoor_ (_wilmoor_! has quit (Ping timeout: 245 seconds)
[22:54:05] _wilmoo__ (_wilmoo__! has joined #mythtv
[22:54:47] _wilmoore_ (_wilmoore_! has quit (Read error: Connection reset by peer)
[22:55:53] stichnot: peper03: got it, thanks. I see the same result from mythcommflag (except that my patched version add a frame=0 entry).
[22:56:57] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[23:10:41] jheizer_laptop (jheizer_laptop! has joined #mythtv
[23:14:36] stichnot: danielk22: Is it possible that the DVB recorder would ignore initial frames when writing to disk but count them anyway for the purpose of the seektable? Or write them to disk but in a way that afvd would skip over?
[23:30:40] MaverickTech (MaverickTech! has joined #mythtv
[23:46:24] natanojl (natanojl! has quit (Ping timeout: 264 seconds)
[23:49:28] zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv
[23:51:22] jheizer_laptop (jheizer_laptop! has quit (Ping timeout: 244 seconds)

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