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

[burek]

[00:15] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:78530240715c: avcodec/h264_cabac: Fix use with the checked bitstream-reader
[03:08] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:52d2bcc78632: avcodec/libopenjpegenc: Check the return code of av_frame_ref()
[03:08] <BBB> michaelni: is this the latest version of valgrind?
[03:09] <michaelni> BBB dunno, its ubitux box
[03:09] <BBB> hm...
[03:09] <BBB> ubitux: ^^
[03:12] <BBB> michaelni: because I can't reproduce locally, fate-valgrind is clean for me
[03:14] <michaelni> i can reproduce with 3.8.1 and 3.7.0 (these are the 2 i have installed locally it seems)
[03:17] <BBB> just valgrind ffmpeg -threads 1 -i bla -f framemd5 -?
[03:17] <BBB> valgrind --quiet --dsymutil=yes /Users/ronaldbultje/Projects/ffmpeg/x86-64-gpl/ffmpeg -nostats -cpuflags all -threads 1 -thread_type frame+slice -i /Users/ronaldbultje/Movies/fate-suite-ff/vp9-test-vectors/vp90-2-00-quantizer-46.webm -flags +bitexact -f framemd5 -
[03:17] <BBB> that's what it executes for me
[03:18] <BBB> oh it stumps it to stderr, duh
[03:22] <michaelni> i was testing with whatever ./configure --valgrind=valgrind used and also with just valgrind ./ffmpeg ...
[03:31] <BBB> fuck fuck
[03:32] <BBB> was the emu_edge patch merged?
[03:50] <michaelni> you mean 91e00c4a785d3f4cd44f1044d3e7b1b34fee8b5c ? 
[03:51] <michaelni> the commit message says its not merged
[03:51] <michaelni> similar and conflicting changes where already in IIRC and IIRC someone said to skip vp9 stuff
[03:52] <michaelni> but maybe i misremember
[03:57] <michaelni> hmm actually this one doesnt look very much vp9 related
[04:09] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:a26e9c1040af: avcodec/mjpegenc: Use av_frame_clone() instead of av_frame_ref()
[04:09] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:9b68538fddf6: avcodec/libopenjpegenc: Replace av_frame_alloc() and av_frame_ref() by av_frame_clone()
[04:09] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:40c218c60dce: avcodec/vc1: fix type of tmp
[04:22] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:41003da94a59: avfilter/avfilter: fix use of uninitialized pointer
[04:22] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:4b8c599e8490: avformat/nutenc: fix missing break in switch
[04:41] <BBB> hm it's itxfm-related as ubitux said
[04:41] <BBB> I'm still suspecting a bad interaction between valgrind and asm
[04:41] <BBB> but I'll debug which part exactly
[04:41] <BBB> I can (for now) reproduce with 00-q-64 block 0 (tx32x32 y) where the input is defined but the output isn't with asm, but not c
[04:41] <BBB> it uses a sub16x16 tx
[04:42] <BBB> it also reproduces with a full 32x32 tx (asm again)
[04:42] <BBB> but sub8x8 (corrupt output) doesn't reproduce it
[04:42] <BBB> very odd
[04:42] <BBB> I'll look further, but for now, sleep
[07:22] <ubitux> BBB: valgrind 3.9.0
[11:56] <saste> michaelni, may be possible to reject mails sent to @mplayerhq.hu?
[12:03] <michaelni> saste, you mean ffmpeg-dev at mplayerhq.hu or something else ? the mplayerhq domain is used by mplayer
[12:04] <michaelni> and its probably possible but i dunno how
[12:07] <saste> michaelni, some users are still using the old address (after three years after it has been changed), and I don't want to add custom rules to my .procmail file
[12:07] <nevcairiel> scream at them, loudly
[12:07] <saste> michaelni, yes ffmpeg-devel at mplayerhq.hu, ffmpeg-user and libav-user
[12:08] <saste> nevcairiel, that doesn't work, better to make them aware of the change in the hard way
[12:10] <nevcairiel> well there is two ways the setup went down originally; either someone was lazy and just aliased the two domains so they get the same mboxes, or they are intentionally available on both ... the second case is easy to fix, the first needs someone to become not-so-lazy :p
[12:12] <michaelni> the mail setup was done by arpi, i dont even know where that domain stuff is configured without investigating
[12:12] <michaelni> saste, also you dont need a custom rule just to fix your rules
[12:13] <michaelni> the List-Id points to ffmpeg.org even for a To: mplayerhq.hu mail
[12:22] <cone-883> ffmpeg.git 03Stefano Sabatini 07master:433b153b681d: doc/ffmpeg: reference time syntax sections in ffmpeg-utils for itsoffset and timestamp options
[12:22] <cone-883> ffmpeg.git 03Stefano Sabatini 07master:ca57659440fc: examples/filtering_audio,video: do not call avcodec_register_all()
[12:38] <cone-883> ffmpeg.git 03Ronald S. Bultje 07master:bd01412313c7: vp9: fix mvref finding to adhere to bug in libvpx.
[12:38] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:367245857399: Merge commit 'bd01412313c728400f1fc5448ede0ad8b51da0d1'
[13:03] <cone-883> ffmpeg.git 03Guillaume Martres 07master:50866c8d95bf: vp9: fix bugs in updating coef probabilities with parallelmode=1
[13:03] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:a0e9dfb5ae5e: Merge remote-tracking branch 'qatar/master'
[13:38] <saste> why the packet PTS can be different from the decoder PTS?
[13:38] <saste> but then I see best_effort_ts is equal to the packet PTS
[13:39] <saste> or in other words, what's the best_effort thing about?
[13:39] <av500> random guessing I guess
[13:39] <saste> or in other words, why the decoder changes the input packet PTS?
[13:42] <kierank> 12:39 PM <"av500> random guessing I guess
[13:44] <saste> kierank, not useful answer
[13:44] <kierank> but it's the actual answer
[13:44] <saste> the problem is that there is any guarantee that input PTS == output PTS, not even with copyts
[13:44] <saste> muxers, decoders, and ffmpeg code cooperate  to make it completely impredictable
[13:53] <michaelni> saste, if i guess that with packet pts you mean demuxer pts, then your question "why packet and decoder pts can differ" has the awnser "because both the container and the codec bitstream can store pts and they can differ"
[13:55] <saste> michaelni, ok
[13:55] <saste> why is that happening?
[13:55] <michaelni> and if they differ then thats probably violating some spec
[13:55] <saste> it is happening with a sample I have
[14:00] <av500> what kind of file?
[14:01] <saste> av500, H.264 in MPEG-TS
[14:32] <Keestu> dear all, it is possible to send custom command to rtsp server through ffmpeg ?
[14:37] <j-b> https://trac.videolan.org/vlc/ticket/10451#comment:5 any idea about this backtrace?
[16:59] <saste> michaelni, problem was due to rounding errors from converting timestamps
[16:59] <saste> otoh I cannot set the timebase in the encoder
[16:59] <saste> (the option has no enabled flags, so it is documented but can't be set in the commandline)
[17:00] <saste> OTOH if I enable it then libx264 is confused, since it sets fsp = 1 /tb
[17:00] <saste> fps
[17:16] <kierank> well...I moved to ffmpeg
[17:16] <kierank> was quite painless apart from --enable-avresample
[17:28] <Compn> kierank : welcome, i guess ? :)
[17:28] <Compn> whyd you switch over ?
[17:28] <kierank> Compn: filters, though I have to fix bugs in those
[17:29] <saste> kierank, i'minterested
[17:29] <saste> (about bugs in filters)
[17:29] <kierank> not really a bug but vf_overlay only supports 420 and 444 but it looks like a simple fix
[17:30] <ubitux> how naive
[17:30] <Compn> how many filters have to add colorspace to? :)
[17:30] <kierank> ubitux: naive to be a simple fix?
[17:30] Action: Compn guesses 10bit support
[17:30] <ubitux> kierank: i remember some little crazyness about such thing in overlay
[17:31] <kierank> even if i'm overlaying *everything* in 422 mode?
[17:31] <ubitux> ask saste about the details i don't know :)
[17:36] <saste> overlay is using drawutils, so we need to extend that and all user filters will be enabled to support 10 bits support (including pad)
[17:36] <kierank> I don't need 10-bit
[17:36] <kierank> I need 422 in overlay
[17:36] <kierank> but you already support 420 and 444 so i don't see why 422 is special
[17:38] <saste> kierank, so you need to extend format mode
[17:38] <kierank> yeah
[17:49] <cbsrobot> subtitling directly in 10-bit would be a nice enhancement
[17:49] <cbsrobot> or generally in > 8-bit
[17:49] <nevcairiel> blending in higher bitdepths isnt really hard
[17:49] <nevcairiel> but is it worth it? :)
[17:53] <cbsrobot> I have a lot of 10-bit clips and it would be awesome to add hardsubs without degrading to 8-bit
[17:54] <saste> kierank, untested patch sent, please report
[18:03] <ubitux> saste: we should make more tests with odd sizes :)
[18:03] <saste> ubitux, why?
[18:04] <ubitux> because it's easy to break without noticing
[18:04] <saste> if you break and you notice is no fun anymore
[18:05] <ubitux> :)
[18:38] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:746350ea0f7b: avcodec/mpeg12dec: Make mpeg2_fast_decode_block_intra() more robust by breaking out on invalid vlcs
[18:38] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:0a59055167ee: avcodec/mpeg12dec: check for overread in mpeg1_fast_decode_block_inter()
[18:38] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:0c8e5fb21183: avcodec/mpeg12dec: Optimize mpeg1_decode_block_intra()
[18:38] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:d82eccea2bf9: avcodec/mpeg12dec: check block index in mpeg2_fast_decode_block_non_intra()
[18:39] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:76b5e99ce9c1: avcodec/mpeg12dec: Check for overread in mpeg_decode_slice()
[18:39] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:5f54756f7e4f: avcodec/mpeg12dec: Disable the checked bitstream reader
[18:39] <cone-883> ffmpeg.git 03Michael Niedermayer 07master:934bb11ad79a: avcodec/mpeg12dec: fix mis-indented line
[18:47] <michaelni> j-b, crash should be fixed, a more complete fix is on the ML
[18:48] <j-b> michaelni: amazing
[18:49] <j-b> but no more --fast for mpeg12?
[18:52] <kierank> hmm maybe i didn't need saste's patfch after all
[18:54] <Compn> nevcairiel : its always worth it
[18:54] <Compn> more bits! 
[18:58] <michaelni> j-b, its still there and can still with some "luck" crash, with the patch from the ML its renamed to fast_crash which should ensure that noone can misunderstand what the option does
[18:59] <j-b> michaelni: but, but, but, it makes it faster!! :)
[19:00] <michaelni> well thats why i tried to make it more robust
[19:00] <michaelni> but ive no idea how successfull i was
[19:01] <michaelni> also mpeg1 / 2 should be faster now with and without "fast" than before
[19:02] <Compn> awesome
[19:02] <j-b> nice
[19:02] <Compn> michaelni sped up mpeg1/2 :)
[19:03] <j-b> Compn: don't joke. It's 70% of our libavcodec related crashes on iOS
[19:04] <Compn> i'm happy its faster
[19:04] <Compn> but you have that many crashes on ios ? :\
[19:04] <Compn> i thought ffmpeg was ROBUST! :P
[19:04] <j-b> haha
[19:04] <j-b> just fun
[20:35] <jnvsor> Quick question about AVRationals, what's the preferred way to reduce it to a framerate?
[20:36] <jnvsor> av_q2d()?
[20:44] <michaelni> av_q2d() is the obvious way yes
[20:45] <michaelni> if instead you want a simpler rational as output theres av_reduce()
[20:48] <jnvsor> I'm trying to port timecode.c from int to rational, quite interesting
[20:49] <jnvsor> Looks like there's a LOT of stuff relying on that int. Ew
[21:14] <cone-883> ffmpeg.git 03João Bernardo 07master:290326711b1a: avutil/opt: Better print representation of number limits
[21:17] <jnvsor> Right, so I've got it compiling using doubles from the drawtext filter timecode instead of ints - is there some sort of test suite I should run to make sure I haven't broken anything else?
[22:18] <Compn> jnvsor : fate test ? 
[22:21] <jnvsor> Compn: Sure. Any idea how to set that up?
[22:21] <jnvsor> Compn: nvm, found the web page
[22:22] Action: BBB pokes ubitux 
[22:24] <Compn> make fate
[22:24] <Compn> after pulling the fate samples 
[22:24] <Compn> or something, i am not sure :)
[22:29] <cone-883> ffmpeg.git 03Serhii Marchuk 07master:f8051bd31a23: mpegts muxer: Change the default subtitle language to "und"
[22:29] <cone-883> ffmpeg.git 03Serhii Marchuk 07master:2ebee19e1ed2: mpegts muxer: restore PMT table of DVB teletext from extradata
[22:29] <cone-883> ffmpeg.git 03Serhii Marchuk 07master:1d0738505386: mpegts demuxer: store PMT values of DVB teletext to extradata
[22:31] <jnvsor> So if I have a fate error, how do I debug it? I'm just seeing a bunch of FFmpeg runs in the .err file and I don't know which is causing the issue
[22:34] <BBB> make fate will stop if there's an error
[22:34] <ubitux> BBB: hey.
[22:35] <ubitux> lpf this week end
[22:35] <ubitux> i'm half dead from my week + lack of previous week end; will get some sleep tonight and will be ready again tomorrow :)
[22:37] <BBB> no, just wanted to ask for review of the other patches
[22:37] <BBB> lpf just whenever you have time and energy, didn't mean to push you on that
[22:38] <ubitux> BBB: i saw the SWAPs update, the 3 patchs look ok
[22:38] <ubitux> unless you meant another patch(es) i have missed?
[22:40] <BBB> no, just that one
[22:40] <BBB> did you ok them? maybe I missed it
[22:41] <ubitux> no i didn't reply, sorry :)
[23:09] <BBB> aha
[23:09] <BBB> ok
[23:09] <BBB> so
[23:09] <BBB> valgrind error
[23:09] <BBB> I have a pretty solid hypothesis
[23:10] <BBB> so you guys see how we do stack arithmetic to get the correct location on the stack to place the idct?
[23:10] <BBB> so we do sub rsp, 2048
[23:11] <BBB> for (i=0;i<4;i++) { do idct32x8_1d and place in rsp[0-512]; add rsp, 512 } sub rsp, 2048
[23:11] <BBB> and then the second idct32x8_1d x4
[23:11] <BBB> that's the error
[23:11] <BBB> algrind thinks it's undefined after add rsp, x
[23:13] <BBB> (it being the memory under rsp), so after add rsp, 512, valgrind thinks the first 512 bytes become undefined agian
[23:13] <jnvsor> Is the last run in a fate .err file the one that caused the error or could it be any of them?
[23:14] <BBB> I'm not sure that's defined in the C standard or anywhere
[23:14] <BBB> jnvsor: last
[23:15] <BBB> ubitux: any opinions on the above? or someone wanna read the c spec or the platform specs on what any of this means?
[23:15] <BBB> I don't think I've ever come across something like that
[23:17] <jnvsor> So I've found the error - a nice nondescript "Input/output error". Any way to track it down a bit further?
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:86bee7984e30: AVFormatContext: add metadata_header_padding field
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:72eeb18468b0: lavf/flacenc: use metadata_header_padding
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:c14b011a97f3: lavf/flacenc: fix comment after previous change
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:0de03fd6a1f1: lavf/id3v2enc: use metadata_header_padding
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:67270ccd3af9: lavf/id3v2enc: update comment about minimum padding
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:fa20babb4661: lavf/avienc: use metadata_header_padding
[23:19] <cone-883> ffmpeg.git 03James Darnley 07master:2efdccac87cb: lavf/avienc: cosmetic indent
[23:36] <jnvsor> Can I get fate to run the failing test in gdb or something?
[23:37] <mark4o> BBB: if a signal handler is run then it will overwrite anything at the stack pointer
[23:37] <nevcairiel> you can use "make V=1 fate-test-name", it'll show you the command used, and you can use that command line in gdb
[23:38] <BBB> jnvsor: make V=1 fate-name-of-test
[23:38] <BBB> oh late sorry
[23:39] <BBB> hm I'll add a stackpointer to resolve this
[23:39] <BBB> kind of annoying
[23:39] <BBB> but ok
[00:00] --- Sat Jan 25 2014