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

[burek]

[00:16:00 CET] <Compn> sware : i've seen it, i know its wrong, but i dont know what IS wrong or how to fix it. i'm very useful :)
[00:16:11 CET] <Compn> i know its playing frames out of order though :)
[00:22:02 CET] <sware> @BBB: I'm trying to find a way to get this information out as I'm doing it within chromium. It's h264 video and I am now getting some messages saying parsed frame has PTS before DTS messages 
[00:22:31 CET] <Compn> chromium video player eh
[00:22:38 CET] <sware> so I'm just hunting it down
[03:59:22 CET] <Compn> you guys get into fights that you dont need to be in :D
[05:02:12 CET] <cone-966> ffmpeg 03Aman Gupta 07master:606eac7b0713: avformat/hlsenc: add hls_flag option to write segments to temporary file until complete
[08:08:23 CET] Action: wm4 stares at the av_usleep(10000); in the code which manages transcoding data flow
[08:08:24 CET] <wm4> why
[08:10:27 CET] <wm4> d61f30a7a0231e "Do usleep(10000) when all demuxers returned EAGAIN."
[08:10:31 CET] <wm4> whatever the fuck
[08:34:02 CET] <flux> wm4, seems like reasonable behavior as an alternative to potentially even busier looping? even though I'm not familiar with the transcoding code at all ;)
[08:34:43 CET] <wm4> the API doesn't/shouldn't have such a concept of needing polling and busy waiting
[08:35:38 CET] <flux> I assume the normal way is to work wait efficiently for activity on one of the demuxers and then call its work function?
[08:36:30 CET] <flux> but, if it happens that the ie. one demuxer is "active" but returns eagain, it indicates a bug or corner case in the demuxer, and in that case the code hides the cpu-burning effect of that issue..
[08:39:28 CET] <wm4> a demuxer probably shouldn't reuen EAGAIN in the first place, and also EAGAIN has no fixed meaning in ffmpeg (but depends on the specific API)
[08:43:01 CET] <flux> it could also be that it used to be so that some demuxer returned EAGAIN but not anymore ;). does git archeology reveal anything?
[08:45:59 CET] <wm4> no idea
[08:46:11 CET] <nevcairiel> EAGAIN in demuxers doesnt make any sense, unless it comes from the underlying network protocol or something
[08:46:33 CET] <nevcairiel> some components only return it if you set the noblock flag
[10:10:47 CET] <cone-425> ffmpeg 03Paul B Mahol 07master:e87a4a85c11e: doc/filters: extend midequalizer description
[16:23:58 CET] <wm4> this cinepak dude
[16:32:12 CET] <kierank> mental
[16:34:09 CET] <wm4> and BBB is suggesting he should replace his i386 cinepak encoding server
[16:34:20 CET] <wm4> (or whatever he is doing, he isn't telling us)
[16:34:30 CET] <BBB> I think its a pretty good suggestion
[16:36:01 CET] <BBB> Im totally having fun though
[16:38:19 CET] <kierank> this is BastyCDGS levels of insane
[16:41:07 CET] <BBB> omg basty!!!
[16:41:09 CET] <BBB> I totally forgot about that
[16:55:14 CET] <JEEB> ;D
[16:56:32 CET] <nevcairiel> never forget CDGS!
[17:09:01 CET] <atomnuker> he did a lot of work, and it looks alright
[17:09:16 CET] <atomnuker> not sure what a mixer would do though
[17:11:39 CET] <kierank> he ported random amiga code
[17:11:49 CET] <kierank> that was awful and microoptimised for the amiga cpu
[17:11:55 CET] <atomnuker> that is some very good code though
[17:12:11 CET] <kierank> looooool
[17:13:18 CET] <kierank> https://github.com/BastyCDGS/ffmpeg-soc/blob/master/libavsequencer/lq_mixer.c#L1540
[17:13:23 CET] <kierank> mmm yeah great code
[17:13:28 CET] <kierank> great documentiation
[17:14:07 CET] <atomnuker> no, really, look at the intrument sample loading and envelope code, great use of macros, the headers are all well documented, and its been reasonably optimized too
[17:14:27 CET] <kierank> that code has about 2 comments in 5000 lines
[17:14:55 CET] <kierank> same for instrument
[17:15:35 CET] <kierank> i don't dare look at hq_mixer
[17:15:47 CET] <kierank> ah yes 7k lines of comment-free code
[17:15:48 CET] <kierank> lovely
[17:16:06 CET] <durandal_170> michaelni: please merge libavsequencer
[17:16:16 CET] <atomnuker> look at that beautiful use of macros
[17:16:53 CET] <kierank> yup as beautiful as swscale
[17:17:10 CET] <durandal_170> state of art
[17:39:52 CET] <wm4> first time I see &= within an if expression
[17:40:43 CET] <wm4> is that code generated or hand-written?
[17:40:58 CET] <BBB> does it matter? :)
[17:41:08 CET] <BtbN> looks like hand copy-pasted to me
[17:41:22 CET] <wm4> there's also a 200loc macro in there
[17:42:04 CET] <wm4> and a table of magic integer values that takes almost 900loc
[17:42:20 CET] <wm4> s/a table/some tables/
[17:42:45 CET] <BBB> look, if I ever needed someone to obfuscate the vp8 loopfilter x86 assembly more
[17:42:51 CET] <BtbN> what the hell is that file
[17:42:51 CET] <BBB> Im absolutely sure Id hire basty to do it
[17:43:10 CET] <wm4> that kind of code would be good as a plugin to add support for some more obscure formats
[17:43:24 CET] <kierank> wm4: "plugins" in ffmpeg
[17:43:26 CET] <kierank> have fun with that
[17:43:48 CET] <BBB> did someone say binary x86/32bit dll loader from xine/mplayer?
[17:44:16 CET] <wm4> yes I wish ffmpeg could do plugins instead of being a big monolithic lump
[17:44:40 CET] <BBB> gstreamer, vlc
[17:44:48 CET] <wm4> "no"
[17:45:01 CET] <BBB> :D
[17:45:06 CET] <nevcairiel> maybe once we're done breaking the api of everything and have a good base to start from
[17:45:43 CET] <wm4> yes I acknowledge that in the current state introducing "plugins" would be extremely harmful
[17:46:03 CET] <wm4> we'd just make weird internals forever
[21:33:01 CET] <cone-534> ffmpeg 03Petri Hintukainen 07master:dface53497c3: matroska: demux BluRay text subtitles
[21:33:02 CET] <cone-534> ffmpeg 03Michael Niedermayer 07master:8c2ea3030af7: avcodec/pictordec: Fix logic error
[21:33:02 CET] <cone-534> ffmpeg 03Maksym Veremeyenko 07master:8efb7f5a26e7: avfilter/vf_scale: Fix chroma positioning for 4:2:0 pixel format
[21:34:17 CET] <TD-Linux> wm4, check out his website (after all his git email says to)
[21:40:48 CET] <TD-Linux> BBB, also did I read it right that rgb24 to rgb565 goes through 4:2:0? :(
[21:40:58 CET] <kierank> ofc
[21:41:02 CET] <kierank> welcome to swscale
[21:41:17 CET] <kierank> this is why i forked it
[22:04:24 CET] <Compn> kierank : did you see the last sample url on the cfhd bug https://trac.ffmpeg.org/ticket/1087 ? should this bug be closed? 
[22:18:07 CET] <JEEB> kierank: have you tried zimg yet?
[22:18:15 CET] <JEEB> although that doesn't kill swscale
[22:18:42 CET] <JEEB> in the sense that if you use the zscale vf you can still get some implicit swscale fun
[22:19:09 CET] <kierank> I have been meaning to
[22:21:14 CET] <JEEB> I'll be poking at it myself API-wise soon
[22:23:19 CET] <JEEB> not sure if it should be utilized with https://github.com/sekrit-twc/libp2p or if zimg now utilizes this library
[22:37:29 CET] <ryantheseer> Anyone know how I can change libavcodec and libavformat libraries to make the RTP packet time stamps available through the API? I'm trying to decode an H264 fragmented stream of video and I need the time stamp given in the RTP packets.
[22:39:04 CET] <BtbN> You mean it doesn't set the packets pts?
[22:43:02 CET] <ryantheseer> When I tried accessing it through the API, I get a "best_effort_timestamp" instead
[22:44:50 CET] <BBB> if you disable best_effort_timestamp, you probably get the rtp timestamps, right?
[22:44:59 CET] <BBB> (since youre suggesting to modify the code anyway)
[22:47:27 CET] <ryantheseer> I can try that.
[23:23:01 CET] <atomnuker> ubitux: you really should have said it has the most annoying blue blinking led which never stops
[23:23:31 CET] <JEEB> blinkenlichten!
[23:25:17 CET] <atomnuker> 2 thick vinyl oyster card holders and a cup on top and its still leaks through the sides
[23:25:38 CET] <atomnuker> I should have gotten a non transparent box but I doubt that would help
[23:26:59 CET] <atomnuker> they could have saved a fraction of a penny and used dim red leds which would last like 50 years of continuous operation
[23:30:26 CET] <Compn> what has led ?
[23:30:31 CET] <Compn> cant edit firmware to disable it ?
[23:31:10 CET] Action: durandal_1707 edits Compn
[23:32:20 CET] <cone-534> ffmpeg 03Derek Buitenhuis 07master:91ed4e71967f: avcodec: Mark some codecs with threadsafe init as such
[23:32:21 CET] <cone-534> ffmpeg 03Rl 07master:1835ed19bb16: libavcodec/cinepak.c: fix a wrong (inverted) misleading comment
[00:00:00 CET] --- Wed Feb  8 2017