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

[burek]

[00:33:48 CET] <cluelessperson> hi all, is there a way to take a single png image, use it for 360 frames, each rotating the color hue by 1 degree?
[00:38:27 CET] <Krampus> Can ffmpeg output to a virtual video source of some sort?  I want to do something where I have a webcam on one computer and the audio/video stream shows up on another as if it was local to that computer.
[00:43:21 CET] <DHE> not really, but ffplay can do sdl-based video playback instead
[00:45:49 CET] <Krampus> Hm... not sure if that'll cover what I'm doing.  My goofy scenario is I have a linux dev workstation and a windows email/lync laptop.  I use remote desktop to connect to the laptop.  Making calls like that is kinda problematic and being able to connect the camera / microphone locally might improve things.
[00:46:07 CET] <Krampus> Or severely complecate them.  I haven't quite decided. :)
[01:01:30 CET] <c_14> Stream the audio/video to the other computer via tcp/udp/another streaming protocol?
[03:13:04 CET] <yongyung> Does resampling from 48khz to 44.1khz cause any data loss below 20khz sounds at all?
[03:13:26 CET] <TD-Linux> no.
[03:35:35 CET] <klaxa> data loss, yes but quality-wise it should not be perceivable
[03:35:53 CET] <klaxa> data is obviously lost because you have less samples per second
[03:43:45 CET] <yongyung> klaxa: That's not how it works, actually. The quality, as in precision to the "actual sound", is defined by the bit-depth. Sample frequency only determines the highest sound frequency you can represent. I just wasn't sure if the conversion is lossless.
[03:44:19 CET] <klaxa> it determines how many points you have to recreate the actual signal
[03:44:24 CET] <klaxa> and 44.1k is less than 48k
[03:44:43 CET] <yongyung> klaxa: I assume you don't really know how signal processing works, do you? ;)
[03:44:43 CET] <klaxa> the bit-depth defines the range of those points
[03:44:50 CET] <klaxa> apparently not?
[03:45:35 CET] <klaxa> i thought i did, but now i'm not sure anymore
[03:45:55 CET] <yongyung> Think of it like this... the sound waves are curves, and the DAC (digital to analog converter) recreates those curves from samples. If you have a parabola, you only need two points to perfectly recreate it
[03:46:29 CET] <klaxa> oh wait, if everything is below 20khz it shouldn't make a difference really
[03:47:07 CET] <klaxa> because you still have enough samples to accurately represent everything
[03:47:38 CET] <yongyung> Well if you record it at the same time to 44.1khz and to 48khz it definitely doesn't make a difference, but I wasn't sure if the conversion is generally lossless or not. Apparently it is.
[03:48:20 CET] <klaxa> i'm still not sure about the lossless thing, i mean you end up with different samples
[03:52:04 CET] <TD-Linux> klaxa, yeah the key bit there was "below 20khz"
[03:52:47 CET] <klaxa> i would rather say there is no information loss then, because there will be less data
[03:54:14 CET] <TD-Linux> digital resampling might not be implemented in a perfectly reversible manner though. e.g. if you go 44.1k to 48k and back again a bunch of times you might start to accumulate error, depending on how you resample
[03:55:03 CET] <yongyung> TD-Linux: Well that was my question, can I do that or not? :p (with wav pcm files, obviously)
[03:56:18 CET] <TD-Linux> you need to be careful to select the same, reversible resampling filter.
[03:56:52 CET] <TD-Linux> in the absence of quantization that's easy. but with quantization a bit more difficult
[03:59:00 CET] <yongyung> Alright, different question, I have an nvidia shadowplay recorded file, which is supposed to be 60 fps, but vlc shows  59.993276 fps instead. Do you think it'd cause audio desync issues if I reencode it with -framerate 60?
[03:59:45 CET] <c_14> You mean with -vf fps=60 or -r 60 as an output option?
[04:00:41 CET] <c_14> Or with -r as an input option?
[04:01:31 CET] <klaxa> isn't -framerate always preferred over -r?
[04:01:38 CET] <c_14> No
[04:01:41 CET] <c_14> They don't do the same thing.
[04:01:57 CET] <yongyung> Uhh, I'm not sure. Just tell me what to use :p I guess -vf fps=60 as output option would be preferred?
[04:01:59 CET] <klaxa> ah right i forgot
[04:02:01 CET] <c_14> If you ie have a file that you know is 60fps but is detected as something else, use -r
[04:02:50 CET] <c_14> (as an input option)
[04:03:00 CET] <c_14> In your case you probably want -vf fps=60
[04:03:34 CET] <c_14> This will cause an audio desync
[04:03:39 CET] <c_14> minor though
[04:03:49 CET] <c_14> (you can use the asetrate audio filter to get rid of it)
[04:04:02 CET] <c_14> (there will be a minor change in pitch though)
[04:04:06 CET] <relaxed> you could use -framerate 60 on a raw h264 file to speed it up without encoding
[04:04:09 CET] <c_14> (if the change in pitch is too much, use atempo)
[04:04:57 CET] <relaxed> no, I meant -r 60
[04:05:34 CET] <relaxed> (as an input option)
[04:08:54 CET] <relaxed> because I think -r as an input option only works with raw formats, not containers
[04:11:22 CET] <c_14> I think it should work for containers too, at least according to the docs it just regenerates the timestamps of the input file. Never tested it though.
[04:16:02 CET] <relaxed> hmm, I could have swore the man page said something about raw formats
[04:16:12 CET] Action: relaxed drinks coffee faster
[04:43:19 CET] <yongyung> c_14, relaxed: If -vf fps=60 causes a slight audio desync but needs reencoding, where's the point of using it instead of just using -r?
[04:44:17 CET] <c_14> the filter will duplicate frames to get to the desired framerate, -r will speed up the video
[04:44:22 CET] <c_14> pick your poison
[04:45:12 CET] <yongyung> Hmm alright
[04:46:18 CET] <c_14> oh, -vf fps shouldn't cause audio desync
[04:46:24 CET] <c_14> because the video length stays the same
[05:38:46 CET] <xintox> anyone stream in here?
[06:41:27 CET] <yongyung> Can anyone here speculate why the youtube encoding guidelines state that 96 or 48khz audio is preferred, when every video you download from them is 44.1khz? The video guidelines seem weird to me, too
[06:42:06 CET] <furq> the best explanation i have is that the youtube encoding guidelines are not very good
[06:42:27 CET] <yongyung> Oh I forgot to link them https://support.google.com/youtube/answer/1722171?hl=en
[06:42:43 CET] <furq> recommended audio bitrate of 384kbps for stereo
[06:42:48 CET] <yongyung> furq: Yeah... maybe. On the other hand they seem so specific. It's just weird
[06:44:11 CET] <furq> it's probably just defensively high to help minimise how much youtube's reencoding will ruin it
[06:44:48 CET] <furq> stuff like putting the moov atom at the front of the file is completely worthless when that file will never appear on youtube
[06:45:06 CET] <furq> unless maybe it makes the reencoding process faster
[06:46:25 CET] <yongyung> furq: That actually helps because youtube will start encoding while your file is still uploading
[06:46:47 CET] <furq> that makes sense then
[06:46:52 CET] <yongyung> But 48khz, 2 consecutive B frames, closed GOP, I can't make sense of those things
[07:01:09 CET] <TD-Linux> yongyung, they've switched to opus which is 48khz
[07:02:04 CET] <TD-Linux> and yeah basically you want a high quality source for their transcodes. moov at front means they can start transcodes while the upload is still in progress
[07:04:07 CET] <yongyung> TD-Linux: They've switched to opus? I've never seen a YT file use opus... I guess if they plan to switch and keep the source files it might make sense
[07:04:34 CET] <TD-Linux> yongyung, nearly all Chrome YT plays are Opus now
[07:05:07 CET] <yongyung> Not sure what that means, can you link to a video that uses Opus?
[07:06:00 CET] <TD-Linux> https://www.youtube.com/watch?v=6H1rPYkRyjE
[07:06:35 CET] <TD-Linux> er I could probably link to one less than 2 hours if you want to youtube-dl it :)
[07:06:49 CET] <furq> just to remind everyone that you can remove youtube videos from your watch history
[07:07:09 CET] <yongyung> TD-Linux: Yeah I was about to ask lol
[07:07:51 CET] <TD-Linux> https://www.youtube.com/watch?v=OZpBMfA9lZs
[07:08:10 CET] <TD-Linux> furq, I am pulling these videos from my watch history :)
[07:08:52 CET] <TD-Linux> but just youtube-dl -F will tell you if it has opus, and most videos uploaded in the last year or many views will have opus
[07:09:58 CET] <furq> yongyung: https://www.youtube.com/watch?v=LfJTcP87hsU
[07:10:02 CET] <furq> enjoy
[07:13:04 CET] <yongyung> TD-Linux: Uhh... Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)
[07:15:02 CET] <TD-Linux> yongyung, umm your video downloader is picking the wrong stream then?
[07:15:26 CET] <TD-Linux> it has opus streams @ 50, 70, and 160 kbps
[07:16:00 CET] <TD-Linux> youtube's javascript certainly picks opus first
[07:16:09 CET] <furq> yongyung: youtube-dl -f webm [url]
[07:16:29 CET] <yongyung> TD-Linux: I use clipconverter.cc usually, and picked the 1080p option. I don't think they're transcoding anything?
[07:16:49 CET] <TD-Linux> no, but youtube also has 128k aac available on most videos.
[07:17:18 CET] <yongyung> Hmm that's certainly interesting
[07:17:52 CET] <TD-Linux> for youtube on potatoes
[07:19:31 CET] <furq> it defaults to avc/aac here
[07:19:39 CET] <furq> at 720p
[07:20:20 CET] <furq> maybe because of firefox's excellent dash support, although iirc it's had webm dash support for longer than mp4
[07:23:06 CET] <yongyung> The hell is vp9
[07:23:08 CET] <yongyung> 303          webm       1920x1080  DASH video 4754k , vp9, 60fps, video only, 104.18MiB
[07:23:33 CET] <yongyung> and youtube has audio-only? it's like a whole new world
[07:24:07 CET] <yongyung> They didn't have all this fancy stuff when I wrote my youtube downloader :D
[07:25:14 CET] <yongyung> So they basically only have separate audio and video streams now and just put them together after the fact
[07:31:55 CET] <yongyung> TD-Linux: So since YT uses Opus I guess we solved the 48khz mystery, any ideas about "2 consecutive B frames" and "Closed GOP. GOP of half the frame rate."? Do you think encoding with exactly those explicit settings would give any benefit?
[07:32:12 CET] <furq> i can only assume it lets them decode it faster
[07:32:44 CET] <TD-Linux> my guess is people with awful encoders really wanted to feel good that they put the right numbers in
[07:32:54 CET] <yongyung> furq: Considering they actually re-encode it I don't think they care about decoding speed...
[07:33:18 CET] <TD-Linux> those settings will give you the best results with a JM derived encoder
[07:33:42 CET] <furq> by them i mean their encoder
[07:34:32 CET] <furq> speaking of youtube uploads, i wonder if they accept flac in mkv yet
[07:34:45 CET] <TD-Linux> yongyung, YT uses MSE now so it delivers video and audio tracks separately to the browser
[07:35:05 CET] <TD-Linux> and VP9 is their newest video codec
[07:40:05 CET] <yongyung> Why is youtube-dl default selecting h264 and vorbis, and where the hell did it even get vorbis from Oo
[07:45:03 CET] <TD-Linux> older YT videos have vorbis as well. I dunno, youtube-dl's selection is kind of wonky
[07:45:51 CET] <furq> it always picks h264/aac for me
[07:46:12 CET] <furq> i can't say i've used it much since dash started working in firefox though
[07:46:24 CET] <furq> s/dash/mse/
[07:46:26 CET] <yongyung> Hmm interesting, some videos have even substantially higher bit rates for vp9 than for h264
[07:46:47 CET] <yongyung> like, 5554k vs 7031k
[07:51:21 CET] <TD-Linux> yeah. I'm not sure exactly but I think they set a higher quality target for their VP9 encodes than H264. so easily compressible videos are quite a bit smaller, and hard videos get bigger
[07:53:00 CET] <furq> probably helps with public perception of VP9
[07:53:22 CET] <TD-Linux> here's an example where VP9 is a lot smaller https://www.youtube.com/watch?v=_Q6J2_nvLSI
[07:55:40 CET] <TD-Linux> furq, maybe, though most users don't know what video codec they are using
[08:01:05 CET] <yongyung> TD-Linux: Can I somehow tell youtube-dl to download two specific  format codes (video and audio) and merge them into an mkv file?
[08:02:16 CET] <yongyung> Okay so a comma seperated list works, let's see if I can get it to merge
[08:04:49 CET] <jafa> hi guys, decoding mpeg2 video (720p60) and feeding it into a filter graph set to "copy" with a pixel format of NV12... the profiler is saying the filter graph is using more CPU (just) than the mpeg2 decode
[08:05:06 CET] <jafa> which seems crazy
[08:05:25 CET] <jafa> what pixel format does the mpeg2 decoder natively spit out?
[08:05:52 CET] <jafa> figure I will compare the profiler results with the filtergraph not changing the pixel format
[08:06:04 CET] <furq> yongyung: -f 123+456
[08:07:18 CET] <TD-Linux> jafa, probably planar YUV
[08:07:18 CET] <jafa> (filtergraph set to "copy" is because this code is common and the filter string is set differently depending on the input video properties)
[08:10:00 CET] <jafa> ok, yeah - seeing a linesize of 1280, 640, 640
[11:38:32 CET] <hepek> Hello everybody.
[11:39:20 CET] <waressearcher2> hepek: hallo und herzlich willkommen
[11:39:33 CET] <hepek> danke
[11:40:01 CET] <hepek> Is there a list of av codecs patented in the US? Some people at my company are concerned that LGPL version of ffmpeg that we use for one of our projects can get us sued by some megacorp for patent infringement.
[11:41:00 CET] <hepek> If there is no such a resource, what would be the best way to check? go to patent.google.com and search for each codec in ffmpeg?
[11:41:44 CET] <hepek> We already pay for h264, mpeg* and aac, for other products. What else could be there?
[11:48:47 CET] <DHE> h265 would be similarly encumbered
[11:50:01 CET] <DHE> the other way to look at it is that the codecs google tries to push for youtube (vp9 and opus) should be either non-patented or royalty-free. do your own research though as opus is technically patented for example
[11:57:05 CET] <hepek> thanks DHE
[12:07:17 CET] <furq> The Opus license automatically and retroactively terminates for any entity that attempts to file a patent suit.
[12:07:20 CET] <furq> ha
[14:13:13 CET] <JonG> I want to use ffmpeg to access my webcam. I tried "ffmpeg -f v4l2 -i /dev/video0 ~/output.mp4", but I am getting an error: "Unknown input format: 'v4l2'". Same with "video4linux2" instead of "v4l2". I therefore assume my build of ffmpeg is missing v4l2. I see that there is a configure option "--enable-libv4l2" (https://ffmpeg.org/ffmpeg-all.html#vi
[14:13:13 CET] <JonG> deo4linux2_002c-v4l2). I added this to my configuration, but running configure I get the error: "libv4l2 not found using pkg-config". How do I add this to my build? I am following the guide at https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu with some modifications. I can add my full configure line if helpful?
[14:27:23 CET] <DHE> depending on your distro you may need a "-devel" package. eg: centos has libv4l-devel
[14:35:45 CET] <JonG> Thanks. has a package libv4l-dev. Installing it with sudo apt-get doesn't seem to affect my issue though. I can see "/usr/lib/x86_64-linux-gnu/pkgconfig/libv4l2.pc", which I guess is the file I need. Maybe I just need to point the ffmpeg / pkg-config to it in the configure options?
[14:35:58 CET] <JonG> Ubuntu has**
[14:39:43 CET] <JonG> Something like:  PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig" ./configure ... ? (Doesn't work)
[15:34:08 CET] <squeegily> I'm trying to set the audio output sink for playing audio, but setting -f pulse "$(sink)" as indicated at https://ffmpeg.org/ffmpeg-devices.html#Examples-12 is firstly not recognized by ffplay, and secondly it does NOT set the output device, just the "friendly" stream name as reported by pavucontrol. I could set it to "spiedermane" and it wouldn't make a difference.
[15:39:13 CET] <squeegily> Specifically, I want to play a 358kHz audio file on the non-default sound card (48kHz), but Pulse has a hardcoded 192kHz limit which it doesn't properly report to programs. fftools have this limit hardcoded, but MPV (my default media player) has no such workaround, and VLC has an awful resampler by default, so I have to use ffplay for this. But I can't figure out how to change the audio output sink.
[15:40:13 CET] <BtbN> Use ffmpeg instead
[15:40:23 CET] <squeegily> I can't find the way to do it with ffmpeg
[15:40:55 CET] <BtbN> Just use the pulse output and set whatever parameters you want.
[15:41:10 CET] <squeegily> But how do I change the output sink?
[15:41:24 CET] <BtbN> It propably has an option for that.
[15:41:28 CET] <bencoh> man ffmpeg-devices
[15:41:36 CET] <BtbN> Or just move it in pavucontrol after it has started.
[15:42:04 CET] <squeegily> I don't want to do that since that saves a permanent override for ffmpeg
[15:42:22 CET] <squeegily> And I've been digging around in the manpages since Saturday
[15:42:44 CET] <bencoh> so what doesnt work with ffmpeg -i foobar -f pulse ?
[15:42:58 CET] <BtbN> It saves the output sink permanently anyway
[15:43:01 CET] <squeegily> that works... for the default audio device
[15:43:11 CET] <bencoh> isn't there a "device" option?
[15:43:20 CET] <squeegily> Nothing that I could find
[15:43:57 CET] <BtbN> You're bad at searching then.
[15:43:58 CET] <squeegily> https://ffmpeg.org/ffmpeg-all.html#Options-57 is where it would be if it existed
[15:44:02 CET] <BtbN> http://ffmpeg.org/ffmpeg-all.html#pulse-1
[15:44:04 CET] <squeegily> pulse output options
[15:44:07 CET] <squeegily> nothing there
[15:44:15 CET] <squeegily> "name" is not the output device
[15:44:24 CET] <BtbN> That's the pulse input you just linked.
[15:46:02 CET] <squeegily> So, from that page you sent the link to
[15:46:08 CET] <squeegily> what flag controns the output device
[15:46:16 CET] <bencoh> the "device" one?
[15:48:22 CET] <squeegily> Thanks.. I don't know how I missed that
[15:49:24 CET] <squeegily> So the -device option is completely missing from ffplay, with nothing to replace it?
[15:50:10 CET] <BtbN> ffplay is, basicaly, just ffmpeg with some default output settings
[15:50:27 CET] <squeegily> And the really nice spectroscope and volume controls
[15:50:49 CET] <bencoh> -option, maybe
[15:51:19 CET] <squeegily> Failed to set value 'device' for option 'option': Option not found
[15:51:55 CET] <durandal_170> ffplay spectroscope is limited use ffmpeg
[17:54:36 CET] <prelude2004c> hey guys.. quick question if i may..doing some transcoding with ffmpeg... one of the players is complaining that when they use the PVR function and record something the "#EXT-E-PVRSTARTTIME" is smaller than 0. I have no idea why that is but it seems that on playback it always plays starting with the last file instead of the first file :( .. Strange right ? is there something i am doing wrong ?
[18:29:42 CET] <cluelessperson> has anyone tested FFSERVER in a LARGE distribution?
[18:29:47 CET] <cluelessperson> 1000+ streams at a time?
[18:39:49 CET] <DHE> ffserver is a borderline hack for doing streaming. if you're doing large scale you want something else. nginx with the rtmp module maybe? (depends on your needs obviously)
[18:45:54 CET] <prelude2004c2> hey guys.. pulling in a source with ffmpeg " skipping 1 segments ahead, expired from playlist" i get those errors and my frame rates start to drop below 25fps ...i get freezing and stuff but yet when i play the same source with VLC i don't have any issues... anyone know why ?
[18:46:01 CET] <prelude2004c2> is there any param i can set to not tod htat ?
[18:50:28 CET] <DHE> sounds like it's not playing fast enough, or it's playing from the first chunk of a live playlist
[18:50:42 CET] <DHE> you start 3rd from the end (typically) for a live playlist
[18:53:21 CET] <prelude2004c2> kind of strange
[19:00:22 CET] <prelude2004c2> is there some way to fix that ? i mean.. it can't play fast enough and files are vanishing in the source before they can be downloaded
[19:01:18 CET] <DHE> hls is the output from ffmpeg?
[21:02:23 CET] <nadermx> I'm currently trying to convert a flv stream to stdout so I can stream the file as a downloadable mp4
[21:03:19 CET] <nadermx> the issue I'm having is I can get the file to show framerate, but the time of the file is not complete
[21:03:48 CET] <nadermx> 'ffmpeg -i "%s" -r 30 -vcodec libx264 -s 640x480 -pix_fmt yuv420p -acodec libmp3lame -f ismv -'
[21:04:09 CET] <nadermx> is what i've tried, also tried chaning the ismv to mov, and quickstart as well, I can't seem to get ac ombination that works
[21:07:33 CET] <DHE> I suppose you want 'mp4' as an output, but officially it's corrupted unless you write it to a file so ffmpeg can seek and fix it when it's done...
[21:08:05 CET] <nadermx> yeah, but I saw you can move the moov to the front
[21:13:24 CET] <kepstin> yeah, but you can only do that if you can write the file and then go back and move the moov afterwards
[21:16:00 CET] <ChocolateArmpits> well you can't really call it moving, more like rewriting the file completely
[21:16:10 CET] <nadermx> would be it possible to make it a h.246  and rename it to a .mp4, so by the time the file is fully loaded the mp4 container can go and read it fully
[21:17:37 CET] <kepstin> ChocolateArmpits: I think there's an option to pre-allocate some space to use for it to avoid the rewrite? or maybe I'm confusing it with the webm index
[21:18:03 CET] <ChocolateArmpits> kepstin: no such thing for mp4 that I know of
[21:20:35 CET] <kepstin> nadermx: if you want to stream mp4 to a client as it's being encoded, you pretty much have to use a chunk-based streaming method like HLS or DASH.
[21:21:03 CET] <kepstin> (in which case, you have a minimum latency equal to the length of a chunk)
[21:21:45 CET] <nadermx> @kepstin and I could make this downloadable file?
[21:23:39 CET] <kepstin> if you want a downloadable file, just encode to a file then serve it, don't bother with trying to stream it as it encodes.
[21:24:17 CET] <nadermx> but this takes way too long on very large files
[21:24:35 CET] <nadermx> and I'm trying to avoid having to store a significant amount of the file as its being encoded
[21:24:55 CET] <nadermx> I'm fine with some latentacy
[21:25:12 CET] <kepstin> well, you're just hitting the limitations of the mp4 format. it's simply not designed to handle this.
[21:25:54 CET] <nadermx> hrmm, so then as you said if I try and use DASH
[21:26:21 CET] <DHE> or a streamable format, like mpegts
[21:26:39 CET] <DHE> (which has a fair amount of overhead but is very streaming-friendly)
[21:27:02 CET] <kepstin> dash is usable for live-streaming to a browser or player, but it doesn't make a file that can be downloaded/saved to hd.
[21:29:18 CET] <nadermx> @DHE alright, mpegts maybe? wouldn't the ISMV also be somewhat useable?
[21:30:17 CET] <DHE> don't know enough about it to be sure. just know that it's Yet Another(tm) variant of .mp4
[21:30:25 CET] <kepstin> depends on your player support requirements, really
[21:30:37 CET] <kepstin> have to research what players you support and what formats work with them
[21:31:34 CET] <DHE> mpegts tends to be highly supported. it's what over-the-air broadcasts are encapsulated in
[21:33:17 CET] <kepstin> hey, if you're doing downloadable files only and know people have fairly good players, you could just go for mkv with an end-of-file index.
[21:34:57 CET] <TD-Linux> kepstin, actually dash can be used with a single fragmented mp4 file. just hope your player supports fragmented mp4.
[21:35:07 CET] <TD-Linux> or use matroska/webm
[21:36:13 CET] <nadermx> could I do a m4v with audio?
[21:37:08 CET] <TD-Linux> m4v is just another extension for mp4
[21:37:47 CET] <nadermx> right, but my logic is the mp4 isn't going to become a mp4 till the file is fully downloaded on the users machine, at which point the entire file is there.
[21:39:00 CET] <nadermx> When i try converting on the fly to m4v the video plays with no audio
[21:39:22 CET] <ChocolateArmpits> m4v is a video-only format
[21:39:32 CET] <ChocolateArmpits> m4a is an audio equivalent
[21:40:15 CET] <nadermx> ah ok
[21:42:17 CET] <nadermx> @kepstin not sure what most users will be on and figure mp4 is most widely supported
[22:09:55 CET] <Betablocker> released a tool today on github - the goal is very easy h264 video streaming for everyone on websites without streaming provider - you are welcome to test it  https://datarhei.github.io/restreamer/ :)
[22:38:31 CET] <TD-Linux> Betablocker, neat! I'd make it more clear on the website that the external stream providers in the pic are optional
[22:40:44 CET] <Betablocker> ok thank you for the hint TD-Linux
[22:42:01 CET] <Betablocker> there is optimization potential on the website & we will update it in the next weeks. but the software is working and the installation should be clear
[22:50:44 CET] <nadermx> seems pretty cool
[22:53:51 CET] <nadermx> can you write the metadata duration to the file?
[22:57:14 CET] <Betablocker> not out of the box yet but ffmpeg is runnig under the engine hood - so it should work with a tiny hack
[22:58:56 CET] <nadermx> Mind sharing that hack?
[00:00:00 CET] --- Wed Jan  6 2016