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

[burek]

[03:01:24 CET] <GTAXL> I have a music video I want to replace the AAC audio track with FLAC. The video is .mp4 AVC with an AAC audio track. I wish to replace the AAC track with a flac file. I assume a .mkv container as it supports both formats would work. What would be the ffmpeg command to accomplish this, preferably without a re-encode and to keep the video settings/bitrate and flac bitrate, etc. Thanks
[03:13:17 CET] <furq> GTAXL: -i foo.mkv -i foo.flac -c copy -map 0:v -map 1:a bar.mkv
[03:16:33 CET] <GTAXL> Thanks, looks easy enough. :D
[10:16:54 CET] <andreaskarlsson> Hi. Can ffmpeg read multiple input streams at the same time? I'm trying to feed both live audio & video through named pipes, but it seems that ffmpeg waits for my first pipe to close before starting to read from the second. My commandline: http://pastebin.com/2mCXQMwn
[11:18:58 CET] <Rathann> hi
[11:19:07 CET] <Rathann> I can't get the -t option to work :(
[11:19:52 CET] <Rathann> I'll post the command line and error in a minute
[11:21:41 CET] <Rathann> https://paste.fedoraproject.org/542774/86030890/
[11:21:54 CET] <Rathann> basically the error is:
[11:21:56 CET] <Rathann> Invalid duration specification for t: 00:80:00
[11:22:07 CET] <Rathann> but according to man ffmpeg-utils, that's a valid form :(
[11:22:16 CET] <Rathann> I also tried -t 80:00
[11:22:20 CET] <Rathann> same error
[11:22:50 CET] <Rathann> and yes, the input file is longer than 80 minutes
[11:25:23 CET] <Rathann> huh, oddly enough it works if I specify just the seconds (4800)
[13:35:09 CET] <vans163> Is anyone aware if inband SPSPPS will fix this problem? https://github.com/moonlight-stream/moonlight-chrome/blob/master/viddec.cpp#L292
[15:39:51 CET] <Stummy> hey there
[15:39:57 CET] <Stummy> :)
[15:45:01 CET] <Stummy> i'm in trouble someone can helpme? e_e
[15:47:34 CET] <durandal_1707> Stummy: like what?
[15:48:31 CET] <Stummy> i'm with a big video in the format m4s, segmented in 400 parts
[15:48:42 CET] <Stummy> and i need to merge it into a mp4
[15:51:43 CET] <Stummy> http://pastebin.com/51d0Brkz
[15:51:53 CET] <Stummy> i'm trying to do this, and get this error
[15:54:49 CET] <Stummy> i'm for days trying to resolve it, but nothing untill now
[15:54:54 CET] <Stummy> hehe
[15:58:45 CET] <popara> Hello, Anybody here familar with QSV? I'm willing to pay if someone managed to make it for me as i'm trying 2 months now without success
[16:00:54 CET] <jkqxz> popara:  What are you trying to do?
[16:01:58 CET] <popara> mate i have do really more than 50 tries to make it work. I install MSS2007R2 fine ( on centos 7.2 ), i compile FFmpeg with libmfx fine too, and when i'm trying to call h264_qsv i get "Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode.". With -look_ahead 0 transcoding is starting, but the whole load is on CPU
[16:02:12 CET] <popara> i remember one time i made it by luck, with an old MSS, but from then i can't make it to work
[16:02:17 CET] <popara> i have a kaby lake CPU
[16:02:37 CET] <popara> i tried on Ubuntu 14.04, and ubuntu 16.10 64bit, and in both of them i get the same error i get on centos 7.2
[16:02:48 CET] <popara> i have followed the documentation line by line, still no luck
[16:03:07 CET] <popara> but on a Windows Machine, it works without problems
[16:03:28 CET] <popara> the same machine i mean, with windows OS 10 64bit, it works perfect, so i 'm doing something wrong on linux but i dont know what
[16:03:32 CET] <jkqxz> Which dispatcher are you using?
[16:03:56 CET] <popara> from the MSS one, and i manually add the libmfx.pc on pkg-config
[16:05:39 CET] <BtbN> why not juse use vaapi instead and avoid all the pain with intels shit?
[16:05:43 CET] <BtbN> *just
[16:05:49 CET] <jkqxz> Can you try it with the packaged one?  <https://github.com/lu-zero/mfx_dispatch>
[16:06:06 CET] <jkqxz> Or that.
[16:06:16 CET] <popara> BtbN and will i have the same perfomance? What is the difference with the qsv
[16:06:17 CET] <kerio> why not just use libx264? :^)
[16:06:51 CET] <BtbN> popara, QSV on Linux is basically a wrapper around libva that adds a whole new lot of problems, and needs a patched system, kernel, libs, ...
[16:06:56 CET] <popara> because on windows machine iw as able to transcode 3 Streams into hevc, without much pain and they were HD. On CPU for 3 streams with this quality i need a monster
[16:07:04 CET] <kerio> oh you want to do hevc
[16:07:06 CET] <BtbN> On Windows QSV is fine, as there is no vaapi
[16:07:11 CET] <BtbN> But on Linux, I don't see the point
[16:07:14 CET] <kerio> yeah, you need hardware acceleration
[16:07:38 CET] <BtbN> Also, MSS2007R2 sounds a bit old? Probably doesn't support KBL?
[16:07:46 CET] <popara> worry i meant 2017
[16:07:52 CET] <BtbN> But yeah, just use vaapi instead.
[16:07:56 CET] <popara> i'm using the latest
[16:08:04 CET] <BtbN> not sure if there is a hevc encoder in ffmpeg though
[16:08:13 CET] <popara> so with vaapi i dont have any drawback?
[16:08:18 CET] <BtbN> Less pain
[16:08:31 CET] <BtbN> It's using the exact same hardware anyway
[16:09:15 CET] <popara> with nvidia encoding on linux, i did it in 5 minutes, qsv :@
[16:09:33 CET] <jkqxz> The VAAPI H.265 encoder is there in ffmpeg.  Quality in the Intel driver sucks epically, though; I don't know if QSV is any better, it might be (never really used H.265 there).
[16:10:08 CET] <kepstin> vaapi and qsv use the same underlying hardware encoder isp, so quality should be identical assuming you manage to match the configuration
[16:10:22 CET] <jkqxz> If you care more about performance than quality it's fine, though.  Easily does 4K60 H.265.
[16:10:30 CET] <popara> And yo compile with vaapi, i just need 1 library and it's done?
[16:10:33 CET] <popara> no pain with kernels with etc
[16:10:46 CET] <BtbN> yes, vaapi works on vanilla libraries and kernel.
[16:10:57 CET] <kepstin> popara: you need a recent enough kernel etc. to make sure it actually supports kaby lake, of course, but other than that yeah
[16:11:07 CET] <BtbN> QSV is a load of bullshit added on top. Even on Windows, but lacks an alternative there.
[16:11:41 CET] <popara> who made qsv documentation first of all seriously has a problem. Half of the steps are missing like they are obvious, but they are not
[16:11:48 CET] <popara> whoever*
[16:11:49 CET] <BtbN> Intel
[16:11:58 CET] <BtbN> Or which documentation do you mean?
[16:12:08 CET] <popara> the official pdf documentation that comes with the MSS
[16:12:19 CET] <BtbN> Yeah, Intel.
[16:12:48 CET] <BtbN> The (software) quality of everything coming out of intel has decreased a lot in recent times
[16:13:13 CET] <popara> and , can the vaapi be compiled statistically?
[16:15:08 CET] <kerio> *statically
[16:15:33 CET] <jkqxz> No.  Like libmfx, it only supports loading it dynamically.
[16:16:50 CET] <jkqxz> (And all the other hardware driver stuff, for that matter.  Stupid licence issues.)
[16:17:58 CET] <kepstin> well, the main reason for vaapi being dynamic is so that it can load drivers for multiple hardware vendors installed at runtime
[16:18:17 CET] <kepstin> I don't think there's actually any license issues stopping libvaapi and the intel driver being statically linked?
[16:18:25 CET] <kepstin> just technical ones :)
[16:19:10 CET] <popara> but i cant compile ffmpeg statically and then move the binary to another machine + install the drivers on that?
[16:19:17 CET] <popara> it will work in this case?
[16:20:36 CET] <kepstin> if you have a static version of libva available to link to, that would probably work
[16:20:38 CET] <jkqxz> While the Intel driver is outwardly open-source, in recent versions it contains compiled binaries without source so you can't distribute it linked it directly to GPL code.  (You would be required to provide full the editable source, which you don't have.)
[16:21:48 CET] <jkqxz> If there is no GPL or similar involved then it's ok.
[16:22:24 CET] <popara> ok anyway i will with vaapi and we will see. I lost 10 days of my life trying to make qsv to work
[16:22:27 CET] <popara> :P
[16:23:20 CET] <jkqxz> Linking libva statically and then having the driver installed on all the machines you use is about the best you can do, and should work.
[16:23:46 CET] <popara> ok i will try it, thanks guys. One last question. Vaapi is for intel gpus only?
[16:24:30 CET] <kepstin> the "vaapi" api is designed to be hardware-agnostic. I think there's some stuff for radeon gpus available, and maybe an adapter driver that lets it be used on nvidia?
[16:24:33 CET] <jkqxz> You can use it on AMD with Mesa.  It's not very good there, but does work somewhat.
[16:24:52 CET] <jkqxz> Well, it's fine for decode, encode is a mess.
[16:44:12 CET] <fartymonk> Hello :) can anyone help me with compiling ffmpeg for android in ubuntu16.10 x64?
[16:47:40 CET] <fartymonk> I've followed the ffmpeg wiki links and tried the writingminds/ffmpeg-android and the roman10 guide to no success.
[17:28:55 CET] <serb> hy guys im looking for help concerning framerates in videos
[17:29:18 CET] <serb> i wanna make ton sof videos that are 60 fps but actually use source files that vary from 25-30 [most of the time but not 100%] to 60 fps [like 1% of the case]
[17:29:44 CET] <serb> i wanna make all of them 60fps cuz wen i speed up or slow down the vids the speed transitition appears smoother @ 60fps rather than 30
[17:29:57 CET] <serb> however those tings are like 2% of the vid
[17:30:09 CET] <serb> besides that the rest of the vid is a 60fps vid with a 30fps vid as srouce
[17:30:15 CET] <serb> Does that affect the File Size of The Vid ?
[17:30:30 CET] <serb> And are there any ways of making such Discrepencies Seem Less Obvious ?
[17:34:26 CET] <Diag> uhh
[17:34:34 CET] <Diag> the speed shouldnt appear smoother?
[17:34:40 CET] <Diag> I dont think ffmpeg does like
[17:34:43 CET] <Diag> tweening does it?
[17:38:40 CET] <kepstin> if you just change the framerate in the obvious way (fps filter or -r output option), you'll get duplicated frames and judder, yeah.
[17:38:50 CET] <kepstin> with very recent ffmpeg versions, you have https://www.ffmpeg.org/ffmpeg-filters.html#minterpolate
[17:39:03 CET] <kepstin> which can interpolate frames, but probably will give you odd motion artifacts
[17:39:10 CET] <kepstin> works nice on pans, anyways :/
[17:42:44 CET] <serb> not pans.
[17:43:33 CET] <serb> Some context: doin vids in sony vegas. source videos are 25-30 fps and i wanna export em as 60 FPS.
[17:53:09 CET] <kerio> by duplicating?
[17:54:47 CET] <serb> Wat do u mean?
[17:55:00 CET] <serb> sony vegas has project settings an i set em to "60 fps"
[17:57:38 CET] <furq> that probably duplicates frames the same way as ffmpeg would
[17:58:05 CET] <serb> Wat is frame duplication?
[17:58:17 CET] <furq> if you want it to seem smoother then you'll have to reencode everything <60fps with minterpolate or one of avisynth/vapoursynth's motion interpolation filters
[17:58:36 CET] <furq> if you have a 30fps video and you convert it to 60fps then it'll just duplicate every frame
[17:58:42 CET] <serb> i dont want it to seem smoother
[17:58:43 CET] <serb> jst us
[17:58:44 CET] <serb> uh
[17:58:48 CET] <serb> pans & "flash" effect
[17:58:58 CET] <serb> to be smoother
[17:59:15 CET] <serb> and really short speedup/down transitions to seem Smoote
[17:59:21 CET] <serb> thx
[17:59:36 CET] <serb> i tink sony vegas has interpolation built in tho
[17:59:42 CET] <furq> converting 25 to 60 is messier because then you'll get some frames duplicated once and some duplicated twice
[17:59:55 CET] <furq> so that'll be more visibly jerky
[18:01:35 CET] <serb> Diag: Nice Nick.
[18:02:02 CET] <Diag> thanks
[18:02:10 CET] <Diag> serb: i was doing it for another channel though
[18:02:49 CET] <Franciman> Hi
[18:03:04 CET] <Franciman> What's the difference between AVFrame.pts and AVFrame.best_effort_timestamp?
[18:03:12 CET] <Franciman> apart from the fact that pts is in time_base units
[18:12:48 CET] <vans163> anyone know a good read/intro on shaders?
[18:13:07 CET] <vans163> https://github.com/moonlight-stream/moonlight-chrome/blob/master/viddec.cpp#L25 this is all looking quite arcane rihgt now
[18:21:31 CET] <rebel2234> anybody in here that can help me with some command line options of ffmpeg? I've got something that works but not sure if options are placed correctly and such.
[18:22:46 CET] <rebel2234> Here is my line: pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v528 -vcodec libx264 -trellis 2 -bf 2 -preset ultrafast -movflags +faststart -vf scale=1280:720 -vb 2600k -acodec aac -ab 128K -strict -2 -mbd rd -copyinkf -flags +ilme+ildct -fflags +genpts -f mpegts -tune zerolatency pipe:1
[18:24:12 CET] <kerio> Diag: did you actually group DonaldTrump
[18:24:29 CET] <kerio> you did, nice
[18:24:46 CET] <rebel2234> this is for Tvheadend and transcoding.  My goal is to have something that can be played on wide variety of players (android STB's, computers, mobile, etc).  Ultrafast is fine for me as I have 9 hdhomerun prime tuners and my i7-3770 can do about 7 of these streams before choking.
[18:26:26 CET] <rebel2234> any additions/subtractions from my command line somebody can recommend?
[18:27:07 CET] <kerio> do you really need -tune zerolatency
[18:27:56 CET] <bencoh> -movflags probably has no meaning with mpegts
[18:28:06 CET] <bencoh> (unless I missed something about the way mpeg-ts works)
[18:28:16 CET] <rebel2234> not really sure? just kinda hodge podged stuff together that I found on internet.
[18:28:24 CET] <BtbN> most of the flags are useless or bad.
[18:28:27 CET] <kerio> lmao
[18:28:35 CET] <bencoh> you probably want to replace -vb/-ab respectively with -b:v/-b:a
[18:28:47 CET] <BtbN> and if the -strict -2 is still needed, you should update your copy of ffmpeg
[18:28:53 CET] <kerio> -preset ultrafast is appreciably worse than -preset veryfast
[18:29:06 CET] <BtbN> the zerolatency tune is bad
[18:29:09 CET] <kerio> -tune zerolatency will enable slice-based threading
[18:29:32 CET] <BtbN> and you are signaling interlaced encoding for some reason
[18:29:35 CET] <kerio> i doubt the extra 3 frames of latency will be impactful for you
[18:29:37 CET] <rebel2234> I am shooting for 7 concurrent streams with my current hardware
[18:29:39 CET] <Diag> kerio: :)
[18:29:49 CET] <bencoh> kerio: and intra-refresh, iirc ... which is even more important here :p
[18:29:51 CET] <Diag> i got it months ago
[18:29:57 CET] <Diag> like
[18:30:01 CET] <kerio> does -tune zerolatency actually use intra-refresh
[18:30:10 CET] <Diag> 6 or so months ago i think
[18:31:26 CET] <bencoh> kerio: oh, maybe not, you still might need to add it actually. haven't played with those for quite some time
[18:32:04 CET] <bencoh> (zerolatency without intra-refresh never made much sense to me though)
[18:34:57 CET] <rebel2234> so something like this? pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v528 -vcodec libx264 -trellis 2 -bf 2 -preset ultrafast -movflags +faststart -vf scale=-1:720 -b:v 2600k -acodec aac -b:a 128K -mbd rd -copyinkf -flags +ilme+ildct -fflags +genpts -f mpegts pipe:1
[18:35:38 CET] <bencoh> drop -movflags +faststart ; and you can probably drop most of the other flags you're specifying unless you understand those :)
[18:36:36 CET] <rebel2234> I would like the output deinterlaced if possible, but it is my understanding that this uses alot of cpu.
[18:38:53 CET] <rebel2234> So this is what I have so far: pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v528 -vcodec libx264 -trellis 2 -bf 2 -preset ultrafast -vf scale=-1:720 -b:v 2600k -acodec aac -b:a 128K -mbd rd -copyinkf -flags +ilme+ildct -fflags +genpts -f mpegts pipe:1
[18:39:19 CET] <rebel2234> are you saying I should drop everything after -flags and -fflags ?
[18:52:14 CET] <rebel2234> lol @ name changes Diag
[18:52:23 CET] <Diag> you just dont look at that
[18:52:31 CET] <Diag> rebel2234: they cut off my weiner so i had to do something else
[18:52:45 CET] <rebel2234> :-)
[18:53:15 CET] <Diag> I DID group that though
[18:53:17 CET] <Diag> :)))))))))))))
[18:53:29 CET] <Diag> i have all the good nicks
[18:54:06 CET] <kerio> rebel2234: do you really need adaptive cbr
[18:54:25 CET] <Diag> "adaptive cbr"
[18:54:27 CET] <Diag> what
[18:54:32 CET] <furq> abr
[18:54:37 CET] <furq> rebel2234: why do you need this to be interlaced
[18:54:54 CET] <rebel2234> i dont want it interlaced
[18:55:13 CET] <furq> oh, you said deinterlaced
[18:55:19 CET] <furq> well yeah you can get rid of most of those options
[18:56:02 CET] <rebel2234> this is what I have got now.  any other recommendations changed to superfast. pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v528 -vcodec libx264 -trellis 2 -bf 2 -preset superfast -vf scale=-1:720 -b:v 2600k -acodec aac -b:a 128K -mbd rd -copyinkf -f mpegts pipe:1
[18:56:23 CET] <furq> get rid of -trellis 2, -bf 2 and -mbd rd
[18:56:47 CET] <furq> and if you want the output deinterlaced then -vf yadif=1:scale=-2:720
[18:56:52 CET] <furq> er
[18:56:59 CET] <furq> -vf yadif=1,scale=-2:720
[18:57:32 CET] <Diag> furq: whens ffmpeg adding support for vce
[18:57:34 CET] <furq> if that's too slow then use yadif=0 instead
[18:57:40 CET] <furq> Diag: when you submit a patch
[18:57:47 CET] <Diag> lol
[18:58:22 CET] <Diag> someone should reach out to amd
[18:58:23 CET] <furq> rebel2234: you probably don't need copyinkf either but it probably doesn't hurt
[18:58:32 CET] <furq> probably
[19:00:26 CET] <furq> why is the internet archive porting vlc to javascript instead of a good player
[19:13:58 CET] <DHE> the trend online is to let the browser play videos natively. see also HLS.js
[19:14:09 CET] <DHE> a trend I'm against, but that's another story
[19:14:25 CET] <DHE> or are they doing something really crazy like node.js ?
[19:15:58 CET] <Diag> DHE: why are you against native codec support in browsers
[19:16:10 CET] <kepstin> I think it's possible to get bits of ffmpeg into the browser via emscripten, would be possible to make a player based on that :/
[19:16:14 CET] <Diag> you some kind of commie
[19:16:31 CET] <kepstin> but using native codecs when available will certainly be faster/more power efficient in most cases
[19:16:36 CET] <DHE> because then there's no resistance whatsoever to things like full h264 video being played at any time for things like ads or just general nuisance
[19:16:50 CET] <DHE> it'd be like 1998 all over again except with .mp4 instead of MIDI
[19:16:53 CET] <Diag> adblock :DDDDDDDDDDDD
[19:18:03 CET] <kerio> bretty gud :DD
[19:19:15 CET] <furq> i'm not complaining about the javascript bit
[19:19:21 CET] <furq> that decision has been made for us
[19:19:32 CET] <furq> but why would they port vlc instead of mpv
[19:19:48 CET] <DHE> I have no idea why javascript took off as much as it did. I thought the industry learned its lesson that running arbitrary code from an otherwise unknown third party was a bad idea
[19:20:13 CET] <furq> all the best languages were made in 10 days and then didn't break the api for 20 years
[19:21:45 CET] <DHE> wow, geniuses must have written them
[19:22:43 CET] <kerio> "best"
[19:23:14 CET] <furq> oh no are you challenging my extremely sincere opinion
[19:24:25 CET] <kerio> YES >:C
[19:26:36 CET] <DHE> I would NEVER *EVER* do such a thing
[19:28:33 CET] <furq> 18:16:36 ( DHE) because then there's no resistance whatsoever to things like full h264 video being played at any time for things like ads or just general nuisance
[19:28:38 CET] <furq> aren't we already well past this point
[19:29:15 CET] <DHE> possibly. firefox lets you disable codecs and containers supported. so I hit all of them
[19:29:22 CET] <Diag> booo
[19:29:35 CET] <Diag> use fucking adblock
[19:29:48 CET] <furq> my favourite one was that google AMP landing page, which is a webpage promoting a technology that reduces bloat from webpages, which played a 3.4MB carousel video in the background and also redownloaded it from the server every time it finished
[19:29:59 CET] <Diag> lol
[19:30:04 CET] <furq> i've seen that shit multiple times too
[19:30:06 CET] <DHE> umm, as they say in the know, "whitelists suck"
[19:30:11 CET] <Diag> ?
[19:30:16 CET] <DHE> which is right under "blacklists suck"
[19:30:22 CET] <Diag> i get zero ads bub
[19:30:30 CET] <furq> sadblock
[19:30:35 CET] <furq> use ublock
[19:30:38 CET] <DHE> no javascript, no ads
[19:30:40 CET] <Diag> thats what i got
[19:30:55 CET] <Diag>  on this page û "
[19:30:55 CET] <Diag> 10 or 4%
[19:30:55 CET] <Diag>  since install
[19:30:55 CET] <Diag> 43,011 or 10%
[19:31:09 CET] <Diag> its good shit fam
[19:31:29 CET] <furq> 998,981 or 10%
[19:31:30 CET] <furq> neat
[19:31:45 CET] <furq> i'll have to make a note of which site takes it over one million
[19:31:50 CET] <Diag> lol
[19:31:56 CET] <Diag> it happens fasy
[19:32:14 CET] <Diag> you get anywhere from 10 to ~200 a page
[20:00:45 CET] <Kirito> Are there any good practical considerations to take in when working with images (frames) or videos that have been (poorly) upscaled? i.e. what would be the best way to downscale such content back to their original dimensions with as little loss in quality as possible?
[20:01:16 CET] <Diag> not doing it lol
[20:01:30 CET] <Diag> Photoshops bicubic sharpener works pretty decently i guess
[20:02:15 CET] <Kirito> Yeah, I was thinking something like that. I did a few experiments using Photoshop's bicupic sharpener on some poorly upscaled images, and it seemed to produce good results
[20:02:16 CET] <kepstin> I'd expect even ffmpeg's default bicubic would give reasonable results assuming you get the original size correct.
[20:02:36 CET] <kepstin> if the video has combing artifacts, you're basically out of luck tho
[20:03:19 CET] <furq> i'm pretty sure avisynth or vapoursynth has an unresize plugin
[20:03:54 CET] <Plorkyeran_> http://avisynth.nl/index.php/Debilinear can do a very good job of reversing a bilinear upscale
[20:04:42 CET] <furq> https://github.com/sekrit-twc/vsunresize
[20:13:11 CET] <Kirito> Thanks for the information / links!
[20:39:06 CET] <kittyfoots> i'm using libavcodec to decode some h.264 video and I'm noticing that it's returning frames in decode order.  Is there a way of having it return frames in presentation order instead or am I going to have to manually sort the frames?
[20:41:03 CET] <JEEB> I'm pretty sure the decoded frames are in presentation order
[20:41:14 CET] <JEEB> demuxed ones are in DTS order of course
[20:44:00 CET] <kittyfoots> I'm dealing with basically a raw bitstream and I'm feeding them in dts order, but the pts and dts values i'm seeing come off the decoder suggest the frames are still in decode order
[20:46:21 CET] <jkqxz> Is max_num_reorder_frames set correctly in the stream?
[20:47:32 CET] <kittyfoots> is that something I need to set manually? I thought it would have been filled by the SPS.  I'm not currently setting it at all.
[20:49:08 CET] <jkqxz> I mean actually in your stream - it's part of the SPS.   It is the main thing which controls how much delay should be applied for reordering.
[20:51:31 CET] <kittyfoots> I'll have to dig through the SPS a bit, I'm using OBS to generate a stream.  I think it uses x264 for encoding so I would think that the SPS is being correctly generated.
[20:53:07 CET] <jkqxz> Yeah, probably fine if it's x264.  Can you tell how much delay is actually being applied?  (That is, after you give it the packet with pts=X, how many more packets do you need to give it before the frame with pts=X comes out?)
[20:54:32 CET] <jkqxz> If that is zero, then something is making lavc believe that the frame doesn't have any reordering, and then the result is understandable.  If it is big enough that all reordering should be taken care of, then dunno, something else funny is going on.
[21:00:05 CET] <kittyfoots> ok, so it looks like it's delayed by 2 frames and the codec context's has_b_frames value is 2, so that seems correct
[21:00:13 CET] <kittyfoots> i wonder why the pts is still in the wrong order though.
[21:06:00 CET] <kittyfoots> here's a sample of the pts/dts values (converted to seconds) http://pastebin.com/B93QhKWm
[21:08:01 CET] <kittyfoots> strangely the pts and dts values don't match after the decode, and some pts values (look at 2.1) are delayed by 4 frames.
[21:08:46 CET] <jkqxz> That has more than two frames of reordering in.
[21:08:54 CET] <kittyfoots> seems to yeah.
[21:09:03 CET] <jkqxz> If only two frames of delay is being applied, that's not enough.
[21:09:54 CET] <jkqxz> I still suspect max_num_reorder_frames...
[21:11:08 CET] <jkqxz> Can you share some of the stream?
[21:11:52 CET] <kittyfoots> yeah give me a minute to record it.  I'm also going to see what ffprobe says about it.
[21:15:19 CET] <kittyfoots> here's a short mp4 recorded from obs: https://drive.google.com/file/d/0BwJX4ibMS46PNDgwSi0tYzRqWm8/view?usp=sharing
[21:17:40 CET] <jkqxz> "@155   VUI: num_reorder_frames                                     011 (  2)"
[21:19:50 CET] <jkqxz> And now that I read up to be able to talk about this more precisely I realise that I was actually thinking of max_dec_pic_buffering, not max_num_reorder_frames.
[21:19:57 CET] <jkqxz> "@158   VUI: max_dec_frame_buffering                              00101 (  4)"
[21:20:38 CET] <jkqxz> Which looks right, because the stream is a simple B-pyramid with depth 2.
[21:21:47 CET] <kittyfoots> which seems to match the 4-frame delay seen in the earlier log.  Now how do I get ffmpeg to behave here, or should I just dig into the vui manually and order the frames outside the decoder?
[21:22:37 CET] <kittyfoots> what tool are you using for that, by the way. I used to have a really great one for digging through h.264 bitstreams but I can't recall what it's called for the life of me
[21:23:06 CET] <jkqxz> That's just the H.264 reference decoder.  It can produce full bitstream traces.
[21:23:23 CET] <kittyfoots> ah thanks.
[21:30:54 CET] <kittyfoots> hm, so it looks like ffmpeg is correctly using num_reorder_frames+1 as the buffer size ( i see 3 frames go in and 1 come out at the beginning )..why are these pts values so far out?
[21:37:05 CET] <jkqxz> Are the pts values on the packets actually correct?
[21:39:14 CET] <kittyfoots> hm, should be.  It's an rtmp stream so the pts values have to be generated from dts+cts basically.
[22:26:02 CET] <rebel2234> Thank You! All that helped! This is working fine! pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v582 -vcodec libx264 -preset superfast -vf yadif=0,scale=-2:720 -b:v 2600k -acodec aac -b:a 128K -copyinkf -f mpegts pipe:1
[22:26:24 CET] <rebel2234> Now I just need an 8 core i7
[22:26:28 CET] <rebel2234> :-)
[22:29:39 CET] <furq> rebel2234: the 3770 has quicksync, you could try that
[22:36:15 CET] <rebel2234> furq: Tried the quicksync and VAAPI and just not enougph compression and weird things happened after 3x streams.
[22:40:40 CET] <kerio> what's the point of copyinkf?
[22:41:28 CET] <rebel2234> not sure what it even does myself
[22:41:31 CET] <rebel2234> do you know?
[22:41:57 CET] <kerio> why is it in your commandline
[22:45:03 CET] <furq> it copies frames before the first keyframe
[22:45:13 CET] <kerio> furq: but we're reencoding
[22:45:26 CET] <furq> oh yeah
[22:45:30 CET] <furq> i guess it's completely pointless then
[22:46:35 CET] <rebel2234> is it hurting anything by having it in there? like cpu?
[22:47:05 CET] <kerio> i'm still not convinced about the ABR video
[22:47:09 CET] <kerio> if it's something to be used locally
[22:47:44 CET] <rebel2234> the video is getting transported over a routed networks sometimes a few hops away
[22:48:19 CET] <furq> if you have a hard bandwidth limit then abr isn't going to do you any good
[22:48:31 CET] <furq> crf and maxrate is probably a better idea
[22:48:49 CET] <rebel2234> furq: what would that look like in command line?
[22:56:44 CET] <rebel2234> so something like this: pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v524 -vcodec libx264 -preset superfast -crf 26 -maxrate 2600k -vf yadif=0,scale=-2:720 -acodec aac -b:a 128K -f mpegts pipe:1
[22:58:12 CET] <rebel2234> would adding any kind of buffer be benificial?
[23:04:37 CET] <kittyfoots> thanks for your help, by the way, jkqxz.  Seems like if i just use DTS and disregard the pts value I don't really have any downstream issues.
[23:06:20 CET] <kepstin> rebel2234: I think you need to use both -maxrate and -bufsize together to enable the VBV management in x264
[23:28:50 CET] <rebel2234> Thank You kepstin! That really cut down on BW pipe:///usr/bin/ffmpeg -loglevel fatal -i http://10.7.7.100:5004/auto/v524 -vcodec libx264 -preset superfast -crf 28 -maxrate 2600k -bufsize 3500k -vf yadif=0,scale=-2:720 -acodec aac -b:a 128K -f mpegts pipe:1
[23:29:43 CET] <rebel2234> And i got rid of the -copyinkf, Thanks kerio and furq
[00:00:00 CET] --- Fri Feb  3 2017