As I said, I'm grabbing IPTV (udp://@239.255.11.116 :udp-caching=600), I think that it's mp2v/mpga in a MPG TS.....What's the source format and container?
Well, the IPTV stream is somewhere between 8 and 16 Mbps, so I hoped that I would be able to do some compression on the fly. MP4 seemed fine... But the question is, should this happen? I mean I would accept dropped frames, maybe even a/v sync problems, but file corruption?? Is this a bug then?I bet the transcode fell behind the stream at some point and the output file got mucked up. Can't you use a 2-stage process, saving first to file as an MPEG TS encapsulation with no video or audio transcoding and run the transcode to mp4 after?
Do you mean, that the file can be corrupt because I'm missing fps from the commandline? Should I then record using e.g.From MPEG2 to MPEG4 you will need the command fps=<framerate>
Ha, I'm not in sync with you in sending messages ;-)Just remuxing with MP4Box is not going to resolve the issue as MPEG2 video needs to be transcoded into MP4 before muxing in MP4Box. If you want to do this in VLC you will need to add the command mentioned earlier.
Sure, when it's DVDs and the like, but this is IPTV that my ISP transcodes (maybe even sends raw?) from DVB-T or DVB-S, and this comes in my country's format, which is PAL, i.e. 25p or 50i.Also it is seldom that MPEG 2 is 25fps generally it is 29.97 or has a 3-2 pull down applied so that it would be 23.976
I'll try to save the log next time...There were some msgs about dropped packets ("too late for... something..." can't remember exactly).Looking at messages during the transcode will often give clues to any proplems.
This is exactly what I do, innit? Well, I use other bitrates, so I can try lower them, but I still think that should it be a performance problem, I would get some other problems than a corrupt file!?Going in the other direction (MPEG 2 to MPEG 4) the command should look something like this:
:sout=#transcode{vcodec=mp4v,vb=1024,scale=1,acodec=mp4a,ab=128,channels=2}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst="C:\Documents and Settings\Owner\My Documents\My Videos\Test.mp4"}}
Maybe, the CPU load is about 30-70% (but it's P4 2.6 with HT enabled), so it might be a problem (maybe the mp4 encoder is single-threaded?) But I still don't see why VLC should produce a corrupt file.The only thing I can think of is your machine may be to slow to capture a live stream and watch it too. Normally in a transcode the coding will speed up or slow down according to the speed of the machine, resolution of the video and or bit rate. Try opening your task Manager and look at the CPU usage during the transcode.
I suspect that there are some high bandwidth/fast motion scenes where one of the logical processors might be overloaded. It seems to me that the video encoder uses one logical processor and the audio encoder uses the other. Maybe when the video encoder reaches 50% (ie. 100% of the logical processor), it might somehow drop frames....still, corrupt file? :-) Memory should not be an issue, I have 1GB RAM...but I'll monitor it next time.30 to 70% shouldn't be an issue. Did you note the memory in use IE. was there any memory left to use? Did Messages indicate a problem during the transcode? I do MPEG2 to MP4 quite often and don't experience a problem even for real time encoding.
There's a lot ofI'm at work now so I'll try when I get home (you know, it's 10am here :-)) and post some log digest here. Thanks for all your input!
Return to “VLC media player for Windows Troubleshooting”
Users browsing this forum: No registered users and 22 guests