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

[burek]

[00:14:46 CET] <cone-919> ffmpeg 03James Almer 07master:f6f1fc2db1b5: fate: fix fate-api dependencies
[00:53:50 CET] <cone-919> ffmpeg 03James Almer 07master:66453b1fba6c: avformat/mov: zero initialize codec_name in mov_parse_stsd_video()
[03:13:44 CET] <cone-919> ffmpeg 03Marton Balint 07master:d318e0602443: ffmpeg: add newline to avformat_write_header error message
[03:13:45 CET] <cone-919> ffmpeg 03Marton Balint 07master:e20e9b9033b7: lavf/fifo: fix undefined behaviour in deinit when destroying mutex
[03:13:46 CET] <cone-919> ffmpeg 03Marton Balint 07master:0f8b852a6428: lavfi/ebur128: specify scaling_factor directly
[10:57:07 CET] <cone-582> ffmpeg 03Nicolas George 07master:22aa649c13b4: fate/colorkey: disable audio stream.
[10:57:07 CET] <cone-582> ffmpeg 03Nicolas George 07master:183ce55b0de0: lavfi: split frame_count between input and output.
[11:38:45 CET] <cone-582> ffmpeg 03Vlad Tarca 07master:2bd83ef26acf: avformat: Add Pro-MPEG CoP #3-R2 FEC protocol
[12:00:13 CET] <durandal_1707> is  mov support broken?
[12:00:36 CET] <JEEB> there are major regressions after the crappy edit list support was added
[12:00:51 CET] <JEEB> there was a flag added that disables that so you could try it
[12:01:10 CET] <JEEB> -ignore_editlist 1
[12:01:34 CET] <JEEB> although that will not fill in any gapless data that was before
[12:08:26 CET] <durandal_1707> is someone working on fixing this?
[12:09:15 CET] <nevcairiel> if you have a particular broken case, giving a sample to the guy from google working on this might help him
[12:11:16 CET] <JEEB> I think I might just post a question on where one could stick the proper export of that data if it's now properly parsed from the files. it should be implemented on the presentation level, not in lavf only
[12:11:55 CET] <JEEB> this whole thing has just dragged for way too long and we have this crapshoot of a thing right now.
[12:12:19 CET] <JEEB> but yes, workarounds galore if you post a sample in the thread :P
[12:20:00 CET] <cone-582> ffmpeg 03Hendrik Leppkes 07master:0539ff0e1b2f: configure: use check_lib2 for cuda and cuvid
[12:27:23 CET] <JEEB> there, now I'm at least not only herping a derp on IRC
[12:39:10 CET] <cone-582> ffmpeg 03Andreas Cadhalpun 07master:7112b56a3413: vp9_mc_template: limit assert to SCALED == 0
[14:27:54 CET] <jkqxz> nevcairiel:  I don't see a way to make this work without keeping qsv_transcode_init().  The filter stuff can be hacked around easily (e.g. <http://sprunge.us/YVUd>, needed because hw_frames_ctx can't be set on the first init), but the encoder starting before the decoder does anything is just fatal to the hwcontext setup.
[14:31:01 CET] <jkqxz> (As far as I can tell, the issues are identical with cuvid.)
[15:21:04 CET] <nevcairiel> jkqxz: i'm currently messing with the cuvid stuff to keep it working, and I had to find a new place for the *_transcode_init calls, but i think it should work without the hack in the init filter method in your patch
[15:23:23 CET] <nevcairiel> at least something simple like ffmpeg -hwaccel cuvid -c:v h264_cuvid -i <file> -c:v h264_nvenc <file> still works
[15:24:33 CET] <nevcairiel> and logging shows it uses cuda pixfmt all around
[15:25:29 CET] <nevcairiel> i'll update my branch when i have rebased all the things
[15:26:35 CET] <jkqxz> Yeah, you don't need it if you have a way to set resample_pix_fmt before the first filter graph init.  I ended up with that because there is no sensible place to set it.
[15:27:27 CET] <jkqxz> That is, it made the filter graph setup work, but the whole transcode still didn't because the hardware context propagation was still broken.
[15:28:13 CET] <nevcairiel> oh you meant when you were trying t oget rid of the transcode_init calls, makes sense
[15:28:14 CET] <jkqxz> Hence the need for *_transcode_init() to hack everything together in one place, which can set resample_pix_fmt and the hardware context.
[15:28:17 CET] <jkqxz> Yes.
[15:28:35 CET] <nevcairiel> without the cleaned up init ordering thats likely going to be hard indeed
[15:29:28 CET] <jkqxz> I'm writing a new qsv_transcode_init() now to use hwcontext but otherwise work mostly as before.
[15:29:45 CET] <nevcairiel> probably going to look much like the cuvid one then
[15:30:28 CET] <BtbN> the cuvid one is pretty generic now, except for that hack to delay hwframes initialization to the cuvid decoder.
[15:31:09 CET] <BtbN> The only catch is that it has to run early enough so all the filters and stuff see the contexts as well
[15:31:50 CET] <nevcairiel> thats the trick right now
[15:32:32 CET] <jkqxz> Not necessarily, it's better off because the hardware context on the decoder isn't needed until get_format() is called.
[15:34:09 CET] <jkqxz> Though it still needs nastiness for the early filter setup, yes.
[15:40:27 CET] <nevcairiel> michaelni: i took out the merge commit that broke the sample from 1167, that one needs more work together with the one after it, might skip that for now and do those two together out-of-band
[15:40:43 CET] <nevcairiel> i pushed an updated set to my branch with cuvid transcoding remaining functional
[15:45:53 CET] <nevcairiel> an interesting side fact: i was transcoding some h264 full hd stream with cuvid/nvenc, and the aac encoding for the audio stream was slowing it down by around half
[15:47:08 CET] <nevcairiel> (on a broadwell-e i7 no less)
[15:47:30 CET] <nevcairiel> 800-900 fps -> sub 500
[15:47:38 CET] <nevcairiel> using aac_coder fast fixes it =p
[16:39:09 CET] <kierank> nevcairiel: put the aac encoding in a different thread :)
[16:39:24 CET] <nevcairiel> of course, but this is ffmpeg.c
[16:39:33 CET] <nevcairiel> my own transcoder uses threads
[16:39:57 CET] <nevcairiel> although if speed is too different,  interleaving constraints will limit it eventually either way
[16:43:07 CET] <jkqxz> nevcairiel:  <http://sprunge.us/bQSV> kindof works, but is horrible.  (Also sprunge wins at link choice.)
[16:45:02 CET] <nevcairiel> as long as it works and is contained to ffmpeg_qsv.c /me shrugs
[16:45:09 CET] <jkqxz> It also fails with default encoder settings, because they include lots of lookahead and you run out of surfaces in the decoder.
[16:45:54 CET] <nevcairiel> there was a problem in the old decoder where it preferred to buffer output surfaces instead of input data, usually blowing up the shared surface pool, but i assume thats done for now
[16:51:12 CET] <jkqxz> Default lookahead depth seems to be 40 in libmfx.  I guess it's easiest to just always give the decoder 64 surfaces for now.
[17:20:43 CET] <michaelni> nevcairiel, seems i cant find any more failures with your branch 
[17:20:56 CET] <nevcairiel> the two commits left in there mostly just move code
[17:21:03 CET] <nevcairiel> so i would hope not
[17:21:03 CET] <nevcairiel> :D
[17:21:33 CET] <nevcairiel> before i have to rebase them again i'll just take that
[17:21:59 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:ba7397baef79: avconv: factor out initializing stream parameters for encoding
[17:21:59 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:50722b4f0cbc: avconv: decouple configuring filtergraphs and setting output parameters
[17:21:59 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:ca7cdffb70c5: ffmpeg_filter: fix hwaccel transcoding
[17:21:59 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:6b449a12906c: Merge commit 'ba7397baef796ca3991fe1c921bc91054407c48b'
[17:21:59 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:198e8b8e7746: Merge commit '50722b4f0cbc5940e9e6e21d113888436cc89ff5'
[17:25:52 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:3e265ca58f05: avconv: do packet ts rescaling in write_packet()
[17:25:53 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:a3a0230a9870: avconv: init filtergraphs only after we have a frame on each input
[17:25:54 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:232399e3ee21: avconv: pass the hwaccel frames context to the decoder
[17:25:55 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:f761d4967053: Merge commit '3e265ca58f0505470186dce300ab66a6eac3978e'
[17:25:56 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:7c282d0c758d: Merge commit 'a3a0230a9870b9018dc7415ae5872784d524cfe5'
[17:25:57 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:4945343606ec: Merge commit '232399e3ee219d16d0e0d482c9f31a26202d4993'
[17:26:37 CET] <nevcairiel> jkqxz: so i assume i just dont merge anything from the avconv_qsv rework and you'll supply a patch on top of ours?
[17:29:52 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:02c2761973df: avconv_qsv: use the device creation API
[17:29:53 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:93cd6dd48859: Merge commit '02c2761973dfc886e94a60a9c7d6d30c296d5b8c'
[17:29:53 CET] <nevcairiel> (thats what i went with)
[17:29:54 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:53e116eeeb1b: doc: update merge status for recent additions and skipped merges
[17:38:13 CET] <cone-642> ffmpeg 03Clément BSsch 07master:4a081f224e12: libavcodec: fix constness in clobber test avcodec_open2() wrappers
[17:38:14 CET] <cone-642> ffmpeg 03Mark Thompson 07master:bd31c61cf94d: avconv: Remove hw_device_ctx output filter reinit hack
[17:38:15 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:db854c6c4a6c: Merge commit '4a081f224e12f4227ae966bcbdd5384f22121ecf'
[17:38:16 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:c17563c5d3c9: Merge commit 'bd31c61cf94d01dbe1051cf65874e7b2c0ac5454'
[17:39:34 CET] <cone-642> ffmpeg 03Mark Thompson 07master:8a62d2c28fba: vaapi_encode: Maintain a pool of bitstream output buffers
[17:39:35 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:724a71dced1c: Merge commit '8a62d2c28fbacd1ae20c35887a1eecba2be14371'
[17:51:48 CET] <jkqxz> Yes, sure.  (Sorry, distracted for a bit.)
[17:54:39 CET] <jkqxz> I have <http://sprunge.us/ibSI>.  Is there some merge magic I should do to make it base on 02c2761973df?
[17:55:35 CET] <jkqxz> (The diff against libav 02c2761973df is much more coherent than the diff against ffmpeg 93cd6dd48859, so I think that makes sense.)
[18:19:01 CET] <jamrial> jkqxz: you mean this http://pastebin.com/JG042ReT?
[18:30:17 CET] <jkqxz> jamrial:  Yes, that would be the other half.  It has components from both, so preserving history correctly would be nice.
[18:32:58 CET] <nevcairiel> history with merges gets kinda confusing anyway, so just make it a patch as such
[18:37:59 CET] <cone-642> ffmpeg 03Vittorio Giovara 07master:f172e22d6aed: pixdesc: Add aliases to SMPTE color properties
[18:38:00 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:2d7cf6f72ba2: Merge commit 'f172e22d6aed0bff36e975bafb0183b6779f9444'
[18:39:22 CET] <jkqxz> I'm not sure what you mean.  How would I make the patch work in that form?  (My git knowledge around this is not very good.)
[18:40:11 CET] <nevcairiel> i meant just make a normal patch
[18:40:52 CET] <jkqxz> And ignore the history.  Ok.
[18:41:14 CET] <nevcairiel> feel free to mention the commit hash its based on in the message
[18:41:30 CET] <jkqxz> Also, how do cherry-picks work wrt that?
[18:42:02 CET] <jkqxz> It doesn't get the history now?
[18:43:38 CET] <nevcairiel> cherry-picks can use hsitory to resolve conflicts if you do it properly, but they dont record any history otherwise
[18:43:57 CET] <BtbN> nevcairiel, does cuvid need some work now, or was that not the breaking set, or is it already fixed for good now?
[18:44:04 CET] <nevcairiel> should be fixed
[18:44:21 CET] <cone-642> ffmpeg 03Vittorio Giovara 07master:444a36269f85: pixdesc: Fix AVCOL_TRC_BT2020_12 name
[18:44:22 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:411ecb0be664: Merge commit '444a36269f853844369af0a9836507e5a2780323'
[18:44:29 CET] <nevcairiel> transcode works at least,  didnt try libnpp
[18:44:37 CET] <nevcairiel> cba to find out how to set that up for building
[18:44:59 CET] <BtbN> if you have cuda/cuvid set up for building, it should just work
[18:45:13 CET] <BtbN> unless you are already using the dynload patches
[18:45:18 CET] <nevcairiel> nah plain master
[18:45:23 CET] <nevcairiel> hence why i fixed configure
[18:45:26 CET] <nevcairiel> :D
[18:45:46 CET] <BtbN> libnpp does not need anything special then. It just has a runtime dep on some libraries
[18:46:17 CET] <nevcairiel> anyway i'm done merging for now, will do more tomorrow, should be mostly easy ones for a long time now, only a few avconv changes tha tdon't apply because they are fixes for the one I skipped
[18:46:55 CET] <BtbN> libnpp will also allways stay non-free
[18:47:12 CET] <BtbN> the libraries are not shipped with the driver, only with the CUDA sdk, and it expects you to ship them with your application.
[18:50:15 CET] <RiCON> what's the criteria for being non-free or free for cuvid/cuda
[18:50:31 CET] <RiCON> considering the proprietary drivers as system drivers?
[18:51:01 CET] <nevcairiel> yeah the driver is usually considered system libraries
[18:51:11 CET] <nevcairiel> if a driver wouldnt qualify, what would
[18:51:35 CET] <RiCON> even though they're proprietary and not shipped with some distros (?)
[18:51:37 CET] <BtbN> RiCON, at this point, only the CUDA SDK header.
[18:51:51 CET] <nevcairiel> RiCON: thats not required for that definition
[18:52:07 CET] <nevcairiel> windows  is proprietary, but its still a big system library
[18:52:14 CET] <RiCON> right
[18:52:22 CET] <RiCON> for windows it makes sense
[18:52:31 CET] <BtbN> I have a re-written implementation of that header, that gets rid of cuda/cuvid being non-free, leaving only libnpp as non-free.
[18:52:52 CET] <BtbN> Need to rebase that set after those changes now probably
[18:53:08 CET] <nevcairiel> i'm sure someone could construct weird arguments for not considering proprietary linux drivers as system libraries
[18:53:32 CET] <BtbN> half of ffmpeg would be non-free then
[18:53:43 CET] <BtbN> depending on the system it's running on
[18:54:31 CET] <RiCON> making the coreaudio encdecs work with windows itunes would be non-free?
[18:55:05 CET] <nevcairiel> that would probably be stretching that definition
[18:56:00 CET] <cone-642> ffmpeg 03Mark Thompson 07master:03cef34aa666: ffmpeg_qsv: Fix hwaccel transcoding
[19:19:46 CET] <cone-642> ffmpeg 03Andreas Cadhalpun 07master:25012c56448a: filmstripdec: correctly check image dimensions
[19:55:00 CET] <BtbN> nevcairiel, scale_npp also still works.
[19:55:19 CET] <nevcairiel> cool. thanks for confirming
[19:55:36 CET] <BtbN> it seems unusually slow to startup though
[19:55:49 CET] <BtbN> it reaches its usual speed after a short while though
[21:59:42 CET] <cone-642> ffmpeg 03Mark Thompson 07master:a8d51bb42474: hwcontext_vaapi: Add driver quirks to the hwdevice
[21:59:43 CET] <cone-642> ffmpeg 03Mark Thompson 07master:2dee500f4cbf: vaapi_encode: Respect driver quirks around buffer destruction
[21:59:44 CET] <cone-642> ffmpeg 03Mark Thompson 07master:1a359e53418f: vf_scale_vaapi: Respect driver quirks around buffer destruction
[21:59:45 CET] <cone-642> ffmpeg 03Mark Thompson 07master:8d47d8407569: hwcontext_vaapi: Try the first render node as the default DRM device
[21:59:46 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:775a8477b74b: hwcontext_vaapi: add a quirk for the missing MemoryType attribute
[22:03:54 CET] <jkqxz> ^ The fourth patch there makes QSV work sensibly on Linux by default without running X.  The last one is needed for QSV hwcontext to work properly with a VAAPI subdevice.  The first three make the last one sensible to merge.
[22:08:02 CET] <nevcairiel> qsv uses vaapi hwcontext?
[22:09:39 CET] <jkqxz> On Linux, yes.
[22:09:51 CET] <nevcairiel> dont we have a qsv hwcontext
[22:10:04 CET] <nevcairiel> or is that some sort of nested deal
[22:10:21 CET] <jkqxz> It does allocation and the device management.  Direct3D is used for the same purpose on Windows.
[22:10:25 CET] <jkqxz> It's nested, yes.
[22:32:14 CET] <cone-642> ffmpeg 03Vittorio Giovara 07master:7a745f014f52: options_table: Add aliases for color properties
[22:32:15 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:bd0db4a32d85: Merge commit '7a745f014f528d1001394ae4d2f4ed1a20bf7fa2'
[22:34:45 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:d2e56cf753a6: avconv: move flushing the queued frames to configure_filtergraph()
[22:34:46 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:94ebf5565849: avconv: restructure sending EOF to filters
[22:34:47 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:07dcef9bc7a6: Merge commit 'd2e56cf753a6c462041dee897d9d0c90f349988c'
[22:34:48 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:cd47bd835a1f: Merge commit '94ebf5565849e4dc036d2ca43979571ed3736457'
[22:34:49 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:e3d9bd7102be: doc/libav-merge: add skipped fixup commits to the list of missing changes
[22:37:19 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:5fcae3b3f93f: hwcontext: clarify the behaviour of transfer_data() for cropped frames
[22:37:20 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:fdfe01365d57: hwcontext: allocate the destination frame for the pool size
[22:37:21 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:c3f113d58488: vf_hwdownload: allocate the destination frame for the pool size
[22:37:22 CET] <cone-642> ffmpeg 03Mark Thompson 07master:f62bb216ac4c: hwcontext_vaapi: allow transfers to/from any size of sw frame
[22:37:23 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:72c38dd66e52: Merge commit '5fcae3b3f93fd02b3d1e009b9d9b17410fca9498'
[22:37:24 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:7071924cf230: Merge commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8'
[22:37:25 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:1f8e1c209db2: Merge commit 'c3f113d58488df7594a489bdbb993a69ad47063c'
[22:37:26 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:3aa7b0a27326: Merge commit 'f62bb216ac4cfbbff16108c6bac35a0282532972'
[22:38:59 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:c67594a2c7fd: qsvdec_hevc: fix a variable name
[22:39:00 CET] <cone-642> ffmpeg 03Anton Khirnov 07master:eccfb9778ae9: qsvdec_hevc: add the UID of the HEVC HW decoder plugin
[22:39:02 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:a478ae39388b: Merge commit 'c67594a2c7fd4381e6d44246b18487c7e6b75f02'
[22:39:03 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:fb40daa7f3b8: Merge commit 'eccfb9778ae939764d17457f34338d140832d9e1'
[22:58:00 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:785c25443b56: movenc: Apply offsets on timestamps when peeking into interleaving queues
[22:58:01 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:8fad4b4e251b: Merge commit '785c25443b56adb6dbbb78d68cccbd9bd4a42e05'
[22:59:55 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:82b7525173f2: Add an OpenH264 decoder wrapper
[22:59:56 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:b2554e61e0ba: Merge commit '82b7525173f20702a8cbc26ebedbf4b69b8fecec'
[23:00:23 CET] <nevcairiel> so many noops
[23:00:26 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:e57de6faa1e7: checkasm: h264dsp: Initialize the padding area
[23:00:27 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:af8b174711f3: Merge commit 'e57de6faa1e796099091c9af947d4755edacccaf'
[23:02:47 CET] <cone-642> ffmpeg 03Martin Storsjö 07master:e48746deec48: checkasm: h264dsp: Move the x and y variables into the randomize_buffer macro
[23:02:48 CET] <cone-642> ffmpeg 03Hendrik Leppkes 07master:f75035b06f4b: Merge commit 'e48746deec48e9ff195841bc3266b4e153a878cd'
[23:23:29 CET] <nevcairiel> jamrial_: why do i foresee a big argument why extra indirections are so bad that we will never get rid of the private-public fields :d
[23:27:53 CET] <jamrial_> nevcairiel: heh
[23:39:49 CET] <jya> anyone know of a source for h264 4k 60fps videos?
[23:41:15 CET] <nevcairiel> i have a couple 50 fps
[23:41:48 CET] <nevcairiel> and one 120
[23:41:49 CET] <nevcairiel> :D
[23:43:53 CET] <DHE> there's always the Big Buck Bunny videos. 4k 60fps (according to the download page)
[23:45:20 CET] <nevcairiel> oh right they released a high frame rate render
[23:45:40 CET] <jamrial_> testsrc2 + x264 :p
[23:45:47 CET] <nevcairiel> that works too
[00:00:00 CET] --- Mon Nov 14 2016