x264 Settings for web Flash Player? [Archive]

nhope

16th March 2011, 18:18

Other than adjusting the bitrate (i.e. higher crf or automated 2-pass etc.), is there any reason not to just go with the x264 version 1913 default settings for web-hosting x264/mp4 files in the Adobe Flash Player using JW Player, Flowplayer etc.? Should I be "dumbing down" any settings (e.g. --b-pyramid none, --weightp 0 etc.)? Should I be adding any VBV settings?

sneaker_ger

16th March 2011, 20:01

All presets (including the default settings) work in Flash Player.

nhope

16th March 2011, 21:20

Thanks. Will changing any of the default settings help smooth playback, particularly HD in a big window or full screen?

sneaker_ger

16th March 2011, 21:32

"--tune fastdecode" (equals "--no-cabac --no-deblock --no-weightb --weightp 0") could help, but I don't have any numbers on the percentage of a typical increase at hand. I wouldn't use or recommend it personally.

Blue_MiSfit

16th March 2011, 23:07

If you only care about the PC, then use the defaults.

If you care about mobile devices, I'd perhaps use --no-cabac, and make sure you're targeting the proper profile and level.

Derek

smok3

16th March 2011, 23:20

i'd try to offer the users to select html5 mode (manually only, dont bother with automagic solutions), which may improve decoding speed in some cases/oses.

after manual selection you may want to check if the browser thinks it can actually play h.264 with a library like
http://www.modernizr.com/

working example html h.246 checker:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Can I play h.264?</title>

<script type="text/javascript" src="modernizr-1.6.min.js"></script>
</head>
<body>
<script>

if (Modernizr.video && Modernizr.video.h264) {

var mytext = "YES, I can play h.264.";
document.write(mytext);
}
else {
var mytext = "NO, I can't play h.264";
document.write(mytext);
if (Modernizr.video)
{
var mytext = "..., but i do support video tag.";
document.write(mytext);
} else {
var mytext = "..., I don't even support video tag.";
document.write(mytext);
}
}

</script>

</html>

benwaggoner

17th March 2011, 00:42

What frame size and frame rate are you targeting? Bitrate? The lower the peak bitrate, the more aggressive you can be on expensive-to-decode features like CABAC and reference B-frames.

Flash can handle High Profile just fine. For users with a recent version of Flash and recent hardware and OS, there is GPU accelerated decode. Of course, old hardware is where the software decoder is most limiting.

upyzl

17th March 2011, 01:46

Maybe you can use higher analysis-relatived parameters such as --me umh, --merange 32 and --subme 10 (note subme10 needs --trellis 2 and AQ on)
Because in the same bitrate for encoding a video (of course CRF is recommended), these parameters have little effect on decode/latency

for web playing, low ref and bframes are recommended (Default's OK)

Dark Shikari

17th March 2011, 04:49

Maybe you can use higher analysis-relatived parameters such as --me umh, --merange 32 and --subme 10 (note subme10 needs --trellis 2 and AQ on)
Because in the same bitrate for encoding a video (of course CRF is recommended), these parameters have little effect on decode/latency

for web playing, low ref and bframes are recommended (Default's OK)Refs and b-frames don't lower decoding speed.

nhope

17th March 2011, 06:53

Thanks for all the replies.

If you only care about the PC, then use the defaults.

If you care about mobile devices, I'd perhaps use --no-cabac, and make sure you're targeting the proper profile and level.
What frame size and frame rate are you targeting? Bitrate?

Personally I've switched to YouTube hosting all my videos, but I'm looking to refine the settings recommended in the guide linked to in my signature, which covers encoding for self-hosting as well as upload to sharing sites.

1280x720 is the priority resolution I'm interested in, but also 1024x576, 768x432, 640x480 and 854x480. The guide targets no particular playback device at the moment, but I could add in content about that. To be honest I have been mostly thinking desktop playback, without giving much thought to mobiles etc..

The guide currently recommends the following bitrates for "busy" videos, or half or even less for low movement/plain background videos:

1280x720 - 2000 Kbps Automated 2-pass
854x480 - 1000 Kbps Automated 2-pass
640x480 - 800 Kbps Automated 2-pass

I'm looking to lower those recommended bitrates a bit, and maybe automate it by determining a crf number that brings the bitrate into the right range.

As it stands, the guide recommends disabling B-Pyramid and P-frame Weighted Prediction; Recommendations which originated from Handbrake and Vegas 8 issues. I now realise that advice is probably off the mark for a MeGUI-based guide.

smok3

17th March 2011, 08:46

nhope: i just finnished encoding a series of short clips with crf 18 and bitrate goes from 1.500 to 10.000, so I'd think bitrate and crf are really not that friendly in the same sequence.

Blue_MiSfit

17th March 2011, 10:16

I'd also agree that streaming is best achieved using target bitrate mode.

hiviking

16th December 2011, 13:36

Yes, the Flash player can play videos encoded with x264, but it has a problem with jerky movement in panning sequences. The same files play smoothly in other players such as VLC or MPC.

This problem has been reported at e.g. http://www.longtailvideo.com/support/forums/bits-on-the-run/transcoding/20303/choppy-video-on-pans.

Are there any x264 settings that can reduce this problem?

iwod

16th December 2011, 18:18

Oh Tarts!!!!! I re-encode all my video thinking with HTML and Flash fall back i have everything covered... i completely forgotten iPad is limited to H.264 profiles!!!!!!!!

CruNcher

16th December 2011, 19:29

Thanks. Will changing any of the default settings help smooth playback, particularly HD in a big window or full screen?

The Browser is more the Problem depending on the usage scenario for Example Firefox is weak in keeping Playback Problem free in extreme usage scenarios (several code running in several different tabs) where Chrome has absolutely the best Performance you ever gonna see :) also it's GPU compositing is amazing and the whole Multithread optimization :)
This also impacts Fullscreen Playback in Adobes own Player instance as well even running in it's own context inside Firefox encapsulated plugin-container isn't very helpful also the piping of the data internally costs time which can result in worse cases in frame drops again :(

See also my Performance Report (simple test scenario) on Bugzilla and the Videos i made using my own Realtime H.264 Hardware Recoding Framework (via Quicksync) :)

https://bugzilla.mozilla.org/show_bug.cgi?id=702485

kieranrk

16th December 2011, 20:43

I've been told Flash even supports 10-bit but I've never verified it for myself.

CruNcher

16th December 2011, 21:10

yes it does it's core is based on Mainconcept and the main know how comes from Elecard which code where floating inside and replaced mostly the entire old Mainconcept base code when both fussioined together for a short time back then so most of the interesting code comes from Elecard :)
It was a time where Mainconcept realized their Code wasn't efficient enough and who knows what would have happened to them without the knowledge from Elecard flowing into it @ that time the Encoder especially was in a very bad shape after the merger that changed rapidly.

smok3

18th December 2011, 20:27

I've been told Flash even supports 10-bit but I've never verified it for myself.

with some funny magenta right border added, but mostly it works (i did not bother to research who to blame).

jmartinr

29th December 2011, 00:05

with some funny magenta right border added, but mostly it works (i did not bother to research who to blame).I did some testing and got that magenta right border too. Has someone any ideas how to avoid that?
Will do some more testing tomorrow and report here.

poisondeathray

29th December 2011, 00:15

Funny, I did some tests yesterday:

10bit 420 => magenta R border
10bit 422 => magenta R border
8bit 422 => mostly ok, but some decoding problems on some frames (colored blocks) , but upsampling quality is almost just as bad as 420

But interestingly Adobe lists support for Hi10P for flash under supported profiles, maybe it's incompatibility with x264's version of Hi10P ?

The video streaming–related subsets of the MPEG-4 part 10 standard supported by Adobe Flash Platform technologies are:
.
.
.

High 10 Profile (Hi10P). Hi10P increases the decoded picture precision of the High Profile to 10 bits per sample.

http://www.adobe.com/ap/products/hdvideo/supported_technologies/h264.html

Dark Shikari

29th December 2011, 00:27

Most likely Mainconcept's decoder supports it, but the renderer/pipeline doesn't implement it properly. I doubt Adobe's ever tested it.

kieranrk

29th December 2011, 09:15

Most likely Mainconcept's decoder supports it, but the renderer/pipeline doesn't implement it properly. I doubt Adobe's ever tested it.

I actually asked Mike about this and this was pretty much his response.

jmartinr

29th December 2011, 12:43

Did some more testing. Varied the video-dimensions and tried different players (JWPlayer and FlowPlayer). I also remuxed to FLV. But it makes no difference at all. The Magenta right border is always there. :(

The two previous posts describe the situation probably best.

jmartinr

31st December 2011, 14:48

Bugreport for this issue: https://bugbase.adobe.com/index.cfm?event=bug&id=3078157

benwaggoner

3rd January 2012, 23:14

I actually asked Mike about this and this was pretty much his response.
It makes me nervous that Flash still has code paths that haven't been well tested...

Silverlight only does progressive 8-bit 4:2:0 largely to constrain the scope of fuzz testing and other hardening validation we need to do.

CruNcher

4th January 2012, 00:06

Not sure but i doubt Adobe has access to the full decoder source so they just implement provided libraries of the broadcast decoder part and everything in the main core gets in tested or not (though special agreements are always possible getting source xs), Microsoft seems to be another situation they own everything themselves or wasn't the AVC decoder in Silverlight and the Microsoft DTV decoder your own implementation so your team knows it inside/out ? ;)
But yeah it's surprising that Adobe actually even advertises with the 10 bit part but its failing for example DivX never advertised it but it was allways in the decoder (failing too) ;)

Silverlight only does progressive 8-bit 4:2:0 largely to constrain the scope of fuzz testing and other hardening validation we need to do.

Yeah and thats the right way something that doesn't work and only is ballast (or might be even a security risk, or attack vector) should be disabled and not compiled (what is not their is also no risk) it seems logic so its a little surprising how Adobe handles it in a Release build especially on such a sensitive platform to exploits ;)

benwaggoner

4th January 2012, 02:02

Not sure but i doubt Adobe has access to the full decoder source so they just implement provided libraries of the broadcast decoder part and everything in the main core gets in tested or not (though special agreements are always possible getting source xs), Microsoft seems to be another situation they own everything themselves or wasn't the AVC decoder in Silverlight and the Microsoft DTV decoder your own implementation so your team knows it inside/out ? ;)
We compile every line of source for everything in the Silverlight runtime. 3rd party binary libs would be crazy talk!

But yeah it's surprising that Adobe actually even advertises with the 10 bit part but its failing for example DivX never advertised it but it was allways in the decoder (failing too) ;)
And that's such a red flag for malware writers, since it shows the code hasn't been heavily vetted, and perhaps an evily designed 10-bit H.264 bitstream could be used to trigger an elevated aribtrary process or something else naughty and dangerous like that.

Yeah and thats the right way something that doesn't work and only is ballast (or might be even a security risk, or attack vector) should be disabled and not compiled (what is not their is also no risk) it seems logic so its a little surprising how Adobe handles it in a Release build especially on such a sensitive platform to exploits ;)
Exactly. An app platform that can run malicous code from any random URL needs to be hardned so that malicous code can't do anything naughty outside a sandbox.

No code that hasn't been thoroughly tested with malicously designed code and data should get installed on end-user machines!

The #1 reason features get cut from Silverlight is due to security test cost.

Blue_MiSfit

4th January 2012, 02:22

I'm very glad to read the above.

jmartinr

10th January 2012, 11:23

I made a few encodes for flash while downsizing some HD-video's. The following commit-message looked promising.

commit 0ba8a9c6973897ec35e1a5d241a71f4f5a4f81aa r2057
Author: Jason Garrett-Glaser <jason@x264.com>
Date: Sat Aug 6 10:45:47 2011 -0700

Improve support for varying resolution between passes
Should give much better quality, but still doesn't support MB-tree yet.
Also check for the same interlaced options between passes.
Various minor ratecontrol cosmetics.

So I made a few encodes form HD to 704x396 with an HD-input for the first pass. If you specify --no-mbtree it works well.

But... the encodes that used the HD-video for the first pass seemed to retain more grain, looking better in calm scenes, but had also less-defined edges, making the overall impression of the video less sharp. Differences were small though.

You can see two test videos at:
http://www.roelofs-coaching.nl/play/testfirstpass/pitch%20rick
http://www.roelofs-coaching.nl/play/testfirstpass/pitch%20rick%20big%20first%20pass
You can download them at:
http://www.roelofs-coaching.nl/Blobs/Videos/testfirstpass/pitch%20rick.mp4
http://www.roelofs-coaching.nl/Blobs/Videos/testfirstpass/pitch%20rick%20big%20first%20pass.mp4

These are not the best test videos. There's not much movement. I tested others, but I'm not allowed to show them, sorry.

CruNcher

11th January 2012, 04:29

hmm most frames decode with heavy errors Flash 11.2 Intel GT1 2559 (Quicksync)

smok3

11th January 2012, 09:05

CruNcher: how do you test?

(i do see some heavy pumping (sharp, blur, sharp, blur, ...) on the guys jacket)

mp3dom

11th January 2012, 09:20

Me too. Full of green frames and lots of decode errors. Clarkdale Intel GPU and latest flash player. I think it depends on too much reference frames (16?). Try to limit it to 5 and it should work correctly. No problem if I disable hardware acceleration. The videos that have problems are the ones in post #29. If downloaded, MPC-HC plays it in software mode, not DXVA.

jmartinr

11th January 2012, 09:23

(i do see some heavy pumping (sharp, blur, sharp, blur, ...) on the guys jacket)

I see it now too. But that's in the source already. :( It's a 31.7 Mbps AVC. Apparently not good enough as an intermediate.

jmartinr

11th January 2012, 09:27

Me too. Full of green frames and lots of decode errors. Clarkdale Intel GPU and latest flash player. I think it depends on too much reference frames (16?). Try to limit it to 5 and it should work correctly. No problem if I disable hardware acceleration. The videos that have problems are the ones in post #29. If downloaded, MPC-HC plays it in software mode, not DXVA.

Ouch. Must be the hardware decoding then. I'll redo them with 5 reference frames.

jmartinr

11th January 2012, 09:46

New versions with 5 refs at:
http://www.roelofs-coaching.nl/play/testfirstpass/pitch%20rick%205ref
http://www.roelofs-coaching.nl/play/testfirstpass/pitch%20rick%205ref%20big%20first%20pass

CruNcher

11th January 2012, 23:34

Jep those work fine

jmartinr

12th January 2012, 00:04

Jep those work fine

:thanks:

Firebird

5th February 2012, 18:38

Magenta right border issue is fixed in Flash player 11.2 beta 5, hooray!

smok3

5th February 2012, 21:21

Magenta right border issue is fixed in Flash player 11.2 beta 5, hooray!

Do they have a changelog with a mention of that? Did you test?

sneaker_ger

5th February 2012, 21:52

I didn't see any changelog, but I could verify it in a small test and it was indeed fixed.

jmartinr

5th February 2012, 21:53

Do they have a changelog with a mention of that? Did you test?

I just checked and it works for my sample (http://www.roelofs-coaching.nl/play/10bit/24uur10bit). :)

jmartinr

28th March 2012, 23:28

Flash player 11.2 is out now.

smok3

29th March 2012, 07:48

and yes, 10 bit 422 stuff does play without magenta border :)

CruNcher

29th March 2012, 12:54

very interesting was updating did not required a Firefox browser restart (Firefox 14 Nightly) :) though it was a minor update from 221 to 228 anyways nice :) the addon display still shows the old build though also as disabled but on websites the new one is loaded without restarting :)
Though many things in Firefox still lack compared to Chromium and Flash usage still needs a lot of work to be as warning buzzword "Fast and Fluid" ;)

In those regards https://bugzilla.mozilla.org/show_bug.cgi?id=702485 still not under control in Firefox 14 yet no chance vs Chromium here, and im slowly not sure anymore if this ever get fixed it's more efficient in this task to run on the CPU rendering part then on the D2D rendering part of Firefox :(
Which in the end means for Fast and Fluid Multimedia Experience Firefox is currently in a bad shape with it's D2D Implementation compared to Google.
Though this issue looks more complex as when the Streaming Thread of Flash runs even more Frames get dropped @ interaction time in D2D mode so the whole interaction between different parts here seems to be inefficient working together (Multithreading with D2D).