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

[burek]

[01:17:56 CEST] <cone-948> ffmpeg 03Alex Agranovsky 07master:9b10ae5727c7: avformat/format: Remove parameters from mime type before comparission for probing
[01:35:53 CEST] <cone-948> ffmpeg 03Ronald S. Bultje 07master:02064d6b7bb9: libvpxdec: apply RGB to 444P16 instead of 422P16.
[02:29:07 CEST] <cone-948> ffmpeg 03Simon Thelen 07master:b84232694ef0: lavf/webvttenc: Require webvtt file to contain exactly one WebVTT stream.
[02:37:16 CEST] <cone-948> ffmpeg 03Ronald S. Bultje 07master:4b66274a86dd: vp9: save one (PSIGNW) instruction in iadst16_1d sse2/ssse3.
[03:44:33 CEST] <cone-948> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:9a168e9371d6: ffserver: unify fail path in socket_open_listen()
[03:44:34 CEST] <cone-948> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:2580395e1cd2: ffserver: unify exit path in http_server()
[03:44:35 CEST] <cone-948> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:314bc20d7a4b: ffserver: remove redundant comment, clarify another one
[04:27:58 CEST] <cone-948> ffmpeg 03James Almer 07master:d5f8a642f6eb: x86: port PSIGNW to cpuflags
[04:59:46 CEST] <Zeranoe> Are there plans to use OpenCL for other aspects?
[05:05:21 CEST] <jamrial> BtbN was interested in it, but not sure if to write something
[05:08:36 CEST] <Zeranoe> IS OpenCL really only suited for filters, or could it be implemented into encoding/decoding 
[05:14:11 CEST] <philipl> BtbN: Added two small comments. Otherwise looks fine.
[05:16:08 CEST] <jamrial> Zeranoe: it can be used for decoders. I know there's at least one hevc decoder out there for opencl
[05:16:16 CEST] <philipl> ignore that. old repeat.
[10:53:45 CEST] <wangchan> hey everyone
[10:53:50 CEST] <wangchan> i need some help please..
[10:53:52 CEST] <wangchan> http://pastebin.com/6jjSWF2d
[10:54:21 CEST] <wangchan> i am trying to add an unlink function into sengment.c because it creates the files and maintains the segmetns but wont delete the ts once it clears it from the .m3u8
[10:54:44 CEST] <wangchan> i want to basically call the unlink function in order to have the segmenter remove the .ts that is no longer needed
[10:54:47 CEST] <wangchan> any help ?
[10:58:21 CEST] <c_14> wangchan: if I were you I'd look at how the hls_delete_segments flag is used in hlsenc.c and copy/adapt that for segment.c
[13:00:29 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:e336c51e6ffc: pixdesc: Consistently order components
[13:00:29 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:ba42096d9acb: Merge commit 'e336c51e6ffcdb93fbcf3c6153d378400608526b'
[13:00:42 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:c7ed26ad6035: pixdesc: Add missing alpha flag for yuva420p9be
[13:00:43 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:6210a64822a3: Merge commit 'c7ed26ad6035793c7212c17545b0ded18b72db69'
[13:02:24 CEST] <cone-264> ffmpeg 03Ronald S. Bultje 07master:2563a33856eb: vp9: re-initialize internal buffers on bpp change also.
[13:02:25 CEST] <cone-264> ffmpeg 03Ronald S. Bultje 07master:a30a8beeb3dc: vp9: Fix emu[] edge overflow conditions for >8bpp/non-420.
[13:03:51 CEST] <cone-264> ffmpeg 03Luca Barbato 07master:7b02cb29d9d6: pixdesc: Document the component order
[13:03:52 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:eadf6cb2c4e8: Merge commit '7b02cb29d9d60cdd5ef321043d11d02023e7dc8f'
[13:06:45 CEST] <cone-264> ffmpeg 03Luca Barbato 07master:41ed749fe987: ogg: Do not try to use the parser if it is not present
[13:06:46 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:09c15eac3e8c: Merge commit '41ed749fe987e60b0485fa721ad869590651324d'
[13:14:44 CEST] <cone-264> ffmpeg 03Luca Barbato 07master:9b5a4a9cce30: mmvideo: Make sure the rle does not write over the frame boundaries
[13:14:45 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:c0746716215b: Merge commit '9b5a4a9cce3042558e107ae1ed30d9bf3d867a35'
[13:22:11 CEST] <cone-264> ffmpeg 03Luca Barbato 07master:db53a2306f62: jpeg2000: Do not warn about known and skippable markers
[13:22:12 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:6e611a183906: Merge commit 'db53a2306f62f05faa67e6f3c60ee55a9b8e4776'
[13:28:01 CEST] <cone-264> ffmpeg 03Luca Barbato 07master:5788623d29c3: jpeg2000: Split codeblock decoding from the main tile decoding
[13:28:02 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:84d04a0dfa05: Merge commit '5788623d29c3e806a7879210986110aced758dc2'
[13:30:58 CEST] <cone-264> ffmpeg 03wm4 07master:b84675d63aae: mmaldec: hack against buffering problems on broken input
[13:30:59 CEST] <cone-264> ffmpeg 03wm4 07master:6b652c0273d7: mmaldec: fix problems with flush logic
[13:31:00 CEST] <cone-264> ffmpeg 03wm4 07master:b7ab6e18eeca: mmaldec: disable timestamp interpolation
[13:31:01 CEST] <cone-264> ffmpeg 03wm4 07master:87a051f97633: lavc: allow asynchronous decoders to return correct pkt_dts values
[13:31:02 CEST] <cone-264> ffmpeg 03wm4 07master:994045972019: mmaldec: fix pkt_dts determination
[13:31:03 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:886f0f5ff1e4: Merge commit 'b84675d63aaede8f6944b901250a10456c5477e6'
[13:31:04 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:45ae2997858d: Merge commit '6b652c0273d79f2e0c52ad91450bd0737cf3c8a6'
[13:31:05 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:30fb54c23f52: Merge commit 'b7ab6e18eecad43593ad2a0e9fc9eba7f24751cb'
[13:31:06 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:264ff3dd2e5c: Merge commit '87a051f97633010f71dfc1d23d806856499bf231'
[13:31:07 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:e75b2e9c4b91: Merge commit '99404597201911de90cff2ef85f2d44176d39147'
[13:31:30 CEST] <cone-264> ffmpeg 03James Almer 07master:1e0b8bf0b3b3: travis: fix dependencies
[13:31:31 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:33be39efe313: Merge commit '1e0b8bf0b3b3b4247fb21e9839af342ae879607c'
[13:32:09 CEST] <BtbN> travis? oO
[13:42:03 CEST] <JEEB> the automatic build/test service
[13:42:47 CEST] <JEEB> I think they also let you check if your pull requests compile pretty much automagically in say, github
[14:19:06 CEST] <cone-264> ffmpeg 03Rostislav Pehlivanov 07master:a83a8d70681a: aacenc_tns: redo coefficient quantization and decision making
[14:19:07 CEST] <cone-264> ffmpeg 03Rostislav Pehlivanov 07master:7b7866387bab: aacenc_tns: encode coefficients directly and reenable compression
[14:19:08 CEST] <cone-264> ffmpeg 03Rostislav Pehlivanov 07master:3381d9267109: aacenc_tns: readjust values for new TNS decision making
[14:19:09 CEST] <cone-264> ffmpeg 03Rostislav Pehlivanov 07master:1e75bee3d603: fate: readjust AAC encoder TNS test
[14:47:59 CEST] <cone-264> ffmpeg 03Tobias Rapp 07master:141637002767: avformat/avienc: add muxer option "write_channel_mask"
[15:09:31 CEST] <nevcairiel> sounds like atomnuker is having fun fighting with what the specs say and what actually makes sense. :)
[15:14:54 CEST] <atomnuker> what the specifications say:
[15:15:00 CEST] <atomnuker> "A suitable choice is to cover a frequency range from 1.5 kHz to the uppermost possible scalefactor band with one filter."
[15:15:04 CEST] <atomnuker> what faac does:
[15:15:30 CEST] <atomnuker> "one filter is what god said to me and that's what I'll put in"
[15:15:39 CEST] <atomnuker> what fdk_aac does:
[15:16:11 CEST] <atomnuker> "hm, oh wow, look at the time, gotta use TNS, I'll just put 2 filters in there of random order"
[15:16:32 CEST] <JEEB> :D
[15:16:41 CEST] <atomnuker> It's random looking at the bitstream it makes
[15:16:41 CEST] <cone-264> ffmpeg 03Vittorio Giovara 07master:6064f697a321: lavc: Enable side data only packets by default
[15:16:42 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:580c4fc98a21: Merge commit '6064f697a321174232a3fad351afb21150c3e9e5'
[15:17:27 CEST] <cone-264> ffmpeg 03Vittorio Giovara 07master:f00f6d538dcb: lavc: Sanitize header inclusion guards
[15:17:28 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:95f92b251334: Merge commit 'f00f6d538dcbaa122eb5e2784f41f4a299296b7b'
[15:17:58 CEST] <cone-264> ffmpeg 03Hendrik Schreiber 07master:1b2412f50185: lavc: Fix compilation with --disable-everything --enable-parser=mpeg4video
[15:17:59 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:73e9f04ea5e8: Merge commit '1b2412f50185447da4212f65f06e8d72a6daf06e'
[15:18:20 CEST] <cone-264> ffmpeg 03Alexandra Hájková 07master:c0a49077ea4f: asfdec: add more checks for size left in asf packet buffer
[15:18:21 CEST] <cone-264> ffmpeg 03Hendrik Leppkes 07master:de969904b18b: Merge commit 'c0a49077ea4ff3a0ad30b9e33f1bb06ba9112aaa'
[15:19:12 CEST] <nevcairiel> so.. a couple more weeks and we beat fdk_aac?
[15:19:12 CEST] <nevcairiel> :D
[15:20:07 CEST] <atomnuker> depends
[15:20:20 CEST] <atomnuker> how do we convert a couple more weeks into Claudio time?
[15:21:30 CEST] <atomnuker> nevcairiel: were you the one using the encoder to stream MPEG2 (which doesn't support PNS)?
[15:21:36 CEST] <nevcairiel> yes
[15:21:50 CEST] <nevcairiel> honestly i'm not 100% sure what would really happen
[15:22:03 CEST] <nevcairiel> I just know that some devices refuse to accept the stream if the ADTS header indicates mpeg4
[15:22:19 CEST] <nevcairiel> so i figure, better not use mpeg4 coding tools
[15:24:52 CEST] <cone-264> ffmpeg 03Peter Belkner 07master:1d2beb686ed4: configure: fix build on mingw64 target with msys2
[15:25:19 CEST] <BBB> when is the meetinh? in 35 min?
[15:25:30 CEST] <nevcairiel> one hour more i th ink
[15:25:49 CEST] <JEEB> 1500 UTC
[15:26:00 CEST] <BBB> I dont know utc
[15:26:02 CEST] <BBB> I know est
[15:26:17 CEST] <Loriker> in 35 mins
[15:26:51 CEST] <nevcairiel> 1500 utc is in 1.5 hours
[15:27:05 CEST] <RiCON> utc doesn't have summer time
[15:27:07 CEST] <JEEB> yeah, because otherwise UK would be just two hours behind me
[15:27:08 CEST] <Loriker> erm yes
[15:27:08 CEST] <nevcairiel> http://time.is/en/UTC
[15:27:12 CEST] <Loriker> sry, we have summer time :)
[15:27:24 CEST] <JEEB> oh
[15:27:35 CEST] <JEEB> so UK is two hours behind, funky
[15:27:45 CEST] <nevcairiel> UK has summer time, but UTC does not =p
[15:27:54 CEST] <Loriker> yes
[15:28:07 CEST] <JEEB> being so high on the map I'd love not having summer/winter time
[15:28:37 CEST] <nevcairiel> they should get rid of the concept, it never actually did serve the purpose it was invented for
[15:28:52 CEST] <Loriker> [x]
[15:28:53 CEST] <JEEB> I really liked living in Japan regarding that, the time was static
[15:29:02 CEST] <JEEB> didn't move around twice a year
[15:29:05 CEST] <iive> nevcairiel: +1
[15:29:09 CEST] <nevcairiel> its not really something i think about much though
[15:29:11 CEST] <nevcairiel> who cares really!
[15:29:12 CEST] <nevcairiel> :D
[15:29:20 CEST] <RiCON> just something to think about two times a year
[15:29:23 CEST] <JEEB> yeah, since most people generally have automagic clocks
[15:29:32 CEST] <JEEB> in their internet-connected things
[15:29:45 CEST] <RiCON> one night you sleep too less, one night you sleep one more hour
[15:29:54 CEST] <nevcairiel> i just sleep the same time
[15:30:02 CEST] <nevcairiel> getting up is just at a different hour
[15:30:33 CEST] <JEEB> i guess you just have some old analogue thing that doesn't try to adjust handling waking up
[15:30:37 CEST] <iive> RiCON: and one week everybody is groggy 
[15:31:12 CEST] <JEEB> because by defualt most things nowadays just switch the time zone for you so you wake up at the same effective time point in all time zones
[15:31:30 CEST] <JEEB> uhh, I meane time zone as in the summer/winter time
[15:31:34 CEST] <JEEB> *meant
[15:37:41 CEST] <RiCON> oh cool, no more need for --target-os=mingw32
[15:42:33 CEST] <nevcairiel> a lot of projects seem to fail with msys2
[15:43:05 CEST] <nevcairiel> i had to pass --host, --target and --build to a whole bunch of autotools projects which worked flawlessly without such shenangians on old msys
[15:46:50 CEST] <saste> yo
[15:47:22 CEST] <saste> just created the #ffmpeg-meeting channel
[15:47:47 CEST] <saste> please join if you want to attend the IRC meeting which will start at 15 UTC
[15:49:29 CEST] <saste> \topic
[16:47:34 CEST] <iive> since I know some people here do profiling and benchmarking, I think this might be useful to them. Just a nice visualisation tool:
[16:47:44 CEST] <iive> http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
[17:05:27 CEST] <atomnuker> wm4: the meeting on #ffmpeg-devel has started, could you join?
[17:05:59 CEST] <saste> all: the ffmpeg IRC meeting began a few minutes ago, please join as soon as possible if you want to attend the IRC meeting
[17:06:07 CEST] <saste> the channel is #ffmpeg-meeting
[17:07:28 CEST] Action: saste pokes wm4
[18:23:25 CEST] <cehoyos> Hi! I wasn't available earlier, what did I miss?
[18:23:42 CEST] <c_14> cehoyos: #ffmpeg-meeting
[18:23:47 CEST] <saste> cehoyos, => #ffmpeg-meeting, we're at point #2
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:4f926a108851: avcodec: use AV_OPT_TYPE_BOOL for refcounted_frames, side_data_only_packets and skip_alpha options
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:9d0a6ede30e6: avdevice/caca: use AV_OPT_TYPE_BOOL for list_drivers option
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:79f0f1a80bd0: avdevice/caca: remove space before ':' (English typo, cosmetics)
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:2c364ef82dcc: avdevice/caca: small trivial macros adjustments
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:306ff409887c: ffprobe: use AV_OPT_TYPE_BOOL for writers options
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:411c32386ad5: avcodec/h264: use AV_OPT_TYPE_BOOL for is_avc option
[18:27:39 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:51cec6c30645: avcodec/libx264: use AV_OPT_TYPE_BOOL for fastfirstpass option
[18:27:40 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:7a256133ffe8: avcodec/textdec: use AV_OPT_TYPE_BOOL for keep_ass_markup option
[18:27:41 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:5cae43e718e5: avdevice/v4l2: use AV_OPT_TYPE_BOOL for use_libv4l2 option
[18:27:42 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:8e22becbc7ed: avcodec/pgssubdec: use AV_OPT_TYPE_BOOL for forced_subs_only option
[18:27:43 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:1e2c23f06c9c: avfilter/treble: use AV_OPT_TYPE_BOOL for csg option
[18:27:44 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:7434b9f66f42: avcodec/roqvideoenc: use AV_OPT_TYPE_BOOL for quake3_compat option
[18:27:45 CEST] <cone-574> ffmpeg 03Clément BSsch 07master:a84613b4c2a5: avformat/mov: use AV_OPT_TYPE_BOOL for export_{all,xmp} options
[18:27:59 CEST] <ubitux> (don't mind the noise, i'm just working on my voter permissions)
[18:28:35 CEST] <durandal_1707> lol
[18:40:53 CEST] Action: rcombs came in late; isn't sure what's being voted on
[18:41:15 CEST] <rcombs> but pretty sure I don't have a vote anyway so it's immaterial
[18:41:55 CEST] <durandal_1707> Anyone can vote how votes will be given
[18:45:06 CEST] <jamrial> rcombs: i lobbied so you would
[18:45:19 CEST] <wm4> so did the meeting result in anything of substance
[18:45:29 CEST] <rcombs> wm4: it's in progress
[18:45:42 CEST] <atomnuker> wm4: no decision on ABI compat yet
[18:46:00 CEST] <llogan2> FFmoots take a long time
[18:46:06 CEST] <durandal_1707> very dramatic and filled with action and CGI
[18:47:02 CEST] <Loriker> it's sarcasm day ...
[18:47:46 CEST] <rcombs> the only thing on the agenda I really have an opinion on is non-ML contributions
[18:49:06 CEST] <iive> it's lile slasher movie... blood everywhere
[18:49:10 CEST] <iive> like
[18:49:18 CEST] <iive> ;)
[18:52:33 CEST] <durandal_1707> now is about non-ml contribution
[19:01:24 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:e3e55758dcf6: lavf/img2dec: Improve jpeg auto-detection.
[19:05:11 CEST] <cehoyos> Could anybody forward the sample from bug 884 to me?
[20:35:00 CEST] <durandal_1707> rcombs: are you gonna change adpcm thp patch as I explained?
[20:55:32 CEST] <cone-574> ffmpeg 03Paul B Mahol 07master:494b79244162: avfilter: use ff_all_channel_counts() instead of ff_all_channel_layouts()
[21:02:49 CEST] <cone-574> ffmpeg 03Paul B Mahol 07master:1bf7bd194bc0: avfilter: add ocr filter
[21:20:15 CEST] <rcombs> durandal_1707: so you're suggesting moving the THP table into ADPCMDecodeContext?
[21:21:51 CEST] <durandal_1707> If more Chan appears so it doesn't use stack, just minor thing, whatever you prefer..
[21:33:24 CEST] <philipl> nevcairiel: So, that sintel sample has a pts discontinuity, which explains the hitch in it.
[21:33:48 CEST] <philipl> or I guess, that's the result of the decoder dropping frames.
[21:34:19 CEST] <nevcairiel> if it works with my LAV decoder, it might as well be the ticket i referenced, since i have had that patch applied for months now
[21:34:32 CEST] <philipl> That makes sense. Let me apply it and test
[21:34:51 CEST] <nevcairiel> reading the hevc spec and looking at the patch again, it does seem kinda faulty what i build there
[21:39:48 CEST] <philipl> Yep, it fixes the sample
[21:43:29 CEST] <nevcairiel> let me test a new and revised patch that makes more sense
[21:44:00 CEST] <nevcairiel> how do i get it to print timestamps again
[21:44:04 CEST] <nevcairiel> i guess framecrc might work
[21:44:57 CEST] <philipl> I used framemd5
[21:45:06 CEST] <philipl> It's not real times but it shows the discontinuity
[21:45:37 CEST] <philipl> I also extracted the section from 8s-10s and checked that.
[21:45:40 CEST] <philipl> easier to work with
[21:46:38 CEST] <rcombs> durandal_1707: works for me, though it might be best to see if other decoders need a similar-sized buffer
[21:47:23 CEST] <nevcairiel> man whatever sample server was linked in that xbmc ticket is slow
[21:56:31 CEST] <philipl> Very.
[21:56:31 CEST] <cone-574> ffmpeg 03Paul B Mahol 07master:2b7703456599: avfilter/vf_framerate: highbit depth support
[21:56:32 CEST] <cone-574> ffmpeg 03Paul B Mahol 07master:349970a67a19: avfilter/vf_framerate: calculate delta from scaled pts instead of unscaled
[21:56:33 CEST] <cone-574> ffmpeg 03Paul B Mahol 07master:16f08b7a0918: avfilter/vf_framerate: unbreak flushing
[21:56:34 CEST] <cone-574> ffmpeg 03Paul B Mahol 07master:6a074cfa1514: avfilter/vf_framerate: fix frame leak at uninit
[21:56:35 CEST] <philipl> I can upload the 2 second sample
[21:57:28 CEST] <nevcairiel> i used the one in the ticket
[21:57:39 CEST] <nevcairiel> and uploaded a new patch which doesnt break fate this time
[21:58:02 CEST] <BtbN> So it actualy was a bug in ffmpeg, interesting.
[21:58:26 CEST] <nevcairiel> we asked the authors of the hevc decoder to look at it months ago
[21:58:36 CEST] <nevcairiel> because my hacky patch fixed the problem but broke fate
[21:58:36 CEST] <nevcairiel> :D
[21:58:43 CEST] <nevcairiel> new patch seems to be better
[22:00:33 CEST] <philipl> nevcairiel: looks reasonable to me, assuming I can read the spec correctly - which may not be a safe assumption.
[22:01:03 CEST] <nevcairiel> i even quoted the relevant part of the spec in the ticket
[22:01:27 CEST] <nevcairiel> the only hacky part is that i set s->eos on init and after flush to trick the logic
[22:01:42 CEST] <philipl> nevcairiel: I read the quote - even then :-)
[22:01:52 CEST] <philipl> BtbN: how goes vp9?
[22:01:53 CEST] <nevcairiel> but s->eos and s->last_eos arent really used for shit
[22:02:15 CEST] <BtbN> philipl, due to lack of time, it doesn't go at all so far.
[22:02:36 CEST] <BtbN> I was at work for most of the day.
[22:03:00 CEST] <nevcairiel> I could sell that as work
[22:03:21 CEST] <philipl> I wish I could.
[22:04:08 CEST] <philipl> Maybe I could get it on our intel partnership roadmap...
[22:04:30 CEST] <fritsch> getting ffmpeg codec integration more "on top of intel's list" would be nice, yes
[22:04:45 CEST] <fritsch> we (kodi) were really happy that BtbN stepped up for the hevc task
[22:04:46 CEST] <philipl> but gstreamer is so awesome.
[22:04:53 CEST] <fritsch> :p
[22:05:17 CEST] <philipl> BtbN is a brave man.
[22:05:42 CEST] <fritsch> hehe - i know him since longer - basically since intel released broken vpp support
[22:06:26 CEST] <BtbN> btw., mesa-11 was just released. With that libudev-loading bug still in place.
[22:06:42 CEST] <BtbN> Just confirmed, mesa-11 with gallium enabled still makes kodi run into an infinite loop on startup.
[22:06:49 CEST] <fritsch> i hope that won't hit me - but the drm/egl vaapi nv12 transfer methods ...
[22:06:59 CEST] <fritsch> in a stable release is gold worthy
[22:08:37 CEST] <philipl> i wonder how well the radeon vdpau hevc works
[22:09:00 CEST] <philipl> they asked if i wanted test hardwarw and then disappeared.
[22:09:16 CEST] <nevcairiel> btw does vdpau 10-bit?
[22:09:28 CEST] <nevcairiel> +do
[22:09:28 CEST] <fritsch> nevcairiel: hehe - just after my n3150 has finished compiling you updated the patch
[22:09:43 CEST] <fritsch> will test the older one first
[22:10:01 CEST] <nevcairiel> just replacing the patch shouldnt be that much re-building
[22:10:06 CEST] <fritsch> yeah, no problem
[22:10:07 CEST] <nevcairiel> just the hevc things
[22:10:13 CEST] <fritsch> need to compile / link kodi against it again
[22:10:21 CEST] <philipl> nevcairiel: no. but it's being worked on.
[22:10:21 CEST] <fritsch> just mentioned ... no problem at all
[22:10:32 CEST] <BtbN> Just that patch should not break the abi
[22:10:37 CEST] <BtbN> no need to rebuild kodi
[22:10:56 CEST] <nevcairiel> philipl: vdpau lacking 10-bit interfaces, driver not ready, or whats the status?
[22:11:57 CEST] <nevcairiel> I thought about adding dxva2 10-bit to ffmpeg mainline, but ... if the user code doesn't handle it properly, it will result in corruption, so the best course would be to add a flag that the user code has to set
[22:12:05 CEST] <nevcairiel> but thats all sorts of terribly  weird
[22:12:08 CEST] <philipl> nevcairiel: obviously lacks 10 bit in the api but all the internal driver parts need updating.
[22:12:55 CEST] <fritsch> vaapi lacks 10bit including skl, but since this hybrid thingy ... i am not fully sure what they will release next in that regard
[22:13:11 CEST] <nevcairiel> nvidia are the only ones with 10-bit hardware support so far
[22:13:19 CEST] <nevcairiel> so i wondered if they made vdpau do it yet
[22:14:10 CEST] <philipl> it appears to be tne top priority for whatever that's worth.
[22:14:41 CEST] <fritsch> nevcairiel: there are some amlogic socs that tell they could do hevc10 decoding
[22:14:42 CEST] <nevcairiel> doesnt help that ffmpeg doesnt even have an appropriate pixel format to represent the surface data the decoder would output
[22:14:50 CEST] <fritsch> hehe
[22:16:24 CEST] <philipl> what format is that?
[22:16:33 CEST] <philipl> its not what we use on the aoftware side?
[22:16:44 CEST] <nevcairiel> nv12 with more bits, aka P010
[22:17:00 CEST] <philipl> as long as uou don't read back...
[22:17:18 CEST] <nevcairiel> well if you just send the surfaces around, you might be able to get by
[22:17:20 CEST] <fritsch> yeah ... that will suck
[22:17:24 CEST] <fritsch> on nvidia the interop with gl
[22:17:26 CEST] <fritsch> needs rework
[22:17:34 CEST] <nevcairiel> on windows read back is pretty fine
[22:17:37 CEST] <nevcairiel> even with 4k-10bit
[22:17:37 CEST] <fritsch> on vaapi we need additional formats to zero copy the surfaces
[22:17:58 CEST] <nevcairiel> the nvidia driver is really good with that kind of thing, does DMA and everything
[22:18:07 CEST] <fritsch> yeah, from kodi pov
[22:18:11 CEST] <fritsch> we render in GL
[22:18:20 CEST] <fritsch> so currently with vdpau we use the glinterop
[22:18:23 CEST] <fritsch> the api defines
[22:18:54 CEST] <philipl> yes. gl interop will need updating.
[22:19:20 CEST] <fritsch> basically, they shall decode it for us
[22:19:22 CEST] <fritsch> and scale :-)
[22:19:23 CEST] <fritsch> hehe
[22:19:27 CEST] <fritsch> as intermediate solution
[22:20:00 CEST] <fritsch> so nothing would change on user side
[22:20:16 CEST] <fritsch> until someone really wants to display with 10 bit
[22:20:51 CEST] <nevcairiel> amazingly zero-copy with dxva2 is now also working (with the EVR renderer), i didnt think they would ever fix it
[22:21:06 CEST] <nevcairiel> with 10-bit that is
[22:21:10 CEST] <nevcairiel> 8-bit always worked
[22:22:05 CEST] <fritsch> mmh, we implemented sse4 copy for our dxva lately
[22:22:13 CEST] <fritsch> to care for radeon cards that don't do any dx11
[22:22:14 CEST] <nevcairiel> of course proper 10-bit display is another matter entirely
[22:23:10 CEST] <nevcairiel> AMD cards are terrible at dxva2 read-back in my experience, at least the older ones, extremely slow
[22:23:25 CEST] <fritsch> jep, it's about the older ones
[22:23:43 CEST] <fritsch> after we changed from dx9 *hust* to dx11 some weeks ago
[22:23:48 CEST] <fritsch> immense load of bugreports ...
[22:23:50 CEST] <fritsch> all AMD
[22:24:06 CEST] <fritsch> and then windows 10 came and the radeon legacy users did not even have dx9 support anymore
[22:24:09 CEST] <fritsch> not funny, not nice
[22:24:18 CEST] <nevcairiel> well thats not your problem :D
[22:24:24 CEST] <nevcairiel> also, kinda funny
[22:24:25 CEST] <fritsch> hehe, hehe
[22:24:27 CEST] <fritsch> tell that the user
[22:24:34 CEST] <fritsch> _but_ it worked ...
[22:24:35 CEST] <fritsch> they tell us
[22:24:44 CEST] <philipl> Finding someone else's bug makes it your problem.
[22:24:45 CEST] <nevcairiel> before you upgraded your OS, you tell them!
[22:24:51 CEST] <fritsch> we are happy that amd linux folks (oss) work nicely with us
[22:24:55 CEST] <fritsch> they even implemented glinterop
[22:25:13 CEST] <philipl> fritsch: what extension does amd use?
[22:25:13 CEST] <fritsch> and vdpau became usable there
[22:25:13 CEST] <nevcairiel> i havent heard complaints from AMD users for a while, its surprising
[22:25:15 CEST] <philipl> the nvidia one?
[22:25:24 CEST] <fritsch> amd oss uses vdpau
[22:25:33 CEST] <fritsch> flgrx uses nothing
[22:25:33 CEST] <nevcairiel> that reminds me i wanted to rip a bluray and watch it later
[22:25:48 CEST] <fritsch> after the xvba nightmare .. kodi's politics is: come with fglrx, no support
[22:25:53 CEST] <philipl> heh.
[22:25:59 CEST] <philipl> I'm impressed you even tried using it.
[22:26:03 CEST] <fritsch> we implemented it
[22:26:06 CEST] <fritsch> xvba for ffmpeg
[22:26:09 CEST] <fritsch> fernetmenta and me
[22:26:09 CEST] <philipl> nevcairiel: you want the easy way or the Right(tm) way.
[22:26:22 CEST] <fritsch> but amd did not release a xvba-sdk with proper mpeg-2 and mpeg-4
[22:26:33 CEST] <fritsch> so we stopped it and throwed it away
[22:26:37 CEST] <cone-574> ffmpeg 03Rodger Combs 07master:3f9fa2d0b58b: ADPCM: Bump THP channel limit to 14
[22:26:41 CEST] <nevcairiel> philipl: both! :D
[22:26:44 CEST] <fritsch> now amd ships fglrx with vaapi support
[22:26:48 CEST] <fritsch> no threadsafe :-)
[22:27:05 CEST] <fritsch> still xvba under the hood
[22:27:13 CEST] <fritsch> i sent them some patches ... but they did not care - as always
[22:27:18 CEST] <fritsch> the closed people that is
[22:27:21 CEST] <fritsch> not the oss people
[22:27:44 CEST] <philipl> nevcairiel: makemkv.com for the easy way. Some insanity involving libaacs and keys you dug up from doom9 is the open-source way.
[22:28:03 CEST] <fritsch> also using makemkv
[22:28:12 CEST] <nevcairiel> yeah i use makemkv
[22:28:39 CEST] <nevcairiel> and i wouldnt need decrypting, i also own AnyDVD HD
[22:28:47 CEST] <nevcairiel> beign a windows user makes things easier
[22:28:55 CEST] <fritsch> :p
[22:29:02 CEST] <fritsch> not until you have to enable the firewall to install ttf fonts
[22:29:14 CEST] <fritsch> http://superuser.com/questions/957907/unable-to-install-fonts-on-windows-10
[22:29:50 CEST] <nevcairiel> its a new OS, things are bound to be broken
[22:30:04 CEST] <fritsch> yeah, the ttf verification code is in the firewall class
[22:30:13 CEST] <fritsch> can happen - refactoring tools and the like :-)
[22:30:17 CEST] <nevcairiel> which windows was ever "good" before the first service pack
[22:30:19 CEST] <philipl> fonts are turing complete!
[22:30:45 CEST] <Loriker> nevcairiel: windows 2.0 ;)
[22:30:52 CEST] <nevcairiel> i dont think i ever used that
[22:32:05 CEST] <Loriker> windows 2.0 isn't something you want to have ever used
[22:32:35 CEST] <fritsch> nevcairiel: philipl stutter is gone!
[22:32:42 CEST] <philipl> yay
[22:32:48 CEST] <fritsch> this is with the old patch
[22:32:54 CEST] <fritsch> will report back in two seconds
[22:33:01 CEST] <fritsch> actually some more seconds
[22:34:54 CEST] <jamrial> nevcairiel: i thought windows 7 was fine before the first service pack
[22:35:12 CEST] <nevcairiel> i suppose it wasnt as bad as previous versions
[22:37:54 CEST] <nevcairiel> I can use 10 just fine now as well, but some of the bugs are just funny :d
[22:39:33 CEST] <jamrial> like what? i'm using win10 as well and only thing i noticed was system setting windows closing themselves then opening again for no reason :p
[22:40:28 CEST] <fritsch> nevcairiel: all fine :-) very nice. thank you very much
[22:43:45 CEST] <nevcairiel> I mailed the authors of the hevc decoder from the OpenHEVC team again with the new patch, if they dont move I'll just send it to the ML and apply it after
[22:43:54 CEST] <nevcairiel> maybe get it in 2.8.1 as well
[22:48:29 CEST] <fritsch> cool
[22:48:44 CEST] <fritsch> funny thing is: gstreamer has the very same issues
[22:48:47 CEST] <fritsch> at the same position
[22:48:52 CEST] <fritsch> but additionally shows artifacts
[22:48:58 CEST] <nevcairiel> dont they use avcodec for that
[22:49:07 CEST] <fritsch> ouh - that would make it clear
[22:49:11 CEST] <fritsch> i honestly don't know
[22:49:23 CEST] <nevcairiel> or with their hardware decoder? i think that might not use avcodec
[22:49:43 CEST] <fritsch> after getting my first gst pipeline to run, cause the vaapi folks only accepted bugs they could reproduce with gstreamer ...
[22:49:47 CEST] <fritsch> i even hated it more
[22:52:31 CEST] <BtbN> gst with vaapi decoder and output doesn't use libav*
[22:52:52 CEST] <BtbN> gst in software mode does, and behaves like all the other lavc based player.
[22:53:32 CEST] <nevcairiel> this particular flag is an inferred element hidden in a side note in the spec
[22:53:41 CEST] <nevcairiel> no surprise people forget to implement it
[22:53:56 CEST] <nevcairiel> but if you think about what the code does without it, it should be obvious that something weird is going on
[22:54:10 CEST] <nevcairiel> why would you routinely just throw away images
[00:00:00 CEST] --- Sun Sep 13 2015