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

[burek]

[00:00:33 CET] <kepstin> apple mobile devices (and other browsers) won't deinterlace it, so it'll look terrible
[00:03:51 CET] <furq> there's no benefit to doing that if you're splitting anyway
[00:06:32 CET] <barhom> furq: what does keeping the source have to do with splitting?
[00:06:49 CET] <barhom> lets assume I can control the deinterlacing on my client-side
[00:07:03 CET] <furq> i mean it'll be the same amount of processing either way
[00:07:11 CET] <DHE> not transcoding to 1080 if you already have a 1080 version is worth considering... if all your other requirements are met. (bitrate, profile, level)
[00:07:33 CET] <barhom> Why wouldn't I give a 1080i, 720p, 480p alternative
[00:08:48 CET] <barhom> DHE: the only issue is the interlacing part, I cant deinterlace if I keep the 1080i source
[00:08:57 CET] <barhom> but in my case I can control deinterlacing to my targets
[00:16:07 CET] <barhom> https://pastebin.com/sCGzAPkz < there, 1080i source copy, 720p, 480p transcode. HLS variants with master playlist
[00:17:07 CET] <furq> i guess that works
[00:17:21 CET] <furq> i'm not aware of any browser player that'll deinterlace the 1080i though
[00:17:51 CET] <barhom> furq: I tried videojs a while back I think that deinterlaced
[00:17:52 CET] <barhom> unsure though
[00:18:05 CET] <barhom> I see one problem though with this setup, the master playlist is kinda wrong
[00:18:21 CET] <DHE> I don't think javascript can deinterlace a video. only signal to the browser player to do it. and that still assumes a deinterlacer API toggle is available
[00:18:47 CET] <barhom> https://pastebin.com/PB7Paqpn < VLC is not selecting the 1920x1080 because of low bitrate
[00:18:53 CET] <DHE> oh hey, variant playlist making is now a thing...
[00:18:56 CET] <barhom> low "BANDWIDTH=XX"
[00:19:09 CET] <barhom> DHE: yup, Im experimenting ;)
[00:23:40 CET] <barhom> I guess I have to email the mailing list. ffmpeg wont write the correct bitrate to the master playlist for copied streams
[00:59:46 CET] <storrgie> I'm trying to figure out how to do something and might be looking in the wrong docs section. I've got an MKV container where I ripped the original content with two audio tracks, I want to pull out one of the audio tracks (the non lossless track), is there a way to list tracks in a container, then rip that track out?
[01:04:41 CET] <iive> storrgie, mkvtoolnix is probably the easiest way, as it comes with gui
[01:05:56 CET] <furq> storrgie: if you want to do it with ffmpeg then ffprobe foo.mkv; ffmpeg -i foo.mkv -c:a copy -map 0:a:0 bar.mka
[01:06:53 CET] <storrgie> yeah I'm poking around in mkvtoolnix I'd like to do this kind of thing in batch eventually, but I'm realizing I need to identify the audio track and it might be different for each rip
[01:07:19 CET] <furq> if you're on windows then just use mkvtoolnix yeah
[01:07:38 CET] <storrgie> nope, linux, and the files are all on a linux server where I'd rather process them with cli
[01:07:43 CET] <furq> oh ok
[01:07:46 CET] <storrgie> but mkvtoolnix has mkvmerge
[01:07:54 CET] <furq> well yeah check ffprobe -show_streams
[01:08:07 CET] <furq> and just ffprobe in general
[01:08:17 CET] <furq> that'll show you the codec of each stream in a manner you can parse easily in a script
[01:08:38 CET] <storrgie> yeesh thats a lot of data
[01:08:56 CET] <furq> -show_entries stream=codec_name
[01:09:14 CET] <furq> and get rid of -show_streams or else it'll show a bunch of metadata entries
[01:26:39 CET] <migu3x> Hello, I'm having a biiiig problem and still don't know how to fix it after a few days. So I captured a stream through VLC which every now and then has this kind of DTS errors because of #EXT-X-DISCONTINUITY tags. This parts of the stream have a different resolution than the actual parts I care from the stream (this are 960x670~) and the stream I want are 1280x720. Is there any way with ffmpeg to copy and put into a new file the frames
[01:43:31 CET] <migu3x> Is anyone here that has any idea of what I'm asking?
[02:28:51 CET] <klaxa> migu3x: there's this bugreport: https://trac.ffmpeg.org/ticket/5419 and this thread on the ML: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html
[02:29:07 CET] <klaxa> maybe that's useful?
[02:41:59 CET] <migu3x> klaxa: That mailing list post says there's a patch, how can I obtain it?
[02:43:15 CET] <klaxa> click on the link at the bottom that link that has "attachments" in the url
[02:43:36 CET] <klaxa> make sure to follow the rest of the thread though maybe there is an updated version of that patch
[02:44:26 CET] <klaxa> it's a git diff formated patch file, iirc you can apply it to a checked out git master with: git am somepatch.patch
[02:44:42 CET] <klaxa> you will need to build ffmpeg from source obvioulsy
[02:44:45 CET] <klaxa> *obviously
[02:47:00 CET] <migu3x> Oh thanks, it's on the official ffmpeg repo right? I am on windows right now, so I can't build it easily right?
[02:47:59 CET] <klaxa> https://trac.ffmpeg.org/wiki/CompilationGuide#Windows
[02:48:32 CET] <klaxa> i'm on linux, haven't used windows in years, can't really help you with that stuff, sorry
[02:51:23 CET] <klaxa> hmm, it seems the discussion died down and the patch was never updated nor applied, apparently also because while it does seem to work, it's apparently not done in an elegant way
[02:52:02 CET] <migu3x> Discussion was from 4 days ago lol. I can't find the repo/branch btw
[02:52:05 CET] <klaxa> but hey, nobody can stop you from using it i guess?
[02:52:15 CET] <migu3x> Imma build it on my c9 tho
[02:52:21 CET] <klaxa> http://git.ffmpeg.org/ffmpeg
[02:52:41 CET] <klaxa> huh, why doesn't it automagically redirect to https? :S
[02:53:08 CET] <migu3x> I mean the one the guy commited
[02:53:58 CET] <klaxa> huh, really?
[02:55:19 CET] <klaxa> hmm does not look like it: https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=hls
[02:55:19 CET] <migu3x> Sorry, really what? I don't get where can I access the commit/branch from the guy on the mailing list. I really don't understand that website
[02:56:29 CET] <klaxa> that guy sent a patch to the mailing list
[02:56:45 CET] <klaxa> you get the ffmpeg master branch by running: git clone https://git.ffmpeg.org/ffmpeg
[02:57:01 CET] <klaxa> then you download the attachment from the email and save it
[02:57:24 CET] <klaxa> then you change into the directory where you checked out ffmpeg and run: git am path/to/patch.patch
[02:57:32 CET] <klaxa> then you follow a compilation guide
[02:57:42 CET] <klaxa> and you should have build ffmpeg with the patch
[02:58:16 CET] <klaxa> but like i said, it doesn't look like it will be commited to ffmpeg the way it is now
[02:59:02 CET] <klaxa> i hope that doesn't mean there won't be something done about it, i personally have no clear idea what exactly is going on, but you're not the first to ask about it
[02:59:30 CET] <migu3x> Okay, thanks for the hlep bro
[02:59:34 CET] <migu3x> Hope I get this working
[04:17:33 CET] <migu3x> So i built ffmpeg on linux
[04:17:41 CET] <migu3x> Does it generate an .exe for windows ?
[04:19:37 CET] <furq> not unless you built it with mingw
[04:21:53 CET] <migu3x> fuck.
[04:22:19 CET] <migu3x> I mean, I run a test and it still threw the error messages, Idk how to test if it worked.
[04:27:41 CET] <migu3x> Nah man this shit is impossible
[05:24:57 CET] <dystopia_> "Non-monotonous DTS in output stream"
[05:25:07 CET] <dystopia_> is there some way i can fix these errors?
[05:25:09 CET] <dystopia_> https://i.imgur.com/j3Lztlr.png
[05:26:35 CET] <migu3x> lol ^
[05:26:49 CET] <migu3x> We just had a talk about that issue
[05:27:11 CET] <migu3x> [22:28] <klaxa> migu3x: there's this bugreport: https://trac.ffmpeg.org/ticket/5419 and this thread on the ML: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html [22:29] <klaxa> maybe that's useful? [22:38] == ilove11ven [~Thunderbi at 45.56.152.173] has joined #ffmpeg [22:41] <migu3x> klaxa: That mailing list post says there's a patch, how can I obtain it? [22:42] == terminalator [terminalat at gateway/vpn/privateinternetacces
[05:29:59 CET] <dystopia_> urg
[05:30:16 CET] <dystopia_> i have 11x6 hour videos i need to cat together
[05:30:18 CET] <migu3x> check that mailing list thread
[05:30:34 CET] <migu3x> Oh sorry, whats your issue?
[05:30:38 CET] <dystopia_> i don't really want to recode them if possible
[05:31:06 CET] <migu3x> I guess that Mailing list thread is your only salvation
[05:31:18 CET] <dystopia_> when i cat the files together, the timestamps go out of wack, eg if i cat the first two chunks in stead of being 12 hours long, its like 8 hours and out of sync
[05:31:26 CET] <migu3x> You need to merge that commit fix to the master branch and bouild your own ffmpeg with the fix
[05:31:28 CET] <dystopia_> same issues with mkvmerge
[05:32:08 CET] <dystopia_> thats beyond my skill set
[05:32:20 CET] <dystopia_> i will just recode to x264
[05:35:28 CET] <migu3x> I did it
[05:35:35 CET] <migu3x> If you have linux I can send you the binary i made
[05:35:47 CET] <migu3x> Ubuntu <
[05:41:07 CET] <gchcetiH> static linked?
[05:51:26 CET] <dystopia_> im on windows migu3x
[05:51:29 CET] <dystopia_> thanks for the offer though
[05:56:55 CET] <furq> idk if it's likely to be the same issue
[05:57:07 CET] <furq> non-monotonous dts in output stream is a generic warning that covers a lot of issues
[05:57:20 CET] <furq> and also that shows up a lot when everything is fine
[05:59:13 CET] <migu3x> For me it made my streams appear as 26 hrs long and video got desynced
[05:59:24 CET] <furq> dystopia_: pastebin the command you're using
[05:59:34 CET] <dystopia_> furq, it was a 64 hour video from nico nico
[05:59:47 CET] <dystopia_> on the back end they saved the videos as 6 hour chunks
[06:00:01 CET] <dystopia_> i have them all nativly downloaded and would just like to cat them backtogether
[06:01:02 CET] <dystopia_> https://pastebin.com/raw/S0htpiiy example of chunk1
[09:15:29 CET] <foobar_user68195> Hello. I have a problem with putting audio from one video to another one as a default audio track with a single command (I'm first doing some manually-adjusted-for-fps-differences trimming so as not to do the operation for huge files if it's going to fail; proof of concept of sorts). https://pastebin.com/hNPyEd62 - commands; https://pastebin.com/QxNZjP3c - error message.
[09:17:51 CET] <Nacht> c:v is missing it's -
[09:18:52 CET] <Nacht> Also, you're trimming the video, so you can't use copy
[10:11:04 CET] <foobar_user68195> Nacht, even after adding the missing "-" and removing copy the error is the same - media type mismatch. Apparently it didn't even get that far. (Also, how do I trim and not re-encode using complex filter, is this even possible?).
[10:35:01 CET] <Nacht> foobar_user68195: You can't trim and not transcode. The moment you use complex_filter you have to transcide (sadly)
[10:37:21 CET] <DHE> any filter requires transcoding. you can't filter without decoding and encoding (bsf aside)
[10:37:31 CET] <Nacht> and I suppose the problems with with error comes from the fact that you're using "fps=24000/1001" on an audio stream
[10:38:02 CET] <foobar_user68195> I read somewhere that it's the actual rate (instead of 23.976, it's 23.97602...)
[10:38:12 CET] <foobar_user68195> Will check without 24k/1k1
[10:38:21 CET] <Nacht> audio uses sample rates
[10:38:23 CET] <Nacht> not fps
[10:39:14 CET] <foobar_user68195> ffmpeg -i goodaudiomovie.avi -r 23.976 goodaudio.mp4
[10:40:01 CET] <foobar_user68195> I'm getting confused with sample rates and fps (I read somewhere that audio has no fps). It's hard to wrap my head around it...
[10:43:36 CET] <foobar_user68195> I'll try and work around it and make it in two steps (one: proof of concept - cut from both videos without transcoding; two: proper complex filter that will work for the cuttings and target huge files). Will get back to you later, thanks for help :)!
[11:17:20 CET] <TarquinWJ> furq: many thanks for the assistance yesterday. I have tried using aac_low (with both -c aac -strict -2, and -c libvo_aacenc) and each time it still produces 2 mono channels
[11:17:55 CET] <TarquinWJ> if you managed to get a single mono channel, I'd love to know what command line you are using
[11:18:44 CET] <TarquinWJ> checking with MediaInfo, it reports:
[11:18:44 CET] <TarquinWJ> Channel(s)                               : 2 channels
[11:18:44 CET] <TarquinWJ> Channel(s)_Original                      : 1 channel
[11:18:44 CET] <TarquinWJ> Channel positions                        : Front: C
[11:51:13 CET] <hellyeah> is there a way to send converted file to some online host instead of localhost?
[11:58:36 CET] <JEEB> there's plenty of protocols available
[11:59:06 CET] <JEEB> ffmpeg.c can list available ones with -protocols
[12:04:32 CET] <hellyeah> like
[12:04:44 CET] <hellyeah> ffmpeg -protocols -http link?
[12:06:31 CET] <hellyeah> https://stackoverflow.com/questions/24017930/how-to-stream-with-ffmpeg-via-http-protocol
[12:56:09 CET] <hellyeah> what is the difference between this command ffmpeg -i http://server:port -c copy somefile.ogg and ffmpeg -i somefile.ogg -chunked_post 0 -c copy -f ogg http://server:port
[12:56:09 CET] <hellyeah> ?
[13:00:27 CET] <th3_v0ice> Can anyone explain what are the hls_ts_options ?
[13:01:56 CET] <TarquinWJ> hellyeah: the first loads a file from a website, and saves a converted version locally. the second seems to load a local file, and upload a converted version to a website. essentially, they do the opposite of each other.
[13:02:17 CET] <hellyeah> ah wrong one
[13:02:50 CET] <hellyeah> ffmpeg -i somefile.ogg -c copy -listen 1 -f ogg http://server:port
[13:02:50 CET] <hellyeah>  and  ffmpeg -i somefile.ogg -chunked_post 0 -c copy -f ogg http://server:port
[13:02:54 CET] <hellyeah> sorry TarquinWJ
[13:03:27 CET] <DHE> th3_v0ice: hls is effectively a format interposer. it's a format that itself makes new files of certain formats. hls_ts_options are the options that go into that lower level output format
[13:06:28 CET] <th3_v0ice> DHE: Ok, is there some place where I can review all the options and see what they are doing?
[13:16:50 CET] <DHE> th3_v0ice: https://ffmpeg.org/ffmpeg-formats.html  HLS will use either the mpegts or mp4 muxer, so those options are available
[13:20:40 CET] <th3_v0ice> DHE: Ok, thanks!
[13:20:57 CET] <TarquinWJ> hellyeah: unless I have misunderstood the docs, the first one will use chunked Transfer-Encoding when posting to the website, while the second will not. it doesn't say what it will use instead of chunked though - perhaps it sends it as a single chunk...
[13:21:25 CET] <hellyeah> so
[13:21:32 CET] <hellyeah> it is like small package
[13:21:37 CET] <hellyeah> is it correct?
[13:21:54 CET] <hellyeah> to send overal thing it will send small piece of video at a time
[13:22:34 CET] <TarquinWJ> send a small piece of the file at a time, whatever that file contains. (note that it will not necessarily be a valid video segment)
[13:23:17 CET] <TarquinWJ> you can read about chunked transfer encoding in various bits of HTTP documentation, such as https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding
[13:24:58 CET] <TarquinWJ> imagine taking a video file, randomly splitting it into 100 bytes (without caring whether each part is now valid video data), sending the pieces of the file, and expecting the other end to stitch the files back together again to make a valid file
[13:25:08 CET] <TarquinWJ> (gross oversimplification, but I hope that makes sense)
[15:08:45 CET] <foldingcookie> is there a way to determine the time position corresponding to a given byte offset in an audio file?
[15:14:20 CET] <TarquinWJ> given that many codecs can do compression over time as well, can't a single byte relate to a whole range of times?
[15:14:58 CET] <BtbN> decode the file until that point and keep track
[15:21:31 CET] <kepstin> foldingcookie: note that in some containers, e.g. ogg, you can resync in the middle of a file and then read the next packet timestamp. But this is very container-specific and doesn't work on most of them.
[15:48:01 CET] <migu3x> Any easy way to build ffmpeg for windows 32 bits (x86) with almost every needed things (openssl,libass,libaac) without being impossible?
[16:54:10 CET] <dadada> hi
[16:54:22 CET] <dadada> can I convert a file that's not yet completely downloaded on the fly?
[16:54:39 CET] <dadada> meaning, the conversion waits for new incoming bytes and keeps on converting
[16:55:10 CET] <dadada> instead of terminating after the end of the file is reached?
[16:55:38 CET] <kepstin> dadada: ffmpeg doesn't really have anything to handle that case at the moment - if it runs faster than the download, it'll exit when it hits the end of the file
[16:55:59 CET] <kepstin> if you plan in advance, you can do something like use 'tee' to save to a file and pipe to ffmpeg at the same time.
[16:57:32 CET] <dadada> ah, ok... is something like this planned?
[16:57:56 CET] <dadada> if I can use a pipe to handle that case I should be mostly find
[16:57:58 CET] <dadada> fine
[17:22:40 CET] <kepstin> dadada: note also that ffmpeg can read directly from http and some other types of streaming urls as well.
[17:23:01 CET] <dadada> noted
[17:25:59 CET] <dadada> I'm going to use tail -fn +1 file to pipe into ffmpeg
[17:27:32 CET] <kepstin> dadada: that should work. Sending a SIGINT to ffmpeg when the file is done will make it cleanly finish & close the output file.
[17:27:49 CET] <dadada> :D
[17:29:41 CET] <dadada> kepstin: are there convenience features in ffmpeg, like "hey ffmpeg, please reduce the video quality of that file enough so that its filesize is reduced by about 30%"?
[17:30:13 CET] <kepstin> dadada: well, if you want a specific filesize, you do that by setting a bitrate.
[17:30:38 CET] <kepstin> if your input is 6000kbit and you want 30% size reduction, set it to encode at 3000kbit :/
[17:30:58 CET] <dadada> why is that not a 50% reduction?
[17:31:09 CET] <kepstin> er, because I made a typo
[17:31:12 CET] <kepstin> that is 50% reduction :)
[17:31:17 CET] <dadada> oh, I almost thought so
[17:31:21 CET] <kepstin> but note that when doing encoding with a bitrate setting, you normally want to do a 2-pass encode
[17:31:39 CET] <dadada> meaning? :D
[17:31:43 CET] <dadada> me is a noobie
[17:32:19 CET] <kepstin> in a 2-pass mode, the encoder gets run twice over the same input file. THe first time it collects stats about the video content to figure out how best to distribute bitrate, and the second time is the real encode.
[17:32:46 CET] <dadada> hmm... I'm doing this live while the file is being downloaded
[17:32:59 CET] <dadada> 2-pass encoding probably won't work in this situation
[17:33:27 CET] <dadada> and I also want to transfer the converted stream live to another location... so there's no time for a second pass
[17:33:37 CET] <dadada> as it is intended to be instantly consumed
[17:33:43 CET] <kepstin> Right, if you want to live stream the output, then you need to use 1 pass mode.
[17:34:12 CET] <dadada> so worse quality... but predictable file size? I take it
[17:34:47 CET] <kepstin> in 1-pass mode, the issue is that you get inconsistent quality. On complex scenes the encoder has to lower quality, and on simple scenes it can use higher quality.
[17:35:07 CET] <dadada> ok
[17:35:57 CET] <kepstin> The x264 encoder has another different option - crf mode. With crf mode, you pick a constant quality level and then it gives you unpredictable, variable bitrate output that maintains quality.
[17:36:31 CET] <kepstin> that's useful for encoding files to disk, but not as good for live streaming normally.
[17:36:37 CET] <dadada> I see
[17:49:15 CET] <memo1> hi, i using ffmpeg to grab video from a hikvision camera.  How i restart ffmpeg command on errors?, or after restart?
[18:14:02 CET] <memo1> i need to wrte a script?
[19:17:37 CET] <acresearch> people, i have 2 .flv video, and i want to combine them into 1 video, same quality same encoding same everything just into 1 file. how can i do that please?
[19:18:55 CET] <JEEB> cat 1.flv 2.flv > full.flv
[19:19:49 CET] <furq> does flv support that
[19:20:02 CET] <JEEB> it should, it's just a stream of packets afaik
[19:20:30 CET] <acresearch> JEEB: oh so no ffmpeg?
[19:20:41 CET] <JEEB> well if you can get around needing it, why not?
[19:20:53 CET] <JEEB> just test that you can play it to the end (same streams etc)
[19:21:02 CET] <JEEB> if that works, then that's it :P
[19:23:52 CET] <acresearch> JEEB: hmmm that is weird, it worked, but the timeing seems wrong,    so first video is 0:29 hours long and second is 2:53 hours long...   the final video is still 2:53 hours long but has both their memory size ?!?!
[19:24:24 CET] <JEEB> FLV doesn't have that info properly anyways so (´4@)
[19:24:41 CET] <JEEB> if you can play through file 1 to file 2 then it should all be OK
[19:24:53 CET] <JEEB> you can also remux from that concatenated thing if you want with -c copy
[19:25:00 CET] <JEEB> if you'd like to check if that improves things
[19:25:11 CET] <JEEB> ffmpeg -i concat.flv -c copy remuxed.flv
[19:45:34 CET] <acresearch> JEEB: were does 1.flv and 2.flv go?
[19:46:01 CET] <JEEB> well you concatenated already, no? result of that is concat.flv
[19:47:31 CET] <acresearch> well i did: cat 1.flv 2.flv > 3.flv
[19:47:45 CET] <JEEB> then 3.flv is what you want as the input (-i FILE)
[19:47:56 CET] <acresearch> then i do: ffmpeg -i 3.flv -c copy final.flv    ?
[19:48:05 CET] <acresearch> aha
[19:48:17 CET] <acresearch> and what will this do?
[19:48:22 CET] <JEEB> remultiplex
[19:48:32 CET] <acresearch> i see
[19:48:40 CET] <JEEB> take the streams into separate "pipes" from the FLV, and then put them back into FLV from zero
[19:49:02 CET] <JEEB> (you could also switch containers at this point if you wanted)
[19:49:14 CET] <acresearch> i see
[20:45:23 CET] <awal> Hi. How can I instruct ffmpeg to write output based only on a stream selected from the output of ffprobe on the input and ignore all other information including metadata, side data and other streams?
[20:47:09 CET] <__raven_> hi
[20:51:42 CET] <__raven_> i am trying to remux AND transcode a dvb-s(2) ts-recording to a lowres-mp4+aac mp4 file. on a newer version (debian) the result is corrupted by missing the header. comparison of versions here: https://pastebin.com/pLNmnYZG
[20:55:17 CET] <sfan5> paste both logs during transcoding
[20:58:39 CET] <__raven_> sfan5: there are no obvious errors during transcoding. trying with debug out?
[20:59:15 CET] <sfan5> might be helpful
[21:01:21 CET] <__raven_> i will try
[21:32:14 CET] <shaz> Hi, is there a possibility to use fifo without encoding? I need -drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 options to use without encoding.
[21:41:14 CET] <shaz> what about the tee muxer with fifo segfaults in case of multiple rtmp outputs? any body has some info?
[21:42:35 CET] <JEEB> segfaults sound wrong although tee muxer is a "fun" thing.
[21:42:45 CET] <JEEB> test current master and if it still happens, post an issue on trac
[21:43:01 CET] <JEEB> (if possible with a gdb backtrace with a non-stripped binary)
[21:43:19 CET] <JEEB> (you can do that with --disable-stripping)
[21:43:35 CET] <shaz> But is there some recent bug with tee muxer?
[21:43:44 CET] <JEEB> not that I know
[21:43:56 CET] <shaz> it works without fifo.
[21:44:57 CET] <shaz> i want to use "-drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1" options with tee muxer but seems i have to use fifo and if i use fifo then it segfaults.
[21:44:59 CET] <JEEB> anyways, I recommend you report the issue on the trac if it still happens with current master with as much information as possible to make it happen
[21:45:25 CET] <JEEB> in the worst case an error check will be added and you get told you're doing something wrong
[21:45:35 CET] <JEEB> (because it really shouldn't be crashing)
[21:45:44 CET] <JEEB> in the best case you've helped uncover a bug :P
[21:46:33 CET] <shaz> yes good point. but seems a bug - as it shouldn't crash but rather give me information if i am using some options wrong.
[21:47:17 CET] <shaz> JEEB: is there any 64 bit binaries? or do I have to compile?
[21:47:40 CET] <JEEB> if you want debug symbols you'll have to most likely compile :P
[21:48:02 CET] <shaz> oh thats painful. there is usually debug symbol packages as well
[21:48:14 CET] <JEEB> if there is, great :P
[21:48:24 CET] <JEEB> FFmpeg itself doesn't provide binaries
[21:48:41 CET] <shaz> ok
[21:48:51 CET] <shaz> i think master is not stable or is it?
[21:49:23 CET] <shaz> usually they have some new patches and features pouring in...
[21:52:05 CET] <JEEB> shaz: master is what most people other than distros use
[21:52:22 CET] <JEEB> in many cases releases are actually worse off than master
[21:52:35 CET] <JEEB> master is where all the fixes (and features, yes) get merged
[21:52:42 CET] <JEEB> generally you can see how workable it is with fate
[21:52:50 CET] <JEEB> http://fate.ffmpeg.org/
[21:52:59 CET] <JEEB> that's the automated testing suite
[21:53:58 CET] <shaz> Thanks JEEB . Already downloading...  Compilation is on the way, lets hope its not a bug ... :)
[21:59:41 CET] <shaz> JEEB: while compiling i found h264_v4l2m2m , i think thats h264 encoder right?
[22:20:35 CET] <shaz> JEEB: i compiled and it says it cant find libx264 encoder
[22:20:39 CET] <shaz> why is that?
[22:21:21 CET] <JEEB> you didn't build FFmpeg with the libx264 library?
[22:21:45 CET] <JEEB> requires you to have libx264 development stuff installed, and then --enable-gpl --enable-libx264
[22:21:53 CET] <shaz> hmm ok
[22:21:56 CET] <JEEB> (because libx264 is GPL and FFmpeg by default is LGPL)
[22:22:07 CET] <transcodeine> thoughts on this error coming off my gpu?  i have already tried the max_queue 'workaround' to no avail:
[22:22:09 CET] <transcodeine> Too many packets buffered for output stream 0:1.577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A
[22:22:29 CET] <transcodeine> only happens when using GPU
[22:22:37 CET] <JEEB> could be the drivers, could be FFmpeg
[22:22:53 CET] <JEEB> report on trac with as much information as possible
[22:22:57 CET] <shaz> thanks JEEB :)
[22:23:39 CET] <transcodeine> https://pastebin.com/HSsLeHUB
[22:23:41 CET] <transcodeine> cli
[22:24:47 CET] <JEEB> https://trac.ffmpeg.org/ is the place to report, and add as much as data as possible for developers to be able to test it themselves (sample file etc)
[22:31:33 CET] <transcodeine> ah it's a known bug
[22:32:09 CET] <JEEB> ?
[22:33:06 CET] <transcodeine> the problem i'm experiencing
[22:33:24 CET] <JEEB> yes? did you mean you found a ticket about your issue?
[22:33:31 CET] <transcodeine> yeah
[22:33:31 CET] <transcodeine> #6375: [bug][regression] Too many packets buffered for output stream
[22:36:20 CET] <JEEB> yea, that's with swdec but your issue is specific to hwdec or hwenc?
[22:37:46 CET] <JEEB> but it would be interesting to know what sort of streams get this :P (try with -v verbose, it should give you stats on which streams got decoded and how much)
[22:38:44 CET] <transcodeine> sure
[22:39:01 CET] <JEEB> because it basically means that something gets stuck somewhere for some track (no frames or packets)
[22:39:14 CET] <transcodeine> from the threads i read it has to do with audio
[22:39:22 CET] <transcodeine> and multiple channel audio
[22:39:26 CET] <transcodeine> or at least everyone has that in common
[22:39:32 CET] <transcodeine> 5+ channels
[22:39:33 CET] <JEEB> well that by itself doesn't fail stuff
[22:39:40 CET] <transcodeine> ah
[22:39:43 CET] <JEEB> given that I've worked with such audio quite a bit
[22:39:49 CET] <transcodeine> fair enough
[22:40:41 CET] <JEEB> I'd recommend you post your full output with either -v verbose or -v debug onto a pastebin-like thing and link it here
[22:41:00 CET] <JEEB> should show how many packets/frames got handled per stream type
[22:41:01 CET] <shaz> JEEB: working ok with master
[22:41:07 CET] <shaz> no issues with same options
[22:41:15 CET] <JEEB> alright
[22:41:19 CET] <JEEB> one more happy user
[22:41:22 CET] <JEEB> (I guess?)
[22:41:33 CET] <shaz> JEEB: I am just worried that it does not break other part of ffmpeg which we are using
[22:41:45 CET] <shaz> thats why we go for releases instead of latest development
[22:41:56 CET] <shaz> but you mentioned that its better, so we will stick with this
[22:42:18 CET] <JEEB> well yea, releases really get rather random amounts of attention
[22:42:57 CET] <JEEB> mostly because there's no official standing on any of them as far as I can tell
[22:43:16 CET] <JEEB> and most people who use FFmpeg and are close to its development work with master
[22:43:47 CET] <JEEB> of course you should have your own API client's test suite to make sure nothing you care about breaks, but any fixes are much more likely to be in master
[22:43:54 CET] <JEEB> than ending up back-ported to releases
[22:44:29 CET] <JEEB> other than stuff that happens to "fix" some fuzz or possibly something that happens to have received a fancy ID as a "security issue"
[22:44:40 CET] <transcodeine> so
[22:45:00 CET] <transcodeine> this below repeated about 9000 times
[22:45:02 CET] <transcodeine> cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[22:45:23 CET] <transcodeine> the next line is the error:  Too many packets buffered for output stream 0:1.
[22:45:40 CET] <JEEB> I'd recommend taking a hard look at your input MOV
[22:45:44 CET] <transcodeine> no other errors
[22:45:51 CET] <transcodeine> corrupt during xfer huh..was thinking of that
[22:46:06 CET] <transcodeine> it's 120GB, good chance.
[22:46:16 CET] <JEEB> boxdumper --timestamp thing.mov
[22:46:22 CET] <JEEB> L-SMASH contains that fancy tool
[22:46:34 CET] <JEEB> you can see if it actually has timestamps set properly in the MOV
[22:46:41 CET] <transcodeine> boxdumper huh
[22:47:03 CET] <acresearch> JEEB: i tried your code and it did not work
[22:47:15 CET] <JEEB> yea, you can either dump the structure (--box) or timestamps (--timestamp)
[22:47:15 CET] <acresearch> combining 2 video into 1
[22:47:19 CET] <JEEB> what
[22:47:40 CET] <JEEB> transcodeine: it will dump the results in stdout so piping it into a file if you want it saved is probably a good idea
[22:47:44 CET] <JEEB> s/piping/redirecting/
[22:48:16 CET] <transcodeine> hah after compiling ffmpeg that thing flew!
[22:48:20 CET] <transcodeine> will do
[22:48:32 CET] <JEEB> transcodeine: in theory MOV/ISOBMFF (MP4) should always have both DTS and PTS (CTS)
[22:48:41 CET] <JEEB> so not having DTS sounds /really/ fishy with MOV input :P
[22:48:46 CET] <transcodeine> i hear ya
[22:48:54 CET] <transcodeine> let me read it with mediainfo from src
[22:48:54 CET] <JEEB> it's either the decoder fucking things for you, or the encoder, or both
[22:49:07 CET] <JEEB> I don't think mediainfo can dump you a list of timestamps?
[22:49:23 CET] <transcodeine> it can verify dts if it was corrupt, no?
[22:49:25 CET] <JEEB> also the file itself could be just fine
[22:49:30 CET] <JEEB> not that I know
[22:49:30 CET] <transcodeine> ok
[22:49:58 CET] <JEEB> I would take the hwdec and hwenc out of the equation first
[22:50:02 CET] <JEEB> then check the timestamps
[22:50:19 CET] <transcodeine> running now
[22:50:32 CET] <JEEB> also why did you have genpts there?
[22:50:36 CET] <JEEB> since MOV should have timestamps just fine
[22:50:43 CET] <transcodeine> i was trying to mess around with a fix for this
[22:50:47 CET] <transcodeine> i saw someone use that to fix it
[22:50:50 CET] <transcodeine> (for them)
[22:50:59 CET] <transcodeine> Failed to construct timeline.
[22:50:59 CET] <JEEB> ok, then just take that away as well to minimize random things
[22:51:03 CET] <JEEB> lol
[22:51:08 CET] <transcodeine> corrupt right?
[22:51:19 CET] <JEEB> not necessarily since it could always be a boog somewhere, but that sounds funny
[22:51:39 CET] <JEEB> ffprobe -of json -show_streams -show_packets FILE.MOV is also possibly interesting
[22:51:42 CET] <transcodeine> hrm
[22:51:44 CET] <JEEB> (this will output a bunch of JSON)
[22:51:57 CET] <JEEB> which will include timestamps read by libavformat
[22:52:34 CET] <JEEB> and IIRC ffprobe even misses some of the random timestamp hackery that's in ffmpeg.c
[22:52:35 CET] <transcodeine> looks 'clean' to me
[22:52:45 CET] <transcodeine> scrolling json as requested :
[22:52:46 CET] <transcodeine> )
[22:52:58 CET] <JEEB> so it has pts and dts set for all packets?
[22:53:20 CET] <transcodeine> let me check- on visual inspection/scrolling yes
[22:53:25 CET] <JEEB> (you could make a short python script to load the JSON)
[22:53:36 CET] <JEEB> from json import load as load_json
[22:53:42 CET] <transcodeine> would it be blank?
[22:53:45 CET] <transcodeine> what am i scripting to find?
[22:54:03 CET] <JEEB> let's see what ffprobe outputs whe AV_NOPTS_VALUE happens
[22:54:06 CET] <JEEB> *when
[22:54:27 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffprobe.c;h=a4ac6972a215af6114972ae601d2e0d3501752ac;hb=HEAD#l797
[22:54:32 CET] <transcodeine> i dumped that to a file
[22:54:33 CET] <JEEB> seems to be N/A
[22:55:06 CET] <transcodeine> is there a chance this is corrupted? will only take 10 min to resend
[22:55:30 CET] <JEEB> you can do a sha256sum file.mov on both sides
[22:55:44 CET] <JEEB> or rsync -rP server:/path/to/file.mov /local/file.mov
[22:55:47 CET] <transcodeine> duh why didn't i think of that
[22:55:53 CET] <JEEB> which would transfer possible non-matching chunks
[22:55:54 CET] <transcodeine> fuck rsync over sha :)
[22:55:55 CET] <transcodeine> faster
[22:56:08 CET] <JEEB> yea, rsync would do the hashing in chunks on both sides
[22:56:16 CET] <JEEB> otherwise you'd have to transfer the whole thing :)_
[22:56:25 CET] <JEEB> (in case of mismatch)
[22:56:35 CET] <transcodeine> i have two linux boxes with it so no probs
[22:56:38 CET] <transcodeine> one i know is good
[22:57:16 CET] <JEEB> but yea, it seems like that function is indeed utilized in show_packet for pts and dts
[22:57:23 CET] <JEEB> so if there's any N/A strings
[22:57:33 CET] <transcodeine> 120GB sha
[22:57:40 CET] <JEEB> that's a AV_NOPTS_VALUE
[22:57:47 CET] <JEEB> (or otherwise confuzzled values)
[22:59:29 CET] <transcodeine> i may have to retract my thought that sha256 is faster :\
[22:59:51 CET] <JEEB> it'd probably be IO bound in either case
[23:00:25 CET] <transcodeine> maybe.  nvme
[23:03:20 CET] <transcodeine> got one, waiting for the other
[23:08:31 CET] <transcodeine> they match :\
[23:09:40 CET] <transcodeine> okay will hammer on this for a bit
[00:00:00 CET] --- Sat Mar 24 2018