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

[burek]

[00:33:55 CET] <analogical> can some ffmpeg ninja please extract the video stream from this site? http://ustvgo.tv/cnn-live-streaming-free/
[00:41:07 CET] <BtbN> extracting video from websites is not something ffmpeg does.
[00:50:11 CET] <analogical> BtbN, wut?
[00:50:21 CET] <analogical> I've done that many times
[00:50:38 CET] <BtbN> very unlikely. You probably used youtube-dl or something the like.
[00:50:43 CET] <BtbN> ffmpeg does not parse html
[03:59:51 CET] <pbd> Hi
[04:00:02 CET] <pbd> I believe the mail server for the trac is not working.
[04:00:11 CET] <pbd> First I'm being told that I'm a spammer..
[04:00:27 CET] <pbd> Then I have the worst of the captchas.
[04:00:30 CET] <pbd> And then no email.
[04:43:55 CET] <void09> any way to make ffmpeg extract all srt subs from an mkv ? i got one with 25 subtitles
[04:54:32 CET] <void09> https://gist.github.com/abjdiat/6383447
[04:54:36 CET] <void09> something like this, but it does not work
[06:22:20 CET] <void09> found one
[06:22:40 CET] <void09> h264_metadata=delete_filler=1 - is there a h265 equivalent to this, or h265 does not have filler ?
[07:03:49 CET] <void09> got this ts file, trying to mkv it: ffmpeg -i "input.ts"  -vcodec copy -acodec copy outputvideo.mkv
[07:04:02 CET] <void09>  Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[07:04:02 CET] <void09> [matroska @ 0x55f747a51440] Can't write packet with unknown timestamp
[07:04:02 CET] <void09> av_interleaved_write_frame(): Invalid argument
[07:04:17 CET] <void09> mkvtoolnix has no issues with it though. any params i can try to fix this situation?
[07:10:54 CET] <void09> just found hte -fflags +genpts advice and that does not fix it, same error
[08:18:45 CET] <Fyr> guys, is there a script for Windows to create a slideshow with transitions?
[08:19:02 CET] <Fyr> if it's a simple bash script, it's alright, I have busybox.
[08:41:22 CET] <void09> Fyr: i usually search github with those keywords when i need stuff like that
[08:41:31 CET] <void09> ffmpeg slideshow
[11:40:42 CET] <lofo> I'm not sure how output formats and networking protocols play out together
[11:41:32 CET] <lofo> i'm trying to stream with tcp://, i managed to make it work with -f mpegts but not mp4
[11:42:26 CET] <lofo> flv works too
[11:42:47 CET] <pink_mist> yeah, mp4 isn't made for streaming
[11:42:53 CET] <pink_mist> trying it is going to be painful
[11:43:23 CET] <JEEB> fragmented mp4 will work
[11:43:38 CET] <JEEB> TheAMM even made it work with a <video> tag apparently
[11:43:41 CET] <JEEB> which was a pleasant surprise
[11:44:20 CET] <TheAMM> "Made" as in set the flags and yolod stdout directly at a browser
[11:45:40 CET] <lofo> if there some source of information that says what format work with what protocol ? Because iwould like to try out many different combinations
[18:14:09 CET] <void09> is there any flags I can use to make sure the resulting mkv file has readable bitrate tag?
[18:14:18 CET] <void09> or whatever mediainfo uses to get the bitrate info
[18:32:20 CET] <Ducky^> I'm using a command, something like this:
[18:32:24 CET] <Ducky^> ffmpeg -y -i WAVs/1.wav -i WAVs/2.wav -i WAVs/3.wav -i WAVs/4.wav -i WAVs/5.wav -i WAVs/6.wav -filter_complex amerge=inputs=6,apad=whole_dur=3600 -c:a pcm_s16le -ar 48000 -rf64 auto -t 3600 6chantest.wav
[18:32:43 CET] <Ducky^> one of the input wav files is longer than the other, but I'd like the output audio to be of fixed length
[18:32:57 CET] <Ducky^> the problem is that the longer file is cut short to the shortest file
[18:33:08 CET] <Ducky^> but all files are padded with silence as expected, up to one hour of audio
[18:33:28 CET] <Ducky^> I'd like the longer file to continue while the shorter files are padded, then the longer file padded once it reaches the end
[18:33:34 CET] <Ducky^> is that possible with ffmpeg?
[18:38:43 CET] <kepstin> Ducky^: sure, you would want to use an apad filter on the shorter inputs to add silence to the end.
[18:40:09 CET] <kepstin> actually, what i'd do is attach an apad filter to each input before feeding to the amerge filter, then you don't need an apad afterwards, and the -t option would set the final duration.
[18:59:35 CET] <matto312> I have question. (I'm new to video but an experienced dev) Using ffmpeg, when my input has FPS = 29.97 and I specify 30 FPS output (using -r 30) ... My question is ... is that bad? What are the implications of doing this? Thanks!
[19:01:36 CET] <DHE> depends how you do it. either you'll skew the speed of the video, or ffmpeg will duplicate frames
[19:02:09 CET] <c_14> using -r as an output option should duplicate frames
[19:04:45 CET] <matto312> Is duplicating frames ok? To me it feels sloppy, but I don't know video stuff well enough
[19:05:27 CET] <c_14> it's essentially the same thing your video player does when video fps != display fps
[19:05:51 CET] <matto312> Gotcha, thx c_14
[19:06:55 CET] <c_14> it can cause some jankiness because you'll be artificially elongating the lengths of certain "frames"
[19:07:34 CET] <c_14> and if you change a video from 29.97 to 30fps and then play that on a display with 59.94 Hz you can end up dropping frames
[19:08:11 CET] <c_14> read: It's usually best not to mess with fps except in specific circumstances, but it's not going to break anything in most cases
[19:08:40 CET] <matto312> c_14 ... thank you, this is really helpful
[19:09:15 CET] <matto312> going to see if I can just pass thru ffmpeg whatever frame rate the input is
[19:09:50 CET] <c_14> if you don't explicitly set the framerate, ffmpeg won't change it
[19:15:42 CET] <bvarg0> What does "[mp3float @ 0x55e4f8bc1540] overread, skip -7 enddists: -4 -4" mean?  Is it a problem?  Is it fixable?
[19:35:45 CET] <cehoyos> bvarg0: It indicates that your mp3 stream is broken
[19:36:45 CET] <cehoyos> matto312: Note that most likely the frame rate of your input stream is not 29.97 but 30000/1001
[19:36:48 CET] <bvarg0> so if the .opus sounds ok, then don't worry about it?  I get a running stream of these errors.
[19:37:09 CET] <cehoyos> For best results, FFmpeg with the setpts filter allows you to change the video speed (to 30 fps)
[19:37:29 CET] <bvarg0> 30000/1001 = 29.97002997
[19:37:32 CET] <bvarg0> ?
[19:37:52 CET] <cehoyos> Which is != 29.97
[19:38:24 CET] <bvarg0> ok, so there's no video here.
[19:38:26 CET] <cehoyos> If your input is a file, provide it, if it is a stream, record it
[19:38:29 CET] <bvarg0> does that make a difference?
[19:38:39 CET] <cehoyos> I wrote "matto312:" to indicate that this information is not meant for you
[19:38:54 CET] <bvarg0> shit, sorry
[19:39:39 CET] <cehoyos> Note that recording can be difficult with FFmpeg, mplayer -dumpstream is an alternative
[19:41:40 CET] <bvarg0> ok, well, i don't know what results from a broken mp3 stream but the output file is intelligable so i suppose it doesn't matter.
[19:41:47 CET] <bvarg0> is there anyway to put a : in
[19:41:51 CET] <cehoyos> If your input is a file, provide it, if it is a stream, record it
[19:41:53 CET] <bvarg0> the output file name?
[19:42:01 CET] <cehoyos> Use file:
[19:51:04 CET] <matto312> ceyhoyos: thx for info ... I'm working with live RTMP input and output is HLS (which is being uploaded to CDN)
[19:52:21 CET] <cehoyos> Then there is no good solution if your input is 30000/1001 and you have to provide 30fps
[19:52:44 CET] <cehoyos> For endless input
[19:54:10 CET] <matto312> cehoyos: so for endless input, going from 30000/1001 to 30 fps ... going to end up with some choppyness?
[19:57:46 CET] <kepstin> yeah, there's basically gonna be a momentary stutter from a duplicated frame every ~1000 frames (so about 33 seconds at 30fps), which is just enough to annoy people who notice it.
[19:58:28 CET] <cehoyos> Unless you use the framerate filter that interpolates and takes a lot of cpu power, likely not being real-time for many resolutions
[19:59:15 CET] <kepstin> (if you play a 30000/1001 video on a 60fps screen it's not *as* noticable, because the player can insert a half-frame delay every ~500 frames instead)
[19:59:32 CET] <matto312> Thx, this info is super helpful
[20:02:30 CET] <kepstin> but yeah - in general with video for computer playback, you should send the video with the framerate as-is, and let the remote player time the frames as best as possible given its local monitor refresh rate.
[20:02:51 CET] <kepstin> for *non* computer video, it's a different story :)
[20:03:35 CET] <matto312> I have another general question that prob will make me sound dumb.
[20:03:35 CET] <matto312> Like I mentioned before, I have live RTMP input and I'm using FFMPEG to output HLS.
[20:03:35 CET] <matto312> Most of the time this works fine. However, occasionally (like 1 out 10 times) FFMPEG appears to have issues with the input.
[20:03:35 CET] <matto312> I'll see flood of messages like "st:1 invalid dropping" and the output doesn't work. It feels like randomly FFMPEG will encounter issues with the RTMP input.
[20:03:36 CET] <matto312> How would you approach an issue like this? Do you think this is an issue with the input or is it something I am doing wrong with FFMPEG.
[20:04:00 CET] <matto312> Oops, sorry about the flood of messages
[20:08:27 CET] <cehoyos> First step is to test current FFmpeg git head and provide (pastebin) the (simplified) command line including the complete, uncut console output
[20:08:52 CET] <cehoyos> Simplified means here that if you don't have a problem with the hls output, file output will make the console paste much more readable
[20:09:55 CET] <matto312> cehoyos thx, I'm on it
[20:09:57 CET] <cehoyos> In the specific case of rtmp input you can test if the native or the librtmp input work better
[20:17:32 CET] <Polochon_street> does anyone have any idea why the given command makes any `ffplay stream` have this garbage output when trying to play it back? https://paste.isomorphis.me/MWK
[20:17:58 CET] <Polochon_street> after waiting 10/15 seconds it eventually picks up the stream and plays it, but it's rather annoying not to know if I did something bad anywhere to have this output
[20:21:00 CET] <cehoyos> Note that here, only complete, uncut console output is supported, no excerpts. That being said, it is normal for transport streams to take a few seconds until reception is ok (this is true for all players, some make a lot of effort to hide the beginning from you)
[20:21:18 CET] <Polochon_street> oh, mb
[20:22:01 CET] <Polochon_street> https://paste.isomorphis.me/nJZ something like this?
[20:22:29 CET] <cehoyos> Unrelated: Putting the encoder first and the filter afterwards imo makes the command line more difficult to read, that may only be me though...
[20:22:52 CET] <cehoyos> LOL, no ;-)
[20:23:56 CET] <Polochon_street> more sth like this? https://paste.isomorphis.me/PPy
[20:24:22 CET] <Polochon_street> I'm asking because I'm trying to get this stream picked up by the hw decoder of my raspberry pi, that decodes h264 via hardware, and it just hangs forever
[20:27:13 CET] <Polochon_street> erf, my laptop kind of died right now
[20:27:33 CET] <Polochon_street> anyways, I was just wondering, maybe I'm not generating a valid h264 stream, or something like this?
[20:28:47 CET] <furq> Polochon_street: the rpi hwdec only supports yuv420p
[20:28:51 CET] <furq> same for most h264 hwdec
[20:29:44 CET] <Polochon_street> oh, so *I am* doing something wrong
[20:29:59 CET] <cehoyos> Add -pix_fmt yuv420p
[20:30:16 CET] <furq> in place of -pix_fmt rgb565le obviously
[20:30:42 CET] <furq> also for future reference you need to use libx264rgb if you actually want rgb output
[20:32:29 CET] <Polochon_street> damn, it worked like a charm
[20:32:36 CET] <Polochon_street> there's still some weird big pixels some places though
[20:33:33 CET] <furq> yeah that filter isn't going to look good in yuv420p
[20:34:33 CET] <Polochon_street> why not?
[20:35:15 CET] <furq> because it's all 1px thick coloured lines and dots on a black background
[20:36:20 CET] <Polochon_street> do you have any lead on how I could improve that?
[20:36:26 CET] <Polochon_street> would you*
[20:38:33 CET] <furq> avectorscope=rc=255:gc=255:bc=255:rf=25:gf=25:bf=25
[20:38:44 CET] <furq> or whatever monochrome values you want
[20:40:13 CET] <Polochon_street> it's not perfect, but it helped a lot, thanks :)
[20:40:36 CET] <furq> you probably also want -crf 18 or something
[20:40:45 CET] <furq> lower values = higher quality
[20:41:55 CET] <Polochon_street> even better
[20:42:05 CET] <Polochon_street> well, thanks a lot, without you I'd be stuck
[21:21:43 CET] <matto312> https://pastebin.com/ZC27A6vY ... This is error that appears to happen randomly, like 1 out of 10 times I run it
[21:42:16 CET] <Ducky^> kepstin: thanks, that makes sense!
[21:50:52 CET] <calloc> What would cause hash differences between container conversions? E.g. md5(flv) == md5(mkv) != md5(mp4)
[21:51:21 CET] <kepstin> containers are different, therefore a hash including the container will be different
[21:51:32 CET] <kepstin> or are you hashing only the streams inside the container?
[21:51:39 CET] <calloc> The streams
[21:51:50 CET] <calloc> md5(flv) == md5(mkv)
[21:51:58 CET] <kepstin> mp4 stores h264 in a different format from other containers, regarding to some headers on the nal units
[21:52:11 CET] <kepstin> the transformation is completely mechanical, and can be undone by a bsf
[21:52:17 CET] <DHE> h264 has a NAL separation mode called Annex B which is different between containers
[21:53:38 CET] <calloc> So can ffmpeg hash them in a container agnostic manner? (or even just mkv, flv and mp4)?
[21:54:38 CET] <kepstin> you could run the video from the mp4 through the -bsf:v h264_mp4toannexb to get a consistent format before hashing, i guess.
[21:54:46 CET] <furq> yeah for this case use the bsf
[21:54:56 CET] <furq> otherwise drop -c copy
[21:55:05 CET] <furq> that'll hash the decoded contents which is slower but more reliable
[21:55:33 CET] <kepstin> is that bsf a no-op if the format is already annex-b?
[21:58:09 CET] <furq> looks like it
[21:58:38 CET] <furq> [AVBSFContext @ 000001d4795c7f00] The input looks like it is Annex B already
[21:58:42 CET] <furq> yes, then
[22:01:00 CET] <calloc> Ok so copy applys some bitstream filters. Are these needed for simple no-encode remuxing? I would like to verify simple conversions.
[22:01:23 CET] <furq> depends what remuxing
[22:01:28 CET] <kepstin> remuxing might require converting the h264 bitstream format, depending on the source and destination containers
[22:01:35 CET] <furq> you can't mux annex b h264 into mp4 so that bsf gets autoinserted
[22:02:33 CET] <calloc> Ok, so my best bet would be handling the filter in the hash rather than the remux.
[22:03:11 CET] <furq> yeah
[22:03:49 CET] <calloc> Would a decode behave pretty consistently for this? I'd rather the hash handle as many filetypes as possible.
[22:04:29 CET] <furq> decoding will work for anything unless the pixel formats don't match
[22:04:50 CET] <furq> it'll be yuv420p 99% of the time though
[22:06:00 CET] <furq> that's only really a concern for lossless rgb stuff
[22:07:11 CET] <calloc> I'm a little paranoid about this service I'm writing reencoding or deleting the original media after a bad remux.
[22:09:03 CET] <kepstin> fwiw, ffmpeg will never re-encode if you ask it to copy, it'll fail instead if it can't copy.
[22:11:35 CET] <kepstin> h264 requires a bit-accurate decoder, so if you decode an h264 stream, the decoded frames will always match (although you have to make sure you're using the image memory layout - pixfmt -  if you're hashing the frame contents)
[22:11:46 CET] <kepstin> the same image memory layout
[22:12:36 CET] <rafael2k> anyone know if currently I can decode xHE-AAC/USAC with ffmpeg linked with fdk-aac v2?
[22:15:02 CET] <cehoyos> rafael2k: Can you provide a sample?
[22:15:45 CET] <rafael2k> cehoyos: yes, if needed.
[22:16:24 CET] <kepstin> looks like the fdk library supports usac, so the answer should be 'yes'
[22:17:12 CET] <calloc> kepstin: pixfmt should be handled in any copy conversions to mkv though, so that should be pretty consistent. Are there any common encodings that do not require bit-accurate decoding?
[22:17:35 CET] <cehoyos> kepstin: Do you have a sample?
[22:18:53 CET] <rafael2k> kepstin: the current anwser is no, as far as I could test
[22:18:57 CET] <kepstin> calloc: pixfmt has no relevance in copy conversions, the same video data can be decoded into a few different layouts (e.g. yuv420p, nv12) which represent the exact same data, but would hash differently.
[22:19:02 CET] <rafael2k> cehoyos: I'll prepare a sample
[22:19:09 CET] <kepstin> rafael2k: did you actually tell it to use the libfdk_aac decoder?
[22:19:19 CET] <kepstin> by default it'll use the builtin decoder.
[22:19:31 CET] <rafael2k> kepstin: good point
[22:19:36 CET] <rafael2k> kepstin: nope
[22:20:21 CET] <cehoyos> calloc: Many audio formats and mpeg-1 do not provide a bit-exact reference
[22:20:22 CET] <rafael2k> kepstin: I'll try forcing the libfdk_aac decoder
[22:20:23 CET] <kepstin> that said, some samples would still be nice, since at some point someone might want to add usac support to ffmpeg's builtin aac decoder.
[22:20:37 CET] <cehoyos> Really?
[22:34:04 CET] <rafael2k> kepstin: I'll get a DRM tx from the air and extract the xHE-AAC bitstream, in order to be sure we have a sample which we can distribute without licensing issues.
[22:35:06 CET] <kepstin> (as an aside, Digital Radio Mondiale has a very unfortunate initialism)
[22:36:22 CET] <furq> yeah everyone will think they're the direct rendering manager
[22:37:07 CET] <rafael2k> lol
[22:37:20 CET] <cehoyos> Sadly, we don't have any samples that do not have licensing issues;-(
[22:37:36 CET] <rafael2k> in past was Digital Rights Managment, now Direct Rendering Manager... wtf
[22:38:20 CET] <cehoyos> And since you mention "extracting": It's often better to provide an unchanged sample stream.
[22:38:46 CET] <rafael2k> I can provide even the I/Q stream
[22:38:47 CET] <rafael2k> ; )
[22:40:17 CET] <cehoyos> But otoh, I don't know DRM...
[22:40:41 CET] <rafael2k> This *might* have a xHE-AAC inside, but I'll try a signal from a DRM30 tx from India: https://github.com/Opendigitalradio/qt-drmplus/files/3916828/Recording_IQ_SPb_95475KHz.zip
[22:40:59 CET] <rafael2k> (which I'm sure has xHE-AAC inside)
[22:51:24 CET] <rafael2k> Found! https://ufpr.dl.sourceforge.net/project/drm/samples/DRM%20sample%20recordings/FMGold_xHE_ModeB_9khz.flac
[22:51:54 CET] <rafael2k> I hope to post a xHE-AAC if I manage to correctly extract the bitstream and decode with standalone fdk-aac v2.
[23:02:32 CET] <calloc> furq, kepstin: Thanks for the tips! Specifying the bit-stream format seems to be what I was after.
[23:11:01 CET] <matto312> I'm using FFMPEG to turn live RTMP into HLS ... most of the time it works fine but every now and then I get flooded with these errors: "DTS 4294967551, next:2147483902996 st:1 invalid dropping" ... here is the cmd and logs: https://pastebin.com/ZC27A6vY ... thx
[23:27:48 CET] <cehoyos> Your FFmpeg is 19 months old...
[23:28:20 CET] <cehoyos> Feel free to also test with --enable-librtmp
[23:46:34 CET] <rafael2k> kepstin: I found a stream with USAC: http://stream.radioh.no:443/rh.x16
[23:47:42 CET] <rafael2k> with stock ffmpeg aac I get: [aac_latm @ 0x55f7b1095f00] Audio object type 42 is not implemented.
[23:49:34 CET] <matto312> cehoyos: thx, I'm walking home, will try when i arrive :)
[23:51:28 CET] <cehoyos> How is the relation of this stream with the wav file you linked before?
[23:55:08 CET] <rafael2k> cehoyos: that wav is an I/Q recording of a DRM transmission
[23:55:18 CET] <rafael2k> forget about it
[23:57:06 CET] <cehoyos> There is no latm parser in FFmpeg and no latm decoder in libfdk, the sample stream therefore cannot be decoded atm
[23:57:32 CET] <cehoyos> How do you know that it contains "USAC"?
[00:00:00 CET] --- Wed Dec  4 2019