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

[burek]

[00:02] <michaelni> looks cute
[00:13] <ubitux> btw, the documentation of the project is insanely good
[00:27] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:63090842df76: av_samples_alloc_array_and_samples: Fix sizeof type.
[00:27] <cone-132> ffmpeg.git 03Michael Niedermayer 07master:578d9cf7ccd3: mxf_timestamp_to_str: dont leave uninitilaized fields in time.
[00:37] <ubitux> saste: i will apply the fade patch maybe tomorrow
[00:37] <ubitux> unless you have some comments
[00:38] <saste> ubitux, I didn't read the patch but I trust you
[00:38] <ubitux> you shouldn't
[00:38] <ubitux> i don't even trust myself
[00:38] <saste> assuming it doesn't break the syntax
[00:38] <saste> well i don't trust me as well
[01:56] <ubitux> anyone on hydrogenaudio to request that guy to share a sample? http://www.hydrogenaudio.org/forums/index.php?showtopic=100448&hl=
[02:38] <cone-132> ffmpeg.git 03Roberto Togni 07master:8017683647f5: qdm2: initialize coeff_per_sb_select from bit_rate
[10:06] <cone-720> ffmpeg.git 03Martin Storsjö 07master:6d0fbebf9493: ppc: hpeldsp: Include attributes.h
[10:06] <cone-720> ffmpeg.git 03Michael Niedermayer 07master:2d234930209a: Merge remote-tracking branch 'qatar/master'
[11:19] <cone-720> ffmpeg.git 03Pavel Koshevoy 07master:5a2a0603780a: libavfilter/af_atempo: Fix uninitialized memory access
[11:19] <cone-720> ffmpeg.git 03Pavel Koshevoy 07master:0c77cdb491de: libavfilter/af_atempo: Avoid round-off error build-up, ticket #2484
[12:00] <saste> ubitux: i'm trying to write a POC for zmq messaging
[12:01] <ubitux> hehe :)
[12:01] <saste> basically i want to write a filter/server which brokes messages queued when  filter_frame() is called
[12:02] <saste> or should it be called a client, which subscribe to a server which sends the commands?
[12:02] <saste> also ideally we could have more than one publishing servers, and thus the "client"/filter may need to subscribe to more than one
[12:02] <saste> but for the moment I think 1 client/1 server should be ok
[12:03] <saste> do you have specific ideas in mind?
[12:04] <ubitux> i don't understand your first sentence
[12:04] <ubitux> :(
[12:04] <saste> with the filter/subscriber approach we can have several filters subscribed to different publishers
[12:04] <ubitux> but maybe that's because i just woke up
[12:05] <saste> the publisher sends a command,
[12:05] <saste> the filter/subscriber receives the command, queues it and process it in filter_frame()
[12:05] <cone-720> ffmpeg.git 03Michael Niedermayer 07master:83330cf5fae6: init_vlc_sparse: fix leak on error
[12:06] <cone-720> ffmpeg.git 03Michael Niedermayer 07master:14369f59c5ad: ffmpeg_filter: fix leak on error
[12:06] <saste> then it should probably send the answer back (e.g. in case of error)
[12:06] <saste> since we have a single publisher to which to communicate, this is going to be a bit easier
[12:07] <saste> the alternative is to have a server, which receives commands from the clients, process them and replies with an error status/message
[12:08] <saste> i'd go with the filter/subscriber approach and see if it works
[12:09] <saste> (the publisher logic needs to be handled outside of ffmpeg of course)
[12:09] <ubitux> just a minute, for the context, the idea is to allow third app to have a more advanced communication with filters than the send command thing, right?
[12:10] <saste> yes
[12:13] <ubitux> so you want a subscriber filter in the filtergraph which is used as the gateway?
[12:13] <ubitux> how will that filter do something with the other filters?
[12:13] <ubitux> use our internal command system?
[12:13] <saste> it will send commands to other filters
[12:14] <saste> like sendcmd
[12:14] <ubitux> right, ok
[12:15] Action: saste is reading man zmq_socket
[12:18] <saste> the problem with the subscriber/publisher approach is that it is unidirectional
[12:19] <saste> so no way to send back status/feedback
[12:40] <saste> looks like i need to do threading in any case...
[12:41] <ubitux> paul was talking about threading a few days ago
[12:41] <ubitux> it might be relevant to have some frame threading... 
[12:42] <ubitux> not sure how that can help you though :)
[12:43] <saste> uhm no after all maybe i don't need it
[12:43] <saste> since I can just query from a socket in filter_frame() in non-blocking mode
[13:22] <ubitux> saste: i wonder if it would be relevant to have a n-1 thread for a filter with n outputs
[13:23] <ubitux> given the design of lavfi, every branch should be independant from each other
[14:22] <ubitux> fun, there is sws_getCoefficients()
[14:22] <ubitux> but it's not used at all
[14:22] <ubitux> at least internally
[14:22] <ubitux> mmh the table is accessed directly, ok
[16:21] <cone-539> ffmpeg.git 03Nicolas George 07master:b57c23f8c85c: lavfi: add asetrate filter.
[16:48] <xlinkz0> is av_seek_frame with no flags the fastest way to seek?
[16:54] <michaelni> xlinkz0, depends on the demuxer
[16:54] <michaelni> with some (that support it) seeking per byte position is faster
[16:55] <xlinkz0> Video: h264 (Baseline) (avc1 / 0x31637661)
[16:55] <xlinkz0> but how would i know what byte i want to seek to?
[16:56] <xlinkz0> don't frames have different sizes?
[17:01] <xlinkz0> well the bottleneck seems to be disk speed anyway
[17:02] <xlinkz0> seek to the end of a 2h 25fps movie is 350ms if the movie is cached
[17:03] <xlinkz0> and 12 seconds if it's not :(
[17:13] <michaelni> xlinkz0, try something else than raw h264
[17:14] <xlinkz0> i have to work on this particular codec
[17:14] <cone-539> ffmpeg.git 03Nicolas George 07master:fd7a7e11b94b: lavfi/buffersink: fix possible leaks after allocation failures.
[17:15] <nevcairiel> seeking in raw files is always impossible, i would suggest to mux it into a container easier for seeking
[17:22] <xlinkz0> that overhead would be bigger than actual seeking
[17:22] <xlinkz0> anyway i can adjust the video length to something as small as 10 minutes
[17:22] <xlinkz0> i tried it on extreme cases to see how bad it could be
[17:32] <cone-539> ffmpeg.git 03Stefano Sabatini 07master:5e893df7ae15: lavfi/sendcmd: fix various "in in" rerepepetitions in messages
[17:32] <cone-539> ffmpeg.git 03Stefano Sabatini 07master:df766673e577: lavfi/sendcmd: drop now pointless sendcmd/asendcmd_init() wrappers
[18:25] <cone-539> ffmpeg.git 03Stefano Sabatini 07master:3e40b85683e6: lavfi: add interleave filters
[19:41] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:047716bbd8f5: ffplay: check av_samples_get_buffer_size() return
[19:44] <michaelni> ubitux, did you see CID991855 Resource leak (vf_curves) ?
[19:47] <michaelni> or CID991854 (ffprobe.c)
[19:47] <ubitux> oh i forgot to mark it as false positive
[19:48] <ubitux> (if it's the same that last time)
[19:51] <michaelni> it will not disappear until you mark it ...
[19:53] <ubitux> yes i know
[19:53] <ubitux> i'm going to do it for real
[19:53] <ubitux> i'm looking again at it
[19:58] <ubitux> done
[20:13] <ubitux> about ffprobe, i'd better let saste deal with it, it's his code mostly :)
[20:14] <ubitux> at least this part
[20:25] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:bc7330a84029: tools/ismindex: dont ignore return code of write_fragments()
[20:25] <cone-539> ffmpeg.git 03Michael Niedermayer 07master:ebea370dc390: ismindex: check mkdir()s return code
[20:57] <cone-539> ffmpeg.git 03Andy Martin 07master:4ac2da379383: lavfi/fade: Added ability to do video fade based on timestamp
[00:00] --- Mon Apr 22 2013