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

[burek]

[12:56:11 CEST] <Raaja> Hello
[12:56:54 CEST] <Raaja> I am new to FFMPEG and I amtrying to get a shared library for FFMPEG and x264 to be used for Android App development.
[12:58:02 CEST] <Raaja> I experience failure when compiling bash script for different architecture to be used under FFMPEG folder.
[12:58:15 CEST] <Raaja> link to the log below.
[12:58:17 CEST] <Raaja> https://pastebin.com/QuUrfdrP
[12:59:21 CEST] <Raaja> i receive "C compiler test failed." everytime i run the bash script.
[12:59:34 CEST] <Raaja> I am working on Ubuntu latest version
[12:59:57 CEST] <JEEB> I find it much simpler to use the standalone toolchain script in NDK
[13:00:13 CEST] <JEEB> also there's --cross-prefix= for the prefix of the tools
[13:00:38 CEST] <Raaja> yes i tried them. I created my own toolchain using the NDK documentation
[13:00:38 CEST] <JEEB> also at this point I would be using clang
[13:00:57 CEST] <Raaja> Iss it possible to guide me through this?
[13:02:06 CEST] <Raaja> link to my sample script here. https://pastebin.com/36sh1C0g
[13:02:25 CEST] <JEEB> in the dir of the NDK there's ./build/tools/make_standalone_toolchain.py . you just give it --arch arm64 --api 21 --install-dir /path/to/toolchain
[13:02:37 CEST] <JEEB> and it gives you aarch64 API 21 thing :P
[13:03:30 CEST] <Raaja> yes i have created a toolchain using the ndk tools
[13:03:41 CEST] <JEEB> also I don't get those extra ldflags, you could just use pkg-config for that
[13:03:46 CEST] <Raaja> i generated it for different architectures
[13:04:15 CEST] <Raaja> Actually I am new to this stuff. I am folllowing a guide and i got the busid scripts from them
[13:04:22 CEST] <Raaja> *build
[13:04:40 CEST] <Raaja> All i wanted is shared .so files generated
[13:04:42 CEST] <Raaja> :)
[13:05:27 CEST] <JEEB> also I hope you understand that using x264 and putting enable-gpl there means you have to put the whole thing under GPL when distributing, right?
[13:05:55 CEST] <Raaja> Whole thing under GPL?
[13:06:02 CEST] <JEEB> yes
[13:06:35 CEST] <JEEB> GPL means that if you use a library that is under GPL the whole thing ends up as GPL
[13:06:47 CEST] <Raaja> i should post licensing info when using it for commercial apps?
[13:07:05 CEST] <JEEB> it means that the whole commercial app's code has to be available as GPL
[13:07:32 CEST] <JEEB> so unless you for some reason need x264, or any other GPL component, don't enable it
[13:07:35 CEST] <JEEB> x264 is the encoder anyways
[13:08:01 CEST] <Raaja> oh so tis not going to be propiertary code. I think this will affect my client bad.
[13:08:19 CEST] <Raaja> i thought only the library comes under GPL
[13:08:25 CEST] <JEEB> no
[13:08:47 CEST] <JEEB> LGPL is "you have to give the code of the LGPL libraries(s) and give the user the capability to switch the library)
[13:09:02 CEST] <JEEB> GPL is "if you use GPL, then you also have to make the thing available under GPL altogether"
[13:10:00 CEST] <Raaja> including the code i right from Android side?
[13:10:16 CEST] <JEEB> your whole app, if you use GPL software
[13:10:22 CEST] <Raaja> which ever the oce consuming GPL licenced code?
[13:10:28 CEST] <JEEB> yes
[13:10:35 CEST] <Raaja> ohh...
[13:11:03 CEST] <JEEB> x264 is specifically GPL because there's also corporate licensing for it.
[13:11:11 CEST] <JEEB> so you can buy a license that is not GPL for x264
[13:11:47 CEST] <JEEB> now if you don't need x264
[13:11:50 CEST] <Raaja> Actually My only concern is that I am looking for a library which can make me stitch 2 videos side by side. i mean 2 input files of the same resolutions.
[13:11:53 CEST] <JEEB> then you go down to LGPL
[13:12:02 CEST] <Raaja> it is going to be a Video file.
[13:12:35 CEST] <Raaja> is there any framework other than FFMPEG? even if i need yo buy a liscence?
[13:13:00 CEST] <JEEB> well FFmpeg is not the thing that's GPL by default :P
[13:13:10 CEST] <durandal_1707> Raaja: gstreamer
[13:13:20 CEST] <JEEB> but sure, there are other media frameworks
[13:13:26 CEST] <JEEB> most of them are LGPL or GPL
[13:13:43 CEST] <JEEB> and even with LGPL you need to give the user the capability to switch the library
[13:13:50 CEST] <JEEB> which can be a problem with android apps
[13:14:02 CEST] <JEEB> what I've seen some android apps is that they separate the part that uses LGPL
[13:14:08 CEST] <JEEB> and make that open source
[13:14:33 CEST] <JEEB> and then call it with the android API things or whatever from their activity that is in the proprietary part
[13:14:50 CEST] <JEEB> but as I noted, this doesn't help with GPL, since that makes the whole thing GPL
[13:15:33 CEST] <Raaja> I hope that helps, I can make the whole function an open source library and and utilize it from app side. I need FFMPEG and x264 only for stitching video to be uploaded to server.
[13:15:53 CEST] <JEEB> as soon as you use a GPL component or license FFmpeg as GPL, that doesn't work
[13:15:55 CEST] <JEEB> that was for *LGPL*
[13:15:58 CEST] <Raaja> oh bad. So Apps which use x264 are all open source?
[13:16:08 CEST] <JEEB> or license x264
[13:16:26 CEST] <JEEB> but have you thought if you actually need x264?
[13:16:42 CEST] <JEEB> like, what role does x264 play in this setup?
[13:17:14 CEST] <Raaja> for mp4 support i mean H.264
[13:17:31 CEST] <JEEB> ok, you do understand that x264 is just the encoder?
[13:17:35 CEST] <Foaly> you can also buy a x264 license
[13:17:45 CEST] <JEEB> Foaly: yea I've mentioned that like two times already
[13:17:50 CEST] <Raaja> I have read in many places that is encodes videos to smaller size?
[13:17:57 CEST] <JEEB> yes, it's a great encoder
[13:18:02 CEST] <Raaja> Sorry if i am wrong I am new to video and Audio
[13:18:07 CEST] <JEEB> I'm just not sure you want it on mobile devices
[13:18:42 CEST] <Raaja> JEEB if i can buy x264 liscence it would be helpful ...
[13:19:26 CEST] <Raaja> JEEB also i have been adviced that x264 is the best encoder for mobile devices as it encodes videos to a much smaller size.
[13:19:42 CEST] <JEEB> ok, so FFmpeg doesn't have a mediacodec encoder
[13:19:59 CEST] <JEEB> so your alternatives are openh264 or x264
[13:20:18 CEST] <JEEB> Raaja: yes if you're basically running it on a PC to encode for the mobile device, sure
[13:20:29 CEST] <JEEB> it's stupidly fast and good with modern PCs
[13:20:40 CEST] <JEEB> but your use case is ARM
[13:20:51 CEST] <JEEB> android devices with possibly limited batterias?
[13:21:13 CEST] <Raaja> yes, so x264 takes much CPU power.
[13:21:18 CEST] <Raaja> understood.
[13:21:28 CEST] <JEEB> but yea, if you need a H.264 encoder doing it in software on android
[13:21:30 CEST] <JEEB> there's openh264
[13:21:32 CEST] <JEEB> and x264
[13:21:47 CEST] <JEEB> openh264 is worse of course, but I have heard its ARM optimizations are pretty good
[13:21:58 CEST] <JEEB> also it has a more liberal license
[13:22:15 CEST] <JEEB> then there's x264 which is of course also optimized but it's GPL/commercial licensed
[13:22:18 CEST] <Raaja> I will checak and know more about it.. Thank you for the information JEEB
[13:22:26 CEST] <JEEB> yes, please do
[13:22:33 CEST] <Raaja> IS there any other way i Can try to acheive my function?
[13:22:49 CEST] <Raaja> I would like to stitch 2 videos files of same ressolution side by side
[13:22:53 CEST] <JEEB> using the android media framework to decode/filter
[13:22:58 CEST] <JEEB> and then push it to the hw encoder
[13:23:32 CEST] <JEEB> most likely if those 2 files were written by the same device the hw decoders should be able to decode it
[13:23:57 CEST] <JEEB> if you plan on needing wider support then you'd possibly want LGPL FFmpeg for the reading of the files and having fall-back software decoding
[13:24:27 CEST] <JEEB> and since LGPL needs you to give the possibility for the user to replace the LGPL component if he/she wants
[13:24:36 CEST] <JEEB> that is probably where you'd have the FFmpeg-using part as a separate app
[13:24:45 CEST] <JEEB> (and open source)
[13:25:03 CEST] <JEEB> but yes, I am pretty sure you should be able to do this with just the Android media frameworks
[13:25:05 CEST] <Raaja> any Libarary as powerful but also has a standalone liscence?
[13:25:26 CEST] <JEEB> not really
[13:26:28 CEST] <Raaja> so apps like MXPlayer, VPLayer and others use FFMPEG. So how does it affect them?
[13:30:36 CEST] <JEEB> ah, the "replace the binary" part seems to be more towards LGPLv3
[13:30:38 CEST] <JEEB> but IANAL
[13:30:43 CEST] <JEEB> (I Am Not A Lawyer)
[13:31:31 CEST] <JEEB> so LGPLv2.1 (which is the default license of FFmpeg), just requires you to publish the full sources of the LGPL software
[13:31:46 CEST] <Raaja> Yes I am confused more about the liscening. I will check them.
[13:31:50 CEST] <Raaja> Ahh that is bad.
[13:32:27 CEST] <JEEB> not really, since it limits itself to the LGPL stuff
[13:32:27 CEST] <Raaja> My client needs a proprietary app
[13:33:18 CEST] <JEEB> LGPL doesn't stop you from making a proprietary app, GPL does :P
[13:34:13 CEST] <Raaja> thats x264, And you have mentioned that i  can buy a license.
[13:34:31 CEST] <JEEB> yes
[13:34:35 CEST] <JEEB> but do you really need x264?
[13:34:51 CEST] <JEEB> anyways, since you're limited to Android
[13:34:59 CEST] <JEEB> I recommend you attempt to do this with the media framework first
[13:35:05 CEST] <JEEB> without FFmpeg
[13:35:28 CEST] <Raaja> Yes I have too. If not I will come again here.
[13:35:34 CEST] <JEEB> you do hw decoding, filter with whatever android might have, and then encode with the hw encoder
[13:35:54 CEST] <JEEB> then if you start hitting crappy components/devices you will start needing fall-backs
[13:36:00 CEST] <JEEB> (software ones)
[13:36:13 CEST] <Raaja> yes Understood.
[13:36:23 CEST] <Raaja> I will first check the documentations for it.
[13:37:58 CEST] <Raaja> You people are really very helpy full. I have been struggling for 2 days to compile .so files for FFMPEG. you have provided lots of informations. Thank you JEEB
[13:38:10 CEST] <Raaja> *helpful
[13:39:06 CEST] <JEEB> getting the .so files for Android at the end of the day is not hard, in a way I just want to make sure you're using x264/FFmpeg understanding the license
[13:39:14 CEST] <JEEB> before helping you
[13:39:36 CEST] <JEEB> and if you really don't need FFmpeg or x264, that's a good alternative as well (esp. since FFmpeg doesn't seem to have hw encoding)
[13:40:54 CEST] <JEEB> and if you don't need especially x264, there's openh264 as a more liberally licensed AVC encoder
[13:41:03 CEST] <JEEB> in case you do need that software fall-back
[13:41:08 CEST] <JEEB> because some devices are indeed shit
[13:47:00 CEST] <Raaja> Yess I understood that. I first make sure that the technique is acheivable from Android side. I will also discuss the licensing issues with my client.
[13:47:12 CEST] <Raaja> I hope you might help some other time, when I am back.
[13:47:17 CEST] <Raaja> Thanks for your help
[14:59:07 CEST] <Raaja> Hello
[14:59:15 CEST] <JEEB> uh-huh
[15:00:37 CEST] <Raaja> JEEB I am not sure it is possible to merge videos side by side in Android.
[15:00:54 CEST] <JEEB> I have no idea how much filtering capabilities Android has
[15:01:07 CEST] <JEEB> like, you open one thing and another thing and start getting decoded frames
[15:01:15 CEST] <JEEB> then you do stuff with textures
[15:01:24 CEST] <JEEB> and you feed the resulting thing into mediacodec again
[15:01:37 CEST] <Raaja> Unfortunately Android's MediaCodec can Decode and Encode Videos, but not as flexible as FFMPEG where i Can place the video side by side and merge it into a single video
[15:03:29 CEST] <JEEB> well, you get a surface (remembered the word for textures in android world) per decoded video
[15:03:41 CEST] <JEEB> then you do filtering on those
[15:03:49 CEST] <JEEB> and you feed a surface with both of them into the encoder
[15:03:57 CEST] <JEEB> like I wouldn't be expecting to find this out of the box
[15:04:07 CEST] <JEEB> you have to do it yerself, the putting them next to each other
[15:16:26 CEST] <Raaja> Yes I understood. But I think it is not much memory effecient. I need to have 3 Surfaces and need to decode frames from 2 videos and them encode them on the third surface.
[15:17:05 CEST] <JEEB> well that's effectively what you'd be doing in FFmpeg as well
[15:17:25 CEST] <JEEB> you open a decoder for one thing, you open another one for another thing
[15:18:23 CEST] <Raaja> I need more insight on this one. I will check again and will let you know,
[15:18:31 CEST] <Raaja> Thanks for the info.
[15:18:42 CEST] <JEEB> in theory you could use the API to render into a single set of buffers but you'd have to take care of making sure all planes get correctly utilized
[15:21:17 CEST] <Raaja> Actually I am really new encoding and decoding. I have done image compression, video playback and stuffs like that. But I haven't worked with encoding or decoding it. So its is difficult for me to understand all of these
[15:21:41 CEST] <Raaja> Thanks for your quick reply though. I will find if there is some more inifo i can get from Documentations.
[15:44:49 CEST] <Raaja> Hello JEEP actually the Surfaces are just for drawing frames onto the screen. But What I am actually looking is I need to stick to Videos which has same size and length , side by side
[15:45:01 CEST] <Raaja> and save them in MP4 format.
[15:45:09 CEST] <Raaja> I hope I am not clear before.
[15:45:48 CEST] <JEEB> I'm pretty sure you can get the stuff from mediacodec in a way to then re-utilize it
[15:45:59 CEST] <JEEB> otherwise people wouldn't be discussing about it on the internet
[15:46:27 CEST] <Raaja> Fortunately i get InputBuffers and OutputBuffers, to work with but, I am not sure how I manipulate them and save them in MP4 format
[15:47:06 CEST] <JEEB> I think it's time for you to find some android developers to talk with
[15:47:31 CEST] <Raaja> I am checking all over the internet, The Decode and Encode is possible but, I am unsure how it works
[15:47:33 CEST] <Raaja> Yes.
[15:47:38 CEST] <Raaja> I think so.
[15:48:25 CEST] <Raaja> But stackoverflow has very low support for MediaCodec rather than FFMPEG for Android
[16:06:29 CEST] <friendofafriend> Hello.  My input is an audio file, and I'm outputting to an icecast server.  ffmpeg is connecting to the icecast server and creating a stream, but instead of outputting at 1x speed, ffmpeg sends data as quick as possible and ends.  How can I output at 1x speed?
[16:07:09 CEST] <JEEB> either feed it something that's going 1x (through UDP or otherwise), or use the -re hack
[16:07:21 CEST] <JEEB> (latter being before the -i option, so it gets applied to the inputs)
[16:10:24 CEST] <friendofafriend> The -re flag is doing exactly what I need.  Thank you so much, JEEB!
[17:17:43 CEST] <CoreX> I need to keep a video within the 1280x720 ratio i know 1280:-2 can do it but it keeps going over 720p to 722> and so on
[17:17:51 CEST] <CoreX> anyway to keep this from happening?
[17:18:54 CEST] <JEEB> sounds like your aspect ratio is either not exact 16:9, or there's a boog somewhere
[17:29:40 CEST] <furq> CoreX: scale=if(gt(a\,16/9)\,1280\,-2):if(gt(a\,16/9)\,-2\,720)
[17:41:48 CEST] <krg_> Hello, I have one query. I have a vob file, but then the audio (multi lingual) starts, ac3 complains and the video has repetitions. Anyone else experine this? I think is the third time.
[17:42:16 CEST] <krg_> I tried -an (no audio) and again the video has repetitions.
[17:42:57 CEST] <furq> krg_: sounds like multiangle
[17:43:28 CEST] <krg_> A ha..., so I need to re-copy the create new vob?
[17:43:33 CEST] <furq> you generally want to preprocess dvds with something that can actually read ifos
[17:43:42 CEST] <furq> so dvdbackup, tccat/tcdemux, etc
[17:43:57 CEST] <furq> pgcdemux if you're on windows
[17:44:13 CEST] <krg_> (linux here) I tried vobcopy, occasionally I have this problem.
[17:44:52 CEST] <furq> if you already have the disc ripped then tccat will let you pick title/chapter/angle and then output on stdout
[17:44:55 CEST] <furq> so you can pipe it into ffmpeg
[17:45:12 CEST] <krg_> a ha!
[17:45:19 CEST] <furq> annoyingly a lot of repos stopped packaging transcode
[17:45:37 CEST] <krg_> I just checked, is very old! 2011!
[17:45:46 CEST] <furq> yeah
[17:45:56 CEST] <furq> it's mostly useless now but tccat and tcdemux are still good
[17:46:06 CEST] <furq> someone ought to package those up separately
[17:46:23 CEST] <krg_> I have it, but it is too much cryptic to me. 10 years ago (I think) it was my fav, but now I prefer ffmpeg and vobcopy.
[17:46:32 CEST] <krg_> I will try now.
[17:47:22 CEST] <krg_> tcscan for a start?
[17:50:46 CEST] <furq> i normally used lsdvd for that
[17:51:20 CEST] <krg_> same result with tccat -i file.vob -t vob -t 1,1,1 | mplayer -
[17:51:23 CEST] <krg_> any help?
[17:54:47 CEST] <krg_> Oops, wrong arg -t vs -T, retry
[18:04:05 CEST] <krg_> furq: thank you for the idea, no solution yet, I think I have to re-rip the dvd. Thank you!
[18:04:41 CEST] <furq> does lsdvd -n say that title has multiple angles
[18:19:42 CEST] <BobCat> Does anyone have a recipe to use a WinXP compatible version of ffmpeg to connect a USB webcam to YouTube Live?
[18:19:59 CEST] <BobCat> And yes, I know I should not be using an ancient OS
[18:20:39 CEST] <BobCat> webcam or manycam, doesn't matter
[18:21:26 CEST] <furq> BobCat: https://trac.ffmpeg.org/wiki/Capture/Webcam#Windows
[18:25:18 CEST] <BobCat> Hopefully that will work with an antique rev of ffmpeg thanks
[18:26:32 CEST] <JEEB> BobCat: anything older than http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c7ab6aff66cba2f265f656ce8d56aa428d4ada76 probably would work on XP?
[18:26:44 CEST] <JEEB> although the reason why that happened I would guess is pretty understandable :P
[18:27:14 CEST] <JEEB> at the point of 2018, april
[18:27:24 CEST] <JEEB> winxp had been out of support for what, four years?
[18:27:25 CEST] <JEEB> :)
[18:27:44 CEST] <JEEB> but yes, technically we kept winxp support for a surprising amount of time :P
[18:28:17 CEST] <furq> well you'll need to build it yourself because zeranoe dropped support much longer ago
[18:28:22 CEST] <furq> on account of libmfx
[18:28:53 CEST] <JEEB> not surprising, dependencies or applications using FFmpeg probably dropped support much earlier :P
[18:30:53 CEST] <BobCat> If I can't find an old built version I'll toss the XP box out a window and use Win7 :)
[19:07:39 CEST] <locsmif> Hi. Yesterday I was explained how to move the index from the tail end of an .mp4 to the front, to optimise for streaming. However, is there also a command I can use to detect this? I'd rather find out on the command line than from trying, waiting 30 seconds to a minuted and then having the stream fail..
[19:08:11 CEST] <locsmif> Even some command returning a byte offset would be grand.
[19:08:47 CEST] <JEEB> you could check with l-smash's boxdumper, I guess?
[19:08:53 CEST] <furq>     boxdumper "$1" | awk '/moov:/ { exit 0 } /mdat:/ { exit 1 }'
[19:09:00 CEST] <furq> is what i have in my snippets file
[19:09:03 CEST] <JEEB> :D
[19:09:05 CEST] <JEEB> lol
[19:09:35 CEST] <atomnuker> locsmif: -movflags +faststart
[19:09:44 CEST] <kepstin> there's always the good old `cat file.mpv | mpv -` test :)
[19:09:49 CEST] <kepstin> if it plays, it's got the moov at the start
[19:09:54 CEST] <furq> atomnuker: he's asking how to detect if it's already faststart
[19:10:30 CEST] <furq> although it's better to use a proper mp4 muxer for remuxing anyway because it does it in one pass
[19:11:25 CEST] <locsmif> So I pull boxdumper from git, and compile, then run. I'm good with that. It's well worth it and little effort
[19:13:00 CEST] <furq> l-smash is worth having installed anyway
[19:17:13 CEST] <locsmif> Oh I see, the whole toolkit, thanks, will do
[19:17:22 CEST] <locsmif> I'd never heard of it before
[19:20:41 CEST] <locsmif> Hmmm, I just found out about this is as well. Since I'm using Serviio, and Serviio uses ffmpeg, I wonder why it's not using this as well, since it's apparently descended from the same tool inside the ffmpeg suite?
[19:20:46 CEST] <locsmif> https://github.com/danielgtaylor/qtfaststart
[19:41:34 CEST] <causasui> kepstin: useless use of cat. do `mpv - < file.mpv`
[20:38:09 CEST] <scientes> is there a command line that will convert DTS to mp3 or aac?
[20:38:36 CEST] <scientes> i've done it before but it wasn't good at keeping the other tracks
[20:38:58 CEST] <scientes> like subtitles
[20:39:12 CEST] <JEEB> you can -c copy (this is all tracks) and then -c:a:X aac the audio track that you want to convert
[20:39:25 CEST] <JEEB> where X is the Nth audio trakc you have selected
[20:39:29 CEST] <kepstin> if you have multiple tracks and you only want to convert one, you need to find out the track ids (ffmpeg -i filename) will print them out, then build a command line that converts only the one you want
[20:41:40 CEST] <scientes> can you give me a complete command line (except for the track number)
[20:41:52 CEST] <scientes> (and the file names)
[20:52:33 CEST] <scientes> I can't get it to keep stream 3 (subtitles)
[20:53:12 CEST] <kepstin> you'll often have to add a "-map 0" to tell ffmpeg that you want to copy all tracks from the first input file (#0)
[20:56:51 CEST] <scientes> http://paste.debian.net/1034674/
[20:57:01 CEST] <scientes> [mp4 @ 0x555854dc9400] Could not find tag for codec subrip in stream #3, codec not currently supported in container
[20:57:42 CEST] <scientes> ohh i need .mkv
[20:58:00 CEST] <scientes> bingo thanks
[21:22:25 CEST] <kerio> you can convert them to mov subtitles
[21:25:11 CEST] <ntd> i have a few sec cameras which provide h264 over rtsp. instead of having multiple apps pull their own stream i'd prefer to just have ffmpeg pull and make them available at localhost with -vcodec copy
[21:25:13 CEST] <ntd> possible?
[21:27:59 CEST] <kerio> i'd set up nginx-rtmp
[21:28:07 CEST] <kerio> in pull configuration
[21:28:28 CEST] <kerio> as a bonus, you also get free-ish HLS serving
[21:29:20 CEST] <ntd> i may look into that, but i'm assuming that what i asked is indeed possible?
[21:46:37 CEST] <kerio> define "make available"
[21:47:02 CEST] <kerio> if you want multiple clients to be able to access the stream via rtmp, then you need a rtmp server
[21:47:13 CEST] <kerio> and ffserver is discontinued
[21:47:15 CEST] <kerio> and also shit
[21:47:37 CEST] <DHE> ffmpeg is not a server, but it can be used to feed one
[21:52:38 CEST] <furq> you could make them available locally with ffmpeg if you use hls
[21:52:55 CEST] <furq> if you don't mind not knowing you're being burgled until 30 seconds after it happens
[21:54:40 CEST] <locsmif> scientes: don't you mean something like: ffmpeg -i input.mp4 -c:v copy -ac 2 -af "pan=stereo|FL=FC+0.30*FL+0.30*BL|FR=FC+0.30*FR+0.30*BR" output.mp4
[21:55:17 CEST] <furq> you don't need pan with -ac 2
[21:55:21 CEST] <furq> unless you want some fancy custom mixdown
[21:55:30 CEST] <ntd> i just wanna pull one stream from each cam, make it available locally instead of having four apps pull sep streams from the cam
[21:55:37 CEST] <locsmif> Yeah, that's to pull up the sound a bit
[21:55:39 CEST] <ntd> ofc, avoiding a 30 sec delay would be appreciated
[21:56:01 CEST] <furq> ntd: if you want to make it available on your local network then you need a streaming server
[21:56:06 CEST] <furq> or hls but that has unavoidable latency
[22:07:25 CEST] <ntd> ok, any recommendations as to a "re-streaming" server? pulls rtsp from remote source A, makes it avail locally as rtsp to client B,C,D using h264 passthrough/-vcodec copy, thusly with minimal overhead?
[22:19:20 CEST] <faLUCE> hello. how can I concat file1.m4a and file2.m4a  ?  They are aac encoded
[22:19:43 CEST] <faLUCE> I tried ffmpeg -i "concat:audio1.aac|audio2.aac" -c copy result.aac  with no luck
[23:07:23 CEST] <SpeakerToMeat> Hello all.
[23:07:52 CEST] <SpeakerToMeat> Is it possible to rewrap xdcam from mxf to mov with -c:v copy even if ffmpeg doesn't support this particular xdcam codec?
[23:08:24 CEST] <JEEB> only if it knows the identifiers and knows how to handle the packets that get demuxed (plus possibly parsed)
[23:09:47 CEST] <SpeakerToMeat> Nod
[23:09:49 CEST] <SpeakerToMeat> I'll try, thanks
[23:10:01 CEST] <SpeakerToMeat> otherwise I'll have to determine which ffmbc is the "current" one :/
[23:10:24 CEST] <JEEB> the ffmbc guy seems to be contributing to FFmpeg again, which is I guess positive
[23:11:07 CEST] <JEEB> because ffmbc was basically doing something that was 100% OK according to the license, but kind of meh. as in, all that work that the guy did was under GPL, and thus nothing could be picked back to FFmpeg as-i
[23:11:11 CEST] <JEEB> *as-is
[23:11:21 CEST] <JEEB> since FFmpeg is generally speaking an LGPL project
[23:11:29 CEST] <SpeakerToMeat> Hmmm ok
[23:11:31 CEST] <JEEB> so you can't even look at the ffmbc code
[23:11:44 CEST] <JEEB> because then you could just be told that you're just copying GPL stuff
[23:11:57 CEST] <JEEB> so you have to have someone else explain how something's done
[23:12:14 CEST] <SpeakerToMeat> Is this the official one? https://github.com/FFmpeg/FFmpeg
[23:12:16 CEST] <JEEB> (or more likely, read the specs and what is actually used in the field)
[23:12:20 CEST] <JEEB> that's a mirror
[23:12:28 CEST] <JEEB> git.videolan.org has the official FFmpeg repo
[23:12:38 CEST] <SpeakerToMeat> ok, thanks
[23:13:02 CEST] <JEEB> and if it isn't supported feel free to make a trac issue if there's none yet
[23:13:07 CEST] <JEEB> and if you can generate a sample, even better
[23:13:25 CEST] <JEEB> of course some "pro" things basically are things where some people don't want to do free work
[23:13:36 CEST] <SpeakerToMeat> Yeah
[23:13:51 CEST] <SpeakerToMeat> I wonder if in this case it'd be only a case of adding a fourcc, to be able to copy directly
[23:13:53 CEST] <JEEB> but depending on how simple it is, it might be doable quickly
[23:14:02 CEST] <JEEB> in the simplest case it's an identifier, yea
[23:14:12 CEST] <JEEB> XDCAM was either MPEG-2 video or AVC/H.264 right?
[23:15:36 CEST] <SpeakerToMeat> Or DV too if I'm not wrong
[23:18:13 CEST] <JEEB> AVC Intra was the biggest scam though in a while
[23:18:23 CEST] <JEEB> there was a public spec, and then oen behind a non-disclosure agreement
[23:18:37 CEST] <JEEB> you can guess which was actually used by implementations
[23:18:56 CEST] <JEEB> and of course since just AVC proper wasn't good enough, it basically broke the stream by just leaving things out
[23:19:03 CEST] <JEEB> like initialization data
[23:19:21 CEST] <JEEB> instead the initialization data was basically hard-coded for each resolution etc
[23:20:14 CEST] <SpeakerToMeat> What about Av1, will it deliver?
[23:20:35 CEST] <JEEB> it seems positive so far, and it finally got finished up in MP4
[23:20:46 CEST] <JEEB> so you not only can encode it, but you can actually put it into MP4
[23:20:56 CEST] <SpeakerToMeat> MP4 official?
[23:21:07 CEST] <JEEB> yes, that's why the MP4 patches got merged just a while ago
[23:21:19 CEST] <JEEB> for both reading and writing
[23:21:30 CEST] <JEEB> matroska should be coming soon and hopefully being similar
[23:21:58 CEST] <SpeakerToMeat> Interesting, I'd expect the company/foundation to fight it, I thought they'd be interested on favoring HEVC over av1
[23:22:19 CEST] <SpeakerToMeat> Or, I'm wrong and the group managing the mp4 spec is not the AVC/HEVC group
[23:22:27 CEST] <JEEB> it's not
[23:22:30 CEST] <SpeakerToMeat> ok
[23:22:32 CEST] <JEEB> there's Mr Singer from Apple etc
[23:22:44 CEST] <JEEB> plus they don't really manage the mappings
[23:23:08 CEST] <JEEB> you can just register your identifier at the mpeg-4 ra
[23:23:17 CEST] <SpeakerToMeat> Btw are the fourcc specs for mp4 paywalled? all I've found are lists compiled by hand by third parties
[23:23:40 CEST] <JEEB> I think MPEG-4 RA is even on github now
[23:23:49 CEST] <JEEB> https://mp4ra.org
[23:23:59 CEST] <JEEB> https://mp4ra.org/#/codecs
[23:24:42 CEST] <SpeakerToMeat> Sweet, thank you very much. I wonder why google searches of old didn't provide this.....
[23:25:02 CEST] <JEEB> yea this site is actually pretty old by now
[23:25:05 CEST] <SpeakerToMeat> Oh, of course, last time I searched I was searching for .mov fourccs not mp4....
[23:25:09 CEST] <JEEB> :)
[23:25:19 CEST] <SpeakerToMeat> *cough*same thing*cough*
[23:25:23 CEST] <SpeakerToMeat> ;)
[23:25:37 CEST] <JEEB> almost
[23:25:47 CEST] <JEEB> there's some funky differences between ISO BMFF and QTff
[23:26:04 CEST] <SpeakerToMeat> Thanks for the link though
[23:26:11 CEST] <JEEB> and yea, they seem to hold the QTff registered codec IDs there as well https://mp4ra.org/#/qtcodecs
[23:26:37 CEST] <JEEB> (also it's funny how the newest version of the qtff PDF is from the sony wikileaks dump)
[23:26:46 CEST] <JEEB> (that's publicly available)
[23:27:04 CEST] <JEEB> I think if you search through apple's docs you will find a lot of the stuff, though
[23:29:16 CEST] <SpeakerToMeat> Damn
[23:29:33 CEST] <SpeakerToMeat> if I read fourcc.c correctly, there's no code for the xdcam I need to wrap
[23:29:50 CEST] <SpeakerToMeat> I'll need to find one of these sketchy quicktime lists (this will go to a .mov) and see if it's listed
[23:30:15 CEST] <TD-Linux> yeah you can see we also registered opus which "competes" with aac
[23:30:23 CEST] <TD-Linux> and there's lots of other codecs that no one cares about there
[23:30:59 CEST] <JEEB> yea
[23:31:06 CEST] <JEEB> it's basically first-come first-serve kind of thing
[23:32:13 CEST] <SpeakerToMeat> Sigh I think I'll have to find the right fourcc and either add it to fourcc.c and recompile, or specify it by hand iif at all possible
[23:32:34 CEST] <JEEB> just make it match the actual video format used if possible
[23:32:48 CEST] <JEEB> AVC/MPEG-2/whatever
[23:32:57 CEST] <SpeakerToMeat> I need XDCAM HD422 1920x1080i30 CBR 50Mb/s all I see listed for that cbr in interlaced are i50 and i60
[23:33:19 CEST] <JEEB> I think i30 means 60 fields per sec?
[23:33:31 CEST] <JEEB> and i50/60 are in fields per sec
[23:33:44 CEST] <SpeakerToMeat> ....
[23:33:46 CEST] <SpeakerToMeat> duh
[23:33:48 CEST] <SpeakerToMeat> sorry
[23:33:50 CEST] <SpeakerToMeat> I'm kinda sick
[23:33:52 CEST] <SpeakerToMeat> and thinking slow
[23:34:46 CEST] <SpeakerToMeat> Ok another stupid question then, how does ff detect the right fourcc? I mean, the source is mxf which afaik doesn't use fourcc but guuid descriptors
[23:35:27 CEST] <JEEB> GUID maps to an avcodec id
[23:35:34 CEST] <JEEB> then muxer looks up the avcodec id
[23:35:41 CEST] <SpeakerToMeat> Which is then mapped to the id
[23:35:45 CEST] <SpeakerToMeat> err
[23:35:50 CEST] <SpeakerToMeat> if I say odd stuff please forgive me.
[23:35:56 CEST] <SpeakerToMeat> I should go take a tylenol and brb
[23:36:01 CEST] <SpeakerToMeat> thanks for the guidance
[00:00:00 CEST] --- Sun Jul 22 2018