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

[burek]

[01:37:14 CEST] <Zeranoe> I'd like to get some feedback for a new Windows builds page I've been working on: http://zeranoe.com/shared/db49jzDNjx1wKPtywhbJX5iJdsLDoTXy/builds/index.html
[02:29:35 CEST] <atomnuker> ubitux: what was it that blocked your thread names patch again?
[02:30:48 CEST] <atomnuker> (yeah, I'm starting to really wish I could see what the threads are doing)
[03:12:55 CEST] <jamrial> atomnuker: i think he ran into compilation issues in some specific scenarios and after four or so iterations he said fuck it :p
[03:14:18 CEST] <atomnuker> it sucks that every single bloody pthreads implementation needed to make a completely different function to do this
[03:14:24 CEST] <atomnuker> and each has its own damn quirks
[03:14:36 CEST] <atomnuker> honestly, how do you screw up something like that?
[03:15:22 CEST] <atomnuker> though I think only the OSX one had a very different API
[03:15:26 CEST] <jamrial> Zeranoe: wouldn't it be better to offer builds for the latest stable branch in the Recommended section, and the git master builds below that?
[03:16:52 CEST] <jamrial> atomnuker: the function apparently is (or was) not standarized, so everyone implemented it their own way. the result was this
[03:53:47 CEST] <Zeranoe> jamrial: That would depend on if stable builds are actually considered "better", which I've heard they are not.
[03:54:39 CEST] <jamrial> Zeranoe: there's a new release every three months, and point releases every few weeks
[03:55:36 CEST] <Zeranoe> Does that make them preferred?
[03:55:56 CEST] <jamrial> regressions are introduced to git master quite often, and even if they are fixed fast, if someone downloaded a snapshot from your website that happened to be in the middle of some big change or merge and never bothered to get a new one again will be stuck with that faulty build for who knows how long
[03:56:42 CEST] <jamrial> and people /will/ download a binary and stick with it until it doesn't do whatever they want to do at the time and see if they can get a newer one
[03:57:11 CEST] <jamrial> so ideally, or at least in my opinion, the recommended one should be a "stable" build
[03:57:50 CEST] <Zeranoe> I've been told before that release builds are cherry picked for patches, and aren't tested any further than a regular commit. Perhaps something has changed
[03:58:38 CEST] <jamrial> release builds get fixes backported when possible, hence the point releases
[03:59:38 CEST] <Zeranoe> I'll keep that in mind. I'd like to hear other peoples thoughts on the matter as well.
[03:59:51 CEST] <jamrial> sure, as i said it's my opinion
[04:01:37 CEST] <jamrial> you can always mention something like "for the bleeding edge/latest features, get the daily snapshots below instead" alongside a warning that they may be less stable or more buggy than the recommended one
[04:04:26 CEST] <Zeranoe> Also an option
[07:06:12 CEST] <zyme> Does anyone know a good or fairly easy transcoding video server to output to chromecast?
[07:06:45 CEST] <rcombs> [warning: corporate shilling] try Plex?
[07:07:33 CEST] <zyme> Thes ones I've run across all use ffmpeg for the transcoding, but don't have instructions on how to setup for chromecasts, even if they list in the specs chromecast compatible;
[07:08:22 CEST] <zyme> Plex requires transcoding to have the videos selected ahead of time, and is far from live.
[07:08:30 CEST] <rcombs> wat
[07:09:01 CEST] <rcombs> it'll live-convert for chromecast (or any other supported device)
[07:09:01 CEST] <zyme> At least thats how jt worked last time I used it.
[07:09:34 CEST] <rcombs> hi I'm in charge of the transcode engine at Plex
[07:13:04 CEST] <zyme> This supposedly is with the plex interface (using the ios remote) or the upnp interface? And is it included with the free version because I use to pay for it but didn't really get anything out of it that I used...
[07:17:32 CEST] <rcombs> free; the native clients
[07:17:39 CEST] <rcombs> hard to do much of anything over DLNA
[07:32:38 CEST] <zyme> And will it Taranscode any video type the PC's codecs support? Or actually I'm really only concerned with playing xvid and hevc. More so Hevc.
[07:42:36 CEST] <ubitux> atomnuker: i couldn't make the configure detect a difference between a function with 2 or 3 args iirc
[10:35:35 CEST] <rcombs> why does AV_CODEC_ID_AAC_LATM exist
[10:36:03 CEST] <rcombs> as opposed to having it as a format for AV_CODEC_ID_AAC like ASC and ADTS, which BSFs and the like can convert between
[10:37:36 CEST] <nevcairiel> iirc latm was deemed different enough to warrant a distinct codec id, so the decoder clearly knows what its getting instead of having to guess from the bitstream
[10:40:28 CEST] <nevcairiel> adts is just a header infront of a basic aac frame, latm is more complex
[10:41:26 CEST] <rcombs> it seems pretty easy to distinguish from ADTS or ASC
[10:41:30 CEST] <rcombs> given it has a syncword
[10:42:02 CEST] <nevcairiel> i'm sure you can find the discussions on the ML
[10:42:12 CEST] <rcombs> it can technically have multiple substreams iiuc but afaict nothing in lav* supports that
[10:42:54 CEST] <rcombs> maybe the LOAS demuxer should convert to ADTS
[10:44:09 CEST] <nevcairiel> thats just a raw demuxer right now, and its more commonly found in mpegts anyway
[10:44:38 CEST] <rcombs> doesn't the mpegts demuxer call into the raw demuxer?
[10:44:45 CEST] <nevcairiel> why would it do that
[10:44:54 CEST] <rcombs> it uses them for probing, at least
[10:44:57 CEST] <nevcairiel> the raw demuxer does nothing
[10:45:09 CEST] <nevcairiel> well not directly, thats all avformat utils.c magic
[10:45:13 CEST] <rcombs> I guess the parser handles packetization
[10:45:42 CEST] <rcombs> my current issues are that (1) you can't remux LATM to <something else> [or vice versa but nobody cares] and (2) it looks like it'd be awkward to fit in with my AAC-parser-on-steroids
[10:46:40 CEST] <nevcairiel> there is no reason a bsf couldnt change the codec id
[10:47:07 CEST] <nevcairiel> its just part of codecpar, and it can change codecpar
[10:47:23 CEST] <rcombs> (in which rcombs pulls a bunch of aacdec_template.c into aac_parser.c to report sampling rate and channel layout and profile, which obnoxiously requires parsing the whole damn bitstream because AAC puts that information all over the place [lol SBR] and doesn't code element lengths)
[10:47:40 CEST] <nevcairiel> sounds like something the decoder should just continue doing then
[10:47:55 CEST] <rcombs> had to build without the decoder because reasons
[12:35:33 CEST] <JEEB> rcombs: yeah that's why mkvmerge used to have a boolean for he-aac :)
[12:35:55 CEST] <JEEB> instead of "just parsing it"
[12:40:28 CEST] <roxlu> Hi
[12:41:05 CEST] <roxlu> Why does the rtp-h264 decoder only uses two STAP-A packets? (here on line 211 https://www.ffmpeg.org/doxygen/2.4/rtpdec__h264_8c_source.html ) ? 
[12:52:12 CEST] <jkqxz> roxlu:  What do you mean?  It makes two passes through the NALs in the packet: the first one to determine how big the output data needs to be, the second one to copy to the output.
[12:56:12 CEST] <roxlu> jkqxz: ah thanks I see it now
[12:57:09 CEST] <zyme> Rcombs: your right it works, Last time I checked it must have not supported the files
[13:06:17 CEST] <zyme> I think I almost had UMS working too, I had it down to only two problems, every file type ended in .ts for some reason, even thiugh and I couldn't find anything about that in any of the config files. And lastly it was transcoding to x264 3.1 instead of 4.1.
[13:07:33 CEST] <zyme> ~Even though it was really a mkv file, and configured for such  ~
[14:59:38 CEST] <KGB> [13FFV1] 15retokromer opened pull request #22: typos (06master...06patch-1) 02https://git.io/vKr8Y
[15:18:56 CEST] <ubitux> anyone to help merging 8d36932c?
[15:24:21 CEST] <ubitux> so we have ff_h264_decode_slice_header() doing { h264_slice_header_parse(); h264_field_start(); }. what the commit is supposed to do is pick all h->current_slice related chunks from h264_slice_header_parse() and move them in ff_h264_decode_slice_header() around the two h264_slice_header_parse() and h264_field_start() calls
[15:28:32 CEST] <ubitux> but this is tricky, because in our case, the init of the ps are entangled in h264_slice_header_parse()
[15:28:55 CEST] <ubitux> (see previous merge commit mostly nooped)
[15:37:29 CEST] <cone-216> ffmpeg 03Clément BSsch 07master:21c081a24651: lavc/h264: fix spacing before comment
[17:14:55 CEST] <roxlu> I'm trying to stream the Sintel video (no audio) using RTP (http://peach.themazzone.com/durian/movies/sintel-1024-surround.mp4). But the generate RTP stream cannot be handled by FFMPEG itself (or I'm using the wrong commands). 
[17:19:10 CEST] <roxlu> Oh sorry, I was wrong, I was using a wrong SDP file :#
[18:44:25 CEST] <cone-216> ffmpeg 03Michael Niedermayer 07master:64caafaeb18a: avformat: Add tee protocol
[20:17:20 CEST] <ubitux> anyone wants to help with the current h264 wave?
[20:17:32 CEST] <ubitux> because i feel like i'm going to noop it and continue the merging of the rest
[20:17:44 CEST] <ubitux> unless someone has a better idea how to deal with it
[20:20:29 CEST] <Chloe> ubitux: what happened to the commit which moved h264_init_ps() to h264_field_start()?
[20:20:50 CEST] <ubitux> mostly noop'ed
[20:20:55 CEST] <ubitux> because it was breaking things
[20:22:27 CEST] <ubitux> it looks like h264_slice_header_parse() in ffmpeg needs some work in order to be able to merge the commits from libav
[20:22:47 CEST] <ubitux> it's probably handling more corner cases, but also makes things much more complex
[20:53:04 CEST] <iive> this doesn't sound like a good thing.
[20:56:03 CEST] <ubitux> right
[20:56:07 CEST] <ubitux> who wants to help?
[21:36:30 CEST] <BBB> jamrial_: does http://pastebin.com/MW6bsxVv fix the issue?
[21:37:32 CEST] <jamrial_> BBB: yeah, it did
[21:38:04 CEST] <BBB> lemme test 32bit before I re-send it...
[21:38:06 CEST] <BBB> tnx for testing
[21:38:19 CEST] <jamrial_> i was writing a reply to tell you i thought i found what was wrong :p
[21:39:53 CEST] <BBB> anyone want to writ a mix4 vp9 loopfilter impl?
[21:39:55 CEST] <jamrial_> it was basically this unless i'm reading it wrong http://pastebin.com/JKhkz6Hd but you evidently figured it out already
[21:40:23 CEST] <BBB> yeah thats the same thing
[21:40:42 CEST] <BBB> I mean, you can sort of see that the assembly isnt the pretties tthing in the world, in that it doesnt use all the x86inc.asm magic stuff
[21:40:50 CEST] <BBB> but it works really well
[21:43:02 CEST] <BBB> I guess Ill write the mix4 myself then, should add another few % to the performance on haswell
[21:43:17 CEST] <BBB> I wish I knew of reasonable ways to make token decoding faster
[22:35:01 CEST] <michaelni> ubitux, posted a patch that moves the h264_init_ps() call point
[23:04:14 CEST] <michaelni> ubitux, does this help or was that unrelated to the next merge ?
[23:08:15 CEST] <ubitux> michaelni: that looks very helpful yes
[23:08:33 CEST] <ubitux> i wouldn't mind a longer explanation in patch 2/2
[23:09:07 CEST] <ubitux> (thanks a lot btw)
[23:09:23 CEST] <michaelni> will add a proper explanation
[23:33:05 CEST] <Chloe> ubitux: thanks for the comment about the CONST option type, it looks a lot better now
[23:34:34 CEST] <ubitux> Chloe: np; so you are josh/Ilya?
[23:34:41 CEST] <Chloe> yes
[23:35:04 CEST] <ubitux> you wouldn't be Ilya87 in the trac btw?
[23:35:16 CEST] <Chloe> No, I'm 'Illya' in trac
[23:35:35 CEST] <ubitux> alright; i got confused since i'm working on a ticket where a certain Ilya87 was active
[23:37:17 CEST] <Chloe> those are the last libopenmpt patches (for now), if they're alright then I have those and then the two others from manx to merge. (scary)
[00:00:00 CEST] --- Wed Jul 20 2016