[01:00:53 CET] <ariyasu> Tue Jan 01 00:00:51 2019 [01:00:59 CET] <ariyasu> happy new year #ffmpeg [01:20:07 CET] <Tachyon> hny! :) [01:49:11 CET] <pomaranc> Tachyon: no [06:20:30 CET] <hungrywolf> does any one know any good tutorial on making a video player using ffmpeg? [06:21:03 CET] <hungrywolf> http://dranger.com/ffmpeg/tutorial01.html << this looks like a good one, but I am seeing many errors when I type in the code [14:27:12 CET] <hungrywolf_> can some one tell me what is the best resource for learning ffmpeg working with c++ [15:32:25 CET] <Reventlov> Hi. How to escape filenames to allow ffmpeg to use them? [15:32:46 CET] <Reventlov> (in a zsh function, e.g. force_subs() { ffmpeg -i "$@" -vf subtitles="$@" "forced_$@"; } ) [15:34:23 CET] <c_14> in the filter with single quotes [15:35:26 CET] <Reventlov> it seems it's not working as expected (still gives error when executed) [15:35:40 CET] <c_14> what error? [15:35:51 CET] <Reventlov> (what do you mean exactly? replace subtitles="$@" with what?) [15:36:23 CET] <c_14> subtitles=\'"$@"\' probably [15:40:11 CET] <Reventlov> well, yeah, thank you c_14 [15:40:14 CET] <Reventlov> bye [16:03:59 CET] <dv_> uh, terminology question. "frame dropped" vs "frame skipped", both during decoding, is there any meaningful difference? it sounds to me like a frameskip is a planned event, like skipping altref VP8 frames, while a framedrop is something unexpected, for example due to corrupted frames. [16:13:15 CET] <DHE> frames can be dropped for legit reasons as well. if you're reducing the framerate, those can be dropped frames. [17:24:27 CET] <dv_> DHE: yeah, but I am solely looking at frame skipping/dropping in a *decoder* [17:30:22 CET] <DHE> you mean the AVCodecContext specifically as opposed to ffmpeg? [17:34:18 CET] <dv_> I mean in general, not specifically ffmpeg [17:34:41 CET] <dv_> I keep reading about frameskipping and framedropping in decoders, and I wonder about their de facto meaning [17:35:09 CET] <dv_> the only distinction I found was that, as said, skipping = planned, normal ; dropping = abnormal, typically because of corrupted frames [17:48:11 CET] <DHE> oh... well, when you're trying to do realtime decoding (ie video playback) and you can't keep up - presumably because CPU is insufficient - something has to give. Maybe you skip drawing the frame on the screen, maybe you skip decoding entirely for some frames and hope to recover some other way (wait for a new keyframe?) [17:48:54 CET] <DHE> one interpretation might be skipping = not rendered on screen, dropped = not given to the decoder at all [17:52:37 CET] <iive> yes, libavcodec support such type of decode skipping. it could be tuned. e.g. skip only frames that are not used for reference (B-Framces) [17:53:01 CET] <iive> skip also forward reference frames (P-Frames).. [17:53:45 CET] <iive> you can also skip only parts of decoding e.g. skip loopfilter (internal codec post-processing). [18:09:31 CET] <DHE> right, but in this channel most people think either in terms of real-time encoding or non-realtime transcoding where decoding is largely irrelevant in the grand scheme of things [22:28:30 CET] <Celmor> how does ffmpeg decide parameters when I omit them? Usually it seems re-encoding downloaded files like for example a twitch vod makes them significantly smaller but I'm not sure how much quality I'd lose [22:29:02 CET] <BtbN> It uses whatever is set as default for the omitted parameter [22:29:06 CET] <BtbN> usually the defaults are bad [22:33:06 CET] <Celmor> so I assume quality loss would be significant? [22:34:56 CET] <Celmor> join #awk [22:35:00 CET] <Celmor> oops [22:35:06 CET] <furq> the defaults for mkv and mp4 are ok [22:35:11 CET] <furq> not good but ok [22:35:25 CET] <BtbN> Depends on the version [22:35:33 CET] <BtbN> it used to be like 200kbit or something [22:35:33 CET] <pink_mist> I thought the fileending has nearly no bearing on the quality of the encoding [22:35:38 CET] <furq> i'm assuming you have a version from the last couple of years with libx264 [22:35:39 CET] <BtbN> and was changed to some crf mode recently [22:35:40 CET] <furq> which most people do [22:36:09 CET] <furq> pink_mist: it has a bearing on what encoders ffmpeg picks [22:36:12 CET] <furq> by default [22:38:07 CET] <Celmor> I'm simply converting stream "dumps" from twitch, mp4 -> mp4, since the bitrate often is constantly unnecessarily around 5k I often get huge decrease in file size if I re-encode the file, omitting any parameters like -c, using latest version and default h264 transcoders [22:40:20 CET] <BtbN> Twitch is using a lot of filler to keep the bitrate constant. Just re-muxing their raw mpeg-ts to mp4 without re-encoding will shrink it. [22:42:44 CET] <Celmor> does "-c copy" also remux? [22:43:16 CET] <Celmor> till now I only experiences decrease in output file size if I omitt the "copy" for the codec [22:43:59 CET] <arejay> i have a .mkv file which consists of both 1080 and 720 resolution frames. curious if there a way ffmpeg can remove all the 1080 frames from the video file [23:27:29 CET] <DHE> arejay: you'll have to figure out which streams are the ones you want to keep (say, 0:0 and 0:2 (video and audio)), then: ffmpeg -i input.mkv -map 0:0 -map 0:2 -c copy output.mkv [23:28:03 CET] <DHE> "ffprobe input.mkv", or "ffmpeg -i input.mkv", will provide a summary of the input file which should be sufficient [23:54:59 CET] <arejay> DHE: dude, thank you!! exactly what i needed [00:00:00 CET] --- Wed Jan 2 2019