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

Sat Nov 21 02:05:02 CET 2015

[00:02:35 CET] <llogan> what machine is that?
[00:16:48 CET] <kierank> the machine I setup for dev work
[00:16:51 CET] <kierank> sits underneath trac
[00:17:08 CET] <nevcairiel> didnt it have hdd trouble once before already
[00:17:30 CET] <nevcairiel> maybe i'm mis-remembering
[00:18:29 CET] <kierank> yeah
[00:18:39 CET] <kierank> swapped the disc out as well...
[00:27:33 CET] <llogan> too bad trac gets so much spambot traffic. not much gets through anymore though, but i'm curious how much of a load they make
[00:47:02 CET] <llogan> oh boy, an SVHS tape has appeared on my desk.
[00:49:53 CET] <llogan> it contains a femullet.
[00:50:39 CET] <atomnuker> does it smell like the 80's?
[00:51:15 CET] <llogan> hmm..let me check. the case still just smells of plastic. vintage 1990
[00:52:03 CET] <cone-408> ffmpeg 03Andreas Cadhalpun 07master:1ed7fcd42af9: hqx: correct type and size check of info_offset
[03:50:22 CET] <cone-573> ffmpeg 03Michael Niedermayer 07master:03a34ef7a925: avcodec/sbr: fix copy and paste error
[03:50:22 CET] <cone-573> ffmpeg 03Michael Niedermayer 07master:8eadabf941a9: avcodec/aacsbr_fixed: Replace a noise_facs_q check by an av_assert0
[09:10:10 CET] <durandal_1707> can somebody kick someone from #ffmpeg?
[11:05:18 CET] <ubitux> http://ubitux.fr/pub/pics/_the-effect-of-replacing-a-shift-by-a-div.png
[11:09:14 CET] <wm4> huh
[11:10:38 CET] <ubitux> just replaced a >>n by a /(1<<n)
[11:10:57 CET] <ubitux> and so it slightly changed for negative vectors
[11:11:16 CET] <ubitux> bottom is a diff between the two above
[11:11:26 CET] <fritsch> yeah, but that expression is not the same
[11:11:42 CET] <nevcairiel> thats his point =p
[11:12:19 CET] <fritsch> okay
[11:25:17 CET] <ubitux> https://www.youtube.com/watch?v=9XMfKYVu_fg
[11:30:34 CET] <cone-384> ffmpeg 03wm4 07master:974721995806: avcodec/h264, videotoolbox: do not return invalid frames on failure
[14:21:49 CET] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:47eeb001e63b: avcodec/ac3: replace #define by typedef
[14:21:50 CET] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:fafb10c30cdb: avcodec/lpc: replace #define by typedef
[14:21:51 CET] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:736845b0cd71: avcodec/resample2: replace #define by typedef
[14:21:52 CET] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:8d48c3700674: avcodec/faanidct: replace #define by typedef
[14:26:59 CET] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:2db114ec3f79: tests/tiny_ssim: replace #define by typedef
[14:27:35 CET] <ubitux>  avcodec/resample2.c wat
[14:27:39 CET] <ubitux> we still have that api?
[14:33:38 CET] <cone-384> ffmpeg 03Ganesh Ajjanagadde 07master:7769e6602d2d: avfilter/af_dynaudnorm: use M_PI
[14:34:15 CET] <Daemon404> ubitux, everyone wants to remove it
[14:34:19 CET] <Daemon404> i dont even know why its there
[14:34:24 CET] <Daemon404> probably mplayer
[14:34:27 CET] <wm4> nothing ever gets removed
[14:34:36 CET] <ubitux> well it will disappear at next bump
[14:34:41 CET] <wm4> it's like venice, everything rotting is actually _good_
[14:34:43 CET] <ubitux> but i thought we already bumped recently
[14:34:54 CET] <nevcairiel> it wasnt 2 years deprecated at the last bump
[14:35:52 CET] <Daemon404> [13:34] <+wm4> it's like venice, everything rotting is actually _good_ <-- i visited venice this year for the first time
[14:35:59 CET] <Daemon404> i did not enjoy teh decrepitness
[14:36:04 CET] <Daemon404> i dont get the appeal.
[14:38:28 CET] <ubitux> wm4: http://pastie.org/10569855
[14:38:35 CET] <ubitux> does that help your issue? (untested)
[14:39:03 CET] <wm4> it probably would, and it looks harmful
[14:39:14 CET] <wm4> but there are many more cases probing would fail, while vsfilter just eats it
[14:39:24 CET] <ubitux> harmful in what way?
[14:39:26 CET] <wm4> s/harmful/harmless
[14:39:28 CET] <wm4> (oops)
[14:39:28 CET] <ubitux> ok
[14:44:30 CET] <cone-384> ffmpeg 03Clément BSsch 07master:6679fcd4198d: avformat/assdec: allow ASS files starting with empty lines
[14:44:44 CET] <ubitux> (just tested, apparently works)
[14:44:57 CET] <BtbN> I wonder if gbs vaapi stuff will ever appear
[14:45:27 CET] <wm4> good question
[14:45:58 CET] <fritsch> did not talk with him since > 6 weeks
[14:46:06 CET] <fritsch> and this was my last question to him, also
[14:46:24 CET] <BtbN> I'm still waiting for that to happen, as there is VAAPI stuff I want to work on
[14:46:57 CET] <fritsch> VP9
[14:47:00 CET] <fritsch> bing, bing :-)
[14:47:21 CET] <wm4> yeah, want to have hardware acceleration for all that vp9 content
[14:47:45 CET] <nevcairiel> there is millions of videos in vp9
[14:47:52 CET] <nevcairiel> its called youtube
[14:47:52 CET] <Daemon404> (From one source)
[14:48:03 CET] <wm4> yeah, that's so high bitrate
[14:48:26 CET] <fritsch> for intel there is only this gpu assisted thingy
[14:48:34 CET] <fritsch> for everything > haswell
[14:48:38 CET] <fritsch> so not including hsw
[14:49:12 CET] <wm4> so, does anyone know why I'm getting a deadlock with h264 decoding if I disable everything but the h264 decoder?
[14:49:17 CET] <Daemon404> ugh... i have to debug my first .scc file
[14:49:19 CET] <nevcairiel> once microsoft releases the final windows sdk update, i can push the dxva2 vp9 patch, didnt feel right to have something that is based on a pre-release sdk
[14:49:23 CET] Action: Daemon404 holds gun up to head
[14:50:48 CET] <nevcairiel> not like many people will be able to build that code, mingw will take a couple years to add it
[14:50:56 CET] <nevcairiel> not sure if they at least have hevc now
[14:51:15 CET] <nevcairiel> (not in any release version, anyway)
[14:54:46 CET] <kierank> wm4: git head?
[14:55:00 CET] <wm4> yeah
[14:55:12 CET] <kierank> can't say for sure but there are a ton of api h264 crashes still
[14:55:18 CET] <wm4> not using libavformat's demuxers, which makes it easier
[14:56:34 CET] <kierank> I think if you implement your own parser and feed it frames differently to the ffmpeg one you can have crashes
[14:56:38 CET] <kierank> cf my report above
[14:57:30 CET] <wm4> I just get a deadlock (or rather, everything is blocking in condition wait calls), not a crash, and only with multihtreading and only if everything other than h264 is disabled
[14:57:56 CET] <kierank> ah
[14:57:59 CET] <kierank> I get crashes
[14:58:06 CET] <kierank> had deadlocks in the past as well
[15:03:56 CET] <nevcairiel> the decoder assumes it gets full frames, if your parser produces something different, its strictly wrong input
[15:04:12 CET] <nevcairiel> (or full fields  where appropriate)
[15:04:42 CET] <kierank> in the past at least you could send slices
[15:07:33 CET] <nevcairiel> do we still have the chunks flag
[15:07:48 CET] <wm4> of course
[15:15:33 CET] <wm4> hm never mind, must have been my own mistake
[15:17:12 CET] <BtbN> I think I'll just start working on the ffmpeg_vaapi.c with the old api. It shouldn't be too much work anyway.
[15:17:38 CET] <wm4> except that gb's work was supposed to reduce this work by a lot
[15:17:57 CET] <BtbN> Don't realy feel like waiting for that anymore
[15:19:02 CET] <durandal_1707> Hm, why I have lost my op?
[15:19:27 CET] <BtbN> because your client is bad
[15:20:01 CET] <BtbN> according to my userlist and /whois you do have Op
[15:20:26 CET] <durandal_1707> but on #ffmpeg
[15:26:16 CET] <beefman> hi.  I'm using this command: avconv -i myfile.mp4 -threads auto -c:a libmp3lame -vn -aq 3 myfile.mp3.  mp3val tells me the result is vbr but has no vbr header, and ffwd & rewind are screwy.  when i use -ab 192000 instead of -aq 3, i get cbr and it works fine.  Is this a bug in avconv or in libmp3lame?  already fixed?
[15:26:44 CET] <BtbN> Wrong channel, and wrong project.
[15:26:56 CET] <beefman> isn't avconv the same as ffmpeg?
[15:26:58 CET] <BtbN> no
[15:27:00 CET] <beefman> ok
[15:27:01 CET] <beefman> sorry
[15:30:14 CET] <beefman> i'm using mint & when i type ffmpeg it says use avconv, ffmpeg is deprecated.  i'm guessing they forked for some reason?
[15:32:35 CET] <wm4> lol
[15:32:51 CET] <ubitux> ask #libav or #ffmpeg depending on the project you use (note: if you use ffmpeg from your distro, it's likely a very old copy of ffmpeg within a very old release of libav)
[15:33:24 CET] <ubitux> look up on the web for extra info about the two projects, there are way enough drama sources
[15:33:25 CET] <Daemon404> thats not true for current ubuntu anymore agaik
[15:33:30 CET] <Daemon404> afaik*
[15:33:31 CET] <ubitux> and anyway, wrong channel
[15:33:35 CET] <Daemon404> indeed
[15:34:10 CET] <beefman> ok so there was drama.  that's all i need to know.  If i switch to ffmpeg, is there any issue with vbr headers when converting mp4s to mp3s using vbr?
[15:38:15 CET] <wm4> beefman: wrong channel
[17:00:39 CET] Action: Daemon404 stares at all the giant threads; doesn't read them
[17:30:26 CET] <wm4> good idea
[17:32:11 CET] <durandal_1707> ubitux: can't you just call request_frame ?
[17:33:05 CET] <ubitux> maybe, but you need to be more specific because i don't understand what you said
[17:40:28 CET] <durandal_1707> ubitux: taking frames and not using them at all
[17:42:04 CET] <ubitux> problem is that i don't receive them
[18:09:23 CET] <durandal_1707> ubitux: why? What are you doing?
[18:24:57 CET] <durandal_1707> just requesting frames should do the trick
[18:35:44 CET] <cone-384> ffmpeg 03Maksym Veremeyenko 07master:d21b690e559b: ffmpeg: preserve profile for audio stream copy
[18:35:45 CET] <cone-384> ffmpeg 03Maksym Veremeyenko 07master:acb430e4d3a7: avformat/flvenc: Add aac_seq_header_detect and flvflags
[19:02:29 CET] <BtbN> How do I add an optional library dependency to the ffmpeg cli tool? I want it to link against -lva-drm if available and enabled
[19:03:08 CET] <J_Darnley> Add the flag to --extra-libs in configure
[19:03:39 CET] <J_Darnley> Or copy what other libs do if you're writing a patch
[19:05:01 CET] <BtbN> I can't find where other libs are doing that.
[19:05:16 CET] <J_Darnley> configure around line 5420
[19:05:16 CET] <BtbN> I'd guess it's somewhere in the dependency chaos the configure script creates. But i have no idea where.
[19:05:26 CET] <J_Darnley> ah, that's what you mean
[19:07:15 CET] <J_Darnley> If its using pkg-config: require_pkg_config
[19:07:39 CET] <BtbN> Sure, that's how i check it. But how do i tell it to add that library to the ffmpeg cli tool?
[19:07:49 CET] <J_Darnley> That should take care of it.
[19:09:12 CET] <J_Darnley> require_pkg_config -> use_pkg_config -> add_extralibs
[19:10:59 CET] <BtbN> prepend ffmpeg_libs $($ldflags_filter "-lva-drm")
[19:11:04 CET] <BtbN> Seems to be what i'm looking for
[19:19:49 CET] <BtbN> nope, doesn't work
[19:44:07 CET] <BtbN> Ok, it was just optimized out, because i wasn't using functions from that lib yet...
[20:01:29 CET] <cone-384> ffmpeg 03Rodger Combs 07master:bf2590aed3e6: ffmpeg: fix -copy_prior_start 0 with -copyts and input -ss
[20:28:54 CET] <cone-384> ffmpeg 03Michael Niedermayer 07master:3444c00aab6e: avformat/ffmdec: Add cleaner API for ffserver to interface without depending on internal ABI
[20:28:55 CET] <cone-384> ffmpeg 03Michael Niedermayer 07master:e33d37202393: ffserver: Use AVOption API to access ffm demuxer instead of direct access depending on ABI
[20:28:56 CET] <cone-384> ffmpeg 03Michael Niedermayer 07master:9b7d39de81ce: avformat/ffmdec: Only return EAGAIN if a server is attached
[20:52:52 CET] <cone-384> ffmpeg 03Paul B Mahol 07master:b885d9ced59c: avformat/rsd: implement seeking
[20:58:16 CET] <ubitux> durandal_1707: i explained the rationale of the filter in the original post; what do you want me to explain in more details?
[20:58:21 CET] <ubitux> i can push it somewhere
[21:00:01 CET] <durandal_1707> I see no problem in filter taking frames from inputs and not using them in any output
[21:00:35 CET] <durandal_1707> so stream selection should work
[21:02:29 CET] <ubitux> yes but it doesn't
[21:02:36 CET] <ubitux> because the filter_frame() function is simply not called
[21:02:43 CET] <ubitux> (when the stream is inactive)
[21:03:33 CET] <ubitux> durandal_1707: https://github.com/ubitux/FFmpeg/compare/streamselect
[21:05:11 CET] <ubitux> durandal_1707: then /ffmpeg -v verbose -nostats -lavfi "testsrc=hd720,realtime[a]; testsrc2=hd1080,realtime[b]; [a][b]streamselect=in=vv:out=v:map=0,showinfo" -f null -
[21:05:25 CET] <ubitux> and press 'c' to switch streams
[21:05:33 CET] <ubitux> you'll see what happens
[21:06:24 CET] <durandal_1707>  then make it always active?
[21:06:37 CET] <ubitux> how?
[21:25:53 CET] <durandal_1707> do you get frames from all inputs?
[21:28:19 CET] <ubitux> only the active one
[21:29:44 CET] <ubitux> those in background are paused
[21:29:50 CET] <ubitux> until we switch to them again
[21:31:37 CET] <durandal_1707> well that can't work, you can't seek
[22:06:21 CET] <dcherednik_> Hello. I am working on fixing errors in ATRAC1 decoder (there is conversation on ffmpeg-devel@). I need to upload new reference files. How can I do it?
[22:45:05 CET] <J_Darnley> dcherednik_: speak to a "manager"
[22:45:09 CET] <J_Darnley> perhaps michaelni
[22:46:43 CET] <michaelni> manager ? ;) but dcherednik_ yes i can upload a new ref file 
[22:47:10 CET] <J_Darnley> admin then?
[22:49:45 CET] <michaelni> doesnt really matter, what file needs to be uploaded and to where ?
[23:18:52 CET] <dcherednik_> Ou. Files should be uploaded to fate-suite/atrac1 (I think ;))) And it is possible to get it here https://yadi.sk/d/DA-xxzM_kcJ5t 
[23:20:11 CET] <dcherednik_> It is fixed pcm file for existed test_tones_small.aea and new pair of encoded aea and source pcm with chirp tone
[23:27:00 CET] <cone-384> ffmpeg 03Andreas Cadhalpun 07master:1c3e43a62738: aacsbr: don't call sbr_dequant twice without intermediate read_sbr_data
[23:31:54 CET] <michaelni> dcherednik_, files uploaded
[23:34:54 CET] <dcherednik_> Thank you! I sent message to ffmpeg-devel@ with patch which included fix for fate. If I need to provide some additional information lets me know.
[00:00:00 CET] --- Sat Nov 21 2015