Wikipedia:Reference desk/Archives/Computing/2017 June 5
| Computing desk | ||
|---|---|---|
| < June 4 | << May | June | Jul >> | June 6 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
June 5
[edit]File Formats
[edit]I just converted a “.flv” into “.mp4” using “YTD” in “ipad”, “iphone” and ”PSP Video H.264” conversion versions, the latter seem to give me the least (from a 33MB to 123MB).
Question is, is “.flv” the best of or is there something else? - Because, “.flv” doesn't work on the smart phone without a special software...
43.245.123.33 (talk) 17:58, 5 June 2017 (UTC)
- .flv is a Flash video format. Given the recent loss of market share Flash is experiencing (thanks in no small part to HTML5), I would not recommend it for use in anything but a dedicated flash application (including web apps, naturally). Interesting it is, or was (I'm not sure if they changed) the format of YouTube videos. Mp4's compression are more common and the licensing on it is less restrictive (it's free for streaming which, in turn is free to the end user) than that used by .flv files. So I would suggest mp4's as the preferable format. That being said, I would also go one step further and recommend .mkv as a preferred file format: It uses an open source container format, and itself is maintained by a company that has a broad footprint and little signs of losing market share. It is technically better in that it produces fewer compression artifacts, and pragmatically better in that, being based on an open source container format, it is likely to outlive either of the other two. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 21:32, 5 June 2017 (UTC)
Don't understand what you mean by "technically better in that it produces fewer compression artifacts". Both MP4 and mkv are containers. (So for that matter is FLV, or F4V which are often given the extension FLV anyway.) You linked to the DivX Plus HD for .mkv, but a mkv can contain any number of different video compression formats. MP4, is more complicated, you may legitimately question whether private streams or non registered video codecs are a proper use of the container. Still even if you restrict usage to registered codecs, there is still a large variety.
More importantly perhaps, by and large both are most commonly used for h.264 (and actually most modern FLV too) . There may be some advantages to putting the video stream in mkv, but if it's the same video stream there are no fewer or more compression artifacts whether the stream is in mkv, MP4, FLV/F4V or raw unless there is some seriously wrong with your playback device. The same if the audio is AAC and again for mkv and MP4. (FLV is perhaps more complicated when it comes to audio as MP3 isn't uncommon. I think the same for F4V)
The source encoder does matter. Since you linked to DivX Plus HD, I'm not sure if you intended to suggest it as the encoder. But if you did, this is still poor advice from a quality standpoint. x264 is generally regarded as giving the best quality encodes for most resonable time frames. It's used by many including last I heard, Google for YouTube.
Encoding settings also matter, and I believe DivX Plus HD does set some more stringent requirements than some others, however what matters than is the encoding settings (bit rate etc). Saying something is in the MP4 container or FLV container doesn't tell you what encoding settings were used. It may be the settings were less than that allowed by DivX Plus HD, but that's a distinct point. And anyway, that only applies if you refer to DivX Plus HD rather than the mkv container.
Of course the other important reminder is unless you need to re-encode for some reason like playback issues, there is no quality advantage to transcoding to another format. I mean if you do extensive pre-processing, then maybe there is an advantage to that, and you'll need to consider what to save after that processing, but that's a different point. (Likewise if you do need to transcode for compatibility reasons.)
Nil Einne (talk) 14:23, 6 June 2017 (UTC)
- Yes, but the container formats all have a dominant format for video and audio encoding. In this case, my comments were in reference to the most dominant encodings for those two containers. 9 times out of ten, when someone produces an .mkv file for example, it is a DivX Plus HD file, meaning it is MPEG-4 AVC encoded video with AAC encoded audio. I don't see the point in disambiguating here, as the vast majority of playback and editing software will support every common encoding of a container if they support that container, and the defaults will be for the formats I described. We are, after all, volunteering here to answer questions, not to create new questions. I think it is preferable to give the OP an answer to their question than to launch into an in-depth explanation of how multimedia data is digitally stored and compressed which the OP may not have the slightest interest in. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:06, 8 June 2017 (UTC)
Bullcrap. The vast majority of mkv are H.264 encoded with x264. Very few people who know what they are doing use DivX Plus HD. This is of course a good thing, since x264 is far superior for DivX Plus HD. Heck not all MKVs even meet the requirements for DivX Plus HD. (Not necessarily a good thing, but it depends on the target audience etc.) Most of the rest of MKVs are content which was encoded by some commercial source (streaming or download sources like Amazon, Netflix, iTunes, BluRay etc) with a probably unknown encoder, although as I said x264 is fairly commonly used commercially but I suspect Apple at least uses neither (I'm assuming they do transcode internally for iTunes files rather than keeping compliant files as it, but I don't really know); and then remuxed into an MKV. Probably the most common alternative codec for H.264 to these is Intel or Nvidia's hardware one, with AMD trailing badly but still coming before DivX Plus HD in usage share. To be fair, I'm fairly sure DivX Plus HD is better than these, but it doesn't change the fact it's not commonly used.
Further as I already said, it is also the case for MP4 and for FLV (particularly if it's really as it probably is F4V) that H.264 (coming from whatever encoder) predominates. The audio as I've already as it a bit more complicated. Thinking a bit more, my original answer wasn't totally correct, AAC isn't as common as you suggest or I also inadvertedly implied. Many MKVs have AC3 or sometimes DTS, again this is audio originating from the source. AAC would be better even for multi channel but audio systems don't necessarily support decoding AAC and people get silly about audio even going as far as to pointless use LPCM. Anyway the main point is it isn't uncommon these audio streams are preserved rather than transcoded and so the MKV doesn't have AAC. (From an audio quality standpoint it obviously doesn't matter, in fact sicne the audio hasn't be transcoded it is technically superior. Still it is mostly wasted bitrate and it's far more likely someone will notice the difference by using those bits for the video instead of the audio.)
Yet you specifically claimed that mkv had fewer compression artifacts which clearly makes no sense when all 3 generally have the same video codec and I think it's clear you're not thinking of audio compression. (Incidently I suspect MP4s have AAC more commonly than mkv although as I already acknowledged FLV is a little more complicated when it comes to audio some still do have MP3.)
Also this is irrelevant to the OP when they are transcoding or encoding the content themselves. Whatever others store inside their MP4s or MKV or whatever, it is not going to make their MKVs better quality if they store VP9. Nor are they going to have worse quality because they used x264 codec (instead of the crappy DivX Plus HD) but stored the output in MP4 instead of MKV. In fact if they did use DivX Plus HD as you linked to them, depending of course on quality settings especially bitrate, it's likely they would have ended up with worse quality despite sticking it in MKV than if they had used x264 no matter that they stick it in MP4 or FLV. (Not that I'm saying they should stick it in either, the point is there's a reason why it's important to distinguiush between container format and video codec.)
In other words, your advice wasn't just wrong, it was useless. There's a difference between simplifying things, and speaking bull crap, and you did the later as nearly all of what you said was misleading or just plain wrong. And yes, when someone answers a question but a big chunk of their answer is basically completely wrong, it's fair to point this out. It's good to volunteer to help but if you are wrong you should still expect to be called out on it.
Nil Einne (talk) 12:57, 9 June 2017 (UTC)
- P.S. In case there's still some confusion, here's some far better advice than your largely wrong one. MKV is arguably the best container format to use but it's not going to give better video compression or fewer compression artiftifacts. That would common from choosing the best video codec. This would often be H.264 using the x264 implementation, generally not DivX Plus HD. HEVC may be the best bet in the future, the licencing controversy seems to have died down a bit, and x265 is starting to get to the stage where it's getting close to at least matching x264 at many bitrates. AAC would also often be the best audio codec, Opus is technically superior but not many use it and compatibility may be a bit hit and miss so I'm reluctant to recommend it. However for many uses, chosing MP4 or even FLV or more likely F4V as the container, isn't really going to be that much of a disadvantage. And for better or worse, since this whole problem arose because of compatibility with crappy players (as I said below), you're probably going to have less compatibility problems by storing the H.264 (preferably from X264) in MP4 than storing it in MKV. (For example, as far as I can tell, the default iOS video player doesn't support MKV. Unsuprisingly it does support MP4 including with H.264. Android nowadays does tend to at least partially support MKV given that WebM is a subset of MKV and Google's push to it. They also support MP4 at least when it has H.264 and AAC as with nearly everyone nowadays.) Although I really think the best solution is just to avoid crappy players. If the problem is solely related to container compatibility, you can of course simply remux into a different container rather than transcoding for now quality loss or size gain/loss although I'd repeat you're probably better of avoiding crappy players. Note if you do choose MKV, there's probably little point using the DivX Plus HD specific extensions, few others do so. Nil Einne (talk) 13:11, 9 June 2017 (UTC)
- Wow. Butthurt much? I stand by everything I said and am not even going to bother reading the crap you wrote past the first sentence. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:46, 9 June 2017 (UTC)
Long time later but I'm not 'butthurt', I just hate people talking bullcrap on the RD. You can standby what you said, it doesn't mean it's not bullcrap. You can't demonstrate it's not bullcrap because as I've amply demonstrated it is bullcrap hence why you can't provide any sources showing it isn't. If you don't want people to call you out for your bullcrap, don't talk bull crap, especially not on the RD.
You can't explain what else is normally in a FLV since as I mentioned, if it's a modern video file (say 5 years or so), if it's FLV (or more likely F4V named FLV) 9/10 it is going to be H264 (albeit with audio codec less clear) although precisely what was used to encode it will be less clear. Actually I forgot to mention but these is a good reason to avoid FLV and it's not because of the codec but because it's probably a lower bitrate. (But still, if you have a 1GB FLV and 1GB MP4 or MKV, this obviously isn't the reason.) And you can't explain what you'll normally find in a MP4. Since as I also mentioned if you take a MP4, maybe 999/1000 it's going to likewise be a H264 and this time probably AAC (I wonder if it's actually maybe more likely than DTS or AC3 than for an MKV.) You can't even explain why you talked about a codec, DivX Plus HD that almost no one uses. Very simple questions which are raised by your responses which you can't explain.
And as said, there's at least one good reason why non one uses DivX Plus HD, since it's inferior to the FLOSS (or optionally commercial/proprietary) alternative x264 which many others, including from what I've read companies like Youtube, Amazon, Netflix [1] and probably Hulu etc. (Not sure about iTunes/Apple.) This incidentally further explains why your comment is highly flawed, since often those companies are using basically DRMed MP4 for their streaming (albeit served with MPEG-DASH or perhaps HLS) with whatever profile they've chosen for compatibility and bandwidth reasons. So yes these are basically MP4s and would generally be better quality than some crap actually encoded with DivX Plus HD, especially since they have a very high quality source and actually know what they're doing. Neither of which I would trust to be true for someone using DivX Plus HD. (Of course actually getting a singular non DRM encumbered MP4 from these sites can be rather difficult. Well except Youtube.)
If you're talking about questionable legality/copyvio files, these are MKV but often taken, as I mentioned, from various sources. Some are webdls, meaning they were encoded with whatever the vendor used, hopefully x264. Some, BluRay rips for example, are re-encoded although nearly always with x264. (Actually I strongly suspect scene rules say x264 must be used e.g. [//scenerules.org/t.html?id=2012_SDTVx264r.nfo.) There is sometimes mention of profiles or PS3 compatibility or whatever, but I don't think I've ever heard of DivX Plus HD before although as my comments may make obvious, I have read quite a bit about these types of files for various reasons. Actually I'm not sure if I even heard of it before you mentioned it and if I did, I definitely did not remember it and I forgot it again after this silly nonsense until I read it again here. This is because, as I mentioned, almost no one uses it. I guess some of the obscure legal content might, but that's about it. (I mean seriously, a simply Google search only found Blender's Durian project and I'm not even sure they actually encoded with DivX Plus HD given their goals, or if it was instead simply a compatibility tag.) DivX sure although this was quickly overtaken by Xvid and other less questionable MPEG-4 ASP codecs, still it at least had some market share. DivX Plus HD probably did help get some of the hardware players to support some standard that they could advertise. Although by now many of them are going beyond that level of support since they know that many of their uses are using copyvio downloads and just want them to be happy.
If you look hard enough, you can get stuff like 10 bit x264 encoded files which given the same bandwidth is probably better quality than the 8 bit ones, but with poor compatibility. These are much more common by far in the anime space from what I've heard. And again, far superior and far easier to find than some crap actually encoded with DivX Plus HD.
I mean can you even find 100 files, not coming from DivX Plus HD or intended as a sample which was actually encoded with DivX Plus HD? It's trivial to find probably 100k+ files which are MKV and encoded with x264. Just check out any torrent site which serves copyvio videos. Or usenet. Or some website linking to download sites. Note as I also mentioned, if you really want to produce DivX Plus HD files, it would make more sense to use x264 to produce them, although as I also mentioned, I don't think I've ever actually heard of someone talk about compliance with their standard.
- Wow. Butthurt much? I stand by everything I said and am not even going to bother reading the crap you wrote past the first sentence. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:46, 9 June 2017 (UTC)
- P.S. In case there's still some confusion, here's some far better advice than your largely wrong one. MKV is arguably the best container format to use but it's not going to give better video compression or fewer compression artiftifacts. That would common from choosing the best video codec. This would often be H.264 using the x264 implementation, generally not DivX Plus HD. HEVC may be the best bet in the future, the licencing controversy seems to have died down a bit, and x265 is starting to get to the stage where it's getting close to at least matching x264 at many bitrates. AAC would also often be the best audio codec, Opus is technically superior but not many use it and compatibility may be a bit hit and miss so I'm reluctant to recommend it. However for many uses, chosing MP4 or even FLV or more likely F4V as the container, isn't really going to be that much of a disadvantage. And for better or worse, since this whole problem arose because of compatibility with crappy players (as I said below), you're probably going to have less compatibility problems by storing the H.264 (preferably from X264) in MP4 than storing it in MKV. (For example, as far as I can tell, the default iOS video player doesn't support MKV. Unsuprisingly it does support MP4 including with H.264. Android nowadays does tend to at least partially support MKV given that WebM is a subset of MKV and Google's push to it. They also support MP4 at least when it has H.264 and AAC as with nearly everyone nowadays.) Although I really think the best solution is just to avoid crappy players. If the problem is solely related to container compatibility, you can of course simply remux into a different container rather than transcoding for now quality loss or size gain/loss although I'd repeat you're probably better of avoiding crappy players. Note if you do choose MKV, there's probably little point using the DivX Plus HD specific extensions, few others do so. Nil Einne (talk) 13:11, 9 June 2017 (UTC)
- Yes, but the container formats all have a dominant format for video and audio encoding. In this case, my comments were in reference to the most dominant encodings for those two containers. 9 times out of ten, when someone produces an .mkv file for example, it is a DivX Plus HD file, meaning it is MPEG-4 AVC encoded video with AAC encoded audio. I don't see the point in disambiguating here, as the vast majority of playback and editing software will support every common encoding of a container if they support that container, and the defaults will be for the formats I described. We are, after all, volunteering here to answer questions, not to create new questions. I think it is preferable to give the OP an answer to their question than to launch into an in-depth explanation of how multimedia data is digitally stored and compressed which the OP may not have the slightest interest in. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 13:06, 8 June 2017 (UTC)
- You usually don't need special software to playback FLV on phones. Any half decent video player should be able to do it. If your video player can't it's probably junk, the software that can do it are just normal players not special. If the FLV actually contains h.264 as is often the case, than you should also get hardware decompression. Still if you really want to use a shitty player on your phone and it is FLV with h.264, it will be better to simply change container probably to MP4. There is no need to transcode. This will mean the quality will not change nor will the size (by much). Of course if you don't actually notice the difference between the FLV and whatever you transcode it to, then there's no real harm for yourself in doing so. Nil Einne (talk) 14:29, 6 June 2017 (UTC)
Correcting author name in a few hundred pages (references)
[edit]Hi, I am wondering if someone knows an easy and fast way (a bot?) to correct Paulin Martin's name in the bblg footnotes of literally hundreds of articles (https://wiki.riteme.site/wiki/Special:WhatLinksHere/Paulin_Martin) where it is erroneously spelled Jean-Pierre-Paul Martin? The most simple way would be to change it to the form it has on books i.e Jean P.P. Martin or even more simply J.P.P. Martin.[D 1] Thanks. darthbunk pakt dunft 20:58, 5 June 2017 (UTC)
- I would check to make sure that the incorrect spelling wasn't the attributed name from the publisher. If it was, then correcting it would introduce an error, making it more difficult to locate the sources. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 21:06, 5 June 2017 (UTC)
- WP:AWB. 14.2.224.5 (talk) 01:21, 6 June 2017 (UTC)
- Moved this thread to Village Pump (technical) (where I should have asked in the first place, sorry (but everybody was helpful, thanks again))darthbunk pakt dunft 23:52, 6 June 2017 (UTC)