Trouble logging in?We were forced to invalidate all account passwords. You will have to reset your password to login. If you have trouble resetting your password, please send us a message with as much helpful information as possible, such as your username and any email addresses you may have used to register. Whatever you do, please do not create a new account. That is not the right solution, and it is against our forum rules to own multiple accounts.

Laga supports yv12, huffyuv doesn't - but I did hear there was some "hack" or "otehr development" of huffyuv which does?

Anyhow, I'm not even sure lagarith supports yv12, I've had some funny experience with it like this:

I have a laga file which is yv12, right? I mux it into mkv with mkvtoolnix(yes, the 7gb file - don't ask) - I then check it and it's not YV12! A friend explained it somehow to me that lagarith reverses it on playbeack or I don't remember what - so anyway... I have much misinformation which I can offer .

Oh, I see, there's some ffdshow huffyuv-yv12 thingy... I'll look it up... As for now - I prefer to stay with Lagarith... Atleast untill I find articles which would show me why I'd want to switch to huffyuv...

As to mp4, what's better in mp4 then in mkv? I'm used to mkv... mp4 feels... "new and untried" sort of...

With regard MP4 vs MKV; it's as they say "Six of one, half a dozen of the other" (to use the term loosley). MP4's main selling points are that it's a recognised industry standard (and an MPEG one at that), so that means you get commercial companies including it in software and hardware. Unfortunately because MKV is not an industry, people are reluctant to support it (except of course in open source circles); so you have a bit of a contrast there.

With MKV, it's gained popularity in the fansub scene due to it's matured softsub formats, which as you know are very flexible. Also in contrast, MP4's softsubs are relatively simple (yet they do have features such as karaoke, displaying the subs on picture for windowed playback or in letterbox when in fullscreen, clickable web links, and of course colours, fonts and positioning/scrolling). Yet this is most likely because the 3GP Timed Text format was originally designed for portable devices with low CPU power, and so not making it as flexible as ASS means they can somewhat ensure the CPU requirements don't get crazy.

I use MP4, one because I want to try and support the industry and show that there is a call for stuff like this, and good hardware and software support, and also a lot of times I don't require subs at all (most of the encoding I do these days is for personal stuff where I don't need subs). Odd times I have encoded for groups, they have used softsubs, so MP4 also fitted my requirements. If 3GP timed text support was at the same level as ASS, I would probably suggest or use it, but a lot of groups are still uptight about having their scripts stolen (insert argument about morals and stealing what isn't legally yours ).

You basically use what fits your needs; in effect MKV is the new replacement for AVI and MP4 is the replacement for MPG (however MP4 is an open standard, so expect it to be more useful than MPG, meaning that when H.265 (or whatever it ends up being called) arrives, you will probably be storing it in MP4 rather than a new MPEG container.

Quote:

Originally Posted by emptyeighty

mp4 and mkv are both pretty much on par when it comes to features. mkv has softsubs, which mp4 doesn't have (yet). mkv also supports vorbis audio by spec. There's also chapters and linked chapters in mkv. mp4 will probably have more hardware players supporting it. Other than that they both store perfectly spec compliant MPEG streams and are generally very good a/v containers.

MP4 has had softsubs since at the very latest, October 2005 (when VLC started supporting it and Gabest picked up on it). It was actually approved in 2004. However, with the supporting being poor at the moment, it might as well not have softsubs since no one uses them because of the fact that there isn't a reliable implementation (except perhaps in Osmo4, which again no one uses).

The reason being that people would rather work on the existing softsub formats than start work on another from scratch (which I can totally appreciate), it's just a little unfortunate.

Quote:

Originally Posted by martino

If you don't plan on using softsubs and Vorbis audio, then I personally think that MP4 would be a better choice, since if you put in h264 video with AAC audio then the chance of people being able to play it on the XBOX360/PS3 (and some more hardware players in the future too) will be much higher. Also, I think that I myself found MP4 to seek slightly faster, but I don't have anything to base this on...

EDIT: Beat by emptyeighty...

Yeah, I don't object to using MKV, it was handy for dealing with TS dumps a while ago, but my personal preference is to use MP4 when you don't need any features that require MKV. In other words, I would rather put a simple H.264 + AAC stream in MP4, than MKV for using MKV's sake (I don't see the sense in putting it in another container when the specified industry standard one does the exact same job). To me that would make as much sense as putting MPEG-2 in AVI rather than MPG.

As you said, it can work out better for cross platform compatability, but if people want to use MKV, who am I to tell them what to do?

Quote:

Originally Posted by martino

MP4 supports softsubs, in the TTXT format (read more here). Basically it can be described as XML madness. And to get a TTXT softsub you need to go from ASS/SSA (where applicable) -> SRT -> TTXT (through mp4box, or some other program if it exists...). And then you can mux it into an MP4 file, however you will only be able to see the subs if you use a splitter like Haali (AFAIK, not sure about the rest). It doesn't work with the XBOX360, as expected, and the PS3 and rest are most likely the same.

And there are no tools AFAIK for editing TTXT subs, apart from using a text editor. >_>

Ending Note: It's a rather messy format.

Yeah, the XML madness though, is only because it's easy to parse. If you wanted to you could make TTXT exactly like ASS (format wise), as long as you added support for the format in MP4Box. The actual file that gets muxed isn't like that, it's just an input format that's easy for MP4Box to read.

Again with 360 and PS3 not supporting 3GP Timed Text, that's hardly surprising when you consider the 360 supports 2.0 AAC but not 5.1 AAC, and also the PS3 supports High Profile H.264 muxed in M2TS and only Main Profile in MP4. Console MP4 support is almost as much of a mess as iTunes. Coincidentally, the KiSS 1600 supports 5.1 AAC, so at least there is one device on the right lines.

Again if software timed text support got to a good level, people might want to try it (I've had a number of people ask me about MP4 softsubs, and I've told them hardsub or MKV), and once files are out there with these subs, companies will see that there is a requirement for them and eventually implement it. It's a vicious cycle. People won't use it because the software support is poor, and the software support is poor because no one uses it.

Messy format yes, but there's nothing wrong with using SRT and converting when you are done and then just formatting the TTXT (positioning and stuff), or using a text editor like Notepad++ which makes it a little more bearable.

Quote:

Originally Posted by jfs

I've added TTXT import/export to the todo-list for Aegisub, but that doesn't mean it'll be done any time soon...

Some things I can see is in ASS but not in TTXT: Specifying the border, shadows, arbitrarily rotated text, text scaling, advanced animations and yes, drawings. I'm not sure TTXT/MPEG-4 provides a method for attaching random fonts to the media, meaning you'll have to rely on the fonts installed on the playback system.

Thanks for the great explanation... I don't really use soft subs... Nor do I really know why people would want to(well, ok, I suppose coz' you can make it biger/smaller? I dunno) - I figure, the op/ed kara need to be hardsubbed anyway(many of them are super CPU intensive) - so why not encode the rest as well? It doesn't offer extra "hardships" (ok ok, so VFR might affect this at times) - so...

I just use .mkv because to me, it seems to be the most "tool-rich" and easiest...

That's a REALLY bad example being that MKV was MADE to handle the formats you put in it, but AVI was NOT made to handle MPEG-2...

Yes, not the best example; all I was getting at was using an alternative container vs the specified/standard container seems pointless to me when there is no reason for doing so (and so limiting interoperability a bit for no other gain, as opposed to limiting interoperability a bit in return for nice softsubs).

Oh, I see, there's some ffdshow huffyuv-yv12 thingy... I'll look it up... As for now - I prefer to stay with Lagarith... Atleast untill I find articles which would show me why I'd want to switch to huffyuv...

If you're encoding a filterpass to lossless for speed reasons, it makes no sense whatsoever to use Lagarith. Pretty much the only point Lagarith has over huffyuv is better compression, which is nonsense since noone uses lossless for actually storing video for any longer period of time, and if you actually WANTED good compression, there are much better alternatives (FFV1 and H.264 q0 come to mind).

Use ffdshow's YV12 Huffyuv, predict plane. It's very very fast, it compresses pretty good (about 4 GB/ep) and it doesn't require a colorspace conversion like the original Huffyuv. There are some people who prefer Lagarith for compression of RGB32 AFX signs, since you have to upload those to a FTP. But not even there is Lagarith the best alternative; you'd be surprised at how well 7zip compresses 32-bit uncompressed AVI's...

__________________

| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read

Meow! Didn't know that , but, I was recommended not to touch the ffdshow's huffyuv - that's my main reason for not touching it - basically, once I read up more on it I'll decide to move then, for now I prefer to stick to the bits that I do know a bit about... But thanks .

Take that how you will. I don't know anything about part 18, but it suggests it's probably attaching fonts to MP4 and using them in playback.

I did look at the TTXT specs at one point, and as far as I understood the subtitles are stored in a binary bitstream format, not even very reminiscent of XML. The XML representation is an invention by the GPAC people to make TTXT editable.
The goal of a TTXT export filter would probably be to export to the XML format.

As for the font embedding, that sounds good Any software support for it yet?

Meow! Didn't know that , but, I was recommended not to touch the ffdshow's huffyuv - that's my main reason for not touching it - basically, once I read up more on it I'll decide to move then, for now I prefer to stick to the bits that I do know a bit about... But thanks .

What would the reason behind that be? I have found it to be about 30-40% faster than LAGS, and not had a single trouble with it so far.

__________________

"Light and shadow don't battle each other, because they're two sides of the same coin"

What would the reason behind that be? I have found it to be about 30-40% faster than LAGS, and not had a single trouble with it so far.

As far as I remmeber - the reason which was given is taht it's development was by some noobs. But it was back like 2-3 months ago, when I trusted more and researched less...

Anyway, I will definetly research this thingy... It just was never a priority - but 30-40% speeds gain? That's something which could save me A LOT of time (my group is doing hellsing OVA atm, meaning ~45 minutes episodes... And soon an OVA which might be longer... So...).

Its from the VfW end of ffdshow. So if you have CCCP (you already have it), or just get the latest tryouts build. The code itself is probably rather old because there has been absolutely nothing to update. The codec has been juiced to hell before it got YV12 support from pengvado, so there wasn't much new work to do I assume. Or no one figured out how to squeeze even more speed out of it.

It not only encodes much faster (it is as far as I know still the fastest lossles encoder) but also decodes extremely fast. So even when you are using that intermediate lossless pass you are not slowed down simply in the decoding phase (though Lags isn't that slow there). Double win. In terms of speed/compression ffvh and lags are the top 2 in my opinion. I've always just tended to use ffvh though for the speed factor. Also I did do all my testing...lol at least 2 or more years ago. Lags might have gotten faster but I haven't seen any mentions of speed in the changelog just bugs.

The only other viable options are VBLE (ancient yv12 lossless codec made in a day...lulz), CorePNG (equally ancient and pretty slow), and FFV1. FFV1 has no rewarding attributes in terms of speed (both encoding/decoding are really slow) but so far it is the best in terms of compression. Its not all i-frames, zomg! Also of course there is lossless H.264, but I've never gotten around to see how well it does. I'd estimate on par with FFV1 and probably equally slow...so not much rewarding there unless you are someone with little filespace.

LAGA vs Huffyuv vs Else? Meow... What options should I put there? Which other loseless codecses are popular? A dude I know uses MSU(or something with M and U)... Hmmm...

Yes...popular opinion polls of course make the most sense from an encoder's perspective. Because we all know popular opinion makes an encoder faster/better/stronger/harder. lulz. Lets just forget the whole testing theory and ask people which encoder they feel is best. Decide with your heart!

Hmmmm, I dunno - I don't really care about compressibility - I have plenty HDD space... so be it 4gb, 10gb or 20gb, it makes little difference to me...

As to speed... Here's the thing, the 1st pass(loseless laga) usually is either very short (IVTC+crop+resize+pre-ivtc filtering) and takes like 2 horus, or is very long (actual filtering) and takes like 8-12 hours... If it's short, I put it on even lower and it doesn't really bother me, if it's long, I put it for when I am asleep .

And now that I have a 2nd computer, phewww...

The above 2 reasons were anti-moveing-away-from-lagarith(plus, I was tld against huffyuv yv12, and all that but don' matter that now)... But I suppose with the amounting testimonials from you guys, I'll give it a few trys... My translator will show up any day now to start work on Claymore - so I'll make a few comparisons there with huffyuv/laga...

Plus, Lagarith sounds so much cooler then "huffyuv" - I mean dood - Lagarith is like LAGARITH! It's like teh powerfull...

>.>
...
<.<

Anyway people, please suggest loseless codecses which other people use(yes yes, I know there's a wiki about loseless codecses, but it's pointless to include those which none uses anyway).

I listed most of the others I know of up there. I did forget about MSU since it is proprietary weirdness. I forgot why I totally gave up on testing it. I think the reason was that although it does compress natively to YV12 the decoder did not support YV12 output. So that was like....totally useless and I had no idea wtf was going on or the purpose of not outputting the internal colorspace used. Or maybe that was another codec...I do recall something did that at least. So that would be extremely useless as an intermediate lossless step if you got YUY2 out.

In summary, finding out what other people use won't take you far unless you are just learning to encode. You'll find many people will say "zomg use this" but when tested it verifably makes no sense or no difference. Such as if someone were to say "use Lagarith" well now you at least know what to use. But why use it specifically? Is there a reason even? Or just because said person doesn't know any other alternatives? With something like YV12 lossless codecs you can easily test them on a number of properties. Encoding speed, decoding speed, and compression. Which you can then reason for yourself which properties are most important to you and use them... popular opinion isn't going to tell you this though. And most likely popular opinion sometimes has little thought/reasoning behind it. So there is always testing yourself, or finding someone else's results from testing with which the results are still valid.