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

[burek]

[01:56:20 CEST] <Zibri_> hello
[04:16:08 CEST] <LikWidChz> Hey folks!
[04:42:51 CEST] <LikWidChz> So random question... I remember seeing some sort of document ... notes... something like that where someone mentions the bits/pixel value for good quality h264 encoding. playing around with H265 is there anything that exists for that? like I'd like to encoding some 720 content and convert it to h265 but remain with the same quality... I know the whole re encode always looses stuff.. but humor me..
[04:46:39 CEST] <furq> use crf, that's what it's for
[04:47:08 CEST] <furq> i haven't seen anyone using bits per pixel as a guide since the bad old days of xvid
[04:47:32 CEST] <LikWidChz> what's that stand for? yeah well ... im old :) thats about the only thing I could remember from it... not sure if it still kinda stands you know
[04:47:50 CEST] <furq> http://slhck.info/articles/crf
[04:47:56 CEST] <furq> x265 has the same thing
[04:48:22 CEST] <LikWidChz> Ahhh I see! so you basicly let the encoder pick the bitrate?
[04:48:29 CEST] <furq> more or less
[04:48:38 CEST] <furq> apparently x265 crf 28 is about the same as x264 23
[04:48:53 CEST] <furq> it's worth experimenting with it though
[04:49:06 CEST] <LikWidChz> ok higher number is less bitrate looking at that link you sent me
[04:49:12 CEST] <furq> right
[04:49:29 CEST] <LikWidChz> I see!, is there any way to gauge output size? im guessing no....
[04:49:38 CEST] <furq> yeah you lose control over that by using crf
[04:50:10 CEST] <LikWidChz> so it sounds like using CBR for h265 is really a giant waste..?
[04:50:19 CEST] <furq> i don't know if x265 even has a true cbr more
[04:50:20 CEST] <furq> mode
[04:50:23 CEST] <furq> x264 doesn't
[04:50:55 CEST] <furq> it's only useful for streaming, and i think people overestimate the need for it there tbh
[04:50:58 CEST] <LikWidChz> really? this is an example string I used for shits and giggles. ffmpeg.exe -i video.avi -s 1920x1080 -vcodec libx264 -b 3500k -acodec libmp3lame -ab 192k video.mkv
[04:51:09 CEST] <furq> that's abr (average bitrate)
[04:51:29 CEST] <furq> it'll try to hit the target bitrate over the whole file
[04:51:53 CEST] <LikWidChz> I see.....
[04:52:06 CEST] <furq> that is also a waste of bits, and also it can under/overshoot if you don't use 2-pass mode
[04:52:20 CEST] <furq> but 2-pass is a waste of time if you don't need to hit a target size
[04:52:30 CEST] <furq> crf will do a better job
[04:53:00 CEST] <LikWidChz> yeah well I kind of just experiemented with h265 the other day and was seriously shocked how much better it was although I realized I need a new processor HAHA.. shit... painfully slow.
[04:53:52 CEST] <furq> it's slow on pretty much any cpu
[04:54:42 CEST] <LikWidChz> Is there anything regarding using like GPU assisted encoding??
[04:54:57 CEST] <furq> nvidia cards can do h265 encoding
[04:55:02 CEST] <furq> but it's probably not very good
[04:55:28 CEST] <LikWidChz> ahhh I see I have two 660 TI's in sli... a bit old...
[04:55:36 CEST] <furq> yeah that's too old
[04:55:53 CEST] <LikWidChz> yeah figured, but oh well. new stuff at some point.
[04:56:04 CEST] <furq> that should have the first-gen nvenc with h264 encoding
[04:56:07 CEST] <furq> but that's also not very good
[04:57:09 CEST] <LikWidChz> Yeah, well  h264 encoding isnt that slow anymore and it seems like it will be not used within the next year or two
[04:58:30 CEST] <furq> i wouldn't be too keen about h265
[04:58:46 CEST] <LikWidChz> oh yeah? your thoughts on the subject?
[04:59:01 CEST] <furq> the licensing is a mess and a lot of companies aren't using it
[04:59:07 CEST] <furq> you can't even upload h265 to youtube atm
[04:59:51 CEST] <furq> there's at least three organisations selling different licenses for it
[04:59:59 CEST] <LikWidChz> ahhhh I see, well I'd guess that will change at some point... I mean... isnt h265 an open source codec?? or am I incorrect.
[05:00:14 CEST] <furq> x265 is open source but h265 is patent-encumbered
[05:00:28 CEST] <furq> if you want to use x265 commercially then you need an h265 license
[05:00:31 CEST] <furq> or three of them, as the case may be
[05:00:39 CEST] <LikWidChz> the whole series silicon valley seems more and more real.
[05:00:41 CEST] <furq> the same is true for h264 but the license situation is less insane there
[05:00:54 CEST] <LikWidChz> I see.
[05:01:18 CEST] <furq> google have got vp9 which is slightly worse than h265 but is license-free
[05:01:37 CEST] <furq> and a bunch of companies are working on a license-free codec which is supposed to be better than h265
[05:02:04 CEST] <furq> if that's mature by the time 4k streaming video is a widespread thing then h265 might end up dead in the water
[05:02:31 CEST] <LikWidChz> Interesting... interesting...
[05:03:26 CEST] <LikWidChz> I snagged some 4k video off youtube and playing around with it now... that link you sent eairler... cant I just change that lib264 to lib265 and use a CRF of 28 ?
[05:03:50 CEST] <furq> it couldn't hurt
[05:04:00 CEST] <furq> you should be able to download that video in vp9 though
[05:04:17 CEST] <LikWidChz> I snagged it with that app youtube-dl
[05:04:28 CEST] <LikWidChz> its I think h264
[05:04:36 CEST] <furq> youtube-dl -F url
[05:04:38 CEST] <LikWidChz> some demo 4k video of costa ricka
[05:04:51 CEST] <furq> you should see a 4k vp9 version
[05:05:09 CEST] <LikWidChz> AHHH... you saying you cant download it in vp9 ?
[05:05:13 CEST] <furq> you can
[05:05:25 CEST] <LikWidChz> oh okay, but what for... use it as source in experimenting?
[05:05:39 CEST] <LikWidChz> shit maybe I have that... haha, one sec lemme see what I actually have
[05:05:44 CEST] <furq> well that should be closer in quality to h265
[05:06:16 CEST] <LikWidChz> you know i have no idea its extension is .webm
[05:06:51 CEST] <furq> i wouldn't use youtube clips as test sources, they're not very high quality
[05:06:54 CEST] <furq> http://ultravideo.cs.tut.fi/#testsequences
[05:07:23 CEST] <furq> the yuv samples are uncompressed (and also massive)
[05:08:17 CEST] <LikWidChz> oh hey thats cool, usually I snag ts files off newsgroups... well here is an open ended question... how do you really test "quality" to compare x vs y video encode??
[05:08:26 CEST] <furq> with your eyes
[05:08:27 CEST] <LikWidChz> 11fps now FYI.
[05:08:29 CEST] <furq> and ideally a good monitor
[05:08:48 CEST] <furq> there are metrics like psnr and ssim but those aren't really accurate with newer video codecs
[05:08:49 CEST] <LikWidChz> nice :) I suppose I asked for that... but just like blocking or the lack of blocking??
[05:09:09 CEST] <furq> blocking, mosquito noise, fine detail retention, etc
[05:09:15 CEST] <LikWidChz> I saw those two acrynyms come up and didnt know what they were ... haven't googled them yet so..
[05:10:41 CEST] <LikWidChz> well just did a quick encode 44 seconds ffmpeg.exe -i "COSTA RICA IN 4K 60fps (ULTRA HD) w_ Freefly Movi-iNJdPyoqt8U.webm" -s 1920x1080 -c:v libx265 -crf 28 test.mkv --- ended up being 8.6mb
[05:11:15 CEST] <furq> you probably want to use slower presets
[05:11:25 CEST] <LikWidChz> by the way you weren't kidding those are pretty big files.
[05:11:27 CEST] <furq> i think -preset veryslow is the slowest
[05:11:48 CEST] <LikWidChz> so bear with me its been a while, does that mess with the motion estimation?
[05:11:48 CEST] <furq> iirc -preset medium with libx265 is about as good as -preset veryslow with libx264
[05:11:55 CEST] <furq> the preset?
[05:11:58 CEST] <LikWidChz> yeah
[05:12:01 CEST] <furq> probably
[05:12:15 CEST] <furq> it does with x264
[05:12:21 CEST] <furq> http://dev.beandog.org/x264_preset_reference.html
[05:12:42 CEST] <furq> x265's preset system is similar in spirit
[05:12:46 CEST] <LikWidChz> with the syntax that im using is that just a plain jane out of the box setup? seriously so many options...
[05:12:56 CEST] <furq> yeah just add -preset slow or whatever
[05:13:29 CEST] <furq> -preset veryslow gives much better compression but it is unsurprisingly very slow
[05:13:36 CEST] <LikWidChz> HEH
[05:13:55 CEST] <LikWidChz> so getting 7.3fps now
[05:14:11 CEST] <furq> http://x265.readthedocs.io/en/default/presets.html
[05:14:12 CEST] <furq> oh neat
[05:14:15 CEST] <LikWidChz> does that decrease file size in the end?
[05:14:18 CEST] <furq> yeah
[05:14:26 CEST] <LikWidChz> i see! I see..
[05:14:27 CEST] <furq> or it may increase quality
[05:14:50 CEST] <furq> what the chosen crf value does depends on the preset
[05:14:50 CEST] <LikWidChz> ... not gonna lie those two links you sent me are a bit over my head.
[05:15:04 CEST] <LikWidChz> 6.2 fps now.
[05:15:21 CEST] <furq> i know what about a third of those x265 options do
[05:15:24 CEST] <LikWidChz> 5.9 shit I better stop talking about it.
[05:15:44 CEST] <furq> i haven't paid much attention to x265 yet
[05:16:06 CEST] <LikWidChz> I mean really when it comes to those presets why are there so many? ... I mean does it depend on what the source is? normal video vs animated?
[05:16:17 CEST] <furq> not really
[05:16:27 CEST] <furq> it's pretty much just how long you're prepared to wait for
[05:16:37 CEST] <LikWidChz> HAHAHAH
[05:16:57 CEST] <furq> also if you're trying to do realtime streaming then it makes a big difference
[05:17:09 CEST] <furq> not that you can really do that with x265 yet
[05:17:11 CEST] <LikWidChz> oh I see, so like encode as you watch?
[05:17:30 CEST] <furq> yeah
[05:17:33 CEST] <LikWidChz> nevermind like apps like plex and what not.
[05:17:55 CEST] <furq> x264 ultrafast is useful if you're streaming a game or something which uses the cpu
[05:18:22 CEST] <LikWidChz> so when I killed the process the averge bitrate was 1780 for 1080p
[05:18:30 CEST] <LikWidChz> 33 seconds at 7.9 megs
[05:18:49 CEST] <furq> i look forward to finding out how slow 4k is with -preset veryslow
[05:19:35 CEST] <furq> also ffmpeg's hevc decoder is pretty slow so you might want to grab one of those uncompressed files if you've got the disk space
[05:19:53 CEST] <LikWidChz> well download one of those videos and give it a try.. I have diskspace for days a 14tb nas.
[05:20:18 CEST] <LikWidChz> however, would be not for days if I had lots of sample videos like that spinning away on it
[05:21:06 CEST] <LikWidChz> holy shit man... there are a ton of options little overwhelming.
[05:23:23 CEST] <furq> it's not usually worth touching anything but -crf and -preset
[05:24:22 CEST] <LikWidChz> well that is very cool.. im guessing with the preset, someone else has done all the work to figure out what options should be in each preset right?
[05:24:42 CEST] <furq> pretty much
[05:29:04 CEST] <LikWidChz> Well hey man, thanks for the chat and help, ill poke at this maybe its worth re encoding a bunch of shit into this format
[07:37:33 CEST] <SouLShocK> just to follow up on yesterdays talk: tried NFS on windows, exactly same speed as samba
[07:37:36 CEST] <SouLShocK> samba/cifs
[07:43:51 CEST] <furq> i don't suppose you had a chance to try it on real hardware
[08:02:53 CEST] <tdr> so your net driver is probably the issue
[08:49:51 CEST] <SouLShocK> furq real hardware?
[10:04:12 CEST] <bencc> is there a fundamental difference between normal transcoding
[10:04:41 CEST] <bencc> and rendering to a virtual screen, doing screen capture and encoding?
[10:44:25 CEST] <k_> is there a command to find out the properties of a video? I am extracting small pieces of video which take up much more space than the whole original video because I am trying to save in hi res
[10:45:08 CEST] <mrelcee> k_ mediainfo
[10:45:31 CEST] <relaxed> ffprobe
[10:50:48 CEST] <k_> thanks!! Is there a FAQ for dummies. eg I have no idea what this means. https://ffmpeg.org/faq.html#How-can-I-read-from-the-standard-input-or-write-to-the-standard-output_003f
[10:51:16 CEST] <k_sze[work]> When I'm at the end of recording a video, am I supposed to repeatedly call avcodec_encode_video2(AVCodecContext * avctx,) with a NULL AVFrame pointer until *got_packet_ptr is 0?
[10:51:58 CEST] <Mavrik> yes.
[12:42:37 CEST] <behrooz_> Hello
[12:42:46 CEST] <behrooz_> i have question.
[12:43:09 CEST] <behrooz_> i have issue when ffmpeg record screen in linux
[12:43:22 CEST] <behrooz_>  i use this command
[12:43:24 CEST] <behrooz_> http://pastebin.com/irUe07PJ
[12:44:07 CEST] <behrooz_> but after start ffmpeg , Xorg cpu usage increse from 6% to 96.5%.
[12:44:15 CEST] <behrooz_> Does anyone idia?
[12:48:42 CEST] <antranigv> if I got it right, the %d.jpg reads only the first 100 files, aye?
[12:49:50 CEST] <antranigv> ah, I just needed to read th FAQ, sorry :3
[13:12:30 CEST] <TwinTailed> Hi. Why the generated H264 output video is just 1 second long with only 1 frame showing?
[13:20:04 CEST] <TwinTailed> Ok, what does "Application provided invalid, non monotonically increasing dts to muxer in stream" mean?
[13:20:46 CEST] <Mavrik> That the timestamps of frames in video aren't in proper order for some reason.
[13:21:08 CEST] <TwinTailed> Mavrik: I am using Frame->pts = av_frame_get_best_effort_timestamp(Frame);
[13:21:19 CEST] <TwinTailed> after decoding and before encoding
[13:21:29 CEST] <Mavrik> Well.
[13:21:48 CEST] <Mavrik> Muxer demands that the frames you try to mux have to go in DTS order.
[13:21:57 CEST] <Mavrik> You're not doing that for some reason :)
[13:22:07 CEST] <TwinTailed> Mavrik: How do I do that?
[13:22:20 CEST] <TwinTailed> what does DTS mean btw?
[13:23:40 CEST] <Mavrik> decoding timestamp
[13:24:03 CEST] <TwinTailed> Mavrik: Here is my code in case you wanted to take a look, http://pastebin.com/KZtSb3BK
[13:24:43 CEST] <TwinTailed> Mavrik: I am getting a 1 second video with just 1 frame showing
[13:24:54 CEST] <TwinTailed> Mavrik: That's why I thought it was a PTS/DTS problem
[13:40:47 CEST] <TwinTailed> can anyone help ^? please :/
[14:43:54 CEST] <beastwick_> I am trying to restrict bandwidth constraints at the cost of quality and I am OK with that, but I'd like to verify I understand how vbv-bufsize and vbv-maxrate work. I'll write a quick example of how I think it does if anyone can give me their input.
[14:46:50 CEST] <DHE> your buffer is filled at a rate of "maxrate" bits per second. whenever a frame is encoded, the size is taken from the bits in the buffer.
[14:47:21 CEST] <beastwick_> If using vbv, vbv-maxrate takes precedence over the bitrate option (which is more of an average). If, fps = 20, vbv-maxrate = 2190 kbps, vbv-bufsize = 110 kbits, that means the buffer is very tiny and the VBV will fluctuate the bitrate of each frame so that over 1 second the constraint of 2190 kbps is respected. Of course VBV makes sure the buffer doesn't empty or fill but at such a small size I guess it will always fill per fra
[14:49:29 CEST] <beastwick_> so the buffer is more of a bit allowance, rather than something being "filled?"
[14:49:41 CEST] <beastwick_> DHE: according to what you wrote?
[14:50:11 CEST] <DHE> typically it starts filled and for each frame it's drained by the size of the encoded frame and then re-filled by $maxrate / $fps  (assuming constant fps)
[14:50:39 CEST] <beastwick_> by re-filled you mean that bits are put back that may be taken away for encoding
[14:50:40 CEST] <DHE> obviously at no time can it ever be overfilled nor drained below 0. If insufficient bits are available the image quality will be degraded to make it fit
[14:51:51 CEST] <DHE> in your numbers example, there's an expectation of 109.5 kbit restored to the buffer every frame (2190 / 20)
[14:52:10 CEST] <DHE> but with a vbv-bufsize of 110 you basically have CBR
[14:52:18 CEST] <beastwick_> that is the goal hah hah
[14:53:30 CEST] <beastwick_> so my buffer could be larger than 110 kbit over time if each frame doesn't need the max 110 kbits?
[14:53:50 CEST] <DHE> that's still not a good idea. keyframes tend to be large relative to other frame types. you'll likely end up with this weird effect where the image quality pulses according to the keyframe interval
[14:54:04 CEST] <beastwick_> that's actually what I noticed last night
[14:54:07 CEST] <beastwick_> the pulsing effect
[14:54:26 CEST] <DHE> yeah, do yourself a favour and find out what the REAL buffer size of your player is and use it
[14:55:22 CEST] <beastwick_> is maxrate the maxrate the buffer can deplete going out over my network?
[14:55:29 CEST] <DHE> internet streaming can usually tolerate a buffer size at least equal to the maxrate. broadcast television uses a fraction, but still a generous fraction.
[14:56:00 CEST] <DHE> if your internet connection is $maxrate fast, and you buffer $bufsize of data prior to starting playback, you should not run out of data and need to stop
[14:56:36 CEST] <DHE> for broadcast TV the time window is usually something like 100 to 500 milliseconds (so 10% to 50% of maxrate) to allow channel surfing
[14:56:46 CEST] <DHE> so for internet purposes, you can probably get away with something even more generous
[14:57:26 CEST] <beastwick_> interesting, I think I am still confused lol, but this helped a little bit. I wish there was like an infographic of the process.
[14:58:03 CEST] <DHE> let's try this another way. what are you doing with your video?
[15:00:16 CEST] <beastwick_> I am trying to extremely restrict bit rate fluctuations. I understand the implications of doing that in terms of quality, but first I just want to see how I can do it, and then ease up to a point I am comfortable. If I specify a bitrate of 2 mbps, currently I don't want to see more bandwidth used per second than what I have specified. I am trying to understand how x264 does this.
[15:01:22 CEST] <DHE> maxrate is just that. the only catch is you need to set a buffersize that matches how much data will be downloaded before playback begins. if there's a 2 second delay before playing begins, then a buffersize of 4M would be fine
[15:01:24 CEST] <beastwick_> I went hunting around because as I understand it the basic bitrate option is an average.
[15:02:20 CEST] <beastwick_> I see, ok, so even if I think my software is reporting a larger kbps for a short time slice it truly is depleting my buffer over the network at the maxrate.
[15:02:35 CEST] <beastwick_> I should probably look at my router for that one.
[15:03:53 CEST] <beastwick_> So if a scene requires say an additional 500 kbits over my maxrate, there's basically enough time for the spike to be downloaded on the user's end because of the buffer, but it's still being sent at the maxrate?
[15:05:11 CEST] <beastwick_> So why on earth would I ever make my bufsize very small? Is that more for minimizing latency?
[15:05:53 CEST] <DHE> like I said, broadcast TV uses a buffer size well under 1 second so that you can start watching TV quickly
[15:06:19 CEST] <beastwick_> right that is indeed what you said, doh
[15:06:21 CEST] <DHE> in that case a user might join at any particular moment rather than play from the start
[15:06:38 CEST] <DHE> so there's more uncertainty about where they're playing from
[15:06:56 CEST] <beastwick_> OK, so it's a latency thing... very interesting...
[15:07:14 CEST] <beastwick_> So if I wanted to do realtime streaming hypothetically, I'd want a small vbv-bufsize.
[15:07:22 CEST] <beastwick_> at the expense of quality
[15:10:47 CEST] <beastwick_> ... this is an aside, but is there a tool I can use to analyze a players decode buffer size?
[15:30:02 CEST] <DHE> I beat something together in perl that uses ffprobe -show_frames. You give it an (estimated) max bitrate and it tells you what the bufsize for the video is. If your maxrate is too low you get an absurdly high buffersize, so it's a bit of trial and error involved
[15:31:04 CEST] <beastwick_> that's pretty cool
[15:31:19 CEST] <beastwick_> you should put it on a git gist or something  for people like me :D
[15:32:50 CEST] <beastwick_> wow I fear I really overcomplicated this whole thing, you made it very easy to understand. I think the reporting tools of the service I am using is truly crap now. They yell at me for bitrate flucs, but the truth is it's not considering the their player's buffer, the network bandwidth is stable arrrg, thanks for your help
[15:33:27 CEST] <beastwick_> also learned now how to minimize playback latency for streaming directly to friends :D, which is awesome
[15:34:37 CEST] <DHE> http://dehacked.2y.net/bitrate-scanner.pl Here's the program I made. It's a bit rough around the edges..
[15:34:51 CEST] <beastwick_> that's cool, maybe I can hack on it myself
[15:34:55 CEST] <beastwick_> ty
[15:35:34 CEST] <DHE> the ffprobe output is read from a file by default because since trial and error is involved I would save the output to disk so I don't have to run it each time. ffprobe with -show_frames actually decodes the video so it's CPU intensive to generate the log
[16:49:12 CEST] <shayden> i'm having problems generating dvbsubs, the command i'm using is ffmpeg -fix_sub_duration -i "MultiLang-Audio-and-Subs-720p-Original.mkv" -i "en.srt" -map 0:0 -map 0:1 -map 1:0 -c:v copy -c:a copy -c:s dvbsub "Single-Tracks.ts"
[16:50:03 CEST] <shayden> when i try to play Single-Tracks.ts with vlc, no subtitles show up, and when i try to play it with ffplay, the video plays fine until the first subtitle is meant to show up, then it crashes with "[IMGUTILS @ 0x7fc04e7fbcc0] Picture size 0x0 is invalid  0B f=0/0
[16:50:07 CEST] <shayden> Cannot allocate subtitle data"
[16:51:01 CEST] <shayden> does anyone have a little experience generating dvbsubs? i also want to avoid just burning them into the main video stream, since i want to eventually have multi-language selectable dvbsubs
[16:55:12 CEST] <TwinTailed> DHE: how do I set frame's PTS? I am getting "Application provided invalid, non monotonically increasing dts to muxer in stream"
[16:56:58 CEST] <c_14> subrip is a text-based subtitle format, dvbsub is an image based format, ffmpeg does not convert beteen the two <- shayden
[16:57:24 CEST] <c_14> tbh it should probably fail with an error outright, not sure why it doesn't
[17:01:00 CEST] <shayden> c_14: i get why ffmpeg can't do image based (dvbsub) to text (srt), but going from text to image is comparatively simple
[17:03:07 CEST] <shayden> c_14: also this page seems to indicate it's possible: http://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo  i'm reading the docs on filter streams to figure out how to create seperate video overlays streams as subtitle streams, i was just hoping someone else here had done it already
[17:03:27 CEST] <c_14> That's something completely different
[17:03:37 CEST] <c_14> That renders the text onto the main video stream
[17:03:41 CEST] <c_14> (or a video stream)
[17:03:58 CEST] <c_14> It does not render the text and encapsulate it into subtile packets as a separate stream
[17:04:31 CEST] <shayden> mmm, ok
[17:08:42 CEST] <shayden> when i do an ffprobe on the output media though, i get this:     Stream #0:0[0x100]: Video: h264 (High 10) ([27][0][0][0] / 0x001B), yuv420p10le(tv, bt709), 960x720 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
[17:08:46 CEST] <shayden>     Stream #0:1[0x101](jpn): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 5.1, fltp, 306 kb/s
[17:08:49 CEST] <shayden>     Stream #0:2[0x102](und): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
[17:09:03 CEST] <shayden> so it's creating a broken dvbsub stream?
[17:09:30 CEST] <shayden> and the actual encoding process doesn't return any errors
[17:10:37 CEST] <c_14> Like I said:
[17:10:45 CEST] <c_14> 14:57 <c_14> tbh it should probably fail with an error outright, not sure why it doesn't
[17:11:12 CEST] <shayden> silent failures are the best kind
[17:11:15 CEST] <c_14> It's creating a dvbsub stream with invalid pictures since it's using the "data" portion of the subrip subtitles as the image portion of the dvbsub stream
[17:11:40 CEST] <c_14> It used to do something similar when generating webvtt streams with dvbsub as input
[17:11:51 CEST] <c_14> It would place binary data into the text subtitle portion
[17:12:02 CEST] <shayden> hmm, ok
[17:12:12 CEST] <c_14> I'll try looking at it later today and see if I can patch in an error
[17:12:18 CEST] <shayden> thanks!
[17:13:36 CEST] <shayden> i guess i'll keep reading about subtitle formats/codecs
[17:14:29 CEST] <shayden> i'm looking through the docs still, but from what you've said i guess ffmpeg only supports dvsub sub copying or encoding from another image based subtitle format?
[17:19:28 CEST] <Gfurst> how do I get into simple filters?
[17:22:14 CEST] <Gfurst> specifically I want to do simple things like, size, scale, crop....
[17:27:21 CEST] <shayden> Gfurst: i haven't done it myself, but i'm looking at the filter docs right now anyway: https://ffmpeg.org/ffmpeg-filters.html#crop
[17:27:50 CEST] <shayden> example command: ffmpeg -i in.mp4 -filter:v "crop=out_w:out_h:x:y" out.mp4 from http://video.stackexchange.com/questions/4563/how-can-i-crop-a-video-with-ffmpeg
[17:27:59 CEST] <Gfurst> shayden: yeah, filtergraphs incredibly alien to me
[17:37:25 CEST] <TwinTailed> [mp4 @ 00600940] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 212992 >= -2048
[17:37:53 CEST] <TwinTailed> I get that message after I add "Frame->pts = av_frame_get_best_effort_timestamp(Frame);"
[17:38:35 CEST] <TwinTailed> but if I don't add that line, I get: "[libx264 @ 01f80060] non-strictly-monotonic PTS", and the output video is just 1 second long with 1 frame shown
[17:42:47 CEST] <TwinTailed> any help really appreciated
[17:48:58 CEST] <Gfurst> ok so I think I've to get scale to work but display still the same size
[17:49:10 CEST] <BtbN> a muxer doesn't get frames. It get packages.
[17:49:15 CEST] <BtbN> And it'a complaining about dts.
[17:50:32 CEST] <asturel> there's no amd vce support for encoding ?:/
[17:52:18 CEST] <asturel> i found https://github.com/GPUOpen-LibrariesAndSDKs/AMF/tree/master/Thirdparty/ffmpeg/ffmpeg-3.0.2 this but sadly this compiled w/o many filters (e.g. delogo)
[18:39:13 CEST] <beastwick> so another quick question about vbv-bufsize and vbv-maxrate, if he vbv-bufsize is lower than the vbv-maxrate, why specify a maxrate?
[18:41:29 CEST] <beastwick> or they don't influence each other
[18:41:37 CEST] <beastwick> ?
[19:07:31 CEST] <TwinTailed> BtbN: So how do I fix the dts its complaining about?
[19:08:01 CEST] <BtbN> set a correct one on the packets you feed to your muxer.
[19:08:11 CEST] <BtbN> But every decent encoder should do that
[19:08:22 CEST] <BtbN> so, don't unset it i guess?
[19:08:55 CEST] <TwinTailed> BtbN: I am unsetting it?
[19:09:12 CEST] <BtbN> No idea, it's your code. Are you?
[19:09:34 CEST] <TwinTailed> I don't think I am
[19:11:14 CEST] <TwinTailed> BtbN: http://pastebin.com/ZTwh6J4z
[19:14:31 CEST] <TwinTailed> BtbN: Does libx264 set it automatically too?
[19:15:49 CEST] <BtbN> The encoder is what makes up the dts...
[19:16:30 CEST] <TwinTailed> BtbN: Isn
[19:16:39 CEST] <TwinTailed> Isn't lib264 for decoding/encoding h264?
[19:16:45 CEST] <TwinTailed> libx264*
[19:16:48 CEST] <BtbN> x264 is a pure encoder.
[19:20:57 CEST] <TwinTailed> BtbN: Is "[libx264 @ 01ee0060] non-strictly-monotonic PTS" anything to worry about
[19:20:58 CEST] <TwinTailed> ?
[19:21:34 CEST] <BtbN> well, it is a strong indicator that you are already passing invalid timestamps to libx264, so it has no chance to generate propper dts/pts.
[19:21:54 CEST] <beastwick> hey BtbN, you've been really helpful, did you see my question about vbv-maxrate and vbv-bufsize?
[19:22:30 CEST] <BtbN> wasn't that already answered?
[19:22:55 CEST] <beastwick> sort of
[19:23:05 CEST] <beastwick> well this question is a little different
[19:23:18 CEST] <beastwick> I understand what is happening with a small bufsize
[19:23:25 CEST] <beastwick> but then why specify a maxrate if it is larger?
[19:23:28 CEST] <TwinTailed> BtbN: How do I pass proper timestamps?
[19:23:37 CEST] <TwinTailed> I need to pass them to the Codec context?
[19:23:44 CEST] <beastwick> I mean the maxrate > bufsize
[19:23:47 CEST] <beastwick> that seems, wrong.
[19:24:06 CEST] <BtbN> TwinTailed, they are per-frame. So you have to set at least a propper pts on them.
[19:24:25 CEST] <BtbN> Which should come out of the decoder, which gets it from the demuxer.
[19:24:51 CEST] <TwinTailed> BtbN: You mean this line of code?pkts->pts = av_rescale_q_rnd(pkts->pts, ps->streams[pkts->stream_index]->time_base, ps2->streams[pkts->stream_index]->time_base, AV_ROUND_NEAR_INF|AV_ROUND_PASS_MINMAX);
[19:26:24 CEST] <SerWou> Hi
[19:26:46 CEST] <BtbN> beastwick, I'd guess so it doesn't fill up the entire buffer with one huge frame, and then trash the quality of the next frames?
[19:26:55 CEST] <BtbN> But i have no idea what magic x264 does internally.
[19:27:56 CEST] <BtbN> From how I understand it, there's a "bit pool", that refillts at a rate defined by vbv-maxrate.
[19:28:08 CEST] <TwinTailed> BtbN: so what should I do to fix the dts?
[19:28:09 CEST] <SerWou> I want to add background music to a video I did. I found multiple option on Google and it works. Unfortunatly, my background music is too loud, is there a way to reduce the background music level while I'm merging the video and music with ffmpeg?
[19:28:13 CEST] <BtbN> And it can't use more bits for a frame than are available in the pool.
[19:28:25 CEST] <BtbN> TwinTailed, no idea, I don't really have time to read and fix your code for you.
[19:28:27 CEST] <beastwick> That's what I was thinking, but I can't wrap my head around it. If I have bufsize the size of one frame, and I set the maxrate to limit the output bandwidth, the bufsize would never be anywhere near the size of maxrate.
[19:28:58 CEST] <BtbN> bufsize the size of one frame?
[19:29:05 CEST] <BtbN> How would that work, they vastly very in size
[19:29:26 CEST] <BtbN> *vary
[19:29:46 CEST] <TwinTailed> BtbN: I didn't tell you to fix my code, just tell me what should I do, since I haven't unset the PTS...
[19:30:08 CEST] <BtbN> then you probably didn't set it in the first place, or didn't set it correctly.
[19:30:47 CEST] <beastwick> Oh, well I believe it was be the minimum bufsize given a GOP. So if I encode at 20 fps and have a bitrate of 2 mbps, then bufsize = 100, which means that there is enough allocation for 1 frame given the desired bitrate per second. (potentially)
[19:30:50 CEST] <BtbN> The demuxer extracts the dts/pts from the container, passes packets with dts/pts to the decoder. Out of that you get a frame with just one timestamp, and the encocder then generates a new dts/pts pair from that.
[19:31:13 CEST] <BtbN> beastwick, that's only on average.
[19:31:21 CEST] <BtbN> I Frames are much larger than P/B frames
[19:31:32 CEST] <beastwick> yes I was warned it would vastly degrade quality
[19:31:44 CEST] <beastwick> but that's not a consideration atm, just trying to understand this
[19:32:04 CEST] <beastwick> so the bufsize isn't in kbits / second, it's just an available pool
[19:32:27 CEST] <BtbN> It's just an "available bits counter", that's capped at vbv-buffsize, and increasing by maxrate bits per second.
[19:32:49 CEST] <beastwick> increasing?
[19:32:54 CEST] <BtbN> yes?
[19:33:04 CEST] <BtbN> until it reaches the buffsize
[19:33:11 CEST] <beastwick> so that's why I am asking
[19:33:17 CEST] <beastwick> if my bufsize is so small
[19:33:24 CEST] <beastwick> what is the point of specifying a maxrate
[19:33:41 CEST] <beastwick> when the bufsize is larger than maxrate, I get it, when it's less, I don't
[19:33:41 CEST] <BtbN> without a maxrate, it won't ever fill up.
[19:34:00 CEST] <BtbN> It's still refilling at the given maxrate
[19:34:08 CEST] <BtbN> the maxrate is per second
[19:34:20 CEST] <BtbN> but you usually have a lot more than one frame per second
[19:34:20 CEST] <beastwick> ah indeed,
[19:34:36 CEST] <beastwick> well in this case 20, so the buffer would fill and empty 20 times per second?
[19:34:46 CEST] <BtbN> It won't neccesarily empty
[19:35:00 CEST] <beastwick> right because some frames might not cost anything depending on factors
[19:35:03 CEST] <BtbN> If a frame doesn't need all of it, some will be left over for another frame, that might need more
[19:35:05 CEST] <BtbN> that's the whole idea
[19:35:09 CEST] <TwinTailed> BtbN: In the transcoding.c example, the pts and dts are set on the AVPacket before being decoded
[19:35:50 CEST] <BtbN> So every time a frame is encoded, it removes, on average, maxrate/fps bits from the pool
[19:35:53 CEST] <beastwick> OH, so when I say 2 mbps maxrate, the amount of refill per second is affected.
[19:36:02 CEST] <beastwick> so just because the buffer is small
[19:36:17 CEST] <beastwick> I am restricting it over the course of 1 second.
[19:36:33 CEST] <BtbN> a small buffer just prevents high spikes
[19:36:53 CEST] <BtbN> because it's very possible the I/P frames might not need a lot of space for quite a while
[19:36:53 CEST] <beastwick> yeah but we're talking about the rate at which the buffer is filled back with bits to use right?
[19:37:02 CEST] <BtbN> and with a large buffer, you'd collect a lot of available bits
[19:37:14 CEST] <BtbN> and when it then suddenly needs more, you'd end up with a huge spike
[19:37:19 CEST] <BtbN> a smaller buffer prevents that
[19:37:27 CEST] <BtbN> at the cost of worse quality during that spike
[19:37:54 CEST] <beastwick> see I thought the spike wouldn't matter due to maxrate, because I was told maxrate is the rate at which the buffer is read (or I guess emptied) to go out (in this case over a network)
[19:38:13 CEST] <BtbN> no, maxrate is the rate at which it's refilled
[19:38:28 CEST] <BtbN> the rate at which it's emptied is defined by how much bitrate the encoder actually needs
[19:39:25 CEST] <beastwick> ok this is making a little more sense now
[19:40:24 CEST] <beastwick> so that's why I can have double the bufsize of maxrate and people with slower connections can wait longer to receive data, because it's... buffered? lol
[19:40:34 CEST] <BtbN> things get bad when the bufsize is too small to even hold a single frame
[19:40:35 CEST] <beastwick> when there is a spike
[19:41:30 CEST] <BtbN> with a high buffsize, the encoder might momentarily produce a lot more outgoing bitrate than the defined maxrate
[19:41:45 CEST] <BtbN> because the buffer is plenty filled, and then a scene change or a lot of action happens
[19:42:03 CEST] <BtbN> So there will be a spike with like 10Mbit/s for a few seconds
[19:42:17 CEST] <BtbN> but on average, the defined maxrate will be kept
[19:42:26 CEST] <beastwick> but because it's behind in the sense that it's buffered, people can spend more time accumulating data that had a higher outgoing bitrate
[19:42:27 CEST] <beastwick> ?
[19:42:42 CEST] <beastwick> at their constant speed?
[19:42:50 CEST] <beastwick> i'm not sure if what I am saying makes sense to you
[19:42:51 CEST] <beastwick> :(
[19:43:10 CEST] <BtbN> so people receving the stream just have to buffer for at least vbv-bufsize/vbv-maxrate seconds, and they will be fine.
[19:43:37 CEST] <beastwick> oh, but I don't want them to see that they are buffering in that case though
[19:44:18 CEST] <BtbN> Every decent player buffers that much by itself
[19:44:37 CEST] <beastwick> I mean that I don't want the video the pause, and say buffering, and then resume.
[19:44:50 CEST] <BtbN> In the worst case, that will only happen once
[19:45:02 CEST] <beastwick> at the begining?
[19:45:03 CEST] <BtbN> And then the player is so far behind that the buffer will hold
[19:45:10 CEST] <BtbN> no, the first time a bitrate spike happens
[19:45:16 CEST] <beastwick> I see what you mean
[19:45:54 CEST] <beastwick> can vbv-init be used to just cause them to wait at the beginning? to anticipate an eventual spike?
[19:47:22 CEST] <BtbN> Isn't that just the initial vbv-buffer fill value?
[19:47:34 CEST] <BtbN> I have never seen a player that doesn't have a buffer settings.
[19:47:41 CEST] <BtbN> And it's usually at least a few seconds
[19:48:05 CEST] <BtbN> so as long as you don't set the bufsize to something crazy like 20 times your maxrate, you're fine.
[19:51:25 CEST] <beastwick> so a bigger bufsize will increase the chances of a spike, and that will affect my outgoing bitrate over a network?
[19:51:52 CEST] <beastwick> I really thought that the data leaving the buffer left at a constant rate :(
[19:54:05 CEST] <beastwick> so the only way to really stop spikes is to shrink the bufsize, i don't understand then why streaming sites suggest a bufsize of twice the maxrate :(, your bitrate could spike over your available bandwidth
[19:58:10 CEST] <TwinTailed> BtbN: Should I use this formula "(1 / FPS) * sample rate * frame number" to set the frame's pts before encoding?
[19:58:42 CEST] <BtbN> you should use the timestamps you already have
[19:59:05 CEST] <BtbN> unless you're decoding something that actually doesn't have any. Then you have to make them up.
[20:00:00 CEST] <TwinTailed> avcodec_receive_frame should be able to do that automatically?
[20:25:15 CEST] <SerWou> back
[20:25:29 CEST] <SerWou> I was away, maybe I haven't saw the answer
[20:25:42 CEST] <SerWou> be here is my question again, sorry for double post
[20:26:00 CEST] <SerWou> I want to add background music to a video I did. I found multiple option on Google and it works. Unfortunatly, my background music is too loud, is there a way to reduce the background music level while I'm merging the video and music with ffmpeg?
[20:27:17 CEST] <SerWou> my current command : ffmpeg -i Realisation.mp4 -i One.mp3 -filter_complex "[0:a][1:a]amerge=inputs=2[a]" -map 0:v -map "[a]" -c:v copy -c:a libvorbis -ac 2 -shortest output.mp4
[20:31:36 CEST] <SerWou> is there an option to loop the music too ? The opposite of -shortest
[20:32:48 CEST] <SerWou> loop -1 ?
[20:35:33 CEST] <kepstin> SerWou: as far as volume goes, you can just add a 'volume' filter on the audio file input, e.g. '[1:a]volume=-6db[quieter];[0:a][quieter]amerge=inputs=2[a]'
[20:35:46 CEST] <furq> -loop -1 only works with image2 iirc
[20:36:37 CEST] <kepstin> if the audio file's some reasonable length such that it would fit in ram when decoded to pcm, I suppose you could just use the 'aloop' filter.
[20:38:26 CEST] <SerWou> it's 7Mo MP3 file @kepstin
[20:38:31 CEST] <kepstin> hmm. you probably don't want to be doing amerge here, I don't think it does what you want - if you have two stereo inputs, it'll generate a 4-channel output, not a "mixed" stereo
[20:38:46 CEST] <kepstin> you probably want amix instead of amerge :)
[20:39:00 CEST] <SerWou> I don't have a clue at all
[20:39:20 CEST] <SerWou> it's web stereo video
[20:39:29 CEST] <SerWou> not high quality
[20:39:48 CEST] <kepstin> if you don't have a clue, then you want amix, not amerge.
[20:40:06 CEST] <kepstin> and a typical 3-4minute song should fit fine in ram with the aloop filter
[20:40:35 CEST] <SerWou> hum
[20:40:46 CEST] <SerWou> could you help me with the new command line please ?
[20:41:22 CEST] <SerWou> something like this http://stackoverflow.com/questions/34117626/how-change-audio-volumes-with-amix-filter-in-ffmpeg
[20:41:44 CEST] <kepstin> '[1:a]aloop,volume=-6db[quieter];[0:a][quieter]amix=inputs=2[a]'
[20:41:49 CEST] <SerWou> well no ;)
[20:41:59 CEST] <SerWou> ok, let me try
[20:42:20 CEST] <kepstin> same command, just replace the filter with that ^^
[20:42:47 CEST] <kepstin> hmm. you're probably gonna run into problems putting vorbis into an mp4 file tho, I didn't think that was supported?
[20:43:04 CEST] <SerWou> looks like a bad idea indeed
[20:43:11 CEST] <SerWou> what do you recommand?
[20:43:36 CEST] <kepstin> either use mkv as the output, or switch the audio to aac or mp3 (libmp3lame)
[20:44:05 CEST] <furq> you need to set loop and size with aloop or it won't do anything
[20:45:03 CEST] <furq> -af aloop=4:2^31-1 will play the input five times
[20:47:28 CEST] <SerWou> lol, i'm lost...
[20:47:40 CEST] <furq> how many times do you want to loop the background music
[20:47:52 CEST] <SerWou> as long as the video length
[20:47:53 CEST] <kepstin> furq: huh, I thought it would just loop everything forever by default.
[20:48:07 CEST] <kepstin> I suppose since it stores in ram the "everything" would be a bad default :)
[20:48:40 CEST] <furq> you can't really just say "as long as the video length" with aloop
[20:49:19 CEST] <SerWou> let's say 1h loop and use -shortest to stop when the video is over ?
[20:49:35 CEST] <furq> '[1:a]volume=-6db,aloop=8:2^31-1[quieter];[0:a][quieter]amix=inputs=2:duration=shortest[a]'
[20:49:40 CEST] <furq> replace the 8 with however many times you need
[20:52:04 CEST] <furq> it sure would be nice if aloop took -1 as an argument to samples
[20:52:44 CEST] <SerWou> the error http://pastebin.ca/3721521
[20:53:10 CEST] <furq> oh
[20:53:14 CEST] <furq> i think it might have to be dB
[20:53:34 CEST] <kepstin> oh, right, it's case sensitive ;?
[20:53:36 CEST] <kepstin> :/
[20:53:51 CEST] <furq> speaking of arguments to filters that we'd like to change
[20:56:52 CEST] <SerWou> No such filter: 'aloop'
[20:57:13 CEST] <furq> you need an ffmpeg newer than 3.0 for aloop
[20:57:57 CEST] <furq> there are other ways but they're even more cumbersome
[20:58:06 CEST] <SerWou> :-@
[20:58:07 CEST] <furq> you might have an easier time just using sox
[20:58:17 CEST] <furq> sox -i in.mp3 out.wav repeat 8
[20:58:47 CEST] <SerWou> but no way to reduce the mp3 volume, I have to do it in another way
[20:59:32 CEST] <furq> sox -v 0.8 -i in.mp3 out.wav repeat 8
[20:59:46 CEST] <furq> or you could still use the volume filter
[21:20:55 CEST] <yury-linux> hello, I'm trying to create an audio-only build that only decodes audio formats supported, and outputs in wav, but  that is not a hard requirement. I also care about binary size so I wanted to create shared build if possible.
[21:22:17 CEST] <DHE> you'll need to specify what you want in the configure scripts. check what's available with: configure --list-encoders  and the other types...
[21:23:22 CEST] <yury-linux> yeah, I got that, but I kinda confused about filters, demuxers and other stuff
[21:23:43 CEST] <DHE> then you can configure with:  configure --disable-encoders --enable-encoder="aac,ac3,adpcm*,pcm*,vorbis" ...
[21:24:25 CEST] <DHE> well, yeah there's a lot of them. it's safe to leave things enabled, it's just executable size and compile time
[21:24:37 CEST] <yury-linux> like what I need ao actually care if I just need it to be able to read all supported formats and output to one or two
[21:25:33 CEST] <yury-linux> ok, what about shared-ness of the build?
[21:25:38 CEST] <DHE> ?
[21:25:47 CEST] <DHE> the .so files will be smaller if that's what you mean
[21:26:49 CEST] <yury-linux> yeah, but I mean atm I have an error (I can post a gist) saying it can't find some lib, while on non-shared build it just works.
[21:28:07 CEST] <yury-linux> here https://gist.github.com/YurySolovyov/2d65477813e2fe9f44a18fe660d030a2
[21:28:31 CEST] <yury-linux> error is: ./ffmpeg: error while loading shared libraries: libavfilter.so.6: cannot open shared object file: No such file or directory
[21:32:11 CEST] <furq> you need to run make install or set LD_LIRARY_PATH to contain your build directory
[21:32:16 CEST] <furq> LD_LIBRARY_PATH
[21:32:31 CEST] <DHE> and since each .so goes into its own directory, that makes for a heck of a list...
[21:32:42 CEST] <furq> also the combined size of the binary and the shared libs will probably be bigger than a static binary
[21:33:43 CEST] <JEEB> DHE: which OS? on lunix they all go under lib/ and in windows they all go under bin/
[21:34:01 CEST] <furq> yeah you're thinking of the headers
[21:34:20 CEST] <DHE> JEEB: once installed, yes. if you try to run from the compile directory, you need LD_LIBRARY_PATH=./libavcodec:./libavformat:./libavutil:...
[21:34:26 CEST] <JEEB> right
[21:34:29 CEST] <DHE> and that's just messy.
[21:34:30 CEST] <furq> oh right yeah
[21:34:44 CEST] <DHE> so what I do is: ln -s */*.so .
[21:34:44 CEST] <JEEB> IMHO you should always install into a prefix, the prefix could be in your home dir even if you want
[21:34:56 CEST] <JEEB> --prefix=/home/jeeb/ownapps etc
[21:35:03 CEST] <DHE> which isn't great either, but at some point it becomes the lesser hassle
[21:35:31 CEST] <DHE> then again I actually like the static link method
[21:35:41 CEST] <yury-linux> does every format requres external libs? I can start with ones that supported without external libs for now
[21:35:51 CEST] <JEEB> 99% of decoding and demuxing things are internal
[21:35:52 CEST] <furq> very few do for decoding
[21:36:16 CEST] <furq> if you only need to output wav then i'm pretty sure you won't need any external libs
[21:36:41 CEST] <furq> yury-linux: https://www.ffmpeg.org/general.html#Audio-Codecs
[21:37:22 CEST] <yury-linux> one note is that I would also need ffprobe for metada, but I'm not sure how that would affect anything
[21:37:22 CEST] <furq> looks like only speex, celt and iLBC need libs for decoding
[21:37:32 CEST] <JEEB> furq: and teletext
[21:37:45 CEST] <DHE> I also run a minimal build, but it's still reasonably featured. all the mpeg standards (including h26[45]), all the input formats I would reasonably expect online, and the filters I see myself using, etc.
[21:37:47 CEST] <JEEB> (yes, lol teletext)
[21:37:49 CEST] <furq> that's not an audio codec
[21:37:56 CEST] <JEEB> ah, limited to audio
[21:37:56 CEST] <DHE> ultimately it cut my ffmpeg static build almost in half
[21:38:18 CEST] <JEEB> DHE: yeah - if you first make your code work and then start limiting the features to the subset you need you can get nice results
[21:38:19 CEST] <DHE> 20 mb -> 12
[21:38:32 CEST] <furq> i used the pro technique of not caring about binary size
[21:38:43 CEST] <DHE> JEEB: I needed to strip a lot of stuff out. I built on my workstation, but run it on a headless system. even the indevs and outdevs caused me pain.
[21:38:58 CEST] <DHE> but I digress
[21:39:38 CEST] <yury-linux> btw, which in/out devs I would need if I just want to send the resulting sream to net ?
[21:40:08 CEST] <furq> you don't need any devices for that afaik
[21:40:13 CEST] <yury-linux> cool
[21:41:46 CEST] <yury-linux> filters? parsers?
[21:42:26 CEST] <furq> if you're literally just transcoding to pcm then you don't need any filters
[21:42:33 CEST] <furq> parsers i have no idea
[21:43:37 CEST] <DHE> parsers are like minimal decoders. they parse the headers of the codecs, maybe packetize elementary streams
[21:43:48 CEST] <DHE> you can do: configure --list-parsers   # and see what they are
[21:44:05 CEST] <DHE> there's a few audio codecs... aac, ac3, opus, vorbis
[21:44:14 CEST] <DHE> (and others)
[21:44:23 CEST] <yury-linux> aac
[21:44:33 CEST] <yury-linux> yeah, will keep them for now
[21:45:40 CEST] <yury-linux> bsfs ?
[21:46:10 CEST] <DHE> bit stream filter s
[21:46:46 CEST] <DHE> probably don't need anything there
[21:49:51 CEST] <yury-linux> what about mux/demuxers?
[21:50:33 CEST] <yury-linux> if it is stereo audio file, I want still it to be stereo
[21:50:42 CEST] <yury-linux> not sure it is related...
[21:51:01 CEST] <kepstin> if you want to read audio from an mp4 file, you'll need an mp4 demuxer, for example
[21:53:40 CEST] <yury-linux> and just muxers are to embed audio back to video?
[21:54:07 CEST] <yury-linux> so I guess it is ok to leave demuxers, but drop muxers....
[21:56:16 CEST] <furq> you'll presumably want the wav muxer
[21:57:27 CEST] <furq> you can also probably get rid of most of the demuxers
[22:04:57 CEST] <yury-linux> weird, now there is no ffmpeg file
[22:06:48 CEST] <furq> did you use --disable-programs
[22:07:51 CEST] <yury-linux> here's my build https://gist.github.com/YurySolovyov/2d65477813e2fe9f44a18fe660d030a2
[22:09:13 CEST] <furq> did the build actually finish
[22:09:24 CEST] <furq> also wavpack isn't the same as wav
[22:10:04 CEST] <yury-linux> should I put wav there?
[22:10:21 CEST] <kepstin> the "encoder" you'll normally use in wav is pcm_s16le; i'm not sure if you can even disable it.
[22:11:01 CEST] <furq> you probably also want the m4a demuxer and the aac decoder
[22:11:17 CEST] <furq> and ogg/vorbis/opus etc
[22:12:06 CEST] <kepstin> is m4a even a separate demuxer? I thought it was just an alias on the mov,mp4,m4a,3gp,3g2,mj2 demuxer
[22:12:10 CEST] <furq> pcm_s16le shows up in --list-encoders so it couldn't hurt to put it in --enable-encoder
[22:12:23 CEST] <furq> kepstin: no, but it's not the same as aac which is all he has
[22:13:22 CEST] <furq> actually you're not doing --disable-demuxers so it doesn't really matter
[22:13:25 CEST] <yury-linux> I'm ok with keeping some aydio suff, and wanted to focus on ripping video off
[22:13:38 CEST] <yury-linux> audio*
[22:13:39 CEST] <furq> aac is normally packed in m4a
[22:13:56 CEST] <furq> if you're only dealing with raw aac bitstreams then you don't need m4a
[22:15:19 CEST] <kepstin> i'm pretty sure you'd want '--enable-demuxer=mov' to get mp4/m4a support, I don't see any separate mp4/m4a entry in the configure script.
[22:16:23 CEST] <yury-linux> for some reason configure gives Enabled programs: ffprobe, no ffmpeg
[22:16:54 CEST] <kepstin> yury-linux: you must have disabled something that the ffmpeg tool needs
[22:17:21 CEST] <yury-linux> i'll update config and post
[22:17:42 CEST] <yury-linux> here https://gist.github.com/YurySolovyov/2d65477813e2fe9f44a18fe660d030a2
[22:18:46 CEST] <kepstin> ffmpeg needs avfilter, avformat which you are disabling
[22:18:55 CEST] <kepstin> the "ffmpeg" program needs ...
[22:19:24 CEST] <yury-linux> right, thanks
[22:19:29 CEST] <yury-linux> will try the build
[22:20:04 CEST] <kepstin> er, i guess you're not disabling avformat
[22:20:12 CEST] <kepstin> so it's probably just avfilter that's the issue
[22:20:38 CEST] <kepstin> (ffmpeg makes use of avfilter internally, with auto-inserted filters for e.g. format conversion, resampling, etc)
[22:21:18 CEST] <yury-linux> ok, ~10mb
[22:22:07 CEST] <yury-linux> I allowed for avfilter and it went ok
[22:22:53 CEST] <yury-linux> but i still seen in build output that vp9 gets build, x264, stuff like that
[22:23:32 CEST] <yury-linux> under libavcodec
[22:23:39 CEST] <kepstin> right now your build is including a lot of stuff like video decoders that you probably don't want. you should put "--disable-decoders" before the line that has "--enable-decoder=..." to disable all the ones you don't want
[22:24:01 CEST] <kepstin> (right now the --enable-decoder= is doing nothing - it's just enabling decoders that are already enabled)
[22:25:13 CEST] <yury-linux> yup, 4mb, cool
[22:25:20 CEST] <kepstin> and do the same for encoders, etc.
[22:25:36 CEST] <kepstin> (like --disable-encoders --enable-encoder=pcm_s16le)
[22:28:19 CEST] <yury-linux> what's the files with _g on the end?
[22:29:53 CEST] <TwinTailed> Does anyone know how to solve "[libx264 @ 004b8500] non-strictly-monotonic PTS" ??
[22:30:53 CEST] <Mavrik> By not passing frames out of order to x264.
[22:31:11 CEST] <Mavrik> It's telling you that frame timestamps aren't increasing monotnically.
[22:31:20 CEST] <Mavrik> (They're not in order as they should be displayed.)
[22:31:56 CEST] <TwinTailed> Mavrik: But I am using avcodec_send_packet/avcodec_receive_frame functions
[22:31:57 CEST] <TwinTailed> in order
[22:32:04 CEST] <TwinTailed> how can they be out of order?
[22:32:36 CEST] <Mavrik> No idea, check your protocols and code.
[22:32:48 CEST] <Mavrik> I'm just telling you what x264 is complaining about :P
[22:32:53 CEST] <Mavrik> You might be also messing up the PTS numbers.
[22:32:59 CEST] <Mavrik> (Did you even print them out yet?)
[22:33:13 CEST] <TwinTailed> Mavrik: http://pastebin.com/H5B5k6w7 , would you mind taking a look at lines 191-294?
[22:33:24 CEST] <TwinTailed> they got the decoding/encoding code
[22:33:28 CEST] <yury-linux> this seems to work, thanks guys, I'll just keep adding needed stuff
[22:34:16 CEST] <Mavrik> TwinTailed, it's really really easier for you to print out the values
[22:34:22 CEST] <Mavrik> Than me debug your C code.
[22:34:43 CEST] <TwinTailed> what values?
[22:35:33 CEST] <Mavrik> timestampt.
[22:35:36 CEST] <Mavrik> *timestamps
[22:35:38 CEST] <Mavrik> PTS and DTS.
[22:36:24 CEST] <TwinTailed> pts for avpacket or avframe?
[22:36:29 CEST] <Mavrik> All of them.
[22:36:37 CEST] <Mavrik> They need to be consistent across the transcoding process.
[22:36:49 CEST] <Mavrik> Since they determine when video player should show the frame right? :P
[22:37:00 CEST] <Mavrik> You're probably losing them somewhere.
[22:37:05 CEST] <Mavrik> Or converting timebases wrongly
[22:37:09 CEST] <Mavrik> Or reordering them somehow
[22:37:16 CEST] <Mavrik> Or you're getting them out of order in the first place.
[22:37:20 CEST] <Mavrik> Figure out which one is it :)
[22:37:37 CEST] <TwinTailed> Mavrik: stream: 0 | PTS: 0 | DTS: -2147483648 | Frame PTS: 0
[22:37:44 CEST] <TwinTailed> those values for all packets
[22:38:05 CEST] <Mavrik> Well that won't work :)
[22:38:14 CEST] <Mavrik> They kinda need to increase with time
[22:38:55 CEST] <Mavrik> A frame shown at exactly 1 sec has to have PTS of 1/time_base
[22:39:03 CEST] <TwinTailed> will it work if i set them manually to a statically increase value?
[22:39:16 CEST] <Mavrik> Only if your video has constant framerate.
[22:39:22 CEST] <TwinTailed> no it doesnt
[22:39:39 CEST] <Mavrik> Well, then you'll be telling the video player wrong values for when it should show frames :)
[22:39:54 CEST] <TwinTailed> i've tried to do the (1 / FPS) * sample rate * frame number formula
[22:40:03 CEST] <Mavrik> For audio?
[22:40:05 CEST] <TwinTailed> but it seems not to work
[22:40:07 CEST] <TwinTailed> both
[22:40:13 CEST] <Mavrik> Well.
[22:40:15 CEST] <Mavrik> :)
[22:40:21 CEST] <TwinTailed> :)
[22:40:31 CEST] <Mavrik> Doesn't your input set those?
[22:40:51 CEST] <Mavrik> Since you're transcoding something, your input should have those set already. What's your source?
[22:41:39 CEST] <TwinTailed> so the decoder is not passing them to the AVPacket?
[22:42:18 CEST] <Mavrik> No idea.
[22:42:20 CEST] <TwinTailed> is it ok if the dts is always 0?
[22:42:25 CEST] <Mavrik> Did you check if your demuxed packets have them set?
[22:42:26 CEST] <Mavrik> No.
[22:42:41 CEST] <Mavrik> Then you're telling the player that the frames need to be ALL decoded at the start of video.
[22:42:44 CEST] <Mavrik> Which will break them horribly.
[22:42:50 CEST] <Mavrik> C'mon ;)
[22:44:34 CEST] <TwinTailed> Mavrik: so avcodec_send_packet() should set the PTS/DTS to the input AVPacket?
[22:44:47 CEST] <Mavrik> send_packet?
[22:45:16 CEST] <TwinTailed> yeah?
[22:45:33 CEST] <Mavrik> In most cases, yes.
[22:45:39 CEST] <Mavrik> Unless the protocol doesn't have that.
[22:45:45 CEST] <Mavrik> But you still didn't tell what the protocol is.
[22:45:51 CEST] <kepstin> my impression was that normally the encoder should set the dts based on the pts and any reordering it does?
[22:46:03 CEST] <TwinTailed> by protocol you mean codec?
[22:46:18 CEST] <TwinTailed> kepstin: its not doing that it seems
[22:47:18 CEST] <kepstin> TwinTailed: well, the example you gave didn't have a pts, so...
[22:47:21 CEST] <Mavrik> kepstin, yes, but only if it gets an AVFrame with proper PTS set
[22:47:35 CEST] <Mavrik> and AVFrame will have a pts set if the decoder got AVPacket with both dts/pts set
[22:47:40 CEST] <Mavrik> :)
[22:48:00 CEST] <Mavrik> So you need to have a proper numbering through the whole chain
[22:48:25 CEST] <TwinTailed> http://pastebin.com/wCX7r1Tj this is a really small code snippet
[22:49:30 CEST] <TwinTailed> Mavrik: What do you mean by protocol?
[22:51:00 CEST] <TwinTailed> Mavrik: What is the difference between PTS and DTS?
[22:52:21 CEST] <kepstin> TwinTailed: with complicated codecs like h.264, video frames might be predicted from future frames. when this is the case, the frames have to be stored in the file and handed to the decoder in a different order than they appear in the real video. This order - the "decode" order - is indicated with dts - the "decode time stamp"
[22:52:57 CEST] <kepstin> I've heard pts as "play time stamp" or "presentation time stamp", it indicates when the frame should actually be shown on screen
[22:53:28 CEST] <Mavrik> TwinTailed, http://www.programering.com/a/MjNwcTMwATg.html
[22:53:36 CEST] <Mavrik> https://stackoverflow.com/questions/6044330/ffmpeg-c-what-are-pts-and-dts-what-does-this-code-block-do-in-ffmpeg-c
[22:53:49 CEST] <kepstin> or someone could just link to external descriptions, that works too :)
[22:54:14 CEST] <Mavrik> Yeah, you kinda need to understand these concepts to be able to work with video.
[22:55:35 CEST] <TwinTailed> ah thank you both for the explanations
[22:55:43 CEST] <TwinTailed> but why is dts being 0?
[22:56:28 CEST] <kepstin> TwinTailed: that's not the right question - you need to figure out why the pts in rawFrame is 0.
[22:56:57 CEST] <TwinTailed> kepstin: If I use "rawFrame->pts = av_frame_get_best_effort_timestamp(rawFrame);" before starting to encode, it is no longer 0
[22:57:22 CEST] <kepstin> TwinTailed: what's the type of file you're reading from? what demuxer?
[22:57:23 CEST] <TwinTailed> I get values like 12288 then 13312
[22:57:29 CEST] <TwinTailed> mp4
[22:57:53 CEST] <kepstin> so... why isn't pts already being set? you shouldn't have to do anything there.
[22:57:56 CEST] <kepstin> hmm.
[22:58:44 CEST] <kepstin> what do the dts and pts values on pkts look like?
[22:59:12 CEST] <TwinTailed> kepstin: stream: 1 | PTS: 1024 | DTS: 0
[22:59:21 CEST] <TwinTailed> stream: 1 | PTS: 2048 | DTS: 0
[22:59:38 CEST] <TwinTailed> for stream 0 however
[22:59:39 CEST] <TwinTailed> stream: 0 | PTS: 50050 | DTS: 0
[23:01:15 CEST] <kepstin> TwinTailed: well, the size of the values is only useful when you know what the timebase is - as long as  they're increasing that's good. Strange that DTS is 0 tho. What codecs are used in the file for video and audio?
[23:01:42 CEST] <TwinTailed> avc1 and aac i think
[23:02:09 CEST] <kepstin> does DTS start increasing once you get past some number of frames? The h264 decoder might have to read in a bunch of frames before it can output one.
[23:02:39 CEST] <TwinTailed> i get this error in the end
[23:02:39 CEST] <kepstin> (i.e. you have to keep feeding frames into the decoder before you might eventually get one out)
[23:02:48 CEST] <TwinTailed> [mp4 @ 005e5180] Application provided invalid, non monotonically increasing dts
[23:02:48 CEST] <TwinTailed> to muxer in stream 0: 19456 >= -4004
[23:03:18 CEST] <TwinTailed> kepstin: I know about that, I have already implemented a fix for such cases
[23:04:06 CEST] <kepstin> TwinTailed: well, that's the general case, really. sometimes you get lucky and hit the special case where they have a frame ready immediately ;)
[23:05:11 CEST] <TwinTailed> but DTS is 0 even for the aac stream
[23:09:44 CEST] <TwinTailed> even if i set dts manually before the printf, it is still 0
[23:10:26 CEST] <TwinTailed> even if i set it to 1
[23:11:27 CEST] <kepstin> you shouldn't ever be manually setting dts, since you can't possibly know what it's supposed to be.
[23:13:00 CEST] <TwinTailed> was just trying
[23:13:10 CEST] <TwinTailed> should i report that as a bug?
[23:14:14 CEST] <kepstin> well, if your decoded frames don't have a pts set, there is a bug somewhere. Assuming the 'ffmpeg' tool can read your file, it's probably not a bug in the ffmpeg libraries.
[23:17:56 CEST] <kepstin> (if ffmpeg or e.g. "ffprobe -show_frames" cannot read correct pts values from your example file, you should open a bug and provide that as a sample...)
[23:19:43 CEST] <TwinTailed> will try it rn
[23:20:41 CEST] <TwinTailed> kepstin: it does
[23:20:47 CEST] <TwinTailed> show correct values
[23:21:05 CEST] <TwinTailed> pkt_pts=58058
[23:21:06 CEST] <TwinTailed> pkt_pts_time=0.967633
[23:21:06 CEST] <TwinTailed> pkt_dts=58058
[23:21:06 CEST] <TwinTailed> pkt_dts_time=0.967633
[23:21:06 CEST] <TwinTailed> best_effort_timestamp=58058
[23:21:06 CEST] <TwinTailed> best_effort_timestamp_time=0.967633
[23:21:07 CEST] <TwinTailed> pkt_duration=2002
[23:21:22 CEST] <kepstin> then the issue is in your code somewhere :/
[23:23:08 CEST] <TwinTailed> kepstin: but ffprobe uses the deprecated decode/encode functions
[23:23:20 CEST] <TwinTailed> it might be a bug in the new functions
[23:23:46 CEST] <kepstin> i assume there would be a lot more people complaining here if that was the case.
[23:24:55 CEST] <TwinTailed> kepstin: the number of questions regarding libav with h264 on google can be counted using ur fingers
[23:30:53 CEST] <furq> how many fingers do you think i have
[23:31:01 CEST] <kepstin> huh, the send/receive frame/packet functions were only added earlier this year. that's really new. I suspect in almost all codecs it's actually using the fallback where it just calls the old api for you :)
[23:31:48 CEST] <TwinTailed> kepstin: from the code snippet, do you see anything wrong?
[23:32:40 CEST] <kepstin> TwinTailed: I've never used this api before, so I dunno :/
[23:37:29 CEST] <kepstin> as far as I can tell from a dumb grep command, there are currently 0 users of the new api in the ffmpeg source tree (aside from try_decode_frame, which isn't itself used anywhere), and only 1 codec which natively implements it (cuvid)
[00:00:00 CEST] --- Fri Sep 23 2016