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

[burek]

[00:21:06 CEST] <kepstin> audio can only be cut on frame accuracy (and it's tricker because some codecs need preroll too). You'll normally only get within ~25ms with aac, I think?
[01:58:21 CEST] <lmat> I'm trying to convert mp3 to CD-audio wav.
[01:58:40 CEST] <lmat> ffmpeg -i "$i" -f s16le -ar 44100 -ac 2 "$(basename "$i" .mp3).wav";  should do it?
[01:59:04 CEST] <lmat> I'm hoping that will take a mp3 file input and output signed 16-bit little-endian 44100 khz, 2-channel audio PCM wav file.
[01:59:11 CEST] <lmat> (according to the red book or whatever it's called)
[01:59:24 CEST] <lmat> (I'm then going to feed these files into cdrecord to burn the disk)
[01:59:35 CEST] <lmat> I ran that conversion, but ffplay doesn't play the audio.
[01:59:43 CEST] <lmat> "Invalid data found when processing input"
[02:03:23 CEST] <lmat> hmm, looks like that ffmpeg command didn't write the RIFF header information?!?
[02:18:04 CEST] <fella> lmat: try '... c:a pcm_u8 ...' instead
[02:19:21 CEST] <relaxed> this has always worked for me, ffmpeg -i "$i" -map 0:a:0 "${i##*/}".wav
[02:21:42 CEST] <relaxed> er, "${i%.*}".wav
[02:31:35 CEST] <lmat> fella: u8!? that's an 8-bit format?
[02:32:25 CEST] <lmat> relaxed: What does 0:a:0 do?
[02:34:10 CEST] <fella> lmat: kk, so 'pcm_s16le' might be a better choise ;)
[02:34:40 CEST] <lmat> relaxed: I did as you suggest, then cdrecord says, "Inappropriate audio coding in 'song.wav'."
[02:37:16 CEST] <furq> lmat: you want -c:a pcm_s16le and get rid of -f s16le
[02:37:27 CEST] <furq> -f overrides the output format, so it's just writing raw pcm data
[02:37:38 CEST] <lmat> OH!
[02:38:18 CEST] <lmat> furq: and stereo?
[02:38:25 CEST] <furq> that's covered by -ac 2
[02:38:31 CEST] <furq> although i assume your mp3s are stereo anyway
[02:38:52 CEST] <furq> also yeah use ${i%.*}.mp3 or some other suitable shell expansion
[02:39:20 CEST] <furq> or uh
[02:39:21 CEST] <furq> .wav
[02:39:32 CEST] <lmat> sure
[02:39:46 CEST] <lmat> hey, cdrecord is doing it!
[02:39:56 CEST] <furq> -ac 2 -ar 44100 will just be no-ops if your source is 44.1k stereo anyway
[02:39:59 CEST] <furq> so there's no harm leaving them in
[02:40:11 CEST] <lmat> furq: I have no reason to think the source is as you mention.
[02:40:25 CEST] <furq> sure
[02:40:29 CEST] <furq> like i said, leave them in
[02:42:25 CEST] <lmat> aye
[02:43:55 CEST] <lmat> thanks so much! \o/
[02:44:01 CEST] <lmat> Now it says I have too much data ^_^
[02:45:17 CEST] <relaxed> when trying to grab two seconds of video with -vf 'select=between(t\,10\,12)', it appears to be decoding the whole file
[02:47:14 CEST] <relaxed> lmat: pastebin.com your command and output
[02:48:43 CEST] <lmat> relaxed: I think I'm good to go. I was trying to put beethoven symphony 5,7, piano concerto 5, piano sonata 8, and a string quartet. I think it's legitimate ^_^
[02:49:02 CEST] <relaxed> ah, too much data on the cd
[02:49:10 CEST] <lmat> relaxed: too much audio. Fo sho
[02:52:43 CEST] <furq> yeah you only get about 80 minutes on a cd
[02:53:22 CEST] <furq> emphasis on "about" because i've seen 87 minutes
[02:53:35 CEST] <furq> but i can't imagine anyone is still making blanks that are capable of that
[02:54:20 CEST] <lmat> Yeah, I've always been fuzzy ^_^
[02:54:31 CEST] <lmat> My disk says "52X 700MB 80min"
[02:54:42 CEST] <furq> you can overburn pretty much any blank
[02:54:52 CEST] <furq> but whether you get one second or five minutes is impossible to know until the write fails
[08:25:43 CEST] <sharax> hello
[08:26:42 CEST] <sharax> i want install ffmpeg on centos 7 and php 7
[08:26:45 CEST] <sharax> can help me?
[08:55:11 CEST] <JEEB> sharax: php-ffmpeg or whatever has nothing to do with FFmpeg. sorry
[08:55:18 CEST] <JEEB> spamming your message will not help you
[08:55:32 CEST] <JEEB> for FFmpeg there IIRC is a compilation guide on the wiki just for FFmpeg
[15:23:46 CEST] <tytan> Hello everyone, I may have a trivial question. Why is ripping a DVD on GNU/Linux not as easy as "ffmpeg -i /dev/cdrom -c:v libx265 dvd.mp4" ? Usually ffmpeg accepts everything as an input for what I have done.
[15:33:06 CEST] <Hello71> for one, last I checked, ffmpeg didn't support reading ISO9660/UDF files
[15:37:43 CEST] <Mavrik> DVDs also tend to be DRM protectd
[15:38:58 CEST] <relaxed> there were many tools already that ripped DVDs, like vobcopy
[15:42:15 CEST] <furq> tytan: nobody has been bothered to add dvdnav support
[15:42:29 CEST] <tytan> I don't know what that is, sorry
[15:43:04 CEST] <furq> libdvdnav
[15:43:19 CEST] <furq> more or less the dvd equivalent of libbluray
[15:43:23 CEST] <furq> which is supported
[15:44:17 CEST] <tytan> ok, can I just get libdvdnav and expect ffmpeg to accept a DVD as input then? Does it mean ffmpeg can rip BluRays easily?
[15:45:01 CEST] <furq> no and yes
[15:45:04 CEST] <tytan> damn
[15:46:29 CEST] <furq> if your disk is encrypted and you have libdvdcss installed then you can probably just pipe from vobcopy
[15:46:45 CEST] <furq> so something like vobcopy -M -o - | ffmpeg -i - -c:v libx265 dvd.mp4
[15:48:48 CEST] <furq> maybe vobcopy needs -l as well, i forget now
[15:49:08 CEST] <tytan> what input does vobcopy expect? /dev/cdrom?
[15:50:11 CEST] <furq> it wants the mountpoint iirc
[15:50:17 CEST] <furq> i've not used it in years
[15:51:40 CEST] <tytan> same :/
[15:51:57 CEST] <tytan> well, I haven't used an optical disc in years
[15:52:30 CEST] <Nacht> I dont even have an optical drive anymore
[15:53:35 CEST] <tytan> that's the point. I ditched my last optical drive in 2011
[15:54:03 CEST] <tytan> now I try to rip that one DVD for a friend with an external drive because I was like yeah ffmpeg can do everything :D
[15:59:25 CEST] <tytan> I'm trying to pipe vobcopy into ffmpeg now. it starts by creating "1-1.vob.partial" in the directory
[16:08:08 CEST] <King_DuckZ> hello, I have a webm file for which ffprobe returns this https://alarmpi.no-ip.org/kamokan/cq?colourless the problem is in my c++ code the object returned by avformat_alloc_output_context2() has nb_streams == 0
[16:08:12 CEST] <King_DuckZ> is that normal?
[16:08:18 CEST] <King_DuckZ> how can it be?
[16:08:36 CEST] <JEEB> no packets have been read yet?
[16:08:59 CEST] <JEEB> there's a probing function as well as you could just read stuff yourself until you think you've had enough
[17:04:56 CEST] <King_DuckZ> JEEB: I'm refactoring some code and I think it used to work... let me see if I can see this probing function anywhere
[17:05:11 CEST] <King_DuckZ> or if it was just reading straight away
[17:10:46 CEST] <JEEB> King_DuckZ: http://svn.ffmpeg.org/doxygen/trunk/group__lavf__decoding.html#gad42172e27cddafb81096939783b157bb
[17:19:25 CEST] <King_DuckZ> JEEB: thanks
[17:22:38 CEST] <King_DuckZ> funny: "options If non-NULL, an ic.nb_streams long array of pointers" but then you need to call this function before you get something meaningful in nb_streams
[17:22:51 CEST] <King_DuckZ> I'm just passing null btw
[17:48:46 CEST] <King_DuckZ> is there any way to tell if an AVFormatContext was allocated with avformat_open_input() or avformat_alloc_output_context2() ? so that I know if I should call avformat_close_input() or not before avformat_free_context()?
[17:50:22 CEST] <King_DuckZ> or is it safe to just call it all the time?
[19:38:55 CEST] <chocolate-elvis> does anyone know of a clever way to check the output of 8bit per channel, 10 and 12? to make sure the bit depth is being maintained? using ffmpeg to decode 12bit jp2k files and passing to a AVFoundation ProRes encoder
[19:41:52 CEST] <furq> chocolate-elvis: if you're encoding with ffmpeg the info dump before it starts encoding will list the pixel format
[19:41:58 CEST] <furq> if it ends in 12le or 12be then it's 12-bit
[19:43:04 CEST] <chocolate-elvis> got it - 12bit little endian vs big endian. any way to programmatically test the bit depth is being maintained in an encoding pipeline? from start to finish? its a strange question I know!
[19:43:43 CEST] <chocolate-elvis> y'know. to make sure it's actually working? thought about creating some test ramps in nuke, but not sure...
[19:44:10 CEST] <chocolate-elvis> if there's a better way
[19:44:41 CEST] <furq> if part of the chain is outside of ffmpeg then i don't know of anything
[19:57:57 CEST] <ilushka4> Hey guys, for some reason, I have a rtsp(mms) stream which I can run with windows media player, but cannot run it with ffmpeg (first tried it with ffmpeg-python and then ffplay). I was trying the query: .\ffplay.exe -i "mms://foobar" -f rtsp, but it returns 400 Bad request
[21:54:51 CEST] <fella> ilushka4: is it a public stream?
[21:55:48 CEST] <GuiToris> hey ChocolateArmpits, can you check this mediainfo output? https://ptpb.pw/dTWE I've followed your advise and I got 'Not Supported Video' again
[21:55:57 CEST] <GuiToris> what did I mess up this time?
[21:56:27 CEST] <GuiToris> I found some differencies but I don't know if they matters
[21:57:15 CEST] <GuiToris> it's Main at L5.1 instead of Main at L5 and 16 frames instead of 5
[21:57:50 CEST] <GuiToris> other than these one, I haven't found anything peculiar
[21:58:16 CEST] <relaxed> GuiToris: that could be it, if 5 doesn't work try 4.1
[21:58:36 CEST] <GuiToris> Main at L5 has worked
[21:58:46 CEST] <GuiToris> I assume 5.1 is not much different
[21:59:18 CEST] <GuiToris> I used yuv420p and profile main
[22:00:12 CEST] <relaxed> ok, use -level 5
[22:01:18 CEST] <relaxed> and -t 10 to create a 10 second sample.
[22:02:56 CEST] <GuiToris> does 'preset veryslow' messes around?
[22:03:12 CEST] <GuiToris> I used to be able to play all my video
[22:03:20 CEST] <GuiToris> s
[22:04:00 CEST] <relaxed> I'm pretty sure -level will set limits to presets
[22:09:33 CEST] <GuiToris> it became High at L5
[22:10:20 CEST] <relaxed> GuiToris: -profile:v main -level:v 5
[22:10:29 CEST] <GuiToris> yes, I've just realized
[22:22:54 CEST] <GuiToris> relaxed, so I'm back, it's not the 5.1 that causes the problem
[22:23:24 CEST] <GuiToris> I reencoded the encoded video and I made 4 5 and 5.1 all worked
[22:24:39 CEST] <GuiToris> what does CABAC / 4 Ref Frames mean?
[22:24:42 CEST] <GuiToris> that's different
[22:30:35 CEST] <ChocolateArmpits> GuiToris, https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding
[22:31:11 CEST] <ChocolateArmpits> And "Ref Frames" signifies "the size of the DPB (Decoded Picture Buffer). "
[22:32:07 CEST] <GuiToris> wow, you are really educated!
[22:32:14 CEST] <ChocolateArmpits> I just know the links
[22:32:19 CEST] <ChocolateArmpits> here http://www.chaneru.com/Roku/HLS/X264_Settings.htm#ref
[22:33:01 CEST] <ChocolateArmpits> some more about Refs https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Decoded_picture_buffering
[22:33:13 CEST] <GuiToris> do you think it can really cause incompatibilty?
[22:33:34 CEST] <ChocolateArmpits> too high ref count could, but at 4 frames, certainly not
[22:34:04 CEST] <ChocolateArmpits> CABAC could only be an issue with very old slow hardware decoders
[22:34:11 CEST] <GuiToris> it's 16 currently, as I see it's the highest
[22:34:37 CEST] <ChocolateArmpits> could you paste the output once more I think the link is dead
[22:34:44 CEST] <GuiToris> sure
[22:35:30 CEST] <GuiToris> https://ptpb.pw/dTWE
[22:35:49 CEST] <ChocolateArmpits> GuiToris, where are you trying to import it to?
[22:36:18 CEST] <GuiToris> does import mean play here?
[22:36:43 CEST] <GuiToris> this would be the final video, I just can't play on our TV - again
[22:36:52 CEST] <ChocolateArmpits> oh just remember
[22:36:53 CEST] <ChocolateArmpits> right
[22:36:56 CEST] <ChocolateArmpits> remembered*
[22:37:30 CEST] <ChocolateArmpits> GuiToris, have you gotten any other combination of AVC+Vorbis playing ?
[22:37:47 CEST] <ChocolateArmpits> because that's an awkward mix
[22:39:19 CEST] <GuiToris> https://ptpb.pw/2SSP
[22:39:26 CEST] <GuiToris> that's what we did a couple of days ago
[22:39:33 CEST] <ChocolateArmpits> that one works right?
[22:39:42 CEST] <GuiToris> it worked, yes
[22:39:55 CEST] <GuiToris> I don't know why is it AVC and if I reencode it's different
[22:40:18 CEST] <GuiToris> I suspect veryslow causes these problems
[22:41:53 CEST] <GuiToris> this is the reencoded output https://ptpb.pw/N93O
[22:41:54 CEST] <ChocolateArmpits> GuiToris, well you can try matching the profile level, refs count, bframe count
[22:42:17 CEST] <GuiToris> it became avc1 here
[22:43:01 CEST] <GuiToris> I've tried 5.1 is not a problem
[22:43:32 CEST] <GuiToris> I'll try this ref number
[22:43:55 CEST] <ChocolateArmpits> the parameter is -refs for ffmpeg
[22:44:06 CEST] <relaxed> GuiToris: try this, ffmpeg -i input -t 10 -profile:v main -level:v 4.1 -preset veryslow -c:a aac -b:a 192k -movflags +faststart output.mp4
[22:44:36 CEST] <GuiToris> vorbis is not a problem
[22:45:38 CEST] <relaxed> ok, then use -profile:v main -level:v 4.1 -preset veryslow
[22:45:52 CEST] <relaxed> you shouldn't need to change the refs by hand
[22:47:39 CEST] <GuiToris> your previous line also worked 4, 5 or even 5.1 worked
[22:47:50 CEST] <GuiToris> -I reencoded the video-
[22:48:04 CEST] <GuiToris> but this isn't a good idea, is it!?
[22:48:52 CEST] <GuiToris> I think I should make a new one, but I don't know what makes the incompatibility
[22:49:20 CEST] <GuiToris> when I reencoded the encoded video from 5.1 to 5.1, it worked
[22:49:33 CEST] <GuiToris> I didn't use veryslow this time
[22:49:36 CEST] <relaxed> the problem is setting -preset veryslow with a -level that's too high
[22:51:34 CEST] <GuiToris> I think you're right, I didn't have any problems while I used medium
[22:53:24 CEST] <GuiToris> the original encoding took about 6 hours, I may not redo the whole thing but reencode this one with 'ultrafast' 'main' and 'yuv420p' and store it on a flashdrive
[23:04:14 CEST] <tytan> Hello everyone, I tried to convert a VP9 webm to a H265 mp4 with the latest static release of ffmpeg on windows using the -c:v hevc_amf option but it just failed. Windows 10 1809, RX Vega 64 driver 18.5.1
[23:07:58 CEST] <tytan> wait, it wailed on a 8K video but worked on a 720 file?!
[23:08:02 CEST] <tytan> *720p
[23:12:03 CEST] <tytan> *worked
[23:27:02 CEST] <GuiToris> relaxed, ChocolateArmpits I've tried level 4.1 which also decreases the ref number and it can be played even if I use veryslow preset
[23:27:32 CEST] <GuiToris> does this also reduce the quality of the picture?
[23:29:46 CEST] <relaxed> not to the human eye, stick with 4.1
[23:32:24 CEST] <GuiToris> thank you for your help!
[23:41:39 CEST] <kepstin> tytan: i haven't seen any published docs on the limits of amd's hardware encoder, but I wouldn't be surprised if it maxes out at 4k.
[23:42:14 CEST] <tytan> too bad because encoding 8K takes a long time even on an 8-core CPU
[23:46:05 CEST] <tytan> are there any hardware encoders that don't produce awful results? I'm pretty disappointed of h264_videotoolbox
[23:46:46 CEST] <kepstin> tytan: no, they're all pretty much like that. Designed to perform realtime or faster encoding on a limited power budget, that's just what you get.
[23:47:24 CEST] <tytan> so libx264 and libx265 are my best quality options for mp4?
[23:47:44 CEST] <kepstin> yep
[23:48:32 CEST] <tytan> and stuff like minterpolate is always crazy slow if you want actual motion interpolation and not blend?
[23:48:40 CEST] <kepstin> http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf says that Vega's hardware encoder maxes out at 2160p60
[23:48:46 CEST] <kepstin> (aka 4k 60Hz)
[23:48:52 CEST] <tytan> nice to know, thanks
[23:50:06 CEST] <kepstin> well, motion interpolation is always gonna look bad no matter how fast or slow it runs ;)
[23:50:30 CEST] <tytan> would you suggest something else?
[23:51:00 CEST] <kepstin> I'd suggest leaving the video at its original framerate
[23:51:45 CEST] <kepstin> (or if necessary to increase video framerate for technical reasons, use the fps filter which will duplicate frames - it might introduce judder, but it'll overall keep the same "look")
[23:52:58 CEST] <tytan> the -r option?
[23:53:16 CEST] <kepstin> the -r output option is not entirely unlike the fps filter
[23:53:25 CEST] <kepstin> (the fps filter has better rounding behaviour)
[23:53:32 CEST] <tytan> ok
[00:00:00 CEST] --- Fri Oct  5 2018