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

[burek]

[00:14:17 CET] <Anderssen> hm, I think there is something else to it; forget about the 32 pixels, that was coincidence. When I'm just below 704, it pads up to 704 width; when I'm above that but below 768, it pads to 768, above that to 832 and so on; it seems the encoder has a predefined range of possible widths. maybe this is also tied to the pixel format nv12.
[00:18:15 CET] <furq> fun
[00:18:46 CET] <furq> i have a 570 in a windows box which works fine with a pal dvd source
[00:18:56 CET] <furq> so i guess it's vaapi or your drivers or both
[00:20:29 CET] <furq> idk what your actual goal is here but i would probably suggest just using x264
[00:20:33 CET] <Anderssen> i think it's hevc_vaapi; maybe they only accept widths divisible by 64
[00:21:11 CET] <pink_mist> I mean, it probably depends on your actual hardware
[00:21:15 CET] <Anderssen> yes, it works with h264_vaapi; i prefer h265 though
[00:21:22 CET] <furq> hardware encoders aren't great at best
[00:21:26 CET] <furq> and amd's is very much not best
[00:21:30 CET] <pink_mist> yeah
[00:22:03 CET] <Anderssen> i pretty much like the results of hevc_nvenc though
[00:29:26 CET] <Anderssen> furq, what's your brand? Mine is Asus Radeon Dual 8GB OC
[00:29:52 CET] <Anderssen> (the NVidia card was on my laptop, it was a gtx-1050-ti mobile)
[00:30:27 CET] <furq> some msi 8GB one
[00:30:40 CET] <furq> the brand shouldn't make any difference, all rx500 series cards have the same VCE block
[00:31:01 CET] <Anderssen> hm
[00:33:59 CET] <Anderssen> maybe i can do it under windows
[00:48:44 CET] <Anderssen> kk, I tried the encoders h264_amf and hevc_amf under windows; the good news: they work. the bad news: they don't react to -crf, -qp, or -qscale or -q:v, constant bitrate seems to be all that's possible (also there is no effect of -pass 1 or -pass 2).
[00:49:28 CET] <BtbN> look at their help entry to see supported options
[00:49:35 CET] <Anderssen> I don't really get it. But it seems to have something to do with the drivers; or maybe the particular ffmpeg build? idk
[00:49:48 CET] <BtbN> crf is mostly an x264 thing
[00:50:28 CET] <Anderssen> crf doesn't work on h264_amf either, though (my ffmpeg build is that from imagemagick).
[00:51:01 CET] <pink_mist> Anderssen: he said x264, not just any old h264 encoder
[00:51:07 CET] <Anderssen> kk
[00:52:04 CET] <Anderssen> idk if there are other options that are used to do constant quality, though. the only ones i know at all are qscale/q:v, crf and qp
[00:52:27 CET] <BtbN> Have you tried looking at the encoders options list?
[00:54:39 CET] <furq> there's -rc cqp but i could never figure out how to make it do anything
[00:55:00 CET] <furq> also it doesn't work with vbaq
[00:55:21 CET] <Anderssen> BtbN, I've looked for one; is there a way to display the options of that particular codec directly by ffmpeg?
[00:55:28 CET] <furq> -h encoder=h264_amf
[00:55:36 CET] <furq> anyway in general i would not use nvenc/qsv/amf for anything other than realtime
[00:57:18 CET] <Anderssen> thanks; yes, indeed they have the -rc option
[01:06:50 CET] <Anderssen> ok, i always find this a little tricky; but apparently they can quantize i-frames and p-frames. they don't have a "general" -qp, but they accept "-qp_i" and "-qp_p" for i-frames or p-frames respectively.
[02:22:18 CET] <gp> Why are these playlists not aligned on segments? https://dpaste.de/pePd
[02:22:47 CET] <gp> I took the video from the first one and added to audio for the second one - but the second one doesn't follow the cut points using copied video?
[02:24:20 CET] <gp> ffmpeg version 4.2.1
[02:30:39 CET] <cehoyos> Consider to test current FFmpeg git head and post on the user mailing list
[02:36:59 CET] <gp> cehoyos: so that should work, right?
[03:01:03 CET] <gp> same result built on snapshot version
[12:35:13 CET] <BeerLover> is there any quality loss if i make mp3 to hls same bitrate?
[12:41:25 CET] <pagios> hello, is it possible to extract the RTP details IP/PORT from a webrtc offer/answer and point to that using ffmpeg to manipulate?
[14:48:27 CET] <pagios> hello all, i would like to get the smallest latency when trancoding into hls, what should i use as arguments/
[14:48:50 CET] <BtbN> Use as short as segments as you can
[14:48:55 CET] <BtbN> so, usually GOP sized segments
[14:49:02 CET] <BtbN> Your latency will be 3 times that length at best
[14:50:00 CET] <pagios> BtbN, i was thinking of using a segment of 1s and a playlist of approximately 1min
[14:50:20 CET] <BtbN> You will need a gop length of 1s then, which is fairly suboptimal
[14:50:32 CET] <BtbN> The playlist length is not relevant for latency
[14:50:42 CET] <pagios> BtbN, yes but just worried about IO too :)
[14:50:46 CET] <pagios> and disk space
[14:51:02 CET] <pagios> BtbN, which flags should i look into?
[14:51:07 CET] <BtbN> hm?
[14:51:22 CET] <pagios>  -flags +cgop -g 10 -hls_time 1
[14:51:26 CET] <pagios> i tried that, is it enough
[14:52:39 CET] <BtbN> a 10 frame gop is way too small
[14:53:00 CET] <BtbN> even a 1 second, so probably 60 frame gop, is horrible for quality
[14:53:44 CET] <pagios> any magic number to set it to?
[14:54:47 CET] <nicolas17> pagios: what clients will consume your stream?
[14:55:40 CET] <nicolas17> Apple has a new thing for low-latency HLS, but it needs a special origin server (instead of just serving static files in a webserver)
[14:55:47 CET] <nicolas17> still compatible with normal CDNs though
[14:56:22 CET] <nicolas17> https://developer.apple.com/videos/play/wwdc2019/502/
[14:56:45 CET] <DHE> for lowest possibly latency, set it to your framerate. so typically 30 or 60
[14:57:09 CET] <DHE> but there is a negative impact on bitrate because keyframes are large and, from a playback standpoint, not necessary. but every file must begin with one
[14:57:13 CET] <pagios> DHE: what about segment size
[14:57:42 CET] <DHE> as was said, -hls_time * 3 will be your approximately player latency
[14:57:55 CET] <DHE> so for 3 second latency, use hls_time of 1
[14:58:07 CET] <DHE> if you're okay with higher latencies, you can set it to 2, and then double your keyframe interval as well
[14:58:41 CET] <nicolas17> 1 GOP is the smallest you can make the segment
[14:59:16 CET] <pagios>  -g 250 -framerate 30 -hls_list_size 0 -start_number 0 -hls_init_time 2 -hls_time 8  <-- what do you think
[15:00:04 CET] <DHE> well, playback delay will be something like 20 seconds, but that's fairly good for quality
[15:00:06 CET] <nicolas17> what latency are you trying to get?
[15:00:26 CET] <pagios> around 10-15 seconds max if possible
[15:00:42 CET] <DHE> then I'm going to recommend -hls_time 4 -g 120
[15:00:51 CET] <nicolas17> ok so at least you don't need to go as far as using ALHLS
[15:01:00 CET] <DHE> for a framerate of 30
[15:01:22 CET] <pagios> DHe something like:  -g 120 -framerate 30 -hls_list_size 0 -start_number 0 -hls_init_time 2 -hls_time 4  <-- what do you think
[15:02:05 CET] <DHE> hls_list_size of 0 is not recommended for live, endless streams
[15:02:16 CET] <pagios> oh
[15:02:27 CET] <nicolas17> hls_list_size 0 means all segments stay in the playlist forever
[15:02:44 CET] <pagios>  -g 120 -framerate 30 2 -hls_time 4 enough i guess
[15:02:49 CET] <DHE> which is fine for a video of finite length, even if it's "live", but it must end.
[15:02:59 CET] <pagios> it is live indeed
[15:03:00 CET] <DHE> you missed your hls_init_time
[15:03:02 CET] <nicolas17> if you're going to stream for a few hours, that may be useful if the player supports rewinding, in case a user wants to watch time-shifted
[15:03:13 CET] <pagios> nicolas17, dont have that
[15:03:24 CET] <DHE> I do. but I have buttloads of storage. :)
[15:04:03 CET] <pagios> DHE, so in your opinion  -g 120 -framerate 30  -hls_time 4 <-- this is gonna achieve around 10sec?
[15:04:06 CET] <nicolas17> sometimes I wish twitch supported such time-shifting :P
[15:04:18 CET] <DHE> pagios: more like 12-16
[15:04:28 CET] <DHE> you said 10-15 so..
[15:04:42 CET] <pagios> is it possible to reach 5 to 10?
[15:04:46 CET] <pagios> curiosity
[15:04:57 CET] <DHE> well, hls_time of 3 means 9-12
[15:05:22 CET] <pagios> what happens to the -g 120 in this case
[15:05:24 CET] <nicolas17> DHE: what happens if hls_time isn't a multiple of the gop size?
[15:05:29 CET] <pagios> exactly
[15:05:44 CET] <DHE> then hls_time is EFFECTIVELY 4 because you only get a keyframe every 4 seconds
[15:06:02 CET] <DHE> so -g 90 is also needed
[15:06:11 CET] <nicolas17> ah I didn't know if it would increase hls_time or decrease gop
[15:06:17 CET] <pagios> what are the cons in this case?
[15:06:28 CET] <DHE> gop is a codec parameter. it doesn't know about your hls_time requirement
[15:06:29 CET] <pagios>  -g 90 -framerate 30  -hls_time 3
[15:06:52 CET] <DHE> users are going to be hitting your HTTP server more often. "requests per second
[15:06:54 CET] <DHE> " will go up
[15:23:46 CET] <pagios> thanks DHE
[15:34:53 CET] <pagios> DHE getting 12sec using  -g  90 -framerate 30  -hls_time 3 , can we go lower ? :)
[15:37:45 CET] <Kadigan> Hm... Interesting. So, I did some more digging w/ the LUTs that ffmpeg accepts, and it seems it has an issue with the one designated as "baselightcube3d", identifies itself as "TrueLight Cube v2.0". The issue is that it lacks a size definition at sample start - a simple "LUT_3D_SIZE 32" fixes that right up, and it seems not to care if there are spaces or tabs as the separator.
[15:51:15 CET] <DHE> pagios: well i did say 9-12 seconds
[16:18:59 CET] <pagios> DHE, yea, can we go as low as 5?
[16:26:33 CET] <DHE> pagios: I would not recommend it
[17:39:54 CET] <friki-> Hi. Can ffmpeg map audio to stream id=9 and video to id=0? '-map' option seems to set correlative ids
[17:41:24 CET] <friki-> The purpose is a DASH output with prefixed ids. May be DASH muxer can help, but I can't found the option
[17:50:08 CET] <Case_Of> hi
[17:50:39 CET] <Case_Of> how could I convert subtitles from a mkv file to a format compatible for video dvds?
[17:52:29 CET] <furq> Case_Of: spumux from dvdauthor will do it
[17:53:11 CET] <Case_Of> oh
[17:54:18 CET] <furq> you might need to demux the subs from the mkv first (-i foo.mkv -map 0:s -c:s copy out.srt)
[18:39:28 CET] <Jan-> hihi
[18:41:08 CET] <Jan-> I have a file here that someone tells me is a video, but I can't tell what kind. It's called 0000000041_20191118_145500.mdt and begins with the four bytes 0xAA00EFF2. The ascii characters mdt appear at offset 22. if I ffmpeg -i it, I get "c:\foobar\filename.mdt: Invalid data found when processing input"
[18:41:32 CET] <Jan-> I'm not even sure this is a video, but does anyone have any ideas
[18:42:26 CET] <Case_Of> oh wow, spumux fails when setting horizontal-alignement="center"
[18:43:08 CET] <Case_Of> it does not output error but no subtitle stream is present in file
[18:43:49 CET] <Case_Of> well, i guess i have to keep subtitles aligned at left
[18:46:59 CET] <nicolas17> Jan-: panasonic camera?
[18:47:04 CET] <Jan-> yeah I just found that
[18:49:06 CET] <JEEB> sounds like fun
[18:49:12 CET] <nicolas17> looks like it records into an mdt file, and when it's done the data is put into a .mov with proper headers and footers
[18:49:24 CET] <Jan-> mm
[18:49:25 CET] <nicolas17> but if you lose power halfway recording, you're left with an mdt file you can't open with anything
[18:49:37 CET] <JEEB> they could have used mpeg-ts for the "cache"
[18:49:37 CET] <Jan-> I found a youtube video about fixing it
[18:49:46 CET] <Jan-> JEEB: only if they're recording mpeg :)
[18:49:48 CET] <JEEB> that way it was a standard container, too
[18:50:10 CET] <nicolas17> and then there's a bunch of websites asking $50 for their data recovery software to fix it :)
[18:50:10 CET] <JEEB> Jan-: I expect cameras to record H.264, HEVC or something else. and you can always make up mappings for containers
[18:50:26 CET] <Jan-> Mostly they're some variant of .mov
[18:50:30 CET] <Jan-> even for tricky raw formats
[18:50:56 CET] <JEEB> well yea, indexed container makes sense for the recording finally
[18:51:22 CET] <Jan-> I don't think this is a panasonic camera file though
[18:51:22 CET] <durandal_1707> nothing make sense in multimedia world
[18:51:33 CET] <Jan-> the filename isn't in the right format
[18:51:36 CET] <JEEB> as far as I can see GH5 etc basically record H.264 or HEVC so they might as well do MPEG-TS :P
[18:51:38 CET] <Jan-> don't you love it when people throw you files with no data
[18:51:43 CET] <JEEB> yup
[18:51:57 CET] <JEEB> is the file at least large enough to probably be video?
[18:52:04 CET] <Jan-> 71MB
[18:52:06 CET] <Jan-> so plausibly yes
[18:52:20 CET] <nicolas17> how long do you think it is?
[18:52:25 CET] Action: Jan- shrug
[18:52:35 CET] <JEEB> is there something like 0x00 00 00 01 in there?
[18:52:36 CET] <nicolas17> 1 hour recording won't fit reasonably :)
[18:52:38 CET] <JEEB> or 0x00 00 01
[18:52:48 CET] <JEEB> (annex B start codes)
[18:52:52 CET] <Jan-> it's a 71MB file
[18:52:59 CET] <Jan-> it's probably got that in there a lot
[18:53:06 CET] <Jan-> most of it is like mush
[18:53:12 CET] <Jan-> could be compressed data
[18:53:19 CET] <durandal_1707> its secret covfefe
[18:53:28 CET] <JEEB> not necessarily?
[18:53:30 CET] <Jan-> but like I say it starts with AA00EFF2
[18:53:46 CET] <JEEB> but yea, check if it has those, then at least it might have raw annex b H.264 or HEVC there
[18:53:47 CET] <Jan-> there's a few more instances of AA00EF
[18:53:49 CET] <JEEB> worth a check :P
[18:54:02 CET] <JEEB> either 4 byte or 3 byte 0x00 00 00 01
[18:54:12 CET] <Jan-> well the first eight bytes are AA00EFF2000001
[18:54:18 CET] <durandal_1707> ffmpeg -f h264 -i covfefe.mdt -f null -
[18:54:21 CET] <Jan-> but two zeroes and a 1 are hardly unusual
[18:54:52 CET] <Jan-> what's the -f null - for
[18:55:07 CET] <durandal_1707> to try decode it fully
[18:55:35 CET] <nicolas17> Jan-: to send the result nowhere, just decode it
[18:55:54 CET] <Jan-> just a massive cascade of errors
[18:55:58 CET] <Jan-> I think this is not h264
[18:56:19 CET] <durandal_1707> it could be drm protected
[18:56:49 CET] <Jan-> possibly.
[18:58:52 CET] <Jan-> the person who gave me this gave me no information whatsoever about where it came from
[18:58:58 CET] <Jan-> I've asked, but of course they've gone silent...
[18:59:07 CET] <JEEB> :D
[18:59:11 CET] <JEEB> classic
[18:59:29 CET] <JEEB> sounds like it's a good time to move and go play pokemon
[18:59:43 CET] <Jan-> I'm not much of a mon-poker
[18:59:47 CET] <Jan-> but you know
[19:03:13 CET] <Jan-> OK it's from a dashcam
[19:03:33 CET] <Jan-> "MiTAC Digital Technology"
[19:03:33 CET] <JEEB> ok, those are usually rather powerless ARM thingamajigs
[19:03:47 CET] <JEEB> so it's either standard H.264 or HEVC repackaged in some weird-ass way, or just MJPEG
[19:04:20 CET] <nicolas17> ugh probably unrelated to the panasonic thing then
[19:07:41 CET] <Jan-> nicolas17: I think you're right
[19:11:56 CET] <Jan-> of course it is super important that they have a custom file format
[19:13:23 CET] <nicolas17> mitacmdt.com -> automotive dashcam -> mio.com -> nothing about mdt format
[19:13:25 CET] <nicolas17> ???
[19:14:27 CET] <nicolas17> I looked at some camera models and the specs say they record in .mp4
[19:14:48 CET] <nicolas17> now I wonder if it records video in .mp4, metadata like GPS trace into a separate .mdt, and they sent you the wrong file
[19:14:55 CET] <Jan-> OK we found something "MDT Player"
[19:15:00 CET] <Jan-> yes it's a dashcam
[19:15:24 CET] <Jan-> and there is an .mdx sidecar file with what looks like a bunch of repeated records in it which might be gps
[19:15:44 CET] <nicolas17> I found an mdt player from "smartwitness" but it didn't *seem* related... maybe it is
[19:15:51 CET] <Jan-> that's the one
[19:15:57 CET] <nicolas17> worth a try
[19:16:26 CET] <Jan-> yes that's the one that works
[19:24:07 CET] <Jan-> I assume it must be an mp4 under the hood
[19:26:18 CET] <nicolas17> if that mdt player works for your file, it can export to mp4 too
[20:27:42 CET] <Polochon_street> Hi! I'm trying to stream something from my main PC to a raspberry Pi from httpd (over wi-fi) and was wondering, what would be the ideal codec so that the Pi has as little decoding as possible to do? wav?
[20:28:14 CET] <Polochon_street> I've managed to get down the latency to ~1s but can't seem to be able to go more down
[20:34:46 CET] <nicolas17> Polochon_street: at first I thought you meant video
[20:35:08 CET] <nicolas17> the raspberry pi should be powerful enough to deal with any audio codec really...
[20:35:42 CET] <Polochon_street> no no I only mean audio sorry if it was unclear
[20:35:50 CET] <Polochon_street> even with low-latency?
[20:36:23 CET] <Polochon_street> the goal is to show a display of a spectrometer of the song while it plays from the main PC, so you can see immediately the latency :p
[20:36:42 CET] <nicolas17> some codecs have more latency than others, some have options to reduce it, but my point is that I doubt the CPU power of the raspi will be a limiting factor
[20:37:06 CET] <Polochon_street> that's what I was wondering
[20:37:35 CET] <Polochon_street> okay, so I have 0-latency if I just don't use any codec and stream raw PCM
[20:38:41 CET] <Polochon_street> hm, that was a lie, it seems to be slowly drifting
[20:39:17 CET] <nicolas17> latency increasing? it can't keep up, maybe you're limited in bandwidth
[20:40:12 CET] <nicolas17> you probably won't get 0 latency with anything involving this much processing (wi-fi alone is pretty complex!), I think what you should do is compensate the latency in the spectrogram
[20:40:45 CET] <Polochon_street> spectrogram will induce a lot of latency, indeed
[20:40:52 CET] <Polochon_street> didn't even think of that
[20:41:19 CET] <nicolas17> oh is the spectrogram on the pi and the audio on the PC?
[20:41:26 CET] <nicolas17> I got it backwards
[20:41:41 CET] <Polochon_street> yes, then I think I can even forget about it ^^'
[20:41:55 CET] <nicolas17> anyway, then it's: delay the audio on the PC to match the latency you get on the pi
[20:42:10 CET] <Polochon_street> is that possible ?
[20:42:44 CET] <nicolas17> I don't know how you're playing it :)
[20:42:59 CET] <Polochon_street> right now I'm just streaming PCM through MPD's HTTPD
[20:43:06 CET] <nicolas17> my bluetooth headphones have 0 latency when I watch a video, but that's because software is compensating, if I try something realtime (gaming, play music) there's like 1 second of latency
[20:45:37 CET] <Polochon_street> I'll try to figure out how I can do this then
[20:45:39 CET] <Polochon_street> thanks a lot! :)
[20:55:51 CET] <Polochon_street> is there an equivalent to ffplay's `-sync ext` in ffmpeg itself?
[20:56:18 CET] <Polochon_street> man doesn't seem to say so
[21:00:22 CET] <Polochon_street> oooor - I could cheat, and stream the spectrogram from my PC :D
[21:52:21 CET] <Case_Of> furq: spumux does not really work&
[22:12:59 CET] <soma_> https://gist.github.com/docoprusta/c294ebaaa68fdc8502b6caa641a75d7f
[23:03:57 CET] <Saberwolf> hello
[23:04:10 CET] <Saberwolf> i have a vary specific question
[23:06:27 CET] <kepstin> Saberwolf: you need to think about it harder, my mind reading isn't able to pick it up.
[23:07:28 CET] <Saberwolf> i am trying to NVenc and NVdec blu-ray raw disk dump and keep the same level of detail as orignal. i am just trying to get Lossless video with 10bit HVEC in MKV container with AC3 Passthrough every thing i keep finding keeps doubling end container file and a bunch of wasted space for processing
[23:08:13 CET] <Saberwolf> i have tryed Handbrake staxrip and few others
[23:08:28 CET] <Saberwolf> i dont know where to beggin with FFMPEG
[23:09:45 CET] <kepstin> you don't want lossless video, that would make it bigger than the source
[23:09:47 CET] <Saberwolf> i am running P2000 Quatro
[23:10:13 CET] <kepstin> in general you want to avoid transcoding where possible, and you're unlikely to improve upon the original bluray encode much with a hardware encoder
[23:10:17 CET] <Saberwolf> i though that if the orignal was lossless then it should be same size
[23:10:24 CET] <kepstin> the original isn't lossless
[23:10:29 CET] <Saberwolf> ok
[23:10:43 CET] <kepstin> bluray uses lossy compression (usually h264, sometimes av1, uhd might be hevc)
[23:12:01 CET] <Saberwolf> what would be a good place to start i just want to have have to transcode
[23:12:01 CET] <kepstin> if you want the bluray smaller while preserving as much quality as possible, use a cpu-based h264 or hevc encoder (x264 or x265) with appropriate slow settings and a crf value found via experimentation, and then wait a while.
[23:12:28 CET] <kepstin> i wouldn't bother with using nvenc for this use case.
[23:12:33 CET] <Saberwolf> lol ya the waiting is what killing me it said 7 days holy cow
[23:12:57 CET] <kepstin> x265 is pretty slow, for regular 1080p stuff i'd stick with x264
[23:13:11 CET] <Saberwolf> i am dealing with 4k
[23:13:19 CET] <Saberwolf> 3480X1600
[23:13:23 CET] <kepstin> right, it's just gonna be slow then.
[23:13:32 CET] <Saberwolf> Fk
[23:14:00 CET] <klaxa> there are not really shortcuts in compression ;)
[23:14:03 CET] <Saberwolf> i am running i7 7700K at 4.4 ghz
[23:14:08 CET] <klaxa> if there were, they wouldn't be shortcuts
[23:14:18 CET] <kepstin> 7 days seems kinda slow, you might want to use a faster encoder preset
[23:14:27 CET] <kepstin> less efficiency, but might be worth it for you
[23:14:43 CET] <kepstin> more cpu cores could help too, up to a point.
[23:14:58 CET] <Saberwolf> i am trying to keep about 40-50 M avrage bitrate
[23:15:24 CET] <Saberwolf> keep overall file size to 60 Gigs
[23:15:28 CET] <kepstin> right, iirc uhd blu-ray is in the neighbourhood of around 100mbit/s
[23:15:56 CET] <kepstin> if you want to actually target a specific filesize, you'd need to use 2-pass encode, which is even slower. But you probably don't need to do that
[23:16:20 CET] <kepstin> encode some short samples of representitive video in 1-pass crf mode, pick a crf value that gives about the bitrate you want, and then stick with that.
[23:16:36 CET] <Saberwolf> i am just running into issuse with losing 10 bit for 8 bit and stuipd big files
[23:17:05 CET] <Saberwolf> software does not support fuly 10bit pipline
[23:17:24 CET] <kepstin> well, both are incorrect encoder settings. ffmpeg will preserve 10-bit when re-encoding by default with a sufficiently new build using libx265
[23:17:45 CET] <kepstin> "sufficiently new" in this case being "within the past year or so" i think, so not even that new.
[23:17:53 CET] <Saberwolf> i was using handbrake and just finshed useing staxrip
[23:18:04 CET] <kepstin> well, this isn't a handbrake or staxrip channel
[23:18:09 CET] <Saberwolf> ya iknow
[23:18:20 CET] <Saberwolf> trying different software
[23:19:18 CET] <kepstin> i'd just use the ffmpeg cli, tbh. it can even read directly from an unencrypted blu-ray file structure.
[23:19:19 CET] <Saberwolf> do you guys have any suggestions on commands i use or stay away from
[23:19:32 CET] <Saberwolf> how do you do that
[23:19:46 CET] <Saberwolf> i am totally green when it comes to FFMPEG
[23:21:25 CET] <kepstin> https://www.ffmpeg.org/ffmpeg-protocols.html#bluray
[23:21:53 CET] <kepstin> if you know the correct playlist number it's pretty easy to use.
[23:22:55 CET] <Media_Thor> #teamtrees  $1 = 1 tree
[23:23:14 CET] <Saberwolf> ya i have it
[23:23:27 CET] <Saberwolf> 00005.m2ts
[23:26:05 CET] <Saberwolf> oops you see Green not what your talking about
[23:26:34 CET] <Saberwolf> 00005.mpls
[23:28:47 CET] <lyncher> hi. the showinfo filter is only displaying the TOP field of a interlaced video. is there any way to have both TOP and BOTTOM fields processed by showinfo filter?
[23:29:06 CET] <lyncher> [Parsed_showinfo_0 @ 00000168d5911680] n:  11 pts:  25982 pts_time:0.433033 pos:   191067 fmt:yuv420p sar:1/1 s:1920x1080 i:T iskey:0 type:B checksum:4ADF336D plane_checksum:[2A64808D 36A6079E B918AB33] mean:[66 120 138 ] stdev:[43.2 5.4 5.1 ]
[23:29:38 CET] <lyncher> all the output lines on my interlaced file have "i:T" and none with "i:B"
[23:31:05 CET] <durandal_1707> you are deeply confused
[23:31:25 CET] <lyncher> T means "true"??
[23:32:25 CET] <durandal_1707> T top field first
[23:34:19 CET] <lyncher> I'm trying to print CC that is being carried in TOP and BOTTOM fields (they should be different)..... but I'm only having access to the information that is in the TOP field
[23:35:13 CET] <lyncher> if I put a separatefields before showinfo I get the duplicated information from TOP field
[23:35:18 CET] <gp> I've found the apad filter to extend audio to the end of video.  How can I use this to pad the beginning when video starts before audio?  So the streams have equal duration?
[23:37:03 CET] <gp> My goal is to make audio and video streams have the same duration regardless of which one stops/starts first
[23:37:47 CET] <kepstin> lyncher: both fields are stored in one frame, the T/B indicates whether the field in the top line (vs. bottom line) is temporally earlier.
[23:38:55 CET] <kepstin> CC information is stored as metadata attached to frames, not to fields.
[23:39:00 CET] <lyncher> ok. how can access bottom fields side data?
[23:39:15 CET] <kepstin> no such thing
[23:39:46 CET] <lyncher> for (int idx = 0; idx < sd->size; idx++) {	av_log(ctx, AV_LOG_INFO, "%x", sd->data[idx]); }
[23:39:58 CET] <kepstin> the frame should contain the CC data for the entire frame (both fields)
[23:40:00 CET] <lyncher> I've added that code in showinfo to dump CC side data
[23:40:24 CET] <kepstin> (note that in analogue signals, the CC data was in a single video line per frame (two fields), it's not per-field there either)
[23:40:25 CET] <lyncher> but only the first field (TOP) is being printed
[23:41:54 CET] <kepstin> I assume the CC you're talking about is EIA-608 or CEA-708?
[23:42:17 CET] <lyncher> 608
[23:42:20 CET] <kepstin> it's stored per frame, not per field
[23:42:40 CET] <kepstin> there's no cc data for the "bottom field", there's just one cc data per frame
[23:43:44 CET] <kepstin> you have to go back to how cc data is stored in the analogue ntsc video signal on line 21 to understand why.
[23:46:51 CET] <kepstin> wait, nvm, i'm confused and wrong
[23:47:39 CET] <kepstin> i was under the understanding that the captions were just stored on ntsc line 21, but apparently the caption line was per field. :/
[23:48:38 CET] Action: kepstin hasn't ever seen any actual examples of something with more than one caption stream only one one line in the video, tho.
[23:49:18 CET] <lyncher> that means that it might be an issue when merging top and bottom fields in a frame (only the data from the first fields is being copied to AVFrame)?
[23:49:35 CET] <kepstin> how exactly is this digital video being created?
[23:49:44 CET] <kepstin> are you taking an analog source through some card?
[23:49:52 CET] <kepstin> is it originally digital?
[23:50:02 CET] <lyncher> mp4 in a h264
[23:50:19 CET] <lyncher> (the other way around.... h264 in a mp4)
[23:50:32 CET] <kepstin> h264 does not store the cc data in the video signal, it's stored as separate packets within the video stream
[23:50:45 CET] <lyncher> yes, SEI units
[23:51:00 CET] <kepstin> have you confirmed that this video actually has multiple cc streams?
[23:51:01 CET] <lyncher> which are then loaded as AVSideData
[23:51:18 CET] <lyncher> it only has one CC stream
[23:52:02 CET] <lyncher> the issue that I found is that in the AVSideData, only the cc_data from top field is present
[23:52:32 CET] <kepstin> that makes sense if there's only a single cc stream
[23:52:45 CET] <lyncher> in showinfo code there's:  for (i = 0; i < frame->nb_side_data; i++)
[23:53:22 CET] <lyncher> which means that the other field info wasn't loaded (because I'm not getting the info that was encoded in h264 SEI units for the bottom field)
[23:53:27 CET] <kepstin> if there were two cc streams then you should have one for odd fields, one for even fields
[23:53:37 CET] <kepstin> but a single cc stream is only in one field iirc
[23:57:33 CET] <kepstin> reading up some wikipedia, it looks like dual audio (sap) broadcasts would often have captions for the first audio track in the odd fields, and captions for the second audio track in the even fields
[00:00:00 CET] --- Tue Nov 19 2019