Page 3 of 70 FirstFirst 123451353 ... LastLast
Results 31 to 45 of 1046

Thread: TyTool 9r8 - Extraction/Frame Accurate Editing/DVD output...

  1. #31
    Join Date
    Jan 2002
    Posts
    183
    Quote Originally Posted by FredThompson
    Your observation of the appearance in the window is correct, the conclusion is dead wrong.
    Actually, Fred, the only dead wrong conclusion is that I don't know *#$ about video.

    I shouldn't have said anything about line twitter because you and Josh both jumped to the same conclusion.

    These are not line-doubling artifacts, these are significant motion defects. The fields may be line-doubled to form full frames, but they are also being played out of order. Fades to black show it most prominently, where the relative luma jumps up and down. You can also see it in high-speed motion, where objects move back and forth significantly.

    You can't tell me that simple line doubling causes the average luma from frame to frame to jump up and down.

    I can see twitter that suggests that the he's doing simple line doubling, which is fine for this purpose, but that's not the issue I'm seeing.

    Now, if it's intentional, that's fine, it's still pretty straightforward to pick the right field, just a little annoying when looking for the end of fade.
    Last edited by lsmod; 02-08-2004 at 08:35 PM. Reason: The censor wouldn't even let me insult myself. ;)

  2. #32
    Join Date
    Jan 2002
    Posts
    4,809
    As I said. I have gone over all of this in great detail in a dozen posts.

    You are indeed seeing what you see. So I do I. But there are reasons for it that have nothing to do with me. Welcome to the wonderful world of DTV streams. Where nothing is as it seems.

    How does it do what it does? Well now that is a good question. Why does it do that? An even better question. The answer is locked away in a an engineers mind somewhere inside DTV.

    They use repeating fields all the time. Not in the 3:2 pulldown pattern. They appear to be using them to save space. Ocassionally they are forced to "get back on track" You see that most often right at/before/after an I-Frame. The end result, 1 field is part of 1 scene and 1 field is part of the next. Merge them to make 1 display image, which is incorrect for mpeg-2, and you get a mangled image. Play them spatially as is correct, at 59.97 fields/sec, and you get a "better looking" image. Play them with proper phosphor fade and you get the correct image.

    As you why to get S1 -> S2 -> S1 -> S2 on occasion. That is something to take up with DTV themselves. Never ever happens to me off a SA Tivo stream.

    Believe it or not it took a freaking pile of work to figure out what is going on. I am not trying to pass crap off on people. I am trying to make it work for my own use and others. Did you really think I had never seen it? Or had no idea what I was looking at? But the way you phrased your comment made me sound either stupid or lazy or just doesn't know better.

    "OK, the fields are obviously wrong in GopEditor. Static graphics twitter up and down, motion judders, fades bounce back and forth."

    Obviously wrong. Whatever... you don't like it. Go back to mpeg2vcr or m2-edit pro. Since they don't bother with looking at the fields to correct for DTV issues you are going to have great results. Knock yourself out.

    --jdiner

  3. #33
    Join Date
    Sep 2002
    Posts
    1,735
    Quote Originally Posted by lsmod
    Actually, Fred, the only dead wrong conclusion is that I don't know *#$ about video.
    Grow some skin then realize your post will be seen by a lot of people. Your post had the very real potential of confusing a lot of people.
    I shouldn't have said anything about line twitter because you and Josh both jumped to the same conclusion.
    It was the most likely way to interpret what you were trying to explain. This issue came up in the last couple of days in the 8r thread. You're the only one who can see what happens on your system.
    These are not line-doubling artifacts, these are significant motion defects. The fields may be line-doubled to form full frames, but they are also being played out of order. Fades to black show it most prominently, where the relative luma jumps up and down. You can also see it in high-speed motion, where objects move back and forth significantly.

    You can't tell me that simple line doubling causes the average luma from frame to frame to jump up and down.

    I can see twitter that suggests that the he's doing simple line doubling, which is fine for this purpose, but that's not the issue I'm seeing.

    Now, if it's intentional, that's fine, it's still pretty straightforward to pick the right field, just a little annoying when looking for the end of fade.
    Josh will probably correct me on this if I'm wrong but what you describe really seems like DTiVo source. There is some goofiness in those streams wrt jumping across GOP boundaries and such. He says field dominance3 can swap all over the stream and frames are repeated when they really shouldn't be. Is your source DTiVo?
    Collecting 9/11, Afghan/Iraq, Mail Call, Trains, Cooking, Woodworking, Fighting Illini - Let's chat
    A/V links: neuron2 doom9 VideoHelp DigitalMediaNet CreativeCow DVDShrink PgcEdit Streambox WMRecorder
    other links: SnapFiles NoNags HackADay Engadget Fontleech OfflineExplorerPro TechBargains PriceWatch

  4. #34
    Join Date
    Jan 2004
    Location
    TX
    Posts
    33
    jdiner, 8r6t1 was working great for me. I'm getting this error using 9r1 when I try to 'get' a show off the Tivo.

    SERVER: We got a message! buf = 'TYSTRM2 192.168.2.4 1284 1174344'
    -> '1174344'
    exporting fsid 1174344 of size 466616320 to stdout
    ********** #1 failed to write to stdout
    Waiting for an incomming connection!

    This happens with 9r1 client and 8r6t1 server also which seems to indictate to me that it might be a client-side problem. The problem does NOT occur with 9r1 server and 8r6t1 client.
    Last edited by pdog; 02-08-2004 at 11:24 PM.
    HDVR2 - 107 hours and monte'd

  5. #35
    Join Date
    Nov 2003
    Posts
    1,754
    Quote Originally Posted by FredThompson
    Grow some skin then realize your post will be seen by a lot of people. Your post had the very real potential of confusing a lot of people.
    It was the most likely way to interpret what you were trying to explain. This issue came up in the last couple of days in the 8r thread. You're the only one who can see what happens on your system.
    Josh will probably correct me on this if I'm wrong but what you describe really seems like DTiVo source. There is some goofiness in those streams wrt jumping across GOP boundaries and such. He says field dominance3 can swap all over the stream and frames are repeated when they really shouldn't be. Is your source DTiVo?
    Jdiner has mentioned this, the fields play in what seems to be a wierd order in the editor, but when you play the final video things are in the right order and play fine. At least everything I've done plays fine.
    Malfunct

    HDVR2 - 120hours - Extraction enabled
    SD-DVR40 - Unhacked (for now)

  6. #36
    Join Date
    Jun 2002
    Location
    here, there, everywhere
    Posts
    190
    On a side note, maybe the point releases could mean different things. (Like Linux kernel releases.) Keep the even point releases for testing/alpha/beta/preview use, and the odd point releases the 'official' release.
    so 9.1, 9.3, 9.5 would be the 'official' supported releases, while the 9.2, 9.4 etc, would be for testing. (and hopefully would not end up in ISOs)

    just a thought.

    As always, thanks for your hard work on a great tool.

    -lloyd-


    Quote Originally Posted by jdiner
    Snoopy put that in his zip? Crap. I have said over and over and over that it was junk. Only for preview purposes of the GopEditor. Crap.

    --jdiner
    SA-2000 Sony 80 Hours w/ tivonet
    SA-2000 Sony 30 Hours w/ turbonet
    SD-H400 Toshiba 80 Hours

    http://themurrays.homeip.net/downloads/tivo

  7. #37
    Join Date
    Nov 2003
    Posts
    1,754
    Quote Originally Posted by lmurray
    On a side note, maybe the point releases could mean different things. (Like Linux kernel releases.) Keep the even point releases for testing/alpha/beta/preview use, and the odd point releases the 'official' release.
    so 9.1, 9.3, 9.5 would be the 'official' supported releases, while the 9.2, 9.4 etc, would be for testing. (and hopefully would not end up in ISOs)

    just a thought.

    As always, thanks for your hard work on a great tool.

    -lloyd-
    I was certain that the file had "preview" in its name when jdiner posted it, I was under no misconception of what was in it, I think people were really hoping for a new version at that point so grabbed the first thing they saw.
    Malfunct

    HDVR2 - 120hours - Extraction enabled
    SD-DVR40 - Unhacked (for now)

  8. #38
    Join Date
    Jan 2002
    Posts
    183
    I clearly overreacted to Fred's tone, and managed to tick everyone off. Let's reset here, because I think what I'm seeing is more that you're describing.

    Quote Originally Posted by jdiner
    As I said. I have gone over all of this in great detail in a dozen posts.
    Which I didn't find, apparently. I did search for this issue and found a discussion of line doubling artifacts. And there's more going on here than just that.

    Quote Originally Posted by jdiner
    As you why to get S1 -> S2 -> S1 -> S2 on occasion. That is something to take up with DTV themselves. Never ever happens to me off a SA Tivo stream.
    What I'm seeing is not 'on occasion' It's every field of every GOP. These are all fairly old .ty files, but they are from multiple channels over a fairly broad period of time.

    Is that what you're seeing? If this is typical than I'd humbly suggest that you flip the field order in the editor. If it's not typical, then fine.

    Quote Originally Posted by jdiner
    Did you really think I had never seen it? Or had no idea what I was looking at?
    Did I really think that I had a stream that was mangled by DirecTV's psuedo-MPEG2 encoding in a way you hadn't seen before? Yes. It's happened before. I had a .ty that would flat out crash anything up to and including 8r3, so I know you were still putting in fixes for DTV weirdness. I know your sample set is pretty large, but the degree to which DTV can abuse MPEG seems boundless.

    Quote Originally Posted by jdiner
    But the way you phrased your comment made me sound either stupid or lazy or just doesn't know better.
    Not my intention. I apologize if my phrasing caught you that way. I've been here (intermittently) for a long time, and I know you've put a huge amount of work into this effort.

    -Z

  9. #39
    Join Date
    Jan 2002
    Posts
    4,809
    Quote Originally Posted by pdog
    jdiner, 8r6t1 was working great for me. I'm getting this error using 9r1 when I try to 'get' a show off the Tivo.

    SERVER: We got a message! buf = 'TYSTRM2 192.168.2.4 1284 1174344'
    -> '1174344'
    exporting fsid 1174344 of size 466616320 to stdout
    ********** #1 failed to write to stdout
    Waiting for an incomming connection!
    The server did not change between versions. The client did but not the networking. That didn't get touched.

    They should be operating exactly the same. I just downloaded 4 shows from my tivo in 1 pass with no problems of any kind. Run your own diff on the servers to make sure they are the same. They should be...

    The #1 message above is when the sending socket on the tivo times out on the send. I.e. the client blocks. Since it can't anymore thanks to taking out the parts of the Posix sockets you are supposed to have to get around some bugs in XP that should no longer be an issue. Infact it shouldn't be possible.

    Anyone else having any trouble?

    --jdiner

  10. #40
    Join Date
    Jan 2004
    Posts
    172

    27 Noob users beware

    Do NOT use the Cygwin1.dll from 8r6. It is significantly smaller and will NOT work with this version.

    Take my word, if you try to just copy your own cygwin1.dll from the previous release, mpeg2enc will just hang and you will feel silly for not having gotten all the files.

    Back to your regularly scheduled editing...

  11. #41
    Join Date
    Jan 2002
    Posts
    4,809
    Quote Originally Posted by lmurray
    On a side note, maybe the point releases could mean different things. (Like Linux kernel releases.) Keep the even point releases for testing/alpha/beta/preview use, and the odd point releases the 'official' release.
    so 9.1, 9.3, 9.5 would be the 'official' supported releases, while the 9.2, 9.4 etc, would be for testing. (and hopefully would not end up in ISOs)
    Not a bad idea. But in this case I had specifically asked him to leave those alone as they were hacks for initial testing and nothing more. He said he would and I had thought he did. Anyway, it is water under the bridge now as 9r1 is out.

    --jdiner

  12. #42
    Join Date
    Sep 2002
    Posts
    1,735
    Quote Originally Posted by lsmod
    I clearly overreacted to Fred's tone, and managed to tick everyone off. Let's reset here, because I think what I'm seeing is more that you're describing.
    Great idea. I'm sorry you took my comments as an attack. That wasn't the intent at all. I was trying to quickly explain the odd character of DTV field use in the hope of avoiding a bunch of newbie panic posts.
    Last edited by FredThompson; 02-09-2004 at 12:51 AM.
    Collecting 9/11, Afghan/Iraq, Mail Call, Trains, Cooking, Woodworking, Fighting Illini - Let's chat
    A/V links: neuron2 doom9 VideoHelp DigitalMediaNet CreativeCow DVDShrink PgcEdit Streambox WMRecorder
    other links: SnapFiles NoNags HackADay Engadget Fontleech OfflineExplorerPro TechBargains PriceWatch

  13. #43
    Join Date
    Jun 2003
    Posts
    304
    Quote Originally Posted by lsmod
    What I'm seeing is not 'on occasion' It's every field of every GOP.
    Why don't you post a short MPEG sample of your output so that people can verify what you're seeing?

  14. #44
    Join Date
    Jan 2002
    Posts
    183
    Quote Originally Posted by Toddler
    Why don't you post a short MPEG sample of your output so that people can verify what you're seeing?
    I guess I need to reiterate. This is only happening in the Frame (actually field) editor. The output is fine.

    Within the editor, the fields are consistently flipped. I understand that the DTV stream is a mess, but this is absolutely consistent in the files I have.

    Edit: Not absolutely consistent. After a dozen or so episodes, I just found one cut that didn't have the problem.

    If there's a bug here, that's fine, and I'm happy to help test and debug. If this is the way it is, a button that flips the field order for the duration of the field editor session (a single cut) would go a long way to make the editor even better than it already is.

    As it stands, it's a little difficult to find the end of a fade, since you have to hop fields two at a time.

    -Z
    Last edited by lsmod; 02-09-2004 at 02:07 AM.

  15. #45
    Join Date
    Nov 2003
    Posts
    1,754
    Quote Originally Posted by Toddler
    Why don't you post a short MPEG sample of your output so that people can verify what you're seeing?
    It doesn't show up in the mpeg, but if you are making a cut in a GOP that "fades to black" when you get close to all black you will see black frame, then picture, then black, then picture, then black black black....

    Jdiner mentioned it in one of his posts and it doesn't show up as anything bad in the final product. My assumption is that jdiner grabs frames as he finds them in the file and gets later fields before earlier ones because thats how they are in there.
    Malfunct

    HDVR2 - 120hours - Extraction enabled
    SD-DVR40 - Unhacked (for now)

Posting Permissions

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