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

[burek]

[00:56:37 CEST] <cone-651> ffmpeg 03Michael Niedermayer 07master:56ddb923c63f: tools/target_dec_fuzzer: Use avcodec_register_all() instead of register_all()
[01:38:59 CEST] <cone-651> ffmpeg 03James Almer 07master:0a6ca7aa0aa1: avcodec/internal: update FF_CODEC_CAP_SETS_PKT_DTS doxy
[01:51:40 CEST] <rcombs> so, what's "scan_all_pmts" actually supposed to do
[01:54:53 CEST] <jamrial> rcombs: looks like some mpegts only thing that somehow made it to ffmpeg/ffplay/ffprobe
[01:55:44 CEST] <rcombs> it seems to be the thing that makes avformat_find_stream_info take 5 or 7 seconds on live streams (indirectly)
[01:55:52 CEST] <rcombs> and I don't understand quite what the purpose is
[01:56:28 CEST] <rcombs> like, there's code in mpegts.c that _seems_ to be trying to tell find_stream_info to finish up when it thinks all streams have been found (by clearing AVFMTCTX_NOHEADER)
[01:56:39 CEST] <james999> is that why there is 5 sec of delay when using ffmpeg to livestream to my xbox one?
[01:56:51 CEST] <rcombs> but the command line tools set scan_all_pmts, which disables that code
[01:56:53 CEST] <james999> I use -f mpegts and it's not live at all
[01:57:08 CEST] <rcombs> james999: if you mean startup latency, yes
[01:57:24 CEST] <rcombs> otherwise& maybe? There are a lot of possible factors there
[01:57:32 CEST] <DHE> that sounds like a probing issue and may be indicative of ffmpeg having trouble finding all the codec parameters it wants.
[01:58:00 CEST] <james999> can I tweak ffmpeg to get the latency minimal? my command is ffmpeg -re -i file.mp4 -vcodec libx264 -f mpegts udp://blahblah
[01:58:37 CEST] <rcombs> find_stream_info continues probing for 5 seconds while AVFMTCTX_NOHEADER is set, even if all codec parameters are found
[01:58:46 CEST] <rcombs> because it assumes more streams might show up during that time
[01:59:27 CEST] <rcombs> mpegts.c sets AVFMTCTX_NOHEADER at startup, but has code to clear it "when all programs have received a PMT"
[01:59:28 CEST] <DHE> that doesn't sound right. with mpegts you know you have everything once you have a PAT, all referenced PMTs, and info on all referenced streams. but that could take a while to measure since you need to wait for all of the above including keyframes in the UDP
[01:59:50 CEST] <rcombs> but that code is disabled when the "scan_all_pmts" AVOption is set to 1
[02:00:01 CEST] <rcombs> and ffmpeg_opt.c (and ffprobe, etc) sets that option by default
[02:00:10 CEST] <rcombs> I'm trying to understand why
[02:00:31 CEST] <DHE> but this is in avformat_find_stream_info that takes 5 seconds, right?
[02:01:10 CEST] <rcombs> yeah
[02:03:22 CEST] <JEEB> that really sounds like full probing of all the streams
[02:03:32 CEST] <JEEB> instead of trusting the PMT
[02:06:21 CEST] <DHE> another possibility is huge keyframe intervals? stream probing needs a keyframe right? x264 defaults to -g 250 I think...
[02:07:07 CEST] <JEEB> well that's what I mean with full probing. also it's time/data amount based, it won't even wait for an IRAP as far as I have seen
[02:07:30 CEST] <JEEB> if you don't get the parameter sets within the alotted probing time it will just throw hands up
[02:08:14 CEST] <DHE> ah, udp...
[02:08:58 CEST] <DHE> I mean that whimsically...
[02:41:35 CEST] <rcombs> looks like it was added by cehoyos in re: http://trac.ffmpeg.org/ticket/3762
[02:42:36 CEST] <rcombs> I think e971eef8 is bonkers
[02:42:58 CEST] <rcombs> if we want scan_all_pmts to be on by default we should turn it on by default in mpegts.c
[02:46:49 CEST] <rcombs> all documentation on the MPEGTS code seems to assume I know what all of the abbreviations mean
[02:46:52 CEST] <rcombs> (I do not)
[03:02:22 CEST] <DHE> what do you need to know?
[03:05:28 CEST] <james999> Eh that's the first time in any software type channel somebody said that. XD
[03:05:43 CEST] <james999> (well that I've seen lol)
[03:30:27 CEST] <james999> idk i'm a novice and i never know where to start with source code and doc on projects
[03:30:51 CEST] <james999> At least in channels like this you can talk to an actual person for a specific issue sometimes
[08:51:08 CEST] <cone-552> ffmpeg 03Carl Eugen Hoyos 07master:20da4135020f: lavf/nutdec: Fix an impossible condition, regression since e0c53c34.
[12:56:16 CEST] <robUx4> nevcairiel: do you know if we do any funky stuff with Win32 thread init ?
[12:56:52 CEST] <robUx4> when I use more than one thread, I get some crashes in a VLC thread when doing D3D11 calls
[12:57:22 CEST] <robUx4> with 1 thread (no pthread_frame involved) don't have any issues with the same VLC thread
[12:58:06 CEST] <robUx4> ie that thread has nothing to do with avcodec and D3D11 is not known to libavcodec at all at this stage
[12:58:37 CEST] <nevcairiel> never heard of any such things
[12:58:54 CEST] <nevcairiel> only thing I know is that its best to avoid mixing native win32 threads and some sorts of pthread wrappers
[13:00:26 CEST] <robUx4> libavcodec is using w32pthread.h which uses native win32 stuff
[13:00:38 CEST] <nevcairiel> and vlc ? :)
[13:00:45 CEST] <robUx4> they both use _beginthreadex()
[13:01:02 CEST] <robUx4> vlc doesn't use pthread on windows
[13:01:32 CEST] <robUx4> it's a crash in NVIDIA drivers, so not easy to understand why
[13:01:49 CEST] <nevcairiel> an entirely unrelated thread crashing doesnt seem to make much sense to me, unless they both do call somewhat related things
[13:02:32 CEST] <nevcairiel> (this is a good time to mention that I'm still not rather fond of mt-hwaccel use :p)
[13:03:21 CEST] <robUx4> yes, it's rather odd
[13:03:22 CEST] <nevcairiel> on that note, what version of avcodec are you using in this case? mt safety improvements have been made only recently
[13:04:02 CEST] <robUx4> 57.92.100
[13:04:31 CEST] <robUx4> (I tried libav with the same result)
[13:04:58 CEST] <nevcairiel> that should be recent enough
[13:05:37 CEST] <robUx4> yes, we force a build using a recent enough version
[13:06:38 CEST] <robUx4> basically lavc requests a frame to write to, we create a vout and do some D3D11 stuff
[13:06:46 CEST] <robUx4> then boom
[13:07:10 CEST] <robUx4> with 1 thread the frame request is in the decoder thread
[13:07:23 CEST] <robUx4> with >1 thread the frame request is in a separate thread
[13:07:39 CEST] <robUx4> the vout work is always in a separate VLC thread
[13:07:47 CEST] <nevcairiel> i assume you enabled the d3d11 mt mode
[13:08:02 CEST] <robUx4> at this stage lavc has no knowledge D3D11 will ever be used
[13:08:32 CEST] <robUx4> I call ID3D10Multithread_SetMultithreadProtected(), yes
[13:08:44 CEST] <nevcairiel> so it crashes before you ever give a frame to lavc?
[13:08:48 CEST] <robUx4> yes
[13:08:57 CEST] <nevcairiel> odd
[13:09:34 CEST] <robUx4> I create my surfaces, I try to create decoder output views, boom
[13:10:04 CEST] <robUx4> (usually the output views are created along while decoding but I moved it for testing)
[13:12:21 CEST] <nevcairiel> one crazy idea, maybe that particular thread needs to call CoInitializeEx? the lavc threads definitely wouldnt have called that
[13:12:56 CEST] <robUx4> I tried that with no effect
[13:16:32 CEST] <robUx4> if I move ID3D10Multithread_SetMultithreadProtected sooner in the code it doesn't crash on the decoder output views creation and decoding works
[13:16:50 CEST] <robUx4> it crashes on exit though...
[13:23:14 CEST] <robUx4> ah no, it was remaining test code, so I guess the thread proctection is best set as soon as one creates the device
[13:47:25 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/v94a8
[13:47:25 CEST] <KGB> 13FFV1/06master 14b15129d 15Jérôme Martinez: JPEG2000-RCT formula update...
[16:22:22 CEST] <ubitux> jamrial: hey, cool stuff with the hevc parser
[16:22:51 CEST] <ubitux> not sure if i can make any relevant review though
[16:22:56 CEST] <jamrial> yeah, it was a fun weekend project
[16:23:48 CEST] <JEEB> najs
[16:23:53 CEST] <JEEB> yea, I read those in the train
[16:24:24 CEST] <BtbN> hm, I wonder how hard it is to make ffmpeg a WebRTC peer
[16:24:36 CEST] <BtbN> would be quite useful
[16:25:01 CEST] <nevcairiel> from experience, those things are all riddled with weird complex shit =p
[16:25:19 CEST] <BtbN> yes, the whitepapers I found for it are wtf complex
[16:25:31 CEST] <BtbN> Even the official library for it is... weird
[16:25:33 CEST] <BtbN> and C++
[16:27:55 CEST] <nevcairiel> jamrial: i assume you added the logctx on all the sei parsing functions just for consistency? most of them dont seem to use it
[16:28:27 CEST] <wm4> any reason why they make it "weird complex"?
[16:28:30 CEST] <wm4> *made
[16:28:40 CEST] <BtbN> Because web 4.0
[16:29:26 CEST] <BtbN> https://webrtc.org/native-code/native-apis/ just look at all the fancy flowcharts...
[16:30:48 CEST] <jamrial> nevcairiel: yeah, it was more automatic than intentional, so i'll remove it where it's not needed
[16:31:27 CEST] <j-b> webrtc...
[16:31:31 CEST] <j-b> that's scary
[16:31:32 CEST] <nevcairiel> i dont particularly care, but its unlikely for existing sei functions to get new log calls
[16:31:37 CEST] <nevcairiel> so might as well
[18:27:58 CEST] <Mista_D> Is there a frame accurate "concat" version? If its in development, would there be anyway to bounty it?
[18:29:47 CEST] <wm4> if you mean the concat demuxer, it can't be frame accurate
[19:14:15 CEST] <cone-155> ffmpeg 03Thomas Mundt 07master:2da5bf4c2f4c: avfilter/interlace: add complex vertical low-pass filter
[19:14:52 CEST] <kierank> 10:31 AM <"j-b> webrtc...
[19:14:52 CEST] <kierank> 10:31 AM <"j-b> that's scary
[19:14:58 CEST] <kierank> yes and people want to use it for video
[19:15:04 CEST] <kierank> that's not just web conversations
[19:26:06 CEST] <ubitux> jamrial: why are you dropping md5 include from hevcdec.h? it seems you still use AVMD5
[19:26:26 CEST] <ubitux> i suppose it doesn't break checkheaders because it's a struct pointer but it's more correct to have it, no?
[19:27:24 CEST] <ubitux> ah, you move it out in the next commit
[19:27:50 CEST] <ubitux> i suppose it's a git split shortcut/mistake
[19:37:12 CEST] <jamrial> ubitux: yeah, originally patches 1 and 2 were one, but i decided to split it to make it more readable
[20:42:56 CEST] <cone-155> ffmpeg 03Muhammad Faiz 07master:9b4648a2cdeb: avcodec/decode: do not treat discarded frames as eof when draining
[20:55:55 CEST] <TD-Linux> BtbN, the easiest current solution is to use Janus in between
[20:57:16 CEST] <TD-Linux> wm4, it's complex because a) it has a lot of features and b) it has encryption (the privacy kind, not the DRM kind)
[20:58:57 CEST] <BtbN> Using WebRTC to stream to a Browser seems the best solution for low latency right now
[20:59:11 CEST] <BtbN> But it's only VP8/Opus from what I can see, so rather limited without server side transcoding
[20:59:33 CEST] <TD-Linux> also VP9, H.264 baseline, and g.711 (don't use g.711 though)
[20:59:53 CEST] <BtbN> not like any of those are better options.
[21:06:17 CEST] <cone-155> ffmpeg 03Muhammad Faiz 07master:c4be288fdbe1: ffmpeg: count packets when queued
[21:15:44 CEST] <BBB> jamrial: ping
[21:16:56 CEST] <jamrial> BBB: pong
[21:17:07 CEST] <BBB> regarding that vp9 patch
[21:17:15 CEST] <BBB> the question is probably how pkt_dts is set
[21:17:32 CEST] <BBB> as long as its set outside the scope of get_buffer, its probably ok
[21:17:50 CEST] <BBB> because the frame returned there is a frame decoded much earlier (a p-skip frame, so we just return the reference with a changed pkt_dts)
[21:17:53 CEST] <BBB> (and pts)
[21:23:48 CEST] <jamrial> BBB: it's set right after the AVCodec.decode() call in decode.c, and in ff_thread_decode_frame()
[21:23:52 CEST] <jamrial> so to be honest, i can't say
[21:24:06 CEST] <jamrial> the patch was mostly to raise awareness of the fact the decoder is setting pkt_dts without the FF_CODEC_CAP_SETS_PKT_DTS cap
[21:24:30 CEST] <wm4> BBB: when decoding, it sets AVFrame.pkt_dts to the input packet's dts
[21:24:38 CEST] <wm4> which probably makes sense in some weird way
[21:25:36 CEST] <wm4> input pkt = the one at the decode call, so basically delayed by the decoder's internal delay
[21:27:29 CEST] <BBB> I guess if it passes fate with threading etc., its ok
[21:27:31 CEST] <BBB> but hard to say
[21:28:50 CEST] <wm4> this implies fate has the correct result
[22:01:28 CEST] <BBB> wm4: fate is correct (vp9 results were generated from reference decoder)
[22:01:36 CEST] <BBB> wm4: s/fate/fate-vp9/
[22:01:51 CEST] <wm4> even the dts values? (I have no idea what dts means for vp9...)
[22:02:45 CEST] <BBB> do we even log dts values?
[22:03:03 CEST] <BBB> ¯\_(Ä)_/¯
[22:03:05 CEST] <nevcairiel> yes
[22:03:12 CEST] <BBB> we do?!?
[22:04:09 CEST] <JEEB> :D
[22:04:46 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/ref/fate/vp9-00-quantizer-00;h=de1f54aa69f43e18bb23562baca7c3fe9985edc6;hb=HEAD
[22:04:50 CEST] <nevcairiel> columns even have a headline!
[22:04:51 CEST] <nevcairiel> :D
[22:05:15 CEST] <cone-155> ffmpeg 03Muhammad Faiz 07release/3.3:58a8e4733ae0: ffmpeg: count packets when queued
[22:05:28 CEST] <nevcairiel> i would assume without re-ordering in vp9 that they are basically always equal to pts though
[22:12:17 CEST] <BBB> nevcairiel: the question was whether pts/dts are copied from the ref which were returning
[22:12:22 CEST] <BBB> (which was decoded earlier)
[22:12:30 CEST] <BBB> nevcairiel: the pts is copied afaict
[22:12:35 CEST] <BBB> so I had to re-set that
[22:12:37 CEST] <BBB> so I set the dts also
[22:12:41 CEST] <BBB> but maybe thats wrong
[22:12:42 CEST] <BBB> who knows
[22:15:58 CEST] <TD-Linux> my initial intuition is that show_existing_frame is still a packet and should have its own dts (not from the ref)
[22:16:54 CEST] <BBB> TD-Linux: I think his point is that dts is set independently of frame buffer allocation
[22:17:07 CEST] <BBB> TD-Linux: in that case, it doesnt need to be set in the decoding module (in this case ffvp9)
[22:17:15 CEST] <TD-Linux> yeah ok
[22:17:28 CEST] <BBB> but yes youre right dts should be set to the packet dts not the ref dts
[22:17:37 CEST] <nevcairiel> thats what it should do
[23:16:00 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:79aa2ff19915: avutil/softfloat: use ldexp(), fixes undefined shift
[23:32:44 CEST] <alevinsn> jamrial:  just to confirm, there are a total of 9 patches associated with "Removing HEVCContext dependencies", right?
[23:32:54 CEST] <jamrial> yes
[23:32:56 CEST] <alevinsn> and you tacked on 8 and 9 without sending a new patch set?
[23:33:06 CEST] <nevcairiel> the numbering got a bit confused
[23:33:11 CEST] <jamrial> yeah
[23:33:14 CEST] <nevcairiel> some patches have a v2, two are outside of the set
[23:33:15 CEST] <nevcairiel> :D
[23:33:27 CEST] <jamrial> the two outside the set are superseeded by those v2 :p
[23:33:40 CEST] <alevinsn> And all of these have to do with "Remove ADVANCED_PARSER in libavcodec/hevc_parser.c"?
[23:33:42 CEST] <jamrial> i'll send a new patchset in a few with the logctx change and the md5.h change ubitux mentioned
[23:34:47 CEST] <ubitux> alevinsn: yeah it's about dropping the schyzophrenic mode of the parser when the decoder is present or not
[23:35:15 CEST] <ubitux> it makes the parser and the decoder use shared code
[23:35:32 CEST] <ubitux> similar to what was done to h264 a while ago
[23:35:41 CEST] <ubitux> so you can have a fully functionnal parser without the decoder
[23:36:19 CEST] <alevinsn> and this originated as a result of a libav merge?
[23:37:16 CEST] <ubitux> yeah mmh iirc that ADVANCED_PARSER was introduced to fix regression(s?) in the parser
[23:37:25 CEST] <ubitux> due to simplifications of not using the decoder
[23:37:34 CEST] <ubitux> something along these lines, you need to check the history
[23:38:18 CEST] <alevinsn> does that mean that, after this change, libav will still have ADVANCED_PARSER while ffmpeg won't?
[23:38:35 CEST] <ubitux> no, ADVANCED_PARSER was added in FFmpeg only
[23:38:37 CEST] <BtbN> if they don't decide to merge it, yes
[23:38:53 CEST] <ubitux> it was a huge hack/workaround
[23:39:30 CEST] <alevinsn> on a separate note, I wouldn't mind a little history lesson on ffmpeg and libav since Michael resigned as leader in 2015
[23:39:41 CEST] <alevinsn> I read the e-mail he sent to ffmpeg-devel
[23:39:47 CEST] <jamrial> ADVANCED_PARSER was done in ffmpeg to keep the functionality of the parser intact after the libav merge basically reduced its functionality considerably (no sei or slice header parsing)
[23:39:52 CEST] <nevcairiel> 2015 to 2017: we worked on code
[23:39:52 CEST] <nevcairiel> :D
[23:39:57 CEST] <JEEB> yup
[23:40:02 CEST] <alevinsn> and he hoped that by resigning, libav and ffmpeg would merge
[23:40:02 CEST] <ubitux> alevinsn: we thought it would help rejoining the projects, but nothing changed
[23:40:28 CEST] <nevcairiel> there is a couple extremely stubborn people on both sides
[23:40:31 CEST] <alevinsn> so, nothing has changed, and no one is technically a leader of ffmpeg since then?
[23:40:56 CEST] <ubitux> blurry area
[23:41:28 CEST] <jamrial> there have been more collaborations from devs of both projects to both projects, but otherwise things didn't really change much in that area
[23:42:12 CEST] <jamrial> and right now ffmpeg has a voting comittee that sometimes works, sometimes doesn't
[23:42:14 CEST] <nevcairiel> in other news, gcc 7.1 was released
[23:42:19 CEST] <JEEB> yup
[23:42:22 CEST] <alevinsn> with the decision made to really move forward with not maintaining some of the libav interfaces
[23:42:35 CEST] <alevinsn> does that effectively mean it will become harder and harder to do merges?
[23:42:56 CEST] <alevinsn> this is regarding using structs directly
[23:42:57 CEST] <nevcairiel> to some degree it might make it easier in some areas, harder in others
[23:46:00 CEST] <ubitux> speaking of this, we need to go back to merges again
[23:46:14 CEST] <ubitux> we really need to avoid putting ourselves in that situation again
[23:46:16 CEST] <nevcairiel> were we blocked somewhere, or just slacking?
[23:47:02 CEST] <ubitux> next one is a h264 one fixing something we can't reproduce for a different reason
[23:47:30 CEST] <jamrial> just noop it, like the mpeg one before it
[23:48:21 CEST] <ubitux> idk..
[23:48:35 CEST] <ubitux> i'm going afk anyway right now
[23:48:37 CEST] Action: ubitux &
[23:48:43 CEST] <jamrial> ok, later
[23:49:28 CEST] <jamrial> our h264 slice code is vastly different, and kierank fuzz tested it a lot, so unless we're sure it fixes something, better to just noop it
[23:58:41 CEST] <jamrial> nevcairiel: there, pretty much the same save for the logctx and md5.h changes, plus some cosmetics, makefile changes and patch order
[23:59:42 CEST] <nevcairiel> i read most of them today and it seemed fine, going to give them another pass a bit later
[00:00:00 CEST] --- Wed May  3 2017