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

[burek]

[00:50:30 CET] <RossW> Anyone know how to force ffmpeg to use a specific output type of jpg, when writing to a pipe?
[00:50:47 CET] <RossW> ffmpeg -i input.jpg -i watermark.png -filter_complex "overlay=10:10" -qscale:v 2 output.jpg    writes a jpeg fine.
[00:51:00 CET] <RossW> ffmpeg -i input.jpg -i watermark.png -filter_complex "overlay=10:10" -qscale:v 2 -f image2 pipe:1   outputs a file, but not a jpeg.
[00:51:29 CET] <RossW> I can't find a    -f jpg   or -f jpeg    type switch, but not through lack of searching!
[00:51:39 CET] <relaxed> -f mjpeg
[00:51:59 CET] <RossW> *facepalm*. of course, thanks, I'll try that.
[00:57:34 CET] <RossW> you're a champ, relaxed.  *thumbs up*
[00:59:16 CET] <relaxed> \o
[05:23:03 CET] <stl1303> anyone know why I might be getting frames out of order out of ffmpeg on h264 decoding? The timestamps of all the frames is out of order
[05:25:36 CET] <klaxa> there is a difference between dts (decoding timestamp) and pts (presentation timestamp)
[05:27:15 CET] <stl1303> Yeah. The presentation time stamps are out order. the video looks like it's constantly repeating itself
[09:53:33 CET] <luc4> Hello! I would like to stream content using multicast RTP but accessing through a RTSP point. I created this conf file for ffserver but I probably did it wrong: https://paste.kde.org/p4lve2fi8. I can play the two rtp streams by using a rtp url, but I can't simply access rtsp://192.168.0.102:5554/bbb.sdp. Is what I'm trying to do possible somehow?
[12:00:34 CET] <feliwir> Hey, i get this error when compiling ffmpeg with SDl2:
[12:00:36 CET] <feliwir> SDL_config.h(37): fatal error C1189: #error:  You should run hg revert SDL_config.h
[12:09:02 CET] <feliwir> i think it's because i tried to compile ffplay with msvc
[12:09:21 CET] <feliwir> it must be possible somehow or not?
[12:33:43 CET] <feliwir> i give up. It's impossible to build ffmpeg with ffplay with visual studio
[12:50:57 CET] <faLUCE> ciao Zuccace ;-)
[13:09:58 CET] <Zuccace> Hi.
[13:55:07 CET] <JEEB> feliwir: I don't think *anyone* has tested that configuration since usually everyone who uses FFmpeg with MSVC just needs the libraries :P
[16:47:15 CET] <nightlingo> hi!
[16:47:26 CET] <nightlingo> I need to be able to stream to stdout when converting into .mp4 format, for example:
[16:47:26 CET] <nightlingo> ffmpeg -i file.avi -f mp4 - > file.mp4
[16:47:27 CET] <nightlingo> However, I get the following error: muxer does not support non seekable output - I get the reason why the mp4 writer doesn't support this. But is there any work around for this? I've beel searching for days! Thank you
[16:49:40 CET] <alexpigment> nightlingo: i presume you're wanting to transcode, right?
[16:50:11 CET] <nightlingo> alexpigment: not necessarily. most of the times I just want to mux audio and video, or split
[16:50:43 CET] <alexpigment> does the same problem happen when you add "-c:v libx264"?
[16:51:15 CET] <nightlingo> Ill try now
[16:52:57 CET] <nightlingo> alexpigment: yes, same error
[16:53:07 CET] <alexpigment> k, so it's not the input video format
[16:53:23 CET] <nightlingo> yes, the problem is that ffmpeg cant write .mp4 to stdout
[16:54:01 CET] <alexpigment> so this is out of my level of expertise, but the other thing i'd try is adding flags that make it seekable
[16:54:28 CET] <nightlingo> alexpigment: but stdout is not seekable
[16:54:43 CET] <nightlingo> alexpigment: how would you do that?
[16:55:17 CET] <alexpigment> perhaps try "-movflags empty_moov"
[16:55:18 CET] <furq> i take it that's not your actual command line
[16:56:09 CET] <alexpigment> furq: are you thinking it's just that c:v and c:a arent specified?
[16:56:43 CET] <furq> no i'm thinking that if it was then he could just do -i foo bar.mp4 and it would do the same thing except it would work
[16:56:53 CET] <furq> but presumably it's not that simple
[16:57:28 CET] <furq> if you really need to write to stdout then either use fragmented mp4 (-movflags frag_keyframe+empty_moov) or just use a different muxer
[16:57:33 CET] <furq> mkv and mpegts can both handle that just fine
[16:58:24 CET] <alexpigment> yeah, i didn't know if "frag_keyframe" mattered in this case, but "empty_moov" directly relates to the seek problem i would think
[16:58:26 CET] <nightlingo> furq: I tried the mpegts container, but it doesnt work well on windows media player
[16:58:38 CET] <furq> oh wow, windows media player
[16:58:57 CET] <nightlingo> furq: yeah :( unfortunately some people still use that
[16:59:15 CET] <furq> what works in windows media player depends on an infinite number of things
[16:59:18 CET] <furq> including the phase of the moon
[16:59:24 CET] <nightlingo> lol
[16:59:41 CET] <alexpigment> furq: i won't get into it, but WMP a lot of advantages on Windows over other players. i wouldn't hate on anyone for using it, especially if they have interlaced content, or if they have an Nvidia graphics card
[17:00:02 CET] <furq> do you mean advantages like not playing anything properly
[17:00:18 CET] <alexpigment> no, advantages like actually doing properly deinterlacing out of the box without having to change settings
[17:00:33 CET] <alexpigment> or like assuming the correct color range rather than forcing limited
[17:00:36 CET] <furq> i'm pretty sure mpc-hc does that out of the box now
[17:00:41 CET] <furq> and mpv does it if you hit d
[17:01:04 CET] <alexpigment> sure, but the average person knows about WMP, VLC, and Quicktime. the latter are both horrible pieces of software
[17:01:13 CET] <furq> all of those are horrible pieces of software
[17:01:25 CET] <alexpigment> yes, but you can agree that WMP is clearly the best out of the three?
[17:01:45 CET] <furq> i've not seen wmp since windows 7
[17:01:54 CET] <furq> i assume ms have made it better because it would be impossible for them to have made it worse
[17:02:23 CET] <alexpigment> furq: i was really making a tangent. i stand behind my statements completely, but there's no need to go into it here
[17:02:53 CET] <alexpigment> nightlingo: what happened when you tried the flags command?
[17:03:05 CET] <furq> i have no idea what wmp will make of fmp4
[17:03:31 CET] <furq> i'm not sure that you can expect it to work everywhere that regular mp4 does
[17:03:32 CET] <nightlingo> alexpigment: the empty_moov one? I had tried that in the past and it was behaving weird in both vlc and media player but I will try that again now
[17:03:44 CET] <furq> you need frag_keyframe as well
[17:03:57 CET] <nightlingo> furq: yes with that as well
[17:04:09 CET] <nightlingo> it was the combination of those two options
[17:04:28 CET] <furq> you do definitely need to output to stdout, right
[17:04:47 CET] <nightlingo> furq: unfortunately yes
[17:05:00 CET] <nightlingo> furq: its in the requirements
[17:07:58 CET] <nightlingo> furq: Im sorry I just realized: I was using -c copy
[17:08:20 CET] <alexpigment> -c:v copy or -c:a copy ?
[17:09:12 CET] <nightlingo> furq: if I dont use this it works with both frag_keyframe and also the mpegts ways
[17:09:23 CET] <nightlingo> furq: -c copy, both audio and video
[17:09:54 CET] <alexpigment> oh weird, i didn't know you could do that. learn something new everyday :)
[17:11:07 CET] <nightlingo> but I would rather do it using the copy option, otherwise it gets too cpu hungry :/
[17:12:23 CET] <alexpigment> that begs the question: what are the audio and video codecs in your original stream?
[17:12:50 CET] <alexpigment> that was really the point of testing c:v libx264 earlier - to see if it was a problem with input codecs
[17:14:24 CET] <alexpigment> at any rate, you might try doing -c:v copy and -c:a aac to rule out a problem with just the audio
[17:14:38 CET] <nightlingo> alexpigment: Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720 [SAR 1:1 DAR 16:9], 1053 kb/s, 30 fps,
[17:14:49 CET] <nightlingo> and Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)
[17:14:55 CET] <alexpigment> weird
[17:15:22 CET] <alexpigment> everything looks good with the codecs themselves, so i don't know why leaving out -c copy would make any difference
[17:16:26 CET] <nightlingo> alexpigment: Im not very familiar with the codecs in general so I wouldnt know. I was hoping to simply copy the data into a different container, but it doesnt work. Maybe a work around would be to convert it with as little processing as possible somehow
[17:16:55 CET] <alexpigment> well, you could use -c:v libx264 -preset veryfast
[17:17:14 CET] <alexpigment> if quality is not a concern at all, then -preset ultrafast would be even quicker
[17:17:54 CET] <alexpigment> and of course, specify your -crf or -b:v values to fit your needs
[17:18:18 CET] <nightlingo> alexpigment: I would like to have the same quality as the input stream
[17:18:31 CET] <alexpigment> is file size a concern?
[17:18:46 CET] <alexpigment> rather, is bitrate a concern?
[17:20:28 CET] <nightlingo> alexpigment: Im not sure. What I know is that I want to approximate as closely as possible the input streams quality and filesize
[17:20:47 CET] <alexpigment> because a low CRF value would be perceptually identical to the original. try starting at -crf 15 and adjust from there. lower is better quality but increasingly ridiculous bitrates
[17:21:26 CET] <alexpigment> well, i guess when you're re-encoding - and re-encoding using a fast x264 preset, getting both the same file size and quality is going to be difficult
[17:21:49 CET] <alexpigment> then again, you do have the advantage of being able to use a "-profile:v high"
[17:22:13 CET] <alexpigment> your input stream uses Main profile, and so it's a little less efficient with bitrate than it would be with High
[17:22:54 CET] <nightlingo> alexpigment: oh so this means that if I do the conversion, Ill end up with a more efficient file than what I began with ?
[17:23:06 CET] <alexpigment> not exactly
[17:23:11 CET] <feliwir> so i right now someone online that can tell me how to compile ffplay with msvc?
[17:23:15 CET] <feliwir> *is
[17:24:04 CET] <alexpigment> what i'm saying is that transcoding between lossy formats is always a losing battle. you usually either give up quality or you give up file size. in this case, you want to maintain both the size and quality *and* you want it to be not very CPU intensive
[17:24:48 CET] <alexpigment> but since your original video is using Main profile rather than High, you can transcode with High profile, which makes your tradeoffs a little less severe
[17:25:06 CET] <nightlingo> alexpigment: oh ok I see. And how can I activate this high profile?
[17:25:23 CET] <alexpigment> "-profile:v high"
[17:25:47 CET] <nightlingo> alexpigment: should I use it in combination with the -c:v libx264 -preset veryfast options?
[17:26:04 CET] <alexpigment> so as a whole, you could try "-c:v libx264 -crf 20 -preset veryfast -profile:v high"
[17:26:20 CET] <nightlingo> alexpigment: cool, thanks!
[17:26:21 CET] <alexpigment> and adjust the CRF lower if the quality isn't good enough for your needs
[17:26:22 CET] <JEEB> profile:v high will do nothing
[17:26:50 CET] <JEEB> you are using a preset that will not use high profile features
[17:27:08 CET] <alexpigment> i'll defer to JEEB's expertise here
[17:27:24 CET] <JEEB> and if you use high profile features then the encoder will pick that profile
[17:27:34 CET] <nightlingo> JEEB: so how should I do it then?
[17:28:20 CET] <JEEB> the first question is why not main profile if you're not using high profile features?
[17:28:44 CET] <JEEB> the encoder is setting the compatibility of your stream according to your settings
[17:28:52 CET] <alexpigment> that was my suggestion. i know that High is more efficient than Main to some degree (not to the level that Main is efficient over Baseline, of course)
[17:29:25 CET] <alexpigment> i'm also curious to know why High profile features aren't used in this scenario. does veryfast disable them?
[17:29:32 CET] <nightlingo> JEEB: Im not sure. What I want to do is to simply -c copy from mp4 -> mpegts. But this results in a file that windows media player has trouble working with. So Im looking for the nearest solution
[17:30:12 CET] <JEEB> alexpigment: 8x8dct is pretty much the only feature requiring high profile
[17:30:32 CET] <nightlingo> JEEB: do you think this is an indexing problem or something? maybe there is a way to fix it? Id really rather use -c copy than transcode
[17:30:43 CET] <JEEB> nfi
[17:31:49 CET] <JEEB> also I hope you're converting that mp4's avcc bit stream to annex b
[17:32:19 CET] <JEEB> although that would make it pretty much unplayable in many players if you didn't
[17:33:47 CET] <nightlingo> JEEB: how do I do that?
[17:37:01 CET] <nightlingo> JEEB: my purpose is perform spliting on an .mp4 file and have ffmpeg output to stdout
[17:37:43 CET] <nightlingo> JEEB: but without transcoding, it should be done by just copying
[17:42:59 CET] <alexpigment> feliwir: i assume the answer's yes, but presumably you've seen these two resources?
[17:42:59 CET] <alexpigment> http://ffmpeg.org/platform.html#toc-Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows
[17:43:04 CET] <alexpigment> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC
[17:43:48 CET] <feliwir> alexpigment, the second resource does never show how to compile ffplay with msvc
[17:43:55 CET] <feliwir> it even explicitly disables it
[17:44:21 CET] <alexpigment> what happens if you remove "--disable ffplay"
[17:44:58 CET] <feliwir> i need to enable ffplay explicitly. And then it complains about missing SDL2 of course
[17:45:39 CET] <feliwir> but there is no way for me to link SDL2 at any stage with that cumbersome buildsystem
[17:45:55 CET] <alexpigment> gotcha. i just saw your question above and wanted to make sure you'd checked both of those guides. assuming you have, and you've enabled ffplay, i don't know what the problem would be
[17:46:38 CET] <feliwir> the problem is that the only way for that buildsystem to find SDL2 is pkg-config. Pkg-config can't find SDL2 installation that was compiled with MSVC
[17:48:03 CET] <alexpigment> i went through that a few days ago compiling on linux, specifically with "libass", "fontconfig", "libbluray" etc. i have no idea what the problem was - i just started from scratch and it worked the second time
[17:48:35 CET] <alexpigment> having said that, i believe the problem was related to some .rc files being empty
[17:48:53 CET] <alexpigment> not sure if that helps at all - i've never worked with Visual C
[17:49:05 CET] <feliwir> the problem here is that it is technically impossible that the buildsystem ffmpeg used will allow me to link a correct SDL2
[17:49:46 CET] <feliwir> alexpigment, i can compile FFMpeg with Linux, MinGW and Visual Studio. But with visual studio ffplay is not compilable
[17:50:12 CET] <alexpigment> fair enough. i don't have much to offer on this particular issue
[17:50:56 CET] <feliwir> i wish ffmpeg would use CMake or something less Unix biased than Autotools
[17:51:37 CET] <feliwir> no matter which project, every project that only used autotools is a pain on Windows
[17:52:37 CET] <alexpigment> well i *end* up compiling ffmpeg on Linux for Windows because it was a hell of a lot easier (for me) than compiling natively on Windows
[17:52:43 CET] <alexpigment> *ended up
[17:52:52 CET] <alexpigment> so i can relate to some degree
[17:53:27 CET] <feliwir> well it works relative well with mingw, but it's much smoother to work with Visual Studio on windows
[18:25:52 CET] <furq> i've said this before, but i would like to extremely vote against cmake
[18:25:59 CET] <furq> not that i think it's on the table
[18:26:38 CET] <furq> also ffmpeg doesn't actually use autotools, the configure script is handwritten
[18:36:26 CET] <c3r1c3-Win> cmake rocks... but I've been told that waf rocks more. ;-)
[18:36:43 CET] <c3r1c3-Win> Really it depends on what you're looking for.
[18:37:06 CET] <c3r1c3-Win> Do you want something that cross-platform and builds stuff easily on different OSes? Then CMake is pretty good.
[18:37:42 CET] <c3r1c3-Win> Not saying that there aren't better solutions.
[18:40:45 CET] <riataman> Hey
[18:41:18 CET] <riataman> I'm trying to record AND display a rtsp stream.
[18:41:31 CET] <riataman> for recording I'm using this line: ffmpeg -i rtsp://192.168.1.2:554/11 -c copy -an  -map 0 -f segment -segment_time 10 -segment_format mp4 "out%03d.mp4"
[18:41:58 CET] <riataman> Is there any way to "divert" the raw stream to a socket/pipe so I can play that using a video player?
[18:42:08 CET] <riataman> while keeping the recording with segmentation?
[18:47:26 CET] <riataman> ok, I may have figured that out https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs
[19:31:14 CET] <ice9> is it possible to use ffmpeg to remove meta / exif data without making any codecs conversions?
[19:58:32 CET] <kepstin> it's kind of hard to answer questions for people when they disappear after only 2 minutes :)
[19:59:08 CET] <furq> hey come on
[19:59:10 CET] <furq> that was 19 minutes
[19:59:12 CET] <furq> a new record for patience
[20:04:18 CET] <kepstin> ah, looked at the wrong leave time.
[21:10:35 CET] <nightlingo> Hello, Im trying to understand how the mp4 format works. I read that ffmpeg cannot write mp4 to stdout because it requires a seekable stream so as to be able to go back and write the header. Is the heaer the moov atom, or the ftyp atom?
[21:13:10 CET] <drv> you can look for avio_seek() in libavformat/movenc.c - all of those places need seekable output
[21:17:50 CET] <nightlingo> drv: can you please explain this? is this a way to overcome the mp4 limitation about writting to non-seekable output?
[21:48:49 CET] <Pandela> I got this weird error I thought I'd share when trying to use -codec copy with a gif to another gif
[21:48:52 CET] <Pandela> Assertion video_par->format == AV_PIX_FMT_PAL8 failed at libavformat/gif.c:130
[21:59:48 CET] <llogan> Pandela: you should report it a bug on trac.ffmpeg.org.
[22:00:28 CET] <Pandela> llogan: Will do
[22:01:10 CET] <llogan> make sure to: 1) use the most recent ffmpeg you can (see FFmpeg download page for links to recent binaries if you can't compile) 2) show your actual command 3) provide the complete console output from the command. 4) provide the input file if it is required to reproduce the issue.
[22:01:36 CET] <llogan> 5) use the code block button to properly format the command and console output.
[22:02:03 CET] <llogan> 6) sacrifice a goat during the full moon
[22:05:05 CET] <slalom> i always forget the last bit
[22:07:32 CET] <llogan> possibly why it the bug was marked as "heretical" by the high inquisitor
[22:21:09 CET] <kepstin> nightlingo: no, it's an inherent problem with the design of the mp4 container.
[22:21:51 CET] <kepstin> nightlingo: there's a variation of mp4 which allows "fragmented" files, but it's not compatible with all that much iirc
[22:22:21 CET] <nightlingo> kepstin: yeah I tried fragmented mp4s and dont work well with some players
[22:22:55 CET] <nightlingo> kepstin: my purpose is to be able to stream a piece (split) of an .mp4 video to stdout
[22:23:48 CET] <kepstin> nightlingo: why do you want to do that?
[22:24:33 CET] <nightlingo> kepstin: im working on a media server
[22:25:14 CET] <kepstin> but a "piece" of an mp4 file doesn't make sense
[22:25:31 CET] <nightlingo> kepstin: the users of the media server require this functionality
[22:26:02 CET] <kepstin> in order to stream an mp4 file for playback, you need some format info at the start of the file. but the mp4 spec is such that the place where this format info is stored also holds some info that can't be written until the entire stream data is known
[22:26:06 CET] <kepstin> so... it can't be done
[22:26:33 CET] <kepstin> either use a different format, or write the segment to disk temporarily before streaming it
[22:26:54 CET] <nightlingo> kepstin: yes I would like to go for the second solution
[22:27:14 CET] <nightlingo> kepstin: sorry, I misread
[22:29:36 CET] <nightlingo> kepstin: I was thinking to find the mdat atoms that correspond to the requested timesplit and then patch the MOOV atom so that it points only the aforementioned atoms
[22:30:17 CET] <kepstin> nightlingo: sure, but now you're in the realm of custom mp4 file manipulation; this isn't something you're gonna use ffmpeg for :)
[22:31:19 CET] <nightlingo> kepstin: yeah, it seems like it. I started with ffmpeg that I guess I have to go for a custom solution, and this is the only channel I thought Id find people who would know about this stuff
[23:05:21 CET] <obamoose> oh what
[23:05:26 CET] <obamoose> there is an ffmpeg channel
[23:05:28 CET] <obamoose> oh my
[23:05:41 CET] <obamoose> hello!
[23:05:53 CET] <obamoose> I'm having issues with looping files in a directory
[23:06:16 CET] <obamoose> while true ; do find /home/me/cgn -name "*.mp4" | xargs - 0 -I ffmpeg -y -re -i -vcodec libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv rtmp://a.rtmp.youtube.com/ ; done
[23:06:21 CET] <obamoose> this is what I have right now
[23:06:44 CET] <obamoose> and the error i'm getting is an infintely loooping terminal
[23:10:16 CET] <diverdude> Hi, this creates a testvideo of resolution 320x240: ffmpeg -f lavfi -i rgbtestsrc -pix_fmt yuv420p -t 30 rgbtestsrc.mp4   I need to make a video of size 4096x3000 instead, it would be good to have some motion in the movie as well. Can i do that in ffmpeg?
[23:13:18 CET] <thebombzen> obamoose: you should not be surprised by an infinitely looping terminal
[23:13:26 CET] <thebombzen> you have while true; do ...; done
[23:13:33 CET] <obamoose> I am new to ffmpeg ;_;
[23:13:39 CET] <thebombzen> that has nothing to do with ffmpeg
[23:13:59 CET] <thebombzen> while true; do ...; done says "loop what's inside infinitely." It's a shell script thing
[23:14:13 CET] <obamoose> Oh that part I understand
[23:14:25 CET] <obamoose> but it's supposed to infinitely loop the videos
[23:14:39 CET] <obamoose> so I'm guessing I made an error with 'insiding'
[23:14:53 CET] <thebombzen> what are you actually trying to do?
[23:15:08 CET] <obamoose> Loop videos inside of the cgn directory infinitely
[23:15:45 CET] <thebombzen> what does it mean to "loop videos" do you mean stream them one after another, and when you're done go back to the beginning?
[23:15:51 CET] <obamoose> yessir
[23:16:02 CET] <thebombzen> if that's true then why don't you pre-encode them
[23:16:14 CET] <thebombzen> no need to encode them on the fly if you know the encoding settings
[23:16:26 CET] <obamoose> aren't they already encoded when .mp4?
[23:16:49 CET] <thebombzen> well you're transcoding them on the fly
[23:16:49 CET] <obamoose> oh
[23:17:02 CET] <obamoose> isn't this '-y -re -i -vcodec libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ac 2 -ar 44100 -f flv' the one doing the re-encoding?
[23:17:13 CET] <diverdude> anyone?
[23:17:47 CET] <thebombzen> diverdude: http://ffmpeg.org/ffmpeg-filters.html
[23:17:54 CET] <thebombzen> obamoose: well no
[23:18:01 CET] <thebombzen> it's not "the one"
[23:18:15 CET] <thebombzen> and first of all, -i takes an argument
[23:18:41 CET] <thebombzen> it sounds like you copy/pasted from several things without understanding what you're really doing
[23:18:48 CET] <obamoose> indeed
[23:18:49 CET] <obamoose> ;_;
[23:20:54 CET] <thebombzen> I suggest you read this for a basic rundown
[23:20:54 CET] <thebombzen> https://ffmpeg.org/ffmpeg.html
[23:22:52 CET] <diverdude> this will make a 30 sec file yeah? ffmpeg -f lavfi -i allrgb -t 30 testsrc.mp4
[23:25:08 CET] <alexpigment> diverdude: yes
[23:25:14 CET] <alexpigment> -t is the length in seconds
[23:25:59 CET] <faLUCE> well, I succeeded in creating a < 100ms latency HTTP-MPEGTS h264 stream, WITHOUT zerolatency
[23:26:01 CET] <faLUCE> !!!
[23:26:31 CET] <alexpigment> faluce: nice! congrats
[23:26:46 CET] <faLUCE> alexpigment: thnks, I'm goingo to publish all
[23:27:02 CET] <BtbN> so you set the settings zerolatency would set for you yourself?
[23:27:24 CET] <faLUCE> BtbN: what do you mean?
[23:27:43 CET] <BtbN> It basically disables B-Frames/Reordering and lookahead. Which is just what you want for low latency
[23:28:00 CET] <BtbN> I'd say sub 100ms is impossible without it
[23:28:16 CET] <faLUCE> BtbN: yes, in fact I disabled B-frames. But I made many other tunes
[23:28:36 CET] <BtbN> So what's the gain from not using lerolatency then?
[23:28:41 CET] <BtbN> That's exactly what it exists for
[23:28:45 CET] <BtbN> *zero
[23:28:51 CET] <faLUCE> BtbN: first of all it's an AUDIO+VIDERO streaming
[23:29:11 CET] <BtbN> audio isn't really critical in terms of latency
[23:29:11 CET] <faLUCE> I obtained this low latency by making many tunes on the grabbing part
[23:29:23 CET] <thebombzen> yea as long as you have opus you're fine
[23:29:32 CET] <faLUCE> it's criticall if you don't have a good pollable mechanism in the API
[23:29:49 CET] <BtbN> There are no B-Frames or reordering
[23:29:53 CET] <BtbN> so nothing to look out for.
[23:30:06 CET] <faLUCE> I implemented the alsa and v4l part, instead of using the ffmpeg wrapper
[23:30:37 CET] <faLUCE> and I tuned all the buffers
[23:31:55 CET] <faLUCE> the non-pollable grabbing part in libav is a big missing feature, IMHO
[23:32:24 CET] <BtbN> "non-pollable"?
[23:32:29 CET] <faLUCE> BtbN: yes
[23:32:39 CET] <BtbN> I'm pretty sure you can just set it to non-blocking mode and then poll it all you want
[23:32:57 CET] <faLUCE> BtbN: you can set it to non blocking, but you cant do any poll on it
[23:33:21 CET] <BtbN> Of course, it will return instantly, so you can just poll if data is available, and go do other stuff if not.
[23:33:41 CET] <faLUCE> BtbN: this means that you have 100% CPU
[23:34:00 CET] <faLUCE> if you use non blocking feature
[23:34:00 CET] <BtbN> so put some sensible sleep in there if everything returned empty
[23:34:09 CET] <faLUCE> BtbN: sleep != polling
[23:34:26 CET] <BtbN> polling without sleep is busy waiting, you don't want that
[23:34:39 CET] <BtbN> You have a rough idea if when data will arrive, so use like a quarter of that time for the sleep
[23:34:41 CET] <BtbN> *of
[23:34:59 CET] <faLUCE> BtbN: that's not a fine implementation
[23:35:18 CET] <BtbN> That's a pretty standard implementation
[23:35:42 CET] <BtbN> And it's how polling works, so I don't see your point...?
[23:36:09 CET] <faLUCE> BtbN: not really. Libalsa and v4l use the select() or poll() API. but when they are wrapped by libav this is not possible
[23:36:59 CET] <BtbN> of course it's not. being able to use select() on something is a very specific case. libav* offers a generaliced API, which exists even on platforms without those calls
[23:37:33 CET] <faLUCE> BtbN: I insist. it's a missing feature of libav, which adds unuseful delay
[23:37:51 CET] <faLUCE> BtbN: note that in the recent libav API, the encoding part is pollable
[23:37:56 CET] <faLUCE> but not the grabbing part
[23:37:57 CET] <BtbN> libav is not going to add API that's specific to a single filter/input on a single OS
[23:38:20 CET] <JEEB> it really depends on the use cases, generalize
[23:38:22 CET] <JEEB> ability
[23:38:28 CET] <JEEB> and care level of people
[23:38:39 CET] <faLUCE> BtbN: but libevent is good for all the platforms
[23:38:43 CET] <BtbN> I'd be surprised if you can select()/poll() encoders in libavc
[23:38:47 CET] <JEEB> if you want to think of a new abstraction, design it and post on ffmpeg-devel
[23:39:01 CET] <faLUCE> JEEB: in fact I made a library
[23:39:03 CET] <JEEB> and then if people like it, implement
[23:39:15 CET] <faLUCE> JEEB: I'll publish it ASAP
[23:39:37 CET] <faLUCE> the only problem is that it's in C++, not C
[23:39:37 CET] <BtbN> Most people would probably just put it in a thread and fire an event from there if new data arrived from a blocking call
[23:39:47 CET] <faLUCE> BtbN: I avoided thread
[23:39:58 CET] <BtbN> That's as cross-platform and straight forward as it gets
[23:40:02 CET] <faLUCE> threads are weird
[23:40:14 CET] <faLUCE> and they should not used for decoupling tasks
[23:40:26 CET] <BtbN> Of course they should, that's the whole idea of them
[23:40:26 CET] <JEEB> c++ will not go into FFmpeg, but for your own use or research I don't think anyone cares
[23:40:50 CET] <faLUCE> BtbN: really not, they are not necessary for decoupling stuff
[23:41:01 CET] <faLUCE> threads are conceived for other things
[23:41:04 CET] <BtbN> But they make it easy and are convenient.
[23:41:16 CET] <faLUCE> BtbN: I don't agree at all
[23:41:33 CET] <BtbN> I won't stop you from making your life harder over that.
[23:42:05 CET] <faLUCE> BtbN: on the contrary, I simplified all, by makiing a very easy event loop
[23:42:19 CET] <faLUCE> anyway, I'll publish all
[23:44:30 CET] <JEEB> btw, there's at least one protocol in lavf that does threads in itself
[23:44:40 CET] <JEEB> have fun guessing which :P
[23:45:47 CET] <faLUCE> JEEB: but it's reasonable that every codec/protocol uses internal threads. What is not reasonable, IMHO, is to use threads for decoupling functions/sources/cycles etc.
[23:46:13 CET] <faLUCE> JEEB: for example AFAIK, x264 uses threads
[23:46:30 CET] <JEEB> well, d'uh
[23:46:31 CET] <BtbN> But that's exactly what they exist for. Let the OS scheduler take care of that stuff, instead of implementing half a scheduler yourself
[23:46:42 CET] <faLUCE> BtbN: no
[23:46:45 CET] <BtbN> yes
[23:47:06 CET] <faLUCE> BtbN: threads are meant when you want to use the multicolre
[23:47:09 CET] <faLUCE> multicore
[23:47:22 CET] <faLUCE> not when you generally want  to decouple functions
[23:47:32 CET] <BtbN> That's what they are also usefull for. But they are just for everything that can happen at the same time.
[23:47:42 CET] <BtbN> There is no RFC that defines what you are allowed to use threads for.
[23:47:48 CET] <faLUCE> BtbN: please.....
[23:48:23 CET] <faLUCE> anyway, think what you want. I'm not going to convince anyone
[23:48:45 CET] <BtbN> I just think it's stupid to make ones life hard to strive for some weird ideal of not using threads for something they make super easy and clean.
[23:49:30 CET] <BtbN> Of course you don't _need_ threads for anything. But they make a lot of stuff easier.
[23:50:04 CET] <faLUCE> BtbN: not really, because threads appear to be easier at the beginning, but then they mess up the code. And having a GOOD event driven api is the EASIEST (for the user) and CLEANEST paradygm
[23:50:31 CET] <BtbN> If you have a good event driven API(See for example Qt), threads become even better and easier.
[23:50:52 CET] <faLUCE> if you have a good event driven API you don't use threads at all
[23:51:02 CET] <BtbN> And why?
[23:51:05 CET] <BtbN> Because you say so?
[23:51:16 CET] <BtbN> If threads make something easier, or faster, you use them.
[23:51:22 CET] <faLUCE> BtbN: ok, think what you want, this discussion is completely useless
[00:00:00 CET] --- Sat Mar 11 2017