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

[burek]

[00:15:53 CEST] <alexpigment> i tried to create a worst-case scenario for testing mpeg2video encoding, and oddly i found that two of my tests failed with the following error "bitrate too low for this video with these parameters"
[00:17:09 CEST] <alexpigment> this occurred with a 2-pass 3.5mbps encoding, but the higher bitrates i tested like 5mbps or 8mbps
[00:17:27 CEST] <thebombzen> well dvds are usually around 6 Mbps fyi
[00:17:33 CEST] <alexpigment> now, given that i'm trying to make a more-or-less automated process and the source content will vary, is there any way to prevent these types of errors?
[00:17:47 CEST] <alexpigment> thebombzen: dvds are whatever bitrate you tell them to be ;)
[00:18:02 CEST] <alexpigment> as with VHS, there are standards for long play, super long play, etc in the consumer market
[00:18:02 CEST] <thebombzen> yes, which is why they are "usually around 6 Mbps"
[00:18:21 CEST] <alexpigment> thebombzen: i feel like you're only thinking of movies from movie studios
[00:18:22 CEST] <thebombzen> Because most of the time people tell them to be around 6 Mbps
[00:18:33 CEST] <alexpigment> rather than the broader landscape of DVDs that exist
[00:18:54 CEST] <thebombzen> Well who do you think produces more DVD-Video. Industry or "just some guy"s
[00:19:08 CEST] <alexpigment> that's like saying the most common frame rate is 24fps (which it's definitely not, if you're making a blanket statement)
[00:19:59 CEST] <alexpigment> thebombzen: i mean that's a fair point, but i also don't work for a movie studio, and this is about putting more content on a DVD than 2hrs
[00:20:20 CEST] <thebombzen> The most common framerate is actually 24 fps
[00:20:24 CEST] <alexpigment> because believe it or not, sometimes you can get away with under 4mbps
[00:20:31 CEST] <thebombzen> Yea I know that
[00:20:38 CEST] <alexpigment> and in my experience, i get things from DVDs that are commonly under 5mbps for sure
[00:21:01 CEST] <thebombzen> 4.8 Mbps is "around 6 Mbps" by the way
[00:21:12 CEST] <thebombzen> it's in the same ballpark
[00:21:16 CEST] <alexpigment> ?
[00:21:17 CEST] <alexpigment> ok
[00:21:19 CEST] <alexpigment> i mean
[00:21:24 CEST] <alexpigment> actually, no :)
[00:21:29 CEST] <alexpigment> i don't agree with that statement :)
[00:21:44 CEST] <thebombzen> yea, it's off by a factor of less than 2
[00:21:46 CEST] <alexpigment> we're talking about a realistic scale of 3-9mbps
[00:21:55 CEST] <alexpigment> 4.8 is nowhere near 6mbps
[00:22:02 CEST] <alexpigment> that's besides the point though
[00:22:16 CEST] <thebombzen> It's not at all beside the point
[00:22:21 CEST] <alexpigment> of course it is
[00:22:25 CEST] <thebombzen> "[18:17:27] <thebombzen> well dvds are usually around 6 Mbps"
[00:22:39 CEST] <thebombzen> if the proximity to 6 Mbps is beside the point
[00:22:41 CEST] <alexpigment> yeah, that was your tangent i believe
[00:22:58 CEST] <alexpigment> the point is i have an automated process here that's failing based on certain types of input content
[00:22:59 CEST] <thebombzen> if it's beside the point then why are you arguing with my statement about the proximity to 6 Mbps
[00:23:27 CEST] <thebombzen> and if you're getting an error that the bitrate is too low with those parameters
[00:23:32 CEST] <thebombzen> perhaps that's because the bitrate is too low
[00:23:38 CEST] <alexpigment> i don't know, it just seemed so wrong in my experience. there's a huge PQ difference in those numbers
[00:24:43 CEST] <alexpigment> ok, but i think i implied this up above if not explicitly stated it. 1-pass works with that bitrate, 2-pass fails
[00:25:43 CEST] <alexpigment> besides, i don't understand the concept of a bitrate that is realistic, but low enough that it causes a complete failure
[00:32:22 CEST] <alexpigment> i'm just going to go ahead and say it. trying to do anything remotely fine-tuned with mpeg2video sucks :)
[00:57:49 CEST] <thebombzen> well mpeg2video sucks in general
[00:57:53 CEST] <thebombzen> so this shouldn't surprise you
[00:58:13 CEST] <thebombzen> clearly you need to use mpeg2 to author a d.vd but the question is why are you trying to author a d.vd in the first place
[01:22:01 CEST] <alexpigment> thebombzen: because DVD is the most universal physical delivery system for video, sadly
[01:22:53 CEST] <alexpigment> i'm sure in here we're all very familiar with the myriad of ways to watch something on your tv. i've got an HTPC on every TV at home, Blu-ray players, a few gaming systems, etc that could easily play a video file from either a USB stick or a network location
[01:23:23 CEST] <alexpigment> but a lot of people out there aren't very techy or are from an older generation, and the most likely way to guarantee that they can play something is on DVD
[01:23:36 CEST] <alexpigment> it *should* be a dead technology but it's just not
[01:29:54 CEST] <thebombzen> Yea I guess so
[01:30:10 CEST] <thebombzen> depending on how much control you have over the other side and how willing the recipient is to listening I can understand
[01:30:38 CEST] <thebombzen> if I had to give a video to my grandmother, I'd probably have to use d.vd because she cannot use anything else and she'd refuse to even try because she hates technology
[01:44:00 CEST] <zipwax_> I am trying to build ffmpeg from msys2 on windows, and know enough to put in the architecture type ,but I'm not sure how to distinguish between a release and a debug mode built. I see there are flags for optimization and stripping symbols, but no main flags for debug or release.
[01:50:04 CEST] <JEEB> zipwax_: you get "release" by default, and debug symbols are orthogonal to that
[01:50:20 CEST] <JEEB> stripping symbols does just that - strips (debugging) symbols
[01:50:35 CEST] <JEEB> enable-debug disables optimizations
[01:51:12 CEST] <JEEB> so in that sense a build without any parameters will give you "release" binaries
[01:51:29 CEST] <zipwax_> dat's what I thought. Thanks for the confirmation.
[01:51:33 CEST] <alexpigment> thebombzen: that's *everyone's* grandma :) although my parents are the same way, even after I bought them all kinds of better tech
[01:52:08 CEST] <thebombzen> zipwax_: yea you're going to want to use a release build unless you're debugging
[01:52:27 CEST] <thebombzen> debug builds are debugger-friendly but if you're just running them are slower
[01:52:51 CEST] <thebombzen> alexpigment: I wouldn't say it's everyone's grandma
[01:53:11 CEST] <thebombzen> one of my grandmothers is the one I was referring to. the other one published a paper digital art in the 1970s
[01:53:24 CEST] <thebombzen> as in she published the paper in the 1970s
[01:53:55 CEST] <alexpigment> well, a good percentage at least. still, if you were to go to, say, walmart or target, it's interesting to see that they sell more DVDs than Blu-ray. it sucks, but that's just how it's gone down. Blu-ray is just some weird format to most people
[01:53:56 CEST] <thebombzen> published a paper on* digital art
[01:54:10 CEST] <alexpigment> yeah i hear you. there are certainly exceptions
[01:54:14 CEST] <thebombzen> well keep in mind that hardware takes longer to catch up than software
[01:54:34 CEST] <thebombzen> I'm all for hot off hte press software, i.e. if I wanted the software to play a bluray I can get it very easily for free
[01:54:51 CEST] <thebombzen> but until I bought a new box a few months ago, I could not play blurays
[01:54:58 CEST] <thebombzen> because I didn't have the hardware BD reader
[01:55:12 CEST] <alexpigment> yeah, i only have Blu-ray burners at this point
[01:55:16 CEST] <alexpigment> 3 of them at home
[01:55:20 CEST] <alexpigment> and several players
[01:55:22 CEST] <thebombzen> all BD burners are BD readers
[01:55:26 CEST] <tdr> thebombzen, blueray on linux can still be a royal pain tho
[01:55:28 CEST] <alexpigment> right
[01:55:52 CEST] <thebombzen> tdr: true. I ended up getting libaacs working with a keydb and all the VUKs and all that jazz when I borrowed an external BD reader
[01:55:54 CEST] <alexpigment> i'm just saying, it was an easy tech leap for me to make. there were no downsides, and the prices came down after 2-3 years
[01:55:56 CEST] <thebombzen> it wasn't fun
[01:56:11 CEST] <thebombzen> alexpigment: you're also not 21
[01:56:13 CEST] <alexpigment> are there any free players that do BD-J yet?
[01:56:25 CEST] <thebombzen> libbluray has a java buildin
[01:56:28 CEST] <JEEB> VLC probably, since they maintain libbluray
[01:56:31 CEST] <alexpigment> thebombzen: that's a good assumption (i'm in my 30s)
[01:56:36 CEST] <tdr> thebombzen, even then its a pain. usually use media-video/makemkv to get keys
[01:56:44 CEST] <thebombzen> alexpigment: you said "my parents" and not "my grandparents" so that's why I guessed
[01:56:47 CEST] <JEEB> (I mean the videolan org, and vlc is the primary player with that)
[01:56:55 CEST] <alexpigment> JEEB: interesting. i thought BD-J was still a no-go
[01:57:00 CEST] <thebombzen> well videolan is VLC essentially
[01:57:13 CEST] <thebombzen> VLC is like their thing and all the other stuff is just sideprojects
[01:57:32 CEST] <thebombzen> they want to claim otherwise "libdvbpsi is just as important as VLC" but who are they kidding
[01:57:46 CEST] <zipwax_> hm. well since I'm on this forum, I might as well ask a question that's been pestering me... I want to use ffmpeg to capture video.. but I want it to set an event when there is data available to read. Is this a topic already well described online? I do not want to poll for new data available.
[01:58:01 CEST] <zipwax_> I want to use the libs natively, not through a command line exe.
[01:58:12 CEST] <thebombzen> alexpigment: libbluray has had Java support for years. of course I never build it with --enable-java because their configure script can't find your JVM, even if you use --with-java=
[01:58:14 CEST] <JEEB> well if you're using the libs you can do pretty much anything
[01:58:34 CEST] <JEEB> you have some way of reading when the capture device becomes available and then start reading it :P
[01:58:36 CEST] <zipwax_> can I without it being horribly tedious, is what I mean.
[01:58:38 CEST] <thebombzen> you need to add CFLAGS=-I/usr/lib/jvm/default/jni/include
[01:58:40 CEST] <thebombzen> or something like that
[01:58:53 CEST] <JEEB> well I have NFI what your capture input is or otherwise
[01:59:08 CEST] <thebombzen> zipwax_: what do you mean "when there is data available"
[01:59:23 CEST] <zipwax_> let's say it's a rtsp video receiver. I want to know when it's got some more data for me to parse.
[01:59:24 CEST] <JEEB> nor your design choise or however the systems around it work
[01:59:31 CEST] <zipwax_> or, perhaps a webcam.
[01:59:43 CEST] <thebombzen> zipwax_: if you're reading from a grab device and you want to use the libraries then you have to do that management yourself
[01:59:44 CEST] <zipwax_> (usb)
[01:59:56 CEST] <JEEB> well do you have something that already tells anything that the thing went online?
[01:59:59 CEST] <JEEB> an event
[02:00:15 CEST] <JEEB> because then you can just follow the event and start capture with that
[02:00:16 CEST] <zipwax_> let's assume the rtsp is already online, but it's shoving data at me ... slowly....
[02:00:28 CEST] <zipwax_> right now I'm polling to see if I can read new data. that seems inefficient.
[02:00:31 CEST] <thebombzen> libavformat doesn't care if the RTSP socket has a nonzero amoutn of available data in the buffer because you have to manually put the data there
[02:00:33 CEST] <alexpigment> man, i have a huge blu-ray collection, but i'm drawing a blank on which ones have BD-J. do they all say Java on the back if they use it
[02:00:34 CEST] <alexpigment> ?
[02:01:05 CEST] <thebombzen> but if you're reading from a network socket then I think the default behavior on *nix is to block until data is available
[02:01:08 CEST] <thebombzen> so that shouldn't be a problem
[02:01:08 CEST] <JEEB> well then you just have something tell you when you've got X amount of data :P
[02:01:28 CEST] <JEEB> I really have no idea how much event-based shit you've got already there
[02:01:44 CEST] <JEEB> for the networking crap. libavformat is simple, reads data and that's it
[02:01:54 CEST] <JEEB> which leads to a polling/timeout kind of thing
[02:02:13 CEST] <JEEB> but if you've got an event going every time you get X amount of data or whatever you mean
[02:02:22 CEST] <JEEB> and then you feed that to a demuxer in an event
[02:02:24 CEST] <thebombzen> zipwax_: fyi if you have a question "how can I get the thing I'm doing working" but you don't actually provide information on the thing you're doing then we can't help you
[02:02:41 CEST] <thebombzen> so if you want us to help you, then "what are you actually trying to do" is an important question
[02:03:10 CEST] <thebombzen> you mentioned both a webcam, an RTSP grab, and an RTP grab
[02:03:12 CEST] <JEEB> but yea, basically if you need an event-based thing then you need to have that something that provides you an event
[02:03:14 CEST] <thebombzen> which are all different things
[02:03:25 CEST] <JEEB> and then if you're using the API you can utilize that
[02:03:34 CEST] <JEEB> but if you don't have anything to provide you an event then...
[02:03:46 CEST] <JEEB> hurf durf
[02:04:07 CEST] <zipwax_> I don't mean to be vague, but I'm having trouble formulating the issue beyond what I already described. I am in windows, am using the ffmpeg libraries, and have to deal with all kinds of live devices as inputs to my video cruncher. I'm using the ffmpeg apis, yes, but I'm unclear if the ffmpeg api set allows me to get an event when my stream has "more" live data for me to read or not.
[02:04:09 CEST] <JEEB> I really don't think this has anything to do with libavformat at this point, but general socket programming or whatever
[02:04:46 CEST] <JEEB> zipwax_: no, you need to do that outside of libavformat then. and then you call libavformat in your event callback
[02:05:07 CEST] <JEEB> as far as I understand your goddamn question
[02:05:09 CEST] <zipwax_> my main line: int nRet = av_read_frame(m_pFormatContext, &m_Packet);
[02:06:26 CEST] <zipwax_> mostly my calls are to av_***. I'm not using anything lower level, if that even exists. (I reckon it does)
[02:07:22 CEST] <JEEB> that's the general API. the only alternative is to have your own AVIO stuff which handles the IO
[02:07:34 CEST] <JEEB> which you then specify to the avformat context
[02:07:45 CEST] <JEEB> and then you keep rolling the reading function as usual
[02:07:47 CEST] <zipwax_> that's what I thought. I am thinking I need to go lower level if I want/need an event set.
[02:08:40 CEST] <JEEB> not really lower level for avformat, but you probably will have to start handling stuff specific to the source type yourself, so you have something doing the event-based callbacks :P
[02:08:52 CEST] <JEEB> and then you give that received data to avformat with AVIO or so
[02:09:33 CEST] <zipwax_> uh, sounds awful.
[02:09:43 CEST] <zipwax_> polling it is then.
[02:09:53 CEST] <JEEB> well I'm not sure where the hell you expected those events to magically appear
[02:10:07 CEST] <JEEB> such things generally are specific to your input type
[02:10:16 CEST] <JEEB> be it network or a capture device protocol or whatever
[02:10:34 CEST] <voip_> hello guys, can i have live output it in HLS ?
[02:10:36 CEST] <voip_> ?
[02:10:55 CEST] <thebombzen> HLS isn't designed for live multicast afaik
[02:10:58 CEST] <thebombzen> but I might be wrong about that
[02:11:11 CEST] <zipwax_> ? are you serious ? (I work in the video capture division of MS, in DirectShow). When we get new network streaming data for a network source, we set an event. when we get new video frame data for a USB web cam, we set an event. We bubble these events up into user mode.
[02:11:43 CEST] <voip_> thebombzen, thank you
[02:11:43 CEST] <zipwax_> If ffmpeg were written w/ a push-model in mind, or at least with an event model in mind, it could rig up events to bubble up to the end user of the API set, sure.
[02:12:01 CEST] <thebombzen> voip_: I'd get a second opinion on that
[02:12:16 CEST] <voip_> ?
[02:12:27 CEST] <thebombzen> afaik HLS's primary purpose is to serve video chunks in a way that allows seeking
[02:12:35 CEST] <thebombzen> but it could also support live multicast
[02:12:47 CEST] <thebombzen> but if your goal is live multicast then you should probably consider something dedicated to that
[02:12:55 CEST] <thebombzen> like Icecast, RT(S)P, etc
[02:13:15 CEST] <zipwax_> I dunno, ffmpeg makes it pretty damned easy... :-)
[02:13:22 CEST] <voip_> i am also thinking, like that
[02:14:09 CEST] <thebombzen> zipwax_: that was @voip
[02:14:26 CEST] <voip_> one more question, is it possible live output  in 265 RTMP ?
[02:14:37 CEST] <thebombzen> this one I have absolutely no idea
[02:14:44 CEST] <thebombzen> someone else here will have to answer that
[02:15:06 CEST] <voip_> thebombzen, thank you
[02:17:34 CEST] <zipwax_> thanks folks
[02:18:42 CEST] <alexpigment> i was just looking into VLC and HDMV menus work, but I can't get BD-J menus to work
[02:19:06 CEST] <alexpigment> i have a feeling there's a reason why "No disc menus" is checked by default on Blu-ray disc playback
[02:23:29 CEST] <furq> voip_: rtmp and hls both only support h264
[02:23:54 CEST] <furq> rtmp technically supports some other video codecs but they're all terrible and ancient
[02:31:38 CEST] <voip_> furq, thank you so much
[02:39:14 CEST] <thebombzen> alexpigment: there's also the "why do I want to watch menus instead of my movie"
[02:39:38 CEST] <thebombzen> afaik with mpv the "disable menus by default" is basically "cause that's what we, the developers want. and mpv is configurable so whatever."
[02:58:27 CEST] <marbar> hey yall. so i was in here yesterday seeking help with an hls issue.
[02:58:43 CEST] <marbar> but it turns out it had nothing to do with hls. the problem was that i was serving the media with transfer-encoding chunked
[02:59:15 CEST] <marbar> and ios was choking on split characters or something
[02:59:30 CEST] <marbar> serving w/o transfer encoding chunked works fine. so yeah, ios is terrible.
[02:59:38 CEST] <furq> nice
[02:59:41 CEST] <marbar> :)
[03:00:09 CEST] <marbar> thanks for helping, too. great ios solidarity in this channel.
[04:03:42 CEST] <alexpigment> thebombzen: re: earlier/vlc, i think it's just because the developers are busy watching movies. as i implied earlier movies aren't the only type of DVDs/Blu-rays. I own hundreds of DVDs, the vast majority of them are music video DVDs from various artists. also with Blu-ray, the whole point of owning - to me - is the special features. the movie itself could be purchased digitally if i didn't
[04:03:42 CEST] <alexpigment> care about those. having said all that, i don't care too much about VLC playback, other than knowing it might be able to support my own BD-J authored discs. it's certainly not mission critical
[04:04:18 CEST] <thebombzen> alexpigment: you are correct, the devs mostly watch movie d.vds which is why I said "it's what we want, and it's configurable anyway"
[04:04:43 CEST] <thebombzen> you can turn off the "menus are disabled" functionality in VLC and mpv, it's just enabled by default because that's what most people (read: the developers) want
[04:13:19 CEST] <alexpigment> thebombzen: understandable. all i know is i tried 2.2.4, and BDMV menus worked (after all the aacs stuff was in place), but BD-J didn't. i updated java and installed a 3.0.0 nightly and it still didn't work. that's the extent of how much i'll probably test, but i just wanted to report back my findings
[08:00:02 CEST] <hendry> is there something better than ffmpeg -f pulse -i default test.wav ? i.e. prevent  Non-monotonous DTS in output stream 0:0; and large wav files ?
[08:26:51 CEST] <LongChair1> Does anyone knows when the new libav bistreaming feature for codecs will land in ffmpeg ?
[08:27:00 CEST] <LongChair1> bitstreaming*
[08:30:34 CEST] <JEEB> I don't think that is what you think it is
[08:30:42 CEST] <LongChair1> uh ?
[08:30:55 CEST] <JEEB> they didn't add bitstreaming additions
[08:31:02 CEST] <LongChair1> i'm talking about this : https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/avcodec.h;h=1c58fe2d689c1c3daca248208c1e2154737e7568;hb=HEAD#l2859
[08:31:14 CEST] <JEEB> it's a new bitstream reader api
[08:31:26 CEST] <JEEB> which they're not 100% sure is ready
[08:31:29 CEST] <LongChair1> if i'm right it allows to get bistream packets in decoder rather than bitstream them inside the decoder or ?
[08:32:06 CEST] <JEEB> no
[08:33:15 CEST] <JEEB> also the thing you linked just seems to be a list of bitstresm filters which sounds like the automatic bitstrram filtering thing
[08:33:24 CEST] <LongChair1> that is what comment says at least :)
[08:33:59 CEST] <LongChair1> yes that is what i'm talking about, avoiding to have to bitstream packets inside the decoder, and get directly bitstreamed data
[08:34:16 CEST] <JEEB> uhh
[08:34:46 CEST] <JEEB> now you're once again talking about bitstrraming which is usually about s/pdif or hdmi audio
[08:34:49 CEST] <LongChair1> typically for h264 / hevc _annexb
[08:35:08 CEST] <JEEB> right
[08:35:12 CEST] <LongChair1> no i'm talking about bistream filters
[08:36:23 CEST] <LongChair1> the decoder i'm working on needs annexb streams, so I do that inside decoder, that feature would remove soem code :)
[08:37:12 CEST] <JEEB> yea if that is that. see when it was added and you can see if it has been merged already
[08:38:27 CEST] <JEEB> too bad in general merging from libav seems to be heavily disliked by  some people in FFmpeg so many people end up giving up in order to not have to go through various levels of pain
[08:39:05 CEST] <LongChair1> JEEB: i can't see that in ffmpeg : https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/avcodec.h#L3781
[08:39:19 CEST] <JEEB> also if it isn't merged yet and you'd like it you could poke ffmpeg-devel with a patch
[08:39:55 CEST] <JEEB> LongChair1: also just fyi git.videolan.org repo is the official one :)
[08:40:06 CEST] <LongChair1> I have no idea what this patch involves, just found that the feature was nice and i could use it :)
[08:43:31 CEST] <JEEB> just look at the git log?
[08:44:05 CEST] <JEEB> but yeah if nothing else make a ticket on the bug tracker that you'd like the feature
[10:19:39 CEST] <thebombzen> welp, TIL that building libvpx from source can be a problem
[10:28:08 CEST] <dv__> is there a video format that can be used for endless recording in a ringbuffer-like manner? like a tape that goes back to the beginning when it is full?
[10:44:13 CEST] <furq> dv__: i don't know if you can do it in a single file, but -segment_wrap does something similar
[10:44:33 CEST] <furq> !muxer segment
[10:44:33 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[10:45:55 CEST] <dv__> ah yes, I already thought of that idea as a plan B
[10:46:15 CEST] <dv__> to just create a bunch of files of fixed length, similar in concept to how log rotation works
[10:46:52 CEST] <dv__> aside from that, I doubt it can be done ... I don't even know if you can reliably detect that the disk is full & then seek back to the beginning of a file
[10:47:43 CEST] <furq> you'd probably end up with timestamp discontinuity issues when you tried to play it back
[10:48:22 CEST] <furq> without some specialised thing to play it back from head
[12:00:11 CEST] <JEEB> LongChair1: I see you didn't report the thing on trac wrt that thing from Libav?
[12:02:22 CEST] <LongChair1> not yet
[12:03:04 CEST] <LongChair1> i dunno if asking for that there would be so suefl, i'd probbaly get a "sure, you can do it :p "
[12:03:19 CEST] <LongChair1> and i have no time to do that ...
[12:34:27 CEST] <dv__> furq: my guess as well
[12:37:44 CEST] <dv__> furq: I'll ask around some more, but I think i'll just go with the segment-based approach
[13:05:36 CEST] <acamargo> hello, do you guys have any how-to/tutorial about using ffmpeg with unix sockets to suggest me?
[13:12:52 CEST] <thebombzen> dv__: depends on what you're doing
[13:13:02 CEST] <thebombzen> for example OBS capture supports a "replay buffer"
[13:13:15 CEST] <thebombzen> which essentially is a sliding-window style recording
[13:13:36 CEST] <thebombzen> but it does it in memory so it's limited to around a minute to two minutes depending on how much ram you have
[13:13:40 CEST] <dv__> I need this for a continuous live cam feed recording
[13:13:55 CEST] <dv__> the feed is compressed with baseline h.264
[13:14:02 CEST] <thebombzen> how large of a "ring buffer" are you looking for
[13:14:07 CEST] <thebombzen> and where you looking to put it
[13:14:09 CEST] <dv__> as large as the SD card on the device
[13:14:49 CEST] <thebombzen> yea, tbh using a segment muxer with mpegts is probably the easiest way to do that
[13:14:59 CEST] <thebombzen> just set the segment size to be one group of pictures
[13:15:09 CEST] <thebombzen> which is usually like ten seconds
[13:15:34 CEST] <thebombzen> and you can use the -segment_wrap option to tell it to start overrwriting after wirting a certain number of segments
[13:16:50 CEST] <thebombzen> acamargo: that's a very vague question
[13:17:07 CEST] <thebombzen> what are you actually trying to do
[13:19:13 CEST] <acamargo> thebombzen, nowadays I'm using a multicast streaming to provide input for several ffmpeg transcoding processes... but multicast is flooding the network :-) I'd like to try another approach, so I was thinking to stream to a unix socket and make the other processes to read from it
[13:20:09 CEST] <thebombzen> well if that's the case why is using ffmpeg with sockets any different than using sockets in general
[13:20:20 CEST] <thebombzen> if you're referring to using ffmpeg to do realtime encoding with sockets
[13:20:39 CEST] <thebombzen> I'm going to stop you right there and say that using the ffmpeg CLI tool to do streaming stuff might work
[13:20:41 CEST] <thebombzen> but you shouldn't expect it to
[13:20:53 CEST] <thebombzen> because you don't have good control over the buffers with ffmpeg's CLI tool
[13:21:07 CEST] <thebombzen> if you want to anyway, named pipes are probably easier
[13:21:40 CEST] <thebombzen> Also you do realize that FFmpeg can do multiple outputs at once, right?
[13:22:03 CEST] <thebombzen> ffmpeg -i input output1_opts output1 output2_opts output2 etc.
[13:22:53 CEST] <acamargo> I'm building a live encoder
[13:22:58 CEST] <thebombzen> like ffmpeg -i input.mkv -c:v libx264 -b:v 6M -c:a aac -b:a 128k output1.ts -c:v libvpx -b:v 6M -c:a libopus -b:a 128k output2.webm
[13:23:14 CEST] <thebombzen> ^ this allows you to transcode all at once with one process
[13:23:25 CEST] <thebombzen> you don't need to split the input and pipe it to several encoding processes
[13:23:26 CEST] <acamargo> one ffmpeg can capture and overlay and transcode up to 6 streams
[13:23:36 CEST] <thebombzen> it can do significantly more than that actually
[13:23:49 CEST] <acamargo> in my dell R610
[13:24:05 CEST] <BtbN> It's not efficient to do multiple encodes in the same ffmpeg process
[13:24:41 CEST] <acamargo> BtbN, I see. when I tried one process cpu load was about 30%
[13:24:50 CEST] <thebombzen> either way, if you want to do separate encodes, the easiest way is to split your input and feed it to separate encoding processes
[13:25:03 CEST] <acamargo> BtbN, when I ran multiple processes I can use better the cpu
[13:25:17 CEST] <thebombzen> you can probably write a 10line c program to output stdin to all the files specified on the command line
[13:25:27 CEST] <thebombzen> and pipe those to ffmpeg
[13:25:41 CEST] <thebombzen> you can also do it with "tee" but I don't know how efficient that is
[13:26:22 CEST] <acamargo> yeah, my problem is the "distribute" the output to several processes
[13:26:37 CEST] <acamargo> multicast do it well... until my netadmin complain
[13:26:38 CEST] <acamargo> hahahaha
[13:26:39 CEST] <acamargo> :-)
[13:27:16 CEST] <acamargo> so I started to search a workaround
[13:28:01 CEST] <acamargo> capture process generating a hls and the streaming processes reading it worked very well... until I notice the latency :-(
[13:29:19 CEST] <acamargo> I also need to generate a preview and a "program" output in the UI
[13:29:30 CEST] <acamargo> so things gets worse
[13:30:38 CEST] <acamargo> I wish I would open source this code
[13:31:17 CEST] <acamargo> I'm trying to convince my boss to open it
[13:31:19 CEST] <acamargo> let's see
[13:34:32 CEST] <BtbN> Just write to a fifo
[13:39:17 CEST] <acamargo> BtbN, I'll try
[17:14:29 CEST] <choki> Does it make sense to use -vcodec copy and -crf together?
[17:14:51 CEST] <choki> I see no error message so far..
[17:15:37 CEST] <kepstin> choki: the option -crf will just be ignored in that case (iirc it should print a warning)
[17:15:48 CEST] <choki> kepstin: you're right!
[17:22:28 CEST] <kepstin> choki: but in general - using "-c:v copy" bypasses the video filtering and encoding, so it doesn't make sense to add any video encoding or filtering options when you use it.
[17:22:42 CEST] <kepstin> some will result in errors, others will just be ignored
[17:27:18 CEST] <choki> kepstin: i just want to reduce filesize with -crf, so can i omit any -vcodec -c:v copy param?
[17:27:49 CEST] <kepstin> choki: if you want to reduce the filesize, you need to re-encode the video, so specify an actual codec instead of "copy"
[17:28:09 CEST] <choki> it is already h264 which is what i want
[17:28:22 CEST] <kepstin> (if you remove it, it will pick some default based on the file format, but it's always better to specify which encoder you want)
[17:28:34 CEST] <kepstin> it doesn't matter what it currently is... :)
[17:28:51 CEST] <kepstin> you're re-encoding it, so you can pick any format as the output :)
[17:28:57 CEST] <choki> i kinda feel overhelmed of all that options ffmpeg has :/
[17:30:24 CEST] <kepstin> I assume you're writing an mp4 output? in that case, you'd probably want to use a command like "ffmpeg -i input.mp4 -c:a copy -c:v libx264 -crf 20 output.mp4"
[17:30:45 CEST] <choki> kepstin: awww thank you! :3
[17:30:54 CEST] <kepstin> adjust the crf as you like for quality. If you want the best quality and don't mind waiting a bit longer, also add "-preset veryslow"
[17:31:39 CEST] <kepstin> in this command, i used "-c:a copy" to copy the audio without re-encoding, because the audio is usually already pretty small.
[17:33:31 CEST] <choki> i already use -an it has no audio :D
[17:35:01 CEST] <ChocolateArmpits> Odd question, but do applications that utilize ffmpeg use the codebase more often or do they use compiled binaries and just pass parameters like in cli?
[17:37:25 CEST] <jrun> i used makemkv to rip my blurays now i want to copy (no transcoding unless i need to) the audio file into my phone for listening. i'm running this:
[17:37:27 CEST] <jrun> ffmpeg -i 00274.m2ts -map 0:1 -acodec copy 00274.dts
[17:37:44 CEST] <kepstin> ChocolateArmpits: I'd expect it to be a bit of a split. Open-source applications tend to use libavcodec et all directly, I think a fair number of commercial apps do as well (with LGPL builds), but commercial stuff that wants GPL features might use the ffmpeg cli, and a lot of open-source stuff just scripts the cli... so :/
[17:38:05 CEST] <jrun> on this file:
[17:38:12 CEST] <jrun> https://gist.github.com/b1da6724b9a8f7687fdb85c15068a306
[17:39:01 CEST] <kepstin> jrun:well, the audio is not dts (it's uncompressed PCM), so I'm not sure how you'd expect to save that in a ".dts" file.
[17:39:03 CEST] <jrun> any idea to improve this... i will also add that copying into dts is probably not a good idea because i'm not sure if android can play it back (stock android music play or some other player)
[17:39:32 CEST] <jrun> kepstin: does that have to *wrapped* in a container?
[17:39:39 CEST] <kepstin> jrun: you should either save it as a wav file - but that might need some format conversion - or just encode to some lossy format that you know works with the phone
[17:39:50 CEST] <jrun> can i, without absolutely any compression, use something like flac for that?
[17:40:09 CEST] <kepstin> well, flac is a compression codec, but it's lossless...
[17:40:21 CEST] <kepstin> you have to check what your phone can play before deciding
[17:40:35 CEST] <jrun> what's the format that would preserve every bit of this?
[17:40:35 CEST] <kepstin> keep in mind that a wav file or flac file will probably be very, very large
[17:40:43 CEST] <kepstin> wav or flac would both do fine
[17:41:12 CEST] <jrun> flac should have a "dont-compress" way of doing it no?
[17:41:28 CEST] <kepstin> jrun: why would you bother? it's lossless compression, and it's super-fast to decode
[17:41:51 CEST] <kepstin> flac saves you disk space without losing any bits.
[17:42:20 CEST] <jrun> does ffmpeg guess from output file name how to transcode? or do i need ot pass more flags?
[17:42:47 CEST] <kepstin> jrun: ffmpeg will guess the codec from the output name by default, but you can override it if you want, or if it picks the wrong thing
[17:44:07 CEST] <jrun> so i'm doing -acodec flac. does flac work like jpeg that one can have different levels of compression and of course with that different lossless-ness?
[17:44:13 CEST] <jrun> if that makes any sense :)
[17:44:43 CEST] <kepstin> flac is always lossless
[17:45:13 CEST] <kepstin> it's like png, not jpeg :)
[17:45:13 CEST] <jrun> you're right, this is gonna give a massive file. i guess i would like to do it by chapters.
[17:45:21 CEST] <jrun> i see
[17:45:48 CEST] <jrun> can ffprobe list the chapters?
[17:46:01 CEST] <kepstin> getting chapters with bd stuff is a pain, the're not stored int he m2ts files but are rather external metadata
[17:46:23 CEST] <jrun> the bluray structure is new to me sorry
[17:46:40 CEST] <kepstin> i think ffmpeg has a blu-ray reading format which you can try? I haven't used it myself.
[17:46:46 CEST] <jrun> i have the whole fs structure of the bluray on the disk
[17:46:52 CEST] <jrun> i see all those meta datas
[17:47:06 CEST] <alexpigment> bdedit is a good probably to use btw
[17:47:36 CEST] <alexpigment> it'll show you the details of all the metadata. those files aren't usually human-readable
[17:49:01 CEST] <jrun> my distro doesn't seem to have it. is it just a perl script?
[17:49:18 CEST] <jrun> that's windows stuff, hmm.
[17:49:46 CEST] <kepstin> jrun: if you build your ffmpeg with libbluray support, you can try this: https://www.ffmpeg.org/ffmpeg-protocols.html#bluray
[17:50:14 CEST] <kepstin> it probably won't work on copy protected disks, but if you've got an unencrypted bd on your drive it should be ok
[17:50:56 CEST] <kepstin> (doesn't look like it has a "stop at chapter" feature tho, which will make splitting things kinda tricky)
[17:53:38 CEST] <jrun> if i could just get a list of them and see if i can map the chpaters to streams.
[17:54:08 CEST] <jrun> nice!
[17:54:22 CEST] <jrun> ffprobe bluray:/mnt/bd
[17:54:41 CEST] <jrun> where /mnt/bd is where i have the disk mounted. listed pretty much everything
[17:55:08 CEST] <jrun> or did it?
[17:55:21 CEST] <jrun> https://gist.github.com/471f6f9ca3e277adcd454ab7b925cc5b
[17:55:46 CEST] <ChocolateArmpits> kepstin, I'm used to just building up the parameter list in my scripts and running the application. Is there something about using the codebase better than this?
[17:55:52 CEST] <kepstin> it listed the playlists (similar to "titles" on a dvd), but not the chapters :/
[17:56:32 CEST] <kepstin> ChocolateArmpits: if you're doing realtime stuff, or are writing an application that is manipulating frame images directly, it's a lot better to use the library
[17:57:35 CEST] <jrun> on a different note, content on bluray itself is encoded in h264; then why people take that and encode again in h264?
[17:57:41 CEST] <kepstin> you can sometimes hack it with pipes, e.g. I have a video renderer that puts raw frames on stdout piped into ffmpeg, but that's kinda hacky and sometimes slow due to the extra read/write calls and memory copying :/
[17:57:47 CEST] <kepstin> jrun: because bds are huge
[17:58:54 CEST] <kepstin> if you ignore the vbv/level limits required on bd, you can get a significantly smaller file that doesn't look much worse
[17:59:30 CEST] <alexpigment> does anyone know if there's a way to pad or add null packets to MPEG-2 video to match the specified bitrate if it falls several mbps below?
[18:00:13 CEST] <kepstin> alexpigment: i don't think you need to do that on dvd..? that sort of thing is only needed for stuff like over-the-air tv broadcast where you have fixed-size cells
[18:00:40 CEST] <alexpigment> yeah it's more about just matching user expectation (i.e. you said this wouldn't fit and it definitely does)
[18:01:00 CEST] <alexpigment> trying to avoid that if at all possible
[18:04:57 CEST] <kepstin> alexpigment: in any case, I think that sort of padding is normally done with null frames in mpeg-ts, I don't think there's an equivalent in mpeg-ps (vob)
[18:06:32 CEST] <kepstin> alexpigment: I could be wrong tho, might want to check what the '-muxrate' option does :/
[18:08:55 CEST] <jrun> 352.92 MiB; not so bad. i guess because it's mono. still 24bit at 48kHz
[18:09:19 CEST] <jrun> kepstin: that's the flac file. i think it's should be fine. this is what ffprobe says:
[18:09:43 CEST] <jrun> https://gist.github.com/0568e533a687689f22c23bdc59ca0fa4
[18:45:29 CEST] <alexpigment> kepstin: that's what i figured, i just wanted to ask. currently using muxrate already
[19:13:00 CEST] <t3v4> hello
[19:13:13 CEST] <t3v4> is here anybody who can help me with normalization of AV_SAMPLE_FMT_S16
[19:13:17 CEST] <t3v4> *AV_SAMPLE_FMT_FLT
[19:26:14 CEST] <zeryx> what's the best way of downscaling (compressing) a video file with ffmpeg?
[19:26:21 CEST] <zeryx> I feel like this is probably a super common usecase
[19:26:45 CEST] <zeryx> I have a raw input video file that I want to compress using some generic compression that will work reliably with most codecs & containers
[19:27:25 CEST] <zeryx> unless I'm missing the fact that an encoding operation is exactly this compression setp
[19:28:32 CEST] <zeryx> yep I'm missing that
[19:29:26 CEST] <roasted> hi friends
[19:30:01 CEST] <roasted> might be a dumb question but trying to brew up a solution to something I'm facing. Can I leverage ffmpeg to take in an RTMP stream and on the same box, rebroadcast it to a multicast address for other clients to connect to?
[19:44:30 CEST] <zeryx> is it possible to set the encoding level during a video concat step using the concat muxer?
[19:45:25 CEST] <zeryx> like does ffmpeg -framerate $n -i images-%05d.jpg -c:v libx264 -preset veryfast -crf 35 someVideo.mp4
[19:45:27 CEST] <zeryx> work*
[19:46:21 CEST] <BtbN> why wouldn't it?
[19:47:03 CEST] <zeryx> because I have no idea how ffmpeg CLI arguments work together
[19:49:05 CEST] <llogan> zeryx: what do you mean by "encoding level"?
[19:53:42 CEST] <Accord> is this legit? https://evermeet.cx/ffmpeg/
[19:54:03 CEST] <Accord> what site would you recommend for statically linked ffmpeg for osx?
[19:56:23 CEST] <kepstin> Accord: that's the site linked to from https://ffmpeg.org/download.html so it's probably ok
[19:56:34 CEST] <Accord> ah, didn't check that
[19:56:35 CEST] <Accord> thanks
[20:47:48 CEST] <IRConan> how easy would it be to take a v4l2 and a pulseaudio input and combine them into a file while displaying the video using Xv using ffmpeg libraries?
[20:59:37 CEST] <alexpigment> does anyone understand the "N" and "M" frames for DVD?
[20:59:48 CEST] <alexpigment> N, as I understand, is the GOP length
[21:00:00 CEST] <alexpigment> but M seems to be derived in some other way
[21:00:27 CEST] <alexpigment> although i believe N should be easily divisible by M
[21:02:31 CEST] <alexpigment> at any rate, if i set closed GOP with the cgop flag and i set the GOP length as 18 and the b frames to 2, i get a video that's M=3, N=16, which is just wrong
[21:06:04 CEST] <kepstin> where are you getting those numbers from?
[21:06:22 CEST] <alexpigment> mediainfo, but i confirmed the N value in VideoRedo
[21:07:00 CEST] <alexpigment> is it possible N=18 and 2 b frames is incompatible with closed GOP?
[21:08:14 CEST] <alexpigment> i get the impression that mpeg2video assumes that cgop means there's a final P frame before the next I frame
[21:08:16 CEST] <alexpigment> i don't know if this is true
[21:08:34 CEST] <alexpigment> but if it is, then i suppose that would make N=18 and 2 b-frames impossible
[21:09:43 CEST] <kepstin> hmm, so N=18 N=3 should be IBBPBBPBBPBBPBBPBBI I think?
[21:09:48 CEST] <kepstin> that is kinda weird :/
[21:10:44 CEST] <kepstin> looks like closed gop does have to end in a P frame, yeah
[21:11:29 CEST] <alexpigment> so for DVDs that do multi-angle (where CGOP is required), i wonder what their N value is
[21:13:04 CEST] <kepstin> assuming you're using 2 B frames, it would either have to be 16 or 19 I guess :/
[21:13:53 CEST] <kepstin> or alternately, the last group of B frames could be shorter, like IBBPBBPBBPBBPBBPBPI
[21:14:24 CEST] <alexpigment> yeah, i don't think there's a way to tune that though
[21:14:32 CEST] <alexpigment> (or if there is, i haven't used it before)
[21:14:35 CEST] <kepstin> not with the ffmpeg cli, yeah
[21:14:47 CEST] <alexpigment> at any rate, i'm going to have to just assume that CGOPs aren't that important
[21:14:51 CEST] <kepstin> you could probably do it with the api by forcing an I frame in the right spot? :/
[21:14:53 CEST] <kepstin> dunno
[21:15:05 CEST] <alexpigment> even if rewinding/fast-forwarding is technically "better" with CGOP
[21:15:35 CEST] <kepstin> hmm, interesting. dvd chapter markers can only be set at the beginning of a CGOP
[21:15:42 CEST] <alexpigment> eh, i'm not too concerned about it, i suppose. just trying to make sure that my files match the specs and recommended settings so that I don't have to do DVD player testing like I did a long time ago
[21:15:50 CEST] <alexpigment> right
[21:16:03 CEST] <alexpigment> chapters and seeking is the main advantage for CGOP
[21:16:30 CEST] <alexpigment> although alternate camera angles require it too (not important for me)
[21:17:12 CEST] <kepstin> my experience on the few dvds I have that use multi-angle is that the quality loss is really bad :/
[21:17:36 CEST] <kepstin> since you basically get half the bitrate per angle, more or less :/
[21:18:15 CEST] <alexpigment> yeah, it's a bit of a novelty feature, although i have a lot of concert DVDs that use it
[21:18:27 CEST] <alexpigment> (and honestly i still don't care about it)
[21:18:41 CEST] <alexpigment> i trust the director's choices ;)
[21:18:53 CEST] <kepstin> for a brief period of time, some anime dvds used it to swap between video with english text and video with japanese text
[21:19:13 CEST] <kepstin> but that was usually during the opening/closing animations, which are the parts most likely to run out of bitrate anyways...
[21:19:18 CEST] <kepstin> the result was generally pretty bad
[21:19:19 CEST] <alexpigment> but yeah, i think DVD is supposed to be M=3,N=15 or M=3,N18 for NTSC
[21:19:24 CEST] <alexpigment> yeah it sounds like a bad idea ;)
[21:19:45 CEST] <alexpigment> so i don't know how to get CGOP and the correct GOP length here...
[21:20:25 CEST] <alexpigment> unless, of course, M is derived in a different way than i think it is. currently my experience is that 2 b-frames gives you an M value of 3
[21:20:40 CEST] <kepstin> yes, that's correct
[21:25:07 CEST] <kepstin> hmm, a brief look at the mpegvideo_enc code makes it seem like they're tring to handle this case
[21:25:24 CEST] <alexpigment> what do you mean?
[21:25:57 CEST] <kepstin> there's some code that in closed gop mode attempts to reduce b-frames before an iframe so it can add a P
[21:26:33 CEST] <alexpigment> well, it seems like that's not working ;)
[21:26:49 CEST] <alexpigment> perhaps it doesn't work with 30i, which is all i'm testing right now
[21:26:49 CEST] <kepstin> what do you have -b_strategy set to?
[21:27:09 CEST] <kepstin> (try setting that to 2 maybe)
[21:27:12 CEST] <alexpigment> i'm not explicitly setting it at the moment, but i can do those 3 tests pretty easily
[21:28:47 CEST] <alexpigment> oh yeah, i just remembered why i'm not using b_strategy 2 anymore ;)
[21:28:50 CEST] <alexpigment> wayyy sower
[21:28:51 CEST] <alexpigment> *slower
[21:31:45 CEST] <alexpigment> b_strategy 2 makes MediaInfo show the GOP as variable
[21:31:48 CEST] <zeryx> are the crf compression values on the same scale as the jpeg compression scale?
[21:32:09 CEST] <kepstin> hmm, this code is kind of hard to read, but I guess it should work with strategy 0 as well. assuming it's not at the end of the video stream, that should statically set 2 bframes, then the code below should be handling removing one and adding a p :/
[21:32:12 CEST] <alexpigment> and also the first gop i stepped through in VideoRedo was only 12 in length with a really odd arrangement of frames
[21:32:26 CEST] <alexpigment> k, trying 0 and then 1 afterward
[21:32:54 CEST] <kepstin> zeryx: no. the 'crf' values are on a separate scale per codec (and indeed also different between 8bit and 10bit versions of codecs)
[21:33:07 CEST] <kepstin> zeryx: the only thing that's common is that lower numbers are higher quality.
[21:33:29 CEST] <zeryx> ugh ok
[21:33:39 CEST] <zeryx> I was hoping I could simplify my input by only taking a single value and using it for both
[21:34:05 CEST] <zeryx> (I'm doing a video split to frames, process frames, concat back to video with compression operation)
[21:35:07 CEST] <kepstin> alexpigment: have you tried -mpv_flags strict_gop ?
[21:36:43 CEST] <kepstin> hmm. it looks like setting closed gop automatically disables scene change detection, so that shouldn't be causing it to do keyframes early
[21:37:01 CEST] <shaki> u,m anyone there?
[21:37:34 CEST] <alexpigment> kepstin: no i haven't. trying that now
[21:38:00 CEST] <alexpigment> also, i had to set scene detection to 1000000000 for some reason earlier
[21:38:02 CEST] <alexpigment> so it's already set
[21:38:31 CEST] <alexpigment> i think it said some value is imcompatible with it
[21:38:37 CEST] <shaki> I'm having trouble in my git clone command in ssh, anyone to help? :)
[21:38:38 CEST] <alexpigment> anyway, trying strict_gop now
[21:39:19 CEST] <kepstin> alexpigment: oh, it doesn't automatically disable it, it just prints an error saying to set it to 1000000000
[21:39:20 CEST] <kepstin> hah
[21:40:28 CEST] <kepstin> alexpigment: ah, yes, the strict_gop flag is what triggers the code to to an odd number of B frames at the end of a gop
[21:40:35 CEST] <kepstin> that should do it :)
[21:40:56 CEST] <kepstin> (without that flag, it just ends the gop early)
[21:43:36 CEST] <kepstin> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpegvideo_enc.c#L1686-L1695 if you're curious
[21:47:31 CEST] <alexpigment> wow
[21:47:33 CEST] <alexpigment> that's it
[21:47:53 CEST] <alexpigment> man, thank you so much for this. so much of this stuff is undocumented without looking in the source code, i guess
[21:47:59 CEST] <kepstin> yeah :/
[21:48:04 CEST] <alexpigment> i'm going to have to read up on that link you sent
[21:49:03 CEST] <alexpigment> man, reading code sucks (and I'm not a true programmer anyway), but I guess this is the best resource for figuring out this janky encoder ;)
[21:49:09 CEST] <alexpigment> thanks again, kepstin
[21:49:28 CEST] <kepstin> the documentation for the strict_gop flag is "Strictly enforce gop size", which is not particularly helpful, but if you're problem is that the gop size is wrong, it's worth a try :)
[21:49:48 CEST] <alexpigment> yeah true :)
[21:54:53 CEST] <kepstin> alexpigment: once you get this all working, please do share your ffmpeg command line, I'd like to compare it with what I've been doing :)
[21:55:04 CEST] <alexpigment> sure thing
[21:55:14 CEST] <alexpigment> i'm close to being done with it
[21:55:33 CEST] <alexpigment> i took what you had, decided it was too slow and kinda started from scratch
[21:55:45 CEST] <xtina> hey y'all. i'm almost finished with my Pi Zero livestreaming project! Thanks to your help i've figured out how to prevent any packet loss even if i record from low wifi signal areas for lots of time
[21:55:50 CEST] <xtina> i have one question
[21:56:01 CEST] <kepstin> yeah, what I wanted to do was simply attempt to max out mpeg2 quality.
[21:56:10 CEST] <kepstin> within the dvd restrictions
[21:56:20 CEST] <xtina> sometimes if i'm in a low wifi signal area for enough time, YouTube Live won't receive packets for a while and will think the stream is completed, and close it. then, even if ffmpeg continues sending packets, they go nowhere
[21:56:43 CEST] <xtina> i need my bash script to know when youtube live marks a stream as complete (which i can easily see from my browser's dashboard) and then re-run the ffmpeg command
[21:57:03 CEST] <xtina> any ideas how the Pi can figure out when it needs to do this?
[21:57:35 CEST] <kepstin> xtina: that's strange - with rtmp, it's a tcp connection, so when youtube stops accepting video it should eventually get a connection reset by peer which causes ffmpeg to exit
[21:57:59 CEST] <xtina> oh, so ffmpeg should exit when this happens
[21:58:07 CEST] <kepstin> it depends on the youtube side
[21:58:15 CEST] <alexpigment> kepstin: what i've found is that 1-pass is just horrible. 2-pass seems to be better even when the average bit rate is quite a bit lower. i know that sounds like a "duh" statement, but it really doesn't make too much sense to use CBR at a high bitrate ever
[21:58:17 CEST] <kepstin> that's what i'd *expect*, but it won't necessarily happen
[21:58:19 CEST] <xtina> hmm, let me double check whether that's the case
[21:58:25 CEST] <xtina> gotcha
[21:58:50 CEST] <Easyfab> Hi, is it possible to use a fraction  or % of total duration  for seeking -ss ? for example  -ss  1500/25
[21:59:56 CEST] <kepstin> Easyfab: there's nothing builtin to the ffmpeg cli to do that.
[22:00:30 CEST] <llogan> you can get duration first with ffprobe then use that info to get your desired -ss
[22:01:06 CEST] <Easyfab> yes so i should use ffprobe and set a variable .
[22:01:07 CEST] <kepstin> ffmpeg does probe the input file durations, so it's theoretically possible to add, just nobody's done it.
[22:35:25 CEST] <alexpigment> kepstin, here's what i think i've settled on:
[22:35:29 CEST] <alexpigment> -f dvd -c:v mpeg2video -target ntsc-dvd -pix_fmt yuv420p -s 720x480 -aspect 16:9 -b:v 4550000 -maxrate 9000000 -bufsize 1835008 -packetsize 2048 -muxrate 10080000 -r 30000/1001 -top 1 -g 18 -keyint_min 18 -bf 2 -flags +ilme+ildct+cgop -mpv_flags strict_gop -sc_threshold 1000000000 -color_primaries smpte170m -color_trc smpte170m -colorspace smpte170m -c:a ac3 -ac 2 -ar 48000 -b:a 384000
[22:36:08 CEST] <alexpigment> that's a 16x9 480i30 preset at 4.55mbps, which gives you ~2hrs on a standard 4.7GB DVD
[22:36:45 CEST] <kepstin> cool, thanks
[22:37:41 CEST] <alexpigment> so i'm not really specifying anything crazy with the motion estimation or the dia, but i am defining a lot of parameters explicitly rather than relying on just the -target parameter
[22:38:13 CEST] <kepstin> yeah, I don't think the -target parameters actually get things quite right :)
[22:38:21 CEST] <alexpigment> yeah, i got that feeling
[22:38:32 CEST] <alexpigment> but i didn't want to neglect something, so i left it in just in case
[22:38:34 CEST] <kepstin> they'll porbably play on most dvd players, but that's simply due to players being more lenient
[22:38:52 CEST] <alexpigment> as i understand it, anything you specify explicitly overrides what's set by using -target
[22:39:58 CEST] <alexpigment> i decided to go conservative on the maxrate because a) not sure what would happen on older/crappier hardware, and b) that's what Premiere caps it at as well
[22:41:02 CEST] <kepstin> if you're curious, the list of stuff the -target option sets is here: https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_opt.c#L2782
[22:42:20 CEST] <kepstin> capping the maxrate around there is common, because you have to account for audio tracks and muxing overhead, yeah
[22:44:44 CEST] <alexpigment> Adobe Encore is a sticker for that stuff. if the video bitrate + audio bitrate ever spikes above the limit in a VBR encode, it just says "nope" and fails
[22:44:51 CEST] <alexpigment> a *stickler*, rather
[22:45:37 CEST] <alexpigment> i suppose it's a good thing, but they're like the Sony of the software world when it comes to adhering to specs that don't usually matter in the real world
[22:45:47 CEST] <kepstin> alexpigment: if the dvd muxer exceeds the muxrate, ffmpeg will print some nasty warnings, I think
[22:45:54 CEST] <kepstin> i forget whether it actually fails the encode
[22:46:34 CEST] <alexpigment> does that account for fluctuations due to vbv?
[22:47:11 CEST] <alexpigment> like it can still exceed the maxrate if the bufsize allows for it, right?
[22:48:07 CEST] <alexpigment> at any rate, i'm not complaining. i've just fought with Adobe Encore more times than i can count
[22:49:35 CEST] <kepstin> well, if your vbv is set correctly, you'll never exceed the muxrate :)
[22:50:27 CEST] <alexpigment> true
[22:59:07 CEST] <alexpigment> weird, i was pretty on the money with a lot of these options that -target ntsc-dvd sets
[23:00:23 CEST] <alexpigment> i also saw there's a comment about the minrate being 1500000 even though 0 is used. i almost used minrate of 1.5mbps to better match what Premiere does, but ffmpeg really complains if you set minrate to something other than zero ;)
[23:09:39 CEST] <BtbN> I'm pretty sure minrate is not a parameter for libx264
[23:10:06 CEST] <alexpigment> i seem to recall that it isn't or that it doesn't get used
[23:10:21 CEST] <alexpigment> at any rate, this is for mpeg2video
[23:11:32 CEST] <kepstin> i wouldn't be surprised if it only supports the minrate = maxrate case for padded cbr, or something like that
[23:12:16 CEST] <alexpigment> man, i've already forgotten all the research i did on CBR/VBR with x264
[23:12:37 CEST] <alexpigment> but min=max works pretty well with mpeg2video, surprisingly
[23:13:35 CEST] <alexpigment> according to my notes, this works OK to make CBR x264: -b:v 5000000 -maxrate 5000000 -minrate 5000000 -nal-hrd cbr
[23:14:15 CEST] <alexpigment> although of course my notes then say "not useful at all unless you need to predict the final output size" ;)
[23:14:59 CEST] <kepstin> or if you're doing tv broadcasting, it's useful for that ;)
[23:15:03 CEST] <alexpigment> true
[23:15:31 CEST] <alexpigment> i remember there was some sort of problem with the mpegts muxer in FFMPEG that I could never work around
[23:15:42 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L189
[23:15:56 CEST] <BtbN> there is absolutely no notion of rc_min_rate anywhere in libx264.c
[23:15:57 CEST] <alexpigment> i was doing x264 + PCM and trying to make a compliant m2ts stream, and it would always leave out the audio
[23:18:18 CEST] <alexpigment> BtbN: if it's not used, it at least doesn't complain about it. doing a few tests right now for my own curiosity
[23:18:33 CEST] <BtbN> well, it's a global option
[23:18:41 CEST] <BtbN> so it's accepted, but entirely unused by x264
[23:18:56 CEST] <kepstin> yeah, ffmpeg can't complain about unused global options, because there's no way for it to tell whether a particular codec uses it or not
[23:19:30 CEST] <BtbN> maybe we should add an API for it?
[23:19:46 CEST] <BtbN> So encoders/decoders/.. can optionally signal which global options they accept
[23:21:52 CEST] <alexpigment> interestingly, in the info it says "Side data: cpb: bitrate max/min/avg: 5000000/0/5000000"
[23:22:05 CEST] <alexpigment> so, you're right that it ignores the minrate
[23:22:09 CEST] <alexpigment> (silently)
[23:24:04 CEST] <BtbN> I'm pretty sure x264 just does not support a minrate, otherwise it would be wrapped
[23:28:14 CEST] <alexpigment> BtbN, yeah now that I look at this again, it makes sense. because the minrate wasn't ever honored, you'd end up with a bitrate lower than what you specified the majority of the time
[23:28:43 CEST] <alexpigment> so the -nal-hrd cbr parameter pads the bits to make it equal to your target
[00:00:00 CEST] --- Wed Apr  5 2017