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

[burek]

[01:00:58 CET] <cone-751> ffmpeg 03Hagen Schmidt 07master:59494863ff34: patcheck: Fix false detection of 'mergeable calls' when line is removed
[02:33:00 CET] <J_Darnley> I really hate the internet sometimes.  I can hardly ever recent docs or guides.
[02:33:40 CET] <J_Darnley> I'm not trying to build gcc 2.9.5
[02:44:38 CET] <Compn> J_Darnley : whjat are you trying to do 
[02:45:38 CET] <J_Darnley> back to cross compiling
[03:41:38 CET] <cone-751> ffmpeg 03Hagen Schmidt 07n2.6.5:HEAD: patcheck: Fix false detection of 'mergeable calls' when line is removed
[08:32:28 CET] <__julian> hi
[08:32:44 CET] <__julian> wm4: are you aware of anyone working on a mmal deinterlace/image_fx filter for ffmpeg yet?
[08:33:20 CET] <rcombs> not working on it at the moment but I plan to
[08:35:10 CET] <rcombs> to be really useful there'll need to be better support for hardware pixel formats in lavfi though
[08:46:42 CET] <__julian> rcombs: what's missing there for dealing hardware pixel formats?
[08:46:56 CET] <rcombs> negotiation
[08:46:59 CET] <rcombs> and conversion
[08:47:10 CET] <__julian> rcombs: the deinterlacer as of today can be used for opaque->opaque only via mmal, btw. yuv420 in/output is broken
[08:47:22 CET] <rcombs> kek
[08:47:35 CET] <__julian> rcombs: for mmal_scale I do have a testing firmware which shall be able to handle opaque->yuv420 though
[08:47:41 CET] <rcombs> oh, neat
[08:48:20 CET] <__julian> actually I have a scenario where I want to do mmal decode -> (opaque) -> mmal deinterlace -> (opaque) -> mmal_scale -> (yuv420) -> mpeg2 encode
[08:48:40 CET] <rcombs> __julian: wouldn't you want to stay in opaque to the end there?
[08:49:06 CET] <rcombs> __julian: not sure if vf_scale should learn to convert/scale between opaque buffers and yuv420p or if there should be new filters for that
[08:49:24 CET] <rcombs> (if the latter, the autonegotiation code needs to be able to use them)
[08:49:59 CET] <__julian> rcombs: as mpeg2 encode can't be done in hardware, no. the last step shall do the output to yuv420 (can be zerocopy in theory, though) for the software encoder
[08:50:29 CET] <__julian> rcombs: wrt to best performance I'd prefer to be able to do scale and format conversion in one step, but I have no idea in how far this fits the ffmpeg filter model
[08:50:54 CET] <rcombs> oh, forgot about that (re: mpeg2 encode)
[08:51:10 CET] <rcombs> __julian: it fits with how vf_scale works, at least
[08:51:16 CET] <__julian> for h264 encode of course you would want to do it all opaque
[08:51:44 CET] <__julian> ok, that's good
[08:52:03 CET] <rcombs> __julian: if you're going to work on this stuff I'd appreciate it if you could keep me (and maybe wm4) posted
[08:52:54 CET] <__julian> rcombs: actually I plan to work on this starting wednesday. hopefully nothing else comes in between. I did all the deinterlace stuff for vlc already, so it shouldn't take me too long once I've worked into the structure of ffmpeg filters
[08:53:27 CET] <rcombs> any work on the infrastructure stuff in lavc, lavfi, or ffmpeg/ffmpeg_filter for handling opaque formats in filter graphs will be useful for plenty of other hardware APIs
[09:07:26 CET] <wm4> __julian: I've planned to do this eventually (but not any time soon), but I didn't want to do it in lavfi
[09:08:16 CET] <__julian> wm4: where would you do it?
[09:08:24 CET] <wm4> since this is afaik also fully async while lavfi is sync, I was expecting data flow problems like in the decoder
[09:08:45 CET] <wm4> so I wanted to do it just in ffmpeg
[09:09:07 CET] <wm4> but if someone does it in lavfi, I'd of course make use of it
[09:10:20 CET] <__julian> yes, it's completely async, but as long as lavfi would allow a delayed output by n frames it would be ok. in vlc we have the same, filters are more or less expected to be sync
[09:11:09 CET] <wm4> well I did something similar in mpv to wrap vapoursynth, which is reasonably async, and it was terrible
[09:11:33 CET] <wm4> so I planned to add async filter support to mpv instead
[09:14:11 CET] <wm4> anyway, since lavfi supports m:n input/output, maybe it's not as bad as in the decoder
[09:21:37 CET] <rcombs> wm4: I'm going to need it in lavfi eventually
[10:44:20 CET] <cone-094> ffmpeg 03Paul B Mahol 07master:04a7ce1a8c67: avfilter/af_afade: add missing fifo write for second stream
[10:44:20 CET] <cone-094> ffmpeg 03Paul B Mahol 07master:c7b933885343: doc/filters: mention afifo
[10:57:47 CET] <cone-094> ffmpeg 03Clément BSsch 07master:56bdf61baa04: avutil/motion_vector: export subpel motion information
[13:04:42 CET] <cone-094> ffmpeg 03Matt Oliver 07master:e9ec28c95ef6: avutil/x86/bswap: Remove warning about bswap intrinsics with msvc.
[14:32:28 CET] <Daemon404> who in here would know the qsv / mfx crap well?
[14:32:45 CET] Action: j-b hides
[14:33:04 CET] <Daemon404> it's a simple question, i promise ;)
[14:33:37 CET] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=6e5864ab294c45814e6d417546f885a0c7dfb7cc
[14:33:51 CET] <Daemon404> i just need to know if this can be applied for the other two mfx-based coders
[14:34:18 CET] <Daemon404> i need to know in order to merge this:https://git.libav.org/?p=libav.git;a=commitdiff;h=fb8753ada23189076bdf903c1c001c0ca8287fae
[14:39:04 CET] <muken> lol
[14:39:28 CET] <j-b> "having 2 projects does not make us loose time".
[14:39:36 CET] <j-b> Daemon404: I will check.
[14:39:59 CET] <j-b> and of course, it makes sooo much sense to have such a fine control on the speed.
[14:40:11 CET] <Daemon404> nothing related to mfx follows logic
[14:40:12 CET] <j-b> nablet-code.
[14:40:24 CET] <kierank> j-b: "having 2 projects does not make us loose time". ???
[14:40:33 CET] <Daemon404> probably some quote he remembered
[14:40:59 CET] <Daemon404> (also i dont know who nablet are)
[14:41:32 CET] <kierank> those people doing the mfx stuff on ffmpeg
[14:41:34 CET] <j-b> stupid people, paid 200,000¬ to push their mfx crap in FFmpeg
[14:41:46 CET] <j-b> while in fact just stealing the code from Luca and making it worse.
[14:42:03 CET] <Daemon404> brb, purchasing a 10 foot pole
[14:42:19 CET] <j-b> code is bad
[14:43:02 CET] <Daemon404> also 200k is insane.
[14:43:14 CET] <j-b> Intel.
[14:43:20 CET] <Daemon404> oh.
[14:49:57 CET] <cone-094> ffmpeg 03Matthieu Bouron 07master:46feb66972bb: swscale/arm: add ff_nv{12,21}_to_{argb,rgba,abgr,bgra}_neon
[14:51:51 CET] <JEEB> :D
[15:10:07 CET] <Compn> j-b : mplayer vaapi patch on mailing list, with this quote "* Fully accelerated, with no extra redundant memcpy of image data (looking at you, VLC)." ;)
[15:10:49 CET] <j-b> Compn: VLC does 0-copy since a long time.
[15:10:59 CET] <Compn> yeah thats what i thought
[15:11:17 CET] <j-b> Android, iOS, Linux, Windows and Tizen.
[15:11:22 CET] <ubitux> if the guy is still using mplayer, it's probably because he's stuck 10 years ago
[15:11:24 CET] <j-b> And OS X, of course.
[15:20:01 CET] <Daemon404> j-b, poke me when you look at mfxcrap
[15:21:50 CET] <wm4> never mind that 0-copy can be slower
[15:44:08 CET] Action: TimNich gets really confused seeing all these references to mfx and thinking mxf&.
[15:45:21 CET] <wm4> ubitux: found a srt subtitle file that uses 0x0D 0x0D 0x0A for line breaks...
[15:45:35 CET] <wm4> lavf detects it as srt, but returns 0 subtitle events
[15:46:53 CET] <wm4> http://sprunge.us/UFgg
[15:48:57 CET] <cone-094> ffmpeg 03Michael Niedermayer 07master:188a1a17a6ec: avformat/movenc-test: Fix integer overflows
[15:51:23 CET] <ubitux> wm4: can you share the raw file?
[15:51:47 CET] <ubitux> so \r\r\n as line breaks...
[15:51:55 CET] <ubitux> while this is madness it should work, it's curious
[15:51:56 CET] <Daemon404> wm4, in my subtitle code i pre-process all input files to normalize linebreaks
[15:52:03 CET] <Daemon404> outside of the (crappy) subtitle lib i use
[15:53:58 CET] <wm4> ubitux: http://sprunge.us/bfPe
[15:54:25 CET] <ubitux> ok, let's ddos Podnapisi.NET to solve the issue
[15:55:00 CET] <wm4> that's illegal, why not just DMCA it on copyright grounds
[15:55:52 CET] <Daemon404> ubitux, sometimes you see that when someone runs a crappy dos2unix regex over a file thats already dos
[15:55:57 CET] <Daemon404> its fairly common
[15:56:08 CET] <wm4> anyway, the lavf code has some clever logic here
[15:56:17 CET] <ubitux> yeah, it needs to handle 
[15:56:19 CET] <wm4> so I'm not sure how to fix it
[15:56:19 CET] <ubitux> \r
[15:56:22 CET] <ubitux> and \r\n
[15:56:47 CET] <ubitux> but if you have \r\r\n... what does it even mean
[15:57:06 CET] <ubitux> technically it means \n\n, but this would break
[15:57:08 CET] <Daemon404> ubitux, simple fix: strip all \r that are not part of a \r\n pair
[15:57:25 CET] <Daemon404> but that just makes issues elsewhere
[15:57:30 CET] <ubitux> yes
[15:57:34 CET] <ubitux> because you have files with only 
[15:57:36 CET] <ubitux> \r
[15:57:38 CET] <wm4> the old mplayer code can read the file
[15:58:20 CET] <durandal_1707> and much more
[16:00:04 CET] <ubitux> so mmh should we just ignore \r if it's followed by \r\r\n?
[16:00:09 CET] <ubitux> :/
[16:00:31 CET] <ubitux> vim detects it as 2 
[16:00:35 CET] <ubitux> 2 \n sorry
[16:00:40 CET] <ubitux> fucking kb
[16:01:08 CET] <ubitux> or we could do that in srt itself
[16:01:32 CET] <Daemon404> its not just srt though
[16:01:34 CET] <ubitux> wm4: how does mplayer deals with multiline events in this file?
[16:01:50 CET] <ubitux> does it really interpret it as 1 linebreak?
[16:01:53 CET] <wm4> IMO conceptually it'd be best to split on \n, and then strip \r as trailing or leading whitespace
[16:02:17 CET] <wm4> ubitux: seems to end up correctly
[16:02:17 CET] <ubitux> how can this work with file with exclusively \r?
[16:02:20 CET] <wm4> no extra lines
[16:02:30 CET] <wm4> do such files exist?
[16:02:33 CET] <ubitux> yes
[16:02:34 CET] <Daemon404> yes
[16:02:43 CET] <ubitux> old macos
[16:02:49 CET] <ubitux> we had several samples for this
[16:02:49 CET] <Daemon404> and current ms word on mac os
[16:02:53 CET] <wm4> I know they do in theory
[16:03:00 CET] <Daemon404> i have had users make subtitles in ms word for mac.
[16:03:10 CET] <wm4> did you shoot them?
[16:03:23 CET] <ubitux> i personally got some \r only subtitles
[16:03:27 CET] <Daemon404> there's a layer of staff in between them and me for this reason
[16:03:44 CET] <ubitux> and actually, not \r only
[16:03:54 CET] <ubitux> because the idiot just edited the files with some shitty software on osx
[16:04:09 CET] <wm4> ah, mplayer code seems to explicitly drop empty lines
[16:04:30 CET] <ubitux> but it still needs to handle the event separator
[16:04:43 CET] <ubitux> how does it make the difference?
[16:06:25 CET] <wm4> it just keeps reading until sscanf finds the event marker
[16:06:34 CET] <wm4> (and it ignores trailing stuff there)
[16:06:35 CET] <ubitux> lol
[16:06:51 CET] <ubitux> smart mplayer is smarter than me :(
[16:07:09 CET] <wm4> and I think it only uses \n as line separator in any case
[16:07:15 CET] <wm4> for srt at least
[16:07:32 CET] <wm4> sometimes dumber and worse code is better at reading broken files
[16:07:39 CET] <wm4> not really a surprise
[16:08:18 CET] <Daemon404> you simply cannot handle all subtitles correctly, the end
[16:08:31 CET] <ubitux> wm4: can you upload it on trac? i'll have a look
[16:09:58 CET] <ubitux> i'll replace the read text chunk with a dumb sscanf 
[16:10:54 CET] <ubitux> thx
[16:12:08 CET] <wm4> ubitux: here it is ^
[16:13:11 CET] <ubitux> yep, noticed, thx
[16:13:52 CET] <ubitux> i need to upload some \r linebreak shitstorm file and the one you uploaded to fate
[16:14:16 CET] <ubitux> because in the future, people will never believe the madness we are handling in the code
[16:15:19 CET] <wm4> heh
[16:15:34 CET] <wm4> let me double check if sprunge corrupts it
[16:16:25 CET] <wm4> wtf, sprunge added a newline at the end of the file
[16:16:37 CET] <ubitux> ahah
[16:16:39 CET] <wm4> how does this even happen
[16:17:29 CET] <wm4> added the file as attachment, just in case
[16:17:47 CET] <ubitux> :)
[16:19:06 CET] <BBB> durandal_1707: youre gonna be my mr filter expert, ok? so lets say I want to use psnr/ssim but my timestamps are not exact
[16:19:10 CET] <BBB> durandal_1707: how shall we fix that?
[16:19:21 CET] <BBB> durandal_1707: right now the tools dont work at all if timestamps dont line up exactly correct
[16:20:32 CET] <durandal_1707> ah, that's because of framesync api filters use
[16:20:47 CET] <Daemon404> setpts the two streams then?
[16:21:06 CET] <durandal_1707> could play with setpts?
[16:21:07 CET] <BBB> I dont know what that means
[16:21:14 CET] <BBB> can you give an example commandline?
[16:21:18 CET] <Daemon404> it overrides the timestamps
[16:21:24 CET] <BBB> like, lets say I have a y4m of 29.97fps
[16:21:34 CET] <BBB> and if you encode that with libvpx, you get an output ivf at 30fps
[16:21:45 CET] <BBB> (you do. dont ask me why, Im not a libvpx maintainer. but thats what it does)
[16:21:46 CET] <Daemon404> http://ffmpeg.org/ffmpeg-filters.html#Examples-88
[16:21:48 CET] <BBB> so how do I compare them?
[16:22:00 CET] <Daemon404> setpts both streams, before the psnr/ssim filters
[16:22:05 CET] <Daemon404> so that timestamps match
[16:22:10 CET] <Daemon404> (it's kinda hacky bet eh...)
[16:22:17 CET] <Daemon404> but*
[16:22:28 CET] <durandal_1707> Hmm libvpx doesn't add frames?
[16:22:33 CET] <BBB> no
[16:23:25 CET] <BBB> so ffmpeg -i file1 -i file2 -lavfi [in0]setpts=N[out0];[in1]setpts=N[out1];[out0][out1]psnr[out2] -f null - ?
[16:23:53 CET] <durandal_1707> setpts=N or like that
[16:24:47 CET] <kierank> 3:21 PM <"BBB> and if you encode that with libvpx, you get an output ivf at 30fps
[16:24:47 CET] <kierank> 3:21 PM <"BBB> (you do. dont ask me why, Im not a libvpx maintainer. but thats what it does)
[16:24:48 CET] <kierank> ROFL
[16:25:09 CET] <BBB> what did I do?
[16:25:29 CET] <kierank> so why does libvpx not understand fractional framerates?
[16:25:57 CET] <BBB> dunno
[16:26:03 CET] <kierank> ...
[16:26:05 CET] <BBB> timestamping is something I prefer to not touch
[16:26:23 CET] <BBB> it understands framerates correctly when encoding with ffmpeg -c:v libvpx-vp9
[16:26:27 CET] <BBB> so I really dont care
[16:26:28 CET] <Daemon404> from what i understand, most people use vpx via ffmpeg
[16:26:31 CET] <BBB> right
[16:26:40 CET] <BBB> sometimes I want to use vpxenc directly and I run into this issue
[16:26:46 CET] <BBB> I dont think its worth fixing
[16:28:33 CET] <kierank> there's that famous vpx bug with timestamps
[16:28:51 CET] <kierank> and vlc
[16:29:36 CET] <durandal_1707> bounty?
[16:30:39 CET] <kierank> can't find it atm
[16:31:09 CET] <kierank> durandal_1707: https://bugs.chromium.org/p/webm/issues/detail?start=100&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary&id=701
[16:32:09 CET] <wm4> wow
[16:32:21 CET] <kierank> comment 3 is just glorious
[16:32:37 CET] <Daemon404> lmao\
[16:33:07 CET] <wm4> well I kind of agree that timestamps shouldn't use all bits, to leave some room for C arithmetic
[16:33:36 CET] <wm4> (which libvpx trips upon, but there got to be much more code that would)
[16:34:23 CET] <wm4> for the record, clock time doesn't fit into 64 bits either
[16:34:45 CET] <wm4> oh, they use microseconds, ok then
[16:35:27 CET] <Daemon404> also, something something mpegts streams, something, wraparound, something long uptime
[16:36:19 CET] <kierank> something something adult clock freq of 27mhz
[16:36:23 CET] <JEEB> :)
[16:36:38 CET] <wm4> what much bits do TS timestamps use? 33?
[16:36:45 CET] <Daemon404> mpegts has two clocks
[16:37:03 CET] <wm4> ew
[16:37:39 CET] <Daemon404> (90khz + 27mhz)
[16:38:54 CET] <kierank> yes a bit regrettable that PTS isn't using 27mhz
[16:39:55 CET] <Daemon404> 'a bit regrettable' could describe almost every multimedia decision ever made
[16:41:18 CET] <kierank> wm4: the clocks are (For a given program) in phase
[16:42:21 CET] <Daemon404> 'g 30
[16:49:34 CET] <ubitux> i'm trying to check if a recent osx is still doing \r exclusive files
[16:49:44 CET] <ubitux> but i can't find an editor on this thing
[16:50:00 CET] <ubitux> the textedit only wants to output rtf crap
[16:50:09 CET] <Daemon404> nothing recent does afaik
[16:50:10 CET] <ubitux> where is inotepad?
[16:50:12 CET] <ubitux> ok
[16:50:14 CET] <Daemon404> except word
[16:50:19 CET] <ubitux> like ms word?
[16:50:22 CET] <Daemon404> yes
[16:50:26 CET] <ubitux> lol
[16:55:40 CET] <wm4> which also happens to be the perfect subtitle editor, to some
[17:24:10 CET] <Plorkyeran> ms word is the perfect editor for all files it can open
[17:24:19 CET] <Plorkyeran> or files that can be mangled into something it can open
[17:26:53 CET] <durandal_1707> lies
[18:24:27 CET] <durandal_1707> ubitux: what's up with streamselect?
[18:27:58 CET] <durandal_1707> what about writing stopwatch kind of filter to measure filter or script speed?
[18:44:39 CET] <michaelni> ubitux, seems valgrind is failing for 2 aac tests on your box, i cant reproduce it here, do you have time to take a look ? (http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-valgrindundef)
[23:00:51 CET] <cone-094> ffmpeg 03Michael Niedermayer 07master:13834c101673: avcodec/mpegvideo_enc: Remove slice structured mode from H.263 as well as the code automatically enabing it
[00:00:00 CET] --- Tue Nov 24 2015