hi,

i have a problem.... simply i have to choose AVI or MPEG-1.
but now i have to store some text-informations like subtitels in dvd's,
can i disable/enable it in mediaplayer?
is it possible with avi/mpeg-1 and what other media-container exist's?

does anyone have realized a programm to create a mpeg-1 stream and wrote in it an sublayer(for text)??? and could give me an inspiration how i can handle it?

thx
sorry for bad english

first of all mpeg-4 (as often used in avi) brings far better quality than mpeg-1/2

the downside is that most hardware player dont support it, meaning if you want to play them on most dvd players you will have to go with mpeg-1/2
svcd and dvd support own subtitle streams

if this is not the case you should use a mpeg-4 codec, but also consider using a better container than avi: ie mkv, ogm or mp4

Supported media file formats:
MPEG-1, MPEG-2 and AVI


that's the problem!
or does avi means it is possible to use mpeg-4?
and can i encode it on the fly?

ogm is so cool but still in too early dev stages...

snake, choose avi! use autogk or drDivX depending on your source...
mpeg2 is good, sure, but mpeg1 sucks big time

about subtitles, i personnaly use divx with subs generated with vobsub (from dvd) and displayed with directvobsub under win media player classic. it works really well that way, it's very flexible, it supports various subs... if you rip from dvd, autogk will take care of (almost) everything for you.
oh, yes, you can enable/disable those subs while playing file if you want to.

yes, use the divx5 or xvid codec


what do you mean? what is your source? dvd, tv... ?

This is true but there are several very easy to use programs that can convert to svcd or dvd from avi with excellent results.

The avi files can be of excellent quality and are usually 1/2 the size of corresponding mpeg1 or 2.

$.02

of course you can convert from one format to another how often you want...

but the question is if it makes sense? and it surely doesnt makes sense, if a svcd is needed, to convert to avi before

Well, I sure would rather have a two cd mp4 rip than a two cd vcd.

Just as an archival sort of thing.

My point was only that the capability to playback on a standalone would not truly be lost.

there are more and more cheap media hub to view a pc's content (avi, mpeg, jpeg...) on a tv.

transcoding is evil

Sounds to me like you are recording from a TV card? Those three options are quite usual. If that is the case it is more difficult to say what is the best format. Qualitywise, the best thing is to use AVI container with a lossless codec (like HuffYUV) and then after recording encode it to a more suitable format, like MPEG4. Recording directly to MPEG4 requires a really fast CPU and I think the quality will suffer. If you for some reason must record to directly to the final format I would go with either MPEG 1/2.

perhaps I described the topic too inaccurately .

i have to record informations from 4different cameras (over firewire/FBAS...)
the second, i have to write some events (text informations) into the file (if it is possible)

later, the videofiles must be readable for another program (that only read mpeg1/2 or avi).
now i really don'T know how to realize it, which container codec i have to choose, and how i can it create?
does anyone knows of you, how i can create a simple mpeg1 file with a my events layer? (it must be visible or not/switchable)


....fuck i hate it to write in english

A team in Australia, developing a commercial product for drivers training are using our matroska container for that, but they dont have to feed the output into another program later that will read only AVI or MPEG, and their stuff comes in compressed already ( i guess they use hardware encoders for the camera outputs).

Why do you have to use one file for all the streams ? As you have to capture 4 different video signals, and all via firewire, you first need to find an application that can handle this at all. Cheapo programs like Ulead Video Studio can certainly capture from a IEE1394 device into AVI, but from 4 at the same time ? Could you use 4 PCs ( cheapo units ) for that, and capture each video stream into an AVI of its own ?

matroska supports an unlimited number of video streams in the same file, but there are no players i know of that which would support that already, maybe VLC does. However, what are you going to do with the 4 video tracks afterwards ? Cut/Merge them into single track ? compare them, means you wonna see 4 video frames simultaneously, as they were recorded, and with very accurate timestamps ?

As a sidenote, matroska supports various forms of text subtitles in the same file, like SRT or SSA, so there is no problem to merge your text comments into the file.

Biggest obstacle IMO is to add matroska muxing output to any app capturing from firewire, and to find an app that can handle multiple cameras at the same time, unless you go for the 4 PC solution i mentioned .....

sorry but i don't have the control, another event starts/stops the record.

well if you really need to capture 4 video streams at the same time you should look for a tool that can do that before worrying about the container

matroska is one container that can handle multiple video streams (also .mp4 is possible) but as chris pointed out there are not many players which are able to play such files correctly (meaning video stream switching)

i guess we should bug gabest to write a video stream switcher finally (the ogm dshow splitter also already handles it)

surveillance purposes?
split the screen to 4 squares and encode one video stream...

some info to the file?
"abc avi tag editor"...
(i was inputting real big avs scripts into avi's with this....but this is not like subtitles,but additional notes in the file that are read with abc avi program itself)

That is b0rked. Most surveillance videos have only occaisional movement on them. So, you set up a system that drops out frames that are almost identical before they are encoded. Doing this in Matroska means you could go hours without writing any more data to the file. If three video stream are still and a fourth has movement, then you only need to encode for that fourth, while the other three take up absolutely no space.

it's a useful tool to represent information from AVI files.... (not really, that i need)
but thx.

the programming guide is changed for me, now i don't have to realize the textinformation into the videofiles.

but for now, thx for all your informations

ok,pamel,let's play that game then;explain (to some detail) an easy way to do this thing(that you just explained) in matroska....

"frames that are almost identical" is a definiton of what exactly?
every video has frames that are "almost identical" if camera is still...

"the other three" will take less space even in 4split screens,as no motion means less bitrate in encoding...if the image is perfectly still,bitrate goes almost to 0 (only the "repeat the frame/mb" info is carried and it takes very lil space)

you said this sux,so what is your proposal to this man?


fine,xsnake..try to write in your native lang. and we'll do our best...( )
lol!

If you want me to explain how to drop duplicate frames from a live video feed using current tools, I don't think that I can. I am reasonably sure that all of the tools don't exist for that, however given that the cause would be for a for-profit company, I don't believe this is asking to much. That is true, and exactly what I am referring to. You may want to take a look at Karl Lillevold's DropDupe filter. Using a filter such as this, you compare the current frame to the last stored frame. Using a user-adjustable setting, you determine if the current frame is different enough to warrant storing. Of course with real video you can search for perfectly identical frames, but it is possible to get close. There are several problems with this situation and it'll probably be easier to list them.

1. If you send a set of perfectly identical frames to a lossy codec, each frame will actually be different. This is because most codecs will compare the current frame to how the previous frame would look decoded. Because a lossy codec has lost detail on the image, it spends the next few frames correcting the image. I had assumed the same thing until I tried storing some still images as video and became frustrated with this.

2. Real video (especially security cameras) always have some variation from one frame to the next in the form of noise/static. Codecs are going to try and store this noise.

3. Because you have to store these differences, the bitrate doesn't ever reach zero, or even just a few bytes/frame.

4. You are going to want to store a keyframe every so often in case you ever need to go back and play a section, and for error protection. Even a single keyframe every minute is going to take SOME space.

5. If you combine all four videos into single stream, any extra keyframes forced by a stream with movement requires all four video streams to be stored in the keyframe. If I had to propose something for security systems, I would say to create an app that built a graph. You have 4 video inputs. Each of these is connected to a custom DropDupe filter, which is connected to the encoder filter. The 4 encoder filters are then connected to the Matroska Muxer and written to a file. If you wanted to be really slick, you create another simple source filter that feeds the current time into a subtitle input on the Matroska Muxer.

The resulting graph should look something like this: In this way, the frames that have no movement never even make it to the encoder, and thus never get saved. You could even play back that file in any current DirectShow player.

Of course, the only real benefit of storing all of the video streams in a single file is that if you seek to a time, it will seek all of the files at the same time.

Unfortunately you can't do it identical with the audio. If you drop audio packets, DirectShow (as well as many other playback systems) will skip the video frames on playback as it uses the audio samples to synch playback with the video. You could, however, create an audio filter that detected very low audio and zeroed out the audio data. Passing an audio codec audio samples that are all at zero does make for pretty good compression ratios.

If you wanted to be extra leet, then you could set a camera looking at wherever the employees signed in, and have the system store employee login/logout data as text subtitles in the file. That way you could seek to a time, see the person sign in, and have the employee information appear on the screen for the person that signed in.

@i4004: It just occured to me that you may have been asking how to solve this guys problem using Matroska and dropping out massive frames. This isn't an option since he needs it in an MPEG-1/2 or AVI source. I was just giving a possible solution for storing 4 mostly static video feeds really efficiently. My apologies if I answered the wrong question.

[quote]If you want me to explain how to drop duplicate frames from a live video feed using current tools, I don't think that I can.[/quote]
thanks for a detailed explanation
(don't get this wrong,but you asked for it...)
my solution is not borked untill you say a better solution...
when you say better solution,my solution can be trashed....

[quote]You may want to take a look at Karl Lillevold's DropDupe filter. [/quote]
dunno about that one,but karl did a helluva job in turning d9 new codecs forum into real9 hangout....and that's a good thing...for anime freaks,that is.....
(this is a sidenote without a real connection to this issue..i just had the urge to say it...)

[quote]Using a user-adjustable setting, you determine if the current frame is different enough to warrant storing.[/quote]
that is good,yes,but again,i'm questioning the real benefits if the image is REALLY STILL...then mpeg4 works extremely efficient too...
i guess the main problem with this surveillance cameras (let's say this guy indeed had simillar job,as sure as hell he never really said what's it all about) is the noise,and that noise can trigger the filter to let the frame...also,images are typically very lo-res,and that another big issue....

so i wouldn't rely on such a filter,but rather would capture all of it...after all it's a surveillance and we need complete record...if the cat triggered the alarm,we need to see it etc.

lately i saw hi-res camera for surveillance(first of it's kind)...developed by a man that did a "The Scientist and Engineer's Guide to Digital Signal Processing" (Steven W.Smith)..that's a neat device...if you can afford it,that is...

[quote]
1. If you send a set of perfectly identical frames to a lossy codec, each frame will actually be different. This is because most codecs will compare the current frame to how the previous frame would look decoded. Because a lossy codec has lost detail on the image, it spends the next few frames correcting the image. I had assumed the same thing until I tried storing some still images as video and became frustrated with this.[/quote]
i disagree...i was just toying with quantization matrices and i used still image for a test sequence (avs' imagereader) and all frames are the same and bitrate is extremely low(in fact i don't think it could be called " bitrate" at all...heh)
that test resulted this thread;
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=372

if your results differ(as you said),i think you need to see my clips...
they have all frames looking the same...no mv's employed at all....no error residue encoded likewise....silly low bitrates as a result

[quote]2. Real video (especially security cameras) always have some variation from one frame to the next in the form of noise/static. Codecs are going to try and store this noise.[/quote]
indeed,as i said...but also as i said this noise can trigger the motion detection and then we see problems with your approach....(as it may result in all frames capped...so no difference to my proposal)
so it was just overkill to employ motion detection...

[quote]3. Because you have to store these differences, the bitrate doesn't ever reach zero, or even just a few bytes/frame.[/quote]
this is same as point2...

[quote]4. You are going to want to store a keyframe every so often in case you ever need to go back and play a section, and for error protection. Even a single keyframe every minute is going to take SOME space.[/quote]
so?
your solution has all-keyframes is it's capping scene changes only....
so your bitrate goes up that tway...

[quote]5. If you combine all four videos into single stream, any extra keyframes forced by a stream with movement requires all four video streams to be stored in the keyframe. [/quote]
who says scene change in one stream will trigger KF at all?
infact i think less KF's will be generated thsi way than in your "detect-motion" way....

[quote]In this way, the frames that have no movement never even make it to the encoder, and thus never get saved. You could even play back that file in any current DirectShow player.[/quote]
i doubt this is a reliable way to do video surveillance;video surveillance relies on simple principle;capture the complete duration,don't skip...you know the murphy's law....your scd would fail in the first place...

also,your system is just an idea..i said a system that works...(actually i was soldering(producing) some ISA cards that do exactly that:4inputs video multiplexer...can switch between the inouts or can show 4 screens at once..feed this to vdub(or simply use "camstudio" or so),use mpeg4 to compress and there you go.....you only need big hdd....surveillance is NOT a place to be saving bitrate excessivelly anyway....)

[quote]Passing an audio codec audio samples that are all at zero does make for pretty good compression ratios.[/quote]
i like high compression ratios too,but come on....some people's life may depend on this stuff....we need ALL the frames on a hdd....not just frames that some filter thinks are worthy...

[quote]@i4004: It just occured to me that you may have been asking how to solve this guys problem using Matroska and dropping out massive frames.[/quote]
no,you just mixed the two of us;you said to drop frames and use mkv...i didn't...
i said your idea won't work....

[quote]This isn't an option since he needs it in an MPEG-1/2 or AVI source. I was just giving a possible solution for storing 4 mostly static video feeds really efficiently. My apologies if I answered the wrong question. [/quote]
this is just an converstaion about two ideas..i think your idea is too-fantastic and can't be applied in a sensible way...(regardless of container used)

he can store mpeg in avi too(with ffvfw... )

cheers

/ivo

This has largely to do with what you think is better. I want a low long term cost with long term storage. The link is there for you to find out about "that one". As a side note, what Karl did is prove how good support can really advance a product. I have been extremely impressed with RV9's non-anime results, but I do not use it myself because I cannot get the tools to work reliably on my system. I have chatted with Karl directly several times and have been impressed with him, his ability to quickly state the limits of his knowledge, his work, and his support. State your preference, but don't knock Karl unless he has done something wrong. Actually there are many different methods to determine if changes in an image are really changes, or if they are noise, and they work quite well. About camera resolution, I guess that just depends. Its not hard to find a digital cameral that will output 640x480. They won't be labelled for 'surveillance', but I don't see why they wouldn't work. One of the codecs I was using was whatever was the common XVID compile back in Nov 2003, so results may be different now. There were only 2 consecutive frames for each image(1544x984), so again... Initial keyframes were about 400KB in size. The following P frames for each keyframe varied from 3KB to 60KB in size. That is certainly nothing to sneeze at, especially if your images aren't identical and you have to store lots of noise. My examples are also with storing images at high bitrate, soooo..... As I said, thats not likely. Unless of course the noise is great enough, but then you just need new cameras. Regardless, with decent equipment, most frames would be dropped correctly. And point 1.... This was a though building on the first two, so I listed it seperately. I could have said the same thing twice though and not had it. Who said that? I don't know of a codec out there that is time sensetive. If you hand a codec 300 frames, it doesn't matter to the codec if you dropped 50000 frames between these as to whether or not it makes one a key frame. All it does is check if there is enough of a difference to warrant a keyframe, or if it reached the max consecutive P/B frame limit. So yes, you might have a single keyframe, and 200 P frames spread out over 10 hours of time. I'm not sure what 'scd' is, but you are right. You would definately want to beta test this for a while before relying on it. I guess that depends on your needs. I'll get to that at the end. I thought I just described a very sensible way to do it. What wasn't sensible about it?Here is how I would like to see a project like this done. This, of course, is for application where you want to be able to set it up, and then not worry about it forever. It also assumes that the area being captured is has only occaisional sporadic movement. I would use the graph as described above. I would set it up on a system that has a fast harddrive dedicated to capturing, and another dedicated to storage of the captured images. For compression, I would choose highbitrate MPEG-4, but without the more processor intesive compression functions enabled. This should allow compression of 4 streams simultaneously without much to much CPU load. The high bitrates would also ensure very clear pictures with little evidence of compression artifacts. I would like to get whatever res the camera/capture card captures at natively, but I would have to do some tests to see what the PC could handle. The software handling the graph could be set up to close the file and start a new one by some parameter such as size, or time. The old file would then be moved to the storage drive. A tape backup drive would be set to automatically backup the storage drive over a network connection. This way, fire, theft, or harddrive failure wouldn't result in lost data.

I would be very surprised if data stored would be greater than that needed for a single tape for one year. This system could run completely free of maintanence for a whole year, and the cost of more storage space after that would be another $5 tape. It would also be able to store timestamps independant of the video stream, and to store lots of useful timed metadata as described in my previous post.

And yes, I do obsess about shaving off bits.

But, as you say, the simplest would be to combine 4 videos into a singe stream and use a hardware MPEG-1/2 encoder to write it to disk. MPEG-1/2 decoders can be extremely reliable with very high levels of fault tolerance. So, its a very reliable, simple method for capturing video. It would just take much more space, and require many more tape changes.

As I was typing this, I got distracted and closed out the window. I had saved a copy of it previously, but the formatting got pooched. So, if it appears that there is a space, line, or letter missing, that is why. I am to tired now to fix it all.

[quote]I have been extremely impressed with RV9's non-anime results,[/quote]
i wasn't...still can't produce mpeg-like sharpness.....but latest vp6 (vp6.2) release has the sharpness nudged up(relative to older vp6 and rv) so i'll toy with that for very lo bitrate stuff (no,i don't expect miracles..we'll see...)
if you have been impressed with rv,you would be even more impressed with wmv9 (i think that for toons rv is better,and for natural stuff wmv9 is better...talking about very low bitrates,off course...on higher bitrates mpeg4 flavours beat both wmv and rv and vp6)

[quote] State your preference, but don't knock Karl unless he has done something wrong[/quote]
i also chatted with him a bit,and i didn't said it's a bad thing to make rv popular....but rv is a lousy natural-video codec...that's all....

karl is OK guy..it's not his fault many people do anime( )
he made rv system much more acceptable in numerous ways....
hell...i use rv from time to time.....(as wmv9 doesn't have one-pass VBR mode and is very slow...and vp6.2 will probably also be slower encoder than rv....but last few times i did ffvfw with h263 quant and it was OK...lores,15fps,cca.320kbit/s...very fast encoding too...but now i aim to pack 3h of 384x288@25fps vintage b/w,noisy,grainy material per 80min cdr;mpeg4 just won't do...it'll be either vp6.2 or rv on 3h/cdr(whichever looks sharper),or 2h of mpeg4 per cdr...)

i don't disagree with you,i just said what i saw....you know me.i like sharp codecs....anyway,doesn't matter really....h264 is far away,so perhaps rv can advance(or even beat it) untill we saw acceptable h264 ( )

as i said,for anime freaks,a good thing(if i did toons i would do rv ONLY!)....

[quote]There were only 2 consecutive frames for each image(1544x984), [/quote]
well,2frames is not really a video sequence,is it....
it's just KF and p-frame....and yes,that way you'll see difference between kf and pf....

[quote]I'm not sure what 'scd' is, but you are right. You would definately want to beta test this for a while before relying on it. [/quote]
scenechangedetection....
yes,it would require many hours of beta testing....

[quote]I thought I just described a very sensible way to do it. What wasn't sensible about it?[/quote]
lack of tools?
in a matter of speaking i proposed a way to do it,and you came with a wild idea(wild because no such tools exist....it's not a crazy idea....)
but frame dropping in surveillance?
i think all that VFR talk gave you wild ideas..( )
software can't/shouldn't be the judge what pieces of video to leave....that's the bottom line...this is why it's better to have man staring at the monitor than to have frame-dropper instead of him..heh

[quote]I would set it up on a system that has a fast harddrive dedicated to capturing, and another dedicated to storage of the captured images. For compression, I would choose highbitrate MPEG-4, but without the more processor intesive compression functions enabled.[/quote]
see,this..this is an excellent idea!
capture to raw,and then convert to mpeg4 in non-realtime way....perhaps even process the image(denoise) with a filter that would preserve all the motion intacted(removedirt)
that's a good way to save bitrate....

[quote]A tape backup drive would be set to automatically backup the storage drive over a network connection.[/quote]
yes,backup is needed here....

[quote]I would be very surprised if data stored would be greater than that needed for a single tape for one year. [/quote]
i would do it all like you said,but without frame dropping;every month tapes are collected,inspected and erased if nothing happened....
if it did,suspicious parts are collected for permant storage....

[quote]And yes, I do obsess about shaving off bits.[/quote]
no you're not...you're not using rv on anime( )
what's that,linux+rv issue?


[quote]So, its a very reliable, simple method for capturing video. It would just take much more space, and require many more tape changes. [/quote]
yes,that was my aim;simple and reliable...anyway,i would throw in your idea about re-encoding the stuff to mpeg4 (cap raw to mjpeg and reencode that to mpeg4 on big hdd's..infact why mjpeg at all;i would place avs between source and mpeg4 encoder...directshowsource() )

[quote]So, if it appears that there is a space, line, or letter missing, that is why.[/quote]
looks ok to me....i also try to keep backup of a post i'm inputting,as you never know if server will accept the reply...if it doesn't,my message is lost(i'm answering offline)

It is a video sequence. And the P frame being different from the keyframe is exactly what I was referring to, whereas you said, "if your results differ(as you said),i think you need to see my clips... they have all frames looking the same..." Which is apparently not the case. The encoder is not designed to search for a string of identical images and just encode the first one well leaving the others as repeats. IE, wasted space. That is a relatively small issue. If it were important to me I would just pay a programmer to write a program that did exactly this. It wouldn't take to long as most of the tools already exist. Actually, software usually is. That is what psychovisual models are built around. Knowing that the human eye is not likely to notice certain things, it removes them to make encoding simpler. Otherwise your only option is to encoder losslessly with something like Huffyuv. I would keep the data forever.

As a side note, dropping frames would make it MUCH easier to review the video. Because only frames with changes are kept, you can advance by frames instead of time to see just the parts where things are actually happenning.

Also, I might change your method to using one of those simple video capturers that connect through USB or FireWire. They do the encoding on the device and just pass over the compressed video. That would be much more simple to capure to the harddrive. Then you could have another computer that took the captured files and recompressed them to MPEG-4, or whatever.

One other thing, I am actually setting up some surveillance cameras for four buildings that would be viewable from a PC. Neither solution is important since they don't need the video recorded. But if they did and wanted to spend the money, I would try my way first to ensure that they could easily store the data forever. If there were any issues, I would just drop down to a simpler method.

nit-picking........
uhh..pamel you really can twist my words in AWFULL way...really....
you said you did a test,but you didn't...you used only 2frames..i told you,that's not a sequence at all.......that's nothing............

i used 250 frame sequence(of 1 natural frame looped) and i got results as i told you;very efficient encoding because encoder is made to detect the motion..if no motion,it's job is awfully simple...and encoder gets to be VERY efficient in saying "ok,no motion,just repeat the previous frame"...etc.


you know that video is mostly p(or b) frames,and in this case kf's are inserted only when encoder is forced to put it...scd will never trigger it,as there's no scene changes....huh...

the encoder is designed exactly as that;looks for things that stay the same and says;repeat this!
it encodes the other things(ie motion) by transferring them(using mv's and transferring the error if needed..that's why bitrate goes up on motion)

regarding the kf and p-frame difference,let me come clean;ffvfw will always make first frame(kf) overcompressed(at quant 31) so sure as hell you'll see THAT difference...

other than that,there really is NO difference,and kf's(other than 1st one) look exactly like p-frames!!!
i told you,i can provide you with the clips(768x576) that'll prove the thing i just said.....
(of both divx3 and ffvfw...sure,divx3's first frame is not overcompressed and looks exactly like others)
no difference to talk about...

so again,if you are encoding 1frame repeated,encoder is very efficient and ,to repeat my words;

why don't you try it for yourself?

i *don't* know what will happen in 2-frame scenario,but that's not a sequence or anything....use 300-400 frames or so....

here's a bitrate graph for such mpeg4....
http://i4004i4004.bizhosting.com/cgi-bin/i...o%20bitrate.png
lower portion of the image shows the bitrate graph,and upper one shows quantizers used....black lines are kf's....


uff..what encoder is dropping frames(other than realvideo,that is...)???
i ment pieces of timeline,not pieces of the spatial info within a frame....
i don't like the way you play,pamel...
we talked about software for dropping frames,not about ways to compress a frame;frame dropping is not a legitimate way to compress anything or to improve the compressability!

this has nothing to do with our discussion...


yes,but only if a frame dropping system is a reliable one....i doubt it would be....


yes...


i think you would have big troubles in getting it to work as you expected...where would you put a scd threshold..too high?too low?...a thief reding this would say;"aha..pamel's system...it's enough to move very slowly to fool it"....( )

your method is very tricky,and i doubt anyone will be using it...ever.....
(that reminds me of this;when i brought the finished(soldered) ISA video multiplexing boards to the developer,i asked him what OS will he use.....he said he'll use win98.....i asked;is that a clever idea?......he said that it is as only few programs will be installed(ie only their program) and that way it'll be stable enough........i think he made a mistake if he picked the win98 and left it there.....same as i think your system is not a stable system.....serious stuff needs serious solutions....i see that os2/warp is used on bank-machines ,so i would use that on surveillance too....that should be stable enough....win98 is not,even if completely empty...)