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

[burek]

[00:02] <ubitux> i need directions for what people want for bitmap subtitles
[00:03] <ubitux> basically, what AVSubtitles lack bitmap wise
[00:03] <ubitux> i'll backlog tomorrow, gn
[00:06] <J_Darnley> The only thing I want is OCR but I guess that comes after all the other hard desisions.
[00:42] <wm4> ubitux: pixel format, also having a common palette for all sub-bitmaps instead of one for each might be helpful
[02:31] <rcombs> wm4: ubitux: potentially, handling bitmap data and text data in the same stream
[03:21] <wangl> capture images frame from the camera, and every 66msframe rate 15	 call av_read_frame,spend time 0ms. 
[03:22] <wangl> if every 40ms(frame rate 25) call av_read_framespend time 50ms
[03:22] <wangl> why?
[03:39] <wangl> i have a problem. call av_read_frame, spend time 60ms, why ??
[03:49] <rcombs> slow I/O?
[03:50] <rcombs> maybe blocking until the camera sends the next frame?
[04:59] <cone-667> ffmpeg.git 03Michael Niedermayer 07master:4898440f6bd1: Move get_avc_nalsize() and find_start_code() to h264.h
[04:59] <cone-667> ffmpeg.git 03Michael Niedermayer 07master:3b678da5e386: avcodec/h264: simplify find_start_code()
[04:59] <cone-667> ffmpeg.git 03Michael Niedermayer 07master:69a9a90d2ef7: avcodec/h264_parser: rewrite the parse_nal_units() loop logic based on h264.c
[05:08] <wangl> @rcombs   if av_read_frame is waiting for the next frame, how to make camera to send frame fast?
[05:25] <rcombs> wangl: that depends on your camera, I'd expect
[05:25] <rcombs> how are you getting input from the camera?
[05:32] <wangl> @rcombs:  
[05:32] <wangl> pFormatCtxSrc_ = avformat_alloc_context();
[05:32] <wangl> AVDictionary* options = NULL;
[05:32] <wangl> av_dict_set(&options, "framerate", "25", 0);
[05:32] <wangl> AVInputFormat * inputFormat = av_find_input_format("dshow");
[05:32] <wangl> avformat_open_input(&pFormatCtxSrc_, "video=Integrated Camera", inputFormat, &options);
[05:32] <wangl> avformat_find_stream_info(pFormatCtxSrc_, &options)
[05:32] <wangl> avcodec_find_decoder
[05:32] <wangl> avcodec_open2
[05:32] <wangl> av_read_frame
[05:35] <wangl> i use the "dshow"
[05:44] <rcombs> please use a pastebin site for pastes longer than ~3 lines
[05:45] <rcombs> and I know next to nothing about dshow, so sorry to say I probably can't help
[05:46] <wangl> that's ok, thank you rcombs
[11:21] <ubitux> J_Darnley: yeah that's orthogonal
[11:21] <ubitux> wm4: about the pixel format, should we still continue with a very small subset of pixel formats?
[11:21] <ubitux> rcombs: yeah right, makes sense
[11:24] <wm4> would you use AVFrame or not?
[11:24] <ubitux> i still don't know
[11:25] <ubitux> it's not exactly easy when you have multiple rectangles
[11:25] <ubitux> we can use the extended data but that's starting to get ugly
[11:25] <wm4> you need all that extra stuff of course (position etc.)
[11:28] <ubitux> yeah exactly
[11:28] <ubitux> so my question really is how you want to use the subtitles api
[14:16] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:852aaead1fc2: avcodec/hevc_ps: Check default display window bitstream and skip if invalid
[15:59] <arwa> Is c in rgb2yuv the uint32 rgb value?
[16:02] <ubitux> yes
[16:03] <arwa> okay thanks
[16:03] <arwa> :)
[16:50] <reynaldo> does anyone remember when did FFmpeg got into Debian/experimental?
[16:54] <thardin> I'm wtf:ing pretty hard at that mxfdec patch
[16:59] <wm4> isn't that normal for mxf
[17:00] <thardin> true
[17:00] <thardin> hopefully I'll have time later this evening to develop a proper patch. context = https://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164589.html
[17:03] <ubitux> afaict it randomizes the last_pos
[17:03] <ubitux> so the next comparison mismatch
[17:03] <ubitux> i must say it's horrible
[17:03] <ubitux> :D
[17:04] <thardin> considering the demuxer already knows what direction it's scanning it should be enough to check whether the position is increasing/decreasing or not
[17:05] <thardin> something like last != cur && (last < cur ^^ mxf->parsing_backward)
[17:14] <cone-536> ffmpeg.git 03Thilo Borgmann 07master:ed2e97ce6a7a: lavd/avfoundation: Fix compilation for non MAC OS devices by conditional compilation of screen capture capabilities.
[18:25] <arwa> hey I am getting segmentation fault for the code I have written. 
[18:27] <wm4> use gdb or valgrind
[18:35] <arwa> I tried debugging it, but It is giving me error for the same function that I copied from hqx filter.
[18:36] <arwa> It is showing me that I am accessing a value which is exceeding the bounds, but I printed the value, and I found that its within range
[18:36] <arwa> I am not sure why is this happening ?
[18:37] <wm4> the _pointer_ is out of range, not the value that you get when dereferencing the pointer
[18:37] <wm4> and accessing it will often appear to work fine, but it's still invalid
[18:37] <wm4> but in this case, apparently it crashed
[18:39] <arwa> The code is here -- " http://pastebin.com/edit.php?i=k4qs1vgu "
[18:40] <arwa> In the init function in this code its giving me seg fault for the value of c at 1st iteration.
[18:42] <arwa> Here the value of c is acting as a pointer, which is accessing the rgbtoyuv value. 
[18:42] <wm4> the link doesn't work
[18:45] <arwa> okay, try this - " http://privatepaste.com/1cb1aa3872 "
[18:49] <wm4> I see nothing too obviously wrong - I'd guess it means you're almost there, but you'll have to debug it yourself
[18:50] <wm4> (also it's not like I have bug-detecting eyes)
[18:50] <wm4> the 64MB rgbtoyuv lookup table it a bit strange though
[18:51] <arwa> What I find strange is I copied this part of the code from hqx filter...!! How can it possibly give me fault?!
[18:52] <wm4> maybe it was written with different assumptions in mind
[18:52] <arwa> yeah probably.
[18:53] <arwa> I will resume looking for the errors, and figure out what is going wrong.
[19:04] <ubitux> arwa: your code needs the AVClass pointer
[19:04] <ubitux> you still haven't read doc/writing_filters.txt
[19:05] <ubitux> mmh actually, my bad, you still don't have any option so it should be fine
[19:06] <ubitux> your code doesn't have a priv_size field
[19:06] <ubitux> in AVFilter
[19:06] <ubitux> so the context is not allocated
[20:07] <cehoyos> reynaldo: FFmpeg was uploaded to experimental 2014-09-16
[20:07] <cehoyos> See https://packages.qa.debian.org/f/ffmpeg.html
[20:10] <reynaldo> cehoyos: cool, thanks a lot pal
[20:13] <cehoyos> You are welcome!
[20:21] <arwa> ummm....so, what should I do?
[20:21] <ubitux> look at priv_size in hqx
[20:25] <ubitux> https://www.indiegogo.com/projects/mox-file-format wut
[20:25] <ubitux> > MOX is going to use the MXF container (SMPTE 377M)
[20:26] <ubitux> > Video formats will be Dirac, OpenEXR, DPX, PNG, and JPEG.
[20:26] <ubitux> :/
[20:28] <nevcairiel> sounds like someone with no ties to the actual open source media world came up with those
[20:28] <ubitux> i see opus though
[20:29] <nevcairiel> his history seems to be taking opensource stuff and plugging it in closed source software, not any actual experience with crazy format details of mxf <.<
[20:30] <wm4> "MOX will read and play consistently on Mac, Windows, Linux, or any other platform. This is because MOX will be an open format based on open standards. It will include an open source C++ library to ensure that any program will be able to easily support MOX files now and forever."
[20:31] <bencoh> meh
[20:31] <wm4> how do they even get money
[20:31] <nevcairiel> so, he wants to implement a new library that reads and decodes all of this? :D
[20:31] <bencoh> "yeah, sure, whateverbullshit"
[20:31] <wm4> it's like I'm missing a simple trick to get rich here
[20:32] <nevcairiel> in  $20.000 no less?
[20:32] <nevcairiel> well good luck!
[21:01] Action: Compn sets mode +b irccloud.com ...
[21:16] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:3b20ed85489a: avcodec/sgidec: fix linesize for 16bit
[21:16] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:a050cf0c451b: avcodec/sgidec: fix count check
[21:35] <gnafu> wm4: "Open source media software developers hate him!  Find out this one crazy trick to get $20,000 like that!"
[21:38] <J_Darnley> I was tempted to post that xkcd comic into that email thread.
[21:45] <cone-536> ffmpeg.git 03Luca Barbato 07master:a6674d2e7771: xcbgrab: XCB-based screen capture
[21:45] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:a38a1d516fe6: Merge commit 'a6674d2e7771dbf7a4a5556f5e126be83cadac96'
[22:25] <cone-536> ffmpeg.git 03Vittorio Giovara 07master:090c67d586e3: matroskaenc: write correct Display{Width, Height} in stereo encoding
[22:25] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:f769671f86ed: Merge commit '090c67d586e3916f9acc49e010b6389d07f97153'
[23:04] <cone-536> ffmpeg.git 03Vittorio Giovara 07master:b46b233baffc: filmstripdec: avoid integer overflow
[23:04] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:76b9043e903c: Merge commit 'b46b233baffc2076a1a17a264ba9553ae0d4878f'
[23:04] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:9612dcd6b24f: avformat/filmstripdec: Fix several integer overflows
[23:33] <cone-536> ffmpeg.git 03Vittorio Giovara 07master:e6c66f1e4ea1: bethsoftvid: check return value and clean memory
[23:33] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:5ee6527c4386: Merge commit 'e6c66f1e4ea19a3aa6ed999c5cb92e1b682c7600'
[23:33] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:0894b9405c0c: avformat/bethsoftvid: print error in case the side date failed to be allocated
[23:49] <cone-536> ffmpeg.git 03Tomas Härdin 07master:11467ecf5197: mxfdec: reduce loop bound in mxf_read_pixel_layout()
[23:49] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:d4e8cc35b3d9: Merge commit '11467ecf519788f2e2f49c63a17eb600e618489e'
[00:00] --- Tue Oct 28 2014