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

[burek]

[00:00] <cone-377> ffmpeg.git 03Carl Eugen Hoyos 07master:43353bf32c92: libxvid: guess a good aspect when we cant store the exact one.
[00:00] <cone-377> ffmpeg.git 03Michael Niedermayer 07master:7caaa72e6248: Merge remote-tracking branch 'cehoyos/master'
[01:53] <cone-377> ffmpeg.git 03Michael Niedermayer 07master:ce228206274b: avcodec/mjpegdec: fix shift_output() with lowres
[03:20] <cone-377> ffmpeg.git 03wm4 07master:b4e1630d4d25: lavc: don't show "Invalid and inefficient vfw-avi..." warning in mpeg4 parser
[09:31] <cone-337> ffmpeg.git 03Luca Barbato 07release/1.1:0eb465f981de: nuv: check ff_rtjpeg_decode_frame_yuv420 return value
[09:31] <cone-337> ffmpeg.git 03Luca Barbato 07release/1.1:1e9e311e2107: dv: Add a guard to not overread the ppcm array
[09:31] <cone-337> ffmpeg.git 03Anton Khirnov 07release/1.1:777bc81a91a4: lavf: fix the comparison in an overflow check
[09:31] <cone-337> ffmpeg.git 03Sean McGovern 07release/1.1:007f3f416573: Prepare for 9.9 RELEASE
[09:31] <cone-337> ffmpeg.git 03Sean McGovern 07release/1.1:4d073ddac95d: Update Changelog
[09:31] <cone-337> ffmpeg.git 03Michael Niedermayer 07release/1.1:bf312714786a: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[11:40] <cone-337> ffmpeg.git 03James Almer 07master:452ac2aaecf7: lavu/ripemd: Fully unroll the transform function loops
[11:40] <cone-337> ffmpeg.git 03James Almer 07master:8702a94e4992: lavu/ripemd: Add a size optimized version of the transform functions
[12:01] <cone-337> ffmpeg.git 03Rainer Hochecker 07master:7d75fb381ba7: h264: do not discard NAL_SEI when skipping frames
[12:33] <durandal_1707> its nice when you add new feature to encoder (but do not to decoder) just to find out decoder crash
[12:33] <durandal_1707> NOT
[12:35] <durandal_1707> michaelni: ff_alloc_packet2 in ffv1enc does not take 16 bit into account correctly
[12:36] <mateo`> isn't cehoyos on irc ?
[12:38] <durandal_1707> only on special occasion
[12:38] <ubitux> mateo`: he's reading the backlog offline
[12:38] <ubitux> mateo`: so you can talk to him like if he was here right now
[12:38] <ubitux> and you'll get a mail answer later ;)
[12:39] <mateo`> i just want to let him know that i'll review the mxfenc patches this evening
[12:39] <durandal_1707> like he is in 12 light hours away
[12:40] <mateo`> at first look, i suspect something fishy about the second patch
[12:40] <ubitux> you can also just assign the ticket to yourself
[12:45] <wm4> does the rtsp:// implementation do anything special that it can't use a user-provided AVIOContext? (like mplayer does)
[12:46] <wm4> I'm getting crappy playback with mplayer ffmpeg://rtsp://... but not with ffplay
[12:46] <mateo`> ubitux: i'll just review the patch when i got some time, if some extra work is needed i'll assign myself to the ticket
[13:05] <wm4> durandal_1707: how does 10 bit yuva work at all? is the alpha component shifted like the other components?
[13:06] <durandal_1707> it spans all values
[13:07] <durandal_1707> just like 8bit
[13:07] <wm4> spans all values as in?
[13:07] <durandal_1707> 0 - 2^10-1
[13:08] <wm4> ok
[13:08] <nevcairiel> he just means that alpha is the same as the other planes
[13:11] <Compn> wm4 : are you using live555 rtsp:// in ffplay ?
[13:11] <Compn> or the native one
[13:11] <Compn> same question goes to mplayer ffmpeg://rtsp://
[13:12] <wm4> I don't think ffmpeg supports live555
[13:12] <wm4> mplayer seems to pick live555 for rtsp://
[13:12] <wm4> and that works fine
[13:12] <wm4> but with ffmpeg://rtsp://... you get video corruption (most likely due to aggressive packet dropping?)
[13:13] <Compn> what url ?
[13:13] <wm4> rtsp://live10.tiesraides.lv/live/tiesraides.lv.10_2
[13:15] <Compn> i think my ip is blocked
[13:19] <durandal_1707> why you listen to that guy...
[13:46] <durandal_1707> huh, segv happens when i use av_reallocp_array
[13:48] <durandal_1707> wtf why memset is there?
[13:57] <cone-337> ffmpeg.git 03Paul B Mahol 07master:6e07bb36393f: avcodec/truemotion2: use av_reallocp_array() and check return value
[13:58] <cone-337> ffmpeg.git 03Paul B Mahol 07master:9bc59c108baf: avcodec/bmpenc: return meaningful error code
[13:58] <cone-337> ffmpeg.git 03Paul B Mahol 07master:5e66d8ac63f9: avcodec/xwdenc: use AV_LOG_ERROR in error message
[14:10] <cone-337> ffmpeg.git 03Paul B Mahol 07master:81f231b5c7c9: avcodec/asfdec: check return value of av_mallocz()
[14:28] <cone-337> ffmpeg.git 03Paul B Mahol 07master:a5615b82eb11: avcodec/eatgv: use av_reallocp_array() and check return value
[14:44] <xlinkz0_> Hi, i'm trying to set the time_base of a file i'm transcoding but i get the following error : Codec AVOption time_base () specified for output file #0 (newintro.mp4) is not an encoding option.
[15:01] <durandal_1707> xlinkz0_: again, wrong channel
[15:02] <xlinkz0_> sorry
[16:03] Action: ubitux finally understands why ffplay fails with vid.stab
[16:04] <ubitux> it's simply that seeking breaks the frame data id
[16:04] <ubitux> and so frames get a transform that don't belong to them...
[16:05] <ubitux> anyway, the deshake filter really looks like vid.stab code (and actually copyright of vid.stab dev is in the header)
[16:05] <ubitux> but the licenses mismatch
[16:05] <ubitux> can anyone comment on this?
[16:06] <ubitux> i don't like this at all, so i'll likely contact the vid.stab guy soon about this to get his opinion
[16:06] <durandal_1707> so it does nothing new functionality?
[16:08] <ubitux> well, segmentation and motion detect look different 
[16:09] <ubitux> but even that, not that much
[16:09] <ubitux> OTOH it's single pass
[16:09] <durandal_1707> how different?
[16:10] <ubitux> so there is no advanced preprocessing like smoothing (which requires N pre and post differences)
[16:10] <durandal_1707> and it is GPL?
[16:10] <ubitux> vid.stab is GPL, vf deshake is LGPL 
[16:10] <ubitux> the whole transformation code is almost identical
[16:10] <ubitux> the general logic is the same
[16:11] <ubitux> anyway, if the author didn't agree, the license needs to be fixed IMO
[16:11] <durandal_1707> well you can fix single typo and relicense to GPL...
[16:11] <ubitux> fix typo? huh?
[16:11] <Compn> hes saying gpl is a typo :P
[16:11] <Compn> but yes, you have to contact author :)
[16:12] <durandal_1707> iirc you are ok to relicense LGPL to GPL and fork it...
[16:12] <ubitux> i wanted to work on deshake because it had the advantage of not being gpl but well..
[16:13] <durandal_1707> but adding wrapper for our forked filters is bummer
[16:13] <ubitux> mmh?
[16:13] <ubitux> vid.stab didn't fork deshake, it was the other way around
[16:13] <durandal_1707> well you sain there is nothing serious improved over lgpl one
[16:14] <ubitux> yes, afaict there is hardly anything better in deshake, but we need to fix the license because it's too much based on vid.stab
[16:15] <ubitux> but i wanted to work on it because it was lgpl :(
[16:15] <durandal_1707> i't tottaly confused
[16:15] <durandal_1707> are you saying we should change our deshake to GPL?
[16:15] <ubitux> s/change/fix/
[16:15] <ubitux> durandal_1707: the main benefit of deshake over vid.stab is the license
[16:16] <durandal_1707> but what was first? chicken or egg?
[16:16] <ubitux> but since the code is heavily based on vid.stab, the LGPL is very dubious
[16:16] <ubitux> vid.stab was first
[16:16] <wm4> why would anyone care about gpl vs. lgpl
[16:16] <wm4> other than actual libav* users, but you don't care about them anyway
[16:16] <durandal_1707> lool
[16:17] <wm4> I mean what I'm trying to say is, why would ffmpeg.c care?
[16:18] <ubitux> i'm raising the topic because there is currently likely a license violation
[16:18] <ubitux> now about prefering lgpl about gpl, i actually needs to use the libraries
[16:18] <durandal_1707> i wonder why this was not raised by original author
[16:19] <ubitux> yes, especially when he submitted his wrapper
[16:19] <ubitux> now i need to dig the mailing list about the deshake submission
[16:28] <Compn> i think he wanted different license on it
[16:28] <Compn> iirc
[16:28] <Compn> i dont know why.
[16:34] <ubitux> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2010-April/080827.html mmh
[16:37] <durandal_1707> line 307 of lavc/avpacket.c : i think this leaks
[17:11] <durandal_1707> kierank: why you care about license violators?
[17:11] <kierank> open source trolls on linkedin
[17:11] <kierank> that troll VLC and others for not supporting pro formats yet their support is based on gpl violation
[17:12] <j-b> kierank: take a list
[17:13] <j-b> I'll take a lawyery look at IBC
[17:18] <TimNich> ffmpeg meet at IBC then ?
[17:36] <kierank> TimNich: open source meet at ibc?
[17:36] <kierank> TimNich: are you going to ibc?
[17:37] Action: kierank thought TimNich was on the invite list
[17:50] <TimNich> kierank:  yes, what invite list?
[17:53] <kierank> TimNich: basically I organise an OSS meetup every year at IBC now
[17:53] <kierank> mark came last year
[17:54] <kierank> but it's on Saturday at 1800 at 4.A61a
[17:55] <kierank> there will be beer and snacks
[17:55] <TimNich> I'll put it in my calender
[17:58] <durandal_1707> where is that?
[17:58] <kierank> durandal_1707: ibc show, amsterdam
[17:58] <kierank> TimNich: is there anything you want on the agenda?
[17:58] <TimNich> give me time to think...
[17:59] <kierank> or do you want to say a few words about your organisations' use/interest in OSS
[17:59] <kierank> atm the speakers are (in no particular order) - Jonas/Rob from SVT talking about Casparcg, j-b from VideoLAN, Mike from BBC News, Lisa from Sourcefabric
[18:04] <TimNich> I can give a brief overview odf where it sits...
[18:11] <kierank> hmmm...could end up being bbc heavy
[18:11] <kierank> especially if r&d end up speaking
[18:35] <TimNich> I'm easy...
[18:37] <kierank> there will be an audience discussion session
[18:37] <kierank> which i will try to avoid from sinking into a GPL/patents discussion
[18:38] <kierank> whilst GPL/patents are important they end up clouding the reality of using OSS when the legal issues are resolved and/or ignored
[18:38] <kierank> it's like discussing DRM, the debate goes nowhere
[18:43] <mdsh> But you could discuss how to obtain a license to use ProRes ...  ;-)
[18:52] <kierank> mdsh: you ask freddie mercury
[18:52] <mdsh> kierank: lol
[18:53] <kierank> but anyway there are a lot of large companies using the lavc prores encoder and decoder
[18:56] <cptspiff> anybody here happen to know a public hls+https stream?
[18:56] <mdsh> kierank: I'm possessive no companies would use codecs for which they have not purchased licensed (or found that no license fee is applicable) - but that's off topic and I'll shut up
[20:27] <cone-630> ffmpeg.git 03Michael Niedermayer 07master:9a0e20817aee: avcodec/util: Make size argument of ff_alloc_packet2() int64_t
[20:27] <cone-630> ffmpeg.git 03Michael Niedermayer 07master:904a2864bdaf: avcodec/ffv1enc: fix size used for ff_alloc_packet2()
[20:27] <cone-630> ffmpeg.git 03Michael Niedermayer 07master:3728603f1854: avcodec/ffv1enc: update buffer check for 16bps
[20:27] <cone-630> ffmpeg.git 03Michael Niedermayer 07master:77f521d9e512: avcodec/ffv1enc: check encode_line()s return code
[20:27] <cone-630> ffmpeg.git 03Michael Niedermayer 07master:8393b80b7d94: avcodec/ffv1dec: Support decoding planes as raw PCM in 1.4
[20:27] <cone-630> ffmpeg.git 03Michael Niedermayer 07master:3576b564ec4f: avcodec/ffv1enc: encode slice as raw PCM in 1.4 when the buffer is too small.
[20:51] <cone-630> ffmpeg.git 03Reimar Döffinger 07master:4ebf09c3461c: Make packed B-frame warning message more useful.
[20:51] <cone-630> ffmpeg.git 03Reimar Döffinger 07master:723cf4b29e8b: Move packed B-frames message level to info.
[22:33] <durandal_1707> michaelni: what PCM means in ffv1?
[22:34] <nevcairiel> i would assume the same as PCM in h264?
[22:34] <michaelni> yes
[22:35] <nevcairiel> it does mean pulse-code modulation, the same as the audio acronym. :p
[22:42] <durandal_1707> huh, since when removing av_log optimize anything except size of binary...
[22:49] <nevcairiel> there is a small call overhead
[22:49] <beastd> durandal_1707: depends on what optimize you mean. anyway reimar summerized the challenge quite precisely. i am not a fan of don's proposals in that case. it misses the point that some av_log calls should always be there in any case. if it would gain any significant speed advantage i would guess someone placed an av_log call at the wrong point. but that is not claimed in the mails AFAICT.
[22:59] <cone-630> ffmpeg.git 03Paul B Mahol 07master:a27227d401ad: avcodec/ffv1dec: fix format detection
[22:59] <cone-630> ffmpeg.git 03Paul B Mahol 07master:d1a16564a237: avcodec/ffv1: YUVA(444,422,420) 9, 10 and 16 bit support
[23:01] <durandal_1707> i like that there is way to disable logs, but there is some bugs hiding there
[23:04] <beastd> well is spares some space. so it might be ok. i can't see any huge advantage though. saving space could probably be done more effectively by different measures and i do not know how much space you do actually save with disabling logs after those
[23:07] <beastd> also if it is to obvious how to out compile every av_log to a certain level and someone uses ffmpeg tools build that way could get exhausting to get proper verbose debug logs.
[23:08] <ubitux> wm4: i'm gonna backport the vobsub fixes and a few other things in a moment
[23:09] <ubitux> i wonder how many branches will need that fix..
[23:09] <beastd> ubitux: did backport fix the skip line overread patch already? because i am doing that ATM
[23:09] <ubitux> oh please do
[23:09] <ubitux> i didn't start :)
[23:15] <beastd> k, continuing :)
[23:15] Action: beastd could not have accepted another duplicate work today
[23:15] <ubitux> :D
[23:16] <ubitux> what did i miss?
[23:17] <durandal_1707> beastd: another?
[23:18] <beastd> not in ffmpeg. i wanted to commit a patch in mplayer, but when i had everything ready i compile-tested and went away for making sth to eat. when i returned the compile was finished and reimar committed the patch already.
[23:18] <ubitux> :)
[23:18] <ubitux> morality: eating is bad
[23:19] <beastd> patch was trivial, but patching, testing and writing the commit already took me precious time
[23:19] <ubitux> morality2: making food is not for developers
[23:19] <beastd> yeah, i am never gonna eat again.
[23:19] <ubitux> if eating was good for health we already knew it
[23:20] <ubitux> and so far, everyone before us died, and they all ate
[23:20] <beastd> or maybe i take moral #2 and just don't cook anymore. then i could be eating japanese junk food in front of the computer all the time ;D
[23:21] <durandal_1707> better leave long hanging fruit to someone else
[23:24] <mateo`> cooking is ok and don't take that much time, cleaning all the stuff required for cooking however does
[23:24] <mateo`> that sucks :(
[23:25] <ubitux> soylent to the rescue.
[23:27] <ubitux> ( https://en.wikipedia.org/wiki/Soylent_%28food_substitute%29 )
[23:28] <durandal_1707> you do need cooking
[23:28] <mateo`> "raw chemical powders" sounds fantastic :D
[23:30] Action: michaelni feels like vomiting after reading the ingredients list
[23:30] <ubitux> :D
[23:30] <ubitux> here is an interesting feedback: http://www.fourhourworkweek.com/blog/2013/08/20/soylent/
[23:30] <ubitux> i actually really wants to try this
[23:31] <ubitux> it should be commercialized soon ;)
[23:32] <durandal_1707> got out of chair!
[23:35] <durandal_1707> *get
[23:36] Action: beastd actually enjoys cooking
[23:36] <durandal_1707> from where you get all ingredients?
[23:37] Action: beastd is also happy to own a dishwasher
[23:42] <durandal_1707> 120g of protein? but what protein, there are bunch of them....
[23:47] <ubitux> "raw"
[23:47] <ubitux> it's atomic cooking
[23:48] <ubitux> mmh actually i'm too tired to do the vobsub backports, maybe tomorrow
[23:48] <ubitux> 'night all
[23:48] <beastd> n8 ubitux
[00:00] --- Tue Sep 10 2013