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

[burek]

[00:06:09 CEST] <nyuszika7h> I have multiple WebVTT subtitles in a m3u8 playlist, how do I get ffmpeg to merge them into one file without repeating the WebVTT header, and delay each subsequent file appropriately as they all restart time codes from 00:00?
[00:06:53 CEST] <nyuszika7h> https://i.imgur.com/hY7x5a9.png
[00:07:22 CEST] <nyuszika7h> hmm that output file is not even all of the subtitles
[00:07:38 CEST] <klaxa> mux the individual files first to video + sub then concat the individual files?
[00:08:32 CEST] <nyuszika7h> well I only have one video since it's from a different source
[00:08:55 CEST] <nyuszika7h> can't get the video from where I got the subtitles because I'm missing the decryption key
[00:09:14 CEST] <nyuszika7h> (and that's a separate playlist anyway)
[00:26:08 CEST] <nyuszika7h> I've got all the files now, trying -f concat but it gives me an error
[00:26:12 CEST] <nyuszika7h> [webvtt @ 000000000246ca40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 41 >= -102481816076876
[00:26:52 CEST] <nyuszika7h> https://ptpb.pw/Ja0-
[00:28:25 CEST] <c_14> Use the concat protocol
[00:29:22 CEST] <c_14> That's the -i concat:foo|bar one
[01:47:54 CEST] <Phi> alright, anyone know anything about h264?
[01:48:54 CEST] <Phi> well not him
[01:50:30 CEST] <Phi> not him either
[02:00:17 CEST] <DHE> can you be more specific?
[02:00:46 CEST] <DHE> I know a number of things as long as I don't have to decode the raw bits (yet)
[02:02:32 CEST] <bibble> what abouts it ? :D
[02:03:02 CEST] <bibble> think it's closed source
[02:05:49 CEST] <bibble> libebml v1.3.1 + libmatroska v1.4.2 Duration: 00:22:09.17, start: 0.000000, bitrate: 5058 kb/s Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709), 1916x1076 [SAR 1:1 DAR 479:269], 23.98 fps, 23.98 tbr, 1k tbn, 2k tbc (default)
[02:06:10 CEST] <bibble> for some reason, I can't resize this mkv
[02:06:32 CEST] <bibble> can use -s 640:380, but not -vf scale=640:-1
[02:07:04 CEST] <bibble> strange
[02:07:08 CEST] <furq> 640:-2
[02:07:18 CEST] <bibble> hmm, interesting
[02:08:17 CEST] <bibble> furq: you're a genius !!
[02:08:27 CEST] <bibble> don't understand it though
[02:08:59 CEST] <bibble> what's the difference between -1 & -2 ?
[02:09:42 CEST] <bibble> oh.. 380 bound box, rather than 640
[02:11:16 CEST] <bibble> nope, still don't get it :)
[02:11:40 CEST] <bibble> but working wonderfully...
[02:18:21 CEST] <Phi> the issue is the timing on my video
[02:18:49 CEST] <Phi> I have an RTSP stream, I want to read timing info from it and output to a video
[02:19:23 CEST] <Phi> output playing at normal speed, basically, framerate not really relevant as long as it's the same visual speed
[02:20:58 CEST] <Phi> I either get a video that plays very slowly, or one that plays one frame and never updates, or one that plays at about 10x speed
[02:21:15 CEST] <Phi> dependent on what I set the codec timebase to (as libx264 requires that be set)
[02:22:24 CEST] <Phi> the input is a variable framerate, so I'm not sure what I should do with packet dts/pts
[02:22:29 CEST] <Phi> if I do nothing it breaks :p
[02:26:10 CEST] <kepstin> bibble: that video is using yuv420p, which is a subsampled chroma format. Oniy sizes that are multiples of two are allowed. If you do "-vf scale=640:-2", it automatically rounds to a multiple of 2.
[02:27:18 CEST] <bibble> oh, thank you kepstin
[02:45:31 CEST] <Phi> "4 fps, 30 tbr, 90k tbn, 8 tbc"
[02:45:31 CEST] <Phi> what
[03:24:56 CEST] <s0126h> what do you people think about this picture? is this legit?  http://www.flatpanelshd.com/pictures/superpls-1l.jpg
[03:46:29 CEST] <Phi> DHE, I have an MP4 playing at double speed
[03:46:44 CEST] <Phi> it's doing 8 fps although the RTSP goes at ~4fps
[03:49:00 CEST] <DHE> sure you got the time base correct?
[03:49:43 CEST] <Phi> I copy it straight from the RTSP's one
[03:50:07 CEST] <Phi>  	video_file_stream->time_base = rtsp_vidstream->time_base; video_file_stream->codec->time_base = rtsp_vidstream->codec->time_base;
[03:50:33 CEST] <Phi> (before avcodec_open2 on the video file stream)
[03:55:21 CEST] <Phi> I'm showing 4 fps, 30 tbr, 90k tbn, 8 tbc
[03:55:27 CEST] <Phi> all of those copied to destination stream
[04:00:16 CEST] <Phi> any idea DHE?
[04:02:24 CEST] <DHE> rtsp isn't my strong suit. I do most of my work in mpegts
[05:23:14 CEST] <Phi> hmm
[05:23:20 CEST] <Phi> my MP4 isn't seekable, any idea how to fix?
[05:24:29 CEST] <Phi> I tried lowering the gop_size, but that didn't do anything
[05:39:08 CEST] <Phi> what's weirder, if I open the stream in RTSP, I get a still image
[05:40:29 CEST] <Phi> (in VLC)
[06:31:55 CEST] <Phi> I fixed that issue, VLC doesn't like a RTSP with a framerate lower than 6
[06:33:41 CEST] <Phi> now I have a dilemma, if I do a DTS/PTS increment +1 manually, I get a MP4 file that plays at double speed
[06:33:48 CEST] <Phi> but seeking in that file works fine
[06:34:08 CEST] <Phi> if I multiply the PTS by 2, I get a normal speed, but seeking doesn't work at all
[06:34:30 CEST] <Phi> VLC just keeps losing the frames until it hits the end of the file
[09:47:43 CEST] <sopparus> how can I respond ona thread without being registred?
[09:49:49 CEST] <sopparus> jkqxz, peter who made that patch wanted to add this
[09:49:51 CEST] <sopparus> I think this patch from ffmpeg is not good. It works for you but all other users using TLS v1.0 will stay on dry with it because TLS v1.0 is not supported anymore. The problematic line is SSL_CTX_set_options which disables v1.0. Without this line both versions are supported but higher version has precedence (I think). You can write something on ffmpeg ml.
[10:28:01 CEST] <jkqxz> sopparus:  I don't understand what you mean.  SSLv2 and SSLv3 are disabled; TLSv1, TLSv1.1 and TLSv1.2 are not?
[10:28:25 CEST] <sopparus> neither do I, thats that he wrote
[10:29:23 CEST] <sopparus> just tested it, it does indeed work with tls 1.0
[10:29:27 CEST] <sopparus> sorry for noice then
[10:29:28 CEST] <sopparus> :)
[13:33:01 CEST] <nyuszika7h> 00:28:25 <c_14> Use the concat protocol
[13:33:16 CEST] <nyuszika7h> I think that will just concat the files, no? the problem is each subtitle file restarts timing at 00:00
[13:33:55 CEST] <c_14> nyuszika7h: I've used the concat protocol for .srt files and it fixed the timestamps
[13:34:18 CEST] <klaxa> it will remux them into a new file
[13:34:59 CEST] <nyuszika7h> oh nice
[13:35:27 CEST] <nyuszika7h> will try that, though I have a LOT of segments, I wonder if it will cause an argument length error
[13:41:08 CEST] <nyuszika7h> c_14: nope, the output file is still messed up
[13:41:34 CEST] <nyuszika7h> it also repeats the WebVTT header still
[13:42:43 CEST] <nyuszika7h> https://i.imgur.com/yNAqyp4.png
[13:44:02 CEST] <c_14> hmm
[13:45:03 CEST] <nyuszika7h> here's the original m3u8, if that helps: http://content-aeuf2.uplynk.com/82103317c22d4c03a9395d1bee07cdb5/sub3.m3u8
[13:45:44 CEST] <nyuszika7h> they usually also have it as a single TTML but that link is 404 for this episode >_>
[13:53:54 CEST] <c_14> If you only need this done once, it might be easiest to take the output from the concat protocol and use sed or something to delete the WEBVTT header lines
[13:55:51 CEST] <nyuszika7h> wait, I had the segments in the wrong order
[13:58:35 CEST] <nyuszika7h> the time codes are still off though because each segment restarts timestamping at 00:00
[13:58:55 CEST] <nyuszika7h> there are things like X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:95911680 but I can't make sense of those numbers
[14:00:15 CEST] <furq> that doesn't work for me with srt either
[14:03:08 CEST] <c_14> Oh yeah, it just interleaved the subtitles. I never actually tested the subs I just looked at the event numbers
[14:11:51 CEST] <nyuszika7h> trying with mkvtoolnix now, it doesn't offset the timestamps despite the documentation saying it shoukd :/
[14:11:54 CEST] <nyuszika7h> *should
[14:16:07 CEST] <nyuszika7h> okay, this is not even as simple as adjusting the timecodes like that because it gets horribly desynced
[14:16:17 CEST] <nyuszika7h> there's supposed to be an offset somewhere but I can't find where
[14:19:42 CEST] <nyuszika7h> hmm there's an EXT-X-DISCONTINUITY which returns the timestamps relative to the time I request the m3u8 file
[14:20:07 CEST] <nyuszika7h> it also returns the initial date, good
[14:20:19 CEST] <nyuszika7h> I'll try to write a script to handle this
[14:31:32 CEST] <furq> isn't the extinf in the m3u8 the segment duration
[14:37:35 CEST] <nyuszika7h> furq: hmm it might be
[14:37:41 CEST] <nyuszika7h> it's always #EXTINF:4.0107
[14:37:53 CEST] <nyuszika7h> well except the last one
[14:38:05 CEST] <nyuszika7h> that might be helpful too
[14:38:46 CEST] <nyuszika7h> I guess that means if the last subtitle doesn't end at 4.0107 in the segment I need to add a delay, makes sense
[17:42:55 CEST] <Filarius> Hello, pls help with erro while piping raw RGB frames via StdIn http://pastebin.com/q2w5dJ4y
[17:45:26 CEST] <Filarius> I sending data with much lower parts then error show
[17:45:40 CEST] <SouLShocK> why the "n" after -c:a ? are you trying to do -an?
[17:46:38 CEST] <Filarius> well, its was like "this do not works, lets try some shit, oh it works!, oh, I changed something and its stop working"
[17:48:39 CEST] <Filarius> -an same result
[17:49:45 CEST] <Filarius> it make file with about 5600 bytes, looks like just header
[17:56:04 CEST] <SouLShocK> rgb24 does not look like it is a supported pixel format
[17:56:49 CEST] <furq> that's an input option
[17:58:06 CEST] <Filarius> processing of file with same data is works okay, if I just replace "-i -" with "-i rgb.raw"
[17:58:30 CEST] <furq> are you sure the thing you're piping from is working correctly
[17:58:58 CEST] <furq> i guess that's probably where you got rgb.raw from
[17:59:59 CEST] <Filarius> i just wrote my data to file
[18:00:33 CEST] <Filarius> just writing wrapper for ffmpeg on C#
[18:02:57 CEST] <Filarius> I need ise github next time
[18:06:02 CEST] <Filarius> any explain what messages from log means ?
[18:55:15 CEST] <Phi> Well, I fixed my double-speed MP4 issue
[18:55:36 CEST] <Phi> the trick is to do av_rescale_ts() on the packet, then multiply BOTH the output pts/dts by 2
[18:55:53 CEST] <Phi> then you get a normal speed MP4 with seeking and duration working properly
[18:56:04 CEST] <Phi> (oddly doubling packet->duration doesn't appear to do anything)
[18:58:09 CEST] <DHE> depends on the format. and it answers questions like how long to show the last frame on-screen of a video
[19:09:16 CEST] <Phi> I would've thought RTSP H264 -> MP4 H264 wouldn't change that
[19:15:14 CEST] <Phi> I think it happened with the copy thing as well
[19:15:40 CEST] <Phi> the issue with the profile staying High was I was basically taking the received network frame and chucking it at the MP4
[19:16:33 CEST] <Phi> now I have to do "receive network frame, pass to decoder, read frames in loop from decoder and pass each one to encoder, read packets in loop from encoder and pass to MP4
[19:16:37 CEST] <Phi> "
[19:16:42 CEST] <Phi> which is slightly more complicated...
[19:17:05 CEST] <Phi> and not very obvious, since all the examples I saw didn't even mention it
[19:17:35 CEST] <Phi> still weird RTSP H264 -> MP4 H264 makes a double-speed MP4
[19:17:43 CEST] <Phi> but eh, ciao
[21:39:29 CEST] <kerio> something only marginally related to ffmpeg - what's the best way of compressing grayscale 16bpp video?
[21:40:28 CEST] <fritsch> lossless?
[21:40:32 CEST] <kerio> yes
[22:09:02 CEST] <klaxa> ffv1 would be a start at least
[22:27:46 CEST] <Filarius22> I found there is 5 y.o. forum thread about ffv1 not support grayscale 16 bpp pixel format
[22:28:55 CEST] <klaxa> >klaxa at neu ~> ffmpeg --help encoder=ffv1
[22:28:55 CEST] <klaxa> >[...]
[22:28:55 CEST] <klaxa> >    Supported pixel formats: yuv420p yuva420p yuva422p yuv444p yuva444p yuv440p yuv422p yuv411p yuv410p bgr0 bgra yuv420p16le yuv422p16le yuv444p16le yuv444p9le yuv422p9le yuv420p9le yuv420p10le yuv422p10le yuv444p10le yuva444p16le yuva422p16le yuva420p16le yuva444p10le yuva422p10le yuva420p10le yuva444p9le yuva422p9le yuva420p9le gray16le gray gbrp9le gbrp10le gbrp12le gbrp14le ya8 gbrp16le rgb48le
[22:29:24 CEST] <klaxa> gray16le should be 16 bpp
[22:31:54 CEST] <Filarius22> I was curious about "le" part of gray16le, its "little engian", maybe you know it already
[22:45:05 CEST] <klaxa> *little endian
[22:45:19 CEST] <klaxa> it's about byte order, and i never get that right
[22:48:38 CEST] <DHE> x86 is little-endian, so that's a native 'short' type integer on an intel CPU
[22:48:54 CEST] <DHE> it shouldn't matter much if you're just using ffmpeg on the commandline
[00:00:00 CEST] --- Sun Oct 30 2016