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

Tue Dec 24 03:05:02 EET 2019

[00:00:34 CET] <nicolas17> your division gives 48 kilobytes, now multiply by 8 to get kilobits
[00:03:17 CET] <shibboleth> BtbN, reason i asked is that even ffmpeg master doesn't list nvenc/nvdec
[00:03:50 CET] <shibboleth> even if compiled with --enable-nvdec/nvenc
[00:04:29 CET] <BtbN> They're not hwaccel modes.
[00:06:20 CET] <shibboleth> -hwaccel nvdec/nvenc does work as an lias without having to specify in/out codecs for cuvid though
[00:06:26 CET] <shibboleth> alias
[01:27:47 CET] <wondiws> what format are those vobsub subtitles? "file" gives me MPEG sequence, v2, program multiplex
[01:28:25 CET] <wondiws> vobsub is the same format as the original DVD subtitles, albeit repackaged, although I'm not even sure if they are actually repackaged
[02:12:09 CET] <cehoyos> BtbN: I just tested and I can confirm that "-f image2 -loop 1" reads the input file again and again.
[09:36:58 CET] <veek> how do i join and sync two .ts files that I download manually
[09:37:17 CET] <veek> just cat'ing them doesn't work
[09:40:27 CET] <veek> nm got it working
[09:41:53 CET] <JEEB> how well concatenating two MPEG-TS things works depends on how completely wonky the timestamps are compared to each other. that said, most of the cases where I've had to repeat content or so, it's worked alright. depends on the playback software of course
[09:56:31 CET] <veek> thanks
[11:35:54 CET] <wondiws> does anybody know by any change how to extract the subtitle stream from a *.vob file in linux? I use mpegdemux to extract the AC3 sound, and in Windows I use VobSub or VSRip (which is the same I believe?) to extract the subtitles, but how do you do this in linux?
[11:36:20 CET] <wondiws> I tried mpegdemux to extract the subtitle stream the same way as the audio stream, but the resulting file didn't make sense to me
[13:49:43 CET] <cehoyos> wondiws: Your question is difficult to understand: dvd subtitles only make sense inside a vob file (an mpeg program stream), you can export them to a raw stream but as you found out, the resulting file is not very useful
[13:50:14 CET] <pink_mist> I think he's asking for OCR stuff
[13:50:26 CET] <pink_mist> iirc vobsubrip is an ocr thing
[13:50:27 CET] <wondiws> pink_mist, no
[13:50:34 CET] <wondiws> I don't want to do OCR
[13:50:46 CET] <cehoyos> What do you want to do?
[13:51:43 CET] <wondiws> the subtitles are monochrome pictures in the MPEG stream. Vobsub/VSRip (in Windows) extracts them from a MPEG2/VOB stream and puts it in a *.sub file, which is again an MPEG2 stream, but with just the subtitles in it
[13:51:57 CET] <wondiws> is there a similar program for linux like Vobsub or Vsrip?
[13:52:34 CET] <JEEB> we can read the idx+sub thing at least
[13:52:35 CET] <wondiws> you can then mux the *.sub file into a mkv file for instance, or use it as an external file
[13:52:37 CET] <cehoyos> You are in the FFmpeg support channel, why do you expect to get support for any other software? (FFmpeg is able to read and write vob files, and it sounds as if your sub file actually is a vob file)
[13:52:54 CET] <JEEB> cehoyos: he wants to explain his needs in the words of that other software
[13:52:56 CET] <wondiws> yes, sub is MPEG2/VOB format too
[13:52:58 CET] <JEEB> not getting help with that other software
[13:53:18 CET] <furq> there is no vobsub muxer
[13:53:23 CET] <wondiws> JEEB but ffmpeg also has code for vobsub, am I right?
[13:53:27 CET] <JEEB> only for reading
[13:53:29 CET] <JEEB> unfortunately
[13:53:29 CET] <furq> ^
[13:53:40 CET] <JEEB> see libavformat/mpeg.c
[13:53:44 CET] <JEEB> that has idx reading etc
[13:53:55 CET] <furq> tcdemux from transcode will do it
[13:54:05 CET] <furq> and i think mencoder as well but idk how
[13:54:10 CET] <wondiws> furq, what is tcdemux?
[13:54:32 CET] <furq> https://linux.die.net/man/1/tcdemux
[13:54:48 CET] <furq> it's part of transcode which isn't developed any more so it fell out of a lot of package managers
[13:54:50 CET] <wondiws> I will have a look
[13:55:26 CET] <furq> mkvtoolnix will also do it but only if you go via mkv first iirc
[13:55:27 CET] <wondiws> furq, then I will compile it myself ;)
[13:55:53 CET] <furq> ffmpeg will mux an mkv with just a dvd subtitle stream and then mkvextract can remux that to vobsub
[13:55:54 CET] <JEEB> but yea, I'm surprised "sub" was actually an MPEG-2 PS structure :P I would have guesstimated it to be just the packets one after another without the unnecessary parts
[13:55:58 CET] <furq> that's probably the least annoying way of doing it
[13:55:59 CET] <wondiws> furq, mkvtoolnix also allows me to extract vobsub subtitles from a mkv file, yes
[13:56:08 CET] <wondiws> but it's not in an mkv file, it's in a vob file ;)
[13:56:45 CET] <pink_mist> but you wanted to put it in a mkv file?
[13:56:46 CET] <wondiws> furq, that's not a bad way actually
[13:56:57 CET] <wondiws> pink_mist, I might
[13:57:06 CET] <pink_mist> afaik mkvtoolnix should support getting things from vob and put in a mkv directly
[13:57:13 CET] <wondiws> pink_mist, ah, even better
[13:57:34 CET] <wondiws> the idx file is just plain text, so that should be easy to convert
[13:57:39 CET] <wondiws> just the timestamps
[13:58:19 CET] <wondiws> or I suppose I could just delete everything from a VOB/MPEG2 stream apart from the subtitles :P
[13:58:24 CET] <wondiws> and rename the file to *.sub
[14:00:41 CET] <wondiws> mkvtoolnix doesn't see subtitles in a vob\
[14:03:27 CET] <furq> mkvtoolnix has a vobsub muxer
[14:03:45 CET] <furq> mkvextract foo.mkv tracks 2:bar.idx
[14:04:09 CET] <furq> or whatever track mkvmerge --identify says
[14:04:52 CET] <furq> unfortunately it doesn't read dvd structures so you'll still need some intermediate tool
[14:06:32 CET] <wondiws> furq, exactly
[14:06:53 CET] <furq> nvm i misread what you siad
[14:08:20 CET] <furq> one of these days i should strip out all the actual transcoding stuff from transcode and make a standalone tccat and tcdemux
[14:08:37 CET] <furq> i'm sure it all has hard dependencies on a bunch of awful shit though
[14:31:44 CET] <wondiws> furq, indeed, I can't compile transcode
[14:31:59 CET] <wondiws> CODEC_ID_AC3 and CODEC_ID_MP2 undeclared
[14:32:09 CET] <DHE> AV_CODEC_ID_AC3 ?
[14:32:50 CET] <wondiws> DHE, probably, I assumed the definitions have changed as this code is from 2003 or something. I didn't know those constants by heart myself though
[14:33:06 CET] <DHE> 2003? I think that's a new record
[14:35:11 CET] <wondiws> does <libavcodec/opt.h> still exist?
[14:35:28 CET] <DHE> no
[14:40:53 CET] <furq> yeah this is probably why it's dropped out of package managers
[14:42:14 CET] <void09> can someone explain to me again the difference between having -ss/-to before/after the input file path ?
[14:42:41 CET] <void09> I cannot really figure it out from the docs explanation
[14:42:47 CET] <wondiws> furq, I compiled it though, without ffmpeg support, sorry ;)
[14:46:28 CET] <DHE> void09: before -i means it applies to the input, seeking before video decoding. after -i means it applies to the output meaning the output discards input until it arrives at the indicated point in time
[14:46:37 CET] <void09> ohhhhhhhhhhhhhh
[14:46:39 CET] <void09> that easy, lol
[14:47:00 CET] <void09> so the after -i is more accurate
[14:47:08 CET] <DHE> before -i can instantly seek anywhere, but lacks precision due to keyframe requirements. after -i means you'll have to wait while the input is decoded, but it can do far more precise seeks (as long as you're not doing stream-copy)
[14:47:11 CET] <void09> but in case of well indexed .mkv files, it should be the same ?.
[14:47:16 CET] <furq> wondiws: if tccat/tcdemux work without ffmpeg support then that's great news for me
[14:47:28 CET] <furq> i assume they do but i've never looked into it
[14:47:38 CET] <void09> DHE: my scenario is serving files over http to do frame accurate encoding of segments
[14:47:51 CET] <void09> think i can do it with just -ss -to before -i ?
[14:47:52 CET] <wondiws> furq, it seems it works, but I have never used this before, so I have to get acquianted
[14:48:04 CET] <void09> so the whole file does not get downloaded for a tiny segment
[14:48:06 CET] <DHE> void09: only if every frame is a keyframe because the seek MUST land on a keyframe
[14:48:34 CET] <void09> no, they're not always keyframes :\
[14:48:41 CET] <void09> but does not the mkv index help with this ?
[14:48:52 CET] <void09> to figure out exactly where each timestamp is ?
[14:48:54 CET] <DHE> the index is really just a keyframe list
[14:49:01 CET] <wondiws> furq, yes, I can extract ac3 audio with tcextract
[14:49:15 CET] <DHE> you can't seek to anything except a keyframe because you can't play video without starting on a keyframe
[14:49:28 CET] <void09> yes, but can't ffmpeg go to the keyframe before the timestamp, if it's before, and just decode the missing frames until it gets to the precise point ?
[14:49:38 CET] <DHE> unless you do crazy shenanigans like play audio with no video (because audio tends to be 100% keyframes by this definition)
[14:50:04 CET] <DHE> void09: I don't think this is a feature ffmpeg has, but you could implement it yourself in a custom application.
[14:50:48 CET] <void09> so i have to download 30GB for 3 seconds :\
[14:52:25 CET] <DHE> or maybe get creative?
[14:53:36 CET] <wondiws> furq, or maybe I should port VSRip to linux :P
[14:53:48 CET] <void09> DHE: i don't feel too creative today
[14:54:04 CET] <void09> i will test, maybe it somehow works
[15:27:18 CET] <Hello71> -ss is now fast as an input option.
[15:28:16 CET] <Hello71> according to the wiki.
[16:05:32 CET] <DHE> -ss was always fast as an option option, but it lacks precision
[16:08:52 CET] <Hello71> uh
[16:08:55 CET] <Hello71> right, the other one
[16:09:16 CET] <DHE> oh?
[16:13:27 CET] <void09> I am doing a ffmpeg -ss -to -i http:// encode to x264 in .mp4.with mp4 i get the video length as reported by vlc/mpv as being the total length of the input. if i use .mkv i get the right output length (1 second)
[16:13:32 CET] <void09> what am i missing ?
[16:13:55 CET] <void09> is it a bug or a feature ?
[16:29:32 CET] <Hello71> it is accurate now
[16:32:31 CET] <void09> Hello71: -ss is fast as an output option ?
[16:32:44 CET] <void09> relevant paragraph ?
[17:23:56 CET] <void09> need help with quoting http input source, ' and " do not work
[17:24:29 CET] <void09> no wary around having spaces but replacing with %20 ?
[17:32:43 CET] <void09> https://trac.ffmpeg.org/ticket/2031
[17:32:51 CET] <void09>      Status changed from closed to reopened
[17:32:51 CET] <void09> The commit was reverted.
[17:32:52 CET] <void09> :))
[17:42:31 CET] <johnjay> hrm. what's the reason consoles were 240p?
[17:43:26 CET] <johnjay> the NES for example is 256x240. this video is saying it was to be on 483 interlaced tv? https://www.youtube.com/watch?v=zwDPx6hP_4Y
[17:46:43 CET] <c0fe> i am running a command to convert m2ts file to mkv and i am getting the following error messages:
[17:46:45 CET] <c0fe> Duplicate element
[17:46:46 CET] <c0fe> Truncating packet of size 257103 to 4206
[17:47:02 CET] <c0fe> Duplicate element
[17:47:12 CET] <c0fe> "/media/power/seagate/g/disc1p1/00001.m2ts: End of file"
[17:47:32 CET] <c0fe> i am running ffmpeg -i "/media/power/seagate/g/disc1p1/00001.m2ts" -scodec copy -acodec copy -vcodec copy -f matroska "/media/power/seagate/g/jap03.mkv"
[17:47:33 CET] <c0fe> why?
[17:49:11 CET] <c0fe> well looks like that file is corrupt because the next file throws up No wav codec tag found for codec pcm_bluray
[17:49:12 CET] <c0fe> av_interleaved_write_frame(): Invalid argument
[17:49:12 CET] <c0fe> Error writing trailer
[17:55:29 CET] <nate> johnjay: Why?  perhaps because the NES came out in 1985 and we didn't exactly have 1080p displays being rolled out back then lol
[17:55:51 CET] <johnjay> well i didn't understand his explanation in the video to save money
[17:56:00 CET] <johnjay> why not do 480i if that's what they had
[17:56:19 CET] <johnjay> and if they didn't then... well it's really 30fps then isn't it?
[17:56:36 CET] <johnjay> because the tv is 30 interlaced frames even and 30 interlaced frames odd
[18:02:22 CET] <nate> johnjay: Format standards are going to be the main factor in frame/refresh rate, keeping in mind NTSC (as it would have been during NES' days), PAL and SECAM.  As for the somewhat halved-ish resolution of at the time, it was indeed probably hardware limitations I would believe
[18:03:14 CET] <johnjay> so it would literally be 1 interlaced frame, then black, then 2nd interlaced frame, then black, etc ?
[18:03:20 CET] <johnjay> i guess that makes sense
[18:03:35 CET] <johnjay> for some reason i don't remember NES game i play as a kid as interlaced with black lines lol
[18:07:46 CET] <kepstin> the nes (and similar) 240p output is actually not quite that
[18:08:08 CET] <kepstin> it actually still outputs 60 fields per second, it's just that they're all field 1
[18:08:29 CET] <kepstin> with most tvs this would cause it to scan the same set of 240 scan lines repeatedly, 60 times a second.
[18:09:26 CET] <kepstin> (tvs usually are a bit blurry so the scan lines from the first vs second field overlap a bit, so the missing lines weren't usually super noticable, particularly on smaller screens)
[18:11:33 CET] <johnjay> maybe i don't understand the crt then
[18:11:56 CET] <johnjay> i thought it was part of the tech that you do 30 lines odd then 30 lines even alternate to get interlaced
[18:12:39 CET] <johnjay> if you can do 60 times per second the odd lines then why not do that for movies as well?
[18:22:08 CET] <Hello71> kepstin: so... 120p?
[18:22:37 CET] <kepstin> no, it's 240p instead of 480i
[18:23:18 CET] <kepstin> with 480i, it does 240 lines marked as field 1, then 240 lines marked as field 2, alternating. The tv offsets to the ones marked as field 2 to fill in the gaps between the lines from field 1
[18:23:24 CET] <Hello71> uh, right
[18:24:15 CET] <kepstin> with the 240p output, it sends 240 lines marked as field 1, then another 240 lines marked as field 1 again. The result is that the tv draws the second "field" over top of where the previous was drawn, making it effectively progressive.
[18:24:35 CET] <kepstin> (i forget if it actually outputs field 1 or field 2, but that doesn't really matter for this)
[18:25:58 CET] <kepstin> the downsides are that you have less vertical resolution (enough to be noticeably less detail in live action video) and depending on the tv, the gaps between lines might be noticable
[18:29:25 CET] <kepstin> this also means that doing video capture of a nes tv output is a pain, you need equipment that can handle the out-of-spec signal and do something reasonable with it.
[18:29:43 CET] <kepstin> some modern hdtvs can't accept it as an input signal, for example :/
[18:29:55 CET] <johnjay> hrm. so this is basically a human issue not a technical one? i.e. having constant black lines is fine for an 8-bit console but not for live action?
[18:30:21 CET] <kepstin> the consoles were so low resolution anyways due to lack of ram that it wasn't an issue
[18:30:53 CET] <kepstin> later consoles with more memory switched to doing proper 480i output to get higher resolution
[18:32:02 CET] <kepstin> (some, like the ps2 and wii, could actually do 480p on supported games with appropriate cables and equipment)
[18:32:18 CET] <kepstin> that would be 480p 30Hz
[18:32:43 CET] <johnjay> yes i still have my ps2 and it has the rgb things.
[18:32:47 CET] <johnjay> forget what they are called
[18:33:08 CET] <kepstin> the three-cable rca jacks are component video, yeah
[18:33:48 CET] <kepstin> the ps2 normally still did 480i over component, you had to use a specific game with progressive support and activate it with certain keypresses or menu config to actually get progressive video.
[18:35:49 CET] <JEEB> I think like gran turismo or something supported even 1080i
[18:35:54 CET] <JEEB> on ps2
[18:36:26 CET] <TanaPanda> composite
[18:36:36 CET] <kepstin> huh, i wouldn't think the ps2 supported the pixel clock high enough to do that
[18:36:37 CET] <TanaPanda> red white yellow is composite
[18:36:45 CET] <TanaPanda> red white blue red green is component
[18:36:45 CET] <kepstin> TanaPanda: single yellow is composite
[18:36:49 CET] <kepstin> the red/white is audio
[18:37:03 CET] <TanaPanda> yea but they usually come in a set
[18:37:44 CET] <TanaPanda> the circle with like 8 pin is s-video
[18:37:57 CET] <TanaPanda> coax or f connector
[18:38:01 CET] <TanaPanda> HDMI
[18:38:07 CET] <TanaPanda> Digital Optical
[18:38:16 CET] <TanaPanda> anything else?
[18:38:18 CET] <TanaPanda> Display port
[18:39:47 CET] <kepstin> huh, wow, so there's apparently around 5 or 6 ps2 games that did support 1080i, including gran turismo 4. that's kinda neat
[18:40:01 CET] <kepstin> and, uh, nhl 2004 for some reason
[18:41:46 CET] <johnjay> kepstin: i'm looking closely at the snes wiki article. it's saying there's 7 modes, the first four are "progressive" at ~240
[18:41:52 CET] <johnjay> so shouldn't capturing snes output be also as bad?
[18:42:04 CET] <kepstin> probably, i bet it depends on the game
[18:42:23 CET] <kepstin> a lot of these console games also switch modes dynamically, which is even more fun
[18:43:13 CET] <johnjay> that's what it says here. 7 modes total, with switching
[18:44:56 CET] <kepstin> the ps2 games with progressive or hd modes usually switched back to 480i for menus and cutscenes
[18:47:00 CET] <johnjay> interesting, didn't know that
[21:19:01 CET] <LFSVeteran> almost there....
[21:19:13 CET] <LFSVeteran> need to find the right codec and format for ffmpeg -ar 192k -f alsa -i plughw:1,0 -codec copy -b:a 192k -f mpegts icecast://live:str3am@127.0.0.1:8000/stream
[21:19:42 CET] <LFSVeteran> the plan is to stream at 192k from plughw:1,0
[21:28:27 CET] <cehoyos> codec copy does not like b:a (and mpegts most likely doesn't like what -f alsa provides)
[21:35:17 CET] <Hello71> I mean, even if it's allowed, it's probably dumb
[21:55:41 CET] <LFSVeteran> I know, but what would be a good choice as codec / format
[21:56:07 CET] <LFSVeteran> so I can replace copy and mpegts
[22:38:22 CET] <LFSVeteran> ok got it working with mp3: ffmpeg -ar 192k -f alsa -i plughw:1,0 -c:a libmp3lame -b:a 192k -content_type audio/mpeg -f mp3 icecast://live:str3am@127.0.0.1:8000/stream
[22:38:41 CET] <LFSVeteran> but that means compression
[22:39:03 CET] <LFSVeteran> is there a way without compression ?
[22:39:42 CET] <BtbN> Streaming uncompressed audio seems like a pointless waste
[22:41:31 CET] <LFSVeteran> compression takes time...
[22:41:52 CET] <LFSVeteran> delay isn't a problem as long it will be a continous stream
[22:42:19 CET] <LFSVeteran> now I have some stops in the stream
[22:51:25 CET] <BtbN> that must be a really crappy CPU if it can't sustain a single mp3 encoder
[22:51:57 CET] <LFSVeteran> embedded
[22:52:25 CET] <LFSVeteran> not a high speed PC cpu
[23:05:10 CET] <BtbN> Even a first gen RPi could probably encode mp3 in real time.
[23:08:58 CET] <LFSVeteran> hmm, maybe encoding isn't the problem then...
[23:09:08 CET] <LFSVeteran> have to dive into it
[00:00:00 CET] --- Tue Dec 24 2019