| Monday, February 11th, 2013, 00:15 UTC | ||
| [00:15:05] | MythBuild: | build #1702 of cppcheck-master is complete: Failure [4failed git] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . /builds/1702 blamelist: Stuart Auchterlonie <stuarta@squashedfrog.net > |
| [01:07:12] | jams (jams!~jams@cpe-24-92-95-170.wi.res.rr.com) has quit (Remote host closed the connection) | |
| [01:18:58] | jams (jams!~jams@cpe-24-92-95-170.wi.res.rr.com) has joined #mythtv | |
| [01:19:40] | stichnot: | tonsofpcs: thanks for the tip, I'll look into that. It would be nice if all our hardcoded 1088s could be avoided by proper metadata handling. Hopefully the metadata covers resolution changes within the same recording. |
| [01:20:01] | tonsofpcs: | resolution changes within the same recording? what? |
| [01:21:01] | stichnot: | Some ATSC stations switch between 1080i and 720p, e.g. at commercial breaks. |
| [01:21:30] | stichnot: | And I think the HD-PVR is supposed to handle this if the STB passes through the original resolution. |
| [01:21:59] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has quit (Ping timeout: 256 seconds) | |
| [01:23:19] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [01:23:23] | stichnot: | The 1080i/720p switching has caused seek/duration/position problems in past code due to assumption of a fixed frame rate. |
| [01:35:56] | tonsofpcs: | frame rate can be variable per-frame even... |
| [01:36:32] | tonsofpcs: | no one here switches modes though. The only station that once did stopped doing so in about 2006... and that was a swap between 4SDs and 1HD+1SD between day and night. |
| [01:37:15] | tonsofpcs: | err, maybe it was 5SDs... I'm not quite sure. I still have all the encoders ;) |
| [01:48:11] | danielk22: | tonsofpcs: It happens more with cable tv. Ads are spliced in at 720p.. not only a different framerate but the pts/dts values reset completely too with one gigem's provider. |
| [01:49:50] | neufeld_AFK is now known as neufeld | |
| [01:49:51] | neufeld: | jpabq: I mentioned earlier that the patch for #11328 didn't apply cleanly against 0.25.2. I took a few minutes to try to resolve the rejected chunks, but it still wouldn't compile because of other changes. Missing declarations at compile time are UpdateFramesWritten(), _total_duration, durationMap, and durationMapDelta. |
| [01:49:51] | ** MythLogBot http://code.mythtv.org/trac/ticket/11328 ** | |
| [01:51:36] | neufeld is now known as neufeld_AFK | |
| [01:57:31] | joki (joki!~joki@p548644D8.dip.t-dialin.net) has quit (Ping timeout: 245 seconds) | |
| [01:58:12] | joki (joki!~joki@p548644F0.dip.t-dialin.net) has joined #mythtv | |
| [02:00:36] | tonsofpcs: | gigem: it gave me the popup again... it was for the channel I was on but I did hear a glitch so I think it did 'retune' |
| [02:00:41] | tonsofpcs: | gonna grab logs now |
| [02:00:59] | tonsofpcs: | danielk22: they're doing it wrong. curse them. |
| [02:03:00] | tonsofpcs: | gigem: guess at steps to repeat: while watching livetv, go back a bit then jump ahead to get back near live. |
| [02:05:06] | tonsofpcs: | says it moved it from card1 to card2 to avoid conflicts at 20:59:41.489. Card2 is the same physical tuner as card1, second encoder. |
| [02:19:04] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has joined #mythtv | |
| [02:30:00] | tonsofpcs: | and it is asking again... |
| [02:30:09] | tonsofpcs: | no interruption though |
| [02:30:13] | jhall_: | I am thinking of using NetStream in the recorders/iptvstreamhandler.cpp |
| [02:30:18] | jhall_: | for my http streams |
| [02:30:46] | jhall_: | I am assuming that NetStream::Safe_Read() will read data from the stream |
| [02:31:08] | tonsofpcs: | oh, no, it did glitch, just about 40s later. Interesting. |
| [02:31:09] | jhall_: | and that I could use UDPPacketBuffer just like the udp:// streams do |
| [02:31:33] | jhall_: | Is that what this code was designed for? |
| [02:31:38] | tonsofpcs: | (and the livetv 'scrollback' reset at that point) |
| [02:32:19] | jhall_: | does UDPPacketBuffer expect udp headers as well as the ts payload, or can I jsut stuff ts packets in there and call it a UDPPacketBuffer? |
| [02:32:34] | jhall_: | I could use the existing write handler helper |
| [02:32:52] | jhall_: | and write an http read helper that reads from NetStream |
| [02:33:22] | jhall_: | this is for allowing iptv streams to come from http urls as well as udp urls. |
| [02:33:59] | jhall_: | but given it is my first mythtv code, I'm just hoping I understand the src correctly |
| [02:36:28] | tonsofpcs: | ok, it seems to have been exactly 30s in... I see it adding itself as a client a lot... decided to move at 21:29:41.171... looks like recording started at 21:30:00.746573... weird.(and recording is still on 2) |
| [02:40:07] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has joined #mythtv | |
| [02:40:15] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has left #mythtv () | |
| [03:17:47] | peper03 (peper03!~richard@port-92-203-107-96.dynamic.qsc.de) has quit (Ping timeout: 255 seconds) | |
| [03:19:18] | peper03 (peper03!~richard@port-92-203-89-195.dynamic.qsc.de) has joined #mythtv | |
| [03:28:53] | gigem: | tonsofpcs: Send logs and I'll have a look tomorrow. |
| [04:06:39] | kc (kc!~Casper@pool-108-36-208-246.phlapa.fios.verizon.net) has joined #mythtv | |
| [04:06:40] | kc (kc!~Casper@pool-108-36-208-246.phlapa.fios.verizon.net) has quit (Changing host) | |
| [04:06:40] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [04:09:29] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has joined #mythtv | |
| [04:44:49] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [04:45:56] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:20:35] | stichnot: | neufeld_AFK: for 0.25 and the #11328 patch, you can remove anything to do with durationMap and durationMapDelta, and replace UpdateFramesWritten() with _frames_written_count++ . |
| [05:20:35] | ** MythLogBot http://code.mythtv.org/trac/ticket/11328 ** | |
| [05:58:21] | Goga777 (Goga777!~Goga777@128-71-57-165.broadband.corbina.ru) has quit (Quit: Leaving) | |
| [06:35:17] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [06:57:19] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [07:01:25] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:08:27] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [07:22:08] | rsiebert (rsiebert!~quassel@g224248009.adsl.alicedsl.de) has joined #mythtv | |
| [07:23:43] | somethinginteres (somethinginteres!~something@cpe-198.144.156.144.ca.yorkinet.com) has joined #mythtv | |
| [07:25:08] | rsiebert_ (rsiebert_!~quassel@g229055229.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [07:29:53] | somethinginteres (somethinginteres!~something@cpe-198.144.156.144.ca.yorkinet.com) has left #mythtv ("Leaving") | |
| [07:44:31] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat) | |
| [07:45:34] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Read error: Operation timed out) | |
| [08:15:20] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [08:36:13] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:c937:220b:ef1b:d49f) has joined #mythtv | |
| [08:44:51] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds) | |
| [09:01:09] | dekarl (dekarl!~dekarl@p4FCEED23.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [09:02:37] | dekarl (dekarl!~dekarl@p4FCEFADF.dip.t-dialin.net) has joined #mythtv | |
| [09:22:09] | stuartm: | We should link to this from trac – http://xkcd.com/1172/ – It's brilliant, and sadly very accurate |
| [09:23:04] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer) | |
| [09:23:20] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [10:13:27] | Merlin83b: | As xkcd often is :) |
| [10:32:18] | MythBuild: | build #1703 of cppcheck-master is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . /builds/1703 |
| [10:46:25] | Merlin83b2 (Merlin83b2!~Daniel@2a00:1ee0:3:1337:c937:220b:ef1b:d49f) has joined #mythtv | |
| [10:46:38] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:c937:220b:ef1b:d49f) has quit (Read error: Connection reset by peer) | |
| [10:49:21] | anykey_ (anykey_!~anykey@84-73-161-59.dclient.hispeed.ch) has quit (Quit: leaving) | |
| [10:49:42] | henkpoley (henkpoley!~henkpoley@2001:980:1241:1:2012:bc0a:538f:bb76) has joined #mythtv | |
| [10:50:51] | anykey_ (anykey_!~anykey@84-73-161-59.dclient.hispeed.ch) has joined #mythtv | |
| [11:12:28] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [11:42:51] | henkpoley (henkpoley!~henkpoley@2001:980:1241:1:2012:bc0a:538f:bb76) has quit (Quit: henkpoley) | |
| [13:48:21] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [13:49:07] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Client Quit) | |
| [14:37:09] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (Ping timeout: 276 seconds) | |
| [14:46:34] | kwmonroe` is now known as kwmonroe | |
| [14:49:11] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [14:50:28] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (Ping timeout: 248 seconds) | |
| [14:50:32] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has joined #mythtv | |
| [14:50:32] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv | |
| [14:50:32] | Captain_Murdoch (Captain_Murdoch!~cpinkham@c-67-183-28-151.hsd1.wa.comcast.net) has quit (Changing host) | |
| [14:56:53] | Sharky112065 is now known as Sharky-Sleep | |
| [14:59:42] | Seeker`: | Any suggestions why there is a segfault in Abort() in NetStream.cpp when cloasing a RAOP connection? |
| [15:10:36] | Seeker`: | stuartm: jya: There is a segfault being caused somewhere in the interaction between netstream and raop stuff when closing a connection. Backtrace is here: http://paste.ubuntu.com/1628270/ I'll create a bug later |
| [15:11:39] | stuartm: | Seeker`: ah, latest master? I think jya may have already fixed that |
| [15:11:47] | stuartm: | there was a namespace collision |
| [15:49:04] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [15:51:59] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [16:15:30] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [16:19:15] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [16:36:06] | stichnot (stichnot!~stichnot@67.218.104.4) has joined #mythtv | |
| [16:36:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:36:06] | stichnot (stichnot!~stichnot@67.218.104.4) has quit (Changing host) | |
| [16:39:25] | Seeker`: | stuartm: ah, ok. Not updated in a week or so |
| [16:40:17] | Seeker`: | stuartm: any idea when it was comitted? |
| [16:43:04] | stichnot: | stuartm: #11382 and #11402 both involve live TV segfaulting somewhere within OSD/MythUI code. Do you think this is an issue of a non-UI thread doing MythUI work it shouldn't be? |
| [16:43:04] | ** MythLogBot http://code.mythtv.org/trac/ticket/11382 ** | |
| [16:43:04] | ** MythLogBot http://code.mythtv.org/trac/ticket/11402 ** | |
| [16:44:15] | stuartm: | stichnot: that's certainly the most likely cause |
| [16:51:13] | stichnot: | I've also been seeing the occasional segfault when playback ends, which could be the same, but the core file doesn't give me a usable stack trace. |
| [16:53:14] | Seeker`: | stuartm: hmm, hasn't been an update to mythraopconnection.cpp in 2 months |
| [16:53:42] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [17:00:15] | jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has joined #mythtv | |
| [17:07:35] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [17:11:50] | stichnot (stichnot!~stichnot@216.239.45.73) has joined #mythtv | |
| [17:11:51] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:11:51] | stichnot (stichnot!~stichnot@216.239.45.73) has quit (Changing host) | |
| [17:59:21] | Merlin83b2 (Merlin83b2!~Daniel@2a00:1ee0:3:1337:c937:220b:ef1b:d49f) has quit (Read error: Connection reset by peer) | |
| [18:26:52] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat) | |
| [18:29:02] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [18:36:12] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [18:52:48] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [19:11:53] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [19:15:03] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [19:23:54] | jpabq: | neufeld_AFK: taylorr, stichnot: I just attached v4 of the keyframe patch. I also did one for fixes/0.25 but I am not in a position to test that one. |
| [19:29:07] | stichnot: | jpabq: what should I look for compared to v3? |
| [19:29:53] | jpabq: | This version makes sure each back-to-back recording starts with a PAT/PMT. Otherwise, no changes. |
| [19:29:59] | taylorr: | jpabq: I don't mind testing on 0.25-fixes but do you think it's safe? |
| [19:31:16] | jpabq: | taylorr: I believe so. I compared dtvrecorder.cpp from 0.26 and 0.25 to make sure I applied the changes correctly, and did not spot any problems. However, since I didn't test it, ymmv. |
| [19:31:39] | taylorr: | jpabq: I'll take it for a spin.. thanks! |
| [19:32:25] | taylorr: | jpabq: I'm curious, why are some keyframes P type and some I type? |
| [19:32:27] | jpabq: | stichnot: I still find it interesting that the version of ffmpeg you tried detects 128 frames between the first and second keyframe in the file. I wonder how our parser is missing those three frames, and why it doesn't miss them after the second keyframe. |
| [19:35:56] | taylorr: | jpabq: does the 0.25 patch have extra code... I see changes to iptvrecorder.h? |
| [19:36:05] | jpabq: | taylorr: good question. an H.264 keyframe should always be an IDR version of I. |
| [19:36:25] | jpabq: | taylorr: I had to make minor changes to most of the recorders, to get the PAT/PMT inserted. |
| [19:36:31] | taylorr: | ah, ok |
| [19:36:58] | taylorr: | jpabq: I notice with the changes that the first keyframe is a "P" type and not an "I" type? |
| [19:37:20] | jpabq: | I will take a look at that |
| [19:37:54] | jpabq: | after lunch :) |
| [19:38:56] | taylorr: | jpabq: no rush, thanks for the improvements... it's nice to have a clean start on the recordings |
| [19:40:09] | stichnot: | jpabq: What would be the observable effects of the change, with respect to keyframe identification, playback, etc.? |
| [19:44:26] | jpabq: | stichnot: really should not be any. It is just desirable to have a PAT/PMT on the front for identification purposes. |
| [19:45:12] | taylorr: | stichnot: didn't you make changes for HD-PVR to only mark the I frames and omit the P frames for keyframe marks? |
| [19:46:04] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8) | |
| [19:46:24] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv | |
| [19:46:24] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host) | |
| [19:46:24] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [19:51:59] | jpabq: | taylorr: I think I must have broke something. |
| [19:52:30] | taylorr: | jpabq: v3 or v4, both? |
| [19:52:38] | jpabq: | v4 |
| [19:53:07] | taylorr: | how often do the PAT/PMT packets arrive? |
| [19:53:47] | jpabq: | I don't know. ffmpeg's output doesn't make sense. ffprobe looks okay, though. |
| [19:54:31] | taylorr: | jpabq: what version of ffmpeg are you using? |
| [19:54:47] | jpabq: | taylorr: The reason we artificially insert a PAT/PMT on the front, is there is not guarantee the stream will have them. If a stream has them, I believe daniel said they would show up every 500ms or so. |
| [19:55:19] | jpabq: | 0.10.6 |
| [19:55:40] | taylorr: | ah, ok, we don't wait on a PAT/PMT packet... that's good |
| [19:55:53] | jpabq: | Guess I should build the latest version by hand |
| [19:55:53] | taylorr: | that's a good version to use |
| [19:56:08] | taylorr: | apparently there is some problems post 0.10 |
| [19:56:16] | jpabq: | oh? |
| [19:59:57] | taylorr: | jpabq: http://ffmpeg.org/trac/ffmpeg/ticket/2143 |
| [20:01:04] | taylorr: | I think it's just timestamp related so it may not cause any issues for what you are working on |
| [20:01:29] | taylorr: | jpabq: so is the intention to start on an IDR frame and not a P frame? |
| [20:01:41] | jpabq: | yes |
| [20:03:41] | taylorr: | jpabq: here is a good command I found on the mailing list to determine which type of packet is first.... ffprobe -analyzeduration 30000000 -show_frames -pretty -i <input> | grep 'pkt_pos\|pict_type\|coded_picture_number' | head -n 150 |
| [20:05:05] | danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv | |
| [20:05:53] | taylorr: | jpabq: remeber that there will be 3 B frames before the first I or P frame is printed out |
| [20:06:26] | taylorr: | the byte position for the I/P frames should be first though |
| [20:06:54] | jhall_: | I think PAT has a limit of 10 seconds |
| [20:06:58] | jhall_: | according to spec |
| [20:07:09] | jpabq: | That is a good command to use. Thanks. |
| [20:07:59] | jpabq: | taylorr: The first video packet has "key_frame=1" even though it has pict_type=P |
| [20:08:24] | taylorr: | jpabq: right, I thought that we wanted an I frame though? |
| [20:08:30] | jpabq: | ffmpeg also uses the convention that a keyframe == IDR |
| [20:10:01] | taylorr: | jpabq: ok, just making sure... I've been taking older recordings and removing all the packets before the first I frame with good success |
| [20:10:04] | jpabq: | I am confused, because I thought the same thing. I thought an IDR was a "special case" I frame. Maybe an IDR doesn't need to be a I frame. |
| [20:10:22] | taylorr: | didn't stichnot look into this |
| [20:11:55] | jpabq: | mythcommflag was not looking for IDR (H.264), it was just looking for I, which caused problem for HD-PVR recordings. So stichnot changed it to look for IDR, but that in turn caused problem for BBC because they don't follow the standard, and don't have any IDR frames, so you have to use I frames. |
| [20:12:22] | jpabq: | He didn't change anything in regards to recording, just commflag. |
| [20:12:33] | jpabq: | just commflag --rebuild |
| [20:13:06] | jpabq: | jhall_: 10 seconds apart? Is that a maximum? |
| [20:13:47] | taylorr: | jpabq: ok, I guess as long as it's a fully coded frame it doesn't matter if it's marked I or P |
| [20:15:54] | taylorr: | jpabq: I guess a good test is to run commflag --rebuild on a recordings that starts with a P frame and see if it is marked as the first frame in the mark up table |
| [20:16:18] | taylorr: | since that process is supposed to mark only IDR frames |
| [20:22:58] | taylorr: | jpabq: found this quote "The short answer is that every IDR frame is an I-frame, but not vice versa, so there can be I-frames that aren't IDR frames." |
| [20:23:13] | taylorr: | if that's true then a P-frame can not be an IDR frame |
| [20:24:36] | jpabq: | I wonder if more than one "frame" can be in a payload? We note where the payload starts, and if an IDR is found anywhere in that payload, we record the start of the payload as the location of the keyframe. |
| [20:25:37] | taylorr: | jpabq: I guess that's possible but the command I'm using is show "frames" so it should be correct |
| [20:26:09] | taylorr: | ffprobe show_frames should decode down into the stream and provide the correct type |
| [20:26:17] | taylorr: | maybe ffmpeg has a bug |
| [20:27:19] | rsiebert_ (rsiebert_!~quassel@e179128158.adsl.alicedsl.de) has joined #mythtv | |
| [20:28:07] | rsiebert (rsiebert!~quassel@g224248009.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds) | |
| [20:34:44] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has joined #mythtv | |
| [20:37:17] | jhall_: | for PAT I think so |
| [20:37:21] | jhall_: | for PMT I Think it is longer |
| [20:37:30] | jhall_: | if memory serves I saw this on www.coolstf.org some time ago |
| [20:38:39] | stichnot: | jpabq, taylorr: just catching up after lunch. jpabq correctly stated everything I did and know about HD-PVR, mythcommflag, and IDR frames. |
| [20:42:30] | taylorr: | jpabq: ok, looks like maybe it's ffmpeg that has issues.... some videos don't have any frames marked as an I-frame?!?! |
| [20:42:56] | taylorr: | other videos do have I-frames marked... very odd |
| [20:44:36] | taylorr: | jpabq: like you say though maybe there is more than one frame in the payload |
| [20:45:06] | taylorr: | sounds like we just need to focus on if it's a keyframe or not and not worry about the pict_type |
| [20:45:59] | jpabq: | Agreed. It does look like back-to-back is still not perfect though. I will work on that some more, see if I can figure it out. |
| [20:50:08] | taylorr: | jpabq: I'm going to try latest ffmpeg master and see if any of this frame identification is better |
| [20:50:11] | rsiebert (rsiebert!~quassel@e179135130.adsl.alicedsl.de) has joined #mythtv | |
| [20:50:35] | taylorr: | jpabq: so even v3 the back-to-back isn't working properly? |
| [20:52:46] | rsiebert_ (rsiebert_!~quassel@e179128158.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [20:53:21] | peper03 (peper03!~richard@port-92-203-89-195.dynamic.qsc.de) has quit (Ping timeout: 245 seconds) | |
| [20:53:28] | jpabq: | taylorr: correct. |
| [20:54:30] | taylorr: | jpabq: what aspect isn't working... just the PAT/PMT insertion? |
| [20:54:32] | jpabq: | According to that command you suggested, the first frame in the second file is has key_frame=0. What is odd, is that ffprobe seems to be otherwise happy with it. |
| [20:55:10] | taylorr: | jpabq: be careful looking at that output... look at the coded_picture number 0 |
| [20:55:11] | peper03 (peper03!~richard@port-92-203-3-121.dynamic.qsc.de) has joined #mythtv | |
| [20:55:32] | jpabq: | v3 only inserts PAT/PMT into the first show, not any subsequent shows. V4 inserts the PAT/PMT at the beginning of each file. |
| [20:55:49] | taylorr: | jpabq: what is bad about not having PAT/PMT? |
| [20:58:55] | taylorr: | jpabq: if you want I can take a look at the ffprobe output |
| [20:58:56] | jpabq: | taylorr: Ah. Thanks. I forgot that there was an out-of-order element possibility. |
| [20:59:12] | taylorr: | yes, that confused me at first :) |
| [21:00:39] | rsiebert_ (rsiebert_!~quassel@g225053103.adsl.alicedsl.de) has joined #mythtv | |
| [21:01:42] | jpabq: | If the PAT/PMT is missing, it is possible for the stream to be miss-identified. For example, I saw a case where mythtv failed to find any keyframes, because it was trying to look for mpeg2 keyframes, in an H.264 stream. Myth has logic like "if h264 then h264keyframes else mpeg2keyframes" So, if doesn't know what kind of stream it is, it assumes mpeg2. |
| [21:02:23] | jpabq: | I changed, that logic to detect an unknown stream type, and report it as such. |
| [21:02:47] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [21:03:00] | rsiebert (rsiebert!~quassel@e179135130.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds) | |
| [21:05:15] | dekarl: | taylorr: without PMT don't know what stream you got. so you can't autoselect the right audio language and other nice things |
| [21:05:42] | taylorr: | ok, thanks for the info |
| [21:06:02] | taylorr: | jpabq: just curious because I haven't ever noticed any problems before |
| [21:06:33] | jpabq: | taylorr: with the tip on out-of-order, it looks like both v3 and v4 are doing the right thing. I still agree there is some confusion about P=keyframe |
| [21:08:09] | taylorr: | jpabq: ok, I'm happy with the changes... I tested with latest ffmpeg and it's still reports P frames |
| [21:08:54] | jpabq: | ffprobe --show_frames segfaults before it reports any pict_type=I frames |
| [21:08:56] | taylorr: | jpabq: so is v4 ok to use now? were there any issues with the pat/pmt insertion? |
| [21:09:06] | jpabq: | Looks okay to me. |
| [21:09:43] | taylorr: | jpabq: I notice a lot of segfaults too.... but for the ones that don't it seems like it always P-frames or always I-frames that are keyframes |
| [21:10:09] | jpabq: | Do you actually see any pict_type=I reported? |
| [21:10:11] | taylorr: | the videos that have P-frames marked as keyframes don't have any I-frames marked anywhere |
| [21:10:24] | jpabq: | Agreed. |
| [21:10:25] | taylorr: | no I don't |
| [21:11:13] | jpabq: | I suspect that where it has keyframe=1, those really are I frames, that are being reported as P for some reason. |
| [21:15:19] | taylorr: | jpabq: just tested a video remuxed into mkv and it still says P-frames so it's not the container but something in the stream itself |
| [21:20:20] | Steve-Goodey (Steve-Goodey!~Steve-Goo@host86-144-3-137.range86-144.btcentralplus.com) has quit (Remote host closed the connection) | |
| [21:29:26] | jya: | Seeker`: can you give me some details on what you do to reproduce that problem, in particular how to set netstream.. I don't use it.. |
| [21:37:14] | Wolfgang2 (Wolfgang2!~Thunderbi@178-27-144-160-dynip.superkabel.de) has joined #mythtv | |
| [22:01:01] | SteveGoodey (SteveGoodey!~steve@host86-144-3-137.range86-144.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:19:33] | Chutt: | stichnot, it's mostly lower-res streaming stuff that needs padding. i had to deal with a hardware decoder a few years back that needed 32 pixel padding, which was crazy. =) |
| [22:20:15] | Chutt: | stichnot, anyway, doesn't avcodec report the coded_width/height in addition to the normal width/height? there really should be a full cropping rectangle exported as well, but it's been too long since i've done stuff with that lib |
| [22:34:58] | jya: | Chutt: the newer ffmpeg (1.1) includes information about width/height for each frame |
| [22:35:10] | Chutt: | just w/h? |
| [22:35:42] | jya: | in AVFrame contains that info. Can now be used to test if resolution has changed across, which makes our mod to ffmpeg with callbacks no longer required |
| [22:35:57] | jya: | that's all I looked at, likely there's more info... |
| [22:36:25] | Chutt: | ideally would be a full rect per frame |
| [22:36:46] | Chutt: | either way |
| [22:36:47] | Chutt: | heh |
| [22:38:40] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Read error: Operation timed out) | |
| [22:46:12] | tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:989a:e343:b22e:a002) has joined #mythtv | |
| [22:46:13] | tgm4883 (tgm4883!~tgm4883@2001:4968:202:3:989a:e343:b22e:a002) has quit (Changing host) | |
| [22:46:13] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [22:47:15] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 276 seconds) | |
| [22:47:48] | stichnot: | Chutt: I'm planning to look deeper into avcodec for more accurate width/height information. Hopefully that could also be used to properly fix #8937 and maybe other uses of 1088 in the code. |
| [22:47:48] | ** MythLogBot http://code.mythtv.org/trac/ticket/8937 ** | |
| [22:49:59] | jya: | stichnot: I will be doing the ffmpeg 1.1 resync this week-end. |
| [22:50:32] | stichnot: | jya: ok, in a branch like before? |
| [22:50:40] | jya: | from there we can start moving so we support things like change of resolution / bitrate on the fly that got broken following the introduction of multi-threaded h264 decoding |
| [22:51:16] | jya: | stichnot: probably… however, the resync will work as-is.. I've done a resync with their trunk just before I instead used the 1.0 branch... |
| [22:51:50] | jya: | so i know what's involved and it's not much… There's been no changes of API between 1.0 and 1.1 |
| [22:51:59] | jya: | so our code will work as-is without modifications |
| [22:52:27] | jya: | except of course if we want to use the new methods to check for change of resolution / audio within the media |
| [22:52:58] | jya: | once we move to that , we can get rid of our patches to ffmpeg that make use of a callback and get closer to the original ffmpeg |
| [22:54:11] | stichnot: | That sounds good. What are the methods called, that we would use for resolution change checking? (so I can look in advance) |
| [22:54:47] | seld (seld!~seld@h170n6-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 260 seconds) | |
| [23:02:02] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [23:11:24] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 256 seconds) | |
| [23:11:28] | jya: | there are no methods called |
| [23:11:43] | jya: | it's up to you to check if the new frame is different from the previous one |
| [23:12:02] | jya: | each AVFrame now contains the information related to the media info |
| [23:12:15] | stichnot: | OK, so I should just look at everything in AVFrame |
| [23:12:25] | jya: | and not just in the codec anymore that was filled at the time of opening the media |
| [23:12:26] | jya: | from what I've seen in ffplay changes |
| [23:12:46] | stichnot: | ok, that sounds good |
| [23:12:58] | jya: | they record the spec of the previous frame, and when there's a new one one coming, they check if it's the same. If not, they re-initialise their output layer |
| [23:13:18] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [23:13:46] | jya: | let me find the change for you… it was easy to tell.. I submitted a bug to them that failed to play a particular media… they quickly added resolution change detection to it |
| [23:17:17] | jya: | http://git.videolan.org/?p=ffmpeg.git;a=commi . . . 746561bba428 |
| [23:17:51] | jya: | see that now they check the height, with, format provided by the AVFrame rather than the codec |
| [23:18:46] | jya: | will need to adapt our code and ditch the callback stuff (there are three different callback, one for DVD, one for bluray, and one generic) |
| [23:19:21] | jya: | i have an idea on how we could do this… could do it just after resyncing |
| [23:23:03] | VManiac16 (VManiac16!~Unknown@69.4.155.83) has joined #mythtv | |
| [23:26:40] | stichnot: | yeah, that looks very nice |
| [23:27:02] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Ping timeout: 255 seconds) | |
| [23:31:13] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 248 seconds) | |
| [23:41:21] | peper03 (peper03!~richard@port-92-203-3-121.dynamic.qsc.de) has quit (Quit: Konversation terminated!) | |
| [23:41:49] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [23:48:27] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 260 seconds) | |
| [23:48:32] | Sharky-Sleep is now known as Sharky112065 | |
| [23:49:44] | danielk222: | jya: do they pass aspect ratio changes too? if not maybe we can get them to include that.. |
| [23:50:08] | jya: | can't you determine it from just looking at the width and height ? |
| [23:52:22] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [23:52:35] | neufeld_AFK is now known as neufeld | |
| [23:54:14] | seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv | |
| [23:54:52] | sl1ce (sl1ce!~johnathan@100.0.73.123) has joined #mythtv | |
| [23:55:49] | jpabq: | jya: not necessarily. For example, instead of 1920x1080, I have actually seen 960x1080 that was supposed to be rendered as 16:9. I guess every horizontal pixel was supposed to be drawn twice. |
| [23:57:28] | jpabq: | I think I read that "Dish" still has some HD channels where are transmitted at half resolution, and then scaled back up by the STB. |
| [23:58:03] | jpabq: | Directv used to do that too, but I think they finally got enough bandwidth to broadcast full-rez now. |
| [23:59:47] | Seeker`: | jya: 1. Start playing something with airplay. 2. Stop playing something with airplay. 3. Watch mythfrontend crash |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.