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

[burek]

[02:18:27 CEST] <giaco> hello
[12:38:18 CEST] <analogical> how do I use FFmpeg to demux a video file into separate audio and video streams?
[12:40:39 CEST] <DHE> as in the cli tool?
[12:40:53 CEST] <analogical> yeah
[12:41:33 CEST] <DHE> and you want, what, an mp4 file for each stream individually
[12:42:35 CEST] <analogical> I want a for each stream individually regardless of format
[12:42:54 CEST] <analogical> *I want a file for each stream individually regardless of format
[12:43:16 CEST] <DHE> well you are going to have to choose a file format. mp4, ts, mkv, what?
[12:44:31 CEST] <analogical> I don't really need the individual streams to be stored in containers
[12:46:55 CEST] <DHE> well they do have to be stored somehow. and most codecs don't properly support being stored raw, or at least lose some important information like framerate
[12:50:22 CEST] <furq> analogical: http://vpaste.net/8M8hk
[12:50:31 CEST] <furq> i don't necessarily recommend using it for the reasons DHE just said
[12:50:55 CEST] <furq> also line 5 isn't comprehensive at all
[12:51:31 CEST] <furq> mkvextract will do the same thing if your source is mkv
[12:53:08 CEST] <analogical> yes mkvextract is limited to mkv files so that's why I wanted to use FFmpeg for other formats
[12:53:24 CEST] <analogical> but it seed?s a little too complicated
[12:53:27 CEST] <analogical> *seems
[12:53:58 CEST] <DHE> something like: ffmpeg -i input.mp4 -c copy -map 0:0 stream1.mp4 -c copy -map 0:1 stream2.mp4
[12:54:12 CEST] <DHE> of course this assumes mp4-friendly streams, etc
[12:55:38 CEST] <analogical> is there a way to make FFmpeg list the different streams that a stored in a file?
[12:55:57 CEST] <DHE> ffprpobe
[12:56:15 CEST] <DHE> or if not available "ffmpeg -i input.mp4" will mostly do the same job, but show errors on the way out
[12:56:24 CEST] <DHE> *ffprobe
[17:58:51 CEST] <Anton-Latukha> Good day, guys, my pull request is stalled, because FFMpeg seems not to have x264 log functionality, to do encoding analyze of x264. Or I just was looking not there.
[17:58:56 CEST] <Anton-Latukha> If someone knows how to get x264 log report from FFMpeg. And it is not `-vmstats`.
[17:59:04 CEST] <Anton-Latukha> I need to get this type of log from FFMpeg:
[17:59:12 CEST] <Anton-Latukha> ```
[17:59:12 CEST] <Anton-Latukha> x264 [info]: mb I  I16..4: 17.9% 68.9% 13.2%
[17:59:12 CEST] <Anton-Latukha> x264 [info]: mb P  I16..4:  9.2% 12.1%  0.6%  P16..4: 40.4%  5.6%  6.7%  0.1%  0.0%    skip:25.2%
[17:59:12 CEST] <Anton-Latukha> x264 [info]: mb B  I16..4:  0.9%  1.1%  0.1%  B16..8: 36.7%  2.7%  0.5%  direct: 2.1%  skip:55.9%  L0:44.6% L1:52.5% BI: 3.0%
[17:59:12 CEST] <Anton-Latukha> ```
[17:59:44 CEST] <Anton-Latukha> https://en.wikibooks.org/wiki/MeGUI/x264_Settings/x264_Stats_Output
[17:59:44 CEST] <Anton-Latukha> Because I need to emulate real environment of Open Source project (that uses FFMpeg encoding).
[18:00:03 CEST] <furq> uh
[18:00:11 CEST] <furq> you should get that once encoding is finished
[18:01:03 CEST] <Anton-Latukha> Oh boy. I am blind.
[18:01:31 CEST] <Anton-Latukha> Sorry. Thank you @furq
[18:27:21 CEST] <hans_> i want to scan through an entire video, and anywhere the frame doesn't change for over 2 seconds, i want to cut till the next frame change after 2 seconds, any suggestions on how?
[18:30:54 CEST] <DHE> you probably want the decimate filter. it will turn duplicate frames into variable FPS video
[18:31:32 CEST] <DHE> hmm.. not quite the same as it was back in the mplayer days...
[18:32:52 CEST] <hans_> will the decimate filter actually alter playback time, or will it just decrease the filesize?
[18:55:32 CEST] <Hello71> DHE: mpdecimate
[19:09:18 CEST] <^Neo> I feel like this is a stupid question, but if you change the aspect ratio of video, but keep the resolution size the same, does the actual storage size change?
[19:09:35 CEST] <^Neo> i.e. 720x480 @ 4:3 is "smaller" than 720x480 @ 16:9?
[19:11:09 CEST] <JEEB> no
[19:11:30 CEST] <JEEB> when you're encoding something the video complexity affects things, the aspect ratio is just a flag
[19:11:37 CEST] <JEEB> it controls playback only
[19:11:39 CEST] <^Neo> yes, that's what I figured
[19:11:45 CEST] <^Neo> my colleagues were thinking otherwise
[19:11:50 CEST] <^Neo> which made me question my own sanity
[19:14:09 CEST] <DHE> unless you accidentally transcode when trying to change the aspect ratio in which case all bets are off for file size
[19:15:07 CEST] <atomnuker> you should really eliminate any non-square pixels though
[19:15:15 CEST] <atomnuker> you're transcoding anyway
[19:15:42 CEST] <atomnuker> higher resolution at lower bitrate should beat lower resolution at higher bitrate but scaled
[19:18:14 CEST] <JEEB> I generally do that in the cases where I downscale (1440x1080 broadcast to 1280x720 encode), but with DVDs etc I generally just crop and set the SAR
[19:18:43 CEST] <atomnuker> 1440x1080 broadcast? wat
[19:18:50 CEST] <JEEB> yes, Japanese terrestial is 99% that
[19:18:53 CEST] <atomnuker> that's not a standard I've heard of
[19:18:58 CEST] <JEEB> there's like two channels that are 1920x1080
[19:19:04 CEST] <JEEB> because they're using 12mbps MPEG-2 Video
[19:19:09 CEST] <JEEB> so they do anamorphic 1080i
[19:19:10 CEST] <JEEB> lol
[19:19:12 CEST] <atomnuker> oooh, they stretch that to 1920
[19:19:16 CEST] <JEEB> yup
[19:19:18 CEST] <JEEB> to save 'em bits
[19:19:42 CEST] <JEEB> and either the kyoto broadcast station is really, really shitty in encoders, or it really makes a difference
[19:19:50 CEST] <JEEB> because KBS stuff is always shit
[19:20:12 CEST] <JEEB> while all the 1440x1080 channels are at least a wee bit better
[19:20:20 CEST] <atomnuker> what does the kyoto broadcast station have anything to do with it?
[19:20:32 CEST] <JEEB> it's one of the few that does non-anamorphic 1080i
[19:20:38 CEST] <JEEB> and it looks like shit :D
[19:21:34 CEST] <JEEB> so either their encoder is crap, or squeezing to 1440 from 1920 actually helps at 12mbps MPEG-2 Video :)
[19:22:32 CEST] <atomnuker> what do other stations broadcast in if not in 12mbps mpeg2? 6mbps h264?
[19:23:10 CEST] <JEEB> the only terrestial H.264 you will see are the mobile things, which use 1/13 of the bandwidth :) 380x180 at 15/1.001 or so
[19:23:33 CEST] <JEEB> they standardized on MPEG-2 Video in like 2002-2003 or so
[19:23:35 CEST] <DHE> here in canada I've only seen mpeg2 over-the-air broadcasts even at 1080i
[19:23:48 CEST] <JEEB> and then in 2006 they threw the H.264 mobile segment in
[19:24:13 CEST] <JEEB> I think they will only change when they'll start switching to 4K
[19:24:37 CEST] <JEEB> the onl exceptions are some commercial satellite things which are 1440x1080 at 8mbps H.264 I think?
[19:24:44 CEST] <JEEB> like AT-X HD
[19:25:11 CEST] <furq> are you specifically talking about japan here
[19:25:17 CEST] <JEEB> yes
[19:25:21 CEST] <furq> ok good
[19:25:46 CEST] <JEEB> and even there you have now some 4K HEVC stations (which were the first usage of BT.2020 I saw in the wild)
[19:25:50 CEST] <JEEB> like, non-HDR BT.2020
[19:25:59 CEST] <furq> i was going to say i was pretty sure i read finland ota is exclusively dvb-t2 now
[19:25:59 CEST] <JEEB> I had to eat my hat in 2014 because of them :)
[19:26:08 CEST] <atomnuker> I have some wowow live non-anamorphic mpeg2 capture here, is that the other station that doesn't do anamorphic?
[19:26:27 CEST] <JEEB> atomnuker: that's the other type of broadcast/commercial satellite
[19:26:41 CEST] <JEEB> they do ~18mbps MPEG-2 Video at 1920x1080
[19:27:10 CEST] <JEEB> BS-J or BS-NHK are some of the BS ones, and WOWOW is one of the CS ones
[19:27:30 CEST] <JEEB> the difference seems to be on which satellite the stuff is? FTA or non-FTA
[19:28:10 CEST] <JEEB> and yea, AT-X HD is one of the exceptions with H.264. And then like one or two WOWOW channels and 4K Channel with HEVC
[19:28:21 CEST] <JEEB> or was it skyperfecttv
[19:28:26 CEST] <JEEB> I think it was the latter
[19:28:38 CEST] Action: Mavrik is guilty of deploying a live broadcast at 960x1080 :/
[19:28:53 CEST] <JEEB> furq: the DVB-T stuff with 576i is definitely still there. they're afraid of closing that stuff up yet :P
[19:29:58 CEST] <furq> maybe it was just one provider then
[20:12:11 CEST] <ariyasu_> spains sports channels used to broadcast in 1440x1080
[20:12:38 CEST] <DHE> that's 1080p but at 4:3 resolution...
[20:14:09 CEST] <ariyasu_> i think it was anamorphic
[20:14:16 CEST] <ariyasu_> it was stretched to 16:9
[20:14:48 CEST] <furq> there's no need to think it was anamorphic then
[20:16:46 CEST] <ariyasu_> skyperfect tv broadcasts in 2160p
[20:17:24 CEST] <ariyasu_> and they are going to trial a 4320p service in december
[20:17:30 CEST] <JEEB> yea they have one or two 4K channels
[20:18:57 CEST] <Mavrik> HEVC?
[20:19:15 CEST] <JEEB> yup
[20:21:08 CEST] <DHE> unfortunately from a broadcast standpoint that's the only codec they would use. with the possible exception of h264 but I don't know of many TVs or boxes that can handle it
[20:21:38 CEST] <JEEB> just the resolution wise it should be OK, but I think at this point 10bit is kind of wanted for either just BT.2020 or HDR
[20:21:57 CEST] <JEEB> and that is something that the AVC ASICs never really supported out of the "pro intra-only" stuff
[20:24:39 CEST] <DHE> I was thinking more of the Level 5.0 (?) requirement. 4.2 only really goes up to 1080p60
[20:24:50 CEST] <DHE> and maybe I just have cheap hardware but 4.1 is the highest I've seen myself
[20:25:44 CEST] <JEEB> well if you have 4K support at all then it kind of becomes less of an issue because you're having bigger buffers in the hardware anyways
[20:27:13 CEST] <DHE> well yes, but I figured that in terms of macroblocks/second, 1080p60 is equivalent to 2160p15 or something. and who wants 4k if it's at 15fps  ?
[20:27:38 CEST] <JEEB> well you already have more buffers if you support 2160p60 in HEVC
[20:27:55 CEST] <JEEB> but sure, I haven't made any sort of real comparison between many plastic boxes
[21:20:17 CEST] <Hello71> DHE: but muh pixels
[21:20:31 CEST] <Hello71> also people complained for years that 60 fps was too many
[21:22:06 CEST] <DHE> then these people will need to have their heads examined after I kick them in the head
[23:08:02 CEST] <sdfsgsddfhdfh> hi
[23:12:55 CEST] <furq> bye
[00:00:00 CEST] --- Tue Jul 10 2018