Ticket #1179 (closed defect: invalid)

Opened 1 year ago

Last modified 1 month ago

Crash on streamed transport stream

Reported by: Nick Assigned to:
Priority: high Milestone: Bugs paradize
Component: Demuxers Version: master
Severity: major Keywords: help
Cc: jb Platform(s): Win32
Difficulty: unknown Work status: Not started

Description

I downloaded a trailer in HD from the apple site. Container is mov and codec is h264, sound aac I think.

I then streamed the file and captured it on the client to an mpeg ts. There is no packet loss on the network and when playing this file from local disk everything is ok.

So then I streamed the transport stream file with following command: 

-vv --intf dummy /work/movies/fantastic4silversurfer-tlr1_h1080p.mov   --sout #duplicate{dst=std{access=rtp,mux=ts,url=192.168.13.51:5000}}

on the client side i open vlc with upd://@5000.

When it plays the stream it has a lot of block artifacts and is realy shaky, after a while the vlc just crashes.

I've uploaded the sequence to :

ftp://streams.videolan.org/incoming/fantastic4.ts ftp://streams.videolan.org/incoming/fantastic4.txt describes the problem in short.

Oh yeah, the crash occurs in libffmpeg.dll

Change History

05/01/07 13:01:22 changed by jb

  • cc set to jb.

Does it also happen in TRUNK and nightly builds ?

05/02/07 08:01:04 changed by Nick

problem remains on trunk nightly build of 01/05/2007

09/16/07 20:37:37 changed by courmisch

  • version changed from 0.8.6 to HEAD.
  • milestone changed from 0.8.6-b to 0.9.0 bugs.

09/22/07 19:59:39 changed by courmisch

  • keywords set to help.
  • milestone changed from 0.9.0 bugs to Bugs paradize.

01/09/08 09:43:25 changed by ileoo

if possible, could you try recent nightly ? it has some changes in h264/ts stuff regarding to streaming which have included after this ticket is opened

07/27/08 13:59:13 changed by hartman

  • status changed from new to closed.
  • resolution set to invalid.

we lost this sample it seems. (likely due to switch to jones?). We are however much more resilient on these types of errors atm. We have already fixed several corrupted h264 crashes on other samples.