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

[burek]

[03:15:43 CET] <CyberShadow> Hello. What's the easiest way I can let a Windows user try a ffmpeg patch I made?
[03:15:43 CET] <CyberShadow> I tried cross-compiling with the mingw-w64-* AUR packages, but that ends up in dependency hell for them (as they would need to get and unpack many of said packages).
[03:44:01 CET] <ricemuffinball> what is better? vp9 or x265
[03:45:10 CET] <another> depends on your definition of better
[03:46:14 CET] <pink_mist> x265 is an implementation of an encoder, while vp9 is coding format ... they're not even the same type of thing
[03:58:08 CET] <ricemuffinball> okay how many vp9 encoders are out there
[03:58:34 CET] <another> at least 2
[03:58:50 CET] <ricemuffinball> what is better? vp9 or h265
[03:58:57 CET] <ricemuffinball> pink_mist happy?
[04:06:04 CET] <ricemuffinball> what is better? vp9 or h265
[04:06:28 CET] <ricemuffinball> or what is better x265 or vp9encoderthatgoogleuses
[04:06:43 CET] <pink_mist> like another said, it depends on your definition of better
[04:07:34 CET] <ricemuffinball> best quality/size
[04:08:00 CET] <ricemuffinball> ignoring playback/hardware support
[04:18:23 CET] <ricemuffinball> everybody:  there is a program called "sox"  that can trim the last 10/20/whatever seconds off of audio file"  , if sox program can do this, why can't ffmpeg ?
[04:21:26 CET] <kepstin> because it's a different program that works in a different way and was made by different people, none of whom wrote that functionality.
[04:22:58 CET] <kepstin> (if someone was going to write that feature, the way to do it would be to add a "-toeof" input option, analogous to -sseof)
[04:23:41 CET] <ricemuffinball> is that difficult to do?
[04:24:34 CET] <ricemuffinball> sox "R:\1.flac" "R:\2.flac" trim 0 -20
[04:24:41 CET] <kepstin> Probably not that hard? But it's C code, so lots of fun ways to screw it up.
[04:24:59 CET] <ricemuffinball> kepstin are you saying "C" is horrible code language?
[04:25:36 CET] <kepstin> i'm kinda surprised that -sseof got added, tbh, we used to just tell people "use ffprobe to see how long the file is and calculate the start time yourself"
[04:26:42 CET] <kepstin> but i guess someone finally got fed up enough with that answer that they decided to write the option :)
[04:26:58 CET] <ricemuffinball> what is the point of -sseof  if i cannot even use trim command
[04:30:50 CET] <ricemuffinball> kepstin do you even know the point of having -sseof option
[04:31:11 CET] <kepstin> to let you set a start point relative to the end of the time
[04:31:22 CET] <kepstin> useful for anyone doing the opposite of what you want to do.
[04:31:48 CET] <ricemuffinball> so only include the last 30 seconds of the file
[04:34:41 CET] <Hello71> wait, are values not allowed to start with -?
[04:35:46 CET] <another> no
[04:35:57 CET] <another> at least not for -t
[04:37:03 CET] <kepstin> note that -sseof takes negative values as input
[04:37:04 CET] <kepstin> it's a separate option because timestamps are weird, and there's some weird cases when you might legit want to seek in a negative direction relative to the start of the file.
[04:37:42 CET] <kepstin> (-t is duration, and negative duration makes no sense)
[04:39:19 CET] <kepstin> -to is used to set a stop time, but it has the same issue as -ss where a negative offset from the start of the file is possible (really unusual, but yeah)
[04:42:16 CET] <ncouloute> test
[04:42:37 CET] <kepstin> ncouloute: didn't work, so sorry about that.
[04:46:06 CET] <analogical> why hasn't this been updated with 4.1.1 ?? https://ffmpeg.org/index.html#news
[04:47:07 CET] <ricemuffinball> analogical wow you are right
[04:47:20 CET] <ricemuffinball> wow, what a mess up
[04:48:17 CET] <ncouloute> Is there any way for ffmpeg to tell you what frame 50 in the input file is in the output file. If I changed the fps. (In my head there is a hard way) If not then is there a way to strictly duplicate every frame?
[04:48:46 CET] <ricemuffinball> ncouloute what are you trying to do exactly?
[04:52:24 CET] <another> unfortunately ffmpeg doesn't do news posts for patch releases
[04:53:27 CET] <ncouloute> So I got a file that is 29.97 fps (roughly) and I am converting it to 59.94 fps. I have a set of marks based on the frame number. So Mark in/Mark Out. I want to maintain those marks I tried just doubling the frame number but i ended up being off by a few frames. My guess is has to do with the original file not being exactly 29.97. MediaInfo reports Variable FPS between 29.97 and 30 on the origanl file.
[04:53:51 CET] <kepstin> analogical: there's never any new features in the point releases, so just assume it says "Bug fixes and performance improvements" or something.
[04:54:00 CET] <kepstin> although there's usually not any performance improvements either
[04:54:29 CET] <furq> ncouloute: are you converting to 59.94fps or 60000/1001 fps
[04:56:20 CET] <ncouloute> using "-vf fps=60000/1001"
[04:57:44 CET] <ncouloute> My thought is if I can just double every frame. I would get a file close to 60 fps but ideally I can figure out what frame ffmpeg will change it to
[05:16:24 CET] <analogical> kepstin, I noticed a slight performance increase but only do simple stuff :)
[05:58:26 CET] <ricemuffinball> is h264 the first codec to support HD video?
[06:00:06 CET] <another> certainly not
[06:01:04 CET] <ricemuffinball> huh, then what
[06:01:32 CET] <another> well there have been quite a few codecs before h264
[06:01:48 CET] <ricemuffinball> such as
[06:02:05 CET] <another> mpeg{1,2,4}
[06:02:25 CET] <another> among others
[06:03:01 CET] <ricemuffinball> mpeg1 doesn't support HD
[06:03:33 CET] <furq>     Stream #0:0: Video: mpeg1video, yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
[06:03:36 CET] <furq> sure it does
[06:04:57 CET] <furq> if you mean things that were actually used for hd then MUSE is probably the first
[06:05:05 CET] <furq> unless you can think of something earlier than 1979
[06:06:18 CET] <another> mpeg2 is still quite popular in broadcasting afaik
[06:06:27 CET] <another> even for HD content
[08:50:05 CET] <ricemuffinball> should i use "costant frame rate" or "variable frame rate"
[09:21:43 CET] <Ariyasu> you probably want cfr
[09:22:02 CET] <Ariyasu> theres pretty much no reason you would ever want vfr
[09:59:20 CET] <ricemuffinball>  Use VFR - Variable Frame Rate (Recommended)
[09:59:20 CET] <ricemuffinball> VFR is a very efficient recording method which allows you to get small file sizes with the maximum FPS which the recording target can obtain. For example, even though you select "60" FPS at the video settings, you will get a "variable 40FPS video" if you are able to get only 40FPS while recording.
[14:47:29 CET] <dongs> hi, how can i take some 4K60P ts/mpeg file and split it into .hevc file frame by frame
[14:47:41 CET] <dongs> actually split frame, not reencode or save as png or wahtever
[14:47:49 CET] <dongs> but just dump each raw .hevc into frame
[14:49:29 CET] <JEEB> the splitting part gets more funky, but dumping the raw Annex B with the start codes should be quite possible from stuff like MPEG-TS
[14:49:44 CET] <dongs> i'd rather not code it
[14:49:56 CET] <dongs> i'd rather just type in some mile-long command line for ffmpeg
[14:50:07 CET] <dongs> i don't expect it to be playable, im jsut curious waht the frame sizes should be,.
[14:50:29 CET] <dongs> the mmt stuff im fucking with, im getting one mpu in teh few megs size, and I doubt thats how big a single frame is, even if its an i-frame
[14:50:29 CET] <JEEB> hmm, in that case if it's MPEG-TS you might get around by just indexing with DVB Inspector or so
[14:50:33 CET] <JEEB> it shows the PES packet sizes
[14:51:21 CET] <JEEB> or if you just want to figure out how much between each start code (four or three byte 0x00 00 00 01 IIRC)
[14:51:32 CET] <dongs> yeah i guess that works too
[14:51:35 CET] <JEEB> ffmpeg -i in.ts -c copy -map 0:v:0 out.h264
[14:51:41 CET] <JEEB> uhh not h264
[14:51:44 CET] <dongs> hevc
[14:51:46 CET] <dongs> but yea
[14:51:47 CET] <JEEB> .hevc, yea
[14:51:51 CET] <dongs> lets try
[14:52:11 CET] <JEEB> if you know the pid you can do -map "0#0xblah" too instead of "first video track from first input"
[14:52:26 CET] <JEEB> anyways, I should take a further look at your MMT stuff
[14:52:33 CET] <JEEB> would be interesting how much IP bullshit one has to parse
[14:52:45 CET] <JEEB> as in, do you really have to implement IP packet parsing up to the media level
[14:52:50 CET] <dongs> no
[14:52:52 CET] <dongs> there's no IP
[14:53:01 CET] <dongs> the onyl IP shit there is NTP
[14:53:03 CET] <dongs> in each slot start
[14:53:06 CET] <dongs> but you can ignore that
[14:53:12 CET] <dongs> the rest of teh stuff is HCfB
[14:53:16 CET] <dongs> which strips all teh ip packets
[14:53:16 CET] <JEEB> ok
[14:53:25 CET] <JEEB> that's much better than I expected
[14:53:28 CET] <dongs> er ip packets = IP HEADERS
[14:53:33 CET] <JEEB> yea
[14:53:41 CET] <JEEB> you have the IP over broadcast thing and just the data I guess?
[14:53:51 CET] <JEEB> with the headers being in the IP over broadcast packets
[14:54:06 CET] <JEEB> (I don't remember the exact ITU spec name, sorry)
[14:54:33 CET] <dongs> http://bcas.tv/paste/results/BYvBA529.html some work in progress here to just walk through the structures
[14:54:33 CET] <JEEB> also if this crap really has MPEG-H audio that'd literally be the first example of me seeing it in the real world
[14:54:57 CET] <JEEB> :)
[14:55:24 CET] <JEEB> I remember you linking a thing the day before, I might grab a sample or so from there
[14:55:40 CET] <dongs> i did record the 22.2 stuff but since thats crypted i don't wanna fuck wiht it until im sure the mpu packet ordering stuff works
[14:55:47 CET] <JEEB> aye
[14:56:07 CET] <dongs> decrpytion works (at least for audio), but the CID stuff is fucking up video
[15:00:27 CET] <match_it> hi all. I have a server with video files (vod). I would to test (as simulation I mean) if 10 or 100 users connect for watching. Is there a tool for this pourpose ?
[15:00:31 CET] <dongs> https://i.imgur.com/myYQhab.png TR-B39 part4 only mentions this about CID
[15:00:53 CET] <dongs> currently dumping all MPU sorted by cid/sequence number/mpu sequence number
[15:01:01 CET] <dongs> and seeing if something makes sense
[15:02:29 CET] <JEEB> right, so it's the IP data flow identifier, and then you just have teh +1 number
[15:03:13 CET] <dongs> https://i.imgur.com/0J98fht.png
[15:03:21 CET] <dongs> -1- -2- is CID
[15:03:24 CET] <dongs> A001 is PID
[15:03:38 CET] <dongs> so there's shit mixed and i have no idea how/why
[15:04:57 CET] <dongs> if I make counters for all packets belonging to different CIDs
[15:05:13 CET] <dongs> 0x0125b368 {0, 536, 29596, 371, 1093, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
[15:05:19 CET] <dongs> the spread is something liek this for a few 100megs sample
[15:05:29 CET] <dongs> cid1 = 536, cid2 = 29xxx etc
[15:06:08 CET] <JEEB> match_it: most companies make their own based on some load testing framework. that might or might not contain FFmpeg :P
[15:06:20 CET] <JEEB> (I mean, you don't really need to play or process the data to load test)
[15:08:29 CET] <match_it> thanks JEEB, could you go indeep a bit on how they actually do ?
[15:08:39 CET] <match_it> could you say something more ?
[15:08:41 CET] <JEEB> dongs: not knowing the packet sizes the 29596 one looks like it's pushed a lot of stuff through
[15:08:56 CET] <dongs> packet size = ~0x550 avg
[15:09:02 CET] <dongs> (thats tlv packet size)
[15:09:08 CET] <dongs> they're variable-ish but around there.
[15:09:11 CET] <JEEB> aye
[15:09:19 CET] <dongs> anyway, i just ran it for liek 4 seconds and breakppointe and looked at counts.
[15:09:20 CET] <JEEB> since finally they made variable packet sizes with TLV :P
[15:10:35 CET] <JEEB> match_it: basics are to emulate a player in the parts that actually access the servers. there's multiple load testing frameworks (some in java, some in python) :P
[15:11:49 CET] <JEEB> match_it: you can f.ex. just search for "github HLS load test" for example
[15:12:07 CET] <match_it> my main conerns is where the players are loaded ? I would to understand if infrastructure layer is suitable (reliable) to give me what the promise .... :P
[15:12:55 CET] <match_it> basically I would test if my ISP gives me enough bandwidth
[15:13:06 CET] <match_it> (instant bandwidth)
[15:13:52 CET] <dongs> JEEB: hmm, lots of 0001's at start of frame to setup decoder i guess
[15:14:10 CET] <dongs> and then 1st next frame is 0x3700 offset away
[15:14:12 CET] <dongs> okay makes sense
[15:14:39 CET] <JEEB> I thought they went all out with ISOBMFF which should have lengths and not Annex B, but ok :D
[15:14:52 CET] <dongs> no this is from 4k mpegts from skapa
[15:14:56 CET] <JEEB> ISOBMFF has length+data, while annex b is start code+data
[15:14:58 CET] <JEEB> ah
[15:15:03 CET] <dongs> using your ffmpeg line
[15:15:06 CET] <JEEB> right'o
[15:15:08 CET] <dongs> just checking sditances between packets
[15:15:28 CET] <JEEB> also you can utilize the dump headers or whatever it was bit stream filter
[15:15:33 CET] <JEEB> if you need to look further
[15:15:46 CET] <dongs> ctrlf in hex editor works fine
[15:15:50 CET] <JEEB> but just looking at start codes often gives a basic idea
[15:15:51 CET] <JEEB> yea
[15:25:25 CET] <match_it> thanks JEEB, I'm looking for load test as you said
[15:29:00 CET] <ossifrage> Any ideas how to convince ./configure to only build libavformat, --disable-all --enable-avformat just results in avutil being built
[15:32:02 CET] <JEEB> you'd probably want to enable some muxers/demuxers/protocols? and yes, that sounds weird given you'd think you'd want all (although that would also bring parsers etc from lavc)
[15:32:32 CET] <JEEB> might also want to open a ticket on trac to document the current behavior and if it's considered weird improving it
[15:32:55 CET] <ossifrage> JEEB, I've been trying from the other direction and it seems to result in avformat not getting built
[15:34:08 CET] <ossifrage> (ah, getting closer, it still builds a huge pile of stuff, I guess I should punt and figure out exactly what I need)
[15:38:20 CET] <ossifrage> JEEB, yeah it seems that avformat is getting turned off, not sure what is triggering it
[15:40:58 CET] <ossifrage> I just punted and let buildroot build whatever it wanted, I'm still using a nfs root, so I can afford some bloat for the time being
[15:42:35 CET] <JEEB> ossifrage: still that sounds like there's two levels of flags, and if there's been a full disablement on one level, even if you enable the lib on the same level if the features are not enabled that you require, then it gets funky :P
[15:42:45 CET] <JEEB> which is why I think an issue on trac might be worthwhile
[15:43:08 CET] <ossifrage> Trying to multiplex some live h.264 elementary steams (from a hardware encoder) into something chrome will play
[15:43:46 CET] <ossifrage> JEEB, yeah the --disable flags turn things off that prevent other things being turned on (or somesuch)
[15:44:16 CET] <JEEB> I've seen other things do --disable-encoders --enable-encoder=list,of,things
[15:44:26 CET] <JEEB> or muxers/protocols/etc
[15:45:20 CET] <ossifrage> FFMPEG_CONF_OPTS += --disable-encoders $(foreach x,$(call qstrip,$(BR2_PACKAGE_FFMPEG_ENCODERS)),--enable-encoder=$(x))
[15:45:38 CET] <ossifrage> That is what buildroot does... disable everything and then enable what you want
[17:22:44 CET] <Accord> I need to efficiently add some video effects on subsegment of a h264 video file, what's the best way to cut that subsegment without transcoding and make sure that I can reinsert it back in the original video?
[17:23:36 CET] <Accord> I created the original h264 file so concat compatibility is not a problem, I can use the same transcoding options on the new segment and concat the before and after pieces
[17:26:05 CET] <JEEB> if you are using libx264 there's an option you can pass to it through libx264-params "stitchable=1" that keeps the parameter sets completely the same (there's some optimization that x264 does to make them smaller by default)
[17:26:26 CET] <JEEB> then otherwise it's a case of you indexing a video and figuring out where you have to start decoding and re-encoding
[17:26:33 CET] <JEEB> and then stitching the AVPackets together
[17:44:18 CET] <Accord> JEEB: any way to do this just with the CLI tool?
[17:45:32 CET] <JEEB> in a very limited sense of having to still index the bloody thing and using a container where seeking works exactly. not to mention that the stiching up is much less comfy than you'd think
[17:46:58 CET] <Accord> JEEB: so use mkv instead of mp4 and ffprobe to know exactly at which frame numbers to cut?
[17:47:46 CET] <JEEB> both mp4 and matroska are fine, and you'd have to do stuff with ffprobe yes
[17:48:36 CET] <Accord> thanks
[18:33:38 CET] <pripolo> Hello I have a SVHS VCR plugged into the S-Video port on a Hauppauge WinTV-HVR1-800, when I try to record video all I get is black output, even when playing a tape
[18:34:22 CET] <pripolo> Here is the command and output, and firmware driver loading (CX23885) https://0x0.st/zHaF.txt
[18:34:58 CET] <JEEB> pripolo: that "not initialized or corrupted" thing sounds bad in the dmesg
[18:35:10 CET] <pripolo> no that's normal
[18:35:23 CET] <JEEB> ok, does anything else read the video through v4l2?
[18:35:35 CET] <JEEB> also it seems to enable two video devices
[18:35:35 CET] <pripolo> what else can I test with? This is on a headless system
[18:35:39 CET] <JEEB> video0 and video1
[18:35:48 CET] <pripolo> video0 is v4l2, video 1 is MPEG2 for TV
[18:36:21 CET] <JEEB> with headless it's much less simple but you could check if vlc had a v4l2 module
[18:36:42 CET] <pripolo> trying video1: [video4linux2,v4l2 @ 0x6516c40] Cannot find a proper format for codec 'none' (id 0), pixel format 'none' (id -1)
[18:36:44 CET] <pripolo> ok
[18:36:58 CET] <pripolo> https://wiki.videolan.org/Documentation:Modules/v4l2/
[18:41:25 CET] <pripolo> there is no CLI only VLC
[18:47:25 CET] <JEEB> pripolo: there most definitely is
[18:47:38 CET] <pripolo> i mean I have to install 100 extra packages i do not need
[18:47:39 CET] <JEEB> you just need to run it without an interface defined
[18:47:41 CET] <JEEB> right
[18:47:50 CET] <JEEB> then you have to build it without the Qt etc interfaces :P
[18:47:56 CET] <JEEB> (or see if there's a more limited package)
[18:47:59 CET] <pripolo> oh yes I can build from source I guess
[18:48:06 CET] <pripolo> this is linux after all
[18:48:15 CET] <JEEB> I think some distributions provide more limited vlc packages
[18:48:26 CET] <pripolo> i use debian
[18:51:26 CET] <pripolo> oh
[18:51:35 CET] <pripolo> with mencoder
[18:51:37 CET] <pripolo> inputs: 0 = Television; 1 = Composite1; 2 = S-Video;
[18:53:32 CET] <pripolo> mencoder tv:// -v -tv driver=v4l2:width=720:height=480:input=2:device=/dev/video0 -ovc copy -o raw.avi
[19:00:36 CET] <pripolo> JEEB I got it
[19:00:57 CET] <pripolo> mencoder tv:// -v -tv channel=0:driver=v4l2:device=/dev/video0:input=2:width=720:height=480 -ovc copy -nosound -o out.avi
[19:01:01 CET] <pripolo> this is not with ffmpeg though so
[19:01:17 CET] <JEEB> so you have to pick the input from a specific device
[19:01:18 CET] <JEEB> I guess
[19:01:59 CET] <pripolo> yeah
[19:02:05 CET] <pripolo> now to get it with ffmpeg
[19:02:08 CET] <pripolo> so that I can use huffyuv
[19:02:12 CET] <JEEB> ffmpeg -h demuxer=v4l2
[19:02:20 CET] <JEEB> see if any of those options are of use
[19:02:26 CET] <JEEB> possibly the list_x ones
[19:03:08 CET] <JEEB> also raise the verbosity level to debug with -v debug since I see a lot of messages in the module with that level
[19:12:18 CET] <pripolo> uhm
[19:12:20 CET] <pripolo> so
[19:12:28 CET] <pripolo> JEEB after installing mencoder, ffmpeg works
[19:12:36 CET] <pripolo> so I think it was actually I was missing some libraries...
[19:12:41 CET] <JEEB> lol
[19:13:00 CET] <pripolo> I don't like libraries
[19:13:12 CET] <pripolo> makes a mess. I prefer static
[19:13:57 CET] <durandal_1707> dont use mencoder
[19:14:21 CET] <pripolo> no I don't want to, it was just a test. ffmpeg is better because i can use huffyuv
[19:15:33 CET] <pripolo> now im trying to figure out audio
[19:16:23 CET] <pripolo> Hardware PCM card 1 'Conexant CX23885' device 0 subdevice 0
[19:33:09 CET] <pripolo> JEEB, now I am stuck on audio
[19:37:18 CET] <pripolo> https://0x0.st/zHM-.txt
[19:37:24 CET] <pripolo> some outputs I get
[20:12:44 CET] <pripolo> do I need an ffmpeg with --enable-indev=alsa --enable-outdev=alsa ?
[20:12:50 CET] <pripolo> because I can see alsa when i do ffmpeg -formats
[20:19:46 CET] <JEEB> pripolo: the alsa indev most definitely seems to be there?
[20:19:58 CET] <pripolo> how do I for sure check?
[20:20:05 CET] <pripolo> -formats or configuration output?
[20:20:11 CET] <JEEB> -demuxers
[20:20:30 CET] <JEEB> ffmpeg -demuxers |grep alsa
[20:20:42 CET] <pripolo> D  alsa            ALSA audio input
[20:20:45 CET] <JEEB> anyways, you wouldn't get those messages there otherwise
[20:20:49 CET] <JEEB> they're specifically labeled alsa
[20:21:01 CET] <pripolo> it's there. im just confused why mencoder would work with audio output but not ffmpeg
[20:21:02 CET] <JEEB> so there is code built which is a) input b) called alsa
[20:21:24 CET] <JEEB> probably just naming differences etc
[20:21:59 CET] <JEEB> you define hw:1 and it attempts to open hw:1,1 and hw:1,2 just looking at your posted part of the log :P
[20:22:11 CET] <pripolo> yeah that was me just trying other subdevices
[20:22:21 CET] <pripolo> 1,1 and 1,2 fails, but 1,0 is OK, just no actual audio captured
[20:22:39 CET] <JEEB> bump verbosity, check stuff
[20:22:42 CET] <JEEB> -v debug
[20:28:20 CET] <pripolo> JEEB https://0x0.st/zHM9.log
[20:28:27 CET] <pripolo> ffmpeg output
[20:30:27 CET] <JEEB> can you check what sort of audio sample rate and channel count mencoder is taking out of the alsa device (and that it is using the same alsa device)
[20:30:56 CET] <pripolo> yup
[20:31:13 CET] <pripolo> https://0x0.st/zHMV.txt full mencoder log
[20:31:34 CET] <pripolo> AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
[20:32:49 CET] <JEEB> also main thing
[20:32:54 CET] <JEEB> it's using v4l2 for the audio, too
[20:33:06 CET] <JEEB> or whatever the tv:// thing is doing in mencoder
[20:33:08 CET] <pripolo> oh darn
[20:33:12 CET] <JEEB> the logging at least goes under v4l2
[20:34:04 CET] <JEEB> I don't have the mencoder code at hand to tell you if it just uses alsa or not in the background
[20:34:16 CET] <JEEB> or if the v4l2 interface also has audio input
[20:34:54 CET] <pripolo> I can't use -f v4l2 anyway because it wants video
[20:34:56 CET] <pripolo> for audio i mean
[20:36:14 CET] <pripolo> wait I think I got it
[20:36:36 CET] <JEEB> I was specifically talking of mencoder there since the audio seems to be coming from underneath it, too :P
[20:39:40 CET] <pripolo> alright well I'm very confused... but now there's audio
[20:39:45 CET] <pripolo> and it's unrelated to watching TV at the same time
[20:39:55 CET] <pripolo> I thought maybe someone was watching
[20:39:57 CET] <pripolo> but now it works?
[20:40:48 CET] <pripolo> ffmpeg -f v4l2 -thread_queue_size 2048 -video_size 720x480 -i /dev/video0 -f alsa -thread_queue_size 2048 -i hw:1 -c:v huffyuv -c:a pcm_s16le -t 15s "$(date +%s)".avi
[20:50:49 CET] <pripolo> and now it's not working again... wtf
[21:18:30 CET] <pripolo> yeah I don't get it JEEb. I've tried it all
[21:18:32 CET] <pripolo> doesn't work
[21:34:06 CET] <ossifrage> Anyone know of an libavformat example that multiplexes live streams?
[21:34:32 CET] <JEEB> I don't think there's anything special with that?
[21:34:37 CET] <JEEB> what exactly do you mean?
[21:35:08 CET] <ossifrage> How about something better then: https://ffmpeg.org/doxygen/0.6/output-example_8c-source.html
[21:35:29 CET] <JEEB> when searching for FFmpeg doxygen, look for trunk
[21:35:35 CET] <JEEB> esp. not branches that are really, really old
[21:35:37 CET] <JEEB> (like 0.6)
[21:35:49 CET] <JEEB> https://roundup.ffmpeg.org/doxygen/trunk/transcoding_8c-example.html
[21:35:53 CET] <JEEB> I think this is the most updated example
[21:35:59 CET] <ossifrage> JEEB, yeah that was the first hit from elgoog
[21:36:07 CET] <JEEB> it handles a lot of stuff, but you can grasp out of it the parts that you need just for parts of it
[21:36:17 CET] <JEEB> like the input/output AVFormatContexts etc
[21:36:49 CET] <ossifrage> I've used ffmpeg to encode video, but that was a long time ago and I'm really rusty with how it works
[21:37:06 CET] <JEEB> for the decoding and encoding APIs we have a separate thing that documents that pretty wel
[21:37:09 CET] <JEEB> *well
[21:37:13 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[21:37:23 CET] <JEEB> not perfect, but I think that's pretty good :P
[21:37:39 CET] <ossifrage> JEEB, I remember it going pretty quick
[21:39:23 CET] <ossifrage> It has been a long time since I did any multiplex and that was bloody transport streams, ick
[21:41:09 CET] <dkozel> Hello. I'm trying to create a constant bitrate transport stream from a webcam and microphone and seem to have it 90+% working, but the audio loses sync intermittently
[21:41:13 CET] <dkozel> https://pastebin.com/BtgigrRs
[21:41:29 CET] <dkozel> I'm capturing with ffmpeg and playing back with mplayer
[21:41:39 CET] <ossifrage> I have the encoded frames with NALU boundaries and the pts
[21:42:06 CET] <dkozel> the ffmpeg command is:
[21:42:08 CET] <dkozel> ffmpeg  -f alsa -thread_queue_size 2048 -i hw:2 -f v4l2 -thread_queue_size 2048 -video_size 1920x1080 -input_format h264 -framerate 24 -r 24 -i /dev/video2 -c:v libx264 -b:v 16M -maxrate 15M -bufsize 8M -b:a 128k -c:a aac -muxrate 17413400 "$(date +%s).ts"
[21:42:37 CET] <pripolo> JEEB I'm giving up for now on audio
[21:42:46 CET] <ossifrage> dkozel, you can always pad transport streams up to any rate you want but injecting null packets
[21:43:08 CET] <dkozel> I believe that that's what muxrate does?
[21:43:12 CET] <JEEB> yes
[21:43:26 CET] <JEEB> you can verify the result with something like DVB Inspector, I think
[21:43:29 CET] <dkozel> and I have a tool that shoes that works
[21:44:02 CET] <dkozel> here: https://github.com/drmpeg/dtv-utils/blob/master/xport.c
[21:45:17 CET] <dkozel> Oh
[21:45:30 CET] <dkozel> mplayer thinks the TS is at 48 fps, not 24
[21:45:37 CET] <dkozel> let me override that and see if it syncs
[21:46:09 CET] <JEEB> I would generally test with ffprobe, vlc and mpv or so (two FFmpeg-using and one that doesn't utilize FFmpeg for demux)
[21:46:11 CET] <dkozel> And no, I've already overridden it in the pastbin
[21:46:23 CET] <dkozel> ok, I can give those a try
[21:46:35 CET] <JEEB> ffprobe -show_packets shows the timestamps of the packets
[21:46:48 CET] <JEEB> you could do similar checks with DVB Inspector for all PES packets
[21:47:01 CET] <JEEB> (it's an MPEG-TS analyzer, will show you DTS/PTS fields)
[21:47:30 CET] <dkozel> VLC has the same audio glitch
[21:48:38 CET] <dkozel> I'll check out DVB inspector
[21:48:38 CET] <JEEB> check the timestamps, then start checking stuff like -debug_ts in ffmpeg.c to see what sort of video/audio timestamps are being passed through
[21:48:55 CET] <JEEB> it will log a *lot* but you will see each packet through its life cycle
[21:49:02 CET] <pripolo> JEEB alright I think I got it... I had installed libraries from debian repo for mencoder, so I think the static build was using THOSE instead of the static libraries
[21:49:04 CET] <pripolo> cause now it works
[21:49:09 CET] <pripolo> after removing mencoder and all extra packages
[21:49:28 CET] <pripolo> sorry for interrupt I just needed to mention
[21:52:13 CET] <dkozel> OK, the audio drop out is very visible in DVB Inspector
[21:52:40 CET] <JEEB> -debug_ts time, just be prepared for like four-to-five lines for each packet
[21:52:44 CET] <dkozel> the Audio with ADTS transport syntax PTS nodes just stop cose to the end of the file
[21:53:59 CET] <dkozel> Hmm. I wonder if this is some issue with the muxrate and the video rate I've chosen
[21:54:35 CET] <dkozel> the audio drop is immediately at the first point where the video bitrate clips into the muxrate
[21:55:16 CET] <dkozel> How do I run the debug_ts on file?
[21:55:41 CET] <dkozel> I'm far from a video expert, heh, this is definitely a learning experience
[21:56:20 CET] <JEEB> it's a parameter for ffmpeg.c
[21:56:28 CET] <JEEB> and you do it while testing the encoding :P
[21:56:46 CET] <JEEB> also bolster your verbosity level to at least -v verbose
[21:57:11 CET] <JEEB> (it's not as spammy as -v debug, but still gives you some extra info on what ffmpeg.c or FFmpeg's libraries are doing)
[21:57:16 CET] <dkozel> ok
[22:04:02 CET] <dkozel> It's going to take a while to interpret the output, but looking in DVB inspector (and just watching the files) the error is always at the end of the file
[22:04:13 CET] <dkozel> Audio does not recover once it's dropped
[22:09:30 CET] <dkozel> Hmm. interesting correlation. The AAC audio reports an FPS of 31.25. The video is 24 FPS. that's a ratio of 1.302. The ratio of video duration to sound duration is 1.269
[22:09:57 CET] <dkozel> The audio and video are synchronized, but maybe the audio is being trimmed inappropriately
[22:23:10 CET] <pripolo> that is normal for audio I see it often
[22:23:24 CET] <pripolo> if you are reading mediainfo
[22:25:36 CET] <dkozel> I am
[22:26:24 CET] <dkozel> reading through the ts_debug log, I'm not making much sense of it.
[22:27:10 CET] <dkozel> there's a possible discrepancy where the video pts time is ahead of the audio ones near it in the log
[22:27:23 CET] <dkozel> I'm going to try recapturing without the -r option
[22:27:52 CET] <dkozel> I added that to resolve "Past duration 0.xxxxx too large" errors
[22:28:02 CET] <dkozel> but maybe it's just hiding the actual problem
[22:29:37 CET] <dkozel> at least the problem is 100% reproducible, and no, removing -r didn't solve it
[22:35:05 CET] <furq> dkozel: 31.25fps is normal for 32khz audio
[22:35:13 CET] <dkozel> thanks furq
[22:35:22 CET] <furq> idk why mediainfo even bothers to report it like that
[22:35:46 CET] <dkozel> *shrug*
[22:36:11 CET] <dkozel> It's probably a true fact in someway, even if a bit confusing
[22:36:24 CET] <furq> it is technically true
[22:36:46 CET] <furq> aac is usually 1024 samples per frame, so 1024 * 31.25 = 32000 samples per second
[22:36:58 CET] <furq> i just don't know why you'd ever need to know that expressed in fps
[22:37:03 CET] <dkozel> Ah. Yeah, that makes sense then
[22:37:24 CET] <dkozel> Actually, I think I have a case
[22:37:40 CET] <dkozel> a radio system I work with has configurable packets per second
[22:38:04 CET] <dkozel> knowing the frame rate of encoded audio would be nice working with that
[22:38:18 CET] <dkozel> https://pastebin.com/4e4uYTfH
[22:38:53 CET] <dkozel> I realize asking for someone to read a verbose log is a stretch, but I think I've reached my current understanding and am not sure what to take from this
[22:39:16 CET] <dkozel> On this recording the last audio PTS is at ~0.431 seconds
[22:39:27 CET] <dkozel> in the outputted ts
[00:00:00 CET] --- Sun Mar 10 2019