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

[burek]

[00:46:45 CET] <Anthropohedron> My understanding of ffmpeg and various video formats is weak, but growing. I've put together a script for myself to rip (with dvdbackup) and encode (with ffmpeg) DVDs to m4v. I am trying to improve that script so I can include subtitles.
[00:49:51 CET] <Anthropohedron> I'm working with a particular DVD that has subtitles in English, Spanish, and French. Using ffprobe on my rip (remember, with dvdbackup), I see three subtitle streams when I use "ffprobe -v error -show_entries stream=index,codec_name,codec_type", streams 6-8, but just ffprobe -i or ffmpeg -i only shows streams 0-5.
[00:51:36 CET] <Anthropohedron> If someone can help me extract the English subtitles to its own file, I think I can figure out the rest, but the various flags I've tried with ffmpeg have failed me. It mostly seems to be an issue with specifying the correct stream.
[00:52:31 CET] <Anthropohedron> This fails: ffmpeg -i concat:"$VOBFILES" -c:s:0:6 copy subtitles
[00:52:45 CET] <Anthropohedron> Help?
[01:09:09 CET] <klaxa> having some output would make a lot of things more concrete and keep people from guessing
[01:21:46 CET] <Anthropohedron> klaxa: http://pastebin.com/CXs5kKU8
[01:22:38 CET] <Anthropohedron> klaxa: http://pastebin.com/8x3zQLJL
[01:24:02 CET] <Anthropohedron> klaxa: http://pastebin.com/j0YvWniZ
[01:24:11 CET] <Anthropohedron> klaxa: What else would you like to see?
[01:24:38 CET] <klaxa> well the last one fails because it has no output
[01:24:54 CET] <klaxa> and also only subtitles
[01:25:06 CET] <klaxa> ah that's what you want
[01:26:02 CET] <klaxa> hmm, i would suggest using .ass or .srt
[01:26:38 CET] <Anthropohedron> Give me a commandline to try and I happily will.
[01:27:24 CET] <Anthropohedron> http://pastebin.com/EQYYJpZ0
[01:28:56 CET] <klaxa> oh wait a minute
[01:29:45 CET] <klaxa> with the concat protocol the subtitles seem to get lost
[01:29:45 CET] <Anthropohedron> ?
[01:29:53 CET] <klaxa> http://pastebin.com/j0YvWniZ
[01:29:54 CET] <klaxa> that one
[01:30:08 CET] <klaxa> there are no subtitle streams in concat:$VOBFILES
[01:30:30 CET] <klaxa> maybe not every file has them?
[01:31:17 CET] <Anthropohedron> http://pastebin.com/huU5tjYm
[01:32:13 CET] <klaxa> ah, i'm a dumb, it also has to be: ffmpeg -i movie/VIDEO_TS/VTS_01_1.VOB -map 0:6 subtitles.ass
[01:32:27 CET] <klaxa> you can't really copy dvd_subtitle i think
[01:32:34 CET] <klaxa> someone might be wiser than me and know better
[01:32:37 CET] <Anthropohedron> ffprobe shows the subtitle streams in that one .vob when I invoke it one way <http://pastebin.com/CXs5kKU8> but not the other <http://pastebin.com/8x3zQLJL>
[01:32:56 CET] <Anthropohedron> I'll try that, one sec.
[01:33:09 CET] <klaxa> it shows them both times?
[01:34:43 CET] <Anthropohedron> If I explicitly ask for -show_entries stream then I see 8 streams. If I just do ffprobe <file> then it shows 5 streams.
[01:35:17 CET] <Anthropohedron> Also, http://pastebin.com/B7SM60D8 looks a bit better. It just can't convert dvd_subtitle to ass.
[01:36:01 CET] <klaxa> what about
[01:36:01 CET] <klaxa>   Stream #0:6[0x20]: Subtitle: dvd_subtitle
[01:36:01 CET] <klaxa>     Stream #0:7[0x21]: Subtitle: dvd_subtitle
[01:36:01 CET] <klaxa>     Stream #0:8[0x22]: Subtitle: dvd_subtitle
[01:36:02 CET] <klaxa> ?
[01:37:25 CET] <Anthropohedron> Right, I see that only under some circumstances and I don't understand why I don't sometimes.
[01:37:48 CET] <klaxa> depending on the file maybe?
[01:38:08 CET] <klaxa> also, i can't seem to find how to properly extract dvdsub subtitles
[01:38:23 CET] <klaxa> https://trac.ffmpeg.org/wiki/ExtractSubtitles this is the closest documentation to what you need
[01:40:08 CET] <Anthropohedron> Right, I see that only under some circumstances and I don't understand why I don't sometimes.
[01:40:14 CET] <Anthropohedron> Whoops.
[01:42:22 CET] <Anthropohedron> I've made some progress, but it seems to be picky about the naming of the output file and I don't know what I should be using: http://pastebin.com/15Ke5tc6
[02:55:48 CET] <lindylex> Is there a way I can get a display where this is record the screen?  ffmpeg -f x11grab -r 25 -s 640x640 -i :0.0+7,53 -vcodec huffyuv screencast.avi
[03:03:18 CET] <DHE> ffplay -f x11grab -r 25 -s 640x640 -i :0.0+7,53    (and move the player window out of the way when it pops up)
[03:03:33 CET] <DHE> I'm assuming you have a big display, like 1080p, with lots of room to put the player aside
[03:03:57 CET] <DHE> or, you know, record for a few seconds and play the video back to look.
[03:09:21 CET] <lindylex> DHEDHe: Failed to set value '25' for option 'r': Option not found
[03:11:02 CET] <lindylex> Thanks I used this  ffplay -f x11grab  -s 640x640 -i :0.0+7,53
[03:30:10 CET] <DHE> oh. oops. sorry.
[03:44:25 CET] <thebombzen> lindylex: use -framerate
[03:44:26 CET] <thebombzen> not -r
[03:44:32 CET] <thebombzen> it depends on what your display is
[03:45:06 CET] <thebombzen> lindylex: what happens if you run this? xrandr -q | grep '\*' | cut -d '*' -f 1 | xargs echo
[03:45:26 CET] <lindylex> 1920x1200 59.95
[03:46:43 CET] <lindylex> thebombzen:  this works perfectly  ffplay -f x11grab -framerate 25 -s 640x640 -i :0.0+7,53
[03:47:02 CET] <thebombzen> well you should use -framerate 59.95 then
[03:47:12 CET] <lindylex> ok let me do that.
[03:47:17 CET] <thebombzen> the second # is the monitor's refresh rate
[03:47:38 CET] <lindylex> Got it
[03:47:40 CET] <thebombzen> the first # is your monitor's size
[03:47:45 CET] <thebombzen> but you probably knew that
[03:47:57 CET] <lindylex> I did.  Thanks for still explaining.
[03:48:19 CET] <thebombzen> also your monitor's refresh rate is set to 59.95 which is really weird
[03:48:23 CET] <thebombzen> tbh it probably should be set to 60
[03:49:01 CET] <lindylex> I have no idea why this is so.  Is this something on the hardware I need to adjust?
[03:50:03 CET] <lindylex> On the monitor it says 1920 X 1200 74KHz 60 Hz 60HZ
[03:52:56 CET] <lindylex> I have seen screen cast that follow the mouse around with a fix box recording dimension.  Is this possible with ffmpeg?
[03:57:32 CET] <thebombzen> try running this:
[03:57:42 CET] <thebombzen> xrandr --output HDMI-0 --mode 1920x1200 --rate 60.00
[03:57:44 CET] <thebombzen> what happens?
[03:58:40 CET] <thebombzen> or instead of HDMI-0
[03:58:44 CET] <thebombzen> whatever it's actually called
[03:58:48 CET] <thebombzen> see xrandr -q for the list
[04:10:12 CET] <lindylex> thebombzen:  http://termbin.com/staw
[04:28:15 CET] <thebombzen> lindylex: ah okay
[04:28:24 CET] <thebombzen> it appears it doesn't support anything other than 59.95
[04:28:26 CET] <thebombzen> for some reason
[04:33:39 CET] <lindylex> This is the hardware:  samsung syncmaster 275t  It broken once and I sent it back as RMA they sent me a used one.  It has not failed since.  I got it in 2008.  I can not wait ofr it to finally fail so I can get a larger screen tv I can connect my computer to.
[09:20:17 CET] <lindylex> I am trying to record audio with ffmpeg -f alsa -ac 2 -i hw:0,0 -y alsaout.wav and it has so much fuzziness in the background.
[09:27:56 CET] <c_14> lindylex: probably your microphone, does arecord produce the same effect?
[09:28:47 CET] <lindylex> I used it before in the past and it had no terrible background noise.  Let me check with arecord.
[09:31:43 CET] <lindylex> c_14: I did this arecord -vv -fdat o.wav and it sounds the same.  FYI ffmpeg version 3.2.4-1
[09:32:26 CET] <c_14> then it's either your microphone or your alsa drivers/setup
[09:32:58 CET] <lindylex> I do have pusleaudio installed.
[09:33:06 CET] <c_14> try using that instead?
[09:33:09 CET] <c_14> -f pulse -i default
[09:34:52 CET] <lindylex> ok one sec
[09:36:04 CET] <lindylex> This arecord -f pulse -i default o.wav gives me this error arecord: main:604: wrong extended format 'pulse'
[09:36:15 CET] <c_14> ffmpeg -f pulse -i default
[09:36:48 CET] <kerio> another patent dies ;o
[09:37:17 CET] <lindylex> It sounds the same.  Lots of background humming.
[09:38:15 CET] <c_14> then it's probably the microphone
[09:39:01 CET] <lindylex> This is what it sounds like https://expirebox.com/download/7ed6587d5f28c5cb1a09aaffd5069ac6.html
[09:44:46 CET] <c_14> no idea, you might want to ask in #pulseaudio since it doesn't seem to be a problem with ffmpeg but rather with your audio setup
[09:44:55 CET] <c_14> maybe the levels are messed up
[09:45:54 CET] <lindylex> ok
[09:46:03 CET] <lindylex> thanks
[09:49:34 CET] <matkatmusic> anyone have any experience writing raw RGB uint8_t's into an AVFrame?
[09:51:15 CET] <matkatmusic> I'm helping another coder figure out why this call to sws_scale() isn't writing data correctly (the output video is all black)
[09:51:16 CET] <matkatmusic> https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ffmpeg/filmstro_ffmpeg_FFmpegVideoScaler.cpp#L104
[09:53:04 CET] <Mavrik> why are you setting data 4 times? O.o
[09:53:34 CET] <matkatmusic> See this reply: https://github.com/filmstro/filmstro_ffmpeg/issues/3#issuecomment-287697897
[09:53:39 CET] <matkatmusic> I asked the same thing
[09:54:35 CET] <Mavrik> That's fugly.
[09:55:02 CET] <matkatmusic> I didn't write that github lib.  i'm just helping him get it working.
[09:55:07 CET] <Mavrik> but probably not critically wrong
[09:55:15 CET] <matkatmusic> the ffmpeg library is really hard to use
[09:55:17 CET] <Mavrik> hard to say what's actually going on in that piece of code
[09:55:27 CET] <Mavrik> because the code architecture is horrible
[09:55:28 CET] <matkatmusic> if you're trying to use it via the API, i mean.
[09:55:33 CET] <Mavrik> it accepts pixel format as a parameter?
[09:55:48 CET] <Mavrik> and then it just ignores that and magically infers it needs 4 bytes per pixel in a single plane?
[09:55:49 CET] <Mavrik> wat.
[09:55:57 CET] <matkatmusic> what are you referring to?
[09:56:31 CET] <matkatmusic> I'm assuming you're referring to this: https://github.com/FFmpeg/FFmpeg/blob/03ce71e4a1187340720e1569ac96c285c145a1f7/libswscale/swscale.c#L824
[09:57:02 CET] <matkatmusic> er, more specifically https://github.com/FFmpeg/FFmpeg/blob/03ce71e4a1187340720e1569ac96c285c145a1f7/libswscale/swscale.c#L753
[09:57:08 CET] <matkatmusic> that's the start of the function
[09:57:13 CET] <matkatmusic> sws_scale()
[09:57:29 CET] <Mavrik> I'm refering to this: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ffmpeg/filmstro_ffmpeg_FFmpegVideoScaler.cpp#L82
[09:57:39 CET] <Mavrik> vs this: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ffmpeg/filmstro_ffmpeg_FFmpegVideoScaler.cpp#L58
[09:57:49 CET] <Mavrik> the "scaler" gets input format as a parameter
[09:58:08 CET] <Mavrik> but then it hardcodes the size of the plane
[09:58:19 CET] <Mavrik> I suggest you take a look for those kind of code smells:
[09:58:25 CET] <Mavrik> 1.) Is the format set properly for your encoder?
[09:58:26 CET] <matkatmusic> I wish mcjack were here to cmoment, cuz that's his code.
[09:58:34 CET] <matkatmusic> comment
[09:58:39 CET] <Mavrik> 2.) Is the AVFrame actually allocated (your pointers should be valid)
[09:58:56 CET] <Mavrik> 3.) Do you set a proper RGB vs. output format?
[09:59:08 CET] <Mavrik> 4.) Do you get an error/warning in the log when running he scaler
[09:59:15 CET] <Mavrik> All of that can easily be checked with a debugger through that code
[10:00:17 CET] <matkatmusic> that brings me to the question, is there a way to use ffmpeg as raw code inside a c++ project instead of having to compile, and link against the compiled binary for a project?
[10:03:25 CET] <Mavrik> Not sure I get the question.
[10:03:32 CET] <Mavrik> You have to compile and link to it in any case.
[10:03:41 CET] <Mavrik> The difference is just when you do it.
[10:04:03 CET] <Mavrik> Due to complexity of the build system, use static libav
[10:04:17 CET] <Mavrik> .. use static libav libraries that will get linked into your binary
[10:09:43 CET] <matkatmusic> yeah, I am trying to understand how he's using it in this "dependencies" section:https://github.com/filmstro/filmstro_ffmpeg
[10:10:06 CET] <matkatmusic> "you will have to build ffmpeg and link your project to it. We use this flags:"
[10:10:22 CET] <matkatmusic> Why can't you just import the source code into a project?
[10:12:16 CET] <Mavrik> Because you'd have to completely recreate the compilation flags for source, handle ASM compilation and for a lot of ffmpeg code that would be illegal.
[10:12:38 CET] <matkatmusic> yuk
[10:12:39 CET] <matkatmusic> lol
[10:13:58 CET] <matkatmusic> ugh, why is ffmpeg so ugly lol
[10:22:46 CET] <matkatmusic> like, why is it written in such a way that it's so difficult to use the API and you have to link against the compiled binary?
[10:23:04 CET] <matkatmusic> because there are so many video formats and it handles all of them?
[10:34:44 CET] <thebombzen> kerio: which patent?
[10:34:51 CET] <kerio> ac-3
[10:35:16 CET] <thebombzen> huh
[10:35:20 CET] <thebombzen> but ac-3 sucks so who cares?
[10:38:07 CET] <kerio> dvd? bluray?
[10:39:32 CET] <thebombzen> ah so apparently this explains it quite well https://ac3freedomday.org/
[10:39:40 CET] <thebombzen> it sucks so nobody cares about ac3 encoding
[10:39:47 CET] <thebombzen> but now it's possible to decode ac3 without licensing fees
[10:40:15 CET] <thebombzen> but afaik libavcodec has an ac-3 decoder that's LGPL, how does that mesh with the patent on ac-3?
[10:40:49 CET] <furq> the same way all the other patented codecs in libavcodec do
[10:41:01 CET] <furq> at least until yesterday
[10:42:13 CET] <Spring> is there a way of finding the total duration of a video taking into account the trim values specified prior to encoding?
[10:47:58 CET] <thebombzen> ah
[10:47:59 CET] <thebombzen> speaking of which
[10:48:06 CET] <thebombzen> how does ffmpeg have an HEVC or H.264 decoder
[10:48:11 CET] <thebombzen> given that they're patented
[10:48:14 CET] <thebombzen> legally how does that work
[10:48:30 CET] <kerio> "¯\_(Ä)_/¯"
[10:48:55 CET] <kerio> if you want to use libavcodec's h264 decoder, pay the fee
[10:49:12 CET] <thebombzen> uh
[10:49:13 CET] <thebombzen> what?
[10:49:19 CET] <thebombzen> do you mean comercially
[10:49:20 CET] <thebombzen> or like
[10:49:28 CET] <thebombzen> technically are we all supposed to be paying the fee
[10:49:36 CET] <furq> the latter
[10:49:38 CET] <kerio> i have honestly no idea
[10:49:41 CET] <kerio> and i don't care
[10:49:50 CET] <thebombzen> but what about things like static mpv builds
[10:49:54 CET] <furq> unless it's on a tv or something in which case the tv manufacturer paid the fee
[10:50:03 CET] <kerio> but if you're selling stuff, you should probably get a lawyer to figure that out
[10:50:14 CET] <thebombzen> cause publishing a static mpv build or static ffmpeg build like lacsh0r or zeranoe
[10:50:17 CET] <kerio> thebombzen: again, that is completely irrelevant
[10:50:21 CET] <thebombzen> that sounds more dubious compared to like
[10:50:24 CET] <thebombzen> just building a local copy
[10:50:35 CET] <kerio> zeranoe is not, as far as we know, using his static build to decode and play h264 content
[10:50:45 CET] <thebombzen> lol
[10:50:47 CET] <thebombzen> that loophole
[10:50:50 CET] <thebombzen> also, if that's true, why is LAME still "nonfree"
[10:50:52 CET] <kerio> ?
[10:50:55 CET] <thebombzen> cas in
[10:51:00 CET] <kerio> no i mean
[10:51:01 CET] <furq> lame has never been nonfree
[10:51:02 CET] <furq> it's gpl
[10:51:03 CET] <thebombzen> Fraunhofer's mp3 patents are expired
[10:51:10 CET] <furq> but nonfree has nothing to do with patents
[10:51:11 CET] <thebombzen> furq: it requires --enable-nonfree
[10:51:13 CET] <furq> it's gpl compatibility
[10:51:17 CET] <furq> and no it doesn't
[10:51:23 CET] <kerio> it's your fault if you're using it to play h264 without paying the fee
[10:51:28 CET] <ritsuka> patents and source code license are two separated things
[10:51:48 CET] <furq> fdk is nonfree because the license is gpl incompatible
[10:51:52 CET] <furq> it has nothing to do with aac patents
[10:52:10 CET] <thebombzen> ah okay
[10:52:13 CET] <thebombzen> so I'm a criminal
[10:52:13 CET] <kerio> and the question still stands, anyway
[10:52:17 CET] <kerio> why are you using mp3 instead of opus? :^)
[10:52:28 CET] <thebombzen> I'm not
[10:52:33 CET] <furq> you're only a criminal if you're in the us
[10:52:36 CET] <thebombzen> it was more just an "on principle" question
[10:52:39 CET] <thebombzen> and I'm in the US
[10:52:40 CET] <thebombzen> so yes
[10:52:42 CET] <furq> if you're in the eu then there's no such thing as software patents
[10:52:44 CET] <ritsuka> if you live if a state where software patents are a thing, nothing prevent the patent holders from suing you if you distribute a compiled binary probably
[10:52:46 CET] <thebombzen> so given that I use lavc's h264 decoder I'm a criminal
[10:52:47 CET] <kerio> excuse me sir, do you have a moment to talk about opus christ?
[10:52:49 CET] <thebombzen> cause I don't pay the fee
[10:53:12 CET] <thebombzen> and the only time I don't use opus is when I'm muxing mp4
[10:53:16 CET] <thebombzen> in which case I use voribs
[10:53:22 CET] <furq> eww
[10:53:42 CET] <thebombzen> well vorbis is better than aac
[10:53:48 CET] <thebombzen> so not any reason not to use it
[10:54:00 CET] <furq> why would you even use mp4 if you're going to mux nonstandard codecs into it
[10:54:09 CET] <thebombzen> it's definitely supported
[10:54:16 CET] <furq> not by 99% of things that support mp4
[10:54:18 CET] <kerio> >better than aac
[10:54:20 CET] <kerio> what
[10:54:22 CET] <thebombzen> it is
[10:54:31 CET] <furq> kerio: it's probably better than fdk
[10:54:36 CET] <thebombzen> libvorbis is a better encoder than fdk
[10:54:36 CET] <furq> it's roughly on a par with apple aac
[10:54:40 CET] <thebombzen> it's probalby on par with quicktime
[10:54:42 CET] <thebombzen> fuck ninjad
[10:54:48 CET] <furq> hi
[10:54:48 CET] <kerio> apple \o/
[10:54:57 CET] <thebombzen> also mp4 technically does support opus according to the list of fourcc's
[10:55:04 CET] <thebombzen> but libavformat refuses to mux it
[10:55:18 CET] <thebombzen> weirdly enough, libavformat *also* won't mux opus inside nut
[10:55:22 CET] <thebombzen> which is weird
[10:55:22 CET] <furq> but yeah i don't see why you'd use mp4 other than for compatibility
[10:55:30 CET] <furq> in which case vorbis is super dumb
[10:55:46 CET] <thebombzen> short answer is that I've had issues with the matroska muxer sometimes
[10:56:10 CET] <thebombzen> given that even windows media player supports 10bit HEVC + Opus + Matroska
[10:56:17 CET] <thebombzen> not really any reason
[10:56:27 CET] <furq> but yeah the official ffmpeg answer for "does ffmpeg infringe patents" is "we don't know"
[10:56:36 CET] <furq> probably followed by "we don't care because we all live in germany"
[10:56:37 CET] <thebombzen> lol
[10:56:40 CET] <thebombzen> haha
[10:56:47 CET] <__jack__> haha
[10:57:01 CET] <thebombzen> software patents are really dumb tbh
[10:57:03 CET] <__jack__> is there really human being in germany ? for real ? :O
[10:57:12 CET] <thebombzen> it's one of the less nice things about the united states
[10:57:16 CET] <furq> the license holders aren't going to come after you unless you're making money anyway
[10:57:20 CET] <thebombzen> is our shitty business protectiosn
[10:57:28 CET] <furq> they gain nothing from making an example from jimmy animes
[10:57:34 CET] <thebombzen> furq: lol you say that but about 10 years ago they did that anyway
[10:57:55 CET] <thebombzen> you remember when the RIAA tried to make examples of people right
[10:57:55 CET] <kerio> furq: preventing the spread of anime is a virtuous act in and of itself tho
[10:57:59 CET] <thebombzen> by suing them for lots of money
[10:58:04 CET] <furq> that's the RIAA
[10:58:08 CET] <furq> that's not software patent holders
[10:58:19 CET] <furq> also, remind me how that worked out for the RIAA
[10:58:29 CET] <thebombzen> it didn't
[10:58:45 CET] <thebombzen> I just think it's funny to say "they don't go after small people"
[10:58:48 CET] <thebombzen> because they totally used to
[10:58:54 CET] <kerio> they didn't get 12 trillion dollars from that single mom? :o
[10:58:55 CET] <thebombzen> the Intellectual Property Shitheads in the US
[10:58:56 CET] <furq> i mean it's a different group of people really
[10:59:04 CET] <thebombzen> it's really the same idea though
[10:59:08 CET] <thebombzen> Intellectual Property Shitheads
[10:59:22 CET] <furq> there's a case to be made there that they can scare people into paying
[10:59:26 CET] <furq> and also everyone knows that piracy is illegal
[10:59:38 CET] <thebombzen> essentially organizations formed on extorting money out of intellectual property they didn't create and only can because they already have money
[10:59:38 CET] <furq> whereas 99% of people who are infringing decoder patents haven't got a fucking clue that they're doing anything of the sort
[11:00:03 CET] <furq> and also the vast majority of people only consume media on devices where the licenses are paid for
[11:00:12 CET] <thebombzen> but it's also the similar product where infringing on IP laws gets you a better product than not doing that
[11:00:18 CET] <kerio> or devices for which there's no reasonable way to get a fee from
[11:00:25 CET] <kerio> like those chinese knockoff phones
[11:00:37 CET] <kerio> how do you even sue nokla
[11:00:42 CET] <kerio> does nokla even exist
[11:00:54 CET] <thebombzen> Nokia is indestructible, of course it still exists
[11:01:03 CET] <furq> i prefer sumsang
[11:01:12 CET] <thebombzen> but like just how pirates can get better quality TV than paying customers
[11:01:13 CET] <Spring> nokla, the knock-off nokia
[11:01:27 CET] <thebombzen> people who use illegal decoders get better decoders than those who pay money
[11:01:30 CET] <thebombzen> encoders too
[11:01:39 CET] <kerio> of course they get better decoders
[11:01:39 CET] <thebombzen> x264 is better than "Adobe Media Encoder" or whatever it's called
[11:01:45 CET] <thebombzen> it's the same idea
[11:01:52 CET] <kerio> they're illegally-distributed ffmpeg
[11:01:53 CET] <ritsuka> nokia is actually suing apple over some h.264 patents, lol
[11:01:59 CET] <furq> people encoding video is a tiny drop in the ocean compared to people downloading torrents
[11:02:13 CET] <kerio> ok that's not true, there's probably some weird chip doing the decoding in hardware
[11:02:22 CET] <thebombzen> but I guess what I'm saying is that one of the problems with IP law is that people who violate it generally get better products than those who don't
[11:02:28 CET] <furq> sure
[11:02:30 CET] <thebombzen> and paying customers should not get inferior products to pirates
[11:02:33 CET] <furq> nobody would disagree with that
[11:02:51 CET] <furq> i doubt that even the guys implementing DRM for bluray would disagree with that
[11:02:53 CET] <thebombzen> well for example if you wanted to watch anime in the US you'd need to use a site like crunchyroll, which streams 1080p and 1.5 Mbps
[11:02:55 CET] <furq> it's just security theatre at this point
[11:03:02 CET] <thebombzen> or you could pirate it
[11:03:05 CET] <thebombzen> and get it at 8 Mbps
[11:03:16 CET] <thebombzen> like
[11:03:18 CET] <kerio> yeah but if you want to watch anime you're a weeaboo
[11:03:23 CET] <thebombzen> guilty
[11:03:23 CET] <kerio> so there's that
[11:03:24 CET] <furq> why would you need 8mbps for 6fps static shots of a high school
[11:03:30 CET] <kerio> LOL
[11:03:36 CET] <furq> in which some kind of bakery contest is undoubtedly taking place
[11:03:42 CET] <furq> and the bakers have got magic powers
[11:03:49 CET] <furq> and one of them is a robot
[11:03:54 CET] <thebombzen> but either way
[11:04:00 CET] <furq> and they have a cute furry pal who's always there with a wisecrack
[11:04:02 CET] <kerio> furq: -tune stillimage
[11:04:03 CET] <kerio> :^)
[11:04:04 CET] <furq> and also it all fucking sucks
[11:04:06 CET] <thebombzen> my point is that pirating it gets you significantly better quality
[11:04:46 CET] <Spring> trouble is bandwidth it would seem
[11:04:55 CET] <Spring> torrenters can share the load
[11:05:04 CET] <kerio> Spring: PLEASE
[11:05:10 CET] <furq> yeah you can't blame stream quality purely on "heh heh...we'll screw the paying customers"
[11:05:19 CET] <furq> streaming vs downloading is inherently different
[11:05:49 CET] <furq> plus you already have the perfect example of pure evil in the form of bluray
[11:06:08 CET] <kerio> why doesn't bluray use flac
[11:06:18 CET] <furq> dolby got to get paid, son
[11:06:27 CET] <Spring> is bandwidth not the reason crunchyroll lowered the quality recently?
[11:06:37 CET] <kerio> why doesn't bluray use Super Patented Lossless Audio Codec By Dolby Digital" then
[11:06:37 CET] <Spring> otherwise what else would they be doing it for
[11:06:41 CET] <furq> i mean i hope it was because of pure contempt for their audience
[11:06:44 CET] <furq> that's why i'd have done it
[11:06:57 CET] <furq> but sadly there is probably a solid technical argument for it
[11:07:07 CET] <kerio> "now introducing 6-bit h264"
[11:07:19 CET] <__jack__> 11:05:19 < furq> streaming vs downloading is inherently different | indeed, they are both made by people with very differents goals
[11:07:30 CET] <furq> kerio: it does
[11:07:40 CET] <furq> it supports DTS-MA
[11:07:41 CET] <kerio> oh, bluray audio is lossless? :o
[11:07:48 CET] <furq> well not usually, but it can be
[11:08:17 CET] <furq> there has to be an AC3 or DTS soundtrack for full compatibility, but a lot of disks have truehd or dtsma soundtracks as well
[11:08:26 CET] <furq> discs
[11:08:47 CET] <furq> you can also use lpcm if you're a crazy person
[11:09:11 CET] <furq> 8-channel 96/24 lpcm
[11:09:12 CET] <furq> yum
[11:10:26 CET] <kerio> i wish i had 96khz radiohead :<
[11:13:11 CET] <thebombzen> kerio: bluray does use flac
[11:13:46 CET] <furq> what
[11:14:36 CET] <tdr> it can
[11:14:39 CET] <thebombzen> ah nvm just several players
[11:14:42 CET] <thebombzen> it's "nonstandard"
[11:14:47 CET] <thebombzen> also
[11:14:52 CET] <thebombzen> why would you want 96 kHz audio
[11:15:06 CET] <thebombzen> 96 kHz is completley unnecessary if you're listening to it
[11:15:06 CET] <furq> so you can tell people about your 96khz audio on the internet
[11:15:20 CET] <thebombzen> but what do you do when someone points out the Nyquist-Shannon Sampling Theorem
[11:15:29 CET] <furq> you show them a screenshot of a sine wave in cool edit pro
[11:15:33 CET] <tdr> it can be raw pcm or it can be dolby compressed soup, those are whats usually used
[11:15:33 CET] <kerio> doesn't my dog have a right to proper audio
[11:15:44 CET] <furq> why would you make your dog listen to radiohead
[11:15:46 CET] <thebombzen> where 48 kHz is enough to construct a signal band-limited signal from 0 to 20 kHz
[11:15:49 CET] <thebombzen> you know
[11:15:53 CET] <kerio> thebombzen: 24
[11:16:11 CET] <thebombzen> well [0, 20) is a subinterval of [0, 24)
[11:16:13 CET] <thebombzen> so we good
[11:16:20 CET] <kerio> furq: why not
[11:16:20 CET] <thebombzen> 96 kHz is useful if you're doing editing tho
[11:16:23 CET] <thebombzen> like
[11:16:26 CET] <kerio> they're the greatest band
[11:16:30 CET] <thebombzen> if you're doing digital processing it can help the algorithms
[11:16:33 CET] <furq> counterpoint: they're not
[11:16:34 CET] <thebombzen> but just listening it's irrelevant
[11:16:45 CET] <thebombzen> radiohead is not the greatest band
[11:16:58 CET] <kerio> 1) you're all wrong
[11:17:12 CET] <kerio> 2) my lappy's sound card supports 96khz output
[11:17:20 CET] <kerio> for dem lappy speakers
[11:17:58 CET] <kerio> probably by just resampling everything to 48khz
[11:18:05 CET] <kerio> but i believe
[11:18:06 CET] <thebombzen> also furq if you're wondering why you need 8 Mbps for anime, it's because you can't watch haasn beat up a guy in blue tights in fullmotion without 8 Mbps
[11:18:08 CET] <furq> https://www.youtube.com/watch?v=LEdAkWOXcVM
[11:18:10 CET] <furq> this is the greatest band
[11:18:14 CET] <Nacht> Anyone here with some knowledge regarding AES and HLS (MPEG-TS) ?
[11:18:17 CET] <thebombzen> in particular you can't at 2 Mbps with -preset fast
[11:18:30 CET] <kerio> thebombzen: the only good anime is initial d
[11:18:40 CET] <kerio> it's all downhill from there
[11:18:44 CET] <thebombzen> like
[11:18:45 CET] <kerio> (ha see what i did there)
[11:18:45 CET] <thebombzen> http://0x0.st/tEX.mkv
[11:18:51 CET] <furq> i do see what you did there
[11:18:53 CET] <thebombzen> haasn needs his waifu
[11:18:58 CET] <thebombzen> at 8 Mbps
[11:19:30 CET] <kerio> thebombzen: ok i have to admit
[11:19:37 CET] <kerio> that is some fucking high quality chinese animation
[11:19:57 CET] <kerio> what's the crf
[11:20:15 CET] <Spring> p good quality
[11:20:27 CET] <thebombzen> this cause I just used a script which set -b:v to 7.5M
[11:20:32 CET] <thebombzen> if I used crf it'd be better
[11:20:36 CET] <furq> you said "it's all downhill from there", which is a joke about how initial d is an animes about young men using their cars to participate in "touge battles", a form of street racing where the cars drive down mountainous passes which is popular in japan, where "downhill" carries the double meaning of things becoming worse and also the way that the cars driven by initial d and his friends and rivals are
[11:20:42 CET] <furq> travelling
[11:20:48 CET] <furq> as such, it is a good joke
[11:20:51 CET] <furq> well done
[11:20:56 CET] <kerio> ty
[11:20:58 CET] <thebombzen> and kerio I don't think Ufotable is a chinese studio
[11:21:05 CET] <thebombzen> but they might have a chinese division
[11:21:13 CET] <thebombzen> Madhouse has a division in Korea
[11:25:56 CET] <Nacht> Anyone know how I can check if all packages of an TS files are 188bytes long with ffprobe ?
[11:36:08 CET] <termos> I'm doing avcodec_send_packet in one thread and avcodec_receive_frame in another, but since I can have any number of codec contexts on the receiving end how do I know which one to pick?
[11:36:56 CET] <BtbN> Nacht, if they weren't, it wouldn't be a .ts file.
[11:36:57 CET] <DHE> the AVCodecContext is something you allocate and provide (except in older versions of ffmpeg where you can use the one in the AVStream of the input).
[11:37:16 CET] <DHE> BtbN: sounds like the issue is, how do I check for corruption
[11:37:34 CET] <Nacht> BtbN: The thing is, once I create an HLS VOD with AES on it, the files aren't x188 long anymore
[11:37:48 CET] <BtbN> termos,  I'm pretty sure you can't multithread libavcodec like that.
[11:37:50 CET] <DHE> well that does happen because AES is a 16 byte block cipher
[11:37:53 CET] <termos> I have it allocated myself not using the one in AVStream, when I do send_packet I use the context corresponding to the input packet based on AVPacket.stream_index
[11:38:09 CET] <DHE> termos: that sounds right
[11:38:25 CET] <termos> I'm guessing on the receiving end I need to loop through all my input streams and try to pull from each of the codec contexts?
[11:39:11 CET] <DHE> I agree with BtbN here. libavcodec is likely not thread-safe when the same context is used in multiple threads without any locking on your end
[11:40:16 CET] <Nacht> The thing is, we're trying out HLS AES for an Android Unity player, but it isn't working. They claim it's due to the packages not being 188bytes long. I just can't think up a way to check this. Since every TS package inspector I can find can't work with AES. FFprobe can, but I'm not sure where to find the value I need
[11:40:18 CET] <termos> ah yes I have a mutex around all usage of the codec context
[11:41:07 CET] <DHE> Nacht: then your player is broken. it's a requirement of AES that every file be a multiple of 16 bytes. even openssl enc will pad files
[11:42:57 CET] <Nacht> DHE: Cheers mate, I can work with that.
[11:52:54 CET] <termos> looping through all the codec context and trying to pull from each of them seems to be the way to go
[12:00:37 CET] <thebombzen> out of curiosity, have there been any subjective comparisons between hevc_nvenc and x264?
[12:01:06 CET] <furq> i'm pretty sure people in here have said x264 is a lot better
[12:11:35 CET] <thebombzen> so I just did some testing and x264 is indeed better at the slower presets like -preset slow
[12:11:43 CET] <thebombzen> but at faster presets nvenc wins
[12:12:37 CET] <kerio> i shall stream with -preset placebo
[12:13:04 CET] <thebombzen> I'm sure your viewers will love the 16 bframes
[12:18:21 CET] <thebombzen> furq: by the way I was comparing x264 10bit to hevc_nvenc 10bit
[12:18:26 CET] <thebombzen> this was also 1080p
[12:18:40 CET] <thebombzen> and itappeared that at the fast presets x264 lost its edge
[12:18:54 CET] <thebombzen> but it might also lose it for huge videos like 4k
[12:19:50 CET] <nolaan> Hi, I'm trying to build ffmpeg 3.2.4, for some reason using --enable-omx doesn't result in CONFIG_OMX 1
[12:19:53 CET] <nolaan> Why?
[12:28:32 CET] <BtbN> Does 3.2 even support omx?
[12:29:41 CET] <furq> yeah
[12:30:20 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/release/3.2/configure#L309
[12:30:58 CET] <furq> nolaan: some options are silently ignored if the headers/libs aren't found
[12:31:06 CET] <furq> idk if omx is one of those but you might want to check config.log
[12:32:46 CET] <nolaan> furq: I checked config.log and it was disabled (CONFIG_OMX 0) even though --enable-omx is specified
[12:32:48 CET] <nolaan> :/
[12:33:36 CET] <nolaan> what are the headers it's looking for?
[12:33:45 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/release/3.2/configure#L5829-L5833
[12:33:48 CET] <furq> nvm i guess that's not it
[12:35:09 CET] <nolaan> furq: for the record I have a ffmpeg 3 compiled with omx support
[12:35:25 CET] <mcjack> Hi everybody, where do I set the color_range?
[12:35:38 CET] <mcjack> the h264 encoder complains: [h264_videotoolbox @ 0x103a17400] Color range not set for yuv420p. Using MPEG range.
[12:36:07 CET] <mcjack> I tried: videoContext->color_range = AVCOL_RANGE_JPEG;
[12:36:18 CET] <mcjack> that didn't change anything
[12:36:43 CET] <mcjack> the result is a black video&
[12:40:09 CET] <mcjack> I basically follow the encoding_decoding.c example
[12:41:40 CET] <mcjack> you can see the code for setup here: https://github.com/filmstro/filmstro_ffmpeg/blob/master/modules/filmstro_ffmpeg/filmstro_ffmpeg_FFmpegVideoWriter.cpp#L186
[12:49:17 CET] <mcjack> ok, I found av_frame_set_color_range(), that fixes the warning, but the video is still black&
[12:50:11 CET] <mcjack> Also can I somehow deduce the desired color_range from the format? I don't want to hardcode the color_range&
[13:08:55 CET] <mcjack> Hi Mavrik, matkatmusic copied me your conversation from this morning, thanks for the suggestions
[13:10:14 CET] <mcjack> I use av_image_alloc() like in the example encoding_decoding, and I get three pointers pointing to '\0', the other 5 NULL, sooms correct?
[13:10:27 CET] <mcjack> seems
[13:14:12 CET] <nolaan> furq: In the context of cross compilation this might be an issue (at least for me ;) ) https://github.com/FFmpeg/FFmpeg/blob/release/3.2/libavcodec/omx.c#L144
[13:14:36 CET] <nolaan> I'm trying configure then I may open an issue
[13:22:15 CET] <nolaan> nope
[13:22:25 CET] <nolaan> still not able to cross compile omx
[13:30:54 CET] <nolaan> meh, you said it : https://github.com/FFmpeg/FFmpeg/blob/release/3.2/configure#L5829-L5833
[13:31:07 CET] <nolaan> ! enabled cross_compile
[13:32:31 CET] <furq> that just disables adding the rpi header path if you're cross-compiling
[13:32:57 CET] <furq> you can definitely cross-compile omx-rpi
[13:45:31 CET] <nolaan> I'm trying :D
[13:51:48 CET] <momomo> anyone have any idea as to why hls is no longer playing on ios >= 10 iphones? used to work on my 4s
[13:51:54 CET] <momomo> but not on 6 and 7
[13:58:18 CET] <momomo> on this site, i found this info: H.264 Baseline 3.0: All devices
[13:58:48 CET] <momomo> my command basically looks like this:
[13:58:53 CET] <momomo>  /momomo/Other/Software/ffmpeg/ffmpeg-git-20160403-64bit-static/ffmpeg -re -i /momomo/Resources/Tv/Streams/Local/a -vf scale=floor(iw*min(1\,min(1024/iw\,768/ih))/2+0.4999999)*2:-2 -map 0:a:0 -map 0:v:0 -preset veryfast -x264-params scenecut=0 -crf 24 -g 125 -r 25 -x264opts keyint_min=125 -c:v libx264 -c:a aac -ac 2 -b:a 128k -f hls -hls_list_size 5 -hls_time 5 -sn /momomo/Generated/Tv/streams/2202367692__Locala/a
[14:15:00 CET] <ZeroWalker> does rtp work with multiple streams? (audio + video)?
[14:53:46 CET] <nolaan> ZeroWalker: normally yes
[14:54:53 CET] <momomo> nolaan: anyone know why hls is no longer wokring in iios ?
[14:54:59 CET] <momomo> >= 9.35
[14:57:04 CET] <nolaan> momomo: nope sorry
[15:00:10 CET] <Nacht> momomo: No idea why it's not working. Just a question though, why a GOP of 125 ?
[15:02:29 CET] <momomo> Nacht: i dont' remember .. i think it was to get a reliable ts length in seconds ... not sure though
[15:02:46 CET] <momomo> Nacht: is that expensive / not good?
[15:03:33 CET] <momomo> "consistent" .. maybe it was the file size .. not sure ... i don't think it's neccessary anymore
[15:03:39 CET] <momomo> should I remove it?
[15:16:25 CET] <Nacht> 125 is quite allot, means you have 5 seconds of P or B frames. Where the default is 1 second
[15:16:52 CET] <Nacht> One fault slipping in, and you get lots of artifacts
[15:18:14 CET] <furq> the default for x264 is 250
[15:18:16 CET] <alexpigment> Nacht: to be fair, i think ffmpeg defaults to 250 keyint these days
[15:18:19 CET] <alexpigment> yeah
[15:18:33 CET] <alexpigment> but i agree that 250 (or 125) is dumb
[15:18:45 CET] <alexpigment> i usually do keyint = framerate
[15:18:54 CET] <Nacht> Aye, same here
[15:18:56 CET] <furq> you definitely don't want 1-second gops for hls because every segment is a new request
[15:19:14 CET] <furq> five seconds is probably about right
[15:19:24 CET] <furq> and there's not much point having keyframes within segments
[15:19:42 CET] <Nacht> Means he has 5 I frames per fragment.
[15:19:45 CET] <alexpigment> (oh i see this is related to HLS from an earlier convo - i'll defer to furq's expertise here
[15:20:17 CET] <Nacht> You have a point there Furq
[15:20:36 CET] <furq> i don't really see the problem with 10-second gops in general
[15:20:39 CET] <Nacht> The 125 does make sense then. One 1 frame per segment
[15:20:47 CET] <furq> or whatever 250 frames works out to
[15:21:21 CET] <furq> it makes accurate seeking slightly more annoying but it's not often i care about that sort of precision
[15:21:40 CET] <furq> and if your input is defective then you've got bigger issues than gop size
[15:22:13 CET] <Nacht> Shouldn't it be 2 I-frames per segment tho ? With a 125 GOP and 5 sec fragments, he will only have 1 per segment
[15:22:31 CET] <furq> why would you need two
[15:22:52 CET] <Nacht> I recall reading that regarding HLS
[15:23:02 CET] <Nacht> It's not requires, but adviced
[15:23:06 CET] <Nacht> *d
[15:23:32 CET] <furq> https://developer.apple.com/library/content/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745-CH1-MEDIASTREAMSEGMENTATION-USE_AT_LEAST_ONE_IDR_FRAME_PER_SEGMENT__PREFERABLY_AT_THE_START_
[15:23:53 CET] <furq> i'm not sure why it says "we recommend at least one" because i don't think it'll work without that
[15:24:20 CET] <furq> i'm fairly sure ffmpeg won't let you do that
[15:25:23 CET] <furq> oh, -hls_flags split_by_time
[15:25:28 CET] <furq> so it's fairly well buried at least
[15:27:36 CET] <alexpigment> momomo: did you see this article? https://flowplayer.org/forum/#!/flowplayer/setup:hls-not-longer-works-with-i
[15:28:41 CET] <alexpigment> according to the last post, it was fixed in iOS on 2016-10-21 . presumably you're on the latest version of iOS?
[15:29:00 CET] <alexpigment> typo; fixed on 2016-12-21
[15:29:07 CET] <momomo> alexpigment: no, i don't know .. i am on 9.3.5
[15:29:17 CET] <momomo> in 4s it is the latest
[15:29:21 CET] <momomo> i don't have an iphone
[15:29:24 CET] <alexpigment> momomo: as a 5s owner, i envy you
[15:29:24 CET] <momomo> iphone 6
[15:29:28 CET] <momomo> hehe
[15:29:31 CET] <momomo> can you try?
[15:29:40 CET] <momomo> i will send you a private pm
[15:30:01 CET] <alexpigment> lemme make sure *I'm* on the latest iOS first
[15:31:47 CET] <momomo> alexpigment: i thought you said they fixed it on the latest version
[15:31:59 CET] <momomo> or they broke it again?
[15:33:02 CET] <momomo> furq: i missed gthe conversation about GOP's ... the conclusion was that I should keep or change something?
[15:33:11 CET] <furq> what you have is fine
[15:33:53 CET] <Nacht> What furq says
[15:37:15 CET] <momomo> lol :)
[15:38:58 CET] <DHE> it's not a bad setting, it just seems odd since it's not, shall we say, an obviously clean number of seconds.
[15:39:22 CET] <DHE> oh, actually you set 25fps so it does kinda work
[15:40:35 CET] <Nacht> Yeah, only note worty is that even apple advices an fragment size of 6 sec, as specified in that link furq gave
[15:42:04 CET] <Nacht> Altho, I did read an article by bitmovin.com where they advice chunks of 2-4 seconds now-a-days
[15:42:08 CET] <Nacht> https://bitmovin.com/mpeg-dash-hls-segment-length/
[15:45:34 CET] <momomo> Nacht: i use 5s
[15:45:56 CET] <momomo> i think that's the minimum on ffmpeg
[15:46:22 CET] <furq> it isn't
[15:47:19 CET] <furq> but five is fine and it's not the problem anyway
[15:53:01 CET] <momomo> on ios devices > 9.3.5 ...  only the first playlist is ever served .. once it's served .. no requests for a ts file is made ... it fails on reception... maybe it's parsing it incorrectly .. maybe its responded with the wrong headers ... not containing new required hls tags? any ideas on the hls specifiation require,ments ?
[16:45:39 CET] <momomo> I was able to play this playlist ( Apple ) : <video src="http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8" />
[16:45:56 CET] <momomo> so it's wierd ... here is a comparison between theirs and my ffmpeg generated one
[16:46:00 CET] <momomo> https://hastebin.com/ipatucexog.http
[16:46:47 CET] <momomo> when i play mine in ios mobile browser .. the request for the playlist is made and i serve the playlist, but then an error occurs ... no request is every made for a ts segment file .. so it cant be the ts file format or encoding issues
[16:46:51 CET] <momomo> it's related to the playlist file
[16:47:03 CET] <momomo> i think the specification must have changed
[16:47:59 CET] <Nacht> 2nd one is a VOD, so you only request the manifest once
[16:49:14 CET] <benlieb> Im trying to reduce some file sizes of some audio that I use for music practice (doesnt need to be amazing quality). Currently Ive compressed the stereo into mono which helped a bit but wondering how to further reduce this: Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 96 kb/s (default)
[16:49:55 CET] <benlieb> can I affect the 44100 or 96 kb/s directly?
[16:50:08 CET] <benlieb> not sure what those correspond to.
[16:50:13 CET] <benlieb> ie, not an expert here
[16:50:19 CET] <alexpigment> ok so you don't need 96kbps
[16:50:34 CET] <DHE> -b:a 96k   # audio bitrate
[16:50:56 CET] <alexpigment> audio bitrates are specified as the total bitrate for all channels, so reducing to mono doesn't change the bitrate
[16:51:23 CET] <alexpigment> so if you change 48kbps, it'll have the size of the audio
[16:51:34 CET] <alexpigment> and be the equivalent quality of a stereo 96kbps stream
[16:52:24 CET] <Nacht> the 44100 is your sampling rate. (44.1 kHz)
[16:53:39 CET] <Nacht> Some more info regarding them: http://wiki.audacityteam.org/wiki/Sample_Rates#rate
[16:53:43 CET] <benlieb> looking a little more I found -ar 22050. This reduced the file size by half. Is this a good way to do what Im trying to do?
[16:54:03 CET] <alexpigment> i don't recommend going to 22khz unless you just don't care about quality
[16:54:14 CET] <benlieb> could you clarify the difference between sample rate and bit rate?
[16:54:16 CET] <kepstin> try reducing the bitrate of the 44.1kHz file first
[16:54:20 CET] <alexpigment> 32khz is somewhat transparent, but 44.1khz is CD quality
[16:54:34 CET] <alexpigment> yeah, just go to 48kbps if you're going to be in mono
[16:55:57 CET] <benlieb> alexpigment: how would I do that exacly?
[16:56:08 CET] <benlieb> -b:a 48k ?
[16:56:30 CET] <alexpigment> -c:a aac -ar 44100 -b:a 48000 -ac 1
[16:56:35 CET] <mcjack> benlieb: samplerate is the decoded rate vs. bitrate is the encoded rate
[16:56:42 CET] <furq> what are you playing this back with
[16:56:48 CET] <furq> if it's something that supports opus then you should use that
[16:57:01 CET] <alexpigment> furq: HE-AAC is probably a safer bet than OPUS
[16:57:11 CET] <furq> for compatibility, sure
[16:57:16 CET] <furq> except the ffmpeg aac encoder doesn't support it
[16:57:24 CET] <benlieb> furq: Im just playing it on any audio player. I have these on different devices and just use it to practice playing against different chord progressions
[16:57:29 CET] <alexpigment> oh right. that's just fdk i guess
[16:57:32 CET] <benlieb> exporting via iReal Pro
[16:58:04 CET] <furq> if you're on *nix then you could maybe install the standalone fdk encoder
[16:58:13 CET] <furq> he-aac is much better at low bitrates
[16:58:24 CET] <benlieb> furq: on mac
[16:58:26 CET] <furq> opus is still better but that's no good if you can't play it back
[16:58:32 CET] <alexpigment> he-aac is usually 48kbps in my experience, except you get stereo and it sounds like true 44.1
[16:59:24 CET] <benlieb> thanks for the input everyone. I have my audio down to about 40% of the orig and that is a good start.
[16:59:33 CET] <furq> fdk is in homebrew if you have that
[16:59:59 CET] <furq> although if you have homebrew then you could potentially just rebuild ffmpeg with fdk
[17:05:55 CET] <delicado> hi, are we allowed to package all the libraries into one binary? If so, how should I call it?... In ffmpeg license, it says here: "Do not rename FFmpeg dlls to some obfuscated name, but adding a suffix or prefix is fine (renaming "avcodec.dll" to "MyProgDec.dll" is not fine, but to "avcodec-MyProg.dll" is)." - so is it okay to rename the library as ffmpeg-codec.dll because it includes all those
[17:05:55 CET] <delicado> separate libraries into one dll?
[17:08:05 CET] <nido> [1;2Hffmpeg-libavcodec_libavdevice_libavfilter_libavformat_libavresample_libavutil_libpostproc_libswresample_libswscale.dll  :)
[17:08:26 CET] <kepstin> ask a lawyer? But you're not hiding the fact that they're ffmpeg libraries, so.. :/
[17:09:13 CET] <Mavrik> delicado, you can always statically link
[17:09:20 CET] <Mavrik> of course if you obey the licesnes
[17:09:59 CET] <kepstin> (I don't think there's any support in the ffmpeg build system for building all the libraries into a single shared object, so if you do that, make sure you make available the modified source...)
[17:12:27 CET] <delicado> yes I woudn't hide that it is using the ffmpeg library. I just don't know why everytime i try to build the ffmpeg source code, it builds one big static library that includes all the ffmpeg modules.. So, I just let it and build it into a dll along with a wrapper..
[17:19:44 CET] <thebombzen> I mostly use opus for high bitrate stuff (like 128k) but how does it compare to he-aac at low bitrates
[17:20:18 CET] <thebombzen> libopus outperforms everything else (including quicktime) at high bitrates
[17:22:13 CET] <kepstin> thebombzen: only comparison I can find is 64kbit stereo, where opus was slightly better than he-aac. http://listening-tests.hydrogenaud.io/igorc/results.html
[17:26:12 CET] <thebombzen> also
[17:26:18 CET] <furq> opus is designed to work well across the whole range
[17:26:18 CET] <thebombzen> if I want to patch my own local copy of ffmpeg
[17:26:38 CET] <thebombzen> is there is a way to do this and still allow me to update the repo via git pull
[17:26:39 CET] <furq> whereas aac had to have that retrofitted with stuff like he
[17:26:42 CET] <thebombzen> ah
[17:27:05 CET] <thebombzen> I want to patch an annoyance but I don't want to have to deal with git stuff
[17:27:07 CET] <furq> not that you can brag about opus' compatibility, but at least you know that every opus file will work on something that supports opus
[17:27:11 CET] <kepstin> thebombzen: just commit your patches, then use "git pull --rebase" to update from git
[17:27:17 CET] <furq> which is more than can be said for aac
[17:27:37 CET] <thebombzen> kepstin: do I need to use git pull --rebase once, or every time I git pull?
[17:27:50 CET] <kepstin> every time you pull, otherwise it'll merge on top of your patch
[17:28:01 CET] <kepstin> alternative: use 'git stash; git pull; git stash apply'
[17:28:26 CET] <furq> what are you patching
[17:28:55 CET] <thebombzen> I want to change nut's default video and audio to ffv1/flac
[17:28:58 CET] <thebombzen> rather than mpeg4
[17:29:10 CET] <furq> oh
[17:29:16 CET] <furq> i guess that's not the kind of thing that'd be accepted upstream
[17:29:24 CET] <furq> mostly because it should obviously be rawvideo/pcm_s16le
[17:32:12 CET] <thebombzen> yea I know that they'd reject it upstream
[17:32:24 CET] <thebombzen> speaking of pcm_s16le
[17:32:30 CET] <thebombzen> why isn't there just one codec
[17:32:32 CET] <thebombzen> rawaudio
[17:32:38 CET] <thebombzen> instead of one for each sample format
[17:32:46 CET] <thebombzen> we don't have a different video codec for each pixel format
[17:32:56 CET] <furq> probably the same reason as the last time you asked this
[17:34:57 CET] <momomo> CAN SOMEONE PLEASE **** TELL ME WHAT THE DIFFERENCE IS BETWEEN THESE TWO PLAYLISTS ARE? BOTH ARE SERVED FROM MY SERVED, THE LOWER ONE TAKEN FROM APPLES M3U8 FILE. IVE MODIFIED IT AND SERVED IT FROM MY SERVER. THE LOWER ONE WORKS, THE UPPER ONE DOESN"T.
[17:35:02 CET] <momomo> https://hastebin.com/qoroqukuye.css
[17:35:58 CET] <momomo> it both cases the m3u8 is served .. but for the above one no ts file is asked for. for the lower one ... it works and the player plays ...
[17:36:17 CET] <furq> er
[17:36:26 CET] <furq> EXT-X-TARGETDURATION should be 5 in the upper one
[17:36:33 CET] <kepstin> momomo: why did you set the target duration to 1 second in the top one?
[17:36:40 CET] <furq> i assume ffmpeg did that
[17:37:41 CET] <kepstin> hmm. but the segments are still listed as 5s, my impression is that ffmpeg uses the min of the segment lengths as target duration?
[17:38:02 CET] <momomo> kepstin: because that has worked prioerly to have dynamic target duration
[17:38:06 CET] <momomo> i just discovered it too
[17:38:11 CET] <momomo> changing to 5 worked
[17:38:29 CET] <momomo> the target duration if modified will tell the player when to request the next m3u8
[17:39:00 CET] <momomo> so I dynamically detect the file on the server and tell the playlist when the next one will be available
[17:39:22 CET] <momomo> seems apple stopped supporting that
[17:40:03 CET] <momomo> values of 3 works
[17:40:07 CET] <momomo> but not lower, 2 or 1
[17:40:10 CET] <momomo> strange
[17:40:23 CET] <furq> that's dumb that they'd break that but it is part of the spec
[17:40:25 CET] <kepstin> huh, according to the spec, the targetduration is supposed to be set to the "maximum media segment duration"
[17:40:29 CET] <furq> yeah
[17:40:44 CET] <kepstin> so having it shorter than all the segments could cause issues, i guess :/
[17:41:09 CET] <furq> it's really dumb that "issues" would include the stream not playing at all
[17:41:11 CET] <kepstin> they say "[having segments longer than target duration] longer segments can trigger playback stalls or other errors"
[17:41:17 CET] <furq> thanks, apple
[17:41:18 CET] <furq> thapple
[17:41:29 CET] <kepstin> so "playback stalls or other errors" allows it not playing at all.
[17:41:37 CET] <momomo> yeah, 1, 1, 1 worked
[17:41:41 CET] <furq> i'm not saying it's outside the spec for it to break
[17:41:45 CET] <momomo> however, 3, 5, 5 also worked
[17:41:47 CET] <furq> just that it's really dumb that that would happen
[17:41:51 CET] <furq> especially if 3 works
[17:42:22 CET] <kepstin> i guess this player just has issues if the difference between the target duration and the segment durations is too big, maybe?
[17:42:34 CET] <thebombzen> kepstin: do I need git pull --rebase each time
[17:42:40 CET] <thebombzen> or is one successful pull enough
[17:42:45 CET] <furq> you need to rebase every time
[17:42:52 CET] <kepstin> thebombzen: I already answered that
[17:42:54 CET] <furq> 16:27:50 ( kepstin) every time you pull, otherwise it'll merge on top of your patch
[17:42:57 CET] <furq> 16:28:01 ( kepstin) alternative: use 'git stash; git pull; git stash apply'
[17:43:04 CET] <momomo> the thing is that when a the player requests the first playlist ... i serve the last - 2 playlist .. in order to stay ahead of the buffer ... and to control the buffer ... so the next playlist is available immediately .. i normally set that to 1 .. prior, apple would fetch that next one at 1
[17:43:07 CET] <thebombzen> ohw elloka
[17:43:10 CET] <thebombzen> oh well okay
[17:43:11 CET] <momomo> i even tweaked hls.js to do that too
[17:43:12 CET] <thebombzen> can't read
[17:43:20 CET] <momomo> because that provided a better playing experience
[17:43:22 CET] <furq> you'd think a too short target duration would just cause the player to make a bunch of redundant requests
[17:43:35 CET] <furq> maybe it just dies if it makes two requests and the playlist hasn't updated
[17:43:36 CET] <momomo> furq: not if the answer is with a new playlist
[17:43:40 CET] <furq> which would explain why 3 works
[17:43:52 CET] <momomo> furq: no, only one request is ever made
[17:43:56 CET] <furq> oh
[17:43:57 CET] <momomo> for the first playlis
[17:43:58 CET] <momomo> t
[17:44:15 CET] <furq> it must actually be checking targetduration against extinfs then
[17:44:19 CET] <momomo> just so stupid that the have an if block < 3 .. break
[17:44:20 CET] <furq> which is incredibly stupid
[17:45:46 CET] <kepstin> well, they warn that setting targetduration too short can cause playback stalls, and that's... apparently what it does :/
[17:45:55 CET] <furq> it causes a stall that lasts forever
[17:45:57 CET] <momomo> yes, it wasn't like this in previous versions eitehr ... i guess now my ios users will be supplied an old playlist .. but start the download of the next avaialble segment file 2 seconds too late .. which would ruin the experience for slow connected users
[17:46:14 CET] <momomo> kepstin: it doesnt do that .. no stalls occur
[17:46:21 CET] <momomo> an error is thrown when reading hte playlist
[17:46:41 CET] <furq> if i was being generous i could call that a stall
[17:46:51 CET] <momomo> if target duration has to be set to 5 .. then how can one control when to load the next segment file ... if one do not want to wait 5 full seconds?
[17:46:57 CET] <furq> but this is iOS safari so i'm absolutely not going to be generous
[17:47:19 CET] <thebombzen> also does anyone know why mpeg4 is the default for nut?
[17:47:31 CET] <kepstin> momomo: the player is supposed to start downloading the next segment based on its estimation of when it'll be needed, that's not really something you control...
[17:47:34 CET] <furq> probably because it's a builtin encoder
[17:47:41 CET] <furq> that question might be better suited to #ffmpeg-devel
[17:47:47 CET] <thebombzen> furq: but for audio it checks for libvorbis's existence
[17:47:47 CET] <kepstin> if the segment lengths are set right, it should know when it'll need the next file :/
[17:47:52 CET] <thebombzen> and defaults to libvorbis if it'st here
[17:48:00 CET] <furq> ok that's just completely stupid then
[17:48:24 CET] <thebombzen> maybe because x264 is gpled
[17:48:27 CET] <thebombzen> but still
[17:48:33 CET] <thebombzen> the "existence" thing should deal with that
[17:48:35 CET] <momomo> kepstin: if i decide that my player should start N back, and not close to the live edge ... then I should be able to tell player that next segment file is already available
[17:48:43 CET] <momomo> maybe there is a tag for that
[17:49:00 CET] <furq> surely if the next segment is available then it's already in the playlist
[17:49:34 CET] <kepstin> so your problem is that the player isn't starting with the first segment in the playlist, but it rather skipping forwards to the latest one?
[17:49:40 CET] <momomo> exactly
[17:50:06 CET] <momomo> at least hls.js is hard to control without this dymanic target duration ... i have total control of it now .. which is ideal
[17:50:11 CET] <momomo> with ios i no longer do
[17:50:27 CET] <DHE> you need EXT-X-ENDLIST or EXT-X-PLAYLIST-TYPE to make it play from the beginning
[17:50:45 CET] <DHE> without them it's assumed to be a live stream and players will play from near the end.
[17:51:02 CET] <DHE> (ie. the most recent and most live)
[17:51:06 CET] <momomo> kepstin: i don't want to start the begining ... but on N - 2 from live edge ..
[17:51:15 CET] <kepstin> it sounds like they might have changed this on purpose in the ios player so that they control the buffers rather than have tricks played by against-spec servers :/
[17:51:57 CET] <momomo> anyhow .. i can probably figure out a way to beat it
[17:52:31 CET] <momomo> i basically only tweak he playlist on the first requests ... then it gets back to 4 or 5 seconds ... which seemed to be fine
[17:52:50 CET] <DHE> I don't think you, as the server owner, can force playback from any particular segment safely. maybe faking an EVENT?
[17:52:56 CET] <kepstin> i'd expect it to work fine if the first playlist includes all the files except the last, the later playlists include all the files, and the segment durations are set correctly.
[17:53:05 CET] <momomo> DHE: I will look into those tags
[17:53:10 CET] <kepstin> i.e. the second request adds two files to the end
[17:53:12 CET] <momomo> have to go... thanks
[17:53:14 CET] <kepstin> instead of just one
[17:53:23 CET] <momomo> kepstin: yes
[17:53:25 CET] <momomo> thank too
[17:53:27 CET] <momomo> that too
[17:53:54 CET] <momomo> at least i figured out why today :S
[17:54:26 CET] <DHE> yeah, all you can do is direct users to play "From the start" and "From near the end (intentionally vague)"
[17:55:31 CET] <momomo> DHE: which tag is that specifically?
[17:55:34 CET] <kepstin> hls is designed to be player-controlled, since presumably the player knows better than the server how much buffer ram it has, how fast its connection is. ANd it can be served from "dumb" http-only servers of course...
[17:56:16 CET] <momomo> kepstin: that's stupid because the only thing the server can control is itself, not all the various players out there
[17:56:52 CET] <DHE> momomo: with EXT-X-ENDLIST you're not allowed to modify the list, but the client will start from the beginning. with EXT-X-PLAYLIST-TYPE:EVENT you're only allowed to append to the list but it can grow and the player should start from the top (if I understand correctly)
[17:57:21 CET] <kepstin> momomo: huh, looks like you might be able to do what you want with https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-4.3.3.4
[17:57:26 CET] <kepstin> EXT-X-START
[17:57:27 CET] <momomo> DHE: yes, i htink ENDLIST is for static m3u8's
[17:57:29 CET] <kepstin> er, wrong link
[17:57:33 CET] <momomo> not live content
[17:57:47 CET] <kepstin> https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-4.3.5.2 - works on non-live streams
[17:58:03 CET] <kepstin> but it's just a "preferred point", and players can (and will) ignore it
[17:59:06 CET] <momomo> kepstin: does it say it doesn't work on live streams?
[17:59:41 CET] <kepstin> momomo: no, it just says that on a non-live stream you shouldn't start within 3 target durations of the last file in the playlist.
[17:59:55 CET] <momomo> ook great, it must be the tag i am after :)
[18:00:52 CET] <kepstin> with your playlist with a target duration of 5, you can probably just set it to "-15" as a hint to the player that you want it to buffer 3 segments.
[18:00:56 CET] <momomo> however, i have to say dynamic target duration is still very good .. many times the player won't do the requests at the price time ... so if a file is served too late, it will still probably make the request 5 seconds later ... rather if tweaked you would almost always be spot on
[18:02:03 CET] <kepstin> if you set the length of each segment in the playlist to the exact length of the segment file, i'd expect that to work fine...
[18:03:35 CET] <momomo> kepstin: ffmpeg does that .. but playback issues do still occur .. also .. not sure how it works, but say if a ts file is served precisely when it is created, but takes 3 secondsd for the user to recieve for some temporary reason, the player will start to play it ... not sure if it subratacs 3 seconds from the asking of the next playlist
[18:04:00 CET] <momomo> i think hls.js still waited 5 seconds
[18:04:07 CET] <kepstin> momomo: the player is supposed to make the next playlist request when it decides it needs to find the next segment. that's up to the player :/
[18:05:48 CET] <kepstin> hmm, the hls spec does actually say some stuff about playlist reloading
[18:06:29 CET] <kepstin> wait at least target duration between reloads, and if the playlist hasn't updated, try again after ½ target duration
[18:07:56 CET] <kepstin> huh, "If the EXT-X-ENDLIST tag is not present and the client intends to play the media normally, the client SHOULD NOT choose a segment which starts less than three target  durations from the end of the Playlist file.  Doing so can trigger playback stalls."
[18:08:03 CET] <kepstin> is the ios player ignoring that? :/
[18:08:24 CET] <meldron> hey guys can somebody explain me the difference between x264 videos with avc1 and avc3 and how I can transcode them with ffmpeg? (has -preset veryfast something to do with it?)
[18:11:24 CET] <alexpigment> meldron: where are you seeing avc3?
[18:12:08 CET] <kepstin> meldron: it looks like https://lists.freedesktop.org/archives/gstreamer-bugs/2013-June/104266.html has a decent description of what avc1 vs avc3 does - it's a difference in the mp4 muxing, not in the actual video encoding.
[18:12:59 CET] <kepstin> I have no idea which format ffmpeg outputs, someone with better knowledge of mp4 would have to answer that :)
[18:13:17 CET] <kepstin> but probably avc1, at least by default
[18:13:46 CET] <alexpigment> it sounds like we need more information about why meldron is forced to know the difference and why he needs to transcode
[18:14:18 CET] <alexpigment> but if avc3 is causing a problem, i suspect that a -c:v copy -c:a copy would do the trick
[18:38:32 CET] <meldron> I transcode several videos with ffmpeg afterwards I have to concat them into a single video
[18:38:44 CET] <meldron> for the first step i am using ffmpeg and for the second mp4box
[18:43:00 CET] <meldron> I thought that i encode all videos with 'ffmpeg -y -i {} -c:v libx264 -r 25 -pix_fmt yuv420p -level:v 4.1 -strict -2' i should be able to concat them without problems
[18:45:24 CET] <kuroro> does anyone know android here?
[18:46:33 CET] <kuroro> using static ffmpeg binary to do a concat of short mp4s and its currently very slow
[18:46:57 CET] <kuroro> in android devices
[18:47:54 CET] <kuroro> looking for faster alternative (i.e MediaCodec, MediaMuxer, or libffmpeg in-memory transcoding)
[18:48:31 CET] <alexpigment> meldron: is that your entire command line?
[18:48:51 CET] <BtbN> sounds like you forgot -c copy?
[18:49:26 CET] <meldron> alexpigment: i left out the image overlay
[18:49:44 CET] <meldron> but basically yeas
[18:49:55 CET] <alexpigment> you mentioned -strict -2, which is required for AAC audio in older builds, but you didn't specify any other audio parameters
[18:49:58 CET] <furq> do you nede to encode them separately
[18:50:00 CET] <furq> need
[18:52:32 CET] <alexpigment> i suspect furq is implying that concat with MP4box is unnecessary if you're going to re-encode with ffmpeg in the first place
[18:53:37 CET] <sectroyer> I have a questions. Does reimar still appear here?
[18:56:07 CET] <furq> meldron: if you do need to encode them separately then use mpegts or some format which is better at that than mp4
[18:56:18 CET] <furq> but otherwise, you can do it all with ffmpeg
[18:56:24 CET] <furq> either by using the concat demuxer or the concat filter
[18:56:37 CET] <furq> the filter is better but more annoying to automate
[19:01:36 CET] <momomo> kepstin: the thing is that the target duration info is kind of useless to even provide.. as each segment length is already specified. the entire point of the target duration must be to forgo the actual length of the ts file being played and use target duration to load the next one... the player need not the target duration to determine that other than have the actual lengths of each ts file ... which it does .. so what is the intent of target duration if
[19:01:36 CET] <momomo> not to be dynamically modified?
[19:05:12 CET] <meldron> furq: so i have a multi step approach, in the first step i create all the video parts and in the second they will be concatnated but not all of them everytime
[19:05:28 CET] <meldron> alexpigment: ah thanks, some artifcates I forgot what the were about
[19:06:00 CET] <alexpigment> meldron: the other thing i was going to mention is that you haven't specified any quality options - like -crf or -b:v - i presume you're OK with the default quality?
[19:06:21 CET] <furq> momomo: https://developer.apple.com/library/content/technotes/tn2235/_index.html#//apple_ref/doc/uid/DTS40010221-CH1-ERRORS_AND_WARNINGS_EXPLAINED
[19:06:41 CET] <furq> WARNING: INF tag with duration 2 seconds or more above the playlist's target duration (10.000 seconds)
[19:06:45 CET] <furq> i guess that explains it
[19:06:57 CET] <furq> they're obviously forcing that in the player now
[19:07:07 CET] <furq> i'm still yet to find a decent explanation for why, though
[19:08:32 CET] <furq> i guess users are more likely to blame choppy playback on apple/safari, but a straight error will be blamed on the stream operator
[19:09:03 CET] <meldron> alexpigment: I also tried preset veryfast, but may be i have to do some fine tuning there, do you have any suggestions?
[19:09:40 CET] <furq> meldron: if you have a good reason to concat them separately then you should definitely use something like mpegts as an intermediate container
[19:10:14 CET] <meldron> furq: ah okay, can you point me to some info about mpegts?
[19:10:31 CET] <furq> https://en.wikipedia.org/wiki/MPEG_transport_stream
[19:10:35 CET] <furq> just replace .mp4 with .ts
[19:10:52 CET] <furq> it's designed for streaming, so it's much less hassle for concatenating
[19:12:19 CET] <momomo> furq: i have below though, not above
[19:12:40 CET] <furq> that warning is for EXTINF > EXT-X-TARGETDURATION
[19:12:47 CET] <momomo> ooh, ok
[19:13:17 CET] <furq> that tool looks potentially useful but i have no idea if it works on anything but osx
[19:13:46 CET] <momomo> it's stupid, because my tweaking of hls.js to use a dynamic target duration ( it uses a fixed and will ignore any values besides the first ) has led to much greater reliability
[19:14:57 CET] <ZeroWalker> isn't there any point to point streaming for video and audio together?
[19:16:55 CET] <meldron> thx alot
[19:17:02 CET] <meldron> everybodt
[19:22:15 CET] <meldron> furq: but then i will to have reencode during concat?
[19:55:36 CET] <Dresk|Dev> I've Googled and oogled and oh so much, why is it when I extract the pure video stream from a file and audio stream and remux them with ffmpeg that the audio chops?
[20:13:38 CET] <alexpigment> Dresk|Dev: What codecs are used for the elementary streams (video and audio), and what format/container are you muxing them into?
[20:14:43 CET] <Dresk|Dev> Video is H.264 high profile, audio is aac made by some professional people, muxing into .mp4
[20:15:21 CET] <DHE> if you extracted into a pure H264 elementary stream, are sure you got the framerate right in the end?
[20:17:13 CET] <Dresk|Dev> http://pastebin.com/Hj2ptNrX - Original video, before extraction
[20:18:13 CET] <DHE> okay, looks like 30fps material in mpeg-ts
[20:18:18 CET] <Dresk|Dev> http://pastebin.com/DMAdXtGw - Video after extraction
[20:20:44 CET] <alexpigment> DHE - does it seem weird to you that the bitrate is way different between the two?
[20:20:59 CET] <Dresk|Dev> It did to me
[20:21:07 CET] <Dresk|Dev> I figured that was a calculation
[20:21:29 CET] <kepstin> Dresk|Dev: what's the ffmpeg command you used to mux the files together, and its output?
[20:21:35 CET] <Dresk|Dev> ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i %CREATEVIDEOS_INPUTFILE% -vcodec copy -an -y "%CREATEVIDEOS_VIDEOSTREAM_OUTPUT_FILENAME%"
[20:21:42 CET] <Dresk|Dev> Easy to fill in the %s
[20:21:49 CET] <Dresk|Dev> The prefix is just -stats
[20:22:00 CET] <Dresk|Dev> So that's extract video
[20:22:00 CET] <alexpigment> -an
[20:22:04 CET] <alexpigment> oh nm
[20:22:05 CET] <alexpigment> continue
[20:22:10 CET] <Dresk|Dev> Here's audio : ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i %CREATEVIDEOS_INPUTFILE% -acodec copy -vn -y "%CREATEVIDEOS_AUDIOSTREAM_INPUT_FILENAME%"
[20:22:19 CET] <Dresk|Dev> Here's mux : ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i %1 -i %2 -vcodec copy -acodec copy -y "%3"
[20:22:31 CET] <alexpigment> MPEG-TS AAC is ADTS right?
[20:22:33 CET] <kepstin> Dresk|Dev: and what are the output filenames? with those commands, ffmpeg's behaviour will depend on filename
[20:23:02 CET] <kepstin> Dresk|Dev: and why aren't you using a single command to mux both rather than extracting then merging?
[20:23:04 CET] <Dresk|Dev> kepstin: I noticed that, why doesn't ffmpeg write the same file despite what extension I give it?  The audio only works if I give the filename an .m4a extension
[20:23:31 CET] <kepstin> Dresk|Dev: if you don't specify an output format with -f, then ffmpeg guesses which format you want using the file extension
[20:24:00 CET] <kepstin> Dresk|Dev: you should probably just run a single command "ffmpeg -i video_input -i audio_input -c copy combined_output" ...
[20:24:04 CET] <Dresk|Dev> I'm confused, what format would it have to guess on if I'm extracting the audio just as it is?
[20:24:20 CET] <kepstin> Dresk|Dev: it has to have some file format to store the audio in...
[20:24:29 CET] <alexpigment> .aac is a raw stream , m4a is the stream inside an MPEG-4 container - which is the common delivery method
[20:24:29 CET] <kepstin> some container format*
[20:25:45 CET] <alexpigment> ok, so fwiw, i used to have problems like this when converting MPEG-TS to MP4, and the key was to do -c:a copy -bsf:a aac_adtstoasc
[20:25:56 CET] <Dresk|Dev> The reason I can't do it at once is because technically the audio input file has over 12 streams, I'm trying to automate it, determining the correct stream is difficult, but doing it in a singular step is much easier in batch
[20:25:58 CET] <alexpigment> i don't know if that's what's going on here, but i figured i'd mention it
[20:26:26 CET] <kepstin> Dresk|Dev: there's multiple audio streams?
[20:27:14 CET] <Dresk|Dev> And then of course I haven't been 100% straight with you guys, VLC plays it fine, but my custom 3D engine which uses FBOs to write ffmpeg frames to as textures and syncs by timestamps is what is causing the audio chopping
[20:27:23 CET] <Dresk|Dev> kepstin: Yeah, multiple languages
[20:27:59 CET] <kepstin> well, then the extract command you gave isn't what you're actually using either, since it would just pull out the first audio track... :/
[20:28:17 CET] <Dresk|Dev> If I re-encode the video the problem goes away, but I don't want to do that, I don't want more quality loss
[20:28:55 CET] <alexpigment> "if i re-encode the video" = re-encode just the video portion, or do you mean re-encoding the video AND audio?
[20:29:04 CET] <Dresk|Dev> Just the video
[20:29:21 CET] <alexpigment> ok, ignore my AAC ADTS conversion suggestion from earlier
[20:29:24 CET] <Dresk|Dev> My engine syncs on timestamps first, and if that doesn't work it tries audio
[20:29:29 CET] <kepstin> Dresk|Dev: can you give an exact copy/paste of a command you used to "re-encode the video"?
[20:29:37 CET] <kepstin> Dresk|Dev: just gotta make sure :)
[20:30:05 CET] <userdr> please how to copy the discution : there is no copy option in my client context menu ?
[20:30:31 CET] <Dresk|Dev> Sorry, this is a little longer
[20:30:36 CET] <Dresk|Dev> ECHO   - Kiosk Optimized MP4 - PASS 1...
[20:30:36 CET] <Dresk|Dev> ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i "%CREATEVIDEOS_VIDEOSTREAM_OUTPUT_FILENAME%" -i "%CREATEVIDEOS_AUDIOSTREAM_OUTPUT_FILENAME%" -pass 1 -%CREATEVIDEOS_PIXEL_FORMAT% -an -codec:v libx264 -threads %CREATEVIDEOS_THREADS% -b:v %CREATEVIDEOS_KIOSK_VIDEO_BITRATE% -f rawvideo -y NUL
[20:30:36 CET] <Dresk|Dev> ECHO   - Kiosk Optimized MP4 - PASS 2...
[20:30:36 CET] <Dresk|Dev> ffmpeg %CREATEVIDEOS_FFMPEG_PREFIX% -i "%CREATEVIDEOS_VIDEOSTREAM_OUTPUT_FILENAME%" -i "%CREATEVIDEOS_AUDIOSTREAM_OUTPUT_FILENAME%" -pass 2 -%CREATEVIDEOS_PIXEL_FORMAT% -strict experimental -codec:a aac -ac 2 -b:a %CREATEVIDEOS_KIOSK_AUDIO_BITRATE% -ar %CREATEVIDEOS_KIOSK_AUDIO_FREQUENCY% -codec:v libx264 -threads %CREATEVIDEOS_THREADS% -b:v %CREATEVIDEOS_KIOSK_VIDEO_BITRATE% -y "%CREATEVIDEOS_MP4_KIOSK_FILENAME%"
[20:30:48 CET] <kepstin> Dresk|Dev: please use a pastebin site...
[20:30:53 CET] <Dresk|Dev> Yeah, sorry
[20:30:57 CET] <kepstin> and you *are* re-encoding the audio with that
[20:31:01 CET] <kepstin> so, yeah.
[20:31:08 CET] <kepstin> that's why I asked :)
[20:31:38 CET] <kepstin> you're also maybe resampling the audio too
[20:31:52 CET] <kepstin> so all sorts of changes to audio and video, it's hard to guess which one "fixed" it
[20:32:13 CET] <alexpigment> ok, throwing this back in the ring. try -c:a copy -bsf:a aac_adtstoasc
[20:32:48 CET] <alexpigment> mpeg-ts aac audio won't work correctly in MPEG-4 containers in my experience
[20:32:50 CET] <Dresk|Dev> What is the preferred form of synchronization?  Timestamps or audio?
[20:32:58 CET] <kepstin> Dresk|Dev: ^^ add that to your command that extracts the audio track from the mpeg-ts to the standalone mp4 file
[20:33:16 CET] <Dresk|Dev> Trying that now
[20:33:46 CET] <kepstin> Dresk|Dev: in general, you should sync the video frame timestamps to the audio clock, since audio rate is determined by the soundcard which runs on a separate clock not synchronized with the cpu clocks
[20:35:54 CET] <kepstin> (this gets more complicated when you're working with e.g. hdmi audio or some usb audio modes, but in general...)
[20:36:07 CET] <Dresk|Dev> Testing now
[20:37:25 CET] <Dresk|Dev> It might be my engine
[20:37:28 CET] <Dresk|Dev> Testing again
[20:38:11 CET] <kepstin> if it works in vlc and mpv and other players, then yeah, it's probably not the file that's the problem.
[20:38:32 CET] <Dresk|Dev> Yeah it's my engine, I have issues in the render thread with vsync, dammit
[20:41:07 CET] <Dresk|Dev> https://beam.pro/dresk - Here, this is something cool for you guys, thanks to all your hard work
[20:44:18 CET] <furq> i saw that and thought "wow that is a pretty good 3d engine"
[20:44:24 CET] <furq> and then realised it was a video of ubisoft's 3d engine
[20:44:50 CET] <Dresk|Dev> Heh
[20:45:22 CET] <Dresk|Dev> My engine is capable of playing back as many video as possible in a 3D scene, including normal videos and 360 videos in those spheres
[20:45:51 CET] <Dresk|Dev> BUT, I've got to disable vsync because I've got some serious timing issues
[20:46:07 CET] <Dresk|Dev> The render thread must be starving my other threads
[20:47:36 CET] <Dresk|Dev> It's funny that the choppiness always happens at the same spot with vsync
[20:47:48 CET] <kepstin> yeah, people are often more sensitive to audio "glitches" than frames being slightly irregularly timed, so make sure you keep the sound card buffers full :/
[20:48:25 CET] <kepstin> if you're getting "choppy audio" that's probably just an underrun on the sound card buffer
[20:48:43 CET] <Dresk|Dev> I'm supposed to write a Vulkan renderer so I don't have to worry about single-threaded GPU commands anymore, but it's just a lot of work
[20:49:26 CET] <kepstin> well, give the audio its own (high priority?) thread, and time the video to the audio :/
[20:51:46 CET] <Dresk|Dev> Oh it's much worse, that video is playing ever so slightly slower in my engine apparently
[20:51:57 CET] <Dresk|Dev> I don't know whose timestamp to trust
[20:53:28 CET] <Dresk|Dev> Good lord I hate synchronization
[20:53:48 CET] <kepstin> you getting the audio sample rate correct? playing back a 48kHz file at 44.1kHz will be "slightly slower" :/
[20:54:12 CET] <Dresk|Dev> I'll double check, I wrote my own mixer so it should cover that
[20:54:25 CET] <Dresk|Dev> ffmpeg mixes but outputs to my mixer
[20:55:19 CET] <Dresk|Dev> kepstin: What do I do when a video has no audio?  Sync to timestamps?  I used to sync purely to audio but silent videos didn't work, I couldn't made a framerate hack but it didn't seem right
[20:56:36 CET] <kepstin> Dresk|Dev: couple options - if you have an audio mixer running anyways, you can still sync based on sound card timestamps, so it plays at same speed as other videos, otherwise fallback to timing based on cpu clock when there's no sound.
[20:59:47 CET] <kepstin> for example, mpv defaults to timing the video frames to audio, but falls back to system/cpu clock if there's no audio
[21:00:36 CET] <kepstin> but it has crazy alternate modes that do stuff like time frames to system clock, then resample audio so it plays at the same rate...
[21:01:24 CET] <Dresk|Dev> I'm not qualified for this, heh
[21:02:53 CET] <Dresk|Dev> I need Vulkan so I'm thread free and OpenCL so I don't have to YUV / RGB conversion on the GPU
[21:03:04 CET] <Dresk|Dev> Well, so it's faster
[21:03:15 CET] <Dresk|Dev> Doing it in software can be faster
[21:09:37 CET] <BtbN> There is portable OpenCL Vulkan Interop?
[21:09:51 CET] <BtbN> And why do you need OpenCL for YUV to RGB conversion?
[21:10:40 CET] <Dresk|DevBox> I'm all over the place, I want hardware decoding without an overlay, obviously, since I need my videos as textures
[21:11:18 CET] <BtbN> best way for that is probably cuvid right now, but that's not exactly portable
[21:12:11 CET] <kepstin> you can do yuv/rgb decently in plain opengl, don't need opencv
[21:12:24 CET] <kepstin> (see e.g. mpv's opengl video output driver)
[21:13:48 CET] <kepstin> if you have planar video and are ok with simple linear scaling, it's practically trivial in a pixel shader :/
[22:54:35 CET] <IntruderSRB> hey guys - anyone of you aware of the restriction
[22:54:37 CET] <IntruderSRB> in regards to DRM protection of interlaced videos?
[22:56:10 CET] <DHE> anything that encrypts the video doesn't care about the difference between progressive and interlaced
[22:59:15 CET] <IntruderSRB> should be like that but I receive weird error from apple 'mediastreamvalidator' when using interlaced
[22:59:35 CET] <IntruderSRB> saying it should be progressive
[23:00:12 CET] <IntruderSRB> so I was just checking
[23:24:41 CET] <st-gourichon-fid> Hello. I need to stream a video to RTP with payload 34, H263-1998 encapsulated with RFC2190 packets.
[23:25:12 CET] <st-gourichon-fid> Inspired by https://trac.ffmpeg.org/wiki/StreamingGuide#StreamingasimpleRTPaudiostreamfromFFmpeg and https://superuser.com/questions/1125344/streaming-in-ffmpeg-using-rtp I try a standard streaming op.
[23:25:25 CET] <st-gourichon-fid> This works: ffmpeg -re -i a.mp4 -vcodec h264 -an  -f rtp rtp://127.0.0.1:1234
[23:26:29 CET] <st-gourichon-fid> ... and I've found an error in my other command. Let me check again.
[23:29:15 CET] <st-gourichon-fid> This streams with ERP payload 96: ffmpeg -re -i a.mp4 -vf scale=352x288 -vcodec h263 -an  -f rtp rtp://127.0.0.1:1234
[23:31:00 CET] <st-gourichon-fid> Payload 96 uses RFC2429/4629 encapsulation. I need to stream with payloas 34 which implied RFC2190 encapsulation.
[23:38:52 CET] <st-gourichon-fid> got it working: ffmpeg -re -i a.mp4 -vf scale=352x288 -vcodec h263 -an  -payload_type 34 -f rtp rtp://127.0.0.1:60263
[23:39:05 CET] <st-gourichon-fid> Thanks for the rubberducking. ;-)
[23:41:36 CET] <st-gourichon-fid> Ah but, no
[23:41:43 CET] <st-gourichon-fid> [rtp @ 0x7f9488009240] Guessing on RTP content - if not received properly you need an SDP file describing it
[23:41:43 CET] <st-gourichon-fid> [rtp @ 0x7f9488009240] Interpreting H263 RTP data as RFC 2429/4629 even though signalled with a static payload type.
[23:44:08 CET] <st-gourichon-fid> this is better ffmpeg -re -i a.mp4 -vf scale=352x288 -vcodec h263 -an -rtpflags rfc2190 -payload_type 34 -f rtp rtp://127.0.0.1:60263
[23:50:26 CET] <st-gourichon-fid> Facing [rtp @ 0x31175a0] Unable to split H.263 packet, use -mb_info 1452 or -ps 1.bits/s speed=0.944x
[23:50:43 CET] <st-gourichon-fid> I follow advice: ffmpeg -re -i b.mp4 -vf scale=352x288 -vcodec h263 -an -payload_type 34 -rtpflags rfc2190 -mb_info 1452 -f rtp rtp://127.0.0.1:60263
[23:51:10 CET] <st-gourichon-fid> One thing remains: client complains [h263 @ 0x7feb440008c0] warning: first frame is no keyframe f=0/0
[23:51:19 CET] <st-gourichon-fid> and indeed, the display starts garbled.
[23:51:34 CET] <st-gourichon-fid> Client is  ffplay rtp://127.0.0.1:60263
[00:00:00 CET] --- Tue Mar 21 2017