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

Tue Oct 1 03:05:06 EEST 2019

[00:00:41 CEST] <Lynne> why would you want assembly for something that's potentially subjective or incorrect at some point?
[00:01:21 CEST] <rcombs> is objectivity related to desired performance?
[00:02:11 CEST] <Lynne> you'll spend a lot of work on something that you might need to potentially rewrite completely
[00:02:39 CEST] <rcombs> ¯\_(Ä)_/¯ in N years we'll all be on ARM anyway
[00:03:29 CEST] <rcombs> and the actual tone-mapping function (which is generally the bit people quibble about) is quite a small part of the overall filter
[00:03:34 CEST] <Lynne> with intrinsics, because the ARM ISA is a deliberately designed trash heap
[00:04:00 CEST] <rcombs> eh I've written a fair bit of aarch64 and found it pretty pleasant tbh
[00:04:13 CEST] <rcombs> documentation complaints aside
[00:04:33 CEST] <rcombs> ("zip" and "unzip" docs can get fucked)
[00:04:57 CEST] <Lynne> were you paid for it? I forced myself to do it for free and never want to look at it again
[00:05:13 CEST] <rcombs> I was
[00:05:55 CEST] <rcombs> (though I've also done some ARM reverse-engineering and binary patching for video game fan TL stuff, and that wasn't bad either)
[00:06:15 CEST] <rcombs> I find NEON easier to work with than SSE2 tbh
[00:06:54 CEST] <rcombs> they use 3-operand instructions for a lot of stuff where intel used 2, and the result is operations that are a lot easier to wrap your head around
[00:08:44 CEST] <Lynne> but its so so soooo slow
[00:09:02 CEST] <rcombs> see eg pmaddwd vs smlal
[00:09:27 CEST] <Lynne> that's what destroyed me, the deemphasis opus function has an 8.2x speedup with avx and I barely managed to get 2.26x or so
[00:09:45 CEST] <Lynne> different reg sizes, but that was for both opus functions
[00:09:53 CEST] <Lynne> and the 15 point fft was slower than C
[00:10:26 CEST] <rcombs> might help that my target was Hurricane and not, like, A53 or w/e
[00:14:28 CEST] <rcombs> I got around 4.7x on what I was working on
[00:15:05 CEST] <Lynne> oh yeah and lack of instructions like mults that accept memory as input, lack of shufps, different xor name making you nih xor because no docs, store and load register incrementors being useless
[00:16:18 CEST] <rcombs> yeah the lack of good addressing modes is pretty obnoxious
[00:16:51 CEST] <Lynne> small things, but 23 or so full registers go out quicker and because renaming isn't a thing you can't reuse temporary registers immediately
[00:17:44 CEST] <rcombs> I mean, maybe it's not a thing on _your_ target
[04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:79597639cb0a: lavf/utils: change the log level to warning if can't get duration
[04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:12e6057fb005: lavf/nutdec: add logging context to log
[04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:541c6356289f: lavf/utils: correct the duration estimation method for nut demuxer
[04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:f5e867570ef4: lavf/utils: Cosmetics: fix indentation for estimate_timings
[04:10:36 CEST] <cone-536> ffmpeg 03Jun Zhao 07master:6ca3d34ff849: lavf/utils: support duration estimate method dump
[06:06:31 CEST] <philipl> jkqxz: https://github.com/philipl/FFmpeg/pull/1
[06:06:41 CEST] <philipl> Lynne: updated with what could be final approach to hw -> hw transfers
[10:23:46 CEST] <jkqxz> philipl:  Can you explain how your new valid_hw_transfer_src_formats field differs from what is returned by av_hwframe_transfer_get_formats()?
[10:25:30 CEST] <jkqxz> It's also unclear to me why the transfer_data_(to|from)_hw are added.
[10:27:07 CEST] <jkqxz> The if hw-hw condition inside av_hwframe_transfer_data() isn't right - a mapped frame has an attached hw_frames_ctx to support unmapping.
[10:27:34 CEST] <jkqxz> (Given two devices, you can hwmap a frame from one and hwupload it to the other.)
[10:31:27 CEST] <jkqxz> In hwupload I don't think you want to create a new device out of nowhere, that's not really something that should happen inside a filter.
[10:32:03 CEST] <jkqxz> Add a derviation path like hwmap has?  (Just for the device, not doing anything with the frames.)
[12:16:14 CEST] <a1rwulf> hey
[12:16:31 CEST] <a1rwulf> i have some trouble to understand the rtsp code. anyone that can help me with it?
[12:18:00 CEST] <BtbN> jkqxz, the thing with CUDA<->Vulkan is, that you can't truly map. It's effectively a copy.
[12:25:49 CEST] <cone-125> ffmpeg 03Paul B Mahol 07master:9c9d5bf257df: avfilter/f_metadata: add ends_with() function for comparing ends of strings
[12:25:50 CEST] <cone-125> ffmpeg 03Paul B Mahol 07master:a6e2cf5eb044: avfilter/f_metadata: do not memleak expr
[12:58:38 CEST] <cone-125> ffmpeg 03Paul B Mahol 07master:8b36968ef465: avfilter/trim: drop all audio frames instead of asserting
[15:19:07 CEST] <BtbN> I still do not understand what that dude actually wants.
[15:23:34 CEST] <thardin> sounds like they want a preset for this
[15:24:17 CEST] <BtbN> But what _is_ "this"? Do they just mean mpeg-2 with 720p content?
[15:25:35 CEST] <thardin> "As i said in precedent explaination attempt, that is to avoid to have to set the bufsize, maxrate and others video settings.
[15:25:38 CEST] <thardin> Like FFmpeg already do for other formats as DVDs for exemple."
[15:25:51 CEST] <J_Darnley> So he wants a new -target option?
[15:26:05 CEST] <thardin> they could just document this on a wiki somewhere
[15:26:21 CEST] <thardin> surely there's a ps3dev wiki or so
[15:26:44 CEST] <J_Darnley> That's the one with preset limits and whatnot in ffmpeg's world.
[15:27:10 CEST] <J_Darnley> *pre-set
[15:28:57 CEST] <J_Darnley> Does he post a document listing the exact settings he wants to use?
[15:29:12 CEST] <J_Darnley> I'll translate them into a target option.
[15:53:53 CEST] <cehoyos> J_Darnley: If you know how to do this for HD-DVD (and possibly test it), this is certainly welcome but this should really not be triggered by Sami32: I doubt that he has access to a HD-DVD player.
[15:55:36 CEST] <J_Darnley> No, I don't.  If he provides a command line for the settings, I will translate that into a -target option.  Otherwise he is SOL to get me to do anything.
[15:57:47 CEST] <BtbN> I don't think he means HD-DVD. Cause PS3 uses Blurays.
[15:57:57 CEST] <BtbN> And I also have doubts about PS3 not supporting h264
[15:58:14 CEST] <J_Darnley> Wasn't it xbox360 that had hddvd?
[15:58:56 CEST] <BtbN> https://manuals.playstation.net/document/en/ps3/current/video/filetypes.html "MP4 file format: H.264/MPEG-4 AVC High Profile (AAC LC)"
[15:59:44 CEST] <BtbN> looks all very standard to me
[16:00:10 CEST] <BtbN> It does list "AVCHD (.m2ts / .mts)" though, which I guess is what he means?
[16:00:50 CEST] <nevcairiel> there is no telling what he means, since he is still mixing random technical terms with no knowledge of their meaning
[16:01:17 CEST] <nevcairiel> and AVCHD is an off-shoot of Blu-ray 
[16:01:37 CEST] <BtbN> And on top of that, should already be supported by ffmpeg just fine?
[16:02:17 CEST] <nevcairiel> he does mostly mention HDV, which is the predecessor to AVCHD
[16:02:49 CEST] <BtbN> It does not even list that as supported format for the PS3
[16:03:12 CEST] <nevcairiel> (both bein camcorder recording formats, primarily, both based on mpeg-ts, HDV  primarily around mpeg2, AVCHD on H264)
[16:34:25 CEST] <philipl> jkqxz: I admit the hw_formats stuff ended up not making a practical difference, but I was motivated by wanting to communicate the distinction between supported hw formats and sw formats, and in theory a context might support a different set of sw formats for a given hw format. None of that actually applies in the cuda/vulkan situation, and we don't really use the input formats list in any way except 
[16:34:31 CEST] <philipl> in how the upload and download filters use them so I can certainly buy that it's not worth making the distinction at the moment.
[16:35:12 CEST] <philipl> The seprate to/from hw function initially stemmed from their presence being part of the transfer mode detection logic, which I scraped, and then I left them in for code clarity. I can roll them back into the regular transfer functions.
[16:36:20 CEST] <philipl> With respect to detecting the transfer mode, why would it go wrong? Because a derived hwframes doesn't have a real context's ability to do transfers?
[16:38:21 CEST] <philipl> and then with respect to device derivation, I agree that today there is a strong relationship between the cuda and vulkan devices, but you can imagine future scenarios where it might be possible to do transfers between unrelated devices; the other data point here is that hwupload_cuda creates a device out of thin air so if we want to replace it with regular hwupload without loss of functionality, 
[16:38:27 CEST] <philipl> you need to be able to do that.
[16:38:28 CEST] <philipl> but I can change it if you prefer.
[16:51:52 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:6e9e14e62e99: avfilter/split: use av_asprintf()
[16:51:52 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:7851e2f368d8: avfilter/af_join: use av_asprintf()
[16:54:09 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:5161b279d611: avfilter/af_join: cosmetics
[17:29:49 CEST] <BradleyS> i'm not in the loop on the ps3 discussion beyond irc, but i can say handbrake has a 1080p30 preset targeting ps3/ps4 that's pretty standard
[17:30:13 CEST] <BradleyS> x264 medium, high profile level 4.0, no tune, crf 22
[17:30:23 CEST] <BradleyS> aac + ac3 audio
[17:30:42 CEST] <BradleyS> mp4 container
[17:31:38 CEST] <BradleyS> if the op seems to need to set vbv parameters, perhaps they've failed to set the encoder level which would handle that
[17:32:53 CEST] <BradleyS> most older devices such as ps3 require level 4.0 or 4.1, we use 4.0 for all 1080p for compatibility and portability
[17:33:31 CEST] <kierank> does x264 set vbv by default for level now?
[17:33:41 CEST] <kierank> in the past you had to force it
[17:33:49 CEST] <BradleyS> i believe so
[17:34:38 CEST] <BradleyS> we don't set it manually, x264 reports it being set and adjusts based on the level chosen, so it would seem so
[17:35:28 CEST] <BradleyS> i'm guessing the op set nothing which probably means auto, so he's getting a higher level and bit rate spikes the ps3 would not support
[17:40:15 CEST] <JEEB> I don't think it still does VBV by default
[17:40:21 CEST] <JEEB> unless something changed
[17:43:02 CEST] <j45> BradleyS: handbrake sets vbv based on provided profile and level for x264.  something rodeo did for us ages ago
[17:43:36 CEST] <BradleyS> i stand corrected, then the op should set vbv to enforce the bit rate maximums for the required level
[17:47:48 CEST] <BradleyS> i'm not sure a ps3 target is warranted as he's just targeting high profile level 4.0 with vbv-bufsize=31250 vbv-maxrate=25000
[17:48:10 CEST] <BradleyS> which is essentially what we use for all 1080p30 h.264
[17:49:17 CEST] <BradleyS> unless you want to get into targets for all common devices like we do with the preset system for handbrake ;)
[18:58:46 CEST] <durandal_1707> i gonna apply scroll vf, anybody against?
[19:38:57 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:a746359ede6c: avfilter: add scroll video filter
[20:16:10 CEST] <Lynne> https://www.lineageos.org/engineering/Bluetooth-SBC-XQ/
[20:16:23 CEST] <Lynne> that was a nice writeup on sbc, didn't expect anything technical
[20:41:25 CEST] <cone-670> ffmpeg 03Vladimir Panteleev 07master:c888adf590ee: libavfilter: add photosensitivity filter
[20:41:26 CEST] <cone-670> ffmpeg 03Paul B Mahol 07master:056bc9393ea7: avfilter/vf_photosensitivity: fix memleak
[21:02:17 CEST] <durandal_1707> Lynne: are you still working on vulkan?
[21:26:44 CEST] <durandal_1707> how to name filter which would mix one short audio with another longer audio at random(user picked) position?
[21:46:24 CEST] <Lynne> durandal_1707: av_useaudacity
[21:46:29 CEST] <Lynne> *af_
[21:46:41 CEST] <durandal_1707> haha
[21:50:41 CEST] <durandal_1707> Lynne: its doable, no need for GUI to add commercial breaks to your favorite shows!
[21:55:25 CEST] <Chagall> I have an AV1 in MP4 file with timebase of 15360, and remuxing it to IVF sets frame rate to 1 and time scale to 15360, which is not correct (it should be 512 framerate for 15360 timescale, or 30fps). any idea what's going on? the fps is detected correctly from ffmpeg/ffprobe's side but based on the IVF header format described at https://wiki.multimedia.cx/index.php/IVF the header-provided fps is definitely wrong
[21:56:09 CEST] <Chagall> eh, I guess that's more for the user channel, mb
[22:45:59 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:675f62a202be: avcodec/aptx: Fix multiple shift anomalies
[22:46:00 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:75fefb1fb7ac: avcodec/utils: Check sample_rate before opening the decoder
[22:46:01 CEST] <cone-670> ffmpeg 03Michael Niedermayer 07master:97450d2b6a08: avcodec/dxv: Check op_offset in dxv_decompress_yo()
[23:24:57 CEST] <J_Darnley> Oh my god.  I found it again.
[23:24:59 CEST] <J_Darnley> http://rinkworks.com/stupid/
[23:43:03 CEST] <beastd> J_Darnley: OMG! That website just kills time instantly. It's entertaining, but I should really stop reading now...
[23:44:04 CEST] <cehoyos> +1
[23:49:59 CEST] <Illya> tmm1: I'm not sure anyone is using the EIT title field, none of those samples use it, some more samples I found didn't have it set but set the short event descriptor instead
[23:50:34 CEST] <Illya> probably better just to leave it out I think
[00:00:00 CEST] --- Tue Oct  1 2019