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

[burek]

[06:16:21 CET] <illegal> how come I can't see stream size in mediainfo whenever I mux with ffmpeg?
[06:16:26 CET] <illegal> I wonder how does mediainfo even get the stream size to begin with
[11:13:54 CET] <ItWasntM_> can anyone tell me how to run ffplay or ffmpeg using dshow output?  I can't seem to find a way to do it.  I want to choose XXX sound card to output audio
[12:12:43 CET] <AlienPenguin> Hi, i am trying to compile ffmpeg 3.2.9 on windows using visual studio 2010, i am following the trac guide, however i found an error while compiling avcodec/proresdec2.c: at line 601 there are two "for" loops with the cycling vars defined within the for definition. I extracted the var definition and it seems to be going good... was this a known issue? or some bad config on my side?
[12:14:24 CET] <SortaCore> I compile it on VS2015 fine
[12:14:45 CET] <SortaCore> not sure if VS2010 is recent enough
[12:16:17 CET] <AlienPenguin> SortaCore, vs2015 should accept that since it supports c99, however i did install, as per trac the c99 convert tools
[12:16:30 CET] <AlienPenguin> and that error i mentioned is the only one that was reported
[12:17:46 CET] <fritsch> what did it complain at this line?
[12:18:12 CET] <fritsch> ah!
[12:18:16 CET] <AlienPenguin> unknown identifier for the loop variable
[12:18:24 CET] <fritsch> it might have a problem with the non need { ?
[12:18:26 CET] <fritsch> hehe
[12:19:19 CET] <fritsch> https://paste.ubuntu.com/26226630/
[12:19:24 CET] <fritsch> but that would be funny
[12:20:15 CET] <AlienPenguin> fritsch, was that a known issue then?
[12:21:05 CET] <fritsch> no - but looking at that code that is all "my imagination" can come up with
[12:21:22 CET] <fritsch> AlienPenguin: can you try it?
[12:21:47 CET] <fritsch> I was not born in 2010 - therefore no idea what happened there in VS
[12:22:00 CET] <AlienPenguin> fritsch, in a while, what i did now was to declare i and j out of the for loops
[12:22:13 CET] <fritsch> which is just making the scope larger
[12:22:32 CET] <fritsch> but i think the issue here rather is that VS has a problem determining the scope
[12:27:16 CET] <therage3> would I need to downscale a 24-bit FLAC audio file to 16-bit before burning a Red Book audio CD? if so, do I need to do it manually?
[12:27:32 CET] <furq> therage3: yes
[12:27:40 CET] <furq> whether you'd need to do it manually depends on what burning tool you're using
[12:28:03 CET] <therage3> yeah, I see
[12:28:03 CET] <furq> i assume some of them will convert to 16/44.1 pcm before burning
[12:28:14 CET] <therage3> I'm just concerned because some people tell me to dither first, others tell  me don't do it
[12:28:18 CET] <therage3> and now I'm all confused
[12:28:23 CET] <furq> it makes no difference really
[12:28:34 CET] <therage3> ._.
[12:28:37 CET] <therage3> so confused
[12:28:37 CET] <therage3> lol
[12:28:39 CET] <furq> it's technically better to dither but you won't be able to hear the difference either way
[12:28:47 CET] <fritsch> therage3: are those audiophile guys that need a green light to hear that stuff sounds great?
[12:28:49 CET] <furq> like with 95% of stuff that audiophiles obsess over
[12:28:51 CET] <therage3> hm I see
[12:29:01 CET] <fritsch> therage3: then I would give them an USB stick ... with the original flac
[12:29:25 CET] <therage3> fritsch: both are audiophiles, the ones that tell me to do it with as well as without dithering, so it's all over the place
[12:29:40 CET] <fritsch> let's do the following
[12:29:44 CET] <fritsch> make it work
[12:29:47 CET] <furq> therage3: ffmpeg -i foo.flac -sample_fmt s16 -dither_method triangular -ar 44100 -filter_size 256 -compression_level 12 foo.wav
[12:29:50 CET] <fritsch> and afterwards tell the one guy: dithered
[12:29:52 CET] <furq> er
[12:29:53 CET] <fritsch> the other one: it's not
[12:29:58 CET] <furq> ffmpeg -i foo.flac -sample_fmt s16 -dither_method triangular_hp -ar 44100 -filter_size 256 -compression_level 12 foo.wav
[12:30:09 CET] <fritsch> you can avoid the triangular
[12:30:11 CET] <furq> triangular_hp is the same thing as sox very high quality, which is what people usually recommend
[12:30:13 CET] <therage3> fritsch: haha, nice. i'll need to try that
[12:30:17 CET] <furq> but yeah, it hardly makes any difference
[12:30:22 CET] <therage3> furq: nice
[12:30:26 CET] <furq> and it's very unlikely to make any audible difference
[12:30:26 CET] <fritsch> I'd check for the cutoff
[12:30:28 CET] <fritsch> frequency
[12:30:49 CET] <furq> er
[12:30:55 CET] <furq> get rid of compression_level as well
[12:31:08 CET] <therage3> i was going to ask
[12:31:12 CET] <therage3> since wav's are, well, uncompressed
[12:31:13 CET] <therage3> lol
[12:31:15 CET] <furq> you might be able to tell that i took this command from an earlier pastebin for someone asking how to do it with flac
[12:31:29 CET] <fritsch> cutoff 1.0 filter_size 256
[12:31:32 CET] <fritsch> and fine
[12:32:15 CET] <furq> what's wrong with the default cutoff
[12:32:29 CET] <fritsch> furq: nothing - but audiophiles you know
[12:32:32 CET] <furq> lol
[12:32:44 CET] <fritsch> in kodi I implemented: high low mid
[12:32:54 CET] <furq> i mean if 1.0 is technically better than 0.97 then i'll add it for the future
[12:32:57 CET] <fritsch> and high uses stuff that CPU load increases over mid by at least 5%
[12:33:06 CET] <fritsch> so that the audiophiles have a CPU load feedback
[12:33:09 CET] <furq> i'm sure it won't be inaudible but this paste is normally going out to audiophiles
[12:33:19 CET] <furq> er, won't be audible
[12:33:39 CET] <furq> -filter_size 256 is already overkill but it sure gives a nice spectrogram of a sweep sample
[12:34:14 CET] <fritsch> jep
[12:34:18 CET] <fritsch> Set cutoff frequency (swr: 6dB point; soxr: 0dB point) ratio; must be a float value between 0 and 1. Default value is 0.97 with swr, and 0.91 with soxr (which, with a sample-rate of 44100, preserves the entire audio band to 20kHz).
[12:34:47 CET] <fritsch> so - no need to change anything
[12:34:55 CET] <fritsch> but yeah, most guys that asked you to dither :-)
[12:35:09 CET] <fritsch> might tell you, that they hear those frequencies ;-) "above" that band
[12:35:27 CET] <fritsch> while they hear whales singing from 1000 km distance and dog pipes before piping them
[12:35:39 CET] <furq> i mean there are people that claim they can hear a difference between aiff and wav
[12:35:47 CET] <fritsch> but in that case I would just blame the speakers of their audio phile cd player
[12:35:48 CET] <furq> everything is possible
[12:35:55 CET] <fritsch> I make blind tests with them
[12:36:00 CET] <fritsch> it's quite easy
[12:36:21 CET] <fritsch> the stranges guys are those that flac encode dts wavs
[12:36:28 CET] <fritsch> :-)
[12:36:37 CET] <fritsch> and then in kodi use the software volume
[12:36:40 CET] <fritsch> and come and complain
[12:36:52 CET] <furq> i mean dts wav is already horrible
[12:37:01 CET] <furq> mux it into mka or something
[12:37:03 CET] <fritsch> jep, but at least you know what might be coming
[12:37:08 CET] <fritsch> and can check
[12:37:20 CET] <fritsch> but decoding flac and checking for DTS no way
[12:37:54 CET] <fritsch> actually thinking of "downdither" from 24 bit to 16 bit
[12:38:02 CET] <fritsch> if that not actually makes more stuff "around" worse
[12:38:32 CET] <fritsch> but yeah - trying to think as audiophile makes life unhappy
[12:38:32 CET] <furq> what you should do is just silently resample everything to 16/48, and then after a year, announce that you did that
[12:38:37 CET] <furq> and see how many people actually noticed
[12:38:42 CET] <fritsch> +1
[12:38:51 CET] <fritsch> like the guy with the 3000 dollar usb dac
[12:38:56 CET] <fritsch> that attached it to android
[12:38:58 CET] <fritsch> :-)
[12:39:01 CET] <fritsch> and used audiotrack
[12:39:08 CET] <fritsch> that resampled everything and all to 48 / 16
[12:39:11 CET] <furq> nice
[12:39:14 CET] <fritsch> he was happy a very long time
[12:39:19 CET] <fritsch> until he saw his DAC display
[12:39:31 CET] <furq> no doubt he was happy until someone pointed it out to him, at which point he realised it actually sounded terrile
[12:39:36 CET] <fritsch> jep
[12:39:37 CET] <furq> b
[12:39:45 CET] <fritsch> same with HD passthrough vs. lpcm decode
[12:39:58 CET] <fritsch> but, but, but my AVR's green light does not light up
[12:40:31 CET] <fritsch> okay, enough fun with the audiophiles
[12:40:55 CET] <fritsch> therage3: buy them the original CD
[12:41:04 CET] <fritsch> from your cold hands ...
[12:42:01 CET] <furq> if it's 24-bit then hopefully it's a better master than exists on cd
[12:43:00 CET] <furq> strong emphasis on hopefully there
[12:43:55 CET] <fritsch> hehe
[12:44:02 CET] <fritsch> most likely ripped from CD
[12:44:06 CET] <fritsch> and "dithered up" haha
[12:52:38 CET] <therage3> well, here's the context
[12:52:44 CET] <therage3> this is the product:
[12:52:58 CET] <therage3> https://data-discs.com/products/sonic-mania
[12:53:12 CET] <therage3> this vinyl comes with a download code for both a FLAC and a lossly mp3 version
[12:53:24 CET] <therage3> the FLAC version is the one I'm dealing with; it's 24-bit, 44.1kHz
[12:53:59 CET] <therage3> i have no clue how the FLAC mastering was done, either from a vinyl or how
[12:56:37 CET] <furq> i assume it'll just be the masters they got from the artist
[12:56:59 CET] <therage3> that still leaves open the question, how the artist came up with those masters
[12:57:11 CET] <therage3> i guess I could send Tee Lopes an email or something and ask
[12:57:11 CET] <furq> by making them?
[12:57:20 CET] <furq> either way there's no cd release of that album
[12:57:30 CET] <therage3> yes, exactly
[12:57:34 CET] <therage3> that's precisely the problem
[12:58:25 CET] <furq> at least you got one of their releases that isn't just dumped from a modded megadrive
[12:59:10 CET] <therage3> megadrive? this is a new game for new consoles
[12:59:16 CET] <furq> i know
[12:59:17 CET] <therage3> not a Sonic game from the early 90s
[12:59:24 CET] <therage3> but yeah I get you
[12:59:34 CET] <furq> data discs have released a lot of megadrive stuff which is just dumped from a console
[12:59:36 CET] <therage3> a lot of people make "OST's" by using the soundtest feature of the game
[12:59:38 CET] <therage3> and record it
[12:59:48 CET] <furq> the only exception is the bare knuckle stuff iirc
[12:59:50 CET] <therage3> and God knows wtf they did to "record" it
[13:00:02 CET] <furq> which is probably just sourced from koshiro's remasters he did for the anniversary cd
[13:00:12 CET] <therage3> I see
[13:01:57 CET] <furq> even their shinobi soundtrack is sourced from a console
[13:02:10 CET] <furq> and i'm sure koshiro has masters of those
[13:02:29 CET] <therage3> damn
[13:02:30 CET] <furq> it's nice of them to be up front about it though
[13:02:55 CET] <furq> there are at least two remastered cds of that soundtrack and i have no idea what the provenance is
[13:02:58 CET] <therage3> maybe they wanted the sound to be identical to what the actual gaming hardware plays
[13:03:08 CET] <therage3> so that people don't go "heyyyy this isn't what's on the game"
[13:03:10 CET] <therage3> i dunno
[13:03:53 CET] <furq> shrug
[13:04:14 CET] <furq> actually
[13:04:17 CET] <furq> http://vgmdb.net/album/4642
[13:04:22 CET] <furq> Disc 1: The Super Shinobi & Bare Knuckle: Ikari no Tekken -PC-8801 Version-
[13:04:44 CET] <furq> the pc-88 is what koshiro composed these on, so he obviously does still have the masters
[13:04:58 CET] <furq> with that said the pc-88 versions of bare knuckle 2 do sound noticeably different
[13:09:43 CET] <therage3> I see
[13:13:36 CET] <furq> aww
[13:13:46 CET] <furq> i saw data discs have previews on their soundcloud, so i thought i'd compare some of the masters
[13:14:00 CET] <furq> but i forgot soundcloud is 128k mp3 and so it just sounds like garbage anyway
[13:15:13 CET] <zash> what is this, 1996?
[13:16:15 CET] <furq> i should try and track down a copy of gunstar heroes because all the cd masters of that sound like garbage
[14:32:23 CET] <khali> good afternoon folks
[14:32:57 CET] <SortaCore> heyo
[14:33:08 CET] <SortaCore> I'm about to go to bed
[14:33:13 CET] <SortaCore> #Brexit
[14:37:18 CET] <khali> alexpigment: I have prepared the samples for you
[14:39:44 CET] <khali> let me know if/when you have time to look at them
[16:07:30 CET] <alexpigment> khali, i'll take a look, but odds are someone else might be more able to help
[16:17:14 CET] <khali> alexpigment: both files are at http://jdelvare.nerim.net/avidemux_vs_ffmpeg/
[16:17:28 CET] <khali> same source, same x264 settings
[16:17:53 CET] <alexpigment> oh this issue. right ;)
[16:18:07 CET] <alexpigment> i was thinking this was something someone else mentioned
[16:18:28 CET] <khali> ffmpeg-generated file is 45% larger
[16:18:32 CET] <alexpigment> k
[16:18:37 CET] <alexpigment> downloading now
[16:18:40 CET] <khali> I stripped sound to get it out of the equation
[16:18:46 CET] <alexpigment> good thinking
[16:19:28 CET] <khali> the only difference I can see is that tbn and tbc values are different
[16:19:57 CET] <khali> I did not specify them, so I don't know how avidemux and ffmpeg decided them
[16:20:38 CET] <alexpigment> well, this might indicate that one is progressive and one is interlaced
[16:21:12 CET] <alexpigment> because mediainfo shows "original frame rate" of 50fps with the avidemux version
[16:21:18 CET] <therage3> lol
[16:21:22 CET] <therage3> so many bad memories
[16:21:29 CET] <therage3> soooo so many bad memories of this very topic
[16:21:29 CET] <alexpigment> :)
[16:21:41 CET] <khali> alex: but mediainfo says Progressive for both files still
[16:22:51 CET] <alexpigment> yeah I see that. but the original frame rate thing I've seen in the past. in my experience it's that the interlacing is done via "separated fields" rather than MBAFF. either way, i'm just throwing that out there as a slight possibility. still looking
[16:22:53 CET] <khali> (the source is clearly interlaced though, you are right)
[16:23:25 CET] <therage3> khali: i had issues exactly like yours, different programs reporting different things
[16:23:35 CET] <therage3> in my case, it turned out to be a shitty mastering process
[16:23:51 CET] <therage3> it was a cartoon that was hard telecined but with bizarelly random hard-telecined frames
[16:23:55 CET] <therage3> which made a lot of filters act up
[16:25:52 CET] <khali> alexpigment: I can't share the source file itself as it is 6 GB, but I can provide any information you need about it
[16:25:53 CET] <alexpigment> khali: out of curiosity, you're presumably wanting to deinterlace, right?
[16:26:21 CET] <alexpigment> and assuming you are, do you want to keep the original motion smoothness (50fps) or decimate down to 25fps?
[16:26:33 CET] <khali> I can also share the 1st few MBs of it if it helps
[16:26:40 CET] <khali> alexpigment: no I don't
[16:26:59 CET] <alexpigment> khali: ok so you're fine with the interlaced combing in the output?
[16:27:21 CET] <khali> the samples are the very beginning of the recording, I chose that because it was easier to produce the 2 files
[16:27:38 CET] <khali> but what I'm actually interested it is later in the source file, and it is not interlaced
[16:28:32 CET] <alexpigment> if you cut the latter part of the source file? if it's actually true progressive, I'm wondering if that ends up the same size in both programs
[16:28:39 CET] <khali> in my experience DVB-T streams are always advertised as interlaced even when the actual material is progressive, probably for "compatibility reasons"
[16:29:37 CET] <khali> alexpigment: no, the file size problem persists, that's even how I noticed it in the first place
[16:30:10 CET] <khali> but I can generate new samples from the right section, if you think this is relevant
[16:30:39 CET] <alexpigment> not yet. looking more into this
[16:31:56 CET] <khali> I have added the output of mediainfo on the source, for your convenience
[16:32:49 CET] <alexpigment> ok, so here are my thoughts:
[16:33:48 CET] <alexpigment> 1) avidemux might be preserving the interlacing, even if mediainfo reports progressive. like I said, it also shows "original frame rate" or 50fps, which only generally exists when some aspect of the video is interlaced, in my experience
[16:34:54 CET] <alexpigment> 2) you've got this set to level 5.0, which is not what I would expect from a 1080p25 video. it's possible that avidemux is enforcing a lower bitrate limit (like 4.0 or 4.1) and ffmpeg is taking full advantage of the 5.0 bitrate limitations
[16:35:28 CET] <alexpigment> you can rule out number 2 by setting them both to level 4.0 and see if the bitrate becomes basically the same
[16:36:44 CET] <alexpigment> you can rule out number 1 by adding an interlacing filter in avidemux. use Yadif and set it to the default settings; in ffmpeg, similarly add -vf yadif=0
[16:37:08 CET] <khali> alexpigment: adding "-level 4.0" on the ffmpeg command line would do that?
[16:37:15 CET] <alexpigment> yeah
[16:37:28 CET] <khali> trying right now
[16:37:59 CET] <khali> I was surprised that 5.0 is the default btw, as I read that most devices available only support 4.1
[16:38:38 CET] <DHE> that's about right. 4.1 supports 1080p at 30fps
[16:38:59 CET] <alexpigment> yeah, 5.0 is generally only necessary for higher resolutions than 1080p
[16:39:16 CET] <alexpigment> even 4.2 is all that's needed for 1080p60/50
[16:39:44 CET] <alexpigment> of course, if the bitrate gets extremely high, you'll hit level 5.0
[16:43:18 CET] <khali> alexpigment: I tried with -level 4.0, no change in file size
[16:43:38 CET] <alexpigment> yeah, i didn't think that was going to be it, but I figured I'd mention it
[16:43:41 CET] <khali> only difference is "Format profile : High at L4" in mediainfo output
[16:43:47 CET] <alexpigment> with such a low average bitrate, it probably isn't spiking too much
[16:43:59 CET] <DHE> can a -level really change anything? the only settable h264 parameter that it can clamp is the reference frame count. libx264 can't change the framerate or the resolution of the input image.
[16:44:35 CET] <alexpigment> DHE: I only mentioned it in case avidemux adds vbv options on the backend to enforce levels
[16:44:52 CET] <alexpigment> ffmpeg doesn't do that for x264 though
[16:45:14 CET] <khali> producing yadif files now
[16:45:33 CET] <DHE> but x264 does that itself. you specify the level to the encoder and it will clamp settings. similarly for preset and profiles
[16:47:40 CET] <alexpigment> DHE: are you sure? if you set level 4.0 and CRF ~1, it'll go beyond the 4.0 bitrate limits I believe
[16:50:40 CET] <alexpigment> fwiw, I just did a test with a high CRF, set one to level 4.0 and one to level 5.0. the file sizes are the same and the avergae bitrate is 102mbps on both
[16:53:27 CET] <khali> with yadif filter applied, avidemux output is down from 15.2 MB to 12.9 MB, and ffmpeg output is down from 22.0 MB to 18.6 MB
[16:53:37 CET] <alexpigment> weird
[16:53:56 CET] <alexpigment> i'm going to try one more thing and then probably give up
[16:53:58 CET] <alexpigment> 1 sec
[16:54:22 CET] <khali> well it is expected that both go down, as the source is indeed interlaced, so progressing encoding was certainly a nightmare for x264 ;-)
[16:54:40 CET] <khali> progressive*, sorry
[16:55:25 CET] <alexpigment> does mediainfo still report an original frame rate of 50 for the one using yadif?
[16:55:43 CET] <alexpigment> the one from avidemux specifically
[16:57:42 CET] <DHE> alexpigment: https://github.com/mirror/x264/blob/master/encoder/set.c#L816 seems I'm wrong. it will show warnings/errors instead of clamp. it doesn't appear to be fatal to the encoder though.
[16:58:23 CET] <alexpigment> also, have you tried putting in -preset veryslow in your ffmpeg command line? everything looks like this should be equivalent, but maybe there's something else that occurs when you explicitly set it
[16:58:35 CET] <alexpigment> DHE: good to know
[16:59:31 CET] <alexpigment> DHE: if you have a chance, take a look at khali's sample files above. he's got one file from avidemux and one from ffmpeg, seemingly using the exact same settings, but the ffmpeg one is significantly bigger
[16:59:41 CET] <alexpigment> i'm out of ideas about what the difference might be
[17:00:31 CET] <khali> alexpigment: yes, after yadif is applied, I still see "Original frame rate : 50.000 FPS" in the mediainfo output
[17:00:50 CET] <alexpigment> k
[17:01:14 CET] <khali> and yes I tried setting -preset veryslow for ffmpeg
[17:01:35 CET] <alexpigment> ok, i'm completely out of ideas then. maybe someone else here might spot the key factor
[17:02:31 CET] <khali> this changes the values of the lookahead_threads, bframes and direct, but does not affect the file size noticeably
[17:04:26 CET] <alexpigment> i believe kepstin was helping you on this the other day, right? maybe he'll chime in and see if he can figure it out with those samples you provided
[17:05:16 CET] <khali> correct, he was trying to help as well
[17:05:26 CET] <khali> I have just uploaded the first 33M of the source file
[17:05:47 CET] <khali> which is the same video duration as my samples, roughly
[17:05:58 CET] <khali> in case it helps any
[17:06:19 CET] <khali> either way, thank you very much alex for your help, that was highly appreciated
[17:07:03 CET] <khali> at least, if you can't figure it out either, it means I'm not completely crazy or inept ;-)
[17:07:04 CET] <alexpigment> no worries. sorry I couldn't be of help
[17:07:26 CET] <alexpigment> you're implying that i'm not inept? ;)
[17:10:10 CET] <alexpigment> khali: actually, I think I just proved that the avidemux one is interlaced
[17:11:08 CET] <alexpigment> 1 sec
[17:12:06 CET] <alexpigment> ok, so I took the avidemux one into handbrake
[17:12:20 CET] <alexpigment> it's deinterlace filter seems to work a little bit better for reasons I don't fully understand
[17:12:48 CET] <alexpigment> anyway, I set it to deinterlace > Yadif > Bob > Interlaced Detection Off
[17:13:00 CET] <alexpigment> I then set the frame rate to 50fps in the Video section
[17:13:08 CET] <alexpigment> the resultant video has 50 unique frames per second
[17:14:31 CET] <khali> it reconstructs full frames from fields, using interpolation?
[17:14:42 CET] <alexpigment> well, not via interpolation
[17:14:52 CET] <alexpigment> maybe some interpolation
[17:14:57 CET] <alexpigment> it's mostly just line doubling though
[17:15:26 CET] <alexpigment> so every field has half the amount of vertical lines (540 instead of 1080). on the most basic level, it just doubles the field lines to 1080 and then makes it a frame
[17:15:27 CET] <khali> that's interpolation.... with weights 0 and 1 ;-)
[17:15:38 CET] <alexpigment> k :)
[17:16:15 CET] <alexpigment> I just meant that it's not interpolating frames in the sense that it's making up frame 1.5 by seeing the difference between frames 1 and 2
[17:16:32 CET] <khali> yes, of course not
[17:16:35 CET] <alexpigment> you know, that horrible thing that modern TVs do by default ;)
[17:16:47 CET] <khali> I know :(
[17:17:14 CET] <khali> I can't believe TV is still using interlaced cameras in 2017
[17:17:40 CET] <khali> these should have been banned from the planet one decade ago
[17:18:04 CET] <alexpigment> khali: well, given that most broadcast is still 1080i, it makes sense for the cameras to be as well, at least from one perspective
[17:18:18 CET] <khali> yeah
[17:18:19 CET] <alexpigment> although ideally, we'd be shooting in 1080p60/50 and the interlacing as necessary for the output
[17:18:28 CET] <khali> my point is that the whole chain should be progressive
[17:18:33 CET] <alexpigment> true
[17:18:57 CET] <khali> and if they want it as smooth as before, they can go 50p/60p
[17:19:05 CET] <alexpigment> but if streaming media is any indicating, getting rid of interlacing would mean than we'd be at 1080p30/1080p25 rather than 1080p60/50
[17:19:22 CET] <alexpigment> *indication
[17:19:30 CET] <khali> personally I would have killed interlacing first, before trying to increase resolution
[17:19:49 CET] <khali> true as well
[17:20:24 CET] <alexpigment> so back to the issue at hand: I'm not exactly sure why avidemux is treating the interlacing differently
[17:20:38 CET] <khali> but it's easier to produce 30p output from 60p source than decent 30p output from 60i
[17:20:48 CET] <alexpigment> but what I would try is to add -flags +ilme+ildct to the ffmpeg command
[17:21:11 CET] <khali> yes sir, trying immediately
[17:21:28 CET] <alexpigment> khali: true, although it depends on the type of source media. getting true ~24fps from 1080i is easy
[17:21:32 CET] <khali> without yadif, right?
[17:21:35 CET] <alexpigment> yeah
[17:21:57 CET] <alexpigment> now, the file sizes are not going to match, most likely. but I believe the file size will still go down on ffmpeg
[17:23:55 CET] <khali> hmmm ffmpeg seems unhappy
[17:24:09 CET] <khali> [libx264 @ 0x11bf0c0] interlace + weightp is not implemented
[17:24:09 CET] <khali> [libx264 @ 0x11bf0c0] using SAR=1/1
[17:24:09 CET] <khali> [libx264 @ 0x11bf0c0] interlaced (1) > level limit (0)
[17:24:27 CET] <alexpigment> oh, do you still have -level 4.0 specified?
[17:24:31 CET] <alexpigment> get rid of that
[17:24:51 CET] <alexpigment> and you can ignore the interlace + weight p and the using SAR messages
[17:24:53 CET] <alexpigment> that's normal
[17:25:14 CET] <khali> no I don't have level specified
[17:25:15 CET] <alexpigment> well, normal for me, anyway. i primarily work with interlaced content
[17:25:18 CET] <alexpigment> k
[17:25:36 CET] <alexpigment> i'd still ignore it
[17:25:41 CET] <khali> file size is a bit down indeed
[17:25:56 CET] <khali> from 22.6 MB to 21.7 MB
[17:25:59 CET] <alexpigment> is it comparable to the with_avidemux.mp4 sample you sent earlier?
[17:26:01 CET] <alexpigment> hmmm
[17:26:22 CET] <alexpigment> maybe a sample of the original source would be helpful for this after all
[17:26:25 CET] <khali> still nowhere close to what avidemux produces (15.6 MB)
[17:26:34 CET] <khali> I have uploaded that already
[17:26:50 CET] <alexpigment> I think avidemux is doing some weird handling of the interlacing. it's passing it off as progressive, but the interlacing is still there in some respect
[17:26:51 CET] <khali> you can download source.ps
[17:26:55 CET] <alexpigment> oh, it's on the same page
[17:27:04 CET] <khali> yep
[17:27:28 CET] <khali> it's a truncated file but hopefully for a MPEG-TS file it shouldn't matter much
[17:27:36 CET] <alexpigment> should be fine i think
[17:34:20 CET] <ZexaronS> Hello
[17:34:56 CET] <ZexaronS> I'm looking to find a way to burn-in DVBSUBtitles from a MPEGTS which uses 3 streams of DVBSUBs
[17:35:32 CET] <ZexaronS> I tried with VLC but no luck, I don't know how to select the correct DVBSUB stream (language)
[17:36:09 CET] <ZexaronS> I used the GUI, probably need to use a more refined command
[17:36:49 CET] <ZexaronS> Also, the file contains Teletext subtitles, which I think may be something else, but it's not showing DVBSUBs in MediaInfo, so I'll do a ffprobe
[17:46:54 CET] <alexpigment> khali: fyi, I'm trying to figure out which filter most closely matches how ffmpeg handles (or doesn't handle, rather) the interlacing of the original source
[17:47:14 CET] <alexpigment> i'll let you know what i find
[17:54:25 CET] <khali> alexpigment: ok
[17:54:58 CET] <khali> alexpigment: but I wonder if you aren't barking up the wrong tree
[17:55:49 CET] <alexpigment> khali: it's possible I am. but if I can get true 50fps out of the avidemux one and I can't out of the ffmpeg one, that means there's a lot more unique data in the one from avidemux
[17:55:53 CET] <khali> because the bitrate difference also exists on the portion of the source which is "progressive" (in the visual sense of the term... might be interlaced from a video stream perspective)
[17:56:24 CET] <khali> alex: but then the avidemux one would be larger, not smaller?
[17:56:34 CET] <alexpigment> it's valid point, but there may be some nuances in how the two types of content get processed
[17:57:52 CET] <alexpigment> khali: if ffmpeg sees every other line as being from a different timestamp, it's going to be harder to encode it into progressive. on the other hand, avidemux might be interpreting the source more correctly, encoding it as mbaff and saving bits because each line is similar to the one above and below it
[17:57:59 CET] <alexpigment> just kind of my off-the-cuff thought here
[17:58:39 CET] <khali> well one interesting data point is that I had to convert a completely different file, old avi which had not need properly encoded at the time
[17:59:04 CET] <khali> I did it with both avidemux and ffmpeg, and I get the same file size
[17:59:07 CET] <alexpigment> i think the real problem is that ffmpeg's handling of MPEG-4 with non-mbaff interlaced encoding is bad. I've had many experiences that point to this
[17:59:18 CET] <khali> (after aligning the settings, that is)
[17:59:35 CET] <khali> so the source definitely matters
[18:00:06 CET] <alexpigment> here's perhaps a better test
[18:00:15 CET] <khali> mediainfo claims my source is MBAFF-interlaced.... is it lying?
[18:00:16 CET] <alexpigment> you don't have something like adobe premiere or a pro level NLE do you?
[18:00:22 CET] <khali> no I don't
[18:00:40 CET] <alexpigment> khali: well, it says "separated fields"
[18:00:40 CET] <khali> running Linux here and no commercial software
[18:00:48 CET] <alexpigment> that's the key factor in my experience
[18:00:54 CET] <alexpigment> maybe non-mbaff is mispoken
[18:00:55 CET] <khali> ok
[18:01:09 CET] <alexpigment> but anything that says "separated fields", I've had to override ffmpeg's default detection
[18:01:29 CET] <alexpigment> this is common among consumer cameras that shoot 1080i
[18:01:34 CET] <alexpigment> in avchd
[18:01:36 CET] <khali> France switched from MPEG-2 to MPEG-4 for DVB-T not so long ago
[18:01:45 CET] <alexpigment> as they should
[18:01:52 CET] <alexpigment> i wish the US would do the same
[18:01:52 CET] <khali> beforehand I was using dvbcut and ffmpeg and it worked like a charm
[18:02:13 CET] <alexpigment> yeah, the reason I was asking about Premiere is that I was going to suggest converting to true interlaced MPEG-2
[18:02:19 CET] <alexpigment> and seeing if the result was the exact same
[18:02:24 CET] <alexpigment> i'll get you a sample in a few minutes
[18:02:38 CET] <khali> but dvbcut no longer works with MPEG-4.... which is how I ended up using avidemux instead.... but avidemux has a few annoying bugs :/
[18:03:02 CET] <alexpigment> if you had Windows, I would HIGHLY recommend videoredo
[18:03:09 CET] <alexpigment> i use that tool every single day
[18:03:58 CET] <alexpigment> that would also probably get rid of those ffmpeg error messages about missing reference picture probably
[18:04:29 CET] <CoreX> you gonna give him the $$$ for videoredo
[18:04:46 CET] <CoreX> tho you could just pirate it
[18:04:54 CET] <khali> no, I would not
[18:04:59 CET] <khali> obviously
[18:05:19 CET] <furq> http://www.videoredo.com/en/images/wwb_img6.jpg
[18:05:30 CET] <CoreX> lol
[18:05:41 CET] <alexpigment> yeah, they definitely get awards for bad stock images
[18:06:29 CET] <alexpigment> anyway, I purchased videoredo for like $50 originally and then upgraded at some point for some lower price. as for paid software, I've gotten my money's worth over and over
[18:06:45 CET] <alexpigment> I think tmpgenc has a similar smartcutter tool but i've never used it
[18:07:58 CET] <khali> handbreak doesn't offer any editing options, right?
[18:08:06 CET] <khali> handbrake* even
[18:08:18 CET] <alexpigment> not that i'm aware of
[18:09:11 CET] <alexpigment> fyi, i'm testing this again after converting to MPEG-2 in premiere
[18:09:12 CET] <CoreX> are you just trying to cut with ffmpeg in certain frames ?
[18:09:39 CET] <alexpigment> if i get the same file size in each, it'll confirm that it's ffmpeg's bad handling of mpeg-4 interlacing
[18:11:25 CET] <alexpigment> khali: ok, same file size now with the converted MPEG-2 source
[18:11:44 CET] <alexpigment> lemme look how i've worked around this in the past
[18:23:37 CET] <alexpigment> khali: ok, I've got the two encodes to match more or less
[18:24:27 CET] <alexpigment> ffmpeg -r 25 -i [source] [settings] -vf yadif=1 -r 25 [output]
[18:24:42 CET] <jaggz> how do I record from a pulseaudio source?  this is the device as displayed by "pactl list sources": http://slexy.org/view/s21zhjKCms
[18:25:34 CET] <alexpigment> avidemux: add filter Yadif > Bob, skip spacial temporal check > Top field first ; add filter Resample FPS > 25 (PAL)
[18:26:02 CET] <alexpigment> that makes both of them deinterlace to 50p, then drop frames down to 25fps
[18:26:18 CET] <alexpigment> which is personally what I'd do with interlaced source content, even if it's got progressive parts
[18:29:33 CET] <alexpigment> khali: of course, if you really want to preserve the original fidelity, make the output rate in ffmpeg be 50fps rather than 25fps. keep the -r 25 before the input though
[18:31:32 CET] <jaggz> https://www.ffmpeg.org/ffmpeg-devices.html#pulse
[18:31:39 CET] <jaggz> weird ffmpeg
[18:31:48 CET] <jaggz> says "PulseAudio input device.  To enable this output device..."
[18:32:18 CET] <fritsch> every output has a monitor attached
[18:40:36 CET] <khali> alexpigment: I never realized -r could be used for both input and output
[18:40:53 CET] <alexpigment> khali: yeah, it's kind of a way to ensure that the file is being read properly
[18:41:14 CET] <alexpigment> or perhaps a way to override the source frame rate for time stretching
[18:41:59 CET] <alexpigment> but either way, my MPEG-2 tests kinda confirmed that this disparity between the two applications has to do with how they handle interlaced MPEG-4. neither of them are really handling the video "right"
[18:42:37 CET] <alexpigment> so the file size may still be bigger than it was with the original avidemux, but at least now you'll have a file that can be properly read by most players
[18:42:47 CET] <khali> I understand, thanks for the investigation
[18:42:57 CET] <khali> but one thing worries me
[18:43:43 CET] <khali> I fully understand how it can affect the bitrate when the input frames are actually interlaced, as is the case of this sample
[18:44:25 CET] <khali> but when the input frames are from a progressive source (true 25 fps, not 50i), I can't see how it can make a difference
[18:45:10 CET] <alexpigment> you mentioned that there is a part that's progressive later on
[18:45:30 CET] <alexpigment> but I don't have that sample, so I can't speak on it
[18:45:50 CET] <alexpigment> maybe it too is actually interlaced and tagged wrong
[18:45:55 CET] <alexpigment> i can only speculate
[18:47:08 CET] <khali> I'll test again on what I believe is progressive
[18:47:13 CET] <khali> maybe I missed something
[18:48:39 CET] <alexpigment> khali: if you look in avidemux at File > Information, see what it says the frame rate is
[18:48:48 CET] <alexpigment> avidemux is shown 50fps on this source.ts file
[18:48:52 CET] <alexpigment> even though it's actually 25fps
[18:49:15 CET] <alexpigment> if it's doing the same thing on your 'progressive' sample, then it's probably handling it in the same quasi-interlaced way
[18:52:39 CET] <khali> alexpigment: it says 50 fps
[18:52:56 CET] <alexpigment> yeah, then i'd guess it's actually 25i
[18:53:31 CET] <khali> I think one cause of problems is that DVB-T streams both interlaced and progressive contents
[18:53:55 CET] <khali> and I guess it "looks better" to deinterlace everything than to deinterlace nothing
[18:54:03 CET] <alexpigment> how can you tell it's actually progressive and not just interlaced with identical fields?
[18:54:09 CET] <khali> so they take the easy way a treat everything as interlaced
[18:54:37 CET] <khali> sorry, what I say may be seen as technically incorrect
[18:54:54 CET] <alexpigment> i mean you ideally don't want to switch back and forth so you don't confuse decoders. in our cable system, everything that's 1080i stays interlaced the entire time
[18:55:09 CET] <khali> I mean that for example TV shows are recorded with interlaced cameras, while movies are recorded with progressive cameras
[18:55:15 CET] <alexpigment> ahh right
[18:55:18 CET] <khali> and both end up in the same DVB-T stream
[18:55:20 CET] <alexpigment> so, that's normal
[18:55:29 CET] <alexpigment> but you have to treat them differently if you're going to deinterlace
[18:55:48 CET] <khali> ideally the information would still be present in the DVB-T stream so that the end viewer (me) knows how to process it best
[18:55:59 CET] <khali> but in practice the information is long lost when the data reaches me
[18:56:05 CET] <alexpigment> well, actually, maybe not for PAL. i don't know what the hell they do for telecined content on PAL tv. maybe they do the 4% speedup
[18:57:13 CET] <khali> yes they do
[18:57:24 CET] <alexpigment> so in NTSC, most things are 1080i as I said. some of the content is filmed at 1080i (29.97fps, 59.94 effective rate), some of it is filmed at 23.976fps and some of it is filmed at 29.97fps
[18:57:40 CET] <khali> movies last a bit less when you watch them on TV in Europe, than in cinema or US TV
[18:58:08 CET] <khali> 25/24 telecine is simply not worth it.... would probably look horrible too
[18:58:43 CET] <alexpigment> so if i were going to deinterlace, i'd deinterlace true 1080i as 1080p50. i'd inverse telecine the film-sourced content to 23.976. i'd then deinterlace and drop frame for the 29.97fps progressive content. OR... i'd just leave it all interlaced. which is basically what i do because it require zero thought and looks correct on my tv
[18:59:05 CET] <alexpigment> *requires
[18:59:10 CET] <khali> hehe
[18:59:24 CET] <khali> perfectionism vs pragmatism :)
[19:00:18 CET] <therage3> the audiophile's worst nightmare
[19:09:47 CET] <khali> I'll have diner now, I'll resume working on this when I return
[19:09:56 CET] <khali> thanks a lot for all the help so far
[19:10:11 CET] <alexpigment> khali: yeah, that's kinda how I do it. I also realize that deinterlacing methods aren't perfect anyway, so pragmatism is kinda also still a better bet :)
[19:10:28 CET] <alexpigment> anyway, see you around later
[19:29:31 CET] <furq> alexpigment: i've only ever seen the 4% speedup but apparently film to pal pulldown is a thing
[19:29:44 CET] <furq> apparently it's called
[19:29:45 CET] <furq>     2-2pulldown.svg
[19:29:50 CET] <furq> shut up clipboard
[19:29:54 CET] <alexpigment> furq: yeah, I just didn't know how they did it for like TV shows. I knew movies did the speedup thing
[19:29:56 CET] <furq> apparently it's called 2:2:2:2:2:2:2:2:2:2:2:3 pulldown
[19:30:05 CET] <furq> you'll forgive me for obviously copying and pasting that
[19:30:09 CET] <alexpigment> but yeah, i knew there was that pulldown method which sounds horrible ;)
[19:30:34 CET] <furq> i've never seen it
[19:30:38 CET] <furq> but then i don't watch very much tv
[19:30:43 CET] <furq> i've certainly never seen it on a dvd
[19:30:43 CET] <alexpigment> i haven't either, but i live in the US, so that's my excuse
[19:31:03 CET] <alexpigment> yeah I think all commercial movies use a speedup
[19:31:15 CET] <furq> every pal film dvd i own is just sped up
[19:31:25 CET] <furq> or at least the ones that i've ripped are
[19:31:32 CET] <furq> i've not checked the times on all of them
[19:31:46 CET] <alexpigment> but since you can't do a speedup in realtime, i wondered if broadcast channels take 23.976 US tv feeds and apply a pulldown
[19:32:49 CET] <furq> 24fps us tv feeds?
[19:32:50 CET] <alexpigment> i realize it's unlikely that someone is getting a *live* 23.976fps feed, but still
[19:32:50 CET] <furq> is that a thing
[19:33:00 CET] <alexpigment> well, shows that are recorded in 23.976
[19:33:32 CET] <alexpigment> anyway, i'm just guessing here. I have no idea how things go down in PAL-land
[19:33:47 CET] <furq> i don't know that any live american shows are simulcast here
[19:33:52 CET] <furq> but if they are then they're probably not 24fps
[19:33:56 CET] <alexpigment> right
[19:34:03 CET] <alexpigment> it would be a 1080i60 > 1080i50 conversion
[19:34:07 CET] <furq> yeah
[19:34:08 CET] <alexpigment> which also sounds problematic
[19:34:13 CET] <furq> which i assume is just dropping every sixth frame
[19:34:38 CET] <furq> it's at least easier than a 480i to 576i conversion
[19:34:43 CET] <alexpigment> i can almost feel the 3:2 pulldown cadence being ruined ;)
[19:34:53 CET] <alexpigment> true
[19:44:43 CET] <kepstin> i think most 24000/1001fps content broadcast in the us is done telecined in a 60i stream :/
[20:25:55 CET] <alexpigment> kepstin: yeah, I figured so. I just didn't know in what form european TV stations get their content for syndication
[21:13:43 CET] <pos> so, i've got this application which is basically doing v:copy and a:copy from a source and piping it to a mp4 with some header mods. problem is, some of the sources are using their own sys or stream uptime as "length" which is messing with playback of said files later on
[21:13:58 CET] <pos> are there any params which will remedy this?
[21:16:17 CET] <pos> long story short: the files (which may last like five minutes) appear to vlc/mplayer/whatever to be for example 232 hours long
[21:41:49 CET] <khali> alexpigment: I tested again, and can only confirm what I said before
[21:42:38 CET] <khali> for film material, which is originally not interlaced, I see a similar difference between the two tools, for same x264 settings
[21:42:48 CET] <alexpigment> *originally is the operative word
[21:43:12 CET] <alexpigment> you have a video that has an interlacing method that neither avidemux nor ffmpeg handle the same way
[21:43:19 CET] <khali> well, I look at the pictures too, and my eyes tell me it's not interlaced and doesn't need deinterlacing
[21:44:28 CET] <alexpigment> khali: i completely understand that, but it *is* interlaced and it is being handled in a particular way. for example, ffmpeg is converting it to 25fps progressive, so it's not just keeping it interlaced
[21:44:45 CET] <khali> alex: I just don't get why either would even try anything, given that I did not enable any filter
[21:45:14 CET] <alexpigment> khali: here's a test you can do
[21:45:19 CET] <khali> alex: is there anyway I can convince ffmpeg that the input if not interlaced?
[21:45:26 CET] <khali> is* not
[21:45:27 CET] <alexpigment> 1 sec
[21:46:02 CET] <alexpigment> take what you out of ffmpeg, then re-run it through avidemux and then ffmpeg with those same settings. i assume the file size is the same now?
[21:46:21 CET] <alexpigment> khali: I think ffmpeg is not realizing it's interlaced in the first place
[21:47:05 CET] <alexpigment> avidemux does seem to realize that the file isn't 25fps progressive, but then it's doing some weird hack job on the output so that it writes a "progressive" file that actually has interlaced frames
[21:48:18 CET] <alexpigment> also, the test I mentioned above, which is taking your ffmpeg output from earlier (the file you put on your server) and re-running the encoding jobs in both avidemux and ffmpeg from this source should kinda prove this
[21:48:41 CET] <alexpigment> if the files end up the same size, that is
[21:49:14 CET] <khali> sorry, do you mean ffmpeg -> avidemux -> ffmpeg, or compare ffmpeg -> avidemux and ffmpeg -> ffmpeg?
[21:51:17 CET] <alexpigment> so, earlier you sent a file that was from source > ffmpeg
[21:51:27 CET] <alexpigment> and this one was bigger than source > avidemux
[21:51:34 CET] <khali> yes
[21:51:36 CET] <alexpigment> take that ffmpeg output
[21:51:51 CET] <alexpigment> run it through the same encoding path in both avidemux and ffmpeg
[21:52:05 CET] <alexpigment> basically re-encode what you've already encoded
[21:52:22 CET] <khali> yeah; that thing I was told to never do ;-)
[21:52:31 CET] <alexpigment> this is for testing and confirmation
[21:52:35 CET] <alexpigment> not for watching
[21:52:43 CET] <khali> and yes, same file size
[21:52:58 CET] <khali> 9473074 vs 9481282, can hardly be closer
[21:53:11 CET] <alexpigment> ok, so the reason is that the output from ffmpeg in the first encode is true progressive
[21:53:33 CET] <alexpigment> ffmpeg basically hamfisted your source and said "here you go. sorry about your fields" :)
[21:53:42 CET] <alexpigment> which is the default behavior for ffmpeg
[21:54:12 CET] <khali> and is the right thing to do in that case, right?
[21:54:27 CET] <alexpigment> it depends on what you want it to do
[21:54:49 CET] <alexpigment> if you're only interested in the part of the video that's true progressive, then I suppose so
[21:54:56 CET] <khali> yes
[21:55:07 CET] <alexpigment> but I would personally still use -yadif=0 on those progressive parts
[21:55:12 CET] <alexpigment> er
[21:55:15 CET] <alexpigment> -vf yadif=0
[21:55:30 CET] <khali> isn't it losing some information?
[21:55:37 CET] <alexpigment> now, the result of this is larger than the output of avidemux, and I understand that, but it's actually in the correct format
[21:56:02 CET] <alexpigment> well, if the content is true progressive in an interlaced stream, then each interlaced field should have exactly 1/2 of the information
[21:56:11 CET] <khali> so your conclusion is that I should stay away from avidemux?
[21:56:12 CET] <alexpigment> and -yadif=0 should combine each field into one frame
[21:56:33 CET] <alexpigment> khali: yeah, it's making a weird file that I don't think will play consistently on different players
[21:56:36 CET] <alexpigment> even if the output is smaller
[21:57:30 CET] <khali> and I've been using for over a year; yay :/
[21:57:40 CET] <alexpigment> if it works, it works, I guess
[21:58:00 CET] <khali> it works with VLC... didn't try the files anywhere else yet
[21:58:29 CET] <alexpigment> I've always felt avidemux was really janky. I get that it has its advantages (a preview that you can use to cut), but most everything it does can be done better by another application on Windows, for me
[21:58:49 CET] <khali> which brings me to my next question: is there a free alternative to avidemux running on Linux?
[21:58:59 CET] <alexpigment> well, VLC also doesn't handle interlacing correctly anyway, but it seems like you're not trying to watch the true interlaced part of the stream
[21:59:33 CET] <alexpigment> VLC makes you have to opt-in to an interlacing mode, and the only decent on is Yadif2x, which is a huge CPU hog and causes dropped frames on many systems
[21:59:38 CET] <khali> I think I'm trying to convince myself that interlaced material doesn't exist.... for my own peace of mind :D
[21:59:51 CET] <alexpigment> khali: there are a lot of people who are in that boat
[22:00:08 CET] <alexpigment> but almost everything I deal with is interlaced, so it's something I have to think about regularly
[22:00:54 CET] <khali> more seriously, I don't record anything interlaced... the few interlaced things I watch, I watch live, and forget about them
[22:01:34 CET] <alexpigment> that's understandable. most things I record are things that don't get rebroadcast ever again, and most of them are true 1080i
[22:01:56 CET] <alexpigment> anything else (tv shows, etc), they'll generally be around for years whenever I want to watch them
[22:02:05 CET] <khali> I was horrified when I found that Breaking Bad had been recorded with TV (interlaced) cameras
[22:02:16 CET] <alexpigment> ah, so the telecine was burned in?
[22:02:19 CET] <khali> and skipped it altogether, although I was told it was pretty good
[22:02:35 CET] <alexpigment> yeah, it's a good show
[22:02:48 CET] <alexpigment> but even if the cameras are interlaced, it's probably in a telecine mode
[22:03:07 CET] <alexpigment> which means that they almost certainly inverse telecined for the master copies
[22:03:18 CET] <khali> what was broadcast on TV here was purely non-encodable
[22:03:26 CET] <khali> I tried a few tricks and gave up
[22:03:29 CET] <alexpigment> there, yes
[22:03:38 CET] <kepstin> well, the problem with doing telecine in camera is that they might have done editing on the interlaced stuff, so there could be bad cuts and mismatched overlays and stuff
[22:03:52 CET] <kepstin> crossfades are the worst :(
[22:04:02 CET] <alexpigment> wouldn't you IVTC before editing though?
[22:04:20 CET] <alexpigment> maybe there's a nuance of telecine modes on cameras that I don't understand
[22:04:40 CET] <kepstin> well, if you just open the stuff you get off the camera in your editing suite, it'll open in interlaced mode
[22:04:52 CET] <alexpigment> right, but we're talking about a major TV studio
[22:05:12 CET] <alexpigment> probably with Blu-ray and streaming distribution in mind from early on
[22:05:41 CET] <kepstin> sure would be nice if that was the case, wouldn't it?
[22:06:00 CET] <alexpigment> kepstin: well, I don't have any reason to think otherwise
[22:06:11 CET] <alexpigment> again, maybe you have info that I don't have
[22:06:15 CET] Action: kepstin notes that crunchyroll gets interlaced raws for some stuff, and they ocassionally fail to detelecine it correctly.
[22:06:53 CET] <alexpigment> that's all anime, right?
[22:07:01 CET] <kepstin> yeah
[22:07:59 CET] <alexpigment> do they actually film it these days?
[22:08:11 CET] <kepstin> anime is normally produced at 24p, with animation traditionally done on 2s (so 12fps), but it's usually edited on - often cheap, previous generation - tv equipment which sometimes doesn't do 24p so you edit on the telecined stuff
[22:08:30 CET] <alexpigment> oh you mean analog sourced content
[22:08:44 CET] <kepstin> no, even digital
[22:08:49 CET] <alexpigment> ah
[22:08:59 CET] <alexpigment> well, consider me ignorant on anime tech
[22:09:06 CET] <kepstin> nah, hasn't been filmed (aside from some movies) since around the mid-late 2000s.
[22:11:16 CET] <alexpigment> anyway, for the sake of steering back to one previous tangent, the breaking bad blu-ray discs are 1080p
[22:11:30 CET] <alexpigment> at some point it got IVTC'd
[22:11:43 CET] <alexpigment> I would hope that would be during the ingestion phase
[22:12:08 CET] <alexpigment> and if not, I guess there are some bad cuts here and there
[22:12:12 CET] <kepstin> i wouldn't be surprised if it was done during bd mastering tho :/
[22:12:29 CET] <alexpigment> maybe
[22:13:25 CET] <kepstin> not saying that's what happened on this show, but i'm pretty sure that is the case for a decent amount of stuff.
[22:19:32 CET] <alexpigment> right, khali was specifically talking about breaking bad; i was just letting him know that the interlaced cameras don't mean that the show was stuck in an interlaced format
[22:19:43 CET] <alexpigment> i.e. the masters for the show are probably in 24p
[22:32:25 CET] <pos> alexpigment, so that's why BB looks weird
[22:32:28 CET] <pos> now i know
[22:33:10 CET] <alexpigment> looks like film to me, but ok
[22:33:21 CET] <alexpigment> pos: did you watch it in a PAL broadcast?
[22:33:25 CET] <pos> on the same tangent: why are walking dead eps so frigginin huge (filesize-wise) compared to others?
[22:33:40 CET] <pos> i can't say the quality is that much better
[22:33:43 CET] <furq> probably grainy
[22:33:54 CET] <pos> any other show: 800-1200mb per 42 mins. wd: 2.1 b
[22:34:01 CET] <pos> gb
[22:34:14 CET] <alexpigment> pos: you're talking about a lossy secondary encode
[22:34:19 CET] <pos> ofc
[22:34:25 CET] <alexpigment> whoever encoded them probably also felt it was worth preserving more quality
[22:34:30 CET] <alexpigment> but grain plays into that as well
[22:34:42 CET] <pos> well, i'm assuming that killers&co know what they're doing
[22:34:45 CET] <furq> https://www.dvdtalk.com/reviews/images/reviews/274/full/1377569910_3.jpg
[22:34:47 CET] <furq> yeah this is super grainy
[22:34:59 CET] <furq> i'm not surprised it's closer to film filesizes
[22:37:01 CET] <pos> right, 'cause almost every pixel changes between each frame
[22:37:03 CET] <pos> ofc
[22:37:29 CET] <furq> also i'm looking at some rips here that are 7-10GB per episode
[22:37:42 CET] <furq> Overall bit rate : 29.6 Mbps
[22:37:45 CET] <pos> what, 1080p TS?
[22:37:53 CET] <furq> 1080 x264
[22:37:56 CET] <alexpigment> furq: that sounds like a blu-ray rip without transcoding
[22:37:57 CET] <furq> crf 17
[22:38:03 CET] <furq> they're hdtv rips
[22:38:07 CET] <alexpigment> CRF 17 on a grainy source will definitely do it
[22:38:32 CET] <furq> well that's 43 minutes
[22:38:35 CET] <alexpigment> I use CRF 18 and end up with 2GB+ rips for 30 minute TV shows regularly
[22:38:36 CET] <furq> so 9GB is a fair old amount
[22:38:52 CET] <alexpigment> then again, my cable company sucks so it's already pretty lossy to begin with
[22:38:59 CET] <furq> lol
[22:39:30 CET] <furq> even the amazon web-dls of this show are massive
[22:39:32 CET] <alexpigment> saying "cable company" and bad quality is almost redundant
[22:39:36 CET] <furq> like 4.7GB per episode
[22:39:45 CET] <alexpigment> that's good to hear though
[22:40:00 CET] <alexpigment> i appreciate that they're not cutting the bitrate too much
[22:40:12 CET] <furq> and then ofc there's one scene group doing 480p rips at 330MB per episode
[22:40:16 CET] <furq> god bless
[22:40:24 CET] <alexpigment> haha
[22:40:27 CET] <therage3> lol
[22:40:48 CET] <furq> i expect there's one scene group doing 1/2 cd xvid rips
[22:40:49 CET] <alexpigment> you gotta help out the people that are still using their modded Xbox for their media center! :)
[22:40:55 CET] <furq> but sadly not where i'm looking
[22:41:23 CET] <alexpigment> maybe they were aiming at 350MB and just reached saturation....
[22:43:32 CET] <pos> i keep coming across asian/middle eastern repos filled with tertiary encode 350mb files
[22:43:42 CET] <pos> bandwith, storage, sharing i guess
[22:44:03 CET] <alexpigment> yeah, when you see 350, you know you're deal with people who are still stuck in the "rip for CD" mindset
[22:44:17 CET] <pos> ofc, over there they sell CDs with this stuff at market
[22:44:28 CET] <alexpigment> yeah, i don't doubt it
[22:44:53 CET] <alexpigment> "pardon me. do you have the newest walking dead on VCD?"
[22:45:18 CET] <pos> ofc sir
[22:45:23 CET] <alexpigment> "oh you have SVCD? I'll have to check that my player can do that"
[22:45:45 CET] <pos> would you like a copy of the last jedi too? super quality :)
[22:45:59 CET] <alexpigment> "i'll take the best camrip you have!"
[22:46:12 CET] <pos> no, this is cinema quality, sir
[22:46:28 CET] <alexpigment> :)
[22:46:39 CET] <pos> ofc they also sell dvd player able to play xvid :)
[22:47:05 CET] <furq> didn't china have its own weird hd disc format
[22:47:09 CET] <alexpigment> yeah
[22:47:15 CET] <alexpigment> CVD i think
[22:47:58 CET] <alexpigment> i think CVD is just SVCD with a really bad horizontal resolution
[22:48:03 CET] <pos> well, imagine living on two dollars a day and having gov censorship up the wazoo. ofc the market will thrive
[22:48:18 CET] <furq> i think CBHD is the one i'm thinking of
[22:48:20 CET] <alexpigment> like VCD horizontal res + SVCD vertical res = CVD
[22:48:24 CET] <alexpigment> oh that one
[22:48:29 CET] <furq> i'm sure i remember it being successful enough to merit a longer wikipedia entry
[22:48:30 CET] <alexpigment> yeah, i don't remember the deal with that one
[22:49:16 CET] <furq>  CBHD uses the PRC government-owned AVS video codec, DRA audio codec,[4] and a new copy protection system, DKAA, as an alternative to HD DVD's and Blu-ray's AACS.
[22:49:42 CET] <furq> http://vpaste.net/S9gz5
[22:49:45 CET] <furq> you know i did that immediately
[22:49:48 CET] <alexpigment> i mean normally i would say this is a fail on china's part
[22:49:49 CET] <pos> and i'm assuming that they managed to keep the keys under lock and key? :P
[22:49:58 CET] <furq> oh i'm sure they did that
[22:50:01 CET] <alexpigment> but i'm sure blu-ray licensing is prohibitive
[22:50:24 CET] <furq> i really want to see some AVS encoded footage now
[22:50:42 CET] <pos> wasn't it chinese manufs ineptitude or lack of caring which lead to the leak of aacs keys?
[22:50:57 CET] <alexpigment> pos: i don't know, but that seems very plausible
[22:51:35 CET] <pos> and then every other image on digg was bart simpson writing said key on a blackboard while the mpaa was trying to take down half the sites on the inet?
[22:51:41 CET] <furq> aacs was cracked through windvd iirc
[22:51:51 CET] <furq> the keys were just sitting in memory while a dvd was being played
[22:52:22 CET] <furq> i think the bluray keys might have been leaked because of some china hardware though
[22:53:01 CET] <furq> i'm pretty sure those early analog capture rips of 4k blurays were done through chinese hdmi boxes that didn't bother with hdcp
[22:53:25 CET] <alexpigment> well, there's one company that makes a stripper
[22:53:37 CET] <pos> oh, konig hdmi audio splitters don't care either
[22:53:39 CET] <alexpigment> whoever makes HDfury
[22:53:55 CET] <furq> hdfury is chinese fwiw
[22:54:10 CET] <alexpigment> well, I remember it was a big deal when they were forced to take the device off the market
[22:54:17 CET] <pos> hdmi in, optical and no-hdcp hdmi out .)
[22:54:24 CET] <alexpigment> I don't even have anything 4k, so I don't know how just general splitters work
[22:54:35 CET] <furq> dcp tried to sue them and it got dropped because they don't actually strip hdcp, they just downgrade it to a lower (already cracked) version
[22:54:40 CET] <furq> which is explicitly allowed by the license
[22:54:44 CET] <pos> prolly won't work with 4k/new hdcp though
[22:55:04 CET] <alexpigment> yeah, HDCP is really crazy with 4k
[22:55:20 CET] <pos> and slysoft got shut down
[22:55:26 CET] <furq> it works up to 2.2 apparently
[22:55:28 CET] <alexpigment> so much that you have to have specific PC hardware from the last 2 years to even play a 4k Blu-ray
[22:55:30 CET] <furq> which i think is the latest?
[22:55:43 CET] <pos> still, i'm seeing tons of x265 4k content getting pushed, so it is possible
[22:55:56 CET] <furq> i've seen some 4k bluray remuxes
[22:56:00 CET] <furq> i'm not sure how that's being done
[22:56:34 CET] <alexpigment> let's put it this way, if I'm going to own a 4k Blu-ray, I'll probably just play the 4k Blu-ray for the time being
[22:56:48 CET] <alexpigment> those file sizes are going to be huge and compression will take forever
[22:57:19 CET] <pos> are they not like bd+? inet connection and auth required for playback?
[22:57:39 CET] <alexpigment> what do you mean?
[22:57:52 CET] <pos> back when aacs got whacked they launched bd0
[22:57:54 CET] <pos> bd+
[22:57:59 CET] <alexpigment> ah
[22:58:08 CET] <pos> your player had to have an inet connection and had to auth each playback
[22:58:12 CET] <alexpigment> well they made some attempt at prevent piracy in 2010
[22:58:20 CET] <alexpigment> and there were a lot of new things that players had to do
[22:58:24 CET] <alexpigment> no analog outputs
[22:58:33 CET] <pos> i was assuming they went all in with 4k
[22:58:36 CET] <alexpigment> bd+, bd live, avchd 2.0
[22:59:25 CET] <pos> judging from release logs (and file sizes) the situation hasn't really changed :)
[23:00:32 CET] <pos> but i sure as fsck won't be buying a 4k set until i find a not-smart OLED i like
[23:00:52 CET] <alexpigment> yeah, i'm still using 2008 samsung TVs that work great
[23:00:54 CET] <pos> current LGs are all smart: no way
[23:01:10 CET] <alexpigment> i'm trying to figure out when it's a good time to buy a 4k tv
[23:01:17 CET] <alexpigment> because now certainly doesn't seem like the right time
[23:01:19 CET] <pos> not now
[23:01:34 CET] <alexpigment> let's let this HDR thing shake out first at least
[23:02:00 CET] <alexpigment> and then whenever OLED gets cheaper or samsung's tech doesn't have any technical downsides
[23:02:08 CET] <pos> you get a tv with software/firmware made by an ad agency (scroogle) or it will be lackluster in some other way
[23:02:26 CET] <alexpigment> well, I honestly don't trust LG to make a good TV
[23:02:34 CET] <alexpigment> but they've got a monopoly on OLEDs right now
[23:02:34 CET] <pos> oh, they make great panels
[23:02:40 CET] <pos> the software though...
[23:02:43 CET] <alexpigment> right
[23:02:51 CET] <alexpigment> when I say a "good tv" i mean the whole package
[23:02:55 CET] <pos> well, the sony oled (with lg panel) is sweeet
[23:03:04 CET] <alexpigment> yeah, i've heard that
[23:03:06 CET] <pos> but is is huge bc of the integrated speaker/woofer
[23:03:19 CET] <pos> and ofc: android tv
[23:03:21 CET] <pos> no thanks
[23:03:48 CET] <pos> present me with an OLED signage (non-smart) display: take my money
[23:03:51 CET] <alexpigment> pos: i think you'll just have to accept that all modern TVs are "smart" and their smart components will become obsolete at some point
[23:04:04 CET] <pos> no, "signage" is becoming a think
[23:04:08 CET] <pos> thing
[23:04:20 CET] <pos> finally
[23:04:33 CET] <alexpigment> yeah, that's a possibility, but I assume there are some downsides with signage TVs
[23:04:42 CET] <khali> thank everybody again for the help, especially alex, I'll go to bed now
[23:04:44 CET] <alexpigment> like lack of certain processing modes or perhaps ports
[23:04:50 CET] <pos> great panels, great expected lifetime, no smart features
[23:04:56 CET] <alexpigment> khali: cool, have a good nice
[23:05:59 CET] <pos> yeah, LG has close to a monopoly on OLED. and samsung is pushing this weird quantum dot LCD fairytale. they still can't show a proper red
[23:06:22 CET] <pos> not a single samsung (lcd) set i've seen since 2008 can show a proper red
[23:06:28 CET] <pos> always orange/pinky
[23:07:01 CET] <pos> ofc it didn't help that the store put a pioneer next to the samsungs ofc
[23:07:15 CET] <pos> "how do you like them apples"
[23:09:25 CET] <pos> i don't get why they did it though. that's like putting a veyron in a datsun store. ofc everyone is going home "to think about it"
[23:12:02 CET] <pos> ever tried out those high-end lg OLEDs? the remote functions as a mouse pointer for the menus
[23:12:17 CET] <pos> gawd, that is awful to use
[23:12:55 CET] <pos> it's like using a laser pointer for a mouse
[23:13:49 CET] <furq> actually i'm one of the three people who really enjoyed navigating menus on the wii
[23:15:38 CET] <alexpigment> furq: yeah, you're weird ;)
[23:16:14 CET] <alexpigment> pos: i'm very much in your camp of having simplified things. when harmony stopped having physical number buttons on their remotes, consider me done as a customer
[23:16:31 CET] <alexpigment> and i'm not going to use my phone as a remote like an idiot
[23:16:40 CET] <alexpigment> just give me some physical buttons and we're good
[23:18:56 CET] <pos> agreed
[23:20:00 CET] <pos> i had ten minutes to kill the other day, went to a best-buy kinda store and was asking about the killer OLED. i wanted to make sure it could be used without an internet connection
[23:20:13 CET] <therage3> lol, good luck with _that_
[23:20:26 CET] <pos> turns out: it can't
[23:20:30 CET] <therage3> exactly
[23:20:36 CET] <pos> it can play media from usb: the other stuff? nope
[23:21:34 CET] <alexpigment> i'd really just appreciate if all TVs didn't come with horrible default settings
[23:21:56 CET] <alexpigment> motion smoothing off, sharpening off, overscan off, edge enhancement off, noise reduction off, etc
[23:22:15 CET] <alexpigment> (i mean i'd like all those things off, to be clear)
[23:25:21 CET] <therage3> so I just managed to downscale these 24-bit FLAC's to 16-bit WAVs successfully with what was suggested here before
[23:25:44 CET] <therage3> managed to burn a CD just fine, with CD-Text and all
[23:26:02 CET] <alexpigment> nice
[23:26:27 CET] <alexpigment> i used to have to do that for certain DVDs so they would play on XBMC
[23:26:43 CET] <therage3> i see
[23:26:44 CET] <alexpigment> they figured out 24bit support at some point later I guess
[23:27:15 CET] <alexpigment> ok guys, I'm heading out. see you all later
[23:27:20 CET] <therage3> see you
[23:57:05 CET] <spacerabbit> is there tools on windows to stream transcoded media from my nas on demand and use the GPU acceleration. (other than plex)
[00:00:00 CET] --- Fri Dec 22 2017