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

[burek]

[07:57:25 CET] <gagandeep> kierank: does dequantization is assembly in cineform sdk means they are doing what you have done, i.e, dequantize all high subbands together
[08:23:03 CET] <cone-272> ffmpeg 03Ravindra 07master:99230b7ef874: libavformat/dashenc: Option to set timeout for socket I/O operation
[08:23:03 CET] <cone-272> ffmpeg 03Rodger Combs 07master:08e0f45cc889: lavf/dashenc: remove unneeded call to dash_free
[08:43:17 CET] <gagandeep> kierank: you haven't seen the horizontal filter in interlaced on mobile, right?
[08:45:38 CET] <gagandeep> kierank: https://pastebin.com/epAxmdZ6, i have pasted the horizontal filter code, see for yourself that this is not haar
[08:46:21 CET] <gagandeep> though i have turned of the intrinsics (processor) code
[08:46:26 CET] <gagandeep> *off
[10:06:58 CET] <gagandeep> kierank
[11:11:45 CET] <gagandeep_> kierank: have you seen the horizontal filter i pointed you to?
[11:15:27 CET] <Chloe> gagandeep_: im sure hell see it, you probably dont need to ping him for a 6th time
[11:19:38 CET] <gagandeep_> yeah, can you guys tell me the diff b/w YUV422P10le and YUY2
[11:29:16 CET] <Chloe> gagandeep_: one is 10 bit. (You can easily find the definitions of most formats online)
[11:34:18 CET] <gagandeep_> yeah, since these formats are related most websites are not hosting information on both of them in the same place, but thanks anyways
[11:34:42 CET] <wm4> remote: -Deny-          In 64925b143ac7bb5ae4717f4de705b89eac61d655:
[11:34:42 CET] <wm4> remote: -Deny-          Trailing whitespace found in tests/ref/fate/exif-image-jpg.
[11:34:46 CET] <wm4> the fuck
[11:34:59 CET] <wm4> not my fault that ffprobe generates this crap
[11:36:20 CET] <durandal_1707> wm4: apply without that exif change?
[11:38:16 CET] <wm4> then fate fails
[11:40:04 CET] <durandal_1707> wm4: let me check if fate changes for that patch here
[11:42:03 CET] <wm4> if I make print_pkt_side_data do nothing it still dumps side data successfully...
[11:42:32 CET] <wm4> oh it's frame side data not packet, nevermind
[11:43:22 CET] <wm4> not dumping frame side data doesn't change the whitespace on other fields
[11:46:07 CET] <wm4> why does -h on the CLI commands even exist, it never prints anything helpful
[11:46:12 CET] <durandal_1707> wm4: i applied just that patch and I do not get fate changes
[11:50:14 CET] <durandal_1707> and why would you get them at all? exif does not use http code
[11:51:28 CET] <wm4> qp changes
[11:57:17 CET] <durandal_1707> wm4: are you having others commits on top of http one?
[11:59:07 CET] <wm4> from what I can see ff_tadd_rational_metadata actually adds the trailing spaces
[11:59:19 CET] <wm4> but no idea why they weren't in the fate ref file before
[12:02:05 CET] <durandal_1707> it doesnt here
[12:03:31 CET] <wm4> what doesn't
[12:04:16 CET] <durandal_1707> wm4: the thing that you run fate. fate passes here just fine with just http.c change
[12:04:49 CET] <wm4> <wm4> qp changes
[12:05:55 CET] <durandal_1707> wm4: the QP patches do this? that is even more mysterious
[12:06:28 CET] <cone-262> ffmpeg 03Steven Liu 07master:a92ca3c07c89: avformat/hlsenc: fix write wrong init file URI string problem
[12:06:28 CET] <cone-262> ffmpeg 03Steven Liu 07master:10a0436dcab3: avformat/hlsenc: reindent after previous commits
[12:06:28 CET] <cone-262> ffmpeg 03Steven Liu 07master:c60866926459: avformat/hlsenc: fix memleak problem about fmp4_init_filename
[12:06:28 CET] <cone-262> ffmpeg 03Steven Liu 07master:c8f625f52998: avformat/hlsenc: fix fmp4 single init file problem
[12:06:28 CET] <cone-262> ffmpeg 03Steven Liu 07master:f19b0c6aeea2: avformat/hlsenc: reindent after previous commits
[12:22:01 CET] <gagandeep_> kierank: are you available right now?
[12:25:32 CET] <wm4> am I the only one who hates how opaque and "magic" fate is
[12:26:02 CET] <wm4> it appears ffprobe will output those trailing spaces, and then the output is compared with the ref file ignoring those spaces
[12:26:13 CET] <durandal_1707> i see no magic in fate
[12:26:17 CET] <wm4> so when I copied the new output to the ref file, I added the spaces and thought it had to be this way
[12:26:25 CET] <wm4> what a fucking waste of time
[12:26:39 CET] <wm4> I can't even find out where it compares the ref files
[12:26:52 CET] <wm4> because it's hidden under a layer of make magic and shell shit
[12:27:14 CET] <wm4>     test "${V:-0}" -gt 0 && echo "$target_exec" $target_path/"$@" >&3
[12:27:14 CET] <wm4>     $target_exec $target_path/"$@"
[12:27:16 CET] <wm4> what does this mean
[12:27:56 CET] <durandal_1707> -gt 0 ----> greater than 0
[12:27:58 CET] <wm4> DEMDEC  = $(call ALLYES, $(1)_DEMUXER $(2:%=%_DECODER))
[12:28:08 CET] <wm4> I know how test works
[12:28:30 CET] <wm4> but I can't tell where in this shitty line noise it compares ref files
[12:28:50 CET] <nevcairiel> You can't quote single lines and ask for explanations, because they have no context
[12:30:01 CET] <wm4> ok it runs diff with -b
[12:30:04 CET] <wm4> fucking hell
[12:30:16 CET] <wm4> nevcairiel: well they're like this all over fate
[12:30:41 CET] <wm4> what I'm complaining about is that it's completely non-trivial to find out how these things fit together
[12:30:58 CET] <wm4> because who ever "designed" it made it maximally "clever" and undebuggable
[12:31:18 CET] <wm4> so why the fuck does the fate test output spaces, but the ref file has none, and why is diff called with -b?
[12:31:25 CET] <nevcairiel> I always manage when I try, so shrug
[12:31:32 CET] <wm4> why the fuck do these tags even include spaces
[12:32:04 CET] <nevcairiel> Excluding whitespace probably helps to deal with line ending differences too
[12:32:29 CET] <durandal_1707> hmm, perhaps ffprobe needs fixing
[12:34:08 CET] <wm4> it's not in ffprobe
[12:34:27 CET] <wm4> the whitespace ignoring is in fate-run.sh, the additional spaces are added in the tiff code
[12:34:48 CET] <wm4> why does git fetch on the ffmpeg repo always take so long
[12:36:06 CET] <durandal_1707> sorry, but this all makes no sense to me. Point to right combination of patches I need to apply and its order so I can reproduce this.
[12:42:53 CET] <cone-262> ffmpeg 03wm4 07master:36855abc0eb9: lavu/frame: fix inconsistent qp_table_buf deprecation
[12:42:54 CET] <cone-262> ffmpeg 03wm4 07master:4b86ac27a017: lavu/frame: add QP side data
[12:42:55 CET] <cone-262> ffmpeg 03wm4 07master:39c1d170a347: http: do not print a warning message for expired cookies
[12:42:56 CET] <cone-262> ffmpeg 03wm4 07master:c0687acbf609: http: avoid out of bound accesses on broken Set-Cookie headers
[12:42:57 CET] <cone-262> ffmpeg 03wm4 07master:b7d842c554b1: http: fix potentially dangerous whitespace skipping code
[13:44:39 CET] <cone-262> ffmpeg 03Martin Vignali 07master:b2bb1cb68be2: fate/hapqa_extract : add test for hapqa_extract bsf
[13:45:38 CET] <cone-262> ffmpeg 03Martin Vignali 07master:3e7fa34d3b68: avfilter/vf_premultiply : fix unpremultiply_offset for rgb input
[14:55:13 CET] <gagandeep_> kierank
[15:00:35 CET] <wm4> gagandeep_: making further pings will only be annoying
[15:02:09 CET] <gagandeep> i'm sorry, i just logged in so i thought of seeing if he's available
[15:16:05 CET] <gagandeep> wm4: by the way i am not sure, but if the nick in user list is present and not greyed out, means that the person is connected and are the pings handled in a different way apart from the usual color?
[15:16:56 CET] <gagandeep> like the message with the nick is rearranged on viewing the client?
[15:18:19 CET] <wm4> uh no idea
[15:18:41 CET] <gagandeep> a'right so its fine to ping once in a while ;)
[15:19:52 CET] <RiCON> gagandeep: highlights are easy to find at least in irssi
[15:20:00 CET] <RiCON> so one should be fine
[15:20:16 CET] <durandal_1707> gagandeep: i'm sure kierank will see all your pings and reply when it can
[15:20:24 CET] <gagandeep> RiCON: ohh, i will start using irssi, as i am using hexchat
[15:20:33 CET] <gagandeep> i didn't know this feature
[17:41:06 CET] <Chloe> So there's a bit of an issue with the new iteration APIs. Because of the effort to separate lavf and lavd, some of the hacky behaviour in how options are found/parsed is being exposed. Basically, finding options works on some behaviour with iterating AVClasses, and making lavd not a hack-of-a-library incrementally (i.e. by separating iteration) messed this up because the 'child_class_next' wants to iterate formats when it gets an avdevice
[17:41:25 CET] <Chloe> Essentially a way to fix it would be to have avdevices have a different child_class_next function but I'm unsure on how to achieve this
[17:43:10 CET] <Chloe> The reason this has to be fixed is that removing avdevice_register_all() in ffmpeg.c breaks searching of options, because it activates the old API which allows iteration of devices within the format iteration function.
[17:48:00 CET] <Chloe> I guess I need a avdevice_get_class
[18:21:28 CET] <cone-677> ffmpeg 03Felix Matouschek 07master:ce1d77a5e7ce: lavd: fix iterating of input and output devices
[18:39:12 CET] <durandal_1707> did anyone compared sofalizer with hrtfm already?
[18:56:39 CET] <cone-677> ffmpeg 03Mark Thompson 07master:0e782661d63b: cbs_h264: Fix overflow in shifts
[18:56:40 CET] <cone-677> ffmpeg 03Mark Thompson 07master:c4eeea76335d: cbs_h265: Use helper macro for maximum values of fixed-width elements
[18:56:41 CET] <cone-677> ffmpeg 03Mark Thompson 07master:84c3c766d86d: h264_metadata: Add support for display orientation SEI messages
[18:56:42 CET] <cone-677> ffmpeg 03Mark Thompson 07master:94d42cb4cc6e: h264_metadata: Remove unused fields
[18:56:43 CET] <cone-677> ffmpeg 03Mark Thompson 07master:84bb8327f571: cbs: Add a table of all supported codec IDs
[18:56:44 CET] <cone-677> ffmpeg 03Mark Thompson 07master:389f4c3e0d0a: hwcontext_vaapi: Fix condition for DRM device derivation
[18:57:22 CET] <jkqxz> atomnuker:  Are you against adding the vaAcquireBufferHandle() version of VAAPI -> DRM mapping at all?
[18:58:16 CET] <jkqxz> jamrial:  Happy with filter_units in the form last sent?  (+ configure dependency on cbs, like trace_headers.)
[19:04:31 CET] <jamrial> jkqxz: yeah, looks good
[19:04:40 CET] <jamrial> maybe add the bsf avoption flag that was implemented recently while at it
[19:04:45 CET] <jamrial> see edce64c9e9 for an example
[19:08:39 CET] <jkqxz> Ok.
[19:17:11 CET] <jkqxz> jamrial:  <https://0x0.st/sa0M.patch> ?
[19:20:12 CET] <jamrial> jkqxz: ship it :p
[19:24:06 CET] <jkqxz> Hmm.  Should hapqa_extract be after h264_foo in alphabetical order?
[19:25:58 CET] <jamrial> i think so. numbers then letters
[19:26:03 CET] <cone-677> ffmpeg 03Mark Thompson 07master:c99f837ddeca: lavc: Add filter_units bitstream filter
[19:26:50 CET] <jkqxz> It's before in the docs and after in the code.
[19:27:26 CET] <jamrial> docs should be changed, then
[19:29:19 CET] <sfan5> is this supposed to happen? https://0x0.st/sa0_.txt
[19:31:55 CET] <jkqxz> Damn, I missed the header.
[19:32:00 CET] <jkqxz> That is, no.
[19:33:38 CET] <jkqxz> libdrm should probably be automatic if you have VAAPI.
[19:42:43 CET] <cone-677> ffmpeg 03Mark Thompson 07master:0f3d1c69b5ed: hwcontext_vaapi: Always include DRM hwcontext header
[19:42:47 CET] <jkqxz> sfan5:  ^
[19:43:40 CET] <sfan5> ty
[20:38:25 CET] <atomnuker> jkqxz: not really, I think we should motivate people to update, and in turn motivate libva's glacial release schedule
[20:38:42 CET] <atomnuker> but I'm not against it if its in the opencl hwcontext
[20:38:59 CET] <atomnuker> since drm->opencl can't work without it
[20:40:50 CET] <atomnuker> I'd like to rely on hwcontext_vaapi for mapping vaapi->drm->vulkan and I'd need ifdeffery to figure out if drm_format is assigned otherwise
[20:41:38 CET] <durandal_1707> atomnuker: could you push latest atrac9 to github so i can a look?
[21:05:21 CET] <jkqxz> The code should be in hwcontext_vaapi anyway since it really has nothing to do with OpenCL.
[21:06:12 CET] <jkqxz> If you don't get a format modifier you can just say return an error?  You don't need any ifdeffery, do you?
[21:06:33 CET] <jkqxz> If it works without format modifiers then you do want this.
[21:10:19 CET] <atomnuker> oh? so opencl can work with the new export api?
[21:11:17 CET] <jkqxz> Beignet doesn't have anywhere to put the format modifier, but yeah it works with either.
[21:11:35 CET] <jkqxz> (The one thing you do gain is the ability to export from Mesa.)
[21:15:04 CET] <jkqxz> Vulkan should be able to do that too.  Not supplying a format modifier will mean "use whatever driver-specific magic if you can" (e.g. dri_bo_get_tiling()).
[21:17:19 CET] <atomnuker> I'll need ifdeffery since DRM_FORMAT_MOD_LINEAR == 0
[21:18:12 CET] <atomnuker> just leave new ESH one in
[21:19:03 CET] <atomnuker> (can't not supply a format modifier sadly, the extension requires one)
[21:20:21 CET] <jkqxz> What's the failure mode of just passing it through?
[21:31:36 CET] <cone-677> ffmpeg 03James Almer 07master:a094e7f16abf: avcodec/aac_adtstoasc: move the reference in the bsf internal buffer
[21:34:30 CET] <cone-677> ffmpeg 03Jun Zhao 07master:840f5b3e5ba1: lavc/h264_metadata_bsf: support dump options.
[21:34:31 CET] <cone-677> ffmpeg 03Jun Zhao 07master:2a103e12ba90: lavc/h265_metadata_bsf: support dump options.
[21:34:32 CET] <cone-677> ffmpeg 03Jun Zhao 07master:dd21f02a0447: lavc/mpeg2_metadata_bsf: support dump options.
[21:54:22 CET] <atomnuker> jkqxz: wrong tiling
[21:55:42 CET] <atomnuker> black screen too if device doesn't support it
[22:42:11 CET] <mistym> I've noticed that -c:v copy seems to consistently fail when using a particular demuxer; is there a good way to figure out what's going wrong?
[22:44:02 CET] <JEEB> -v verbose or -v debug I guess? and otherwise it's mostly debugging (be it av_log stuff or something else)
[22:49:06 CET] <mistym> "Output stream #0:0 (video): 0 packets muxed (0 bytes);"
[22:49:07 CET] <mistym> Hm :|
[22:49:14 CET] <mistym> "0 frames successfully decoded, 0 decoding errors"
[22:49:17 CET] <JEEB> that's at the end
[22:49:21 CET] <mistym> That's right.
[22:49:28 CET] <JEEB> and no decoding is what's supposed to happen with copy
[22:49:31 CET] <JEEB> since you're just demuxing
[22:49:35 CET] <mistym> Ah yeah, true.
[22:49:57 CET] <mistym> I confirmed I was able to use -c:v copy with a different container, so it seems to just be this demuxer.
[22:57:32 CET] <mistym> What functions will be called on the demuxer in this context? Wondering what I should be dropping debug logs into.
[22:57:50 CET] <nevcairiel> the demuxer does not know any difference
[23:03:45 CET] <mistym> Aha, so I'm seeing it reach the read_packet function, but then getting "cur_dts is invalid" at each of them
[23:03:53 CET] <mistym> Which doesn't happen in a context where it's reencoding instead of copying
[23:08:07 CET] <Compn> welcome to stream copy hell :)
[23:08:45 CET] <mistym> 😭
[23:08:46 CET] <JEEB> mistym: there's various things which don't get proper timestamps until after decoding
[23:08:57 CET] <mistym> JEEB: Right :/
[23:08:57 CET] <JEEB> for example if you start remuxing MPEG-TS to MPEG-TS with H.264 or MPEG-2 Video
[23:09:04 CET] <JEEB> you can end up with broken output
[23:09:27 CET] <JEEB> while if you re-encode the same thing, the decoder/encoder combo will produce working timestamps :P
[23:10:28 CET] <mistym> The reason I wanted to do this is because my videos are being rejected by a vintage decoder, and I figured I could rule out whether my muxer or the Cinepak encoder is at fault by remuxing an existing video in this format
[23:10:46 CET] <mistym> Or rather, the vintage decoder is crashing after one frame, which sure makes me think it's the Cinepak encoder and not my muxer :b
[23:11:02 CET] <mistym> I wonder, is there anything I can do in the demuxer to ensure timestamps get set properly?
[23:11:54 CET] <JEEB> if you can, you can start setting them in the demuxer, yes
[23:12:29 CET] <mistym> It looks like the demuxer is setting sample->pts but not sample->dts, which I guess is probably at fault
[23:21:02 CET] <mistym> Hmmm, that doesn't seem to be doign it. Anything else I'm missing, I wonder...
[23:44:27 CET] <jkqxz> jamrial:  Wtf?  "It expands to a constant expression of type float representing a quiet NaN."
[23:45:31 CET] <jamrial> yeah, but not all compilers do things right. this DJGPP one doesn't
[23:45:50 CET] <jamrial> and i think gcc on netbsd also had the same issue
[23:46:18 CET] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20180318204606&log=compile&slot=x86_64-netbsd-gcc34
[23:46:23 CET] <jkqxz> Hmm, can we do something else there?  I don't actually care about NAN, it's just a nice invalid value.
[23:46:52 CET] <jamrial> imo, just apply my patch. these are all super obscure systems or super old compilers
[23:48:59 CET] <jkqxz> Right, the other instances are all doing exactly the same thing.
[23:49:10 CET] <jkqxz> Ok, LGTM then.
[23:52:10 CET] <cone-677> ffmpeg 03James Almer 07master:d8ca7a7e700b: configure: add const_nan dependency to h264_metadata_bsf
[00:00:00 CET] --- Mon Mar 19 2018