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

[burek]

[03:06:48 CEST] <Case_Of> atomnuker: i am testing cyanrip in my chroot
[03:08:16 CEST] <Case_Of>     Stream #0:0: Audio: flac, 44100 Hz, stereo, s16, 128 kb/s
[03:08:16 CEST] <Case_Of>  &
[03:08:27 CEST] <Case_Of> 128kb/s by default
[03:09:37 CEST] <Case_Of> atomnuker: what a cd is using as default bitrate?
[03:10:07 CEST] <Cracki> 441
[03:10:08 CEST] <Cracki> 00
[03:10:35 CEST] <Cracki> that's 1411.2 kbit/s
[03:10:50 CEST] <Cracki> so the 128 kb/s for *flac* are bogus
[03:11:23 CEST] <Cracki> you know... it's ok to ask the channel, no need to chase specific people
[03:11:42 CEST] <Case_Of> i was asking atomnuker because it's his ripping program
[03:11:45 CEST] <Case_Of> cyanrip
[03:12:17 CEST] <Cracki> hm
[03:12:31 CEST] <Case_Of> so let's try cyanrip -b 1411
[03:12:41 CEST] <Cracki> does flac even work with bitrates?
[03:13:02 CEST] <Case_Of> good question
[03:13:14 CEST] <Case_Of> ffmpeg considers that flac has bitrate
[03:13:34 CEST] <Cracki> if I were a flac encoder, I'd ignore bitrate
[03:14:18 CEST] <Case_Of> then how could it be done?
[03:14:28 CEST] <Case_Of> to get a lossless rip?
[03:17:38 CEST] <Cracki> flac is lossless
[03:17:53 CEST] <Cracki> dude you are asking questions that tell me you don't understand the tools
[03:18:00 CEST] <Cracki> you've been at this for a few days
[03:19:28 CEST] <Case_Of> that's possible
[03:20:40 CEST] <Case_Of> Cracki: was it you that recommended me whipper few days ago?
[03:20:51 CEST] <Cracki> no
[03:20:55 CEST] <Case_Of> ok
[03:21:50 CEST] <Case_Of> because actually i prefer whipper method
[03:21:53 CEST] <Cracki> my impression is that you're obsesses with "lossless", but you don't seem to comprehend how CDs are read
[03:22:48 CEST] <Case_Of> then enlight me :)
[03:23:54 CEST] <Cracki> read up on how data on a CD is arranged, specifically how much error correcting data is stored
[03:24:13 CEST] <Cracki> reading an audio cd perfectly isn't too difficult
[03:24:36 CEST] <Case_Of> yeah probably
[03:24:42 CEST] <Cracki> and you _have_ been told what these tools do (read slowly, read multiple times, check hashes against a database, ...)
[03:24:57 CEST] <Case_Of> both whipper and cyanrip read the cd perfectly i think
[03:24:58 CEST] <Cracki> and you _have_ had the chance to figure out what FLAC is
[03:25:28 CEST] <Case_Of> but cyanrip is doing postprocess conversion, so i think it's a wrong approach
[03:25:53 CEST] <Cracki> so you should understand that flac is more like zip than mp3
[03:26:04 CEST] <Case_Of> ok
[03:26:05 CEST] <Cracki> wat
[03:26:09 CEST] <Cracki> you "think"?
[03:26:18 CEST] <Cracki> what do you think it does?
[03:26:35 CEST] <Case_Of> it says encoding
[03:27:30 CEST] <atomnuker> Case_Of: oh, if you read the logs it says "lossy bitrate"
[03:27:39 CEST] <atomnuker> lavf still reports bitrate even if a format is lossless
[03:27:52 CEST] <atomnuker> I guess I can unset it if the codec is lossless though
[03:28:23 CEST] <atomnuker> and yes, bitrate is very much ignored for lossless formats
[03:28:34 CEST] <Case_Of> but ffmpeg is still showing it
[03:28:41 CEST] <Case_Of> so it's maybe not cyanrip fault
[03:29:00 CEST] <Case_Of> ffmpeg -i song.flac still shows that bitrate
[03:30:13 CEST] <Case_Of> ffmpeg should ignore that
[03:32:35 CEST] <atomnuker> well, I think it shows average bitrate
[03:33:18 CEST] <Case_Of> so by default the average bitrate set by ffmpeg is 128kbps?
[03:47:10 CEST] <atomnuker> no, that's the cyanrip default, in ffmpeg it depends on the encoder used
[03:51:01 CEST] <Case_Of> ok
[03:59:49 CEST] <johnnny22> hey
[04:29:27 CEST] <Case_Of> atomnuker: my gentoo chroot for cyanrip https://caseof.tk/cyanrip_subsystem.tar.xz
[06:28:33 CEST] <johnnny22> wouldn't be nice if the hls demuxer could support a start_media_sequence as an alternative to the start_live_index ?
[06:30:59 CEST] <JEEB> i think the chinese guy hacking on the hls/dash stuff looks at the trac issue tracker, so feel free to request it there
[08:11:31 CEST] <Wallboy> Can someone explain what setpts really does? I often see tutorials on filters and see "setpts=PTS-STARTPTS" used quite a lot with no real explanation of why/what it's doing besides "zeroing out the timestamp to avoid sync issues". What is the value of PTS? and the value of STARTPTS? What does the expression actually equate to? Does it apply on each frame? I've already done research on PTS and
[08:11:31 CEST] <Wallboy> I know WHAT it is and how it describes when a particular frame is supposed to be shown. I just don't understand what PTS-STARTPTS is supposed to accomplish
[08:21:52 CEST] <greysondn> Wanting to pipe raw frames from ffmpeg used to decode into python and then back out into a second ffmpeg process for reencoding. I've been here once before and established that, while perhaps I struggle a bit with the nature of video codecs, I know what I'm doing. My source is "lossless" x264 in RGB color space, I'll be using Python's PILLOW library, can someone *please* just give me some guidance on setting up the two pipes in a 
[08:22:26 CEST] <greysondn> (I was here once before and this was actually a suggested solution that I'm finally getting around to looking at, for the record.)
[08:29:17 CEST] <greysondn> Derp. Python 3.7, my derp for not being clearer there.
[11:11:46 CEST] <Mavrik> mornin
[11:12:17 CEST] <Mavrik> Wallboy, what that really does is subtracts timestamp of the first frame (STARTPTS) from each frames timestamp
[11:12:34 CEST] <Mavrik> so essentially it makes sure first frame starts at timestamp 0 instead of whatever else
[11:13:07 CEST] <Wallboy> so it ONLY applies to the first frame?
[11:13:14 CEST] <Mavrik> no, to each frame
[11:13:30 CEST] <Mavrik> pretty much all filters apply to all frames
[11:13:38 CEST] <Wallboy> to me STARTPTS is the first PTS... so in my mind naturally that would be... 0... so you see my confusion
[11:13:48 CEST] <greysondn> Been three hours but for he record I'm still here. Just started dumping what should be my source video for my question about three hours ago.
[11:13:59 CEST] <greysondn> No hurry, just noticed signs of life was all.
[11:14:27 CEST] <Wallboy> what is the CURRENT PTS MINUS the STARTPTS changing?
[11:14:31 CEST] <Mavrik> Wallboy, there's absolutely no rule that the first frame should start at 0 :)
[11:14:42 CEST] <Mavrik> in a file or a stream
[11:14:54 CEST] <Wallboy> so we are subtracting a very very small value from the current PTS?
[11:14:55 CEST] <Mavrik> think live streams - how would you start at 0 when connecting in a middle of a live video? :)
[11:15:05 CEST] <Mavrik> Why would the value be small?
[11:15:22 CEST] <Wallboy> well given a non live stream... an normal input file
[11:15:28 CEST] <Wallboy> why would the STARTPTS not be 0
[11:15:35 CEST] <Mavrik> Because someone created it like that.
[11:15:39 CEST] <Mavrik> Again, there's no rule.
[11:15:40 CEST] <Mavrik> At all.
[11:15:46 CEST] <Mavrik> It can start wherever.
[11:15:46 CEST] <Wallboy> isn't the PTS the time to display a video frame... when i first laucnah a video, the first frame shoudl be displayed at... 0? no?
[11:15:57 CEST] <Mavrik> If should be yes
[11:16:02 CEST] <Mavrik> But that doesn't mean the first PTS has value of 0.
[11:16:15 CEST] <Mavrik> If you cut a video in half.
[11:16:26 CEST] <Mavrik> Why would you expect the second half to have first timestamp of 0?
[11:16:34 CEST] <Wallboy> yes, because it's a NEW video
[11:16:35 CEST] <Mavrik> Cutting doesn't change the timestamps
[11:17:01 CEST] <Mavrik> Retimestamping the video would be pointless waste of CPU... and could bring in sync issues.
[11:17:21 CEST] <Mavrik> Because there's also no rule that you have audio frames with exact same PTS as video
[11:17:39 CEST] <Wallboy> so in general what is the first PTS value of a "normal" mp4 or avi for the sake of example, be?
[11:17:49 CEST] <Wallboy> for the first frame
[11:17:49 CEST] <Mavrik> It can be whatever.
[11:17:58 CEST] <Mavrik> You're trying to look for a rule that doesn't exist.
[11:18:05 CEST] <Mavrik> It can literaly be any number.
[11:18:20 CEST] <Mavrik> It can be 0 or 8549385943
[11:18:36 CEST] <Wallboy> but if it was a value that was 15 seconds... and i opened the file in my video player, and not got a video for 15 seconds... i would be thinking something is wrong with this video
[11:18:59 CEST] <Mavrik> Yes, but PTS isn't absolute time
[11:19:13 CEST] <Mavrik> The player really cares about spacing between PTS values of frames
[11:19:15 CEST] <Mavrik> Not their exact values.
[11:19:30 CEST] <Mavrik> Every player will just start immediately playing from first frame.
[11:19:35 CEST] <Wallboy> I guess what i'm really confused about is what the expression (PTS-STARTPTS) is doing?
[11:19:39 CEST] <Wallboy> what is that accomplishing?
[11:19:44 CEST] <Wallboy> and why do you see this often after trim filter
[11:19:47 CEST] <Mavrik> It's making sure that the file you output will start at 0
[11:20:01 CEST] <Mavrik> It's generating a pretty file you're hoping to have - the one that starts at 0 PTS :P
[11:20:17 CEST] <Mavrik> So it subtracts first time stamp from all the others
[11:20:23 CEST] <Mavrik> So if your input has timestamps that are like:
[11:20:24 CEST] <Wallboy> ok, but then why is it not setpts=0?
[11:20:29 CEST] <Mavrik> 110, 120, 130, 140, 150
[11:20:30 CEST] <Wallboy> if it makes sure it "starts at 0"
[11:20:40 CEST] <Mavrik> Your output will be (110-110), (120-110) ...
[11:20:44 CEST] <Mavrik> or in other words, 0, 10, 20, ...
[11:20:59 CEST] <Mavrik> Because setpts=0 would set timestamp on EVERY frame to 0
[11:21:15 CEST] <Mavrik> Telling the player "show all of these frames at once!"
[11:21:26 CEST] <Mavrik> And generating something that's not playable ;P
[11:22:08 CEST] <Wallboy> so when in general in a complex filter chain would setpts=PTS-STARTPTS be needed? or better... when is it NOT needed?
[11:22:39 CEST] <Mavrik> No idea why it's needed in your case.
[11:22:45 CEST] <Mavrik> In most cases it shouldn't be needed.
[11:22:51 CEST] <Mavrik> But hard to say because I don't know what you're doing.
[11:22:53 CEST] <Wallboy> i see it in almost all usages of the trim filter
[11:23:04 CEST] <Wallboy> with the reason as "to avoid quirks with timestamps, this is needed"
[11:23:54 CEST] <Mavrik> *shrug*
[11:24:04 CEST] <Mavrik> I'd expect that to introduce a bit of sync issues.
[11:24:06 CEST] <Wallboy> https://trac.ffmpeg.org/wiki/FilteringGuide
[11:24:10 CEST] <Mavrik> But as I said, perhaps it's legitimate.
[11:24:16 CEST] <Wallboy> "a good idea to pass all overlay inputs through setpts"
[11:24:30 CEST] <Wallboy> as in the guy who wrote that doesn't know if it's needed
[11:24:35 CEST] <Mavrik> ah
[11:24:42 CEST] <Mavrik> for overlay it makes sense
[11:25:04 CEST] <Mavrik> because you're joining multiple videos
[11:25:10 CEST] <Mavrik> and if they don't start at the same timestamp
[11:25:22 CEST] <Mavrik> They won't start at the same time.
[11:27:17 CEST] <Wallboy> about a year ago, i was having audio sync problems with lib-rubberband and a video that was going out of sync, someone suggested the setpts filter with that expression, and it did solve the issue. I didn't try to understand the why of it, and now a year later, I'm refactoring a program I'm writing that uses ffmpeg and am just trying to understand certain filters
[11:29:00 CEST] <Wallboy> i still don't understand the "start at 0 timestamp" i keep seeing with PTS-STARTPTS
[11:30:16 CEST] <Wallboy> i'll have to study it more... i'm sure i'll have a "ohhhhh of course" moment lol
[11:30:34 CEST] <furq> startpts is the pts of the first selected frame
[11:30:34 CEST] <Mavrik> Perhaps use ffprobe to print out pts of all frames in your streams?
[11:30:38 CEST] <Mavrik> Before and after processing?
[11:31:55 CEST] <furq> basically if you're doing trim;trim;concat then each clip you give to concat needs to start at 0 or else you'll get big pts discontinuities
[11:32:13 CEST] <furq> which will manifest themselves in a variety of fun ways
[11:34:10 CEST] <furq> so trim=start_pts=100:end_pts=200,setpts=PTS-STARTPTS will have 100 deducted from every pts value so you get 0-100 instead of 100-200
[11:34:54 CEST] <Wallboy> i have a filterchain that takes a video and appends an OUTRO video using concat, but in between that main video and outro video, i create a third video that acts as a fade between the main video and outro video
[11:35:23 CEST] <Wallboy> so trims and concat IS used in my chain, but i only had to do it to fix an audio sync issue with the main video
[11:35:48 CEST] <Wallboy> from what i can recall when i set this up a year ago and just am going through code to refactor/understand things better
[11:36:46 CEST] <Wallboy> I'll have to re-read your guys comments tomorrow to undrstand better, cause i'll be honest, i'm a few too many bourbons in right now to try and understand this atm lol (hey it's the long weekend where i live :P)
[11:37:14 CEST] <Wallboy> but thanks for answering, i'm sure I'll have a "eureka" moment tomorrow
[17:42:03 CEST] <kepstin> rrg: cheap usb grabbers are actually pretty decent at dealing with poor quality vhs signals
[17:42:55 CEST] <kepstin> rrg: only reason you'd want tbc is if frames in the resulting video have some lines shifted horizontally
[17:43:00 CEST] <rrg> i already did recordings with it and as far as i remember those werent that great
[17:43:31 CEST] <rrg> was 1 or 2 years ago
[17:44:17 CEST] <Cracki> are luma and chroma of a single at least aligned to each other?
[17:45:12 CEST] <kepstin> Cracki: no reason they wouldn't be, iirc vhs stores in a composite format so they'd all be together
[17:45:23 CEST] <rrg> have to look for the recordings ...
[17:45:36 CEST] <Cracki> depending on severity, some post-capture filtering might be possible. I'm not sure how to align lines properly though... the content of two lines would need to be aligned, but if they have originally "shifted" content, that would fail to give the right result
[17:45:54 CEST] <Cracki> one would have to overscan and hope the fringes of the picture can be used for alignment
[17:46:19 CEST] <Cracki> best results on uncompressed video ;)
[17:46:35 CEST] <kepstin> rrg: but yeah, if the recordings just look bad in general - well, that's vhs. If you have the specific issue of horizontally shifted lines, TBC would help.
[17:49:20 CEST] <kepstin> make sure that you're capturing in 4:2:2 or 4:1:1 sampling rather than 4:2:0 if hardware supports it, so you have separate chroma per line. Makes later filtering easier.
[17:50:24 CEST] <rrg> left and right edge are wavy
[17:50:41 CEST] <rrg> i think a tbc is probably what i need
[17:51:55 CEST] <rrg> also some stoppers but i think that was the problem of the bad windows software of the grabber brand - will record this time raw under linux with the help of the nvidia card
[17:53:10 CEST] <Cracki> what does "the nvidia card" have to do with grabbing?
[17:54:32 CEST] <kepstin> well, if you have really poor cpu, i guess using a hardware encoder means you can keep up with realtime capture
[17:54:58 CEST] <kepstin> but even a pretty low end modern computer should have no issue doing hundreds of fps in x264 at sd resolution.
[17:57:34 CEST] <rrg> i thought that last time the cpu couldnt keep up
[17:58:17 CEST] <rrg> i have stoppers and the usb grabber had to be cooled ... D:
[18:10:02 CEST] <Cracki> take care to encode that stuff at highest possible quality, if you need to do any filtering (tbc in software)
[18:11:16 CEST] <Cracki> i forwarded dscastro. he has this problem: (rtsp camera feed) -> trancode to mpeg4 -> upload to s3 bucket
[18:13:55 CEST] <dscastro> Cracki: i spend two days tweaking a python code to grab rtsp feed and write files, just finished within minutes a ffmpeg version :)
[18:26:31 CEST] <pi-> Varying '-threads' value doesn't appear to affect computation time on my MacBook Pro.
[18:26:37 CEST] <pi-> Am I missing something?
[18:26:40 CEST] <No0n3Left> Im trying to put a .opus file in a .ogg file, but every time I try, it recodes the opus into vorbis. Opus can be embeded in (and Im pretty sure is officially supported by) OGG, so how can I tell it just to put it in an ogg container and not to recode it
[18:26:51 CEST] <pi-> Is it likely to take advantage of say a 32-core LinuxVM?
[18:29:07 CEST] <Mavrik> No0n3Left, what's your command line?
[18:29:26 CEST] <Mavrik> pi-, are you using an encoder that can properly use threads?
[18:29:27 CEST] <No0n3Left> Mavrik: ffmpeg -i Original.opus New.ogg
[18:29:37 CEST] <No0n3Left> Also have tried -c copy, but that doesnt actually change it to ogg
[18:29:39 CEST] <Mavrik> Yeah, that's going to reencode with default settings
[18:29:42 CEST] <Mavrik> and trash quality :P
[18:29:47 CEST] <Mavrik> -c copy is what you want.
[18:29:58 CEST] <c_14> No0n3Left: there's no difference between .opus and .ogg
[18:30:09 CEST] <c_14> .opus is just the file extension for "opus in ogg"
[18:30:11 CEST] <No0n3Left> If I do -c copy, then check it with ogginfo, it says its not valid ogg
[18:30:32 CEST] <No0n3Left> It just says Type Unknown
[18:31:21 CEST] <Cracki> what version of ogginfo do you use?
[18:31:33 CEST] <Cracki> use ffprobe.
[18:32:25 CEST] <No0n3Left> NVM, ffprobe shows it as valid ogg
[18:32:35 CEST] <Cracki> sounds like ogginfo is outdated
[18:32:47 CEST] <c_14> I think ogginfo just doesn't know about opus
[18:33:27 CEST] <Cracki> don't blame ffmpeg for ogginfo not understanding the file ;)
[18:33:42 CEST] <No0n3Left> Yeah, didnt realise ogginfo didnt know opus
[18:33:53 CEST] <c_14> No0n3Left: the only thing you need to do to "convert" between .opus and .ogg is rename the file
[18:34:12 CEST] <c_14> the file formats are otherwise identical
[18:34:54 CEST] <No0n3Left> Ok, thanks
[18:38:33 CEST] <furq> No0n3Left: there's a fork of ogginfo for opus
[18:38:34 CEST] <furq> opusinfo
[18:38:49 CEST] <furq> it is weird they wouldn't just merge them but shrug
[18:41:03 CEST] <No0n3Left>  furq: I dont even have that command on my system. The ogg tools are a mess sometimes. Especially the kate ones. Wish ffmpeg supported kate, but I dont think it does.
[18:41:22 CEST] <c_14> No0n3Left: separate package opus-tools (probably)
[18:41:50 CEST] <c_14> ogginfo is in the vorbis-tools package and opusinfo in the opus-tools package (at least on my distro)
[18:42:56 CEST] <furq> i forgot what kate was so i googled it and the top page of matches is all about a woman called kate ogg
[18:43:06 CEST] <furq> so i guess that speaks to how popular ogg kate is
[18:43:42 CEST] <c_14> Isn't kate also the text editor?
[18:43:51 CEST] <furq> yeah
[18:43:52 CEST] <No0n3Left> Yeah, but its really the only good way to embed subtitles in ogg
[18:44:26 CEST] <furq> is there any reason to use theora nowadays
[18:45:10 CEST] <furq> i guess even if there is you can just mux it into mkv
[18:46:14 CEST] <No0n3Left> Theora is the losseless one right?
[18:46:34 CEST] <furq> no
[18:46:49 CEST] <furq> theora is the ogg video codec
[18:46:56 CEST] <furq> i assume you're using that if you need subtitles
[18:47:25 CEST] <No0n3Left> No, just with audio. IDK. Like to keep subtitles embeded in audio if I can. Not really needed
[18:49:04 CEST] <No0n3Left> Whats wrong with theora though? AFAIK its one of the only open and decent video codecs
[18:50:49 CEST] <Mavrik> furq, hmm, using Theora these days sounds pretty insane
[18:51:11 CEST] <Mavrik> Isn't it stuck on like DivX level of coding standard
[18:51:19 CEST] <Mavrik> yp.
[18:53:00 CEST] <furq> it's not even that good
[18:53:37 CEST] <furq> No0n3Left: vp8/vp9 are acceptably open for most people and they're less ancient
[18:53:49 CEST] <furq> and av1 whenever they get around to making that usable
[18:56:18 CEST] <No0n3Left> Ok, thats good to know
[18:59:52 CEST] <No0n3Left> [M
[18:59:52 CEST] <No0n3Left> i[M#
[21:13:29 CEST] <johnnny22> what exactly is this "Enable interaction on standard input" about exactly ? What kind of interaction are we talking about here and where would it be documented ?
[21:17:08 CEST] <BtbN> Where do you see that?
[21:19:37 CEST] <johnnny22> Within the https://ffmpeg.org/ffmpeg-all.html#Main-options --> -stdin option
[21:19:49 CEST] <furq> johnnny22: hit ? while ffmpeg is running
[21:20:50 CEST] <johnnny22> aaah, thanks
[21:21:44 CEST] <johnnny22> makes sense!
[21:51:53 CEST] <acetone> hello, I am trying to encode raw frames with avcodec_encode_video2(), but it keeps throwing exception. Can you help me?
[21:57:37 CEST] <BtbN> ffmpeg does not throw exceptions. You mean it crashes? Or returns an error?
[22:05:56 CEST] <acetone> BtbN yeah, msvc handles it as an exception... But it chrashes.
[22:06:59 CEST] <DHE> well ffmpeg is C, but an 'exception' is another language thing like C++
[22:08:13 CEST] <acetone> I am comparing process to one that is working, and I can not see difference. So AVframe seems to be OK. Can it crash because of messed up codec context?
[22:09:52 CEST] <acetone> problem is, that AVCodecContext has so many fields, that it is hard to debug
[22:10:47 CEST] <DHE> the return code from avcodec_encode_video2 is a negative number and av_strerror() can convert it to a human-readable string
[22:11:37 CEST] <DHE> the other thing you can try is turning on logging or raising the print cutoff. I forget what the default is...
[22:12:50 CEST] <acetone> avcodec_encode_video2 chrashes, so there is no error code
[22:12:59 CEST] <acetone> also console is silent
[22:13:33 CEST] <DHE> so full segfault...
[22:13:44 CEST] <acetone> I am accessing avcodec_encode_video2 from another software so it is library...
[22:46:52 CEST] <pi-> I asked earlier: I'm using `-threads=0` which IIRC should optimise for the number of CPU cores available. However I'm getting no noticeable performance benefit.
[22:47:21 CEST] <pi-> Someone suggested maybe I am using a codec that doesn't support parallellization.
[22:47:25 CEST] <DHE> well that's usually the default anyway
[22:47:25 CEST] <TheAMM> Someone will correct me, but that's encoder specific
[22:47:46 CEST] <TheAMM> libvpx for example isn't able to count the cores
[22:47:55 CEST] <BtbN> 0 is the default, so unless you were intentionally limiting to 1 before, there won't be any difference
[22:48:09 CEST] <pi-> tx, good knowledge
[22:48:19 CEST] <pi-> How to know which codec I'm using?
[22:48:29 CEST] <pi-> Do I have any choice in the matter?
[22:48:42 CEST] <BtbN> You're telling it which codec to use
[22:48:56 CEST] <pi-> I need to separate streams, insert blips into the audio stream, re-merge.
[22:49:08 CEST] <pi-> I want to export .mp4
[22:50:19 CEST] <pi-> I'm encoding Digital content > 17kHz, so it's important that a compression algorithm doesn't erode the information content
[22:50:42 CEST] <pi-> If I set .mp4, is that determining the codec?
[22:51:08 CEST] <TheAMM> You mean you have audio above 17khz?
[22:51:22 CEST] <pi-> Thatyup
[22:51:27 CEST] <furq> pi-: -h muxer=mp4
[22:51:29 CEST] <pi-> -that
[22:51:34 CEST] <furq> will tell you what the default codecs are
[22:51:41 CEST] <TheAMM> If you're only touching the audio, you don't have to re-encode the video
[22:51:47 CEST] <furq> but i could just tell you that they're x264 and aac
[22:52:31 CEST] <pi-> I wish my outsource dev could have at least been bothered to pop his head into this channel
[22:52:33 CEST] <furq> i have no idea what the cutoff for the builtin aac encoder is but i'd be surprised if it was above 17khz
[22:52:49 CEST] <furq> it doesn't look like it lets you set it
[22:53:30 CEST] <furq> also yeah you probably don't need to touch the video stream
[22:53:40 CEST] <furq> and this will be a few orders of magnitude quicker if you don't
[22:54:32 CEST] <pi-> I've got a couple of other cases to handle: in one case the audio track is supplied separately. Can that be done without fiddling with the video?
[22:54:42 CEST] <furq> sure
[22:54:56 CEST] <furq> -i foo.mp4 -i bar.m4a -map 0:v -map 1:a -c copy baz.mp4
[22:55:30 CEST] <furq> as a general rule you should never listen to anyone on the internet outside of this channel about ffmpeg
[22:55:41 CEST] <furq> they're almost always extremely wrong
[22:58:57 CEST] <FurretUber> Hi, is there a way to capture the audio of a specific application using pulseaudio, instead of an entire source?
[23:00:03 CEST] <BtbN> The API allows it, but I'm not sure if ffmpeg implements it.
[23:01:01 CEST] <johnnny22> is there a way to ask ffmpeg to only quit on a keyframe when the user presses [q] ?
[23:01:15 CEST] <poutine> I am reading about HLS, and am having trouble wrapping my mind around EXT-X-DISCONTINUITY a bit, I'm reading https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.2.3 but what I don't understand is "timestamp sequence", is that referring to PTS/DTS within the segments themselves, if they change, it must be signaled by this discontinuity tag?
[23:01:58 CEST] <poutine> number, type, and identifiers I assume is just that it has the same PAT/PMT stuff
[23:02:26 CEST] <poutine> also referring to mpegts segments specifically
[23:02:35 CEST] <pi-> How might I go about sourcing a ffmpeg expert for consultancy?  I know it's frowned on on Freenode, and I apologise, but if anyone here might be willing, please PM me.
[23:02:42 CEST] <DHE> the nice thing about mepgts is that you can literally just concatenate all the .ts files together and get a playable video
[23:03:08 CEST] <poutine> DHE, I have noticed though that players treat directly concatted files differently
[23:03:14 CEST] <c_14> pi-: the ffmpeg-devel mailing list
[23:03:17 CEST] <poutine> than ffmpeg concatenating them
[23:03:25 CEST] <poutine> seek/duration times
[23:03:33 CEST] <BtbN> ffmpeg also only does exactly that
[23:03:42 CEST] <BtbN> seeking and duration in mpegts just aren't well defined
[23:04:07 CEST] <DHE> mpegts has okay timestamps (1/90,000 timebase) but no durations on frames
[23:04:17 CEST] <BtbN> and no index
[23:04:47 CEST] <DHE> the concat filter does do things assuming that the timestamps originate from 0 for each file, whereas with HLS it's assumed the timestamps just keep counting between files and don't reset
[23:05:23 CEST] <DHE> there is a `random access indicator` suggesting a mpegts chunk is a good place to start playing from, but you have to go hunting for such a marked chunk
[23:06:06 CEST] <DHE> but yeah, it's intended as a streaming format which has its ups and downs
[23:06:41 CEST] <poutine> DHE, There's no way to make ffmpeg start its timestamping from the end of another file's to eliminate discontinuities?
[23:06:57 CEST] <poutine> like if I were live streaming hls, and only knew what was one program ahead at any given time
[23:07:41 CEST] <DHE> poutine: I think HLS was intended to be friendly for a simple app that just splits off a live feed into HLS without any work being done. just look for that random access indicator and split the file on that marker
[23:07:57 CEST] <DHE> it's not QUITE that simple but it's damned close
[23:09:37 CEST] <poutine> Thanks, looking into it
[23:09:55 CEST] <DHE> well, I don't expect the average user to actually look into the mpegts file format
[23:10:20 CEST] <poutine> I've looked at PAT/PTS/DTS/PES/PMT tables, scte35 table injection, etc
[23:10:37 CEST] <DHE> well you've done your reading
[23:10:40 CEST] <poutine> did not mean all of those were tables, but am familiar with some
[23:13:25 CEST] <DHE> protip: install the GUI version of wireshark (if you don't have it already) and open a .ts file with it to see the file format directly...
[23:17:54 CEST] Action: DHE is waiting while valgrind finds his code bugs... while the program runs at ~2% speed.... :/
[23:25:59 CEST] <bencoh> I guess you tried asan before going for valgrind?
[23:27:53 CEST] <DHE> bencoh: valgrind include --show-reachable=yes and works better with applications without requiring a recompile...
[23:28:22 CEST] <bencoh> and is much slower, yes :)
[23:28:28 CEST] <bencoh> but yeah I get your point
[00:00:00 CEST] --- Mon Aug  6 2018