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

Sun Nov 4 03:05:02 EET 2018

[00:54:23 CET] <brimestone> Is there an ffmpeg/ffplay wrapper for Swift4 or objective c?
[04:44:34 CET] <grosso> hi
[04:45:12 CET] <grosso> i'm using ffmpeg to receive a rtsp stream, like this: ffmpeg -i 'rtsp://192.168.1.44:8559/live.sdp -c copy output.mkv
[04:46:25 CET] <grosso> the problem is that ffmpeg actually don't save the file until the streaming is stopped from the sending end... it actually don't do anything until streaming is stopped
[04:47:38 CET] <nicolas17> that seems unlikely... where would all the stream be stored meanwhile? in RAM?
[04:49:04 CET] <grosso> I tryed with several different options: to save a file, to save a sequence of pictures, using segments, re-streaming through udp, etc etc etc... in all cases, it just receives the stream (I see that at the sender end) but don't do anything more until streaming stops
[04:49:24 CET] <grosso> yes! it stores it in RAM!!
[04:51:45 CET] <grosso> nicolas17... it's so strange.. I can't make it do anything until stop sending stream... then it saves the files from what I think has to be a large RAM buffer
[04:52:22 CET] <pink_mist> have you tried streaming so much that it won't fit in RAM?
[04:53:20 CET] <nicolas17> how big is the file when you stop it?
[04:54:28 CET] <grosso> well, i do no tryed beyond a minute or two... when working with sequences of pictures, it can deliver 1000 pictures from ram
[04:55:00 CET] <grosso> that actually is 40 seconds
[04:56:08 CET] <grosso> what I think it behaves like the imput was actually a file, rather than a live streaming
[04:56:34 CET] <nicolas17> file size I mean
[04:58:14 CET] <grosso> file size is easy 4mBytes
[04:58:34 CET] <grosso> i don't stressed out
[04:58:43 CET] <grosso> just a minute or so
[04:59:07 CET] <nicolas17> it can buffer data before writing to output file but 4MB seems too much...
[04:59:35 CET] <grosso> it does it..
[05:01:33 CET] <grosso> it don't do anything until streaming stops.. if it could buffer 100MB it will... don't do anything until streaming stops from sender
[05:01:55 CET] <grosso> that's the problem
[05:02:26 CET] <grosso> I can't make it behaves like if a real live streaming
[05:03:09 CET] <grosso> it just behaves like if the input was a file
[05:04:15 CET] <nicolas17> input files don't behave like that either
[05:04:22 CET] <nicolas17> buffering the entire video in memory makes no sense
[05:04:26 CET] <nicolas17> try for longer time?
[05:04:53 CET] <grosso> ok, I can try for longer time
[05:05:03 CET] <grosso> just wait a moment
[05:09:11 CET] <grosso> ok, I just started now
[05:09:21 CET] <grosso> tell me when to stop
[05:10:05 CET] <nicolas17> maybe like 2 minutes to ensure it exceeds 4MB?
[05:10:40 CET] <grosso> ok
[05:10:49 CET] <grosso> it is running now
[05:11:51 CET] <grosso> maybe it just buffer the last 4mb of video...what is for sure is that it don't saved any file so far
[05:12:21 CET] <grosso> so, I stop it?
[05:12:42 CET] <furq> grosso: try setting -rtbufsize
[05:14:00 CET] <grosso> 8MB
[05:15:54 CET] <grosso> rather than limit buffer size, i would like to force it to save files before stream stops
[18:08:46 CET] <gaara4896> Hello, I was trying to compile ffmpeg, and I face this problem. The config.log looks something like this: https://pastebin.com/DUzgv9W6, but libstegolib.so did exists inside the folder
[18:08:50 CET] <gaara4896>                    ffmpeg/lib/libstegolib.so, anyone have any idea what might be the cause?
[18:09:27 CET] <JEEB> not upstream stuff
[18:09:46 CET] <JEEB> please take this to the developers of this specific project
[18:10:01 CET] <JEEB> since stegolib is not part of FFmpeg nor is what you're building part of the standard FFmpeg
[18:10:27 CET] <JEEB> but what it sounds is that you don't have that stegolib thing in your linker search path
[18:10:42 CET] <JEEB> good luck with trying to get support from that project
[18:10:46 CET] <gaara4896> I actually wanted to ask CMake or Make specific problem, not ffmpeg, wondering what IRC channel is related to it?
[18:13:30 CET] <JEEB> gaara4896: no idea. your best bet is to just ask for guidance with that project you are trying to build
[18:17:24 CET] <pink_mist> gaara4896: /msg alis help
[18:17:35 CET] <pink_mist> gaara4896: alis is the freenode bot for channel listing and searching
[19:09:41 CET] <Filarius> hello, would somebody say me is there will be really big difference for encoding time if I take same raw data file and encode it as 1080p source or 4k source, or 480p source ?
[19:10:07 CET] <Filarius> with x264 codec
[19:11:18 CET] <furq> yes
[19:12:45 CET] <tdr> more data or less data to encode = more or less work to do
[19:14:06 CET] <Filarius> just for sure... input file is like just 1Gb raw data( always same for all setings), and only what I change will be making ffmpeg think what resolution it could be, with common settings on x264
[19:14:54 CET] <Filarius> yes, result file will be different at frame count, but in this I only want know what will be with time spent on encoding
[19:15:39 CET] <Filarius> furq, and where it will be faster ?
[19:17:57 CET] <Filarius> I know I ask strang thing, but I talk about it with buddy and its about using ffmpeg in data procedding
[19:18:00 CET] <Filarius> *processing
[19:27:30 CET] <ChocolateArmpits> Filarius, in theory then it shouldn't
[19:27:51 CET] <ChocolateArmpits> unless there's something memory related due to bigger frames
[19:28:56 CET] <ChocolateArmpits> Filarius, you may have to pad it if the data length doesn't stricly match the input settings you will use
[19:29:27 CET] <Filarius> yep, padding added
[19:30:12 CET] <Filarius> just there some stranger found my old "data to video" project so we came to this question
[19:31:26 CET] <ChocolateArmpits> I think there was someone else some time ago who wanted to also lossy compress data as well
[19:32:11 CET] <Filarius> a sent days and nights making DCT data coding as I see simple squares is too stupid ideas, and that dude say me what he prefer version what pack data into b/w squares !
[19:32:27 CET] <Filarius> ***i spent days and nights
[19:33:22 CET] <Filarius> maybe I was here with same question
[19:33:32 CET] <Filarius> 2-3 years ago
[19:33:43 CET] <ChocolateArmpits> nah it was a month or so ago
[19:34:00 CET] <ChocolateArmpits> definitely in the last few months
[19:37:34 CET] <Filarius> well, I have 2 y.o. project on GitHub already made it with Integer Cosinus Transform "stolen" from E264 sources and making error-less coding/decoding best at ~7 bits per 8x8 block yuv420p for case if you want upload it on Youtube (thought testes also like 2 years ago)
[19:40:16 CET] <Filarius> thought shortly ago i was back to project with idea to rewrite to make cross platform and I found pure ICT isn't working so best as I thought before, also made myself a little-little more undertanding how actually x264 works
[20:10:26 CET] <kerio> how do i shove hevc into rtmp?
[20:11:07 CET] <JEEB> you don't
[20:11:09 CET] <JEEB> it's not specified
[20:11:14 CET] <JEEB> go ask Adobe if you need it
[20:11:30 CET] <JEEB> so that it appears in annex E of https://wwwimages2.adobe.com/content/dam/acom/en/devnet/flv/video_file_format_spec_v10_1.pdf
[20:12:06 CET] <JEEB> although adobe really felt like they were going the fragmented mp4 route
[20:12:33 CET] <JEEB> and FLV (which is what is transferred over RTMP) went the way of the dodo
[22:33:23 CET] <M6HZ> Hello, is there a way to extract CEA 608/708 subtitles from h264 stream over http ? This works, but only for local files: ffmpeg -f lavfi -i movie=file.ts[out+subcc] -map 0:1 -f srt -
[22:35:56 CET] <JEEB> I don't see it being any more special unless protocols are blacklisted in the lavfi thing
[22:36:11 CET] <JEEB> technically you don't need lavfi for the thing at all, but ffmpeg.c doesn't support it
[22:36:34 CET] <JEEB> writing an API client that does caption extraction should be pretty simple
[22:36:53 CET] <JEEB> just init lavf+lavc and grab the captions from the video packets' side data
[22:38:28 CET] <M6HZ> JEEB, here is what I get if I substitute the file name with a url to a ts file: [Parsed_movie_0 @ 0x555934ccec00] Failed to avformat_open_input 'http'
[22:38:48 CET] <JEEB> sounds like you need to escape the :
[22:38:51 CET] <nicolas17> that's because : separates parameters in a filtergraph
[22:40:53 CET] <M6HZ> you mean like that: \: ?
[22:40:56 CET] <nicolas17> yes
[22:41:06 CET] <M6HZ> It doesn't change anything.
[22:41:47 CET] <JEEB> http://ffmpeg.org/ffmpeg-filters.html#Notes-on-filtergraph-escaping
[22:42:07 CET] <JEEB> read up this
[22:42:08 CET] <JEEB> :)
[22:42:15 CET] <M6HZ> ok
[22:42:24 CET] <nicolas17> maybe your shell is interpreting \: and sending : to ffmpeg
[22:44:02 CET] <M6HZ> nicolas17, I think you're right.
[22:46:48 CET] <M6HZ> The result is different if I double the escape \\:
[22:46:54 CET] <M6HZ> Now it looks like the option -referer is ignored.
[22:47:33 CET] <M6HZ> Is this option incompatible with -lavfi ?
[22:48:20 CET] <JEEB> lavfi makes the lavf context by itself so whatever you set with ffmpeg.c probably ain't gonna get passed
[22:49:09 CET] <M6HZ> Wow. Ok.
[22:49:46 CET] <JEEB> you could see what that movie filter does
[22:49:56 CET] <JEEB> and if it has options for passing lavf options
[22:50:12 CET] <JEEB> although to be honest if I was in your shoes I'd probably make a simple API client for the FFmpeg APIs
[22:52:48 CET] <M6HZ> JEEB, I would rather avoid that since I would like it to be the more portable and with the fewer dependencies possible.
[22:53:31 CET] <JEEB> well FFmpeg with its libs are already your dependencies
[22:54:44 CET] <nicolas17> I don't understand why the video can't be passed to -i
[22:54:58 CET] <JEEB> because ffmpeg.c doesn't have the logic to handle side data packets
[22:55:23 CET] <JEEB> for some reason only lavfi's movie filter has that functionality and generates that extra stream from it if it notices the captions might be there
[22:55:43 CET] <JEEB> (well I can understand why kind of, ffmpeg.c is a mess)
[22:59:45 CET] <M6HZ> Humm, I guess I'm running out of options.
[23:02:20 CET] <nicolas17> curl -H "Referer: http://example.com/" http://example.com/video.mp4 | ffmpeg -f lavfi -i movie=/dev/stdin[out+subcc]
[23:02:23 CET] <nicolas17> or would movie=- work?
[23:03:07 CET] <M6HZ> Yes, obviously, It would work, but this is a m3u8 stream ...
[23:03:57 CET] <nicolas17> HLS? ouch
[23:04:17 CET] <nicolas17> hmm
[23:04:42 CET] <nicolas17> JEEB: would "ffmpeg -i http://blah -codec copy -" at least *preserve* side data?
[23:05:53 CET] <JEEB> hmm, that would still have the side data in the AVPacket I guess
[23:05:58 CET] <M6HZ> by "side data" do you mean the subtitles ?
[23:05:58 CET] <JEEB> so quite possibly yes
[23:06:09 CET] <JEEB> M6HZ: they're part of the video stream as side data, so yes
[23:06:19 CET] <M6HZ> Yes, they are preserved
[23:06:39 CET] <JEEB> nicolas17: basically I don't see any special handling of SIDE_DATA anything in ffmpeg.c so most likely the AVPackets will just get passed on
[23:06:58 CET] <nicolas17> then maybe:
[23:07:08 CET] <nicolas17> ffmpeg -referer http://example.com/ -i http://example.com/stream.m3u8 -codec copy -f matroska - | ffmpeg -f lavfi -i movie=-[out+subcc] -map 0:1 -f srt -
[23:07:35 CET] <nicolas17> maybe another -f is more appropriate I dunno
[23:08:25 CET] <M6HZ> nicolas17, even if I do:  ffmpeg -i file.ts -c:v h264 -f matroska - | mpv -    I can still get the subtitles.
[23:08:51 CET] <JEEB> since they're in the video track yea
[23:09:07 CET] <JEEB> unless something touches those AVPackets inappropriately it will pass them through
[23:09:36 CET] <nicolas17> yeah but -c:v h264 would unnecessarily re-encode the video, you should use -c:v copy since you're ignoring the actual video anyway
[23:10:03 CET] <M6HZ> JEEB, ok, interesting.
[23:10:32 CET] <M6HZ> nicolas17, yes, I know that, it's just that it was odd to me.
[23:10:59 CET] <JEEB> but yea, this is just a hack from hell tbqh :P but hey, I've already voiced my opinion
[23:11:32 CET] <nicolas17> isn't ffmpeg.c a hack from hell? :v
[23:11:57 CET] <JEEB> yea, but I recommended a simple lavf+lavc API client
[23:12:03 CET] <JEEB> since just doing what he needs isn't too hard
[23:12:14 CET] <nicolas17> yeah maybe
[23:12:38 CET] <JEEB> grab the side data, make AVPackets from them for the caption decoder, pass them to srt stuff
[23:13:40 CET] <nicolas17> I tried writing the equivalent of "ffmpeg -f image2 -i frame%03d.png output.mp4" in C and it was somewhat painful, but I may have done it in the middle of the codecpar transition...
[23:14:21 CET] <nicolas17> ffprobe on my program's output file gave different results than on ffmpeg's output and it took me forever to find what differed and it was subtle
[23:14:27 CET] <M6HZ> JEEB, Do you think it would also be easy to delete these subtitles once I have extracted them from the video ?
[23:14:40 CET] <JEEB> in what sense?
[23:15:47 CET] <M6HZ> nicolas17, In the end what differed ?
[23:15:49 CET] <M6HZ> JEEB, me ?
[23:15:54 CET] <M6HZ> At *
[23:16:51 CET] <nicolas17> I don't remember anymore ^^
[23:17:04 CET] <JEEB> ffprobe generally doesn't massage stuff as much as ffmpeg.c does in various if clauses
[23:17:14 CET] <nicolas17> there is a filter to strip all sidedata
[23:17:15 CET] <JEEB> so it's closer to what the APIs return
[23:17:21 CET] <M6HZ> JEEB,  I would like to extract the subtitles in a text file, and delete them from the h264 stream, then "merge" them again in a more conventional way.
[23:18:33 CET] <JEEB> I can see how that is done but no idea about ffmpeg.c
[23:20:39 CET] <M6HZ> nicolas17,  sidedata, asidedata
[23:22:21 CET] <M6HZ> nicolas17, Great !
[23:23:02 CET] <M6HZ> nicolas17, sadly it means that I have to re-encode the whole stream.
[23:24:15 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#toc-Bitstream-Filters :P
[23:26:16 CET] <M6HZ> JEEB, Wow interesting, I've never played with this option.
[23:49:37 CET] <M6HZ> JEEB, So it looks like I have the choice between "extract_extradata" + "remove" and "h264_metadata" + "delete_filler", apparently the subtitles are located in SEI messages.
[23:50:51 CET] <JEEB> yes, whatever removes SEI messages of a certain type. not going to say if that combo is correct or not since extract_extradata is supposed to just put extradata (decoding init data) into the AVCodecContext's extradata field
[00:00:00 CET] --- Sun Nov  4 2018