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

[burek]

[00:38] <Compn> Daemon404 : what is this http://www.youtube.com/watch?v=D78FXnQX-yM
[00:38] <Compn> Sora No Otoshimono Forte Opening HD
[00:41] <Compn> can we still laugh at horrible anime or is that racist now ?
[00:42] <JEEBsv> it's always ok to laugh at horrible anime
[00:44] <JEEBsv> I think the best part of Sora no Otoshimono was that one ending where panties flew around the world >_>
[01:12] <iive> Compn: i think it is time japanese to remove the ban on porn.
[01:23] <Daemon404> what did i just watch
[01:49] <ubitux> Sora No Otoshimono is pretty awesome :)
[01:49] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * rb4bccf3e4e 10ffmpeg/libavcodec/wmadec.c: 
[01:49] <CIA-17> ffmpeg: wma: fix off-by-one in array bounds check.
[01:49] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:49] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[01:49] <CIA-17> ffmpeg: 03Martin Storsjö 07master * r94f1b11a6f 10ffmpeg/libavformat/rtpenc.c: 
[01:49] <CIA-17> ffmpeg: rtpenc: Fix the AVRational used for av_rescale_q_rnd
[01:49] <CIA-17> ffmpeg: The current one has a zero denominator - this is what was
[01:49] <CIA-17> ffmpeg: intended in 14aecc50fae6.
[01:49] <CIA-17> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[01:49] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r4c25269ced 10ffmpeg/libavcodec/pngdec.c: 
[01:49] <CIA-17> ffmpeg: png: convert to bytestream2 API.
[01:49] <CIA-17> ffmpeg: Protects against overreads in the input buffer.
[01:49] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:49] <CIA-17> ffmpeg: CC: libav-stable at libav.org
[01:49] <CIA-17> ffmpeg: 03Kostya Shishkov 07master * r681e726865 10ffmpeg/libavcodec/dca.c: dca: include libavutil/mathematics.h for possibly missing M_SQRT1_2
[01:49] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r4ffe5e2aa5 10ffmpeg/libavcodec/huffyuv.c: (log message trimmed)
[01:49] <CIA-17> ffmpeg: huffyuv: add padding to classic (v1) huffman tables.
[01:49] <CIA-17> ffmpeg: We slightly overread the input buffer, so we require
[01:49] <CIA-17> ffmpeg: padding at the end of the buffer, as is documented in the
[01:49] <CIA-17> ffmpeg: get_bits API. Without padding, we'll read uninitialized
[01:49] <CIA-17> ffmpeg: data or beyond the end of the .rodata, which may crash.
[01:49] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:49] <CIA-17> ffmpeg: 03Dale Curtis 07master * ref0d779706 10ffmpeg/libavformat/oggdec.c: (log message trimmed)
[01:49] <ubitux> Compn: it's one of the rare animes with a lot of different op & endings
[01:50] <ubitux> i only saw the first season, but this was really a great one actually
[01:50] <ubitux> it also started quite a meme around the flying panties& :)
[01:50] <ubitux> (ppl started to make flying panties and stuff&)
[01:51] <ubitux> anyway, 'night :)
[02:09] <CIA-17> ffmpeg: 03Piotr Bandurski 07master * r520cf05338 10ffmpeg/libavcodec/svq1dec.c: 
[02:09] <CIA-17> ffmpeg: svq1dec: use AV_LOG_ERROR for error message
[02:09] <CIA-17> ffmpeg: Reviewed-by: Paul B Mahol <onemda at gmail.com>
[02:09] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:09] <CIA-17> ffmpeg: 03Piotr Bandurski 07master * raf55a9d80a 10ffmpeg/ (libavcodec/iff.c libavformat/iff.c): 
[02:09] <CIA-17> ffmpeg: iff: add support for IFF DEEP
[02:09] <CIA-17> ffmpeg: Fixes trac #1045.
[02:09] <CIA-17> ffmpeg: Thanks to Peter Ross for his help with this patch.
[02:09] <CIA-17> ffmpeg: Reviewed-by: Paul B Mahol <onemda at gmail.com>
[02:09] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:12] <bcoudurier> oh it's we have 2 seasons of it on hulu
[06:34] <puffin444> Hello
[09:23] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * r19e72e0a8d 10ffmpeg/libavcodec/sunrast.c: 
[09:23] <CIA-17> ffmpeg: Fix 32bit sunrast decoding.
[09:23] <CIA-17> ffmpeg: This patch visually breaks the sample from ticket #895,
[09:23] <CIA-17> ffmpeg: but decodes it identically as Gimp, ImageMagick and xview.
[14:35] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * rd07de6d75d 10ffmpeg/libavformat/mpegts.c: Cosmetics: Remove superfluous newline.
[15:55] <LeeZhang> I am using ffmpeg API to develop a transcoding project. Right now I can transcode mpeg2 ts stream to AVI, MP4 or MKV local files. However, when I want to transcoding it to H.264/aac and put them into a TS container, the video can not be played whle the audio is perfect. I got the log information from ffmpeg "H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb)".
[15:56] <LeeZhang> So 
[15:56] <LeeZhang> So I initiated the h264_mp4toannexb bitstreamfilter and use av_bitstream_filter_filter to process the packet before write them to output file. However, av_bitstream_filter_filter returns 0 and the final output file still the same situation and the warning information still happen.
[15:57] <LeeZhang> When I used the Elecard Stream Analyzer to check my transcoded file, I found the file missed SPS and SEI information for the video stream. There is only SPS and SEI information for audio stream.  I do not know why the TS container can not produce these information for me.  
[15:57] <LeeZhang> There is another log information about DTS, it only happen every 29 frames. That is so strange.  Please help me.  I used the latest version of ffmpeg. 
[15:58] <LeeZhang> ffmpeg version git-2012-03-09-d07de6d Copyright (c) 2000-2012 the FFmpeg developers built on Mar  9 2012 14:57:55 with gcc 4.5.2 configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree --enable-version3 --enable-x11grab --enable-shared
[15:58] <LeeZhang>  libavutl      51. 42.100 / 51.  42.100 libavcodec     54. 10.100 / 54. 10.100 libavformat    54.  2.100 / 54.  2.100 libavdevice    53.  4.100 / 53.  4.100 libavfilter     2. 63.100 /  2. 63.100 libswscale      2.  1.100 /  2.  1.100 libswresample   0.  7.100 /  0.  7.100 libpostproc    52.  0.100 / 52.  0.100
[16:11] <Compn> anyone remember the login info to access incoming on j-b's server >
[16:11] <Compn> ?
[16:11] <Compn> and can share it with me ?
[16:12] <Compn> bcoudurier / bcoudu ? michaelni ? 
[16:12] <Compn> saste ?
[16:29] <saste> Compn: no idea
[16:29] <saste> i don't even know what server you're referring to
[16:32] <Compn> ftp://upload.ffmpeg.org/incoming
[16:33] <Compn> which is accessible from http somehow...
[16:33] <Compn> http://streams.videolan.org/incoming/
[16:33] <Compn> ok got the login info
[16:33] <Compn> thanks ubitux :)(
[16:34] <ubitux> np
[16:34] <ubitux> it's impressive how i'm able to remember such info after seeing it a few seconds months ago, and forget a bunch of more important ones i hear regulary
[16:35] <Compn> yeah, i recognize it after you told me
[16:35] <Compn> but memorized too many passwords to recall it on its own
[16:35] <Compn> :D
[16:35] Action: Compn memorizes other peoples passwords too ;\
[16:35] <Compn> stupid memory
[16:35] <ubitux> :(
[16:36] <ubitux> not reliable at all, and slower than a 5400rpm hard drive
[16:36] <Compn> urgh
[16:36] <Compn> vlc shares the incoming dir :P
[16:37] <ubitux> no one use iwmmxt stuff?
[16:37] <ubitux> it seems libav is dropping that
[16:38] <Compn> i forgot what that is
[16:38] <Compn> cpu instruction ?
[16:38] <ubitux> https://lists.libav.org/pipermail/libav-devel/2012-March/023784.html
[16:41] <Compn> the problem with getting rid of something because it broke 2 years ago is that some of these platforms dont update ffmpeg every year ...
[16:41] <Compn> so yeah , you remove it and then find out in a few months how they used XXX feature , but hadnt needed to upgrade :D
[16:42] <ubitux> "we didn't upgrade ffmpeg because compilation was broken (in iwmmxt), but didn't report it, and now we really need to upgrade"
[16:42] <ubitux> this is what i'm afraid of
[16:42] <ubitux> or "we disabled the optim because build was broken with it"
[16:44] <Compn> right lol
[16:48] <Compn> ehe
[16:49] <Compn> videolan uploaders want g2m4 codec  :)
[16:50] <j-b> Compn: no shit?
[16:58] <Compn> j-b : should i make a proposal on ffmpeg soc to make a decoder for it ? :)
[16:58] <j-b> I think Maxim is on it
[16:58] <j-b> but yes
[16:58] <j-b> we have offered 1000EUR to FFmtech to support this project, IIRC.
[16:59] <Compn> strange they didnt make an announcement about that ...
[17:00] <Compn> ooh good idea , ffmpeg.org have a bounties page
[17:00] <Compn> well maybe just stick it on news page
[17:02] <Compn> j-b : is that offer still good, can i post it to ffmpeg news page ?
[17:02] <j-b> Compn: no. See with the foundation
[17:02] <Compn> or maybe i should ask maxim ...
[17:02] <j-b> yes
[17:03] <Compn> did you get the binary decoder working in win32 videolan ?
[17:03] <j-b> a long time ago
[17:03] <j-b> I never pushed the patch
[17:03] <j-b> and I won't
[17:03] <j-b> binary decoders are a shame
[17:04] <Compn> reverse engineer breeding program
[17:04] <Compn> :D
[17:07] <Compn> hopefully my dumb questions havent annoyed you :)
[17:10] <j-b> no
[17:25] <ubitux> saste: can't we reduce the amount of allocation done in lavfi?
[17:25] <ubitux> for each frame, there is a lot of heap allocations and copy
[18:11] <codevomit> working on a project that requires streaming to the interenet whilst simultaniousely recording to hard disk, we noticed when the connection became slow it caused a bottle neck in data and the video was being recorded to the harddisk at the slow speed of the internet connection until it died, loosing video before it could be recorded to hard disk
[18:12] <codevomit> is there any way to uses a buffered output streams so that does not occure?
[18:14] <merbanan> codevomit: can you elaborate ?
[18:14] <codevomit> which part do you want me to elaborate on?
[18:18] <merbanan> everything, what you say doesn't make any sense to me
[18:24] <Compn> codevomit : are you using ffmpeg itself or tying together with libavcodec/libavformat ?
[18:25] <Compn> i mean, is this your program calling ffmpeg, or are you writing something that uses the internal libs ?
[18:26] <Compn> codevomit : when you say 'when the connection became slow it caused a bottle neck in data and the video was being recorded ... died' , it sounds like you had a network timeout and the connection was lost.
[18:26] <Compn> also it would be useful to know which transport you are using, be it tcp, udp, rtsp, http, ftp, rtmp etc
[18:27] <Compn> codevomit : you mean, when the outbound stream was limited, that the recording of data to the harddrive slowed ?
[18:27] <codevomit> we're using ffmpeg wrapped in swig, calling the main function, the protocal is rtsp, ffmpeg starts buffering a load of video to the point of it crashing causing us to lose video
[18:28] <codevomit> yup compn, that's exactly what i mean :)
[18:28] <Compn> is it possible just to use two different processes, one to record and one to stream ?
[18:30] <Compn> and to fix the problem, its easier for us if we are able to reproduce it somehow. on a stream, with an example command line if you are using one
[18:30] <codevomit> our input is comming from a directshow device, we also plan to put jni callbacks in ffmpeg.c so that we can get a preview image
[18:30] <Compn> or if you have a patch to fix it, or know where the bug is exactly...
[18:31] <Compn> cool :)
[18:31] <Compn> videolan has this ability to play / record / stream at the same time 
[18:33] <codevomit> we've got modification we need which we've done in ffmpeg
[18:35] <codevomit> is there a way to give each output stream it's individual buffer?
[18:36] <codevomit> *an individual
[18:36] <Compn> i have no idea, i just help users make better bugreports ;)
[18:36] <Compn> better ask merbanan if hes still around
[18:40] <codevomit> cheers for help compn
[19:54] <michaelni> ubitux, Tjoppen, theres a ping for a timecode patch on ffmpeg-dev from Matthieu Bouron
[20:01] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rad53c7f9ec 10ffmpeg/ (4 files in 4 dirs): 
[20:01] <CIA-17> ffmpeg: lavf: Add system to seperate relative timestamps from absolute ones.
[20:01] <CIA-17> ffmpeg: With this we can always know if a timestamp is based on added durations
[20:01] <CIA-17> ffmpeg: from an unknown origin or if it is based on a correct timestamp (and possibly
[20:01] <CIA-17> ffmpeg: added durations)
[20:01] <CIA-17> ffmpeg: This should fix some bugs where this distinction was mixed up.
[20:01] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:26] <Freshness> hi, if anyone knows or wants to help out with codevomit's question earlier, i'm his co-worker and I'd also appreciate the help
[21:29] <funman> 12:35 < codevomit> is there a way to give each output stream it's individual  buffer?
[21:29] <kierank> yes
[21:29] <kierank> use get_buffer
[21:29] <funman> i think you can provide your own functions
[21:29] <kierank> (not documented well regrettably)
[21:30] <Freshness> get_buffer eh? hmm i'll have to look at that one
[21:30] <Freshness> to be more clear on his original point, we are trying to use one input from a directshow device, and send two output FLV streams, one right to hard drive and one via RTSP to a remote server
[21:31] <kierank> http://git.mansr.com/?p=omapfbplay;a=blob;f=avcodec.c;h=7418643eec5f18714d97553b6b1089184c1b0f30;hb=d03f042ecac0a231bedeadc7a6c67f0102d5505a
[21:31] <kierank> oh output stream
[21:31] <kierank> that's different
[21:31] <kierank> never mind
[21:31] <Freshness> the problem is that the hard drive copy is supposed to be a failsafe for when the internet connection drops out
[21:31] <Freshness> but as far as we can tell when one output stream fails, the whole ffmpeg process dies
[21:31] <kierank> supplying user buffers for output streams is avio's job
[21:32] <Freshness> we've been looking to isolate each output but my co-worker was wondering if there was any prior work in that area
[21:32] <Freshness> our thoughts going in the direction of running each output as a separate thread with their own buffers
[21:33] <Freshness> so we could handle problems from the rtsp output while not affecting the hard drive output at all and letting that just merrily chew on the directshow input
[21:34] <Freshness> as far as we can tell there's nothing to support that in the design?
[21:34] <kierank> there is a way
[21:34] <kierank> avio
[21:36] <Freshness> i really need to look at what he's been doing so far, i just know what he's attempting and my experience so far has been limited to developing libavdevice
[21:37] <Freshness> well, for private use of course because i'm a terrible c coder
[21:37] <Freshness> :[
[21:38] <Freshness> kierank, what do you mean about avio
[21:38] <Freshness> i just had a look at the reference, i've used this before for a small extra protocol module
[21:38] <kierank> avio is the system used for output streams
[21:39] <Freshness> should he interface with this directly rather than use ffmpeg directly?
[21:39] <funman> http://git.videolan.org/?p=vlc.git;a=blob;f=modules/access/avio.c;h=ddfe86fc31c93962d22ec66281c7798f70a0152e;hb=HEAD
[21:39] <funman> this file uses avio for both input and output
[21:40] <wbs> Freshness: sure you talk about rtsp, sure it's not rtmp? you can't write "flv" to rtsp, but you do write it over rtmp
[21:40] <Freshness> ohh, I see where you're going
[21:40] <funman> and can be instanciated several times in one process (provided you have newer than 0.10 i think)
[21:40] <Freshness> wbs: duh, yes you're right, I mean rtmp
[21:41] <Freshness> we're going off bleeding edge so that will work i think
[21:43] <Freshness> yeah that will probably work out well for us
[21:43] <Freshness> thanks to all
[22:10] <ubitux> michaelni: yes i saw the patch from mateo` about mxf, i reviewed what i could already (timecode api usage), i can't comment much more on it
[22:14] <michaelni> ubitux, thx
[22:15] <durandal_1707> michaelni: can you check that frame mt decoding for dnxd/utvideo works as expected?
[22:16] <michaelni> durandal_1707, ill take a look later
[22:22] <cbsrobot> Tjoppen: it seems these files do not get recognized as been dnxhd files in mxf: http://dnxhd.gridtank.com/
[22:23] <cbsrobot> a propos dnxhd or the dnxhd_unquantize_c function
[22:23] <Daemon404> cbsrobot, btw... do you work for cbs?
[22:24] <cbsrobot> I'm comparing ffmbc dnxhd with ffmpeg dnxhd and there is a subtle difference
[22:24] <cbsrobot> Daemon404: of course :-D
[22:25] <cbsrobot> cbs like cybernetic broadcasting systems
[22:25] <Daemon404> o
[22:25] <Daemon404> lol
[22:27] <cbsrobot> so in dnxhd_unquantize_c from ffmbc there is a j = ctx->intra_scantable.permutated[i]; and j is used to call the weight_matrix[j]
[22:27] <cbsrobot> in ffmpeg it uses weight_matrix[i] 
[22:28] <funman> Daemon404: doesn't mru work in london?
[22:28] <Daemon404> funman, yes. but WFH
[22:33] <cbsrobot> bcoudurier: ^ you might be interested
[22:57] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r174678ff5b 10ffmpeg/libavformat/mpegvideodec.c: 
[22:57] <CIA-17> ffmpeg: mpegvideo_probe: Fix misdetection of mpeg4video files.
[22:57] <CIA-17> ffmpeg: (issue1210)
[22:57] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:03] <michaelni> durandal_1707, what exactly should i check ?
[23:05] <durandal_1707> michaelni: that it takes less time for decoding when multiple threads are used to decode on mulicore cpu
[23:10] <michaelni> moment, i first need to create a longer dnxhd file, the reg test one is too short
[23:16] <michaelni> durandal_1707, seems dnxhd decodes around 20% faster with 8 threads than 1 (thats on my busy i5)
[23:17] <michaelni> also 8 threads seem faster than 4
[23:19] <durandal_1707> ok then
[00:00] --- Sat Mar 10 2012