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

[burek]

[00:34] <Tim_G> nevcairiel: that's why CC0 exists btw, for the countries where PD doesn't exist
[00:55] <kapouik> hi
[00:56] <kapouik> I'm looking on source code of the version 2.4 on github and I find something strange 
[00:57] <kapouik> the branch 2.4 has been updated in 2.5 if I look the latest commit message
[00:57] <kapouik> is it normal ?
[01:46] <michaelni> kapouik, what do you look at, and what do you see that you find strange exactly ?
[01:50] <kapouik> https://github.com/FFmpeg/FFmpeg/tree/release/2.4 <- look latest commit on this branch
[01:50] <cone-867> ffmpeg.git 03Martin Storsjö 07master:50036c30df83: fate: Use bitexact conversions in the dpxparser test
[01:50] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:8d3133f46851: Merge commit '50036c30df83b609bc5a95276f1287f8b9b8bdd6'
[01:50] <kapouik> michaelni, it look like you commit on the wrong branch
[01:51] <kapouik> oh my fault ... I just look again ... I have read 2.5 and not 2.4.5
[01:51] <kapouik> sorry for the mistake 
[01:57] <cone-867> ffmpeg.git 03Martin Storsjö 07master:b91a5757fcbf: dashenc: Fix writing of timelines that don't start at t=0
[01:57] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:e5a3766767a1: Merge commit 'b91a5757fcbf723da99b05b298a6f820271dbc2b'
[02:12] <cone-867> ffmpeg.git 03Martin Storsjö 07master:8d54bacb789c: dashenc: Remove some stray double spaces
[02:12] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:0ffb61e8cabf: Merge commit '8d54bacb789c7d37ca3cf48d9ac13083ad0c1ba7'
[02:26] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:17dc83ab5e69: avfilter/vf_cropdetect: add RGB & RGBA support
[03:57] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:60e2c3110ae3: avfilter/vf_cropdetect: Unroll 1byte per sample loop
[03:57] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:5c7227bbb3c1: avfilter/vf_cropdetect: Unroll 3 & 4 bytes per sample loop
[05:46] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:6ab4812f31c6: avfilter/vf_cropdetect: support 9-16bit planar formats
[05:46] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:a2e2a9f240a7: avfilter/vf_cropdetect: fix ; typos
[05:46] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:e405a8a73eeb: avfilter/vf_cropdetect: extend limit to cover 16bit pixel formats
[10:34] <cehoyos> saste: I fear your review does not really help;-)
[11:30] <saste> cehoyos, what review?
[11:47] <cehoyos> You wrote on -devel that you prefer to use struct member names in ffprobe but that you agree it's nice to have more meaningful output.
[11:50] <ubitux> nb_ref_frames would be even better
[11:55] <saste> cehoyos, the choice is left to the contributor
[12:03] <ubitux> saste: is it possible to plug a filtergraph (with 1 input and 1 output) at the end of another filtergraph?
[12:03] <ubitux> typically in the context of the ffplay or ffmpeg
[12:03] <ubitux> like, imagine you would want to support -vf foo -vf bar
[12:04] <ubitux> (and i really meant a filtergraph, not a filter)
[12:05] <saste> ubitux, it should be doable, but only *before* configuration
[12:05] <saste> once a filtergraph is configured I don't think that's possible
[12:06] <ubitux> ok
[12:06] <saste> also you need to know how to link output and input pads, of course
[12:06] <ubitux> and can you call any of the avfilter_graph_parse_* function multiple times on the same graph?
[12:40] <saste> ubitux, never tried...
[12:40] <saste> I don't know what happens if you configure a graph multiple times
[13:58] <ubitux> why do we still have AVFilterBufferRef things all over?
[13:59] <ubitux> ah it's under FF_API thing
[14:15] <ubitux> mmh we still have 2 filters with "needs_fifo" flag?
[14:29] <cone-77> ffmpeg.git 03Clément BSsch 07master:39e18b1f4063: avfilter/framepack: use FF_CEIL_RSHIFT()
[14:29] <cone-77> ffmpeg.git 03Clément BSsch 07master:0c10cf6ab1aa: fate: add a fate-filter-framepack rule
[15:14] <anshul__> I am planning to write a filter, that use data stream and 2 programs with multiple stream, Which implementation should I chose for my starting point
[15:24] Action: ubitux wonders why there is a distinction between AVFilterLink and AVFilterInOut
[16:05] <ubitux> i'd like to test if an option is available in a given format before opening
[16:05] <ubitux> how can i do that?
[16:06] <ubitux> akira4: hey :)
[16:06] <ubitux> akira4: how are things going?
[16:07] <akira4> good timing :) I had a few doubts about the protocol patch.
[16:08] <ubitux> sure
[16:10] <akira4> I'm not sure what exactly the dvd_protocol_send function is for. It seems to be used in all the build_packet_* function calls
[16:13] <cone-77> ffmpeg.git 03Michael Stypa 07release/2.1:bf5df31b4f92: fix Makefile objects for pulseaudio support
[16:14] <ubitux> akira4: it sounds like future plans for a user callback
[16:14] <ubitux> like, you know, for menu and stuff
[16:14] <ubitux> you can probably drop that stuff
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:8240fa5701aa: avcodec/motion_est: use 2x8x8 for interlaced qpel
[16:14] <ubitux> i see no such thing available right now in the URLProtocol
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:80ba4b5d4536: avformat/rmdec: Check codec_data_size
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:56c5e009a184: swscale/x86/rgb2rgb_template: fix crash with tiny size and nv12 output
[16:14] <cone-77> ffmpeg.git 03wm4 07release/2.1:68b6a5efbfd5: avformat/matroskadec: fix handling of recursive SeekHead elements
[16:14] <cone-77> ffmpeg.git 03Rob Sykes 07release/2.1:059762d9da08: swresample/soxr_resample: fix error handling
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:844f7f78aa52: avformat/aviobuf: Check that avio_seek() target is non negative
[16:14] <cone-77> ffmpeg.git 03wm4 07release/2.1:df1ea139b4fb: lavu/frame: fix malloc error path in av_frame_copy_props()
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:b4c4f9dba613: configure: create the tests directory like the doc directory
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:96981b092c09: avcodec/vmdvideo: Check len before using it in method 3
[16:14] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:ba99e90357c9: avcodec/utvideodec: Fix handling of slice_height=0
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:07a37001a323: avformat/mov: check atom nesting depth
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:9354c47d2ec9: swscale: increase yuv2rgb table headroom
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:ac499d8142f3: avcodec/h264: make the first field of H264Context an AVClass
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:35819400e782: avcodec/indeo3: use signed variables to avoid underflow
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:9dc6a7f13a23: avcodec/hevc: clear filter_slice_edges() on allocation
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:84bc2cea2377: avcodec/h264: Clear delayed_pic on deallocation
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:7bd8ea83a0ba: avcodec/hevc_ps: Check diff_cu_qp_delta_depth
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:b188ff5e183d: avcodec/h264: Check *log2_weight_denom
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:d3853ad11f21: avcodec/indeo3: ensure offsets are non negative
[16:15] <cone-77> ffmpeg.git 03Anton Khirnov 07release/2.1:01c83f4cb197: jvdec: check frame dimensions
[16:15] <cone-77> ffmpeg.git 03Anton Khirnov 07release/2.1:823a9177a3ea: mmvideo: check frame dimensions
[16:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:a736171b69b0: avformat/mov: Fix memleaks for duplicate STCO/CO64/STSC atoms
[16:15] <cone-77> ffmpeg.git 03Stefano Sabatini 07release/2.1:67e2394cc68e: lavf/segment: remove duplicated and inconsistent cleanup code in seg_write_packet()
[16:15] <ubitux> akira4: basically, you want something as basic as libavformat/bluray.c
[16:16] <ubitux> if possible
[16:16] <ubitux> (it's a ~200 line file which seems to support the strict minimum)
[16:17] <ubitux> hopefully the libdvd* offers a similar api
[16:18] <ubitux> so feel free to drop anything not used or incomplete
[16:20] <j-b> commit release rage
[16:28] <cone-77> ffmpeg.git 03Michael Niedermayer 07release/2.1:c27539cd1eaa: Update for 2.1.7
[16:55] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:eb465b8c56d4: avfilter/vf_uspp: clear AVPacket to not leave uninitialized memory
[16:58] <ubitux> huh... in ffplay, is->video_st is set in configure_video_filters(), but is->audio_st is not st in configure_audio_filters()
[16:58] Action: ubitux confused
[17:00] <ubitux> oh great it's called twice
[17:08] <ubitux> aselect should be made sample accurate
[17:08] <ubitux> i think.
[17:43] <anshul_mahe> What i need to do, if my patch breaks ABI
[17:44] <anshul_mahe> and what to do, if there is no existing revision or similar thing in world realted to my patch
[17:46] <ubitux> add the fields at the end
[17:46] <ubitux> btw, use PRIu64 and similar instead of %llu
[17:51] <anshul_mahe> Actually I am looking some more harsh review comments, about implementation and logic used
[17:52] <ubitux> i know, that's why i'm mentioning it here
[18:10] <Tim_G> anshul__: is it possible to use AVBuffer instead of adding a new structure?
[18:11] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:eee9b7a673de: ffprobe: Support extracting the number of reference frames
[18:12] <anshul__> I dont know I will look at it, will get back 2 u soon
[18:15] <anshul__> Tim_G: yes that struct is good, i will surely use it
[18:16] <anshul__> you want me to use it instead of AVData structure
[18:17] <anshul__> What do we do when things break ABI, I rarely understand this ABI and API concept
[18:23] <anshul__> i will look git logs for this ABI thing
[18:26] <Daemon404> as ubitux said, if you add fields at the end, it's not an ABI break
[18:26] <BtbN> As long as only ffmpeg functions are used to allocate the struct
[18:27] <Daemon404> well, yeah.
[18:28] <ubitux> damn ffmpeg
[18:29] <ubitux> i feel like this -ss thing is going to be annoying
[18:31] <anshul__> ok, i will do that thanks
[18:31] <Daemon404> i should look closer at that patch...
[18:31] <Daemon404> AVData sounds liek a way too generic name
[18:31] Action: Daemon404 wonders what is wrong with avbuffers here
[18:32] <anshul__> I was changing it to AVBuffer as Tim_G suggested, didn't knew about it
[18:32] <Daemon404> oh ok
[18:34] <anshul__> can be add is_valid in AVBuffer, or use size to check whether its valid  or not
[18:35] <anshul__> because moving got_output variable is much cumbersome
[22:15] <BBB> lol @ that x265 idea
[22:15] <BBB> I remember a while ago there was a user trying to add runtime BE/LE selection to ffmpeg, so he could make runtime-selectable universal binaries for macosx that work on both ppc and x86
[22:15] <BBB> ...
[22:16] <BBB> I think theyre in the same ballpark
[22:16] <kierank> debian does the 8-bit/10-bit thing
[22:18] <iive> i think elf supports such a thing, but there is a patent covering it.
[22:22] <BBB> theres a patent for a bit that specifies whether a following image sequence consists of one progressive frame or two half fields that are to be interleaved to emulate a progressive image sequence
[22:22] <BBB> I bet you theres a patent for any sentence that anyone in this chat channel has ever uttered
[22:25] <iive> well, i've read about somebody trying to implement this, i don't remember what list was, kernel, glibc or gcc. but they scrapped the code because it was covered by patent.
[22:28] <ubitux> it's still an enigma to me why both x264 and x265 can't just have 8 and 10 bit available in the same build
[22:29] <ubitux> maybe that require some extended templating for a lot of code but well... is that really impossible to do?
[22:30] <iive> ffmpeg can decode 8.9,10 bit with same binary :)
[22:31] <nevcairiel> ubitux: well its just a design decision i guess
[22:33] <ubitux> i believe it really is a technical issue
[22:33] <ubitux> no one would make such annoying "design" on purpose
[22:34] <iive> maybe they couldn't extend their existing design, without making a huge mess in the code.
[22:34] <nevcairiel> in x264 probably because 10-bit was bolted on afterwards
[22:34] <nevcairiel> and x265 was just a copy :p
[22:35] <iive> maybe somebody could explain to me, why the 10bit version cannot encode 8bit videos...
[22:35] <iive> it can't, can it?
[22:36] <kierank> who is mentoring the crypto person?
[22:36] <kierank> opw student
[22:36] <kierank> can we have AES-NI (i.e something useful) instead of random ciphers that nobody uses
[22:36] <kierank> pleasssssee
[22:36] <nevcairiel> i wonder how hard using aes-ni is
[22:37] <nevcairiel> do we have a benchmark for aes?
[22:40] <jamrial> i posted some numbers a while ago
[22:40] <ubitux> kierank: maybe tell it in the thread
[22:40] <ubitux> and explain why it would be welcome :)
[22:40] <jamrial> gcrypt uses aes-ni, and it's many times faster than c thanks to it
[22:43] <jamrial> nevcairiel: tools/crypto_bench
[22:51] <wm4> <BBB> I think theyre in the same ballpark <- what's the matter, for decoding this is also done?
[22:59] <kierank> it's not
[22:59] <kierank> well it kind of is
[23:01] <BBB> I dont think we dlopen on decoding
[23:01] <BBB> I think they just dont want to add another layer of templating to their api
[23:01] <BBB> which is kind of a silly reaon
[23:01] <BBB> but whatever
[23:02] <BBB> theres no fundamental reason why you wouldnt be able to do it
[23:02] <BBB> its just effort
[23:02] <BBB> and most developers are lazy
[23:02] <kierank> well the right way would actually be to mix them in an encoder
[23:03] <iive> BBB: you know h264 code better, is it possible to do 8 bit decoding with 10bit routines?
[23:03] <kierank> because for many calculations you don't need 10-bits of precision 
[23:03] <iive> i mean, encoding...
[23:15] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:081567397e3c: avfilter/vf_yadif: add >8bit planar rgb formats
[00:00] --- Wed Dec 31 2014