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

[burek]

[00:20] <nevcairiel> michaelni: avpriv_color_frame asserts when using a hwaccel in h264, pixel format is not planar
[00:25] <nevcairiel> michaelni: i sent a small patch about that
[00:35] <cone-323> ffmpeg.git 03James Almer 07master:a56fd9edab57: lavu: Fix checkheaders for x86/emms.h
[00:35] <cone-323> ffmpeg.git 03Hendrik Leppkes 07master:1d6f6ff4d9fa: h264: don't initialize missing pictures when using a hwaccel
[00:44] <cone-323> ffmpeg.git 03James Almer 07master:2e988fd68964: lavc/tta: Use a safer check for encrypted streams
[00:44] <cone-323> ffmpeg.git 03James Almer 07master:b8bb661dab8e: Changelog: Add entry for encrypted TTA stream decoding
[01:55] <Compn> j-b : how goes the bittorrent demuxer? :P
[01:55] <Compn> j-b : bonus points if you have it implemented into ffmpeg. that way more players can utilize ffmpeg code :)
[01:56] <j-b> Compn: you _really_ think the issue is the demuxer or protocol paet?
[01:56] <j-b> part?
[01:56] <j-b> Of course the issue is the UI, the management and the downloading services
[01:56] <Compn> hmm? i mean the overall project
[01:57] <Compn> i dont know which part is the difficult . probably cache, demuxer quirks (mov/avi index at end of file) 
[01:57] <Compn> implementing an entire bt client ...
[01:58] <Compn> j-b : but is my idea of putting it in ffmpeg good or bad ? 
[01:59] <Compn> or its already started in vlc ?
[01:59] Action: Compn is slow with the ideas today
[02:00] <Compn> j-b : its not important, just another dumb idea from me  :)
[02:02] <j-b> Compn: so far, we've done nothing, and we're sponsoring nothing
[02:02] <j-b> so, I got no idea
[02:04] <Compn> can vlc use ffmpeg's network stuff ?
[02:04] <j-b> sure.
[02:04] <Compn> ok
[02:04] <Compn> so at least it would be possible to implement it in ffmpeg
[02:04] <Compn> and vlc could use it from there
[02:05] <j-b> sure
[02:05] <j-b> but, once again, the hard part is NOT the networking part
[02:06] <Compn> it sounds kinda similar to apple / adobe fragmented thing
[02:06] <Compn> unless i'm completely missing something 
[02:06] <Compn> thing = http
[02:09] Action: Compn keeps focusing on networking part for some reason
[02:24] <iive> j-b: what is the problem with the UI? 
[02:24] <saste> iive, interface are usually a mess to do (correctly)
[02:24] <iive> but why does it need ui at all?
[02:25] <j-b> iive: well, you have media player UI, and you need to rape it, in order to have a torrent-management-system in it
[02:25] <Compn> iive : limit bandwidth, specify download dir
[02:25] <j-b> of course not
[02:25] <Compn> j-b : cant just put it all in settings ?
[02:25] <j-b> all those are trivial
[02:25] <Compn> whats the hard part ?
[02:25] <Compn> i mean
[02:25] <Compn> what ui do you need ?
[02:25] <j-b> look at Utorrent
[02:25] <Compn> like utorrent status or something 
[02:25] <Compn> ah
[02:26] <j-b> You need a playlist-like-thing to list your torrent
[02:26] <j-b> because if you play just one, it will buffer for a long time
[02:26] <iive> see it is network problem :P
[02:27] <Compn> lolol
[02:27] <j-b> moreover, the UI needs to talk to this module in a very specific way (it ain't your average demuxer)
[02:28] <iive> instead of utorrent, take a look of the original bittorrent client, or even transmision... not much to click there.
[02:28] <Compn> just text output? lol
[02:28] <Compn> use ffmpegs ascii decoder :D
[02:29] <Compn> wont be pretty
[02:29] <j-b> iive: even for that, you need to control your demuxer in different way than RTSP/RTMP
[02:29] <iive> the problem is elsewhere, e.g. do you want disk caching... because then you create permanent copy on your system.
[02:30] <Compn> you need disk caching , for indexes at end of files :P
[02:30] <j-b> So, you need a special API, and even with one-torrent-at-a-time, you need status that is a bit more than "buffering"
[02:30] <iive> the biggest problem of course it bandwidth, you need to both download blocks in realtime playback and download blocks in random order to keep the seeding balanced.
[02:31] <iive> ...in order for realtime playback...
[02:31] <Compn> i dont think the implementation needs seeding balance
[02:32] <Compn> its the same thing anyways, in order or random
[02:32] <Compn> still the same amount of data
[02:33] <iive> no it is not. torrent always uses random.
[02:33] <j-b> you can
[02:33] <Compn> torrent can be configured to set priority to rares pieces, starts/ends of files, or download in order 
[02:34] <iive> it is same amount of data, but if everybody have the first 10% of the movie and only 1 seed have the rest, you will get a lot worse speed when trying to get something from the 90%
[02:34] <Compn> its the same speed! 
[02:34] <iive> no. for the 10% you have 10 seeders, so you get 10x speed.
[02:35] <Compn> until everyone catches up, then its the same speed
[02:35] <iive> and if you use it in video content, you are most likely to start from the start :P
[02:35] <j-b> in-order is possible
[02:35] <j-b> but it is bad
[02:36] <iive> yes, it is bad for the swarm.
[02:36] <Compn> doesnt miro already do this btw ?
[02:36] <Compn> and isnt it based on vlc...
[02:37] <Compn> http://www.getmiro.com/download/features/
[02:38] <Compn> or is it just a mix of the two. i dunno never used it
[02:54] <highgod> Hi, all I want to ask a question. Can ffmpeg be compiled using mingw64 and create 64bits libs and dlls? thanks
[03:09] <Compn> highgod : yes, it can
[03:10] <Compn> oh, maybe not
[03:10] <Compn> we dont have a fate box for it
[03:11] <Compn> er
[03:11] <Compn> yeah
[03:11] <Compn> highgod : http://ffmpeg.zeranoe.com/builds/
[03:11] <Compn> zeranoe has 64bit mingw ffmpeg builds
[03:11] <Compn> and instructions for doing it ^^
[03:43] <cone-323> ffmpeg.git 03Reinhard Tartler 07release/0.5:deb650c69231: Release notes and changelog for 0.5.10
[03:43] <cone-323> ffmpeg.git 03Michael Niedermayer 07release/0.5:0360dbefad8a: Merge remote-tracking branch 'qatar/release/0.5' into release/0.5
[04:24] <highgod> OK,thanks Compn.
[04:29] <Zeranoe> Could anyone explain to me the license details of fdk-aac? A lot of users are asking for fdk-aac, and reading the license for this lib I find "Redistribution and use in source and binary forms, with or without modification, are permitted without payment of copyright license fees provided that you satisfy the following conditions:" Which then lists a few conditions. Is there any way to load the library dynamically and still compl
[04:30] <cone-323> ffmpeg.git 03Michael Niedermayer 07release/0.5:a23a3dba2544: qdm2: check array index before use, fix out of array accesses
[04:30] <cone-323> ffmpeg.git 03Michael Niedermayer 07release/0.5:fee26d352a52: roqvideodec: check dimensions validity
[04:30] <cone-323> ffmpeg.git 03Michael Niedermayer 07release/0.5:13093f9767b9: vqavideo: check chunk sizes before reading chunks
[04:30] <cone-323> ffmpeg.git 03Michael Niedermayer 07release/0.5:d34cfb33afb8: update for 0.5.11
[04:48] <Compn> Zeranoe : got a link?
[04:48] <Zeranoe> Compn: A link for the license? 
[04:48] <Compn> ya
[04:49] <Zeranoe> Compn: https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE#L29
[04:49] <Compn> Zeranoe : thats wbs's repo, maybe he can explains it
[04:49] <Zeranoe> The license looks very similar to the GPL and I'm surprised FFmpeg wont allow it in a GPL build.
[04:50] <Zeranoe> Compn: Explain why FFmpeg wont allow it under the GPL?
[04:50] <Compn> its very similar to gpl build
[04:50] <Compn> possibly You may not charge copyright license fees for anyone to use, copy or distribute the FDK AAC Codec
[04:50] <Compn> software or your modifications thereto.
[04:50] <Compn> goes against gpl
[04:50] <Compn> since you can charge for gpl
[04:51] <Compn> not sure what a 'copyright license fee' would even be ...
[04:51] <Zeranoe> Compn: If the lib cannot be included in a GPL build, would it comply with the license if FFmpeg was built to accept a fdk-aac lib file, like a .dll and use it externally when it needs it? 
[04:53] <Zeranoe> Compn: Since both libs allow for distribution of a binary, only thing would be the license for the fdk-aac code that FFmpeg uses to call the lib.
[04:54] <Compn> you dont just want to put it in 'non-free' ?
[04:54] <Compn> but i dunno, i'm no license master
[04:54] <Compn> your idea sounds good
[04:54] <Zeranoe> libfdk-aacenc.c is under the LGPL so it should be ok
[04:55] <Zeranoe> Compn: Non-free means I cant redistribute the binary, which is my goal.
[04:55] <Zeranoe> I want to provide my uses with a FFmpeg that can use the best AAC encoder lib.
[04:56] <Zeranoe> users**
[11:53] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:ef4c71e8f83a: lavfi/unsharp: add check on matrix x/y size values oddity
[11:53] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:d2cadea3f085: lavfi/unsharp: directly access in-loop variables in apply_unsharp()
[11:53] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:64e592eef26b: lavfi/unsharp: merge definition and declaration in init_filter_param()
[11:53] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:89505f2c3f8e: lavfi/unsharp: add missing NULL check
[11:53] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:8c85a9f046fb: lavfi/mp: drop mp=unsharp filter
[11:53] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:7ca2f8b1130b: lavfi/mp: drop mp=kerndeint filter
[11:56] <ubitux> can anyone tell me if the avcodec.h change in the subtitle character encoding patch is fine?
[11:56] <ubitux> Nicolas seems to have some concern about it
[11:56] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/139117.html
[11:56] <ubitux> "Wait for
[11:56] <ubitux> confirmation about the avcodec.h part though.
[11:56] <ubitux> "
[11:57] <ubitux> (basically +#define AV_CODEC_PROP_BITMAP_SUB    (1 << 16))
[12:02] <ubitux> oh maybe he was refering to the rest though
[12:05] <ubitux> well i'll resend a patch
[12:48] <ubitux> wm4: subtitles character encoding, soon.
[12:48] <ubitux> (finally)
[12:48] <wm4> ok
[12:48] <wm4> what are you going to use?
[12:48] <ubitux> it's done, i'm just waiting for a last comment
[12:49] <ubitux> no utf-16 yet though, Nicolas seems to be interested to working on it
[12:50] <ubitux> https://github.com/ubitux/FFmpeg/compare/master...sub-recode-nofilter
[12:56] <ubitux> should i increment micro or minor when adding a field to AVCodecContext?
[12:56] <nevcairiel> wasnt minor for such things
[12:57] <ubitux> ok
[13:01] <ubitux> saste: 
[13:01] <ubitux> -unsharp             7d72d2ab7b7f60159c822a097e01068b
[13:01] <ubitux> +unsharp             d41d8cd98f00b204e9800998ecf8427e
[13:01] <ubitux> :(
[13:04] <cone-485> ffmpeg.git 03Clément BSsch 07master:8732271e4025: lavc: mark bitmap based subtitles codecs as such.
[13:04] <cone-485> ffmpeg.git 03Clément BSsch 07master:f796399344a1: lavc: support subtitles character encoding conversion.
[13:04] <cone-485> ffmpeg.git 03Clément BSsch 07master:3a0a959dcbf8: lavfi/subtitles: split options between ass and subtitles.
[13:04] <cone-485> ffmpeg.git 03Clément BSsch 07master:08d149d6889b: lavfi/subtitles: support charenc option.
[13:04] <cone-485> ffmpeg.git 03Clément BSsch 07master:2a14b23484be: lavfi: rename vf_ass.c to vf_subtitles.c
[13:04] <cone-485> ffmpeg.git 03Clément BSsch 07master:90fb3e9bee60: lavfi/subtitles: set a different description between ass and subtitles.
[13:04] <ubitux> wm4: have fun ^
[13:07] <wm4> hm, vf_subtitles doesn't actually use this new flag?
[13:08] <ubitux> yes it does
[13:08] <ubitux> -vf subtitles=foo.srt:charenc=cp1251
[13:09] <cone-485> ffmpeg.git 03Clément BSsch 07master:b1e6b144ed92: lavc/utils: reindent in avcodec_decode_subtitle2() after f7963993.
[13:09] <wm4> I mean AV_CODEC_PROP_BITMAP_SUB
[13:10] <ubitux> mmh good point, maybe it should now
[13:10] <wm4> and maybe codecs which decode to ass should be marked as well (in fact, AV_CODEC_PROP_BITMAP_SUB is entirely useless for now, because of backwards compatibility)
[13:11] <ubitux> it's mainly meant to be used internally
[13:11] <ubitux> notably to set sub->format (0 or 1)
[13:11] <ubitux> or enable/disable charset re-encoding
[13:14] <wm4> I still don't quite see how vf_subtitles prevents opening an image subtitle decoder as ass decoder
[13:14] <ubitux> it doesn't
[13:15] <ubitux> it will basically do nothing
[13:15] <ubitux> first bitmap sub expected ’ break the loop, do nothing
[13:15] <ubitux> i'll add an error soon now that we have the flag
[13:15] <ubitux> for backward compat, you can rely on sub->format
[13:15] <ubitux> for the first decoded sub
[13:23] <wm4> so I have to try to decode the first subtitle just to detect a property statically known before any decoding?
[13:23] <ubitux> or use AV_CODEC_PROP_BITMAP_SUB now
[13:24] <ubitux> i can't do much more for the old versions
[13:24] <ubitux> any subtitles format not with the AV_CODEC_PROP_BITMAP_SUB prop is supposed to decode to ass
[13:30] <cone-485> ffmpeg.git 03Stefano Sabatini 07master:894ed8fbb71d: tests: fix values for the unsharp test
[13:39] <cone-485> ffmpeg.git 03Clément BSsch 07master:fe150a48a72e: lavc: fix codec_descriptor and pkt_timebase doxy.
[13:39] <cone-485> ffmpeg.git 03Clément BSsch 07master:f3147917bf00: lavf/subtitles: error out in case of bitmap subtitles.
[13:40] <wm4> ubitux: any news on fixing the ass packet format?
[13:40] <ubitux> i'm going back to it slowly
[13:40] <ubitux> i wanted to get done with the charset thing first
[14:33] <cone-485> ffmpeg.git 03Anton Khirnov 07master:1f8f43a5b5e9: error_resilience: add required headers.
[14:33] <cone-485> ffmpeg.git 03Michael Niedermayer 07master:59e46ef63ab4: Merge remote-tracking branch 'qatar/master'
[16:03] <cone-485> ffmpeg.git 03Nicolas George 07master:dcc73aaaa995: doc/examples: do not allocate AVFrame directly.
[16:58] <cone-485> ffmpeg.git 03Clément BSsch 07master:1e860f16688b: doc/codecs: simple sub_charenc option documentation.
[17:35] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07master:cf36180143b3: Only set accelerated arm fft functions if fft is enabled.
[17:37] <cone-485> ffmpeg.git 03Michael Niedermayer 07master:09ece9fa6c45: eval: print() support
[17:37] <cone-485> ffmpeg.git 03Michael Niedermayer 07master:29c8619a4977: fate: add print() to the tests of eval
[17:41] <durandal_1707> anyone working on lua filter?
[18:06] <cehoyos> nevcairiel: If you look at the mkvalidator output in ticket 2263, is it sufficient for you to see why libavformat does not know where to find keyframes?
[18:06] <cehoyos> And if you know why: How can such files be produced: I have the same version of mkvmerge installed here and if I remux the file, FFmpeg reads the resulting file fine (seeking does not take ages)
[18:07] <nevcairiel> most software will probably only read the first seekhead, and without cues seeking in mkv is butt-slow
[18:08] <nevcairiel> especially because the second seekhead as at the end of the file, it appears
[18:09] <cehoyos> How can I check if the seekhead is really at the end of the file?
[18:09] <cehoyos> And since our sample is 11G: How can I produce such a sample?
[18:09] <cehoyos> ... such a shorter sample;-)
[18:10] <nevcairiel> well mkvalidator says the second seekhead is at 11568150341
[18:10] <nevcairiel> that sounds like 11g =p
[18:10] <cehoyos> ok, sorry..
[18:11] <nevcairiel> no idea how to produce something like this, maybe it didnt have the ability to seek in the output and then decided to write it at the end is better then not at all
[18:11] <cehoyos> Something like mkvmerge -o - ?
[18:12] <nevcairiel> never tried anything like this
[18:15] <cehoyos> mkvmerge -o - produces a file ./-
[18:17] <cehoyos> nevcairiel: Does this link describe why mkvmerge put a second seek head at the end of the file? https://trac.bunkus.org/ticket/290
[18:19] <nevcairiel> but in this case it references the second seek head from the first
[18:19] <nevcairiel> so you know where it is and can parse it directly
[18:20] <nevcairiel> so i can only guess that it simply failed to reference the secondary one in the primary one
[18:22] <cehoyos> So basically I have to keep the file;-(
[18:26] <cehoyos> Is my comment correct? https://ffmpeg.org/trac/ffmpeg/ticket/2263#comment:8
[18:27] <nevcairiel> from what i know without having seen the file, yes
[18:28] <cehoyos> Thank you!
[18:41] <ubitux> the print thing in eval will be very useful
[18:42] <ubitux> thx :)
[19:47] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07master:fdec49cbe83f: Add gray16 as a supported v4l2 input format.
[19:47] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07master:fdbe7628a957: Add yvu410 as a supported v4l2 input format.
[20:21] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07master:8d0757e1079f: Revert "swfenc: use av_get_audio_frame_duration() instead of AVCodecContext.frame_size"
[20:23] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8d0757e1079f588ed69f629e2d1a4d5f232dc298 <-- protip: bug ids are not a replacement for an actual descriptio
[20:23] <Daemon404> n
[20:24] <Daemon404> http://ffmpeg.org/developer.html#Development-Policy 
[20:24] <Daemon404> #3
[20:25] <Daemon404> in this case, the bug ID still doesnt have a dexription of why the patch reverts it
[20:27] <durandal_1707> cehoyos: that bug do not have reproduced and analyzed set
[20:27] <Compn> Daemon404 : its reverted because it fixes the bug. i think your real question is "why is that previous change causing this swf bug"
[20:27] <durandal_1707> Compn: please, stop
[20:28] <Daemon404> Compn, let us name all our commits "fix bug"
[20:28] <Compn> hehe
[20:28] <Compn> it should be fix regression :P
[20:34] <durandal_1707> swf can have mp3 which is not covered by av_get_audio_frame_duration
[20:35] <cehoyos> durandal_1707: I cannot reproduce it because I don't know how to feed FlashPlayer
[20:35] <durandal_1707> and how you found out reverting fixes it?
[20:37] <cehoyos> This is difficult to answer because I am not sure what the deeper meaning of your question is.
[20:38] <cehoyos> (But the answer would be: Because I used git bisect for some time and afaict, the original test was not just unreviewed but untested.)
[20:38] <cehoyos> s/test/patch
[20:38] <durandal_1707> wasn't it reproduced with ffmpeg too? eg. durationts from demuxer are set to 0?
[20:39] <cehoyos> Daemon404: My patch description contains an exact description why the patch was needed
[20:39] <Daemon404> where
[20:39] <Daemon404> its not in the commit message.
[20:39] <Daemon404> how did you test this patch
[20:39] <Daemon404> why does it fix it
[20:39] <Daemon404> etc
[20:40] <durandal_1707> also coverage for muxing lot of codecs in swf or any other container is small
[20:42] <durandal_1707> cehoyos: but bug report also have also near to 0 useful info
[20:42] <durandal_1707> so user might not use mp3 in swf at all
[20:43] <durandal_1707> bug report is just incomplete, and fix/revert is (even if correct) pure guesswork
[20:46] <cehoyos> durandal_1707: No, the duration is ok with ffmpeg -i file.swf
[20:46] <durandal_1707> lol the ticket have enough info
[20:47] <durandal_1707> it is just hidden in stupid log file
[20:47] <durandal_1707> cehoyos: that can be from parser ...
[20:48] <cehoyos> Daemon404: I have a suggetion; Could you find out which sample / bug report / hypothetical case was fixed by 9fb7e14?
[20:49] <Daemon404> if it switches to a new config and fails, instead of just giving up, it will revert to the old one
[20:49] <Daemon404> its pretty obvious
[20:49] <Daemon404> also piitning out random Libav commits does not magically make it OK.
[20:49] <kierank> oh nice, someone just *had* to try putting latm in mkv
[20:49] <cehoyos> durandal_1707: I completely agree that posting logs is significantly more useful than attaching, but I tried to help the user because it was his first report afair.
[20:50] <Daemon404> the amount of english comprehension in this channel is painful.
[20:51] <cehoyos> Daemon404: (Do you honestly think it is a random commit? Because if yes, this whole discussion makes even less sense.) You misunderstand: I don't need an explanation what the patch does, I probably don't understand it anyway, and if I would be interested, looking at it would probably be sufficient, the point is *why*
[20:52] <Daemon404> you need an explanaion of why it was reverted. "fixes bug X" with ZERO technical details is not valid
[20:52] <durandal_1707> cehoyos: you should reopen bug and wait for poster to reply that issue have really been fixed (you cant or did not tried to reproduce it after all)
[20:52] <cehoyos> I disagree, but that is probably not the point...
[20:52] <cehoyos> durandal_1707: I disagree because OP's often never react and as you know we have too many open reports.
[20:53] <cehoyos> (In this specific case, no testing is necessary, but that is beside the point.)
[20:53] <cehoyos> Daemon404: Wow, I just wanted to leave because of you being quite offensive;-)
[21:04] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:381e3e7e44f9: Revert "swfenc: use av_get_audio_frame_duration() instead of AVCodecContext.frame_size"
[21:04] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:98d06b046dfe: Revert "swfenc: use av_get_audio_frame_duration() instead of AVCodecContext.frame_size"
[21:04] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:6407800521d2: Revert "swfenc: use av_get_audio_frame_duration() instead of AVCodecContext.frame_size"
[21:11] <Compn> kierank : no not more latm stuff :V
[21:12] <kierank> :)
[21:13] <durandal_1707> there is some other latm open bug?
[21:42] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07fatal: ambiguous argument 'refs/tags/n0.5.11': unknown revision or path not in the working tree.
[21:42] <cone-485> Use '--' to separate paths from revisions
[21:42] <cone-485> refs/tags/n0.5.11:HEAD: Revert "swfenc: use av_get_audio_frame_duration() instead of AVCodecContext.frame_size"
[22:14] <durandal_1707> michaelni: i sent patch for lavfi/noise to stop using rand/srand - i looked at output and quality of noise looks almost same
[22:18] <peper03> Is a patch to add passing PRIVATE_STREAM_2 MPEG2 packets to the user likely to be accepted?  I would only add a new codec ID and pass the packet as-is.  There doesn't seem to be much point with a decoder as it's a pure data packet and from what I can see, used for different purposes (DVD, Dreamcast - Sofdec).
[22:19] <peper03> I couldn't see any other data-only codec IDs so I can't base my patch on other implementations.
[22:21] <durandal_1707> peper03: there is patch on ml?
[22:23] <peper03> durandal_1707: Not yet.  I've basically got everything prepared (I think) but I just wanted to check a couple of basic points first as I'm not subscribed to the ml yet etc. etc.
[22:24] <peper03> Did I understand the guidelines correctly, indentation due to an 'if' should be submitted separately?
[22:24] <durandal_1707> i'm not mpegts expert so can't really help
[22:24] <durandal_1707> peper03: yes, easier to review
[22:25] <peper03> durandal_1707: Sure.  No problem.  Again, just wanted to ensure I hadn't misunderstood.
[22:26] <peper03> durandal_1707: Are you aware of any other data-only packets that are currently handled?
[22:26] <peper03> Handled = passed back to the caller?
[22:28] <cone-485> ffmpeg.git 03Michael Niedermayer 07master:dece584a639c: h264: avoid calling get_format() multiple times
[22:29] <durandal_1707> peper03: i'm not qualified enough to answer such question
[22:30] <peper03> durandal_1707: Ok, np.  Thanks.
[22:31] <durandal_1707> michaelni: so what I should use instead of RAND_MAX?
[22:32] <michaelni> UINT_MAX IIRC
[22:34] <durandal_1707> michaelni: is it relevant that rand returns int and lfg unsigned?
[22:37] <cone-485> ffmpeg.git 03Carl Eugen Hoyos 07master:259603b91767: h264: don't initialize missing pictures when using VDPAU.
[22:38] <michaelni> it could make a difference depending on how its used
[22:42] <durandal_1707> i replaced RAND_MAX with UINT_MAX and nothing chaged, still noise on screen
[22:43] <durandal_1707> rand(3) here returns positive numbers
[22:44] <durandal_1707> and RAND_MAX is INT_MAX
[22:48] <cone-485> ffmpeg.git 03Paul B Mahol 07master:f4e29c408cea: lavfi/noise: switch to AVLFG noise generator
[22:48] Action: llogan wonders if saste will administer GSoC this year.
[22:57] <durandal_1707> so g2m is comming
[23:01] <Compn> someone is working on it durandal_1707 ?
[23:02] <durandal_1707> Compn: codecs.multimedia.cx
[23:03] <Compn> hah, someone must have trolled kostya :)
[23:03] <Compn> wonder where he found the smallest go2 binary codec
[23:03] <Compn> i spent a while in archive.org looking for it
[23:09] <Compn> oh yes
[23:09] <Compn> http://codecs.multimedia.cx/?p=431
[23:09] <Compn> that was the one i found :)
[23:10] Action: Compn was the troll :D
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:760929117df0: alsdec: check block length
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:caeca53a09fd: qdm2: check array index before use, fix out of array accesses
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:391e0fc6c90c: roqvideodec: check dimensions validity
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:af343f5cddc5: eamad: fix out of array accesses
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:2cac35086c9e: vqavideo: check chunk sizes before reading chunks
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:e6ac11e41734: aacdec: check channel count
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:41eda870483f: pngdec/filter: dont access out of array elements at the end
[23:45] <cone-485> ffmpeg.git 03Michael Niedermayer 07release/0.8:377fabc9e687: Update for 0.8.13
[23:46] <Compn> j-b : is there any g2m1 samples hiding in vlc trac or ftp? :)
[23:54] Action: Compn looking for webinars
[23:54] <Compn> wmv3 , wmv1 , mss2
[00:00] --- Mon Feb 18 2013