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

[burek]

[00:01:11 CET] <atomnuker> tmm1: patch sent
[00:07:45 CET] <jamrial> atomnuker: he sent one himself 10 minutes ago :p
[00:42:02 CET] <atomnuker> welp, mine doesn't extend above 80 chars :)
[00:42:24 CET] <atomnuker> jkqxz: nice patches, except for the legacy drm mapping thing
[00:42:50 CET] <atomnuker> why do we need 200 lines to do something we can already do?
[01:04:38 CET] <mistym> I've seen both // and /* */ comments used in ffmpeg internal code. Is one preferred over the other?
[01:05:15 CET] <JEEB> I generally do // for single-liners and /* */ for multi-line
[01:05:59 CET] <atomnuker> I prefer /* */ for everything
[01:06:26 CET] <tmm1> atomnuker: ugh there's more in mpeg12dec.c too
[01:06:56 CET] <mistym> In that case I can probably pick my style, huh :b
[01:06:58 CET] <tmm1> in decode_Chunks
[01:13:49 CET] <jkqxz> atomnuker:  Which bit are you talking about?  Moving the VAAPI->DRM mapping from the OpenCL code to the VAAPI code makes it usable with other things.
[01:14:21 CET] <jkqxz> And having it use ESH if present as well as well as ABH lets you map in cases where ABH doesn't work.  (E.g. Mesa NV12 -> Beignet.)
[01:15:22 CET] <jkqxz> Oh, you replied on the ML too.
[01:32:49 CET] <tmm1> jkqxz: would h/w h264 decs be able to use this h264_metadata bsf to extract a53 side data and attach it to the decoded hw frames?
[01:33:27 CET] <jkqxz> Yes.
[01:33:35 CET] <jkqxz> Assuming they can match the input packets to output frames.
[01:33:42 CET] <cone-006> ffmpeg 03Michael Niedermayer 07master:2f37082827a4: avformat/mov: Fix integer overflows related to sample_duration
[01:33:42 CET] <cone-006> ffmpeg 03Michael Niedermayer 07master:64c9ce0abc0f: avcodec/wmalosslessdec: Reset num_saved_bits on error path
[01:33:42 CET] <cone-006> ffmpeg 03Michael Niedermayer 07master:8ee3265dbe2e: avcodec/nuv: Check for minimum input size for uncomprssed and rtjpeg
[01:33:42 CET] <cone-006> ffmpeg 03Michael Niedermayer 07master:939440ad1aa8: avcodec/nuv: rtjpeg with dimensions less than 16 would result in no decoded pixels thus reject it
[01:48:46 CET] <mistym> Is there a way to access duplicate frame info from within a muxer?
[01:49:29 CET] <atomnuker> jkqxz: libdrm 2.4.91, beignet 1.3, libva 1.1.0, mesa 17.something
[01:58:49 CET] <jkqxz> And doing what?
[01:59:27 CET] <atomnuker> sudo ffmpeg -init_hw_device "opencl=ocl:1" -f kmsgrab -device /dev/dri/card1 -framerate 30.0 -i /dev/null -filter_hw_device ocl -vf hwmap,unsharp_opencl,hwdownload,format=bgr0 -f null -
[01:59:52 CET] <jkqxz> Oh, huh.  I didn't try direct kmsgrab -> opencl.
[02:01:58 CET] <jkqxz> On your derive-not-working thing, you're running as root?  Is the failure at <https://github.com/intel/libva/blob/master/va/drm/va_drm.c#L73>, and does it work if you remove everything in that if statement?
[02:04:41 CET] <atomnuker> don't know, I don't have an easy way of compiling it and running it
[02:05:10 CET] <jkqxz> On your kmsgrab->Beignet, "-format bgra".  OpenCL doesn't support three-component formats.
[02:05:55 CET] <atomnuker> tried that, "Invalid output format bgra for hwframe download.", so I guess maybe its not supported
[02:06:01 CET] <jkqxz> Works for me.
[02:06:18 CET] <jkqxz> ffmpeg_g -v 55 -y -vsync 0 -device /dev/dri/card0 -f kmsgrab -format bgra -i - -vf 'hwmap=derive_device=opencl,unsharp_opencl,hwdownload,format=bgra' -frames:v 100 out.mp4
[02:07:14 CET] <atomnuker> ah, works now
[02:07:42 CET] <atomnuker> 4.1 fps for a 3840x2160 display :/
[02:11:37 CET] <atomnuker> mapping to opencl seems horribly slow in general, its 10 fps for a vaapi->opencl interop (hwmap,unsharp_opencl) decoding 4k h264 video, drops to 5.9 fps when you hwdownload it too
[02:12:43 CET] <jkqxz> libva checks weird things on startup because reasons.  The DRM->VAAPI derivation works fine if you are actually the DRM master rather than using CAP_SYS_ADMIN to break the restrictions on looking at framebuffers owned by other people.
[02:13:17 CET] <jkqxz> kmsgrab -> OpenCL tops out at ~120fps for me at 1920x1080.
[02:13:30 CET] <jkqxz> kmsgrab -> unsharp_opencl, I mean.
[02:14:39 CET] <atomnuker> same performance on both my laptops (intel 520 and 530), with every distribution and various vintages of beignet I've tried
[02:18:54 CET] <atomnuker> in comparison there's no speed loss mapping to vulkan and I can hwdownload the same nv12 4k video at 130fps
[02:19:09 CET] <atomnuker> I blame beignet
[02:21:53 CET] <jkqxz> Downloading mapped frames is not generally an allowed thing.  Most of the mapping APIs explcitly block it.
[02:23:53 CET] <atomnuker> oh, because they're not user visible, probably
[02:24:41 CET] <atomnuker> in vulkan I either do a gpu copy to host memory (on AMD) or copy to an intermediate buffer before copying it using the cpu to a frame
[02:25:40 CET] <atomnuker> I hear intel are going to implement the awesome host mapping thing, though they haven't yet because they've been busy with 1.1
[02:26:45 CET] <atomnuker> if somehow the memory flags of the imported frame are host visible and its tiling is linear I can skip either and download it using a cpu memcpy
[02:27:23 CET] <atomnuker> which isn't really suprising on intel because vram==gpu ram and for some reason in between my 2 laptops the framebuffer is tiled on one and linear on my 530
[02:29:50 CET] <tmm1> libavcodec/mpegvideo_enc.c:3598:5: note: in expansion of macro 'MERGE(er.error_count)'
[02:41:38 CET] <JEEB> just looking at this patch I'm more and more wondering if this is just a case of the program's PCR PID not being utilized as the reference...
[02:41:42 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/dfeeeb226094a8b00f7319b89e4d3b3660326d35
[02:41:55 CET] Action: JEEB needs to sleep on it a bit more
[02:46:07 CET] <JEEB> it does seem to help, though https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png
[02:47:27 CET] <JEEB> you don't see it due to the difference in range too well, but that's `./ffprobe -v verbose -select_streams "#274" -show_frames -of json https://kuroko.fushizen.eu/videos/pid_switch_sample.ts` dumped into JSON files and passed through http://up-cat.net/p/ba27da7f
[02:48:00 CET] <JEEB> with `./pts_plotter.py vanilla_audio.json patched_audio.json`
[03:50:04 CET] <tmm1> what's the replacement for -vaapi_device on master
[04:08:52 CET] <leif> Is the `avutil/bprint.h` file supposed to be part of the public API?
[04:09:11 CET] <leif> (I noticed that `avutil/avutil.h`doesn't seem to re-export it.
[04:10:15 CET] <wm4> avuitl.h isn't supposed to recursively include all libavutil headers if you mean that
[04:10:45 CET] <leif> Ah, okay. I think that answers my question. Thank you.
[04:14:46 CET] <tmm1> hrm i tried init_hw_device but it keeps throwing ENOMEM
[04:16:54 CET] <atomnuker> tmm1: doesn't -init_hw_device "vaapi=some_id:/dev/dri/renderDXXX" -hwaccel vaapi -hwaccel_output_format vaapi -i <file> -filter_hw_device some_id -vf <filters> work?
[04:17:33 CET] <atomnuker> (IMO hwaccels should always output their native formats, I think this got changed kinda recently)
[04:22:43 CET] <tmm1> i can't even get that far https://paste.ubuntu.com/p/nJpj5PSBBK/
[04:46:35 CET] <gagandeep> kierank: i have finally found that the wavelet transform of the first level is horizontal temporal
[04:47:03 CET] <gagandeep> so for implementing the filter do i need to take care of a specific order
[04:47:38 CET] <mistym> Does ffmpeg provide any helpers for reformatting audio into a planar format? Or is that something I need to implement myself in a muxer?
[05:05:22 CET] <atomnuker> tmm1: you've got a broken <something> on your system then
[05:06:33 CET] <wm4> mistym: libswscale, although a muxer should just request the correct format in the first place
[05:07:09 CET] <mistym> wm4: Thanks, how would I do that? Can I list an enumeration of various supported formats? There's more than one valid audio format for this container.
[05:07:27 CET] <tmm1> ok looks like configure didn't pick up my libva, and apparently ENOMEM is the error you get when built without CONFIG_VAAPI
[05:07:46 CET] <wm4> tmm1: ah, talk about useless error codes
[05:08:12 CET] <wm4> mistym: there's a list of allowed codecs I think, don't know how this would work for PCM formats though
[05:08:39 CET] <wm4> seems like there are explicit codec IDs for planar
[05:08:47 CET] <mistym> Yeah, I've got a list of them already
[05:08:59 CET] <wm4> so just look how other muxers do it
[05:15:50 CET] <mistym> I have been looking around, but I've been having a bit of trouble finding it. IIRC I was told in the past that I could set a default codec but not an enumerated list of supported codecs.
[05:17:33 CET] <atomnuker> mistym: why do you need to change input to planar though?
[05:17:59 CET] <mistym> atomnuker: This container format only supports planar stereo.
[05:18:28 CET] <atomnuker> yeah, so flag that the muxer only accepts planar PCM and ffmpeg.c will automatically convert to planar
[05:18:40 CET] <mistym> Oh great! How can I do that?
[05:19:30 CET] <wm4> I think for formats with multiple codecs, you can only hope for the best, and return an error on the wrong codec, but not sure
[05:20:08 CET] <wm4> there's no list of codecs, so I was wrong about that
[05:22:20 CET] <atomnuker> .audio_codec       = AV_CODEC_ID_PCM_S16BE_PLANAR, in the avoutputformat should work
[05:23:02 CET] <atomnuker> or just pick whatever codec id you need from avcodec.h, look for AV_CODEC_ID_PCM_<stuff>
[05:23:49 CET] <mistym> Right, I guess I can do that and make the compressed PCM format something I check for manually; so that will hint it to convert to planar automatically regardless of input
[05:24:40 CET] <mistym> Unfortunately I've got two different planar formats supported; I don't think the hint will work if the user wants one of those over the other
[05:25:38 CET] <mistym> (Specifically, AV_CODEC_ID_PCM_S16BE_PLANAR and AV_CODEC_ID_PCM_S8_PLANAR are both supported)
[05:27:52 CET] <atomnuker> make 2 muxers then with each one being identical to the other except for audio_codec
[05:28:51 CET] <mistym> Right, I guess movenc does that for QuickTime variants
[05:30:11 CET] <atomnuker> or you can use the codec_tag param and use 1 muxer
[05:30:58 CET] <mistym> Oh yeah, I was meaning to ask how that worked.
[05:39:12 CET] <mistym> I know I've seen it used in, eg, movenc. Would I need to do anything beyond creating an AVCodecTag with the appropriate codec IDs? Or is there something else I'd need to do to get the effect I'm looking for?
[05:39:26 CET] <wm4> <atomnuker> make 2 muxers then with each one being identical to the other except for audio_codec <- that sounds fishy
[06:04:12 CET] <mistym> wm4: Ideally I'd prefer to avoid that, though I can use it as the only fallback!
[06:21:31 CET] <mistym> At this point, aside from that, my muxer seems pretty close to finished... I'll have to submit it to the mailing list soon
[07:03:11 CET] <tmm1> jkqxz: i'm going to try copying your a53_option to the mpeg2_metadata bsf too
[08:25:12 CET] <wm4> so what are those a53 BSFes useful?
[08:25:16 CET] <wm4> +for
[08:41:38 CET] <tmm1> well i want to try to use them from the mpegts demuxer, to extract the a53 side data and feed it into a real subtitle stream
[08:42:29 CET] <wm4> does this solve the reordering problem?
[08:42:58 CET] <wm4> easy to solve for mpeg2, but h264...
[08:43:02 CET] <tmm1> not sure.. might not work for the h264 case
[08:44:00 CET] <tmm1> i don't really understand how the reordering works
[08:44:16 CET] <wm4> it needs to follow the frame output logic
[08:44:42 CET] <tmm1> so the packet pts isn't enough
[08:44:44 CET] <wm4> like the encoded pixel data, the a53 data is part of the encoded frame, and thus needs to be buffered and reordered for display
[08:45:00 CET] <wm4> and the h264 output logic is apparently hellish complex
[08:45:23 CET] <tmm1> but do SEI nalus get reordered too?
[08:45:28 CET] <wm4> pts could probably be used, although that is seen as fishy, and also you need to know max buffering
[08:46:03 CET] <wm4> I think SEIs generally simply affect the following frames in coding order
[08:46:16 CET] <wm4> so the a53 data is definitely reordered, with the video frames
[08:51:33 CET] <tmm1> yea i guess i need to try it and see what happens
[08:51:43 CET] <tmm1> for hw codecs like mediacodec there's no other option
[09:25:07 CET] <cone-240> ffmpeg 03Aman Gupta 07master:936312d18c98: avcodec/mediacodecdec: add debug logging around hw buffer lifecycle
[09:48:36 CET] <cone-240> ffmpeg 03Matthieu Bouron 07master:41d7c4d3813b: avcodec/mediacodecdec_common: make INFO_TRY_AGAIN trace messages more consistent
[10:58:00 CET] <Mina> Hi, I am interested in contributing to FFmpeg as part of GSoC. Is this the right place to be?
[11:01:35 CET] <jdarnley> Yes it is
[11:02:23 CET] <jdarnley> If you have your eye on a specific project/task then you should also contact the mentor directly.
[11:05:16 CET] <rcombs> wm4: tmm1: the H264 parser fills missing timestamps based on bitstream reorder info, at least to some extent
[11:06:53 CET] <rcombs> count me as interested re: the BSFs
[11:07:00 CET] <wm4> the h264 parser parser?
[11:10:25 CET] <rcombs> uh
[11:10:46 CET] <wm4> as in the h264 impl. in the parser API
[11:10:56 CET] <rcombs> yeah
[11:11:01 CET] <wm4> as opposed to BSF or other places where h264 is parsed
[11:11:14 CET] <rcombs> yeah
[11:13:34 CET] <rcombs> but yeah count me interested for sure
[11:14:00 CET] <rcombs> tmm1: I've thought about adding that sort of capacity in lavf itself
[11:14:15 CET] <rcombs> I see 2 barriers, basically
[11:15:28 CET] <rcombs> the reordering (plus the codec multiplier between MPEG-2, H264, and now HEVC [does anyone have A/53-in-HEVC samples]), and having to add an AVStream from outside the demuxer itself (not sure if this would cause problems for existing demuxer code, so maybe it would have to be an API demuxers call to opt in)
[11:16:02 CET] <wm4> what do you mean, from outsie the demuxer
[11:16:07 CET] <wm4> like utils.c?
[11:16:12 CET] <rcombs> yeah, something like that
[11:16:26 CET] <rcombs> it's mostly applicable to mpegts so I guess it could just live there
[11:16:31 CET] <wm4> some demuxers will probably not like that, so a flag would be best
[11:16:41 CET] <rcombs> yeah, figured
[11:17:10 CET] <rcombs> and then I'm not sure how I'd expose them in terms of stream selection: give them the same ID, like with the AC3+TrueHD (was that it?) thing?
[11:19:05 CET] <rcombs> or maybe give the subtitles something like `base_stream_id | 0x10000`, since MPEGTS PIDs are, what, 25-bit?
[11:19:49 CET] <rcombs> though that doesn't apply to other formats
[11:20:32 CET] <rcombs> I guess you could have funky selection constructs like 0:v:#0x104 and 0:s:#0x104
[11:22:23 CET] <wm4> I'd expose it as metadata instead of making up things
[11:22:53 CET] <rcombs> well you have to be able to select the stream, and you can't select by metadata
[11:24:57 CET] <wm4> get metadata from ffprobe -> select the needed stream index
[11:25:25 CET] <rcombs> I try not to use indexes when possible because they're not guaranteed to be stable
[11:25:42 CET] <rcombs> so if I save an index, there's no guarantee it'll be the same in a later ffmpeg version
[11:26:44 CET] <rcombs> tmm1: my other plan to deal with a53 captions was to write hwaccels for mpeg2, h264, and hevc that do nothing
[11:27:31 CET] <rcombs> which gets you frame side data, but then doing something useful with that isn't easy
[11:28:48 CET] <wm4> I'd treat indexes as unstable too
[11:28:59 CET] <wm4> didn't seem like that in Plex though
[11:29:40 CET] <wm4> yeah that idea is hacky but sounds interesting
[11:29:58 CET] <rcombs> plex uses IDs when they're nonzero
[11:29:58 CET] <wm4> probably will still waste some time parsing unnecessary things, dunno
[11:30:09 CET] <rcombs> and indexes otherwise, since not all demuxers set them
[11:30:37 CET] <rcombs> but in demuxers that don't set them, streams are usually in a fixed order in the header anyway, so there's no reason for indexes to be unstable
[11:30:59 CET] <rcombs> they're only unstable in headerless stuff like MPEGTS where the index order is just whatever order the demuxer finds them in
[11:39:04 CET] <gagandeep> kierank: how do i output to the frame using AVFrame, i have seen the code you have written with pic->linesize but i am having some problem
[11:40:02 CET] <gagandeep> odd or even field has shifted by a few pixels to the left
[11:40:21 CET] <gagandeep> one of the fields, but i can't make out which one
[11:41:31 CET] <gagandeep> kierank: also can you explain the use of horiz_filter_clip ?
[11:42:16 CET] <gagandeep> basically the last level decoding of the wavelet is to be done using horizontal temporal transform
[11:42:43 CET] <gagandeep> so i am only using horiz_filter for horizontal inverse transform
[11:48:25 CET] <gagandeep> kierank: https://imgur.com/5CKiPLB
[11:49:25 CET] <gagandeep> guys can somebody help me with av frame?
[11:50:49 CET] <durandal_1707> gagandeep: whats issue with av frame?
[11:52:40 CET] <gagandeep> please see the image posted
[11:52:50 CET] <durandal_1707> yes, and?
[11:53:43 CET] <durandal_1707> looks like width/linesize mess
[11:54:00 CET] <durandal_1707> cant guess without looking at code
[11:54:40 CET] <durandal_1707> do you have code part that deals with av frame?
[11:54:42 CET] <gagandeep> yeah i am using width in vertical filter to directly load in av frame and then linesize for shifting to the next odd row of av frame
[11:54:57 CET] <wm4> linesize is the size of a line in bytes, _including_ invisible padding
[11:55:11 CET] <wm4> width is the size of a line of visible pixels (excludes possible padding at the end)
[11:55:29 CET] <wm4> linesize is per plane (i.e. per data pointer)
[11:58:12 CET] <gagandeep> https://pastebin.com/FQyscFqW HERE IS THE CODE
[12:01:24 CET] <durandal_1707> gagandeep: interlaced vertical filter functions should use linesize instead of width i guess
[12:01:43 CET] <gagandeep> yup i am doing that now, will reply on compiling
[12:08:52 CET] <gagandeep> k, that got fixed but even after doing the horizontal temporal transform the interlaced output is still not good
[12:14:38 CET] <gagandeep> durandal_1707: when outputting some files using yadif that have only one frame, ffplay doesn't run
[12:14:53 CET] <jkqxz> tmm1:  Neat.  I primarily wrote that for use inserting the captions with encoders which don't currently support it, extract was mostly incidental (but good for testing).
[12:15:32 CET] <gagandeep> is there a filter to use for single frame interlaced files
[12:15:49 CET] <gagandeep> or some parameter needs to be passed to ffmpeg
[12:16:07 CET] <jkqxz> Maybe some of this code should be shared, though.  The MPEG-2 bit is pretty much identical, and H.265 will be as well if anyone cares about that.
[12:27:00 CET] <gagandeep> nevermind, i can just use ffmpeg to convert with yadif
[12:29:08 CET] <jkqxz> Is there any sensible way to deal with H.265 RExt subprofiles?
[12:29:32 CET] <jkqxz> Should they just all be treated as top-level profiles, even though there are 9001 of them?
[12:33:03 CET] <kierank> gagandeep: clipping for rgb
[12:33:05 CET] <kierank> that's full range
[12:38:39 CET] <gagandeep> kierank: https://pastebin.com/ABVqU05n i have tried to implement the temporal transform (interlaced_vertical_filter) and seperated progressive and interlaced in this in the last level, can you take a look at this
[12:38:59 CET] <kierank> gagandeep: please send a git diff
[12:44:17 CET] <jkqxz> nevcairiel:  Is there any RExt support at all in DXVA2?
[12:50:02 CET] <gagandeep> kierank: for sending the git diff, i need to do git apply patch.diff?
[12:54:08 CET] <durandal_1707> gagandeep: you need to apply changes, or just do: git diff
[13:00:00 CET] <gagandeep> yeah so does kierank wants me to upload the git diff file somewhere or directly send it via git send-mail
[13:00:21 CET] <kierank> on phone
[13:00:24 CET] <kierank> sorry
[13:00:31 CET] <durandal_1707> gagandeep: pastebin git diff
[13:00:37 CET] <gagandeep> k
[13:01:38 CET] <gagandeep> kierank: https://pastebin.com/aMq03Q55
[13:03:59 CET] <gagandeep> it is not final and it is still problematic but see if some feature like clip is to be used for the pixel
[13:06:00 CET] <durandal_1707> gagandeep: have new picture of output?
[13:11:28 CET] <gagandeep> kierank: i need to do some work right now, so i will be logging off now and will discuss with you later :)
[13:32:06 CET] <nevcairiel> jkqxz: not really,  nvidia hardware can do 12-bit, but the dxva2 specs dont expose it (yet)
[13:35:44 CET] <jkqxz> I just installed the 16299 SDK, and the headers don't mention anything beyond Main and Main 10.
[13:35:45 CET] <nevcairiel> technically there is no reason why it wouldnt though, the data structures contain all the things, they would just need to define a profile for it
[13:36:18 CET] <jkqxz> I'm wondering about <https://github.com/intel/libva/pull/195>.
[13:36:27 CET] <jkqxz> (Intel seems to be getting support for all the things.)
[13:36:51 CET] <nevcairiel> libva might, but non-420 chroma is still unlikely to be done in hardware
[13:37:03 CET] <jkqxz> (Including ones like Main 4:2:2 profile which doesn't actually exist.)
[13:37:34 CET] <nevcairiel> hevc profiles are a bit odd anyway, technically its all "RExt" profile, unless you take the rext feature bits and somehow make profiles out of them
[13:38:05 CET] <jkqxz> That's what Intel seems to want to do here.  I'm not sure that filling the profile list with all 9001 of these things is useful to anyone.
[13:38:26 CET] <nevcairiel> i considered doing that in avcodec, tbh
[13:38:36 CET] <nevcairiel> but i just got lazy and see very few rext files anyway
[13:39:36 CET] <jkqxz> Put the general_max_Nbit_constraint_flag and friends in the bits above general_profile_idc as the FF_PROFILE values?
[13:40:57 CET] <nevcairiel> yeah basically read the 8 rext constrain bits into the profile somehow
[13:41:18 CET] <durandal_1707> atomnuker: have you finished atrac9?
[13:41:21 CET] <nevcairiel> or 7, i think one of those is not good for a profile
[13:41:50 CET] <nevcairiel> or was it 8 good ones and one that wasweird
[13:41:52 CET] <nevcairiel> something like that
[13:41:54 CET] <nevcairiel> been a while
[13:42:40 CET] <jkqxz> 8 good ones and 1 irrelevant in table A.2.
[13:43:12 CET] <atomnuker> durandal_1707: I got band extension working, which was the last thing I had to implement, I still need to find out why some files don't decode properly (seems there's padding in between frames)
[13:43:35 CET] <jkqxz> Adding them has the nice property that zero means not-constrained, so existing REXT profile would be correct.
[15:25:12 CET] <jamrial> people need to configure they email clients right. eleven part patchsets with no reply-to headers make a mess on people's inboxes
[15:36:20 CET] <atomnuker> what client do you use?
[15:40:22 CET] <BBB> what is the way to set timestamps in libavfilter again?
[15:40:27 CET] <BBB> (override timestamps)
[15:40:35 CET] <BBB> there was a way to do it but I forgot :(
[15:47:23 CET] <durandal_1707> BBB: setpts?
[15:47:38 CET] <BBB> THANK YOU!!!!!
[15:47:57 CET] <BBB> (I mean it)
[15:48:01 CET] <durandal_1707> i accepts $
[15:48:06 CET] <BBB> lol
[15:48:13 CET] <BBB> do you want to do contract work? or just $?
[15:48:56 CET] <durandal_1707> $ first, contract work later
[15:48:59 CET] <jamrial> atomnuker: thunderbird, but it's not my client that matters, it's the sender's not setting reply-to headers
[15:49:35 CET] <BBB> durandal_1707: hm& Ill buy you beer at this summers VDD, is that ok?
[15:49:41 CET] <BBB> its a fair $ substitute
[15:50:29 CET] <durandal_1707> i drink only milk
[15:52:54 CET] <iive> jamrial, i thought these are sent through git itself
[15:53:20 CET] <jamrial> iive: usually
[15:53:31 CET] <jamrial> one of the patchsets i replied to was sent with git send-email
[15:53:47 CET] <jamrial> yet not as a single thread
[15:54:11 CET] <jamrial> afaik the default is setting reply-to headers, so it was manually disabled for some reason
[16:10:33 CET] <nevcairiel> all the mails i've seen have reply-to headers
[16:10:39 CET] <nevcairiel> and i dont care about the thread thing personally
[16:10:57 CET] <nevcairiel> (also, the ML itself sets the reply-to headers, anyway)
[16:11:37 CET] <nevcairiel> what is more annoying is if people send replys to you and only put the ML in CC, then most mail clients also default to responding to the person only, and not the ML
[16:12:41 CET] <wm4> yeah
[16:13:04 CET] <wm4> then I have to edit the recipient list in my client too
[16:13:09 CET] <wm4> pretty annoying
[16:13:14 CET] <wm4> but I blame my mail client
[16:13:23 CET] <nevcairiel> if i notice it early enough i can hit reply to all or reply to list
[16:13:43 CET] <nevcairiel> well not sure a client is doing anythign wrong if the ML is only in CC
[16:21:20 CET] <cone-045> ffmpeg 03Vishwanath Dixit 07master:9c249110ea97: avformat/hlsenc: fix for zero EXTINF tag duration
[16:22:40 CET] <jamrial> nevcairiel: i'm talking about Jun Zhao's and Steven Liu's latest patchsets
[16:24:26 CET] <jamrial> no In-Reply-To or References headers, so mail clients consider each of them a new separate thread
[16:25:02 CET] <nevcairiel> you should specify that you mean "In-Reply-To" and not "Reply-To", because those are entirely different things
[16:25:14 CET] <nevcairiel> and the second is present everywhere
[16:25:32 CET] <jamrial> ah, sorry
[16:25:45 CET] <jamrial> and no, it's not in Zhao's set
[16:26:02 CET] <nevcairiel> is for me
[16:26:48 CET] <nevcairiel> and i dont care about those threading headers anyway
[16:27:10 CET] <nevcairiel> i have a folder all patch mails go into, and i actually prefer them displayed flat out instead of folded under the first one
[16:28:14 CET] <jamrial> really? they push everything else up (or down) in your inbox, and looks incredibly ugly
[16:29:03 CET] <nevcairiel> they dont if they go into their own folder and only push themselves around =p
[16:29:22 CET] <nevcairiel> do you have everything from everywhere in the same inbox folder?
[16:29:24 CET] <nevcairiel> now that would annoy me
[16:31:05 CET] <jamrial> no, i have one folder per mailing list
[16:32:31 CET] <jamrial> gmail imap on thunderbird, so it's all synced. no idea how it looks in webmail since i don't use it
[16:32:45 CET] <nevcairiel> gmail webmail doesnt do threads anyway
[16:33:49 CET] <jamrial> thunderbird does, and it makes reading patchsets bearable for me :p
[16:55:32 CET] <jamrial> kierank: ping
[16:55:41 CET] <kierank> jamrial: pong
[16:56:51 CET] <jamrial> kierank: can you try https://github.com/jamrial/FFmpeg/commits/h2645_parse and see if that excessive memory usage you fixed some time ago in h2645_parse comes back for you?
[16:57:20 CET] <kierank> jamrial: yes but iirc there's a sample on trac that does it
[16:57:41 CET] <kierank> oh i don't use parser btw
[16:57:44 CET] <kierank> it was code in the decoder
[16:58:06 CET] <kierank> unless that code is shared
[16:58:27 CET] <kierank> https://trac.ffmpeg.org/ticket/6789?cversion=0&cnum_hist=4
[16:59:49 CET] <jamrial> it is shared, yes
[17:01:10 CET] <kierank> that's the sample I did testing on
[17:02:56 CET] <jamrial> i can't play those PCAP files
[17:04:49 CET] <kierank> https://usercontent.irccloud-cdn.com/file/JIs1o8Fx/BadPacketStream.ts
[17:05:11 CET] <kierank> you have to loop it though with multicat
[17:05:21 CET] <kierank> these errors don't occur on files easily
[17:05:32 CET] <kierank> or you could concatenate and hope the ts demux does something sane
[17:05:52 CET] <jamrial> ok, will give that one a try
[17:12:23 CET] <jamrial> kierank: "./ffmpeg -f concat -i BadPacketStream.concat -f null -" with the concat file loading the above sample like 80 times resulted in memory consumption never going above ~200mb
[17:13:08 CET] <kierank> ah sorry
[17:13:11 CET] <kierank> you've got to use all 3
[17:13:31 CET] <kierank> https://usercontent.irccloud-cdn.com/file/MzyhzdMW/PacketStream1.ts
[17:13:35 CET] <kierank> https://usercontent.irccloud-cdn.com/file/KWhu9e3n/PacketStream2.ts
[17:13:36 CET] <kierank> as he explains in the ticket
[17:13:51 CET] <kierank> you might be able to concatenate them in the order
[17:14:06 CET] <kierank> but probably worth reverting to an ffmpeg before my patch and seeing the issue first
[17:23:36 CET] <mistym> Wanted to follow up on last night - is there a good way to hint ffmpeg that I want more than one planar audio format for a muxer?
[17:24:11 CET] <mistym> By setting PCMS16BE_PLANAR as the default audio codec I can get ffmpeg to automatically reformat audio into planar for me, but this muxer also supports PCM8_PLANAR.
[17:24:30 CET] <nevcairiel> you can accept multiple, but muxer can only have one default format
[17:24:53 CET] <mistym> Is there a way to tell it about the other one? Since users can't specify planar formats on the CLI, IIRC
[17:25:14 CET] <nevcairiel> you can specify any codec on the cli
[17:28:11 CET] <mistym> Oh yeah, looks like it, misremembered.
[17:28:41 CET] <mistym> So I guess I just can't get it to automatically reformat pcms8 stereo as planar, and it'd require the user to manually specify it?
[17:29:01 CET] <nevcairiel> it would always pick the default format unless overriden
[17:38:31 CET] <tmm1> rcombs: dummy hwaccel for a53 is wn interesting idea
[17:41:38 CET] <jamrial> kierank: nice, was able to reproduce it reverting your fix, but not with my changes in the above repository
[17:45:43 CET] <jamrial> kierank: the issue was apparently in av_fast_padded_malloc(). using any other method to allocate the buffers solves this
[17:46:00 CET] <kierank> no the issue is the way the nals are allocated
[17:46:45 CET] <jamrial> take a look at my repository above. it reverts your changes and allocates one buffer per nal like it used to, but using avbufferref rather than av_fast_padded_malloc()
[17:47:14 CET] <jamrial> and the issue is gone
[17:50:18 CET] <jamrial> the first of the two patches in the repository does that. the second just removes some excessive padding but i need a certain fuzzed file to make sure it's fine
[17:52:02 CET] <mistym> Actually I'm reminded, I meant to ask something else related to this muxer
[17:52:45 CET] <mistym> The only supported video codec is Cinepak, but it uses a minor variant of Cinepak that IIRC isn't used in any other container format.
[17:53:19 CET] <mistym> Would it be more correct for me to reformat the video packets within the muxer, or to add an option within the Cinepak encoder and make the container require it somehow?
[17:54:18 CET] <mistym> (The variant only involves tacking on a brief 16-bit header to every video packet, as far as I know. Possibly tweaking a length value to compensate.)
[17:56:14 CET] <nevcairiel> if this is basically only a header or something, and this is the only place its ever going to be used, its probably best to do that in the muxer
[17:57:48 CET] <mistym> Yeah, from the documentation I've read there's no change to the data beyond *maybe* tweaking the reported packet size. When decoding ffmpeg just drops the extra header bytes entirely.
[17:57:52 CET] <mistym> Thanks!
[18:00:29 CET] <kierank> jamrial: and how does that reduce memory usage
[18:01:20 CET] <kierank> the problem is that the old code allocated the largest nal amount possible for every nal thousands of times
[18:02:25 CET] <kierank> I also don't understand the need for the change
[18:03:25 CET] <nevcairiel> afaik the old code specifically tried to avoid allocating a new buffer for every nal and instead reuse a persistent buffer, changing it to a new allocation for every buffer would always have been easy, but it may impact performance
[18:04:02 CET] <jamrial> kierank: av_fast_padded_malloc() may have been leaking memory before your fix
[18:04:34 CET] <jamrial> and my intention is to go back to one buffer per nal but using avbufferref instead so they can easily be reused on things like cbs
[18:05:08 CET] <nevcairiel> please do include proof that it doesnt make decoding slower :p
[18:05:14 CET] <jamrial> without the need for lots of memcpy
[18:05:29 CET] <kierank> nevcairiel: that's the old old code
[18:05:31 CET] <jamrial> nevcairiel: well, if anything, it would make it as fast as it was before kierank's fix :p
[18:05:45 CET] <kierank> jamrial: no, there wasn't a leak
[18:06:04 CET] <kierank> there was just excessive allocations
[18:06:09 CET] <jamrial> then why does my patch in the above repo not reintroduce the issue even though it went back to one buffer per nal?
[18:06:26 CET] <nevcairiel> kierank: i can definitely see new allocs per nal that were not present before the patch on said branch, so clearly changes that can impact performance
[18:06:37 CET] <nevcairiel> one buffer per nal was never how it worked
[18:06:44 CET] <nevcairiel> because that would've been fine
[18:06:49 CET] <jamrial> nevcairiel: see commit 03b82b3ab9883cef017e513c7d0b3b986b3b3e7b
[18:06:52 CET] <jamrial> it was that way
[18:07:00 CET] <kierank> nevcairiel: yes the pre-elenril merge code was not per nal
[18:07:02 CET] <nevcairiel> the problem was that it used the same buffer which grew over time
[18:07:04 CET] <jamrial> kierank changed it to solve the excess memory allocation issue
[18:07:10 CET] <kierank> nevcairiel: not quite
[18:07:23 CET] <kierank> the way it allocated was based on the largest NAL it had seen
[18:07:25 CET] <kierank> and reused the buffer
[18:07:29 CET] <kierank> because of "fast"
[18:07:40 CET] <nevcairiel> thats what i mean with "growing"
[18:07:46 CET] <nevcairiel> it never shrunk ever
[18:08:12 CET] <kierank> you could have |B|S|S|S|S|S| then |S|B|S|S... it would allocate a big nal eventually for every slot
[18:08:14 CET] <kierank> and boom
[18:08:32 CET] <jamrial> which would be why using a different alloc function gets rid of the issue, as in my patch, right?
[18:08:41 CET] <nevcairiel> jamrial: av_fast_padded_malloc doesnt allocate a new buffer though, its like a realloc
[18:08:51 CET] <nevcairiel> hence central buffer that gets re-used
[18:09:13 CET] <nevcairiel> per-nal buffers were not used because of performance concerns
[18:09:19 CET] <nevcairiel> so please do measurements :)
[18:09:34 CET] <nevcairiel> also, if kierank fixed the issue, whats there to fix?
[18:09:38 CET] <kierank> iirc per nal buffers were still vulnerable
[18:09:43 CET] <kierank> just not as bad
[18:10:10 CET] <jamrial> nevcairiel: i'm not trying to fix anything, i'm trying to go back to per nal buffer as in before 03b82b3ab9 but without the issue that prompted said commit
[18:10:21 CET] <nevcairiel> like I said, we never had per-nal buffers
[18:10:46 CET] <jamrial> did you even check that commit?
[18:11:20 CET] <jamrial> it allocs a buffer on every H2645NAL struct
[18:11:31 CET] <nevcairiel> av_fast_padded_malloc is a realloc to resize the shared buffer
[18:11:48 CET] <jamrial> i'm talking about how it was before that commit
[18:11:53 CET] <jamrial> there was no shared buffer, there was one per nal
[18:11:54 CET] <kierank> yes and that was broken
[18:12:03 CET] <kierank> it was still vulnerable to large allocs iirc
[18:12:22 CET] <kierank> ah yes probably was a speed thing then for me
[18:12:27 CET] <kierank> because you could get 1 nal per MB
[18:12:29 CET] <kierank> or something
[18:13:23 CET] <jamrial> i'm trying to go back to before that commit, one buffer per H2645NAL, but without the issue described in that same commit
[18:13:36 CET] <nevcairiel> you have not explained why
[18:13:46 CET] <nevcairiel> the code works fine and less allocations is better?
[18:13:57 CET] <jamrial> i said it above, to easily reuse each nal buffer in other parts of the tree, like cbs
[18:14:18 CET] <nevcairiel> if something like cbs makes decoding slower, then I'll complain
[18:14:22 CET] <nevcairiel> so please prepare numbers
[18:14:39 CET] <wm4> is cbs involved in decoding
[18:14:52 CET] <kierank> indirectly
[18:14:52 CET] <jamrial> no, i don't plan to make that the case
[18:14:53 CET] <nevcairiel> no, but he wants to change decoder code to re-use it in cbs
[18:14:59 CET] <kierank> what nevcairiel said
[18:15:11 CET] <kierank> per nal allocs are pointless
[18:15:18 CET] <kierank> you alloc a buffer and then shrink the nals
[18:15:23 CET] <wm4> wasn't that about the parser?
[18:15:26 CET] <kierank> the nals are guaranteed to be <= to the size of the buffer
[18:15:29 CET] <kierank> wm4: code is used in the decoder
[18:15:31 CET] <kierank> shared
[18:15:34 CET] <jamrial> h2645_parse is not the parser, it's shared code
[18:15:37 CET] <wm4> kierank: even the NAL alloc?
[18:15:41 CET] <kierank> yes
[18:15:43 CET] <wm4> woah
[18:15:52 CET] <wm4> but why
[18:15:55 CET] <nevcairiel> its the main function that splits a h264/5 bitstream into unescaped NALs
[18:16:01 CET] <nevcairiel> you need that in all sorts of things
[18:16:30 CET] <wm4> is there an extra unescaping step that the decoder needs too?
[18:16:48 CET] <nevcairiel> everything that reads the bitstream needs unescaping?
[18:18:15 CET] <wm4> how wasteful
[18:18:36 CET] <kierank> wm4: how else can you unescape nals?
[18:18:38 CET] <nevcairiel> at least it makes for a bitstream without aliased startcodes
[18:18:40 CET] <nevcairiel> that would be worse
[18:19:08 CET] <nevcairiel> that reminds me of some DTS streams where the sync codes can be found in the payload, so annoying to parse sometimes
[18:19:22 CET] <wm4> I assumed it'd somehow be part of the bitstream reader
[18:21:00 CET] <nevcairiel> checking for that on every buffer re-fill would probably be worse for performance then going through it once and fixing it
[18:21:33 CET] <nevcairiel> in the annexb case it needs to scan through it once anyway to find the next NAL, in the same process it already checks if any escapes are found, and if none are in there it skips the unescaping process
[18:21:49 CET] <wm4> yeah makes sense
[18:22:06 CET] <wm4> still seems annoying
[18:22:39 CET] <jamrial> nevcairiel: does https://github.com/jamrial/FFmpeg/commit/3991d6c3b709943840adad9e30c3154695808735 look better?
[18:22:52 CET] <jamrial> can still be reused
[18:23:30 CET] <kierank> I don't understand the goal of this
[18:23:46 CET] <wm4> wants to achieve zero-copy
[18:23:53 CET] <kierank> why can't CBS just use a full size buffer like everyone else
[18:26:10 CET] <nevcairiel> jamrial: in the nice case of no escaping being needed, there suddenly is a memcpy, how unfriendly
[18:26:26 CET] <jamrial> nevcairiel: decoding never runs that part anyway
[18:26:41 CET] <jamrial> small_padding is 0 in h264dec
[18:27:41 CET] <jamrial> unless -flag2 +fast is used, admitedly
[18:35:08 CET] <nevcairiel> also technically still frees/allocs the buffer every run instead of re-using it like it did before, could probably use av_buffer_realloc to keep it identical
[18:39:07 CET] <nevcairiel> (or some more custom  code, fast_padded_malloc had the advantage of not caring if the buffer is too big - or well, that could also result in the memory use problems, but its faster)
[18:39:09 CET] <jamrial> av_buffer_realloc does a memcpy of the contents that ultimately are not going to be used, though
[18:39:30 CET] <jamrial> but in the case of the requested buffer being smaller or equalt to the existing one then yeah, it would save one alloc
[18:41:10 CET] <nevcairiel> can always through the code you have there under a simple size check
[18:41:14 CET] <nevcairiel> throw*
[18:51:05 CET] <jamrial> nevcairiel: added a check for that
[18:51:18 CET] <jamrial> maybe i could try writting a av_buffer_fast_alloc() or such
[19:50:36 CET] Action: durandal_1707 wrote hrtfm audio filter, does horizontal spatialization just fine without any HRIRs, pure magic, you only need to enter speed of sound and radius of your head
[20:12:22 CET] <atomnuker> awesome, this is for headphones, right?
[20:13:45 CET] <durandal_1707> atomnuker: yes
[20:14:28 CET] <atomnuker> can you add support for expression to set the angle? like pos(theta) = 2*current_sample_number?
[20:15:39 CET] <atomnuker> erm angle(sample_number) = 2*sample_number
[20:16:24 CET] <durandal_1707> why? better to implement filter commands
[20:16:56 CET] <atomnuker> is there a way to do that with a filter command?
[20:18:47 CET] <durandal_1707> yes, with (linear?) interpolation
[20:20:30 CET] <atomnuker> what do you mean?
[20:20:51 CET] <wm4> isn't the speed of sound basically always the same in a normal environment
[20:21:32 CET] <durandal_1707> wm4: it depends on air temperature
[20:24:32 CET] <durandal_1707> atomnuker: you set different angle of channel and it moves to it over time
[20:24:44 CET] <atomnuker> oh, that's cool, yep
[20:24:55 CET] <atomnuker> (an expression would be more flexible though)
[20:25:18 CET] <durandal_1707> and slow
[20:43:02 CET] <atomnuker> maybe
[21:55:36 CET] <cone-966> ffmpeg 03Marton Balint 07master:68f5384804fa: ffprobe: fix infinite loop in subtitle decoding
[23:05:33 CET] <BodecsB> I would like to ask about framesync
[23:09:33 CET] <BodecsB> and regarding streamselect/astreamselect filter
[23:11:53 CET] <llogan> you can just ask your questions. you may have to wait a while for answer.
[23:15:37 CET] <jamrial> atomnuker: what were you trying to do here? https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vc2enc.c;h=2e480ba8d0feba1ee40e1c924bd71a4fe2c58a82;hb=HEAD#l1169
[23:16:30 CET] <BodecsB> I found a bug in process_frame function of f_streamselect.c In some ocassion ff_filter_frame is not called and it cause the filter to hang
[23:17:57 CET] <BodecsB> I could fix by a call to ff_filter_set_ready. But I am not sure wheter is a good fix or just a hack
[23:18:37 CET] <atomnuker> jamrial: that generates the magic multiply/shift values needed to avoid divs from the table of quantizers
[23:19:01 CET] <atomnuker> it basically does the same thing daala did to generate its small division replacement tables - https://github.com/xiph/daala/blob/master/tools/divu_const.c
[23:19:15 CET] <jamrial> long on windows is the same as int, so 1UL << 32 makes the compiler complain
[23:19:26 CET] <jamrial> use UINT32_MAX instead
[23:20:14 CET] <jamrial> assuming it even makes sense to use such a mask. the variable is uint32_t and nothing seems to promote the calculation to 64bit
[23:25:31 CET] <atomnuker> yeah, seems like you're right, I'll fix it
[23:26:20 CET] <llogan> BodecsB: that's Paul B Mahol's (durandal_1707) filter, but he doesn't seem to be here now. You could ask again later, or submit a patch to ffmpeg-devel, or make a bug report.
[23:28:32 CET] <BodecsB> thank you. I thought to ask here before submit the patch. Yesterday I submitted a patch in another filter and it was a duplicate of something I was not aware. So I try to be carefull.
[23:30:18 CET] <llogan> makes sense
[00:00:00 CET] --- Tue Mar 13 2018