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

[burek]

[00:05:00 CEST] <J_Darnley> WTF!
[00:07:09 CEST] <BBB> poor J_Darnley...
[00:07:15 CEST] <BBB> are you trying to udnerstand MpegEncContext?
[00:07:25 CEST] <BBB> its a rabbit hole! beware
[00:08:44 CEST] <J_Darnley> Heh.  Might be better than dirac.
[00:09:10 CEST] <J_Darnley> Well atleast that *is* identical now.
[00:19:31 CEST] <atomnuker> jkqxz: one thing I don't get is why a wrapped avframe codec is needed?
[00:19:57 CEST] <atomnuker> is lavd only able to output packets?
[00:20:04 CEST] <nevcairiel> its basically a demuxer
[00:20:05 CEST] <nevcairiel> so yes
[00:20:06 CEST] <jkqxz> Yes.  lavd is lavf.
[00:20:37 CEST] <nevcairiel> didnt we also have this concept of raw packets
[00:22:31 CEST] <nevcairiel> maybe that was only supported for muxing
[00:24:17 CEST] <kierank> it's basically a hack to avoid memcpy
[00:24:25 CEST] <kierank> and shuffle between avformat and avcodec
[00:25:19 CEST] <atomnuker> what's going to be the pix_fmt of the decoded avframe?
[00:25:38 CEST] <atomnuker> AV_PIX_FMT_DRM_PRIME?
[00:26:14 CEST] <jkqxz> It's representing a DRM object in GPU memory.  See the first patch.
[00:26:20 CEST] <atomnuker> (so you'd have to hwdownload it if you wanted to feed it into a cpu encoder?)
[00:26:21 CEST] <jkqxz> (This is why it can't use rawvideo at all.)
[00:26:28 CEST] <jkqxz> Yes, you would.
[00:26:31 CEST] <atomnuker> cool
[00:26:54 CEST] <jkqxz> (And this might be hard if it's tiled somehow.)
[00:43:25 CEST] <wm4> why am I getting compilation errors in simple_idct.c
[00:43:46 CEST] <wm4> int vs. ptrsdiff_t
[00:44:26 CEST] <wm4> oh, this file was removed and was somehow stale in my checkout? then why is it compiled
[00:44:57 CEST] <nevcairiel> simple_idct.c still exists in libavcodec/, just not in libavcodec/x86/
[00:45:10 CEST] <wm4> this was the x86 one
[00:45:38 CEST] <nevcairiel> the makefile just references a .o file, maybe it got confused what source to use
[00:46:39 CEST] <kierank> i had the same problem
[00:46:56 CEST] <nevcairiel> how do you even end up with a stale .c file, git should just delete it when you update
[00:48:43 CEST] <kierank> it was the .d file
[00:49:40 CEST] <nevcairiel> thats a different problem then =p
[02:52:26 CEST] <jamrial> jkqxz: check my fix for ticket 6644. your coded bitstream api is also unable to parse this weird/broken VUI syntax where default_display_window is not present at all
[09:06:10 CEST] <cone-460> ffmpeg 03Tobias Rapp 07master:d47159a42d8a: fate: add test for asetnsamples filter with padding disabled
[10:35:15 CEST] <cone-460> ffmpeg 03Nicolas George 07master:f5a9c63401c8: lavfi: guess a timestamp for compat status change.
[10:35:16 CEST] <cone-460> ffmpeg 03Nicolas George 07master:dfed8e2cbb48: ffmpeg: rename a variable.
[10:35:16 CEST] <cone-460> ffmpeg 03Nicolas George 07master:36c111c40f4b: ffmpeg: use reordered duration for stream PTS.
[10:35:17 CEST] <cone-460> ffmpeg 03Nicolas George 07master:5ba2aef6ec47: lavfi/buffersrc: add av_buffersrc_close().
[10:35:18 CEST] <cone-460> ffmpeg 03Nicolas George 07master:8043d8eb3bf5: ffmpeg: send EOF pts to filters.
[11:23:31 CEST] <durandal_1707> wm4: will you apply sup muxer??
[13:16:25 CEST] <ubitux> so& should i push the perf patchset?
[13:46:05 CEST] <BBB> ubitux: I think so, if you like it
[13:51:08 CEST] <cone-058> ffmpeg 03Kaustubh Raste 07master:2e79813a8ec7: avcodec/mips: Improve vp9 lpf msa functions
[13:51:09 CEST] <cone-058> ffmpeg 03Kaustubh Raste 07master:c75b23cbea79: avcodec/mips: Improve vp9 idct msa functions
[13:51:10 CEST] <cone-058> ffmpeg 03Kaustubh Raste 07master:9b2c3c406fdd: avcodec/mips: Improve vp9 mc msa functions
[13:51:11 CEST] <cone-058> ffmpeg 03Mark Wachsler 07master:fde5c7dc79eb: libavcodec/h264_parse: don't use uninitialized value when chroma_format_idc==0
[14:10:15 CEST] <kierank> BBB: ubitux: do you have any comments on the number differences?
[14:10:18 CEST] <kierank> i.e which one is right?
[14:11:08 CEST] <BBB> number difference?
[14:11:15 CEST] <BBB> sorry, need context
[14:28:49 CEST] <ubitux> kierank: the kernel perf api has an overhead due to i guess various function calls internally
[14:29:22 CEST] <ubitux> whether our heuristics are better than the one in the kernel, i can't say
[14:29:31 CEST] <kierank> BBB: difference between the old measurement and the perf one
[14:29:50 CEST] <BBB> oh, dont ask me, I dont know :-p
[14:30:07 CEST] <wbs> well as long as direct inlined instruction measurement is noiseless (no scheduler interruptions etc) that's obviously always better and correct
[14:30:12 CEST] <ubitux> someone should probably make a graph of the two so we can see if they are at least proportionnal, or if it's a relatively constant overhead, etc
[14:31:02 CEST] <wbs> ubitux: I thought about implementing the same, but you beat me to it - in general I guess it makes sense on arm, although the previous one that requires kernel enabling always should be preferred if usable
[14:31:40 CEST] <wbs> I guess the main question is if the perf based one is noiseless enough to be usable for benchmarking/tuning of asm implementations
[14:31:46 CEST] <wbs> and I think it is
[14:32:03 CEST] <ubitux> current politic is to only weakly enable it on arm and aarch64
[14:32:40 CEST] <ubitux> the perf results are actually passed through the same ffmpeg heuristics
[14:32:48 CEST] <ubitux> maybe that should be avoided?
[14:32:55 CEST] <wbs> I don't think it matters
[14:33:03 CEST] <ubitux> i'm assuming it helps for the first cold runs
[14:33:12 CEST] <wbs> possibly yeah
[14:33:19 CEST] <ubitux> with checkasm it also helps removing the "nop" cost
[14:34:31 CEST] <ubitux> atomnuker suggested to use another PERF_COUNT_HW
[14:34:34 CEST] <ubitux> i don't remember which
[15:58:42 CEST] <BBB> ubitux: do you need further testing for your patchset? or is it waiting on something to be applied other than formal review?
[15:59:16 CEST] <ubitux> which one? perf?
[15:59:23 CEST] <ubitux> i don't mind further testing
[15:59:26 CEST] <BBB> autodetect
[15:59:31 CEST] <BBB> or, rather, disable-autodetect
[15:59:42 CEST] <BBB> sorry, that was confusing
[15:59:46 CEST] <ubitux> ah, well, i tested it, but that might not cover all the cases
[16:00:00 CEST] <ubitux> disable-autodetect is upstream
[16:00:09 CEST] <ubitux> what's left is the apple things
[16:00:11 CEST] <BBB> yes
[16:00:19 CEST] <ubitux> it tested with --disable-autodetect --enable-xxx individually and it worked
[16:00:31 CEST] <ubitux> now i don't know, maybe it doesn't work with old osx, or even cross compile
[16:00:34 CEST] <ubitux> i didn't test those
[16:26:44 CEST] <cone-058> ffmpeg 03Ilia Valiakhmetov 07master:83c12fefd22f: avcodec/pthread_slice: add ff_slice_thread_execute_with_mainfunc()
[16:26:45 CEST] <cone-058> ffmpeg 03Ilia Valiakhmetov 07master:e59da0f7ff12: avcodec/vp9: Add tile threading support
[17:25:58 CEST] <gh0st__> Should I update the libavcodec/version.h for vp9 tile threading feature?
[17:27:47 CEST] <gh0st__> And in general how libavcodec/version.h is updated? What criteria should be met for it to be updated?
[17:29:34 CEST] <jamrial> gh0st__: version is updated usually if api or anything facing the user is affected. new/removed modules bump minor, new/removed options bump micro, etc
[17:30:05 CEST] <jamrial> gh0st__: i don't think this requires a version bump, but it could use a changelog entry
[17:30:43 CEST] <gh0st__> jamrial: ok, thanks for explanation.
[17:39:09 CEST] <BBB> slice-threading is  auser-facing feature
[17:39:15 CEST] <BBB> I think micro bump might be ok
[17:44:29 CEST] <BBB> gh0st__: your commit message is strange - youre adding a note to changelog about adding tile threading, not actually adding tile threading ;)
[17:44:43 CEST] <BBB> changelog: mention vp9 tile threading feature
[17:44:45 CEST] <BBB> (or so)
[17:46:50 CEST] <jkqxz> jamrial:  Did you try it and something actually goes wrong?  It correctly says that the bitstream is invalid for me.
[17:47:06 CEST] <gh0st__> BBB: Your right, duh. =)
[17:48:12 CEST] <gh0st__> BBB: I'll be careful next time.
[17:48:15 CEST] <jkqxz> (More generally, I'm against adding absurd hacks to parse consistently broken bitstreams - it's just wrong, say so and discard it.
[17:48:19 CEST] <jkqxz>  But I think I'm in a minority on that one, and I don't want to start a fight on the ML.)
[17:48:19 CEST] <jamrial> jkqxz: it gets values all wrong and aborts as it tries to read vui display window information from bits that are from vui timing information
[17:48:48 CEST] <jamrial> jkqxz: just pointing it out. the decoder needs to handle these since they are real world samples
[17:48:54 CEST] <jkqxz> Ah, the one from the ML is still lacking overread detection.
[17:48:58 CEST] <jamrial> but you're not forced to support them in your reader api
[17:49:00 CEST] <jkqxz> That exists in newer versions.
[17:50:19 CEST] <jkqxz> (Ends on "[AVBSFContext @ 0x277a9a0] Invalid ue-golomb code at max_bytes_per_pic_denom: bitstream ended.".)
[17:51:10 CEST] <jamrial> with trace_headers bsf i get "max_bytes_per_pic_denom out of range: 1023, but must be in [0,16]."
[17:51:40 CEST] <jamrial> but yeah, that's because the entire display window stuff is missing, so your reader is looking at the wrong stuff
[17:51:42 CEST] <jkqxz> Yeah, it'll be reading over the end of the stream with that version.
[17:52:08 CEST] <jamrial> i wonder what encoder is writing these files with truncated sps...
[17:52:11 CEST] <jkqxz> There is some stuff pending in libav and once that is crystallised I'll re-merge and send it again.
[17:53:03 CEST] <jkqxz> Do we know of any other decoders containing crazy hacks to handle these files?
[17:53:29 CEST] <jamrial> not that i'm aware. i tried a hevc bitstream browser and it handled it much like your cbs reader
[17:54:27 CEST] <jamrial> but since the file is fully playable if you workaround the missing bits, the best option is to try to parse them right, at least for the decoder
[17:56:41 CEST] <jkqxz> I guess whoever made that encoder must have only tested with decoders which just stop at vui_parameters_present_flag, since nothing after that point is actually necessary for normal decode.
[17:58:33 CEST] <jamrial> it is for raw bitstreams, since you wouldn't be able to get framerate without reading the vui timing information part
[17:58:43 CEST] <jamrial> afaik
[17:59:34 CEST] <jkqxz> Framerate sounds unnecessary for decoding...
[17:59:52 CEST] <jamrial> playback then
[18:01:27 CEST] <ubitux> michaelni: any other comment on the perf patchset?
[18:06:12 CEST] <BBB> jamrial: the vps also contains timing info
[18:08:08 CEST] <jkqxz> It doesn't in the sample file for this problem.
[18:08:26 CEST] <jamrial> BBB: at least with sample (or rather, the raw bitstream extracted out of the matroska container), before my patch, were sps vui timing info is not parsed, libavcodec reports a generic 25fps. with my patch it reads the timing information and gets the correct 29.97
[18:08:59 CEST] <BBB> sps vui timing info != vps timing info
[18:09:03 CEST] <BBB> it contains the same information
[18:09:08 CEST] <BBB> but its not the same bits in the bitstream
[18:09:15 CEST] <BBB> whether the file contains it is indeed a different matter ;)
[18:09:33 CEST] <jamrial> s/least with/least with this/
[18:10:17 CEST] <jamrial> that's the thing, vps timing info is evidently not present in this file :p
[18:10:24 CEST] <jkqxz> <http://sprunge.us/HddR>, vps_timing_info_present_flag = 0.
[18:10:44 CEST] <BBB> I was commenting more generally about you wouldnt be able to get framerate w/o reading the vui timing
[18:10:52 CEST] <BBB> you can, if the file contains vps timing ;)
[18:11:09 CEST] <BBB> anyway, youre right, this file doesnt contain it so not ueful for this conversation
[18:11:23 CEST] <jamrial> ah, true
[18:11:55 CEST] <doublya> I'm trying to encore a video with a gt 1030 with hevc_nvenc. nvenc_open_session(avctx) on line 381 of nvenc.c is failing. "unsupported device (2)"
[18:12:15 CEST] <BtbN> a 1030 does not have a hardware encoding unit.
[18:12:38 CEST] <BtbN> also not a question for this channel.
[18:14:59 CEST] <michaelni> ubitux, no more comments from me about perf, i seems to build fine on all i tested
[18:15:25 CEST] <ubitux> alright, thanks
[18:15:33 CEST] <ubitux> i'll push it then
[18:15:45 CEST] <ubitux> i'll push the configure OSX stuff too pretty soon
[18:15:51 CEST] <ubitux> unless someone wants to review it
[18:16:56 CEST] <doublya> Thanks. Well I asked here because I was under the impression it did have an encoding unit.  I was debugging the src to see why it was failing.  Thanks.
[18:30:55 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:cf0eed2525bd: avfilter: add Haas stereo enhancer
[18:42:38 CEST] <kurosu> regarding the hevc vui stuff, when looking why it would look like this, I wound up on a development version of hevc, ie non-standard but pretty much like those many mpeg4 part2 bastardized implementations that each needs its own quirks
[18:43:25 CEST] <kurosu> hard to identify, except "that didn't look right", which is what's being done/about to be done
[18:47:13 CEST] <jamrial> maybe we should abort on these files if err_detect is set to compliant, for that matter
[18:52:54 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:e0d56f097f42: checkasm: use perf API on Linux ARM*
[18:52:55 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:9c0d823a7c2c: lavu/timer.h: factor out timer report
[18:52:56 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:dc27df47ff99: lavu/tests/des: rename crypt to crypt_ref
[18:52:57 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:e0b9b3e60ea3: lavu/tests: move timer.h include earlier
[18:52:58 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:f61379cbd45a: lavu/timer.h: add Linux Perf API support
[18:56:23 CEST] <atomnuker> ubitux: should have used PERF_COUNT_HW_REF_CPU_CYCLES
[18:57:06 CEST] <ubitux> isn't 3.3 a bit too recent?
[18:57:19 CEST] <ubitux> do you observe a difference in results?
[18:57:33 CEST] <atomnuker> good point, didn't notice
[18:57:45 CEST] <atomnuker> nope, didn't have time to benchmark
[18:59:36 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:b476e7720c06: build: fix objcc header check
[18:59:37 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:f8519529cfed: lavfi/coreimage: reduce dependency scope from QuartzCore to CoreImage
[18:59:38 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:b6dce64a8ea5: build: add check_apple_framework()
[18:59:39 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:97d8013582f5: build: add --disable-avfoundation autodetect switch
[18:59:40 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:496d0178b0ed: build: add --disable-coreimage autodetect switch
[18:59:41 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:1cf23e3fddd1: build: cleanup audiotoolbox handling
[18:59:42 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:260ea7a7b395: build: cleanup videotoolbox
[19:02:22 CEST] <kurosu> jamrial, dunno, I guess the user-friendliness of mpeg4p2 quirk handling must be continued - if that's at least frequent, it's not unwarranted
[19:03:25 CEST] <kurosu> pinged j-b about vdd, but he probably has bigger fish to fry
[19:03:50 CEST] <kurosu> would anyone in here know whom I could ask for more details ?
[19:03:54 CEST] <kierank> jamrial: 
[19:03:57 CEST] <kierank> j-b: ^
[19:03:58 CEST] <kierank> sorry
[19:05:00 CEST] <kurosu> I queried/private messaged him already a day ago, don't want to bother him further
[19:05:06 CEST] <BBB> kurosu: what do you want to know?
[19:05:12 CEST] <BBB> kurosu: you can ask felix
[19:06:03 CEST] <kurosu> will probably need housing accommodations and wanted to know who would be my "hostelmate"
[19:06:10 CEST] <kurosu> also a more precise location
[19:07:02 CEST] <kierank> I wonder when "who can't share with whom" will become NP hard
[19:07:53 CEST] <kurosu> I know nobody enough to have any preference or for someone to have such a preference
[19:08:28 CEST] <kurosu> ok, the location was added since 2 days ago, it seems
[19:10:32 CEST] <atomnuker> I'm just wondering if thursday night is sponsored too
[19:10:42 CEST] <atomnuker> j-b said it probably would be but that was over a month ago
[19:11:23 CEST] <kurosu> I'd be arriving on friday afternoon at best
[19:11:56 CEST] <kurosu> but that's likely an interesting thing for a lot of (more regular) attendees
[21:42:48 CEST] <durandal_1707> Compnn: did you knew that you can have opengl display in console?
[21:46:45 CEST] <atomnuker> durandal_1707: that's how wayland compositors work, lol
[21:51:34 CEST] <Compnn> durandal_1707 : egl or the other gl i'm forgetting about ?
[21:51:42 CEST] <Compnn> cant remember the name
[21:51:48 CEST] <Compnn> mesagl ... no, another one
[21:51:56 CEST] <durandal_1707> atomnuker: i have ffmpeg displaying stars in console, it can be screensaver
[21:52:49 CEST] <durandal_1707> Compnn: backend of some sort
[21:55:32 CEST] <jkqxz> Does SDL have a KMS backend?
[21:55:40 CEST] <atomnuker> never worked
[21:57:52 CEST] <atomnuker> durandal_1707: you mean a VT (e.g. ctrl+alt+f1), right?
[21:58:09 CEST] <JEEB> drm stuff
[21:58:39 CEST] <durandal_1707> atomnuker: yes
[21:59:00 CEST] <durandal_1707> JEEB: drm vo drops frames
[21:59:32 CEST] <JEEB> k
[23:38:40 CEST] <BBB> michaelni: 22553U typo?
[23:38:54 CEST] <BBB> michaelni: Im assuming that should be (unsigned)i_ict_params[1]?
[23:45:01 CEST] <michaelni> BBB, yes, ill change it
[00:00:00 CEST] --- Sat Sep  9 2017