2007-07-23, 02:50 | Link #62 |
Certified Organic
Join Date: Dec 2005
|
what is wrong with R1 DVDs?
so after downloading Yatta! and its 25 or so zip files I have determined the program is not for me. I also found out the manual/help file has not been updated in over 3 years. I almost never use DVD as a source so I guess I'll put it off until I become a more serious encoder. TV broadcasts are broadcasted as film converted to video, so the telecline process has already been done before airing. is this true for HDTV broadcasts also? they are already in 24fps? |
2007-07-23, 03:06 | Link #63 |
King of Hosers
Join Date: Dec 2005
Age: 41
|
25 zip files?
Yatta is 1 zip file. Think of it like the GUI. If you were using a DVD as a source you would need the other zips (which I am guessing what you are referring to) anyways in order to encode the file. The only thing really required with Yatta should be FieldHint, 1 other zip. So two things required to use Yatta including itself. Of course you need a whole host of other things to actually rip and encode a DVD source, but they are unrelated to Yatta. If you didn't want to use Yatta, you would still need them. |
2007-08-23, 21:50 | Link #64 |
Certified Organic
Join Date: Dec 2005
|
i have some new raws to play with
it seems the Code E raws have been upscaled to 1280x720 which I would prefer BUT they seem to have been taken from an original Divx encode now if I downscale these to 704x400, on a typical home computer screen, will the show appear to look the same? On a 30" screen the difference will be noticeable? why would people upscale to 1280x720, this is not mod16. Is it for watching on TVs? |
2007-08-23, 22:13 | Link #65 | ||
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
Quote:
Quote:
|
||
2007-08-30, 23:46 | Link #69 |
Aegisub dev
IT Support
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 39
|
Although this can change from disc to disc, you'd usually crop 8 from left and 8 from right, leaving top and bottom unchanged, i.e. Crop(8,0,-8,0). Sometimes there are small black borders on top or bottom, in that case, also crop them (by as much as necessary), and then scale it back to 480.
After cropping, you can either scale it to 4:3 or make it anamorphic. e.g. Crop(8,0,-8,0) LanczosResize(640,480) or Crop(8,2,-8,0) LanczosResize(640,480) or Crop(8,2,-8,0) LanczosResize(704,480) or just Crop(8,0,-8,0) |
2007-08-31, 01:58 | Link #70 |
Certified Organic
Join Date: Dec 2005
|
when I cropped 8x8 in nonanomorphic, it forced the resolution to 640x496 or something like that automatically. I'll force it anomorphic to 480 and see how it comes out tonight.
I'm thinking this DVD version was redone differently from the TV version so I shouldnt expect it to look the same. It has a mini-widescreen look. I've been meaning to play with the LanczosResize templates, though. Another thing I learned today is there is something called Hybrid interlacing. Someone is trying to shoot me in the foot. |
2007-10-14, 15:26 | Link #71 |
Join Date: Feb 2006
|
Another thing Eclipse does right
I used to just download the XviD releases from Eclipse (which are still more popular, going by seed/peer counts), but have recently switched to their h264 encodes.
I'm happy to see they group has one of the few encoders maintaining the divisible by 16 rule for h264 encodes (704x400 instead of 704x396), so they deserve a thumbs up for that Hopefully more encoders will follow suite and realize they will produce better quality by following this rule for h264 encodes, despite the *slight* aspect ratio distortion. I myself would like to encourage 768x432 as the "new" size standard for 16:9 widescreen productions. Its divisible by 8, at least, and maintains the aspect ratio perfectly. Edit: Sorry mods! Didn't realize a related thread already existed. I usually check first, but didn't this time. Last edited by Onniguru; 2007-10-15 at 18:31. Reason: Sorry, Xris, didn't know a thread like this already existed |
2007-10-14, 15:58 | Link #72 | ||
Away for good
Join Date: Mar 2006
Age: 36
|
Unless the source was a TV Station upscale or if the capper scaled it to 1280x720 (I assume)....
But I guess that their source must've been "caught" at 704x396 (720x480. TS you know what, if you do...) after cropping as resizing if you know the "drill" that is. And then their encoder resized to 704x400 due to ugly blocks, when using h264 if not dived by 16. So resizing 704x396 to 768x432 would generally be a very "bad" idea if you know why, and if you don't then it's not needed for you to be explained "why". Encodage will always be the hardest part of all staff positions, except Editing and TLing, depending on how you work (for example, you can't TL a joke directly into straight English). And changing lines for a sentence of a specific theme or meaning, depending on how well the TLor did his job, might be tricky. I guess it depends on what your show your working with, as it's been targeted for a specific age. The TSer has his "hard" job depending on if you alpha time or break lines often, scene timing and so on... Quote:
And this is cuz you'd rather want a video "capped" source in a higher resolution with a bitrate of around 1200-3600 kbps than a cap at around 720x480 or lower with a kbps of 1200-3600, to later upscale when watching on a PC. These caps were NOT meant for you with "low specc" PCs or people with a very very slow "internet connection". XviD and rar madness era belongs to the country folks that started with it, and cuz of that it spread and still exists today. And again, people who do not watch these "caps" or other "encodes" in fullscreen does not belong to these "high" resolutions. Edit: Quote:
Edit2: Some minor typos. Last edited by Shounen; 2007-10-14 at 16:39. |
||
2007-10-15, 16:48 | Link #73 | |||||
Oblivious
Fansubber
Join Date: Jul 2007
|
Quote:
Quote:
Quote:
Quote:
Quote:
Last edited by Skyward; 2007-10-15 at 17:22. |
|||||
2007-10-15, 19:02 | Link #74 | |
Join Date: Feb 2006
|
Quote:
Having read this thread now, I can indeed see that 768x432 would be a very bad idea indeed, and considerably worse even than leaving it at 704x396. I've been doing LanczosResize(704,400) for my encodes because I knew stuff was supposed to be divisible by 16, although before today I did not know why ( I also now know thats called mod16, heh ). However, I had not been cropping at all ( I figured 1% distortion == acceptable). I did not know other were doing it; now I do. I'll go ahead and add the cropping in. Edit: Just wanted to add that I suspect most group's widescreen encodes are also 704x400, and just call the releases 704x396 in the file name so that the public at large wont look at it and say 'oh mah garsh, Selma, we don't want that version, it done be distorted, like' Last edited by Onniguru; 2007-10-15 at 19:16. Reason: addenda ;) |
|
2007-10-15, 19:42 | Link #75 | |
makes no files now
Join Date: May 2006
|
Quote:
That's what I usually do. Personally I find black borders a bit distracting, even when they are just 2 pixels wide, but then those can be cropped out in the decoder anyway. So I guess it comes down to personal "encoding preference" since you can go both ways.
__________________
|
|
2008-02-16, 16:28 | Link #76 |
Member
Join Date: Jul 2007
|
So Yersterday i tryed to test the advantage of 704*400 encodes over 704*396. i thought i understanded the theorie and that 704*400 whould need a smaler maximumbitrate, maybee i was wrong... So i took some of my lossless 704*400 files, and started some test 1stpasses. For the comparison@ 704*396 i used the same LL with an Avisynth script only for croping the vertical bordes 2 pixels on each side. (plz no complaining over AR, this encode will never see an 2ndpass or a release) So maybee this was the wrong way and i should have maked a new lossless with the same filters, only other croping and resizing to get to 704*396. So now the results of the Test, questions after this:
All test at the same setings (my standart Xvid setings), frome a Xvid 1stpass. MVS= maximal videostream size from xvid StatsReader. ABR= average bit rate for the 1stpass u get in vdub encodestatus at the end of the encode. Test1: 704*400: MVS: 314 Mb ABR: 1400kbps 704*396: MVS: 314Mb ABR: 1400kbs ( "The hardest to compress file" showed no difference in bitrate, i thought it would be the on i could see the most difference.) Test2: 704*400: MVS: 183MB ABR: 999kbps 704*396: MVS: 184MB ABR: 1003kbps (so ´"the easy one" shows the most differnce???) Test3: 704*400: MVS: 242mb ABR: 1318kbps 704*396: MVS: 242mb ABR: 1319kbps (wow only a 1kb diference for the average kilo byte per second so no difrrence in the rounded maximal videostream size for a 24 minutes show) So know my questions. Is ther any other advantages then comprasion, in staying mod16, maybee compresion artefacts are fewer\or less visiual if u use mod16, or the containeroverheat is smaller? Can it be my sloppy croping, spoiled the results and it would be better to make new lossless with the same filters, only other croping and resizing to get to 704*396 ? Last edited by max2k; 2008-02-16 at 17:27. |
2008-02-16, 19:49 | Link #78 |
x264 Developer
Join Date: Feb 2008
|
There is absolutely no disadvantage to using non-mod16 resolutions except that it means you need a tiny bit more bitrate to store the extra rows. As an example, if you're encoding 800x596, that will take the same amount of bitrate as 800x600. As you can see, the difference is absolutely negligable--and nobody cares.
The way x264 handles mod16 is by "mirroring" the rows of pixels over the edge of the frame to fill the mod16 boundary. This avoids introducing compression artifacts and such that other methods prior sometimes did. If a hardware player "didn't support non-mod16", it couldn't play 1080p , because 1920x1080 isn't mod16 either. "Supporting non-mod16" actually means "supporting post-decoding cropping," because all streams as encoded at mod16 no matter what because of the mirroring/padding I described earlier. |
2008-02-17, 02:29 | Link #79 |
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
I can attest with certainty that during my compatibility tests about mod16 2-3 years ago, there were several instances where 704x396 occasionally caused problems: VSfilter had some issues, some "standalone" media players (that was before CCCP had become the quasi-standard), and there were also credible reports from standalone player issues which I couldn't verify myself for obvious reasons.
Basically, in my opinion it's simply _stupid_ to risk incompatibilities for 4 friggen pixels. After all, you sometimes have to crop raws anyways, so this minimal change is completely unnoticeable. The slight bitrate losses are just the icing on the cake. There is NO reason to take this risk unnecessarily. |
|
|