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

[burek]

[00:38:16 CET] <jleclanche> gnarface: higher thread_queue_size didn't help. I'm working around this by having a separate `pacat` process running at the same time as the ffmpeg process.. feels kinda bad
[00:38:33 CET] <jleclanche> pacat is super efficient at it but then i have to merge the two myself, oh well
[01:19:05 CET] <esspapier> https://a.uguu.se/mbfOgUAJftYc.png
[01:19:10 CET] <esspapier> creating gifs is hard
[02:20:44 CET] <lindylex> I have always wanted to understand what process can I use to get an exact cut of a video using ffmpeg.  Some videos I can not get it to cut exactly where I want.
[02:21:07 CET] <lindylex> To the .5 second at times.
[02:44:53 CET] <kepstin> lindylex: assuming you're re-encoding (i.e. you're not using -c copy), ffmpeg should have frame-exact seeking.
[03:00:05 CET] <DHE> depends on whether you put the seek command on the input or output
[03:00:33 CET] <DHE> the input will by necessity seek to a keyframe on the input. but a seek on the output will discard [decoded] input frames to the time it wants
[03:02:57 CET] <lindylex> kepstin : It has to transcode.
[03:03:21 CET] <lindylex> DHE : let me look into this.
[03:03:38 CET] <kepstin> DHE: ffmpeg seeks to exact frames with -ss on the input, assuming it's transcoding.
[03:04:07 CET] <kepstin> DHE: (it does that by seeking to the keyframe prior to where you want, then decoding and discarding the extra frames)
[03:04:23 CET] <DHE> really? last time I tried that it didn't...
[03:04:26 CET] <DHE> then again that was years ago now
[12:05:03 CET] <rahul_-> Hi All
[12:07:06 CET] <rahul_-> I am trying to do ffmpeg -i big_buck_bunny_1080p_h264.mov -vbsf h264_mp4toannexb -vcodec copy -an 2.h264
[12:07:21 CET] <rahul_-> I want to do same in my program also, how can i ?
[13:58:57 CET] <moreentropy> hi. I seem to have a timestamp issue when streaming audio live, don't know how to approach this
[13:59:52 CET] <moreentropy> i encode from alsa to multiple streaming formats (icecast, hls, dash). after a few days the timestamp in dash and hls starts to move more and more into the future
[14:00:55 CET] <moreentropy> for HLS it doesn't matter but when turning on program_date_time after 6 days of encoding the timestamps are ~20 seconds in the future.
[14:03:16 CET] <moreentropy> the DASH stream seems to synchronize to the wall clock, so after a few days of encoding the stream will wait for ~20 seconds before starting playback. I wonder if i have to resample or somehow tell ffmpeg to keep up timing? sound input is digital from a broadcast processor
[14:09:34 CET] <BtbN> you usually want to re-start the process every once in a while
[14:12:05 CET] <DHE> sounds like a case of multiple hardware clocks not being in perfect sync...
[14:13:19 CET] <rahul_-> How can i get the codec name ?
[14:13:28 CET] <rahul_-> in my case the video is H264
[14:13:38 CET] <moreentropy> yeah i don't really want to restart the process as that means all listeners will be disconnected (it's for the live streams of a FM radio station)
[14:14:21 CET] <rahul_-> I am doing this https://pastebin.com/jaEjJRdS
[14:15:16 CET] <vbmizio> hi all, can someone help me with concatenate coommand?
[14:16:10 CET] <moreentropy> the stream encoder pc should be NTP synced, I guess the sound card input isn't synced to the wallclock though (48khz digital in). So my wild guess is that I have to let ffmpeg resample the input to have it in sync with it's view of wall clock time
[14:17:33 CET] <rahul_-> but with pFormatCtx i am getting video_codec_id = AV_CODEC_ID_NONE
[14:22:40 CET] <vbmizio> I'm using ffmpeg to concatenate some video clip. I use the -f concat -i "C:\MyFileList.txt" -c copy "D:\Video\5tracce\mer.MOV" string, but if the source video clips have more than an audio track, the output video file has just one track. Can you help me?
[15:08:56 CET] <debianuser> moreentropy: What device do you capture from? I.e. is that `-f alsa -i default`?
[15:10:52 CET] <moreentropy> debianuser: -channel_layout stereo -f alsa -sample_rate 44100 -i hw:0,0
[15:12:04 CET] <moreentropy> i used to capture from a dsnoop device shared by multiple processes but now have chained all encoders into one ffmpeg invocation that uses the hw device
[15:12:12 CET] <moreentropy> (using fifo for each output)
[15:15:34 CET] <moreentropy> the streams in question are resampled to 48000 (for historical reasons we have to capture in 44100 and resample to 48000 for dash/hls and keep 44100 for mp3/vorbis icecast streams). don't know if this contributes to the drift somehow
[15:48:46 CET] <debianuser> moreentropy: Maybe you can do it the other way around? I.e. capture in 48000 and resample to 44100 for mp3/vorbis? Or maybe keep 48000 for all of them?
[15:50:01 CET] <DHE> I suspect that the sound card is subtly capturing at a different bitrate, like 44099 Hz or something, and it's causing the drift...
[15:57:42 CET] <moreentropy> audio is fed to the soundcard using spdif w/ rate 44100 so i can't capture  with a different rate.
[15:58:50 CET] <moreentropy> DHE: so I guess i have to look into the resampling options to compensate for that? https://ffmpeg.org/ffmpeg-resampler.html
[15:59:34 CET] <DHE> it's just a theory as to what is causing the slow drift... hardware isn't necessarily going to run at precisely the right clock speed. it's also possible the video source suffers a similar problem.
[16:01:04 CET] <moreentropy> yeah. in this case it's audio only but with absolute timestamps in the output.
[16:01:43 CET] <moreentropy> i guess i'll try out what i find and see what will mitigate the drift
[16:04:39 CET] <moreentropy> apart from that I'm totally in love with ffmpeg as a stream encoder for our little FM radio station. incredibly powerful <3
[16:06:05 CET] <DHE> oh, there is no video is there... well never mind that then
[16:08:08 CET] <moreentropy> yeah i'm also experimenting with sending audio from that ffmpeg to another ffmpeg and combining it with a video stream from ffmpeg running on a raspberry pi and getting it reasonably synced but that's a totally different story, first want to get the HLS and DASH straight
[16:17:29 CET] <Zuu> Hi guys, i have a bit of trouble understanding the documentation. specifically this part: https://ffmpeg.org/ffprobe-all.html#Examples-130
[16:18:21 CET] <Zuu> i try: ffprobe -select=1 <yadda yadda yadda>
[16:18:41 CET] <Zuu> i get error: Missing argument for option 'select=1'
[16:19:01 CET] <Zuu> i tried all kinds of variations of that, essentially same error message every time
[16:19:27 CET] <furq> Zuu: -vf select=1
[16:19:56 CET] <Zuu> error msg: Failed to set value 'select=1' for option 'vf': Option not found
[16:22:57 CET] <Zuu> just to eliminate all misunderstandings, my complete command line that i just tried: ffprobe -show_frames -i "TestContent/LG Dolby Comparison 4K Demo.ts" -vf select=1
[16:23:25 CET] <furq> put it before the output filename
[16:23:28 CET] <Zuu> without the "-vf select=1" part, i get proper output
[16:23:42 CET] <Zuu> i dont have an output filename, this is ff_probe_
[16:24:15 CET] <Zuu> and the documentation i linked is also for ff_probe_
[16:24:17 CET] <furq> oh right there's some dumb shit you have to do to get that to work in ffprobe
[16:24:38 CET] <Zuu> Well, that's why i come here :D
[16:24:46 CET] <furq> why do you want to use select in ffprobe anyway
[16:25:04 CET] <Zuu> because it's much muuuuuuuch faster
[16:25:18 CET] <furq> are you sure you don't actually want -skip_frame
[16:25:36 CET] <Zuu> i tried that too, but im not convinced it is nearly as fast as the filter
[16:25:45 CET] <Zuu> err as the 'select' thing
[16:26:15 CET] <Zuu> i want to skip things as early in the process as possible, and if i understand, the 'select' thing does that
[16:27:02 CET] <furq> if you really want to try it then ffprobe -f lavfi amovie=foo.ts,select=1
[16:27:08 CET] <Zuu> so yeah, i really want to see a working example of just the simplest select=1 expression
[16:27:32 CET] <furq> but -skip_frame is a decoder option, filters only affect the output file
[16:27:45 CET] <furq> so i sort of doubt select will be faster in ffprobe
[16:27:58 CET] <furq> given that there's no output file
[16:28:05 CET] <Zuu> when i said 'filter' i mean the english non-video-topic-specific meaning
[16:28:16 CET] <Zuu> which is why i corrected it
[16:28:21 CET] <furq> select is a video filter
[16:28:36 CET] <Zuu> anywho, i will try that lavfi thing
[16:28:57 CET] <Zuu> but im afraid it will bork when my filenames are wird with spaces or whatever
[16:29:33 CET] <furq> just quote everything after lavfi in that case
[16:30:47 CET] <Zuu> ffprobe -show_frames -f lavfi amovie="TestContent/LG Dolby Comparison 4K Demo.ts",select=1  results in a whole heap of red error output
[16:31:20 CET] <Zuu> two last lines: [lavfi @ 00000176be9c3660] Cannot create the link amovie:0 -> select:0
[16:31:24 CET] <Zuu> amovie=TestContent/LG Dolby Comparison 4K Demo.ts,select=1: Invalid argument
[16:33:21 CET] <furq> sorry, that should be movie, not amovie
[16:33:37 CET] <furq> movie,select for video, amovie,aselect for audio
[16:35:25 CET] <Zuu> Ah! ok, now something happens :D
[16:35:42 CET] <furq> i checked and select=0 is no faster than select=1
[16:37:25 CET] <Zuu> i get loads of extra output with that lavfi thing
[16:38:39 CET] <Zuu> thousands of lines like this: [hevc @ 000001a40892e660] Skipping NAL unit 62
[16:38:53 CET] <Zuu> interleaved into the otherwise useful output i want
[16:40:50 CET] <Zuu> well, i take that back, its not interleaved, it's only just that
[16:43:38 CET] <Zuu> ah, no, it is interleaved, i just confused myself
[16:53:07 CET] <Zuu> im not having much luck with this... all i want is to extract all times of keyframes, and it's not going too well :/
[16:54:13 CET] <Zuu> -skip_frame nokey works super well for some stuff, but for say .ts files it doesnt work at all, and still lists a whole bunch of non-key frames
[17:04:44 CET] <furq> if your only issue is that you get error output then add -v quiet
[17:04:48 CET] <furq> or redirect stderr
[17:04:56 CET] <furq> the show_frames output is on stdout so that won't be affected
[17:05:21 CET] <furq> if it's still reporting non-keyframes then maybe remux to mkv or something in advance
[19:56:53 CET] <Zuu> it just seems to me, that pretty much all media players can seek instantly to any position within these files.
[19:57:37 CET] <Zuu> i dont understand why ffprobe takes so long to tell me the information a mediaplayer essentially needs to do that seek
[20:13:58 CET] <Zuu> it looks a lot to me, like ffprobe does full decoding, even though i just want to drump the keyframe index
[20:14:52 CET] <JEEB> you should be able to get that with just -show_packets if the container flags random access points
[20:14:56 CET] <JEEB> instead of -show_frames
[20:15:00 CET] <JEEB> -show_frames actually decodes
[20:15:39 CET] <kepstin> that said, I don't think there's any ffprobe options that just dump the seek index (for formats that have one, of course, mpeg-ts doesn't)
[20:16:01 CET] <Zuu> right now im testing on an mkv file
[20:19:07 CET] <Zuu> also, even with a ts file vlc can seek in a fraction of a second
[20:19:23 CET] <Zuu> but maybe it does some guessing :-/
[20:20:23 CET] <JEEB> the best you can do with MPEG-TS is just seek to a byte range and hope for the best (blu-ray MPEG-TS does have extra timestamp fields after each packet, but you get to those after you've once seeked so it's kind of unlikely VLC uses those)
[20:20:25 CET] <Zuu> however, even with the -show_frames removed, and adding -show_packets the output is still super slow, i dont percieve any speed difference
[20:20:56 CET] <kepstin> yeah, with an mpeg-ts file, you'd probably seek by doing a binary search through the stream, each step syncing and then looking at the timestamp - and it breaks down horribly if there's discontinuities.
[20:21:11 CET] <JEEB> kepstin: https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png
[20:21:14 CET] <JEEB> you remind me of this
[20:21:42 CET] <Zuu> also, let me be clear, that im using ffprobe on an mkv file now
[20:21:50 CET] <JEEB> yes, you have mentioned that already
[20:22:02 CET] <JEEB> also -show_packets being as slow as -show_frames sounds really weird
[20:22:17 CET] <JEEB> since it's just parsing the file (and it depends on the container how much reading it's actually doing)
[20:22:26 CET] <JEEB> it's not decoding the actual stuff within the packets
[20:22:29 CET] <Zuu> i can see the timestamps of the keyframes appear in the output somewhat in "realtime"
[20:22:58 CET] <Zuu> theres roughly a keyframe every second, and i see one line appear roughly every second
[20:23:00 CET] <kepstin> I mean, if you're limited by disk io rather than decode speed, that could be the case.
[20:23:10 CET] <JEEB> that is either massive bit rate (like really, really massive), or you've got some other option there enabling decoding. or you're IO bound.
[20:23:26 CET] <JEEB> first and last are same thing for different reasons
[20:23:44 CET] <Zuu> 120-130 MB/s equential read on disk drive
[20:23:58 CET] <kepstin> and how big is the video file?
[20:24:24 CET] <furq> Zuu: are you still using select instead of skip_frame nokey
[20:24:29 CET] <Zuu> 26GB
[20:24:54 CET] <Zuu> furq, i tried all four combinations of those two
[20:25:24 CET] <JEEB> ok, if you're using some other parameter that enables decoding then show_packets isn't going to help you :P
[20:25:37 CET] <furq> yeah don't use lavfi at all
[20:25:39 CET] <JEEB> although show_packets is enable in containers which mark random access points
[20:25:41 CET] <furq> i did say it would be slower
[20:25:52 CET] <JEEB> gah
[20:25:54 CET] <JEEB> that came out weird
[20:26:07 CET] <Zuu> :)
[20:26:22 CET] <JEEB> anyways, if you just want to know your random access points then show_packets is enough if you are using containers that mark random access points
[20:26:29 CET] <kepstin> Zuu: a file that big, and a disk that speed, the *fastest* it could go is to scan the entire file length in about 5 minutes.
[20:26:55 CET] <Zuu> when i dont use the lavfi i get all frames, not just keyframes
[20:27:02 CET] <furq> shrug
[20:27:14 CET] <furq> just -skip_frame nokey works as expected here with a dvb-t2 ts
[20:28:42 CET] <Zuu> this commandline: ffprobe.exe -show_packets -show_entries frame=key_frame,pkt_pts_time -select_streams v -print_format json=c=1 -skip_frame nokey -i "some.mkv"
[20:28:50 CET] <Zuu> gives me infor for all frames
[20:30:39 CET] <kepstin> Zuu: -skip_frame operates on the decoder, so you'd have to use -show_frames instead of -show_packets for it to take effect.
[20:30:40 CET] <Zuu> The fastest output i can get is with this: ffprobe.exe -show_packets -show_entries frame=key_frame,pkt_pts_time -select_streams v -print_format json=c=1 -f lavfi "movie=some.mkv,select=key"
[20:30:58 CET] <Zuu> but even this, is super slow
[20:31:06 CET] <furq> yeah show_frames works as expected
[20:31:09 CET] <Zuu> kepstin, i see
[20:31:16 CET] <furq> it's still not quick
[20:31:26 CET] <furq> it took about 2m30 on a 59m 1080i file
[20:31:30 CET] <Zuu> yeah, its only just a smidge faster than realtime
[20:31:33 CET] <DHE> printing the stats is not the hard part. it's the decoding of all frames
[20:31:36 CET] <furq> but the box it's running on isn't the quickest
[20:32:20 CET] <furq> there's no way -skip_frame nokey -show_frames should only be slightly faster than realtime
[20:33:04 CET] <kepstin> unless your 26gb video file is only 5 minutes long.
[20:33:14 CET] <Zuu> ok, its obvious i want fast output, what do you sugest?
[20:33:14 CET] <kepstin> but I dunno how you'd manage that :/
[20:33:38 CET] <Zuu> i can copy that file in place in 3 minutes and 30
[20:34:21 CET] <kepstin> Zuu: how long does running that command take *in total*? I.e. how much slower is it actually than disk speed?
[20:34:27 CET] <furq> what OS is this
[20:34:33 CET] <Zuu> am i wrong if im guessing that it should be possible to traverse just the timestamps of the keyframes by reading far less data than the full content?
[20:34:41 CET] <kepstin> furq: mentioned ffprobe.exe, so must be windows
[20:35:04 CET] <furq> is it faster if you redirect the output to a file
[20:35:07 CET] <furq> cmd.exe is legendarily slow
[20:35:20 CET] <Zuu> furq, one console line per second, is what i get now
[20:35:30 CET] <furq> oh
[20:35:31 CET] <furq> nvm then
[20:36:01 CET] <Zuu> as i say, a key frame per second in the video file, and i get those lines in only just a smidge faster than realtime
[20:36:25 CET] <furq> shrug
[20:36:27 CET] <furq> http://vpaste.net/KC9Y2
[20:36:30 CET] <furq> all i can tell you is this
[20:36:42 CET] <Zuu> so the total time it would take to get the full output would be projected to be 1h and 43mins
[20:37:21 CET] <Zuu> and i can copy the file in place in less than 4 minutes
[20:37:52 CET] <JEEB> then you're either requesting actual decoding in some way, or something weird-ass is happening :P
[20:38:04 CET] <Zuu> i gave you the full command line
[20:38:53 CET] <Zuu> i mean, can any of you propose me a command line, a full one, to try?
[20:38:59 CET] <Zuu> what should be the fastest?
[20:39:02 CET] <furq> the one i just pasted
[20:39:15 CET] <Zuu> ok, i try
[20:39:18 CET] <furq> you can redirect to NUL on windows iirc
[20:39:23 CET] <Zuu> indeed
[20:39:24 CET] <JEEB> yes
[20:39:24 CET] <furq> instead of /dev/null
[20:39:28 CET] <JEEB> NUL instead of /dev/null
[20:39:57 CET] <furq> i assume windows has no equivalent of time
[20:41:12 CET] <furq> http://www.pc-tools.net/win32/ptime/
[20:41:14 CET] <furq> maybe that
[20:41:18 CET] <furq> or just get a stopwatch out
[20:41:23 CET] <kepstin> hmm. that command looks like it's bottlenecked mostly on the time decoding the keyframes :/
[20:41:32 CET] <kepstin> so with a shorter keyframe interval, it'll run slower
[20:42:21 CET] <Zuu> furq, i redirected to actual file, and waited 10 seconds, the output has only gotten to time 18
[20:42:32 CET] <Zuu> Also, it output _all frames_ not just keyframes
[20:42:51 CET] <kepstin> making it multithreaded (adding -threads N with some reasonable value of N) should help, if the decoder supports it
[20:43:06 CET] <Zuu> but i dont want to decode :(
[20:43:25 CET] <Zuu> i just want keyframe times
[20:44:29 CET] <furq> if that command is outputting non-keyframes then something wonky is going on
[20:44:32 CET] <furq> as i said, it works fine here
[20:44:49 CET] <Zuu> so i cant possibly fix that wonkyness?
[20:44:53 CET] <furq> i have no idea
[20:45:05 CET] <Zuu> i just downloaded the most recent stable version from the website
[20:45:34 CET] <furq> what codec is this
[20:45:52 CET] <kepstin> Zuu: honestly, just run "ffprobe -show_packets -select_streams v -print_format json=c=1 -i input.mkv" and then process the output to remove lines that don't have "flags": "K_"
[20:45:59 CET] <kepstin> that should run disk speed
[20:46:09 CET] <Zuu> furq, HEVC
[20:46:25 CET] <kepstin> Zuu: the thing slowing you down was the -show_entries frame=key_frame which triggered the decoder
[20:46:31 CET] <Zuu> kepstin, i just did, by copying the file, 130 MB/s
[20:47:09 CET] <Zuu> argh, i have to take the phone...
[20:47:22 CET] <furq> i would hope skip_frame nokey works with hevc but maybe it doesn't
[20:47:30 CET] <furq> that would also explain why decoding is so slow
[20:47:47 CET] <furq> i'm guessing this is 4k given the filesize
[20:48:54 CET] <kepstin> on linux, i'd say run this: ffprobe -show_packets -select_streams v -print_format json=c=1 -i video-h265-veryslow.mp4 | grep -v '"flags": "__"'
[20:49:04 CET] <kepstin> that's fast, it gives the info you want.
[20:49:08 CET] <kepstin> dunno how to do that on windows.
[20:49:25 CET] <tomtomb> Hello all, I could really use your help..
[20:49:47 CET] <furq> presumably it's -skip_frame that triggers the decoder, given that it's a decoder option
[20:49:59 CET] <kepstin> furq: no, it's the -show_entries frame=key_frame
[20:50:05 CET] <furq> your command runs in 41s on that file
[20:50:07 CET] <kepstin> since that asks for frame metadata
[20:50:15 CET] <furq> which is way faster
[20:50:34 CET] <kepstin> tomtomb: I'm afraid my crystal ball is out of commission, you might have to actual say what you need help with.
[20:50:56 CET] <tomtomb> kepstin, wow, that's disappointing... :)
[20:51:26 CET] <tomtomb> I have an mxf file with 8 audio streams, I want to convert it to stereo so that streams 1,3,5,7 would be the left channel of the stereo, and 2,4,6,8 for the right one.. I tried with amerge (merge all 8 channels, without splitting to left/right) ffprobe says the stream is 7.1
[20:52:11 CET] <tomtomb> how do I tell it to merge the audio to a single channel?
[20:52:15 CET] <furq> you'd need amerge and pan
[20:52:20 CET] <furq> !filter pan @tomtomb
[20:52:20 CET] <nfobot> tomtomb: http://ffmpeg.org/ffmpeg-filters.html#pan-1
[20:52:51 CET] <kepstin> tomtomb: amerge to combine the individual audio streams to a single multi-channel audio stream, then pan to downmix the channels.
[20:53:42 CET] <furq> alternatively you could amix the odd ones, amix the even ones, and then amerge those
[20:53:51 CET] <furq> that might be easier
[20:54:15 CET] <tomtomb> amix? need to look it up, thanks!
[20:54:21 CET] <furq> !filter amix @tomtomb
[20:54:21 CET] <nfobot> tomtomb: http://ffmpeg.org/ffmpeg-filters.html#amix
[20:54:33 CET] <furq> i believe it'll have the same channel layout as the input but i might be wrong
[20:54:52 CET] <furq> i assume you have eight mono streams so that should be fine
[20:56:35 CET] <furq> -filter_complex "[a:0][a:2][a:4][a:6]amix=4[left];[a:1][a:3][a:5][a:7]amix=4[right];[left][right]amerge"
[20:56:39 CET] <furq> something like that
[21:15:08 CET] <tomtomb> No channel layout for input 1, The following filters could not choose their formats: Parsed_amerge_2... makes any sense?
[21:17:01 CET] <durandal_1707> tomtomb: insert aformat=channel_layouts=PICK_LAYOUT, before every input to amerge filter
[21:32:00 CET] <furq> tomtomb: that's just a warning, it should still work
[21:32:24 CET] <furq> oh nvm that's a different message
[21:36:42 CET] <tomtomb> -filter_complex "[0:1][0:3][0:5][0:7]amix=inputs=4[left];[0:2][0:4][0:6][0:8]amix=inputs=4[right];[left]aformat=channel_layouts=mono[left2];[right]aformat=channel_layouts=mono[right2];[left2][right2]amerge=inputs=2[stereo]" -map "[stereo]"..
[21:36:43 CET] <tomtomb> phew...
[21:43:31 CET] <furq> you can just do amix=4,aformat=channel_layouts=mono
[21:43:38 CET] <furq> too late now though
[21:44:32 CET] <furq> i'm guessing at least one of your input streams isn't mono
[21:48:19 CET] <tomtomb> furq, I have one stream with 8 mono channels
[21:48:39 CET] <tomtomb> furq, amix=4,aformat=channel_layouts=mono seems to be working great too, thanks!
[22:19:39 CET] <Zuu> kepstin, that does it indeed!
[22:20:00 CET] <Zuu> this one you pasted: ffprobe -show_packets -select_streams v -print_format json=c=1 -i video-h265-veryslow.mp4 | grep -v '"flags": "__"'
[22:20:16 CET] <JEEB> not sure you need the -i with ffprobe, but
[22:20:17 CET] <JEEB> *btw
[22:20:34 CET] <Zuu> Less than 3 minutes, so definitely not decoding anything too much :D
[22:20:38 CET] <JEEB> and yes, that looks quite a bit closer to the command lines I utilize
[22:27:39 CET] <Zuu> but that still gives me all frames actually, i just noticed
[22:27:53 CET] <Zuu> so it seems like it still runs through the entire file
[22:28:09 CET] <Zuu> i think i got happy a bit too quickly
[22:28:13 CET] <kepstin> Zuu: the ffprobe command gives all the frames
[22:28:21 CET] <JEEB> well yes, it gives you all *packets*
[22:28:31 CET] <Zuu> i only want info on keyframe packets
[22:28:36 CET] <kepstin> Zuu: that's why i pipe the output through grep, which removes the packets that don't have the keyframe flag set
[22:28:38 CET] <JEEB> just limit it after the thing
[22:28:54 CET] <JEEB> since you are not going to be able to limit the parsing and at this point IO is your limiting factor most likely
[22:29:03 CET] <kepstin> Zuu: anything with "flags": "K_" is a keyframe, just filter it yourself somehow
[22:29:06 CET] <Zuu> but for my purpose i decidedly want info only on keyframe packets to do it much  much faster than reading the entire file
[22:29:06 CET] <JEEB> write a simple python script parsing the JSON script or something :P
[22:29:21 CET] <JEEB> Zuu: you're not going to get that
[22:29:29 CET] <JEEB> and at this point as I mentioned you're most likely IO bound
[22:29:43 CET] <JEEB> and you're not going to be parsing any less with libavformat
[22:29:50 CET] <kepstin> Zuu: there is no way to get keyframes on mpegts faster than reading the entire file. And ffmpeg doesn't come with any tools to read the indexes in other formats for outside consumption.
[22:29:51 CET] <Zuu> but VLC certainly dont read the entire file up to say time 1h just to seek to that position
[22:29:58 CET] <JEEB> and neither does lavf
[22:30:05 CET] <JEEB> you can seek in the API if you really want
[22:30:13 CET] <kepstin> Zuu: getting a list of keyframes and seeking are different things.
[22:30:25 CET] <JEEB> just that you can't be sure in all containers if you get where you want :P
[22:30:32 CET] <Zuu> ok, what can i do to just dump the seeking information then?
[22:31:22 CET] <kepstin> Zuu: ffmpeg doesn't ship with any tools that do that. I don't know if libavformat provides that in a way that you can build a custom tool.
[22:31:39 CET] <JEEB> can't do that as far as I know since access to a possible index - if available in a format - is not in the API
[22:31:42 CET] <JEEB> you can seek just fine
[22:31:56 CET] <JEEB> and it will internally have an index if such exists in the demuxer
[22:32:03 CET] <JEEB> but I'm pretty sure that isn't exported
[22:32:29 CET] <JEEB> if you are specifically working with some container you can utilize things like mkvinfo etc
[22:32:30 CET] <kepstin> Zuu: so it sounds like you'd have to find or write a format-specific tool to read the seek index (if present)
[22:32:52 CET] <JEEB> although I think mkvinfo will seek through teh full thing?
[22:32:53 CET] <JEEB> no idea
[22:33:01 CET] <Zuu> well, i can call ffprobe once for every second of a file
[22:33:22 CET] <Zuu> seeking 2000 times, and then dump the first frame
[22:33:31 CET] <JEEB> anyways, I would recommend just sharing what you actually want to do
[22:33:38 CET] <kepstin> Zuu: that would certainly be much slower than scanning the file with ffprobe to dump all the packet info, then filtering out keyframes
[22:33:40 CET] <JEEB> as in the end thing
[22:33:45 CET] <Zuu> just a ridiculous way of doing it, but it certinaly proves that i dont need any format specifics to do it with ffprobe
[22:34:18 CET] <JEEB> well 2000 is most likely less than the amount of random access points in a 26 gig file
[22:34:26 CET] <JEEB> but hey, what do I know
[22:34:35 CET] <Zuu> kepstin, slower, because it hasnt built it in. but i would end up reading much much muuuuch less of the file
[22:36:12 CET] <Zuu> the slowness comes from the repeated parsing of meta, if anything... maybe i can just adapt ffprobe to seek in the same meta throughout the file, and dump the first keyframes it encounters after every seek
[22:36:42 CET] <JEEB> the "slowness" just comes from the fact that the API is built around packet access
[22:36:54 CET] <JEEB> so you have functionality to seek, and to read packets
[22:37:25 CET] <JEEB> I do agree that it might be in some way useful to export the information off of an index in a file, but I don't think we have an interface for that separately
[22:37:28 CET] <kepstin> if you're gonna program a custom tool, and you're dealing with formats that have a seek index, then you'd want to just make a tool that finds and dumps the seek index. You could maybe even do it by hacking ffmpeg to throw some print statements in the demuxer :/
[22:37:41 CET] <Zuu> that's fine, i will just seek one second forwards, dump, seek, dump, seek, ...
[22:38:00 CET] <JEEB> just use the API then, most likely will be more optimal
[22:38:22 CET] <JEEB> open an avformat context, start reading etc
[22:38:56 CET] <Zuu> JEEB, avformat is a concept in the lib?
[22:39:05 CET] <JEEB> libavformat is one of the libraries in FFmpeg
[22:39:14 CET] <JEEB> it handles IO and demuxing/muxing
[22:39:22 CET] <Zuu> alright
[22:39:32 CET] <kepstin> Zuu: yeah, a program that just opens the file and calls av_seek_frame() with appropriate flags could probably do that reasonably well.
[22:39:47 CET] <Zuu> i guess will have to hack together a new tool then :)
[22:39:48 CET] <kepstin> no clue if it would actually be any faster than just reading the whole file
[22:40:10 CET] <JEEB> in files with indices it can be since you can just tell it to seek to the closest random access point
[22:40:39 CET] <JEEB> (just be warned that by default it goes forwards compared to the timestamp you've noted, not to the closest one before it)
[22:40:52 CET] <Zuu> thats what i want, all random access points (i thought they just happened to all be aligned with keyframes)
[22:40:53 CET] <JEEB> (there's a specific flag you have to give it to seek to the closest random access point before the point)
[22:41:03 CET] <Zuu> which is why i started out wanting to dump all the keyframes
[22:41:29 CET] <JEEB> Zuu: well the index isn't exported, you just have an interface to seek to timestamp X
[22:41:40 CET] <Zuu> sounds cool, JEEB. just what i am looking for :)
[22:41:50 CET] <Zuu> i get it
[22:42:02 CET] <Zuu> i have to build a new tool thing
[22:42:14 CET] <Zuu> i just hoped it was part of what ffprobe already did
[22:42:32 CET] <Zuu> especially with all the skip-nonkey stuff
[22:43:01 CET] <JEEB> generally people are OK with going through the full file with a demuxer, esp. since various formats work really badly with seeking
[22:43:15 CET] <JEEB> as in, that gives you constant results
[22:43:28 CET] <JEEB> then you of course have formats where if you have the index you have all the knowledge
[22:44:08 CET] <Zuu> but one of the guys said something like mpeg-ts didnt have indexes for instance, but when i play with VLC i have zero issues seeking to wherever
[22:44:16 CET] <JEEB> you get close to X
[22:44:24 CET] <kepstin> yes, you can seek in mpegts. NO, it does not have an index
[22:44:25 CET] <JEEB> and you probably get to the same place
[22:44:39 CET] <JEEB> basically the best thing you can try with MPEG-TS is to seek byte-wise
[22:44:42 CET] <JEEB> since it has no index
[22:44:53 CET] <Zuu> but seeking to a spot in a multigigabyte file definitely doesnt dead the entire file
[22:44:58 CET] <JEEB> of course not
[22:45:03 CET] <Zuu> *read
[22:45:05 CET] <JEEB> but to get an exact index of it
[22:45:08 CET] <JEEB> to seek exactly to point X
[22:45:13 CET] <JEEB> instead of "close to point X"
[22:45:24 CET] <JEEB> you need to index it
[22:45:27 CET] <Zuu> ok, so we are just dealing with guesses
[22:45:31 CET] <JEEB> yup
[22:45:51 CET] <Zuu> i presume ffprobe currently would do the same kind of guessed if asked to seek to a time?
[22:45:52 CET] <kepstin> if you have an mpeg-ts file with no timestamp discontinuities, you can do a sort of "guess and check" thing with seeking, sort of like a binary search
[22:46:00 CET] <Zuu> *guesses
[22:46:21 CET] <JEEB> kepstin: discontinuities are exactly why you want to deal with bytes :D
[22:46:27 CET] <kepstin> ffmpeg (and all other tools using libavformat) will attempt to seek in mpegts, yes. Results vary depending on how the timestamps are arranged in the file.
[22:46:47 CET] <Zuu> that's good enough for me :D
[22:46:51 CET] <JEEB> yes, I wrote a small app that exports the first decode'able frame after a seek for testing
[22:46:59 CET] <JEEB> that was extremely fun with MPEG-TS
[22:47:09 CET] <Zuu> imperfect input gives imperfect output, thats just part of life
[22:47:15 CET] <JEEB> glad you understand :)
[22:47:20 CET] <kkkist> is there any way to make every frame of a video into separate 1 second video of that frame?
[22:47:21 CET] <JEEB> and after all, MPEG-TS was made for broadcast
[22:47:31 CET] <kepstin> with mpegts, you just read until you sync, then read until you get an idr frame :/
[22:47:39 CET] <JEEB> yup
[22:47:46 CET] <JEEB> wait for that magical 0x47 byte
[22:48:22 CET] <JEEB> and then read 188 byte packets to first get "what programs are here", then "what streams there are in this program" and finally you get the first random access point :P
[22:48:37 CET] <Zuu> eeek
[22:48:49 CET] <kepstin> kkkist: there are lots of ways, but they will typically involve writing some sort of script that runs ffmpeg commands.
[22:49:07 CET] <JEEB> Zuu: but yea, MPEG-TS is a thing that was meant to be received A->B and read by a receiver :D
[22:49:12 CET] <JEEB> not exactly best thing for seeking
[22:49:12 CET] <Zuu> first time i ran into that program thing, i had no idea what was going on
[22:49:34 CET] <Zuu> i mean, i just played a recording in VLC, and it wasnt the channel i actually recorded
[22:49:36 CET] <kkkist> kepstin what command would that be (that has to be looped)?
[22:49:53 CET] <JEEB> Zuu: yea, you often have multiple programs in a single stream
[22:50:33 CET] <Zuu> JEEB, now i quite like it, because... you know, you can record more things at once with one tuner :D
[22:50:52 CET] <JEEB> so you first get a packet that says "we have program 1337, program 22414, and program 2304 in this stream. see packets with ID X, Y, Z for indexes on which packet IDs are what streams on those programs"
[22:51:00 CET] <kepstin> heh, if you're not using all the bits possible in the frequency range you own, then you're just wasting them with padding, right? :)
[22:51:20 CET] <Zuu> :)
[22:51:33 CET] <Zuu> i did not consider it like that at all, makes perfect sense
[22:52:54 CET] <JEEB> also MPEG-TS is lovely dynamic. you can just send stream mappings for a program again and again. I even have samples with the video stream switching completely to another stream :)
[22:52:59 CET] <Zuu> JEEB, i've actually had some TV tuner software that mixed up the sounds among the video streams actually
[22:53:15 CET] <Zuu> super annoying
[22:53:36 CET] <JEEB> I've only had that with software that doesn't understand dual mono
[22:53:44 CET] <JEEB> which ends up rather... bizarre
[22:54:03 CET] <JEEB> for example I have a stream where there's a single stereo track of AAC
[22:54:10 CET] <Zuu> dual mono? like a stereo track that's intended to be split?
[22:54:11 CET] <JEEB> but the content is split into two tracks
[22:54:14 CET] <JEEB> yes
[22:54:29 CET] <JEEB> so if you decode and play it as normal stereo you get commentary on your right ear
[22:54:35 CET] <JEEB> and normal sports audio on the left
[22:54:36 CET] <Zuu> that does sound super crazy
[22:55:10 CET] <Zuu> do you even win anything encoding wise by not just have two normal seperate mono tracks?
[22:55:24 CET] <JEEB> no idea
[22:55:30 CET] <JEEB> dual mono generally seems to be rare
[22:57:06 CET] <Zuu> oh well, i think i will have a play with the libavformat
[22:57:24 CET] <JEEB> the basics are seen @ http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/demuxing_decoding.c;h=69a31a893519cdb91bd1f39cad6b7df02b160e59;hb=HEAD#l251
[22:57:29 CET] <Zuu> Thanks a lot to all of you for all the help :)
[22:57:45 CET] <JEEB> open input, maybe call find_stream_info
[22:57:52 CET] <JEEB> then world's your oyster
[22:58:13 CET] <Zuu> ooh nicey!
[22:58:18 CET] <JEEB> there's an API for seeking and then of course "av_read_frame()"
[22:58:25 CET] <JEEB> which IMHO is rather misnamed
[22:58:29 CET] <JEEB> because it gives you a packet
[22:58:35 CET] <JEEB> buut hey, old things
[22:59:06 CET] <Zuu> yeah a frame of data, not a frame of video, i get it
[22:59:18 CET] <JEEB> it even gets you something called an AVPacket
[22:59:18 CET] <JEEB> lol
[22:59:24 CET] <Zuu> hehe
[22:59:46 CET] <JEEB> I think in all of my newer code I've just written a wrapper around it which is called read_packet() or something
[22:59:49 CET] <JEEB> so I don't confuse myself
[23:00:41 CET] <JEEB> also another protip
[23:01:02 CET] <JEEB> av_parse_time(&timestamp, argv[3], 1)
[23:01:12 CET] <JEEB> timestamp being a pointer to a int64_t
[23:01:37 CET] <JEEB> (if you want to take stuff from command line, that is)
[23:01:50 CET] <JEEB> (and yes, I should use getopt or something)
[23:02:27 CET] <Zuu> oh, a text based time in argv[3]? parsed to int64_t
[23:02:33 CET] <JEEB> yup
[23:02:50 CET] <Zuu> will probably come in handy during testing at least
[23:03:12 CET] <JEEB> it supports all the fancy stuff like 00:01:00.000 but I just used it for SEC.MSEC
[23:03:18 CET] <JEEB> and that was the simplest way of getting it :D
[23:03:35 CET] <Zuu> the timestamps are in millisecs, right?
[23:03:39 CET] <JEEB> no
[23:03:42 CET] <Zuu> the int64_t
[23:03:44 CET] <Zuu> no?
[23:03:44 CET] <JEEB> ah
[23:03:50 CET] <JEEB> you get AV_TIME_BASE
[23:03:52 CET] <JEEB> out of that one
[23:03:56 CET] <Zuu> ah
[23:03:58 CET] <JEEB> which is like microseconds or so?
[23:03:59 CET] <JEEB> not sure
[23:04:13 CET] <JEEB> then you scale that into the time base of the stream you are interest in
[23:04:45 CET] <JEEB> av_rescale_q(timestamp, AV_TIME_BASE_Q, input_ctx->streams[picked_stream_idx]->time_base);
[23:05:18 CET] <JEEB> that gets your timestamp from AV_TIME_BASE_Q (which is what av_parse_time returns) to the picked stream's time base
[23:05:28 CET] <JEEB> (and it returns you the scaled timestamp)
[23:06:24 CET] <JEEB> and then av_seek_frame(input_ctx, picked_stream_idx, rescaled_timestamp, AVSEEK_FLAG_BACKWARD)
[23:06:28 CET] <JEEB> does the seek
[23:07:04 CET] <JEEB> AVSEEK_FLAG_BACKWARD tells it you want the closest thing *before* that point which is a random access point (if possible)
[23:07:21 CET] <JEEB> by default it will just pick the cloest from both sides? not sure
[23:07:50 CET] <JEEB> and if you want more info/docs on these functions I just noted
[23:08:02 CET] <JEEB> site:ffmpeg.org doxygen trunk KEYWORD
[23:08:07 CET] <JEEB> is what has helped me a lot
[23:08:30 CET] <JEEB> (Even though my editor has started showing me the documentation doxygen in the editor lately)
[23:12:18 CET] <Zuu> Wow, that is super nice JEEB :D
[23:12:56 CET] <Zuu> really good hints :)
[23:13:35 CET] <Zuu> i almost feel like i can throw something together in no time with all those hints.... buuut it always takes longer than i think :)
[23:21:56 CET] <kepstin> by default, i believe it will find the closest keyframe after or on your seekpoint
[23:22:11 CET] <JEEB> yea
[23:22:21 CET] <JEEB> that's why you need the FLAG_BACKWARD to get the previous
[23:23:39 CET] <kepstin> so if you just want to find all the seekpoints, I'd say don't use backwards. First seek to 0, then read a packet, then seek to the pts from that +1, and repeat
[23:23:54 CET] <kepstin> each time it should jump to the next seekpoint
[23:24:55 CET] <kepstin> (maybe use backwards seek on the first one to handle weird negative timestamps ;)
[00:00:00 CET] --- Tue Mar 13 2018