VideoHelp Forum
+ Reply to Thread
Results 1 to 19 of 19
Thread
  1. Hi to all!

    I am using TMPEG Video mastering works 5 (latest version) to create MP4s using x264. They are encoded in CBR, ca. 1.6mbps and apart from that I use mainly settings from a standard given preset. These MP4s are the source files for a Wowza Server packaging them into TS for HLS streaming.

    PROBLEM: Playback on iOS7 (and iOS8) does not start properly. Audio starts playing back but picture starts with a freeze frame of the beginnig of the second TS chunk. Only after ca. 10 seconds, when the start of the second chunk is reached, video joins in. Also, when seeking through the vid the behaviour is similar. in IOS6 the playback seems OK.

    The tests I conducted came to the conclusion that there is an issue with the H264 encoding. I tested several other encoders (Handbrake, Xmedia Recode, etc.) and they all playbyck fine using just random settings. Remuxing the mp4s from TMPEG with such tools does not solve it, too. Also, when I use a different codec in TMPEG the problem vanishes. Unfortunately I canīt use them in general because they degrade quality and/or are way too slow.

    Using the Elecard Stream eye tools the only manifest difference I could find is a buffer overflow which is kind of extreme (see att., this is just for a chunk of 10s) Apart from that the mp4s look very much the same like from the other encoders. I suspect the issue has sth. todo with rate control or buffering. In TMPEG I can adjust the VBV buffer size (is set to Automatic, resulting in a buffer size of ca. 1s of the bitrate) and the VBV filling rate, which is set per default to 90%. Adjusting these values also did not solve the problem.

    Please post your ideas!
    Thx in advance!
    Attached Thumbnails Click image for larger version

Name:	buffer-overflow.PNG
Views:	210
Size:	27.5 KB
ID:	25777  

    Quote Quote  
  2. That is really confusing since:
    • x264 doesn't have a cbr mode.
    • x264 encoding should be normally equally fast independent of the GUI speed.
      Differences should only come from decoding, filtering differences, assuming the encoding settings are the same.

    PROBLEM: Playback on iOS7 (and iOS8) does not start properly. Audio starts playing back but picture starts with a freeze frame of the beginnig of the second TS chunk. Only after ca. 10 seconds, when the start of the second chunk is reached, video joins in. Also, when seeking through the vid the behaviour is similar. in IOS6 the playback seems OK.
    After or before packaging them using Wowza Server ?
    Quote Quote  
  3. Hi Selur,
    thx for your answer. To clarify:

    x264 doesn't have a cbr mode.
    Well, as I read it has several options to restrict datarate. In TMPEG I get the option "CBR" and indeed it limits quite strictly to the adjusted value. Unfortunately, this cannot be the only reason for the problem as I also tried encoding in VBR which did not solve the problem.

    x264 encoding should be normally equally fast independent of the GUI speed.
    In TMPEG you can choose between x264, CUDA or Intel Media SDK codec of which the latter ones are not useable, for ex. because of speed.

    After or before packaging them using Wowza Server ?
    What I described only affects playback on iOS7/8 devices that playback the final HLS stream. Playback of the native MP4 files on PC or in browser players is fine.
    Quote Quote  
  4. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Is there a way to look at the command line that was actually passed in TMPGEnc ? (There might be a disconnect between the GUI and the actual parameters passed) Can you look for a log file? Or can you manually enter values? What was the --vbv-maxrate value? The reason is x264 won't violate buffer restrictions according to buffer analyzers when you use the CLI . Or better yet , test the CLI version.

    There can be other reasons for playback issues - certain settings are known to cause issues on certain platforms and devices. What was the full command line ?
    Quote Quote  
  5. Hi poisondeathray,
    thanks for your answer,
    unfortunately I cannot get between TMPEG and x264 to find out how the job is created exactly. Iīve mailed support though, maybe I overlooked sth.

    What I can reason from the GUI settings and help documents is that the VBV parameters I have access to are:
    --vbv-bufsize
    This is set to automatic and results in a buffer size of exactly 1s x declared bitrate of the vid.

    --vbv-init (falsely declared as "VBV default buffer filling rate", should be "sets how full the VBV Buffer must be before playback starts")
    Set to 90% per default. You can see that in the buffer analyzer. When you change the value there is a knee at the respective position in the curve, meaning the buffer starts emptying.


    I donīt find anything in the GUI that might have an influence on this parameter:
    --vbv-maxrate

    In the meantime I also tested a VBR version of the same video to see if this solves the problem with HLS playback. Unfortunately it does not, although the buffer behaviour seems kind of normal (see 2nd picture)

    Maybe you could give me some more hints which factors could affect playback in that way I originally posted. Do you think the buffer/bitrate behaviour is a hot lead in this respect?

    Cheers
    Attached Thumbnails Click image for larger version

Name:	buffer-behaviour-with-VBR.PNG
Views:	20
Size:	25.8 KB
ID:	25823  

    Quote Quote  
  6. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Obviously the problem is TMPGEnc's implementation of x264 , or the settings used - since handbrake, xmediarecode etc... which also use x264 playback fine

    You need to examine the log file or the actual parameters passed , or why not just use one of the other many GUI's for x264 instead of TMPGEnc until they resolve the issue (or even learn to use the commandline) ?

    You can use mediainfo (view=>text) on the encoded file, and it will provide some of the information of x264 encoding settings used. Compare that to the ones done by handbrake etc... It doesn't contain all the info, a log file would be better, but still will give you more clues

    I would make sure GOP's are closed, and follow quicktime compatibility settings suggestions, and don't use long strings of b-frames
    http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#QuickTime-compatible_Encoding

    --ref 4 --qpmin 4 --bframes 3

    Long GOP intervals can be problematic with seeks (usually only slow seeking) , so limit the max keyframe interval size as well. This varies by device or platform, but the shorter the interval, the more it potentially adversely affect compression as well. A good compromise might be 2 second intervals (e.g. 30fps source would use --keyint 60)

    Sometimes the container can cause problems, the major brand and type (e.g. MP42 vs. ISOM for MP4 container) . But usually there is no playback at all if this is the case, I doubt this is the problem
    Quote Quote  
  7. Hi there,
    thanks for your help! I already did a lot of testing, for ex. with keyframe interval, GOP, etc. Unfortunately there was no solution in this direction and exactly thatīs what makes it kinda tough. Also what did not work is remuxing the mp4 from TMPEG with Xmedia or Avidemux, so it is not about the container.

    As you can see in the parameters I extracted below, there is hardly a difference between handbrake, Xmedia Recode and TMPEG in this respect. I found the following to be the most outstanding ones. But none of them gives me a good lead, I checked here:

    constrained_intra=1 (vs. 0 in handbrake/Xmedia)
    b_bias=60 (vs. 0)
    scenecut=0 (vs. 40)
    rc=cbr (vs. abr, 2pass)
    nal_hrd=cbr (vs. none)

    Btw- what do you make out of the buffer behaviour? I canīt really tell the significance of it nor if this might be the cause of the prob.

    The problems only occur when the Vids are being segmented into TS for HLS and played back on iOS7/8. As segmenting happens with Wowza there might be just a tiny incompatibility. We fed Wowza MP4s from many encoders with various settings and they all work fine. Just not the ones from TMPEG..

    I am using TMPEG because it is a handy tool to create jobs, i.e. doing a little editing, cropping, scaling, inserting subtitles with good preview function and batch operation I donīt have to program I am kind of stuck to it so thatīs why I have to find this out..

    Cheers
    ###############################################
    Handbrake:
    x264 core 112
    cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=912 / ratetol=1.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00


    Xmedia Recode:
    x264 core 142 r2409
    cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=25 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=43 / intra_refresh=0 / rc_lookahead=60 / rc=abr / mbtree=1 / bitrate=1500 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=69 / qpstep=4 / vbv_maxrate=24000 / vbv_bufsize=24000 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00


    TMPEG Mastering Works 5 Version. 5.5.0.105
    x264 core 136
    cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.10:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=2 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=1 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=1 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=60 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc_lookahead=60 / rc=cbr / mbtree=1 / bitrate=1600 / ratetol=1.0 / qcomp=0.80 / qpmin=11 / qpmax=65 / qpstep=4 / vbv_maxrate=1600 / vbv_bufsize=1600 / nal_hrd=cbr / ip_ratio=1.40 / aq=1:1.20
    Quote Quote  
  8. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    buffer shouldn't be an issue because your VBR encode within limits exhibits the same playback problems

    But something is wrong if that mediainfo report is accurate, and if it is the same one for the the 1st screenshot for the buffer analyzer. Can you post a stream copy segment of the source file, perhaps the 1st 20 seconds ? Basically I've never seen any current x264 version violate VBV restraints, all the bugs have been worked out on that AFAIK

    Does this playback occur with other source videos ? (try some other videos)





    cqm=2
    Not sure if this is the reason for the buffer issue , or the Wowza issue, but the TMPGEnc encode uses a CQM (custom quantizer matrix), try disabling that. Basically AQ has made the usage of CQM's obsolete, there might be some incompatiblity going on

    Notify TMPGenc and Wowza, they might already be aware of the issue, and might already have a workaround or fix
    Last edited by poisondeathray; 19th Jun 2014 at 10:25.
    Quote Quote  
  9. Hi Poisondeathray,
    I could provide you with anything you want but please specify

    - segm. of the source file from which the mp4s are encoded (usually an MPG2 PS)
    - segm. of the resulting TMPEG/mp4 which will be used as input for Wowza
    - one of the final .TS segments that Wowza outputs

    The first screenshot of the Buffer analyzer relates to one of the final TSs. What is your theory?

    Cheers
    Quote Quote  
  10. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Try without CQM first. If that doesn't resolve issue, upload all 3 of them, 20s of each

    Not sure what to make of it. I'm inclined to blame Wowza, but that doesn't explain why it would work when the same process is done with handbrake
    Quote Quote  
  11. Hi there,
    so I uploaded a zip with
    - source .mpeg (Xmedia Recode out)
    - inter .mp4 (TMPEG out)
    - final .TS (Wowza out, 3 first chunks)

    also:
    - buffer analysis of the first chunk, others look almost the same

    I am very curious what you find out. Actually I also tried using Elecard Stream Analyzer, which is a nice tool but did not have any clearcut findings.

    Cheers and thanx
    Attached Images  
    Attached Files
    Quote Quote  
  12. btw.: display on for ex. current ipad shows a freeze frame of the beginning of the second chunk with audio already playing back. After the vid has reached the 2nd chunk it plays back normally.
    Quote Quote  
  13. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    1) To reiterate, it's unlikely that the buffer violation is the culprit for playback issues you describe, because post#5 with the VBR version without overflow issues still exhibits the same playback problem. So I think those are separate issues.

    2) But x264 shouldn't be violating VBV restrictions at all - that suggests there is something wrong with TMPGEnc's x264 implementation. So could there possibly be other problems as well? Also since handbrake etc... work fine. The difference in settings that jumps out that I can see might be contributing is the CQM. Did you try disabling that yet? The other differences in settings shouldn't matter that much

    3) There are issues with the wowza split sections - certain decoders have problems playing them back properly, yet have no problems playing the TMPGEnc precursor. That suggests problem is wowza splitting .


    But what is causing wowza to fail with TMPGEnc encodes, but not handbrake etc.... Can you upload a handbrake version, and the resultant wowza splits ?


    This doesn't affect playback issues you describe, but as an aside, you should be IVTCing film sources in your workflow. The frame rate should be 24p, not 29.97, where every 5 frame is a duplicate . Not only does it harm compression (20% more frames to encode) , it produces jerky playback
    Quote Quote  
  14. Hi there,
    nice you know the business
    IVTCing would be a good idea in this case. But I just made a quick one.. usually our NTSC source material is natively interlaced..
    I will try tweaking the QMs and get back to you.
    Thanks for your input!
    Quote Quote  
  15. Hi poisondeathray,
    sorry, no luck with changing cqm to 0. Same issue.
    Next week I will upload a package that is working with Handbrake mp4s.
    Have a nice weekend!
    Quote Quote  
  16. Hi there,
    here is one more attempt to shed light into this.

    I attached a handbrake mp4 version of the same source with whatever settings, and the respective .ts from Wowza. Of course these run perfectly on iOS7.

    Also I tried tweaking TMPEG again, matching the x264 settings from handbrake and Xmedia Recode. Of course, it does not solve the problem. Below you find the parameter set.

    Differences remain in
    slices=1 (vs. not set)
    nal_hrd=vbr (vs. none/ not set)

    x264 core 136
    cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=1 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=1600 / ratetol=1.0 / qcomp=0.60 / qpmin=11 / qpmax=65 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=1700 / vbv_bufsize=1700 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00

    Anymore ideas?
    Attached Files
    Quote Quote  
  17. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    I'll have a look at it later, but slices and nal hrd shouldn't make a difference to how wowza handles the file
    Quote Quote  
  18. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    I would avoid using TMPGEnc until they fix their x264 implementation . Their modified x264 appears to be broken. If you enter the same values on the same source (no IVTC) - there is no buffer overflow with x264 CLI . Although the buffer issue probably doesn't itself lead directly to ios playback issue (since the TMPGEnc VBR encode was within limits adn playback still had issues) , it is possible there are other issues introduced since their modified x264 doesn't behave like standard x264 used in CLI , handbrake, etc. etc...

    I don't use TMPGEnc, can you find their x264.exe and upload it ?
    Quote Quote  
  19. Hi there,
    well, yeah, I think youīre right, they customized x264 in a bad way. There is no x264.exe but TMPGEncVMW5Encoder.exe.
    Itīs not really good PR for their product, especially as their support is not responsive to our request!
    If you still think itīs worth exploring, Iīd mail it to you!
    Cheers and thx. for your input!
    Quote Quote