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

[burek]

[00:07:28 CEST] <furq> kevinnn: just save it as .h264 then
[00:26:17 CEST] <victorqueiroz> Is FFMPEG suitable for a game in terms of performance?
[00:26:38 CEST] <kepstin> victorqueiroz: need more information. what do you plan to use ffmpeg for?
[00:26:42 CEST] <JEEB> depends on the exact modules, but various common video/audio formats are plenty fast enough
[00:26:51 CEST] <JEEB> less common ones are often not optimized for speed :P
[00:27:00 CEST] <kepstin> ffmpeg has probably the best software h264 and vp8/9 decoders, fwiw.
[00:27:48 CEST] <victorqueiroz> JEEB: I was just using libjpeg to decode jpeg images and found myself writing codecs and abstractions so I thought: Hm, maybe I could use ffmpeg to do that. I don't like using stb implementations, if you ask me
[00:28:23 CEST] <JEEB> STB (?)
[00:28:30 CEST] <JEEB> for me that is "set-top box"
[00:28:42 CEST] <victorqueiroz> JEEB: https://github.com/nothings/stb
[00:28:50 CEST] <victorqueiroz> JEEB: is that a vim shortcut?
[00:29:49 CEST] <kepstin> no, just an acronym used in the video world
[00:30:07 CEST] <JEEB> a set top box is one of those things you get fed by your internet/cable companies :P
[00:30:10 CEST] <JEEB> the plastique boxes
[00:30:31 CEST] <kepstin> if you're encoding video for a stb, that means you're encoding it for broadcast tv, to be decoded by a box that (in the case of crt tvs) traditionally sat on top of the tv
[00:30:46 CEST] <kepstin> they don't really fit on top of tvs any more :(
[00:31:22 CEST] <JEEB> victorqueiroz: anyways, take a look at the transcoding and transcoding_aac examples for example
[00:31:35 CEST] <JEEB> they do go a bit different way by including stuff that you probably don't need
[00:31:38 CEST] <JEEB> like encoding
[00:31:43 CEST] <JEEB> but it's a general overview of the API
[00:31:56 CEST] <kepstin> victorqueiroz: ffmpeg is mostly designed for use with audio/video media rather than still images, it might be a bit awkward to use for only still images.
[00:32:09 CEST] <JEEB> libavformat for reading/writing into containers, libavcodec to decode and encode packets into raw frames
[00:32:12 CEST] <JEEB> etc
[00:32:26 CEST] <JEEB> for actual playback there are higher level libraries such as libvlc or libmpv
[00:35:42 CEST] <victorqueiroz> JEEB: That's very nice guys. Thank you for explaining
[00:35:51 CEST] <victorqueiroz> I'll just stick to libjpeg-turbo for now, then
[00:43:59 CEST] <q66> please don't use jpeg for textures in games
[00:45:14 CEST] <CounterPillow> There's so many formats that are better than JPEG
[00:45:22 CEST] <q66> for textures, always
[00:45:38 CEST] <q66> either keep them uncompressed or use something that GPUs can crunch like ASTC/ETC or even S3TC
[00:46:28 CEST] <q66> jpeg will make them look like ass for no benefit other than pure savings of storage space, and it seriously messes up things like normalmaps
[00:49:34 CEST] <Atlenohen> Hey guys, is MPEG-2 video codec any good for lossless, the CPU resources are a factor, so if it's a lot easier on the CPU than x264 it's good, but would it be any better over x264 for same resources?
[00:50:00 CEST] <JEEB> x264 is an encoder, fyi
[00:50:04 CEST] <JEEB> the format is called AVC or H.264
[00:50:10 CEST] <JEEB> also x264 can be freaking fast
[00:50:30 CEST] <JEEB> unlikely that an MPEG-2 encoder would be faster than x264 with preset ultrafast :P
[00:55:07 CEST] <JEEB> and for decoding I remember decoding SD encodes that were created with more or less what x264 --tune fastdecode is now with the original 733MHz Xbox
[00:56:08 CEST] <JEEB> (it was more or less a pentium 3 era celeron)
[00:56:14 CEST] <another> i don't think mpeg2 has a lossless mode
[00:56:24 CEST] <JEEB> and yea, I don't remember that either
[00:56:50 CEST] <another> at least not in ffmpegs implementation
[01:07:50 CEST] <CounterPillow> If you want fast lossless, you can do huffyuv. If you want small lossless, you can do ffv1 or H.264 in lossless mode.
[01:09:00 CEST] <CounterPillow> also consider that with x264, the speed profiles still apply, so lossless ultrafast is probably still gonna be better than huffyuv for most cases
[01:09:08 CEST] <another> afaik ffvhuff was the faster one
[01:09:28 CEST] <another> *faster than huffyuv
[01:09:34 CEST] <CounterPillow> ah, cool
[01:10:21 CEST] <another> at least it supports a lot more pixel formats
[01:10:47 CEST] <CounterPillow> At any rate, at certain resolutions your bigger concern with fast lossless codecs is whether your disk can keep up
[01:28:08 CEST] <Atlenohen> Good suggestions guys
[01:28:55 CEST] <Atlenohen> except that MPEG-TS has limited codec support ... it's not strict but it's a bonus, I need something lossless that can go into MPEG-TS
[01:31:42 CEST] <furq> you're pretty much stuck with x264 then
[01:38:30 CEST] <Atlenohen> Allright. Also double checking, is it true that most video today is VFR and that it just appears as CFR ?
[01:43:28 CEST] <Atlenohen> Like in MKV, and the ones that support VFR
[01:47:34 CEST] <Atlenohen> Oh and, would VFR/CFR and time stuff change according to what codec is uses, or it has no effect, it's all in the container ?
[01:49:07 CEST] <Atlenohen> I see 1/90000 for MPEG-TS which seems a huge difference to MKV's 1/1000
[01:50:05 CEST] <Atlenohen> That makes MPEG-TS better right?
[01:54:20 CEST] <kepstin> Atlenohen: in practice, the 1/1000s precision used by most tools with mkv is fine
[01:56:45 CEST] <kepstin> for typical current video framerates
[01:58:59 CEST] <Atlenohen> Also I was trying to test whether a video is CFR or VFR, but it takes time to manually see each frame in ffprobe, is there any automated way of seeing the timecode changes that would indicate CFR? I remember it now but forgot
[01:59:24 CEST] <kepstin> Atlenohen: anyways, most common current containers store each frame with a timestamp value, allow arbitrary jumps in the timestamp value between frames, and index based on time.
[02:06:07 CEST] <Atlenohen> Here's .ts file https://pastebin.com/VzJUvXWN
[02:10:32 CEST] <Atlenohen> kepstin: I've got a number of files, configurations, codecs, containers to test, I'll really need some kind of an utlitiy which analyzes everything about time codes and PTS and whatever, and produces a report
[02:11:02 CEST] <Atlenohen> It's no way it's doable manually going through each multi 100 MB or GB (lossless) file
[02:11:25 CEST] <Atlenohen> At least incredibly impractical for me to even attempt it
[02:38:18 CEST] <Atlenohen> I got something so AVI + MPEG4 starts at: pkt_pts_time=0.000000 and goes to 0.066667 and 0.083333
[02:39:37 CEST] <Atlenohen> while MPEG-TS and x264 starts at: 0.016667 and goes to 0.033333, 0.050000, 0.066667, 0.083333
[02:43:46 CEST] <Atlenohen> that's a precision diff, but how to see whether one is constant frame rate or not
[02:44:23 CEST] <Atlenohen> pkt_duration_time=0.016667  by that number'
[02:44:24 CEST] <Atlenohen> =
[02:44:28 CEST] <Atlenohen> ?
[04:31:38 CEST] <kepstin> Atlenohen: if the pkt_duration_time varies by no more than ±0.002 or so between frames, you can probably treat the video as cfr. errors smaller than that are likely due to rounding when converting between timebases.
[04:32:41 CEST] <kepstin> would want to test any given threshold against a sample of videos to make sure it works for you tho.
[04:33:17 CEST] <kepstin> depends exactly what you're going to use this "cfr video" knowledge for, really.
[09:36:29 CEST] <CarlFK> I have files created with -flags +ilme+ildct  https://github.com/CarlFK/voctomix-outcasts/blob/master/record-timestamp.sh#L36
[09:36:50 CEST] <CarlFK> I want to deinterlace them now.
[09:37:02 CEST] <CarlFK> this made nice video, but no audio:
[09:37:16 CEST] <CarlFK> ffmpeg -i 14_58_47.tsi -map 0:v -c:v:0 mpeg2video -pix_fmt:v:0 yuv420p -qscale:v:0 2 -qmin:v:0 2 -qmax:v:0 7 -keyint_min 0 -bf:0 0 -g:0 0 -deinterlace -acodec copy -f mpegts 14_58_47.tsp
[09:39:36 CEST] <CarlFK> do I need -map 0:a -c:a:0
[09:45:28 CEST] <durandal11707> why are you using -deinterlace ?
[09:47:31 CEST] <CarlFK> to deinterlace
[09:47:58 CEST] <durandal11707> that is bad and wrong way, search google for better ways
[09:48:16 CEST] <CarlFK> will it fix my audio problem ? ;)
[09:48:20 CEST] <JEEB> hint: the yadif video filter is mostly what you want
[09:48:49 CEST] <JEEB> CarlFK: and yes if you start mapping manually you need to map the audio too :)
[09:49:09 CEST] <JEEB> you current only map the video track(s) from the input
[09:54:09 CEST] <CarlFK> google says replace    -deinterlace with   -vf yadif=3:1,mcdeint=2:1
[09:55:10 CEST] <JEEB> don't use the numeric values :<
[09:55:14 CEST] <JEEB> magical values = unreadable
[09:55:20 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html
[09:55:25 CEST] <JEEB> see the options for yadif here
[09:57:06 CEST] <durandal11707> CarlFK: your audio is which codec?
[09:58:11 CEST] <CarlFK> durandal11707: I wanted to copy it.  it was created with         -map 0:a -c:a:0 mp2 -b:a:0 192k -ac:a:0 2 -ar:a:0 48000 \
[09:58:58 CEST] <CarlFK> getting rid of the number sped it up
[09:59:36 CEST] <CarlFK> looks like Ill have audio this time too:     Stream #0:1[0x101](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, s16p, 192 kb/s
[11:01:50 CEST] <superware> after I'm calling avformat_find_stream_info for an RTSP stream, how can I get the actual mrl for each of the video/audio streams? eg. opening rtsp://...:554/CH001.sdp might open the video on rtp://...:1234, how can I get the actual video stream mrl?
[11:04:19 CEST] <JEEB> not sure if that is exported
[11:04:35 CEST] <JEEB> since lavf is supposed to handle that for you so that you can just read packets of data
[11:04:45 CEST] <JEEB> lavf generally is on a higher abstraction level
[11:17:23 CEST] <superware> JEEB: are you sure it's somehow no exposed? :|
[11:17:31 CEST] <superware> not somehow exposed...?
[12:05:37 CEST] <JEEB> superware: you'd have to look into it but I would bet it'd be a lower abstraction layer thing
[12:32:44 CEST] <superware> JEEB: managed per AVStream?
[12:46:07 CEST] <JEEB> superware: no, I mean something that a normal API user would not require to know :P
[13:19:36 CEST] <superware> ok, thanks
[22:43:08 CEST] <Mysterytrain> when you see, subrip, in a subtitle stream, what does that mean?
[22:55:42 CEST] <c_14> it's a subtitle format
[23:04:22 CEST] <causa-sui> I have been using ffmpeg to make short clips out of larger video files. With one, I want to make an "eternal loop" i.e. play the clip, then seamlessly play the clip in reverse back to the beginning. Would anyone be kind enough to help me figure out how?
[23:18:32 CEST] <DHE> reverse is tricky. you'll probably want to turn the movie into individual frames (png, jpegs, whatever), reverse the filenames, and then re-encode a backwards video movie from that
[23:26:27 CEST] <c_14> there is the reverse filter
[23:26:36 CEST] <c_14> it'll just use a lot of memory depending on the size of the video
[23:44:58 CEST] <bencc> I have a video with animated cartoon over fixed background
[23:45:15 CEST] <bencc> is there a way to crop the cartoon and hide the background?
[23:57:22 CEST] <TheAMM> bencc: https://ffmpeg.org/ffmpeg-filters.html#crop
[23:57:51 CEST] <TheAMM> I wish you luck with your youtube anime rips
[23:59:01 CEST] <causa-sui> c_14: not a big video. can I do this in one operation or would you make a normal + reversed video, and then conjoin them after?
[00:00:00 CEST] --- Wed May 29 2019