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

[burek]

[00:18:34 CET] <icheyne> hi guys. I can't get MP4 files to play on my TV from 2010. It's one of the old xvid/avi playing TVs. The audio stutters a lot. Do you know of any compatibility settings I can try?
[00:21:45 CET] <pzich> icheyne: if it's H.264 compatible and you're talking about trying different profiles, you can try: https://trac.ffmpeg.org/wiki/Encode/H.264#iOS
[00:21:47 CET] <paule32> thx
[00:21:53 CET] <paule32> it works
[00:21:58 CET] <icheyne> hmm
[00:22:02 CET] <paule32> great project
[00:22:36 CET] <paule32> but the encoder is so slooowww
[00:22:40 CET] <icheyne> pzich: OK thank that's worth a try
[00:22:59 CET] <paule32> i have lattency > 5 seconds
[00:23:40 CET] <furq> paule32: are you using rtmp or hls
[00:23:47 CET] <paule32> rtmp
[00:24:47 CET] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#buflen
[00:24:54 CET] <furq> i guess you could try that but it can be overridden by the client
[00:25:13 CET] <furq> hls is much worse for latency fwiw
[00:27:39 CET] <paule32> thx
[00:28:16 CET] <furq> vlc or whatever player you're using should have a configurable buffer size
[00:37:53 CET] <icheyne> pzich that didn't work - thanks though. I'll keep trying.
[00:38:59 CET] <paule32> furq: what are the vlc screen options for a screen rect?
[00:39:23 CET] <furq> idk i only use vlc for testing streams
[00:59:08 CET] <paule32> ah i have done it
[00:59:18 CET] <paule32> -s is for size
[01:01:05 CET] <paule32> and -i :0.0,sx,sy  is for screen 0 with sub pixel (start + offset) sx = size x, and sy = size y, so you can hidde things, if you want
[01:01:09 CET] <paule32> cewl
[01:20:50 CET] <TD-Linux> cluelessperson, also note you can set various -speed options to make the encoder go faster.
[01:21:11 CET] <furq> can you set those through ffserver though
[01:21:29 CET] <TD-Linux> no idea
[01:21:57 CET] <TD-Linux> but if you can't it's totally useless :)
[01:22:30 CET] <furq> i don't think that's the thing that makes ffserver useless
[01:22:32 CET] <cluelessperson> TD-Linux, 1.  it seems to use a single thread by default.
[01:22:38 CET] <furq> yes it does
[01:23:09 CET] <TD-Linux> furq, well... :)
[01:23:12 CET] <cluelessperson> 2.  4 threads on a 3ghz xeon isn't enough to power webm streaming?  wtf
[01:23:24 CET] <furq> it's enough to power webm streaming if you use vp8
[01:23:36 CET] <TD-Linux> and vp9 if you set proper speed options (barely)
[01:23:47 CET] <cluelessperson> furq, ah, maybe this is using vp9
[01:23:48 CET] <furq> last time i tried i got about 5fps on an overclocked i7 at 720p
[01:23:52 CET] Action: cluelessperson checks debugging
[01:23:59 CET] <furq> granted i didn't mess around with speed settings
[01:24:10 CET] <furq> and the multithreading didn't seem to be doing anything
[01:24:21 CET] <TD-Linux> with vp8 I can pretty easy get few hundred fps on my laptop
[01:24:27 CET] <furq> yeah vp8 is much faster
[01:24:48 CET] <TD-Linux> hangouts is trialing vp9... so it's realtime on some systems at least
[01:24:48 CET] <furq> still not as fast as x264 though ;_;
[01:25:40 CET] <kepstin> I suspect that if you tune vp9 to be as fast as vp8, you probably lose most of the efficiency improvements...
[01:25:56 CET] <cluelessperson> how to choose between vp8 and vp9?
[01:26:05 CET] <furq> -c:v libvpx
[01:26:10 CET] <furq> in ffserver i have no idea
[01:26:16 CET] <TD-Linux> kepstin, maybe, but vp9 has some features that are disproportionately good
[01:26:26 CET] <TD-Linux> e.g. not being limited to 4x4 transforms
[01:26:52 CET] <kepstin> right, but then the encoder has to spend more time deciding which type of transform to use :)
[01:27:22 CET] <kepstin> (but with good heuristics, i suppose it could still provide some improvements at the same speed)
[01:27:27 CET] <TD-Linux> yes, but the gains are worth the time spent, especially on higher resolutions
[01:27:35 CET] <cluelessperson> I'm doing this.   ffmpeg -i avengers.mp4 -codec:v libvpx -threads 8 test1.webm
[01:27:41 CET] <cluelessperson> and can barely keep up
[01:28:17 CET] <cluelessperson> it IS vp8
[01:28:18 CET] <cluelessperson> wtf
[01:28:30 CET] <kepstin> sure, but if you're doing realtime stuff there is a maximum amount of time you have per frame :)
[01:28:37 CET] <TD-Linux> cluelessperson, specify a speed
[01:28:41 CET] <cluelessperson> 5 FPS
[01:28:56 CET] <cluelessperson> straight up conversion it's outputting 5FPS
[01:29:01 CET] <cluelessperson> that's soo bad
[01:29:01 CET] <furq> which ffmpeg/libvpx version
[01:29:03 CET] <cluelessperson>   Stream #0:0 -> #0:0 (h264 (native) -> vp8 (libvpx))
[01:29:03 CET] <cluelessperson>   Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis))
[01:29:14 CET] <TD-Linux> yeah even with defaults 5FPS doesn't make much sense though
[01:29:34 CET] <cluelessperson> furq,
[01:29:34 CET] <cluelessperson> ffmpeg version 2.4.3-1ubuntu1~trusty6 Copyright (c) 2000-2014 the FFmpeg developers
[01:29:34 CET] <cluelessperson>   built on Nov 22 2014 17:07:19
[01:29:41 CET] <furq> yeah that's pretty old
[01:29:44 CET] <TD-Linux> no your libvpx
[01:29:55 CET] <furq> if your libvpx is that old then i'm not surprised it's slow
[01:30:01 CET] <cluelessperson> furq, http://hastebin.com/coseporiwo.pas
[01:30:04 CET] <furq> although maybe a bit surprised it's that slow
[01:30:23 CET] <TD-Linux> ehh I'm still a bit surprised. but cluelessperson, try specifying -speed 2
[01:30:27 CET] <TD-Linux> higher numbers = faster
[01:30:52 CET] <cluelessperson> TD-Linux, the quality is already terrible.
[01:31:01 CET] <furq> yeah because you're not specifying a bitrate or crf
[01:31:12 CET] <cluelessperson> I'll try those options out.  bbs
[01:31:15 CET] <cluelessperson> Thank you
[01:31:23 CET] <cluelessperson> friend is bothering me so I might disappear shortly
[01:31:42 CET] Action: TD-Linux notes to set Daala's default quality to crf 5 so that people are amazed by the quality
[01:46:17 CET] <xintox_> anyone familiar with neulion streams?
[01:46:40 CET] <xintox_> they key only downloads after about 5 attemps
[02:31:14 CET] <Guiri> I have a weird issue.  I wrote a python script that streams movies using the -concat filter.  It works fine on my laptop, ffmpeg installed with Homebrew, but fails on my server, also installed via Homebrew: http://fpaste.org/300445/05658314/
[02:33:32 CET] <Guiri> Perhaps my scaling function isn't robust enough against weird resolutions? http://fpaste.org/300446/45005677/
[02:35:35 CET] <Guiri> It's similar to the last comment here: http://stackoverflow.com/questions/19425674/ffmpeg-concat-and-scale-simultaneously
[04:03:38 CET] <cluelessperson> So what's a well support stream format that I should do?
[04:27:51 CET] <cluelessperson> furq, I was specificying a bitrate in ffserver however
[04:34:19 CET] <cluelessperson> How does youtube handle streaming so well?
[04:34:32 CET] <cluelessperson> do they just pretranscode it to a streamable format?
[05:11:25 CET] <kepstin> all the youtube content (except live stuff) is batch transcoded to multiple formats that are ready for streaming, yeah. Youtube servers are just glorified fileservers.
[05:12:19 CET] <kepstin> you upload a video, they start transcoding on multiple machines to maybe 6-8 different audio/video formats depending on video resolution
[05:13:38 CET] <kepstin> they even go back and re-encode old videos into newer formats
[05:22:14 CET] <Guiri> Back, laptop battery died.  Any takers on my SAR issue with scale above?
[07:01:25 CET] <xintox_> can anyone play this url? http://content-ausc1.uplynk.com/channel/439e26ab1ca449139fd9d73d1809a562/i.m3u8
[07:04:04 CET] <pinPoint> play?
[07:04:46 CET] <xintox_> stream it with ffmpeg
[07:06:33 CET] <paule32_> good morning
[07:06:36 CET] <pinPoint> erm. I have no idea how
[07:07:19 CET] <paule32_> can i stream a picture in picture? e.g. in corner a webcam, or view and on rest the desktop?
[10:18:55 CET] <xintox_> does anyone know how to pass my own key file to an encrypted stream?
[10:19:05 CET] <xintox_> such that ffmpeg decrypts it in the output?
[10:44:27 CET] <khali> paule32_: I think the overlay filter can do that
[10:44:45 CET] <khali> there are examples in the ffmpeg-filters man page
[10:54:24 CET] <tobylane> I'm changing the location of the ffmpeg libs in a program, and afterwards I get this error dyld: lazy symbol binding failed: Symbol not found: _swr_free
[10:54:31 CET] <tobylane> Expected in libavresample.2.1.0.dylib
[10:55:24 CET] <tobylane> avresample is depending on another dylib that is in the same folder, and where it is looking for (/usr/local/lib)
[11:23:13 CET] <pkeuter> when i have a h264 file which looks fine, and then convert it to uncompressed avi, the video starts jumping all up and down (on tv, not on my computer), so it must have something to do with interlacing, but anyone has an idea on how to fix this?
[12:30:45 CET] <pkeuter> anyone?
[12:31:13 CET] <Fyr> K!
[12:46:54 CET] <khali> pkeuter: we can't help you without more details, starting with the exact command line and the exact output from ffmpeg
[12:47:05 CET] <khali> all that should go to pastebin and you post the link here
[13:47:38 CET] <Nosomy> can someone explain to me why the decoder flac to wav by ffmpeg isn't correct?
[13:48:41 CET] <dv_> define "isn't correct"
[13:48:53 CET] <Nosomy> no same stream.
[13:49:22 CET] <dv_> how exactly? difference in the sample values? length difference? dropped samples? gaps?
[13:49:33 CET] <Nosomy> difference in the sample values.
[13:49:53 CET] <dv_> and you are 100% sure you decode to the exact same sample format?
[13:50:12 CET] <Nosomy> same flac source
[13:50:21 CET] <Nosomy> very diffs wavs outs
[13:50:39 CET] <dv_> I mean, if the flac file contains 24-bit samples, but ffmpeg's wav output uses 16 bit, it will of course be different
[13:50:56 CET] <Nosomy> flac is 16bits.
[13:51:12 CET] <Nosomy> Lav Filters, OpenCodec from Xiph, and Cue Tools, generates correct wavs.
[13:51:33 CET] <dv_> hm, may be a bug indeed then.
[13:55:29 CET] <furq> how are you comparing them
[13:56:34 CET] <Nosomy> Look top the hexadecimal stream in wav.
[13:56:51 CET] <Nosomy> with hexaeditor.
[14:01:52 CET] <Nosomy> is strange, if ffmpeg is based on lavfilters, why the differece?
[14:03:11 CET] <fritsch> lol
[15:34:05 CET] <paule32_> can i customize the string/stream url
[15:34:24 CET] <paule32_> actually i have the application section
[15:34:34 CET] <paule32_> maybe "live"
[15:35:10 CET] <paule32_> then the entry/publish point is:  rtmp://server.tld/live/mystream
[15:35:36 CET] <paule32_> but i can't see "mystream" in config file
[15:42:30 CET] <DHE> while I don't have an RTMP server myself, "live" is considered the 'application' name so you might go looking in that direction
[15:43:51 CET] <furq> paule32_: you can publish to anything under rtmp://abc.de/live/
[15:44:08 CET] <furq> if you want to restrict then see nginx-rtmp on_publish
[15:44:50 CET] <furq> assuming your application name is live ofc
[16:49:55 CET] <Nosomy> updated
[16:49:59 CET] <Nosomy> problem solved
[16:52:48 CET] <paule32_> DHE: do you would like a account?
[16:53:13 CET] <DHE> no no...
[16:57:35 CET] <paule32_> so, i can subsi sub application names/streams?
[16:59:22 CET] <paule32_> i don't follow the last session in detail, so i ask it again:
[16:59:59 CET] <paule32_> how can i make the stream faster, but with minimal quality lost
[17:00:28 CET] <furq> pastebin your current ffmpeg command
[17:01:20 CET] <Nosomy> crf?
[17:02:15 CET] <paule32> http://fpaste.org/300661/50108891/
[17:02:46 CET] <furq> use a faster preset
[17:03:01 CET] <furq> i'm surprised you're having speed issues at 640x480 10fps though
[17:03:26 CET] <paule32> what is better? 10, 5, 2?
[17:03:42 CET] <furq> ?
[17:03:49 CET] <paule32> fps
[17:03:59 CET] <furq> better for what
[17:04:08 CET] <paule32> -r 10, -r 5 -r 2
[17:05:01 CET] <furq> i don't know what you mean by "better"
[17:05:09 CET] <furq> lower framerates will encode faster but look worse
[17:05:53 CET] <Nosomy> bitrate value, lol
[17:06:07 CET] <BigD> Figured out how to merge files from my camcorder into a single file - now would like to optimize the file for youtube.  ffprobe result of 1 of 3 files http://pastebin.com/Y2ewjDiU
[17:07:39 CET] <Nosomy> make list.txt file 'file01.mp4' in another line: file '02.mp4"
[17:07:45 CET] <BigD> I record my teams soccer games - post them for players to review. Just need to optimize - since it take too long to do.
[17:07:49 CET] <Nosomy> for echa file
[17:07:54 CET] <Nosomy> e to end
[17:07:59 CET] <furq> BigD: i take it you have limited upload bandwidth
[17:08:05 CET] <furq> otherwise there's no reason to optimise for youtube
[17:08:08 CET] <Nosomy> ffmpeg -f concat -i list.txt.
[17:08:13 CET] <Nosomy> -c copy
[17:08:20 CET] <BigD> yes, very limited unfortunately.
[17:08:37 CET] <furq> i would probably just reencode to 720p
[17:08:48 CET] <furq> there's not much difference between 720p and 1080p on youtube
[17:09:07 CET] <paule32> BigD: under Windows?
[17:09:24 CET] <BigD> yes under windows
[17:09:38 CET] <paule32> ask google about "manycam"
[17:09:50 CET] <BigD> code I use: ffmpeg -f concat -i h:\mylist.txt -c copy final.mp4
[17:10:08 CET] <furq> i like how two people have answered the question you said you'd solved
[17:11:02 CET] <furq> anyway i would probably just downscale to 720p at default settings and go from there
[17:11:24 CET] <BigD> furq: default setup on camera?
[17:11:30 CET] <furq> default ffmpeg x264 settings
[17:11:50 CET] <furq> if by optimise you mean reencoding rather than recording it differently
[17:12:06 CET] <BigD> furq: can you get sample ffmpeg please
[17:12:33 CET] <furq> ffmpeg -i source.mp4 -c:v libx264 -vf scale=1280:720 -c:a copy dest.mp4
[17:13:25 CET] <furq> the defaults are -preset medium and -crf 23 which is a good place to start, tweak those as needed
[17:13:33 CET] <BigD> furq: I still need to concat 3 files
[17:14:28 CET] <furq> ffmpeg -f concat -i h:\mylist.txt -c:v libx264 -vf scale=1280:720 -c:a copy dest.mp4
[17:15:09 CET] <BigD> furq: thanks much appreciated.
[17:15:48 CET] <Nosomy> diffs codecs need reencode to concat
[17:16:00 CET] <Nosomy> same codecs you can use copy
[17:16:10 CET] <furq> if they're all from the same camcorder i imagine they're all the same codec and size
[17:16:16 CET] <furq> plus he's reencoding them anyway
[17:16:20 CET] <shincodex> how does this damn library handle putting images from a camera onto a sdl surface and something corrupts
[17:16:27 CET] <Nosomy> i prefer copy
[17:16:38 CET] <BigD> furq; yes all the same codex see http://pastebin.com/Y2ewjDiU
[17:16:39 CET] <furq> good for you
[17:17:14 CET] <shincodex> say I have rtsp stream and if it ever flakes out for a microsecond and come back can pixel buffer for that perticular frame be partial Or no frame at all reject dropped broken
[17:18:33 CET] <Nosomy> camcorder?
[17:18:34 CET] <Nosomy> lol
[17:20:25 CET] <Nosomy> for windows, better capture tool is Fraps (catch all), after is dxtory with utvideo, and for last ffmpeg with screen capturer recorder
[17:21:01 CET] <furq> who are you talking to
[17:21:38 CET] <Nosomy> just comment
[17:24:21 CET] <furq> paule32: fyi -x264opts keyint and -g are the same option, so you probably don't want them to be set to different values
[17:26:29 CET] <furq> there's also no reason to change it from the default unless you care about seeking
[17:28:01 CET] <BtbN> OBS is also decent for capturing on Windows
[17:28:19 CET] <BtbN> (And also on linux/osx, with the multiplatform version)
[17:28:24 CET] <Nosomy> BtbN, only  for lossy
[17:28:31 CET] <BtbN> why?
[17:28:33 CET] <furq> doesn't everyone use shadowplay now
[17:28:44 CET] <furq> or whatever the amd knockoff is called
[17:28:51 CET] <Nosomy> x264 lossless in OBS take much cpu yet with ultrafast
[17:28:52 CET] <BtbN> Why would a lossless recording from OBS be any worse than one from fraps/dxtory?
[17:29:04 CET] <BtbN> Use hardware encoding then.
[17:29:20 CET] <Nosomy> Hardware encoding isn't lossless
[17:29:29 CET] <BtbN> yes it is, if you set it into lossless mode.
[17:29:33 CET] <BtbN> And x264 lossless ultrafast takes barely any CPU.
[17:29:48 CET] <BtbN> You trade filesize against CPU usage.
[17:30:09 CET] <furq> i like how people are obsessed with having a lossless step to preserve quality before uploading it to youtube
[17:30:14 CET] <furq> where quality goes to die
[17:30:39 CET] <BtbN> It's usualy more about post-processing it without quality loss
[17:30:55 CET] <furq> it's still going to end up being horribly compressed though
[17:30:58 CET] <Nosomy> because this lossless if possible upload is recommend
[17:33:15 CET] <pepee> I'm running this command to make a video from an image and an audio file, how could I improve the quality of the final video? it looks bad at the start of the output video:  ffmpeg -y -loop 1 -r 2/3 -i /tmp/in.jpeg -i /tmp/in.ogg -c:v libvpx -c:a copy -shortest -tune stillimage -f webm /tmp/out.webm
[17:33:25 CET] <Nosomy> BtbN isn't, CQP 0 H.264 Quicksync isn't lossless, although it is much closer to a lossless than x264 crf 1
[17:33:48 CET] <BtbN> No idea about QSV, i don't care about that.
[17:34:04 CET] <BtbN> But i'd be surprised if it doesn't have a lossless setting.
[17:35:09 CET] <shincodex> is there a way to dictate ffplay to receieve frames at a rate so if i say 15fps I get 15 frames in a second.
[17:35:46 CET] <BigD> furq: got [mp4 @ 04c32da0] Codec for stream 1 does not use global headers but container format requires global headers (ffmpeg -f concat -i h:\mylist.txt -c:v libx264 -vf scale=1280:720 -c:a copy dest.mp4)
[17:36:28 CET] <Nosomy> BigD
[17:37:26 CET] <Nosomy> try ffmpeg -f concat -i mylist -c copy  -bsf:v h264_mp4toannexb out.mp4
[17:38:37 CET] <BigD> furq: still processing - not sure if that error will affect output file
[17:39:19 CET] <BigD> Nosomy: thanks, I will give that a try afterwards
[17:39:33 CET] <Nosomy> BigD how is your list format?
[17:41:39 CET] <BigD> Nosomy: 3 mp4 files ( one is 4gb, other is 2.6gb and the last one is 600mb)
[17:43:46 CET] <Nosomy> BigD
[17:43:51 CET] <Nosomy> how i use: http://pastebin.com/Bxci4ALA
[17:43:55 CET] <Nosomy> and works
[17:45:00 CET] <Nosomy> the files need stay the same folder of ffmpeg.
[17:45:48 CET] <Nosomy> otherwise you must pass the fullpath
[17:46:42 CET] <BigD> Nosomy: yes, that is what I was using but now trying to reduce video from 1080p to 720p - for uploading to youtube since I have limited upload bandwidth
[17:47:04 CET] <Nosomy> in this case need reencode
[17:47:13 CET] <furq> BigD: you can usually ignore that error
[17:47:29 CET] <furq> and yeah it'll take a while
[17:47:51 CET] <furq> the result should be a lot less than 23mbit though
[17:48:45 CET] <BigD> furq: thanks I will ignore error message, just waiting for it to finish. Anything I can do to speedup.
[17:48:52 CET] <furq> not while it's running
[17:49:14 CET] <furq> you can use -preset fast (or faster/veryfast/ultrafast) but those will make the output file bigger
[17:50:19 CET] <furq> if you're going to do a speed vs size comparison you might want to just use the 600mb input file to test with
[17:50:29 CET] <furq> speed vs size vs quality, rather
[17:50:58 CET] <fritsch> durandal_1707: JEEB thanks again for your help yesterday - it's now finished (with sws_scale jpeg range): https://github.com/xbmc/xbmc/pull/8583#issuecomment-164490025
[17:51:36 CET] <BigD> furq: okay - guess I can't have my cake and eat it. (fast and small file). Agree I will use a small file for testing (speed, size, quality)
[17:51:54 CET] <furq> yeah the settings you use will be a compromise between all three
[17:53:01 CET] <Nosomy> fast and small file = bad quality
[17:53:21 CET] <BigD> furq: will it automatically use multi-threading on a 64 bit processor.
[17:53:25 CET] <pepee> I'm making a video from an image + an audio file, how could I improve the quality of the final video? the 1st frame looks very pixelated, then quality improves with the next frames. cmd is: ffmpeg -y -loop 1 -r 2/3 -i /tmp/in.jpeg -i /tmp/in.ogg -c:v libvpx -c:a copy -shortest -tune stillimage -f webm /tmp/out.webm
[17:53:26 CET] <furq> yes
[17:54:11 CET] <pepee> would I have to make 2 passes?
[17:54:30 CET] <Nosomy> vpx and quality is more hard to hit the both
[17:55:16 CET] <BigD> Nosomy: understand - hence will play around with a small file to see what we can live with - just for player reviews via youtube.
[17:56:19 CET] <Nosomy> pepee, vpx and 2pass is almost necessary
[17:57:35 CET] <Nosomy> small file with good quality requeires slower presets.
[17:57:43 CET] <Nosomy> BigD.
[17:58:19 CET] <Nosomy> *requires.
[17:58:52 CET] <pepee> Nosomy, ah, thanks
[18:01:09 CET] <pepee> is there a way to tell ffmpeg to make two passes by itself, automatically?
[18:01:40 CET] <Nosomy> nop, you need made a script for this
[18:02:02 CET] <Nosomy> or rentered with command
[18:02:40 CET] <Nosomy> *reenter
[18:04:02 CET] <Nosomy> ffmpeg [other params] -an -pass 1 nul
[18:04:02 CET] <Nosomy> ffmpeg [other same before params ] -pass 2 out.file
[18:07:32 CET] <pepee> well, that's sad. libx264 "just works", but vpx doesn't look as good :(
[18:07:56 CET] <Nosomy> vpx default is bad
[18:08:14 CET] <furq> pepee: libvpx uses a really low bitrate by default
[18:08:31 CET] <pepee> what could be an option/workaround?
[18:08:47 CET] <furq> -b:v 0 -crf 20
[18:09:02 CET] <pepee> hmm, thanks, lemme try
[18:09:16 CET] <furq> that crf value might be totally wrong, i know it's not the same for vpx as it is for x264
[18:09:27 CET] <furq> tune it as you see fit, lower numbers = higher quality
[18:09:36 CET] <Nosomy> and inst'.
[18:09:49 CET] <Nosomy> crf of x264 is 1 to 51
[18:09:58 CET] <Nosomy> vpx is 4 to 64
[18:10:22 CET] <Nosomy> the ranges
[18:10:29 CET] <pepee> yep, that looks MUCH better
[18:10:31 CET] <furq> also don't use -crf with 2-pass
[18:11:13 CET] <Nosomy> crf not work with 2pass.
[18:11:19 CET] <furq> right
[18:11:51 CET] <Nosomy> only for make 1pass of 2passes encode work,
[18:13:18 CET] <Nosomy> though who use crf isn't concerned about filesize
[18:14:47 CET] <Nosomy> crf of x264 is float, of vpx is integer, correct furq?
[18:14:59 CET] <pepee> thank you very much, people
[18:27:08 CET] <awidgery> Hi - can anyone help me with a problem with choppy audio RTP streaming over wifi?
[18:28:50 CET] <BtbN> Don't use Wifi.
[18:36:00 CET] <waressearcher2> GPRS ?
[18:36:48 CET] <DHE> wifi sucks. it's unreliable and inconsistent. it might be good for HTTP based streaming like youtube, HLS or .mp4 streaming but not realtime
[18:38:08 CET] <BtbN> A good wifi link and a TCP based protocol can work out ok
[18:40:49 CET] <Mavrik> DHE, RIGHT.
[18:41:02 CET] <Mavrik> except that it works just fine in several environments where high-performance udp streaming is used :P
[18:41:23 CET] <Mavrik> But yeah, in bad envrionments, TCP helps.
[18:43:10 CET] <DHE> but I mean in general. 2.4 GHz wifi is subject to interference from other 2.4 GHz devices, including but not limited to wireless phones, microwave ovens, your neighbour's wifi, and your other neighbour's wifi.
[18:43:18 CET] <DHE> it's not reliable at all
[18:44:02 CET] <Mavrik> Indeed. The person talking about wifi didn't say he's on 2.4GHz though.
[18:44:37 CET] <Mavrik> awidgery, can you use anything else except RTP?
[18:46:54 CET] <waressearcher2> aber warum nicht 5GHz oder 60GHz ?
[18:53:38 CET] <awidgery> Yes, I can use any protocol that will give a reasonably low latency. I'm going from Raspberry Pi - Wifi - iOS app/Mac. The weird thing that is I go RPi - wifi - ethernet - Mac it works perfectly
[18:53:56 CET] <awidgery> I'm on 2.4GHz, yes
[18:57:15 CET] <Mavrik> Hmm.
[18:57:51 CET] <Mavrik> awidgery, try using MPEG2-TS over UDP or MPEG2-TS over TCP
[18:58:03 CET] <Mavrik> That usually gave significantly better results.
[18:58:36 CET] <awidgery> OK so my current command is: ffmpeg -f alsa -i plughw:1,0 -acodec libmp3lame -ab 128k -ac 1 -ar 44100  -f rtp rtp://234.5.5.5:1234
[18:58:46 CET] <mifritscher> hi
[18:58:55 CET] <awidgery> What would you recommend trying?
[18:59:18 CET] <DHE> mpegts over udp needs a throttler
[18:59:33 CET] <mifritscher> why does ffmpeg ignore filters given with vf if streaming to ffserver? if I use it e.g. recording to file or stream it raw via udp it works file
[18:59:47 CET] <shincodex> you ever hit a turtle with your car before]
[19:00:40 CET] <Mavrik> awidgery, -f mpegts udp://234.5.5.5:1234
[19:04:02 CET] <awidgery> Mavrik, that command runs fine on the Pi, but VLC on the Mac refuses to connect. Can you still use the multicast IP with udp:// ?
[19:04:21 CET] <Mavrik> yes, certanly, that's how IPTV works :)
[19:04:58 CET] <awidgery> Hmm weird - VLC refuses to load the stream at all when I point it to udp://234.5.5.5:1234
[19:06:30 CET] <c_14> awidgery: try adding a ?listen to the end when playing
[19:08:17 CET] <awidgery> Mavrik, c:14: OK VLC works if I point it to udp://@234.5.5.5:1234
[19:08:29 CET] <awidgery> The choppiness is (mostly) gone - yay!
[19:08:31 CET] <Mavrik> yp
[19:08:38 CET] <Mavrik> try it with TCP as well
[19:08:49 CET] <Mavrik> it might be more reliable but it could also be significantly worse :)
[19:08:57 CET] <Mavrik> not sure if you can multicast tcp tho
[19:09:02 CET] <Mavrik> you'll have to unicast it
[19:09:17 CET] <awidgery> Mavrik: "tcp://234.5.5.5:1234: Network is unreachable"
[19:09:31 CET] <Mavrik> yeah, do tcp://<machine-ip>:1234
[19:09:38 CET] <awidgery> I've not done unicast - what command do I use for that?
[19:09:39 CET] <Mavrik> and on VLC tcp://127.0.0.1:1234
[19:11:10 CET] <awidgery> "Connection to tcp://191.168.1.201:1234 failed: Connection refused
[19:11:10 CET] <awidgery> tcp://191.168.1.201:1234: Connection refused"
[19:11:43 CET] <awidgery> "Connection to tcp://192.168.1.201:1234 failed: Connection refused
[19:11:43 CET] <awidgery> tcp://192.168.1.201:1234: Connection refused" - 192.168.1.201 is the IP of the Macbook (receiving device)
[19:12:01 CET] <c_14> you need to start the player first
[19:12:03 CET] <c_14> then the streamer
[19:12:07 CET] <c_14> tcp is connection oriented
[19:12:09 CET] <Mavrik> Probably need something listening on that port first :)
[19:12:11 CET] <c_14> you always need the "server" first
[19:13:37 CET] <awidgery> Hmm - that's not going to work anyway for my application - it's a baby monitor, so I want the Pi to be transmitting constantly, and the mobile app to be able to pick up the audio...
[19:13:56 CET] <Mavrik> Well, then you need a better wifi :)
[19:14:37 CET] <c_14> Or make it more complex
[19:15:27 CET] <awidgery> Is there any way to get ffmpeg/VLC to buffer at either end?
[19:15:35 CET] <c_14> By turning the "monitor" into a tcp server that starts streaming whenever clients connect
[19:15:39 CET] <c_14> awidgery: it should do that automatically
[19:16:31 CET] <awidgery> I originally tried using icecast/darkice (using TCP I think) but the latency was 15s+. And a baby can do a lot in 15 seconds :)
[19:24:28 CET] <awidgery> Mavrik c_14 thanks for your help
[19:54:55 CET] <cbsrobot_> wyatt8740: you could also try the http://ffmpeg.org/ffmpeg-filters.html#hqx filter
[19:55:16 CET] <wyatt8740> cbsrobot_: I was the one who requested that filter
[19:55:21 CET] <wyatt8740> but thanks
[19:55:36 CET] <wyatt8740> It's not what I was looking for
[19:56:09 CET] <wyatt8740> ( ee https://trac.ffmpeg.org/ticket/3404 )
[19:56:11 CET] <wyatt8740> *see
[19:56:21 CET] <cbsrobot_> I thought it could help for pixel art - instead of swscale
[19:56:31 CET] <wyatt8740> it only works on lossless video anyway
[19:56:54 CET] <wyatt8740> and interference-ridden analog S-video capture is not exactly ideal
[19:58:52 CET] <wyatt8740> That filter I requested mainly because it wasn't in ffmpeg yet and sometimes it does look cool. But for pixel art sometimes I want it to stay pixelly.
[20:00:00 CET] <llogan> scale=w:h:flags=neighbor
[20:02:27 CET] <hid> hi
[20:02:50 CET] <hid> how can I convert spc music files to wav?
[20:03:32 CET] <furq> with foobar2000
[20:03:38 CET] <furq> or preferably not at all
[20:07:17 CET] <hid> oh I found out deadbeef open them :o
[20:07:25 CET] <hid> thx furq
[20:07:54 CET] <furq> yeah anything good should open them
[20:08:09 CET] <furq> there's no reason to convert them unless you're a fan of using a thousand times more space than you need to
[21:45:53 CET] <MrGlass> If I use options like '-vcodec copy', does that also copy thinks like presets & such? My assumption is thats a transcoder setting & not a codec setting so it wouldn't, but figured I could ask
[21:46:34 CET] <BtbN> It's -c:v, and it can't copy what's not there.
[21:46:36 CET] <TD-Linux> no, it copies the video bitstream exactly, there is no transcoding.
[21:47:35 CET] <TD-Linux> "presets" are an encoder specific setting, they don't have any meaning in a video file
[21:52:42 CET] <MrGlass> hrm, so if I'm trying to use vcodec copy with the -ss command (to segment some video), will it not do a transcode to deal with a keyframe thats before the start time
[21:53:40 CET] <DHE> depends where on the commandline you put the -ss option. Before or after the input file matters
[21:54:12 CET] <MrGlass> after, as part of the output
[21:54:41 CET] <MrGlass> I'm trying to take a file and cut it into 1 minute segments
[22:56:45 CET] <DHE> MrGlass: there is a 'segment' output format you might be able to use.
[23:15:40 CET] <satt> Hey guys, still having an issue with padding - my command is generating negative values sometimes.  Pretty new to this still, any help is appreciated!
[23:16:09 CET] <satt> Here's my log/some other details for failed files https://gist.github.com/StoryStar/d720f9a9727a93b20a43
[23:17:19 CET] <satt> I'm concatenating a bunch of different files together.  My current filter text looks like this:
[23:17:21 CET] <satt> [$count:v]scale=if(gt(ih\,iw)\,-2\,$VID_WIDTH):if(gt(ih\,iw)\,$VID_HEIGHT\,-2),pad=$VID_WIDTH:$VID_HEIGHT:(ow-iw)/2:(oh-ih)/2,setsar=sar=1/1[v$count];
[23:17:48 CET] <satt> also tried this, but it seemed to cause more issues than it fixed
[23:17:49 CET] <satt> [$count:v]scale=if(gt(iw\,ih)\,$VID_WIDTH\,$VID_HEIGHT):if(gt(iw\,ih)\,$VID_WIDTH\,$VID_HEIGHT),pad=$VID_WIDTH:$VID_HEIGHT:(ow-iw)/2:(oh-ih)/2,setsar=sar=1/1[v$count];
[23:23:48 CET] <xintox_> Unable to open key file
[23:24:00 CET] <satt> other info - the majority of my videos (if not all) are in portrait (cell phone videos mostly), $VID_HEIGHT and $VID_WIDTH are the smallest dimensions of all the inputs
[23:24:07 CET] <xintox_> anyone have a fix for this?
[23:43:27 CET] <llogan> xintox_: how to duplicate issue?
[23:47:38 CET] <xintox_> llogan: can i pm you?
[00:00:00 CET] --- Tue Dec 15 2015