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

[burek]

[00:07:15 CET] <michaelni> jamrial, i dont know this code well enough to really comment. But it would be better if changes like this would go overf the ML and are tested by someone or reveiwed by someone who knows the code
[00:13:01 CET] <jkqxz> I don't really care.  I'll skip it.
[00:16:20 CET] <cone-545> ffmpeg 03Diego Biurrun 07master:e2399e0c1aeb: fate: Error out more gracefully on configure failure
[00:16:21 CET] <cone-545> ffmpeg 03Mark Thompson 07master:9053b0885957: Merge commit 'e2399e0c1aeb110456405d23e211066fab6cb041'
[01:21:23 CET] <cone-545> ffmpeg 03Zhong Li 07master:2d6b3f3a9dce: qsvenc: Provide a detailed error message if the parameters are invalid
[01:21:24 CET] <cone-545> ffmpeg 03Mark Thompson 07master:0cf9fa99242a: Merge commit '2d6b3f3a9dce409ca51d70ef4b85c0593bb4b109'
[01:29:33 CET] <cone-545> ffmpeg 03Zhong Li 07master:0645698ecc20: lavc/qsvenc: disable h264 look_ahead by default
[02:17:13 CET] <TimothyGu> michaelni, BtbN: I think I'm mirroring with a cronjob
[04:26:26 CET] <gagandeep_> guys, what does pix_fmt store in avCodecContext?
[04:31:01 CET] <gagandeep_> nevermind, i know now it stores pixel format(rgb, yuv, etc..) ,
[05:06:08 CET] <gagandeep_> kierank: i was unable to run the attatchment files of bug 6675 in windows media player, have you run them after installing the decoder in windows?
[11:03:41 CET] <nevcairiel> hrm lets see if that fate failure in MSVC was fixed in 15.6
[11:45:26 CET] <jcpf> hi, I'm wondering about a check here: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_ps.c#L457
[11:46:02 CET] <jcpf> could anyone tell me why poc_cycle_length couldn't be == to the offset_for_ref_frame length? it doesn't seem to be an overflow in the case of equality?
[11:47:54 CET] <jcpf> in other words, shouldn't the test be > instead of >= ?
[11:53:07 CET] <nevcairiel> the spec limits that field to 255, our array is 256 in size, so its still correct
[11:53:12 CET] <jkqxz> Because the standard says "The value of num_ref_frames_in_pic_order_cnt_cycle shall be in the range of 0 to 255, inclusive.", that array is 256.
[11:53:24 CET] <durandal_1707> jkqxz: how to use kmsgrab on intel?
[11:55:26 CET] <jkqxz> durandal_1707:  Read documentation, follow instructions?
[11:55:42 CET] <jcpf> ah thanks nevcairiel & jkqxz - and the array is 256 for alignment/optimization reasons I suppose?
[11:57:09 CET] <jkqxz> Maybe?  Not sure it would have much effect, given that it will be padded to that anyway.
[11:57:32 CET] <durandal_1707> jkqxz: do i really need to use vaapi?
[11:58:18 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #110: CRC part is also possible with v0/v1 (06master...06crc_v0) 02https://git.io/vA5VK
[11:58:31 CET] <jkqxz> It's also short, which is just wrong because the range is INT_MIN+1 to INT_MAX.  Presumably noone actually uses that feature...
[12:00:14 CET] <jkqxz> durandal_1707:  It can import to other things, too.  OpenCL can work, and I think atomnuker has it working with Vulkan.  You can hwdownload to software, but you will have to untile it yourself if you do.
[12:02:28 CET] <durandal_1707> simple "ffmpeg -f kmsgrab -i - -f null -" gives "No handle set on framebuffer: maybe you need some additional capabilities?"
[12:03:34 CET] <jkqxz> Sounds like you need some additional capabilities.  CAP_SYS_ADMIN, for example.
[12:09:22 CET] <durandal_1707> looks like i will just use Super + R
[12:15:43 CET] <jkqxz> Probably sensible.  kmsgrab is only really intended for when you have a requirement to use ~zero CPU and can cope with the constraints, or weird cases where you want to capture across transitions between environments (switching from X to Wayland, say).
[12:16:50 CET] <jkqxz> If you don't need to do something like that then other methods are much easier.
[12:26:18 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #111: Information about how to terminate the Range Coder (06master...06TerminateRangeCoder) 02https://git.io/vA5r5
[12:54:10 CET] <atomnuker> durandal_1707: "sudo ffmpeg -f pulse -channels 2 -sample_rate 48000 -i default -init_hw_device "vaapi=vp:/dev/dri/renderD128" -f kmsgrab -framerate 30.0 -crtc_id 0 -i /dev/null -filter_hw_device vp -vf hwmap -c:v hevc_vaapi -b:v 8M -compression_level 0 -c:a libopus -b:a 96k -y out.nut"
[12:54:37 CET] <atomnuker> that's what I use when I need to record my screen and can't be bothered to install kde/gnome/whatever's screenshooting api or want video and audio
[12:55:16 CET] <atomnuker> you should set compression level to 7 if you need 60fps
[12:55:44 CET] <atomnuker> (and set the framerate param to kmsgrab to 60 too)
[12:56:36 CET] <atomnuker> also if you want audio not from the microphone you'll need to start up pavucontrol, go to the recording tab and switch the source of lavc to monitor
[12:56:50 CET] <atomnuker> there's a device param for pulseaudio but that's never worked
[12:59:23 CET] <atomnuker> in theory you don't have to init vaapi youseful, you could use hwmap=derive_device=vaapi, but that's never worked for me, I get "libva: va_getDriverName() failed with operation failed,driver_name=i965"
[13:04:13 CET] <atomnuker> also there's no interop between drm and opencl so for now you need to use vaapi
[13:24:48 CET] <jya> is there a particular advantage over the remixer found in libavresample vs the one found in libswresample ?
[13:28:16 CET] <nevcairiel> they are pretty much the same
[13:29:58 CET] <jya> they certainly looks inspired by one another (not sure who came with one before the other etc)
[13:30:17 CET] <durandal_1707> avresample does not support s64(p) sample formats
[13:30:26 CET] <nevcairiel> thats ok, noone needs that
[13:31:27 CET] <jya> libavresample handles the AV_CH_TOP_blah channels
[13:31:35 CET] <jya> not that I've ever seen use of those
[13:32:22 CET] <nevcairiel> handle how?
[13:32:31 CET] <nevcairiel> the mixing matrix generation doesnt seem to account for them
[13:32:39 CET] <jya> you're right... my bad
[13:32:48 CET] <jya> only to determine if a layout is "sane" or not
[13:32:59 CET] <nevcairiel> in fact the mixing matrix code looks quite the same
[13:34:11 CET] <nevcairiel> avr is just nicer indented and has more comments
[13:34:12 CET] <jya> indeed
[13:35:16 CET] <jya> they definitely share common history there (and I'm guessing libavresample copied here)
[13:35:28 CET] <wbs> they're both derived from the same code in libavcodec
[13:41:40 CET] <atomnuker> welp, lavr is deprecated so its on its way out
[13:51:04 CET] <nevcairiel> hrm the fate failues with msvc2017 didnt get fixed in the latest update, maybe i should stop being lazy and figure out a way to report them
[14:28:16 CET] <wbs> nevcairiel: I haven't run fate with msvc on x86, but in 15.5 I got a new failure on arm64 that wasn't there in 15.4 (which was the first release with the arm64 compiler); it's reported at https://developercommunity.visualstudio.com/content/problem/183078/arm64-misoptimizations-in-visual-studio-155.html and allegedly fixed upstream, but the fix didn't seem to make it into 15.6 still
[14:28:42 CET] <nevcairiel> which tests made that fail?
[14:28:58 CET] <wbs> magicyuv and webp
[14:29:06 CET] <nevcairiel> I see magicyuv here as well
[14:29:09 CET] <nevcairiel> but also rmdec
[14:29:14 CET] <nevcairiel> but rmdec only in 32-bit, not in 64-bit
[14:29:18 CET] <nevcairiel> so I might look into that
[14:29:33 CET] <wbs> sounds good
[14:30:54 CET] <nevcairiel> there is also some oddness which i've been blaming in float accuracy things so far, but I haven't had time to look at that more thoroughly
[14:31:33 CET] <nevcairiel> maybe that thought is misleading myself, should give it a look more closely sometime
[15:17:59 CET] <BBB> maybe we should suggest microsoft to run ffmpeg as a test case for their compiler team?
[15:18:01 CET] <BBB> is that crazy?
[15:26:09 CET] <jamrial> gcc afaik does something like that with certain projects that if miscompiled it would be considered a huge regression
[15:26:14 CET] <jamrial> so probably not
[15:26:38 CET] <iive> in the past every gcc x.y.0 version had at least 1 compiler bug
[15:27:39 CET] <jamrial> the only version i recall miscompiled ffmpeg in a very obvious way was 4.9.0, which broke the flac decoder
[15:29:50 CET] <jamrial> keeping tree vectorization disabled has kept us mostly safe from misoptimizations
[15:30:28 CET] <nevcairiel> that option still causes a wide range of issues though
[17:41:13 CET] <jkqxz> <https://0x0.st/smLG.patch> as a more general way to do <http://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226129.html>, and without weird muxer-specific options?
[17:41:51 CET] <nevcairiel> yeah definitely dont want such logic in a muxer
[17:51:13 CET] <JEEB> is that the movenc thing?
[17:51:15 CET] <JEEB> yea
[17:51:45 CET] <JEEB> i love it how everyone wants to hack their stuff there because it seems simplest :D
[17:57:11 CET] <jkqxz> Does that filter have much other use?  I guess it could strip SEI as well, to break your libx264 files...
[17:57:52 CET] <nevcairiel> who knows
[17:58:21 CET] <nevcairiel> remvoing AUD and in-band SPS/PPS is probably the most obvious
[17:58:58 CET] <nevcairiel> but if your packaging is so dumb that it doesnt understand anything but plain slice nals
[17:59:41 CET] <jkqxz> Those two are already done by h264_metadata and extract_extradata respectively.
[18:02:13 CET] <nevcairiel> could theoretically strip MVC data out of a combined stream
[18:02:15 CET] <nevcairiel> or something like that
[18:02:56 CET] <nevcairiel> although a blacklist might be easier to handle in such cases then a whitelist
[18:04:56 CET] <nevcairiel> or remove Dolby Vision data
[18:05:00 CET] <nevcairiel> all sorts of random usecases!
[18:05:20 CET] <nevcairiel> (but also again, blacklist would be neater)
[18:06:53 CET] <jkqxz> That would be easy to change.
[18:06:53 CET] <JEEB> ye
[18:07:01 CET] <jkqxz> Or have both.
[18:07:12 CET] <nevcairiel> both might be nice depending on use-case, not sure how crazy that is
[18:21:46 CET] <jkqxz> Sounds like it's nonuseless, then.  I'll clean that up later and send it.
[18:33:22 CET] <jamrial> extract_extratada, remove_extradata and dump_extradata should ideally be combined, for that matter
[18:34:16 CET] <jamrial> the first one even does the same thing as second if you set the remove option
[18:35:56 CET] <nevcairiel> what does dump even do
[18:36:04 CET] <nevcairiel> write it to stderr?
[18:36:05 CET] <nevcairiel> :D
[18:41:37 CET] <jkqxz> What should be used as the separator for ranges?  Like "1,4-7,12", except commas are already special.
[18:42:00 CET] <nevcairiel> semicolon?
[18:43:34 CET] <jamrial> nevcairiel: inserts the extradata at the start of either keyframes, or all frames
[18:44:01 CET] <nevcairiel> dump seems like an odd name for that
[18:45:19 CET] <jkqxz> "1;4-7;12"?  Maybe.
[18:45:44 CET] <jkqxz> I had '|' initially, but that looks pretty horrible.
[18:46:08 CET] <jamrial> how is it done with filters? avfilter stuff, i mean
[18:48:59 CET] <nevcairiel> colong seperates arguments, comma separates filters, semicolon entire filter chains
[18:49:02 CET] <nevcairiel> colon*
[18:50:20 CET] <jamrial> also | to separate "item lists"
[18:50:36 CET] <jamrial> so even if ugly, there is some precedent for it
[18:52:21 CET] <jkqxz> It can probably be argued to be an item list.
[18:53:02 CET] <nevcairiel> dont have to necessarily take the avfilter syntax, avilfter has so many separators that it just ran out at some point
[18:53:50 CET] <jamrial> basically "filter_name=item_cnt|1st_item=value|2nd_iten=value"
[18:54:54 CET] <jkqxz> -bsf:v 'filter_unit_types=remove_types=1|4-7|12' doesn't look too bad.
[18:55:12 CET] <jkqxz> Both ';' and '|' are shell-active, so need to be escaped there already.
[18:58:29 CET] <jamrial> maybe call the bsf simply "filter_units"? right now we want to filter by type, but in the future we could expand it to some other criteria
[19:04:50 CET] <jkqxz> That would make sense.
[19:12:25 CET] <jkqxz> Should it do anything about empty packets on output?
[19:13:47 CET] <jamrial> maybe return EAGAIN?
[19:15:06 CET] <jkqxz> Currently I just hand the zero-sized packet to the output (and it has the right timestamps and whatnot).
[19:15:16 CET] <jamrial> basically, request more data until it can actually output something
[19:15:50 CET] <jkqxz> mp4 and mkv muxers are ok with that, but mpegts doesn't like it very much.
[19:15:56 CET] <jamrial> like the vp9_superframe bsf, which consumes packets until it can output a complete superframe
[19:16:44 CET] <wm4> zero-sized packets are icky
[19:16:59 CET] <wm4> they're randomly interpreted as invalid or EOF
[19:27:04 CET] <jkqxz> That's a good reason.  I'll make it keep asking for more input packets until it can make a nonempty output packet.
[19:28:59 CET] <JEEB> yea since we now have decoding and encoding APIs that do the same thing too
[19:29:12 CET] <wm4> the old APIs did that too
[19:29:34 CET] <wm4> we would have had the chance to change this, but apparently it was decided not to make 0 sized packets proper packets
[20:07:49 CET] <jamrial> jkqxz: the patch you sent doesn't seem to request for more input?
[20:25:41 CET] <gagandeep> kierank: for the bug6675, where the last 8 pixels distort, have you been able to run the attatchments for that bug in windows media player with the cineform decoder?
[20:25:57 CET] <kierank> no but i've seen someone do it
[20:26:00 CET] <kierank> and it looked correct
[20:26:14 CET] <JEEB> I would recommend building the decoder sample app and see the decoded YCbCr?
[20:27:08 CET] <kierank> yes that too
[20:27:39 CET] <gagandeep> how would i do that?
[20:27:48 CET] <JEEB> see cineform's code repo
[20:28:52 CET] <gagandeep> there is a sampledecoder.cpp
[20:29:00 CET] <gagandeep> in decoder sdk
[20:29:20 CET] <JEEB> read their documentation and get-to-hackan
[20:29:25 CET] <JEEB> and thus you get a reference decode :P
[20:29:35 CET] <gagandeep> a'right thanks
[20:31:29 CET] <jkqxz> jamrial:  Yes it does?  The while loop in filter_units_filter().
[20:34:13 CET] <jamrial> ah, ff_bsf_get_packet() is what returns EAGAIN
[20:34:19 CET] <jamrial> nevermind
[20:34:35 CET] <JEEB> :)
[20:38:51 CET] <gagandeep> kierank: what is plane[i].idwt_buf and idwt_temp you used in cfhd.c, i am looking at the document but i cant understand
[20:39:18 CET] <gagandeep> they are short pointers but for what?
[20:40:19 CET] <kierank> it's the big buffer for all the subbands
[20:41:42 CET] <gagandeep> ok, so hear this, in bug6675, 1088 height did not produce errors, but in alloc buffers for 1080, h8, h4, h2 are wrong, so do you think this would help
[20:42:27 CET] <gagandeep> alloc_buffers would get h8, h4, h2 right with heights divisible by 16, was that intentional
[20:44:23 CET] <kierank> possibly
[20:44:29 CET] <kierank> i have not looked into detail at this bug
[20:44:39 CET] <kierank> but you are definitely looking in the right place i think
[20:45:06 CET] <kierank> you need to look at the official decoder to see how to do it i guess
[20:45:27 CET] <gagandeep> because FFALIGN macro is causing 1080 to jump to 1088, and yeah i will need to look at official decoder for this
[21:15:41 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/pull/280 wtf
[21:15:49 CET] <BtbN> most of those changes make no sense
[21:18:23 CET] <JEEB> so they have a static analyzer + some sort of automated thing?
[21:18:31 CET] <JEEB> which tries to generate fixes
[21:18:32 CET] <JEEB> :D
[21:18:33 CET] <kierank> "AI"
[21:18:40 CET] <JEEB> """AI"""
[21:20:25 CET] <BtbN> Their "Dead Code" checks are stupid. If that's dead code, the lines before are as well, and those are kept?
[21:25:22 CET] <nevcairiel> it probably just mislabels that and means write-only assignment
[21:30:10 CET] <TD-Linux> that bot performed better on a couple other projects I've seen it hit
[21:31:09 CET] <BtbN> probably because ffmpeg used to have a static analyzer already, and the simple stuff always got fixed
[22:11:36 CET] <gagandeep> kierank: i am very new to building apps in c and c++ using cmake which cineform sdk uses
[22:12:00 CET] <gagandeep> kierank: i installed cineform-sdk to build TestCFHD using cmake
[22:13:16 CET] <gagandeep> but does it also install some libraries along with it
[22:16:14 CET] <kierank> I think you can decode with the test application
[22:19:31 CET] <gagandeep> that TestCFHD is decoding but i need output in YCrCb 
[22:19:45 CET] <gagandeep> like you guys were saying earlier
[22:20:08 CET] <kierank> what output does it give
[22:22:28 CET] <gagandeep> in terminal output is ; found n frames in file
[22:22:53 CET] <gagandeep> after that Decode Res.: <resolution>
[22:23:31 CET] <kierank> should be possible to decode with the test
[22:23:47 CET] <gagandeep> then avg decode times for different pixel format
[22:24:25 CET] <gagandeep> so i should go in the test file and write a function to output to a file
[22:48:39 CET] <gagandeep> kierank: in test file EXPORT_DECODES_PPM macro was off so it was not outputing any file
[22:55:43 CET] <cone-854> ffmpeg 03Stefan _ 07master:313b6057fbf1: avcodec/mediacodec_wrapper: blacklist more software decoders
[22:55:44 CET] <cone-854> ffmpeg 03Aman Gupta 07master:c22e7b00e4b9: avcodec/mediacodec: reduce loglevel for per-frame logging
[22:55:45 CET] <cone-854> ffmpeg 03Aman Gupta 07master:b19e11a4dc83: MAINTAINERS: add myself to mediacodec
[22:57:32 CET] <wbs> tmm1: ^ about that blacklist; OMX.SEC.* is also the proper name for actual hardware decoders on many exynos SoCs
[22:58:39 CET] <JEEB> \o/
[22:58:48 CET] <mateo`> wbs: oh crap
[23:00:01 CET] <sfan5> wbs: it's OMX.Exynos.* on my devices, besides Google Chrome does this too
[23:00:30 CET] <wbs> sfan5: on galaxy s3 they were named e.g. OMX.SEC.avc.dec
[23:00:56 CET] <mateo`> regarding the behaviour change tmm1 proposed on the ml for the mediacodec decoders, it feels like it requires a major bump ?
[23:02:17 CET] <sfan5> wbs: well then Google must have a reason for doing it incorrectly
[23:03:00 CET] <wbs> sfan5: I guess they might be more or less quirky if you're chrome and facing the whole internet, at least
[23:03:21 CET] <sfan5> the condition could be changed to (strstr(name, "OMX.SEC") && strstr(name, ".sw."))
[23:03:54 CET] <wbs> that's probably safer - did you ever see a sample of an actual name of one of those that is claimed to be sw?
[23:04:22 CET] <sfan5> 03-06 18:17:44.145 13332 13434 V mpv     : [ffmpeg/video:warn] hevc_mediacodec: Found decoder OMX.SEC.hevc.sw.dec
[23:04:59 CET] <wbs> I guess it depends on if you want to know "is this codec for sure a sw codec", or "will this codec behave completely correctly in every single weird case we can throw at it"
[23:05:00 CET] <sfan5> my device only has OMX.SEC.*.sw.*, the real ones are OMX.Exynos.* as I've said
[23:05:16 CET] <wbs> yeah, the naming usually changes with soc generation
[23:06:15 CET] <sfan5> adding a check for ".sw." works for me" so I don't mind either way
[23:06:15 CET] <gagandeep> JEEB: i had to enable some macros in testCfhd file given in documentation to get the outputs
[23:06:21 CET] <sfan5> mateo`: would you like a patch to fix this?
[23:07:45 CET] <mateo`> sfan5: yes please
[23:09:58 CET] <mateo`> would it make sense to add an option to the decoder to allow software decoders to be used ? when ffmpeg cannot be bundled with its own native sw decoders for "legal" reasons
[23:10:26 CET] <sfan5> sounds useful to me
[23:10:48 CET] <tmm1> videotoolbox has an 'allow_sw' option, could reuse that here too
[23:14:37 CET] <mateo`> ok, i'll reuse the same name
[23:15:29 CET] <cone-854> ffmpeg 03James Almer 07master:0ca33b1d4eb2: avformat/utils: free existing extradata before trying to allocate a new one
[23:15:30 CET] <cone-854> ffmpeg 03James Almer 07master:2aa42fac77ac: avformat/utils: simplify ff_alloc_extradata()
[23:16:21 CET] Action: mateo` afk
[23:23:21 CET] <gagandeep_> kierank: the files attatched in bug 6675 are not getting decoded by test file even thought it has decoded the other files and outputed the ppm files for frames, i believe that the attatchment in bug6675 are corrupted 
[23:23:44 CET] <kierank> ok
[23:24:40 CET] <gagandeep_> i am also not getting any output in console so it means that the buffer is not flushed on console, ie must be a crash
[23:24:54 CET] <kierank> ok
[23:25:03 CET] <kierank> does ffmpeg not play the file in 6675
[23:25:15 CET] <gagandeep_> ffmpeg is playing them
[23:25:28 CET] <kierank> i think this is just a container problem
[23:25:41 CET] <gagandeep_> but they were not getting decoded in windows media player and now also in test file
[23:25:51 CET] <gagandeep_> you must be right about that as well
[23:26:21 CET] <gagandeep_> now atleast i don't have to log in windows to decode the files of cfhd :P
[00:00:00 CET] --- Wed Mar  7 2018