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

[burek]

[00:03:34 CEST] <CoJaBo> durandal_1707: bugtracker seems to be down..
[00:18:03 CEST] <aletorrado> Hi! I'm trying to specify codecs with the new dash muxer, but couldn't :(
[00:18:29 CEST] <aletorrado> (ffmpeg -i something -c:v vp9 -f dash output)
[00:22:40 CEST] <aletorrado> i'm getting "codec not currently supported in container" but dash is agnostic about codecs
[00:27:45 CEST] <jkqxz> Yes, DASH itself doesn't care.  But usually (and in this case) the fragments use MP4, which does.
[00:28:37 CEST] <aletorrado> yeap. It's nice the all-in-one-command dash muxer. It would be great to use other containers as well
[03:11:47 CEST] <Me4502> Hi, I'm using concat - and for every second text file I give it, I get "File-name: Invalid argument"
[03:12:01 CEST] <Me4502> http://pastebin.com/B68tKCfT
[03:12:10 CEST] <Me4502> That's an example of atext file that gives Invalid argument
[03:12:35 CEST] <Me4502> http://pastebin.com/FzGCTUZb - This one works fine
[03:15:26 CEST] <Me4502> ffmpeg -hide_banner -y -f concat -i filename.txt -c copy folder/main.mp4
[03:26:22 CEST] <ZeuZ> is anyone still around?
[03:27:31 CEST] <ZeuZ> http://pastebin.com/Su8Zaies --> what am I lacking while linking?
[03:43:10 CEST] <Me4502> http://pastebin.com/4usZSGPz
[03:43:14 CEST] <Me4502> That's my full output
[03:51:22 CEST] <Me4502> Okay, this is odd
[03:51:31 CEST] <Me4502> Once the main video reaches 42 frames, it starts occuring
[03:51:51 CEST] <Me4502> So it will only concatenate 42 frames before starting to fail
[03:54:13 CEST] <Me4502> ffmpeg is already the newest version (7:3.0.2-2) - that appears to be the actual latest acording to the website
[05:15:43 CEST] <drazin> anyone know a command or way to delete the first audiotrack from a directory of mp4 files?  i messed up the first audiotrack and need to re-do them but need to delete the tracks first
[06:18:44 CEST] <Admin__> good day ladies and gents.. i am segmenting source input into HLS output.. everything works well except sometimes the .ts segments run wild and do not break to the next segment file thus filling up the hard drive. Anyone know what causes this ? Is it some bug in the segmenting ?
[06:19:58 CEST] <Admin__> code is super simple : http://pastebin.com/raw/DDGrtxY6 .. i may even have a few things there that should not be there but its all while testing
[06:20:03 CEST] <Admin__> anyone have a clue?
[06:35:58 CEST] <Admin__> DHE , moment of truth
[06:36:13 CEST] <Admin__> 26.5 is about to roll over
[06:49:03 CEST] <Admin__> DHE , no luck
[06:49:20 CEST] <Admin__> still stopped working at exactly 26 hours and 30 minutes
[08:33:12 CEST] <ffmpegishard> Hey, I'm trying to cut out pieces of a video file, but the timing seems to be a bit wanky. I'm using MPC-HC with high precision timer enabled to find out when the segments I want to extract start and end
[08:34:10 CEST] <ffmpegishard> To test it, I tried to just extract the frame at the start and at the end using the command: ffmpeg -ss <start-time> -i <video file> -vframes 1 <output image file>
[08:35:17 CEST] <ffmpegishard> And that gives the correct results, but when I then try to do: ffmpeg --ss <start-time> -i <video file> -to <end-time> -c copy <output-videofile> it doesn't start on the same frame, but a little before it
[08:35:46 CEST] <ffmpegishard> thats -ss not --ss
[08:36:54 CEST] <ffmpegishard> The other problem is that it also seems that since I use -ss the -to option is then relative to the starting mark set at -ss, which is fine, because I can just subtract the end from the start and put that in, but the problem is the start point
[08:39:49 CEST] <ffmpegishard> When I tried to do: ffmpeg -i <video file>  -ss <start-time>  -to <end-time> -c copy <output-videofile>
[08:40:45 CEST] <ffmpegishard> It gets the right start time, but before the first video shows up there is a little pause where only the audio plays. I can solve this by adding -an, which then produces the correct timing, but I would like to know why the audio plays beforehand
[08:44:18 CEST] <ffmpegishard> I'm also very new to ffmpeg, so I don't really know, but I think it may have something to do with the "-c copy" part, because when I remove it, the previous command works: ffmpeg -i <video file>  -ss <start-time>  -to <end-time> <output-videofile>
[08:44:26 CEST] <ffmpegishard> But it's a lot slower
[11:05:11 CEST] <yagiza> Hello!
[11:06:29 CEST] <yagiza> Do anyone know, how to play with ffplay an RTP stream, streamed by ffmpeg with opus encoder?
[11:07:36 CEST] <yagiza> When I do:
[11:07:36 CEST] <yagiza> ffmpeg -re -f lavfi -i aevalsrc="sin(400*2*PI*t)" -c libopus -ar 8000 -f mulaw -f rtp -sdp_file out.sdp rtp://127.0.0.1:1234
[11:07:36 CEST] <yagiza> it starts streaming something
[11:11:21 CEST] <yagiza> Next, when I try:
[11:11:22 CEST] <yagiza> ffplay rtp://127.0.0.1:1234
[11:11:22 CEST] <yagiza> It says:
[11:11:22 CEST] <yagiza> [rtp @ 019029e0] Unable to receive RTP payload type 97 without an SDP file descr
[11:11:22 CEST] <yagiza> ibing it
[11:11:22 CEST] <yagiza> Input #0, rtp, from 'rtp://127.0.0.1:1234':
[11:11:22 CEST] <yagiza>   Duration: N/A, bitrate: N/A
[11:11:23 CEST] <yagiza> Failed to open file 'rtp://127.0.0.1:1234' or configure filtergraph
[11:11:23 CEST] <yagiza>     nan    :  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0
[11:12:22 CEST] <yagiza> Now, if I try
[11:12:23 CEST] <yagiza> ffplay out.sdp
[11:12:23 CEST] <yagiza> or
[11:12:23 CEST] <yagiza> ffplay -i out.sdp
[11:12:23 CEST] <yagiza> it says:
[11:12:23 CEST] <yagiza> [rtp @ 01915a60] Protocol not on whitelist 'file'!sq=    0B f=0/0
[11:12:23 CEST] <yagiza> out.sdp: Invalid data found when processing input
[11:12:35 CEST] <yagiza> What should I do?
[11:29:35 CEST] <jcdejong> hello, I recently upgraded ffmpeg to 3.0 and the -shortest option is acting strange for me since then.. instead of the expected 198 frames I get a video of 249 frames.. is this the right place I could find somebody who could help me?
[11:30:36 CEST] <jcdejong> I already spent a lot of time searching and debugging, and am kinda stuck.. So I hoped I could find someone here who could review what I did or point me in the right direction
[11:32:37 CEST] <jcdejong> here's a pastebin with my commands: http://pastebin.com/AK4SUC70 it looks like it has something to do with the .mov overlay I'm using (and which I want to cut of at the end of the input file)
[14:23:41 CEST] <ZeuZ> hey guys, where can I find in the docs/examples a snippet of using the concat from C?
[16:23:18 CEST] <Seekha> Hi, is there a way to straem a mpegts stream (with scrambled video) on UDP?  It seems not to work
[16:24:00 CEST] <Seekha> I do something like : ffmpeg -re -i myfile_.ts -vcodec copy -acodec copy -f mpegts udp://host:port
[16:24:07 CEST] <Seekha> (or withtout the -re)
[16:24:27 CEST] <Seekha> with non scrambled video it works... what I do wrong?
[16:42:28 CEST] <drazin> can anyone lead me to a script or a command that can set the disposition of audio tracks for multiple files without converting or processing anything?
[17:39:35 CEST] <CoJaBo> durandal_1707: So anyway, I finally did figure out how to reproduce that bug :/
[17:51:55 CEST] <yagiza> Still nobody, who knows how to play RTP stream with ffplay?
[17:59:23 CEST] <nucular> Hey, given a series of images as the input, how would I shift them by one frame (skip one frame and loop) without renaming files manually?
[18:16:59 CEST] <furq> nucular: probably -start_number 1
[18:29:06 CEST] <ATField> (hello) I am having problems with defining multiple force_style parameters. While both [-vf subtitles='D\:\\INPUT.ass':force_style="FontName='Gotham Black'"] and [-vf subtitles='D\:\\INPUT.ass':force_style="FontSize=22" "02 force style 790k,fontSize22.webm"] work fine, trying to combine them into [-vf subtitles='INPUT.ass':force_style="FontName='Gotham Black',FontSize=22"] seems to contain...
[18:29:08 CEST] <ATField> ...some syntax error because it confuses ffmpeg  it returns a  No such filter: 'FontSize'.
[18:29:40 CEST] <ATField> The problem seems to be with quotemarks, but no idea what order should be the proper one.
[18:30:06 CEST] <ATField> Can you help with some hints, please?
[18:31:04 CEST] <furq> force_style="FontName=Gotham Black,FontSize=22"
[18:31:07 CEST] <furq> looks like it should work
[18:33:23 CEST] <ATField> [-vf subtitles='D\:\\INPUT.ass':force_style="FontName=Gotham Black,FontSize=22"]  returned the same error (No such filter: 'FontSize' Error opening filters!).
[18:36:13 CEST] <furq> it works with single quotes
[18:40:28 CEST] <ATField> (its still rendering, but) Replacing them with single quotes seems to work if the fonts name doesnt have spaces (otherwise it gets confused again).
[18:41:32 CEST] <ATField> ( [ -vf subtitles='D\:\\INPUT.ass':force_style='FontName=Sylfaen,FontSize=22' ] )
[18:42:31 CEST] <furq> 'FontName="Gotham Black",FontSize=22' works
[18:42:40 CEST] <ATField> ok, adding double seemed to help
[18:42:40 CEST] <furq> the docs could probably use another example or two
[18:43:34 CEST] <ATField> I was trying it out when you posted it : p. Also, I thought in case of using multiple quote types at once, the doulbe-quotes were supposed to be the external pair? Or it depends on the syntaxs flavour?
[18:44:50 CEST] <ATField> Yeah, there was also a problem with defining .ass location: it needed a bunch of weird escape characters, like with drawtext.
[18:46:38 CEST] <ATField> One more thing: when I specify the font, it still ends up rendered in cursive \ Italics. Can I prevent this to force non-cursive?
[18:49:13 CEST] <WereCatf> I tried asking about this the other day, but got nothing useful, so I'll try again: is anyone using NVIDIA's NVENC via ffmpeg? Something has changed as it no longer works for me, no matter what I do. It used to work fine and I'm wondering if anyone else has the same issue or if someone knows what's wrong.
[18:55:25 CEST] <ATField> All right! It worked with the font I needed (sans the cursive) ! Thanks for help.
[18:55:53 CEST] <ATField> WereCatf: Why not ask on stackexchange? More people likely to see the question that way.
[18:56:37 CEST] <WereCatf> ATField: Um, because the problem is with ffmpeg and this is ffmpeg's IRC-channel?
[18:57:47 CEST] <ATField> I know, but the more exposure the better, right? The platform there would also improve readability for both sides (just saying).
[18:59:48 CEST] <Demon_Fox> Is there a page listing a great many common container formats (like ogg), that lists the supported media types they can contain?
[19:01:57 CEST] <ATField> Demon_Fox: Like this? https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
[19:03:53 CEST] <Demon_Fox> By chance, do you have a non-wiki link?
[19:05:30 CEST] <Demon_Fox> I'm writing up an explanation of codecs and containers for some people I know
[19:06:48 CEST] <kepstin> Demon_Fox: for many containers, there really isn't any definite list of supported codecs. And the ones that do have a list, it's scattered all over the places through various standards organizations and whatnot :/
[19:07:00 CEST] <Demon_Fox> I see
[19:07:04 CEST] <Demon_Fox> Thanks
[19:07:23 CEST] <furq> a lot of formats have unofficial extensions as well
[19:07:55 CEST] <kepstin> e.g. you can throw pretty much anything in avi if you make up a fourcc and install (on windows) a vfw codec that uses that.
[19:08:43 CEST] <Demon_Fox> I wonder how bad vlc is with this
[19:08:58 CEST] <furq> it'd be nice if `ffmpeg -h muxer=mp4` showed allowed codecs rather than just the defaults
[19:09:07 CEST] <furq> although that'd probably get a bit unwieldy for mkv and the like
[19:09:30 CEST] <CoJaBo> What other formats are there for piping uncompressed frames to ffmpeg?
[19:09:32 CEST] <kepstin> furq: yeah, but as we discovered last week, there's a function to see if a codec is supported in a container but most containers don't have it implemented :/
[19:09:48 CEST] <furq> there's obviously something in ffmpeg which checks, though
[19:09:57 CEST] <furq> otherwise it would let you mux anything into mp4
[19:10:04 CEST] <kepstin> many containers in ffmpeg do have a list of codecs that's checked in the open function
[19:10:24 CEST] <kepstin> but that's not a list of codecs the container supports, that's a list of codecs that ffmpeg knows how to mux into the container
[19:10:35 CEST] <Demon_Fox> I don't know of any formats that matroska doesn't support
[19:10:39 CEST] <furq> well that's usualy the same thing as far as an ffmpeg user is concerned
[19:10:40 CEST] <furq> +l
[19:10:50 CEST] <furq> and there are some subtitle formats which don't work with mkv
[19:10:55 CEST] <furq> at least not through ffmpeg
[19:11:01 CEST] <Demon_Fox> yeah...
[19:11:09 CEST] <WereCatf> That's not really a fault with the container-format, though, is it?
[19:11:16 CEST] <Demon_Fox> Thanks for all of the support :)
[19:11:21 CEST] <kepstin> (getting the check function to work should be simple for most containers in ffmpeg - factor out the checking code from the open function so it can be shared with the check function. SOmeone just needs to do it :/)
[19:11:32 CEST] <Demon_Fox> the format support that is :)
[19:11:37 CEST] <WereCatf> I was under the impression that you can use pretty much anything with Matroska if you wish, it's just up to the software to support it
[19:11:56 CEST] <Demon_Fox> Now I can use this to find what I'm looking for: "ffmpeg -h muxer=X"
[19:12:07 CEST] <furq> Demon_Fox: that just shows the default formats
[19:12:21 CEST] <furq> i.e. what you get if you specify a format but no codecs
[19:12:26 CEST] <Demon_Fox> I mostly just need the common one's
[19:12:29 CEST] <kepstin> one of the really tricky things about matroska is that it has support for storing anything that can be stored in AVI via a compatibility mode
[19:12:32 CEST] <Demon_Fox> supported by a given format that is
[19:12:43 CEST] <Demon_Fox> By the way, why was avi extended to support as much as it does?
[19:13:04 CEST] <furq> stupidity, i assume
[19:13:06 CEST] <CoJaBo> Because it's the only thing most players support lol
[19:13:16 CEST] <Demon_Fox> Seriously?
[19:13:17 CEST] <kepstin> Demon_Fox: avi is a really simple container, so it was pretty trivial to extend.
[19:13:22 CEST] <Demon_Fox> I see
[19:13:35 CEST] <CoJaBo> It would simply make too much sense to support a new format, therefore extending the existing one until it's buggy as all hell
[19:13:48 CEST] <Seekha> Someone has sucessfully transmitted a mpegts (with scrambled video) over UDP with ffmpeg ?
[19:13:57 CEST] <kepstin> you just pick a codec id ("fourcc") that nobody was using, and make codec for windows that registers to that, and then any windows player could play it.
[19:13:58 CEST] <furq> people preferred to hack up an existing container rather than use something like matroska which is designed for it
[19:14:13 CEST] <Seekha> Not scrambled it's ok, but when it's scrambled it doesn't transmit anything
[19:14:33 CEST] <Demon_Fox> I have some false assumptions about what supports what now
[19:14:39 CEST] <Fyr> guys, does s16le equal pcm_s16le?
[19:14:44 CEST] <furq> yes
[19:14:49 CEST] <Demon_Fox> I just kind of thought new format support for avi would be dead
[19:14:50 CEST] <Fyr> (for FFMPEG syntax)
[19:14:52 CEST] <Fyr> &
[19:14:53 CEST] <Fyr> ?
[19:14:55 CEST] <furq> Demon_Fox: that wiki link is the best thing i know of
[19:14:59 CEST] <furq> https://en.wikipedia.org/wiki/Video_file_format
[19:15:00 CEST] <furq> or that one
[19:15:38 CEST] <kepstin> well, the support for h264 and other codecs of similar vintage in avi is pretty hacky :/
[19:15:51 CEST] <furq> yeah i know avi has issues with vorbis audio
[19:15:55 CEST] <furq> which is why some dreadful people created .ogm
[19:16:48 CEST] <Demon_Fox> Hopefully soon, AV1 will take over when it's released
[19:16:55 CEST] <furq> av what now
[19:17:13 CEST] <Demon_Fox> Let me link it
[19:17:25 CEST] <Demon_Fox> http://aomedia.org/about-us/
[19:17:28 CEST] <Demon_Fox> oops
[19:17:37 CEST] <Demon_Fox> http://aomedia.org/
[19:17:50 CEST] <furq> are they making a container format as well
[19:17:54 CEST] <furq> that seems like a waste of time
[19:17:54 CEST] <Jan-> technical question: is the motion compensation the most time-consuming part of h.264 encoding?
[19:18:12 CEST] Action: kepstin notes that "av1" is nearly impossible to search for, since google autocorrects it to "avi"
[19:18:12 CEST] <Demon_Fox> Alliance for Open media is taking the existing next-gen open codecs and trying to make something with them and be done by 2017 and in use later that year
[19:18:28 CEST] <furq> i thought they were just making a new codec
[19:18:39 CEST] <furq> and then lying about it being production-ready by 2017 because there's no chance
[19:19:06 CEST] <Demon_Fox> It's mainly companies that are tired of being extorted by patent holders after already paying royalties
[19:19:32 CEST] <kepstin> yeah, supposed to be some new codec using ideas from stuff like vp9 and daala and whatnot?
[19:19:44 CEST] <furq> if they can even improve on vp9 i'll be impressed
[19:19:49 CEST] <furq> or rather, improve upon libvpx-vp9
[19:19:59 CEST] <Demon_Fox> vp8, vp9, Thor, Daala, and I think that's all
[19:20:05 CEST] <Demon_Fox> There might be more
[19:20:21 CEST] <Demon_Fox> However, I think the alternative name for av1 is supposed to be vp10
[19:20:33 CEST] <furq> oh are they the same thing
[19:20:37 CEST] <kepstin> hmm, daala had some neat stuff going on with the chroma-from-luma predictions and whatnot
[19:21:01 CEST] <kepstin> but it was all pretty experimental
[19:21:16 CEST] <furq> tbh i'd rather they finished writing their vp9 encoder
[19:21:41 CEST] <Jan-> hasn't the mpeg licensing organisation claimed that basically development of any codec is now impossible without their patents?
[19:21:58 CEST] <furq> yeah and turkeys have also claimed christmas sucks
[19:22:07 CEST] <Jan-> Boo. Cake.
[19:22:11 CEST] <Jan-> Oh no wait I mean, yay, cake!
[19:22:12 CEST] <CoJaBo> kepstin: Put it in quotes
[19:22:55 CEST] <kepstin> CoJaBo: i tried, but still didn't find anything useful :/
[19:22:59 CEST] <furq> have mpeg-la gone after vp8/9 yet
[19:23:00 CEST] <CoJaBo> kepstin: Queries like "av1" -"avi" is sometimes necessary too, as it ocasionally ignores the quotes
[19:23:08 CEST] <furq> i know they were threatening that they could do that if they wanted to
[19:23:25 CEST] <kepstin> hmm. I guess 'xvp8' is dead and gone now
[19:23:30 CEST] <Jan-> is it me or is google getting a bit scary these days
[19:23:36 CEST] <Jan-> it knows that "lemon meringue" is clearly "pie"
[19:23:55 CEST] <kepstin> furq: mpegla and google came to a settlement about vp8/9, iirc
[19:24:08 CEST] <Jan-> and "coach darla black neon" is "pink sneakers"
[19:24:10 CEST] <Jan-> this is strange
[19:24:21 CEST] <furq> oh so they did
[19:24:47 CEST] <furq> or they did for vp8 anyway
[19:25:51 CEST] <Demon_Fox> The development of any new video codec is not impossible without their patents
[19:26:02 CEST] <Demon_Fox> Daala doesn't even use standard DCT
[19:26:10 CEST] <furq> wasn't that what dirac was going for
[19:26:12 CEST] <Demon_Fox> It uses overlapping transforms like audio
[19:26:24 CEST] <furq> or is going for, if they're still working on it
[19:26:25 CEST] <Demon_Fox> dirac was wavelet transforms
[19:26:51 CEST] <furq> i meant about avoiding mpeg-la patents
[19:26:57 CEST] <Demon_Fox> Daala was a research project to actively defy the modern approaches to codecs
[19:28:01 CEST] <Demon_Fox> furq, They are doing all they can to avoid them, taking a lot of inspiration from opus
[19:28:31 CEST] <Demon_Fox> including some vector based prediction process
[19:28:52 CEST] <kepstin> if you're interested in the daala tech, reading through the tech demos on https://xiph.org/daala/ is kinda neat.
[19:29:18 CEST] <Demon_Fox> It's the neatest thing I've seen in a while
[19:29:49 CEST] <Demon_Fox> It's supposed to actually be competing with h.265 in file size
[19:30:19 CEST] <Demon_Fox> AV1 is supposed to just take the current open tech and turn it into something useful for right now while they develop
[19:31:55 CEST] <Demon_Fox> xiph and the alliance for open media are however implementing protective patents
[19:32:23 CEST] <Demon_Fox> Basically, patenting the new techniques and using an open no-royalty license for their contents
[19:35:12 CEST] <Demon_Fox> Anyways, thanks for the wikipedia pages
[19:36:36 CEST] <kepstin> but yeah, I suspect that the folks working on "av1" are just gonna keep using the webm (matroska) container for it
[19:42:51 CEST] <WereCatf> I tried asking about this the other day, but got nothing useful, so I'll try again: is anyone using NVIDIA's NVENC via ffmpeg? Something has changed as it no longer works for me, no matter what I do. It used to work fine and I'm wondering if anyone else has the same issue or if someone knows what's wrong.
[20:06:20 CEST] <ATField> Where can I find a listing of all possible arguments for (subtitle) force_style? The Docs dont mention much about it, aside from FontName, PrimaryColour, and fontsize.
[20:09:36 CEST] <furq> ATField: i assume it accepts any ass format
[20:09:38 CEST] <furq> https://www.matroska.org/technical/specs/subtitles/ssa.html
[20:09:47 CEST] <furq> there's a list there although i don't know if it's complete
[20:12:15 CEST] <CoJaBo> What other formats are there for piping uncompressed frames to ffmpeg?
[20:13:26 CEST] <ATField> furq: Oh, that makes sense. Thanks.
[20:16:57 CEST] <ATField> It accepts a string containing ASS style format KEY=VALUE couples separated by ",".  I guess my brain just decided to ignore the plainly written text. x_x
[20:22:18 CEST] <f00bar80> http://vpaste.net/OypxP << I'm asking if this is a correct 2 Passes encoding script , or anything is missing
[20:30:00 CEST] <f00bar80> ppl any comment?
[20:38:08 CEST] <kepstin> f00bar80: m3u8 isn't an ffmpeg muxer, did you want segmented hls?
[20:38:47 CEST] <kepstin> for 2 pass you need to wait for the first pass to finish and write the stats file before starting the second pass with the same input
[20:39:06 CEST] <kepstin> I'm not sure what you're doing there, but running both at the same time certainly doesn't make sense...
[20:40:03 CEST] <f00bar80> kepstin: so how then I can run the 2 Passes in script ?
[20:40:25 CEST] <kepstin> remove the & at the end so it waits for one to finish before starting the second
[20:40:51 CEST] <kepstin> (obviously, if you're doing a live stream, 2-pass is impossible)
[20:40:54 CEST] <f00bar80> kepstin: you mean the & at the end of the first command , right?
[20:41:08 CEST] <f00bar80> kepstin: why it's impossible ?
[20:41:31 CEST] <kepstin> because in order to run the second pass, you need to wait for the first pass to finish
[20:41:41 CEST] <kepstin> then do a second encode of the exact same source data
[20:41:57 CEST] <f00bar80> kepstin: if it's the case .. then what can be an alternative for the pass , regarding quality enhancement for live streaming ?
[20:42:48 CEST] <f00bar80> kepstin: and doesn't by removing & in the first pass, gonna to work it out that way you meantioned?
[20:42:50 CEST] <kepstin> f00bar80: you have to define the exact requirements of the live streaming - what bitrate, etc. do you need. In some cases (e.g. lan streams) you can maybe use -crf mode, but most of the time you're gonna be stuck with 1-pass mode.
[20:43:20 CEST] <kepstin> f00bar80: it depends exactly what your source is whether that would work
[20:43:30 CEST] <f00bar80> I have the bit rate already defined ..
[20:43:54 CEST] <kepstin> if you play that source stream, then wait 10 minutes, then play the source stream again, does it play the exact same thing both times?
[20:44:06 CEST] <f00bar80> kepstin: it's a mpegts , that's the source
[20:44:29 CEST] <kepstin> so is the source live? or is it a pre-recorded file?
[20:44:31 CEST] <f00bar80> kepstin: , no ..  it does play a live content
[20:44:45 CEST] <kepstin> ok, then yes, doing 2-pass with that as a source would work fine.
[20:44:52 CEST] <kepstin> er wait
[20:44:58 CEST] <kepstin> if it's live, then no 2pass wouldn't work
[20:45:06 CEST] <f00bar80> :(
[20:45:20 CEST] <kepstin> to do 2-pass, you'd have to save a bunch of the content locally, then do the encode twice from your local file
[20:45:29 CEST] <f00bar80> kepstin: so which alternatives .. I do have then
[20:45:47 CEST] <kepstin> or just use a 1-pass mode if you need it to be done live/realtime
[20:46:17 CEST] <furq> use a higher bitrate or a slower preset
[20:46:21 CEST] <kepstin> (either -crf if you have no bitrate limits to worry about - e.g. high-speed lan, or use 1-pass bitrate)
[20:46:40 CEST] <furq> i assume from the vbv stuff that there is a bitrate constraint
[20:46:49 CEST] <furq> or that this command was copied from stackoverflow
[20:47:01 CEST] <f00bar80> yes there's a bitrate
[20:47:46 CEST] <CoJaBo> What other formats are there for piping uncompressed frames to ffmpeg?
[20:48:13 CEST] <furq> ffmpeg -formats | grep pipe
[20:48:50 CEST] <kepstin> CoJaBo: not sure what you mean; I normally use 'rawvideo' which can accept uncompressed frames in pretty much any pixel format you like.
[20:49:59 CEST] <CoJaBo> kepstin: It's a PITA tho, as I have to specify every parameter on both sizes of the pipe :/
[20:50:22 CEST] <f00bar80> being able to identify the better bitrate I have to use, is by try an error ? also preset slow vs superhigh how it affects the output quality ?
[20:50:55 CEST] <kepstin> f00bar80: pick the slowest preset you can which still encodes video fast enough for your application.
[20:51:41 CEST] <kepstin> and you identify the bitrate to used based on what you want the output for. If the output is for streaming video online, you pick a bitrate that fits in the network speed you have.
[20:52:33 CEST] <furq> CoJaBo: you could try yuv4mpegpipe
[20:52:40 CEST] <f00bar80> kepstin: so again 2 passes won't work in this case even by removing the & at the first pass ?
[20:52:57 CEST] <furq> assuming the frames are yuv and not rgb
[20:52:59 CEST] <CoJaBo> furq: Needs to be uncompressed RGB tho
[20:53:07 CEST] <furq> you're pretty much stuck with rawvideo then
[20:53:15 CEST] <CoJaBo> That really sucks :/
[20:53:24 CEST] <kepstin> f00bar80: no. the way 2-pass work is that once the first pass is done, it writes a stats file to disk. the second pass then at the start opens the stats file and uses it to make better decisions about how to encode the /same/ input video.
[20:53:57 CEST] <CoJaBo> furq: What is the pixel order on that?
[20:54:05 CEST] <CoJaBo> or is it settable
[20:54:07 CEST] <f00bar80> kepstin: so what that thing which doesn't allow that to happen ?
[20:54:31 CEST] <furq> CoJaBo: no idea, it doesn't seem to be documented anywhere
[20:54:52 CEST] <kepstin> your commands (if you ignore the other errors) would cause the second pass to start before the first pass completes, so it would give an error saying the stats file is missing. And since the source video is live, the input isn't the same, so the stats file is useless anyways.
[20:56:15 CEST] <f00bar80> kepstin: is the no way to make the second pass to wait till there's stats file? or cause this is a live stream , there'll be no stats file as it's always playing
[20:56:27 CEST] <furq> both
[20:57:22 CEST] <f00bar80> so the only option i have is to play with the bitrate and the preset values ?
[20:57:30 CEST] <furq> yes
[20:57:42 CEST] <CoJaBo> furq: My input stream is a sequence of bitmaps, which are bottom-up; is there a way to flip the video in ffmpeg if I need to?
[20:57:49 CEST] <kepstin> 2-pass mode is only usable for non-realtime applications where you have the complete video available in advance.
[20:58:00 CEST] <furq> CoJaBo: is it raw bitmap data or bmp files
[20:58:05 CEST] <furq> if it's the latter you can use image2pipe
[20:58:17 CEST] <CoJaBo> furq: image2pipe is broken
[20:58:27 CEST] <furq> oh
[20:58:32 CEST] <furq> what's wrong with it
[20:58:34 CEST] <CoJaBo> Bug 5598
[20:58:47 CEST] <CoJaBo> It crashes ffmpeg
[20:58:49 CEST] <furq> fun
[20:59:08 CEST] <CoJaBo> My problem is that I need a work-around till that's fixed :/
[20:59:39 CEST] <furq> is it really that big a problem to have to specify params twice
[20:59:41 CEST] <CoJaBo> And one of the comments already suggested it could be a "wontfix" issue for some weird reason :/
[20:59:43 CEST] <f00bar80> kepstin: what about using hls-flags delete-segments accompanied with bitrate/preset?
[20:59:56 CEST] <furq> that doesn't make any difference
[20:59:59 CEST] <CoJaBo> furq: It sorta is; >_>
[21:00:13 CEST] <f00bar80> kepstin: this by any mean .. enhance quality?
[21:00:53 CEST] <kepstin> f00bar80: what 2-pass mode does is analyze the *entire length* of the video to decide which parts need more bitrate and which parts are ok with less. It only makes sense if have the *entire length* of the video saved on disk somewhere.
[21:01:56 CEST] <kepstin> f00bar80: the delete segments is irrelevant to video quality, that just frees up disk space if you don't need the entire output saved.
[21:01:59 CEST] <f00bar80> kepstin: and that ..can't be applied on live streams by anyway ? I assume that it's an important thing to be done
[21:02:50 CEST] <f00bar80> kepstin: "decide which  parts need more bitrate and which parts are ok with less
[21:02:58 CEST] <f00bar80> kepstin: i mean
[21:03:04 CEST] <kepstin> f00bar80: i'm not sure how you'd analyze the entire length of a live stream before you start encoding.
[21:03:15 CEST] <kepstin> without a time machine
[21:03:40 CEST] <CoJaBo> furq: In any case, I still need to flip the video, otherwise it'll come out upside-down
[21:04:00 CEST] <kepstin> furq: well, if the image2pipe stuff worked, the bmp decoder would take care of that :/
[21:04:07 CEST] <f00bar80> kepstin: so the only option ,.. is bitrate/preset try/error?
[21:04:11 CEST] <kepstin> er, CoJaBo ^^
[21:04:32 CEST] <kepstin> f00bar80: no trial and error for bitrate - you pick based on the requirements of your network.
[21:04:47 CEST] <kepstin> f00bar80: some trial and error on preset, you pick the slowest one that is still fast enough
[21:05:12 CEST] <furq> it's unlikely that you'll see any significant improvements with anything below slow
[21:05:40 CEST] <kepstin> anything below slow you'd need a really impressive system to get realtime anyways :)
[21:05:52 CEST] <furq> yeah especially with that number of streams
[21:07:15 CEST] <furq> f00bar80: you can probably reduce the audio bitrate a bit
[21:08:01 CEST] <CoJaBo> kepstin: Yes, but I can't use image2pipe at all :/
[21:08:42 CEST] <kepstin> CoJaBo: but yes, if you can get the image data into ffmpeg at all, you can flip it pretty easily with video filters.
[21:08:58 CEST] <CoJaBo> Yeh, but getting it there is hte hard part lol
[21:09:08 CEST] <furq> i take it you're stuck with bmp
[21:10:12 CEST] <CoJaBo> I could potentially convert to another uncompressed RGB, but not easily
[21:10:49 CEST] <CoJaBo> I can directly support PNG, but it's unbelievably slow, and JPEG, but the quality is awful
[21:11:27 CEST] <kepstin> hmm. you can't set the png compression down to minimum in hopes of making it faster? :/
[21:12:04 CEST] <kepstin> i guess most png encoders don't have an option to store completely uncompressed image data in png bitstream format ;)
[21:13:10 CEST] <CoJaBo> No option for quality, I'd have to write my own encoder
[21:13:33 CEST] <CoJaBo> It is possible to do uncompressed png, but I think the checksums would still murder me speed-wise
[21:13:52 CEST] <furq> have you tried bmp_pipe
[21:14:04 CEST] <CoJaBo> bmp_pipe is the same as image2pipe, apperently
[21:14:06 CEST] <furq> i'm guessing it's just an alternate name for image2pipe but it's not documented anywhere so i could be wrong
[21:14:20 CEST] <furq> nvm then
[21:14:28 CEST] <CoJaBo> yeh, and noe of this is documented >_>
[21:15:05 CEST] <CoJaBo> I'm guessing they's why they're so quick to suggest a wontfix, the feature I broke isn't even one that's documented D=
[21:15:11 CEST] <furq> you could just output raw bitmap data and use -f rawvideo which would at least save you the flip
[21:15:23 CEST] <furq> that's probably not the solution you want though
[21:15:43 CEST] <CoJaBo> I have to get the raw data by peeling it out of the bitmaps
[21:16:16 CEST] <CoJaBo> And there is a stupid amount of overhead for reading data in this thing
[21:16:48 CEST] <kepstin> do you have a bunch of bmp images on disk, or is some kind of in-ram thing?
[21:16:58 CEST] <CoJaBo> They're generated on-the-fly
[21:17:28 CEST] <CoJaBo> The app renders the image, converts it to BMP, then writes that bmp to a fifo
[21:19:13 CEST] <kepstin> CoJaBo: hmm. the image2pipe demuxer has an option 'frame_size' that takes a value in bytes. since the bmps are all gonna be the same size, you could try to set that maybe?
[21:19:24 CEST] <kepstin> as a workaround for the probe being weird
[21:19:56 CEST] <CoJaBo> kepstin: ..where did you even find that?
[21:20:19 CEST] <kepstin> ffmpeg -h demuxer=image2pipe
[21:21:14 CEST] <furq> i like how many help responses in this channel contain "you could maybe try"
[21:24:46 CEST] <CoJaBo> kepstin: It's really weird it doesn't set that automatically..
[21:25:08 CEST] <kepstin> CoJaBo: yeah, sounds like the bmp parser is horribly busted, at least when used with pipe input
[21:28:19 CEST] <CoJaBo> ............damn
[21:28:46 CEST] <CoJaBo> kepstin: Setting frame_size causes a memory leak; it just crashes a slightly different way :/
[21:29:43 CEST] <kepstin> the actual bmp decoder in ffmpeg works perfectly fine, it's just an issue with the bmp parser in image2pipe :/
[21:30:21 CEST] <kepstin> (I wrote the current 'gdigrab' code, which gets a stream of DIB (bmp) images from a windows api, and sends them to the bmp decoder inside ffmpeg)
[21:35:50 CEST] <CoJaBo> kepstin: Wait no, I screwed up
[21:36:04 CEST] <CoJaBo> kepstin: I put it after the -i; it works fine put at the proper place
[21:36:24 CEST] <CoJaBo> kepstin: Care to write a new one for image2pipe? =D
[21:36:26 CEST] <kepstin> hmm. I fond the current image2pipe code a bit hard to read, but it *looks* like it by default just reads the input in 4KiB chunks and passes that right to the decoder, rather than parsing the frame sizes and putting each complete frame into a buffer
[21:36:35 CEST] <kepstin> i'm surprised it works at all with any codec :/
[21:36:53 CEST] <CoJaBo> Where is that code located?
[21:37:03 CEST] <kepstin> libavformat/img2dec.c
[21:40:08 CEST] <kepstin> hmm. I guess the idea was they wanted to do as little parsing of the format as possible in the "demuxer" and rely on the decoder to be able to find frame boundaries
[21:40:34 CEST] <kepstin> which works on some of the more structured formats, but not with the bmp decoder :/
[21:41:44 CEST] <kepstin> so yeah, I guess there's two way to fix it - make image2 able to parse the images enough to figure out frame sizes, or make the bmp decoder less dumb so it knows how much data the frame's supposed to contain :/
[21:41:53 CEST] <CoJaBo> ..actually not sure how that could work with any piped image format :/
[21:42:07 CEST] <CoJaBo> Where is the bmp decoder?
[21:42:49 CEST] <CoJaBo> The total size of the bmp frame is literally offset 2 in the header...
[21:42:50 CEST] <kepstin> in the directory where all the codecs are, in files that contain the name of the codec in the filename.
[21:43:05 CEST] <CoJaBo> And there's even a cli parameter to set that size >_>
[21:43:32 CEST] <kepstin> I suspect it's bmp_parse.c where the real fix is needed.
[21:43:49 CEST] <CoJaBo> bmp_parser.c?
[21:43:57 CEST] <kepstin> but that does attempt to read the actual frame size...
[21:43:58 CEST] <kepstin> yeah
[21:45:45 CEST] <CoJaBo> ..yeh, I see that too. It reads the size, but then why is it acting like it isn't?
[21:49:21 CEST] <kepstin> man, this bmp parser code is hard to read. no comments, and it's storing a bunch of state all mashed up into a uint64 in non-obvious ways
[21:50:56 CEST] <CoJaBo> ..yeh, I can't figure out what any of those if blocks are doing
[21:51:37 CEST] <CoJaBo> if I knew what all those parameters were and what the output needed to be, I'd rewrite the thing from scratch myself >_>
[21:53:58 CEST] <WTDs> Hello, I'm new on the chat and to ffmpeg too. I have a problem demuxing VOB file to mpeg. I try to archive our family dvds with no losses in quality. I figured I can cat all the VOB files together then run them through ffmpeg -codec copy to demux/fix timestamps. But i got one DVD this didnt worked, getting error messages "Non-monotonous DTS in output stream" Do any of you know why could it be?
[21:54:27 CEST] <f00bar80> on a 4 cores cpu i can run 16 h.264 simultaneous encoding safely ?
[21:56:30 CEST] <kepstin> WTDs: hmm. you probably tried to combined vob files from different dvd titlesets. You should concatenate e.g. the files named VTS_01_{01,02,03,..}.vob to one file, then VTS_02_{01,02,03,...}.vob to another.
[21:57:59 CEST] <kepstin> er, VTS_XX_{1,2,3,...}.VOB - I forgot that the second number only has 1 digit not 2 :)
[21:59:14 CEST] <kepstin> f00bar80: depends a lot on the type of cpu, but you'll probably have to use a pretty fast x264 preset to pull that off realtime (which means lower quality)
[22:01:13 CEST] <f00bar80> kepstin: what do you mean by fast x264
[22:01:47 CEST] <kepstin> f00bar80: I said "fast x264 preset", you missed a word.
[22:02:27 CEST] <f00bar80> kepstin: so preset superfast , right?
[22:02:44 CEST] <kepstin> f00bar80: for that kind of encoding job, I'd either go with a higher-end many core server chip (xeon) or *maybe* consider using nvidia quadro cards. Either way, expensive hardware, needs a lot of testing to find the right balance.
[22:02:56 CEST] <kepstin> f00bar80: you have to try and see. I don't have your machine!
[22:40:54 CEST] <ChocolateArmpits> 5% load per encode at best
[22:41:38 CEST] <ChocolateArmpits> I don't imagine coding hd streams at the level
[23:13:31 CEST] <grrk-bzzt> Hello
[23:14:21 CEST] <grrk-bzzt> Is FFV1 supposed to have a good compression ratio, or is it just supposed to be a little less heavy than rawvideo?
[23:15:43 CEST] <kepstin> ffv1 should have fairly good compression on many types of videos. It's often used as a video archival codec.
[23:16:35 CEST] <grrk-bzzt> I had a screen recording using x265 lossless which had more than 5hours of nothing (plain black) and it compressed very well (<100 MBytes) and when converted to FFV1 it jumped to a 3GB file
[23:17:16 CEST] <grrk-bzzt> So I don't know if I'm not using the correct settings
[23:17:26 CEST] <furq> ffv1 is intra-only so it's not well-suited to that kind of material
[23:17:33 CEST] <grrk-bzzt> Alright
[23:19:47 CEST] <kepstin> huh, I thought it actually supported some non-intra mode? or at least gop size >1?
[23:19:57 CEST] Action: kepstin doesn't know much about the codec itself tho
[23:36:38 CEST] <DHE> keep in mind x264/5 lossless requires attention on your part to ensure the colourspace isn't reduced to yuv420 first
[23:37:22 CEST] <CoJaBo> DHE: Latest versions seem to default to 444 (if converting from RGB, anyway)
[23:37:44 CEST] <CoJaBo> Threw me for a loop, older ones would assume 420 (not much supports 444 >_>)
[23:38:14 CEST] <CoJaBo> 11.5×14
[23:39:14 CEST] <grrk-bzzt> DHE, I'm working with retrogaming videos. Usually there's two cases. Either the pixel format is pal8, or I'm using it for screen recording. In either case, I'm using the following options: -flags +bitexact -sws_flags +full_chroma_inp+accurate_rnd+bitexact -fflags +bitexact -pix_fmt yuv420p
[23:39:46 CEST] <grrk-bzzt> s/either/both
[00:00:00 CEST] --- Tue May 31 2016