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

[burek]

[10:13:26 CEST] <JEEB> 33
[10:21:16 CEST] <kierank> durandal_1707: I don't understand what that telecine guy trying to do
[10:21:40 CEST] <durandal_1707> me too
[10:22:03 CEST] <kierank> he is trying to do some spatial telecine
[10:22:09 CEST] <kierank> I don't see how that can ever look good
[10:23:12 CEST] <JEEB> he has been going around the mpv channel and the ffmpeg users' channel
[10:23:24 CEST] <kierank> he was angry nobody responded
[10:23:30 CEST] <JEEB> apparently some sort of hardware person who might have misconceptions about things
[10:23:30 CEST] <kierank> and then was using some custom notation
[10:23:31 CEST] <kierank> (wtf)
[10:23:57 CEST] <JEEB> he first came asking if players did telecine when they were showing 24p on a 60Hz screen
[10:24:03 CEST] <JEEB> then he asked how to do telecine
[10:24:04 CEST] <JEEB> etc
[10:24:10 CEST] <JEEB> rather confuzzled he seemed
[10:25:12 CEST] <JEEB> (although I'm exactly as confuzzled regarding what he actually wants to achieve)
[10:52:09 CEST] <nevcairiel> mc
[10:52:13 CEST] <nevcairiel> woops
[11:43:22 CEST] <cone-795> ffmpeg 03Paul B Mahol 07master:a2dbd857333b: doc/filters: fix alphabetic order of some video filters
[12:57:28 CEST] <cone-795> ffmpeg 03Jun Zhao 07master:da6e56991662: configure: fix --disable-alsa can't work
[12:57:29 CEST] <cone-795> ffmpeg 03Jun Zhao 07master:43b341263189: configure: fix --disable-v4l2-m2m can't work
[15:39:54 CEST] <soub> Hi, I solved one minor bug #8111. I run a command git commit then git format-patch what I do next to send it to mailing list. Pls help I am doing first time. 
[15:40:05 CEST] <BtbN> send-email
[15:41:13 CEST] <soub> BtbN: where I can find content to send,  git format-patch nothing gives me output 
[15:41:28 CEST] <BtbN> format-patch outputs a patch
[15:41:34 CEST] <BtbN> send-email takes that file
[15:41:43 CEST] <BtbN> well, it outputs one patch per commit
[15:42:57 CEST] <soub> Okay thank you BtbN 
[15:59:19 CEST] <jamrial> durandal_1707: do you have a sample to test the 360 stuff?
[15:59:24 CEST] <jamrial> also, example command lines
[16:12:00 CEST] <durandal_1707> jamrial: fetch vimeo or facebook or youtube 360 video
[16:12:16 CEST] <BtbN> "People are ignoring my ticket, better set it to Important!"
[16:12:24 CEST] <durandal_1707> what you trying to do?
[16:13:35 CEST] <jamrial> test the asm you wrote
[16:17:59 CEST] <durandal_1707> jamrial: do you know how to fetch video?
[16:19:07 CEST] <jamrial> found a cube 3x2 one and an equirect one i had around
[16:19:35 CEST] <jamrial> no idea what to pass to in_forder or out_forder, though
[16:20:05 CEST] <durandal_1707> youtube 3x2 is eac
[16:20:41 CEST] <durandal_1707> facebook 3x2 cube is v360 simple c3x2
[16:21:11 CEST] <durandal_1707> vimeo is always equirectangular
[16:21:18 CEST] <JEEB> I was kind of saddnened that vimeo's 360 video has no metadata :P
[16:21:29 CEST] <JEEB> so when I was looking into handling it, noope
[16:21:43 CEST] <JEEB> yea, it generally seems to be equirectangular
[16:37:43 CEST] <durandal_1707> jamrial: you use only first three options, others are for more advanced stuff
[16:37:54 CEST] <jamrial> alright
[18:30:53 CEST] <durandal_1707> jamrial: second pmulld is needed
[18:49:18 CEST] <durandal_1707> also i cant get pmaddwd to work
[18:55:34 CEST] <durandal_1707> because linesize is int
[19:12:55 CEST] <dloman91> hello, I am trying to encode unregistered SEI data on every frame and it appears that in h264_metadata_bsf.c the bsf is checking for sps and only adding the data to I frames. I am wrong in thinking that the standard says I can write SEI data to any frame instead of just to the GOP? Is there a specific reason SPS is checked or is this a bug?
[19:15:06 CEST] <jamrial> durandal_1707: i got it working. i just replaced pmulld with pmaddwd. no need to remove the pmovsxwd lines, or change how to broadcast it in m0
[19:15:18 CEST] <jamrial> as long as linesize values fit in a signed word, it works
[19:17:35 CEST] <jkqxz> dloman:  You can put SEI NAL units in any access unit you like.  The functionality in h264_metadata is intended for adding a single stream-level tag, so it deliberately only adds it to frames which already contain an SPS.
[19:18:49 CEST] <durandal_1707> jameial: i get with that invalid output
[19:20:42 CEST] <dloman91> i see @jkqxz is there a specific way one is supposed to add SEI to access units such as the h264_metadata_bsf? or should i just write my own with code similar to what is done in the h264_metadata_bsf
[19:21:11 CEST] <jamrial> i get the same checksums
[19:22:03 CEST] <jkqxz> dloman91:  Your own code like it.
[19:24:03 CEST] <durandal_1707> jamrial: any speedup noticeable from it?
[19:24:10 CEST] <durandal_1707> snd show it
[19:24:38 CEST] <jamrial> i don't even notice a speedup with the function compared to c. the filter is pretty slow
[19:24:51 CEST] <dloman91> sounds good. If i made a merge request which added a field to the h264_metadata_bsf to toggle between every frame and sps would that be acceptable or should something like that be in its own seperate bsf?
[19:25:20 CEST] <jkqxz> What would be the use-case be for adding the same thing to every access unit?
[19:25:33 CEST] <dloman91> MISB 604.6
[19:25:53 CEST] <dloman91> it adds precision timestamps to every AU
[19:26:37 CEST] <dloman91> frame i am not 100% certain on the difference between frame and AU (i am very new to this)
[19:27:22 CEST] <jkqxz> That doesn't sound like you want the same data in every access unit.
[19:27:30 CEST] <dloman91> correct
[19:27:40 CEST] <dloman91> i am modifiying the filter every frame
[19:28:37 CEST] <jkqxz> So the sei_user_data option isn't what you want at all.
[19:28:57 CEST] <dloman91> why do you say that?
[19:29:28 CEST] <jkqxz> Because it's a single string provided as an option.
[19:30:13 CEST] <dloman91> A Precision Time Stamp Identifier, equal to the ASCII string MISPmicrosectime,shall be inserted into the H.264/AVC compressed user_data_unregistered SEImessage field uuid_iso_iec_11578, so that it relates to a specific Motion Imageryframe.
[19:30:25 CEST] <dloman91> thats from MISB604.6 spec
[19:30:45 CEST] <dloman91> A one-byte Time Status followed by an 11-byte Modified Precision Time Stamp shallbe inserted into the H.264/AVC compressed user_data_unregistered SEI messagefield user_data_payload_byte, so that it relates to a specific Motion Imagery frame.
[19:31:16 CEST] <dloman91> its a magic string then a status then a uint64_t with some 0xff every 3 bytes
[19:32:31 CEST] <jkqxz> Where are you going to get the timestamp from?  If it's present in side-data then adding a new pass/insert/remove/extract-type option to H.264 metadata sounds plausible.
[19:32:48 CEST] <dloman91> in my case hardware
[19:35:15 CEST] <dloman91> every frame before i av_bsf_send_packet i set the sei_user_data opt on the bitstreamFilterContext to the updated value
[19:37:44 CEST] <jkqxz> While that probably works, it's definitely doing naughty things with the API.
[19:40:47 CEST] <jkqxz> I'm not familiar with this standard or who uses it, but it does look vaguely sensible.  A new option to use it seems fair.
[19:40:57 CEST] <dloman91> haha. yes i figured. but you only yolo once also i had not clue how to do it correctly
[19:41:03 CEST] <dloman91> its very common in drones
[19:41:46 CEST] <jkqxz> (Including start code emulation bytes in H.264 is a bit of a joke, though I guess it's inherited from the MPEG-2 code.)
[19:42:13 CEST] <dloman91> start code emulation?
[19:42:46 CEST] <dloman91> is that the 0xffs inside of the time data?
[19:43:15 CEST] <jkqxz> Yeah.  H.264 already deals with that, so adding them in the data is redundant.
[19:43:24 CEST] <dloman91> ahh
[19:44:45 CEST] <dloman91> would love to learn the correct way to do this. How would you implement this without abusing the API?
[19:47:21 CEST] <jkqxz> Make a new side-data type containing your special timestamps, and attach them to each frame before you send it to the BSF.  Add an option to h264_metadata to indicate that it should make the SEI out of your timestamps (like the display orientation stuff).
[19:47:39 CEST] <cone-327> ffmpeg 03Michael Niedermayer 07master:9d3ddef519e8: avcodec/apedec: Fix 32bit int overflow in do_apply_filter()
[19:47:39 CEST] <cone-327> ffmpeg 03Michael Niedermayer 07master:8a1a9588fb44: avcodec/vqavideo: Limit resolution
[19:47:39 CEST] <cone-327> ffmpeg 03Michael Niedermayer 07master:dfa5d1a3667f: avcodec/iff: Check for overlap in cmap_read_palette()
[19:47:41 CEST] <jkqxz> Or maybe existing frame metadata is good enough without adding a new side-data type?  Not sure on that one.
[19:48:15 CEST] <jkqxz> PTS is a timestamp value.  If your timebase is microseconds then you've already got the right thing there.
[19:48:37 CEST] <dloman91> but the PTS is relative to start of the video no?
[19:48:51 CEST] <dloman91> this is supposed to be since unix epoch
[19:49:18 CEST] <jkqxz> There is no requirement that PTS starts at any particular value.
[19:50:02 CEST] <dloman91> interesting. I didnt know that
[19:51:55 CEST] <Lynne> there isn't, but don't expect containers to handle non-zero start PTS properly
[19:52:09 CEST] <dloman91> the frame metadata stuff. is that in the h264_metadata bsf or is that somewhere else?
[19:53:16 CEST] <JEEB> Lynne: movenc f.ex. does just fine :) its default mode is to shift stuff to start from zero, though. but if stop that it should take it just fine. (you can  test this with -itsoffset XXXX -copyts in ffmpeg.c)
[19:53:39 CEST] <jkqxz> See libavutil/frame.h.
[19:54:20 CEST] <Lynne> IIRC matroska really didn't like it (or maybe mpv didn't like it on playback)
[19:54:25 CEST] <JEEB> (you might or might not need to add the flag for discontinuities for fragmented mp4 though)
[19:54:42 CEST] <JEEB> (otherwise it will attempt to make the thing continuous and start the fragments at 0)
[19:54:46 CEST] <cone-327> ffmpeg 03Gyan Doshi 07master:fa697aa92f5d: ffmpeg: switch to avformat_seek_file for stream_loop
[19:54:47 CEST] <cone-327> ffmpeg 03Gyan Doshi 07master:2b66c757d6aa: fate: add test for stream_loop
[19:57:19 CEST] <dloman91> ahh so AVFrameSideData? I was looking at this last week :) ... I couldn't figure out how to use this and also if this data was encoded or if it was additional to the encoded stream 
[20:02:10 CEST] <durandal_1707> jamrial: what cpu do you have? and what resolution you test?
[20:03:20 CEST] <jamrial> durandal_1707: haswell, and tried a 3072x2048 cubemap video
[20:05:16 CEST] <durandal_1707> isnt haswell old cpu with worse performance then broadwell?
[20:05:49 CEST] <JEEB> it has AVX2
[20:05:52 CEST] <durandal_1707> i get nice speed boost here
[20:05:59 CEST] Action: JEEB still has 4790K
[20:06:03 CEST] <JEEB> which is a haswell refresh
[20:06:48 CEST] <jamrial> durandal_1707: gather is slow on haswell, so maybe that's why
[20:07:42 CEST] <durandal_1707> buy tiger lake
[20:11:11 CEST] <dloman91> trying to understand the flow here #1 add new AVFrameSideDataType #2 attached side data to frame w/ av_frame_new_side_data #3 somewhere inside of avcodec_send_frame & avcodec_receive_packet take AVFrameSideData turn it into a AVPacketSideData (but only 1 per Frame) #4 inside of h264_metadata bsf check if there is this special Side data and if so wr
[20:11:11 CEST] <dloman91> ite it to SEI unregistered data for that packet
[20:11:44 CEST] <tmm1> dloman91: there's a patchset on the list for h264 cbs which does similar logic for a53 side data
[20:11:49 CEST] <tmm1> you will probably find that useful
[20:12:35 CEST] <tmm1> jkqxz: whenever you get a chance, would appreciate a review of the v4l2 drm patchset on the list
[20:12:47 CEST] <dloman91> total n00b here, my apologies. where can i find said patchset?
[20:13:53 CEST] <dloman91> this https://patchwork.ffmpeg.org/patch/9076/ ?
[20:13:57 CEST] <Lynne> tmm1: lgtm for the --disable-v4l2-m2m configure patch, push it now, and push it to old releases where it applies cleanly
[20:15:35 CEST] <Lynne> does it also fix --disable-hwaccels?
[20:16:21 CEST] <tmm1> dloman91: https://patchwork.ffmpeg.org/patch/8161/ 
[20:16:29 CEST] <tmm1> that might not be the latest but it should give you an idea
[20:16:34 CEST] <tmm1> i need to revive that patchset
[20:16:52 CEST] <dloman91> awesome thanks
[21:08:20 CEST] <kierank> Is that really worth a CVE
[21:08:52 CEST] <jamrial> who knows
[21:19:46 CEST] <jamrial> it made it to a release, and it uses uninitialized memory. guess that's enough for a cve
[21:27:22 CEST] <BtbN> I guess some people get paid per CVE. So... everything is a CVE
[23:36:34 CEST] <rcombs> mmmmmm, looks like libcuda has some logs gated behind __RM_ENABLE_VERBOSE_OUTPUT=1
[23:38:40 CEST] <BtbN> Where did you find that? oO
[23:44:35 CEST] <rcombs> oh my, what might CUDA_MEMCHECK do
[23:45:18 CEST] <rcombs> BtbN: disassembly
[23:45:29 CEST] <rcombs> see also CUDA_MEMCHECK_RECORD_FORMAT_VERSION, CUDA_MEMCHECK_FLAG
[23:45:37 CEST] <rcombs> and CUDA_MEMCHECK_OUTPUT
[23:46:29 CEST] <rcombs> guess there's a "cuda-memcheck" tool available and these env vars are undocumented implementation details
[23:46:37 CEST] <nevcairiel> those things are possibly used by the cuda-memcheck tool, which is basically valgrind for cuda
[23:46:42 CEST] <nevcairiel> ^
[23:47:26 CEST] <rcombs> those ones are all read as strings; contrast with some other stuff in here that's either read as an unsigned int, or immediately checked only for null, and then first-byte-equals-'1'
[23:49:13 CEST] <rcombs> it's funny, they've got a whole routine for reading an env var and copying its value to a provided buf+length
[23:49:59 CEST] <rcombs> maybe they think that'll make it okay when they CALL SETENV FROM LIBRARY CODE HOLY FUCK
[23:50:23 CEST] <rcombs> ahahahaha they pthread_mutex_lock() around setenv()
[23:50:28 CEST] <rcombs> sure that'll make it all fine
[23:51:51 CEST] <rcombs> I'm gonna see what that logging var does later
[23:52:34 CEST] <rcombs> currently I'm trying to track down an issue where a GPU remains in the P0 power state (instead of dropping to P5 or P8) after I avcodec_open2() and then avcodec_close() an nvenc
[23:52:44 CEST] <rcombs> seems to be somewhat inconsistent
[23:53:33 CEST] <rcombs> nvidia-smi doesn't report the process as still using the GPU after the avcodec_close(), so I'd bet this is a driver bug, but if I can work around it that'll probably be quicker than getting them to fix it
[23:54:12 CEST] <BtbN> If you report that to the nvidia ffmpeg conacts via E-Mail they'll definitely be interested.
[23:57:46 CEST] <rcombs> which contacts?
[23:58:28 CEST] <rcombs> also amusingly the P-state seems to drop back to normal if I close() some leaked file descriptors& that are opened in cuInit(), which has no corresponding deinit function
[23:58:56 CEST] <rcombs> so for a while I just thought this was an unsolvable design flaw, but it turns out that it does _sometimes_ drop even with those fds still open
[23:59:15 CEST] <rcombs> and also the P-state doesn't go to P0 when they're first opened; only when the actual session is started later
[23:59:18 CEST] <BtbN> One would expect any such FDs to auto close on app exit
[00:00:00 CEST] --- Fri Sep  6 2019