The VideoLAN Forums

is it possible to do multi-pass encoding with vlc?

i have noticed that with the same bitrate video files (and same codec/container), the quality of videos encoded with vlc look slightly worse than other videos (that i presume are encoded with multi-pass encoding).

if you can make vlc do multi-pass encoding, is there a way to make it raise the quality per frame, like quality to performance trade off kind of thing? i want to achieve the maximum quality video for a given bitrate.

No!

im sorry, in my original post, i meant to type, "if you CAN'T make vlc do multi-pass encoding...".

i just want to know if there is any way to make the quality of the video higher without changing the bitrate. i think i saw something like that in the preferences menu for the x264 encoder.

1. change the encoder.

2. Reduce the resolution (size).

3. Play with the encoder settings in Preferences. In most cases the defaults are a good starting point and prove to be satisfactory for most people.

as long as you mentioned encoders, which is your favorite?

i use h.264 most of the time. is this the best encoder? is there a best encoder?

It depends on the purpose. If it is quality playback from a excellent source then x264 (AVC) is probably the best choice.

yeah, that matches my purpose. thanks for all your advice

hi all, I'd like to encode videos for mobile use (small res and bitrate) but would like to see how it reacts to packet loss.
1. which encoder (free) can i use?
2. which parameters do you have access to when encoding (apart from packet size, fps, bitrate)?
3. If you choose a specific packet size and expected packet loss (for ex in QT) how does in impact the NALU size, use of FU As, intra coding redundancy? Can this be set manually in some encoders?

Thx in advance for repsonses,

cheers

1. VLC offers a reasonable variety of encoders.

2. Packet size is a function of the container, like MPEG TS. Frame rate is a function of the source. Most containers allow the specification of FPS but this does not convert per say and may lead to out of sync audio if it is different than the source. Bit rate and size (resolution) are valid for streaming.

3. There is no good way to answer your questions as generally this effects the quality and size of the file being generated and not it being streamable. Packet loss is a function of the container, speed of your connection and the traffic or reliability of the connection. I'm not sure how you would even try to account for this within the encoding of a file??? QT (to the best of my knowledge) does not support MPEG TS. But does support h.264, MP4v and MP4a in a MP4 or MOV container. For streaming MP4v in a MOV container may be the better choice because of the CPU load and up connection speed of most equipment, assuming QT compatibility is a requirement.

I agree with fps being a function of the source, and for ex a scene change reinitiates the key frame hence not perfect sync...

However, I disagree on the packet loss issue: provided that you know what is packet loss ratio in a wireless environnement (which i do) it seems possible for example to play with intra coded redundancy, placing it, say 5 FUs earlier than the redunded info if the typical packet loss burst is 3 FUs long.. this could better the quality of error resilience, could'nt it?

And a last question: how could i see (or find an example of) the throughput of an H264 encoded file function of time to see what weighs how much, and how it is mapped on NALU, abd then FU if I use a non interleaved packetization mode for instance.

Thank you for previous responses, and hope I can thank you again

cheers

Packet loss in any system forces a retransmit. So the question becomes one of time versus resolution or bitrate so the connection can keep up with what ever is being sent in real time.

Doubtful this could be accomplished at the format level. However I suppose it could be at the container level, depending on the container.

I'm not aware of tools to look at these functions. Perhaps one of the developers could point you in the right direction.

actually, i cannot alow retransmission, therefore I need to minimize the impact of a loss on the stream. however, being exceptional I need to figure out which type of redundancy is effective, and not too costly in terms of file size..
I of course use interleaving of frames, but I think some redundancies can be placed as wished..

And am still interested in throughput against time curves

cheers and thanks again

When setting up terrestrial broadcast encoding systems, we implement fairly stiff forward error correction on our UDP stream to eliminate the need for retransmission. Not sure if this is applicable to your needs, but I'll tell you that it works very well us. Note that FEC in these encoding systems is a function of dedicated, very expensive hardware devices. However, it is entirely possible to reproduce such functionality using software.