Beirdobot, irc.freenode.net

Saturday, May 3rd, 2014, 01:19 UTC

[01:19:51]

arescorpio (arescorpio!~arescorpi@211-243-16-190.fibertel.com.ar) has joined #mythtv

[01:31:03]

kc (kc!~Casper@unaffiliated/kc) has quit (Quit: Leaving)

[02:00:05]

kc (kc!~Casper@pool-71-185-186-159.phlapa.fios.verizon.net) has joined #mythtv

[02:00:05]

kc (kc!~Casper@pool-71-185-186-159.phlapa.fios.verizon.net) has quit (Changing host)

[02:00:05]

kc (kc!~Casper@unaffiliated/kc) has joined #mythtv

[02:00:10]

kc (kc!~Casper@unaffiliated/kc) has quit (Remote host closed the connection)

[02:26:04]

peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 252 seconds)

[02:26:48]

peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv

[02:30:28]

nyloc (nyloc!~quassel@p3EE2D8DF.dip0.t-ipconnect.de) has joined #mythtv

[02:33:54]

_nyloc_ (_nyloc_!~quassel@p3EE2DE3C.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)

[03:29:17]

fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds)

[03:30:42]

fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv

[04:02:32]

arescorpio (arescorpio!~arescorpi@211-243-16-190.fibertel.com.ar) has quit (Excess Flood)

[04:15:55]

tgm4883 (tgm4883!uid23806@ubuntu/member/tgm4883) has quit (Ping timeout: 240 seconds)

[04:16:44]

XDS2010_ (XDS2010_!sid1218@gateway/web/irccloud.com/x-wgyyhvhvbrfaptop) has quit (Ping timeout: 246 seconds)

[04:17:03]

superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (Ping timeout: 252 seconds)

[04:35:44]

tgm4883 (tgm4883!uid23806@gateway/web/irccloud.com/x-kcsqokppvmwcolcq) has joined #mythtv

[04:39:26]

superm1_ (superm1_!uid4318@gateway/web/irccloud.com/x-geugtjgbfozobwjq) has joined #mythtv

[04:50:12]

XDS2010_ (XDS2010_!sid1218@gateway/web/irccloud.com/x-afibmcwysjsgnmbt) has joined #mythtv

[04:52:29]

kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 264 seconds)

[04:59:33]

kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv

[05:03:20]

Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv

[06:08:30]

superm1_ (superm1_!uid4318@gateway/web/irccloud.com/x-geugtjgbfozobwjq) has quit (Read error: Connection reset by peer)

[06:09:54]

superm1_ (superm1_!uid4318@gateway/web/irccloud.com/x-oazlwxbalrdunvax) has joined #mythtv

[06:33:34]

rsiebert (rsiebert!~quassel@g226061215.adsl.alicedsl.de) has joined #mythtv

[06:36:31]

rsiebert_ (rsiebert_!~quassel@e179130053.adsl.alicedsl.de) has quit (Ping timeout: 250 seconds)

[07:31:08]

SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has joined #mythtv

[07:33:17]

joki (joki!~joki@p54861BBF.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds)

[07:38:49]

joki (joki!~joki@p5486189E.dip0.t-ipconnect.de) has joined #mythtv

[08:00:02]

jya:

#11377 is giving me the @#$@â€¦

[08:00:02]

** MythLogBot http://code.mythtv.org/trac/ticket/11377 **

[08:00:28]

jya:

hopefully, after that Iâ€™ll have a good grasp on myth decoding & rendering

[08:04:17]

ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (*.net *.split)

[08:04:18]

jheizer (jheizer!~jheizer@73.51.93.177) has quit (*.net *.split)

[08:04:18]

poptix (poptix!poptix@poptix.net) has quit (*.net *.split)

[08:04:18]

Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (*.net *.split)

[08:04:18]

jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (*.net *.split)

[08:04:18]

SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has quit (*.net *.split)

[08:04:18]

dblain_ (dblain_!~dblain@mythtv/developer/dblain) has quit (*.net *.split)

[08:04:19]

purserj (purserj!~purserj@hosting.collaborynth.com.au) has quit (*.net *.split)

[08:04:19]

neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has quit (*.net *.split)

[08:04:20]

jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (*.net *.split)

[08:04:21]

Gibby (Gibby!~Gibby@184.170.249.223) has quit (*.net *.split)

[08:04:21]

eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has quit (*.net *.split)

[08:04:21]

toeb_ (toeb_!~toeb@HSI-KBW-109-193-197-240.hsi7.kabel-badenwuerttemberg.de) has quit (*.net *.split)

[08:05:07]

ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv

[08:06:09]

jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv

[08:06:10]

Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv

[08:06:10]

poptix (poptix!poptix@poptix.net) has joined #mythtv

[08:06:10]

jheizer (jheizer!~jheizer@73.51.93.177) has joined #mythtv

[08:06:54]

SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has joined #mythtv

[08:06:54]

dblain_ (dblain_!~dblain@mythtv/developer/dblain) has joined #mythtv

[08:06:54]

purserj (purserj!~purserj@hosting.collaborynth.com.au) has joined #mythtv

[08:06:54]

neufeld (neufeld!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv

[08:11:36]

jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv

[08:11:36]

Gibby (Gibby!~Gibby@184.170.249.223) has joined #mythtv

[08:11:36]

eee-blt (eee-blt!~nb0yjxtr@ma.sdf.org) has joined #mythtv

[08:11:36]

toeb_ (toeb_!~toeb@HSI-KBW-109-193-197-240.hsi7.kabel-badenwuerttemberg.de) has joined #mythtv

[08:12:20]

dekarl:

stuartm, an idea for the web frontend. I have recording rules like ">60% star rating + HD filter" or "the inetref matches my watchlist on themoviedb". Now I'd like to see matching upcoming/past recordings of only one rule. Not sure what to do with recordings that match more the one recording rule.

[08:18:26]

seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has quit (Ping timeout: 246 seconds)

[08:20:54]

seld (seld!~seld@h7n7-rny-a12.ias.bredband.telia.com) has joined #mythtv

[08:28:34]

xris (xris!~xris@mythtv/developer/xris) has quit (Read error: Connection reset by peer)

[08:33:27]

xris (xris!~xris@xris.forevermore.net) has joined #mythtv

[08:43:28]

dekarl:

stuartm, another idea. depending on the "this channel" filter either show "all" or a list of channel with the correct "call sign". But what to do if the channel has been deleted since the rule has been created?

[08:47:07]

xris (xris!~xris@xris.forevermore.net) has quit (Ping timeout: 276 seconds)

[08:52:34]

xris (xris!~xris@xris.forevermore.net) has joined #mythtv

[08:59:11]

xris (xris!~xris@xris.forevermore.net) has quit (Read error: Connection reset by peer)

[09:03:29]

xris (xris!~xris@xris.forevermore.net) has joined #mythtv

[09:04:18]

stuartm:

dekarl: think we can do that

[09:05:01]

stuartm:

dekarl: if the channel has been deleted we can indicate that no channels match, perhaps even highlight those rules as 'broken' in the recording rule screen

[09:11:07]

dekarl:

Ok, I can write it down at https://code.mythtv.org/trac/wiki/WebFrontendWishlist so it doesn't get lost

[09:16:28]

doev (doev!~doev@p4FD43399.dip0.t-ipconnect.de) has joined #mythtv

[09:32:40]

doev (doev!~doev@p4FD43399.dip0.t-ipconnect.de) has quit (Quit: Verlassend)

[09:33:24]

peper03:

jya: Sorry for that!

[09:33:37]

jya:

peper03: I have that video playing now !

[09:33:44]

jya:

but h264 is now broken :)

[09:33:45]

dekarl:

Decoupling the seektable storage in the database and access to it from frontends could be a nice addition. e.g. access it via myth protocol and in memory cache, so we can bulk write to the databse. Judging from all the discussions about I/O system performance...

[09:33:47]

peper03:

jya: Without corruption?

[09:33:50]

jya:

yep

[09:33:59]

peper03:

Cool.

[09:34:13]

peper03:

Not the h264 bit, obviously :)

[09:34:42]

jya:

Iâ€™ve moved the code to use the new (well, 1.5 years) hwaccel APIâ€¦ And suddenly things work much better

[09:35:04]

jya:

hwaccel API is already use by the vaapi et xvba code

[09:35:26]

jya:

vdpau was still on the pretty much original code as it was first produced by nvidia years ago

[09:36:14]

jya:

it seems that with that particular sample, you have mpeg2 frame that canâ€™t be decoded by vdpau, so you get a mix of bothâ€¦ ffmpeg handles those properly, but you need to be called the proper way

[09:36:24]

peper03:

Is hwaccel part of vdpau?

[09:36:29]

jya:

no

[09:36:44]

jya:

hwaccel is FFmpeg set of API where you define a structure

[09:37:20]

jya:

so things look exactly like a normal codec. You define callbacks to render the frame, to decode the frame, memory context etc..

[09:37:29]

jya:

and ffmpeg calls it accordingly

[09:38:20]

jya:

the annoying thing, is the that hwaccel in ffmpeg 1.2 has been obsoleted in 2.0

[09:38:43]

jya:

now you provide even the painter to ffmpeg AVCodecContext and they call it directly

[09:39:11]

jya:

you donâ€™t extract the frame like we do and pass it to the painter

[09:39:26]

jya:

which is rather incompatible the way we do thingsâ€¦

[09:39:27]

peper03:

Ok, I think I get it. So we would get called to decode the frame and would try to use vdpau, which would fail in this case. We'd return the error and ffmpeg would pass it to a software decode callback?

[09:39:45]

peper03:

That's not good :(

[09:40:02]

jya:

we have mythplayer that opens the decoder, and then create the painter. Then in mythplayer decoder loop, we decode one frame, and mythplayer pass it to the painter

[09:40:58]

jya:

if you look at how they did it in xbmc and various player.. they actually have a decoder+painter class. it would be up to avfd to create both the decoder and the painter

[09:41:22]

jya:

the advantage of this, is that ffmpeg perfectly handles the transition between different format, or change of resolution

[09:41:28]

jya:

thatâ€™s how they do it.

[09:41:32]

stuartm:

not exactly by the OO book

[09:41:38]

jya:

for us, itâ€™s very messy.

[09:42:05]

jya:

stuartm: actually, the implementation in xbmc is far more OO than what we did in avfd

[09:42:23]

jya:

in avfd you pretty much have the code for all methods: vdpau, vaapi, d3d etc

[09:42:44]

jya:

with an exception for decoding only hw methods like crystalhd and VDA

[09:43:27]

jya:

in xbmc, they pretty much ask for a decoder, for a painterâ€¦ they have a vdpau one, a vaapi one etc..

[09:43:31]

jya:

much cleaner IMHO

[09:43:48]

jya:

not a massive lump of code all over the place like we do in avfd

[09:43:50]

stuartm:

aye, sounds like it

[09:44:07]

stuartm:

avfd is a mess, on that I think everyone would agree

[09:44:29]

jya:

the worse, is that we have the painter in libmytui, with the videoout method in libvdpau that calls the painter directly, and vice-versa

[09:44:46]

jya:

vdpau is done in one way

[09:45:15]

jya:

vaapi has a decoder class, a videoout class with direct call to opengl rendering

[09:45:39]

jya:

d3d is almost identical, you can tell it was done reproducing vaapi

[09:45:44]

jya:

(or vice-versa)

[09:45:52]

jya:

the other beauty in xbmc

[09:46:17]

jya:

is that the painter/rendering is creating when they are fed a frame

[09:46:43]

jya:

so they can do : will vdpau works? yesâ€¦ use it.. if not, will vaapi work? no will vda work etcâ€¦

[09:46:57]

jya:

and should the next frame change the support, itâ€™s all done on the fly

[09:47:16]

jya:

they donâ€™t have settings to say: use vdpau, vaapi, opengl or what else

[09:47:24]

jya:

itâ€™s all automatic, and they use the best one

[09:48:06]

stuartm:

the way it should be

[09:48:08]

jya:

we could do the same thingâ€¦ would have to refactor the entire avfd, go for a OO approach to link the decoder with the painter

[09:48:36]

jya:

and that would allow us to properly handle change of resolution, format etcâ€¦

[09:48:51]

jya:

without crashing like we do due to multi-threading problems

[09:49:21]

jya:

that would also allow to get rid of most of our changes in the mpegts code which is only there to handle change of format/resolution

[09:49:46]

jya:

anywayâ€¦ iâ€™m rather excited about itâ€¦

[09:50:06]

jya:

now back to at least being able to play all content so we can have a good 0.27.1 and move on

[09:51:34]

jya:

iâ€™m even thinking of shamelessly do the same way xbmc did it, and take all their code

[09:52:01]

jya:

they seem to be able to use Advanced 2X deinterlacer on all hardware.. they have a comment in the code about it

[09:52:44]

peper03:

I think it's a good idea to consider refactoring some of the code. Turfing some unneeded cruft out and refactoring the required cruft is usually quite pleasing (as long as the required work is clear in advance and you've actually got the time to work on it!)

[09:53:14]

peper03:

It's so unfortunate that time is nearly always the limiting factor.

[09:55:09]

jya:

my wife pretty much gave me an ultiimatum on working with myth

[09:55:45]

jya:

iâ€™ve spent the whole week on myth, including nights and we the 3rd on the way she wants me to take over

[09:55:53]

jya:

s/we/with

[09:56:22]

stuartm:

jya: they've borrowed our code in the past too

[09:56:56]

jya:

Anyone running master or devel/027candidates; can you try the cutlist editor and tell me if you are having an issue where when you move the cursor around, it still displays the same frame all the time ?

[09:57:18]

jya:

i had it happening to me (until I restored the mythconverg database) and now canâ€™t reproduce it

[09:57:29]

jya:

we have two people on the user list talking about it

[09:57:32]

jya:

iâ€™m at loss

[09:58:08]

jya:

could be related to what Iâ€™m seeing from time to time when switching channel, it shows a frame from a while back, sometimes even minutes earlier

[09:59:26]

stuartm:

I can't see how the database could be involved, a race of some description might be a better explanation

[09:59:46]

stuartm:

race, or some other timing related condition

[10:00:31]

stuartm:

although even then ...

[10:10:01]

jya:

someone was commenting on how it could be due to the seek table being incorrect as thereâ€™s a myth utility (canâ€™t remember which one) which generate invalid seek tables

[10:10:11]

jya:

(thatâ€™s a current bug report)

[10:28:08]

dekarl:

hmm, not seeing it under mythcommflag or mythtranscode right now

[10:29:05]

dekarl:

ahh, – video decoding – https://code.mythtv.org/trac/ticket/12010

[10:34:36]

peper03:

jya: Just updated to the latest master (previous build was from February *blush*). Editing the cutlist before the update worked fine. After updating, the log fills with 'decoding error' and the frame doesn't change.

[10:36:24]

jya:

greatâ€¦ now if you go back to february , does the issue occur again?

[10:37:00]

jya:

thatâ€™s what occured to me.. once I had the issue, it didnâ€™t matter how i went back, was still having it

[10:37:14]

jya:

anyhow, excellent, you can do a git bisect for me then :)

[10:40:47]

peper03:

I'll do my best. It updated the database from 1322 to 1324 in case that has anything to do with it.

[10:50:33]

peper03:

jya: I'll look at it later. SWMBO is requesting my presence :)

[10:51:27]

jya:

when youâ€™re ready to start bisecting, let me know , and Iâ€™ll give you the info to run the old code against the newer database

[10:54:15]

peper03:

Will do. I'll try the commit changing to 1324 first. If the problem doesn't appear there, it saves trying to mess about with database versions.

[11:01:44]

stuartm:

jya: I guess that's possible

[11:07:31]

stuartm:

fwiw, IIRC it's not that one of the ultilities produces bad seek tables but that it uses a different, older seektable scheme

[11:23:28]

Goga777 (Goga777!~Goga777@128-71-38-228.broadband.corbina.ru) has joined #mythtv

[11:30:28]

doev (doev!~doev@vpnclfun09.uni-koblenz.de) has joined #mythtv

[11:35:29]

doev (doev!~doev@vpnclfun09.uni-koblenz.de) has quit (Ping timeout: 252 seconds)

[12:26:59]

natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv

[13:07:07]

dekarl1 (dekarl1!~dekarl@p4FE85F16.dip0.t-ipconnect.de) has joined #mythtv

[13:09:59]

dekarl (dekarl!~dekarl@p4FCEE76D.dip0.t-ipconnect.de) has quit (Ping timeout: 250 seconds)

[13:23:51]

natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 250 seconds)

[13:29:03]

jya:

who has a super extra low CPU machine (atom or lower) but with a nvidia / vdpau enabled card?

[13:36:18]

dekarl1 is now known as dekarl

[13:38:19]

dekarl:

jya, I'm not setup for bisecting (using packages on a netboot machine) but can update that to master or master+patch. Dual Core Atom with VDPAU

[13:38:42]

jya:

oh, I donâ€™t want you to bisect

[13:38:49]

jya:

just need to test a patch

[13:38:57]

jya:

basically, making sure vdpau is properly use

[13:39:53]

jya:

what I have currently works well, plays all videos Iâ€™m throwing at it, but I canâ€™t tell if itâ€™s using vdpau or not, the log doesnâ€™t show (e.g libavcodec log shows [h264] instead of [h264_vdpau] like it use to.

[13:40:22]

jya:

for h264 itâ€™s simple enough to tell the difference if vdpau is used or not. CPU usage is clearly different (100+% vs 4–5)

[13:40:40]

jya:

but for mpeg2 and wmp3 not so much, and my machines are too powerful to tell

[13:40:47]

dekarl:

ok, I can throw H.264/VC-1 stream directly from bluray at the atom...

[13:41:08]

jya:

like wmp3 video I have itâ€™s all within 4–8% vdpau or not, even with the old code

[13:41:20]

dekarl:

Ahh, its about SD MPEG-2 and similar where its hard to notice?

[13:41:23]

jya:

do you have wmp3 videos and mpeg2 (hd/sd) to test?

[13:41:28]

jya:

yeah.

[13:41:32]

dekarl:

lots of MPEG-2 SD recordings

[13:41:53]

dekarl:

WMP3 basically means VC-1 style codecs?

[13:42:03]

jya:

the way the code was doing before, is if weâ€™re trying to play vdpau, then we search for the vdpau equivalent codec

[13:42:25]

jya:

that method works for wmp3 and mpeg2, but not for h264, when I try that I get lots of errors

[13:43:02]

jya:

i donâ€™t want to have a different code depending on the codec, so I want a generic vdpau code doing exactly the same thing no matter the codec

[13:43:23]

jya:

http://www.avenard.org/files/media/mediatest/

[13:44:00]

jya:

http://www.avenard.org/files/media/mediatest/ . . . 20sample.mpg (HD h264), http://www.avenard.org/files/media/mediatest/nachtschicht.asf (wmp3)

[13:44:07]

jya:

let me paste you the change

[13:44:11]

jya:

youâ€™re running master?

[13:44:15]

dekarl:

aye

[13:44:37]

dekarl:

0.28.20140327–1

[13:45:24]

jya:

ok

[13:45:31]

jya:

give me 10 minutes to wrap things up

[13:54:44]

gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Quit: Leaving)

[14:08:44]

jya:

dekarl: http://pastebin.com/V8YfegmZ

[14:08:55]

jya:

currently, ffmpeg+vdpau doesnâ€™t workâ€¦ has to be full vdpau

[14:09:12]

jya:

well, it should.. but it doesnâ€™t :)

[14:10:44]

jya:

so to compare the CPU usage for software decoding, youâ€™ll have to cancel the changes

[14:11:09]

** jya having doubts pure software would work now : **

[14:18:29]

peper03:

jya: Cut-list editor problem seems to be caused by [c519bba36] (https://github.com/MythTV/mythtv/commit/c519bba36)

[14:19:04]

jya:

thatâ€™s what was said in the dev list

[14:19:14]

jya:

but the code involved is never called there :(

[14:19:31]

jya:

are you editing live TV or a recording?

[14:19:40]

peper03:

A recording.

[14:20:01]

jya:

okâ€¦ even weirder

[14:20:08]

peper03:

Although it's quite possible it was recorded from LiveTV, in case that makes a difference.

[14:20:38]

peper03:

I don't actually have a receiver connected to this machine at the moment because one of the cards in my production box died.

[14:21:38]

jya:

I wonder if itâ€™s due to the change in locking FileRingBuffer

[14:21:50]

peper03:

The previous commit [606f1c750] (https://github.com/MythTV/mythtv/commit/606f1c750) was ok, [c519bba36] (https://github.com/MythTV/mythtv/commit/c519bba36) was bad.

[14:22:13]

jya:

this comment: – // lockForWrite takes priority over lockForRead, so this will

[14:22:14]

jya:

- // take priority over the lockForRead in the read ahead thread.

[14:22:27]

jya:

and if you just revert that particular commit itâ€™s all good?

[14:22:50]

stuartm:

step through it with gdb/other?

[14:23:00]

peper03:

That's what git bisect said, yes.

[14:23:59]

jya:

stuartm: the only code that is affected in the entire chain is in FileRingBuffer::Seek,

[14:24:06]

jya:

and the locking is suspicious

[14:24:37]

jya:

peper03: i mean if you do: with current checkout on c519bba36

[14:24:48]

peper03:

jya: Doing that now.

[14:25:05]

jya:

you see the issue, and git checkout c519bba36~ , then you don't

[14:25:49]

jya:

that would be interesting, because when youâ€™re just on c519bba36, the new internalread mode isnâ€™t called yet. Itâ€™s in the next commit. That seriously narrow the area where thereâ€™s an issue

[14:25:53]

jya:

and my guess itâ€™s the locking

[14:26:08]

jya:

sounds like it anyway

[14:29:42]

peper03:

jya: Yep, 606f good c519 bad.

[14:32:16]

jya:

peper03: excellentâ€¦ can you try this please ?

[14:32:17]

jya:

http://pastebin.com/BaZiv7rR

[14:34:54]

gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv

[14:36:37]

jya:

if that doesnâ€™t make a different letâ€™s try: http://pastebin.com/tqP3WWen

[14:36:50]

jya:

none of those are tested nor compiledâ€¦

[14:37:15]

jya:

unlocking to relock right-away should be fineâ€¦ though I donâ€™t like it, always unforeseen consequences ...

[14:37:38]

jya:

something like this could be done, though very dirty

[14:37:52]

peper03:

Well, it stops the 'decoding error' outputs but moving backwards and forwards is odd. It seems like it only updates once you navigate past a keyframe.

[14:39:28]

jya:

still have the still frame showing?

[14:40:25]

peper03:

Yes and no. The frame only seems to update once you navigate past the next keyframe.

[14:43:01]

peper03:

Yes, that seems to be the issue. The OSD updates ok but the frame shown only shows the keyframe. This is on an h264 recording. Let me try an MPEG2 recording.

[14:44:43]

jya:

peper03: http://pastebin.com/Tvi5ztH0

[14:44:50]

jya:

thatâ€™s back to the original locking behaviour

[14:44:50]

peper03:

MPEG2 seems ok. I can move frame by frame there. But I get the 'decoding error' messages again if I jump to the end of the recording. Don't get them on the h264 recording.

[14:47:28]

jya:

but is that different to what it was doing earlier (without the internal readmode)

[14:49:38]

** jya hating all those locks in mythâ€¦ **

[14:49:52]

peper03:

Not sure about the end of recording but I got the decoding error messages with both recordings when navigating normally.

[14:50:12]

jya:

how is patch03 doing?

[14:50:41]

peper03:

Trying it now. h264 seems the same...

[14:51:14]

peper03:

mpeg2 too

[14:51:33]

peper03:

So that made no difference to that issue.

[14:54:15]

jya:

you mean same as without any of those patches?

[14:54:40]

peper03:

Sorry, no. I mean all three patches give the same results.

[14:55:05]

jya:

meaning when you move left/right, the image stays the same...

[14:55:15]

jya:

like press up until you move by 20s

[14:55:25]

jya:

now move left right, does the image stays the same?

[14:55:40]

peper03:

On h264 material yes. On mpeg2 it works as expected.

[14:55:57]

jya:

what i saw was the image changing, and then the old one show up again

[14:56:14]

peper03:

On h264 it stays the same until you hit another keyframe. So moving by 20s will update the image.

[14:56:44]

peper03:

The keyframes on this recording seem to be about 1.7 seconds apart. So moving by 1 second, the image only updates every second press.

[14:57:38]

jya:

well, i canâ€™t explain then

[14:57:51]

jya:

you see that changes made in that commit

[14:58:03]

jya:

if you have an explanation...

[14:58:26]

jya:

with patch 3, itâ€™s back to identical behaviour

[14:58:33]

jya:

or maybe ...

[15:00:16]

peper03:

All the patches stop the 'decoding error' message and allow you to navigate in the cut-list editor. It's just the updating of the image that is still not quite right.

[15:00:31]

jya:

with:

[15:00:33]

jya:

http://pastebin.com/DCFDj6dL

[15:00:42]

peper03:

It could, of course, be that the image update bit is maybe caused by a different commit.

[15:00:48]

jya:

do you see in the log: internal readmode active or inactive?

[15:01:19]

jya:

well, you said just doing git checkout to the commit just before, doesnâ€™t make you see the issue

[15:02:39]

peper03:

Yes, that's true.

[15:02:40]

jya:

and if you re-add rawbitrate = 800; line 383 ?

[15:02:51]

peper03:

Applying new patch now...

[15:04:56]

jya:

iâ€™d be astonished it made a difference

[15:06:53]

peper03:

'internal readmode inactive'

[15:07:12]

jya:

okâ€¦ thatâ€™s what i thought

[15:07:27]

jya:

oh wellâ€¦ i try that a bit laterâ€¦

[15:09:28]

jya:

whatâ€™s the opposite of ctrl-c ctrl-c in emacs (e.g. how do i uncomment)?

[15:12:23]

** jya M-u â€¦ so intuitive **

[15:21:37]

peper03:

jya: Just tried going back to [c519bba] (https://github.com/MythTV/mythtv/commit/c519bba). That exhibits the same update behaviour (only updates on when passing keyframes on h264 and 'decoding error' if I jump to the end of an mpeg2 recording).

[15:21:59]

peper03:

I guess I was only looking for the decoding errors in the logs and not at the image when I looked before.

[15:22:13]

jya:

at so itâ€™s not that commit in the end?

[15:22:30]

jya:

though you did say applying the patch with the lock remove the decoding error right?

[15:23:18]

peper03:

The decoding errors are in [606f1c750] (https://github.com/MythTV/mythtv/commit/606f1c750). The other issue seems to be in an earlier commit.

[15:25:19]

peper03:

So the StopReads/StartReads patch seems to fix the decoding errors.

[15:26:15]

jya:

ok...

[15:26:18]

jya:

good to know

[15:26:58]

jya:

if you do StopReads(); StartReads(); in FileRingBuffer::SeekInternal, right at the beginning, is that enough?

[15:27:38]

peper03:

Yes, the first patch you sent seemed to work ok. Hang on a second and I'll double-check it again.

[15:27:47]

jya:

ok.. so if I understand properly, the frame issue may or may not be related to that commit

[15:28:18]

jya:

the first one I was playing with the lock I believe.. here, I donâ€™t even touch it

[15:28:22]

peper03:

The frame issue appears *not* to be related to that commit. It occurs in the previous commit.

[15:28:49]

jya:

ah no.. that was my first patch :)

[15:29:05]

peper03:

Easy to get confused :)

[15:29:17]

jya:

itâ€™s also very late here :)

[15:29:28]

jya:

and I had a very late night yesterday on that vdpau thing

[15:29:42]

peper03:

You'll be getting into trouble again with her indoors :)

[15:34:32]

jya:

I love the answer I got on libavuser in regards to vdpau

[15:34:44]

jya:

so the â€œde-facto official documentationâ€ is â€¦.

[15:34:45]

jya:

.....

[15:34:46]

jya:

https://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_vdpau.c

[15:37:24]

peper03:

jya: Ok, first patch (http://pastebin.com/BaZiv7rR) works fine.

[15:37:40]

jya:

just for removing the error though

[15:37:58]

jya:

and mpeg2

[15:38:01]

jya:

h264 wrong

[15:38:05]

jya:

do i have this right?

[15:38:21]

peper03:

And forget the frame-update issue. That was obviously a complete and utter brain-fart on my side. Stupid me was looking at end-credit slides. They don't change every frame.

[15:38:37]

** peper03 buries his head in shame **

[15:40:55]

jya:

youâ€™re kidding right?

[15:41:09]

jya:

so first patch was all that was required ?

[15:41:29]

jya:

i had done a TinTin Soviet thing: didnâ€™t see the point of it, so removed it

[15:41:59]

jya:

anyway.. thanks

[15:42:04]

jya:

one issue resolved

[15:45:36]

jya:

iâ€™m very puzzled on why it would cause a decoding error however

[15:47:57]

peper03:

I wish I was kidding!

[15:48:34]

dekarl:

jya, got to leave for the playground... 2 hunks failed to apply to master, I can look at it later

[15:48:45]

peper03:

I should probably not be allowed near a computer for at least several hours.

[15:48:55]

jya:

dekarl: no worriesâ€¦

[15:49:07]

jya:

i got the confirmation that what i was doing was correct

[15:49:17]

dekarl:

even better :)

[15:52:55]

jya:

and i carefully measured, i can see the difference CPU-wise

[15:53:10]

jya:

whatâ€™s weird though, is in the libav log, thereâ€™s nothing telling you youâ€™re using vdpau

[16:05:44]

J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv

[16:19:50]

Warped_ (Warped_!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has joined #mythtv

[16:20:07]

Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Ping timeout: 252 seconds)

[16:22:16]

_joey (_joey!~joey@pa49-183-5-130.pa.vic.optusnet.com.au) has joined #mythtv

[16:22:42]

_joey:

please recommend a good DVB-T USB tuner for linux

[16:22:44]

_joey:

thanks

[16:25:34]

Warped_ (Warped_!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 29.0/20140421221237])

[16:40:42]

SteveGoodey:

_joey: Have you seen this ? http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices

[16:55:20]

jya:

peper03: iâ€™ve pushed all my last changes (all related to video playback fixes)â€¦ would appreciate if you could test it against the DVD you had problems playing before

[17:02:28]

peper03:

jya: Ok, compiling now.

[17:04:39]

jya:

\o/

[17:05:03]

peper03:

Yep. That plays fine! :)

[17:05:10]

jya:

excellent...

[17:05:23]

jya:

need to add support for 90 / 270 degres rotated iphone video

[17:05:45]

jya:

in vdpau thatâ€™s simple.. but i need to learn about opengl now

[17:07:49]

jya:

what is better, 160 commits with all the last ffmpeg fixes to 1.2 branch, or one big one ? I gather it makes it easier for finding regression to have plentyâ€¦ that and the author is kept

[17:08:19]

peper03:

You mean VVS (http://www.youtube.com/watch?v=Bt9zSfinwFA)? Problem is, if you do that, how will anyone ever learn?

[17:08:33]

jya:

VVS?

[17:08:52]

jya:

ahhh

[17:09:06]

jya:

ahahah

[17:09:32]

jya:

LOL

[17:13:26]

peper03:

My wife is slowly learning.

[17:19:29]

jya:

mine isnâ€™t :)

[17:19:55]

jya:

anyone with an interlaced VC1 video?

[17:20:13]

jya:

looking at the list of fixes in ffmpeg 2â€¦ they have a fix for those

[17:22:00]

jya:

seems to be common with BBC blurays

[17:25:19]

stuartm:

jya: I might do but I don't know offhand

[17:30:10]

stuartm:

doh, all of my blu-ray rips were on a drive I pulled out of the NAS because it was starting to fail

[17:30:20]

stuartm:

haven't got around to replacing it

[17:30:29]

jya:

raid?

[17:31:21]

stuartm:

no

[17:33:22]

stuartm:

drive still works, but was starting to produce SMART warnings so I decided to remove it to prevent wear until I bought a replacement, thought I'd spread the rips around more but so far every one in mythvideo is missing

[17:35:12]

stuartm:

well not every one, but those that are present are either H.264 or progressive VC1

[17:35:40]

jya:

found an interlaced VC1 sample

[17:36:00]

doev (doev!~doev@p4FD42C04.dip0.t-ipconnect.de) has joined #mythtv

[17:36:57]

jya:

interestingâ€¦ without the patch, vdpau doesnâ€™t play it at all. and with itâ€™s perfect. but using ffmpeg decoder it plays about 2–3 times too fast

[17:41:09]

Goga777 (Goga777!~Goga777@128-71-38-228.broadband.corbina.ru) has quit (Ping timeout: 252 seconds)

[17:44:27]

_joey (_joey!~joey@pa49-183-5-130.pa.vic.optusnet.com.au) has quit (Ping timeout: 252 seconds)

[17:44:46]

stuartm:

oops, might help if the NAS wasn't powered off

[17:46:29]

_joey (_joey!~joey@pa49-183-5-14.pa.vic.optusnet.com.au) has joined #mythtv

[17:48:00]

stuartm:

and despite what the box says, Planet Earth is progressive :/

[17:48:29]

Goga777 (Goga777!~Goga777@128-71-38-228.broadband.corbina.ru) has joined #mythtv

[17:55:34]

doev (doev!~doev@p4FD42C04.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)

[17:59:53]

jya:

stuartm: should you backport 8d11d72f570aa52d7cd8a102e7ac4fa90c77ab16 ?

[17:59:56]

jya:

[8d11d72f570aa52d7cd8a102e7ac4fa90c77ab16]

[18:00:18]

jya:

https://github.com/MythTV/mythtv/commit/8d11d . . . 4fa90c77ab16

[18:01:16]

stuartm:

jya: I may, but it's mostly a cosmetic change, you can still enter manually type the correct symbol rate into the combobox

[18:01:26]

jya:

ok

[18:09:13]

doev (doev!~doev@vpnclfun11.uni-koblenz.de) has joined #mythtv

[18:34:08]

rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has quit (Quit: Coyote finally caught me)

[18:49:01]

doev (doev!~doev@vpnclfun11.uni-koblenz.de) has quit (Ping timeout: 276 seconds)

[18:53:46]

jya:

paul-h: whatâ€™s the point of RemoteFile::CopyFile ? thereâ€™s already a utility for doing just that

[18:54:15]

jya:

RemoteFile doesnâ€™t seem the best place to add high level utility routine

[18:58:40]

xris (xris!~xris@xris.forevermore.net) has quit (Changing host)

[18:58:40]

xris (xris!~xris@mythtv/developer/xris) has joined #mythtv

[19:02:14]

Goga777 (Goga777!~Goga777@128-71-38-228.broadband.corbina.ru) has quit (Read error: Connection reset by peer)

[19:05:09]

jya:

jpabq: could you rename your ExternalRecorder files names so they are all lowercase to keep consistency ?

[19:05:45]

doev (doev!~doev@p4FD418EF.dip0.t-ipconnect.de) has joined #mythtv

[19:13:50]

_joey (_joey!~joey@pa49-183-5-14.pa.vic.optusnet.com.au) has left #mythtv ()

[19:43:18]

doev (doev!~doev@p4FD418EF.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds)

[20:28:49]

superm1_ (superm1_!uid4318@gateway/web/irccloud.com/x-oazlwxbalrdunvax) has quit (Ping timeout: 245 seconds)

[20:29:21]

superm1_ (superm1_!uid4318@gateway/web/irccloud.com/x-loicbwbixxnpmdix) has joined #mythtv

[20:33:17]

rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:1842:e9f:3b7a:b15e) has joined #mythtv

[20:33:17]

rhpot1991 (rhpot1991!~rhpot1991@2001:4968:202:3:1842:e9f:3b7a:b15e) has quit (Changing host)

[20:33:17]

rhpot1991 (rhpot1991!~rhpot1991@ubuntu/member/rhpot1991) has joined #mythtv

[20:43:17]

andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has joined #mythtv

[20:51:13]

dekarl:

jya, oh my... I looked at the interlaced VC-1 fix... good luck understanding whats happening there and why when the next person comes along... A lookup table with four values (one unused value, oh noes) and proper documentation would have been wasting so much memory... Maybe we should submit a patch to avoid the branch ;)

[20:51:56]

dekarl:

or just use a plain old switch statement and let the compiler come up with the lookup table (and maybe even a perfect hash, if its worth it)

[21:22:55]

dekarl:

out = (0x38 >> (in << 1)) & 03; // turn 0,1,2 into 0,2,3

[21:40:46]

SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!)

[21:41:28]

jpabq:

jya: If it was up to me, I would rename all the other files to be mixed case — to keep consitency ;-) I did briefly think about the fact that *most* of the file names were all lowercase, but since that is not 100% true I figured people didn't really care.

[22:09:08]

jheizer (jheizer!~jheizer@73.51.93.177) has quit (Ping timeout: 255 seconds)

[22:45:53]

kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: Poof)

[22:46:59]

kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv

[23:20:48]

jya:

dekarl: itâ€™s all in the commit log.. it needs 0, 2 or 3, ffmepg uses 0, 1 or 2

[23:23:26]

jya:

jpabq: i do care, mostly because in the past, weâ€™ve had people renaming those files, and my mac is a case insensitive file system, and that causes havoc with git

[23:28:35]

jya:

in any case, i havenâ€™t seen a combined case files for years now (only exception are directory names), which files are you referring to?

[23:39:04]

andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)

MythLogBot@irc.freenode.net :: #mythtv

Current users (72):