GNOME Bugzilla – Bug 702152
tsdemux: Patches in output video and time stamp calculation issues with network input
Last modified: 2014-03-07 09:15:37 UTC
I am using gstreamer(version 1.0.4). I have a ts file(it is 100MB file, download it using following link), its details are given below. My pipeline is: test.ts link: https://docs.google.com/file/d/0Bx2DzyzsJg9YYmxRNXUwejYzOGc/edit?usp=sharing gst-launch-1.0 udpsrc port=10000 ! decodebin ! deinterlace mode=0 fields=1 method=4 tff=0 ! tee ! queue ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! x264enc tune=zero-latency ! filesink location=out.264 When I recieve my test.ts file through network over udp I am seeing patches in the output video after 6000 frames. Also video is running twice faster than audio(because video timestamp is half of audio timestamp), No avsynch at all. Finally it leads to pipeline hang(all threads are in pthread_cond_wait mode)!!!. This is repeatable and with roughly the same pattern so it's quite interesting. If I remove the encoder from the pipeline(see below given pipeline) I dont see any issue at all. Surprizing!!! I have validated the network input, its perfectly fine. gst-launch-1.0 udpsrc port=10000 ! decodebin ! deinterlace mode=0 fields=1 method=4 tff=0 ! tee ! queue ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! filesink location=out.yuv If I repeate the same experiment with test.ts as fileinput through filesrc I dont see any issue.!!! TS FILE DETAILS: ======================================================== Format : MPEG-TS Overall bit rate : 8 237 Kbps VIDEO ------------------------------------------------------- ID : 1002 (0x3EA) Menu ID : 1200 (0x4B0) Format : AVC Format/Info : Advanced Video Codec Format version : Version 2 Format profile : Main@L4.0 Format settings, CABAC : Yes Format settings, ReFrames : 4 frames Codec ID : 27 Bit rate : 7 312 Kbps Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Bits/(Pixel*Frame) : 0.141 Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177 Transfer characteristics : BT.709-5, BT.1361 Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177 Audio #1 ------------------------------------------------------- ID : 1003 (0x3EB) Menu ID : 1200 (0x4B0) Format : MPEG Audio Format version : Version 1 Format profile : Layer 2 Codec ID : 4 Bit rate mode : Constant Bit rate : 128 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Compression mode : Lossy Delay relative to video : -630ms Language : English Audio #2 ------------------------------------------------------- ID : 1004 (0x3EC) Menu ID : 1200 (0x4B0) Format : AC-3 Format/Info : Audio Coding 3 Format profile : Layer 2 Mode extension : ME (music and effects) Format settings, Endianness : Big Codec ID : 6 Bit rate mode : Constant Bit rate : 384 Kbps Channel(s) : 6 channels Channel positions : Front: L C R, Side: L R, LFE Sampling rate : 48.0 KHz Bit depth : 16 bits Compression mode : Lossy Delay relative to video : -781ms Stream size : 4.65 MiB (5%) Language : Hindi Thanks in advance Regards JasonP
Hi, Seeing similar issue here. Is this bug confirmed? Any updates or patches on this? Regards, Jagadish
Somewhat related to bug #704769, but that's independent of the timing problems you mention
(In reply to comment #1) > Hi, > > Seeing similar issue here. Is this bug confirmed? Any updates or patches on > this? Do you see any patches? ;)
(In reply to comment #0) > I am using gstreamer(version 1.0.4). I have a ts file(it is 100MB file, > download it using following link), its details are given below. My pipeline is: > > test.ts link: > https://docs.google.com/file/d/0Bx2DzyzsJg9YYmxRNXUwejYzOGc/edit?usp=sharing > > [...] > > When I recieve my test.ts file through network over udp I am seeing patches in > the output video after 6000 frames. Also video is running twice faster than > audio(because video timestamp is half of audio timestamp), No avsynch at all. > Finally it leads to pipeline hang(all threads are in pthread_cond_wait > mode)! What pipeline do you use to stream this file over udp, and what pipeline do you use to play back the udp stream with audio and video? Does it also stop, with all threads waiting for a condition variable, if you just play back the video?
Hi Sebastian, That was quick :) I dont see any patch. I have an FTA receiver through which I recieve TS stream. My transcoding pipeline crashes in no time. And when I analyses the timestamp using gst-launch, I was awestruck to see the mess as follows. But no issues when I record the file and replace udpsrc with filesrc. So I'm keen on knowing why is the timestamp getting messed up in live case gst-launch-1.0 udpsrc port=5050 ! decodebin ! audio/x-raw ! checksumsink 99:99:99.999999999 422c822f8731c059dffccce23d180630dd9bcef1 99:99:99.999999999 61643ecd5663d113fd5f340d213eaaea614d80b0 99:99:99.999999999 3353e1fc55fae86a2799c0ab66f65ed0cdf20110 99:99:99.999999999 15f46e1af2829ea3374599337d84ebf84760f33e 99:99:99.999999999 23392814ecaacaf70f37e3d3b9ea817063f358c5 99:99:99.999999999 07e7254f6c39ffb731fa35d180cd3077fb091b80 99:99:99.999999999 b8e1ba1519d5bc3c473b832ffe3d14eb98541a5e 99:99:99.999999999 e85f70cbbe9c4d372292348961f040d4f07dbf65 99:99:99.999999999 60d76cd846a78c3f68557afb015e744bdfbcbd1c 0:00:20.170285341 c203eb2429527afcb9b498127d7af813b90d2cdd 0:00:20.194285341 485eaac47813eaef115a06478b54b87aee9d60a4 0:00:20.218285341 2cf05ef4a79178cf98c7d7e85a4ddfe1e01cbf99 0:00:20.242285341 29d07aeb1fd832afaa7e949e2ae695b497f3d9b4 0:00:20.266285341 f0bde3f5c7dd056ac21ac615a2ba50918bda3280 0:00:20.290285341 e8fc357add181f5c84b953b86f0db0cc86036548 0:00:20.314285341 169d8fcab76215cce81d8dbe4fc5e80f3c7f1a3d 0:00:20.338285341 9038c208ca432bd9f376d22e407cd1176982ba67 0:00:20.362285341 72a0157b318808dc766491e7cc647988e65b8ac6 0:00:20.386285341 98979d59adf99da049fc2cabe69e1f757e46ae19 0:00:20.410285341 ca18829060593b4729b3c8dc8bd2f97e7aedc1f3 5124087:48:30.910070877 bba4a4a451bec4c8c774f5ad83ec3ddf024f07b5 5124087:48:30.934070877 96c228df75278e9801f953fd2da15fdbfbb4a483 5124087:48:30.958070877 d56da5ec59fe903c75a568b7a04fefcee5878945 5124087:48:30.982070877 f6cd2596f7bf19c69c7263f791c58587377f25ca 5124087:48:31.006070877 b666f2245d23d1eed121bd2b8b330d55b7645864 5124087:48:31.030070877 ef85aa462cf18ddb08d92298fa6c8b4f69fe8218 5124087:48:31.054070877 bb5a94e51f69759b04fb2f0bbd334a67e090cc81 5124087:48:31.078070877 20e75ca871293463c206a985a19eaec1264ba4de 5124087:48:31.102070877 bd80c4e7a81701eeb5aa268c91f5be395e851990 5124087:48:31.126070877 b1dfa67cee1e3b2edc7a1cd2c15ebe12de4d9642 0:00:32.438364753 f9ac641d295bdaf5e288be447bebb78b1c08b2d2 0:00:32.462364753 279ff8edbad726f4f893c54ed820393545f0dcbc 0:00:32.486364753 53aa32828ba7362f86d0784242296c3fbabf8f23 0:00:32.510364753 4c078384d3035065ed44bfcecb2bc3e21af7c752 0:00:32.534364753 c71ce54d022588775cef48981fff75aa30f04397 0:00:32.558364753 4cc3f44ede67b7adc10e184e633cac6fcf75f46c 0:00:32.582364753 3597694df7df9d634850003629d1f356523508bf 0:00:32.606364753 ed660717d5474dfa87813d2f4e42413f0d55dc8d 0:00:32.630364753 0e4134a78224ba9f054938cda01b80b4f7488432 0:00:32.654364753 921d993c68960886f6e19b7fe2e83e8658ceecbd 5124095:34:12.567848426 d4ea61e925edc354e3f59b67edfcc515309b64b6 5124095:34:12.591848426 cb4f0a96a84e1809426512a226338b09a4d662f7 5124095:34:12.615848426 12df1e492ba59f0eef2ea9bc2e0f24dcd44f8f2b 5124095:34:12.639848426 8b9acda76fe60a7fc01f4d11cf8f93fcba45f9aa 5124095:34:12.663848426 58d9f90d8ddf45b39bd5950cb45d1adc9b345918 5124095:34:12.687848426 52ca6c8229c5846a7125fb1058607160b1e8e213 5124095:34:12.711848426 4ead83c77c0853a4c7dcc6ccaff33b0c4a2859c8 5124095:34:12.735848426 4d277751b9f9f3616ed4de8253bac1c201fdbe50 5124095:34:12.759848426 dbc7a8c0e1e76b66fa867676bb5a245ae26d2478 5124095:34:12.783848426 64314fb7bb20b578604326402dde75eea3873191 0:00:32.918204235 38ff520e1dde272bcadb0013c1669606f8486146 0:00:32.942204235 ae082b0c2eccad627f5f38243c7d978932830fd8 0:00:32.966204235 c8715b22d8f96b633831fb4c08ae7cf071f0af1b 0:00:32.990204235 37edb7e49f979c74d91f7e6a540937161e975ce6 0:00:33.014204235 a320ffb01e055bcbdf26cad749624968ff0005a1 0:00:33.038204235 908074d2d08776ee17551132e9426e7a40beaa32 0:00:33.062204235 ad231aa924e93e0ffdf41e4014ff15e39f35c08a 0:00:33.086204235 5e52608d60b9a93150017c189ab4ae86559b2cb5 0:00:33.110204235 3bdc808e50819ea4cf96b816ccc9ff5a30bdd950 0:00:33.134204235 b9bd2a98ec0101c08b39feb6f8cdd810118db170 5124083:10:26.282216270 a7ee0941f7875605051e6813f149fef02cc93a13 5124083:10:26.306216270 7d699beb87ed3ef7882a3386d590cde2931b15c2 5124083:10:26.330216270 d2174adab364f6a2f0faa666e4d05d6af53db25b 5124083:10:26.354216270 76990e4bacf8ba830efa63b2313d205af4b05b86 5124083:10:26.378216270 2774ff29b95557512fa575e446b7e0c1d26e0515 5124083:10:26.402216270 a607838dd9fce8f4e8c5cb9ccf345d106268d2f9 5124083:10:26.426216270 ad801aa35e6f8929b1fa6d3e07aaa03190116926 5124083:10:26.450216270 e6942933865a4661e54f766bfeca292942d3b112 5124083:10:26.474216270 7c1afc1819f4ef3bad1ae5d14547c7f71f0e6f1b 5124083:10:26.498216270 101f62d816ae05be2432a9333f0d502a21684e39 5124083:10:26.522216270 c1a888640ae75c946faa2c10bdfb7e05e1a5b8cd 0:00:28.225719844 867929bf00215491ce7c700e20276c0b3880002a 0:00:28.249719844 e9a7c8e252b829d0291ae91ec11357a3e0033305 0:00:28.273719844 ed61103dcac75be9e6a6e69964bd880f14fa3278 0:00:28.297719844 e1de3a71b750f9fa6c69ed134ac848b44f492ebc 0:00:28.321719844 a78d606e45f51d25defd4fece73aed9e24c34301 0:00:28.345719844 999244c4ef04abe7ca60cca0ad4d0a3bb7bc2ff5 0:00:28.369719844 0803175688c7984cab8e5069ddb9acee6bb2581e 0:00:28.393719844 5ab77b5b3925a0ac736afa23e996357b31e28200 0:00:28.417719844 f2c87ef8561acc318bd71c902e21466614d06627 Regards, Jagadish
Please attach such large pastes as a file in the future, otherwise this bug will soon become unreadable ;) I'd assume something is wrong in tsdemux with the handling of timestamps in the live case when upstream does not provide proper timestamps (udpsrc). Which version are you running? Are things better with 1.1.2 or latest git master (there were quite some tsdemux changes)?
Sebastian, My apologies. Will put logs into a txt file in future I'm currently using 1.0.8 and seeing this issue. Not sure if I can check with 1.1.2 since it has API changes. Let me check with the master and let you know in a few minutes Regards, Jagadish
1.1.2 is backwards compatible with 1.0.x, API and ABI.
> > What pipeline do you use to stream this file over udp, and what pipeline do you > use to play back the udp stream with audio and video? > > Does it also stop, with all threads waiting for a condition variable, if you > just play back the video? I am using professional broadcast standard card, which reads from and file and sends sends it over udp. It handles times-tamp properly. I am playing the transcoded stream using elementary stream analyzer (player).
I mean how are you playing the udp stream with gstreamer with audio and video, to see the a/v difference. I assume the broadcast card is sending in realtime and not as fast as it can?
I can kind of reproduce this by streaming using tsplay from the tstools (https://code.google.com/p/tstools/) Jason: a small tip, try to keep chilled and remember it is volunteers working on gstreamer. Using terms like "I was awestruck to see the mess" isn't really motivating :)
Hello Edward, I'm sorry. Didn't literally mean it :-) Was just exaggerated! Sebastian, I'm currently checking with 1.1.2. Migrating dependency packages for that. Will let you know my results. If possible, will get the dumps and attach it here Many thanks :), Jagadish
(In reply to comment #11) > I can kind of reproduce this by streaming using tsplay from the tstools > (https://code.google.com/p/tstools/) > > Jason: a small tip, try to keep chilled and remember it is volunteers working > on gstreamer. Using terms like "I was awestruck to see the mess" isn't really > motivating :) Thank you Edward for the tip ;). I really appreciate the work you guys are doing. And I am afraid that I didn't post "I was awestruck to see the mess" message!!! :). Anyways, please let me know if any details are required about the bug. Thanks a ton :)
The dump that I shared earlier was a duplicate of the bug https://bugzilla.gnome.org/show_bug.cgi?id=707673 which has got fixed in git master. This issue does not exist for me now Regards, Jagadish
Thanks for the heads up ! Closing bug *** This bug has been marked as a duplicate of bug 707673 ***