XBMC4Xbox

Dan Dar3 wrote:The problem is not the picture size, but highly compressed bitrate (amount of data for a frame) with large picture size. Encode Xvid or MP4 with lower bitrates and you can achieve the same large image size.

MPEG2 - more data to read (disk, network etc), but easier to decode (less CPU + memory).

Actually a closer look at the screenshot gives an impression of lots of encoding artefacts.
...which is exactly what I'd expect of MPEG2 Pt2, H.262 (i.e. the almost-20yo standard for DVD and StdDef DVB) encoded at 1280x720 (i.e. 720p) with a bit rate of ~100kbps.
I'd be amazed if the moving images looked anything other than unacceptably poor on a big telly.

It's all about trying with what suits each and every one, not one movie encodes the same and everyone has a different setup.

I have a 32" LCD screen and I look at it from 3-4 meters away so I encode 640x360 MP4/AAC double pass, it looks good to me XBMC4Xbox upscaled to 720p (I'm all for quality but once it's a good enough level I like to focus on content). Same might be sufficient for a someone with a kick ass large TV they want to watch from accross the room and see the hairs in the actor's nose, I don't know

I think light flashes or high moving scenes are hard to encode properly without artefacts unless you put a lot of data into it, that's where I guess variable bitrate or double pass could help. Problem with variable bitrate is that at times it could be so high that the CPU will choke and may lose frames at playback. In fact that could be a playback artifact as well, I remember trying some filter settings and to me it looked to produce those artifacts instead of say dropping frames (referring to XBMC4Xbox, playing the same scenes a few times with different filter settings, but I guess my visual comparison was subjective, but just a thought).

Dan Dar3 wrote:I think light flashes or high moving scenes are hard to encode properly without artifacts unless you put a lot of data into it, that's where I guess variable bitrate or double pass could help. Problem with variable bitrate is that at times it could be so high that the CPU will choke and may lose frames at playback. In fact that could be a playback artifact as well, I remember trying some filter settings and to me it looked to produce those artifacts instead of say dropping frames (referring to XBMC4Xbox, playing the same scenes a few times with different filter settings, but I guess my visual comparison was subjective, but just a thought).

Right, like the H.264 skip loop filter. Agree.

But can we please spell artefacts correctly, for our side of the Atlantic.

I can forgive Dan for that. English is his second language and it's a alot better than mine in some cases !

ar·ti·fact also ar·te·fact (ärt-fkt)
n.
1. An object produced or shaped by human craft, especially a tool, weapon, or ornament of archaeological or historical interest.
2. Something viewed as a product of human conception or agency rather than an inherent element: "The very act of looking at a naked model was an artifact of male supremacy" (Philip Weiss).
3. A structure or feature not normally present but visible as a result of an external agent or action, such as one seen in a microscopic specimen after fixation, or in an image produced by radiology or electrocardiography.
4. An inaccurate observation, effect, or result, especially one resulting from the technology used in scientific investigation or from experimental error: The apparent pattern in the data was an artifact of the collection method.

seems the dictionary is more forgiving than you.. well not to worry. I shall punish ye spicemuseum at next bug report!

Thanks for the more in-depth explanations about the codecs and containers, been a little while since I fussed with any of it but the whole concept is not too hard to understand.

I found the article BuZz posted Here on the development history of ffmpeg to be extremely interesting and I do recommend anyone to give it a read, In short the way I understand it the original developers got locked out of the project and it was hijacked and forked with the same name, and you might find it interesting to know that the version of ffmpeg that ships with many linux distros like ubuntu actually have this forked version that is not as robust and might handle the command parameters differently or in my case gave me a very poor "blocky" output file.

Solution: Remove these "inferior" libav versions that came with my ubuntu 12.04 and and compile and install the "True" ffmpeg packages from source, in fact this "true" version is the same ffmpeg source that is used to compile ffmpeg in xbmc4xbox (according to a very strange man from the U.K. )

The Commands:

1)Remove the existing packages
2)Get the dependencies Installation:

x264 - H.264 video encoder (not necessary but may be useful for other packages that might depend on it)
Enter the following to fetch the source, compile and install the x264 package *TIP* - You can reduce the time it takes to compile code by splitting the job across multiple processor threads with the -j command flag, so if you have a dual core cpu you might want to use the "make -j 4" command instead of just "make", I used "make -j 8" myself on all of the make commands with a dual core cpu without problems, you can adjust this parameter to whatever you feel is necessary. Thank buZz for pointing this out too

fdk-aac - AAC audio encoder - (again not completely necessary but it may be required for other packages that depend on it) libvpx - VP8 video encoder and decoder ( again not completely necessary but it may be required for other packages that depend on it)
FFmpeg - The Meat&Potatoes
Finnish ffmpeg is now ready for use and the command that BuZz posted earlier to re-encode 1080p videos (or any size/format videos) into 720p mkv files will work correctly any give nice crisp output files that in my case got reduced to half the file size in MB and guaranteed to playback on xbmc4xbox without dropping frames, you might see slight artifacts on very rare occasions but it wont drop frames

Here is that command again

BuZz wrote:I can forgive Dan for that. English is his second language and it's a alot better than mine in some cases !

Guys guys, thanks Buzz, appreciated, get him good now, back to the thread...

Dan Dar3 wrote:Problem with variable bitrate is that at times it could be so high that the CPU will choke and may lose frames at playback.

Most (all?) encoders will let you specify minimum and maximum bitrates when encoding with VBR to get around this problem.

@AZImmortal
I don't want to go into a debate what's allowed where, I just wanted to mention one of the problems around variable / average bitrate, and along the same note what values would you need to choose for min / max as well. One example, HandBrake only allows you to set an average bitrate through the interface (but who uses that), maybe it's possible to do that through advanced parameters, I don't know.

I don't even know why I even posted on this thread, it seems I'm only pointing to potential problems that people people may not even have

Dan Dar3 wrote:@AZImmortal
I don't want to go into a debate what's allowed where, I just wanted to mention one of the problems around variable / average bitrate, and along the same note what values would you need to choose for min / max as well. One example, HandBrake only allows you to set an average bitrate through the interface (but who uses that), maybe it's possible to do that through advanced parameters, I don't know.

I don't even know why I even posted on this thread, it seems I'm only pointing to potential problems that people people may not even have

Ah, gotcha. In my head I was only thinking about command line encoders where it would be easy to specify min/max bitrates. I didn't think about frontends/GUIs that might not have such options. I just wanted to make the suggestion in case you were having problems with dropping frames.