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

[burek]

[00:00:35 CEST] <Timothy_Gu> ubitux: ping?
[00:11:56 CEST] <kierank> michaelni: what does the argument 'n' refer to in mc_dir_part?
[00:12:37 CEST] <kierank> #4431 picks a reference frame past the end
[00:12:42 CEST] <kierank> which is insane
[00:15:13 CEST] <michaelni> n  is 4x4 block index 
[00:16:41 CEST] <kierank> thanks
[00:30:01 CEST] <kierank> so any ideas why H264Ref *ref = &sl->ref_list[0][sl->ref_cache[0][scan8[n]]]; would be nondeterministically setup
[00:36:59 CEST] <michaelni> kierank, ive a change locally that might fix this (iam not sure yet, as ive seen a 2nd crash with a previous sample from you which is what iam looking at atm)
[00:37:31 CEST] <kierank> what does your change do?
[00:37:50 CEST] <michaelni> fix race between slice threads
[00:38:32 CEST] <kierank> from a small sample of the zzuf crashes, they all seem to be as a result of ref_cache being corrupt
[00:41:12 CEST] <Compn> more asserts! :P
[00:41:17 CEST] Action: Compn runs
[00:48:01 CEST] <kierank> michaelni: if you need anything please let me know i guess
[00:49:09 CEST] <michaelni> no, just need to test a bit more
[00:50:30 CEST] <kierank> ok, I will fuzz the patch when the time comes
[00:56:23 CEST] <cone-841> ffmpeg 03Michael Niedermayer 07master:43b434210e59: avcodec/h264: Fix race between slices where one overwrites data from the next
[01:10:17 CEST] <llogan> in 4436, among the extra chaff, user attempts to stream copy/mux pcm_s16le into .mpg, then ffmpeg can't decode resulting file. should this muxer even allow arbitrary (non mpeg) audio formats?
[01:14:22 CEST] <Compn> llogan : we should prevent user from creating bad files, unless they provide option -yes-iam-an-idiot :P
[01:26:54 CEST] <kierank> michaelni: many more segfaults on the way...
[01:32:34 CEST] <kierank> ok they all seem to be the same crash #4438
[02:10:59 CEST] <Prelude2004c> hey guys.. looking for a developer to help me port NVENC to work with AMD cards or build a process that will handle the work of multiple sessions and only send 1 or 2 sessions to NVidia cards ( overcome session limit )  .. Anyone interested ? If so please PM me
[02:19:46 CEST] <kierank> Prelude2004c: how do you plan to avoid the session limit
[03:09:15 CEST] <Guest81495> hi, i'm trying to build ffmpeg on windows using msvc 2013. i followed the guide and i am stuck with this error when running make: http://pastebin.com/7tHB4ANj
[03:09:18 CEST] <cone-841> ffmpeg 03Michael Niedermayer 07master:c4b2017ba66e: avcodec/h264: finish previous slices before switching to single thread mode
[03:09:27 CEST] <Guest81495> configure succeeded without any issues. any idea what could be wrong here?
[03:41:29 CEST] <kierank> michaelni: fuzzing looks good - thanks for all the bug fixes
[03:41:33 CEST] <kierank> will let it run overnight
[03:53:52 CEST] <Timothy_Gu> Guest81495: looks like an escaping issue
[03:55:43 CEST] <Timothy_Gu> Guest81495: still here?
[03:56:45 CEST] <kierank> j-b: https://github.com/Microsoft/FFmpegInterop
[06:00:27 CEST] <Timothy_1u> Hmm
[10:34:44 CEST] <fffan> fellows, I have a big problem, Can anyone help me?
[10:36:26 CEST] <fffan> j-b
[11:23:23 CEST] <fffan> when I open multilple rtmp urls in a process , my process crashed.
[11:34:04 CEST] <debianuser> loki_: If still relevant, to build x11grab without xcb: `./configure ... --enable-x11grab --disable-libxcb`. Why're you asking by the way?
[11:43:55 CEST] <ubitux> Timothy_Gu: i'm not much available currently; is it about coverage?
[11:47:15 CEST] <wm4> ubitux: btw. I've seen some srt subtitles with duration 0, but which were obviously meant to be displayed
[11:47:35 CEST] <wm4> (so the end timestamp was the same as the start timestamp)
[11:47:38 CEST] <ubitux> until the next sub?
[11:47:51 CEST] <wm4> these subs were a bit strange though... maybe someone incompetent tried to timeshift them
[11:47:56 CEST] <wm4> probably
[11:48:08 CEST] <wm4> and only some events
[11:48:15 CEST] <wm4> e.g. one file had 2 of such events
[11:50:21 CEST] <ubitux> http://pastie.org/pastes/10077899/text quick hack
[11:50:46 CEST] <ubitux> you might want to add a time threshold (10 sec?) and check if the sub has content
[11:50:54 CEST] <ubitux> and eventually warn in this case
[11:51:20 CEST] <debianuser> loki_: Ah, found your messages in #ffmpeg. I was wondering because some time ago I noticed x11grab being fast on its own but slowing down to ~50fps with encoder due to slow RGB->YUV420 conversion. Tried to patch it (pastebin.com/aCmV9A4W), but it was still slow, despite the code itself (pastebin.com/ivJrF5kv) giving 180fps easily. Don't know why. :(
[11:52:26 CEST] <BtbN> It's slow because your CPU is lacking basic extensions that make the conversion fast.
[11:57:42 CEST] <debianuser> BtbN: Well, the same C code compiled separately was much faster. :) Is it fast for you? Easy test: `time ./ffmpeg -f x11grab -r 60 -s 1920x1200 -i :0 -vf format=yuv420p -t 30 -f null -` (adjust to your monitor resolution). It should take exactly 30 seconds, if it takes like 50 seconds - your cpu is slow too. :)
[11:58:19 CEST] <BtbN> The bgr0->nv12 conversion does ~400 fps for me, tested that a few days ago.
[12:03:39 CEST] <debianuser> Well, the problem was that it's fast for me on its own, but slow when used inside ffmpeg with that command somewhy. :( (downloading latest linux static build to make sure)
[12:17:56 CEST] <debianuser> BtbN: Nope, nothing changed for me: http://pastebin.com/amPLwwfP :( Can you show your output of `time ./ffmpeg -loglevel debug -f x11grab -r 60 -s 1920x1200 -i :0 -vf format=yuv420p -t 30 -f null -` so I could compare your working case with my broken one, maybe I'll see my problem then.
[12:24:57 CEST] <BtbN> I'm not testing on a machine with X.
[12:36:56 CEST] <wm4> ubitux: appears to work... anyway, the question is, how is it supposed to work? AFAIK one test file claimed that subs with 0 duration should not be visible...
[12:37:03 CEST] <wm4> so maybe both is possible
[12:37:27 CEST] <wm4> though I'd assume nobody actually uses such invisible subtitles on purpose
[12:42:27 CEST] <iive> I think some subtitle software makes srt where the first sub is with duration 0 and contains the fps of the video file.
[12:43:02 CEST] <iive> it would make more sense to do that for .sub (microdvd)
[12:46:55 CEST] <wm4> yeah, microdvd can have that
[12:46:58 CEST] <wm4> never seen it with srt
[12:47:27 CEST] <ubitux> there is already an exception for microdvd for that iirc
[12:48:33 CEST] <ubitux> wm4: what is the one with subs expecting 0 duration?
[12:48:52 CEST] <ubitux> if they are such, they should probably not use that api
[12:49:42 CEST] <wm4> what api?
[12:49:52 CEST] <wm4> actually fate/sub/SubRip_capability_tester.srt implies subs with no duration should be invisible
[12:53:28 CEST] <wm4> debianuser: why aren't you using xcbgrab?
[12:53:46 CEST] <ubitux> wm4: this demuxing subtitles api
[12:54:06 CEST] <ubitux> specifically for text (with the exception of vobsub) standalone subs
[12:54:35 CEST] <ubitux> (fully loaded, then sorted, duration calculated if -1 / or <= 0 now)
[12:54:43 CEST] <debianuser> wm4: Unknown input format: 'xcbgrab' :)
[12:55:21 CEST] <wm4> nevermind, both x11grab and xcbgrab use the name "x11grab" (wtf???)
[12:58:15 CEST] <debianuser> wm4: I tried both (official static build using xcb and custom `./configure ... --enable-x11grab --disable-libxcb`), original x11grab is a little bit faster, but I'm still not getting 60fps with any of them. :(
[13:05:29 CEST] <ubitux> wm4: the test could be changed if that's the prefered behaviour
[13:06:34 CEST] <ubitux> the only use case of having a zero duration sub would be in a context of caption just like sami, where one sub hides the previous one; but this is handled in the demuxer itself so..
[13:07:31 CEST] <wm4> I'm fairly certain it could actually break things with ass
[13:07:36 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:0bcb669eccba: avformat/mov: Disallow ".." in dref unless use_absolute_path is set
[13:07:37 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:3ce32f640115: avcodec/dnxhddec: Check that the frame is interlaced before using cur_field
[13:07:38 CEST] <cone-232> ffmpeg 03Anton Khirnov 07release/2.2:fdb8a35b0267: hevc: make the crop sizes unsigned (cherry picked from commit c929659bdd7d2d5848ea52e685a3164c7b901bb0)
[13:07:39 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:58e055cb262e: avcodec/hevc_ps: More complete window reset
[13:07:40 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:691dbc628a43: avcodec/hevc_ps: Check cropping parameters more correctly
[13:07:41 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:33877cd276f9: avcodec/msrledec: restructure msrle_decode_pal4() based on the line number instead of the pixel pointer
[13:07:42 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:c701506525b3: avutil/pca: Check for av_malloc* failures
[13:07:43 CEST] <wm4> so handling it in the demuxer is actually welcome
[13:07:43 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:5b4e58ed4c36: avcodec/h264: Fail for invalid mixed IDR / non IDR frames in slice threading mode
[13:07:44 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:6496cbee695b: avcodec/h264_refs: Do not set reference to things which dont exist
[13:07:45 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:e63f330a1c3c: ffmpeg: Fix extradata allocation
[13:07:46 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:3852b172e7de: avcodec/h264: Fix race between slices where one overwrites data from the next
[13:07:47 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07release/2.2:8f026e2b388a: avcodec/h264: finish previous slices before switching to single thread mode
[13:07:48 CEST] <cone-232> ffmpeg 03Timothy Gu 07release/2.2:83ac312c3cbf: tests/fate.sh: report different status for different errors
[13:08:36 CEST] <ubitux> wm4: i'm thinking of rescale that could go wrong too
[13:09:12 CEST] <ubitux> but yeah i dunno
[13:12:01 CEST] <iive> wm4: i suspect that most of the srt i've seen with that, are conversion from .sub (microdvd).
[13:15:17 CEST] <ubitux> wm4: can you show an example btw?
[13:18:14 CEST] <wm4> ubitux: http://sprunge.us/VdiQ
[13:18:21 CEST] <wm4> 00:27:25,771 --> 00:27:25,771
[13:19:22 CEST] <wm4> it's actually spoken... right before a scene change, where the subtitle offset is messed up and you have to resync
[13:19:30 CEST] <wm4> (I hate external subtitles)
[13:19:53 CEST] <wm4> so maybe these subs got messed up because someone incompetent tried to timeshift them
[13:32:37 CEST] <loki_> debianuser: i think BtbN is right. We need upgrade.
[13:33:18 CEST] <loki_> if you have no ssse3 all conversions of pixel format will be slow
[13:34:43 CEST] <debianuser> loki_: Maybe, but upgrade of what? ;) In my case the trick is that the very same C code works about 5 times faster on its own then inside ffmpeg. (and according to /proc/cpuinfo I have ssse3) :)
[13:35:11 CEST] <loki_> maybe i need carefully read you writing
[13:35:14 CEST] <loki_> wait a sec
[13:36:27 CEST] <loki_> wait....
[13:36:41 CEST] <loki_> you too messing with nvenc am i right lol?
[13:37:47 CEST] <loki_> and what code you run stand alone?
[13:38:59 CEST] <loki_> how much fps you got from x11grab without any conversion?
[13:39:40 CEST] <debianuser> My test is simple: `time ./ffmpeg -loglevel debug -f x11grab -r 60 -s 1920x1200 -i :0 -t 30 -f null -` is fast, while `time ./ffmpeg -loglevel debug -f x11grab -r 60 -s 1920x1200 -i :0 -vf format=yuv420p -t 30 -f null -` is slow, ~40fps for me (initially there was actual encoder there I nailed it to format conversion later).
[13:39:45 CEST] <debianuser> I digged through the ffmpeg code and tried to patch it adding a special case for my format conversion (pastebin.com/aCmV9A4W), but it was still slow, despite the code itself (pastebin.com/ivJrF5kv) giving 180fps easily. Don't know why. :(
[13:40:40 CEST] <loki_> maybe because it is not just pixel convertion there?
[13:41:00 CEST] <loki_> yuv420p are not nv12
[13:43:17 CEST] <debianuser> My benchmarks: (static ffmpeg, x11grab using xcb): 100fps easily when run on its own, 40fps with `-vf format=yuv420p` or e.g. `-vcodec libx264 -preset ultrafast -pix_fmt yuv420p`. Output example: http://pastebin.com/amPLwwfP  Maybe it's not just pixel convertion, but what...
[13:45:48 CEST] <BtbN> well, h264 encoding.
[13:46:12 CEST] <BtbN> ffmpeg -v debug -f lavfi -i rgbtestsrc -pix_fmt yuv420p -c:v rawvideo -f rawvideo -y /dev/null
[13:46:21 CEST] <BtbN> if you want to test raw pixel format conversion performance
[13:46:53 CEST] <wm4> lol at libswscale being the bottleneck again
[13:47:08 CEST] <BtbN> Well, i wouldn't call 3000 fps bottleneck
[13:47:15 CEST] <BtbN> it's a bottleneck on CPUs without ssse3
[13:47:36 CEST] <loki_> debianuser: i don't think you can get 60 fps with libx264
[13:47:37 CEST] <BtbN> nv12 is slightly slower, with 2000 fps
[13:48:22 CEST] <debianuser> BtbN: your command is "pixfmt:rgba", how can I make it "pixfmt:bgr0"?
[13:48:40 CEST] <BtbN> you can't.
[13:49:08 CEST] <debianuser> :( x11grab (and maybe dshow? can't test) produce "pixfmt:bgr0"
[13:49:18 CEST] <loki_> and what?
[13:49:39 CEST] <BtbN> bgr0 and argb aren't that diffrent.
[13:52:52 CEST] <loki_> debianuser: if you have ssse3 you can try hardware encoder to get 60 fps
[13:52:54 CEST] <debianuser> BtbN: Well, they are different for ffmpeg :) because your command is ~1500fps for me, while `time ./ffmpeg -loglevel debug -f x11grab -r 60 -s 1920x1200 -i :0 -vf format=yuv420p -t 30 -f null -` is ~40fps.
[13:53:01 CEST] <loki_> nvenc for example
[13:53:15 CEST] <loki_> hm
[13:53:33 CEST] <loki_> so you have 40fps and ssse3?
[13:53:53 CEST] <loki_> do you have asm optimizations on?
[13:54:18 CEST] <loki_> check out that you really have ssse3
[13:54:28 CEST] <loki_> and not sse3
[13:54:37 CEST] <loki_> it is different things.
[13:55:02 CEST] <loki_> i have 40 fps on 1920x1080
[13:55:13 CEST] <debianuser> loki_: I can't make ffmpeg to feed encoder with 60fps. :( E.g. this output http://pastebin.com/amPLwwfP - was with "official" static build. /proc/cpuinfo : flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
[13:56:04 CEST] <loki_> and with your own build?
[13:56:15 CEST] <loki_> just ffmpeg main from git?
[13:56:40 CEST] <loki_> debianuser: what video card you have?
[13:57:06 CEST] <loki_> i done bgr0 to nv12 with cuda in my version
[13:57:10 CEST] <loki_> it runs fast.
[13:57:15 CEST] <loki_> you can try it.
[14:01:26 CEST] <debianuser> loki_: Heh, I'm mostly trying to find out why ffmpeg is fast for other cases (e.g. BtbN's rgbtestsrc command), but is so slow for x11grab case. I mean screengrabbing is a common usecase, it would be great if it was fast by default, not limited to 40fps. :)
[14:02:13 CEST] <BtbN> screencapture is slow, very slow.
[14:02:16 CEST] <loki_> so can you please answer for my questions. how much fps from x11grab without any pixel convertin?
[14:02:27 CEST] <loki_> and other which video card you have.
[14:02:47 CEST] <loki_> i have 70 fps
[14:03:00 CEST] <loki_> without any pixel convertion
[14:03:48 CEST] <loki_> and with cuda and nvenc i get 43 fps sometimes max on idle, and stable 30 fps under heavy load in my case Dota 2
[14:05:09 CEST] <loki_> but my gpu goes to 70 C lol
[14:06:19 CEST] <loki_> and as BtbN said, that i have very bad bus utilization... which i can fix only malloc ~ 400mb of gpu memory
[14:06:35 CEST] <loki_> and it is not right.
[14:06:51 CEST] <loki_> or maybe i don't get how nvenc works.
[14:18:43 CEST] <loki_> another thing... i can't get why my system ffmpeg faster in test then my build
[14:19:05 CEST] <loki_> i think all options about optimization and x11grab are meet
[14:32:24 CEST] <debianuser> BtbN: `time ./ffmpeg -v debug -f x11grab -r 60 -s 1920x1200 -i :0 -t 30 -f null -` on its own (without "-vf format=yuv420p") is fast. It's 60fps with ffmpeg using ~5% CPU. But adding "-vf format=yuv420p" makes go down to 40fps. :(
[14:34:16 CEST] Action: debianuser feels bad when people blame x264 being too slow or xorg being too slow, while it seems to be some small stupid bug in pixel format conversion and I can't find how to fix it. :(
[14:35:02 CEST] <loki_> i think bug that x11grab can not be threaded.
[14:35:30 CEST] <BtbN> No idea what bug you mean. 60 fps for x11 grab is already quite nice
[14:36:41 CEST] <debianuser> loki_: without format conversion I can get 100fps with command: `time ./ffmpeg -f x11grab -r 100 -s 1280x1024 -i :0 -t 30 -f null -`.
[14:37:14 CEST] <loki_> so what gpu you have?
[14:37:30 CEST] <loki_> i want to show some code for gpu pixel convertion
[14:38:16 CEST] <debianuser> nvidia geforce 8600, but it doesn't matter for that command, since my problem happens somewhere inside ffmpeg, before the encoder part.
[14:38:38 CEST] <BtbN> Yes it does matter, it has to pull the frames from your GPU.
[14:38:46 CEST] <BtbN> nvidia GPUs are exceptionaly bad at this
[14:39:06 CEST] <loki_> debianuser: and what cpu?
[14:40:21 CEST] <debianuser> BtbN: Yes! Having 60fps, even 100fps with x11grab itself is great! Having it limited to 40fps due to some format conversion bug in ffmpeg - that's what bothers me. :(
[14:40:29 CEST] <BtbN> Not a bug.
[14:40:45 CEST] <BtbN> format conversion is rather slow.
[14:42:25 CEST] <loki_> so i think all about timings and threading...
[14:43:06 CEST] <loki_> grabing of screenshots in syncrounus operations and it is already bottleneck.
[14:43:14 CEST] <debianuser> Being fast for "pixfmt:rgba" but slow for "pixfmt:bgr0" seems like a bug to me. :)
[14:44:12 CEST] <nevcairiel> depends, with a it might want to preserve alpha which would be more work
[14:46:24 CEST] <BtbN> Well, nobody writing hand-optimized assembler for that conversion for your set of cpu features is not a bug.
[14:47:25 CEST] <debianuser> nevcairiel: heh, but "pixfmt:rgba" is FASTER than "pixfmt:bgr0" :)
[14:48:14 CEST] <loki_> strange...
[14:48:28 CEST] <loki_> i have fps down when i add coversion
[14:48:37 CEST] <loki_> and it is fastest with bgr0
[14:48:44 CEST] <loki_> i think you doing something wrong
[14:48:58 CEST] <nevcairiel> BtbN: wat, nvidia GPUs being exceptionally bad at getting the image from the GPU? Have you tried this on AMD? It'll make your entire system crawl when you try to grab 1080p @ 60 fps on some GPUs :P
[14:49:26 CEST] <BtbN> Well, my integrated intel one happy does 200fps+
[14:49:29 CEST] <nevcairiel> At least the windows driver has a nice DMA path for this with minimal CPU usage, experience on other OS'es might vary
[14:49:38 CEST] <nevcairiel> on windows i can easily grab 500 fps
[14:49:54 CEST] <BtbN> No x11grab on windows though
[14:50:03 CEST] <BtbN> windows has propper APIs for screen grabbing, too
[14:50:05 CEST] <nevcairiel> nah, just the copy from gpu memory
[14:50:45 CEST] <nevcairiel> (unfortunately ffmepg doesnt support any of the proper Windows APIs though)
[14:51:06 CEST] <nevcairiel> well, the one proper API, that is.
[14:51:22 CEST] <BtbN> Desktop Duplication on Win8+
[14:51:30 CEST] <nevcairiel> yeah, thats the only proper API
[14:51:33 CEST] <nevcairiel> anything before sucks
[14:52:30 CEST] <debianuser> BtbN: Agree. It seems there wasn't even a C-special case for it. So I tried to write one (basically copypasted ff_rgb24toyv12_c() in libswscale/rgb2rgb_template.c). Tested it: http://pastebin.com/ivJrF5kv ~180fps (!). Patched ffmpeg with it: http://pastebin.com/aCmV9A4W - 53fps.
[14:52:35 CEST] <nevcairiel> in any case, AMD even has trouble in real-time copying of a 1080p60 video stream back to system memory after decoding on the GPU, while both intel and nvidia cna do 500 fps easy (assuming it decodes that fast)
[14:52:35 CEST] <debianuser> Even without asm, just a plain C implementation got me faster than 40fps, still not 180fps, not even 60fps somewhy. :(
[14:53:15 CEST] <BtbN> Because it's an inefficient C implementation.
[14:53:44 CEST] <nevcairiel> Without proper profiling, its impossible to judge where the speed is really going
[14:54:15 CEST] <debianuser> But why ffmpeg+x11grab = 100fps, C-implementation = 180fps, ffmpeg+x11grab+C-implementation=53fps?
[14:54:59 CEST] <nevcairiel> because its all running on one thread, so performance cost adds up
[14:56:04 CEST] <debianuser> It should be ~100fps then, since ffmpeg+x11grab takes ~5% CPU :)
[14:56:40 CEST] <nevcairiel> 100 fps means it takes 10ms to process every frame, 180 fps means it takes 5.5ms to process each frame, add both up, it takes ~15.5 ms per frame (~65 fps).. add some small extra overhead, and its easily at 53 fps
[14:56:56 CEST] <wm4> huh, I thought ffmpeg used multiple threads to a degree
[14:57:02 CEST] <wm4> ffmpeg.c I mean
[14:57:09 CEST] <nevcairiel> probably not in such a capture graph
[14:59:18 CEST] <debianuser> nevcairiel: "100 fps means it takes 10ms to process every frame" - But it doesn't actually do anything during those 10ms :) It just captures them every 10ms, using ~5% CPU.
[14:59:55 CEST] <nevcairiel> then profile, and stop speculating.
[15:00:06 CEST] <nevcairiel> we cant help you unless you provide tangible evidence
[15:00:43 CEST] <debianuser> I tried. :) callgrind of my patched ffmpeg says that most of the time is spent in my function...
[15:00:59 CEST] <debianuser> Hm... Maybe there's a bug in x11grab somewhere, doing usleep(10000) no matter how much time it spent doing format conversion...
[15:02:47 CEST] <debianuser> nevcairiel: by the way, if you're on windows, can you show what format is used when doing screengrabbing there? I.e. `ffmpeg -v debug -f dshow -r 60 -s 1280x1024 -i ... -vf format=yuv420p -t 30 -f null -` ?
[15:37:21 CEST] <cone-232> ffmpeg 03Vignesh Venkatasubramanian 07master:6fd300ac6c2c: lavf: Add support for WebM Live Muxing
[16:23:41 CEST] <loki_> debianuser: hi
[16:24:22 CEST] <loki_> debianuser: try simplescreenrecorder. i think he do biggest cpu utilization and it gives me high fps then ffmpeg
[16:24:41 CEST] <loki_> and it use ffmpeg to encode video lol
[16:24:51 CEST] <loki_> i think there is something about threading.
[16:25:41 CEST] <loki_> can someone explain me one thing. i checked code of x11grab and there is pause. are grabbing and encoding are independent proccess or not?
[16:26:13 CEST] <BtbN> x264 uses multiple threads. That's it.
[16:27:27 CEST] <nevcairiel> my guess is that conversion is on the same thread as grabbing
[16:28:12 CEST] <rcombs> just took a look at this "WebM Chunk" muxer
[16:28:54 CEST] <rcombs> wondering if it'd make more sense to have MPEG- and WebM-DASH both implemented using a more advanced form of the segment muxer
[16:29:04 CEST] <rcombs> less code duplication that way
[16:30:04 CEST] <loki_> nevcairiel: so that pause between frames can be bottleneck?
[16:30:12 CEST] <rcombs> speaking of which, michaelni: any thoughts on my segment.c patch? The WebM Live patch ended up making the changes we discussed (and decided not to make) in matroskaenc.c
[16:31:32 CEST] <Daemon404> does anyone who is not Google use webm dash
[16:31:35 CEST] <Daemon404> real question
[16:32:17 CEST] <rcombs> Daemon404: I'm planning on using something similar to but not quite like WebM Dash
[16:33:13 CEST] <rcombs> (segmented H.264 and AAC [single set of segments, rather than one per stream] with the header in a separate file, with on-demand concatenation from the seek target onwards handled on the server instead of the client)
[16:33:58 CEST] <Daemon404> uh
[16:34:04 CEST] <Daemon404> so why not use MPEG-DASH
[16:34:07 CEST] <Daemon404> which does exactly taht
[16:34:26 CEST] <Daemon404> and is actually a standard 
[16:34:40 CEST] <rcombs> because DASH clients are extremely picky about segment durations being as-advertised
[16:34:50 CEST] <rcombs> which is hard when you're remuxing user content on-demand
[16:35:06 CEST] <Daemon404> define user content
[16:35:15 CEST] <rcombs> the user's media files
[16:35:31 CEST] <Daemon404> only remuxing input seems like a bad idea
[16:35:40 CEST] <Daemon404> all sorts of broken garbage
[16:36:04 CEST] <rcombs> it's fast on weak hardware, doesn't degrade quality, and doesn't eat CPU
[16:36:13 CEST] <rcombs> there's an option to not do that
[16:36:47 CEST] <Daemon404> i mean, ive written something similar
[16:36:49 CEST] <rcombs> also, have you ever tried to use MPEG-DASH on an embedded system
[16:36:56 CEST] <Daemon404> getting teh segment lengths and stuff right is annoying but doable
[16:36:57 CEST] Action: rcombs points at Chromecast
[16:37:02 CEST] <Daemon404> yes i have
[16:37:16 CEST] <rcombs> fun fact, Chromecast doesn't actually have a DASH demuxer; you're supposed to do it in JS
[16:37:22 CEST] <Daemon404> i know
[16:37:32 CEST] <Daemon404> i wrote our DASH code
[16:37:34 CEST] <rcombs> and thus are extremely limited on memory (and therefore segment sizes)
[16:37:35 CEST] <Daemon404> our = company
[16:37:53 CEST] <Daemon404> you want super large segment sizes regardless
[16:38:03 CEST] <Daemon404> teh entire point of segments is adaptive streaming
[16:38:12 CEST] <BtbN> unless you do live streams
[16:38:18 CEST] <BtbN> super large segments = high delay
[16:38:25 CEST] <Daemon404> soryr
[16:38:28 CEST] <Daemon404> i mistyped
[16:38:28 CEST] <michaelni> rcombs, maybe ask/discuss with vignesh, ive no real preferrance on how its solved
[16:38:34 CEST] <Daemon404> im eant to type you DONT want large segments, BtbN 
[16:38:37 CEST] <Daemon404> meant*
[16:38:46 CEST] <rcombs> except when you're in JS and the whole segment has to be held in memory
[16:38:57 CEST] <Daemon404> rcombs, thats every dash implementation.
[16:39:07 CEST] <Daemon404> the mediasource api uses a uint8array
[16:39:08 CEST] <rcombs> (except for some reason there are a load of HLS client implementations that want to hold whole segments in memory)
[16:39:10 CEST] <Daemon404> you append, and feed to it
[16:39:16 CEST] <Daemon404> (in js)
[16:39:54 CEST] <Daemon404> in practice you probably want 5-10s segments at most
[16:40:00 CEST] <Daemon404> to be able to adapt properly
[16:40:01 CEST] <Daemon404> and quickly
[16:40:13 CEST] <rcombs> (like Roku: it handles large single MKV, MP4, MPEG-TS& files just fine& but if you have a single segment in an HLS stream larger than a few tens of MB, the whole thing freezes up)
[16:40:23 CEST] <Daemon404> roku is garbage
[16:40:29 CEST] <Daemon404> single worst plastic toy 
[16:40:34 CEST] <rcombs> there are bunches of other HLS clients just like that
[16:41:01 CEST] <rcombs> no fucking idea why they see "HLS" and go "hurr durr better buffer whole segments in memory when I have no problem streaming anything else"
[16:41:23 CEST] <Daemon404> i hink if you have segment sizes that large, somethign is weird
[16:41:35 CEST] <Daemon404> maybe 4k might be that large for a sane seg len
[16:41:38 CEST] <rcombs> Daemon404: that's great when you're on a powerful encoder machine spitting out several adaptive streams at the same time and serving to a lot of clients
[16:42:04 CEST] <Daemon404> ?
[16:42:21 CEST] <rcombs> Daemon404: but my use-case is a consumer media server that needs to be able to run reasonably on an ARM
[16:42:28 CEST] <Daemon404> i am quite sure that using a smaller segment length will not cripple an ARM cpu
[16:42:31 CEST] <Daemon404> while muxing
[16:42:37 CEST] <rcombs> yeah, sure
[16:42:46 CEST] <rcombs> but you don't have fine control of the segment sizes
[16:42:56 CEST] <rcombs> you're limited by the input stream's keyframes
[16:43:06 CEST] <Daemon404> usually you have some control over kf distance
[16:43:06 CEST] <rcombs> 1 large GoP == fucked
[16:43:26 CEST] <Daemon404> rcombs, also
[16:43:28 CEST] <Daemon404> may i add
[16:43:37 CEST] <Daemon404> mpeg dash does not require segs to start with keyframes
[16:43:38 CEST] <Daemon404> nor does hls.
[16:43:45 CEST] <Daemon404> in fact, most hls streams ive seen do not.
[16:44:29 CEST] <Daemon404> right now, one browser doesnt support DASH properly like that though (because Google only cares about youtube, and noone elses)
[16:44:38 CEST] <Daemon404> i would think non-keyframe segments would be standard in live streaming
[16:44:46 CEST] <Daemon404> thats specifically why the bug was filed for chrome
[16:44:50 CEST] <Daemon404> (it works fine for hls)
[16:45:49 CEST] <rcombs> wait wat
[16:46:07 CEST] <Daemon404> e.g. look at every single hls stream from akamai
[16:46:16 CEST] <rcombs> http://dashif.org/about-dash-industry-forum/ "Segments are keyframe-aligned across representations"
[16:46:30 CEST] <Daemon404> you are conflating segments and fragments perhaps
[16:46:39 CEST] <Daemon404> ah, no, i am conflatign DASH and MSE
[16:46:43 CEST] <Daemon404> MSE does not require it
[16:48:25 CEST] <Daemon404> fwiw i think it's insane to server user content directly to viewers by rmeuxing
[16:48:29 CEST] <Daemon404> security nightmare
[16:49:04 CEST] <nevcairiel> if the user controls that content, ie. its his own media library, its probably fine
[16:49:12 CEST] <rcombs> "user" here == "server owner" + "people the server owner has explicitly shared the server with"
[16:49:36 CEST] <rcombs> "A segment that contains video SHOULD have at least one key frame and enough information to completely initialize a video decoder."&
[16:49:53 CEST] <Daemon404> rcombs, let me find the relevant chromium bug
[16:49:55 CEST] <rcombs> &but it's just a SHOULD, so I SHOULD play around and see which clients are lenient about it
[16:49:59 CEST] <nevcairiel> should in spec talk is MUSST HAVE?
[16:50:04 CEST] <Daemon404> rcombs, i already did
[16:50:13 CEST] <Daemon404> it works fine in IE, not in chrome
[16:50:19 CEST] <Daemon404> and firefox doesnt have DASH... sooo
[16:50:29 CEST] <Daemon404> let me dig up teh relevant bug
[16:51:11 CEST] <Daemon404> https://code.google.com/p/chromium/issues/detail?id=229412
[16:51:12 CEST] <Daemon404> iirc
[16:51:25 CEST] <Daemon404> > Reported by acolw... at chromium.org, Apr 9, 2013
[16:51:28 CEST] <rcombs> Daemon404: and Safari, Opera, pre-Blink Opera (as deployed on a number of Smart TV devices), various Android player stacks, Roku, PS3/4, Xbox 360+One, Windows 8, <ad nauseum>
[16:51:29 CEST] <Daemon404> so dont hold out hope
[16:51:44 CEST] <Daemon404> rcombs, i menat for FASH
[16:51:46 CEST] <rcombs> ("Smart" TV)
[16:51:46 CEST] <Daemon404> DASH*
[16:52:04 CEST] <Daemon404> i know for a fact hls should work fine with no keyframe at the start
[16:52:35 CEST] <Daemon404> because the largest CDN in the world makes it like that
[16:52:39 CEST] <Daemon404> served to all those devices.
[16:52:41 CEST] <rcombs> I should send a patch to add an option to let segment.c break video on non-keyframes, then
[16:52:44 CEST] <nevcairiel> i've seen many android phones that even fail on hls streams with a keyframe, since we encode them that way
[16:53:01 CEST] <Daemon404> nevcairiel, android hls is writeoff
[16:53:05 CEST] <rcombs> nevcairiel: Android phones don't even need an excuse to fail on media playback
[16:53:06 CEST] <Daemon404> they just dont care
[16:53:22 CEST] <rcombs> it's so fragmented
[16:53:24 CEST] <nevcairiel> it works perfectly fine on nexuis phones
[16:53:32 CEST] <nevcairiel> some others however
[16:53:34 CEST] <nevcairiel> specifically sony
[16:53:35 CEST] <nevcairiel> :d
[16:53:43 CEST] <Daemon404> hls works on my s4, but dash in chrome on the same s4 is lolbad
[16:53:55 CEST] <rcombs> I feel very sorry for our Android guys who have to put up with this shit
[16:54:00 CEST] <nevcairiel> we dont use chrome, we use the media player
[16:54:08 CEST] <rcombs> ExoPlayer is apparently nice, though
[16:54:19 CEST] <Daemon404> nevcairiel, api-level is still incosistent as hell
[16:54:27 CEST] <Daemon404> android dev policies are nonexistent afaict
[16:54:35 CEST] <rcombs> in that it gives better consistency for another level or two of the player stack
[16:55:12 CEST] <rcombs> (by putting it in the app instead of in hundreds of different ROMs for different versions on different phones from different manufacturers who don't give a fuck)
[16:55:20 CEST] <wm4> <Daemon404> mpeg dash does not require segs to start with keyframes
[16:55:21 CEST] <wm4> <Daemon404> nor does hls.
[16:55:21 CEST] <wm4> <Daemon404> in fact, most hls streams ive seen do not.
[16:55:34 CEST] <wm4> does ffmpeg's hls demuxer handle this correctly?
[16:55:40 CEST] <Daemon404> i dont know
[16:55:44 CEST] <Daemon404> i have never used it
[16:55:50 CEST] <Daemon404> wm4, try any akamai hls stream i guess
[16:55:50 CEST] <wm4> (I don't see how it could)
[16:55:59 CEST] <nevcairiel> the demuxer probably just throws a continues mpegts stream at the mpegts demuxer
[16:56:06 CEST] <Daemon404> the only hls i care about is mostly apple's
[16:56:09 CEST] <rcombs> nevcairiel: yup
[16:56:10 CEST] <Daemon404> and some android
[16:56:23 CEST] <Daemon404> i can use less-shitty things elsewhere
[16:56:23 CEST] <nevcairiel> i wonder if ExoPlayer is something i might want to look into
[16:56:25 CEST] <Daemon404> instead of hls
[16:56:34 CEST] <rcombs> so I'd guess, some broken frames until the first keyframe and then normalcy
[16:56:51 CEST] <wm4> hm that's weird then
[16:56:56 CEST] <rcombs> nevcairiel: our Android guys tell me they're also reasonably responsive to GitHub issues
[16:57:12 CEST] <Daemon404> for now
[16:57:16 CEST] <Daemon404> until they build up
[16:58:14 CEST] <nevcairiel> ExoPlayer would also make it reasonably easy to hook up new formats, if we ever feel the need to do that
[16:59:01 CEST] <rcombs> they're in the middle of wrapping up HLS support, where they previously just had DASH
[16:59:07 CEST] <rcombs> (and non-streaming formats)
[16:59:31 CEST] <nevcairiel> once HLS is in and tested, it might be an interesting choice for us, get away from the vendor-specific problems in the default media player
[18:13:11 CEST] <Daemon404> how painful are STL subtitles
[18:13:52 CEST] <nevcairiel> is that a real question or one of the rhetorical kind
[18:14:12 CEST] <Daemon404> lol
[18:14:19 CEST] <Daemon404> someone approached me about adding stl support
[18:14:24 CEST] <Daemon404> to vimeo
[18:14:24 CEST] <kierank> Hahaha
[18:14:36 CEST] <nevcairiel> the format isnt that crazy
[18:15:10 CEST] <Daemon404> it looks less annoying than scc was
[18:15:41 CEST] <nevcairiel> one annoying part is that it supports loading graphics
[18:15:44 CEST] <nevcairiel> instead of plain text
[18:15:49 CEST] <nevcairiel> but you could just ignore that for now
[18:16:00 CEST] <Daemon404> doesnt matter
[18:16:07 CEST] <Daemon404> i normalize subtitles to a common subset
[18:16:13 CEST] <Daemon404> id just drop it and warn
[18:16:44 CEST] <nevcairiel> then the format probably shouldnt be too bad
[18:20:50 CEST] <Timothy_Gu> michaelni: sorry about forgetting to push to release/1.2. did you backport it or no? There aren't any conflicts iirc
[18:21:34 CEST] <michaelni> Timothy_Gu, just cherry picked it locally
[18:42:53 CEST] <Timothy_Gu> michaelni: ok
[20:08:54 CEST] <cone-232> ffmpeg 03Luca Barbato 07master:108f2f381acb: parseutils: Extend small_strptime to be used in avformat
[20:08:55 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07master:0739179bfb00: Merge commit '108f2f381acb93827fb4add0517eeae859afa3bf'
[20:28:03 CEST] <Plorkyeran> STL's actually pretty pleasant as far as subtitle formats go
[20:28:09 CEST] <Plorkyeran> there's a real spec
[20:28:18 CEST] <Plorkyeran> and real-world usage is similar to what the spec says
[20:28:30 CEST] <Plorkyeran> and the spec is not 500 pages
[20:28:43 CEST] <Plorkyeran> that alone puts it ahead of most formats
[20:31:53 CEST] <wm4> ubitux: I have a MicroDVD file with this as first line: {1}{1}23.976
[20:32:06 CEST] <wm4> ubitux: libavformat appears to return it as event
[20:32:19 CEST] <wm4> Plorkyeran: sounds pretty awesome indeed
[20:32:56 CEST] <wm4> and libavformat has a stl demuxer thanks to OPW
[20:34:18 CEST] <wm4> does anyone know any other software which actually reads the MicroDVD fps header?
[20:34:26 CEST] <wm4> open source software, that is
[20:34:58 CEST] <j-b> VLC does
[20:35:08 CEST] <Plorkyeran> I'm pretty sure Aegisub does
[20:35:37 CEST] <j-b> wm4: in vlc we try to strtof and if it's a value that makes sense, uses it.
[20:36:14 CEST] <wm4> j-b: do you remember which source file?
[20:37:08 CEST] <j-b> wm4: you're a stealer!
[20:37:09 CEST] <j-b> wm4: https://git.videolan.org/?p=vlc.git;a=blob;f=modules/demux/subtitle.c;hb=HEAD#l880
[20:37:29 CEST] <wm4> thanks
[20:37:50 CEST] <j-b> I would take this source code with extreme care
[20:37:57 CEST] <j-b> a LOT of security issues are in it.
[20:38:52 CEST] <wm4> that kind of stuff is why I dumped mplayer's subtitle parser
[20:39:06 CEST] <wm4> mplayer's was a lot worse, of course
[20:39:27 CEST] <Plorkyeran> huh, aegisub's parser also allows square brackets
[20:39:35 CEST] <wm4> so it tries "sscanf( s, "{%d}{}%[^\r\n]", &i_start, psz_text ) == 2", but how is this not dead code?
[20:39:37 CEST] <Plorkyeran> I wonder what insane program that's a hack for
[20:40:03 CEST] <wm4> it calls break; if i_stop!=1, and i_stop is initialized to -1
[20:42:10 CEST] <wm4> weird, libavformat's code looks like it should be handling this
[20:47:20 CEST] <wm4> uh, just doesn't skip the line itself
[20:47:34 CEST] <j-b> 20:44 < fflogger> [editedticket] calestyo: Ticket #4441 (support HDCD) updated https://trac.ffmpeg.org/ticket/4441#comment:4
[20:47:44 CEST] <j-b> lol, we had the same crap asked
[20:52:30 CEST] <wm4> ubitux: ooh, I get it, it was because I still had your hack applied to extend subtitles with duration=0
[20:57:50 CEST] <cone-232> ffmpeg 03Luca Barbato 07master:27f274628234: parseutils: Make av_small_strptime public
[20:57:51 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07master:9c37c8124614: Merge commit '27f274628234c1f934b9a6a6380ed567c1b4ceae'
[20:58:36 CEST] <kierank> Daemon404: do you mean EBU STL or the other STL?
[20:59:09 CEST] <Daemon404> i was only told stl
[20:59:15 CEST] <Daemon404> the one in common use
[20:59:25 CEST] <kierank> dunno then
[20:59:27 CEST] <kierank> could be either
[20:59:41 CEST] <Daemon404> i doubt it is ebu stl
[20:59:43 CEST] <Daemon404> since it is new
[20:59:46 CEST] <Daemon404> and european
[21:00:04 CEST] <kierank> spruce stl
[21:00:06 CEST] <kierank> that's the one
[21:00:35 CEST] <Daemon404> ebu shouldnt have aliased the name
[21:03:36 CEST] <kierank> spruce did
[21:03:37 CEST] <kierank> ebu stl is from the 80s
[21:04:17 CEST] <Daemon404> oic
[21:51:26 CEST] <cone-232> ffmpeg 03Vignesh Venkatasubramanian 07master:d6bb82387c12: webmdashenc: Fix fate in MSVC
[22:05:16 CEST] <debianuser> so, it seems x11grab works like this: usleep(frametime-curtime); request frame; sleep until the frame is received; process the frame (format conversion). It may be possible to workaround that by doing asynchronous request of the next frame while current frame is still processed and then "delaying" that frame a little...
[22:05:19 CEST] <debianuser> Or better, it could be fixed by doing format conversion in a separate thread. Other inputs (dshow, v4l, gdigrab) could benefit from it too. But I don't know how to do that. Don't even know where to start looking. :(
[22:48:15 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07master:3662e251cbe0: avformat/asfenc: Check for index_ptr allocation failure
[22:56:33 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07master:f289422a3ea5: avformat/ape: Use av_malloc_array()
[23:28:18 CEST] <cone-232> ffmpeg 03Michael Niedermayer 07master:235589ee9e9a: avformat/segment: Change enum to int, which is accessed via AVOption as int
[23:28:20 CEST] <Prelude2004c> hey.. can anyone help me with these errors please ( http://pastebin.com/xqDemsiA ) .. my CPU's are fine no load almost.. the card is barely being used
[23:31:48 CEST] <Prelude2004c> anyone?
[23:49:44 CEST] <Compn> Prelude2004c : try asking on mailing list, more attention there
[23:50:14 CEST] <Compn> Prelude2004c : without command line params we dont know whats wrong... network issue mayyyybe ? check dmesg too
[00:00:00 CEST] --- Wed Apr  8 2015