DirecShow: Best Quality?

[hessebou]

Hello,

i want to play from a PVR-350 card and safe the stream. works fine.

but: what is the best quality no matter the bandwith.

do i set MPEG TS or what is the best?

and is it better to klick codes or dont set this options?

[VLC_help]

Quality/bitrate wise x264 is best option, but it is very CPU intensive and x264 encoder is broken in 0.9.x release. Containers don't affect to quality, they only limit codecs that you can use. If you are on local network, MPEG-2 inside TS is usually a good choice.

[dj_consoles]

i was testing use vlc to stream directshow from capture card use MPEG-2 in my LAN, so far this is the better video codec,



above is my stream info, there are some decoded block, this is normal condition ?

thx

[VLC_help]

Lost frames/butffers are bad, other things aren't.

[dj_consoles]

after one days do directshow stream, i was getting this error :

Code: Select all

ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659449822, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659489800, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659529811, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659569811, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659609800, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659649077, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659689066, last: 99659760466) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659809066, last: 99660119733) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659879688, last: 99660190333) mux_ts debug: adjusting rate at 0/381078 (68/25) mux_ts debug: adjusting rate at 0/381078 (20/5) mux_ts debug: adjusting rate at 0/381078 (5/0) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659919700, last: 99660190333) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659959688, last: 99660190333) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659999688, last: 99660190333) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99660039400, last: 99660190333) ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99660079411, last: 99660190333) stream_out_transcode debug: late picture skipped (187245) stream_out_transcode debug: late picture skipped (178245) stream_out_transcode debug: late picture skipped (185256) mux_ts debug: adjusting rate at 0/319245 (73/11) stream_out_transcode debug: late picture skipped (183689) stream_out_transcode debug: late picture skipped (174678) stream_out_transcode debug: late picture skipped (181678) stream_out_transcode debug: late picture skipped (172700) stream_out_transcode debug: late picture skipped (179700) stream_out_transcode debug: late picture skipped (186700) stream_out_transcode debug: late picture skipped (169289) stream_out_transcode debug: late picture skipped (176278)

do you advice for me ?

thx

[tkapela]

in the "Transcode" setup, try mp2v to start. If you're doing SD resolutions, most cpu's should be able to compress live. h.264 consumes more cpu than mp2v, so try mp2v first.

If you have multiple cores, you could add "threads=n" where N is the number of cores in your system. This may allow your system to encode live video if it presently is not fast enough.

One important thing to note is that win32 builds after 0.8.6 have either been crashy/unstable at SD and HD resolution when encoding, especially with threading. This may or may not actually work for you given curren state of code.

[VLC_help]

ffmpeg warning: almost fed libavcodec with a frame in the past (current: 99659919700, last: 99660190333)

prolly a libavcodec related bug.