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

[burek]

[00:38:42 CET] <tmm1> jkqxz: does it make sense for me to create a new file called vf_scale_common.c? is there any convention i should be using for the name of the file or of the shared internal helper functions
[00:52:14 CET] <jkqxz> Something like that?  Looking at existing files it looks like vf_xxx is meant to contain the xxx video filter, so maybe just scale.c or scale_common.c.
[00:52:38 CET] <tmm1> ah good idea
[00:54:28 CET] <jkqxz> For function naming I would probably make them all ff_scale_* to match that.
[01:13:04 CET] <atomnuker> "Failed to open codec in avformat_find_stream_info" when trying to decode something opus
[01:13:33 CET] <atomnuker> did something break?
[01:16:22 CET] <tmm1> jkqxz: here's a first stab: https://github.com/tmm1/ffmpeg/compare/ffmpeg:master...scale-vaapi-expr.diff
[01:17:07 CET] <tmm1> not sure if the helper should create and manage var_values itself.. seems like there's some differences on what variables are exposed in the various filters
[01:18:45 CET] <tmm1> i'm passing inlink in already, so all the vars computed off that i can populate
[01:19:14 CET] <tmm1> vf_scale populates OHSUB/OVSUB too based on the outlink
[01:19:36 CET] <tmm1> so maybe just pass inlink/outlink and then i can kill var_names/var_values and the four var iw/ih identifiers
[01:43:44 CET] <tmm1> ok this works, will send patch to the list
[02:02:23 CET] <cone-796> ffmpeg 03Michael Niedermayer 07master:3782656631fa: avcodec/mjpegdec: Check for for the bitstream end in mjpeg_decode_scan_progressive_ac()
[02:02:24 CET] <cone-796> ffmpeg 03Michael Niedermayer 07master:536ac72f46b7: Revert "Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'"
[02:10:55 CET] <llogan> Compn: got a bounce message from your email host: delivery temporarily suspended: host dnvrco-pub-iedge-vip.email.rr.com refused to talk to me: 421 4.7.1 - Connection refused - <79.124.17.100> -  Too many concurrent connections ( <6> ) from source IP
[02:13:37 CET] <llogan> only getting that from you, another rr user, and a wanadoo.fr guy
[02:13:56 CET] <llogan> (for ffmpeg-devel)
[02:26:49 CET] <cone-796> ffmpeg 03Andreas Cadhalpun 07master:842e98b4d83d: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
[02:39:29 CET] <cone-796> ffmpeg 03Andreas Cadhalpun 07release/2.8:f7e18dea7ad2: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
[02:39:30 CET] <cone-796> ffmpeg 03Andreas Cadhalpun 07release/3.0:1a168061da70: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
[02:39:31 CET] <cone-796> ffmpeg 03Andreas Cadhalpun 07release/3.1:f77bb85b08de: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
[02:39:32 CET] <cone-796> ffmpeg 03Andreas Cadhalpun 07release/3.2:83269fd13b79: pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
[03:05:49 CET] <cone-796> ffmpeg 03Andreas Cadhalpun 07master:4bd5d824e927: boadec: remove log messages
[04:15:55 CET] <atomnuker> christmas really doesn't stop until its like march or something
[04:16:19 CET] <atomnuker> sent out a huge ~+2500 lines patchset to the ml
[04:45:39 CET] <Compn> yeah i havent been getting ffmpeg-devel mails :\
[04:46:33 CET] <Compn> they come every 3 days, weird stuff
[04:51:32 CET] <philipl> BtbN: You want to merge the 10bit transcode change then? I'm happy to do it.
[04:52:16 CET] <philipl> is there a version bump for adding support for pix fmts to swscale?
[04:52:55 CET] <philipl> specifically input, rather than output support.
[04:53:16 CET] <philipl> It doesn't look like it.
[04:59:09 CET] <Compn> good question for michaelni
[04:59:20 CET] <Compn> swscale version bump
[05:11:21 CET] <Compn> anyone here want to run an incoming ftp server for temporary ?
[05:11:22 CET] <Compn> ehe
[09:48:48 CET] <cone-703> ffmpeg 03Vittorio Giovara 07master:44972e227df0: ratecontrol: Move mpegenc-only function where it is used
[09:48:49 CET] <cone-703> ffmpeg 03Clément BSsch 07master:e4d65434633b: Merge commit '44972e227df0f7ad5aa9004d971fb54e9dc5c849'
[10:02:58 CET] <BtbN> philipl, yeah, will do so myself if you don't get to it by the time I get home. If you can get to it earlier, feel free.
[11:00:32 CET] <ubitux> what's up with this past duration warning all the time? :(
[11:01:28 CET] <wm4> where
[11:02:03 CET] <ubitux> x11grab to mkv
[11:02:06 CET] <ubitux> currently
[11:02:31 CET] <ubitux> might actually depend on the speed
[11:03:29 CET] <wm4> ew, vsync code
[11:40:36 CET] <wm4> we have 166 unused pixdesc entries (because of "AV_PIX_FMT_0RGB=0x123+4,")
[11:40:45 CET] <wm4> that's only ~5KB wasted space
[11:40:48 CET] <wm4> less than I thought
[11:42:58 CET] <ubitux> we can fill the gap with the space created now, can't we?
[11:43:54 CET] <wm4> yeah, most formats get appended to the end anyway
[11:44:05 CET] <ubitux> then maybe we should set 0x123 as a deprecated value
[11:44:14 CET] <ubitux> so next api/abi bump shift all of them
[11:44:26 CET] <wm4> yeah removing the "0x123+4" (why even 4?) would be a nice thing when we change ABI
[11:44:53 CET] <BtbN> why does that huge gap even exist?
[11:45:53 CET] <ubitux> abi compat with libav
[11:46:38 CET] <wm4> yes
[12:00:25 CET] <durandal_1707> ubitux: how to add custom styles from subtitle decoder?
[12:00:39 CET] <ubitux> insert ass tags
[12:00:59 CET] <ubitux> or you mean custom ass style?
[12:01:03 CET] <ubitux> in the header i guess
[12:01:08 CET] <ubitux> look at mmh microdvd maybe
[12:01:14 CET] <ubitux> i think i did that in this one
[12:01:31 CET] <ubitux> that might be only changing the default one though
[12:03:44 CET] <durandal_1707> ubitux: this ones defines multiple styles
[12:04:22 CET] <ubitux> i don't remember if the ass insert function allows to specify the style yet, i believe it doesn't
[12:05:03 CET] <ubitux> better reinsert all the style tags at the beginining of every dialog currently
[12:05:15 CET] <ubitux> and add a TODO/FIXME
[12:05:34 CET] <durandal_1707> ubitux: doing it via tags is mess
[12:06:00 CET] <ubitux> welcome to subtitles and our clumsy api
[12:06:46 CET] <ubitux> i don't know when i'll be motivated to work on subtitles again, but currently merges are a priority
[12:14:49 CET] <durandal_1707> ubitux: are you paid to do merges?
[12:15:08 CET] <ubitux> not really
[12:17:03 CET] <ubitux> ffmpeg is important for my paid job, so while i have no directive to work on the merge, from a global PoV the well being of the project is important and thus i decided it was important to work on this instead of doing more productive and fun things
[12:17:28 CET] <ubitux> i'll have to stop soon because of other priorities though
[12:19:49 CET] <ubitux> all of this is a waste of health/time/money, but i don't think we have a choice
[13:21:19 CET] <j-b> atomnuker: you're a genius
[14:11:51 CET] <ubitux> michaelni: #define avpriv_tempfile ff_tempfile
[14:11:56 CET] <ubitux> b4f59beeb
[14:12:17 CET] <ubitux> that function doesn't exist
[14:12:37 CET] <ubitux> or i'm crazy?
[14:13:22 CET] <ubitux> oh so it's actually defining a ff_tempfile() function prototype below
[14:13:55 CET] <ubitux> ...and the function avpriv_tempfile actually becomes really private everywhere else?
[14:17:30 CET] <wm4> ./libavcodec/file_open.c:1:#include "libavutil/file_open.c"
[14:17:33 CET] <wm4> welcome to hell!
[14:24:32 CET] <Compn> ehe
[14:24:50 CET] <Compn> wm4 : its not my fault videolan changed ftp and didnt notify us :P
[14:30:56 CET] <cone-703> ffmpeg 03Vittorio Giovara 07master:d639dcdae022: ratecontrol: Move Xvid-related functions to the place they are actually used
[14:30:57 CET] <cone-703> ffmpeg 03Clément BSsch 07master:566bfd59c963: Merge commit 'd639dcdae022130078c9c84b7b691c5e9694786c'
[14:41:14 CET] <Compn> carl , what do you think about getting an extra ftp server? 
[14:42:00 CET] <ubitux> mmh, so if i understand a1f6a2dfda correctly, they broke the meaningful separation of 1 pass vs 2 pass (the comments "1 Pass Code" and "2-Pass code" go away)
[14:42:22 CET] <BtbN> why do we even need a ftp server? Wouldn't an http(s) site with an upload form be more modern?
[14:42:50 CET] <ubitux> more dangerous
[14:42:58 CET] <BtbN> hm? Why?
[14:43:34 CET] <ubitux> dynamic execution on an http server is a wide attack vector
[14:44:15 CET] <BtbN> Well, ftp also isn't the most secure thing anymore. kernel.org listed that as its reason to get rid of it.
[14:44:47 CET] <ubitux> if you need upload with dynamic web, it requires a special machinery code to handle that properly
[14:44:59 CET] <ubitux> which basically means rewritting ftp server code into php/whatever
[14:45:35 CET] <ubitux> i would be way more confident with running an ftp server than an http upload form with the crazy web frameworks behind
[14:46:29 CET] <ubitux> the main problem with ftp is port filtering behind a firewall
[14:47:26 CET] <BtbN> https://www.kernel.org/shutting-down-ftp-services.html "Most software implementations have stagnated and see infrequent updates" can't deny that though
[14:47:45 CET] <BtbN> A well maintained upload web-service would be superior imo.
[14:48:01 CET] <BtbN> And not hard to set up at all. Could even do things like automatic expiry if nobody claims the file, and things like that.
[14:49:25 CET] <ubitux> afaict this ftp was used for delivery only
[14:49:32 CET] <Chloe> What's this for? 
[14:49:39 CET] <ubitux> for which http is indeed much simpler
[14:49:39 CET] <BtbN> sample upload
[14:49:46 CET] <ubitux> but if you need user upload
[14:49:54 CET] <ubitux> there is no way you're going to be more secure with http
[14:50:02 CET] <Chloe> Ah, that should be fairly simple to do.  Just don't execute the files, right? 
[14:50:20 CET] <BtbN> Yeah, and don't make them publicly available, only to registered developers.
[14:50:42 CET] <Chloe> Users would probably feel more at home using a website than ftp 
[14:50:46 CET] <cone-703> ffmpeg 03Vittorio Giovara 07master:a1f6a2dfdaf9: ratecontrol: Reorder functions to avoid forward declarations
[14:50:47 CET] <cone-703> ffmpeg 03Clément BSsch 07master:26d5caf67994: Merge commit 'a1f6a2dfdaf9beb42ca66e49d10bfaf5905a0128'
[14:51:06 CET] <BtbN> That's what I'm thinking as well. ftp is quite dated and not everyone has a client for it anymore.
[14:51:21 CET] <BtbN> (I don't, as I haven't used ftp in ages)
[14:52:19 CET] <Chloe> Wonder if it could be integrated with trac
[14:53:04 CET] <BtbN> Does trac have some kind of oauth API?
[14:56:43 CET] <Chloe> I don't think so
[14:57:46 CET] <cone-703> ffmpeg 03sumit 07master:479241da37da: ffmpeg_cuvid: add 420 10-bit transcode support for hwaccel cuvid
[15:09:12 CET] <cone-703> ffmpeg 03Matthieu Bouron 07master:209ee680ce99: mov: Fix stsc_count comparison
[15:09:13 CET] <cone-703> ffmpeg 03Clément BSsch 07master:0983e1395709: Merge commit '209ee680ce99035202520b900326a57f7fa0aceb'
[15:10:33 CET] <cone-703> ffmpeg 03erankor 07master:0101d2909550: mov: fix decryption with edit list
[15:10:34 CET] <cone-703> ffmpeg 03erankor 07master:37557b28b9f5: mov: add fate test for decryption with edit list
[15:33:05 CET] <ubitux> re 90bc423212396e96a02edc1118982ab7f7766a63
[15:33:20 CET] <ubitux> should we use index < count - 1 to prevent overflow issues?
[15:35:09 CET] <ubitux> i guess could should be pretty safe already?
[15:35:40 CET] <ubitux> index might not though
[15:37:29 CET] <ubitux> better safe than sorry, adjusted
[15:38:14 CET] <ubitux> maybe i should replace as a macro too because of signdness
[15:50:13 CET] <cone-703> ffmpeg 03Vittorio Giovara 07master:90bc42321239: mov: Wrap stsc index and count compare in a separate function
[15:50:14 CET] <cone-703> ffmpeg 03Clément BSsch 07master:e26e6240b670: Merge commit '90bc423212396e96a02edc1118982ab7f7766a63'
[15:50:39 CET] <ubitux> someone might want to have a look to this ^
[17:38:08 CET] <cone-703> ffmpeg 03Michael Niedermayer 07master:b28ae1e09bd3: avcodec/ituh263dec: Implement B frame support with UMV
[17:52:30 CET] <cone-703> ffmpeg 03Carl Eugen Hoyos 07master:aecdb14ad9a0: lavc/error_resilience: Remove two unused variables.
[19:10:02 CET] <cone-703> ffmpeg 03Michael Niedermayer 07master:e00c516d1e24: avcodec/ituh263dec: Correct indention
[19:10:03 CET] <cone-703> ffmpeg 03Michael Niedermayer 07master:901c62549441: avcodec/ituh263dec: Use correct error codes in ff_h263_decode_mb()
[19:10:04 CET] <cone-703> ffmpeg 03Michael Niedermayer 07master:4f651c723b59: avcodec/h263: Remove disabled and wrong code from ff_h263_loop_filter()
[19:23:23 CET] <cone-703> ffmpeg 03bnnm 07master:c61b28e0421f: avcodec/atrac3: Add multichannel joint stereo ATRAC3
[19:23:24 CET] <cone-703> ffmpeg 03Paul B Mahol 07master:c279c44a3aaa: avformat/msf: support codec 1, which is 16 bit pcm le
[19:36:51 CET] <cone-703> ffmpeg 03Paul B Mahol 07master:71ca855c9d61: avcodec/wmalosslessdec: remove warning message as bug is fixed
[19:37:47 CET] <Compn> bonus points
[19:37:54 CET] <Compn> since the vlc uploader is public
[19:38:03 CET] <Compn> it means we cannot accept samples via it that are market private
[19:38:06 CET] <Compn> because it is... public
[19:38:32 CET] <Compn> carl ^^ be sure to remember that , if the publically available incoming continues.
[22:01:56 CET] <cone-703> ffmpeg 03Michael Niedermayer 07master:0126cd95ccc3: avcodec/ituh263dec: Correct timestamp recovery for B frames
[22:05:42 CET] <cone-703> ffmpeg 03Lucas Sandery 07master:15d7e31dcb68: ffplay: allow borderless playback windows
[22:08:12 CET] <philipl> BtbN: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1044
[22:08:15 CET] <philipl> That seems wrong.
[22:08:20 CET] <philipl> It should 444P10 right?
[22:08:54 CET] <philipl> As it is now, 12bit content will be transformed to 444P16 and then truncated by nvenc. You presumably want swscale to dither to a 10bit format.
[22:09:42 CET] <BtbN> hm, I vaguely remember there being some reasoning behind that, but I forgot
[22:10:29 CET] <jkqxz> Isn't that an MSB/LSB packing issue?  10-bit in P010 and similar (which presumably nvenc would use) is in the MSBs, but 10-bit in the normal ffmpeg formats is in the LSBs.
[22:11:43 CET] <jkqxz> Then since all of the two-byte MSB-packed formats are interchangable by ignoring low bits, it doesn't actually matter that the format is 16 there.
[22:12:30 CET] <philipl> My point is that if you feed 12bit input (say as P016), ffmpeg will use swscale to do P016 -> YUV444P16 and then nvenc takes it as 10bit and throws the 2 bits away.
[22:12:53 CET] <philipl> If it is 444P10, then swscale will be used to do P016->P010 or P016->YUV444P10 and will dither
[22:12:59 CET] <philipl> Presumably that's more what you want?
[22:14:04 CET] <jkqxz> Does ffmpeg have an MSB-packed 10-bit YUV 4:4:4 format to use?
[22:14:32 CET] <philipl> nvenc does not support > 10bit today.
[22:15:00 CET] <philipl> It accept P010 and YUV444P10. I don't know what the packing order is.
[22:16:12 CET] <jkqxz> It would be insane if they were packed at different ends, though I admit that isn't a good reason for it not to be the case.
[22:18:54 CET] <jkqxz> My point is, if ffmpeg doesn't have support for the necessary 10-bit MSB-packed format in swscale then there is no way to get the dithering to work in one step (two steps would work: YUV444P12 --dither-> YUV444P10 --extend-> YUV444P16, say, and that still ends up with 16-bit input).
[22:21:48 CET] <philipl> My point is it doesn't want 16bit input.
[22:21:57 CET] <philipl> nvenc wants 10bit.
[22:22:12 CET] <philipl> So presumably the YUV444P12 -> dither -> YUV444P10 is all you want.
[22:22:17 CET] <philipl> You give that to nvenc and it's happy
[22:22:20 CET] <BtbN> "10 bit Planar YUV444 [Y plane followed by U and V planes]. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data."
[22:22:27 CET] <philipl> Right.
[22:22:46 CET] <philipl> On the nvenc side it's 10bit, so presumably we should pretend it is 16bit on the ffmpeg side.
[22:22:54 CET] <philipl> should not!
[22:23:00 CET] Last message repeated 1 time(s).
[22:23:59 CET] <BtbN> but wasn't the 10bit format in ffmpeg LSB, while nvenc supports MSB
[22:24:27 CET] <BtbN> or expects, rather
[22:25:18 CET] <philipl> AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV444P10BE?
[22:25:22 CET] <philipl> or is that still not right?
[22:25:45 CET] <BtbN> No, not the endianess, but where in the 16 bits per pixel the 10 bits of data are stored
[22:26:06 CET] <philipl> I get it.
[22:26:09 CET] <philipl> Anyway.
[22:26:14 CET] <philipl> My round about punchline.
[22:26:47 CET] <philipl> Today, if you pass 12bit content, it will be converted to this 444P16 format by ffmpeg and that is sent to nvenc but it is more correct to convert to P010 with dithering.
[22:26:56 CET] <philipl> The default behaviour is wrong, in other words.
[22:27:42 CET] <BtbN> you can try changing it to AV_PIX_FMT_YUV444P10
[22:27:56 CET] <philipl> I can :-)
[22:28:36 CET] <philipl> Doing so certainly makes P010 preferred for 12bit stuff.
[22:28:47 CET] <BtbN> But I'm quite sure it will do weird stuff, as ffmpeg will put the 10bit of data into the 10 LSB of the 16 bits, while ffmpeg expects them to be in the 10 MSB, which is the reason why it's a 16bit format, as it basically shifts the 10 bit into the MSB
[22:28:55 CET] <BtbN> *while nvenc expects
[22:28:57 CET] <philipl> If the LSB/MSB handling is wrong and so 444P10 is broken, then I think we need to just drop it completely
[22:29:20 CET] <philipl> or you add a separate pixfmt that allocates the bits accurately
[22:29:23 CET] <BtbN> It's not broken, it's just a diffrent pixel format, which I don't think ffmpeg currently has
[22:29:34 CET] <BtbN> Let alone how it's called
[22:31:55 CET] <JEEB> so, what would be the preferred way to do input update events?
[22:32:11 CET] <JEEB> from f.ex. a demuxer
[22:40:28 CET] <philipl> BtbN: Ok, so yes, the bitness is wrong. If you try and use the ffmpeg 444p10, you get wrong values. You also end up encoding with 4:4:4 even for 4:2:0 input.
[22:40:40 CET] <philipl> So your output file is not usefully compatible.
[22:40:45 CET] <JEEB> hmm
[22:40:55 CET] <philipl> So I'd say we either add the pix fmt or drop the format altogether.
[22:40:59 CET] <BtbN> yeah, that's about what I remembered as being the reason behind it
[22:41:10 CET] <JEEB> maybe AVPacketSideData since it's in AVPackets
[22:41:23 CET] <BtbN> I'd say we add the pix fmt(and make up a name for it)
[22:41:38 CET] <BtbN> Not having a SWS implementation shouldn't matter for now, it just won't ever be used until someone feels like doing one
[22:41:49 CET] <philipl> right.
[22:43:58 CET] <jkqxz> If you add a 'format=p010' filter then it does do the right thing, yes?  Doesn't that mean that the format selection code is the issue, and adding the format would just mean 12-bit 4:2:0 is still encoded as 10-bit 4:4:4 because ite would still be the first choice?
[22:44:47 CET] <jkqxz> Not that adding the format is bad - it would reduce confusion.
[22:48:23 CET] <philipl> No. If the format is marked as a 10bit format, then the selection code will prefer p010 as it matches the subsampling
[22:48:33 CET] <philipl> Today the 444p16 is preferred because it 'preserves' all 12 bits
[22:49:42 CET] <jkqxz> Ah, right, yes.  I was thinking it would continue to choose 4:4:4 because that throws away less information, but that's not actually a useful thing to do.
[22:53:42 CET] <BBB> atomnuker: omg a new opus encoder
[22:58:20 CET] <philipl> So is the ffmpeg yuv444p10 endianness the same as P010 endianness? and the nvenc one is weird? What is the 'normal' one? MSB or LSB? I always get so confused.
[22:58:32 CET] <BtbN> they are all little endian
[22:58:43 CET] <BtbN> it's about the position of the 10bits within the 16bit word
[22:59:12 CET] <BtbN> nvenc expects it the way P010 does it
[22:59:19 CET] <BtbN> but in ffmpeg, only P010 itself works that way
[23:01:05 CET] <philipl> I mean, which 'end' is cut off?
[23:01:55 CET] <BtbN> it's allways a 16 bit short, that's how ffmpeg places the 10 bits in it: xxxxxx1111111111
[23:01:55 CET] <philipl> With P010, the least significant bits are zeroed out, right?
[23:02:08 CET] <BtbN> yes, or undefined
[23:02:24 CET] <BtbN> 1111111111xxxxxx
[23:02:28 CET] <BtbN> and that's how nvenc expects it
[23:02:39 CET] <BtbN> so basically a <<6 on every single short
[23:02:48 CET] <philipl> Right.
[23:03:01 CET] <philipl> and the other ffmpeg formats shift the other way
[23:03:52 CET] <BtbN> the reasoning behind having it in the MSBs is that you can just throw any format at 10 bit, no matter if it'S 10, 12 or 16 bit, and it will work.
[23:04:04 CET] <philipl> Yeah, which makes sense.
[23:04:09 CET] <BtbN> Which is what nvenc does currently for it, just uses the 16 bit format
[23:04:54 CET] <philipl> I'm asking for the sake of naming, so it would be something like YUV444P10LEMSB
[23:05:17 CET] <philipl> or just YUV444P10MSB
[23:05:23 CET] <BtbN> rather P10MSB
[23:05:37 CET] <BtbN> And the LE/BE at the end and a native define
[23:05:41 CET] <BtbN> like all the other formats
[23:05:49 CET] <philipl> Yeah.
[23:07:46 CET] <philipl> michaelni: don't think I saw a reply from you yesterday. Should adding a new input format for swscale mean a version bump? History suggests no.
[23:09:04 CET] <jkqxz> Does nvenc take P10LE or P010-native, anyway?
[23:09:08 CET] <philipl> jkqxz: yes.
[23:09:30 CET] <michaelni> philipl, we didnt in the past but you can if you lik
[23:09:31 CET] <michaelni> e
[23:09:38 CET] <philipl> michaelni: ok. thanks.
[23:10:30 CET] <jkqxz> Since it runs on presumably-big-endian POWER stuff that might actually be answerable?  It was asked for VAAPI in the past, and I'm still not sure what the answer should be.
[23:14:52 CET] <BtbN> jkqxz, it only runs on x86 platforms
[23:14:56 CET] <BtbN> so no way to tell really
[23:16:21 CET] <BtbN> I'd assume it's always little endian though, as the GPU doesn't really care about the platform, and that is what will ultimately be reading the pixels
[23:17:03 CET] <jkqxz> I thought IBM liked putting nvidia stuff in big POWER machines?  Maybe that's just for compute and doesn't do video, though.
[23:29:36 CET] <cone-703> ffmpeg 03Philip Langdale 07master:4c2176d45be1: swscale: add P016 input support
[00:00:00 CET] --- Thu Feb  2 2017