1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

mp4 transcoding appears to be eliminated

Discussion in 'TiVo Home Media Features & TiVoToGo' started by larry99, Feb 18, 2009.

  1. moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    I encoded to mp4+h.264+ac3 a 720p mpeg2 episode of Lost and sure enough both the source mpeg2 and destination mpeg4 are 59.94 fps and it streams and pushes fine to Tivo.
     
  2. burnside

    burnside New Member

    42
    0
    Jan 12, 2009
    What is the command you use to encode the mpeg2 to mp4+h.264+ac3 if I may ask?
     
  3. moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    ffmpeg -y -i "inputFile.mpg" -vcodec libx264 -coder 0 -level 41 -r 29.97 -sameq -g 300 -bufsize 14745k -b 5000k -maxrate 16000k -bug "+autodetect+ms" -me epzs -trellis 2 -mbd 1 -acodec copy -f mp4 "outputFile.mp4"

    (P.S. You may want to remove the -r 29.97 option to use same frame rate as source and adjust the -b 5000k option for size vs. quality tradeoff)
     
  4. txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    Is there any way to make it possible for a pull to bring in a mp4 file without a transcode? I know my wife would prefer this...and I would too if the pushes are what are causing my Tivo's service connection calls to fail.

    Jason
     
  5. wmcbrine

    wmcbrine Ziphead

    10,364
    22
    Aug 2, 2003
    Absolutely not.
     
  6. Mar 1, 2009 #226 of 297
    jg123

    jg123 New Member

    26
    0
    Mar 14, 2003
    If you have success transcoding mkv to mp4 using ffmpeg, I would love to hear it. I'm having the same issues with the latest builds of x264 and ffmpeg.
     
  7. Mar 1, 2009 #227 of 297
    moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    A big downside to mpeg4 encodings natively on the Tivo is that FF/REW don't seem to work very well, especially FFx1.

    This post seems to sum up pretty nicely why FF/REW with mpeg4 is not very good compared to mpeg2:
    http://www.dbstalk.com/showthread.php?p=1999410#post1999410

    In my small list of h.264 encodings there are some that FF better than others, but so far any h.264 clips I have produced with either ffmpeg or handbrake are not good for FFx1. I did some experimentation with ffmpeg altering GOP size from 30-300 range and reference frames from 1-6 range, etc. but they didn't really seem to have much effect.

    If anyone here has h.264 encoding recipe that works well for FFx1 please post.

    EDIT: Forgot to mention that wmv files with VC-1 video and WMA9 audio work pretty well with FFx1 when streaming natively to Tivos. (streambaby doesn't yet support native streaming of those files but I added that in tivostream a while back. There is a way to get streambaby to stream those natively if someone is interested)
     
  8. Mar 2, 2009 #228 of 297
    txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    There are a few different things that determine whether or not to place an I-frame (key frame) in h.264. One of them is the min/max keyint value (like GOP). The recommendations that I have seen is to use fps for min and 10xfps for max. That would give you key frames every 1 to 10s. The other thing that can add a key frame is scene cut. This is a function in h.264 (x.264) that attempts to determine when there is a scene change and will add a key frame. The number set determines sensitivity to a scene change. See this post for a decent summary of x.264 settings. So, it is possible that your videos that seek better have more scene changes and therefore more key frames.

    My understanding of reference frames is that they are used to determine if the scene is static or moving and will allow better compression if you use a larger number. I don't think they should affect seeking (although I guess they could since I would expect that a higher number would require more processing power to decode).

    Finally, here are couple of posts, one on mencoder settings and the other from doom9 forum about blu-ray. The mencoder post does say that keyint does affect seeking behavior. And the doom9 post lists the blu-ray values of -keyint as 24 and --min-keyint as 2. Based on that, it looks possible that in order to improve seeking in blu-ray they went with an extremely low value for min/max keyint. I don't have blu-ray, so I don't know what FF/RW is like, but I think we should be able to try some encodes with similar values to see if seeking is improved.

    Jason
     
  9. Mar 2, 2009 #229 of 297
    moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    x264 -> ffmpeg mappings can be found here:
    http://ffmpeg.x264.googlepages.com/mapping

    So x264->ffmpeg mappings for settings you mentioned would be:
    --keyint maps to -g
    --min-keyint maps to -keyint_min

    I already experimented alot with -g argument (I tried as low as 12) as I mentioned in my post above and that alone didn't seem to help. I also adjusted -refs (reference frames) from 1-6 range and it didn't seem to help either. I really expected that combination of decreasing GOP size and increasing reference frames should have helped, but it didn't.
    I don't see how -keyint_min is going to help but it's worth a try.

    I suppose there is a risk that if you try and optimize too much for improved FF performance you may well end up sacrificing much of the efficiency/space savings compared to mpeg2.

    I don't know offhand if there is a utility for viewing GOP structure of H.264 encodings but that sounds like it would be useful. (I think VideoRedo has such a utility for mpeg2 but not sure if it will work for mpeg4).
     
  10. Mar 2, 2009 #230 of 297
    txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    I think you can use MediaInfo to get the information that you are looking for.

    I am not sure what the -keyint_min defaults to in ffmpeg, but I would guess that it could limit how low you could go with your -g setting (-keyint). And frankly, I guess I really don't know how often key frames are set in MPEG2? I assumed they are more often than H.264...but I never checked.

    I will play around with some of these when I get a chance. Let me know if you find anything interesting. It is always possible that the seeking on the tivo is limited by the hardware decoding power, but it does sound like this is an overall problem with h.264.

    Jason
     
  11. Mar 2, 2009 #231 of 297
    moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    Thanks. For mpeg2 GOP size is typically pretty small (I think 18 frames/GOP is max for NTSC) and there is 1 I frame per GOP. I think a typical structure is something like: IBBPBBPBBPBB

    According to the x264->ffmpeg reference I posted above looks like GOP size for h.264 encodings are typically much larger than that (250 is given as default).

    To be honest though a lot of this is over my head and I don't really understand much about it which is why I post here in the hopes with others with a lot more understanding would be better suited to experiment and/or post here.
     
  12. Mar 2, 2009 #232 of 297
    txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    Yeah, I am hacking my way through this. Trying to learn some as I go. At least it is relatively easy to test this now that I can push things up to the tivo as mp4. If I get a chance, I will run some test cases tonight.

    Jason
     
  13. Mar 3, 2009 #233 of 297
    Dan203

    Dan203 Super Moderator Staff Member TCF Club

    37,446
    165
    Apr 17, 2000
    Nevada
    18 frames is max for an NTSC DVD, but the actual max for an MPEG-2 program stream is 1024 frames. It's very common for streams from DSS or digital cable to have really long GOPs (i.e. 30-50 frames). They do this because it increases compression and for a realtime playback system it doesn't effect quality too much. Although it does effect features like FF/RW, which is why on a S3 or DirecTiVo, which records the bitstream directly, some channels seem to FF/RW smoother then others.

    H.264 videos do typically have longer GOPs in general, but most encoding programs try to keep to around 50 frames max so that features like seeking and FF/RW are more practical. The longer the GOP the harder it is too seek and the harder it is to create smooth, usable, FF/RW functionality.

    Dan
     
  14. Mar 3, 2009 #234 of 297
    moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    Thanks for your input Dan.

    I experimented tonight again with GOP size and reference frames and got no improvement at all (-keyint_min=2 didn't have any noticeable impact either). The source clip is a recording from Tivo: a short 1 min 480i mpeg2 with Video CBR of 3Kbps and 29.97 fps. That clip has smooth FF/REW in mpeg2 format but various h.264 ffmpeg encodes with low GOP size and several reference frames failed to yield a good smooth FF/REW. No better with Handbrake and x264 encoder either. Could well be from that kind of source it's not possible to get a workable h.264.

    The following h.264 encoding on the other hand behaves pretty nicely with FF (not very good with REW)
    systm--0063--dolby--hd.h264.mp4 so I know the Tivo h.264 decoder is able to do smooth FF. The key specs according to MediaInfo on this are:
    L3.1 AVC1 (H.264), 720p, 2 reference frames, 2Kbps CBR, 24 fps
    MediaInfo doesn't give any other information on GOP structure AFAIK.

    I also tried an mpeg2 720p clip (also from Tivo) as a starting point but had no better luck getting a smooth FF h.264 encoding from it either using ffmpeg.

    From either of the 2 mpeg2 sources above on the other hand if I use Microsoft Media Encoder 9 or Microsoft Expression Encoder 2 (Silverlight encoder) to generate a wmv encoding (VC-1 AP video with wma9 audio) the result is a nice smooth FF in both cases when streaming to Tivo (REW is choppy as expected).

    So not sure what else to try at this point. It's not a huge deal to me as I don't use FFx1 that much but still it bothers me and would be nice to get to the bottom of this.
     
  15. Mar 3, 2009 #235 of 297
    txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    I took a 10min clip at the beginning of Empire Strikes Back and encoded it 3 different ways in handbrake: my default profile (see P.S.), changed keyint to 24 (from 240) and keyint-min to 2 (from 24), and another with keyint=2/keyint-min=2 + no Pframe skip/DCT decimate. In all case, FFx1 looks fine. FFx2 (whatever speed of 2nd FF press) looks choppy in clip #1, but DOES look smoother in clips #2 & #3. I am not sure I can tell a difference between #2 and #3 though. It looks like each of those changes added another ~10% to the file size.

    In MediaInfo, if you move to one of the other views (anything other than Basic), you will see what the encoding setting are for the mp4 that you are looking (at least I do with Handbrake).

    Jason

    P.S. Default profile (pulled from MediaInfo, text view):
    Code:
    cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / keyint=240 / keyint_min=24 / scenecut=40(pre) / rc=crf / crf=17.9 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
     
  16. Mar 3, 2009 #236 of 297
    txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    Ok, to answer my own question: The mp4 pushes seem to load in 10-15min chunks. The short clips were...shorter than that, so I was not able to watch as they loaded. If I push a longer video, then I can start watching after the first block of time is transferred up.

    Jason
     
  17. Mar 3, 2009 #237 of 297
    moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    Thanks for the info. I'll have to try encoding from a DVD source to see if that's the difference. As Dan mentioned DVD sources have short GOP structure so are probably a better source candidate to begin with. Can you try the same profile on a Tivo SD recording to see how FFx1 looks? In my case FFx1 is not really choppy, but it doesn't appear to be any faster than normal play speed.
     
  18. Mar 3, 2009 #238 of 297
    moyekj

    moyekj Well-Known Member

    11,140
    31
    Jan 23, 2006
    Mission...
    BINGO! I just discovered that it is indeed the S3 H.264 decoder that seems to be the issue. When I play my same H.264 test clips on a Tivo HD unit FFx1 works pretty well. In comparison when playing on my S3s FFx1 doesn't really work at all - it's basically same as play speed.
    So while I'm sure encoding parameters make a difference to some degree the basic problem is that S3 H.264 decoder is just not up to par with the Tivo HD H.264 decoder.

    This holds true for S3 VC-1 decoder vs THD VC-1 decoder as well as there are Netflix streams that play fine on THD units but don't work properly on S3 units.
     
  19. Mar 3, 2009 #239 of 297
    txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    That is an interesting data point. Hopefully that is something that Tivo is aware of and can fix with software.

    Jason
     
  20. Mar 3, 2009 #240 of 297
    Dan203

    Dan203 Super Moderator Staff Member TCF Club

    37,446
    165
    Apr 17, 2000
    Nevada
    That is very strange.

    FYI: The length of the GOPs in the source MPEG-2 file should not effect the output H.264 file in anyway. The encoder has to decode the source file to raw video frames before reencoding, so the structure of the source file never comes into play. However the framerate and whether or not the source is interlaced can effect the output file. So those are the things you should probably look at when trying to figure out why one file works OK and another does not.

    Dan
     

Share This Page