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

[burek]

[00:15] <cone-159> ffmpeg.git 03plepere 07master:63832e01c3c7: hvcodec/x86/hevcdsp: make macros more modular to support functions that are not sse4
[02:11] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:6df33c4926c8: avcodec: include GET_RL_VLC() in trace output
[02:11] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:e54c052beedb: avcodec/mpeg4videodec: print run/level/index values
[02:43] <michaelni> BBB, Daemon404, do you have comments on  "[FFmpeg-devel] [PATCH 2/2] configure: Use intel math.h header" ? (its about intel/ms compilers)
[03:35] <Snowleaksange> sorry for irate comments earlier.  ffmpeg is pretty sweet.  was just frustated cuz i hit single deadend.  but it didnt even take me long to implement libpng, libjpeg and bmp which is all i needed
[04:13] <BBB> michaelni: I don't really know, admittedly kinda very hacky but I can't really easily come up with something clean
[04:30] <michaelni> Snowleaksange, np, just if you find a fixable problem and have an idea on how we can fix it, dont hesitate to tell us
[04:31] <michaelni> about image2, for multiple image support with %d or otherwise something capable to open multiple "things" is needed
[04:34] <michaelni> BBB, so i should apply it ? or do you think it makes sense to wait (i agree wholeheartly that its ugly ...)
[04:57] <michaelni> nevcairiel, it seems ffmpeg_dxva2.c doesnt build on or fate box and also isnt disabled by configure (see http://fate.ffmpeg.org/history.cgi?slot=x86_32-ubuntu-mingw32-gcc)
[05:21] <cone-529> ffmpeg.git 03Michael Niedermayer 07master:341cacb9ac1b: avcodec/x86/hevcdsp_init: fix build failure with --disable-mmx
[07:39] <ubitux> should i add an asan and ubsan fate instances?
[07:42] <ubitux> mmh we don't have a tsan either?
[11:09] <ubitux> mmh it's strange i have a clang/tsan instance but i don't see it on fate.ffmpeg.org
[11:14] <ubitux> oh wow it's "locked" meh
[11:36] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20140509093218&slot=x86_64-archlinux-gcc-ubsan
[11:36] <ubitux> > libavcodec/mpegaudiodec_template.c:219:33: runtime error: left shift of negative value -1
[11:37] <ubitux> > libavcodec/golomb.h:75:13: runtime error: shift exponent -31 is negative
[11:37] <ubitux> i added gcc-asan and gcc-tsan too, they're still running
[11:38] <JEEB> nice
[11:38] <wm4> indeed
[11:42] <nevcairiel> michaelni: apparently that fate box has a broken dxva2api header. iirc classic mingw32 didn't ship that header at all, so it must be a third party install. if you have access to that box, can you send me the dxva2api.h, so i can check it out and build a test to check it?
[11:51] <nevcairiel> (not that i consider classic mingw32 still to be relevant in the real world)
[11:55] <JEEB> yeah, it has been very well made irrelevant
[12:02] <wm4> wow these responses are so assholish
[12:02] <wm4> apparently you can nest extern"C" blocks
[12:03] <wm4> so it should actually be no problem to add them to the headers
[12:03] <nevcairiel> the argument pro is equally stupid though, its not really anoying or stupid, its well documented that you need to, and thats that
[12:04] <wm4> there's no technical reason to require every API user to do this, other than being assholes
[12:22] <ubitux> ubsan/asan/tsan fate instances available
[12:23] <ubitux> just like helgrind & drd, tsan detects has a shitload of problems, probably always the same issue
[12:24] <ubitux> i hope nicolas' patch is applied soon
[12:34] <michaelni> nevcairiel, http://pastebin.com/v770na2m (its debians mingw IIRC)
[12:55] <BBB> tsan lol
[12:56] <BBB> http://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/ ftw :-p
[13:06] <j-b> oh god, that seems like a HACK
[13:13] <BBB> hi j-b
[13:17] <compn> we may be looking at different failures at the same time (as is demonstrated by the different outputs for the 2 shown failures).
[13:17] <compn> nooo
[13:21] <nevcairiel> michaelni: as i thought, the header is just broken, it uses wrong variable names in some defines .. guess that needs a test
[13:21] <j-b> creating invalid files because an IE plugin does not support it...
[13:23] <compn> you're just upset internet explorer is turning into a media player :P
[13:24] <compn> who needs vlc, it plays right in the browser ;)
[13:25] <j-b> compn: your trolls are less strong those days
[13:25] <kierank> less of a troll and more of the truth =p
[13:27] <BBB> Compn: well it was different failures caused by the same bug
[13:28] <BBB> Compn: so the patch created from one test case fixed all of the bad md5s in that particular file
[13:28] <compn> yes, luckily it wasnt multiple bugs :)
[13:28] <BBB> that would've sucked, yes
[13:28] <BBB> but other files showed different bugs
[13:29] <compn> are we recording fate for random test failures like that ?
[13:29] <BBB> not systematically
[13:29] <compn> i mean does fate test 1233 fail once in 100 runs ?
[13:29] <BBB> right, not systematically
[13:29] <BBB> we probably should, esp. for multithreaded codecs and fate boxes, but we don't
[13:30] <BBB> maybe someone wants to hack on fate and extend it to do this?
[13:31] <BBB> also... someone broke fate comment strings for darwin
[13:31] <BBB> "gcc 4.6.4 (MacPots gcc46 4.6.4_3+univesal)"
[13:31] <BBB> MacPoRRRRts univeRRRRRsal?
[13:31] <BBB> someone hates the r
[13:31] <compn> maybe is broken key 
[13:32] <compn> on an old broken keyboard :P
[13:33] <BBB> indeed
[13:33] <BBB> is someone fixing hevc asm on windows?
[13:44] <cone-85> ffmpeg.git 03Michael Niedermayer 07master:0be95996d0a0: avcodec/mpegaudiodec_template: make shift unsigned to avoid undefined behavior
[13:44] <cone-85> ffmpeg.git 03Michael Niedermayer 07master:2201d1a0f8c5: avcodec/hevc: Fix undefined shifts
[14:02] <ubitux> mmh
[14:02] <ubitux> 56ee3f9de7b9f6090d599a27d33a392890a2f7b8 caused a regression it seems
[14:04] <ubitux> btw, didn't we have some kind of ffbisect at some point?
[14:04] <nevcairiel> should still exist
[14:04] <Daemon404> tools/ ?
[14:04] <nevcairiel> you need to use tools/bisect-create to create the script
[14:05] <Daemon404> ah yea
[14:05] <ubitux> ah that's because i'm in a bisect branch obviously
[14:05] <ubitux> in the other one state
[14:05] <nevcairiel> because otherwise it would overwrite itself
[14:08] <ubitux> yeah well i confirm that's the regression, meh
[14:08] <ubitux> i have some trouble with a flv because of this
[14:12] <ubitux> without -ss 0: http://pastie.org/pastes/9159067/text
[14:12] <ubitux> with -ss 0: http://pastie.org/pastes/9159069/text
[14:13] <ubitux> if -ss 0 is supposed to drop the negative ts, i don't see how that applies here
[14:13] <nevcairiel> hrm how do I debug a h264 clip that outputs no frames unless i set the showall flag? debug log outputs not much :(
[14:13] <ubitux> it looks like it's picking a random ts
[14:14] <ubitux> and obviously it's not a kf so the output is garbled
[14:18] <Voicu> hello, how do I use a filter programmatically?
[14:18] <ubitux> Voicu: see doc/examples/filtering_video.c
[14:19] <Voicu> thanks
[14:26] <Voicu> hmm, I'm not sure
[14:26] <Voicu> I need to use the aac_adtstoasc filter
[14:26] <Voicu> for converting an AAC stream
[14:26] <Daemon404> thats a bitstream filter
[14:27] <Daemon404> i.e. not libavfilter
[14:27] <Voicu> yeah my bad
[14:27] <Daemon404> also careful, that particular filter isnt perfect
[14:27] <Voicu> OK, so I have the bitstream initialized, how do I use it?
[14:27] <Daemon404> (i dont think its possible to be)
[14:27] <Daemon404> i actually dont know -- never had to
[14:27] <Voicu> well ye, different fields I suppose
[14:27] <Daemon404> nevcairiel maybe
[14:28] <ubitux> gcc: error: unrecognized command line option -fno-sanitize-recover
[14:28] <ubitux> :(
[14:28] <nevcairiel> i never used bitstream filters
[14:28] <Daemon404> o ok
[14:40] <nevcairiel> bitstream filters are more for remuxing, not required for decoding
[14:40] <nevcairiel> so.. never touched the stuff
[14:44] <cone-85> ffmpeg.git 03Hendrik Leppkes 07master:bc47801968fc: configure: check for recent dxva2api headers with fixed COBJMACROS defines
[14:50] <Voicu> nevcairiel, I am remuxing
[14:50] <Voicu> i.e. I have 2 streams, one h264, one aac and I am streaming them to a rtmp server in flv format
[14:51] <Voicu> but I did, I just had to use av_bitstream_filter_filter
[15:11] <nevcairiel> apparently streams without IDRs and without recovery SEIs don't play at all without the showall flag, that can't be as desired .. it shows absolutely corruption free, too. Just no IDRs, plenty I frames though.
[15:21] <ubitux> libav receiving patches to fix things already fixed in ffmpeg makes me really sad for the time wasted by these non aware contributors...
[15:22] <ubitux> (https://lists.libav.org/pipermail/libav-devel/2014-May/059501.html - http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5db49fc38d9132e134de92584f296559bec3b789)
[15:34] <cone-85> ffmpeg.git 03Diego Elio 'Flameeyes' Pettenò 07master:a7b554f86399: rtpdec: make the NTP time values unsigned.
[15:37] <ubitux> patch from 2010? are you time traveling michaelni? :)
[15:39] Action: kshishkov puts a nice FFmpeg sticker on his laptop
[15:39] <kshishkov> feel free to use that exact quote
[15:40] <ubitux> ahaha
[15:44] <nevcairiel> ubitux: the interesting part about that patch is that its only half the fix, there is a follow up commit with more corrections
[15:44] <ubitux> the guy might be still debugging
[15:49] <ubitux> does anyone have a sample with negative ts?
[15:50] <ubitux> (at the beginning)
[15:50] <ubitux> in flv if possible
[15:50] <ubitux> or any idea how to generate one
[16:05] <Voicu> can you just demux and remus a file and alter the .pts of the packets?
[16:05] <Voicu> *remux
[16:14] <ubitux> ok so it seems the initial seek fails in my case (-ss 0 with a flv)
[16:15] <ubitux> but it changes something in the context
[16:15] <ubitux> which makes everything else crumble
[16:15] <ubitux> ff_read_frame_flush() is the responsible
[16:18] <ubitux> which is called just before s->iformat->read_seek() in seek_frame_internal()
[16:20] <ubitux> flush_packet_queue() to be more specific
[16:27] <ubitux> why is this code called before seek?
[16:27] <ubitux> shouldn't it be called after the seek if it succeed instead?
[16:27] <DHE> I have a patch I'm considering submitting to ffmpeg. It takes A53 subtitles (currently collected by the mpeg1/2 decoder) and puts them into libx264 output. But it modifies the mpeg1/2 collector a bit in a way that might not sit well with others.
[16:29] <J_Darnley> What do you mean by "puts them into libx264 output"?  Anyway, you can ask for comments here or send a patch to the devel mailing list and ask for comments there.
[16:30] <DHE> J_Darnley: I have a Set Top Box for IPTV. It can show closed captions from a feed transcoded from MPEG2 to H264 using ffmpeg now
[16:32] <DHE> http://www.dehacked.net/ffmpeg-a53-to-libx264.txt This is the patch (git format-patch output)
[16:33] <compn> you force mpeg subs into side data and pass it to x264 eh
[16:33] <DHE> mpeg12dec.c is already collecting it. I just modified it to grab full headers (some metadata was previously uncollected and I am not sure I can reliably regenerate it right now)
[16:34] <DHE> but it's working. I have it running on my desk right now.
[16:34] <DHE> Haven't run regression suites on it yet
[16:34] <compn> ah
[16:34] <J_Darnley> oh yes, I forgot x264 had that feature
[16:35] <ubitux> no one familiar with the seek code? :(
[16:35] <ubitux> fate doesn't seem to like to have the flushing post seek
[16:36] <DHE> so that's my patch
[16:36] <DHE> I can see a white-space error in libx264.c but otherwise...
[16:37] <compn> i think michael is mpeg maintainer , wait for him 
[16:50] <JEEB> gcc sure is "quick" in backporting fixes
[16:51] <wm4> it's a GNU project after all
[16:51] <JEEB> commits from either 23rd or 28th that fix the golomb optimization derp
[16:51] <JEEB> are not yet in
[16:51] <JEEB> (in the 4.9 branch)
[16:52] <JEEB> wm4, that is true indeed
[16:53] <michaelni> DHE, doesnt this break the ABI of libavutil, the frame side data format is defined in it
[16:59] <DHE> it does? I checked and all I found (in ffmpeg itself) using it was a diagnostic that just reports its existance
[17:00] <DHE> there's 1 or 2 bytes of metadata I was having trouble regenerating from the existing code. Maybe I just didn't try hard enough.../
[17:03] <DHE> well, back to the drawing board then
[17:04] <ubitux> why is flac_read_timestamp() marked as av_unused?
[17:04] <ubitux> it looks very used to me
[17:04] <wm4> maybe it's not used under all configurations
[17:05] <ubitux> doesn't seem so
[17:08] <Daemon404> blame?
[17:09] <ubitux> first commit introducing the function (it's recent)
[17:10] <Daemon404> o
[17:14] <Voicu> is there a tutorial or something that explains how presentation timestamps and timebases work?
[17:15] <Voicu> also, is it normal for every AAC packet to have a duration of 655360 ?
[17:15] <Voicu> the numbers don't add up in the end
[17:16] <Daemon404> Voicu, pts * timebase = time in ms (in ffmpeg's case)
[17:18] <Voicu> hmm, it still doesn't add up
[17:18] <Voicu> I have ~11s of video and I get 30s when doing pts * timebase
[17:19] <Daemon404> i get the feeling youre pulling the wrong number from somewhere
[17:20] <Voicu> well I have an AAC stream that ffmpeg reads
[17:20] <Voicu> the pts values I get go up to 30s worth
[17:20] <ubitux> funny, ret = avformat_seek_file(ic, -1, INT64_MIN, timestamp, timestamp, 0); doesn't work (and breaks everything) while ret = avformat_seek_file(ic, -1, INT64_MIN, timestamp, INT64_MAX, 0); works fine
[17:21] <ubitux> i guess that's because the seek succeed in the second case
[17:25] <wm4> ubitux: I'm simply using the old seek API
[17:25] <wm4> except when it doesn't work
[17:25] <ubitux> it's the same thing
[17:25] <wm4> then I revert to the new one
[17:26] <ubitux> the problem is deeper
[17:26] <ubitux> but i'm pretty confused at the internals of the seeking code
[17:26] <Daemon404> Voicu, get from where
[17:27] <Daemon404> ubitux, pre-indexing master race
[17:27] <Voicu> Daemon404, the packets I was reading from the stream
[17:27] <Voicu> Daemon404, but now I almost got it
[17:27] <Voicu> I fixed the timebases and I get timestamps which are roughly /2
[17:27] <Voicu> so, I missed something simple
[17:29] <wm4> optional preindexing in libavformat would be nice
[17:30] <Daemon404> i dont think it would "fit" in very easily
[17:30] <Daemon404> api wise
[17:31] <wm4> I don't really see a problem
[17:31] <wm4> but it'll make utils.c uglier
[18:14] <cone-85> ffmpeg.git 03nu774 07master:9880a0d4b131: pcm-dvd: Fix 20bit decoding
[18:14] <cone-85> ffmpeg.git 03Michael Niedermayer 07master:8a21613821fd: Merge commit '9880a0d4b131ef36694d62f78060350a81f08b80'
[18:15] <kierank> who is at linuxtag?
[18:35] <cone-85> ffmpeg.git 03Matt Oliver 07master:3554c2fafc46: libmpcodecs: Fix compilation due to missing static in suncc.
[19:11] <michaelni> ubitux, is "[FFmpeg-devel] [PATCH] avformat/mux: 2 subtitle packets could have the same DTS" ok ?
[19:12] <michaelni> its just a 1 line patch 
[19:45] <DHE> I updated my A53 CC patch. New version at: http://www.dehacked.net/ffmpeg-a53-to-libx264.txt
[19:45] <DHE> (old version intentionally overwritten - it had a memory error)
[19:46] <DHE> I think I can drop some of the last few bytes from the extra sei data, still experimenting.
[19:51] <Daemon404> it should probably be a private option
[19:51] <Daemon404> it doesnt seem wise to hard enable it
[20:06] <cone-85> ffmpeg.git 03Michael Niedermayer 07master:398e3a591fb8: avcodec: replace uses of deprecated avcodec_set_dimensions()
[20:09] <DHE> Daemon404: makes sense
[20:38] <DHE> Refreshed the patch, added some comments, removed some bytes from the stream output (WorksForMe) and made it an option that defaults to off
[22:14] <cone-85> ffmpeg.git 03Matthew Lindner 07master:b372f673427c: avcodec: better level/index printing
[00:00] --- Sat May 10 2014