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

[burek]

[00:00] <ubitux> there are more stuff in the previous posts iirc
[00:00] <ubitux> the 3 previous ones seem to be about that
[00:01] <CIA-41> ffmpeg: 03Clément BSsch 07master * rad55244c96 10ffmpeg/libavfilter/vf_overlay.c: lavfi/overlay: remove dead initialization.
[00:01] <CIA-41> ffmpeg: 03Clément BSsch 07master * r16dc5f2050 10ffmpeg/ (10 files in 4 dirs): Replace various inlined inverse AVRational with av_inv_q().
[00:04] <durandal_1707> note that 0RGB is used in patch....
[00:09] <CIA-41> ffmpeg: 03Piotr Bandurski 07master * r1b72a7e8a9 10ffmpeg/libavformat/aiffenc.c: aiffenc: fix remuxing of qdm2
[00:21] <Daemon404> [17:53] <+durandal_1707> and kostya is almost begging that it get info ffmpeg
[00:21] <Daemon404> ^ go2meeting has a metric shitload of users
[00:22] <Daemon404> vlc sees tons
[00:22] <Daemon404> we see tons uploaded at vimeo too
[00:22] <Daemon404> assuming it isnt a troll.
[00:22] <j-b> we have a shitload of this codec
[00:23] <j-b> no idea why
[00:23] <Daemon404> yeah so do we
[00:23] <Daemon404> no idea why :P
[00:38] <CIA-41> ffmpeg: 03Piotr Bandurski 07master * r68f4156f44 10ffmpeg/libavformat/movenc.c: movenv: fix remuxing of qdm2
[00:46] <durandal_1707> Daemon404: so you want this patch into ffmpeg?
[00:50] <iive> if it is so hard to RE the real codec, is that patch real at all or just troll.
[00:51] <iive> btw what is the bounty for g2m codecs?
[00:52] <durandal_1707> j-b is out of money
[00:53] <llogan> ubitux: stefano mentioned that he doesn't want tickets assigned to him (see 1492).
[00:53] <ubitux> llogan: it was done automatically when i selected the documentation category
[00:53] <llogan> ah. I was wondering about that.
[00:55] <Compn> i wonder if that gotomeeting patch was rejected for some reason in libav
[00:55] <Compn> but could be accepted into ffmpeg :P
[00:56] <llogan> what's libav?
[00:56] <durandal_1707> Compn: seriously, look at patch
[00:56] <Compn> by j-b ?
[00:56] <durandal_1707> llogan: it is "upstream" fork where real "work" happens
[00:58] <Compn> patch is missing riff entry anyhow
[00:58] <Compn> :P
[01:00] <Compn> Daemon404 : are you using mplayer binary codec to decode them ? :P
[01:00] <Compn> at vimeo
[01:00] <Compn> if not, why not?
[01:03] <Compn> durandal_1707 : i am no programmer, i cant tell whats wrong with code ...
[01:03] <durandal_1707> Compn: it is only 321 lines
[01:03] <durandal_1707> vaporware
[01:04] <Compn> did you compile it ?
[01:04] <Compn> :p
[01:04] <durandal_1707> enotime
[01:05] <Compn> zerocodec decoder is only 130 lines 
[01:05] <Compn> :P
[01:05] <Compn> of course, decoder complexity does not match up with previous RE blog entries talking about compression features
[01:06] <Compn> i wonder if it outputs a message like 'g2m stinks' or 'france isnt very nice'
[01:06] <Compn> ehe
[01:07] <Compn> could just /q kshishkov i guess
[01:07] <Compn> oh the g2m are already in riff.c nm
[01:07] <durandal_1707> it just sets all pixels to 0x004294CF
[01:10] <durandal_1707> and looks like put cursor too...
[01:14] <kierank> i would speculate it produces a tricolor
[01:14] <Compn> ehe
[01:15] <Compn> i wonder if kostya made it because of my previous comment
[01:15] <Compn> 'let those french guys RE their own codecs'
[01:15] <iive> Compn: you are french now?
[01:15] <durandal_1707> the version check for libmp3lame is pointless - it does not work
[01:15] <Compn> iive : no, but copyright on that patch is to j-b :P
[01:17] <iive> Maybe we should ask j-b to commit it, but also add av_log with something like "special thanks to kostya for RE this codec". I guess that would be meta trolling. ;)
[01:20] <Compn> maybe we should just email gotomeeting and see if they'll give us some decoder code :P
[01:25] <iive> this is too obvious :P
[01:36] <CIA-41> ffmpeg: 03Paul B Mahol 07master * r958df52ae0 10ffmpeg/configure: 
[01:36] <CIA-41> ffmpeg: configure: make libtwolame check more robust
[01:36] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[01:46] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * re4b53d995c 10ffmpeg/libavformat/mov.c: 
[01:46] <CIA-41> ffmpeg: mov: dont clip timestamps at 0
[01:46] <CIA-41> ffmpeg: Fixes Ticket1251
[01:46] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:56] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r7bf16ec300 10ffmpeg/libavformat/mpc8.c: 
[02:56] <CIA-41> ffmpeg: mpc8: fix pts
[02:56] <CIA-41> ffmpeg: Fixes Ticket1254
[02:56] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:28] <durandal_1707> michaelni: i think right fix for mpc8 is to set packet duration
[03:30] <durandal_1707> and packet duration for mpc7 is always same
[03:35] <CIA-41> ffmpeg: 03Paul B Mahol 07master * r9c1619b5fe 10ffmpeg/libavcodec/mpc7.c: 
[03:35] <CIA-41> ffmpeg: mpc7: remove duplicated definitions
[03:35] <CIA-41> ffmpeg: They are available in mpc.h
[03:35] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[03:41] <michaelni> durandal_1707, possible but it might cause issues as all timestamps are then unknown (if only duration is set)
[03:43] <michaelni> lavf can resolve this but it adds more delay
[03:43] <durandal_1707> michaelni: but it have avpriv_set_pts_info
[03:45] <durandal_1707> problem is more evident with -c copy
[03:52] <michaelni> what problem ?
[03:53] <durandal_1707> compare it with flac files....
[03:53] <michaelni> can you please just tell me instead of giving riddles
[03:53] <michaelni> i have many bugs to work on
[03:53] <durandal_1707> no worry, i will work on this and sent it for review
[03:53] <michaelni> ok, thanks
[03:56] <durandal_1707> lol pts is set in such way that duration should be 1....
[03:57] <durandal_1707> avpriv_set_pts_info(st, 32, MPC_FRAME_SIZE, st->codec->sample_rate);
[03:57] <durandal_1707> usually it is set this way:
[03:57] <durandal_1707> avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
[03:57] <durandal_1707> and than pkt->duration have more sense...
[04:19] <durandal_1707> nvm it just not worth changing this ....
[04:50] <durandal_1707> michaelni: when seeking i get strange stuff - does mpc8 misses flush?
[04:51] <durandal_1707> hmm this happens only with mplayer
[09:04] <randomguy123> hello ffmpeg, I tried to use latest git and my impression WTF!? Anybody every tries to run it in debug build (e.g. without NDEBUG enabled?)
[09:06] <randomguy123> I downloaded a video clip (fantastic_four_rise_of_the_silver_surfer-trailer which is h264 high with aac stereo) and I stream it locally using VLC. Then I tried to read that rtp stream using ffmpeg ... and my impression WTF!!! I get asserts all over the place
[09:07] <randomguy123> for example:     assert(s->pict_type == AV_PICTURE_TYPE_I || (s->last_picture_ptr &&
[09:07] <randomguy123>                                                  s->last_picture_ptr->f.data[0]));
[09:07] <randomguy123> inside mpegvideo.c
[09:08] <randomguy123> udp.c code simply crashes on probing (inside udp_close it tries to pthread_mutex_destroy and pthread_cond_destroy uninitialized mutex and cond variables etc).
[09:09] <randomguy123> Even after fixing all this shit I can't simply save rtp stream to local file.
[09:10] <randomguy123> here's the output of epic fail: http://pastebin.com/6n8fEsLe
[09:13] <randomguy123> this message ("increase fifo_size URL option") seems to be pure BS, I tried to add that fifo_size url parameter but while parsing url code always adds fifo_size=0 so it's always 0 anyways. Not sure if I missed something about it...  (rtpproto.c(116):    url_add_option(buf, buf_size, "fifo_size=0");)
[09:15] <randomguy123> Here's how I stream locally with vlc: vlc.exe" -vvv "Fantastic Four - Rise of the Silver Surfer - Trailer.mp4"  :sout=#rtp{sdp=rtsp://localhost:8554/test} :sout-keep --loop
[09:15] <randomguy123> and here's how I try to save it with ffmpeg: ffmpeg.exe -i "rtsp://localhost:8554/test"  -vcodec copy -acodec copy output.mp4
[09:20] <randomguy123> approximately same shit happens with non-debug builds from http://ffmpeg.zeranoe.com: http://pastebin.com/jddcPmhm
[09:20] <randomguy123> anybody can tell if I should try libav instead, or ffmpeg is still the tool to use?
[09:23] <ubitux> randomguy123: do you mind opening a proper bug report on the trac for the assert in mpegvideo.c?
[09:23] <TimNich> ubitux: Just beat me to it...
[09:24] <ubitux> randomguy123: also for the rtp problem, the command line would be interesting; if you could open an issue as well& :)
[09:25] <ubitux> also, are all of these regressions? and if so, what was the last working version you tested?
[09:26] <ubitux> randomguy123: about libav, it's a fork; if you want to try with libav you're obviously free to do it. If those issues are not reproducible with libav, the bug report are even more interesting 
[09:26] <ubitux> randomguy123: and last thing, this is a development channel; so unless you have fixes to discuss, i'd recommand to report bugs on the trac, or use the #ffmpeg user channel
[09:27] <randomguy123> I've never tried to do it. I simply need to write imput module for ffmpeg and rtsp is similar in functionality to what I need to write. So I compiled ffmpeg in debug and stepthrough the code to see what's going on. I didn't do ffmpeg related stuff for a while, but when I used it last time (for programming) it seemed to be more stable
[09:29] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * re6b9903d82 10ffmpeg/libavcodec/shorten.c: 
[09:29] <CIA-41> ffmpeg: shorten: fix cmd type
[09:29] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[09:29] <randomguy123> i can post quick fixes righ here if anybody cares. I don't want to create proper diffs, no offence, a few years ago I create lots of patches spent hours literary creating them and I got some BS in reply and i unsubscribed and never came back.
[09:29] <randomguy123> libavformat/udp.c udp_close: 
[09:30] <randomguy123>     pthread_mutex_destroy(&s->mutex);
[09:30] <randomguy123>     pthread_cond_destroy(&s->cond);
[09:30] <randomguy123> these two should be inside if (s->thread_started) { ... } block, otherwise they are executed on junk data (initizlied to 0).
[09:30] <ubitux> randomguy123: no worry; but most of the time the first step is to allow us to reproduce the issue :p
[09:32] <randomguy123> I use winpthread, that's probably why same code has no problems. But simply probing any udp resource should call that code. Put a breakpoint there and see values of mutex and cond, both are 0.
[09:32] <ubitux> randomguy123: so this would fix the probing on what?
[09:32] <randomguy123> that is, they were inited by default as calloc for extra_data_size
[09:33] <randomguy123> movind these two destroys inside the block makes sure that destroy isn't called on uninitizlized mutex and cond variables.
[09:34] <randomguy123> search that entire file for thread_started, you'll see that only when thread_started is 1 these variables are properly initizlied.
[09:34] <randomguy123> otherwise they aren't good to touch.
[09:36] <randomguy123> here's how to reproduce rtsp problems. http://www.h264info.com/clips.html Download Link: fantastic_four_rise_of_the_silver_surfer-trailer.zip (90 MB)
[09:36] <ubitux> thanks
[09:36] <randomguy123> then stream locally the video with vlc: vlc.exe -vvv "Fantastic Four - Rise of the Silver Surfer - Trailer.mp4"  :sout=#rtp{sdp=rtsp://localhost:8554/test} :sout-keep --loop
[09:37] <randomguy123> then simply try to ffmpeg -i "rtsp://localhost:8554/test"
[09:37] <ubitux> just in case you suddenly disappear or still don't plan to send any patch; to whom the credits should go in the commit?
[09:37] <randomguy123> or better: ffmpeg -i "rtsp://localhost:8554/test" -vcodec copy -acodec copy output.mp4
[09:38] <randomguy123> in case if it's confirmed and proper fixes, put Pavel
[09:39] <ubitux> there is one other Pavel in ffmpeg git history; Pavel Koshevoy
[09:39] <ubitux> if that's not you, any extra name? :)
[09:39] <randomguy123> there is another one as well, years ago, full git has me there a few time
[09:40] <ubitux> oh Pavel Pavlov then
[09:40] <ubitux> ok
[09:40] <randomguy123> some pretty useless patches were committed
[09:40] <randomguy123> yes
[09:42] <ubitux> the ffmpeg command seems to work for me
[09:42] <ubitux> valgrind doesn't detect any problem
[09:43] <ubitux> but i might not have the same threading configuration since i'm on *nix
[09:48] <randomguy123> it's very possible that pthread_mutex_destroy on unix check for 0 pointers, or it simply might use different code. The docs don't mention if it's safe to destroy uninitialized mutex, I assume it's not safe to do so.
[09:48] <ubitux> i have HAVE_PTHREAD_CANCEL set, and mutex/cond destroyed are called without entering in the thread started block
[09:48] <ubitux> randomguy123: ok
[09:49] <randomguy123> me to, I have pthread_cancel available. I use win-pthread official pthread windows port.
[09:49] <ubitux> yeah
[09:49] <ubitux> it looks right anyway to put them in the block
[09:49] <ubitux> give me a minute i'll send a patch at your name
[09:50] <randomguy123> just don't put that old email there.
[09:50] <ubitux> then maybe give me a valid one, or send it yourself :)
[09:51] <randomguy123> commit from ur email, and simply mention my name without email, that's all
[09:52] <ubitux> i'd prefer not :)
[09:52] <ubitux> i'd rather google your name to find your email
[09:52] <ubitux> you have to take responsability ;)
[09:52] <randomguy123> why not?? :) ah
[09:53] <randomguy123> ok, there's a reason why. I don't want my emplyer to see that I'm messing with open source stuff :)
[09:54] <ubitux> i can wait for non-working hours to send the patch if that's the issue
[09:54] <ubitux> i don't mind to send it anonymous though
[09:55] <randomguy123> it's non working now, just send anonymous, please!
[09:55] <ubitux> ok ok
[09:56] <randomguy123> another thing with reading rtsp. inside udp.c udp_open(...) on line 523 or so:
[09:56] <randomguy123> s->circular_buffer_size = strtol(buf, NULL, 10)*188;
[09:56] <randomguy123> add this log for testing: av_log(h, AV_LOG_WARNING, "uri: '%s'; s->circular_buffer_size:%d\n", uri, s->circular_buffer_size);
[09:57] <randomguy123> no matter what I try it's always going to use circular_buffer_size = 0
[09:57] <randomguy123> this is what I get in the log:
[09:57] <randomguy123> [udp @ 026CF410] uri: 'udp://[::1]?localport=8078&fifo_size=0'; s->circular_buffer_size:0
[09:57] <randomguy123> [udp @ 026CF4B0] uri: 'udp://[::1]:0?localport=8079&fifo_size=0'; s->circular_buffer_size:0
[09:57] <randomguy123> [udp @ 0216D390] uri: 'udp://[::1]?localport=8080&fifo_size=0'; s->circular_buffer_size:0
[09:57] <randomguy123> [udp @ 0217D540] uri: 'udp://[::1]:0?localport=8081&fifo_size=0'; s->circular_buffer_size:0
[09:59] <ubitux> first UDP patch is in my queue, 'will submit later (i'm actually at work too and not really supposed to do that)
[10:00] <randomguy123> the other issue is that fifo_size=0 is always there and I'm not sure how to avoid that. I tried to simply hadcode some value but in that case I really get bad results.
[10:01] <randomguy123> basicaly, when I dump to output.mp4 I get somewhat broken video. because of multiple: 
[10:02] <randomguy123> [NULL @ 00CEC370] RTP: missed 2 packets
[10:02] <randomguy123> [NULL @ 00CEC370] RTP: missed 1 packets
[10:02] <randomguy123> ...
[10:03] <michaelni> the fifo=0 is there because rtsp bypasses normal API and accesses udp through ffurl_get_file_handle()
[10:03] <randomguy123> the windows builds from zeranoe.com produce the same broken output result, though it didn't crash inside pthreads (perhaps it uses winthreads?)
[10:03] <michaelni> thats a long standing design flaw IIRC
[10:04] <ubitux> http://pastie.org/private/ifqql4v4tf4swtdo9socw  randomguy123 is that fine with you?
[10:04] <randomguy123> yes, that's how i did it.
[10:04] <ubitux> michaelni: can i push that?
[10:05] <ubitux> (sorry i'm skipping proper ml review :p)
[10:05] <michaelni> ubitux, LGTM
[10:05] <ubitux> thank you :)
[10:06] <randomguy123> michael: when I tried to put some code to avoid that fifo=0 the problem become even worse.
[10:06] <CIA-41> ffmpeg: 03anonymous 07master * r388243bb27 10ffmpeg/libavformat/udp.c: 
[10:06] <CIA-41> ffmpeg: udp: do not call pthread_{mutex,cond}_destroy when not initialized.
[10:06] <CIA-41> ffmpeg: This seems to cause a crash on Windows.
[10:06] <CIA-41> ffmpeg: The author of that patch was a random guy on IRC who wants to stay anonymous.
[10:07] <ubitux> randomguy123: how can we reproduce the mpegvideo.c assert with that same video clip?
[10:07] <randomguy123> I thought that I get these [h264 @ 00DA5BC0] RTP: missed %d packets because thread can't keep up with the incoming data and with a queue it should be fixed
[10:08] <ubitux> was that because of some udp corrupted packet?
[10:08] <randomguy123> but, I put a kludge and set circular_buffer_size to a few megs I get hudreds of missed RTP packets like this:
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 71 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 1 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 3 packets
[10:08] <randomguy123>     Last message repeated 1 times
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 105 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 24 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] top block unavailable for reque
[10:08] <randomguy123> [h264 @ 00DA5BC0] error while decoding MB 28 0, b
[10:08] <randomguy123> [h264 @ 00DA5BC0] concealing 2720 DC, 2720 AC, 27
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 168 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 71 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 43 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 11 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 101 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 63 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 104 packets
[10:08] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 54 packets
[10:08] <ubitux> please pastebin :(
[10:09] <randomguy123> [h264 @ 00DA5BC0] RTP: missed 150 packets
[10:10] <randomguy123> sorry, wanted to copypasta only a couple of lines.
[10:11] <randomguy123> the mpegvideo assert happens for me almost always. in the same setup. All I need to do is: ffmpeg.exe -i "rtsp://localhost:8554/test"
[10:12] <randomguy123> Also, it seems that I'm getting this assert: assert((put_bits_ptr(&s->pb) == s->pb.buf)); inside mpegvideo_enc.c
[10:13] <ubitux> ah got it with debug
[10:13] <randomguy123> it's ff_MPV_encode_picture function. It happened when I tried to run make fate. Obviously I compiled without -DNDEBUG
[10:14] <randomguy123> and one more thing. I'm getting problems with make fate (I don't have full samples three).
[10:14] <ubitux> (what are your compile flags?)
[10:14] <randomguy123> after todays update I started to have this problem: TEST    lavf-dv_fmt
[10:15] <ubitux> there is no such problem detected on fate
[10:15] <randomguy123> actually I use intel compiler on windows, but I get the same problems with mingw build: ../configure --enable-gpl --prefix=install && make fate
[10:15] <ubitux> maybe there is a sample dependency issue
[10:16] <ubitux> michaelni: should i open an issue for the assert() in mpegvideo.c or you're looking at it?
[10:16] <randomguy123> there was a week or some that issue that one fate test was included which was supposed to be disabled. But in that case of DV there is no issue, it's all 
[10:16] <ubitux> < randomguy123> Also, it seems that I'm getting this assert: assert((put_bits_ptr(&s->pb) == s->pb.buf)); inside mpegvideo_enc.c // how do you trigger this one?
[10:17] <randomguy123> make fate with debug build.
[10:17] <randomguy123> I had it some time ago and commented it out.
[10:17] <ubitux> debug build ’ what options?
[10:18] <randomguy123> try maybe --enable-debug? or --extra-cflags'-UNDEBUG"
[10:18] <ubitux> i'm going to add a fate instance for this, so just give me the one you did :)
[10:18] <ubitux> --enable-debug or extra cflags one? :D
[10:19] <michaelni> ubitux, ill look at the assert but iam sleeping currently
[10:19] <ubitux> ok ok :)
[10:21] <randomguy123> I tried to look around, I don't see where -DNDEBUG gets added. I'll enable that assert and try to run the make fate
[10:22] <ubitux> i have a fate box with -DDEBUG, but build only, no run test
[10:22] <ubitux> maybe i should change that
[10:26] <ubitux> ok great it triggers the problem
[10:26] <ubitux> i'm going to enable the tests
[10:26] <ubitux> so we won't forget those assert
[10:26] <ubitux> tests enabled, will fail soon :)
[10:27] <randomguy123> by the way, mingw build fails some other tests as well. cygwin build passes more tests. BUT, even cygwin fails the dv_fmt test
[10:28] <randomguy123> mingw fails basic parsing tests because of crippled libc that comes with ms compiler. strtod is the issue and sscanf
[10:28] <ubitux> the cygwin box hasn't reported anything since a few days on http://fate.ffmpeg.org/
[10:29] <ubitux> but the dv test was passing
[10:29] <randomguy123> that's surprising, I checked the fate ... I didn't do anything special, regular build
[10:30] <ubitux> mingw tests have issues with the amix only according to fate
[10:30] <ubitux> (btw, thanks for those reports)
[10:30] <randomguy123> i have latest mingw builds (gcc 4.7), 4.5.3 on cygwin
[10:30] <ubitux> if you want to add some fate instances that would be welcome
[10:31] <randomguy123> what do you mean to add?
[10:31] <randomguy123> add fate tests or fixes for them?
[10:31] <ubitux> add a dedicated cygwin/mingw box running fate and reporting results
[10:32] <ubitux> that is, http://ffmpeg.org/fate.html#Submitting-the-results-to-the-FFmpeg-result-aggregation-server
[10:32] <randomguy123> ah, ok, I got what you meant
[10:37] <randomguy123> I try to make make fate from clean git on cygwin.
[10:37] <randomguy123> in a few mins
[10:43] <randomguy123> it doesn't even build on cygwin. After fixing usual lineendings I got this error: /cygdrive/c/work/summit-components/H264/ffmpeg-all/ffmpeg-bs/ffmpeg-vlc-git/library.mak:95: *** missing separator.  Stop.
[10:44] <ubitux> this is a problem with the git clone doing crlf
[10:44] <ubitux> there is a config for that
[10:44] <ubitux> just a sec
[10:44] <randomguy123> not sure why, the copy that I modified doesn't have changes in that library.mk file. Something else breaks the build. I use local gitattributes
[10:45] <ubitux> git config --global core.autocrlf false
[10:45] <ubitux> try another clone with that
[10:51] <randomguy123> by the way, --enable-shared and then make fate on mingw. It doesn't work because dlls are located in their own folders and ffmpeg.exe won't start.
[10:57] <ubitux> no idea how that's supposed to be solved on mingw
[10:57] <ubitux> on nix i set a rpath parameter for that
[11:00] <randomguy123> ubitux: clean git on cygiwn -> make fate is OK. I must have screwed up something and dv_fmt fails. Will check later on. rpath: On mingw I copy them manually :) it probably makes sense that fate should depend on install in that case there are no isssues. If I recall correctly that's how it used to work long time ago when it was make test... i might be wrong though.
[11:00] <ubitux> no idea
[11:00] <ubitux> maybe playing with --prefix would do the trick
[11:00] <ubitux> as if you were going to install it in the current directory or something
[11:01] <randomguy123> yes, that's what I'll be using probably later on.
[11:01] <randomguy123>  anyways, i'm done for today, thanks for listening, I'm off
[11:01] <ubitux> thanks for the contrib
[11:01] <ubitux> see you soon, maybe :)
[11:11] <ubitux> TimNich: so the colors in the smptebars looks correct now?
[11:11] <ubitux> 'would be nice to have a SD & HD version of that filter
[11:16] <ubitux> Tjoppen: would you mind having a look to the lavf/mxfenc patch i sent a few days ago? (lavf/mxfenc: simplify frame rate checks)
[11:17] <ubitux> it's basically doing an approximate of the frame rate based on the time_base (25, 30, 50, ...) instead of weird floating checks
[11:18] <ubitux> the fabs(a-b) < 0.0001 is just to do a a == b with floating points
[12:01] <TimNich>  ubitux: I think so apart from the Q I fudge. Unless you can spot something I missed....
[14:45] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rf72e0d9a9f 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[14:45] <CIA-41> ffmpeg: mpegvideo_enc: remove assert that has become obsolete with the new API
[14:45] <CIA-41> ffmpeg: it now just checks uninitialized and unused data.
[14:45] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:45] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rf8dbbe5464 10ffmpeg/libavcodec/mpegvideo_enc.c: 
[14:45] <CIA-41> ffmpeg: mpegvideo_enc: switch some assert to av_assert
[14:45] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:48] <ubitux> hey saste :)
[14:48] <saste> hi
[14:48] <ubitux> saste: about the doc issue on trac where you became owner; it was done automatically when i set the category to documentation
[14:48] <saste> uhm this explains something
[14:49] <saste> for a moment i believed you was trolling me (given the message i posted when closing another docu ticket)
[14:49] <saste> ;-)
[14:49] <ubitux> :D
[14:49] <ubitux> nop i'm not yet that evil
[14:50] <saste> yes that's not the only issue with pos2man
[14:50] <saste> *pod2man
[14:50] <ubitux> that script is old
[14:50] <ubitux> i wonder if there isn't a more recent version somewhere
[14:51] <saste> there is another issue with @@ from texi -> pod or texi -> html
[14:51] <saste> it is customized to our own needs, so updating it is not viable
[14:51] <ubitux> ah i think i saw that one
[14:52] <ubitux> michaelni: thx for fixing the assert :)
[14:52] <ubitux> the DDEBUG box didn't have the time to fail :)
[14:52] <ubitux> maybe it will pass now :)
[14:53] <ubitux> ah actually it failed.
[14:53] <ubitux> there are a few other assert
[16:43] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r3e0b4e32c9 10ffmpeg/libavcodec/svq1enc.c: 
[16:43] <CIA-41> ffmpeg: svq1enc: set picture_structure correctly
[16:43] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:44] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * re6690b6a56 10ffmpeg/libavcodec/mpegvideo.c: 
[16:44] <CIA-41> ffmpeg: mpegvideo.c: convert some asserts to av_assert
[16:44] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:58] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r610c67df37 10ffmpeg/libavcodec/mpegvideo.c: 
[16:58] <CIA-41> ffmpeg: mpegvideo: remove last_picture_ptr / h264 assert.
[16:58] <CIA-41> ffmpeg: This assert is no longer true since h264 error concealment needs
[16:58] <CIA-41> ffmpeg: last_picture_ptr to be set.
[16:58] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:09] <ubitux> anyone registered for VDD here?
[17:09] <ubitux> saste?
[17:09] <saste> ubitux: not yet
[17:10] <saste> not sure if i'll go indeed...
[17:10] <saste> who's going there?
[17:10] <ubitux> no idea
[17:10] <ubitux> libav ppl at least :p
[17:10] <ubitux> (http://www.videolan.org/videolan/events/vdd12/)
[17:11] <saste> where did i put my anti-troll suit?
[17:11] <durandal_1707> what is usually happening on such events?
[17:11] <j-b> porn watching
[17:11] <j-b> and troll fighting
[17:11] <saste> a bunch of nerds talk and troll about technical stuff
[17:13] <ubitux> i'll be there btw
[17:13] <ubitux> maybe just a few hours like last year thought
[17:14] <ubitux> i hope there are talks :p
[17:46] <CIA-41> ffmpeg: 03Nicolas George 07master * rd74ade7d5f 10ffmpeg/ffprobe.c: ffprobe: refactor frames decoding.
[19:45] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r21eafa18e6 10ffmpeg/libavcodec/msrle.c: 
[19:45] <CIA-41> ffmpeg: msrle: fix extradata palette handling
[19:45] <CIA-41> ffmpeg: Fixes Ticket1273
[19:45] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:43] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * ra80ce390df 10ffmpeg/libavformat/avidec.c: 
[21:43] <CIA-41> ffmpeg: avidec: parse INFO tags at the end
[21:43] <CIA-41> ffmpeg: Fixes Ticket1123
[21:43] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:29] <CIA-41> ffmpeg: 03Martin Storsjö 07master * r6c071a2b38 10ffmpeg/libavformat/utils.c: 
[22:29] <CIA-41> ffmpeg: lavf: Declare an AVRational struct without a struct literal
[22:29] <CIA-41> ffmpeg: At this place, the normal way of initializing a struct works
[22:29] <CIA-41> ffmpeg: fine, there's no need for a struct literal.
[22:29] <CIA-41> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[22:29] <CIA-41> ffmpeg: 03Mans Rullgard 07master * radd8f5eab7 10ffmpeg/tests/fate/filter.mak: 
[22:29] <CIA-41> ffmpeg: fate: simplify variable setting filter.mak
[22:29] <CIA-41> ffmpeg: This removes some needless indirection and duplication.
[22:29] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:29] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r2b6804328e 10ffmpeg/libavcodec/imc.c: 
[22:29] <CIA-41> ffmpeg: imc: remove empty if() block
[22:29] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:29] <CIA-41> ffmpeg: 03Mans Rullgard 07master * rb40ea0f41d 10ffmpeg/libavcodec/imc.c: 
[22:29] <CIA-41> ffmpeg: imc: remove unused field IMCContext.one_div_log2
[22:29] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:29] <CIA-41> ffmpeg: 03Janne Grunau 07master * r859a579e9b 10ffmpeg/libavcodec/ (nuv.c rtjpeg.h): 
[22:29] <CIA-41> ffmpeg: nuv: check RTjpeg header for validity
[22:29] <CIA-41> ffmpeg: CC: libav-stable at libav.org
[22:29] <CIA-41> ffmpeg: 03Mans Rullgard 07master * rbaac24e680 10ffmpeg/ (Makefile configure): 
[22:29] <CIA-41> ffmpeg: build: generalise rules and variable settings for av* programs
[22:29] <CIA-41> ffmpeg: This simplifies adding extra flags for individual programs
[22:29] <CIA-41> ffmpeg: and also allows more than one object file per program.
[22:30] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:30] <CIA-41> ffmpeg: 03Mans Rullgard 07master * rbc90230b98 10ffmpeg/libavcodec/imc.c: 
[22:30] <CIA-41> ffmpeg: imc: fix size of a memset()
[22:30] <CIA-41> ffmpeg: IMCContext was changed from an array to a pointer in 66b84e4,
[22:30] <CIA-41> ffmpeg: but this memset() was not updated.
[22:30] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:30] <CIA-41> ffmpeg: 03Janne Grunau 07master * r110d015ad4 10ffmpeg/libavcodec/nuv.c: 
[22:30] <CIA-41> ffmpeg: Revert "nuv: check per-frame header for validity."
[22:30] <CIA-41> ffmpeg: The check is bogus since the nuv frameheader is already skipped
[22:30] <CIA-41> ffmpeg: and the (decompressed) RTjpeg header is checked.
[22:30] <CIA-41> (10 lines omitted)
[22:49] <randomguy123> ffmpeg, these asserts aren't good either:
[22:49] <randomguy123> libavcodec/mpegvideo.c inside dct_unquantize_h263_intra_c assert(s->block_last_index[n]>=0);
[22:49] <randomguy123> libavcodec/elbg.c inside get_high_utility_cell assert(!elbg->cells[i]);
[22:49] <randomguy123> libavcodec/utils.c inside avcodec_default_release_buffer assert(pic->type==FF_BUFFER_TYPE_INTERNAL);
[22:49] <randomguy123> if I modify it with av_assert0 then it won't pass make fate because these asserts will trigger
[22:59] <randomguy123> also, this idea of libavcodec that could abort for some reason isn't great (the av_assert0 macro). Imagine an app that uses libavcodec for some simple stuff (decoding jpeg images for example) and the app may crash because of these asserts on bad jpegs or something like that
[23:01] <durandal_1707> randomguy123: than do not modify code
[23:01] <randomguy123> sorry??
[23:02] <durandal_1707> if it aint broken don't break it
[23:02] <Tjoppen> ubitux: sorry, can't. very limited internet access
[23:02] <ubitux> Tjoppen: no worry ok :)
[23:02] <ubitux> randomguy123: afaict michaelni is changing the assert to avassert[012]; i guess those will be changed at some point
[23:03] <ubitux> randomguy123: also, i enabled the DDEBUG run so the assert issues are raised
[23:03] <ubitux> michaelni fixed some today, there are a few left
[23:03] <ubitux> see http://fate.ffmpeg.org/report.cgi?time=20120806175412&slot=x86_64-archlinux-gcc-ddebug
[23:04] <randomguy123> i don't get what you mean. By the way, I don't get what's wrong with gcc build. to enable asserts it's now DDEBUG required. They must be on by default. To disable them DNDEBUG is required, that's standard c
[23:04] <ubitux> -DDEBUG is not the default
[23:04] <randomguy123> the "i don't get what you mean" part was for durandal
[23:05] <ubitux> i have a fate instance where it's enabled, and make the assert getting triggered
[23:05] <ubitux> ok
[23:06] <durandal_1707> the purpose of asserts is to prevent of introduction of bugs in code
[23:06] <randomguy123> DDEBUG has no relation to regular assert, that's what I say, by looking at ffmpeg builds it looks like all the asserts have to be enabled in all builds, but they are NOT for some reason.
[23:07] <randomguy123> i'm not questioning purpose of asserts, I know what they are for. But at the same time no assert should call abort on bad input in release builds.
[23:08] <durandal_1707> and instead you propose that app should segv instead?
[23:09] <durandal_1707> if asserts are triggered it means code is buggy and bug should be reported
[23:09] <ubitux> randomguy123: as i said, they're getting fixed
[23:09] <ubitux> randomguy123: look at the git history
[23:09] <randomguy123> it's ok for a ffmpeg cli tool, but it's not that ok for apps that use libavcodec etc. At some point I had to decode jpegs and png on mobile phone and it was easiest to simply use libavcodec but it would abort on bad input (that came from network). It was years ago, though.
[23:09] <durandal_1707> asserts should not be triggered for bad input....
[23:10] <durandal_1707> that is also bug which should be reported
[23:10] <ubitux> randomguy123: from today: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=610c67df37bf362319037fc4ef9aab8057947176 
[23:10] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e6690b6a569faaa6c60978485ffb91ebcaafe19b
[23:10] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f8dbbe546435b892a050551f2260e4baf2a1f52b
[23:10] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f72e0d9a9f516be77d20c6a37dcd34add8f932e3
[23:10] <randomguy123> yes, I saw new updates, of course. But replacing assert with av_assert0 is questionable, meaning that libavcodec becomes minefield for any app that links to it.
[23:11] <ubitux> randomguy123: assert means that shouldn't happen; i guess even bad input shouldn't actually trigger that
[23:11] <durandal_1707> randomguy123: so you prefer segv instead of assert?
[23:11] <ubitux> gotta go
[23:12] Action: ubitux &
[23:12] <randomguy123> with standard assert at least you are sure that they aren't compiled away in release builds, but libav* seems that didn't use them that much to check code correctness, e.g. they were always left out.
[23:12] <ubitux> night ppl :)
[23:12] <ubitux> randomguy123: the point is that if they aren't compiled it will likely crash instead
[23:13] <randomguy123> assert means that it should only happen in special build. In release build these checks shouldn't even exist.
[23:13] <durandal_1707> randomguy123: if you prefer segv, send patch to optionally disable assert0
[23:16] <randomguy123> ubitux, it's usually what it looks like, but most of the time it's just not the case.
[23:16] <randomguy123> Durandal: I use it on windows, so not sure what sigv is, but standard assert behavior was fine, but all of asserts were compiled away in ffmpeg builds.
[23:22] <randomguy123> cool shit :)
[23:23] <randomguy123> (i'm talking about the bot).
[23:25] <randomguy123> the thing about asserts. If there is a problem in relase builds often you won't be able to do anything no matter what you do: abort, or kill the app or cross your fingers and try to continue risking to get sigsegv. So, I guess standard asserts are the way to go, and in places where checks are necessary it should be error logging, it's kind of clear i guess
[23:29] <michaelni> assert(random user has no access to /etc/shadow); <-- you dont want to continue here
[23:35] <randomguy123> assert ins't proper way to check if a user has some access. It makes sence in cases like this:
[23:35] <randomguy123> if(!user_has_access(...)){
[23:35] <randomguy123>    return;
[23:35] <randomguy123> }
[23:35] <randomguy123> ...
[23:35] <randomguy123> assert(user_has_access(...));
[23:36] <randomguy123> basically, there was something made to make sure that it doesn't happen. and asserts down the logic line could be there just to verify that this assumption is valid that after the if(...) statement that condition didn't change.
[23:41] <michaelni> randomguy123, and you really want to continue if that assert fails on your example ?
[23:41] <michaelni> especially if the if() and assert was fliped and assert(!(user_has_access(...));
[23:42] <michaelni> also if you want to help improve the code that would be very welcome!
[23:43] <randomguy123> it's not the point. Asserts very often could be used a way to notify that certain condition is true at some point in code.
[23:43] <randomguy123> for code like this:
[23:43] <randomguy123> assert(is_ok);
[23:43] <randomguy123> if(!is_ok) av_log(...);
[23:43] <randomguy123>  Some compilers in release builds may even skip check for if(!is_ok)
[23:45] <randomguy123> i think I saw that armcc in some place if NDEBUG is defined it redefines assert(...) into compiler specific pragma that helps the optimizer to assume certain condition.
[23:48] <randomguy123> I think regular asserts were OK, I simply don't understand why they were never used. To disable asserts NDEBUG must be defined, but I don't see NDEBUG anywhere passed to gcc, so I have no clue why regular asserts don't do anything in ffmpeg. ANybody can explain?? :)
[23:49] <randomguy123> because regular asserts were never used there became lots of obsolete asserts. Basically, if at some point assert becomes invalid it shouldn't start aborting in regular build of vlc or any other app that uses libavcodec.
[00:00] --- Tue Aug  7 2012