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

[burek]

[00:11:12 CEST] <michaelni> ubitux, deleted SAMI_ass_capability_tester.smi
[00:12:03 CEST] <ubitux> michaelni: thx! :)
[00:14:34 CEST] <michaelni> np
[00:39:20 CEST] <BtbN> Someone happens to know how to calculate http://cgit.freedesktop.org/vaapi/libva/tree/va/va_dec_hevc.h#n268 this field from the ffmpeg HEVCContext? I can't see any obvious indication for it there.
[00:39:32 CEST] <BtbN> Do I just have to add up the size of all NALs in the HEVCPacket?
[00:40:21 CEST] <nevcairiel> vaapi uses a long slice structure? well, "haw-haw" </nelson> :p
[00:40:40 CEST] <BtbN> vaapi also does some other bullshit for hevc
[00:41:02 CEST] <BtbN> like, ignoring its own common structures, and making new common structures with a HEVC suffix, rendering large parts of the common code useless
[00:41:10 CEST] <nevcairiel> for h264 long slices, it works doing this: slice->BitOffsetToSliceData  = get_bits_count(&sl->gb);
[00:41:43 CEST] <nevcairiel> so, getting the number of read bits from the read buffer
[00:42:00 CEST] <nevcairiel> (in dxva2)
[00:42:10 CEST] <BtbN> yeah, for vaapi h264 it's the same code
[00:42:17 CEST] <BtbN> But for hevc it only wants bytes, not bits
[00:42:31 CEST] <nevcairiel> >> 3
[00:42:32 CEST] <nevcairiel> :P
[00:43:23 CEST] <BtbN> So my idea would be just to add up the sizes of all HEVCNAL's in the HEVCPacket of the HEVCContext
[00:43:44 CEST] <BtbN> Or maybe the raw_size?
[00:45:15 CEST] <nevcairiel> if its anything like the bitoffset field for h264, then thats not the value it wants
[00:47:55 CEST] <BtbN> The HEVC SliceHeader does have a size field, but it's an int*?
[00:54:31 CEST] <wm4> BtbN: are you trying hevc ffmpeg hwaccel decoding?
[00:54:36 CEST] <BtbN> yep
[00:54:42 CEST] <wm4> k
[00:55:19 CEST] <BtbN> i should propably not stop at every single weird thing, and put a TODO there instead
[01:08:46 CEST] <rcombs> http://puu.sh/jCXAR/f8da3ae246.mkv <-- user reports a regression decoding this file where MP3 frames don't line up with Matroska packets; mpv works with it fine, but ffplay and ffmpeg.c report "Header missing" and produce garbled audio
[01:11:21 CEST] <rcombs> somewhere between a5e5959d52860678d028df07ad1351a11aaf47f7 and fefe04259ae903f265074ef3e8db7e0941f00307
[01:13:46 CEST] <wm4> mpv actually uses libavcodec's mp3 parser for this
[01:14:36 CEST] <rcombs> I thought at first it was using mpg123 but apparently that was removed while I wasn't looking
[01:14:52 CEST] <wm4> yep
[01:34:24 CEST] <rcombs> wm4: ah, yeah, it behaves the same as ffplay with `-demuxer lavf`
[01:41:24 CEST] <rcombs> hmm, and I'm not quite sure why that would've regressed
[01:46:20 CEST] <rcombs> but it's definitely fine in the earlier version, so :shrug:
[01:46:40 CEST] <rcombs> well, for some definition of "fine"
[01:47:35 CEST] <rcombs> it warns once about an "incomplete frame" but that's about it
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:72237ef6e933: ffmpeg_filter: Do not override the dimensions in sub2video_prepare()
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:0ac83047f67b: ffmpeg: Print sub2video: rectangle coordinates in case of overflows
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:bd5d11d9f5fd: ffmpeg: Use actual frame dimensions in checks in sub2video_update()
[02:16:25 CEST] <cone-144> ffmpeg 03Michael Niedermayer 07master:4ada49f9dbed: ffmpeg: Use the decoders dimensions in sub2video_get_blank_frame()
[02:31:50 CEST] <jamrial> allyuv.png 28.2mb, allyuv.bpg (lossless) 6.3mb, allyuv.webp (lossless) 1.3mb
[02:34:03 CEST] <ubitux> yeah bgp is not really for lossless
[02:34:31 CEST] <ubitux> and webp is actually designed to replace both jpg & png, right?
[02:34:47 CEST] <jamrial> yeah
[02:35:10 CEST] <jamrial> i'm suprised at how badly png did here more than anything
[02:36:29 CEST] <ubitux> isn't it simply because our encoder is bad?
[02:36:45 CEST] <ubitux> what happened after an optipng on it?
[02:36:50 CEST] <jamrial> ah, could be
[02:38:40 CEST] <cone-144> ffmpeg 03Mariusz SzczepaDczyk 07master:767d780ec001: doc/examples: rename avio_list_dir -> avio_dir_cmd
[02:39:38 CEST] <jamrial> running optipng -o7, give me a few minutes :p
[02:39:54 CEST] <ubitux> i'm running it as well... :D
[02:43:53 CEST] <ubitux> this reminds me the dark ages of libvpx encoding vp9 hd footage
[02:45:00 CEST] <jamrial> did it get better since then?
[02:45:06 CEST] <ubitux> no idea
[02:45:28 CEST] <ubitux>   zc = 9  zm = 9  zs = 0  f = 2IDAT size = 2073183
[02:45:33 CEST] <ubitux> so about 2M with these settings
[02:45:37 CEST] <jamrial> also, bgpenc took several minutes as well enconding this image, all while eating 1gb of ram
[02:45:44 CEST] <ubitux> haha
[02:46:00 CEST] <ubitux>   zc = 9  zm = 9  zs = 1  f = 2IDAT size = 2071737
[02:46:04 CEST] <ubitux> ~2M again
[02:54:43 CEST] <ubitux> yeah in the end that's what you get
[02:54:47 CEST] <ubitux> 2M after optipng
[02:55:06 CEST] <ubitux> webp still much better, but png remains decent
[03:12:07 CEST] <wm4> ffmpeg's encoder can be made to use some extended png features
[03:12:21 CEST] <wm4> obscure avoptions
[03:27:12 CEST] <rcombs> welp I'm failing miserably at `git bisect run`
[03:27:21 CEST] <rcombs> landing on nonsense
[03:28:13 CEST] <rcombs> is there something I have to do to avoid libav merge funkiness
[03:37:21 CEST] <Plorkyeran> there's nothing built in to git for it
[03:38:10 CEST] <Plorkyeran> git bisect doesn't really work when you commit broken things then fix them in the next commit
[03:38:40 CEST] <Plorkyeran> unless there's something you can do to distinguish that sort of brokenness from the brokenness you're looking for
[04:52:57 CEST] <rcombs> ah-ha!
[04:52:59 CEST] <rcombs> regressed in 8ca098f4445cd12d39b2c55b0dfb8c988b7b28ce
[07:21:10 CEST] <atomnuker> libmodplug does a nice job with everything except midi files
[07:21:52 CEST] <atomnuker> it should support timidity samples (pat instruments) but it isn't working
[07:22:41 CEST] <atomnuker> the code apparently only pokes to see if timidity.cfg exists in some defined directory and falls back to horribly using software FM synthesis for instruments
[07:24:33 CEST] <atomnuker> If no one can confirm it has ever worked for them I'll probably write a decoder using libmodplug, an actual still living project
[07:24:48 CEST] <atomnuker> *libfluidsynth
[08:45:44 CEST] <rcombs> anyone around who knows mpegaudio_parser?
[08:45:55 CEST] <rcombs> wtb some examination of https://trac.ffmpeg.org/ticket/4776
[08:46:28 CEST] <rcombs> it's the `if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES)` branch in 8ca098f4445cd12d39b2c55b0dfb8c988b7b28ce that causes the bug (removing it fixes it), but I'm not sure if that's there for a reason
[09:02:41 CEST] <nevcairiel> if its possible that frames dont line up with packets, then it probably shouldnt set the flag that triggers the complete frames thingy
[09:08:36 CEST] <nevcairiel> (in matroskadec)
[09:08:49 CEST] <nevcairiel> seems like a bad mux though
[09:10:02 CEST] <rcombs> yeah
[09:10:24 CEST] <rcombs> but apparently at least some other software handles it, and it used to work in ffmpeg
[09:24:42 CEST] <ubitux1> rcombs: there is a ffbisect to avoid the libav merges
[09:25:13 CEST] <rcombs> where?
[09:25:56 CEST] <ubitux1> rcombs: tools/bisect-create maybe
[09:26:18 CEST] <ubitux1> it will create a tools/ffbisect
[09:26:27 CEST] <ubitux1> dunno how it works in details, never used it
[09:27:24 CEST] <rcombs> looks like it basically checks if ffmpeg.c exists
[09:27:38 CEST] <rcombs> which is basically what I ended up doing but less dumb
[09:27:39 CEST] <ubitux1> yeah, it avoids landing in a libav state
[09:27:57 CEST] <rcombs> and skips otherwise
[09:28:02 CEST] <rcombs> simple enough
[12:35:14 CEST] <durandal_1707> michaelni: could you look at #3847?
[12:39:56 CEST] <cone-491> ffmpeg 03Michael Niedermayer 07master:31d6f8de53bf: doc/filter_design: Remove reference to the deprecated and unused cur_buf_copy
[12:39:56 CEST] <cone-491> ffmpeg 03Rodger Combs 07master:b4b2717ffe89: lavf/matroskadec: Fully parse and repack MP3 packets
[13:29:21 CEST] <Compn> ubitux1 / rcombs : does any of that need to be in developer documentation ?
[13:29:27 CEST] <Compn> re libav merge bisecting
[13:30:29 CEST] <rcombs> Compn: probably worthwhile
[13:31:02 CEST] <rcombs> just saying "make the first line of your `bisect run` script `[ -f ffmpeg.c ] || exit 125`" gets you a decent stretch of the way there
[13:31:47 CEST] <rcombs> and then the bisect-create script works if you're doing it manually
[14:21:33 CEST] <Compn> rcombs : post to ml if you can and someone will make a docs patch...
[14:21:35 CEST] Action: Compn afk
[15:27:25 CEST] <BtbN> Does HEVC only ever have one slice per frame?
[15:28:41 CEST] <cone-491> ffmpeg 03Michael Niedermayer 07master:0cb87cd7d4cf: avfilter/avfiltergraph: Implement and use find_best_sample_fmt_of_2()
[15:31:24 CEST] <iive> BtbN: only if you want to
[15:31:56 CEST] <BtbN> Well, I'm trying to write vaapi hevc hwaccel, and vaapi wants to know a slice_data_byte_offset
[15:32:03 CEST] <BtbN> And i have no idea where to get it from
[15:32:19 CEST] <BtbN> "Byte offset from NAL unit header to the begining of slice_data()"
[15:33:05 CEST] <BBB> BtbN: isnt that the same as slice header length?
[15:33:23 CEST] <BtbN> https://github.com/gbeauchesne/gstreamer-vaapi/blob/master/gst-libs/gst/vaapi/gstvaapidecoder_h265.c#L2315
[15:33:28 CEST] <BtbN> that's how gstreamer calculcates it
[15:33:31 CEST] <BtbN> so i'd say yes
[15:34:46 CEST] <BBB> I dont think we export it at this point, but feel free to add a field with the appropriate value at the bottom of hls_slice_header
[15:35:12 CEST] <iive> BtbN: this is hunaly readable explanation of h265 features http://www.f265.org/f265/static/txt/h265_companion.html
[15:35:19 CEST] <iive> humanly...
[15:35:35 CEST] <BBB> do you call hls_slice_header in vaapi_hevc?
[15:35:41 CEST] <BBB> or is there some other interafce?
[15:35:56 CEST] <BtbN> The normal hevc code calls into the hwaccel i think
[15:36:00 CEST] <BtbN> so it should be called automaticaly
[15:36:17 CEST] <BBB> something like get_bits_count(s->HEVClc->gb) should work upon initial frame decoding
[15:36:45 CEST] <BBB> and then align and >>3 it to get byte
[15:36:56 CEST] <BtbN> But isn't that per-frame?
[15:37:05 CEST] <BBB> no, thats called for each slice
[15:37:11 CEST] <BBB> each nal unit
[15:37:24 CEST] <BBB> so if a frame has multiple nal units / slices, its called multiple times
[15:40:15 CEST] <BtbN> So basicaly slice_param->slice_data_byte_offset = (get_bits_count(h->HEVClc->gb) + 7) / 8; should be enough?
[15:40:34 CEST] <BBB> I believe so
[15:40:48 CEST] <BtbN> Maybe + 1, as the nal_unit_type has already been read before
[15:41:06 CEST] <BBB> thats possible, it depends on where the gb is initialized
[15:41:18 CEST] <BtbN> The h264 vaapi code adds 8
[15:41:22 CEST] <BtbN> for the same reason
[15:42:12 CEST] <BBB> init_get_bits8(gb, nal->data + 2, nal->size);
[15:42:17 CEST] <BBB> so it may be +2, not +1
[15:42:28 CEST] <BBB> anyway, try values, compare with gstreamer, and see what the correct value is :-p
[15:43:01 CEST] <BBB> buf[1] is the temporal id, apparently?
[15:43:43 CEST] <BBB> bbl
[16:03:32 CEST] <BtbN> The vaapi error communication is also very nice
[16:04:14 CEST] <BtbN> VA_STATUS_ERROR_INVALID_VALUE
[17:54:03 CEST] <durandal_1707> michaelni: thanks
[17:55:29 CEST] <michaelni> np
[18:17:44 CEST] <cone-491> ffmpeg 03Andreas Cadhalpun 07master:fbc8eb685784: ffmpeg: use av_buffersrc_add_frame instead of av_buffersrc_add_ref
[18:21:29 CEST] <BtbN> __gb__, do you happen to know if there is a way to get more information out of libva/the intel driver than "Error 18 - invalid parameter"? I tried enabling LIBVA_TRACE and setting VA_INTEL_DEBUG=3, but the trace log only contains the basic function calls and parameters.
[18:59:31 CEST] <kierank> atomnuker, Daemon404: so say 7pm at cheshire cheese?
[18:59:36 CEST] <kierank> on thursday
[19:10:33 CEST] <Daemon404> kierank, do i need to eat first or not
[19:10:37 CEST] <kierank> dunno
[19:10:47 CEST] <Daemon404> 145 Fleet St, London EC4A 2BU
[19:10:49 CEST] <Daemon404> this one?
[19:11:18 CEST] <kierank> yes
[19:11:46 CEST] <Daemon404> sure
[19:11:51 CEST] <Daemon404> tahts walking distance for me
[19:12:36 CEST] <atomnuker> fine by me as well
[22:38:56 CEST] <cone-455> ffmpeg 03Andreas Cadhalpun 07master:d90fbde06a80: buffersink: introduce FIFO_INIT_ELEMENT_SIZE to complement FIFO_INIT_SIZE
[23:06:28 CEST] <philipl> BtbN: sounds like vaapi is keeping you entertained.
[23:08:33 CEST] <wm4> intel stuff always does
[23:17:10 CEST] <Daemon404> lmao debian guy comparing breaking ffmpeg api BS with a libc
[23:18:56 CEST] <wm4> I must join the trolling
[23:19:03 CEST] Action: wm4 looks
[23:24:49 CEST] <wm4> don't see anything about libc
[23:25:45 CEST] <Daemon404> it might have been put in youre libav folder
[23:25:47 CEST] <Daemon404> its on both MLs
[23:25:52 CEST] <Daemon404> your*
[23:26:28 CEST] <wm4> google does that, but I don't see it
[23:26:40 CEST] <nevcairiel> the last mail from andreas, last paragraphj
[23:26:41 CEST] <wm4> or maybe it's an old mail
[23:26:57 CEST] <wm4> oh
[23:27:00 CEST] <wm4> I'm just blind
[23:27:03 CEST] <Daemon404> ;p
[23:27:33 CEST] <Daemon404> i must admit it's really damn annoying to have Mr Distro Maintainer NAK all deprecations ever
[23:28:11 CEST] <wm4> I don't get why he endlessly argues with us instead of the downstreams
[23:28:18 CEST] <wm4> maybe it's because the downstreams are dead or something
[23:28:47 CEST] <Daemon404> it's the least amount of effort
[23:28:58 CEST] <Daemon404> doesnt break -> sit on ass
[23:29:03 CEST] <Daemon404> the distro packager way.
[23:32:00 CEST] <jamrial> i'm with nevcairiel. if we postpone everything we'll be discussing this again in one year
[23:32:13 CEST] <Daemon404> yep
[23:32:50 CEST] <nevcairiel> indeed, a bunch of those have been postponed  before
[23:34:00 CEST] <jamrial> i'm surprised this one guy even said two years between deprectation and removal was too short. and he was talking about the pixfmt stuff that's just adding an AV_ prefix to some defines
[23:34:47 CEST] <Daemon404> [22:29] <@Daemon404> the distro packager way.
[23:35:04 CEST] <Daemon404> clearly you have never dealt with one
[23:39:18 CEST] <wm4> jamrial: imagine you're a package manager... and then someone demands you to ACTUALLY MAINTAIN YOUR PACKAGES
[23:39:21 CEST] <wm4> the horror
[23:40:07 CEST] <JEEB> "wait... I can't just git checkout and build things?"
[23:46:38 CEST] <nevcairiel> its like people asking to update the ffmpeg integraiton in your project, which some random contributor wrote 3 years ago and noone knows how it works
[23:47:08 CEST] <durandal_1707> deprecate all the things
[23:47:47 CEST] <Daemon404> nevcairiel, rm -r?
[23:49:03 CEST] <nevcairiel> but features!
[23:49:16 CEST] <durandal_1707> they want maintainers for free
[00:00:00 CEST] --- Mon Aug 17 2015