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

Sat May 5 03:05:03 EEST 2018

[00:12:26 CEST] <cone-506> ffmpeg 03Haihao Xiang 07master:314994051b3d: vaapi_encode_h264: Take VAAPIEncodeH264Context::sei_needed as an ORed value
[02:21:46 CEST] <cone-506> ffmpeg 03Michael Niedermayer 07master:dc7a8f731084: avcodec/h263dec: Document padding_bug_score heuristic used for wrong stuffing
[10:08:55 CEST] <cone-914> ffmpeg 03Rodger Combs 07release/4.0:b32f86596953: lavf/dashenc: don't call flush_init_segment before avformat_write_header
[11:22:11 CEST] <JEEB> ugh, sorry for the top-post on the mailing list. I felt like I had to reply ASAP and was on my phone
[12:14:44 CEST] <durandal_1707> ubitux: if you not gonna review lut3d and edgedetect patches, i gonna apply them soon
[12:14:58 CEST] <ubitux> i'll do that later today if you can wait
[12:16:41 CEST] <JEEB> ugh
[12:19:04 CEST] <JEEB> what's with the Steven Liu guy? can't he see the mismatching types, and the lack of timestamp discontinuity handling, and the possible issues with nonzero DTS..
[12:19:23 CEST] <JEEB> instead of addressing them, why just go with "it's all gonna be alright"
[12:19:52 CEST] <JEEB> (not all things have to be things that need to be fixed, but at least goddamn looked into - which most likely he didn't)
[12:19:57 CEST] <kierank> JEEB: he's a maintainer lol
[12:20:54 CEST] <wm4> ah ffmpeg's development "model"
[12:20:58 CEST] <JEEB> michaelni: if he goes on pushing that thing, please do some action as that patch clearly is not gone through the process
[12:21:32 CEST] <JEEB> I don't give a flying crap if this is called the status quo with the development model by some people, it is clearly not done yet
[12:25:08 CEST] <wm4> well, the current highly vague rules only lead to conflict and discontent, until they (hopefully) either lead to clarifications and improvements, or destroy the project as deserved
[12:28:09 CEST] <JEEB> that I don't disagree with, and writing rules generally is hard
[12:28:37 CEST] <JEEB> or at least it seems like coming up with any sort of attainable ones is
[12:28:41 CEST] <JEEB> and/or upkeeping them
[12:28:51 CEST] <JEEB> but I really don't care about that bigger problem at the moment :P
[12:28:59 CEST] <JEEB> my concern is primarily what I saw right now
[12:34:12 CEST] <wm4> writing/defining rules actually isn't that important, it's more important to establish how things should work, and to enforce it
[12:34:22 CEST] <JEEB> yes
[12:34:28 CEST] <JEEB> that's what I was *trying* to say
[12:34:29 CEST] <wm4> currently this is not working and we have flamewars every week
[12:35:11 CEST] <wm4> not like I'm a project management expert, but it seems pretty obvious that the current situation is really bad
[12:57:24 CEST] <michaelni> JEEB, what is the issue with the patch ? about discontinuities, muxers generally should not have discontinuous input timestamps
[12:59:55 CEST] <JEEB> dts is int64_t, not "unsigned int"
[13:00:17 CEST] <JEEB> just read the initial comments and if any of them are not relevant then they are not relevant. also f.ex. movenc.c takes in discontinuities just fine?!
[13:00:29 CEST] <JEEB> also I am not sure if I talked about discontinuities
[13:00:33 CEST] <JEEB> just having a nonzero start time
[13:00:50 CEST] <JEEB> but that's less important than handling the FLV int32_t timestamp roll-over
[13:01:07 CEST] <JEEB> as in, if we just make sure that we do the roll-over correctly I'm OK with that
[13:03:37 CEST] <JEEB> also my original commetns were written under the assumption of unsigned 32bit since that's what I assumed with "unsigned int", but in reality we need to do roll-over over int32_t
[13:06:59 CEST] <michaelni> JEEB, i think you should post that to the ML
[13:08:07 CEST] <michaelni> i think theres maybe some misunderstanding between people
[13:10:27 CEST] <JEEB> I don't have the mail client open right now, and I have other things to attend to right now
[13:10:31 CEST] <JEEB> unfortunately
[13:11:21 CEST] <michaelni> JEEB, btw about int32_t, the >>24 & 0x7f is what flvenc does currently, i understand that this neverf sets the sign bit even for negative int64. Which may be wrong and maybe should be changed but iam not sure this belongs in this patch
[13:14:04 CEST] <JEEB> nah, the timestamps seem to start at zero so that's probably done understandably
[13:15:13 CEST] <JEEB> although to be 100% correct someone would have to check how adobe's implementation does timestamp roll-overs
[13:15:25 CEST] <JEEB> is it just over zero, or from negative
[13:15:40 CEST] <JEEB> (most likely it will just roll over in positive values)
[13:16:06 CEST] <JEEB> so effectively we're rolling over an unsigned 31 bit integer :P
[13:30:12 CEST] <michaelni> JEEB, ive looked a bit more at this now, isnt the "0 ts might be wrong if start is not 0" issue unrelated to this patch ? Its writing 0 currently, it still does after the patch. only the midstream headers change which feels correct
[13:31:02 CEST] <michaelni> i agree that 0 might be bad if starttime is far from 0 but the patch doesnt introduce or change this issue
[14:24:53 CEST] <durandal_1707> Compn: why are you raising your opinions on ml?
[14:26:24 CEST] <wm4> to make it worse
[14:36:07 CEST] <cone-914> ffmpeg 03wm4 07master:022d4a2114d2: avformat/matroskaenc: do not write timebase as framerate
[14:36:08 CEST] <cone-914> ffmpeg 03wm4 07master:1d642ebfdb31: avformat/hls: don't propagate deprecated "user-agent" AVOption
[14:43:56 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:4bad76b6e9e4: avfilter/vf_amplify: add more options for finer filtering
[14:50:53 CEST] <Compn> durandal_1707 : because that is where discussion goes
[14:56:50 CEST] <Compn> .mkv : Used for Video files, as well those containing audio (movies) or video only
[14:56:50 CEST] <Compn> .mka : Used for audio only files, can contain any supported audio compresion format, such as MP2, MP3, Vorbis, AAC, AC3, DTS, or PCM
[14:56:50 CEST] <Compn> .mk3d : For files with stereoscopic (3D) video
[14:56:50 CEST] <Compn> .mks :Used for Subtitles that an 'elementary' matroska stream
[14:57:08 CEST] <Compn> cmon, someone should tell the mkv people to get rid of this .mks .mk3d shit we've never heard of or seen
[14:57:22 CEST] <nevcairiel> just because you have not seen those doesnt mean they exist
[14:57:27 CEST] <nevcairiel> get off your soapbox already
[14:57:34 CEST] <nevcairiel> dont exist*
[14:58:13 CEST] <durandal_1707> Compn should kill mplayer already
[15:41:29 CEST] <ubitux> should i switch to non-simd op to do f(ABCD) = {A,A+B,A+B+C,A+B+C+D}? 
[15:42:59 CEST] <ubitux> maybe with a bunch of add and ext with 0000 i could do sth
[15:43:02 CEST] <jdarnley> If you have oodles of spare regs you could do it
[15:44:27 CEST] <jdarnley> vector registers I mean
[15:44:38 CEST] <ubitux> yeah aarch64 has a shit ton of them
[15:45:18 CEST] <nevcairiel> 3 adds and 3 shifts could do it, not sure how efficient that is
[15:45:28 CEST] <jdarnley> Oh, I was picturing x86 instructions to do it
[15:46:33 CEST] <jdarnley> And I guess it depends whetehr ABCD are in vector regs already.
[15:46:47 CEST] <jdarnley> *whether
[16:08:51 CEST] <Chloe> JEEB: you have further comments for flvenc: Fix sequence header update timestamps?
[16:09:43 CEST] <nevcairiel> why does everyone feel like rushing that patch, its been on the ML for 21 hours only and the original author didnt even have time to respond to any comments yet
[16:10:57 CEST] <Chloe> nevcairiel: well i wanted to ask for more time on behalf of JEEB
[16:11:53 CEST] <Chloe> I guess it doesnt matter if there are more comments, just ask for more time anyway
[16:12:37 CEST] <JEEB> Chloe: I am currently drinking a beer after a not-so-perfect work week. to be honest, I don't even use rtmpenc, but I saw clear possible issues there (like passing int64_t through "unsigned int", and not being sure how the FLV timestamp wrap-over is going to be handled)
[16:14:26 CEST] <Chloe> JEEB: ya we gucci. Im not able to do much cause I also feel like shit but it shouldnt get pushed until you give some more comments at least hopefully
[16:19:55 CEST] <durandal_1707> Chloe: why you feel like that?
[16:22:08 CEST] <Chloe> durandal_1707: its not ffmpeg related.
[16:34:31 CEST] <cone-914> ffmpeg 03Sergey Lavrushkin 07master:9479955c6265: Adds SRCNN filter.
[17:57:00 CEST] <cone-914> ffmpeg 03wm4 07master:7074a7ccd9a4: avformat: add vapoursynth wrapper
[18:15:43 CEST] <durandal_1707> have nothing left to do, help me!
[18:18:35 CEST] <wm4> fix y4m seeking
[18:19:01 CEST] <jamrial> even more sizeof(AVFrame) :(
[18:20:12 CEST] <jamrial> you really couldn't tidy up the rawvideo implementation posted in doom9 and push that instead?
[18:20:38 CEST] <wm4> as if ABI mattered
[18:21:06 CEST] <jamrial> it does, we already released 4.0 with the new soname
[18:21:08 CEST] <wm4> as far as I can see it only sets a random unused number anyway
[18:22:28 CEST] <wm4> also you didn't comment on this when kmsgrad added it
[18:22:44 CEST] <durandal_1707> wm4: y4m seeking works fine here
[18:34:17 CEST] <JEEB> durandal_1707: do you want to check out that one case I've not had time to debug?
[18:42:39 CEST] <durandal_1707> JEEB: the midstream parameters change? i thought that is unsupported
[18:44:02 CEST] <JEEB> well at least the audio things work :P
[18:44:19 CEST] <JEEB> if input stream switches between 5.1 and stereo
[18:44:26 CEST] <JEEB> and my output is stereo, it works a'OK
[18:44:35 CEST] <JEEB> I think what didn't work is something different
[18:44:42 CEST] <JEEB> but that's not as relevant
[18:45:13 CEST] <JEEB> in this case it's to find out what happens when the audio changes and why it originally caused the end-of-stream trigger for subtitle overlay
[18:45:29 CEST] <JEEB> I made a fix for it, but it seems to have some imperfections regarding performance
[18:45:40 CEST] <JEEB> mostly because I probably didn't dive deep enough
[18:46:03 CEST] <JEEB> I can share a sample and a replication command line if you are interested
[18:46:53 CEST] <durandal_1707> JEEB: share it
[18:47:11 CEST] <JEEB> roger
[18:48:20 CEST] <JEEB> replication filter chain https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227511.html
[18:48:23 CEST] <JEEB> then the sample...
[18:49:08 CEST] <JEEB> durandal_1707: https://kuroko.fushizen.eu/samples/2018-03-26-subtitles_disappear_after_ad_pause.ts
[18:49:42 CEST] <JEEB> if you want to see the full glory, revert http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e760c12aeef608aa8b416664687b9aca3a2c6f68
[18:50:10 CEST] <JEEB> there still seems to be something wrong, though, possibly buffering or something. you don't notice it with file->file, but live stuff seems affected
[18:51:41 CEST] <wm4> 90% of ffmpeg development effort is arguing about bullshit
[18:52:25 CEST] <JEEB> durandal_1707: the diff I used to debug it https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227630.html
[19:15:33 CEST] <JEEB> durandal_1707: anyways do note if you figure anything out
[19:15:56 CEST] <JEEB> and that's why I mentioned if only the relevant parts should be re-init'd in a filter chain
[19:16:00 CEST] <JEEB> instead of the whole thing
[20:05:29 CEST] <JEEB> who's reviewing the mailing list queue?
[20:05:37 CEST] <JEEB> hanna's got a mail in the queue it seems
[20:17:12 CEST] <durandal_1707> Compn ^
[20:40:14 CEST] <ubitux> durandal_1707: do you have the edgedetect patchset in a branch?
[20:40:20 CEST] <ubitux> i'd like to give a try
[20:40:58 CEST] <durandal_1707> ubitux: cant you use patches on ml?
[20:41:07 CEST] <ubitux> i can
[20:41:19 CEST] <ubitux> it's just simpler if i run a git fetch
[20:43:47 CEST] <durandal_1707> ubitux: see canny branch
[20:44:10 CEST] <ubitux> thanks
[20:55:23 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:fe0a6bcbda0f: avcodec/mediacodec_wrapper: add helper to fetch SDK_INT
[20:55:24 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:f6681feda641: avcodec/mediacodecdec: restructure mediacodec_receive_frame
[20:55:25 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:a75bb5496ac6: avcodec/mediacodecdec: wait on first frame after input buffers are full
[20:55:26 CEST] <cone-914> ffmpeg 03Aman Gupta 07master:9b563f6584b5: avcodec/mediacodecdec: add workaround for buggy amlogic mpeg2 decoder
[20:55:54 CEST] <JEEB> has anyone received parser buffer reallocation failures from libavcodec/parser.c?
[20:56:03 CEST] <JEEB> from MPEG-TS input
[20:57:15 CEST] <JEEB> Haven't been able to capture samples of where it has happened, but if the data's not broken that'll be fun :)
[20:58:25 CEST] <tmm1> haven't seen that
[20:59:20 CEST] <JEEB> I'll probably set up a source-dumping setup next week since I've had it happen on the same source stream a few times now
[21:05:17 CEST] <jamrial> JEEB: sounds like oom? the only way to get that kind of error in parse.c seems to be that
[21:05:27 CEST] <jamrial> it should also print the amount of memory it tried to allocate
[21:29:45 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:901dc11bb67e: avfilter/vf_lut3d: add planar rgb support
[21:34:14 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:aba39cc1f18f: avfilter/vf_convolution: add column/vertical mode
[21:39:42 CEST] <tmm1> rcombs: did you see this hevc decoding regression after the videotoolbox_postproc_frame patch
[21:40:42 CEST] <rcombs> yeah, haven't had a chance to look at it yet
[21:41:28 CEST] <tmm1> trying to poke at it but i dont' understand this postproc stuff yet
[21:41:38 CEST] <tmm1> weird it doesn't trigger on all samples either
[21:41:44 CEST] <tmm1> here's a shorter one that does it: https://s3.amazonaws.com/tmm1/videotoolbox/germany-hevc-zdf.ts
[21:50:01 CEST] <JEEB> thanks to whomever who passed through hanna's e-mail :)
[21:58:38 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:d122c8b1028b: avfilter/vf_edgedetect: add canny mode
[21:58:39 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:0bcc66571aab: avfilter/vf_edgedetect: add planes option
[21:58:40 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:20c83be27a3e: avfilter/vf_edgedetect: add more formats support to canny mode
[22:04:47 CEST] <rcombs> tmm1: ¤ó¿ì§§§§
[22:06:53 CEST] <durandal_1707> JEEB: only slowdown i get is spam: Changing frame properties on the fly is not supported by all filters.
[22:09:10 CEST] <JEEB> yea, I don't think with my fix the thing is actually slowing down - but rather it might have to do with buffering or something. it seems to drop out with pushing live output into an HTTP end point
[22:09:23 CEST] <JEEB> without my fix it seems to work fine
[22:10:59 CEST] <JEEB> my next step would have been to start adding logging towards where AVFrames are received from the filter chain
[22:14:55 CEST] <durandal_1707> JEEB: so what is an issue? this happens only over network and not with files?
[22:15:33 CEST] <JEEB> I would like you to clear your mind, revert my fix and check how you would go about debugging the original issue
[22:15:45 CEST] <JEEB> because I'm pretty sure I just didn't dig deep enough :P
[22:15:52 CEST] <JEEB> also it should be relevant in file input as well
[22:16:08 CEST] <durandal_1707> but i see nothing wrong, fps=103
[22:16:10 CEST] <JEEB> whatever the issue is, it should be visible with any in/output protocol
[22:17:27 CEST] <JEEB> ok, and going by clear things that seem to go wrong there, if you are encoding the audio you should notice that there's a "audio PTS went backwards" warning
[22:17:37 CEST] <JEEB> that's not because of input
[22:17:50 CEST] <JEEB> it seems like the audio filter chain outputs the input PTS as-is after the re-init
[22:18:17 CEST] <JEEB> forgetting that you had an offset because input frame size != output frame size (most visible with AAC)
[22:18:27 CEST] <JEEB> since AC3 is 15xx samples per frame
[22:18:36 CEST] <JEEB> and AAC is (generally) 1024
[22:19:41 CEST] <JEEB> but that happens pre/post my fix so that isn't seemingly breaking anything - just either seemingly incorrect lavfi API usage, or incorrect handling of things in lavfi (one or the other, not sure if the lavfi docs specify this)
[22:24:05 CEST] <durandal_1707> JEEB: with aresample, I get strange error: Error while add the frame to buffer source(Invalid argument).
[22:24:18 CEST] <JEEB> yea
[22:24:28 CEST] <JEEB> those come before-after my patch I think?
[22:24:36 CEST] <JEEB> and yes, as I noted in the mailing list entry I mentioned
[22:24:43 CEST] <JEEB> you need the audio to get the bug to happen
[22:24:48 CEST] <JEEB> no audio - no filter chain reset
[22:26:03 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227511.html
[22:26:05 CEST] <JEEB> for the record
[22:26:21 CEST] <JEEB> and my debugging codes https://ffmpeg.org/pipermail/ffmpeg-devel/2018-April/227630.html
[22:30:55 CEST] <tmm1> rcombs: looks like some AVFrame are being returned with hw_frames_ctx==NULL
[22:31:02 CEST] <rcombs> sounds bad
[22:59:07 CEST] <tmm1> rcombs: lol wtf, hw_frames_ctx is def being set but by the time postproc is called its randomly back to NULL sometimes
[23:01:55 CEST] <durandal_1707> lol, overlay in vs is so slooow
[23:07:49 CEST] <rcombs> tmm1: watchpoint!
[23:08:09 CEST] <rcombs> tmm1: that or it's getting set for one field but not the other
[23:10:10 CEST] <BBB> does anyone want to push the libvmaf patch for me?
[23:14:04 CEST] <jamrial> i was going to ask which one, but well
[23:23:55 CEST] <cone-914> ffmpeg 03Paul B Mahol 07master:244d4ba0da00: avfilter/vf_lut3d: fix typo
[23:25:41 CEST] <durandal_1707> BBB: which patch?
[23:26:25 CEST] <BBB> https://patchwork.ffmpeg.org/patch/8699/
[23:31:29 CEST] <cone-914> ffmpeg 03Kevin Wheatley 07master:51775bc1cdef: avfilter/vf_libvmaf: the libvmaf filter tried to join on an invalid thread id
[23:32:24 CEST] <durandal_1707> FUUUUUUUUUUUUUUUUUUUUUUU, i wanted to apply it
[23:33:37 CEST] <jamrial> haha
[23:35:57 CEST] <BBB> ty <3
[23:57:59 CEST] <BtbN> the ffmpeg cli does not support changing bitrate mid stream via commands, does it?
[00:00:00 CEST] --- Sat May  5 2018