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

burek burek021 at gmail.com
Wed Mar 30 02:05:01 CEST 2016


[00:17:08 CEST] <Psi-Jack> I'm having an issue with ffmpeg I can't seem to resolve. I've got a .flac file I'm trying to convert to m4a with the libfdk_aac module.
[00:18:00 CEST] <Psi-Jack> ffmpeg -y -i "08-Elastic Heart.flac" -c:a libfdk_aac -b:a 256k "08-Elastic Heart.m4a" -- Results in this error: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[00:18:33 CEST] <JEEB> the error is somewhere before that
[00:18:41 CEST] <JEEB> just pastebin the whole command and command line output
[00:18:43 CEST] <JEEB> and link here
[00:19:24 CEST] <jkqxz> andrey_utkin:  So you've got a stream with some failing frames in it; now you want to work out what's special about those frames.  (Looks like the decoder chokes most of the way through those frames (~1100/1350); maybe you have some fixed buffering somewhere which is being exceeded?)
[00:20:24 CEST] <Psi-Jack> Okay. Will do.
[00:24:23 CEST] <Psi-Jack> https://paste.linux-help.org/view/645140af
[00:24:58 CEST] <jkqxz> andrey_utkin:  You might also want to extract the elementary stream ("-i input.mkv -c copy output.264"), which you can then do more with.
[00:28:02 CEST] <JEEB> Psi-Jack: add -vn after input file name
[00:28:21 CEST] <JEEB> it's trying to encode the JPEG in there as AVC... with CUDA
[00:28:36 CEST] <Psi-Jack> Heh, sheash...
[00:28:38 CEST] <JEEB> which fails :P
[00:28:50 CEST] <Psi-Jack> Alrighty! Yep. That's working alrighty
[00:28:53 CEST] <JEEB> vn tells it that no video should be encoded
[00:29:00 CEST] <Psi-Jack> Right, I looked it up. :)
[00:29:04 CEST] <JEEB> also you should most probably update that ffmpeg
[00:29:21 CEST] <Psi-Jack> I wish I could, it's actually amazing that I have this version at all, on CentOS 7.
[00:29:29 CEST] <Psi-Jack> WITh the fdk_aac support.
[00:29:47 CEST] <Psi-Jack> I could compile a new version, sure, but I prefer not to if I don't /need/ to. :)
[00:31:58 CEST] <Psi-Jack> Looks like that also handles tagging copies too, which is VERY nice, compared to my previous method, which was to use ffmpeg to output WAV, then use neroAacEnc to stream that to AAC in-line.
[00:32:07 CEST] <Psi-Jack> (aka: through pipes)
[00:50:31 CEST] <Psi-Jack> Heh.
[00:50:34 CEST] <Psi-Jack> This is totally wierd...
[00:53:44 CEST] <Psi-Jack> My script is running through multiple files converting everything from .flac to .m4a that isn't in the working directory or the library directory itself, but doing the ffmpeg by the CLI directly on a specific file, no problem. Doing it in my bash script, "very odd things" (tm) happen, where it....
[00:53:47 CEST] <Psi-Jack> Well, https://paste.linux-help.org/view/801dd066
[00:54:03 CEST] <Psi-Jack> It's hard as hell to explain what's going on here...
[00:54:37 CEST] <Psi-Jack> Most of all, I have no clue what that whole Enter command: <target>|all <time>|-1 <command>[ <argument>] is all about.
[00:55:41 CEST] <Psi-Jack> Or why it has Press [q] to stop, [?] for help...
[00:56:53 CEST] <Psi-Jack> Huh.. -nostdin solved that issue...
[00:56:58 CEST] <llogan> Psi-Jack: maybe you need -nostdin
[00:57:04 CEST] <Psi-Jack> heh
[01:04:53 CEST] <Psi-Jack> Hmm interesting.
[01:05:28 CEST] <Psi-Jack> It doesn't /entirely/ seems to copy the metadata over to the new format fully, for some odd reason. I'd thought it would but running musicbrainz on it shows a lot of metadata isn't.
[01:54:35 CEST] <andrey_utkin> jkqxz, hard to imagine a fixed buffer size issue when I-frames are passed perfectly on full framerate, and even low quality low framerate P-frames even on single channel get broken instantly
[01:55:47 CEST] <andrey_utkin> also it's interesting that ffmpeg dumps just few decoding errors, but in fact all the time of P-frames being enabled is distorted
[01:56:33 CEST] <andrey_utkin> so maybe distortion happens before encoding, and decoding errors are unrelated to this (i.e. there are at last two separate issues)
[01:57:39 CEST] <andrey_utkin> jkqxz, I appreciate your help very much, would you be so kind to hear the whole story and to help with fixing specific issues? Not for free of course.
[02:37:45 CEST] <kepstin> Psi-Jack: yeah, ffmpeg doesn't copy multi-value fields properly, unfortunately
[02:38:10 CEST] <Psi-Jack> Hmm yeah...
[02:38:16 CEST] <kepstin> Psi-Jack: and it doesn't translate fields - picard uses different tag names in different formats in some cases, and ffmpeg tries to copy them as-is
[02:38:40 CEST] <kepstin> (it translates some fields, but only the obvious common ones)
[02:38:53 CEST] <Psi-Jack> Well, it does a better job than my ffmpeg to wav to stdout piped to neroAacEnc, and then going and using neroAacTag to tag it, one thing at a time.
[09:50:12 CEST] <sagax> hi all!
[09:50:44 CEST] <sagax> how to check that codecs and formats write?
[09:50:51 CEST] <sagax> in ffmpeg
[09:51:50 CEST] <sagax> i see codecs with ffmpeg -codecs and i see formats with ffmpeg -formats, but i wish check that ffmpeg see codecs and work,
[09:51:55 CEST] <sagax> how to check this?
[13:28:51 CEST] <jkqxz> andrey_utkin:  All P frames are wrong, even if they don't get decode errors?  That probably means your header is wrong somehow (maybe there is some flag not used for IDR frames which isn't right in the parameter sets, or maybe the fixed-QP isn't quite as fixed as you thought, or something else).
[13:33:07 CEST] <lmeadors> \quit
[13:33:37 CEST] <jkqxz> The reference decoder output made it look like there weren't any errors there, but I don't precisely remember how that works.  (The trace option I was talking is compile-time in JM/ldecod/inc/defines.h.  You probably want to cut the file down a bit before trying to use it, though, because the output is enormous.)
[15:13:47 CEST] <frenda> Hey there
[15:13:53 CEST] <frenda> for i in *.vtt; do ffmpeg -i $i $i.srt; done
[15:13:59 CEST] <frenda> that does not work!
[15:14:14 CEST] <ncopa> somethign like this: http://tpaste.us/AW4Y
[15:15:08 CEST] <c_14> ncopa: that link went into the wrong channel, paste it again in -dev
[15:15:16 CEST] <c_14> frenda: define "does not work"
[15:15:31 CEST] <frenda> c_14: http://paste.ubuntu.com/15551607/
[15:15:45 CEST] <ncopa> c_14 it did. sorry
[15:16:07 CEST] <frenda> -i A.vtt A.srt --> works, but, that loop does not
[15:17:33 CEST] <c_14> Try enclosing $i in quotes like "$i" ?
[15:19:30 CEST] <c_14> But this seems like a problem with your shell.
[15:19:39 CEST] <c_14> Try replacing ffmpeg with echo and seeing what happens
[15:21:12 CEST] <frenda> Ah, solved by enclosing $i; Thanks man
[15:26:12 CEST] <frenda> Oops, it keeps the 'vtt' in file name!
[15:26:26 CEST] <frenda> files are converted from A.vtt to A.vtt.srt, while I need A.srt
[15:30:22 CEST] <c_14> "${i%%vtt}srt"
[15:35:18 CEST] <frenda> c_14, Ah, life is simple now.
[15:35:38 CEST] <frenda> %% or just one %?!
[15:44:36 CEST] <Noturno99> hey guys, is there a way to stop ffmpeg trying to read rtmp? I get this message continuously: Trying different position for server digest!
[16:01:56 CEST] <LuisM> hi folks
[16:05:14 CEST] <lukesan> sorry guys, is there a way to use ffmpeg to recover an mp4 corrupted file ( "moov atom not found")?
[16:06:28 CEST] <JEEB> no
[16:07:00 CEST] <JEEB> it can't be automated without having a library of how different things (usually pieces of hardware) write it
[16:07:09 CEST] <JEEB> and even then it's quite up to the luck :P
[16:07:18 CEST] <JEEB> use movie fragments or another container than mp4
[16:14:13 CEST] <lukesan> thanks a lot JEEB
[17:29:01 CEST] <fred1807> I want to write a script, that will scan a folder of videos and rename the filenames with the video resolution of each file. Can I use ffmpeg for this?  What would be a ffmpeg command to return the Video Resolution only, as a single string, so I can use it as a variable ?
[17:30:35 CEST] <JEEB> use ffprobe and its json output
[17:30:41 CEST] <JEEB> then parse the json for the video track(s)
[17:30:51 CEST] <JEEB> that would contain the resolution
[17:36:48 CEST] <furq> fred1807: ffprobe -v error -of csv -select_streams v:0 -show_entries stream=height,width foo.mkv | cut -d, -f2,3 | tr , x
[17:44:42 CEST] <fred1807> furq: Perfect, thank you!
[17:54:01 CEST] <gnome1> nice. I've been using ffmpeg -i when I need to get some information quickly ,maybe I should be using ffprobe instead?
[17:55:11 CEST] <kepstin> ffprobe can show more detailed information, and it outputs a machine-readable format useful for scripting.
[17:55:45 CEST] <mr_pinc> When FFMPEG is outputing a line like - frame= 5438 fps=143 q=30.0 - what does the q= stand for?
[17:56:24 CEST] <DHE> quantizer. a measure of the image quality at that moment. it's meaning is codec dependent
[17:56:39 CEST] <kepstin> nominally, the quantizer picked for the frame. But it's pretty meaningless on modern codecs like h264 since it can use different quantizers for different parts of a frame.
[17:57:17 CEST] <mr_pinc> Ok so if I specify -  -c:v libx264 -crf 25  - how does my '25' relate to the q=300.0?
[17:57:22 CEST] <mr_pinc> err q=30.0?
[17:57:37 CEST] <kepstin> mr_pinc: it doesn't really relate at all.
[17:58:18 CEST] <mr_pinc> ok good to know.
[17:58:28 CEST] <mr_pinc> thank you
[18:22:46 CEST] <xreal> What's the highest possible AAC quality to get with the GNU version ?
[18:24:08 CEST] <xreal> I mean, the settings ;)
[18:32:57 CEST] <kepstin> xreal: you mean, with ffmpeg's internal aac encoder?
[18:34:47 CEST] <kepstin> xreal: I think you probably want to stick with the defaults for the most part, and just set a bitrate.
[18:36:10 CEST] <xreal> kepstin: I've read the experimental AAC would be nice ?
[18:36:15 CEST] <xreal> AAC encoder*
[18:36:36 CEST] <c_14> It's not experimental anymore
[18:36:49 CEST] <xreal> oooh: but it is no longer experimental and these options are unnecessary since 5 December 2015 ;)
[18:36:52 CEST] <xreal> c_14: thx
[18:38:01 CEST] <xreal> Trac says, VBR settings (-q:a) are experimental and likely to get even worse results than the CBR. Is this also true since 5th December ?
[18:40:01 CEST] <c_14> I think that's still accurate, but am not sure.
[18:45:33 CEST] <slylock105> hi guys
[18:46:19 CEST] <slylock105> I am trying to convert mp3 to wav(8000hz) using ffmpeg but in one instance it truncates the wav file
[18:46:32 CEST] <slylock105> can anyone suggest what I could be doing wrong
[18:47:02 CEST] <slylock105> ffmpeg -i $MP3FILE -acodec pcm_s16le -ac 1 -ar 8000 $WAVFILE
[18:51:28 CEST] <xreal> Hehe, playback Full HD 50i video material on an i5 is ... incredible unwatchable :)
[18:51:35 CEST] <xreal> raw imagery
[18:51:40 CEST] <xreal> RGB24 :)
[18:55:17 CEST] <kepstin> well, 1080i50 raw should be perfectly watchable... as long as you don't want it to be deinterlaced ;)
[18:58:28 CEST] <xreal> kepstin: oh yeah, playback was set to deinterlace ,)
[18:58:30 CEST] <xreal> ;)
[19:05:10 CEST] <xreal> Hmm.. I want to create 1080i50 mp4 from my cutting application using ffmpeg. Is it best to output uncompressed RGB24 from the application or shall I use MJPEG at 100% ?
[19:34:18 CEST] <momomo> why does java redirect the ffmpeg output to the error stream ?
[19:47:04 CEST] <xreal> kepstin: can I get your ideas on that ?
[19:49:30 CEST] <kepstin> xreal: well, ideally your app would be outputting raw yuv420p video, since that's the format that you probably want to encode the video to.
[19:49:55 CEST] <xreal> kepstin: oh, I thought RGB24 is the best format... 1 sec
[19:50:19 CEST] <kepstin> if you can't do that, raw rgb and doing the conversion to yuv420p in ffmpeg would be next best, but you have to do some stuff with filters to get it to do an interlaced conversion, I think.
[19:51:27 CEST] <xreal> kepstin: I can select ffmpeg video encoder in the application, but can't set yuv420p as colorspace.
[19:52:57 CEST] <furq> which application
[19:53:10 CEST] <xreal> furq: Magix Video Deluxe Premium 2016
[19:54:38 CEST] <xreal> The application is very acceptable for its price, but of course not "high end".
[19:55:38 CEST] <furq> rgb24 might be better, it depends what you intend to do with the video
[19:55:50 CEST] <furq> if you want it to be playable everywhere then you probably want yuv420p
[19:56:51 CEST] <xreal> furq: Actually, I'd like to upload it to Vimeo and watch it on my Raspberry
[19:57:13 CEST] <furq> there's no point using rgb then
[19:57:21 CEST] <kepstin> well, vimeo's gonna re-encode it anways, but there's no benefit, yeah
[19:57:28 CEST] <furq> exactly
[19:57:31 CEST] <furq> it'll just make the upload take longer
[19:57:49 CEST] <xreal> furq: My problem is, you CAN NOT select a color space on output.
[19:57:59 CEST] <xreal> uncompressed AVI is RGB24 only.
[19:58:00 CEST] <furq> can you set ffmpeg options
[19:58:26 CEST] <xreal> furq: but not inside magix, only when exporting uncompressed avi using ffmpeg encoder.
[19:58:38 CEST] <furq> that's what i meant
[19:58:44 CEST] <xreal> furq: let me create a screenshot
[19:59:08 CEST] <furq> it seems like you should be able to but i've seen a few cheap commercial NLEs and it doesn't surprise me if you can't
[19:59:28 CEST] <furq> i'm not sure why i said cheap, that applies across the board really
[19:59:37 CEST] <xreal> furq: http://fs5.directupload.net/images/160329/nd4nruh6.png
[20:00:14 CEST] <kepstin> xreal: pick YV12, that's basically the same as yuv420p (has the u/v planes switches, but ffmpeg handles that fine)
[20:00:26 CEST] <furq> i'm glad someone had that committed to memory
[20:00:42 CEST] <xreal> kepstin: Thanks!
[20:01:23 CEST] <furq> i420/iyuv is exactly the same as yuv420p i think
[20:01:28 CEST] <kepstin> hmm, actually, you could use I420/IYUV instead, that uses the same plane order as yuv420p
[20:01:35 CEST] <kepstin> either way it doesn't really make a difference
[20:02:15 CEST] <xreal> Hmm... Why it bad to export to rgb24 and convert to mp4 with yuv420p later?
[20:02:20 CEST] <furq> are you uploading the uncompressed video directly or is this an intermediate video for editing
[20:02:36 CEST] <xreal> furq: intermediate. Magix MP4 encoder isn't THAT good ;)
[20:02:41 CEST] <furq> ok good
[20:02:44 CEST] <kepstin> xreal: it depends what your sources are and how the editor works internally
[20:02:58 CEST] <furq> it's not bad as such, there's just no point having an rgb intermediate file if your final file is yuv420p
[20:03:05 CEST] <xreal> kepstin: I think, it uses RGB24, since the native AVI export without a filter is RGB24.
[20:03:07 CEST] <kepstin> if the editor works internally in rgb, then it doesn't make a difference. if the editor works internally in yuv, the conversion to rgb then back can be a bit lossy
[20:03:08 CEST] <furq> yuv420p will be smaller
[20:03:21 CEST] <xreal> Okay.
[20:03:27 CEST] <xreal> I think, I need to do some tests for the future.
[20:03:49 CEST] <xreal> Let me check what format my input material is in
[20:04:27 CEST] <kepstin> (the only reason I remember that YV12 thing is that old versions of the x264 command-line encoder only supported yv12 as the raw input format)
[20:06:17 CEST] <xreal> Video: MPEG4 Video (H264) 1920x1080 50fps [V: h264 high L4.2, yuv420p, 1920x1080]
[20:06:24 CEST] <xreal> Wrapped in MPEG-TS
[20:07:13 CEST] <furq> i should have probably guessed that from the fact that it's 1080i50
[20:07:24 CEST] <furq> i don't know where you'd find an rgb 1080i source
[20:10:22 CEST] <Kuroonehalf> Hi! I need some help please. Recently I switched my streaming setup from regular OBS to OBS studio, and turns out I set different settings for my local recording than before, and it's making ffmpeg error when trying to reencode (might not be the right word here) the flv files into mp4
[20:11:54 CEST] <xreal> I'll be back in some minutes. THanks for your input !
[20:18:06 CEST] <Kuroonehalf> these new OBS settings are -> https://vgy.me/u83Xtv.png , and the command line stuff -> https://vgy.me/4HH2Zw.png
[20:18:42 CEST] <Kuroonehalf> let me know if there's important information missing and/or how to obtain it
[20:18:50 CEST] <furq> what options are there for video encoder in obs
[20:19:04 CEST] <furq> flv seems to be flv1, which you don't want to use unless you live in 2003
[20:19:26 CEST] <Kuroonehalf> I see
[20:19:36 CEST] <furq> also you were right about reencoding not being the right word, you're remuxing
[20:19:56 CEST] <Kuroonehalf> ah, okay, I thought that might be the case  :p
[20:20:11 CEST] <Kuroonehalf> is there a way to salvage this footage?
[20:20:34 CEST] <furq> does it need to be mp4
[20:21:00 CEST] <Kuroonehalf> ideally yes, as it's for use in Premiere
[20:22:03 CEST] <furq> well if premiere can't import flv1 then you'll have to reencode it, presumably to h264
[20:22:25 CEST] <Kuroonehalf> could you instruct me on how I could do that?
[20:23:07 CEST] <furq> ffmpeg -i src.flv -c:v libx264 -c:a copy dest.mp4
[20:23:41 CEST] <furq> assuming the source is worth salvaging, i can't imagine 1000kbps flv1 is watchable
[20:24:07 CEST] <Kuroonehalf> it's from drawing streams, so 1k bitrate works fine
[20:28:35 CEST] <Kuroonehalf> Kay, reencoding now. Thanks for the help o/
[20:33:03 CEST] <Kuroonehalf> By the way, do you reckon I should use one of the tuning options available? Since it's drawing, only small portions of the screen are being modified at a given time. Once every few seconds or minutes I might pan the canvas, but otherwise it's fairly static
[20:34:51 CEST] <Kuroonehalf> I also have a music track overlay that updates every second with the current play time in the track
[20:35:02 CEST] <Kuroonehalf> but it's really small
[20:36:49 CEST] <furq> tune animation might make sense
[20:58:03 CEST] <melzza> Is there a way to save directly to .ts format? I am trying to concatenate videos made from .png files. for testing purposes, i used half of the pngs to make video one and half to make video two.
[20:58:42 CEST] <melzza> i followed the process from the ffmpeg website for concatenating, using 2 intermediate files. please see http://pastebin.com/iQYA3W3N
[20:59:16 CEST] <melzza> but it seems like this is another step that i could avoid if i had the .ts file created instead of the .mp4 in the first steps
[20:59:44 CEST] <kepstin> melzza: sure, change the file extension of the output to .ts instead of .mp4
[21:00:16 CEST] <melzza> oh, it's the easy. eek! okay
[21:00:18 CEST] <melzza> thank you
[21:00:23 CEST] <melzza> it's that easy*
[21:00:59 CEST] <llogan> melzza: you can do it all in once command with the concat filter
[21:03:01 CEST] <melzza> well, normally, i don't have the second movie available. i am making the movie based on png output that is accumulated over ~1hr of simulation. so i will make potentially one movie from N .png files. at the next hour, i would make another movie from M .png files, etc.... until I concatenate them at the end.
[21:03:12 CEST] <melzza> i could not think of an easier way to do this, though i am open to ideas
[21:03:24 CEST] <melzza> i am very new to ffmpeg
[21:04:31 CEST] <llogan> melzza: then you can make the video segments as you did in the first two commands then use the concat demuxer to concatenate them all
[21:05:32 CEST] <llogan> fewer steps
[21:07:45 CEST] <melzza> hm.... okay. i apologize but totally new to this stuff. would i write a script that just busy-waits for new .png files to come into the directory and then streams them onto the end?
[21:10:34 CEST] <melzza> i had looked into the demuxer, but i wasn't entirely sure how to use it for my use case -- hence i used the protocol
[21:21:44 CEST] <melzza> i think that is where my confusion comes in. so say, as an example, the script sleeps for ~1hr [it's on a queuing system, so better if it just wastes a core or so]. it creates an mp4 based on the PNG files accumulated over the last 60 minutes. my confusion is where to use the demuxer. do i wait until the very end of the script and then pass it all of the mp4s, or is there a way to do it incremently?
[21:22:30 CEST] <furq> use it at the very end
[21:23:14 CEST] <furq> there's not really any benefit to doing it incrementally, it should be very fast even with hours of footage
[21:25:08 CEST] <melzza> so are you saying just let the sim generate all of the .pngs and then call ffmpeg once at the end? Or are you saying I can still call the intermediate steps to make an .mp4 and then just concatenate once at the end? sorry - just need clarification.
[21:25:48 CEST] <melzza> in this case, making the intermediate .mp4s provides the benefit that the .pngs associated with it can be deleted
[21:25:53 CEST] <furq> concatenate once at the end
[21:26:28 CEST] <melzza> okay -- so using the demuxer, i can keep everything in the .mp4 format? rather than doing the .ts conversion?
[21:26:44 CEST] <furq> sure
[21:26:56 CEST] <furq> you could just use ts for the segments though
[21:28:29 CEST] <melzza> okay! is there any intuition if the protocol or the demuxer is faster (for the last step)? not sure what it's calling underneath the hood
[21:29:24 CEST] <furq> the protocol is pretty much just doing cat file1 file2 > file3
[21:29:36 CEST] <furq> which is why it only works with certain containers
[21:29:45 CEST] <furq> i would expect that to be faster since afaik it doesn't have to decode
[21:30:20 CEST] <melzza> okay -- thanks so much for your help
[21:30:58 CEST] <kepstin> well, neither the protocol or demuxer have to decode. In the protocol case, one demuxer is run over the resulting stream; in the demuxer case it opens each stream separately with its own demuxer. The perf difference should be negligible, other than differences due to the container used.
[21:31:08 CEST] <xreal> furq kepstin: The file is 2 MB smaller with y420 :)
[21:32:06 CEST] <xreal> furq kepstin: But it's still RGB24 1920x1080 50fps :(
[21:32:16 CEST] <xreal> Seems like the app can't do the export correctly.
[21:38:07 CEST] <xreal> AH! I made it work!  IYUV 1920x1080 50fp
[21:49:26 CEST] <Kuroonehalf> Hey Furq. I reencoded the first of those vods I asked for help with (flv1 -> libx264), and the final file size ended up 600MB. Usually these chunks of 5 hour footage, after remuxing from normal flv -> mp4, end up taking up 2 gigs. Is it normal that it became so much smaller when reencoded? :O
[21:52:12 CEST] <Kuroonehalf> I think it was furq who helped me. Apologies if I mixed up the name
[21:53:23 CEST] <kepstin> Kuroonehalf: h264 is a much better codec than flv1, so it's normal for the file to be smaller for the same quality
[21:53:39 CEST] <Kuroonehalf> I see
[21:54:09 CEST] <kepstin> (of course, you should actually check that the quality is comparable)
[21:54:15 CEST] <Kuroonehalf> is there perhaps some way I could save to flv from OBS using some other better codec? Or is the flv format restricted to that?
[21:54:30 CEST] <Kuroonehalf> I did, and I didn't notice any differences
[21:55:08 CEST] <furq> if you can normally remux flv to mp4 then i assume it's using h264 already
[21:55:10 CEST] <kepstin> Kuroonehalf: possibly. check the "Video Encoder" dropdown and see what other options are available
[21:55:23 CEST] <furq> but from that options screen it looks like it's using vbr
[21:55:39 CEST] <Kuroonehalf> it's constant bitrate
[21:55:47 CEST] <furq> or false cbr, sure
[21:55:56 CEST] <furq> for a screencast that'll be wasting bits a lot of the time
[21:56:22 CEST] <Kuroonehalf> kepstin: it has this https://vgy.me/bukGvs.png
[21:56:33 CEST] <Kuroonehalf> x264 encoder option
[21:56:53 CEST] <kepstin> Kuroonehalf: well, that would be better than flv1 for sure :)
[21:57:14 CEST] <furq> if you want the same filesize as you got from ffmpeg then disable cbr and add "-crf 23" to the x264 options
[21:57:15 CEST] <kepstin> it's a program designed for streaming, so it doesn't appear to let you do crf encoding, which is a pity
[21:57:19 CEST] <furq> although i think it defaults to that anyway
[21:57:31 CEST] <furq> that obviously won't be cbr but i don't think it really matters that much
[21:58:14 CEST] <kepstin> furq: from that screenshot, it appears to default to 1-pass vbr bitrate mode :/
[21:58:16 CEST] <furq> actually nvm that won't work
[21:58:17 CEST] <furq> yeah
[21:58:21 CEST] <Kuroonehalf> this won't change how flv works, right? As in, the reason I use flv is because if there's a power outage or some such disaster where the computer is shut down without warning, the video archive survives
[21:58:46 CEST] <kepstin> Kuroonehalf: yeah, unlike mp4 where if the file end is missing, the video's unplayable :)
[21:58:52 CEST] <Kuroonehalf> yeah
[21:58:55 CEST] <furq> that's a property of the container so it'll make no difference
[21:58:58 CEST] <kepstin> Kuroonehalf: that's a quirk of the mp4 container, it's unrelated to the codec
[21:59:02 CEST] <Kuroonehalf> okay, just making sure
[21:59:13 CEST] <JEEB> also you can go around that limitation if you use movie fragments
[21:59:24 CEST] <JEEB> which makes every GOP go into its own fragment
[21:59:28 CEST] <furq> assuming OBS supports that, which it probably doesn't
[21:59:28 CEST] <JEEB> within the container
[21:59:43 CEST] <JEEB> if it uses one of the major muxers the feature is available for it
[21:59:53 CEST] <JEEB> if it has hidden it, then bad for it
[22:00:17 CEST] <furq> anyway you can probably reduce the bitrate a bit, especially if you use a slower profile
[22:01:19 CEST] <Kuroonehalf> usually when I stream with CPU usage = veryfast & profile = high, I average 13% CPU usage during stream
[22:01:29 CEST] <furq> profile makes no difference
[22:01:44 CEST] <Kuroonehalf> do you think I could increase the preset a few notches without much impact to performance?
[22:01:48 CEST] <kepstin> furq: you said profile originally, did you mean preset?
[22:01:53 CEST] <furq> oh
[22:01:54 CEST] <furq> so i did
[22:01:57 CEST] <furq> yeah i meant preset
[22:02:09 CEST] <furq> try preset faster and tune animation
[22:02:19 CEST] <Kuroonehalf> gonna try medium and tuned to animation next time
[22:02:33 CEST] <furq> or medium, sure
[22:05:05 CEST] <Kuroonehalf> hm, it seems that I can have different streaming settings than local recording. So I can do CBR for streaming but save in VBR. Would that be preferable?
[22:05:53 CEST] <furq> there's no reason at all to use cbr for local recording
[22:06:10 CEST] <kepstin> Kuroonehalf: x264 doesn't really support cbr, I have no idea what that checkbox does. I guess it probably sets up some vbv buffer constraints :/
[22:06:22 CEST] <furq> there's no reason to use 1-pass bitrate mode over crf either, but you don't seem to get the option
[22:06:32 CEST] <Kuroonehalf> okay. CRF 23 yes?
[22:06:43 CEST] <furq> i don't think that'll work
[22:06:45 CEST] <hpp> there is really no need to go higher than very fast when streaming. faster preset can use twice cpu time.
[22:06:57 CEST] <furq> there's no option to disable bitrate mode
[22:07:19 CEST] <kepstin> for sure, enabling that 'CBR' box for a local file is probably a bad idea; would only reduce quality since bandwidth isn't an issue.
[22:08:48 CEST] <xreal> Should be okay? ffmpeg -i "test.avi" -c:v libx264 -preset medium -crf 22 -c:a aac -b:a 160k test.mp4
[22:09:54 CEST] <kepstin> xreal: depends what for, but that should give you reasonable/moderate video quality at an ok encoding speed with decent audio.
[22:10:39 CEST] <xreal> kepstin: the incoming quality isn't thaaat good... Panasonic Lumix, but acceptable. Thanks for your support.
[22:11:33 CEST] <xreal> "rame= 3993 fps=5.6 q=30.0 size=   77593kB time=00:01:19.80 bitrate=7964.6kbits/" - why does it say q=30 ?
[22:11:45 CEST] <furq> because q has nothing to do with crf
[22:11:55 CEST] <xreal> oooh, I am stupid.
[22:18:35 CEST] <needmorespeed> Are there H.264 encoders other than x264 that can be used with FFmpeg?
[22:19:17 CEST] <xreal> Interesting. The encoded video is stuttering and the quality is worser than the direct export from Magix. Seems like crf 22 is too low
[22:20:47 CEST] <JEEB> needmorespeed: yes but most likely you won't gain what you nickname says you want :P
[22:20:57 CEST] <JEEB> xreal: you mean too high?
[22:21:31 CEST] <JEEB> because higher = higher quant ranges are used, lower = lower quant ranges are used. and the lower you go in quants the more bits you use.
[22:22:23 CEST] <xreal> JEEB: The file has less the size from Magix export. On playback of the mp4 file from FFmpeg, the CPU (i5) is at more than 65%. On playback the other file, it's around 30%
[22:25:31 CEST] <xreal> Seems like there is a problem with rawvideo.
[22:25:47 CEST] <xreal> Don't know if it's a problem of Magix (the outputting application) or ffmpeg
[22:28:25 CEST] <carli> Hi, any way to use ffmpeg server for routing to some rtmp server?
[22:31:20 CEST] <xreal> kepstin JEEB furq: rawoutput from the application seems to make the trouble.
[22:49:05 CEST] <petecouture> Using ffmpeg to encode a live rtp stream into m3u8 / .ts fragements. Has anyone ever run into an issue of the system stop generating .ts fragments and then suddenyl it catches up by creating a several empty frags. Almost like the uploading speed isn't very fast.
[23:05:25 CEST] <relaxed> carli: https://trac.ffmpeg.org/wiki/StreamingGuide
[23:13:56 CEST] <carli> relaxed: thanks for the link, I know how to stream, I searching for some solution where webrtc is used as source for ffmpeg
[23:14:28 CEST] <carli> I'm searching even ..
[23:16:22 CEST] <petecouture> carli: ffmpeg can't accept webrtc as a source
[23:16:49 CEST] <petecouture> You need a webrtc streaming server which converts the stream to rtp then you have ffmpeg connect ot that stream
[23:16:52 CEST] <petecouture> kurento.org
[23:16:57 CEST] <petecouture> is the server I'm currently using
[23:19:59 CEST] <carli> petecouture: thanks
[23:20:29 CEST] <petecouture> wowza is also a solution which has a lot better support but doesn't scale cost wise
[23:20:53 CEST] <carli> petecouture: but if I would like tu use ffmpeg for streaming :D
[23:20:56 CEST] <relaxed> carli: but you can send video to webrtc via ffmpeg
[23:21:33 CEST] <kepstin> can you? does ffmpeg do dtls?
[23:21:35 CEST] <carli> relaxed: I would like to send from browser to ffmpeg ... so I can save it or stream  ..
[23:21:59 CEST] <petecouture> relaxed: I don't think that's right.
[23:22:16 CEST] <relaxed> I know it's right
[23:22:47 CEST] <petecouture> how is the peer connection maintained
[23:22:47 CEST] <relaxed> you can have a v4l loopback device and have ffmpeg encode to it, then webrtc will just do it's thing
[23:24:01 CEST] <kepstin> carli: to send from browser to a server to record, you need to have something on the server that the browser can connect to for signalling (a webserver app, basically), and then something that handles the media bits of setting up the webrtc channel that ffmpeg doesn't support yet (this includes ICE and DTLS). after that, this app can just hand off the
[23:24:01 CEST] <kepstin> decrypted rtp to ffmpeg somehow to save it.
[23:24:46 CEST] <petecouture> ? but is that ffmpeg encoding directly to webrtc or is the v4l handling it.
[23:25:07 CEST] <relaxed> petecouture: v4l loopback is just the proxy
[23:25:29 CEST] <relaxed> oh, yes, webrtc still does the encoding
[23:25:49 CEST] <kepstin> petecouture: you can do ffmpeg -> v4l loopback, then the web browser reads from the virtual loopback webcam and re-encodes the video and sends to webrtc.
[23:26:08 CEST] <petecouture> Right but ffmpeg isn't doing the webrtc work
[23:26:13 CEST] <petecouture> that's all I ment
[23:26:15 CEST] <relaxed> correct
[23:26:19 CEST] <kepstin> yeah, the browser does in that case.
[23:27:22 CEST] <kepstin> there's enough corner cases and weird interop things in webrtc that if you want to send to webrtc from a app that's not a browser, you probably want to do it via the webrtc library extracted from chromium :/
[23:28:39 CEST] <carli> Ok, back to start :(
[23:28:43 CEST] <petecouture> carli: Just a heads up, the webrtc to ffmpeg output is a bit of a pain to get right.
[23:29:12 CEST] <petecouture> Very little documentation on it out there. Let me know if you want some pointers
[23:29:12 CEST] <carli> petecouture: i need webrtc in input ...
[23:29:37 CEST] <carli> petecouture: not output
[23:29:47 CEST] <petecouture> That's what I'm taking about
[23:29:50 CEST] <petecouture> webrtc source
[23:30:01 CEST] <carli> petecouture: ok
[23:30:21 CEST] <carli> Thank you all!
[23:30:24 CEST] <petecouture> but you have to have a webrtc streaming server that converts webrtc to rtp
[23:30:30 CEST] <petecouture> then you can use that as the source for ffmpeg
[23:31:02 CEST] <petecouture> with rtp you'll need to understand sdp and offer/response hand shaking
[23:31:21 CEST] <petecouture> Kurento and Wowza are the two everyone is using these days
[23:31:40 CEST] <carli> petecouture: ye I understand that, well if I use some streaming services, I don't need ffmpeg :D
[23:31:59 CEST] <petecouture> if you're just looking to save the media to disk
[23:32:02 CEST] Action: kepstin uses freeswitch for some of that stuff - it can accept a webrtc call, and record to a local file using ffmpeg as a library.
[23:32:13 CEST] <kepstin> (but that might be more complicated than you need)
[23:32:20 CEST] <petecouture> I'd recommend looking at kurento. It's pretty easy to setup a save to disk from a webrtc feed
[23:32:49 CEST] <carli> petecouture: well all of them offers some space there, so they save streams directy to files ...
[23:33:57 CEST] <petecouture> kepstin: thanks for that. I'm having issues with my stream being recorded right via kurento.
[23:36:14 CEST] <carli> kepstin: so you can stream that call to rtmp :D
[23:37:12 CEST] <kepstin> carli: freeswitch can in fact do that; they have their dev calls in a webrtc conference that's broadcast live on youtube :)
[23:39:20 CEST] <carli> kepstin: Need to check this :D Thanks!
[23:41:20 CEST] <Zeranoe> Is it possible to cat/type a file to FFmpeg so that it is not doing the file reading itself?
[23:42:21 CEST] <kepstin> Zeranoe: yes.
[23:42:29 CEST] <andrey_utkin> Zeranoe, cat file | ffmpeg -i - ...
[23:43:14 CEST] <carli> One other question, for streaming mp4 file to rtmp size: Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 4218 kb/s, 25 fps, 25 tbr, 25k tbn, 50 tbc (default), what are CPU requirements ?
[23:43:41 CEST] <kepstin> carli: you don't need to re-encode that, so cpu requirements are minimal
[23:44:30 CEST] <Mavrik> yeah, no point in reencoding that
[23:45:23 CEST] <carli> Damn so I need to find out what takes my CPU to the sky ...
[23:45:27 CEST] <carli> Thanks!
[23:46:48 CEST] <kepstin> carli: if you're not using -c:v copy, it will re-encode it... you need to show us your complete command line if you want more help :)
[23:48:41 CEST] <carli> kepstin: ye here is the line: ffmpeg -re -i inputfile.mp4 -f flv -vcodec libx264 -r 20 -c:a libfdk_aac -b:a 128k -ac 2 rtmp://server.com
[23:49:24 CEST] <carli> I tester with 10fps and it's the same thing ..
[23:49:28 CEST] <carli> tested even
[23:50:06 CEST] <llogan> the encoding is what makes your CPU work so hard
[23:51:09 CEST] <carli> flv or ?
[23:52:07 CEST] <relaxed> you can copy the audio/video streams while only changing the container
[23:52:24 CEST] <relaxed> ffmpeg -re -i inputfile.mp4 -f flv -c copy rtmp://server.com
[23:52:27 CEST] <petecouture> I think you can just copy each codec instead of reencoding. Seems like a waste there
[23:52:31 CEST] <petecouture> damn relaxed beat me to it
[23:53:41 CEST] Action: relaxed holsters
[23:54:10 CEST] <carli> Let me test this ..
[23:54:18 CEST] <carli> Thanks!
[23:55:48 CEST] <carli> Huh! It works, so it's better that I convert other files before stream!
[23:55:56 CEST] <carli> Thank you all!
[23:56:09 CEST] <relaxed> you're welcome
[00:00:00 CEST] --- Wed Mar 30 2016


More information about the Ffmpeg-devel-irc mailing list