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

[burek]

[00:28:14 CEST] <durandal_1707> ultrav1olet: what version?
[00:30:17 CEST] <argoneus> hello
[00:30:36 CEST] <ultrav1olet> durandal_1707: I copy-pasted -ss 00:XX:XX - obviously the result became shorter. Sorry, I'm an idiot ;-)
[00:30:56 CEST] <argoneus> I have a .mkv file with english subtitles and I'm using ffmpeg -i file.mkv -filter_complex "[0:v][0:s]overlay[v]" -map "[v]" -map 0:a:1 output.mp4
[00:31:09 CEST] <argoneus> but for some reason the resulting mp4 is missing the hardcoded subtitles?
[00:33:26 CEST] <dl2s4> are you sure they are hardcoded? i guess hardcoded subtitles does not disappear just so
[00:33:35 CEST] <argoneus> well
[00:33:42 CEST] <argoneus> when I open the .mkv in my video player I can choose them
[00:33:54 CEST] <argoneus> but when I open the mp4 there's no subtitles anymore nor are there any in the video
[00:36:09 CEST] <notdaniel> any tips on nvenc optimization? missing some of the x264 parameters :/ been setting a max bitrate and buffer size but otherwise just using -cq
[00:36:09 CEST] <dl2s4> yeah they are  not hardcoded then. you should be able to mux in the subtitles maybe ass, srt or whatever format into your mp4 i guess... i guess mp4 allows most subtitles format, could be wrong, not sure how to fix your problem exactly though, i mean how the ffmpeg command would look like.
[00:36:25 CEST] <argoneus> hmm
[00:36:40 CEST] <iive> dl2s4: it supports only its own format(s) for subtitles
[00:37:29 CEST] <ultrav1olet> mp4 is quite picky in regards to subtitles formarts
[00:37:31 CEST] <dl2s4> iive, ok, thanks. argoneus then you would need subtitle format which are supported for mp4
[00:37:47 CEST] <ultrav1olet> you cannot just copy e.g. srt subs to it as far as I remember
[00:39:12 CEST] <argoneus> it doesn't work with .mkv either
[00:40:55 CEST] <iive> mkv should take srt, ass and vobsub
[00:42:19 CEST] <argoneus> it's dvd subtitles
[00:42:30 CEST] <argoneus> not sure if that changes anything
[00:44:22 CEST] <iive> vobsub are dvd subtitles, and they are bitmap based ones
[00:44:35 CEST] <iive> so no easy conversion to text based ones, like srt/ass
[00:45:50 CEST] <argoneus> I just need to take a mkv file
[00:46:06 CEST] <argoneus> and produce a mp4 or similar with the subtitles already in it
[00:46:11 CEST] <argoneus> because where I'm playing these you can't choose subs
[00:46:13 CEST] <argoneus> is there no easy way to do this?
[00:57:23 CEST] <relaxed> you can hard sub them, but it requires encoding
[01:12:08 CEST] <bhuey> Hi, I'd like some help with confguration files
[01:12:45 CEST] <bhuey> I got a .swf URL working with a combination of ffmpeg and ffserver configurations but I really don't understand what's going on there
[01:12:58 CEST] <bhuey> I'd like to eventually get it to work with .mpg format
[01:13:08 CEST] <bhuey> and abandon .swf
[01:13:26 CEST] <bhuey> this a Raspberry Pi 3 btw
[01:13:32 CEST] <bhuey> it's got omx acceleration
[04:03:06 CEST] <LABcrab> Hello room. I have a finnicky .AVI file. It's almost 5 GB and it will only play well in WMP. I made it using Virtual VCR. What should I do to make this a more convenient file? ffmpeg and related tools misrender the file.
[04:04:11 CEST] <dystopia_> misrender how?
[04:04:30 CEST] <dystopia_> x264 is probably the best codec to use atm
[04:04:48 CEST] <LABcrab> It will spit out a random frame from time to time. WMP doesn't do that.
[04:05:49 CEST] <dystopia_> ffmpeg -i in.avi -c:v libx264 -c:a copy out.mkv
[04:06:11 CEST] <dystopia_> or add in -t 60 to test a small sample like
[04:06:19 CEST] <dystopia_> ffmpeg -t 60 -i in.avi -c:v libx264 -c:a copy out.mkv
[04:06:34 CEST] <LABcrab> Yes, but won't this still give me a problem?
[04:07:10 CEST] <dystopia_> test it
[04:07:12 CEST] <dystopia_> then report back
[04:07:21 CEST] <dystopia_> also a pastebin of your media info
[04:07:28 CEST] <dystopia_> and a pastebin of your ffmpeg log
[04:07:33 CEST] <dystopia_> would help diagnose issues
[04:08:34 CEST] <LABcrab> Still doing it. :-(
[04:13:13 CEST] <LABcrab> https://pastebin.com/MrmD8iER
[04:17:23 CEST] <LABcrab> The audio portion (PCM) works just fine. It's the video (RAW) that is giving me a problem.
[04:30:11 CEST] <LABcrab> Can anyone help me with the raw file, please?
[05:14:44 CEST] <dystopia_> sorry i was afk LABcrab
[05:14:54 CEST] <dystopia_> it's 4:2:2
[05:15:01 CEST] <dystopia_> you should probably make it 4:2:0
[05:15:14 CEST] <LABcrab> How can I do this?
[05:15:35 CEST] <LABcrab> I've extracted all the frames as BMP.
[05:16:41 CEST] <dystopia_> add -pix_fmt yuv420p
[05:17:05 CEST] <dystopia_> ffmpeg -t 30 -i in.avi -c:v libx264 -pix_fmt yuv420p -c:a copy out.mkv
[05:18:09 CEST] <LABcrab> Should I change something in my Virtual VCR settings?
[05:18:27 CEST] <dystopia_> i don't know
[05:18:39 CEST] <dystopia_> it's up to you what your capturing and how you want to do it
[05:59:31 CEST] <LABcrab> I redid the capturing and almost all errors are gone. No more indexing and so forth. I still need to fix a small part at the end of the music video, but it shouldn't be a big deal.
[06:40:20 CEST] <HoPollo> Hello there, can someone help me about ndi pls ?
[11:17:14 CEST] <ultrav1olet> I'm trying to mux my video with UTF-8 subs and ffmpeg doesn't like that
[11:17:50 CEST] <ultrav1olet>  Unable to recode subtitle event "Meet my fiancý," from UTF-8 to UTF-8
[11:17:52 CEST] <ultrav1olet> Error while decoding stream #1:0: Invalid or incomplete multibyte or wide character
[11:18:26 CEST] <ultrav1olet> this doesn't work: "-sub_charenc UTF-8 -i subs.srt"
[11:18:41 CEST] <ultrav1olet> the subtitles file is a valid UTF-8 file
[11:18:44 CEST] <BtbN> that does not look like they are in UTF-8. The error means it encountered a character that's not UTF-8
[11:19:19 CEST] <ultrav1olet> the file is indeed UTF-8 :(
[11:19:29 CEST] <ultrav1olet> "Meet my fiancée"
[11:19:51 CEST] <ultrav1olet> 7-bit ascii -> Meet my fianc.e
[11:20:22 CEST] <ultrav1olet> ooops, 8859-1 "Meet my fiancée" also works
[11:20:26 CEST] <ultrav1olet> strange
[11:21:36 CEST] <ultrav1olet> BtbN: thanks, ISO 8859-1 works :-)
[13:35:08 CEST] <flok420> I get "int avcodec_copy_context(AVCodecContext*, const AVCodecContext*) is deprecated" what is the alternative? the examples in google show something that uses a codec member of a structure but apparently that codec-member is deprecated as well?
[13:37:16 CEST] <JEEB> you create your own avcodec context and if you want to initialize it from the codec parameters of a stream you use avcodec_parameters_to_context
[13:37:26 CEST] <JEEB> for the input that is
[13:37:43 CEST] <JEEB> for output you should be creating your own lavc context in any case
[13:43:33 CEST] <flok420> so, AVCodecContext *codec_ctx = avcodec_alloc_context3(codec);   avcodec_parameters_to_context(codec_ctx, format_ctx->streams[video_stream_index]->codecpar);    ? (I'm trying to adapt an example I found on stackoverflow to reflect the deprecation changes: https://stackoverflow.com/questions/10715170/receiving-rtsp-stream-using-ffmpeg-library )
[13:46:15 CEST] <flok420> oh, no, something fails now: [swscaler @ 0xf3b9a0] bad src image pointers
[13:51:51 CEST] <JEEB> flok420: I recommend just looking at the examples under docs/examples :P
[13:51:57 CEST] <JEEB> those take you through demuxing
[13:52:07 CEST] <JEEB> and to be honest "receiving RTSP" is nothing special
[13:52:52 CEST] <JEEB> the only thing you have to keep in mind that you want to look at an example that uses the avcodec_send_packet | avcodec_receive_frame
[13:52:58 CEST] <JEEB> new decoding APIs
[13:53:09 CEST] <JEEB> (encoding side has the same thing, where the API consists of two end points)
[13:53:16 CEST] <JEEB> feed with one, receive from another
[13:53:28 CEST] <JEEB> and both can tell you to try again after poking the other
[13:56:54 CEST] <flok420> JEEB: ok, I will. thank you for your time!
[14:38:46 CEST] <flok420> 1 warning left! \o/
[16:02:52 CEST] <T-K1> hi i'm trying to have ffmpeg read from an existing stream but it's complaining about the port, am I doing something wrong? ffmpeg -i udp://127.0.0.1:41234 thestream.mp4
[16:03:44 CEST] <T-K1> [udp @ 0x3131800] bind failed: Address already in use
[16:34:14 CEST] <dystopia_> hello
[16:34:33 CEST] <dystopia_> using concat to join 2 .m2ts files, but my output no longer has audio
[16:34:35 CEST] <dystopia_> https://pastebin.com/raw/QEiwYH9L
[16:34:52 CEST] <dystopia_> anyone know why ? it looks like it's catting the audio in the log
[16:40:50 CEST] <alexpigment> dystopia: what if you just do a stream copy on one into a new m2ts container?
[16:41:02 CEST] <alexpigment> in my experience, the ts muxer in ffmpeg sucks, and i've gotten the same result many time
[16:41:04 CEST] <alexpigment> *times
[16:41:13 CEST] <alexpigment> completely unrelated to concat in my experience
[16:42:32 CEST] <dystopia_> how would i do that alexpigment?
[16:42:32 CEST] <atomnuker> ts sucks period, you can't make it not suck
[16:42:42 CEST] <dystopia_> this is my first time working with m2ts
[16:43:17 CEST] <alexpigment> dystopia: just do ffmpeg -i [input] -c copy -f mpegts [output.m2ts]
[16:43:29 CEST] <alexpigment> atomnuker: i disagree with this whole-heartedly, but to each his own ;)
[16:43:58 CEST] <alexpigment> i mean, sure, it may not be as robust as MKV, but it's supported natively by more systems, both in the user and commercial world
[16:44:10 CEST] <alexpigment> and with a good muxer like Tsmuxer, everything works fine
[16:44:15 CEST] <dystopia_> so "ffmpeg -i 1.m2ts -1 2.m2ts -c copy -f mpegts out.m2ts" ?
[16:45:17 CEST] <atomnuker> alexpigment: its not robust, its very wasteful and it doesn't support new technologies
[16:45:18 CEST] <alexpigment> yeah
[16:45:24 CEST] <dystopia_> it's running now, will see how it ends up :)
[16:45:36 CEST] <alexpigment> dystopia: sorry, no
[16:45:39 CEST] <alexpigment> i meant just one video
[16:45:41 CEST] <dystopia_> when i get the files joined atomnuker it will be going to x264 :)
[16:45:52 CEST] <dystopia_> then how do i add the second video alexpigment?
[16:46:00 CEST] <dystopia_> i already have 2x 1 video :p
[16:46:13 CEST] <alexpigment> this is not a 'fix'; this is verifying that the problem just exists in general, regardless of concat
[16:46:38 CEST] <alexpigment> if you get audio when just doing a stream copy for one file, then you can ignore the concat part of the issue
[16:46:54 CEST] <alexpigment> i said that backwards, but hopefully you get my point ;)
[16:48:02 CEST] <alexpigment> atomnuker: i get that it's not the newest technology. it was created a very long time ago and has been slow to update. but it's a professional standard and works very well on more systems than MKV does
[16:48:18 CEST] <alexpigment> like, for instance, a fresh install of Windows 7
[16:49:28 CEST] <alexpigment> MKV only works if you install a bunch of crap. the average person will install VLC, which is a horrible piece of shit, and probably end up watching improperly deinterlaced content (480i and 1080i are common in ts files)
[16:50:18 CEST] <dystopia_> no audio doing that alexpigment
[16:50:25 CEST] <alexpigment> that's what i figured
[16:50:26 CEST] <dystopia_> but again it looks like it's copying the audio
[16:50:30 CEST] <alexpigment> ok, so ffmpeg is not your tool :)
[16:50:36 CEST] <alexpigment> is it PCM audio, by chance?
[16:50:46 CEST] <dystopia_> yeah 24bit
[16:50:51 CEST] <alexpigment> yep
[16:51:17 CEST] <dystopia_> i can encode in segments and then cat afterwards
[16:51:22 CEST] <dystopia_> but thats meh
[16:51:29 CEST] <dystopia_> would like to just set it going and leave it
[16:51:38 CEST] <alexpigment> that's a long-standing issue that I would someone would fix, but there are too many people out there who naively think that TS is a format not worth working on, rather than, you know, a huge international standard ;)
[16:51:40 CEST] <furq> no audio in what
[16:51:48 CEST] <furq> in what player
[16:51:54 CEST] <dystopia_> [15:34:35] <dystopia_> using concat to join 2 .m2ts files, but my output no longer has audio
[16:51:54 CEST] <dystopia_> [15:34:36] <dystopia_> https://pastebin.com/raw/QEiwYH9L
[16:51:59 CEST] <dystopia_> no audio in the file furq
[16:52:03 CEST] <alexpigment> furq: it's a problem with streams not getting copied into TS files in general
[16:52:12 CEST] <dystopia_> looking in media info, and playing in mpc
[16:52:15 CEST] <dystopia_> no audio is present
[16:53:14 CEST] <alexpigment> dystopia_ do you *need* ffmpeg for this? I know tsmuxer should be able to do it
[16:53:29 CEST] <furq> if you're reencoding anyway then don't mux to ts
[16:53:39 CEST] <furq> you might as well just use the concat filter if you're reencoding
[16:53:58 CEST] <dystopia_> so go to which container then?
[16:54:06 CEST] <furq> probably mkv
[16:54:08 CEST] <alexpigment> MKV doesn't have the same issue
[16:54:15 CEST] <dystopia_> ok :)
[16:54:16 CEST] <dystopia_> testing now
[16:54:48 CEST] <dystopia_> [matroska @ 0000000002c22f00] No wav codec tag found for cod
[16:54:48 CEST] <dystopia_> av_interleaved_write_frame(): Invalid argument
[16:54:48 CEST] <dystopia_> Error writing trailer of Red.Night.mkv: Invalid argument
[16:54:51 CEST] <atomnuker> alexpigment: "professional" is a bad word when talking about multimedia
[16:54:53 CEST] <dystopia_> yeah it didn't like that
[16:54:59 CEST] <atomnuker> professional things suck
[16:55:00 CEST] <dystopia_> i will give ts muxer a shot
[16:55:16 CEST] <alexpigment> atomnuker: all television. all blu-ray. is that a better description?
[16:55:33 CEST] <furq> try adding -c:a pcm_s24le
[16:55:38 CEST] <dystopia_> ok
[16:55:39 CEST] <furq> mkv should definitely support 24-bit pcm
[16:55:53 CEST] <alexpigment> furq: it might not support 24be maybe?
[16:56:07 CEST] <furq> maybe
[16:56:07 CEST] <alexpigment> assuming this is coming from a blu-ray disc, i'm pretty sure they use 24-bit big endian
[16:56:11 CEST] <furq> yeah
[16:56:13 CEST] <dystopia_> it's running furq
[16:56:15 CEST] <furq> pcm_bluray is big endian
[16:56:45 CEST] <furq> i doubt the endianness makes a difference, it probably just can't find the codec tag
[16:56:59 CEST] <alexpigment> fair point
[16:57:07 CEST] <furq> but going to pcm_s24[bl]e is lossless anyway
[16:57:09 CEST] <atomnuker> alexpigment: not all television, only compressed one and uncompressed is already pretty much taking over
[16:57:21 CEST] <atomnuker> for studio-studio stuff
[16:57:36 CEST] <alexpigment> atomnuker: what television system do you know of that doesn't use TS?
[16:57:56 CEST] <atomnuker> uncompressed internal stuff
[16:58:13 CEST] <alexpigment> yeah, mxf and mov are big for intermediate stuff
[16:58:17 CEST] <alexpigment> i'm talking about deliverables
[16:58:29 CEST] <JEEB> raw streams over IP is what atomnuker is talking about
[16:58:39 CEST] <JEEB> within the broadcast studio to feed into encoders
[16:58:51 CEST] <JEEB> well, "studio"
[16:58:55 CEST] <alexpigment> that's fine; i just said that all television and all blu-ray use TS
[16:59:20 CEST] <alexpigment> which is really just to say that TS is a HUGE standard. it's not some weird format
[16:59:53 CEST] <atomnuker> it is a weird format
[16:59:57 CEST] <alexpigment> as a person who authors blu-ray discs regularly, i deal with it every single day
[16:59:59 CEST] <atomnuker> what sane format uses 188 byte packets
[17:00:20 CEST] <alexpigment> atomnuker: your opinions on this are really just misinformed. i'm done with this conversation
[17:01:02 CEST] <JEEB> (note: he works in broadcast so he has most definitely worked with the internals of MPEG-TS :D)
[17:01:07 CEST] <JEEB> or well, he *used* to work
[17:02:02 CEST] <dystopia_> that worked furq
[17:02:13 CEST] <dystopia_> but the output mkv is 800mb smaller than the source files
[17:02:23 CEST] <dystopia_> did i just loose meta data and stuff like that?
[17:02:25 CEST] <alexpigment> dystopia: you're probably missing some streams
[17:02:26 CEST] <furq> no
[17:02:32 CEST] <furq> that's normal for mpegts to mkv
[17:02:33 CEST] <alexpigment> unless it's a REALLY long file
[17:02:41 CEST] <dystopia_> ok
[17:02:46 CEST] <dystopia_> tyvm :)
[17:02:53 CEST] <furq> video:16784092kB audio:1292961kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 10.315392%
[17:02:59 CEST] <alexpigment> ah, nm then
[17:03:05 CEST] <furq> note the muxing overhead
[17:03:07 CEST] <alexpigment> lots of null packets i suppose
[17:20:58 CEST] <El_Porro> hello
[17:24:57 CEST] <El_Porro> is there any way to redirect output stream to an audio-video player like can do RTMPdump or other streaming tools ?
[17:32:23 CEST] <El_Porro> is there any link i can follow ?
[17:42:53 CEST] <porro> is there any way to redirect an output ffmpeg stream to an audio-video player ?
[17:48:06 CEST] <markmedes2> Friends, I'm trying to set the number of threads on ffmpeg, but it's not working. Do you know why?
[17:48:36 CEST] <alexpigment> markmedes2 - are you using the libx264 encoder?
[17:48:43 CEST] <markmedes2> yes
[17:48:49 CEST] <alexpigment> and i presume you're specifying -threads [#]
[17:48:54 CEST] <markmedes2> yes
[17:49:04 CEST] <alexpigment> no clue, then. that should work
[17:49:34 CEST] <markmedes2> I want to use less cores so I can keep using the machine, but it's always using all of them
[17:49:41 CEST] <alexpigment> oh
[17:49:50 CEST] <alexpigment> i don't think those two things necessarily correlate
[17:50:45 CEST] <alexpigment> having said that, how many threads are you specifying, how many logical cores do you have, and what CPU % is ffmpeg taking up?
[17:51:34 CEST] <markmedes2> I have 4 logical cores, intel i5. I'm asking ffmpeg to use 3 or less, I've specified 1 thread, 2 and 3, but it keeps using all four
[17:51:57 CEST] <markmedes2> pretty much 100% usage
[17:51:58 CEST] <alexpigment> is ffmpeg taking up 25% CPU when you specify 1 thread?
[17:52:08 CEST] <markmedes2> no, full 100%
[17:54:06 CEST] <alexpigment> i just verified i'm getting ~14% with 1 thread on my Core i7
[17:54:11 CEST] <alexpigment> what version are you using?
[17:54:52 CEST] <DHE> threading may be used in other ways than you specified. filtering, decoding, and encoding can all be threaded and each takes different args for how to specify the thread counts
[17:55:08 CEST] <markmedes2> version 3.3.2
[17:55:34 CEST] <markmedes2> oh, that's new info for me
[17:55:40 CEST] <alexpigment> DHE makes a good point. decoding shouldn't generally account for the rest of the 100%
[17:55:50 CEST] <alexpigment> but do you have any filtering going on?
[17:56:01 CEST] <markmedes2> yes, I'm scalling
[17:56:04 CEST] <alexpigment> libx264 itself will generally respect the thread count
[17:56:31 CEST] <markmedes2> is there a doc on how to use all those different args?
[17:57:23 CEST] <alexpigment> can you check to make sure it's sitting at around 25% when you take out the scaling?
[17:57:43 CEST] <markmedes2> no right, now, I'm currently encoding, should take some time
[17:58:37 CEST] <alexpigment> and just to be clear, ffmpeg itself is taking up nearly 100%, right? i want to make sure you're not looking at the overall CPU usage for your system
[17:58:50 CEST] <markmedes2> nope, it's ffmpeg alright
[17:58:54 CEST] <alexpigment> k
[17:58:59 CEST] <alexpigment> are you using lanczos scaling?
[17:59:02 CEST] <alexpigment> or bilinear?
[17:59:18 CEST] <markmedes2> -filter:v scale="640:trunc(ow/a/2)*2"
[17:59:29 CEST] <markmedes2> I'm on freebsd if that matters...
[18:00:36 CEST] <alexpigment> it very well could. that same filter on my brings my CPU usage up above 20% on average, so there is a penalty, but it's nowhere near what you're seeing
[18:00:54 CEST] <alexpigment> i'm on Windows. I can't test freebsd unfortunately
[18:01:01 CEST] <markmedes2> k
[18:02:03 CEST] <markmedes2> well, I'll test it again without scalling when econding is done. I have to go now. Thank you for tips.
[18:02:13 CEST] <thebombzen> DHE: how does one specify multiple threads for a filtergraph :O
[18:03:12 CEST] <jkqxz> There are a lot of things in ffmpeg that might create threads, including external libraries like libx264.  If the specific CPU use matters, you are probably better off controlling it externally by the tools your OS offers.
[18:03:37 CEST] <markmedes2> k
[18:03:53 CEST] <jkqxz> The internet suggests that taskset exists on freebsd.
[18:04:15 CEST] <markmedes2> cool
[18:04:20 CEST] <markmedes2> thank you
[18:04:27 CEST] <jkqxz> So set CPU affinity to the first three CPUs and no ffmpeg thread will ever run on the fourth one.
[18:05:50 CEST] <markmedes2> nice thx
[18:25:44 CEST] <relaxed> the power to serve
[18:54:41 CEST] <pgorley> hi, swr_convert's second parameter (in) is a decoded AVFrame's data, right?
[19:17:45 CEST] <LABcrab> Hi! I'm looking to use ffmpeg to output a Theora file, as ffmpeg2theora doesn't work with RAW files for me.
[19:18:33 CEST] <BtbN> Why do you want to use theora? It's... not good
[19:18:48 CEST] <LABcrab> BtbN, it works well on PowerPC.
[19:19:07 CEST] <BtbN> and h264 or vp9 doesnt?
[19:19:19 CEST] <LABcrab> Namely, the G4 Mac. The quality is fine for me. I'm converting from a raw VHS recording in any case.
[19:19:45 CEST] <LABcrab> It's for use with TenFourFox, which doesn't natively support H264.
[19:20:21 CEST] <BtbN> no idea how software decode compares there
[19:21:01 CEST] <LABcrab> It works wonders on 360p.
[19:21:25 CEST] <thebombzen> LABcrab: if you have ffmpeg compiled with libtheora support, you can use the standard ffmpeg syntax
[19:22:09 CEST] <thebombzen> ffmpeg -i input_file -c:v libtheora -b:v VIDEO_BITRATE -c:a libvorbis -q:a 5 output.ogv
[19:22:32 CEST] <LABcrab> Is there such a thing as -q:v? If so, is there something around 3Mbit/s?
[19:22:47 CEST] <LABcrab> 3Mbytes/s is what I meant.
[19:22:52 CEST] <thebombzen> Only if the video encoder supports VBR encoding. I have no idea if libtheora does
[19:23:26 CEST] <thebombzen> You might be able to get away with some -qp:v N, but I recommend just setting the bitrate to 3M if you want that
[19:23:40 CEST] <thebombzen> You can use 2-pass encoding to make it better
[19:23:57 CEST] <LABcrab> ffmpeg -i 1.avi -vcodec libtheora -acodec libvorbis -q:a 6 -b:v 3072k -vf "scale=640:480, crop=640:360, yadif" ~/Desktop/Movie.ogv
[19:24:26 CEST] <thebombzen> You should use -c:v or -codec:v, and -c:a or -codec:a
[19:24:33 CEST] <thebombzen> simply because vcodec and acodec are deprecated
[19:24:44 CEST] <thebombzen> they're not wrong, but good habits are to use new syntax
[19:24:51 CEST] <LABcrab> Yeah. Shorter, too.
[19:24:55 CEST] <thebombzen> also, ffmpeg supports -b:v 3M
[19:25:09 CEST] <LABcrab> How would I add two-pass?
[19:25:10 CEST] <thebombzen> Also, if you're going to deinterlace it, you should do that first
[19:25:26 CEST] <LABcrab> Thus yadif, scale, crop.
[19:25:33 CEST] <BtbN> you deinterlace last.
[19:25:36 CEST] <BtbN> after scaling
[19:25:37 CEST] <thebombzen> really what
[19:25:44 CEST] <thebombzen> but doesn't ffmpeg smudge the scanlines together
[19:26:03 CEST] <BtbN> iirc scale is interlacing aware. But you still do it first, for better quality
[19:26:17 CEST] <BtbN> I meant in that commandline, not how to to it properly
[19:26:21 CEST] <thebombzen> OH
[19:26:24 CEST] <thebombzen> okay I was really confused
[19:26:32 CEST] <BtbN> It should work though
[19:26:38 CEST] <thebombzen> yea LABcrab we mean Yes, you should yadif, scale, crop
[19:26:40 CEST] <BtbN> but the other way around is better
[19:27:23 CEST] <thebombzen> LABcrab: Also, consider using zscale instead of scale if your FFmpeg has zimg support compiled in
[19:27:34 CEST] <thebombzen> otherwise just use scale
[19:27:44 CEST] <LABcrab> It's the ffmpeg in OS X on Intel.
[19:27:56 CEST] <BtbN> OSX has ffmpeg?
[19:27:59 CEST] <BtbN> like, on its own
[19:28:09 CEST] <thebombzen> the easiest way to check is to try using -vf zscale and if it complains that it can't find the filter, then go back to scale
[19:28:20 CEST] <thebombzen> ffmpeg -f lavfi -i testsrc -vf zscale -f null -
[19:28:23 CEST] <thebombzen> what does this say?
[19:29:02 CEST] <thebombzen> either way, to answer your earlier question on how to do 2-pass, you should try this:
[19:29:27 CEST] <LABcrab> It seems like a lot of work to convert an AVI from a VHS.
[19:29:42 CEST] <thebombzen> Not quite, we just don't know what you have available to you
[19:30:19 CEST] <LABcrab> I added ffmpeg. :-)
[19:30:36 CEST] <LABcrab> I installed it from the binaries online. Same with ffmpeg2theora.
[19:31:35 CEST] <thebombzen> for two-pass, do this: ffmpeg -i input -vf yadif,scale=640:480,crop=640:360 -c:v libtheora -b:v 3072k -an -pass 1 -f null -
[19:31:37 CEST] <thebombzen> that's the first pass
[19:32:13 CEST] <thebombzen> then: ffmpeg -i input -vf yadif,scale=640:480,crop=640:360 -c:v libtheora -b:v 3072k -c:a libvorbis -q:a 5 -pass 2 output.ogv
[19:45:06 CEST] <LABcrab> [libtheora @ 0x7f8a53010200] theora_encode_YUVin failed (encoder is not ready or is finished) [-10]
[19:45:06 CEST] <LABcrab> Video encoding failed
[19:45:06 CEST] <LABcrab> [libvorbis @ 0x7f8a53011400] 36 frames left in the queue on closing
[19:45:06 CEST] <LABcrab> Conversion failed!
[19:45:15 CEST] <LABcrab> However, the video plays just fine.
[19:52:19 CEST] <applepi> Hi all..  I am using node-rtsp-stream to stream an RTSP stream over a websocket (it uses ffmpeg behind the scenes.)  When letting it run on my server, the size= output continues to grow and grow, it starts at about 2000KB and eventually starts causing issues around 6.5GB.
[19:52:28 CEST] <thebombzen> LABcrab: what version of FFmpeg are you using?
[19:52:30 CEST] <applepi> Any thoughts on what could be causing this?
[19:52:32 CEST] <thebombzen> what version of libtheora?
[19:53:24 CEST] <BtbN> that sounds like exactly what I'd expect to happen?
[19:53:36 CEST] <BtbN> If you keep streaming video, the size just gets bigger and bigger
[19:53:38 CEST] <thebombzen> applepi: size= ist he total number of bytes encoded
[19:53:51 CEST] <thebombzen> it's not the bitrate
[19:54:11 CEST] <thebombzen> it growing nonstop is expected behavior. if it stopped growing that would be essentially a freeze
[19:54:43 CEST] <thebombzen> LABcrab: that sounds like a bug in the theora encoder or wrapper. what version are you using of FFmpeg?
[19:55:37 CEST] <applepi> Ahh, hm, I haven't had time to start it again but I was concerned it was actually just growing continuously in RAM, not just keeping track of how much it's encoded over time.
[19:55:57 CEST] <applepi> * well, I've started it again, but it was just a few minutes ago
[20:00:07 CEST] <thebombzen> yea, ffmpeg doesn't keep track of the total amount of ram it uses in various places
[20:00:32 CEST] <thebombzen> but it's only a single process, so you can figure that out elsewhere
[20:01:05 CEST] <LABcrab> I have 3.3.2
[20:03:18 CEST] <Mista_D> Hi, is there any filter to mark audio encoding, identifying audio btrates when streaming adaptive audio please?
[20:09:03 CEST] <thebombzen> LABcrab: do the last 36 frames of the video play just fine? just wondering. if you dont' care then yay!
[20:09:13 CEST] <thebombzen> but otherwise we'll have to debug that
[20:09:33 CEST] <LABcrab> I concatenate two files together anyway. The video plays just fine. I'm sure the 36 last frames are black.
[20:09:51 CEST] <thebombzen> alright cool
[20:09:58 CEST] <LABcrab> If you're interested, I can send you a link. It's about 95 MB, though.
[20:22:12 CEST] <thebombzen> not worth it enough to me
[20:23:10 CEST] <LABcrab> Okay.
[20:23:45 CEST] <LABcrab> In HTML5, does the video only download when "Play" is clicked, or is it cached when my page loads?
[20:23:57 CEST] <BtbN> that's entirely up to your browser
[20:23:58 CEST] <LABcrab> I'm assuming the former.
[20:24:08 CEST] <BtbN> Firefox and Chrome alone behave vastly different
[20:36:26 CEST] <LABcrab> Thanks for the help. Have a nice day.
[22:23:54 CEST] <c7j8d9> when I copy a vp9.2 webm video to a mkv container the file size reduces in half. Is this normal?
[22:24:25 CEST] <JEEB> can you play it and get exact same amount of pictures out?
[22:24:31 CEST] <JEEB> s/play/decode/
[22:26:24 CEST] <c7j8d9> hadn't tried that. was just curious if it was normal. it was the same with mp4
[22:28:57 CEST] <kerio> when you say "copy"...
[22:29:53 CEST] <c7j8d9> -c copy
[22:29:56 CEST] <c7j8d9> remuxing
[22:36:36 CEST] <JEEB> c7j8d9: it's not normal for any track to go down in size significantly unless the bit rate is very very small. which is why I recommend doing something like `ffmpeg -i input -f null -` for both input and output clips
[22:36:45 CEST] <JEEB> which will decode them and do nothing with the output
[22:36:52 CEST] <JEEB> (throw them to "null")
[22:44:26 CEST] <paveldimow> Hi, does anyone here know how timecodes (timestamps) actually work? It's not specific ffmpeg question but I don't know a better place to ask
[22:45:09 CEST] <JEEB> paveldimow: you have PTS and DTS and a time base
[22:45:22 CEST] <JEEB> time base is how many ticks is one thing (second)
[22:45:40 CEST] <JEEB> and PTS and DTS are the presentation and decoding time stamp on that time base
[22:45:41 CEST] <JEEB> that's it
[22:46:06 CEST] <paveldimow> well that's it for someone who knows much more then me :)
[22:46:17 CEST] <paveldimow> but let me ask you a more direct question
[22:47:28 CEST] <paveldimow> what I would like to do is to have one incoming stream (let it be rtmp) that contains both audio and video that are in sync.
[22:47:48 CEST] <c7j8d9> JEEB: of course when I tried remuxing again they were the same size. thanks for the help
[22:48:32 CEST] <paveldimow> now, I have another incoming audio stream which for example is 5 sec late and I want to mix AND sync that audio with video coming in the first stream
[22:48:51 CEST] <paveldimow> is something like this technically possible?
[22:49:25 CEST] <JEEB> yes, you just have to adjust the timestamps accordingly on one or the other source's tracks
[22:49:36 CEST] <JEEB> if you know the actual difference it's all possible :P
[22:50:20 CEST] <paveldimow> heh ok, fair enough ;)
[22:51:35 CEST] <paveldimow> thank you JEEB I will take a closer look at this since I am coming from cisco network space :)
[22:51:45 CEST] <paveldimow> I will have a lot to learn
[22:51:51 CEST] <paveldimow> thank you once again
[22:52:50 CEST] <paveldimow> almost to forgot the main question
[22:54:01 CEST] <paveldimow> beside ffmpeg are there any tools that are low level with gui which I can you to inspect mpeg2, mpeg4 and mpeg ts ? something like wireshark for mpeg
[22:55:01 CEST] <JEEB> I don't think a GUI is needed if the output is good enough and fits a less buffer :) but for MPEG-TS I am using https://sourceforge.net/projects/dvbinspector/files/?source=navbar
[22:55:34 CEST] <JEEB> for MPEG-4 Part 12 I utilize L-SMASH's boxdumper with the --box parameter (and output to a less buffer which I can scroll through)
[22:56:12 CEST] <JEEB> for very basic inspection ffmpeg/ffprobe are already quite useful
[22:57:12 CEST] <c7j8d9> mediainfo works well and looks good too
[22:57:42 CEST] <JEEB> that's similar to ffprobe, as in it doesn't go on the format specifics
[22:57:59 CEST] <paveldimow> thank you guys, much appreciated!
[22:58:03 CEST] <JEEB> also ffprobe can output data on all demuxed packets' general data, unlike mediainfo (and output as json)
[22:58:42 CEST] <JEEB> also mediainfo can tell you things that are not necessarily true more often. and then when someone asks why mediainfo shows something all I can reply is "I don't know, read the source code of mediainfo"
[22:59:06 CEST] <paveldimow> any book(s) you can recommend for newbie like me?
[22:59:28 CEST] <JEEB> I hear http://lurkertech.com/lg/video-systems/ is OK for a basic guide
[23:00:07 CEST] <paveldimow> you reply fast like google :)
[23:00:32 CEST] <JEEB> and then after you get through basics you can go for stuff like https://tech.ebu.ch/circles-of-confusion
[23:01:31 CEST] <JEEB> of course each format (container, video, audio, subtitle etc) is different
[23:02:23 CEST] <paveldimow> thank you!
[23:03:06 CEST] <JEEB> but the basics on what YCbCr is (in general terms), and that 99%+ of all video is YCbCr goes a long way
[23:03:18 CEST] <JEEB> you'd be surprised how many people think that video comes as RGB and just needs to be scaled or so ;)
[23:03:22 CEST] <JEEB> (After decoding)
[23:03:56 CEST] <JEEB> oh, and that limited (aka "TV") range is the de facto standard in video for YCbCr
[23:06:53 CEST] <paveldimow> hmmmm that's to much info for me I will start to cry :) I never heard of YCbCr or something similar
[23:07:13 CEST] <paveldimow> I am network guy, you know packets everywhere ;)
[23:07:28 CEST] <JEEB> think of Y as the greyscale version of your image, and Cb is chroma (color) blue, Cr is chroma (red)
[23:08:15 CEST] <paveldimow> and Y?
[23:08:20 CEST] <JEEB> luminance
[23:08:25 CEST] <JEEB> "greyscale version of your image"
[23:08:27 CEST] <paveldimow> oh a gray scale
[23:08:32 CEST] <paveldimow> grey
[23:08:33 CEST] <paveldimow> :)
[23:08:41 CEST] <JEEB> ugh, sorry about that
[23:08:44 CEST] <JEEB> getting late :P
[23:08:50 CEST] <paveldimow> np :)
[23:09:17 CEST] <paveldimow> hmmmm do you know if time codes are present in mpeg4 container?
[23:09:25 CEST] <paveldimow> or it's just in mpeg ts?
[23:09:33 CEST] <JEEB> timecodes or timestamps?
[23:09:47 CEST] <JEEB> timecodes usually mean SMPTE timecodes
[23:09:59 CEST] <JEEB> timestamps are just timestamps (PTS/DTS)
[23:10:21 CEST] <paveldimow> what confuses me from wikipedia
[23:10:23 CEST] <paveldimow> Transport Stream had been originally designed for broadcast. Later it was adapted for usage with digital video cameras, recorders and players by adding a 4-byte timecode (TC) to standard 188-byte packets, which resulted in a 192-byte packet.[11][12] This is what is informally called M2TS stream. The Blu-ray Disc Association calls it "BDAV MPEG-2 transport stream".[11] JVC called it TOD (possibly an abbreviation for "Transport stre
[23:11:33 CEST] <JEEB> non-standard stuff can call itself how it wants. I haven't checked what the 4 extra bytes in the 192 byte MPEG-TS contain :)
[23:11:44 CEST] <JEEB> some sort of timestamp, but if it's SMPTE timecode or not is E_NO_IDEA
[23:11:55 CEST] <paveldimow> :)
[23:12:07 CEST] <paveldimow> so it's non standard thing
[23:12:29 CEST] <JEEB> might be standardized in blu-ray specifications but I don't think it's in the MPEG-TS specification
[23:12:45 CEST] <JEEB> as long as it doesn't contain 0x47 it's compatible ;)
[23:12:55 CEST] <JEEB> (MPEG-TS packets start with 0x47)
[23:14:33 CEST] <paveldimow> and I can get a packet level view with dvb inspector?
[23:15:02 CEST] <JEEB> yes, MPEG-TS packet view
[23:15:21 CEST] <JEEB> ffprobe actually gets you each packet contained within the container with -show_packets option
[23:15:29 CEST] <JEEB> it's on a different level of abstraction :)
[23:15:54 CEST] <JEEB> *each stream packet contained within the container
[23:16:12 CEST] <JEEB> because you don't get each MPEG-TS packet, but then the data chunks within those packets
[23:17:22 CEST] <paveldimow> hmmmm so one data chunk contains multiple packets?
[23:17:44 CEST] <JEEB> MPEG-TS packets are 188 byte so you kind of have to often span multiple MPEG-TS packets :D
[23:18:02 CEST] <JEEB> and of course all the metadata is passed in MPEG-TS packets as well
[23:19:03 CEST] <paveldimow> understand
[23:20:33 CEST] <JEEB> like usually a few times a second you get a PAT, which explains what programs (think: separate sets of streams - "TV channels") there are in the stream, each of which will then also have a PMT coming (which then tells you how many streams there are in a specific program ("channel"))
[23:20:55 CEST] <paveldimow> what?
[23:21:02 CEST] <paveldimow> PAT?
[23:21:09 CEST] <JEEB> Program Association Table
[23:21:17 CEST] <paveldimow> is that in mpeg packets too?
[23:21:39 CEST] <JEEB> it's a type of MPEG-TS packet, yes
[23:21:41 CEST] <JEEB> :)
[23:21:49 CEST] <JEEB> I think it's the one that has ID 0x00 or so
[23:22:07 CEST] <paveldimow> type? what that means that there are multiple MPEG-TS packet types?
[23:22:33 CEST] <JEEB> ayup. they are all 188 byte long and start with 0x47, but the contents differ
[23:22:49 CEST] <JEEB> (and some contents span multiple packets)
[23:23:07 CEST] <paveldimow> wait
[23:23:57 CEST] <paveldimow> you said that all are 188 bytes and start with 0x47 but why did you say that PAT starts with 0X00 then?
[23:24:02 CEST] <JEEB> no
[23:24:06 CEST] <JEEB> the *id* is 0x00
[23:24:16 CEST] <JEEB> it's a field in an mpeg-ts packet ;)
[23:24:23 CEST] <JEEB> "pid"
[23:24:27 CEST] <paveldimow> aha that makes sense!
[23:24:29 CEST] <paveldimow> :)
[23:27:16 CEST] <JEEB> so you start reading data, wait until you get the 0x47 start code. then you try parsing the MPEG-TS packet, and ignore them until you find one with PID 0x00. then you will know the PIDs of PMT (Program Mapping Table) packets for all the currently registered programs in the stream. then you can wait for packets with that PID :D
[23:27:42 CEST] <JEEB> and it goes further like that
[23:28:06 CEST] <JEEB> PMT contains the PIDs for the tracks of a program, and their types if I recall correctly
[23:28:19 CEST] <paveldimow> hmmmm
[23:28:40 CEST] <paveldimow> it's pretty late here but I must ask you one more stupid question
[23:29:07 CEST] <paveldimow> ready steady go!
[23:29:10 CEST] <paveldimow> :)
[23:29:36 CEST] <paveldimow> how any decoder knows which pakets are in one "frame"
[23:30:07 CEST] <paveldimow> every frame has some kind of header?
[23:30:24 CEST] <paveldimow> how about timestamps? are they used for synchronization?
[23:30:39 CEST] <JEEB> do you mean decoder as in parser or an actual decoder?
[23:31:03 CEST] <paveldimow> actual decoder let's say player vlc for example ffplay or so
[23:31:37 CEST] <JEEB> usually decoders will take in full packets only so you have a parser before hand to build them up for you
[23:32:04 CEST] <paveldimow> how they know, hey here is the MPEG-TS packets that belongs to the same I frame?
[23:32:31 CEST] <paveldimow> but still how parser knows?
[23:33:04 CEST] <JEEB> well, in case of MPEG-TS there most likely is a field that says that the packet contains a part of a coded video/audio/subtitle packet
[23:33:32 CEST] <JEEB> and then you have a parser that parses raw coded frames and usually there's some way of knowing where the coded frame ends
[23:33:58 CEST] <JEEB> so the demuxer feeds the parser data and then the parser follows the standard to cut those into actual packets that you can feed into a decoder
[23:34:19 CEST] <paveldimow> and how/when synchronization jumps in place?
[23:34:35 CEST] <JEEB> every MPEG-TS packet I think has a 33 bit timestamp field
[23:35:04 CEST] <JEEB> and then a counter so you know if you had packet loss
[23:36:37 CEST] <JEEB> the timestamps in MPEG-TS were DTS if I recall correctly, so with less simple formats you have to decode the stream (or at least parse it) to start getting proper PTS.
[23:37:30 CEST] <paveldimow> rocket since for me for now ;)
[23:38:49 CEST] <JEEB> something like matroska or ISOBMFF (mpeg-4 container) have variable length packets (samples)
[23:38:53 CEST] <JEEB> which is simpler
[23:39:04 CEST] <JEEB> since you get <LENGTH><DATA>
[23:39:20 CEST] <JEEB> so if it's a coded video sample you just grab the data and pass it to a decoder
[23:41:41 CEST] <paveldimow> I'll take a look at matroska since I like that name :)
[23:41:58 CEST] <paveldimow> I can't understand anymore without sleep
[23:42:01 CEST] <paveldimow> :)
[23:42:22 CEST] <paveldimow> Thank you JEEB, it was a pleasure to chat with you!
[23:42:56 CEST] <paveldimow> you gave me a lot of explanations
[23:44:08 CEST] <paveldimow> it's still blurry to me, but much less for sure after this chat
[00:00:00 CEST] --- Fri Aug 11 2017