High Quality FLV with metadata for pseudostreaming

[misterio]

Hello, this might be the first and good place to start asking questions =)

We run a high definition site, we need to encode to high definition FLV, so we're thinking that h.264 is the way to do this...

This person has done it:

http://blog.somestuff.org/index.php?entry=entry080530-135418

we tried to do this and it played fine, except when we tried to seek into the video (flv_stream module) we would only get sound being played back...

Also, if we would only encode to MP4 (h.264) we need to eliminate that wait time at the beginning (about a minute or so of wait time) to not confuse the users into thinking that its buffering and really, only reading the moov atoms (yes they've already been moved to to the front using MP4Box -isma videofile.mp4 )


Videos that we host are anywhere from 5 minutes to 3 hour footage, how would I encode this to a much crisper, cleaner more vibrant export using ffmpeg or mencoder? any thoughts? perhaps example command lines?

[poisondeathray]

Are you "streaming" or using "progressive downloading"?

AFAIK seeking and cuepoints only work with rtmp streaming , not progressive download (HTTP) as that site uses and what most sites use (e.g. youtube, vimeo etc...). This is not the same thing as seeking when already downloaded as with progressive download.

Some info on encoding using ffmpeg
http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/
http://forum.doom9.org/showthread.php?t=134225

[misterio]

Poison, thanks for your quick reply, I really appreciate it... well... as far as I know, there's streaming, progressive download and pseudostreaming, peudostreaming can be done by using a module for lighttpd or a php script like xmoov, we use pseudostreaming, not through RTMP...

[poisondeathray]

I'm not an expert on this, and I was actually learning about this exact topic yesterday...

From what I understand, that is why it's not working on smok3's site (the site you linked to), because his is set up as progressive download.

Do you have the modded lighttpd version for h.264 ?

For pseudostreaming and lighttpd , here is an example using an rss playlist .
http://www.longtailvideo.com/support/jw-player-setup-wizard?example=16

I think it has to be set up properly on the server side for the chapter seekpoints. Also I think the video assets have to have an I-frame or cue-point for the seek point or it will skip to the nearest one (ie seeking isn't perfect and this is the most common complaint using this setup). You can add more frequent keyframes in the encoding settings as you see fit so seeking will be more precise, but the compression will suffer. You would use a qpfile in x264 to specify chapter points and I-frames, not sure how to do it with mencoder or ffmepg

[misterio]

I see it working fine on smok3's site... I mean, he uses cheap streaming which is what we also use =) . im wondering why we have followed his command line to mux h.264 to flv and it still isn't working, the only difference was that he used flvmdi and we use flvtool2 becuase we run on a linux enviroment, is there flvmdi for linux?

[poisondeathray]

Exactly what do you mean by not working?

How are you doing the seeks?

My understanding is that when you mux h.264 to flv, the moov atom is changed and you need qt.faststart or similar to fix it. I get around that problem by using mp4box as you've already mentioned automatically places it at the beginning

I don't know of any linux flvmdi equivalent. But if you encode it properly it should work ... I think

Have you asked on the JW forums? Also smok3 posts on Doom9, he might know more you could ask there as well

[misterio]

it starts playing just fine... however... once we move the scrubber it will seek to the position, except we don't get video, just audio... using JWPlayer

[poisondeathray]

Dumb question, but do you mean his video on your site? or viewing his site directly?

I'm not sure why this is happening as I just started to learn about non progressive download options...sorry

[misterio]

ffmpeg -y -i video.avi -an -pass 1 -threads 2 -vcodec libx264 -s 640x400 -b 512k -bf 3 -subq 6 -cmp 256 -refs 5 -qmin 10 -qmax 51 -qdiff 4 -coder 1 -loop 1 -me_method hex -me_range 16 -trellis 1 -flags +mv4 -flags2 +bpyramid+wpred+mixed_refs+dct8x8 -partitions parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -g 240 -r 20 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 video_HD2P.mp4

also, we've started with those settings as per recommendation - however, we get the following error:

Seems stream 0 codec frame rate differs from container frame rate: 29.98 (65535/2186) -> 29.97 (2997003/100000)
Input #0, avi, from 'mythbusters.avi':
Duration: 00:43:02.76, start: 0.000000, bitrate: 1132 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 624x352 [PAR 1:1 DAR 39:22], 29.97 tbr, 29.97 tbn, 29.98 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 128 kb/s
Invalid value '1' for option 'loop'


any thoughts?

[smok3]

misterio:
just some random notes:
1. php streaming of AVC flv files wont work with new versions of jw player, you would have to use older (i blame adobe), edit: you may find more info on jw forums
3. 3 hour clips wont work fine with pseudostreaming, make it 10 minutes or something
4. the demo i have online uses both pseudostreming (on some lowres clip) and progressive download on some others (mainly HD stuff)
5. i wouldn't use dumb pseudostreaming for HD
6. big bugs bunny encodes really fine even at some lower bitrates and as such is not really representative on what would happen with some other material...
7. i have no idea about ffmpeg, so can't help there

edit2: if you suspect something is wrong with your encodes, here is the download link to the bunny that pseudostreams;
http://blog.somestuff.org/static.php?page=bunny

edit3: hm, if you are working on warez site, then i'am sorry i took the time to write this.

[misterio]

No sir, not warez haha, its a legit site... thanks for providing the info, i'll run some tests and get back to you and then I'll provide the url of the site that we're working on

[disturbed1]

ffmpeg -y
---------------------------
Invalid value '1' for option 'loop'


any thoughts?

I know nothing about the jw player, or integrating flash with apache, but......
-loop 1 is not a valid ffmpeg option in that context. If you copy and pasted some command from a website, look at it again.

-loop_input loop (current only works with images)
-loop_output number of times to loop output in formats that support looping (0 loops forever)
-flags
\\\\\\\\\\\ loop E.V.. use loop filter

If you wanted to use the loop filter, add it after your flags definition. Maybe like this
-flags +mv4 +loop

If you haven't found it already, there is a thread dealing with a very similar subject at doom9's forum. Have a look there.

[misterio]

thanks for this, we've been working on creating a high quality FLV output that doesn't look like its been made with different colored legos... we want to ditch DivX but need to find a way to encode to a good FLV (pseudostreamable) to come close to the quality. Any thoughts?

[poisondeathray]

Here are some psudeostreaming examples with h.264 .mp4 with the modded streaming module + JW. Wait time not that bad
http://h264.code-shop.com:8080/testlist.html
http://h264.code-shop.com/trac

None of them are longer than 20min, but smok3 says not to use long clips for pseudostreaming

[misterio]

I've created an example at this test page:
I've also included the ffmpeg commands used to create these video files...

http://66.90.73.189/sampler/test.html

the last one was first encoded to h.264 (mp4) then muxed to flv and then injected with FLVtool2, it seeks but will only throw sound, and no display when doing so. =(

the second video is a h264 video in mp4 container, and ran through qt-faststart, however, notice the 1-2 minute wait time for the video to load...

[poisondeathray]

The wait time for the .mp4 version was about 3-4 seconds for me, not close to 1-2min ... but the .flv was clearly faster to load. None of them seek very well for me before downloaded.

The other examples in the page I listed above seem to seek smoothly and only 1-2 sec delay even between seeks. Might be a bandwidth bottleneck on your end?

EDIT: the 3rd one seeks with video & audio, but the timeline counter is screwed up. (e.g. I skip to 30min mark, but the timeline counter still reads 0:15)

[misterio]

Too many discrepancies, would you imagine the amount of e-mails we would receive in support tickets we're thinking of outsourcing the encodes, with www.encoding.com or hire a freelancer to set this up for us for high quality flv (high definition too) and seekable, so if you know anyone, please do lead them to vureel[at]nitemedia.com

thanks!! and thanks all for your help

[baybrady]

I think that h.264 in FLV with keyframe metadata for seeking is not really flushed out yet.
The issue you mention, sound but no video, is common with the JW4.x series player.
I'd guess it will work fine for you with one of the JW3.x series. Also FlowPlayer worked for me.

I think the central issue is that the seeked FLV returned by lighttpd+mod_flv_streaming, for an h.264-in-FLV, is not a nice FLV file. mplayer won't play it and mediainfo barely recognises it. But somehow JW3.x and FlowPlayer do not have a problem with these seeked FLVs.

I guess the problem with these seeked FLVs is either created by the metadata injector (the old standard ones don't know about AAC audio or h.264 video, so some metadata fields are empty), or else due to some error caused by attempting to start a h.264 video in the middle (even though on a keyframe).

If anyone has more info, please enlighten.

[zoobie]

you lost me...

you're concerned about the wait time before the h264/mp4 plays?
you're concerned about seeking when the video has never been seen?
you're a HD site and will be outsourcing?

try someplace with a faster connection
you'll see most mp4's play within seconds in the JW player unless it's huge
you can always break it up into smaller segments
don't turn off the JW player's icons

these are major concerns?
I'd be thankful the damn thing even works...HD on the net...and free to boot
JMO

[baybrady]

you lost me...

you're concerned about the wait time before the h264/mp4 plays?
you're concerned about seeking when the video has never been seen?

These are valid concerns.
The other related one is the load on the server doing all the moov atom calculations through lighttpd's mod_264_streaming.

If h264/flv seeking worked, the three of these issues would be addressed. Consider, the bigger the files, and the more end users you have, the more these things matter.

[Cornucopia]

If you haven't already read this, you may be interested in: http://labs.influxis.com/?p=4, which clarifies a few things about buffering and streaming which may point you to a solution.

My take:
1. Make sure your server has a Super High Speed backbone connection (so the "bottleneck" would only be on the client-side)
2. Use a REAL RTMP server solution (you may want to check out those OpenSource beta options...)--better realtime QoS, will scale better with more clients (multicasting, etc)
3. Use scripts to make the flash be pseudo-Multi-bitrate; this will match the quality to the user connection without further scaling problems
4. Don't inject the metadata after the fact, use an industrial strength encoder that allows for direct creation of metadata along wth the encode--like DigitalRaptids. Gonna have to put out the $$$ somewhere...
5. Long segments = Bad idea. This is part of what is making the buffering worse. Use a script/metafile/redirector to concatenate (in realtime for the clientside) multiple segments, each with their own seek indexing.
6. Lower your keyframe interval (smaller GOP length), and optimize your encode through other means: cleaner source/more preprocessing, tweaking Matrix tables, using a carefully-crafted constrained 2-pass VBR with hand-picked I-frame points, VBV buffer tweaking, etc.
7. Test on multiple sites (both client and server) to get a good real-world idea about the kind of load and QoS you should expect
8. Finally, realize that this is only the early stages of HD streaming and some of the kinks will still need to be worked out...

Scott

edit:>>>>>>>>>>>>>>>>
and yes, Big Buck Bunny, or any cell/3d animation for that matter, isn't a good indicator of what's achievable with a particular bitrate structure

[zoobie]