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

[burek]

[04:36:49 CEST] <tester> Hi.  I'm working on an image processing project, and am new to ffmpeg.  I'm decoding an MPEG-4 video file and I need to access the frames in RGB format.  My question is: which type of decoding result will be fastest, planar or packed pixel?  Thanks.
[04:51:42 CEST] <TD-Linux> generally planar
[04:53:31 CEST] <kepstin> hmm, to decode mpeg-4 to rgb, you need to do a format conversion from yuv to rgb
[04:53:47 CEST] <kepstin> i think they'll probably both be about the same, really.
[04:54:06 CEST] <kepstin> and packed rgb is usually better-supported than planar by other software
[05:08:22 CEST] <tester> Alright, thanks
[09:33:06 CEST] <xxzzxx> hi
[09:33:19 CEST] <xxzzxx> anyone here ?
[15:42:46 CEST] <thunfisch> hi, can anyone point me to some information on how to compile ffmpeg with decklink support for ubuntu 16.04? right now it's complaining about the missing sdk-headers of course, but i don't know where to put those.
[16:15:35 CEST] <xochilpili> hi all
[16:16:34 CEST] <Elgu> hi
[16:17:04 CEST] <xochilpili> i have in my library a lot of movies and series, but they're in different format, mp4, avi, mkv mostly, i have installed plex in the server in order to watch them, but im experiencing some troubles with plex, and i think about to make my own "plex"
[16:17:44 CEST] <xochilpili> but as far i understand, <video> tags in html5 can only reproduce ogg, mp4 files but not mkv
[16:18:10 CEST] <tp_> the mkv container works in chrome
[16:18:28 CEST] <xochilpili> is there a way to transcode the selected file using ffmpeg in realtime ? i mean, i click on a video that i want to watch, then transcode the mkv into a mp4 in order to watch it
[16:18:31 CEST] <kepstin> it's up to the browser, but vp8/vp8 in webm and h.264 in mp4 are the most widely supported
[16:18:34 CEST] <xochilpili> is that possible?
[16:18:48 CEST] <kepstin> into mp4? no. But you could do webm maybe
[16:18:58 CEST] <xochilpili> webm ?
[16:19:44 CEST] <kepstin> you could also look at doing HLS or DASH streaming
[16:20:58 CEST] <xochilpili> thanks !
[16:21:32 CEST] <Filarius> Hell, how to make ffmpeg take source in "player mode". I record livestreams and they often have A/V sync issue (non-monotonous DTS) on start, and this also make re-encoded record also have A/V sync issue, and even appears in video editing in Sony Vegas
[16:21:36 CEST] <Filarius> *Hello
[16:22:22 CEST] <Filarius> this issue looks like lag, freeze, or repeating video in first 3 seconds
[16:22:56 CEST] <Filarius> http://pastebin.com/jtYnTB58
[16:24:24 CEST] <xochilpili> kepstin, using HLS i need to convert all files into a mp4 or m3u8 ??
[16:25:37 CEST] <kepstin> xochilpili: you'd probably want to use ffmpeg's hls muxer, which generates the playlist and segment files.
[16:25:43 CEST] <Filarius> and also issue is not "works" at Web players like in Dropbox, Youtube also somehow fix it, but I have too many videos
[16:27:23 CEST] <xochilpili> kepstin, im lost
[16:27:39 CEST] <furq> xochilpili: i'd expect most of your mkv files will be h.264 and aac or mp3, in which case you can remux them to mp4 and they'll play in a browser
[16:28:35 CEST] <kepstin> as long as there's no subtitles, yeah :)
[16:28:44 CEST] <furq> srt subtitles will be fine
[16:29:19 CEST] <kepstin> well, most browsers only play external webvtt subs right now :/
[16:29:24 CEST] <kepstin> but I guess that's doable
[16:29:26 CEST] <furq> oh, browsers
[16:29:33 CEST] <furq> i forgot that quickly
[16:29:38 CEST] <xochilpili> im really lost, i dont know how to start
[16:29:51 CEST] <xochilpili> i found this: http://ffmpeg.gusari.org/viewtopic.php?f=12&t=914
[16:30:16 CEST] <xochilpili> but i think this guy is capture from a device with video2linux /dev/vide0
[16:30:25 CEST] <xochilpili> which is not my case
[16:30:36 CEST] <furq> isn't this the exact problem which plex is supposed to solve
[16:30:40 CEST] <furq> i don't see what else it does
[16:31:26 CEST] <momomo> furq, i switched to using your suggested version of ffmpeg, static build .. but now I am getting: Decoder (codec dvb_teletext) not found for input stream #0:2
[16:31:37 CEST] <xochilpili> plex remux files?
[16:31:47 CEST] <momomo> i think its not able to parse subtitles files or something
[16:32:05 CEST] <furq> is there a teletext stream
[16:32:13 CEST] <furq> i would have thought that would be ignored
[16:32:17 CEST] <momomo> furg, maybe yes .. is there a way to ignore it ?
[16:32:44 CEST] <furq> i guess that's a video stream, so just use -map if you don't care about it
[16:33:13 CEST] <furq> https://ffmpeg.org/ffmpeg.html#Advanced-options
[16:35:03 CEST] <furq> oh maybe it is a subtitle stream
[16:35:20 CEST] <furq> try -map -0:s
[16:37:24 CEST] <momomo> furq, Stream map '0:s' matches no streams.
[16:37:42 CEST] <momomo> it might be that i don't have one now
[16:38:19 CEST] <momomo> To ignore this, add a trailing '?' to the map.
[16:38:30 CEST] <momomo> -map? -0:s
[16:38:33 CEST] <momomo> didn't work
[16:38:59 CEST] <momomo> neither did -map -0:s ?
[16:40:34 CEST] <momomo> now,  it seems i have the same error ( program switched maybe ) Decoder (codec dvb_teletext) not found for input stream #0:2
[16:40:43 CEST] <momomo> even with -map -0:s
[16:42:19 CEST] <furq> if it's always stream 0:2 then use -map -0:2
[16:42:25 CEST] <momomo> output http://hastebin.com/ijewetoyon.md
[16:42:31 CEST] <momomo> i tried that
[16:42:43 CEST] <momomo> that did not work .. doesn't match
[16:43:17 CEST] <thunfisch> okay, got my ffmpeg to compile (decklink-sdk headers had to go to /usr/include), but now it's missing the -c, -acopy, -vcopy commands etc. used this config: https://paste.xinu.at/aps/ could it be, that I left too many flags out?
[16:43:43 CEST] <furq> momomo: paste the command
[16:44:22 CEST] <momomo> here is the command: http://hastebin.com/emusehahox.mel
[16:44:23 CEST] <furq> thunfisch: there is no such flag as -acopy or -vcopy
[16:44:32 CEST] <furq> it's -c:a copy and -c:v copy
[16:44:43 CEST] <thunfisch> oh, okay
[16:44:48 CEST] <xochilpili> found this: http://dash-mse-test.appspot.com/dash-player.html
[16:44:49 CEST] <furq> and -c copy to copy all streams
[16:45:07 CEST] <xochilpili> but how to they create the mpd ?
[16:45:09 CEST] <thunfisch> furq: if i use -c, it says command not found
[16:45:20 CEST] <xochilpili> how's the server side?
[16:45:27 CEST] <furq> command not found is a shell error message, not ffmpeg
[16:46:55 CEST] <momomo> furq, me ?
[16:47:11 CEST] <furq> i have no idea what's going on with yours
[16:47:49 CEST] <furq> 0:s and 0:2 should both work
[16:47:52 CEST] <momomo> seems like something has happened in the latter builds .. or maybe this static build is using a different configuration ?
[16:48:45 CEST] <furq> i think you need to link with libzvbi to enable dvb_teletext
[16:48:47 CEST] <momomo> furq, here is the configuration http://hastebin.com/uroxavijic.mel
[16:48:50 CEST] <furq> i guess the static builds don't do that
[16:49:04 CEST] <momomo> furq, is it easy to build ffmpeg manually ?
[16:49:14 CEST] <momomo> or will i have to spend  like a day on that ?
[16:49:22 CEST] <furq> it's pretty easy
[16:49:40 CEST] <furq> i don't think you should have to, though
[16:49:50 CEST] <momomo> the build in ubuntu now uses some libsass that I have too old for .. and I am not sure how to update that
[16:49:52 CEST] <furq> you should be able to ignore that stream regardless
[16:50:00 CEST] <momomo> there is probably other dependencies
[16:50:16 CEST] <momomo> ook .. does the map command look right thouhg ? the location of it ?
[16:50:22 CEST] <momomo> or should it be before the input ?
[16:50:25 CEST] <momomo> or after
[16:50:31 CEST] <furq> it's an output option
[16:50:48 CEST] <furq> you could try -map 0:0 -map 0:1
[16:51:00 CEST] <furq> or -map 0:v -map 0:a
[16:51:37 CEST] <furq> maybe there's some bug related to ignoring undecodable streams
[16:52:06 CEST] <furq> but there should be no need to build your own ffmpeg unless you actually want to decode the subtitles
[16:52:40 CEST] <momomo> i couldn't find any new references to it
[16:52:42 CEST] <momomo> online
[16:53:07 CEST] <furq> references to what
[16:53:16 CEST] <momomo> to a bug of that nature
[16:53:21 CEST] <furq> oh
[16:53:26 CEST] <furq> yeah that's a weird one
[16:53:50 CEST] <momomo> even this causes error
[16:53:51 CEST] <momomo> Stream map '0:0' matches no streams.
[16:54:01 CEST] <momomo> probably not using hte map function properly
[16:55:38 CEST] <momomo> ah
[16:55:46 CEST] <momomo> i was using -map -0:1
[16:55:51 CEST] <furq> oh right
[16:55:57 CEST] <furq> yeah - is to exclude
[16:58:04 CEST] <momomo> -map 0:v -map 0:a is correct ?
[16:58:10 CEST] <furq> should be
[16:58:12 CEST] <momomo> or -map 0:a:2  ?
[16:58:15 CEST] <momomo> -sn (output)
[16:58:15 CEST] <momomo>     Disable subtitle recording.
[16:58:20 CEST] <furq> -sn should also work
[16:58:49 CEST] <furq> that probably makes more sense actually
[16:59:16 CEST] <momomo> thanks dude! i spent like 4 hours on this yesterday
[16:59:23 CEST] <momomo> you need to come in on sundays too :P
[16:59:24 CEST] <momomo> haha
[16:59:30 CEST] <momomo> -sn worked
[17:00:20 CEST] <momomo> yesterday i also found these options :
[17:00:50 CEST] <momomo> -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -i but they are unrecogninzed ...
[17:01:24 CEST] <momomo> i've noticed that sometimes a process  can die ( if I pull the ethernet cable  for like a minute ) but I would like it to resume when it can ..
[17:01:37 CEST] <momomo> these options are noted under protocol ( http )
[17:01:54 CEST] <momomo> https://ffmpeg.org/ffmpeg-protocols.html
[17:02:06 CEST] <momomo> but I seem to be using them wrong
[17:02:23 CEST] <furq> i have those in a recent build
[17:02:26 CEST] <furq> they're new in 3.x
[17:03:56 CEST] <momomo> oh maybe I should try again .. i tried before  i think ( couldnt get this verion to work )
[17:04:51 CEST] <momomo> yeah, they worked
[17:14:54 CEST] <Carl_> Could anyone help me out please? I am streaming H264 video to media server. Everything works as expected but the video delay is the problem. After a few seconds the delay get bigger. I'm using these parameters for encoding http://pastebin.com/v0N78k3r
[17:24:38 CEST] <xochilpili> how can i convert srt into vtt files?
[17:25:15 CEST] <Elgu> I compiled ffmpeg on centos and when I try to use vp9 it gives me following message
[17:25:17 CEST] <Elgu> [libvpx-vp9 @ 0x2684ae0] The encoder 'libvpx-vp9' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.
[17:25:35 CEST] <Elgu> is there a way to accept vp9 always?
[17:25:42 CEST] <Elgu> without -strict -2
[17:28:22 CEST] <Carl_> How could i reduce packet size without losing much quality ?
[17:28:42 CEST] <Elgu> Carl_: vp9
[17:29:54 CEST] <satinder___> hi , I am using drawtext filter with updated text file every time but I am getting following error
[17:30:11 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] [FILE @ 0x7f17fc000180] Error occurred in mmap(): Invalid argument
[17:30:11 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] The text file 'OverlayInfo' could not be read or is empty
[17:30:11 CEST] <satinder___> Failed to inject frame into filter network: Invalid argument
[17:30:11 CEST] <satinder___> [video4linux2,v4l2 @ 0x7f17ec000c20] Some buffers are still owned by the caller on close.
[17:30:11 CEST] <satinder___> open: No such file or directory
[17:30:28 CEST] Last message repeated 1 time(s).
[17:30:28 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] [FILE @ 0x7f17fc000180] Error occurred in mmap(): Invalid argument
[17:30:28 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] The text file 'OverlayInfo' could not be read or is empty
[17:30:28 CEST] <satinder___> Failed to inject frame into filter network: Invalid argument
[17:30:28 CEST] <satinder___> [video4linux2,v4l2 @ 0x7f17ec000c20] Some buffers are still owned by the caller on close.
[17:30:28 CEST] <satinder___> open: No such file or directory
[17:30:45 CEST] Last message repeated 1 time(s).
[17:30:45 CEST] <satinder___> sorry for mistake
[17:31:12 CEST] <satinder___> Some body give my suggestion about rename the file I did it
[17:31:25 CEST] <Carl_> Elgu, is it good for video streaming?
[17:31:35 CEST] <furq> Carl_: if you're streaming mpegts over tcp/udp then append ?pkt_size=1316 (or whatever) to the url
[17:31:41 CEST] <Elgu> I don't know that, but it's good for videos
[17:31:44 CEST] <satinder___> rename(temfile ,/home/Overlayfile )
[17:31:46 CEST] <furq> that's how you do it with the ffmpeg cli, idk if it works the same with the api
[17:32:02 CEST] <furq> that should also have no effect on quality
[17:32:03 CEST] <satinder___> but the error is same
[17:32:21 CEST] <satinder___> for 2 mins that is working after that i am getting error
[17:32:31 CEST] <Carl_> furq, i'm streaming over rtsp
[17:34:02 CEST] <satinder___> please any one can help me ??
[17:34:32 CEST] <Carl_> the video quality is excellent, but the delay is horrible
[17:34:39 CEST] <furq> oh
[17:34:48 CEST] <furq> i doubt that has anything to do with packet size
[17:35:02 CEST] <Elgu> no one any idea?
[17:35:05 CEST] <Elgu> [libvpx-vp9 @ 0x2684ae0] The encoder 'libvpx-vp9' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.
[17:35:15 CEST] <furq> Elgu: what's wrong with adding -strict -2
[17:35:27 CEST] <Elgu> I use a python tool to encode videos
[17:35:31 CEST] <Carl_> i thought reducing packets , sending them to server might reduce the delay
[17:35:37 CEST] <Elgu> and on my pc it's working finde, but on my server it isn't
[17:35:44 CEST] <Elgu> so I was wondering.
[17:36:00 CEST] <furq> probably different ffmpeg versions
[17:36:11 CEST] <furq> afaik libvpx-vp9 was only marked as experimental recently
[17:36:36 CEST] <furq> -strict -2 should make no difference if you're not using any marked-as-experimental codecs
[17:36:55 CEST] <Elgu> yeah could be
[17:37:04 CEST] <Elgu> my pc is running the one from the arch reo
[17:37:13 CEST] <Elgu> my server is using the latest I guess
[17:37:15 CEST] <Elgu> I compiled it
[17:37:57 CEST] <Carl_> Even reducing bitrate wont help me
[17:38:32 CEST] <furq> Carl_: you could try whatever the api equivalent of -tune zerolatency is
[17:38:41 CEST] <Elgu> Carl_: https://pypi.python.org/pypi/webm
[17:38:49 CEST] <Elgu> try this out, it's awesome
[17:39:20 CEST] <furq> that doesn't have anything to do with what he's asking
[17:39:55 CEST] <Elgu> yeah but anyways
[17:39:56 CEST] <Elgu> good tool
[17:41:27 CEST] <Carl_> i'm using c++ for ffmpeg
[17:42:02 CEST] <xochilpili> does anyone know how to convert subtitles in srt into vtt ?
[17:42:46 CEST] <furq> xochilpili: -c:s webvtt
[17:43:12 CEST] <Carl_> furq, -tune zerolatency is reducing unreadable quality lol
[17:43:18 CEST] <xochilpili> furq, ffmpeg -i source.srt -c:s webvtt output.vtt?
[17:43:34 CEST] <furq> xochilpili: if you're converting srt to vtt then you don't even need the -c:s webvtt
[17:44:34 CEST] <xochilpili> i have done this : ffmpeg -i source.srt out.vtt and i got this >  Unable to find a suitable output format for out.vtt
[17:44:41 CEST] <furq> Carl_: increase the bitrate?
[17:44:54 CEST] <furq> or the gop size, although that might cause more latency issues depending on your streaming setup
[17:46:57 CEST] <satinder___> furq : what I can do for atomic writing of a textfile for drawtext filter , Currently I am using rename(oldpath , newpath) , but I getting still error after 2 mins of video playing
[17:55:24 CEST] <satinder___> hi there are any one ??
[17:59:14 CEST] <Carl_> the delay is like 20sec and getting worse by the time
[18:03:14 CEST] <Guest78901> Hey!
[18:03:46 CEST] <Guest78901> I'm having trouble running frei0r filters with ffmpeg, would appreciate any help...
[18:03:59 CEST] <Guest78901> I posted an SO q with all the details here http://stackoverflow.com/questions/36398469/running-frei0r-filters-with-ffmpeg-could-not-find-module-pixeliz0r
[18:04:25 CEST] <Guest78901> but basically, I installed frei0r with homebrew
[18:04:40 CEST] <Guest78901> and I can't figure out how to tell ffmpeg where the filters are
[18:14:30 CEST] <entdark> hello, guys
[18:14:51 CEST] <entdark> I have a problem writing default mp4 files
[18:15:37 CEST] <entdark> the problem is when the file reaches 2 GB size, it stops encoding
[18:15:59 CEST] <entdark> the command is "ffmpeg -f avi -i - -threads 0 -preset ultrafast -y -pix_fmt yuv444p -crf 23 %o.mp4 2> ffmpeglog.txt"
[18:16:05 CEST] <kepstin> what os, filesystem?
[18:16:20 CEST] <entdark> windows 7 x64, ntfs
[18:16:33 CEST] <entdark> writing into ffmpeg stdin
[18:16:49 CEST] <entdark>     Stream #0:0: Video: rawvideo, bgr24, 1280x720, 60 fps, 60 tbr, 60 tbn, 60 tbc
[18:16:49 CEST] <entdark>     Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s
[18:22:45 CEST] <entdark> it also happens on mac
[18:23:00 CEST] <entdark> unable to check its filesystem now
[18:32:37 CEST] <entdark> alright, it stops at 1.56 GB
[18:39:10 CEST] <entdark> also, I just found out it's not file size limit issue, because with "-crf 0", I am currently getting the file over 2 GB
[18:39:25 CEST] <furq> at a guess, your input file is broken
[18:40:17 CEST] <entdark> well it is raw bgr24 data and raw pcm data
[18:40:24 CEST] <entdark> as I showed above
[19:55:55 CEST] <Filarius> hello, I need help in fixing video. Problem is what all PC players have various issue related to A/V sync, even after editors live Sony Vegas or Adobe Premier but looks okay in webplayers  http://pastebin.com/jtYnTB58  https://www.dropbox.com/s/yrvlvy2nry1izwk/record.flv
[19:56:22 CEST] <Filarius> video made by recording HLS stream
[20:03:56 CEST] <furq> Filarius: does the source video play correctly
[20:06:21 CEST] <Carl_> I can connect to both media servers. To localhost:1935 and also to my friends computer. But if i'm connecting to my friends computer then the data aren't going through. Server says that somekind of connection is available.
[20:06:33 CEST] <Carl_> If i'm connecting to localhost, then everythings works fine
[20:06:41 CEST] <Carl_> server i'm using is wowza media server
[20:06:48 CEST] <Carl_> i thought mby someone here can help me
[20:06:56 CEST] <furq> paste the non-working command
[20:07:08 CEST] <Carl_> unfortunately ther aren't non-working command
[20:07:14 CEST] <Carl_> just data doesn't go through
[20:07:24 CEST] <Carl_> maybe somekind of firewall which is blocking ?
[20:07:28 CEST] <Carl_> i'm out of ideas
[20:15:14 CEST] <c_14> What's the command?
[20:20:14 CEST] <entdark> so any idea on my issue?
[20:37:20 CEST] <momomo> what would be the reason -preset ultrafast lags a hls generated stream? cpu is around 2%
[20:39:51 CEST] <furq> lags?
[20:46:50 CEST] <entdark> alright, resolved the problem: it was in my code, so nvm
[20:55:45 CEST] <momomo> furq, yes, more frequent hickups near each ts segment ends in the player
[20:58:07 CEST] <momomo> -preset ultrafast goes down to 1-2 % for a stream .. while without I am hitting 6% - 15% .. which is unstainable .. I could not run more than 5-10 streams per server like that
[20:58:57 CEST] <momomo> question is what makes ultrafast or even veryfast lag
[20:59:03 CEST] <momomo> since cpu usage is lower
[20:59:09 CEST] <furq> does it happen with other presets
[20:59:18 CEST] <momomo> from doc: Try -preset veryfast if you are unsure of what to choose, then watch the console output or the video to see if the encoder is keeping up with your desired output frame rate: if it is not then use a faster preset and/or reduce your -video_size.
[20:59:40 CEST] <momomo> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites
[20:59:49 CEST] <furq> the wiki isn't really documentation
[20:59:55 CEST] <furq> a lot of it is outdated or anecdotal
[21:00:10 CEST] <furq> especially the streaming stuff which is about one step removed from folklore
[21:00:52 CEST] <momomo> yes, but maybe still relevant .. what do they mean .. watch the console if computer is keeping up .. the cpu usage is lower, it should be able to .. right?
[21:01:04 CEST] <furq> i assume it just means cpu usage
[21:01:13 CEST] <furq> or the framerate, rather
[21:01:56 CEST] <furq> like i said, check if it happens with other presets
[21:03:39 CEST] <momomo> i lowered the framerate to 10 but it still occurs ...
[21:03:48 CEST] <momomo> tried veryfast .. also
[21:03:54 CEST] <momomo> trying fast now
[21:04:06 CEST] <pa> do you guys have idea why hevc is getting spread, while vp9 is not?
[21:04:18 CEST] <pa> i read that performance-wise vp9 is the same is not better
[21:04:20 CEST] <furq> spread across cores?
[21:04:23 CEST] <pa> if
[21:04:30 CEST] <momomo> furq, maybe ultrafast requires a faster processor than about cpu usage
[21:04:31 CEST] <furq> i've never been able to make libvpx's multithreading work properly
[21:04:37 CEST] <momomo> althouhg mine is quite fast
[21:04:43 CEST] <momomo> but a laptop
[21:04:48 CEST] <TD-Linux> pa, what do you mean VP9 is not being spread?
[21:04:52 CEST] <momomo> i7 768m
[21:05:01 CEST] <pa> TD-Linux, i mean is not being used
[21:05:01 CEST] <furq> i don't see how the preset would cause this, especially if it still happens with veryfast
[21:05:09 CEST] <furq> i'd be more inclined to believe some other setting is causing it
[21:05:09 CEST] <TD-Linux> pa, but it is, Youtube and Steam use it
[21:05:20 CEST] <pa> i see a lot of videos appearing in x265 or hevc
[21:05:21 CEST] <furq> i noticed earlier that your command was missing -g and -keyint_min
[21:05:22 CEST] <TD-Linux> HEVC is practically nonexistent for internet streaming
[21:05:27 CEST] <pa> but nothing is  vp9
[21:05:37 CEST] <furq> which could explain it
[21:05:50 CEST] <furq> pa: all youtube videos from the past year or so are vp9
[21:06:00 CEST] <furq> vp9 is supported in most browsers, h265 isn't
[21:06:20 CEST] <pa> well but then why people don't use it, only google?
[21:06:28 CEST] <pa> no good free encoder?
[21:06:31 CEST] <pa> or easy to use?
[21:06:32 CEST] <furq> well it's google's codec so obviously they use it
[21:06:41 CEST] <kepstin> google uses the same encoder as everyone else (libvpx)
[21:06:46 CEST] <TD-Linux> pa, they do use it, your premise is wrong :)
[21:07:00 CEST] <kepstin> (google wrote the encoder)
[21:07:01 CEST] <furq> but it's not supported everywhere and will never be supported on iOS, which means every big video streaming service needs an mpeg-la licence for h.264 anyway
[21:07:05 CEST] <iive> i think he ask, why pirates don't use vp9
[21:07:22 CEST] <furq> so vp9 only makes sense if they're more bandwidth-constrained than cpu-constrained
[21:07:25 CEST] <furq> which i guess nobody is
[21:07:54 CEST] <furq> and pirates don't use vp9 because h.265 is probably a better codec
[21:08:03 CEST] <kepstin> why pirates don't use it? It's really slow to encode (multithreading issues too), and if you're pirating video you obviously don't care about licensing your encoder anyways :)
[21:08:04 CEST] <furq> and they don't care about the licensing fees
[21:08:31 CEST] <TD-Linux> x265 is not exactly speedy either
[21:08:32 CEST] <momomo> furq, yes, i removed those .. as I am experimenting ... and didn't see that they were neccesaary ... i've tried adding those too though .. i was thinking that -g and -keymin might increase cpu usage since they might possibly have to conform to more ruls
[21:08:39 CEST] <furq> x265 is a lot faster than vp9 in my experience
[21:08:44 CEST] <furq> libvpx-vp9 that is
[21:09:03 CEST] <furq> momomo: afaik you will run into problems with hls if your gops aren't fixed size
[21:09:07 CEST] <TD-Linux> furq, at what speed setting?
[21:09:26 CEST] <furq> the defaults iirc
[21:09:29 CEST] <TD-Linux> x265 can operate a lot faster than vp9 but you start losing significant quality at presets faster than veryslow
[21:09:58 CEST] <furq> i heard from unreliable internet sources that x265 medium is roughly equivalent to x264 veryslow
[21:10:00 CEST] <momomo> furq, using -x264-params scenecut=0 results in 10s segments
[21:10:05 CEST] <momomo> so not sure what g does
[21:10:11 CEST] <momomo> i've trying to figure that out
[21:10:19 CEST] <furq> -g is the maximum gop size
[21:10:26 CEST] <momomo> what is gop ?
[21:10:29 CEST] <furq> group of pictures
[21:10:48 CEST] <kepstin> approximately equivalent to keyframe interval, basically
[21:10:58 CEST] <kepstin> and every hls segment has to start with a keyframe
[21:10:59 CEST] <TD-Linux> furq, yeah that sounds about right
[21:11:13 CEST] <momomo> i am guessing -x264-params scenecut=0 applies something like that though ?
[21:11:15 CEST] <furq> momomo: the default for -g is 250, so 25fps video will give you 10-second gops if scenecut is off
[21:11:35 CEST] <iive> scenecut probably disables the scene change detection
[21:11:37 CEST] <furq> if your hls segment size isn't the same as the gop length then you're going to have a bad time
[21:11:47 CEST] <iive> that could insert additional keyframes at scene change
[21:11:50 CEST] <furq> segments have to start on an idr frame
[21:12:49 CEST] <kepstin> I think the way the HLS muxer in ffmpeg works, if there isn't an IDR frame in the right spot, it'll keep outputting to the current segment until it hits an IDR frame, then it switches
[21:13:00 CEST] <kepstin> so you'll get segments with really variable size and length
[21:13:20 CEST] <furq> well not if scenecut is off
[21:13:56 CEST] <pa> i havent seen many vp9 vids, but the hevc ones i found online aren't exactly high quality
[21:14:08 CEST] <furq> pa: most people who encode x265 don't know how to use it
[21:14:24 CEST] <furq> they read "50% smaller than x264!!" and encode at a really low bitrate at medium
[21:14:27 CEST] <TD-Linux> pa, keep in mind "quality" is a function of how many bits they put in
[21:14:31 CEST] <kepstin> well, if you're doing 30fps video, -g is 250, and you want 10 second segments - the end result is you're gonna get 16.6 second segments instead :/
[21:14:34 CEST] <momomo> i've haven't really exprienced any major issues with using just scenecut until i added preset ultrafast
[21:14:50 CEST] <furq> even though medium is barely more efficient than x264
[21:14:51 CEST] <momomo> i will try now agian with the other options .. although I already have
[21:15:42 CEST] <momomo> yes, same issues
[21:15:52 CEST] <furq> paste the full command
[21:16:01 CEST] <furq> also did you say it was still happening with preset fast
[21:17:01 CEST] <momomo> furq, http://hastebin.com/paladuvaju.md
[21:17:07 CEST] <momomo> furq, no, i think fast was good
[21:17:53 CEST] <furq> weird
[21:18:31 CEST] <momomo> but i can't really get my head around it .. ultrafast is supposed to lead to lower cpu usage
[21:18:48 CEST] <momomo> so it has to be about cpu speed ultimately
[21:19:16 CEST] <momomo> or a bug
[21:19:43 CEST] <momomo> but the commend in the old doc seems to suggest that something can make this lag
[21:19:53 CEST] <momomo> but it is not clear what
[21:20:10 CEST] <kepstin> momomo: I'm still not clear on exactly what you're seeing as "lag"
[21:20:37 CEST] <momomo> kepstin, at the end of each segment .. the player will request a new segment .. with no preset or preset fast i am getting those in time
[21:20:48 CEST] <momomo> with ultrafast it appears as if they don't get created in time
[21:21:06 CEST] <kepstin> momomo: so the new segment is in the playlist, but isn't on disk?
[21:21:13 CEST] <furq> oh weird
[21:21:33 CEST] <furq> i take it you're testing on localhost or lan so it's not a network issue
[21:21:38 CEST] <kepstin> ... the segments shouldn't be added to the playlist until they're completely written, iirc
[21:21:42 CEST] <kepstin> so that doesn't make sense
[21:21:53 CEST] <momomo> kepstin, not neccesary .. the playlist might still be outdated .. but the player will ask for a playlist again .. it's a bout 0.1 seconds lag
[21:22:07 CEST] <momomo> "outdated" -> not ready
[21:22:32 CEST] <momomo> it appears as if the segments are not done as quickly as with other presets
[21:22:32 CEST] <furq> yeah if the player hits the end of the playlist it'll start buffering iirc
[21:22:35 CEST] <furq> rather than stopping
[21:22:52 CEST] <momomo> yes, and ask for the playlist again until there is a new file
[21:23:07 CEST] <momomo> i can double check
[21:23:22 CEST] <furq> try it with a bunch of different presets
[21:23:42 CEST] <furq> i can't imagine why the preset would cause that, especially not if it's faster presets which don't work
[21:23:49 CEST] <kepstin> in the command you pasted, you're using -g 125 and -r 25, and want 10s segments
[21:23:53 CEST] <kepstin> that's not gonna work...
[21:24:03 CEST] <furq> 10 seconds is 125*2
[21:24:07 CEST] <furq> that should work fine
[21:24:14 CEST] <kepstin> oh, wait, i just can't math
[21:24:23 CEST] <kepstin> for some reason, 125/25=3 in my head ;)
[21:25:24 CEST] <momomo> i just noticed #EXTINF:10.021333,
[21:25:30 CEST] <momomo> in some playlist files
[21:25:39 CEST] <momomo> #EXTINF:10.000000, in others
[21:26:00 CEST] <momomo> ultrafast maybe does not confirm strictly to the segment length
[21:26:10 CEST] <furq> that's less than one frame
[21:27:25 CEST] <momomo> yes, not much
[21:28:38 CEST] <kepstin> you don't have '-re' on your command-line, right?
[21:28:49 CEST] <momomo> i tried it .. but that didn't help
[21:28:59 CEST] <furq> i'd have thought you'd need it for http streaming
[21:28:59 CEST] <kepstin> well, that should make it worse :)
[21:29:01 CEST] <momomo> kepstin, it's an input option right?
[21:29:21 CEST] <furq> yeah
[21:29:24 CEST] <kepstin> if it's a live input, you do *not* want -re
[21:29:31 CEST] <momomo> furq, the documentation is really confusing on that one
[21:29:41 CEST] <furq> it's normally used for streaming from files
[21:29:41 CEST] <kepstin> if it's a pre-recorded input that streams at faster than realtime, you want -re to slow it down
[21:30:13 CEST] <momomo> "Should not be used with actual grab devices or live input streams (where it can cause packet loss)." ...  It is useful for real-time output (e.g. live streaming).
[21:30:37 CEST] <momomo> i guess i have a live input stream .. but also a live output stream
[21:30:48 CEST] <kepstin> if you have a live input stream, you do not want -re.
[21:30:56 CEST] <momomo> ok
[21:30:59 CEST] <furq> if it works at all without -re then don't use it
[21:31:00 CEST] <kepstin> without -re, it'll encode as fast as it can read frames from the input
[21:31:11 CEST] <furq> it'll be very apparent whether or not you should use it
[21:31:21 CEST] <kepstin> which, at that preset, means that it'll be waiting on the input to provide more frames
[21:31:27 CEST] <momomo> i think i will just set a larger timeout after the playlist is ready
[21:31:29 CEST] <kepstin> what type of stream is the input, exactly?
[21:31:37 CEST] <momomo> it seems to be more ok later on.
[21:31:45 CEST] <momomo> after a couple of lags
[21:31:56 CEST] <kepstin> yeah, once the player has buffered a couple of segments behind, it'll be fine
[21:31:56 CEST] <furq> you could try a larger segment size
[21:32:06 CEST] <furq> that'll increase latency but it should reduce buffering
[21:32:12 CEST] <kepstin> momomo: what type of stream is the input?
[21:32:18 CEST] <momomo> tvheadend
[21:32:26 CEST] <kepstin> no, what protocol?
[21:32:29 CEST] <momomo> http
[21:32:32 CEST] <kepstin> what video container?
[21:32:41 CEST] <kepstin> is it hls? mpeg-ts?
[21:32:57 CEST] <fritsch> most likely broken - if it comes from tvhs demuxer ...
[21:33:11 CEST] <kepstin> how about you just paste your ffmpeg output?
[21:33:19 CEST] <momomo> mpeg2video
[21:35:10 CEST] <momomo> furq, the problem is that most often on a live stream you will always be close to the end ... the only way is to wait x seconds after playlist is ready to start 3 seconds after or something
[21:37:21 CEST] <kepstin> momomo: usually, the player is expected to prebuffer some amount of video before it starts playing, which will put enough delay in that the next segment will be ready in time.
[21:37:49 CEST] <furq> you can configure the buffer length with hls.js
[21:38:36 CEST] <momomo> kepstin, the player will ask for the manifest file first .. and soon as it gets it starts playing
[21:38:40 CEST] <momomo> at least hls.js does
[21:39:02 CEST] <momomo> i have a timeout functionality on the server
[21:39:04 CEST] <momomo> side
[21:40:31 CEST] <momomo> furq, i have played with those and using: http://hastebin.com/ilogocopah.cpp
[21:40:46 CEST] <momomo> timeout is 60000
[21:42:33 CEST] <momomo> i think a larger server timeout after playlist is working fine now .. although it might catch up eventually ..
[21:42:40 CEST] <momomo> but I think it's fine
[21:43:30 CEST] <momomo> i have also turned of crf so maybe the stream can be copied faster without any processing
[21:43:43 CEST] <momomo> or the cpu usage doesn't jump up
[21:44:04 CEST] <momomo> 1-2 % now
[21:44:12 CEST] <momomo> which is pretty much the same as crf 23
[21:45:26 CEST] <kepstin> momomo: the default is to do a crf encode at something around 22-24ish (i forget the exact default)
[21:45:40 CEST] <furq> 23
[21:45:48 CEST] <furq> if you don't specify -b:v then it'll be running at crf 23
[21:45:54 CEST] <furq> or -q:v
[21:46:52 CEST] <kepstin> that said, crf encode is an odd choice for a live stream, since the bitrate's gonna be very unpredictable. I suppose it's ok for a lan, tho, where you know you have 100mbit+ available.
[21:47:54 CEST] <furq> i'd assume it's fine if you have maxrate set
[21:48:21 CEST] <furq> emphasis on assume because the vbv is an enigma wrapped in a riddle wrapped in several contradictory wiki articles and forum posts
[21:49:18 CEST] <TD-Linux> the only way to know for sure is to read the code
[21:49:28 CEST] <momomo> fuck .. i have increaed it from 2000 to 5000 and it still occurs .. maybe it's something in hls.js
[21:50:19 CEST] <furq> TD-Linux: if i read the code am i then bound by the covenant of blood to never explain it to anyone clearly
[21:50:30 CEST] <furq> or will that just come naturally
[21:50:54 CEST] <TD-Linux> no, likely you will get angry, attempt to rewrite it, give up halfway through and retire to a small cottage in the woods
[21:52:32 CEST] <momomo> let me try with 10s timeout after playlist is generated .. although that is too much since next segment will overwrite it
[21:54:43 CEST] <momomo> still happened .. lowering to 7500
[21:56:08 CEST] <momomo> still happening
[21:56:18 CEST] <momomo> this is wierd
[21:56:21 CEST] <momomo> have to try in vlc
[21:57:21 CEST] <momomo> happens in vlc too .. it seems the cutting might make a few frames disappear at times
[21:57:30 CEST] <TD-Linux> fyi I don't think maxrate works with crf looking at the code
[21:57:32 CEST] <momomo> it goes blank and audio disappears
[21:58:27 CEST] <momomo> i am talking about a timeout
[21:58:40 CEST] <momomo> but it appears as if it is something else
[21:59:16 CEST] <momomo> i am going to try increassing list_size and remove hls_delete_segments
[21:59:20 CEST] <momomo> and try to play it afterwards
[22:03:14 CEST] <momomo> is there a way to get hls.js to ask for the next file much earlier or more aggressively ?
[22:04:03 CEST] <momomo> maxBufferLength
[22:04:18 CEST] <momomo> but mine is already 60
[22:04:49 CEST] <furq> maybe manifestLoadingRetryDelay
[22:05:03 CEST] <furq> that defaults to 1s though
[22:07:43 CEST] <momomo> i am exploring wether the transfer of files due to possibly being bigger because of preset ultrafast is causing hte lag .. the file is not served quickly enough from when it is asked for .. even though the initial timeout is large ... the asking for ts files is happening to late
[22:10:10 CEST] <furq> i can't imagine that would cause a noticeable difference on a lan
[22:11:26 CEST] <momomo> i need to continue with this tomorrow
[22:13:39 CEST] <momomo> it's a strange problem though .. but vlc seems fine .. so it's possibly a hls.js issue but i can't understand what would be the difference between the presets for it
[22:14:24 CEST] <momomo> i will play with some options tomorrow, thanks  for your help today :)
[22:19:24 CEST] <momomo> what is up with targetduration? http://hastebin.com/oducomemid.vala
[22:19:28 CEST] <momomo> 11
[22:20:42 CEST] <momomo> for no preset i get #EXTM3U
[22:20:42 CEST] <momomo> #EXT-X-VERSION:3
[22:20:42 CEST] <momomo> #EXT-X-TARGETDURATION:10
[22:20:42 CEST] <momomo> #EXT-X-MEDIA-SEQUENCE:0
[22:20:42 CEST] <momomo> #EXTINF:10.000000,
[22:20:43 CEST] <momomo> a0.ts
[22:20:46 CEST] <momomo> 10
[22:25:57 CEST] <momomo> sometimes i get 10 .. sometimes i get 11
[22:26:10 CEST] <momomo> but when I get 10 nothing happens
[22:26:16 CEST] <momomo> so this might be the issue
[22:26:39 CEST] <momomo> if segment length is 10 and it targets 11 for reload then obviously its going to lag
[22:36:50 CEST] <momomo> i programmatically alter this now on the fly and it appears to be working .. replacing 11 with 10
[22:36:55 CEST] <momomo> no lag
[22:37:01 CEST] <momomo> it appears as if its a bug in ffmpeg
[22:37:05 CEST] <momomo> output of playlist file
[22:37:46 CEST] <momomo> i'd prefer if I didn't have to read the text and replace it .. althouhg it works, it is potentially slower than my otherwise super optimized code :P
[22:38:06 CEST] <momomo> the targetduration must be the same as hls_time
[22:39:06 CEST] <momomo> yes, lag gone
[22:39:38 CEST] <momomo> i will post a bug report tomorrow
[23:13:06 CEST] <momomo> by manipulating ext_targetduration and even putting it at 1 i can force hls.js to load playlists every second
[23:13:19 CEST] <momomo> there should be such an option to manipulate this using ffmpeg
[23:14:47 CEST] <kepstin> I guess it must be automatically generating the targetduration by rounding up the length of the first segment. I think passing through the value of the -hls_time parameter untouched might be better.
[23:15:15 CEST] <kepstin> since it's the *target* duration not the arbitrarily guessed from first segment duration :)
[23:22:50 CEST] <kepstin> hmm, nope, the behaviour is correct: https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3.3.1
[23:23:16 CEST] <kepstin> hmm. close to being correct
[23:23:41 CEST] <kepstin> the lengths should be rounded to the nearest integer, not done with a ceiling function
[23:23:57 CEST] <kepstin> so in this case, it should be 10 not 11.
[23:24:08 CEST] <kepstin> but 11 is still acceptable.
[23:37:55 CEST] <kepstin> momomo: if you feel like building your own ffmpeg, you could give https://www.kepstin.ca/dump/0001-hlsenc-Round-segment-lengths-when-calculating-EXT-X-.patch a try
[23:38:07 CEST] <kepstin> I think that'll make it slightly more spec compliant
[23:39:27 CEST] Action: kepstin should doublecheck that he has the right ffmpeg rev checked out there, that From date in 2001 is a bit odd.
[23:40:23 CEST] <kepstin> huh, dunno what's up with that. patch is fine
[00:00:00 CEST] --- Tue Apr  5 2016