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

burek burek021 at gmail.com
Tue May 2 03:05:01 EEST 2017


[00:00:34 CEST] <thebombzen> that sounds weird because the data stream is in the container originally, so it should still be there
[00:00:51 CEST] <thebombzen> are you sure the input file is actually an mp4? or is it an mov?
[00:01:11 CEST] <alphabitcity> i believe it's an mp4, but let me double check
[00:01:33 CEST] <alphabitcity> .nut worked
[00:01:52 CEST] <thebombzen> I thought it would yea. but what format is the input? ffmpeg wont' tell you but "file" should be able to
[00:02:03 CEST] <alphabitcity> "1.mp4: ISO Media"
[00:02:32 CEST] <thebombzen> is there anything after that
[00:02:44 CEST] <thebombzen> anyway try remuxing to MOV and see what happens
[00:02:51 CEST] <thebombzen> MOV supports a lot more than mp4
[00:03:06 CEST] <alphabitcity> there's nothing after that
[00:05:11 CEST] <alphabitcity> the original cmd changed to .mov worked too
[00:05:31 CEST] <thebombzen> so .mov worked and .mp4 didn't?
[00:05:41 CEST] <alphabitcity> so it seems. i will try again
[00:05:41 CEST] <thebombzen> it sounds like your original file was an mov and not an mp4
[00:09:19 CEST] <alphabitcity> .mp4 and .mov both had trouble: https://pastebin.com/KZsChmPL
[00:10:31 CEST] <thebombzen> that looks like it's not trouble. and don't use -c:s copy
[00:10:34 CEST] <thebombzen> you don't have subtitles
[00:11:04 CEST] <thebombzen> what makes you say it had trouble? it copied it and it worked, right?
[00:12:35 CEST] <alphabitcity> (sorry for the slow responses. double checking everything)
[00:14:21 CEST] <alphabitcity> ok, aside from a warning, looks like .mov works .. the ouput included "other streams:420kB", which I assume refers to the data track
[00:15:27 CEST] <alphabitcity> i wonder if i can just rename output.mov to output.mp4 .. the container of 1.mp4 is "ISO Media" and the container of out.mov is "ISO Media, Apple QuickTime movie"
[00:17:54 CEST] <alphabitcity> seems to work. thank you very much @thebombzen
[00:24:33 CEST] <thebombzen> alphabitcity: do not
[00:24:46 CEST] <thebombzen> renaming the file doesn't actually make it an mp4. it's still an mov
[00:25:10 CEST] <alphabitcity> maybe the input was a .mov to begin with?
[00:36:12 CEST] <thebombzen> that is what I suggested
[00:36:28 CEST] <thebombzen> [18:05:41] <thebombzen> it sounds like your original file was an mov and not an mp4
[01:23:10 CEST] <faLUCE> so, basically, I don't understand how to demux a http mpegts stream with libav: do I have to manage http with avio or with avformat?
[01:24:30 CEST] <JEEB> there's a http avformat protocol, AVIO is needed when you need custom IO layer
[01:24:44 CEST] <JEEB> so if the lavf http thing is good enough, you can use that
[01:24:56 CEST] <JEEB> if you have issues with the lavf http thing, you can use AVIO to handle the IO yourself
[01:28:30 CEST] <faLUCE> JEEB: then, do I have to allocate two output formats separately? (one for http and one for mpegts) ?
[01:29:50 CEST] <JEEB> pretty sure if you set a muxer's output URI to "http://blah.ts" that is 1) HTTP and 2) MPEG-TS, and the latter you can set manually so the URI can be like "http://blaaaah"
[01:31:13 CEST] <faLUCE> JEEB: I see. I thought I could use only one AVFormatContext for both
[01:31:30 CEST] <JEEB> I don't get what you're saying
[01:33:02 CEST] <faLUCE> JEEB: you are saying that I have to allocate two AVFormatContexts.With the first one I unpack the HTTP packets, with the second one I demux the unpacked HTTP packets (mpegts)
[01:33:26 CEST] <faLUCE> I thought I could do that with only one AVFormatContext
[01:35:02 CEST] <faLUCE> JEEB: with rtmp-flv I remember that I can use only one AVFormatContext
[01:35:18 CEST] <BtbN> rtmp is flv over tcp
[01:35:37 CEST] <faLUCE> BtbN: I see
[01:37:01 CEST] <faLUCE> when demuxing, do I have to call av_write_frame() ? (as I do for muxing)
[01:37:36 CEST] <faLUCE> sorry, nm
[01:37:45 CEST] <faLUCE> just saw the demuxing page in the API doc
[04:08:26 CEST] <damdai> <+jludka> so you need to check what ffmpeg reports for that file. if it's wrong too, then the problem is there, and you need to report the bug to ffmpeg. mpc-hc uses lav filters, and lav filters uses ffmpeg. if ffmpeg is wrong, everything down the line will be wrong too, and it needs to be fixed in ffmpeg
[04:08:29 CEST] <damdai> is this statement true?
[04:15:46 CEST] <damdai> <+jludka> so you need to check what ffmpeg reports for that file. if it's wrong too, then the problem is there, and you need to report the bug to ffmpeg. mpc-hc uses lav filters, and lav filters uses ffmpeg. if ffmpeg is wrong, everything down the line will be wrong too, and it needs to be fixed in ffmpeg
[04:15:47 CEST] <damdai> is this statement true?
[05:18:46 CEST] <james999> yes...?
[07:35:08 CEST] <nevermind1> gu
[11:27:00 CEST] <hendry> my 4K recording from my GoPro5 seems to spat out several files. Is it possible to join them to make one large video with ffmpeg with https://trac.ffmpeg.org/wiki/Concatenate ?
[12:38:19 CEST] <meth> Do you know how to encode using an AMD GPU?
[15:05:17 CEST] <meth> OpenCL: Unable to query installed platforms
[15:05:22 CEST] <meth> are you all dead?
[15:12:13 CEST] <DelphiWorld> hey
[15:12:22 CEST] <DelphiWorld> why am i getting Failed to query surface attributes with ffmpeg & libva?
[15:19:06 CEST] <crow> I am using VDR application to watch Live TV (softhddevice plugin is as output device needed) which use ffmpeg. but here it crush on an channel switch. is this right place to provide backtrace as it seems (for me as just ordinary user) to be ffmpeg related or should i join other channels?
[15:19:53 CEST] <DelphiWorld> if its ffmpeg related, see if the vdr use the latest ffmpeg lib. if yes, provide backtrace to both of ffmpeg & vdr
[15:24:56 CEST] <alias_> Hi. I am working on a little java cli program which uses ffmpeg to convert audiobooks (audible .aax files) into mp3 files. It reads the time marks of the chapters from the aax file and creates one mp3 file per chapter.
[15:25:10 CEST] <alias_> onversion is rather fast on an audiobook with few, large chapters (e.g. 10h and chapters of 1h length), about 20x conversion speed iirc. If the audiobooks contains many short chapters (e.g. 10h, chapters of 5min length), the conversion speed is only around 3-5x.
[15:25:19 CEST] <alias_> Is there a way to speed this up? I am developing and testing on an i5 and a 64 bit linux with a recent kernel. The files bitrates are 130kbit/s. Would converting into a single mp3 file and splitting the result by chapters speed thing up? Thanks in advance!
[15:30:46 CEST] <crow> DelphiWorld i am not sure if there is enough log in backtrace but i dont see how could i provide more: https://defuse.ca/b/r8YBzfjU softhddevice plugins use ffmpeg 3.x (only installed on my system).
[16:57:29 CEST] <crow> did someone checked above back trace? is it usufull or does it need more information?
[17:09:11 CEST] <c_14> crow: looks internal to the program itself, message them
[17:09:32 CEST] <c_14> none of those threads are anywhere near libav* territory
[17:14:38 CEST] <crow> ok thank you ill contact then vdr-softhddevice plugin developer.
[18:06:17 CEST] <brian_> aha
[18:06:49 CEST] <brian_> folks: I am pretty new in Windows env and not sure how to do this in Windows ? "./configure --enable-nvenc --enable-cuda --enable-nonfree"
[18:12:45 CEST] <ariporad_> Hi all, I was hoping to get some help with using ffmpeg to add chapter markers to a MP3 file. (The file doesn't already have chapters.) AFAICT, the way I would go about this is to put the chapters in a ffmetadata file, but I'm having some trouble figuring out how to add chapter images or links using this method. If anyone had any pointers for this, that would be amazing!
[18:18:07 CEST] <brian_> folks help this newbie : I am pretty new in Windows env and not sure how to do this in Windows ? "./configure --enable-nvenc --enable-cuda --enable-nonfree"?
[18:19:34 CEST] <c_14> https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW
[18:21:49 CEST] <brian_> thanks c_14
[18:45:17 CEST] <cryptodechange> cropdetect rounds down my media to the nearest 16th, how can I do it so it's to the exact pixel?
[18:46:54 CEST] <c_14> =round=1
[18:47:17 CEST] <cryptodechange> -vf "cropdetect=24:16:0"
[18:47:29 CEST] <c_14> change 16 to 1
[18:48:16 CEST] <cryptodechange> Thanks! no change... cancelled my encode for no reason :'(
[18:48:33 CEST] <furq> it's often better to do it by eye anyway
[18:48:54 CEST] <c_14> yuv420p probably needs 2 instead of 1
[18:48:57 CEST] <cryptodechange> print screen, measure by pixels?
[18:48:57 CEST] <c_14> because even dimensions
[18:49:31 CEST] <furq> there are tools that do it
[18:50:02 CEST] <cryptodechange> Is cropdetect not an adequate tool?
[18:50:06 CEST] <furq> if you have clean black bars then cropdetect will do fine
[18:50:13 CEST] <cryptodechange> I
[18:50:16 CEST] <cryptodechange> Oh I see*
[18:50:30 CEST] <cryptodechange> Typically, blu ray sources would have clean?
[18:50:36 CEST] <furq> i should hope so
[18:51:25 CEST] <furq> it's useless for things like head switching noise, but you'd hope bluray releases wouldn't have that
[18:51:31 CEST] <cryptodechange> Doing cropdetect=1:1 gives me weird dimensions#
[18:51:54 CEST] <furq> don't change the first value
[18:55:03 CEST] <furq> fwiw if i was using cropdetect i'd probably encode a single frame to check it's close enough
[18:55:18 CEST] <furq> -i foo -vf crop=... -frames:v 1 test.png
[18:55:41 CEST] <furq> or -i foo -vf crop=... -f y4m - | mpv -
[18:56:50 CEST] <cryptodechange> How can I encode a specific frame e.g. midway the movie
[18:57:17 CEST] <furq> -ss 01:23:45
[18:58:33 CEST] <cryptodechange> hm
[18:58:41 CEST] <cryptodechange> Doing it by eye I get 1920:804
[18:59:01 CEST] <cryptodechange> Doing it by -vf "cropdetect=24:1:0" I get 1920:800
[19:48:39 CEST] <cryptodechange> Encoding a bluray with everything but the video copied, 12000kbit/s
[19:49:01 CEST] <cryptodechange> encoding just the video with everything cut out, ~5500kbit/sec
[19:49:26 CEST] <cryptodechange> I'm confused, 6500kbit was the audio?
[19:50:16 CEST] <sfan5> multiple audio tracks?
[19:51:28 CEST] <c_14> blurays tend to use very high bitrates
[19:51:28 CEST] <furq> yeah that's not unusual for dts
[19:51:40 CEST] <c_14> oh, I read that incorrectly
[19:51:42 CEST] <c_14> nvmd me
[19:51:45 CEST] <furq> dtsma is up to 25mbit
[19:52:53 CEST] <cryptodechange> aha
[19:53:04 CEST] <cryptodechange> yeah, crikey, 5 audio trackls
[19:53:11 CEST] <furq> that would also explain it
[19:53:23 CEST] <cryptodechange> I figured I'll just encode video, then mux what I want included
[19:53:50 CEST] <cryptodechange> Dang though, that's about 7gb down from a 32gb remux
[19:54:02 CEST] <furq> five regular dts audio tracks will come to about 6.5mbit
[19:54:05 CEST] <cryptodechange> with my 'nuke' settings @ 3.2 fps :P
[19:54:14 CEST] <furq> but yeah even one track can easily exceed that on a bluray
[19:54:41 CEST] <cryptodechange> 4 DTS and 1 AC3
[19:55:07 CEST] <cryptodechange> -x264-params me=tesa:level=4.1:vbv-maxrate=62500:vbv-bufsize=78125:merange=64:b-adapt=2:ref=5:bframes=16:rc-lookahead=150:trellis=2:subme=10:direct=auto:analyse=all:deblock=-3,-3:psy-rd=1,0.0:aq-strength=0.8
[19:55:17 CEST] <cryptodechange> on top of veryslow preset
[19:55:23 CEST] <furq> why are you using the vbv
[19:55:33 CEST] <furq> to say nothing of the useless shit like me-tesa
[19:55:38 CEST] <furq> s/-/=/
[19:55:49 CEST] <cryptodechange> I stole the value from handbrake
[19:56:10 CEST] <furq> and merange=64
[19:56:30 CEST] <furq> which is absolutely mental
[19:56:33 CEST] <cryptodechange> Super overkill ikr
[19:57:03 CEST] <furq> i mean if you want the feds to think you're running a grow op then it makes sense
[19:57:22 CEST] <furq> that's the only possible reason to use settings like that
[19:57:27 CEST] <furq> it certainly won't have a tangible effect on the video
[19:58:10 CEST] <furq> although it's hard to say whether that's worse than rc-lookahead=150
[19:59:08 CEST] <cryptodechange> I did have ref=16 too
[19:59:22 CEST] <furq> that actually makes sense though
[19:59:48 CEST] <furq> bframes=16 is "overkill"
[19:59:57 CEST] <furq> in that it's 99% wasted effort but occasionally will do something
[20:00:09 CEST] <cryptodechange> I primarily use plex
[20:00:11 CEST] <furq> those merange and rc-lookahead values are more than double what preset placebo uses
[20:00:25 CEST] <cryptodechange> so want to ensure compatibility, I don't mind the encode times hense the rediculous values
[20:00:31 CEST] <furq> which is called "placebo" for a reason
[20:03:42 CEST] <furq> i've said it before but it's really a waste of time using anything more involved than -preset veryslow -tune animation -level 4.1
[20:03:55 CEST] <cryptodechange> This is for bluray movies
[20:04:01 CEST] <cryptodechange> film*
[20:04:07 CEST] <furq> both in terms of encoding time and time wasted reading atrocious forums compiling The Perfect Command Line
[20:04:12 CEST] <cryptodechange> but I suppose you'd recommend film in lieu
[20:04:14 CEST] <furq> -tune film or -tune grain then
[20:04:32 CEST] <cryptodechange> temp wise, I'm at 50c
[20:04:39 CEST] <furq> 16 bframes makes even less sense for film content
[20:04:42 CEST] <cryptodechange> and still managing to use plex without issue
[20:04:48 CEST] <cryptodechange> I just run the command and leave it over night
[20:04:59 CEST] <cryptodechange> I use ref=5 now
[20:05:01 CEST] <furq> every time i've done an encode of regular film content with 8 bframes, the encoding log tells me it's never used more than 5
[20:05:24 CEST] <cryptodechange> What's the different between bframes and ref?
[20:05:48 CEST] <furq> bframes is the maximum number of consecutive bidirectional predictive frames
[20:05:55 CEST] <cryptodechange> veryslow uses ref=16, doesn't that have compatibility issues?
[20:05:56 CEST] <furq> refs is the number of frames in either direction that a b/p frame can use
[20:06:08 CEST] <cryptodechange> the source bluray is 4 ref frames
[20:06:12 CEST] <furq> and yes it does have compat issues, which is why you specify -level 4.1
[20:06:19 CEST] <cryptodechange> aha
[20:06:29 CEST] <furq> that'll clamp the value of refs to whatever the maximum the level can take is
[20:06:48 CEST] <cryptodechange> I use level=4.1 in x264-params
[20:06:54 CEST] <furq> 16 refs means the decoder has to hold 16 frames in memory, which some hardware decoders can't
[20:06:57 CEST] <furq> and er
[20:07:03 CEST] <furq> i'm not sure if that does the same thing
[20:07:21 CEST] <furq> i forget whether it's libavcodec or libx264 which clamps refs
[20:07:40 CEST] <furq> if it's libavcodec then you'd need to use -level in ffmpeg
[20:09:18 CEST] <furq> i actually normally use -preset veryslow -bf 5 -merange 16
[20:09:33 CEST] <furq> but 24 is probably better for 1080p
[20:11:50 CEST] <cryptodechange> What values would actually cause compatibility issues if set wrong? (like ref)
[20:12:04 CEST] <furq> refs is the only one i'm aware of
[20:12:22 CEST] <furq> setting -level should clamp everything as long as you don't set it to some value that's impossible at that resolution/framerate
[20:12:39 CEST] <c_14> clamping level/profile should ensure compatibility
[20:12:54 CEST] <furq> yeah, profile as well
[20:13:00 CEST] <furq> but you normally don't need to worry about that these days
[20:13:08 CEST] <cryptodechange> I'm the sort of guy who buys 64gb ram for my gaming rig
[20:13:09 CEST] <furq> most things will play high at 4.1 now
[20:13:42 CEST] <cryptodechange> so the overkill, put placebo to shame settings fits my character >_>
[20:13:55 CEST] <furq> there's very little point tweaking things beyond the presets unless you have some pathological source
[20:14:24 CEST] <cryptodechange> I should truncate the vbv all together?
[20:14:44 CEST] <furq> i don't think that's needed but i'm not an expert on hardware decoders
[20:14:52 CEST] <cryptodechange> Baby steps is needed here
[20:14:53 CEST] <furq> if you're not burning this back to a bluray then i suspect it's not needed
[20:15:11 CEST] <furq> and you're probably not or else you'd need nal-hrd=cbr and whatnot
[20:16:08 CEST] <furq> i mean use me=tesa and bframes=16 if you want, those might actually achieve something
[20:16:37 CEST] <furq> but the only effect of merange=64 and rc-lookahead=150 is that one day someone will see that in the encoding settings stanza in mediainfo and think "this guy is fucking mental"
[20:17:10 CEST] <c_14> And on that day you can go "Mission Accomplished"
[20:17:33 CEST] <cryptodechange> going to start my own scene team name
[20:17:37 CEST] <furq> they'll then see that you're using subme=10 when 11 exists, and wonder what happened there
[20:17:46 CEST] <furq> (i don't recommend 11, but if you insist on maxing everything out)
[20:17:47 CEST] <cryptodechange> iMaBitMeNTaL^_^
[20:18:00 CEST] <cryptodechange> Look out release groups
[20:18:31 CEST] <cryptodechange> in all seriousness, if someone comes up to me and tells me I'm crazy for setting x264 settings, I would've worried about being hacked more than anything
[20:18:53 CEST] <furq> i mean i'd take that over finding someone's done a 1-pass 2mbit abr encode with -preset ultrafast
[20:18:59 CEST] <furq> and yes, of course i've seen that
[20:19:09 CEST] <cryptodechange> plex uses -veryfast
[20:19:22 CEST] <furq> yeah but plex doesn't then think it'd be good to upload that to the internet
[20:19:24 CEST] <cryptodechange> Hence why I want to try and limit the bitrate to itty bitty bittys
[20:19:43 CEST] <cryptodechange> Private plex server ofc
[20:20:05 CEST] <cryptodechange> When I'm remote transcoding my media on the go
[20:20:08 CEST] <furq> of course i have also seen several different ways where someone has tagged an upload as "x264" when it isn't
[20:20:28 CEST] <furq> including the pleasant surprise of finding it's actually a dvd remux, and the less pleasant surprise of finding it's 1080 mpeg4
[20:20:29 CEST] <cryptodechange> 32gb transcoded veryfast would be better than 10gb transcoded veryfast, and faster too
[20:20:47 CEST] <cryptodechange> not be better**
[20:21:28 CEST] <cryptodechange> subme=10 vs. subme=11
[20:21:47 CEST] <cryptodechange> QPRD in all frames vs. no early termination in analysis
[20:22:16 CEST] <cryptodechange> Handbrakes says subme=10 is the most powerful option
[20:22:24 CEST] <cryptodechange> and slowest, apparently
[20:31:21 CEST] <furq> why would you listen to what handbrake has to say
[21:39:35 CEST] <kepstin> that's part of the reason to use the presets - they'll be kept up to date when options change in x264...
[22:03:16 CEST] <shincode> 1>  /usr/bin/:"/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/" 1>  ./config.mak does not exist configuring new platforms 1>  cl is unable to create an executable file. 1>  If cl is a cross-compiler, use the --enable-cross-compile option. 1>  Only do this if you know what cross compiling means. 1>  C compiler test failed. 1>
[22:03:33 CEST] <shincode> 	bash ./configure --toolchain=msvc
[22:03:38 CEST] <shincode> earlier i had this added
[22:03:42 CEST] <shincode> 	bash ./configure --toolchain=msvc --enable-pic --enable-cross-compile --target-os=win32 --host-os=win32 --arch=x86 \
[22:03:46 CEST] <shincode> its so stupid
[22:03:51 CEST] <shincode> the script the tool is foolish
[22:03:56 CEST] <shincode> im using a msys i686
[22:04:31 CEST] <shincode> i go which cl in configure and its like what?
[22:09:58 CEST] <Punkbit> I'm trying to figure out why ffmpeg does not work for me on my machine
[22:10:12 CEST] <Punkbit> installed through homebrew:
[22:10:24 CEST] <Punkbit> brew install ffmpeg --with-fdk-aac --with-tools --with-freetype --with-libass --with-libvorbis --with-libvpx --with-x265
[22:10:41 CEST] <Punkbit> mac os siera 10.12.4
[22:11:04 CEST] <Punkbit> trying to convert using command: ffmpeg -i frame%04d.png logo.mp4
[22:11:20 CEST] <Punkbit> for the image sequence frame0000.png ~ frame0140.png
[22:11:37 CEST] <Punkbit> The result is a 20kb file mp4
[22:12:58 CEST] <Punkbit> log https://pastebin.com/g34zTT0C
[22:13:33 CEST] <Punkbit> Any hints on how to fix this? Thank you!
[22:14:00 CEST] <furq> is the output file actually broken
[22:14:23 CEST] <Punkbit> 18,798 bytes (20 KB on disk)
[22:14:37 CEST] <Punkbit> `The document logo.mp4 could not be opened. `
[22:14:43 CEST] <Punkbit> The document logo.mp4 could not be opened.
[22:14:53 CEST] <Punkbit> That's the error message I get, so I think the answer is that the file is broken
[22:15:06 CEST] <furq> what gives you that error
[22:15:27 CEST] <Punkbit> the output file, logo.mp4 in this case, this is the file I tried to generate from the image sequence
[22:15:38 CEST] <furq> i mean what are you trying to open it with
[22:15:38 CEST] <Punkbit> frame0000.png ~ frame0140.png
[22:15:43 CEST] <Punkbit> Quicktime player
[22:16:00 CEST] <furq> you might want to check in a better player
[22:16:05 CEST] <furq> that log doesn't indicate anything went wrong
[22:16:05 CEST] <Punkbit> it's only 20KB though
[22:16:13 CEST] <furq> that's not impossible
[22:16:15 CEST] <Punkbit> Ok I'll check with vlc
[22:16:27 CEST] <furq> i mean it's unlikely but it depends on the source
[22:16:41 CEST] <Punkbit> Ok :) I'll download vlc player
[22:16:58 CEST] <furq> and quicktime could be breaking because it's yuv444p
[22:17:09 CEST] <furq> so yeah test with vlc or mpv
[22:17:28 CEST] <Punkbit> is there any other format I can try instead for converting this to? that is compatible with quicktime?
[22:17:38 CEST] <furq> add -pix_fmt yuv420p
[22:17:40 CEST] <Punkbit> *installing vlc
[22:18:04 CEST] <Punkbit> I'll try
[22:21:47 CEST] <Punkbit> furq: you're absolutely right! Thanks so much for your help!
[22:32:51 CEST] <crow> c_14 i compiled now ffmpeg 3.2.4 and build VDR plugin softhddevice against this and it does not crash, but with ffmpeg 3.3 it does
[23:21:26 CEST] <chicken_anda_cow> hey... I would like to change the maximum analyze duration (cause a webstream seems to send metadata too rarely). I tried -analyzeduration 140000000 but ffmpeg still insists on 7000000 :( y that?
[23:21:47 CEST] <arvut> hoi
[23:21:58 CEST] <arvut> kinda need help regarding choice of -acodec
[23:22:46 CEST] <chicken_anda_cow> (if it matters: ffmpeg version 8.0.0-110-gfe48e16)
[23:23:03 CEST] <furq> there is no such version
[23:23:26 CEST] <arvut> where can I get a list of installed audiocodecs that ffmpeg can use and which ones work for playing the finished file (from DVD, VIDEO_TS/ to .mp4 container) on a ipad2?
[23:23:46 CEST] <furq> arvut: if it's mp4 then your choices are pretty much ac3 and aac
[23:23:55 CEST] <furq> the dvd will already have ac3 on it so you might as well just not reencode
[23:24:18 CEST] <arvut> its a VHS cassette, converted to dvd with a dvd/vhs player setup, I didn't do this work. I'm doing the digitalizing steps from dvd to file
[23:24:31 CEST] <arvut> furq: oh, so I skip the -acodec option?
[23:24:34 CEST] <furq> -c:a copy
[23:24:35 CEST] <chicken_anda_cow> furq: oh no, i time-travelled again ;_;
[23:25:11 CEST] <arvut> furq: so all those long scripts with tons of options you find in various guides are mostly meaningless/obsolete?
[23:25:20 CEST] <chicken_anda_cow> -.- it's on a libreelec host (obviously the devs mixed up their version number...)
[23:25:27 CEST] <furq> most ffmpeg information on the internet is wrong, yes
[23:25:36 CEST] <furq> chicken_anda_cow: that's not even a commit hash in ffmpeg or libav
[23:25:45 CEST] <furq> so idk what's going on there
[23:26:15 CEST] <chicken_anda_cow> :/
[23:26:27 CEST] <furq> but yeah analyzeduration should go up to INT_MAX
[23:26:36 CEST] <furq> and the default is 5M, so idk where 7M is coming from
[23:28:06 CEST] <chicken_anda_cow> damn :/
[23:29:58 CEST] <furq> i guess pastebin the full command and output somewhere
[23:32:35 CEST] <chicken_anda_cow> well, obviously the libreelec devs fixed the analyzeduration. i'll try to annoy them :)
[23:43:13 CEST] <furq> https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/multimedia/ffmpeg
[23:43:20 CEST] <furq> i don't see any changes to analyzeduration in here
[23:47:54 CEST] <chicken_anda_cow> yes... it turned out that the duration was correctly set for the h264 part of the stream...
[23:48:23 CEST] <chicken_anda_cow> But for mpegts it still is 7000000 https://pastebin.com/twMn7v51
[23:48:56 CEST] <furq> oh, hls
[23:49:10 CEST] <furq> i saw someone mention a bug where analyzeduration doesn't work properly with the concat demuxer
[23:49:20 CEST] <furq> this could well be the same thing
[23:49:21 CEST] <chicken_anda_cow> ah
[23:49:35 CEST] <furq> although good luck getting a bug report past cehoyos when the version number is 8.0.0
[23:50:44 CEST] <chicken_anda_cow> yeah great... >.<
[00:00:00 CEST] --- Tue May  2 2017


More information about the Ffmpeg-devel-irc mailing list