Disable transcode caching.. Or something?

[codilx]

Hi there,

I'm having trouble with this in Windows as well in Linux (Ubuntu).

I have a LAN broadcast of a DVB-T stream. I'm trying to transcode it and view it from work etc.

There is a problem with the broadcast itself - sometimes the signal goes out for a ~second. If you're watching the broadcast directly with VLC - it just "hiccups" and continues playing normally.

If I transcode this broadcast, during the "hiccup", the audio keeps on going the way it's supposed to, but the video tries to stay the way it was before the loss of signal. Thus - video lags behind, while audio races away - and I get a massive video/audio sync problem. I tried all possible codecs with no success, all of them try to keep the video "fluid", while the audio just goes forward. So - it has to do with VLC.

Is there a way, to disable caching.. or something? I'm not exactly sure what the problem is, but I'm trying to get the transcoding to just get over with the hiccup and transcode what it has to, instead of making the video and audio totally out of sync.

I tried:
--no-plugins-cache
audio-sync
all video/audio codecs
my VLC stream input/output caching set to 0ms

My parameters:

Code: Select all

vlc http://192.168.1.100:1101 --sout="#transcode{vcodec=DIV3,vb=1000,scale=1,acodec=mp3,width=480,height=320ab=32,channels=1,samplerate=22050,fps=25}:std{access=http,mux=ts,dst=:8080}"

[Greg]

Seems to be "Or something" causing the problem

The earlier VLC 1.0.x versions don't seem to have the same problem. Might work for you
See
viewtopic.php?f=4&t=86406
and
viewtopic.php?f=4&t=87254

Guess it needs some clever development people to fix it

[codilx]

Thanks, I've downgraded to 1.0.6, but I after initiating the same command to run the transcoding, I get this error:

Specified sample_fmt is not supported.

Edit: I noticed this due to audio codecs. I've tried mp3, mpga - both of them initiate the Specified sample_fmt is not supported. error. If I choose aac or ogg - no error shows up, but no audio is passed through. This doesn't happen with vlc 1.1.x .. Any ideas?..

Edit2: There seems to be major issues with codecs in 1.0.6 on Ubuntu 10.10. Nothing works for audio using 1.0.6, but with 1.1.4 - every codec works fine... BUT the video lagging behind audio is just killing me with 1.1.4, but having no audio but perfect video on 1.0.6 just doesn't work. I noticed that the video lagging doesn't happen in 1.0.6 (the way it's supposed to). I downed my connection so that I would have stuttering video, and it's fine - the video plays where it has to after stuttering, but when streaming with 1.1.4 - the video stays at the same place, while the audio races on.

Just annoying really.. I really hope I won't have to change my linux to windows (haven't tested 1.0.6 on windows yet, as I'm trying this from remote, and can't boot back to windows remotely). I noticed that using Ubuntu as apposed to Windows - the "hiccups" I mentioned aren't as painful in Ubuntu. The "hiccup" happens - and then it just plays quickly. With Windows - it takes another second or two to get back into rythm.

Don't get me wrong, but I wish there was real opposition against VLC. Maybe that would kickstart the developers to fix ongoing bugs. Simple bugs with the mozilla plugin haven't been fixed for 8months so far and going. Deinterlacing, transcoding, muxing issues keep haunting me and nothing seems to improve with each version. I still have to try my best to get VLC to work, as there are no alternatives that could perform the tasks I need.. But come on..

[Rémi Denis-Courmont]

It is not a matter of developers being sloppy because they do not have competition (there is competition). It's more a matter of developers not having time or not there being enough developers.

You are more than welcome to put your money and your time where your mouth is. Funding for VLC development is abysmal at the moment. Bugs don't get fixed out of thin air.

[codilx]

I would rather pay a license fee than donating to a project that isn't going anywhere for a few years now. If simple bugs would be fixed that have plagued forums and support tickets for months if not years - I would gladly donate or pay a license to use VLC. But the way it is now, I'd rather give $20 to a homeless guy, that would be more productive on both ends.

The problem is that the developers don't listen to problems that we encounter. This community is a great way to beta test new versions, and you get loads of feedback, be it good or not, but how can you explain issues, such as the one I have with this thread, or even the mozilla plugin that doesn't support fullscreen and controls?? This problem came through with versions 1.1.x up, is it that difficult to pin point what was done wrong, and just use what worked in the previous versions. It's not like you have to rewrite entire modules, just work with what works best. Already 9 public builds have been released, and none of them have fixed this problem. Only more arise, such as transcoding TV streams and video/audio sync problems that happen gradually with time, that don't occur in 1.0.x versions. How about auto deinterlacing being taken out of the new mozilla plugin, because it's a "security feature"? It's just wrong. You have a whole community that tests this software on multiple platforms, using multiple devices - you can't get any better testing done than that.

Like with most open source projects, the initial development is done with huge interest, but it dies over time, especially when more and more problems arise. Fixing problems becomes a chore, rather than pleasure when initial development started. This will end in one of two ways. 1 - the project dies completely, or 2 - it will commercialize with licenses or one-time fees. By the looks of things, the first option will most likely happen. It's sad, but a lot of huge projects died, the ones that went commercial turned to new directions as the consumer base changed. I hope none of this happens and the developers kick into action.

Good luck VLC, you need it.

[Jean-Baptiste Kempf]

I would rather pay a license fee than donating to a project that isn't going anywhere for a few years now. If simple bugs would be fixed that have plagued forums and support tickets for months if not years - I would gladly donate or pay a license to use VLC. But the way it is now, I'd rather give $20 to a homeless guy, that would be more productive on both ends.

Do what you want, but please, please avoid long bla-bla of your justification. You are making everyone loose time by reading your long diatribes.

The problem is that the developers don't listen to problems that we encounter.

This is totally untrue. Look at the many threads where the issue is "resolved in next major release", look at the mailing lists, the ticket closed on trac, etc...

What you want to say is "developers don't listen to my problems".

How can you explain issues, such as the one I have with this thread, or even the mozilla plugin that doesn't support fullscreen and controls??

Transcoding works fine for some cases, and doesn't for other cases. Maybe you are using it wrong. (you are encoding in DIV3 in 2011, SRSLY?)
The Mozilla plugin is more complex because it needs some important development investment, around 2man.months to do it.

How about you think that you are annoyed because your issues is not fixed? Guess what? you are not the only one using vlc, and not everyone has the same usecases.

Oh, and btw, you didn't even explain your issue... Pasting one line of launching vlc is not explaining. Blablating is not explaining... There is a reason why there are messages and verbosity logs... But you didn't even try to read them.

Like with most open source projects, the initial development is done with huge interest, but it dies over time, especially when more and more problems arise. Fixing problems becomes a chore, rather than pleasure when initial development started. This will end in one of two ways. 1 - the project dies completely, or 2 - it will commercialize with licenses or one-time fees. By the looks of things, the first option will most likely happen. It's sad, but a lot of huge projects died, the ones that went commercial turned to new directions as the consumer base changed. I hope none of this happens and the developers kick into action.

Bla-bla, diatribe, and majors authority arguments with no facts...
VLC development is quite well working, even if you don't like it:
http://git.videolan.org/?p=vlc.git;a=shortlog;h=HEAD

Please, go away with your hatred...
You've made me lost too much time already.

[Rémi Denis-Courmont]

So you're blaming hobbyists for not fixing your problems and not going commercial. And exactly how you're helping?

I don't want to take the financial and professional risk of starting up my own commercial VLC licensing business. Besides, I don't see who would buy 20$ licenses when you can get the software for free anyway (due to GPL). This would be a suicidal business model.

Guess what you don't want to take that responsibility, neither do we. You are in no position to lecture us.

[codilx]

@Jean-Baptiste Kempf - Yes, I'm using DIV3 in 2011, I'd rather use h264, not DIV3, because when using normal codecs such as h264, the video/audio sync drifting problem happens when transcoding a tv stream using VLC, whereas for some reason, only the DIV3 codec that I'm using in 2011 - doesn't have that issue. That's been tested on linux and windows with mid-end and high-end PCs, so I'm sure as hell this isn't a OS or CPU/GPU related issue. As you failed to notice, I'll repeat myself - 9 public builds released that have this problem, whereas older builds didn't. *facepalm* in order here. Is it THAT hard to rollback to what worked? I'm a web developer, not just a random guy who's just having a bad day, so I know this isn't THAT difficult to accomplish in a just a bit less than a year. Rollback - it worked for you almost a year ago.

"Maybe you are using it wrong." - Umm.. How about try writing an up-to-date documentation? Half of the flags and overall options I use now, are from forums here and others, not from your documentation.

"Pasting one line of launching vlc is not explaining." - If I paste a log, will it be enough for your to start actually attending to this specific problem, or is it just one of those things no one wants to do, so everyone keeps pushing it aside? I understand that live TV transcoding and streaming isn't the most used feature in VLC, but more and more people are reporting the same issue.

"Look at the many threads where the issue is "resolved in next major release", look at the mailing lists, the ticket closed on trac, etc..." - Most tickets I see are closed and not fixed.

@Rémi Denis-Courmont - What I'm trying to say, is that if this was software was payed for, 1. Hopefully there wouldn't be so many bugs that take eras to fix, and 2. More attention would be payed to problems that do rise up.

I am grateful for the developers who sacrifice their time and develope an awesome piece of code that is used by masses. I use it too, but I just wish that easy to fix issues, or problems that don't get fixed for months and years - would be fixed. But now - I can't use 1.0.x in windows, because apparently there are issues with hangups in windows (every 6 or so hours the transcoding dies without any errors), I can't use 1.0.x in linux because codecs conflict with the new kernel I have to use in order to use my DVB-T card. And I can't use 1.1.x versions in linux and windows, because of the video lagging issue. So basically - I'm screwed, until a fix comes out. That's what gets on my nerves, because fixing this problem is simple - use what worked in 1.0.x. That's all I'm trying to say.

[Rémi Denis-Courmont]

We probably have a different solution of "simple". For a start, synchronization is one of the hardest bit of code in VLC, meaning it is very hard to get right, possibly impossible to get right in all cases.

Secondly, if it was that easy, you would already have backported/forward-ported the needed patches or reverted the offending changes and compiled VLC yourself. You don't need to be a VLC develoment guru to do that.