[Ffmpeg-devel-irc] ffmpeg-devel.log.20150630

[burek]

[00:02:55 CEST] <durandal_170> wm4: you could write poetry
[00:04:47 CEST] <wm4> wat
[00:04:57 CEST] <Compn> durandal_170 : cropdetect is from mplayer iirc, thats why gpl ?
[00:05:19 CEST] <Compn> dont quote me on that :P
[00:09:19 CEST] <Compn> wm4 : asf_o should not become default until its tested against the wmv/asf/wma/dvr-ms samples in samples.ffmpeg.org . 
[00:09:44 CEST] <Compn> not even sure why i have to say this, should be common sense.
[00:11:37 CEST] <nevcairiel> fixing the old demuxer now after it being broken for years is however also something that time should be spent on, it'll continue to have terrible code quality issues =p
[00:12:02 CEST] <Compn> huh?
[00:12:40 CEST] <Compn> ok then
[00:13:12 CEST] <Compn> wonders if nevcairiel saw the list of bugs compn found on -devel
[00:13:16 CEST] <durandal_170> New one will be fixed eventually
[00:13:40 CEST] <nevcairiel> Compn: fix those instead of working on the old one now
[00:13:51 CEST] <nevcairiel> if someone wanted to improve the asf demuxer, they could've started years ago
[00:13:55 CEST] <nevcairiel> now its just for show
[00:14:08 CEST] <philipl> Nevertheless, the new one is too buggy to switch over to as-is.
[00:14:45 CEST] <j-b> Compn: are you compiling all the samples?
[00:14:58 CEST] <Compn> j-b :  i linked to the samples on -devel, yes
[00:15:15 CEST] <Compn> (also i didnt find any bugs i nthe old asf demuxer while testing, or i would report them too)
[00:16:18 CEST] <nevcairiel> I never said the new one should be default right now, its just that carl objected without even testing a single file, and then goes to fix the old demuxer to support his non-argument even more, which is just stupid
[00:16:49 CEST] <Compn> i wasnt claiming you made that claim nevcairiel. thats why i was talking to wm4 when i said it
[00:17:34 CEST] <wm4> what did I say?
[00:17:58 CEST] <philipl> I don't disagree. Carl appears to have poisoned the waters somewhat. Compn went and found real failures that need to be addressed.
[00:18:18 CEST] <philipl> Whether Carl is being productive or not is orthogonal, even if it's not desirable.
[00:18:34 CEST] <Compn> wm4 : "The new demuxer was written based on the official ASF spec, and was
[00:18:34 CEST] <Compn> tested against a number of real world samples.
[00:18:51 CEST] <Compn> from your mail
[00:19:39 CEST] <wm4> well that's probably not wrong
[00:19:47 CEST] <Compn> wm4 : then "Which ones? Surely you know, as it has been severe enough that you got MiNi to block the new demuxer and not only keep the old demuxer, but to leave it as default."
[00:20:42 CEST] <Compn> which is why i was disagreeing with whatever comment you made about defaults.
[00:20:53 CEST] <Compn> not important, hope i dont offend anyone :P
[00:21:08 CEST] <j-b> you offend me
[00:21:18 CEST] <Compn> j-b : i'm going to commit those qsv patches :P
[00:21:26 CEST] <philipl> haha.
[00:21:36 CEST] <j-b> Compn: haha
[00:21:47 CEST] <wm4> anyway, no matter how you look at it, having two demuxers in the code tree just because one was "merged" but found insufficient is a pretty absurd situation on its own
[00:21:49 CEST] <philipl> I think we can all agree *those* are offensive.
[00:21:58 CEST] <nevcairiel> companies, no clue about anything
[00:22:25 CEST] <Compn> hmm
[00:22:33 CEST] <Compn> didnt we have this exact same discussion before?
[00:22:41 CEST] <Compn> i think about prores (and before that something else)
[00:22:44 CEST] <wm4> we have them all the time
[00:22:49 CEST] <philipl> intel have competent engineers who know how to work with open-source projects. Where's __gb__ when you need him?
[00:22:49 CEST] <wm4> and it keeps happening
[00:23:08 CEST] <wm4> haha, Intel
[00:23:09 CEST] <j-b> libyami
[00:23:10 CEST] <j-b> lol
[00:23:13 CEST] <wm4> Intel never seem to finish anything
[00:23:25 CEST] <wm4> just half-baken APIs and implementations where you look
[00:23:31 CEST] <wm4> (probably some kind of management problem)
[00:23:33 CEST] <kierank> their marketing is good though
[00:23:34 CEST] <philipl> Not in our part of the world to be sure.
[00:23:44 CEST] <kierank> half the world says "WHY DONT YOU SUPPORT HARDWARE ENCODING"
[00:23:44 CEST] <philipl> But their kernel and Xorg work is fine.
[00:24:03 CEST] <wm4> their GPU drivers keep causing issues
[00:24:06 CEST] <Compn> wonder how many chinese ffmpeg forks with big hwaccel patches there are...
[00:24:17 CEST] <wm4> it requires performing black magic not to get tearing with Intel GPUs
[00:24:40 CEST] <nevcairiel> I dunno, qsv decoding just seems like wasted effort, whats wrong with dxva2 for windows and vaapi for linux
[00:24:42 CEST] <philipl> wm4: That's a wider mesa issue I think.
[00:25:07 CEST] <Compn> isnt qsv in the cpu ?
[00:25:11 CEST] <wm4> philipl: I doubt it... Intel don't even use many parts of Mesa due to NIH
[00:25:16 CEST] <Compn> or am i thinking of a diff api...
[00:25:18 CEST] <nevcairiel> Compn: strictly in the gpu .. which is in the cpu
[00:25:24 CEST] <Compn> oh yes
[00:25:25 CEST] <Compn> that one
[00:25:34 CEST] <nevcairiel> they just only built integrated-GPUs
[00:25:46 CEST] <Compn> anyone use intel widi ? :P
[00:25:47 CEST] <jamrial> i remember trying to use lavfilter's qsv decoding with a fresh haswell win8.1 notebook some time ago and got choppy video out of a 1080p h264 video
[00:25:48 CEST] <nevcairiel> but if you buy a CPU without a built-in GPU, you dont get qsv
[00:26:09 CEST] <philipl> wm4: This is true, but solving tearing requires co-ordination all the way up to the presentation layer.
[00:26:12 CEST] <Compn> so its the intel atom thing all over again ?
[00:26:58 CEST] <wm4> philipl: I suppose... but nvidia gets it right
[00:27:05 CEST] <wm4> or at least "more right"
[00:27:13 CEST] <philipl> wm4: Yes, the do. But they replaced everything :-)
[00:27:28 CEST] <philipl> (and not without good reasons)
[00:28:11 CEST] <Compn> wm4 : i think my nvidia card is dying -  http://i.imgur.com/iaPdHXE.jpg
[00:28:40 CEST] <nevcairiel> your OS is also dead for a decade already
[00:28:52 CEST] <philipl> Anyway - two asf demuxers. The old one has known problems and is likely unsalvagable. The new one has different known problems, and can't credibly be switched in as the new default.
[00:28:53 CEST] <kierank> windows xp
[00:28:53 CEST] <kierank> nice
[00:28:55 CEST] <wm4> lol direct2d...
[00:29:03 CEST] <Compn> thats vista, i'll have you know.
[00:29:12 CEST] <Compn> with classic theme
[00:29:17 CEST] <Compn> because screw colors.
[00:29:29 CEST] <philipl> So if you accept that the new one is more likely to be made workable than the old one, you need to have both around until the new one does reach that level.
[00:29:35 CEST] <wm4> why don't you use win7 like normal people
[00:29:51 CEST] <wm4> (and wow win8 is terrible I can't believe it)
[00:29:53 CEST] <Compn> win7 is outdated too
[00:30:11 CEST] <Compn> now you're all in the same boat as me! no one can upgrade! bwahaha
[00:30:27 CEST] <wm4> I use windows for testing stuff only
[00:30:43 CEST] <nevcairiel> 8.1 is fine, you can easily just ignore the new UI
[00:31:12 CEST] <Compn> philipl : someone will be testing the new demuxer on a large group of samples soon.
[00:31:31 CEST] <nevcairiel> and once 10 is stable, it should resolve the last concerns about UI problems that 8 had
[00:31:53 CEST] <philipl> Compn: Right. I'm really just responding to people being unhappy that we've got two in the codebase. It seems that's unavoidable unless you want to believe the old one can be made good.
[00:32:10 CEST] <jamrial> Win10 being a free upgrade makes me wonder if their intention is to push the Win Store, reduce fragmentation, or both
[00:32:18 CEST] <Compn> philipl : you cant make everyone happy.
[00:32:25 CEST] <philipl> Compn: agreed.
[00:32:33 CEST] <Compn> jamrial : you know its going to be a subscription os, right? pay $100 year for windows.
[00:32:43 CEST] <Compn> every year. until the end of time.
[00:32:46 CEST] <jamrial> no, it's not
[00:32:48 CEST] <wm4> a fresh win81 install is plastered with commercials
[00:32:50 CEST] <Compn> no?
[00:32:53 CEST] <jamrial> where did you get that?
[00:32:57 CEST] <wm4> so no doubt they're pushing this store crap
[00:33:01 CEST] <Compn> thats what i'd do if i was microsoften
[00:33:09 CEST] <nevcairiel> what commercials
[00:33:17 CEST] <nevcairiel> the only commercials a fresh 8.1 now gets is for windows 10
[00:33:20 CEST] <jamrial> Compn: good thing you don't work for them then :p
[00:33:59 CEST] <wm4> nevcairiel: when you open what was once the start menu, there are dozens of "applets" active that get content from commercial third party sites
[00:34:07 CEST] <wm4> like news, weather, whatever
[00:34:12 CEST] <nevcairiel> oh, i never use that
[00:34:12 CEST] <Compn> jamrial : http://www.forbes.com/sites/gordonkelly/2015/05/12/free-windows-10-has-high-cost/
[00:34:38 CEST] <wm4> and in the video player thing (whatever the heck it is) you readily can subscribe to TV shows etc.
[00:34:51 CEST] <wm4> all geared towards dumb consumers
[00:35:09 CEST] <nevcairiel> Compn: that article is sensationalism and FUD
[00:35:10 CEST] <wm4> not even OSX is this bad
[00:35:33 CEST] <Compn> nevcairiel : so windows will be free then ?
[00:35:43 CEST] <nevcairiel> fact remains, if you upgrade within the first year, its entirely free
[00:35:49 CEST] <nevcairiel> if you wait longer, you pay a one-time upgrade price
[00:36:02 CEST] <nevcairiel> unless they extend it, they did that with 8 before
[00:36:06 CEST] <wm4> the win10 thing keeps crashing for me
[00:36:15 CEST] <wm4> and apparently it wants me to sign in to get win10?
[00:36:25 CEST] <jamrial> Compn: it doesn't mention a yearly fee like you said above
[00:36:39 CEST] <Compn> jamrial : "Yes, Windows 10 will be the last numbered version of the OS and going forward it will simply become a ‘Windows’ subscription service. "
[00:36:49 CEST] <nevcairiel> thats BS
[00:37:00 CEST] <jamrial> so speculation is facts now?
[00:37:02 CEST] <Compn> i believe you , thats the last i heard of it
[00:37:07 CEST] <nevcairiel> some idea the author created
[00:37:09 CEST] <Compn> i havent seen microsoft deny it
[00:37:39 CEST] <Compn> i thought it was a news site, not blog speculation
[00:37:42 CEST] <Compn> my bad.
[00:38:08 CEST] <wm4> hm, tried seeking with the new asf demuxer
[00:38:13 CEST] <wm4> it just doesn't work
[00:39:34 CEST] <Compn> nevcairiel : to answer your question earlier, i'm no programmer, i cant fix the demuxer old or new. if i find bugs with either i'll report them with samples.
[00:39:40 CEST] <nevcairiel> to be fair, it often also doesnt work with the old one wm4 =p
[00:39:58 CEST] <wm4> yes
[00:40:03 CEST] <nevcairiel> thats really the major complaint I hear from my users, seeking in asf is broken
[00:40:10 CEST] <wm4> it's all fucked up
[00:40:18 CEST] <Compn> why not port mplayer asf demuxer to ffmpeg ?
[00:40:21 CEST] <michaelni> which ticket was that ?
[00:40:21 CEST] <Compn> it works, and it doesnt suck :D
[00:40:29 CEST] <Compn> for seeking*
[00:40:39 CEST] <nevcairiel> Compn: its mplayer, it must suck .. also its probably GPL
[00:41:05 CEST] <Compn> >wants to ripoff lgpl code >thinks gpl code is cancer?
[00:41:30 CEST] <Compn> sorry, troll slipped out
[00:41:46 CEST] <Compn> michaelni : can you do frame-accurate seek with asf file ?
[00:41:58 CEST] <Compn> i'm not even sure ffmpeg has a frame accurate seek option
[00:42:02 CEST] <nevcairiel> i dont need frame accurate, i need working =p
[00:42:13 CEST] <nevcairiel> anyway, sleepy time
[00:42:18 CEST] <Compn> nevcairiel : ffmpeg -i file.asf -ss 30 ?
[00:42:22 CEST] <wm4> is there a git mirror for mplayer yet? or anything browseable
[00:43:35 CEST] <Compn> wm4 : git clone git://git.mplayerhq.hu/mplayer
[00:44:00 CEST] <Compn> not sure ............ if that works.
[00:44:39 CEST] <wm4> it does
[00:44:47 CEST] <Compn> or if updated.
[00:45:03 CEST] <nevcairiel> what does mplayer use otherwise, cvs? =p
[00:45:04 CEST] <philipl> I git-svn'ed my own. Only took 12 hours.
[00:45:18 CEST] <Compn> hey i miss cvs , but mplayer is  still on svn.
[00:45:25 CEST] <nevcairiel> cvs is terrible
[00:45:30 CEST] <wm4> https://github.com/pigoz/mplayer-svn/blob/master/libmpdemux/demux_asf.c
[00:45:50 CEST] <Compn> mplayer asf demuxer is half the size of ffmpeg. although i wonder if dvr-ms is not supported
[00:46:05 CEST] <wm4> there are other files
[00:46:10 CEST] <Compn> ah
[00:46:27 CEST] <wm4> asheader.c/h, asf.h, asfguid.h, and of course all the code messed into demuxer.c without any reason
[00:46:31 CEST] <Compn> ah
[00:46:36 CEST] <Compn> nevermind then
[00:47:26 CEST] <Compn> mplayer has support for encrypted/drm asf too. i wasnt able to test that with ffmpeg demuxers-not sure if supported
[00:55:22 CEST] <Compn> wm4 : so , just add parsing to lavf asf and will be simple to make it seek like mplayers ?
[00:55:46 CEST] <wm4> wat
[00:56:40 CEST] <Compn> nevermind, i'm thinking of non-seekable to seekable.
[00:56:52 CEST] <Compn> back to jp2k i go.
[01:03:18 CEST] <Compn> did anyone ever answer michaelni's question about who maintains asf_o ?
[01:04:29 CEST] <Compn> durandal_170 : whos going to fix the new asf demuxer ? where should the bugs be reported?
[01:06:40 CEST] <Compn> any volunteers ?
[01:06:46 CEST] Action: Compn runs
[01:18:10 CEST] <JEEBsv> Compn: sasshka is the author (elenril's sister), and thus the maintainer
[01:19:45 CEST] <kierank> JEEBsv: lol
[01:21:28 CEST] Action: JEEBsv goes back into thinking about a probing mode that knows its input is PCM and that something could be inside
[01:24:49 CEST] <kierank> something in side PCM in ffmpeg
[01:24:49 CEST] <kierank> lol
[01:24:57 CEST] <kierank> won't work evah
[01:25:26 CEST] <JEEBsv> I must say, I was quite surprised I got AAC in PCM to work as a test for my demuxer
[01:25:42 CEST] <BBB> isnt PCM simply raw audio data?
[01:25:45 CEST] <BBB> or is this another pcm?
[01:25:45 CEST] <JEEBsv> I just forced AAC and told I needed full parsing
[01:26:25 CEST] <JEEBsv> BBB: bitstreaming
[01:27:05 CEST] <JEEBsv> I just got a demuxer working that works with old captures, back when raw MPEG-TS wasn't yet available
[01:27:08 CEST] <kierank> there's lots of bitdepth oddities
[01:27:26 CEST] <kierank> like how you deal with a 16-bit bitstream within 20-bit pcm (yes this is allowed)
[01:28:05 CEST] <rcombs> 4 zero bits?
[01:28:22 CEST] <JEEBsv> so it has re-encoded captured 4:2:2 video, and since you could tell your receiver the capture card can habla bitstreaming, bitstreamed AAC in PCM :3
[01:28:48 CEST] <kierank> rcombs: yes but in a continuous 20-bit bitstream
[01:29:04 CEST] <kierank> nothing is byte aligned
[01:29:06 CEST] <JEEBsv> this was the best you could get up until middle of '07 or so
[01:29:15 CEST] <JEEBsv> as far as capturing Japanese DTV went
[01:31:03 CEST] <JEEBsv> (unless you had one of those receivers that just gave you the MPEG-TS over firewire or so, although you possibly needed to hardware mod the STB to get that working)
[01:44:01 CEST] <Compn> is the default audio encoder for mkv vorbis ?
[01:44:35 CEST] <Compn> is vorbis the default audio encoder for mkv ?
[01:47:59 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:84afc6b70d24: avcodec/mjpegdec: Fix small picture upscale
[02:09:15 CEST] <llogan> Compn: ffmpeg -h muxer=matroska
[02:11:16 CEST] <llogan> it depends on your build what the default is
[02:55:00 CEST] <BBB> so my understanding is that we now have 2 asf demuxers that both suck?
[02:55:05 CEST] <BBB> thats just awesome
[03:16:52 CEST] <rcombs> people still care about asf?
[03:36:01 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:4aa0de644a2d: avcodec/h264_refs: discard mismatching references
[09:12:54 CEST] <cone-130> ffmpeg 03James Almer 07master:6415dcb01318: configure: fix hevc_vdpau_hwaccel dependencies
[10:53:49 CEST] <cehoyos> Hi! Can anybody explain to me what "prediction method" means wrt jpeg2000?
[11:09:39 CEST] <JEEBsv> Compn: the asf demuxer person woke up so I re-linked the samples you posted to her and she happily accepted them
[11:09:41 CEST] <michaelni> cehoyos, the prediction_method is used by the j2k encoder to choose between the 5/3 and 9/7 wavelets, probably a private avoption should be added with a name like wavelet or wavelet_type 
[11:15:23 CEST] <cehoyos> I'll send a patch in a moment that changes the default pred to 1: This makes the encoder lossless which is what people expect.
[11:16:03 CEST] <cehoyos> Or do you disagree? I was surprised to see that for both snow and j2k, "left" is 9/7, everything else is 5/3.
[11:16:44 CEST] <cehoyos> JEEBsv, Compn: Are we now doing the reviews for avconv? Are there really so few bugs?
[11:17:16 CEST] <cehoyos> So few bugs in FFmpeg, I mean...
[11:18:02 CEST] <JEEBsv> of course not, I just see the new demuxer as a positive thing and if someone has taken the effort to test it with some samples and linked some broken ones that's always great
[11:18:05 CEST] <JEEBsv> nobody's perfect
[11:19:12 CEST] <michaelni> cehoyos, if people prefer lossless wavelet as default (as long as no non lossless quality/qscale is set) then that should be default of course
[11:19:17 CEST] <cehoyos> Well, I remember also sending a link to broken samples: Did you forward them?
[11:19:56 CEST] <cehoyos> I wonder why these samples aren't a sufficient starting point for her (if she really needs help, I honestly wonder where she searched for relevant samples if not on our bug tracker)
[11:20:26 CEST] <JEEBsv> I haven't been looking at the ML :)
[11:20:27 CEST] <cehoyos> michaelni: The jpeg2000 encoder does not listen to qscale, or does it?
[11:21:03 CEST] <michaelni> s->lambda = s->picture->quality * LAMBDA_SCALE;
[11:21:08 CEST] <cehoyos> Just found it...
[11:21:33 CEST] <cehoyos> So what is the correct solution? And isn't the j2k encoder non-experimental if it can encode losslessly?
[11:22:57 CEST] <michaelni> if people feel its good enough then the experimental flag could indeed be removed
[12:09:50 CEST] <cehoyos> michaelni: No comments for "Only fail aac mpegts muxing if the first frame is broken"?
[12:17:15 CEST] <Compn> cehoyos : that was literally 10 minutes worth of work and barely 30 samples i looked at.
[12:18:00 CEST] <Compn> and i only did that because at least 3 developers in ffmpeg thought you and michaels' opinion of the demuxer was wrong
[12:18:38 CEST] <cehoyos> So why do you think they thought we (I?) were wrong?
[12:18:42 CEST] <cehoyos> I am curious...
[12:18:51 CEST] <cehoyos> And I still didn't see their samples;-(
[12:18:59 CEST] <Compn> they thought you were biased against any code from libav
[12:19:09 CEST] <cehoyos> Of course! That is why I tested it.
[12:19:22 CEST] <Compn> well they wanted you to post samples that you tested
[12:19:28 CEST] <cehoyos> Didn't i?
[12:19:34 CEST] <Compn> i dont remember any urls...
[12:19:51 CEST] <cehoyos> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174755.html
[12:20:10 CEST] <Compn> lol :)
[12:20:28 CEST] <Compn> well, you know, link to one or two , not a list ;D
[12:20:43 CEST] <cehoyos> And as said: I wonder what else could be the starting point, or do I miss something?
[12:21:13 CEST] <Compn> you are right, that is the starting point, and all asf/wmv/dvr-ms samples on samples repo. why those files werent all tested is a mystery to me.
[12:21:26 CEST] <cehoyos> I don't understand: Hendrik explained yesterday that he thinks one or two samples would make no difference (and I actually agree), so I posted all (or probably most) of the samples that fail.
[12:21:49 CEST] <cehoyos> So now somebody agrees that this is a mystery, thank you!
[12:22:06 CEST] <Compn> cehoyos : some devels dont like you or your opinions , i dont know why :(
[12:22:10 CEST] <cehoyos> Now the question is: Why do I not trust those people and everybody else seems to trust them?
[12:22:22 CEST] <Compn> i have not the answers.
[12:23:11 CEST] <nevcairiel> We just don't distrust them on principal alone like you do
[12:23:24 CEST] <cehoyos> Thank you for your enlightening explanations! Allow me to suggest once again to test a few (old!) tickets with status "new", we really need some help!
[12:23:56 CEST] <Compn> cehoyos : i had to drop everything and test the demuxer before it became some kind of huge flamewar...
[12:24:01 CEST] <Compn> but yes i need to test more tickets
[12:24:14 CEST] <cehoyos> nevcairiel: What difference does this make? Yes, I tested the demuxer because I consider them evil people, but how is my opinion about them relevant for the asf demuxer?
[12:24:16 CEST] <Compn> cehoyos : thank you for testing all of the trac that you do, its invaluable and you would be hard to replace.
[12:25:20 CEST] <cehoyos> Or are you saying that you believe that new demuxer is not the default because I (or somebody) doesn't like the avconv developers? That is very hard to understand...
[12:26:06 CEST] <Compn> cehoyos : nevcairiel is taking the position that libav does not use our code out of principal, so maybe he thinks you do the same thing. instead of reviewing for technical problems like ffmpeg has always done and always will do in the future.
[12:26:23 CEST] <Compn> at least thats the only way i can read his statements
[12:26:26 CEST] <cehoyos> As said, this is hard to understand...
[12:26:58 CEST] <cehoyos> (Except for the issue that I believe you cannot know what FFmpeg will do in the future...)
[12:27:06 CEST] <Compn> lol
[12:27:14 CEST] <Compn> got me there
[12:27:44 CEST] <durandal_170> I don't get it
[12:27:50 CEST] <cehoyos> What?
[12:28:30 CEST] <Compn> i dont get why libav has a malfunctioning bugreport system.
[12:28:38 CEST] <cehoyos> It is not malfunctioning
[12:28:44 CEST] <Compn> its on purpose?
[12:28:49 CEST] <cehoyos> And to the best of my knowledge it was never malfunctioning.
[12:28:57 CEST] <wm4> ffmpeg's bug report system is also malfunctioning
[12:29:17 CEST] <cehoyos> Afaict, this was the explanation that Reinhrad used (or was told to use) when Debian asked what happens with bug reports on avconv.
[12:29:38 CEST] <Compn> cehoyos : some devs dont like how you close their bugs. i've asked you in the past to leave bugreports alone if reported by Daemon404 and now i'm asking to leave wm4 bugs alone ;D
[12:29:40 CEST] <cehoyos> (I use the avconv bugreport system very regularly to find issues)
[12:29:54 CEST] <Compn> ah, so debian misinfo :\
[12:30:09 CEST] <Compn> remind me never to use debian/buntu again
[12:30:21 CEST] <cehoyos> I leave bug reports alone that I cannot reproduce (as said there are many with status "new"), I will continue to close incomplete or duplicate reports.
[12:31:02 CEST] <cehoyos> But please do replace me if you can do better, or suggest that somebody else replaces me: You would do me a favour!
[12:31:02 CEST] <durandal_170> Why are you doing all this?
[12:31:06 CEST] <cehoyos> What?
[12:31:17 CEST] <Compn> well sometimes devs just want to report a bug without full uncut output, is that so wrong, cehoyos ?
[12:31:27 CEST] <cehoyos> Yes, do you disagree?
[12:31:29 CEST] <nevcairiel> Your definition of incomplete is what's the problem, bug reports against the API just don't come with a uncut ffmpeg output
[12:31:45 CEST] <nevcairiel> Because ffmpeg.c is not involved
[12:31:48 CEST] <cehoyos> Do you remember me closing an "API bug report"?
[12:32:08 CEST] <cehoyos> I do close the ticket if no explanation is given if the issue can be reproduced with ffmpeg or not.
[12:32:53 CEST] <cehoyos> durandal_170: Of which asf demuxer are you in favour? Which samples did you test?
[12:33:33 CEST] <Compn> cehoyos : like i said, i cant replace you. i'm just trying to get other devs not to get so mad at you. i like your work. 
[12:33:51 CEST] <nevcairiel> Anyone that looked at the code should agree that the new one should be favored once it's been properly tested, the old one is just terrible spaghetti code
[12:34:05 CEST] <cehoyos> Hmm.
[12:34:07 CEST] <durandal_170> I tested several samples and mplayer asf demuxer is winner
[12:34:23 CEST] <Compn> should port mplayer asf to ffmpeg :)
[12:34:26 CEST] <Compn> gpl only!
[12:34:30 CEST] <Compn> :))))
[12:34:32 CEST] <cehoyos> nevcarirel: It is true that this is an argument I am quite strongly biased against.
[12:34:52 CEST] <wm4> <cehoyos> I do close the ticket if no explanation is given if the issue can be reproduced with ffmpeg or not. <- why do I have to go through the trouble to reverse-engineer ffmpeg.c just to see whether it can reproduce the problem
[12:34:55 CEST] <cehoyos> durandal_170: I don't disagree but how is this related to question?
[12:35:04 CEST] <wm4> or even to find out if it can
[12:35:14 CEST] <Compn> wm4 : just paste some trac urls that are closed
[12:35:19 CEST] <cehoyos> wm4: I believe you don't have to - there is irc and the user mailing lists.
[12:36:13 CEST] <cehoyos> But from my experience bug reports that I fail to reproduce are very rarely fixed: So either you are interested in the issue and epxlain how it can be reproduced or it won't be fixed.
[12:36:26 CEST] <cehoyos> (It will often be fixed accidentally of course.)
[12:37:14 CEST] <cehoyos> And this is of course not a decision I made, I am just descirbing my ten-year experience with bug fixing in FFmpeg.
[12:39:09 CEST] <durandal_170> there sure are bugs that you closed and I reopened
[12:39:55 CEST] <cehoyos> And there are more bugs that you closed and I reopened;-))
[12:47:35 CEST] <Compn> nevcairiel : also no one made the argument that the code shouldnt be replaced until it was tested. its just our definition of 'tested' is different i think
[12:48:53 CEST] <Compn> for instance, after its in libav for at least a year as the default, i think that would be a good test.
[12:49:11 CEST] <Compn> although not a complete test, a good one.
[12:49:32 CEST] <cone-130> ffmpeg 03Luca Barbato 07master:5bdfc17189e4: asf: Do not skip data streams
[12:49:33 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:8f9c39b3e8c9: avformat: rename asfdec.c to asfdec_f.c
[12:49:34 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:0d5a27c2b5a1: Rename asfdec-o.c to asfdec_o.c
[12:49:35 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:3cd6b6aa0f84: Merge commit '5bdfc17189e4ea63c6b46b6d5256852fcb409d68'
[12:49:35 CEST] <Compn> or a good start.
[12:49:54 CEST] <cehoyos> Compn: Who would test the new demuxer in the next year?
[12:50:00 CEST] <Compn> shhhh you :D
[12:50:31 CEST] <iive> what is the big deal with the asf demuxer?
[12:50:45 CEST] <cehoyos> That's what I would like to know!
[12:50:45 CEST] <wm4> iive: it was rewritten by evil people
[12:50:45 CEST] <Compn> iive : they didnt even test samples from samples.ffmpeg.org on it.
[12:51:09 CEST] <cehoyos> wm4: While this is true, it has no relevance whatsoever afaict.
[12:51:11 CEST] Action: Compn wonders why we even bother having a samples repo if no one uses it
[12:51:14 CEST] <cehoyos> (At least not for me!)
[12:51:39 CEST] <cehoyos> Well, I need it very much and I would be quite unhappy if it disappears.
[12:52:26 CEST] <iive> well, they rewrite stuff. what's the problem with it?
[12:52:46 CEST] <iive> (it=asf demuxer)
[12:52:52 CEST] <Compn> fails to decode bunch of files (all dvr-ms i think?)
[12:53:09 CEST] <Compn> er demux*
[12:53:20 CEST] <cehoyos> iive: No problem, it's their time!
[12:53:42 CEST] <Compn> crashes on go2meeting , although i didnt reproduce that
[12:54:18 CEST] <Compn> well i didnt test ffprobe
[12:55:10 CEST] <wm4> Compn, cehoyos: can you give me a list of links to files that currently fail with the new demuxer?
[12:55:22 CEST] <Compn> wm4 : the two mails i posted
[12:55:31 CEST] <Compn> are the ones i found to fail
[12:55:46 CEST] <Compn> i didnt test more than that
[12:55:54 CEST] <cehoyos> Link to my email is above (although since you answered I believe you read it)
[12:56:08 CEST] <Compn> they include the links
[12:56:12 CEST] <Compn> i can paste them to you if you want
[12:56:20 CEST] <Compn> i think someone posted them to the developer
[12:56:41 CEST] <Compn> who i now know the irc nick of, so i can now report them properly next time :P
[12:57:16 CEST] <Compn> but i probably wont spend more time on it, until at least all samples.ffmpeg.org are tested.
[12:57:26 CEST] <Compn> including carl's url which has all trac samples...
[12:58:23 CEST] <Compn> muh speghetti code
[13:00:42 CEST] <cehoyos> wm4: Is ticket 4499 valid? Wouldn't the time that gets spent in the beginning now (iiuc) have to be spent anyway? Or do I misunderstand?
[13:06:32 CEST] <cone-130> ffmpeg 03Luca Barbato 07master:1b4c468477f3: riff: Validate the wav header size before trying to parse it
[13:06:32 CEST] <wm4> cehoyos: looks like the usual complaint about how subtitles are not part of the normal processing
[13:06:33 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:6d9dfb1267d0: Merge commit '1b4c468477f3b8d372da8ef4e5405539ad9c1501'
[13:06:55 CEST] <wm4> that is, hardsubbing subtitles with lavfi
[13:07:40 CEST] <cehoyos> So it is a duplicate of ticket 2067?
[13:09:03 CEST] <wm4> probably
[13:15:18 CEST] <cone-130> ffmpeg 03John Högberg 07master:42bc768e5240: mpegts: Add jpeg2000 stream type
[13:15:19 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:088b410ea2ee: Merge commit '42bc768e5240ec01237ad2eb7c69b917158de258'
[13:23:59 CEST] <Compn> cehoyos : do you remember the bug where png files were being converted with lower luma? and colormatrix was the solution to set bt709 ? i cant seem to find that bug. trying to help mencoder user :P
[13:24:49 CEST] <cehoyos> https://trac.ffmpeg.org/search?q=colormatrix ? (No, I don't remember atm)
[13:25:05 CEST] <Compn> http://trac.ffmpeg.org/ticket/1582 is all i could find
[13:25:56 CEST] <Compn> cehoyos : ah, http://trac.ffmpeg.org/ticket/225
[13:27:33 CEST] <Compn> arg its reopened
[13:27:34 CEST] <Compn> ;P
[13:29:29 CEST] <cehoyos> Isn't 225 an issue with playback software?
[13:30:08 CEST] <Compn> i'm not sure i will have to review the samples.
[13:31:38 CEST] <cehoyos> Does anybody know John Högberg? We would really need such a sample, I had searched for it before...
[13:39:20 CEST] <cehoyos> Compn: Would you like to write him an email and ask him?
[13:40:36 CEST] <cehoyos> (Michael has already done so though)
[13:40:44 CEST] <Compn> cehoyos : https://trac.ffmpeg.org/ticket/2267
[13:43:46 CEST] <cone-130> ffmpeg 03James Zern 07master:e91f860ea74e: vp9/update_prob: prevent out of bounds table read
[13:50:05 CEST] <Compn> cehoyos : i think this explains the problem , https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images
[13:50:08 CEST] <Compn> Color space conversion and chroma sub-sampling
[13:50:09 CEST] <Compn>  By default when using libx264, and depending on your input, ffmpeg will attempt to avoid color subsampling. Technically this is preferred, but unfortunately almost all video players, excluding FFmpeg based players, and many online video services only support the YUV color space with 4:2:0 chroma subsampling. Using the options -pix_fmt yuv420p or -vf format=yuv420p will maximize compatibility.
[13:50:28 CEST] <Compn> or maybe not
[13:51:42 CEST] <cehoyos> That cannot be the issue when converting from h264 to mpeg4 (which only supports yuv420p, not yuvj420p).
[13:51:55 CEST] <cehoyos> I wonder if the issue is that the input files should be interpreted as yuv420p...
[13:52:31 CEST] <Compn> i remember yuvj420p was a solution to some problems on the mailing list
[13:52:44 CEST] <Compn> i give up for now, driving me crazy.
[13:54:39 CEST] <wm4> the yuvj formats are deprecated
[13:55:06 CEST] <Compn> great
[13:55:42 CEST] <Compn> [image2 @ 031c0360] Pattern type 'glob' was selected but globbing is not supported by this libavformat build
[13:56:02 CEST] <Compn> example on that page not support ed in muh nightly build ?
[13:56:51 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:5c047f3ad49c: avcodec/j2kenc: store libavcodec ident in a comment unless bitexact mode is used
[13:57:08 CEST] <nevcairiel> it uses functions from the C runtime for globbing, which may not exist on windows, i dunno
[14:01:01 CEST] <Compn> ah
[14:15:56 CEST] <[-T-]> high all :)
[14:16:01 CEST] <[-T-]> hi*
[14:16:24 CEST] <durandal_170> hi
[14:16:53 CEST] <[-T-]> using drocon11 qsv decoding implementation, I was able to do qsv decoding + qsv encoding :)
[14:17:09 CEST] <[-T-]> actually, I merged drocon11 qsvdec*.c files in master
[14:17:14 CEST] <[-T-]> and now it kinda works
[14:17:39 CEST] <[-T-]> though, i cannot use ffmpeg sw deinterlacing because I only have NV12 pixels :/
[14:25:04 CEST] <wm4> wat
[14:34:08 CEST] <[-T-]> wat wat ?
[14:44:10 CEST] <cehoyos> michaelni: Pushed three patches to github, please merge; no opinion about http://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174749.html ?
[15:09:01 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:8080688d0e3d: lavc/hapenc: Silence a warning for multithreaded encoding.
[15:09:02 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:e97ec65630d1: doc: Add jpeg2000 encoder documentation.
[15:09:03 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:0f5b99653120: lavc/j2kenc: Make jp2 output compatible with Kakadu.
[15:10:59 CEST] <cehoyos> michaelni: I also pushed a small configure patch to show the relation of snappy and hap, please merge.
[15:12:31 CEST] <michaelni> cehoyos, can you rebase this on top of master (without that trailing whitespace i removed from the previous commit)
[15:12:52 CEST] <cehoyos> Sorry...
[15:12:53 CEST] <michaelni> merge would be a mess otherwise
[15:12:58 CEST] <cehoyos> Where was it?
[15:13:01 CEST] <cehoyos> In the doc?
[15:13:09 CEST] <michaelni> yes
[15:14:30 CEST] <cehoyos> michaelni: Done, thank you!
[15:22:36 CEST] <cone-130> ffmpeg 03Carl Eugen Hoyos 07master:9295ee137ac9: configure: Mention hap encoding for --enable-libsnappy.
[16:04:13 CEST] <Compn> [-T-] : thanks for testing, but it looks like e veryone hates those patches.
[16:05:26 CEST] <michaelni> hate ? what patches ?
[16:06:25 CEST] <michaelni> qsv?, i dont hate clean qsv support
[16:07:20 CEST] <michaelni> the patches need some cleanup yes
[16:07:47 CEST] <[-T-]> yes ...
[16:07:52 CEST] <wm4> "some"
[16:08:12 CEST] <[-T-]> these patches are not fully functionnal
[16:08:52 CEST] <[-T-]> but at least, https://github.com/drocon11/ffmpeg-qsv/tree/qsvdec works much better than master
[16:09:00 CEST] <[-T-]> for qsv decoding ...
[16:09:15 CEST] <[-T-]> now I miss VPP .. without it, no deinterlacing
[16:09:35 CEST] <[-T-]> the dirty merge is here: https://github.com/TheTroll/ffmpeg
[16:10:21 CEST] <wm4> as if vpp deint works in any shape or form
[16:11:07 CEST] <[-T-]> what do you mean ?
[16:13:05 CEST] <cone-130> ffmpeg 03Michael Niedermayer 07master:0083c16605aa: avfilter/vf_transpose: Fix rounding error
[16:13:27 CEST] <wm4> [-T-]: I know xbmc struggled to get it to work
[16:13:31 CEST] <wm4> and so did I
[16:16:03 CEST] <[-T-]> quicksync VPP ?
[16:16:33 CEST] <Compn> michaelni : i wasnt talking about you, but j-b seemed to indicate his displeasure for those patches.
[16:16:42 CEST] <Compn> amongst other developers
[16:16:58 CEST] <j-b> of course
[16:17:01 CEST] <j-b> it's utter crap
[16:17:26 CEST] <[-T-]> is there a way, besides trans-pifmt-ing and hw deinterlacing, to deinterlace NV12 ?
[16:17:27 CEST] <j-b> as usual, with Intel, sorry to say
[16:18:10 CEST] <Compn> [-T-] : add nv12 to deint filters or maybe some opengl shader deint...
[16:18:28 CEST] <Compn> who has nv12 video anyway? :P
[16:18:40 CEST] <[-T-]> quicksync :)
[16:18:50 CEST] <Compn> it cant output normal pixfmt ?
[16:18:50 CEST] <[-T-]> it outputs and takes as input NV12
[16:19:00 CEST] <[-T-]> that or RGB4
[16:19:04 CEST] <Compn> blurgh
[16:19:32 CEST] <Compn> adding it to filters doesnt sound like that difficult of a task though
[16:19:33 CEST] <[-T-]> which makes it impossible to use the regular imgconvert deint
[16:19:36 CEST] <Compn> maybe i'm wrong...
[16:19:48 CEST] <[-T-]> not sure how to do that :)
[16:19:56 CEST] <[-T-]> if you have some spare time .. :p
[16:20:14 CEST] <Compn> make sample of interlaced nv12 so we can test with
[16:20:38 CEST] <Compn> preferably high motion of course
[16:20:45 CEST] <j-b> interlaced NV12 ?
[16:20:51 CEST] <j-b> Compn: all hardware decoder output NV12
[16:21:01 CEST] <j-b> Compn: it's the defacto standard
[16:21:08 CEST] <Compn> yes i know nv12 is what all video cards use
[16:21:14 CEST] <Compn> i just never seen it in an mkv file :P
[16:21:25 CEST] <j-b> raw? me neither.
[16:22:01 CEST] <j-b> for software, NV12 would be the standard too, if FFmpeg did not output I420
[16:22:02 CEST] <Compn> should ask intel to donate some hw to devs so we can test shit.
[16:22:06 CEST] <[-T-]> Compn: can I easily do that with a ffmpeg command line ?
[16:22:19 CEST] <[-T-]> using the h264_qsv decoder
[16:22:33 CEST] <Compn> probably not, i like making difficult requests [-T-]
[16:22:37 CEST] <[-T-]> :)
[16:22:47 CEST] <[-T-]> well, if i ask for .yuv output
[16:22:57 CEST] <[-T-]> will it transform pixels to YUV420 ?
[16:23:00 CEST] <Compn> probably yes
[16:23:52 CEST] <Compn> its just easier for some devs to work with a file instead of a hardware output...
[16:23:55 CEST] <Compn> is all i'm saying
[16:23:56 CEST] <[-T-]> if there an API i could use to dump the frames in a file ?
[16:24:14 CEST] <Compn> because some devs dont have intel hardware
[16:24:23 CEST] <Compn> or other... hardware
[16:24:55 CEST] <Compn> ffmpeg can probably just generate nv12
[16:24:58 CEST] <Compn> in software
[16:25:01 CEST] <Compn> just because.
[16:29:12 CEST] <[-T-]> yes
[16:29:36 CEST] <[-T-]> but anyway, getting the full QSV chain would be awesome
[16:29:49 CEST] <[-T-]> for live tv transcoding for instance
[16:40:41 CEST] <kierank> planar is just a historical oddity
[16:40:45 CEST] <kierank> from avisynth et al
[16:40:57 CEST] <kierank> most of the world uses packed chroma (x264 included)
[16:41:36 CEST] <wm4> planar is easier to handle
[16:41:44 CEST] <wm4> nv12 is just a wtf cross between packed and planar
[16:41:55 CEST] <wm4> a sane world would use s 4:4:4 32 bit packed format only
[16:42:53 CEST] <kierank> packed is faster
[16:42:57 CEST] <kierank> cf x264
[16:44:01 CEST] <wm4> by how many percent?
[16:44:23 CEST] <nevcairiel> low single digits, but still, its not like nv12 is a complex format
[16:53:29 CEST] <BtbN> Bullshit of the day: nvenc is better than x264 because it produces smaller files at the same bitrate.
[16:54:13 CEST] <nevcairiel> heh
[16:54:32 CEST] <kierank> loool
[16:54:49 CEST] <BtbN> According to the comments on that YouTube video, you also need at least an i5 for NVENC to perform propperly, and you might want to overclock it a bit.
[18:21:41 CEST] <durandal_170> how much eedi3 is useful?
[18:22:30 CEST] <JEEBsv> nnedi3 you mean?
[18:22:58 CEST] <nevcairiel> there is also eedi .. there is a whole long family of algorithms of the edi kind
[18:24:23 CEST] <JEEBsv> yeah
[18:24:33 CEST] <JEEBsv> just that usually people use nnedi3 for general usage
[18:43:20 CEST] <durandal_170> but that one use 20mb data
[19:34:54 CEST] <philipl> wait, so libmxf works on linux? 
[19:35:10 CEST] <BtbN> Intel implemented it as a wrapper on top of libva there...
[19:35:16 CEST] <philipl> so there's vaapi, yami and mfx on linux?
[19:35:22 CEST] <BtbN> exactly
[19:35:44 CEST] <BtbN> but only libva actualy interacts with the hardware
[19:35:49 CEST] <BtbN> everything else just sits on top of it
[19:36:02 CEST] <philipl> but the vaapi api is so terrible that no one will implement direct support in ffmpeg
[19:36:16 CEST] <philipl> so we get these wrapper patches from intel.
[19:36:31 CEST] <BtbN> Well, nice thing about mfx/qsv is, it also works on windows.
[19:37:10 CEST] <philipl> sure. this patch set then makes the raw vaapi decoder redundant?
[19:37:21 CEST] <BtbN> When i asked in the intel channel about improving the libva encoding api instead, i got called a troll who has obviously never had any experience with hardware encoders.
[19:37:43 CEST] <philipl> hah.
[19:38:12 CEST] <BtbN> "you have to manualy generate parts of the NAL and pass it to libva" "That's how all hardware encoders work"
[19:38:27 CEST] <philipl> ok. so yami was rejected for being a useless wrapper. qsv is ok on linux because we have to have it for windows anyway.
[19:38:41 CEST] <BtbN> currently, QSV is windows-only i think
[19:38:41 CEST] <philipl> so beautiful.
[19:38:48 CEST] <philipl> until now 
[19:38:52 CEST] <BtbN> without that patch, it doesn't work on linux.
[19:38:56 CEST] <philipl> right
[19:38:58 CEST] <BtbN> And i'm not exactly a fan of that.
[19:39:09 CEST] <BtbN> (Of that patch)
[19:39:37 CEST] <philipl> It could be made non shitty I guess.
[19:40:07 CEST] <BtbN> I think the main point of that patch is that there is no vaapi hwaccell in the ffmpeg cli tool
[19:40:19 CEST] <BtbN> With the qsv decoder, it could use hw decoding on intel hw
[19:40:24 CEST] <philipl> right
[19:40:35 CEST] <philipl> and that's desirsble.
[19:40:38 CEST] <BtbN> I'd much rather see ffmpeg_vaapi.c instead
[19:41:06 CEST] <philipl> i assume that would be horrible to write, hence no one doing it.
[19:41:22 CEST] <BtbN> libva is not that terrible for decoding
[19:41:23 CEST] <wm4> <philipl> ok. so yami was rejected for being a useless wrapper.  <- not really... many were against it, but in the end the guy didn't post a new patch with all flaws fixed
[19:41:45 CEST] <BtbN> Well, with all those complaints he got, that's not too surprising.
[19:41:55 CEST] <wm4> BtbN: I was thinking about simplifying the ffmpeg vaapi api in the same way it was done for vdpau
[19:42:01 CEST] <philipl> true, he walked away, but there were plenty of objections to the concept.
[19:42:22 CEST] <BtbN> i never dealt with the ffmpeg/vaapi interop
[19:42:56 CEST] <philipl> does anything use it? __gb__ never got his mplayer hooks merged.
[19:43:05 CEST] <philipl> i guess kodi?
[19:43:09 CEST] <BtbN> I think xbmc does
[19:43:19 CEST] <BtbN> at least it did when i was still trying to add VPP support for hw deinterlacing
[19:43:47 CEST] <BtbN> Which btw. was finaly done a few weeks ago(It was over a year ago when i gave up)
[19:43:53 CEST] <philipl> heh.
[19:45:59 CEST] <BtbN> I got my intel HTPC because of the great open source support
[19:46:15 CEST] <BtbN> And ended up sticking an nvidia card in there, because their proprietary drivers actualy work
[19:46:21 CEST] <philipl> so if this qsv stuff goes in, there's an argument to deprecate the vaapi stuff.
[19:46:32 CEST] <BtbN> Not realy
[19:46:34 CEST] <philipl> a familiar story.
[19:46:45 CEST] <BtbN> no distro is ever going to package any qsv libraries
[19:46:55 CEST] <philipl> libmxf is a disaster?
[19:47:06 CEST] <BtbN> You need to register at intel to download it
[19:47:19 CEST] <BtbN> And it's closed source
[19:47:25 CEST] <philipl> *sigh*. so as broken as nvenc.
[19:47:58 CEST] <philipl> i poked some people at nvidia about improving the nvenc header licence. maybe that will pan out.
[19:48:34 CEST] <BtbN> I realy need to get some nvidia maxwell card, but they just won't release GT cards...
[19:49:13 CEST] <BtbN> There's a bunch of maxwell stuff i'd like to add to nvenc
[19:51:07 CEST] <philipl> such as? Most of it seemed behind the scenes.
[19:51:35 CEST] <BtbN> primarily yuv444p lossless encoding
[19:51:45 CEST] <philipl> Mm. right.
[19:52:08 CEST] <philipl> Well, I'm sitting on a 960 and a 980 here ;-)
[19:52:38 CEST] <philipl> But i don't want to steal your fun. and dont hsve time.
[19:53:03 CEST] <BtbN> It shouldn't be much work. Needs a static init function, which sets the supported pixel formats to yuv444p when the lossless preset is selected, and limits it to the same SM level as it does for hevc
[19:54:14 CEST] <BtbN> I need a new card for my HTPC anyway, as the current one has no slot cover plate, so it falls out of its PCIe slot when i move the PC the slightest bit
[19:54:29 CEST] <BtbN> But nvidia just doesn't want to release new HTPC cards
[20:03:52 CEST] <philipl> yeah. all the new low end cards listed in the last driver release are using recycled chips. no sign of a gm208 yet.
[20:05:20 CEST] <wm4> BtbN, philipl: mpv uses vaapi and vpp too (the latter of which probably doesn't work)
[20:05:52 CEST] <BtbN> vpp is a mess
[20:06:11 CEST] <BtbN> and if you complain, you get told that it works in gstreamer
[20:06:35 CEST] <BtbN> and after days of trying to get into that code, which intenaly wraps the api two times, you find out that it actualy doesn't work
[20:08:19 CEST] <wm4> 2 times?
[20:09:00 CEST] <BtbN> It first has wrappers around basicaly every libva function. And then it wrapts that into some intermediate api, which is then used by the actual gstreamer module
[20:09:47 CEST] <BtbN> So even if you look at the intermediate api, you still have to lookup most of what it does
[20:11:06 CEST] <wm4> awesome
[20:11:08 CEST] <wm4> but why
[20:11:25 CEST] <BtbN> I have no idea
[20:11:34 CEST] <BtbN> propably someone else wrote each wrapper
[20:13:40 CEST] <philipl> if we keep wrapping it, maybe it won't stink.
[20:14:32 CEST] <BtbN> I actualy already wrote a "working" libva-only h264 encoder
[20:14:41 CEST] <BtbN> But it's P-Frame only, and doesn't have propper rate control
[20:14:51 CEST] <nevcairiel> stink always manages to find a way to get through all the wrapping
[20:15:07 CEST] <BtbN> The base api is just incomplete
[20:15:14 CEST] <BtbN> to make the lives of the people developing it easier
[20:18:14 CEST] <philipl> The fact that it even lets you write that kind of partial implementation is damning.
[20:36:32 CEST] <jamrial> hevc and mpeg2 qsv encoders on libav ml
[20:36:52 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:330863c9f19a: avcodec/h264_slice: Use w/h from the AVFrame instead of mb_w/h
[20:46:48 CEST] <rcombs> jamrial: still windows-only and nonredistributable?
[20:47:44 CEST] <nevcairiel> you can probably use them with lucas libmfx thing, which basically includes the libva thing on our ML, just in separate code
[20:49:10 CEST] <rcombs> hmm, I got the impression there as a license issue with libmfx but now that I look, the Zeranoe builds have it
[20:49:51 CEST] <nevcairiel> I wanted to investigate enabling qsv encoding for a distributed build, but I was told it breaks XP support of the binary, I need to confirm if I can do that yet
[20:49:53 CEST] <nevcairiel> damn $work =p
[20:50:45 CEST] <rcombs> >XP >2015.5
[20:50:48 CEST] <jamrial> also, mingw-w64 apparently added the missing bits to get d3d11va hwaccel working on trunk
[20:51:03 CEST] <jamrial> mingw-w64 v5 is going to be nice
[20:51:27 CEST] <nevcairiel> > mingw-w64 trunk, would rather shoot myself into the foot, and I'm still healing from the last foot injury!
[20:52:19 CEST] <jamrial> hey, nobody forces you to use it. just wait for it to be branched and tagged :p
[20:52:50 CEST] <jamrial> msys2's gcc package uses mingw-w64 trunk for some reason, so i'm using that
[20:53:06 CEST] <nevcairiel> I dont think they actually really branch from trunk, they slowly merge a whole lot of stuff into the stable branch and tag/branch from that
[20:53:14 CEST] <nevcairiel> well maybe for a major version like 5 they do
[20:53:15 CEST] <jamrial> expect when i need to compile something that doesn't depend on a billion dlls, where i use a custom build static gcc using v4
[20:53:16 CEST] <nevcairiel> what do i know
[20:53:23 CEST] <jamrial> *except
[20:53:37 CEST] <nevcairiel> I always use my own gcc builds
[20:53:42 CEST] <nevcairiel> in fact, just finished 4.9.3
[20:53:54 CEST] <nevcairiel> (if anyone cares: http://files.1f0.de/mingw/mingw-w64-gcc-4.9.3-stable-r14.7z)
[20:55:01 CEST] <nevcairiel> I'm undecided if I should care about d3d11va .. there is one or two things I might like having, but I'm told its a bitch to setup, more boilerplate than dxva2
[20:55:56 CEST] <jamrial> my custom gcc is a recent snapshot from the 5.1 branch, which i will replace with 5.2.0 as soon as it comes out in two weeks
[20:56:07 CEST] <nevcairiel> I guess more like 3
[20:56:13 CEST] <nevcairiel> they never hit their projected release dates
[20:56:13 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:3ad678a85b96: fate: Update ac3 test to the new request_channel_layout option
[20:56:14 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:a9aed08fa4e9: Merge commit '3ad678a85b96fc5fecd60e3d3a31ca5ffc89d67f'
[20:56:42 CEST] <jamrial> is it Win8 only for that matter, or works also on Vista/7?
[20:57:24 CEST] <nevcairiel> d3d11? Thats a bit .. odd. Its documented to only work on  8+, but it also seems to work on 7 to some degree
[20:57:33 CEST] <jamrial> configuring ffmpeg with _WIN32_WINNT=0x0600 (AKA, Vista) seems to enable it using mingw-w64 trunk
[20:58:34 CEST] <nevcairiel> mingw often has those version guards wrong, but in this case its not, d3d API is not protected by that at all
[20:58:42 CEST] <nevcairiel> even msvc SDK has them unprotected
[20:59:21 CEST] <nevcairiel> win7 has those APIs, but if the documentation is right it should result in runtime init failures, but apparently, it doesn't when you request a certain profile
[20:59:46 CEST] <nevcairiel> its a bit contradictory in the docs
[21:01:52 CEST] <cone-342> ffmpeg 03Paul B Mahol 07master:185e76976e82: avfilter/vf_ssim: fix some cosmetics issues
[21:02:13 CEST] <nevcairiel> so TL;DR, it s eems to work on 7 at least
[21:02:15 CEST] <nevcairiel> vista not sure
[21:02:26 CEST] <jamrial> nobody cares about vista anyway :p
[21:02:39 CEST] <jamrial> but Win7 looks like will be the new XP
[21:02:41 CEST] <nevcairiel> luckily  avcodec doesnt actually need to link against anything d3d11-wise
[21:02:56 CEST] <nevcairiel> so no runtime deps on d3d11 being available from that side
[21:04:17 CEST] <nevcairiel> people will irrationally stick to their long-time OS no matter what
[21:04:19 CEST] <JEEBsv> jamrial: we'll see how much traction win10 gets with the free upgrades and seemingly rolling thing
[21:04:28 CEST] <nevcairiel> but I think win10 might have the right sauce to win a bunch of them over
[21:04:30 CEST] <JEEBsv> although sure, corps will stay on some LTS-like thing
[21:04:42 CEST] <JEEBsv> (including one of the LTS versions of win10)
[21:05:54 CEST] <jamrial> assuming dx12 is even half as good as it's being sold as, i'm making the switch
[21:07:04 CEST] <nevcairiel> DX12 and the other low-overhead APIs should deliver, assuming the games actually use them properly to multi-thread more
[21:19:23 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:3e3056f2a020: h264: Allow stream and container cropping at the same time
[21:19:24 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:2e9dcb82e5d5: Merge commit '3e3056f2a020dd77efdf379dbd4c06a65b4a499a'
[21:26:09 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:303ec065a904: aic: Fix slice size computation for widths multiples of 32 macroblocks
[21:26:10 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:4ff0c61ba800: Merge commit '303ec065a90498c29d384b4add2ac626bc38d5eb'
[22:01:32 CEST] <cone-342> ffmpeg 03Luca Barbato 07master:e95c7a61852c: mov: Preserve the metadata even when bit-exactness is requested
[22:01:33 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:cfcb9f5e3628: Merge commit 'e95c7a61852cc5b9ce5445ff034b87553e61958a'
[22:06:05 CEST] <llogan> damn it. i was hoping ffmpeg-trac ML wouldn't break URLs
[22:10:01 CEST] <cone-342> ffmpeg 03Luca Barbato 07master:6f4cd33efb5a: cosmetic: Reformat ff_h263_decode_mba
[22:10:02 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:5585da7c5e47: Merge commit '6f4cd33efb5a9ec75db1677d5f7846c60337129f'
[22:16:38 CEST] <lglinskih_> wm4, kierank: can you review my first version of seek-test? Did I correctly understand what you want?=) https://github.com/lglinskih/FFmpeg/blob/59715a3353eaa319529d8c3a11dd93fe8795fcf2/tests/api/api-seek-test.c
[22:18:36 CEST] <wm4> looking
[22:19:29 CEST] <wm4> lglinskih_: duplicating the code for decoding before and after the seek isn't really ideal
[22:19:46 CEST] <wm4> lglinskih_: it also should be able to perform multiple seeks, each with possibly different parameters
[22:20:00 CEST] <wm4> and each time, a different number of packets might be read and decoded
[22:27:06 CEST] <cone-342> ffmpeg 03Luca Barbato 07master:0a49a62f9987: h263: Always check both dimensions
[22:27:07 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:2a227fe8799e: Merge commit '0a49a62f998747cfa564d98d36a459fe70d3299b'
[22:32:13 CEST] <lglinskih_> wm4: now it's actually reads and decodes a different number of packets, but it starts reading only from the first frame
[22:32:50 CEST] <lglinskih_> wm4: next step -- seek not only to 0
[22:36:32 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:0bfab80a0d9f: h264_sei: Group error check outside the switch block
[22:36:33 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:8e6c5c432236: Merge commit '0bfab80a0d9fce0180e8aa2a947267f89b725091'
[23:07:49 CEST] <cone-342> ffmpeg 03Vittorio Giovara 07master:271ce76d317c: h264: Parse registered data SEI message and AFD value
[23:07:50 CEST] <cone-342> ffmpeg 03Michael Niedermayer 07master:7e9c7b623f05: Merge commit '271ce76d317c5432e151216cf23f12b77ed6cb7e'
[23:23:15 CEST] <cone-342> ffmpeg 03Nicolas DEROUINEAU 07master:04a68f43488c: avcodec/h264: Greenmetadata SEI parsing
[23:33:43 CEST] <wm4> nevcairiel, Daemon404: remind me, can DLLs export variables?
[23:35:10 CEST] <Plorkyeran> yes
[23:35:13 CEST] <Plorkyeran> but please don't do that
[23:35:28 CEST] <wm4> ffmpeg already seems to export av_util_ffversion
[23:36:22 CEST] <nevcairiel> yeah its possible, but its rather ugly to import them
[23:36:25 CEST] <Daemon404> we had purposely removd all exported variables
[23:36:35 CEST] <wm4> too bad they're back!
[23:36:51 CEST] <wm4> added in december 2014
[23:39:16 CEST] <wm4> it lacks av_export, which is apparently required for variables
[23:39:39 CEST] <nevcairiel> there is still a few left, btw
[23:39:43 CEST] <nevcairiel> avpriv mostly
[23:41:03 CEST] <nevcairiel> codec data shared between decoder and demuxer
[23:44:35 CEST] <kierank> lglinskih_: looks ok as long as you seek to somewhere not 0 :)
[23:46:56 CEST] <kierank> I'm not 100% sure how you're going to make reference files
[23:48:34 CEST] <wm4> hm, I also wonder how to confirm the results
[23:48:53 CEST] <wm4> when seeking in a player, you often get visual corruption etc. if something is wrong
[23:50:44 CEST] <BBB> even if something is not wrong you may still get visual corruption
[23:50:50 CEST] <BBB> just try seeking in a hevc/annexb stream
[23:51:13 CEST] <nevcairiel> one could argue  something is wrong then =p
[23:52:27 CEST] <BBB> I suppose
[23:52:41 CEST] <BBB> I mean, when an asteroid hits earth and all dinosaurs die, you could claim something is wrong
[23:52:59 CEST] <BBB> but I dont think that suggests theres a mechanism in place to prevent it - its the expected behaviour
[23:53:13 CEST] <nevcairiel> h264 knows how to prevent it
[23:53:20 CEST] <BBB> yeah, hevc doesnt do that :(
[23:54:30 CEST] <BBB> brb
[23:59:31 CEST] <wm4> could someone coerce Stephan Holljes into posting proper patches?
[23:59:47 CEST] <wm4> that is, using git send-email
[23:59:57 CEST] <nevcairiel> who now
[00:00:00 CEST] --- Wed Jul  1 2015