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

[burek]

[00:06:44 CEST] <philipl> getting mpv building isn't hard, and it's actually usable as a player
[00:09:30 CEST] <nevcairiel> another "useful" carl patch in that ticket =p
[00:10:31 CEST] <wm4> so where the heck are the kodi devs
[00:10:40 CEST] <nevcairiel> they probably dont care
[00:13:35 CEST] <nevcairiel> wth is with the indenation in matroskaenc.c, that part of the code is practically unreadable
[00:13:40 CEST] <nevcairiel> indentation*
[00:14:04 CEST] <nevcairiel> i hate it when people re-shuffle code and then someone says "dont reindent, makes it harder to read"
[00:14:09 CEST] <nevcairiel> yeah well the end result is crap
[00:14:50 CEST] <wm4> isn't the convention to including the reindentation in the final patch, or add it as separate commit?
[00:16:34 CEST] <Zerowalker> Is it possible to have a closed source plugin linked to ffmpeg?
[00:18:00 CEST] <Timothy_Gu> Zerowalker: no
[00:18:55 CEST] <nevcairiel> sure it is, use dynamic linking, build ffmpeg as LGPL
[00:19:06 CEST] <philipl> Or don't distribute the resulting binary.
[00:20:57 CEST] <Zerowalker> the plugin/patch would be that a closed sourced codec get's implemented into ffmpeg through dynamic lib or something. A private build
[00:21:23 CEST] <Zerowalker> i am not the one doing this the developing, but i am trying to find out if licensing allows this (and i suck at this license stuff)
[00:21:31 CEST] <kierank> you can't distribute that ffmpeg
[00:22:01 CEST] <Zerowalker> that's ok i think, as it's only intended for personal use
[00:22:35 CEST] <Timothy_Gu> Zerowalker: it's not legal to distribute this build, but if you are not distributing then I guess nobody cares
[00:22:57 CEST] <Zerowalker> but it's acceptable then? I download ffmpeg for example, then i patch it with the closed source so it links to a dynamic lib and a new codec appears
[00:23:18 CEST] <Zerowalker> but, it doesn't violate anything then, as long as it's not distributed?
[00:23:32 CEST] <Zerowalker> and i guess that means publication of sort
[00:25:10 CEST] <kierank> it means giving the binary to anyone
[00:28:15 CEST] <Zerowalker> i see, but the developer can make a patch and "distribute" that to who he wants, and then those that have it can privately compile an ffmpeg version with that patch, for private use?
[00:29:01 CEST] <kierank> yes but all those ffmpeg builds would be nonfree
[00:29:30 CEST] <j-b> Anyone started working on VC-5?
[00:29:57 CEST] <nevcairiel> wm4: reading the code, i'm suspicious that matroskaenc might write wrong values for those subtitle cue elements, though
[00:30:09 CEST] <Zerowalker> nonfree, you mean that in the sense that it can't be distributed for free cause of the other licenses? If so that's not a problem for private use:)
[00:30:25 CEST] <nevcairiel> j-b: do we have vc-2 through 4 done already? :d
[00:30:34 CEST] <j-b> nevcairiel: don't we?
[00:30:47 CEST] <j-b> nevcairiel: I thought we had vc-1-3
[00:30:49 CEST] <Zerowalker> But as long as that's allowed, and making a patch, codec thing in closed source etc, then i think i have it's all good
[00:31:08 CEST] <j-b> VC-2 is Diract and VC-3 is DNxHD
[00:31:46 CEST] <j-b> nevcairiel: VC-5 is Cineform
[00:36:28 CEST] <nevcairiel> vc-1 support is still not 100%, afaik dirac suffers a similar fate
[00:36:33 CEST] <wm4> nevcairiel: I haven't really checked yet (that's why I want the kodi devs to do that)
[00:36:45 CEST] <j-b> nevcairiel: indeed.
[00:36:51 CEST] <wm4> nevcairiel: from a superficial look it looked ok though
[00:37:03 CEST] <nevcairiel> i would be somewhat surprised if kodi actually uses the subtitle cues for subtitles on seek
[00:37:09 CEST] <nevcairiel> they probably just get confused by all the extra cues
[00:37:27 CEST] <wm4> (I thought kodi used ffmpeg's demuxer)
[00:37:41 CEST] <nevcairiel> no clue how that one behaves when seeking in such a stream
[00:37:43 CEST] <nevcairiel> i dont use it
[00:37:43 CEST] <nevcairiel> :D
[00:37:59 CEST] <nevcairiel> .. and i had to fix mine when these cues appeared
[00:41:14 CEST] <nevcairiel> anyway i think the cluster position in the cue thingy may be wrong
[00:41:23 CEST] <nevcairiel> but its getting late, and i will delay checking until tomorrow
[00:43:19 CEST] <wm4> you mean the "relative" cluster position?
[00:43:55 CEST] <nevcairiel> yeah
[00:44:07 CEST] <nevcairiel> from a quick look at the code, its relative to the start of the file, not the segment
[00:44:15 CEST] <nevcairiel> but maybe i missed something
[00:44:33 CEST] <philipl> wm4: on the subject of demuxing mkv, why doesn't mpv use the ffmpeg demuxer?
[00:44:53 CEST] <wm4> philipl: apparently ordered chapters are the main reason
[00:45:22 CEST] <wm4> (probably the same reason nevcairiel uses the haali code for mkv)
[00:45:28 CEST] <nevcairiel> bad seeking and ordered chapters/linked segments, yea
[00:45:40 CEST] <philipl> no one wants to push that to ffmpeg?
[00:46:13 CEST] <philipl> seems like no-one uses the demuxer in the real world right now.
[00:46:20 CEST] <nevcairiel> there would be a two year debate on which level to handle it, and in the end it would result in both of us having to rewrite mkv support
[00:47:18 CEST] <wm4> just exporting the ordered chapter info somehow would be enough for mpv, but yeah
[00:47:52 CEST] <philipl> *sigh*
[00:48:25 CEST] <wm4> actually a Libav dev had plans for this
[00:48:49 CEST] <wm4> exporting OC info as some sort of playlist, and avconv.c would have been able to use this info
[00:49:01 CEST] <philipl> That's probably the least controversial way to do it
[00:49:31 CEST] <wm4> there's a WIP branch somewhere (if it even still exists...)
[00:51:20 CEST] <nevcairiel> its like from 2011 and even that attempt was very controversial back then :p
[00:52:49 CEST] <wm4> wow 2011
[00:53:10 CEST] <wm4> and then there's the even older patch that implemented OC directly in the demuxer (haali-style)
[01:09:13 CEST] <cone-136> ffmpeg 03Timothy Gu 07master:0c6a92a447b3: matroskaenc: Fix indentation
[01:11:09 CEST] <Zerowalker> Is there a better place to discuss this licensing thing i asked about?
[01:11:34 CEST] <BtbN> turns out libva git already has the missing trace parameter stuff i just added myself to the release version...
[01:13:04 CEST] <wm4> BtbN: d'oh
[01:13:23 CEST] <BtbN> And libva git also plays 4K60 just fine
[01:13:27 CEST] <BtbN> hevc
[01:14:04 CEST] <wm4> you mean just changing to git made it work?
[01:15:22 CEST] <BtbN> yes, from libva/intel-driver 1.6.0 to latest git master.
[01:16:56 CEST] <llogan> Zerowalker: yes, ffmpeg-user since it's not about development of FFmpeg
[01:17:19 CEST] <wm4> BtbN: sounds like very good news
[01:17:39 CEST] <BtbN> There is still this one sample with messed up colors
[01:17:52 CEST] <BtbN> And i can't figure out if it's just broken or there's something wrong with the code
[01:18:14 CEST] <BtbN> ffplay playing it flawlessly suggests it's something in the code
[01:18:29 CEST] <BtbN> gst is refusing to play it at all, because invalid format
[01:19:08 CEST] <Compn> BBB : i'm registered and coming already
[01:19:23 CEST] <Compn> BBB : actually i'm going to be in france driving around from sept 5-22 ...
[01:19:49 CEST] <Compn> although i barely speak 5 words of french
[01:20:51 CEST] <Compn> so also i'm not going to be on irc.
[01:21:05 CEST] <Compn> llogan : do you mind taking over doing ml moderation?
[01:21:22 CEST] <Compn> (not that i've been helping much)
[01:22:02 CEST] <llogan> sure, but i didn't know anyone else was doing it.
[01:22:30 CEST] <Compn> i've been doing it off and on for few years now :P
[01:23:26 CEST] <llogan> i guess it was you then who does the mystery queue clearing i see once in a great while
[01:24:03 CEST] <Compn> it gets cleared but fills back up again quickly :P
[01:24:20 CEST] <durandal_1707> want vc-5? Pay!
[01:24:32 CEST] <Compn> (i also do mplayers' moderation, rarely)
[01:25:17 CEST] <Compn> BBB : i'm trying to remember if we met at vdd in paris or dublin 
[01:25:31 CEST] <BBB> I was in paris for 15 minutes a few years back
[01:25:40 CEST] <BBB> I was traveling to the netherlands and happened to be in town
[01:25:40 CEST] <Compn> i've got the long beard
[01:25:42 CEST] <Compn> ah
[01:25:47 CEST] <BBB> but I was only there for 15 minutes and then had to run
[01:25:48 CEST] <BBB> sadly
[01:25:51 CEST] <BBB> this time Il be there the whole time
[01:27:32 CEST] <Compn> for disneyland too ? :P
[01:27:37 CEST] <Compn> on the 18th
[01:29:35 CEST] Action: Compn afk
[01:29:54 CEST] <Compn> nevcairiel : dont worry, i wont be joining in the ffmpeg/libav talks...
[01:33:52 CEST] <philipl> BtbN: might be a libva bug of course.
[01:34:03 CEST] <philipl> I've got some vdpau brokenness that I'm pretty sure is a driver/library issue
[01:34:28 CEST] <philipl> can you remux the file to make gst happy?
[01:34:29 CEST] <BtbN> gst not playing the file at all is not exactly helpfull to determine if some of my parameters are wrong
[01:34:34 CEST] <philipl> or does it think the stream is broken?
[01:34:44 CEST] <BtbN> It complains about it way after the demuxer level
[01:34:51 CEST] <BtbN> vaapidecode says the picture is invalid
[01:35:02 CEST] <philipl> And in your code it doesn't?
[01:35:11 CEST] <philipl> Might be worth seeing where it's barfing in gst and if you can fix it...
[01:35:18 CEST] <BtbN> I'm not using gst modules in my ffmpeg code ;)
[01:35:36 CEST] <philipl> I mean compile all of gst from scratch and get to work :-)
[01:36:31 CEST] <philipl> My 'reference' application was the hacked up nvidia app that borrowed a ton of code from gst but displayed frames in decode order.
[01:36:35 CEST] <philipl> Made it hard to spot visual problems...
[01:51:34 CEST] <cone-136> ffmpeg 03Timothy Gu 07master:b144008c1ba6: ffmpeg_opt: Add missing comma
[02:20:16 CEST] <BtbN> philipl, "GstVaapiDecode:vaapidecode0: No valid frames decoded before end of stream"
[02:20:20 CEST] <BtbN> Is the error gst gives
[02:30:20 CEST] <BtbN> according to the va trace log, it doesn't even try to decode a single frame
[02:30:33 CEST] <BtbN> so i guess their nevc parser dislikes what it sees
[02:30:37 CEST] <BtbN> *hevc
[02:41:09 CEST] <cone-136> ffmpeg 03Timothy Gu 07master:68a9c8ac774d: swscale: Silence an unused variable warning
[04:02:55 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:dda69253578f: avformat/segment: Do not free the filename twice
[05:00:47 CEST] <cone-136> ffmpeg 03James Almer 07master:4c39892b6741: avcodec/vdpau: fix compilation of mpeg1/mpeg4/vc1 decoders when h264 is disabled
[05:10:08 CEST] <philipl> BtbN: weird.
[05:10:27 CEST] <philipl> That's the gst parser giving up, not anything in libva right?
[09:23:32 CEST] <j-b> Daemon404: it's called LibreOfficeKit and they are consolidating it.
[10:43:24 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:e030d3c61fdb: avfilter/vf_blend: use the name 's' for the pointer to the private context
[10:52:45 CEST] <BtbN> philipl, yes. libva is initialized, but nothing is ever decoded with it. It gives up before. But in the vaapidecode module. So it can only be the nal parsing happening there.
[10:53:59 CEST] <BtbN> http://forum.kodi.tv/showthread.php?tid=231955&pid=2089922#pid2089922 has some more samples that are broken in similar ways though
[10:55:44 CEST] <BtbN> So i'll assume something is still slightly broken.
[11:50:11 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:47df8716451f: avfilter/af_aphaser: use the name 's' for the pointer to the private context
[12:03:36 CEST] <durandal_1707> Why is there libavfilter/log2_tab.c?
[12:16:52 CEST] <cone-136> ffmpeg 03Ganesh Ajjanagadde 07master:6455e4fb5bc3: configure: do not fork off grep subprocess while testing for whitespace
[13:07:49 CEST] <BtbN> __gb__, if you have some time, i posted the vaapi hevc patch on ffmpeg-devel.
[13:11:38 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:3fbc9deb954c: avfilter/vf_vectorscope: fix bug in checking pixel format flags
[13:11:39 CEST] <cone-136> ffmpeg 03Paul B Mahol 07master:a16251a6d040: avfilter/vf_histogram: fix bug in checking pixel format flags
[13:15:46 CEST] <BtbN> __gb__, also, I found some samples that have distorted colors when played via ffmpeg. gst refuses to play them at all, with a strange error from vaapidecode
[13:16:27 CEST] <BtbN> https://dl.dropboxusercontent.com/u/46848344/hevc/birds_1080p_24fps_h265.mkv for example
[13:27:16 CEST] <nevcairiel> I wouldn't get distracted by the gst failure, its probably a red herring
[13:27:27 CEST] <nevcairiel> the sample decodes fine with other hardware interfaces
[13:28:45 CEST] <BtbN> Well, but without gst decoding it correctly i have nothing to compare the trace against. :D
[13:29:27 CEST] <nevcairiel> you could debug gst and see where it fails
[13:29:50 CEST] <BtbN> Just setting all the delta luma/chroma weight/offset parameters to 0 yields better results, but it still shows artifacts on those samples
[13:29:52 CEST] <nevcairiel> maybe remux to ts or raw h265 to see if it changes anything
[13:30:09 CEST] <BtbN> The vaapidecode module fails at parsing the bitstream
[13:30:14 CEST] <BtbN> remuxing has no effect
[13:30:25 CEST] <BtbN> It doesn't even reach libva
[13:31:19 CEST] <BtbN> Which makes me suspect that there is some hevc corner case that wasn't respected when implementing gst(and maybe even libva)
[13:32:06 CEST] <BtbN> The only other reason i can still think of is that the luma/chroma offsets are wrong, and the calculation ffmpeg does on them doesn't match what libva expects
[13:32:36 CEST] <nevcairiel> the chroma offsets are only read if chroma_weight_l0_flag[i] is set
[13:32:45 CEST] <nevcairiel> but you never see those flags
[13:32:58 CEST] <nevcairiel> but if they are not set, it should zero the struct .. hm
[13:33:13 CEST] <BtbN> That flag doesn't exist.
[13:33:18 CEST] <BtbN> in the libva interface
[13:33:56 CEST] <nevcairiel> if its not set in the bitstream, it would result in avcodec nulling out the weight and offsets anyway
[13:34:07 CEST] <BtbN> The values are propperly zeroed though, that's visible in the trace logs
[13:34:09 CEST] <nevcairiel> and 0 seems to be the proper fallback value to set it to
[13:34:45 CEST] <BtbN> There are only errors on frames where they are not 0
[13:34:58 CEST] <Daemon404> j-b, oh. glob help us all.
[13:41:48 CEST] <nevcairiel> I bet your scaling lists are still wrong, since you dont un-zigzag them
[13:42:04 CEST] <nevcairiel> but that should cause general corruption, not necessarily colors being wrong
[13:54:32 CEST] <BtbN> nevcairiel, found something else: slice_param->delta_chroma_log2_weight_denom = sh->chroma_log2_weight_denom;
[13:54:36 CEST] <BtbN> ffmpeg un-delta'd it
[13:54:48 CEST] <BtbN> s->sh.chroma_log2_weight_denom = av_clip_uintp2(s->sh.luma_log2_weight_denom + delta, 3);
[13:54:53 CEST] <BtbN> and that doesn't look exactly reversible
[13:55:14 CEST] <soummyaah> Hey! I'm new to the ffmpeg community. I wanted to know if you would be participating in the September round of internships via Outreachy. Also, how could I start contributing? (Whether you are going to be participating or not.) I've read a bit about ffmpeg and the work done here excites me. Though it all seems very new to me. What would be the best way to proceed?
[13:55:47 CEST] <wm4> soummyaah: subscribe to the development mailing list, and watch how things work
[13:56:28 CEST] <wm4> then you could look at the bug tracker and attempt to analyzer and fix issues
[13:56:33 CEST] <wm4> *analyze
[13:56:38 CEST] <soummyaah> wm4 Thanks for the advice. Are there any easy open issues I could get started with?
[13:56:45 CEST] <wm4> (I don't know about the Outreachy process)
[13:57:14 CEST] <wm4> I don't know... you'll pretty much have to look yourself
[13:57:17 CEST] <soummyaah> Sounds good. Could I PM you in case I need to ask more?
[13:57:32 CEST] <wm4> just ask on this channel, I'm not anyone special either
[13:57:59 CEST] <soummyaah> Okay, thanks! I'll start with the mailing list and the bug tracker.
[13:59:05 CEST] <wm4> at first you'll probably want to find out how to use git, how to compile ffmpeg, how to run our test suite FATE (if you didn't already)
[14:01:57 CEST] <soummyaah> I've familiar with git and have compiled ffmpeg. I haven't run the test suite yet though. I'll start with that.
[14:08:21 CEST] <wm4> excellent... doc/fate.texi has more information
[14:10:23 CEST] <wm4> is the "old" bug tracker available anywhere? I'm looking at a commit from 2008, and it references an issue number which obviously doesn't match with our current bug tracker
[14:12:53 CEST] <nevcairiel> BtbN: the clipping shouldnt trigger in a conformant stream, so just subtract the luma value?
[14:13:11 CEST] <BtbN> yeah, i just noticed that it doesn't clip it to 3, but to 1 << 3
[14:16:55 CEST] <nevcairiel> does it help?
[14:18:28 CEST] <BtbN> Found some other stuff gst does diffrently, adding that right now.
[14:19:18 CEST] <BtbN> https://github.com/gbeauchesne/gstreamer-vaapi/blob/master/gst-libs/gst/vaapi/gstvaapidecoder_h265.c#L2342 seems strange, isn't the value only set when chroma_format_idc != 0? So the logic is reversed here?
[14:19:58 CEST] <nevcairiel> the ffmpeg condition says != 0
[14:22:18 CEST] <wm4> yeah, why does vf_colormatrix exist at all
[14:22:59 CEST] <wm4> in the libavfilter model all video conversions happen with vf_scale, so why have additional filters which take care of such aspects
[14:23:06 CEST] <nevcairiel> obviously the answer is because swscale cant do the job
[14:23:17 CEST] <wm4> yeah, too hard to fix libswscale
[14:23:21 CEST] <nevcairiel> vf_scale is a scale filter, a pure yuv conversion doesnt really fit the bill
[14:23:31 CEST] <wm4> sure it does
[14:23:42 CEST] <wm4> the API even supports it, as far as I can see
[14:23:53 CEST] <nevcairiel> you would need a dedicated processing path for this
[14:23:57 CEST] <nevcairiel> ie. copy colormatrix =p
[14:28:28 CEST] <BtbN> nevcairiel, so far no sample i tested even used the sacling lists, so they might very well be wrong, yes.
[14:29:04 CEST] <nevcairiel> fate has a few
[14:29:45 CEST] <nevcairiel> if only i remembered which
[14:30:00 CEST] <nevcairiel> SLIST_* are probably a good bet =p
[14:33:08 CEST] <BtbN> Are you looking at http://samples.ffmpeg.org/allsamples.txt ?
[14:33:28 CEST] <nevcairiel> nah fahttp://fate-suite.ffmpeg.org/hevc-conformance/
[14:33:32 CEST] <nevcairiel> woops
[14:33:34 CEST] <nevcairiel> http://fate-suite.ffmpeg.org/hevc-conformance/
[14:34:13 CEST] <nevcairiel> the SLIST samples is what I used to figure out scaling list problems
[14:34:37 CEST] <nevcairiel> or you know, just copy vdpau or dxva2
[14:35:47 CEST] <BtbN> the birds sample is fixed now.
[14:35:59 CEST] <BtbN> propably just the missing delta
[14:36:48 CEST] <nevcairiel> yay
[14:37:21 CEST] <BtbN> The SLIST ones definitely are still broken
[14:48:36 CEST] <BtbN> strange stuff
[14:48:45 CEST] <BtbN> luckily the code from vdpau just works
[16:12:20 CEST] <nevcairiel> So we actually respond to his issue and we're the bad guys now, instead kodi flst out ignored him, and they are perfect
[16:12:27 CEST] <nevcairiel> Some guys sure are jaded :p
[16:13:30 CEST] <wm4> from a superficial look at our code, I feel like I should push a reindent commit
[16:13:40 CEST] <wm4> from a second look, it seems like the code is correct
[16:14:02 CEST] <wm4> the relative position thing, I mean
[16:14:10 CEST] <wm4> relative_packet_pos = avio_tell(s->pb) - mkv->cluster.pos;
[16:14:33 CEST] <nevcairiel> Yeah I found the missing piece, it seems fine
[16:14:40 CEST] <wm4> I also remember how support for this got added, and I explicitly tested it (and I've already found out before that mkvmerge wrote this incorrectly, and got mkvmerge to fix their bug)
[16:14:56 CEST] <nevcairiel> The only issue is the order of the cues, apparently
[16:15:09 CEST] <wm4> and I agree that the order isn't guaranteed
[16:15:49 CEST] <nevcairiel> But the order would be a more fundamental problem in avformat mixing code
[16:15:55 CEST] <nevcairiel> Muxing*
[16:17:08 CEST] <BtbN> Even with correct(?) ScalingList handling, the samples still show artifacts.
[16:17:16 CEST] <BtbN> gst shows the exact same ones though
[16:43:43 CEST] <wm4> "I am disappointed that the Kodi devs haven't addressed it, but I know the person who usually takes care of it (FernetMenta?) is busy implementing hevc acceleration via vaapi in, strangely enough, FFmpeg. "
[16:45:24 CEST] <nevcairiel> too bad his work is all for nothing :p
[16:47:33 CEST] <wm4> I wonder what "AV sync issue in stream 1 at 0:00:13.823 with duration of 0.666ms : broken timecode, apparent audio skew is -1ms" is about
[16:47:47 CEST] <wm4> isn't this natural, since matroska timestamps are usually rounded to milliseconds?
[16:48:23 CEST] <wm4> and since matroska doesn't have fractional timestamps, it can't be fixed
[16:50:00 CEST] <nevcairiel> he collected like 3 different "symptoms" of some errors in that report by now, its just nonsensical raving of a user
[16:51:15 CEST] <nevcairiel> BtbN: if it decodes things equal to gst now, i would say just ship it and fix whatever needs fixing later, it looks fine to me so far
[16:52:37 CEST] <nevcairiel> i think we hurt his feelings now, and we didnt even get mean
[16:52:44 CEST] <wm4> *shrug*
[16:54:46 CEST] <nevcairiel> i still bet the mere presence of the subtitle cues causes it, or something
[16:55:08 CEST] <nevcairiel> the ffmpeg mkv demuxer seek method seems to somehow try to do something with subtitle cues
[16:55:15 CEST] <nevcairiel> but seeking was always a bit flaky in that one
[16:55:34 CEST] <nevcairiel> he even in one post said remuxing with mkvmerge didnt help
[16:55:42 CEST] <nevcairiel> makemkv probably just doesnt wr ite subtitle cues
[16:56:04 CEST] <philipl> BtbN: So, either you've faithfully reproduced an error in the gst impl, or it's a low level bug :-)
[16:56:24 CEST] <philipl> But if you can get gst to show it in a broken way, then I think __gb__ might feel obliged to fix it.
[16:58:51 CEST] <BtbN> just the 4 SLIST_* samples from fate
[16:58:55 CEST] <BtbN> ffplay plays them correctly
[16:59:01 CEST] <BtbN> gst and mpv/kodi don't.
[16:59:07 CEST] <BtbN> via vaapi
[16:59:15 CEST] <philipl> Weird.
[16:59:28 CEST] <wm4> BtbN: ffplay has vaapi support?
[16:59:31 CEST] <philipl> But that ought to be enough to make __gb__ reappear.
[16:59:50 CEST] <BtbN> No, otherwise it would propably also break in the same way.
[16:59:55 CEST] <nevcairiel> wm4: he meant software decoded
[17:00:00 CEST] <BtbN> I use ffplay to verify if the file works in general.
[17:00:16 CEST] <philipl> Well, I know the SLIST samples work in vdpau.
[17:00:18 CEST] <BtbN> Doesn't work too amazing for 4K stuff though
[17:00:28 CEST] <BtbN> yeah, they are definitely not broken
[17:00:31 CEST] <BtbN> it's something with vaapi
[17:01:37 CEST] <wm4> considering not even gst can do it, maybe you don't need to care yet
[17:01:50 CEST] <philipl> that's my thought.
[17:02:07 CEST] <wm4> the gst implementation is from an intel dev, isn't it
[17:02:19 CEST] <philipl> __gb__: :-)
[17:02:20 CEST] <BtbN> yes, from gb
[17:02:38 CEST] <BtbN> There are 3 parameters still marked as fixme/todo. In both ffmpeg and gs
[17:02:40 CEST] <BtbN> *gst
[17:02:43 CEST] <BtbN> maybe it's related to one of them
[17:02:53 CEST] <philipl> BtbN: Does LTRPSPS_A_Qualcomm_1.bit play correctly for you?
[17:03:14 CEST] <nevcairiel> still with the long term refs, huh
[17:03:33 CEST] <philipl> Well, not all of them. There are two samples that still fail but others with LTRs work
[17:03:45 CEST] <philipl> And I certainly can't see the problem in any real world clip.
[17:03:47 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/vaapi_hevc/libavcodec/vaapi_hevc.c#L245
[17:03:48 CEST] <BtbN> those 3
[17:04:01 CEST] <BtbN> LTRs should be fully implemented
[17:04:08 CEST] <philipl> but my nvidia contact is unresponsive these days so no progress there (this bug is in their reference player too so I can't compare to anything)
[17:04:43 CEST] <wm4> oh, if it's from gb, maybe wait what he has to say
[17:04:48 CEST] <nevcairiel> BtbN: st_rps_bits is easy
[17:04:50 CEST] <BtbN> yes, LTRPSPS_A_Qualcomm_1.bit plays fine.
[17:04:51 CEST] <philipl> At a guess, 'st_rps_bits' would be the number of its
[17:04:55 CEST] <wm4> haven't heard anything from him for almost a week though
[17:04:55 CEST] <philipl> bits
[17:05:14 CEST] <BtbN> at least i can't spot anything that looks wrong
[17:05:17 CEST] <nevcairiel> BtbN: look at dxva2_hevc.c, 94-97
[17:05:56 CEST] <nevcairiel> vaapi doesnt seem to have the other variable there, but the bit count variable is this one
[17:06:09 CEST] <philipl> right
[17:07:11 CEST] <nevcairiel> for the other two ..  dxva has them too
[17:07:16 CEST] <nevcairiel> but i dont set them
[17:07:25 CEST] <philipl> dun dun dun.
[17:07:44 CEST] <nevcairiel> from the dxva spec:
[17:07:45 CEST] <nevcairiel> Note  This flag does not correspond to any indication provided in the HEVC bitstream itself. Thus, a host software decoder would need some external information (e.g. as determined at the application level) to be able to set this flag to 1. In the absence of any such available indication, the host software decoder must set this flag to 0.
[17:08:15 CEST] <philipl> Odd. I guess it's in vaapi because it's in dxva?
[17:08:28 CEST] <nevcairiel> maybe it does serve some kind of purpose which i just dont understand
[17:08:51 CEST] <nevcairiel> the dxva spec was written by someone who knows hevc really well, so it must be of some use to someone
[17:10:42 CEST] <nevcairiel> setting them can probably yield some small performance optimizations
[17:12:48 CEST] <BtbN> I'll just leave them alone for now.
[17:26:20 CEST] <BtbN> https://bpaste.net/show/0aeee9f3a759 https://bpaste.net/show/f7f14df11de3
[17:26:34 CEST] <BtbN> At least the trace log thinks the ScalingList buffer is a VAIQMatrixBufferH264
[17:26:57 CEST] <nevcairiel> that may as well be a reason for a problem
[17:27:20 CEST] <BtbN> it does so for both gst and ffmpeg
[17:27:47 CEST] <BtbN> va_TraceVAIQMatrixBufferHEVC does exist though
[17:28:09 CEST] <nevcairiel> https://www.mail-archive.com/libva@lists.freedesktop.org/msg03203.html
[17:28:30 CEST] <nevcairiel> if thats the full extent of the problem, probably not related
[17:29:38 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va_trace.c#n3240
[17:29:40 CEST] <BtbN> that's the problem
[17:29:45 CEST] <BtbN> copy-paste problem
[17:31:28 CEST] <BtbN> Not something that should affect decoding
[17:41:32 CEST] <BtbN> The ScalingLists ffmpeg produces are diffrent from what gst generates.
[17:41:39 CEST] <BtbN> Similar in most parts, but some are diffrent
[17:41:54 CEST] <nevcairiel> different how
[17:42:24 CEST] <BtbN> https://bpaste.net/show/87c85cfce8ec (gst)
[17:42:29 CEST] <BtbN> https://bpaste.net/show/8d7bbd4131cb (ffmpeg)
[17:42:44 CEST] <BtbN> starting at line ~320
[17:42:55 CEST] <nevcairiel> those are long scaling lists
[17:43:41 CEST] <kierank> some encoder optimised for metrics do that
[17:43:44 CEST] <kierank> encoders
[17:44:23 CEST] <nevcairiel> seems like the order is different
[17:45:08 CEST] <nevcairiel> but as gst also has issues decoding the files..
[19:10:09 CEST] <durandal_1707>  anybody against pushing stack filters?
[19:10:34 CEST] <wm4> not me
[19:11:04 CEST] <Daemon404> me neither
[19:47:22 CEST] <kierank> is there a way to decode only iframes from ffmpeg.c or the api?
[19:53:24 CEST] <ubitux> kierank: skip_frame nokey?
[19:54:17 CEST] <kierank> ah thanks
[19:54:47 CEST] <kierank> just wanted to see what would happen with intrarefresh
[19:54:47 CEST] <ubitux> so, av_dict_set(&dec_opts, "skip_frame", "nokey", 0) probably
[19:55:01 CEST] <ubitux> but you can do it on the fly too
[19:55:29 CEST] <ubitux> avctx->skip_frame = AVDISCARD_NONKEY maybe
[20:05:50 CEST] <nevcairiel> kierank: probably doesnt output anything with intra refresh =p
[20:06:28 CEST] <kierank> Yeah
[20:06:31 CEST] <kierank> Totally empty
[00:00:00 CEST] --- Thu Aug 27 2015