*.rmvb editing

[datascab]

Hello, I did some splitting a re-joining with rmeditor.exe.

I had it working nicely apart from the fact the joined file is not the same as the original.

I did a split at 5 secs and it changed this to 4.969 (i think this is to do with keyframes).

The latter portion is the problem. I tried to do a split with both start times of 4.969 and 5 secs. and it doesnt come out right. The final merged file is always several msec short and there is a visual pause when watching the playback of the joined file.

Has anyone else successfully managed to split and join a file to match its original?

I read somewhere about stepping back about 50ms from the split point to make sure if includes the keyframe but this gave no improvement.

Thanks for your help.

Data

[Sirber]

http://forum.doom9.org/showthread.php?s=&threadid=66336

duplicate thread :angry:

[datascab]

I have read that thread already and managed to split and rejoin the files etc.

I can use that command line program fine.

The problem is that the split and rejoined doesnt match the original and there is a visual pause.

I always try my best to read the previous thread etc.

Thanks

Data

[karl_lillevold]

The problem is that some video data may be lost at the break point. As you know, a compressed video has key frames at certain intervals. Specifically, with RV9 we insert a key frame at every detected scene change, or at least every 10 seconds if there are no scene changes.

The way rmeditor works is that it snaps to the nearest audio frame at or after the starting time you indicate, and all video until the first video key frame after this audio key frame, will be discarded.

So it is possible to split, and then re-join without losing information, but then you have to select a split time, exactly at the audio frame prior to a video key frame. You can find all of this information with rmeditor -i input.rmvb -d dump.log.

Example:

...
packet 3275: stream 0 timestamp 57892 size: 76
packet 3276: stream 0 timestamp 57892 size: 62
packet 3277: stream 1 timestamp 57934 size: 640
packet 3278: stream 0 timestamp 57974 size:4985 keyframe
packet 3279: stream 0 timestamp 57974 size:5477 keyframe
packet 3280: stream 0 timestamp 57975 size:1314
packet 3281: stream 0 timestamp 57975 size:1368
packet 3282: stream 1 timestamp 58050 size: 640
packet 3283: stream 0 timestamp 58058 size:3565
...

In this case stream 1 is audio and stream 0 is video, and you should be able to pick timestamp 57934 as your break point for lossless split and re-join. You can translate timestamp in milliseconds to timecode like this: 0:57.934. I have verified that this works and results in no break in audio or video.

Let me know if this helps. Thanks!

[datascab]

Thanks very much for that info. I will give it a try also.

Data

[datascab]

Hello,

I just tried that method of looking at the *.log file.

Like yours, stream 0 is video and stream 1 is audio.

The unusual thing i noticed is that the keyframes are against stream 1 which is the audio stream?

Anyway, i did a split at 5.121 which is the timestamp just before a keyframe (although it says its for stream 1 which is audio).

The resultant of this was shorter than the original so no better.

I've uploaded the dump log and the *.rmvb in question to: -

http://homepage.ntlworld.com/skivy

If you get time could please take a look and tell me where i am going wrong?

Thanks

Data

[karl_lillevold]

all audio frames are "keyframes". You need to pick a cut time at the audio frame right before a video keyframe, so that would in this case be 5.341, not 5.121. However, for this short test stream, rmeditor then tells me "Error: The cut would have created a stream containing no data." for the 2nd part, but I am no rmeditor expert, so I will have to check with the Producer team.

[datascab]

ahh i see what u mean now. i dint realise about audio keyframes...

This short test sample was just to see if it would work or not.

I'll try a full 1400mb sample and see if that works.

Do you know of a GUI for this program that would automate the splitting a joining process.

Thanks

Data

[karl_lillevold]

@datascab: There is no dedicated GUI for this purpose, as far as I know. Well, except the RMEditorGUI that was shipped with the last Producer GUI, but it is not really doing this either. D-C's AutoRV9 automagically parses the 1400MB RM file to find the correct cut point to split the file into requested chunks of data, without losing information. D-C is an RM file format expert, so I am sure he could write such a standalone tool, if he wanted to and had time though.

[datascab]

Hey,

I did a full encode and split with join so i could make a good comparison.

I've posted the results on my site .....

http://homepage.ntlworld.com/skivy

in a nutshell i still was a lossy process so i'd appreciate it if you could take a look at the log file.

I did choose a timestamp that was prior to a video keyframe.

In that log is the command line text i used also.

I've also just put the properties for the 1st split file and i notice the duration is less than the cut point?

THanks

Data

[karl_lillevold]

I checked the exact behavior of rmeditor, and I think what happens is the following: There is a very specific case where B-frames are thrown out at the beginning of a cut, but that is for a good reason.

For example, if you had the following sequence:
I1 P2 B3 I4, which is written out as:
I1 P2 I4 B3

And the start cut happens at I4, then B3 is discarded since P2 is no longer available. Leaving B3 in the file would potentially create artifacts if the newly cut file was pasted to another file (since the decoder would attempt to decode B3 using I4 and the last I/P frame from the preceeding file, which is not appropriate).

If knowing that you later intend to paste the same two files back together, it would be possible to add an over-ride switch to not discard any data. There are plans to develop a frame-based RM editor, and such a feature could well be added there, but we do not plan on updating the existing rmeditor. Thanks for the discovering this problem though.

[datascab]

THanks for that info.

Is it fair to assume that telling AutoRV9 to do the split and then joining them afterwards will still yield a different end result?

From what you said do you think I will soon be able to split, edit and join without loss?

Finally a bit of advice. If you had a film that managed 100% compressilibity with a final size of 1100Mb would you create a file of this size or just make it 1400Mb since this would fill 2 CD's?

I'm hoping you might say 1100Mb since i did the Matrix 2 and this yielded 87% with a final size of 1400Mb.

Maybe now dvd recorders are cheaper this might be a better option, since i could put several films on a 4.3Gb disc with no splitting.

Thanks

Data

[karl_lillevold]

A frame based editor will unfortunately not be available anytime soon. I am afraid there can be up to three frames lost also with AutoRV9, since this a problem with rmeditor that I was not aware of until now.

Even with full anamorphic and 5.1 audio, 2 CDs are sometimes too much, and encoding for a smaller target filesize is no problem, just like you suggest. According to your properties you have 0.183 bits/pixel for your test encode, and this is a very reasonable number.

[datascab]

Hello,

Thanks for that info.

Splitting isnt a biggy at the moment.

Can you please put me out of my misery. How can you calculate the bits/pixel.

Is your calculation based on the display sixe of 1020*548?

The actual encoded space was 700*548.

THanks

Data

[karl_lillevold]

i did not know your exaxt encode size, but I guessed 720x548 :)
pixels per second : 700 * 548 * 25 = 9590000
bits per second (for video) : 1805277

bits per pixel = bits per second / pixels per second = 1805277 / 9590000 = 0.188.

This is also automatically calculated and displayed by AutoRV9, when you decide on a total filesize.

[datascab]

Thanks, that calculation is the same as the one i just cobbled together. The thing thats confusing me now is what information the compressibility test is giving me?

I did a test with this movie with the start 0.19 (autorv9 est.).

The result was 136%.

I did the same on matrix 2 and a similiar bits/pixel gave a comp. test result of 86%.

I suppose this means some films are more compressible than others.

THats ok but how can I use the compress. test results to make a better bitrate figure?

THanks

Data