Page 5 of 70 FirstFirst ... 345671555 ... LastLast
Results 61 to 75 of 1041

Thread: MUX'ing, VSplit, and MPG2 files.

  1. #61
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by edpuffmonster
    If I recall correctly, Jdiner's vsplit is based on Warren Toomey's.

    Technically he's violating the GPL by releasing the binaries with no source available. He has repetedly said, however, that he will eventually include the source, so I guess it's not so bad. (his reasoning for not releasing the source yet is arguable, but sound)
    I thought I had addressed this before. But was in another thread. So one more time. My work is all original. (I have no idea who Warren Toomey is but I will look at the link in the above message about his stuff...) That is why it actually works. No slam to previous authors. But there are reasons that nothing else has been as successful. I will release source, but since I wrote it I get to set the time frame.

    --jdiner

  2. #62
    Join Date
    Jun 2001
    Location
    Dallas
    Posts
    588
    and for the record again. Stop friggin whining about source!!!

    It is his code to do with as he pleases. We are all lucky that he is contibuting his time and effort to make the tools AND also making them available for us to use. It is his CHOICE to do this and he could have just as easily made tools for himself and never bothered with the rest of us.

    So once again let it drop, move on, find something else to talk about.

    If you want source so bad, write your own.
    Information wants to be free....

  3. #63
    Join Date
    Jan 2002
    Posts
    311
    Originally posted by KRavEN
    and for the record again. Stop friggin whining about source!!!

    It is his code to do with as he pleases. We are all lucky that he is contibuting his time and effort to make the tools AND also making them available for us to use. It is his CHOICE to do this and he could have just as easily made tools for himself and never bothered with the rest of us.

    So once again let it drop, move on, find something else to talk about.

    If you want source so bad, write your own.
    To heck with the source... I WANT A PONY!!!
    -- digitalAir

    1 DSR6000R (35 hour) currently running Xtreme 3.1 and tivonet

  4. #64
    Join Date
    Mar 2002
    Location
    Asylum
    Posts
    85
    Originally posted by KRavEN
    and for the record again. Stop friggin whining about source!!!
    It is his code to do with as he pleases.
    Narf. If it were based on GPL'd code, as I thought I had read, people would have every right to whine about it :P

    Stop friggin whining about my whining!

    Besides, it's fun to pretend I'd actually do something with the source if I had it.

  5. #65
    Join Date
    Jan 2002
    Posts
    4,809
    The only portion of anything that I have written that is based on GPL code. Is the mfs_stream program. It's source has been released.

    I suppose in that light the server portion of the TyTool also contains the same code. However it is just the mfs_stream code run in a secondary thread. i.e. no changes to the source. But I suppose I should release that server source.

    I dunno if anyone is interested in that part or not. Litterally it is a small parser with some socket code...

    --jdiner

  6. #66
    Join Date
    Jan 2002
    Posts
    4,809
    Oh man. Well that explains why I could not fix it. The TyStream file itself on one of the recent bad clips I was sent is actually wrong. This is a first for me. Never seen one where it is simply wrong before.

    Having decided on that. I have removed it from my test pool. There is nothing at present that I can do about a bad tyStream file. When it is corrupt it is over...

    Having said that it means I can remove the latest debug code and re-run the latest testbed and if all is well the next version of vsplit will be ready to roll...

    --jdiner

  7. #67
    Join Date
    Feb 2002
    Posts
    363

    vsplit

    What features will the new version contain? How will a person know if the tystream is bad or the cause of problems.

    THANKS

  8. #68
    Join Date
    Aug 2002
    Posts
    260
    jdiner:

    Excellent. Can't wait.

    Do you think the tystream as it exists on the TIVO is bad, or is it a rare problem with etraction? (i.e., could it be "fixed" by re-extracting the same program).

  9. #69
    Join Date
    Jan 2002
    Posts
    4,809

    Re: vsplit

    Originally posted by RxMan
    What features will the new version contain? How will a person know if the tystream is bad or the cause of problems.
    From the types of errors. If things get off and stay off all the way through that is a TyStream file error. If it is a -1x4 error report then those should now be fixed.

    I can't tell if it is a bad extraction that is the problem with this one clip that I have or if it is something else. But the file itself is smashed. No way to recover and keep going. The "key" to seeing this is in getting a "fix it dear henry" message. This message is displayed if a header shows up for decoding with a totally wrong header type. I.e. we want time and position information on something that is neither audio nor video data. As evidenced by the current "bad" clip.

    Think of it this way. Inside the TyStream file things line up like this:

    Rec 1 ----> VHeader ----> 16 bytes
    Rec 2 ----> VBody ----> 7000 bytes
    Rec 3 ----> VHeader ----> 16 bytes
    Rec 4 ----> VBody ----> 7000 bytes
    Rec 5 ----> AHeader ----> 16 bytes
    Rec 6 ----> ABody ----> 480 bytes

    Now these sizes made up to some extent. I have seen video records as large as almost 128k bytes.

    Things that are "always" the case. A header record points to header data, and a body record points to body data.

    Now in going through this new "really bad" clip this is the case to a certain point in the file. (In everything else I have this is always the case...) Then suddenly this is not the case. Where the header records point is suddenly and inexplicably body data. Something like this:

    Rec 1 ----> VHeader ----> 16 bytes
    Rec 2 ----> VBody ----> 7000 bytes
    Rec 3 ----> VHeader ----> 16 bytes
    Rec 4 ----> VBody ----> 7000 bytes + 16 bytes of the next header + 42 bytes of the next body.
    Rec 5 ----> AHeader ----> 16 bytes of the next body.
    Rec 6 ----> ABody ----> 398 bytes of this body. The 16 for the next header, and then some of the body after it.

    I have checked and rechecked my code and manually gone through the problem chunk by hand. And it is not a calculation errors the TyStream information itself is simply wrong.

    Anyway it continues like this. Once off it stays off for several chunks. Things eventually appear to line up. But there is no way to maintain sync in the current form. We have a hole and there is nothing reasonable that can be automated to fix/find these holes. I would have to "restart" the mechanism and build a new set of files once things are back on track in the TyStream file. This is possible just very time consuming.

    I am not going to do that at this point. For several reasons:

    1- This is the one and only case that I have seen myself where this happened. I can't explain it but I do know from history that it is rare.

    2- Why bog down in a fixes for such a rare case when we can move on with the mainstream things.

    3- While I do have time now it is limited and as a result I have to prioritize.

    I hope this clears a few things up. I do wonder what happened to the Tivo it was occuring on to make it happen...

    --jdiner
    Last edited by jdiner; 09-06-2002 at 01:12 PM.

  10. #70
    Join Date
    Jan 2002
    Posts
    4,809
    Ok. A simple poll. There is a choice facing me right now and it affects most of the rest of you so I want some feedback.

    I am working on the mux'ing as most of you know. Plain and simple right now I am having problems. I think I have it hammered it out and then something else breaks. So this could take awhile.

    Now having said that I have in playing just fine as an mpeg right now. But the editing of them is still smashed.

    Now I can either spend my time trying to get "busted in the same way" as something else and in so doing get back on track for editing via another program. OR I can call it good and start moving on with the rest of this stuff including the editor I have been creating for my own stuff.

    My editor is not a full blown editor. Never will be. What it is is a GOP level editor for the cutting of commercials. When I did it manually some time ago, read months and months ago now, I got it working. A few visual sniggles took place but I have a technique to try to get rid of that. Since it is not a frame level editor it is not nor will it ever really be "perfect". It is possible there will be a few frames on either side that are unwanted.. But it will cut commercials and maintain sync.

    This is "good enough" for me. And it is much much easier to do. Which means that I should be able to get it out the door much sooner than tweaking the dark to get things to a point where the editors out there will like it.

    Ok. So the poll.

    1- Keep going with tweaking the mpeg file output until m2-edit and mpeg2vcr will frame/gop edit the output mpeg successfully.

    or

    2- Keep making the mpeg file play in the most places i.e. software and hardware mpeg-2/dvd players. With our own custom cutting/editing software...

    I was going to ask that people PM me with their suggestiong but this does affect what so many are waiting/hoping for. So let's do it here in this thread. Anyone with an option or a dream chime in. But please keep it civil...

    --jdiner

  11. #71
    Join Date
    Nov 2001
    Location
    USA
    Posts
    118

    poll

    jdiner,

    I'm not sure I fully understand either option, but if it's of any use to you I'd rather have the mux'ing. I have like 50 movies piled up on my Hughes and can't get anything to sync properly not matter how I mux!
    -Bronco

  12. #72
    Join Date
    Aug 2002
    Posts
    260
    Even though I don't have an MPEG-2 editor, I would say #2.

    Getting output of a sync'd and widely playable MPEG-2 file that can be edited by other programs if desired would appear to be a higher priority. Especially if you already have a rough-cut GOP level commercial editor to throw out for optional use.

    That's my opinion, anyway.

    Thanks for all of the effort on this.

  13. #73
    Join Date
    Jan 2002
    Posts
    4,809
    Ok. Perhaps I was not clear enough.

    What can happen here is this.

    Option #1 - Keep working on the generation of the mpeg-2 file. In the hopes that at some point it will work to edit it with one of the commercial editors. Thus at some point something could be done with what is coming out of those to burn to disk. What ever type of disk people are using.

    Option #2 - Do it myself and in so doing forget about ever being compatible with one of the other editors. Thus the ONLY way to ever edit it at that point will be with the internal one I am building. The benefit here is that things are and stay sync'ed even after the cuts have been made.

    --jdiner

  14. #74
    Join Date
    Mar 2002
    Location
    Fort Worth
    Posts
    190
    1- Keep going with tweaking the mpeg file output until m2-edit and mpeg2vcr will frame/gop edit the output mpeg successfully.
    To me, this sounds like you want to create a program stream that any DVD player can play and any DVD authoring program can edit without losing sync, so I vote for this.

    2- Keep making the mpeg file play in the most places i.e. software and hardware mpeg-2/dvd players. With our own custom cutting/editing software...
    This sounds like a nearly-standard program stream that some DVD players or authoring programs can't handle, so I don't vote for this, despite the nifty advert-zapping editor.

    John,
    Who realizes, of course, that the main criteria for what you're to work on next should be what sounds like the most fun to you.

  15. #75
    Join Date
    Aug 2002
    Posts
    260
    jdiner:

    My mistake. Misread your initial post.

    I would still stick with #2, as long as the simple GOP level editor permitted users to easily scan through (like, with a dragable bar) the video to cut where they wanted (i.e., not just sensing all black I-frames and alowing cuts there, but whatever else they wanted to cut, as well).

    If its something like, say, the simple chapter marking mechanism in SpruceUp (just a small video screen, dragable bar for position in the video and a chapter mark button) where you could essentially cut "chapters" (segments), that would probably be more than acceptable to most. The downside of being off a few extra frames on either side on cuts with GOP level editing is pretty low.

    Then, perhaps at some point later on, you might try to go back and see if you can get tytool to massage the data such that commercial editors could work on it (option #1).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •