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

[burek]

[01:08:26 CET] <kingsley> When a GPU driver crashes, does gdb's "bt" command have lines for the program calling it, like ffmpeg or melt?
[01:08:41 CET] <kingsley> Case in point:
[01:09:12 CET] <kingsley> "melt" is absent from the gdb backtrace at
[01:09:16 CET] <kingsley> https://paste.debian.net/996175/
[01:10:02 CET] <kingsley> I suppose a bug may also corrupted the stack.
[01:25:34 CET] <jkqxz> You might want to look at other threads?  That's hit the heap corruption detector in glibc in a thread which is just exiting.
[06:25:38 CET] <mhd4mr> What's FFMPEG Twitter account?
[06:59:38 CET] <systemd0wn> Question: What's the right way to detect a command failure? I ran ffmpeg copying an HLS stream to local disk. I disconnected the network, I see many failed to open segment errors, then the cmd exits. However, it exited 0.
[09:31:45 CET] <kingsley> jkqxz: I'm back.
[09:34:22 CET] <kingsley> I'm intrigued and impressed that you guessed the process whose stack trace is in the pastebin hit a heap corruption detector.
[09:34:39 CET] <kingsley> Coincidentally, the crashing program also reports...
[09:34:54 CET] <kingsley> *** Error in `/usr/bin/melt': double free or corruption (fasttop): 0x80271510 ***
[09:35:20 CET] <kingsley> Question 1.) How did you know it hit a heap corruption detector?
[09:35:51 CET] <kingsley> Question 2.) How did you know it's in glibc?
[09:37:03 CET] <kingsley> Hmmm...
[09:37:26 CET] <kingsley> I seem to have answered my own first question.
[09:38:17 CET] <kingsley> Line 7 in the pastebin says...
[09:38:22 CET] <kingsley> malloc_printerr (action=<optimized out>, str=0xb7ece35c "double free or corruption (fasttop)", ptr=<optimized out>, ar_ptr=0xb7f20780 <main_arena>) at malloc.c:5049
[10:54:16 CET] <dreamy> Hi, how can I set start_pts with ffmpeg? I tried setpts filter but I couldn't change it.
[11:36:15 CET] <dreamy> how can I set start_pts with ffmpeg? I tried setpts filter but I couldn't change it.
[11:53:46 CET] <Alaggard> Hi there!
[11:55:23 CET] <Alaggard> I've got an error during the compilation of ffmpeg enabling libmp3lame. It says that I need version >= 3.98.3. I'm using CentOS 6.8 and my lame versions are 3.100. Can someone give me some help? Thanks in advice
[11:58:05 CET] <Alaggard> I've followed the guide to compile and install ffmpeg for centos from the trac site
[12:03:49 CET] <furq> Alaggard: check config.log
[12:04:06 CET] <furq> the actual error will be somewhere near the end
[12:05:50 CET] <Alaggard> the last line says: ERROR: libmp3lame >= 3.98.3 not found
[12:05:57 CET] <Alaggard> anything else after that
[12:06:27 CET] <Alaggard> and the line before that is "collect2: ld returned 1 exit status"
[12:06:50 CET] <furq> pastebin the last 100 lines or so
[12:08:15 CET] <Alaggard> https://pastebin.com/KEMGtAte here it is, last 200 lines
[12:13:09 CET] <sfan5> that's a linking problem with libmp3lame
[12:14:16 CET] <sfan5> might be static build of libmp3lame
[12:15:27 CET] <Alaggard> can you guide me on how to solve this?
[12:18:11 CET] <sfan5> you installed libmp3lame from the repos right?
[12:18:18 CET] <Alaggard> yes
[12:18:43 CET] <Alaggard> https://pastebin.com/SWZkGJL9
[12:18:46 CET] <Alaggard> all the versions
[12:20:31 CET] <sfan5> twolame is not actually needed for mp3 but that looks correct
[12:20:46 CET] <sfan5> output of readelf -d /usr/lib/libmp3lame.so | grep NEEDED?
[12:21:07 CET] <Alaggard> readelf: Error: '/usr/lib/libmp3lame.so': No such file
[12:21:29 CET] <Alaggard> here could be the problem
[12:22:50 CET] <sfan5> ah should've read your log
[12:23:22 CET] <sfan5> Alaggard: ffmpeg is trying to use the static libmp3lame from /root/ffmpeg_build/lib/ which causes problem because that's just how static libs are
[12:24:07 CET] <sfan5> i assume this was part of the guide you mentioned and you can probably fix it by passing --extra-libs="-lm" to configure
[12:28:11 CET] <Alaggard> yeeah dude!! with this extra-libs was compiled! Thank you so much!!!
[12:30:28 CET] <zhhcxs> is there faster codec to h264???
[12:31:37 CET] <zhhcxs> who are here
[12:32:36 CET] <sfan5> a faster encoder?
[12:33:10 CET] <ritsuka> faster than what?
[12:34:18 CET] <zhhcxs> when i sace stream rtsp h264with ffmpeg i got lot of miss packages
[12:34:35 CET] <zhhcxs> then the decoder not working well
[12:34:43 CET] <sfan5> sounds like a network problem
[12:35:00 CET] <zhhcxs> i want to save stream to disk via udp but without copy
[12:35:41 CET] <sfan5> ffmpeg -i udp://whatever -c copy -y output.mkv
[12:35:47 CET] <zhhcxs> no... i can do the same action with liv 55 without any problem
[12:36:15 CET] <furq> zhhcxs: pastebin your full command
[12:36:58 CET] <zhhcxs> ffmpeg -i rtsp://x.x.x.x file.h264
[12:37:24 CET] <sfan5> like i said add -c copy in the middle
[12:37:25 CET] <furq> firstly, you definitely don't want an h264 ES
[12:37:35 CET] <furq> and also you can just use a faster preset
[12:37:44 CET] <furq> -preset superfast file.mkv
[12:38:22 CET] <furq> although yeah i don't see why you wouldn't just copy it
[12:38:22 CET] <zhhcxs> i dont want use copy because i mybe want to overlay
[12:38:30 CET] <furq> never mind then
[12:38:45 CET] <sfan5> just use a faster preset then
[12:38:56 CET] <furq> also you probably want -c:a copy to copy the audio stream (if there is one)
[12:39:02 CET] <zhhcxs> live55 use same codec??
[12:39:19 CET] <zhhcxs> why i dont want h264 file??
[12:39:30 CET] <furq> h264 is an h264 elementary stream
[12:39:42 CET] <zhhcxs> i want to stream it on rtsp after that
[12:40:02 CET] <furq> probably use mpegts then
[12:40:16 CET] <furq> -c:v libx264 -c:a copy -preset superfast out.ts
[12:40:40 CET] <zhhcxs> i xont want copy i want to overlay so coy not help
[12:40:54 CET] <sfan5> you're only copying the audio with the above command
[12:40:56 CET] <furq> that copies the audio stream, not the video stream
[12:41:14 CET] <zhhcxs> i dont neet the audio
[12:41:21 CET] <sfan5> then you can use -an
[12:41:23 CET] <zhhcxs> why save to ts file??
[12:43:38 CET] <zhhcxs> can you tell me please how can i stream via rtsp over http??
[12:44:31 CET] <zhhcxs> https://stackoverflow.com/questions/47348336/ffmpeg-rtsp-over-http-not-working
[12:45:35 CET] <sfan5> isn't ffserver deprecated?
[12:46:22 CET] <zhhcxs> why deprecated??
[12:46:56 CET] <JEEB> because nobody wants to maintain it and it's never been generally adopted
[12:47:29 CET] <zhhcxs> i use ffserver to stream mjpeg and rtsp ocer tcp&udp to many clients
[12:48:01 CET] <zhhcxs> so how can i stream mjpeg to many clients??
[12:48:38 CET] <zhhcxs> this is only server that get feed from ffmpeg
[12:54:11 CET] <zhhcxs> @JEEB how do you stram via ffmpeg to some clients on mjpeg for ex.?
[12:58:39 CET] <durandal_1707> you dont, you get back to cave
[13:00:27 CET] <zhhcxs> what???
[13:02:59 CET] <JEEB> I'm really sorry about durandal_1707, he's had a traumatic past
[13:04:01 CET] <durandal_1707> yes, with caves and bears
[13:05:06 CET] <zhhcxs> jeeb can you help me please???
[13:05:42 CET] <durandal_1707> can nginx be used?
[13:06:29 CET] <JEEB> zhhcxs: I have a $dayjob, so no
[13:06:50 CET] <zhhcxs> oh i got you
[13:07:11 CET] <zhhcxs> can i send you mail and you wil answer on night please??
[13:07:38 CET] <JEEB> no
[13:08:19 CET] <zhhcxs> thank friend
[13:09:19 CET] <zhhcxs> who can help me on streaming??
[13:36:38 CET] <Alaggard> Huh... I want to shot myself. On make process I've got "cc1: error: unrecognized command line option "-Wmaybe-uninitialized"" any solution?
[13:37:00 CET] <sfan5> gcc too old
[13:37:14 CET] <Alaggard> gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC)
[13:37:29 CET] <Alaggard> just updated Developer Tools
[13:52:51 CET] <sfan5> Alaggard: GCC 4.4.7	March 13, 2012  ~https://gcc.gnu.org/releases.html
[13:53:42 CET] <sfan5> even if the repos don't provide it, you will need a newer gcc
[14:09:01 CET] <uhmmm> hi everyone. using ffmpeg 3.4 on a debian docker container to re-encode a web radio feed into AAC 64K
[14:09:06 CET] <Alaggard> sfan5 yup, I'm compiling 4.9, if not, I will go newer
[14:09:11 CET] <uhmmm> it should run 24/7
[14:09:30 CET] <uhmmm> it works for some time, but it eventually fails with "muxing overhead: unknown"
[14:10:08 CET] <sfan5> any log messages before / after that?
[14:10:15 CET] <uhmmm> I'm trying to work around this with a wrapper script but it would be nice to know what the problem is
[14:10:22 CET] <uhmmm> nothing particular in the logs
[14:10:25 CET] <uhmmm> the usual AAC stuff
[14:10:50 CET] <uhmmm> "opening for reading... opening for writing...", etc.
[14:11:12 CET] <sfan5> i suggest doing one run with -report
[14:11:17 CET] <sfan5> that should produce a finer logfile
[14:11:27 CET] <uhmmm> I will, thank you
[15:59:44 CET] <niwreg> Hi
[15:59:57 CET] <niwreg> i´m running into some problems while compiling ffmpeg
[16:00:58 CET] <niwreg> i´m following this guide https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[16:01:34 CET] <niwreg> and then i run into: cc1: some warnings being treated as errors ffbuild/common.mak:60: recipe for target 'libavcodec/h264_cavlc.o' failed make: *** [libavcodec/h264_cavlc.o] Error 1
[16:02:15 CET] <niwreg> i tried static and shared builds
[16:02:45 CET] <niwreg> tried the apt-get install libx264-dev and build 264 myself as in the example
[16:02:49 CET] <niwreg> but still no luck
[16:03:14 CET] <JEEB> sounds like you have some leftovers from an older version
[16:03:26 CET] <JEEB> if you are OK with resetting the whole FFmpeg code dir, `git clean -dfx`
[16:03:43 CET] <niwreg> it was a fresh install of ubuntu but i can try that
[16:04:32 CET] <JEEB> the h264 decoder is internal, so if that fails something's wrong
[16:04:51 CET] <niwreg> https://pastebin.com/HdJNDkvk this is the complete error
[16:06:56 CET] <niwreg> maybe i shouldn't use the snapshot of ffmpeg?
[16:10:05 CET] <jkqxz> niwreg:  That looks like the file has been edited (truncated?).  Line 976 should be <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_cavlc.c#l976>.
[16:11:20 CET] <violetina> hi , i just built a ffmpeg version in docker with debian from git, ffprobe version n3.0.9-71-g94e538a Copyright (c) 2007-2017 the FFmpeg developers
[16:11:20 CET] <violetina> if i run ffprobe it not shows field_order=tt  on this version , my local gentoo ffprobe shows this for the same file, is this a known bug or did i miss something during the build?
[16:12:20 CET] <JEEB> 3.0 is pretty darn old
[16:12:29 CET] <JEEB> your local gentoo can have something much newer
[16:13:01 CET] <violetina> hmm maybe i need to change the build script , let me have a look  thanks pointing that out
[16:14:06 CET] <violetina>   git clone -b release/3.0 https://github.com/FFmpeg/FFmpeg.git ffmpeg
[16:14:06 CET] <violetina> seems to be in my script , not sure why i hardcoded that :x
[16:15:27 CET] <niwreg> jkqxz: i'm going to edit that back and let you know
[16:16:08 CET] <ntrrgc> How can I build ffmpeg? I cloned https://git.ffmpeg.org/ffmpeg.git and ran ./configure but it stalls forever
[16:18:30 CET] <jkqxz> ntrrgc:  Are you on Windows?  If so, wait longer.
[16:19:14 CET] <ntrrgc> jkqxz: I'm on Linux.
[16:19:38 CET] <ntrrgc> it just finished, several minutes later...
[16:19:40 CET] <jkqxz> It should finish in at most a minute or so.  Can you see from ps whether it's doing anything?
[16:19:59 CET] <jkqxz> Right.  Yeah, it's slow and provides no feedback while running.
[16:20:05 CET] <ntrrgc> :/
[16:20:09 CET] <furq> it really shouldn't be that slow on *nix
[16:20:21 CET] <furq> it normally takes less than 30 seconds here
[16:20:36 CET] <ntrrgc> That's still beyond my expectations for a configure script...
[16:20:43 CET] <jkqxz> Depends on the machine.  It takes a looong time on slow ARM SBCs.
[16:20:44 CET] <ntrrgc> I assumed it was broken.
[16:20:56 CET] <furq> as opposed to in msys where it takes longer than the actual compilation
[16:21:30 CET] <niwreg> alright replaced the file with the version from git
[16:21:36 CET] <niwreg> let's see if it builds
[16:22:37 CET] <ntrrgc> https://trac.ffmpeg.org/wiki/CompilationGuide/Centos so... in order to enable opus, the process is downloading a tarball with curl?
[16:23:06 CET] <ntrrgc> ah, no
[16:23:33 CET] <ntrrgc> Those are instructions for installing the library inside the prefix before building ffmpeg.
[16:23:59 CET] <furq> https://www.johnvansickle.com/ffmpeg/
[16:24:04 CET] <furq> you might just want to use those on centos
[16:25:26 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#libvmaf
[16:25:30 CET] <furq> neat, didn't know about that
[16:25:41 CET] <furq> (unrelated)
[16:29:57 CET] <niwreg> nice it passes trough the file :)
[16:35:43 CET] <ntrrgc> furq: thanks, but I'm not using CentOS but Fedora... and the reason I'm building from source is to report a bug.
[16:36:00 CET] <ntrrgc> So I need the latest revision from git.
[16:37:06 CET] <furq> the git build on there is the latest revision
[16:41:45 CET] <ntrrgc> oh, good to know for the next time.
[16:51:09 CET] <furq> it's not always but it is right now
[16:55:25 CET] <JEEB> sasasass/41
[16:56:22 CET] <niwreg> yes cloning the latest git works :)
[16:56:24 CET] <niwreg> thanx :)
[17:27:53 CET] <comwizz2> Hello, I was hoping to get a little help trying to decode some raw h264
[17:28:11 CET] <DHE> h264 elementary stream?
[17:29:42 CET] <comwizz2> I am receiving the sps and pp in a packet, then the raw frames. The problem is when I try to send the decoder the pps and sps it gives me an invalid parameter error
[17:34:48 CET] <Alaggard> Hi there
[17:35:06 CET] <Alaggard> sfan5 can't compile yet T_T
[17:35:41 CET] <Alaggard> i upgraded gcc to 5.2.0 and still giving the "check_cc -Wmaybe-uninitialized" error
[17:36:18 CET] <jkqxz> Just delete that line from configure?  It's only checking for a warning option.
[17:38:17 CET] <Alaggard> This is the output console log : https://pastebin.com/zeWa31GP  And this is the config.log latests lines https://pastebin.com/VXUcQjMT
[17:38:22 CET] <Alaggard> if can help
[17:38:31 CET] <Alaggard> I'm going to check the line from configure
[17:45:07 CET] <BtbN> comwizz2, the sps/pps is that's usually supplied as extradata
[17:45:11 CET] <BtbN> *what's
[17:46:21 CET] <comwizz2> I am sending avcodec_receive_packet(context, x0x0x0x1[sps]x0x0x0x1[pps]) And it is returning -22 invalid argument?
[17:47:11 CET] <comwizz2> I tried supplying it as extra data and that works at first. but the stream resends the config packet sometimes and if I release and rebuild the context with the new data the stream stops working
[17:49:09 CET] <comwizz2> I havent tried ignoring the resends, but sometimes the stream size changes, then rebuilding the context works correctly
[17:50:15 CET] <BtbN> No idea how random stream changes in the middle work
[17:50:22 CET] <BtbN> I suspect they need a full decoder re-init
[17:50:35 CET] <comwizz2> Yeah I do a reinint and the feed goes black
[17:50:57 CET] <comwizz2> unless the stream size changed then it works correctly with a reinit
[17:51:24 CET] <Alaggard> jkqxz I don't find anything
[17:51:24 CET] <comwizz2> But I dont know how to detect if it changes the size because I get the size from the decoder output right now.
[17:52:53 CET] <BtbN> changes the size?
[17:53:23 CET] <BtbN> If you mean the resolution, the new decoder should set it on the context, and on all frames it outputs
[17:54:21 CET] <comwizz2> Yes, I mean the resolution. I'm not setting the decoded resolution I'm getting it from the decoded frames.
[17:55:10 CET] <comwizz2> I dont actually know what it will be before then
[17:55:44 CET] <BtbN> If you initialize the decoder with proper extradata, it should come up with the resolution fields on the context properly populated
[17:57:25 CET] <comwizz2> Humm ok. I guess I can always initialize a new decoder, but if resolution hasn't changed, discard it.
[17:57:25 CET] <sfan5> Alaggard: googling seems to indicate that gcc 4.7 already supports that warning, maybe ffmpeg is not actually using the right gcc to compile stuff?
[17:58:05 CET] <BtbN> Or just use it?
[17:58:37 CET] <BtbN> you can also just straight up compare the extradata with memcmp, if it changes, you need a re-init
[18:01:28 CET] <comwizz2> If I use the new one the stream goes black, I was using the new one every time.
[18:01:41 CET] <BtbN> that makes no sense
[18:01:57 CET] <Ober> bjib
[18:02:20 CET] <BtbN> I suspect you are not properly spinning up a new decoder, or the stream is not meant to be split there, and you misunderstand something.
[18:02:24 CET] <BtbN> Where does it even come from?
[18:02:50 CET] <BtbN> a raw h264 stream, which randomly changes resolution in the middle, sounds very odd
[18:03:30 CET] <devinheitmueller> BtbN: Happens with broadcast television all the time.
[18:03:37 CET] <devinheitmueller> Well, not as much nowadays, but it used to.
[18:03:54 CET] <BtbN> you don't get a raw h264 stream from broadcast televison.
[18:04:06 CET] <devinheitmueller> At least in the US, it was very common for HD television channels to switch to standard definition during commericals.
[18:04:15 CET] <BtbN> It is common for TV channels to do that
[18:04:17 CET] <devinheitmueller> If by raw you mean an elementary stream, then true.
[18:04:24 CET] <BtbN> but they use a proper container that signals that kind of stuff
[18:04:42 CET] <raytiley_> anyone familiar with integrating the zerone windows builds into a visual C++ project. Everything builds and links  but get a runtime error about swr_alloc can't be located in avformat-58.dll
[18:04:51 CET] <devinheitmueller> Not necessarily.  If none of the underlying codecs change, the PMT wont differ at all.
[18:05:11 CET] <BtbN> raytiley_, that does not sound surprising, as the name suggests, the function is in swresample
[18:05:40 CET] <BtbN> mpeg-ts, which is frequently used there, has a discontinuity indicator
[18:06:07 CET] <devinheitmueller> You can have discontinuities without resolution changes, and you can have resolution changes without discontinuities.  :-)
[18:06:27 CET] <BtbN> you cannot have resolution changes without some kind of indication that a stream change happened.
[18:06:27 CET] <raytiley_> yeah, i'm just not sure why it's looking in that dll as apposed to the swresample-3.dll
[18:07:00 CET] <devinheitmueller> The change is indicated in the elementary stream via the NAL properties.
[18:07:07 CET] <BtbN> are you sure it's not avformat which is looking for that symbol, and it wants you to link to swresample?
[18:07:47 CET] <BtbN> It's in the extra data.
[18:08:03 CET] <BtbN> And as a decoder cannot usually change that mid-decode, you have a discontinuity there, which triggers a re-init
[18:08:07 CET] <raytiley_> I am not.
[18:08:22 CET] <comwizz2> Its a screen sharing stream
[18:08:32 CET] <raytiley_> It was my understanding that the `.lib` files load the dll they require.. I'm not sure how they releate to each other
[18:08:50 CET] <BtbN> .lib files can be static libs or shims that load DLLs
[18:09:00 CET] <devinheitmueller> BtbN: The MPEG-TS container doesnt do anything to indicate the resolution at all.  Sure you could potentially spot a discontinuity and do a resynchronize based on it, but that works out of dumb luck, not design.
[18:09:08 CET] <BtbN> If they are rather large, they are most likely static, in which case you have to link all the dependencies of them manually
[18:09:22 CET] <BtbN> devinheitmueller, it indeed doesn't. But it does indicate a stream discontinuity.
[18:09:32 CET] <BtbN> So you can reinit the decoder
[18:09:59 CET] <BtbN> That's not "dumb luck". That's exactly what that bit is there for.
[18:10:20 CET] <raytiley_> the avformat.lib is 140KB
[18:11:26 CET] <BtbN> that sounds like a dll loader
[18:11:38 CET] <BtbN> In which case the error doesn't really make a lot of sense
[18:12:00 CET] <alexpigment> i've never seen TV broadcasts switch resolution - at least on my cable. they DO, however, switch between 2.0 and 5.1 AC3 all the time, and that screws up my recorder every time :)
[18:12:18 CET] <BtbN> It's very common that commercials are in different resolutions
[18:12:21 CET] <alexpigment> (sorry, not really related to the heart of the combo. just chiming in)
[18:12:23 CET] <raytiley_> I guess i'm not sure if there is something up w/ the zeronae ffmpeg builds, or my project
[18:12:36 CET] <comwizz2> Ill have to come back with the error it gives me when the avcc header is resent but the resolution didn't change (which results in a black screen and no frames I believe)
[18:12:42 CET] <BtbN> I have even seen channels that send a movie in 1080i, and then send commercials as SD mpeg2
[18:12:45 CET] <alexpigment> BtbN - by the time it gets to my cable box, it's been converted into 1080i or whatever the station is
[18:12:52 CET] <BtbN> And happily change back and forth between the two
[18:13:00 CET] <alexpigment> that may just be a factor of having cable
[18:13:21 CET] <BtbN> As long as it's DVB with mpeg-ts on top, resolution changes are 100% possible and commonly used
[18:13:28 CET] <alexpigment> maybe on a raw satellite stream it's doing what you say, but I don't have direct experience
[18:13:47 CET] <BtbN> The transport medium for DVB doesn't really matter there. It's generally the same
[18:14:00 CET] <JEEB> i've seen plenty of local channels just splitting in adverts in a different PID
[18:14:05 CET] <devinheitmueller> alexpigment: Yeah, at least in the US, its much more common nowadays for the broadcaster or MSO to lock the stream to a specific resolution, to make it more seamless for TVs that take too long to swtich.
[18:14:06 CET] <JEEB> *PIDs
[18:14:07 CET] <alexpigment> right, but I'm telling you that it doesn't happen with my cable company (spectrum)
[18:14:21 CET] <JEEB> so you receive stuff and then you get a new PMT for the ads
[18:14:31 CET] <JEEB> which switches you to a completely different set of streams
[18:14:42 CET] <JEEB> and then after ads you switch back
[18:14:56 CET] <alexpigment> devinheitmueller: yeah, my cable box is set to auto-switch to a new resolution. that would be annoying as hell, if it went blank for a second between each commercial ;)
[18:15:04 CET] <BtbN> Probably cheaper, saves them a transcoder box
[18:15:12 CET] <JEEB> yea
[18:15:25 CET] <BtbN> The "cable box" outputs in a static resolution anyway, and would scale up/down internally
[18:15:45 CET] <alexpigment> BtbN: that's what the auto setting is for. it changes based on the native resolution of the stream
[18:16:00 CET] <alexpigment> which is why it goes to 480i on SD channels, 720p on some HD and 1080i on other HD channels
[18:16:06 CET] <BtbN> If you have a slow TV, that setting sounds like a bad idea to set
[18:16:06 CET] <devinheitmueller> BtbN: Yes.  Some of the early cable boxes would change the HDMI resolution based on the source content, which was an absolutely terrible experience for the user.
[18:16:41 CET] <BtbN> Well, I have my HTPC set to do pretty much the same. But not for resolution, but refresh-rate
[18:16:48 CET] <alexpigment> devinheitmueller: many (most?) still do that, it's just not on by default. if you record things from your cable though, you don't want to wasting time recording a 480i stream that's scaled up to 1080i
[18:16:51 CET] <devinheitmueller> Nowadays pretty much all cable boxes and OTA settop boxes will pick the highest resolution your TV supports and lock all output to that resolution.
[18:17:16 CET] <BtbN> a lot of TVs have really terrible upscalers
[18:17:41 CET] <alexpigment> BtbN: it's very true. for casual watching, i'd just keep everything on 1080i. for recording, that's where the native resolution is important
[18:17:49 CET] <devinheitmueller> alexpigment: Unless youre using a MythTV box or some other component video recorder, all recordings done by a cable box will be of the already compressed stream (i.e. not the uncompressed video that goes out to the display)
[18:18:14 CET] <alexpigment> devinheitmueller: mine is HDMI capture
[18:18:28 CET] <devinheitmueller> Same thing applies with HDMI.
[18:18:42 CET] <devinheitmueller> Not that I want to talk about how youre recording HDMI from a cable box.  :-)
[18:18:46 CET] <alexpigment> devinheitmueller: maybe I missed your point there. what are you saying?
[18:19:25 CET] <devinheitmueller> In your case then yes the resolution matters.  For most people, the DVR records the incoming stream and hence whether the output to the TV is 1080i or 480i doesnt have any impact on the size of the recording.
[18:19:26 CET] <alexpigment> devinheitmueller: I'm a person who has owned (and still owns) many VCRs. This is just my way of carrying on the tradition of saving things that get lost in time
[18:22:31 CET] <alexpigment> anyway, didn't mean to derail. Just pointing out that in practice, I don't see resolutions changes on broadcast, but everything is already transcoded once or twice by the time it gets to me. and bitrate-starved at that :)
[18:23:17 CET] <JEEB> well the stuff I get is what is also passed onto clients
[18:23:23 CET] <JEEB> and holy fuck I see various shit
[18:23:38 CET] <JEEB> (and I also see internal streams that are using various features in MPEG-TS)
[18:24:04 CET] <alexpigment> yeah, if you're working high enough on the chain, you seem some interesting stuff
[18:24:26 CET] <alexpigment> some channels are doing 4:2:2 H.264 at 60mbps
[18:24:27 CET] <JEEB> most often I see the same stuff that gets pushed through the cable as well, it's not like they re-transcode that from the source often
[18:24:49 CET] <JEEB> so you get all that local tV station ad cut-ins etc
[18:24:58 CET] <JEEB> so PMT updates with PID switches happen all the time
[18:25:13 CET] <devinheitmueller> JEEB: You would be surprised how often cable companies transcode OTA video.  It allows them to pack more OTA channels into a single 38Mbit QAM channel.
[18:25:22 CET] <JEEB> well sure
[18:25:27 CET] <alexpigment> Spectrum DEFINITELY transcodes OTA
[18:25:33 CET] <alexpigment> 100% certainty on that
[18:26:07 CET] <JEEB> but yea, just saying that PID switches in the content aren't unusual
[18:26:09 CET] <alexpigment> I'm pretty sure they put 3 HD channels into on 19mbit QAM
[18:26:20 CET] <JEEB> and I have examples of a broadcaster dynamically switching a channel on/off
[18:26:30 CET] <JEEB> so the PID for a channel's video track just switches and you get SD
[18:26:30 CET] <alexpigment> JEEB: no worries. I trust you - I just haven't seen it
[18:26:46 CET] Action: JEEB has that sample in his test samples for the lulz
[18:26:52 CET] <JEEB> just to see how many people's shit it breaks
[18:27:28 CET] <alexpigment> JEEB: actually, now that you mention it. I *have* seen that on OTA. For like 20 seconds it switched from HD to SD
[18:27:38 CET] <alexpigment> so you think the HD just got switched off and fell back to the SD?
[18:46:17 CET] <raytiley_> https://www.irccloud.com/pastebin/NKgRQg86/
[18:47:52 CET] <raytiley_> this is output from my linker... as far as I can tell it's finding swr_alloc int the correct place, not sure why at runtime it would fail to find it in the avformat-58.dll... Anyone used ffmpeg in a visual C++ solution successfully?
[19:18:51 CET] <comwizz2> ray, I tried ended up doing a mingw build and linking to it from there
[19:21:01 CET] <comwizz2> to be clearer, I built ffmpeg in mingw, then consumed it from a vc++ project.
[19:25:14 CET] <raytiley_> comwizz2: did you have the same issue with the zeronae builds?
[19:28:03 CET] <comwizz2> to be honest no idea what that means T_T
[19:32:02 CET] <raytiley_> :)
[19:32:03 CET] <raytiley_> https://ffmpeg.zeranoe.com/builds/
[19:40:54 CET] <dystoipa_> https://pastebin.com/Vh1RHLg1
[19:41:03 CET] <dystoipa_> how come my -t 10 are not being respected?
[19:41:14 CET] <dystoipa_> it just runs forever on each command
[19:41:44 CET] <alexpigment> have you tried putting the -t 10 after the input to see if that works?
[19:42:00 CET] <alexpigment> not that this explains anything - just suggesting as a test to further isolate the issue
[19:42:23 CET] <c_14> dystoipa_: I think you'd have to put -t on all inputs for that to stop?
[19:42:47 CET] <c_14> Also not sure if that's respected for these sorts of input so do what alexpigment said
[19:43:00 CET] <ChocolateArmpits> ^
[19:47:02 CET] <dystoipa_> thank you
[19:47:18 CET] <dystoipa_> it had to be after all inputs
[19:47:22 CET] <dystoipa_> it's working now
[20:24:37 CET] <dystoipa_> [gdigrab @ 033588c0] Capturing whole desktop as 1920x1080x32 at (1920,0)
[20:24:38 CET] <dystoipa_> [gdigrab @ 033588c0] Stream #0: not enough frames to estimate rate; consider increasing probesize
[20:24:45 CET] <dystoipa_> how do i increase the probesize?
[20:25:10 CET] <trogof> is there a way to use ffmpeg to make an mkv file from a dvd while just copying, not transcoding, the streams?
[20:29:56 CET] <ChocolateArmpits> trogof, use ffmpeg -i "concat:VTS_01_0.VOB|VTS_01_1.VOB" -codec copy -map 0:v -map 0:a output.mkv
[20:30:21 CET] <trogof> ChocolateArmpits: what does the concats part do? will that make one huge mkv with all chapters?
[20:31:03 CET] <ChocolateArmpits> It will join the distinct VOB files.
[20:32:20 CET] <trogof> ChocolateArmpits just two of them? VTS_01_0.VOB and VTS_01_1.VOB?
[20:32:31 CET] <ChocolateArmpits> As many as there are
[20:32:39 CET] <ChocolateArmpits> you separate them using a vertical bar
[20:32:40 CET] <trogof> i see
[20:32:55 CET] <ChocolateArmpits> Generally you should open the files and see if they fit your case
[20:33:02 CET] <trogof> i was confused because the _0 for my dvd is actually the menu to select episode
[20:33:09 CET] <trogof> and _1 is the first actual episode
[20:33:13 CET] <ChocolateArmpits> Yeah some are not "video" content
[20:33:38 CET] <ChocolateArmpits> menus are basically mpeg-coded pictures
[20:34:01 CET] <trogof> also another thing, i dont know if this is something wonky vlc is doing, but for some reason the vob files dont open exactly for each episode where they should, but delayed or hastened by 10 to 15 seconds
[20:34:10 CET] <ChocolateArmpits> You should skip them from the command
[20:34:22 CET] <trogof> but when i select an episode in the menu they start where they should
[20:34:25 CET] <trogof> odd behaviour, that
[20:34:28 CET] <ChocolateArmpits> vlc is bad for dvds
[20:35:02 CET] <trogof> so i've noticed lol
[20:35:04 CET] <ChocolateArmpits> idk if you're on windows, but mpc-hc had somewhat good support
[20:35:10 CET] <trogof> i see
[20:35:20 CET] <ChocolateArmpits> even windows media player lol
[20:35:46 CET] <trogof> https://mpc-hc.org/2017/07/16/1.7.13-released-and-farewell/
[20:35:50 CET] <trogof> well this is a shame
[20:36:28 CET] <dystoipa_> it's very much feature complete trogof
[20:36:32 CET] <trogof> dystoipa_: i see
[20:36:36 CET] <dystoipa_> so you can still use it :)
[20:36:37 CET] <dystoipa_> i do
[20:37:05 CET] <trogof> nice
[20:42:56 CET] <trogof> ok so i ran that command
[20:42:58 CET] <trogof> and i got this
[20:43:00 CET] <trogof> https://pastebin.com/raw/6zUZUXge
[21:44:55 CET] <im_dumb> hi, i am trying to stream content that is captured on a blackmagic decklink studio 4k card to a sencore receiver using ffmpeg. i have a command that seems to send correctly to the sencore receiver, however the file format that the receiver reads off is incorrect. it says it is receiving an h264 stream, but i have specified ffmpeg to use mpegts
[21:45:52 CET] <im_dumb> my command is this: https://pastebin.com/VxyjKAGn , is there anything glaringly wrong with how i am declaring the format of mpegts?
[21:46:01 CET] <im_dumb> the sencore receiver accept mpegts packets
[21:46:21 CET] <sfan5> nope nothing wrong there
[21:55:13 CET] <im_dumb> darn :(
[21:56:44 CET] <JEEB> I don't think you need -re with any actual realtime input
[21:57:01 CET] <JEEB> -re is an awful hack meant for non-realtime inputs
[21:57:13 CET] <im_dumb> oh
[21:57:26 CET] <im_dumb> so if it's coming from a camera, and fed to a black magic card, -re is probably useless?
[21:57:43 CET] <JEEB> well your capture card is highly unlikely to push you stuff too early
[21:57:55 CET] <im_dumb> one can hope :~)
[21:58:07 CET] <JEEB> then it is time traveling
[21:58:35 CET] <im_dumb> great scott!
[21:59:37 CET] <JEEB> but yea, that is mpeg-ts coming out into your UDP
[21:59:57 CET] <JEEB> you might want to set a muxrate and whatever the udp push-out thing was
[21:59:59 CET] <JEEB> -bitrate?
[22:00:32 CET] <JEEB> also no idea what that flush_packets is
[22:00:52 CET] <DHE> -muxrate 8M -bitrate 8M -pkt_size 1316 udp://239.0.0.1:1234
[22:01:05 CET] <im_dumb> i'll try that
[22:01:10 CET] <JEEB> and maxrate at that as well I bet too keep the encoder at bay
[22:01:25 CET] <JEEB> (with a matching bufsize according to requirements)
[22:01:37 CET] <DHE> for UDP based MPEGTS you also want a bufsize that's around 20-50% of the maxrate
[22:01:49 CET] <JEEB> hmm
[22:02:13 CET] <JEEB> I wonder if lavf UDP output can be made readable by some of those Very Expensive Boxes
[22:02:22 CET] <DHE> it's what I'm doing.
[22:02:23 CET] <DHE> :)
[22:02:28 CET] <JEEB> ok, so it's possible
[22:02:28 CET] <im_dumb> i have to head home, i appreciate your guys' help, i will be back :) thanks
[22:03:07 CET] <JEEB> for example I've had maxrate 3000k, bufsize SOMETHING and muxrate 3200k / bitrate 3200k
[22:03:20 CET] <JEEB> and I think pkt_size was that exact random value that is cargo culted from somewhere
[22:03:40 CET] <JEEB> so you'd guess I want to set bufsize something extra low?
[22:03:44 CET] <DHE> MPEGTS is like the old ATM network standard with fixed size cells of 188 bytes. 1316 is the max size that fits in a 1500 MTU ethernet packet (7 cells)
[22:03:51 CET] <DHE> that's where the number comes from
[22:03:52 CET] <JEEB> ah right
[22:03:57 CET] <JEEB> and yes, 188 bytes I know :)
[22:04:08 CET] <DHE> also assume a 10% muxing overhead. 3200 isn't enough. I'd go 3500 and see how it turns out
[22:04:18 CET] <JEEB> ah right
[22:05:07 CET] <JEEB> I was calculating kind of ~9-10% :)
[22:05:12 CET] <JEEB> since I had no audio
[22:05:19 CET] <JEEB> 3000k maxrate video and all that jazz
[22:05:43 CET] <DHE> yeah, but the muxing overhead of mpegts is pretty bad. 10-11 is a safer bet.
[22:05:51 CET] <JEEB> alright
[22:06:08 CET] <JEEB> should I tweak the muxrate as well, or only UDP bit rate?
[22:06:37 CET] <JEEB> since I'd guess the mux rate would get overflown anyways
[22:06:44 CET] <JEEB> if it needs more overhead
[22:06:51 CET] <DHE> the muxer will warn if it overflows
[22:07:03 CET] <JEEB> which it IIRC didn't
[22:07:24 CET] <DHE> muxrate <= bitrate   (but generally as close to each other as possible)
[22:07:31 CET] <JEEB> yup
[22:07:34 CET] <JEEB> that I gathered :)
[22:08:10 CET] <JEEB> anyways, this means that what I was doing more or less matches "best practices"
[22:08:21 CET] <JEEB> since it could have been the network creating the derps as well
[22:08:50 CET] <JEEB> I wanted to test just passing what I was getting as input through things, but someone had put service ID limiting onto the network
[22:08:51 CET] <DHE> this is why you need the bitrate parameter. most switches are garbage.
[22:08:58 CET] <CoReX> JEEB are you saying that -re can be removed even with live inputs as ffmpeg reads the live input frame-by-frame till the file stops
[22:09:17 CET] <DHE> CoReX: the source is only going to provide input at realtime rates anyway
[22:09:19 CET] <JEEB> CoReX: live input that doesn't EOF at your face doesn't need -re
[22:09:42 CET] <DHE> let the udp output bitrate soak up any small sputters in the throughput
[22:10:06 CET] <JEEB> and yes, I've rather fast learned that switches are crap a few years back ;)
[22:10:12 CET] <CoReX> ok thanks thats really intresting
[22:10:32 CET] <DHE> yeah I know. I learned a lot about microbursts in the last 9 months or so.... and how to detect them with wireshark
[22:11:06 CET] <JEEB> -re is an ffmpeg.c hack that basically waits X milliseconds for the input to more or less move at a "real time" speed
[22:11:17 CET] <JEEB> which can lead to really "funny" things if you timestamps go wee-wee
[22:11:17 CET] <CoReX> been using it for the last few months to game capture footage and it would always lag behind the writing file
[22:11:23 CET] <JEEB> *cough* MPEG-TS *cough*
[00:00:00 CET] --- Sat Nov 18 2017