News:

--

Main Menu

v2.6 Seek to end of TS H.264 failure

Started by mbluett, December 21, 2012, 01:37:15 AM

Previous topic - Next topic

mbluett

Just installed AVIDemux 2.6 on Win 7 SP1 (64 bit version) running on a AMD Phenom II X4 945 # GHz with 4 Gig of RAM a few days ago and it doesn't appear to work properly.

1.   Won't seek to end of H.264 video (TS file created by Hauppauge Colossus) or an MPEG TS file (also create with the Colossus). An Info window opens showing a SEEK error. In a particular case it said "Error seekting to 6657048ms".

2.   When using the mouse to position the slider control (the control to the left of the jogger wheel) with a TS H.264 video, the slider will always jump to the left end of it's range (i.e., it will not stay where you put it). However, the TIME field does update to the correct spot. If you then click play the slider will jump to the correct spot.

      In MPEG TS files this works properly.

These problems make it almost impossible to remove a portion of video from the end of the video clip. And even when you do, AVIDemux gets very confused to the point of where the slider will no longer update the TIME field properly.

mbluett

De-installed AVIDemux 2.6 (64-it version) and installed a newer 32-bit version from http://code.google.com/p/mulder/ (2.6.0.8295).

The slider works fine with H.264 TS files. So it appears that problem has been fixed.  However, the seek problem is still present (i.e., I cannot seek to the end of the video file using the >| control without receiving a SEEK error).

Also I am unable the last few frames of the video. The frames I set the set the start and end markers on are both I-TFF frames.

Double-clicking on CROP under filters results in AVIDemux crashing.

Jan Gruuthuse

from 2.6 avidemux is time based and not frame based. Selecting cutting points needs to be done with up/down keyboard arrow keys only.
Download the latest (currently: r8323) from here:
http://avidemux.org/nightly/
available soon:
http://avidemux.razorbyte.com.au/

TCmullet

I have this error and numerous more.  I'm trying to edit my first .MP4 capture from a new Hauppauge Colossus.  I finally got the hang of making cuts just like in Vdub.  The B marker, like in Vdub, means that the frame PRIOR to it is the last one to be deleted when you press delete. (Makes sense, once you get the hang of it.)  But you can never delete the last frame, b/c the ability to move the pointer to the spot AFTER the last frame isn't there.  I can only move the pointer to the last frame.  You HAVE to be able to move it to "last frame + 1", in which case the screen should go blank.  This seems a fundamental requirement, such that I don't understand how the prog could have gotten to this point in time (v 2.6.1) and not have that.

The capture does not end on an I-frame.  So when I attempt to delete from the last I-frame to the end, I cannot delete the last frame (which is a P frame).  When I try to left-arrow back through the frames, it crashes.

When I save, it warns me that not all cuts were on I-frames.  Well, of course the last gop was a messy one, so I figure that's why it gives that message.  I am very sure I made all cuts throughout the 1.5 hour program EXACTLY on I-frames.  That is, I press the red "A" when the current frame says "I (xx)", and after going forward in the timeline, I press the red "B" when the current frame says "I (xx)" again.  Then press delete.  Every cut was done like this, except the last gop which I either left as is, or tried to delete.

After it crashed the first time, I nearly cried b/c of all the time I had "lost" doing these tedious edits.  And I could not find out where the crash log info was, nor any possible edit list.  I sighed relief when upon restarting, it prompted me to "load crashed file"!  So I could retry this madness repeatedly.

I had to experiment a lot to figure out what I was supposed to do with "Output Format", given that I am doing "direct stream copy" for both video and audio ("copy" and "copy").  I settled with "mp4v2 muxer".  This is different than the docs which speak of it in other terms.

While I WAS able to save my edited file two times, the files are bad, in that my original raw capture plays perfectly in Windows Media Player.  Perfect means that I can slide the scroller anywhere along the timeline and the show resumes playing perfectly at that point.  But both of my saved files play terribly, if at all, when scrolling to any point past my first embedded edit point.  To me that means the files are created incorrectly.

Would one or more of you kind folks please help me sort through these problems.  I just downloaded this today.  I installed the 32-bit Win version first, then uninstalled it and installed the 64-bit version, as I have Win 7, 64-bit.  I would be happy to make attachments, but can't figure out the cryptic instructions about "logs" etc.


TCmullet

I've discovered that what I was using was 2.6.1, the most recent RELEASED version.  The most recent BETA is 8392.  I've installed the 64-bit version of that now, and as best I can tell, all problems I described still exist.

Jan Gruuthuse

If you make your recordings in mpeg-ts format instead of your choice of mp4 recordings, is that working better?
If you make the selection for your cutting points and use the left and right arrow keys: these are not good. Only selected with up/down arrow are fine to use.
Can you provide 2 x 5 second recordings in mp4 and upload to rapidshare.com or similar internet service and provide a download link for these.
What is the used video codec in the .mp4 you saved. Perhaps these work in avidemux 2.5.6? You could use both 2.5.6 and 2.6.1 alongside.
For testing use smaller videoclips.

mean

It could be 2 things :
* The files are indeed borked
* The player is picky

For the 1st, i would need a sample of the recording untouched and instructions about what you do to try to reproduce
It does not need to be long, 1 mn is enough

TCmullet

#7
Quote from: Jan Gruuthuse on January 26, 2013, 07:39:50 AM
If you make your recordings in mpeg-ts format instead of your choice of mp4 recordings, is that working better?
I had to talk to Hauppauge customer support for a couple other things, and I asked the guy's advice about containers. The card allows 3 options.  He clarified that the vid & aud codecs are the same no matter which container I pick. When I said I'd had lots of experience w/AVI and with Mpeg2, but zero in the "HD" world, he recommended the MP4 container as being the "most editable". The 3 containers possible are M2TS (which I believe is the mpeg-ts you mentioned), TS, and MP4.  I plan for various reasons to stick w/MP4.
QuoteIf you make the selection for your cutting points and use the left and right arrow keys: these are not good. Only selected with up/down arrow are fine to use.
After checking these 4 keystrokes out, I believe you are mistaken or at least misleading about this. L & R navigate frame to frame.  The up and down arrows jump to the next I-frame the respective direction.  There's nothing inherently better about getting to an I-frame via the up/down keys vs the the single-frame keys, except that with the single-frame keys you must make sure that you are sitting on an I-frame before you pressing a select key.  I initially thought you were saying there's a serious bug where moving forward with the rt-arrow key does not actually move it forward even tho it shows that it does.  I can't simply jump to I-frames.  I have to known what is in the several frames immediately preceding and following the I-frame.  Therefore I stick w/the L & R-arrows.  But I WILL keep in mind the up/down.  Good to know.  (I would have found it in the "Go" menu eventually.)
QuoteCan you provide 2 x 5 second recordings in mp4 and upload to rapidshare.com or similar internet service and provide a download link for these?
Will do, after I finish writing this. I gather by "2 x 5" you meant 2 to 5 seconds in length.  I'll give you something longer.
QuoteFor testing use smaller videoclips.
As far as testing using smaller clips, here's where I am. I'm just getting into HD, having been in Mpeg2-capture-land for 10+ years, including a lot of Vdub usage. I was hunting for something to allow segments of an MP4 video to be cut out without re-encoding, and AVIDemux was recommended from multiple sources.  I had tried it once many months ago (2.5 or earlier), but as the instructions were not clear enough for me to learn cuts editing very quickly, I dropped it.  (I was in a hurry, and the docs are a little cryptic.) I only had minor MP4 clips.  Now that I'm getting into HD seriously, I really need a tool, so I spent SLOW t-i-m-e reading the docs.  I'm happy to see it is supposed to work like Vdub, at least as far as cutting goes.  I have a bunch of big MP4 clips captured that all need editing (and I'm way behind), so as AVIDemux has been around awhile and as simple video cuts is the most basic of actions, I saw no need to test the program apart from a real-world edit project. I unconsciously thought, "how could there be any bugs in THESE parts of the program?" But perhaps the development is not as far along as I would have expected. And the world of MP4 is anything but simple compared to the world of Mpeg1/2, I realize. I will make a short clip, then "pretend" to need to edit it.  Hopefully, I can easily recreate the problems.
QuoteWhat is the used video codec in the .mp4 you saved. Perhaps these work in avidemux 2.5.6? You could use both 2.5.6 and 2.6.1 alongside.
I had thought that would be obvious as I mentioned the Hauppauge Colossus card, which only generates 1 vid and 1 aud codec. As the card isn't new (I never invest in "new" technologies), I figured if others had come to the board with the same card, then all of you knew already. But maybe it's not widely known, so... the video is ALWAYS H.264 and the audio is always AAC. I can send MediaInfo screen shots if needed.

UPDATE:  I was partially incorrect about what the card captures for audio.  It is always AAC IF you are coming from the analog RCA jacks.  But if you use an optical cable (which I haven't acquired yet), then whatever format the source supplies is what will be stored in the container, for example, AC3.

TCmullet

Quote from: mean on January 26, 2013, 07:53:25 AM
It could be 2 things :
* The files are indeed borked
Damaged?  Not likely.  But as I mentioned to Jan, I will create a small file, vs spending a day to upload the 5GB file I've been working on.  I have several other big ones, too.  I can recapture all of them from the DVR if needed, but I doubt any are bad.  But my decade of experience with the excellent Dazzle DVC-II Mpeg2 capture card (which I still use), tells me that any time you build an encoder meant to encode in ***real time***, you are asking for problems that don't crop up in the world of software encoding. (As you know) software encoders create whatever they need to and ASK for each next frame.  But realtime encoders (which usually means hardware encoders, but that's not really relevant) have to make a lot of decisions and UNFAILINGLY generate code "out the door" IN TIME for the next frame to come, which will not wait (it's real time).  Therefore maybe the nuances of the codec's definition are pushed to some edges in these cases.  And it could be these nuances that AVDemux is not correctly anticipating.
Quote* The player is picky
I seriously doubt we can conclude that.  It's Windows Media Player, current version.  Now I know there's been a long history of WMP not doing what many want.  But if the raw MP4 created by the Colossus card is extremely playable, then any edited subset of it should be too.
QuoteFor the 1st, i would need a sample of the recording untouched and instructions about what you do to try to reproduce. It does not need to be long, 1 mn is enough
Yes, will do.  If real short, I'll attach the clip, else will use MediaFire probably.  The script I can attach.

I suspect all or most of the problems are consequential to the bug of not being able to move the cursor to the last frame + 1, so I'll look for that first.  And if I didn't say it before, I'm using "Copy", "Copy", and "mp4v2" as output options. (I landed on mp4v2 only after trying several others which didn't work.)

TCmullet

Hi guys.

Here's a raw clip, 7MB:
http://www.mediafire.com/?2brzu9urg9ick15

As I said, I'll start with "basics".

1.  Just try to go to the end.  It will fail. ("Error seekting to 24385ms")  And there are 2 errors.  The error of failing to position the cursor after the last frame, and the error of misspelling "seeking".  (You added a "t".)
2.  Just "copy" "copy" "mp4v2" the whole thing.  Then bring up both in MediaInfo.  They each have two different containers.  I expected (and kind of want) the containers to be the same.
3.  Then try any kind of cutting of GOPs out.  I can't get exactly the same problem as with my 5GB one, but I think most things you try will not come out like you wish.  These here are enough for starters.  Maybe just fixing #1 will indirectly solve others.

Is this the first you will have seen of a file from the Hauppauge (pronounced HAW-pog) Colossus?  After seeing SO many negative reviews on Amazon, I was about to go away from it (having grown used to the idea that "THIS is my future card"), but decide to call a salesman.  Gee they have offices on several continents, so how could so many cards be bad??  I came away "believing" in them again, at least enough to break my bank to buy one.  Customer support has been good so far.

You'll notice that I capped it at 2mbps avg, instead of the default 9, just to make the file smaller.

TCmullet

#10
A separate problem cropped up during my attemts to get or create a test clip.  One option was to cap an SD clip to save space.  Res. depends on the res of the incoming signal, so simply picking an SD channel allowed that.  However, the resulting 2 minute clip, though it had MANY MANY quick scene changes in it, had only ONE I-frame, which was the first frame in the clip.  All the rest were P and B frames!  This is something I'm going to communicate with Hauppauge about.  In any HD (1920x1080i) clip, there's an I-frame about every half second, with all the rest being P frames.

FYI, here are 2 test clips at 480i, each with only an initial I-frame:
http://www.mediafire.com/download.php?s76isivp48nvh56
http://www.mediafire.com/download.php?0t4frr070m1z7ai
One's at an abmornally low bitrate of 1mbps; the other is the default 4mbps average.

With only 1 I-frame throughout a long clip, that makes any cutting impossible (without reencoding).  This is raising a question I've had for years.  Wouldn't it be possible to take a given P or B frame, and programmatically retrieve the needed info from adjacent frames to MANUFACTURE it into an I-frame?  This question would have been a little appropriate in Mpeg2, but here especially it seems like a valuable function to have.  I simply want to convert a frame to I-frame so I can GOP-cut on it, like we're speaking of through this portion of my thread. I realize that at least the immediately adjacent frames would have to be modified in some way as well.

UPDATE:  Nuts.  I just recorded a 480i clip (720x480) for a full 30 minutes, with avg bitrate 4mbps.  There is still only ONE I-frame in it!  I definitely have to call Hauppauge.

TCmullet

Quote from: Jan Gruuthuse on January 26, 2013, 07:39:50 AM
If you make your recordings in mpeg-ts format instead of your choice of mp4 recordings, is that working better?
I'm going to look into that.  I'm finding evidence that TS and M2TS are better than MP4, and of the two, M2TS might be best.  I found these threads:
http://www.hauppauge.co.uk/forum/showthread.php?18394-M2TS-TS-or-MP4
http://forum.cyberlink.com/forum/posts/list/19721.page;jsessionid=0A7656708218653959235350FB91FBCD
A user there says, "The one I would choose is TS. You are probably using a Hauppauge capture card and Arcsoft software those are the 3 options you have. M2TS works well in Powerdirector, MP4 as created in Arcsoft software is a bit wonky."   I guess I don't want "wonky" files from my ArcSoft/Hauppauge-Colossus.
http://www.networkedmediatank.com/showthread.php?tid=34258
A guy there quotes a deadlink which said "TS and M2TS are effectively the same thing. M2TS adds a four byte timestamp to each packet which can help with timing during playback. (192 byte packets vs 188 byte in .ts files)"  To me that says I should use M2TS and get best possible playback.  What's a mere 2%?

Jan Gruuthuse

#12
I only have experience with mpeg-ts. These are from STB (Set-top box) DVB-S2 digital recording.
Main difference: .TS is broadcast dvb-(T/T2/S/S2/C/C2) .m2ts is used on Blu-ray Disc Video.
source: MPEG transport stream
Sample recording in mpeg-ts 18 MB download: http://rapidshare.com/files/1658367159/10Mbps1920x1080video-AVC-2ch-audio-AC-3-mpegaudio.ts

TCmullet

Jan, I looked over (and experimented with) your file in detail.  Thanks for uploading.

I use MediaInfo a lot, so I'm going by that.  (But I also see the "Info" panel in AviDemux, which has it's own oddities.)

Was surprised a bit to see 25.000 fps. I guess that means you're in PAL-land.  (No prob.--just took me by surprise.  I do realize America isn't where the majority of people are.)  Uh, "Info" shows 50fps.  Why, when it's really 25?  (I know that it's 50 FIELDS per second interlaced.)

It appears that we cannot get to the first frame.  Maybe.  (The slider isn't all the way to the left.)  The first frame should show (IMHO) as 00:00:00.000, but it shows .240.  That's less than 1 frame (.040), but greater than 1 field (.020), so I don't know what's going on there.

Also puzzling is there appears to be no keyframes (I-frames).  Only P and B.  What's the deal there, both with the file not having I's, and with the prog. treating P-frames as though they were a key-frame?

I expressed earlier frustration that I can't seek to "last frame + 1" in order to delete the trailing frames.  But I see now that if you only press "A" WITHOUT pressing "B", then it defaults to the very end and DOES delete all the trailing frames.  I was believing I MUST get on that "last + 1".  I see now you have eliminated the need for seeking to that or selecting that.  (As you may know, in Vdub, you must explicitly go to and select the "last + 1" frame.)

I successfully removed the trailing scene of the bookshelf.

I was pleased to see that the MediaInfo outputs for both unedited and edited files shows the same parameters for video and audio.  Video is MPEG-TS.

(Btw, I have scrapped the plan of capturing MP4 files, in favor of M2TS.)

But when I proceeded to edit a file from my Colossus card (an .M2TS), the input shows MPEG-TS, but the output is different, BDAV and it doesn't show "Maximum Overall bit rate" out to the right as does the original file.  This bothers me, making me hesitant to use the program.  I picked "Copy" "Copy" and "Mpeg-TS muxer" as the left column values.

Jan, (and Mean), is there any way we can get the program, when doing "Copy" "Copy" to create the new header exactly to match the input one??  BDAV might be compatible, but I think we should be able to produce the exact same header for output as input.  At the very least, it would make some of us feel MUCH MUCH safer.

Also, could you please tell about the VBR muxing option?  How can we know whether to set it or not, and what value to set it at if we do set it??   (Some explanation of what it means might make it easier for us users to decide on our own.)  I'm very ignorant, yet don't want to create a master file that won't be "right".

mean

#14

The MP4 are sort of funny
It seems to contain only one I at the beginning, and maybe PTS/DTS are borked (not 100% sure yet)

The VBR muxing means :
* If not set and you use a mux rate of 10 MBs, padding will be added so that the bitrate will stay at around 10 MBs
* If set, it can do much lower  as it depends only on the used bitrate, no padding

All non esssential headers are discarded and recreated depending on the output format
I'll see if libavformat supports TS-2 like format