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

[burek]

[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