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

[burek]

[01:25:58 CEST] <cone-304> ffmpeg 03Marton Balint 07master:593987810ef8: avutil/parseutils: dont assume standard time when parsing a timestamp
[08:35:01 CEST] <bms20> Hi.  I'm trying to work out how to obtain an AVCodecContext* from an AVStream*, without using the deprecated codec pointer in AVStream.  Is there a way to do this in a non-deprecated form?
[08:35:37 CEST] <andrey_turkin> you don't. Instead you create new AVCodecContext and populate it from AVStream
[08:36:26 CEST] <andrey_turkin> side remark - doc/examples really ought to be updated...
[08:39:55 CEST] <bms20> Ok - I am trying to forward port code from ffmpeg 2.6; the code does not create an AVCodecContext from what I can see.  With older ffmpeg(s) were the stream's codec fields automatically populated in avformat_open_jnput?
[08:41:37 CEST] <andrey_turkin> right. Now you are not supposed to use that codec context. Instead after open_input and after find_stream_info you should create new codec contexts for streams you are interested in, and populate then via avcodec_parameters_to_context
[08:42:31 CEST] <andrey_turkin> so basically instead of getting stream->codec you just create new one using avcodec_alloc_context3 and fill it in using avcodec_parameters_to_context
[08:42:53 CEST] <bms20> Ok - that sounds very sensible.  In which case I'll hold the contexts myself.
[08:43:11 CEST] <andrey_turkin> right, and it is decoupled from format context
[08:43:26 CEST] <bms20> and use codecpar for obvious things like width/height, etc.
[08:43:32 CEST] <bms20> Sounds like a sensible decoupling.
[08:44:39 CEST] Action: andrey_turkin is waiting for someone to usher this conversation to #ffmpeg
[08:52:53 CEST] <bms20> Andrey - thanks for your help; will crash and try this tomorrow.
[10:20:58 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vKZWf
[10:20:58 CEST] <KGB> 13FFV1/06master 146c03d12 15Michael Niedermayer: remove trailing whitespaces
[10:24:26 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vKZWZ
[10:24:26 CEST] <KGB> 13FFV1/06master 145abe932 15Michael Niedermayer: Favor https URLs where the servers support them...
[12:57:02 CEST] <cone-190> ffmpeg 03Steven Liu 07master:b45a976ed4d4: add split_by_time flag for support splite mpegts segment at non-keyframe
[13:15:03 CEST] <cone-190> ffmpeg 03Michael Niedermayer 07master:37c658b56b4c: doc/muxers: Fix Thisimproves typo
[13:15:04 CEST] <cone-190> ffmpeg 03Michael Niedermayer 07master:92139c1bd190: avcodec/mediacodecdec_h264: Fix occured typo
[15:04:48 CEST] <cone-190> ffmpeg 03Michael Niedermayer 07master:9585c50942a4: avcodec/iff: remove useless ()
[15:04:49 CEST] <cone-190> ffmpeg 03Michael Niedermayer 07master:a2550e7d2e4c: avcodec/iff: Check that there are enough bytes in dgb before reading
[15:33:06 CEST] <cone-190> ffmpeg 03Matthieu Bouron 07release/3.1:1410732621dd: lavc/mediacodecdec_h264: properly convert extradata to annex-b
[16:15:40 CEST] <cone-190> ffmpeg 03Ronald S. Bultje 07master:f0a2b6249bb2: vp9: add 16x16 idct avx2 (8-bit).
[16:15:41 CEST] <cone-190> ffmpeg 03Ronald S. Bultje 07master:70d418c7e6af: Revert "PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD."
[16:52:58 CEST] <ubitux> vp9_inv_dct_dct_16x16_add_8_8 improvements are kinda impressive
[16:53:06 CEST] <ubitux> > 23x faster
[16:53:16 CEST] <ubitux> with avx2
[16:53:20 CEST] <ubitux> i like this
[16:53:27 CEST] <ubitux> much better than a 0.91x :D
[16:54:29 CEST] <nevcairiel> the C code looks phenomenally slow though, thats kind of insane improvements
[16:54:45 CEST] <BBB> maybe the c code was compiled with O0, I Dont really know
[16:54:52 CEST] <BBB> the point was more the avx vs. avx2 comparison
[16:55:03 CEST] <BBB> that should hold OK regardless of C compiler flags
[16:56:17 CEST] <ubitux> 1.5x for avx vs avx2 is nice too
[17:03:08 CEST] <BBB> yeah the avx2 speed improv is quite good
[17:03:14 CEST] <BBB> Ill try 32x32 when I find time also
[17:07:03 CEST] <BBB> if anyone feels like redoing the loopfilter, I can explain how the 2x merging in the caller (vp9.c) works, we need to change that to 4x merging to get it to work for avx2/8bit
[17:07:14 CEST] <BBB> (i.e. its not exactly trivial)
[17:39:07 CEST] <jamrial> BBB: would have been 2x if you didn't have to deal with the crosslane crap
[17:39:28 CEST] <BBB> the crosslane crap only affects the store operations though
[17:39:35 CEST] <BBB> (and the transpose of course)
[17:39:58 CEST] <jamrial> that's the speed up i saw in most avx2 functions compared to ssse3/avx where i didn't use any perm or insert/extract
[17:42:01 CEST] <jamrial> like in ME functions
[17:43:42 CEST] <jamrial> nevcairiel: would be interesting to rebench the c version now that we disabled tree vectorization
[17:46:36 CEST] <outcast> hi! is this the right place to ask for help with a C# question using ffmpeg?
[17:47:16 CEST] <BBB> outcast: no
[17:47:25 CEST] <BBB> outcast: this channel is only for development of ffmpeg, not with ffmpeg
[17:47:49 CEST] <outcast> k is there a channel for that
[17:48:11 CEST] <BBB> jamrial: interesting& I guess idct is somewhat special because as register size increases, the size of things like transpose increases accordingly which naturally dilutes the 2x optimization ideal
[17:48:33 CEST] <BBB> but the MC results are promising and its what Id expect for the horizontal loopfilter, I guess
[17:48:38 CEST] <BBB> (the ones which dont need to transpose0
[17:48:43 CEST] <RiCON> outcast: it's in the topic (#ffmpeg)
[17:49:40 CEST] <outcast> ok thanks i was over there just not found what im looking for in the documents in the topic there yet
[17:49:47 CEST] <outcast> i'll head back over there
[18:22:55 CEST] <cone-190> ffmpeg 03James Almer 07master:f60b54902f45: avformat/oggenc: make flac the default for oga muxer
[20:50:18 CEST] Action: mateo`_ working on the next libav merge
[21:01:26 CEST] <JEEB> mateo`_: did you still want that 10bit AVC sample btw?
[21:01:38 CEST] <JEEB> to see how your things revert from hwdec to swdec
[21:03:03 CEST] <mateo`_> JEEB: the decoder should properly fail at init time right now (if it was not the case before)
[21:03:12 CEST] <JEEB> oh, cool
[21:03:21 CEST] <JEEB> because before it went all the way to decoding
[21:03:39 CEST] <JEEB> I will reinstall my android development VM as I somehow borked its / :D
[21:03:58 CEST] <mateo`_> I added some profile checks in e452abc5c2441356d1aa22ffcd8a9183aa1fac33
[21:04:15 CEST] <JEEB> coolio
[21:07:45 CEST] <mateo`_> JEEB: anyway, if you still can share this sample, I'm happy to do some testing
[21:09:06 CEST] <JEEB> mateo`_: the oldest one being http://cccp-project.net/beta/test_files/H.264-10bit-sample-railgun.mkv :) (my apologies for the animated content)
[21:10:52 CEST] <JEEB> but I guess this is better than superheroes in spandex ;)
[21:10:53 CEST] <mateo`_> no worries, I tend to consume a lot of anime content
[21:13:30 CEST] <mateo`_> "any" content is fine except that bunny thing
[21:14:49 CEST] <JEEB> tell me about it...
[21:22:50 CEST] Action: mateo`_ crying watching big buck bunny for the 1000000 time
[21:23:49 CEST] <JEEB> at this point if someone asks for a sample for something I push out tears of steel
[21:23:59 CEST] <JEEB> it's a) shorter and b) less BBB
[21:24:23 CEST] <nevcairiel> dont hate on BBB, what did he ever do to you
[21:24:46 CEST] <JEEB> being overused is the only sin it did
[21:24:51 CEST] Action: JEEB 29
[21:24:54 CEST] <JEEB> welp
[21:25:12 CEST] <BBB> can we please rename that sample to something else?
[21:25:31 CEST] <BBB> like PBR (phat buck rabbit)
[21:25:41 CEST] <JEEB> :D
[21:27:20 CEST] <ubitux> and what do we do about beaglebone black?
[21:29:59 CEST] <mateo`_> make it decode PBR, and grab a hammer
[21:33:26 CEST] <mateo`_> michaelni: are there other samples than this one ffmpeg-bugs/trac/ticket3962/multiple_stsd.mp4 to test multiple stsd ?
[21:40:07 CEST] <llogan> PBR is a shitty beer.
[21:40:25 CEST] <llogan> hipster juice
[22:35:49 CEST] <michaelni> mateo`_, the samples in the fate-quickdraw and fate-gsm-toast might contain multiple stsd
[22:37:33 CEST] <mateo`_> michaelni: thanks, btw the merge (https://github.com/mbouron/FFmpeg/commit/5d3f3a421d70890eff73434b93cb55c233731bd1) passes fate and handle ffmpeg-bugs/trac/ticket3962/multiple_stsd.mp4, i'll do more testing tomorrow morning
[22:38:41 CEST] <michaelni> tickets/4400/cartest_supers.mov might also be multiple stsd
[23:14:54 CEST] <michaelni> mateo`_, the commit breaks ffmpeg-bugs/trac/ticket1918/aark15sd_9A62E2FA.mp4
[23:19:53 CEST] <michaelni> mateo`_, ./ffmpeg -i matrixbench_mpeg2.mpg -t 1 -frag_duration 200k test2.mov ; ./ffprobe test2.mov -show_packets -print_format compact
[23:19:58 CEST] <michaelni> ffprobe segfaults
[23:21:18 CEST] <michaelni> tickets//2991/wwwq_cut.mp4 fails very similar to ticket1918
[23:23:01 CEST] <cone-706> ffmpeg 03Carl Eugen Hoyos 07master:244d22452c7d: lavc/Makefile: Fix standalone compilation of the lame encoder.
[23:34:45 CEST] <llogan> Compn: i'll be gone from july 13 - august 2. could you tend to ML then? mostly from july 25-aug 2 as I not have internet/cell range then.
[23:40:18 CEST] <flux> $9
[23:40:34 CEST] <flux> (oops)
[00:00:00 CEST] --- Tue Jul 12 2016