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

[burek]

[00:00:05 CEST] <furq> is #3 still slow if you don't run anything on #1
[00:00:10 CEST] <aib> I guess it's two vCores to one physical core?
[00:00:17 CEST] <furq> well one would hope so
[00:00:51 CEST] <furq> but i don't see any guarantee that you're not getting physical cores shared with another instance
[00:01:03 CEST] <aib> yes, core #3 is slow only when bogomips is running on core #1
[00:01:10 CEST] <furq> probably not that then
[00:01:54 CEST] <aib> I'll check the other configurations but I'm guessing it will be #1 paired with #3 and 2 with 4
[00:02:00 CEST] <kepstin> hmm, if that's the case, then it looks like they're doing standard intel topology/thread numbering
[00:02:34 CEST] <ppw> https://stackoverflow.com/questions/7274585/linux-find-out-hyper-threaded-core-id
[00:02:43 CEST] <ppw> "If hyperthreading is detected then lock the process to use the even-numbered logical processors only. This will make one of the two threads in each processor core idle so that there is no contention for resources."
[00:03:02 CEST] <aib> furq: so there you have your answer. I'm much stupider :S
[00:03:29 CEST] <furq> i'll take your word for it
[00:03:42 CEST] <kepstin> the standard intel cpu numbering is for the first n/2 "cpus" to be the real cores, then the second n/2 "cpus" to be the hyperthread siblings corresponding to the first set of cpus
[00:03:47 CEST] <aib> iive had it on the second guess
[00:04:00 CEST] <aib> I've spent hours trying to figure this out. even wrote that stupid program for this :D
[00:04:28 CEST] <aib> I always assumed it was a scheduling artifact
[00:05:51 CEST] <kepstin> note that for video encoding with x264, I think there is a performance benefit to hyperthreading, so it's better to allow it to use hyperthread siblings rather than to lock it to physical cores
[00:06:14 CEST] <kepstin> since it's memory intensive, i guess, so the cpu prefetchers can do a better job or something
[00:10:27 CEST] <aib> hmm, I haven't tried multithreading within ffmpeg yet
[00:11:09 CEST] <aib> (my application processes many segments at once, I have many more ffmpeg instances than cores, anyway)
[00:12:51 CEST] <aib> by the way, 1-3 and 2-4 are siblings as expected. idle-priority thread on 1 slows down realtime-priority thread on 3 and vice versa :/
[00:13:19 CEST] <aib> ...but I don't even care that it's not harder to get the configuration I want. I have the answer to the riddle!
[00:13:27 CEST] <aib> s/not/now
[10:03:58 CEST] <Guest64222> Hello,
[10:07:27 CEST] <Guest64222> I am trying to build a C shared library using ffmpeg, I am using ffmpeg's static libraries. I am facing a problem when trying to use a lib which depends on an other one, for example I can use libavresample.a but not libavcodec.a. If my shared lib uses libavcodec.a, Dllimporting it fails. If I remove calls to libavcodec.a functions, it works again
[10:08:04 CEST] <Guest64222> Correction : "I can use libavutil.a but not libavcodec.a"
[10:08:52 CEST] <Guest64222> any thoughts ?
[10:30:51 CEST] <kam187> Hey guys I'm trying to enhance voice in a video using a lowpass and high pass filter
[10:30:57 CEST] <kam187> is there any way to set the gain?
[10:47:19 CEST] <oT2_> Do I have to includes shared libraries when using the static ones ? Every time I use a function of a static library which depends on an other ffmpeg lib, it fails
[11:31:08 CEST] <zerodefect> I'm decoding some PAL content and then re-encoding using the "mpegts" format which outputs it to udp using the mpeg2video codec...
[11:33:22 CEST] <Mavrik> Yay? :)
[11:33:29 CEST] <zerodefect> The issue I'm experiencing is that there are some artifacts in the video when viewed through ffplay.  The console output for ffplay indicates that "ac-tex damaged at xxx" and "Warning MVs not available".  Any tips on how I can investigate the source of my errors.  I'm using the C-API by the way, not console
[11:33:56 CEST] <Mavrik> Do you have that issue if you store output to a file?
[11:34:10 CEST] <zerodefect> Good question. Let me give that a go
[11:34:18 CEST] <Mavrik> Usually it's a buffering issue
[11:34:37 CEST] <Mavrik> Either you're overrunning the buffers somewhere (input in your API or output), have too high bitrate or the network is unreliable
[11:36:53 CEST] <zerodefect> I think you're spot on.  Playing output file through ffplay, no artifacts :)
[11:37:13 CEST] <zerodefect> Interesting that my bitrate is only 600,000. That's nothing.
[11:37:31 CEST] <zerodefect> Admittedly, I'm running Ubuntu Zesty in a VM hosted on Windows.
[11:37:51 CEST] <Mavrik> Usually it's the player input buffer that's funny
[11:37:58 CEST] <Mavrik> Also try using tcp :)
[11:38:41 CEST] <zerodefect> Ah ok.  For the record, I am timing the video so that the rate of transmission is same as the rate of playback.
[11:38:55 CEST] <Mavrik> Hmm
[11:39:01 CEST] <Mavrik> Are you compensating for bitrate spikes? :)
[11:40:16 CEST] <zerodefect> Are you talking about in the video encoder?  I haven't explicitly set CBR.  I'm guessing, I can't control the buffering in the sender?
[11:41:02 CEST] <Mavrik> Uhm... thing is... CBR is kinda rare when doing video
[11:41:11 CEST] <Mavrik> I'm not sure if ffmpeg's MPEG-2 encoder really does true CBR
[11:42:10 CEST] <zerodefect> Yeah, in transport streams there is usually stuffing that is introduced, right?
[11:42:25 CEST] <Mavrik> Depends on use-case.
[11:42:32 CEST] <Mavrik> Stuffing is really needed only for DVB-C/T
[11:42:47 CEST] <Mavrik> For majority of cases it's silly because you're wasting expensive bandwidth with stuffing :)
[11:43:10 CEST] <Mavrik> Better codecs (e.g. x264) actually rely on the fact that they can overrun bandwidth for awhile to get better quality.
[11:44:07 CEST] <zerodefect> How can I use TCP to test.  TCP is connection-oriented, so I need to establish a connection before sending/receiving, right?
[11:44:26 CEST] <Mavrik> I think if you just do tcp:// and run ffplay first it'll work
[11:44:40 CEST] <Mavrik> It's mostly just to test - it should show if your network is dropping packets or something
[11:45:12 CEST] <Mavrik> But I'm pretty sure that uneven bitrate is at fault if you have an algoritem taking CBR into account when sending data
[11:50:00 CEST] <zerodefect> Yeah, it's fine with TCP :)
[11:50:20 CEST] <zerodefect> Awesome cheers.
[11:51:16 CEST] <zerodefect> One last question...for now.  I'm feeding the encoder a interlaced frame, but it looks to output a progressive frame (according to ffplay).
[11:52:35 CEST] <Mavrik> zerodefect, check if your AVFrame is marked as interlaced before encoding
[11:52:55 CEST] <Mavrik> zerodefect, and make sure you enable interlaced encoding
[11:53:13 CEST] <Mavrik>         codec_context->flags |= (CODEC_FLAG_INTERLACED_DCT | CODEC_FLAG_INTERLACED_ME) on older, no idea what's it now with codecpar
[11:53:56 CEST] <Bruutal> i have 200,000.00 dollar to invest. what should i invest on?
[11:56:30 CEST] <zerodefect> Mavrik, I'll investigate that.  I'm not setting any of those flags.  Many thanks for your help :)
[11:56:48 CEST] <Mavrik> Also make sure the frame is actually interlaced :P
[11:56:59 CEST] <Mavrik> encoder won't interlace it for you ;P
[11:59:34 CEST] <zerodefect> yeah, just checked. 'interlaced_frame=1' and 'top_field_first=1'
[12:05:11 CEST] <zerodefect> Got interlaced going.  Checked the output (not into much detail), and it looks right on preliminary inspection.
[12:06:56 CEST] <zerodefect> Mavrik, do you think that it's the spikes in the video bitrate that causes the receiver's buffers to overflow?
[12:07:26 CEST] <Mavrik> I'd first check the network, VM network drivers can be wonky.
[12:11:07 CEST] <zerodefect> Ok. Thanks
[16:07:51 CEST] <Diego_> Hi there. I have a question about ffmpeg, as I'm using it for compiling audio and video sources into a one single video file. Anyone that could help me?
[16:09:27 CEST] <celyr> combining ?
[16:10:38 CEST] <Diego_> Yes, but I'm facing a different problem right now. I will try to explain myself as much as possible
[16:12:28 CEST] <Diego_> Well, what I'm doing right now, as I said, is compiling an audio and video into a single video file. The problem right now is that I record video and audio, simultaneously, from different sources. What I should do now is to combine them into different files. E.g: I have 2 sources, which generates 4 files (2 audios and 2 videos). When I combine them, I get 2 video files. What I want to achieve now is to combine those 2 output videos int
[16:13:23 CEST] <Diego_> "2 windows" in a single video, not just concatenate both
[16:14:25 CEST] <Diego_> I don't know if that is possible with FFMpeg
[16:16:53 CEST] <Diego_> I don't know if its quite clear
[16:24:46 CEST] <BtbN> do you mean a mosaic?
[16:25:32 CEST] <Diego_> Yes
[16:31:44 CEST] <durandal_1707> its FFmpeg
[17:01:35 CEST] <dantedevil> Hi, i've a problem with motion. I have a Rasperri Pi3 and 3 Ipcam.  Now i have 2 error looking my motionlog file.
[17:01:54 CEST] <dantedevil> [0:av1] [ERR] [ENC] [May 31 16:31:54] ffmpeg_avcodec_log: cabac decode of qscale diff failed at 56 13
[17:01:54 CEST] <dantedevil> [0:av1] [ERR] [ENC] [May 31 16:31:54] ffmpeg_avcodec_log: error while decoding MB 56 13, bytestream 397
[17:01:54 CEST] <dantedevil> [0:av2] [ERR] [ENC] [May 31 16:32:17] ffmpeg_avcodec_log: left block unavailable for requested intra mode at 0 24
[17:01:54 CEST] <dantedevil> [0:av2] [ERR] [ENC] [May 31 16:32:17] ffmpeg_avcodec_log: error while decoding MB 0 24, bytestream 1168
[17:02:05 CEST] <dantedevil> someone can help me
[17:02:09 CEST] <dantedevil> ??
[17:39:09 CEST] <PlanC> I'm streaming the output of ffmpeg to a browser and I can't get the duration to show properly
[17:39:52 CEST] <PlanC> since ffmpeg adds the duration once the entire file has been processed (since it doesn't know the duration before that) I'm having to specify it before based on the input length
[17:39:58 CEST] <PlanC> my command looks like this:
[17:40:39 CEST] <PlanC> ffmpeg -i video.mp4 -i audio.mp3 -c copy -metadata duration='00:01:00.00' output.mkv
[17:40:56 CEST] <PlanC> now this actually sets the duration to 1 minute in VLC
[17:41:14 CEST] <PlanC> but the problem is that as soon as I seek in the video, the VLC player crashes
[17:41:36 CEST] <PlanC> anyone know how I can stop that from happening?
[17:41:48 CEST] <BtbN> you can't seek in a live stream
[17:42:09 CEST] <BtbN> and a regular mkv file is invalid before the final "lead-out" has been written
[17:42:11 CEST] <PlanC> it's not a live stream though
[17:42:21 CEST] <BtbN> it is, if you try to play it before the file is done
[17:42:35 CEST] <BtbN> How the hell does it even take that long to do so with -c copy? It should be done in an instant
[17:42:53 CEST] <PlanC> it's not taking long
[17:43:14 CEST] <PlanC> I'm just streaming it before it ends
[17:43:29 CEST] <PlanC> so it doesn't have to wait 20-30 seconds before the download starts in the browser
[17:43:46 CEST] <BtbN> Use hls/dash for live streaming.
[17:44:04 CEST] <PlanC> hls/dash?
[17:44:06 CEST] <BtbN> I also don't think mkv is supported by browsers universally. Only safe bet is mp4
[17:44:13 CEST] <PlanC> so like separate video and audio?
[17:50:17 CEST] <PlanC> the reason I chose mkv is that it's really fast
[17:50:33 CEST] <PlanC> the speed is around 40x-50x
[17:50:52 CEST] <PlanC> but with mp4 it's at 2x-3x
[17:52:27 CEST] <PlanC> BtbN, is there any way to replicate the "lead-out" from the start?
[17:52:32 CEST] <BtbN> no
[17:52:38 CEST] <PlanC> what does it consist of?
[17:53:04 CEST] <PlanC> because I'm looking at the metainfo in VLC and the only things missing are the bitrate and duration
[17:54:46 CEST] <BtbN> a lot of things, like the duration, the seekhead with information on how to seek in the file(offets to specific frames), track masters
[17:55:27 CEST] <BtbN> if the seekhead is missing, the file cannot be seeked in
[17:55:37 CEST] <furq> what browser are you even playing mkv in
[17:55:38 CEST] <PlanC> the strange thing is that some of the mkv files work perfectly with just the "-metadata duration='00:01:00.00'"
[17:55:41 CEST] <furq> it's not supported in any without plugins afaik
[17:55:43 CEST] <PlanC> and I can even seek in those videos
[17:55:46 CEST] <BtbN> furq, I think firefox play it just fine
[17:55:50 CEST] <PlanC> but for some other files it just crashes
[17:55:59 CEST] <PlanC> I'm not playing them in the browser though
[17:56:02 CEST] <PlanC> I'm playing them in VLC
[17:56:02 CEST] <BtbN> The ones that are actually finished are obviously working
[17:56:09 CEST] <PlanC> none of them are finished
[17:56:14 CEST] <furq> 16:39:08 ( PlanC) I'm streaming the output of ffmpeg to a browser and I can't get the duration to show properly
[17:56:15 CEST] <PlanC> all are streamed
[17:56:39 CEST] <BtbN> you have to set -live 1 if you want to stream mkv.
[17:56:41 CEST] <PlanC> furq: as in streaming the data to the browser's file manager
[17:57:16 CEST] <PlanC> I'll try -live 1 and see how it goes
[17:57:19 CEST] <BtbN> Also, what the hell do you expect to happen if you instruct a player to seek to a segment that has not been streamed yet?
[17:57:34 CEST] <BtbN> If you stream, there is no duration, and no seeking.
[17:57:39 CEST] <BtbN> If you want those, use finalized files.
[17:57:43 CEST] <PlanC> no no
[17:57:50 CEST] <PlanC> the file is only played once the entire file is downloaded
[17:58:04 CEST] <BtbN> ?!
[17:58:11 CEST] <BtbN> You are making no sense to me
[17:58:21 CEST] <PlanC> how do I explain
[17:58:53 CEST] <BtbN> if you want to play a video in a browser, use mp4 and maybe set -movflags faststart
[18:00:11 CEST] <PlanC> as soon as ffmpeg starts processing the file and provides an output file
[18:00:16 CEST] <PlanC> e.g output.mkv
[18:00:34 CEST] <PlanC> I'm starting to download chunks from that output.mkv and sending it to the browser's download manager
[18:00:49 CEST] <PlanC> once ffmpeg is finished and every single chunk of output.mkv is sent
[18:00:52 CEST] <PlanC> I play the file in VLC
[18:00:53 CEST] <BtbN> you can't do that
[18:00:58 CEST] <PlanC> well it's working
[18:01:01 CEST] <PlanC> but I can't seek
[18:01:07 CEST] <BtbN> ffmpeg seeks back to the beginning of the file at the end, and writes the trailer.
[18:01:11 CEST] <PlanC> working as in video plays
[18:01:14 CEST] <PlanC> exactly
[18:01:17 CEST] <BtbN> So the chunks you sent are dummy-chunks, resulting in an invalid file.
[18:01:17 CEST] <PlanC> that's my problem
[18:01:31 CEST] <PlanC> the video plays perfectly in windows media player
[18:01:32 CEST] <PlanC> and mpc
[18:01:34 CEST] <PlanC> but not VLC
[18:01:44 CEST] <BtbN> It's an invalid file, it's pure luck. Don't do that.
[18:01:55 CEST] <PlanC> it's worked on a whole bunch of files though
[18:01:59 CEST] <PlanC> I've tried 10-15 files
[18:02:06 CEST] <BtbN> Generate it with -live 1 if you want to be able to do that. Will remove seeking/duration.
[18:02:23 CEST] <kepstin> Well, it's not really super invalid, it just will be missing the seek info because ffmpeg has to go and add that at the end.
[18:02:32 CEST] <PlanC> I really need the seeking though
[18:02:36 CEST] <kepstin> So if the player can seek without an index, it'll be seekable (but slow)
[18:02:40 CEST] <BtbN> don't send an unfinished file then
[18:03:06 CEST] <PlanC> yeah if I only could find a way to have that trailer added from the start
[18:03:08 CEST] <BtbN> kepstin, it will have markings that those things exist, but have dummy data in its place. Hence a player reading this might do unexpected things. Or crash.
[18:03:21 CEST] <BtbN> PlanC, the information needed for it are not known until the whole file has been generated.
[18:03:27 CEST] <BtbN> It has to be the last thing written.
[18:03:35 CEST] <PlanC> the only thing that isn't known is the duration, right?
[18:03:50 CEST] <BtbN> And all the segment offsets to generate the seekhead.
[18:04:02 CEST] <BtbN> Which is, as the name might suggest, what makes the file seekable.
[18:04:22 CEST] <PlanC> how difficult would it be to add the seekhead manually?
[18:04:30 CEST] <BtbN> from what?
[18:04:33 CEST] <PlanC> it's fine if it's off for 1-2 seconds
[18:04:43 CEST] <PlanC> based on the input file
[18:04:44 CEST] <BtbN> You don't have the neccesary information before the file is done.
[18:04:58 CEST] <furq> just use mpegts
[18:05:23 CEST] <BtbN> Just finalize the file before you start downloading it, I don't get it?!
[18:05:45 CEST] <PlanC> BtbN, but that would require me to wait until ffmpeg is done before I can start streaming
[18:05:47 CEST] <furq> i've given up on trying to understand what's actually happening
[18:05:56 CEST] <BtbN> you do that one time, and then offer the converted file.
[18:06:00 CEST] <furq> but mpegts will probably do what you want it to do
[18:06:12 CEST] <BtbN> mpegts is not seekable to begin with
[18:06:27 CEST] <kepstin> PlanC: you might be able to do some horrible hack where you skip the first few chunks in your dynamic download system, then only send them after ffmpeg has exited :/
[18:06:33 CEST] <PlanC> furq, mkv is supported by more players though
[18:06:34 CEST] Action: kepstin wouldn't recommend actually doing that
[18:06:59 CEST] <BtbN> What you are asking for is technically impossible, no matter how hard you try to argue.
[18:07:11 CEST] <PlanC> it's so close to working though
[18:07:16 CEST] <BtbN> Convert the file ahead of time.
[18:07:24 CEST] <PlanC> I've literally got it working in all players I've tested except vlc
[18:07:45 CEST] <BtbN> you can't get seeking working, as the seekhead has not been written.
[18:07:47 CEST] <kepstin> PlanC: well, "working", in that the other players have a slow fallback seek ability if there's no index available
[18:08:02 CEST] <PlanC> kepstin: but most players have that right
[18:08:10 CEST] <PlanC> (except VLC)
[18:08:16 CEST] <kepstin> sure, but you shouldn't rely on it.
[18:08:20 CEST] <BtbN> Why are you making your life that hard? Just store the converted file.
[18:08:48 CEST] <ritsuka> please don't create more broken files, there are already enough out there. So many hacks just to keep things working&
[18:09:03 CEST] <PlanC> BtbN: but that would require ffmpeg to finish first leading to a bunch of wasted time
[18:09:15 CEST] <BtbN> So run it ahead of time, not on the last second?
[18:09:24 CEST] <PlanC> what do you mean?
[18:09:26 CEST] <BtbN> You said your content is not live, so what's the issue with that?
[18:09:51 CEST] <kepstin> is this user-uploaded media? I guess you're trying to reduce turn-around time
[18:09:59 CEST] <PlanC> but ffmpeg would have to finish completely and then I could start sending the chunks
[18:10:01 CEST] <PlanC> kepstin, yeah exactly
[18:10:21 CEST] <kepstin> PlanC: if you want to send stuff streaming or in chunks, then use a streaming/chunked format
[18:10:23 CEST] <PlanC> kepstin, it's a real waste of time to have them wait 20-30 seconds before the download starts
[18:10:43 CEST] <kepstin> consider doing something crazy like doing a remux into mkv in javascript in the browser :/
[18:10:44 CEST] <BtbN> good luck with your brokenness then, I'm out of idea what else to tell you.
[18:10:44 CEST] <furq> it's also a waste of time if you send them a broken file
[18:10:48 CEST] <PlanC> kepstin, which formats are "streamable"?
[18:11:11 CEST] <BtbN> mkv with -live 1, mpegts, hls, dash, fragmented mp4, ...
[18:11:11 CEST] <kepstin> PlanC: mpegts, any segmented format, mkv without a seek index.
[18:11:27 CEST] <BtbN> All of them are not seekable by definiton.
[18:11:33 CEST] <BtbN> And have no inherent duration
[18:11:42 CEST] <BtbN> you can't have both.
[18:12:15 CEST] <furq> vlc should at least be able to seek in mpegts because it's expecting there to be no index
[18:12:24 CEST] <furq> it'll be slow, obviously
[18:12:39 CEST] <PlanC> both are needed though
[18:12:54 CEST] <PlanC> video without capability to seek is pretty much useless no?
[18:13:12 CEST] <BtbN> You can bash your head against that wall as much as you like. Not possible.
[18:13:13 CEST] <kepstin> PlanC: I dunno how exactly you're building/saving the file, but if you can seek in the saving code then just go back and update the start of the file after ffmpeg has exited :/
[18:13:42 CEST] <BtbN> kepstin, he's offering them for download, and starts the download before the file is done...
[18:13:53 CEST] <PlanC> yeah
[18:14:09 CEST] <PlanC> so the bytes that are sent to the browser and out of my control
[18:14:10 CEST] <kepstin> if it's just going through the browser, then yeah, the only solution is a time machine
[18:14:11 CEST] <PlanC> I can't change those
[18:14:17 CEST] <Fenrirthviti> Why are you not storing them already converted? That's just crazy
[18:14:27 CEST] <kepstin> and if you had one of those, presumably you wouldn't be asking us about this
[18:14:33 CEST] <Fenrirthviti> Trying to remux as part of a download operation is insane
[18:14:39 CEST] <PlanC> Fenrirthviti, storage restrictions
[18:14:55 CEST] <BtbN> again, it's simply not possible, nothing else to tell you.
[18:15:08 CEST] <Fenrirthviti> Store in a better format with better compression then?
[18:15:21 CEST] <Fenrirthviti> This sounds like the worst possible way to work around storage restrictions.
[18:15:36 CEST] <furq> i still have no idea what's actually happening here
[18:15:47 CEST] <furq> the best thing i can come up with is some kind of website that remuxes to mkv
[18:15:58 CEST] <BtbN> someone is upset that pigs can't fly.
[18:16:05 CEST] <furq> well yeah i got that much
[18:16:10 CEST] <Fenrirthviti> There's a whole lot of pieces to this story missing.
[18:16:14 CEST] <furq> but i want to know why
[18:16:17 CEST] <Fenrirthviti> Like, why the source files just can't be offered for download?
[18:16:18 CEST] <furq> i won't be able to sleep at night
[18:16:43 CEST] <BtbN> furq, I think he's trying to build a custom YouTube, but wants to offer the video for playback absolutely immediately?
[18:17:09 CEST] <kepstin> if it was just for playback, they'd use HLS or something, which is (sort of) seekable immediately while streaming :/
[18:17:19 CEST] <furq> two of the selling points of youtube, at least for me, are that it stores the video and that it plays the video in the browser
[18:17:23 CEST] <furq> so i don't think that's it
[18:17:31 CEST] <kepstin> it's the "download an mkv file as it's being encoded" that's the problem here.
[18:17:36 CEST] <BtbN> Not even HLS/DASH is seekable immediately. The playlist with duration information is written at the very end as well
[18:18:17 CEST] <kepstin> BtbN: you could hack it by pretending to be a live stream until the full encode is done, i guess.
[18:18:37 CEST] <BtbN> But he insists on it being seekable right away.
[18:18:44 CEST] <BtbN> Which is outright impossible
[18:18:50 CEST] <kepstin> but the usual solution to this is to segment the file before encoding and throw ridiculous amounts of computing hardware to encode the video quickly.
[18:18:57 CEST] <PlanC> what's kind of weird is that I can't just add the trailer to the end of the file
[18:18:58 CEST] <kepstin> then you get fast turnaround and complete files
[18:18:59 CEST] <furq> is he even encoding it
[18:19:02 CEST] <furq> i thought he was copying
[18:19:05 CEST] <PlanC> I really can't figure out why that isn't possible
[18:19:22 CEST] <Fenrirthviti> because that's not how it works.
[18:19:23 CEST] <kepstin> PlanC: the trailer is added at the end, but it has to go back and stick a value in the header to tell the player where to find the trailer
[18:19:26 CEST] <BtbN> furq, even without encoding, the muxer still only has the required information when all packets are muxed
[18:19:30 CEST] <furq> well yeah
[18:20:05 CEST] <Fenrirthviti> The headers are read already by the player, so when it gets added later, the file would have to be reloaded which sounds like it's defeating the whole point of this endeavor, whatever that may be
[18:20:30 CEST] <Fenrirthviti> I think storing the files better in the first place is the better solution :\
[18:20:53 CEST] <PlanC> storage limit otherwise I would
[18:21:10 CEST] <Fenrirthviti> so your source is a live stream?
[18:21:13 CEST] <Fenrirthviti> or what here?
[18:21:18 CEST] <PlanC> no
[18:21:31 CEST] <PlanC> it's for college
[18:21:32 CEST] <Fenrirthviti> I'm confused why you can't just offer the original source file and why you need to remux then
[18:21:45 CEST] <kepstin> PlanC: in these days of amazon giving out terabytes of storage for cents, a storage limit seems ridiculous :/
[18:21:53 CEST] <furq> for cents per hour
[18:21:57 CEST] <PlanC> we have a huge ton of recorded lecture material which is stored with separate audio and video
[18:22:25 CEST] <Fenrirthviti> Ah ha.
[18:22:29 CEST] <PlanC> it's good to play online but if you want to play it locally on a video player it gets annoying
[18:22:35 CEST] <furq> oh shit we're getting somewhere
[18:22:44 CEST] <Fenrirthviti> See, now things are starting to make more sense, sort of
[18:22:48 CEST] <PlanC> this is why I want to combine them and stream on the fly
[18:22:57 CEST] <furq> in this case the sensible thing to do is remux it all to mp4 and delete the originals
[18:23:05 CEST] <kepstin> PlanC: then... remux to mp4 and throw out the originals? then it'll play in both browser and download
[18:23:11 CEST] <furq> ^5
[18:23:19 CEST] <Fenrirthviti> which is what I said 15 minutes ago \o/
[18:23:27 CEST] <furq> you must have one of those crystal balls
[18:23:32 CEST] <PlanC> the data is huge though
[18:23:38 CEST] <PlanC> several TB
[18:23:40 CEST] <furq> it'll be exactly as huge after it's remuxed
[18:23:49 CEST] <Fenrirthviti> remux shouldn't really change size much, if at all
[18:23:57 CEST] <PlanC> all on a really weak processor that is just designed to do i/o
[18:24:03 CEST] <furq> the processor doesn't matter
[18:24:07 CEST] <furq> you're remuxing
[18:24:18 CEST] <Fenrirthviti> it's a disk speed operation at that point
[18:24:19 CEST] <PlanC> won't that take an insane amount of time to do?
[18:24:29 CEST] <kepstin> of course, this depends on the codecs in the original files
[18:24:35 CEST] <furq> if it's h264 video and aac/mp3 audio then no
[18:24:40 CEST] <kepstin> if they're something that can't be muxed into mp4 then this'll be harder
[18:24:57 CEST] <kepstin> but if the codecs are ok, then just use -c copy and be happy.
[18:25:07 CEST] <furq> and if it's not h264 video and aac/mp3 audio then you should go to a different college
[18:25:31 CEST] <Fenrirthviti> I'd even remove the /mp3 from that statement at this point :P
[18:25:38 CEST] <furq> but yeah the overhead of muxing to mp4 should be well under 1%
[18:25:50 CEST] <furq> even less if the originals are already in m4v/m4a
[18:26:40 CEST] <PlanC> not sure what to do really
[18:26:54 CEST] <BtbN> Convert the whole collection to faststarting mp4.
[18:26:54 CEST] <PlanC> the best solution would be the mkv solution since the videos actually do play
[18:27:13 CEST] <BtbN> You can get rid of the originals once that's done
[18:27:21 CEST] <Fenrirthviti> That's actually the worst solution, not sure why you think it's the best
[18:27:26 CEST] <BtbN> In theory even while it's running, but I'd want to verify that all the conversions worked.
[18:27:29 CEST] <Fenrirthviti> and that will never work, as has been stated several times.
[18:27:55 CEST] <furq> i'd be happy if you went with the mkv solution if you went on a campaign to ban vlc on your campus
[18:27:55 CEST] <kepstin> unless you have Fenrirthviti's crystal ball, to read the mkv headers before they're written :/
[18:28:00 CEST] <PlanC> it does work although it relies on the fallback of the video players as you said
[18:28:06 CEST] <furq> that would be a sacrifice worth making
[18:28:26 CEST] <BtbN> it's incredibly broken, just don't do that.
[18:28:48 CEST] <PlanC> wouldn't it be possible to somehow move the headers to the end of the file and have line in the start that points to them?
[18:29:00 CEST] <furq> yes
[18:29:06 CEST] <PlanC> so I'd have the trailer and all other data in the end
[18:29:06 CEST] <kepstin> PlanC: that's exactly what happens already
[18:29:07 CEST] <furq> you do that by waiting until the mkv has been finished
[18:29:24 CEST] <Fenrirthviti> -c copy -movflags +faststart out.mp4 problem solved '.')b
[18:29:25 CEST] <kepstin> PlanC: but you have to update the field at the start once you find out where the end bit is, so the player can find it
[18:29:26 CEST] <PlanC> but when it finishes it adds it to the start not the end, right?
[18:29:53 CEST] <kepstin> PlanC: by default it's added at the end, but the poiner at the start can't be set until you know where "the end" is
[18:29:54 CEST] <Fenrirthviti> If you start playing it before the file is finalized, it will never work
[18:29:56 CEST] <Fenrirthviti> no matter what you do.
[18:30:06 CEST] <furq> how are you going to access the end of the file if the entire point of this is that you don't want to wait until the file has finished being written
[18:30:25 CEST] <Fenrirthviti> You would have to close and reopen the file after the files are finalized, which is not something you will have control to do if you're playing it in a local player
[18:31:12 CEST] <PlanC> but I wonder if it'd be possible to estimate where the end is based on the input audio and video
[18:31:22 CEST] <furq> sure it would
[18:31:26 CEST] <furq> but ffmpeg doesn't do that
[18:31:32 CEST] <furq> you'd have to write your own remuxer
[18:31:32 CEST] <PlanC> I'm just copying the data into the mkv and file size is usually input video + input audio
[18:31:36 CEST] <kepstin> PlanC: just batch remux all your files. done. :/
[18:31:47 CEST] <furq> also yeah why did you just ignore the thing we all said you should do
[18:32:02 CEST] <PlanC> you mean remuxing all the files?
[18:32:05 CEST] <furq> yes
[18:32:39 CEST] <Fenrirthviti> Let's start here... What is the format of the original video and audio files?
[18:33:17 CEST] <PlanC> webm
[18:33:27 CEST] <PlanC> both audio and video
[18:33:42 CEST] <furq> are these dash fragments
[18:33:44 CEST] <Fenrirthviti> webm is a container, what's inside it?
[18:33:50 CEST] <kepstin> ... well, that's annoying, but it means you just have to remux them into webm. no real problem.
[18:34:03 CEST] <kepstin> webm is only allowed to contain vp8, vp9, vorbis, and opus
[18:34:15 CEST] <furq> if they're dash fragments then there's a corresponding playlist which any decent media player will play back
[18:34:24 CEST] <Fenrirthviti> true, I guess it doesn't matter at that point.
[18:34:43 CEST] <Fenrirthviti> but remuxing to webm isn't that big of a deal
[18:34:51 CEST] <furq> even if they're not you could presumably just generate a dash manifest for each
[18:35:18 CEST] <PlanC> some of the files are inactive so it would also be a waste to process those as well
[18:35:24 CEST] <kepstin> PlanC: but if both inputs are just plain webm files, then 'ffmpeg -i video.webm -i audio.webm -c copy combined.webm' will be superfast and make you a single webm with both audio and video, which can be downloaded or used in the browser.
[18:35:32 CEST] <kepstin> then delete the original separate webms, done.
[18:36:17 CEST] <Fenrirthviti> most everything these days should play webm, so you don't need to convert to mkv or anything
[18:36:45 CEST] <kepstin> note that webm is basically a ... profile? ... of matroska with the codecs permitted limited - most players support both
[18:37:46 CEST] <Fenrirthviti> That actually reminds me, I was going to do latency tests with streaming webm through icecast
[18:38:02 CEST] <Fenrirthviti> Gotta find a low-latency replacement for stinking rtmp one of these days :x
[18:38:03 CEST] <furq> PlanC: do you have .mpd manifests for each of these lectures
[18:38:17 CEST] <furq> or is it just one webm for video and one for audio per lecture
[18:38:40 CEST] <furq> if you have manifests then vlc/mpv etc should be able to play those directly
[18:40:51 CEST] <PlanC> no manifests
[18:40:56 CEST] <PlanC> just a bunch of webm files
[18:41:04 CEST] <furq> shame
[18:41:12 CEST] <furq> i would recommend just creating manifests instead of remuxing
[18:41:21 CEST] <furq> since that'd be non-destructive and quicker
[18:41:43 CEST] <PlanC> do audio files also act in the same way?
[18:41:45 CEST] <furq> but idk of a tool that generates them for existing videos (maybe ffmpeg does?) and apparently vlc stable doesn't play them back
[18:41:52 CEST] <furq> you'd need vlc beta
[18:42:04 CEST] <furq> and if this is for anyone on campus to use then that's probably a non-starter
[18:42:41 CEST] <PlanC> I'll actually try vlc beta on the non-seekable mkvs and see if it works
[18:42:55 CEST] <furq> that was not what i was hoping you'd take away from this, but ok
[18:42:58 CEST] <BtbN> they are not non-seekable, they are broken.
[18:43:19 CEST] <BtbN> I don't get your obsession with a "solution" that has been pointed out as bad and broken to the bone multiple times.
[18:43:45 CEST] <kepstin> i mean, ffmpeg does try to make them broken in a way that they're still playable, so you can preview/recover incomplete encodes, but still.
[18:44:04 CEST] <BtbN> It will write a dummy pointer to the header at the end
[18:44:09 CEST] <BtbN> and no indication it is missing
[18:44:17 CEST] <BtbN> what happens with that is not well defined
[18:44:26 CEST] <BtbN> VLC seems to just try to seek there, and in turn crash
[18:44:28 CEST] <PlanC> I know it's not an orthodox way of doing it
[18:44:39 CEST] <PlanC> but if all the players are able to play the video then why not?
[18:44:40 CEST] <BtbN> There have been numerous proper ways pointed out...
[18:44:53 CEST] <BtbN> Because it's broken and can randomly fail at any point.
[18:45:04 CEST] <PlanC> they require processing of all the files beforehand though(?)
[18:45:10 CEST] <BtbN> yes, so?
[18:45:28 CEST] <BtbN> Ever seen what YouTube does? Sometimes for days before a video goes live?
[18:45:35 CEST] <PlanC> I also tried vlc beta and it's surprisingly able to seek in the broken mkvs
[18:45:57 CEST] <BtbN> Seems like they fixed the crash then, but it can't seek properly, it's just technically impossible
[18:45:57 CEST] <PlanC> but they have entire dcs at their disposal
[18:46:07 CEST] <BtbN> You just do it ONCE
[18:46:12 CEST] <kepstin> PlanC: just remux the audio and video files together into a single webm in advance, that's a super fast lossless conversion, and you can delete the original files if you are short on space.
[18:46:12 CEST] <PlanC> BtbN, no it actually seeks
[18:46:25 CEST] <BtbN> it just fast-forwards until it reaches the desired timestamp.
[18:46:27 CEST] <PlanC> but that once applies to so many files
[18:46:31 CEST] <BtbN> wouldn't call that seeking.
[18:47:07 CEST] <BtbN> Seeking backwards goes back to the beginning, and fast-forwards again
[18:47:44 CEST] <PlanC> no I can actually go to different parts of the video
[18:47:55 CEST] <PlanC> the only problem is that it sort of lags though
[18:47:56 CEST] <Fenrirthviti> It's not actually seeking though.
[18:48:05 CEST] <PlanC> I guess that my only is to remux the entire thing
[18:48:06 CEST] <BtbN> And I just explained you how it does that...
[18:50:05 CEST] <Fenrirthviti> wonder what happens when you try to skip to the part of the file that isn't remuxed yet :P
[19:53:03 CEST] <Guest4761> Hi everyone, just to know : If I concat 2 videos, with a different resolution, is it supposed to work ?
[19:53:17 CEST] <Guest4761> with the concat demuxer
[19:56:10 CEST] <Guest4761> Is the mp4 format OK with different resolutions ?
[19:57:05 CEST] <Guest4761> It seems facebook, VLC will play a video with different resolutions, but it will take some time to go from a video to another one
[19:57:37 CEST] <DHE> it's not the file format's choice. and generally speaking it's not reliable to change resolution - concat only officially supports nigh-identical encoder settings
[19:57:50 CEST] <DHE> even mixing and matching x264 encoder options might not work, for example
[20:29:08 CEST] <ac_slater_> alright guys, I have a super weird issue (ffmpeg 3.2). I have an h264 file (annex b) that I mux into mpegts via `ffmpeg -i file.h264 -vcodec copy -f mpegts file.ts` if I strip out the h264 file from the ts file (invert what I did), the md5sums dont match
[20:29:26 CEST] <ac_slater_> ie - the mpegts muxer doesnt seem to be invertible :(
[20:29:58 CEST] <ac_slater_> it's also adding nal type 9 and sometimes 14 (which are both not really valid for annex b h264)
[20:34:47 CEST] <furq> are you sure it's the mpegts muxer and not the h264 muxer
[20:37:36 CEST] <BtbN> you should never ever deal with raw .h264 files
[20:37:46 CEST] <BtbN> h264 without a container is incomplete
[21:12:15 CEST] <ac_slater_> furq: what's an h264 muxer? Basically I expect the h264 file going into the mpegts to be the same thing coming out (if I do -vcodec copy)
[21:13:17 CEST] <ac_slater_> BtbN: right, I'm actually writing an interface to an encoder with the libs. But stupidly the encoder spits out huge data so it's actually fed to me as an mpegts stream before I can pipe it to the right place
[21:13:35 CEST] <ac_slater_> so h264->mpegts->h264->[what I really want to do with it]
[21:13:48 CEST] <BtbN> hm?
[21:14:04 CEST] <ac_slater_> but that wont work if I cant retrieve the input nearly untouched from the mpegts mux in the middle
[21:14:24 CEST] <ac_slater_> BtbN: that doesnt make sense? Which part?
[21:14:57 CEST] <BtbN> You have an application that gives you a raw h264 file?
[21:15:13 CEST] <BtbN> and another one that takes it? And in between you use mpegts?
[21:16:23 CEST] <ac_slater_> BtbN: yea its super weird. Some device is encoding video into h264. The only thing that device speaks is IP so they pack the encoded h264 into mpegts and send it to me. But I really want the raw bitstream
[21:17:12 CEST] <BtbN> why?
[21:17:18 CEST] <BtbN> raw bitstream is lacking any timing information
[21:17:31 CEST] <ac_slater_> we at least know that ahead of time
[21:17:43 CEST] <ac_slater_> rate, etc
[21:20:59 CEST] <ac_slater_> I tested this pipeline outside of the streaming thing I just mentioned
[21:21:16 CEST] <ac_slater_> I just took an h264 file, muxed it with mpegts, then unmuxed it back to h264 and the md5sums dont match
[21:21:19 CEST] <ac_slater_> should they?
[21:21:44 CEST] <aptalca> Hi guys, I keep getting "Segmentation fault (core dumped)" whenever I try nvenc or cuvid (or both). I used the johnvansicle build as well as compiled it myself with nvenc and the result is the same. The machine is an ubuntu 16 VM (kvm) with a GT710 passed through. I have nvidia-375 drivers installed as well as cuda 8. FWIW, plex media server, which uses a forked version of ffmpeg can use nvenc with no problems on the same
[21:21:44 CEST] <aptalca> machine with the same media so I don't think it's a hardware or an OS problem. Any way I can get more info or logs? Here's the log I have, which doesn't say much: http://sprunge.us/JbZd
[21:23:53 CEST] <BtbN> Unless you use the bitexact flags, I wouldn't expect them to
[21:24:06 CEST] <BtbN> And even then I'm not sure if all involved components support it
[21:24:06 CEST] <DHE> ac_slater_: possibly an annex-B mismatch?
[21:24:11 CEST] <ac_slater_> aptalca: try to query your gpus and see "ffmpeg  -f lavfi -i testsrc -vcodec h264_nvenc -gpu list -f null -"
[21:24:50 CEST] <furq> you should have an ffmpeg_debug binary from when you built it
[21:25:02 CEST] <furq> you should probably run that with gdb and get a backtrace
[21:25:30 CEST] <ac_slater_> DHE: I'm inserting annexb into the mux and definitely getting annexb out. But I think I found the mismatch. For some reason, when muxing, NAL unit type 9 is added when SPS/PPS occurs
[21:25:33 CEST] <aptalca> ac_slater_: that line also gave me a seg fault
[21:25:44 CEST] <ac_slater_> aptalca: shux sorry man
[21:25:56 CEST] <aptalca> lol
[21:26:04 CEST] <ac_slater_> aptalca: I think the nvidia library is trying to dynamically load a shared library you dont have
[21:26:40 CEST] <ac_slater_> aptalca: you should have had it in the driver distribution but I'm not sure why. Just rebuild ffmpeg yourself to see if you have the required libs
[21:26:53 CEST] <ac_slater_> aptalca: https://developer.nvidia.com/ffmpeg
[21:27:01 CEST] <aptalca> ok, I'll try to rebuild again
[21:27:24 CEST] <ac_slater_> aptalca: first compile the cuda example for deviceQuery to see if CUDA is working
[21:27:30 CEST] <ac_slater_> (and run it)
[21:27:35 CEST] <furq> ac_slater_: was that the exact command you ran
[21:27:50 CEST] <ac_slater_> furq: for what?
[21:27:56 CEST] <furq> i can't even mux .264 into mpegts, it just gives me a pts unset error
[21:28:14 CEST] <ac_slater_> furq: do this `ffmpeg -i file.h264 -vcodec copy -f mpegts file.ts`
[21:28:31 CEST] <BtbN> you need to add -r 50 or something as input option, so it has a framerate
[21:28:32 CEST] <ac_slater_> furq: then `ffmpeg -i file.ts -vcodec copy file2.h264`
[21:28:41 CEST] <furq> yeah that doesn't work here
[21:28:48 CEST] <furq> doesn't work with -r 30 either
[21:28:57 CEST] <ac_slater_> hmm works for me
[21:29:02 CEST] <furq> maybe something changed in 3.3
[21:29:04 CEST] <ac_slater_> it's finding the right FPS as well
[21:29:08 CEST] <ac_slater_> but maybe I'll force it
[21:29:16 CEST] <BtbN> there is no fps to be found in a .h264 file
[21:29:20 CEST] <BtbN> it's just a series of raw frames
[21:29:23 CEST] <ac_slater_> good point
[21:29:27 CEST] <furq> yeah i was curious how your command worked without -r
[21:29:31 CEST] <ac_slater_> maybe it defaults to 25 and my source is 25
[21:29:36 CEST] <furq> but it doesn't work at all for me, even with it
[21:30:43 CEST] <ac_slater_> hmm maybe -r is broken
[21:30:50 CEST] <ac_slater_> cause it's not working when I try to force 30 for example
[21:30:53 CEST] <furq> it still works as expected with mp4
[21:30:56 CEST] <ac_slater_> hmm
[21:31:19 CEST] <furq> where did you get the h264 es from
[21:31:28 CEST] <ac_slater_> I can send you the one I'm using
[21:31:33 CEST] <ac_slater_> furq: it's 50 mb
[21:31:46 CEST] <ac_slater_> let me make it smaller
[21:31:46 CEST] <furq> i'm not really expert enough to diagnose it from that
[21:31:52 CEST] <furq> but i got mine from -f lavfi -i testsrc=d=5
[21:31:56 CEST] <ac_slater_> right, I'm just saying it didnt seem to matter
[21:32:01 CEST] <ac_slater_> but the testsrc works too
[21:32:04 CEST] <BtbN> you have to put -r in front of -i
[21:32:07 CEST] <furq> was yours generated by ffmpeg
[21:32:09 CEST] <BtbN> otherwise it's an output option.
[21:32:17 CEST] <ac_slater_> testsrc + x264 is enough to show that the muxer is not invertible for me
[21:32:19 CEST] <furq> that's all i'm wondering about
[21:32:33 CEST] <ac_slater_> yea
[21:32:37 CEST] <furq> weird
[21:33:04 CEST] <ac_slater_> my target is a hardware encoder but even files encoded with x264 resemble the same properties
[21:33:21 CEST] <furq> why does it actually matter if it's invertible
[21:33:28 CEST] <BtbN> I still don't get why you do that weird dance with raw h264 files. Just transcode the .ts you get?
[21:33:34 CEST] <furq> and also yeah that
[21:33:49 CEST] <ac_slater_> eh
[21:33:54 CEST] <furq> i mean i guess you're going back to 264 to verify it's identical
[21:34:00 CEST] <ac_slater_> there are all tiny devices
[21:34:09 CEST] <furq> but i don't see why that matters as long as the video streams are identical (-f hash)
[21:34:14 CEST] <ac_slater_> the place where the raw streams ends up cant reencoder
[21:34:17 CEST] <ac_slater_> reencode *
[21:34:33 CEST] <BtbN> this is pure remuxing though, no encoding involved
[21:34:38 CEST] <ac_slater_> oh right
[21:34:42 CEST] <furq> yeah what does that have to do with the format
[21:34:51 CEST] <ac_slater_> BtbN: I think the mpegts muxer is just spitting out a bad h264 file
[21:35:01 CEST] <BtbN> I doubt that
[21:35:02 CEST] <ac_slater_> "spitting out" when I demux
[21:35:09 CEST] <furq> like i said, if -f hash matches up then i don't see the problem
[21:35:18 CEST] <ac_slater_> I mean, it does contain nal 0 which is an error
[21:35:23 CEST] <ac_slater_> they dont match furq
[21:35:35 CEST] <furq> i mean the ffmpeg hash muxer, not just md5sum
[21:35:39 CEST] <ac_slater_> ohhh
[21:35:43 CEST] <ac_slater_> let me try that
[21:36:26 CEST] <furq> that decodes the streams and hashes them, so if those are different then you've got big problems
[21:42:20 CEST] <ac_slater_> hmm well
[21:42:25 CEST] <ac_slater_> I think you guys are right
[21:42:44 CEST] <ac_slater_> but I still think there is a bug somewhere or my input file is just really bad
[21:47:13 CEST] <ac_slater_> but doing to mux+unmux with -f hash between everything did yield the same hash
[21:47:43 CEST] <ac_slater_> md5sum on the raw files is still a mismatch which is weird
[21:47:51 CEST] <ac_slater_>  but maybe ok
[21:48:11 CEST] <c_14> date header of some type probably
[21:48:12 CEST] <furq> the hash muxer hashes the decoded pictures, so if they're packed differently then that makes sense
[21:48:21 CEST] <ac_slater_> yea
[21:48:31 CEST] <ac_slater_> thanks guys
[21:48:32 CEST] <furq> but yeah if you just want to check two streams are identical then that's what you want
[21:48:38 CEST] <furq> file hashing is pretty useless at that
[21:48:39 CEST] <ac_slater_> so awesome, thanks furq
[21:48:56 CEST] <furq> or two streams decode identically, rather
[21:48:56 CEST] <ac_slater_> c_14: yea probably
[22:02:44 CEST] <ac_slater_> well my final verdict is that the code I wrote against libavformat/codec is weird. I basically just construct a format context against the input, and read AVPackets in a loop appending them to a file. Essentially, I wrote `ffmpeg -i file.ts -vcodec copy file2.h264`
[22:02:53 CEST] <ac_slater_> and THAT file is hashing differently
[22:02:57 CEST] <ac_slater_> so there is a something
[22:05:36 CEST] <ac_slater_> ah ha!
[22:05:51 CEST] <ac_slater_> I found which case makes it shit itself
[22:08:19 CEST] <ac_slater_> I tried using udp as input to just try to chain these pipelines together with the network as opposed to just trying it on raw files. Raw files always works (hashes are file). But it appears things are SUPER WEIRD over even localhost udp. I'm seeing some loss I think
[22:08:24 CEST] <ac_slater_> anyway. thanks guys
[22:10:40 CEST] <Bruutal> i have 200,000.00 dollar to invest. what should i invest on?
[22:11:16 CEST] <atomnuker> bitcoin
[22:12:02 CEST] <ac_slater_> pizza
[22:15:03 CEST] <furq> what did you spend the other $50,000 on
[22:32:33 CEST] <durandal_170> furq: on sex, drugs and roqnroll
[23:15:53 CEST] <Tatsh> finally got a hold on nvenc
[23:16:00 CEST] <Tatsh> -qp is the key
[23:16:12 CEST] <Tatsh> which is similar but not quite the same as -crf
[23:16:22 CEST] <Tatsh> and it's very touchy depending on what resolution you have
[23:18:36 CEST] <Tatsh> 480p = 60x speed :)
[00:00:00 CEST] --- Thu Jun  1 2017