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

burek burek021 at gmail.com
Sat Sep 5 02:05:02 CEST 2015


[01:00:59 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:f5a6a8336fa2: avfilter/af_channelmap: Reorder operations to avoid memleak
[01:06:48 CEST] <RiCON> ffmpeg.org down?
[01:07:27 CEST] <c_14> RiCON: works for me
[01:07:59 CEST] <RiCON> yeah, works again
[01:40:54 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:cbd3cd8eb2de: avcodec/vp3: Check init_get_bits8() for failure
[01:40:55 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:f1593e4ca564: avcodec/tta: Check init_get_bits8() for failure
[01:40:56 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:a51d4246d8ac: avcodec/svq1dec: Check init_get_bits8() for failure
[03:39:49 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:6ae1a32d8ac7: avcodec/sonic: Check init_get_bits8() for failure
[03:39:50 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:21d8c6612fce: avcodec/smacker: Check init_get_bits8() for failure
[03:39:51 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:194dd155582d: avcodec/ira288: Check init_get_bits8() for failure
[03:39:52 CEST] <cone-556> ffmpeg 03Michael Niedermayer 07master:bd6610c3b39e: avcodec/hevc_parser: Check init_get_bits8() for failure
[11:25:01 CEST] <martijnb> does anyone know if there are there people actively working on mpeg dash  demuxing/generating manifest files? or are there reasons not to?
[11:40:37 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:325ee610ba97: avcodec/libfdk-aacdec: Remove unused variable
[11:40:37 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:e9c58033e884: doc/examples/http_multiclient: Fix occured typo
[12:05:03 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:cf410f8fb94d: ffmpeg: Drop redundant ist check
[12:05:04 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:66a7bc001094: avcodec/adpcm: Check init_get_bits8() for failure
[12:05:05 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:c447ab0e746c: avcodec/eatgq: Check init_get_bits8() for failure
[12:12:29 CEST] <kierank> rtmp into decklink will never work
[12:25:05 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:71ec8e1ed6cf: avcodec/g2meet: Fix potential overflow in tile dimensions check
[12:25:06 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:fb0466699575: avcodec/g2meet: Also clear tile dimensions on header_fail
[13:00:11 CEST] <BtbN> martijnb, there already is a dash muxer?
[13:23:21 CEST] <martijnb> BtbN, yeah, though seeming it doesn't generate manifests it's basically an advanced segmenter as far as I figure
[13:23:36 CEST] <BtbN> Of course it generates the mpd.
[13:23:59 CEST] <martijnb> it does? I just read you need mp4box on the side
[13:24:12 CEST] <nevcairiel> there is dashenc
[13:24:12 CEST] <martijnb> well, just demuxer then, my mistake
[13:24:17 CEST] <BtbN> No idea what you are reading.
[13:24:22 CEST] <JEEB> libavformat/dashenc.c
[13:24:24 CEST] <JEEB> :P
[13:24:40 CEST] <BtbN> The demuxer needs some xml parser, and so far nobody wanted to introduce that dependency.
[13:25:39 CEST] <nevcairiel> avxml!
[13:29:47 CEST] <martijnb> are there any obvious motivations not to? not enough demand to warrant another dependency? licensing nonsense? 
[13:30:29 CEST] <nevcairiel> probably just that noone cared enough to bother to write it
[13:32:12 CEST] <iive> libxml2 is under MIT license, so there should be no issues on that front.
[13:35:29 CEST] <BtbN> But it's another external dependency.
[13:35:38 CEST] <BtbN> And someone would have to deal with the horrors of mpeg-dash.
[13:37:30 CEST] <martijnb> the parsing seems fairly doable but demuxing anything adaptive is a pain of course
[13:37:58 CEST] <BtbN> There'd be no support for adaptive stuff.
[13:38:05 CEST] <BtbN> Just one stream.
[13:38:58 CEST] <martijnb> introducing libdash as a dependency would be out of the question?
[13:39:49 CEST] <nevcairiel> libdash uses avformat, circular much? :D
[13:40:12 CEST] <martijnb> the irony wasn't lost on me
[13:40:47 CEST] <wm4> all XML parsers I've seen were broken in some way (e.g. bad libraries, even if they handled XML well)
[13:41:07 CEST] <nevcairiel> libxml2 is just annoying to use, otherwise it seem fine
[13:41:37 CEST] <wm4> is that the gnome thing?
[13:41:40 CEST] <nevcairiel> yes
[13:41:44 CEST] <nevcairiel> but it doesnt use glib
[13:41:49 CEST] <nevcairiel> in case you are wondering :p
[13:41:52 CEST] <nevcairiel> no external deps
[13:45:39 CEST] <wm4> as expected this lib is bloated and insane
[13:45:47 CEST] <wm4> and has some fun global state
[13:45:57 CEST] <wm4> a loooots of CVEs
[13:46:47 CEST] <wm4> I wonder what's the deal with this... isn't basic XML pretty simple after all?
[13:47:16 CEST] <martijnb> you'd think..
[13:47:46 CEST] <nevcairiel> basic simple parsing is pretty simple, but such a library of course tries to cover all the use cases, including schema validation and all the shit that comes with it
[13:52:55 CEST] <wm4> we don't need all that
[13:53:00 CEST] <wm4> no dtds, no xpath, etc.
[13:53:40 CEST] <martijnb> writing a simple parser for mpd's specifically would be easy enough too, but obviously that'll limit it's applicability, don't know if that's the way we'd want to go
[13:54:01 CEST] <nevcairiel> i would be against a half-assed specialized parser for that
[13:54:17 CEST] <martijnb> yeah, it doesn't sound appealing
[13:54:18 CEST] <nevcairiel> its not like libxml2 is that bad, and its pratcically a system library everywhere anyway
[13:54:36 CEST] <wm4> it doesn't have to be half-assed, just parse XML correctly
[13:56:30 CEST] <martijnb> risk is of course that people will then try to extend it and we'll still end up with all the same issues existing xml libs suffer
[13:58:05 CEST] <wm4> libxml2 even has a http client
[13:58:51 CEST] <nevcairiel> of course, need to download schemas
[14:21:09 CEST] <Compn> martijnb : probably we dont feel like duplicating youtube-dl
[14:21:19 CEST] <Compn> martijnb : adding support to ffmpeg for youtube-dl might be useful
[14:21:39 CEST] <Compn> someone was working on dash though
[14:22:01 CEST] <wm4> Compn: what the fuck does youtube-dl have to do with this
[14:22:11 CEST] <Compn> sorry, just woke up, ignore me
[14:25:29 CEST] <martijnb> youtube uses dash for higher qualities afaik, that's the link?
[14:25:54 CEST] <Compn> yes
[14:26:04 CEST] <Compn> youtube is the only one using dash i've seen so far
[14:26:20 CEST] <martijnb> it's just one application though
[14:26:24 CEST] <Compn> just like youtube is the only one using vp9 and webm... ;p
[14:26:41 CEST] <martijnb> only way to stream hevc and still following standards is dash
[14:27:13 CEST] <martijnb> something like wowza only streams hevc over dash
[14:27:30 CEST] <martijnb> so there's more applications than youtube out there, and there's bound to be more coming ;)
[14:27:43 CEST] <JEEB> uhh
[14:27:48 CEST] <JEEB> HEVC is standardized in MPEG-tS
[14:27:54 CEST] <JEEB> thus HLS is also valid
[14:28:04 CEST] <martijnb> is it? I thought it was draft still
[14:28:10 CEST] <JEEB> yes, it has been for quite a while
[14:28:13 CEST] <JEEB> even before 14496-15
[14:28:14 CEST] <nevcairiel> its not like anyone cares, if they want to do something they invent new standards
[14:28:20 CEST] <kierank> hevc in flv in dash
[14:28:28 CEST] <BtbN> dash is mp4
[14:28:30 CEST] <martijnb> neat
[14:28:32 CEST] <JEEB> kierank: all my yes.jpg
[14:28:39 CEST] <kierank> hevc in mxf 
[14:28:48 CEST] <JEEB> I bet I'll see that at some point :P
[14:28:51 CEST] <JEEB> with some funky XML
[14:29:13 CEST] <JEEB> also what's that thing about object-based audio?
[14:29:18 CEST] <kierank> mpeg-h
[14:29:21 CEST] <kierank> and dolby ac-4
[14:29:34 CEST] <JEEB> oh, ac-4 also has that? ugh
[14:29:35 CEST] <kierank> I think your (new) employer works closely with dolby
[14:30:07 CEST] <JEEB> could be, so far has been very far from my vectors, though
[14:30:21 CEST] <kierank> all the protein boxes I have have huge dolby logos on them
[14:31:33 CEST] <JEEB> yeah... all the boxes that ended up here were before all that stuff was stuck on them methinks
[14:36:38 CEST] <martijnb> Compn, any idea who that someone is?
[15:31:37 CEST] <ubitux> do we have standalone image formats that are not into image2?
[15:32:15 CEST] <ubitux> or asked differently, any saner way than checking for image2 demuxer for a 1-image "media"?
[15:37:27 CEST] <wm4> you just want to probe image formats?
[15:38:04 CEST] <ubitux> i want to check if i'm opening an image
[15:38:13 CEST] <wm4> good luck
[15:38:17 CEST] <ubitux> :D
[15:38:21 CEST] <wm4> personally I check for image2pipe
[15:38:42 CEST] <wm4> image2 doesn't work correctly (for reasons... because of the pattern crap)
[15:38:51 CEST] <wm4> I guess we could define a flag
[15:39:00 CEST] <wm4> (but would it be set for gif? or apng?)
[15:39:16 CEST] <ubitux> what doesn't work correctly?
[15:39:29 CEST] <wm4> I use custom IO with libavformat
[15:39:48 CEST] <wm4> it doesn't work with image2 for whatever reasons
[16:07:49 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:339550e7c80e: vp9: reset segmentation information on context reset.
[16:07:50 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:caf6512ac4e3: vp9: deal with the case where update_map=0 but we're key/intraonly.
[16:07:51 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:cc9d3a3e3696: vp9: fix indentation.
[16:07:52 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:8d25a11dc79c: vp9: use resetctx in the same way as libvpx.
[16:07:53 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:eaff36c973af: vp9: fix segmentation map retention if segmentation is turned off.
[16:07:54 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:48f641a18b84: vp9: clip intermediates in dequant calculations.
[16:07:55 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:ecd9f57edcbd: vp9: read reserved bit in RGB header.
[16:07:56 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:7cc7d13fe32f: vp9: fix RGB chroma subsampling.
[16:07:57 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:8b45e87f64d5: vp9: fix segmentation map retention across keyframe boundaries.
[16:07:58 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:4ecb8b419183: vp9: don't erase values for {lf,ref,skip,q}_enabled if segmentation=0.
[16:07:59 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:10142f994acb: libvpxdec: explicitly signal RGB.
[16:08:00 CEST] <cone-672> ffmpeg 03Ronald S. Bultje 07master:9ee2ddd773f9: vp9_parse: fix parsing of pskip and profile 2/3.
[16:19:35 CEST] <Compn> martijnb : Martin Storsjö worked on the dash encoder...
[16:19:47 CEST] <Compn> otherwise i dont know who else is working on it, sorry. i have forgotten
[16:19:55 CEST] <Compn> martijnb : feel free to ask on the list though
[16:20:26 CEST] <Compn> martijnb : martin s is here as "wbs" , not sure hes active though
[16:21:11 CEST] <martijnb> yeah, had found his name, so I might throw an email his way asking if he knows more, if there's people working on it and if they need help
[16:21:16 CEST] <martijnb> can't hurt I figure
[16:21:42 CEST] <Compn> right :)
[16:23:49 CEST] <martijnb> for now I'm just glaring at the clock trying to make it go faster as it's slowly but surely nearing weekend ;p
[16:24:24 CEST] <Compn> wm4 : conversing with potential developers can encourage development. just talking to people and figuring out questions and answers can be seen as friendly. where as ignoring questions or not responding to them can seem cold or unhelpful, discouraging people from working on ffmpeg... thats why i talk to people, answer questions and ask dumb questions...
[16:24:54 CEST] <Compn> ehe
[16:26:31 CEST] <Compn> people question my usefulness here. must reinforce positive working environment.
[17:09:41 CEST] <wm4> didn't someone want to add packed 4:4:4 format support? what happened to it?
[17:10:08 CEST] <nevcairiel> he disappeared
[17:14:33 CEST] <ubitux> i wonder if i should merge my lut3d xyz addition
[17:14:59 CEST] <ubitux> but the query format negociation is a bit annoying
[17:15:12 CEST] <ubitux> durandal_1707: are you working on query_formats2 or something?
[17:24:45 CEST] <ubitux> is Ganesh on IRC?
[18:03:48 CEST] <durandal_1707> ubitux: nope, im bussy with something else
[18:15:33 CEST] <durandal_1707> ubitux: what you need for query_formats?
[18:20:05 CEST] <BBB> Compn: you messed up the temporal order of VDD departures
[18:20:13 CEST] <BBB> youre leaving before me but listed after me
[19:07:22 CEST] <wm4> did I land on that guys spam filter or what
[19:08:28 CEST] <durandal_1707> cc him
[19:20:47 CEST] <cone-672> ffmpeg 03Paul B Mahol 07master:5b658bcc8ad2: avfilter/vf_waveform: 9 and 10 bit depth support for lowpass & color filter
[19:20:48 CEST] <cone-672> ffmpeg 03Paul B Mahol 07master:fda05554e378: avfilter/vf_waveform: reduce number of operations a little
[19:20:49 CEST] <cone-672> ffmpeg 03Paul B Mahol 07master:55886c67e719: avfilter/vf_waveform: change intensity to float
[19:35:35 CEST] <cone-672> ffmpeg 03Paul B Mahol 07master:db592f3b03a2: avfilter/vf_waveform: stop abusing s->size for calculating limit
[19:42:13 CEST] <ubitux> durandal_1707: i need to force one specific pixel format (or eventually a small set) if i have one one specific pixel format as input 
[19:42:32 CEST] <ubitux> simple condition though
[20:37:25 CEST] <durandal_1707> ubitux: and how query_formats2 could acomplish that?
[20:37:47 CEST] <ubitux> i thought you were talking about that not long ago
[20:37:53 CEST] <ubitux> for conditionnal negociation
[20:38:03 CEST] <wm4> I question why lavfi needs "global" format negotation
[20:50:04 CEST] <cone-672> ffmpeg 03Paul B Mahol 07master:f011e98cb17b: avfilter/vf_vectorscope: change intensity to float
[20:52:24 CEST] <durandal_1707> ubitux: yes, but how to acomplish it?
[20:52:45 CEST] <ubitux> absolutely no idea
[20:52:49 CEST] <durandal_1707> wm4: what is alternative?
[20:56:37 CEST] <wm4> durandal_1707: using a naive conversion filter insertion algorithm
[22:45:16 CEST] <durandal_1707> wm4: and how it would work?
[22:46:29 CEST] <wm4> durandal_1707: try to configure filter pad with a format, if it fails, the filter suggests an acceptable format, and a filter to convert to this format is inserted
[22:47:05 CEST] <wm4> but this suggestion will be rejected because that wouldn't compute an "ideal" filter graph (nevermind that even so libavfilter is pretty dumb with its automatic conversion filter insertion)
[22:50:33 CEST] <ubitux> libav is trying to implement bayers as... codec? wut?
[22:50:44 CEST] <ubitux> (we have bayer pixel formats in ffmpeg, right?)
[22:51:06 CEST] <wm4> we do... and implementing them as codecs is the right way
[22:51:17 CEST] <wm4> just like ffmpeg implements some raw formats as codecs
[22:51:32 CEST] <wm4> like v210
[22:52:51 CEST] <ubitux> well, no codec encodes bayer?
[22:53:02 CEST] <ubitux> pretty sure you can find some in tiff at least
[22:53:18 CEST] <ubitux> (not sure if the decoding is straightforward)
[23:49:28 CEST] <cone-672> ffmpeg 03Carl Eugen Hoyos 07master:f253c341755e: lavc/j2kenc: Remove experimental flag.
[23:52:56 CEST] <cone-672> ffmpeg 03Carl Eugen Hoyos 07master:f7361dbcf482: lavc/mxfdec: Support more mxf files with codec_ul.
[23:53:38 CEST] <y2k> hi! in a demuxer, I don't know how many mp3 frames I have written out. now I am trying to figure out the time offsets for certain points in the mp3 data stream (for adding chapter support). is there a way to do this easily? 
[23:54:08 CEST] <y2k> are there existing examples I could look at?
[00:00:00 CEST] --- Sat Sep  5 2015


More information about the Ffmpeg-devel-irc mailing list