Odd, Vimeo works fine for me.
GH3 Panasonic GX7 vs GH3 Shootout
- Thread starter TheDingo
- Start date
Odd, Vimeo works fine for me.
nobbystylus
Well-known member
GH3 is flatter, and likely a bit more gradable. The GX7 looks to have more baked in contrasty sharpness.
Camera Expert
Well-known member
Have anyone else done comparisons of the GH3 and GX7?
Also, has it been proven that the GX7 doesn't have an AA filter?
Also, has it been proven that the GX7 doesn't have an AA filter?
Last edited:
M. Gilden
Canon DSLR Moderator
Encoding algorithms are NOT created equal, even at the same bitrate and codec.
If you were to take a video and encode it with Apple's compressor, then take the same file and use Adobe's Media Encoder, heck even throw in Sony Vegas and Handbrake into the mix, match the settings and bitrate as best you can, I think you'll STILL find that all 4 versions are ever-so-slightly different.
When it comes to Youtube vs Vimeo, while they are both H.264, the libraries and methods of encoding are proprietary to each service. Which is better can be debated, however saying they are the same is just outright incorrect. I personally found Vimeo's image more pleasing, and found it respected the rec709 flags better than YouTube did (Youtube used to destroy my colors because it assumed the flag was set incorrectly on certain upload formats - vimeo handled it fine).
I still use Youtube for the social aspects of it, being able to reach a wider audience across more devices... but this is neither here nor there. The uploader used Youtube to distribute, and there's nothing we can do about that. TheDingo, you downloaded the 720p stream that Youtube had already compressed and should be identical to what you see streaming on their site. Downloading it using Opera's tools is the same as using Keepvid.com or any other video downloader that just captures the stream being broadcast and saves it to a file instead of playing it. Vimeo accounts allow you to download the ORIGINAL untouched and uncompressed by the service, which is something Youtube does not allow.
But enough about that- I want to see a G6 / GX7 / GH3 shootout!
Not in my experience. Vimeo sucks so bad I gave it up and went solely with YouTube. Plus, you have to pay to get 1080 with Vimeo, and it seems like most people don't. So you not only get inferior compression, but only 720 out of the original 1080.
Last edited:
M. Gilden
Canon DSLR Moderator
You are entitled to your opinion. But I think you'll find a many users here who will argue the contrary based on their own experience.
The developers at Vimeo have gone to great lengths to tweak and perfect their encoding algorithm as much as possible (as opposed to youtube's back end, which is more about speed processing, bandwidth and reaching the most users rather than highest quality encoding).
The result is that some people claim Vimeo's 720p is actually superior to Youtube even at 1080p, particularly when it comes to detail in motion such as zooms and fast pans.
If you'd like to see for yourself, this example was linked in a similar discussion a while ago:
http://blog.photoframd.com/2009/12/17/comparing-hd-video-compression-on-youtube-and-vimeo/
Resolution isn't everything when your compression is inferior. Also, I think statistically a ridiculously small fraction of users actually watch content in full HD. The average consumer household computer/laptop monitor resolution sits just shy of it, last I checked. And if someone wants to pixel peep your work at full 1080p, they are likely the same type of person who will download the original source off the vimeo link.
I don't want to see this discussion derail into another YT vs Vimeo, but there are a lot of people who prefer Vimeo to Youtube for very good reasons.
When you use a downloader plugin for youtube, you aren't getting the source video. You're getting the same video that youtube is streaming.
That's why I posted the comment "or the nearest facsimile to the source".
I still find the quality of YouTube videos MUCH better when you watch them from the downloaded video, which may be the result of better decoding from the current VLC media player that I'm using.
M. Gilden
Canon DSLR Moderator
Unlikely, decoded video shouldn't vary by player. The information that's there is there no matter how you look at it, its the quality of the ENCODER that makes a difference (ie. how information is compressed to fit within the required bitrate).
What's possible, however, is that your browser and flash plugin aren't playing nicely together. Depending on your setup, there are some experiments you can try to improve that.
Try using a few different players and you will definitely see a difference in image quality. Generally the VLC media player seems to do the best job with my Windows 7 workstation.
I was a New Media developer for 10 years and worked mainly in Director and Flash, I currently use 4 different web browsers, though most of the time I use Chrome these days. ( Opera used to be my standard, but they're now developing with the Chrome platform and haven't fully ported all of their Opera features to the new platform. Currently I'm testing the Opera 19 Developer browser right now. )
I still stand by what I stated, where I find the downloaded video files produce higher quality playback when used with the VLC media player than any of the streaming Flash browser plug-ins.
M. Gilden
Canon DSLR Moderator
I understand that you have experience with multiple browsers (and I think its funny that you keep name dropping Opera), but my background in computer science & engineering can't help calling shenanigans. The file should not look significantly different once downloaded, especially since VLC is based on the same open source libraries for h.264 playback.
Encoders are where the real difference takes place- Their job is to take the full resolution image and figure out a way to fit it within the required bitrate while following the rules of h.264. Sort of like a good accountant versus a bad one: If you bring your documents to a mediocre accountant, he will follow the rules and get you a certain amount of money back on your taxes (hopefully!). If you bring them to an excellent accountant, he will follow the same rules, but know all the tricks and loopholes to get more of a return. Both are following the guidelines of the IRS, but one does a better job and is more efficient.
A good encoder will compress more detail into the stream while still being compatible with any h.264 decoder. It shouldn't matter which decoder is used, its the encoder that makes the difference.
Now, I'm not saying every player will look 100% equal- sometimes one does a better job upscaling to fill the screen. Sometimes the gamma balance or color flags are interpreted differently. Sometimes real-time decoding is negatively effected by hiccups in the stream or the CPU can't keep up with the decoding thread (bits of data can be discarded in those situations to keep the stream running in real time), but the data that is in that stream will not change.
So, if you have a healthy computer setup, a good network connection and decent player (heck, try bypassing flash and run youtube in HTML5 mode), the detail displayed in the stream should not change. And if it does, there is something awry.
Opera has been my favorite browser since 2000 when Opera ver 4.0 was released, but the Opera devs have been struggling to stay current the past couple of years, so they made a deal with Google to use their Chrome platform and rebuild an "Opera-fied" version of Chrome. Things still aren't there yet, but version 19 looks very promising. ( I use IE only for compatibility checks and when I need to update Windows, Firefox is my third choice after Chrome, and the Opera-fied Chrome browser will go back to being my favorite once they've finished a full feature port. )
But it all depends on how those libraries are being used by the player, and in some cases the players are using their own CODEC libraries instead of the system CODEC libraries. In theory all playback should look the same if all players are using the same CODEC libraries with the same settings, but I'm not seeing this when I test the same video files with different media players, so I am pretty certain that things are not being handled the same way under the hood.
Depends on what the encoder is doing, as again there are a large range of encoding variables that will effect the final look of the compressed video.
I've been using the professional Sorensen Squeeze encoder encoder since version 2 was released in the late 90's ( Flash's Spark CODEC was invented by Sorenson along with their Sorensen Pro 3 CODEC which was also used by Flash at one point), along with the Canopus ProCoder ( now owned by GrassValley ), TMPGEnc ( for MPEG-1 encoding in the late 90's ), and On2's FlixPro encoder for FLV encoding. ( On2 invented the Flash FLV format that was essentially a repackaging of their VP6 format. The superior TrueMotion VP7 CODEC went nowhere, then the TrueMotion VP8 CODEC was gobbled up by Google when they bought On2 in 2010 and turned into an Open-Source platform )
I will disagree here, as I honestly think that both ends of the compression/decompression process can have a significant impact on the final image displayed. ( I would equate this to setting color-balance when shooting video and setting color-balance in post. Both processes are important to achieving the final result you want )
My take away from this comparison video is that the IQ is very similar, close enough to mix & match footage in a project. Which means that I could use my GH3 for interviews and other footage that requires sound recording while using the GX7 for silent b-roll footage. Not a bad combo I think.
I really like that the GX7 has in-camera image stabilization, focus peaking, and this new (supposedly faster) Light Speed AF. Sounds like a great run-n-gun b-roll camera.
I really like that the GX7 has in-camera image stabilization, focus peaking, and this new (supposedly faster) Light Speed AF. Sounds like a great run-n-gun b-roll camera.
Thomas Smet
Veteran
Decodes are just like encoders and not all programs use them the same even if there are built off the same library. That would be like saying all programs built off of Microsoft DirectX function exactly the same. We know that isn't true and sometimes when there is an API involved people implement that differently.
Encoding is only half the equation that takes place with video. The encoder crunch things together to make the data fit in a much smaller size. It does this with DCT compression, predicted motion, chroma subsampling and various other methods. There can be an endless combination of encoding settings that make all videos different. It is then the job of the decoder to try and put that video back together again by reversing the process as best as possible. All decoders will handle this process differently because the process to put the video back together can be sometimes a bit complex.
This is one of the key reasons why different DVD and Blu-Ray players can offer a different level of quality. In theory they should all just use mpeg2 or mpeg4 decoding and should look exactly the same but sadly that is not the case.
stoneinapond
Veteran
For still images only.
I didn't see that mentioned in any of the product descriptions that I read. If that's true then it's a major disappointment.
And I think it's only 2-axis stabilization, not the 5-axis stabilization that Olympus has in it's OMD EM-1 and OMD EM-5 cameras. ( 1 stop advantage with the 2-axis system, 3-4 stop advantage with the 5-axis system )
M. Gilden
Canon DSLR Moderator
*sigh* I wanted to back out of this part of the conversation because it isn't fair that we are taking over an otherwise informative thread regarding cameras.
But since so many seem to disagree and/or misunderstood what I said, I'd like to respond once more for prosperity, then politely ask that further comments be taken to a new thread (or you may PM me if you'd like to discuss, or heck even just argue with me- I'm up for it! :grin: )
Yes and no. Decoders are not just like encoders. Encoders have an infinitely more complex job to tackle than the decoders do.
A Decoder's job is to put that puzzle back together following the rules of the codec. Whereas an encoder has an almost infinite amount of ways to break the image up, there aren't so many different ways to put it back together- in fact, one could argue that there's really only ONE correct way, the way that the encoder designated. Will it always be? That depends- built into the decoder is a sort of "panic mode", where it is allowed to flub up the puzzle at times in order to keep up with real-time processing (in other words, skip parts of data to move on to the next frame instead of having choppy motion and having to pause to keep up). This can happen if the CPU can't keep up or the data stream isn't constant, or any number of factors.
The REAL question is, what happens to the image data after that? Well, that's where things get complicated. You have the information for a decoded frame of video, and it should be more-or-less what the encoder wanted it to look like. But the image has to go through a lot of other processes and libraries before it actually appears on your screen. For example, how to determine the color represented by each pixel, if pixels are being resized (bicubic, lanczos, etc), constrained to fit a bounding box, etc. All that can change, but the actual library decoding the frame should not vary enough to notice a big difference.
On that note, the DirectX comment just further explains my point- an instruction asked to a DirectX function will give the same response every time. That's sort of the idea, a standardized set of functions.
"Now, I'm not saying every player will look 100% equal- sometimes one does a better job upscaling to fill the screen. Sometimes the gamma balance or color flags are interpreted differently. Sometimes real-time decoding is negatively effected by hiccups in the stream or the CPU can't keep up with the decoding thread (bits of data can be discarded in those situations to keep the stream running in real time), but the data that is in that stream will not change. "
The data will not change. If a compressor managed to fit more detail into the stream, it will still be there. The details of how it is interpreted and displayed might vary however.
What's the difference, you may ask?
I'll tell you- a poor compressor will lose sharpness and definition in the image. A good decoder won't bring that back. The decoder (assuming it isn't dropping data or choosing to ignore parts of it) will recreate whatever resolution and detail is found in the encoded image. It might scale pixels differently or go through a different set of drivers to get the colors on screen, but if we are trying to compare resolution and edge detail, it shouldn't be different enough to determine one being "better" or "worse" than the other, unless one is truly horrible. The differences between encoders are exponentially more noticeable than the differences in decoders.
Here's the point- Yes, there will be some minor discrepancies between players. Colors, scaling, layering within bounding boxes, thread priorities and real time stuff... but if you want to see the definition of a stream, I really don't believe that downloading a compressed youtube stream and playing it in VLC will yield a significantly better image than playing it directly off youtube. That's really all I was trying to get at here, and I apologize to the OP for the sidebar here.
I'd be happy to discuss this matter further elsewhere, it doesn't belong here.
But since so many seem to disagree and/or misunderstood what I said, I'd like to respond once more for prosperity, then politely ask that further comments be taken to a new thread (or you may PM me if you'd like to discuss, or heck even just argue with me- I'm up for it! :grin: )
Yes and no. Decoders are not just like encoders. Encoders have an infinitely more complex job to tackle than the decoders do.
A Decoder's job is to put that puzzle back together following the rules of the codec. Whereas an encoder has an almost infinite amount of ways to break the image up, there aren't so many different ways to put it back together- in fact, one could argue that there's really only ONE correct way, the way that the encoder designated. Will it always be? That depends- built into the decoder is a sort of "panic mode", where it is allowed to flub up the puzzle at times in order to keep up with real-time processing (in other words, skip parts of data to move on to the next frame instead of having choppy motion and having to pause to keep up). This can happen if the CPU can't keep up or the data stream isn't constant, or any number of factors.
The REAL question is, what happens to the image data after that? Well, that's where things get complicated. You have the information for a decoded frame of video, and it should be more-or-less what the encoder wanted it to look like. But the image has to go through a lot of other processes and libraries before it actually appears on your screen. For example, how to determine the color represented by each pixel, if pixels are being resized (bicubic, lanczos, etc), constrained to fit a bounding box, etc. All that can change, but the actual library decoding the frame should not vary enough to notice a big difference.
On that note, the DirectX comment just further explains my point- an instruction asked to a DirectX function will give the same response every time. That's sort of the idea, a standardized set of functions.
You are mostly correct, as I understand it. And I even admitted this:
"Now, I'm not saying every player will look 100% equal- sometimes one does a better job upscaling to fill the screen. Sometimes the gamma balance or color flags are interpreted differently. Sometimes real-time decoding is negatively effected by hiccups in the stream or the CPU can't keep up with the decoding thread (bits of data can be discarded in those situations to keep the stream running in real time), but the data that is in that stream will not change. "
The data will not change. If a compressor managed to fit more detail into the stream, it will still be there. The details of how it is interpreted and displayed might vary however.
What's the difference, you may ask?
I'll tell you- a poor compressor will lose sharpness and definition in the image. A good decoder won't bring that back. The decoder (assuming it isn't dropping data or choosing to ignore parts of it) will recreate whatever resolution and detail is found in the encoded image. It might scale pixels differently or go through a different set of drivers to get the colors on screen, but if we are trying to compare resolution and edge detail, it shouldn't be different enough to determine one being "better" or "worse" than the other, unless one is truly horrible. The differences between encoders are exponentially more noticeable than the differences in decoders.
I'm aware. My background is in Computer Science and engineering. I studied this stuff and wrote papers on codecs in college before some of this was even around.
I think that has less to do with decoding the image as it does with things like de-interlacing, scaling, gamma and color translation, etc. I'd like to think that internally the standalone boxes at some point get the same information extracted from the stream, then they go different ways with it.
Here's the point- Yes, there will be some minor discrepancies between players. Colors, scaling, layering within bounding boxes, thread priorities and real time stuff... but if you want to see the definition of a stream, I really don't believe that downloading a compressed youtube stream and playing it in VLC will yield a significantly better image than playing it directly off youtube. That's really all I was trying to get at here, and I apologize to the OP for the sidebar here.
I'd be happy to discuss this matter further elsewhere, it doesn't belong here.
Last edited: