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

[burek]

[00:25:07 CEST] <Zeranoe> Any particular reason this hasn't been committed? https://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/217977.html
[00:26:39 CEST] <jamrial> Zeranoe: nobody noticed it in the ml, i guess
[00:26:41 CEST] <jamrial> i'll push it
[00:28:29 CEST] <Zeranoe> Oh wow, ffmpeg.org is participating in battleforthenet
[00:29:12 CEST] <Zeranoe> jamrial: Appreciate it
[00:33:46 CEST] <jamrial> Zeranoe: done
[00:34:00 CEST] <jamrial> looks kinda ugly, though
[00:35:38 CEST] <Zeranoe> I figured the strong placement was for what made it unique from the others?
[00:35:59 CEST] <Zeranoe> but yeah, I don't know why we're using any strong elements
[10:15:22 CEST] <JEEB> rcombs: hmm, how was mpeg-1 audio defined in ISOBMFF?
[10:15:34 CEST] <JEEB> I remember having some herps and derps about that
[10:15:41 CEST] <rcombs> dunno, I've never seen that
[10:15:46 CEST] <JEEB> ok
[10:15:53 CEST] <rcombs> just mp2
[10:16:00 CEST] <JEEB> oh right, the file is called "mp3 parsed as mp1" lol
[10:16:03 CEST] <JEEB> so it was the other way
[10:16:11 CEST] <JEEB> lavf flagged it as mp1 audio
[10:16:22 CEST] <JEEB> and then lavc would of course eat it
[10:16:33 CEST] <JEEB> but if you were in DShow you could get the MS MPEG-1 audio decoder
[10:16:36 CEST] <JEEB> which would just derp
[10:17:16 CEST] <JEEB> seems to have been http://www.cccp-project.net/beta/test_files/mp3_parsed_as_mp1.mp4
[10:20:05 CEST] <JEEB> LGTM'd the movdec related stuff
[10:21:10 CEST] <rcombs> michaelni had an issue with a file from trac, I think, but I wasn't able to reproduce
[10:21:21 CEST] <rcombs> not sure if that means I fixed it since I last sent this series, or if it's something else
[10:27:23 CEST] <rcombs> JEEB: meanwhile, lol @ shitty platform decoders forcing differentiation between MPEG audio layers
[10:27:34 CEST] <JEEB> yes
[10:27:57 CEST] <rcombs> I can't think of a reason for this
[10:28:17 CEST] <JEEB> well the fourccs are different and the built-in mpeg-1 audio decoder is the ancient one
[10:28:24 CEST] <JEEB> while the one for mp3 is a newer one
[10:28:28 CEST] <JEEB> (´4@)
[10:28:40 CEST] <JEEB> or actually not sure, might be the same one but the FourCC controls it or something
[10:28:51 CEST] <JEEB> at this point I'm not even sure
[10:29:04 CEST] Action: JEEB kind of has moved away from DShow being his daily driver
[10:29:10 CEST] <rcombs> smart man
[10:29:43 CEST] <JEEB> as soon as the opengl stuff in mpv worked well enough under windows I jumped over with no regrets
[10:29:51 CEST] <JEEB> since I didn't need the mpc-hc ui
[10:30:13 CEST] <JEEB> (since the WASAPI audio renderer got done first I remember and thus that wasn't a problem)
[10:32:36 CEST] <ubitux> JEEB: i often use concat demuxer, and actually i have it in production
[10:32:43 CEST] <ubitux> it's useful when you're splitting encode typically
[10:32:49 CEST] <ubitux> (and then chunk remux everything at the end)
[10:33:04 CEST] <ubitux> it's not a "random stupid usecase"
[10:33:28 CEST] <JEEB> I'm pretty sure I didn't use the word "stupid"
[10:33:36 CEST] <ubitux> sure, i did ;)
[10:33:45 CEST] <JEEB> and yes, I noted it will work for specific use cases
[10:33:52 CEST] <ubitux> also, when you have a stack with a relatively high risk of failure
[10:33:59 CEST] <ubitux> you actually want to do multiple encodes
[10:34:05 CEST] <ubitux> even if it's not in parallel
[10:34:16 CEST] <ubitux> then you can start again the encode later etc
[10:34:22 CEST] <JEEB> the problems happen when people try to use it outside those working use cases
[10:34:23 CEST] <ubitux> the final step being a concat demux/remux
[10:34:45 CEST] <ubitux> well, the concat demuxer has constraints on the input
[10:34:57 CEST] <ubitux> it errors if not met, i don't think that's a bad thing
[10:35:03 CEST] <JEEB> definitely not
[10:35:20 CEST] <ubitux> really, the concat demuxer helps a lot of people
[10:35:24 CEST] <JEEB> it does
[10:36:14 CEST] <ubitux> and i don't think it's more a hack than hls & friends
[10:36:23 CEST] <ubitux> it's exactly the same principle behind
[10:36:39 CEST] <ubitux> anyway, i should probably tell that to wm4
[10:36:52 CEST] <ubitux> but i think he's salty enough currently
[10:37:08 CEST] <JEEB> for example just now someone was complaining about a/v desynch with it on #ffmpeg and I can't really help with that :P
[10:37:23 CEST] <JEEB> it could have been the guy's splitting or concat
[10:37:27 CEST] <JEEB> or both augmented
[10:37:32 CEST] <JEEB> E_NO_IDEA
[10:37:56 CEST] <ubitux> :)
[11:56:16 CEST] <memeka> hi ... where can i find the code that copies a buffer *after decoding* to the output device?
[11:57:19 CEST] <memeka> is it av_memcpy_backptr ?
[11:59:59 CEST] <nevcairiel> without context, we can't answer that.
[12:04:49 CEST] <memeka> nevcairiel: i am trying to find out the bottleneck on my system when running ffmpeg (i don't have perf enabled)
[12:05:23 CEST] <memeka> hw decoding is fast - if i do -f null - => I get >100fps on 1080p video
[12:05:45 CEST] <memeka> but playing video is slow (even with opengl) => there is no zero-copy, there is a slow memcpy
[12:06:15 CEST] <nevcairiel> ffmpeg by itself is not a very optimized player
[12:06:15 CEST] <memeka> i have a faster memcpy implementation, and i would like to replace the default memcpy from ffmpeg with that implementation :)
[12:06:40 CEST] <memeka> nevcairiel: i'm using mpv; even ffmpeg with fbdev output has the same results :)
[12:06:42 CEST] <nevcairiel> you should use an actual player if you want playback
[12:06:51 CEST] <memeka> of sdl output => same results :P
[12:07:00 CEST] <memeka> yup using mpv :)
[12:07:27 CEST] <memeka> but like i said ... same results everywhere ... memcpy is slow on 1080p videos => they max out a core @ 100% 
[12:07:37 CEST] <ubitux> > faster memcpy implementation
[12:07:38 CEST] <jkqxz> Is this a mapping-uncached-memory thing?
[12:07:48 CEST] <ubitux> what kind of faster memcpy?
[12:07:56 CEST] <jkqxz> (If yes, don't do that.  Get the GPU to do the copy for you.)
[12:08:10 CEST] <memeka> ubitux: i have some NEON optimized memcpy (i on arm)
[12:08:18 CEST] <ubitux> ok, don't do that then
[12:08:23 CEST] <ubitux> that's up to your libc
[12:08:33 CEST] <nevcairiel> any decent libc will  already provide that
[12:09:03 CEST] <memeka> the imp i have is from android... anw... it's worth a try ...
[12:09:18 CEST] <memeka> so is there a place where i can replace memcpy? :)
[12:09:28 CEST] <jkqxz> LD_PRELOAD
[12:09:54 CEST] <JEEB> oh, bionic
[12:09:58 CEST] <memeka> jkqxz: it's actually got another name the function ... should i rename it to memcpy and use LD_PRELOAD?
[12:09:58 CEST] <JEEB> is it really that bad?
[12:10:10 CEST] <JEEB> I mean, for memcpy
[12:10:30 CEST] <memeka> JEEB: timed in gstreamer, decode 1080p frame = 19ms, memcpy = 24ms :)
[12:10:45 CEST] <JEEB> is that decoding or decoding+copy?
[12:10:57 CEST] <memeka> just decode = 19ms, just copy = 24ms :P
[12:11:03 CEST] <memeka> total = the sum :)
[12:11:09 CEST] <JEEB> ok
[12:11:26 CEST] <JEEB> are you using mediacodec in which mode?
[12:11:37 CEST] <JEEB> the surface or the other way?
[12:11:39 CEST] <memeka> JEEB: not mediacodec, the new v4l2
[12:11:42 CEST] <JEEB> oh
[12:11:50 CEST] <JEEB> so that stuff actually works?
[12:11:59 CEST] <memeka> yes :)
[12:12:03 CEST] <nevcairiel> apparently super slow
[12:12:14 CEST] <nevcairiel> wasnt one point of that thing to have zero-copy with all its complexity
[12:12:23 CEST] <JEEB> I think so?
[12:12:26 CEST] <memeka> nevcairiel: just decode (output to null) => 130fps on 1080p video
[12:12:43 CEST] <memeka> the rest of the stuff to output is not in v4l2 :P
[12:12:44 CEST] <JEEB> memeka: how limited is hw support btw?
[12:12:56 CEST] <JEEB> is it still just that one thing?
[12:13:07 CEST] <memeka> what do you mean?
[12:13:08 CEST] <nevcairiel> just decode is pointless to measure, as you always need to get to the image in some way
[12:13:25 CEST] <nevcairiel> and much hardware has serious issues delivering it efficiently
[12:13:49 CEST] <JEEB> memeka: IIRC the v4l hwaccel only worked with some things
[12:14:10 CEST] <JEEB> like, if I have my oneplus one, would it work? (some qualcomm with adreno)
[12:14:11 CEST] <memeka> yeah well like i said, just wanna try another memcpy :) worst case => it's as slow as libc memcpy :P
[12:14:28 CEST] <memeka> JEEB: the v4l2 stuff was done on qualcomm on linux :)
[12:14:33 CEST] <memeka> and apparently is fast :P
[12:14:48 CEST] <memeka> (probably some zero-copy available or a better output format)
[12:15:05 CEST] <memeka> i know if works on some other vendor too
[12:15:12 CEST] <memeka> and works on mine too - exynos MFC
[12:15:48 CEST] <memeka> so far only qualcomm one is fast - my exynos decoder outputs NV21/NV21 which i guess is hard to convert
[12:16:13 CEST] <memeka> there's a HW converter, but v4l2 filters have not been implemented yet :P
[12:16:16 CEST] <memeka> anw .... :)
[12:16:34 CEST] <JEEB> yea, but does it require kernel newer than X and all that jazz :P
[12:16:50 CEST] <memeka> can I do LD_PRELOAD from .o ?
[12:16:52 CEST] <JEEB> as in, is it worth trying it out with mpv-android compared to just plain old mediacodec :P
[12:19:03 CEST] <memeka> dunno android :) it was made on linux 
[12:19:17 CEST] <jkqxz> memeka:  For LD_PRELOAD you want to make a shared object (.so) containing just "memcpy" as an external symbol.  The linker should be able to make that directly from a relocatable object (.o).
[12:20:24 CEST] <jkqxz> On hardware support for V4L2, it's meant to be common.  But, like OpenMAX (which it is basically an in-kernel copy of), the implementations are all subtly different.
[12:20:59 CEST] <jkqxz> It does work on multiple so far, but I certainly wouldn't rely on it working on a random implementation without testing it pretty carefully.
[12:25:47 CEST] <JEEB> yea, mediacodec at least gets some testing on android 5+
[12:26:17 CEST] <memeka> jkqxz: thanks
[12:26:35 CEST] <memeka> so there's exactly no change :( not even sure it got memcpy from there :(
[12:26:46 CEST] <memeka> does ffmpeg implements its own?
[12:27:15 CEST] <jkqxz> No, it uses the libc one.  (Hence you can override it with ELF interposition via LD_PRELOAD.)
[12:27:40 CEST] <memeka> libavutil/mem.c 
[12:28:00 CEST] <nevcairiel> mem.c is allocation, not copy
[12:29:57 CEST] <memeka> https://www.irccloud.com/pastebin/y9vrmwaI/
[12:30:11 CEST] <memeka> this exports memcpy correctly, right?
[12:40:01 CEST] <memeka> i changed stuff in the ASM code of the function, and it works the same :) so clearly it's not using it :D
[15:32:34 CEST] <jya> BBB: ping
[15:34:49 CEST] <BBB> jya: hi!
[16:01:42 CEST] <captainmurphy>  Hi everyone! Could someone point at functions (in libav* sources) that take care of handling RTMP/RTSP input? Thank you.
[16:03:02 CEST] <jkqxz> libavformat/rt[ms]p*
[16:04:08 CEST] <captainmurphy> thnx
[16:16:10 CEST] <BtbN> Those aren't function you can use yourself though. You juse use them a normal protocol of libavformat.
[16:17:15 CEST] <JEEB> he asked that question on #ffmpeg and I just auto-answered him on how to utilize it with the API :P
[16:17:26 CEST] <JEEB> didn't even notice he was looking for the actual implementation details
[16:17:42 CEST] <JEEB> (esp. since he replied with "Great! Thanks"
[16:41:11 CEST] <durandal_1707> lol
[16:41:31 CEST] <JEEB> git is hard, let's go shopping
[16:43:41 CEST] <thardin> more like "please do our work for us"
[16:44:07 CEST] <thardin> you'll do all the work and our bosses will make all the money
[17:42:46 CEST] <yooyo3d> i think i have found very rare bug... in libavformat/mux.c in finction av_write_trailer add following
[17:42:52 CEST] <yooyo3d> s->internal->nb_interleaved_streams = 0;
[17:42:59 CEST] <yooyo3d> this prevents reusing AVFormatContext
[17:43:05 CEST] <yooyo3d> after closing file
[18:31:33 CEST] <nevcairiel> Don't think a context is meant to be reusable
[18:52:58 CEST] <yooyo3d> Im trying to make live recording (with transcoding) and I want to write A/V to file.. but after some time (like 10 min) i want to close that file and start new one, without releasing AV* stuff.
[18:53:53 CEST] <yooyo3d> regular way is to write trailes, call avio close and then start all over (alloc context, open codec, avio_open, write header, write packets...)
[18:56:43 CEST] <yooyo3d> with above change (s->internal->nb_interleaved_streams = 0;) and with some AVPacket.pts changes its possible to write_trailes, then call avio_close, then call avio_open, clean some AVStream fields write_header and start writing packets
[18:57:14 CEST] <yooyo3d> *trailer
[22:13:24 CEST] <cone-669> ffmpeg 03Daniel Kucera 07master:858db4b01fa2: libavformat: not treat 0 as EOF
[00:00:00 CEST] --- Fri Oct 20 2017