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

[burek]

[00:40:31 CEST] <DHE> default swscaler is bilinear. for downsampling, is there a better choice? better as in "burns more CPU, but probably worth it"
[00:40:45 CEST] <DHE> or just a subjective opinion of which looks best
[00:41:46 CEST] <JEEB> I recommend trying out zscale filter that uses the zimg library
[00:44:30 CEST] <DHE> interesting. is it faster? higher quality?
[00:44:40 CEST] <DHE> seems to have similar options to stock ffmpeg scaling
[00:45:03 CEST] <JEEB> not sure about the zscale side but in general it should be rather nicely multithreadable and based on correctness
[00:45:23 CEST] <JEEB> your main worry thus becomes to make sure swscale doesn't do any actual scaling or colorspace conversions :)
[00:48:23 CEST] <DHE> uhh.. what?
[00:59:11 CEST] <vade> am I responsible for re-timing AVFrames that are vended out of a avbuffer/ avbuffer sink filter chain if im asking to do re-sampling? @JEEB ?
[01:18:48 CEST] <Aison> hello, just extracted all subtitle streams from a blueray rip mkv with ffmpeg -i file.mkv -map 0:s -c:s copy file_subs.mkv
[01:19:05 CEST] <Aison> the subtitle only mkv file is 1gb! why so big? it is just some text!?
[01:23:07 CEST] <Plorkyeran> blu-ray subtitles are images
[01:23:32 CEST] <Aison> oh
[01:23:53 CEST] <Aison> quit retarded ...
[01:24:21 CEST] <Aison> but instead of a good font renderer inside the blueray player, they implement crap like BD+
[01:34:24 CEST] <klaxa> bluray could have been good
[02:27:24 CEST] <antiPoP> hi, what does this command do: ffmpeg -i video.mp4 -r 0.09 cuadro_%01d.jpg
[02:27:47 CEST] <antiPoP> I think is for creating thumbnails  but how the -r option works
[02:29:09 CEST] <antiPoP> ?
[02:30:12 CEST] <llogan> ffmpeg will drop frames to make 0.09 fps.
[02:31:39 CEST] <antiPoP> llogan,  this is used to created thumbnails
[02:31:41 CEST] <antiPoP> and works
[02:31:48 CEST] <antiPoP> but idk how
[02:34:52 CEST] <antiPoP> seems it created an thumb each 1/.09 secs
[05:48:48 CEST] <Admin__> hey guys.. quick question please... i am transcoding some live content that has closed caption data in video.. but its 60fps and i am transcoding 30fps...i am doing c:s copy or -scodec copy and i can't get closed caption working.. weird thing is it was working last week and now it stopped again.. anyone know why ?
[05:49:02 CEST] <Admin__> what can i do to guarantee that the closed caption data gets through
[06:21:40 CEST] <Admin__> anyone?
[06:24:15 CEST] <koka> (koka) I need help with compiling ffmpeg on windows 7
[06:24:31 CEST] <koka> I compiled it using msys already.
[06:24:41 CEST] <koka> ) I am trying to compile a program with only a single call to av_register_all() as a test program
[06:24:56 CEST] <koka> ) But I get errors like undefined reference to __mingw__vscanf in stdio.h
[06:25:11 CEST] <koka> Can anybody help me in understanding what this error is ? (Im using i686-mingw-w64 for compiling test program)
[06:26:48 CEST] <koka> Anyone ?
[06:27:42 CEST] <koka> Any kind of help plz ?
[07:17:13 CEST] <ironSpider> Is there any way to splice (ideally using -sseof) a "live" file (specifically, av_foundation capture of a desktop)? My attempts have come up short (some codecs through an error for sseof, others never stop transcoding (as though sseof has no effects))?
[07:20:08 CEST] <ironSpider> For example, ffmpeg running in a shell capturing screen in file desktop.mp4 for 10 minutes, and while this is running, in another shell, I want to extract the last 30 seconds of desktop.mp4
[07:45:12 CEST] <flux> ironspider, no, it's not possible to read mp4-files live. you could do it with .ts though, in principle.
[07:46:02 CEST] <flux> the information required to read mp4 files is written last (ie. frame sizes, frame timings), though in principle it might be possible to find a h264 from the mp4 file without that information (but you would need to write that tool yourself)
[07:46:36 CEST] <thebombzen> you can also use matroska if you need a streamable format
[07:47:15 CEST] <flux> the encoding doesn't write any essential information last? streamable isn't the same as live, but maybe it does work?
[07:53:28 CEST] <Admin__> can anyone help with my question?
[07:56:16 CEST] <ironSpider> @thebombzen I did try matroska (.mkv) but it did not work with -sseof (neither before the -i, nor after)
[07:57:04 CEST] <ironSpider> @flux I did try a couple of different codecs, I'll try a ts right now and see if sseof will work with the live file
[07:58:09 CEST] <flux> if sseof doesn't work with ts then perhaps some more brutal approaches can work, such as taking the last megabyte of the file and playing that
[08:03:21 CEST] <ironSpider> @flux will try ts in just a minute, but just in case, "taking the last megabyte" as in tailing (or using dd) to cut the file to it's last 1MB? there'd be no corruption in doing that?
[08:04:08 CEST] <flux> well, in principle it should try to find the first valid frame from that stream
[08:04:17 CEST] <flux> actual ts streams from dvb are corrupt all the time ;)
[08:04:42 CEST] <flux> if you skip the first second from that 1 megabyte you might get pristine :)
[08:05:34 CEST] <ironSpider> @flux I'll be trying that, thanks for the tip
[08:50:55 CEST] <techno156> \o
[08:51:15 CEST] <techno156> Is compiling fdk-aac currently broken when compiling in cygwin?
[08:52:07 CEST] <techno156> ld can't seem to find fdk-aac, though I have those libraries in my /usr/local/lib
[08:58:22 CEST] <techno156> nevermind. Turns out that ld doesn't search through /usr/local/lib
[08:58:28 CEST] <techno156> thanks anyway. :D
[11:26:29 CEST] <Dariush> Hi. I have two files: the first one has the following properties: 23.96 fps, 24 tbr, 16k tbn, the other one the following: 11.79 fps, 12 tbr, 16k tbn. I want to concatenate them. I cannot reencode the first file for size reasons. I reencoded the second file with '-r 24' and got the following: 24 fps, 24 tbr, 12288 tbn. tbr got fixed, but tbn broke, and the files again concatenate with...
[11:26:30 CEST] <Dariush> ...errors. It was recommended to me on this channel to remux both files to mkv, which I did with the following results: 23.96 fps, 23.96 tbr, 1k tbn and 24 fps, 24 tbr, 1k tbn respectively, which upon concat results in the same problem. How can I make the two timebases match (preferably in mp4 container)?
[12:14:52 CEST] <termos> I have a video stream where some timestamps are absolute and others are relative, so I get audio ts being say 40 and video ts being 26643644. Is there a way to get the same ts for both audio and video?
[14:30:22 CEST] <rooisnoek> Hi, I hope this is the right place to post this question. For my masters research I have to encode/decode and manipulate MP4 files containing H.264 video data (audio is currently irrelevant). What resources or standards (like ISO) would I need to aquire and study to be able to write software to do this? Since FFmpeg can at least decode H.264 natively I hope someone here might be able to help.
[14:42:59 CEST] <pgorley> rooisnoek: A quick search came up with this: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200305-S!!PDF-E&type=items
[14:43:19 CEST] <pgorley> Not sure if it's exactly what you're looking for, but it might be a good place to start
[14:49:46 CEST] <rooisnoek> Thanks for the response. I am aware of those standards (ITU H.264 aka MPEG-4 Part 10). Just wanted to hear whether those standards alone provide all the information I might need
[14:51:12 CEST] <pgorley> I'm guessing it should have all the information you'd need about h264
[14:51:30 CEST] <DHE> there's two parts here - parsing the .mp4 container to get the H264 frames, and decoding the H264 frames into full bitmap images
[14:51:30 CEST] <pgorley> Other than that, you might want to get your hands on the full mpeg4 spec
[14:54:29 CEST] <rooisnoek> If I look at the ISO website my budget won't affort all the MPEG-4 standards. Currently I'm consider part 10 (AVC/H.264), part 12 (ISO base media file format) and part 14 (MP4 file format)
[14:56:39 CEST] <rooisnoek> part 14 seems to depend on part 12. The reason I came here is that part 12 seems to require other standards (unless I'm misreading the freely available introduction) so I want to find out whether anybody knows if theres anything else I might need.
[14:58:29 CEST] <elmarikon> cheers! Can anyone help me with setting metadata for mxf muxing!? Eg. I tried -metadata modification_date="2016-05-19 23:23:23". Then wheile packaging it shows the correst value, but when I check afterwards it is set to "0000-00-00 00:00:00". Is there a way to correctly set that?!
[15:09:55 CEST] <ritsuka> rooisnoek: 10 and 12 are free
[15:09:59 CEST] <ritsuka> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
[15:19:22 CEST] <rooisnoek> thanks ritsuka. I did see there are free version available, but I think they are older version of the standard. Still, I guess I can always start with them and see whether I can get by without the latest versions.
[15:21:54 CEST] <rooisnoek> Part 12 appears to be the latest version, Part 10 is the 2012 version, the newest published is 2014 I think
[15:34:27 CEST] <DHE> anyone know what the .f4m format is or how to play it?
[15:35:41 CEST] <DHE> content appears to be XML but no obvious indication of how to play it beyond it's an Adobe thing (flash?)
[15:38:29 CEST] <rooisnoek> DHE, I think a .f4m file is the manifest file for Adobe HTTP Dynamic Streaming (HDS). It only describes the available media files on a server
[15:39:32 CEST] <DHE> that's something I can google for. thanks.
[15:59:22 CEST] <s00b4u> I am looking for documentation on FFplay but could not find much. For example, the command "ffplay -h" generated a huge list of options
[15:59:39 CEST] <s00b4u> but I don't know how to use them
[16:00:05 CEST] <s00b4u> Is there any documentation/tutorial which gives some examples?
[16:01:13 CEST] <DHE> a lot of the options are similar to ffmpeg's since ffplay consists of the decoding half of ffmpeg's features
[16:02:14 CEST] <DHE> https://www.ffmpeg.org/ffplay.html for the basics, https://www.ffmpeg.org/ffplay-all.html to go deep into all the options available, including the complete video/audio filter
[16:04:08 CEST] <s00b4u> thanks DHE. I already had access to those links. I was looking for some examples which help in understanding easily
[16:04:24 CEST] <DHE> well what do you want to do? typically "ffplay filename.mp4" will be sufficient
[16:07:32 CEST] <s00b4u> Just wanted to learn about all the options which are available. As such, I don't need it but just for my own learning.
[16:21:21 CEST] <OmegaVVeapon> has anyone ever created a stable mpeg multicast stream with ffmpeg? :/
[16:32:46 CEST] <DHE> OmegaVVeapon: I have, but the actual multicast transmission is handled by an application I wrote
[16:33:06 CEST] <DHE> which probably doesn't qualify I bet...
[16:58:46 CEST] <OmegaVVeapon> not unless your application is open-source, hehe
[16:59:31 CEST] <OmegaVVeapon> btw, do some of your streams contain subtitles such as DVB teletext?
[16:59:43 CEST] <OmegaVVeapon> this is what's getting me stuck with ffmpeg
[17:00:01 CEST] <OmegaVVeapon> looping audio and video streams works great
[17:05:07 CEST] <vade> Hi. Im having a subtle issue with libfilter / buffer source / sink when using a compand filter. I have a transcoder I am working on and my video is timed perfectly on transcode, however if i pass audio through my filter chain, which has a compand operation, I get less samples than if I dont. I am aware of encoder / decoder delay, and my old code path which used libswresample worked fine, but obviously sans filtering. Ive logged when my filter c
[17:05:07 CEST] <vade> gets AVERROR(EAGAIN) and it requests the exact number of frames I drop
[17:06:32 CEST] <vade> however, I dont get them back when I try to flush my filter chain by passing through NULL frames
[17:07:07 CEST] <vade> (ie, calling av_buffersink_get_samples with empty AVFrames) - and then requesting flushed encoded packets after that
[17:12:55 CEST] <vade> :X
[17:17:07 CEST] <vade> yea its not the filter at all
[17:17:31 CEST] <vade> er, filter chain, its just the compand filter specifically. the buffer source and sink dont eat 9 frames of audio
[17:26:46 CEST] <dvee> Hello, Im trying to transcode a multicast mpegts stream from dvlast through ffmpeg to an rtmp server but Im getting lots of distortion on the video feed and the audio occasionally breaks/squeeks. Ive tried messing around with loads of ffmpeg options but they none seem to be making a difference. Saving the multicast udp output to file with multicat gives me a perfect video & audio version. Any help much appreciated! More Inf
[17:26:47 CEST] <dvee> http://pastebin.com/vrcD0h9Z
[17:31:26 CEST] <DHE> dvee: sounds like you need a larger receive buffer then?
[17:33:12 CEST] <vade> Ok, im really lost about this compand filter dropping frames
[17:33:35 CEST] <vade> ive tried forcing a call to  avfilter_graph_request_oldest to no avail
[17:35:26 CEST] <dvee> DHE: Thanks Ill have a mess around, how do I set that?
[17:37:09 CEST] <DHE> dvee: try "udp://239.255.1.1:8267?fifo_size=100000&buffer_size=262144"   (quotes needed because & will be interpreted by the shell otherwise)
[17:37:19 CEST] <DHE> I made the numbers up, but let's see how it goes
[17:48:18 CEST] <dvee> DHE: It hasnt helped unfortunately :( Ive messed around with the figures a bit but none seem to make a difference (Tested with both MP4 output file and rtmp flv)
[18:22:16 CEST] <ploop> I want to burn in subtitles using the subtitle filter. this works fine for the most part, but the output files is much, much smaller than the input file, and there's a noticeable drop in quality. is there any way to prevent this?
[18:22:58 CEST] <lavalike> ploop: what options are you using?
[18:22:59 CEST] <ploop> I would do -vcodec copy, but I think that will screw up the subtitle filter
[18:23:41 CEST] <ploop> lavalike: ffmpeg -i 01.mkv -acodec copy -vf subtitles=filename=01.mkv:si=1 burned01.mkv
[18:23:55 CEST] <lavalike> yeah I was thinking about -c:a copy -c:v copy too, try it out
[18:24:12 CEST] <ploop> is -c:a copy the same as -acodec copy?
[18:24:47 CEST] <ploop> so "-vcodec copy" won't interfere with the subtitles filter?
[18:24:58 CEST] <lavalike> yes, and I am only guessing yes for the second one
[18:25:16 CEST] <lavalike> you can try on a small subset of the file to avoid having to wait forever
[18:26:27 CEST] <lavalike> (-ss mm:ss -t mm:ss for starting at the first time specified and going on for the second one)
[18:29:33 CEST] <ploop> yeah lavalike, Filtergraph 'subtitles=filename=02.ass' was defined for video output stream 0:0 but codec copy was selected.
[18:34:42 CEST] <dvee> Added most recent errors, including DHEs recommendations and some more stuff I found on google. Still getting a pixelated stream with audio breakage :( -> http://pastebin.com/qUcSNuNT
[18:36:43 CEST] <Admin__> hey guys.. quick question please... i am transcoding some live content that has closed caption data in video.. but its 60fps and i am transcoding 30fps...i am doing c:s copy or -scodec copy and i can't get closed caption working.. weird thing is it was working last week and now it stopped again.. anyone know why ?
[18:39:46 CEST] <lavalike> ploop: I don't understand, did it work or not? (:
[18:40:55 CEST] <ploop> lavalike: no, as I expected I can't copy the video directly because the subtitles filter needs to edit it
[18:42:11 CEST] <furq> ploop: set -crf
[18:42:22 CEST] <furq> the default is 23, you probably want something lower
[18:42:37 CEST] <ploop> furq: is that the compression amount
[18:42:40 CEST] <furq> yes
[18:42:44 CEST] <furq> lower values are higher quality
[18:42:53 CEST] <ploop> so 0 would be effectively the original?
[18:42:58 CEST] <lavalike> I guess there's also this http://ffmpeg.org/ffmpeg-filters.html#overlay-1
[18:42:59 CEST] <furq> no, 0 is lossless
[18:43:13 CEST] <ploop> so like converting an ogg to flac?
[18:43:15 CEST] <furq> yes
[18:43:31 CEST] <ploop> so I would want something low but nonzero if I'm converting from a lossy source?
[18:43:32 CEST] <furq> if you run mediainfo on the source it might show you the value the source used
[18:43:52 CEST] <furq> if not then 16-24 are usually reasonable values
[18:45:22 CEST] <furq> you might also want to mess with -preset and -tune
[18:46:27 CEST] <furq> if the source is using -tune grain or -tune animation and you're not then there'll be a noticeable difference
[19:12:35 CEST] Action: kepstin notes that 0 is lossless only when using 8-bit x264 - not 10bit; but if you don't know otherwise, you're probably using 8-bit
[19:21:14 CEST] <lavalike> kepstin: neat, why is that?
[19:23:36 CEST] <kepstin> It's just a quirk of how the values are scaled. Crf values aren't comparable between the two. If you actually want lossless, use the option -qp 0, which is the same on both.
[19:31:02 CEST] <Elirips> Hello. Has anyone an idea what might be going on: I call multiple ffmpeg with '.. -updatefirst 1 -y c:\vid\cam01.jpg', '.. -updatefirst 1 -y c:\vid\cam02.jpg', etc. Suddenly one instance fails to write. Checking in process explorer tells me that an instance called with '-updatefirst 1 -y c:\cam01.jpg' has an open handle to the file c:\cam02.jpg
[19:31:10 CEST] <Elirips> How should that be possible?
[19:33:57 CEST] <kepstin> what's "-updatefirst"? I can't find that anywhere in the ffmpeg docs
[19:34:02 CEST] <kepstin> did you mean to use "-update 1"?
[19:35:01 CEST] <DHE> lavalike: there is the need to fill the bottom bits with something. 8-bit 0000000 maps to 10-bit 0000000000. 8-bit 11111111 maps to 10-bit 1111111111. But for most values in between there's technically rounding inaccuracies
[19:35:42 CEST] <DHE> fractions x/255 don't always directly map to fractions of  y/1023
[19:35:46 CEST] <Elirips> kepstin: yes, I mean that.. but I use 'updatefirst 1'.. and its working as it is overwriting the same file
[19:36:35 CEST] <Elirips> using version ffmpeg version N-78252-gb62825a
[19:37:48 CEST] <kepstin> Elirips: in this case, your filename doesn't have anything that looks like a pattern, so I don't think the value of the '-update' option makes a different. (I'd have to double-check the source to be sure)
[19:38:41 CEST] <Elirips> kepstin: its quite confusing
[19:39:21 CEST] <Elirips> well, I have to move on. I'll try tomorrow with the latest version of ffmpeg and try to use just 'update 1' instead of 'updatefirst 1'
[19:39:57 CEST] <kepstin> oh, "update" and "updatefirst" are aliases of each-other, they do the same thing
[19:41:12 CEST] <lavalike> kepstin, DHE, I see
[19:41:16 CEST] <Elirips> its just very confusing: If I search for open handles on a file, I see that an instance called with an output-file of 'cam01.jpg' suddenly has a handle to 'cam02.jpg'
[19:41:55 CEST] <Elirips> which makes the instance that is supposed to write to 'cam02.jpg' fail because it cannot move its .tmp file to the destination
[19:42:07 CEST] <kepstin> that is a bit odd... since the filename has no pattern in it, there's no way that ffmpeg could generate a new filename with a different number
[19:42:28 CEST] <Elirips> indeed
[19:42:40 CEST] <Elirips> I'm not 100% sure if the output of process explorer is 100% correct
[19:42:47 CEST] <kepstin> so, my guess is that there's a typo somewhere, or you've matched up the wrong process
[19:43:05 CEST] <Elirips> but I see that the file is locked, and if I kill the instance reported by process explorer the lock is gone
[19:43:31 CEST] <Elirips> I checked for typos in the command-line / evaluation of the handles / etc. for half a day now :/
[19:44:09 CEST] <Elirips> will ffmpeg internally use anything like named pipes that could interfere if I start about 60 instances at the same time?
[19:45:01 CEST] <kepstin> I don't know enough about windows to say for sure, but I don't see why it would. You can run a ton of them on linux with no issue.
[19:45:45 CEST] <kepstin> my best guess is that you've simply started up two using the same filename, and the output of the process explorer is confusing/misleading/wrong?
[19:46:06 CEST] <kepstin> maybe you're making an ffmpeg command that has multiple output files listed?
[19:46:48 CEST] <Elirips> I'm pretty sure my commands are correct, and what process explroer tells me matches up with the behaviour, but yes, its absolutely... ill...
[19:46:51 CEST] <kepstin> given the options you say you're using, an ffmpeg told to output to cam01.jpg will never open cam02.jpg.
[19:47:09 CEST] <Elirips> that helps already a lot
[19:47:35 CEST] <Elirips> then process exp. must be wrong
[19:47:52 CEST] <kepstin> of course, it is usually more helpful if you can pastebin the entire command line exactly as you're running it, and the output here
[19:48:03 CEST] <Elirips> anyway, I'm out of time
[19:48:06 CEST] <Jnorthrup> hello!
[19:48:17 CEST] <Elirips> I'll check back tomorror / next week - except I find my stupid mistake tomorrwo
[19:48:20 CEST] <Elirips> thanks for all the input
[19:48:33 CEST] <Jnorthrup> I am using the latest, static windows 64 ffmpeg from... ffmpeg.org
[19:49:13 CEST] <kepstin> Jnorthrup: that doesn't make sense, ffmpeg.org doesn't distribute windows builds.
[19:49:30 CEST] <kepstin> Jnorthrup: you mean the ones from https://ffmpeg.zeranoe.com/builds/ ?
[19:49:42 CEST] <Jnorthrup>  i can refine that...  ffmpeg version N-80011-gaf3e944 Copyright (c) 2000-2016 the FFmpeg developers
[19:49:50 CEST] <Jnorthrup> that looks right
[19:51:08 CEST] <Jnorthrup> """ffmpeg   -i C:\t\Source_4_3_anamorphic_SD_PAL.mpeg -vf scale="720:404",setsar=1/1,pad="720:486:0:43:black" -ar 48000 -ac 2   -r ntsc  -qscale:v 2  -y m.mxf""" is creating a raster bar line of pixels top and bottom played through vlc, ffplay, and windows media player.
[19:51:24 CEST] <Jnorthrup> ^split line
[19:51:46 CEST] <Jnorthrup> the last scanlin goes to about 33% of the frame then continues as padding
[19:52:08 CEST] <Jnorthrup> opposite happens on the first inner scanline of the clip
[19:52:19 CEST] <Jnorthrup> like its been rotated a tenth of a degree
[19:53:35 CEST] <Jnorthrup> same for mp4 format output as well, with whatever different codecs
[19:57:52 CEST] <furq> Jnorthrup: does it happen if you use an even number instead of 43
[20:01:47 CEST] <Jnorthrup> well, yes, but it looks inconsistent like the source media might be an influence depending on screen motion and color
[20:04:35 CEST] <Jnorthrup> looks good enough to ship.  concerning nonetheless :)
[20:17:42 CEST] <Jnorthrup> the source media is a transcode witha  fuzzy last scanline.  the artifact exists in the source media as a much more vague scanline. my ffmpeg transcode is apparently making a determination color or black and there is a hard processing artifact resulting from the "boolean" determination in mid scanline
[20:44:35 CEST] <kepstin> ouch, if you have a partial scanline at the end, then the original digital video capture wasn't centered correctly :/ If you're rescaling & padding anyways, it might make sense to crop a bit extra just to clean that up.
[20:47:29 CEST] <kepstin> I assume your input is a 720x576 stream if it's PAL?
[20:51:59 CEST] <kepstin> (btw, your setsar is wrong if your output is intended to be 4:3 ntsc; it should be '11/10')
[21:19:29 CEST] <Jnorthrup> kepstin: it is anamorphic PAL so it was 16:9 source encoded to 4:3 -- but the broadcast spec says 720x486 target geom
[21:20:17 CEST] <Jnorthrup> so the client wants 720x 404? 16:9 with letterbox
[21:20:34 CEST] <kepstin> yeah, anamorphic pal is something ridiculous like 864/531 sar, and 720x486 as 4:3 ntsc is 11/10 sar
[21:20:35 CEST] <Jnorthrup> im just working backwards through various handbrake notes
[21:21:02 CEST] <kepstin> getting the exact height and width for this scaling to get the aspect correct will be a pain :/
[21:21:30 CEST] <Jnorthrup> i put down ffmpeg 10 years ago, never heard of anamorphic before this week
[21:22:11 CEST] <kepstin> because of stupid video standards, you need to scale the middle 702.9 pixels of the PAL video to fill the middle 704 pixels of the NTSC video, then set the height to 369 pixels
[21:22:27 CEST] <Jnorthrup> anamorphic _anything_ seems to be "some hack we used to record" and then someone went wikifying thier experience for the world to accept as a standard
[21:22:28 CEST] <kepstin> then if you use the 11/10 sar, it'll be correct, assuming the original video was correct
[21:23:25 CEST] <kepstin> (the width difference is only about 1 pixel total - so I wouldn't bother; leave it as 720)
[21:24:54 CEST] <kepstin> er, did I say 369? typo, i mean 396
[21:25:44 CEST] <kepstin> so, -vf scale=720:396,pad=720:486:0:36,setsar=11/10 should be correct enough
[21:26:01 CEST] <Jnorthrup> wait,  so why is pal shifting 702.9 pixels into 704 NTSC pixels ?  is this the shape of the cathode ray tubes differing here?
[21:26:17 CEST] <kepstin> just strange differences in how the video sampling was defined :/
[21:27:08 CEST] <kepstin> if you're really curious, http://lurkertech.com/lg/video-systems/#480i_nonsq_sampling and http://lurkertech.com/lg/video-systems/#576i_nonsq_sampling (or read the whole page to get an idea of how badly everything is messed up)
[21:27:28 CEST] <kepstin> first link is ntsc 720x486, second link is pal 720x576
[21:27:45 CEST] <JEEB> 625 you mean?
[21:28:26 CEST] <kepstin> the "clean aperture" is the section of the picture that has the standard "aspect ratio" of 4x3 or 16x9 when displayed on a screen
[21:29:02 CEST] <JEEB> this is another page which might be harder to read than the lurker's guide but does lead you to them numbers and how they get calculated http://chromashift.org/aspectratio/
[21:29:06 CEST] <kepstin> JEEB: PAL is a "625" line standard, but normal digital sampling only captures 576 lines of picture (the other lines contain sync and things)
[21:29:14 CEST] <JEEB> kepstin: yes I know :)
[21:29:30 CEST] <JEEB> blu-ray spec f.ex. calls the resolutions 625 and... 525 I think?
[21:29:37 CEST] <JEEB> but actual res is 480 and 576
[21:29:42 CEST] <JEEB> (the other way)
[21:30:14 CEST] <kepstin> the really annoying thing is that dvd and bluray mpeg files use 720x480 as ntsc, which is *usually* just 720x486 with the bottom 6 pixel cropped off ;)
[21:30:43 CEST] <JEEB> well at least the blu-ray spec specifies the SAR values
[21:30:50 CEST] <kepstin> (but not always, so vertical alignment is fun)
[21:30:53 CEST] <JEEB> DVD only had "generic" values like 4:3 or 16:9
[21:31:12 CEST] <JEEB> + DVD was generally paper only so getting your hands on the text was :effort:
[21:31:22 CEST] <kepstin> yeah, dvd players were expected to ignore the mpeg sar values and display with the appropriate sar according to the video standard used, I guess :/
[21:31:45 CEST] <Jnorthrup>     Stream #0:0: Video: mpeg2video (Main), yuv420p, 720x486 [SAR 11:10 DAR 44:27], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn
[21:31:58 CEST] <JEEB> so yeah, when doing encoding for blu-ray you can at the very least know how the thing's supposed to be shown
[21:32:25 CEST] <JEEB> and since it's very likely it's just taking that stuff from the DVD side with SD
[21:32:29 CEST] <kepstin> Jnorthrup: note that your video is gonna look pretty juddery from the 25->30000/1001 framerate confersion
[21:32:34 CEST] <JEEB> I'm generally using that as the guiding point
[21:32:45 CEST] <kepstin> at least the hidef video standard are less annoying
[21:32:50 CEST] <kepstin> square pixels! yay!
[21:34:24 CEST] <JEEB> not in the SD side of blu-ray, though
[21:34:48 CEST] <kepstin> Jnorthrup: if your output device supports interlaced video, you could telecine 25->30 then speed up by 1.001x to make the video smoother.
[21:34:53 CEST] <JEEB> but at least the sar values are defined :)
[21:35:49 CEST] <kepstin> JEEB: they're 11/10 and 44/30 for "4:3" and "19:9 anamorphic", right?
[21:36:19 CEST] <kepstin> anything else would be really annoying, since then it would be *different* from what other stuff does :/
[21:36:27 CEST] <kepstin> (above numbers for ntsc)
[21:36:27 CEST] <Jnorthrup> i just got the order for 16:9 in NTSC pal.  my output still has some black edges along the side now 1-2 pixels depending on whiteness of the scene
[21:36:58 CEST] <Jnorthrup> woops "in ntsc 4:3"
[21:37:07 CEST] <JEEB> kepstin: 480i with 40:33 | 10:11 and 576i with 16:11 | 12:11
[21:37:24 CEST] <kepstin> Jnorthrup: keep in mind that the active picture area for ntsc is only the middle 704 pixel, anything outside of that doesn't matter and won't be shown.
[21:37:40 CEST] <kepstin> (aside from some computer players, which do show it, but whatever)
[21:37:42 CEST] <JEEB> kepstin: I can confirm that this page shows you the info that's in the spec http://www.x264bluray.com/home
[21:37:44 CEST] <Jnorthrup> ooh! ammo for the bugreport!
[21:38:27 CEST] <kepstin> most computer players don't automatically crop ntsc or pal video, but if shown on a TV you won't see the edges.
[21:39:05 CEST] <JEEB> and to be honest players shouldn't crop that stuff unless there's metadata for that. which there is none of with DVDs
[21:40:10 CEST] <kepstin> well, with dvds you can assume that the content's either ntsc or pal, and assume that it was sampled using the standard methods, and then display only the clean aperture. But that's a lot of assumptions :)
[21:40:10 CEST] <furq> what's the active picture width for pal
[21:40:21 CEST] <furq> based on these dvds i've been ripping lately it's "whatever we feel like today"
[21:40:26 CEST] <JEEB> with DVDs another issue with PC players is that the field used for aspect ratio is generic and doesn't specify if it should be taken in as the truth, or viewed through the ye olde lense. Although DVD-specific players can always limit themselves :)
[21:40:50 CEST] <kepstin> furq: 768*(54/59) according to http://lurkertech.com/lg/video-systems/#576i_nonsq_sampling
[21:41:23 CEST] <JEEB> the one I linked is the old article from uwasa, it was mirrored on chromashift.org
[21:41:33 CEST] <JEEB> it has a lot of the details regarding that funkyness
[21:42:07 CEST] <JEEB> + how to derive the exact values (of which those that are used in blu-ray are simpler approximations)
[21:42:32 CEST] <kepstin> note that the bluray spec got the pal sar values wrong, should be 54/59. But the 16/11 value is nicer for computer use, since it gives 768*(11/12) which is exactly 704px rather than 702.90...
[21:42:39 CEST] <kepstin> er, the 12/11
[21:43:03 CEST] <JEEB> uhh
[21:43:17 CEST] <JEEB> I recommend reading the chromashift link I posted
[21:45:56 CEST] <kepstin> hmm. http://lurkertech.com/lg/video-systems/#sqnonsq calculates it straight from the sampling frequencies used to get 59/54 for pal.
[21:46:28 CEST] <kepstin> oh, are there multiple different sampling rates used? :/
[21:47:13 CEST] <JEEB> it's a messy thing, and around part 2 (connection between the analog and the digital) it starts getting calculated
[21:47:25 CEST] <kepstin> hmm, no, that lines up with the ""Industry standard" square pixels for 625/50 systems" from the chromashift page
[21:47:31 CEST] <Jnorthrup> Input #0, mpeg, from 'C:\t\Source_4_3_anamorphic_SD_PAL.mpeg':
[21:47:33 CEST] <Jnorthrup>   Duration: 00:00:20.09, start: 0.457189, bitrate: 5685 kb/s
[21:47:34 CEST] <Jnorthrup>     Stream #0:0[0x1e0]: Video: mpeg2video (High), yuv420p(tv), 720x576 [SAR 1:1 DAR 5:4], 5184 kb/s, 25 fps, 25 tbr, 90k tbn
[21:47:36 CEST] <Jnorthrup>     Stream #0:1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s
[21:47:38 CEST] <Jnorthrup> no 576i here
[21:48:46 CEST] <JEEB> kepstin: also there's this perl script based on the stuff written in that page I linked http://ps-auxw.de/cgi-bin/ar-calc.pl
[21:49:40 CEST] <JEEB> and yes, it's a mess.
[21:49:53 CEST] <kepstin> JEEB: ah, I see, the person on the chromashift page tried to calculate "exactly square pixels" rather than use the not-quite-square industry standard "square pixel" sampling
[21:50:24 CEST] <kepstin> which means, those values don't line up with what industry standard hardware does :/
[21:53:00 CEST] <kepstin> industry says "sample at 14.75MHz and call it square", which is what leads to the 54/59 value. chromashift person tried to calculate how to make it exactly square, which gives 4320/4739, and bluray folks took a simplified fraction that was easier to deal with in digital media, which gives 11/12
[21:53:08 CEST] <kepstin> fun.
[21:54:25 CEST] <JEEB> basically if one looks at the blu-ray values then the chromashift stuff looks very muchos correct since it just seems to be simplified
[21:54:48 CEST] <JEEB> here's the comparison for the 576i values http://up-cat.net/p/9fdc8052
[21:54:51 CEST] <kepstin> (btw, the industry standard value gives 0.91667, bluray gives 0.91525, a tiny difference, and chromashift gives 0.91158, bigger difference from both)
[21:55:36 CEST] Action: kepstin did v/h for that
[21:55:55 CEST] <Jnorthrup> bleh, anamorphic bad.
[21:56:12 CEST] <kepstin> so in most cases, you can treat the bluray and industry standard sampling values as the same; the error is pretty small.
[21:56:13 CEST] <Jnorthrup>  beer good!
[21:57:15 CEST] <kepstin> of course, these are all the 4:3 ratios, to get the anamorphic 16:9 ones, multiply the h by (16/4) and the v by (9/3)
[21:57:31 CEST] <kepstin> no question about that from anyone, at least :/
[21:57:48 CEST] <JEEB> I've basically been keeping the values mentioned in chromashift as the correct stuff, and used the blu-ray values for DVD and blu-ray purposes
[21:59:04 CEST] <Jnorthrup> i never had any complaints flattening all the things to square pixels and doing splices and then spending 10x that long fixing for faad/faac desync
[21:59:23 CEST] <Jnorthrup> never done broadcast before
[21:59:32 CEST] <kepstin> the chromashift values will give theoretically more square pixels, if you take a 720x576 video and display it on a computer screen, but i wouldn't use it for anything else, since it differs from the "square pixel" sampling values that hardware samplers use :/
[22:00:21 CEST] <kepstin> and I wouldn't bother treating the hardware "square pixel" sampling and bluray sar differently, since the margin of error is so small.
[22:02:45 CEST] <kepstin> of course, the only time that this conversion would come up is if for some reason you have square video and want to convert to non-square video for e.g. encoding to bluray or dvd
[22:03:14 CEST] <kepstin> in which case, you could use either the 11/12 or 54/59 values pretty much interchangably and nobody would notice :?
[22:03:43 CEST] <kepstin> (and the bluray values are nicer, because you don't have fractional pixels)
[22:04:09 CEST] <JEEB> aspect ratio can be quite wrong and people just wouldn't notice, so yeah - blu-ray values are what I go with because that's what the SAR values get to be written @ SD BD
[22:04:36 CEST] <JEEB> the AVC stuff is much nicer because it removed the implied values from aspect ratio values
[22:04:58 CEST] Action: kepstin is in north america and basically doesn't deal with pal, so at least everything's always just 10/11
[22:04:58 CEST] <JEEB> MPEG-2 Video was plagued by the fact that the field just said "16:9" or "4:3"
[22:05:22 CEST] <JEEB> so it was fully context specific
[22:05:32 CEST] <JEEB> rather than "this is my SAR, biatch"
[22:06:17 CEST] <kepstin> yep. but handily, a dvd player was usually designed for either pal or ntsc, and so it only needed to know that "if video is 4:3, use sar X, if video is 16:9 use sar Y"
[22:06:51 CEST] <JEEB> yes, if the player had the context it was simple
[22:07:08 CEST] <kepstin> (and even a multiformat player could autodetect by just seeing the number of lines or framerate of the video)
[22:08:16 CEST] <JEEB> I would rather autodetect by checking if you're playing a DVD. Not sure about DVB/ATSC digital SD stuff. Not sure how fucked up SD digital broadcast specs are.
[22:08:49 CEST] <JEEB> F.ex. I have no idea which aspect ratio values should be used with my own country's SD DVB broadcasts
[22:09:18 CEST] <JEEB> oh, and for extra fun there's Japanese ISDB-T SD broadcasts, which are BT.709.
[22:09:52 CEST] <kepstin> for digital broadcast video? it's simple... is the video 576 line? it's pal, use the pal sar; if it's 486/480 line? it's ntsc, use the ntsc sar
[22:10:20 CEST] <JEEB> if I would have to actually poke such streams I'd probably go on read the specs
[22:10:32 CEST] <JEEB> esp. the Japanese case could be funky
[22:10:34 CEST] <kepstin> the only difference between the japanese and north american standards was something about signal level, iirc; they're the same sar.
[22:11:26 CEST] <JEEB> yeah but at least the colorimetry for Japanese SD is BT.709. No idea if that also means that you're supposed to treat the aspect ratio as modern stuff as well.
[22:11:54 CEST] <JEEB> (back when I read ARIB specs I only focused on the colorimetry and thus I remember nothing on how AR was spec'd)
[22:12:04 CEST] <kepstin> if the video's still 720x486/480? then no, it's still the same old sar.
[22:12:20 CEST] <kepstin> since it would just be the same old sd video played without being resampled
[22:12:41 CEST] <JEEB> quite possible, but yeah - I'd probably take a look at the regional specs :)
[22:12:44 CEST] <kepstin> (although maybe with color matrix adjustments - but I bet that half the time they forget to do that, too)
[22:12:57 CEST] <JEEB> nah, the colors are correctly BT.709
[22:13:10 CEST] <JEEB> at least in my limited checks
[22:13:48 CEST] <kepstin> you sure? if a tv station has an old video file sampled using bt.601 they might not fix the color matrix before broadcasting it... but then who knows :)
[22:14:27 CEST] <JEEB> yeah, sure - fucked up samples can happen everywhere :) but at least the stuff I could confirm was indeed following the ARIB specification
[22:14:38 CEST] <kepstin> (it could be hard to tell unless you actually have the correct video to compare too, iirc getting that wrong is just a slight color cast)
[22:15:00 CEST] <JEEB> yeah, you can't confirm it without comparing
[22:15:10 CEST] <JEEB> and having a known-correct rendering of the same stuff
[22:16:01 CEST] <kepstin> at least with BT.202 it should be really obvious if something's wrong ;)
[22:16:03 CEST] <kepstin> 2020
[22:16:05 CEST] <JEEB> yeah
[22:16:19 CEST] <JEEB> it was real fun looking at the first .jp BT.2020 broadcasts in players
[22:16:27 CEST] <kepstin> *and* they dropped interlaced modes completely
[22:16:28 CEST] <kepstin> about time
[22:16:41 CEST] <JEEB> special coding modes, yes. but you still can code fields separately
[22:16:46 CEST] <JEEB> and signal them correctly
[22:16:49 CEST] <JEEB> (in HEVC)
[22:17:04 CEST] <JEEB> BT.2020 itself removed interlacism though, yes
[22:17:07 CEST] <kepstin> the codecs support it, but BT.2020 doesn't allow them
[22:18:31 CEST] <JEEB> SMPTE ST 2084 is also fun
[22:18:36 CEST] <kepstin> I'm surprised HEVC kept an interlaced encoding mode, but i guess that's what happens with design by committee; someone influential probably just said they had to be able to use it for legacy interlaced media :/
[22:18:53 CEST] <JEEB> well, leaving header fields was simple
[22:19:07 CEST] <JEEB> and would keep the cable TV mafia happy
[22:19:25 CEST] <JEEB> they tried real hard to convince the committee that special modes were needed
[22:19:34 CEST] <JEEB> but pretty much got "fuck you"'d on JCT-VC
[22:19:45 CEST] <kepstin> oh, did they actually still include an actual interlaced encoding transform like h264's mbaff?
[22:19:48 CEST] <kepstin> or not?
[22:19:51 CEST] <JEEB> no
[22:19:54 CEST] <JEEB> no special coding modes
[22:20:02 CEST] <JEEB> literally just header values
[22:20:09 CEST] <JEEB> frame vs field and top/bottom
[22:20:18 CEST] <JEEB> IIRC
[22:20:28 CEST] <JEEB> so you code fields as separate pictures
[22:20:38 CEST] <JEEB> just like normal video
[22:20:45 CEST] <Venti^> yes, there is nothing else... although they could not have worded the specification any less clearly
[22:22:02 CEST] <kepstin> hmm. do they allow selecting the frame vs field encoding to be switched per-picture?
[22:22:07 CEST] <Venti^> there are some uses for interlacing in HEVC, mostly to do with proprietary workflows that _have_ to work with legacy interlaced content though
[22:22:25 CEST] <JEEB> yeah, I'm fine with the header values be there
[22:22:25 CEST] <kepstin> (similar to h.264's PAFF mode?)
[22:23:55 CEST] <Venti^> I wish decoders supported the header values though...
[22:25:33 CEST] <Venti^> I tried to push a patch to ffmpeg, but it turned out that having two input pictures result in one output picture in ffmpeg caused way too many problems, at least more than my limited understanding of ffmpeg could resolve
[22:25:43 CEST] <kepstin> hmm. it's apparently "per-stream", so i guess it's in some codec initialization metadata? or every IDR frame when you're doing e.g. an mpeg-ts broadcast?
[22:26:37 CEST] <JEEB> Venti^: yeah the framework seems to expect both fields in one picture or so but then the decoder is trying to be modern and output fields separately (plus in some cases I think it gets the timing values wrong for them)
[22:26:53 CEST] <JEEB> so there's a mismatch of how things are implemented
[22:27:06 CEST] <Venti^> kepstin: it's per picture... there is some wording in the spec for setting them per stream, but my understanding is that they do nothing and you have to say the interlacing and field order for every picture anyway
[22:27:29 CEST] <JEEB> pretty much
[22:29:52 CEST] <kepstin> so to handle interlaced hevc in ffmpeg right now, you'd have to manually throw on a 'tinterlace' filter to recombine the fields?
[22:30:23 CEST] <JEEB> if you want the following filters handle it correctly, yes :)
[22:30:53 CEST] <JEEB> if that filter takes two pictures and puts them together :P
[22:31:32 CEST] <kepstin> with mode=merge that is indeed exactly what it does.
[22:32:57 CEST] <JEEB> if HEVC had any more usage someone would probably fix the later stuff to not expect fields merged
[22:33:50 CEST] <kepstin> well, I think it would require adding some additional frame metadata to indicate that a given "frame" is actually a field, and whether it's a top or bottom field.
[22:34:49 CEST] <kepstin> then you could even have it auto-insert a filter that recombines fields, setting interlaced and tff/bff flags correctly and passes through progressive frames.
[22:41:57 CEST] <pfelt> OT: anyone around that has exp. with a sencore mrd?  i'm having a hard time finding x264 settings compatible with the mrd we have
[22:43:59 CEST] <pgorley> Is it normal that ffmpeg -hwaccels returns vdpau when I have an Intel GPU? Shouldn't it be vaapi?
[22:44:46 CEST] <JEEB> mesa IIRC has a vdpau API nowadays, but I'm not sure if you want to use that one on !nvidia even though it's available
[22:44:47 CEST] <kepstin> that prints a list of the hwaccels ffmpeg was compiled to support; has nothing to do with what's actually useful on your system.
[22:44:53 CEST] <pgorley> Oh
[22:44:54 CEST] <JEEB> oh, right
[22:44:59 CEST] <JEEB> that list isn't dynamic
[22:44:59 CEST] <JEEB> :D
[22:45:05 CEST] <pgorley> I should recompile then
[22:45:17 CEST] <JEEB> also it will only list the stuff that ffmpeg.c can handle
[22:45:33 CEST] <JEEB> so if ffmpeg.c doesn't have a va-api using thing in it, then it's not gonna be there
[22:45:43 CEST] <JEEB> at least that's what I think
[22:45:47 CEST] <kepstin> it currently prints 'vdpau qsv vaapi' on my system, with a recent git
[22:46:03 CEST] <kepstin> but 'qsv' doesn't actually work, since I haven't convinced the intel media stuff to install yet.
[22:46:49 CEST] <kepstin> and vaapi doesn't work, since something weird about me running in a wayland session rather than X maybe?
[22:46:57 CEST] <kepstin> :/
[00:00:00 CEST] --- Fri May 20 2016