[00:08:35 CET] <SortaCore> what would affect a file's duration and framerate, but not its playing speed? [00:22:51 CET] <klaxa> a rip in space-time [00:32:21 CET] <thebombzen> SortaCore: what do you mean "playing speed" [00:32:43 CET] <SortaCore> In VLC it plays at normal speed, the video is of a camera feed with time in it [00:33:05 CET] <thebombzen> what are you trying to accomplish [00:33:11 CET] <SortaCore> but VLC shows a framerate that's much lower than the camera actually is, and a duration far higher [00:33:23 CET] <SortaCore> copying H264 from RTSP stream to MP4 container, without transcoding [00:33:33 CET] <thebombzen> why not just use ffmpeg [00:33:35 CET] <thebombzen> and not VLC [00:33:57 CET] <SortaCore> oh, you misunderstood [00:34:05 CET] <SortaCore> when I playback the MP4 in VLC, it comes up like that [00:34:09 CET] <thebombzen> also, recording to mp4 is a bad idea. you should probably record to mpegts, and then remux to mp4 later. [00:34:56 CET] <thebombzen> mp4 is not designed for anything realtime at all [00:35:18 CET] <SortaCore> it's not going to be played back immediately [00:35:25 CET] <SortaCore> it's just recording it without transcoding [00:35:31 CET] <thebombzen> doesn't matter, don't record a realtime stream to mp4 [00:35:52 CET] <SortaCore> mpeg-ts is mpg? [00:35:56 CET] <thebombzen> mpegts is mpegts [00:36:02 CET] <thebombzen> .ts is the usual file extension [00:36:15 CET] <thebombzen> either way: [00:36:33 CET] <SortaCore> I'm using C++, not the commandline [00:36:42 CET] <thebombzen> either way, I wouldn't trust VLC [00:36:54 CET] <thebombzen> what is the reported framerate of the mp4 file if you use: ffmpeg -i recording.mp4 [00:37:35 CET] <SortaCore> stand by one, houston [00:45:30 CET] <SortaCore> https://pastebin.com/raw/D4YGZ8ag [01:11:07 CET] <Aatch> Hi, I have a thread-safety question: [01:12:27 CET] <Aatch> When using send_packet/recieve_frame, is it possible to have one thread call send_packet until it sees EAGAIN, and have another thread call recieve_frame until it sees EAGAIN? [01:13:07 CET] <DHE> as long as you hold a lock (you provide your own) while calling the functions in each thread, sure [01:13:35 CET] <DHE> obivously the same lock... [01:15:39 CET] <Aatch> DHE: Thanks [01:16:56 CET] <Aatch> A related question: how much (if at all) do video codecs buffer frames? i.e. should I expect an EAGAIN after sending one packet (assuming no recieve_frame between them). [01:17:58 CET] <DHE> that is highly dependent on the codec and its settings. x264 could buffer 60 frames or more with default settings, or none if you av_dict_set(&dict, "tune", "zerolatency", 0); [01:18:36 CET] <DHE> not that I would encourage zerolatency mode [01:21:01 CET] <Aatch> Hmm, so I probably shouldn't rely on there being a buffer, but I can probably get away abusing the codec's for the proof-of-concept I'm doing. Thanks! [01:22:58 CET] <SortaCore> ffmpeg.exe rtsp -> mp4 results in frame= 2169 fps=5.4 q=-1.0 size= 23040kB time=00:06:55.03 bitrate= 454.8kbits/s speed=1.03x [01:52:06 CET] <SortaCore> thebombzen: does any of that help ya [01:55:39 CET] <thomedy> okay im begging someone for help [01:55:57 CET] <thomedy> im trying to include ffmpeg as an external library into my c++ program on mac osx 8 [01:56:07 CET] <thomedy> any mac developers [02:01:49 CET] <SortaCore> thomedy: this is IRC so help may take several hours [02:03:04 CET] <thomedy> well i am subject to my frustrations anyway... are you available now? [02:03:26 CET] <SortaCore> I know nothing about mac [02:03:49 CET] <thomedy> dude im stumpped [02:04:09 CET] <thomedy> this shouldn't be this hard but i dont think im doing anything crazy its just not working [02:05:01 CET] <SortaCore> you've compiled it for shared library then? [02:05:47 CET] <thomedy> i did brew install [02:06:02 CET] <thomedy> so i let home brew build it.. im downloading the srccode now to try that [02:09:11 CET] <kepstin> for c++ the thing to note is that ffmpeg is a C library, so you're gonna have to put extern "C" {} around the header includes, other than that, just use pkg-config for compiler and linker flags (homebrew should set that up, I think, although i'm not a mac user...) [02:09:36 CET] <thomedy> there is a pkg_config in my folder [02:09:44 CET] <thomedy> and so that means i need extern "c" [02:09:46 CET] <thomedy> to include [02:09:52 CET] <thomedy> and #include < wont work [02:09:56 CET] <thomedy> is that what your saying [02:10:03 CET] <thomedy> i will have to google pkg-config [02:10:22 CET] <thomedy> everything is so outdated or swift/objective c related [02:10:37 CET] <kepstin> you still use #include, but you have to wrap it inside an extern "C" {} block so the compiler knows it's a C include, not C++ [02:14:16 CET] <garyserj> kepstin: thanks [02:26:16 CET] <thebombzen> SortaCore: that says it's 6 frames per second. is the video supposed to be 6 frames per second? [02:28:31 CET] <SortaCore> yep [02:29:00 CET] <SortaCore> but the pastebin has a far higher duration [02:29:15 CET] <SortaCore> I record for about 30 seconds or so and it turns it into 21 minutes and greater [02:39:05 CET] <thebombzen> SortaCore: it sounds like you're probably writing the PTS incorrectly [02:39:30 CET] <thebombzen> or somehow your implementation isn't correctly writing the file [02:39:41 CET] <thebombzen> as for how to do it properly? I have no idea, I dont' use the API [02:39:43 CET] <DHE> timebase mismatch maybe? [03:42:14 CET] <Netun0> Hi, I'm streaming OK but my problem is audio.. will it be possibile in near future to just repeat a audio in ffmpeg? [04:04:11 CET] <SortaCore> DHE: the time base is set to the RTSP stream's one, 1/90000 [04:04:23 CET] <SortaCore> but I am manually setting the PTS/DTS to framenum++ [04:05:15 CET] <SortaCore> then I do av_packet_rescale_ts on video container time base and video file stream timebase, then multiply both DTS and PTS by two [04:05:54 CET] <SortaCore> I came up with this method after a good while of strugging to get libx264 to work without complaining about non-monotonic DTS [04:06:20 CET] <SortaCore> works fine in h264_qsv too, just copy without transcode that's messed up [04:23:09 CET] <Johnjay> hmm ok [05:45:10 CET] <SortaCore> without pts/dts manually set, I get Application provided invalid, non monotonically increasing dts to muxer in stream [08:27:36 CET] <dradakovic> i have ffmpeg running and working fine. But i would like some sort of monitorin to see if specific multicast from it is still active or did it drop. Can i do that locally with ffprobe? I cant seem to join my local ffmpeg streams. I can join the streams from anywhere else on the network [08:28:05 CET] <dradakovic> I can see it active with tcpdump but i wanted to make a script to check for activity [08:28:21 CET] <dradakovic> cant put tcpdump in a script. SO ffprobe would be fine [09:00:32 CET] <hendry> hi, i'm trying to create a webp thumbnail like Youtube does it, but `ffmpeg -i ~/media/out/2017-12-17/MVI_6940.MP4 -vf scale=320:240 -vf fps=1 out.webp` scaling doesn't seem to work. Any ideas where I am going wrong ? [09:37:06 CET] <jkqxz> hendry: You can't give it multiple "-vf" options (it just uses the last one). Combine them into a single filter chain as "-vf scale=320:240,fps=1". [09:38:11 CET] <hendry> jkqxz: ah [10:51:35 CET] <SortaCore> DHE/JEEB: any suggestions for keeping a good dts/pts for RTSP H264? Without setting them relative to frame number, I get complaints about non-monotonic increasing DTS when copying the H264 straight from rtsp demuxer to mp4 muxer [10:52:23 CET] <SortaCore> setting frame number works fine in non-copy and copy, but in copy the duration of the file is completely wrong, 21 mins or greater for a half-minute file [10:52:31 CET] <SortaCore> (copy being no transcode) [11:08:15 CET] <Nacht> Hmm. I always thought an IDR frame should have a PPS and SPS accompanying it. [12:13:11 CET] <SortaCore> is there a reason GitHub needs to keep a HTTPS connection open constantly in the background :p [12:16:11 CET] <jrabe> are you referring to the websocket connection? [12:18:40 CET] <BtbN> Isn't it pretty common to keep the http connection open? So it doesn't have to be re-established the next time [12:21:06 CET] <zash> Don't browsers keep like a ton of connections open? [12:21:34 CET] <jrabe> they do, and GitHub also uses websockets to push live updates (for example if someone adds a new comment to an issue you have open) [12:34:04 CET] <SortaCore> yea, keeping connections open while the user has the tab open... or even had it open in the last hour or so... [14:59:12 CET] <DHE> SortaCore: it also dynamically tracks the little notification icon. so yeah... [15:59:00 CET] <alexpigment> does anyone know what the use case is for xHE-AAC? [16:03:47 CET] <alexpigment> nm, ignore the last question. what exactly is the difference between MPEG-2 AAC and MPEG-4 AAC? [16:04:01 CET] <alexpigment> can I use MPEG-2 AAC inside an MPEG-4 container? [16:05:33 CET] <DHE> the ".mp4" file format largely has nothing to do with the "MPEG" family of codecs [16:06:18 CET] <alexpigment> well, if I'm using the native AAC encoder in FFMPEG to create MPEG-4 files with H.264 + AAC, am I using MPEG-2 AAC or MPEG-4 AAC? [16:07:03 CET] <atomnuker> mpeg4 [16:07:27 CET] <alexpigment> is there a way to create MPEG-2 AAC instead within FFMPEG? [16:08:16 CET] <atomnuker> yes, -profile mpeg2_aac_low [16:08:41 CET] <atomnuker> -profile:a mpeg2_aac_low [16:08:43 CET] <alexpigment> awesome. is there any noticeable change in quality? any loss in compatibility? [16:09:13 CET] <atomnuker> yes, there'll be a slight loss in quality, there should be an increase in compatibility [16:09:34 CET] <alexpigment> would 160kbs still be relatively transparent though? [16:09:36 CET] <alexpigment> er [16:09:38 CET] <alexpigment> kbps [16:09:38 CET] <atomnuker> yes [16:09:45 CET] <alexpigment> that's what I needed to know [16:09:47 CET] <alexpigment> thanks atomnuker [16:12:01 CET] <Kingsy> I have a video file, 1080p mkv h264 and when I play it on a blu ray player via usb its jumpy. Works fine on my compujter. What would be the bestway to re-encode it via ffmpeg so it plays smooth on the player? [16:14:15 CET] <alexpigment> Kingsy: what's the frame rate? what's the bitrate? [16:15:09 CET] <Kingsy> one second [16:16:35 CET] <Kingsy> alexpigment: 23.976 fr [16:16:41 CET] <alexpigment> that should be fine [16:16:45 CET] <alexpigment> what's the bit rate and level [16:16:59 CET] <Kingsy> 1536kb/s [16:17:05 CET] <Kingsy> not sure what you mean by level [16:17:07 CET] <alexpigment> that's the audio bit rate presumably [16:17:17 CET] <alexpigment> PCM stereo audio I'm guessing? [16:18:04 CET] <alexpigment> anyway, here's what I'd recommend: [16:18:26 CET] <alexpigment> ffmpeg -i [infile] -c:v copy -c:a aac output.mp4 [16:18:42 CET] <Kingsy> alexpigment: the audio is DTS [16:18:54 CET] <alexpigment> if it's still jumpy, there's something about the video stream that's creating the problem [16:19:10 CET] <alexpigment> if it plays fine, then it was either a) the MKV container or b) the audio track(s) [16:19:21 CET] <Kingsy> could it be because its DTS? [16:19:32 CET] <Kingsy> the content bitrate is roughly 4000 kb/s [16:19:33 CET] <alexpigment> DTS could be a problem within an MKV container, I suppose, though the player should almost certainly support DTS on a Blu-ray disc [16:19:35 CET] <Kingsy> but it varies [16:19:57 CET] <Kingsy> alexpigment: can we convert that too with ffmpeg [16:20:09 CET] <Kingsy> I don't care if its DTS as long as its reasonable [16:20:13 CET] <alexpigment> yeah, that's what the command I did above does [16:20:15 CET] <Kingsy> just to try and cover all bases. [16:20:29 CET] <alexpigment> it's converting only the audio to AAC and putting it in a more standard MP4 container [16:20:37 CET] <alexpigment> and leaving the video untouched [16:20:52 CET] <Kingsy> ah ok! is it worth scaling it down to 720p incase its the software decoder ont he device? [16:21:06 CET] <alexpigment> Kingsy: I doubt it [16:21:27 CET] <alexpigment> re-encoding the video is time consuming and will generally cause loss in quality [16:21:43 CET] <alexpigment> converting the audio from DTS to AAC will probably be unnoticeable to most people [16:21:47 CET] <Kingsy> thats true I suppoed. but the goal is to get it to be smooth and watchable. [16:22:01 CET] <Kingsy> if its jumpy it wont cut it [16:22:14 CET] <Kingsy> so a loss in quality if it makes it smooth is fine really. 720p is still decent [16:22:21 CET] <Kingsy> but if you say it wont matter than I beelive you [16:22:23 CET] <alexpigment> Kingsy: please try the command I listed above [16:22:27 CET] <Kingsy> I know nothing about this stuff [16:22:28 CET] <Kingsy> ok [16:22:38 CET] <alexpigment> let me know what you find and we'll go from there [16:22:48 CET] <alexpigment> it should be a very quick test [16:24:07 CET] <Kingsy> alexpigment: thanks! I will try it tonight, will you be around tomorrow same tiem? I will let you know what happens :) [16:25:16 CET] <alexpigment> most likely. if I'm not, just re-ask the question and say that you've ruled out the audio and the container as being problematic [16:27:37 CET] <Kingsy> ok great. Thanks so much! [16:28:48 CET] <alexpigment> np [16:33:44 CET] <Nacht> Is it possible to get 'showspectrumpic' to only draw certain freq (bandwidth) ? I'm only intrested in 200hz to 500hz [16:39:42 CET] <alexpigment> atomnuker: is there a way to tell in the resultant stream if MPEG-4 AAC or MPEG-2 AAC is being used? [16:44:42 CET] <alexpigment> when specifying -profile:a mpeg2_aac_low , i get the following warning: "PNS unavailable in the "mpeg2_aac_low" profile, turning off" [16:45:03 CET] <alexpigment> i'm not sure if that means *turning off PNS* or *turning off mpeg2 aac low profile* [16:45:17 CET] <alexpigment> and I can't figure out a way to verify either one [16:58:08 CET] <kepstin> turns off PNS: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/aacenc.c;h=fa7932... [16:58:47 CET] <alexpigment> that's what I thought. i just can't figure out a way to tell that the stream is actually MPEG-2 AAC LC [17:05:11 CET] <alexpigment> anyway, I guess it's relevant to point out that MPEG-2 AAC LC's royalty payments are no longer needed as of Dec 4, 2017 [17:05:25 CET] <atomnuker> alexpigment: the only difference between mpeg4 aac and mpeg2 aac is that PNS isn't available in mpeg2 aac [17:05:28 CET] <alexpigment> but MPEG-4 AAC LC and other variants still require royalties [17:05:49 CET] <atomnuker> so pns is turned off if you use the mpeg4 aac profile [17:06:01 CET] <alexpigment> atomnuker: that's my understanding as well. I just am looking for something to say "MPEG-2 AAC LC" when looking at the file [17:06:09 CET] <atomnuker> not possible [17:06:14 CET] <alexpigment> ok [17:06:33 CET] <alexpigment> well, I guess that's what I needed to know [17:06:35 CET] <atomnuker> in fact, pns should be ignored by any mpeg2 decoders [17:07:08 CET] <atomnuker> one person did complain that an early-2000 home cinema player didn't decode it correctly with pns so I added that profile switch [17:07:38 CET] <alexpigment> well, it's good to know I'm talking to the right person then :) [17:07:40 CET] <atomnuker> I guess that decoder must have been non-compliant as it didn't ignore it [17:08:03 CET] <alexpigment> a non-compliant decoder? surely not... :) [17:08:23 CET] <atomnuker> in an early 2000s hardware decoder? its more likely than you'd think [17:08:35 CET] <alexpigment> I was making a joke [17:09:07 CET] <atomnuker> I know :) [17:09:39 CET] <alexpigment> so is PNS just a flag that tells the decoder to add noise? [17:10:51 CET] <atomnuker> more than that, high frequencies (e.g. from cymbals or "S" from human voice) is essentially just noise [17:11:03 CET] <atomnuker> noise is hard to encode normally [17:11:43 CET] <atomnuker> so PNS allows you to skip coding expensive coefficients and just replace them with white noise [17:11:57 CET] <alexpigment> ok, so there is an actual difference in the encoder then [17:12:25 CET] <alexpigment> "replace all open hi hats with white noise" [17:12:53 CET] <alexpigment> those are the hardest things to encode in my experience [17:13:23 CET] <alexpigment> i can hear 'watery' sounds in open hi hats in most lossy streams [17:14:29 CET] <atomnuker> yeah, that's spectral leakage, its what happens when the frequencies spread out, both in the time domain (lapped transforms) and frequency domain (quantization) [17:14:50 CET] <alexpigment> interesting [17:15:02 CET] <atomnuker> opus solved this issue by using cleverer quantization so its cheap to code noise, but opus has troubles with tones [17:15:37 CET] <atomnuker> thankfully the tone disadvantage is less than the disadvantage of not being able to code noise efficiently so that's part of why opus is so good [17:16:13 CET] <alexpigment> ah [17:17:45 CET] <alexpigment> well, back to the original point, it might be interesting to others to know that using -profile:a mpeg2_aac_low can save a company money [18:03:07 CET] <termos> calling av_buffersrc_add_frame_flags on full hd frames is taking a lot of memory bandwidth, especially if done multiple times into different filter graphs. My "routing thread" that pushes frames into different filter+encoding threads eat a lot of time. Is there a way around this? [18:12:53 CET] <ritsuka> alexpigment: why would it save money? [18:13:37 CET] <alexpigment> ritsuka: because the patent fees for MPEG-2 AAC LC went away on December 4th [18:13:56 CET] <alexpigment> MPEG-4 AAC LC fees still in effect until 2023 for most countries [18:17:44 CET] <DHE> termos: are you using reference counted frames? it eliminates the need for copying when frames are passed around. especially if you have a split call in your filtergraph [18:18:45 CET] <termos> hm, no split call, it's several different filter graphs so I don't think I can use ref counted frames as all the filter graphs can't filter the same frame data [18:19:02 CET] <atomnuker> termos: are your frames refcounted/ [18:21:55 CET] <termos> no they are not [18:25:02 CET] <termos> it works well if I have 4-5 encodings, but when it get close to 15 output resolutions there are issues. Doing some proxy scaling before pushing to lower resolution filter graphs lowers the time spent copying by a lot, but still not sufficient. Just wondering if this is a solved problem [18:26:02 CET] <DHE> if you reference count the frames then the AVFrame effectively is read-only but the same memory is used for all of them. you really should be doing that. [19:13:00 CET] <alexpigment> i've got a weird one that I could use some help with [19:13:30 CET] <alexpigment> in the past, I've used a patch to x254's encoder.c file to limit the number of threads that it automatically calculates to 16 [19:13:38 CET] <alexpigment> this helps on systems with low amounts of RAM [19:14:03 CET] <alexpigment> anyway, trying to rebuild today and when the patch is in place, I get lots of errors [19:14:23 CET] <alexpigment> patch: https://pastebin.com/3LKzChCj [19:14:28 CET] <DHE> number of threads shouldn't have that big an impact on RAM usage. lookahead is going to consume WAY more memory [19:14:31 CET] <alexpigment> errors: https://pastebin.com/QaJYFYcD [19:14:43 CET] <DHE> line 8 has a misbalanced number of parens [19:14:55 CET] <alexpigment> oh :) [19:14:58 CET] <alexpigment> well, there's that [19:15:03 CET] <alexpigment> I was copying and pasting from an older patch [19:15:21 CET] <alexpigment> I guess that somehow got changed. Thank you for noticing that [19:18:17 CET] <alexpigment> DHE: i believe the lookahead threads is based on the max threads value [19:18:42 CET] <alexpigment> in which case, I think this effectively does the same thing [19:19:21 CET] <DHE> it's not number of threads. it's number of frames. x264 effectively stores uncompressed frames in memory up to the requested number (assuming nothing caps it) [19:20:16 CET] <alexpigment> oh you're talking about the rc_lookahead value [19:20:27 CET] <alexpigment> I believe I already cap that for certain resolutions [19:21:02 CET] <alexpigment> but either way, capping the threads as I'm doing is very much the difference between being able to encode 4k and not [19:21:34 CET] <alexpigment> especially if you have a processor with 16 logical cores [19:47:07 CET] <alexpigment> atomnuker: do you know of an easy way to force -profile:a mpeg2_aac_low for all AAC encoding? editing the source is a lot easy for me than editing all my generic -c:a aac calls to ffmpeg [19:47:54 CET] <atomnuker> change {"aac_pns", "Perceptual noise substitution", offsetof(AACEncContext, options.pns), AV_OPT_TYPE_BOOL, {.i64 = 1}, [19:47:58 CET] <atomnuker> to {"aac_pns", "Perceptual noise substitution", offsetof(AACEncContext, options.pns), AV_OPT_TYPE_BOOL, {.i64 = 0}, ... [19:48:34 CET] <alexpigment> is that in aacenc.c? [19:48:40 CET] <atomnuker> yes [19:48:42 CET] <alexpigment> awesome [19:48:45 CET] <alexpigment> thank you very much [19:48:46 CET] <atomnuker> or "if (avctx->profile == FF_PROFILE_MPEG2_AAC_LOW)" to if (1) [19:49:59 CET] <alexpigment> the former seems easy enough [19:50:03 CET] <alexpigment> thanks again [19:50:52 CET] Action: therage3 blinks [20:07:51 CET] <sm_> hi, i'm trying to use ffmpeg to pull images from a video every minute. this works fine but when i try to scale the images down, the ffmpeg command doesn't work. [20:07:58 CET] <sm_> https://pastebin.com/iG44cbBg [20:08:29 CET] <sfan5> pastebin the output too [20:11:24 CET] <sm_> output: https://pastebin.com/gyjUWiA2 [20:12:15 CET] <sfan5> i don't see an error message there [20:12:33 CET] <sfan5> in any case don't pass vf twice and use -vf fps=1/60,scale=320:180 instead [20:12:51 CET] <sm_> sorry I wasn't clear. no error message comes up but the output seems like it's outputting every single frame - not one every minute [20:12:55 CET] <sm_> Ok i can try that [20:15:08 CET] <sm_> @sfan5 passing in vf once looks like it fixed my issue, thank you [21:38:04 CET] <saml> how can I cut a video file without re-encoding? [21:38:21 CET] <saml> by googling. thanks [21:39:12 CET] <alexpigment> saml: did you answer yourself in your second line or what? [21:39:21 CET] <saml> yup i did [21:39:24 CET] <alexpigment> ok [21:39:35 CET] <saml> -vcodec copy -acodec copy -ss [21:39:47 CET] <alexpigment> yeah [21:40:07 CET] <alexpigment> one thing to note is that it may not be frame-accurate depending on the gop length of your original video [21:40:26 CET] <alexpigment> i'm pretty sure you can only cut at I-frames [21:40:46 CET] <alexpigment> anything else requires a smartcutter like VideoRedo [21:40:58 CET] <saml> ah i see. i just wanted to cut this 5GB file to something under 1MB where there's problem with ffmpeg [21:41:04 CET] <alexpigment> ah [21:41:09 CET] <alexpigment> should be fine then [21:41:18 CET] <saml> ffmpeg fails at certain point of the video with a bunch of errors. i wanted to isolate so i can show you :P [00:00:00 CET] --- Wed Dec 20 2017