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

[burek]

[02:10:03 CEST] <ZexaronS> hello
[02:10:09 CEST] <ZexaronS> so these media players
[02:10:18 CEST] <ZexaronS> all rely on external dependencies
[02:10:44 CEST] <ZexaronS> can't I just play a MP4 on any platform without worrying if they have installed their OS correctly ?
[02:11:04 CEST] <c_14> statically link your media player against libav*
[02:11:28 CEST] <ZexaronS> Basically, is it going to automatically use the appropriate player on their system, I see a bunch of different players
[02:11:40 CEST] <c_14> what?
[02:11:49 CEST] <ZexaronS> in plugins
[02:11:55 CEST] <ZexaronS> i see WMP, Apples, and Androids
[02:12:19 CEST] <c_14> what's the problem you're having?
[02:12:35 CEST] <ZexaronS> They're all enabled on default
[02:12:54 CEST] <ZexaronS> I hope static linking is simple enough, programming skill needed ?
[02:13:20 CEST] <ZexaronS> throught BPs or need C++ ?
[02:13:29 CEST] <c_14> you don't need to program, but you need to know some basics
[02:13:33 CEST] <c_14> like how to compile things
[02:14:31 CEST] <ZexaronS> compile libav ?
[02:14:46 CEST] <c_14> https://trac.ffmpeg.org/wiki/CompilationGuide
[02:14:53 CEST] <furq> what's your actual question
[02:15:47 CEST] <ZexaronS> Never done that but it's always a first time, I have some knowledge yes I did programming before, but not in c++ like deeply
[02:17:12 CEST] <ZexaronS> However, if I choose not to link, if they play this, it'll just play the video if their apple, andorid or windows is set up correctly, so I don't have to do any platform specific things on my project ?
[02:17:47 CEST] <ZexaronS> I thought linking was just adding a dll, not sure why compilation is needed
[02:18:14 CEST] <c_14> you compile source code to get the objects that you link
[02:18:19 CEST] <ZexaronS> This project is meant for desktop so yeah i can ignore the mobile stuff
[02:19:24 CEST] <ZexaronS> oh so there is no libav.dll anywhere, i expected it would
[02:40:23 CEST] <ZexaronS> Haven't done anything yet, at least I know it's possible, that helped
[02:43:28 CEST] <ZexaronS> c_14: Okay, I see tutorials making "Media Player" but that's some thing from the plugins, how is this static linking going to work with that, can I just proceed following tutorials ?
[02:43:58 CEST] <ZexaronS> or I have to make my own plugin
[02:44:14 CEST] <c_14> plugin for what?
[02:44:30 CEST] <ZexaronS> to play video
[02:44:57 CEST] <c_14> I'm still not sure what you're trying to do here
[02:44:58 CEST] <ZexaronS> x264, vp9, vp8, x265
[02:45:11 CEST] <ZexaronS> those 4 should be enough
[02:45:17 CEST] <c_14> 2 of those are encoders, not codecs
[02:45:38 CEST] <ZexaronS> and audio ofcourse, mp3, aac, ac3, vorbis
[02:45:45 CEST] <ZexaronS> that would be enough for my needs
[02:45:59 CEST] <ZexaronS> if it's anything out of that i can recode those occurences
[02:47:20 CEST] <ZexaronS> There is Media Player, Media Texture, probably have to first figure out the difference
[02:49:39 CEST] <ZexaronS> Aaa now i see in the settings, player overrides, automatic, oh that explains a lot
[02:52:30 CEST] <ZexaronS> eh
[02:52:40 CEST] <ZexaronS> failed to import .webm unknown extension
[02:52:47 CEST] <ZexaronS> meh i'll continue in morning doesn't look good
[02:53:05 CEST] <ZexaronS> what a deal breaker omg
[02:53:22 CEST] <dj_una> Hi everyone, im currently pushing my signal from my local computer to a remote server with nginx rmtp module installed. I can play that signal fine, my problem comes when I wanna push this signal from my remote rmtp server and forward it to Twitch. Here is my cmd line currently: ffmpeg -threads 12 -i rtmp://localhost:1935/transcode/gee -vcodec libx264 -profile:v main -preset:v ultrafast -r 60
[02:53:23 CEST] <dj_una> -g 120 -sc_threshold 0 -b:v 4500k -maxrate 4500k -bufsize 4500k -acodec copy -b:a 96k -ar 48000 -ac 2 -f flv rtmp://live-arn.twitch.tv/app/STREAMKEY_CENSORED
[02:53:59 CEST] <dj_una> any ideas? the fps is everything else than constant, same goes for bitrate
[02:54:45 CEST] <dj_una> Im on Windows btw
[02:55:47 CEST] <ZexaronS> OOOOOOOOOOOOOOOOOOOOOP
[02:56:10 CEST] <ZexaronS> c_14, furq, sorry, I thought I was in the unreal engine channel
[02:56:17 CEST] <ZexaronS> oops
[03:37:48 CEST] <thebombzen_> Wait how does yuv420p interact with interlaced content
[03:38:37 CEST] <thebombzen_> Is that why people use yuyv422
[03:55:45 CEST] <chatter29> hey guys
[03:55:57 CEST] <chatter29> allah is doing
[03:56:05 CEST] <chatter29> sun is not doing allah is doing
[03:56:07 CEST] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[04:17:14 CEST] <TD-Linux> thebombzen, badly and yes
[06:26:54 CEST] <Aelius> I want to create a looping video, and for that I need to start/end on exact frames. The best way I can think to do that losslessly is to extract all frames to images, delete as necessary, then recombine the frames back into the video
[06:27:53 CEST] <Aelius> (ffmpeg trim commands dont seem to have the required precision, sometimes being more than 5seconds off what I tell it to trim)
[06:28:01 CEST] <Aelius> how exactly should I approach this?
[06:32:08 CEST] <thebombzen> they absolutely have the required precision
[06:32:23 CEST] <thebombzen> if you're not transcoding then they won't though
[06:32:32 CEST] <thebombzen> i.e. if you're streamcopying, but it appears you're not here
[06:32:52 CEST] <thebombzen> it's also worth noting that some containers (mpegts and vob come to mind) don't have good seeking support
[06:33:07 CEST] <Aelius> right. I avoid transcoding where possible, so in practice it seems like those commands never work
[06:33:23 CEST] <thebombzen> well dumping the video to frames is a form of transcoding
[06:33:40 CEST] <thebombzen> just don't use "-c copy" when you're trying to extract a single frame
[06:33:42 CEST] <Aelius> I avoid lossy operations where possible
[06:33:56 CEST] <thebombzen> well you're still transcoding
[06:34:08 CEST] <thebombzen> you're dumping your video to png frames
[06:34:11 CEST] <thebombzen> that's transcoding
[06:34:36 CEST] <Aelius> you made that clear, which is why I corrected myself to more accurately describe what I avoid.
[06:34:56 CEST] <thebombzen> what you're trying to do is cut the video temporally, but you realize that if you don't re-encode it using a lossy format it'll be enormous
[06:35:51 CEST] <thebombzen> if you try to dump the frames, you'll have just a bunch of pngs anyway
[06:36:08 CEST] <thebombzen> and those pngs are not a video format. if you want to actually have a video you'll need to encode that again anyway
[06:36:19 CEST] <thebombzen> so instead of dumping frames and picking and choosing and then re-encoding those with libx264
[06:36:22 CEST] <Aelius> well, I never specified what format I was going to output images in. I was hoping to find an answer like, dumping the actual h264 encoded frames
[06:36:29 CEST] <thebombzen> You can't do that
[06:36:34 CEST] <thebombzen> because H.264 uses Inter prediciton
[06:36:52 CEST] <Aelius> darn
[06:36:59 CEST] <thebombzen> But either way, whatever format you're going to use, you did say that it was a looping video
[06:37:04 CEST] <thebombzen> which is still video
[06:37:13 CEST] <thebombzen> and png frames are *still not video*
[06:37:42 CEST] <thebombzen> so it doesn't actually matter what you want the output format to be in, because dumping the frames will still require you to transcode
[06:39:27 CEST] <Aelius> that concept is clear. suggestions then? or is lossy inevitable
[06:39:46 CEST] <thebombzen> its' inevitable if you want to have your video be smaller than the moon
[06:40:13 CEST] <thebombzen> Lossless video is enormous. like 200 Mbps or something for 1080p yuv420p
[06:40:41 CEST] <thebombzen> You don't want that. And a sequence of PNGs doesn't help either
[06:41:20 CEST] <Aelius> I vaguely recall something about '-c copy' only trimming on the nearest keyframe- what is a keyframe, can it be abused  to make streamcopy trimming more accurate without having the video become 'the size of the moo'?
[06:41:39 CEST] <thebombzen> well video isn't just "a sequence of images"
[06:41:44 CEST] <thebombzen> because the images are often close to another
[06:42:04 CEST] <thebombzen> so they use something called "inter prediction" which in short records changes from the previous frame
[06:42:54 CEST] <thebombzen> every once in a while (usually around once every 250 frames) there is a frame that doesn't do this. that is encoded in a self-contained way
[06:42:58 CEST] <thebombzen> it's called an I-frame or a keyframe
[06:43:23 CEST] <thebombzen> In order to actually get the data from a frame that isn't a keyframe, you need to start decoding video from the most recent I-frame
[06:44:15 CEST] <thebombzen> Because of this you can't cut the video without transcoding it unless you cut it on an I-frame
[06:44:45 CEST] <thebombzen> because if you try to cut the video on a frame that isn't a keyframe, the data will be garbage without the I-frame before it
[06:45:45 CEST] <thebombzen> so if you're using streamcopy, ffmpeg knows it can't cut it anywhere except and I-frame, so it won't
[06:46:00 CEST] <Aelius> even in the absense of frames, though, it sounds like there could be a way to keep all i-frames intact and just remove inter-predictions
[06:46:09 CEST] <thebombzen> That's called decoding.
[06:46:34 CEST] <Aelius> well, not necessarily
[06:46:40 CEST] <thebombzen> No, it's decoding.
[06:46:42 CEST] <Aelius> the decoder understands some metadata or language in the file
[06:46:48 CEST] <Aelius> why is it not possible to modify that
[06:47:00 CEST] <thebombzen> Taking the compressed video and removing the information that is used to reduce redundancy is literally what decoding is
[06:47:38 CEST] <thebombzen> You cannot "demote" a P-frame (predictive) to an I-frame by "removing the inter prediction"
[06:47:48 CEST] <thebombzen> "while preserving the intra-prediction"
[06:47:51 CEST] <thebombzen> that doesn't make any sense
[06:48:05 CEST] <thebombzen> especially since the inter-prediction is what makes it possible to keep the bitrate manageable
[06:48:09 CEST] <thebombzen> we *could* also use MJPEG
[06:48:15 CEST] <thebombzen> But there's a reason we don't
[06:50:05 CEST] <Aelius> I don't understand enough to understand why that doesn't make sense. Decoders must follow a set of instructions- what makes you so adamant that this set of instructions can't be changed, such that the way the video is decoded changes?
[06:51:24 CEST] <thebombzen> If you were to change the instructions that a decoder follows, it would produce garbage
[06:51:55 CEST] <thebombzen> You might be thinking that each frame is first encoded lossily as an I-frame and then it's encoded using inter prediciton from previous frames.
[06:52:02 CEST] <thebombzen> But that's not at all how it works.
[06:52:27 CEST] <thebombzen> A P-frame is encoded directly from uncompressed to compressed using both the information from itself and from previous frames at once
[06:52:43 CEST] <thebombzen> it's not possible to decode a P-frame but leave its inter prediciton intact
[06:52:49 CEST] <thebombzen> leave its intra prediction* intact
[06:53:14 CEST] <thebombzen> because that would mean that it was intra-coded before it was inter-coded which it wasn't.
[06:53:51 CEST] <thebombzen> You also wouldn't want to do that
[06:54:36 CEST] <thebombzen> Even if you could, you'd be left with a bunch of H.264 I-frames in sequence, which would still have a bitrate that's too high for you
[06:55:00 CEST] <thebombzen> there's a reason we don't use lossy intra-only codecs like mjpeg
[06:56:26 CEST] <Aelius> could you define intra and inter coding?
[06:57:33 CEST] <thebombzen> Intra coding is prediction that reduces redundancy within a frame
[06:57:37 CEST] <thebombzen> (like the way jpeg works)
[06:57:45 CEST] <thebombzen> inter-coding works across frames
[07:00:04 CEST] <thebombzen> see: https://en.wikipedia.org/wiki/Group_of_pictures
[07:05:33 CEST] <Aelius> thanks thebombzen
[07:05:42 CEST] <thebombzen> yw
[07:06:29 CEST] <Aelius> moving out of hypotheticals, my first trim worked, but this second one is not. specifically, the -to is't working and the output extends to the end of the video (only 2s longer than where I'm trying to trim)
[07:06:33 CEST] <Aelius> ffmpeg -ss 00:00:06.446 -i mmd.mp4 -to 00:00:08.946 test2.mp4
[07:07:51 CEST] <Aelius> not sure why the -to isnt taking
[07:18:51 CEST] <Aelius> nvm figured it out
[07:35:54 CEST] <thebombzen> Aelius: -to doesn't work as expected a lot
[07:36:23 CEST] <thebombzen> because if you use -ss before -i, ffmpeg will shift the timestamps so they start at zero
[07:36:29 CEST] <thebombzen> and thus "-to" and "-t" behave the same way
[09:44:33 CEST] <superware> I'm trying to follow https://gist.github.com/RLovelett/67856c5bfdf5739944ed by calling jpeg_codec = avcodec_find_encoder(AV_CODEC_ID_JPEG2000); jpeg_context = avcodec_alloc_context3(jpeg_codec); jpeg_context->pix_fmt = ctx->pix_fmt; jpeg_context->width = frame->width; jpeg_context->height = frame->height; but avcodec_open2(jpeg_context, jpeg_codec, NULL) fails and returns -22, any ideas?
[11:15:14 CEST] <superwar> I'm trying to save a frame as a jpeg 2000 file, such in https://gist.github.com/RLovelett/67856c5bfdf5739944ed#gistcomment-1916026, but it doesn't seem the packet data after encoding is a valid jpeg 2000 file, any ideas?
[11:17:55 CEST] <oerg866> yo
[11:19:07 CEST] <oerg866> is there a way to tell libx264 to leave certain parts of an image alone
[11:19:17 CEST] <oerg866> like, store it with higher detail (possibly even raw)
[11:19:24 CEST] <oerg866> e.g. HUD elements of video games
[13:22:42 CEST] <Aerroon> so i have a problem
[13:22:59 CEST] <Aerroon> when i cut a video in ffmpeg the video playback does not seem to update as smoothly in vlc
[13:23:07 CEST] <Aerroon> and if i close the video the audio keeps playing for a few seconds
[13:23:29 CEST] <Aerroon> ffmpeg -i "test.mkv" -ss 00:33:00.0 -vcodec copy -t 14 -an "test_cut.mkv"
[13:23:36 CEST] <Aerroon> i know this one is without audio but it has the same problem
[13:23:47 CEST] <Aerroon> VLC will update playback head at like 0 seconds then jumps to 5, then 8 etc
[13:31:55 CEST] <kepstin> oerg866: when you're using the libx264 api directly, yes, you can provide a map of qp offsets to make it use more bits of some parts of the frame than other. But I don't think this api is available if you're using it via ffmpeg/libavcodec.
[14:55:53 CEST] <oerg866> kepstin: that's unfortunate, but thanks for the answer
[16:06:07 CEST] <alexpigment> hey guys, i was trying to test DVD encoding with FFMPEG, and i'm having a problem where I specify a higher bitrate (e.g. 8mbps) on a 2-pass encoding, but i end up with ~5.5mbps average. if i specify something lower than 5.5mbps, it honors it. additionally if i do a 1-pass encoding at 8mbps, it ends up as 8mbps. anyone have any experience with this and might know what's going on?
[16:21:10 CEST] <kepstin> alexpigment: basically, mpeg2 is a pretty awful codec, and the bitrate (vbv buffer size) controls required for dvd aren't very good
[16:21:58 CEST] <kepstin> alexpigment: when you run mpeg2video encoding in 2-pass mode, it'll often determine that because of the dvd bitrate controls, adding more bits to the file won't actually make quality any better, so you get a smaller file. It should also print a message to that effect.
[16:22:48 CEST] <kepstin> (the problem is that it can't add more bits to the "hard" parts of the video, because it's already maxed out the dvd bitrate there, and adding more bits to the "easy" parts would just be a waste)
[16:23:41 CEST] <alexpigment> i just tried it again and no obvious messages showed up indicating that, although i understand your general explanation
[16:24:13 CEST] <alexpigment> it's just weird to me that it doesn't do the same thing in 1-pass mode
[16:26:49 CEST] <kepstin> rate control of 1-pass abr modes in all video codecs is generally not as smart as the 2-pass modes...
[16:29:11 CEST] <alexpigment> well, here's another question then. i notice that the bitrates in the first pass don't get higher than ~6mbps. is it possible to specify different parameters in the first pass that cause a larger variation?
[16:29:20 CEST] <alexpigment> i'm wondering if that will affect the decisions in the second pass
[16:29:52 CEST] <alexpigment> (for context, i'm fairly green on two-pass from FFMPEG itself, so i don't know what rules there are about how the parameters vary
[16:30:04 CEST] <kepstin> alexpigment: the "bitrate" shown in the ffmpeg console output is just an average. even on the first pass it's probably maxing out the vbv buffers on hard scenes
[16:30:39 CEST] <kepstin> but when encoding DVDs, I usually set -b:v and -maxrate to the same value, fwiw
[16:30:57 CEST] <alexpigment> i suppose so. i just know that on one-pass encoding there's a notable difference between 8mbps and 9mbps on this video. it's not like it's too simple of a sample video
[16:32:49 CEST] <alexpigment> anyway, i'll keep messing around with it and see if i can find some more details. thanks for the info kepstin
[16:34:14 CEST] <kepstin> if you can avoid dvd encoding, just do it. iirc, many blu-ray players can play (simplified?) blu-ray disk structure on dvd disks, which might sometimes be an option worth looking into :)
[16:35:21 CEST] <alexpigment> kepstin, don't worry. this isn't something i'm doing by personal choice :)
[16:35:27 CEST] <alexpigment> and yeah, i'm very familiar with AVCHD
[16:35:44 CEST] <alexpigment> unfortunately, as a common distribution format, the DVD still reigns supreme
[16:35:57 CEST] <alexpigment> (and you're talking to someone with ~10 Blu-ray players in his garage)
[16:36:01 CEST] <Fenrirthviti> I think you meant usb flash drive
[16:36:20 CEST] <Fenrirthviti> physical media is so 2016.
[16:36:38 CEST] <alexpigment> Fenrirthviti, sure, but you can't deliver a USB flash drive to a customer and know for sure that they can play it on their TV. hell, neither of my Samsungs can play video from flash drives
[16:36:58 CEST] <Fenrirthviti> was mostly sarcasm :P
[16:37:14 CEST] <alexpigment> Fenrirthviti: the younger generation - of which I'm somewhat a part of - is going to realize that they should have thought harder about physical media in the near future
[16:37:17 CEST] <alexpigment> no worries
[16:37:37 CEST] <Fenrirthviti> Why do you say that?
[16:37:57 CEST] <alexpigment> still, physical media is still great for being able to store something long-term without having to think about optimizing the file size. I archive to Blu-ray discs constantly with no re-encoding from the original source (e.g. ATSC broadcasts)
[16:38:37 CEST] Action: kepstin has a stack of multi-terabyte hard drives to use for offline storage of stuff like that :/
[16:38:41 CEST] <alexpigment> Fenrirthviti: because cloud storage currently isn't feasible for minimally-compressed video and people lose hard drives constantly, despite the fact that we should all be backing stuff up
[16:39:13 CEST] <kepstin> the main issue with a lot of non-physical media, imo, is that a lot of the content people get is DRM'd so it can't really be archived at all
[16:39:14 CEST] <alexpigment> kepstin: same here. i've got over 30TB on my main machine, 16 of that being just backups
[16:39:20 CEST] <Fenrirthviti> I disagree with that wholeheartedly, but it's a bit of a religious debate at that point.
[16:39:47 CEST] <alexpigment> Fenrirthviti: are you disagreeing that cloud storage isn't feasible for video, or what?
[16:39:55 CEST] <Fenrirthviti> yes
[16:40:05 CEST] <Fenrirthviti> the first one
[16:40:38 CEST] <alexpigment> Fenrirthviti: what service do you recommend, and how expensive is it compared to, say, just buying some 4-8TB hard drives every year?
[16:41:04 CEST] <alexpigment> also, i really wonder how long it would take to back up my storage on the cloud with a 10mbps upload cap :(
[16:41:19 CEST] <Fenrirthviti> There's a ton of free services out there that work just fine. If your goals are straight archival, then yes maybe not the best solution.
[16:41:33 CEST] <alexpigment> of course my goal is straight archival
[16:41:37 CEST] <alexpigment> what else would it be?
[16:41:44 CEST] <Fenrirthviti> Content delivery
[16:41:53 CEST] <Fenrirthviti> i.e. stuff like Plex or other streaming media services
[16:42:06 CEST] <alexpigment> oh, you're talking about heavily compressed end-user stuff
[16:42:29 CEST] <nido> theres online storage that hosts tbsized data partitions for free?
[16:42:30 CEST] <Fenrirthviti> doesn't have to be heavily compressed
[16:42:37 CEST] <alexpigment> i suppose that would work on the cloud. having said that, i seem to recall a lot of services charge wayyy more for video
[16:43:04 CEST] <alexpigment> Fenrirthviti: I generate between 10-20GB per day
[16:43:09 CEST] <alexpigment> i just don't think cloud is gonna work
[16:43:31 CEST] <Fenrirthviti> Yeah, we're talking two completely different things at this point :P
[16:43:38 CEST] <alexpigment> i agree with that ;)
[16:44:26 CEST] <alexpigment> anyway, a stack of Verbatim 25GB BD-R discs are an amazing value, especially considering how durable they are
[16:44:32 CEST] <Fenrirthviti> nido: there's a couple shady chinese services that offer 1-5tb for free if you install their desktop app :P
[16:45:30 CEST] <alexpigment> sounds like a glowing endorsement haha
[16:45:44 CEST] <Fenrirthviti> if you have a throwaway VM to install the app on? sure why not.
[16:46:18 CEST] <Fenrirthviti> Plus a lot of the free services like dropbox have incentives to get more free space that are pretty easy
[16:46:38 CEST] <alexpigment> yeah but doesn't dropbox still put restrictions on video content?
[16:46:58 CEST] <Fenrirthviti> Not sure, I host my own private cloud.
[16:47:22 CEST] <kepstin> hmm, are bd-r disks actually kind of reasonable nowadays? I got a bd-writer just for use as a reader, and haven't really tried writing anything with it yet :)
[16:47:35 CEST] <alexpigment> kepstin: very reasonable
[16:48:00 CEST] <alexpigment> 50pk of 25gb discs is $42 on amazon
[16:48:51 CEST] <alexpigment> of course, the 50GB dual layer discs are still high by comparison, but also doable if you do a lot of video work
[16:49:15 CEST] <alexpigment> those are $67 for a 25pack
[16:50:01 CEST] <furq> fwiw none of those china services actually work except for baidu pan
[16:50:15 CEST] <furq> and also a lot of them got shut down recently
[16:50:20 CEST] <alexpigment> i'm quoting prices for Verbatim non-LTH discs, because there's honestly no reason to buy anything else
[16:50:21 CEST] <kepstin> hmm, still quite a lot higher $/gb than picking up a stack of hard drives tho :/
[16:50:35 CEST] <Fenrirthviti> the 360drive one was still going last I saw a month or so ago
[16:50:40 CEST] <alexpigment> kepstin: yes, but they will last longer and you don't need to buy a backup
[16:50:42 CEST] <furq> it's still running but it's useless
[16:50:47 CEST] <Fenrirthviti> ah, ok
[16:50:54 CEST] <furq> they give you 36TB of storage but then cap you to unusable speeds after 2GB/day
[16:51:03 CEST] <furq> so you'll need about 50 years to fill that up
[16:51:13 CEST] <Fenrirthviti> I abused the shit out of that one for.... things, a while back
[16:51:37 CEST] <furq> they used to have massive lists of files they were hosting that you could import into your share
[16:51:42 CEST] <furq> but they nixed that ages ago
[16:51:49 CEST] <alexpigment> furq: yeah that sounds very legit ;)
[16:52:04 CEST] <furq> also yeah all of those services dedup across the entire service
[16:52:09 CEST] <furq> which seems very secure
[16:52:25 CEST] <furq> baidu pan is nice to have though
[16:52:37 CEST] <furq> and you can just install the app in android-x86 in a vm
[16:56:02 CEST] <Xys> Hello, how is it possible to fix DTS "out of order" issues when concatenating two videos please ?
[16:59:22 CEST] <BtbN> It's what happens if you concat videos that are unrelated
[16:59:31 CEST] <BtbN> It shouldn't break anything normally
[17:01:01 CEST] <alexpigment> Xys: i guess the real question here is if you're trying to avoid re-encoding or not
[17:03:31 CEST] <Xys> Well, I have a big 4k video (1 min), and a small video (2 secs). I can re-encode the small video, but not the big one
[17:04:10 CEST] <Xys> @alexpigment : I don't want to re-encode everything
[17:04:39 CEST] <alexpigment> well, it sounds like you need to re-encode the small one to match the specs of the big one before you concat
[17:06:03 CEST] <BtbN> If the video parameters are the same, I don't see why you wouldn't be able to concat them
[17:08:04 CEST] <Xys> alexpigment : I re-encoded the small one to have the same : h264 profile, colorspace, resolution, timescale and framerate
[17:11:01 CEST] <alexpigment> Xys: and it's still not working with concat?
[17:11:22 CEST] <Xys> With concat demuxer nope
[17:12:48 CEST] <alexpigment> Xys: i don't know then. perhaps mediainfo would help figure out the differences between the files
[17:15:15 CEST] <Xys> alexpigment : Thanks, I'm gonna try it
[17:17:43 CEST] <Xys> alexpigment : Can different audio formats cause the bug in VLC ? (The video only plays the first chunk)
[17:20:08 CEST] <alexpigment> Xys: are you saying that the video files that you tried to concat have different audio formats?
[17:22:59 CEST] <Xys> alexpigment : both aac (LC), mp4a, 48k, stereo, fltp
[17:23:19 CEST] <Xys> alexpigment : but 189 kb/s VS 2 kb/s
[17:23:32 CEST] <Xys> alexpigment : one audio is a silent track created with ffmpeg
[17:23:47 CEST] <alexpigment> i'd worth trying to re-encode just the audio, i suppose
[17:23:53 CEST] <Xys> okay
[17:23:59 CEST] <alexpigment> although i'm not sure that would cause any problems
[17:24:07 CEST] <alexpigment> *it's worth
[17:24:47 CEST] <Xys> first video is : MP4 v2 [ISO 14496-14]
[17:24:59 CEST] <Xys> second video is : MP4  Base Media v1 [IS0 14496-12:2003]
[17:25:12 CEST] <Xys> alexpigment : could it cause any problems for the concat demuxer ?
[17:25:27 CEST] <alexpigment> i don't have any first hand experience, but i seem to recall this came up recently
[17:25:32 CEST] <kepstin> that's just the container format, shouldn't have anything to do with the video stream itself...
[17:26:01 CEST] <furq> yeah the demuxer doesn't care about that
[17:26:14 CEST] <furq> otherwise it wouldn't be a very good demuxer
[17:26:27 CEST] <Xys> kepstin : Oh hello, I've tried your solution with the concat protocol, but I still had the same issue
[17:26:43 CEST] <kepstin> Xys: with mpeg-ts files, you still had the same problem?
[17:26:48 CEST] <kepstin> hmm :/
[17:28:01 CEST] <Xys> kepstin : Yes. Basically I have a video footage from the samsung gear 360 camera, and I want to add an image (that last 3 secs) at the end of the video
[17:31:07 CEST] <alexpigment> Xys: you mentioned earlier that you used the same H.264 profile
[17:31:20 CEST] <alexpigment> doesn't the gear360 record in H.265?
[17:32:38 CEST] <Xys> alexpigment : Hm.. you're maybe right but I see h264 with ffprobe
[17:33:12 CEST] <Xys> alexpigment : I can give you a dropbox link if you want to have a look at the video ?
[17:33:19 CEST] <alexpigment> sure
[17:33:22 CEST] <alexpigment> just pm me
[17:33:26 CEST] <Xys> okay thanks
[17:43:56 CEST] <Hennio> how can I register a single decoder, instead of avcodec_register_all?
[17:44:04 CEST] <Hennio> in my case H264
[17:44:11 CEST] <Hennio> using avcodec_register
[17:44:34 CEST] <Hennio> I declar an `extern AVCodec ff_h264_decoder;`
[17:44:55 CEST] <Hennio> but its unresolved because im using dlls
[17:45:03 CEST] <Hennio> and would be found at runtime, not compile time
[17:58:11 CEST] <alexpigment> has anyone seen MediaInfo report a container profile? I'm looking at Xys's video and it's level 4.1 Baseline, but it also says "Container Profile=High at 1.3"
[17:58:27 CEST] <alexpigment> and it carries through if you do a -c copy to a new file
[18:23:19 CEST] <riataman> anybody knows if there's any way to make fragmented mp4s work on iOS?
[19:08:14 CEST] <voxadam> Is it possible for a daemon user to encode video using QSV while a regular meatbag user such as myself is logged in and using the GPU? The CPU is an i5 3570 (Ivy Bridge), and I'm running a 4.10 kernel.
[19:09:50 CEST] <sfan5> voxadam: if by QSV you mean the thing exposed via vaapi then yes that should definitely work
[19:10:39 CEST] <voxadam> sfan5: I suppose VAAPI is what I'm talking about. So many video technologies and APIs, so little time.
[19:11:25 CEST] <sfan5> (https://ffmpeg.org/pipermail/ffmpeg-user/2016-May/032153.html)
[19:17:38 CEST] <voxadam> Thanks!
[19:38:48 CEST] <agrathwohl> I am attempting to encode a raw 8 bit yuv420p Y4M source with FFV1 with FFmpeg 3.2.4. The frame size is very large (4096x4096). Once encoding begins, FFmpeg outputs this message continually: '[ffv1 @ 0x55db67462740] Cannot allocate worst case packet size, the encoding could fail' Is this bad? If so, anything I can do to remedy this?
[19:43:13 CEST] <c_14> nothing you can do without modifying ffv1enc.c
[19:43:38 CEST] <c_14> And I think in the worst case, the encoding should just fail if it hits the limit
[20:35:36 CEST] <alexpigment> if i'm rendering in one application and piping to ffmpeg, is there any way to avoid a) rendering twice, or b) writing a huge temporary file?
[20:35:55 CEST] <alexpigment> i suspect the answer is no, but i just wanted to make sure there isn't some trick ffmpeg can do that at least speeds up the process somehow
[20:37:36 CEST] <BtbN> Why would you render twice when you pipe to ffmpeg?
[20:37:46 CEST] <kepstin> alexpigment: you're trying to do a 2-pass encode?
[20:37:47 CEST] <iive> 2 pass encoding?
[20:37:59 CEST] <kepstin> then yeah, tmp file or render twice. no other way to do it without a time machine
[20:38:37 CEST] <alexpigment> oh sorry, yeah i completely forgot the relevant piece of information - 2-pass is what i'm talking about ;)
[20:38:58 CEST] <iive> if you don't care for the exact final size or bitrate, you can just give it reasonable -crf
[20:39:20 CEST] <alexpigment> having said that, is it possible to render once in low resolution to generate the stats file, then render in full res for pass 2?
[20:39:32 CEST] <kepstin> alexpigment: depends on the codec whether that works
[20:39:54 CEST] <BtbN> I doubt it
[20:40:23 CEST] <kepstin> iirc with libvpx you can use stats from a high res pass when doing a later low res pass
[20:40:39 CEST] <kepstin> I dunno anything where the other way works
[20:41:00 CEST] <BtbN> the stats gained from a low-ress pass just don't neccesarily apply to a higher res
[20:41:03 CEST] <iive> bad idea, since ME is big part of the stats
[20:41:04 CEST] <BtbN> a lot of finer movement might be just lost
[20:41:50 CEST] <DHE> I do recall x265 does explicitly suggest that strategy in its own documentation
[20:41:56 CEST] <alexpigment> iive: i need to predict the final size for disc authoring
[20:41:56 CEST] <alexpigment> k, just figured i'd ask. that would be a really nice optimization for FFMPEG imho
[20:41:56 CEST] <alexpigment> just like a quick-and-dirty 2-pass
[20:41:56 CEST] <alexpigment> kepstin: that seems backwards, but i suppose it makes sense for encoding multiple resolutions
[20:42:05 CEST] <alexpigment> BtbN: well, if you have extremely fine details in only certain parts of the video, yes i can see how it wouldn't apply
[20:42:31 CEST] <DHE> maybe just use an enormous lookahead buffer?
[20:42:33 CEST] <alexpigment> DHE: really? is this recommended for 4K specifically?
[20:43:01 CEST] <DHE> alexpigment: the context I saw it in was to allow you to render multiple bitrates of the same video. start with the high res version and then feed the information into the other variants
[20:43:12 CEST] <DHE> for things like MPEG-DASH
[20:43:27 CEST] <alexpigment> DHE, oh right. that's what kepstin was mentioning about re: libvpx
[20:43:54 CEST] <alexpigment> basically the rendering is the bottleneck in my case - not the encoding. so i'd ideally like to avoid having the bottleneck twice
[20:44:15 CEST] <alexpigment> and of course, writing a huge temp render could lead to some unexpected cases where disk space runs out
[20:44:32 CEST] <iive> alexpigment: you can probably use lossless mode of x264
[20:44:47 CEST] <kepstin> well, if you have a lot of cpu power, you could do the first pass and write a lossless encode at the same time
[20:44:57 CEST] <iive> the file would still be huge, but smaller than raw image
[20:45:19 CEST] <DHE> offload some portion of it? one machine runs the render, another runs the encoder. still have to run it twice, but might help the performance aspect of it?
[20:45:44 CEST] <alexpigment> this would all be on one machine, unfortunately
[20:46:03 CEST] <alexpigment> i guess the basic answer i'm getting is "no" :) so no point wasting much more time on this
[20:46:04 CEST] <alexpigment> thanks guys
[20:46:39 CEST] <kepstin> if you figure out how to do it, you would have already told us by coming back with your time machine, so I guess you never figured it out ;)
[20:47:05 CEST] <alexpigment> kepstin: it's possible i got stuck in 1885 by accident and so that info was lost on the locals and forgotten over time
[20:48:00 CEST] <alexpigment> and maybe like some young apprentice tried to come back for me, but i decided "fuck it, i'm staying here with mary steenburgen"
[20:48:30 CEST] <kepstin> and just to confuse everyone, nvenc has a mode called "2-pass" which isn't actually 2-pass at all, but just a look-ahead rate control mode.
[20:48:48 CEST] <DHE> yep. learned that. :/
[20:49:29 CEST] <alexpigment> yeah i wasn't sure what that did, but i was definitely testing it in 1-pass ;)
[20:50:38 CEST] <kepstin> x264 does lookahead by default, at least in the slower modes, which is part of the reason why people get confused when they send it a few hundred frames but haven't gotten any encoded frames back yet :)
[20:51:48 CEST] <alexpigment> yeah i think my usual presets are like 40-60
[21:02:14 CEST] <BtbN> kepstin, it's not look-ahead
[21:02:33 CEST] <BtbN> if works in low-latency mode where it always returns a packet for a frame immediately
[21:02:51 CEST] <BtbN> I have absolutely no clue what it is doing internally
[21:06:36 CEST] <DHE> zerolatency mode does do that. but the good presets without zerolatency mode will buffer packets. and lots of them. I've had dozens even though I only set 2 bframes
[21:08:01 CEST] <BtbN> That's not the point
[21:08:11 CEST] <BtbN> the point is that nvenc 2pass can't be some lookahead thing
[21:09:48 CEST] <kepstin> oh, wow, it really isn't lookahead
[21:10:21 CEST] <DHE> true, you can have low-latency + 2pass.. how does that work?
[21:10:33 CEST] <kepstin> https://gist.githubusercontent.com/kepstin/6672f5a0bc5e26c304e671c828a23d1b/raw - nvenc 2 pass from their docs
[21:10:45 CEST] <kepstin> it encodes a frame at a time rather than a macroblock at a time
[21:11:15 CEST] <DHE> well, TIL
[21:11:34 CEST] <alexpigment> that's a very different view of 2-pass encoding on Nvidia's behalf ;)
[21:11:46 CEST] <DHE> qp => frame  rather than frame => entire video
[21:35:07 CEST] <thebombzen> so 2pass encoding ifyou're nvidia just means aq
[21:35:10 CEST] <thebombzen> go figure
[21:36:36 CEST] <cjt> Hi, I'm trying to figure out why the video I get from ffmpeg works fine in VLC but not mpv
[21:36:42 CEST] <cjt> command/output at https://pastebin.com/KYPRDSMc
[21:37:10 CEST] <cjt> In VLC, audio is correct (it's the audio from 00:01:00 to 00:02:00 in the source file)
[21:37:19 CEST] <cjt> in mpv, audio starts from 00:00:00 in the source file
[21:37:34 CEST] <c_14> probably ask in #mpv?
[21:38:00 CEST] <c_14> can't see anything wrong with that command
[21:38:46 CEST] <c_14> except that some lines in the paste are in the wrong place
[21:39:42 CEST] <cjt> If you mean it's badly formatted then it's probably my fault, I copy-pasted it from a small terminal window
[21:39:55 CEST] <cjt> So lined might be wrapped unneccesarily
[21:40:27 CEST] <c_14> lines 49-65 and 45-48 should be swapped
[21:42:38 CEST] <cjt> Alright will try asking mpv people, thanks
[22:21:07 CEST] <alexpigment> can you use the psnr filter to generate a log of the average psnr of the resultant video?
[22:21:15 CEST] <alexpigment> or does it just work when you specify two inputs?
[22:22:45 CEST] <furq> how would it work with just one video
[22:22:56 CEST] <alexpigment> you're constantly comparing the input to the output
[22:23:04 CEST] <alexpigment> that's how it would work in my head
[22:23:35 CEST] <alexpigment> basically i'm transcoding, and i'd like to get a summary at the end that i can use as a loose guide for visual quality compared to the original
[22:23:37 CEST] <furq> oh right you mean during encoding
[22:23:42 CEST] <alexpigment> right
[22:23:50 CEST] <furq> the filterchain doesn't have any access to the encoded frames
[22:24:10 CEST] <alexpigment> i see
[22:25:11 CEST] <furq> if it's x264 then you can use -x264-params psnr=1
[22:25:28 CEST] <alexpigment> yeah, this is mpeg2video unfortunately ;(
[22:25:58 CEST] <furq> i guess you'd need a second pass then
[22:25:58 CEST] <alexpigment> i'm going to try and make a quick script here, but i have a feeling my source (raw avi) and encoded file (dvd vob) won't line up on the frames
[22:26:00 CEST] <alexpigment> we'll see
[22:26:03 CEST] <furq> or a third pass if it's mpeg2video
[22:26:51 CEST] <furq> i feel like that should be ok
[22:28:39 CEST] <furq> does ffmpeg split vob at 1GB
[22:28:45 CEST] <furq> assuming you don't do it manually obv
[22:30:13 CEST] <alexpigment> not at the moment
[22:30:18 CEST] <alexpigment> well
[22:30:23 CEST] <alexpigment> *i'm not splitting* at the moment
[00:00:00 CEST] --- Tue Apr  4 2017