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

[burek]

[00:43:11 CET] <multi_io> got it working
[02:16:17 CET] <multi_io> well, almost
[02:16:42 CET] <multi_io> resulting video plays fine in mplayer, but ffprobe complains "Unsupported codec with id 100359 for input stream 2"
[02:17:28 CET] <multi_io> source video was: Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, 2 channels, fltp, 96 kb/s    Stream #0:1: Video: wmv2 (WMV2 / 0x32564D57), yuv420p, 320x240, 415 kb/s, 24 tbr, 1k tbn, 1k tbc
[02:18:19 CET] <multi_io> output video is mp4, no special codec options to ffmpeg
[02:20:05 CET] <multi_io> mplayer on the output video (as I said, it plays fine) says [lavf] stream 0: video (h264), -vid 0\n[lavf] stream 1: audio (aac), -aid 0, -alang und\n[lavf] stream 2: subtitle (mov_text), -sid 0, -slang eng
[02:21:43 CET] <multi_io> not sure where that subtitle stream came from, there's none in the input video
[03:54:37 CET] <poutine> good evening, I love you
[04:33:47 CET] <Hello71> nty
[06:35:07 CET] <fling> Does opencl help much? What about x264?
[16:39:20 CET] <TheWild> hello
[16:39:54 CET] <TheWild> any chances to convert ISO/VOB to MKV/whatever without reencoding?
[16:42:45 CET] <TheWild> ok, never mind. setting .mp4 file as output worked. I tried .mkv at first thinking it's more universal
[16:43:28 CET] <JEEB> both should work
[16:48:47 CET] <TheWild> ffmpeg -i 'concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB' -c copy /tmp/ramfs/80.mp4
[16:49:00 CET] <TheWild> can't copy the localized audio though :/
[16:49:25 CET] <furq> TheWild: -map 0
[16:50:50 CET] <TheWild> -map 1:a:0 ?
[16:51:20 CET] <JEEB> that is a single input as far as I can tell :P
[16:51:21 CET] <furq> no, -map 0
[16:51:29 CET] <JEEB> 1 would be the second input
[16:51:32 CET] <JEEB> 0th is the first one
[16:53:11 CET] <TheWild> ffmpeg -i 'concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB' -c copy -map 0:v:0 -map 0:a:1 /tmp/ramfs/80.mp4
[16:53:25 CET] <TheWild> hooray! Thank you JEEB.
[16:53:35 CET] <TheWild> you gave me hint what keyword I should search for
[16:53:50 CET] <TheWild> oh, furq
[16:53:53 CET] <TheWild> JEEB too
[17:42:50 CET] <and_> Hello! How can I change the interval ffmpeg (hls) is using to poll live stream m3u8 file? The problem is that it seems to do this every 20sec but my stream requires 10s or the url expires and stream stops.
[17:44:16 CET] <JEEB> it should depend on the ext duration
[17:44:35 CET] <JEEB> in the HLS playlist
[17:47:40 CET] <and_> the second playlist (first has links to playlists with different bitstreams) has #EXT-X-TARGETDURATION:10 (i think it's the needed info, no?) set but seems like it's not honoured
[17:50:36 CET] <JEEB> looking at hls.c on master it is supposed to use half of target_duration for reload interval
[17:52:28 CET] <JEEB> if you have built FFmpeg yourself I can even tell you how to verify that it did indeed read it :P
[17:53:04 CET] <JEEB> also there is a logic that checks the last segment's duration for it as well (supposedly for live playlists under some circuimstances)
[17:53:06 CET] <and_> at the moment i'm testing with ffplay version 4.1. when i open the playlist, streams stops ~1min and from logs i can see  DEBUG: ffmpeg[70000E597000]: [hls,applehttp] Failed to reload playlist 2
[17:53:51 CET] <and_> but when i create simple loop that pings the playlist url every 10sec witch curl my stream doesn't stop
[17:55:42 CET] <JEEB> http://up-cat.net/p/e3430418
[17:56:29 CET] <and_> the link is http://err-egress.cdn.mind.ee/live/etvh/playlist.m3u8 and it should be available now (many shows are geoblocked)
[17:57:47 CET] <JEEB> this with an extra message when the badly named parse_playlist gets called http://up-cat.net/p/1f014c11
[17:58:09 CET] <JEEB> (name of function is "parse playlist" while it also goes and gets the playlist then as well)
[17:58:58 CET] <JEEB> also I don't think curl by default does keepalive between requests
[17:59:08 CET] <JEEB> while the hls "demuxer" does keepalive I think by default
[18:03:09 CET] <and_> i use packaged ffmpeg, haven't compiled anything for ages :(
[18:04:04 CET] <and_> the server should be wowza and apparently it's enough to fetch the url with your id= every 10sec to keep the stream alive
[18:04:44 CET] <Alina-malina> not sure how to fade out with ffmpeg
[18:05:16 CET] <Alina-malina> by time, not frame second
[18:05:41 CET] <JEEB> and_: you can see if -v debug says anything useful (although you will be getting a *lot* of logging, and I'm not sure how much would be from hls.c)
[18:06:07 CET] <JEEB> also you might want to check if `-http_persistent 0` helps
[18:06:20 CET] <JEEB> before input, since it's an input option
[18:14:16 CET] <and_> JEEB: tried http_persistent but didn't help. the m3u8 url just stops working if not polled every 10s. for example https://err10.babahhcdn.com/live/etvh/index.m3u8?id=35466747366527 is now dead and logtail from ffplay: https://pastebin.com/m8bMm58q
[20:02:22 CET] <FishPencil> How should a PSNR be normalized to give a similar result to SSIM (0-1)?
[20:35:42 CET] <Alina-malina> anyone? might have idea how to realize fade out at the end of the video with seconds and not frames?
[20:36:49 CET] <durandal_1707> Alina-malina: duration/d ?
[20:38:00 CET] <Alina-malina> durandal_1707, hmmm is that an option?
[20:38:23 CET] <durandal_1707> yes
[20:39:06 CET] <Alina-malina> durandal_1707, well this is my command ffmpeg -i wormax11_.mp4 -y -vf fade=out:1900:100 test2.mp4   i could hardly find that 1900 frame, but this is really not convenient for me
[20:39:22 CET] <Alina-malina> let me find the usage of duration option, never used that
[20:40:07 CET] <durandal_1707> start_time/st too
[20:43:33 CET] <FishPencil> So I did a comparison between x265's -preset normal vs. -preset veryslow. The SSIM is only 0.129% different between the two... I know SSIM doesn't tell the whole story, but that doesn't seem worth it for the massively increased computation time.
[20:44:35 CET] <furq> ssim doesn't tell much of a story at all for modern video codecs
[20:44:43 CET] <furq> you probably want to use vmaf or something
[20:44:53 CET] <furq> or your eyes, but that's not ideal if you want numbers as an output
[20:46:07 CET] <FishPencil> For PSNR it was like 0.0258% difference between the two.
[20:46:29 CET] <furq> psnr is much the same
[20:46:39 CET] <FishPencil> I know SSIM/PSNR doesn't tell me much, but I do feel like if it's less than a 1% difference I'm likely not going to visually see that
[20:47:28 CET] <furq> they're really not useful metrics at all
[20:48:03 CET] <FishPencil> I would say they get you in the same city as the ballpark.
[20:48:37 CET] <furq> at least x264 and x265 intentionally distort the input image
[20:48:40 CET] <furq> and probably vpx
[20:49:21 CET] <furq> you can turn all the psy stuff off with -tune psnr but then you've turned all the psy stuff off so it's not a fair comparison
[20:49:59 CET] <FishPencil> I did use the tune option, and I'd assume that without it the visual comparison would be even hard to tell
[20:51:15 CET] <FishPencil> For the difference between placebo and ultrafast it was 1.53% different for SSIM
[20:51:39 CET] <furq> like i said, vmaf is the only thing in ffmpeg that even claims to be able to give you useful metrics for this
[20:52:04 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#libvmaf
[20:52:56 CET] <FishPencil> That's fine and I can try it, but I really doubt it's going to be shocking different like you're suggesting.
[20:54:00 CET] <furq> disabling psy makes a noticeable difference to quality
[20:54:21 CET] <furq> and i would assume it disproportionately affects the slower presets because they use it more
[20:54:28 CET] <furq> it does in x264 anyway
[20:55:41 CET] <FishPencil> Are you able to tell the difference between veryslow and normal with x264?
[20:57:05 CET] <FishPencil> s/normal/medium
[20:57:32 CET] <furq> that's a broad question
[20:57:40 CET] <furq> i have noticed the difference before with all other settings being equal
[21:10:58 CET] <Alina-malina> durandal_1707, ffmpeg -i wormax11_.mp4 -y -af "fade=out:st=00\:00\:28.0\:d=4" test2.mp4  i am trying this command, but there is no fade on that time :-/
[21:11:48 CET] <durandal_1707> Alina-malina: remove last \
[21:12:12 CET] <durandal_1707> you are escaping duration
[21:12:16 CET] <Alina-malina> ok let me try just a second checking
[21:14:02 CET] <Alina-malina> still cant see any effect durandal_1707
[21:15:10 CET] <durandal_1707> Alina-malina: pastebin command & full uncut ffmpeg output
[21:15:54 CET] <Alina-malina> durandal_1707, https://pastebin.com/raw/Kb7Rfa8i
[21:16:22 CET] <FishPencil> furq: Was it blind testing?
[21:17:58 CET] <furq> no
[21:18:10 CET] <durandal_1707> Alina-malina: you are using very old, >5 years ffmpeg
[21:18:23 CET] <furq> i have no confidence i could consistently do it
[21:18:31 CET] <furq> i'm just saying psnr and ssim are not good metrics for this
[21:18:43 CET] <Alina-malina> oh
[21:18:53 CET] <Alina-malina> durandal_1707, ok letme try to upgrade, strange i thought i already ugprade it
[21:19:05 CET] <durandal_1707> Alina-malina: also just use seconds for st option
[21:19:28 CET] <FishPencil> furq: I'm just saying I don't think they're completely useless and do tell a little of the story.
[21:20:25 CET] <FishPencil> furq: It's not like they're going to give <0.1% difference values and in reality the sources are completely distinguishable
[21:23:34 CET] <Alina-malina> durandal_1707, same :-/
[21:28:25 CET] <durandal_1707> Alina-malina: pastebin command & full uncut ffmpeg output
[21:29:48 CET] <Alina-malina> durandal_1707, https://pastebin.com/raw/2cK58j8h
[21:30:56 CET] <durandal_1707> Alina-malina: -vf, -af is for audio
[21:31:18 CET] <Alina-malina> oh
[21:32:10 CET] <Alina-malina> oh finaly durandal_1707 thank you so much my man!
[23:38:39 CET] <atoms118> ok so I'm trying to stream 1080p60 video from a PC to a smartphone real-time for VR purposes; I currently have http://dpaste.com/22KKKC4, however there's still ~1 second of latency
[23:39:08 CET] <atoms118> it's running over loopback currently, not actually streaming to my smartphone, so it isn't the network being a bottleneck or anything
[23:39:34 CET] <atoms118> I'm not certain whether it's the attached streaming script not working or if ffplay is just really slow at decoding
[23:57:10 CET] <furq> atoms118: it should be -tune ultrafast,fastdecode
[23:57:28 CET] <furq> er
[23:57:33 CET] <furq> -tune zerolatency,fastdecode
[00:00:00 CET] --- Mon Dec  3 2018