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

[burek]

[01:57:34 CET] <cone-709> ffmpeg 03James Almer 07master:d36335bda5e5: avcodec/parser: use a mutex instead of atomics in av_register_codec_parser()
[03:32:01 CET] <SortaCore> huh
[03:32:13 CET] <SortaCore> I accidentally suspended a bunch of chrome processes and I stayed connected
[03:36:27 CET] <cone-709> ffmpeg 03Marc-Antoine Arnaud 07master:206b25f9f45a: avfilter: reorder variable definition in geq
[03:36:28 CET] <cone-709> ffmpeg 03Marc-Antoine Arnaud 07master:ac6b0bba79fe: avfilter: slice processing for geq
[03:36:29 CET] <cone-709> ffmpeg 03Marc-Antoine Arnaud 07master:e425047a47b6: avfilter: rename variables in geq
[03:36:30 CET] <cone-709> ffmpeg 03Michael Niedermayer 07master:b2be76c0a472: avcodec/dnxhddec: Check dc vlc
[11:49:27 CET] <JEEB> mistym: yea, but you still need to parse the packets to get the header positions :D
[11:49:54 CET] <JEEB> so in theory the decoder post-parser would be the thing to do it
[11:50:24 CET] <JEEB> but as I noted I got no replies regarding how to do multiple decoder modes
[11:50:26 CET] <JEEB> .17
[12:18:53 CET] <wm4> I didn't need to know that avi supports annexb h264 too
[13:39:30 CET] <JEEB> wm4: people stick everything into avi
[13:39:37 CET] <JEEB> ubfortunately
[13:39:57 CET] <wm4> yeah
[13:40:10 CET] <wm4> how does h264 with bframes work at all?
[13:45:35 CET] <nevcairiel> it doesnt, you get wront  timestamps
[13:45:39 CET] <nevcairiel> wrong*
[13:47:54 CET] <wm4> aw
[13:48:48 CET] <nevcairiel> you basically only get dts timestamps
[13:50:24 CET] <wm4> not really, DTS have this weird delay, so it doesn't quite work
[16:01:08 CET] <BtbN> kierank, uhm, why did you send a PullRequest on Github? It can't be merged.
[16:01:30 CET] <kierank> wanted to see what happens if I press the button saying "Create a code of conduct"
[16:01:36 CET] <kierank> and that's apparently what it does
[16:01:52 CET] <BtbN> So that's a default CoC Github gives you?
[16:02:05 CET] <kierank> it gives you options between large project and small project
[16:04:46 CET] <wm4> lol
[16:05:22 CET] <wm4> so it's a template
[16:05:38 CET] <wm4> and github has a button to make it easy to copy it into every project?
[16:05:40 CET] <wm4> that seems dumb
[16:26:02 CET] <kierank> wm4: it has a button to apply a code of conduct to a project yes
[16:26:25 CET] <durandal_1707> nack , missing contact info
[16:26:30 CET] <kierank> a million times better than the CoC we have now that's so bad i wouldn't use it for toilet paper
[16:27:06 CET] <wm4> the problem is less with the CoC and more with enforcing it
[16:27:20 CET] <durandal_1707> free speech  against mplayer devs
[16:27:40 CET] <kierank> wm4: well a good CoC has this in it
[16:28:30 CET] <atomnuker> its all toilet paper
[16:29:05 CET] <atomnuker> empty words that are useless at solving anything, used by weak people losing an argument
[16:29:13 CET] <durandal_1707> paper is useful
[16:29:38 CET] <wm4> yeah atomnuker would rather start an edit war
[16:31:03 CET] <atomnuker> as long as its left as-is without any muting or banning it'll solve itself out by the people waging it
[16:31:36 CET] <atomnuker> self-regulation may not work for markets but I'm confident it'll work elsewhere
[16:32:16 CET] <atomnuker> particularly in systems that were created by self-regulation, like open source
[16:33:52 CET] <wm4> you mean the hotter you flame the more likely you're to win
[16:34:00 CET] <wm4> that seems indeed how it works currently
[16:34:33 CET] <wm4> solving conflict by creating more conflict
[16:34:34 CET] <wm4> genious
[16:39:21 CET] <atomnuker> well its better than a coc which just says "mob the first who throws a bad word"
[16:41:39 CET] <atomnuker> sure it solves the problem but there's no guarantee the solution it made was the best solution
[16:42:13 CET] <kierank> atomnuker: you weren't there in like 2010 and before when it was conflict every day
[16:42:21 CET] <kierank> gotta learn from the past
[16:42:31 CET] Action: kierank regrettably mentions the past
[16:59:41 CET] <jamrial> anyone want to look at the mutex patches so we may finally nuke the lavu atomic stuff?
[17:04:39 CET] <wm4> I just "reviewed" the 3 v2 patches
[17:07:26 CET] <atomnuker> durandal_1707: are the only issues with yuvj in ffplay and mjpegdec?
[17:07:30 CET] <cone-560> ffmpeg 03Paul B Mahol 07master:7bb1be9af0ea: avfilter: add arbitrary audio IIR filter
[17:08:37 CET] <wm4> I think it sort of broke down on libavfilter?
[17:09:18 CET] <durandal_1707> atomnuker: anywhere where michaelni points out something
[17:09:46 CET] <atomnuker> well that leaves 2 issues then
[17:09:53 CET] <atomnuker> "warning: passing argument 1 of ff_make_color_range_list from incompatible pointer type [enabled by default]" in the lavfi part of the patchset
[17:10:00 CET] <atomnuker> (which is easily fixable)
[17:10:37 CET] <durandal_1707> ffplay issue can be fixed by rming ffplay
[17:10:39 CET] <atomnuker> and the "[mjpeg @ 0x334dea0] colorspace not supported in jpeg" error in mjeg encoding
[17:10:59 CET] <durandal_1707> iirc i fixed that one
[17:11:12 CET] <durandal_1707> locally
[17:11:36 CET] <atomnuker> oh, ok, that leaves just the warning
[17:12:02 CET] <atomnuker> resubmit them and I'll lgtm
[17:13:00 CET] <atomnuker> ubitux: did you manage to finish the subtitles in avframe stuff?
[17:13:02 CET] <durandal_1707> need docs changes
[17:13:43 CET] <ubitux> atomnuker: no& :(
[17:13:51 CET] <ubitux> fuck me
[17:13:51 CET] <atomnuker> got blocked somewhere?
[17:14:04 CET] <ubitux> i have no decent excuse
[17:14:12 CET] <ubitux> i'm sorry
[17:14:30 CET] <jamrial> ubitux: christmas/new years is a good reason
[17:14:51 CET] <ubitux> would be relevant if i was a social person
[17:15:03 CET] <jamrial> not even family? :o
[17:15:22 CET] <ubitux> nope, haven't seen them for a long time
[17:15:31 CET] <jamrial> ah
[17:18:52 CET] <cone-560> ffmpeg 03James Almer 07master:9ed4ebc530dd: avcodec/util: use a mutex instead of atomics in avcodec_register()
[17:18:53 CET] <cone-560> ffmpeg 03James Almer 07master:57960b1f2800: avformat: use mutexes instead of atomics in av_register_{input,output}_format()
[17:18:54 CET] <cone-560> ffmpeg 03James Almer 07master:167e659b289f: avfilter: use a mutex instead of atomics in avfilter_register()
[17:19:39 CET] <jamrial> now, lets get rid of lavu atomics
[17:25:04 CET] <atomnuker> ubitux: well if you think we're close we could probably postpone the bump some time for you to finish it
[17:25:33 CET] <ubitux> no, bump for now
[17:25:34 CET] <ubitux> it's fine
[17:27:20 CET] <jamrial> you mean postpone closing the unstable abi season?
[17:29:55 CET] <wm4> Chloe: time to learn how to resolve conflicts with git rebase
[17:31:10 CET] <Chloe> shouldnt be too bad with `git pull -r` and 3 way merges
[17:35:23 CET] <ubitux> jamrial: no, don't postpone
[17:35:26 CET] <atomnuker> jamrial: yeah, I was hoping to have subs in avframe in but its fine, as long as yuvj and the avpriv atomic stuff is in
[17:36:21 CET] <jamrial> does that need to be done while the abi is unstable? sizeof(avframe) is not part of it
[17:36:49 CET] <atomnuker> doesn't it deprecate avsubtitles?
[17:37:46 CET] <rcombs> mmmmm, subs in avframe
[17:46:21 CET] <atomnuker> ubitux: if you want can you push some wip somewhere if someone wants to finish it?
[18:07:15 CET] <cone-560> ffmpeg 03James Almer 07master:dcbf034a0fd2: avcodec/error_resilience: remove unused header
[18:07:16 CET] <cone-560> ffmpeg 03Anton Khirnov 07master:89b84cb18b54: It has been replaced by C11 stdatomic.h and is now unused.
[18:07:33 CET] <jamrial> way to fuck up the commit subject...
[18:07:34 CET] <BBB> is there a title missing in that commit?
[18:08:12 CET] <jamrial> yes
[18:08:17 CET] <jamrial> the actual commit subject
[18:08:40 CET] <jamrial> i fucked up and removed it, leaving only the second line
[18:08:49 CET] <BBB> it happens, its ok
[18:09:09 CET] <jamrial> at least the reference to the original commit is there in the cherry-pick line
[18:21:44 CET] <durandal_1707> i want float128 type
[18:22:32 CET] <atomnuker> is 80 bit precision not enough?
[18:22:48 CET] <rcombs> float256 or go home
[18:22:56 CET] <SortaCore> float4096 when
[18:23:02 CET] <SortaCore> https://pastebin.com/raw/Ytcivhm0 r8 my patch bois
[18:23:05 CET] <kierank> durandal_1707: long double
[18:23:21 CET] <rcombs> loooooong double
[18:23:30 CET] <SortaCore> long long double
[18:24:09 CET] <rcombs> #define loooooong long long
[18:24:28 CET] Action: SortaCore thumbs up
[18:25:02 CET] <BBB> kierank: long double is 80 bits no?
[18:25:17 CET] <wm4> which compiler dev thought "this is a good idea"
[18:25:41 CET] <BBB> wm4: the one thats running for president in the next election cycle
[18:25:58 CET] <atomnuker> only on gcc with default settings
[18:26:05 CET] <atomnuker> long double is 64 bits on msvc
[18:26:22 CET] <atomnuker> I think you needed some special flag to enable it there
[18:28:41 CET] <rcombs> x87's not even present on e.g. quarks
[18:29:45 CET] <wm4> BBB: did I miss anything?
[18:30:11 CET] <SortaCore> no r8ing?
[18:30:13 CET] <BBB> ignore it, it was a poor attempt at a joke
[18:31:02 CET] <BBB> SortaCore: for broader review, Id send patches to the list; with just a link, we dont know what its about or whether we should look at it
[18:31:24 CET] <BBB> SortaCore: it could be a patch to any part of the codebase, likely one I know nothing about, so I dont click
[18:31:24 CET] <atomnuker> yeah, most of the people who care about qsv are on the list
[18:32:23 CET] <jkqxz> There are people who care about qsv?
[18:32:56 CET] <BBB> someone just wrote a patch for it :-p
[18:33:00 CET] <jamrial> people with intel notebooks maybe
[18:33:10 CET] <jkqxz> Wrt that patch, Am I missing something about why you don't just provide a device with only a hardware implementation?
[18:34:09 CET] <jkqxz> The internal initialisation is only there so that some simple cases are easier.
[18:36:34 CET] <SortaCore> atm there's one setting: select any implementation, software or hardware
[18:36:57 CET] <SortaCore> qsv software is probably worse than not using qsv at all
[18:37:13 CET] <SortaCore> so I added an option for requiring a hardware impl
[18:37:59 CET] <jkqxz> Why would you ever use the internally-made session, though?  The implementation is attached to the device context, you pass the type you want when you create that.
[18:40:20 CET] <SortaCore> *whoosh*
[18:42:25 CET] <jkqxz> ... -c:v h264_qsv -hwaccel qsv -hwaccel_device hw_any -i blahblah ...
[18:42:47 CET] <SortaCore> how do you do it in C++?
[18:43:10 CET] <jkqxz> Set hw_frames_ctx or hw_device_ctx.
[18:43:23 CET] <jkqxz> s/hw/AVCodecContext.&/g
[18:44:09 CET] <jkqxz> (The former for hardware frame output, the latter for software.  An Intel guy recently wanted to add the latter for hardware too, dunno if that will actually happen.)
[18:44:16 CET] <jkqxz> Are you using AV_PIX_FMT_QSV or not?
[18:44:34 CET] <SortaCore> I'm not currently, I was getting errors from sws_scale saying it wasn't compatible
[18:45:19 CET] <SortaCore> atm I get an RTSP stream in, YUV420P output, I convert to NV12 (and other formats), pass to QSV, read back into a MP4
[18:45:30 CET] <SortaCore> other formats being RGB for display and so forth
[18:46:34 CET] <jkqxz> Make a device reference with av_hwdevice_ctx_create(&device_ref, AV_HWDEVICE_TYPE_QSV, "hw_any", NULL, 0), then put it as AVCodecContext.hw_device_ctx on all of you encoders and decoders.
[18:47:11 CET] <jkqxz> I assume you are on Windows there, because on Linux the multiple devices without explicit handling is really broken.
[18:47:23 CET] <SortaCore> yea, Windoze
[18:47:50 CET] <SortaCore> atm I was creating a device, but for dxva2
[18:48:31 CET] <jkqxz> If you have a dxva2 device you can derive the matching qsv device from it using av_hwdevice_ctx_create_derived().
[18:49:22 CET] <SortaCore> atm I have neither for source, because it's RTSP
[18:49:42 CET] <SortaCore> so should I go dxva2 + derived qsv or just qsv
[18:50:47 CET] <durandal_1707> atomnuker: with very long filtergraph you can do multiband compression with native filtering
[18:51:10 CET] <durandal_1707> ignoring mcompand
[18:51:28 CET] <jdarnley> > [Fri 05 18:24] <rcombs> #define loooooong long long
[18:51:34 CET] <jdarnley> I need to use that comewhere
[18:51:38 CET] <jdarnley> *somewhere
[18:51:43 CET] <durandal_1707> because it have issues..
[19:00:16 CET] <jkqxz> SortaCore:  Use dxva2 for decode and derive the matching qsv device for encode.
[19:14:56 CET] <rcombs> long long double
[19:17:53 CET] <wm4> and for int128_t, long long long
[19:17:57 CET] <wm4> ...int
[19:18:07 CET] <wm4> unsigned long long long int
[19:18:36 CET] <wm4> oh I thought "long int" is legal but it's not
[19:18:57 CET] <wm4> I'm very confused
[19:19:20 CET] <jamrial> now that we have to trash every CPU made in the past two decades, some of these might actually become useful
[19:29:30 CET] <SortaCore> so probably not the best time to sell my old i5
[19:30:15 CET] <SortaCore> @jkqxz: alright, so create a dxva2, pass it with av_buffer_ref as hw_device_ctx to decoder, then create derived qsv and pass that to the qsv encoder?
[19:35:58 CET] <jkqxz> Yes.
[19:58:47 CET] <cone-560> ffmpeg 03Paul B Mahol 07master:52c959a23766: avfilter/af_aiir: do not crash with invalid options
[20:13:08 CET] <LongChair> hmmm could anyone confirme something for me regarding ML ? 
[20:13:34 CET] <LongChair> i just submitted some fixes for rockchip rkmpp, and attached two patches
[20:13:59 CET] <LongChair> the ML mail seems to contain both, but i can only see one in here https://patchwork.ffmpeg.org/patch/7146/
[20:14:13 CET] <LongChair> did i screw up something ? 
[20:15:06 CET] <jamrial> maybe it's stuck in moderation queue
[20:15:13 CET] <jamrial> Compn: ^
[20:15:44 CET] <wm4> seems to be more about patchwork reading only the first attached patch
[20:16:59 CET] <LongChair> Should I resubmit it in two mails ? or is the ML one good enough  ? :)
[20:20:04 CET] <wm4> good enough for me
[20:20:26 CET] <wm4> though separate mails or even using git send-email would make reviewing easier
[20:28:20 CET] <durandal_1707> i figured how to do linear phase crossover with iir filters and 4th order linkwitz-riley
[20:47:40 CET] <cone-560> ffmpeg 03James Almer 07master:b9ad04b19c0c: fate: add PERSIST_RPARAM_A_RExt_Sony_3 hevc conformance test
[21:10:18 CET] <SortaCore> do I have to use av_buffer_ref for both jkqxz?
[21:48:57 CET] <Compn> wat\
[21:53:01 CET] <Compn> jamrial : nothing stuck in mod queue atm
[21:53:15 CET] <Compn> that was 2 hours ago, possibly lou or someone else cleared it
[21:53:19 CET] <Compn> or it never made it to us:\
[21:53:39 CET] <jamrial> Compn: yeah, my bad. i misunderstood what he said and assumed he sent two mails, where only one made it through
[21:53:47 CET] <jamrial> when he had sent one with two attachments
[21:54:28 CET] <Compn> no prob
[21:54:51 CET] <Compn> just letting you know the results of me checking. i can check anytime, and feel free to ask me to check it :)
[22:11:36 CET] <jamrial> wm4: regarding the encryption stuff, i don't really like having those two functions using avpacket in lavu
[22:12:36 CET] <jamrial> both are something that should be done by the muxer/demuxer itself, like with every other side data type
[22:35:16 CET] <wm4> jamrial: the data is relatively complex, so the idea was to make the exact representation internal, and to have the user access it through the new functions
[22:35:24 CET] <wm4> I guess they could be in libavcodec as well
[22:35:57 CET] <wm4> what we really want is probably not having side data be a flat byte array
[22:36:22 CET] <wm4> but currently the general side data API pretty much guarantee that you can
[22:38:26 CET] <jamrial> what makes it complex is that subsamples field, yeah
[22:41:19 CET] <jamrial> how about making the functions one take a byte array passed by the caller (who got it with av_packet_get_side_data) to fill the AVEncryptionInfo struct, and the other allocate a byte array that the caller then needs to add as side data with av_packet_add_side_data?
[22:50:36 CET] <wm4> jamrial: I guess that wouldn't be too bad if you see an advantage in this
[22:52:11 CET] <jamrial> not having lavu use lavc structs is worth it
[22:56:24 CET] <wm4> oh right, if it's going to be in lavi it actually can't or shouldn't use AVPacket at all
[00:00:00 CET] --- Sat Jan  6 2018