[FFmpeg-user] avoid pixelated dvb-t

[Andy Furniss]

Moritz Barsnick wrote:
> Did you originally write "the console does not display errors"????
>
> On Mon, Dec 07, 2015 at 23:56:09 +0100, juan carlos Rebate wrote:
>> [h264 @ 0000000006290940] Found reference and non-reference fields
>> in the same frame, which is not implemented. Update your FFmpeg
>> version to the newest one from Git. If the problem still occurs, it
>> means that your file has a feature which has not been implemented.
>> [h264 @ 0000000006290940] If you want to help, upload a sample of
>> this file to ftp://upload.ffmpeg.org/incoming/ and contact the
>> ffmpeg-devel mailing list. (ffmpeg-devel at ffmpeg.org)
>
> Unless someone disagrees, this here is the description of your
> problem.

Yea could be, though transport streams at the start/with packet loss do
spew a lot of noise. I can't be sure I've seen that massage exactly, but
have seen "upload sample"  many times on streams that are fundamentally
playable once they get going or have a loss free run.

> If you want to capture this as a file, you probably have to do
> something like:
>
> $ ffmpeg -i rtp://239.0.0.73:8208 -map 0:v -c copy -t 10 dump.ts

This has got me wondering - is it possible with ffmpeg to dump "raw"
without remuxing. I don't know if it would work with rtp but maybe

mplayer -dumpstream

would make a better sample as the original transport stream continuity
counters/PCRs would be intact and would show up any packet loss.

Is wireless involved here?

udpxy was mentioned, I tried that many years ago and it was useless in 
my test - maybe it's better now.

> (Even more valuable information was at the top of your output,
> probably scrolled out of screen?)

It would be good to see the start = stop the player quickly.