2013-02-19, 20:56
All I know is that your sample file was damaged.
2013-02-19, 20:58
all .TS samples from dvb-s MPEG2 are like that. whatever image/receiver i use, they are all like that.
Mpeg4 dvb-s2 are ok. But those aren't.
Mpeg4 dvb-s2 are ok. But those aren't.
2013-02-19, 22:59
ok here info from OpenPLI DEV, hope this can help you:
I think this is the point: If you start recording a channel, it will simply start copying any bits from the pid's in the transport stream that are relevant to the channel, which, amusingly, is also dictated by metadata from the channel itself. Enigma will probably start recording on a transport stream packet size boundary (188 bytes) bit IT WILL NOT make sure the stream is exactly at the start of PES packets for audio and video. Any player that says it can play transport stream must be able to deal with that. It must scan en discard packets that are part of a PES packet that belong to a previous PES packet until a new PES packet is started, for all substreams (all audio/video/other pid's). I think XBMC has a bug somewhere in that area. Another possibility is that XBMC doesn't try hard enough to find transport stream metadata (the PSI: PAT/PMT tables) or does a poor job interpreting them.
In any way there is very little enigma can do about this situation.
If enigma would be producing non-confirming transport streams, the SoC in the receiver (hardware, complies to standards) wouldn't be able to play them back itself!
I think this is the point: If you start recording a channel, it will simply start copying any bits from the pid's in the transport stream that are relevant to the channel, which, amusingly, is also dictated by metadata from the channel itself. Enigma will probably start recording on a transport stream packet size boundary (188 bytes) bit IT WILL NOT make sure the stream is exactly at the start of PES packets for audio and video. Any player that says it can play transport stream must be able to deal with that. It must scan en discard packets that are part of a PES packet that belong to a previous PES packet until a new PES packet is started, for all substreams (all audio/video/other pid's). I think XBMC has a bug somewhere in that area. Another possibility is that XBMC doesn't try hard enough to find transport stream metadata (the PSI: PAT/PMT tables) or does a poor job interpreting them.
In any way there is very little enigma can do about this situation.
If enigma would be producing non-confirming transport streams, the SoC in the receiver (hardware, complies to standards) wouldn't be able to play them back itself!
2013-02-20, 00:43
No idea, but I couldn't get Mplayer or VLC to play the sample either.
2013-02-20, 01:22
here .TS sample works ok with mpc-hc.
but honestly, that's it, wmp doesn't play it with ffdshow.
but honestly, that's it, wmp doesn't play it with ffdshow.
2013-02-21, 00:55
nope - ffplay is the test tool of ffmpeg. For knowing if this will be fixed by just bumping the internal ffmpeg version someone would need to build the official ffmpeg incl. ffplay and test playing the file with that tool. Then compare ffplay from ffmpeg 0.10.2 (thats what xbmc uses internally atm) with the latest ffplay/ffmpeg release.
2013-02-21, 05:34
i dont have ffplay. i can play .TS with mpc-hc, i just want to be able to play them with xbmc internal player. :|
