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

[burek]

[02:05:01 CEST] <lostquelana> oh, I never remembered to thank you nichego and ln for helping me earlier
[02:05:04 CEST] <lostquelana> thanks you guys
[02:43:56 CEST] <lvella> I have a DVD source with 5.1 ac3 audio, but I believe original source is either mono or stereo
[02:44:19 CEST] <lvella> is there an easy way to know if the tracks were upscaled from mono or stereo?
[02:58:55 CEST] <c_14> Listen to/extract the individual channels and compare them to see if they're the same/extremely similar.
[03:01:23 CEST] <c_14> https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a5.16mono <- you can use that to extract them
[03:23:03 CEST] <qxt> How do I see what the Chroma resolution of a video file is with ffprobe ? Not sure if this file is YUY2 or YU12.
[03:25:07 CEST] <durandal_170> qxt: by inspecting returned format
[03:25:32 CEST] <qxt> -show_format ?
[03:26:49 CEST] <durandal_170> maybe, its pixel format
[03:42:18 CEST] <qxt> pix_fmt=yuv420p is that the chroma resolution?
[03:42:45 CEST] <qxt> this is some old dv tape from like 1991.
[03:43:07 CEST] <qxt> Just dumped it onto my computer using IEEE1394
[03:49:19 CEST] <qxt> I am gonna guess I am retarded and did not see that was YV12. yuv420p is planar 4:2:0 chroma (shared between 2x2 pixels).
[04:02:15 CEST] <qxt> Anybody know of a video frameserver that works with vlc? Need to feed some video to avisynth
[12:54:50 CEST] <Fyr> guys, what is ffmpeg-10bit in Zeranoe's build?
[12:55:12 CEST] <JEEB> probably one linked with 10bit x264
[12:55:30 CEST] <JEEB> since you can only have one bitness built into the encoder (between 8 and 10, although 9 is almost universally unused)
[12:55:56 CEST] <Fyr> interesting
[12:56:56 CEST] <Fyr> does 10-bit change anything to eye?
[12:57:22 CEST] <c_14> depends on the bitrate, if you have relatively low-bitrate content with gradients then yes
[12:58:19 CEST] <furq> 10-bit generally compresses better in my experience
[12:58:32 CEST] <Fyr> cool
[12:58:35 CEST] <JEEB> 10bit is mostly used for the compression benefit. you can think of a compression error of N bit in 8bit width vs 10bit width
[12:58:45 CEST] <furq> you shouldn't use it if you have any compatibility requirements at all
[12:58:50 CEST] <Fyr> furq, how does it compress in comparison with h264?
[12:58:52 CEST] <JEEB> usually people use 8bit for HW decoding compatibility, though
[12:58:54 CEST] <Fyr> *265
[12:59:02 CEST] <furq> i've not used x265 much
[12:59:10 CEST] <Fyr> bad
[12:59:12 CEST] <furq> the compression benefit with 10-bit x264 is basically free in terms of speed though
[12:59:24 CEST] <furq> whereas x265 is ~10x slower if you want it to beat x264
[12:59:29 CEST] <Fyr> x265 compresses as twice as better than h264.
[12:59:33 CEST] <JEEB> ahahahahaha
[12:59:36 CEST] <furq> sure
[12:59:43 CEST] <JEEB> HEVC as a format is better than AVC, yes
[12:59:59 CEST] <JEEB> but now you're sticking implementations into the game
[13:00:05 CEST] <JEEB> and those are much less optimized at the moment
[13:00:48 CEST] <furq> which highly scientific study did you get that twice as good figure from
[13:01:03 CEST] <JEEB> JCT-VC made PSNR-based studies, that's true. but that's with HM
[13:01:09 CEST] <JEEB> + it's theoretical
[13:01:18 CEST] <JEEB> also I think they had some viewing-based tests
[13:01:28 CEST] <JEEB> but as I said, those tests are done with the reference encoder
[13:01:43 CEST] <JEEB> and they are aiming to theoretically set the bar of how well the format can be used
[13:02:06 CEST] <JEEB> now the actual human-usable encoders have to find the places they can optimize in both psychovisual as well as speed side
[13:02:08 CEST] <furq> it's annoying because i see a lot of people who just take that as gospel and release stuff with x265 set to half the bitrate they'd normally use
[13:02:16 CEST] <furq> and then they use preset medium
[13:02:19 CEST] <furq> so the result is just garbage
[13:03:14 CEST] <JEEB> funny of course is the fact that on such low bit rate x265 probably does somewhat better than x264, due to the more-PSNR-like result (blurring, lines are probably clearer)
[13:03:21 CEST] <JEEB> but preset medium is what it is of course :P
[13:03:53 CEST] <JEEB> I should do another test, but I want to wait for my 2xE5-2670 rig to arrive
[13:04:20 CEST] <furq> even with a slower preset i'd be shocked if it ever beat x264 veryslow at half the bitrate
[13:04:22 CEST] <Fyr> I always use the slowest preset and one of the highest crf. =)
[13:04:35 CEST] <furq> enjoy your 2fps encodes then
[13:04:42 CEST] <JEEB> > highest CRF
[13:04:47 CEST] <JEEB> enjoy your highest compression
[13:04:53 CEST] <furq> i assume that means lowest
[13:05:00 CEST] <Fyr> yeah
[13:05:08 CEST] <JEEB> then he was on x264 in lossless mode with a 8bit encoder :P
[13:05:11 CEST] <__jack__> cbr is garbage anyway, you should not use it
[13:05:18 CEST] <JEEB> crf != cbr
[13:05:19 CEST] <furq> who said anything about cbr
[13:05:22 CEST] <Fyr> guys, what is hdmv_pgs_subtitle?
[13:05:29 CEST] <Fyr> is it srt?
[13:05:34 CEST] <JEEB> it's image-based subs from blu-rays
[13:05:47 CEST] <Fyr> can I convert it into SRT?
[13:05:52 CEST] <furq> not with ffmpeg
[13:05:53 CEST] <JEEB> with subtitle edit, yes
[13:05:58 CEST] <JEEB> it'll OCR
[13:06:00 CEST] <furq> you'd need an ocr tool like subtitle edit
[13:06:08 CEST] <Fyr> JEEB, what tool should I use?
[13:06:13 CEST] <JEEB> I just noted one
[13:06:17 CEST] <JEEB> same that furq noted
[13:06:24 CEST] <Fyr> ok
[13:06:43 CEST] <Fyr> didn't realize, that it's a name of program. =)
[13:07:00 CEST] <furq> it's windows only if that's an issue
[13:07:07 CEST] <furq> there's a popular cross-platform equivalent but i forget the name
[13:10:36 CEST] <Fyr> can I export PGS subtitles into a temporary MKV file, then compound the final MKV file with PGS subtitles?
[13:10:49 CEST] <Fyr> (I'm remuxing a Blu-ray)
[13:10:52 CEST] <furq> give it a try
[13:12:46 CEST] <Fyr> *highest reasonable CRF
[13:12:56 CEST] <Fyr> (=
[13:28:21 CEST] <Fyr> does mpegts support chapters?
[13:39:38 CEST] <DHE> Fyr: no, mpegts is intended to be streaming-friendly. to the point that you could join it at any single byte or even maybe bit in-transit
[13:39:56 CEST] <Fyr> cool, thanks
[13:42:34 CEST] <Fyr> DHE, is VOB streaming-friendly?
[13:43:59 CEST] <DHE> fairly well so
[13:45:43 CEST] <DHE> for reference, mpegts is what's used by digital over-the-air broadcasts
[14:25:01 CEST] <BtbN> Isn't VOB mpegps?
[14:25:08 CEST] <BtbN> So, the non-streaming variant of it
[14:26:33 CEST] <Fyr> guys, how to mux multiple input into one-filed output?
[14:26:57 CEST] <JEEB> multiple -i and -map
[14:27:02 CEST] <JEEB> read up on ffmpeg-all.html
[14:27:23 CEST] <Fyr> I used the example, but ffmpeg uses only the very first audio.
[14:27:33 CEST] <Fyr> ignores the other audio streams.
[14:28:47 CEST] <furq> yeah that's what -map is for
[14:29:28 CEST] <Fyr> I used:
[14:29:28 CEST] <Fyr> $ ffmpeg -ss 16:30 -t 60 -i .\II.h264 -ss 16:30 -t 60 -i .\II-1.mkv -ss 16:30 -t 60 -i .\II-2.mkv -ss 16:30 -t 60 -i .\II-3.mkv -map 0:0 -map 1:0 -map 2:0 -map 3:0 -c copy -threads 3 -y 1.mkv
[14:29:50 CEST] <Fyr> the output file has only the video and the very first audio stream.
[14:31:32 CEST] <__jack__> Fyr: -map 1:0 means "get the first stream from input #2"; you may need more map, like "-map 1:1" etc
[14:31:46 CEST] <furq> you presumably want -map 1:a instead of 1:0
[14:31:48 CEST] <furq> likewise for 2 and 3
[14:32:07 CEST] <__jack__> without mapping, ffmpeg get a stream-type at all, that's why you got only a single audio stream
[14:33:15 CEST] <Fyr> __jack__, no, the first file - video, the other ones - audio.
[14:33:37 CEST] <Fyr> despite the fact that it's MKV.
[14:33:50 CEST] <Fyr> it has only the audio stream.
[14:47:03 CEST] <onodera> Hi, is it possible to capture my cursor when recording my screen using x11grab
[14:50:45 CEST] <onodera> oh it does this by default heh
[14:50:46 CEST] <durandal_1707> onodera: it's not captured by default?
[14:50:48 CEST] <onodera> sorry
[14:50:53 CEST] <onodera> durandal_1707: yeah it is
[15:04:53 CEST] <AndrewMock> I'm about setup a test between qaac and ffmpeg's native aac encoder at 96kbps for professionally-recorded speech.
[15:05:02 CEST] <AndrewMock> Which one would win today?
[15:05:24 CEST] <AndrewMock> I know that ffmpeg's native aac encoder has made good progress.
[15:06:42 CEST] <furq> why are you asking us if you're about to test
[15:07:07 CEST] <Fyr> AndrewMock, no need, FFMPEG's AAC still sucks.
[15:07:20 CEST] <AndrewMock> i was just excited lol
[15:07:23 CEST] <Fyr> variable bitrate is not implemented yet.
[15:07:46 CEST] <AndrewMock> haha okay i will test in a year or so i guess
[15:07:57 CEST] <AndrewMock> thx for the timesaver
[15:08:09 CEST] <Fyr> =)
[15:08:20 CEST] <Fyr> if you set the bitrate lower than 128 kbps, you will hear Satan's voice.
[15:08:59 CEST] <furq> 14:07:23 ( Fyr) variable bitrate is not implemented yet.
[15:09:03 CEST] <furq> the docs disagree with you on that
[15:09:07 CEST] <Fyr> higher bitrate will sound just bad.
[15:09:18 CEST] <Fyr> furq, try it.
[15:09:21 CEST] <AndrewMock> oh i mean 96kbps mono male speech only
[15:09:38 CEST] <furq> at 96k per channel i doubt you'll be able to tell any difference
[15:09:39 CEST] <Fyr> atomnuker said that he will implement it in the end of the year.
[15:10:01 CEST] <AndrewMock> either way qaac is stable i will stick with that
[15:10:17 CEST] <Fyr> thumb up
[15:11:01 CEST] <JEEB> uhh, I don't see the issue in lack of VBR other than possibly using more bits than you want to
[15:11:19 CEST] <JEEB> and 96kbps mono is indeed high enough that even a crappy encoder would be able to handle it
[15:11:55 CEST] <JEEB> of course VBR would be more fun but telling someone an encoder sucks by just not having it is...
[15:12:12 CEST] <AndrewMock> even when played through a few grand in gear?
[15:12:13 CEST] <furq> 14:09:18 ( Fyr) furq, try it.
[15:12:15 CEST] <furq> i just did
[15:12:16 CEST] <furq> it works fine
[15:12:27 CEST] <furq> i also checked the logs and the only thing i can find atomnuker saying about it is that it works fine, to you
[15:12:30 CEST] <AndrewMock> i.e. sound reinforcement / PA
[15:12:31 CEST] <Fyr> furq, what parameters have you used?
[15:12:49 CEST] <furq> -q:a 1 and -q:a 2 both work and give different bitrates
[15:12:52 CEST] <JEEB> AndrewMock: you have to have something that fails real hard at 96kbps + mono. possibly FFmpeg's encoder circa 2010 when it created audible artifacts
[15:13:09 CEST] <furq> and they're both vbr
[15:13:18 CEST] <AndrewMock> alright
[15:13:19 CEST] <AndrewMock> peace
[15:13:23 CEST] <AndrewMock> thx
[15:14:11 CEST] <furq> 15:18:01 ( atomnuker) Fyr: yes, the encoder supports VBR, just use -q:a 0.0-1.0 instead of -b:a 128k
[15:15:35 CEST] <furq> that -q range seems to be wrong/outdated though
[15:15:42 CEST] <JEEB> yeah, most probably
[15:16:33 CEST] <Fyr> agreed
[15:16:41 CEST] <Fyr> but this range says nothing to me.
[15:16:47 CEST] <Fyr> + it's not in the wiki.
[15:16:56 CEST] <Fyr> + it's not in the docs.
[15:17:20 CEST] <JEEB> welcome to OSS, unless someone cares there's no magically appearing docs
[15:17:26 CEST] <JEEB> or actually not limited to OSS
[15:17:31 CEST] <Fyr> sure
[15:17:39 CEST] <JEEB> I've seen some proprietary projects having fun amounts of docs :P
[15:17:52 CEST] <furq> i vaguely remember that vbr mode isn't particularly well-optimised yet
[15:18:05 CEST] <furq> but it's definitely working
[15:18:17 CEST] <JEEB> even still that shouldn't actually worsen the capability of the encoder to compress
[15:18:37 CEST] <JEEB> since that's the same as with CBR. CBR is just a more limited VBR
[15:18:50 CEST] <furq> oh fun
[15:19:02 CEST] <furq> -q:a 0 gives me 144kbps but -q:a 0.1 is 20kbps
[15:19:16 CEST] <JEEB> zero probably goes to some default
[15:19:22 CEST] <furq> yeah that comes out the same as 1
[15:19:30 CEST] <furq> 2 is ~2x the bitrate of 1 though
[15:19:43 CEST] <furq> although there isn't much point in a 256k stereo aac
[15:20:03 CEST] <furq> if i wanted to spend that many bits i'd just use lame
[15:48:49 CEST] <Fyr> sorry, I just confused dates in here: https://trac.ffmpeg.org/ticket/2686#comment:379
[15:49:27 CEST] <Fyr> but still VBR is not documented and not implemented.
[15:49:49 CEST] <furq> it is implemented
[15:49:56 CEST] <furq> and it is partially documented, just the q range isn't
[15:52:10 CEST] <Fyr> then it should be.
[15:58:13 CEST] <ZeuZ> Guys, I need to turn a JPEG into a frame that will repeat 24 times, is there any libav compatible way of reading a FILE* structure or file descriptor? or do I need to parse it manually?
[16:11:30 CEST] <pa> hello! anyone with a dvb-s2 card pointed at Hotbird 13E in here? :-)
[16:22:56 CEST] <kynlem> hey
[16:38:14 CEST] <kynlem> is there a lossless audio format that can live happily inside a mp4 container?
[16:38:26 CEST] <furq> alac
[16:38:55 CEST] <JEEB> I think officially only ALS
[16:39:11 CEST] <JEEB> but what devices support, probably ALAC with the right types mentioned in the header
[16:39:46 CEST] <kynlem> ffmpeg -i canontest.mov -ss 0.00 -t 60.06 -acodec alac -vcodec libx264 chunk-alac.mp4
[16:40:04 CEST] <furq> als and sls are officially supported in mp4 but i'd expect alac is more common than either of them
[16:40:09 CEST] <kynlem> doesn't work "[mp4 @ 0x7fef03001000] Could not find tag for codec alac in stream #1, codec not currently supported in container"
[16:40:15 CEST] <furq> oh fun
[16:40:19 CEST] <kynlem> "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument"
[16:40:25 CEST] <JEEB> yeah, then it requires mov
[16:40:26 CEST] <c_14> only works with the mov muxer
[16:40:33 CEST] <JEEB> which is just another mode of the same muxer
[16:41:01 CEST] <c_14> I think someone wanted to also allow it for mp4, but the thread never advanced.
[16:41:21 CEST] <kynlem> but the mov container is less widely supported than mp4, no?
[16:41:44 CEST] <kynlem> seems like it
[16:41:54 CEST] <furq> do you need specific device support
[16:42:05 CEST] <kynlem> no
[16:42:37 CEST] <furq> if you don't then just use flac in mkv
[16:43:00 CEST] <furq> that way you don't have to pollute the earth with more alac
[16:43:14 CEST] <kynlem> got it. on the other hand, what would be the standard command line arguments to get audio of the highest possible quality inside an mp4 container?
[16:43:32 CEST] <furq> apparently there's no als encoder in ffmpeg so you'd be stuck with aac
[16:43:32 CEST] <JEEB> raw pcm (which is now standardized) or ALS
[16:43:37 CEST] <furq> oh is pcm supported now
[16:43:43 CEST] <JEEB> those are the two lossless formats in mp4
[16:43:56 CEST] <kynlem> pcm gives me same trouble
[16:44:13 CEST] <kynlem> ffmpeg wouldn't put it inside mp4
[16:45:14 CEST] <kynlem> ffmpeg version 2.8.3, that is.
[16:45:51 CEST] <JEEB> try latest
[16:45:53 CEST] <furq> i get the same thing with a recent git version
[16:45:57 CEST] <JEEB> ok
[16:45:59 CEST] <furq> recent-ish, about a month old
[16:46:05 CEST] <JEEB> then the muxer might have not been updated to the raw PCM specs
[16:46:19 CEST] <JEEB> just like the FLV muxed didn't let you mux non-44.1kHz AAC for quite a while :)
[16:46:22 CEST] <JEEB> *muxer
[16:46:50 CEST] <furq> i take it alac in mp4 is a non-starter until it shows up in some kind of actual spec
[16:47:27 CEST] <BtbN> any other rate in flv is a bad idea though, JEEB.
[16:47:45 CEST] <BtbN> I have seen weird things with non-44.1Hz in flv
[16:47:51 CEST] <BtbN> +k
[16:53:59 CEST] <JEEB> BtbN: it works just fine in flash with AAC
[16:54:18 CEST] <JEEB> because the FLV spec says that the field is just written as 44.1kHz in the container
[16:54:25 CEST] <JEEB> and the actual AAC stream is to be used for any information
[16:54:25 CEST] <BtbN> If you upload flv with 48kHz AAC to youtube, it interprets it as 44.1kHz
[16:54:35 CEST] <JEEB> then youtube is a dumb fuck
[16:54:47 CEST] <JEEB> when they re-transcode your shit
[16:55:12 CEST] <BtbN> yep, but It made me switch everything to .ts or .mkv
[16:55:19 CEST] <JEEB> not a bad idea
[16:56:11 CEST] <JEEB> but in any case, you can always have broken third parties in the flow. But as far as FLV is generally concerned, flash and modern FFmpeg handle AAC in it just fine
[16:56:26 CEST] <JEEB> although I haven't tried multichannel AAC in FLV recently with flash
[16:56:45 CEST] <BtbN> In general i like the flv container. It's very simple and just works.
[16:57:10 CEST] <JEEB> (mostly because flash sucks and I would like standardized outputs read by clients to it)
[16:57:54 CEST] <BtbN> Isn't flv primarily kept alive by rtmp now?
[16:57:59 CEST] <JEEB> yes
[16:58:20 CEST] <JEEB> although it is used by some 3rd parties like rtmp-nginx
[16:58:28 CEST] <JEEB> to stream out things in other formats as well
[16:58:34 CEST] <JEEB> as the input protocol
[16:58:43 CEST] <BtbN> primarily due to the lack of alternatives.
[16:58:45 CEST] <furq> that's still using rtmp
[16:59:03 CEST] <BtbN> I'm not aware of anything else than can be used as ingest protocol for video streams.
[16:59:08 CEST] <JEEB> furq: as input, yes
[16:59:19 CEST] <JEEB> BtbN: MSS is used by some servers
[16:59:31 CEST] <JEEB> in theory you could use a lot of things as the input feed
[16:59:38 CEST] <JEEB> but those are the two I've seen so far
[17:00:08 CEST] <BtbN> rtmp supports things like dropping the least important packages in case of congestion.
[17:00:32 CEST] <furq> i'd take rtmp all day long over hls or dash
[17:00:44 CEST] <JEEB> yes, it's an actual stream protocol
[17:00:51 CEST] <BtbN> hls/dash only exist because browsers are shit.
[17:01:00 CEST] <JEEB> and because people want to use their HTTP caching solutions
[17:01:15 CEST] <furq> and because people apparently don't need to seek backwards any more
[17:01:28 CEST] <JEEB> HLS and DASH don't stop you from having a buffer available
[17:01:29 CEST] <BtbN> seeking in a hls/dash stream works just fine
[17:01:47 CEST] <JEEB> it's just not a streaming protocol
[17:01:54 CEST] <furq> dash on youtube breaks about 50% of the time for me when i seek backwards
[17:02:07 CEST] <furq> i'm sure that's youtube's fault but i don't regularly use any other dash vod service
[17:02:10 CEST] <BtbN> Never seen seeking on YouTube break.
[17:02:10 CEST] <JEEB> or well, DASH and HLS are generally used over HTTP which is not a video streaming specific protocol :P
[17:02:19 CEST] <furq> i guess it could also be firefox's fault
[17:02:31 CEST] <furq> it wouldn't be a great surprise if their dash/mse implementation is broken
[17:02:39 CEST] <BtbN> I'm using Firefox.
[17:02:52 CEST] <JEEB> they can have various bugs as well, and 'tube generally is probably optimizing for Chrome's JS/MSE implementation
[17:03:05 CEST] <furq> has seeking seriously never broken for you on youtube
[17:03:09 CEST] <JEEB> recently I've had the buffering in the 'tube player fail with some clips
[17:03:27 CEST] <furq> that 50% figure was an exaggeration but not by much
[17:03:30 CEST] <JEEB> hasn't broken for me more than any MSE-based thing
[17:03:34 CEST] <furq> i'd say it happens at least every third or fourth time i try it
[17:03:44 CEST] <furq> the video just hangs and i have to refresh the page
[17:03:58 CEST] <JEEB> yeah, deffo a player implementation (or browser implementation) issue
[17:03:58 CEST] <furq> seeking backwards, that is
[17:04:00 CEST] <BtbN> Is that some old gstreamer based firefox?
[17:04:02 CEST] <furq> seeking forwards is usually fine
[17:04:05 CEST] <furq> no it's firefox on windows
[17:04:17 CEST] <BtbN> Never had that issue.
[17:04:39 CEST] <furq> fun
[17:04:41 CEST] <JEEB> if you want to see how well DASH works in general you could try Google's Android DASH/HLS/MSS player library's example player
[17:04:50 CEST] <JEEB> that thing is actually surprisingly good
[17:05:08 CEST] <BtbN> HLS in browsers is kinda... interesting.
[17:05:09 CEST] <furq> i did have a bunch of issues just after they switched to dash but i'm pretty sure those were to do with my isp
[17:05:10 CEST] <JEEB> ExoPlayer I think
[17:05:16 CEST] <BtbN> They remux to mp4 on the fly...
[17:05:23 CEST] <furq> yeah i've used hls.js
[17:05:36 CEST] <furq> it works surprisingly well for a hideous abomination
[17:06:04 CEST] <BtbN> isn't that actually some ffmpeg-like tool, re-compiler to js?
[17:06:12 CEST] <JEEB> no
[17:06:18 CEST] <JEEB> hls.js is a HLS parser in js
[17:06:24 CEST] <JEEB> and then remuxing into ISOBMFF fragments
[17:06:29 CEST] <furq> what he said
[17:06:31 CEST] <BtbN> I'm pretty sure I have seen some emscripten headers in there.
[18:06:32 CEST] <Fyr> is difference in size usual when remuxing? I copied all the streams from m2ts to mkv and found that the final output file is 3 Gb smaller than the source one.
[18:09:43 CEST] <furq> ts has more overhead than mkv
[18:10:05 CEST] <furq> i've remuxed some 720p movies and got a ~500MB size difference
[18:10:40 CEST] <furq> if that's an m2ts from a blu-ray or something then 3GB sounds plausible
[19:20:03 CEST] <pandaologist> can't get graticules on the waveform monitors working anymore
[19:20:07 CEST] <pandaologist> examples: https://trac.ffmpeg.org/wiki/WaveformMonitor
[19:20:23 CEST] <pandaologist> has this been deprecated, or has the syntax changed?
[19:35:31 CEST] <durandal_1707> pandaologist: command?
[19:38:31 CEST] <durandal_1707> pandaologist: if you use rgb it will not display it
[19:41:23 CEST] <pandaologist> guh
[19:41:29 CEST] <pandaologist> found the problem
[19:41:39 CEST] <pandaologist> only in git at the moment
[19:41:44 CEST] <pandaologist> durandal_1707: thanks
[20:48:55 CEST] <kynlem> ffmpeg -i canontest.mov -ss 180.18 -t 60.06 -acodec libfdk_aac -b:a 192k -vcodec libx264 -crf 16 -x264opts keyint=12:min-keyint=12:scenecut=-1 -map 0 chunk3.mp4
[20:49:41 CEST] <kynlem> when i split canontest.mov into 4 videos as above, and then merge them back, i get a popping sound at points where they meet
[20:50:27 CEST] <kynlem> but when i do the same and use -acodec copy (it's pcm) and mov as the output container, then they merge back fine
[20:50:31 CEST] <kynlem> any clues?
[21:06:15 CEST] <Fyr> Gibbs phenomenon?
[21:08:57 CEST] <kynlem> Fyr: and how can you deal with it?
[21:09:23 CEST] <Fyr> just copy?
[21:09:31 CEST] <kynlem> not possible
[21:09:35 CEST] <Fyr> if copying doesn't give that sound.
[21:09:45 CEST] <kynlem> the source is pcm-encoded, the output should be in mp4 container
[21:09:57 CEST] <kynlem> mp4 isn't a friend of pcm
[21:10:22 CEST] <kynlem> or any lossless audio codec for that matter
[21:11:10 CEST] <Fyr> I can suggest: 1) convert 2) cut
[21:11:10 CEST] <Fyr> if this doesn't work: 1) cut 2) convert
[21:11:20 CEST] <Fyr> I think the latter is what you're talking about.
[21:12:04 CEST] <kynlem> yeah, i'm trying the former now
[21:12:28 CEST] <Fyr> why is it not possible?
[21:13:41 CEST] <furq> ffmpeg doesn't support pcm or alac in mp4
[21:13:49 CEST] <furq> and it doesn't have als or sls encoders
[21:14:12 CEST] <Fyr> furq, why does it not support ALAC?
[21:14:23 CEST] <furq> because alac isn't officially supported in mp4
[21:14:33 CEST] <Fyr> I all my life converted into/from ALAC with FFMPEG.
[21:14:37 CEST] <furq> pcm is but it's a relatively recent addition
[21:14:51 CEST] <Fyr> the only problem I encountered - covert art.
[21:14:53 CEST] <furq> why would you ever convert to alac
[21:15:36 CEST] <furq> kynlem: i assume there's a requirement for the split files to be mp4 and they're not just intermediate files
[21:16:28 CEST] <furq> and also that those cut points won't end up at keyframe boundaries if you encode the whole thing and then split it
[21:17:08 CEST] <Fyr> ALAC had better compression with faster decompression a few years ago.
[21:17:19 CEST] <Fyr> only a year ago FLAC become comparable.
[21:17:30 CEST] <Fyr> at least, when converting with FFMPEG.
[21:17:50 CEST] <Fyr> though, some perks still have not been implemented in FFMPEG.
[21:18:00 CEST] <furq> i've never really used flac with ffmpeg but flac in general has always been better than alac
[21:18:11 CEST] <Fyr> in general - yes.
[21:18:19 CEST] <Fyr> with FFMPEG - no.
[21:20:34 CEST] <durandal_1707> Fyr: why?
[21:20:42 CEST] <Fyr> what why?
[21:21:11 CEST] <durandal_1707> explain what you just said?
[21:21:19 CEST] <Fyr> about ALAC?
[21:21:35 CEST] <durandal_1707> FLAC
[21:22:43 CEST] <Fyr> when converting audio file with FFMPEG, ALAC had better compression than FLAC. a year ago I noticed that FFMPEG developed to provide good compression in comparison to ALAC.
[21:22:49 CEST] <Fyr> sorry, I have to reboot.
[21:23:01 CEST] <Fyr> now I keep all my lossless audio library in FLAC.
[21:30:04 CEST] <pandaologist> can someone help me? I would like to add an audio volume monitor to my filter; showvolume would work ok
[21:30:08 CEST] <pandaologist> https://ffmpeg.org/ffmpeg-filters.html#toc-showvolume
[21:30:17 CEST] <pandaologist> current filter is as follows
[21:30:19 CEST] <pandaologist> ffplay video.avi -vf "format=yuv422p,split=5[a][b][c][d][e],[b]waveform=c=4:g=1:flags=dots,scale=h=128[bb],[c]waveform=c=2:g=1:flags=dots,scale=h=128[cc],[d]waveform=m=row:r=0:g=1:flags=dots[dd],[e]vectorscope=color5:g=1[ee],[a][bb][cc]vstack=inputs=3[V1],[dd][ee]vstack[V2],[V1][V2]hstack"
[21:30:49 CEST] <pandaologist> ideally it would be stacked vertically or horizontally
[21:33:18 CEST] <pandaologist> i just can't work out how to display a visual audio monitor alongside the video
[21:55:26 CEST] <durandal_1707> pandaologist: using -filter-complex for all of them instead of -vf
[22:24:48 CEST] <itt788> i'm trying to extract a part of an mkv video that contains 4 streams being as follwing -- 0 : video, 1 : audio lang 1, 2 : audio lang 2, 3 : subtitles. I would like my extract to contain either or audio streams or if impossible lang 1. My command line is "ffmpeg -ss 0:10:00 -i in.mkv -c:v copy -c:a:0 copy out.mkv". Either with using -c:a:0 or -c:a:1 I'm getting only lang 2 in my extract.
[22:27:45 CEST] <pandaologist> durandal_1707: can i use that directly in ffplay?
[22:27:59 CEST] <kynlem> furq: do you mean video keyframe?
[22:28:05 CEST] <pandaologist> i guess i could filter in ffmpeg and pipe to ffplay
[22:28:23 CEST] <durandal_1707> pandaologist: yes, pipe
[22:28:33 CEST] <kynlem> furq: in the source video, it's every 12th frame
[22:28:44 CEST] <kynlem> furq: and i'm keeping it that way in the cuts using 'keyint=12:min-keyint=12'
[22:49:07 CEST] <pandaologist> durandal_1707: got it! thanks :)
[23:38:20 CEST] <ploop> is it possible to use ffmpeg to make a video that's just a still image for a certain amount of time? I tried "ffmpeg -i image.png -t 10 video.mkv", but the output seems to last a single frame instead of 10 seconds
[00:00:00 CEST] --- Sun May 22 2016