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

Thu Oct 3 03:05:02 EEST 2019

[00:57:17 CEST] <k-man> how do i do something like ffmpeg -i "concat: *.mp3" .... ?
[00:57:46 CEST] <cehoyos> Either use the concat demuxer or the concat filter, see the documentation
[00:58:16 CEST] <cehoyos> (The concat protocol may work but should lead to audio artefacts for "real" mp3 files with headers)
[00:59:19 CEST] <furq> k-man: on linux, printf "file %q\n" *.mp3 | ffmpeg -f concat -protocol_whitelist file,pipe -safe 0 -i -
[00:59:32 CEST] <k-man> furq: ah right
[00:59:44 CEST] <k-man> so I can't really do the glob in the ffpmeg command directly
[00:59:49 CEST] <furq> no
[00:59:55 CEST] <k-man> furq: thank you
[01:00:28 CEST] <furq> the concat protocol won't work right with mp3 anyway because of id3 tags etc
[01:00:44 CEST] <cehoyos> The decoder should "eat" most of the tags
[01:00:50 CEST] <k-man> ah good point
[01:00:58 CEST] <furq> does the protocol decode
[01:01:23 CEST] <cehoyos> But audible artefacts are possible
[01:01:35 CEST] <furq> i thought it basically just did cat *.mp3
[01:01:46 CEST] <cehoyos> That's what it does (not just basically)
[01:01:55 CEST] <furq> wait nvm i'm dumb
[01:02:03 CEST] <cehoyos> But the decoder should have a high error resilience
[01:02:04 CEST] <furq> i forgot you don't have to copy
[01:02:13 CEST] <furq> right
[01:02:33 CEST] <cehoyos> And the original mp3 could be raw...
[01:02:44 CEST] <cehoyos> without any tags
[01:02:52 CEST] <furq> well you'd still have wrong duration headers etc
[01:03:01 CEST] <furq> but presumably the decoder can cope with that
[01:03:06 CEST] <k-man> my goal is to convert to m4b also
[01:03:12 CEST] <cehoyos> I don't think an original mp3 contains a duration header
[01:04:37 CEST] <cehoyos> ffmpeg -i input -vn -acodec mp3 -f rawvideo -map 0:a:0 out
[01:04:46 CEST] <furq> oh yeah i guess that's in the xing header
[01:04:50 CEST] <cehoyos> produces a nice mp3 file that can be concatenated
[01:04:52 CEST] <cehoyos> yes
[01:05:14 CEST] <cehoyos> (This does not work for all audio encoders, particularly not for vorbis and friends)
[01:05:59 CEST] <furq> i'm not sure how else you'd get an mp3 with no xing header nowadays
[01:06:55 CEST] <furq> k-man: -f ipod out.m4b will get you a valid m4b file
[01:07:02 CEST] <furq> but it won't have chapters or anything like that
[01:07:17 CEST] <k-man> furq: yeah, i'm realising that
[01:07:23 CEST] <furq> i don't think you can do that with ffmpeg
[01:07:29 CEST] <furq> it's not just standard mp4 chapters or anything
[01:07:42 CEST] <k-man> furq: why is that better than -f mp4 out.m4b?
[01:07:45 CEST] <cehoyos> And above is identical to: ffmpeg -i input -vn -id3v2_version 0 -write_xing 0 out.mp3
[01:08:15 CEST] <furq> ipod has different defaults than mp4 that are supposed to be for m4a
[01:08:20 CEST] <k-man> apparently you can do something with chapters and metadata? https://ffmpeg.org/ffmpeg-formats.html#Metadata-1
[01:08:20 CEST] <furq> i couldn't tell you what any of them are right now
[01:08:38 CEST] <k-man> furq, nice, thanks
[01:08:45 CEST] <furq> and yeah i think that'll just write standard mp4 chapters
[01:08:53 CEST] <furq> (assuming there is a standard and it's not some itunes extension)
[01:08:59 CEST] <furq> but m4b metadata is a totally different thing
[01:09:08 CEST] <k-man> furq, is it?
[01:09:14 CEST] <furq> i'm pretty sure it is
[01:12:20 CEST] <furq> i might be thinking of something else actually
[01:12:24 CEST] <furq> someone in a forum post claims it works anyway
[01:19:28 CEST] <k-man> what am I doing wrong here? http://ix.io/1NEG
[01:22:49 CEST] <furq> add -vn after -i
[01:23:20 CEST] <k-man> thank you
[01:24:19 CEST] <k-man> disable video in the output right?
[01:32:58 CEST] <brimestone> how can I use the output of av_dump_format so I can store the the output on Standard Error to a "String" or better yet to a struct
[01:34:45 CEST] <klaxa> don't think you can really, it writes to stderr
[01:35:06 CEST] <klaxa> with av_log()
[01:35:32 CEST] <brimestone> klaxa: how would I access a specific value pair?
[01:36:40 CEST] <klaxa> which one?
[01:36:59 CEST] <brimestone> Well, fps, fmt_pix, timecode
[01:37:31 CEST] <klaxa> i think av_dump_format() just accesses AVFormatContext fields
[01:38:20 CEST] <klaxa> and for that stuff you need an AVStream
[01:38:46 CEST] <klaxa> see dump_stream_format() maybe?
[01:39:52 CEST] <brimestone> im sooooo close...
[01:43:05 CEST] <brimestone> I think I found it!
[01:45:26 CEST] <klaxa> for pixel format you will need AVFormatContext->streams[i]->codecpar->format
[01:47:21 CEST] <klaxa> that will be an int which correspends to an AVPixelFormat Enum
[01:47:28 CEST] <klaxa> *enum
[01:51:50 CEST] <brimestone> how about timecode?
[01:52:09 CEST] <klaxa> what do you mean by that?
[01:52:16 CEST] <brimestone> I see some video codec stores timecode on the Format header but some of them stores in on the stream
[01:53:04 CEST] <klaxa> what kind of timecode is it though? creation? duration?
[01:53:11 CEST] <brimestone> https://gist.github.com/brimestoned/728b975a913c16c74a1c65e31c4ef46a line 417
[01:53:37 CEST] <klaxa> that's metadata
[01:54:14 CEST] <klaxa> it's custom to each file
[01:54:27 CEST] <klaxa> no idea what it is supposed to represent even
[01:54:54 CEST] <klaxa> unless it's a high resolution timestamp :P
[01:54:54 CEST] <brimestone> So that's not part of the [Stream] ?
[01:55:02 CEST] <klaxa> no
[01:55:35 CEST] <klaxa> as you can see each stream has its own "tags" object
[01:55:49 CEST] <klaxa> and the format (container) has one as well
[01:56:35 CEST] <brimestone> which I'm able to loop thru each stream and output its metadata.. but I don't know how to get to the Format part of it
[01:57:11 CEST] <brimestone> Yeah, how would I get a hold of the Format container?
[01:57:23 CEST] <klaxa> that's your AVFormatContext
[01:57:24 CEST] <klaxa> https://www.ffmpeg.org/doxygen/3.2/dump_8c_source.html#l00132
[01:58:53 CEST] <brimestone> fmtCtx.metadata direct?
[01:59:20 CEST] <klaxa> looks like it
[01:59:23 CEST] <brimestone> Wow! You're right! Its right there!
[04:24:56 CEST] <InkButton> i'm trying to encode a raw video before uploading to youtube, and i'm using the settings suggested here: https://gist.github.com/mikoim/27e4e0dc64e384adbcb91ff10a2d3678
[04:25:06 CEST] <InkButton> the encoding is going at 0.025x speed
[04:25:11 CEST] <InkButton> about 0.8 fps
[04:25:22 CEST] <InkButton> but its using virtually no CPU
[04:26:31 CEST] <InkButton> is there some way to make this faster without compromising quality? i want to get youtube to give me the VP9 codec for my videos, it seems ot always apply VP1 and makes my videos look like trash.
[04:29:15 CEST] <InkButton> my processor is i5-8500
[04:29:18 CEST] <furq> weird
[04:29:20 CEST] <furq> looks fine to me
[04:30:02 CEST] <furq> you can drop -coder 1, -bf 2, -g 30 and -b:a 384k
[04:30:09 CEST] <furq> and -profile:v high
[04:30:23 CEST] <furq> those are all either implied or just bad recommendations
[04:30:38 CEST] <furq> the defaults for all of those are either the same or better
[04:30:55 CEST] <furq> oh and -profile:a aac_low is default as well
[04:31:20 CEST] <furq> also whether youtube gives you vp9 or not has nothing to do with the source video
[04:31:33 CEST] <InkButton> ffmpeg -i /Volumes/Raid/sweetbunsvoiceover_1.mov -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -movflags +faststart -c:a aac ~/Desktop/sweetbuns-compressed.mp4
[04:31:37 CEST] <InkButton> >
[04:31:42 CEST] <furq> i'm pretty sure you'll get vp9 once the video hits a certain view count
[04:32:01 CEST] <furq> based on anecdotal evidence, because obviously google never release any info about this
[04:32:17 CEST] <InkButton> its running at 0.4x now which is quite a bit faster.
[04:32:26 CEST] <InkButton> still seems to be barely using my CPU
[04:32:35 CEST] <furq> yeah none of that would have fixed the cpu utilisation
[04:32:53 CEST] <InkButton> its fluctuating around 25% CPU usage nwo
[04:33:08 CEST] <InkButton> now* (maybe just using 1 core?)
[04:33:15 CEST] <furq> it shouldn't be
[04:33:21 CEST] <furq> unless you're getting thermal throttled or something
[04:33:42 CEST] <furq> or you have really slow disk read speeds
[04:34:00 CEST] <InkButton> thats possible, its pulling this file of a not particularly fast raid.
[04:34:27 CEST] <furq> if the bitrate figure in the ffmpeg output is accurate then that's only ~20MB/s
[04:34:32 CEST] <furq> so it'd have to be a very slow raid
[04:34:55 CEST] <furq> but i assume from the profile that it's lossless so maybe that figure is wrong
[04:35:28 CEST] <furq> also your source is aac so you should probably be using -c:a copy
[04:52:13 CEST] <InkButton> Hi furq, thanks for your help so far. i tried to reboot and see if that was it
[04:53:11 CEST] <InkButton> i'm still getting really low CPU utilization with: -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -movflags +faststart -c:a aac
[04:53:23 CEST] <InkButton> if i do just: -crf 18 -vcodec libx264
[04:53:30 CEST] <InkButton> it does full 100% CPU utilization
[04:53:45 CEST] <InkButton> with the input and output files in the same places both times
[04:53:50 CEST] <InkButton> so i guess this rules out a hard drive speed issue
[04:56:44 CEST] <InkButton> ok, acutall just confirmed the only flag that matters on whether or not it does the full CPU utilization is: "-preset slow"
[04:56:54 CEST] <InkButton> without that it goes at 100% CPU
[04:57:12 CEST] <InkButton> its not supposed to just mean "do this slower" is it?
[04:57:30 CEST] <InkButton> i figured it was actually doing something more computationally expensive, not just using less CPU
[05:01:48 CEST] <InkButton> strangely enough: -preset slower, is actually using 100% CPUn and running at lot FASTER than -preset slow.
[05:01:55 CEST] <InkButton> :shrug:
[05:04:01 CEST] <InkButton> LOL i spoke too soon. it WAS ripping along at 100% CPU and almost 1x, for the first 40 seconds of the video, now its slowed to a crawl, just like -preset slow.
[05:18:20 CEST] <kepstin> yeah, your bottleneck is somewhere other than the cpu, probably storage speed.
[05:18:44 CEST] <kepstin> x264 is really good at multithreading and using all the cpu if you aren't bottlenecked elsewhere
[05:20:30 CEST] <InkButton> ok. thanks. will try moving source file
[05:22:08 CEST] <kepstin> given the last thing you said, it might be the destination that's the issue, not the source
[05:22:17 CEST] <kepstin> (or that could have just been a caching effect)
[07:09:20 CEST] <InkButton> well thanks again for the advice earlier guys, turns out one of my disks is failing in that raid array
[07:09:27 CEST] <InkButton> good think i caught it when I did
[13:19:41 CEST] <termos> How would I go about selecting say the first input on the second DeckLink Quad card here? https://www.irccloud.com/pastebin/pexumCL3/
[13:21:56 CEST] <BtbN> iirc more than one card is not supported by the code as it is right now
[13:28:22 CEST] <termos> hmm okey, I see there's some querying of a unique name https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_common.cpp#L343 but not sure if it's used, that might even be the one that's printed
[13:35:49 CEST] <termos> https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=88995 found this, I can set the card names manually in BlackmagicDesktopVideoSetup and that seems to work well
[15:30:03 CEST] <jumping_jack> hello, so im using the following command to stream from my logitech usb webcam c270 : "ffmpeg -f dshow -rtbufsize 64M -i "video=Integrated Webcam" -s 1280x720 -f sdl2 -" ; im very new to ffmpeg so i dont know what all these args stand for but the problem is that the saved video has a resolution of 640 x 480 only. how can i change that
[15:30:14 CEST] <jumping_jack> specfically, set it to 1280 x 720 too
[15:31:22 CEST] <BtbN> you're telling it to scale whatever res it gets from the device to 720p
[15:32:13 CEST] <jumping_jack> BtbN, thank you for responding. but its setting the resolution to 640 x 480 ?
[15:32:55 CEST] <BtbN> That's probably what the camera defaults to
[15:33:15 CEST] <jumping_jack> BtbN, specifically, during the recording i (apparently) see the window size as the resolution, its the saved video that has the 640 x 480 resolution
[15:33:42 CEST] <BtbN> The command you pasted also does not record to anything
[15:34:40 CEST] <jumping_jack> BtbN, well yes i added a filename output.mkv to the command later which i forgot to include, the whole command looks like
[15:34:54 CEST] <jumping_jack> "ffmpeg -f dshow -rtbufsize 64M -i "video=Integrated Webcam" -s 1280x720 -f sdl2 - output.mkv"
[15:35:29 CEST] <BtbN> You are creating a second output file, with no options applied to it at all.
[15:35:38 CEST] <BtbN> all the options after -i apply to the sdl2 output
[15:36:01 CEST] <BtbN> also, -s will only scale whatever res comes from the camera to 720p, you most likely don't want that.
[15:36:36 CEST] <jumping_jack> how do i apply a resolution option to my output mkv
[15:38:02 CEST] <BtbN> You set the resolution on the webcam input. Look at the dshow format doc to find out how.
[15:39:26 CEST] <jumping_jack> i am new to ffmpeg, i don't know much about video encoding, i just want the output file in 720p
[15:40:03 CEST] <BtbN> If the camera only outputs 640x480, there is little point in scaling it to 720p. Doing so will also stretch the image.
[15:40:35 CEST] <BtbN> So check the device options if it can record in a higher res
[15:41:02 CEST] <jumping_jack> when i recorded from the webcam using vlc, it did so in the resolution of "1280x960"
[15:41:35 CEST] <jumping_jack> i am pretty sure that it can record in 720p
[15:41:47 CEST] <BtbN> Have you tried reading the Wiki and documentation yet? https://trac.ffmpeg.org/wiki/DirectShow
[15:44:29 CEST] <jumping_jack> yes i have it on my screen and im trying to understand
[15:44:45 CEST] <jumping_jack> you said above that im ccreating a file with no input options applied to it at all
[15:45:12 CEST] <jumping_jack> does that mean i can give it a -s 1280 x 720 argument too after output.mkv ?
[15:45:22 CEST] <BtbN> Options always apply to the next input or output on the command line.
[15:45:30 CEST] <BtbN> so your Scaling-Command applies to the SDL output.
[15:45:42 CEST] <BtbN> And you have given no options for the mkv output, so it will use all defaults.
[15:45:53 CEST] <BtbN> But really, you do not want output scaling. You want to set the cameras resolution.
[15:47:03 CEST] <jumping_jack> ok, but i dont understand how vlc was able to record in 1280 x 960 by default ?
[15:47:35 CEST] <BtbN> You set it to that resolution probably.
[15:48:17 CEST] <jumping_jack> BtbN, no i didnt change anything
[15:48:23 CEST] <jumping_jack> thats what confuses me
[15:48:32 CEST] <BtbN> You must have set a resolution at some point.
[15:49:58 CEST] <jumping_jack> no i just went to open media, set device name to my cam and started recording
[15:50:38 CEST] <jumping_jack> BtbN, you also said above that i gave the mkv output no options, how do it give it options ?
[15:51:07 CEST] <jumping_jack> im sorry to be bugging you but its just that i dont much about video processing and i need to get this done
[15:51:36 CEST] <BtbN> You place them before it on the command line, but after any preceeding inputs/outputs
[15:52:05 CEST] <BtbN> You'll probably only want to set it to use libx264 and -crf 20 or something.
[15:52:32 CEST] <jumping_jack> so the options have to come 'after' output.mkv ?
[15:52:51 CEST] <BtbN> No?
[15:52:53 CEST] <BtbN> Before
[15:53:02 CEST] <BtbN> But after any preceding input or output.
[15:53:45 CEST] <jumping_jack> okay so could you please show me how a command giving explicit size to the output.mkv would look like in my case
[15:53:55 CEST] <BtbN> I can't, since I don't have dshow available to me.
[15:54:08 CEST] <BtbN> But the Wiki has a whole bunch of examples on how to set the devices resolution
[15:55:02 CEST] <jumping_jack> okay so i know im asking this thing in another way
[15:55:36 CEST] <jumping_jack> "ffmpeg -f dshow -rtbufsize 64M -i "video=Integrated Webcam" -s 1280x720 -f sdl2 -s 1280x720 - output.mkv"; is this where the size fits in ?
[15:58:32 CEST] <jumping_jack> nevermind, i figured it out
[16:00:06 CEST] <jumping_jack> ffmpeg -f dshow -video_size 1280x720 -i "video=Integrated Webcam" output.mp4 -f sdl2 -
[16:00:31 CEST] <jumping_jack> the above command worked for me
[16:01:00 CEST] <jumping_jack> i applied all the options to the video file first, then added sdl as a ""
[16:01:11 CEST] <jumping_jack> i applied all the options to the video file first, then added sdl as a "secondary output"
[16:25:41 CEST] <cards> doesn't ffmpeg have a direct built-in validation tool that only does validation (and so it does it fast)?  the only thing i can find is encoding a video to a null device, but this takes a lot more time due to the cpu work
[16:26:32 CEST] <cards> i would have figured either ffmpeg or ffprobe have a -validate switch
[16:27:07 CEST] <kepstin> i'm not sure what you'd expect a "validate" feature to do
[16:28:19 CEST] <kepstin> reading, demuxing, and decoding a file probably makes sense, and that's exactly what running ffmpeg with the null output does (it doesn't encode when using the null output unless you explicitly ask it to)
[16:28:54 CEST] <kepstin> (you might also want to add a -map 0 option so it reads all streams from the file instead of a subset)
[16:31:55 CEST] <furq> i guess something that just parses bitstreams and makes sure they're not obviously broken
[16:32:10 CEST] <furq> validate would be a bit of misnomer though because it would miss most problems
[16:32:36 CEST] <cards> i would like to catch bitflips if possible
[16:32:52 CEST] <cards> assuming each frame has some checking
[16:33:00 CEST] <DHE> sounds like a full decode of the video/audio would be required to do that, or at least enough work that CPU usage would be quite high doing so
[16:33:04 CEST] <furq> it doesn't but the hash muxer doesn't decode
[16:33:11 CEST] <furq> so you could just store those hashes somewhere and compare them
[16:33:35 CEST] <furq> unless "assuming" means you're using a format that does actually have frame checksums
[16:34:07 CEST] <cards> hmm.  maybe i was using some wrong command switches, because after several minutes it was predicting that it would take several hours to complete.  longer than the video's playback length
[16:34:59 CEST] <cards> furq: right.  if the format has frame checksums, does ffmpeg actually validate them or ignore them?
[16:36:02 CEST] <furq> it ignores them unless you set -err_detect crccheck
[16:36:20 CEST] <furq> that's a decoder option though
[16:36:31 CEST] <furq> so obviously implies decoding
[16:36:33 CEST] <cards> ah good to know
[16:37:16 CEST] <cards> so what would be a good commandline you recommend i use to validate a file, decoding only
[16:37:42 CEST] <furq> -err_detect crccheck -i foo -f null -
[16:38:15 CEST] <furq> or like crccheck+bitstream+buffer+explode+careful+aggressive if you want to go hog wild
[16:38:47 CEST] <furq> if you're just interested in bit flips and your codec has embedded checksums then just crccheck is fine
[16:39:38 CEST] <cards> thanks.
[16:39:46 CEST] <cards> i may just need to run this on a better cpu
[16:40:10 CEST] <kepstin> cards: share your command line? we can tell you if something's obviously wrong
[16:40:21 CEST] <cards> it's the same furq pasted
[16:40:39 CEST] <furq> what codec is it
[16:40:49 CEST] <cards> h264
[16:40:57 CEST] <kepstin> furq did not paste a complete command line, i want to see the whole thing.
[16:41:28 CEST] <kepstin> well, i suppose if you stick an "ffmpeg" on the front that is complete :)
[16:42:40 CEST] <cards> ffmpeg -v error -i foo.mp4 -f null - > error.log
[16:42:55 CEST] <kepstin> i'd expect that command to either be cpu-limited on the video decoder or io limited on your storage device.
[16:43:24 CEST] <cards> meaning it would only decode in realtime?
[16:43:35 CEST] <furq> maybe try with 2>error.log
[16:43:42 CEST] <furq> mostly because that'll actually work
[16:43:50 CEST] <kepstin> no, it should decode much faster than realtime if your cpu and disk are fast enough
[16:43:51 CEST] <cards> pardon?
[16:43:54 CEST] <furq> but also maybe the stdout file output and then redirect is causing problems
[16:44:06 CEST] <cards> sorry, windows here.
[16:44:12 CEST] <furq> that should still work on windows
[16:44:20 CEST] <cards> why the 2
[16:44:23 CEST] <furq> 2 is stderr
[16:44:34 CEST] <furq> - writes to stdout and then > redirects stdout, so the file output, not the ffmpeg log output
[16:44:36 CEST] <cards> -v error is no better?
[16:44:38 CEST] <furq> ffmpeg always logs to stderr
[16:44:52 CEST] <kepstin> ffmpeg's console log output is on stderr, not stdout, since you often pipe video out of ffmpeg on stdout
[16:44:56 CEST] <furq> right
[16:45:20 CEST] <furq> i'd be surprised if that was causing a slowdown but it is windows
[16:45:28 CEST] <furq> i'm often surprised by how their terminal works
[16:45:42 CEST] <kepstin> the null muxer doesn't actually write any output, so that *should* cause an issue, but.. :/
[16:45:46 CEST] <cards> hmm
[16:45:47 CEST] <kepstin> shouldn't*
[16:45:48 CEST] <furq> right
[16:46:05 CEST] <kepstin> i think on windows you can use "-f null NUL"
[16:46:12 CEST] <furq> if nothing else that'll actually write the error log to a file
[16:47:36 CEST] <cards> will ffmpeg also validate mp3 audio?  i've been meaning to do a side-by-side compare of other mp3 validators
[16:47:48 CEST] <cards> they all seem to catch different errors and not others
[17:04:14 CEST] <kepstin> i'd expect most mp3 validators would find errors with the file format, not necessarily with the contents. i'm pretty sure there's changes you can make to mp3s where they'll still decode fine but will have audible issues.
[17:04:39 CEST] <kepstin> if your goal is to just detect if something in the file has *changed*, you're probably best off using external checksums.
[17:05:21 CEST] <kepstin> (with a few notable exceptions for formats that actually have internal checksums)
[17:07:16 CEST] <cards> the 3 validators that i've found useful will each flag all the same mp3s for eggregious errors, and then they variously split off to also covering ID3 tag mishaps and other technical ugly.  but not subjective audio quality
[17:11:45 CEST] <cards> a good validator will also tell you that there's anomalous data at the end of a file.  people like to add hidden ZIP and RAR containers to just about everything.
[17:13:05 CEST] <cards> if you want a good time, see which image hosting sites will let you upload an [image][hidden-rar].jpg/png and then serve it for viewing without stripping off the container
[19:16:32 CEST] <fred1807> I want to stream over tcp from vps1 to vps2... On source, I ust tcp://destinationip:port  ?
[19:16:47 CEST] <fred1807> use
[19:32:31 CEST] <ChocolateArmpits> fred1807, yeah that's how you use it but you may also want to set -listen 1 so ffmpeg wouldn't crash if no stream was present and would connect immediately when it's there. Additionally make sure the command line loops in case the connection goes down on occasions
[19:32:47 CEST] <ChocolateArmpits> ALSO
[19:32:58 CEST] <ChocolateArmpits> make sure to specify the format of the input
[19:33:12 CEST] <ChocolateArmpits> so place -f [format] before the input. If the input is mpegts then -f mpegts
[19:33:20 CEST] <cehoyos> In general, you should never specify the input format with FFmpeg
[19:33:35 CEST] <cehoyos> But with tcp, you have to specify the output format as there is no default for tcp
[19:35:04 CEST] <fred1807> nice, so in the listening  side (vps2).. ffmpeg -f mpegts -i udp:localhost:5000 -listen 1 ........
[19:35:40 CEST] <ChocolateArmpits> you'd have to use udp
[19:35:43 CEST] <ChocolateArmpits> whoops
[19:35:47 CEST] <ChocolateArmpits> tcp*** not udp
[19:36:08 CEST] <ChocolateArmpits> and the address needs to point to the sender, not receiver
[19:36:31 CEST] <ChocolateArmpits> also -listen 1 needs to go before the input
[19:54:24 CEST] <fred1807> so..   on server (vp1)  ffmpeg ........ -f mpegts tcp://localhost:5000    on client (vps2)  ffmpeg -listen 1 -f mpegts -i tcp://serverIp:5000
[20:03:22 CEST] <BLZbubba> hi guys i have a transport stream that is misbehaving and I was wondering if someone could help convert it to mkv with ffmpeg copy - http://uberdl.com/tmp/bogus_stream.ts
[20:03:33 CEST] <BLZbubba> mpv plays it, vlc & mplayer fail
[20:04:52 CEST] <cehoyos> Needs -f mpegts to prove me wrong;-)
[20:05:32 CEST] <cehoyos> The reason is that it starts with 1 MB of "0"
[20:06:09 CEST] <DHE> pretty... also it has a lot of instances of pts < dts
[20:06:54 CEST] <cehoyos> If you cut the "0"s, the detection works fine.
[20:13:29 CEST] <DHE> ffmpeg -f mpegts bogus_stream.ts  # works with a lot of log/console messages
[20:17:14 CEST] <BLZbubba> sweet, you guys are awesome
[20:17:23 CEST] <ChocolateArmpits> fred1807, well you'd use the server IP address in first, because the listener can't connect to localhost that's on another system
[20:17:35 CEST] <DHE> *ffplay
[20:18:03 CEST] <furq> or 0.0.0.0 to listen on all addresses
[20:22:47 CEST] <cehoyos> The sample seems pathologic to me: If I cut the first 10.000 (or more) of 950.000 zeros, detection works fine
[20:23:02 CEST] <fred1807> tcp://0.0.0.0:5000: Connection refused
[20:24:10 CEST] <ChocolateArmpits> cehoyos, what about analyze_duration or probesize or even *GASP* skip_initial_bytes
[20:24:33 CEST] <cehoyos> All three do not help
[20:24:55 CEST] <cehoyos> The reason is that I believe there is a limit for the initial probing
[20:26:11 CEST] <cehoyos> It is apparently ~1M
[20:26:29 CEST] <cehoyos> The only question is if ".ts" should be detected
[20:27:32 CEST] <cehoyos> ".mpeg" and ".mpg" are not detected for the obvious reason that they are dubious but that may not be true for ".ts"
[20:28:36 CEST] <durandal_1707> ffprobe /dev/zero
[20:29:38 CEST] <cehoyos> An extension does not help for this case either
[20:41:08 CEST] <fred1807> ffmpeg -i 'moviefile.mp4' -filter_complex "scale=iw*min(1\,min(1280/iw\,720/ih)):-1" -c:v libx264 -preset veryfast -crf 30 -r 30 -an -f mpegts tcp://0.0.0.0:9000           Gives me connection refused
[20:43:34 CEST] <ChocolateArmpits> fred1807, you need to use the system address there, I have no idea why furq suggested that for output
[20:44:05 CEST] <fred1807> what would be a system address?
[20:44:20 CEST] <ChocolateArmpits> I suppose the listener process runs on another system, yes?
[20:44:30 CEST] <fred1807> yes, another vps
[20:44:57 CEST] <ChocolateArmpits> can they communicate otherwise?
[20:45:11 CEST] <ChocolateArmpits> are they on the same network?
[20:45:38 CEST] <fred1807> maybe I should output to a pipe, and use ssh to cat the pipes ?
[20:47:48 CEST] <ChocolateArmpits> I don't know how that works, sorry
[20:47:54 CEST] <fred1807> ChocolateArmpits: not the same network... I was expecting to communicate via internet
[20:49:02 CEST] <cehoyos> BLZbubba: Do you know how the sample was created?
[20:49:49 CEST] <cehoyos> The issue is that the mpegts probing function weighs the probing score against the probe_size which the mpegps (and possibly all other probe functions) do not
[20:57:03 CEST] <BLZbubba> "-c copy" is the best feature of all time
[20:57:14 CEST] <taliho> ChocolateArmpits: Can you ping the ip address where you are trying to send the stream?
[20:57:26 CEST] <BLZbubba> cehoyos: no, the file just fell off a truck in front of my house
[20:58:02 CEST] <BLZbubba> tennis stream service of a tournament in china
[20:58:40 CEST] <BLZbubba> it is playing perfectly with vlc now.  thanks!
[20:59:08 CEST] <taliho> fred1807: Can you ping the ip address of where you are trying to stream?
[21:06:28 CEST] <taliho> fred1807: if you want to do it properly with ssh you need to setup local forwarding
[21:07:57 CEST] <taliho> fred1807: if you don't care about encryption you could just open up a port on your target machine and send data
[21:09:34 CEST] <taliho> fred1807: on the target machine get ip address with: $ ip addr a
[21:10:56 CEST] <taliho> on target: $ sudo ufw allow 9000/udp #opens port 9000 for udp traffic
[21:11:19 CEST] <fred1807> yes I can ping, I just opened the ports
[21:11:24 CEST] <fred1807> tcp in this case...
[21:11:53 CEST] <taliho> from host: ffmpeg xx -f mpegts udp://ipaddress:port
[21:13:04 CEST] <taliho> on target: ffprobe -f mpegts udp://ipaddress:port
[21:13:14 CEST] <cehoyos> BLZbubba: I can see what it is, my question was how did you record it?
[21:14:25 CEST] <taliho> make sure ipaddress is *not* something like 192.168.x.x because that's local
[21:15:31 CEST] <taliho> if you just want to test connection between the two: on target $ nc -l -u ipaddress port
[21:15:48 CEST] <taliho> on host $ nc -u ipaddress port
[21:16:09 CEST] <taliho> and you should be able to type messages between the two
[21:17:31 CEST] <taliho> RE: "yes I can ping, I just opened the ports" -- you only need to open port on the target machine (i.e. where you are binding to port)
[21:38:37 CEST] <BLZbubba> cehoyos: bit torrent :P
[21:39:00 CEST] <BLZbubba> aka "fell off a truck"
[21:39:13 CEST] <BLZbubba> that is an old mafia term
[21:54:14 CEST] <cehoyos> Sorry, I misread your message above...
[00:00:01 CEST] --- Thu Oct  3 2019