VideoHelp Forum
+ Reply to Thread
Page 2 of 3
FirstFirst 1 2 3 LastLast
Results 31 to 60 of 77
Thread
  1. There is no sync issue on the longer sample in PM - it was a false alarm (from the edited version you posted earlier where you cut the middle) . It seems fine when re-encoding with directshow ...or other methods too.

    Now I'm wondering if we are seeing the same thing ? What do you mean exactly by "3 frames missing ?" I hope you're not referring to the crossfade and the end of the DJ into Ellen ? Or do you have a clip that you re-encoded that shows the problem ?
    Quote Quote  
  2. Trust me. Remux that file that I initially posted and play it back with vlc. 3 frames are gone. It's like the dj has his hands out to clap and then they're suddenly together.
    Quote Quote  
  3. Yes, I saw that with remuxing with tsmuxer - we are past that discussion. Directshow players had no problems. But in some players, there was a pixellation at that spot, not missing frames - eitherway something is wrong with certain decoders handling that remuxed stream.

    But now I'm talking about re-encoding. You're going to have to do that anyways for BD since these are non compliant. Earlier you said you tried re-encoding (even without b-pyramid) and got the same thing
    Quote Quote  
  4. I tried reencoding but the three frames were still missing from both programs that I tried to encode with.

    And, no, I have no problem authoring with these files other than the aforementioned skip. I've been doing it for years
    Quote Quote  
  5. Can you upload a small clip of one of the problem re-encodes ? This will help identify where your problem is (probably decoding)
    Quote Quote  
  6. Originally Posted by poisondeathray View Post
    Can you upload a small clip of one of the problem re-encodes ? This will help identify where your problem is (probably decoding)
    I'm so confused. The problem that I have with the reencode is the exact same problem that I have with the edited file. It skips those three frames. Both programs read it the exact same way.
    Quote Quote  
  7. ok I don't see the problem when re-encoding. I'm assuming we are talking about the same thing, since 3 dropped frames is easy to see. Especially if you go frame by frame afterwards to double check

    I didn't use tmpgenc to encode. The first time I used avisynth with DirectShowSource() and ffmpeg to encode. The 2nd time I skipped avisynth and used ffmpeg directly (so decode and encode, not through directshow)

    I suspect this is all related to the open GOPs. Open gop's are good for compression efficiency and quality, not so good if you intend to edit . It's more of a final distribution choice, not acquisition choice . If you do a quick search many people seem to have problems with thse streams in all types of software . It's just that some programs/ decoders have problems with open GOPs in AVC streams , maybe tmpgenc is one of them
    Quote Quote  
  8. Forget reencoding. What about muxing? What happens to the file between its original state and after it gets muxed?
    Quote Quote  
  9. Download and check this . I bob deinterlaced, and resized to SD to keep the filesize down. I don't see any dropped frames, it's in sync. It plays fine in all players: vlc, mpchc, potplayer, etc...

    The purpose is to see if it's DEcoded correctly before encoding. Or maybe there is something else you are referring to that I'm missing ?
    Image Attached Files
    • File Type: mp4 2.mp4 (7.55 MB, 120 views)
    Quote Quote  
  10. Originally Posted by digitalfreaknyc View Post
    Forget reencoding. What about muxing? What happens to the file between its original state and after it gets muxed?
    You're going to have to re-encode for BD anyways. And didn't you want to "fix" this problem for your videos ? SO that it will be handled in anything, any software, any hardware without issues ?

    If you authored them as-is in the past - probably you did have other problems authoring and didn't realize it . It might just be you have a strong BD player that can handle anything , even non compliant streams. Basically these won't play properly on some BD players
    Quote Quote  
  11. Right. That's what I'm saying. Its not being decoded correctly. Once it hits tsmuxer (via multiavchd, which is my authoring program), I'm screwed. Ultimately, I'd like to figure out what the Hell vrd is doing to the files so I don't have to encode everything
    Quote Quote  
  12. Originally Posted by poisondeathray View Post
    Originally Posted by digitalfreaknyc View Post
    Forget reencoding. What about muxing? What happens to the file between its original state and after it gets muxed?
    You're going to have to re-encode for BD anyways. And didn't you want to "fix" this problem for your videos ?

    If you authored them as-is in the past - probably you did have other problems authoring and didn't realize it . It might just be you have a strong BD player that can handle anything , even non compliant streams. Basically these won't play properly on some BD players
    I have 2 ps3's, I make discs for family members and sell videos all around the world. Never had any problems whatsoever. What problems would I run into? Does the short concert file that I uploaded initially have open GOP's? If so, that means that's how the Hauppauge records. Nothing I can do about it
    Quote Quote  
  13. Yes, that's sort of the whole point of using videoredo, the smart editing part...

    But your HDPVR streams are non compliant to begin with - you shouldn't be authoring without re-encoding in the first place. Any decent authoring tool will reject them for pass through and force a re-encode . But the the truth is many BD players can play non compliant streams, especially newer models. One the other hand , there are some players that will for sure have problems. You will see stuttering and some may flip back to the menu. That' s the reason why there are "standards" . You don't want to make something (especially not for commercial use) that is broken. That's why professional authoring tools have some sort of error checking at multiple stages. And decent authoring tool will reject these streams right away on import
    Quote Quote  
  14. Originally Posted by poisondeathray View Post
    Yes, that's sort of the whole point of using videoredo, the smart editing part...

    But your HDPVR streams are non compliant to begin with - you shouldn't be authoring without re-encoding in the first place. Any decent authoring tool will reject them for pass through and force a re-encode . But the the truth is many BD players can play non compliant streams, especially newer models. One the other hand , there are some players that will for sure have problems. You will see stuttering and some may flip back to the menu. That' s the reason why there are "standards" . You don't want to make something (especially not for commercial use) that is broken. That's why professional authoring tools have some sort of error checking at multiple stages. And decent authoring tool will reject these streams right away on import
    But, again, I'm not having a problem with that. Zero complaints. The only issue I'm having is the skip, which I'm trying to solve
    Quote Quote  
  15. You solve it by re-encoding it. If you don't want to re-encode, good luck with that ....

    You're lucky not to have any complaints. Seriously.

    Does the short concert file that I uploaded initially have open GOP's? If so, that means that's how the Hauppauge records. Nothing I can do about it
    Yes, I already mentioned that earlier.

    You have the option to get something else to record
    Quote Quote  
  16. Why was the open-GOP problem not mentioned by VRD?
    What other capture cards will let you record encoded channels with 5.1?
    What user-friendly programs are out there that I can use to re-encode that won't include the skip?
    Quote Quote  
  17. I reproduced the issue that digitalfreaknyc was talking about and I think he will not solve this as long as he is using TSmuxer or original Hauppauge recorded video.

    Here's what I did and the results I got:

    Scenario 1:

    Loaded "testingdigi.ts" in VRD. There, it says entire output is 00:00:14.16 (14 seconds, 16 frames)

    Saved the file in new TS with VRD. In status I saw it decoded some frames and in the end it reported: Max PTS underflow (ms): 220
    In VRD log it also mentioned PTS underflow and also that it recoded 11 frames.

    I load this new TS file in VRD and on output it now says 00:00:14.15 (14 seconds, 15 frames)

    I go to IDR frame at 00:00:01.18 and from there the sequence is this: b,b,p,b,b,b,IDR (no jump)

    I mux this new ts with tsMuxer and open it in VRD

    I go to same IDR frame at 00:00:01.18 and from there the sequence is this: b,b,p, IDR (visible jump, missing frames)


    Scenario 2:

    I did the same thing like before but this time I mux TS in mkv (or mp4) This time, no message about Max PTS underflow.
    In VRD log again it says that it recoded 11 frames. All frames are there from 00:00:01.18.

    Once I mux this with tsMuxer the same thing happens, 3 frames are missing.

    So that guy from VRD probably told you the truth, something about overlapping time stamps that maybe isn't allowed in TS if the Open GOP is used. But then again VRD's TS muxer is keeping all frames so I'm not sure what's going on. Maybe it's bug in tsMuxer?

    Maybe the only solution is the complete recode but this time using Closed GOP, I don't know.

    Digitalfreaknyc, are you using the new VRD (version 5) or 4? I find that the 5 solved ALL issues that I had with 4 when i was dealing with TV recordings that use Open GOP. Before it was impossible to cut the file without some kind of glitch or small error. Now with v5 everything is perfect.
    Quote Quote  
  18. I had a closer look, and I agree VRD is technically doing anything wrong.

    It looks like it is using different settings (deblocking diabled) - so it's easy to identify which frames were processed. (You're allowed to use different settings between different GOPs limited by IDR's - that's not a problem) . The section re-encoded with VRD is only up to the middle of the DJ section. It stops before a true IDR frame and the rest is untouched . After that section - that's the original PVR stream - that includes that section with the end of the DJ. Theoretically , since this is a new GOP, nothing VRD has done before that should affect this section

    You can try to use a better muxer, but no BD compliant muxer will touch it because it's not compliant in the first place
    Quote Quote  
  19. Originally Posted by badyu17 View Post

    Digitalfreaknyc, are you using the new VRD (version 5) or 4? I find that the 5 solved ALL issues that I had with 4 when i was dealing with TV recordings that use Open GOP. Before it was impossible to cut the file without some kind of glitch or small error. Now with v5 everything is perfect.
    First off, thank you very much for joining the extremely helpful "poisondeathray" in trying to figure out wtf is going on with my files.

    Yes, I do have the new version of VRD and have been using it since it came out. Still have the same problems.

    The thing I don't understand is how I'm the only person using the Hauppauge who is having this problem. Or am I the only one who is noticing this problem? Not re-encoding has been a priority for me since I want to ensure the highest quality that I can muster.

    At this point, I'm at a total loss. TSmuxer is a core program for multiavchd, which is one of the few (only?) programs that doesn't re-encode when files are authored. That's why I chose it. Yes, it's simplistic but it certainly gets the job done.

    I guess the other question is the one that PDR brought up about a directshow decoder. What professional encoding programs out there utilize that decoder? Right now, my entire workflow is being torn apart and I'm frustrated.
    Last edited by digitalfreaknyc; 27th Jun 2015 at 11:57.
    Quote Quote  
  20. Originally Posted by digitalfreaknyc View Post

    The thing I don't understand is how I'm the only person using the Hauppauge who is having this problem. Or am I the only one who is noticing this problem?

    Hauppauge streams are buggy in the first place . Not just this model, but others as well. You're not the only one. Maybe you're the only one reporting this specific problem, but there are other problems. Just search and there are many posts about various problems with these streams in other programs

    Not re-encoding has been a priority for me since I want to ensure the highest quality that I can muster.

    If no re-encoding is a priority you need a device that records compliant BD streams. I don't know what options are out there



    At this point, I'm at a total loss. TSmuxer is a core program for multiavchd, which is one of the few (only?) programs that doesn't re-encode when files are authors. That's why I chose it. Yes, it's simplistic but it certainly gets the job done.

    ALL authoring tools don't re-encode compliant streams. This is true for every single one of them, blu-ray or dvd. Strictly speaking, "authoring" has nothing to do with encoding. So a pure authoring tool can't encode . But if multiavchd was updated, it would re-encode this because it's not compliant.

    You enjoy using multiavchd and tsmuxer because they allow you to author non compliant discs. Other tools won't allow you to make problematic discs because of the error checking


    I guess the other question is the one that PDR brought up about a directshow decoder. What professional encoding programs out there utilize that decoder? Right now, my entire workflow is being torn apart and I'm frustrated.
    Totalcode (Rovi / Mainconcept) can, but it might be difficult to force a certain decoding pathway (it might prefer to use something else)

    I'm not up to date on all the current GUI's but freeware like megui, xvid4psp can be configured to use directshow. Megui isn't the easiest to use. And again , if you are going to re-encode, you should do it with proper BD compliant settings - that way it will pass any authoring tool check. This is discussed extensively elsewhere and other threads if you want more info

    Directshow can be problematic too, if you don't configure it properly. It relies on system installed splitters and codecs - so if you have something misconfigured....
    Quote Quote  
  21. @digitalfreaknyc

    I never used multiavchd but I know about the program and that it uses tsMuxer to generate file/folder structure with menus (?) I only used tsMuxer directly to generate either avchd or blu-ray folder a long time ago. I know that it creates m2ts files. Can you try to re-use folder structure that multiavchd created and switch the created m2ts (from tsMuxer) with the one created by VRD as the VRD can also create m2ts without re-encoding.
    Quote Quote  
  22. Originally Posted by badyu17 View Post
    @digitalfreaknyc

    I never used multiavchd but I know about the program and that it uses tsMuxer to generate file/folder structure with menus (?) I only used tsMuxer directly to generate either avchd or blu-ray folder a long time ago. I know that it creates m2ts files. Can you try to re-use folder structure that multiavchd created and switch the created m2ts (from tsMuxer) with the one created by VRD as the VRD can also create m2ts without re-encoding.
    That is a VERY good idea and something I can try. Thank you!

    I know that you guys are getting very hung up on the open GOP thing but, thus far, that has not been a problem at all. Unless the open-GOP relates to the skip in frames, it really doesn't affect this situation, as I'm dealing with it right now. My bigger issue is what to do with all of the movies/files that I have already authored. I guess it's a possibility to take the first 5 seconds of each one and re-encode and then merge the first and second parts...unless that will just move the 3-frame-jump further into the file.

    I just want to start fresh, going forward, and know how to handle this issue.
    Quote Quote  
  23. Muxing with ffmbc into m2ts doesn't cause the 3 frame drop, when previewed in videoredo . Not sure how that helps you , because if you use tsmuxer or multiavchd to author afterwards - it will come back . Maybe you can just replace the .m2ts in the stream folder, or try some other manipulations but it will probably cause other issues

    e.g.

    ffmbc -i testingdigi.ts -vcodec copy -acodec copy -f mpegts ffmbc.m2ts
    Quote Quote  
  24. Originally Posted by poisondeathray View Post
    Muxing with ffmbc into m2ts doesn't cause the 3 frame drop, when previewed in videoredo . Not sure how that helps you , because if you use tsmuxer or multiavchd to author afterwards - it will come back . Maybe you can just replace the .m2ts in the stream folder, or try some other manipulations but it will probably cause other issues

    e.g.

    ffmbc -i testingdigi.ts -vcodec copy -acodec copy -f mpegts ffmbc.m2ts
    Is there anything with a GUI? The problem with all of the programs you're recommending is that I don't understand line commands at all.
    Quote Quote  
  25. Not sure about GUI's for it, maybe selur's hybrid ? I'm not up to date on all the GUI's

    If you place a copy of ffmbc.exe in the directory of .ts to be converted (just try with 1 .ts for now) , and place this batch file "ts_ffmbc_to_m2ts.bat" (unzip it and place in the same folder) , double click the .bat, it will use ffmbc to re-wrap all the .ts files in the directory to .m2ts using ffmbc.
    Image Attached Files
    Quote Quote  
  26. Originally Posted by poisondeathray View Post
    Not sure about GUI's for it, maybe selur's hybrid ? I'm not up to date on all the GUI's

    If you place a copy of ffmbc.exe in the directory of .ts to be converted (just try with 1 .ts for now) , and place this batch file "ts_ffmbc_to_m2ts.bat" (unzip it and place in the same folder) , double click the .bat, it will use ffmbc to re-wrap all the .ts files in the directory to .m2ts using ffmbc.
    Unfortunately, even THAT made no sense to me.
    Quote Quote  
  27. I've been experimenting all night and here's some food for thought (or not)...

    In trying DGAVCDec, I'm able to demux a file even after it's been screwed up with TSmuxer and get it back to its original state. Meaning, I could theoretically throw it into TMPGENC or any other encoding program and re-encode. But it still proves that the frames are there and that the files are salvageable. It's just figuring out how the hell to fix it.
    Taking the raw files created by DG, I can remux into MKV using MKVToolNix. Unfortunately, that doesn't fix the problem because if I go back to tsmuxer from there, I'm still screwed.

    Oddly enough, people were talking about DGAVCDec dropping 3 frames about 4 years ago because of videoredo.
    http://forum.doom9.org/showpost.php?p=1647773&postcount=2957
    Last edited by digitalfreaknyc; 28th Jun 2015 at 01:53.
    Quote Quote  
  28. You just encode it like I mentioned earlier with directshow decoding (or any method that isn't prone to the framedrop problem)

    Videoredo is one of the programs that is sensitive to , and decodes with the problem (as opposed to some directshow players , so you can videoredo to check to see if problem exists)

    I verified this with blu ray compatible encode settings for a 10sec test and "authored" with tsmuxer, and there are no frame drops in videoredo in the 00000.m2ts file.

    I like your earlier idea - if only the beginning is affected, then maybe a smarter way is just to encode a beginning section then append. But if you had multiple edits all over, this might be tedious to do, I would just re-encode the whole thing

    I would do it with non smart rendering (ie. cut on keyframes, GOP boundaries on IDR frames) . However, the potential problem is many programs misidentify "i" non-IDR frames with IDR "I" frames. This causes big big problems. For example ffmpeg based programs. It would be safer to encode the whole thing in that case
    Image Attached Files
    Quote Quote  
  29. Originally Posted by poisondeathray View Post
    You just encode it like I mentioned earlier with directshow decoding (or any method that isn't prone to the framedrop problem)

    Videoredo is one of the programs that is sensitive to , and decodes with the problem (as opposed to some directshow players , so you can videoredo to check to see if problem exists)

    I verified this with blu ray compatible encode settings for a 10sec test and "authored" with tsmuxer, and there are no frame drops in videoredo in the 00000.m2ts file.

    I like your earlier idea - if only the beginning is affected, then maybe a smarter way is just to encode a beginning section then append. But if you had multiple edits all over, this might be tedious to do, I would just re-encode the whole thing

    I would do it with non smart rendering (ie. cut on keyframes, GOP boundaries on IDR frames) . However, the potential problem is many programs misidentify "i" non-IDR frames with IDR "I" frames. This causes big big problems. For example ffmpeg based programs. It would be safer to encode the whole thing in that case
    I could actually use any program now, since, like I said, TMPGENC now recognizes all frames. However, it's absolutely ridiculous that I have to re-encode everything that I record with the Hauppauge. Like...seriously?? That's just insane!

    Also, I tried re-encoding the first 30 seconds of that file last night and leaving the rest "as is." Every program that I tried to play it back on went absolutely nuts.

    I'm going to try authoring and replacing the files with the original M2TS today, burning a few BD-RE's and seeing how that turns out.
    Quote Quote  
  30. Originally Posted by digitalfreaknyc View Post


    I could actually use any program now, since, like I said, TMPGENC now recognizes all frames. However, it's absolutely ridiculous that I have to re-encode everything that I record with the Hauppauge. Like...seriously?? That's just insane!
    It's not "insane" in my perspective - The files aren't blu-ray compliant to begin with - they never made that claim. If you didn't need blu-ray , you wouldn't need to re-encode it. The videoredo output files play fine. You wouldn't need multiavchd, tsmuxer, etc... thus no problem.

    Also, I tried re-encoding the first 30 seconds of that file last night and leaving the rest "as is." Every program that I tried to play it back on went absolutely nuts.
    How did you do that ? cut off the 1st bit, re-encode the first bit, then append ? how did you append ? what programs and method exactly ?

    If you didn't segment on IDR boundaries, it's expected that every program will complain
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!