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

burek burek021 at gmail.com
Tue Mar 29 02:05:01 CEST 2016


[00:13:23 CEST] <J_Darnley> What software gives those two messages about the files?
[00:13:31 CEST] <J_Darnley> stemid ^
[00:16:38 CEST] <stemid> ffprobe?
[00:16:57 CEST] <J_Darnley> No, the two from your first message
[00:17:07 CEST] <stemid> file(1)
[00:17:27 CEST] <stemid> I'll try a different id3 version
[00:17:32 CEST] <stemid> I found the option to set that
[00:17:46 CEST] <stemid> but it feels like a stretch
[00:20:27 CEST] <J_Darnley> Did I miss anything after my last message?
[00:21:08 CEST] <stemid> I said I used the file(1) utility to get that data. and also that I'm trying to set the id3 version to 2.3 to see if that'll make a difference.
[00:21:26 CEST] <J_Darnley> ah
[00:22:13 CEST] <stemid> apparently google music can stream to sonos directly, but it won't help if it can't discover the music first.
[00:26:03 CEST] <J_Darnley> ha!  results from my own library
[00:27:10 CEST] <stemid> wow changing the id3 version solved it!
[00:27:32 CEST] <stemid> so that might be good to know, the ffmpeg default makes songs unplayable in popular music apps.
[00:27:38 CEST] <J_Darnley> Ah.  I guess I'll stop looking for more difference
[00:28:20 CEST] <J_Darnley> They must be pretty poor if they can't handle v2.4
[00:28:32 CEST] <stemid> yes of course it's bad of them but still good to know, something fitting for an FAQ
[00:28:36 CEST] <stemid> imo
[00:28:45 CEST] <stemid> anyways, this is the command I used, from the manpage basically ffmpeg -i "$file" -id3v2_version 3 -f mp3 "`basename "$file" .wav`.mp3"
[00:29:18 CEST] <J_Darnley> FYI You probably want -c copy in there
[00:29:44 CEST] <stemid> thanks will check what that does
[00:30:01 CEST] <J_Darnley> Copies instead of encodes
[00:30:19 CEST] <J_Darnley> I thought you were starting with mp3 files though
[00:30:25 CEST] <stemid> I had both wav and mp3
[00:30:32 CEST] <stemid> so copy would be good if I went from mp3 to mp3 I assume
[00:30:40 CEST] <J_Darnley> Yes, definitely
[00:30:42 CEST] <stemid> but I decided to encode from wav to mp3
[00:31:57 CEST] <J_Darnley> Also: ${file%.wav}.mp3
[00:32:19 CEST] <stemid> yeah I normally prefer parameter expansion but I just wanted to get my song played quickly.
[00:32:30 CEST] <stemid> #bash nazis are in here :)
[00:32:35 CEST] <J_Darnley> huehuehue
[00:43:49 CEST] <stemid> found threads about the id3 version on google product forums. known issue for them at least.
[00:46:00 CEST] <J_Darnley> I'm glad you'reatisfied.
[00:46:11 CEST] <J_Darnley> Ew.  Who turned on overwrite?
[00:46:16 CEST] Action: J_Darnley hits insert
[07:42:30 CEST] <parrot1> I tried to link against ffmpeg libraries but I got error  undefined reference to symbol 'avfilter_graph_alloc@@LIBAVFILTER_6' . Any idea?
[08:54:08 CEST] <HiRo__> hello everyone, I use ffmpeg to restream a rtsp link to ffserver, my CLI is: "ffmpeg -rtsp_transport tcp -probesize 2147483647 -analyzeduration 2147483647 -loglevel 48 -i "rtsp://myurl" -rtsp_transport tcp -y -flags +global_header -c:v http://localhost:8090/feed.ffm". ffmpeg output a error  "Could not find codec parameters for stream 0 (Video: h264, 1 reference frame, none(left)): unspecified size", can anyone help me to fix it?
[09:10:04 CEST] <thebombzen> HiRo__: it looks like you're doing -c:v followed by a URL? -c:v is output video codec
[09:14:17 CEST] <HiRo__> sorry, full CLI is "ffmpeg -rtsp_transport tcp -probesize 2147483647 -analyzeduration 2147483647 -loglevel 48 -i "rtsp://myurl" -rtsp_transport tcp -y -flags +global_header -c:v copy http://localhost:8090/feed.ffm"
[11:54:11 CEST] <Guest16296> Heelo. Is this the place to get help with ffplay?
[11:56:32 CEST] <Guest16296> When I run "ffplay -report" the log seems to be printed to both the logfile and the screen. How can I have it print only to the file
[11:56:33 CEST] <Guest16296> ?
[12:03:22 CEST] <c_14> add -v quiet
[12:12:32 CEST] <Guest16296> c_14 Thank you. I had assumed that would affect the report file too. I should have tested it
[12:50:08 CEST] <hoodedfigure> Hey folks. Is there a way to add a selective brightness filter which keeps bright areas as they are and increases brightness of dark areas?
[13:13:30 CEST] <hoodedfigure> Is there some kind of a 'levels' function to adjust luma?
[13:17:06 CEST] <hoodedfigure> found it, thanks
[13:17:13 CEST] <hoodedfigure> https://ffmpeg.org/ffmpeg-filters.html#colorlevels
[13:17:15 CEST] <hoodedfigure> bye
[14:40:41 CEST] <jmack> thebombzen: I compiled everything as stated in the link llogan sent me, and the only thing that didn't go well was x265. The one thing I noticed right away was the 'audacity' is experiencing problems and has a tendency to crash after having a captured audio file from ffmpeg inported and played more than one.
[14:42:57 CEST] <jmack> thebombzen: May be a bug, but I suspect it might have something to do with 'avconv' not being removed from my system.
[14:47:45 CEST] <jmack> thebombzen: As I said, x265 was the only thing that didn't install as easy as the others. The PATH used might be the problem or maybe it's just me...whatever the case I had to physically move the program to the $HOME/bin, it seems fine with the exception that ffmpeg complains it can't use it! LOL
[15:06:04 CEST] <jmack> anyone: Got any ideas?
[15:20:57 CEST] <bencoh> jmack: ffmpeg needs libx265 (the library), not x265 (the tool)
[15:21:38 CEST] <bencoh> so you need to install the lib (and you might need to tell the build system to do so)
[15:22:44 CEST] <jmack> bencoh: sorry bout that...yes, I did install the library.
[15:24:10 CEST] <jmack> bencoh: I'm not an expert, "tell the build system to do so" ?
[15:24:49 CEST] <jmack> bencoh: Please explain...
[15:25:18 CEST] <J_Darnley> For example: when compiling x264 you need to explicitly enable a library otherwise you only get the command line encoder.
[15:25:27 CEST] <bencoh> if you can see libx265 in your lib folder then it should be fine
[15:25:59 CEST] <bencoh> if you installed to a non-standard folder you need to tell that to ffmpeg's configure as well
[15:26:50 CEST] <jmack> OK, how do I do that?
[15:27:59 CEST] <furq> --extra-cflags="-I/path/to/x265/include" --extra-ldflags="-L/path/to/x265/lib"
[15:28:06 CEST] <jmack> Yes, I installed to $HOME/bin...
[15:28:48 CEST] <jmack> furq: This will fix it?
[15:28:57 CEST] <furq> that depends on what it is
[15:29:15 CEST] <jmack> Or do I need to recompile the whole ffmpeg?
[15:30:47 CEST] <jmack> Do I need to recompile the ffmpeg with those options?
[15:31:25 CEST] <furq> well the fact that it compiled in the first place implies you didn't compile with --enable-libx265
[15:31:42 CEST] <furq> so you probably want to do that as well
[15:31:56 CEST] <jmack> OK, you might have something there
[15:34:33 CEST] <jmack> Hold on a minute. I'll check to see if I compiled with "--enable-libx265"
[15:36:52 CEST] <jmack> furq: Your right I didn't use --enable-libx265, damn it..
[15:37:34 CEST] <jmack> Like I said i'm not an expert...
[15:39:18 CEST] <jmack> So has anybody else ran into trouble with 'audacity' after installing ffmpeg?
[15:46:06 CEST] <jmack> Is there a conflict between ffmpeg and avconv that causes problems in 'audacity' ?
[15:46:19 CEST] <thebombzen> jmack: Audacity uses the libav in the repositories
[15:46:30 CEST] <thebombzen> put simply, libav sucks.
[15:46:41 CEST] <thebombzen> my best guess is that bug was fixed in ffmpeg eight months ago
[15:46:52 CEST] <thebombzen> and libav devs were too arrogant to pull it
[15:48:03 CEST] <jmack> OK, i agree with the "libav sucks" part
[15:48:49 CEST] <jmack> How do i get audacity to use ffmpeg lib?
[15:49:19 CEST] <jmack> Or can it be fixed at all?
[15:50:07 CEST] <c_14> jmack: if it uses the libraries you'll probably have to recompile, if it uses the ffmpeg binary you'll have to check if it has a config option for the path to it
[15:51:11 CEST] <jmack> Recompile Audacity?
[15:51:15 CEST] <c_14> yes
[15:51:30 CEST] <c_14> recompile it to link against FFmpeg's libraries
[15:52:06 CEST] <c_14> and if you compiled FFmpeg with shared libraries you'll probably have to make sure your RPATH is set correctly when linking and/or set LD_LIBRARY_PATH before running audacity
[15:54:09 CEST] <jmack> OK. i used the software manager to install Audacity and it has sh*t the bed the bed again...
[15:55:35 CEST] <mr_pinc> Hello I have a command line that i'd like to have some of the command line parameters explained - can anyone help?   -c:v libx264 -crf 25 -profile:v high -r 30
[15:55:49 CEST] <mr_pinc> Mainly I understawnd everything before '-profile'
[15:56:05 CEST] <mr_pinc> So really it's the -profile:v high -r 30 part
[15:56:58 CEST] <c_14> The profile option sets the H.264 profile to use, in this case high. -r 30 sets the output framerate (fps) to 30
[15:57:15 CEST] <__z0k__> hi, dont know if anyone can help with a probl i'm having transcoding an rtmp to rtmp stream
[15:57:29 CEST] <__z0k__> im'm using the cmd ffmpeg -re -i rtmp://184.72.239.149/vod -map 0:0 -map 1:1 -acodec copy -vcodec copy -f flv rtmp://localhost:1935/dash/test
[15:57:36 CEST] <mr_pinc> ok does that relate at all to the crf 25 command?  Like if I am specifying the quality with -crf 25 how does high profile fit in?
[15:57:45 CEST] <__z0k__> and getting the following error: Server error: Failed to play ; stream not found.                                                  
[15:57:48 CEST] <__z0k__> rtmp://184.72.239.149/vod: Operation not permitted
[15:57:50 CEST] <mr_pinc> c_14 is there a way to specify same source frame rate?
[15:58:02 CEST] <JEEB> don't override frame rate and input timestamps are used
[15:58:05 CEST] <c_14> just don't set the option, same is default
[15:58:21 CEST] <JEEB> profiles = features, levels = how much memory the decoder requires in modern video formats
[15:58:42 CEST] <JEEB> the x264 presets also limit features and high is the highest for 8bit 4:2:0 picture encoding
[15:58:54 CEST] <JEEB> so essentially -profile high is pretty much a no-op in many cases :P
[15:59:20 CEST] <JEEB> x264 by default selects the profile according to your preset, and generally you use profile to limit the features to a specific profile
[15:59:37 CEST] <JEEB> so f.ex. if your preset doesn't use 8x8dct, which is high profile specific, you will get main profile selected
[15:59:59 CEST] <JEEB> so generally you set the profile when you want something lower than high in all cases
[16:00:02 CEST] <JEEB> like baseline or main
[16:00:31 CEST] <c_14> And if you don't care, just don't set it.
[16:01:13 CEST] <JEEB> yes, x264 by default selects the profile required by your features enabled in the preset you're using
[16:02:06 CEST] <mr_pinc> c_14: Very helpful thank you
[16:03:33 CEST] <c_14> __z0k__: can you play the stream using a media player? It might be firewall/access restriction on the server side.
[16:09:29 CEST] <gnome1> JEEB: what about the level? so if I don't touch these settings, I won't get a bigger file or something like that?
[16:12:38 CEST] <bencoh> if you dont set level/profile, x264 will decide based on other encoding options, and/or preset
[16:16:25 CEST] <jmack> I noticed that when i import a captured audio file into Audacity it seems offset from the zero line, is that normal?
[16:17:12 CEST] <kepstin> that depends on hardware. Means you have a dc offset in the analog side
[16:24:57 CEST] <jmack> I thought that's what it was, but running 'normalize' with 'remove dc offset' doesn't get rid of it, thanks for your help kepstin :)
[16:26:00 CEST] <thebombzen> jmack: check in #audacity
[16:27:01 CEST] <kepstin> jmack: iirc, the usual way to remove dc offset (particularly if it shifts over time) it to apply a high pass filter at an inaudible low frequency, something around 1-5Hz maybe
[16:27:16 CEST] <jmack> OK, sorry, its just when you find someone who knows you just want to get as many answers as possible...
[16:28:11 CEST] <jmack> kepstin: thanks man
[16:28:24 CEST] <jmack> thebombzen: sorry again
[16:29:20 CEST] <thebombzen> jmack: and stop apologizing every other message
[16:29:33 CEST] <jmack> OK
[16:57:01 CEST] <lmat> Why is the vertical scale on ffplay linear instead of logarithmic?
[16:58:11 CEST] <lmat> oh... scale=log maybe... checking
[16:59:43 CEST] <lmat> my goodness... https://ffmpeg.org/ffplay-all.html
[16:59:48 CEST] <lmat> I see a lot of work has gone into this...
[16:59:56 CEST] <lmat> And I thought I was (mis-)using a debugging tool
[17:00:06 CEST] <c_14> lmat: I'm pretty sure it just inserts a default showspectrum filter
[17:00:55 CEST] <c_14> And the default scale should be sqrt
[17:01:11 CEST] <thebombzen> lmat: I find ffplay most useful because it's really really fast and configurable with a commandline. compared to mplayer which is slightly slower but the default options are better suited for long playback and has more keyboard shortcuts
[17:01:47 CEST] <thebombzen> i.e. in ffplay you specify which streams to play, with switches and in mplayer you use a keyboard shortcut once you've run it.
[17:04:23 CEST] <lmat> thebombzen: I play music to which I work using ffplay.
[17:04:53 CEST] <lmat> thebombzen: I've created a script to play recursively, optionally shuffling, optionally showing the (default) showspectrum, etc.
[17:05:02 CEST] <__z0k__> c_14: hm it might be, let me check my firewall
[17:05:08 CEST] <lmat> c_14: thanks
[17:05:23 CEST] <thebombzen> lmat: then you're using the right tool :D
[17:06:02 CEST] <lmat> c_14: How would I write the command to reproduce the default?
[17:06:14 CEST] <lmat> c_14:  ffplay  file.flacc 'showspectrum'; for instance doesn't work.
[17:11:02 CEST] <durandal_170> ffplay doesn't support a->v filters
[17:11:24 CEST] <kepstin> lmat: the default is "-showmode rdft" (if there's no video), which sets up the filter internally.
[17:14:57 CEST] <lmat> kepstin: Ahh, I see. Can you help me get started with a command to "showspectrum"?
[17:15:23 CEST] <lmat> I normally do  ffplay audio.wav;
[17:15:47 CEST] <kepstin> lmat: not sure what you mean... you can't manually use the showspectrum filter in ffplay, since it doesn't support a->v filters as durandal_170 said
[17:16:34 CEST] <kepstin> but it's the default in ffplay, so why do you even need to set it?
[17:17:27 CEST] <durandal_170> use mpv
[17:17:35 CEST] <lmat> kepstin: I want to modify its behaviour. It shows the frequency on a linear scale (as far as I can tell) and I prefer a logarithmic scale.
[17:17:37 CEST] <bencoh> :]
[17:18:01 CEST] <lmat> kepstin: What should I make of the 'showspectrum' part of this page: https://ffmpeg.org/ffplay-all.html#Syntax
[17:18:24 CEST] <lmat> well... https://ffmpeg.org/ffplay-all.html#showspectrum-1
[17:18:25 CEST] <kepstin> lmat: you can't do that with ffplay.
[17:18:59 CEST] <lmat> kepstin: What tool is that webpage documenting?
[17:19:19 CEST] <kepstin> lmat: that page is autogenerated, and just includes all the filters - even ones you can't use with ffplay
[17:19:32 CEST] <lmat> kepstin: Thanks. So I guess I come back to my original question ^_^
[17:19:33 CEST] <kepstin> (unless you feel like recoding ffplay to support the -filter_complex option like the ffmpeg command line tool does)
[17:19:40 CEST] <lmat> Why is the vertical scale on ffplay linear instead of logarithmic?
[17:20:25 CEST] <kepstin> it should be sqrt, actually, since that's the filter default
[17:21:00 CEST] <lmat> kepstin: That would make sense, but based on my experience, it doesn't seem to be... Screen shot coming.
[17:22:57 CEST] <lmat> Here is a logarithmic sweep: http://i.imgur.com/xPSZcll.png
[17:23:05 CEST] <lmat> I'll generate a linear one, too...
[17:23:55 CEST] <kepstin> oh, wow, the ffplay showmode isn't actually using the showspectrum filter internally
[17:24:02 CEST] <kepstin> it's actually a separate implementation
[17:25:11 CEST] <kepstin> looks like it is using sqrt scaling as well, though.
[17:25:25 CEST] <kepstin> if i'm reading this correctly
[17:25:57 CEST] Action: lmat cries
[17:26:16 CEST] <lmat> Maybe the showspectrum filter was too processor intensive?
[17:27:11 CEST] <kepstin> nah, it should be about the same. They're both using the same rdft implementation, of course.
[17:28:24 CEST] <kepstin> hah, according to the comments, the 'showspectrum' filter was actually made by extracting the rdft code from ffplay and turning it into a filter.
[17:30:39 CEST] <lmat> hah
[17:44:03 CEST] <kepstin> lmat: if you're in a particularly horrible mood, here's a horrible hack: ffmpeg -nostdin -i awesomemusic.ogg -filter_complex 'asplit[a][b];[a]showspectrum=scale=log:color=fruit[c]' -map '[b]' -map '[c]' -c:a pcm_s16le -c:v rawvideo -f nut - | ffplay -
[17:44:31 CEST] <lmat> ^_^
[17:45:10 CEST] <c_14> kepstin: want an even worse hack? use -f sdl and -f alsa (or -f pulse)
[17:46:22 CEST] <c_14> And you don't need the asplit, you can just -map 0:a instead
[17:46:33 CEST] <lmat> What color mode matches ffplay default?
[17:46:35 CEST] <JEEB> I'd just see if you could do the same with mpv
[17:46:41 CEST] <kepstin> lmat: channel
[17:47:23 CEST] <c_14> JEEB: I've tried and it's a pain, I think the only way I got it working was using the lavfi input device with the movie filter... Not much fun
[17:47:30 CEST] <c_14> Might have missed something though, or something might have changed
[17:47:36 CEST] <JEEB> ah
[17:47:41 CEST] <JEEB> that's possible, sure
[17:48:11 CEST] <kepstin> when playing with filters in mpv, i found a lot of lavfi filters don't really work properly, particularly if they rely on frame metadata (e.g. the interlaced flag isn't passed through)
[17:48:46 CEST] <lmat> With kepstin 's hack: http://i.imgur.com/N1utPb4.png  just ffplay awesomemusic.ogg; http://i.imgur.com/G3byUmq.png
[17:49:01 CEST] <lmat> kepstin: thanks!
[17:49:42 CEST] <c_14> Oh, cool. nvmd. the --lavfi-complex option does exactly what I want
[17:49:46 CEST] <lmat> (What is this awesomemusic.ogg that shakes and wiggles so much!?  Renee Fleming.)
[17:53:13 CEST] <c_14> lmat: if you have mpv you can use mpv --lavfi-complex='[aid1]asplit[ao][foo];[foo]showspectrum=scale=log[vo]' awesomemusic.ogg
[17:53:21 CEST] <c_14> should incur less overhead
[17:55:35 CEST] <kepstin> huh, that renders at a lower framerate for me
[17:57:54 CEST] <c_14> Probably because it reads input at realtime? Maybe add -re to the ffmpeg command?
[17:58:28 CEST] <kepstin> no, I mean the mpv one does; it's kind of jerky
[17:58:34 CEST] <kepstin> the ffmpeg hack was perfectly smooth
[17:59:28 CEST] <lmat> c_14: cool!
[18:00:09 CEST] <kepstin> i guess something in that filter chain messes with mpv's frame timing :/
[18:04:27 CEST] <c_14> Hmm, both look the same to me. It gets a bit jittery for me if I render at 1080p, but it does that for both.
[18:11:01 CEST] <lmat> yeah, I think ffplay uses linear... Here's a log sweep from 200 to 20,000 hz, 10 seconds: http://i.imgur.com/emtO76g.png and a linear sweep with the same parameters: http://i.imgur.com/QuzdVVm.png
[18:11:54 CEST] <lmat> oh well. Thanks for all the suggestions!
[18:17:18 CEST] <lmat> you know... the "crazy hack" given by kepstin has the same behaviour :o
[18:17:23 CEST] <lmat> The linear sweep looks... linear
[18:21:53 CEST] <lmat> Ah! I was doing it wrong!
[18:22:23 CEST] <lmat> I was running ffmpeg -autoexit -vn -; X-|
[18:25:25 CEST] <lmat> hmm, still, changing scale=log to scale=sqrt and scale=lin looks basically the same. Maybe I'm
[18:25:41 CEST] <lmat> well no wonder. rtfm: scale = "intensity color values"
[18:30:22 CEST] <lmat> showcqt does it logarithmically.but...
[18:31:19 CEST] <lmat> heh, Apparently Il mio tesoro is in Eb...
[18:31:48 CEST] <lmat> Of course, I assume this showcqt is using A=440.
[18:31:56 CEST] <lmat> And that Placido Domingo is using the same reference.
[19:11:58 CEST] Action: kepstin is too lazy to add 'showspectrum' support to his player, so he uses a silly ffmpeg command to hook it to the pulseaudio monitor input and give a spectrum of whatever's playing :)
[19:36:49 CEST] <explodes> Does the ffmpeg library load codecs from disk?
[19:37:31 CEST] <explodes> i.e. if i run the ffmpeg (as built libraries) on an iphone vs. an android vs. a PC or mac, they might have different codecs available?
[19:37:44 CEST] <explodes> iphone: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8c3d833400] moov atom not found
[19:37:49 CEST] <explodes> android: plays just fine
[19:38:49 CEST] <pzich> different devices definitely may have different codecs
[19:38:54 CEST] <pzich> if that's what you're asking
[19:39:09 CEST] <explodes> nooouuu ok ok
[19:39:28 CEST] <pzich> welcome to the fun world of video and streaming :D
[19:42:54 CEST] <kepstin> explodes: if you're getting a 'moov atom not found' error, that usually means that your mp4 file is incomplete (missing the end) or corrupted
[19:43:03 CEST] <kepstin> that's unrelated to codecs.
[19:44:27 CEST] <explodes> well, it plays on android just fine. the same ffmpeg binaries do not play the video on ios
[20:02:25 CEST] <markamillia> hello, I'm trying to combine 2 videos into one that plays them both side by side
[20:02:35 CEST] <markamillia> I'm having trouble with the example online
[20:08:08 CEST] <durandal_170> what trouble?
[20:09:58 CEST] <kepstin> explodes: according to that error, the problem isn't that the libraries are different - it's that the file is different.
[20:26:04 CEST] <fturco> hello. i'm transcoding some dvds with the vp9 codec (-c:v libvpx-vp9). i have a dual core cpu.
[20:26:27 CEST] <fturco> i read somewhere that vp9 doesn't automatically detect the number of cores yet. is that true?
[20:26:46 CEST] <fturco> if so, how can i tell ffmpeg to use both cores to increase speed?
[20:27:16 CEST] <kepstin> fturco: you could try manually setting -threads 2 and see if it makes a difference. But libvpx doesn't seem to make use of multithreading very well, particularly for standard definition sources.
[20:28:16 CEST] <fturco> here (http://wiki.webmproject.org/ffmpeg) it says "recommended value : number of real cores - 1)"
[20:28:26 CEST] <fturco> why?
[20:29:51 CEST] <kepstin> it's probably implemented as "the number of threads in addition to the main thread"
[20:32:12 CEST] <fturco> so i could use -threads 1
[20:32:31 CEST] <kepstin> try a couple values, see if you get any improvement
[20:32:43 CEST] <kepstin> I suspect it'll be marginal differences at best
[20:33:57 CEST] <fturco> i cannot try right now because my cpu is already busy with an encoding process. it will take all the night for it to finish. tomorrow i'll try re-running the same ffmpeg command plus the -threads 1 option
[20:35:05 CEST] <fturco> the system monitor currently doesn't show 100% usage for both cpu.
[20:38:27 CEST] <fturco> here (http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide) it says: "Multi-threaded encoding may be used if -threads > 1 and -tile-columns > 0."
[20:38:40 CEST] <fturco> so i guess -threads 1 won't work
[20:39:16 CEST] <fturco> i find documentation on the internet to be lacking in this case..
[20:39:21 CEST] <kepstin> and tile-columns can reduce the encoding efficiency, particularly on SD material (it doesn't hurt as much on HD or 4K stuff because the tiles are bigger)
[20:39:57 CEST] <fturco> that guide seems to be tailored for HD material
[20:40:29 CEST] <kepstin> yeah, the newer codecs like H.265 and VP9 all have HD+ and 4K material as the design target
[20:41:08 CEST] <fturco> i guess the -b:v 1000k bitrate option is also tailored for hd material. what i should use for a DVD?
[20:41:12 CEST] <furq> i wouldn't bother with vp9 unless you have some issue with mpeg-la
[20:41:46 CEST] <fturco> just like the idea of using a completely free format/codec instead of proprietary one
[20:42:21 CEST] <kepstin> 1000k is actually a bit low for hd stuff, I'd think... but I don't have much experience with using vp9. You'd probably want to use the quality based mode (-crf in ffmpeg) for most stuff instead of bitrate control, though.
[20:43:27 CEST] <fturco> i have even more difficulties at choosing wich -crf value to use. at least the bitrate is something tangible..
[20:43:41 CEST] <pzich> -crf is even better than bitrate
[20:43:55 CEST] <pzich> bitrate is completely arbitrary based on the content and codec
[20:44:01 CEST] <kepstin> bitrate is a meaningless number uncorrelated to how good the video looks, and in non-quality modes 1-pass bitrate will even make quality vary over time
[20:44:03 CEST] <furq> crf is better when sensible values are well documented
[20:44:05 CEST] <pzich> at least -crf is a stab at quality
[20:44:14 CEST] <furq> i haven't really found any consistent information on what to use for libvpx
[20:44:34 CEST] <furq> and i'm not spending ten million years trying out multiple values
[20:44:45 CEST] <pzich> ...you'd be doing the same for bitrate, no?
[20:45:00 CEST] <fturco> can -crf mode be use with two-pass encoding too?
[20:45:04 CEST] <kepstin> sure, but crf is faster because you don't need to wait for two passes
[20:45:16 CEST] <kepstin> with vp8, crf mode was a bit wonky because you also needed to set a bitrate (which was used as a "max bitrate" value), and it did give improvements with 2-pass mode
[20:45:21 CEST] <kepstin> dunno how much of that applies to vp9
[20:45:43 CEST] <furq> you still need to set a bitrate but you can set it to 0 to disable the bitrate cap
[20:46:23 CEST] <fturco> do you suggest me to ask on the #vp8 irc channel?
[20:46:34 CEST] <furq> is there such a thing
[20:46:37 CEST] <kepstin> with x264, crf mode is basically equivalent to the second pass of a two pass mode in most cases, so 2pass doesn't really make a difference there.
[20:46:37 CEST] <fturco> yes
[20:46:46 CEST] <kepstin> dunno about x265, might be similar?
[20:47:05 CEST] <furq> 2-pass makes a difference if you're targeting a filesize
[20:47:14 CEST] <furq> i expect x265 and vp9 are the same but i've not used them enough to say for sure
[20:47:22 CEST] <kepstin> if you're targetting a file size, you're not using crf mode :)
[20:47:49 CEST] <furq> nvm i misread that
[20:48:47 CEST] <furq> i'm sticking with 10-bit x264 for now anyway
[20:49:09 CEST] Action: kepstin has to deal with browser decoders, so he still used 8bit most of the time :/
[20:57:33 CEST] <TD-Linux> libvpx VBR with 2 pass is very similar to CRF
[20:59:24 CEST] <kepstin> with x264, a crf encode and a vbr mode with the same bitrate as the crf encode used should be basically identical
[20:59:45 CEST] <kepstin> with vpx, i'd expect it to be close, but it uses different codepaths iirc so it won't be exactly the same...
[21:00:22 CEST] <TD-Linux> yeah, in libvpx, Q mode is more like constant quantizer
[21:01:31 CEST] <Filarius> just short question if somebody know - RTMP stream link is  "URL/secret_key"  like rtmp://1.1.1.1/some/some2/secret_key ?
[21:01:49 CEST] <mrmenacex> Has anyone succesfully made a webm dash manifest file using ffmpeg using the vp9 codec ? I have been trying for a day to make one and i keep getting errors . here is my pastebin http://pastebin.com/DhuKbddy
[21:02:12 CEST] <kepstin> Filarius: it depends exactly how that's implemented on the server. can't really say - the key might be part of the path, it might be an rtmp parameter...
[21:02:39 CEST] <Filarius> well, i meam link to stream to server, like Twitch
[21:02:48 CEST] <kepstin> Filarius: best idea might be to search "name of video streaming site ffmpeg" on google and see if someone else has figured out the exact syntax already
[21:02:58 CEST] <kepstin> it'll vary between services
[21:06:09 CEST] <kepstin> https://trac.ffmpeg.org/wiki/StreamingGuide actually has a twitch example there, the url format looks like "rtmp://live.twitch.tv/app/live_********_******************************"
[21:06:54 CEST] <kepstin> I think youtube's live feature gives you the full url rather than separate url and stream key.
[21:20:38 CEST] <mrmenacex> Anyone used DASH with vp9 yet ?
[21:27:06 CEST] <kepstin> mrmenacex: youtube does :)
[21:27:18 CEST] <kepstin> (no idea if anyone here uses it tho)
[21:32:26 CEST] <mrmenacex> kepstin: is youtube here ? lol
[21:33:34 CEST] <mrmenacex> kepstin: i probably should have said "anyone in here" haha
[21:40:34 CEST] <mrmenacex>  Well after some further googling i see a mail group post that says that ffmpeg can't make DASH manifest files if the video uses the vp9 codec , but it's from 2015 does anyone know how to check if this is fixed in the latest stable version ?
[21:43:18 CEST] <JEEB> it's quite a bit more different than that, since you're going out of the things specificed by MPEG-DASH (container is matroska/webm and all)
[21:43:36 CEST] <JEEB> so how is the GoogleDASH even specified!?
[21:44:05 CEST] <JEEB> we have just gotten random patches from Google that supposedly create the kind of webm they want
[21:44:20 CEST] <JEEB> but nothing in relation to manifests :P
[21:45:02 CEST] <JEEB> the only DASH manifest writer is in movenc.c
[21:45:19 CEST] <JEEB> because while you can do DASH with mpeg-ts, pretty much no-one does that :P
[21:45:24 CEST] <mrmenacex> JEBB: in the mail group it said that it does work with vp8 ?
[21:46:25 CEST] <JEEB> I have no idea, the only thing I know is that the DASH manifest stuff for Google's matroska subset/fork is not really defined because only youtube uses it :P
[21:47:19 CEST] <TD-Linux> mrmenacex, if it doesn't work you might want to file a ticket in trac about it
[21:47:44 CEST] <JEEB> if you can find actual specifications etc it might be implemented
[21:49:04 CEST] <JEEB> but I'm not even sure if there's a player for WebM DASH other than youtube's
[21:49:59 CEST] <JEEB> for HLS and actual specified DASH there are some JS implementations and MS's Edge browser can even natively support DASH manifests
[21:50:16 CEST] <JEEB> but the stuff you're talking of is very muchos Google-specific stuff
[21:51:38 CEST] <gnome1> and then google changes the format :-D
[21:52:41 CEST] <Mavrik> fun part about DASH
[21:52:52 CEST] <Mavrik> Safari supports it but it's only whitelisted if domain is netflix.com :P
[21:52:57 CEST] <JEEB> hah
[21:55:12 CEST] <Mavrik> Also it's a horrible spec that should be taken behind the shed and shot.
[21:55:26 CEST] <Mavrik> I have no frigging idea why Google refuses to support HLS in Chrome.
[21:55:41 CEST] <mrmenacex> what is hls ?
[22:00:45 CEST] <mrmenacex> i'm not that good with c but here is a link talking about the problem . http://ffmpeg.org/pipermail/ffmpeg-user/2015-September/028610.html
[22:02:02 CEST] <mrmenacex> so it works with vp8 but not with vp9 ? Also afaik only h265 and vp9 codecs do resolutions higher than 1080p ? and h265 has no browser support at all?
[22:03:34 CEST] <gnome1> mrmenacex: the currently widely used "streaming" protocol that relies heavily on HTTP, "playlists" served over HTTP
[22:03:42 CEST] <kepstin> mrmenacex: hmm? you should be able to do >1080p video just fine with h264/vp8. The newer codecs are just more efficient at it.
[22:03:49 CEST] <gnome1> designed by apple, stands for or some people call it HTTP Live Streaming
[22:04:12 CEST] <gnome1> the benefit of it so far is that it has become so widespread that many flash-based players are just HLS players and you can easily play it outside of the browser
[22:04:56 CEST] <gnome1> meanwhile, I think some of the players I use rely on ffmpeg for hls support, and sometimes the support is not perfect (I have to switch between players sometimes), which is expected, I guess some HLS implementations are just broken
[22:06:21 CEST] <Mavrik> gnome1, there are corner cases which aren't well documented or specified which cause problems
[22:06:49 CEST] <Mavrik> like where IDR frames have to be when doing quality switching, length of segments, etc.
[22:06:59 CEST] <gnome1> yeah, corner cases are something I'd expect
[22:08:44 CEST] <gnome1> and there's caching, I've seen streams that stutter, or that show delays when changing segments, or longer delays when starting up apparently because one of the variants is down
[22:08:59 CEST] <gnome1> and most of the time I'd just like to sit down and be able to enjoy the stream :-)
[22:09:13 CEST] <gnome1> it's already good that it can be played somehow without running any browser
[22:15:19 CEST] <TD-Linux> Mavrik, the reason is IPR as usual.
[22:16:04 CEST] <gnome1> doesn't make sense, but in this world I've seen enough not to question lack of sense
[22:16:20 CEST] <gnome1> like suing pocket music player manufacturers because they can be used to play music
[22:17:18 CEST] <furq> i can't help but notice that you have an "o" in your nick
[22:17:24 CEST] <furq> that might infringe on my patent for rounded corners in nicks
[22:17:40 CEST] <furq> please cease & desist
[22:18:05 CEST] <Mavrik> ö?
[22:18:35 CEST] <furq> i was thinking more like ¡
[22:34:59 CEST] <andrey_utkin> jkqxz, you have consulted me about debugging of broken h.264 stream, would you be so kind to look at my results? https://gist.github.com/andrey-utkin/73fb8975b8f18178a43a https://gist.github.com/andrey-utkin/1e0a2a85e4f039fe5ae3
[23:17:28 CEST] <lmeadors> i'm trying to create encrypted HLS content from an unencrypted m4a file and failing miserably
[23:18:19 CEST] <lmeadors> i have a 128 bit key: `openssl rand 16 > my.key`
[23:18:50 CEST] <lmeadors> i created a key info file with a url and a reference to that key in it
[23:19:28 CEST] <BtbN> I still wonder what the point of encrypting video with a well known AES key is.
[23:19:38 CEST] <lmeadors> i found a couple of SO posts where people were telling how to do it, but neither seem to be working quite right
[23:21:42 CEST] <lmeadors> one of them creates a beautiful m3u8 file, but no encryption is applied (even less useful than encrypting video with a well known AES key)
[23:21:54 CEST] <Mavrik> BtbN, content provider requirements :P
[23:22:16 CEST] <lmeadors> the other appears to encrypt yhe content, but only includes the last 5 segments :|
[23:28:19 CEST] <lmeadors> i can post my script somewhere if anyone has time to look at it - i'm hoping it's just me missing something dumb
[23:31:21 CEST] <lmeadors> the command is this:
[23:31:22 CEST] <lmeadors> ffmpeg -i test_source/tin_pan_ally.m4a -c:a libmp3lame -b:a 128k -map 0:0 -f segment -segment_time 30 -hls_key_info_file output/tin_pan_ally.keyinfo -segment_list output/tin_pan_ally.m3u8 -segment_format mpegts 'output/output-%03d.ts'
[23:31:40 CEST] <lmeadors> the key info file looks like this:
[23:31:54 CEST] <lmeadors> http://my_host_prefix/output/tin_pan_ally.key
[23:31:54 CEST] <lmeadors> output/tin_pan_ally.key
[23:32:44 CEST] <lmeadors> but the m3u8 file hos no reference to that url in it :/
[23:32:59 CEST] <lmeadors> but the m3u8 file has no reference to that url in it :/
[23:54:41 CEST] <lmeadors> this is using ffmpeg version 2.8.6, btw
[23:56:57 CEST] <lmeadors> i guess i can try to ghetto it out and manually encrypt the ts files and add the line to the m3u8 file
[23:57:04 CEST] <lmeadors> seems lame, but it might work
[00:00:00 CEST] --- Tue Mar 29 2016


More information about the Ffmpeg-devel-irc mailing list