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

[burek]

[00:37:10 CET] <void09> ok so adding debug_ts is pretty useless for getting timestamps of stream errors.. I get a 500MB log file :\
[00:37:15 CET] <void09> any other ideas ?
[00:41:30 CET] <void09> how to get timestamps of decoding errors in a file
[01:00:32 CET] <void09> anyone still here ? I tried for the first time to convert .ts to .mkv before cutting it.. and this results in the following error being spammed in the terminal: Non-monotonous DTS in output stream 0:0; previous: 6148040, current: 6148020; changing to 6148040. This may result in incorrect timestamps in the output file.
[01:03:43 CET] <void09> does that for every 40miliseconds (every frame)
[01:31:34 CET] <kingsley> Do you happen to know of a filter that refracts light like looking through a prism?
[01:31:39 CET] <kingsley> If so, what is it called?
[01:45:08 CET] <Hello71> how would that work exactly
[04:30:50 CET] <realies> is there a way to prevent dynaudnorm from boosting quiet sections of a voice recording and amplifying static noise?
[05:46:10 CET] <c_14> you could maybe try using agate to try and remove the static noise before using dynaudnorm
[06:31:51 CET] <realies> c_14, I was wondering how to estimate the threshold, volume detect only gives the loudest bins
[06:36:08 CET] <c_14> you'd probably just have to test. start with the default (0.125) and adjust as necessary
[06:38:07 CET] <realies> c_14, trying to make it work automatically for various input files
[07:47:38 CET] <kepstin> you could also try loudnorm instead which has builtin noise gating. it'll still boost quiet stuff tho (depending how you configure lra), but that's kind of what both filters are designed for.
[08:09:47 CET] <kingsley> Hello71: If your question, "how would that work exactly" was in response to my search for a filter that refracts light, like looking through a prism, here's more detail on how it might work.
[08:09:53 CET] <kingsley> For the user'
[08:10:29 CET] <kingsley> Oops! I accidentally pressed my <enter> key too soon. Sorry!
[08:14:03 CET] <fling> What is the universal way of including a text file into the output?
[08:14:15 CET] <kingsley> From the user's perspective, I can imagine the filter accepting 3 arguments: 1.) The file name of the original video, 2.) the angle at which the effect is rotated from the viewer's perspective (like tilting a prism) and 3.) how widely to spread the refracted color spectrum (like how far away the prism is from your eye).
[08:14:18 CET] <fling> Should it be put not as metadata but as a separate stream?
[08:22:17 CET] <kingsley> (Continuing my elaboration on how a filter might simulate refracting light like a prism...) From a software developer's perspective, and if I recall correctly, code has already exists that can convert a tuple of red, green and blue intensities in a pixel into a full spectrum color histogram. This could be done for each pixel, with the histogram's height translated into the alpha/transparency, and the resulting rainbow line tilted by the
[08:22:17 CET] <kingsley> angle defined in 2.) above, and spread across the distance defined in 3.) above.
[08:24:15 CET] <friendofafriend> My stream displays at the appropriate framerate in ffplay, but when I use VLC it plays at a much faster rate and then freezes and shows "picture is too late to be displayed (missing xxx ms)" messages until "ES_OUT_SET_(GROUP_)PCR  is called too late (pts_delay increased to 4648 ms)".  Sometimes I see messages like "Could not get display date for timestamp 0".  Is there some way to fix it?
[08:25:21 CET] <kingsley> fling: If I understand your question correctly, and I may not, maybe you could render text into video by doing something like
[08:28:45 CET] <kingsley> -filter_complex "<bla bla bla...>, drawtext=fontcolor=white: text=<(cat /tmp/text.txt):fontsize=30:x=5:y=10,<bla bla bla>...
[08:32:01 CET] <kingsley> friendofafriend: I'm not sure if I understand exactly what you're seeing, but your nice, detailed description reminds me of when I tried to watch a video on a slow computer. I wonder if ffplay is faster than vlc. Maybe you could test it by doing something like 1.) trying a 3rd video player, like maybe dragon, and/or rendering to a lower resolution and trying to watch that in vlc.
[08:33:45 CET] <fling> kingsley: sounds interesting, otoh I want to keep it as a text file
[08:33:47 CET] <friendofafriend> kingsley: It's really weird.  It's like the stream caches and then all the frames are displayed at once, then it caches again.  ffplay works perfectly, like it always has.
[08:34:05 CET] <fling> probably not possible for any container
[08:35:33 CET] <kingsley> fling: I happened to notice you wrote that you want to keep "it" as a text file. Whut ezzz deese, humfff, "it", uhf wheeech u speak?
[08:36:46 CET] <fling> kingsley: just a text file I want to embed :P
[08:36:57 CET] <fling> kingsley: I could put it into metadata in some containers I believe
[08:37:03 CET] <fling> or as an unknown stream in others
[08:37:09 CET] <fling> thinking of an universal way of doing so
[08:38:03 CET] <kingsley> fling: Sorry if I wasn't clear. Please check out "/tmp/text.txt" in my example above. It was my way of indicating your text file.
[08:39:51 CET] <fling> your example is irreversible, I will not be able to easily get the file back
[08:41:17 CET] <friendofafriend> I'm using this command for ffmpeg.  https://paste.debian.net/plain/1117404  When I play in VLC, I have to use vlc "http/h264://example.com/test.h264" or it won't demux the stream as h264, and then I get that weird play-all-the-frames-in-cache-at-once behavior.
[08:41:47 CET] <jemius> If I transform a color video to a grayscale one, shouldn't it take up significantly less disk space afterwards?
[08:42:00 CET] <kingsley> fling: If it would be convenient, comfortable, and all those good things, maybe you could explain how a file might be irreversible.
[08:42:16 CET] <fling> jemius: only if it is lossless already
[08:42:55 CET] <fling> kingsley: if I embed a jpeg thumbnail into an mp4 container then I will be able to extract if afterwards.
[08:42:56 CET] <kingsley> jemius: I dunno, but maybe the answer depends on whether it's compressed or not.
[08:43:39 CET] <fling> kingsley: same with other metadata and streams. If I add a sub stream then I will be able to extract it for example.
[08:48:45 CET] <kingsley> fling: Thank you for elaborating. If I understand correctly, maybe you're looking for a video encoding format or container that's reversible. If so, I don't know the answer, but I suppose searching with key words like... video container and reversible might find something like a wikipedia page that describes an open format you might use.
[08:59:16 CET] <fling> what? :D
[09:08:00 CET] <friendofafriend> Ah, the problem seems to "go away" when I'm not reencoding to a new framerate.  Then VLC doesn't complain.  It sure would be great to find a way to fix the timestamps (?) on the stream, so I can go back to a low FPS.
[09:08:53 CET] <friendofafriend> For some reason, that darn VLC just refuses to play the URL, and needs http/h264://example.com/stream instead.
[09:18:59 CET] <Weasel_> friendofafriend: why should vlc demux when your stream is not muxed into container but a raw video stream in h264?
[09:19:34 CET] <Weasel_> put it into container so vlc might work better
[09:20:57 CET] <friendofafriend> Weasel_: Isn't m4v a container?
[09:21:54 CET] <Weasel_> it is, but you were talking about h264 file
[09:22:17 CET] <realies> kepstin, loudnorm has built-in noise gating? :o not seeing anything on this in the docs
[09:23:32 CET] <friendofafriend> Weasel_: It was just the extension, I think?  My command line is over here.  https://paste.debian.net/plain/1117404
[09:24:33 CET] <friendofafriend> For some reason, VLC assumes it an MPEG-PS stream until I do that http/h264:// thing.  I have the same problem with mpeg4 stuff, I have to use VLC with http/mp4v://.
[09:25:35 CET] <friendofafriend> And HTML5 playback?  Never seen it work.  I've been trying at it for weeks (months).
[09:26:13 CET] <JEEB> mp4v and h264 sounds like you didn't mux into a container?
[09:26:26 CET] <JEEB> since they sound like demuxers for *raw* H.264 or MPEG-4 Video
[09:26:30 CET] <Weasel_> friendofafriend: ffmpeg looks into filename extension to decide what to write.
[09:27:03 CET] <friendofafriend> Isn't muxing into a container just a matter of passing -f m4v or something like that?
[09:27:29 CET] <JEEB> Muxer m4v [raw MPEG-4 video]:
[09:27:36 CET] <JEEB> > raw MPEG-4 video
[09:27:52 CET] <JEEB> so you are specifying indeed to just write out raw video :)
[09:28:43 CET] <friendofafriend> If I use -f mp4, I get "[mp4 @ 0x560901862040] muxer does not support non seekable output".  What container should I use for HTML5 playback?
[09:29:08 CET] <Weasel_> mp4 should work
[09:29:20 CET] <friendofafriend> (I'm just trying to take some RTSP stream and barf it into Icecast.)
[09:31:03 CET] <Weasel_> so you want live... thats a bit more complicated. look into hls/mpeg-dash
[09:31:29 CET] <JEEB> friendofafriend: if you want streaming mp4 you will need to do fragmented
[09:32:25 CET] <Weasel_> html5 spec doesn't do live
[09:32:37 CET] <JEEB> -f mp4 -movflags frag_keyframe+delay_moov
[09:32:38 CET] <JEEB> ye
[09:32:47 CET] <JEEB> or well, you can write your own MSE
[09:32:50 CET] <JEEB> and feed that into the player
[09:32:58 CET] <JEEB> but it will not be as easy as <video src="blah.mp4">
[09:33:02 CET] <JEEB> unfortunately
[09:33:03 CET] <friendofafriend> What's an MSE, JEEB?
[09:33:07 CET] <JEEB> media source extensions
[09:33:19 CET] <JEEB> you handle the I/O, and pass buffers to the HTML5 video stuff
[09:33:35 CET] <JEEB> for HLS and DASH there are pre-created things like dash.js or hls.js
[09:33:53 CET] <JEEB> welcome to HTML5 video where everyone has decided that they want to implement things in JS ;)
[09:36:19 CET] <friendofafriend> Those flags are working fine to stream MP4 to ffplay (and thank you), but I get "waiting for VOL" messages out of VLC.  And I have to use http/mp4v://example.com/stream to make it work.
[09:36:40 CET] <JEEB> that shouldn't work ^^;
[09:36:48 CET] <JEEB> you need to force mp4 or whatever the fragmented mp4 demuxer in VLC is
[09:36:57 CET] <JEEB> if you don't want to force a demuxer, use an extension
[09:37:17 CET] <friendofafriend> Like naming it .mp4, right?
[09:37:23 CET] <JEEB> yes, if it is actually mp4
[09:37:40 CET] <JEEB> ffprobe should tell you then what it figures out `ffprobe -v verbose -i URL`
[09:37:52 CET] <fling> kingsley: I could put a thumbnail as a video stream and can add the text file as a comment exif field of the thumbnail :>
[09:38:16 CET] <JEEB> for random text files in multimedia files matroska had a nice feature called attachments
[09:38:22 CET] <JEEB> usually utilized for stuff like fonts for subtitles
[09:38:30 CET] <JEEB> but you could utilize that for putting random txt files into stuff
[09:38:59 CET] <JEEB> friendofafriend: if you need more idea on the HTML5 video stuff, I recommend reading up on MSE et al from Mozilla's MDN
[09:39:36 CET] <montana> what do you people think about vp9 vs x265
[09:40:12 CET] <JEEB> x265 is an encoder, so you probably mean HEVC/H.265 there
[09:40:20 CET] <montana> jeeb sorry you are right
[09:40:27 CET] <JEEB> anyways, no matter if format is good or bad; the encoders decide
[09:40:42 CET] <montana> i guess
[09:40:44 CET] <JEEB> I can have an opinion on the format spec, but that doesn't mmean I can utilize the good things in the spec :)
[09:40:54 CET] <JEEB> libvpx is notoriously bad
[09:40:59 CET] <JEEB> for stuff like rate control
[09:41:11 CET] <JEEB> you can clearly see it's google's "throw over all" style of open source :)
[09:41:18 CET] <JEEB> "it works for our use case, that's it"
[09:41:19 CET] <friendofafriend> I think it's making an MP4 container now?  Still no dice with that darn traffic cone.  https://paste.debian.net/plain/1117410
[09:41:22 CET] <montana> wow it is?  does youtube/google use libvpx ?
[09:41:34 CET] <JEEB> yes
[09:41:56 CET] <JEEB> VP8/VP9 are google formats (VP8 originally On2's which Google bought)
[09:42:13 CET] <montana> if libvpx is notoriously bad, why does google use it
[09:42:20 CET] <JEEB> because it works well enough for their use case
[09:42:22 CET] <JEEB> which is very specific
[09:42:44 CET] <montana> then in what case is it horrible
[09:42:48 CET] <montana> can you give me an example
[09:43:11 CET] <JEEB> if you want actual psychovisual optimizations and good compression and rate control
[09:43:23 CET] <JEEB> rate control and psychovisual optimizations is where libvpx suck
[09:43:47 CET] <JEEB> which is why the encoder that one of the FFmpeg developers is selling is getting licensed by corporations :P because it makes prettier output for the same bit rate
[09:43:53 CET] <montana> jeeb i see so  if you are comparing libvpx vs  x265,   x265 is superior?
[09:44:17 CET] <JEEB> x265 is also a trash can :D but at least it implements a standardized trash can and can utilize some code off of x264
[09:44:29 CET] <JEEB> but yes, I would probably utilize x265 more easily than vpx
[09:44:55 CET] <JEEB> basically, lack of community participation in both libvpx and x265 are making it less fun than x264 for example
[09:45:22 CET] <JEEB> x265 for example still doesn't properly do psychovisual optimization when utilizing large blocks
[09:45:31 CET] <JEEB> as in, larger than x264's 16x16
[09:45:37 CET] <montana> jeeb then why do i see #x265 channel in freenode
[09:45:55 CET] <Weasel_> friendofafriend: your problem is that mp4 is not streaming friendly if it is not fragmented, put in into flv if you want to stream it like that the easy way
[09:45:57 CET] <JEEB> because it was made? :D I think I used to be there and I even contributed some documentation stuff years ago
[09:46:23 CET] <JEEB> Weasel_: how is FLV better than fragmented MP4 over a constant connection?
[09:46:43 CET] <Weasel_> I didn't say its better but easy
[09:46:48 CET] <JEEB> how is it easier?
[09:47:07 CET] <montana> jeeb you don't see  #vc1/#wmv  channel in freenode
[09:47:35 CET] <JEEB> montana: of course not. you have channels around for both libvpx (#vp8 if I recall correctly) and x265
[09:47:52 CET] <JEEB> unless someone made a channel to reverse engineer that stuff (although VC-1 has a specification)
[09:48:05 CET] <Weasel_> JEEB: I don't know how to make fragmented mp4 like just changing filename extension
[09:48:07 CET] <JEEB> what I mean is that the community never really got into x265 or libvpx
[09:48:22 CET] <JEEB> Weasel_: I just posted the flags and the guy is now happily pushing out fragmented mp4?
[09:48:30 CET] <JEEB> (´4@)
[09:48:37 CET] <JEEB> also if you need a real streaming container, there is MPEG-TS
[09:48:43 CET] <JEEB> which is standardized
[09:48:46 CET] <JEEB> and thus better than FLV
[09:49:36 CET] <Weasel_> JEEB: I missed that
[09:50:34 CET] <JEEB> FLV is effectively limited to H.264+AAC and single audio and video stream only. and its timestamps are in 1:1000. and it will never be extended because adobe doesn't care
[09:50:58 CET] <JEEB> ideas in RTMP were good, but we have better standardized containers to build similar TCP based streaming things
[09:51:07 CET] <JEEB> be it MPEG-TS, fragmented MP4 or something else
[09:58:51 CET] <friendofafriend> JEEB: MPEG-TS works great!  But I don't know what to use as a player for a pointy-clicky-web-browser user.
[10:00:15 CET] <Weasel_> friendofafriend: my hls/dash commandline for hls.js/dash.ja, dual stream from ip cam for adaptive stream https://pastebin.com/Y1jmk3qR
[10:00:18 CET] <JEEB> friendofafriend: well hls.js does have a JS MPEG-TS parser and parts that pass it through to the media parts
[10:00:34 CET] <JEEB> but you would have to implement the live stream as continuous MPEG-TS stream *yourself*
[10:00:50 CET] <JEEB> as noted, HLS and DASH is what have pre-existing solutions which you can "just include in a web page"
[10:01:44 CET] <montana> jeeb thanks for the info
[10:01:47 CET] <friendofafriend> I'm not doing anything terribly complicated.  Is there a way to play FLV in the browser?  FLV is loading fine in VLC here.
[10:02:17 CET] <Weasel_> flv.js via rtmp server
[10:03:15 CET] <friendofafriend> Oh, it'd have to be rtmp.   I've just got some Icecast server.
[10:04:56 CET] <montana> mkv is superior than flv
[10:05:35 CET] <montana> mkv is superior than flv/mp4   because mkv can be played unfinished/partially encoded/downloaded  file
[10:05:55 CET] <montana> not sure about webm
[10:06:11 CET] <JEEB> fragmented mp4 works just fine with unfinished
[10:06:15 CET] <JEEB> nobody just uses them by default :P
[10:06:33 CET] <montana> mkv have one weakness
[10:06:49 CET] <montana> audio bitrate doesn't show up correctly on mkv container
[10:06:58 CET] <montana> but it shows correctly on mp4 container
[10:07:15 CET] <montana> i wonder why that is
[10:09:24 CET] <friendofafriend> Must have made the FLV container the wrong way.  I found http://bilibili.github.io/flv.js/demo/ , gave it the URL of the stream and it reports "
[10:09:38 CET] <friendofafriend> ... Sorry, "[TransmuxingController] > Non-FLV, Unsupported media type!"
[10:11:50 CET] <montana> https://mp4repair.org/ is the only website/tool  that can repair  mp4 file
[10:13:20 CET] <Weasel_> friendofafriend: hls.js/dash.js easier if you have a web server you can use to serve those files produced by ffmpeg, no setting up rtmp
[10:14:23 CET] <friendofafriend> Weasel_: I think the delay would be sort of a problem, it's ~1min, right?
[10:16:09 CET] <montana> if i use this command, what would happen to audio?   ffmpeg -i input.mkv -c:v libaom-av1 -crf 30 -b:v 0 output.mkv
[10:17:09 CET] <Weasel_> friendofafriend: seems to be ~20 secs, flv ~2 sec
[10:19:33 CET] <friendofafriend> FLV seems like a better fit than what I was doing before, especially if HTML5 players don't handle live content anyway.
[10:20:44 CET] <friendofafriend> I sure hope I can figure out a way to get flv.js working.  The demo of flv.js seems to indicate my FLV file is still somehow pooched.
[10:21:31 CET] <Weasel_> friendofafriend: I am testing Node-Media-Server which is able to fetch rstp streams and serve those
[10:26:38 CET] <friendofafriend> I guess I'm more confused than ever.   That flv.js "works by transmuxing FLV file stream into ISO BMFF (Fragmented MP4) segments, followed by feeding mp4 segments into an HTML5 <video> element through Media Source Extensions API."
[10:27:57 CET] <Weasel_> MSE can chew those fragmented mp4 as JEBB said, but problem is getting them there
[10:29:29 CET] <JEEB> Weasel_: flv.js I understand why it exists (pre-existing FLV+RTMP crap) but I really dislike recommending it to people  xD
[10:29:47 CET] <JEEB> but yea, people really haven't focused on MPEG-TS or fragmented MP4 things in .js MSE
[10:29:55 CET] <JEEB> as in, outside of DASH etc
[10:31:38 CET] <Weasel_> JEEB: just giving options, latency is a bit of a problem with hls/dash for me which I haven't yet found out how to resolve
[10:32:38 CET] <friendofafriend> Using an FLV container has already helped a lot, and I really appreciate the direction.
[10:34:16 CET] <friendofafriend> Now to discover the weird world of .js players!  It seems like a real freak show, outside of that HTML5 stuff.  Wish they'd considered live streams.
[10:37:39 CET] <montana> i just did  ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 output.mkv  which is 1 minute video   and it resulted in  5 second output.mkv
[10:37:46 CET] <montana> why is it doing that
[10:38:04 CET] <squ> framerate?
[10:38:47 CET] <montana> 5 fps
[10:39:04 CET] <squ> and the result
[10:39:49 CET] <montana> 5 fps  but 5 second
[10:39:53 CET] <montana> not 1 minute
[10:40:12 CET] <squ> what framerate input has
[10:40:16 CET] <montana> 5 fps
[10:40:27 CET] <squ> idk then
[10:41:17 CET] <montana> and how do i modify that command so that it doesn't reencode the audio and just do bypass audio
[10:41:29 CET] <squ> -c:a copy
[10:41:37 CET] <montana> oh akay thanks
[10:59:32 CET] <JEEB> Weasel_: yea, I mean you could do very similar things to RTMP+FLV with TCP/HTTP and MPEG-TS or MP4 pipes. possibly not even much harder than that :D
[10:59:44 CET] <JEEB> it's just that at least publicly you don't have orange site posts about stuff like that
[11:16:25 CET] <Weasel_> JEEB: hmmh, there seems to be websocket servers and near realtime js players out there. I would still like to be (upcoming) standards compliant so client could be anything that works for one
[11:17:04 CET] <JEEB> Weasel_: yea websockets usually pop up because people seem to not be able to drop buffers with XHR
[11:17:15 CET] <JEEB> (XMLHtttpRequest or whatever it was in JS)
[11:17:25 CET] <JEEB> so if you have a long-running XHR request it will just buffer up and up
[11:17:34 CET] <JEEB> I have heard you can work around this, but I have never tested this
[11:17:52 CET] <JEEB> another standard thing is webrtc
[11:17:58 CET] <JEEB> and there is seemingly a python media server for that
[11:19:26 CET] <JEEB> https://github.com/aiortc/aiortc
[11:19:35 CET] <JEEB> I haven't tested this, but some people seem to be using this
[11:19:42 CET] <JEEB> under the hood WebRTC is "just RTP" which is great :P
[11:19:49 CET] <JEEB> because RTP is low latency, UDP
[11:20:03 CET] <Weasel_> I have taken a quick look at that but still at testing technologies phase
[11:20:31 CET] <JEEB> I think webrtc is already on less testing phase than f.ex. all the mess with low latency HLS and DASH :P
[11:20:52 CET] <JEEB> since it will probably tkae half a year or a year until those file based things get settled
[11:22:05 CET] <JEEB> and the apple LLHLS is going to wreck people's hopes about being OK with a "dumb" file cache
[11:23:23 CET] <JEEB> anyways, as long as your solution works in mobile and browsers and uses standard tools like MPEG-TS/MP4/HTTP/WebRTC it is "good enough" I'd say.
[12:09:41 CET] <cluelessperson> I'm looking for a way to reliably transcode media and stream it viea html easily
[12:09:46 CET] <cluelessperson> I don't know where to look
[12:13:09 CET] <TheAMM> How are there so many people trying to stream currently? Weird
[12:13:25 CET] <cluelessperson> TheAMM, it's a common problem/task.
[12:13:53 CET] <cluelessperson> I want to stream out security camera footage, or a shared video to my brother, or an animation, or whatever.
[12:14:04 CET] <BtbN> "stream vis HTML", so, you mean HLS/DASH?
[12:14:09 CET] <TheAMM> Yes, but there's been like four or five people talking about it or nearby subjects within the past few days
[12:14:20 CET] <cluelessperson> yes, probably HLS/DASH
[12:14:23 CET] <TheAMM> And I personally am writing a security cam thing as well
[12:14:24 CET] <cluelessperson> oh weird
[12:16:01 CET] <TheAMM> If you don't want to mess with hls, look at fragmented mp4, though you'll have to do extra work if you want multiple viewers (without starting an encode for each)
[12:18:22 CET] <TheAMM> Ie. server spawns ffmpeg for fragmented mp4, reads stdout and sends that to client (browser)
[12:18:54 CET] <TheAMM> There's lots of ways to stream video though and I'm not the expert, so state your case and someone might help
[12:24:56 CET] <JEEB> HLS/DASH is the simplest thing to get rolling
[12:25:01 CET] <JEEB> with browsers and mobile
[12:25:06 CET] <cluelessperson> TheAMM, I'm hoping for a super simple/easy prerolled solution.
[12:25:08 CET] <JEEB> bcause everone has already written the client side
[12:25:16 CET] <JEEB> you have hls.js/dash.js for browser
[12:25:25 CET] <cluelessperson> "run this thing with this config"  "make availble this file or stream and bam, it's distributed"
[12:25:27 CET] <JEEB> you have exoplayer for mobile (android) and the iOS thing for HLS
[12:26:10 CET] <JEEB> cluelessperson: get an http server out like nginx, enable PUT/POST from specific IPs etc (internal, your encoder), then use the hls or dash module
[12:26:22 CET] <JEEB> that will get you a HLS or DASH stream
[12:26:30 CET] <JEEB> module in FFmpeg that is
[12:27:08 CET] <cluelessperson> JEEB, that sounds doable.
[12:27:31 CET] <montana> anybody know which aac encoder youtube/google uses
[12:28:05 CET] <BtbN> I'd guess fdk, since that one was ripped out of Googles source tree
[12:28:05 CET] <JEEB> cluelessperson: if you need web browser support AND live streaming, that is probably atm the most off-the-shelf thing
[12:28:59 CET] <JEEB> BtbN: you'd be surprised how separate from each other those blocks within GOOG are
[12:29:10 CET] <JEEB> since fdk-aac comes from AOSP
[12:29:19 CET] <BtbN> Google says YouTube might be using FhG AAC, which I have never heard of before.
[12:29:30 CET] <JEEB> that's fraunhofer, and fdk-aac is fraunhofer
[12:30:15 CET] <BtbN> so Fraunhofer made two entirely separate AAC encoders?
[12:30:45 CET] <montana> fdk-aac isn't as good as apple's aac encoder though
[12:31:01 CET] <BtbN> I doubt Google is using Apple encoders.
[12:31:55 CET] <montana> i just realized youtube is incredibly stupid;  i uploaded a 32kbps audio,  yet  it creates a 96kbps dash audio
[12:32:20 CET] <BtbN> Of course it does. It has its standard set of outputs, and it will encode them no matter what.
[12:32:48 CET] <montana> btbn i am pretty sure you are even not that stupid to do such thing
[12:33:10 CET] <BtbN> I also fail to see why it's stupid. When transcoding, using a slightly higher bitrate to preserve quality isn't unheard of.
[12:33:13 CET] <JEEB> it has nothing to do with stupid
[12:33:28 CET] <JEEB> you have set outputs, you do them. you do not take what the input was into account.
[12:33:36 CET] <JEEB> that way you know exactly what you are getting out
[12:33:37 CET] <JEEB> always
[12:33:55 CET] <montana> does it make any sense to transcode 32 kbps speech audio into flac?
[12:34:19 CET] <BtbN> If flac is your standardized output, sure.
[12:34:41 CET] <BtbN> But audio bitrate is usually tiny enough so you don't need to care that much.
[12:34:51 CET] <BtbN> If they transcoded every video to 1080p, that'd be a bit of a waste.
[12:35:20 CET] <montana> btbn i doubt they do that
[12:35:31 CET] <BtbN> Which is what I just said, yes.
[12:38:21 CET] <montana> it also transcode 4 fps video to 6 fps
[12:38:45 CET] <montana> how does one just add 2 extra from nothing?
[12:38:51 CET] <montana> extra frames*
[12:38:55 CET] <BtbN> you duplicate frames as usual
[12:39:12 CET] <montana> btbn that's a lot of wasted bandwidth
[12:40:10 CET] <BtbN> no, it's not.
[12:40:19 CET] <BtbN> A duplicated frame will compress to virtually nothing.
[12:40:49 CET] <montana> also i uploaded  60kbps video  and it creates 400kbps dash video
[12:40:58 CET] <BtbN> And bumping the framerate to something that can be smoothly played on 24/30/60/120/144 Hz screens makes a lot of sense
[12:41:19 CET] <montana> that's a lot of wasted bandwidth
[12:41:25 CET] <BtbN> ?
[12:41:30 CET] <montana> also i uploaded  60kbps video  and it creates 400kbps dash video
[12:41:50 CET] <BtbN> 60kbps video is stupid enough to be ignored in their setup
[12:42:19 CET] <BtbN> They will transcode it with their standard set of transcodes for the given resolution no matter what.
[12:42:44 CET] <montana> you cannot make magically m ake 60kbps look better by making it 400kbps
[12:42:54 CET] <BtbN> Nobody claimed it does.
[12:43:03 CET] <montana> so it's pointless
[12:43:24 CET] <BtbN> YouTube _always_ transcodes, just to have a standard set of outputs they know their player can deal with.
[12:44:05 CET] <BtbN> And for security reasons I suppose.
[12:44:26 CET] <montana> what does extra kbps have to do with security?
[12:44:43 CET] <BtbN> You do not give user-uploaded data to your viewers.
[12:44:52 CET] <BtbN> One zero-day in the decoder, and you're in for a bad time.
[12:44:57 CET] <BtbN> So you always transcode.
[12:45:25 CET] <montana> i don't understand
[12:45:44 CET] <BtbN> That seems to be the case for everything you brought up so far, yes.
[12:48:18 CET] <montana> btbn have you actually seen a video that is malicious
[12:48:33 CET] <BtbN> There's been plenty of those, yes.
[12:48:58 CET] <BtbN> You can completely takeover most Android-Phones that are lacking security updates that way.
[12:49:29 CET] <montana> but are they actually legit videos?
[12:50:04 CET] <BtbN> They are crafted to run an exploit payload
[12:57:43 CET] <montana> i want to encode using av1, what is best way to do this without having issues
[12:58:21 CET] <CounterPillow> Not using av1
[12:58:48 CET] <montana> CounterPillow why is av1 giving so much issues
[12:59:44 CET] <CounterPillow> Is it?
[13:00:29 CET] <montana> i just did  ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 output.mkv  which is 1 minute video   and it resulted in  5 second output.mkv
[13:01:26 CET] <CounterPillow> Most distributions ship an ancient libaom
[13:01:43 CET] <montana> i am using 4.2.1
[13:02:03 CET] <CounterPillow> That does not tell me anything about your libaom version
[13:02:11 CET] <montana> sorry you are right
[13:02:17 CET] <CounterPillow> Which is what encodes the video here.
[13:02:37 CET] <montana> how do i find the version #
[13:03:13 CET] <CounterPillow> I'm sure your distribution has some sort of package manager that would tell you this
[14:08:32 CET] <Hello71> kingsley: I doubt that this exists in ffmpeg. maybe you can find it as a plugin for some video editing software
[14:09:11 CET] <Hello71> did you read man ffmpeg-filters
[14:43:50 CET] <realies> can you use ffmpeg to do a classic peak normalisation without the dynamic leveling?
[15:00:18 CET] <durandal_1707> realies: yes, volume filter
[15:22:49 CET] <realies> durandal_1707, you mean volumedetect + volume?
[15:34:50 CET] <Techman> Hmm, had a guy on /r/irc talk about not being able to talk in here. Can you guys consider putting something in the topic that mentions having to be registered to speak?
[16:36:48 CET] <TheAMM> You can see that in the channel mode and I expect the server should also warn in the status buffer
[16:37:02 CET] <TheAMM> Of course this will all fly over their heads
[16:47:05 CET] <pink_mist> TheAMM: you need to /mode #ffmpeg +q to see it
[16:47:11 CET] <pink_mist> it's not in the channel mode at all
[16:47:47 CET] <DHE> channel doesn't have any mode flags that would prevent talking in a channel without registering..
[16:48:20 CET] <DHE> wait, is there a +q match for unregistered that's set?
[16:48:26 CET] <pink_mist> DHE: yes it does, it has +q $~a
[17:09:19 CET] <pinky> $ ffmpeg -v verbose -i rtp://@224.0.0.56:46712 -f mp3 udp://172.20.36.128:3000
[17:09:26 CET] <pinky> seems to just sit here and never output anything
[17:12:12 CET] <pinky> when i ^C i get
[17:12:13 CET] <pinky> [AVIOContext @ 0x55e57c439d00] Statistics: 0 bytes read, 0 seeks
[17:12:13 CET] <pinky> udp://@224.0.0.56:46712: Immediate exit requested
[17:12:36 CET] <pinky> when i tcpdump i see 16:12:23.010316 IP 172.20.32.10.59464 > 224.0.0.56.46712: UDP, length 1272
[17:24:39 CET] <familiyaF> Hi, how can I verify if the video is 29.97i(59.94 fields) using ffprobe
[17:44:32 CET] <JEEB> familiyaF: you can decode a few frames of the video stream and utilize data from -show_streams and -show_frames
[17:45:06 CET] <JEEB> I'd think that by decoding like 5 frames you'd probably have enough for a guesstimate
[17:51:58 CET] <familiyaF> JEED: Thanks, got the information
[17:52:03 CET] <familiyaF> interlaced_frame=1
[17:52:03 CET] <familiyaF> top_field_first=1
[17:52:21 CET] <JEEB> and match that with the PTS difference
[17:52:36 CET] <familiyaF> r_frame_rate=19001/317
[17:52:36 CET] <familiyaF> avg_frame_rate=19001/317
[17:52:57 CET] <JEEB> those are different, you can also just compare either pts or pts_time
[17:53:00 CET] <JEEB> of the frames
[18:01:33 CET] <pinky> how do you set the input sample rate? nothing i do works
[18:01:39 CET] <pinky> $ ffmpeg -v verbose -i <(pamon) -ich 1 -och 1 -isf s16 -isr 44100 -f mp3 /tmp/tf.mp3
[18:01:43 CET] <pinky> just getting static
[18:05:55 CET] <JEEB> -sample_rate ? before input
[18:06:11 CET] <JEEB> also probably want to set sample format too, unless that one is already correct
[18:06:26 CET] <JEEB> input related options generally go before -i
[18:06:30 CET] <pinky> ah ok
[18:06:31 CET] <JEEB> output related go after
[18:06:33 CET] <pinky> let me try
[18:08:18 CET] <pinky> ugh nothing works
[18:08:54 CET] <JEEB> I'm not sure what you're doing with the pamon stuff etc
[18:09:03 CET] <pinky> just want to stream an mp3 from pulseaudio
[18:09:11 CET] <JEEB> try dumping something you know is actually s16le
[18:09:22 CET] <JEEB> into a temp file first (without an extension)
[18:09:30 CET] <JEEB> just to make sure we get the parsing of that right
[18:09:38 CET] <JEEB> then you can switch the input to your pulse or whatever
[18:09:42 CET] <pinky> pamon default according to pamon -h should be 44100 and s16ne
[18:09:53 CET] <pinky> ffmpeg doesn't have an s16ne though
[18:10:07 CET] <JEEB> that's probably "native endian" which means little endian on most x86 machines :P
[18:10:23 CET] <JEEB> so ffmpeg -v verbose -f s16le -ar 44100 -i stuff
[18:10:27 CET] <JEEB> that should do it :P
[18:10:45 CET] <JEEB> also probably number of channels is useful too :P
[18:10:50 CET] <JEEB> -ac 1/2
[18:11:00 CET] <pinky> ah nice
[18:11:01 CET] <JEEB> https://trac.ffmpeg.org/wiki/audio%20types
[18:11:32 CET] <pinky>   Stream #0:0 -> #0:0 (pcm_s16le (native) -> mp3 (libmp3lame))
[18:11:34 CET] <pinky> trying
[18:12:06 CET] <pinky> ah! that works :)
[18:12:15 CET] <pinky> thanks a lot :)
[18:12:18 CET] <JEEB> np
[18:12:26 CET] <pinky> nwo i just need to get nginx to stream it
[18:12:33 CET] <pinky> hopefully i can write it to a unix socket
[18:13:24 CET] <furq> you probably want icecast for that
[18:13:36 CET] <pinky> ah yeah might be easier
[18:13:44 CET] <pinky> had trouble last time i was trying to do it with nginx
[18:13:54 CET] <furq> an icecast url should work fine in an audio tag
[18:13:58 CET] <furq> or directly in a browser
[18:14:17 CET] <furq> plus nginx can just feed it directly
[18:14:20 CET] <furq> er
[18:14:22 CET] <furq> plus ffmpeg can just feed it directly
[18:21:26 CET] <pinky> ah sweet :)
[18:21:30 CET] <Anderssen> to the topic of extracting teletext: I've tried to decode to plain text, and it works, but somehow it doesn't work with bitmap: https://pastebin.com/Mg28EWS0
[18:22:09 CET] <Anderssen> what does work, is when I change to "-txt_format text" and output as .srt, but of course that doesn't preserve colors
[18:23:18 CET] <JEEB> Anderssen: -txt_format ass and output to ass
[18:23:23 CET] <JEEB> that preserves a lot of the stuff
[18:23:29 CET] <JEEB> text is literally just the text part
[18:23:51 CET] <JEEB> for the bitmap mode you have to output as images
[18:23:58 CET] <JEEB> not exactly going to work in a text-only subtitle format :)
[18:24:09 CET] <JEEB> so something like image2 I think?
[18:24:21 CET] <JEEB> where you define a pattern and then get the images written out as png or something
[18:24:55 CET] <Anderssen> this gives me this error: https://pastebin.com/RCui2GwY
[18:26:43 CET] <JEEB> I have no idea how that goes to eval or something
[18:27:12 CET] <JEEB> sounds like something really weird is going on in that thing
[18:27:18 CET] <JEEB> try with current master FFmpeg?
[18:28:41 CET] <JEEB> because txt_format value ass definitely exists
[18:29:00 CET] <JEEB> http://up-cat.net/p/93f8bdea
[18:29:51 CET] <Anderssen> is the current ffmpeg master available on a SuSe repository; or would I have to compile it manually?
[18:30:00 CET] <JEEB> unless... Anderssen `ffmpeg -h decoder=libzvbi_teletextdec`
[18:30:08 CET] <JEEB> see if the ass value even exists in your old FFmpeg?
[18:30:17 CET] <Anderssen> yes, it says text, bitmap and ass
[18:31:01 CET] <JEEB> I have no idea of opensuse package availability. there was someone building 64bit linux binaries and those might include zvbi?
[18:31:19 CET] <JEEB> https://johnvansickle.com/ffmpeg/
[18:31:33 CET] <JEEB> yea, has zvbi
[18:31:54 CET] <Anderssen> I think zvbi should be installed anyway; the txt_format option is from libzvbi, no?
[18:31:59 CET] <friendofafriend> I'm sending h264 video in an FLV container to an Icecast server.  There are no errors in the ffmpeg terminal output, but after some time ffplay will only show "Invalid data found when processing input" when playing the stream.  Is there any obvious brain damage with my command?  https://paste.debian.net/plain/1117489
[18:32:07 CET] <JEEB> Anderssen: I meant the binary which I linked :P
[18:32:13 CET] <JEEB> which are static binaries for 32bit and 64bit linux
[18:32:45 CET] <JEEB> Anderssen: I had to check the build info document whether the person enables compilation with zvbi or not
[18:35:22 CET] <JEEB> Anderssen: alternatively you could build FFmpeg yourself with --enable-libzvbi --enable-zlib
[18:35:36 CET] <JEEB> zlib for PNG output, zvbi for ttxt decoding
[18:36:04 CET] <Anderssen> hm, let's see, I'm trying to install the master now
[18:40:26 CET] <Anderssen> ok, it produced an output .ass file with -txt_format ass
[18:46:38 CET] <Anderssen> ok, so, I saved page 100 from teletext and did a .ass file; apparently vlc didn't like that file, it just showed me a black screen as soon as i loaded it and went superfast (according to timestamp). however, smplayer displayed that page properly. I wonder what happens if I do several pages
[18:47:15 CET] <JEEB> you might need -fix_sub_duration with teletext and some other broadcast subtitle formats
[18:47:28 CET] <JEEB> since the text samples don't contain durations
[18:47:50 CET] <JEEB> Anderssen: basically it might end up in a mess because you're going to get it all in a single stream
[19:03:49 CET] <Anderssen> ok, what happens is that, when I save 5 pages, in the .ass file all of those pages get a start time code with 0.04 s apart from each other and a duration that is being given by the parameter -fix_sub_duration (otherwise it's a duration of 10 hours, apparently).
[19:04:26 CET] <JEEB> Anderssen: yea since the duration gets calculated as the difference of receipt between the AVSubtitles
[19:04:39 CET] <Anderssen> the file was at 25 fps, so 0.04 would mean that every frame there would be another subtitle page; except that when the first page lasts 5 seconds, the other's don't overwrite them
[19:05:24 CET] <JEEB> generally it's a bad idea to try and pull in multiple subtitle pages into a single output
[19:06:03 CET] <JEEB> -fix_sub_duration with a single page should give you proper results
[19:08:42 CET] <Anderssen> yeah, though then it appears that i have to either start ffmpeg multiple times (for each page) in order to produce 1 .ass file each, or to produce 1 file and then copy/pase 1 line out of it or delete the rest in order to view just a single page
[19:09:20 CET] <JEEB> you can just have multiple inputs (-i BLAH) with a differing page selection in there
[19:09:27 CET] <JEEB> unfortunately we don't mark the AVSubtitles with the page
[19:09:43 CET] <JEEB> otherwise you could filter them as they come out of the decoder
[19:09:49 CET] <JEEB> and not have X decoders :P
[19:10:00 CET] <Anderssen> I don't get though why it produces no bmp
[19:10:25 CET] <JEEB> with bitmap?
[19:10:42 CET] <JEEB> post full command with -v verbose and its terminal output in a pastebin, link here
[19:11:22 CET] <Anderssen> yeah , it's still the same output like before though (with master ffmpeg)
[19:13:15 CET] <Anderssen> in order to be sure: https://pastebin.com/NXL7iekf
[19:20:16 CET] <void09> ok this is weird, making a mkv from a 8.6GB .ts with mkvtoolinks results in 4.4GB, with ffmpeg, 8.4GB, what is going on here :\ . bitrate shows to be about half in the mkvtoolnix generated one, and the file appears complete when playing it
[19:20:50 CET] <furq> did you map all the streams
[19:20:58 CET] <void09> there's just two, audio and video
[19:25:37 CET] <void09> please tell me how to debug this
[19:27:14 CET] <void09> 6034kbps video for the mkvtoolnix one, 11.3Mb/s for the ffmpeg one, 11.3Mb/s in the .ts
[19:27:37 CET] <void09> I know for a fact it's supposed to be around 11, so what could have happened with the mkvtoolnix one
[19:47:04 CET] <DanielTheFox> hi there
[19:47:28 CET] <DanielTheFox> is there a way to make ffmpeg perform frameskip if the output target bitrate (for video at least) is too low?
[19:47:50 CET] <JEEB> no, that is generally an encoder feature
[19:47:50 CET] <DanielTheFox> that is, start skipping frames "dynamically" instead of reducing quality
[19:47:53 CET] <DanielTheFox> aww
[19:48:03 CET] <DanielTheFox> does either mpeg4 or h263 do that?
[19:48:52 CET] <JEEB> not that I can tell
[19:48:57 CET] <DanielTheFox> oh
[19:49:07 CET] <DanielTheFox> ok, so I'll just stick to manually tampering with framerate
[19:49:27 CET] <Hello71> this seems like a bad idea
[19:49:33 CET] <DanielTheFox> now, is there a way to make ffmpeg change its output framerate at user request in the middle of a transcoding job?
[19:49:51 CET] <JEEB> there was some thing to adjust parameters for video filters, so in theory
[19:50:10 CET] <JEEB> although it almost sounds like you want extra logic in the API client
[19:50:22 CET] <JEEB> (ffmpeg.c is also an API client of the FFmpeg APIs)
[19:50:30 CET] <DanielTheFox> heh
[19:51:31 CET] <DanielTheFox> so it's likely that I'll just split the video in many parts, set them varying framerates and then glue them with no framerate changing (and using a container that doesn't mind having changing framerates, such as MP4 or MKV)
[19:52:08 CET] <DanielTheFox> then I'll end with a video that in theory should be standard, but some (or many) players, especially hardware ones, will start having troubles playing
[19:52:25 CET] <JEEB> thanks to the proliferation of mobile phone camera videos I wouldn't be too worried
[19:52:45 CET] <JEEB> I mean, there surely are some plastic boxes that will fail, but that number is becoming slimmer and slimmer
[19:52:55 CET] <DanielTheFox> hrm, yeah
[19:53:12 CET] <JEEB> but yea, what you mean are timestamp based containers
[19:53:12 CET] <DanielTheFox> my user base is extremely specific and known to have to deal with those specific issues
[19:53:14 CET] <JEEB> as opposed to frame rate
[19:53:20 CET] <DanielTheFox> yeah, MP4 vs AVI
[19:53:34 CET] <JEEB> in AVI you could hack it with skip
[19:53:42 CET] <DanielTheFox> but then I'm not free either
[19:53:54 CET] <GenTooMan> WEBM?
[19:54:02 CET] <JEEB> free?
[19:54:20 CET] <DanielTheFox> well, hrm
[19:54:31 CET] <DanielTheFox> if the container says I'm 30 fps
[19:54:44 CET] <DanielTheFox> and I start skipping frames, then I might have 15 fps, 10 fps, 7.5 fps
[19:54:47 CET] <JEEB> timestamp based containers have timestamps
[19:54:50 CET] <JEEB> not frame rate
[19:54:51 CET] <DanielTheFox> but not really 24 or something
[19:54:57 CET] <DanielTheFox> oh, yeah, glad MP4 exists
[19:55:03 CET] <JEEB> matroska's the same
[19:55:06 CET] <JEEB> mpeg-ts as well
[19:55:07 CET] <JEEB> etc etc
[19:55:12 CET] <DanielTheFox> AVI is gonna have such issues from old days tho
[19:55:23 CET] <DanielTheFox> although, again, I might have to deal with these ones as well
[19:55:37 CET] <JEEB> yes, AVI is where you used to make the frame rate 120/1.001 and then used skip frames to put various frame rates into it :P
[19:55:54 CET] <DanielTheFox> (the issues are related to avoid throwing legacy equipment to trash, which personally I agree with for both economical and environmental reasons)
[19:56:58 CET] <DanielTheFox> ok, so, hrm
[19:57:03 CET] <GenTooMan> The unfortunate thing is people built things with the replaceable mindset instead of considering how permanent things are. The Cell phone is a classic example.
[19:57:42 CET] <DanielTheFox> yeah, I think my time is worth less than throwing expensive stuff to the trash bin
[19:58:10 CET] <DanielTheFox> especially because I already do pretty much nothing, so I consider my time very affordable
[19:58:51 CET] <DanielTheFox> hrm, so.
[19:59:01 CET] <DanielTheFox> I believe I'll experiment with the available filters
[19:59:26 CET] <DanielTheFox> see ya boys, you'll know when I have an issue if I come back
[19:59:31 CET] <DanielTheFox> thanks for the info.
[20:00:29 CET] <GenTooMan> I suspect we all have issues... :D
[20:02:56 CET] <void09> JEEB: got a .ts file that turned almost half in size when converted to mkv with mkvtoolnix. ffmpeg shed just around 7%
[20:03:23 CET] <void09> I am thinking maybe this station uses some kind of padding in the container, to keep data rate constant even if actual av bitrate can vary
[20:03:24 CET] <JEEB> are you sure both included the same streams etc?
[20:03:34 CET] <void09> yes, it's just audio + video
[20:03:34 CET] <JEEB> yes, padding packets are a normal thing in MPEG-TS for broadcast
[20:03:39 CET] <JEEB> but that shouldn't get remuxed
[20:03:44 CET] <void09> well, it does
[20:03:49 CET] <JEEB> so it can have padding H.264 packets
[20:03:59 CET] <void09> that's an awful lot of padding
[20:04:12 CET] <JEEB> well, feel free to look at the thing in DVB Inspector?
[20:04:17 CET] <JEEB> that has nice graphs n' stuff
[20:04:28 CET] <JEEB> (it's my go-to tool to look at insides of MPEG-TS)
[20:05:15 CET] <JEEB> basically since you tell me both remuxed the same streams, it must mean that one of them filtered stuff out of the streams :P
[20:05:21 CET] <JEEB> or you are misunderstanding wtf the tools are doing
[20:05:31 CET] <JEEB> thus, looking at what's inside the MPEG-TS originally might help you understand
[20:06:04 CET] <JEEB> and yes, half of the thing being padding is an awful lot, but the container level padding is not passed through in FFmpeg
[20:06:10 CET] <void09> JEEB: one .ts recording from 8.6gb went down to 4.4gb in mkvtoolnix, 8.4gb in ffmpeg
[20:06:24 CET] <JEEB> thus the only thing where you can have padding is the actual streams
[20:06:32 CET] <JEEB> and H.264 are known to possibly have padding packets
[20:06:35 CET] <JEEB> *is known
[20:06:38 CET] <JEEB> void09: that is not what I mean
[20:06:51 CET] <void09> tried other raw recording from the same station, 15.1gb to 11.2gb in mkvtoolnix
[20:07:02 CET] <JEEB> you tried to imply that FFmpeg when remuxing somehow copied the input container padding
[20:07:05 CET] <JEEB> which it does not
[20:07:12 CET] <JEEB> since you do *not* receive the padding through the APIs
[20:07:12 CET] <void09> maybe i am remuxing it wrong
[20:07:28 CET] <JEEB> thus the only thing where the padding can be are the elementary streams
[20:07:41 CET] <void09> I did -vcodec copy -acodec copy outputvideo.mkv
[20:07:44 CET] <JEEB> anyways, just take a look at the darn input file in DVB Inspector or so :P
[20:07:55 CET] <JEEB> you will then see if it's container level, or the streams
[20:08:08 CET] <void09> looking at it, but what am i supposed to look for
[20:08:10 CET] <JEEB> if it's container level, the container bit rate is much higher than the included streams' average
[20:08:26 CET] <JEEB> while if the streams are actually shown taking most of the space
[20:08:39 CET] <JEEB> then the padding or whatever mkvmerge rips out is within the streams
[20:08:47 CET] <JEEB> which yes, would get remuxed by FFmpeg most likely
[20:09:03 CET] <JEEB> (there are bit stream filters which might help you with that - you just need to apply them explicitly)
[20:10:45 CET] <void09> there's transport packets in the .ts with the same data "bx     rum IT", repeating
[20:11:19 CET] <JEEB> yea, but unless those show up as actual stream content in payload
[20:11:25 CET] <JEEB> which padding packets shouldn't
[20:11:59 CET] <JEEB> void09: you can easily look at the bit rate graph tab
[20:12:21 CET] <void09> it looks mostly blue
[20:12:36 CET] <JEEB> it should tell you the legend for what is blue
[20:12:42 CET] <void09> bi bykk oacjets
[20:12:48 CET] <void09> no NUL packets*
[20:13:07 CET] <void09> so as expected, h264 padding
[20:13:12 CET] <void09> how to get rid of it with ffmpeg?
[20:14:04 CET] <JEEB> I think there was a bit stream filter that let you filter out NAL units of specific type
[20:14:32 CET] <JEEB> ah
[20:14:56 CET] <JEEB> -bsf:v h264_metadata=delete_filler
[20:14:58 CET] <JEEB> that might do it
[20:15:04 CET] <JEEB> since that option says > Deletes both filler NAL units and filler SEI messages.
[20:15:08 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#h264_005fmetadata
[20:16:35 CET] <void09>  Undefined constant or missing '(' in 'delete_filler'
[20:16:48 CET] <void09> -bsf:v h264_metadata=delete_filler -vcodec copy -acodec copy outputvideo.mkv
[20:17:38 CET] <JEEB> try adding =1 at the end?
[20:18:42 CET] <void09> that did the trick : ) thanks
[20:19:15 CET] <void09> mkvtoolnix still wins by about 1.5MB though
[20:19:26 CET] <void09> well, certainly better than 4GB :P
[20:20:36 CET] <JEEB> probably the duplicated parameter sets
[20:21:08 CET] <JEEB> try h264_redundant_pps,h264_metadata=delete_filler=1 ?
[20:21:40 CET] <JEEB> ah no,
[20:21:53 CET] <JEEB> extract_extradata,h264_metadata=delete_filler=1
[20:22:07 CET] <JEEB> or the other way so that the extract_extradata thing gets cleaner input?
[20:22:18 CET] <JEEB> asdf, forgot the remove=1
[20:22:19 CET] <JEEB> option
[20:22:20 CET] <JEEB> :)
[20:22:39 CET] <JEEB> h264_metadata=delete_filler=1,extract_extradata=remove=1
[20:23:04 CET] <JEEB> remove filler, extract and remove parameter sets etc from in-band
[20:24:25 CET] <JEEB> (broadcast needs to push that with each random access point)
[20:25:02 CET] <JEEB> (while in matroska/mp4 you can have it in a single place if you're not planning on streaming it in a way where you lack the spot where you wrote it once)
[20:34:33 CET] <void09> ok will try
[20:35:54 CET] <JEEB> &41
[20:37:17 CET] <void09> hm ?
[20:37:48 CET] <JEEB> typo of /41 :P
[21:49:15 CET] <deadbeef84> Hi, I'm trying to extract part of an HLS stream using this command: "ffmpeg -ss 30 -i stream.m3u8 out.mp4" However no frames are extracted. My test file can be generated with this command: "ffmpeg -f lavfi -i "testsrc=duration=60" -hls_time 10 -hls_list_size 10 -hls_playlist_type event -hls_segment_type fmp4 stream.m3u8". Is this a known limitation of the hls-demuxer? Anyone in here willing to help me
[21:49:21 CET] <deadbeef84> out?
[21:50:44 CET] <void09> what does -ss 30 mean ?
[21:52:47 CET] <JEEB> seek to 30s
[21:55:03 CET] <deadbeef84> Just found this ticket which seems relevant https://trac.ffmpeg.org/ticket/7359
[22:08:51 CET] <void09> JEEB: I want to ask you whhile you're still around, got any idea why I am getting this message for every single frame, when doing "ffmpeg -i "outputvide.mkv" -ss 00:15:37.651 -to 01:45:05.331  -vcodec copy -acodec copy outputvideo2.mkv" (outputvideo.mkv being the .ts tv cap that i first converted to mkv)
[22:08:57 CET] <void09> Non-monotonous DTS in output stream 0:0; previous: 5367520, current: 5367500; changing to 5367520. This may result in incorrect timestamps in the output file.
[22:09:21 CET] <void09> when cutting to mkv directly from the .ts I do not get this message spam
[22:09:56 CET] <JEEB> seems like timestamps got derped (most likely during the TS->matroska remux)
[22:10:28 CET] <JEEB> although usually muxers complain if you went backwards in time...
[22:10:37 CET] <JEEB> wonder if it's a reorder thing that got applied wrong
[22:10:41 CET] <JEEB> (´4@)
[22:11:11 CET] <JEEB> void09: also did the stripping of extraneous extradata (parameter sets) get it smaller?
[22:16:07 CET] <void09> oh I forgot, let me check
[22:20:04 CET] <void09> ffmpeg "input.ts" -bsf:v h264_metadata=delete_filler=1,extract_extradata=remove=1 outputvideo3.mkv
[22:20:12 CET] <void09> well this is slow, 3x vs 200x before
[22:20:42 CET] <JEEB> ouch
[22:20:42 CET] <void09> * ffmpeg -i "input.ts" -bsf:v h264_metadata=delete_filler=1,extract_extradata=remove=1 outputvideo3.mkv
[22:21:31 CET] <void09> not sure if that's what caused the mkv to be smaller.. going to take a while to find out now :)
[22:21:54 CET] <void09> smaller for mkvtoolnix, which did it very fast, 30 seconds for 10GB or so
[22:24:37 CET] <void09> jeeb just tried to run the command that produced the monotonous timestamp errors, but using the mkvtoolnix produced mkv instead of the ffmpeg one as input. no errors this time
[22:24:37 CET] <JEEB> that's a pretty creepy slowness
[22:24:55 CET] <JEEB> yup
[22:25:02 CET] <void09> there must be some esoteric flag somewhere i can use to fix this i bet :D
[22:25:17 CET] <JEEB> I've had issues with remuxing mpeg-ts (and probably raw H.264)
[22:25:19 CET] <void09> mkvtoolnix seems to have great defaults
[22:25:31 CET] <JEEB> that's not defaults, that's just timestamp handling
[22:25:47 CET] <void09> default timestamp handling then :P
[22:25:56 CET] <JEEB> you shouldn't need any other timestamp handling
[22:26:17 CET] <JEEB> if the stuff you push out only becomes OK after you've fed it through a decoder, that's a boog
[22:26:28 CET] <JEEB> unfortunately I have not had the time to look into it
[22:26:51 CET] <void09> you should, this is very important :P
[22:27:10 CET] <JEEB> 1) I need to figure out a sample (because most I've seen be OK?)
[22:27:20 CET] <JEEB> 2) it has to be a point where I'm not busy with something
[22:27:45 CET] <JEEB> if you have a sample there and can dd a few dozen megabytes off of it and the problem happens within that, that'd be great to have :P
[22:28:05 CET] <JEEB> dd bs=1M count=20 if=blah.ts of=blah_cut.ts
[22:28:06 CET] <void09> oh so this should not happen with all ts files ?
[22:28:10 CET] <JEEB> yea
[22:28:29 CET] <JEEB> depends on how it was created and what's the H.264 stuff inside it (or mpeg-2 video, or mpeg-4 video)
[22:28:36 CET] <JEEB> (yes I have actually seen the last one in a system)
[22:29:00 CET] <JEEB> was quite the "wait what are they really using MPEG-4 Part 2 here?!"
[22:29:28 CET] <void09> here you go: https://www55.zippyshare.com/v/leOjaEBL/file.html
[22:29:31 CET] <JEEB> not even the studio profile stuff which si 4:4:4
[22:29:51 CET] <JEEB> void09: I may recommend 0x0.st to which you can push with just curl and I think -F or so?
[22:29:56 CET] <montana> what happened to  .avi container? why don't i see anymore
[22:30:01 CET] <montana> it was popular before
[22:30:10 CET] <JEEB> it didn't support required things for modern formats
[22:30:16 CET] <JEEB> and there were better ones even in the 1990s
[22:30:34 CET] <void09> here you go again: http://0x0.st/zI-G.ts
[22:30:43 CET] <montana> jeeb which was?
[22:31:20 CET] <JEEB> void09: thanks
[22:31:42 CET] <JEEB> void09: and that cut file also has the same issue?
[22:31:45 CET] <JEEB> if you remux it
[22:31:55 CET] <void09> well I did not try that, let's see
[22:32:04 CET] <JEEB> it most likely has
[22:32:36 CET] <void09> hm simple remuxing with no seeking produces no errors
[22:32:52 CET] <JEEB> you probably need to mux into something with proper timestamps first
[22:32:54 CET] <void09> well except these which I get pretty much every time: [matroska @ 0x56372ca6f500] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[22:32:55 CET] <void09> [mpegts @ 0x56372c323280] PES packet size mismatch
[22:32:57 CET] <JEEB> then try to remux that
[22:33:13 CET] <void09> oh right I forgot, need to .mkv it with ffmpeg then cut it
[22:33:42 CET] <void09> fmpeg -i "blah_cut.mkv"  -vcodec copy -acodec copy blah_cut2.mkv
[22:33:45 CET] <JEEB> but yes, unset timestamps sounds like problems :)
[22:33:47 CET] <void09> [matroska @ 0x561079f726c0] Non-monotonous DTS in output stream 0:0; previous: 29611, current: 29591; changing to 29611. This may result in incorrect timestamps in the output file.
[22:33:51 CET] <JEEB> yup
[22:33:52 CET] <JEEB> thanks
[22:34:46 CET] <JEEB> montana: in the 1990s? MPEG-TS and MOV as two? first one is still utilized for A->B streaming use cases, and mov later became mp4 (and matroska was designed in various ways based on it)
[22:35:12 CET] <JEEB> the only reason to use AVI was that it was easily'ish understandable, and there were simple enough interfaces for it on windows
[22:35:18 CET] <JEEB> (VFW etc)
[22:44:37 CET] <void09> you looking into it JEEB or did I miss something ?
[22:45:24 CET] <JEEB> void09: I won't do it now, but possibly during the week-end. I've got some other things I'm hoping to get done with regards to mpv too :)
[22:45:36 CET] <void09> oh one more little thing.
[22:45:43 CET] <JEEB> also I want to review some FFmpeg patches already lying on the mailing list
[22:45:45 CET] <JEEB> :P
[22:45:53 CET] <void09> why would I get a 0.560 timestamp at the beginning of the video when opening a cut file in mpv ?
[22:46:24 CET] <void09> My logic says it should begin at 0 sharp :P
[22:46:27 CET] <JEEB> depending on how streams match up the start of the clip might not be zero
[22:46:41 CET] <void09> yes but half a second ?
[22:46:54 CET] <JEEB> go look at the timestamps with ffprobe or something :P
[22:46:55 CET] <void09> i mean first frame is 40ms
[22:47:12 CET] <JEEB> I think the best example of this are mp4 files with edit lists to cut off stuff
[22:47:34 CET] <JEEB> like when you cut on not exactly a random access point in your input, and then the nice mp4 writer adjust the edit list :P
[22:47:41 CET] <void09> JEEB: I do this with the resulting cut files, I skip the extra frames I get by using mkv chapter with mkvtoolnix
[22:47:58 CET] <void09> RAP, indeed
[22:48:27 CET] <JEEB> anyways, I don't have a magical eight-ball unfortunately so I can't tell you /why/ in your specific case :P
[22:48:34 CET] <void09> after applying the chapter mpv reports 0 as the starting timestamp
[22:49:23 CET] <JEEB> instead of guesstimating, please just look at the timestamps of that file
[22:49:43 CET] <void09> hmm I'll have to google on that
[22:49:46 CET] <JEEB> also remember that adding chapters generally tends to also be part of a full remux so what exactly mkvtoolnix does there I' 100% not sure
[22:50:09 CET] <JEEB> for matroska you can either -show_packets with ffprobe and -of json (to get something nicely parse'able), or you can use mkvinfo
[22:50:25 CET] <void09> I'm adding the chapters myself manually, by watching the exact timestamps of the frames in mpv (with < > keys)
[22:50:40 CET] <JEEB> yes but I mean you can't /expect/ an application to not touch the file at all otherwise
[22:50:44 CET] <JEEB> when you add the chapters
[22:50:48 CET] <JEEB> it /might/ be nice like that
[22:50:51 CET] <JEEB> but always verify
[22:51:10 CET] <JEEB> but yea, look at the timestamps of the first 20 packets or whatever
[22:51:20 CET] <JEEB> preferably both of the primary streams (a/v)
[22:51:29 CET] <JEEB> you should then see whatever the fuck you're seeing in there
[22:51:47 CET] <void09> mkvinfo outputvide11.mkv
[22:51:47 CET] <void09> (MKVInfo) Error: Couldn't open source file outputvide11.mkv (open file error).
[22:52:29 CET] <void09> ah nvm, i missed an o
[22:52:45 CET] <JEEB> there's an option you pass to mkvinfo if I recall correctly to get the list of timestamps of each packet
[22:52:55 CET] <JEEB> (and stuff like the RAP flag etc)
[22:53:54 CET] <JEEB> could have been just the -v option to raise verbosity
[22:54:07 CET] <JEEB> it will print quite a lot of stuff but you should get a grasp of the timestamps
[22:54:21 CET] <void09>  Cluster
[22:54:21 CET] <void09> | + Cluster timestamp: 00:00:00.001000000
[22:54:21 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.001000000
[22:54:21 CET] <void09> |  + Frame with size 686
[22:54:21 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.022000000
[22:54:45 CET] <void09> oh that's the audio
[22:54:58 CET] <void09>  Cluster
[22:54:58 CET] <void09> | + Cluster timestamp: 00:00:00.001000000
[22:54:58 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.001000000
[22:54:58 CET] <void09> |  + Frame with size 686
[22:54:58 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.022000000
[22:55:03 CET] <void09> there we go, the .460
[22:55:16 CET] <JEEB> sounds like you pasted the wrong stuff :P
[22:55:20 CET] <void09> wait no
[22:55:21 CET] <JEEB> also recommending pastebin or 0x0.st
[22:55:25 CET] <void09> |+ Cluster
[22:55:25 CET] <void09> | + Cluster timestamp: 00:00:00.448000000
[22:55:25 CET] <void09> | + Simple block: key, track number 2, 1 frame(s), timestamp 00:00:00.448000000
[22:55:25 CET] <void09> |  + Frame with size 679
[22:55:25 CET] <void09> | + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.460000000
[22:55:28 CET] <void09> last one, promise :D
[22:56:37 CET] <JEEB> sounds like you only encountered a valid video packet in your input after encountering some valid audio packets
[22:56:44 CET] <void09> seems this video is actually 50fps interlaced, not 25,
[22:56:52 CET] <JEEB> probably some could have been dropped but ffmpeg.c just takes it all
[22:57:01 CET] <JEEB> after seeking that is
[22:57:36 CET] <JEEB> sp of that cluster is the first one with a video packet, it just means you had audio come before it
[22:57:39 CET] <JEEB> :P
[22:58:31 CET] <JEEB> when re-encoding you often get ffmpeg.c duplicating the first frame according to some guesstimated frame rate
[22:58:31 CET] <void09> right, and the chapter resets it to 0
[22:58:50 CET] <JEEB> so you kind of get the two closer to each other
[22:59:07 CET] <JEEB> (often happens when starting off broadcast MPEG-TS since you most likely do not hit a RAP)
[22:59:24 CET] <JEEB> so your audio streams will start getting valid packets first
[22:59:49 CET] <JEEB> although with the newfangled audio formats people decided they wanted groups of packets and RAPs as well
[23:00:01 CET] <JEEB> not sure how much that helps them
[23:00:40 CET] <void09> well this happens after cutting with ffmpeg, so it has nothing to do with mpeg-ts but the way ffmpeg logic works when cutting
[23:00:55 CET] <void09> not sure how often spaced is the RAP for AAC audio
[23:01:05 CET] <JEEB> AAC and those older formats are all RAP
[23:01:09 CET] <JEEB> all packets can be decoded
[23:01:52 CET] <JEEB> void09: it has to do with a mish-mash of things. mpeg-ts seek is not exact due to no index, blah blah
[23:02:03 CET] <JEEB> just saying it's probably not as simple as you make it out :P
[23:02:08 CET] <JEEB> and not just the cutting part
[23:02:19 CET] <void09> who would have thought it's such a rocket science to cut a file :\
[23:02:21 CET] <void09> properly
[23:02:28 CET] <JEEB> welcome to containers designed for A->B
[23:02:48 CET] <JEEB> and it 100% based on the amount of effort the author of the mpeg-ts reader wanted to put into seeking
[23:02:56 CET] <void09> well, welcome to ffmpeg not caring about frame exact decoding ? :)
[23:02:57 CET] <JEEB> which I'm not surprised is not too much since you have to index to properly seek
[23:03:00 CET] <void09> seeking*
[23:03:15 CET] <JEEB> yes, that is not a primary use case nor something FFmpeg's primary APIs promise you will get
[23:03:26 CET] <JEEB> since FFmpeg's APIs are also supporting A->B
[23:03:33 CET] <JEEB> where you have no such thing as a file
[23:03:35 CET] <JEEB> for example
[23:03:44 CET] <void09> tv recordings processing is not a primary use case?
[23:04:01 CET] <JEEB> processing that requires full indexing
[23:04:02 CET] <JEEB> is not
[23:04:18 CET] <JEEB> and I don't say that this isn't a thing that people don't do
[23:04:29 CET] <JEEB> after all, that is why we have ffms2 :P
[23:04:39 CET] <JEEB> which of course does not help you since it is for /decoding/
[23:05:26 CET] <JEEB> void09: if you look at things like murdoc cutter, dgindex etc, which are for handling MPEG-TS, all of them pre-index and take a while to do that
[23:05:41 CET] <JEEB> they can take that luxury since that is their only use case
[23:05:47 CET] <JEEB> they're not gonna get a live stream from UDP
[23:05:51 CET] <JEEB> or a TV receiver
[23:06:02 CET] <JEEB> this of course doesn't mean that FFmpeg's base APIs couldn't have such a thing
[23:06:09 CET] <void09> well it's not such a big deal to decode 10gb h264 on a modern computer
[23:06:12 CET] <JEEB> but it most likely wouldn't be the default for such things
[23:06:40 CET] <JEEB> I'm basically just trying to explain why your specific use case is not there yet :P
[23:06:53 CET] <void09> It should be though. It's sooo basic :)
[23:07:15 CET] <JEEB> uh-huh
[23:07:49 CET] <JEEB> now time to decide whether you want that feature generally in the libavformat library, or is it gonna be a thing specific to MPEG-TS seeking?
[23:08:11 CET] <JEEB> (architecturally since there's multiple non-indexed containers it would be the first one)
[23:08:31 CET] <JEEB> and now suddenly you need to design, figure it out and code it
[23:09:32 CET] <JEEB> anyways, not saying it's an unneeded feature since you have ffms2 etc which are providing indexed decoding etc for such things like aegisub/avisynth/vapoursynth
[23:09:58 CET] <JEEB> but unfortunately it is also much simpler to handle it in its own application/library that specifically serves such a need
[23:10:09 CET] <JEEB> since you don't need to give a flying mcdongle about any other use cases
[23:10:19 CET] <JEEB> which you'd have to do if you'd add the feature into lavf
[23:11:11 CET] <JEEB> anyways I hope you understand the other reason in addition to developer priorities (aka "what hurts their leg" or "what they fancy") why the feature is not there :P
[23:12:20 CET] <JEEB> like, if this was a job I'd get a list of crap that needs to be done based on who pays and what and how much business it could bring. in my case, it's what I happen to give a damn about. and I think that's often the case.
[23:13:15 CET] <void09> Makes perfect sense. Yet I am amazed how many things you can do with ffmpeg.. and you can'd do this :D
[23:13:31 CET] <void09> well, you can, just not bit perfect I guess
[23:13:31 CET] <JEEB> you can do what you want /with/ FFmpeg
[23:13:41 CET] <JEEB> as in, if you make an application that uses the APIs and indexes
[23:13:43 CET] <void09> yeah yeah API vs cli tool
[23:13:48 CET] <JEEB> you can do the same thing as ffms2
[23:13:48 CET] <void09> I know I know :D
[23:13:55 CET] <JEEB> just not decode, but do packet copying
[23:14:00 CET] <JEEB> ffmpeg.c is ffmpeg.c
[23:14:06 CET] <JEEB> it's trying to be a jack of all trades
[23:14:18 CET] <JEEB> you can get scary far with it
[23:15:26 CET] <JEEB> also for the reference, the only productive thing I did during the last 24h in open source was to review a pull requst :P
[23:15:29 CET] <JEEB> https://github.com/mpv-player/mpv/pull/7176
[23:17:32 CET] <void09> mpv is nice
[23:17:42 CET] <void09> but I never got it to display dvd/bluray menus properly
[23:17:50 CET] <void09> I mean, to get their interactiveness
[23:18:19 CET] <void09> No idea if it just can't do it right or I am missing some compile options
[23:18:28 CET] <furq> didn't they drop dvdnav support
[23:19:07 CET] <furq> DVD menus are not supported.
[23:19:08 CET] <furq> close enough
[23:20:41 CET] <void09> huh, strange
[23:32:36 CET] <JEEB> void09: basically since nobody wanted to maintain the stuff it was removed.
[23:32:52 CET] <JEEB> effectively VLC is the only one which actually has someone maintaining that stuff
[23:33:00 CET] <void09> JEEB: :O
[23:33:16 CET] <void09> the stripping run finished and i can't belive this
[23:33:39 CET] <void09> cut video is 5.1GB
[23:33:54 CET] <void09> cut/remuxed with ffmpeg/mkvtoolnix normally
[23:34:12 CET] <void09> on this tv station it seems there's no h264 padding or not significant
[23:34:13 CET] <void09> buuut
[23:34:58 CET] <void09> the filler and extradata line i added in ffmpeg, produced a 3.1GB MKV file
[23:35:12 CET] <void09> from which I still have to cut 30 minutes soi can compare with the 5.1GB one
[23:35:13 CET] <void09> WTF
[23:35:30 CET] <void09> 3.1 GB is uncut
[23:35:44 CET] <void09> from 7.4GB input
[23:35:46 CET] <JEEB> just make sure you actually were doing copy codec for video?
[23:36:03 CET] <void09> lol you think I did an encode ? :D
[23:36:15 CET] <void09> lol I did
[23:36:17 CET] <JEEB> just saying it's worth a double-check
[23:36:20 CET] <void09> that's why it was so slow
[23:36:23 CET] <JEEB> also would explain the slowness
[23:36:24 CET] <JEEB> yup
[23:36:28 CET] <void09> facepalm
[23:39:31 CET] <void09> ok. mkvtoolnix still 3MB smaller even with the metadata strip
[23:50:42 CET] <JEEB> can just be a difference of what things it writes as far as the matroska container goes
[23:51:00 CET] <JEEB> you could look into it more, but :eff:
[00:00:00 CET] --- Sat Nov 23 2019