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

[burek]

[01:14:57 CEST] <HSKW> hello ffmpeg... i've a problem to transcode this stream: Stream #0:0[0x200]: Video: h264 (High 4:2:2) ([27][0][0][0] / 0x001B), yuv422p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 
[01:14:57 CEST] <HSKW> tbc
[01:16:55 CEST] <llogan> wrong channel. #ffmpeg-user is for user help.
[01:17:40 CEST] <nevcairiel> its just #ffmpeg isnt it
[01:18:47 CEST] <HSKW> nevcairiel: ok thans.. but seems as a bug :( sorry
[01:19:41 CEST] <nevcairiel> unless you have a patch to fix the bug, it should still be reported in #ffmpeg or on our Trac bug tracker
[01:20:44 CEST] <llogan> nevcairiel: yes. early onset dementia.
[01:21:57 CEST] <HSKW> http://pastebin.com/BihJaLG4
[02:14:41 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:86fec7a7e861: doc/APIchanges: document the lavu/lavf field moves
[02:40:26 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07release/3.1:5c695ce90386: doc/APIchanges: document the lavu/lavf field moves
[02:40:27 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07release/3.1:fc25481d17be: Update for 3.1.1
[02:45:58 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:2a8dadb38f6b: doc/APIchanges: fill in missing git hash
[02:46:00 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07release/3.1:ce36e74e7575: doc/APIchanges: fill in missing git hash
[03:27:31 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07n3.1.1:HEAD: doc/APIchanges: fill in missing git hash
[05:05:47 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07release/3.0:96f5019bde0f: avcodec/libopenjpegenc: Set numresolutions by default to a value that is not too large
[13:43:57 CEST] <ubitux> michaelni: can i have testing for my merge-libav branch?
[13:44:13 CEST] <ubitux> it's just a single merge commit
[14:10:44 CEST] <michaelni> ubitux, seems working fine
[14:10:51 CEST] <ubitux> cool, thanks
[14:11:49 CEST] <cone-209> ffmpeg 03Anton Khirnov 07master:3fba16ecd978: h264: factor starting a new field out of parsing the slice header
[14:11:50 CEST] <cone-209> ffmpeg 03Clément BSsch 07master:99b37f53a13d: Merge commit '3fba16ecd978d5bed338b8da643c3435e62b3437'
[14:21:10 CEST] <cone-209> ffmpeg 03Anton Khirnov 07master:d1f539c97e04: h264: merge the two reinit blocks in slice_header_parse()
[14:21:11 CEST] <cone-209> ffmpeg 03Clément BSsch 07master:2021326f995f: Merge commit 'd1f539c97e04e7cebecaf6916c5064f243d39fcf'
[14:23:28 CEST] <cone-209> ffmpeg 03Anton Khirnov 07master:6e92181bf836: h264: pass just the PPS to get_chroma_qp()
[14:23:29 CEST] <cone-209> ffmpeg 03Clément BSsch 07master:5565e2711162: Merge commit '6e92181bf836f48627a4733b6fd240a99fd36365'
[16:46:25 CEST] <mateo`> hello, is there a function that convert the pps/sps data from the H264ParameterSet (not encapsulated), into a NALU ?
[16:52:42 CEST] <BtbN> bsf_h264_mp4toannexb?
[16:57:30 CEST] <mateo`> BtbN: I need to have a separate sps and pps buffers (nalu) for the MediaCodec decoders, I was previously using my own function to achieve that before switch to ff_h264_decode_extradata
[16:57:45 CEST] <BtbN> so the extradata basically?
[16:58:00 CEST] <mateo`> but I just noticed that ff_h264_decode_extradata remove the rbsp encapsulation
[16:58:24 CEST] <BtbN> bsf_h264_mp4toannexb gives you an extradata output buffer, nicely 0001 encoded
[16:58:31 CEST] <BtbN> look at the cuvid decoder on how to use it.
[16:58:43 CEST] <mateo`> but i need to separate the sps and pps manually right ?
[16:58:55 CEST] <BtbN> Yes, that's the usual extradata.
[17:12:51 CEST] <mateo`> BtbN: how would I split the pps / sps reliably ? look for {0, 0, 0, 1} header and split according to nalu type ?
[17:17:44 CEST] <nevcairiel> there is no guarantees the extradata will be set if the stream already is annexb
[17:25:18 CEST] <mateo`> nevcairiel: are you talking about the extradata of the bsf or the extradata of the avctx ?
[17:25:24 CEST] <nevcairiel> both
[17:28:14 CEST] <mateo`> in the case I have the extradata, I have two choices, either I keep using ff_h264_decode_extradata but I actually need to re-encapulsate the pps and sps buffers
[17:28:35 CEST] <mateo`> or using the bsf to convert the extradata to annex-b and then split the pps and pps
[17:29:43 CEST] <mateo`> I'm not sure what would be the best solution though
[18:33:16 CEST] <michaelni> ubitux, "./ffmpeg -fdebug +ts -i issue2.ts -vframes 12 -f null - 2>&1 | egrep 'read_frame_internal stream=' | sed 's/@.*]//' | grep stream=2" DTS are lost
[18:34:33 CEST] <michaelni> http://samples.ffmpeg.org/MPEG-VOB/transport/issue2.ts
[18:35:09 CEST] <michaelni> i think almost the same regression happened a month ago already
[18:45:14 CEST] <michaelni> seems caused by 2021326f995ff2eda5cd2aae600853f6eddb507d
[19:28:15 CEST] <michaelni> ubitux, posted a fate test for a similar (?idenntical) failure since 2021326f995ff2eda5cd2aae600853f6eddb507d
[20:02:43 CEST] <jamrial> michaelni: http://pastebin.com/myR8GHzz seems to fix it for me
[20:08:06 CEST] <BBB> jamrial: I know we cant decode some files, Im saying thats a bad thing so if its limited effort, lets not make it worse
[20:08:32 CEST] <jamrial> right
[20:08:38 CEST] <jamrial> BBB: sorry for that reply then
[20:08:54 CEST] <BBB> dont feel bad, its ok
[21:01:37 CEST] <cone-688> ffmpeg 03Martin Vignali 07master:92bf87db294c: fate/webp : add test for lossless picture to improve cover
[21:42:55 CEST] <cone-688> ffmpeg 03James Almer 07master:77eb05a2f11f: avcodec/h264_slice: Only call ff_h264_flush_change() on initialized contexts
[21:43:16 CEST] <michaelni> jamrial, diff applied with some changes, thanks alot!
[22:08:37 CEST] <BBB> jamrial: so & Im looking for a second opinion here, like, an independent one& am I being too hard on these guys for saying an encoder needs a decoder?
[22:16:33 CEST] <JEEB> BBB: I do tend to agree that in general it goes dec->enc, or both at the same time. be it a fully lavc decoder or just utilizing a decoder library
[22:16:42 CEST] <iive> BBB: are you talking about libx264 ?
[22:17:15 CEST] <jamrial> BBB: no, you're not being hard
[22:17:41 CEST] <jamrial> i'm sure they can add support for these files to the libvpxdec wrapper just as easily
[22:18:49 CEST] <JEEB> yeah
[22:18:58 CEST] <BBB> I feel that right now, nobody really knows how to deal with these files. in most cases its just ffmpeg doeesnt play it or gstreamers ffmpeg plugin isnt working"
[22:33:39 CEST] <kierank> BBB: does vp9 do anything special for it's alpha coding?
[22:33:58 CEST] <kierank> to aid sharp edges etc
[22:34:03 CEST] <BBB> no
[22:34:07 CEST] <BBB> it a separate stream
[22:34:15 CEST] <BBB> I suppose its typically coded at a lower Q since its veyr simple
[22:34:24 CEST] <BBB> but no idea
[22:34:30 CEST] <BBB> its not in the main bitstream
[22:34:33 CEST] <kierank> hmm, still a bit annoying then, whole point of alpha is to have clean edges
[22:35:43 CEST] <BBB> yes
[22:35:49 CEST] <BBB> but I mean, Im not asking them ro change the coding
[22:35:55 CEST] <BBB> Im just asking them to provide an implementation
[22:36:31 CEST] <kierank> I just wonder if anybody thought through how to code alpha properly
[22:38:52 CEST] <BBB> likely noto
[22:39:01 CEST] <BBB> why do research if you can hack it together quickly and ship it
[22:39:05 CEST] <BBB> :-p
[22:39:11 CEST] <BBB> its not like h264 did a good job at this
[22:39:32 CEST] <kierank> apple have their own alpha in 264
[22:39:34 CEST] <kierank> basic rle
[22:46:27 CEST] <nevcairiel> arent there like 3 different ways to code alpha in webm, or something
[22:46:33 CEST] <nevcairiel> or did they finally decide on one officially =p
[22:47:14 CEST] <JEEB> :D
[23:11:32 CEST] <BBB> nevcairiel: 2, right? the one in webp and the one in vp8/alpha/webm
[23:11:51 CEST] <BBB> and isnt the one in webp for lossless rgba only or so?
[23:11:54 CEST] <BBB> I dont recall exactly
[23:12:56 CEST] <jamrial> BBB: no, webp also supports yuva420p for lossy+alpha
[23:13:21 CEST] <BBB> ah
[23:13:36 CEST] <BBB> does that use the same mechanism as rgba lossless?
[23:13:39 CEST] <BBB> then maybe there are 3 ways
[23:14:54 CEST] <llogan> i should tweet about 3.1.1. what should i say about it? didn't really follow the details.
[23:14:55 CEST] <nevcairiel> all i remember is that the alpha data is practically encoded as "side-data" in the mkv/webm layer and nort part of the video codec, which already screams fail to me
[23:16:30 CEST] <jamrial> webp has the alpha bitstream separate from the vp8 bitstream, in a different chunk
[23:16:46 CEST] <jamrial> looks like it's used for both lossy and lossless
[23:16:54 CEST] <nevcairiel> ie. alpha is an afterthought, thats never a good recipe for success
[23:20:24 CEST] <jamrial> llogan: maybe just say we released 3.1.1 and it has fixes for people that "experienced problems" upgrading from 3.0 to 3.1 with their applications or something like that
[23:22:38 CEST] <jamrial> or maybe not even that. most users looking at twitter would probably only care about the cli and that didn't have any issues
[23:23:57 CEST] <jamrial> nevcairiel: yeah, the ALPH chunk is part of the "extended" format
[23:24:19 CEST] <jamrial> same with animated webp data
[23:24:41 CEST] <nevcairiel> did webp ever see any kind of adoption?
[23:24:56 CEST] <jamrial> chromium based browsers only afaik
[23:25:00 CEST] <nevcairiel> at least webm is kinda getting more widely supported in stock browsers
[23:25:12 CEST] <nevcairiel> even MS signed up for that
[23:25:13 CEST] <jamrial> firefox refuses to adopt it
[23:25:27 CEST] <nevcairiel> firefox politics are just weird
[23:26:58 CEST] <jamrial> they did adopt webm/vp8 and webm/vp9 like everyone else, so it's not just "google bad" or whatever
[23:27:17 CEST] <llogan> jamrial: how about, "We just released FFmpeg 3.1.1 which fixes a few API related issues present in the recent 3.1 release."
[23:28:01 CEST] <nevcairiel> Apple seems to flat out not bother with webm as the last hold out
[23:28:07 CEST] <nevcairiel> safari and iOS have zero support
[23:32:10 CEST] <jamrial> google also released a WIC component to add webp support to Windows Photo Viewer and such
[23:32:38 CEST] <nevcairiel> heh
[23:34:21 CEST] <jamrial> it's for vista, 7 and 8, but i installed it on 10 and works fine. seems to work with everything except animated webp
[23:35:01 CEST] <jamrial> llogan: should work i guess
[00:00:00 CEST] --- Sat Jul  2 2016