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

[burek]

[00:02:10 CET] <cone-557> ffmpeg 03Sean McGovern 07master:7b0b5bc810cd: cmdutils: update copyright year to 2018
[00:02:12 CET] <cone-557> ffmpeg 03Mark Thompson 07master:68de778ccc35: Merge commit '7b0b5bc810cdb9ef100492c9a9f2d30602c04336'
[00:04:22 CET] <jkqxz> Next is AMF.  I'm not sure I want to disentangle all the random cosmetics from Luca here.
[00:27:17 CET] <cone-557> ffmpeg 03Michael Wootton 07master:34c113335b53: Add support for H.264 and HEVC hardware encoding for AMD GPUs based on AMF SDK
[00:27:18 CET] <cone-557> ffmpeg 03Mark Thompson 07master:3895fce26ec7: Merge commit '34c113335b53d83ed343de49741f0823aa1f8cc6'
[00:28:06 CET] <jkqxz> I really don't like how that got a different author in the two tines, but there isn't much we can do about that now.
[00:33:13 CET] <cone-557> ffmpeg 03Maxym Dmytrychenko 07master:cbe28bc069dd: qsv: better to use alignment by 16 and HEVC 10b requires alignment by 32
[00:33:14 CET] <cone-557> ffmpeg 03Mark Thompson 07master:96cf0d8a9cf3: Merge commit 'cbe28bc069dde1d53d937ee10700bb123279c7c8'
[00:35:26 CET] <jkqxz> wbs:  Should I merge the next one?
[02:14:13 CET] <TimothyGu> how good is performance of Clang compared to GCC these days
[02:17:50 CET] <atomnuker> if https://www.phoronix.com/scan.php?page=article&item=clang6-gcc8-epycznver1&num=1 is anything to go by it depends but mostly gcc is slightly faster
[02:21:06 CET] <TimothyGu> well I don't really have a 64-core ryzen so idk if that's the best benchmark to use for me...
[02:29:11 CET] <DHE> but gcc 8.0 is still a pre-release isn't it?
[02:40:12 CET] <jamrial> using znver1 is a bad idea on gcc for the time being. it's not been fully tuned since its addition, where they at first just copied bdver4 values
[02:41:07 CET] <jamrial> i remember seeing some tests where using haswell, skylake or even generic as march/mtune yielded better results
[07:55:04 CET] <wbs> jkqxz: feel free to
[14:11:19 CET] <RiCON> wm4 (?): it's disabled by default
[14:13:10 CET] <wm4> yes that's me
[14:13:15 CET] <wm4> it is?
[14:13:36 CET] <wm4>     {"http_persistent", "Use persistent HTTP connections",
[14:13:36 CET] <wm4>         OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, FLAGS },
[14:13:45 CET] <wm4> I think that means on by default
[14:14:17 CET] <wm4> http_multiple too
[14:14:27 CET] <wm4> though there are things that can disable them
[14:18:11 CET] <RiCON> oh ok, i thought 1 meant false
[14:18:29 CET] <RiCON> keep mistaking it with bash
[15:23:39 CET] <SortaCore> wait, init_output_stream() is only called after the stream has already closed?
[15:39:27 CET] <SortaCore> why am I getting a filter with libx264?
[15:39:37 CET] <wm4> ?
[15:42:53 CET] <SortaCore> ffmpeg -report -rtsp_transport tcp -i "rtsp://[censored]" -c:v libx264 -debug_ts -y "X:\h264frames\libx264rtsp.mp4"
[15:43:16 CET] <SortaCore> copy_ts posts times from a filter, but I've not specified one
[15:43:32 CET] <SortaCore> one = a filter
[15:44:09 CET] <SortaCore> is it a pts/dts fix because libx264 whines about non-monotonic otherwise?
[15:48:44 CET] <rcombs> SortaCore: it's referring to the buffer or scale filter
[15:49:07 CET] <rcombs> all ffmpeg.c transcodes go through a filter chain, even if it's effectively a no-op one
[15:51:30 CET] <SortaCore> I didn't see it for copy codec, so is that the exception?
[15:52:04 CET] <BtbN> that's not a transcode
[15:52:07 CET] <BtbN> there's nothing to filter
[15:52:39 CET] <SortaCore> derp
[15:57:05 CET] <SortaCore> I used to have PTS = DTS = framenum++; but I heard that was bad
[15:57:19 CET] <SortaCore> so now I'm basically going through all the codecs I use and trying to replicate ffmpeg.c's timing
[15:58:02 CET] <BtbN> if your timebase is setup like that, and you have no re-ordering, that's the normal way it will look like
[15:59:08 CET] <DHE> SortaCore: remember ffmpeg has to deal with all kinds of scenarios with weird inputs, formats with different requirements, etc. if you have narrow needs and known codecs/formats, that can be valid
[15:59:19 CET] <DHE> then again, usually you use a dts value provided by the encoder
[15:59:32 CET] <SortaCore> see, I'm getting it from RTSP, and I'm not sure how that works
[15:59:41 CET] <SortaCore> for all I know the frames aren't read at a regular pace
[15:59:59 CET] <SortaCore> it's from a live feed and I don't want people juddering across the screen
[16:00:30 CET] <BtbN> that sounds like a horrible source
[16:00:45 CET] <SortaCore> I think the source is fine, but I dunno
[16:00:47 CET] <BtbN> Just pass along the input timestamps and timebase, and you should be fine though
[16:00:59 CET] <SortaCore> yea, except all the codecs complain about that
[16:01:20 CET] <SortaCore> libx264 complains with every packet, and most of them complain about the first five or so
[16:01:21 CET] <BtbN> your source is indeed messing something up then
[16:02:56 CET] <DHE> if you join the stream on a non-keyframe, then yes the decoder will complain for a while until it gets its first keyframe
[16:03:39 CET] <SortaCore> I thought ffmpeg.c automatically waited for the first keyframe?
[16:04:04 CET] <SortaCore> I'm waiting in my C++ code for the keyframe, but still get the complains, but more importantly ffmpeg.c complains too
[16:06:28 CET] <SortaCore> hold on, I'll paste
[16:10:25 CET] <SortaCore> https://pastebin.com/raw/gLDH8Tyf
[16:10:42 CET] <SortaCore> whoopsies it has a login
[16:10:54 CET] <SortaCore> don't nobody pro hax that
[16:12:06 CET] <SortaCore> but yea, the first packet is timed at dts 0.95, so ffmpeg offsets everything back by -0.9, and then the first five packets have invalid time
[16:13:14 CET] <wm4> nice, this just became a free rtsp test stream!
[16:13:30 CET] <SortaCore> nuuu
[16:14:24 CET] <SortaCore> I'll get the guy to change it so you can't spy on a security office
[16:14:34 CET] <SortaCore> but whatever burns your bacon
[16:15:04 CET] <wm4> you can probably delete the paste, dunno?
[16:15:11 CET] <SortaCore> nah, I'm guest
[16:15:35 CET] <SortaCore> you need a pro pastebin account to do that
[16:16:11 CET] <SortaCore> that doesn't demonstrate the bug, actually, which is kinda dumb because I remember it happening there
[16:16:15 CET] <SortaCore> lemme try another codec
[16:17:11 CET] <SortaCore> wait, you need the scale filter for using qsv?
[16:20:00 CET] <wm4> you might?
[16:20:13 CET] <wm4> the scale filter just converts pixfmts
[16:20:29 CET] <wm4> if the qsv encoder doesn't take your input pixfmt, it has to be converted
[16:25:09 CET] <SortaCore> well, input pixel format is yuvj420p, and qsv needs either nv12 or qsv
[16:25:23 CET] <nevcairiel> well there you go, it needs converting then
[16:26:28 CET] <JEEB> (even if the data is the same, it has to be half-packed which is what nv12 is)
[16:35:17 CET] <SortaCore> *making intensifies*
[17:33:36 CET] <SortaCore> I think I was decoding with h264_qsv and then transcoding to another codec, which woulud explain the issues
[18:16:00 CET] <wm4> does anyone remember the nature of the recent windows configure slowness and whether it was fixed?
[18:36:39 CET] <atomnuker> I'd agree to switch to meson as long as we dump the configure script and I don't have to do the porting :)
[18:42:58 CET] <jamrial> wm4: win 10 falls creator seems to have an issue with process creation, which can lead to 15 min configure runs
[18:43:25 CET] <wm4> I think it's more like 20 min for me
[18:43:33 CET] <wm4> atomnuker: wasn't there a Libav POC
[18:48:22 CET] <iive> I think this was pointed as possible reason for the windows configure slowness... and it should have been addressed by MS update https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/
[18:48:53 CET] <wm4> yeah someone else also pointed this out
[18:49:04 CET] <wm4> but not sure if it's that
[19:00:06 CET] <nevcairiel> that one was fixed, so its not that =p
[19:06:37 CET] <wm4> my install might not have the update yet then
[19:07:21 CET] <jamrial> in any case, if you're developing and not making a build for distribution, a "workaround" is to disable components you're not going to use
[19:07:42 CET] <jamrial> so the dependency checks finish faster
[19:21:53 CET] <iive> well, the article also kind of show the method to investigate the issue, if you are running win10 yourself.
[20:05:09 CET] <cone-254> ffmpeg 03Jun Zhao 07master:383804edd812: lavfi/deinterlace_vaapi: fix can't show full option information.
[20:05:10 CET] <cone-254> ffmpeg 03Gyan Doshi 07master:e1e89c0695b4: avfilter/vidstab: check bytesPerPixel only for packed formats.
[20:23:37 CET] <jya> who worked on the Apple AT decoder?
[20:24:06 CET] <jya> Rodger Combs from blame.. what's his irc handle?
[20:25:20 CET] <JEEB> rcombs
[20:25:29 CET] <rcombs> oh no what did I do
[20:25:35 CET] <rcombs> is it the channel layout bug
[20:27:30 CET] Action: JEEB plays some dramatic nier: automata OST music
[20:28:25 CET] Action: rcombs plays weight of the world instead
[20:28:41 CET] <JEEB> :D
[20:29:06 CET] Action: JEEB needs to finish B,C,D,E still
[20:29:20 CET] <rcombs> woooow
[20:29:28 CET] <rcombs> and here I thought I was late getting through those
[20:29:35 CET] <JEEB> yea, I used 40h for A and then Stuff
[20:29:52 CET] <JEEB> I was kind of put off by it not warning that I had hit the final mission :<
[20:30:02 CET] <JEEB> suddenly my pass rate went down by 10% or so
[20:30:07 CET] <JEEB> in unfinished subquests
[20:30:17 CET] <rcombs> dw you can go back to them later
[20:30:30 CET] <rcombs> you get a mission select once you finish& I forget what exactly
[20:30:37 CET] <rcombs> some point in one of the later routes
[20:30:46 CET] <JEEB> yea, but I had gotten through various things like emil's challenge
[20:30:53 CET] <JEEB> and just never activated the reward
[20:30:55 CET] <JEEB> :>
[20:31:22 CET] <rcombs> I _think_ those flags stay? Not 100% sure though
[20:31:40 CET] <JEEB> at least the pass % went down
[20:31:43 CET] <JEEB> will check later
[20:32:48 CET] <rcombs> jya: well did you have a question or were you just curious who I was
[21:00:00 CET] <jamrial> https://bitbucket.org/multicoreware/x265/commits/f09f3b4a21151de001fee2bb9e0e600c7b57fa39 https://bitbucket.org/multicoreware/x265/commits/b4edf9b44d234dd2ee5c8d41ee69a1bc6aa79a20
[21:00:15 CET] <jamrial> sometimes i wonder why we ever bother to add new functions with weird suffixed names to not break the API when other projects don't seem to give half of a shit about it
[21:01:09 CET] <wm4> indeed
[21:02:09 CET] <BtbN> Because they bump their soname every few days
[21:02:30 CET] <atomnuker> ^^that, its annoying
[21:03:43 CET] <jamrial> BtbN: doens't matter, they broke API
[21:03:57 CET] <jamrial> 2.7 will not be source compatible with 2.6 without preprocessor checks for the same damned function
[21:04:01 CET] <BtbN> yeah, but that way they only annoy devs, and not users with crashes
[21:08:31 CET] <jamrial> atomnuker: not really. while x264 and x265 are admitedly overkill with their soname bumps, doing one per year or so is nice to keep the tree clean and prevent headaches that are result of several releases having to be binary compatible
[21:08:42 CET] <Chloe> wm4: what should I be using instead of pthread_once
[21:08:48 CET] <jamrial> see ffmpeg from 3.0 to 3.4
[21:10:23 CET] <wm4> Chloe: ff_thread_once
[21:11:07 CET] <wm4> Chloe: that's just #defined to the pthread ones to avoid build failure of threads are disabled
[21:11:18 CET] <Chloe> right
[21:11:20 CET] <wm4> (I have no idea why you can build ffmpeg with threads disabled)
[21:19:18 CET] <Chloe> wm4: so to summarise: 1) remove if(x) x->next = null; stuff 2) replace all pthread_once with ffmpeg NIH 3) remove RTP_NEXT api deprecation (just remove it) 4) safe-for-threads-ify lavd -> lavf bridge
[21:19:23 CET] <Chloe> right?
[21:22:22 CET] <wm4> uh probably
[21:22:50 CET] <wm4> I don't remember if that's complete, but sounds right
[21:24:41 CET] <Chloe> and yes, the decision to have the lavd and lavf lists separate with the new API is not a mistake, it will need to be supported in FFmpeg, but that's not too difficult
[21:25:36 CET] <wm4> that'd probably be an API break though
[21:25:49 CET] <wm4> so the old API still has to support it
[21:25:59 CET] <Chloe> the old api does still support it 
[21:26:10 CET] <Chloe> through the lavf callback
[21:26:10 CET] <wm4> it appears sometimes format probing also picks libavdevice demuxers
[21:27:23 CET] <Chloe> apart from registering external things, all the old APIs should behave exactly the same to a user
[21:27:33 CET] <JEEB> wm4: how the flying... :D
[21:28:00 CET] <wm4> I noticed because mpv /dev/video0 apparently uses the lavd v4l demuxer
[21:28:13 CET] <wm4> (you must have such a device file)
[21:28:49 CET] <wm4> if (av_strstart(p->filename, "/dev/video", NULL))
[21:28:53 CET] <wm4> lol
[21:31:45 CET] <JEEB> lol
[21:35:32 CET] <Chloe> wm4: so I can just remove ff_ functions? are they not public api or...?
[21:35:53 CET] <JEEB> ff_* are not public, yes
[21:35:55 CET] <JEEB> av_* are
[21:36:36 CET] <wm4> yeah, all public API starts with av
[21:36:56 CET] <wm4> (with avpriv not being public, but part of the ABI, idiotically)
[21:53:08 CET] <Chloe> I thought I was being clever by doing everything on a separate branch but now it's messed the history up. 
[21:53:29 CET] <JEEB> rip
[22:18:40 CET] <jya> rcombs: i did have a question :)
[22:19:21 CET] <jya> sorry, I got AFK , 
[22:19:31 CET] <jya> or more accurately, I was wondering  where you got your documentation. 
[22:21:01 CET] <jya> today I had a file that didn't play for me, while your decoder handled it fine
[22:23:34 CET] <rcombs> huh, surprising
[22:23:45 CET] <rcombs> jya: it's nothing secret, just apple's public docs and header files
[22:23:59 CET] <rcombs> docs at developer.apple.com, headers in the SDK
[22:25:47 CET] <BtbN> I really wonder what idiot made the HLS player on the PS4
[22:26:07 CET] <BtbN> Every time it automatically changes quality, it restarts the other qualities playlist from the top
[22:26:17 CET] <durandal_1707> jya: what file?
[22:26:21 CET] <BtbN> so it constantly jumps back like 10 seconds when it decides to change quality. Which it does a lot.
[22:26:44 CET] <BtbN> So with a bad connection, you watch in reverse...
[22:26:54 CET] <BtbN> until it can't anymore
[22:27:06 CET] <jya> and the difference was to set the magic cookie on the converter https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/audiotoolboxdec.c#L287
[22:29:11 CET] <durandal_1707> what decoder didnt worked?
[22:32:08 CET] <rcombs> "magic cookie" just means extradata
[22:32:16 CET] <nevcairiel> with some magic cookie header, apparently
[22:33:22 CET] <rcombs> nevcairiel: which is just however the extradata is formatted in MP4
[22:34:09 CET] <rcombs> so for AAC you have to convert ADTS to ASC and then wrap it in the ESDS which is fucking obnoxious and pointless
[22:34:17 CET] <rcombs> but it's not like it's just something they made up
[22:35:52 CET] <jya> rcombs: I found no documentation related to some of the stuff you do :)
[22:36:02 CET] <jya> durandal_1707: firefox one on mac
[22:37:20 CET] <rcombs> jya: I don't remember where I learned everything that goes into that, it was mostly a lot of testing and general research
[22:38:08 CET] <rcombs> a few times I did run afplay or afconvert under lldb on an input file that wasn't working, and look at which APIs it called with what data
[22:39:05 CET] <nevcairiel> i did that for something else a few years ago, so annoying to reverse engineer api usage, write proper docs ffs
[22:39:32 CET] <rcombs> there was one API that was actually straight-up broken
[22:39:48 CET] <rcombs> the function to parse an MPEG audio header
[22:39:51 CET] <rcombs> which is a 4-byte value
[22:40:04 CET] <nevcairiel> oh i remember that
[22:40:14 CET] <nevcairiel> it takes like a pointer or something instead of the value, right
[22:40:16 CET] <rcombs> the docs indicate you pass in a pointer to a char array, and a size (presumably you're supposed to point to the packet)
[22:40:39 CET] <rcombs> but looking at the disassembly, it looks like there was a stray & somewhere
[22:40:50 CET] <rcombs> which wouldn't have yielded a compiler warning, because the arg is a void*
[22:41:02 CET] <nevcairiel> so do they just not call this function anywhere, or also hack around it? =p
[22:41:05 CET] <rcombs> so instead of passing your pointer to the parser, it passed a pointer to your pointer
[22:41:40 CET] <rcombs> so it actually worked if you casted your pointer to int32_t*, dereferenced it, and casted the result to intptr_t and then to void*
[22:41:43 CET] <nevcairiel> thats what happens when the only api consumer and the api itself are basically written at the same time
[22:41:50 CET] <nevcairiel> you write it broken and noone notices
[22:41:54 CET] <rcombs> nevcairiel: as far as I can tell there is no consumer
[22:42:10 CET] <rcombs> I reported it and they said it looked fine
[22:42:24 CET] <rcombs> and I'm like "no look I have example code and can point at the exact line of assembly where it went wrong"
[22:42:39 CET] <rcombs> and then they fixed it with no release note in the next patch release
[22:44:42 CET] <jya> rcombs: ok... the one thing i had to hack around pretty bound was adding HE-AAC support for content where the SBR is inband
[22:44:52 CET] <jya> and everything look like an AAC-LC
[22:45:00 CET] <rcombs> oh yeah that's a fine mess
[22:45:13 CET] <rcombs> since you have to tell it the channel count and sample rate ahead of time
[22:45:42 CET] <rcombs> and there's no API (that I'm aware of) to find that out just with packet data
[22:45:48 CET] <rcombs> (there is at the container level)
[22:47:52 CET] <jya> rcombs: so what I did is wrap the content in an ADTS stream, I then create a FileStream on it, and feed samples. I listen to metadata callback to see if it can extract a magic cookie
[22:50:33 CET] <jya> and then I create a new decoder with the final number of channels and sampling rate
[23:05:53 CET] <rcombs> jya: yeah that works
[23:06:21 CET] <rcombs> I might do that in lavc if any of my users ever complains
[23:06:30 CET] <rcombs> patch welcome of course
[23:08:57 CET] <jya> rcombs: https://searchfox.org/mozilla-central/source/dom/media/platforms/apple/AppleATDecoder.cpp#672 the issue is that you must make the decoder creation/initialization lazy
[23:09:33 CET] <rcombs> it already is, to some extent
[23:09:34 CET] <jya> here I store the aac packet in an array until extradata got extracted or 2-3 packets are seen
[23:09:47 CET] <rcombs> see the distinction between ffat_init_decoder and ffat_create_decoder
[23:10:26 CET] <rcombs> it'd need a queue, though
[23:41:04 CET] <cone-254> ffmpeg 03James Almer 07master:1b5d3c08e3fb: avformat: small cosmetics after 6512ff72f9
[00:00:00 CET] --- Thu Jan 18 2018