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

[burek]

[00:00] <ohsix> and a lot of it's not relevant anymore, except for a few people still putting them on cdr's and using those old players
[00:00] <Daemon404> ohsix, ironically that goes against what the scene is supposed to do :P
[00:00] <Daemon404> that is "dont leak from our topsite to torrents!"
[00:00] <Daemon404> ;P
[00:00] <iive> things like sprites, partial tranformations and the deadfull body modeling.
[00:00] <ohsix> i don't purport to proscribe what a "scene" is supposed to do :<
[00:00] <iive> deadfull->dreadful 
[00:01] <ohsix> before there were torrents things still got leaked, there was posting to newsgroups, irc bots, dump sites; torrents aren't all that interesting in that regard
[00:01] <Daemon404> i know
[00:02] <ubitux> https://trac.handbrake.fr/wiki/LibHandBrakeSync  it would be nice to have such article about the way it's handled in ffmpeg
[00:02] <ubitux> i'm pretty curious about it
[00:03] <Daemon404> iive, btw, the bulk of my experience with the whole asp->avc transition has been related to pc playback and not hardware playback
[00:03] <Daemon404> so im a tad biased, if you hadnt noticed :P
[00:03] <Daemon404> \
[00:05] <ohsix> i wish i had something better than the wii to play stuff back, but in practice it's not very limiting, it's not HD and stuff looks like crap on an old tv anyways (xvid actually looks quite good with the temporal smoothing of a crt vs. what it looks like anywhere else :)
[00:05] <Daemon404> crts can do wonders for the eyes
[00:05] <Daemon404> maybe nto so much for detail
[00:05] <ohsix> i say i wish, but i mean if it didn't do it already i wouldn't play stuff on tv; and i'm not going to spend 50$ on a widget :]
[00:06] <Daemon404> most people i know seem to use xbox or ps3 and either playback stuff directory or stream (transcoding on teh fly to something else)
[00:07] <Daemon404> since they already own for for gaming
[00:07] Action: Daemon404 just uses a monitor + pc
[00:08] <ohsix> my pc with the nice speakers and display stubbornly will not move like my laptop, or the wii which i keep at an entirely different house where stuff is actually played on the tv :P
[00:09] <Daemon404> your laptop doesnt do hdmi/dvi/vga out?
[00:09] <ohsix> has vga, but the tv doesn't
[00:10] <Daemon404> ah.
[00:12] <ohsix> unless it's a foreign film i tend to be dividing my attention a bit anyways, tying up the laptop would suck (unless i'm the only one watching it)
[00:12] <iive> the crt/tv have about 1.7 gamma, while most lcd are about 2.2 or 2.4
[00:28] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rc2b8dea182 10ffmpeg/libavcodec/wmaenc.c: 
[00:28] <CIA-17> ffmpeg: wmaenc: limit block_align to MAX_CODED_SUPERFRAME_SIZE
[00:28] <CIA-17> ffmpeg: This is near the theoretical limit for wma frame size and is the most that
[00:28] <CIA-17> ffmpeg: our decoder can handle. Allowing higher bit rates will just end up padding
[00:28] <CIA-17> ffmpeg: each frame with empty bytes.
[00:28] <CIA-17> ffmpeg: Fixes invalid writes for avconv when using very high bit rates.
[00:28] <CIA-17> ffmpeg: CC:libav-stable at libav.org
[00:29] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r1ec075cfec 10ffmpeg/libavcodec/wmaenc.c: 
[00:29] <CIA-17> ffmpeg: wmaenc: limit allowed sample rate to 48kHz
[00:29] <CIA-17> ffmpeg: ff_wma_init() allows up to 50kHz, but this generates an exponent band
[00:29] <CIA-17> ffmpeg: size table that requires 65 bands. The code assumes 25 bands in many
[00:29] <CIA-17> ffmpeg: places, and using sample rates higher than 48kHz will lead to buffer
[00:29] <CIA-17> ffmpeg: overwrites.
[00:29] <CIA-17> ffmpeg: CC:libav-stable at libav.org
[00:29] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r5d652e063b 10ffmpeg/libavcodec/wmaenc.c: 
[00:29] <CIA-17> ffmpeg: wmaenc: check final frame size against output packet size
[00:29] <CIA-17> ffmpeg: Currently we have an assert() that prevents the frame from being too large,
[00:29] <CIA-17> ffmpeg: Signed-off-by: Justin Ruggles <justin.ruggles at gmail.com>
[00:29] <CIA-17> ffmpeg: 03Loren Merritt 07master * r0f53d0cf4b 10ffmpeg/libavutil/x86/x86inc.asm: 
[00:29] <CIA-17> ffmpeg: x86inc: don't "bake" stack_offset in named arguments.
[00:29] <CIA-17> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[00:29] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r8249a23fc1 10ffmpeg/libswscale/x86/output.asm: swscale: remove now unnecessary hack.
[00:29] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * re25be47154 10ffmpeg/libavcodec/x86/ (vp8dsp-init.c vp8dsp.asm): vp8: convert idct/mc x86 assembly to use cpuflags().
[00:29] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r28170f1a39 10ffmpeg/libavcodec/x86/vp8dsp.asm: vp8: convert loopfilter x86 assembly to use cpuflags().
[00:29] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * r8476ca3b4e 10ffmpeg/libavcodec/x86/vp8dsp.asm: vp8: convert idct x86 assembly to use named arguments.
[00:29] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * rb4188f0d46 10ffmpeg/libavcodec/x86/vp8dsp.asm: vp8: convert simple loopfilter x86 assembly to use named arguments.
[00:29] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r6c7a01621c 10ffmpeg/libavcodec/nellymoserenc.c: nellymoserenc: use proper MDCT overlap delay
[00:29] <CIA-17> ffmpeg: 03Ronald S. Bultje 07master * rdccb2cd3f9 10ffmpeg/libswscale/x86/output.asm: 
[00:29] <CIA-17> ffmpeg: swscale: make %rep unconditional.
[00:29] <CIA-17> (42 lines omitted)
[00:29] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rb0350c1c30 10ffmpeg/libavcodec/ (ra144.h ra144enc.c): 
[00:29] <CIA-17> ffmpeg: ra144enc: fix end-of-stream handling
[00:29] <CIA-17> ffmpeg: Use CODEC_CAP_DELAY and CODEC_CAP_SMALL_LAST_FRAME to properly pad and flush
[00:29] <CIA-17> ffmpeg: the encoder at the end of encoding. This is needed in order to have all input
[00:29] <CIA-17> ffmpeg: samples decoded.
[02:41] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rccb76ad91f 10ffmpeg/libavcodec/cook.c: 
[02:41] <CIA-17> ffmpeg: cook: check decouple values.
[02:41] <CIA-17> ffmpeg: This fixes a out of global array read in the cplscale* tables.
[02:41] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[02:41] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:41] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * re75518e18d 10ffmpeg/libavcodec/indeo3.c: 
[02:41] <CIA-17> ffmpeg: indeo3: move MV check up.
[02:41] <CIA-17> ffmpeg: This adds checking for modes >= 10.
[02:41] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[02:41] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:10] <Compn> hyc : libav is thinking of reinventing the rtmpe wheel as a summer of code project. maybe you could talk some sense into wbs and lu_zero :)
[04:10] <Compn> http://wiki.multimedia.cx/index.php?title=Libav_Summer_Of_Code_2012#RTMP.5BE.7CS.7CT.7CTE.5D_protocol_implementation
[04:46] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r263bb6edcf 10ffmpeg/libavcodec/bit_depth_template.c: (log message trimmed)
[04:46] <CIA-17> ffmpeg: bit_depth_template: use av_clip_uint8 over crop_tab.
[04:46] <CIA-17> ffmpeg: This fixes some global out of array reads and wrong cliping.
[04:46] <CIA-17> ffmpeg: No speed difference meassurable under clang on i5
[04:46] <CIA-17> ffmpeg: also all important code paths on all important platforms should
[04:46] <CIA-17> ffmpeg: use SIMD.
[04:46] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[04:46] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r1007a805a4 10ffmpeg/libavcodec/smc.c: 
[04:46] <CIA-17> ffmpeg: smc: Fix overread.
[04:46] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[04:46] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:08] Action: Daemon404 really wonders how many of these loads of things these 2 find are with scripts/tools
[05:14] <Compn> where are these reported ?
[05:14] <Compn> i'd like to know how many million other commits i should expect :D
[05:14] <Daemon404> that was my next question
[05:14] <Daemon404> inb4 private email
[05:15] Action: Compn guesses ffmpeg-legal
[05:15] <Daemon404> well
[05:15] <Daemon404> libav is making a buttload of "Mateusz "j00ru" Jurczyk and Gynvael Coldwind" commits too
[05:15] <Compn> yeah
[05:16] <Compn> since thats the only list i'm not on
[05:16] <Compn> ;D
[05:16] <Compn> and whatever priv lists libav has...
[05:25] <Daemon404> i dont think they have priv lists
[05:26] <Compn> priv irc at least
[05:26] <Compn> they didnt plan the fork in public anyways
[05:26] <Daemon404> im not sure why theyd have a private channel
[05:27] <Daemon404> other than :conspiracytheories:
[05:27] <Compn> and libav-devel irc and ml is absolutely silent , discussion wise
[05:28] <Daemon404> private email and PM?
[05:28] <Compn> could be
[05:28] <Daemon404> doesnt really matter to me
[05:28] <Compn> same 
[05:28] <Daemon404> im just curious how many billion more vulns these 2 guys found
[05:28] <Compn> i'm curious what site they run
[05:29] <Compn> like 'superleetsecurity.com' or something
[05:29] <Daemon404> i googled it and found their sites
[05:29] <Compn> which most security researchers run
[05:29] <Compn> ah
[05:29] <Daemon404> blogs rather
[05:29] <Compn> well...
[05:29] <Daemon404> with some windows kernel sploit papers
[05:29] <Daemon404> and such
[05:29] <Daemon404> think they work for google
[05:29] <Daemon404> (i.e. chrome-related?)
[05:30] <Compn> chrome dropped ffmpeg iirc
[05:30] <Compn> but maybe they are fixing it for youtube
[05:30] <Daemon404> youtube uses ffmpeg
[05:30] <Daemon404> i know that
[05:31] <Compn> should be easy enough to run all of the ffmpeg stuff in virtual sandbox and just come up with scripts to verify that 20kb mpeg file shouldnt take 99 hours to encode..
[05:31] <Compn> what i'm trying to say is , isnt all of this time better spent on codecs instead of mem leaks, overreads, exploits n such ? :P
[05:31] <Daemon404> id imagine theyre CVEs
[05:31] <Daemon404> i guess
[05:32] <Compn> yes some are
[05:33] Action: Daemon404 wanders off to watch some tv before sleeping
[05:36] <Compn> http://osvdb.org/creditees/6602-matthew-j00ru-jurczyk
[11:41] <kriegerod> Please could somebody look at by bugreport https://ffmpeg.org/trac/ffmpeg/ticket/1034 ? First of all i want to know do i do the right thing, and is it indeed the ffmpeg bug
[14:33] Last message repeated 1 time(s).
[15:10] <michaelni> kriegerod, ill look at it
[15:48] <michaelni> kriegerod, the problem is the buffer size for audio packets in mpegenc is fixed to 4096 and the pcm packets can be random sizes
[15:48] <michaelni> do you know what is the correct buffer size for pcm ? maybe 4096 is correct but i dunno ...
[15:50] <michaelni> video vbv sizes are written all over the net, audio seems not that commonly mentioned
[15:50] <kriegerod> not sure, but log in my ticket says "size=6144", maybe that's frame data size (for stereo 48kHz case)
[15:51] <michaelni> the buffer size for pcm in dvd should be written in the dvd spec
[15:51] <michaelni> but they cost $$$
[15:52] <kriegerod> so the limit is #define MAX_PAYLOAD_SIZE 4096?
[15:52] <kriegerod> in mpegenc.c:31
[15:53] <michaelni> nope, its stream->max_buffer_size = 4 * 1024;
[15:53] <michaelni> the comments tell us its correct for VCD
[15:56] <michaelni> also the pcm encoder sets CODEC_CAP_VARIABLE_FRAME_SIZE which makes it produce unpredictable frame sizes
[15:58] <michaelni> the pcm encoder used for mpeg should not set that and instead have frame_size set to something thats smaller than the buffer size
[15:58] <michaelni> or the mpeg muxer would have to more intelligently split pcm packets
[16:01] <kriegerod> thanks for help
[16:02] <Tjoppen> michaelni: compute_pkt_fields() messes up timestamps for intra-only MPEG-2 that doesn't have the low_delay flag set
[16:03] <Tjoppen> the "invalid dts/pts combination" thing is at fault
[16:03] <Tjoppen> setting CODEC_FLAG_LOW_DELAY doesn't help (it's a D-10 MXF file)
[16:30] <Tjoppen> it's actually guessing the same dts=0 twice
[16:43] <michaelni> Tjoppen, can i have a sample to reproduce this ?
[16:45] <Tjoppen> I'll produce a .mov to rule out mxfdec
[16:45] <Tjoppen> I suspect any IMX file from FCP would trigger it too
[16:48] <Tjoppen> of course it works fine with a mov file. hm
[16:55] <Tjoppen> http://titan.codemill.se/~tomhar/samples/sony-d10.mxf here's the sample anyway. I'm trying to get pts = dts = current_edit_unit since it's intra-only
[16:59] <Tjoppen> simple idea: only do that workaround for mpeg-ps
[17:00] <Tjoppen> raw video stream: http://titan.codemill.se/~tomhar/samples/sony-d10-V1.m2v
[17:09] <michaelni> Tjoppen, if low_delay is 0 in the mpeg headers then dts != pts for intra only
[17:15] <Tjoppen> you mean I and P? judging by the code that is. B-frames display as soon as they decode AFAICT
[17:15] <Tjoppen> ooh, wait.. I can just set PTS can't I?
[17:16] <Tjoppen> and leave DTS unset..
[17:18] <cbsrobot> michaelni: libavcodec/cook.c:773:9: error: non-void function 'decouple_info' should return a value
[17:18] <Tjoppen> hrm, of course not. well, dts ended up == pts at least, only both initially -1
[17:19] <michaelni> Tjoppen, B frames do have dts==pts but there are no B frames in intra only 
[17:20] <Tjoppen> good, then we're on the same level. in this case the intra-only stream has low_delay = 0 though
[17:20] <cbsrobot> I'm not sure if it should return 0 or -1 ...
[17:22] <Tjoppen> heh, "pkt->pts = mxf->current_edit_unit; pkt->dts = pkt->pts - 1;" works
[17:23] <michaelni> cbsrobot, both 0 i suspect
[17:24] <michaelni> Tjoppen, looks correct if 1 is the frame duration
[17:27] <Tjoppen> it is. MXF is CFR only (AFAICT)
[17:27] <Tjoppen> however, shouldn't this ideally depend on whether low_delay = 0 or 1? as in dts = pts - low_delay + 1?
[17:28] <michaelni> yes, indeed
[17:28] <michaelni> low_delay is rarely 1 though from my experience
[17:28] <Tjoppen> the problem then is that the demuxer doesn't know this
[17:28] <michaelni> but it may be different in mpeg in mxf, i dunno
[17:29] <michaelni> Tjoppen, you could set just pts
[17:29] <Tjoppen> I tried that. didn't work properly. still got first pts = -1
[17:29] <Tjoppen> -1, 1, 2, 3
[17:29] <michaelni> hmm
[17:30] <michaelni> what changed the first pts ?
[17:30] <michaelni> looks like a bug to me
[17:30] <Tjoppen> compute_pkt_fields() did
[17:31] <michaelni> do you know what part exactly ?
[17:31] <Tjoppen> down in "if((delay==0 || (delay==1 && pc)) /*&& st->codec->codec_id != CODEC_ID_H264*/){" 
[17:31] <Tjoppen> in "pkt->dts = st->last_IP_pts;"  last_IP_pts is zero twice
[17:32] <Tjoppen> so {dts,pts} ends up like {0,0},{0,1},{1,2} which further down gets "fixed" to {-1,-1},{0,1},{1,2}
[17:32] <CIA-17> ffmpeg: 03Nicolas George 07master * r3073aadf2d 10ffmpeg/libavdevice/ (alsa-audio-dec.c jack_audio.c timefilter.c timefilter.h): (log message trimmed)
[17:32] <CIA-17> ffmpeg: timefilter: internally compute feedback factors.
[17:32] <CIA-17> ffmpeg: The feedback factors for the timefilter are directly computed from
[17:32] <CIA-17> ffmpeg: the expected period. This commit changes the init function to accept
[17:32] <CIA-17> ffmpeg: the period itself and compute the feedback factors internally,
[17:32] <CIA-17> ffmpeg: rather than having all client code duplicate the formulas.
[17:32] <CIA-17> ffmpeg: This commit also actually fixes the formulas: the current code had
[17:32] <CIA-17> ffmpeg: 03Nicolas George 07master * r9bbe6ed1e0 10ffmpeg/libavdevice/timefilter.c: 
[17:32] <CIA-17> ffmpeg: timefilter: allow variable periods.
[17:32] <CIA-17> ffmpeg: Initially found and designed by Michael Niedermayer.
[17:32] <CIA-17> ffmpeg: 03Nicolas George 07master * r456d65a5c6 10ffmpeg/libavdevice/ (alsa-audio-dec.c alsa-audio.h): 
[17:32] <CIA-17> ffmpeg: alsa: fix timefilter usage.
[17:32] <CIA-17> ffmpeg: The period argument is supposed to be the number of samples since
[17:33] <Tjoppen> one fix could be to use st->cur_dts if it's set. not sure how OK that is
[17:35] <michaelni> Tjoppen, "further down" ?
[17:35] <Tjoppen> in the "if (presentation_delayed) {" block
[17:37] <michaelni> in update_initial_timestamps() ?
[17:37] <Tjoppen> no, compute_pkt_fields()
[17:37] <michaelni> which line changes the pts ?
[17:41] <Tjoppen> I don't know. however, making sure dts doesn't end up duplicated like that fixes the problem
[17:51] <michaelni> i cant see any place except update_initial_timestamps() that can chnage the pts
[17:51] <michaelni> that is in the if() you quoted
[17:56] <Tjoppen> I'll try to cobble together a feature branch to demonstrate this
[18:54] <michaelni> Tjoppen, i can probably fix compute_pkt stuff when ive a testcase ...
[19:14] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rc99bd29462 10ffmpeg/libavcodec/wmaenc.c: 
[19:14] <CIA-17> ffmpeg: Revert "wmaenc: check final frame size against output packet size"
[19:14] <CIA-17> ffmpeg: This condition cannot happen, if it can it is a bug that MUST be fixed.
[19:14] <CIA-17> ffmpeg: And i very happily volunteer to fix it if someone reports a case to
[19:14] <CIA-17> ffmpeg: me that fails.
[19:14] <CIA-17> ffmpeg: This reverts commit 5d652e063bd3a180f9de8915e5137aa4f938846d.
[19:14] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r0d92e5a682 10ffmpeg/libavcodec/wmaenc.c: 
[19:14] <CIA-17> ffmpeg: wmaenc: add assert to check encode_superframe() return.
[19:14] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:14] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r0a7bf34042 10ffmpeg/libavcodec/wmaenc.c: 
[19:14] <CIA-17> ffmpeg: wmaenc: change some asserts to av_assert0.
[19:14] <CIA-17> ffmpeg: This ensures they are always checked
[19:14] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:04] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * r18794000c6 10ffmpeg/libavcodec/wmalosslessdec.c: 
[20:04] <CIA-17> ffmpeg: Remove AV_LOG_DEBUG from av_dlog() calls.
[20:04] <CIA-17> ffmpeg: AV_LOG_DEBUG is forced by the av_dlog definition.
[20:55] <Tjoppen> michaelni: I'll try to create one for wednesday
[22:46] <CIA-17> ffmpeg: 03Derek Buitenhuis 07master * rd6e4e69a49 10ffmpeg/libavcodec/ (libutvideo.cpp libutvideo.h): 
[22:46] <CIA-17> ffmpeg: libutvideo: Move structs and includes to header
[22:46] <CIA-17> ffmpeg: This is so the forthcoming encoder wrapper can share
[22:46] <CIA-17> ffmpeg: them.
[22:46] <CIA-17> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:46] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:46] <CIA-17> ffmpeg: 03Derek Buitenhuis 07master * r01606d10e6 10ffmpeg/ (9 files in 3 dirs): 
[22:46] <CIA-17> ffmpeg: libutvideo: Add Ut Video encoder wrapper
[22:46] <CIA-17> ffmpeg: All colorspaces are supported.
[22:46] <CIA-17> ffmpeg: Renamed libutvideo.cpp to libutvideodec.cpp.
[22:46] <CIA-17> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:46] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:04] <Daemon404> \o/
[23:08] <Compn> heh
[23:08] <Compn> dont worry, anime people will complain about something else in ffmpeg 
[23:08] <Compn> its what anime people do. ;D
[23:08] <Daemon404> you do realize thats me
[23:08] <Daemon404> right?
[23:09] <Daemon404> re: anime people
[23:09] <Compn> yes
[23:09] <Compn> patch author and anime person.
[23:09] <Compn> you
[23:09] <Daemon404> lul
[23:09] <Compn> or your buddies
[23:09] <Compn> cohorts
[23:10] <Compn> japan anime sucks so hard now :P
[23:10] Action: Compn trolls some more
[23:14] <gnafu> Compn: Sounds like you're watching /hentai/, rather than anime.
[23:15] <Daemon404> nowadays, anime == hentai
[23:15] <Compn> yeah, they did fanservice for a while
[23:15] <Compn> now its just straight up porn
[23:15] <Compn> moe fad was pretty brutal too
[23:16] <Compn> wheres the next fad anime to sell to the kiddies ?
[23:36] <iive> what is fad?
[23:38] <ubitux> Compn: to my surprise, i saw some recent good stuff; usagi drop was nice for instance
[23:38] <ubitux> steins;gate wasn't that bad either, except the beginning
[00:00] --- Tue Mar  6 2012