[Ffmpeg-devel-irc] ffmpeg.log.20171124
burek
burek021 at gmail.com
Sat Nov 25 03:05:01 EET 2017
[04:17:42 CET] <Diljeet> hello
[04:17:58 CET] <Diljeet> need help compiling ffmpeg just one simple help
[04:18:14 CET] <TheRock> Ok
[04:18:17 CET] <Diljeet> i compiled both libmp3lame and ffmpeg seperately
[04:18:23 CET] <Diljeet> but hoe to compile together
[04:18:51 CET] <TheRock> the libs are usually included in the ffmpeg main build
[04:19:01 CET] <TheRock> in ./configure
[04:19:27 CET] <Diljeet> how to include them, ffmpeg configure says libmp3lame not found
[04:19:53 CET] <TheRock> you probably have to specify include/lib pathes
[04:19:55 CET] <Diljeet> ok so i should include libmp3lame.so file path in libs?
[04:20:25 CET] <Diljeet> ok i will try, thanks for helping
[04:34:05 CET] <TheRock> Diljeet its important that you play water man while compilin
[04:34:08 CET] <TheRock> or it will fail
[04:35:54 CET] <Diljeet> ??water man
[04:36:03 CET] <TheRock> yeah
[04:36:18 CET] <Diljeet> i have no idea about water man
[04:36:54 CET] <TheRock> Ok, then it will fail
[04:37:31 CET] <Diljeet> oh no
[04:37:40 CET] <Diljeet> i will search google
[04:37:53 CET] <TheRock> i will give you the direct link
[04:38:00 CET] <TheRock> Diljeet https://www.youtube.com/watch?v=_GG3vM_jJwo
[04:38:03 CET] <TheRock> here it is
[04:38:08 CET] <TheRock> you must play it during compile
[04:39:32 CET] <Diljeet> ok thanks
[04:39:43 CET] <TheRock> welcome
[06:07:10 CET] <Hussain> Hi. Anyone here?
[06:08:27 CET] <Diljeet> Hussain what are you looking for
[06:13:33 CET] <Hussain> I am trying to convert a BMP to monochrome PCX as that is the only format acceptable to TSC label printers
[06:14:30 CET] <Hussain> Can't find the correct option for that. The simple conversion creates a PCX file which has a color palette. The printer doesn't print that.
[06:15:02 CET] <Hussain> The image I create is a QR Code using the ZXing DLL, so is pure black & white. No gray scales.
[06:15:06 CET] <Hussain> Help?
[06:33:38 CET] <relaxed> Hussain: from looking at "ffmpeg -h encoder=pcx", maybe adding "-pix_fmt monob" is what you need
[06:39:13 CET] <Hussain> Thx. Shall try now..
[06:53:47 CET] <Hussain> Looking promising. As I generate a .tmp file, how do I specify the input format? i.e. ffmpeg -i tmpfile.tmp -inputformat bmp -c pcx output.pcx?
[07:28:21 CET] <ayum> Hi, I am using ffmpeg read the stream from a v4l2 device, but seems the device supports only uyvy422 format. can I convert it to yuv420p format, then pass it to a avfilter? because the avfilter only supports yuv420p format.
[08:41:51 CET] <dilip> I am getting this error while trying to add a logo and drawtext at the same time using ffplay : error message = Input pad "default" with type video of the filter instance "Parsed_drawtext_2" of drawtext not connected to any source
[08:42:36 CET] <dilip> My command goes like this: ffpaly -vf "movie=logo100.png[logo];[in][logo]overlay=main_w-overlay_w-10:10 [input_with_logo] ; \
[08:42:36 CET] <dilip> drawtext=fontsize=20:fontcolor=red:text='This is a test line'[drawtext] ; \
[08:42:37 CET] <dilip> [input_with_logo][drawtext] overlay=x=w/10*mod(t\,10):y=h-line_h[out]" \
[11:40:26 CET] <fps> ok, let's say i have a uint8_t* pointing to a region of memory holding a single channel grayscale image of size width, height
[11:40:45 CET] <fps> it's dense, so the linesize (ffmpeg speak) is equal to the width of the image
[11:41:33 CET] <fps> and now i want to use swscale to convert it to yuv420p. is this complete madness:
[11:42:11 CET] <fps> i setup the sws_context ala:
[11:42:26 CET] <fps> m_sws_context = sws_getContext(
[11:42:26 CET] <fps> m_av_codec_context->width,
[11:42:26 CET] <fps> m_av_codec_context->height,
[11:42:26 CET] <fps> AV_PIX_FMT_GRAY8,
[11:42:26 CET] <fps> m_av_codec_context->width,
[11:42:28 CET] <fps> m_av_codec_context->height,
[11:42:31 CET] <fps> AV_PIX_FMT_YUV420P,
[11:42:33 CET] <fps> SWS_BILINEAR, NULL, NULL, NULL);
[11:42:39 CET] <BtbN> please don't flood the channel, thanks.
[11:42:41 CET] <fps> i hope multiline pastes are ok when the channel is as quiet as it is now
[11:43:58 CET] <fps> and then lateron i do:
[11:44:06 CET] <fps> const uint8_t *d[1] = { img_data };
[11:44:07 CET] <fps> const int src_linesize[1] = { m_av_codec_context->width };
[11:44:07 CET] <fps> sws_scale(m_sws_context, d, src_linesize, 0, m_av_codec_context->height, m_av_frame->data, m_av_frame->linesize);
[11:44:15 CET] <fps> where img_data is the buffer holding my src data
[11:44:34 CET] <celyr> fps, why not using paste.debian.org or something ?
[11:45:02 CET] <fps> so the question is: is swscale ok with there being only a single entry in the linesize array if the src format is AV_PIX_FMT_GRAY8
[11:45:15 CET] <fps> and also in the data array
[11:45:45 CET] <BtbN> If the pix_fmt only has one plane, it is obviously expected to be that way
[11:45:55 CET] <BtbN> And use a pastebin
[11:47:08 CET] <fps> BtbN: nothing is ever obvious when it comes to complex apis
[11:47:17 CET] <fps> and the obvious thing is often wrong..
[11:47:36 CET] <BtbN> What could possibly be in there? grey8 only has one plane of data
[11:47:49 CET] <BtbN> Each pix_fmt has a well defined amount of planes
[11:48:09 CET] <fps> BtbN: ok, i missed the part of the documentation wwhere that is clarified :)
[11:48:38 CET] <BtbN> It's a static structure, so it has to have space for the maximum amount of planes any format can have
[11:48:44 CET] <BtbN> the unused ones are just that, unused
[11:51:11 CET] <fps> ok, thanks for the clarification
[12:34:44 CET] <nado> hi
[12:35:16 CET] <nado> is there a way to scan some file to get its video track bitrate informations if it is not present in headers ?
[12:35:40 CET] <zash> is that what ffprobe does?
[12:37:25 CET] <nado> i havent used ffprobe before, but simply doing "ffprobe file.mkv" doesnt give me more information
[12:37:46 CET] <nado> should i use some options to have longer scan duration ?
[12:38:27 CET] <durandal_170> yes
[12:38:32 CET] <durandal_170> read docs
[12:45:01 CET] <nado> durandal_170, thanks, im trying, i gave up, i searched again on google with ffprobe instead of ffmpeg, found some stackexchange examples, didnt work
[12:46:14 CET] <nado> "-show_entries stream=bit_rate" shows "N/A" for every stream
[12:46:45 CET] <durandal_170> you need to decode it i think
[12:49:21 CET] <durandal_170> https://github.com/zeroepoch/plotbitrate/blob/master/plotbitrate.py
[12:50:58 CET] <nado> thank you for the link
[13:30:16 CET] <nado> i tested plotbitrate script and it worked great, thank you durandal_170, i dont think i would've found the correct ffprobe command by myself
[13:31:50 CET] <nado> bye o/
[13:36:16 CET] <fps> interesting. vlc and virtualdub both decode the video with different brightness compared to the original 8bit mono values i encoded..
[13:37:24 CET] <fps> setting codec_context->qmin and qmax to 0 should introduce zero quantization, right_
[13:37:27 CET] <fps> right=
[13:37:33 CET] <fps> argh, german, keyboard.. ;)
[16:12:14 CET] <kepstin> fps: some thoughts - the video might have been converted from full-range to limited-range (the latter is standard for video applications), also what codec are you using? many don't have a lossless option, and that's the wrong way to set it for those that do.
[17:00:26 CET] <AppleTor> sub, i have a little problem here. So, I'm downloading video via m3u8 playlist. sometime one or two chunks failed to download. is there a chance i could make ffmpeg to retry downloading that chunk instead of jumping to the next chunk?
[17:00:39 CET] <AppleTor> *sup lol
[17:11:41 CET] <kepstin> why does a chunk fail to download? The typical reason is that the chunk has expired (been removed from the server), so retrying wouldn't help.
[17:12:46 CET] <kepstin> if you're getting that, it probably means that your ffmpeg command is running too slow on a realtime stream.
[18:01:15 CET] <AppleTor> kepstin my home connection sometimes going nuts, if i retry the whole process then the download will 100% complete
[18:01:33 CET] <AppleTor> or maybe error on other chunk, not the exact same chunk
[18:02:31 CET] <AppleTor> i can confirm that the chunk is on always alive state, and it's not removed from the server :)
[18:54:33 CET] <MrSassyPants> Why does "-vcodec copy -acodec copy" re-encode?
[18:56:45 CET] <DHE> without seeing a commandline, I'm guessing it's because you put them before the input file rather than before the output file
[19:00:24 CET] <MrSassyPants> DHE, yeh, that was it
[20:12:52 CET] <degenerate> I'm confused about the output of ffprobe for this video file: http://termbin.com/7r8k
[20:12:55 CET] <degenerate> the first stream is the video, it is 720x480 [SAR 32:27 DAR 16:9], but in the stream json output it says "sample_aspect_ratio": "109:90", "display_aspect_ratio": "109:60"
[20:12:58 CET] <degenerate> video in question: https://uccdn.bid13.com/original_videos/y/K/yKsRfyWQs8NZc6nVIc3kuKFOn3UWbyv4KJX5QddKNwS.mov
[20:13:22 CET] <degenerate> furq: you seem to know a lot more than me about this stuff, maybe you know why this video has two different SAR/DAR ?
[20:15:14 CET] <kepstin> depending on the container and codecs in question, it's often possible for the codec to specify a different sar/dar from the container
[20:15:38 CET] <kepstin> during playback, the container one should generally override the codec in that case
[20:16:39 CET] <degenerate> kepstin: thanks, so how do i know which one is correct, do i just trust what's in the json output?
[20:20:59 CET] <kepstin> degenerate: the one in the json output you get with -show_streams is the one you should be using
[20:21:06 CET] <kepstin> of course on this file it might just be wrong :/
[20:23:59 CET] <furq> that looks fine to me?
[20:24:30 CET] <furq> 720/480 * 32/27 = 16/9
[20:25:04 CET] <kepstin> the sar - 109:90 is a 10th of a percent off from the typical value of 40:33
[20:25:10 CET] <furq> oh right i forgot that bit
[20:25:12 CET] <kepstin> so it should look correct, yes
[20:25:14 CET] <furq> yeah idk where 109/90 comes from
[20:25:25 CET] <kepstin> it's close enough that nobody would notice
[20:25:52 CET] <furq> 1.82 is a decent enough way off from 1.78
[20:26:06 CET] <furq> not a huge deal though
[20:26:20 CET] <kepstin> this is ntsc video tho, remember it has side borders that aren't part of the picture area
[20:26:30 CET] <kepstin> the middle 704x480 of the video has a 16:9 aspect
[20:26:31 CET] <degenerate> yeah, thats what i was confused about, it seems like the 32:27 was more correct, when i play back that file, it appears to be 16:9 (no letterboxing at fullscreen on a 16:9 monitor)
[20:27:05 CET] <degenerate> oh...
[20:27:05 CET] <kepstin> so if you have a 720x480 video, it should be slightly wider than 16x9
[20:27:06 CET] <degenerate> hmm
[20:27:09 CET] <furq> yeah my best guess would be ffmpeg noticing it's dv and cutting 16px off the width to compensate
[20:27:19 CET] <furq> i'm not sure why it would bother though
[20:27:44 CET] <kepstin> i'd expect ffmpeg to return the whole thing, and you'll get slight borders on the top and bottom on a 16:9 monitor
[20:27:47 CET] <degenerate> oh wait, i was wrong, it does have slight side letterboxing
[20:28:04 CET] <furq> in the video itself or when you fullscreen it
[20:28:19 CET] <degenerate> in the video itself
[20:28:36 CET] <degenerate> and then if i fullscreen it
[20:28:43 CET] <degenerate> it has slight top bottom letterboxing
[20:28:52 CET] <kepstin> yes, that's expected.
[20:29:18 CET] <degenerate> so i should be using the 109/90 then, and ignoring the 32/27
[20:29:21 CET] <degenerate> correct?
[20:29:24 CET] <kepstin> to get an exact 16:9 video with no letterboxing, you'll want to crop it to 704:480 (e.g. using -vf crop=704:480:8:0)
[20:29:29 CET] <kepstin> use the 109/90, yes
[20:29:45 CET] <degenerate> interesting. thanks.
[20:29:50 CET] <furq> well 109/90 would be the dar
[20:30:06 CET] <furq> the correct sar would be 40/33
[20:30:23 CET] <kepstin> (or even better, fix the video to use the accepted standard sar of 40/33)
[20:30:28 CET] <degenerate> whaaa? where does that come into this? i don't see 40/33 in the ffprobe output at all.
[20:30:29 CET] <furq> right
[20:30:42 CET] <furq> 40/33 is the standard ntsc sar for 704*480
[20:30:46 CET] <furq> to get 16:9 output
[20:30:48 CET] <kepstin> degenerate: the video's encoded incorrectly - it has values that are almost, but not quite, correct.
[20:31:06 CET] <kepstin> small enough difference from the correct value that it's effectively unnoticable
[20:31:13 CET] <furq> it's correct for dv isn't it
[20:31:19 CET] <degenerate> im trying to do this in an automated fashion, so i need to trust what ffprobe gives me.
[20:31:39 CET] <kepstin> nah, dv uses the same horizontal sampling frequency as any other ntsc analog capture
[20:31:54 CET] <degenerate> i have two options, trust the json in show streams, or trust the header output (stderr) and regex out the sar dar from there
[20:32:02 CET] <kepstin> degenerate: trust the json
[20:32:09 CET] <degenerate> k
[20:32:11 CET] <degenerate> thanks
[20:32:18 CET] <kepstin> if you're doing automated processing, that's the best you can do
[20:32:20 CET] <furq> if ffprobe is saying the sar is 109/90 then that's just plain wrong
[20:32:29 CET] <kepstin> anything better would need manual cleanup
[20:32:51 CET] <furq> wait
[20:32:52 CET] <furq> nvm
[20:32:54 CET] <kepstin> furq: that's what's in the file, so that's what it says :/
[20:33:04 CET] <furq> yeah for some reason i had 109/60 in my head
[20:33:12 CET] <kepstin> yeah, 109/60 is the dar.
[20:33:14 CET] <furq> so it's no wonder all these numbers were coming up wrong
[20:33:56 CET] <kepstin> weird that the time base is 100/2997 rather than 1001/30000, too
[20:34:05 CET] <furq> oh wow nice
[20:34:28 CET] <furq> lots of things that are half a percent out here
[20:34:54 CET] <degenerate> "i'll just make a script that adds motion graphic clips to the front of videos people upload, it'll be easy, no problem".
[20:35:00 CET] <degenerate> 2 years later, i'm still fighting this thign
[20:35:03 CET] <furq> lol
[20:35:15 CET] <kepstin> this file was apparently made on nov 11, what kind of software uses just slightly off values like that in 2017? :(
[20:35:39 CET] <degenerate> kepstin: lots of people who are uploading these files have old digital cameras
[20:35:52 CET] <furq> yeah if someone is still using dv then i wouldn't expect anything about their workflow to be up to date
[20:35:52 CET] <degenerate> like those old point and shoots from a decade ago
[20:36:06 CET] <furq> also lol
[20:36:13 CET] <furq> i've never seen ffprobe reporting yuv411p before
[20:36:23 CET] <furq> i knew it was a thing but it still makes me feel deeply uncomfortable
[20:36:27 CET] <kepstin> that's normal for DV, iirc?
[20:36:29 CET] <furq> yeah
[20:36:35 CET] <furq> i've just never actually seen it in text before
[20:36:49 CET] <kepstin> but yeah, I assume someone got out their old firewire camera from 2005 and made a mov file on their classic bondi blue imac or something
[20:37:43 CET] <furq> anyway yeah
[20:37:57 CET] <furq> if you're trying to automate this then the ARs ffprobe reports are going to be what ffmpeg is using anyway
[20:38:10 CET] <furq> so just encode your bumper to the same dimensions and sar and it'll "work"
[20:38:17 CET] <furq> even if things are slightly out
[20:38:35 CET] <furq> it'll at least be consistently out
[20:39:36 CET] <degenerate> well theres more than that, theres a bunch of text sections, and crossfades.
[20:39:47 CET] <degenerate> and then i concat the whole thing
[20:40:00 CET] <degenerate> i guess i could also do the text sections at the sar/dar of the input clip
[20:40:17 CET] <furq> yeah
[20:40:46 CET] <furq> on the off chance ffmpeg gets something completely wrong then you're not automating it anyway
[20:40:48 CET] <kepstin> honestly, you could probably just get away with doing all your stuff at a few fixed sizes and aspect ratios, and then just scaling the nearest one
[20:41:05 CET] <furq> yeah you probably want to cache the bumpers and stuff somewhere after the first encode
[20:41:11 CET] <furq> if you're not already
[20:41:26 CET] <kepstin> (although you'd need special handling for stuff like this weird padded ntsc sort of thing)
[20:41:33 CET] <degenerate> well the script does generate the bumpers to the same resolution of the middle video, i was just not handling sar/dar properly previously. cause i didn't evne know that was a thing until recently.
[20:42:04 CET] <degenerate> (then i store them so i don't generate them everytime)
[20:42:21 CET] <degenerate> i guess i could add sar/dar to that part, and cache those as well.
[20:42:26 CET] <furq> yeah
[20:42:47 CET] <furq> the vast majority of stuff nowadays has a sar of 1 anyway
[20:42:51 CET] <degenerate> probably faster actually, cause i wouldn't have to reencode the middle (longer) clip.
[20:43:05 CET] <furq> aside from the odd 1440x1080 thing
[20:43:17 CET] <furq> i'm sure some scoundrels are still broadcasting that
[20:43:19 CET] <kepstin> like in this case, you could render your stuff to 720p or whatever with square pixels, scale based on sar and height to the correct width, pad to the full video size.
[20:44:03 CET] <kepstin> isn't 1440x1080 mostly used in cheaper 1080p handheld camcorders nowadays?
[20:46:57 CET] <kepstin> (that said, I am kinda annoyed that there's no specced HD 4:3 resolutions, so all the HD rescans of 4:3 films have to be pillarboxed)
[20:47:17 CET] <furq> isn't that more of a bluray problem
[20:54:44 CET] <kepstin> mostly, yeah
[21:01:55 CET] <degenerate> So if i wanted to convert a SAR:1, DAR:16:9, 1920x1080 clip to 720x480, SAR:109:90, DAR:109:60, i would do:
[21:01:55 CET] <degenerate> -vf scale=720x480 -vf setdar='109:60' -vf setsar='109:90'
[21:01:56 CET] <degenerate> ?
[21:05:04 CET] <furq> just setsar
[21:05:13 CET] <furq> also it'd be -vf setdar=args,setsar=args
[21:05:37 CET] <furq> (if you did actually need to set both which you don't)
[21:06:02 CET] <degenerate> would i later be able to concat the clips, i.e. without re-encoding the ntsc one?
[21:06:40 CET] <furq> if ffmpeg has a dv encoder then probably
[21:07:18 CET] <durandal_1707> it have
[21:11:25 CET] <kepstin> degenerate: actually, you'd do -vf scale=704:480,pad=720:480:8:0,setsar=109:90
[21:11:54 CET] <kepstin> (calculating the exact scale and pad values there *can* be done automatically given the sar and output resolution)
[21:13:19 CET] <SonicTheHedgehog> https://trac.ffmpeg.org/wiki/Seeking#Cuttingsmallsections <<< What is the difference between "faster seek" and "slower seek"?
[21:14:08 CET] <TheRock> the one is faser and the other is slowe
[21:14:35 CET] <kepstin> SonicTheHedgehog: the "faster seek" option seeks in the input file, and gives you video with timestamps starting at 0 from that point
[21:15:08 CET] <kepstin> the slower option decodes the entire videos, throwing out frames until it gets to the desired point (which will then have timestamps corresponding to the time within the original video)
[21:15:18 CET] <SonicTheHedgehog> kepstin: Interesting.
[21:15:25 CET] <kepstin> that's pretty much it, although there's other options that affect timestamp manipulation
[21:18:09 CET] <kepstin> if you have videos where seeking works reliably, you'll almost always want to use the faster option
[21:18:53 CET] <SonicTheHedgehog> Interesting, yeah. Thanks.
[23:37:06 CET] <Scrappy> Trying to understand why ffmpeg is detecting a 29.97 interlaced feed as 29.97 fps, 59.94 tbr. Why is tbr double fps?
[23:39:20 CET] <kepstin> Scrappy: tbr is the 'r_frame_rate' field, see the faq entry: https://www.ffmpeg.org/faq.html#AVStream_002er_005fframe_005frate-is-wrong_002c-it-is-much-larger-than-the-frame-rate_002e
[23:39:46 CET] <kepstin> it's not a framerate, it's an internal detail about the timestamps.
[23:40:34 CET] <BtbN> pretty much because there are that many fields per second. But it's just the timebase. As long as it's a multiple of the fps, all is good
[23:40:46 CET] <Scrappy> @kepstin - thank you!
[23:42:29 CET] <Scrappy> What I find is looking at avg_frame_rate/r_frame_rate - they are both 59.94 coming from av_format_find_stream_info;
[23:42:46 CET] <Scrappy> but after decoding the first frame, the context framerate drops to 29.97
[23:43:11 CET] <Scrappy> (the feed is actually 29.97)
[23:47:57 CET] <relaxed> 2 fields/per second = 1 frame/per second at 29.97
[23:51:11 CET] <Scrappy> This behaviour changed between 3.0 and 3.3. I used to use time_base/ticks_per_frame in 3.0 and they would work out to 29.97. But since I updated to 3.3, time_base has 59.94 for time_base
[23:56:50 CET] <relaxed> I butchered that :/
[00:00:00 CET] --- Sat Nov 25 2017
More information about the Ffmpeg-devel-irc
mailing list