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

[burek]

[01:40:23 CEST] <blue_misfit> hey remind me - if I want to specify options to the http protocol handler assuming I have http input, how do I do that?
[01:40:35 CEST] <blue_misfit> e.g. I want to specify http_version=1.1
[05:54:39 CEST] <horohoro55> Hello, what is moov atom ?
[06:00:22 CEST] <furq> it's a header in an mp4/mov that contains the file details
[06:01:27 CEST] <horohoro55> Is it's bitlength fixed ?
[06:01:37 CEST] <horohoro55> (meaning can I just copy it from another file ^^)
[06:02:18 CEST] <horohoro55> (I am trying to repair AVC MOV video files)
[06:05:01 CEST] <furq> no, but if you have a working file from the same device then it might be
[06:06:36 CEST] <horohoro55> yes that's the idea
[06:06:50 CEST] <horohoro55> I have a corrupted file and a not corrupted file from the same device
[06:07:23 CEST] <furq> http://vpaste.net/gCBKv
[06:07:29 CEST] <furq> that's the sort of thing it actually contains
[06:07:31 CEST] <horohoro55> I have tried using untrunc but it tells me "Failed to parse atoms in truncated file". Search on the issue and a guy told to copy the 20 first byts of the header to make it work
[06:07:43 CEST] <furq> obviously stuff like stsc and stco are variable length
[06:07:45 CEST] <horohoro55> tried, didn't work :/
[06:08:19 CEST] <furq> you probably want to use something like boxdumper on a working file and see what the next atom in the file is
[06:08:37 CEST] <furq> and then just zero everything up to that and try copying the one you have in there
[06:08:55 CEST] <furq> https://github.com/l-smash/l-smash
[06:08:57 CEST] <furq> boxdumper from here
[06:14:47 CEST] <horohoro55> I insert [moov: Movie Box] into my corrupted file ?
[06:16:13 CEST] <furq> i've never done it so idk how it works in detail, but moov is the thing your corrupt file is missing
[06:16:28 CEST] <furq> i'm not sure what you'd do with the variable length fields
[06:16:42 CEST] <furq> and obviously the duration and stuff will probably be wrong
[06:16:46 CEST] <horohoro55> [moov: Movie Box] position = 251428872. So I insert everything after bit 251428872 into my file ... hum
[06:16:48 CEST] <horohoro55> what is frea ?
[06:16:58 CEST] <horohoro55>     [frea]
[06:16:58 CEST] <horohoro55>         position = 24
[06:16:58 CEST] <horohoro55>         size = 234260
[06:17:26 CEST] <horohoro55> I guess mdat is what I am interested in (the actual video)
[06:17:53 CEST] <furq> yeah
[06:17:59 CEST] <furq> frea is apparently just some kodak metadata
[06:18:41 CEST] <horohoro55> Ok let's try to do something like that
[06:19:06 CEST] <furq> if the moov atom is at the end of the file then hopefully that'll be a bit easier
[06:19:31 CEST] <furq> you might just be able to copy the whole thing across
[06:20:41 CEST] <horohoro55> let's try adding the header first
[06:20:54 CEST] <horohoro55> The position of boxdumper are in bytes or bit ?
[06:21:43 CEST] <horohoro55> bytes I guess
[06:23:31 CEST] <furq> yeah it must be bytes
[06:35:45 CEST] <horohoro55> I copied everything from:[moov: Movie Box]
[06:35:46 CEST] <horohoro55>  position = 251428872
[06:35:48 CEST] <horohoro55> but same issue
[06:36:09 CEST] <horohoro55> ffmpeg is still unable to find moov. Is the position of the moov indicated in the header ?
[06:36:34 CEST] <horohoro55> (by the way isn't it stupid to have it in the footer, how does a player do while preview if information are in the footer)
[09:34:32 CEST] <keglevich> hey all... I'm using the following command for UDP streaming:
[09:34:39 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -preset veryfast -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000"
[09:34:49 CEST] <keglevich> The command works flawlessly on i5 or i7 CPU's... but I have issues on i3 (i3-8100) CPU's... it always crashes with fatal error "av_interleaved_write_frame(): Cannot allocate memory" and "Error writing trailer of udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000: Cannot allocate memory" ... the CPU is running at around 30% stable, but crashes anyway... I'm wondering why this is happening... why on i5 or i7 runs ok...but lower en
[09:35:34 CEST] <keglevich> Also, I'm using "pthreads" ffmpeg version with it....with standard w32threads version, it works just fine all the time
[09:35:53 CEST] <keglevich> I guess it has to be something with pthreads multithreading on weaker CPU's, but I don't know how to solve it
[09:37:18 CEST] <ChocolateArmpits> keglevich, did you test same binary with all 3 systems?
[09:37:34 CEST] <keglevich> yes
[09:38:02 CEST] <keglevich> on all 6-core CPU's works flawlessly..even with 3 or 4 simultaneous streams
[09:38:28 CEST] <keglevich> on 4-core cheaper CPU's it uses about 30% of CPU, but it just crashes randomly after 10mins or so
[09:39:22 CEST] <keglevich> if I add "fifo_size=1000000" to UDP output, it's a bit better, but I guess that's not even right as fifo_size is input parameter if I'm not mistaken
[09:39:29 CEST] <keglevich> but it uses more memory definitely
[09:39:43 CEST] <keglevich> so (in some way) it works
[09:40:42 CEST] <keglevich> as far as I know pthreads uses a separate trhead for packet UDP sending, so I believe the overflow happens there...it has to be something in these low-end CPU's that's not fast enough
[09:42:40 CEST] <ChocolateArmpits> keglevich, did you try streaming to localhost?
[09:42:53 CEST] <ChocolateArmpits> just in case this is something in the network configuration
[09:44:41 CEST] <keglevich> hmm, I don't believe it's a network config error as I tried on three different motherboards with either i3-8100 or i5-2400 CPU's...different NIC's, etc...
[09:44:57 CEST] <keglevich> but ok, I can set it up to 127.0.0.1:10000 just to be sure
[09:46:03 CEST] <keglevich> it's already running, we'll see
[09:46:54 CEST] <keglevich> I simply believe that one single trhead (pthreads streaming) does overflow on weaker CPU's
[09:50:28 CEST] <jkqxz> "Cannot allocate memory" means that you're out of memory, not CPU.  Does that machine have less available memory than the others you tested?
[09:52:17 CEST] <keglevich> all machines have 8GB of memory... but memory shouldn't be an issue, I'm using 32-bit ffmpeg as well which can consume max 2GB of memory if I'm not mistaken...also memory usage never goes over 400MB or so in task manager
[09:53:22 CEST] <keglevich> also...streaming to localhost also crached after 5mins a few moments ago...same error
[09:56:42 CEST] <jkqxz> Try the 64-bit version, I guess.  Or run in a debugger and find the first allocation call which fails?
[09:57:56 CEST] <ChocolateArmpits> keglevich, maybe this has something to do with the bitrate parameter in the address and pthreads as you say? if the mux bitrate overshoots then maybe the thread implementation can't account for that properly. Just guessing
[09:59:58 CEST] <keglevich> ChocolateArmpits, that's probably true...without bitrate parameter (w32threads version) doesn't crash on weaker CPU's...
[10:00:22 CEST] <keglevich> but I need to use bitrate parameter to get as clean as possible CBR output
[10:00:38 CEST] <keglevich> if there's an option to do proper CBR without bitrate paramater...I'm all ears
[10:00:46 CEST] <ChocolateArmpits> keglevich, why not simply increase it? I guess it must pad the output anyways, no?
[10:01:11 CEST] <keglevich> I tried that as well...insreasing it for 10%, 20% or even more...same results
[10:12:15 CEST] <keglevich> is there maybe another option to get clear perfect CBR output without pthreads ffmpeg version and without using output bitrate UDP parameter?
[10:12:23 CEST] <keglevich> cause I havent' found it yet...
[19:41:28 CEST] <fl1pside555> a
[19:43:52 CEST] <fl1pside555> Hi, I have a blu-ray rip. I want to downmix all of the tracks to stereo. The command I'm using results in just a single audio track in the output. I think I need to use the map command, but I'm not sure how to specify all audio tracks. This is the command I'm using.
[19:44:04 CEST] <fl1pside555> ffmpeg -i INPUT -c:v copy -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR" OUPUT
[19:45:43 CEST] <JEEB> -map 0:a
[19:45:50 CEST] <JEEB> maps all audio tracks
[19:46:08 CEST] <JEEB> also I'm pretty sure you can downmix by just telling the filter chain that you want stereo
[19:46:16 CEST] <JEEB> unless you need some special downmixing that's not standar
[19:46:17 CEST] <JEEB> d
[19:48:17 CEST] <JEEB> aformat=channel_layouts=stereo
[19:48:18 CEST] <JEEB> I think
[19:48:36 CEST] <furq> iirc -ac 2 is aresample=ocl=stereo
[19:48:53 CEST] <furq> you probably just want to use -ac 2 if you need multiple audio tracks
[19:49:07 CEST] <JEEB> uhh, you should never recommend -ac
[19:49:12 CEST] <fl1pside555> That command was one I came across on the web. It was a thread where a few people were discussing the best way to do it.
[19:49:13 CEST] <JEEB> it gets confusing for anything over 2
[19:49:21 CEST] <furq> this is 2 though so it's fine
[19:49:28 CEST] <JEEB> and it's better to have people say "I want stereo"
[19:49:29 CEST] <furq> and it saves having to use lavfi and filter every audio track
[19:49:34 CEST] <furq> -lavfi rather
[19:49:46 CEST] <JEEB> umm, doesn't it work with just -af ?
[19:49:57 CEST] <JEEB> aformat=channel_layouts=stereo
[19:50:09 CEST] <JEEB> or aresample=ocl=stereo
[19:50:42 CEST] <JEEB> furq: the problem with using channel counts at all is that you are setting a precedent. so that the next time someone is looking for 5.1 they will say 6 instead of "5.1"
[19:50:47 CEST] <fl1pside555> This is the thread
[19:50:48 CEST] <fl1pside555> https://superuser.com/questions/852400/properly-downmix-5-1-to-stereo-using-ffmpeg
[19:50:59 CEST] <JEEB> fling: by default FFmpeg should downmix correctly
[19:51:06 CEST] <JEEB> as long as you tell it you want stereo
[19:51:11 CEST] <furq> -af only has a single output
[19:51:21 CEST] <JEEB> yes but doesn't that apply to all mapped tracks?
[19:51:22 CEST] <fl1pside555> So, what would the command be?
[19:51:25 CEST] <furq> not as far as i can tell
[19:51:32 CEST] <JEEB> ok, then I remember incorrectly
[19:51:33 CEST] <furq> unless i've been using it wrong
[19:51:56 CEST] <JEEB> I think it was when you wanted multiple outputs or something you started having issues with -af/-vf
[19:52:25 CEST] <furq> i just tried it
[19:52:26 CEST] <furq> http://vpaste.net/jv2LE
[19:52:42 CEST] <furq> -map 0:a just outputs 0:0
[19:52:47 CEST] <JEEB> umm
[19:53:01 CEST] <JEEB> that's because you have >1 inputs
[19:53:16 CEST] <furq> oh yeah duh
[19:53:18 CEST] <JEEB> you're trying to map audio tracks 0,1 from input 0
[19:53:33 CEST] <furq> ignore everything i said then
[19:54:01 CEST] <JEEB> fl1pside555: -af aresample=ocl=stereo or -af aformat=channel_layouts=stereo
[19:54:16 CEST] <JEEB> that should give you teh standard specified way of downmixing to stereo
[19:54:37 CEST] <JEEB> the only reason you shouldn't be using that is if you knowingly want to pick something that is not the standard, specified way of downmixing content
[19:55:01 CEST] <JEEB> the simplest case of this is that since stereo doesn't have an LFE channel, all LFE will be discard according to the specification
[19:55:10 CEST] <JEEB> so some people like to have LFE in non-LFE mixes :P
[19:55:35 CEST] <fl1pside555> That's what the discussion in the thread was about. They were tweaking the level of dialogue against the SFX, music, etc.
[19:56:09 CEST] <fl1pside555> That's why they came up with that filter (or whatever it is!)
[19:56:18 CEST] <JEEB> that's separate from just downmixing you know :P
[19:56:29 CEST] <JEEB> there's one way of doing dowmixing correctly
[19:56:33 CEST] <JEEB> (according to specification)
[19:56:44 CEST] <JEEB> and then if you want to tweak it, that's a whole separate discussion
[19:56:54 CEST] <JEEB> I know that you might want to do loudness normalization for example
[19:56:57 CEST] <furq> i'm pretty sure those values you pasted are the atsc standard values
[19:57:05 CEST] <furq> which is what ffmpeg defaults to iirc
[19:57:24 CEST] <JEEB> I wouldn't be surprised if ATSC actually copied them from whatever else there is which is what FFmpeg used
[19:57:34 CEST] <fl1pside555> So, if wanted to play about with the versions in that thread, what command would I use to apply it to all of the audio tracks?
[19:57:46 CEST] <furq> just add -map 0:a
[19:58:03 CEST] <JEEB> but yea, the nr1 thing that people want is loudness normalization usually after 5.1->stereo downmix
[19:58:14 CEST] <JEEB> since 5.1 mixes tend to have a large difference in volume between those
[19:58:42 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#loudnorm
[19:58:59 CEST] <JEEB> I think you'd do this after you downmix, I think?
[19:59:08 CEST] <fl1pside555> ffmpeg -i INPUT  -c:v -map 0:a  copy -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR"
[19:59:14 CEST] <fl1pside555> Like that>
[19:59:27 CEST] <JEEB> -c:v copy becamse -c:v -map ... :P
[19:59:30 CEST] <JEEB> *became
[19:59:37 CEST] <JEEB> but otherwise yes
[19:59:43 CEST] <JEEB> it has to be after input, that's all
[19:59:55 CEST] <JEEB> (and before the output)
[20:01:02 CEST] <fl1pside555> ffmpeg -i INPUT  -c:v copy -map 0:a -af "pan=stereo|FL < 1.0*FL + 0.707*FC + 0.707*BL|FR < 1.0*FR + 0.707*FC + 0.707*BR"
[20:01:16 CEST] <JEEB> yup
[20:01:26 CEST] <JEEB> that map is basically "map all audio track(s) from input 0"
[20:01:54 CEST] <fl1pside555> Gotcha. I understand the syntax now.
[20:02:23 CEST] <fl1pside555> Thanks a lot. I'll give them a try and see if I notice much difference between the standard one, and the one they came up with in the thread.
[20:24:01 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316"
[20:24:39 CEST] <keglevich> this command should produce perfect mpegts UDP CBR, but it isn't near real CBR... can someone suggest what to do to improve it?
[22:21:06 CEST] <GuiToris> hello, what audio container file can I use, if I'd like to extract audio from a video and mediainfo says : Format AC-3
[22:21:09 CEST] <GuiToris> acc?
[22:21:16 CEST] <GuiToris> I mean aac
[22:21:21 CEST] <furq> aac is a codec
[22:21:28 CEST] <furq> you can mux ac3 into m4a
[22:21:50 CEST] <furq> or you can just extract the raw bitstream and then put an id3 tag on it like an absolute monster
[22:21:54 CEST] <furq> (lots of people do this for some reason)
[22:22:32 CEST] <Mavrik> And then get A/V sync messed up? :D
[22:22:33 CEST] <Shibe> Hi, I created this library that allows me to easily encode dmabufs, I was hoping someone could review it and point out if I'm doing something wrong/incorrect? https://hastebin.com/raw/zujeberiki
[22:22:44 CEST] <furq> Mavrik: this is just for listening to it
[22:23:04 CEST] <GuiToris> furq, for f in *.MTS; do ffmpeg -i "$f" -vn -acodec copy ${f%.*}.m4a; done   is this reasonable?
[22:23:17 CEST] <furq> sure but you probably want to select tracks explicitly
[22:23:24 CEST] <furq> presumably -map 0:a:0 instead of -vn
[22:24:26 CEST] <GuiToris> video, audio and subtitle?
[22:24:46 CEST] <keglevich> ffmpeg -re -i 1.mp4 -c:v libx264 -g 50 -pix_fmt yuv420p -x264opts nal-hrd=cbr -b:v 2200k -minrate 2200k -maxrate 2200k -bufsize 260k -muxrate 2600k -pcr_period 30 -c:a mp2 -b:a 192k -ac 2 -ar 48000 -f mpegts "udp://239.1.1.1:10000?pkt_size=1316"
[22:24:50 CEST] <keglevich> this command should produce perfect mpegts UDP CBR, but it isn't near real CBR... can someone suggest what to do to improve it?
[22:24:58 CEST] <GuiToris> thanks furq
[22:27:05 CEST] <Mavrik> keglevich, there's no such thing as perfect CBR in video
[22:27:14 CEST] <Mavrik> and ffmpeg isn't optimized for that use-case at all
[22:27:31 CEST] <Mavrik> so if you need that insanity you just wrote up there you'll have to buy some pro equipment
[22:28:11 CEST] <keglevich> Mavrik: that insanity is needed by our partner fr DVB-T set-top-boxes
[22:28:21 CEST] <Mavrik> Indeed.
[22:28:31 CEST] <keglevich> it's either we do this with ffmpeg (if it can be done) or as you said...we buy expensivce equpiment
[22:28:31 CEST] <Mavrik> Yeah, we tried to use ffmpeg for DVB-C.
[22:28:37 CEST] <Mavrik> Report if you find a miracle :P
[22:28:43 CEST] <keglevich> and I came really close with ffmpeg already
[22:28:51 CEST] <Mavrik> But PCR generation is utterly broken (or was a bit ago) and we had to go back to cisco boxes
[22:29:02 CEST] <Mavrik> If you manage to fix it, let me know.
[22:29:26 CEST] <keglevich> PCR generation seem to work fine in conjunction with pcr_period and muxrate
[22:29:33 CEST] <Mavrik> But IIRC the main issue is that mpegts muxer from ffmpeg just makes up PCR in a way that makes any kind of DVB ingester choke
[22:29:53 CEST] <keglevich> also...near perfect CBR stream can be done using "pthreads" ffmpeg and output UDP parameter "bitrate"
[22:30:07 CEST] <keglevich> but...pthreads in really unstable from what I've seen so far
[22:30:24 CEST] <JEEB> it's definitely not perfect
[22:30:33 CEST] <JEEB> improvements are welcome
[22:30:38 CEST] <keglevich> and we experience random crashes...therefore I'd like to go ahead with w32threads version and find similar solution as we did with ptrheads
[22:30:49 CEST] <Mavrik> There were some reports that OBS can do it better with different MPEG-TS muxer, but I've never tested it.
[22:31:01 CEST] <keglevich> OBS is shit...simply
[22:31:05 CEST] <JEEB> OBE you mean?
[22:31:12 CEST] <JEEB> OBS is the gamer thing
[22:31:28 CEST] <keglevich> yes...OBS can't even accept various ffmpeg parameters
[22:31:43 CEST] <keglevich> and does only progressive output...so no go
[22:31:44 CEST] <Mavrik> OBE or whatever yeah
[22:32:24 CEST] <keglevich> JEEB: would you maybe have some suggestion how to improve stability with pthreads version of ffmpeg?
[22:32:32 CEST] <Mavrik> I do have to admit that I didn't waste more than a week trying to get ffmpeg's mpeg-ts muxer under control so I might have missed something obvious. And that was like 2 years ago :/
[22:33:40 CEST] <JEEB> keglevich: I haven't had UDP/MPEG-TS output stuff going too much, might have to dwelve into it again later
[22:33:45 CEST] <keglevich> regarding stability with pthreads....it works as far as we use high-class CPU's (i7, i5-8600), and as long as it has enough CPU room left... if we do it on low-class budget CPU.s (for instance i3-8100) it crashes randomly after 10mins or so with "cannot allocate memory" fatal error...even though CPU load is no more than 50% on those cheap CPU's
[22:34:05 CEST] <JEEB> keglevich: both on 64bit?
[22:34:20 CEST] <keglevich> yes...32bit and 64bit
[22:34:47 CEST] <JEEB> try getting a backtrace through gdb or so
[22:34:51 CEST] <keglevich> as soon as CPU load is 80% or more, it crashes on all CPU's
[22:35:22 CEST] <keglevich> w32threads version never crashes...even if I do 5+ HD streams on single CPU and cpu load is 100% all the time
[22:35:45 CEST] <Mavrik> Is both of that on Windows?
[22:35:49 CEST] <keglevich> yes
[22:38:24 CEST] <keglevich> under 50% CPU load it won't crash...multiple streams with pthreads versions and over 60%+ CPU load... it'll crash randomly.... but when 80%+ CPU load, it'll crash in 3mins or so
[22:39:10 CEST] <keglevich> always same error "av_interleaved_frames...cannot allocate memory" or something similar
[22:39:45 CEST] <keglevich> "av_interleaved_write_frame(): Cannot allocate memory" and "Error writing trailer of udp://239.2.2.2:10000?pkt_size=1316&bitrate=2600000: Cannot allocate memory"
[22:40:11 CEST] <keglevich> memory usage never exceeds 400MB thought
[22:40:20 CEST] <keglevich> so it's not memory related I guess
[22:50:05 CEST] <furq> is there a standard for the track layout on blu-ray audio discs
[22:50:41 CEST] <furq> everything i've seen has been one playlist and then one chapter per track, but idk if that's actually specified anywhere
[00:00:00 CEST] --- Sun Sep 30 2018