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

[burek]

[00:00:02 CEST] <cone-414> ffmpeg 03Marton Balint 07master:8594a8fbf9b0: ffplay: factorize checking if a stream needs additional packets
[00:00:02 CEST] <cone-414> ffmpeg 03Marton Balint 07master:e32857f30eed: ffplay: ensure that we buffer at least 1 second of content
[00:11:23 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:3fd0694a119a: avformat/version: Change the version bumping comment
[00:11:23 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:dfbb5de172b3: tests/api/api-codec-param-test: Do not directly access caps_internal
[00:26:36 CEST] <cone-414> ffmpeg 03Thomas Mundt 07master:b577d4218385: doc/filters.texi: Move bwdif to correct alphabetical position
[00:30:54 CEST] <cone-414> ffmpeg 03Marton Balint 07master:517fe64406d4: avformat/mux: do not call write_header multiple times if it fails the first time
[00:30:55 CEST] <cone-414> ffmpeg 03Marton Balint 07master:e07b8d68f5ee: avformat/mux: do not call write_packet with a flush packet if header is not written
[00:31:21 CEST] <Illya> ubitux: sure, no problem. 
[01:28:50 CEST] <Illya> ubitux: is it possible I could get a list of the files which are being picked up as tracked files? guys at libopenmpt are interested
[06:10:32 CEST] <cone-564> ffmpeg 03Dan Dennedy 07master:b8d754c5d0a2: lavc/videotoolbox: Fix videotoolbox compile error on OS X 10.8.
[06:23:15 CEST] <j-b> 'morning
[09:44:04 CEST] Action: michaelni wonders if 6:02 isnt closer to evening than morning 
[09:46:38 CEST] <j-b> it's always morning on IRC.
[09:53:25 CEST] <mateo`> morning :)
[10:08:28 CEST] <cone-152> ffmpeg 03Matthieu Bouron 07master:432891a96e66: lavc/mediacodecdec{,_h264}: set FF_CODEC_CAP_SETS_PKT_DTS capability
[10:36:18 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:4fdea02d688c: lavc/h264: add a logging ctx to ff_h264_pred_weight_table()
[10:36:19 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:38a2d9aeec08: lavc/h264_parser: replace AVCodecContext with logging ctx in scan_mmco_reset()
[11:23:47 CEST] <ubitux> Illya: run fate, and when a test fails, run that specific test with make fate-thetest V=1 to get the sample reference
[11:24:07 CEST] <ubitux> you can also run with make -k so it doesn't stop after the first test
[12:02:08 CEST] Action: andrey_turkin feels so shameful for breaking the build
[12:05:28 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:99c554efc8b0: h264: eliminate low_delay
[12:05:29 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:7f045c4429e9: h264: merge ff_h264_free_context() into h264_decode_end()
[12:05:31 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:d98ca4b14c67: Merge commit '99c554efc8b09c3f1bb2fb41c3da5431085f7470'
[12:05:31 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:c957909a9f48: Merge commit '7f045c4429e91688f1f2335dd347203431901c06'
[12:10:15 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:0e7772c5e4f1: h264: remove unused H264SliceContext.rbsp_buffer
[12:10:16 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:cbe2dc7275bb: Merge commit '0e7772c5e4f1b31e2a3dda714ba4f89b1cca644a'
[12:25:40 CEST] <cone-152> ffmpeg 03Carl Eugen Hoyos 07master:dcdf69561fde: lavc/audiotoolboxdec: Forward extradata for QDMC and QDM2.
[12:33:10 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:56087ec0a293: h264: drop a pointless indirection
[12:33:11 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:0ab1816315b0: Merge commit '56087ec0a29314d1860f6f0e6f40fbb9b40feccd'
[12:45:40 CEST] <ubitux> dammit git forgetting to merge chunks
[12:48:55 CEST] <ubitux> ah my bad that was an error from me
[12:52:26 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:370ddc7b38d6: h264: remove H264Context.pict_type
[12:52:27 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:c8f7a23319e5: Merge commit '370ddc7b38d6b27b54fc2f5ee5f3dd9506f8c7c8'
[14:02:36 CEST] <ubitux> i need help for the merge of b77fffa127663028169c5ed543956af4b9496c29 
[14:03:11 CEST] <ubitux> in decode_nal_units() our err == SLICE_SINGLETHREAD case does more; (calling ff_h264_execute_decode_slices etc)
[14:03:26 CEST] <ubitux> i'm not sure how to merge that chunk
[14:04:07 CEST] <ubitux> should i keep the again label and call it at the end of the context_count > 0 scope?
[14:06:18 CEST] Action: Compn wonders if it would be better just to make a script to take libav-cvslog changes and send them as patches to ffmpeg-devel
[14:06:24 CEST] Action: Compn runs before anyone sees that
[14:06:49 CEST] <Compn> fuck this merge bs...
[14:07:25 CEST] <ubitux> what would be the point?
[14:07:48 CEST] <ubitux> you understand that nowadays not a single patch applies cleanly?
[14:08:20 CEST] <ubitux> there would be very little point in having unappliable patches noise on the ml 
[14:09:10 CEST] <ubitux> 200 patches to go btw
[14:09:20 CEST] <ubitux> s/patches/merge/
[14:11:29 CEST] <nevcairiel> ubitux: that ff_h264_execute_decode_slices block is also executed right after the loop, i think it could go from the error condition
[14:12:46 CEST] <nevcairiel> its only done in the error right now so that slices are all processed properly
[14:13:05 CEST] <nevcairiel> however, since we then would support parallel slice decoding in that case, that error condition is entirely not needed anymore
[14:13:09 CEST] <nevcairiel> even if we do more in it
[14:13:50 CEST] <nevcairiel> at least thats my understanding
[14:14:01 CEST] <nevcairiel> (now do we test this case in fate?)
[14:14:46 CEST] <ubitux> ok so you think i can drop the err == SLICE_SINGLETHREAD case completely?
[14:14:52 CEST] <nevcairiel> yes
[14:15:11 CEST] <nevcairiel> that error should not be emitted anymore by the function anyway
[14:15:13 CEST] <ubitux> i'll make a fate pass with THREADS and push it on my branch for more testing
[14:15:22 CEST] <nevcairiel> make sure to select only slice threads
[14:15:27 CEST] <nevcairiel> doesnt apply to frame threads
[14:15:41 CEST] <nevcairiel> THREAD_TYPE=slice i think
[14:15:45 CEST] <ubitux> ok
[14:15:49 CEST] <ubitux> it's still emitted
[14:16:22 CEST] <ubitux> i need to drop it probablyh
[14:17:02 CEST] <nevcairiel> the libav case only dealt with deblocking, maybe we check for other things?
[14:17:24 CEST] <nevcairiel> in that case the whole error block would need to stay, and just the deblocking thing not raise that error anymore
[14:18:09 CEST] <nevcairiel> hm yeah looks like we have one other check there
[14:18:23 CEST] <nevcairiel> so the err == SLICE_SINGLETHREADED block probably needs to stay for now
[14:18:31 CEST] <nevcairiel> and just the deblocking thing stop returning that error
[14:19:24 CEST] <ubitux> and so the again label stays
[14:19:35 CEST] <nevcairiel> indeed
[14:19:47 CEST] <ubitux> that 800 lines function should probably be split btw
[14:20:01 CEST] <nevcairiel> i think some parts of it are going out in further merges
[14:20:12 CEST] <nevcairiel> at least iirc
[14:25:42 CEST] <ubitux> so i can't drop single_decode_warning either
[14:25:44 CEST] <ubitux> :(
[14:26:54 CEST] <nevcairiel> unfortunately not
[14:27:13 CEST] <nevcairiel> but at least streams with that deblocking type get faster?
[14:30:05 CEST] <ubitux> no idea
[14:30:21 CEST] <ubitux> i updated my merge-libav branch if you want to test
[14:30:35 CEST] <ubitux> michaelni: test welcome again ^
[14:31:49 CEST] <ubitux> michaelni: btw, test for the ppm welcome as well :p
[14:31:57 CEST] <ubitux> pnm* even
[15:32:41 CEST] <ubitux> i'll apply the deblocking merge commit soon
[15:32:54 CEST] <michaelni> ubitux, ok, i cant find a case that fails
[15:33:07 CEST] <ubitux> cool, thanks
[15:34:57 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:b77fffa12766: h264: make slice threading work with deblocking_filter=1
[15:34:58 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:405398989093: Merge commit 'b77fffa127663028169c5ed543956af4b9496c29'
[15:36:31 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:9c858ce33fa9: h264: remove a pointless comment
[15:36:32 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:fabdb7505a7b: Merge commit '9c858ce33fa9b94ebc320dd9d9fa423e708e90cc'
[15:36:56 CEST] <ubitux> funny thing: this comment is duplicated in a header
[15:40:27 CEST] <ubitux> nevcairiel: somehow, that stuff seems to go away in e0652795292223f8bc8e5bac019c1fca7323d23c
[15:41:10 CEST] <ubitux> i'll drop all that stuff in that merge, and request testing again
[15:42:17 CEST] <cone-152> ffmpeg 03Anton Khirnov 07master:4fd34e639d15: h264: remove pointless setting of some variables in loop_filter
[15:42:18 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:0528410e0492: Merge commit '4fd34e639d15b44e02686c9b4ef58c9c3c9b0a69'
[15:42:37 CEST] <nevcairiel> you'll probably need to skip merging 2e5bde9 as we still have the single threaded fallback mode
[15:43:34 CEST] <nevcairiel> e065279 looks simple enough
[15:44:04 CEST] <cone-152> ffmpeg 03Matthieu Bouron 07master:acfab2dce6d3: lavf/mov: ignore ctts entries that do not apply to a least one sample
[16:16:59 CEST] <ubitux> nevcairiel: do you think it's true in ffmpeg?
[16:17:16 CEST] <ubitux> (the statement about the restriction)
[16:19:36 CEST] <nevcairiel> we dont use the H264_MAX_THREADS constant any more then they do, so might as well be
[16:19:56 CEST] <nevcairiel> maybe it was used to init a static array before or something
[16:21:09 CEST] <ubitux> i'll ask for testing again after this one
[16:37:07 CEST] <ubitux> anything i should test in particular for these commits?
[16:40:00 CEST] <nevcairiel> a sample with a lot of slices would probably help
[16:40:08 CEST] <nevcairiel> but i dont know where one might find one oft hose
[16:41:56 CEST] <ubitux> anyway i pushed that simple merge in my branch
[16:42:32 CEST] <ubitux> one tricky part is h->max_contexts = FFMIN(h->max_contexts, nb_slices) going away
[16:42:46 CEST] <ubitux> and the fact that i don't fully understand the consequences of such change
[16:42:49 CEST] <ubitux> and dunno what to test
[17:53:02 CEST] <jamrial> ubitux, nevcairiel: x264 should be able to encode a sample with lots of slices
[18:18:16 CEST] <cone-152> ffmpeg 03Matthieu Bouron 07master:0ea58059d635: lavc/h264_ps: add ff_h264_ps_uninit and use it
[18:30:20 CEST] <ubitux> jamrial: ok
[18:30:36 CEST] <ubitux> rkern: did you have a chance to investigate the "why?" for VT?
[18:30:51 CEST] <ubitux> like, why the NAL splitting broke VT
[18:31:08 CEST] <ubitux> i have the same issue in my app using the library
[18:31:25 CEST] <ubitux> (and unfortunately i don't have access to h264context to make a similar fix)
[18:31:34 CEST] <ubitux> so it feels like a regression somehow
[18:31:43 CEST] <nevcairiel> the "fix" makes no sense to me how it fixes it
[18:31:49 CEST] <nevcairiel> or how it ever worked before
[18:31:57 CEST] <ubitux> yeah.
[18:32:17 CEST] <ubitux> it really feels like sps and pps nal are just stripped out of the stream
[18:32:26 CEST] <ubitux> but that's just an hypothesis
[18:34:08 CEST] <rkern> I haven't figured it out yet. It might be related to the length codes.
[18:35:21 CEST] <rkern> The new way of creating the video format description takes a length code size (1, 2, or 4 bytes), but I'm not sure how to add that when it's using the non-h264 specific function.
[18:36:05 CEST] <rkern> I'll do some more digging tonight.
[18:39:39 CEST] <rkern> ubitux: I missed that... The sps and pps were there before but aren't now?
[18:40:59 CEST] <nevcairiel> that makes no sense, the full buffer before splitting is given to the hwaccel function
[19:27:59 CEST] <EvanR> screen capture from avfoundation in 3.0.2 produces a skewed and or garbled picture depends on pixel_format chosen, seems like a bug
[19:28:11 CEST] <EvanR> building ffmpeg from git to see its still broke
[19:33:54 CEST] <EvanR> yep
[19:59:31 CEST] <durandal_1707> jamrial: ping
[20:00:31 CEST] <jamrial> durandal_1707: pong
[20:01:21 CEST] <durandal_1707> jamrial: what 0xe6 as arg to pshufw does?
[20:02:26 CEST] <durandal_1707> second arg is 0x0808080808080808
[20:02:49 CEST] <durandal_1707> or 8080....
[20:03:29 CEST] <jamrial> well, in this case i think it does virtually nothing since all the words are the same
[20:05:44 CEST] <jamrial> but assuming the mmx reg is 3|2|1|0 (each one a 16 bits word), it would shuffle them into 3|2|1|3
[20:05:50 CEST] <jamrial> http://www.felixcloutier.com/x86/PSHUFW.html
[20:17:50 CEST] <cone-152> ffmpeg 03Petru Rares Sincraian 07master:bc370c8f6879: fate: add test for alimiter
[21:23:17 CEST] <cone-152> ffmpeg 03Benjamin Larsson 07master:ce028bc35064: Remove Benjamin Larsson from MAINTAINERS
[21:32:33 CEST] <cone-152> ffmpeg 03Clément BSsch 07master:d0bde818acc7: MAINTAINERS: update my entries
[21:34:51 CEST] <llogan> got bored of subtitles, eh?
[21:51:00 CEST] <ubitux> llogan: no, it's scoped by "text subtitles"
[21:51:06 CEST] <ubitux> no need to explicit files
[00:00:00 CEST] --- Tue Jun 21 2016