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

[burek]

[00:05:39 CET] <sfan5> 4 is fine too
[00:34:58 CET] <furq> 4 lowpasses at like 15.5khz
[00:35:03 CET] <furq> which isn't really "cd quality"
[00:37:17 CET] <furq> also i'm pretty sure 96kbps per channel for 5 is a limit, not a target
[00:37:21 CET] <furq> so it should always come in lower than that
[00:38:26 CET] <sfan5> add -cutoff 20000
[00:38:37 CET] <sfan5> though i'm not sure what quality implications that had
[00:38:38 CET] <sfan5> has*
[00:38:56 CET] <furq> honestly, just use 5
[00:39:45 CET] <sfan5> if you have the space, ofc
[00:43:00 CET] <furq> ok apparently the HA page is completely wrong about it being a limit
[00:43:17 CET] <furq> i just encoded an EP and it came in around 240kbps
[00:43:23 CET] <furq> so yeah i guess 4 is more attractive in that case
[00:43:58 CET] <furq> i am completely shocked and devastated that i found incorrect information on hydrogenaudio
[00:57:32 CET] <utack> furq i think fdk aac always cuts off at 17khz, no?
[00:57:43 CET] <utack> so 15.5 is really not THAT different from what it normally does
[01:02:19 CET] <furq> vbr 5 has no lowpass
[01:04:10 CET] <utack> ah for vbr only
[01:04:19 CET] <utack> but any bitrate CBR has it...
[01:04:23 CET] <utack> that is really odd?
[01:05:10 CET] <furq> a bit
[01:05:17 CET] <furq> lame also lowpasses at any cbr bitrate but not with v0
[01:05:20 CET] <furq> so it's not unprecedented
[01:05:24 CET] <furq> i couldn't tell you why though
[01:06:11 CET] <utack> i noticed that on a sound test on android with BT headphones, at 17.000 it cut off.
[01:06:33 CET] <utack> pretty weird choice to do so, when you have the bandwith to go high bitrate
[01:37:11 CET] <chandoo> hi ffplay is giving me the error in windows10
[01:37:13 CET] <chandoo>  encoder         : Lavc57.10
[01:37:13 CET] <chandoo> SDL advised audio format 33056 is not supported!
[11:56:59 CET] <irgendwer4711> hi, is there any way to visulize the mbtree of a 1st pass?
[11:57:10 CET] <irgendwer4711> e. .g like a diagram
[17:18:04 CET] <logicWEB> hey :-) so, I was doing a big transcode recently, and it suddenly got into this state where ffmpeg had a high probability of randomly crashing partway through
[17:18:10 CET] <logicWEB> it crashed at a different time on each pass
[17:18:25 CET] <logicWEB> I'm not 100% certain yet, but I *think* it might have correlated with ASS subtitles that extended past the bottom edge of the frame
[17:18:59 CET] <c_14> segfault?
[17:18:59 CET] <logicWEB> I have adjusted the subtitles and I'm pretty sure they always fit in the frame now, and I've had one successful transcode pass with no crashing, and another pass is well underway with no crash yet
[17:19:02 CET] <logicWEB> yeah
[17:19:11 CET] <c_14> core dump/backtrace?
[17:19:27 CET] <logicWEB> I mean, it's Windows, so "ffmpeg.exe has stopped working"
[17:19:33 CET] <c_14> oh
[17:19:35 CET] <c_14> eeeeh
[17:19:45 CET] <c_14> I think you can get at crash dumps in windows _somehow_
[17:19:51 CET] <logicWEB> yeah, harder to capture a backtrace on a Windows build
[17:20:01 CET] <logicWEB> I don't think Windows captures them by default but you can install dev tools that let you get them
[17:20:07 CET] <logicWEB> it does capture some basic info, not sure if it'd be enough to debug
[17:20:19 CET] <c_14> plus the windows builds probably aren't built with debug info
[17:21:02 CET] <logicWEB> probably not, yeah
[17:21:55 CET] <c_14> if you could create a small file out of the original that can be used as a reproducer, that would work as well
[17:22:03 CET] <logicWEB> I just dug one up in the Event Viewer
[17:22:13 CET] <logicWEB> Faulting module name: ffmpeg.exe, version: 0.0.0.0, time stamp: 0x00000000 / Exception code: 0xc0000005 / Fault offset: 0x00000000016e6612
[17:22:19 CET] <logicWEB> it has this line too: Report Id: 7c402be4-e824-48cd-b229-95b90c3947e1
[17:22:36 CET] <logicWEB> I've never done it before but I *think* Windows actually logs the crash with some server Microsoft operates, and you can use that ID to look up the details
[17:23:10 CET] <logicWEB> I don't know if I could, because the crashes typically happened on frame numbers 4 or 5 digits wide (the entire source video was ~70,000 frames)
[17:23:13 CET] <Johnjay> i've looked up things in the event viewer but i have no idea what to do with the data other than the description
[17:23:27 CET] <Johnjay> i do know you can lookup the minidump but that's it
[17:23:40 CET] <logicWEB> but if my theory is right then perhaps it doesn't matter what the video is at all, it's all about the subtitles
[17:24:08 CET] <c_14> does it happen around the same timestamp? because then you can potentially just grab that part of the subs/source file
[17:24:10 CET] <logicWEB> might even be able to reproduce it with -i color
[17:24:17 CET] <logicWEB> nope, it was different every time
[17:25:14 CET] <logicWEB> across 12 attempts, 10 crashed, 2 succeeded, and the crashes were at frame numbers 8663, 52792, 6758, 41489, 4510, 12683, 24993, 20263, 18965 and 31856
[17:25:30 CET] <c_14> hmm
[17:25:32 CET] <c_14> that's weird
[17:26:18 CET] <logicWEB> yeah, I don't think it points to a logic error in the encoder. it _would_ be consistent with something overwriting bits of the heap it doesn't own, if the heap layout isn't exactly the same every time through
[17:26:34 CET] <logicWEB> I'm guessing there's something stochastic about x264 encoding? two consecutive encodes with identical parameters won't produce the same bits of output?
[17:26:58 CET] <logicWEB> that could explain why the heap is different on each run, and why the point at which it overwrites something sensitive is different each time
[17:27:11 CET] <furq> x264 is deterministic as long as the vbv is off iirc
[17:27:19 CET] <logicWEB> hmm okay, there goes that theory...
[17:27:30 CET] <logicWEB> maybe it's Windows itself doing it with its address space layout randomization
[17:27:34 CET] <BtbN> vbv is on usually, unless you do crf or so
[17:27:44 CET] <furq> well crf is on usually so yeah
[17:27:51 CET] <logicWEB> I was forcing the CRF in those encodes to values between 19.9 and 20.5
[17:27:57 CET] <logicWEB> 20.4
[17:28:09 CET] <furq> you're not using avisynth or something like that are you
[17:28:13 CET] <logicWEB> nope
[17:28:25 CET] <furq> is this a git build
[17:28:38 CET] <logicWEB> hmm, yes it is
[17:28:54 CET] <logicWEB> --version says git-2017-12-22-e3b2c85
[17:28:55 CET] <furq> if you just want it to work then just try a release build
[17:28:59 CET] <furq> oh that's pretty old
[17:29:20 CET] <furq> any bug report from that version would be useless unless you can reproduce it with git head
[17:29:26 CET] <logicWEB> yeah, so I guess for meaningful debugging, I'd need to reproduce it with... yeah exactly
[17:29:54 CET] <logicWEB> for what it's worth, the command-line was structured like this: ffmpeg -i 00000.m2ts -map 0:0 -map 0:1 -vf ass=Subs.ass -c:a aac -b:a 192k -global_quality:a 500 -c:v libx264 -preset veryslow -crf 19.9 -y Output-CRF19.9.mkv
[17:30:30 CET] <furq> you should probably use -vf subtitles from ffmpeg
[17:31:05 CET] <furq> -vf ass is some internal libavfilter thing that doesn't require lavc/lavf
[17:31:06 CET] <logicWEB> okay, so I guess if I decide to pursue this, I'll do it with the most recent build and I'll see if I can make it happen with a minimal ASS file and -i color
[17:31:19 CET] <furq> i'm not entirely sure why that's useful to anyone but it must be good for something
[17:31:32 CET] <logicWEB> does -vf subtitles use ASS internally too?
[17:31:43 CET] <furq> it uses any text subtitle format that libass supports
[17:32:05 CET] <logicWEB> okay so the end effect should be essentially pixel-identical to -vf ass, it's just a more modern & better-supported code path?
[17:32:14 CET] <furq> subtitles depends on other libs in ffmpeg
[17:32:34 CET] <furq> it should look identical but you might want to double check
[17:32:40 CET] <furq> but subtitles is definitely the recommended thing to use
[17:33:28 CET] <logicWEB> okay, good to know
[17:33:32 CET] <furq> so yeah if you have found a bug then it's probably in -vf ass
[17:33:36 CET] <furq> i don't know how much use that gets
[17:34:15 CET] <logicWEB> the subtitles in question had a misconfiguration causing them to have massive drop shadows, and I noticed yesterday that the drop shadow was so large it actually extended past the bottom of the framebuffer. the crashes seemed to stop when I reduced the drop shadow so that the text is entirely within the framebuffer
[17:34:41 CET] <logicWEB> (but I don't have enough attempts yet to say conclusively that the crashes are gone)
[17:42:57 CET] <logicWEB> okay I just generated weird behaviour by making a sample ASS file with the same misconfiguration and piping it through ffplay -v lavfi -i color=color=red -vf ass=Crash.ass
[17:43:25 CET] <logicWEB> about 2/3 of the way through, it just stopped advancing the subtitles, and then the video played past the -t 30 I'd set it to. when it got to about 60 seconds in, I hit 'q' and the process froze instead of exiting
[17:46:01 CET] <logicWEB> hmm, it's not doing it again
[19:32:51 CET] <mateothegreat> j #rasbian
[19:45:51 CET] <logicWEB> mateothegreat: btw I think it's "raspbian", not "rasbian"
[19:46:40 CET] <mateothegreat> yea...
[19:46:43 CET] <mateothegreat> I totally nailed it bro
[19:46:48 CET] <logicWEB> :sD
[19:46:49 CET] <logicWEB> :-D
[19:47:08 CET] <mateothegreat> man quassel is a pile of shit
[19:47:26 CET] <mateothegreat> time to roll out some eggdrop bots on kubernetes giggity
[19:47:42 CET] <mateothegreat> is that still a thing lol
[19:48:46 CET] <logicWEB> I'm not actually sure of the answer to that :-)
[19:49:09 CET] <mateothegreat> I'm trying to get all this slack off of me
[19:49:09 CET] <mateothegreat> ugh
[19:49:18 CET] <mateothegreat> (slack chat that is)
[19:51:35 CET] <logicWEB> true story, the icon on my taskbar next to "#ffmpeg on Freenode" reads "Slack"
[19:52:13 CET] <mateothegreat> :/
[20:01:48 CET] <pos> Is it at all possible to display multiple inputs (v4l, streams, etc) on the same screen (sep frames, vlc calls this "mosaic") with ffplay?
[20:03:08 CET] <durandal_1707> pos: yes
[20:04:06 CET] <durandal_1707> also ffplay is for testing only, use mpv
[20:04:59 CET] <pos> i have been searching for "mplayer/ffplay/mpv/etc mosaic" without much luck
[20:05:23 CET] <durandal_1707> pos: mpv.io is web page
[20:05:26 CET] <pos> i've found a way to use ffserver and then play it, but waste of resources
[20:07:17 CET] <durandal_1707> pos: mpv video1.mkv --external-files=video2.mkv --lavfi-complex="[vid1][vid2]hstack[vo]"
[20:07:34 CET] <durandal_1707> that is command for playing 2 videos side by side
[20:08:30 CET] <durandal_1707> if you also need audio from both inputs, use: mpv video1.mkv --external-files=video2.mkv --lavfi-complex="[vid1][vid2]hstack[vo];[aid1][aid2]amix[ao]"
[20:08:33 CET] <pos> so "mpv rtsp://1.2.3.4/1.sdp --external-files=rtsp://1.2.3.5/1.sdp --lavfi-complex="[vid1][vid2]hstack[vo]"" should work?
[20:09:14 CET] <durandal_1707> pos: that is filtering with mpv player, same can be done with ffmpeg
[20:09:51 CET] <durandal_1707> using network as input, may work, I did not tried
[20:10:08 CET] <pos> additional inputs, comma sep using the same --external-files or sep --external-files?
[20:12:58 CET] <durandal_1707> pos: look into manual, either use --external-files= or --external-file=
[20:13:14 CET] <pos> right
[20:14:47 CET] <furq> pos: you can also do ffmpeg -i rtsp://foo.sdp -i rtsp://bar.sdp -lavfi hstack -c:v rawvideo -f nut - | mpv -
[20:16:02 CET] <furq> mpv uses the same lib for filtering though so it should work without that
[20:35:35 CET] <pos> both work, but the latter lets ffmpeg do some layout magic that neither mpv nor mplayer supports?
[22:37:19 CET] <pos> ffmpeg -i rtsp://foo.sdp -i rtsp://bar.sdp -lavfi hstack -c:v rawvideo -f nut - | mpv -
[22:37:45 CET] <pos> this works fine if all sources have the same resolution, any way to make it scale diff ones?
[22:38:26 CET] <durandal_1707> pos: add neccessary spagetti code before hstack filter :)
[22:38:56 CET] <durandal_1707> could use scale2ref filter... to be automatic
[22:41:37 CET] <pos> looking at it. how would it be applied for say 4 diff rtsp sources output as a 1920 composite?
[22:45:35 CET] <durandal_1707> it goes very complicated, and it may become slow
[22:47:26 CET] <furq> you'll probably need setpts as well
[22:47:31 CET] <furq> unless you know the timestamps are all in alignment
[22:48:33 CET] <pos> -fflags setpts
[22:48:35 CET] <pos> check
[22:48:36 CET] <pos> :)
[22:48:38 CET] <furq> if you want a 2x2 grid then setpts,scale for each input, hstack 0 and 2, hstack 1 and 3, then vstack those
[22:48:46 CET] <furq> and no i mean -vf setpts=PTS-STARTPTS
[22:49:17 CET] <furq> you might specifically not want that
[22:49:42 CET] <furq> but e.g. if one source is way ahead of the others then this'll just buffer frames forever and probably eventually get oom killed
[22:49:58 CET] <furq> if you know the timestamps are in sync then you probably don't want to rewrite them arbitrarily
[22:50:57 CET] <pos> right. this is turning out to be somewhat complicated, any sw that just does this on auto?
[22:51:52 CET] <pos> kinda easy with vlc, unfortunately there is a bug in a xenial dependency
[22:51:56 CET] <furq> not that i know of
[22:52:04 CET] <furq> it's not really that complicated
[22:52:43 CET] <pos> ok, care to paste an example, then i'll reverse the syntax?
[22:55:05 CET] <furq> http://vpaste.net/akDJU
[22:55:06 CET] <furq> something like that
[22:57:45 CET] <furq> that'll work but if these are security cameras or something that you'd want to keep in sync then setpts will desync them
[22:57:48 CET] <furq> so just remove those if necessary
[22:58:08 CET] <pos> right. scale each input as per the output res. i was going about this the wrong way.
[22:58:11 CET] <pos> thanks
[22:58:19 CET] <furq> s/will/may/
[23:02:37 CET] <pos> now, adding additional sources seems straightforward, but i'll have to test on-site and won't be there until next week. care to spot me an eight or twelve input example so i won't waste an hour figuring out the hstack/vstack lines then?
[23:03:38 CET] <durandal_1707> pos: that is really too much
[23:04:04 CET] <durandal_1707> and pts drops are not really handled gracefully
[23:04:53 CET] <pos> will re-instantiate each hour or so
[23:05:06 CET] <durandal_1707> so if you want pro solution you will need to do something about that...
[23:05:19 CET] <durandal_1707> that will not help much
[23:05:42 CET] <durandal_1707> actually i never tested framesync so much with network streams
[23:20:31 CET] <pos> yeah, testing with some tunneled conns right now
[23:20:37 CET] <pos> isn't pretty
[23:23:47 CET] <furq> pos: hstack/vstack take as many inputs as you want
[23:23:58 CET] <furq> so e.g. [v0][v2][v4][v6]hstack=4[t]
[23:25:21 CET] <pos> the mosaic hangs at diff intervals, output has "Past duration 0.963402 too large" several times a second
[23:31:31 CET] <pos> furq, got it, thanks
[23:46:12 CET] <pos> furq, i scaled it up for eight inputs ad adjusted the scale res
[23:47:39 CET] <pos> https://pastebin.mozilla.org/9080290
[23:48:31 CET] <pos> with height 270 the output image only fills half the screen, with 540 (since only two rows) the output gets mangled
[00:00:00 CET] --- Sun Mar 18 2018